The System Development Life Cycle

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.
Systems design: Describes desired features and operations in detail, including
screen layouts, business rules, process diagrams, pseudocode and other
documentation.
Implementation: 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.
Maintenance: What happens during the rest of the software's life: changes,
correction, additions, and moves to a different computing platform and more.
This, the least glamorous and perhaps most important step of all, goes on
seemingly forever.
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, and 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.
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.

What prompts a new system?

Reasons for introducing a new system may be:
The current system may be no longer suitable for its purpose.
Technological developments may have made the current system redundant or
outdated.
The current system may be too inflexible or expensive to maintain.

Feasibility Study
This is the first stage of the systems life cycle. The scope and objectives of the proposed
system must be written down. The aim of the feasibility study is to understand the
problem and to determine whether it is worth proceeding. There are five factors to be
considered:
Technological
Economic
Legal
Operational
Schedule
The completion of this stage is marked by the production of a feasibility report produced
by the systems analyst. If the report concludes that the project should go ahead, and this
is agreed by senior managers, detailed requirements analysis will proceed.

Analysis/Requirements analysis
The second phase of systems analysis is a more detailed investigation into the current
system and the requirements of the new system.
Gathering details about the current system may involve:
Interviewing staff
Examining current business and systems documents and outputs
Sending out questionnaires and analyzing responses
Observation of current procedures
During the analysis phase various diagrams are created to depict different aspects of the
system. These include:
Data Flow Diagrams
Entity-Relationship Diagrams
Computer Aided Software Engineering (CASE) tools

System Design
The design specifies the following aspects of a system:
The hardware platform which type of computer, network capabilities, input,
storage and output devices.
The software programming language, package or database.
The outputs report layouts and screen designs.
The inputs documents, screen layouts and validation procedures.
The user interface how users will interact with the system.
The modular design of each program in the application.
The test strategy, test plan and test data.
Conversion plan how the new system is to be implemented.
Documentation including systems and operations documentation. Later, a user
manual will be produced.
System Specification - The system specification must describe how the new
system will work. Screen layouts and reports must be designed; file content and
organization specified, and each program in the system must be described by
means of program specification, structure charts, pseudocode or flowcharts. The
programmer then codes, tests and debug the programs.
Program Design Methods structured charts and algorithms
Prototyping - building a working model of a new system in order to evaluate it,
test it or have it approved before building the final product.
Choosing a software solution The criteria on which the final choice is based
will include; usability, performance, suitability and maintainability.
Testing Strategies Dry run using a trace table, unit testing and integration
testing.
Test Plan and test data A test plan needs to be drawn up for each program in a
system and is usually in the form of a trace table showing each item that needs to
be tested. It should cover every possible type of input including values that are too
long, too small or invalid for other reasons such as an alphabetic character being
entered instead of a number. The test plan needs to show each test and what the
expected results should be.
Technical documentation This helps to ensure that a system can be maintained
after completion. It is essential that proper documentation is kept to enable a
newcomer to make necessary corrections, alterations or enhancements.

 Contents of a documented system

o an accurate and up-to-date systems specification:
o Data Flow Diagrams showing the inputs to the system, files required,
processes to be carried out and output from the system;
o a description of the purpose of each program within the system;
o a structure diagram, flowchart or pseudocode for each program in the
system;
o organization, contents and layout of each file used;
o layout and contents of all output prints and displays;
o current version of each program listing;
o test data and expected results.

System Implementation
This phase includes both the coding and testing of the system, the acquisition of hardware
and the installation of the new system or conversion of the old to the new one.
The installation phase can include:
installing the new hardware, which may involve extensive recabling and
changes in office layouts;
training the users on the new system;
conversion of master files to the new system, or creation of new master files.

System Evaluation
A new system when completed must be evaluated to ensure that it meets the users
original specifications and is satisfactory in all aspects.
Minor programming errors may have to be corrected, clerical procedures amended, or
modifications made to the design of reports or screen layouts.
The system is evaluated in terms of:
Effectiveness does it do what it is supposed to do?
Usability is it easy to use?
Maintainability will it be easy to maintain?

Often it is only when people start to use the new system that they realize its
shortcomings. In some cases they may realize that it would be possible to get even more
useful information from the system than they realize, and more programs may be
requested. The process of system maintenance, in fact, has already begun, and the life
cycle is complete.

System Maintenance
All system requires maintenance, and in fact the vast majority of programmers are
employed to maintain existing programs rather than to write new ones.
Types of maintenance:
Perfective
Adaptive
Corrective