Configuration Management Introduction

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 87

Change: The cause, result, object to be managed of CM

Topics to be discussed:

Short History What is CM Objectives of CM Audience of CM Usage Configuration Management Processes and Activities

Short History

Configuration, to form or after, derives from the Latin com-, meaning with or together, and figurare, to form

It also means a relative arrangement of parts or elements.


Configuration management, as we know today, started in the late 1960s. In the 1970s, the American government developed a number of military standards, which included configuration management

Later, especially in the 1990s, many other standards and publications discussing configuration management have emerged

In the last few years, the growing understanding of process/ product development as a collection of interrelated activities has influenced work on configuration management
This means that CM is now also considered from a process point of view.

Introduction

To cope with the drastically changing business environment, enterprises are becoming strongly focused on ways to:

achieve speed-oriented management management efficiency, and costs

Improve Reduce

In achieving these goals, enterprises should undergo if not many, some drastic changes

These changes would not only apply to the core business/ operations of the organization. Even back support departments like HR, Sales and Marketing, etc were obligated to undergo changes internally, and even as part of the totality of changes in an organization
Being

subjected to Configuration Management

What is CM?

There are many definitions of configuration management and many opinions on what it really is

Configuration management is unique identification, controlled storage, change control, and status reporting of selected intermediate word product components, and product during the life of a system

CM processes/ activities

The view of configuration management that we will use in this course is process oriented

Therefore, the definition includes activity areas, which can be describes in terms of process descriptions
These processes are Identification, Assessment/ Approval, Implementation, Test/ Release, Status Accounting Reporting (Auditing)

CM Five Processes

Identify Asses/ approve Implement Test/ Release Account/ Audit


Identification Assessment & Approval Implementation Test & Release Status Accounting

Audit

CM is cyclic or is it?

In everyday language, configuration item is often used to refer to an item, which is then to be produced several versions.

This is not strictly correct. In fact, each new version of a configuration item is a new configuration item in its own right
CM activities may be viewed as cyclic for each item class placed under configuration management. This means that the configuration item continuously goes through the mill (or the process)

The first cycle is initiated by a (planned) need for configuration item, and later the driving force is a change request

In each cycle, a configuration item will be identified, produced, stored, and released for usage.

Objectives of CM

CM is a set of related processes that will achieve the following objectives:

Maintain a detailed record of each products configuration. This means tracking down to the patch and revision level of individual component and sub-components of the product Control the changes implemented. This includes a formal process for change requests, assessment, approval, implementation, test and release

Ensure an audit trail. This includes change requests, approvals, test results, installation/ deployment dates, and post installation quality assurance tests to support the systems operational baseline configuration documentation Facilitate life cycle management and operational consistency. This is verified by auditing installed systems against baseline configuration documentation

Audience of CM

The audience of CM includes ___________________ These customers fall in to four categories, each using CM for differing purposes.
Role
User

How it applies
Request a change or recommend an improvement to the new process

Changer
Information Technology personnel

Provide change to the process


Recommend a change or to propose an improvement in the IT related concerns Manage the process (the old, and the new)

Configuration Control Manager

Usage

The configuration management consists of series of processes that flow clockwise

Five of the six processes are sequential, starting with requirements or improvements identification and ending with status reporting
The sixth process, auditing, is an on going process to verify that the system configuration documentation accurately reflects the systems actual configuration

Processes
Identification

Activity
User initiates a change request. Someone else will validate a change request, notifies the initiator, and passes the request on to the Configuration Control Manager The CCM assigns priorities, initiates a review, complies the findings, and forwards the findings to one of three parties Depending on the requester, CCB, subject matter experts, or peer review approves or denies the requests directed to them

Assessment and Approval

Implementation

If the change request is approved, the project is implemented. If the Change request is denied, it is closed out and the initiators are notified
Provides criteria for testing the system after a change has been implemented and releasing the system back into operation This process documents the change that been implemented This process audits the configuration documentation against the actual system configuration

Test and Release

Status Accounting Audits

A Closer Look at Configuration Management

Fundamentals of Configuration Management


1.1 The need for configuration management 1.2 Basic concepts of configuration management

1.3 Configuration management in standards/ regulations


