Roger Clarke's Web-Site © Xamax Consultancy Pty Ltd,  1995-2024
HOME	eBusiness	Information Infrastructure	Dataveillance & Privacy	Identity Matters	Other Topics
What's New		Waltzing Matilda	Advanced Site-Search

The Conventional System Life-Cycle

Roger Clarke

Revision of 15 January 2000

© Xamax Consultancy Pty Ltd, 1997, 2000

This document is at http://www.rogerclarke.com/SOS/SLC.html

Introduction

The development of new applications of information technology is an expensive and risk-prone business. It is essential that the process, the product, and the resources invested, be managed responsibly. The experience of four decades of commercial software projects has resulted in a conventional approach to the management of application development, which is often referred to as the 'system life-cycle'.

The Concept of the System Life-Cycle

The term 'system life-cycle' (SLC) is used to convey that:

• the approach deals with all components of the system, i.e. including not only hardware, networking, systems software and applications software, but also the substantial amount of human activity that is involved;
• there are many review activities that check the product, the process and resource usage against plans; and
• the process is cyclical, in the sense that each version of a product becomes part of the environment within which the next version is developed.

During the last two decades, the portfolio of existing application software has become substantial. For this reason, it is now unusual to construct an application completely 'from scratch'. Instead, the development of new applications generally comprises the evaluation and acquisition of appropriate components, the construction of additional components that are unique to the application, and the integration of the acquired and constructed components into a whole.

Important elements of the SLC include phases, tasks and checkpoints:

• a Phase is a broad set of related tasks;
• a Task is a specific activity with a defined purpose; and
• a Checkpoint, also called a Milestone, or a Deliverable, is a defined outcome whose delivery signals the completion of a Phase or Task.

The Conventional System Life-Cycle

Conventionally, the SLC is divided into the following Phases:

• Project Planning. This establishes the project's purpose, scope, stakeholders, cost/benefit analysis, resourcing, and project management framework. Its Checkpoint is an agreed Terms of Reference and Project Plan;
• Requirements Analysis. This establishes 'what' the product is to do. It requires that participants adopt an enquiring, analytical frame of mind, rather than the 'synthetic', inventive or constructive approach appropriate in later Phases. Its Checkpoint is an agreed System Requirements Statement (SRS);
• System Design. This establishes 'how' the product is to perform the functions defined in the SRS. Its Checkpoint is an agreed System Design Specification. This Phase may be further broken down into:
  • Logical Design. This is largely independent of the physical environment in which the product is to run; and
  • Physical Design. This maps the Logical Design onto a physical environment, comprising specific systems software, networks and workstations;
• Construction. This involves the evaluation and acquisition of existing software, the writing of additional software, the detailed specification of manual activities, the integration of all elements into a whole, and successive layers of testing of the software. Its Checkpoint is an integrated application that has satisfied defined quality standards, including multiple levels of testing, supported by appropriate documentation;
• Implementation. This is the introduction of the service into usage by the intended clientele. Its Checkpoint is an accepted, operational service;
• Operation. This is the ongoing use of the system, and includes provision for incident reporting and work requests to deal with errors, and with changes in the system's environment and in users' needs.

Review is undertaken at the completion of all Phases, and of major Tasks; and on a periodic basis. The purposes of a review are:

• to assess progress and delays;
• to account for resource-usage;
• to explain material variances from resource-allocations and elapsed-time schedules;
• to identify any remedial action that may be necessary, to assist in the re-estimation of uncompleted Phases and Tasks;
• to assist in the planning of future Phases and Tasks; and
• (in the case of serious negative variances) to provide management with information to support a 'go/no-go' decision about continuation of the project.

The SLC is often represented using the 'waterfall' metaphor. This depicts the phases as a cascade, with control flowing down from one Phase to the next. The difference between a series of Phases and a cascade of Phases is fairly trivial. However, the metaphor can be extended to make it useful.

Comparison can be drawn between the SLC and a 'hydro-electric power scheme', which involves water being pumped back up the hill and released back down the cascade. This model allows for the possibility that the review undertaken at the end of a Phase may result in a decision that the outcomes do not meet the requirements, and that the current Phase needs to be repeated. The form of the diagram shown below allows for looping back to any earlier Phase. It also reflects the fact that post-implementation reviews may, and eventually do, result in a new project being commenced, with a view to either replacing the existing system, or to significantly augmenting it.

