Extended Function Point Metrics
4.3.3 Extended Function Point Metrics
The function point measure was originally designed to be applied to business infor- Extending function
mation systems applications. To accommodate these applications, the data dimen- points are used for
sion (the information domain values discussed previously) was emphasized to the engineering, real-time, exclusion of the functional and behavioral (control) dimensions. For this reason, the and control-oriented applications.
function point measure was inadequate for many engineering and embedded sys- tems (which emphasize function and control). A number of extensions to the basic function point measure have been proposed to remedy this situation.
A function point extension called feature points [JON91], is a superset of the function point measure that can be applied to systems and engineering software applications.
92 PA R T T W O M A N A G I N G S O F T WA R E P R O J E C T S
The feature point measure accommodates applications in which algorithmic complex- ity is high. Real-time, process control and embedded software applications tend to have high algorithmic complexity and are therefore amenable to the feature point.
To compute the feature point, information domain values are again counted and weighted as described in Section 4.3.2. In addition, the feature point metric counts a new software characteristic—algorithms. An algorithm is defined as "a bounded com- putational problem that is included within a specific computer program” [JON91]. Invert-
WebRef
ing a matrix, decoding a bit string, or handling an interrupt are all examples of algorithms.
A useful FAQ on function Another function point extension for real-time systems and engineered products points (and extended
has been developed by Boeing. The Boeing approach integrates the data dimension function points) can be
obtained at of software with the functional and control dimensions to provide a function-oriented
http://ourworld.
measure amenable to applications that emphasize function and control capabilities.
compuserve.com/
Called the 3D function point [WHI95], characteristics of all three software dimensions
homepages/ softcomp/
are “counted, quantified, and transformed” into a measure that provides an indica- tion of the functionality delivered by the software. 6
The data dimension is evaluated in much the same way as described in Section
4.3.2. Counts of retained data (the internal program data structure; e.g., files) and external data (inputs, outputs, inquiries, and external references) are used along with measures of complexity to derive a data dimension count. The functional dimension is measured by considering “the number of internal operations required to transform input to output data” [WHI95]. For the purposes of 3D function point computation, a “transformation” is viewed as a series of processing steps that are constrained by a set of semantic statements. The control dimension is measured by counting the num- ber of transitions between states. 7
A state represents some externally observable mode of behavior, and a transition occurs as a result of some event that causes the software or system to change its mode of behavior (i.e., to change state). For example, a wireless phone contains soft- ware that supports auto dial functions. To enter the auto-dial state from a resting state, the user presses an Auto key on the keypad. This event causes an LCD display to prompt for a code that will indicate the party to be called. Upon entry of the code and hitting the Dial key (another event), the wireless phone software makes a transition to the dialing state. When computing 3D function points, transitions are not assigned
a complexity value. To compute 3D function points, the following relationship is used:
index = I + O + Q + F + E + T + R (4-2)
6 It should be noted that other extensions to function points for application in real-time software work (e.g., [ALA97]) have also been proposed. However, none of these appears to be widely used in the industry.
7 A detailed discussion of the behavioral dimension, including states and state transitions, is pre- sented in Chapter 12.
Semantic
Determining the
statements
complexity of a transformation for 3D function
points [WHI95].
Processing steps
where I, O, Q, F, E, T, and R represent complexity weighted values for the elements discussed already: inputs, outputs, inquiries, internal data structures, external files, transformation, and transitions, respectively. Each complexity weighted value is com- puted using the following relationship:
(4-3) where N il ,N ia , and N ih represent the number of occurrences of element i (e.g., out-
complexity weighted value = N il W il +N ia W ia +N ih W ih
puts) for each level of complexity (low, medium, high); and W il ,W ia , and W ih are the corresponding weights. The overall complexity of a transformation for 3D function points is shown in Figure 4.6.
It should be noted that function points, feature points, and 3D function points rep- resent the same thing—"functionality" or "utility" delivered by software. In fact, each of these measures results in the same value if only the data dimension of an appli- cation is considered. For more complex real-time systems, the feature point count is often between 20 and 35 percent higher than the count determined using function points alone.
The function point (and its extensions), like the LOC measure, is controversial. Proponents claim that FP is programming language independent, making it ideal for applications using conventional and nonprocedural languages; that it is based on data that are more likely to be known early in the evolution of a project, making FP more attractive as an estimation approach. Opponents claim that the method requires some "sleight of hand" in that computation is based on subjective rather than objec- tive data; that counts of the information domain (and other dimensions) can be dif- ficult to collect after the fact; and that FP has no direct physical meaning—it's just a number.
94 PA R T T W O M A N A G I N G S O F T WA R E P R O J E C T S
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