configuration management - hwyjc32/project/ref-software...objectives to explain the importance of...

Configuration management

Adapted from Ian Sommerville 2006, Software Engineering, 8th edition. Chapter 29 1

ObjectivesObjectives

To explain the importance of software To explain the importance of softwareconfiguration management (CM)

To describe key CM activities namely CM To describe key CM activities namely CMplanning, change management, versionmanagement and system buildingg y g

To discuss the use of CASE tools to supportconfiguration management processes


Topics coveredTopics covered

Configuration management planning Configuration management planning Change management

Version and release management Version and release management System building

CASE t l f fi ti t CASE tools for configuration management



New versions of software systems are created as


New versions of software systems are created asthey change:• For different machines/OS;• Offering different functionality;• Tailored for particular user requirements.

Configuration management is concerned with Configuration management is concerned withmanaging evolving software systems:• System change is a team activity;y g y;• CM aims to control the costs and effort involved in

making changes to a system.


Configuration managementConfiguration management

Involves the development and application of Involves the development and application ofprocedures and standards to manage anevolving software product.g p

CM may be seen as part of a more generalquality management process.q y g p

When released to CM, software systems aresometimes called baselines as they are a startingpoint for further development.


System familiesSystem families


CM standardsCM standards

CM should always be based on a set of standards which CM should always be based on a set of standards whichare applied within an organisation.

Standards should define how items are identified, howchanges are controlled and how new versions aremanaged.

Standards may be based on external CM standards (e g Standards may be based on external CM standards (e.g.IEEE standard for CM).

Some existing standards are based on a waterfallprocess model - new CM standards are needed forevolutionary development.


Concurrent development and testingp g

A time (say 2pm) for delivery of system A time (say 2pm) for delivery of systemcomponents is agreed.

A new version of a system is built from theseycomponents by compiling and linking them.

This new version is delivered for testing usingd fi d t tpre-defined tests.

Faults that are discovered during testing aredocumented and returned to the systemdocumented and returned to the systemdevelopers.


Frequent system buildingq y g

It is easier to find problems that stem from It is easier to find problems that stem fromcomponent interactions early in the process.

This encourages thorough unit testing - This encourages thorough unit testingdevelopers are under pressure not to ‘break thebuild’.

A stringent change management process isrequired to keep track of problems that havebeen discovered and repaired.


Configuration management planning All products of the software process may have to

Configuration management planning All products of the software process may have to

be managed:• Specifications;• Designs;• Programs;• Test data;• Test data;• User manuals.

Thousands of separate documents may bep ygenerated for a large, complex software system.


The CM plan

Defines the types of documents to be managed

The CM plan

Defines the types of documents to be managedand a document naming scheme.

Defines who takes responsibility for the CM Defines who takes responsibility for the CMprocedures and creation of baselines.

Defines policies for change control and version Defines policies for change control and versionmanagement.

Defines the CM records which must bemaintained.


The CM planThe CM plan

Describes the tools which should be used to Describes the tools which should be used toassist the CM process and any limitations ontheir use.

Defines the process of tool use. Defines the CM database used to record Defines the CM database used to record

configuration information. May include information such as the CM ofy

external software, process auditing, etc.


Configuration item identification

Large projects typically produce thousands of documents

Configuration item identification

Large projects typically produce thousands of documentswhich must be uniquely identified.

Some of these documents must be maintained for thelifetime of the software.

Document naming scheme should be definedso that related documents have related namesso that related documents have related names.

A hierarchical scheme with multi-level names isprobably the most flexible approach.• PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE


Configuration hierarchyConfiguration hierarchy


The configuration database

All CM information should be maintained in a

The configuration database

All CM information should be maintained in aconfiguration database.

This should allow queries about configurations to beanswered:• Who has a particular system version?• What platform is required for a particular version?What platform is required for a particular version?• What versions are affected by a change to component X?• How many reported faults in version T?

Th CM d t b h ld f bl b li k d t th The CM database should preferably be linked to thesoftware being managed.


CM database implementationCM database implementation

May be part of an integrated environment to May be part of an integrated environment tosupport software development.• The CM database and the managed documents are

ll i i d hall maintained on the same system CASE tools may be integrated with this so that

there is a close relationship between the CASEthere is a close relationship between the CASEtools and the CM tools.

More commonly, the CM database is maintainedy,separately as this is cheaper and more flexible.


Change management

Software systems are subject to continual

Change management

Software systems are subject to continualchange requests:• From users;From users;• From developers;• From market forces.

Change management is concerned with keepingtrack of these changes and ensuring that theyare implemented in the most cost-effective way.


The change management process

Request change by completing a change request form

The change management process

Request change by completing a change request form Analyze change request if change is valid then Assess how change might be implemented

Assess change cost Assess change cost Submit request to change control board if change is accepted then repeat

make changes to software make changes to software submit changed software for quality approval until software quality is adequate create new system version else else reject change request else reject change request


Change request form

The definition of a change request form is part of the

Change request form

The definition of a change request form is part of theCM planning process.

This form records the change proposed, requestor ofchange, the reason why change was suggested and theurgency of change(from requestor of thechange).change).

