System Development Life Cycle: Models and Methodologies

Introduction to System Development Life Cycle

According to Walsham (1993), the system development life cycle (SDLC) is an approach to developing an information system or software product characterized by a linear sequence of steps that progress from start to finish without revisiting any previous step. The SDLC model is one of the oldest systems development models and is still probably the most commonly used (Walsham, 1993). The SDLC model is essentially a project management tool used to plan, execute, and control systems development projects (Whitten & Bentley, 1998). System development life cycles are usually discussed in terms of conventional development using the Waterfall Model or the prototyping development Spiral Model. It is important to understand that these are just models; they do not represent the total system (Whitten & Bentley, 1998). Models reflect the structure of the organization, its management style, the relative importance it attaches to quality, timeliness, cost, and benefit, its experience, its general ability levels, and many other factors. There should not be any single standard life cycle because companies are unique (Whitten & Bentley, 1998).

As suggested by Whitten and Bentley (1998), most SDLCs have five major phases:

• Planning
• Analysis
• Design
• Implementation
• Support

The Waterfall Model

The Waterfall Model represents a traditional type of SDLC. It builds upon the basic steps associated with SDLC and uses a "top-down" development cycle to complete the system. Walsham (1993) delineated the steps in the Waterfall Model as follows:

• An initial evaluation of the existing system is conducted and deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
• The new system requirements are then defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
• The proposed system is designed. Plans are developed and delineated concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
• The new system is developed, and the new components and programs are obtained and installed.
• Users of the system are trained in its use, and all aspects of performance are tested. If necessary, adjustments are made at this stage.
• The system is put into use. This can be done in various ways. The new system can be phased in according to application or location, with the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
• Once the new system has been running for some time, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times.
• Users of the system should be kept up to date concerning the latest modifications and procedures.

On the basis of the Waterfall Model, if system developers find problems associated with a step, an effort is made to return to the previous step — or the specific step in which the problem occurred — and correct the problem by completing that step again. The Waterfall Model was given its name based on the visual appearance of the schedule associated with the model.

According to Walsham (1993), a number of advantages have been identified in relation to the Waterfall Model. One advantage is that the model relies on the creation of a System Specification Document (SSD) that allows the cost and schedule of the system to be known once the SSD is created. Additionally, the model provides extensive documentation for companies that require it and has a long history of success in the computer industry.

Disadvantages identified by Walsham (1993) in relation to the Waterfall Model include that changes to contracts and costs must be renegotiated if such changes are made after construction has begun. Users must also wait until the end of the project — or until at least a major portion of it is complete — before observing results. Finally, the early phases of the project often take much longer due to the time required to generate the detail necessary in the SSD. According to Kay (2002), another major problem associated with the Waterfall Model is that it assumes the only role for users is in specifying requirements, and that all requirements can be specified in advance. However, as Kay explains, requirements emerge and change throughout the process and during later maintenance phases, leading to the need for ongoing feedback and iterative consultation. As a result, many other SDLC models have been developed.

Survivable Systems Analysis Model

With the growing recognition that information systems (IS) play a major role in ensuring the success of virtually all organizations in business, government, and defense, awareness has also increased that such success depends on the availability and correct functioning of large-scale networked information systems of extensive complexity (Whitten & Bentley, 1998). Consequently, the SDLC model has become the context for further development of IS requirements that focus on system survivability — that is, end products that survive (Carnegie Mellon Software Engineering Institute, 2002).

As delineated by the Carnegie Mellon Software Engineering Institute (CMSEI) (2002), survivability is the capability of a system to fulfill its mission in a timely manner, even in the presence of attacks or failures. Survivability moves beyond the realm of security and fault tolerance with a focus on the delivery of essential services. From a survivability perspective, the delivery of essential services remains critical even when systems are penetrated or experience failures, and rapid recovery of full services is required when conditions improve (CMSEI, 2002). According to the Institute, survivability addresses highly distributed, unbounded network environments that lack central control and unified security policies.

According to CMSEI (2002), the focus of IS development when survivability is a critical component is on ensuring three key capabilities:

• Resistance: the capability of a system to repel attacks.
• Recognition: the capability of a system to detect attacks as they occur and to evaluate the extent of damage and compromise.
• Recovery: the capability of the system to maintain essential services and assets during an attack, limit the extent of damage, and restore full services following an attack.

CMSEI (2002) developed an IS development approach called the Survivable Systems Analysis (SSA) method (formerly the Survivable Network Analysis method) that focuses on applying requirements in development and implementation to ensure an end product capable of survivability. According to the Institute, SSA is a practical engineering process that permits systematic assessment of the survivability properties of proposed systems, existing systems, and modifications to existing systems. The SSA process is composed of four steps:

• Step One — System Definition: developing an understanding of mission objectives, requirements for the current or new system, the structure and properties of the system architecture, and risks in the operational environment.
• Step Two — Essential Capability Definition: identification, based on mission objectives and failure consequences, of essential services (services that must be maintained during an attack) and essential assets (assets whose integrity, confidentiality, availability, and other properties must be maintained during an attack), as characterized by usage scenarios traced through the architecture to identify essential components whose survivability must be ensured.
• Step Three — Compromisable Capability Definition: selection of intrusion scenarios based on assessment of environmental risks and intruder capabilities, and identification of corresponding compromisable components — those that could be penetrated and damaged by intrusion.
• Step Four — Survivability Analysis: analysis of IS components and the supporting architecture for the key survivability properties of resistance, recognition, and recovery; and production of a survivability map that enumerates, for every intrusion scenario and corresponding compromised component, the current and recommended IS architecture strategies for resistance, recognition, and recovery.

As suggested by the Center for Technology in Government (CTG) (1998), while the SDLC has been used extensively, it carries a number of associated problems. The SDLC has been criticized for its rigid design and inflexible procedure. Consequently, SDLC fails to account for the fact that real projects rarely follow the sequential flow the model proposes. Because the SDLC model is a sequential process, any variations create problems for the developer. Additionally, most IS development projects experience a great deal of uncertainty about requirements and goals in the beginning phases, making it difficult for customers to identify these criteria at a detailed level. The SDLC model does not accommodate this natural uncertainty well. The result is that implementation of the SDLC model can be a long, painstaking process that fails to provide a working version of the system until late in the process. Such criticisms led to alternative SDLC processes that offer faster results, require less up-front information, and provide greater flexibility.