Configuration Management Main issues: manage items during software life cycle usually supported by powerful tools

Some Simple CM Scenarios Developer A wants to see latest version of foo.c and its change history since last week B needs to revert foo-design.doc to its version two days ago B makes a release of the project and he needs to know what items to include and which version

Some Simple CM Scenarios (cont.) A lives in New Delhi, India and B lives in Boston, US, they want to work on HelloWorld.java together In the latest release, a serious bug is found and manager C wants to track what changes caused the bug, who made those changes and when C wants to get reports about current project progress to decide if she needs to hire more programmers and delay the alpha release

Configuration Item (CI) Version, Variant, and Revision Configuration SCM Terminology Configuration Item (CI) Version, Variant, and Revision Configuration Baseline Workspace

Configuration Item (CI) An approved and accepted deliverable, changes have to be made through formal procedure Examples: Management plan Requirement Design specification Source code and executable code Test specification, data, and records Log information User documentation Library and supporting software Bug reports, etc.

Version, Variant, and Revision Version: a CI at one point in its development, includes revision and variant Revision: a CI linked to another via revision-of relationship, and ordered in time Variant: functionally equivalent versions, but designed for different settings, e.g. hardware and software Branch: a sequence of versions in the time line 1.2 1.3 1.4 Win32 on x86 1.3.1.1 1.3.1.2 Solaris on SPARC 1.2 1.3 1.4

How Versions are Stored Full copy of each version Delta (differences between two versions) Forward delta Reverse delta Mixed delta 1.1 1.2 1.3 1.4 1.1 1.2 1.3 1.4

Baseline A collection of item versions that have been formally reviewed and agreed on, a version of configuration Marks milestones and serves as basis for further development Can only be changed via formal change management process Baseline + change sets to create new baselines

Workspace An isolated environment where a developer can work (edit, change, compile, test) without interfering other developers Examples Local directory under version control Private workspace on the server Common Operations Import: put resources into version control in repository Update: get latest version on the default branch Checkout: get a version into workspace Checkin: commit changes to the repository

Configuration An arrangement of functional CIs according to their nature, version and other characteristics Guaranteed to recreate configurations with quality and functional assurance Sometimes, configuration needs to record environment details, e.g. compiler version, library version, hardware platform, etc. Simple examples Ant buildfile, Makefile

Configuration Control Board ensures that every change to the baseline (change request - CR) is properly authorized and executed CCB needs certain information for every CR, such as who submits it, how much it will cost, urgency, etc CCB assesses the CR. If it is approved, it results in a work package which has to be scheduled. so, configuration management is not only about keeping track of changes, but also about workflow management SE, Configuration Management, Hans van Vliet, ©2008

Configuration management tasks identification and definition of configuration items, such as source code modules, test cases, requirements specification managing changes and making configuration items available during the software life cycle, usually through a Configuration Control Board (CCB) keeping track of the status of all items (including the change requests) crucial for large projects SE, Configuration Management, Hans van Vliet, ©2008 © SE, Configuration Management, Hans van Vliet

General Workflow of a change request change request (CR) investigate notify owner reject approve schedule work request info defer implement change SE, Configuration Management, Hans van Vliet, ©2008

Tool support for configuration management if an item has to be changed, one person gets a copy thereof, and meanwhile it is locked to all others new items can only be added to the baseline after thorough testing changes in the status of an item (e.g. code finished) trigger further activities (e.g. start unit testing) old versions of a component are kept as well, resulting in versions, like X.1, X.2, … we may even create different branches of revisions: X.2.1, X.2.2, … and X.3.1, X.3.2, ... SE, Configuration Management, Hans van Vliet, ©2008

Functionalities of SCM tools Components (storing, retrieving, accessing, …) Structure (representation of system structure) Construction (build an executable) Auditing (follow trails, e.g. of changes) Accounting (gather statistics) Controlling (trace defects, impact analysis) Process (assign tasks) Team (support for collaboration) SE, Configuration Management, Hans van Vliet, ©2008

Models of configurations version-oriented: physical change results in a new version, so versions are characterized by their difference, i.e. delta change-oriented: basic unit in configuration management is a logical change identification of configuration becomes different: “baseline X plus fix table bug” instead of “X3.2.1 + Y2.7 + Z3.5 + …” SE, Configuration Management, Hans van Vliet, ©2008

