In this term paper we will discuss about the four fundamental phases of System Development Life Cycle [SDLC] which have often been enlarged by different experts to highlight different aspects of the System Development laying stress on different phases from specific viewpoint.
Term Paper on System Development Life Cycle
Term Paper # 1. System Analysis Phase:
System Analysis, which is the first phase of the System Development Life Cycle, can be defined as the process of analyzing and identifying a problem with the objective of finding out a better way of doing it, which would result in higher throughput and or shorter response time — the benefits expected to be derived being much more than the expenses involved in the total project.
ADVERTISEMENTS:
Its four different sub-phases are:
SSDS:
i. Survey,
ii. Study,
ADVERTISEMENTS:
iii. Define, and
iv. Selection.
i. Survey:
It is the stage of fact finding where a preliminary investigation is carried out to find out whether it is worth taking up the study. Naturally, the decision is made on the basis of a rough cost-benefit analysis; which roughly quantifies what will be the cost involved in the process of computerization and what will be the benefit derived out of it.
ADVERTISEMENTS:
The output of this survey is a report called Feasibility Study, which is considered by the user organisation to decide whether further resources will be committed for the other phases of the study to get the proposed improvements.
The survey is carried out by having broad discussion with the persons concerned to get a feel of what the present system is and what the future expectations are. The relevant sample documents are also collected.
The survey has to find out:
1. Who are the persons directly and indirectly affected by the system — the users.
ADVERTISEMENTS:
2. What are the goals and objectives of the business organisation?
3. What are the data inputs to the system — the sources, volume, and timings.
4. What are the current outputs — the volume, timings, and which are the functions affected by it.
5. What different transaction are carried out within the system.
ADVERTISEMENTS:
6. What are the bottle-necks and what causes them.
7. What are the constraints under which the new system has to operate.
8. What are the suggestions for improvement from users, if any.
9. What will roughly be the expenditure to develop the system and the time required,
10. What are the benefits which could possibly be available from the new system, quantified in terms of money.
Taking all these factors into account, a Feasibility Study Report is prepared where the findings of the survey and the recommendations are given, as well as, the roughly estimated cost-benefit analysis. In the Feasibility Study, no commitments are given about the actual cost-benefit, the solutions or their alternatives, because that calls for detailed investigation which is carried out at the next sub-phase.
ii. Study:
Under this sub-phase, once the project is approved, detailed investigations and analysis are carried out in the areas, where these were briefly carried out in the survey stage. Here the objective is to learn the operations of the present system with a view to find out a feasible solution in terms of the requirements of the user.
The study conducts an in-depth fact finding using different techniques and tools and these findings are verified or cross-checked. The study now goes deep into the problem, where symptoms were noted at the survey stage and identifies the limitations and constraints affecting performance. A cause-and-effect analysis is carried out in each problem area of the system.
It may so happen that by the detailed analysis carried out, the system is found to be more complex than it was initially thought at the survey stage. This would call for revision of the scope of the study. Moreover, a some what detailed cost-benefit analysis is possible at this stage, so the original one is updated. The document prepared after the study stage is called Problem Statement, which is made available to the user with all the findings. It also includes an outline of the solution proposed in broad perspective.
iii. Definition:
The objective of the definition phase is to specify what would be the desired output of the proposed system, without bothering about how it would be done, the black box approach. Naturally, the requirements have to be finalized in consultation with the users, who has to approve it. While discussing the requirements with the users, it is always better to ask about each need specified, why it is required.
In this phase, the attention shifts from the present system to the proposed system — the present system providing the background. The outputs required must be quantified, because inter alia, ultimately the performance of the new system will be evaluated in terms of these standards.
It is better to rank the objectives in terms of priority and importance while outlining the requirements of the proposed system; modeling is usually done to present the requirements to the users for better understanding.
The type of the processes to be done manually and those to be done using computers have also to be finalized. The document prepared at the end of this phase is called the Requirement Statement, which gives the detail requirement of the proposed system, which is the foundation for the new system.
iv. Selection:
The objective of this stage is to broadly formulate a number of alternative systems which would more or less meet the user needs specified in the Requirement Statement and then select the best among the lot by appraising each in proper perspective.
The factors to be taken into consideration for developing alternative solutions would be:
1. The role to be played by the users of the system, both directly and indirectly.
2. The computer processing mode, like batch or interactive processing and for which operations. Choice between distributed and centralized processing would also come into play.
3. The type of hardware to be used — mainframe, mini, or micro or combinations, etc.
4. The operating system — multiprogramming, multi-access, etc.
5. The other software — purchased or developed in-house.
6. The file system to be used and the data base to be built.
7. The controls to be introduced to ensure reliability and security of the system.
Apart from the above factors, the man-machine interface at each stage from input to ultimate output have to be taken into account under different combinations and then final selection made. Although, the key factor in selecting the best alternative is the cost-benefit assessment, two other factors are also considered.
Once the final system is selected, it is essential to prepare a schedule indicating when, which components or stages of the system will be implemented leading to the full operational stage of the proposed system.
The document which is prepared at the end of the Selection Phase is called the Systems Proposal — which is a detail document giving everything of that has been done under the phase of the System Analysis. The introductory part gives the background of the project, it scope, structure, etc., which is followed by an analysis of the present system highlighting its strengths and weaknesses, the alternative solutions considered with the basis of appraisal, the final solution considered and the reasons for so.
The System Proposal also called Feasibility Report, is supported by different documents prepared using system analysis tools and the techniques applied. The final profitability statement is also enclosed, showing investment and operational cost. It is the final document, the approval of which initiates designing and implementing the proposed system.
System analysis involves a detailed analysis and investigation of an existing system in the problem area, taking into account the objectives and requirements of the users operating within the various constraints, and selection of an optimum solution after evaluating suitable alternatives — to provide the framework of the proposed system contemplated to replace the existing one.
The objectives of a business organizations are definite time-bound targets set to achieve, keeping in mind the goals, which are what it wants to achieve in its line of business. For example, the goal could be to maximize profit and an objective could be to reduce cost of operation by 10% within 2 years.
Term Paper # 2. System Design Phase:
Once the phase of the system analysis has been systematically completed ending with the broad outline of the approved, proposed system, we enter the second phase of the System Development Life Cycle [SDLC], which is the System Design phase.
In the analysis phase, the emphasis was on what are required to be achieved by the proposed system and so it was implementation-oriented planning. In the design phase, the emphasis shifts to how the objectives will be achieved through the proposed system and so it involves implementation-dependent planning.
The two distinct sub-phases of the system design phase are:
1. Design the detailed specification of the proposed system; and,
2. Acquire the necessary hardware with supporting software.
Since the System Design Phase is followed by the System Implementation Phase, where developing programs for the proposed system is a major activity, to avoid any misunderstanding, the design phase has to prepare all the specification which would be needed by the programmers to develop the programs.
Hence, the design phase has two clear cut objectives:
Firstly, to design a user-friendly computer based information system under the identified constraints which will meet the requirements of the users as agreed upon, and,
Secondly, to draw the complete specification for successful program building.
Generally, taking into account the technological and profitability factors, the detailed specification of the hardware is first finalized and then the programming specification are drawn up, as the characteristics of the hardware and its components have an impact on the software.
In other words, the broad activities of the design phase are to design the:
1. Processing methods and the different procedures.
2. Structure of the files and the data base.
3. Outputs and the inputs to the system.
4. Specification of the program to be developed.
The system analyst must not overlook the aspects of user-friendliness, user- acceptance, the system-constraints, and the flexibility for future development.
Taking the total system into account, the design process starts by decomposing, also called factoring, of the proposed system into its functional modules or sub-systems using the structured designing techniques.
The different factors to be considered and provided in the design are:
1. What procedures, the sequences of working steps, to be followed in the manual processing areas, which have been decided earlier in the selection phase.
2. How the input will be captured, the modes, formats, style, etc.
3. How the output information will be presented — soft/hard copies, forms, frequencies, and levels.
4. What data base and file management system will be used for storage of data — format, access method, etc.
5. What will be the volume of processing in normal and peak-load periods along with the turn-around/response times.
6. What will be the hardware of the CPU and the peripherals.
7. What operating system will be used — single/multi-user, LAN, etc.
8. What portion of the software will be ready-made for what purpose and how much will be developed in-house.
9. What back-up and recovery system will be followed.
10. What internal control and audit measures will be taken for reliability, security, etc.
11. What will be the complete specification of the programs to be developed.
12. What man-power would be required with their respective levels of skills.
13. What training and development have to be provided to the users.
System design involves detailed design of the proposed computer based information system, using various tools, whose outline was drawn up in the previous phase — the what and how of the existing system being already established.
It also involves acquiring the hardware with supporting software, if required. The design phase enables programmers to take up building up of appropriate programs for the proposed system, with built-in controls to ensure integrity and security of the resources.
Term Paper # 3. System Implementation Phase:
This is the third stage of the System Development Life Cycle, where the implementation of the design specification prepared is accomplished and the new system is put into operation. The activities involve, installing the hardware and the software after development, carrying out various kinds of tests, finalizing the manuals for the user, and then handing over the new system to the user.
The handing over exercise can be accomplished in different ways, as detailed below:
1. Abrupt Cut over or Direct Approach:
Under this procedure, one fine morning, which is predetermined, the manual system is discontinued and the computerized system comes into full operation, with all the files with updated data. This is a high-risk transfer operation, which may lead to chaos.
Under this procedure, the new system runs in parallel with the old system for some time and then when teething troubles have been taken care of, the old system is discontinued. However, this is possible when there is such a facility for parallel operation, which is generally the case with computerization of manual systems. It is quite safe.
Under this procedure the new system is implemented location-wise in one after another physical areas. Also called Pilot Running Approach by some.
This is a procedure where instead of implementing the whole system in one go, it is implemented in stages. For example, the sales, material systems etc. are implemented one by one.
In spite of all manuals and discussions, it is essential to draw up plans for systematic user training and its implementation so that the user can feel at home with the new system and can even handle emergency situations.
We should always learn from what we do and that is called experience. Moreover, since it is the responsibility of the system team to ensure compliance with user requirement, it is absolutely necessary to review the performance of the new system in terms of what was decided earlier. In addition, the procedures for developing the system along with different steps taken should also be reviewed to enrich experience.
The testing of a program to ensure it as bug-free is a difficult and time-consuming process.
Generally, the testing is carried out with data of three types, such as:
1. The normal, typical data for general testing.
2. Extreme values of valid data to test exceptional cases.
3. Incorrect data for testing the capabilities of error-handling.
The testing is a difficult exercise because even a limited number of conditional paths [if – then] results in so many combinations that a hidden bug may not be detected during testing. The execution errors are generally caused by bad data, bad parameters, or bad values used in the program.
Testing in depth involves finding out whether the algorithms have been used correctly to solve the problems and whether the program correctly executes the algorithm used. In computer language, any defect or error in software or hardware is called a bug, and the process of detecting and removing the bug, is called Debugging. The basic objective of testing is to debug the system developed.
Detection of bugs is greatly facilitated by modular programming, where individual modules can be tested before hand.
Hence, there are many testing stages, such as:
When the individual modules are separately tested and made bug-free.
When different modules are combined to create large relevant modules and then testing is carried out.
When all modules are combined to create the final program and then tested.
4. User Testing [also called Beta-Testing]:
It is carried out by the users to detect bugs during rigorous use.
In each case, different types of data, as mentioned earlier, are used in testing.
In this phase need-based programs are developed, tried and tested, integrating the same with the hardware and acquired software, if any — training and developing the users and then handing over the new system in a planned manner.
Term Paper # 4. Program Maintenance Phase:
It is the last phase, which is said to be giving the finishing touches with modifications and improvements in the programs and displays and ensuring that the system operates smoothly, fulfilling its planned objectives.
Programming is a dynamic exercise as the user’s needs go on changing with time calling for updating of the application programs adding new features and this is called maintenance of programs.
The program life cycle comprises:
1. Analysis and design of the system to be computerized.
2. Encoding the solution in computer language.
3. Implementing the new system to replace the existing system.
4. Program maintenance and upgrading.
As far as the cost of an application package prepared for an user is concerned, the cost of maintenance is much more than the cost involved in other three areas, because modifying an existing program is a complex task. For enhancing the performance of a program, changes have to be made at source level and then it is to be recompiled to get the modified version. Because each module is inter-related with other modules, careful changes in source code are necessary.
Documentation plays a vital role in program maintenance. It is absolutely necessary not only to preserve the source code with each modification properly dated and commented, but also all related documents. Usually, when programs are developed bound books called manuals are prepared for helping the user to understand how the program is to be operated, what are the facilities provided, etc.
These are variously called as User Manual, Reference Manual, System Manual, etc. But for program maintenance, additional documents are required which include Program Flow Chart, Data Flow Diagrams, etc.
It is also essential to preserve the details of the various testing activities carried out, the result of such testing, and what steps were taken to rectify errors/ mistakes in what way.
Generally, both the input and output have well designed screens for display and these should also be preserved by taking screen dumps. In short, for successful maintenance of program at minimum cost, all the documents prepared / used during the development of the program must be properly preserved and properly dated — to prevent mix-ups of revised documents with superseded documents.
Documentation is a process which results in recording on paper of all facts and figures of all the aspects of the system development process, right from problem definition to its solution by implementing the new system — and it must be done in a systematic manner with proper indexes, not merely jotting down something on a scrap of paper, with high chances of misplacement.
It is also essential to keep all back-up papers of all reports prepared. Unfortunately, this is an area which is often neglected by the system people. The system analyst must document what has been done and why.
In system development activities, often one has to go back to check or correct something. In absence of proper document, it may take hours to find out what was done and why. Good documentation is also essential for proper system support.
Moreover, for effective system development, the system analyst often has to go back to the previous phases for carrying out modifications; when systematic documentation is a great help. The documents relate to the existing system, with its strengths and weaknesses, as well as to the new system developed.
The various documents generated at the end of different phases of system development life cycle, and those needed to be preserved are:
1. Report on Feasibility Study at the end of Survey Phase.
2. Documents on working of the present system and its analysis.
3. Problem Statement prepared after the Study Phase.
4. Objective and priority statements.
5. General and Technical Requirements finalized after Definition Phase.
6. Details of alternative solutions prepared and their appraisal.
7. Details of the selected proposal.
8. Schedule of implementing the project.
9. Feasibility Report prepared after the System Analysis Phase.
10. Detailed specification of the approved proposal.
11. Documents relating to program-coding of the system.
12. Details regarding various tests carried out.
13. Manuals for training and development of users.
14. The record of all tools and techniques used and their output.
15. All correspondences with the user regarding different aspects.
In general, the documents generated during system development can be classified as:
a. Analytical:
As the name suggests, these documents are prepared during various analysis carried out of the existing system.
b. System:
These are the documents which contain the definition of what the proposed system is going to be.
c. Program:
These are related to the programming aspect of the new system and includes algorithms, program codes, etc.
d. Operation:
These are related to execution of the system, the procedures to be followed to operate the hew system.
e. User:
These are the manuals and other documents which are generated during interaction with the user.