| ||||||
|
| ¡¡ |
SCM Definitions
SCM, like CM, is defined as the discipline of identifying the configuration of a system at discrete points in time for purposes of systematically controlling changes to this configuration and maintaining the integrity and traceability of this configuration throughout the system life cycle.
Configuration Management is the process of identifying and defining the items in the system, controlling the change of these items throughout their lifecycle, recording and reporting the status of items and change requests, and verifying the completeness and correctness of items.
Configuration Management is 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, and verify compliance with specified requirements.
[Software] Configuration Management is the the management of a software design as it evolves into a software product or system. It is also a means of communicating to the project's designers and developers, the technical detail and events that lead to the eventual build and delivery of the final product. It is not a hard line of control or wielding of the proverbial billy club. Those who have employed CM offer their praises. Many who did not employ CM rue the day they turned it down, never to know what caused their projects to do so poorly. . . . Configuration Management has been described as a discipline that governs the identification, control, status accounting, and auditing of a given entity, such as a software program or system, and the components that make up that entity. It has also been described as one of the many processes that occur within a developing engineering environment in which several engineering, software, and manufacturing processes are performed concurrently. . . . The primary activities of configuration management are identification, change control, status accounting, and configuration audit. Also added is interface control, and subcontractor CM control. Experience has shown that these are most essential to the successful conduct of the CM process when interface and subcontractors are part of a project.
Configuration Management (CM) is a discipline that applies technical and administrative direction and surveillance over the lifecycle of items to:
Configuration Management: The discipline of identifying all components and their relationships in a continually evolving system (taking into account relevant system interfaces) for the purpose of maintaining integrity, traceability and control over change throughout the lifecycle.
On any team project, a certain degree of confusion is inevitable. The goal is to minimize this confusion so that more work can get done. The art of coordinating software development to minimize this particular type of confusion is called configuration management. Configuration management is the art of identifying, organizing, and controlling modifications to the software being built by a programming team. The goal is to maximize productivity by minimizing mistakes.
Configuration management is the discipline of developing uniform descriptions of a complex product at discrete points in its lifecycle with a view to controlling systematically the manner in which the product evolves.
CM is the discipline of controlling the evolution of complex systems; software CM is its specialization for computer programs and associated documents.
Configuration Management (CM) is a collection of techniques which coordinate and control the construction of a system. Engineers have been developing complex systems for millenia. Many of the principles of CM were developed to enable hardware engineers to design and assemble the components or ever more sophisticated configurations. Some of the principles would have been familiar to the project manager charged with building the pyramids. In the 1990s millions of men and women develop complex systems using software. The systems consist of a myriad of component parts each of which evolves as it is developed and maintained. Software CM ensures that this evolution is efficient and controlled, so that the individual components fit together to form a coherent whole.
The most frustrating software problems are often caused by poor configuration management. The problems are frustrating because they take time to fix, they often happen at the worst time, and they are totally unnecessary. For example, a difficult bug that was fixed at great expense suddenly reappears; a developed and tested feature is mysteriously missing; or a fully tested program suddenly doesn't work. Configuration management helps to reduce these problems by coordinating the work products of the many different people who work on a common project.[2] Without such control, their work will often conflict, resulting in such problems as:[1]
These problems stem from confusion and lack of control, and they can waste an enormous amount of time. The key is to have a control system that answers the following questions:[2]
The key role of Software Configuration Management (SCM) is to control change activity so these questions can be answered. If, however, SCM is viewed merely as a management tool or contractual obligation, it can easily become a bureaucratic roadblock that impedes the work. While such systems may be contractually required, the real need is to assist the programmers in controlling and tracking their work, while ensuring that nothing is lost or destroyed.[5]
Configuration Management: The process of identifying and defining the configuration items in a system by controlling their release and any subsequent changes throughout the system life cycle; recording and reporting the status of configuration items and change requests; and verifying the completeness and correctness of configuration times. Software Configuration Management: Configuration management as applied to systems, or portions of systems, that consist primarily of software. More specifically a set of engineering procedures for tracking and documenting software throughout its life cycle to ensure that all changes are recorded and that the current state of the software is known and reproducible. SCM has four components, which this glossary defines separately: Configuration Identification, Configuration Control, Configuration Audit, and Configuration Status Accounting.
The purpose of Software Configuration Management is to establish and maintain the integrity of the products of the software project throughout the project's software lifecycle. Software Configuration Management involves identifying the configuration of the software (i.e., selected software works products and their descriptions) at given points in time, systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the software lifecycle. The work products placed under software configuration management include the software products that are delivered to the customer (e.g., the software requirements document and the code) and the items that are identified with or required to create these software products (e.g., the compiler). A software baseline library is established containing the software baselines as they are developed. Changes to the baselines and the release of software products built from the baseline library are systematically controlled via the change control and configuration auditing functions of software configuration management.
Software CM is a discipline for controlling the evolution of software systems.... A CM solution is dependent on an organization's needs and how it defines CM. The standard definition for CM taken from IEEE standard 729-1983 includes:
The definition includes terminology such as configuration item, baseline, release and version, etc. At a high level, most designers of CM systems incorporate functionality of varying degrees to support these aspects. But at the implementation level, from the user's viewpoint, most CM systems have different functionality. Among the many reasons for these differences are: disparate hardware platforms, operating system, and programming languages. But an interesting reason is due to the different kinds of users of a CM system. This stems from the role the user plays in the organization. In particular, a manager, a software engineer developing an application, an application customer, and an environment builder tend to see CM differently. As a result, they may want differing (albeit complementary) functionality from their CM system. For example, to a manager the term "CM" conjures up the image of a Configuration Control Board. To a software engineer, the image of baselines arise. To a customer, versions of the application arise. And to the environment builder, mechanisms such as libraries and data compression arise. All these images obviously result in different requirements for a CM system and hence possibly different functionality. When examining current technology that automates CM functions, it becomes clear that the definition of CM as given by the IEEE standard needs to be broadened to encompass the extra functionality found in CM systems. This concerns:
The most widely used definition of software configuration management SCM comes from the standards community [IEEE87, IEEE90a, IEEE90b, Buck93]. Configuration management (CM) is a discipline that oversees the entire life-cycle of a software product or family of related products. Specifically, CM requires identification of the components to be controlled (configuration items) and the structure of the product, control over changes to the items (including documentation), accurate and complete record keeping, and a mechanism to audit or verify any actions. This definition is not complete. Dart [Dart92] suggests that the definition should be broadened to include manufacturing issues optimally managing the construction of the product, process management, ensuring adherence to the defined processes and team work supporting and controlling the efforts of multiple developers. Tichy [Tich88] provides a definition that is popular in the academic and research communities: software configuration management is a discipline whose goal is to control changes to large software system families, through the functions of: component identification, change tracking, version selection and baselining, software manufacture, and managing simultaneous updates (team work). We prefer these definitions because the emphasis is on evolution of and access to software components by teams of developers, rather than control or prevention of access in the standards definition. Concurrent or parallel, distributed configuration management is simply a recognition of the true state of software development in the 1990s managing the evolution of software produced by geographically distributed teams, working semi-autonomously, but sharing a common software base.
What is Configuration Management (CM)? There are a number of different interpretations. For purposes of this newsgroup, we are talking about tracking and control of software development and its activities. That is, the management of software development projects with respect to issues such as multiple developers working on the same code at the same time, targetting multiple platforms, supporting multiple versions, and controlling the status of code (for example beta test versus real release). Even within that scope there are different schools of thought:
While process management and control are necessary for a repeatable, optimized development process, a solid configuration management foundation for that process is essential.
Configuration management is the practice of handling changes systematically so that a system can maintain its integrity over time. Another name for it is "change control." It includes techniques for evaluating proposed changes, tracking changes, and keeping copies of the system as it existed at various points in time.
[Software] Configuration Management is a combination of tools and techniques for controlling the software development process and is implemented using software tools of differing natures. The tools used are the same for all personnel, regardless of position or responsibility.... The task of configuration management is to address the classic problems of shared data, multiple maintenance, and simultaneous update, overcome communication obstacles, and provide useful information to its users. One of the basic paradigms of configuration management is that it provide a dynamic perspective of the project. To accomplish this, the entire project must be considered in a global sense. From requirements to and specifications to components, documentation and test, to the final product, each element of the product is as important as any other element ... [and] nearly every element will change in one way or another during the project lifecycle. Different groups of personnel have different needs when the global perspective of the project is considered. A developer may need to know about the various revisions of a source code module. The project manager may need to know about varius versions or releases of the project. Higher level management or marketing may only want to know about released products. The developer requires a more intimate view, that is, a fine granularity, the project manager does not. By using various options of the tool set, individuals acquire a perspective of the project suited to their particular needs. Using a single toolset, every need of each team member can be met as long as the tools used are adaptable. A good configuration management tool set should not require that the working environment be altered to conform to the requirements specified by the tools. The tool set should be adaptable to the environment. The tools should provide a vast functionality, enabling the user to match his or her needs, whether the user is a developer, documentation editor, project manager, or test engineer.
Configuration Management (CM) is the engineering and administrative disciples (which include configuration identification, control, status accounting, and auditing) that ensure that every part of the projects configuration is identified, reliable, traceable, and repeatable. These four disciplines are in fact very straightforward and logical ways of ensuring that:
. . . Think of CM as a spinal cord, linking all parts of the nervous system; providing the single channel through which all information can flow, but protecting it with a hard yet flexible vertebra! . . . A configuration item (CI) is any part of the development and/or deliverable system (whether software, hardware, firmware, drawings, inventories and/or documentation) which needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained. CIs can differ widely in complexity and may contain other CIs in a hierarchy.
Configuration Management: Management and development of the evolution of a system by identifying its exact state and composition, its configuration, at discrete points in time, in order to control change and ensure traceability of system evolution.
Configuration Management: An integrated sequence of process that enables developers to identify appropriate outcomes (e.g., data models, source code, requirements documents, and so forth) so they can review, compare, extend, or otherwise modify these outcomes in a coordinated manner.
Configuration Management: A supporting process whose purpose is to identify, define, and baseline items; control modifications and releases of those items; report and record status of the items and modification requests; ensure completeness, consistency, and correctness of the items; control storage, handling, and delivery of the items.
Configuration Management: The task of defining and maintaining configurations and versions of artifacts. This includes baselining, version control, status control, and storage control of the artifacts.
Software Configuration Management is the process of identifying, organizing, controlling, and tracking both the decomposition and recomposition of: software structure, functionality, evolution, and teamwork. In short, SCM is the "glue" between software artifacts, features, changes, and team members; it forms the ties that bind them all together from concept to delivery and beyond.
Definitions appearing on this page were contributed to me by the following people:
|