1.4 Configuration management related to Process improvement
1.4.1 1.4.2

CM process Model CM planning levels

CM activities in detail (Configuration Identification)

The need for CM

It is the objective of CM to administer and supply information about the product. It is often said that people once having worked with proper implemented configuration management without realizing it will realize the strengths of CM when working in environments where it is not implemented

CM should provide visibility of the products configuration through recording specific data in order to establish and maintain integrity of the product described by the configuration throughout its complete life cycle.

CM in detail

CM is the discipline of organizing, controlling, and managing the evolution of defined products from a descriptive point of view It supports all phases from the requirements phase till the end of the product lifecycle It identifies the products and components and keeps tracks of how they are organized and where they are stored Manages and controls changes of any kind and for any reason to these configuration items such that the integrity of the product can be maintained

Collects and disseminates information about configuration and its items based on recorded data

CM is based on the principle of immutability

which implies the existence of versions, and provides mechanisms and techniques for the co-ordination of a team of people working together

Costs and Benefits

Proper performance of configuration management activities costs resources and time


Costs The moment when the configuration items are placed under configuration management Benefits Saves time and money

The level of formality applied throughout the life cycle

Can be transferred into saved budget by calculating how much solving problems like defects (operational/ details/ specs), delays, etc would have costs
* Indirect savings obtained from more effective, efficient and reliable phases and as a result a higher quality of the product is achieved.

The total number of configuration items defined

CM in standards/ regulations

Two of the standards known to professionals:


ISO CM

10007 (Guidelines for Configuration Management)

aspects of ISO 20000 (Service Management)

The rest of the standards are all software related i.e. CMMI, ISO/IEC 9001:2000, ISO/IEC 12207:1995, etc., etc., etc.

Configuration Management related to Process Improvement

CM has two different relations to Process Improvement

CM is a support process for process improvement, that is for products being produced and maintained by those responsible for process improvement

Process improvement staff should perform configuration management on the products they are responsible for

CM can also be the subject for process improvement

Setup and constantly improving a configuration management should be the responsibility of process improvement

Improving CM

Improving CM is setting up a plan to improve the discipline of CM within the organization to reach a higher maturity level This improvement plan should reflect the aimed maturity or ambition and comply with the internally defined policy. Includes:

Implementation of automated tools

Defining overall standards and guidelines


Including a common terminology Education and training of CM personnel

Different Roles in Improving CM

Improving the CM processes in an organization is an organizational change project


Change manager Change agents Champions Target group

Activities in Improving CM

Determining current state Defining goal Planning and monitoring implementation Pilot project Roll out Determining success

CM Process Model

CM is a process consisting of the Five CM activities.

CM is an even-driven process

Starts when an item needs to be controlled (at least for the planning and identification)

Ready to be placed under configuration management


Released for usage or a next phase Events are identified which leads to changes

Information is needed
Audit needs to be executed

Skills/ People

Processes

Technology/ Tools

The Challenge is to find the right Balance

Although CM process is based on the same basic principles, the process itself can be implemented differently per organization or even per product type Responsible unit should describe in detail how the process is/ will be implemented

CM planning levels

Organization level (CM strategy) Product level needed when no project is defined like at the end of the life cycle or cross project level or maintenance Project level when developing a release of a product

CM Activities: IDENTIFICATION

Learning Objectives for CM activities: Identification


Understand and explain the criteria for defining Configuration items Recall the products that can be placed under configuration management Describe the attributes to be defined for configuration items

Describe and explain the concept of configuration controlled documentation

Configuration Identification
SELECTION AND NAMING

Configuration Items Candidates

Purposes:
Determine

which products should be taken under configuration management unique configuration items the characteristics (attributes/ metadata) for configuration items

Determine

Specify

relations to other configuration items and to the outside world

Configuration item candidates

In principle everything may be placed under configuration management Configuration item a product placed under CM - is assembled in configurations

Configurations may vary in complexity - may be an individual item or a hierarchical collection of other configurations/ CI

Configuration item cont

The individual CI in a configuration may be of all types in any required mixture Note that CIs can be any possible part of a product defined as a configuration (in tagalog parte ng kabuuan) that it is necessary to have identified, produced, stored, used, and changed individually

