Software Configuration Management

Software Configuration Management

• Software configuration management manages all software entities.

• It is viewed as a communicator , it communicates a client’s requirements and ensures that system requirements can be traced to the final product.

• It defines, implements and manages product life cycles by planning, identifying, controlling, auditing and improving the elements by which they are created.

• It provides mechanisms for managing all changes in efficient, cost-effective, and timely manner.

• It also puts into place a framework for maintenance and support of a product

Why is configuration management (CM) important?

It is important because it is vital to any software company’s software development and maintenance activities. Without CM, these activities are prone to chaos, errors, lack of repeatability and low developer productivity, as well as unmanageable software evolution which limits the growth of a company and its products.

With CM, a company reduces its risks by instituting a sane, manageable approach to software development and maintenance. This ensures that it has a sound infrastructure in place for its software product evolution and the growth of its software development environment. It is also in a position to meet the demands of its customers and the changing marketplace, any standards certification, or process improvement efforts.

What are the tasks needed in getting from the piece parts of a software system to the assembled product?

At the minimum:• Accept individual components from developers• Update source code• Assemble object or executable code• Build systems for use by test team• Install on target system• Keep track of trouble• Keep track of changes• Identify configuration of each system build and note changes• Check that documentation exists• Prepare software for shipment• Reproduce software if needed

Software Manufacturing begins when developers deliver the following to a software manufacturing group:

• A fully functional and unit-tested process or library• A set of test scripts, drivers and data to perform the unit test• A makefile that automatically builds, tests and produces

documentation for the unit, see “makefile” example posted under “Reference Material” directory

• All the source code necessary to construct the unit tests and makefile

• An exact specification of the release which cites the exact version of the source code necessary to construct the units included in the release

• Initial user documentation

IEEE std 1042-1987Software Configuration Management Activities1. Establish baseline

• Assign unique identifier to Configuration Item (CI). Example CIs: project plan, project software engineer guide, needs statement, requirements description, architectural description, source code, test plan.

• Create baseline document

2. Identify different internal releases (I.e. successive variants of same product baseline)

3. Ensure complete, current technical product documentation

4. Enforce standards• Software quality assurance

5. Use Software Configuration Management to promote each CI from one development phase or test to another

6. Use Software Configuration Management to identify involvement in internal (development) baselines

An entity that is designated for configuration management and treated as a single entity in the configuration management (CM) process is called a configuration item (CI). Software is viewed as a collection of software configuration items.

ConfigurationItem Examples

Management Plan Process plan, SE guide, test plan, maintenance planSpecification Requirements, design, testing specificationDesign Source codeTesting Test design, case, procedure, data generationSupport software Planning documentsCode Source, executableLibraries Component, reuse libraries

Change Management is defined relative to baselines. A baseline is a work product that signals a point of departure from one activity and the start of another activity.

Change Management is accomplished by identifying each baseline product and tracking all subsequent changes made to that baseline.

The goal of software configuration management is to ensure that configuration of a software process product is accurately known at any particular time.

Basic Elements of Software Configuration Management (SCM)

SCM Element Method

Software configuration item Define baseline components Identification

Software configuration Mechanism for initiating, preparing, evaluating, Control approving or disapproving all change proposals

Software configuration Mechanism for determining the degrees that the Auditing current state of a software system reflects its baseline

Software configuration Mechanism for maintaining a record of how astatus Accounting system has evolved, and the state of a system relative to published documentation and written agreements

Most of the tools started out in the Unix marketplace, with a few exceptions beginning in the Windows PC world. Now, most Configuration Management (CM) tools gear for the client/server arena, supporting Unix platform as well as Windows.

CM tools are categorized into three classes:

1. Version control tools2. Developer-oriented tools3. Process-oriented tools

When buying a CM tool, it is the operational aspect of CM that are important to consider.

Tools of Software Configuration Management

Version Control: Managing the different versions of files, configurations, product releases and executables, and ensuring unique identification of each along with groupings of items into configurations and releases.

Dependency Tracking:Keeping track of the dependencies or relationships between items(such as files within a configuration item, between design documents and code, or between code and its libraries), so that a consistent configuration can be selected and built. It includes knowledge of any structural issues, so that other CM functionality, such as change impact analysis, can be resolved.

Important Operational Aspects of a CM tool

Change Control:Tracking the changes to items under development and maintenance as bug fixes and enhancements are made to them. This includes keeping a history of why the change was needed; when, how and who made the change; whether it was tested; who approved the change; and when it was completed, deferred or escalated.

