Software Lifecycle and Typical Lifecycle Models

The software lifecycle defines the complete process by which software is conceived, developed, deployed, maintained, and eventually retired. In the context of modern engineering — particularly for complex systems such as autonomous platforms, embedded systems, or enterprise solutions — understanding the lifecycle is essential to ensure quality, reliability, and maintainability. The lifecycle acts as a roadmap that guides project teams through stages of development and management. Each stage defines specific deliverables, milestones, and feedback loops, ensuring that the software evolves in a controlled, traceable, and predictable way ¹⁾.

“The software lifecycle refers to a structured sequence of processes and activities required to develop, maintain, and retire a software system.” — ²⁾ In other words, the lifecycle describes how a software product transitions from idea to obsolescence — incorporating all the engineering, management, and maintenance steps along the way. The lifecycle ensures:

• Consistency: A common framework for teams and stakeholders.
• Quality assurance: Enables verification and validation at each stage.
• Traceability: Establishes clear relationships between requirements, design, code, and tests.
• Risk management: Provides checkpoints to detect and correct issues early.
• Scalability: Supports integration of multiple teams, technologies, and versions.

In regulated domains like aerospace, automotive, and medical devices, adherence to a defined lifecycle is also a legal requirement for certification and compliance (e.g., ISO/IEC 12207, DO-178C, ISO 26262).

Different industries and projects adopt specific lifecycle models based on their goals, risk tolerance, and team structure. The most widely used models are explained in this chapter.

The Waterfall Model is one of the earliest and most widely recognised software lifecycle models. It follows a linear sequence of stages where each phase must be completed before the next begins ³⁾.

Advantages:

• Clear structure and documentation.
• Easy to manage for small, stable projects.
• Suitable for regulated environments (e.g., aerospace, defence).

Limitations:

• Inflexible to changes once development begins.
• Late discovery of integration or requirement issues.

An evolution of the waterfall approach, the V-Model emphasises testing and validation at each development stage. Each “downward” step (development) has a corresponding “upward” step (testing/validation).

Advantages:

• Strong focus on verification and validation (V&V).
• Ideal for safety-critical systems (e.g., ISO 26262, DO-178C).
• Provides traceability between design and testing phases.

Limitations:

• Requires well-defined requirements upfront.
• Difficult to adapt to rapid changes.

Instead of completing the whole system in one sequence, the iterative model develops the product through multiple cycles or increments. Each iteration delivers a working version that can be reviewed and refined. Advantages:

• Early delivery of functional prototypes.
• Easier adaptation to requirement changes.
• Continuous stakeholder feedback.

Limitations:

• Higher integration overhead.
• May require complex configuration management (each iteration produces new versions).

Agile development (e.g., Scrum, Kanban, Extreme Programming) emphasises collaboration, adaptability, and customer feedback. It replaces rigid processes with iterative cycles known as sprints.

Core Principles ⁴⁾:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change by following a plan.

Advantages:

• High flexibility and customer involvement.
• Continuous delivery of value.
• Improved responsiveness to market and technology changes.

Challenges:

• Requires disciplined teams and strong communication.
• Less suitable for safety-critical certification unless paired with hybrid models (e.g., Agile + V-Model).

Introduced by Boehm ⁵⁾, the Spiral Model combines iterative development with risk analysis. Each loop of the spiral represents one phase of the process, with risk evaluation at its core.

Advantages:

• Focused on risk reduction.
• Suitable for large, complex systems.
• Allows progressive refinement and flexibility.

Limitations:

• Complex management and documentation.
• Requires expertise in risk assessment.

Modern systems increasingly adopt DevOps — integrating development, testing, deployment, and operations into a continuous cycle. This model leverages automation, CI/CD pipelines, and cloud-native

Advantages:

• Rapid and reliable delivery.
• Real-time monitoring and feedback integration.
• Continuous improvement of deployed systems.

Challenges:

• Requires cultural and organisational transformation.
• Demands sophisticated toolchains and automation infrastructure.

In software engineering, Configuration Management (CM) refers to the systematic process of identifying, organising, controlling, and tracking all changes made to a software system throughout its lifecycle. It ensures that:

• The correct versions of software components are used.
• Changes are controlled, reviewed, and documented.
• The entire system remains consistent and reproducible across teams and environments.

According to ISO/IEC/IEEE 828:2012, CM is defined as: “A discipline applying technical and administrative direction and surveillance to identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, and record and report change processing and implementation status.”

In other words, Configuration Management keeps the software stable while it evolves. Configuration management exists to:

