1. Seattle Area Software Quality Assurance Group Release and Configuration Management, The Acceleration of Change and Its Contribution To Software Quality 05/18/2006

2. The discipline of identifying the components of a continuously evolving system (taking into account relevant system interfaces) for the purposes of controlling changes to these components and maintaining integrity and traceability throughout the system life cycle British Standard 6488 Configuration Management Definition

3. Configuration Management:... A discipline applying technical and administrative direction and surveillance to A.Identify and document the functional and physical characteristics of a configuration item (CI) B.Audit the CI’s to verify conformance to specification, interface control documents and other requirements C.Control changes to CI’s and their related documentation, and D.Record and report information needed to manage CI’s effectively, including the status of proposed changes and the implementation status of approved changes. Mil-STD -480B Configuration Management Definition

4. Configuration Management Planning The urge to change is temptation defined but uncontrolled change is chaos – managing this temptation starts with a good Configuration Management Plan A good CM Plan is a necessary pre-requisite for success Configuration Management Components

5. The CM Plan must take into account:  Requirements  Planning  Process Documentation  Assessments  Roles, Responsibilities and Resources  Tools & Training  Supplier CM Management  Business Continuity – disaster recovery plan Configuration Management Components

6. Configuration Identification You can’t manage change on what you don’t identify. Proper configuration identification is the basis of configuration management. Configuration Management Components

7. Configuration Identification:  Product Structure  Product Identification  Baselines  Product Marking  Software CM Libraries  Retrievable Product Definition Data Configuration Management Components

8. Configuration Change and Variance Management Changes introduced in an uncontrolled manner result in maintenance nightmares, wasted time and users carrying pitchforks and torches screaming “where’s the release”. Configuration Management Components

9. Configuration Change and Variance:  Change Identification  Classification  Justification  Descriptions  Coordination and Evaluation of Impacts  Authorization Configuration Management Components

10. Configuration Status Accounting Where are we? Visibility of change and the progress of that change is accomplished with well defined status accounting of the configuration of the product throughout its life cycle – from design to final release. Configuration Management Components

11. Configuration Status Accounting:  Recording and Reporting – implement the requirement to record and report out on the state of the configurable items.  Visibility – the reports should be readily available and visible to support decision making, risk management and implementation planning Configuration Management Components

12. Configuration Audits The audit process verifies that the product meets its requirements. Configuration Management provides the requirement traceability and teams with Quality Assurance to ensure that adequate testing has taken place on the product being released. Configuration Management Components

13. Configuration Audits:  Functional - verify requirements to ensure product will function within its intended used  Physical - verify that the as-built product conforms to the as-designed product definition data  Discrepancy – ensure that all discrepancies associated with the product are addressed Configuration Management Components

14. A Product Release occurs when a software product is built and released from development. There is both an internal release when the product is released to Software Quality Assurance and an external release when the product is released to the customer. Release Management Definition The practice of effective Release Management involves the creation of a Configuration Management Database (CMDB), into which master copies of all software is logically stored. The CMDB manages the control and release of the product.

15. You can’ test what you don’t know Software Quality What component(s) in the product changed? Why was the change made? Who made the change? What interfaces are affected? Christmas Light Paradigm W2K SQL COTS Oracle UNIX We work with software products in an environment that resembles a tangle of lights and they are all different z/OS Legacy

16. What component in the product failed ? Christmas Light Paradigm What happens when a light bulb burns out? We are left scrambling while the customer waits. W2K Oracle UNIX Software Quality Your testing depends on a well defined well built product Legacy

17. SOX Global Markets Software subcontractors Multi-site development New technology Increasing software complexity W2K Oracle UNIX Acceleration Of Change The speed and rate of change is increasing – it is not going to get any easier no matter how frustrated or much money we burn Legacy

18. This involves more than creating a Release & Configuration Management Plan. This means detail instructions on building the software product and releasing the software product. The act of documenting the process will assist the organization to design and agree on a process that meets the objectives of the project. Back To The Basics Document Your Process

19. The Released Product should contain more than just the code. A good VDD (version description document) should accompany every release along with release notes, how the product was built, user manuals … All of this information should be stored in the Configuration Management Database if for nothing else than to be able to restore the baseline in case of disaster. Back To The Basics Document Your Baseline

20. Make sure the development and testing environments have the same configuration. Something as simple as compile options or using an OS with a different service pack can wreak havoc on testing. Make it part of your process to audit these environments – it is time well spent. Back To The Basics Have the Project Use the Same Environment

21. There are many good configuration tools on the market so choose one that will be capable of easily creating a baseline. Can the CM tool easily provide good identification and marking of CIs? Does the tool provide a good audit trail? Identify the CM criteria you need to meet your project’s objectives and document that in the CM plan in the choice of the tool Most of all use the CM tool – it does no one any good if a developer is using their own filing system for CM. Back To The Basics Choose A Good Configuration Management Tool and Use IT

22. Make sure the build environment is empty of all past files. The build should be done in an environment that is empty. Doing a build in such an environment will help identify missing or improper files – common problem is to forget to check in all your files prior to the build. Back To The Basics Do Your Builds In A Clean Environment

23. A baseline audit verifies the changes made since the last baseline. It is assurance that what was planned and designed is what is being delivered. The product is ready for release when testing and the audit is complete. It is good practice to place your final release under configuration control. One benefit is to provide for a comparison in case you need to go back and rebuild the baseline Back To The Basics Baseline Audit

24. Change is accelerating and the only way to maintain pace is to automate especially the build process. The build process should be script driven with as little human intervention as possible. The more hands on during the build the greater the chance of error and the more time is required for a successful build. Back To The Basics Automate

25. Back To The Future Understanding Release and Configuration Management and working closely with the Release & Configuration Management team will make your testing more manageable as we try to realize the 2001 future!