Configuration management

1. Configuration management • Managing the products (code and documentation) of system as it changes

2. Configuration management • 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 • Configuration management is concerned with managing evolving software systems

3. Configuration management • 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

4. System families

5. Daily system building • 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

6. 29. 1 Configuration management planning • All products of the software process may have to be managed • Specifications • Designs • Programs • Test data • User manuals • Thousands of separate documents are generated for a large software system

7. CM planning • 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

8. The CM plan • Types of documents to be managed • Who takes responsibility for CM • Policies for change control and version management • CM records which must be maintained • …

9. Configuration hierarchy

10. 29.2 Change management • Software systems are subject to continual change requests • 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

11. The change management process

12. C h an ge Re qu e st F o rm Pr o j e ct : N u m b e r: P r o t e u s / PC L-T o o ls 2 3/ 9 4 C h an ge re qu e s t e r : D a t e : I . S o mm e rv il l e 1 /1 2 / 9 8 R e q u es te d c h an ge : W h e n a c o m p o n e n t is s el e cte d f r om t h e st r u c t u r e, d i s p l ay t h e n a m e o f t h e f i le w h e r e i t i s s t o re d . C h an ge a n a l y se r: A n a l ys i s da t e : G . D ea n 1 0/ 1 2 / 9 8 C om po n e n ts a f f ec t e d: D i s p l a y - I c o n. S e l ect , D i s p l a y - I c o n. D i sp la y Ass oc i a t e d c o m p o n e nts : F i l eTa b le C h an ge a ss e ss m e n t: R e la t iv e l y s i m p l e t o im p l e m en t a s a f il e n a m e ta b l e i s ava i la b l e . R e q u i r e s t h e d e s i g n an d i m p l e m e nt a ti o n o f a di sp l a y f ie l d . N o c h an g e s t o ass oc i ate d c om p o ne n t s ar e r eq u i r ed . C h an ge p r i o ri t y : L o w C h an ge im p l e me n t at io n: E st i m a t e d e f f o r t : 0 .5 da ys D a t e t o C C B : C C B d eci si o n da te : 1 5/ 1 2 / 9 8 1 /2 / 9 9 C C B d eci si o n: A cce p t c ha n ge . C h an g e t o be i m p l e m en t e d i n R e lea s e 2. 1 . C h an ge im p l e me n t o r : D a t e o f c h a n g e : D a t e sub Example Change request form mi tt e d t o QA: QA decision Date submitted to CM: C omm e n ts

13. Change tracking tools • 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

14. Change control board • Decide based on a cost, strategic and organizational viewpoint • Should be independent of project team • Representatives from client and contractor staff

15. Derivation history • 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

16. Component header information

17. 29.3 Version and release management • 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

18. Version identification • 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

19. Version numbering • Simple naming scheme uses a linear derivation e.g. V1, V1.1, V1.2, V2.1, V2.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

20. Version derivation structure

21. 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. • 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

22. System releases • 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 • Systems are now normally released on CD-ROM or as downloadable installation files from the web

23. Release problems • Release management must not assume that all previous releases have been accepted.

24. Release decision making • Must plan when to distribute a system release • Preparing and distributing a release is expensive • Factors: • technical quality • competition, marketing requirements • customer change requests

25. Release creation • Collect all files and documentation • Configuration descriptions / instructions/ scripts • Documented to allow re-creation

26. 29.4 System building • 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’

27. System building

28. System building problems • Do the build instructions include all required components? • Is the appropriate component version specified? • Are all data files available?

29. System building problems • 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?

30. 29.5 CASE tools for configuration management • 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 stand-alone tools to integrated CM workbenches

31. Change management tools • 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

32. Version management tools • Version and release identification • Storage management. • Change history recording • Independent development

33. Delta-based versioning

34. e.g. Microsoft Visual Source Safe • Part of Visual Studio • Handles Sharing of Files in a project • Check out for making changes • Check back in after changes • Handles Multiple Versions • Saves latest • Saves “Backward Deltas” • Mostly makes sense with network common area available to whole team

35. Microsoft Visual Source Safe • VSS keeps a database • Inside DB there are Projects • Projects include files • Users have working folder for when they are working on something • Shadow Folder – common, read only versions of current code

36. Microsoft Visual Source Safe • 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