an automated configuration management d. … automated configuration management system to benefit...

An automated configuration management

system to benefit software developers

D. Cayford

ComW

ABSTRACT

'The referee had a good game, I hardly noticed he wasthere!' is probably the best compliment a football referee willreceive. His task , which can be frustrating and thankless, isto support the football players but also ensure that the rulesof the game, as defined by the Football Association (FA), areadhered to, in order that paying customers receive value formoney and therefore return again. These sentiments could beapplied to a Software Configuration Management System (SCMS),whose purpose is to support software developers, but alsoensure that the controls defined by Project Management areadhered to in order that the paying customers receive areliable, quality product.

Of course, it is quite possible for footballers to producea good match without a referee at all, as long as all playershave sufficient self discipline to abide by the rules, and moreimportantly, that nothing goes wrong! It could also be arguedthat a game with no referee is better than a game with a badreferee ie. one who inhibits the flow, creates obstacles, andcauses resentment among the players. Similar arguments canalso be used against an SCMS. On the other hand, the FA andmost players accept that the game of football benefits from aneffective referee, one that does not restrict skill andindividuality, one whose presence is not obstructive, one whocan take action when tempers are raised in order to preventchaos, and one who can provide status reports back to themanagement of the game.

Perhaps the analogy between a football referee and a SCMSends there. A major difference is that the effectiveness of anSCMS does not stop when the final whistle blows! Not only is itimportant to deliver a quality product on time, but it isessential that maintenance and enhancements to the system canbe easily implemented over a long period of time. The best wayof ensuring this is to record in the SCMS, the identity of allsoftware components, the relationships between them, and the

Transactions on Information and Communications Technologies vol 9, © 1994 WIT Press, www.witpress.com, ISSN 1743-3517

596 Software Quality Management

history of change. The best chance of achieving thissuccessfully, and thereby realising the full benefits ofConfiguration Management (CM), is with the active support ofthe software developers.

This paper provides an example of an SCMS which has beenimplemented successfully during the development phase of alarge project. The essential factor has been in considering theneeds of software developers, and as a result, the system isviewed positively and not as a restrictive and inconvenientoverhead.

INTRODUCTION

In 1987, BAeSEMA was awarded one of the largest softwareprojects ever placed as a contract by the MoD. The softwaredevelopment team, which peaked at around 250 people, hasalready delivered 6 releases and is currently working inparallel on a further 4 more, to be completed by end-1994. Aswell as being large (1 million lines of ADA) and technicallydemanding (described as one of the 10 most complex softwareprojects in the world), the demands of developing andsupporting multiple phased releases dictated that effectiveconfiguration management was essential.

The impetus to 'get it right' came from ProjectManagement, who also accepted that the SCMS would take time andeffort to establish and maintain. Experience had shown thatwith pressures to develop, build, and test complex software totight timescales, even software engineers with good intentions,often regard CM as an activity that has to be discarded whenthe pressure mounts. It was felt that this situation must beavoided since it presented support engineers with an uphilltask to correct and modify that software, especially if thestructure and history is not identifiable. In addition, thelong term view was that if a system could satisfy the demandsof this project, especially during the periods of rapidchanges, it would be relatively simple to apply to all futureprojects within the Company. Note: This has in fact alreadyoccurred, for a project which, if anything, is even larger,more complex, and more demanding.

SCOPE

At an early stage of the project the scope of the SCMSwas identified; it would be used for document control, codecontrol, baselines, change control, tools control, metricsmeasurement, and reporting. It was to be accessible to allmembers of the project, during the System Design, Development,Integration, and Support stages. In-built approval mechanisms


Building Quality into Software 597

would be required to ensure that items could only be progressedthrough critical stages of the life-cycles with the agreementof nominated, independent personnel. The SCMS would be requiredto store securely a large number of CIs and provide controlled,concurrent access to them for reference and change.

Documents to be controlled would be generatedelectronically and include management documentation (plans,procedures etc), design documents, and test documents. Codeitems would include source code, generated executables, testdata, and test results.

Document Generation and Code Generation tools were to bean important feature of the project, which was to be developedaround JSD methodology. The JSD databases from which detaileddesign documents and code were generated would need to beconfigured as related sets of data.

The key aspects of the project life-cycles were consideredas follows. At the system design stage, the SCMS would need tocope with a relatively small number of CIs and baselines.During development, the number of CIs would rise dramatically,although the frequency of baselines would remain low. Theinteraction between development teams working on differentreleases would become a major issue. During integration, therewould be rapid change to CIs, an increased number of baselines,and there would be significant interaction between integrationand development teams. At the support stage, the configurationmust be clearly defined so that external fault reports andproposed enhancements could be processed quickly. Theinteraction with later development and integration teams wouldremain a major issue.

