1.

Software Configuration Management Working spaces in development: Freezing content

at the end of phases, formalizing transfers,
The "V" lifecycle: controlling visibility, controlling manufacturing use,
Software Specification archiving validated states, minimizing stored data.
Preliminary design Different working spaces: Developer workspace,
integration space, validation space, delivery space,
Detailed design incoming space, reference space. Other
Coding organizations are possible.
Unit tests As-designed / As-built configurations: Rules for managing data: Defined access rights
(read, write) and modes (authentication) for different
Integration tests Hardware: Each manufactured item has its own as- workspaces. Each workspace has a unique
Validation tests built configuration identified by a serial number or responsible.
lot number. Working space diagram: Illustrates the flow
Versions: V 1.1, V 1.2, V 1.3, V 2.0, V 2.2, V 3.0, etc. between different workspaces (developer,
Software: All product items are identical; identified
Configuration management goal: To have the by a license number (not used for configuration integration, validation, reference, delivery, incoming)
necessary data for building the same product again. management). and archives.
Items influencing software configuration: Identification of items: Version identification: No normative rule; version
Files used for software build: source files, data Software component: An item (document, source numbering varies. Example: Version number (major
files, parametrization files index), revision number (minor index), variant (OS,
file, data, test result…) whose definition and hardware, options), provisional version.
Production tools: compiler, makefile (options and changes are controlled during the product
order of compilation, libraries…) lifecycle. Each component is individually identified. Software marking: On delivery support, displayed on
screen, in source files, in exe file (e.g., using Unix
Operational environment: operating system, Software product: Composed of a set of software command "what"). Configuration management tools
firmware, hardware, COTS, Open Source Software components, structured within a product tree. automate identifier placement. Signature: checksum
Software components from engineer's and user's Software decomposition example: Shows a for data integrity control.
perspectives: Engineers see source code, data files. software (CI) with Component 1 (subcontracted), Releases and configuration control: Release tree
Users see executables and installation scripts. All Component 2 (COTS and developed), and identifies software changes. Working spaces use
items attached to each software release and Component 3 (developed). "view" mechanisms for controlled data access and
identified. Tailoring configuration management: Based on parametrization. Access rights management.
software category (Category 1: risk of main mission
loss; Category 2: risk of secondary mission loss;
Category 3: no mission consequence). Higher risk
categories start configuration control earlier in the
development process.
Concurrent file access: Diagram showing how
multiple users can access and modify files
concurrently, highlighting the need for concurrency
control.
Process control: Procedures for organization
interoperability with software factory tools. Uses
attributes, event capturing ("triggers"), logic links
management, permissions, and locks.
Additional features for software configuration
management: Definition of workspaces and access
rights, data safeguard procedures, internal/external
software identification, development tool use,
change tracking, file identification and marking.
General norms for software configuration
management: Examples: ECSS-M-40, CMII.
Norms for software development with
configuration management sections: ISO 12207,
ECSS-E-40-Part 1_B, ECSS-E-40-Part 2_B, ECSS-Q-
80_B.