The software process can be decomposed into stages, sometimes also called phases, and activities. The stages comprise the set of activities necessary to achieve a milestone. Activities generate products, like the requirement specifications, software architectures, or the source code. A milestone defines a point of macro management, where the project stakeholders assess whether the stage goal was achieved, and if the project can proceed to the next stage, repeat the current stage, or even if the project should be canceled. On the other hand, at the end of each activity there is a micro management evaluation where the project manager assesses how the activity result contributed to the overall stage goal and what actions should be taken.
The different process models can be explained in terms of what is the relation between stages and activities.
The waterfall process model defines a one-to-one relationship between stages and activities. The stages goals are the generation of products that are used as input to the next. The stage assessment is based on the evaluation of the quality of the generated product. The communication between stages is done through the products, which reduces the number of communication channels between the teams and promotes a separation of competences.
The iterative and incremental model associates with each stage the delivery of an increment of functionality. Each stage comprises all types of activities, from business modelling to deployment. The stage evaluation consists on the acceptance by the client and the feedback received from the use of the software artefact.
Although the software architecture of a system may emerge by refactoring the functionality it is unusual to start the implementation of functionality in the absence of a design structure that is accepted by the team and guides the development. Therefore, the iterative and incremental model has a prior stage where the architecture is defined. Depending on the emphasis put on it there are several variations. Agile processes define a system metaphor which provides a common understanding of the design. Reuse-based models define, or select, an application framework that provides the structure to the application and the increments of functionality are done by extending the framework. Note that agile processes can also follow a reuse-based model when the metaphor is concretized by a set of abstract classes. Finally, it is possible to have a more explicit architectural design activity with the corresponding assessment of the systemic qualities.
The Rational unified process defines four stages: inception, elaboration, construction, and transition. The stages goal is to verify whether the project achieved a certain level of knowledge and, so, different kinds of activities may be necessary to achieve the goal. The inception stage’s goal is to verify whether the system makes sense from the business viewpoint. To do so, the most relevant activities are business modelling and requirements specification. The software architecture of the system is defined in the elaboration stage, where requirement specification, software design, and implementation activities are done to obtain the level of knowledge necessary to produce an architecture. In the construction stage the system is implemented and tested through increments of functionality and the main activities are design, implementation and test. Finally, the transition stage’s goal is to deploy the system in the clients environment and the main activities are testing and deployment.
The spiral model is a risk driven process which explicitly emphasizes risk management activities. Each stage includes risk management activities in order to increase the possibility of success. A stage is a full iteration consisting of four main activities: determine objectives, identify and resolve risks, development and test, and plan the next iteration. In each stage a software product is generated during the development and test activity. When the development and test activity sequentially produce requirements specification, system design, and implementation artifacts, the spiral model can be seen as a waterfall model enriched with risk management. The identify and resolve activities are responsible to identify the main risks of the project and define risk reduction strategies.
A large number of process models have been proposed which combine these basic models. This is actually what happens on real software development projects which combine and adapt the different models according to their needs.