Systems Development Life Cycle

In Systems Development Life Cycle (SDLC) model, the development process is divided into a set of well-defined steps or phases as follows:

• Systems Investigation
• System Analysis and Requirements Definition
• Systems Design
• Software Development
• Testing
• Implementation
• Maintenance

The SDLC is a development process that is best suited for projects where the requirements can be clearly defined. SDLC encourages top-down problem solving. That is, designers must first define the problem to be solved and then use an ordered set of steps to reach a solution. In SDLC, the development activities are performed as a sequence of phases. The major phases are illustrated in the figure 3.1.3. In SDLC, each phase begins only after the previous phase has been completed. Each phase usually produces one or more model(s), and/or products (shown in figure 3.13 in rectangles with rounded corners underlined). The models become part of a phase report, whic h describes what have been achieved in this phase and outlines a plan for the next phase. The report also includes any models, new or expanded user requirements, design decisions and problems encountered. This information is used at the next phase. Phase reports are also used to keep the management informed of project progress, so that management can change or modify project direction and allocate resources to the project. In the following subsections, we will discuss each phase in detail.

The development phases in SDLC

Systems investigation phase: The systems development life cycle begins with the System Investigation Phase. This phase includes problem definition and feasibility study. The major goals and objectives of the project are identified in this phase. This typically includes answering the following questions:

1. Problems in or opportunities for improving the existing syste
2. Objectives of the system investigation
3. Overview of the proposed system
4. Expected costs and benefits of the proposed system

A vital step in the system investigation phase is the feasibility study. Feasibility study includes:

• Operational feasibility – whether the project can be put into action or operation. This includes considering motivational, logistical and acceptance considerations (such as resistance by users and other ethical considerations).
• Technical feasibility – whether hardware, software and other system components can be acquired or developed to solve the problem.
• Schedule feasibility – whether the project can be completed in a reasonable amount of time.
• Economic feasibility – whether the project is financially viable. Whether the predicted benefits offset the costs and time needed to obtain them.
• Legal feasibility – whether there are laws and regulations that may prevent or limit the system development project.

 Let us consider an example of a school. Let us assume that presently the school uses a manual system for administration purposes of the school. A computer-based information system (i.e. School Information and Management System - SIMS) for the school can dramatically improve the efficiency of its Administrative Division. If we were to develop a SIMS for the school using SDLC, the first step will be to perform a system investigation phase. In the system investigation phase, we will identify the following:

• Problems in or opportunities for improving the existing system. By having a SIMS in the school, we can keep all student records, staff records, timetables etc. in the SIMS. This can improve the efficiency of the administrative division. For example, some of the objectives of the system may be:

1. Release student reports within 2 days of submitting the marks by teachers.
2. Student character and leaving certificates provided to students within 2 working days from the time of request.
3. Student reports are accessible to students and parents via the Internet.
4. Staff attendance and salaries are calculated using SIMS.

• Objectives of the system investigation

1. The objectives of the system investigation phase are to evaluate the feasibility and merit of introducing a SIMS to the school. The operational, technical, schedule, economic and legal feasibility is studied. Also, justification for introducing a SIMS to the school is discussed.In our SIMS example, a requirement may be to keep student and staff records in Sinhala and Tamil languages. The technical feasibility study will investigate whether current technology has adequate support for Sinhala and Tamil languages.

• Overview o f the proposed system

1. The overview of the proposed system including the main features is discussed. The following diagram illustrates an example of a proposed system.

An overview of a proposed School Information and Management System (SIMS)

In the above figure, the School Information and Management System (SIMS) keep data of students and staff in a database. The staff enter their attendance information to the system (by swiping a proposed staff identification card). SIMS uses this information in computing the salaries of the staff members. Teachers enter the student marks to the SIMS from the staff room. The Student Reports are generated by the SIMS and accessible to students via the school network (i.e. from the computer lab). The parents also have access to the Student Report of their child via the Internet. The Registrar uses information in the SIMS database to verify records and generate Student Character and Leave Certificates.

• Expected costs and benefits of the proposed system

1. Since the school currently uses a manual system, the costs must be computed for technology infrastructure, re -organization and training of staff. Then an analysis of whether the benefits outweigh the costs or not must be determined.

This phase results in a statement of requirements (i.e. formal definition of what the system must do). This document includes the project goals, project bounds and resource limits. This output is often reviewed by a steering committee, often consisting of senior management, users, IS department personnel and other functional areas. After review, the approval may be given by the management to carry on with the other phases and allocate resources for the project. 

System analysis and requirements definition phase: The next phase, Systems Analysis and Requirements Definition, results in the detailed system specifications. This includes an analysis model which describes how the current system works and what it does, requirements model which gives detailed requirements on what the users want the new system to do, and design model which describes how the new system will work and what it does.

In this phase, the existing system is studied in detail. Data on the existing system is gathered using different techniques, such as (1) inspecting written documents, (2) conducting interviews, (3) questionnaires and (4) onsite observations. The next step is to manipulate the collected data so that it is usable for the development team participating in the system analysis. Various techniques including data flow diagrams (DFD), entity relationship diagrams (ER), screen layouts, report layouts etc. are used for documenting requirements. (The study of these techniques in detail are beyond the scope of this book. Readers are encouraged to refer to the Suggested Learning Materials in section 3.6 and other related references for further information). In this phase, requirements for the new system are proposed, reviewed and documented. The figure below shows an example of a Student Report generated by SIMS.

A Sample Student Report generated by the proposed School Information
and Management System (SIMS)

At the end of this phase, the detailed system specifications (also popularly known as the Systems Requirements Specification – SRS) of the new system are generated. This document specifies in detail all the functionalities of the proposed system (i.e. “What the system does?”). These requirements are used in the next phase, which is the Systems Design phase. 