Cont Risks in Selection of CIs

Selecting too many CIs could result in too much work (and/ or less productivity) Cost and Benefits

Too much work lead to the misconception that CM is a bureaucratic process Less productivity (remember one of the costs of CM)

Cont Risks

Selecting too few CIs does not give the control you are aiming for Configuration Identification is one of the main cornerstones during the manufacturing process of the products

Impossible to control something you do not know

Types of CIs

Software Hardware

Network data
Documents Services

Physical CIs and Electronic CIs

Cont Types of CIs

For each of the types, it has to be decided whether and how they may be placed under CM In view of CM the differences between the types need to be understood with respect to the attributes and storage of a CI

Configuration Identification: Baselines in CM

What do you mean by Baseline/s???

A baseline is an agreed-to-configuration, formally established at a specific point in time It serves as a reference for further activities and a basis for managing changes CIs identified in this first activity may be treated as the baseline that could serve as the comparison point after the release of a specific item is done

Examples of CIs

Software related components which when controlled within software development is SCM Hardware in CI context is the hardware to be delivered as part of the product Information sources containing information related to the product (requirements, specs, user manuals, etc)

Cont Examples of CIs

The services to be delivered for a product are intangible, and cannot be identified as CIs. However the tangible components sustaining them, can be placed under CM (procedure description, training material, and user manuals)

Cont Examples of CIs

Companies often have cross-organizational products or assets for which CM should be considered (administrative docs, company product assets, infrastructure, etc)

Unique Identification of CIs

An organization must define the conventions for unique identification of configuration and its items One general convention not enough Typically several conventions are necessary for various types of CIs (like both hardware and software, documents and codes, supplier and distributor, etc)

Cont

Unique identification may include affiliation, name, version, states, date (referring to the status), and storage place The unique identification must connect the registration and the actual product (physical or electronic) in such a way that it is always possible to find the CI Examples: electronic products (file names), specs (version, supplier, price, etc)

CI attribute: relationships

Unique identification is also a necessity for registration of relations between CIs The relations between CIs are part of the attributes to record

Types of Relations

Build (model) Dependency (to who/ what department, supplier, etc)

