Software Configuration Management

1
Software Configuration Management
2

• Software Configuration Management
• Software configuration management manages all
  software entities.
• It is viewed as a communicator , it communicates
  a clients 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

3
Why is configuration management (CM)
important? It is important because it is vital
to any software companys 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.
4

• 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

5

• 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

6

• IEEE std 1042-1987
• Software Configuration Management Activities
• 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
• Identify different internal releases (I.e.
  successive variants of same product baseline)
• Ensure complete, current technical product
  documentation
• Enforce standards
• Software quality assurance
• Use Software Configuration Management to promote
  each CI from one development phase or test to
  another
• Use Software Configuration Management to identify
  involvement in internal (development) baselines

7
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.
Configuration Item
Examples
Management Plan Process plan, SE
guide, test plan, maintenance plan Specification
Requirements, design,
testing specification Design
Source code Testing
Test design, case, procedure,
data generation Support software
Planning documents Code
Source, executable Libraries
Component, reuse libraries

8
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.
9
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
a status Accounting system
has evolved, and the state of a system
relative
to published documentation and written
agreements
10
Tools of Software Configuration Management

• 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
• Version control tools
• Developer-oriented tools
• Process-oriented tools
• When buying a CM tool, it is the operational
  aspect of CM that are important to consider.

11
Important Operational Aspects of a CM tool
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.
12
Important Operational Aspects of a CM tool Cont
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.
13
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??
14
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.
15
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.
16
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.
17
Benefits of Configuration Management
More independence for a software development
organization, instead of the CM knowledge being
in one persons 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
18
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.
19
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 organizations 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.
20

• 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

21
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)
22
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
4
F 85,96,105
C 38,44,50
A 30,40,45
G 70,75,80
E 19,26,34
1
5
7
2
Start
B 19,25,30
H 28,32,38
3
6
D 38,44,48
Task Min,avg,max
Critical path
Task
Estimated min, average, max time required to
complete a designated task
23
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)
24
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.
25
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?
26
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

27
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 projects schedule or
resources. Table 11.1 in Chapter 11 gives
several example software metrics divided into
industry-standard categories.
28
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
29
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

• To deploy a standard set of metric definitions
  and then collect and analyze software measurement
  data across all software development projects
• 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)
30
Metrics for Testing Almost all testing metrics
are project specific A 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 or Requirements
incomplete requirements Design Progress
Number of requirements
documented planned
versus actual

31
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!
32
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
33

• Homework 03/31/05
• Please read chapters 11 12