Roger Clarke's Web-Site

 

© Xamax Consultancy Pty Ltd,  1995-2017


Roger Clarke's Conventional SLC

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:

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:


The Conventional System Life-Cycle

Conventionally, the SLC is divided into the following Phases:

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

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:

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.



xamaxsmall.gif missing
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 50 million in early 2015.

Sponsored by 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-2017   -    Privacy Policy