User:R. Koot/Method engineering/Software configuration management

From Wikipedia, the free encyclopedia

You have new messages (last change).
"SCM" redirects here. For other uses, see SCM (disambiguation).

Software Configuration Management (SCM), as part of Configuration management (CM), is a method to control and manage the software development process.

According to Bersoff (1997) SCM can be defined as “the discipline of identifying the configuration of a [software] system at distinct point in time for the purpose of systematically controlling changes to the configuration and maintaining the integrity and traceability of the configuration throughout the system life cycle”. Contrary to its age SCM has an extensive history..

This entry is part of the Method Engineering Encyclopedia, constructed by MSc Business Informatics students of the Utrecht University (The Netherlands).

Contents

[edit] Goals & benefits of SCM

The main goal of SCM is to identify, control, maintain, and verify the versions of software configuration items. Babich (1986) argues that the art of SCM lies in the coordination of the software evolution process, by which confusion and resulting mistakes are minimized, and productivity is maximized.

The goal of SCM benefits the organization in four major ways (Futrell et al., 2002):

  • Control: SCM offers the opportunity to review, approve, and incorporate changes to the configuration item. It provides a standard method for change, maintenance, traceable changes, and controlled changes to the baseline of the configuration item.
  • Management: SCM provides a process of automatic identification and guidance of configuration items in their whole life cycle.
  • Cost Savings: Throughout the whole life cycle of a configuration item cost savings can be realized by using SCM. By actively defining, tracing, and auditing configuration items, failures can be detected early, and corrective action can be taken. No confusion in task division can occur.
  • Quality: Deliverables are checked continuously during the software development process. By checking the human-work in an automated way, the level of compliance of deliverables with predefined requirements can be maximized.

[edit] Overview

Figure 1: Main activities in the SCM Process
Enlarge
Figure 1: Main activities in the SCM Process

The SCM process can be generalized as depicted in figure 1. This diagram consists of the six main activities of the SCM process, on which will be elaborated in the next section. It makes clear that the initial step creates the context of all following activities. Also, ‘’Software Configuration Identification’’ is relevant for the whole process. Notice that the process between ‘’Software Release Management & Delivery’’ and ‘’Software Configuration Control’’ is iterative.

Figure 2: Process-data diagram for SCM
Enlarge
Figure 2: Process-data diagram for SCM

A more comprehensive view on the SCM process is obtained by summarizing the topic in a process-data model (Saeki, 2003). This overview (figure 2) is created using the meta-modelling technique. Next to the main activities (figure 1), also sub-activities are given. Both are recognizable as ovals and displayed at the left side (meta-process model). The roles of parties involved are given between brackets. At the right side the main concepts and deliverables are given are rectangles (meta-data model). The right side uses the modelling grammar of class diagrams (part of UML). For both sides the style of the shapes have got the same meaning. Plain boxes represent simple concepts or activities, dark-mirrored boxes represent closed concepts or activities (but not elaborated on irrelevant sub concepts), while open-mirrored boxes represent open concepts or activities (relevant sub concepts are elaborated upon).

The section ‘Activities’ will explain the actions in each phase. Then the ‘Roles’ section describes the responsibilities of all involved roles. The main concepts are explained in ‘Concepts’ section.

[edit] Activities

The process-data diagram (figure 2) describes the activities of the SCM process at her left side, represented by oval boxes. This section elaborates on those activities in order to make clear what happens at each stage. The division of activities is mainly based upon Scott & Nisse (2001). A comprehensive list of activities and sub activities, including a short definition, is given in the appendix.

[edit] Management of the SCM process

The initial phase of the SCM process considers the context wherein the process has to occur. To plan this process it is essential to know the organizational structures and their relationships. Sometimes the software development process is conducted parallel to hardware or firmware development or selection procedures. It is necessary to have a good overall picture of those related items before the SCM planning is conducted.

The next sub activity gathers the available guidelines and constraints for the SCM process. Guidelines can come forth of standards or preferences from the customers. Constraints may be corporate policies or contracts with stakeholders.