Version Control Models (1/3) Basic problem of collaborative work Figure from svn-book

Version Control Models (2/3) Model 1-Pessimistic: lock-modify-unlock Problems: Forget to unlock Parallel work not possible Deadlock Figure from svn-book

Version Control Models (3/3) Model 2-Optimistic: copy-modify-merge Figure from svn-book

Change control process Status accounting Configuration audit SCM Processes Change control process Status accounting Configuration audit Release management CM planning

Change Control Process Submission of Change Request (CR) Technical and business evaluation and impact analysis Approval by Change Control Board (CCB) Engineering Change Order (ECO) is generated stating changes to be made criteria for reviewing the changed CI CI’s checked out Changes made and reviewed CI’s checked in

Status Accounting Administrative tracking and reporting of CIs in CM system Examples Status of proposed changes Status of approved changes Progress of current version, on or behind schedule Estimate of resources to finish one task bugs identified by configuration audit

Configuration Audit Independent review or examination to assess if a product or process is in compliance with specification, standards, contractual agreement, or other criteria Examples Verifies that CIs are tested to satisfy functional requirements Verifies that baseline contains necessary and correct CI versions Ensures that changes made to a baseline comply with the configuration status reports

The change management process Change Request Form Project: SICSA/AppProcessing Number: 23/02 Change requester: I. Sommerville Date: 20/01/09 Requested change: The status of applicants (rejected, accepted, etc.) should be shown visually in the displayed list of applicants. 3:06 PM Chapter 25 Configuration management

A partially completed change request form (a) Project: SICSA/AppProcessing Number: 23/02 Change requester: I. Sommerville Date: 20/01/09 Requested change: The status of applicants (rejected, accepted, etc.) should be shown visually in the displayed list of applicants. Change analyzer: R. Looek Analysis date: 25/01/09 Components affected: ApplicantListDisplay, StatusUpdater Associated components: StudentDatabase 3:06 PM Chapter 25 Configuration management

A partially completed change request form (b) Change assessment: Relatively simple to implement by changing the display color according to status. A table must be added to relate status to colors. No changes to associated components are required. Change priority: Medium Change implementation: Estimated effort: 2 hours Date to SGA app. team: 28/01/09 CCB decision date: 30/01/09 Decision: Accept change. Change to be implemented in Release 1.2 Change implementor: Date of change: Date submitted to QA: QA decision: Date submitted to CM: Comments: 3:06 PM Chapter 25 Configuration management

Release Management Creation and availability of a new version of software to the public Release format Source code + build script + instructions Executables packaged for specific platforms Other portable formats: Java Web Start, plugins Patches and updates: automatic, manual Release content Source and/or binary, data files, installation scripts, libraries, user and/or developer documentation, feedback programs, etc.

Make a CM Plan Standards CM plan components IEEE Std 828 (SCM Plans), ANSI-IEEE Std 1042 (SCM), etc. CM plan components What will be managed (list and organize CIs) Who will be responsible for what activities (roles and tasks) How to make it happen (design processes for change requests, task dispatching, monitoring, testing, release, etc.) What records to keep (logs, notes, configurations, changes, etc.) What resources and how many (tools, money, manpower, etc.) What metrics to measure progress and success

CM Tools Version control Bug tracking Build Project management RCS, CVS, Subversion, Visual Source Safe, Rational ClearCase Bug tracking Bugzilla, Mantis Bugtracker, Rational ClearQuest Build GNU Make and many variants, Ant Project management Sourceforge.net, freshmeat.net, GForge, DForge

Configuration Management Tasks Identification tracking changes to multiple SCI versions Version control controlling changes before and after customer release Change control authority to approve and prioritize changes Configuration auditing ensure changes are made properly Reporting tell others about changes made

Version Control Terms Entity Variant New version composed of objects at the same revision level Variant a different set of objects at the same revision level and coexists with other variants New version defined when major changes have been made to one or more objects

Version identification Procedures for version identification should define an unambiguous way of identifying component versions. There are three basic techniques for component identification Version numbering; Attribute-based identification; Change-oriented identification.

