CSE7315M32 - Lyle School of Engineering

SMU CSE 7315

Planning and Managing a Software

Project

Module 32

Software

Configuration Management

Implementation

Copyright 1995-2009, Dennis J. Frailey

CSE7315 M32 - Version 9.01

CSE7315 – Software Project Management

Objective of This Module

 To discuss issues of implementing software configuration management:

Futrell, chapter 31; Humphrey, chapters 7, 12



CSE7315- Software Project Management 2


Functions




Configuration Management Has

Five Major Functions

1) Configuration Identification

– Which parts are combined in what way to make a given release/version

2) Configuration Control

– How & when are changes made to software?

3) Change Management

4) Status accounting

– Where is each component?

5) Configuration Authentication




Function 1:

Configuration Identification

 This is the process of naming components and defining the way they combine to make the product (configuration)

 Required at every level of decomposition that can be independently used, sold, replaced or tested

 Too much identification can be hard to maintain whereas too little causes productivity problems





Includes ...

 Naming conventions for each version of the software and for each version of each configuration element

– Unique name for identification purposes

– Version or change level to distinguish different versions

 Descriptions of how the named elements are combined to form higher level elements

Elements of the configuration would include software, documents, development tools, procedures, test cases, and so on.





Also Includes ...

 Naming convention and description for each component that makes up each element

– Unique name for identification purposes

– Version

– Description - list of component parts




You Must Identify the Parts and the Structure

MAIN

COMP1 COMP2 COMP3

MOD1 MOD2 MOD3

Version Description for

Software Release 2.0

--------

MAIN 2.3

COMP1 2.2

COMP2 1.7

etc.



Software Structure

MAIN consists of the following components:

COMP1; COMP2; COMP3

COMP1 consists of:

MOD1; MOD2; MOD3

COMP2 consists of: etc., etc.


Function 2:

Configuration Control

 This task revolves around having only one official copy of code (baseline) to serve as a reference point

 Sub tasks include:

– Promotion management

– Build management

– Access control mechanism




Promotion Management

Release

Version

Beta Test

Version

Alpha Test

Version

Development

Version



You must keep track of when software is ready to “promote” to a new level, what procedures are followed as it passes through levels, etc.


Build Management

Source

Modules (C)

Source Modules

(in Java)

You must keep track of how the software is built, so you can construct it properly

Java

Compiler

Directives

(Build File)

Loader

Source Modules

(Assembly)



Assembler

Correctly Built

Version


Access Control Mechanisms

 Allow only authorized access and changes

 Allow “checkout” (for change purposes) to only one individual at a time

 Use private working copies for making modifications (until they are tested)




Function 3:

Change Management

Change proposal authorization mechanisms

– So you know why a change is being made and who has responsibility for it

– Often done by a Configuration Control Board to make sure all affected parties are informed




Typical Authorization

Mechanisms

 Change initiation procedures

 Change classification mechanisms

 Change evaluation processes

– What is the impact of this change?

 Change dispositioning

– Do we want to make this change?

 Change implementation

 Change verification

 Final change approval





(continued)

Maintain change records

– Record what was done, by whom, and how to test it

– So that you can …

...reinstate or recreate any previous state

...track all changes from the most recent baseline

...assure that subsequent changes are correct

...make sure that affected components are changed properly





(continued)

Check-in procedures

– Make sure that ...

...items checked in have been properly tested

...proper regression testing has been performed before making a changed module part of the configuration

...all affected parts are recompiled




Function 4:

Status Accounting

This function entails maintaining descriptions and status information on all versions of the software

 Description of the current baseline

– All elements - name, description, status (being changed, to be fixed, etc.)

– All changes - type, why, who, when, cause of problem, etc.





(continued)

 Description of current vs. next release or version

– What changes will be included

– Status of those changes

– Statistics such as how often changed, etc. for each component of the baseline





(continued)

 Descriptions and copies of prior versions

– Archiving if no longer in use

– Access if still in use

 Record of all change activity

– Record of all changes since baseline

– For any element, identify all changes, all users, all uses of that element

– For any change, identify all affected elements




Function 5:

Configuration Authentication

 Functional Configuration Audit

– Verifies that the software does what it is supposed to do

 Meets its requirements, passes its tests, is properly designed, etc.

 Physical Configuration Audit

– Verifies that all the parts are there and that they are the correct parts

 For example, if you compile the source, do you get the right version of the object code?





Responsibilities

Who does which of the various functions?




There are Three Generally

Acknowledged Configuration

Management Responsibilities

 Configuration Manager or Librarian

 Module Owner

 Change Control Board

These three must work together to have effective

CM. But these jobs are often performed by people in different organizations – this can lead to configuration management problems




Configuration Manager or

Librarian (for a software item or group of software items)

 The central control point for all changes

– Defines/communicates/enforces procedures

– Establishes baselines and backups

– Forbids unauthorized changes

– Records all changes

– Assures that changes are properly tested

– Resolves all exceptions




Questions The Configuration

