Software Configuration Management (SCM) Software Configuration Management (SCM) is a) the development and b) the application of standards and procedures for CONTROLLING all software artifacts produced in the development and support of software. Major Activities for successful SCM: 1.Overall planning of development and application of SCM 2.Assigning responsibilities to develop SCM system 3.Rollout the standards and procedures for implementation 4.Implement and practice (enforce) the procedures for SCM 5.Track the progress and make necessary adjustments

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

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. 1.Requirements and Change Requests documents 2.Project, Quality, Test and various plan documents 3.Architecture/Design documents 4.Prototype code and documents 5.Implementation Source and Object code 6.Test Scenario documents 7.Test cases, test input data, and testing results 8.Installation guide document 9.User Guide, etc. The identification of what artifacts will be inventoried and managed must be completed.

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

Example of: Inter-relationship and Intra-relationship of Artifact Types to be Managed Specification Version 1 Code Version 1 Test Scenario Version 1 Code Version 2 Specification Version 2 Code Version 3 Test Scenario Version 2 Test Scenario Version 3 Should this be version 1.1 instead ?

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

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.)

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.... Private Copies Formally Inspected Functionally Tested Integration & System Tested Golden Copy promote

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 Lock/unlock : disable and enable accessing

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.

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”

Main “Mechanisms” for SCM 1.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 process that can create a complete or a part of the system for both: –constant and regular build cycles –final “golden disc” for release

Some “Popular” SCM tools Rational Clear/Case - IBM CMVC - IBM PVCS – Serena Visual SourceSafe – Microsoft Team Foundation Server - Microsoft Concurrent Version Syst. (CVS)– Open-Source SCCS – UNIX (comes with)

Some Interesting “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

“Topics” 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.

“Topics” Related to SCM (cont.) 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

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.

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