System Development Life Cycle
Quickstudy by Russell Kay from Computerworld∞
System Development Life Cycle (SDLC) is the overall process of developing information systems through a multistep process from investigation of initial requirements through analysis, design, implementation and maintenance. There are many different models and methodologies, but each generally consists of a series of defined steps or stages.
Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.
To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.
The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:
Project planning, feasibility study:
Establishes a high-level view of the intended project and determines its goals.
Systems analysis, requirements definition:
Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
The real code is written here.
Integration and testing:
Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment:
The final stage of initial development, where the software is put into production and runs actual business.
What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.
But It Doesn't Work!
The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."
Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.
The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.
The spiral model emphasizes the need to go back and reiterate earlier stages a number of times as the project progresses. It's actually a series of short waterfall cycles, each producing an early prototype representing a part of the entire project. This approach helps demonstrate a proof of concept early in the cycle, and it more accurately reflects the disorderly, even chaotic evolution of technology.
Build and fix is the crudest of the methods. Write some code, then keep modifying it until the customer is happy. Without planning, this is very open-ended and can by risky.
In the rapid prototyping (sometimes called rapid application development) model, initial emphasis is on creating a prototype that looks and acts like the desired product in order to test its usefulness. The prototype is an essential part of the requirements determination phase, and may be created using tools different from those used for the final product. Once the prototype is approved, it is discarded and the "real" software is written.
The incremental model divides the product into builds, where sections of the project are created and tested separately. This approach will likely find errors in user requirements quickly, since user feedback is solicited for each stage and because code is tested sooner after it's written.
Big Time, Real Time
The synchronize and stabilize method combines the advantages of the spiral model with technology for overseeing and managing source code. This method allows many teams to work efficiently in parallel. This approach was defined by David Yoffie of Harvard University and Michael Cusumano of MIT. They studied how Microsoft Corp. developed Internet Explorer and Netscape Communications Corp. developed Communicator, finding common threads in the ways the two companies worked. For example, both companies did a nightly compilation (called a build) of the entire project, bringing together all the current components. They established release dates and expended considerable effort to stabilize the code before it was released. The companies did an alpha release for internal testing; one or more beta releases (usually feature-complete) for wider testing outside the company, and finally a release candidate leading to a gold master, which was released to manufacturing. At some point before each release, specifications would be frozen and the remaining time spent on fixing bugs.
Both Microsoft and Netscape managed millions of lines of code as specifications changed and evolved over time. Design reviews and strategy sessions were frequent, and everything was documented. Both companies built contingency time into their schedules, and when release deadlines got close, both chose to scale back product features rather than let milestone dates slip.
ISO 12207 and Related Software Life-Cycle Standards
by Jim Moore, The MITRE Corporation, firstname.lastname@example.org
This note describes ISO 12207, a high-level standard addressing all
processes of the software life cycle. It also traces the evolution of life-cycle
standards, differentiates the efforts of IEEE, ISO, and other organizations,
and discusses the significance of 12207 to international software acquisition.
The Institute of Electrical and Electronics Engineers (IEEE) is now
voting on whether the U.S. should adopt International Organization for
Standardization (ISO) 12207, which specifies software life-cycle processes.
Because of the burgeoning of standards over the last few years, it is important
that software engineers understand what 12207 provides and how it relates
to other standards dealing with life-cycle processes.
Overview of ISO 12207
ISO 12207 offers a framework for software life-cycle processes from
concept through retirement. It is especially suitable for acquisitions
because it recognizes the distinct roles of acquirer and supplier. In fact,
the standard is intended for two-party use where an agreement or contract
defines the development, maintenance, or operation of a software system.
It is not applicable to the purchase of commercial-off-the-shelf (COTS)
In most cases, 12207 uses conventional standards language: "shall"
to indicate mandatory provisions, "should" for recommendations,
and "may" for permissible actions. Since the standard applies
to both acquirer and supplier, one might expect it to place mandatory requirements
upon both parties. Its language, however, makes a subtle distinction: those
provisions that apply to the acquirer typically use the verb "will,"
denoting a "declaration of purpose or intent by one party," not
ISO 12207 provides a structure of processes using mutually accepted
terminology, rather than dictating a particular life-cycle model or software
development method. Since it is a relatively high-level document, 12207
does not specify the details of how to perform the activities and tasks
comprising the processes. Nor does it prescribe the name, format, or content
of documentation. Therefore, organizations seeking to apply 12207 may want
to use additional standards or procedures that specify those details.
The ISO is currently developing such guides and assessment procedures
to complement 12207; the IEEE Software Engineering Standards Committee
is also planning to reorganize its collection of standards to complement
ISO 12207 describes five "primary processes"-- acquisition,
supply, development, maintenance, and operation. It divides the five processes
into "activities," and the activities into "tasks,"
while placing requirements upon their execution. It also specifies eight
"supporting processes"--documentation, configuration management,
quality assurance, verification, validation, joint review, audit, and problem
resolution--as well as four "organiza-tional processes"--management,
infrastructure, improvement, and training.
The ISO standard intends for organizations to tailor these seventeen
processes to fit the scope of their particular projects by deleting all
inapplicable activities; and it defines 12207 compliance as the performance
of those processes, activities, and tasks selected by tailoring.
The Evolution of Life-Cycle Standards
The Department of Defense is a pioneer in defining software development
life cycles. In the last few years, the DoD undertook an effort to unify
DoD-STD-2167A (used by the mission-critical community) and MIL-STD-7935
(used by the information systems community) to create one life-cycle standard--MIL-STD-498.
Just as 498 was nearing approval, however, the DoD shifted its acquisition
policies toward more reliance on commercial standards. As a result, 498
was approved for an interim period of only two years. The IEEE and the
Electronics Industry Association (EIA) then initiated a joint project to
create a commercial replacement for 498. This effort produced one standard
with two names: an IEEE Trial Use Standard 1498 and an EIA Interim Standard
640. Since both the IEEE and the EIA produced the standard, the American
National Standards Institute (ANSI) designated the document as ANSI Joint
Meanwhile, ISO 12207 was also underway. Whereas J-016 defined only the
development process, 12207 described four additional primary processes,
as discussed above. Furthermore, in 1992, the IEEE had completed its own
life-cycle process standard, 1074, providing detailed descriptions of development
and maintenance activities as well as their connections. In principle,
one could use 1074 to construct processes that would comply with the requirements
of either J-016 or 12207. The challenge now is to "harmonize"
or otherwise converge these three different documents. Two current efforts
will accomplish this goal.
First, the IEEE is balloting on the U.S. Adoption of ISO 12207. A yes
vote would provide a common basis of understanding for organizations who
wish to acquire software across international boundaries. Some parties
contend that 12207 is essential if the U.S. is to play a role in worldwide
Second, the IEEE and the EIA are collaborating on another joint standard--the
"U.S. Industrial Implementation" of 12207--which will be structured
around the process framework of 12207 but add the "technical goodness"
of J-016 to the development process. This standard will be useful for defense,
commercial, and international acquisitions.
The new joint standard is scheduled for completion in December 1996.
The results of this effort will then guide the planned revisions to 12207
and 1074, creating a harmonized pair of standards: the former specifying
requirements for the software life cycle and the latter specifying how
to construct a life-cycle model.