2. Configuration Management
Total Page:16
File Type:pdf, Size:1020Kb
Computer Science and Software Engineering University of Wisconsin - Platteville 2. Configuration Management Yan Shi SE 3730 / CS 5730 Lecture Notes Outline . What is configuration management? — Identification — Change control — Status accounting — Audit and review . CM techniques and practices — lock-modify-unlock — copy-modify-merge — RCS — branching — deltas . CM tools Why is CM needed? . ``This worked yesterday and doesn't work now.” What happened? . ``The user manual says to do this, but when I do it, something different happens.'' Which is correct, the manual or the code? Why was one changed? . ``The code changes that I made last week are no longer in the code.” What happened to the fix? Who changed the code and Why? . ``The listing doesn't match what the program does!'' Which is correct? . ``Did the bug get fixed in this copy, too?'' Why is CM needed? . Control the changes — Versions of documents need to be combined to form a product, or configuration — With many people working on many files, inconsistencies can occur . Required for testing — We must know and control what source was used to produce a software system in order to know what is being tested — We need to be able to build and rebuild a software system reliably . Reduce the quality cost — https://www.youtube.com/watch?v=Ij1yDpfZI8Q CM CONCEPTS AND COMPONENTS What is Configuration Management? . Software CM is a discipline for managing the evolution of software systems throughout all stages of the software life cycle. SCM is a component of SQA system. — Infrastructure component — Organizational framework . SQA teams are often required to take the responsibility of managing the CM system. Support, Control and Service . Support — Developers, organization, customer . Control — Specifications, documents, software, and other deliverables . Service — “SCM is a service provider in that it supports people and controls data.” SCM functional areas . Identification — identify components, structure . Control: — control releases and changes . Status accounting — record, report status . Audit and review — validate completeness Configuration identification . What is the configuration of my system? . What version of the file is this? . What are the components of the system? . Version control is involved during identification. Prerequisite for other CM functionalities Software configuration item . Software configuration item (SCI): — An approved unit of software code, a document or piece of hardware that is designed for configuration management and treated as a distinct entity in the SCM process. — The main criterion: whether needed for future development or maintainace . Each SCI must have a unique and consistent name: — Augment the name with various attributes such as type of document, OS, language, etc. — It is a terrible practice to have an SCI change name for each version. Use a consistent name and let the CM system to handle versions. main09-01-2015a.cpp, main09-01-20145.cpp, main09-02-2015a.cpp main.cpp Typical SCI . Documents — development plan, requirement specifications, design specifications, database description, test plan, test report, user manuals, maintenance plan, change requests, CM plan, version description, standards, etc. Software code — source code, prototype . Data files — parameters, codes, etc. — test cases and test scripts . Software development tools — compilers, debuggers, linkers, etc. — CASE tools Version . SCI version: — The approved state of an SCI at any given point of time during the development and maintainace process. Software configuration version: — An approved selected set of documented SCI versions that constitute a software system or document at a given point of time, where the activities to be performed are controlled by SCM procedures. — The software configuration versions are released according to the cited procedures. Identification activities . Select items to be placed under control SCIs . Identify which version of a SCI can or cannot be included in a working release . Uniquely identify various versions of the software . Define relationships and interfaces between various software products . Release configuration documentation . Establish controlled repositories . Establish configuration baselines Configuration baselines . Configuration baseline is a fixed reference configuration established by defining and recording the approved SCI at a milestone event or at a specified time. Each configuration baseline serves as a point of departure for future SCI changes. — Baselines for different SCIs may occur at different times, (e.g., requirement baselined before code) — Once an SCI is baselined, modifications are strictly controlled by CM policies. — Incremental baselines occur sequentially over the life cycle. Typical Baseline Progression http://www.chambers.com.au/glossary/baseline.php Configuration change control . What is controlled? . How are the changes to the products controlled? . who controls the changes? . when are the changes accepted, received, and verified? . Configuration change control makes sure the product is in a consistent state and enforces access control Access control . We don’t want multiple people writing to the same file concurrently. Different groups in an organization play different roles with respect to the development process. — Coders and testers need read access to requirements, but they should not be permitted to directly change them. — Marketing and requirement engineers should be able to write requirements, but not change code. — Quality Assurance Engineers should have write access to test cases, but coders should not be able to change test cases. Change Control . Change control: a process for proposing, evaluating(feasibility, marketability, economics, risks, etc.) and changing an existing system. Types of changes: — Defects fixing — Enhancement — Ports: modifying a system so that it can run in different environments. Change control process . A generic change control process [Berlack 1992] Software changes Analyze and assess impact Software enhancement Prepare change proposal Problems Evaluate Control Board change proposal Incorporate Yes No Archive Approve change change Supply Verify change feedback to originator end Configuration Control Board . CCB is a committee of many stakeholders — sales, marketing — development — quality assurance — customer support who meet regularly to execute this change control process. Standard Change Request Form http://www.projectmanagementdocs.com/project-documents/change-request.html Change control policies . Who can initiate the change requests . criteria for placing an SCI under formal change control . The “change impact” analysis expected for each requested change . How revision history should be kept . The check-in/check-out procedure . Procedure to approve changes . How change requests are tracked and resolved . The reviews and regression tests required . The procedure to update all affected software life cycle components to reflect the approved changes Configuration status accounting . Accounting is the art of recording, summarizing, reporting, and analyzing financialthe change transactions. process . What is the status of an SCI? . Which version of an SCI implements an approved change request? . What is different about a new version of a system? . How many faults are detected and how many are fixed each month? . What is the cause of the change? Typical Configuration Status Report . A list of the configuration items that comprise a baseline . The date when each version of each configuration item was baselined . A list of the specifications that describe each configuration item . The history of baseline changes including rationales for change . A list of open change requests by configuration item . Deficiencies identified by configuration audits . The status of works associated with approved change requests by CI. Configuration auditing . Is a change properly resolved? . Does the system satisfy the requirement? . Are all changes incorporated in this version? . Configuration auditing verifies that the software product is built according to the requirements, standards, or contract agreement. Informal and formal audits . Informal audits are performed at key phases of the software life cycle. Reviews . Two formal audits are conducted before the software is delivered to the customer: — functional configuration audit (FCA) validate the system against the requirement — physical configuration audit (PCA) whether the design and reference documents represent the software that was built. CM TECHNIQUES History of SCM techniques . 1960s: — change and configuration control concepts (UCSB); . 1970s: — diff algorithm (by bell labs) — SCCS(Source Code Control System by bell labs ); . 1980s: — RCS (Revision Control System) : only for single files — CVS (Concurrent Version System) . 2000: Subversion . now: distributed revision control systems (git) Software Repository . Sources files reside in a software repository. — once it has been added to the repository, it becomes subject to version control. — version control tools are responsible for managing the repository. A.K.A. project databases or project libraries. Workspace . Each team member has a workspace, which is designed to prevent members from interfering with each other’s work. — When a change to a document is required, it is checked out to a team member’s workspace. — Any changes made in the workspace don’t affect the repository. — Test/review the document and then check it in. changed documents are copied back into