Software Life Cycle Models The software life cycle is a general model of the software development process, including

all the activities and work products required to develop a software system. A software life cycle model is a particular abstraction representing a software life cycle. Such a model may be:
y y

activity-centered -- focusing on the activities of software development entity-centered -- focusing on the work products created by these activities

These are complementary views: activities produce work products. A software life cycle model is often referred to as a software development life cycle (SDLC). IEEE 1074 Standard for Developing Life Cycle Processes The IEEE standard 1074 seeks to establish a common framework for developing life cycle models. It describes the activities and processes needed for the development and maintenance of software, and provides examples for typical situations. The standard divides the set of activities into processes, and processes into process groups. Software Processes and Process Groups in IEEE 1074 Process Group Processes Life Cycle Modeling Selection of a Life Cycle Model Project Initiation Project Management Project Monitoring and Control Software Quality Management Pre-development Development Concept Exploration System Allocation Requirements Design Implementation Installation Operation and Support Maintenance Retirement Verification and Validation Software Configuration Management Documentation Development Training

Post-development

Integral Processes

A summary of the activities and work products of each process group follows.
Life Cycle Modeling

The project manager customizes the selection and sequencing of the activities required for a particular project
Project Management

The project manager initiates, monitors and controls the project throughout the software life cycle. The project management plan is documented in the Software Project Management Plan (SPMP) during the Project Initiation process, and the plan is updated to reflect changes throughout the project.
Pre-Development

Management and the client identify an idea or need, and the manager establishes the initial system architecture. The need may addressed through:
y y y

greenfield engineering -- a new development effort interface engineering -- a change to the interface of an existing system reengineering -- a software replacement of an existing business process

A Problem Statement or Statement of Need (IEEE 1074) describes the business requirements to be addressed by the project. Most authors say that the problem statement should not discuss design and implementation topics, but your textbook suggests that subsystem decomposition and communication infrastructure be included.
Development

The development process per se includes all the process directly involved in the construction of the system.
Post-Development

After the software product is developed, it must be installed, maintained, and given operational support, and an existing system may need to be retired (terminated).
Integral (Cross-Development) Processes

Some processes (in addition to project management) take place during the complete lifetime of the project. Two of these processes require definition:
y y

verification -- showing that the system models comply with the specification, through reviews, audits, and inspections validation -- ensuring that the system addresses the client's needs, through system testing, beta testing, and client acceptance testing

Life Cycle Models A variety of life cycle models have been proposed, most of which focus exclusively on the development processes.
Code and Fix

A simple and widely used software life cycle model: Repeat the following steps until the solution is good enough. 1. 2. 3. 4. Code Compile and execute Detect errors Fix

Waterfall Model

The waterfall model prescribes a sequential execution of a set of development and management processes, with no return to an earlier activity once it is completed. Some variants of the waterfall model allow revisiting the immediately preceding activity ("feedback loops") if inconsistencies or new problems are encountered during the current activity.
V-Model

Another variant of the waterfall model -- the V-model -- associates each development activity with a test or validation at the same level of abstraction. Each development activity builds a more detailed model of the system than the one before it, and each validation tests a higher abstraction than its predecessor.
Spiral Model

Barry Boehm devised the spiral model to address the weaknesses of the waterfall model, especially its lack of resilience in the face of change. The spiral model focuses on addressing risks incrementally by repeating the waterfall model in a series of cycles or rounds:
y y y y y y y y y

Concept of Operation Software Requirements Software Product Design Detailed Design Code Unit Test Integration and Test Acceptance Test Implementation

Each round consists of four phases (as illustrated in this figure):

1. Determine objectives: product definition, determination of business objects, specification of constraints, generation of alternatives 2. Evaluate alternatives: risk analysis, prototyping 3. Develop product: detailed design, code, unit test, integration 4. Plan next cycle: customer evaluation, design planning, implementation, customer delivery The spiral model is an improvement on the waterfall model, as it provides for multiple builds and provides several opportunities for customer involvement. However, it is elaborate, difficult to manage, and does not keep all workers occupied during all phases.
Boehm subsequently proposed a modified version of the spiral model -- the WinWin spiral model -- which adds activities to the start of each cycle to identify the key stakeholders and their "win" conditions. See Using the WinWin Spiral Model: A Case Study by Boehm et al. (PDF format) and Anchoring the Software Process by Boehm (PostScript). Prototyping -- the Sawtooth and Shark Tooth Models

As a software product is being developed, the developers' view of the system diverges from the client's view, since the developer's focus on design and implementation while the client remains focused on requirements. The sawtooth model provides checkpoints during the development process in order to check that development is proceeding in a direction that will eventually meet the client's requirements. Typically, the checkpoints involve demonstrating a prototype to the client. For example, two prototypes may be developed: 1. a revolutionary prototype is an illustrative model of the system, representing only a small fraction of the required functionality 2. an evolutionary prototype, shown late in the development process, is based on a completed design and implements some of the required functionality The shark tooth model adds management reviews and demonstrations to the sawtooth model. Since these may be seen to be at an intermediate level of abstraction, a diagram of the model includes large "teeth" and small "teeth".
Rapid Application Development and the Time Box Model

