scm-software configuration management

8/7/2019 SCM-Software Configuration Management

http://slidepdf.com/reader/full/scm-software-configuration-management 1/22

Contents

Introduction..............................................................................................................................1

The purpose and benefits of SCM.............................................................................................2 SCM Activities...........................................................................................................................3

Configuration Identification.......................................................................................................4

Configuration Control................................................................................................................5

Configuration status accounting...............................................................................................7

Configuration Audits.................................................................................................................8

SCM Planning............................................................................................................................8

Automation of SCM...................................................................................................................9

Common features of SCM tools...............................................................................................10

Version Control .............................................................................................................................11

Lenses for the Analysis...........................................................................................................16

Maintenance systems.............................................................................................................18

Standards................................................................................................................................19

Conclusion:.............................................................................................................................20

Guidelines...............................................................................................................................21

Introduction

Configuration management (CM) is a field of management that

focuses on establishing and maintaining consistency of a system or

product's performance and its functional and physical attributes with its

requirements, design, and operational information throughout its life.

When we build computer software, change happens. And

because it happens, we need to control it effectively. Software

configuration management (SCM) is a set of activities that are designed to

control change by identifying the work products that are likely to change,

establishing relationships among them, defining mechanisms for managing



different versions of these work products, controlling changes that are

imposed, and auditing and reporting on the changes that are made.

For information assurance CM can be defined as the

management of security features and assurances through control of

changes made to hardware, software, firmware, documentation, test, test

fixtures, and test documentation throughout the life cycle of an informationsystem.CM for information assurance, sometimes referred to

as Secure Configuration Management, relies upon performance, functional

and physical attributes of IT platforms and products and their environments

to determine the appropriate security features and assurances that are

used to measure a system configuration state.

The purpose and benefits of SCM

SCM is a critical element of software engineering (Feiler 1990)According to Leon (2000), it is needed because of the increased complexityof software systems, increased demand for software and the changingnature of software.

Leon also states that SCM can be used as a strategic weapon that

will give theorganization an edge over those who are not using SCM or using it lesseffectively. When used effectively during a product's whole life-cycle, SCMidentifies software items to be developed, avoids chaos when changes tosoftware occur, provides needed information about the state ofdevelopment, and assists the audit of both the software and the SCMprocesses. Therefore, its purposes are to support software development and



to achieve better software quality. As it can be seen in Figure 1, SCM is oneof the major elements leading

SCM Activities

According to the IEEE's (IEEE Std. 828-1990) traditional definition ofSCM, the following four activities are included: configuration identification,configuration control, configuration status accounting and configurationaudits. Successful SCM implementation also requires careful planning(Abran & Moore 2001). SCM planning produces a document called SCM plan,in which SCM activities and other practices of SCM are described carefully

The SCM process further defines the need to trace changes, and the abilityto verify that the final delivered software has all of the plannedenhancements that are supposed to be included in the release. It identifiesfour procedures that must be defined for each software project to ensurethat a sound SCM process is implemented

The SCM Activities can be represented as:



Configuration Identification

According to Leon (2000), configuration identification is a processwhere a system is divided into uniquely identifiable components for thepurpose of software configuration management. These components arecalled computer software onfiguration items (CSCIs) or shorter and moregenerally justconfiguration items (CIs). A CI can be a unit or a collection oflower level items. IEEE defines configuration identification as an element of

SCM, consisting of selecting the CIs and recording their functional andphysical characteristics in technical documentation. Each CI must be namedand versioned uniquely to distinguish it from the other CIs and from otherversions of CIs. Examples of CIs are project plan, specifications, designdocuments, source codes, test plans and test data, executables, make files,tools, and SCM plan. Whitgift (1991) also states that every source itemshould have a status attribute which defines the level of approval that theitem has achieved. An example of the range of status values for an element



code is: untested, module tested and integration tested. Accordingly, adocument can have such values as draft, proposed and approved.

In the configuration identification phase, a project's baselines andtheir contentsare also identified. A baseline is a software configuration managementconcept that helps us to control change (Leon 2000). It is a document or

product that hasbeen formally reviewed and that thereafter serves as abasis for further development. It can also be an assembly of CIs, anaccepted configuration. The most common baselines of softwaredevelopment can be demonstrated as the life cycle model shown is atraditional waterfall model; every phase produces a baseline

Configuration Control

As stated earlier, software can change very quickly and easily, anduncontrolled changes can lead to chaos. Therefore, after the configurationitems of the system have been identified, the next step is to control thechanges to the software. Controlling changes during software development

