Software Configuration Management Fernando Brito e Abreu - - PDF document

1

Software Configuration Management

Fernando Brito e Abreu (fba@di.fct.unl.pt) Universidade Nova de Lisboa (http://www.unl.pt)

QUASAR Research Group (http://ctp.di.fct.unl.pt/QUASAR)

Software Engineering / Fernando Brito e Abreu 2 17-May-05

SWEBOK: the 10 Knowledge Areas

Software Requirements Software Design Software Construction Software Testing Software Maintenance Software Configuration Management Software Engineering Management Software Engineering Process Software Engineering Tools and Methods Software Quality

2

Software Engineering / Fernando Brito e Abreu 3 17-May-05

Summary

• Deliverables and Their Dependencies
• What is Configuration Management ?
• Identification
• Organization
• Modification
• IEEE C.M. Model
• What Must A C.M. Plan Include?
• C.M. In Project Control
• C.M. Tools

Software Engineering / Fernando Brito e Abreu 4 17-May-05

Software Deliverables

Examples

requirements specification design model source code module test battery user manual executable program ...

Called “configuration items” in this context

3

Software Engineering / Fernando Brito e Abreu 5 17-May-05

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!

Software Engineering / Fernando Brito e Abreu 6 17-May-05

What Is Configuration Management?

Set of mechanisms and activities that allows

software deliverables to be:

identified (know which is which)

• rganized (know their interdependencies)

modified under control (who, why, when)

Must be a part of the development process

along all phases of the life-cycle

4

Software Engineering / Fernando Brito e Abreu 7 17-May-05

CM along the lifecycle (in RUP)

Configuration Mgmt Management Environment Business Modeling Requirements Analysis and Design I mplementation 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 Transition Inception Construction Software Engineering / Fernando Brito e Abreu 8 17-May-05

Identification:

Naming and Versions

Unique identifiers must be assigned to:

Each deliverable Each baseline Each 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

Software Engineering / Fernando Brito e Abreu 9 17-May-05

Organization:

Baselines

Baseline - set of deliverables that define a

particular version of a system or subsystem

A baseline is often called a configuration The minimum number of deliverables in a

baseline are those needed to allow:

independent reuse corrective and evolutive maintenance

Software Engineering / Fernando Brito e Abreu 10 17-May-05

Organization:

Branches

Are used when a product is to be deployed in multiple

target platforms

Require diachronic traceability mechanisms :

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

Greek Greek: :

• dia

dia -

• through

through

• kronos

kronos -

• time

time

6

Software Engineering / Fernando Brito e Abreu 11 17-May-05

Other examples of CM tools

Software Engineering / Fernando Brito e Abreu 12 17-May-05

Modification:

Check-in

First version of deliverables is built in the “sandbox”

Kids, Soldiers or Cats?

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

Who is doing / who authorized the check-in Who validated / verified the deliverable Which is the updated version of the related deliverables When the check-in event took place

7

Software Engineering / Fernando Brito e Abreu 13 17-May-05 Software Engineering / Fernando Brito e Abreu 14 17-May-05

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-out Who authorized the check-out Why is the check-out required Who will be in charge of the deliverable When the check-out event took place

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

constraints!

8

Software Engineering / Fernando Brito e Abreu 15 17-May-05

Modification: Check-out (continued)

Checking-out an already checked-out deliverable

• ptimistic 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 later flexible but more complex

in both cases, partners should be notified: email is often

used to do that when a partner is not logged on

Software Engineering / Fernando Brito e Abreu 16 17-May-05

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 conciliated Most 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

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

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)

Software Engineering / Fernando Brito e Abreu 18 17-May-05

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

Software Engineering / Fernando Brito e Abreu 19 17-May-05

IEEE C.M. Library Model

Deliverables, 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 integration

Operational components or full-system versions to install

in the final client are "freezed" (in the Static Library)

Dynamic library (sandbox) Controlled library Static library

Check-in Check-out Client Installation Freezing actions V&V actions

D e l i v e r a b l e m

• d

i f i c a t i

• n
• ANSI/IEEE Standard 1042

ANSI/IEEE Standard 1042

Software Engineering / Fernando Brito e Abreu 20 17-May-05

What Must a CM Plan / System Include?

Tasks definition and responsibilities Selected tools, techniques and methodologies Synchronic traceability mechanisms

dependencies executables automatic generation

Diachronic traceability mechanisms

branches deltas

11

Software Engineering / Fernando Brito e Abreu 21 17-May-05

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 deliverables Standards for documentation (to enforce reuse) Procedures for security copies Procedures for delivery generation

Software Engineering / Fernando Brito e Abreu 22 17-May-05

The Support of CM in Project Control

Putting 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

Software Engineering / Fernando Brito e Abreu 23 17-May-05

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

Software Engineering / Fernando Brito e Abreu 24 17-May-05

Without Configuration Management...

... we loose the synchronic and diachronic traceability

13

Software Engineering / Fernando Brito e Abreu 25 17-May-05

CM Tools

Tools can and must be used for automation of

most CM work

There are many CM tools available The most complex (and expensive) CM tools

allow large development teams, distributed over several sites

Software Engineering / Fernando Brito e Abreu 26 17-May-05

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

Software Engineering / Fernando Brito e Abreu 27 17-May-05

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.

Software Engineering / Fernando Brito e Abreu 28 17-May-05

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

Software Engineering / Fernando Brito e Abreu 29 17-May-05

C.M. Tools Web Links

MKS 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

Software Engineering / Fernando Brito e Abreu 30 17-May-05

16

Software Engineering / Fernando Brito e Abreu 31 17-May-05 Software Engineering / Fernando Brito e Abreu 32 17-May-05

17

Software Engineering / Fernando Brito e Abreu 33 17-May-05 Software Engineering / Fernando Brito e Abreu 34 17-May-05

18

Software Engineering / Fernando Brito e Abreu 35 17-May-05

Other examples of CM tools

PVCS (Polytron Version Control System) ESE System (Evolution Support Environment System), SySL EPOS CASE SODOS System PACT SCCS - Source Code Control System (AT&T) UNIX standard Mainly code targeted textual interface

Software Engineering / Fernando Brito e Abreu 36 17-May-05

Examples of Tools

RCS - Revision Control System (GNU) freely available from GNU for UNIX environments improvement over SCCS still textual interface supports any kind of text files (source code, manuals, test data) CVS - Concurrent Version System (GNU) also produced by GNU extends RCS by allowing concurrent file manipulation

19

Software Engineering / Fernando Brito e Abreu 37 17-May-05

Examples of Tools

CMS/AIT - Configuration Management System / Action Item

Tracking

Produced by CIMware Technologies Inc. (USA) Uses an Oracle repository CMS - Configuration Management System Produced by Workgroup Technologies (USA) Uses a modified version of RCS

Software Engineering / Fernando Brito e Abreu 38 17-May-05

Examples of Tools

SMS Produced by Intasoft Inc. (UK) Source code control facilities using a preprocessor Menu interface Available for PCs, UNIX and VAX/VMS. ADC / Aide-de-Champ Produced by SMDS / Software Maintenance & Development

Systems Inc (USA)

Configuration items and their interrelations are stored in a

database supporting the Entity-Relationship model.

20

Software Engineering / Fernando Brito e Abreu 39 17-May-05

Examples of Tools

SABLIME Project Administration System Produced at AT&T Bell Laboratories Allows 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.

Software Engineering / Fernando Brito e Abreu 40 17-May-05

Examples of Tools

CCC/Manager Produced by Softool Corporation (USA) Available for DEC, IBM, Sun, HP, Harris and PCs. CMF - Configuration Management Facility Produced by Expertware (USA) TEAMNET Produced by TeamOne Systems Inc. (USA) Has a fusion mechanism that allows conflict resolution Allows to freeze versions Textual and menu interfaces

21

Software Engineering / Fernando Brito e Abreu 41 17-May-05

Examples of Tools in Environments

AMPLIFY CONTROL Produced by CaseWare Inc ( http://www.cwi.com) Graphical interfaces for Motif, Sunview and Openview Object-oriented repository with SQL query facilities CMZ Produced in CERN (http://www.cern.ch) Suports development in C and Fortran Library management is integrated with code edition and test Available for Apollo, IBM VM/CMS, IBM MVS, IBM RS/6000,

VAX/VMS, Ultrix, Gould UTX, Cray Unicos, Sun, SGI, HP/UX, etc

Software Engineering / Fernando Brito e Abreu 42 17-May-05

Examples of Tools in Environments

DSEE - DOMAIN Software Engineering Environment

• riginally developed for Apollo workstations (now HP)

distributed software development support allows concurrent operation and different target generation VAXSET environment for Digital’s VMS CMS - Code Management System - code libraries and

configuration control

MMS - Module Management System - similar with UNIX make Integrated with other modules (eg: Language Sensitive Editor,

Source Code Analyzer, Test Manager)

PCA - Performance and Coverage Analyzer

22

Software Engineering / Fernando Brito e Abreu 43 17-May-05

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.

Software Engineering / Fernando Brito e Abreu 44 17-May-05

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.