Software and System Development Life-cycles

• Why learn about Systems Analysis and Design?
• Historical perspective
• The Traditional Life Cycle
• Three types of process model
The waterfall model
Exploratory programming
Prototyping
• Software development using a 4GL
• Prototyping as analysis tool  
• RAD
• Further Reading and Bibliography

• you are likely, in your future career, to find yourself involved in systems development - perhaps:
• as a worker whose job is being re-organised, or
• as part of a team involved in developing a new system or
• adapting an existing system; or
• with responsibility for specifying requirements for a new system.
• the system development lifecycles are 'process' models - they outline recognised steps for successfully completing complex tasks. You can use these steps as guidelines for completing projects at work and at home. (eg: buying a personal computer system, or doing a final year project!)

depicts the relationship between the Client (Owner of the system), the Users (the eventual operators of the system which is to be introduced) and the Application Development Team, headed by the Analyst .  Each corner of the triangle represents possibly conflicting points-of-view and different agendas in respect of the development of a new system. Theoretically (hopefully) the three parties will reach some compromise where they all have an equal say in the final system - shown by the lines meeting in the centre of the triangle.

The Systems Analyst

• investigates, analyses how information is used and the requirements of current system
• judges feasibility of computer system
• designs new system; and specifies:
• programs
• hardware
• data structures
• procedures
• HCI and training
• is responsible for:
• documentation of the project and system,
• overseeing installation,
• testing and evaluation

Historical perspective

• Costly mistakes in the development of large systems
• Problems with maintenance of existing software
• Developments in hardware;
• users/clients calling for:
• "MORE MORE MORE software"
• "Better software please."
• "Cheaper software please."
• "We want it yesterday"
(Is it any different now in the new millenium?)

The association of software production with the discipline of engineering resulted in use of engineering process models, known within the world of I.T as system development life-cycles. The traditional system development life-cycle (taken from Royce, 1970), is shown below, followed by a description of each stage.

The Traditional Life Cycle

Typically a small committee with responsibility for project budgets will decide in principle to go ahead with some project. They will usually:

• specify Terms of Reference - giving a brief outline of:
• what areas the system is to cover
• what will be included
• what will NOT be included
• propose a Feasibility Study, indicating:
• how long it will it take to produce
• who will produce it
• a deadline (ie: the date by which it is expected)

• test all units working together as system - distinct units/modules/sub-systems may work individually but may not work together!
• requires users to okay ('sign off') system

The traditional life-cycle model (TLC) has been used, and is still being used, as the basis of development process models. Somerville suggests a number of general models (or development process paradigms). Three models which are used (as opposed to being theoretically useful) are:

• The 'WATERFALL' Model
• EXPLORATORY Programming
• PROTOTYPING.

• The waterfall model of the software development process is within the same paradigm as the traditional life cycle description.
• The development process is seen as being made up of a series of distinct phases, or stages, each of which can be completed, and 'signed off'.
• Typically the completion of a stage is marked by the submission of a set of defined deliverables (outlined above in the description of the Traditional Life Cycle).
• Progress through the system is measurable and above all manageable.

A major problem with software design is the need for iteration - typically required for, and a result of, verification and validation (described in Boehm, 1981, quoted by Somerville):

• "Verification: 'Are we building the product right?'
• Validation: 'Are we building the right product?"

Some problems with exploratory programming:

• No 'real' specification so no verification is possible.
• Maintenance likely to be difficult & costly because of lack of documentation and multiplicity of changes from initial proposal.
• Because of many alterations, typically software developed in this way has an ill-defined structure .
• Typically the exploratory approach requires highly skilled practitioners.

1. an original or model after which anything is formed;
2. the first thing or being of its kind;
3. a pattern, exemplar, or archetype " (Websters 20th C.)

• get an idea of what the system will offer; and
• provide feedback on whether the system is what is required.

Advantages of prototyping stage:

• identification of misunderstandings between 'users' and software developers;
• detection of missing user services
• identification of difficult-to-use or confusing user services
• requirements validation aid (discovering inconsistencies)
• early availability of a working (limited) system
• may serve as basis for specification for a 'production quality' system

• 'users' may not give up prototype.
• prototype may become basis of implementation (but lacks safety-critical features)
• may be used as basis for contract with s/w engineer(s) eg: 'build one like this' - no legal standing.
• non-functional requirements cannot be adequately expressed
• omission of functions in prototype may mean prototype not used in same way as fully operational system
• AND may encourage inadequate problem analysis

Prototyping is seen sometimes as representing 'unacceptably large proportion of system development costs.' However, see Somerville on relative costs of corrective maintenance. For example: it "was estimated that one US Air Force system cost $30 per instruction to develop and $4000 per instruction to maintain over its lifetime" (Boehm, 1975) (It should be noted that systems typically  contain thousands, if not many hundreds of thousands, of instructions!) 

Currently, 4GLs are good tools for prototyping. The 4GL process model is almost identical to the prototyping model.

Software development using a 4GL

Prototyping as analysis tool

Advantages of using a 4GL in prototyping stage

• improved productivity in software engineering and (possible) reduction in costs;
• complete rewrites of prototype software possible allowing (possibly) a more exploratory approach; and also
• (possibly): 'user' programming;
• improved documentation;
• smaller development teams.

A new (in 1997) development strategy called Rapid Applications Development (RAD) is already being used.
RAD makes use of:

• well organised and structured group meetings which must have representatives of the Client and Users (see TheTriangle at start of this document).

The user representatives must be authorised to make decisions;
• small teams using Computer Aided Software Engineering tools (CASE). The team usually includes user representatives (or works with ready access to users.)
• 'timeboxes', generally measured in weeks rather than months, within which the teams work on and complete prioritized tasks - using a combination of the exploratory and prototyping lifecycle models.

A very good book to look at is : Software System Development - a gentle introduction, by Carol Britton and Jill Doake, McGraw-Hill, chapters 1, and 2.
Also:
Birrell, N.D. & Ould, M.A, (1986) A Practical Handbook for Software Development, C.U.P.
Fairley, R.E, (1987) Software Engineering Concepts, McGraw-Hill;
Jones, G.W. (1990) Software Engineering, John Wiley & Sons
Parkin, A. (1985) Systems Analysis, Edward Arnold
Somerville,I., (1990) Software Engineering (3rd ed.), Addison Wesley 

1. In the 60's, the phrase 'software crisis' was coined to describe the problems people were having with computers and computing. What strategies were adopted to deal with the crisis and were they successful?
2. Using diagrams to illustrate your answer, describe three models of the system development life-cycle.
3. If you were advising a chief executive on how to go about developing and introducing a new information system in a large organisation, what advice would you give on the type of system development life-cycle she should propose?
4. Who or what is a systems analyst and what does his/her job entail?
5. In this lecture a diagram showing one of the three types of process model is different from the other diagrams, in that a 'flowchart' technique is used. How would the diagram look if it were drawn using the same methodology as the other diagrams? Why do you think the 'flowchart' method was used for that particular process model?