Rapid application development (RAD) is an approach rather than a model. Its proponents view formal life cycle models as inherently inefficient, due to the large amount of documentation and the number of reviews required. The formality of such models is seen as interfering with customer communication. Instead, RAD focuses on developing a sequence of evolutionary prototypes which are reviewed with the customer, both to ensure that the system is developing toward the user's requirements and to discover further requirements.

The process is controlled by restricting the development of each integration to a well-defined period of time, called a time box. Each time box includes analysis, design, and implementation of a prototype. One problem with RAD is reaching closure -- the customer always has feedback, and the developers and the customer may never agree that the project is done.
Reference: Murray R. Cantor, Object-Oriented Project Management with UML (Wiley, 1998), pp.96--98 [QA 76.9 O35 C36 1998] Synch-and-Stabilize

Synch-and-stabilize is Microsoft's attempt to scale-up a loosely structured small-team ("hacker") style of product development.
y y

many small teams (3 - 8 developers per team) work in parallel changes are synchronize frequently so components will work together o developers check-in their code by a particular time so a new build (complete recompile) is done by the end of the day or the next morning o a defect that "breaks" the build must be fixed immediately features are evolved incrementally, with occasional innovations o start with a "vision statement" o select features and establish priority of features with user input o developers are free to innovate or adapt to unforseen competitive opportunities or threats o continual testing during development the product is stabilized at 3 or 4 milestone junctures in the project lifetime o thorough internal and external testing (beta sites) o fix almost all errors detected o "zero-bug" release at the last milestone

The process is also called a "milestone", "daily build", "nightly build", and "zero-defect" process. The overall strategy is to quickly introduce products that are "good enough" to capture a mass market, then improve the product, selling multiple product versions and upgrades. Read "How Microsoft Builds Software" by Michael A. Cusumano and Richard W. Selby (Communications of the ACM, Vol. 40, No. 6 [June 1997], pp. 53-61) in the reading packet.
Iterative and Incremental Development

The Unified Process is an example of an iterative software development process. Its designers -Ivar Jacobson, Grady Booch, and James Rumbaugh -- characterize the process [1] as:
y

use-case driven -- The use case model describes the complete functionality of the system. It replaces the traditional functional specification of the system, extending the question "What is the system supposed to do?" with the words "for each user?"

The use cases drive the development process: developers create design and implementation models to realize the use cases, and testers test the implementation to ensure that the use cases are correctly implemented.
y

architecture-centric -- The software architecture represents the most significant static and dynamic aspects of the system -- the platform on which the software is to run, reusable components and frameworks available, deployment considerations, legacy systems, and nonfunctional requirements. The architect selects the use cases which represent the key functions of the system (5% to 10% of all the use cases), specifies them in detail, and realizes them in terms of subsystems, classes, and components.

iterative and incremental -- The software development project is divided into miniprojects, each of which is an iteration that results in an increment. Each iteration deals with the most important risks and realizes a group of use cases that together extend the usability of the product as developed so far. In the early phases, a superficial design might be replaced by a more detailed or sophisticated one; in later phases, increments are typically additive.

For a presentation of this process which distinguishes between the management and the technical views of the process, see A Rational Development Process by Philippe Kruchten, Rational Software Corp.
For a list of software engineering "best practices" and details regarding major milestones and workflows, see also Rational Unified Process: Best Practices for Software Development Teams For more details about the phases of the Unified process, see A Rational Approach to Software Development Using Rational Rose 4.0

Entity-Based Models
Issue-Based Life Cycle Model

Bruegge and Dutoit present (textbook, pp. 483--485) an issue-based life cycle model, in which the project is driven by a set of issues such as "How do we set up the initial teams?" and "What software architecture shall we use?" Issues are classified as open or closed, but closed issues can be reopened as changes occur in the application or solution domain. Issues are maintained in an issue base accessible to all project participants. Issues do not directly correspond to risks, as some issues are design problems, not risks. The management problem in issue-based development is to keep the number of open issues small and manageable. By organizing the project around issues, all life cycle activities may proceed

concurrently, using dependencies between issues to determine which activities can be performed concurrently and what the impact of reopening an issue will be.
Workbook-Centered Development

IBM's Object-Oriented Technology Center uses an iterative and incremental process, but organizes it around work products -- documents, models, and software -- and uses a structured workbook to ensure that the work products are available and organized for access by the entire project. Work products are seen as the primary means of project communication.

Capability Maturity Model

The Software Engineering Institute (SEI) has defined five levels to characterize the maturity of a software development organization: 1. Initial -- ad hoc activities; dependence on the heroic efforts and skills of key individuals. 2. Repeatable -- each project has a well-defined software life cycle, but different models are used for different projects; success is predictable for similar projects. 3. Defined -- uses a documented model for all activities; model is customized at the beginning of each project. 4. Managed -- metrics are defined for activities and deliverables; data is collected during the project to quantify progress 5. Optimized -- measurement data are used to improve the model.