Original Article Reference

by Harsha Chakravarti

In today’s world, there are many software applications and hardware components created, to meet multiple needs of multiple organizations.  These components include the Windows NT and network configurations, Unix related systems and configurations and mainframe related applications and configurations.  In order to meet the needs of any given configuration of applications, hardware and/or documentation related to these, a defined Configuration Management process plays a role in an organization.

Overview

Configuration Management (CM) principles underlie business practices used throughout industry and government to provide:

• The orderly establishment, documentation and maintenance of a product’s functional, performance and physical attributes,
• Management of changes, and
• Access to accurate information about the product’s development, use and maintenance.

CM practices should be employed because they make good business sense, rather than requirements being imposed by an external entity.  All of the CM principles are applicable in which a robust CM approach is necessary, however some of the principles may not apply.  CM practices should be applied selectively, commensurate with the application environment.

Processes within Project Management interact through or with Configuration Management.  A major purpose of CM is to establish and provide a standardized effective and efficient process to centrally manage change for integral components within a project. 

The goal of the CM process is to facilitate orderly management of product information about the assets and the changes to the assets that need to be controlled.   Assets include configuration items such as runs or job-streams, code (programs and executables), test plans (STP), Configuration Management Plans (CMP), software requirements (SRS/SRD, technical specifications), design documents (SDD), Hardware parts descriptions, etc.  CM is designed to ensure that organizations have the information they need to make sure their products perform as intended.  The beneficial purposes of a Configuration Management Process, when implemented, include improvement of capability, performance, reliability and correction of defects.

Scope of the Process

Configuration Management processes span the life cycle (especially the development life-cycle) of a product.  It typically starts with the requirements phases and cycles through the design, development and installation phases.  The scope of the process provides a means for:

1. The establishment, documentation and maintenance of a product’s performance, functional and physical attributes, and
2. Management of changes to these attributes.

Configuration Management (CM) principles address the composition of a project, documentation defining the project, and other data that supports the project.   CM is a baseline and requirement management process that provides managed control to all phases of a project life cycle. CM is a management discipline that applies technical and administrative direction to the development, production, and support life cycle of a project.  In achieving this, CM is a management process for establishing and maintaining consistency of a project's performance, functional, and physical attributes with its requirements, design, and operational information throughout its life.

Benefit(s) of Configuration Management.

At every stage of the project, appropriate controls can be defined to ensure correct understanding of the project.  For example, at the end of the requirements phase, controls can be implemented to ensure that the stakeholders (such as development staff and the customers) have a good understanding of the requirements.  These can be reviews of functional requirements before a formal programming or code change.  Any changes to requirements required as a result of the controls can be implemented at this point, thereby ensuring that the IS/IT staff know these requirements well enough to proceed to the design and coding phases.

Benefits derived from the utilization of the Configuration Management process include:

• Providing the ability to control scope.
• Allowing changes to baseline work products to be proposed and evaluated, with considerations to impact of changes, in a controlled and timely manner.
• Managing change activity through a defined process such as:

o        Providing the ability to document and track change proposals and their impact(s), providing a historic trail of the development of work products.

o        Providing the ability for all stakeholder groups to have the opportunity to approve/deny change proposals with a high level of understanding the change impact(s).

• Providing the ability for improvements to be considered and implemented back in to the requirements gathering process.

Consequences of not utilizing this process could include:

• Failing to meet customer expectations
• Overrun budgets and/or hours
• Delayed schedules
• Past due milestones/deadlines
• Difficulty in testing missing and/or incorrect requirements
• Loss of customer priority for requirements
• Unmanageable change requests

Processes within Configuration Management.

The CM process addresses the composition of a product, configuration documentation defining a product, and other data and products that support it. CM is structured into integrated processes that provide for complete product life cycle management. The CM process may be related to a single product or to a collection of products (such as application systems or subsystems).  CM is usually described in terms of the following processes:

• CM Planning and Management – planning the CM process for the context and environment in which they are to be performed.
• Configuration Identification – i.e. Definition of the product/Project and its configuration items.
• Configuration Change Management – i.e. Control of changes to the product/project and its documentation
• Configuration Status Accounting – i.e. Provide the status of product/project and its documentation
• Configuration Verification and Audit – i.e. verify the consistency of the documentation against the product (such as a Quality Peer Review process).

Deliverables/Documentation

The following products can be considered as Configuration Management (CM) deliverables, including but not limited to:

1. Project Document Deliverables – Software Requirements Specifications/Documents (SRS, SRD, RTM, SAS) and related e-mail.
2. Code (if software is changed or updated) – example: runs, programs, executables, Client/Server code such as Powerbuilder or FoxPro, dlls and related material.
3. Test Plans (example Systems Test Plans or STP), test cases, test scenarios and test results
4. Post Project Review Walkthrough documents.
5. Configuration Management Plans (CMP)

Change Control

For most projects, two (2) levels of change control can come into play:

• Level 1 changes:  The control here is applicable to any proposed change to a project/product that does not impact internal interfaces within the division, external interfaces outside the division and other applications.
• Level 2 Changes:  Controls here are applicable to changes that impact internal interfaces, external interfaces, other applications, schedule, budget or deliverables.

Configuration and Change Management

Configuration Change Management is a process for managing product configuration changes and variances.  

Benefits of change management process include:

• -     Enabling change decisions to be based on knowledge of complete change impact,
• -     Limit changes to those that are necessary or offer significant benefit
• -     Ensuring customer interests are considered
• -     Documenting and limiting variances.

The process includes identifying need for change, documenting change impact, evaluating and coordinating the change incorporating the approved change and verifying consistency of the product definition.  

Changes are initiated for a variety of reasons including:

• -     Provision of new capabilities
• -     Enhancing product support
• -     Effecting product improvements
• -     Correcting defects or deficiencies
• -    Preventing schedule slippage.

Configuration Management Process Approach

The first step is to establish baselines of the application software and/or the production configuration.  

This involves:

• Identification of the system’s functional characteristics (such as policies, practices, standards) and products (such as software/hardware)
• Identification of the system’s configuration at discrete points in time for the purposes of systematically controlling changes to the configuration.
• Ensuring an orderly transition from one milestone to the next, during development, testing and implementation.

The second step is to identify Configuration Items.  This means:

• Dividing baseline requirements into individual Configuration Items (CI)
• Developing a process to track Configuration Items throughout their lifecycles, and
• Uniquely identifying the Configuration Items.

Configuration Control Structure

The first step is to Establish Procedures for configuration control.  The process involved includes:

• Translating established baselines into policies and procedures to identify, evaluate, approve or disapprove, and implement proposed changes.
• Building a change control process to ensure that all changes have proper staffing, approvals and documentation, and
• Establishing documentation and reporting requirements for change requests and their approvals.

The next step is to establish Approval Criteria for approval, disapproval or deferring changes.  This means that the chain of co-ordination/approvals necessary to make a requested change needs to be determined.

The third step is to establish an Accounting/Audit trail.  The accounting process include:

• Establishing controls for reviewing and auditing a change to determine its effect on the system’s features.
• Initiating a process to review and test, to ensure that the changes have been performed correctly.
• Initiating a process to ascertain that only the “authorized” changes have been made to the system, and
• Ensuring that the process actually works the way it was designed.