Life Cycle Approaches

A life-cycle approach describes how work is organized and how the system progresses through its life-cycle stages.

The stages describe what kinds of concerns exist over the system life. The approach describes how the work is performed.

There is no single best life-cycle approach for all systems. The approach should be tailored to the system, organization, risk, constraints, stakeholders, and operational context.

Sequential Approach

A sequential approach organizes work as a mostly linear progression from one stage to the next.

A simplified sequence may be:

1. Concept
2. Requirements
3. Architecture
4. Design
5. Implementation
6. Integration
7. Verification
8. Validation
9. Deployment
10. Operation
11. Support
12. Retirement

When It Is Useful

A sequential approach may be useful when:

• Requirements are stable
• Technology is mature
• Interfaces are well understood
• Regulatory documentation is important
• The system has strong review gates
• Rework would be expensive or unsafe
• The organization needs formal control

Strengths

Strengths include:

• Clear planning structure
• Defined milestones
• Strong documentation control
• Easier contractual alignment
• Useful for regulated environments
• Supports formal reviews and baselines

Limitations

Limitations include:

• Late discovery of integration problems
• Slow feedback from users
• High cost of late changes
• Risk of overcommitting before learning enough
• Potential mismatch with uncertain or evolving needs

A sequential approach should still allow iteration where needed.

V-Model Approach

The V-Model is a common Systems Engineering life-cycle representation.

The left side of the V usually represents decomposition and definition. The bottom represents implementation. The right side represents integration, verification, and validation.

A simplified V-Model structure is:

Purpose of the V-Model

The V-Model emphasizes that verification and validation should be planned as requirements and architecture are defined.

For every level of definition, there should be corresponding evidence that the solution satisfies that definition.

Benefits of the V-Model

The V-Model helps teams:

• Connect requirements to verification
• Plan integration early
• Maintain traceability
• Understand hierarchy
• Manage interfaces between levels
• Coordinate subsystem and system-level evidence
• Avoid treating testing as an afterthought

Limitations of the V-Model

The V-Model can be misinterpreted as a rigid waterfall process.

In practice, Systems Engineering uses the V-Model with iteration, feedback, and recursion.

A useful V-Model is not simply a one-way path. It is a framework for connecting definition, realization, integration, verification, and validation.

Iterative Approach

An iterative approach repeats activities to improve the solution as understanding increases.

Iterations may occur within any life-cycle stage.

Examples include:

• Refining stakeholder needs after interviews
• Revising requirements after analysis
• Updating architecture after trade studies
• Improving prototypes after user feedback
• Correcting design after integration testing
• Updating support strategy after operational experience

Benefits of Iteration

Iteration helps teams:

• Reduce uncertainty
• Improve stakeholder alignment
• Discover problems earlier
• Adapt to new information
• Improve system performance
• Manage technical risk

Risks of Poor Iteration

Iteration should be managed intentionally.

Poorly controlled iteration can cause:

• Scope creep
• Requirements instability
• Configuration confusion
• Schedule delays
• Interface churn
• Verification rework
• Stakeholder fatigue

Iteration should be supported by configuration management, decision records, change control, and traceability.

Recursive Approach

A recursive approach applies Systems Engineering processes at multiple levels of the system hierarchy.

For example:

• The aircraft is engineered as a system.
• The propulsion subsystem is engineered as a system.
• The engine control unit is engineered as a system.
• The embedded software is engineered as a system.

Each level may define:

• Stakeholders
• Requirements
• Architecture
• Interfaces
• Risks
• Verification methods
• Validation methods
• Life-cycle concerns

For more detail, see:

Hierarchy within a System

Iteration vs. Recursion

Iteration and recursion are related but different.

A project may use both.

For example, a subsystem team may recursively apply the V-Model at its own level while iterating through several architecture alternatives.

Incremental Approach

An incremental approach delivers the system in parts or increments.

Each increment adds capability, performance, scope, or maturity.

Examples

A system may be delivered as:

