System Development Life Cycle (SDLC)
The System Development Life Cycle (SDLC) is a conceptual model for software development that consists of multiple phases: Software Concept; Analysis; Design; Coding and Debugging; System Integration and Testing; Implementation; and Maintenance and Support. Each phase can be thought of as a building block for the next phase. There are different SDLC models that may be followed, such as the classic “Waterfall Model,” “Spiral,” and “Evolutionary Prototyping,” as well as many modified Waterfall models.1 The key is to adapt a model that lends structure to your project. This paper features a Waterfall Model for the SDLC.
In the Waterfall model, a software development project progresses through a sequence of steps from initial software concept through maintenance and support. The model is sometimes referred to as document-driven because documents are produced in each phase and used in subsequent phases. The documents serve as a progress indicator throughout the life-cycle until a working software product is available. Planning is often difficult in software development projects due to intangible items. However, when using the Waterfall model the requirements are usually well-defined so planning can be done up front. The Waterfall model works well with complex projects where the requirements are well understood because the complexity can be dealt with in a structured way.
A fairly simple software project can become complicated very quickly, so keeping the project organized and documented is essential. Many projects fail or miss deadlines and come in severely over budget for the simple reason that thorough analysis and design are not done up front and risk is not managed. Careful consideration of each phase of the SDLC, while participating in a software development project, will greatly increase the chances of a successful project. Planning on several levels is essential for the successful completion of any software project. The SDLC can be beneficial to a software project regardless of the size or complexity of the project if a conceptual model is followed. The following seven SDLC phases illustrate the selected Waterfall Model.
Phase 1: Software Concept
The first phase in the SDLC identifies and defines the system to be developed. In this phase the researcher and software engineer brainstorm about the system and what it will do. Document requirements (using the template in Appendix A) as much as possible, so that an adequate system can be built that will be flexible for handling future enhancements. Communication among the research team including the software engineer, researcher, project manager (if other than the software engineer or researcher), stakeholders, and funding
1 The “Spiral” model divides a software development project into several smaller projects that address the major risks first. “Evolutionary Prototyping” is a model in which a prototype is developed and eventually refined into the final software product. Hybrid SDLC models may be successfully utilized as well. S. McConnell, Rapid Development Taming Wild Software Schedules (Redmond, Washington: Microsoft Press, 1996), pp. 136-147.
Sponsors is critical in this phase to ensure that proper requirements are obtained and documented.
Phase 2: Analysis
The team analyzes the requirements of the system to gain a clear understanding of what is required; in addition the software engineer must understand the technical aspects of the requirements. Figure out where and how the system will be used, who the users will be, and document everything for use in the Design phase. The team members must document even the seemingly trivial details gleaned during analysis, because these are the things that turn out to be very important for the proper execution of the software product.
Phase 3: Design
In the design phase, the analysis that was done in the previous phase is reviewed and the software engineer devises a design solution. The design must support the requirements and be as explicit as possible. Software design tends to start out relatively simple, but as all the requirements are considered, systems tend to become complex and unwieldy. It is good practice to prioritize the features based on importance and effort while putting together the design. Use Appendix B, a project schedule template, for documenting the tasks to implement the design. Use Appendix C, a priority list template, for establishing priority of project features. This way the coding schedule can incorporate the tasks associated with high priority features in a timely manner because there is the chance that items with lower priority may not make it into the software or may be included in a future release.
A solid architecture and design will avoid significant rework later on. Mainstream technology usually follows industry standards and is supported well; therefore problems can quickly be resolved when they arise. Careful consideration must be given before utilizing cutting edge technology. Since the technology is innovative, bugs and other technical issues will be present, and will need to be worked out as they are encountered. When problems arise, quick solutions are difficult to craft because the knowledge base and support is very limited. Even minor problems in these technologies can cause a cascade of modifications that need to be implemented which can adversely affect the whole project schedule and ultimately jeopardize the project.
Technical complexity increases the risk for the software project and should be avoided if possible. Issues resulting from unnecessary technical complexity can negatively impact the schedule, because a great deal of time could be spent trying to work around issues.
Phase 4: Coding and Debugging
Coding and debugging is the phase where the design is implemented by the software engineer. The design described in the previous phase serves as the blueprint for the system to be built, providing most of the information the software engineer will need. The software engineer will interpret the design and develop the code. Even when the software engineer is also the designer, it is important to have a detailed design, because it is easy to overlook minor details that can result in a major error.
Debugging is the process of locating and removing errors from the code. Most current programming languages allow compiling a “debug” version of the code. The “debug” version allows stepping through code, setting breakpoints, viewing current variable values, and offers debug information about the code that helps the software engineer locate problems. After the code is stable, the production version of the code is compiled and used for system testing.
Phase 5: System Integration and Testing
System integration occurs when distinct software modules are linked together and are capable of functioning as a unit. When there are multiple software engineers on a project, all the developers are expected to code to an accepted standard; if they do, and the design is good, there will likely be very few problems, if any, at this point. Unfortunately, this is not always the case. A common cause of system breakdown is a software engineer deciding that something needs to be done differently without informing the other software engineers. Because modules need to work together, a common protocol must be followed.
System testing helps to locate problems, and potential problems, with a software system. It is essential to have people other than the software engineers testing the software. It is a good idea to develop test plans to ensure that the testers adequately test critical functionality as well as less important items. For larger software projects, reporting bugs and prioritizing bug fixes will be a coordinated effort between the project manager, software engineer, and testers. Use Appendix C, a priority list template, for establishing priority of bug fixes. The software engineer and the project manager should come to an agreement on what to fix and what to let go, based on time, effort, and risk. This phase of the project usually takes on a life of its own, especially when the development team is large. In smaller software projects, testing tends to be straightforward, but in large projects, it is very time consuming to test every scenario, so adequate time must be allocated for testing in the schedule.
Phase 6: Implementation
Implementation is the process of installing the software on the customer’s (e.g., other agency client, NIST Server) system and applying licensing agreements and access rights. This process can be somewhat difficult since it is hard to know exactly what kind of system hardware and supporting software may be encountered during the installation. As a result, problems occasionally arise due to compatibility issues. Prior planning can help to minimize some of these problems. Licensing and access rights that were established during the design phase will be applied in the implementation phase. Software may be designed so that certain features are limited or turned off based on the particular license that is applied. Appropriate licensing ensures the proper level of functionality for the software product. Proprietary libraries, dynamic link libraries (DLLs) and other modules to be used in conjunction with the software product being implemented are examples of entities that may require additional licensing.
After implementation, do a presentation for the sponsor and invite the sponsor to do some acceptance testing. Keep the sponsor in the loop during development so there will not be any big surprises at the final demonstration. After acceptance testing, and any final revisions following that meeting, present a formal letter to the sponsor transmitting the final product and indicating closure of the project. This meeting is a good opportunity to confirm the sponsor’s interest in funding maintenance and support activities (see 2.7) as well as to identify the sponsor’s interest in funding additional features suggested during testing.
Phase 7: Maintenance and Support
Maintenance includes items such as patches and data updates, while support includes bug fixes, help for users of the software, and collecting requests for new functionality. Discuss maintenance and support with the customer up front. Different types of maintenance and support may be provided based on what makes sense for the particular software product that is being created as well as on the needs of the customer. Determining the right mix of maintenance and support is challenging and fraught with uncertainty, but aligning customer expectations before maintenance and support issues arise will help maintain customer satisfaction and may potentially lead to additional future funding.
It is important to maintain a copy of the source code once the development effort has ended. It is also recommended to maintain version specific source code. There are a few different source control software packages that efficiently do this. Maintaining version specific source code enables an old version to be recompiled should unanticipated issues arise after software release. Depending on the agreement with the sponsor, updates for the software product may be issued occasionally. Data updates may be required, if requested by the sponsor, for software that needs to use a current data set. This should be contractually agreed to and not implied. It is important to maintain a copy of the source code, data, installation program and executable application in a secure manner after the project is completed. Maintain security by having the project manager and the software engineer keep archival copies.
