Chapter 2—The Systems Development Life Cycle

Developing anything more than a simple data retrieval system is a multiyear project. The number of system users, their requirements, the network of relationships, the complexities of ever-changing technology, and the personal politics involved with any system increases the importance of sound project management and an in-depth understanding of the life cycle of a systems development project. While an LDS is not just a project—it requires ongoing maintenance, use, training, etc.—thinking of LDS development as a project in its early phases can be useful.


The systems development life cycle is "a protect management technique that divides complex projects into smaller, more easily managed segments or phases."

Source: Federal Financial Institutions Examination Council. Development and Acquisition.

Many words can be used to name the stages and substages in an information systems development effort, but for the purposes of this guide, the following verbs will be used to describe the whole life cycle: plan, analyze, design, develop, test, deploy, maintain, and evaluate. (Note: The framework depicted in the graphic on the following page applies to the systems development life cycle only. This Forum guide is not organized around this framework.)


The importance of thorough planning cannot be over emphasized. And neither can the need to take as much time as necessary to implement the plan successfully. For the purposes of this guide, "planning" includes working with a broad range of stakeholders who may be affected—or believe they may be affected—by the LDS in order to articulate the goals of the new system (see chapter 4), as well as assigning roles and responsibilities for project management (see chapter 3). Developing a communication plan that includes all individuals and groups that may be affected by the education information system is essential. System development efforts might be seriously affected if a stakeholder becomes an active opponent of the effort. These potential surprises and other risks should be articulated and evaluated during the planning process. Data quality, sharing, and security strategies should be discussed—as well as the stakeholders and risks associated with these strategies. General goals should be defined by project deliverables with a set schedule and budget for each separate component as well as for the whole. At this point, the scope of the project—what is and is not to be included—should be clearly described and a method for managing changes established to monitor and control scope creep. In the planning stage, the current environment should be analyzed (see chapters 4, 6, and 7) and a clear picture of the future information system should emerge (see chapters 78). Anything missed in the planning stage may go unnoticed until it is too late to fix or, at best, a return loop to the planning stage is required. Every project returns to the planning stage in the iterative process of system development; while this is unavoidable, the number of times repeating this stage is required can be reduced through thorough planning and by using the systems development life cycle the first time.


Analyzing the information needs of all system users is a long and tedious process. It requires great patience and repetition to generate the input necessary to turn vague ideas of what would be useful information into definable and actionable system requirements. This is where the project goals and deliverables become defined in functional process terms. This is also where the project is critically examined to articulate and define the risks associated with the work to be done and what resources are needed. Each of these risks should be classified as high, medium, or low; and assigned a strategy for mitigation in case it materializes. Consideration should also be given to how data quality and security will be ensured (see chapters 4, 8, and 9). It may be useful to consider existing working models (such as successful in-house-developed and "off-the-shelf" systems), while focusing on the most important ways the information in your desired system will be used and reported. Sharpening your understanding of the desired "there" system will make your analysis much more effective and shorten this stage of the process considerably.

The Forum has more detailed information...

... about these issues


In the design stage, all the mental pictures created in the earlier stages are put into clear and completely documented forms. Business rules are articulated and refined, screen layouts are developed and improved, process diagrams are drawn and redrawn, and system documentation is carefully and completely kept. As with the previous two stages, the design stage often exposes issues or problems not previously discussed. This requires a return to the earlier stages in order to plan and analyze the newly exposed concerns.


When the design documents are complete, they are given to the developers to write the code that will automate the processes and produce the desired result. Coding standards and naming conventions are but two of the many considerations that must be made by the system developers.


During the development stage, the testing stage begins and testing plans, user acceptance tests, and a testing schedule are developed. These tests are run, shortcomings are discovered, and the system is modified to eliminate any defects. Any time or effort avoided at this stage may come back multiplied many times if a system defect survives to plague the system's end users.


In the deployment stage, the new system—with its hardware, software, and applications—is installed and often run parallel to the old system until the acceptance criteria established earlier (in the plan and analysis phases) are met. System security is deployed and tested in real time situations, and data quality is checked and verified.


When the system has met all required tests, it enters the maintenance stage. The system operations team performs periodic quality assurance and system security audits, updates hardware and software as needed, and maintains documentation. The maintenance stage continues as long as the system is operating and serves not only to keep the system running, but also to make incremental improvements.


The data system should be evaluated throughout its life cycle to ensure it is being implemented successfully, working optimally and cost effectively, providing measurable benefits, and meeting user needs as initially identified in the planning stages and as they evolve over time. Newly identified requirements will often warrant system changes beyond the level of "incremental," requiring serious monitoring and evaluation that will produce system change requirements. Such changes should be routed through the entire systems development life cycle process. When it is determined that the existing system is no longer as effective or efficient as it should be, the system owners will go through the systems development life cycle again, beginning with planning for improvements to the existing system or the development of a new system.