Pert NetConcept: Life Cycle Model


  1. Introduction
  2. Definition
  3. Classifying Life Cycle Processes
  4. Describing a Process
  5. Sequencing Work Units
  6. Phases, Activities and Tasks
  7. Example
  8. Further Reading

1. Introduction

This page discusses the concepts behind the design of software life cycle models (SLCMs). It provides you with the basic building blocks of a model and gives examples of their use. Armed with this information you can:

  1. Create a custom SLCM for you project
  2. Tailor an existing SLCM
  3. Evaluate a SLCM

2. Definition

A software life cycle model (SLCM) is a representation of the major components of software development work and their interrelationships in a graphical framework that can be easily understood and communicated. Just as the WBS partitions the deliverable into its component parts so the SLCM apportions the work to be done into manageable work units.

You must have a defined SLCM for your project to:

  1. Define the work to be performed
  2. Divide up the work into manageable pieces
  3. Determine project milestones at which project performance can be evaluated
  4. Define the sequence of work units
  5. Provide a framework for definition and storage of the deliverables produced by the project
  6. Communicate your development strategy to project stakeholders

A SLCM achieves this by:

  1. Providing a simple graphical representation of the work to be performed
  2. Allowing focus on important features of the work, downplaying excessive detail
  3. Providing a standard work unit hierarchy for progressive decomposition of the work into manageable chunks
  4. Providing for changes (tailoring) at low cost

3. Classifying Life Cycle Processes

In planning software development you need to consider the complete exercise as a process. To effectively manage it you need to break it up into component subprocesses. Figure 107.1. presents the 3 main classes of software development process and gives examples of the members of each class.

Figure 107.1. Software life cycle process classifications.

Life cycle process classifications

Project Support Processes are involved with the management of the software development exercise. They are performed throughout the life of the project.

Development Processes embody all work that directly contributes to the development of the project deliverable. They are typically interdependent.

Integral processes are common processes that are performed in the context of more than one development activity. For example, the review process is performed in the context of requirements definition, design and coding.

4. Describing a Process

Processes are described in terms of a series of work units. Work units are logically related chunks of work. For example, all preliminary design effort is naturally chunked together. Figure 107.2 describes the components of a work unit.

Figure 107.2. Components of a work unit.
Components of a work unit
A work unit is described in terms of:

Work Flow Input/Output. Work flows are the work products that flow from one work unit to the next. For example, in figure 107.1 the design specification flows from the output of the design work unit to the input of the code work unit. Work flows are the deliverables from the work unit. All work units must have a deliverable. The life cycle model should provide detailed descriptions of the format and content of all deliverables.

Entry criteria are the conditions that must exist before a work unit can commence.

Statement of work (SOW). The SOW describes the work to be performed on the work flow inputs to create the outputs.

Exit criteria. The conditions that must exist for the work to be deemed complete.

Table 107.1. Examples of entry and exit criteria and statements of work.

Entry Criteria Statement of Work Exit Criteria
  1. Prior tasks complete
  2. Prior deliverables approved and baselined
  3. Tasks defined for this work unit
  4. Deliverables defined for this work unit
  5. Resources available
  6. Responsibilities defined
  7. Procedures defined
  8. Process measurements defined
  9. Work authorized
  1. Produce deliverable
  2. Interview user
  3. Conduct review
  4. Conduct test
  5. Conduct technical investigation
  6. Perform rework
  1. Deliverable complete
  2. Deliverable approved
  3. Test passed
  4. Acceptance criteria satisfied
  5. Milestone reached

Feedback paths are the paths by which work performed in one work unit impacts work either in progress of completed in a preceding work unit.

A code - design feedback path
For example the model depicted in figure 107.3 allows for the common situation where the act of coding often uncovers inconsistencies and omissions in the design. The issues raised by programmers then require rework of the baselined design document.

Defining feedback paths provides a mechanism for iterative development of work products. That is, it allows for the real world fact that specifications and code are seldom complete and correct at their first approval point. The feedback path allows for planning, quantification and control of the rework effort.

Implementing feedback paths on your project requires the following procedures:

  1. A procedure to raise issues or defects with baselined deliverables.
  2. A procedure to review issues and approve rework of baselined deliverables.
  3. Allocation of budget for rework in each project phase.

5. Sequencing Work Units

Figure 107.4 provides an example of a life cycle model constructed by sequencing work units.

Figure 107.4. Life cycle model.
Project Model

In figure 107.4 examples of work flows are requirements specification and design specification. The work units are Design, Code and Test and the feedback paths carry requirements, design and coding issues.

Note that the arrows in a life cycle model do not signify precedence. For example, in figure 107.4 all design does not have to be complete for coding to commence. Design may be continuing while some unrelated elements of the system are being coded.

6. Phases, Activities and Tasks

A primary purpose of the life cycle model is to communicate the work to be done among human beings. Research has shown that humans have a problem dealing with more than 9 chunks of information at one time (refer to George A. Miller's concept of a "chunking limit"). To guarantee comprehension, a single life cycle model should therefore not have more that 9 work units. Clearly this would not be enough to describe even the simplest projects.

Work unit decompositionWork Unit Leveling
The solution is to decompose large work units with a set of levels with each level providing more detail about the level above it. Figure 107.5 depicts 3 levels of decomposition.

  1. The Phase Level. Phases describe the highest levels of activity in the project. For example, requirements capture and design. Phases are typically used in the description of development processes.
  2. The Activity Level. Activities are logically related work units within a phase. They are typically worked on by a team. For example, interview users is a requirements capture activity.
  3. The Task Level. Tasks are components of an activity that are typically performed by one or two people. For example, conduct purchasing manager interview is a specific task that is a component of the interview users activity. Tasks are where the work is done. A task will have time booked to it on a time sheet. A single task should be completed in an average elapsed time of 5 working days. Its duration should not exceed 15 working days.

Note that phases, activities and tasks are all types of work unit. You can therefore describe them all in terms of entry criteria, statement of work and exit criteria.

7. Example

Figure 107.6 provides a phase level life cycle model for a software development project.

Figure 107.6. A generic project model.
A generic project model

8. Further Reading

[19] IEEE Standard for Developing Software Life Cycle Processes.

[20] Controlling Software Projects, Tom DeMarco. Refer chapter 13.

[2] Managing the Software Process, Watts Humphrey. Refer chapter 13.

[21] ISO/IEC 12207:1995 Information technology -- Software life cycle processes

Software Engineering Web
1997 Chambers & Associates Pty Ltd
Module: 107 v1.0 c_pmodel.htm
Updated: July 02, 2006