Configuration Management
Four Types of Activities
•Configuration management planning
•Change management
•Version and release management
•System building
Configuration Management (1)
•New versions of software systems are created as they evolve
–different machines / OS
–offer different functionality
–Tailored for particular users / requirements
•CM is concerned with managing evolving software systems
–System change --> team activity
–control the costs and effort involved in making changes to a system
Configuration Management (2)
•Involves development and application of procedures and standards to manage an evolving software product
•Part of a more general quality management process
•When released to CM, software systems are sometimes called baselines
–a starting point for further development
System Families
CM Standards
•Based on a set of standards, applied within an organization
•Standards should define:
–how items are identified,
–how changes are controlled, and
–how new versions are managed
•Standards may be based on external CM standards (e.g. IEEE standard for CM)
CM Planning (1)
•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
CM Planning (2)
•Start: early phases of the project
•Define the documents or document classes which are to be managed
–Formal Documents
•Documents required for future system maintenance should be identified and specified as managed documents
Configuration Management Plan (1)
•Defines types of documents to be managed and a document naming scheme
•Defines who is responsible for the CM procedures and creation of baselines
•Defines policies
–change control and version management
•Defines the CM records which must be maintained
Configuration Management Plan (2)
•Describes the tools which should be used and any limitations on their use
•Defines the process of tool use
•Defines the CM database used to record configuration information
•May include information such as the CM of external software, process auditing, etc.
CM Item Identification
•Large projects typically produce thousands of documents which must be uniquely identified
•Some documents are maintained for the lifetime of the software
•Document naming scheme should be defined so that related documents have related names
•A hierarchical scheme with multi-level names is probably the most flexible approach
Configuration Hierarchy
CM Planning Database
•Maintain all CM information in a CM database
•Allow queries about configurations to be answered:
–Who has a particular system version?
–What platform is required for a particular version?
–What versions are affected by a change to component X?
–How many reported faults in version T?
•CM database should be linked to the software being managed
CM Database Implementation
•May be part of an integrated environment to support software development
–The CM database and the managed documents are all maintained on the same system
•CASE tools may be integrated so that there is a close relationship between the CASE tools and the CM tools
•Typically, the CM database is maintained separately as this is cheaper and more flexible
Change Management
•Software systems are subject to continual change requests from
–users
–developers
–market forces
•Change Management:
–keep managing these changes and ensuring that they are implemented in the most cost-effective way
Change Management Process
Change Request Form
•Definition of change request form is part of the CM planning process
•Records:
•Change required
•Suggestor of change
•Reason why change was suggested
•Urgency of change (from requestor of the change)
•Change evaluation
•Impact analysis
•Change cost and recommendations (System maintenance staff)
Change Request Form
•See second lecture part.
Change Tracking Tools
•Major problem in change management:
–tracking change status
•Change tracking tools:
–keep tracking the status of each change request and automatically ensure that change requests are sent to the right people at the right time
•Integrated with email systems allowing electronic change request distribution
Change Control Board
•Changes should be reviewed by an external group who decide whether or not they are cost-effective from a strategic and organizational viewpoint rather than a technical viewpoint
•Should be independent of project responsible for system
•May include representative from client and contractor staff
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
•May be included as a comment in code. If a standard prologue style is used for the derivation history, tools can process this automatically
Example: Derivation History
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
Versions / Variants / Releases
•Versions
–An instance of a system which is functionally distinct in some way from other system instances
• Variant
–An instance of a system which is functionally identical but non-functionally distinct from other instances of a system
•Release
–An instance of a system which is distributed to users outside of the development team
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
•Systems may be released on magnetic tape, floppy disk, or CD-ROM
Version Identification
•Simple naming scheme user a linear derivation (e.g. V1, V1.1, V1.2, V2.1, V2.2…)
•Actual derivation structure is a tree or a network rather than a sequence
•Names are not meaningful
•Hierarchical naming scheme may be better
Version Derivation Structure
Attributed Version 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; Can cause problems with uniqueness
•Needs an associated name for easy reference
Release Management
•Releases must incorporate changes forced on the system by errors discovered by users and by hardware changes
•They must also incorporate new system functionality
•Release planning is concerned with when to issue a system version as a release
Lehman’s Fifth Law
•The incremental system change which can be incorporated in each release of the system is approximately constant
•If too many new features are included at the same time as error repairs, the cost of producing a new release is significantly increased
•If a release has many changes incorporated, it must be followed by a further release fixing problems in the first release
System Release Strategy
Release Problems
•Customer may not want a new release of the system
–They may be happy with their current system as the new version may provide unwanted functionality (e.g. Word 6)
•Release management must not assume that all previous releases have been accepted. All files required for a release should be re-created with a new release is installed
Version Management Tools
•Version and release identification
–Systems assign identifiers automatically when a new version is submitted to the system
•Controlled change
–Only one version at a time may be checked out for change. Parallel working on different versions
•Storage management
–System stores the difference between versions rather than all the version code
•Change history recording
RCS - Revision Control System
•RCS is a relatively old tool but still widely used
•Minimized the disk requirements by only storing differences (deltas) from a base version
•Applies deltas to the latest release to re-create earlier system versions
•Allows any named version or release to be generated
•Allows independent development of different releases
Deltas in RCS
Parallel Development in RCS
RCS Limitations
•Designed as a code control system -- therefore intended for use with ASCII text
•Cannot be used to manage object code or other documents with non-ASCII representations (e.g. multimedia files)
•Test-based user interface. Version browsing is difficult
•Version retrieval based on the name rather than the version attributes
•Involves taking all system components and combining them into a single executable system
•Different systems are built from different component combinations
•May take several days for large systems if all components are compiled and linked at the same time
•Do the build instructions include all required components?
–When there are many hundreds of components making up a system, it is easy to miss one out. This should normally be detected by the linker
•Is the appropriate component version specified?
–A more significant problem. A system built with the wrong version may work initially but fail after delivery
•Are all data files available?
–The build should not rely on ‘standard’ data files. Standards vary from place to place
•Are data file references within components correct?
–Embedding absolute names in code almost always causes problems as naming conventions differ from place to place
•Is the system being built for the right platform?
–Sometimes must build for a specific OS version or hardware configuration
•Is the right version of the compiler and other software tools specified?
–Different compiler versions may actually generate different code and the compiled component will exhibit different behavior
Configuration Threads
•Identify the version to be built by specifying its attributes (e.g. Build the version with identifier attribute, R3; build the version with status attribute ‘beta test’ etc.)
•Identify the version of the compiler and support tools along with its parameters which is to be used in building a system version
CM Support with an Integrated DB
•CM tools may be implemented using database query and browsing facilities
•Using process information, other tools such as editors / compilers etc. can be integrated and can automate version creation
•Information dissemination of versions and changes con be incorporated in the process information
Database Oriented CM Tools
•Rely on a powerful semantic or object-oriented database
•Store both process and product information
•Provide an integrated set of tools for configuration management
•Integrated with other tools through the database
•Graphical user interface
•Still research prototypes
Summary (1)
•CM is the management of system change to software products
•Effective CM is essential in large software projects
•CM activities include CM planning, change management, system building, and version and release management
•A formal document naming scheme should be established and documents should be managed in a database
Summary (2)
•System releases should be phased with releases fixing problems interleaved with releases offering new functionality
•System building involves assembling components into a system. It is always supported by system building tools such as MAKE
Software Configuration Management
Course Objectives
•What is Configuration Management?
•Why Configuration Management ?
•Functions of Configuration Management:
–Configuration Identification
–Configuration Control
–Configuration Audit
–Configuration Status Accounting
•How to Form a Software Configuration Management Team and a Software Configuration Control Board
Chapter 1
Overview
What is Configuration Management?
•Definition from IEEE – A discipline applying technical and administrative direction and surveillance to:
–Identify and document the functional and physical characteristics of a configuration item
–Control changes to those characteristics
–Record and report change processing and implementation status
–Verify compliance with specified requirements
What is Configuration Mgmt (cont’d)?
•A way to control a product and its components over time
•A formal process that involves:
–Identifying the configuration of software work products and their descriptions at given points in time:
•Applications being developed or maintained
•Development and maintenance tools
–Systematically controlling changes to the configuration
What is Configuration Mgmt (cont’d)?
–Maintaining integrity and traceability of the configuration throughout the life cycle
•SCM is part of the system configuration management process
Source: Adapted from Paulk, M.C., et. al. (CMU/SEI-93-TR-25), p. L2-71.
Exercise
•As you watch the playlet on the next two pages, prepare to discuss the following questions:
–What are the problems?
–What are the underlying causes of the problems?
–What should FFI have done to avoid them?
Common Problems
•Updates are lost; over written.
•Problems and changes are not tracked or related.
•Changes are not related to crashes.
•It is unclear exactly what changes were made.
•It is unclear whether new requirements are in the product.
•It is unclear which version supports which customer.
•The previous version that worked cannot be rebuilt.
•Poor communication – People who might be able to help are not made aware of problems.
Misconceptions
•CM is not required in this program.
•CM is applied after development.
•CM procedures slow down development.
•The document can be changed later.
•We do not have time for change boards.
CM Objectives
Ensure that all project personal know:
–What is supposed to be built
–What is being built
– What has been built
To avoid:
–Delay in schedule
–Cost overruns
–Communication problems
Why Do We Need Configuration Management?
•Because we are good at:
–Creating
–Having Ideas
–Producing Things
–Making Decisions
–Writing Programs
–Changing Programs
–Issuing Instructions
Why Do We Need Configuration Management?
•Because we are not good at:
–Documenting
–Recording Changes
–Keeping History
–Recording Decisions
–Cleaning Up
–Communicating
Four Common Problems in Software Development
•Communication breakdown
•Shared data
•Multiple maintenance
•Simultaneous update
What is Configuration?
•A set of the artifacts or configuration items (intermediate and end-products) that define the system, or a part of the system, within the system’s lifecycle
What is a Configuration Item?
•An aggregation of hardware, software, or both designated for configuration management and treated as a single unit for the configuration management process.
Functions of Software Configuration Management
–Configuration identification
–Configuration control
–Configuration status accounting
–Configuration audit
0 comments:
Post a Comment