• Ensure traceability – every change can be traced to its origin (e.g., requirement, issue report, or design change).
• Prevent chaos – without CM, multiple developers could overwrite each other’s work or deploy incompatible versions.
• Enable collaboration – teams distributed globally can work on the same product using consistent artefacts.
• Maintain compliance – in safety-critical domains (automotive, aerospace), regulatory standards require version control and change tracking.
• Support automation – CI/CD pipelines rely on version-controlled repositories and configuration metadata.

To understand CM, several foundational terms must be defined.

Configuration Item (CI) A Configuration Item is any component of the system that is subject to configuration control. Examples include:

• Source code files
• Build scripts and binaries
• Databases and configuration files
• Test scripts and reports
• Documentation and requirement specifications
• Firmware or deployed container images

Each CI is uniquely identified, versioned, and tracked over time ⁸⁾.

Baseline A baseline is a formally approved version of one or more configuration items that serves as a reference point. Once established, any changes to the baseline must follow a defined change control process. Types of baselines:

• Functional baseline – system requirements approved for development.
• Allocated baseline – subsystem design completed and approved.
• Product baseline – tested and released version ready for delivery.

Baselines create stability checkpoints in the lifecycle ⁹⁾.

Version Control Version control systems (VCS), such as Git, Mercurial, or Subversion, track and manage modifications to source code and other files. They enable:

• Team collaboration.
• Historical traceability.
• Branching and merging for feature development.

Version control forms the technical backbone of configuration management.

Change Management Change management defines how modifications are proposed, evaluated, approved, and implemented. Typical steps:

• Request – a developer or stakeholder submits a change request (CR).
• Impact analysis – assess implications on cost, schedule, and performance.
• Approval – change control board (CCB) reviews and authorises.
• Implementation and verification – perform and test the change.
• Documentation and closure – record and archive results.

This structured approach ensures accountability and quality control ¹⁰⁾.

Configuration Audit A configuration audit verifies that the configuration items and documentation:

• Match the approved baseline.
• Have passed required verification steps.
• Are properly labelled and traceable.

Two common types:

• Functional Configuration Audit (FCA): Confirms functional requirements are met.
• Physical Configuration Audit (PCA): Confirms physical configuration matches documentation.

Audits maintain integrity and compliance, especially in defence and aerospace projects ¹¹⁾.

Even though CM brings structure and order, it faces numerous practical challenges, particularly in distributed and complex systems.

Complexity and Scale Modern systems can contain millions of lines of code, hundreds of dependencies, and multiple configurations for different platforms. Managing all these variations manually is infeasible. Example: An autonomous vehicle might include distinct configurations for:

• Development simulations
• Real-time embedded control
• Cloud analytics backend

Solution: Automated configuration management with metadata-driven tools (e.g., Ansible, Puppet, Kubernetes Helm).

Multiple Development Streams In large projects, teams work on multiple branches or versions simultaneously (e.g., development, testing, release). This increases the risk of:

• Code divergence and merge conflicts.
• Dependency mismatches.
• Integration bottlenecks.

Solution:

• Enforce branching strategies (GitFlow, trunk-based development).
• Integrate CI/CD pipelines for automated testing and builds.

Hardware–Software Interdependencies In embedded or cyber-physical systems, configurations depend on hardware variants (processors, sensors, memory). Maintaining alignment between software builds and hardware specifications is difficult. Mitigation:

• Maintain configuration matrices mapping software versions to hardware variants.
• Employ digital twins for verification ¹²⁾.

Frequent Updates and Continuous Delivery In the DevOps era, software may be updated multiple times per day across thousands of devices. Each update must maintain consistency and rollback capability. Challenge:

• Balancing speed (Agile/DevOps) with control (safety and certification).

Solution:

• Versioned deployment pipelines.
• Canary releases and A/B testing.
• Immutable infrastructure (containers and images stored as CIs).

Data and Configuration Drift Configuration drift occurs when the system’s actual state deviates from its documented configuration — common in dynamic, cloud-based systems. Causes:

• Manual changes bypassing automation.
• Untracked dependencies.
• Environment-specific overrides.

Prevention:

• Use Infrastructure as Code (IaC) for full traceability.
• Periodic configuration audits and compliance scanning (e.g., Chef InSpec, AWS Config).

Regulatory and Compliance Demands In domains like aerospace, medical, and automotive, configuration management is a compliance requirement under standards such as ISO/IEC/IEEE 12207, ISO 26262 or IEC 61508 Challenge:

• Maintaining traceability between requirements, code, and tests through continuous change cycles.

Solution:

• Use integrated Application Lifecycle Management (ALM) platforms (e.g., IBM DOORS, Siemens Polarion) that link requirements, commits, and test cases.