The metrics information would relate to the size ofsoftware, and the level and nature of changes. Managementreports were to be considered a key aspect which could bedefined and implemented at any stage.

The SCMS should be easy to use, impose minimal trainingoverhead, be cost-effective and provide benefits to softwaredevelopers by automating many activities, using batchprocessing, be responsive, provide facilities which save timeand effort, and provide information which may otherwise not beavailable.

APPROACH

At the outset there appeared to be two approachesavailable: either to write a detailed requirement specificationfor the SCMS and implement a solution, or to adopt a flexible,building block approach of defining and implementing the SCMS



in stages. The first approach was rejected on the grounds thatit would take too long to agree a detailed specification andthe project would be too advanced by the time a solution wasimplemented. The second approach offered advantages in that theSCMS could develop and grow with the project, and it offeredmore scope for using in-house resources, which would mean thatthe system could be more easily adapted and expanded to meetfuture project requirements.

A Software Configuration Manager (SCM) was identified as akey person, who should manage the implementation of the system,ensure that Def Stan 05/57 and IS09001 standards were met, callin expertise where necessary, and collect the views of projectmembers.

It was also decided to establish an SCMS Implementationteam whose role would be: to write detailed specifications foreach element of the system; to identify whether acceptableproprietary tools existed; to develop in-house those elementswhich could not be purchased; to test all aspects of thesystem; and to initially implement the SCMS in a liveenvironment on behalf of the project teams. The latter task wasto ensure that the SCMS implementation team gained practicalexperience of using the system as well as knowing the theory,arid also to resolve any difficulties prior to the project teamsbeing impacted.

THE SCMS MODEL

The SCMS Implementation Team identified a four-tier modelthat would meet the outline requirement.

The first tier contained the essential tools for the jobie. the referee's whistle, little red book etc. For the SCMS,this represented the essential ingredients of configurationcontrol, namely: a secure storage area with controlled access;allocation of unique identifiers to configured items; in-builtapproval process (unapproved/approved items); automated issue(for change and reference); notification to interested users;and progressive archival (and retrieval) of redundant items.

