Forum 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 ---------------------------------------------------------------------- =46rom: kpierce@d.umn.edu (Keith Pierce) 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 ---------------------------------------------------------------------- =46rom: Hossein Saiedian 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 ---------------------------------------------------------------------- =46rom: Bashar Nuseibeh Subject: PostDoc Positions Imperial College Department of Computing Project FEAST Research Associate =46ollowing 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. ---------------------------------------------------------------------- =46rom: "Kathy Beckman" 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. ---------------------------------------------------------------------- =46rom: Bob Lechner 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 E------------------------------------------------------------------- =46ASE 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 =46ax: 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 =46ax: 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 =46ax: 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 =46ax: 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 =46ax: 412-268-5758 Email: nrm@sei.cmu.edu