Choosing the appropriate level of formality
The following two examples illustrate how the amount of formality in a development process varies.
Example 10
Government legislation often requires software systems to be built to support new administrative functions. When developers compete to supply such software systems, they are asked to conform to government-approved standards. One of those standards is known as PRINCE, which stands for ‘PRojects IN Controlled Environments’ and relates to the management of projects and the quality of the developed software.
Commonly, developers must be able to show that their development process conforms to the regulations set out in PRINCE. In addition, developers may be required to adopt an approved process for their analysis and design activities. The most common of these for use with PRINCE is known as the structured software analysis and design methodology (SSADM).
Example 11
In certain financial areas, being first to offer some new service is the way to make the most profit. In other words, time-to-market is critical because if you miss out your competitor takes the spoils. When there is a need for a software system to support such a service, development is almost a race against time. Every aspect of the development process has to be tuned to meet the time-to-market.
So the aim is to do the simplest things needed that could possibly work when delivered. It also means that communication overheads must be minimised, so there will be few developers (say, two) who work to a minimal set of agreed procedures. Also, if the amount of actual code produced is small, the chance of introducing errors is reduced.
Of course, there must still be testing to ensure that the software performs its intended purpose, but if the complexity of the software is also minimal, there will be fewer tests to do.
Examples 10 and 11 show that there is no single development process that is appropriate to all kinds of software product. The amount of information recorded during development may be different in the two examples.
Example 10 illustrates the need for a formal development process. Although it is a slow and deliberate course of action, the resultant software system must be able to deal with all the nuances of the legislation. The developers must be able to show that each aspect of the legislation has been incorporated into the final software system. Software configuration management is the discipline of managing and controlling change in the evolution of software systems (IEEE, 1990, p. 20).
The control and maintenance of the integrity of a project’s deliverables (ensuring that they do not become corrupted or inconsistent) is the responsibility of the configuration management activity, which is related to the need for integration.
In contrast, Example 11 relates to software that is required for a specialised purpose with a minimal development time. The developers have the benefit of a narrow scope for the software system, and the short development time means that it is unlikely that the users will request many changes, further reducing the demands on development.
In general, the size of a project influences the choice of development process. As illustrated in Example 11, the amount of formality in the process can be minimal. Small teams of up to 10 people can communicate and respond to changes informally.
In larger projects, such as in Example 10, a well-defined procedure for controlled development is necessary – an informal communication network on its own is not enough. One approach to the solution of the problem of large projects is to split the group into smaller teams according to the responsibilities set out in a given development process. Just as modularisation is the way to deal with the complexity of a software system, developers can be assigned different activities and deliverables within a given project. This partitioning allows developers to specialise and become analysts, designers, programmers and so on.
Agile development encourages collaborative development to reduce the problems of communication that can arise in large projects. XP promotes pair programming where the code is written by pairs of programmers to encourage communication, feedback, encouragement (Beck, 2004), and in Scrum the daily scrum meeting promotes team awareness, with every member of the team knowing what others are doing. In Example 11, developers may opt for an agile approach with pair programming, as in XP, and quickly deliver an initial version that is then updated on short iteration cycles.
At some point, a software system will have outlived its usefulness. The developers should consider the expected lifetime of the prospective software when they assess the risks of producing a successful product. In Example 11, the time-to-market is a significant factor, but the expected lifetime is likely to be short because of the nature of financial markets. So a slow and deliberate development process is inappropriate.