Configuration Management, Software Project Management

8/14/2019 Configuration Management, Software Project Management

1/36

Configuration ManagementDibyesh Giri

Nepal


2/36

Configuration Management

Configuration Management is the process which controlsthe changes made to a system and manages thedifferent versions of the evolving software product.

Configuration management involves the development andapplication ofprocedures and standards for managing an

evolving system and releasing them to customers.Procedures should be developed for building systems andreleasing them to customers.

Standards should be developed for recording andprocessing proposed system changes and identifying and

storing different versions of the system.CM may be part of a more general software qualitymanagement process.

In some organizations, the same managermay sharequality management and configuration management

responsibilities.


3/36


Software may be released by the developers to aquality assurance team who are responsible forchecking that the system is ofacceptable quality.

It is then passed to the configuration management

team who become responsible for controlling changesto the software.

Controlled systems are sometimes called baselines asthey are a starting point for controlled evolution.

Reasons why systems exist in different configurations.1. For different computers.2. For different operating systems.

3. Incorporating client-specific functions, etc.


4/36


Configuration managers are responsible forkeepingtrack of the differences between software versions andfor ensuring that new versions are derived in a controlledway.

Configuration managers are responsible for ensuringthat these new versions are released to the correctcustomers at appropriate time.

The configuration management process and associateddocumentation should be based on a set ofstandards.Within an organization, these standards should be

published in a configuration management handbook oras part of a quality handbook. e.g. IEEE standard 828-1983, which is a standard for configuration managementplans.


5/36


Initial

System

PC

Version

DEC

Version

SunVersion

VMS

Version

Mainframe

Version

Unix

Version

Workstation

Version

DEC-Digital Electronic Configuration


6/36

CM takes over control of systems after

they have been developed.

Planning CM process must start during

system development.

A CM plan should be developed as part of

the overall project planning process.

Configuration Management CM Planning


7/36


The CM plan should include at least the following information:

The definition ofwhat entities are to be managed and a formalscheme for identifying these entities.

A statement ofwho takes responsibility for the configuration

management procedures and for submitting controlled entities tothe configuration management team. The configuration management policies which are used for

change control and version management. A description of the records of the configuration management

process which should be maintained.

A description of the tools to be used for configurationmanagement and the process to be applied when using thesetools.

A definition of the configuration database which will be used torecord configuration information.


8/36


An important part of the CM plan is the definition ofresponsibilities.

It should define who is responsible for the delivery of eachdocument or software component to quality assurance

and configuration management.It may also define the reviewers of each document.

The person responsible for document delivery need not bethe same as the person responsible for producing the

document.To simplify interfaces, it is often convenient to make projectmanagers or team leaders responsible for all of thedocuments produced by their team.


9/36


ConfigurationItemidentification In the course of developing a large software system, thousands of

documents are produced. Many of these are technical workingdocuments which present a snapshot of ideas for furtherdevelopment

These documents are subject to frequent and regular change. A key task of the configuration management planning process is todecide exactly which items ( or classes of item) are to be controlled.

Documents or groups of related documents under configurationcontrol are formal documents or configuration items

Project plans, specifications, designs, programs and test data suits

are normally maintained as configuration items. However, all documents which may be necessary for future systemmaintenance should be controlled.


10/36


ConfigurationItemidentification The document naming scheme must assign a

unique name to all documents underconfiguration control.

There will be relationship between documents.e.g. design documents will be associated withprograms.

These relationships can be recorded implicitly by

organizing the naming scheme so that relateddocuments have a common root to their name. This leads to hierarchical naming scheme.


11/36


ConfigurationItemidentification

Hierarchical naming Scheme:PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODE

PCL-TOOLS/EDIT/HELP/QUERY/HELPEFRAMES/FR-1 These names have a number of components. The initial part of the

name is the project name, PCL-TOOS.

There are four separate tools.

PCL-TOOLS/COMPILE

PCL-TOOLS/BINDPCL-TOOLS/EDIT

PCL-TOOLS/MAKE-GEN

The problem with naming schemes of this sort is that they areproject-based.

Components are identified as being associated with a particularproject.


12/36


The Configuration Database As part of the configuration management plan, a

database schema to record configuration informationshould be defined.

The configuration database is used to record all relevantinformation relating to configurations. Its principal functions are to assist with assessing the

impact of system changes and to provide managementinformation about the CM process.

As well as defining the database schema, procedures forrecording and retrieving project information must also bedefined as part of the Configuration ManagementPlanning Process.


13/36


The Configuration DatabaseA configuration database must be able to provide answers to a variety of queries about system configurations. Typical

queries might be:

3. Which customers have taken delivery of a particularversion of the system?

4. What hardware and operating system configuration isrequired to run a given system version?

