Configuration Management Principles and Practice
| Every company or organizational unit in a company that develops products should consider configuration management. Configuration management becomes part of the general culture. This means it should be adjusted to the company culture, whether loose, rigorous , or in between. Configuration management may be viewed from different perspectives: people, product, project, cross-organizational, process, and tools. Each is briefly introduced below and discussed at greater length in the book. People Perspective
Many people affect and are affected by configuration management by fulfilling the roles it involves. These may be categorized as configuration management roles, organizational roles, project- related roles, and external roles. Product Perspective
Configuration management to be performed for a product depends on the nature of the product. Today, we find more and more complex products composed of different types of subproducts, such as software (applications), hardware (boxes, PCs, peripherals), networks (LAN, Internet), data (system data, parameter values), services (intangible deliveries such as training and maintenance). Any product may have more or lesseven noemphasis on subproducts . A product may, for example, be
Products may be simple, complex, or somewhere in between. They may be harmless, with no great impact on human lives or other companies, like games or household equipment, or they may be safety-critical, like flight control systems or medical equipment. They may be developed as shrink-wrapped products, like a test tool, or as bespoke software, like a control system for a factory. Any product has a combination of these attributes. Project Perspective
The work of developing and maintaining a product may be organized in one project or in a number of projects under different management during the product's lifetime. The project perspective is concerned with performing configuration management for a product in the project or projects during its life cycle. A product goes through a number of life cycle activities, for which configuration management should be considered . These may be preparation, requirements specification, design, production (e.g., coding and/or manufacturing), integration, testing, and operation and maintenance, as illustrated in Figure I-1. Figure I-1. Generic Development Model
The activities mentioned above are just building blocks that are arranged according to the chosen development model. A number of development models exist, such as the waterfall model (similar to Figure I-1), agile development, incremental development, and iterative development. Each subproduct may follow its own development modelfor example, the software subproduct may follow an iterative development model, while the hardware subproduct follows a waterfall model. As Figure I-1 also shows, a number of support functions exist for preparing, developing, operating, and maintaining a product. These functions, which may include project management, quality assurance, and configuration management, should be performed during a product's entire lifetime. Performing these support functions produces objects, which must also be considered for configuration management. The development activities and support functions included in this book are based on the activities and support functions defined in maturity models. Cross-Organizational Perspective
All companies have cross-organizational objects or assets for which configuration management should be considered: infrastructure, company product assets (such as components for reuse developed using a product-line approach), and company documentation (sales material, plans, quality system, process descriptions, and so on). Process Perspective
Configuration management may well be the subject for process improvement. In fact, as soon as a company starts to consider configuration management, the process perspective needs to be taken into account. To sustain the work, processes must be understood and implemented and must continuously undergo improvement. Process improvement and the concept of maturity models to support it, especially in software development, are becoming more and more common in the industry. In the Capability Maturity Model (CMM), configuration management plays a prominent part as a key process area at level 2. Another maturity model, used mostly (and most) in Europe, is the BOOTSTRAP model. As part of a BOOTSTRAP assessment, a company is given a list of its five processes that most require improvement. As of early 2001, more than 50 BOOTSTRAP assessments had been performed in Denmark. Table I-1 shows the three most frequently appearing processes. Table I-1. Improvement Recommendations
More than half the projects had problems in the way they implemented configuration management and needed to improve their practices. This made configuration management the second most frequent process. Tools Perspective
It is virtually impossible to manage configuration management without one or more tools. Many tools are available, but many companies prefer to develop their own. |