Augustana University College


Software Engineering and Human-Computer Interfaces

The Software Life Cycle

Software Life Cycle Models

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).

IEEE 1074 Standard for Developing Life Cycle Processes

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.

Software Processes and Process Groups in IEEE 1074
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
Post-development Installation
Operation and Support
Integral Processes Verification and Validation
Software Configuration Management
Documentation Development

A summary of the activities and work products of each process group follows.

Life Cycle Modeling

The project manager customizes the selection and sequencing of the activities required for a particular project

Project Management

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).

Integral (Cross-Development) Processes

Some processes (in addition to project management) take place during the complete lifetime of the project. Two of these processes require definition:

Life Cycle Models

A variety of life cycle models have been proposed, most of which focus exclusively on the development processes.

Code and Fix

A simple and widely used software life cycle model: Repeat the following steps until the solution is good enough.

  1. Code
  2. Compile and execute
  3. Detect errors
  4. Fix

Waterfall Model

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.

Spiral Model

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):

  1. Determine objectives: product definition, determination of business objects, specification of constraints, generation of alternatives
  2. Evaluate alternatives: risk analysis, prototyping
  3. Develop product: detailed design, code, unit test, integration
  4. Plan next cycle: customer evaluation, design planning, implementation, customer delivery

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).

Prototyping -- the Sawtooth and Shark Tooth Models

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:

  1. a revolutionary prototype is an illustrative model of the system, representing only a small fraction of the required functionality
  2. an evolutionary prototype, shown late in the development process, is based on a completed design and implements some of the required functionality

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 and the Time Box Model

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.

Iterative and Incremental Development

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:

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

Entity-Based Models
Issue-Based Life Cycle Model

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.

Workbook-Centered Development

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.

Capability Maturity Model

The Software Engineering Institute (SEI) has defined five levels to characterize the maturity of a software development organization:

  1. Initial -- ad hoc activities; dependence on the heroic efforts and skills of key individuals.
  2. Repeatable -- each project has a well-defined software life cycle, but different models are used for different projects; success is predictable for similar projects.
  3. Defined -- uses a documented model for all activities; model is customized at the beginning of each project.
  4. Managed -- metrics are defined for activities and deliverables; data is collected during the project to quantify progress
  5. Optimized -- measurement data are used to improve the model.

Other Resources

. Software Development Lifecycles

. Software Process Models by Colin Potts, Georgia Tech


1 The Unified Software Development Process (Addison Wesley, 1999).