• Minimum initial capability
• Operational prototype
• Release 1, Release 2, Release 3
• Block upgrades
• Capability increments
• Product variants
• Modular deployments

Benefits of Incremental Development

Incremental development helps teams:

• Deliver value earlier
• Reduce risk through staged capability
• Learn from operational feedback
• Manage funding constraints
• Support evolving stakeholder needs
• Avoid waiting for all features before deployment

Risks of Incremental Development

Risks include:

• Architecture erosion
• Integration complexity
• Interface instability
• Technical debt
• Inconsistent user experience
• Verification complexity across versions
• Configuration management challenges

A strong architecture is especially important for incremental approaches.

Agile and Adaptive Approaches

Agile and adaptive approaches are common in software-intensive and digital systems.

They emphasize:

• Frequent delivery
• User feedback
• Prioritized backlogs
• Cross-functional teams
• Adaptation to change
• Continuous integration
• Continuous testing

Agile in Systems Engineering

Agile approaches can be combined with Systems Engineering.

Systems Engineering remains important for:

• System context
• Stakeholder alignment
• Architecture
• Interfaces
• Safety
• Security
• Regulatory evidence
• Verification and validation
• Life-cycle support
• Cross-team coordination

Agile delivery does not remove the need for Systems Engineering. It changes how some Systems Engineering work is performed and synchronized.

Spiral Approach

A spiral approach organizes development around repeated cycles of risk analysis, prototyping, evaluation, and refinement.

Each cycle typically includes:

1. Determine objectives
2. Identify and analyze risks
3. Develop and evaluate alternatives
4. Plan the next cycle

When Spiral Approaches Are Useful

Spiral approaches are useful when:

• Risks are high
• Technology is immature
• Requirements are uncertain
• User needs are evolving
• Prototyping is valuable
• Early learning is more important than rigid prediction

Evolutionary Approach

An evolutionary approach treats the system as something that will change over time.

This is common for:

• Systems of systems
• Enterprise systems
• Software platforms
• Defense capabilities
• Infrastructure networks
• Long-lived product families
• Digital services

Evolutionary approaches recognize that the first delivered system may not be the final desired capability.

Model-Based Systems Engineering Approach

Model-Based Systems Engineering, or MBSE, uses models as a primary means of capturing, analyzing, communicating, and managing system information.

An MBSE-enabled life-cycle approach may use models for:

• Stakeholder needs
• Requirements
• System context
• Behavior
• Interfaces
• Architecture
• Parametric analysis
• Verification planning
• Validation planning
• Traceability
• Configuration control

MBSE can support sequential, iterative, incremental, V-Model, agile, and evolutionary approaches.

Hybrid Approaches

Most real projects use hybrid life-cycle approaches.

Examples include:

• Sequential governance with iterative engineering
• V-Model structure with agile software delivery
• Incremental deployment with formal safety certification
• MBSE-supported architecture with spiral risk reduction
• Evolutionary capability delivery with configuration-controlled baselines

Hybrid approaches are often necessary because systems include different kinds of elements.

For example, a cyber-physical system may include:

• Hardware with long procurement lead times
• Software with frequent releases
• Safety certification with formal evidence
• Operators requiring training
• Infrastructure requiring site installation
• Support systems requiring logistics planning

The life-cycle approach must coordinate these realities.

Selecting a Life-Cycle Approach

Selection should consider:

Common Mistakes

Common life-cycle mistakes include:

• Treating the life cycle as only a schedule
• Ignoring support and retirement until late
• Choosing a process model without tailoring
• Applying agile delivery without system-level architecture
• Applying sequential governance without feedback loops
• Planning verification too late
• Ignoring enabling systems
• Failing to manage interfaces across increments
• Treating operations as separate from engineering
• Confusing project completion with system success

Key Takeaway

Life-cycle approaches should be selected and tailored to fit the system. A good approach provides enough structure to manage risk and enough adaptability to learn, integrate, and deliver value.