Status Reporting:Tracking the history and current status of each item, and being able to ask key questions about any version of any item and generate tailored reports for management purposes.

Important Operational Aspects of a CM tool Cont…

Build Management:Tracking how items are built, and what software components, tools and flags were involved, so that items (such as releases) can be reproduced accurately. This includes capturing a bill of materials and managing the reuse of executable objects for optimal builds. Included are the means by which code builds are distributed across platforms, such as for load sharing and optimizing build performance.

Process Management:Managing all the steps, people, procedures and phases that items go through during development and maintenance. This entails the development, release management and change processes. For example: a typical change process; when a change request is received….. What are the steps may follow before this change be released and shipped to the customer??

Important Operational Aspects of a CM tool Cont…

Important Operational Aspects of a CM tool Cont…

Workspace Management:Enabling developers to create code and make changes in a protected environment, so that they do not interfere in a destructive manner with each others’ work. Workspaces enable developers to work in parallel on the same objects, or work remotely with synchronized environments containing the latest fixes from their team members. Code changes can be merged and conflicts resolved.

Repository Management:Capturing all the CM information (such as history, dependencies and changes) about the objects in a library or database and making it visible to all users of the CM system. Queries are used to access all historical and current information, and tailored reports and be generated.

Important Operational Aspects of a CM tool Cont…

Audit Control:Validating the CM system. You must be able to check that the system maintains the integrity of objects under CM. This is important for users who must have confidence that the CM system functions as expected.

Not all software development organizations feel that they need all these capabilities. Depending on where the needs are, appropriate tools can be chosen to satisfy the needs.

Benefits of Configuration Management

Productivity enhancement, especially for developers who can focus mostly on code development as opposed to chores.

More opportunity for growth the ability to have variant release for multi-platform products and propagate changes across them, and to ship patches to specific customers.

Visibility into the status of the software development and maintenance activities, as well as to all the changes and data items; history of all items such as who made a change, and when, how, why, and what changed.

Better forecasting of release dates, because the change cycle time becomes measurable and more predictable

Fewer bugs found in field releases.

More independence for a software development organization, instead of the CM knowledge being in one person’s mind, it is disseminated throughout the organization via the CM tool.

Concurrent engineering is possible. Each team member (developers, testers, etc.) can work simultaneously and not hold up the work of others.

Distributed development is possible, so team can work on related changes at different geographical sites.

Better quality releases

More responsive to customers’ needs since change cycle is more predictable

Benefits of Configuration Management

The Three Classes of CM Tools

Version Control Tools:There are where versions of objects, such as source code, executables, graphics, documents, libraries and scripts can be archived in an optimal way via “delta” techniques. These tools are extensions of SCCS, RCS or CMS.

Developer-Oriented Tools:These include version control capabilities, as well as supporting the needs of teams of developers and build managers in parallel development, creating, merging, changing and releasing products in a distributed manner.

Process-Oriented Tools:These included version control capabilities; at least some of the developer-oriented capabilities and the ability to automate the software flow life cycles to provide an integrated approach to change management where problem tracking is associated with code.

The tool classes typically determine the degree of effort involved in tool adoption, that is, installation and deployment. But adoption also depends on the development organization’s needs, goals and the willingness to pay for services to support the deployment of the tool.

As a uniform model of functionality is demanded by the CM marketplace, the CM tools will become more proficient at solving CM problems, the classes will disappear.

Some of the Tools of Software Configuration Management

• The Source Code Control System (SCCS) is a suite of Unix operating system programs for tracking and control of versions of text files. The SCCS system was introduced by Rochkind to maintain large programs in a production environment.

• The Revision Control System (RCS) is another suite of Unix operating system programs for tracking and control versions of text introduced in 1982 by Walter Tichy.

• The Concurrent Revision System (CVS) for Unix system is downloadable from http://www.mozilla.org A PC version of CVS called WinCVS is downloadable from http://www.cyclic.com

Tools for Software Configuration Management Auditing

Well-planned projects take advantage of tools such as Project Evaluation Technique/Critical Path Method (PERT) network diagram and Gantt time-allocation charts.

Planning charts give a project management teams tools for tracking the progress of developers during a project.

They have become an accepted part of SCM auditing (IEEE Std. 1042-1987)

PERT Charts

A PERT network diagram displays task sequences required for a project. A PERT network helps display interrelationships between tasks. PERT charts also make it possible to described varying task schedules.

Sample PERT Chart:

1

4

5 7