has been defined as a task for SCM (Pressman 1997). According to Leon(2000), baselines have a very important role in managing change. baselinescan be changed only through formal change control procedures includingthe following steps: evaluation, coordination, approval or disapproval andimplementation of changes to configuration items.

A change request can result from many things. For example, newfeatures, enhancements of existing features or defects can lead to changerequests (Leon 2000.) The process starts, when a need for change is



noticed. A properly completed change request form is sent to theconfiguration control board (CCB), whose main function is toevaluate and to approve or disapprove change requests (Leon 2000)According to Leon (2000), change requests can also be deferred when theyand their associated documentation are filed for later resolution. If a changerequest is approved, proposed changes are assigned to developers to be

implemented. After implementation, the changes are verified in varioustesting procedures to ensure that they have been implemented as agreed.

Change is one of the most fundamental characteristics in anysoftware development process (Leon 2000). Lehman (1980) also suggeststhat change is intrinsic in software and must be accepted as a fact of lifeMaking changes to software is easy, but if it is done at will, chaos will resultAccording to McConnell (1998), effective projects control changes, whereasineffective projects allow changes to control them. However, Whitgift (1991)states that the level and formality of control required varies considerably;

large teams need strict and formal change control, but small teams can relyon much less formal control.

The change management process for conventional software



Configuration status accountingSoftware development produces lots of information that should be

recordable and reportable whenever needed. According to IEEE (IEEE Std.610.12-1990), configuration status accounting consists of the recording andreporting of information needed to manage a configuration effectively,including a listing of the approved configuration identification, the status ofproposed changes to the configuration and the implementation status ofapproved changes. All this and other information related to CIs andactivities concerned with them are thus available for the people involved inthe project. Status accounting reports include change logs, progressreports, CI status reports and transaction logs



Configuration Audits

According to Leon (2000), the purpose of configuration audits is toensure that the software product has been built according to specified

requirements (Functional Configuration Audit, FCA), to determine whetherall the items identified as a part of CI are present in the product baseline(Physical Configuration Audit, PCA), and whether defined SCM activities arebeing properly applied and controlled (SCM system audit or in-processaudit). A representative from management, the QA department, or thecustomer usuallyperforms such audits. The auditor should have competent knowledge bothof SCM activities and of the project (Leon 2000).

SCM PlanningAccording to Abran & Moore (2001), a successful SCM implementation

requires careful planning and management. All of the SCM activitiesintroduced above are described in the SCM plan. The main purpose of theSCM plan is to answer such questions as: who is going to do what, when,where, and how (Buckley 1996). Thus, the SCM plan serves as a guidelinefor the people working with software configuration management. Accordingto Buckley (1996), a configuration management plan is written for eachproject. However, an organization may use a generic SCM plan template



that can be tailored to each particular project. Table 1 presents the commoncontents of an SCM plan according to IEEE standards:

Automation of SCM

The basic SCM activities introduced in the previous subsection areassisted by SCM tools. According to Leon (2000) the role of an SCM tool is toautomate SCM activities and to improve development productivity.Automating manual SCM tasks provides more time to do the actuadevelopment work, leading to improved speed and productivity. From adeveloper point of view, SCM offers a stable development environment,maintains configuration items, stores their history, supports productbuilding and coordinates simultaneous changes (Crnkovic et al. 2001). In



other words, it helps software developers in their daily work. According toEstublier (2000), a typical modern software configuration management tooprovides primary services in the following areas:

Management of the repository of components

Version control

Support for engineers

Workspace management

Concurrency control

System building

Process control and support

According to Dart (1990), SCM is generally a combination of manual andautomated procedures. However, since most SCM processes are welestablished and repetitive, they can be supported by computers (Conradi &

Westfechtel 1999). We know that configuration identification is an SCMactivity in which configuration items are selected and their functional andphysical characteristics are recorded in technical documentation. Accordingto Leon (2000), this type of information can be captured and updatedautomatically by an SCM tool. Change management is an activity that issupported in many of today’s SCM tools (e.g. Conradi & Westfechtel 1999;Leon 2000). As one example, information about change requests goesdirectly to all the people concerned (such as the CCB), and they can thensend approval or disapproval immediately by e-mail or other messaging

systems. All the information related to the change process, such as whoinitiated the change, who implemented the change, andhow the change was implemented, can be captured and used for statusaccounting to manage the whole project more effectively (Leon 2000.) Thisand other relevant information can be then queried for the purposes ofvarious reports. As explained earlier, configuration auditing is the validationof the completeness of a product. According to Leon (2000), SCM tools canautomate most of the auditing, because they can generate the necessaryinformation for verification purposes. For example, one person might need ahistory of all changes and another a log containing details about workcompleted.

