This paper provides a comprehensive overview of the System Development Life Cycle (SDLC) as an approach to developing information systems and software. It explains the foundational concept of SDLC and examines several key models used in its implementation, including the Waterfall Model, the Survivable Systems Analysis Model, the Prototyping Model, the Exploratory Model, the Spiral Model, and the FAST Methodology. For each model, the paper identifies associated advantages and disadvantages. The PIECES framework and documentation best practices are also discussed. The paper draws on established literature to highlight how SDLC models have evolved in response to the limitations of earlier sequential approaches.
This study guide is drawn from PaperDue's library of 130,000+ paper examples across 47 subjects.
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:
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:
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.
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:
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:
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.
"Alternative models addressing SDLC flexibility limitations"
"Eight-phase FAST method and problem classification tool"
"Documentation standards and formal SDLC benefits"
Always verify citation format against your institution’s current style guide requirements.