5. How many versions of a system have been createdand what were their creation dates?

6. What versions of a system might be affected if a

particular component is changed?7. How many change requests are outstanding on a

particular version?

8. How many reported faults exist in a particular version?


14/36

Configuration Management Change

Management

Change is a fact of life for large Software System. This requires corresponding changes to be made to the

software. There is therefore a need for a system to ensurethat changes are recorded and applied to the system in acost-effective way.

Change management procedures should be designed toensure that the costs and benefits of change are properlyanalyzed and that changes to a system are made in acontrolled way.

Change management processes involve technical change

analysis, cost-benefit analysis and change tracking. The first stage in the change management process is to

complete a Change Request Form (CRF). This is a formaldocument where the requester sets out the changerequired to the system.


15/36


Management

Change Request FormProject: Proteus/PCL-Tools Number:23/94

Change requester: I. RGP Date: 1/08/2007

Request change: When a component is selected from the structure, display the name of the filewhere it is stored.

Change analyser: BNB Analysis date: 10/08/2007

Component affected: Display-Icon-Select, Display-Icon-Display

Associated components: FileTable

Change assessment: Relatively simple to implement as a file name table is available. Requires thedesign and implementation of a display field. No changes to associated components arerequired.

Change priority: Low

Change implementation:

Estimated effort: 0.5 days

Date of CCB: 15/08/2007 CCB decision date:02/09/2007(Change ControlBoard)

CCB decision: Accept change, Change to be implemented in Release 2.1

Change Implementer: Date of change:

Date submitted to QA: QA decision:

Date submitted to CM:

Comments


16/36


Management

The CM team, rather than the system developers, isresponsible for building a new version or release of thesoftware.

Change requests are themselves configuration items.They should be registered in the configuration database.

As software components are changed, a record of thechanges made to each component should bemaintained. This is sometimes called the derivationhistory of a component.

The procedural nature of this process means that achange process model can be designed and integratedwith a version management system. This model maythen be interpreted so that the right documents arepassed to the right people at the right time. e.g. Lifespan.


17/36

Configuration Management Version and

Release Management

Version and release management are the processes ofidentifying and keepingtrack of different versions andrelease of a system.

A system version is an instance ofa system that differs, in

some way, from other instances. New versions of thesystem may have different functionality, performance ormay repair system faults.

Some versions may be functionally equivalent but designedfor different hardware or software configurations. If there

are only small differences between versions, one ofthese is sometimes called a variant of the other.


18/36


Release Management

A system release is a version that isdistributed to customers.

Each system release should either include

new functionality orshould be intended fora different hardware platform.

Normally, there are more versions of a

system than release. Some versions maynever be released to customers. e.g.versions may be created within anorganization for internal development or

for testing.


19/36


Release Management

A release is not just an executable program or setof programs. It usually also includes:

Configuration files defining how the releaseshould be configured for particular

installations. Data files which are needed for successful

system operation. An installation program which is used to help

install the system on target hardware. Electronic and paper documentation describing

the system.


20/36


Release Management

All above information must be made available on somemedium which can be read by customers for thatsoftware.

For large systems, this may be magnetic tape.

For smaller systems, floppy disks may be used.Increasingly, however, releases are distributed on CD-ROM

disks because of their large storage capacity.

When a system release is produced, it is important to

record the versions of the operating system, libraries,compilers and other tools used to build the software.

If it has to be rebuilt at some later date, it may benecessary to reproduce the exact platform configuration.


21/36


Release Management

Version Identification

Identifying versions of a system appears to be

straightforward.

Linear Scheme 1.0 subsequent 1.1,1.2,1.3,

At some stage it is decided to create release 2.0

and process starts again 2.1,2.2,2.3,

Version Management tools such as SCCS(Rochkind, 1975) support this approach to

version identification.


22/36


Release Management

Version ManagementLinear Scheme is simple but it has associated problems: When should a new release (i.e. a new branch in the derivation

graph) rather than a new version be created?

If several versions are created from a single parent, how shouldbe they numbered? e.g. say a system is intended to run on anumber of different computer architectures. These are all derivedfrom a single base release numbered 1.0. Should the versions benumbered 1.1, 1.2 and so on, implying sequential derivation?

If many versions of a system are created and distributed todifferent customers, should the version naming scheme includesome customer identifier? Each customer or system user mayhave a unique version of the system.

These identification problems arise because the naming schemeimplies a linear derivation of versions whereas the actual logical

derivation structure is a network structure.


23/36


Release Management

Version ManagementAn alternative to a numeric naming structure is to

use a symbolic naming scheme. e.g. rather thanrefer to Version 1.1.2, a particular instance of a

