At the end of this session, you will be able to:
- Ø Learn what software configuration management is
- Ø Study the important terminologies used in software configuration management
- Ø Explain the tasks involved in software configuration management
Change management is a life cycle activity, not just a maintenance activity.
Change is inevitable and it can occur at any stage of software development.
Here, we will illustrate a few basic reasons why we encounter change in software application development. If the business need is not clear to the customers, then the way it is communicated often doesn't address the actual need which, at a later point of time, might result in a change. Secondly, if there is a change in the operating environment in which the system functions. Thirdly, a change might result from the errors committed due to other reasons during requirement gathering, design, and the testing phase of the life cycle.
Since you now know the fact that change is inevitable in software application development, the next basic question that arises is how are we going to manage these changes? To manage changes in software application development, we use the discipline of software configuration management, which operates throughout the life cycle of an application development.
Here is an illustration of configuration management. Configuration management is a discipline that involves a set of activities that need to be performed to manage and control the changes that arise during the software development life cycle. The discipline of configuration management is applied across the life cycle of the project. SCM is that aspect of project management that focuses exclusively on systematically controlling the changes that occur during the project by using a defined process. SCM is a support activity that makes technical and managerial activities more effective with the basic objectives of delivery of high-quality software product to the client. It involves identifying and documenting the physical and functional characteristics and managing the security and protection of a software artifact.
Now, here is an illustration of the basic questions a configuration management system helps us to answer about any document or code that is created or used in software development or maintenance. Typical questions that any SCM process should address are:
- What are the artifacts to be developed within the life cycle?
- What is the status of an item?
- How do I identify a work product uniquely, every time I make a change and how do I record its effect on other items?
- How do I inform everyone else of the changes I have made to an existing document or code?
The most important concept of software configuration management is a software configurable item or SCI. Software configurable items are the basic building blocks of any software product. Changes to the software configurable items need to be managed in order to control change of the software product. Here is an example of a house that relates to an SCI. The building plan, the floor design, the doors, windows, and chimney of the completed house can be identified to be the configurable items of a house. In case of a software application requirements document, the design document, code, test strategy document, and the delivered application itself can be considered to be examples of SCI.
A baseline is a specification or product that has been formally reviewed and agreed upon. Examples of baselines are reviewed design document, approved project plans, and accepted product. Baselines are well-defined points in the evolution of a software application. Hence, the baselining criteria and the person responsible for meeting the criteria need to be defined prior to planning configuration management.
Using version control of a configurable item, we are able to identify multiple instances of the same configurable item, uniquely. Assume that we have completed building a house using the Base-lined project plan: House_Project_Plan_Version_1.0, and Base-lined Floor Design Document: House_Floor_Design_Version_1.0. Now, there is a need to change the pattern of windows of the house.
To change the window pattern of the house, we would need to re-plan the project and recreate the floor design. The version number of the initial project plan is incremented by 1.0 and the new plan is named: House_Project_Plan_Version_2.0. The floor design is also updated and the version number of the initial floor plan is incremented by 1.0 and the new floor design is named: House_Floor_Design_Version_2.0. Based on the new baselined configurable items House_Project_Plan_Version_2.0 and House_Floor_Design_Version_2.0, an updated version of the house is created. The following page will give you details on Access control.
Access control is used to maintain integrity of configurable items. Not all associates working in a software company are allowed to access the documents pertaining to a particular project. Only core members of a project are allowed to gain access to documents of a project. Again, within the project, different user groups are defined and access rights are defined for each user group. Separate work areas are defined for each team and access is controlled within each work area.
The first task for initiating the discipline of software configuration management, referred to as SCM, is to create the configuration management plan. The next step is to form the SCM team as per the roles identified in the SCM plan. The third step is to set up a library or project repository structure as per the SCM plan. Along with this task, access rights of each team member to each repository are also defined and implemented. Changes implemented in all items are then implemented as per the methodology documented in the SCM plan. The status of items changed is maintained by the SCM coordinator. All activities of SCM are subject to configuration audits conducted by the quality reviewer.
The software configuration management plan documents the processes and methodologies that will be used to manage change in the project. It also identifies the roles of the team members who will be responsible for implementing change control in a project.
The SCM plan identifies the names of the SCM team and the roles of each member, that is, the names of the reviewers, approvers, SCM coordinator, and other team members who will be responsible for implementing a change.
Libraries or repositories are areas where a project stores and maintains the documents and executables. This page illustrates the repository structure for version controlled items. The development area contains all items documents that are in development while review or test area contains items that are ready for testing. The baseline area contains all the approved items that are ready for project use and deliverable to the next step or stage. Old items that are no longer in use are stored in the archival area.
Here you will see how user access rights are defined for each of the area or repository and how read or write access is controlled in a project. To maintain integrity of the work products, access rights to each of the folders is defined.
A software project has both version controlled and non version controlled items. All the items that will undergo changes throughout the life cycle are version controlled and called documents, such as design document, code etc., There are many other items, which reflect the status at the given point of time and that individual item will not undergo changes. Only a new instance will be created. These are typically non-version controlled and called as records. Examples are Status reports, review records.
This naming conventions of configurable items have been described here. The qualifier can be a project or a module or a sub project name or any combination of them identified as appropriate to a project.
To manage changes in a software configuration item, it is necessary to identify the multiple instances of a configurable item uniquely. We use the concept of a naming convention and a version number to identify a configurable item. After a configurable item is baselined, a version number is given to the configurable item, generally starting at 1.0. As already described earlier, a baselined configurable item is either reviewed or approved based on the criteria set for baselining the item.
Here you can see how non-configurable items like quality records are named. The example is that of a review sheet for a design document. In this case, a qualifier can be a project or a module or a sub project name or any combination of them identified as appropriate to a project.
Change control is a procedural activity that ensures quality and consistency as changes are made to configurable items. Change control is the means by which changes are accepted into a project in a controlled manner without causing great instability. Manages the process for initiating and making changes to baselined software configurable items.
Status Accounting keeps track of changes made to Configurable Items and its current status by maintaining a history and a continuous status over the period of time. The status can be WIP, baselined, under review, or change etc. This helps in identifying the list of changes required, the changes incorporated, and the changes pending.
The quality reviewer or SCM coordinator of the project audits all activities pertaining to configuration management. There are two types of audit that a quality reviewer performs, functional configuration audit and physical configuration audit. Functional configuration audit verifies that the system satisfies the specifications and this is typically verified by auditing the traceability matrix. The traceability matrix traces each requirement through the design, code, and test case, whereas the physical configuration audit verifies the typical SCM question of the status accounting of all SCIs.
In this page, you will learn about the modes of configuration management. SCM can be either tool-based or manual or a combination of the two. Manual management essentially involves configuring a folder structure in a file server with controlled access rights for various areas. Tool-based management covers automatic version control mechanism for both source code and documents, and access control. Since the process is automatic, the chances of committing manual errors are eliminated. Examples of SCM tools are: VSS, Clearcase, CVS, etc. SCM can be performed as a combination of these two mechanisms.
Currently, VSS from Microsoft is most widely used across projects. We will learn the various features of configuration management by using VSS as the source control tool. VSS allows automatic version management eliminating the version naming conventions. Instead, it keeps a history of the previous versions of the same file through frequent check-ins or check-outs. Apart from that, the details of the check-ins and check-outs can be stored by labeling each version of an item. The labeling can also be used for automatic build management of the software at defined intervals by improving the tool using add-ins to VSS. VSS allows multiple degrees of folder level access control mechanisms to a group or at individual level. Parallel development is also possible through the usage of branching and merging of the main chain.
In this session, you have learned that:
- Software configuration management is a discipline used to manage and control change across the project software development life cycle
- The terminologies used in SCM are:
- Software Configurable Item, These are the components of a product that are to be controlled for managing change in a product. They are identified using naming conventions and version numbering
- Baseline, Is the formally agreed upon project plan
- Version Control, Identifies multiple instances of the same configurable item, uniquely
- Access Control, Is used to maintain integrity of configurable items
- The software configuration management plan documents the processes and methodologies that will be used to manage change in the project. It also identifies the roles of the team members who will be responsible for implementing change control in a project.
- The SCM plan includes Names of the SCM team members, Roles of each SCM team member, Name and location of project libraries, User access right for project libraries, Names of configurable items, Names of non version controlled items, Process for change control, and Process for status accounting.