ESTABLISHING A SOFTWARE METRICS PROGRAM
4.9 ESTABLISHING A SOFTWARE METRICS PROGRAM
The Software Engineering Institute has developed a comprehensive guidebook [PAR96] for establishing a “goal-driven” software metrics program. The guidebook suggests the following steps:
1. Identify your business goals.
WebRef
2. Identify what you want to know or learn.
A Guidebook for Goal- Driven Software
3. Identify your subgoals. Measurement can be
4. Identify the entities and attributes related to your subgoals. downloaded from
www.sei.cmu.edu
5. Formalize your measurement goals.
6. Identify quantifiable questions and the related indicators that you will use to help you achieve your measurement goals.
7. Identify the data elements that you will collect to construct the indicators that help answer your questions.
8. Define the measures to be used, and make these definitions operational.
9. Identify the actions that you will take to implement the measures.
10. Prepare a plan for implementing the measures.
A detailed discussion of these steps is best left to the SEI’s guidebook. However, a brief overview of key points is worthwhile. Because software supports business functions, differentiates computer-based sys- tems or products, or acts as a product in itself, goals defined for the business can almost always be traced downward to specific goals at the software engineering level.
The software metrics For example, consider a company that makes advanced home security systems which you choose are driven
have substantial software content. Working as a team, software engineering and busi- by the business or
technical goals you ness managers can develop a list of prioritized business goals: wish to accomplish.
1. Improve our customers’ satisfaction with our products.
2. Make our products easier to use.
3. Reduce the time it takes us to get a new product to market.
4. Make support for our products easier.
5. Improve our overall profitability. The software organization examines each business goal and asks: “What activi-
ties do we manage or execute and what do we want to improve within these activi- ties?” To answer these questions the SEI recommends the creation of an “entity-question list” in which all things (entities) within the software process that are managed or influenced by the software organization are noted. Examples of entities include development resources, work products, source code, test cases, change requests, software engineering tasks, and schedules. For each entity listed, software people develop a set of questions that assess quantitative characteristics of the entity (e.g., size, cost, time to develop). The questions derived as a consequence of the cre- ation of an entity-question list lead to the derivation of a set of subgoals that relate directly to the entities created and the activities performed as part of the software process.
Consider the fourth goal: “Make support for our products easier.” The following list of questions might be derived for this goal [PAR96]:
• Do customer change requests contain the information we require to adequately evaluate the change and then implement it in a timely manner?
• How large is the change request backlog? • Is our response time for fixing bugs acceptable based on customer need? • Is our change control process (Chapter 9) followed? • Are high-priority changes implemented in a timely manner?
Based on these questions, the software organization can derive the following sub- goal: Improve the performance of the change management process. The software
CHAPTER 4 S O F T WA R E P R O C E S S A N D P R O J E C T M E T R I C S
process entities and attributes that are relevant to the subgoal are identified and mea- surement goals associated with them are delineated.
The SEI [PAR96] provides detailed guidance for steps 6 through 10 of its goal- driven measurement approach. In essence, a process of stepwise refinement is applied in which goals are refined into questions that are further refined into entities and attributes that are then refined into metrics.
Parts
» The Concurrent Development Model
» SUMMARY Software engineering is a discipline that integrates process, methods, and tools for
» PEOPLE In a study published by the IEEE [CUR88], the engineering vice presidents of three
» THE PROCESS The generic phases that characterize the software process—definition, development,
» THE PROJECT In order to manage a successful software project, we must understand what can go
» METRICS IN THE PROCESS AND PROJECT DOMAINS
» Extended Function Point Metrics
» METRICS FOR SOFTWARE QUALITY
» INTEGRATING METRICS WITHIN THE SOFTWARE PROCESS
» METRICS FOR SMALL ORGANIZATIONS
» ESTABLISHING A SOFTWARE METRICS PROGRAM
» Obtaining Information Necessary for Scope
» An Example of LOC-Based Estimation
» QUALITY CONCEPTS 1 It has been said that no two snowflakes are alike. Certainly when we watch snow
» SUMMARY Software quality assurance is an umbrella activity that is applied at each step in the
» R diagram 1.4 <part-of> data model; data model <part-of> design specification;
» SYSTEM MODELING Every computer-based system can be modeled as an information transform using an
» Facilitated Application Specification Techniques
» Data Objects, Attributes, and Relationships
» Entity/Relationship Diagrams
» Hatley and Pirbhai Extensions
» Creating an Entity/Relationship Diagram
» SUMMARY Design is the technical kernel of software engineering. During design, progressive
» Data Modeling, Data Structures, Databases, and the Data Warehouse
» Data Design at the Component Level
» A Brief Taxonomy of Styles and Patterns
» Quantitative Guidance for Architectural Design
» Isolate the transform center by specifying incoming and outgoing
» SUMMARY Software architecture provides a holistic view of the system to be built. It depicts the
» The User Interface Design Process
» Defining Interface Objects and Actions
» D E S I G N E VA L U AT I O N
» Testing for Real-Time Systems
» Organizing for Software Testing
» Criteria for Completion of Testing
» The Transition to a Quantitative View
» The Attributes of Effective Software Metrics
» Architectural Design Metrics
» Component-Level Design Metrics
» SUMMARY Software metrics provide a quantitative way to assess the quality of internal product
» Encapsulation, Inheritance, and Polymorphism
» Identifying Classes and Objects
» The Common Process Framework for OO
» OO Project Metrics and Estimation
» Event Identification with Use-Cases
» SUMMARY Object-oriented analysis methods enable a software engineer to model a problem by
» Partitioning the Analysis Model
» Designing Algorithms and Data Structures
» Program Components and Interfaces
» SUMMARY Object-oriented design translates the OOA model of the real world into an
» Testing Surface Structure and Deep Structure
» Deficiencies of Less Formal Approaches 1
» What Makes Cleanroom Different?
» Design Refinement and Verification
» SUMMARY Cleanroom software engineering is a formal approach to software development that
» Structural Modeling and Structure Points
» Describing Reusable Components
» SUMMARY Component-based software engineering offers inherent benefits in software quality,
» Guidelines for Distributing Application Subsystems
» Middleware and Object Request Broker Architectures
» An Overview of a Design Approach
» Consider expert Web developer will create a complete design, but time and cost can be appropriate
» A Software Reengineering Process Model
» Reverse Engineering to Understand Data
» Forward Engineering for Client/Server Architectures
» SUMMARY Reengineering occurs at two different levels of abstraction. At the business level,
Show more