Software Configuration Management
16 likes12,566 views
This document discusses software configuration management principles and practices. It begins with an introduction to configuration management and its history. The main principles of SCM are then outlined, including configuration identification, change control, configuration status accounting, and configuration audits/reviews. The document also discusses SCM automation and tools, challenges in SCM, and provides a comparison of various SCM tools.
Editor's Notes
- #3: Hi everyone, Today’s topic is configuration management (CM). I will introduce the concept of CM. And Guy will open the door for Basic principles. Then Stephane will lead us to SCM automation and SCM tools, and also talk about the SCM future If we have time, I’ll compare the
- #4: Before we give the accurate definition of Configuration Management, I’d like to have one simple sentence to show what is the CM, so everybody can have the starting point. Configuration Management is a documentation system for tracking the work. Is that simple? The simplest CM could be a piece of paper. I can use it write down what is the problem, where I find the bug, what I’ve changed to fix the bug. That is what I do everyday. Well, somebody keep it in mind, but the information can not be shared, it could be forgotten, we say this (head) is not a CM. How long have the engineers write the memo on a piece of paper?
- #5: I tried to dig out the history of formal CM concept. The earliest one I got is 1984 British Standard. I’m pretty sure it is not the earliest one. My parent worked on computer science in 1958, I’ve pretty sure somebody has invented paper at that time so they can use.
- #6: Today, story is different. The computer has been changed. The computer project has been changed. The expectation has been changed as well. We have much bigger project. The size is bigger means more components and more shared component. When the shared component is changed, then it’s may not be a simple story on the paper anymore. We may need to notify all the shared users. The another difference is the development of the project may last longer. We have different releases, we customize the project for different customer. The binder get thicker and thicker and we get harder to find the original paper. We have much more people involved in the project. When multiple people work in some component simultaneously, it always has problem to overwrite each other’s.
- #7: So what we want? A fantastic(expensive) CM system is not our goal. It is just a tool. We want the tool to help us to have our change activity converge, so we can have a stable product to deliver.
- #8: Now, let’s go back to the so called accurate concept of CM. It is just the memo of work.
- #9: The IEEE definition is very interesting. It has 3 key words: Technical, administrative, and surveillance. It tends to fit the CM concept to the organization. It is not just a technical issue, it also help the administrator to understand the scope of the target, the problem and current status. And it also supply a evaluation framework to check the work.
- #10: From the definition, everybody have the idea in mind. Before we move forvord, I want to emphesize that CM is not:
- #11: The CM covers:
- #12: Mention that each component builds somewhat upon the next. The last item is optional and the overall process should be tailored for the specific organization.
- #13: Configuration Item definition: Any part of the development and/or deliverable system (whether software, hardware, firmware, drawings, inventories and/or documentation) which needs to be independently identified, stored, tested, reviewed, used, changed, delivered and/or maintained. CIs can differ widely in complexity and may contain other CIs in a hierarchy. [Kelly, 1996]
- #14: 1. Known Functionality: The features and functions of a particular baseline will be documented and available for reference. 2.Known Quality: The quality of a baseline will be well defined. For example, all known bugs will be documented and the software will have undergone a complete set of testing before being released. 3.Unchangable: A baseline, once defined, cannot be changed. The list of the CIs and their versions are set in stone. Any changes may become a new baseline, but the existing baseline does not change. 4.Recreatable: All the CIs comprising the baseline can be recreated at any point in time. This is critical for maintaining development, testing, and multiple release versions. An example baseline for a software configuration item may include the current level of: [Humphrey, 1990] *Each module including source code. *Each test case including source code. *Each build tool used including the compiler. *Each data set including both test and operational data. *Each macro, library, and API (header files). *Each instalation or operating procedure.
- #15: Information considered by the Change Control Board * Size: typically in lines of code (LOC). *Alternatives: consideration of other approaches to problem. *Complexity: will the change affect many modules? *Schedule: affect on other jobs *Impact: future considerations on design *Cost: weigh potential costs versus savings. *Severity: importance of making the change. *Relation to other changes: synergies or conflicts *Test: any special test requirements *Resources: are people available to do work? *System impact: will this affect performance characteristics? *Benefits: special reasons to make this change? *Politics: accommodation of an important user? *Change maturity: length of time this change has been under consideration.
- #16: The following information is required to accurately account for a configuration item's status: [Humphrey, 1990] *The time at which the baseline was established. *The time at which each CI and change was included in the baseline. *A description of each CI. *The current status of each software-related engineering change. *The description of each software change. *The status of each software change. *The documentation status for each baseline. *The changes planned for each identified future baseline.
- #17: Possible Change Metrics - Change frequency: indicates error-prone modules - Total number of changes completed - Average change completion time - Number of outstanding changes (per module) Also mention that these SCM metrics are also used by size and cost estimators.
- #18: SCM is common to all process change in that it requires: Champions: initiate change process and bring it to the attention of management. Sponsors: senior management must provide support and resources Agents: responsible for actually planning and implementing the change SCMP: outlines objectives, responsibilities, and the approach and methods to be used Outline in brief CVS at Pason: Requirements and planning doc (cross-platform) System configuration How-to docs and FAQ-o-matic Sysadmin and backup
- #34: FtpVC is a very simple shareware, which only support checkin/checkout using FTP. It does not have version label and version branch.
- #36: Stephane talked one of the challenge is to transfer the CM data between the different CM system. StarTeam does very well here. StarTeam can exchange the data with other CM tool (PVCS, SourceSafe) StarTeam also can export the data to Microsoft Project, so it helps the project planning part of Software Engineering.
- #37: Visual Source Safe can integrate with Visual Studio. So the files can be checkin/checkout from Visual Studio