|
|
Teaching Old Software Dogs, Old Tricks By Professors Lawrence Bernstein and David Klappholz The ACM Software Engineering Notes will publish this article about the innovative "Live-Thru" case history approach invented by Profs Bernstein and Klappholz in their March issue. Here is the article: Software projects often fail because too many software practitioners think that the discipline of Software Engineering equals bureaucracy. They might lack Software Engineering education and expertise. If they took a Software Engineering course at all, they fought its principles. Worse, they don't accept Software Best Practices. We lectured on case histories of failed software projects and offered associated readings. Unfortunately these merely confirmed in many students their own superiority to other people's stupid mistakes. Still other students accepted intellectually that common problems exist for identifiable reasons, but did not internalize the lessons to the point of altering their own behavior. The challenge was to develop a teaching technique that creates a classroom environment that lets students make Software Engineering mistakes typical of real projects despite knowing the pitfalls and through personal experience gain insight. These insights might otherwise take years of introspection and experience to articulate- if they are ever achieved at all. Motivation Our approach is to force students to live through specific case histories. Each one is chosen to get across a few key issues. This method works. Students internalize the software engineering lessons. They then use best practices in new projects to avoid the traps they experienced. Here is how the approach works. First, select a set of software process issues. Here are the ones we chose for our first live-thru case history:
Second, chose a case history based on a project facing these challenges. Do not give students the entire case history up front; rather, give them the same problem the original developers faced. Give the students the same information about the problem than the original developers had when they began. You may simplify information to ease understanding. Background Typical Computer Science programs offer a Software Engineering or Senior Project course as a capstone. Because of the very different natures of technology on the one hand and process on the other, and because computer science students are typically technology-oriented and process-averse, the typical Software Engineering course imparts far fewer future software people than desired. We developed a novel instructional method, the Live-Thru Case History, method for addressing this problem. We applied 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. They learned how to deal with them. All this in only six weeks, with two class meetings a week. One class meeting each week was devoted to individual unstructured project meetings and the other to lectures on Software Engineering topics including other case histories. Conducting the Case History Because there would be only one live-thru case history in our Senior Project course, we choose one that would achieve the greatest effect in the limited time available. We used the case history of a brief development project that one of the authors worked on, in 1985, as a public service project. The problem 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. Results 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 for 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 re-assigned 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 the end of the live-thru 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 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. Claims 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 re-learned them as they tried to apply them. Doug McIlroy, who long ago named our field Software Engineering, comments, ".your novel fillips on the customary spec/design/build/test/deliver/evaluate team project heighten the realism of the exercise. The surprise change of team, and the hidden (as distinct from open-ended) specification is also new. Directions The authors ask 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-thru 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. The authors may be reached at lbernstein@ieee.org and d.klappholz@worldnet.att.net. |
