Software Configuration Management (SCM)

1. Software Configuration Management (SCM) • Software Configuration Management (SCM) is a) the development and b) the application of standards and procedures to the CONTROL of all software artifacts produced in the development and support of software. • Major Activities for successful SCM: • Overall planning • Assigning responsibilities • Rollout the plan for implementation • Implement and practice SCM • Track the progress and adjust

2. Over-All Planning for SCM • Major areas of planning • What is the development and support process utilized and thus what are the artifacts that need to be identified,inventoried and managed ? • Who is responsible for the various aspects of SCM ? • What are the key procedures and policies ? • What tools are needed and how much other resources are needed ? • What is the impact of SCM and relationship to other activities ?

3. Software Artifacts to be Managed • Depending on the process, the identified milestones and the committed deliverables, the list of items that need to managed may be different; but many of the following are included. • Requirements and Change Requests documents • Project, Quality, Test and various plan documents • Design documents • Prototype code and documents • Implementation Source and Object code • Test Scenario documents • Test cases and test data • Internal and external review documents • etc. • The identification of what artifacts will be inventoried and managed must be completed.

4. Types of Artifacts to be Managed • Documents : Text, Diagrams, Spread sheets, etc. • Code : source code text, executable object code • Data : data in some file or database • Pictures : Bitmapped photographic images • Audio : sound bytes of speech, music, etc. • Video : audio and images Code is the most common, and sometimes the only, artifact that is managed

5. Example of: Inter-relationship and Intra-relationship of Artifacts to be Managed Test Scenario Version 3 Specification Version 2 Code Version 3 Test Scenario Version 2 Code Version 2 Test Scenario Version 1 Specification Version 1 Code Version 1

6. Responsible parties for SCM • Planning and Impact Analysis of SCM • management personnel • process, quality assurance and configuration administration personnel • software implementation personnel • tools personnel • Designing the procedures and policies • process, quality assurance and configuration administration personnel • tools personnel • Implementing and running the tools • tools personnel and configuration administration • Participants in implementing & using SCM • the complete development organization • subcontract personnel • consultants • customers

7. Key Procedures and Policies • Naming Convention for the artifacts must be able to allow the unique identification of each artifact that is inventoried and managed. An example of 6 part product release naming convention: • pp.cc.vvv.rrr.ttt.fff where • pp is the product code (if numeric then this gives 100 unique products such as financial application, Java compiler, etc.) • cc is the country code (if numeric then this gives 100 countries such as US, French, Japanese, UK, German, Chinese, Spanish, etc.) • vvv is the version code (if numeric then this gives 1000 versions such as the MS Win98 version, UNIX version, LINUX version, etc.) • rrr is the release code (if numeric then this gives 1000 releases such as release 1, or release 2, etc.) • ttt is the type code (if numeric this gives 1000 types of material such as design doc, req. spec, test case, source code, etc.) • fff is the format (if numeric this gives 1000 types of format such as text, spreadsheet, jpeg, binary, etc.)

8. Key Procedures and Policies (cont.) • Naming Convention and Promotion Scheme for product under development or in support is a little different. • There must be a clear rule about promoting the artifact from one stage of development or support to another. • Once the artifact is promoted to a certain stage, it is locked at that stage. • It is also important to promote related artifacts such as code, help text and test cases promote promote promote promote . . Formally Inspected Functionally Tested Integration & System Tested Golden Copy Private Copies

9. Key Procedures and Policies (cont.) • Micro view of policies on control of an artifact that need to be created, accessed, and deleted. • Create : an artifact may be created for the first time and assigned a unique identifier • Delete : an artifact may be destroyed and its unique identifier is returned to the pool. • Access: an artifact may be accessed: • view only : no conflict in viewing • modification purpose : there may be conflict in that multiple parties may be accessing the same material for modifications, but the result of modifications when returned will be out of synch. There needs to be check-out and check-in rules for artifacts

10. Key Procedures and Policies (cont.) • System build : is a process where all the necessary code and code libraries are brought together and compiled and linked so that, as a set, the code will run. This process is extremely important during testing of large system with multiple participants and/or geographically distributed participants . • Build cycle may be daily or weekly or semi-monthly • All the changes to the artifacts must be submitted prior to the build cycle via a pre-set time frame or by build administrator’s announcement. • A build tool is almost a must where artifacts that are not changed are picked up from one library and those that are modified are picked up from another so lengthy re-compilation time may be saved.

11. More on Build (Partial Build) • A build in its simplest form is just compiling and linking a single program. • A build with lots of programs and lots of library functions will need a “script” or a set of “instructions” to tell the system • Which source code • Where are all the source code • Where are all the libraries • In what order to compile the code • The order the code needs to be linked 1. For testers and code fixers, they only want to test a few modules and fix the modules associated with the testing discovered problems. 2. So, they rarely want to build a complete system for a test or re-test --- only the changed modules. 3. But ---- they may not know all the relationships --- causing multiple errors in the build script for these “partial builds”

12. Main Mechanisms for SCM • Product “Versioning and Release” control tool that can handle complex naming convention and a complex product inventory scheme. 2. Artifact creation, modification, promotion, locking, and deletion mechanism which allows multiple and geographically distributed participants. 3. System build mechanism that can create a complete or a part of the system for both: • constant and regular build cycles • final “golden disc” for release

13. Some “Popular” SCM tools • Rational Clear/Case - IBM • CMVC - IBM • PVCS – Merant • Visual SourceSafe – Microsoft • CVS – Open-Source

14. Some Interesting Tools Technology Related to SCM • Storage and access of the artifact: • complete copy every time • first copy but only the modified part for subsequent copies • mixture of one original copy for each version’s first release but just the changed parts for subsequent releases • Super compare algorithm for searching out the changed artifacts and the specific changes. • Information linkages of : • Who uses information X (e.g. module fan-in sources or requirement to design to code) • Whom does information X use

15. Areas Related to SCM • Change Management where all changes must be: • requested • approved • completed • stored • All change management activities need to be performed and records kept within the SCM system. • A key artifact needed to track changes is the change request form which depending on its usage may be complex or simple: e.g. • request submission source, reason, priority, and date • request estimated impacts on schedule , cost, product, etc. • status : approved, denied, in development and test, completed • actual impact on schedule, cost product, etc.

16. Areas Related to SCM • Quality Assurance Management to measure and track quality: e.g. • relating number of changes to number of failures in error prone analysis • relating “ where used” information in SCM to fan-in and fan-out information • Process & Project Management to track and measure productivity, cost, and schedule: e.g. • using linkage information to relate certain requirements to cost and schedule

17. SCM Roll-Out and Implementation • All SCM related standards and procedures are defined and agreed to by the organization. • All SCM tools are installed and support personnel are in place. • The complete organization and especially the users are trained on the procedures and the tools. • All the groups in the organization has committed to using the SCM system and implementation or pilot implementation is started with some kind of broad announcement or ceremony.

18. Track & Audit SCM Usage • Personnel, both technical and administrative, must be ready to support and track the usage of SCM system. • Capacity of resources • Number of transactions • Number of problems found and resolved • etc. • Funds must be allocated for continual maintenance and upgrade of the SCM system itself