1. Benefits
1.1. Organizes tasks and activities
1.2. Help manage assets
1.3. Provide ability to track changes
1.4. Ensures correct configurations of software
1.5. Ensures that engineering are implementing changes into the correct baseline.
1.6. Provides the ability to trace the process from requirements to product.
1.7. Limits legal liability by recording all data
1.8. Helps reduce the life-cycle cost of of maintaning software, which can easily exceed the initial cost of development.
1.9. Allows responsibility to be managed to be traced to the source.
1.10. Provides a stable enviroment fo the software development process to be defined, repeated and improved.
1.11. Enhances compliances with standards being applied.
1.12. Provides an environment in wich meaningfull measures can be gathered and used.
1.13. Allows quick and easily auditing
1.14. Provides the ability to reproduce circumstances/conditions under which the product was by retaining information relative to the production process.
1.15. Provides communication channels between groups.
1.16. Fosters an ability to improve wihout being punitive in nature.
1.17. Provides an understanding of when the product is ready for release.
1.18. Helps produce higher quality software.
2. A discipline for managing the evolution of computer systems throughout all stages of systems development.
3. Functional areas
3.1. Configuration identification
3.1.1. Objectives
3.1.1.1. identifying the structure of the software systems, uniquely identifying individual components and making them accessible in some form.
3.1.2. Identification answers
3.1.2.1. What is the configuration of my systems?
3.1.2.2. What version of the file is this?
3.1.2.3. What are the components of the systems.
3.2. Configuration change control
3.2.1. Objectives
3.2.1.1. Control the release and changes to software products throughout the software life cycle
3.2.2. Identification answers
3.2.2.1. What is controlled?
3.2.2.2. How are the changes to the products controlled?
3.2.2.3. Who controls the changes?
3.2.2.4. When are the changes accepted, received, and verified?
3.3. Configuration status accounting
3.3.1. Objectives
3.3.1.1. Recording and reporting of the changes process.
3.3.2. Identification answers
3.3.2.1. What changes have been made to the systems?
3.3.2.2. How many files were affected by this problem report?
3.4. Configuration Auditing
3.4.1. Objectives
3.4.1.1. Verifies that the software product is built according to the requirements, standards, or contractual agreement.
3.4.2. Types
3.4.2.1. Functional configuration audit (FCA)
3.4.2.1.1. Verifies that the software satifies the software requirements stated in the System Requirements Specification and the Interface Requirements Specification.
3.4.2.2. Physical configuration audit (PCA)
3.4.2.2.1. Determines whether the design and reference documents represent the software that was built.
3.4.3. Identification Answers
3.4.3.1. Does the system satisfy the requirements?
3.4.3.2. Are all changes incorporated in this version?