Concept: Life Cycle Model

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:

Create a custom SLCM for you project
Tailor an existing SLCM
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:

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

A SLCM achieves this by:

Providing a simple graphical representation of the work to be performed
Allowing focus on important features of the work, downplaying excessive detail
Providing a standard work unit hierarchy for progressive decomposition of the work into manageable chunks
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.

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
Prior tasks complete Prior deliverables approved and baselined Tasks defined for this work unit Deliverables defined for this work unit Resources available Responsibilities defined Procedures defined Process measurements defined Work authorized	Produce deliverable Interview user Conduct review Conduct test Conduct technical investigation Perform rework	Deliverable complete Deliverable approved Test passed Acceptance criteria satisfied 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:

A procedure to raise issues or defects with baselined deliverables.
A procedure to review issues and approve rework of baselined deliverables.
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 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.

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