In the early 1960s, application software developers realized the software development process needed some structure. Computers were becoming more numerous and the need for programmers was growing. The capabilities of hardware and software expanded. In turn, software development projects began to grow in scope. Organizations that owned computers demanded more functionality from their large investments. The increased demand for functionality required more sophisticated applications. Software developers began to collaborate to create systems of software that were made up of numerous programs that worked together.

Software development began to look like an engineering process. It needed a model to help coordinate all of the individual pieces and people involved. One emerged that is still in use in various forms today. That model is the System Development Life Cycle (SDLC). It is also known as the Software Development Life Cycle. The SDLC is a formal model for creating and modifying software. Although the SDLC has commonly been implemented as a waterfall approach in the past, many of today’s organizations implement the SDLC using agile scrum, spiral, or other methods. Regardless of the approach used, the SDLC breaks down the software development process into a number of phases with the goal of standardizing and simplifying software development management. FIGURE 14-1 shows a 10-phase SDLC model; however, many software development organizations combine several of these phases to create a simplified model with only five to seven phases.

The SDLC uses industry best practices to guide software system development activities. Software development activities have the characteristics of projects. Software projects have specific start and end dates. They also have specific deliverables. A deliverable is an object created as a result of project activities. Using the wealth of best practices from project management for software development projects is a good fit. Project management techniques help standardize the software development process. These techniques make it easier to identify problems and fix them.

The SDLC provides both control and visibility of the tasks throughout the development project. It can also increase the probability of success. The SDLC encourages the development processes to be repeated in a predictable fashion. The SDLC has been around for quite a while in different forms. It has matured and changed with system architectures, but the overriding themes have remained the same. Throughout the years, the SDLC has also been called:

• The classic life cycle model

• The linear sequential model

• The waterfall method

The most important concept in SDLC is decomposition, or breaking down a software development project into distinct phases. From a security perspective, this practice provides specific points in time. These points in time allow you to validate or test the product to ensure it meets requirements. You can never start testing too early. The earlier you validate that your deliverables satisfy the requirements for the phase you are in, the more secure the final product will be. The SDLC phases mark different activities along the development process. The 10-phase SDLC defines the following phases:

1. Initiation—This phase is where you scope and submit the initial project to management for approval and funding. If management agrees, the process is formally authorized and the process moves to the next phase.

2. System/Information Engineering and Modeling—Here you collect information about your environment and the environment’s requirements. The idea is that you document everything your computing environment has and any specific requirements or restrictions. For example, if your proposed software system requires Microsoft IIS web server and none of your servers has IIS installed, document this information. You’ll need either to change the web server requirement or install IIS. You don’t have to make decisions yet, but you’ll need these facts for later phases when making decisions. This information will provide a baseline of what your environment currently does and what must be changed to support the new or modified application.

3. Planning—You develop your project management plan in this phase. The processes include resource requirements and scheduling. The deliverables of the planning phase direct the remainder of the software project.

4. Software Requirement Analysis—You’ll document what the software must do in this phase. This includes both functionality and security requirements. Study the business needs that the software will meet. List them in terms of business functions.

5. System Analysis and Design—Once you know details about your environment and what the software must do, begin the process of designing software that will fulfill business requirements. The deliverable of this phase is a complete design document that describes the software. You haven’t written any software yet—you have just described it. Your descriptions can be formal, such as using Unified Modeling Language (UML), or informal using your own standards. The important point is that the development team clearly understands what it needs to write. This is also the last chance to ensure your project is still on track before coding begins. If there are any design documents that do not satisfy the requirements from the previous phase or do not fit with your environmental requirements, address those before continuing.

6. Code Generation—This phase is not the starting point. By this stage of the SDLC, most big decisions have already been made. Ensure that all code generated during this phase meets the design criteria from the previous phase. The code you generate in this phase should operate correctly.

7. Formal Testing—This phase is the first formal mention of testing. However, you should have been validating that each phase’s deliverables meet the requirements of the previous phase’s deliverables. Thorough validation can save a lot of wasted programming effort.

8. Implementation—The implementation phase represents the point in the project where the customer accepts the software product and the software moves into a production environment.

9. Maintenance—This is typically the last phase. It is the step after implementation. Once in the maintenance phase, there are really only two main reasons to modify the application. One reason to modify the application is enhancement request. The only other reason to modify the application is to fix a bug. In either of these situations, the correct approach is to return to Step 1 and go through the whole process again. However, you don’t start from scratch. This time, you have all of the deliverables from the previous phases. You simply start with a description of what you want to change, and then go through each phase until you end up with modified code. By ensuring that even code fixes meet the application’s design goals, you avoid many of the situations where a fix breaks something else. It takes a little longer, but you save time and money by not chasing as many bugs later.

10. Disposition—This phase represents the activities related to retiring a software product and cleansing any hardware of sensitive data. In nearly all cases, plan to either archive application data or transfer it to another system. The disposition phase addresses all of the activities that reverse the actions in the implementation phase. By the end of this phase, you have completely removed all of your sensitive data from any hardware or devices that may be sold or recycled.

The SDLC formalizes the development process. This process also keeps you from jumping ahead and writing code that doesn’t satisfy requirements. Don’t make the mistake of allowing your team to start the project by writing code. You will almost always end up either ditching or rewriting at least parts of software you develop without planning. Some development approaches rely on prototyping at the beginning of projects. Even in these cases, though, you should have already put plans in place for ensuring any code is secure. Any time your software has to interact with other system components, carefully decide how it should operate. That requires time to make decisions before writing code.

Keep two important points in mind when following the SDLC. One, precede the code generation phase with several iterations of modeling and design. Two, validate each phase’s deliverables. By the time you reach the code generation phase, make certain you have substantial documentation on the software’s purpose, requirements, and design. It should be fairly easy to validate whether or not software written in this phase satisfies the system design.

Each phase has defined deliverables. A phase in the SDLC ends when the project team has accepted the deliverables for that stage. Deliverables are up to standard when they satisfy all of the goals, including security goals. Each phase generally culminates with a meeting of the project team to review the phase’s deliverables. When the team agrees that the deliverables are valid, the phase ends and the project moves to the next step. Phase validation and testing should identify any areas in your project where you have deviated from the prior phase’s deliverables. Make sure that the deliverables for each phase satisfy all preceding deliverables. Testing at every phase ensures that your team will quickly spot any variances from the stated design. Early detection of problems allows you to fix the problems with the minimum cost and disruption to the project.