Differences

This shows you the differences between two versions of the page.

--- en:safeav:softsys:softmgmt [2025/10/17 15:19] – agrisnik
+++ en:safeav:softsys:softmgmt [2026/04/24 09:33] (current) – subchapters added raivo.sell
@@ Line 1: / Line 1: @@
-====== Software Lifecycle and Configuration Management ======
+====== Software Lifecycle and Typical Lifecycle Models ======
-{{:en:iot-open:czapka_b.png?50| Bachelors (1st level) classification icon }}
+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 ((Sommerville, I. (2016). Software Engineering (10th ed.). Pearson)).
+=== Definition ===
+“The software lifecycle refers to a structured sequence of processes and activities required to develop, maintain, and retire a software system.” — ((Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner’s Approach (9th ed.). McGraw-Hill)) 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).
+===== Typical Software Lifecycle Models =====
+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 ====
+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 ((Royce, W. W. (1970). Managing the development of large software systems. Proceedings of IEEE WESCON)).
+<figure The Waterfall Model  >
+{{ :en:safeav:as:as:rtu_ch4_figure1.png?400| The Waterfall Model }}
+<caption>The Waterfall Model </caption>
+</figure>
+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.
+==== The V-Model (Verification and Validation Model) ====
+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).
+<figure V-Model Lifecycle  >
+{{ :en:safeav:as:as:rtu_ch4_figure2.png?400| V-Model Lifecycle }}
+<caption>V-Model Lifecycle</caption>
+</figure>
+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.
+==== The Iterative and Incremental Model ====
+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 Methodologies ====
+Agile development (e.g., Scrum, Kanban, Extreme Programming) emphasises collaboration, adaptability, and customer feedback. It replaces rigid processes with iterative cycles known as sprints.
+<figure Agile Lifecycle  >
+{{ :en:safeav:as:as:rtu_ch4_figure3.png?400| Agile Lifecycle }}
+<caption>Agile Lifecycle</caption>
+</figure>
+Core Principles ((Agile Alliance. (2001). Manifesto for Agile Software Development. https://agilemanifesto.org)):
+  * 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).
+==== The Spiral Model ====
+Introduced by Boehm ((Boehm, B. W. (1988). A spiral model of software development and enhancement. Computer, 21(5), 61–72.)), 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.
+<figure Spiral Lifecycle  >
+{{ :en:safeav:as:as:rtu_ch4_figure4.png?400| Spiral Lifecycle }}
+<caption>Spiral Lifecycle</caption>
+</figure>
+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.
+==== DevOps and Continuous Lifecycle ====
+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
+<figure DevOps Lifecycle  >
+{{ :en:safeav:as:as:rtu_ch4_figure5.png?400|  DevOps Lifecycle }}
+<caption> DevOps Lifecycle</caption>
+</figure>
+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.
+=== Comparative Overview ===
+^ Model ^ Main Focus ^ Advantages ^ Best Suited For ^
+| Waterfall | Sequential structure | Simple, predictable | Small or regulated projects |
+| V-Model | Verification and validation | Traceable, certifiable | Safety-critical systems |
+| Iterative/Incremental | Progressive refinement | Flexible, early testing | Complex evolving systems |
+| Agile | Collaboration & feedback | Fast adaptation, user-centric | Software startups, dynamic projects |
+| Spiral | Risk-driven development | Risk control, scalability | Large R&D projects |
+| DevOps | Continuous integration | Automation, rapid delivery | Cloud, AI, or autonomous platforms |
+===== Configuration Concepts and Challenges =====
+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.
+<figure The Role of Configuration Management  >
+{{ :en:safeav:as:as:rtu_ch4_figure6.png?400| The Role of Configuration Management }}
+<caption>The Role of Configuration Management (Adapted from ((Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner’s Approach (9th ed.). McGraw-Hill)) ((IEEE. (2012). ISO/IEC/IEEE 828: Configuration Management in Systems and Software Engineering. IEEE Standards Association.))) </caption>
+</figure>
+==== Key Concepts in Configuration Management ====
+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 ((Sommerville, I. (2016). Software Engineering (10th ed.). Pearson)).
+**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 ((Pressman, R. S., & Maxim, B. R. (2020). Software Engineering: A Practitioner’s Approach (9th ed.). McGraw-Hill.)).
+**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 ((IEEE. (2012). ISO/IEC/IEEE 828: Configuration Management in Systems and Software Engineering. IEEE Standards Association)).
+**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 ((NASA. (2021). Configuration Management Procedural Requirements (NPR 7120.5E). National Aeronautics and Space Administration)).
+==== Challenges in Configuration Management ====
+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 ((Wang, L., Xu, X., & Nee, A. Y. C. (2022). Digital twin-enabled integration in manufacturing. CIRP Annals, 71(1), 105–128.)).
+**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).
+===== Main Steps and Tools of Configuration Management =====
+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.
+<figure The Configuration Management Cycle >
+{{ :en:safeav:as:as:rtu_ch4_figure7.png?400| The Configuration Management Cycle }}
+<caption>The Configuration Management Cycle (Adapted from ((IEEE. (2012). ISO/IEC/IEEE 828: Configuration Management in Systems and Software Engineering. IEEE Standards Association)) ((NASA. (2021). Configuration Management Procedural Requirements (NPR 7120.5E). National Aeronautics and Space Administration)))</caption>
+</figure>
+**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:
+<figure Example hierarchy >
+{{ :en:safeav:as:as:rtu_ch4_figure8.png?400| Example hierarchy }}
+<caption>Example hierarchy</caption>
+</figure>
+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.
+<figure Change Control Workflow >
+{{ :en:safeav:as:as:rtu_ch4_figure9.png?400| Change Control Workflow }}
+<caption>Change Control Workflow</caption>
+</figure>
+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.
+<figure Configuration Status Flow >
+{{ :en:safeav:as:as:rtu_ch4_figure10.png?400| Configuration Status Flow }}
+<caption>Configuration Status Flow</caption>
+</figure>
+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:
+  - Functional Configuration Audit (FCA): Confirms the system performs as intended.
+  - 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 ((Wang, L., Xu, X., & Nee, A. Y. C. (2022). Digital twin-enabled integration in manufacturing. CIRP Annals, 71(1), 105–128.)).
+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.
+==== Main Tools for Configuration Management ====
+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)**
+^ Tool ^ Description ^ Example Use ^
+| Git | Distributed version control system; supports branching and merging. | Used for nearly all modern software projects. |
+| Subversion (SVN) | Centralised version control with strict change policies. | Preferred in regulated environments (aerospace, defence). |
+| Mercurial | Similar to Git, optimised for scalability and ease of use. | Used in research or large repositories. |
+**Build and Continuous Integration Tools**
+^ Tool ^ Purpose ^ Example Use ^
+| Jenkins / GitLab CI | Automate building, testing, and deploying changes. | Trigger builds after commits or merge requests. |
+| Maven / Gradle / CMake | Manage project dependencies and build processes. | Ensure reproducible builds. |
+| Docker / Podman | Containerise environments for consistency. | Package applications with dependencies for testing and deployment. |
+**Infrastructure and Environment Management**
+^ Tool ^ Function ^ Application ^
+| Ansible / Puppet / Chef | Automate configuration and provisioning. | Keep server environments synchronised. |
+| Terraform | Infrastructure as Code (IaC) for cloud platforms. | Manage cloud resources with version control. |
+| Kubernetes Helm | Manages container-based deployments. | Controls configurations in microservice architectures. |
+**Artifact and Release Management**
+^ Tool ^ Purpose ^ Example Use ^
+| JFrog Artifactory / Nexus Repository | Store and version compiled binaries, libraries, and Docker images. | Maintain reproducibility of releases. |
+| Spinnaker / Argo CD | Manage continuous deployment to production environments. | Implement automated rollouts and rollbacks. |
+**Configuration Tracking and Documentation**
+^ Tool ^ Purpose ^ Use Case ^
+| ServiceNow CMDB | Tracks configuration items, dependencies, and incidents. | Enterprise-scale CM. |
+| Atlassian Confluence | Maintains documentation and process records. | Collaboration and change documentation. |
+| Polarion / IBM DOORS | Links requirements to configuration items and test results. | Traceability in regulated environments. |
+Example – An integrated  CM Workflow:
+<figure An integrated  CM Workflow >
+{{:en:safeav:softsys:rtu_ch4_figure11.png?400| An integrated  CM Workflow }}
+<caption>An integrated  CM Workflow (Adapted from GitLab, Atlassian, and IEEE 828 integration frameworks)</caption>
+</figure>
+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 ((Raj, A., & Saxena, P. (2022). Software architectures for autonomous vehicle development: Trends and challenges. IEEE Access, 10, 54321–54345)).
+==== Common Pitfalls and Lessons Learned ====
+Even mature organisations often encounter challenges in lifecycle and configuration management:
+^ Pitfall ^ Effect ^ Mitigation ^
+| Poor version control discipline | Loss of traceability | Enforce the branching strategy and pull request reviews. |
+| Incomplete configuration audits | Undetected inconsistencies | Automate audit workflows and compliance scanning. |
+| Manual deployment processes | Environment drift | Use CI/CD and Infrastructure as Code. |
+| Siloed documentation | Lack of visibility | Centralise records using CMDB or ALM platforms. |
+| Lack of cultural adoption | Resistance to process discipline | Provide training, incentives, and leadership support. |
+Organisations that succeed in embedding CM practices view them not as bureaucracy, but as enablers of reliability and trust.
-<todo @karlisberkolds></todo>
-<WRAP excludefrompdf>
-      * [[en:safeav:softsys:lifecycles]]
-      * [[en:safeav:softsys:configuration]]
-      * [[en:safeav:softsys:configurationtools]]
-</WRAP>

en/safeav/softsys/softmgmt.1760703545.txt.gz · Last modified: 2025/10/17 15:19 by agrisnik