Based on the context, constraints, and guidelines a sound SCM plan (SCMP) should be created. In this plan the objectives of the other SCM activities, which will be discussed later on, will be designed. Other issues to be addressed are responsibilities for tasks and organization, planning of (human) resources and scheduling, use of SCM tools and their implementation, decisions about third parties, vendors or subcontractors to be involved, and finally the identification and control planning of interfaces to external components.

The execution of this SCMP should be supervised. There are SCM tools which are capable to support the process control task. Surveillance leads to further SCM process optimization by continuously process improvement.

[edit] Software Configuration Identification

The goal of this activity is to identify the software items that need to be controlled. This is based on the product structure modelling process. This is the process of breaking down the product (baseline) into several parts and items (software configuration items). Also, identification schemes are created for configuration items and their versions (part of version & variant management). Tools should be selected and implemented in order to acquire and manage the controlled items. This phase is repeated as new items need to be created during the SCM process. It is essential to understand the software configuration (the context wherein one can identify a configuration item), and to describe their relationships. Essential for this phase are the procedures to define a baseline for an item. Also the baseline versions should be defined.

All the controlled items should be stored in a central software library. This centralized space collects all versions, and related documentation.

[edit] Software Configuration Control

This phase concerns the management of changes to configuration items during the software product life cycle. The process starts when new changes are identified with a change request (essential part of change management). During the whole software life cycle, change requests can be initiated by users and developers of the software. A standard process for handling change requests should be created. This document should describe the formal procedures for handing in and recording change requests, evaluate costs and impact, and accept, modify or reject the request. When the change request is approved by the Software Configuration Control Board, an implementation plan is created. This plan describes the procedures how the change requests are converted to a tangible solution.

Sometimes there are constraints in the software development process for which no satisfying solutions can be found at that point in the software life cycle. Then, deviations and waivers should be created.

Often the basic software building blocks are used for several related products of a manufacturer. In that case this phase of the SCM process is more complicated due to proper product family modelling.

[edit] Software Configuration Status Accounting

To control the configuration items, it is essential to record and report about the current state of affairs. An automated system will be used to capture and report all relevant information during the life cycle of a software configuration item.

The collected information will be used as input for the development team, the maintenance team, project management, and quality assurance activities. Reports can be periodic or ad-hoc. This feedback can be used to improve the system by directed recommendations.

[edit] Software Configuration Auditing & Validation

Software is subject to many regulations, guidelines, constraints, plans, and procedures. On a regular base this compliance should be checked by a software audit. This activity assures an independent evaluation of the conformance of the configuration item under study. Audits are conducts following standard (detailed) process descriptions.

There are three fields of interest for audits: functional configuration, physical configuration, and in-process audits of the software baseline. The functional configuration audit concerns the question if the item is similar to the prevailing specifications. The physical audit considers if the technical documentation is consistent with the built software. The last form of auditing, in-process of baseline, investigates the status of several elements of the configuration. A purpose of this last audit is to check if the current baseline meets the specifications.

[edit] Software Release Management & Delivery

This last phase of the SCM process is dedicated to the release of a software version. The correct baseline, composed of baseline versions of configuration items, is compiled to an executable program. This executable can be delivered to any recipient, for purposes of testing or distribution to customer. Specific build instructions are needed to guarantee that the build steps are taken and that they are performed in the right sequence. Sometimes different versions of the same product should be built (for platform, customer, functionality, etc.). The area of software engineering concerned with this process is build management.

When an executable program is created, the program should be delivered. This can occur to external or internal customers. Internal customers are just interested in the file and technical documentation. For external distribution some additional steps should be taken, such as inserting a manual, release notes, and put it in a box. The topic on release management elaborates on this activity in more detail.


[edit] Roles

In figure 2 the roles involved in each activity are given between the brackets. In total we can identify four different roles in the SCM process. As the SCM process is mainly managerial, only those roles are discussed here.

[edit] Software Configuration Management Group (SCM Group)

The Software Configuration Management Group has to define the inventory of software and related documents to be controlled during development. Also the baseline versions which are in use at the start of the project are identified. New releases of an application are updated in the software library.

The SCM Group is identified by the Project Manager, and has a role in the ‘’Software Configuration Identification’’ phase.

[edit] Project Manager (PM)

