1. 1 / 16 CS 425/625 Software Engineering Software Configuration Management Guest Speaker Jim Hunt November 17, 2008

2. 2 / 16 Outline n n Introduction n n Version Management n n Change Control n n Build Systems n n Status Accounting n n Audit

3. 3 / 16 Introduction…. n n Software Configuration Management = Software CM is a discipline for controlling the evolution of software systems.... The standard definition for CM taken from IEEE standard 729-1983 includes: u u Identification: an identification scheme is needed to reflect the structure of the product. This involves identifying the structure and kinds of components, making them unique and accessible in some form by giving each component a name, a version identification, and a configuration identification. For example, this addresses the question, "What version of the file is this?" u u Control: controlling the release of a product and changes to it throughout the lifecycle by having controls in place that ensure consistent software via the creation of a baseline product. For example, this addresses the question, "How many changes went into the latest version of this product?" u u Status Accounting: recording and reporting the status of components and change requests, and gathering vital statistics about components in the product. For example, this addresses the question, "How many files were affected by fixing this one bug?" u u Audit and review: validating the completeness of a product and maintaining consistency among the components by ensuring that components are in an appropriate state throughout the entire project life cycle and that the product is a well-defined collection of components. For example, this addresses the question, "Are all the correct versions of files used in this current release?"

4. 4 / 16.Introduction… n n Software = The components that comprise a software system. These configuration items include, but are not limited to : u u Requirements and specifications u u Source code u u Structured environment (links) u u Development tools u u Resource files (graphics, sounds, etc.) u u Test plans u u User documentation u u Executable or binary output

5. 5 / 16..Introduction.. n n Configuration = An arrangement of functional units according to their nature. u u Source u u Libraries u u Tools u u Resources u u Structure u u Release Documentation u u Supporting Documentation

6. 6 / 16 …Introduction. n n Management = Coordinating and harmonizing a group toward accomplishing a goal. u u Software Configuration Management is a planned activity   Identify   Process   Analyze Identify Process Analyze

7. 7 / 16 Version Management….. n n Version = a set of configuration items each identified by a revision. File 1 Rev 3 Rev 2 Rev 1 File 2 Rev 4 Rev 3 Rev 2 Rev 1 File 3 Rev 1 Version 1 Version 2

8. 8 / 16.Version Management…. n n Methods for revision control u u Archive files   1 archive contains a base revision and a list of differences between revisions Works well for text Archive contains all the history of the file u u Flat files   Each revision is a complete copy of the file including any differences Works well for binary Metadata is required to contain the history

9. 9 / 16..Version Management… n n Common problems with multiple developer projects u u Simultaneous Update = Two or more programmers work separately on the same program. Last one to change the program can easily overwrite the other’s work. u u Shared Code = Each programmer in the team needs to know if a piece of the program has been modified. Their individual workspaces need to be updated to reflect this. u u Common Code = In large systems common functions and interfaces may change. As this affects the design of calling programs, every programmer must be alerted.

10. 10 / 16 …Version Management.. n n Techniques used in your Personal Software Process u u Check In / Check Out = When ready to edit a file, Check Out the latest revision and apply a semaphore to indicate to others that they someone else is editing. (Lock the file) When finished, Check in the new revision and unlock. u u Optimistic lock = In this situation, the work file is edited and checked in. On Check In differences are detected, and a merge is requested if necessary. u u Change sets = Many times, a changes to software requires changes in multiple files. Checking in revisions of a single file without the others can result in breakage. Being able to identify a set of changes and being able to undo the set of changes as a whole is advantageous. (Atomic Commit) n n Integrate your PSP into a Team Software Process u u Follow team coding standards u u Use Peer to Peer code inspections u u Communicate to the team through project roles (Project Manager, Software Architect, Module Owner, etc)

11. 11 / 16 Change Control.. n n Baseline = An identified Version of a system to which changes are may be applied. n n Change Request = A record that describes the attributes of a change. u u Description (Bug, Feature, Variant) u u Baseline to be changed ( Found In version) u u Affected Items (BOM) u u Status - lifecycle or workflow state (open, estimated, assigned, fixed, base lined, verified, closed) n n Release = A baseline that has gone through a verification process and packaged for downstream use. Baseline2 = Baseline1 + CR#2 + CR#4

12. 12 / 16.Change Control.. n n Understand the impact of Change u u Upstream impact - How does the requested change affect the requirements, architecture and specifications. u u Value Analysis – What is the cost of implementation vs. the added value of the change. u u Downstream impact – What changes in build scripts, test plans, user documentation, and setup are necessary to implement the change. n n Change is easy risk analysis is hard u u 1990 AT&T lost 75 million calls in one incident as a result of a single line of code in an code upgrade of one of their switches u u Feb 2000 Ferrari 360 Modena recalled for anti-lock brake instability – Software. April 2001 recalled again – Software.

13. 13 / 16 Build systems n n A build system automates the transition from source to executable u u Makefiles – use rules to invoke commands consistently by file type. (i.e..cpp to.o may use a dependency checker, and a compiler to make the target.o from the source.cpp) u u Build scripts – perform a repeatable build from a baseline and changes. Creates a new baseline. Performs the compiles, links, and packaging of final targets. u u IDE build – Simple graphical changes or changes to properties can have a big impact as to how the product is generated in an integrated development environment. The environment itself is a candidate for change and version control. Binary reproducibility is a requirement in certain regulated business environments such as Medical Devices and Gaming Machines. Binary reproducibility means that the executable software can be recreated identically byte for byte from the source code at any time by a third party. Create a thought experiment as to the steps and deliverable components necessary to achieve this. Try it.

14. 14 / 16 Status Accounting n n A visualization of managed versions and changes at the present time u u Shows the identified baseline of components and structure u u Shows the identified changes and their respective lifecycle disposition u u Used to communicate to the development and management teams u u Used as a tool for resource management Release Dashboard 12/3/2007 Version1.01.11.21.32.0 StatusRetiredReleasedIn TestIn Development ChangesInitial baselineCR#1 CR#2CR#3CR#4 CR#5FR#1 FR#2 FR#3 RisksFailed - still finding this release in the field Currently supported. Must work around CR3-5 Requires full regression due to Risk of CR#3 CR#5 makes a change in requirements and specifications, customer buyoff required Project management wants to roll CR4 and CR5 into a single release along with the new features.

15. 15 / 16 Audit n n Logs the history of all actions associated with the SCM function u u Who u u What u u When u u How n n Used for process improvement n n Used to show liability n n Data may be subject to subpoena

16. 16 / 16 Future of SCM n Case Tools output a great deal of change with very little input. u UML integration with SCM tools u Tools should be optimized to isolate changes n Distributed SCM architecture. u The repository is not in a common location, rather the various working locations contain the historic revisions. n Adaptive systems u Changes are performed by the system itself.  How can these changes be managed?  Changes are treated as a data model.  The program becomes content.  How does risk get reduced?