The software life cycle is a general model of the software development process, including all the activities and work products required to develop a software system. A software life cycle model is a particular abstraction representing a software life cycle. Such a model may be:
These are complementary views: activities produce work products.
A software life cycle model is often referred to as a software development life cycle (SDLC).
The IEEE standard 1074 seeks to establish a common framework for developing life cycle models. It describes the activities and processes needed for the development and maintenance of software, and provides examples for typical situations.
The standard divides the set of activities into processes, and processes into process groups.
| Process Group | Processes |
|---|---|
| Life Cycle Modeling | Selection of a Life Cycle Model |
| Project Management | Project Initiation Project Monitoring and Control Software Quality Management |
| Pre-development | Concept Exploration System Allocation |
| Development | Requirements Design Implementation |
| Post-development | Installation Operation and Support Maintenance Retirement |
| Integral Processes | Verification and Validation Software Configuration Management Documentation Development Training |
A summary of the activities and work products of each process group follows.
The project manager customizes the selection and sequencing of the activities required for a particular project
The project manager initiates, monitors and controls the project throughout the software life cycle.
The project management plan is documented in the Software Project Management Plan (SPMP) during the Project Initiation process, and the plan is updated to reflect changes throughout the project.
Management and the client identify an idea or need, and the manager establishes the initial system architecture. The need may addressed through:
A Problem Statement or Statement of Need (IEEE 1074) describes the business requirements to be addressed by the project. Most authors say that the problem statement should not discuss design and implementation topics, but your textbook suggests that subsystem decomposition and communication infrastructure be included.
The development process per se includes all the process directly involved in the construction of the system.
After the software product is developed, it must be installed, maintained, and given operational support, and an existing system may need to be retired (terminated).
Some processes (in addition to project management) take place during the complete lifetime of the project. Two of these processes require definition:
A variety of life cycle models have been proposed, most of which focus exclusively on the development processes.
A simple and widely used software life cycle model: Repeat the following steps until the solution is good enough.
The waterfall model prescribes a sequential execution of a set of development and management processes, with no return to an earlier activity once it is completed. Some variants of the waterfall model allow revisiting the immediately preceding activity ("feedback loops") if inconsistencies or new problems are encountered during the current activity.
Another variant of the waterfall model -- the V-model -- associates each development activity with a test or validation at the same level of abstraction. Each development activity builds a more detailed model of the system than the one before it, and each validation tests a higher abstraction than its predecessor.
Barry Boehm devised the spiral model to address the weaknesses of the waterfall model, especially its lack of resilience in the face of change. The spiral model focuses on addressing risks incrementally by repeating the waterfall model in a series of cycles or rounds:
Each round consists of four phases (as illustrated in this figure):
The spiral model is an improvement on the waterfall model, as it provides for multiple builds and provides several opportunities for customer involvement. However, it is elaborate, difficult to manage, and does not keep all workers occupied during all phases.
Boehm subsequently proposed a modified version of the spiral model -- the WinWin spiral model -- which adds activities to the start of each cycle to identify the key stakeholders and their "win" conditions. See Using the Win-Win Spiral Model: A Case Study by Boehm et al. (PDF format) and Anchoring the Software Process by Boehm (PostScript).
As a software product is being developed, the developers' view of the system diverges from the client's view, since the developer's focus on design and implementation while the client remains focused on requirements.
The sawtooth model provides checkpoints during the development process in order to check that development is proceeding in a direction that will eventually meet the client's requirements. Typically, the checkpoints involve demonstrating a prototype to the client. For example, two prototypes may be developed:
The shark tooth model adds management reviews and demonstrations to the sawtooth model. Since these may be seen to be at an intermediate level of abstraction, a diagram of the model includes large "teeth" and small "teeth".
Rapid application development (RAD) is an approach rather than a model. Its proponents view formal life cycle models as inherently inefficient, due to the large amount of documentation and the number of reviews required. The formality of such models is seen as interfering with customer communication.
Instead, RAD focuses on developing a sequence of evolutionary prototypes which are reviewed with the customer, both to ensure that the system is developing toward the user's requirements and to discover further requirements.
The process is controlled by restricting the development of each integration to a well-defined period of time, called a time box. Each time box includes analysis, design, and implementation of a prototype.
One problem with RAD is reaching closure -- the customer always has feedback, and the developers and the customer may never agree that the project is done.
Reference: Murray R. Cantor, Object-Oriented Project Management with UML (Wiley, 1998), pp.96--98 [QA 76.9 O35 C36 1998]
Synch-and-stabilize is Microsoft's attempt to scale-up a loosely structured small-team ("hacker") style of product development.
The process is also called a "milestone", "daily build", "nightly build", and "zero-defect" process.
The overall strategy is to quickly introduce products that are "good enough" to capture a mass market, then improve the product, selling multiple product versions and upgrades.
Read "How Microsoft Builds Software" by Michael A. Cusumano and Richard W. Selby (Communications of the ACM, Vol. 40, No. 6 [June 1997], pp. 53-61) in the reading packet.
The Unified Process is an example of an iterative software development process. Its designers -- Ivar Jacobson, Grady Booch, and James Rumbaugh -- characterize the process [1] as:
The use cases drive the development process: developers create design and implementation models to realize the use cases, and testers test the implementation to ensure that the use cases are correctly implemented.
The architect selects the use cases which represent the key functions of the system (5% to 10% of all the use cases), specifies them in detail, and realizes them in terms of subsystems, classes, and components.
For a presentation of this process which distinguishes between the management and the technical
views of the process, see
A Rational Development Process
by
Philippe Kruchten, Rational Software Corp.
For a list of software engineering "best practices" and details regarding major milestones and workflows, see also
Rational Unified Process: Best Practices for Software Development Teams
For more details about the phases of the Unified process, see
A Rational Approach to Software Development Using Rational Rose 4.0
Bruegge and Dutoit present (textbook, pp. 483--485) an issue-based life cycle model, in which the project is driven by a set of issues such as "How do we set up the initial teams?" and "What software architecture shall we use?" Issues are classified as open or closed, but closed issues can be reopened as changes occur in the application or solution domain. Issues are maintained in an issue base accessible to all project participants.
Issues do not directly correspond to risks, as some issues are design problems, not risks.
The management problem in issue-based development is to keep the number of open issues small and manageable. By organizing the project around issues, all life cycle activities may proceed concurrently, using dependencies between issues to determine which activities can be performed concurrently and what the impact of reopening an issue will be.
IBM's Object-Oriented Technology Center uses an iterative and incremental process, but organizes it around work products -- documents, models, and software -- and uses a structured workbook to ensure that the work products are available and organized for access by the entire project. Work products are seen as the primary means of project communication.
The Software Engineering Institute (SEI) has defined five levels to characterize the maturity of a software development organization:
Software Development Lifecycles
Software Process Models by Colin Potts, Georgia Tech
1 The Unified Software Development Process (Addison Wesley, 1999).
