Comment thread

It's been quiet here this month partly because I went diving again, but also because I've been asked to teach a course at King Mongkut's Institute of Technology in Lad Krabang here in Bangkok.

The course I've been asked to teach is Systems Analysis and Design. The course outline in the prospectus is:

Software system life cycle, techniques and tools for systems analysis and design, structure system model, prototyping, user interface design, database design, network design, coupling, cohesion, morphology and other design guidelines, including design and management of software project

That's pretty wide ranging.

Because I only have a short time to prepare for the course (just a few weeks) and the course is pretty long (nearly 50 hours over 16 weeks) I'm going just going to use the University's normal course text, Systems Analysis & Design in a Changing World by John Satzinger et al. I don't really have a strong opinion on what the book says yet, but my first impressions are that it is pretty comprehensive and pretty easy to follow. It also comes with a full set of presentation slides for each week which is also important to me as I won't have time to prepare my own.

I will be adding a number of my own points drawn from my experience of building and delivering large systems and showing lots of examples from real commercial work. I'll also be setting coursework based on real-world examples. I'll write more about these things as they happen.

If anybody out there wants a break from the rat-race then there are plenty of teaching opportunities here in Thailand where you could spend a year (or two) teaching computing at a University and spend your weekends on tropical islands. If you felt that way inclined you could also take in a PhD whilst you were doing it.

Teaching waterfall

One of the things that most surprised me was that I was told I didn't have to teach waterfall. Now I agree that a general systems analysis and design course shouldn't be teaching specific methodologies, but it does need to teach why methodologies are structured in the way they are.

Waterfall and iterative project structures attempt to optimise project resources in two different ways and have different risk and resource profiles that they work on.

For waterfall a small team performs a design and implementation plan during the early stages of the project which can then be efficiently implemented by a much larger team. The downside is of course that once the project plan is decided upon then any change to either specification or design carries with it a massive risk of project failure. It just isn't easy to get the large team of implementors to change direction.

An iterative project, on the other hand, decreases the risk of project failure where the specifications are subject to change, but the increased communications overhead means that the team size must be small. This means that iterative projects do not work for very large systems because it's almost impossible to bring enough resources to bear.

In the real world of course things aren't this polarised. Waterfall projects tend to be structured in phases to introduce some iterative aspect to the process making them less susceptible to requirements change and even the most agile of iterative projects still have scope and resource planning done before the project starts.

Successful practitioners need to understand the difference in resource allocation and specification risk in order to design a project plan that picks the right elements from both iterative and waterfall structures in order to bring the system in on time, on budget and with the required features.

This means that you can't teach systems analysis and design without teaching both waterfall and iterative development because unless you understand both ends of the spectrum you won't know how to create the methodology for your project. And that means that, old fashioned as it is, I will be teaching waterfall.

October 2007

Teaching waterfall

See also