Software Configuration Management Copyright, 2006 © L.Ouyang Liubo Ouyang Personal Software Process Lecture 10

L.Ouyang, PSP, Lecture 10 Introduction Configuration management is the art of identifying, organising and controlling modifications to the software being built by a programming team -- W.A. Babich’86

L.Ouyang, PSP, Lecture 10 Introduction SCM activities: identifying the changeidentifying the change controlling the changecontrolling the change ensuring that the change is being properly implementedensuring that the change is being properly implemented reporting the change to other interested partiesreporting the change to other interested parties

L.Ouyang, PSP, Lecture 10 Introduction Software maintenance vs. SCM Maintenance: a set of activities that occur after delivery SCM: begins when a software project begins and lasts till the software is taken out of operation

L.Ouyang, PSP, Lecture 10 Software configuration Software artefacts: programs (source and executable)programs (source and executable) documents (requirements specification, project plan, user manual,..)documents (requirements specification, project plan, user manual,..) data (test data)data (test data) The main problem: CHANGE SCM as an SQA activity

L.Ouyang, PSP, Lecture 10 Baseline A specification or product that has been formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedure -- IEEE Std

L.Ouyang, PSP, Lecture 10 Baseline The most common software baselines: System specificationSystem specification Software requirements specificationSoftware requirements specification Design specificationDesign specification Source codeSource code Test plans/Procedures/DataTest plans/Procedures/Data Operational systemOperational system

L.Ouyang, PSP, Lecture 10 Software configuration items (1) System specification Software project plan Software requirements specification Preliminary user manual Design specification Source code listing Test specification

L.Ouyang, PSP, Lecture 10 Software configuration items (2) Operation and installation manuals Executable program Database description As-built user manual Maintenance documents Standards and procedures for SE Software tools

L.Ouyang, PSP, Lecture 10 Identification Each SCI is treated like an object Types of objects: basic and aggregate ones A basic object: a unit of text (e.g. a section of requirements, a listing for a module, a suite of test cases) An aggregate object: a collection of basic and aggregate objects

L.Ouyang, PSP, Lecture 10 Identification Each object has: A nameA name A description: the SCI type (program, document, data), a project identifier, change and/or version informationA description: the SCI type (program, document, data), a project identifier, change and/or version information Resources: entities that are provided, processed or referenced by the object (e.g. data types, functions etc.)Resources: entities that are provided, processed or referenced by the object (e.g. data types, functions etc.) A realisation: a pointer to the “unit of text”A realisation: a pointer to the “unit of text”

L.Ouyang, PSP, Lecture 10 Identification An object an aggregate object Example: Type_expressions Type_checker Symbol_table Type_checker Type_checker Static_analyser

L.Ouyang, PSP, Lecture 10 Identification Obj1.0 Obj1.1Obj1.2 Obj1.3Obj1.4 Obj2.0Obj2.1 Obj1.1.1Obj1.1.2 Evolution graph A complete version of the software

L.Ouyang, PSP, Lecture 10 Version control SCM allows.. to specify alternative configurations.. through the selection of appropriate versions. This is supported by associating attributes with each software version, and then allowing a configuration to be specified by describing the set of desired attributes. -- G.M. Clemm’89

L.Ouyang, PSP, Lecture 10 Version control The attributes of software version can be: a version number,a version number, a string of boolean variables (switches) that describe functional changes made to the systema string of boolean variables (switches) that describe functional changes made to the system

L.Ouyang, PSP, Lecture 10 Versions and component variants The need for variants: Software localisationSoftware localisation Performance trade-offPerformance trade-off Explicit version construction: numbers (SCCS) Implicit version construction: tags in CVS; HRT systems: selection of variants can be based on non-functional requirements

L.Ouyang, PSP, Lecture 10 CVS cvs -d :local:c:\src\cvsroot init mkdir election mkdir election/require mkdir election/concept cd election cvs import -m “Created directory struc” elect artur start Start

L.Ouyang, PSP, Lecture 10 CVS cvs checkout CVSROOT/modules cd CVSROOT edit the ‘modules’ file CVSROOT CVSROOT CVSROOT CVSROOT modules CVSROOT/modules modules CVSROOT/modules cvs gnu/cvs cvs gnu/cvs rcs gnu/rcs rcs gnu/rcs require elect/require require elect/require Defining modules

L.Ouyang, PSP, Lecture 10 CVS cvs commit -m “Added the require module” modules cd.. cvs release -d CVSROOT # release the ‘modules’ Defining modules

L.Ouyang, PSP, Lecture 10 CVS cvs tag srs-1-0. #assigning a tag cvs checkout -r srs-1-0 require #getting a revision cvs rtag -b -r old-rel new-rel require #create a branch Other operations

L.Ouyang, PSP, Lecture 10 Homework Get familiar with the CVS system: start to use it on your project.

L.Ouyang, PSP, Lecture 10 Summary Software configuration Baseline Revisions and branches Version control CVS

L.Ouyang, PSP, Lecture 10 Further readings cvs_toc.html

L.Ouyang, PSP, Lecture 10 Quality assessment 1. What is your general impression ? 2. Was it too slow or too fast ? 3. Did you learn something important to you ? 4. What to improve and how ?