It also records change evaluation, impact analysis,change cost and recommendations (System

i t t ff)maintenance staff).


Change request formChange request form


Change tracking tools

A major problem in change management is

Change tracking tools

A major problem in change management istracking change status.

Change tracking tools keep track the status of Change tracking tools keep track the status ofeach change request and automatically ensurethat change requests are sent to the right peopleg q g p pat the right time.

Integrated with E-mail systems allowingelectronic change request distribution.


Change control board

Changes should be reviewed by an external group who

Change control board

Changes should be reviewed by an external group whodecide whether or not they are cost-effective from astrategic and organizational viewpoint rather than at h i l i i ttechnical viewpoint.

Should be independent of project responsiblefor system. The group is sometimes called a changefor system. The group is sometimes called a changecontrol board.

The CCB may include representatives from client andt t t ffcontractor staff.


Derivation history

This is a record of changes applied to a

Derivation history

This is a record of changes applied to adocument or code component.

It should record in outline the change made the It should record, in outline, the change made, therationale for the change, who made the changeand when it was implemented.p

It may be included as a comment in code. If astandard prologue style is used for the derivationhistory, tools can process this automatically.


Component header informationComponent header information

// BAN KSEC project (IST 6087)//// BAN KSEC-TOOLS/AUTH/RBAC/USER_ROLE////// O bject : currentRole// A uthor: N. Perwaiz// Creation date: 10th November 2002////// © L ancaster University 2002//// Modifica tion history// V ersion Modifier Date Change Reason// V ersion Modifier Date Change Reason// 1 .0 J. Jones 1/12/2002 Add heade r Submitted to CM// 1 .1 N. Perwaiz 9/4/2003 New field Change req. R07/02


Version and release management

Invent an identification scheme for system

Version and release management

Invent an identification scheme for systemversions.

Plan when a new system version is to be Plan when a new system version is to beproduced.

Ensure that version management procedures Ensure that version management proceduresand tools are properly applied.

Plan and distribute new system releases.y


Versions/variants/releases

Version An instance of a system which is

Versions/variants/releases

Version An instance of a system which isfunctionally distinct in some way from othersystem instances.y

Variant An instance of a system which isfunctionally identical but non-functionallyy ydistinct from other instances of a system.

Release An instance of a system which isdistributed to users outside of the developmentteam.


Version identification

Procedures for version identification should Procedures for version identification shoulddefine an unambiguous way of identifyingcomponent versions.p

There are three basic techniques for componentidentification• Version numbering;• Attribute-based identification;• Change-oriented identification.


Version numbering

Simple naming scheme uses a linear derivation

Version numbering

Simple naming scheme uses a linear derivation• V1, V1.1, V1.2, V2.1, V2.2 etc.

