Mgmt.
1
Software Configuration Engineering II Configuration Mgmt
TEXT: Essentials of Software Engineering, Frank Tsui, Orlando Karam Chapter 11 PROJECT WORK: We will do a lab not related to the project this week. OBJECTIVES: The student shall be able to: Define configuration item, configuration aggregate, version, release, change request, branch, merge, Change Control Board, baseline, and why each is important. Describe the lifecycle of a Change Request Describe how a programmer uses checkout and checkin during programming and why they are necessary. List advanced build techniques used by SCM tools, and why they are useful. Describe the purpose of a baseline, what it consists of, and why it is needed. Be able to use SubVersion tool to create versions, check-in, check-out files, display file history, and show differences between versions. Describe the function of the Makefile utility. CONCEPTS: Introduction Versions, Releases & Baselines Change Management & Builds Makefile and Subversion Subversion Lab Total 1/4 hour 1/2 hour 1/2 hour 1/2 hour 1.25 hour 3 hours
Configuration Mgmt.
2
Software Configuration Management (SCM)
The purpose of Software Configuration Management is to assist the programmers in controlling and tracking their work, while ensuring that nothing is lost or destroyed. Configuration Management standards are a requirement of SEI Level 2, and ISO 9000. Key SCM Components include:
Version & Release Management
Version and Release Management: Identifies, tracks, retrieves, and merges different versions and releases of configuration items and aggregates. Configuration Item (CI): A single entity: work product or piece of software (e.g. SPMP, design document, source code file, test plan, users manual) Configuration Aggregate (CA): A composite of configuration items; a complete product. Version: An instance of a configuration item (or file) at a well-defined point in time Baseline: A formal version or internal release Release: Version which is distributed to customers.
Version & Release Management
Initial Version [1.0.0]
[PC1.0.0]
[PC1.1.0]
[UNIX1.0.0]
[UNIX1.1.0]
[SUN1.1.0]
Version Control: Tracks which file belongs to which: Components: Product X consists of Module A, B, C. Versions: Product X Release L, M, or N. Variants: Product X vs. Product Y. Variant: Different product
Configuration Mgmt.
3
E.g.: UNIX version, Windows version, Mac version of an application E.g.: Aircraft versions: A319, A320, A321 Products may share configuration items or have different configuration items depending upon if code is common or different. Branch: Allows multiple users to work on a single configuration item concurrently Used for bug fixes: Branch name may include author, change request #: SLS_CR3459 May be used to implement Variants. Merge: Automated way to merge different versions of a configuration item into one version Purpose: Merge different bug-fixes into a new (releasable) version E.g. 3-way merge: Takes changes from each modified version in relation to the older, common version If two versions implement different code in the same spot then merge must be manually determined. Identification & Reporting: CIs are named and organized for retrieval, and changes are tracked. E.g.: What is the latest version of for Variant X? Which test plan was used for version Q? Which Change Requests were implemented in version Q? Which customers have been delivered version Q? Which programmers should have access to file Y? How many change requests are outstanding? What is the state of Change Request Q on File Y? Each version, release, or CI may be named as follows (for example) ProductCode.CountryCode.Release#.Version#.FileType Programming: A lock is obtained on a CI while file is being modified The programmer receives a Change Request To create a new version of a module, programmer checks the version out. Programmer must have permissions to check out the delta version. A working version is saved in programmer's private workspace for programmer's private use. The delta version of the module is locked so that no other programmer can check out the module delta. When change is completed, programmer checks the version back in, and promotes it A new delta version is created, which other programmers can read and build from. A description of the new delta version is input by the programmer. The delta version lock is removed. The state of the Change Request is promoted for release. A description of all changes and revisions is maintained by the SCM tool.
Configuration Mgmt.
4
Change Management
Change Management: Documents all change requests. Change Request: Form requesting a change to a work product Change Control Board decides which changes get implemented. Change Control Board consists of project manager (possibly with senior engineers) Change Request Form: Includes recommendation/reason for change, date requested, time expended, lines of code (LOC) changed, description of implementation, person responsible for change, state of change, and products affected. Track changes and back out of changes if necessary. Duplicate, invalid or already considered changes may be rejected or linked to previous change requests. Change Control: Changes incur the following steps: 1. Generate Change Request 2. Change Control Board approves, prioritizes and assigns the order. 3. Programmer 'checks out' item, makes change, 'checks in' item. 4. Change Control Board reviews updated Change Request(s) and schedules to Baseline 5. The Configuration Management team then builds and/or release new baseline.
System Builds
System Building: Builds an executable to run on a target configuration. Builds the system using the requested versions and/or releases, according to priority. Uses build rules to select compilers, linkers, and compile/link options. Only rebuilds source modules which have been modified or which have had their includes modified since last build with same configuration. May divvy module building to multiple servers simultaneously. Configuration Management tools are usually automated (i.e. database). Build Rules Can build releases OR with releases bug-fix branches OR latest version. To build, must specify build rules: Specify each bug-fix branch to be included in build Specify the release version to add branches to (or newest version). Build will include modified files with branches if available, otherwise released version Multiple branches on a same file will cause problems.
Configuration Mgmt.
5
Baselines
Baseline: A specification or product that the Change Control Board has formally reviewed and agreed upon, that thereafter serves as the basis for further development, and that can be changed only through formal change control procedures. Golden Copy Use of Baselines: Only tested and approved changes/code are included in a baseline. A trial baseline is regression tested before being accepted. Once an initial product level has stabilized, a first baseline is established. With each successive set of enhancements, a new baseline is established. Each baseline is retained in a permanent database together with all the changes that produced it. The baseline, (release, and version) is fully protected against changes and unauthorized use. Programmers can change modules of the baseline to produce new versions. To be able to document and reproduce the same code version and test conditions, a baseline tracks the use of exact versions: System Specification Software Project Management Plan Software Requirements Specification Preliminary User Manual & Final User Manual Design Specifications Source Code Test Specification: Plans, Procedures, Cases, Recorded results. Operation and Installation Manuals Executable Programs Database Description Maintenance Documents: Problem Reports, Change Requests Software Engineering Standards & Procedures Baseline selections should be defined by project's needs. A large project would typically require the following baselines: Requirements. Specifications: Program external specifications. Design: design and rationale for designs Software unit module: after s/w written, inspected and unit tested. Integration baseline: After unit test is completed for all modules. Operational baseline: Established at time of system shipment. Basis for subsequent shipments, repairs, and enhancements.
Configuration Mgmt.
6
SCM management
Goals of SCM as part of SEI Level 2: SCM activities are planned Selected software work products are identified, controlled, and available Changes to identified software work products are controlled Affected groups and individuals are informed of the status and content of software baselines A Software Configuration Management Plan or Standard includes descriptions of the: Select configuration management tool(s) Define software configuration items Describe processes and naming schemes to be applied for change control Describe processes and naming schemes for baselines, releases, archival via version management (including branch/version/release naming/numbering schemes); Identify role & responsibility of Configuration Controller or Configuration Control Board Define access restrictions (who gets to access what) Define reconciliation procedures (for two or more simultaneous change requests per CI) Define backup procedures for the SCM tool Different generations of tools: First Generation Tools: No integration between tools. E.g.: UNIX SCCS, RCS for revision control and make for system building Second Generation Tools: Integrated revision control, system building, no change management integration. E.g.: DSEE, Lifespan Third Generation Tools: $$$: Integrated revision control, system building, change management. E.g. Clearcase Configuration Auditing: Are SCM functions occurring as planned? Checks i...