Systems Development Life Cycle

The systems development life cycle (SDLC, often called the software development life cycle) refers to all the steps required to develop a system from conception through implementation, support, and (ultimately) retirement. In other words, we mean the entire life of a system, from birth to death.

The life cycle is a development process designed to achieve two objectives: a system that performs its intended function correctly and securely, and a development project that’s completed on time and on budget.

A typical waterfall model of system development contains all the steps required to take a project from conception to completion. See an illustration of the waterfall model in Figure 7-3. (We describe other models in the section “Other systems development life cycle models,” later in this chapter.)

The waterfall model is so-called because its steps progress like a series of waterfalls. And in a software development project performed using the waterfall model, each of the stages is performed sequentially, one at a time.

In the following sections, we take a look at each of the steps of the waterfall model in detail to understand what happens in each.

Conceptual definition

Conceptual definition is a high-level description of a system. It generally contains no details — it’s the sort of description that you want to give to the business and finance people (you know, those folks who fund your projects and keep you employed). You don’t want to scare them with details.

A typical conceptual definition for the Apple iPad would read something like this: “Attractive, sleek tablet computer, touch-screen controls, crisp high-resolution display, long battery life, holds a wide variety of content that is all sold by Apple.”

No detail here is too specific. Conceptual is just that — describing the concept.

Functional requirements

Functional requirements are basically a list of required characteristics of the system. Rather than a design, the functional requirements are a collection of things that the system must do. Continuing the iPad example, some functional requirements would include

Weight: No more than 1 pound

Connectivity: Connects to Internet via WiFi, Bluetooth, Wireless USB, WiMax, and 3G cellular

Battery life: 200 hours

Capacity: 200 GB of data

Quality: DVD-quality audio and video

Although functional requirements don’t give you design-level material, this description contains more details than the conceptual definition. The Marketing or Product Concept people come up with these sorts of ideas.

Functional requirements usually include a test plan, which is a detailed list of characteristics of the system that must be tested. The test plan describes how each test should be performed and also what the expected results should be. Generally you have at least one test in the test plan for each requirement in the functional requirements.

Functional requirements must contain expected security requirements for the system.

A proposed system’s list of desired features is its functional requirements.

Functional specifications

You could call the functional specifications the Engineering department’s version of functional requirements. Rather than a list of have-to-have and nice-to-have items, the functional specification is more of a what-it-is (we hope) or a what-we-think-we-can-build statement. Continuing our iPad example:

Weight: 1.5 pounds

Connectivity: WiFi, Bluetooth, GSM 3G cellular

Battery life: 10 hours of video playback, 150 hours of audio playback

Capacity: 8 GB to 64 GB of data

Quality: DVD-quality video and audio

Functional specifications aren’t quite a design, but rather a list of characteristics that Engineering thinks they can create in the real world. Note the compromises on weight and top speed from the preceding section’s functional requirements: The people in Marketing didn’t get what they wanted (64GB storage capacity and 500 hours of battery life), but then, those folks never do.

From a security perspective, the functional specifications for an operating system or application should contain all the details about authentication, authorization, access control, confidentiality, transaction auditing, integrity, and availability.

Design

Design is the process of developing highest-detail designs. In the application software world, design includes entity-relationship diagrams, data-flow diagrams, database schemas, over-the-wire protocols, and more.

For example, an iPad design review would consist of engineering drawings, bills of materials (a list of all the components required to build one Apple iPad), and building instructions.

Design review

The design review is the last step in the design process, in which a group of experts (some of whom are on the design team and some of whom aren’t) examine the detailed designs. Those not on the design team give the design a set of fresh eyes and a chance to maybe catch a design flaw or two.

By the time a project is in the design review stage, the marketing people who came up with those wild and crazy specifications are getting a dose of reality; engineers who work on detailed designs sometimes have to “dial back” those initial wish-list specs to something that can actually be built.

Coding

Coding is the phase that the software developers yearn for. Most of them would prefer to skip all the preceding steps (described in the preceding sections) and start coding right away — even before the product people have a chance to develop formal requirements. It’s scary to think about how much of the world’s software was created with coding as the first activity. (Would you fly in an airplane that the machinists built before the designers could produce engineering drawings?)

Coding usually includes unit testing, which is the process of verifying all the modules that are built in this phase.

Software developers need to follow secure coding practices! The Open Web Application Security Project (OWASP, at www.owasp.org ) has a really great set of guidelines that members of the software industry generally accept. See the sidebar “The Open Web Applications Security Project,” in this chapter, for more details.

Code review

As in the design phase (discussed in the section “Design review,” earlier in this chapter), the coding phase ends with a code review in which a bunch of prima donna engineers examine each other’s program code and get into religious arguments about levels of indenting and the correct use of curly braces. Seriously, though, during code review, engineers can discover any mistakes that would cost you a lot of money if you had to fix them later in the implementation process or in maintenance mode.

Several good tools exist that you can use to automatically identify security vulnerabilities and other errors in software code. Many organizations use these tools to ferret out programming errors that would otherwise remain and result in vulnerabilities that attackers might exploit.

Unit test

When portions of an application have been developed, it’s often possible to test the pieces separately. This is called unit testing. Unit testing allows a developer or tester to verify the correct functioning of individual modules in an application.

Unit testing is usually done during coding, and doesn’t always show up as a separate step in process diagrams.

System test

