Configuration Management

1. 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 of 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 used

20. What is Configuration Management • 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

38. 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. Chapter 25 Configuration management

39. A partially completed change request form (a) 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. Change analyzer: R. Looek Analysis date: 25/01/09 Components affected: ApplicantListDisplay, StatusUpdater Associated components: StudentDatabase Chapter 25 Configuration management

40. A partially completed change request form (b) Change Request Form 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: Chapter 25 Configuration management

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

42. Release management • A system release is a version of a software system that is distributed to customers. • For mass market software, it is usually possible to identify two types of release: • major releases which deliver significant new functionality, and • minor releases, which repair bugs and fix customer problems that have been reported. • For custom software or software product lines, releases of the system may have to be produced for each customer and individual customers may be running several different releases of the system at the same time. Chapter 25 Configuration management

43. Release tracking • In the event of a problem, it may be necessary to reproduce exactly the software that has been delivered to a particular customer. • When a system release is produced, it must be documented to ensure that it can be re-created exactly in the future. • This is particularly important for customized, long-lifetime embedded systems, such as those that control complex machines. • Customers may use a single release of these systems for many years and may require specific changes to a particular software system long after its original release date. Chapter 25 Configuration management

44. Release reproduction • To document a release, you have to record the specific versions of the source code components that were used to create the executable code. • You must keep copies of the source code files, corresponding executables and all data and configuration files. • You should also record the versions of the operating system, libraries, compilers and other tools used to build the software. Chapter 25 Configuration management

45. Release planning • As well as the technical work involved in creating a release distribution, advertising and publicity material have to be prepared and marketing strategies put in place to convince customers to buy the new release of the system. • Release timing • If releases are too frequent or require hardware upgrades, customers may not move to the new release, especially if they have to pay for it. • If system releases are too infrequent, market share may be lost as customers move to alternative systems. Chapter 25 Configuration management

46. Release components • As well as the the executable code of the system, a release may also include: • configuration files defining how the release should be configured for particular installations; • data files, such as files of error messages, that are needed for successful system operation; • an installation program that is used to help install the system on target hardware; • electronic and paper documentation describing the system; • packaging and associated publicitythat have been designed for that release. Chapter 25 Configuration management

47. Factors influencing system release planning Chapter 25 Configuration management

48. Factors influencing system release planning Chapter 25 Configuration management

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

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