Software Configuration Management


Published on

Principles and Practices (Msc in Software Engineering program 2002)

Published in: Technology, Business
1 Comment
No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • 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
  • 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?
  • 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.
  • 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.
  • 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.
  • Now, let’s go back to the so called accurate concept of CM.

    It is just the memo of work.
  • 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.

  • From the definition, everybody have the idea in mind. Before we move forvord, I want to emphesize that CM is not:

  • The CM covers:
  • 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.
  • 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]
  • 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.

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

  • FtpVC is a very simple shareware, which only support checkin/checkout using FTP. It does not have version label and version branch.

  • 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.
  • Visual Source Safe can integrate with Visual Studio. So the files can be checkin/checkout from Visual Studio

  • Software Configuration Management

    1. 1. Software Configuration Management Principles and Practices By Guy Davis, Stephane Saleh and Kejin Huang
    2. 2. Abstract The concept (Kejin)   Basic principles (Guy)  SCM Automation and Tools (Stephane)  SCM in the Future (Stephane)  Tools comparison (Kejin)
    3. 3. Introduction Configuration Management(CM) is a documentation system for tracking the work.
    4. 4. History 1980, Bersoff, E. H., Henderson, V.D., and  Siegel, S. G. Software Configuration Management. Prentice-Hall. 1984, The British Standard BS 6488  1987, IEEE Guide to Software Configuration  Management 1987. IEEE/ANSI Standard 1042-1987. 1987, U. S. Department of Defense. DoD  2167a Standard 1987. DoD.
    5. 5. Why SCM is needed The project body  The project may be big. When a change is made in a shared component, the user may not be notified. (The change may be a bug fix or an improvement.) The time  The development progress steps may last long. When the versions become a tree, the bugs could appear or disappear in different nodes. The people  A lot of people may be involved. A simultaneous update may destroy the others’ work.
    6. 6. The goal (why) To have change activity converge  Controlling ad-hoc change creates a stable  software development environment Control of change is a major part of baseline  management SCM co-ordinates access to change of the  software work products which is particularly important when there is more than one individual work on a software work product
    7. 7. Concept “Configuration management involves the collection  and maintenance of data concerning the hardware and software of computer systems that are being used.” [SIMON & DENNIS - Ref 1] “CM embodies a set of techniques used to help  define, communicate and control the evolution of a product or system through its concept, development, implementation and maintenance phases.” [SWEETMAN - Ref 2] “CM, a key concept in the Information Age, is a set of  systematic controls to keep information up to date and accurate.” [MORRIS - Ref 3]
    8. 8. Concept (cont’d) “A discipline applying technical and  administrative direction and surveillance to. …” (IEEE)  “A collection of hardware, software, and/or firmware, which satisfies an end- use function and is designated for configuration management.quot; (ISO)
    9. 9. What is not Just version management   Just change management  Just a build-and-release tool  An administration tool
    10. 10. The Scope
    11. 11. Principles of SCM  Configuration Identification – Baselines  Change Control  Configuration Status Accounting  Configuration Audits and Reviews – SCM metrics
    12. 12. Configuration Identification  SCM Planning document – Objectives, responsibilities, and methods  Identify configuration items: – Independent components of the system  Logical configuration hierarchy – Object-based view – Directory-based view
    13. 13. Baselines  Complete status of a CI at a given time  Know quality and functionality  Unchangeable and able to recreate Mozilla SCM Roadmap
    14. 14. Change Control  Control change between baselines  Various levels of control – Open policy (no control, just tracking) – Informal code review by module owner – Change Control Board (CCB)  Tailor level to organization and project
    15. 15. Configuration Status Accounting  Monitor status of CIs and change requests – Complete listing of all changes since last baseline (including who, what, when) – Ideally changes should be traceable to rationale  Allows tracking of progress to next baseline  Allows for previous releases/versions to be extracted for testing
    16. 16. Configuration Audits and Reviews  Validation of completeness and consistency  SCM audits occur during project transitions – Requirements, design, implementation, test, …  Ensures that SCM plan is being followed  Useful to review SCM metrics gathered  Feedback allows process improvement
    17. 17. Implementation Issues Requires champions, sponsors, agents   Requires planning (SCMP)  Requires training and documentation  Requires maintenance  Can be measured and improved
    18. 18. SCM Automation  Why Automation? - Difficult to manage developments by large teams operating at different remote sites - Projects are becoming bigger and more complex
    19. 19. SCM Automation (cont’d) (A. Brown, S. Dart, P. Feiler, K. Wallnau, 1991)
    20. 20. SCM Automation (cont’d)  Components Concepts - Component concepts help identify and access components of a software product. - Requirements covered: version control, configuration, repository, etc. - Example of tools or systems: Revision Control System (RCS), Sherpa Design Management System (DMS)
    21. 21. SCM Automation (cont’d)  Structure and Construction Concepts - Concepts that deal with capturing changes to a component and its structure. - Requirements covered: building, optimizing , recording information to allow regeneration of components, etc. - Example of tools or systems: Aide-De-Camp (ADC), Jasmine system model, Rational…
    22. 22. SCM Automation (cont’d)  Team Concepts - Concepts that help with the co-ordination and synchronization of software engineering teams working on a project. - Requirements covered: work areas for isolating work, synchronizing, concurrent work… - Example of tools or systems : Shape, Software Management System (SMS), Network Software Environment (NSE)
    23. 23. SCM Automation (cont’d)  Process Concepts - Concepts that are related to process functionalities. - Requirements covered: lifecycle support, task management, communication and automatically recording information. - Example of tools or systems : PowerFrame, ISTAR, LIFESPAN, Change and Configuration Control (CCC)
    24. 24. Tool Class 1 Code or Developer oriented CM tools only supply the code management, version control, including check-in, check-out, merge, etc.
    25. 25. Tool Class 2  Process oriented CM tools also supply management for software development activities. It may cover:  Version Control  Change Control  Product Management  Problem Tracking  Activity Tracking  Build Management  Document Management  Requirements Tracking.
    26. 26. SCM Challenges • Technological Issues • Process-Oriented Issues • Managerial Issues • Political Issues • Standardization Issues
    27. 27. SCM Challenges (cont’d) • Technological Issues - Switching CM Capabilities - Interoperability between CM - Global Perspective on CM - Repositories - Distributed CM - Perfective Maintenance Support
    28. 28. SCM Challenges (cont’d) • Process-oriented Issues • Political Issues • Standardization Issues
    29. 29. Q/A
    30. 30. Tool Index (cont’d)  FtpVC  PERFORCE  PVCS  QEF  QVCS  RAZOR  SABLIME  Software Manager (MKS)  Source Code Manager  StarTeam  TeamConnection (IBM)  TLIB  CVS
    31. 31. Comparison +1CM AccuRev AllChange CCC Change Man ClearCase   Client/server        Graphical GUI        Basic CM        commands Baselines        Report           Auto-make          Integration         with other tools Life-cycle           support Tool Class 1 2 2 2 2 1
    32. 32. Comparison (cont’d) CM Synergy CMF Code Co-op CMVS CMZ CONTROL- CS Client/server       Graphical GUI            Basic CM            commands Baselines        Report            Auto-make            Integration           with other tools Life-cycle            support Class Tool 2 2 1 2 1 1
    33. 33. Comparison (cont’d) DSM eChange FtpVC NeumaC PerFORCE PVCS   Man M+ Client/server       Graphical GUI             Basic CM Half      commands Baselines       Report             Auto-make          Integration with         other tools Life-cycle support            Class Tool 2 2 1 2 1 1
    34. 34. Comparison (cont’d) QEF QVCS RAZOR SABLI Software Source Code ME Manager Manager Client/server       Graphical GUI    Basic CM      commands Baselines       Report    Auto-make  Integration with    other tools Life-cycle   support Class Tool 2 1 2 2 2 2
    35. 35. Comparison (cont’d) StarTeam TeamConne TeamW TLIB TRUEchange ction are Client/server      Graphical GUI   Basic CM      commands Baselines      Report Auto-build  Integration with PVCS other tools SourceSafe MsProject Life-cycle support Class Tool 2 2 2 1 1
    36. 36. Comparison (cont’d) VisualEnabler Visual MainSoft Voodoo CVS SourceSafe VSS Client/server      Graphical GUI      Basic CM      commands Baselines      Report Auto-build  Integration with    other tools VisualStudio Cervisia, WinCVS Life-cycle support 1 1 1 1 1 Class Tool
    37. 37. References A. Brown, S. Dart, P. Feiler, K. Wallnau. The State of Automated Configuration  Management, Software Engineering Institute. Carnegie Mellon University. 1991. Berlack, R.H. Evaluation & Selection of Automated Configuration Management  Tools. 1995. Dart, Susan. Concepts in Configuration Management. Software Engineering Institute.  Carnegie Mellon University. 1991. abscm_concepts.html Eich, Brendan. Mozilla Tree Management Roadmap. Mozilla Organization. 2002. http://  Humphrey, Watts S. Managing the Software Process. Addison-Wesley Publishing  Company. Reading, Massachusetts. 1990 Kelly, Marion. Configuration Management: The Changing Image McGraw-Hill U.K.,  1996. Menks, D. Software Configuration Management. University Of Calgary. 2001. 