Breakdown (Specs)
Impact-relations (improvement, Price/ cost,

Records of relations supply valuable information when products are analysed or need to rebuild (e.g. for correcting issues, implementing new functionality)

Traces these are registrations of relations between CIs

Two types of Traces:

Forward traces references to all design object and test procedures from individual requirements Backward traces references from individual design objects and test procedures to the requirements implemented and tested

Trace information is important for understanding the product, and avoiding omissions

Impact analysis

Relations between CIs can be one-to-one, one-to-many or many-to-many

CI attribute: Authorization and Distribution

May be derived CM, project or a quality plan

To implement proper configuration control have general directions for authorization specified in a plan

Examples: responsibilities for:


Production Delivery Acceptance

for different types of CIs

Authorities in CIs

Author him/herself for CIs (drafts of documents) A group consisting the project manager, the person responsible for QA, and representative of the customer (for documents to be used by everybody)

Other CI attributes

How (process) With what (tools) Has been produced

Where (environment)
Ownership

Multiple ownership exist


For CM, the responsible person (rather than group or department) related to changes should be known

Cont Other attributes of CIs

Other technical attributes:


Requirements Designs Test

reports

Quiz: Identification of CIs


By partner ONLY Identification of Configuration items in a certain product/ service Different item per partner Situation: Improving your chosen product, what CIs are you going to select for identification stage

1. 2. 3. 4. 5. 6.

Situation: Improving your chosen product What CIs are you going to select for identification stage Determine each item as software, hardware, documents, or services Describe the baseline/s for each CI Identify the forward trace/s or/and backward trace/s for each CI (if both are applicable) Who has/have authorization for each CI? Explain Describe the how, with what, where each CI has been produced

Choose 1 product among the ff:


Registration Form Transcript of Records A Medical Bill Pay slip Clearance Form

CONFIGURATION ITEM: STORAGE AND RELEASE

In most configuration management related standards, storage and release is not defined as a separate set of activities A sub-activity of Configuration Identification

Storage plays an essential role in establishing and maintaining integrity of products


Release is essential for making configuration items available for usage

Objectives of Storage and Release

Ensure that any CI is stored in such a way that it will not disappear, that it can be found anytime It can be delivered in the expected condition

Storage Areas

Stored items are physically present at a specific location, a storage area The term area is used for storage of both physical and electronic items

For electronic items, it can be: directory structure on a workstation, a loose-leaf book, a shelf, a desk, etc.

3 Types of Storage Areas


Configuration Controlled Area Manufacturing Area

Usage Area

Manufacturing Area

Is the location where drafts and un-finished products are kept while they are being produced or developed May also be referred to as development library, workspace area, or sandbox

A complete manufacturing area will often consist of a considerable number of independent areas

Usage Area

Is the location where the products are being deployed to and used

Usage any deployment of the product as it is without changing it in any way


Some Types of Usage: a. Review of a specification b. basis for development of a design (for example) c. test specification d. testing of a component e. actual deployment of a finished product

The responsibility of for the usage area varies depending on the usage context. For example: - Review of a project; reviewers desk - Execution of a product in production; production machine or on users workstation

Configuration Controlled Area

This is where CIs are stored by transfer from the manufacturing area
Manufacturing Area

Configuration Controlled Area

Usage Area

Configuration items are released from the configuration controlled area to the usage area.

Storage in Configuration Controlled Area


This area contains the CIs themselves May be referred to as the CM area or the controlled library CIs are transferred from manufacturing area to configuration controlled area when they are ready to be placed under CM Check-in

Release from the Configuration Controlled Area

CIs kept in the configuration controlled area are given out to stakeholders via the usage or manufacturing areas Release from storage

Two types of Release from Storage

Release can take place to the usage area, when a configuration item is going to be used as it is It can also take place to a manufacturing area if a CI is going to be used as the basis for manufacturing another

Release Cont

A release may be accompanied by a release note stating the contents of and reason for it Information about distribution of releases, such as who has got what and why, may be registered as part of the attributes for a configuration item

CONFIGURATION CHANGE CONTROL

Two aspects of handling changes to CI

The control of the impact of change on the CIs - Configuration Change Control

The actual implementation and verification of changes - is called change management and is not part of CM

Configuration Change Control

Implies the need to control every change to all the CIs

For each new version of a CI it should identify the changes that have been implemented relative to the predecessor
All changes should be traceable from the change request to the configuration item(s) where the change has been implemented and vice versa

Causes for Changes

When a product is being developed, deployed, and maintained, wishes for change/s are inevitable Employees make mistakes, business requirements change over time, and the environment in which a product is deployed can evolve as well

People constantly develop their knowledge about their products and business processes consequently get new ideas for the evolution of the product Some even say a solution to a task will create new problems: We learn while doing

Events

The initiation of configuration change control is the occurrence of an event. Event could be anything varying from a simple incident during deployment or validation tests to a new business need for adapting the product for commercial or regulation reasons

Some aliases of an Event - anomalies

- bugs
- problems - deviations - failures - enhancements - waivers - incidents

The first five are related to the recognition of events where the product does not conform to expectations Enhancements are events where new ideas for improvement of the product is recognized

Waivers are events where the customer agrees to leave requirements unfulfilled

An event must be registered if it pertains to one or more CIs and if it is not evident that no change can possibly be caused by the event The event registration must be done meticulously so that the origin of the event can be understood and followed by stakeholders, recreated, investigated, and decided upon by the appropriate CCB, and monitored to confirmation of solution implementation

The information should also be useable in data analysis to find trends and suggestion for process improvement

Event registration requirements


Information about the originator of the event A comprehensive description

When and how the event was identified


Asserted impact Possible solution Suggested responsible for solution Appropriate signatures

Events can be raised by all stakeholders within the organization or at customers Depending on the event there may be an impact onto individual projects, entire development lines throughout the whole enterprise An event may lead to a formal change request of the defined configuration item. The decision about the fate if an event is made by the relevant CCB

Assignment: Individual

Think of just 1 possible important event to be changed in your ID Identify its type or alias, and provide the requirements, except the appropriate signatures

Follow the same format


Essay form. Always explain clearly

You might also like