Systems Development Life Cycle

The system development life cycle refers to 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 system development model contains all the steps required to take a project from conception to completion. See an illustration of this model in Figure 7-1.

Figure 7-1: A typical system develop-ment model takes a project from start to finish.

Read on as we take a look at each of these steps 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 iPod would read something like this: “Attractive, fits in the palm of the hand, intuitive VCR-like controls, long battery life, holds thousands of songs.”

No detail here is too specific. Conceptual is just that.

Functional requirements

Here is a list of required characteristics of the system. It’s not a design but a collection of things that the system must do. Continuing the iPod example, some functional requirements would include

• Weight: No more than 2 oz.

• Battery Life: 500 hrs

• Capacity: 100,000 songs

• Quality: DVD-audio and video quality

Still, this isn’t design-level material, but it contains more details than the conceptual definition. This is a document that Marketing or Product Concept people would come up with.

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 security requirements that the system is expected to have.

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

Functional specifications

You could call this the Engineering 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 example:

• Weight: 5.5 oz.

• Battery Life: 20 hrs

• Capacity: 20,000 songs

• Quality: DVD–quality video and audio

This is still not quite a design but rather a list of characteristics that Engineering thinks is real world. Note the compromises on weight and top speed: the people in marketing didn’t get what they wanted (100,000 songs 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, audit, integrity, and availability.

Design

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

An example would consist of engineering drawings, bills of materials (a list of all the components required to build one Apple iPod), and building instructions.

The design review is the last step in the design process, where the detailed designs are examined by a group of experts, some of whom are on the design team and some of whom are not. 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.

Coding

Coding is the phase that the software developers yearn for. Most of them would just as soon skip all previous steps 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 in which coding was 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 had better be following secure coding practices! The Open Web Applications Security Project (OWASP) has a really great set of guidelines that is generally accepted in the software industry. See the nearby sidebar for more details.

Code review

Just as in the design phase, the coding phase ends with a code review where 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, it’s good for engineers to examine their peers’ work in order to discover any mistakes that would be more costly to fix later on.

Several good tools exist that can be used to automatically identify security vulnerabilities and other errors in software code. Many organizations are using these tools to ferret out programming errors that would otherwise remain and result in vulnerabilities that may be exploitable.

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.

System test

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 is carried out here.

Of course, the system test includes testing all the system’s security functions because they were included in the test plan.

There are some great tools available that are used to rigorously test for vulnerabilities in software applications. Many organizations consider this a necessary step in system test, in order to ensure that there are no exploitable vulnerabilities.

The Open Web Applications Security Project

The Open Web Application Security Project, or OWASP, has published a short list of standards that have been adopted by organizations, most notably the Payment Card Institute and its Data Security Standard (PCI DSS). The top ten software vulnerabilities cited by OWASP are:

• Unvalidated input

• Broken access control

• Broken authentication and session management

• Cross-site scripting (XSS) flaws

• Buffer overflows

• Injection flaws

• Improper error handling

• Insecure storage

• Denial of service

• Insecure configuration management

Removal of these vulnerabilities means that a software application is more robust, reliable, and secure. You can find out more about OWASP - and even join or form a local chapter - by visiting the organization’s Web site at www.owasp.org.

Certification

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

Accreditation

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 be to offer it for sale, build and ship, or whatever put into production means in your organization.

 Tip   (ISC) ² now offers the CAP (Certified Accreditation Professional) certification for those of you who 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 bone-headed mistakes made while developing requirements and specifications. Here’s where maintenance comes alive. The Change Management and Configuration Management processes kick into play in order to maintain control of - and document all changes to - the system over its lifetime.

Good documentation in the form of those specification and design documents is important 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.

Notes about the life cycle

Larger organizations implement the software development life cycle with 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 their projects are much bigger. The seemingly expensive overhead of project management and all these reviews, approvals, and so on are intended to prevent the organization from making costly mistakes by pushing a project along too fast and possibly skipping important steps.

Because of unexpected events, projects frequently must back up one step to make corrections. For instance, in our iPod example, the marketing people wanted the iPod to contain 100,000 songs, but the engineering folks could only eke out 20,000. 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 they settle their differences, they move on.

Change Management

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

Change Management is usually performed by a Change Review Board, which has members from departments such as Development, Operations, and Customer Support, as well as other stakeholders in the organization.

 Instant Answer   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 is the mechanism that 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 these changes for each change and release of the system, and 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.

 Instant Answer   The process of recording modifications to a production environment is called Configuration Management.