The Project Manager is most active in the first part of the SCM process. The first tasks are to assist the SCM Group with the identification of the initial software library. Also, the Software Configuration Management Plan is written by the Project Manager. This person keeps further control over the whole process.

The Project Manager is involved in all steps, with more focus on Management of the SCM process, Software Configuration Identification, and Software Configuration Status Accounting.

[edit] Software Configuration Controller (SCC)

The Software Configuration Controller (SCC) has a central role in the SCM process. First it assists and leads the SCM Group. After identifying the baseline of the software library, the SCC is further responsible for updating the library. So inserting new or changed items and the check-in/check-out processes are conducted by the SCC. Also the initial implementation of the software library management system is done by the SCC. The SCC performs audits on new versions and defines baseline candidates. The SCC also controls the Release Management process for building and releasing new applications.

The SCC is involved in the Software Configuration Identification, Software Configuration Control, Software Configuration Auditing & Validation, and Software Release Management & Delivery. The SCC is appointed by the Project Manager.

[edit] Software Configuration Control Board (SCCB)

The Software Configuration Control Board (SCCB) is responsible for the authorization of new baseline versions. They review baseline candidates (identified by SCC), and approves all changes to configuration items as identified in the SCM plan. They also approve the SCM Plan and separate the whole software project into several components which are assigned to project managers. When a new release is proposed by the SCC, the SCCB has to approve this release from the baseline.

The SCCB is involved in the Management of the SCM Process, Software Configuration Identification, Software Configuration Control, and Software Release Management & Delivery.


[edit] Concepts

In the process-data diagram (figure 2) some concepts are identified at the right side (rectangles). Now the most important concepts are addressed and those not already present in Wikipedia are explained. In the appendix a comprehensive list of concepts is given.

  • AUDIT REPORT: Document containing the evaluation of the conformance of software product and processes to the applicable regulations, standards, guidelines, plans, and procedures (Scott & Nisse, 2001).
  • BASELINE
  • CHANGE REQUEST: A petition for modifying the behaviour of a system due to normal business changes or because there is a bug in the system (TheFreeDictionary.com).
  • CONFIGURATION ITEM (= Controlled Software Configuration item)
  • DEVIATION: Authorization to depart from a provision prior the development of the item (Scott & Nisse, 2001).
  • EXECUTABLE FILE
  • IMPLEMENTATION PLAN: Document that outlines how the requests should be implemented and when (Scott & Nisse, 2001; edited).
  • IN-PROCESS REPORT: Summary of audit performed during the development process aimed at investigation of the current status of specific elements of the configuration (Scott & Nisse, 2001).
  • RELEASE
  • RESULT REPORT: Summary of audit performed at a (controlled) software item (Scott & Nisse, 2001).
  • SOFTWARE ADAPTATION: Solution to provisions that cannot be satisfied at the designated point in the life cycle (Scott & Nisse, 2001).
  • SOFTWARE CHANGE DOCUMENT: Document specifying the approved changes to be made in a system (Scott & Nisse, 2001; edited by author).
  • SOFTWARE CONFIGURATION MANAGEMENT PLAN: Living document that serves as a reference for the SCM process (Scott & Nisse, 2001).
  • [library (computer science)|SOFTWARE LIBRARY]
  • TECHNICAL SOFTWARE DOCUMENTATION
  • VARIANT: New version of an item that will be added to the configuration without replacing the old version (Scott & Nisse, 2001).
  • VERSION
  • WAIVER: Authorization to use an item, following its development, which departs from the provisions in some way (Scott & Nisse, 2001).

[edit] SCM Tools

The SCM process should get support from SCM tools in order to keep track of the ambiguous and complex process. There is a huge collection of tools, each with its own core competences. Most of these tools embed ‘best practises’ to perform the SCM process, and so they deviate a bit from the standard process presented in figure 2. Mostly, change management and configuration management are joined in an integrated tool: SCCM (Software change and configuration management).

The selection of the right tool is a complicated process. Futrell et al. (2002) argued 11 selection criteria to consider: multi-user support, intuitive GUI, conformity to the organization’s development environment, scalability, flexibility in integrating other software development tools, ease of setup, modifiable models, process management, extensive support for the development phase, management of non-development objects, and permission management. As most of the commercial tools available support those criteria, it is essential to ask yourself what your project requirements are, how each tool can contribute to the critical success factors of your project, and conduct an extensive market search for all tools.

