Register your product to gain access to bonus material or receive a coupon.
Configuration Management Principles and Practice
- By Anne Mette Jonassen Hass
- Published Dec 30, 2002 by Addison-Wesley Professional. Part of the Agile Software Development Series series.
Book
- Sorry, this book is no longer in print.
Description
- Copyright 2003
- Dimensions: 7-3/8" x 9-1/4"
- Pages: 424
- Edition: 1st
- Book
- ISBN-10: 0-321-11766-2
- ISBN-13: 978-0-321-11766-3
Configuration management (CM) is frequently misunderstood. This discipline is growing in popularity because it allows project participants to better identify potential problems, manage change, and efficiently track the progress of a software project. CM is not easy, but at the same time, it need not be difficult. This book gives the reader a practical understanding of the complexity and comprehensiveness of the discipline. Many current CM practitioners rely too heavily on commercial CM tools, and fail to understand the concept as a whole. With the deeper knowledge of CM principles taught in this book, readers will be better able to manage and deliver their next project. The book is included in the Agile Software Development Series because there is growing recognition that an effective configuration management strategy is the cornerstone of a truly agile project.
Sample Content
Online Sample Chapter
What Is Configuration Management?
Downloadable Sample Chapter
Click below for Sample Chapter(s) related to this title:
Sample Chapter
1
Table of Contents
List of Figures
List of Tables
Foreword by Kim Caputo
Foreword by Alistair Cockburn
Preface
Introduction
I. WHAT IS CONFIGURATION MANAGEMENT?
1. Definition of Configuration Management Used in This BookConfiguration Management Activities
Metadata
Configuration Management Is Cyclicor Is It?
Quality Assurance Process
Audit
Identification
Inputs
Outputs
Process Descriptions
Unique Identification
Examples
Authorization
Roles
Connection with Other Activities
Storage
Library
Main Processes
Process Descriptions
Roles
Connection with Other Activities
Example
Change Control
Inputs
Outputs
Change Control Activities
Usage of Metadata
Consequence Analysis
Roles
Process Descriptions
Connection with Other Activities
Example
Status Reporting
Inputs
Outputs
Process Descriptions
Roles
Connection with Other Activities
False Friends: Version Control and Baselines
Version Control
Baseline
2. Configuration Management in Maturity ModelsCMM Version 1.1
CMM Maturity Levels
Definition
Activities
CMMI
CMMI Process Areas
Definition
Goals
Practice-to-Goal Relationships
Capability and Maturity Levels
Achieving Capability Levels
Level 2 for All Process Areas
Raising the Capability of the Configuration Management Process
ISO 15504 (SPICE) and BOOTSTRAP 3.2
SPICE Process Model
Definition
Goals
Best Practices
Maturity Levels
Maturity of Configuration Management
3. Configuration Management in International StandardsOverview of Related Standards
BS6488, DoD, IEEE
BS6488
DoD Mil-Std-973
IEEE-Std-610.12-1990
ESA PSS-05-09
Introduction from the Guide
GAMP
Description from the Guide
ISO 9001:1994, ISO 9000-3, and ISO 9001:2000
ISO 9001:1994
ISO 9000-3
ISO 9001:2000
4. Organizations Working with Configuration ManagementInstitutions and Companies
CM Today Yellow Pages
Institute of Configuration Management
Conferences
Ovum
Software Engineering Institute
Projects
ACME
AdCoMs
DaSC
5. Scoping the Configuration Management TaskLevel of AmbitionCost/Benefit Analysis
Level of Ambition = Scope + Formalism
Formalism for a Configuration Item
Degrees of Formalism
Earliest and Latest Extremes for Starting Configuration Management
Formalism and Tools
Expansion of Scopefrom Candidate to Item
No Rough Drafts—Please!
Expansion from the Middle
Examples
Calculation of Profitability
Expenses
Savings
Pitfalls in Connection with Scoping
Too Demanding
Wrong
Too Coarse or Too Fine
Too Embracing or Too Exclusive
Too Late or Too Early
How to Treat What Is Kept Outside
Objects to Keep Outside
Identification
Storage
II. CONFIGURATION MANAGEMENT DATA
6. What Can Be Placed under Configuration ManagementPhysical or Electronic Objects
Configuration Item Class Hierarchy
Physical Objects
Electronic Objects
Types of Objects in Product Perspective
Software
Hardware
Network
Data
Services
Tools
Types of Objects in Project Perspective
Life Cycle Activities
Support Functions
Tools
Types of Objects in Cross-Organizational Perspective
Cross-Organizational Perspective
Administrative Documents
Company Product Assets
Infrastructure
Quality System
Deliveries under Configuration Management
Examples
Project Relationships
Deliveries for Planned Events Like Milestones
Development Model
Milestones
7. What One Needs to Know about a Configuration ItemOverview of Metadata for a Configuration Item
Data Elements
Metadatabase Medium
Other Data Elements
Metadata for Unique Identification
Belongs To
Name
Version
Status
Date
Storage Location
Storage Medium
Example of States for a Document
Example of States for a Source Code Unit, Including in Build
Metadata for Authorization
Producer
Person Holding Overall Responsibility
Person Responsible for Approval
Ownership
Metadata for Relations to Other Configuration Items
Traces To (and From!)
Tracing Registration
Importance of Tracing
Produced With
Derived From
Consists Of
Metadata for Distribution
May Be Distributed To
Has Been Distributed To
8. What One Must Register for a Configuration ItemItem Approval
Quality Approval
Medium
Content
Examples
Release Request
Medium
Content
Stock Control
Examples
Event Registration
Life Cycle and Responsibility
Content
Created
For Evaluation
Under Decision
Under Change
Closed
Classification
Examples
Change Request
Life Cycle and Responsibility
Content
Created
Implemented
Approved
New Events
Examples
9. What Information Is Available for Configuration ItemsExamples
Release Note
Item Status List
Item History List
Item Composition List
Trace Report
Configuration Management as Supplier of Measurements
Ideas for Process Improvement
III. ROLES IN CONFIGURATION MANAGEMENT
10. People and Configuration ManagementConfiguration Management as a Career
Qualifications
Managing Configurations Is Everyone's Job
Understanding Team Roles
Putting Teams Together
11. Configuration Management RolesConfiguration Control Board
Skills and Knowledge
Multiple Boards
Managing Configurations of CCB Work Products
References
Librarian
Tools
Managing Configuration of Library Work Products
References
Person Responsible for Configuration Management
Planning Configuration Management
Managing Configuration Management Work Products
References
12. Organizational RolesManagement
Defining and Tracking Goals
Benefits
References
Person Responsible for Assets
Different Process Descriptions
References
Person Responsible for Operation
Configuration Management Responsibility
References
Person Responsible for Process Management
Managing Configurations of Process Management Work Products
References
Person Responsible for Environments and Tools
Managing Configurations of Environments and Tools
References
Support/Helpdesk
References
13. Project-Related RolesAnalyst
Benefits
References
Designer
Benefits
References
Programmer
Benefits
References
Integrator
Benefits
References
Tester
Benefits
References
Project Manager
Benefits
Managing Configurations of Project Management Work Products
References
Person Responsible for Quality
Managing Configurations of Quality Assurance Work Products
References
Person Responsible for Customer Contact
References
Person Responsible for Subcontractor Contact
References
14. External RolesCustomer
References
Subcontractor
References
IV. CONFIGURATION MANAGEMENT IN PRACTICE
15. General PrinciplesMilestones
Identification
Generic Content Lists
Storage
Change Control
Status Reporting
Document Handling
Configuration Items or Deliveries
Identification
Authorization
Tracing
Storage
Change Control
Status Reporting
Emergency Changes
Examples
Principles for “Cheating”
Avoid Cheating
Examples Again
16. Configuration Management in Development ActivitiesDocumentation Activities (Specifications and Design)
Identification
Coding
Unique Identification
Authorization
Tracing
Storage
Change Control
Integration
Production Time
Unique Identification
Tracing
Storage
Change Control
Test
Deliveries
Identification
Tracing
Storage
Change Control
Operational Use
Configuration Management Considerations
Release
Event Registration
Status Reporting
Organizational Considerations
Backup
Maintenance
New Versions
Configuration Management Considerations
Example
17. Managing Configurations for Project Support FunctionsProject Management
Example
Deliveries
Connection with Other Processes
Identification
Tracing
Change Control
Status Reporting
Configuration Management
Milestone Deliveries
Storage
Change Control
Status Reporting
Quality Assurance
Connection with Other Processes
Subcontractor Management
Identification
Storage
Change Control
Status Reporting
Delivery
18. Managing Configurations in Different Development ModelsAgile Development
Configuration Management in Agile Development
Empowered Teams
Process Handling
Environment and Support
Requirements Management
Working Together
Frequent Delivery of Working Software
Communication and Documentation
Status Reporting
Frequent-Build Technique
Planning Considerations
Configuration Management Considerations
Frequent Builds Are Not Frequent Storage
Identification
Building
Storage
Backtracking
Change Control
Example
Integrated Product Development
Organizational Considerations
Configuration Management Considerations
Approach
Iterative Development
Configuration Management Considerations
Requirements Management
Identification
Storage
Change Control
Status Reporting
Sequential Development
W-Model
Configuration Management Considerations
Identification
Change Control
Status Reporting
19. Managing Configurations for Different Product TypesComposite Systems
Design Considerations
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
Multiplatform
Configuration Management Considerations
Identification
Multivariants
Examples
Requirements Considerations
Design Considerations
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
Safety-Critical Products
Examples
Configuration Management Considerations
Size of Product (Large and Small)
Small Systems
Large Systems
Identification
Storage
Change Control
Status Reporting
Tool Considerations
Web Applications
Examples
Content Management
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
20. Managing Configurations under Special ConditionsMultisite Development (Geographic Distribution)
Example
Organizational Considerations
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
Example
Multiple Stakeholders
Get an Overview of the Requirements
Analyze the Requirements
Describe the Fulfillment
Conflict of Authority
Parallel Development
Example
Planning Considerations
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
Tool Considerations
Tool Support
Configuration Management Considerations
21. Managing Configurations for Cross-Organizational FunctionsCompany Infrastructure
Organizational Considerations
Identification
Storage
Change Control
Status Reporting
Cross-Organizational Objects
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
External Reuse Component Development
Examples
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
Internal Asset Development (Product-Line Approach)
Examples
Central Ownership of Components
Configuration Management Considerations
Identification
Storage
Change Control
Status Reporting
Quality System, Including Process Management
Configuration Management Considerations
Responsibility
Identification
Storage
Change Control
Status Reporting
V. IMPROVING CONFIGURATION MANAGEMENT
22. Getting Started on Configuration Managementup to Capability Level 1How to Get Started from Nothing 267
Getting the Right People
Collecting Best Practices Internally
Looking at the Outside World
Focus
Look Ahead
First Steps Toward Configuration Management
Establish Baselines
Track and Control Changes
Minimum Documentation
Establish Integrity
Experiences in Implementing Configuration Management
Overall Conclusion
Datamat Ingegneria dei Sistemi
S.I.A S.p.A
Istiservice, S.p.a
Event A/S
Sysdeco A/S
23. Planning Configuration Managementup to Capability Level 2General Planning Advice
The Plan Itself
Connection to the Project
Template
Table of Contents for a Configuration Management Plan
Configuration Management Plan: Introduction
Purpose
Scope
Vocabulary and Reference Lists
Configuration Management Plan: Management and Relations to the Environment
Organization
Responsibilities
Interface Control
Subcontractor Management
Relevant Standards
Configuration Management Plan: Activities
Identification
Storage
Change Control
Status Reporting
Configuration Management Plan: Schedule
Tasks
Phases and Milestones
Diagrams and Charts
Configuration Management Plan: Tools, Techniques, and Methods
Tools
Techniques and Methods
24. Processes for Configuration Managementup to Capability Level 3Processes in General
Connection with Maturity Models
Definitions
A Process Is Like a Recipe
Process Model
Configuration Management ProcessesOverview
Special Requirements for Configuration Management Processes
Configuration Management ProcessModel Examples
25. Continuous Improvement of Configuration Managementup to Capability Level 4 and 5General Software Process Improvement Advice
Processes in Use
Dissemination and Adaptation
Companies at Capability Levels 4 and 5
Metrics for Controlling Configuration Management Performance
Metrics in General
Measuring Methods
Measurement Plan
Examples
Analyzing Metrics for Control and Improvement
Statistics
Balance Point
VariationWhat Is Normal
Control Charts
26. Tool Support for Configuration ManagementClasses of Tools for Configuration Management
Individual Support
Project-Related Support
Full, Company-Wide Process Support
Who Should Use Which Tool?
Organizational Considerations
Business Goals
Buy It or Do It Yourself
Environmental Constraints
Legacy from the Past
Financing
Organizational Scope
Ownership
Planning for the Future
Willingness to Change
Selecting a Configuration Management Tool
Evaluation Group
Evaluation Method
Requirements
Detailed Evaluation
Nomination of the Winner
Requirements for Configuration Management Tools
Integration with Other Tools
Performance
Scalability
Usability
Web Access
Requirements for the Tool Supplier
Acquaintances
Employees
Financial Status
Focus
Tool Use
Reputation
Support Facilities
Customizing Configuration Management Tools
One Tool or More
Changing Tools or Processes
From Class to Class
Appendix A. Configuration Management Process Model:A Software Code ExampleAppendix B. Configuration Management Process Model:A Tracing Example
Appendix C. Agile SCM
Glossary
Bibliography
Index 0321117662T12242002
Preface
My Life As a Software Professional
I have two—well three, really—passions in my professional life: test, configuration management, and process improvement. I started my career as an all-round developer—a little requirements elicitation, a little analysis, a lot of coding and re-coding, and some test—more than 20 years ago. During these first professional years, I always loved the testing part themost—making my work run on the computer and enjoying the satisfaction of being told, in a factual and precise way, that something was wrong, which enabled me to carry out the correction and then finally enjoy the privilege of knowing that at least this error was a secret between me and the computer.
My experience grew, and my working teams grew. The problems grew. I wasn't always certain that I had produced what I was supposed to and that I had tested everything. And sometimes an error would reoccur! I got a job as the person responsible for system and acceptance test in a company making software for the European Space Agency, and, for the first time in my then twelve year career, I heard the words configuration management. I had no clue as to what it was, but as I spent hours and hours trying to figure it out, discussing it with the person responsible for quality assurance, and actually using parts of it in my daily work, I came to understand what a wonderful tool I had found.
For the first time I was able to trace my test cases to the requirements. I was able to tell, at any given point, how many requirements I had covered in my test specification and how many requirements were still outstanding. I didn't have to encounter the frustration of having made test cases for requirements that were not going to be implemented anyway. In cases where I had forgotten the reason for a turn in the work, I was able to find a previous version of my test specification and see why I had changed it. I loved it!
For the last seven years, I have been working as a consultant, spending a good deal of my time on testing assignments of many different types in many different companies. One of the things I have learned from these assignments is that there is often a difference between what a customer asks for and
Test consultants are often presented with a system to test without the right conditions for performing a professional test.
The requirements may be in any state from non-existent to brilliantly documented, with a pronounced bias towards the first extreme. If requirements are present, they are most often not up-to-date. This is partly a requirement specification problem, partly a configuration management problem.
Test requires resources in terms of time and people to perform the test. These resources are often all too scarce. This is a project management problem. When test consultants plan and perform a test they need to establish an overview of not only what has to be tested, but also how the test is progressing, what errors have been found, and what the state of error correction is. These are configuration management issues.
It is a temptation for a consultant to try to deliver what the customer really needs. There are, however, some limitations and threats in this approach. The art is to strike the right balance between what is needed and what is feasible. One of the things to keep in mind as a consultant is to keep up the standards, but keep it light. So I try to keep up the configuration management standards as I solve the test assignment—hoping that my customer will get an idea of what configuration management is, and maybe ask for some assistance in that direction too.
Another part of my time is spent assessing software producing companies using the BOOTSTRAP maturity model and method. Like the related Capability Maturity Model (CMM), this model includes configuration management. As an assessor in more than forty assessments, I have time and again seen the blank look in people's eyes when I ask how they perform configuration management. The eyes rarely get less blank if I elaborate and ask about tracing between work products, production of error reports, or other detailed configuration management disciplines.
On the other hand people are more than willing to talk about the problems they have experienced due to lack of control over what is being implemented and tested, and when, and lack of control over what errors have occurred and which ones are being corrected and which are not.
Despite the fact that configuration management is one of the basic disciplines for a sound development (in CMM it is a key process area at level 2) many people go through a considerable part of their career without any idea of what configuration management is and how it can ease their everyday tasks; just like I did. So I keep emphasizing the importance of configuration management and very often recommend it as one of the first disciplines a company should be working on when embarking on structured process improvement.
The Creation ofThis Book
In 1999 the Danish organization Datateknisk Forum, an association of about seventy software producing companies, asked me to write a book on configuration management. The demand was the result of a survey amongst the members as to what topic they needed a book on.
Some of the comments and requirements that came back from the survey were:
I took on the assignment because in my own experience, configuration management has been of great value, not because I felt I knew much about it theoretically. I know much more now, and I hope I shall be able to convey to the readers some of the understanding, knowledge, and appreciation of the discipline that I have gained during my work on this book. If the readers try at least some of the detailed disciplines of configuration management, it is my hope that they will experience the same enthusiasm about the usefulness of the discipline as I did.
The book is written on the basis of the study of literature as well as experience—and also on the basis of attitudes and opinions. It contains a lot of examples, advice, and recommendations, which are not to be regarded as the TRUTH, but primarily as the sum of a lot of experience—positive as well as negative.
When I learned that the book was to be published in the Agile series, I knew little about Agile development. But as I studied the values and principles I found out that I had practiced it in parts for years. Agile software development is a wonderful idea, and one of the cornerstones of its success is configuration management, so it was a pleasure to be able to contribute to the series with one of my favorite disciplines. The book may seem a bit heavy to some Agilists, but I think it is better to discard some formality and some detailed activities deliberately, knowing what it is that one has not performed, rather than just not performing it, out of ignorance. So, Agilists and others, read and choose!
The Purpose of the Book
This book is not supposed to be a primer in configuration management. It does, however, start with an introduction to fundamental principles, in order to establish a basic understanding of the concepts used in the main part of the book, which discusses the more advanced issues encountered when configuration management has to be implemented in practice.
The overall purpose of the book is twofold:
It is assumed that the reader has some knowledge of other disciplines within software development, such as planning, design, test, and quality assurance.
0321117662P08272002
Foreword
Click below for Sample Chapter(s) related to this title:
Foreword
Index
Click below to download the Index file related to this title:
Index
More Information
Other Things You Might Like
Practical Software Architecture: Moving from System Context to Deployment
- By Tilak Mitra
- eBook $38.39
- About
- Affiliates
- Cookies
- FAQ
- Legal Notice
- Ordering Information
- Pearson+
- Privacy Notice
- Do Not Sell My Personal Information
- Press
- Promotions
- Support
- Write for Us