It was decided to use two proprietary tools, one fordocument control (Digital's All-in-1 office automation systemincorporating WPSPLUS as a word processing package) and one forcode control (Lifespan). Both tools provided programmableinterfaces to allow their capabilities to be enhanced, andthese were considered to be essential features.

The basic capabilities of the All-in-1 system for documentgeneration and electronic messaging were extended in-house toproduce a document control system by incorporating the required



automated configuration control features. For the code controlsystem, Lifespan readily provided all of these elements andalso featured facilities to define baselines and to import andexport hierarchical sets of data.

The second tier incorporated user interfaces for thedocument and code control systems. This was considered to bethe critical ingredient for success of the SCMS, especiallywith the realisation that the change control mechanisms werejust documents and therefore the user interfaces would alsoincorporate change control. If tailored interfaces could beproduced which satisfied the needs of the project and providedusers with simple but powerful utilities, then success was morelikely. In our football analogy, the referee's consideration ofplayer's needs and impulses, as well as implementation of therules, dictates whether he is viewed positively or not. Theimplementation of the user interfaces therefore is the majortopic for the rest of this paper.

The third tier encompassed visibility of the SCMSdatabase, which came in three forms: a Configuration Librarywhich identified the latest version of, and relationshipsbetween, the major configuration items; metrics tools whichgathered data and represented it in graphical form; and userspecific and general purpose status reports.

The fourth tier provided essential but minimal guidance onhow to use the system - simple procedures and user guides.

TAILORABLE USER INTERFACES

As stated earlier, tailorable user interfaces were seento be the essential ingredient to successfully implementing theSCMS. The main aims were to make them simple but powerful, andwith functionality which saved effort for developers whilemaintaining controls. In addition, the aim was to provide asystem which was consistent, easy to use, responsive, and whichincorporated notification messages on occurrences and requiredactions.

The importance of the user interfaces dictated that theyshould be developed in-house in close consultation with theusers. Expertise was required in both All-in-1 and Lifespan,and their programmable interfaces. This was gained initially byutilising consultants from the tool suppliers and then trainingin-house personnel.

Four factors were taken into account when developing theuser interfaces: functionality, presentation, controls, anddata capture. Functionality was mainly dictated by the softwaredevelopment teams, in terms of the utilities that were



essential and also any which would save them time. No limit wasplaced on the complexity of a function, since the plan was touse batch processing for time-consuming activities. Therequired functions were assessed and implemented whereverpossible. In general, the presentation was menu driven,although direct access to certain utilities was provided. Thedecision on controls was dictated by the status reports thatwere required and the level of notification. Data capture fellinto three categories: the data required by the document andcode control mechanisms in order for the functionality to beachieved, the data required for control information, and thedata required for metrics and reporting.

The net outcome was separate tailored user interfaces forthe document control, code control, and change controlfunctions. The key features which have been implemented aredescribed below.

Document Control

Two All-in-1 menus were developed to interface with theDocument Control System (DCS); the first provided functions fora user to progress a document from the Word Processing (WP)environment into the DCS, and the second allowed a document tobe progressed within/from the DCS. In the WP environment, twokey features were provided, as highlighted in figure 1:

Word and Document Processing

SEL Select Folder:Title:Date: Modified on:

cEDPRIRI

VS

CreateEditDeletePrintReadIndexRecall index

ViewSend

Ref:

Clasj

ARFD

TR

sif ication:

Assign projectFile and distri

Training

referenceLbute

Figure 1 User's WP Environment Options

AR enables a unique project filing reference to be assignedto a document. The document is left in the WP environment but



its reference is automatically updated to the value allocated,and the version is flagged as 'DRAFT' eg. version 1A DRAFT. Anentry is made in the DCS indicating where the draft documentexists.

FD allows a document to be filed in the DCS and a messagesent to users specified on the document distribution list. Thedocument is deleted from the WP environment. The 'DRAFT' statusis dropped from the document version eg changed from 1A DRAFTto 1A. At this stage, approvers of the document are identified,as are any parent documents.

In the DCS environment, three key features were provided,as highlighted in figure 2:

Cabinet Options

SEL SelectSELI Select Issue

P PrintR ReadI IndexV View

CV Create New VersionCS Create Summary Sheet

CF Create FolderEF Edit Folder

MP Multiple PrintMCD Copy to Personal Cabinet

Folder:Title:Ref:

Classification:

Archive State:

APP Approvals OptionsARCH Archiving Options

L Locate DocumentPI Print IndexUDI Update Document IndexMFD Master File Directory

Figure 2 DCS Environment Options

APP provides approval options, enabling a document to besubmitted for approval (by originator), withdrawn from approval(by originator), approved (by named approvers/checkers), andraised to issue (by originator). A document is prevented fromfurther updates during the approval process. Raising a documentto issue causes the version status to increase from itsunapproved value to the approved status eg. l A t o l .

CV allows a new version of a document to be created in auser's WP environment for update purposes, based on the latestversion in the DCS. The document version is automaticallyincreased to the next 'draft' state eg. from 1A to IB DRAFT orfrom 1 to 2A DRAFT. A record is maintained in the DCS of where



the draft document exists.

MCD generates a copy of a document from the DCS into a user'sworking environment for reference purposes. The documentversion is automatically updated to 'copy' status eg. from 1Ato 1A COPY.

Change Control

The change control system within the SCMS was based onthree existing paper based control mechanisms: an ObservationReport (OR), a Change Request (CR), and a Concession (CN). TheOR was used to identify a problem, which would be investigatedand recommendations made. The CR was used to detail the natureof a change and the items affected. A Concession was used ifthe implementation of an identified problem was to be deferred.

The important factor about these change control mechanismswas that they could all be treated as documents, and thereforethe DCS could be applied to them. A key feature of the changecontrol documents, however, was that a high percentage of thetext was fixed format and so special document proformas weredesigned. These enabled data to be captured into separate filesand processed for status reports and metrics purposes.

Two additional menus, as shown in figures 3 and 4, wereintroduced into the WP environment to support the changecontrol life-cycles. In addition to the AR and FD functionsdescribed earlier, the following functions were provided:

OR/CR Reporting Facility

SEL Select Report Report:Title:Ref:

COR Create Observation ReportCCR Create Change Request

EDPRVI

S

EditDeletePrintReadViewIndex

Send

ED

INV

APP

ARFD

Edit Data

Investigation Options

Approvals Options

Assign ReferenceFile OR/CR Document

Figure 3 Change Control Options (a)



COR/CCR create OR and CR documents with special proformas toaid data entry and capture.

INV provides options which allow an investigation report to becreated and then to be attached to an OR, incorporating arecommendation and additional metrics data gathering.

APP incorporates additional approval stages for an OR or CRduring its life-cycle, prior to it being filed in the DCS.

OR/CR Reporting Facility - continued (1)

SEL Select Report Report:Title:Ref:

ROR Reference OR ER Enter RecommendationDOR De-reference OR RR Remove Recommendation

MT Modify Title MAN OR/CR Reporting

SC Spell Check REP Reporting Facility

Figure 4 Change Control Options (b)

ROR allows an OR to be referenced from a CR, andsimultaneously records the CR reference on the OR.

ER provides the capability to enter a closure recommendationreference on an OR, other than a CR (which is provided by ROR).

MAN/REP provide management/user status report options onoutstanding ORs and CRs.

Code Control and Baselines

Code control and baselines were implemented by developingan interface to the Lifespan control system. A single screenwas developed, as shown in figure 5, to support development(code implementation) and integration of system builds. The keyfunctions relevant to these activities are described below.



LIFESPAN Access Routines

NH Create LIFESPAN HeadersUH Update LIFESPAN HeadersVH Variant LIFESPAN Headers

RI Retrieve Item(s)

LCI List Changed ItemsROV Retrieve Old VersionCCR Configure CR Items

LUC List Unbaselined CRsLBC List Baseline Changes

BDI Baseline Development ItemsRDB Retrieve Development B/L

URI Unlock Retrieved Item(s)

LUI List Unchanged ItemsLFO List Files Out For Change

RCR Retrieve CR Items

Figure 5 Lifespan Access Facilities

During development, the essential requirements were notonly to control individual code items, but also to controldatabases (directories) of related items. Control of individualitems was achieved via the mandatory Lifespan header blockassociated with each item. This header block maintained theunique identifier and change history details for an item. Threefunctions were provided, which operated on a single item ormultiple items, to standardise the generation and entry of keydelta within the header:

NH applies a Lifespan header to a new item by establishing aunique name and setting the initial version.

UH updates a Lifespan header by generating a new versionrecord and recording the applicable change request (CR)reference.

VH creates a variant Lifespan header by allocating a newunique name and version, and recording that the item is avariant of an existing item from an earlier release.

For controlling databases of items, two further functionswere provided:

BDI allows a 'snapshot' to be made in Lifespan of the currentstate of a user's database ie. a baseline that can be recalledin the future.

RDB retrieves a development baseline which has been configuredin Lifespan.



On completion of development, the configured developmentbaselines are withdrawn from Lifespan, via the RDB function,and integrated into a system build. At this stage the formalchange control mechanisms are invoked, whereby an observationreport (OR) is raised to record details of a problem (ormultiple related problems) and their consequent investigation,and a CR is raised to record the action taken. The followingfunctions were provided to support rapid changes of code itemsduring the integration of system builds:

RI retrieves an item or set of items from Lifespan into auser's working environment to allow changes to be made. Theitems are locked to that user to prevent other changes beingmade in parallel. The Lifespan header block for each item isupdated to a new version and the CR reference is identified asthe reason for change.

CCR configures a set of CR changes in Lifespan, by searchingfor items with a specified CR reference and automating theconfiguration process. A list of the items is generated forincorporation into the CR document to identify the itemsaffected by the change. The development databases affected bythe changes are also identified. Note: A new build baseline isgenerally defined following multiple CR configurations, when anew system build is initiated.

LUC produces a list of all CRs which have been configured inLifespan but not yet applied to a system build baseline. Thelist identifies the CR reference, the date configured, and thedatabases affected.

RCR retrieves CR changes from Lifespan and applies them to abuild baseline.

LCI/LUI/LFO/LBC provide status reports of items changed viaa CR, items not changed for a CR, items currently out forchange and locked, and items that were changed in a specificbuild baseline.

BENEFITS OF THE SCMS

The original aim was to implement the SCMS in such a waythat it provided benefits to software developers, therebyproviding a platform for achieving longer term benefits duringthe project support phase, and provide a system which could beapplied to all future projects. The following benefits havehelped to achieve this objective:

a) The tailored user interfaces incorporate effectiveand powerful utilities, but the relatively small number meansthat the system is easily understood. No formal training of



