software configuration management - moodle

1

Software Configuration Management

Fernando Brito e Abreu ([email protected])Universidade Nova de Lisboa (http://www.unl.pt)QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

Software Engineering / Fernando Brito e Abreu 217-May-05

SWEBOK: the 10 Knowledge AreasSoftware RequirementsSoftware DesignSoftware ConstructionSoftware TestingSoftware MaintenanceSoftware Configuration ManagementSoftware Engineering ManagementSoftware Engineering ProcessSoftware Engineering Tools and MethodsSoftware Quality

2


SummaryDeliverables and Their DependenciesWhat is Configuration Management ?Identification OrganizationModificationIEEE C.M. Model

What Must A C.M. Plan Include?C.M. In Project ControlC.M. Tools


Software DeliverablesExamples

requirements specificationdesign modelsource code moduletest batteryuser manualexecutable program...

Called “configuration items” in this context

3


defA.inc defB.inc defBibS.inc defBibD.inc bibliotecaD.src moduloA.src principal.src moduloB.src bibliotecaS.src moduloA.obj moduloB.obj principal.obj bibliotecaS.obj bibliotecaD.obj. bibliotecaS.slib bibliotecaD.dlib executavel.exe

Deliverable Dependencies

Deliverables are not independent from each other; Dependencies are known but seldom enforced!


What Is Configuration Management?Set of mechanisms and activities that allows software deliverables to be:

identified (know which is which)organized (know their interdependencies)modified under control (who, why, when)

Must be a part of the development processalong all phases of the life-cycle

4


CM along the lifecycle (in RUP)

Configuration Mgmt

Management

Environment

Business Modeling

Requirements

Analysis and Design

Implementation

Test

Deployment

Preliminary Iteration(s)

Iter.#1

Process Disciplines

Supporting Disciplines

Iter.#2

Iter.#n

Iter.#n+1

Iter.#n+2

Iter.#m

Iter.#m+1

Elaboration TransitionInception Construction


Identification: Naming and Versions

Unique identifiers must be assigned to:Each deliverableEach baselineEach version (either of deliverables or baselines)

a deliverable id can be composed of name + version number

There must be an explicit convention for versions and deliverables identifiers.

5


Organization:Baselines

Baseline - set of deliverables that define a particular version of a system or subsystemA baseline is often called a configurationThe minimum number of deliverables in a baseline are those needed to allow:

independent reusecorrective and evolutive maintenance


Organization:Branches

Are used when a product is to be deployed in multiple target platformsRequire diachronic traceability mechanisms :

storage and manipulation of “deltas”forward and backward reversing facilities

GreekGreek::•• diadia -- throughthrough•• kronoskronos -- timetime

6


Other examples of CM tools


Modification:Check-in

First version of deliverables is built in the “sandbox”Kids, Soldiers or Cats?

Check-in allows deliverables to be put under CMUsually requires information on:

Who is doing / who authorized the check-inWho validated / verified the deliverableWhich is the updated version of the related deliverablesWhen the check-in event took place

7



Modification:Check-out

Check-out puts copies of deliverables in the sandbox (they are supposed to be checked-in again ...)Usually requires information on:

Who did the check-outWho authorized the check-outWhy is the check-out requiredWho will be in charge of the deliverableWhen the check-out event took place

“Read-only” check-out should be free from the previous constraints!

8


Modification: Check-out (continued)Checking-out an already checked-out deliverable

optimistic strategy: probability of this occurrence is small, so the deliverable is locked upon the first request

the second partner must wait until the lock is released (when the first checks-in the required deliverable)this strategy is rigid but simple

pessimistic strategy: probability of this occurrence is not neglectable, so we must allow it

merging conflicts must be solved laterflexible but more complex

in both cases, partners should be notified: email is often used to do that when a partner is not logged on


Modification:Conflict resolution

When two or more instances of the same deliverable are checked-out, a merging mechanism is required upon next check-in:

Differences must be identified and conciliatedMost differences can be merged automatically (no conflicts)Some conflicts request human intervention

The same happens when we want to collapse two, or more, branches

9


Modification:Authorization

Responsible must have experience and authority!

Modifications are only authorized with appropriate fundament, usually through an appropriate form -request for modifications or improvements (RFI).

These forms should be distributed to final users

Users should be notified of the request follow-up (acceptation, postponement, refusal)

An Intranet can be used to submit requests [Monteiro99]

CM responsible should only allow a definitive change to a baseline if all interrelated deliverables are adequately modified (synchronic traceability enforcement)


Modification:Request for Improvements Checklist

Which is the effort and cost required?How complex is the change and what is the technological risk?Are the components to be changed highly coupled with others?What is likely to happen if the changes is not implemented properly or not implemented at all?What is the relative importance of this change when compared with other pending requests?Who will make the change?

10


IEEE C.M. Library ModelDeliverables, while being developed and modified frequently, are kept in the Dynamic Library (“sandbox”)Deliverables are "promoted" to the Controlled Library, when they are ready for V&V actions and integrationOperational components or full-system versions to installin the final client are "freezed" (in the Static Library)

Dynamic library(sandbox)

Controlledlibrary

Staticlibrary

Check-in

Check-out

ClientInstallation

Freezingactions

V&VactionsDeliverable

modification

•• ANSI/IEEE Standard 1042ANSI/IEEE Standard 1042


What Must a CM Plan / System Include?Tasks definition and responsibilities

Selected tools, techniques and methodologies Synchronic traceability mechanisms

dependenciesexecutables automatic generation

Diachronic traceability mechanismsbranchesdeltas

11


What Must a CM Plan / System Include?Register and storage procedures (“check-in” and “check-out”)Modification and distribution procedures of deliverables (who authorizes, when and how?)Updating strategy of catalogs of deliverablesStandards for documentation (to enforce reuse)Procedures for security copiesProcedures for delivery generation


The Support of CM in Project ControlPutting modules under a configuration management mechanism, managed by staff members distinct from developers enables project management control!Examples:

the percentage of modules, specified in detailed design, which were finished is easily verifiable, therefore avoiding the “90% syndrome” by allowing an evaluation of the real completion compared to the previewed one;defects and failures in modules are registered because module modification implies their check-in in configuration management, which usually must be justified.

12


Concluding Remarks ...During all project life-cycle we need to keep an updated library with all deliverables produced

CM guarantees their integrity and consistency

It must be possible to trace all change requests back to requirements

CM is often seen by team members as a monotonous task that restricts individual freedom!

A strong commitment (not just involvement) is needed by upper management to guarantee its adequate adoption


Without Configuration Management...

... we loose the synchronic anddiachronic traceability

13


CM ToolsTools can and must be used for automation of most CM workThere are many CM tools availableThe most complex (and expensive) CM tools allow large development teams, distributed over several sites


CM Tools: Characteristics (1) Interface Type: textual, menus or GUI?

Configuration items supported: source code (always) and all other types of deliverables (requirements specifications, analysis and design documents, manuals, test plans, etc ?

Repository: normal file system, relational or OO database?

For integration purposes, the “openness” of the repository is a must!

14


Tools: Characteristics (2) Configuration Control: association of deliverables in aggregates (baseline), that can (or cannot) be frozen and to which a version identifier is given?

Access Control: mutual exclusion in the access of configuration items?

This problem occurs when, for instance, two programmers want to simultaneously modify the same configuration item;

some tools send a notification (mail) to the user who tries to access an item under use by somebody else;

new breakthroughs are envisaged due to recent results of cooperative work research.


Tools: Characteristics (3) Generation Control: automation of executables generation process based on dependencies and triggering actions between configuration items?

Support for evolution?Identification of modifications ("deltas") on a given item;

ability to revert modifications (reverse diachronic traceability).

Support for distribution: allow configuration items to be spread in several machines in a network?

Support for integration: with tools as editors, code analyzers, analysis and design tools, test tools, etc?

15


C.M. Tools Web LinksMKS SourceIntegrity (http://www.mks.com/products/scm/sipro/)PVCS Version Manager (http://www.hallogram.com/intersolv-pvcs/manager/index.html)Microsoft SourceSafe (http://www.ralgi.com/products/vss/sourcesafe.html )JavaSafe (http://www.javasoft.com/marketing/collateral/java_safe_ds.html )Sablime (http://www.bell-labs.com/project/sablime/index.html )CCC/Harvest (http://www.platinum.com/products/appdev/cccharps.htm )Continuus/CM ( http://www.cwi.com/products/productsBB.html )SCM (http://www.unipress.com/cat/scm.html )

More info: http://www.loria.fr/~molli/cm-index.html


16



17



18


Other examples of CM toolsPVCS (Polytron Version Control System)

ESE System (Evolution Support Environment System),

SySL

EPOS CASE

SODOS System

PACT

SCCS - Source Code Control System (AT&T)UNIX standardMainly code targetedtextual interface


Examples of ToolsRCS - Revision Control System (GNU)

freely available from GNU for UNIX environmentsimprovement over SCCSstill textual interfacesupports any kind of text files (source code, manuals, test data)

CVS - Concurrent Version System (GNU)also produced by GNUextends RCS by allowing concurrent file manipulation

19


Examples of ToolsCMS/AIT - Configuration Management System / Action Item Tracking

Produced by CIMware Technologies Inc. (USA)Uses an Oracle repository

CMS - Configuration Management SystemProduced by Workgroup Technologies (USA)Uses a modified version of RCS


Examples of ToolsSMS

Produced by Intasoft Inc. (UK)Source code control facilities using a preprocessorMenu interfaceAvailable for PCs, UNIX and VAX/VMS.

ADC / Aide-de-ChampProduced by SMDS / Software Maintenance & Development Systems Inc (USA)Configuration items and their interrelations are stored in a database supporting the Entity-Relationship model.

20


Examples of Tools

SABLIME Project Administration SystemProduced at AT&T Bell LaboratoriesAllows code and documentation management.Information about requests for modifications, their rationale and actions for their implementation can be stored in association with target files.Allows to generate reports and historical metrics about modifications.


Examples of ToolsCCC/Manager

Produced by Softool Corporation (USA)Available for DEC, IBM, Sun, HP, Harris and PCs.

CMF - Configuration Management FacilityProduced by Expertware (USA)

TEAMNETProduced by TeamOne Systems Inc. (USA)Has a fusion mechanism that allows conflict resolutionAllows to freeze versionsTextual and menu interfaces

21


Examples of Tools in EnvironmentsAMPLIFY CONTROL

Produced by CaseWare Inc ( http://www.cwi.com) Graphical interfaces for Motif, Sunview and OpenviewObject-oriented repository with SQL query facilities

CMZProduced in CERN (http://www.cern.ch)Suports development in C and FortranLibrary management is integrated with code edition and testAvailable for Apollo, IBM VM/CMS, IBM MVS, IBM RS/6000, VAX/VMS, Ultrix, Gould UTX, Cray Unicos, Sun, SGI, HP/UX, etc


Examples of Tools in EnvironmentsDSEE - DOMAIN Software Engineering Environment

originally developed for Apollo workstations (now HP)distributed software development supportallows concurrent operation and different target generation

VAXSETenvironment for Digital’s VMSCMS - Code Management System - code libraries and configuration controlMMS - Module Management System - similar with UNIX makeIntegrated with other modules (eg: Language Sensitive Editor, Source Code Analyzer, Test Manager)PCA - Performance and Coverage Analyzer

22


Bibliography[Bab86] W.A. Babich, Software Configuration

Management, Coordination for Team Productivity, Addison-Wesley, 1986.

[Ber92] H.R. Berlack, Software Configuration Management, John Wiley & Sons, 1992.

[Buc96] F.J. Buckley, Implementing Configuration Management: Hardware, Software, and Firmware, second ed., IEEE Computer Society Press, 1996.

[Con98] R. Conradi and B. Westfechtel, “Version Models for Software Configuration Management,”ACM Computing Surveys, vol. 30, iss. 2, June 1998.

[Dar90] S.A. Dart, Spectrum of Functionality in Configuration Management Systems, Software Engineering Institute, Carnegie Mellon University, 1990.

[IEEE828-98] IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans, IEEE, 1998.

[IEEE12207.0-96] IEEE/EIA 12207.0-1996//ISO/IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology - Software Life Cycle Processes, IEEE, 1996.

[Mid97] A.K. Midha, “Software Configuration Management for the 21st Century,” Bell Labs Technical Journal, vol. 2, iss. 1, Winter 1997, pp. 154-165.

[Moo98] J.W. Moore, Software Engineering Standards: A User’s Roadmap, IEEE Computer Society, 1998.

[Pau93] M.C. Paulk et al., “Key Practices of the Capability Maturity Model, Version 1.1,” technical report CMU/SEI-93-TR-025, Software Engineering Institute, Carnegie Mellon University, 1993.

[Pre04] R.S. Pressman, Software Engineering: A Practitioner’s Approach, Sixth ed, McGraw-Hill, 2004.

[Roy98] W. Royce, Software Project Management, A United Framework, Addison-Wesley, 1998.

[Som05] I. Sommerville, Software Engineering, seventh ed., Addison-Wesley, 2005.


Related standards(IEEE730-02) IEEE Std 730-2002, IEEE

Standard for Software Quality Assurance Plans, IEEE, 2002.

(IEEE828-98) IEEE Std 828-1998, IEEE Standard for Software Configuration Management Plans, IEEE, 1998.

(IEEE1028-97) IEEE Std 1028-1997 (R2002), IEEE Standard for Software Reviews, IEEE, 1997.

(IEEE12207.0-96) IEEE/EIA 12207.0-1996//ISO/ IEC12207:1995, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology - Software Life Cycle Processes, IEEE, 1996.

(IEEE12207.1-96) IEEE/EIA 12207.1-1996, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes - Life Cycle Data, IEEE, 1996.

(IEEE12207.2-97) IEEE/EIA 12207.2-1997, Industry Implementation of Int. Std. ISO/IEC 12207:95, Standard for Information Technology-Software Life Cycle Processes - Implementation Considerations, IEEE, 1997.

(ISO15846-98) ISO/IEC TR 15846:1998, Information Technology - Software Life Cycle Processes -Configuration Management, ISO and IEC, 1998.

software configuration management - moodle

Documents