Differences

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

--- en:safeav:softsys:configuration [2025/10/17 15:44] – agrisnik
+++ en:safeav:softsys:configuration [2026/04/24 09:32] (current) – removed raivo.sell
@@ Line 1: / Line 1: @@
-====== 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).

en/safeav/softsys/configuration.1760705069.txt.gz · Last modified: 2025/10/17 15:44 by agrisnik