Those familiar with military aviation training methods and simulators will be aware of a fact which came to my attention just last week. During a meeting with a major UK supplier of military and civilian hardware and software, their representative reminded me that military pilots, once qualified, are most regularly trained in the tasks which they least regularly carry out.

While a pilot will be operating the undercarriage and trimming elevators or the rudder in every flight, he will hopefully never need to eject from the cockpit. However, should he ever need to, he absolutely must know how to go about it, the procedures that need to be carried out and the controls used to ensure his safe ejection from the cockpit and deployment of his parachute. To ensure that this is the case, he will regularly undergo cockpit ejection training in a simulator environment, but will rarely use a simulator to practise trimming procedures.

Whatever role we find ourselves in, most of us quickly internalize those activities which we regularly carry out. How does this relate to training software engineers?

During the last few years I’ve been disappointed to learn of the number of educational establishments which will teach many of the topics we’ve discussed only through a lecture format. Whilst I appreciate that projects are time-consuming to plan and run, my experience tells me that a student who is encouraged to use the techniques they learn in the context of a team project, will not only gain a better understanding of how a project is run and the project management techniques they’ve learned, but also will be more likely remember the likes of UML and SSADM.

Application of taught skills is, in my view, essential to the full learning and further development of those skills, and also gives the opportunity for students to experience them in something closer to a real world environment, rather than just in the sterility of the lecture hall.

It’s clear to me that the use of the Structured Systems Analysis and Design Method (SSADM) is still an important part of the software engineering educational curriculum in many countries. I discussed this briefly in a recent debate with the author of one of the leading textbooks on software engineering, which in the latest editions has dropped its chapters on such ‘traditional’ techniques. While it’s true that much of the commercial software world has moved onto ‘contemporary’ techniques, I believe there is still some educational value to be gained from understanding SSADM.

The key point is that many of the contemporary techniques are simply that: techniques. Many of the standards from the Object Management Group do not advocate a particular method of invoking techniques such as the Unified Modeling Language (UML), although of course a number of methodologies such as RUP and Select Perspective incorporate UML techniques in their delivery. Therefore students may be taught how to model a system using use cases, classes, state models and components, but the context for that modeling activity is often less clearly communicated to them. The application of SSADM in an educational environment can really help students to understand the value of the common concepts behind all these techniques.

In particular, the concepts of abstraction and iteration can be very effectively taught using SSADM tools. The several levels of dataflow diagram advocated by both SSADM and Yourdon approaches are an ideal way to communicate to students how a high-level abstract view, which is simple and quick to understand, can be of real value to those trying to comprehend a complex system. Of course this high-level view is then iteratively decomposed (the reverse of abstraction) gradually increasing the level of detail of each process, until sufficient information is identified about the system.

Of course, the all-to-familiar occurrence of technology favouritism plays a part in how software engineering is taught. In my next post, I’ll consider the pitfalls of allowing personal preference to influence curriculum content too greatly, and the importance of providing a balanced viewpoint.