Information Technology Reference
In-Depth Information
control software development (design/redesign) processes or products. The primary
purpose of measurement is to provide insight into software processes and products
so that an organization can better make decisions and manage the achievement of
goals. This chapter provides a review of metrics that can be used as critical-to-quality
(CTQ) with some guidelines that can help organizations integrate a measurement
process with their overall DFSS software process.
What are “software metrics?” Goodman (1993) defines software metrics as “the
continuous application of measurement-based techniques to the software develop-
ment process and its products to supply meaningful and timely management infor-
mation, together with the use of those techniques to improve that process and its
products.” In software organizations, measurement often is equated with collecting
and reporting data and focuses on presenting the numbers. The primary purpose of this
chapter is to focus measurement more on setting goals, analyzing data with respect
to software development, and using the data to make decisions. The objectives of
this chapter are to provide some guidelines that can be used to design and implement
a process for measurement that ties measurement to software DFSS project goals
and objectives; defines measurement consistently, clearly, and accurately; collects
and analyzes data to measure progress toward goals; and evolves and improves as
the DFSS deployment process matures. In general, measurement is for development,
understanding, control, and improvement.
Modern software development practitioners likely are to point out that naive and
simplistic metrics can cause more harm than good. Measurement is an essential
element of software development management. There is little chance of controlling
what we cannot measure. Measurement assigns numbers based on a well-defined
meaning. Software metrics help avoid pitfalls such as cost overruns (most projects
fail to separate design and code costs) and clarify goals. Metrics can help answer
questions, such as what is the cost of each process activity? How “good” is the code
being developed? How can the code under development be improved?
By aligning the measurement process with the overall software process, DFSS
projects and organizations can collect and analyze data simultaneoulsy to help make
decisions with respect to project goals and obtain feedback to improve the mea-
surement process itself. Figure 5.1 presents a working definition for a software
measurement process.
Measurement is related to software entities as given in Table 5.1. Input software
entities include all of the resources used for software research, development, and
production such as people, materials, tools, and methods. DFSS process software
entities include software-related activities and events and usually are associated with
a time factor. For example, activities such as developing a software system from
requirements through delivery to the customer, the inspection of a piece of code, or
the first months of operations after delivery, and time periods that do not necessarily
correspond to specific activities. Output software entities are the products of the DFSS
software process that includes all the artifacts, deliverables, and documents that are
produced such as requirements documentation, design specifications, code (source,
object, and executable), test documentation (plans, scripts, specifications, cases, and
reports), project plans, status reports, budgets, problem reports, and software metrics.
Search WWH ::
Custom Search