Configuration management is a process of tracking and controlling the changes in software in terms of the requirements, design, functions and development of the product.
IEEE defines it as “the process of identifying and defining the items in the system, controlling the change of these items throughout their life cycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items”.
Generally, once the SRS is finalized there is less chance of requirement of changes from user. If they occur, the changes are addressed only with prior approval of higher management, as there is a possibility of cost and time overrun.
A phase of SDLC is assumed over if it baselined, i.e. baseline is a measurement that defines completeness of a phase. A phase is baselined when all activities pertaining to it are finished and well documented. If it was not the final phase, its output would be used in next immediate phase.
Configuration management is a discipline of organization administration, which takes care of occurrence of any change (process, requirement, technological, strategical etc.) after a phase is baselined. CM keeps check on any changes done in software.
Change control is function of configuration management, which ensures that all changes made to software system are consistent and made as per organizational rules and regulations.
A change in the configuration of product goes through following steps –
● Identification – A change request arrives from either internal or external source. When change request is identified formally, it is properly documented.
● Validation – Validity of the change request is checked and its handling procedure is confirmed.
● Analysis – The impact of change request is analyzed in terms of schedule, cost and required efforts. Overall impact of the prospective change on system is analyzed.
● Control – If the prospective change either impacts too many entities in the system or it is unavoidable, it is mandatory to take approval of high authorities before change is incorporated into the system. It is decided if the change is worth incorporation or not. If it is not, change request is refused formally.
● Execution – If the previous phase determines to execute the change request, this phase take appropriate actions to execute the change, does a thorough revision if necessary.
● Close request – The change is verified for correct implementation and merging with the rest of the system. This newly incorporated change in the software is documented properly and the request is formally is closed.