logging in or signing up SCM ankush85 Download Post to : URL : Related Presentations : Share Add to Flag Embed Email Send to Blogs and Networks Add to Channel Uploaded from authorPOINT lite Insert YouTube videos in PowerPont slides with aS Desktop Copy embed code: Embed: Flash iPad Dynamic Copy Does not support media & animations Automatically changes to Flash or non-Flash embed WordPress Embed Customize Embed URL: Copy Thumbnail: Copy The presentation is successfully added In Your Favorites. Views: 2019 Category: Education License: All Rights Reserved Like it (4) Dislike it (0) Added: March 06, 2009 This Presentation is Public Favorites: 1 Presentation Description No description available. Comments Posting comment... Premium member Presentation Transcript Software Configuration Management : 1 Software Configuration Management Software Configuration Management : 2 Software Configuration Management Definition 1. Software Configuration Management (SCM) is the discipline of controlling the evolution of software systems. 2. Roger Pressman says that SCM is a "set of activities designed to control change by identifying the work products that are likely to change, establishing relationships among them, defining mechanisms for managing different versions of these work products, controlling the changes imposed, and auditing and reporting on the changes made." Slide 3: 3 Wayne Babich describes SCM as "the art of identifying, organizing, and controlling modifications to the software being built by a programming team. It maximizes productivity by minimizing mistakes." Why is it needed? : 4 Why is it needed? Software changes constantly. Change causes chaos. SCM helps prevent change chaos: Tracks development history, Prevents or reconciles conflicting changes, Tracks configurations and baselines, Tracks error reports and fixes, Automates configuration selection, keeps software in well-defined state. SCM is indispensable for the development and maintenance of large, long-lived software. Symptoms of the Change Chaos : 5 Symptoms of the Change Chaos Problems of identification and tracking: “This program worked yesterday. What happened?” “I fixed this error last week. Why is it back?” “Where are all my changes from last week?” “This seems like an obvious fix. Has it been tried before?” “Who is responsible for this change?” Problems of version selection Software Delivery Problems Why Is SCM Important? : 6 Why Is SCM Important? CM enhances the ability to provide maintenance support necessary once the software is deployed. The National Institute of Standards and Technology (NIST) says that software will be changed to adapt, perfect, or correct it. Pressman points out that new business, new customer needs, reorganizations, and budgetary or scheduling constraints may lead to software revision. It helps to eliminate confusion, chaos, double maintenance, the shared data problem. Who Is Involved in SCM? : 7 Who Is Involved in SCM? Virtually everyone on a software project is affected by SCM. From the framers of the project plan to the final tester, we rely on it to tell us how to find the object with the latest changes. During development, when iterations are informal and frequent, little needs to be known about a change except what it is, who did it, and where it is. Who Is Involved in SCM? (Contd..) : 8 Who Is Involved in SCM? (Contd..) In deployment and baselining, changes must be prioritized, and the impact of a change upon all customers must be considered. A change control board (CCB) is the governing body for modifications after implementation. How Can Software Configuration Be Implemented in Your Organization? : 9 How Can Software Configuration Be Implemented in Your Organization? We used to say, "Make a plan and stick with it—never waffle," and "Requirements must be frozen—how else will we know what to code?" Now, we say, "Plans are living documents—they will be in a continual state of change as project knowledge increases." We now know that requirements are never frozen—they merge, evolve and become expanded, enhanced, and extended. As long as artifacts of software development can undergo change, we will need some method of managing the change. How Can Software Configuration Be Implemented in Your Organization? (Contd..) : 10 How Can Software Configuration Be Implemented in Your Organization? (Contd..) Because SCM is such a key tool in improving the quality of delivered products, understanding it and how to implement it in your organization and on your projects is a critical success factor. The SCM provide you with a composite SCM plan template for use in any of your projects. The issues and basics for a sound SCM system are as follows: How Can Software Configuration Be Implemented in Your Organization? (Contd..) : 11 How Can Software Configuration Be Implemented in Your Organization? (Contd..) The four basic requirements for an SCM system SCM principles Planning and organizing for SCM SCM Tools Benefits of SCM Path to SCM implementation The Four Basic Requirements for an SCM System : 12 The Four Basic Requirements for an SCM System Identification, Control, Audit, and Status Accounting are the four basic requirements for a software configuration management system. These requirements must be satisfied regardless of the amount of automation within the SCM process. An SCM tool, a tool set, or a combination of automated and manual procedures may satisfy all four. Identification : 13 Identification Each software part is labeled so that it can be identified. Furthermore, there will be different versions of the software parts as they evolve over time, so a version or revision number will be associated with the part. The key is to be able to identify any and all artifacts that compose a released configuration item. Think of this as a bill of materials for all the components in your automobile. When the manufacturer realizes that there has been a problem with parking brakes purchased from a subcontractor, it needs to know all the automobile models using that version of the parking brake. It is the same with software. Identification (Contd..) : 14 Identification (Contd..) If we are building a multimedia system that has audio MPEG3 drivers for Windows 98, Windows 2000, Windows CE, Linux, and FreeBSD operating systems, how do we find out which releases are impacted when we find an error in the Linux product? You must go back to your SCM system to identify all the common components in all operating system releases that are impacted. Control : 15 Control In the context of configuration management, "control" means that proposed changes to a Configuration Item (CI) are reviewed and, if approved, incorporated into the software configuration. The goal is to make informed decisions and to acknowledge the repercussions associated with a change to the system. These changes may impact budgets, schedules, and associated changes to other components. Control (Contd..) : 16 Control (Contd..) If a problem is reported in a released product, software engineers must act quickly to evaluate repercussions—a "fix" for one client's version of the product may be dangerous to another. The control inherent in an SCM system shows each version in which the flawed component appears. Auditing : 17 Auditing Auditing an SCM system means that approved requested changes have indeed been implemented. The audits allow managers to determine whether software evolution is proceeding both logically and in conformance with requirements for the software. The SCM system should document changes, versions, and release information for all components of each configuration item. When such documentation is in place, auditing becomes a straightforward analysis task. Status Accounting : 18 Status Accounting Reports and documentation produced by the status accounting function are the auditable entries. All approved parts of a software configuration must be accounted for, and the software parts list must reflect the transition from part CIn to CIn+1. This accounting provides the historic information to determine both what happened and when on the software project. Status Accounting (Contd..) : 19 Status Accounting (Contd..) Status accounting enables the auditing requirement of the SCM. As a project manager, the status accounting holds a wealth of information on the amount of effort required throughout the life cycle of the product in its development and maintenance. This is critical to the software project manager in making estimates for new systems based on historic information. The SCM can be used as one of the key components of the project managers' metrics system SCM Principles : 20 SCM Principles Understanding of SCM SCM Plans and Policies SCM Processes Metrics Tools for SCM SCM Configuration Items (CI) Understanding of SCM : 21 Understanding of SCM An understanding of SCM is critical to the organization attempting to institute any system of product control. Understanding through training is a key initial goal. Executives and management must understand both the benefits and the cost of SCM to provide the needed support in its implementation. Understanding of SCM (Contd..) : 22 Understanding of SCM (Contd..) Software developers must understand the basics of SCM because they are required to use the tool in building their software products. Without a total understanding, a partial implementation of SCM with workarounds and back doors will result in disaster for an SCM system. SCM Plans and Policies : 23 SCM Plans and Policies Development of an SCM policy for an organization and the subsequent plans for each product developed is crucial to successful SCM implementation. Putting SCM into an organization is a project like any other, requiring resources of time and money. There will be specific deliverables and a timeline against which to perform. SCM Plans and Policies (Contd..) : 24 SCM Plans and Policies (Contd..) The policy for the organization lays out in a clear, concise fashion the expectations that the organizational leadership has for its system. It must lay out the anticipated benefits and the method to measure the performance to those benefits. SCM Processes : 25 SCM Processes The specific processes of SCM are documented for all users to recognize. Not all SCM processes need to be used within an organization or on a product. Yet, it is important to have available, in "plain sight," those processes that are used specifically in your organization. This also maps those processes to how they are implemented. Metrics : 26 Metrics The measures used to show conformance to policy and product plans are important details. These measures show where the organization is along the path to reaping the benefits of SCM. Tools for SCM : 27 Tools for SCM Actually, it makes little sense to pick the tools to use in SCM without having done all the previous work. Putting a tool in place without training, policy, or metrics is an exercise in automating chaos. You will simply have an automated way to turn out the wrong product faster. SCM Configuration Items : 28 SCM Configuration Items The configuration items (CI) are those "things" that represent internal and external project deliverables. They are the final result of all the work done to implement SCM in your organization. SCM is the identification scheme for the software components of a system. It controls changes to the configuration and maintains integrity and traceability of the configuration. SCM Configuration Items (Contd..) : 29 SCM Configuration Items (Contd..) Change control is the management of change as one part of the SCM process. Version control is the management of the product versions generated as part of the SCM process. Release control is the transformation of configuration items into a deliverable product. Planning and Organizing for SCM : 30 Planning and Organizing for SCM When planning for SCM in your product development organization, you must first understand the classes of potential problems that can exist. Once the classes are understood, the inherent problems that are causing configuration management issues may be easily identified. Planning and Organizing for SCM : 31 Planning and Organizing for SCM Potential SCM Problem Classes 1. Multiple Developer Syndrome When you have a project that requires more than one developer, there is the problem with multiple people working on one product base. Slide 32: 32 2. Multiple Releases Enhancements to the base product should result in additional releases of the product containing the latest changes. Once the second release is available, some users are on an earlier release. Having an SCM makes managing those releases possible. Slide 33: 33 3. Product Family As products are built that offer the same capabilities across a heterogeneous set of hardware platforms, both the common and the platform-specific software bases must be managed. Slide 34: 34 4. Requirements Change The first law of systems engineering is that no matter where we are in the system life cycle, the system/software will change, and the desire to change it will persist throughout the life cycle. Dealing with this change represents a major management challenge. Having an SCM in place will ease the management of these changes to the requirements of the products that will occur. Slide 35: 35 5. Schedule Change As requirements change, so must the schedule. Having the SCM in place allows the project manager to look at historic effort levels in getting out releases. Slide 36: 36 6. Software Changes No product developer has the luxury to write code once and forget about it. Along with requirements and schedules, the software being developed changes in response to those other changes. Software is not static. That is its inherent power. It can be changed, so it will be changed. SCM systems track those changes so that, if the wrong change is made, a previous working version is available. Slide 37: 37 7. Staff Changes In the best of organizations, people get promoted, take other jobs, and leave. When that happens in the midst of a development project, not just the technology knowledge goes out the door. The long-learned knowledge of how things are done is also gone. Slide 38: 38 8. System/User Documentation Change No product developer has the luxury to produce in a technology or tool vacuum. All product developers use hardware, microcode, operating systems, tools, and documentation that are not under their control. SCM Staffing : 39 SCM Staffing It is better to have a few highly experienced people than a large number of inexperienced people. These experienced few must be able to see congruence between software products and perceive what is missing from a software product. SCM Staffing : 40 SCM Staffing We can group the characteristics and abilities needed by the four SCM functions: Identification, Control, Auditing, and Status Accounting. Identification 1. Ability to see partitions 2. Ability to see relationships 3. Some technical ability 4. System engineering orientation 5. Programming SCM Staffing (Contd..) : 41 SCM Staffing (Contd..) Control 1. Ability to evaluate benefits versus cost 2. System viewpoint (balance of technical/ managerial, user /buyer/seller) 3. An appreciation of what is involved in engineering a software change SCM Staffing (Contd..) : 42 SCM Staffing (Contd..) Auditing 1. Extreme attention to detail 2. Ability to see congruence 3. Ability to perceive what is missing 4. Extensive experience with technical aspects of system engineering or software engineering SCM Staffing (Contd..) : 43 SCM Staffing (Contd..) Status Accounting 1. Ability to take notes and record data 2. Ability to organize data 3. Some technical familiarity 4. System engineering orientation 5. Programming SCM Tools : 44 SCM Tools Basic selection criteria includes the following : Multi-user support Intuitive GUI Conformity to the organization's development environment Scalability Flexibility in integrating other software development tools Ease of setup Modifiable models Process management Extensive support for the development phase Management of nondevelopment objects Permission management Slide 45: 45 Multiuser Support—Tools are to be used concurrently by several users. They have to store all acquired information in a central, shared repository, and the SCM tool has to allow controlled parallel work on the different project documents. Slide 46: 46 · Intuitive GUI—Because the tools will be used throughout the project and not only by developers, an intuitive, easy-to-use graphical user interface is considered very important. Slide 47: 47 Conformity to the organization's development environment—The organization must define up front the hardware and software development platforms used. For example, the project may work on a heterogeneous network of Unix-based workstations (mainly Sun Sparc stations) and PCs. The tool has to be able to store its shared repositories on a workstation and has to allow PC clients as well as workstation clients supporting the operating systems and protocols. Slide 48: 48 · Scalability—The tool should work equally well for smaller projects as for larger ones. Slide 49: 49 · Flexibility in integrating other software development tools—The tool must allow the integration of all the other development tools to provide a highly homogeneous environment. Especially the tools for design, implementation, and testing will have to co-operate on the common SCM repository. Slide 50: 50 Ease of setup—The SCM tool should allow an easy installation and setup, and should be able to run nearly "out of the box." Slide 51: 51 Modifiable models—Though a working set of models should be predefined, each of these should be modifiable and extensible. This is especially important because project managers and developers want to adapt these models to the software development process as defined for the company. Slide 52: 52 Process management—Process management comprises efficient support of object life cycles and object promotion, together with a flexible and extensible approach to life cycle models. Slide 53: 53 Extensive support for the development phase— During development when checkout and update of objects is frequent, the tool should aid a developer in determining the set of objects that need an update or renewed check-in. These do a good job in change management once the first release has been produced. Slide 54: 54 Management of nondevelopment objects— SCM tools must manage all artifacts of the project, not just code. These will mainly be documents and their versions and releases. The tool must be able to support that. Slide 55: 55 Permission Management—Everyone should not have access to make changes to different pieces of the software. In many situations, check-in and checkout only will not prevent integration from being broken by multiple people modifying code for their own designs and interfaces. Benefits of SCM Process and Tools : 56 Benefits of SCM Process and Tools SCM benefits an organization in four areas: Control Management Cost Savings Quality Slide 57: 57 Control Control in SCM provides the ability to review, approve, and incorporate changes into a configuration item. There must be one controlling SCM tool so that there is only one set of training, license management, installation, and user procedures. All project personnel use the tool. Inherent in the tool is a standardized, measurable process for change. Integrity maintenance of CIs is enforced throughout the product life cycle. The tool permits only controlled change to the baseline CIs, and all changes are tracked. Slide 58: 58 Management Management in SCM is concerned with the automation of identifying and guiding configuration items through their life cycle to final assembly as part of product and delivery. Identification of CIs through a unique naming convention allows version, release, update, and full change tracking. Project status reporting is accomplished in a clear and consistent format based on SCM collected information on all CIs under configuration management. Slide 59: 59 Cost Savings Cost savings are realized across the entire product development life cycle with SCM. Maintaining product integrity through defined, tracked, and audited CIs provides a managed bill of materials for the product released to customers. Cost savings scale with SCM use and application across applications. Side effects are reduced through controlled change by understanding the impact on all versions and releases. Accurate and repeatable release control is produced in a repeatable fashion over entire product families for all customers and users. Slide 60: 60 Quality Software development is a people-intensive activity, and quality must be considered at every person-to-tool interface. Ensuring a high-quality work environment must address the process of building software products in an automated fashion. This must include tracking CIs to the tools that produced them and the clients that ultimately receive the product. Slide 61: 61 Measuring the end product to ensure high quality is done through tracking the changes made to a product throughout its life cycle. Repeatable management and change control in a documented and measured fashion allows accurate estimation of future efforts. Quality is an ongoing process. The lessons learned in one product must be transferred to new, related products and entire product families. Some Problems with Software : 62 Some Problems with Software Software development has traditionally suffered from producing end products with a definite lack of inherent quality. The symptoms of this quality lack are listed here: Software development projects are often delivered late and over budget. Often the delivered product does not meet customer requirements and is never used. Software products simply do not work right. As we look into the symptoms of our software development malaise, five principal issues related to software development arise. Some Problems with Software : 63 Some Problems with Software Lack of Visibility Lack of Control Lack of Traceability Lack of Monitoring Uncontrolled Change Slide 64: 64 Lack of Visibility Software is conceptual in nature. Unlike a bridge, a building, or another physical structure, it is not easy to look at software and assess how close it is to completion. Without strong project management, "software is 90% complete 90% of the time." Through the adoption of SCM policy and the definition of the configuration management model of the software under development, all CIs, components, and subcomponents are immediately visible for versions, releases, and product families. Slide 65: 65 Lack of Control Because software is inherently intangible, it is also more difficult to control. Without an accurate assessment of progress, schedules slip and budgets are overrun. It is hard to assess what has been accomplished and what remains to be done. SCM provides the mechanism for controlling the project through measuring the amount of effort compared to the project management plan and estimating the future effort based on past work Slide 66: 66 Lack of Traceability A lack of linkage between project events contributes to project failures. The main benefit of SCM is providing the traceability among versions, releases, and product families. A traceability thread allows management to examine the chain of events that caused a project to encounter difficulty as an integral process within the auditing capability of SCM. Slide 67: 67 Lack of Monitoring Without traceability and visibility, monitoring of software development projects becomes extremely difficult. Management cannot make informed decisions, and thus schedules slip further and costs continue to exceed budget. SCM provides the tools that open up the process to external monitoring. Management makes informed decisions avoiding schedule slips and budget excesses through the monitoring available with SCM tools and the integral workings of the CCB. Slide 68: 68 Uncontrolled Change Software is very malleable; it is idea-stuff, and customers constantly have new ideas for it. People would rarely ask a bridge constructor to make the kinds of changes midproject that software customers tend to request. The impact of such changes can be just as great. All SCM tools, along with the CCB, support a mechanism for appropriate change control. SCM and its Benefits : 69 SCM and its Benefits SCM is most important, and most often neglected, during V&V activities, which include software testing. SCM tracks the action item status, so overall system status can be assessed well before final builds and releases are done. Verification and validation testing are supported through the four basic SCM processes: identification, control, auditing, and status accounting. Let's look at examples of V&V testing in the context of each of these components. SCM Identification Benefits to V&V : 70 SCM Identification Benefits to V&V Automatic preparation of release notes List of changed software modules Definition of development baseline Generation of incident reports Definition of operational baseline Control of the configuration item identification Management of CCB meetings Prioritization of test and incident issues Establishment of turnover dates Approval of audit and test reports Approval of incident report resolutions SCM Auditing Benefits to V&V : 71 SCM Auditing Benefits to V&V Comparison of new baseline to previous baseline Assurance that standards have been met Audit trail of the testing process (verification, validation, and acceptance) of the software system Documentation of experience with technical aspects of system engineering or software engineering SCM Status Accounting Benefits to V&V : 72 SCM Status Accounting Benefits to V&V Logging and tracking of incident reports Publication of CCB minutes Slide 73: 73 With all of these potential benefits of SCM, project managers must address real-world considerations. Management commitment is the real key to implementing SCM on a specific project in a given organization. By treating the implementation of SCM as a project, the project plan must start at the top to secure commitment to checks and balances. Slide 74: 74 THANKS You do not have the permission to view this presentation. In order to view it, please contact the author of the presentation.