are several different ways to divide the work that takes place in the
development of an application. The work breakdown in general comprises the
project's life cycle. If you asked five SEs to describe the life cycle of a
typical computer application, you would get five overlapping but different
should remember from systems analysis that a sequential project life cycle (SPLC) starts when a software product
is conceived and ends when the product is no longer in use. Phases in a SPLC
SPLC phases are more appropriate to business than to military/government
applications because, in the government, the first four phases (initiation'
definition, feasibility, and functional requirements definition) are usually
completed by a different organization than that of the implementers. Government
projects are subject to congressional review, approval, and budgeting. So, a
government project requiring congressional appropriation is usually defined as
beginning at the conceptual design phase and ending with deployment of the
system with operational status according to Department of Defense standard
#2167a [DOD, 1985]. In contrast, business IS are typically initiated by a user
department requesting that a system be built by an MIS department. The need for
an IS is typically motivated by some business situation: a change in the method
of business, in the legal environment, in the staffing/support environment, or
in a strategic goal such as improving market competitiveness.
call these SPLC phases a 'Waterfall' approach to applications because the
output of each phase feeds into the next phase, while phases are modified via
feedback produced during the verification and validation processes. Phases in
the waterfall definition are defined as discrete even though, in practice, the
information is obtained in a nonlinear manner and the phase beginnings and
endings are difficult to distinguish. To identify discrete beginnings and
endings, most companies use the completion of the major product (i.e., program
or document) produced during each phase as signaling the phase end. So,
completion of a feasibility report, for instance, identifies the end of the
feasibility analysis phase. In the following subsections, each phase of the
project life cycle (SPLC) is defined, with the main activities and documents
INITIATION. Project initiation is the period of time during which the need for an
application is identified and the problem is sufficiently defined to assemble a
team to begin problem evaluation. The people and organizations affected by the
application, that is, the stakeholders,
are identified. Participants from each stakeholder organization for the
development team are solicited. The outcome of initiation is a memo or formal
document requesting automation support and defining the problem and
FEASIBILITY. Feasibility is the analysis of risks, costs and benefits relating
to economics, technology, and user organizations. The problem to be automated
is analyzed in sufficient detail to ensure that all aspects of feasibility are
evaluated. Economic feasibility analysis elaborates costs of special hardware,
software, personnel, office space, and so forth for each implementation
In technical feasibility analysis,
alternatives for hardware, software, and general design approach are determined
to be available, appropriate, and functional. The benefits and risks of
alternatives are identified.
Organizational feasibility is an analysis of
both the developing and using organizatiop.s' readiness for the application.
Particular emphasis is placed on skills and training needed in both groups to
ensure successful development and use of the application. The decision whether
or not to use consultants and the type of role they would play during
development is made during organizational feasibility analysis. Organizational
decisions include effectiveness of the organization structure and definition of
roles of individual jobs in the organization as they will be with the new
application. The feasibility report summarizes
economic, technical and organizational feasibility
risks and contingency plans related to the application
concept for the software product and an explanation of its superiority to
needs and tentative schedules
of project staffing by phase and level of expertise
feasibility is established, the Software
Development Life Cycle (SDLC), a subcycle of the SPLC, begins. This
subcycle typically includes phases for analysis, conceptual design, design,
implementation, testing, and installation and checkout. SDLC end is signaled by
delivery of an operational application.
ANALYSIS. The analysis phase has many synonyms: Functional Analysis, Requirements
Definition, and Software Requirements Analysis. All of these names represent
the time during which the business requirements for a software product are
defined and documented. Analysis activities define
requirements-"what" the system is supposed to do. The format of the
functional requirements definitions depends on the methodology followed during
the analysis phase.
requirements-terminal, message, or network response time, input/output volumes,
process timing requirements (e.g., reports must be available by 10 A.M.).
requirements-what data come from and go to other using applications and organizations.
The definition includes timing, media, and format of exchanged data.
requirements-information learned during analysis that may impact design
activities. Examples of design requirements are data storage, hardware, testing
constraints, conversion requirements, and humanmachine interaction requirements
(e.g., the application must use pull-down menus).
standards-the form, format, timing, and general contents of documentation to be
produced during the development. Development standards include rules about
allowable graphical representations, documentation, tools, techniques, and aids
such as computer-aided software engineering (CASE) tools, or project management
scheduling software. Format information includes the content of a data
dictionary/repository for design objects, project report contents, and other
standards to be followed by the project team when reporting project
accomplishments, problems, status and design.
plan for application development is refined.
documentation summarizes the current method of work, details the proposed
system, and how it meets the needs of the required functions. Requirements from
the work activities are described in graphics, text, tables, structured
English, or some other representation form prescribed by the methodology being
CONCEPTUAL DESIGN. Once the proposed
logical system is understood and agreed to by the user, conceptual design
begins. Other names for conceptual design activity include preliminary design, logical
design, external design, or software requirements specifications. The major
activity of conceptual design is the detailed functional
definition of all external elements of the application, including screens,
reports, data entry messages, and/or forms. Both contents and layout are
included at this level. In addition, the logical data model is transformed into
a logical database schema and user views. If distribution or decentralization
of the database is anticipated' the analysis and decision are made during conceptual
design. The outputs of conceptual design include the detailed definition of the
external items described above, plus the normalized and optimized logical
all organizations treat conceptual design separately. Outputs of conceptual
design may be in a conceptual design document or might be part of the functional
requirements document developed during analysis. Depending on the project
manager's personal taste and experience, the conceptual design might be
partially completed during logical design and fully completed during physical
design. In this text, the two phases, design and conceptual design, are
treated as one.
maps "what" the system is supposed to do into "how" the
system will do it in a particular hardware/software configuration. The other terms
used to describe design activities include detailed design, physical design,
internal design, and/or product design.
the design phase, the software engineering team creates, documents, and
architecture-identifies and defines programs, modules, functions, rules,
objects, and their relationships. The exact nature of the software architecture
depends on the methodology followed during the design phase.
components and modules-defines detailed contents and functions of software components,
including, but not limited to, inputs, outputs, screens, reports, data, files, constraints,
contents, timing, responsibilities, and design of data exchanged with other
applications or organizations.
the strategy, responsibilities, and timing for each type of testing to be performed.
maps "what" to "how" for data. In database terms, this is
the definition of the physical layout of data on the devices used, and of the
requirements, timing, and responsibility for distribution, replication, and/or
duplication of data.
SUBSYSTEM/PROGRAM DESIGN. Subsystem and/or program designs are
sometimes treated as subphases of the design phase. Whether they are separate
phases or not, the software engineering team creates, documents, and verifies
control structure-defines how each program/module is activated and where it
returns upon completion.
structure and physical implementation scheme-defines physical data layouts with
device mapping and data access methods to be used. In a database environment,
this activity may include definition of a centralized library of data
definitions, calling routines, and buffer definitions for use with a particular
any programs and buffers which are expected to be memory-resident for on-line
and/or real-time processes.
algorithms-specifies mathematically correct notation to allow independent
verification of formula accuracy.
component (routine with approximately 100 source procedure instructions)
identifies, names, and lists assumptions of program component design and usage.
Assumptions include expectations of, for instance, resident routines and/or
data, other routines/modules to be called in the course of processing this
module, size of queues, buffers, and so on required for processing.
CODE AND UNIT TEST. During coding, the low-level program elements
of the software product are created from design documentation and debugged. Unit testing is the verification that the program does what it is
supposed to do and nothing
In systems using reusable code, the code is customized for the current
application, and checked to ensure that it works accurately in the current environment.
TEST. During testing-sometimes called Computer Software Component (CSC)
Integration and Testingll-the components of a software product are evaluated
for correctness of integrated processing. Quality assurance testing may be
conducted in the testing phase or may be treated as a separate activity. During
quality assurance tests, the software product (i.e., software or documentation)
is evaluated by a nonmember of the project team to determine whether or not the
analysis requirements are satisfied.
IMPLEMENTATION. Also called
Installation and Checkout, implementation
is that period of time during which a software product is integrated into its
operational environment and is phased into production use. Implementation
includes the completion of data conversion, installation, and training.
this point in the project life cycle, the software development cycle ends, and
the maintenance phase begins. Maintenance
and operations continue until the project is retired.
OPERATIONS AND MAINTENANCE. Operations and
maintenance is the period in the software life cycle during which a software
product is employed in its operational environment, monitored for satisfactory
performance, and modified as necessary. Three types of maintenance are
Perfective-to improve the
performance of the application (e.g., make all table indexes binary to minimize
translations, change an algorithm to make the software run faster, and so on.)
Corrective-to remove software
defects (i.e., to fix bugs)
Adaptive-to incorporate any
changes in the business or related laws in the system (e.g., changes for new
type of maintenance requires a minianalysis and mini-design to determine
social, technical, and functional aspects of the change. The current operational
versions of software and documentation must be managed to allow identification
of errors and to ensure that the correct copy of software is run. One aspect of
change management specifically addresses
application programs in support of maintenance activities.
RETIREMENT. Retirement is the period of time in
the software life cycle during which support for a software product is
terminated. Usually, the functions performed by the product are transferred to
a successor system. Another name for this activity is phaseout.