Some examples of SCM Tool vendors are given in table 1.

Name Vendor
AllFusion CA-Pan/LCM Configuration Manager Computer Associates
ClearCase IBM (former: Rational)
PVCS Professional Serena
Perforce Perforce Software
Razor Visible Software
Sablime Lucent Technologies
Synergy/CM Telelogic
Visual Enabler Soft Lab
Visual Source Safe Microsoft

Table 1: Examples of SCM Tools


[edit] Example

Software Configuration Management is known as a very complicated process. Therefore a practical example of a tangible product can enlarge the insight of the practitioner. The next steps are a walkthrough through the SCM process for the firmware of a mobile phone. We will focus on the software that has to be written for the functioning of the device. The process is graphically illustrated in figure 3.

Figure 3: Mobile phone example of the SCM process
Enlarge
Figure 3: Mobile phone example of the SCM process
  • SCM Process Management: The goal of this project is to design a single platform firmware for a family of mobile phones of one vendor. Some functionality is given as constraint, even as some milestones on the timeline of the process. Guidelines are retrieved from earlier firmware development processes, and are for example that a small core-functionality should be designed initially which is extended with more functions later on. The SCM plan is created and describes which activities should be passed through and procedures for some sub activities are set.
  • Software Configuration Identification: A basic set of software artefacts are identified as configuration items, in this example classes for the mobile OS. The company selects IBM Rational ClearCase as the SCM Tool, and implements a compatible software library to store the configuration items, and later on their versions, and technical documentation. Relationships between objects in the software library are identified.
  • Software Configuration Control: An external actor, e.g. a customer, complains about a bug in the firmware. This complaint is converted to a change request, which is approved by the SCCB. The required changed are implemented to the old version, and a new version is placed into the library. The Configuration Identification phase is now repeated to check if this version should be stamped as new ‘baseline’.
  • Software Configuration Status Accounting: The project manager keeps track of the development process. He frequently creates reports with status information. When he identifies shortcomings, or interpretation failures, he directly gives feedback to the responsible software developers to correct it.
  • Software Configuration Audit & Validation: An independent body of software engineers frequently audits the new software versions, and validates if those versions are confirm the prevailing regulations and guidelines. For example if the requested Bluetooth-functionality is only available to the intended mobile phones in the family. The audit team can consist of engineers from another project team (e.g. other mobile phone family).
  • Software Release Management & Delivery: When the project manager identifies a completed status in the status accounting phase, it is time to build the releases of each member of the mobile phone software family. After building, internal tests at the manufacturer can be conducted, where after external delivery consist of nice looking boxes, user documentation, and the phone including software.

[edit] See Also


[edit] References

  • Babich, W.A. (1986). ‘’Sotware Configuration Management, Coordination for Team Productivity’’. 1st edition. Boston: Addison-Wesley
  • Bersoff, E.H. (1997). Elements of Software Configuration Management. ‘’IEEE Computer Society Press, Los Alamitos, CA,’’ 1-32
  • Futrell, R.T. ‘’et al.’’ (2002). ‘’Quality Software Project Management.’’ 1st edition. Prentice-Hall.
  • Saeki M. (2003). Embedding Metrics into Information Systems Development Methods: An Application of Method Engineering Technique. ‘’CAiSE 2003,’’ 374-389.
  • Scott, J.A. & Nisse, D. (2001). Software configuration management. In: ‘’Guide to Software Engineering Body of Knowledge’’. Retrieved February 15, 2006, from

http://www.swebok.org/stoneman/version_1.00/SWEBOK_w_correct_copyright_web_site_version.pdf

[edit] Appendix

Next the comprehensive activity (table 2) and concept (table 3) tables are given. The activities and concepts are mainly derived from Scott & Nisse (2001).

Table 2: Activity table
Enlarge
Table 2: Activity table
Table 3: Concepts table
Enlarge
Table 3: Concepts table
Retrieved from "http://en.wikipedia.org../../../r/2E/_/User%7ER._Koot_Method_engineering_Software_configuration_management_82b0.html"
In other languages