Training Software Engineers – Part 1 – Conventional Techniques

I’ve been involved in some significant training programmes over recent months and have come to realise a few things about the way we seem to teach our craft. These experiences are drawn from close to 200 hours of training I’ve delivered, developed or co-presented in the last year, which have ranged in content from ‘traditional’ techniques such as SSADM through to ‘contemporary’ agile and test-driven development. In this first post in the series, I’ll consider the relevance of the more mature approaches to software engineering to those currently learning the profession.

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.