Configuration management
©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 1Configuration management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 2Objectives To explain the importance of softwareconfiguration management (CM) To describe key CM activities namely CMplanning, change management, versionmanagement and system building To discuss the use of CASE tools to supportconfiguration management processes©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 3Topics covered Configuration management planning Change management Version and release management System building CASE tools for configuration management ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 4 New versions of software systems arecreated as they change:• For different machines/OS;• Offering different functionality;• Tailored for particular user requirements. Configuration management is concernedwith managing evolving software systems:• System change is a team activity;• CM aims to control the costs and effort involvedin making changes to a system.Configuration management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 5Configuration management Involves the development and application ofprocedures and standards to manage anevolving software product. CM may be seen as part of a more generalquality management process. When released to CM, software systems aresometimes called baselines as they are astarting point for further development.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 6System familiesServerversionLinuxversionPC versionInitialsystemDesktopversionWindows XPversionHPversionSunversion ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 7CM standards CM should always be based on a set of standardswhich are applied within an organisation. Standards should define how items are identified,how changes are controlled and how new versionsare managed. Standards may be based on external CM standards(e.g. IEEE standard for CM). Some existing standards are based on a waterfallprocess model - new CM standards are needed forevolutionary development.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 8Concurrent development and testing A time (say 2pm) for delivery of systemcomponents is agreed. A new version of a system is built from thesecomponents by compiling and linking them. This new version is delivered for testingusing pre-defined tests. Faults that are discovered during testing aredocumented and returned to the systemdevelopers.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 9Frequent system building It is easier to find problems that stem fromcomponent interactions early in the process. This encourages thorough unit testing -developers are under pressure not to ‘breakthe build’. A stringent change management process isrequired to keep track of problems that havebeen discovered and repaired. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 10 All products of the software process mayhave to be managed:• Specifications;• Designs;• Programs;• Test data;• User manuals. Thousands of separate documents may begenerated for a large, complex softwaresystem.Configuration management planning©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 11 Defines the types of documents to bemanaged and a document naming scheme. Defines who takes responsibility for the CMprocedures and creation of baselines. Defines policies for change control andversion management. Defines the CM records which must bemaintained.The CM plan©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 12The CM plan Describes the tools which should be used toassist the CM process and any limitations ontheir use. Defines the process of tool use. Defines the CM database used to recordconfiguration information. May include information such as the CM ofexternal software, process auditing, etc. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 13 Large projects typically produce thousands ofdocuments which must be uniquely identified. Some of these documents must be maintained forthe lifetime of the software. Document naming scheme should be definedso that related documents have related names. A hierarchical scheme with multi-level names isprobably the most flexible approach.• PCL-TOOLS/EDIT/FORMS/DISPLAY/AST-INTERFACE/CODEConfiguration item identification©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 14Configuration hierarchyPCL-TOOLSEDITSTRUCTURESBINDFORMCOMPILE MAKE-GENHELPDISP LAY QUERYAST-INTERFACEFORM-SPECS FORM-IOCODEOBJECTS TESTS©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 15 All CM information should be maintained in aconfiguration database. This should allow queries about configurations to beanswered:• Who has a particular system version?• What platform is required for a particular version?• What versions are affected by a change to component X?• How many reported faults in version T? The CM database should preferably be linked to thesoftware being managed.The configuration database ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 16CM database implementation May be part of an integrated environment tosupport software development.• The CM database and the managed documentsare all maintained on the same system CASE tools may be integrated with this sothat there is a close relationship between theCASE tools and the CM tools. More commonly, the CM database ismaintained separately as this is cheaper andmore flexible.©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 17 Software systems are subject to continualchange requests:• From users;• From developers;• From market forces. Change management is concerned withkeeping track of these changes and ensuringthat they are implemented in the most cost-effective way.Change management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 18Request change by completing a change request formAnalyze change requestif change is validthenAssess how change might be implementedAssess change costSubmit request to change control boardif change is acceptedthenrepeatmake changes to softwaresubmit changed software for quality approvaluntil software quality is adequatecreate new system versionelsereject change requestelsereject change requestThe change management process ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 19 The definition of a change request form is part of theCM planning process. This form records the change proposed, requestor ofchange, the reason why change was suggested andthe urgency of change(from requestor of thechange). It also records change evaluation, impact analysis,change cost and recommendations (Systemmaintenance staff).Change request form©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 20Change request formChange Request FormProject: Proteus/PCL-Tools Number: 23/02Change requester: I. Sommerville Date: 1/12/02Requestedchange: Whenacomponentisselectedfromthestructure,displaythe name of the file where it is stored.Change analyser: G. Dean Analysis date: 10/12/02Components affected: Display-Icon.Select, Display-Icon.DisplayAssociated components: FileTableChange assessment: Relatively simple to implement as a file name table isavailable.Requiresthedesignandimplementationofadisplayfield.Nochangesto associated components are required.Change priority: LowChange implementation:Estimated effort: 0.5 daysDate to CCB: 15/12/02 CCB decision date: 1/2/03CCB decision: Accept change. Change to be implemented in Release 2.1.Change implementor: Date of change:Date submitted to QA: QA decision:Date submitted to CM:Comments©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 21 A major problem in change management istracking change status. Change tracking tools keep track the statusof each change request and automaticallyensure that change requests are sent to theright people at the right time. Integrated with E-mail systems allowingelectronic change request distribution.Change tracking tools ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 22 Changes should be reviewed by an external groupwho decide whether or not they are cost-effectivefrom a strategic and organizational viewpoint ratherthan a technical viewpoint. Should be independent of project responsiblefor system. The group is sometimes called a changecontrol board. The CCB may include representatives from clientand contractor staff.Change control board©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 23 This is a record of changes applied to adocument or code component. It should record, in outline, the change made,the rationale for the change, who made thechange and when it was implemented. It may be included as a comment in code. Ifa standard prologue style is used for thederivation history, tools can process thisautomatically.Derivation history©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 24Component header information// BANKSEC project (IST 6087)//// BANKSEC-TOOLS/AUTH/RBAC/USER_ROLE//// Object: currentRole// Author: N. Perwaiz// Creation date: 10th November 2002//// © Lancaster University 2002//// Modification history// Version ModifierDate Change Reason// 1.0 J. Jones 1/12/2002 Add header Submitted to CM// 1.1 N. Perwaiz 9/4/2003New field Change req. R07/02 ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 25 Invent an identification scheme for systemversions. Plan when a new system version is to beproduced. Ensure that version management proceduresand tools are properly applied. Plan and distribute new system releases.Version and release management©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 26 Version An instance of a system which isfunctionally distinct in some way from othersystem instances. Variant An instance of a system which isfunctionally identical but non-functionallydistinct from other instances of a system. Release An instance of a system which isdistributed to users outside of thedevelopment team.Versions/variants/releases©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 27Version identification Procedures for version identification shoulddefine an unambiguous way of identifyingcomponent versions. There are three basic techniques forcomponent identification• Version numbering;• Attribute-based identification;• Change-oriented identification. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 28 Simple naming scheme uses a linearderivation• V1, V1.1, V1.2, V2.1, V2.2 etc. The actual derivation structure is a tree or anetwork rather than a sequence. Names are not meaningful. A hierarchical naming scheme leads to fewererrors in version identification.Version numbering©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 29Version derivation structureV1.0 V1.1 V1.2 V2.0 V2.1 V2.2V1.1b V1.1.1V1.1a©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 30 Attributes can be associated with a version withthe combination of attributes identifying thatversion• Examples of attributes are Date, Creator,Programming Language, Customer, Status etc. This is more flexible than an explicit naming schemefor version retrieval; However, it can cause problemswith uniqueness - the set of attributes have to bechosen so that all versions can be uniquelyidentified. In practice, a version also needs an associatedname for easy reference.Attribute-based identification [...]... edition. Chapter 29 Slide 1 Configuration management ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 2 Objectives To explain the importance of software configuration management (CM) To describe key CM activities namely CM planning, change management, version management and system building To discuss the use of CASE tools to support configuration management processes ©Ian... support configuration management processes ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 3 Topics covered Configuration management planning Change management Version and release management System building CASE tools for configuration management ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 22 Changes should be reviewed by an external... integrated support for configuration management. More tightly integrated tools so easier to use. However, the cost is less flexibility in the tools used. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 45 Change management tools Change management is a procedural process so it can be modelled and integrated with a version management system. Change management tools • Form... Tailored for particular user requirements. Configuration management is concerned with managing evolving software systems: • System change is a team activity; • CM aims to control the costs and effort involved in making changes to a system. Configuration management ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 5 Configuration management Involves the development and application... Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 43 CASE tools for configuration management CM processes are standardised and involve applying pre-defined procedures. Large amounts of data must be managed. CASE tool support for CM is therefore essential. Mature CASE tools to support configuration management are available ranging from stand-alone tools to integrated CM workbenches. ©Ian... version Initial system Desktop version Windows XP version HP version Sun version ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 46 Version management tools Version and release identification • Systems assign identifiers automatically when a new version is submitted to the system. Storage management. • System stores the differences between versions rather than all the version code. Change history recording •... request forms; • Workflow system to define who does what and to automate information transfer; • Change database that manages change proposals and is linked to a VM system; • Change reporting system that generates management reports on the status of change requests. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 37 System release strategy Factor Description Technical quality of the system If... Chapter 29 Slide 5 Configuration management Involves the development and application of procedures and standards to manage an evolving software product. CM may be seen as part of a more general quality management process. When released to CM, software systems are sometimes called baselines as they are a starting point for further development. ©Ian Sommerville 2004 Software Engineering, 7th edition.... implemented. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 38 Release creation Release creation involves collecting all files and documentation required to create a system release. Configuration descriptions have to be written for different hardware and installation scripts have to be written. The specific release must be documented to record exactly what files were used to create it.... files may be involved. System building tools may provide • A dependency specification language and interpreter; • Tool selection and instantiation support; • Distributed compilation; • Derived object management. ©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 31 Attribute-based queries An important advantage of attribute-based identification is that it can support queries . supportconfiguration management processes©Ian Sommerville 2004 Software Engineering, 7th edition. Chapter 29 Slide 3Topics covered Configuration management. Configuration management planning Change management Version and release management System building CASE tools for configuration management ©Ian Sommerville 2004