The traditional Systems Life Cycle.
The traditional Systems Life Cycle is the oldest method for building information systems. This methodology assumes that an information system has a life cycle similar to that of any living organism, with a BEGINNING > MIDDLE > END.The Systems Life Cycle methodology has six stages. It partitions the system development process into distinct stages and develops an information system sequentially, stage by stage. The six stages and a detail definition of each are as follows:Stage 1 - Project DefinitionDetermines whether the organization has a problem and whether that problem can be solved by building a new information system. The following questions are answered: Why do we need a new system project? What do we want to accomplish? If a project is called for, the project definition stage identifies general objectives, specifies the scope of the project and develops a project plan that can be shown to management.Stage 2 - Systems StudyThis stage analyzes the problems of the existing system (manual or automated) in detail, identifies objectives to be attained by a solution to these problems, and describes alternative solutions. The systems study phase examines the feasibility of each solution alternative for review by management. The following questions are answered: What do the existing systems do? What are their
strengths, weaknesses, trouble spots, and problems? What should a new or modified system do to solve these problems? What user information requirements must be met by the solution? What alternative solution options are feasible? What are their costs and benefits?Answering these questions requires extensive information gathering and research; sifting through documents, reports, and work papers produced by existing systems; observing how these systems work; polling users with questionnaires; and conducting interviews. All of the information gathered during the system study phase will be used to determine information system requirements. The systems study stage describes in detail the remaining life cycle ...
This is a preview of the whole essay
strengths, weaknesses, trouble spots, and problems? What should a new or modified system do to solve these problems? What user information requirements must be met by the solution? What alternative solution options are feasible? What are their costs and benefits?Answering these questions requires extensive information gathering and research; sifting through documents, reports, and work papers produced by existing systems; observing how these systems work; polling users with questionnaires; and conducting interviews. All of the information gathered during the system study phase will be used to determine information system requirements. The systems study stage describes in detail the remaining life cycle activities and the tasks for each phase.Stage 3 - DesignThis stage produces the logical and physical design specifications for the solution. Design and documentation tools (flow diagrams, structure charts, system flowcharts, etc.) are used to develop formal specifications.Stage 4 - ProgrammingThis stage translates the design specifications produced during the design stage into software program code. Specifications are prepared for each program in the system which describes what each program will do, the type of programming language to be used, inputs, outputs, processing logic, processing schedules, and control statements . Customized program code is written generally using a 3rd or 4th generation programming language.Stage 5 - InstallationConsists of the final steps to put the new or modified system into operation: testing, training, and conversion. The software is tested to ensure that it performs properly from both a technical and a functional business standpoint. A formal conversion plan provides a detailed schedule of all the activities required to install the new system, and the old system is converted to the new one.Stage 6 - Post ImplementationConsists of using and evaluating the system after it is installed and is in production. It also includes updating the system to make improvements. A formal post-implementation audit is done to determine how well the new system has met its original objectives and whether any revisions or modifications are required. After the system has been fine tuned, it will need to be maintained while it is in production to correct errors, meet requirements, or improve processing efficiency.Division of LaborThis methodology has a formal division of labor between end users and information systems specialists. Technical specialists such as systems analysts and programmers are responsible for systems analysis, design and implementation work; End-users are limited to providing information requirements and reviewing the work of the technical staff.Outputs and SignoffA product or output is produced at each stage of the life cycle and is the basis for sign-off agreements. The product or output for the six stages are as follows: STAGE (Output or Product) 1. Project Definition (Project proposal report) 2. Systems Study (System proposal report) 3. Design (Design specifications 4. Programming (Software code) 5. Installation (System performance tests) 6. Post Implementation (Post implementation audit)Suitability and LimitationsThe Systems Life Cycle methodology is usually used for building large transaction processing systems (TPNS) and management information systems (MIS) where requirements are highly structured and well-defined. It also remains appropriate for complex technical systems requiring rigorous and formal requirements analysis, predefined specifications, and tight controls over the systems-building process (space launches, air traffic control, and refinery operations). This methodology has serious limitations and is not well suited for most of the small desktop systems that dominate during the 1990s and beyond.Resource IntensiveThis methodology is resource intensive in that a tremendous amount of time must be spent gathering information and preparing specifications and sign-off documents. It may take years before a system is finally installed. If development time is too prolonged, the information requirements may change before the system is operational. The system that takes many years and dollars to build may be obsolete while it is still on the drawing board.Inflexible and Inhibits ChangeThis methodology does not allow for revisions to the system to ensure that requirements are met. Whenever requirements are incorrect, or an error is encountered, the sequence of life cycle activities can be repeated. This may cause the generation of volumes of additional documents and substantially increase development time and costs. Because of the time and cost to repeat the sequence of life cycle activities, the methodology encourages freezing of specifications early in the development process. This means that changes cannot be made. Once users approve specification documents, the specifications are frozen. Because users sometimes have a problem visualizing a final system from the specification documents, it is common for them to sign-off on them without fully comprehending their contents. They sometimes learn during programming and testing that the specifications are incomplete or not what they had in mind. Proper specifications cannot always be captured the first time around, early enough in the life cycle when they are easy to change.Suited to Decision-Oriented ApplicationsDecision making can be rather unstructured and fluid. Requirements constantly change or decisions may have no well-defined models or procedures. Decision makers often cannot specify their information needs in advance. This high-level of uncertainty cannot be easily accommodated by this methodology.
