Function-Based Metrics
19.3.1 Function-Based Metrics
The function point metric (Chapter 4) can be used effectively as a means for predict- ing the size of a system that will be derived from the analysis model. To illustrate the use of the FP metric in this context, we consider a simple analysis model represen-
To be useful for tation, illustrated in Figure 19.3. Referring to the figure, a data flow diagram (Chap- technical work,
measures that will ter 12) for a function within the SafeHome software is represented. The function assist technical
manages user interaction, accepting a user password to activate or deactivate the decision making (e.g.,
system, and allows inquiries on the status of security zones and various security sen- errors found during
sors. The function displays a series of prompting messages and sends appropriate unit testing) must be
control signals to various components of the security system. collected and then
normalized using the The data flow diagram is evaluated to determine the key measures required for FP metric.
computation of the function point metric (Chapter 4): • number of user inputs
• number of user outputs • number of user inquiries • number of files • number of external interfaces
4 SafeHome is a home security system that has been used as an example application in earlier chapters.
Weighting Factor
Measurement parameter
Count
Simple Average Complex
Number of user inputs
9 Number of user outputs
8 Number of user inquiries
6 Number of files
7 Number of external interfaces
20 Count total
F I G U R E 19.4 Computing function points for a SafeHome function
Three user inputs—password, panic button, and activate/deactivate—are shown in the figure along with two inquires—zone inquiry and sensor inquiry. One file (system configuration file) is shown. Two user outputs (messages and sensor
status) and four external interfaces (test sensor, zone setting, activate/deacti-
vate, and alarm alert) are also present. These data, along with the appropriate com- plexity, are shown in Figure 19.4.
The count total shown in Figure 19.4 must be adjusted using Equation (4-1):
WebRef
i )]
A useful introduction on FP has been prepared by
where count total is the sum of all FP entries obtained from Figure 19.3 and F i (i = 1 Capers Jones and may be
to 14) are "complexity adjustment values." For the purposes of this example, we obtained at
i www.spr.com/ ) is 46 (a moderately complex product). Therefore, library/
0funcmet.htm
Based on the projected FP value derived from the analysis model, the project team can estimate the overall implemented size of the SafeHome user interaction function. Assume that past data indicates that one FP translates into 60 lines of code (an object- oriented language is to be used) and that 12 FPs are produced for each person-month of effort. These historical data provide the project manager with important planning information that is based on the analysis model rather than preliminary estimates. Assume further that past projects have found an average of three errors per function point during analysis and design reviews and four errors per function point during unit and integration testing. These data can help software engineers assess the com- pleteness of their review and testing activities.
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
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