Human and Organisational Factors The most difficult aspect of CM is often cultural, not technical. Teams may resist documentation or formal change control due to perceived bureaucracy. As a result:

• Changes occur without review.
• Records become incomplete.
• Knowledge is lost during turnover.

Solution:

• Establish clear CM policies and training.
• Promote configuration discipline as a core part of engineering culture.
• Integrate CM practices seamlessly into daily workflows (e.g., automated pull requests and code reviews).

Configuration management (CM) is not a single activity but a cyclic process integrated into the entire software lifecycle. The ISO/IEC/IEEE 828:2012 standard identifies four principal activities:

• Configuration Identification
• Configuration Control
• Configuration Status Accounting
• Configuration Audit

In modern practice, a fifth step — Configuration Verification and Review — is also added for continuous improvement and compliance.

Configuration Identification The first step in CM defines what needs to be managed. It involves:

• Listing all Configuration Items (CIs) (e.g., code, documents, libraries, binaries).
• Assigning each CI a unique identifier (e.g., version tag, build ID).
• Structuring these items into a configuration hierarchy.

Example hierarchy:

Tools & Techniques:

• Version Control Systems: Git, SVN, Mercurial.
• Artefact Repositories: JFrog Artifactory, Nexus.
• Configuration Databases (CMDBs): ServiceNow CMDB, BMC Helix.

Goal: Create a clear inventory of every managed artefact and its dependencies.

Tools and Techniques:

• Issue & Change Tracking: Jira, Redmine, Azure DevOps, Bugzilla.
• Code Review Systems: GitHub Pull Requests, Gerrit, GitLab Merge Requests.
• Workflow Automation: Jenkins, GitHub Actions, Bamboo.

Goal: Ensure that every change is reviewed, justified, and properly recorded before being implemented.

Configuration Status Accounting (CSA) CSA provides visibility into the current state of configurations across the project. It records which versions of CIs exist, where they are stored, and what changes have occurred. Typical outputs include:

• Version histories and change logs.
• Baseline status reports.
• Release documentation and distribution tracking.

Tools & Techniques:

• Version Reporting Tools: Git log, Git tag, or custom CI/CD reports.
• Automated Dashboards: Grafana, Kibana, Jenkins build monitor.
• ALM Suites: IBM Rational Team Concert, Siemens Polarion.

Goal: Provide transparency and traceability, so project managers and auditors can reconstruct the exact configuration of any product version at any point in time.

Configuration Audit A Configuration Audit ensures the product conforms to its baseline and that all changes were properly implemented and documented. It verifies:

• Each configuration item matches its specification.
• All documentation is updated.
• No unauthorised modifications exist.

There are two types:

1. Functional Configuration Audit (FCA): Confirms the system performs as intended.
2. Physical Configuration Audit (PCA): Confirms that the physical implementation matches the design documentation.

Tools & Techniques:

• Automated Compliance Tools: Chef InSpec, OpenSCAP, AWS Config.
• Manual Audits: Checklists and review boards.
• Digital Twin Validation: Comparing digital models with deployed assets ¹⁵⁾.

Goal: Ensure integrity, consistency, and compliance across the entire configuration baseline.

Configuration Review and Verification This optional step closes the CM loop. It assesses whether CM processes are effective and aligned with project objectives. Activities include:

• Reviewing CM documentation and records.
• Evaluating tool performance and automation coverage.
• Identifying gaps or inefficiencies for improvement.

Tools:

• CM maturity models (CMMI, ISO/IEC 15504).
• Quality management platforms (e.g., Atlassian Confluence for audit documentation).

Goal: Support continuous improvement and process optimisation.

Modern CM relies heavily on automation and integration tools to manage complexity and enforce discipline across teams. These tools can be categorized by function.

Version Control Systems (VCS)

Build and Continuous Integration Tools

Infrastructure and Environment Management

Artifact and Release Management

Configuration Tracking and Documentation

Example – An integrated CM Workflow:

Toolchain Integration for Autonomous Systems In autonomous platforms (e.g., UAVs, vehicles), CM tools are often integrated with:

• Simulation tools (Gazebo, CARLA) for versioned testing.
• Digital twins for validation of real-world behaviour.
• Edge deployment systems for over-the-air (OTA) updates.

This hybrid approach ensures consistent software across all nodes — from cloud services to embedded controllers ¹⁶⁾.

Even mature organisations often encounter challenges in lifecycle and configuration management:

Organisations that succeed in embedding CM practices view them not as bureaucracy, but as enablers of reliability and trust.