Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
Function point analysis
Dreger J., Prentice-Hall, Inc., Upper Saddle River, NJ, 1989. Type: Book (9789780133323214)
Date Reviewed: Jul 1 1990

Dreger introduces function points (FPs) and their use for measuring an application from an end-user perspective. This slim and readable book is organized into six chapters. Chapter 1 (40 pages) discusses guidelines for identifying and weighting function points. Chapter 2 (21 pages) goes through a parts system example. Chapter 3 (16 pages) covers applying the 14 “general application characteristics” (environment factors) to modify the unadjusted function point count. Chapter 4 (30 pages) gives a larger personnel system example. Chapter 5 (24 pages) describes how to use FPs to size maintenance work. Chapter 6 (14 pages) is on using FPs in productivity evaluation and business planning. An afterword by Brenda Dorr (13 pages) gives high-level briefing charts for use in starting a measurement program. An appendix (18 pages) has a solution to the case study in chapter 4 and blank forms for use in function point analysis (FPA).

The book succeeds in introducing the basics of counting and weighting FPs. Detailing various circumstances for counting or not counting FPs does not always make for exciting reading, but the author does better than expected with an informal and readable style. The strength is in the examples--especially the personnel system contributed by Prof. Eberhard E. Rudolph of the University of Auckland, which makes up, in chapter 4 and the appendix, nearly 20 percent of the book (using the very non-FP-like number of pages as the measure). The reader will find the author’s compilation of guidelines from Unisys, the GUIDE handbook, and other sources on how to count and use FPs useful. The refinement of counting rules is an ongoing affair, with the International Function Point User Group (IFPUG) playing an active role.

Readers should appreciate that the book’s detailed discussions of counting rules are necessary; sensitivity of the total unadjusted FP count to variations in individual counting rules is a concern in FPA. For example, the author makes it clear that his way of counting logical outputs differs from the IFPUG standard. The effect of this difference on the case study in chapter 4 is that the author’s total unadjusted FP count is greater than what would be the IFPUG total by a factor of 2 [1].

Function points originated in the information systems domain, whose characteristics are assumed throughout the book. For example, the stated milestones in the development process--end of design after 80 percent of the project duration and end of coding after 95 percent--will surprise readers (like me) who develop unprecedented, real-time systems and ask “what about testing?” (Several groups are now making progress in adapting FPs outside the information systems domain.)

The level of enthusiasm approaches marketing hype: “We have learned how a marvelous tool--Function Point Analysis--can be used to solve not only this, but many other problems as well--both today and tomorrow] We have seen that with proper use it can--and will--every day provide levels of usefulness and precision until recently only dreamed about” (p. 144).

The book is best when it covers the basics of FP identification with solid examples. The text describes the benefits of FP to characterize project size and the “business value of a system to the user.” Less convincing is the discussion of what to do with the FPs after they are counted, such as how to use FPs for productivity analysis and planning. Early in the book we are told that FPA is “by far the most accurate and effective software metric ever developed” and that it “accurately and reliably evaluates--to within 10 percent for existing systems and 15–20 percent for planned systems” programmer productivity, project cost, and development time. After the number of FPs is determined, however, chapter 6 informs us that the range of effort required to code one COBOL function point is 3–87 hours. Also, the required effort per FP increases nonlinearly with the number of FPs in the project. Such variation calls into question the earlier assertions of accuracy in estimating project cost once FPs are known. Among minor points is the incorrect (or confusing) identification of the modification formula on page 110 as “total project size.” Distractions include the repeated reference to two particular 4GL products, the example of a company’s decision analysis comparing 3GLs and 4GLs, and the afterword with briefing charts on getting started in FP measurement (see Grady and Caswell [2] for guidelines on starting a measurement program).

On balance, this very readable introduction to FPA should help readers who have heard of function points and want to know how to identify them in their MIS applications.

Reviewer:  W. W. Agresti Review #: CR113710
1) Porter, B. Review of Function point analysis, by J. Brian Dreger. Syst. Dev., August 1989, 8.
2) Grady, R. B. and Caswell, D. L. Software metrics: establishing a company-wide program. Prentice-Hall, Englewood Cliffs, NJ, 1987. See <CR> Rev. 8804-0237.
Bookmark and Share
 
Performance Measures (D.2.8 ... )
 
 
Productivity (D.2.9 ... )
 
Would you recommend this review?
yes
no
Other reviews under "Performance Measures": Date
Applied software measurement
Jones C., McGraw-Hill, Inc., New York, NY, 1991. Type: Book (9780070328136)
Aug 1 1992
The measurement of locality and the behaviour of programs
Bunt R., Murphy J. The Computer Journal 27(3): 238-253, 1984. Type: Article
Feb 1 1985
Estimating the fault rate function
Jennings T. IBM Systems Journal 31(2): 300-312, 1992. Type: Article
May 1 1994
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy