Configuration Management/SPM

Configuration management (CM) concepts were created by the United States Department of Defence in 50’s. Those concepts were approved and implemented by various management modules and standards. CM is a management discipline as a baseline for other subcategories like Software Configuration Management which is put into practice in software engineering.

CM is the controlled way to manage the development and modifications of systems and products, during their entire life cycle.

In general Configuration Management and Software Configuration Management issues and resolutions are the same, but SCM is concerned with all the things having to do with building and deploying well tested, reproducible software builds. SCM is throughout the whole software development life cycle and concerned to achieve desired results at the end.

To realize it there is a wide range of CM tool vendors that provide an environment, defined methods and processes to support software developers and project managers on a daily basis. This is important because software is deployed in a cycle, and the uptake of this cycle can vary widely and can mean that features that are currently deployed in the field have been significantly changed or rewritten by developers, meaning that bugs found in the field will require developers to revisit old code.

SCM is becoming more adopted and significant due to Capability Maturity Model Integration developed by Software Engineering Institute. Significance in CMMI to achieve level two to five appraisal, CM utilize a great role.

CM System Functionality and Integration

Software Configuration Management could be grouped in the domain of significance that encompasses key functionalities. Software system architecture describing the build-up of the system includes rules and procedures within software application functionality and user interfaces. In distributed environment importance of data representation and communication between distributed objects, protocols and message interchange between client/server applications.

Data representation in software engineering is generally represented as a file system with files and directories to manage data and metadata. Data replication in distributed environment is dealing with repositories, backup systems and client/server applications in SCM. Focus on distributed computing applications, SCM tools treating distributed objects as peer-to-peer applications. Distributing data and metadata is managed synchronized; deadlocks and access rights to the data are applied, particularly in version control.

For application integration there are many tools available in SCM. Support for information exchange between other applications is provided. Development environments are often designed as a tool within a tool. Integrated Development Environments (IDE) often provides additional capabilities for version control besides compilation of the code that can be checked in/out from repositories.

Software Configuration Management

Version Management

The concept of version management

Version management is the basic function in software configuration management. All of elements should be auto-given specific version label, to ensure it’s unique. It is also a process to identify and track within different system versions. The purpose of version identification is to differ, search, and track system versions, it represents the relationship with versions. Any of one version should be unique and differ from other versions on its functionality and capability. In every one version, the defect should be fixed, or some shortfall will be added or amended.

The access privilege should be configured according with the position and status of the baseline. Generally, before the baseline version, all versions should be locked. If it needs some change on those versions, it should do operation based on the process of the change control.

Advantage of version management

• Ensure the system can restore or go back to any version in history.
• Traceability between versions
• Providing help on finding bugs

Version Models

• Check In/Check Out Model
• Composition Model
• Long Transaction Model
• Change Set Model

Configuration Selection

Selection of configuration management tools for any software project are driven by a number of factors.

• Pre-existing solutions
• Company Culture
• Availability of solutions
• Resource constraints

Use of SCM tools are widespread and many organizations will have an established SCM system in place. However in organizations that do not have such and SCM system in place, a procedure along the following lines can be employed:

• Establish an Evaluation Group
• Set out Evaluation Criteria and Prioritized Requirements
• Research and choose tools for evaluation
• Compare tools and make final decision

CMM and SCM Selection

CMM designates CMM as a key Process Area (KPA) and sets out requirements for planned use of SCM within an organization. These requirements will govern how SCM solutions are chosen in any organization. The factors that will influence the choice of SCM tools are mainly concerned with training and resourcing of both a specific SCM group as well as the everyday users of the SCM system. Procedures are defined by the SCM group that govern the structure and use of the SCM system.

CMM lists activities performed in the KPA which will constrain the types of SCM tool that can be chosen. However almost every SCM tool will meet these requirements. In short while CMM indirectly shapes the type of SCM tool used, it does little to list specific requirements.

Further reading

Configuration Management Principles and Practice, Anne Mette Jonassen Hass, Chapter 26. Tool Support for Configuration Management Implementing ITIL Configuration Management, Larry Klosterboer, Chapters 2, 3, 4, 5

Build Management

After development of source code the software is passed on to the software quality team who takes responsibility for system testing. Should any faults be discovered during system tests, the software quality team sends back the source code to the development team for repair. The repaired version comes back to the quality assurance team where the source code is checked again for quality. If the quality is acceptable the source code is then considered controlled system which means that changes have to be agreed on and recorded before being implemented. Every version of accepted source code must be placed under configuration management. These versions are stored for later release into production. The concepts of Configuration Management describe these processes in more detail.

Release Management

Software eventually needs to get released to the end users and this is what the procedure of Release Management is for.

The software being released is linked with the “Build Management” process because the software being released comes from a production build of the Build Management process. This software could be in different forms, e.g. patch, upgrade or full version releases.

During the process of Release Management the software is finalised for release to the end users. Release Management is made up of four parts:

[Source: [1] ]

1. Change Management – version control of changes
2. Build Management – building software under controlled measures
3. Deployment – fully tested then sent to production
4. Incident Management – this includes keeping track of any issues that may arise that would affect production or require the production process to change.

Release Management, while mainly thought of for releasing runtime files, can also be used in releasing related files. Related files are:

1. Configuration Files – specific installation configuration
2. Data Files – for the system to work
3. Installation Program – to help the end users to set-up the program on their machine
4. Documentation – electronic and/or paper documentation to describe the system and its operations, functionality, etc
5. Packaging – logos, boxes, pictures, etc for the release

It is up to the customer to decide whether or not they want to install the release – they may be happy with their current installation.

Issues such as how to release the product (CD, DVD, downloadable, etc), documentation to include, marketing (packaging, etc) need to be decided during the process.

The main benefits of Release Management to companies are increased customer satisfaction (from more efficient release cycles) and reduction of costs.

Workspace Management

Increasing amount of a large scale software projects require workspace managements for groups and individuals. In Configuration Management Workspace Management is a very important module. Workspace Management deals with private isolated workspaces and shared. For multiple developers to work on projects transparently, CM tools should provide transparent environment to developers rather than managing individually, regarding access rights, synchronisation to files check in/out, build/make functionality and file merging, this encompasses concurrent control and development.

Change Management

Changes in software occur throughout the development lifecycle. Those changes can be added functionality, bug fixes, improvements of the module. Change Management deals with these issues to provide standard and efficient methods to implement and trace those changes.

The goal of the Change Management process is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of change-related incidents upon service quality, and consequently improve the day-to-day operations of the organization.

Change Management does not predict any changes but it handles the changes that occur during the development and maintenance phase. Traceability is a part of the Change Management. Valuable information may be acquired from that and valuable metrics can be extracted.

Concepts in CM Systems

Component Concepts

In order to apply configuration management effectively, it’s important to have the fundamental concepts in place. There are 4 main activities to consider:

Identification

The “Identification” process is concerned with uniquely identifying a configuration item and its relation with other configuration items. A configuration item is an item produced in several versions and placed under configuration management. The description of the configuration item which is included while storing the item is called Metadata. Metadata is a database concept that means data about the data stored in a database. Therefore the initial process in configuration management is to identify configuration items and their description in the form of Metadata.

The identification process can be initiated as a result of two main incidents. For example when a project plan includes deliverables in response to the project scope it can be assumed that this deliverable will be designed, developed, tested etc. This deliverable must be placed under configuration management.

On the other hand a change might be required on existing configuration items. Such a change is initiated through a Change Request. The result of such a change is automatically a new version of the existing configuration item and therefore must be placed under configuration management.

Storage

With all deliverable products it is important have a storage system in place so that the products can be accessed and kept safe from damage or loss. This storage system can be any physical implementation, for example in the form of a file server, archived optical media, etc. An important aspect of this storage system is that there is the ability to record registration and release information about the items.

Storage involves three main processes:

• Placement in storage from the production/ development

In this event the item has reached a state where it’s ready to be placed under configuration management – in other words when it has been approved.

• Release from storage for usage

Should the item be required for usage, a release request is initiated to grant permission and distribution of the item.

• Release from storage for production/ development

This occurs in the case of the requirement to develop a new version of an existing configuration item. The release from storage back to production is initiated through a Change Request. In this case it is important to have control in place to ensure redundant changes being applied at the same time.

Change Control

It is not uncommon for configuration items to be prone to change. Business requirements can change or evolve over time or sometimes a configuration item performs different than expected. Changes of products are then necessary to adapt the business requirements. Change control manages Change Requests and actual changes made to products. For configuration items it is important to have a record to trace any change to its predecessor and where, when and by whom the change was made.

Examples of events where Change Control is initiated:

• A specification problem caught during a walkthrough
• A coding error found during an inspection
• An enhancement request from a customer
• A marketing request for additional features
• A problem report from a customer
• A business opportunity, for example a migration of the product to a new platform

Status Reporting

In order to have a clear understanding of the state configuration items and changes being made to products Status Reporting tools provide the necessary information to manage a product’s development and maintenance in readable manner.

Status reports include:

• Release notes
• A configuration item list
• A traceability matrix

Process Concepts

Context Management

In complex applications involving detailed workflow and intrinsic relationships between data files, context management tools can shield a user from much of the complexity involved in carrying out a task. Context management tools will effectively track the actions of a user, continuously managing dependencies and versioning for relevant data files as well as storing related worksets as a working context for a given action. The context is persisted and the user can leave and return to a given action as desired. The relevant context will be restored and the user can carry on from where the left off. The benefit to the user is that

• they do not have to concern themselves with low-level SCM actions for individual files and interdependencies
• relevant worksets can be represented as a single entity or collection of entities, rather than a collection of files scattered around an SCM storage system
• work can be paused and resumed as required and it is easy for the user to return to a specific task without having to concern themselves with configuring a specific environment, as the context will take care of that.

Context Management is widely used in medical applications and is a generally useful in assisting workflow.

Contract

A software development process will often require the deliver of certain items based on a given set of inputs and procedures. A contract defines what those inputs are and the process and deliverables for that process item. Inputs and outputs may be configuration items. By following the contract, process is guaranteed, defined outputs are delivered and process is easily measured against contract milestones.

Change Request

Change request manages the work flow required to execute a change request. Evaluators will be identified and assigned for an incoming change. Once evaluated the change will be approved or denied. If approved suitable team members will be assigned. Changes will be carried out and verified before finalizing and qualifying the change. Only then can the change request be finalized.

Life Cycle Model

The life cycle model applies to the means of managing SCM items through the phases of the life cycle of the product and is intrinsically linked with the software development model chosen. The life cycle model for a project using a waterfall process would focus on the transitions from stage to stage, and the handoff and interactions between development, testing, release and production. For an Agile project, the life cycle would need to cater for throw-away prototypes, rapid change and frequent releases.

Structure and Construction Concepts

Change Set

A change set is made up of a difference relationship, the related files and information about changes. A difference relationship is an abstract of the differences between the versions of components.

If changes to a configuration are made, they are recorded in a change set. These change sets can be used to have customised configurations of the software.

The information recorded includes:

• The changes made to the files in the configuration
• Why the changes were made (the reason)
• Who made the changes
• When the changes were made

The places where the changes are recorded depend on the scope. The scope is defined by the user e.g. fixing a bug, resolving an issue number (from a tracker system), etc.

Each change set is given a specific name. The user selects the change set to apply from the “default” configuration.

The change sets can be based on previous change sets or can be new ones. By using the change sets, users can pick and choose different configurations for their current needs.

System Modelling

System Modelling details how the system is made up (its structure), the different components in it, and the build process of the system.

In System Modelling there is a “family” which is used to keep track of the different versions of a project. This “family” contains a history of all the different versions associated with the date and user that created them.

Jasmine is a system model that is textual in nature. It is modified by the users and tools can use this to do their work. It is described by sets and functions. These sets and functions represent different types of information:

1. Relations between product components – module makeup, dependency of components, order of build, “templates” (description of all relations).
2. Version binding information – notion of a “family” [see above]
3. Construction rules – how components were build / are to be built, what compiler and version was used, arguments for the compiler, etc.
4. Verification rules – are the compiled files correct and valid, etc.

With all the relationships and rules recorded with Jasmine, the tools accessing it can make better assessments on what components would be affected from the result of changing another component.

The integrity of the project is helped by System Modelling because of the way it helps describing the configuration, dependencies, etc.

Subsystem

The idea of a subsystem is the division of a large project into smaller sections. When a user makes changes, then the changes are limited to the subsystem rather than the entire project.

Each subsystem is regarded as a separate project when working with it – it has its own version control system, etc.

Unless specified that components are to be exported in an interface, subsystems cannot access components of other subsystems.

The “Rational” environment can be used to manage subsystems. It does checks like checking to see if the subsystem implements an interface correctly, etc.

