| Related: |  |
 |
Configuration management (CM) is one of the cross-cutting activities that occurs throughout the system life cycle. There are 2 principles involved: Establishing System Integrity which includes setting the baseline and Maintaining System Integrity through monitoring and managing changes to the produce baseline.
Configuration Management (CM) is a cross-cutting activity that isnt strictly a Systems Engineering (SE) activity but rather supports SE activities. CM can be thought of as a process for establishing and maintaining consistency of baselines, approving and controlling changes, and recording and reporting changes in status of a system/product under development.
CM recognizes that Change Happens. This is about establishing the baseline definition of the product and its documentation then managing the changes as they happen.
Configuration management [CM], in conjunction with other systems engineering activities, is used to establish system integrity [integrity is defined as all system functionality, physical characteristics, and design match its documentation] and then maintain this integrity throughout its life.
The Electronic Industries Alliance (EIA) standard 649 defines CM as
A management process for establishing and maintaining consistency of a products performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.
The general CM process is demonstrated graphically below.
Figure 24: CM Process Overview
(Source: FHWA)
During Project Planning one of the activities should be to develop a plan for how Configuration Management will be carried out. A CM plan is a document that will guide the CM program of a particular group. Typical contents of a CM plan include items such as:
Personnel
Responsibilities
Resources
Training requirements
Administrative meeting guidelines
Definition of procedures
Tools/tool use
Organization configuration item (CI) activities
Baselining
Configuration control
Configuration status accounting
Naming conventions
Audits and Reviews
Subcontractor or vendor CM requirements
There are three application areas that need planning. The agency's CM plan for the life of the system, the implementation team's CM plan for development, and the CM Plan for the product vendors. The agency's CM plan should identify the requirements for the development team's CM plan and vendor's CM plan and the needed outputs to support the life of the system.
See Section 6.3 for a template for a Configuration Management Plan
Identify what needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained. Identifying the configuration items and what identifiers will be used during the product life cycle. Configuration Identification defines the product and identifies its configuration documentation. What is it that makes up the baseline for the product?
Baseline: An agreement at a given point in time that is under configuration control and used for measuring progress and as the basis for defining change. The term itself is meaningful only when preceded by another noun that specifies the type of agreement (e.g., schedule baseline, cost baseline, requirements baseline, etc.).
Configuration identification is the process of documenting and labeling the items in the system. Depending on the scale of the particular CM program, this simply may involve software versions or, in the case of a large program, all hardware, software, documentation, and the CM plan itself. The goal of configuration identification is to provide a unique identifier for each item to help track the changes to that item and to be able to understand its place in the system. Often, identification involves recording the identifier, maintenance history, relevant documents and other information that will simplify the change process in the future.
The benefits of configuration identification are to provide a way to uniquely identify the system components to support traceability and change management processes. This minimizes confusion over various versions of configuration items and facilitates the change control process. It allows items to be more easily tracked as they undergo change.
With a product development underway or in use it is important to manage the changes to the baseline.
This is the process to manage changes to the configuration items. This involves a change management board and documentation that identifies the change, rationale, cost, risk, and priority.
The basics steps in a Change Management process are shown below:
Figure 25: Change Management Process
(Source: FHWA)
1. Identify the Change - Step 1 is to identify the Changes. The CM Plan should establish who can suggest changes and how that I managed either informally with the project staff or a formal. Also capture how those change requests will be documented online forms, spreadsheet, database, etc.
2. Evaluate the Changes - This is more applicable to the Incremental Change approach as changes are identified or requested someone needs to look at it and determine its impact. Include the person requesting the change but also include someone from the group that really understands the details of the architecture. Depending on the change, you may need to inform impacted stakeholders possibly even scheduling a mini-review between some of the stakeholders to discuss the potential change.
3. Approve the Change - Present one or more incremental changes to the Configuration Control Board or Maintenance Committee/Team for review - face-to-face, email, teams, etc. Approve/accept, reject, or defer the change and document the decision.
4. Update the Baseline - Now that the changes have been approved, they need to be rolled into the baseline products. If the same team isnt around to make the changes then the new team members will need access to the source files AND the knowledge to use the tools may need to plan for this ahead of time. Make sure that you update the versions tracking all of the outputs products.
5. Notify the Stakeholders - Last but not least, let your community of stakeholders know whats been done. This applies equally to incremental changes and full updates but you may want to tailor how much publicity is done for each type. This can be done in a number of ways or a combination of: email, press releases, presentation at committees, working groups, etc.
E
Effective communication of baseline changes to all affected parties is critical to effective configuration management. To that end, make sure your contact list is complete and current.
Configuration Status Accounting is the process by which the project provides status and information about a product and its configuration documentation. Keeping track of updates as they occur.
The configuration audit is used to verify consistency of configuration against the baseline. Occasionally, a project team will perform an audit or have an outside group audit the records and products and compare them to the documented baseline. This may result in corrective actions or a need to update the CM Plan.
There are two types of audits, [functional and physical]. Functional audits match the product to the functional and performance requirements [acceptance verification]; and physical audits match version numbers and physical identifiers with the documentation.
When is Configuration Management done? As shown below, the CM Plan will be developed during the initial stages of a project. It will be one of the plans developed, typically as part of the Project Management Plan or a Systems Engineering Management Plan.
Figure 26. Where does the Configuration Management take place in the project timeline?
(Source: FHWA)
As the project development progresses, CM will be carried out against the documentation the Needs in the ConOps, system requirements, the design specifications, and system architecture information all become part of the baseline and configuration management should be done throughout this part of the project. Then as the hardware and software are developed, purchased, installed, tested, and handed off any changes to the product baseline will also need to be managed.
Is there a policy or standard that includes Configuration Management?
FHWA Regulations do not specifically mention general Configuration Management practices to be followed. EIA 649 National Consensus Standard for Configuration Management provide a great deal of applicable information.
What should I track in this process step to reduce project risks and get what is expected? [Metrics]
On the technical side:
Changes to the specific area of the system. A high number of changes may indicate a design weakness
Monitor the impact of a change: who will be affected and how much of the system will need to be changed?
On the project management side:
Growth in the number of change requests. This is an indication that the baseline was established too early
Monitor the types of changes. Determine if the changes are critical to meet the initially stated requirements or if this is new functionality that can be deferred to the next phase of work
Configuration
management for systems development is a management process for the project
products. Configuration management works together with a good systems
engineering process. The systems engineering process provides the orderly establishment
of the project products and documentation and Configuration Management is used
to maintain consistency between the system changes to its documentation.
The following checklist can help answer the question Are all the bases covered? once the activities above have been planned or performed. The checklist is not sufficient by itself.
R Is there a CM plan for the project?
R Was the plan reviewed and supported by all the stakeholders?
R Is the organization for CM in place for the project?
R Is there sufficient funding to sustain the CM activities throughout the life of the system?
R Does the development team have a CM process and was it reviewed by the system's owner and stakeholder?
R Is the product documentation complete to the extent that the system's owner can use another qualified development team to upgrade and maintain the system independent of the initial development team? [extremely important]
R Does the vendor have a CM process for their products?
R Does the vendor provide a notice of design changes?
R Does the vendor provide a notice of obsolescence?
R Does the vendor provide on-going maintenance support?
| Related: | |
|