Version numbering Simple naming scheme uses a linear derivation V1, V1.1, V1.2, V2.1, V2.2 etc. The actual derivation structure is a tree or a network rather than a sequence. Names are not meaningful. A hierarchical naming scheme leads to fewer errors in version identification.

Version derivation structure

Attribute-based identification 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. This is more flexible than an explicit naming scheme for version retrieval; However, it can cause problems with uniqueness - the set of attributes have to be chosen so that all versions can be uniquely identified. In practice, a version also needs an associated name for easy reference.

Attribute-based queries 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. The query selects a version depending on attribute values AC3D (language =Java, platform = XP, date = Jan 2003).

Change-oriented identification Integrates versions and the changes made to create these versions. Used for systems rather than components. Each proposed change has a change set that describes changes made to implement that change. 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.

Change Control Process - 1 Change request is submitted and evaluated to assess its technical merit and impact on the other configuration objects and budget Change report containing the results of the evaluation is generated Change control authority (CCA) makes the final decision on the status and priority of the change based on the change report

Change Control Process - 2 Engineering change order (ECO) is generated for each change approved ECO describes the change, lists the constraints, and criteria for review and audit Object to be changed is checked-out of the project database subject to access control parameters for the object Modified object is subjected to appropriate SQA and testing procedures

Change Control Process - 3 Modified object is checked-in to the project database and version control mechanisms are used to create the next version of the software Synchronization control is used to ensure that parallel changes made by different people don’t overwrite one another

Configuration Management Team Analysts. Programmers. Program Librarian.

Change Control Board Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint. Should be independent of project responsible for system. The group is sometimes called a change control board. The CCB may include representatives from client and contractor staff. Customer representatives. Some members of the Configuration management team.

Problem is reported to configuration control board. Programmer’s View - 1 Problem is discovered. Problem is reported to configuration control board. The board discusses the problem is the problem a failure? is it an enhancement? who should pay for it? Assign the problem a priority or severity level, and assign staff to fix it.

Programmer files a change report documenting all changes made. Programmer’s View - 2 Programmer or analyst locates the source of the problem determines what is needed to fix it Programmer works with the librarian to control the installation of the changes in the operational system and the documentation. Programmer files a change report documenting all changes made.

Change Control Issues Synchronization (when?) Identification (who?) Naming (what?) Authentication (done correctly?) Authorization (who O.K.’d it?) Routing (who’s informed?) Cancellation (who can stop it?) Delegation (responsibility issue) Valuation (priority issue)

Software Configuration Audit - 1 Has the change specified by the ECO been made without modifications? Has an FTR been conducted to assess technical correctness? Was the software process followed and software engineering standards applied? Engineering change order formal technical review

Software Configuration Audit - 2 Do the attributes of the configuration object reflect the change? Have the SCM standards for recording and reporting the change been followed? Were all related SCI's properly updated?

Configuration Status Report What happened? Who did it? When did it happen? What else will be affected by the change? Reference Introduction to Configuration Management, lecture slides for COMP3100/3500, Ian Barnes, the Australian National University. Software Configuration Management, Center for Development of Advanced Computing, Mumbai at Juhu, India. Concepts in Configuration Management Systems, Susan Dart, CMU. Software Configuration Management: A Roadmap, Jacky Estublier, CNRS, France. Further Reading Software Engineering, a Practitioner’s Approach (6th), part 4, Roger Pressman. Code Complete (2nd), Steve McConnel. http://cmcrossroads.com/ Implementing and Integrating PDM and SCM, Ivica Crnkovic et al. Version Control with Subversion, Ben Collins-Sussman et al.

Evolution of SCM tools Early tools: emphasis on product-oriented tasks Nowadays: support for other functionalities too. They have become a (THE) major tool in large, multi-site projects Agile projects: emphasis on running system: daily builds SE, Configuration Management, Hans van Vliet, ©2008

Configuration Management Plan Management section: organization, responsibilities, standards to use, etc Activities: identification of items, keeping status, handling CRs SE, Configuration Management, Hans van Vliet, ©2008

Summary CM is about managing al kinds of artifacts during software development Crucial for large projects Supported by powerful tools SE, Configuration Management, Hans van Vliet, ©2008