Designing an Incremental-Iterative One-Semester, Undergraduate Course in Software Engineering
Alistair Cockburn
Humans and Technology
Humans and Technology Technical Report TR 2006.03
Abstract
This paper describes the design of a one-semester, undergraduate software engineering course that mirrors work habits from industry – teamwork, simple project management, automated testing, configuration management, and incremental development – while keeping to the IEEE/ACM Software Engineering curriculum guidelines [1]. The course makes a three-pass spiral through the topics, deepening the topics on each pass, in tandem with giving initially small and then larger assignments, handed in with incremental delivery and process reflection after each delivery.
The material is being taught in two courses at Utah Valley State College concurrently with its construction. Developing-while-teaching has caused a pruning and tightening of the course material.
1. Introduction
One of the complaints heard from industry is that software engineering courses don't properly prepare students to work in the real world. The question arises: How would an industry practitioner structure the material to give a sense of what is needed in industry, while still adhering to the IEEE/ACM curriculum guidelines?
Related is the question of how to adapt courses for agile software development. We would want to give homework assignments requiring incremental delivery while teaching modules several weeks long.
Not specifically related to those two questions, but relevant to instructors of software engineering courses, there are many who wonder what the foundations of software engineering consist of. Speaking personally, I have heard instructors in both academia and industry start by apologizing for the sorry state of software engineering. It would be a nice, though not required outcome, to be able to include a sound foundation for this introductory software engineering course.
In all cases, the course must make use of the IEEE/ACM curriculum guidelines for software engineering courses [1].
2. A new foundation, a new structure
This section addresses the design of the course for the three design questions just mentioned.
2.1. Incremental delivery
The issue with the greatest impact on course design is incremental delivery. The problem is that it may take more than half the course to present enough basic project management, requirements, analysis and design information for the student to use on their homework assignments.
The solution is to use the incremental-iterative approach to presenting the material. This can also be called a spiral approach, or as one person called it, a candle-dipping approach (keep dipping the candle until it gets thick enough).
The principle is to touch on all the "critical" issues right away, enough to establish some useful behavior, but very lightly, not to overwhelm the students. Once those are in place, the students can be given some assignments that use those basic behaviors while the instructor starts on the second spiral (dip), deepening the topics or introducing new ones.
The question, of course, is just what to include in those first lectures. That is presented in Section 3.
2.2. Agile practices
The agile practices most useful to include are: working in teams, incremental / iterative development, automated regression testing, use of configuration management, progress reporting through burn-up or earned-value charts, mid-project retrospectives, and incorporating changing requirements and designs.
These are good practices to include because although agile development shops require them, these are practices that all companies hope their new software engineers know.
2.3. Foundations for software engineering
Three foundations for software engineering are: Craft; Cooperative games of invention and communication; Lean manufacturing [2, 3].
The concept of craft teaches students to pay attention to the medium in which the work is being done and to their skills in using techniques suited to that medium. Software development involves (at least) seven crafts: Deciding what to build; Managing the project; Modeling; Designing the external view; Architecting; Programming; Validating decisions.
The students should be introduced to all seven of those crafts, with instruction that they will deepen their abilities in other courses.
Cooperative games model human activities where people have to help each other to achieve an outcome. Their "moves" serve to strengthen or weaken their position[3]. In software development, the goal is to deliver a useful system; a competing goal is to create an advantageous position for the following game, which is to extend the system or a neighboring system.
The cooperative game model teaches the importance of teamwork, of communication, and of constructing strategies in situations that never quite repeat. The need to learn strategies motivates the study of the project management body of knowledge.
Lean manufacturing, derived from Toyota’s car manufacturing, includes more than pull, kanban, and small batch sizes. It includes cross-training workers in each others' specialties, and being helpful to others in the supply chain. Most directly applicable to software engineering management, though, is the body of literature on queues in manufacturing flows.
To make that body of literature applicable to engineering requires viewing the unvalidated decision as the unit of inventory. With that shift, a software team can be seen as consisting of a coordinated flow of decision makers. All of the queuing theory and other mathematics behind lean manufacturing become available to guide the software development manager.
Lean manufacturing teaches principles for setting up and running the development environment, the importance of small batch handoffs, of cross-training people, and of helping other groups in the (decision and deliverable) supply chain.
It doesn't take much class time to present these foundations, nor do they disturb the delivery of normal software engineering material. They do, however, frame the subject matter so that the course material makes an orderly progression.
· The use of the spiral approach, ongoing linkage to other courses in the department, is naturally explained by the craft aspects of the field.
· The inclusion of teamwork, communication and project management strategies is explained by the cooperative game.
· Lean manufacturing principles explain the advanced project management strategies around work flow. These need to be mentioned in the first semester, but will probably only be understood in a second semester course.
2.4. Meeting IEEE/ACM guidelines
There is nothing in the above to contraindicate any content in the IEEE/ACM guidelines [1]. What must be done is to select the subset of the curriculum topics that meet the above criteria and that fit in approximately one semester's contact hours (see Section 5).
To guide that selection, we still need is to give the course an overriding purpose, and a selection basis or razor to decide what to include or exclude at a fine-grained level.
2.5. Purpose of the course
The purpose of the course is to show "how it all fits together." The "it all" that evidently needs fitting together refers to all the elements of a software development project; at the same time, it refers to all the courses in the software engineering curriculum.
The hope is that the student comes away from the course with an understanding of how project management fits with requirements, and those with design, testing, teamwork and documentation. This understanding will allow student to be placed on projects in a company and comprehend how their work fits with other people's.
Similarly, the student should come away from the course seeing that the other courses in the department deepen the craft practices in the field (as opposed to being a seemingly random spattering of topics).
2.5. Selection razor
The course was designed with this thought in mind: "If you had to hire a person with only these weeks of formal education, what would you want them to know when they came out?" There are many things the new employee can learn on the job, and certain things they should come already aware of.
The answer to the question is of course personal. The final selection of topics represents the bias of the people shaping its initial content: Alistair Cockburn as chief designer, and Neil Harrison and Chuck Allison of UVSC (Utah Valley State College), all with experience in both industry and academia. Neil Harrison, teaching the course at the same time that the detailed slides and test are being written, gets final veto and adjustment on each topic.
The UVSC courses consist of 25 - 30 75-minute meetings. Allowing time to discuss homework gives 12 - 18 slides per lecture (we try to include in-class activities where possible, which cuts the slide count down to 12). Because of the spiral approach, early topics must be distilled to just 12 slides.
This time pressure plus the selection razor helped in making decisions about what to keep and what to drop within the topics, down to the level of individual sentences.
The selection razor has also pointed to areas of omission within the IEEE/ACM guidelines. Section 5 lists the topics not in the guidelines that we considered important enough to include.
3. Topic sequence
Table 1 shows the allocation of themes to number of class meetings. Table 2 shows a subset of the topics selected for the six lectures in the first round.
The second round (six lectures) adds requirements gathering, external system design, and more information on each craft. Halfway through the second round, the students have sufficient background to be given their major project assignment. That assignment is scheduled to take six weeks, with a delivery and process reflection every two weeks.
Requiring the major project to be delivered incrementally serves three purposes. It teaches the students to work in incremental fashion. It gives them the opportunity to reflect on their work habits every other week and incorporate those improvements in the next delivery. Finally, it evens out the students' work load, reducing the typical end-of-semester crush.
Major Theme / # meetingsHuman: Teams / 2
Basic Project / 1
Human: Reflection / 1
Craft: PM / 2
Craft: Needs / 2
Craft: V&V / 2
Craft: External Design / 2
Craft: Architecture / 3
Craft: Programming / 1
Craft: Basic Process / 1
Approaches: many / 2
Approaches: learn 1 / 1
Advanced Project Stuff / 1
Table 1. Allocation of themes to meetings.
Teams: team exercises with reflection, team protocols, process miniatures, cooperative games, trust and feedback.Projects: alignment to purpose, priorities, planning, visibility, burn charts.
Programming: configuration management, incremental development, automated testing, Walking Skeleton.
Architecture: communicating designs, UML, responsibility-driven design, Hexagonal Architecture, design for testability.
Process, Project Management: documenting a methodology, project types, role of a PM.
Table 2. Round 1 topics (six lectures).
4. Course design and validation
We designed the course working in two directions.
First, we (Alistair, Neil, Chuck) went through the IEEE/ACM curriculum guidelines, marking topics we felt should be addressed in a one-year course on software engineering given the purpose we had set out. We trimmed that list to the subset that might be reached in the first semester, using the selection razor. We had to bear in mind that the students get several chances to see each topic.
Second, Alistair drafted a coarse-grained and medium-grained path through the topics (as described in Section 3), using both the selection razor and the IEEE/ACM topics list. Neil and Chuck reviewed that.
Third, Alistair wrote the slides and text material a few lectures ahead of each class meeting. These were reviewed by Neil, Chuck, and Dr. Chris Jones.
Dr. Jones, Chair of UVSC's Information Systems & Technology Department, became interested and offered to teach the material in that department's System Analysis, Design and Integration course. He became another reviewer of the detailed material.
5. IEEE/ACM guidelines
It would be appropriate here to show the prioritization scores for the entire list of IEEE/ACM curriculum topics. For space reasons that is not practical. What can be of interest is to see what was felt missing from that list, and what Knowledge Areas (KAs) were selected for the first two rounds of the spiral (The following tables don't show process topics; they are in the course but outside the craft spiral).
round / IEEE KA / Topic1 / FDN / shu-ha-ri [3]
1 / EVO / versioning & configuration mgmt
1 / MGT / status and visibility
1 / MGT / purpose of the system
2 / MAA / importance of domain knowledge
3 / MGT / PM strategies
3 / DES / interaction between design and team structure (Conway's Law)
Table 3. Key topics in the course but not in the IEEE/ACM curriculum guidelines.
IEEE KA / TopicPRF / team communication
Cmp / test-first programming
DES / design principles: cohesion coupling
MAA / requirements process
MAA / acceptance test design
MGT / work breakdown structure
MGT / effort estimation
VAV / regression testing
Table 4. IEEE topics included in the first round.
IEEE KA / TopicCmp / reuse & libraries
DES / interaction between design and requirements
DES / design tradeoffs
DES / measures of attributes (coupling, cohesion)
EVO / impact analysis
MAA / requirement for product versus project; system boundary
MAA / managing changing requirements
MGT / task scheduling
MGT / resource allocation
PRO / individual software process (model, define, measure, improve)
PRO / team processes (as above)
VAV / cognitive walkthroughs
VAV / coverage analysis
VAV / test cases from use cases and stories
Table 5. IEEE topics included in the second round.
7. Acknowledgements
The philosophy of the course design, the course structure and the detailed lesson plans are due to Alistair Cockburn. This is one reason Alistair is the sole author on this paper.
Neil Harrison and Chuck Allison expressed interest in tuning, teaching and validating the course at UVSC. They co-prioritized the IEEE topics and reviewed the material at every stage. Neil Harrison deserves additional credit for being the first volunteer to teach the course.
The second acknowledgement is to Dr. Chris Jones of UVSC for offering to be another test subject. Both Neil and Chris signed up to teach a course with an unusual structure, being written just days ahead of their teaching schedules.
They are writing experience papers evaluating the course design from the instructor's perspective.
8. References
[1] IEEE Computer Society, Association for Computing Machinery, Software Engineering 2004: Curriculum Guidelines for Undergraduate Degree Programs in Software Engineering, A Volume of the Computing Curricula Series, August 23, 2004.