Software Engineering and Development Life Cycle

Software Process Models

---

A software process model is an abstract structural description of how a software development process is carried out. There exists a wide range of software process models. Even the simple example from analysis to coding (Fig. 1), outlined by Winston W. Royce in “Managing the development of large software systems: concepts and techniques”, could be seen as a process model.

Fig 1. — In simple projects that are intended for internal use, a simple process from analysis of the problem to coding can be sufficient.

While the above process can be suitable for small projects intended for internal use, additional steps are needed as projects grow more complex.

Loading Exercise...

The article by Royce also included a diagram of a more complete process, starting from requirements end ending with operations, shown below (Fig. 2).

Fig 2. — In simple projects that are intended for internal use, a simple process from analysis of the problem to coding can be sufficient.

Although Royce never used the term, the process shown in Figure 2 has since become known as the Waterfall model. In the Waterfall model, each of the phases of the software development life cycle are completed before the next phase begins, which allows bringing in information from the previous phase into the next phase.

The Waterfall model became popular in the 1980s, in part as it was adopted by the US Department of Defense. The US Department of Defence expected that software development contractors would follow the Waterfall model when developing software.

However, in his article, Royce also argued that the Waterfall model is not suitable for large software systems, as it does not allow for feedback from the later phases to the earlier phases.

One could ask whether the folks at the US Department of Defense ever read Royce’s article to the end.

Loading Exercise...

In the article, Royce outlines incrementally better models, where information learned during later phases could be provided to earlier phases, and also highlights aspects such as creating a preliminary program design before coding, working on a prototype first, and having an understandable overview document that is up to date.

Most importantly, Royce emphasized the need to involve the customer in the development process, as the customer is the one who knows what they want.

Involving customer early on is also at the core of Agile process models that have become increasingly popular in the last few decades. Agile process models are a response to documentation-driven heavy software development processes. Agile process models build on the idea of iterative and incremental development, where the software is developed in short iterations (e.g. a few weeks), and the requirements are refined during the development process with the intent to maximize value for the customer.

Working on the software in short iterations allows for the customer to see the progress and to provide feedback. It helps also the team to continuously validate or correct their approach. This is in line with the Agile Manifesto, which emphasizes customer collaboration over contract negotiation:

We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.

Loading Exercise...

Although Agile is mentioned here, it is important to note that Agile is not a silver bullet and Agile process models may not be suitable for all projects. The term Agile has also been used quite loosely, even to the extent of associating it with just hacking away. Agile should not be thought of a practice where requirements or specifications are not needed; rather, Agile emphasizes the importance of customer collaboration and responding to change.

Hacking away without a good overview of requirements or without a specification can increase the likelihood of failed project.