Introduction To Software Configuration Management


Published on

Configuration management (CM) is a field of management that focuses on establishing and maintaining consistency of a system's or product's performance and its functional and physical attributes with its requirements, design, and operational information throughout its life.[1] For information assurance, CM can be defined as the management of security features and assurances through control of changes made to hardware, software, firmware, documentation, test, test fixtures, and test documentation throughout the life cycle of an information system.

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

No notes for slide

Introduction To Software Configuration Management

  1. 1. Introduction to Software Configuration Management scmGalaxy Author: Rajesh Kumar [email_address]
  2. 2. Intro to SCM: Table of Contents <ul><li>Purpose of This Presentation </li></ul><ul><li>General Definition of SCM </li></ul><ul><li>List of Components for SCM </li></ul><ul><li>Detailed Description of the SCM Components </li></ul>
  3. 3. Intro to SCM: Purpose of This Presentation <ul><li>There are a number of definitions of SCM out there. Everyone has their own idea of what it means. </li></ul><ul><li>The purpose of this presentation is twofold: </li></ul><ul><ul><li>to describe what is involved in Software Configuration Management (SCM) in the BASA environment, and </li></ul></ul><ul><ul><li>to help the SCM practitioner look beyond the SCM tasks to understand the spirit and reasoning behind those tasks and to learn to think in SCM terms. </li></ul></ul>
  4. 4. Intro to SCM: General Definition of SCM in Nova <ul><li>In general, the purpose of SCM is to manage and control changes to the Customer’s software assets. </li></ul><ul><li>This includes the following three principle areas: </li></ul><ul><ul><li>Manage the Software Process, </li></ul></ul><ul><ul><li>Perform the Compile/Build Function for the Software, and </li></ul></ul><ul><ul><li>Packaging the Software for delivery into the Customer’s production environment. </li></ul></ul>
  5. 5. Intro to SCM: List of Components for Nova SCM The following page contains the list of the components of SCM.
  6. 6. Intro to SCM: List of Components for Nova SCM <ul><li>Configuration Identification </li></ul><ul><li>Configuration Control </li></ul><ul><li>Status Accounting and Audits </li></ul><ul><li>Baselines </li></ul><ul><li>Build Management </li></ul><ul><li>Process Management </li></ul><ul><li>Packaging Management </li></ul><ul><li>Teamwork </li></ul><ul><li>SOX Compliance </li></ul>
  7. 7. Intro to SCM: Detailed Description of the SCM Components <ul><li>The following slides describe each of the SCM Components in more detail. </li></ul>
  8. 8. Intro to SCM: Configuration Identification <ul><li>Configuration Identification – To be able to determine the components of the Software Product. </li></ul><ul><ul><li>What is the Software Product? You cannot manage or control something if you don’t know what it is. </li></ul></ul><ul><ul><li>Configuration Identification is the process of determining the scope of the Software Product. </li></ul></ul><ul><ul><li>We must have a list of the components that make up the Software Product, including all user and project documentation. </li></ul></ul><ul><ul><li>The components within the scope are known as Configuration Items, or CIs. </li></ul></ul>
  9. 9. Intro to SCM: Configuration Control <ul><li>Configuration Control – Control changes to the Software Product. </li></ul><ul><ul><li>SCM requires that we manage and control all changes to the Software Product so that we know exactly what changes have been applied. </li></ul></ul><ul><ul><li>We must ensure that no unauthorized changes are made. </li></ul></ul><ul><ul><li>We must ensure that every authorized change is made by following a well-defined change process. </li></ul></ul>
  10. 10. Intro to SCM: Status Accounting and Audits <ul><li>Status Accounting and Audits – Know the current state of all components in the Software Product and which are affected by what change request. </li></ul><ul><ul><li>Status Accounting is used to track the progress of changes to the Software Product associated with a project. </li></ul></ul><ul><ul><li>Audits are used to ensure the integrity of the scope of the project. </li></ul></ul>
  11. 11. Intro to SCM: Status Accounting and Audits (cont’d) <ul><li>Status Accounting </li></ul><ul><ul><li>The Status Accounting process tracks baselines, work requests, and the inventory of current CIs. </li></ul></ul><ul><ul><li>The purpose of Status Accounting is to provide project status throughout the development process and to maintain a living documentation of the changes in status of all CIs. </li></ul></ul>
  12. 12. Intro to SCM: Status Accounting and Audits (cont’d) <ul><li>Audits </li></ul><ul><ul><li>SCM audits verify that the software product satisfies the baselined requirements and ensures that what is built is what is actually delivered. </li></ul></ul><ul><ul><li>SCM audits also ensure that traceability is maintained between all CIs and that all work requests are associated with one or more CI modifications. </li></ul></ul><ul><ul><li>SCM Audits are the “watchdogs” that ensure that the integrity of the project’s scope is preserved. </li></ul></ul>
  13. 13. Intro to SCM: Baseline <ul><li>Baseline – Create the ability to easily re-construct earlier versions of the Software Product. </li></ul><ul><ul><li>A baseline is a snapshot in time of the Software Product or documentation. </li></ul></ul><ul><ul><li>We “take a baseline” at every point in the process that we want to be able to get back to. </li></ul></ul><ul><ul><li>A baseline might be as simple as taking a Harvest Snapshot or certifying a version of a product and moving it to a specified directory. </li></ul></ul>
  14. 14. Intro to SCM: Build Management <ul><li>Build Management – Ensure that the components of the Software Product were built/compiled or distributed directly from the code repository without opportunity for unauthorized changes. </li></ul><ul><ul><li>This is the process of extracting the Software Product source from the version control tool, compiling it, and storing it in a secure location. </li></ul></ul><ul><ul><li>The key is to ensure that the SCM Team knows exactly where the source code came from, what is included, and can certify that it was not tampered with by unauthorized persons. </li></ul></ul>
  15. 15. Intro to SCM: Process Management <ul><li>Process Management – Ensure that the Software Product that goes into Production is the same as the Software Product that was tested. </li></ul><ul><ul><li>Process Management is designing, establishing, and maintaining a consistent development process that meets the needs of the development team while allowing the changes to the Software Product to be controlled and tracked. </li></ul></ul><ul><ul><li>Process Management for an application is defined in the SCM Plan, which is developed and owned by the SCM Team. </li></ul></ul><ul><ul><li>Process Management is also the act of protecting the Software Product from being modified by circumventing the defined process. </li></ul></ul>
  16. 16. Intro to SCM: Process Principle #1 The following four slides illustrate one of the most effective SCM process principles used in the BASA applications today. For applications that do not have a well-defined development process, implementing this principle will usually cut their defect rate significantly.
  17. 17. Intro to SCM: Process Principle #1 – The Right Way Access to modify code is only allowed in the Development State. There is no opportunity to circumvent the process downstream.
  18. 18. Intro to SCM: Process Principle #1 – The Right Way The Development Team has read-only access to the Test and subsequent environments. Once Code enters the Test State, it is not touched again by the Development Team.
  19. 19. Intro to SCM: Process Principle #1 – The Wrong Way Code moved from environment to environment without process circumvents the development process. Code should only be promoted through the Version Control Tool.
  20. 20. Intro to SCM: Process Principle #1 – The Right Way Code should only be promoted through the Version Control Tool, not from environment to environment.
  21. 21. Intro to SCM: Packaging Management <ul><li>Packaging Management – Ensure that the Software Product is packaged/prepared for Production in a standardized and consistent manner. </li></ul><ul><ul><li>Once the Software Product has been built, it must be packaged for delivery to the production environment. </li></ul></ul><ul><ul><li>Package management means having a standard and consistent process for preparing the Software Product for installation, so that installations are consistent and the chances of installation problems are reduced. </li></ul></ul>
  22. 22. Intro to SCM: Teamwork <ul><li>Teamwork – Work with each Project Team to provide the appropriate amount of SCM process for each application, balancing risk, expediency, and funding. </li></ul><ul><ul><li>The SCM needs for a large, critical application are different from that of a small non-critical application. </li></ul></ul><ul><ul><li>Designing and maintaining process costs money. The goal is to use enough process to reduce the risk to an acceptable level. </li></ul></ul><ul><ul><ul><li>Too much process introduces excessive costs. </li></ul></ul></ul><ul><ul><ul><li>Too little process introduces excessive risks. </li></ul></ul></ul>
  23. 23. Intro to SCM: Teamwork (cont’d) <ul><li>Teamwork – </li></ul><ul><ul><li>The SCM Team works with all of the other teams to determine the appropriate level of process. Again the Development Process is described in the SCM Plan. </li></ul></ul><ul><ul><li>Too much process strangles and slows the development process. </li></ul></ul><ul><ul><li>Not enough process allows recurring defects, unauthorized changes, and, in the extreme, unexplained changes to the production environment. </li></ul></ul><ul><ul><li>The SCM Team involve the other teams in developing the process so they understand the reason for each part of the process. </li></ul></ul>
  24. 24. Intro to SCM: Teamwork (cont’d) <ul><li>Teamwork – </li></ul><ul><ul><li>Some keys to developing the appropriate amount of process: </li></ul></ul><ul><ul><ul><li>Start out the process design with too much process. Design tight controls for every part of the development process. The idea is that it is easier to loosen up later than to tighten up. </li></ul></ul></ul><ul><ul><ul><li>Examine each part of the process to determine the benefit it brings. If you cannot qualify the benefit of a process, then you probably should not implement it. </li></ul></ul></ul><ul><ul><ul><li>Look for gaps in the defined process and close them. These gaps usually represent ways to circumvent the process. </li></ul></ul></ul>
  25. 25. Intro to SCM: SOX Compliance <ul><li>SOX Compliance – Ensure that all changes to Software Products are conducted according to BellSouth’s SOX directives. </li></ul><ul><ul><li>As a publicly traded corporation, BellSouth is bound by US law to comply with SOX guidelines. </li></ul></ul><ul><ul><li>The SCM Team participates in SOX compliance and is obligated to report any SOX violations to the SOX Auditing Team. </li></ul></ul><ul><ul><li>All applications must have a process for providing the appropriate SOX artifacts to substantiate our Customer’s compliance with the SOX guidelines. </li></ul></ul>
  26. 26. Thank You ! Author: Rajesh Kumar [email_address]