A system test occurs when all the components of the entire system have been assembled, and the entire system is tested from end to end. The test plan that was developed back in the functional requirements step (see the section “Functional requirements,” earlier in this chapter) is carried out here.

Of course, the system test includes testing all the system’s security functions because the program’s designers included those functions in the test plan.

You can find some great tools available for rigorously testing for vulnerabilities in software applications. Many organizations consider use of such tools a necessary step in system tests so that they can ensure the system has no exploitable vulnerabilities.

Certification & accreditation

Certification is the formal evaluation of the system. The system is declared fully functional. Every intended feature performs as planned.

Accreditation is a five-dollar word that means the people in the mahogany offices have said that it’s okay to put the system into production. That could mean to offer it for sale, build it and ship it, or whatever put into production means in your organization.

(ISC)² now offers the Certification and Accreditation Professional (CAP) certification, which you might consider if you want to take accreditation to the next level in your career.

Maintenance

At this point, the system is in production, and now its customers start putting in change requests because of a bunch of boneheaded mistakes made while developing requirements and specifications. Here’s where maintenance comes alive. The Change Management and Configuration Management processes (see the following sections) kick into play in order to maintain control of — and document all changes to — the system over its lifetime.

You need good documentation, in the form of those original specification and design documents, because the developers who wrote this system have probably moved on to some other cool project . . . and the new guys who don’t know beans are left to maintain it.

Change Management

Change Management is the formal business process that ensures all changes made to a system receive formal review and approval from all stakeholders before implementation. Change Management gives everyone a chance to voice their opinions and concerns about any proposed change so that the change goes as smoothly as possible, with no surprises or interruptions in service.

A Change Review Board — which has members from departments such as Development, Operations, Customer Support, and Security as well as other stakeholders in the organization — usually performs Change Management.

The process of approving modifications to a production environment is called Change Management.

Configuration Management

Often confused with Change Management (and vice versa), Configuration Management has little to do with approvals but everything to do with recording all the facts about the change. Configuration Management captures actual changes to software code, end-user documentation, operations documentation, disaster recovery planning documentation, and anything else that’s affected by the change. Configuration Management archives technical details for each change and release of the system, as well as for each instance of the system, if more than one instance exists.

Change Management and Configuration Management address two different aspects of change in a system’s maintenance mode. Change Management is the what, and Configuration Management is the how.

The process of managing the changes being made to systems is called Change Management. The process of recording modifications to a production environment is called Configuration Management.

Notes about the life cycle

Larger organizations implement the system development life cycle by using a complex, formal process. Each step in the process contains its own steps, actions, deliverables, reviews, approvals, and recordkeeping. A formal process dictates knowing what step a project is in (product concept, functional requirements, functional specs, design, and so on), as well as whether a project is allowed to pass from one step to the next.

Large organizations implement such processes because they have such big projects. The seemingly expensive overhead of project management and all these reviews, approvals, and so on hopefully prevent the organization from making costly mistakes that might occur if they pushed a project along too fast and possibly skipped important steps.

Because of unexpected events, projects frequently must back up one step to make corrections. For instance, in the iPad example we use in the preceding sections, the Marketing people wanted the iPad to contain 200 GB of memory, but the Engineering folks could eke out only 64 GB and stay within budget. Such a discrepancy would trigger a return to the functional-requirements step to get the Marketing people back to Earth and get the functional requirements to align with realistic functional specifications. After the two groups settle their differences, they can move on to other projects with more experience through lessons learned.

Other models of the system development life cycle

We spend a lot of time describing the traditional waterfall life cycle in the preceding sections. The waterfall model is a comprehensive process that includes a lot of up-front planning and design to ensure that the actual development portion of it (the coding that developers always seem to want to start too soon) is done right. For all the integrity that the waterfall model provides, you can’t say that it’s a time-friendly approach to software development.

The waterfall model was developed back in the mainframe-computing era when a typical larger software development project could take two years. When breakthroughs in software development technology began in the 1980s, so too did the need to make the actual process of software development more efficient (timewise). So some other models — RAD (Rapid Application Development), Spiral, and Scrum, for example — have appeared that allow an organization to get software developed quickly.

Security principles in software development

No matter what development model is used, these principles are important in order to ensure that the resulting software is secure:

Security in the requirements: Even before the developers design the software, the organization should determine what security features the software needs. This set of security requirements should range from thorough input field validation to authentication and access controls. If security is absent from requirements, it’s likely to be absent in the design and implementation as well.

Security in the design: The design of an application should include security features, ranging from vigorous input checking, strong authentication, audit logs, and privacy.

Security in testing: An organization needs to test all the security requirements and design characteristics before declaring the software ready for production use. All test scripts and test results should be archived for later use, if needed. Automated tools should be used to test source code for security vulnerabilities and other types of defects.

Security in the implementation: New applications need to be implemented on secure, hardened servers, and done in a way so that programmers do not have access to the production environment. If data was migrated from an older application, this migration must be done carefully so that security of any sensitive data is not compromised.

Ongoing security testing: After an application is implemented, security testing should be performed regularly, in order to make sure that no new security defects are introduced into the software. Also, because new security holes are discovered all the time, it is possible (and even likely) that a program that is secure at the beginning will be less secure in the future, because of these vulnerabilities that are discovered (and were always there).

When an organization makes security a part of a new application’s design, that application is likely to experience far fewer security problems later on.