Manager Can Answer

 What has changed since the baseline?

 What tests have been or need to be run?

 Where is the code? (specification / user’s guide / etc.)

 What constitutes the current version?

This job is often performed by a configuration management professional




Module Owner (Technical

Control Point)

(for each module or component)

 Individual with technical responsibility

– Knows and understands the design

– Knows and understands the interfaces to/from

– Technical control point for changes, fixes, enhancements

– Responsible for technical integrity

– May do periodic regression tests

– Reviews all changes




Questions The Module Owner

Can Answer

 How do I call / use this module?

 How does it work?

 Why does it work that way?

 Can I change it this way?

 Is the spec right or the code? (if they differ)

This job is often performed by a software developer.

May not view this as a CM function!




Suggestions Regarding Module

Owners

1) Have a backup for each module owner

– Generally the things they know are not well documented

– If the module owner leaves, you don’t want to be in deep trouble

2) Have an owner for each interface as well

– For the same reasons you have module owners




Suggestions Regarding Module

Owners

(continued)

3) If the software is important or will have a long maintenance period, all of the answers to all of the questions should be documented somewhere

4) Make sure the CM role of the module owner is understood by the module owner, the configuration control board, and the configuration manager!

5) There may be a technical working group of knowledgeable software developers that discusses proposed changes and makes recommendations to the change control board




Change Control Board

 Controls, evaluates and coordinates changes

– Includes representatives from all affected functions, such as development, documentation, quality assurance, maintenance, test, etc.

– Makes sure all ramifications of any proposed change are understood

– Authorizes work to make changes

– Authorizes incorporation of changes after suitable tests




Suggestions Regarding the

Change Control Board

 Make sure all key organizations are represented

 Make sure that, when an issue involving a module is discussed, that module’s owner is present or has been consulted

This job is often performed by managers. They often feel pressure to make decisions but may not understand the implications of their decisions.




Planning a SwCM Program




1) Analyze the Current

Software Process

 Understand the culture of the organization

 Identify what artifacts should be under the CM control

 If you do too much too soon, it has high cost for little benefit

 If you do too little too late, it may result in loss of control and integrity




2) Define the SwCM Process and Procedures

 Define configuration control functionality

 Establish the change management procedures

– This requires achieving balance between chaos and bureaucracy and should initially focus on frequent and expensive problems

 Establish responsibilities needed to successfully implement the control mechanism




3) Document the Plan

 Decide and resolve all issues that must be documented in an SwCM plan

 Document all SwCM functions, risks, responsibilities and automation needs in one place to serve as a reference point in the future

 Define processes and procedures for all

CM activities

 Identify any training needs before the

SwCM process can be implemented

– Standards like DoD, NASA and IEEE can be helpful




4) Evaluate Tools

 The tool should be able to match the requirements of the SwCM process

– The SwCM process drives the selection of tools, not vice versa

 The tool should be able to support all of your SwCM needs

– Can it handle the documents, test cases, and other non-code elements of your configuration?

– You may need to supplement a tool with manual procedures or other tools




Evaluate Tools

(continued)

 Does it run on your host machine and OS?

 Does it integrate with your compilers, editors, etc?

 Determine special needs of your language or design method, e.g:

– Changing a module in Ada forces you to recompile all modules that utilize the changed module

– Some design tools produce multiple files that must be kept together




Evaluate Tools

(continued)

 Can the tool scale up to your project?

– Some tools work fine on small projects but cannot handle a large one

– You may need to augment the tool to fix or enhance it for your purposes

 Beware - this can be a “tar baby”

 Work with the vendor to influence them to make needed improvements

 Work with other users to share effort

 Many tools are file oriented

– You may need a more advanced concept, such as

“change set oriented” tools




Evaluate Tools

(continued)

 What amount of training and expertise are required to use the tool properly?

– Modern CM tools can be very complex and difficult to use

– People with inadequate training and experience may use them improperly

 Inefficencies

 Errors

– Many organizations treat CM as a clerical function – this is not adequate for modern software systems




Final Steps for Planning SwCM

5) Perform a Pilot

– It is important to understand the weaknesses before applying a CM system to a large scale project

6) Rollout the SwCM system

7) Facilitate ongoing improvement




Some Practical Problems with

Implementing SwCM

Prerequisites

Cost vs. Benefit

Adequacy of Tools

Software CM vs. Other CM




Three Important Prerequisites to Implementing SwCM

 Management support

 A repeatable process

 Awareness of risks




Management Support

 CM can be an expensive function and adds time & overhead to a project

 It inhibits quick fixes near a deadline

 Promotes team productivity over individual productivity

Management support is essential to acquire resources and to enforce the CM policies in the development process against many forms of resistance




Repeatable Process

 The SwCM process must be integrated into the development process to improve the team productivity & product quality

Without an existing repeatable process, the risk of inappropriate CM process is very high. This may cause more problems rather than solving the problems of the existing process




All Risks Identified

 All SwCM related risks should be identified and mitigated before enforcing the SwCM process

 Typically, fewer than 25% of risks in implementing SwCM are technical

