Software systems come and go through a series of passages that account for their inception,
initial development, productive operation, upkeep, and retirement from one generation to
another. This article categorizes and examines a number of methods for describing or modeling
how software systems are developed. It begins with background and definitions of traditional
software life cycle models that dominate most textbook discussions and current software
development practices. This is followed by a more comprehensive review of the alternative
models of software evolution that are of current use as the basis for organizing software
engineering projects and technologies.
Background
Explicit models of software evolution date back to the earliest projects developing large software
systems in the 1950's and 1960's (Hosier 1961, Royce 1970). Overall, the apparent purpose of
these early software life cycle models was to provide a conceptual scheme for rationally
managing the development of software systems. Such a scheme could therefore serve as a basis
for planning, organizing, staffing, coordinating, budgeting, and directing software development
activities.
Since the 1960's, many descriptions of the classic software life cycle have appeared (e.g., Hosier
1961, Royce 1970, Boehm 1976, Distaso 1980, Scacchi 1984, Somerville 1999). Royce (1970)
originated the formulation of the software life cycle using the now familiar "waterfall" chart,
displayed in Figure 1. The chart summarizes in a single display how developing large software
systems is difficult because it involves complex engineering tasks that may require iteration and
rework before completion. These charts are often employed during introductory presentations,
for people (e.g., customers of custom software) who may be unfamiliar with the various
technical problems and strategies that must be addressed when constructing large software
systems (Royce 1970).
These classic software life cycle models usually include some version or subset of the following
activities:
System Initiation/Planning: where do systems come from? In most situations, new
feasible systems replace or supplement existing information processing mechanisms
whether they were previously automated, manual, or informal.
Requirement Analysis and Specification: identifies the problems a new software system is
suppose to solve, its operational capabilities, its desired performance characteristics, and
the resource infrastructure needed to support system operation and maintenance.
Functional Specification or Prototyping: identifies and potentially formalizes the objects
of computation, their attributes and relationships, the operations that transform these
objects, the constraints that restrict system behavior, and so forth.
Partition and Selection (Build vs. Buy vs. Reuse): given requirements and functional
specifications, divide the system into manageable pieces that denote logical subsystems,
then determine whether new, existing, or reusable software systems correspond to the
needed pieces.
Architectural Design and Configuration Specification: defines the interconnection and
resource interfaces between system subsystems, components, and modules in ways
suitable for their detailed design and overall configuration management.
Detailed Component Design Specification: defines the procedural methods through which
the data resources within the modules of a component are transformed from required
inputs into provided outputs.
Component Implementation and Debugging: codifies the preceding specifications into
operational source code implementations and validates their basic operation.
Software Integration and Testing: affirms and sustains the overall integrity of the
software system architectural configuration through verifying the consistency and
completeness of implemented modules, verifying the resource interfaces and
interconnections against their specifications, and validating the performance of the
system and subsystems against their requirements.
Documentation Revision and System Delivery: packaging and rationalizing recorded
system development descriptions into systematic documents and user guides, all in a
form suitable for dissemination and system support.
Deployment and Installation: providing directions for installing the delivered software
into the local computing environment, configuring operating systems parameters and user
access privileges, and running diagnostic test cases to assure the viability of basic system
operation.
Training and Use: providing system users with instructional aids and guidance for
understanding the system's capabilities and limits in order to effectively use the system.
Software Maintenance: sustaining the useful operation of a system in its host/target
environment by providing requested functional enhancements, repairs, performance