Software Lifecycle
Models
A software lifecycle model is a process for developing software.
The IEEE 1074
Framework
The IEEE 1074 framework is a 1997 IEEE standard for defining software lifecycle models.
IEEE 1074 doesn't attempt to define a lifecycle model, rather it describes what sub-processes should be included in a lifecycle model.
These sub-processes are organized into six process groups:
Lifecycle Modeling
Selection of a lifecycle model
Project Management
Project Initiation
Project Monitoring and Control
Software Quality Management
Pre-development
Concept Exploration
System Allocation
Development
Requirements
Design
Implementation
Post-Development
Installation
Operation and Support
Maintenance
Retirement
Integral Processes
Verification and Validation
Software Configuration Management
Documentation Development
Training
Integral Processes
Integral processes cut across the other processes. Their work products are verified (are they the right products?), validated (are they built correctly?), documented, and placed under version control.
Development
Processes
There are three main development processes. Here's a rough model:
Stakeholders
A stakeholder is any individual or organization that has a stake in a software project.
In these lectures we identify only three stakeholders:
Requirements
The goal of a requirements process is to produce a requirements model. This is a complete view of the system from the user's perspective.
The requirements process is often divided into two sub-processes:
Requirements Gathering
Requirements Analysis
The goal of requirements gathering is to produce a functional specification for the system. The goal of requirements analysis is to produce a computation-independent model of the system that shows the domain-specific data manipulated by the system as well as the flow of control.
All stakeholders participate in the requirements processes.
Design
The goal of design is to produce the design model, or platform-independent model. This is a model of the system from the developer's perspective. This model decomposes the system into sub-systems and the sub-systems into components. It also shows the dependencies between sub-systems and components.
Only developers participate in the design process.
Implementation
The goal of the implementation process is to map the design model to testable, platform-specific source code.
Only developers participate in the implementation process.
Modeling
Although not specified by IEEE1074, the requirements and design models are usually created using modeling tools and expressed as UML diagrams.
Classifying
Lifecycle Models
Lifecycle models are divided into activity-centered models and entity-centered models.
Activity-centered models focus on processes. Entity-centered models focus on work products.
Lifecycle models can be sequential or iterative.
Lifecycle models can have maturity levels. The CMM framework identifies five maturity levels for a software lifecycle:
Initial
Repeatable
Defined
Managed
Optimized
Lifecycle models can be placed on a spectrum:
Adaptive models can quickly react to requirement changes, but can't often predict where they will be in six months. Planning, controlling, big up-front design, documenting, and monitoring are hallmarks of predictive models.
Agile methodologies dominate the adaptive end of the spectrum, while heavyweight processes like RUP and Waterfall dominate the predictive end of the spectrum.