|
|
home | about Q/P | contact us | |
|
|||||
| article | ||||
 |
Frank J. Koch There has been much discussion in recent years about the role of software metrics in helping software organizations improve productivity and quality. In our never-ending search for simple solutions to complex problems, measurement is often seen as a panacea for our software ills. This article presents a measurement strategy for software organizations that are in the early stages of establishing a software process. Software measurement satisfies two sets of objectives. The first relates to project management, where measures are needed to develop project estimates, to monitor progress and performance, and to determine if the software products are of acceptable quality. The second set of measurement objectives addresses organizational needs: to determine overall productivity and quality levels, to identify performance trends, to better manage software portfolios, to justify investments in new technologies, and to help in planning and managing (or justifying) the software function. While it has been said that "if you can measure it, you can manage it," software measurement is effective only when it is part of a stable software management discipline. According to the Software Engineering Institute (SEI), 75% of the organizations who have assessed their software process relative to the SEI's Capability Maturity Model for Software (CMM) are functioning at Level 1. Often characterized as chaotic or ad hoc, a Level 1 process provides little foundation for meaningful measurement - projects are generally poorly planned and controlled and provide little basis for quantitatively assessing quality. At Level 2, an effective project management discipline is established: the scope of a project is understood, reasonable plans are developed, and the project is effectively tracked and managed. As organizations with a Level 1 process improve their software process, they must focus on metrics to support the management system that will be established as the core of their Level 2 process. According to Jim Clemmer, in Firing on All Cylinders, "The key to effective measurement of service/quality is a small number of simple measures that channel the organization's energy and focus on the strategic areas with the highest potential return." For a software organization with a Level 1 process, this translates to four basic measures: software size, project cost, project schedule, and defect counts. Software sizing is a prerequisite to accurate estimating. Historically, software developers have estimated projects using methods only slightly more sophisticated than "Is it bigger than a bread box?" Today we have available several sizing techniques that can help us develop more rational cost and schedule estimates. Two commonly used size measures are lines of code (LOC) and function points (FP). LOC, a tradition of software engineering organizations, requires an accurate internal view of the system. The FP method, more popular in information systems organizations, is based on an external view of the system, as seen by the user. Considerable disagreement exists, however, over the relative merits of the two methods. Ever the fence sitter, I believe that the FP metric is most useful as a basis for planning during the early phases of a project and to measure the final product, while the LOC metric is best suited to measuring progress during coding and testing phases. Project cost and schedule measures, which support basic project control, may be the easiest with which to start, since project leaders are likely to be familiar with them. Examples of cost and schedule include comparisons of actual costs and completion dates to estimated costs and dates. They may be easily extended to include the use of earned value techniques, which help with early identification of performance issues. Further, cost and schedule data may be correlated to software size data to determine productivity rates for projects and the organization. Measuring software quality by counting defects may be more problematic. While a Level 1 process may provide reasonably consistent post-release defect data in the form of user problem reports, useful defect data may not be routinely collected during the development process until inspection and testing practices are well established. Measurement programs work best when the desired data are normal outputs of the management and engineering processes in use. They fail when they are too complex or burdensome or when the objectives are not well communicated. Enormous resistance is encountered when those who are asked to provide measurement data see it as an onerous task from which they derive no benefit or, worse, fear it will be used to assess their personal performance. Implementing software metrics is not for the faint of heart or those easily discouraged. However, by keeping your measurement program simple, relevant, and an integral part of your process and by measuring only stable and defined processes, your organization can start to achieve the benefits of a quantitative software quality management system. About the author Mr. Koch is a Principal of Process Strategies, Inc. and an Associate Consultant for Q/P Management Group, Inc. He specializes in software management, with specific emphasis on software process assessment, strategic planning for process improvement, implementing change, and project management. He is an Authorized Lead Assessor for SEI CBA-IPI services. Mr. Koch can be reached via Q/P Management Group, Inc. © Copyright, 2000-2002. Q/P Management Group, Inc. Proprietary and Confidential. All Rights Reserved. |
|||
