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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 2 Objectives l To explain the importance of software configuration management (CM) l To describe key CM activities namely CM planning, change management, version management and system building l To discuss the use of CASE tools to support configuration management processes

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 3 Topics covered l 29.1 Configuration management planning l 29.2 Change management l 29.3 Version and release management l 29.4 System building l 29.5 CASE tools for configuration management

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 5 Configuration management l Involves the development and application of procedures and standards to manage an evolving software product l May be seen as part of a more general quality management process l When released to CM, software systems are sometimes called baselines as they are a starting point for further development

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 7 CM standards l CM should always be based on a set of standards which are applied within an organisation l Standards should define how items are identified, how changes are controlled and how new versions are managed l Standards may be based on external CM standards (e.g. IEEE standard for CM) l Existing standards are based on a waterfall process model - new standards are needed for evolutionary development

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 8 CM for evolutionary development (Concurrent development and testing) l A time for delivery of system components is agreed l A new version of a system is built from these components by compiling and linking them l This new version is delivered for testing using pre-defined tests l Faults that are discovered during testing are documented and returned to the system developers

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

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

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 13 The CM plan (continued) l Tools for CM l CM database used to record configuration information l Other …

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 14 l Large projects produce thousands of documents l Some must be maintained for the software lifetime l Document naming scheme needed l Hierarchical scheme with multi-level names Configuration item identification

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 16 l All CM information should be maintained in a configuration database l This should allow queries about configurations to be answered What customers have a particular system version? What platform is required for a particular version? How many versions have been created? What versions are affected by a change to component X? How many reported faults in version T? l The CM database should preferably be linked to the version management system for software being managed The configuration database

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 17 CM database implementation l May be part of an integrated environment to support software development. The CM database and the managed documents are all maintained on the same system l CASE tools may be integrated with this so that there is a close relationship between the CASE tools and the CM tools l More commonly, the CM database is maintained separately as this is cheaper and more flexible

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 20 l Definition of change request form is part of the CM planning process l Records change required, suggestor of change, reason why change was suggested and urgency of change(from requestor of the change) l Records change evaluation, impact analysis, change cost and recommendations (System maintenance staff) Change request form

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 21 Example Change request form mitted toQA:QA decision Date submitted to CM: Comments

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 22 Change request form

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 23 l A major problem in change management is tracking change status l 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. l Integrated with systems allowing electronic change request distribution l May be integrated with Configuration Management DB Change tracking tools

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

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

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 28 l Version An instance of a system which is functionally distinct in some way from other system instances l Variant An instance of a system which is not functionally identical but non-functionally distinct from other instances of a system l Release An instance of a system which is distributed to users outside of the development team Versions/variants/releases

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

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

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 33 Attribute-based queries l An important advantage of attribute-based identification is that it can support queries so that you can find ‘the most recent version in Java’ etc. l Example AC3D (language =Java, platform = NT4, date = Jan 1999)

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 34 Change-oriented identification l Integrates versions and the changes made to create these versions l Used for systems rather than components l Each proposed change has a change set that describes changes made to implement that change l Change sets are applied in sequence so that, in principle, a version of the system that incorporates an arbitrary set of changes may be created

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 35 l Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes l They must also incorporate new system functionality l Release planning is concerned with when to issue a system version as a release Release management

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 36 System releases l Not just a set of executable programs l May also include 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 l Systems are now normally released on CD-ROM or as downloadable installation files from the web

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 39 System release strategy

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

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

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

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 45 System representation l Systems are normally represented for building by specifying the file name to be processed by building tools. Dependencies between these are described to the building tools l Mistakes can be made as users lose track of which objects are stored in which files l A system modelling language addresses this problem by using a logical rather than a physical system representation

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide CASE tools for configuration management l CM processes are standardized and involve applying pre-defined procedures l Large amounts of data must be managed l CASE tool support for CM is therefore essential l Mature CASE tools to support configuration management are available ranging from stand- alone tools to integrated CM workbenches

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

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

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

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

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

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

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 53 System building l Building a large system is computationally expensive and may take several hours l Hundreds of files may be involved l System building tools may provide A dependency specification language and interpreter Tool selection and instantiation support Distributed compilation Derived object management

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 54 Component dependencies

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 55 l Configuration management is the management of system change to software products l A formal document naming scheme should be established and documents should be managed in a database l The configuration data base should record information about changes and change requests l A consistent scheme of version identification should be established using version numbers, attributes or change sets Key points

©Ian Sommerville 2000Software Engineering, 6th edition. Chapter 29Slide 56 Key points l System releases include executable code, data, configuration files and documentation l System building involves assembling components into a system l CASE tools are available to support all CM activities l CASE tools may be stand-alone tools or may be integrated systems which integrate support for version management, system building and change management