Common features of SCM toolsToday there are a number of SCM tools available, while their

features vary greatly. According to Leon (2000, p. 202), "each tool has itsown strengths and weaknesses. For example, some are better at change

Page10



management, whereas others have excellent build management andversioning capabilities." These are explained in details:

VERSION CONTROL

The main purpose of version control is to manage differentversions of configuration objects that are created during the softwareengineering process. According to Taramaa (1998), the term “object” isused by some authors to describe CI. A “component repository” is a placewhere all the versions of CIs are kept. The terms “version”, “revision” and“variant” are basic SCM concepts. Therefore, their differences are explainednext. The meaning of “branching” and “merging” is also explained. Let usassume that a developer is producing an item not yet under SCM control.S/he can freely modify the item, and the changes made affect this item, inparticular. But when the item is put under SCM control, changes to the itemproduce new revisions, CIs that change and evolve with time. They may becreated for various reasons, such as to extend functionality or to fix bugs(Conradi & Westfechtel 1996). Variants are versions that are organized inparallel development lines called branches. However, branches are only oneway to implement variants, because they can be done also with conditionacompilation, with installation description, or with a run-time check (Perssonet al. 2001). There are two types of variants: permanent and temporary(Whitgift 1991). Permanent variants are created, for example, when theproduct is adjusted for different environments. There can be a variant for

Linux and another for Windows. The difference between a permanent and atemporary variant is that a temporary variant will later be integrated withanother variant (Zeller 1996). This kind of integration is also called “merge”.According to Whitgift (1991), an instance of an item, each of its variants andrevisions, is called an item version.Figure 5 presents a situation where development is done in parallebranches. When revision 1.3 is almost done, revision 1.2, which is already inuse at a customer site, is noticed to have a bug. If there is no time to waitfor revision 1.3 to be approved, a temporary bug-fix branch is created, the

bug is fixed, and the variant is supplied to the customer. After that versions1.3 and 1.2.2 are merged into version 1.4. At the same time, developmentis also done in a permanent variant branch for Linux. Version attributevalues, mentioned in the SCM process section, are also supported by manyCM tools (Whitgift 1991). They can provide facilities for recording theevolution of an item through its lifecycle.

Page11



BASIC VERSION CONTROL:

WORKSPACES AND CHECK OUT/IN:

WORKSPACE MANAGEMENT

Page12



SCM tools can also help developers to work in peace by providing themwith private workspaces. The purpose of provided workspace is to preventusers from interfering with one another's work (Dart 1994). Developers cancheck out desired files or configuration from the repository in their ownworkspaces. The “check out” operation creates copies of the items in thedeveloper's workspace; after that, the developer can modify the items as

needed and finally execute “check in”. The “check in” operation copiesitems back into the repository: the version control system then creates newversions as needed. Figure 6 represents the check out/in process. A “get“operation equals to a “check out” operation, except that the files copiedinto the workspace are read-only and therefore cannot be modified. Theterminology in use for these operations can vary between different SCMtools.

BUILD MANAGEMENT

Whether you choose to use automated tools to build yourapplications or still use a manual process, a software configurationmanagement system helps you manage your process and results.

The term "build" is defined by Webopedia , as follows:

A particular version of a software package typically consists of anywherefrom a few files to thousands of files, depending on the application. Asoftware configuration management tool assists you in managing builds byenabling you to:

• Find out how a build was constructed and what went into itsconstruction for debugging or reproducibility purposes.

• Compare two or more builds.

RELEASE MANAGEMENT Release management is closely tied to build management in that a

specific release is essentially a production build of your application. Inaddition to putting the runtime software in its final form, release

management includes the deployment process as well as the update of related metadata that goes into tracking a given version of a softwareapplication. The primary purpose of a release is to make the applicationavailable to its end users.

Page13

http://www.webopedia.com/

http://www.webopedia.com/



CONCURRENCY CONTROL

The implementation of concurrency control depends on the SCM tool inuse. Some of these tools use so-called optimistic concurrency contro(Asklund & Bendix 2002), which means that files are not locked whenchecking them out, and there may be simultaneous modifications to the

same files by multiple users. Others prevent simultaneous access by using alocking mechanism. Microsoft's Visual SourceSafe (VSS) is a one example ofan SCM tool in which both of these mechanisms are implemented andlocking is used as a standard setting. below presents a situation where oneuser is trying to check out a project file already checked out by anotheruser; the tool's locking mechanismprevents this operation by disabling the check out function. However, if the“multiple checkouts” function is enabled in VSS, users are able to check outfiles that have already been checked out by another users. The users

