|
|
|
|
| |
| Just
starting to look for an SCM solution for your
organization? Our Assessments are designed to
get you headed in the right direction-inahurry!
Implementing
a comprehensive software configuration management
solution can be a large undertaking and a big
investment. Knowing what you already have, what
you need, and how to plan and budget for your
SCM solution often seems overwhelming at first.
An SCM Labs Assessment can help. In typically
2 - 4 weeks, you can learn the facts about your
current SCM solution. You get a detailed report
on its strengths and weaknesses along with expert
recommendations and a roadmap on the best plan
for getting to the right solution for your organization
- all for a single fixed cost. Whether you are
looking at CMMI, ITIL, ISO or any of the many
other guidelines, we can help you get there faster. |
|
| Software
configuration management (SCM) is the organization
of the components of a software system so that
they fit together in a working order, never out
of synch with each other. Those who have studied
the best way to manage the configuration of software
parts have more elegant responses.
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.
1 .We think that Pressman's
description is a better description because we
often view SCM as meaning software change management.
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.
2 .The Software Engineering
Institute says that it is necessary to establish
and maintain the integrity of the products of
the software project throughout the software life
cycle. Activities necessary to accomplish this
include identifying configuration items/units,
systematically controlling changes, and maintaining
the integrity and the traceability of the configuration
throughout the software life cycle. Military standards
view configuration as the functional and/or physical
characteristics of hardware/software as set forth
in technical documentation and archives in a product.
In identifying the items that need to be configured,
we must remember that all project artifacts are
candidates—documents, graphical models,
prototypes, code, and any internal or external
deliverable that can undergo change. In SW PM
terminology, a configuration item might be a proposal/estimate
or bid, project plan, risk management plan, quality
assurance plan, CM plan itself, test plan, system
requirements specification, system design document,
review metric, code, test result, tool (editors,
compilers, CASE), and so on. There are basic objects
and aggregate objects to be configured. The number
of relationships among them reflects the complexity
of the configuration task. |
|
Software
project managers pay attention to the planning
and execution of configuration management, an
integral task, because it facilitates the ability
to communicate status of documents and code as
well as changes that have been made to them. High-quality
released software has been tested and used, making
it a reusable asset and saving development costs.
Reused components aren't free, though—they
require integration into new products, a difficult
task without knowing exactly what they are and
where they are. CM enhances the ability to provide
maintenance support necessary once the software
is deployed. If software didn't change, maintenance
wouldn't exist. Of course, changes do occur. 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. CM works for the project
and the organization in other ways as well. It
helps to eliminate confusion, chaos, double maintenance,
the shared data problem, and the simultaneous
update problem, to name but a few issues to be
discussed in this chapter. |
|
| 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. 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. |
|
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, morph, and 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. 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. |
|
|
|
|
|
