The information systems life cycle
- 1. The Information Systems Life Cycle
- 2. Overview of Systems Life Cycle • Goals must be thoroughly understood • Formal procedures and methods ensure: ▫ On-time delivery to required specification • Methodology ▫ Sequential ▫ Each stage well-defined ▫ Developed in 60s and 70s to suit transaction-processing systems
- 4. The waterfall model F e a s ib ility s tu d y A n a ly s is R e q u ir e m e n ts A n a ly s is D e s ig n D e s ig n C o d in g a n d te s tin g Im p le m e n ta tio n C o n v e r s io n R e v ie w a n d M a in te n a n c e P o s tim p le m e n ta tio n r e v ie w
- 5. The waterfall model • Shows developers may have to re-think and re-work some stages • Project milestones ▫ Terminate each stage ▫ Work is ‘signed-off’ ▫ Approval required to proceed to next stage • End-user not involved in developmental process ▫ This requires very accurate statement of requirements ▫ This is a major drawback
- 6. What prompts a new system? • The current system may no longer be suitable for its purpose • Technological developments may have made the current system redundant or outdated • The current system may be too inflexible or expensive to maintain
- 7. Feasibility study (TELOS) • Technical feasibility ▫ does the technology exist to implement the proposed system, or is it a practical proposition? • Economic feasibility ▫ is proposed system cost-effective – if benefits do not outweigh costs, it’s not worth going ahead. • Legal feasibility ▫ Is there any conflict between the proposed system and legal requirements – e.g. the Data Protection Act? • Operational feasibility ▫ are the current work practices and procedures adequate to support the new system? • Schedule feasibility ▫ how long will the system take to develop, or can it be done in a desired time-frame?
- 8. Requirements analysis Gathering details about the current system will involve: ▫ Interviewing staff at different levels from end-users to senior management ▫ Examining current business and systems documents and output may include current order documents, computer systems procedures and reports used by operations and senior management ▫ Sending out questionnaires the questions have to be carefully constructed to elicit unambiguous answers ▫ Observation of current procedures by spending time in various departments. A time and motion study can show where procedures could be more efficient, or to detect bottlenecks
- 9. Requirements analysis (cont.) Systems analyst’s report will: ▫ Examine data and information flows in the organisation May use data flow diagrams ▫ Establish what the proposed system will actually do (not how it will do it) ▫ Analyse costs and benefits ▫ Outline system implementation options (e.g. in-house or using consultants) ▫ Consider possible hardware configurations ▫ Make a recommendation
- 10. System design specifies the following aspects of a system: ▫ The hardware platform - which type of computer, network capabilities, input, storage and output devices ▫ The software - programming language, package or database ▫ The outputs - report layouts and screen designs ▫ The inputs - documents, screen layouts, validation procedures ▫ The user interface - how users will interact with the computer system ▫ The modular design - of each program in the application ▫ The test plan and test data ▫ Conversion plan - how the new system is to be implemented ▫ Documentation - including systems and operations documentation. Later, a user manual will be produced
- 11. Implementation • Coding and testing of the system • Acquisition of hardware and software • EITHER ▫ Installation of the new system OR ▫ Conversion of the old system to the new one
- 12. Installation This can include ▫ Installing the new hardware, which may involve extensive recabling and changes in office layouts ▫ Training the users on the new system ▫ Conversion of master files to the new system, or creation of new master files.
- 13. Methods of conversion • Direct changeover ▫ The user stops using the old system one day and starts using the new system the next — usually over a weekend or during a slack period • Parallel conversion ▫ The old system continues alongside the new system for a few weeks or months • Phased conversion ▫ Used with larger systems that can be broken down into individual modules that can be implemented separately at different times • Pilot conversion ▫ New system will first be used by only a portion of the organisation, for example at one branch or factory
- 14. Post-implementation review • Review may result in: ▫ ▫ ▫ ▫ Some programming amendments Adjustment of clerical procedures Modification of some reports Request for new programs
- 15. System maintenance • Perfective maintenance ▫ This implies that while the system runs satisfactorily, there is still room for improvement. • Adaptive maintenance ▫ All systems will need to adapt to changing needs within a company. • Corrective maintenance ▫ Problems frequently surface after a system has been in use for a short time, however thoroughly it was tested. Any errors must be corrected.
- 16. Prototyping • The waterfall model of the system life cycle doesn’t allow for modifications to the design. E s ta b lis h a n o u tlin e s p e c ific a tio n D e v e lo p a p ro to ty p e E v a lu a te S p e c ify D e s ig n a n d im p le m e n t s y s te m
- 17. Benefits of prototyping • Misunderstandings between software developers and users can be identified • Missing functions may be detected • Incomplete or inconsistent user requirements may be detected • A prototype version will be quickly available to demonstrate the feasibility to management • The prototype can sometimes be used for training before the final system is delivered
- 18. Varieties of prototyping • Piloting ▫ Using a prototype to test feasibility • Modelling ▫ To develop an understanding of user requirements • Throw-away prototyping ▫ Discarded after evaluation and then real system is built • Evolutionary prototyping ▫ Each prototype takes a step towards the final solution