Configuration management l Managing the products code and

Configuration management l Managing the products (code and documentation) of system as it changes ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 1

Configuration management l New versions of software systems are created • • l Enhancements / Fixes Different stages of development For different machines/OS Less likely, tailored for particular user requirements, offering different functionality Configuration management is concerned with managing evolving software systems ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 4

Configuration management l l l Involves the development and application of procedures and standards to manage an evolving software product 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 2000 Software Engineering, 6 th edition. Chapter 29 Slide 5

System families ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 6

Daily system building l l It is easier to find problems that stem from component interactions early in the process Encourages thorough unit testing - developers are under pressure not to ‘break the build’ Successful use requires stringent change management process to keep track of problems that have been discovered and repaired Produces many versions that must be managed ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 9

29. 1 Configuration management planning l All products of the software process may have to be managed • • • l Specifications Designs Programs Test data User manuals Thousands of separate documents are generated for a large software system ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 10

CM planning l l l Starts during the early phases of the project Must define the documents or document classes which are to be managed Documents which might be required for future system maintenance should be identified and specified as managed documents ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 11

The CM plan l l l Types of documents to be managed Who takes responsibility for CM Policies for change control and version management CM records which must be maintained … ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 12

Configuration hierarchy ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 15

29. 2 Change management l Software systems are subject to continual change requests • • • l l From users From developers From market forces Change management is concerned with keeping track of these change requests and ensuring that they are implemented in the most cost-effective way Change management starts when materials put into configuration management ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 18

The change management process ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 19

Example Change request form Change Request Form Project: Proteus/PCL-Tools Number: 23/94 Change requester: I. Sommerville Date: 1/12/98 Requested change: When a component is selected from the structure, display the name of the file where it is stored. Change analyser: G. Dean Analysis date: 10/12/98 Components affected: Display-Icon. Select, Display-Icon. Display Associated components: File. Table Change assessment: Relatively simple to implement as a file name table is available. Requires the design and implementation of a display field. No changes to associated components are required. Change priority: Low Change implementation: Estimated effort: 0. 5 days Date to CCB: 15/12/98 CCB decision date: 1/2/99 CCB decision: Accept change. Change to be implemented in Release 2. 1. Change implementor: Date of change: QA decision Date submi tted to QA: Date submitted to CM: Commen ts ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 21

Change tracking tools l l A major problem in change management is tracking change status Change tracking tools keep track the status of each change request and automatically ensure that change requests are sent to the right people at the right time. Integrated with E-mail systems allowing electronic change request distribution May be integrated with Configuration Management DB ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 23

Change control board l l l Decide based on a cost, strategic and organizational viewpoint Should be independent of project team Representatives from client and contractor staff ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 24

Derivation history l l Record of changes applied to a document or code component Should record, in outline, the change made, the rationale for the change, who made the change and when it was implemented Impact in tracked item should be marked May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 25

Component header information ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 26

29. 3 Version and release management l l Invent identification scheme for system versions Plan when new system version is to be produced Ensure that version management procedures and tools are properly applied Plan and distribute new system releases ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 27

Version identification l l Procedures for version identification should define an unambiguous way of identifying component versions Three basic techniques for component identification • • • Version numbering Attribute-based identification Change-oriented identification ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 29

Version numbering l l Simple naming scheme uses a linear derivation e. g. V 1, V 1. 2, V 2. 1, V 2. 2 etc. However, actual derivation structure may be a tree or a network rather than a sequence Names are not meaningful. Hierarchical naming scheme may be better ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 30

Version derivation structure ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 31

Attribute-based identification l l l Attributes can be associated with a version with the combination of attributes identifying that version Examples of attributes are Date, Creator, Programming Language, Customer, Status etc. More flexible than an explicit naming scheme for version retrieval; Supports queries when looking for versions Can cause problems with uniqueness Awkward - needs an associated name for easy reference ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 32

System releases l l Not just a set of executable programs May also include • • • l Configuration files defining how the release is configured for a particular installation Data files needed for system operation An installation program or shell script to install the system on target hardware Electronic and paper documentation Packaging and associated publicity Systems are now normally released on CD-ROM or as downloadable installation files from the web ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 36

Release problems • Release management must not assume that all previous releases have been accepted. ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 37

Release decision making l l l Must plan when to distribute a system release Preparing and distributing a release is expensive Factors: • • • technical quality competition, marketing requirements customer change requests ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 38

Release creation l l l Collect all files and documentation Configuration descriptions / instructions/ scripts Documented to allow re-creation ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 40

29. 4 System building l l l The process of compiling and linking software components into an executable system Different systems are built from different combinations of components Invariably supported by automated tools that are driven by ‘build scripts’ ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 41

System building ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 42

System building problems l l l Do the build instructions include all required components? Is the appropriate component version specified? Are all data files available? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 43

System building problems l l l Are data file references within components correct? Is the system being built for the right platform Is the right version of the compiler and other software tools specified? ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 44

29. 5 CASE tools for configuration management l l CM processes are standardized 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 standalone tools to integrated CM workbenches ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 46

Change management tools l l Change management is a procedural process so it can be modelled and integrated with a version management system Change management tools • • • Form editor Workflow system Change database, with query facilities ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 47

Version management tools l l Version and release identification Storage management. Change history recording Independent development ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 48

Delta-based versioning ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 49

e. g. Microsoft Visual Source Safe l l Part of Visual Studio Handles Sharing of Files in a project • • l Handles Multiple Versions • • l Check out for making changes Check back in after changes Saves latest Saves “Backward Deltas” Mostly makes sense with network common area available to whole team ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 50

Microsoft Visual Source Safe l l l VSS keeps a database Inside DB there are Projects include files Users have working folder for when they are working on something Shadow Folder – common, read only versions of current code ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 51

Microsoft Visual Source Safe l l l l Check out file – copied to your working folder While checked out, other check-outs are stopped Check back in makes file available to others If not changing file, can Get / View the file (read only) Can cancel checkout if decide not to change file VSS can show differences between versions of a file VSS keeps track of versions using numbers, by date, AND by user-defined labels (names) Can try to merge different versions of a file ©Ian Sommerville 2000 Software Engineering, 6 th edition. Chapter 29 Slide 52