checking in such files must themselves resolve any conflicts betweenmodifications that may occur if VSS is not able to merge the modificationsautomatically. Figure 8 presents this situation, where the users havemodified the same lines, and therefore the user who checks in later has tosolve the problem. All activities should be based on the project's SCMprocedures as defined in theSCM plan.

The advantages of concurrent development are remarkableDevelopment teams can work with the same files, while the SCM toocontrols development. According to Leon (2000), the difference betweenconcurrent and parallel development is that in concurrent developmentbranches are finally merged into a single item, whereas in paralleldevelopment merging is not performed and branches go ahead separatelyThe same alternatives can exist at the project level. For example, if there isa project that reaches the testing stage, the project can be branched so thattesting and bug fixing can be performed separately. Development continuesin the main branch, and later on the modified files on these two branchescan be merged.

Page14



SYSTEM BUILDING

In system building (a.k.a. build management), the purpose is tocombine needed file versions and then compile them to create anapplication. Building can be done for a subsystem, a module, or a wholesystem (Leon 2000) and the building strategy can be either incremental orfrom scratch. In incremental building, only files that been changed will bebuilt; correspondingly, all files will be built when building from scratchAccording to Whitgift (1991), building from scratch can be a very expensiveprocess in terms of machine resources, because a large system may containthousands of files of source code.SCM tools can facilitate building work by capturing necessary informationand making the building process repeatable. To be repeatable, details ofused components, components' versions, the operating system and itsversion, compiler and linker options etc., are required (Leon 2000). An SCMtool usually includes a Make tool to generate an executable software systemreliably and efficiently (Conradi & Westfechtel 1998).

PROCESS CONTROL AND SUPPORT According to Estublier (2000), process support means both the

"formal" definition of what is to be performed on what (a process model)and the mechanisms to help reality conform to the model. In practice, aState Transition Diagram (STD) and activity-centred modelling are offeredas a solution. As an example Estublier (2000) states that change control istraditionally an integral part of SCM tools.

Page15



Lenses for the AnalysisThis section constructs the SCM lenses through which current

agile software development methods will be analyzed. The followinganalytical lenses were seen as relevant for addressing the researchpurposes of this publication. As has been said, software configurationmanagement is a critical element of software engineering (Feiler 1990)According to Compton & Conner (1994), it is an essential activity that musttake place whenever developing software. SCM is needed because of

increased complexity of software systems, increased demand for softwareand the changing nature of software (Leon 2000). Again, according to Leon(2000), proper application of SCM is a key component in the development ofquality software. This perspective explores how the method in questionaddresses SCM. For example, the method may have SCM as a keypractice; then its viewpoint towards SCM can be seen as explicit. Therefore,this perspective also explores the various methods' SCM-relatedpractices.According to Abran & Moore (2001), a successful SCMimplementation requires careful planning. SCM planning is the basis for

project's SCM implementation precisely recording in an SCM plan who isgoing to do what, when, where, and how (Buckley 1996). This viewpointexamines what the method defines as SCM planning. According to Leon(2000), configuration identification is the basis for subsequent control of thesoftware configuration. It is "the process whereby a system is separated intouniquely identifiable components for the purpose of SCM" (Leon 2000, p91). From this perspective, what the method in questiondefines as item identification and baselining will be analyzed. As statedbefore, change is one of the most fundamental characteristics in anysoftware development process (Leon 2000). Lehman (1980) states thatchange is intrinsic in software and must be accepted as a fact of life.According to Leon (2000), making changes to software is easy, butmanaging those changes (the uncontrolled changes) is not. Howeveruncontrolled change can create problems serious enough to create projectfailures. Controlling changes while software isbeing developed has been defined as a task for SCM (e.g. IEEE 828-1990).Taramaa 1998). This viewpoint explores agile software developmentmethods from a change management perspective. In other words, what the

Page16



method in question defines as change management and how it should behandled will be examined.

The purpose of software configuration management tools is tosupport and automate SCM activities and to provide help for developers.According to Leon (2000), the role played by SCM tools is becoming moreand more important in today’s complex software development

environments. Leon (2000) also states that no SCM tool is the solution forevery software configuration management problem, but SCM tools can be astep towards more effective software configuration managementWeatherall (1997, p. 3) sums this up as follows: "SCM is first an attitude;second, a process; and only third, a set of tools."However, softwareconfiguration management tools are important part of a comprehensivesoftware configuration management solution and, therefore, they can beseen as relevant to the evaluation of agile software development methodsfrom the SCM point of view. This dimension explores what the role of SCM

tools is in a particular agile method.

