I actually wrote this back in 2002 as part of a HNC in Software Engineering and Computing, but it’s still useful, so I’ll add it here 🙂
Systems Analysis : Systems Life Cycles
- Systems Life Cycles
- Key elements in the prototyping approach
- Critical appraisal of Systems Analysis Techniques
Systems Life Cycles
Using SSADM4, the Systems life cycle will follow the main phases given below, though depending on the nature of the
project in question some of these sections may not be required.
Information systems planning
Acknowledging the importance of information systems to a business, the first step is to realise improvements can always be made planning an exercise to analyse an organisations present position and look at ways to improve upon it.
At this stage the project is set up, terms of reference agreed and initial plans are drawn up.
Having set the parameters it must be decided whether the project is in fact feasible:
Is it technically possible?
Are there moral, legal or social constraints that would render the model untenable?
Will the result be financially viable or beneficial to the organisation?
Will the proposed changes be acceptable by those it affects, who must work with it?
Are there “in-house” differences of opinion that would negatively influence the proposals?
The current environment is analysed in great detail to determine the needs and requirements and requirements for a new process. The first stage is concerned with interviews and data collection relating to the existing method and using this for the second stage to outline the broad specification for new systems design options.
Business systems design
At this phase of the process various technical solutions that have been offered are evaluated and the best fitting scenario selected. That done a detailed logical design is developed to show clearly the benefits of the chosen system and how it will operate within the business.
The business systems design actually has four distinct stages, these being:
Stage 2 – Business Systems Options (as envisaged by thorough systems analysis)
Stage 3 – Definition of requirements
Stage 4 – Technical systems options
Stage 5 – Logical design
Stage 6 is the final stage of the full SSADM where the logistical design is converted to one that fits the hardware and software selected.* It involves the profile and make-up for any database or files, specification for programs and detailed operating and manual procedures that support the new system.
*(This assumes that this is the best solution to improve the process and an alternative non IT based process has not been proposed).
The construction is concerned with the assembly and testing of programs into a system as clearly laid out by the systems analysts in stages 4 through 6.
The transition stage deals with moving over from the old (possibly paper based) system, to the newly constructed process. In involves the actual installation of any new equipment and training users for the new process. This can be a clean move, changing overnight, but it is common for the two systems to run simultaneously for a time before the new systems takes over.
At this point, SSADM has completed its work and is not actively supported. The business model has fully moved over to the developed system.
Maintenance and review
Once running through its production phase it will be monitored:
Are there any errors or bugs?
Does the system needs adapting somehow?
Is new equipment or software required?
Has it met the set requirements?
Ultimately this leads to a cyclic process with the system being fully analysed and improved again.
Key elements in the prototyping approach
Prototyping is a method of developing a simple working system and refining it though a number of iterations. Often it involves in-house programming using 4GL’s and is targeted at just one part of the business system rather than the whole process.
Prototyping has five basic stages:
- In the first step the systems basic needs are established.
- Next a working model of the process is developed, covering the bare essential needs.
- The prototyped the system is monitored to see how the users find it and if they have any suggestions for improvements themselves.
- Once necessary changes have been established these are implemented in the model, this process continuing until the final version meets all the requirements.
- Finally, having established the needs a decision is made to either discard the prototype and begin a formal systems design or (less often) accept the prototype as the new production systems.
Critical appraisal of Systems Analysis Techniques
The underlying assumption is that the users do not know what they want, or if they do are not clearly defining their requirements. Thus using the prototype approach the user can see the system develop and recommend suitable modifications over time, thus ensuring the process takes the desired shape.
Prototyping is primarily used to develop business functions which have not previously been computerised and is invariably targeted at specific areas within the business.
There are a number of reasons to use or begin with prototyping. To begin with it helps avoid incorrect specifications which can prove costly to correct. It also provides common reference points for both users and analysts to identify potential problems and plan for them. Another benefit can be that because the end users are actively involved they tend to view the changes more favourably are thus are less resistant to changes in the system.
Against this approach is the time factor. Using a database as an example, the initial program can be designed in a matter of hours, but as it develops in complexity it takes ever longer to make even small changes and keep the integrity of the system. Users often don’t see this factor, focusing only on the few hours it took for the first version.
Another factor against it can be that even fully development, it may prove ineffective as it must also tie in with the other processes in the business model.
Many systems analysts consider prototyping as a useful tool towards defining the part of the picture in the early stages rather than as a viable working model.
Full systems analysis looks at the working process as a whole and may take many months looking at the existing method, interviewing staff and examining forms and data models just beginning to formulate concrete plans. Once formulated, various other stages must be completed before the process reaches the production stage. In its favour is that it should be highly focused on the actual needs of the business with the end result being a more effective system which can be further refined and enhanced over time.
Against structured analysis it can be very expensive, perhaps needing years to realise the cost benefits. Added to this unless they are properly advised and consulted end users can have misgivings and resentment to the intrusions and to the changes of the new system. Finally, if the newly implemented business system proves unviable correcting it can be very costly, perhaps ruinously so and can engender deep resentment towards any further changes.
Higher National Computing: Core units for BTEC Higher Nationals in Computing and IT
By Bruce Hellingsworth, Patrick Hall and Howard Anderson, © 2001
Butterworth-Heineman: ISBN 0-7506-5230-6
SSADM Version 4: A practical approach
By Mike Goodland with Caroline Slater, © 1995
McGraw-Hill: ISBN 0-07-709073-X
SSADM Version 4: A user’s guide
By Malcolm Eva
© 1992 McGraw-Hill: ISBN 0-07-707409-2
Introducing Systems Analysis
By Steve Skidmore, © 1994
Blackwell Publishers: ISBN 1-85554-231-5
Letts Revise A2 Computing
By Roger Legg
Letts Educational: ISBN 1-85805-910-0
Information Systems – Strategy to Design
By Chris Clare and Gordon Stuteley, © 1995
International Thomson Computer Press: ISBN 1-85032-259-7
By John Bingham and Garth Davies, © 1972, 1978, 1992* (*Professional Masters edition)
Macmillan Press Limited: ISBN 0-333-56984-9
Information Systems Development – A Database approach (Second Edition)
By D.E. Avison
Blackwell Scientific Publications Limited: ISBN 0-632-03028-3