The Attributes of Effective Software Metrics
19.2.3 The Attributes of Effective Software Metrics
Hundreds of metrics have been proposed for computer software, but not all provide practical support to the software engineer. Some demand measurement that is too complex, others are so esoteric that few real world professionals have any hope of understanding them, and others violate the basic intuitive notions of what high- quality software really is.
Ejiogu [EJI91] defines a set of attributes that should be encompassed by effective software metrics. The derived metric and the measures that lead to it should be
• ? Simple and computable. It should be relatively easy to learn how to derive the
How should
we assess
metric, and its computation should not demand inordinate effort or time.
the quality of a • proposed Empirically and intuitively persuasive. The metric should satisfy the engineer’s
software metric?
intuitive notions about the product attribute under consideration (e.g., a met- ric that measures module cohesion should increase in value as the level of cohesion increases).
• Consistent and objective. The metric should always yield results that are unambiguous. An independent third party should be able to derive the same metric value using the same information about the software.
• Consistent in its use of units and dimensions. The mathematical computation of the metric should use measures that do not lead to bizarre combinations
Experience indicates of units. For example, multiplying people on the project teams by program- that a technical metric
will be used only if it is ming language variables in the program results in a suspicious mix of units intuitive and easy to
that are not intuitively persuasive. compute. If dozens of
• Programming language independent. Metrics should be based on the analysis “counts” have to be
made and complex model, the design model, or the structure of the program itself. They should computations are
not be dependent on the vagaries of programming language syntax or required, it’s unlikely
semantics. that the metric will be widely applied.
• An effective mechanism for high-quality feedback. That is, the metric should provide a software engineer with information that can lead to a higher- quality end product.
Although most software metrics satisfy these attributes, some commonly used met- rics may fail to satisfy one or two of them. An example is the function point (discussed
in Chapter 4 and again in this chapter). It can be argued 3 that the consistent and objective attribute fails because an independent third party may not be able to derive the same function point value as a colleague using the same information about the software. Should we therefore reject the FP measure? The answer is: “Of course not!” FP provides useful insight and therefore provides distinct value, even if it fails to sat- isfy one attribute perfectly.
19.3 M E T R I C S F O R T H E A N A LY S I S M O D E L
Technical work in software engineering begins with the creation of the analysis model. Data, functional, and
XRef
It is at this stage that requirements are derived and that a foundation for design is behavioral models are
established. Therefore, technical metrics that provide insight into the quality of the discussed in Chapters
analysis model are desirable.
11 and 12. 3 Please note that an equally vigorous counterargument can be made. Such is the nature of soft-
ware metrics.
PA R T T H R E E C O N V E N T I O N A L M E T H O D S F O R S O F T WA R E E N G I N E E R I N G
F I G U R E 19.3
Part of the Sensors analysis model
Test sensor
for SafeHome
Password
software
Zone inquiry
Zone setting
SafeHome
Sensor inquiry
Panic button
Activate/deactivate
Sensor status
Activate/deactivate
Alarm
Password, sensors . . .
alert
Monitoring & response
subsystem
System configuration data
Although relatively few analysis and specification metrics have appeared in the literature, it is possible to adapt metrics derived for project application (Chapter 4) for use in this context. These metrics examine the analysis model with the intent of predicting the “size” of the resultant system. It is likely that size and design complexity will be directly correlated.
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