Some project management methods seriously short-change the Requirements Analysis Phase. These are typically based on IEEE standards, have a heavily 'software engineering' flavour, and substitute a 'Functional Design Specification' for the SRS. These approaches fail to appreciate the significance of user needs, and in effect replace the 'what'-oriented, user-focused Requirements Analysis Phase with a 'how'-oriented, technical/synthetic/constructive Conceptual Design Phase.

Studies have shown conclusively that errors made during the development of a system are much more expensive the earlier that they are made in the project; hence a mere program bug is of the order of 100 times less expensive to fix than a misunderstanding of users' needs. It is accordingly very risky to short-change the Requirements Analysis Phase and adopt a technical or software engineering approach too early in the project.

Productised project management methods are sold by many companies, in the form of binders containing documents and forms, and associated courses. Software development consultancies and contractors generally have a project management method that they prefer to apply to development contracts that they perform. These productised methods reflect various interpretations of the SLC described above. Such products are often inappropriately called 'methodologies'. That term technically refers to 'study of methods', not to a particular method; and hence it only allows for the singular, not the plural.

Advanced Considerations

Modern applications have long lives, and undergo substantial modification and enhancement. It is also common for them to be first made available in an initial version that provides sufficient functionality for users to commence gaining value, but falls short of the full set of capabilities intended. It is conventional to refer to these incremental versions as Releases. These are typically identified by Release numbers, allowing for multiple minor releases within a major release (e.g. Release 1.0 followed by 1.1), and for minor fixes and enhancements within a minor release (e.g. Release 1.1c).

In principle, Phases are undertaken serially. In practice, two factors result in them being interleaved:

• Haste. It is often necessary to expedite delivery of applications. This may arise because of real deadlines (e.g. a legal obligation), arbitrary deadlines (set so as to focus the minds of the project staff), or because of competitive pressures. Hence there is often a need to 'crash' the project schedule, i.e. commence some nominally later Tasks, or even whole Phases, before the Checkpoint for predecessor Phases and Tasks are satisfied. This requires calculated risks to be taken; and
• Scale and Complexity. The nature of contemporary applications results in them generally being developed progressively. Later Releases are commonly commenced prior to the completion of the SLC for the earlier Releases.

A further qualification to the SLC is the use of 'prototyping'. This is an experimental, iterative approach to the development of software and human processes. Prototyping is appropriate to functions that are not well-understood, e.g. because they are innovative. In extreme cases, an entire new service may be so poorly understood that it is impractical to approach it in the disciplined manner required by the SLC. The outcomes and resource-usage when a prototyping approach is adopted are largely unplannable, and it is therefore a very risky approach to adopt for structured projects. This hasn't prevented it becoming over-fashionable, being over-used, and attracting trendy names (e.g. 'rapid application development').

Despite the fact that the conventional SLC is an over-simplified model, it provides a valuable framework for project management. Importantly, it establishes the basis on which an experienced project manager can perform risk assessment, and establish a risk management strategy, such that new systems can be delivered within an acceptable time-frame, with acceptable risk-profiles.

Technologies and fashions change, sometimes briskly. During the last decade, the long-dominant 'structured' philosophy has been giving way to a descendant philosophy referred to as being 'object-oriented'. This provides greater opportunity for re-use of existing code, and hence for increased productivity (by avoiding the continual re-writing of common functions), and for increased quality (by applying pre-tested blocks of code).

The object-oriented approach has not fundamentally changed the SLC, but has resulted in some modifications to the approach, and some changes to the terminology used.

Personalia

Photographs Presentations Videos

Access Statistics

The content and infrastructure for these community service pages are provided by Roger Clarke through his consultancy company, Xamax. From the site's beginnings in August 1994 until February 2009, the infrastructure was provided by the Australian National University. During that time, the site accumulated close to 30 million hits. It passed 65 million in early 2021. Sponsored by the Gallery, Bunhybee Grasslands, the extended Clarke Family, Knights of the Spatchcock and their drummer

Xamax Consultancy Pty Ltd ACN: 002 360 456 78 Sidaway St, Chapman ACT 2611 AUSTRALIA Tel: +61 2 6288 6916

Created: 26 August 1997 - Last Amended: 15 January 2000 by Roger Clarke - Site Last Verified: 15 February 2009
This document is at www.rogerclarke.com/SOS/SLC.html
Mail to Webmaster   -    © Xamax Consultancy Pty Ltd, 1995-2022   -    Privacy Policy