The users can select different subsystems and put them together to form a version of the overall application.

Object Pool

The “Domain Software Engineering Environment” (DSEE) can generate objects, which are placed into an “Object Pool” for each of the users to share and use. The objects are generated from the information available from system modelling. Different versions of components with different properties, etc can be generated and placed in the object pool.

Each object in the object pool has metadata associated with it; version, source, etc.

When a user wants to build a system and one part of the system is a custom version, if that custom version has already been generated and placed in the object pool, then that can be used rather than building it again. When the objects expire they are removed from the object pool to save space, processing time, etc.

Attribution

With attribution, a system is defined as a data model in an ERD database. The components of the system are represented as objects and all the relationships between it and the other components are represented in the database. The attributes (name and value pairs) are linked with the objects in the database.

Attributes can be predefined or user-defined. An example of a predefined attribute is “type” which is used to describe if the object is a document, a component, etc)

The dependencies between the components are represented as relationships in the database, e.g. one object is associated with another.

By using attributions, a user can describe a system in an abstracted manor rather than a full configuration of files, data, documents, etc.

Consistency Maintenance

Consistency maintenance is used to check if the configurations are valid. The Configuration Management Assistant (CMA) does the validation and usability checks. Usability checks ensure that the configurations:

• Have complete configuration
• Are Unambiguous
• Are Consistent
• Lack version skews

By having usability checks, CMA ensures that all component instances are in the configuration and only one instance of the component exists.

When a new configuration is created, CMA uses the information already acquired in the database to check if the new configuration is usable. By doing this, any issues with the configuration can be detected and consistency can remain intact.

Team Concepts

Work space

• Private work space

According to the requirement, every developer works in different work space in different develop phase. In private space, developer works on his private branch after get the operation admission. All of his contribution and progress will be present on this private branch version. Except the developer himself, other team members all could not operate any one of data on this private space.

• Integration work space

This work space is a public space for develop team. The team leader has the privilege to read and write on this work space. Within the team, any of team members only can read on this work space.

• Public work space

Public work space is to store the achievement for the whole develop teams. The standard version is provided in this work space as the knowledge base for the whole organization.

Transparent View

Every team member would be given the READ privilege to do read operation on work space.

Configuration Management Standards

ANSI/EIA-649 National Consensus Standard for Configuration Management

This standard is for use in Configuration Management and contains details of CM terminology and a CM process. This process is defined by 5 Configuration Management functions and their underlying fundamental principles.

The standard is there “to maintain consistency between the product definition, the product's configuration, and the CM records.” [Source: “CM Standards, ANSI/EIA-649-1998 and MIL-STD-973 (1992) Relative to CMII (Rev B)]

This standard supersedes the “MIL-STD-973 Configuration Management” standard.

Federal Standard 1037C

This is known as “Telecommunications: Glossary of Telecommunication Terms” and is in the public domain. It was developed and published by the US government.

The document provides a large base of telecommunication terms and definitions for use by US government and international specialists.

In 2001, this standard was replaced by ANSI T1.523-2001, “Telecom Glossary 2000”.

GEIA Standard 836-2002 Configuration Management Data Exchange and Interoperability

GEIA is an acronym for “Government Electronics & Information Technology Association”.

The standard covers exchange of CM data using XML.

“"EIA-836 facilitates the interoperability and exchange of CM data by clearly delineating CM data elements and their relationships, and by providing the information content of CM data exchanges. The level of interoperability between dissimilar systems is determined by trading partner agreement. The extensible markup language (XML) facilitates data sharing and exchange among different systems. EIA-836 provides a set of standard definitions and business objects that can be used by XML frameworks in interfacing the content elements among one or more systems or databases.

EIA-836 is designed to have wide applicability across vertical industries. The process employed to provide access, sharing or exchange, is typically accomplished using one of many available product data management tools or systems, often customized to a specific organizational environment. To be most effective, the capabilities of the process, tools or systems, should embody the CM principles in ANSI/EIA-649 "National Consensus Standard for Configuration Management;" in conjunction with the business objects and data element definitions in EIA-836.” [Source: GEIA website]

This standard is related to the “ANSI/EIA-649 National Consensus Standard for Configuration Management” standard.

IEEE Std. 828-1998 IEEE Standard for Software Configuration Management Plans.