system might be referred to asV1/VMS/DBserver. This implies that this is ofversion of database server for a Digital computerrunning the VMS operating system.

This has some advantages over the linear schemebut, again, it does not truly represent thederivation structure.


24/36


Release Management

V1.0 V1.1

V1.1.1V1.1b

V1.2 V2.0 V2.1

V1.1a

V2.2

Version derivation structure

Version Management


25/36


Release Management

Version Management

Customer

Development language

Development status Hardware platform

Creation date

New system versions should always be created bythe CM team rather than the system developers.System developers should not have write accessto this database.


26/36


Release Management

Release Management New versions of a system may be created to fix reported

faults or as part of the development process.

Creating a new system version involves creating newsource code and building the system.

Creating a release, however, is more complex andexpensive. As well as creating new source code andsystem building, data and configuration files may have to

be prepared and new documentation written. Therelease must be packaged and distributed to customers.


27/36


Release Management

Release Management

Over the lifetime of a system, changes are likely to beproposed on a fairly regular basis.

Corrective changes are intended to fix faults.

Perfective changes are intended to implement newrequirements.

Adaptive changes are intended to change the system tomake it operate in a new environment.

The configuration managermust decide how often thecomponents affected by these changes should be rebuiltinto a new version or release of the system.


28/36


Release Management

Release Management

When a new release of a system is created, thechanges which have been made may introduce

new faults or bring other existing faults to light.The more changes to system, the more new faultswill be introduced.

If a release incorporates a large numberof

changes, it is likely that there will be acorrespondingly a large number of new faults.

These have to fixed in the next system release.


29/36


Release Management

Release Management

Lehman suggested that if a lot of newfunctionality was introduced in one release

of a system, it would be necessary toissue another release fairly quickly.

This suggests that it is unwise to change

too much of a systems functionality atonce. Otherwise an excessive numberoffaults may be introduced.


30/36


Release Management

Release Management

A good change strategy is to interleave fault

repair release immediately after the

Enhanced release.

All serious faults (faults which cause system

corruption) should be repaired before

functional or behavioral changes are applied.

Enhanced

release

Repair

release

Repair

release

Enhanced

release

Repair

release

Figure System Release Strategy



31/36


Release Management

Version Management Tools

Version management involves managing large amounts ofinformation and ensuring that system changes arerecorded and controlled.

There are several CASE tools available to supportversion management.

For UNIX platforms, the most widely used versionmanagement systems are SCCS (Rochkind, 1975) andRCS (Tichy,1985).

Version management system control a repository ofconfiguration items where the contents of that repositoryare immutable (i.e. cannot be changed).



32/36


Release Management

Version management tools

All version management systems provide acomparable basic set of capabilities althoughsome have more sophisticated facilities than

others. Examples of the capabilities which maybe included in a version management systemare:

3. Version and release identification

4. Controlled change5. Storage management

6. Change history recording


33/36

Configuration Management CM Tools

Configuration Management Tools VSS Visual Source Safe for documents.

VSTS - Visual Studio Team System

VAJ - Visual Age for Java for source files. RCE Revision Control Engine.

Software Manager Information from virtual sky.

QVCS Quma Version Control System.

Source Code Manager. SCLM Software Configuration Library Manager.

CVS Concurrent Version System.


34/36


VSS

VSS is used through out the life cycle. The purpose ofthis tool is identifying the configurable items in theproject. Keep those in repository and maintain versioncontrolling.

It is a Version control tool.

VSS is a virtual library of computer files. VSS is a common repository In VSS store the information like FRS, SRS, TP, Test

cases documents

In VSS documents read only but not modifying If we want to modify that first we need to check out(download) the required file to our local system thenmodify the file and then check in (upload) the modifiedone.


35/36


VSS

Virtual Source Safe... Visual SourceSafe (VSS)is a client/server application which acts as astorage system for files.

A file stored in a VSS server is not available viathe standard file system, instead, it must beaccessed through the VSS client tools Tool.

Mainly useful to developer, for storing code and

maintains version copying a code from VSS Bydevelopers is called CHECK-IN Upload the codein to VSS is called CHECKOUT.


36/36


VSS-VSTS

Microsoft recently developed a team collaboration tool called "VisualStudio Team System" (VSTS). This tool allows source controlmanagement and several other software development managementtools.

Microsoft will be promoting VSTS in future instead of VSS. However,next few years, VSS will still be the most popular source control

system due to it's easy to use user interface, simple configurationsand availability of experienced users.

Visual Source Safe is available as part ofVisual Studio .NETproducts.

The following are the various versions currently in use by majority ofthe development teams:

Visual Source Safe 5.0 Visual Source Safe 6.0 Visual Source Safe 2005 Visual Source Safe 2005 is

available as part of the Visual Studio 2005 suite of products.