users has been required; simple user guides and occasionallunchtime seminars have been the only necessary support.

b) The small overhead to software developers of the SCMSis compensated for by the benefits of secure storage, easyaccess to configured items, reproducible baselines, impact ofchange reports, and detailed status reports of configured itemsand outstanding changes. The readily available data/reports hasalso reduced the number of meetings, which has resulted in moreeffective use of personnel resources.

c) The number of free text user inputs has been kept toa minimum. The majority are either selectable from an optionlist or fixed format and subject to verification. Data entry istherefore not an onerous activity and the captured data isreliable and suitable for producing valuable status reports andmetrics information.

d) The user interfaces may be tailored further in thefuture to meet changes in project methods or to increase thefuctionality, because the experience has been gained in-house.

CONCLUSION

This paper has not described all aspects of the SCMS buthas concentrated on the impact and benefits to users. It hasbeen developed and implemented without affecting projecttimescales and the establishment of a CM Tools team has been anessential ingredient to this achievement. Software developershave had a major impact on the facilities provided, which hasresulted in a positive attitude towards its use. Thealternative approach of purchasing/developing a system andimposing its use is not considered to be a viable option.

The SCMS has proved to be a success and further benefitsas the project enters the support phase will justify theinvestment in establishing the system. It has helped transformattitutes positively towards CM and a second, larger projectbeing developed within BAeSEMA, is currently benefit ting fromthe work described in this paper, as will future projects ofall sizes.