Page17



Maintenance systems

Configuration management is used to maintain an understanding of

the status of complex assets with a view to maintaining the highest level of

serviceability for the lowest cost. Specifically, it aims to ensure thatoperations are not disrupted due to the asset (or parts of the asset)

overrunning limits of planned lifespan or below quality levels.

In the military, this type of activity is often classed as "mission readiness",

and seeks to define which assets are available and for which type of

mission; a classic example is whether aircraft on-board an aircraft carrier

are equipped with bombs for ground support or missiles for defense.

A theory of configuration maintenance was worked out by Mark

Burgess, with a practical implementation on present day computer systemsin the software Cfengine able to perform real time repair as well as

preventive maintenance.

PREVENTIVE MAINTENANCE

Understanding the "as is" state of an asset and its major components

is an essential element in preventive maintenance as used in maintenance,

repair, and overhaul and enterprise asset management systems.

Complex assets such as aircraft, ships, industrial machinery etc. depend on

many different components being serviceable. This serviceability is often

defined in terms of the amount of usage the component has had since it

was new, since fitted, since repaired, the amount of use it has had over its

life and several other limiting factors. Understanding how near the end of

their life each of these components is has been a major undertaking

Page18

http://en.wikipedia.org/wiki/Cfengine

http://en.wikipedia.org/wiki/Cfengine



involving labor intensive record keeping until recent developments in

software.

PREDICTIVE MAINTENANCE

Many types of component use electronic sensors to capture data whichprovides live condition monitoring. This data is analyzed on board or at a

remote location by computer to evaluate its current serviceability and

increasingly its likely future state using algorithms which predict potentia

future failures based on previous examples of failure through field

experience and modeling. This is the basis for "predictive maintenance".

Availability of accurate and timely data is essential in order for CM to

provide operational value and a lack of this can often be a limiting factor.

Capturing and disseminating the operating data to the various supportorganizations is becoming an industry in itself.

The consumers of this data have grown more numerous and complex with

the growth of programs offered by original equipment manufacturers

(OEMs). These are designed to offer operators guaranteed availability and

make the picture more complex with the operator managing the asset but

the OEM taking on the liability to ensure its serviceability. In such a

situation, individual components within an asset may communicate directly

to an analysis center provided by the OEM or an independent analyst.

Standards

ANSI/EIA-649-1998 National Consensus Standard for Configuration

Management

EIA-649-A 2004 National Consensus Standard for Configuration

Management

ISO 10007:2003 Quality management systems - Guidelines for

configuration management

Federal Standard 1037C

GEIA Standard 836-2002 Configuration Management Data Exchange

and Interoperability

IEEE Std. 828-1998 IEEE Standard for Software Configuration

Management Plans

Page19



MIL-STD-973 Configuration Management (cancelled on September 20,

2000)

STANAG 4159 NATO Materiel Configuration Management Policy and

Procedures for Multinational Joint Projects

STANAG 4427 Introduction of Allied Configuration Management

Publications (ACMPs) CMMI CMMI for Development, Version 1.2 CONFIGURATION

MANAGEMENT

CMII - The Path to Integrated Process Excellence.

Conclusion:

As you can see from the points made above, there are many benefits

to configuration management in addition to simply avoiding chaos. The

degree to which you implement it in your environment is up to you and

determined by the size, scope, and requirements of the software for which

your team is responsible.

In software engineering, software configuration management (SCM) is

the task of tracking and controlling changes in the software. Configuration

management practices include revision control and the establishment

of baselines.

SCM concerns itself with answering the question "Somebody didsomething, how can one reproduce it?" Often the problem involves not

reproducing "it" identically, but with controlled, incremental changes.

Answering the question thus becomes a matter of comparing different

results and of analyzing their differences. Traditional configuration

management typically focused on controlled creation of relatively simple

products. Now, implementers of SCM face the challenge of dealing with

Page20



relatively minor increments under their own control, in the context of the

complex system being developed.

This study yielded results indicating a benefit to using configuration

management on projects of this nature.

Guidelines IEEE Std. 1042-1987 IEEE Guide to Software Configuration

Management

MIL-HDBK-61A CONFIGURATION MANAGEMENT GUIDANCE 7 February

2001

10007 Quality management - Guidelines for configuration

management

GEIA-HB-649 - Implementation Guide for Configuration Management

ANSI/EIA-649-1998 National Consensus Standard for Configuration

Management

EIA-836 Consensus Standard for Configuration Management Data

Exchange and Interoperability

ANSI/EIA-632-1998 Processes for Engineering a System

Page21

scm-software configuration management

Documents