3 6

2

=Critical path =Task

Start

A30,40,45

C38,44,50

F85,96,105

G70,75,80

H28,32,38

D38,44,48

B19,25,30

E19,26,34

TaskMin,avg,max

=Estimated min, average, max time required to completea designated task

PERT charts are tiered. Selected activities in a PERT chart will be associated with separated task schedules in lower-level PERT charts that gives a more accurate picture of what must be done to complete a particular task. I.e. milestones in a PERT charts will be more visible at different levels of details.

This makes it possible for managers to summarize more detailed task schedules and track subtasks leading to the completion of a major activity in a high-level PERT chart. (Marciniak, 1994)

A Gantt chart provides another means of depicting task schedules for a software development project.

This form of task scheduling was introduced in 1903 by Henri Gantt to plan and control military campaigns.

Horizontal bars are used to depict tasks or activities, and indicate starting and completion times.

Developing and Using Testing Metrics

For software development projects, the planning process collects together the number of functional requirements, measurement data to support the number of lines of code to be generated per staff-hour, the staff-by-month curve and the milestones.

When development starts, measurement data were collected, such as the number of use cases designed this week, the number of source lines of code developed this week, the number of bugs reported this week and the number of bugs closed this week.

A most typical question this is often asked is “Are we still on schedule?”

A software metric is a standard way of measuring some attribute of the software development process. A measurement is numerical data that is collected and reported in the units defined by the metric.The primary benefits of deploying software metrics are:

• Sharing benchmark data with other software development projects

• Collecting status data in the same unit across an organization to determine progress toward a goal

• Calibrating labor forecasts

• Estimating of development effort or schedule, based on historical actual

• Reporting process improvement trend data during reviews

Software measurement data must be taken or converted into quantifiable units of measure, as defined by the software metric. The data should relate to attributes of a software process, its products or the development project’s schedule or resources.

Table 11.1 in Chapter 11 gives several example software metrics divided into industry-standard categories.

A sample Software Metrics

Metrics Name Definition

SIZE Number of thousands of equivalent source lines of code (KESLOC)

EFFORT The number of nonadministrative staff members on the development project per month

SCHEDULE The allocation of calendar months to the individual phases of software development life cycle

QUALITY The number of bugs per KESLOC

Simply having a Software Metric in a development project does not guarantee quality software product.

A good companion strategy for software metrics program has two parts:

1. To deploy a standard set of metric definitions and then collect and analyze software measurement data across all software development projects

2. To employ the Goal-Question-Metric (GQM) decision process for project dependent selection of software measurements

The GQM method consist of identifying the goals that stakeholders have for a metric, then asking questions the measurements are intended to answer (Basil and Weiss,1984)

Metrics for Testing

Almost all testing metrics are project specificA sample testing metrics used by projects are:

Testing Metric Name Definition Predicate Logic Bugs Number of bugs found in the predicates of logical constructs (IF, WHILE etc.) /KELOC

Loop Indexing/Limits Bugs Number of bugs found in the indexing or limits of loop constructs (DO, FOR etc.) /KELOC

Testing Progress Number of test cases passed versus tests planned over time

Change Proposals and Number of mandated product changes and Action Item Volatility redirections over time

Missing/Incomplete Number of bugs found to be from missing orRequirements incomplete requirements

Design Progress Number of requirements documented – planned versus actual

Bug Density (Bugs / KSLOC)

The most basic testing metric are associated with bugs. It is natural for a project to itemize, prioritize, and report status on bugs by severity.

This allows analysis to be on the quality of software for each build.

If a testing metric showed that static testing has been used to find bugs in requirements, designs and code, and more major bugs were found in the detailed design and code phases than in system testing, this means that thorough testing of the product has started long before the system testing phase – a good practice!

The Software Error Estimation Program (SWEEP), developed by Software Productivity Consortium, is a forecasting tool for estimating bug rates, include latent bugs. (any bug that remains in a software product; I.e. it exists but has not yet been found.)The value of the SWEEP model is that it aids in the management and prediction of bugs in software-intensive systems.

Three models are used by SWEEP:

Time-base model – allows you to estimate and track bugs during system test and integration cycles

Phased-based model – allows you to predict and track bugs for multiple phases and cam provide bug information before you execute any code

Planning-aid model – allows the user to set bug discovery objectives in a software project based on experience from previous projects; it generates a bug discovery profile based on corporate data to guide the software project toward those objectives.

http://www.software.org

Homework 03/31/05

1. Please read chapters 11 &12