Contents
What is Configuration Management?
Configuration Management has its roots in the US Department of Defence in the 1950’s. It started as a technical management discipline and has been widely adopted by many other engineering disciplines, including Systems Engineering and Software Engineering. Configuration Management focuses on establishing, and maintaining, the consistency of a system or product throughout its lifetime. CM is a collection of competencies, techniques and tools whose purpose is to ensure the consistency of the system’s requirements, functional attributes and physical properties.
For the purposes of this paper we shall consider four fundamental, inter-related activities:
Revision Control
Revision control is concerned with controlling access to project artefacts and maintaining a history of changes to each artefact.
Configuration Identification
Before you can control any artefact you must identify what it is, what information it is going to contain and how it will be controlled.
Change Management
When an artefact has to change, Change Management controls when, or even if, the changes may be performed.
Release Management
Release Management focuses on the delivery of software outside the development department.
These activities are inter-related and highly dependent on each other.
Why perform CM?
Good Configuration Management ensures that the current design and build state of the system is known and recorded; and doesn’t rely on the tacit knowledge of the development team.
Being about to access an accurate historical record of system development is very useful – not only for project management and audit purposes, but for development activities such as debugging (for example, knowing what has changed between one set of tests and the next to help identify what could possibly be causing a fault).
Effective use of CM tools enables engineers to formally (and safely) record all change details. In particular, not only what was changed in the product but why it was changed
CM ensures that documentation can be produced which truly describes delivered systems.
Sometimes, it is necessary to rebuild old versions of products to reproduces problems for customers, such as the military, haven’t upgraded their tools to the latest versions.
Finally, and not to be overlooked (since these things happen!) good CM practices enable a system to be rebuilt correctly in the event of mistakes, failures and catastrophes.
Getting CM wrong
Configuration management can seem an awful lot of effort, much of which appears to be an overhead on the development of software. However, getting CM wrong can lead to the following:
– The wrong requirements being accepted
– The wrong design being implemented
– The wrong tools being used for development
– The wrong software being tested
– The wrong test suite being used
– The wrong version of software being released
Any of these could lead to huge amounts of wasted effort, wasted money, late deliveries and seriously dissatisfied customers. It doesn’t matter how good the software is, delivering the wrong product is never going to win you any plaudits.
He specialises in C++, UML, software modelling, Systems Engineering and process development.
- Practice makes perfect, part 3 – Idiomatic kata - February 27, 2020
- Practice makes perfect, part 2– foundation kata - February 13, 2020
- Practice makes perfect, part 1 – Code kata - January 30, 2020
Glennan is an embedded systems and software engineer with over 20 years experience, mostly in high-integrity systems for the defence and aerospace industry.
He specialises in C++, UML, software modelling, Systems Engineering and process development.
Hi,
We have a course in Document Controller and I have used one picture in my presentation from your site.
Can you please confirm me if this is a copyright piture and if it is ok if we use it on our slide ?
Waiting for your reply.
Regards,
Susmita Sah
Susmita,
By all means use the image; but could you please acknowledge Feabhas in your presentation.
Thank you for taking the effort to contact us. So many wouldn't.
Hi,
Is it possible to develop an aviation configuration management framework to track components changes and have capability of status reporting at regular intervals?