¶ … system development life cycle (SDLC) approach to the development of Information Systems and/or software is provided. An explanation of SDLC is offered, with different models applied in implementing SDLC delineated. Advantages and disadvantages associated with each of the models will be identified. System Development Life Cycle

According to Walsham (1993), system development life cycle (SDLC) is an approach to developing an information system or software product that is 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 basically a project management tool that is used to plan, execute, and control systems development projects (Whitten & Bentley, 1998). System development life cycles are usually discussed in terms of the 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 and its general ability levels, and many other factors. There should not be any standard life cycle because companies are unique (Whitten & Bentley, 1998).

As suggested by Whitten and Bentley (1998), most SDLC's have five major categories. These categories include:

Planning

Analysis

Design

Implementation

Support

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 in completing the system. Walsham (1993) delineated the steps in the Waterfall Model, including include the following:

An initial evaluation of the existing system is conducted and deficiencies are then 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 then trained in its use, and all aspects of performance are tested. If necessary, adjustments must be 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, and 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 is up and running for awhile, 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 go back to the previous step, or the specific step in which the problem occurred, and "fix" the problem by completing the step once more. The Waterfall Model was given its name based of the visual appearance of the schedule associated with the model. Figure 1 provides a visual depiction of the model's development schedule.

Figure 1: Waterfall Model

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

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

Thus many other SDLC models have been developed.
Survivable Systems Analysis Model

With the growing recognition that information systems (IS) play a major role in insuring the success of virtually all organizations in business, government, and defense, awareness has also increased that such success is dependent on the availability and correct functioning of large-scale networked information systems of involving extensive complexity (Whitten & Bentley, 1998). Consequently, the SDLC model has become the context for further development of IS development requirements that focus on system survivability (i.e., 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. As further clarified by the Institute, survivability moves beyond the realm of security and fault tolerance with a focus on delivery of essential services. On the basis of a survivability perspective, the delivery of essential services remains critical, even when systems are penetrated and/or experience failures, and rapid recovery of full services 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 insuring three key capabilities of IS: resistance, recognition, and recovery. Therefore, as outlined by CMSEI, IS requirements for development and implementation are those which help to insure that the final product has the following capabilities in order to be successful:

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 attack, limit the extent of damage, and restore full services following attack.

CMSEI (2002) has developed an ISD approach, the Survivable Systems Analysis (SSA) method (formerly the Survivable Network Analysis method) that focuses on the application of requirements in development and implementation to insure 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. As delineated by the Institute, the SSA process is composed of four steps, as follows:

Step One: System Definition: developing an understanding of mission objectives, requirements for the current or new system, structure and properties of the system architecture, and risks in the operational environment.

Step Two: Essential Capability Definition: identification of (as based on mission objectives and failure consequences) essential services (i.e., services that must be maintained during attack) and essential assets (i.e., assets whose integrity, confidentiality, availability, and other properties must be maintained during attack) as characterized by usage scenarios, which are 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 (components 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 the production of a survivability map that enumerates, for every intrusion scenario and corresponding compromised component effects, the current and recommended IS architecture strategies for resistance, recognition, and recovery.

As suggested by Center for Technology in Government (CTG) (1998), while the SDLC has been used extensively, it has a number of associated problems. According to CTG, SLDC has been criticized due to rigid design and inflexible procedure. Consequently, as addressed by CTG, SDLC fails to account for the fact that real projects rarely follow the sequential flow that the model proposes. Because the SDLC model is a sequential process, any variations in its process create problems for the developer. As well, as identified by CTG, most ISD projects experience a great deal of uncertainty about requirements and goals in the beginning phase of the project, and it is therefore difficult for customers to identify these criteria on a detailed level. The SDLC model does not accommodate this natural uncertainty very well. The end 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. Thus, such criticisms…