Software lifecycle models define how requirements, design, implementation, test, deployment and maintenance are organised. The waterfall model gives a simple sequential structure, but tends to discover integration defects late. Iterative and incremental models reduce this risk by delivering partial versions early. Agile methods improve feedback and adaptability, but must be constrained when safety evidence, traceability and certification are required. Spiral development emphasizes risk reduction and can be useful in large autonomy research programmes. DevOps integrates development, test, deployment and operational monitoring, which is important for connected autonomous systems that receive updates after release.

Safety-critical autonomy cannot adopt any lifecycle model without modification. The book's central V-model remains the organising framework because it preserves traceability between specification and evidence. However, the V-model should not be interpreted as a one-pass waterfall. Modern projects often use incremental development inside V-model phases: prototypes and simulations mature requirements; software releases are integrated progressively; operational monitoring feeds back into hazard analysis and requirements refinement. The essential discipline is not the calendar shape of the process, but the preservation of bidirectional traceability and controlled baselines.

Configuration management is the discipline that keeps a software system stable while it evolves. It identifies configuration items, controls changes, records status and audits baselines. For an autonomous system, configuration items include source code, requirements, models, compiler versions, middleware configuration, calibration data, AI model weights, training datasets, test cases, container images, operating-system builds, safety manuals, SBOMs and deployed binaries. A release is safe only if its complete configuration can be reconstructed and related to the evidence used to approve it.

The configuration-management cycle starts by identifying items and assigning unique versions. Change control then evaluates proposed modifications, including their impact on requirements, hazards, timing, security and certification evidence. Status accounting records which versions exist and where they are used. Configuration audits confirm that the tested and released product matches the approved baseline. Continuous review improves the process and reduces configuration drift.

The software supply chain has become a major part of safety engineering. Modern products assemble operating systems, open-source components, vendor SDKs, protocol stacks, middleware, container bases, cryptographic libraries and cloud services. Open-source components provide transparency, reuse and innovation, but they also introduce obligations: vulnerability monitoring, licence compliance, long-term support, patch management and evidence that the component is appropriate for its safety role. A component may be technically reliable in an IT context but unsuitable for a safety-critical control path without additional containment and verification.

Maintainability is a safety property over the product life. Autonomous systems often operate for years, while software dependencies and hardware platforms change much faster. A safe architecture needs separation between safety-critical and non-safety functions, explicit compatibility matrices, reproducible builds, update and rollback mechanisms, and a release process that prevents configuration drift. Over-the-air updates and software-defined features can reduce service cost and add capability, but they also transform validation into a continuing obligation after the first product release.

Configuration management is implemented through a set of recurring activities. Configuration identification defines what is controlled and how items are named. Configuration control defines how proposed changes are reviewed, approved, implemented and verified. Status accounting records the current and historical state of configuration items. Configuration audits confirm that documentation, software artefacts and released products match the approved baseline. Review and improvement ensure that the process remains effective as the system and organisation grow.

Modern toolchains automate many of these activities. Version-control systems track source code, models and documents. Artefact repositories store binaries, containers and generated files. CI pipelines build, test and package software reproducibly. ALM tools link requirements to commits, reviews, tests and release records. Infrastructure-as-code tools capture deployment environments. Vulnerability scanners and SBOM tools support supply-chain governance. These tools are helpful only if they are integrated into the engineering workflow and treated as part of the evidence chain.

Human factors remain a recurring risk. Teams under schedule pressure may bypass change control, modify configuration manually or treat documentation as separate from engineering. Automation should therefore reduce friction: pull requests should trigger traceability checks, builds should record tool versions automatically, test reports should be archived with the baseline, and release dashboards should show unresolved safety, security and configuration issues.