| |
Practical Software Measurement (PSM) is an objective
process for analyzing project issues, risks, and financial
management, focusing on software project management. PSM provides
government and industry managers with objective information
for making sound decisions and for meeting cost, schedule,
and technical objectives. It is based on actual DoD, government,
and industry experience, representing the best practices in
the software and engineering communities.
Back to Top
|
| |
PSM Insight is a PC-based software tool that
automates the Practical Software Measurement
(PSM) process. PSM Insight includes tailoring, data
entry, and analysis functions to help you develop a project-specific
software measurement database and analyses. While PSM Insight
provides templates of commonly-used issues and measures, it
is also completely flexible for you to customize analysis
to project-specific needs.
PSM Insight is sponsored by the Department of
Defense and the U.S. Army Software
Metrics Office.
Back to Top
|
| |
If the maintenance (or sustaining support) process
is organized into periodic releases, PSM is implemented similar
to a new systems development process. Issues are decided during
the planning of the release and are based on things like schedule
and staffing constraints, requirements/change request volume,
etc.
If the maintenance process treats every change request as
ad hoc or continuous releases, issues and measures focus more
on maintaining and improving baselines over time, versus monitoring
discreet events. For instance, improvement goals may focus
on reducing the backlog of change requests over time, responding
more quickly to customer requests, improving software reliability,
and maintaining or improving software maintainability.
Finally, the issues and measures selected during a maintenance
project will probably be different than those selected during
the program's development.
Back to Top
|
| |
The first thing to consider is whether the data
being supplied really needs to change or whether the same
data can be used to provide insight into new issues or areas
of concern. If changes really are needed, make sure that what
you need can realistically be delivered.
Think of it this way: A new issue for the government
should almost always be equally important to the developer;
therefore, they should already be generating some data to
address the problem. Find out what that data is, and plan
to use it, if possible. Also, make sure the developers understand
why something represents a new issue for the government.
Finally, consider reducing the requirements to supply other
measurement data (i.e., drop the requirement to provide measures
for an issue which is less important or under control, or
allow reporting of some data less frequently).
Back to Top
|
| |
Integrated Product Teams (IPTs) integrate all
areas of the program team, including the government and developer
personnel, in order to improve and streamline the communications
and program decision-making processes. A goal of IPTs is to
de-centralize decision-making and cut down on red tape.
IPTs can be used to jointly define the measurement program
requirements (tailoring). Primarily, IPTs provide a logical
infrastructure for the regular review of measurement results.
IPTs can analyze and discuss the meaning of measurement results;
they can determine root causes, consider alternatives, and
recommend, and in some cases initiate, corrective actions.
Back to Top
|
| |
Even if the government and the developer are
working closely together, it is important for the government
to have the ability to do their own analysis with raw measurement
data independent from the developer organization. This means
either having raw data delivered to the government regularly
or having on-line access to the contractors data collection
systems and databases.
This does not imply that the government thinks that the contractor
will manipulate the data and should in no way be construed
as a lack of trust. Instituting this type of capability primarily
forces the government to thoroughly understand the true project
status and not make any assumptions about what the developer
is communicating. When both parties analyze results and then
get together to discuss them, the questions they each bring
to the table are the basis for high-quality communications.
Back to Top
|
| |
The PSM issues are simply mechanisms designed
to help software programs identify and classify their own
issues. PSM's common issues simply characterize problems which
plague many software-intensive programs. Programs can either
1) use these issues as a starting point when considering what
their issues really are or 2) map their specific issues to
one of these common issues.
Also, remember that new issues, categories, or measures can
be defined and used within the PSM Guidance. The PSM process
stays the same, no matter what the issue is.
Back to Top
|
| |
This is a problem on any project, really. However,
it is important to consider that just because measurement
results might provide some indication of a person's performance
doesn't mean the results need to be used for this purpose.
The decision not to use results this way must be addressed
through education.
What needs to be emphasized to anyone using
or with access to measurement results is that the results
are simply a problem-solving tool. As Deming points out, most
of the problems are in the process; poor results are usually
not due to an individual's poor performance. Results should
be used to identify and isolate problems, then to pinpoint
what process caused the problem. For instance, poor schedule
performance may appear to be due to poor project management
abilities, but are, in fact, due to a poor estimating process.
It's management's responsibility to help the organization
develop reliable processes. When measurement data must be
used for oversight purposes, make sure the people using it
understand this.
Also, consider making it a rule to only show data for oversight
purposes at the group level.
Back to Top
|
| |
At the DoD level, the 5000 series requires measurement.
The AIS world is specifically required to measure according
to PSM's 6 common issues. In general, DoD policy is becoming
less and less definitive. With this in mind, PSM is designed
to help people meet whatever requirements they are faced with.
Instructors should be familiar with the latest
policy statements, standards, and program requirements for
measurement, both at the DoD level and also those requirements
specific to the service/organization for which they will be
providing training. The "Supplemental Materials"
section of the Instructor Notebook contains some of this information.
Other good sources for this information are the U.S. Air Force's
Crosstalk,the U.S. Army OPTEC's Insight newsletter, etc.
Back to Top
|
| |
There is no "right" answer to this
question because variations between plans and actuals must
be interpreted within the context of the program, and depend
on the program's risk tolerance. In most cases, knowing when
something is a "bad enough" problem is pretty obvious.
People look not just at a single current variation, but also
use the "preponderance of evidence" approach (e.g.,
integrated analysis) and consider what the trends suggest.
Many organizations set "rules of thumb"
for certain issues/indicators. A standard rule of thumb is
to pay special attention to any indicator with a 20% variance
overall or a 10% variance in any period.
Back to Top
|
| |
Read the book. People new to software measurement should read
Part 1 of the PSM Guidebook first to get an overview of the
PSM approach. People faced with the immediate task of implementing
measurement on a program should use the more detailed guidance
found in Parts 2,3, and 4 while they are performing the steps
necessary to select and apply measurement in real-time. Students
which are more comfortable learning by example should read
through one of the case studies in Part 5. Students who need
deeper coverage of a particular area of software measurement
should refer to the bibliography in Part 6, which recommends
a number of books and reports on software measurement.
Back to Top
|
|
