INFORMATION GOVERNANCE

Systems Development Life Cycle

The chapter covers the first two stages, system initiation and requirements analysis, of the SDLC in detail. This document covers the remaining SDLC stages.

Refer to textbook page 107 for an explanation of the following:

· System Initiation

· Requirements Analysis

· System Design

· System Construction

· System Acceptance

· System Implementation

System Design Phase

When the requirements analysis phase has been completed and the functional requirements identified, the system is designed. The systems design phase provides the design or blueprint for the technical solution for the proposed system. The design phase describes how the system should function. This includes how:

· Users interact with the system and the types of user interfaces they need

· Components of the system interact with each other and existing application programs

· The data model for the system integrates with existing data models

· The application will be programmed

· The technical environment for the system will be prepared

· System testing will be conducted

· System migration will be handled

A special technical team is assigned for the system design phase. One of the first steps is to assess the existing technical infrastructure and capabilities and to attempt to leverage these as much as possible. However, the team may discover that new technology platforms are required to support the new system. Items such as data access and storage, runtime and batch time requirements, reporting, archiving, security and auditing, and interface development are identified.

An important part of the design phase is to specify design standards. Among these standards are specifications for naming conventions, programming techniques, screen formatting and graphical user interface design, report generation, application navigation, documentation formats, and application testing. Configuration management standards that prescribe the way changes to the software are tracked and how backup and recovery procedures are handled are also specified. Design standards would fall under data governance policies and procedures.

The logical data model is transformed into a physical data model. Physical database repositories are created to handle the application. In designing the physical database, designers take into consideration items such as how the data is used, number of users expected to access the database simultaneously, anticipated peak user loads, and retention requirements.

During this phase, prototypes of the system are often developed. The prototypes address aspects of the system such as screen and usability design, navigation, controls such as buttons, and presentation and report styles. Prototypes help the end user assess the functionality of the system. It is easier and less costly to make adjustments and refinements in this stage than in construction and implementation states.

The output of this phase is a technical architecture document that specifies the hardware, software, database, and tools and peripherals needed, performance requirements of the system, technical risks, and data and code migration plan.

System Construction

System construction includes all of the activities required to build and test the system. Training materials and system documentation are also developed during this stage. Individual components and utilities of the system are developed and then are tested individually by the construction team using test scripts to ensure functional requirements are met. Test scripts identify the function and technical requirements the system must perform and expected outcomes. Any deviations from the specifications are noted, examined, and corrected. Once each module is tested, then the technical team initiates integration testing. Integration testing is an iterative approach. It involves adding module after module to the system and testing each successive addition to ensure that technical and functional requirements are met. A final end-to-end system test is then performed with all modules and utilities.

System Acceptance

After system construction, the system is handed over to the end-users and the project team to validate that it meets all of the functional requirements identified during requirements analysis. An acceptance test plan is developed and used to assess the system operation. This stage of the SDLC is critical because it is the last opportunity to identify and correct defects prior to the system going into production. Emphasis is placed on testing the application and the data. Data throughput, manipulations, and load should be thoroughly tested to ensure that expected outputs are produced. The system acceptance environment should be as close as possible to the actual production environment and the testing team composed of representatives from all end user roles that will be using the system.

System Implementation

System implementation includes the deployment of the system and its continuing maintenance. The project team develops detailed implementation plans. Unlike other SDLC stages, the implementation stage affects real business operations. Errors or missteps during this stage can have a potentially catastrophic impact on the business. Training end users is a significant part of this stage of the life cycle.

Several different approaches may be used for implementation. Each has its own risks and costs. These approaches are called parallel, phased, and direct conversion. Frequently, a new implementation is replacing an older system. When this is the case, a parallel approach may be used. This involves running both the old and the new systems until the managers and technical staff are confident that the new system is functioning as intended. This approach is costly and can be confusing to staff, but it ensures that a backup system would be available if needed.

A second approach is the phased approach. The phased approach is usually implemented in one of two ways. In one approach, portions of the new system are implemented over time, usually module by module, instead of installing the entire system at once. This allows for easier identification and remedy of any defects found by the user and technical teams. The system can also be phased in location by location. In this approach the entire system may be implemented in one or a few units at a time rather than implementation occurring throughout the entire organization. This approach limits the impact of any defects and risks to a smaller segment of the business.

The final approach is called a direct cutover, where the entire system is implemented on a specified date throughout the organization. This approach is risky but can work if there was sufficient testing and if there are adequate backup and recovery procedures in place.

Implementation also involves ensuring that the system is meeting all functional and technical requirements. Evaluation scripts are developed and used to identify any lingering defects.

Once all evaluation is completed, the system is considered to be operational and enters the maintenance phase. The responsibilities for the system are then turned over from the implementation team to a maintenance team.