SOE managing change in system development projects: configuration management
2
3 understanding the problem of change change is one of the most fundamental characteristics in any software development process (Leon 2000) it is intrinsic and must be accepted as a fact of life (Lehman 1980) changing software is very easy, but if it is done at will, results in chaos (Leon 2000) effective projects control changes, whereas ineffective projects allow changes to control them (McConnell 1998) the level and formality of control should vary according to project conditions (Whitgift 1991)
4 sources of change requirements change through misunderstanding, better customer understanding or situational change (= requirements churn) analysis clarification with improving developer understanding design improvements, evolutionary design changes, code improvement, refactoring bug fixes during test improvements and new functionality after release version, variant and implementation change component and code reuse
5 change sources: system evolution system variants initial system mobile PC Windows XP Linux server desktop SUN... alpha beta bug + issue fixes 1.0 1.1 1.3 new functionality version evolution 2.0 2.1 2.3
6 SAP to 2006
7 change sources: system evolution implementation 1 SAP r6.20 implementation 1 implementation 2... implementation n implementation 2... implementation n SAP r7.0 standard system
8 example: a simple (but late) change request requirements specification design specification test plan system documentation user manual the customer requests a new field on a screen change request presentation code model code database reports test scripts and cases XML component and system interfaces
9 a simple (but late) change request the customer requests a new field on a screen change request document -ation change test rewrite unit test debug system build system test recode
10 change problems change inherent in the life of the system many developers working concurrently on many (hundreds or thousands of) documents and files probability of introduction of further errors and communication problems system must be built and tested, preferably early many possible combinations of version, implementation and variant releases
11 software configuration management (SCM) the purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software life cycle. Software Configuration Management involves identifying configuration items for the software project, controlling these configuration items and changes to them, and recording and reporting status and change activity for these configuration items. SEI 2000a
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 A lives in New Dehli, India and B lives in Boston, US - they want to work on HelloW.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 an innocent-looking change 2 days before release causes major test problems the whole design is rolled back to its state before the change C wants to get reports about current project progress to decide if she needs to hire more programmers and delay the alpha release
13 a set of practices: - change control - version control - release management supported by tools: - configuration database - source code repository - build tools
SCM terminology configuration item any development output for which change control is considered necessary baseline a collection of configuration item(s) which is reviewed and approved, and thus under change control often a project milestone revision a change to a baseline configuration a particular assembly of configuration items (such as all the source code files for release 3.0) version a configuration adding repair or new functionality variant a configuration with similar functionality on a different platform release a version or variant distributed to users
CM activities identification status accounting control audit identification identifying the items to be managed, establishing naming conventions (e.g. PCLtools/edit/forms/display/AST-interface/code), storage and access control change evaluation change coordination change approval change implementation status accounting tracking of status of configuration items audit verifying that a configuration conforms to its specification
16 CM practice example
17 change request form Change Request Form Pr oject: Proteus/PCL-T ools Number: 23/02 Change r equester: I. Sommerville Date: 1/12/02 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/02 Components affected: Display-Icon.Select, Display-Icon.Display Associated components: FileT able 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 control board (CCB) review change implementation: code, documentation Change implementation: Estimated effort: 0.5 days Date to CCB: 15/12/02 CCB decision date: 1/2/03 CCB 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 baseline update verification, audit
18 managing collaborative working: version control, revision control solutions: pessimistic: file locking optimistic: version merging
19 version control: terminology checkout creates local working copy of file change (diff, delta) modification to a file under version control commit write or merge changes to repository merge 2 or more sets of changes applied to repository file delta compression retains the only the differences between successive versions of files trunk mainline development stream branch an alternative development stream tag/label point in time snapshot of group of files
20 version management tools version and release identification system assigns 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 record reasons for version creation independent development parallel working on different versions project support can manage groups of files associated with a project rather than just single files
21 trunk and branch, forward and reverse integration
22 example version control tool: Subversion
system building s y s t e m b u i l d e r version m a n a g e m e n t s y s t e m c o m p i l e r s l i n k e r b u i l d s c r i p t s o u r c e c o d e c o m p o n e n t v e r s i o n s o b j e c t c o d e c o m p o n e n t s e x e c u t a b l e s y s t e m compiling and linking software components into an executable system different systems built from different combinations of components invariably supported by automated tools driven by build scripts
system building tools building a large system is computationally expensive and may take several hours hundreds of 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 s c a n. o s c a n. c s y n. o s y n. c d e f s. h c o m p s e m. o s e m. c c g e n. o c g e n. c Example: SCons
25 release management release: not just a set of executable programs, 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 release creation involves collecting all files and documentation required to create a system release configuration descriptions for different hardware and installation scripts the release must be documented to record exactly what files were used to create it - this allows it to be re-created if necessary
26 many varieties of integrated tool support Rational ClearCase Rational BuildForge
27 traditional configuration management configuration management is the management of system change to software products a formal document naming scheme should be established and documents should be managed in a database the configuration data base should record information about changes and change requests a consistent scheme of version identification should be established using version numbers, attributes or change sets system releases include executable code, data, configuration files and documentation system building involves assembling components into a system case tools are available to support all CM activities case tools may be stand-alone tools or may be integrated systems which integrate support for version management, system building and change management
28 Agile CM automated daily build release environment version control test scripts code continuous integration sandbox
SOE: refactoring and patterns 29 traditional and agile configuration management traditional agile focus documents and code code activities CM practice, change management, version control, automated build version control, automated build responsible CM team, CM board programmers process formal, managed informal and integrated with practice environment outcome importance CM audit (documented product control) indispensible in medium and large projects next release indispensible