A Brief Introduction to Configuration Management

1. A Brief Introduction to Configuration Management

2. Maintenance is Inevitable • System requirements are likely to change while the system is being developed because their environment is changing • Systems are tightly coupled to their environment • When a system is installed it changes the environment and that can change the system requirements • The delivered system may not meet its requirements • Systems must be maintained to remain useful in their environment

3. Types of Maintenance • Corrective Maintenance (21%) • making changes to repair defects • Adaptive Maintenance (25%) • making changes to adapt software to external environment changes (hardware, business rules, OS, etc.) • Perfective Maintenance (50%) • extending system beyond its original functional requirements • Preventative Maintenance (4%) • modifying work products so that they are more easily corrected, adapted, or enhanced

4. Spiral Maintenance Model

5. Maintenance Costs • Usually greater than the development costs (2 to 10 times as much in some cases) • Affected by both technical and non-technical factors • Increase as software is maintained and system corruption is introduced • Aging software can have high support costs (e.g. old languages, compilers, etc.)

6. Maintenance Developer Tasks • Understand system. • Locate information in documentation. • Keep system documentation up to date. • Extend existing functions. • Add new functions. • Find sources of errors. • Correct system errors. • Answer operations questions. • Restructure design and code. • Delete obsolete design and code. • Manage changes.

7. Maintenance can be tough • Limited understanding of hardware and software (maintainer). • Management priorities (maintenance may be low priority). • Technical problems. • Testing difficulties (finding problems). • Morale problems (maintenance is boring). • Compromise (decision making problems).

8. Maintenance Cost Factors • Staff turnover • no turnover usually means lower maintenance costs • Contractual responsibility • developers may have no contractual obligation to maintain the delivered system and no incentive to design for future change • Staff skills • maintenance staff are often inexperienced and have limited domain knowledge • Program age and structure • as programs age their structure deteriorates, they become harder to understand and change

9. Maintenance Prediction • Concerned with determining which parts of the system may cause problems and have high maintenance costs • Change acceptance depends on the maintainability of the components affected by the change • Implementing changes degrade system and reduces its maintainability • Maintenance costs depends on number of changes • Costs of change depend on maintainability

10. Maintenance Prediction

11. Maintenance Complexity Metrics • Predictions of maintainability can be made by assessing component complexities • Most maintenance efforts only affect a small number of system components • Maintenance complexity depends on • complexity of control structures • complexity of data structures • module size

12. Maintenance Process Metrics • Maintainability measurements • number of requests for corrective maintenance • average time required for impact analysis • average time to implement a change request • number of outstanding change requests • If any if these increases it may signal a decline in maintainability

13. Maintenance Tools • Text editors (better than punch cards). • File comparison tools. • Compilers and linkage editors. • Debugging tools. • Cross reference generators. • Complexity calculators. • Control Libraries. • Full life cycle CASE tools.

14. Configuration Management • Software changes are inevitable • One goal of software engineering is to improve how easy it is to change software • Configuration management is all about change control. • Every software engineer has to be concerned with how changes made to work products are tracked and propagated throughout a project. • To ensure quality is maintained the change process must be audited.

15. Software Configuration Items • Computer programs • source • executable • Documentation • technical • user • Data • contained within the program • external data (e.g. files and databases)

16. Baselines • A work product becomes a baseline only after it is reviewed and approved. • A baseline is a milestone in software development marked by the delivery of one or more configuration items. • Once a baseline is established each change request must be evaluated and verified before it is processed.

17. Sources of Change • New market conditions dictate changes to product requirements or business rules • New customer needs demand modification of data, functionality, or services • Business reorganization causes changes in project priorities or SE team structure • Budgetary or scheduling constraints require system to be redefined

18. Change Requests • Requests can come from users, customers, or management • Change requests should be carefully analyzed as part of the maintenance process before they are implemented • Some changes requests must be implemented urgently due to their nature • fault repair • system environment changes • urgently required business changes

19. Change Prediction • Predicting the number of changes requires understanding the relationships between a system and its environment • Tightly coupled systems require changes whenever the environment changes • Factors influencing the system/environment relationship • number and complexity of system interfaces • number and volatility of system requirements • business processes where the system is uses

20. Soo! What is Configuration Management? • “SCM is the control of the evolution of complex systems,…, for the purpose to contribute to satisfying quality and delay constraints.” – Jacky Estublier • “SCM provides the capabilities of identification, control, status accounting, audit and review, manufacture, process management, and teamwork.” – Susan Dart

21. What is CM (cont.) • CM is a key process in Capability Maturity Model (recently updated to CMMI) • Level 1-Initial: ad hoc/chaotic • Level 2-Repeatable: basic project management and documentation • Level 3-Defined: standard and complete process control and procedures • Level 4-Managed: predictable process performance and precise measurements • Level 5-Optimizing: continuous and recursive improvement to performance • CM operates through the software life cycle

22. What is CM not • Not just version control • Not just for source code management • Not only for development phase • Selecting and using tools are important, but design and management of CM process are more crucial for project success

23. 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

24. Some Simple CM Scenarios (cont.) • A lives in New Dehli, 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

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

26. 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.

27. 1.2 1.3 1.4 1.2 1.3 1.4 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 Win32 on x86 1.3.1.1 1.3.1.2 Solaris on SPARC

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

29. 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

30. 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

31. 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

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

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

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

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

36. 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

37. 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

38. 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

39. 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.

40. Make a CM Plan • Standards • 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

41. CM Tools • Version control • 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

42. Reference and Further Reading 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.

43. 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

44. Version Control Terms • Entity • 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

45. 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

46. 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

47. 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

48. Configuration Management Team • Analysts. • Programmers. • Program Librarian.

49. Change Control Board • Customer representatives. • Some members of the Configuration management team.

50. 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.