Forum for Advancing Software engineering EducationForum for Advancing Software engineering Education
Volume 6 Number 13 June 17, 1996
Contents:
CFP: SQE97 Symposium on Software Engineering Education
Course Materials for an SPI Course
PostDoc Positions
ASTD Series on Measuring Training ROI
Some thoughts on SwEng project scope
Subject: CFP: SQE97 Symposium on Software Engineering Education
The International Conference on Software Quality Engineering (may 5-7,
1997, Udine, Italy), includes a symposium on software engineering
education. Draft papers are due November 1, 1996. For more information,
contact the conference secretariat, Clare Shepherd at
cshepherd@wessex.witcmi.ac.uk, or see the conference web page at
http://www.witcmi.ac.uk/conferences/sqe97cfp.htm
Subject: Course Materials for an SPI Course
I plan to offer a course entitled ``Software Process Improvement'' in
which I would like to cover software process improvement concepts,
quality software, and maturity models (e.g., CMM, ISO 9003, SPICE).
This course is intended for software engineers, software development
managers, and graduate students in computer science and MIS.
Graduate standing in computer science or MIS, introductory courses in
software engineering or systems analysis, or industrial experience in
software development is expected.
Has anyone taught or attended such a course? Would you please provide
hints/suggestion:
* how to organize the course
* what topics to cover and in what order
* about how much time to spend on each topic
(this is a one-semester, 16-week course)
* what resources (books/article/reports) to use
Please respond via e-mail; I'll summarize and post.
Many thanks in advance,
Hossein Saiedian
Subject: PostDoc Positions
Imperial College
Department of Computing
Project FEAST
Research Associate
Following the award of an EPSRC grant, the Department has two vacancies
for
Post Doctoral Research Associates. Non doctoral applicants having
relevant
industrial experience may also be considered.
The FEAST/1 project will investigate, model and seek to improve the
software processes of four major industrial collaborators based on a
view
of the software process as a feedback system. It is expected that the
work
will open up new approaches to process modelling and improvement and
make
these generally available.
The successful candidates will have a strong interest in the software
engineering process and its improvement. Familiarity with modelling and
statistical estimation techniques and with dynamical systems will be a
major asset. The study, based on process structures and project data
acquired from the collaborators, will require the development and
interpretation of system dynamic process models and analyses of time
series
data for system identification.
The appointments will, in the first instance, be for two years with
salaries in the range =A318 120 to =A323 653 including London Allowance
(under
review) and are due to start in the late summer or early autumn of this
year.
To apply, submit a CV to Professor Lehman at 180 Queen's Gate, London
SW7
2BZ by 21 June 1996 (tentative - three weeks after appearance of
advert).
Include the names and addresses of two referees. For further information
phone 0171 594 8214, fax 0171 594 8215 or email mml@doc.ic.ac.uk.
Subject: ASTD Series on Measuring Training ROI
Beginning in February, 1996, in its "Training and Development" magazine,
the American Society for Training and Development (ASTD) began
publishing a 3-part series on measuring training Return on Investment
(ROI). The series is based on 18 case studies selected for publication
in Measuring Return on Investment, edited by Jack G. Phillips and
published by ASTD in 1994.
The first article, "ROI: The Search for Best Practices," by Mr.
Phillips, defines the ROI process as the fifth level of the standard
4-level Kirkpatrick training evaluation model. In this 5-level
approach, training results are measured as follows:
Level 1 Students' reaction and planned action after training
What are students' reactions to the training? What do they
plan to
do with what they've learned?
Level 2: Students' learning
What skills, knowledge, or attitudes have changed as a result
of the
training? By how much?
Level 3: Students' application of learning on the job
Did students apply what they learned once they were back on
the job?
Level 4: Business results
Did the students' application of learning on the job produce
measurable business results?
Level 5: Return on investment
Did the monetary value of the business results exceed the
training
costs?
Phillips found that while most organizations conduct Level 1
evaluations, few conduct the Level 5 ROI evaluation. He argues that
"it's difficult to show that any improvement can be attributed to
training unless measurements are taken at each level."
The rest of the first article is devoted to a model for developing ROI
evaluation, beginning with collecting post-training data and concluding
with the actual calculation of ROI. Phillips reports that many of the
organizations in the case study followed a similar model.
Reprints of this series can be obtained from ASTD Customer Service, 1640
King Street, Box 1443, Alexandria, VA USA 22313-2043, Phone
703-683-8100. Cost is $10 per article.
Subject: Some thoughts on SwEng project scope
[Excerpt from a discussion on the software requirements engineering
discussion group]
Nancy Mead Wrote:
> I can greatly sympathize with the need to use small problems for
illustration.
> One of the tasks that I undertook when I first came to the SEI was to
use
> some of Mary Shaw's architectural ideas on the real-time system I had
been
> working on in industry (a 500 KSLOC Ada project). I got some
interesting
> results which I presented to CMU's Architecture Reading Group, but the
fact
> is that I had to spend a lot of time describing the context and as a
result
> I think I lost some of the audience in those details, before
describing my
> results. I guess we need both small and large examples to show that a
method
> actually works, but it may not be very practical to publish the large
ones,
> or even a piece of them.
My remarks are prompted by the "Let's Get Real" discussion this month.
I'd like to recommend one approach that adds realism to academic
projects,
which comes from 20 years experience teaching OOA&D and Software
Engineering:
This appproach is fruitful, but time-consuming; it applies Bertrand
Meyer's
advice to evolve legacy projects over many semesters - instead of
restarting
toy projects from scratch every semester.
In fact, I believe that all software engineering students need
experience
with legacy projects of significant size (among other things, of
course).
Industrial-strength projects are not required to gain this initial
experience.
In fact, we cannot expect students to jump the three orders of magnitude
from typical (say, 1K line) academic projects to commercial products of
up to 1M lines without some intermediate steps, regardless of whether
the focus is on requirements, design, implementation or maintenance.
In my opinion, a good size for a transition project for graduating
students
would be 30K lines of code. Not coincidentally, this happens to be the
geometric mean of a 1K line academic exercise and a 1M line commercial
product. Industry needs to build further from this happy medium.
There is a price to be paid by both students and faculty:
Students go through a large learning curve
to learn the legacy project architecture and code internals,
and aonther one if they are unfamiliar with information modeling and
generic object-oriented architecture.
The instructor also undertakes a large effort,
as the local customer and manager of continuously evolving projects,
whose student programmer staff has an annual turnover about 200%.
To make this approach practical requires faculty members who have a
vested
interest in the ongoing projects. This comes from either external
sponsorship
or internal demand for the software being developed. In our case,
successive
generations of software engineering students are the consumers as well
as
the developers, of projects whose goal is a broad and self-sufficient
set
of object-oriented CASE tools.
Developing object-oriented CASE tools is a rather narrow application
domain, but it has significant advantages, and the payoff is also large:
Participating students (all MS/CS candidates at UMass-Lowell) are
already
familiar with this application domain - it is their future bread and
butter.
They have access to all the source code, which exposes the
implementation
requirements and limitations of CASE tools, as well as the problems that
maintainers must deal with. There are plenty of good and bad examples
among some 40K lines of source code and its documentation that have
evolved
during the 10-year history of this project. (:-)
Participating faculty can cover more ground and simplify their
evaluation
tasks by requiring an object-oriented methodology; analysis and design
and source code examples become readable and reusable over all projects,
not special cases that are reinvented every semester.
Our OO CASE tools fall into three generic areas:
(1) code generators for persistent databases from schema definitions;
(2) state diagram interpreters for object life cycle state models;
(3) block diagram editor for graphic design with various diagram styles;
(4) conversion processes which inter-relate tool inputs and outputs:
(a) schema diagrams provide inputs to the database code
generator;
(b) state diagrams provide inputs to the state model
interpreter ;
(c) design diagrams become .gif files and image maps with
hyperlinks
to subdiagrams and text for browsing over the web.
No matter when a student encounters these tools during their evolution,
there is plenty of opportunity to learn from their enhancments. For
example,
our tools are now being used to boot-strap one another, and are being
ported from unix to MS-Windows platforms.
This has the effect of leveraging hard-won knowledge about OO CASE tool
methodology so its use can be more productive over multiple semesters.
Bob Lechner
Computer Science Dept.
UMass-Lowell
lechner@cs.uml.edu
www.cs.uml.edu/~lechner
FASE Volume 6 Number 13
Send newsletter articles to one of the editors, preferably by
category: Articles pertinent to corporate and government training to
Kathy Beckman, sdmce@access.digex.net; Academic education, and all
other categories to fase@cs-server.d.umn.edu, or to Keith Pierce,
kpierce@d.umn.edu.
Send requests for information or to add or delete a subscription to
fase-request@cs-server.d.umn.edu
with one of the words HELP, SUBSCRIBE, or UNSUBSCRIBE in the SUBJECT
line.
Send problem reports, returned mail, or other correspondence about this
newsletter to kpierce@d.umn.edu
You can retrieve back issues by anonymous FTP from from
ricis.cl.uh.edu or through WWW at URL http://ricis.cl.uh.edu/FASE/
Keith Pierce -- Academic/Misc Editor and ListMaster
University of Minnesota Duluth, Duluth, MN 55812-2496 USA
Phone: 218- 726-7194
Fax: 218-726-6360
Email: kpierce@d.umn.edu
Kathy Beckman -- Corporate/Government Editor
Computer Data Systems
One Curie Ct., Rockville MD 20850 USA
Phone: 301-921-7027
Fax: 301-921-1004
Email: sdmce@access.digex.net
David Eichmann -- FASE Archivist
University of Houston - Clear Lake
Box 113, 2700 Bay Area Blvd., Houston, TX 77058 USA
Web: http://ricis.cl.uh.edu/eichmann/
Phone: 713-283-3875
Fax: 713-283-3810
Email: eichmann@rbse.jsc.nasa.gov or eichmann@cl.uh.edu
Laurie Werth -- Advisory Committee
Taylor Hall 2.124
University of Texas at Austin, Austin, Texas 78712 USA
Phone: 512-471-9535
Fax: 512-471-8885
Email: lwerth@cs.utexas.edu
Nancy Mead -- Advisory Committee
Software Engineering Institute
5000 Forbes Ave.
Pittsburgh, PA 15213 USA
Phone: 412-268-5756
Fax: 412-268-5758
Email: nrm@sei.cmu.edu