Systems design phase: The Systems Design Phase produces a design specification for the overall system being developed. This specifies how the system will be built meeting all requirements specified by the SRS. This includes an architectural design, which specifies the high-level modules being built, and a detailed design, which specifies the user interfaces, system procedures and low-level modules of the new system.

The design specifications typically cover the following areas:

• Hardware design: All computer equipment including input, processing and output devices with performance characteristics. In our example of SIMS, hardware design includes specification of all hardware requirements (such as computers etc.) and specifying for what purpose the equipment will be used.

• Software design: All software must be specified with capabilities. Certain software may be purchased or others may be developed. All input, output and processing requirements are considered in software design. In our example of SIMS, this includes all software that needs to be purchased (such as Operating Systems, Database Management Systems) and also specifying the software components to be developed (such as Principal, Registrar, Student, Parent interfaces to SIMS, etc.).

• Personnel Design: Positions, job titles and task descriptions are considered in the personnel design. In our SIMS example, we may propose new positions, duties and job titles such as a “System Administrator” etc. and even restructure existing positions.

• Database design: The type, structure and function of the database must be specified. In our SIMS example, this may include the database design that stores the student and staff records.

• Telecommunications and network design: The necessary characteristics of the communications software, media, and devices must be specified. In our SIMS example, this pertains to the school network design that connects the different computer systems.

• Procedures design: All information systems require procedures to run applications and handle problems if they occur. These important policies are captured during procedures design. An important aspect of this step is to design security and backup polices and procedures to minimise the potential for fraud and crime.

• Training requirements: Specifies the training requirements.

• Maintenance requirements: Specifies maintenance requirements for both hardware and software.

• Design Decisions and Alternatives: Major design decisions and alternatives considered are documented.

Various tools and techniques are used in the system design phase. We will not discuss these techniques in detail as it is beyond the scope of this textbook. Readers are encouraged to refer to materials outlined in section 3.6 and other related references for further information.

Software development phase: The specifications produced in the systems design phase provide the input for the Software Development Phase. At this stage, software developers and programmers build and test individual modules of the overall software system. The individual modules are integrated to produce the new system.

Testing phase: Testing Phase proceeds in parallel with the major phases. A broad test strategy is defined at the time the system requirements are identified. Detailed test design takes place during system design, and testing is a part of the software development phase. There are different types of testing that takes place:

• Unit testing: tests individual modules.
• Integration testing: modules are integrated and tested.
• System testing: entire system is tested
• Acceptance testing: verifying users’ test scenarios. This is usually performed at the end of the system development to verify that the system meets users’ requirements.

Other types of testing include stress testing (with large volumes of data and users), reliability testing (how does the system handle failures?) and security testing (how does the system perform with respect to security attacks?). In addition to the testing types mentioned above, in SDLC, after each phase, the output is verified/validated to ensure that the phase objectives have been correctly met. 

Implementatio n phase: The Implementation Phase puts into operation the system built in the software development phase. This phase includes user training, acceptance testing and deploying the new system (also called conversion). Conversion of the system may proceed in four ways:

• Direct implementation: The entire system is replaced with the new system at once.

• Parallel implementation: Both systems (i.e., the new and the old systems) are executed in parallel for a certain defined period of time. This strategy is helpful because of the following:

1.  Results of the old system can be compared with the results of the new system.
2. Failure of the new system at the early stage, does not affect the working of the organisation, because the old system continues to work, as it used to do.

• Phased implementation: The new system is introduced in a phased manner. In this implementation, the new system is installed in parts. Some part of the new system is installed first and executed successfully for considerable time period. When the results are found satisfactory then only other parts are implemented. This strategy builds the confidence and the errors are traced easily.

• Pilot implementation: Pilot implementation allows users to test-drive the solution to make sure it meets both business and technical needs. During a pilot implementation, the solution is installed and configured in the users’ environment for the first time. A pilot implementation provides a snapshot of the same functionality of a full system implementation, generally without the scalability and redundancy found in a full system. To complete the changeover, users must be trained in system operation and any existing old procedures converted to the new system.

Maintenance phase: Maintenance is needed to eliminate any errors in the system during its working life and to tune the system to variations in its working environment. Also, an important review is the post-implementation review. This is usually conducted after sometime the system is implemented. The goal of the review is to evaluate how well the system meets its objectives.

In SDLC, there is a definite end point to each phase. The phases are carried out in strict sequence. One phase must be completed before the next phase starts. The problems are solved in a top-down manner from the initial concept to the detailed design and development.

The SDLC allows for a large degree of management control. At the end of each phase, a formal review is performed and a decision is made whether to continue, terminate the project or modify and repeat some of the current tasks of the current phase. During the SDLC, documentation is created and this can be useful for system modification later. A major problem of SDLC is that the user does not see a solution until the system is nearly complete. It may result in a system, which does not address the user’s real needs since the development was based on development team’s understanding of the needs. This is quite possible since the user may not necessarily be a computer literate or expert on systems and his expression of requirements may be incomplete and inaccurate resulting in misunderstanding by the development team. SDLC is also inflexible to changing needs of the users. Changes to requirements during system development may not be incorporated. This is because once the systems requirements definition phase is completed, the development team works on other phases without much interaction with the users. If the users’ requirements change during this time, the development team may not be aware or be able to incorporate these new requirements to the system. Even with these shortcomings, SDLC is still a popularly used development methodology for many TPS and MIS systems because of its advantages. Table 3.2 below illustrates some of the advantages and disadvantages of SDLC.

Advantages and Disadvantages of SDLC