software configuration management


Published on

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

No notes for slide

software configuration management

  2. 2. Some Sources • Ahmad K. Shuja, Jochen Krebs. IBM Rational Unified Process Reference and Certification Guide—Solution Designer. IBM Press, 2008. • Bellagio, David E. Milligan, Tom J. Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction. Addison Wesley Professional, 2005. • Aiello, Bob. Sachs, Leslie. Configuration Management Best Practices. Addison Wesley Professional, 2011. • Kemper, Chris; Oxley, Ian. Foundation Version Control for web developers. Friendsfot Apress, 2012. • Londoño & Lozano, EAFIT University, 2010.
  3. 3. Before….. Think about relation between:
  4. 4. Before… We must remember always… Software is bounded only by the limits of the human imagination. Uncontrolled and undirected, imagination can quickly give rise to nightmare
  5. 5. Definition Software Configuration Management (SCM) is a software-engineering discipline comprising the tools and techniques (processes or methodology) that a company uses to manage change to its software assets.
  6. 6. Software Configuration Management is how you control the evolution of a software project
  7. 7. IEEE Standard 828 (1983, 1998, 2005, 2008, 2012). The minimum required contents of a Software Configuration Management Plan (SCMP) are established, and the specific activities to be addressed and their requirements for any portion of a software product's life cycle are defined.
  8. 8. IEEE Standard 828. SCM constitutes a good engineering practice for all software projects, whether phased development, rapid prototyping, or ongoing maintenance. It enhances the reliability and quality of software by (next..)
  9. 9. IEEE Standard 828 1. Providing structure for identifying and controlling documentation, code, interfaces, and databases to support all life-cycle phases 2. Supporting a chosen development/maintenance methodology that fits the requirements, standards, policies, organization, and management philosophy 3. Producing management and product information concerning the status of baselines, change control, tests, releases, audits, etc
  10. 10. According with SWEBOK 2014 Chapter 6 Configuration management (CM) is the discipline of identifying the configuration of a system at distinct points in time for the purpose of systematically controlling changes to the configuration, and maintaining the integrity and traceability of the configuration throughout the system life cycle.
  11. 11. Come back to IEEE 828 Chapter 6 A discipline applying technical and administrative direction and surveillance to: identify and document the functional and physical characteristics of a configuration item, control changes to those characteristics, record and report change processing and implementation status, and verify compliance with specified requirements
  12. 12. According with SWEBOK 2014
  13. 13. IEEE Standard 828. Configuration: • The configuration of a system is the functional and physical characteristics of hardware or software as set forth in technical documentation or achieved in a product. • It can also be thought of as a collection of specific versions of hardware, firmware, or software items combined according to specific build procedures to serve a particular purpose
  14. 14. Some CM standards and models • IEEE 828 • IEEE 1704 (1997) • IEEE 12207 Software Life Cycle Processes • CMMI • NTC-ISO-10007 como Administración de la calidad – Directrices para la Administración de la Configuración…
  15. 15. Configuration Item  Any selected artifact (file) or set of selected artifact to manage its configuration and be treated as a single entity. Example: code, executable objects, scripts, documents, etc.  An aggregation of hardware, software or both kinds of components, designated for configuration management and treated as one entity in the management process (IEEE Std 610.12).  An aggregation of work products selected for configuration management and treated as a single entity in the process(CMMI).
  16. 16. Software Configuration: • Physic and functional features of the software exposed in a technical documentation or reached in a product (IEEE) • Set of controlled configuration items, at a given moment of time (CMMI)
  17. 17. Versions and Variants One version is an instance of a configuration item or a system that differs in some form of another instance. Predecessor - Successor Record The variants are equivalent versions in functionality but differ in hardware or software environment
  18. 18. Phase Version • Pla 1.0 1.1 • Req 1.0 1.1 1.2 • Ana 1.0 1.1 • MD 1.0 1.1 • Cod 1.0 1.1 1.2 1.3 LB 0.0.1 1.3 1.2 1.4 LB 0.0.2
  19. 19. • Branching • Build • Release • Delta
  20. 20. • Build: Combination of components of a system in executable components in a target configuration. • Release: More than just the executable code, it includes installation files, data, settings, release notes and manuals. They are created for external use • Delta: it is used to recover the history of an item. Difference between the new version and the previous.
  21. 21. Baseline Specification or product that has been formally reviewed and approved, provides a basis for future development and can only be changed through a formal change control. IN OUT Controlled Enviroments LB 0.0.1 Power Factor Correction
  22. 22. Baselines are used to track the software configuration at a discrete point in time
  23. 23. About Baselines – RUP A baseline is a 'snapshot' in time of one version of each work product in the project repository. It provides an official standard on which subsequent work is to be based, and to which only authorized changes can be made. After an initial baseline is established every subsequent change to a baseline is recorded as a delta until the next baseline is set. The three main reasons for creating baselines are reproducibility, traceability, and reporting.
  24. 24. Rule of Baselines baselines should be created at the end of each project iteration
  25. 25. SCM Best Practices • Identify and store artifacts in a secure repository. • Control and audit changes to artifacts. • Organize versioned artifacts into versioned components. • Organize versioned components and subsystems into versioned subsystems. • Create baselines at project milestones. • Record and track requests for change.
  26. 26. SCM Best Practices • Organize and integrate consistent sets of versions using activities. • Maintain stable and consistent workspaces. • Support concurrent changes to artifacts and components. • Integrate early and often. • Ensure reproducibility of software builds.
  27. 27. Be Careful SCM component is a set of related files and directories that are versioned, shared, built, and baselined as a single unit ¿?
  28. 28. Be Careful
  29. 29. Be Careful Change request management involves tracking requests for changes to a software system. These requests can result from defects found by a testing organization, defects reported by customers, enhancement requests from the field or customers, or new ideas produced internally.
  30. 30. SCM Tools • SCM tools are software tools that automate and facilitate the application of the SCM best practices. • It is unrealistic to try to maintain effective SCM without an SCM tool. • The goal of successful SCM is to allow as much change as possible while still maintaining control of the software. SCM tools help automate tedious, manual, and error-prone pieces of the SCM process, and can ensure that your project can support all of the SCM best practices.
  31. 31. SCM Tools Examples • CVS • Subversion • Bugzilla • Mantis • IBM Rational ClearCase • GIT
  32. 32. SCM Tools Examples (web–Collaborative!) • GitHub • GoogleCode • Gforge • Jazz • Microsoft Team Foundation Server • …
  33. 33. SCM Tools Basic Functions • To maintain a library or repository of files • To create and store multiple versions of files • To provide a mechanism for locking (to enforce serialized change to any given file) • To identify collections of file versions • To extract/retrieve versions of files from the repository
  34. 34. Basic operations (Note: check-in - commit)
  35. 35. SCM Process • A process defines the steps by which you perform a specific task or set of tasks. An SCM process is the way SCM is performed on your project specifically, how an SCM tool is applied to accomplish a set of tasks. • A key mistake most people make is to assume that an SCM tool will, in and of itself, solve their SCM problems or support their SCM requirements. How you apply the SCM tool to your development environment is called the usage model, or SCM process. It is this model or process that will in part determine how successfully you address your SCM issues.
  36. 36. Unified Change Management • is a software-configuration management process for software development that spans the development life cycle, managing change to requirements, design models, documentation, components, test cases, and source code • Fundamental to UCM is the unification of the activities used to plan and track project progress with the artifacts being changed • Implementation of the UCM model is realized by both process and tools
  37. 37. UCM Process Source: Chapter 3 - Bellagio, David E. Milligan, Tom J. Software Configuration Management Strategies and IBM® Rational® ClearCase® Second Edition A Practical Introduction. Addison Wesley Professional, 2005
  38. 38. Unified Change Management UCM was derived from observed best practices in thousands of development organizations that demonstrated a capability to develop software in a robust, scalable, and repeatable way. By automating these best practices, UCM provides value to a development organization in many ways, but four areas are key: • Abstraction: we work best on higher-level tasks • Communication: about individual activities, relieving developers of the burden of remembering the specific files and versions they created to fulfill activities on which they worked
  39. 39. Unified Change Management • Stability: the project progresses in a known, controlled way with markers placed along the way to denote intermediate stable points • Control: mechanisms to assist in managing the flow of changes from a developer's isolated development stream to a project-integration area or to other developers; tracking, managing, and controlling the flow of changes from the project's integration area or from other developer's streams; and assisting in integrating those changes
  40. 40. UCM Process Overview
  41. 41. A new role… The configuration manager is familiar with an organization's configuration and change-management processes and with the SCM tools being used. The configuration manager is responsible for creating and maintaining the physical infrastructure necessary to implement the design. This primarily involves creating and maintaining repositories and importing existing files and directories. (In some organizations the configuration manager is also responsible for things such as disk space allocation, network resources, and backup strategies as they relate to SCM data. The process described here allocates these activities to the system administrator.)
  42. 42. The Architect: Defining the Implementation Model
  43. 43. The Configuration Manager: Setting Up the SCM Environment
  44. 44. The Project Manager: Managing a Project
  45. 45. The Developer: Joining a Project and Doing Development
  46. 46. The Integrator: Integration, Build, and Release
  47. 47. Finally UCM provides the software-configuration management tools and processes to achieve effective, efficient software development. It does this by building upon a model that unifies the activities and artifacts upon which projects are built and progress. This model serves to raise the level of abstraction at which development is done; to provide stability for projects and individual contributors; to manage, track, and control the flow of changes in a project; and, finally, to provide facilities for automated project metrics as well as real-time communication about a project's activities and artifacts. You have seen that the UCM process can be described in terms of five roles: the architect, the configuration manager, the project manager, the developer, and the integrator.
  48. 48. IEEE 828 propose a structure for a SCM Plan; it must constains: Introduction Describes the purpose of the plan, the scope of its application, the key terms and references SCM Management Who - Indicates the responsibilities and authority to carry out the activity plan SCM Activities How - Indicates all activities to be performed in the application to the project SCM Shedule When - Indicates the required coordination of SCM activities with other activities in the project SCM Resources What - Indicates the tools, human and physical resources to implement the plan SCM Maintance Plan Indicates how the plan will be maintained during its application IEEE-828 SCM Plan
  49. 49. Introducción Describir el sistema o los ítems de configuración a los cuales se les aplica el plan, además el propósito del plan y los documentos relacionados y aplicables en orden de prioridad Políticas y procedimientos Incluir los elementos de la administración de la configuración que estén acordados. Se deben definir las políticas, organización y las responsabilidades, criterios para selección de los IC y la frecuencia y control de los informes. Identificación de la configuración Se recomienda elaborar un árbol de la familia de IC con las especificaciones, convención de numeración, las líneas base por ser establecidas. Control de la configuración Indicar la organización, composición y téminos de JC y su relación con otras juntas. Además se debe especificar los procedimientos para el control de cambios. Recuento del estado de la configuración Definir los procedimientos para recolectar los registros y como se deben mantener los datos necesarios para producir informes. Auditoría de la Configuración Se debe incluir la lista de auditorías a realizar, los procedimientos de auditorias y las autoridades y disciplinas involucradas. Plan según propuesta de NTC-ISO 10007
  50. 50. You must remember… • SCM is a strategic practice oriented to products, projects and organization, helping to reduce the chaos. • With tools only, we can only achieve to automate processes, so the organization obtain low-quality products faster • SCM allows the improvement of product quality, understanding and knowing how it should be implemented in projects (it is a critical success factor). • Tools are used to benefit the SCM implementation, but have it without having done a previous training, without defined policies and without established metrics, is a practice that leads to the automation of chaos.