Adam Goucher (![[info]](http://l-stat.livejournal.com/img/userinfo.gif){kind=small} agoucher) wrote,@ 2006-03-10 09:05:00 |
|
Watts Humphrey: Managing the Software Process - Chapter 7
Software Configuration Management - Part 1
Software Configuration Management - Part 1
- Change management is one of the fundamental activities of software engineering
- Since a key objective of the software process is to have change activity converge until the final product is stable enough to ship, the management of all changes is important
- The Need for Configuration Management
- Configuration management helps to reduce problems by coordination the work products of the many different people work on a common project
- Without control, the following could occur:
- Simultaneous update - A makes change. B makes change. B obliterates A’s change
- Shared code - Changes in shared (by programmers) code are not communicated
- Common code - Changes in common (by the system) code are not communicated
- Versions
- Control systems answer the following questions:
- What is my current software configuration?
- What is its status?
- How do I control changes to my configuration?
- How do I inform everyone else of my changes?
- What changes have been made to my software?
- Do anyone else’s changes affect my software?
- Software Product Nomenclature
- There is no standardized nomenclature, but...
- System - The package of all the software that meets the user’s requirements
- Subsystem - Large systems can have many subsystems
- Product - Subsystems typically contain many products
- Components - Products are made of Components
- Module - These are the smallest produced unit which comprise Components
- This lines up roughly with the hierarchy of tests
- Unit - Module test
- Integration - Interface testing for Components, Products, Subsystems and Systems
- Functional - What is normally referred to as “testing”
- Regression - Quality/Functions have not regressed
- There is no standardized nomenclature, but...
- Basic Configuration Management Functions
The key SCM tasks:
- Configuration Control
- There is one official copy of the code. I would add that there is one official copy of the code per release branch
- Rule of thumb: there are no two separate copies of an identical program
- Revisions
- Keep track of every chance to every module and every test case
- There is one official version and every prior version is identified and retained
- Retained copies can be used to assist in tracing problems
- Development is simply a repetitive cycle of revision, integration and test
- Derivations
- The ability to determine what has changes is one of the most powerful software testing aids
- Versions
- Several different functions can be implemented by the same module with only modest coding differences
- Each would, of course, have its own sequence of revisions and revision numbering schemes
- Deltas
- The use of versions solves the problem of different functional needs for the same module but introduces multiple copies of the same code.
- Problems with deltas
- A version can be made of a version which makes it hard (if not impossible) to work with the base code
- If for some reason you lose a delta, it is impossible to recreate the change</lli>
- So use temporary deltas
- Permanent module variations should result in the module being split
- Conditional Code
- useful for handling slight code variations
- Advantage
- There remains one copy of the code
- Disadvantages
- Requires the proper parameters to trigger; which could be astronomical is large systems
- Nightmare to maintain over a decent length of time.
- Configuration Control
- Baselines
- the baseline is the foundation for configuration management
- the official standard on which subsequent work which only authorized changes are made
- every change is recorded as a delta until the next baseline is set
- Baseline Scope
- While it may not seem that critical to save every single change, some such minor omission always seems to cause the most devastating problems in final system or acceptance test
- Rule -- Unless you know it isn't important it is. I would argue that it should be “Unless you know it isn't important, now, it might be in the future, so check in the change anyways”
- Baseline Control
- controlled flexibility is accomplished by providing the programmers with private working copies of any part of the baseline
- changes should not all be integrated and tested in one big bang
- changes need to be integrated in stages
- periodic regression tests should be run against the baseline to ensure that the integrated changes to that point do not introduce problems
- Configuration Management Records
- every change proposal is documented and authorized before being made
- proposal includes: reason for change, cost in time, cost in LOC, person responsible for change, products affected
- detailed records are crucial when hardware and software changes are made simultaneous
- most important type of record is the test report
- anyone can submit test reports, not just those in the test group
- test reports do not include proposed fix, unless a workaround was applied that would be an acceptable permanent solution
- another important record is the expect list
- detailed listing of every function / feature planned for each component in the new baseline
- developers should maintain a current list of all functions, features, fixes etc for the new baseline
- even if no other aspect of the program is directly affected by a change, it will likely affect test, documentation and integration
- Configuration Management Responsibilities
- Configuration Manager
- responsibilities
- develop, document and distribute the SCM procedures
- establish the system baseline, including backup provisions
- ensure that no unauthorized changes are made to the baseline
- ensure that all baseline changes are recorded in sufficient detail so they call be reproduced and backed out
- ensure that all baseline changes are regression tested
- provide the focal point for exception resolution
- can answer the following questions
- what code is this?
- what changed?
- what tests were run?
- what were the test results?
- where is this code?
- developed and tested code is expensive and it must be retained and protected. this is the configuration manager's basic responsibility
- responsibilities
- Module Ownership
- designating a programmer as an owner of a module helps maintain design integrity
- advantages
- knows and understands the module design
- provide advice on interfacing with the module
- technical control point for all module modifications
- review all changes and conduct periodic regression tests
- disadvantages
- "hit by a bus" vulnerable
- Change Control Board
- ensures that all changes are properly considered and coordinated
- includes members from all aspects of the development group (development proper, test, support, doc etc)
- reviews each change and either approves, disapproves or defers for more information
- seen as a bottleneck when deadlines are tight, but it is exactly at that time that it is needed the most
- development manager should chair the board
- Configuration Manager
- Need for Automated Tools
- most disastrous mistakes are often made when a project is under the greatest schedule pressure
- while harried programmers invariably intended to document their changes when there was time, it is later extremely difficult to remember precisely what was done and why
- track changes my module for code churn when targeting testing
- use commercially available tools unless it is absolutely essential not to
