A process model (or life cycle) is a description of all the events and activities in the life of a software system or product and the sequence in which they happen. So you can choose how to connect the activities together to form a process model, which you can then use to elaborate a process for developing software. For example, if you arrange the five activities of requirements, design, implementation, testing and maintenance into a single sequence, you have the classic waterfall model.
However, in practice it is not usually possible to complete each activity correctly in one attempt. In addition, as development proceeds, the products of earlier stages become dated, as your understanding of both the software and its environment evolves.
If projects use a strictly sequential process model, a working version of the software system will not be available until late in the testing activity. This will represent a long wait for both customer and users, who won’t be able to see a working response to their requirements until the final product is finished. In addition, any errors detected in the working version of the software could be disastrous as it would be too late to correct them. Real projects rarely follow a purely sequential process model. The act of reviewing is an important activity when testing the quality of any development process and its resulting products.
An alternative process model is to iterate around one or more of the activities. Iteration allows the developers to improve the outputs from a given set of activities and get feedback before moving on to the next activity. In particular, iteration allows a group of people, usually developers, to perform a review of a sequence of activities, or of an activity and its outputs.
In general, reviewing a proposed solution provides the feedback necessary to modify it and improve the solution. Think what happens when you need to tune a guitar or violin. You pluck a string, a note sounds, and you adjust the tension on that string. You repeat the process until you get the desired pitch.
It is often difficult to identify all requirements and state them explicitly at the outset of a development project. It is a good idea to start with a subset of the requirements and incrementally grow the system with feedback from each iteration. This approach is known as iterative and incremental development. As shown in Figure 6, each iteration is a complete, small project, with a short, fixed timeframe (timeboxed), consisting of requirements, design, implementation, testing and integration, and resulting in a partially working system. Each of these repeated short iterations adds complexity until the final system is produced.
In an iterative and incremental development, users obtain useful and usable software quickly. This method also enables the developers to take on board feedback from users as the software develops – an increment may simply be an enhancement of the previous version. Increments can be developed sequentially or in parallel, depending on circumstances. For example, a small team might choose to develop increments sequentially, according to a priority agreed with the users.
Allow approximately 20 minutes.
OpenLearn - Approaches to software development Except for third party materials and otherwise, this content is made available under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 Licence, full copyright detail can be found in the acknowledgements section. Please see full copyright statement for details.