Software Configuration Management(SCM) is an area, about which I had not written recently. So in a way, it was a long pending due, which had to be written. Recently I was asked by one of my blog readers, 'Veerendra', to write something about it and its role in Software Testing. So I thought of writing this article. Hope this helps...
Software Configuration Management(SCM):
As the systems being built today increase in software content, the need for software configuration management continues to rise. Prime contractors are integrating millions of lines of code from multiple subcontractors. Companies are required to produce and maintain variants of their main product to reach out to a diversified market. Project Manager/leaders are aware of the need to better manage and control their projects.
Change is a fact of life in software development:
Customers want to modify requirements, developers want to modify the technical approach, and management wants to modify the project approach. Modification is necessary, because, as time passes, all parties know more about what they need, which approach would be best, and how to get it done and still make money. The additional knowledge becomes the driving force behind most changes. But, these changes must be carefully controlled.
According to the Software Engineering Institute’s (SEI’s) Key Process Areas definition of software configuration management (SCM) (Paulk et al. 1993a; Paulk et al. 1993b), the purpose of SCM is to establish and maintain the integrity of the products produced throughout the project’s software life cycle. Knowing the state of the product that a project is developing and knowing that it satisfies the customer’s requirements are of utmost importance for any project leader. SCM then can be viewed as a support function that helps a project leader better manage and control the project (IEEE 1997).
SCM VS. Change Control:
SCM is often equated to change control. Indeed change control is a critical component of SCM, but it is only one of many. Following is a brief look at the components of SCM and how they connect to supporting a project leader’s ability to manage and control the project.
Configuration Management and the Use of Peer Reviews:
Configuration management status accounting can help the project leader make decisions on what degree of formality peer reviews should follow. For example: The product the project is building consists of 50 modules or units. Status accounting information reveals that 45 of the modules have changed once in six months, but five of the modules have changed 10 times per month for the past two months. With this configuration status information, the project leader can choose to conduct formal software inspections on the five modules that are experiencing rapid change and use less formal walkthroughs to ensure the integrity of the 45 modules that change infrequently.
Interface Control:
The definition of interfaces is one of the most important SCM planning and tracking activities (IEEE 1997). There must be agreement of each group or organization’s responsibility. Any proposed changes to the product or baselined configuration items can be considered and evaluated by all affected groups.
There are two basic types of interfaces that must be considered: organizational interfaces and technical interfaces. Organizational interfaces are those in which configuration management controls the transfer of configuration items from vendor to customer, project to project, and co-developer to co-developer. SCM ensures that the correct configuration items are sent to the correct people. Organizational interfaces also include life-cycle phase interfaces. Phase interfaces become critical when control of the product is being transitioned between different groups (for example, software development group to independent test group for formal testing). Technical interfaces are descriptions that should be placed under configuration management control like any other configuration item. Technical interfaces include system, user, software, hardware, and communication interfaces.
Subcontractor Control:
If a portion of a software development project is to be subcontracted (out sourced) to another organization, the responsibility for the SCM generally belongs to the contracting organization and specifically the project leader of the project that requires this outside support. The subcontractor is normally only responsible for the portion of the work that his or her organization is tasked to perform. The integration of the subcontracted work is normally the responsibility of the organization that subcontracted portions of the work.
An effective SCM system greatly increases the opportunity to have portions of the product subcontracted out and then integrated back into a whole that satisfies the customer’s technical and quality requirements. SCM must be applied to a subcontractor to ensure that the subcontractor is able to maintain the integrity of the subsystem for which it has contracted (Paulk et al. 1993a; Paulk et al. 1993b). This includes placing necessary life-cycle products under configuration control to ensure consistency with the main development effort and maintaining a subcontractor’s software library that will release the agreed-upon configuration items or subsystems to the contracting organization.
Software Configuration Audits:
Configuration auditing verifies that the software product is built according to the requirements, standards, or contractual agreement. Auditing also verifies that all software products have been produced, correctly identified and described, and that all change requests have been resolved (IEEE 1997; Kasse 1995).
A software configuration audit should be performed periodically to ensure that the SCM practices and procedures are rigorously followed. The integrity of the software baselines must be assessed and the completeness and correctness of the software baseline library contents must be verified. The accuracy of the implementation of the changes to the baselines must be verified to ensure that the changes were implemented as intended. It is recommended that a software configuration audit be performed before every major baseline change.
Software configuration auditing should be continuous, with increased frequency and depth throughout the life cycle. Types of configuration audits include functional configuration audits, physical configuration audits, in-process audits, and traceability audits .
SCM Plan:
The SCM plan is the document that describes how a project will manage configurations (Paulk et al. 1993b; Whitgift 1991). The SCM plan should cover:
# The scope of the plan, including the project, the software to be developed, and the life-cycle phases
# The relationship between the SCM plan and the other standards or plans that describe how the project will be managed (for example, software development, SQA plan)
# SCM roles and responsibilities
# Configuration identification
# Baselining
# Configuration control
# Configuration management status accounting
# Interface control
# Subcontractor control
# Software configuration audits
# Software library
Conclusion:
SCM is one of the most important process improvement tools that Project Manager/leaders/Test Mangers can use to evolve and deliver their product in a controlled manner. Knowing the state of the product that a project is developing and knowing that it satisfies the customer’s requirements is of utmost importance for any project leader. Since many of the most frustrating software problems are often caused by poor configuration management, proper configuration management is critical.
Even if an organization has little or no configuration management in place and is just getting started with a configuration management program, five simple steps will add a great deal of control and project tracking information:
1) Formalize the use of reviews before a configuration item is baselined;
2) Uniquely identify system components;
3) Establish simple change control;
4) Build up a repository of configuration items, change requests, and problem reports; and
5) Restrict access to the project library.
A good place to start is with simple status reports, which may include only the versions one has. When developing a change history, one can expand to a status accounting system, which includes who changed it, when, why, how, and what was affected, as described earlier in the article. Then, a configuration audit can be performed to make sure the approved change requests have been implemented completely and correctly. Once established, FCAs would be the next step to ensure that the system matches what was approved, and nothing more. Then, a physical audit can be added to ensure that the documentation matches the changes.
It is important to implement requirements traceability from the beginning through systems testing, implementing life-cycle work-product consistency checks. This means that if a requirements change request has been accepted, one must go through life-cycle phases to determine if it is necessary to make a corresponding change. Without the ability to trace through the life-cycle process, it cannot be done. Once one has the design document, he or she needs the ability to go backward and forward to look at the other life-cycle work products.
After expanding to multisite, multicountry, and multicultural projects, one may be looking at implementing at multiple levels of control boards and need to ensure that all parts are being managed and controlled with consistency and integrity. Otherwise, it cannot all be brought together and integrated into a working and maintainable system. Ultimately, some project managers are responsible for the entire integrated product!
Software Configuration Management(SCM):
As the systems being built today increase in software content, the need for software configuration management continues to rise. Prime contractors are integrating millions of lines of code from multiple subcontractors. Companies are required to produce and maintain variants of their main product to reach out to a diversified market. Project Manager/leaders are aware of the need to better manage and control their projects.
Change is a fact of life in software development:
Customers want to modify requirements, developers want to modify the technical approach, and management wants to modify the project approach. Modification is necessary, because, as time passes, all parties know more about what they need, which approach would be best, and how to get it done and still make money. The additional knowledge becomes the driving force behind most changes. But, these changes must be carefully controlled.
According to the Software Engineering Institute’s (SEI’s) Key Process Areas definition of software configuration management (SCM) (Paulk et al. 1993a; Paulk et al. 1993b), the purpose of SCM is to establish and maintain the integrity of the products produced throughout the project’s software life cycle. Knowing the state of the product that a project is developing and knowing that it satisfies the customer’s requirements are of utmost importance for any project leader. SCM then can be viewed as a support function that helps a project leader better manage and control the project (IEEE 1997).
SCM VS. Change Control:
SCM is often equated to change control. Indeed change control is a critical component of SCM, but it is only one of many. Following is a brief look at the components of SCM and how they connect to supporting a project leader’s ability to manage and control the project.
Configuration Management and the Use of Peer Reviews:
Configuration management status accounting can help the project leader make decisions on what degree of formality peer reviews should follow. For example: The product the project is building consists of 50 modules or units. Status accounting information reveals that 45 of the modules have changed once in six months, but five of the modules have changed 10 times per month for the past two months. With this configuration status information, the project leader can choose to conduct formal software inspections on the five modules that are experiencing rapid change and use less formal walkthroughs to ensure the integrity of the 45 modules that change infrequently.
Interface Control:
The definition of interfaces is one of the most important SCM planning and tracking activities (IEEE 1997). There must be agreement of each group or organization’s responsibility. Any proposed changes to the product or baselined configuration items can be considered and evaluated by all affected groups.
There are two basic types of interfaces that must be considered: organizational interfaces and technical interfaces. Organizational interfaces are those in which configuration management controls the transfer of configuration items from vendor to customer, project to project, and co-developer to co-developer. SCM ensures that the correct configuration items are sent to the correct people. Organizational interfaces also include life-cycle phase interfaces. Phase interfaces become critical when control of the product is being transitioned between different groups (for example, software development group to independent test group for formal testing). Technical interfaces are descriptions that should be placed under configuration management control like any other configuration item. Technical interfaces include system, user, software, hardware, and communication interfaces.
Subcontractor Control:
If a portion of a software development project is to be subcontracted (out sourced) to another organization, the responsibility for the SCM generally belongs to the contracting organization and specifically the project leader of the project that requires this outside support. The subcontractor is normally only responsible for the portion of the work that his or her organization is tasked to perform. The integration of the subcontracted work is normally the responsibility of the organization that subcontracted portions of the work.
An effective SCM system greatly increases the opportunity to have portions of the product subcontracted out and then integrated back into a whole that satisfies the customer’s technical and quality requirements. SCM must be applied to a subcontractor to ensure that the subcontractor is able to maintain the integrity of the subsystem for which it has contracted (Paulk et al. 1993a; Paulk et al. 1993b). This includes placing necessary life-cycle products under configuration control to ensure consistency with the main development effort and maintaining a subcontractor’s software library that will release the agreed-upon configuration items or subsystems to the contracting organization.
Software Configuration Audits:
Configuration auditing verifies that the software product is built according to the requirements, standards, or contractual agreement. Auditing also verifies that all software products have been produced, correctly identified and described, and that all change requests have been resolved (IEEE 1997; Kasse 1995).
A software configuration audit should be performed periodically to ensure that the SCM practices and procedures are rigorously followed. The integrity of the software baselines must be assessed and the completeness and correctness of the software baseline library contents must be verified. The accuracy of the implementation of the changes to the baselines must be verified to ensure that the changes were implemented as intended. It is recommended that a software configuration audit be performed before every major baseline change.
Software configuration auditing should be continuous, with increased frequency and depth throughout the life cycle. Types of configuration audits include functional configuration audits, physical configuration audits, in-process audits, and traceability audits .
SCM Plan:
The SCM plan is the document that describes how a project will manage configurations (Paulk et al. 1993b; Whitgift 1991). The SCM plan should cover:
# The scope of the plan, including the project, the software to be developed, and the life-cycle phases
# The relationship between the SCM plan and the other standards or plans that describe how the project will be managed (for example, software development, SQA plan)
# SCM roles and responsibilities
# Configuration identification
# Baselining
# Configuration control
# Configuration management status accounting
# Interface control
# Subcontractor control
# Software configuration audits
# Software library
Conclusion:
SCM is one of the most important process improvement tools that Project Manager/leaders/Test Mangers can use to evolve and deliver their product in a controlled manner. Knowing the state of the product that a project is developing and knowing that it satisfies the customer’s requirements is of utmost importance for any project leader. Since many of the most frustrating software problems are often caused by poor configuration management, proper configuration management is critical.
Even if an organization has little or no configuration management in place and is just getting started with a configuration management program, five simple steps will add a great deal of control and project tracking information:
1) Formalize the use of reviews before a configuration item is baselined;
2) Uniquely identify system components;
3) Establish simple change control;
4) Build up a repository of configuration items, change requests, and problem reports; and
5) Restrict access to the project library.
A good place to start is with simple status reports, which may include only the versions one has. When developing a change history, one can expand to a status accounting system, which includes who changed it, when, why, how, and what was affected, as described earlier in the article. Then, a configuration audit can be performed to make sure the approved change requests have been implemented completely and correctly. Once established, FCAs would be the next step to ensure that the system matches what was approved, and nothing more. Then, a physical audit can be added to ensure that the documentation matches the changes.
It is important to implement requirements traceability from the beginning through systems testing, implementing life-cycle work-product consistency checks. This means that if a requirements change request has been accepted, one must go through life-cycle phases to determine if it is necessary to make a corresponding change. Without the ability to trace through the life-cycle process, it cannot be done. Once one has the design document, he or she needs the ability to go backward and forward to look at the other life-cycle work products.
After expanding to multisite, multicountry, and multicultural projects, one may be looking at implementing at multiple levels of control boards and need to ensure that all parts are being managed and controlled with consistency and integrity. Otherwise, it cannot all be brought together and integrated into a working and maintainable system. Ultimately, some project managers are responsible for the entire integrated product!
thanks
ReplyDeleteNice information give about the software configuration.
ReplyDeleteInstitute Management Software