The actual derivation structure is a tree or a The actual derivation structure is a tree or anetwork rather than a sequence.

Names are not meaningful Names are not meaningful. A hierarchical naming scheme leads to fewer

errors in version identification.e o s e s o de t cat o


Version derivation structureVersion derivation structure


Attribute-based identification

Attributes can be associated with a version with

Attribute based identification

Attributes can be associated with a version withthe combination of attributes identifying thatversion• Examples of attributes are Date CreatorExamples of attributes are Date, Creator,

Programming Language, Customer, Status etc. This is more flexible than an explicit naming scheme

for version retrieval; However it can cause problems withfor version retrieval; However, it can cause problems withuniqueness - the set of attributes have to be chosen sothat all versions can be uniquely identified.In practice a version also needs an associated name for In practice, a version also needs an associated name foreasy reference.


Attribute-based queriesq

An important advantage of attribute based An important advantage of attribute-basedidentification is that it can support queries so thatyou can find ‘the most recent version in Java’yetc.

The query selects a version depending onq y p gattribute values• AC3D (language =Java, platform = XP, date = Jan

2003)2003).


Change-oriented identificationg

Integrates versions and the changes made to create Integrates versions and the changes made to createthese versions.

Used for systems rather than components. Each proposed change has a change set that describes

changes made to implement that change.Change sets are applied in sequence so that in principle Change sets are applied in sequence so that, in principle,a version of the system that incorporates an arbitrary setof changes may be created.


Release management

Releases must incorporate changes forced on

Release management

Releases must incorporate changes forced onthe system by errors discovered by users and byhardware changes.g

They must also incorporate new systemfunctionality.y

Release planning is concerned with when toissue a system version as a release.


System releasesSystem releases

Not just a set of executable programs. Not just a set of executable programs. May also include:

• Configuration files defining how the release is configured for aparticular installation;particular installation;

• Data files needed for system operation;• An installation program or shell script to install the system on

target hardware;target hardware;• Electronic and paper documentation;• Packaging and associated publicity.