– The rest are political, management and cultural risks

– For example, determining who controls change or makes decisions




Cost vs. Benefit of CM

 Configuration management can be an expensive function

 CM adds time and overhead to a project

 If you do too much too soon, it has high cost for little benefit

 If you do too little too late, it may result in loss of control and integrity

 It is a management function but is typically performed by software development people who may not understand much about management




Avoiding Excessive Overhead

Configuration management is notorious for adding overhead costs and time to a project. But these can be managed and controlled.




Techniques for Controlling CM

Overhead

 Carefully integrate the CM function with the rest of the software development process

– Make the necessary CM steps a natural part of the process

 Be careful to choose the right amount of

CM for the particular product

 Be careful to choose tools and procedures that are efficient and effective




Another Way to Control

Overhead: Multiple Levels of CM

 Have different levels of formality for different situations

 Formality may change as development progresses, for example as individual development is replaced by group activities

 Formality may vary as a function of the size of the development team or the complexity of the product




Multiple Levels of CM

Individual Control

If it affects only 1 person, that individual is responsible for all configuration management



Engineering Control

If it affects only one team

(same location, same group of related modules), that team does configuration management

(with all responsibilities accepted by team members)


Multiple Levels of CM

(continued)

Formal Control

If it affects more than one team, or people outside of the local team, it becomes appropriate to use a more formal CM function, often carried out by a separate organization.

...

CM Staff

Developers

CSE7315- Software Project Management Copyright 1995-2009, Dennis J. Frailey


50

CM Tools

 Some CM tools are inadequate, slow and expensive, and/or cumbersome to use

– They may not scale up well for large projects

– In the past, such tools have typically been developed by people with a limited frame of reference

 They may not be good at both document CM and design model and code CM, especially for different languages

 Most modern tools are difficult to learn and to use properly




CM Tools

 They may not integrate well with the rest of the software development tools and especially not with other tools used on a large program, such as system engineering or hardware design tools

 Upgrades to new versions of a tool may be difficult because of lack of full compatibility

 Translations between different tools may be impossible!

– Different underlying models




Recommendations on CM

Tools

 Plan well ahead of time

– Define levels of CM needed, procedures to be used, etc.

– Use some form of CM from the very beginning

 for requirements documents, SOW, etc.




Recommendations on CM

Tools

(continued)

 Get the best tools you can

– Evaluate thoroughly

-- can it scale up?

-- does it run on your host machine and OS?

-- does it integrate with your compilers, editors, etc?

-- does it support all of your CM needs?

– You may need to use multiple tools or do some steps by hand




Recommendations

(continued)

 Determine special needs of your language or design method

– For example, if you change a module in Ada, you must recompile all modules that utilize the changed module

– Some design tools produce multiple files that must be kept together

 You may need to augment the tool to fix or enhance it for your purposes

– Beware - this can be a “tar baby”

– Work with the vendor to influence them to make needed improvements

– Work with other users of the tool to share effort




Software CM vs. Other CM

 In concept, software CM is no different from hardware CM

 But in practice, software CM is needed more intensely, sooner

– Intangibility of software

– Software change cycle is relatively short

– Software complexity is relatively high

– Proliferation of artifacts during software development

– Difficulty of telling “what goes with what” in software




Final Remarks

 You must plan CM from the start

 You must manage the configuration

 You must automate CM or it will become too much of a burden

 CM tools and methods are not always up to the task

– Often tend to bog down with large software projects

– Typically do not handle code, documents, design models, and other artifacts equally well

– Typically file oriented rather than “change set” oriented




Summary of Module

 Software Configuration Management has five key functions and three key roles

 The roles are often carried out by individuals from different organizations who must understand the need to work with each other and that they are all part of the CM process

 There are many practical issues associated with planning and implementing CM




References

 Ben-Menachem, Mordechai, Software CM

Guidebook , McGraw Hill Book Co., 1994,

ISBN 0-07-709013-6, LC# 94-001102

 Compton, Stephen B. & Guy Conner, CM for

Software , Van Nostrand Reinhold, 1994,

ISBN 0442017464

 Dart, Susan A., "Achieving the Best Possible

Configuration Management Solution,"

CrossTalk , Vol 9 #9 (September, 1996).

 Esterbrook, Steve, The Configuration

Management (CM) Resource Guide , 1999, http://www.quality.org/config/cmguide.html




References

(continued)

 Marshall, A. J., "Demystifying Software

Configuration Management." CrossKeys ,

Vol 8 #5, (May, 1995).

 NASA, Software Configuration

Management Guidebook , 1995, http://satc.gsfc.nasa.gov/GuideBooks/cmpub.ht

m

 Parnas, David Lorge. "Software Aging."

Proceedings of the 16th International

Conference on Software Engineering ,

1994, pp. 279-287.




END OF

MODULE 32




CSE7315M32 - Lyle School of Engineering

END OF

MODULE 32

Related documents

Products

Support

CSE7315M32 - Lyle School of Engineering

END OF

MODULE 32

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib