Sophisticated engineering services track long-term systems and their components through the lifecycle. Released system configurations need to be built, operated, repaired, maintained and disposed of at any point in deployment – even if these fielded systems are not the latest version. Configuration Management (CM) is the approach to control system configurations using dedicated processes and tools to perform Product Data Management (PDM).
The PDM process involves data from initial design, prototyping, release to production, and Engineering Change Notice (ECN) process. It also controls the design review and approval process, allows for ad hoc prototyping, ensures Engineering Resources Planning (ERP) methodology integrates across the correct systems and departments to enable consistent flow of information, and collects correct approvals before the team applies changes.
A robust CM approach helps in the product lifecycle throughout development, operation and maintenance phases. It also enables the team to create variants and new versions of the product. Variants are delivered solutions that have alliterations with respect to the product baseline – sometimes creating a new product baseline or fork. New versions are permanent downstream changes to the baseline.
Within the Engineering Lifecycle Management (ELM) or Project Lifecycle Management (PLM), teams create artifacts as part of design and/or development. These artifacts include meeting minutes, requirements documents, design documents, test cases, test plans, engineering drawings, design specifications, theme sheets, source code and software distributions.
PLM is the system while PDM is the tool set. PDM manages all of the data associated with a product. PLM is a strategic business approach that aims to maximize product performance (profitability, quality, etc.) at every stage. PLM is the framework for innovation, product introduction, product maintenance and end-of-life/obsolescence planning.
Within a product, a logical piece of software or hardware is referred to as a component. Hence, for software products, these are also referred to as Computer Software Configuration Item (CSCI) components. These are basically every separate running software process that runs within the operational solution. Artifacts would include such items as design documents, source code and the compiled solution. Non-software components, as well as software components, may have multiple artifacts.
Artifacts are collected into a technical data package (TDP) to represent a configuration, often forming a release, which updates the baseline. Baselines are frozen configurations for one or more components. Once in a baseline, the artifacts (or at least the version in the technical data package), from one or more components, are frozen inside the baseline.
Streams are configurations that are modifiable. If multiple components depend on each other (sharing schema, protocols or interfaces), they must change together before the configuration is frozen to form a new baseline. To support multiple variants, baselines are branched into multiple streams. Usually there is one global configuration off which variants branch. Within the software development lifecycle, branches can be used to create maintenance and feature release separately – which is best practice for ongoing software product maintenance as seem with operating systems such as Ubuntu. These separate streams reference and will often update the main/master stream.
Sometimes a variant loses reference to the original product's stream. There is referred to as a fork. While similar, this long-term separation from the original will create a new baseline.