Ramblings on Software Architecture: Software Development Process

This is the first of a set of blogs on the topic of developing software.
It relates to software architecture by showing the context; by showing how architecture
relates to the overall process.

I have always had an interest in the development process, but this was enhanced when
I got a copy of the book, "The Object Oriented Design Process” by Tom Rowlett.
The problem was that the methodology described left out many important steps, and
there was nothing about the actual development process - there was nothing on progress
control, change control or quality control. It occurred to me that I could
write a much better book, but unfortunately I am not much of a writer and there
has never been enough time. So these blogs will have to do for now.

There are three components to the development process: the model, the
methodology, and the management.

The first is the development model. This describes the overall structure of the
project and how it evolves over time. The models are "waterfall", "iterative",
"test driven", "incremental" and "spiral". Each one attempts to solve problems
with its predecessor, but still each can be used for certain categories of projects.

Waterfall

The waterfall model was the first formalisation of the development process.
The development of a system was divided into four phases: analysis, design,
implementation and testing. The project would be scheduled so that each phase
was completed before the next was begun. This simple model was well suited to
the usual project scheduling tools and has been the basis for managing projects
for many many years.

Of course there are some serious problems. If testing shows up a bug, you need
to send it back to the implementation phase to get it fixed. Similar problems
can occur in the other phases. Generally you only use the waterfall model for
very small projects in a well known environment.

Iterative

The iterative model formalises the feedback from one phase to the previous.
It allows the designers to begin work as soon as the analysts have most of
the requirements defined and it allows the designers to seek clarification
from the analysts. Similarly the programmers can start on some of the coding
earlier, and can seek clarification of the design. Testing and bug fixing can
be managed sensibly.

The main problem is that all the testing still happens at the end where the
pressure to complete is at its maximum.

Test Driven

The test driven model starts the testing process as soon as the requirements
have been defined. While the designers are developing the design for the system,
the testers can be designing their tests. The testing can begin as soon as some
components of the system have been developed.

This model works well for small developments, but for large projects it can
take too long to deliver anything, during which time the requirements can start
to change.

Incremental

The incremental model breaks the functionality of the system into separately
deliverable components, or increments. This enables us to get something
delivered quickly. It also allows the design to be adjusted if the requirements
change - each increment includes a small analysis and design step to keep the
project aligned with the business.

Note that not all increments get delivered to the customer as a release. An
increment should be a small, well defined body of work concentrating on a
single aspect and may only take a few weeks to develop. If the customer has
a lengthy acceptance testing procedure it might be overwhelmed by releases
that happen monthly, so it might be best to only do a release occasionaly.

The problem with large projects is that the first increment can take too long
to deliver since it has to create most of the infrastructure to support even the
smallest amount of functionality.

Spiral

The spiral model attempts to get early increments delivered more quickly by
using less or lower quality infrastructure. The project thus advances in two
dimensions at once - quality and functionality.

The main danger is that the initial low quality increments might give the
project a bad reputation, so it might be better to keep the first few as
demonstration only versions rather than as actual releases.