System Development Life Cycle (SDLC) Introduction SDLC is the process by which systems analysts, software engineers and programmers build systems. It is a project management tool, used to plan, execute and control systems development projects.

SDLC is a phased approach to analysis and design, which holds that systems are best developed through the use of a specific cycle of analyst and user activities.

The development of software systems is a complex process, normally involving many people with a variety of special skills (analysts, engineers and programmers etc.). The process is broken down into stages or phases that deliver several intermediate outputs to the final system. These stages and phases together are known as the SDLC.

Analysts disagree on exactly how many phases there are in the SDLC but agree on its organized approach. No matter how many discrete stages there are in SDLC, they are never accomplished as separate steps. Instead several activities can occur simultaneously and activities may be repeated. Traditional SDLC can be divided into the following discrete stages:

Identifying problems, opportunities and objectives In this first phase of SDLC, the analyst is concerned with the identification of visible and invisible problems, opportunities and objectives. This stage is critical to the rest of the project, since no one wants to waste subsequent time addressing the wrong problem.

The people involved in this phase are the users, analyst and systems managers coordinating the project. Activities in this phase consist of interviewing user management, summarizing the knowledge obtained, estimating the scope of the project and documenting the results.

The output of this stage is a feasibility report containing a problem definition and summarizing the objectives. This report will then assist the managers to make a decision whether to proceed with the proposed project or not.

Determining information requirements In this phase the analyst determines the information requirements for the particular users involved. Amongst the tools used to define information requirements are: Sampling and investigating hard data Interviewing Questionnaires Observing decision makers' behavior Office environment Prototyping

The people involved in this phase are the analysts and users, typically operation managers and operation workers. The systems analyst needs to know the details of the current system, such as: WHO are the people involved? WHAT is the business activity? WHERE does the work take place? WHEN does the work take place? HOW current procedures are performed? WHY is the current system being used?

At the end of this phase, the analyst should understand how the organization functions, and have complete information on the people, goals, data and procedures involved.

Analyzing system needs The next phase to be undertaken by the system analyst is the analysis of the system needs. Special tools such as Data Flow Diagrams (DFD's) may be used to chart the input, processes and output of the organization's functions in a structured graphical form. From the DFD's, a data dictionary is developed that lists all of the data items used in the system as well as their specifications.

During this phase the analyst also analyzes the structured decisions made with the help of any of the following three methods: Structured English Decision tables Decision trees

At the completion of this phase, the analyst prepares a systems proposal that summarizes what has been found, provides cost-benefit analysis of alternatives and makes recommendations on what (if anything) should be done. Each system problem is unique and there is never just one correct solution.

Designing the recommended system In this phase of SDLC, the analyst uses the information gathered earlier to accomplish the logical design of the information system. Part of the logical design of the system is devising the user interface. The interface connects the user with the system and is, thus, extremely important. The analyst also designs accurate data entry procedures so that the data going into the information system are correct.

The design phase also includes designing files or databases that will store much of the data needed by the decision makers in the organization. A well-organized database is the basis for all information systems. The analysts, in this phase, also works with the users to design output that meets their information needs.

Lastly, the analyst must design the controls and backup procedures to protect the data and produce specification packets for the programmers. Each packet should contain input and output layouts, file specifications and processing details. It may also contain decision trees or tables, DFD's, a system flow chart and the names and functions of any pre-written code routines.

Developing and documenting the software This phase requires the analyst to work with the programmers to develop any original software that is needed. Some of the structured techniques for designing and documenting software include structure charts, flow charts, Nassi-Schniederman charts and pseudocode. The analyst may use one or more of these methods to communicate with the programmers.

During this phase, the analyst also works with users to develop effective documentation for the designed software, including operation manuals.  

Testing and maintaining the system Before the information system could be put into action, it must be testes. It is much less costly to catch problems before the system delivered to the users. Some of the testing is carried out by the programmers only and some by the analyst in conjunction with the programmers. A series of tests to pinpoint problems is run first with dummy data and eventually with actual data taken from the current system.

Maintenance of the system and its documentation begins in this phase and is carried out routinely throughout the life of the information system

Implementing and evaluating the system In this last phase of system development, the analyst helps implementing the information system. This involves training the users to handle the new system either by the vendors or better yet by the systems analyst.

Additionally, the analyst needs to plan for a smooth conversion from the old system to the new one. This includes the conversion of files from the old to new format or building a database, installing equipment and bringing the new system into action. Evaluation takes place during every phase of the SDLC. A key criterion that must be satisfied is whether in intended users are indeed using the new system.

General Principles for SDLC Every system is a part of a larger system and can be broken down into smaller sub-systems. The components of a system must communicate with each other. The most specialized systems are the least flexible. Systems grow and change.

The system is for the end user The system is for the end user. Get the end user involved throughout the systems development. Establish phases and tasks to better manage systems development projects. Systems development tasks are not strictly sequential. They may overlap and the analyst may have to backtrack to correct mistakes. Systems are capital investments and these should be justified as such. Establish checkpoints to reevaluate feasibility and don't be afraid to cancel infeasible projects despite sunk costs. A system should be documented while it is being developed.

Activities that overlap much of the SDLC There are several phases that overlap many or all the phases of SDLC. For this reason they are not called phases but umbrella activities. These include: Fact finding Documentation and presentation Feasibility analysis Project management

SDLC Problems Projects are not integrated. Slow delivery. Systems are error prone. Systems are inflexible. Low user involvement.