Author Contact Information |
|
|---|---|
|
Larry Bernstein, Director Phone:201-216-5442 |
Dr. David Klappholz Phone:201-216-5509 |
 |
 |
Volume 5 Number 2 - Software Engineering Education
Software projects often fail because the staff lacks Software Engineering education or when they had it they fought it. To compound the problem they don't accept Software Best Practices. Our challenge is to overcome the natural biases of software professionals and computer science students. Reading case histories of failed software tends to convince some students of others' stupidity. While other students intellectually accept the existence of the problems, just reading about them does not convert many at the 'gut level.' At the gut level one sits up, takes notice, and does something different.
Our approach is to force students to live through specific case histories, each one chosen to get across a small number of important issues. The method works. Students internalize the software engineering lessons and follow best practices to avoid the traps they experienced.
Here is how the approach works. First, a set of software process issues is selected. Here are the ones we chose for our first live-through case history:
Second, a case history based on a project facing these challenges is chosen. Students are not given the entire case history up front; rather, they are given the same problem/project as the actual developers who executed the case history faced. They are given no more information about the problem/project than were those developers. The project information is simplified to ease understanding.
Computer Science is the study of the technology (State-of-the-Art) involved in the development of computer software. As it is usually taught in a post-secondary setting, Computer Science deals with "programming in the small," i.e., one-person or few-person software projects. Software Engineering, on the other hand, is the study of the method or process (State-of-the-Practice) whereby production software is developed - "programming in the large." State-of-the-Practice includes both engineering practices and project management or group dynamic processes. Many post-secondary programs in Computer Science offer a Software Engineering or Senior Project course as a capstone.
Because of the very different natures of technology on the one hand and method/process on the other, and because computer science students are typically technology-oriented and method/process-averse, the typical Software Engineering course reaches far fewer future software developers than suits the best interests of either the students themselves or the software industry at large. We have developed a novel instructional method, the Live-Through Case History method for addressing this problem, have developed a first live-through case history, and have used it successfully in the first few weeks of a two-semester undergraduate Software Engineering course.
The result was that students were shocked into an awareness of the issues and how to deal with them in six weeks of two classes a week. One class meeting was devoted to project meetings and the other to lectures on Software Engineering topics including other case histories.
Because there would be only one live-through case history in our Senior Project course, we had to choose one that would achieve the greatest effect in the limited time available. We chose the case history of a brief development project that one of the authors worked on, in 1985, as a public service project. The problem/project was that of automating an elementary school library's manual system for generating overdue-book notices.
The class of forty students was divided randomly into four equal-size development teams. Students were given the same details, as were the original software developers in the case history. The instructor played the role of the customer, the school librarian, and was available to students, to respond to questions, both in class and by e-mail. Students were told that the customer would evaluate their work, exactly as work is evaluated in the real world.
As is frequently the case in real software development projects, the overdue book notice project had a hidden requirement that was so obvious to the customer that she failed to mention it; it is that overdue notices must be sorted, first by teacher name, then, for each teacher by class, and, finally, within each class by student's family name. The system analyst rejected the real software system when she first saw it. The original developers failed to elicit the hidden make-or-break requirement, and thus failed to satisfy it. Each of the student teams fell into this same trap and they learned the lesson of the need to find any 'hidden requirements.'
The need for high-quality documentation and for contingency planning were motivated students by the classroom equivalent of the real-world phenomenon of loss of staff members due to illness, death, relocation, etc. At the midpoint of the project, the student from each team judged, by the instructor, to be the team's strongest developer and another, randomly chosen, team member were removed from the team and reassigned to a different team. To evaluate the success of the staff change on students' approach to software engineering, after the case study project students were then asked to describe what they would have done differently had they understood that the real-world conditions under which they would be operating included the possibility of staff changes. About three quarters of the students mentioned the importance of up-to-date documentation, and about twenty percent had developed insight into appropriate utilization of staff, including the use of "understudies" and of preparation for the incorporation of new team members and thus demonstrated that they had learned the value of these processes.
Evaluation of how well the students internalized the need for solid requirements engineering was done at the end of the live-through case history. A written exam was based on another case history. This case history included a more difficult requirements engineering problem than that of the overdue book notice project. About three quarters of the students showed that they had mastered the notion of hidden for requirements, and about one third showed that they had achieved reasonable competence in requirements engineering; about ten percent showed extremely keen insight into the problem.
The innovative process of live-through case histories is more effective than the traditional teaching of the Software Engineering course. In the past students were given lectures, homework and exams based on a well-respected Software Engineering text. Then they were asked to develop a project. When they approached the project they could not readily apply the techniques they learned. Once they understood the need for the processes they relearned them as they tried to apply them.
The authors are asking those teaching software engineering to use these case histories in their courses and report on the results. Materials are available at web site www.NJCSE.org along with a complete paper describing the live-through approach in detail. Please participate in gathering data to support or refute the claims in this paper. It is our intent to use the experience of instructors in several venues to make anecdotal conclusions more meaningful and perhaps statistically significant. We invite those who agree with us to join a consortium for the purpose of creating additional case histories and helping to refine the process.
Lawrence Bernstein is a recognized expert in software technology, network architecture, network management software, software project management, and technology conversion. He is teaching graduate courses on Computer Networks and undergraduate Software Engineering at Stevens Institute of Technology in Hoboken, NJ.
He had a 35-year distinguished career at Bell Laboratories in managing large software projects and since retirement heads his own consulting firm. At Bell Labs he became a Chief Technical Officer of the Operations Systems Business Unit and an Executive Director. In parallel with these Bell Labs positions he was the Operations Systems Vice President of AT&T Network Systems from 1992-1996.
Mr. Bernstein holds eight software patents, has published one book and many articles on software engineering. The IEEE selected two of his articles for inclusion in best paper compendiums.
David Klappholz has twenty-seven years of experience teaching computer science and performing and supervising technology research sponsored by such organizations as NSF, DOE, IBM Research, and The New Jersey Commission on Science and Technology. His major research has been in: programming languages for parallel- and super-computers, and software tools for parallelizing sequential code. He is currently an Associate Professor of Computer Science at Stevens Institute of Technology. His current research interests include the design of novel methods for motivating and teaching Software Engineering.
Author Contact Information |
|
|---|---|
|
Larry Bernstein, Director Phone:201-216-5442 |
Dr. David Klappholz Phone:201-216-5509 |
|
|
|