When designing a Software Configuration Management Plan, this standard sets out the minimum required articles needed as well as what activities need to be completed in each part of the product life cycle.

The following information is from the Swiss Association for Quality:

Project Scope: This standard establishes a required format and set of minimum contents for Software Configuration Management plans. It identifies requirements for configuration identification, configuration control, configuration status accounting and reporting, and configuration audits and reviews. It applies to entire life cycle of critical software. It also applies to non critical software and to software already developed. The application of the standard is not restricted to any form, class or type of software. In addition, it will establish a correlation between the content of software configuration management plans as defined in 828 and the content of such plans as defined in IEEE 12207.1, Guide for Information Technology - Software Life Cycle Processes - Life Cycle Data by adding an annex which will correlate the assumptions relating to content of the two documents and trace content between subject documentation.

Project Purpose: To achieve harmonization of the content definition for software life cycle process results among the IEEE software engineering standards and with related international standards.

MIL-STD-973 Configuration Management

This was a US Military standard and superseded MIL-STD-480, -481, -482, -483, -1456 and sections of MIL-STD-1521. The standard set out definitive Configuration Management Tasks for US Military contractors to follow. This standard has been discontinued.

The successor to this standard is the "ANSI/EIA-649, National Consensus Standard for Configuration Management" standard.

The following information is from the Swiss Association for Quality:

Configuration Management Planning, Configuration Management Identification, Configuration Control, Configuration Status Accounting, Configuration Audits

This standard defines configuration management requirements which are to be selectively applied, as required, throughout the life cycle of any configuration item (CI). Configuration management requirements for software have been included. Where requirements are common to both hardware and software items they are shown as requirements for CIs, where are not common, they are shown as requirements for computer software configuration items (CSCIs) or hardware configuration items (HWCIs)

This standard established requirements in the following areas:

• Configuration management plan
• configuration identification, configuration
• control and audits
• interface control
• engineering release control
• configuration managements reports/records.

Contracts invoking this standard will specifically identify the appropriate applicable paragraphs and appendixes or portions thereof as defined in the contract work statement depending upon the scope of the program, and the complexity of the item being procured.

Testing and Version Control

Relationship between testing and version control

Testing starts on each new version and ensures the basic function works well on each version (baseline version or fix version). Incremental published version reduces the workload and pressure on testing. On the incremental version, testing will be only focused on basic function and those changed functions or bug fix. Version control provides an easy and comparable way on test result.

Unit Test

Unit test a testing method running by the developer. The developer should make sure his code would work on the daily build. It tests whether the expected result would be gotten by developer themselves.

Smoke Test

Smoke test also calls sanity test. It is a small scope testing work based on the daily build which the developer provides every day. The test purpose is to verify whether the defect is fixed on this build. And it also tests the basic functions on this build, ensure there is no new defect will be produced.

Regression Test

Regression test starts at when CM publishes a new software version. This version should be stable, integrated some new branches, new function from different component teams. This version build comes from many builds which PASSED in its sanity test.

CMMI Configuration Management

CMMI’s Definition of Configuration Management

“The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items”

CMMI steps for CM

SEI Capability Maturity Model Integration, Version 1.1 for Systems Engineering and Software Engineering (CMMI-SE/SW, V1.1) lists the following practices as instrumental for a CM capability in an organization :

1. Identify the configuration items, components, and related work products that will be placed under configuration management.
2. Establish and maintain a configuration management and change management system for controlling work products.
3. Create or release baselines for internal use and for delivery to the customer.
4. Track change requests for the configuration items.
5. Control changes in the content of configuration items.
6. Establish and maintain records describing configuration items.
7. Perform configuration audits to maintain the integrity of the configuration baselines.

For further reading visit: SEI Configuration Management

Object-Oriented Software Configuration Management

Object oriented software configuration management is centred around the idea that, most SCM tools are centred around a storage model and forces the user to think of their software - which they normally view as class and objects - in terms of files and folders. In the realm of object oriented SCM tools this represents a disconnect between the concept of the architecture and logical structure of the software and file based SCM elements of the software.

Object Oriented SCM tools therefore treat revisions as changes in the logical structure and relationships between classes and objects, rather than simple file level changes that are tracked by simple tagging and labelling. The Molhado Project is an example of an object oriented SCM toolkit for building object oriented SCM software.