Systems are now normally released on optical disks (CD Systems are now normally released on optical disks (CDor DVD) or as downloadable installation files from theweb.


Release problems

Customer may not want a new release of the

Release problems

Customer may not want a new release of thesystem• They may be happy with their current system as the

i id d f i linew version may provide unwanted functionality. Release management should not assume that all

previous releases have been accepted All filesprevious releases have been accepted. All filesrequired for a release should be re-created whena new release is installed.


Release decision makingg

Preparing and distributing a system release is an Preparing and distributing a system release is anexpensive process.

Factors such as the technical quality of the Factors such as the technical quality of thesystem, competition, marketing requirementsand customer change requests should allg qinfluence the decision of when to issue a newsystem release.


System release strategyy gy

Facto r Descriptionp

Techn ical qua lity ofthe system

If serious system faults are repo rted wh ich a ffect the way in wh ichmany cus tomers use the sys tem, it may b e nec essary to issue a faultrepa ir release. Howeve r, minor system faults may be repa ired by issuingpatche s (often d istributed ove r the Internet) that can be app lied to the

t l f th tcurrent release of the system.

Platform change s You may hav e to create a new releas e of a software app lication when anew version o f the ope rating sys tem platform is released .

LehmanÕs fifth law( Ch t 21)

This sugge sts that the increment of func tiona lity that is included in eachl i i t l t t Th f if th h b t(see Chapter 21) release is app roximately cons tant. Ther efore, if there has been a system

release with significant ne w func tiona lity, then it m ay have to befollowed by a repa ir release.

Competition A new system releas e may be n eces sary be cause a co mpeting p roduc t isava ilable.

Marke tingrequ irements

The marketing d epar tment of an org anisation may have made acommitm ent for releases to be ava ilable at a pa rticular da te.

Customer chang eproposa ls

For customised systems , cus tomers may have made and paid for aspecific set of system change propo sals and they expe ct a system release


p p p y g p p y p yas soon as these have been implemented.

Release creation

Release creation involves collecting all files and Release creation involves collecting all files anddocumentation required to create a systemrelease.

Configuration descriptions have to be written fordifferent hardware and installation scripts have topbe written.

The specific release must be documented torecord exactly what files were used to create it.This allows it to be re-created if necessary.


System building

The process of compiling and linking software

System building

The process of compiling and linking softwarecomponents into an executable system.

Different systems are built from different Different systems are built from differentcombinations of components.

This process is now always supported by This process is now always supported byautomated tools that are driven by ‘build scripts’.


System building problems Do the build instructions include all required

t ?

System building problems

components?• When there are many hundreds of components making up

a system, it is easy to miss one out. This should normallybe detected by the linkerbe detected by the linker.

Is the appropriate component versionspecified?• A more significant problem. A system built with the wrong

version may work initially but fail after delivery. Are all data files available?

• The build should not rely on 'standard' data files. Standardsvary from place to place.


System building problems Are data file references within components

System building problemsp

correct?• Embedding absolute names in code almost always causes

problems as naming conventions differ from place to place. Is the system being built for the right platform

• Sometimes you must build for a specific OS version or hardwareconfiguration.g

Is the right version of the compiler and othersoftware tools specified?• Different compiler versions may actually generate different code andDifferent compiler versions may actually generate different code and

the compiled component will exhibit different behaviour.


System buildingy g


CASE tools for configuration managementg g

CM processes are standardised and involve CM processes are standardised and involveapplying pre-defined procedures.

Large amounts of data must be managed.g g CASE tool support for CM is therefore essential. Mature CASE tools to support configuration

management are available ranging from stand-alone tools to integrated CM workbenches.


CM workbenches

Open workbenches Open workbenches• Tools for each stage in the CM process are

integrated through organizational procedures andg g g pscripts. Gives flexibility in tool selection.

Integrated workbenches• Provide whole-process, integrated support for

configuration management. More tightly integratedtools so easier to use However the cost is lesstools so easier to use. However, the cost is lessflexibility in the tools used.


Change management toolsg g

Change management is a procedural process so it can Change management is a procedural process so it canbe modelled and integrated with a version managementsystem.Change management tools Change management tools• Form editor to support processing the change request forms;• Workflow system to define who does what and to automate

information transfer;information transfer;• Change database that manages change proposals and is linked

to a VM system;• Change reporting system that generates management reportsChange reporting system that generates management reports

on the status of change requests.


Version management toolsVersion management tools

Version and release identification• Systems assign identifiers automatically when a new version is

submitted to the system. Storage management

• System stores the differences between versions rather than all theversion code.

Change history recording• Record reasons for version creation• Record reasons for version creation.

Independent development• Only one version at a time may be checked out for change. Parallel

working on different versions.working on different versions. Project support

• Can manage groups of files associated with a project rather than justsingle files.


Delta-based versioningDelta based versioning


System buildingy g

Building a large system is computationally Building a large system is computationallyexpensive and may take several hours.

Hundreds of files may be involved Hundreds of files may be involved. System building tools may provide

• A dependency specification language andA dependency specification language andinterpreter;

• Tool selection and instantiation support;• Distributed compilation;• Derived object management.


Component dependenciesComponent dependencies


Key points

Configuration management is the management of system

Key points

Configuration management is the management of systemchange to software products.

A formal document naming scheme should beestablished and documents should be managed in aestablished and documents should be managed in adatabase.

The configuration data base should record informationb t h d h tabout changes and change requests.

A consistent scheme of version identification should beestablished using version numbers, attributes or changeg gsets.


Key pointsKey points

System releases include executable code data System releases include executable code, data,configuration files and documentation.

System building involves assembling components into asystem..

CASE tools are available to support all CM activitiesCASE tools may be stand alone tools or may be CASE tools may be stand-alone tools or may beintegrated systems which integrate support for versionmanagement, system building and change management.


configuration management - hwyjc32/project/ref-software...objectives to explain the importance of...

Documents