function/feature points comp.software-eng archive file "funcpoints" last changed 10 Apr 1992 This file contains information on the following subjects. Numbers in column 1 count distinct messages with the corresponding subject. 1 Charles Symons' book 1 Code Coverage == fewer bugs? 3 Function Points metric 1 Help with function points and feature points 1 International Function Points User's Group 1 What is a "function point count"? 3 What the heck's a function point? ------------------------------------------------------------------------ References: Albrecht, A.J., J.E. Gaffney : Software Function, Source Lines of Code, and Development Effort Prediction: A Software Science Validation. IEEE Transcations on Software Engineering, SE-9, Nov. 83, 639-648. A. J. Albrecht, "Measuring application development productivity" in Proceedings IBM Applications develop. Symp., CA Oct. 14-17, 1979; Guide Int. and Share, Inc. , IBM Corp, p83 Symons, C.R. : Function Points Analysis: Difficulites and Improvements. IEEE Transcations on Software Engineering, SE-14, Jan. 88, 2-11. J. Brian Dreger: Function Point Analysis. Prentice-Hall (1989). Capers Jones : Applied Software Measurement - Assuring Productivity and Quality. McGraw-Hill, 1991, ISBN 0-07-032813-7. C.F. Kemerer : An empirical validation of Software Cost Estimation Models Communications of the ACM, Vol 30(5), pp 416-770, 1987 (compares COCOMO, SLIM, ESTIMACS and Function points] From dalamb@umiacs.umd.edu Wed Jul 31 05:57:32 1991 Subject: Function Points metric I reviewed a book by James Martin called "Rapid Application Development", one of whose appendices gives a detailed worksheet for computing function points for business applications; the book also reports that many organizations are using these numbers. So, do people believe "function points" are a pointless measure? :-) Or that they don't really measure "functionality" ? Or that they're too subjective to be counted as a "measure" (they do appear to "require an experienced analyst" to compute them). Date: Thu, 1 Aug 91 21:31:23 -0700 From: franklin@enuxha.eas.asu.edu (Malcolm L. Franklin) Opinions expressed here are strictly my own and not necessarily those of any past or present employer. We used a "function-point-like" method to estimate a 20 man-month project at Allied Signal aerospace/Garrett Engine Division. The implementation of the method was a tool called ESTIMACS developed by Howard A. Rubin. We sat down in fron of an IBM PC/AT & answered a whole buch of questions about the types of thinsg the system would do, how many people were woking on it, how far we were from the customer site & so on. The tool spit out an estimate that we (My boss, a PhD in CS, and myself, who was then working part time, while working full time on an MS in CS) felt was overly conservative. When we delivered the system, we pulled out the ESTIMACS estimate and found that it had under-estimated the project by ~1 month Pretty good eh! especially since we were working from a first-cut requirements analysis. Anyway, to give you an idea of the application domain, the system stores Numerical Control (NC) programs on a VAX t network, and downloads them into machine tools on the factory floor. The system enforces configuration management and Q.C. related controls to ensure that the right programs are used, changes to programs are tracked & so on. I'm sure the ESTIMACS system has been refined since we used it (1988), but the last reference I have on it is: Rubin, Howard A., "Macro-Estimation of Software Development Parameters: The ESTIMACS System," SOFTFAIR Conference on Software Development Tools, Techniques and Alternatives (Arlington VA., July 25-28), IEEE Press, New York, 1983, pp 109-118. Dr. Rubin's address in that (old) article is: Dr. Howard A. Rubin Department of Computer Science Hunter College City University of New York New York, NY 10021 (212)570-5265 From: nwegmann@ducvax.auburn.edu Subject: Re: Function Points metric Date: 1 Aug 91 18:59:02 GMT In article <1991Jul31.154837.13828@murdoch.acc.Virginia.EDU>, sgf0z@kelvin.seas.Virginia.EDU (Steven Glenn Fox) writes: > > Although not a function point practitioner, I have come across them in a > number of places and they do seem to have a rather large following. > From what I have learned, they do seem to be a good functional measure, > for support of this, I suggest Low and Jeffery's article in the IEEE SE of > January 1990. They do also agree that you need a trained analyst to accurately > assess function points. As to its following, there is an International > Function Point Users Group that is supposed to have many members. > > Function points seem to be very good for functionality of information systems, > but for more complex software, they are not as helpful, and I would argue > misleading. I have recently heard of a measure called Feature Points that > is supposed to correct this aspect of Function Points. This I believe was > developed by Capers Jones of Software Productivity Research. I know this > adds an element called algorithms to the function count, but little more about > it. > > I am interested in hearing more about Feature Points as well as Function > Points if anybody has any knowledge or experience. > > ------------ > Steven G. Fox sgf0z@virginia.edu > Department of Systems Engineering, University of Virginia Steven, I've got a little exposure to the feature point concept while working at another job. In particular, I was able to work some with a software estimation tool called CheckPoint. This tool was supposed to provide micro versus macro estimation capabilities against software development and maintenance projects considering many different project variables. The tool made use of function points as well as features points. From reading the documentation that came with the tool and the online help, feature points were intended to pick up where function points appear to leave off. In other words, feature points were suppose to represent a "superset" of function points. The calculation of function points involved calculations (i.e., counting) of certain items (e.g., logical inputs/outputs/etc...) and feature points involved basically similar calculations plus additional counting considerations. I apologize for not remembering the exact details but it has been some time since I looked at the tool. By the way, you might also find it interesting to note that the tool was developed by Software Productivity Research (SPR). As you mentioned in your post, Capers Jones works with SPR. The fellow who came up with the concept of function points at IBM, (I forget his name off the top of my head, is it Hufschmidt or something like that?) moved on to join SPR where he further refined his function point concept and came up with the feature point concept. Lucky Capers, huh? :-) One of the nice features I remember about the CheckPoint tool is that it allowed specification/capture of not only what it termed hard factors associated with software development/maintenance but also soft factors. Hard factors being the usual things considered when thinking about estimating a project's makeup such as number of warm bodies who will be working on the project and the like. The soft factors explored those areas such as (now get ready for this) working office space. Capers mentioned in some documentation associated with the tool that from his studies he found this to be a factor which should be considered when estimating software development/ maintenance efforts. I tend to agree with Capers in attempting to consider soft factors such as these. In any case, the tool itself at times seemed to be very detailed in its request for information (input) from the person attempting to estimate a project. And yes, feature points were a part of it. The tool's interface at times seemed a little overwhelming (i.e., you would find yourself lost 6 or 7 levels deep in a menu structure about a particular subject area) and the product came at a price of around $19,000. Ouch, |-). Sorry to drag you through the CheckPoint discussion but I felt I needed to because my only limited exposure to feature points was via this tool. Hope this helps some. Norbert Wegmann Auburn University, Auburn, Alabama INTERNET: nwegmann@ducvax.auburn.edu From: seb1@druhi.ATT.COM (Sharon Badian) Subject: Re: Function Points metric Date: 2 Aug 91 14:21:55 GMT Function points were developed by Alan Albrecht of IBM (now retired). Albrecht does not work for SPR and did not develop feature points. Capers did that all on his own. I have worked extensively with Capers and feature points suffer from not being well defined. He defines an algorithm, but it's not something that you say "Oh, I know how to count that!" and Capers doesn't give you much help in the counting. Also, whereas Albrecht's function point formulas were developed using regression on actual data, Capers did nothing of the sort, at least to my knowledge. So, again, you are on your own. Checkpoint now sells for $25K, so the ouch has gotten bigger. :-) For another measure of "functionality" you might look at Donald Reifer's function point variation for real time systems. He DOES give you good rules for counting and he has done regression. I have not actually used his method (I hope to try it out sometime this year) but it looks promising. My only reservation (one I have with all these functionality counting methods, including DeMarco's BANG) is that they are not available until after you have a very good idea of your requirements. This makes them less than useful for early estimation. I think Reifer's function points may be useable at an earlier stage if you are willing to accept a fair amount of uncertainty in your estimate. From: mao@praxis.co.uk (Martyn Ould) Subject: Charles Symons' book Date: 5 Aug 91 07:42:40 GMT Organization: Praxis, Bath, U.K. For the latest Mark II FPA see Charles Symons's "Software sizing and estimating", just published by Wiley ISBN 0-471-92985-9. The counting rules are very definitely about information systems - it even says it in the book's blurb! From: warren@eecs.cs.pdx.edu (Warren Harrison) Subject: International Function Points User's Group Date: 6 Aug 91 19:56:39 GMT Organization: Portland State University, Portland, OR The IFPUG (International FUnction Points Users' Group) will have their Fall Conference on October 7-11 in Scottsdale Arizona. For more info, call IFPUG at 614/895-7130 or FAX at 614/895-3466. They are predicting approx. 200 attendees (at least that's how many copies of their handouts authors need if they don't make the deadline for the proceedings). In the DP community function points are at least as well accepted as code metrics such as Software Science and Cyclomatic Complexity. From: ksh@ai.mit.edu (K. Shane Hartman) Date: 16 Aug 91 23:19:23 GMT Organization: ITS Preservation Society Al Albrecht developed function points. He is now associated with SPR. Capers (not Al) actually developed Feature Points as an extension, to deal with real time software such as operating systems. The reason is that Function Points (developed primarily for information systems) tended to understate the functional size of real time systems because the internal algorithmic complexity was much higher than typical database oriented system. Capers also developed a simplified methodology for counting Function Points that is more appropriate for use when the project requirements are not fully specified. The difference between Feature Points and Function Points is simple. Feature points assigns a lower weight to External User Data Groups (or Data Files) and adds an additional counting category for Algorithms. We are working with the International Function Point Users Group to refine and extend the Function Point standards. You can contact obtain more information about IFPUG from Nancy Marshall 5008-28 Pine Creek Drve Westerville, OH 43081-4899 614-895-7130 You can read more about Feature Points, Function Points, Functional Metrics and software measurement in general in Capers' book, "Applied Software Measurement", McGraw Hill, ISBN 0-07-032813-7. We also teach an intensive two day course in Feature Points and Function Points. Call us at the number below if you are interested. Or send me E-Mail and I will send you brief descriptions of the counting methodologies. Checkpoint Version 2.0 has been simplified and (I believe) is easier to use than its predecessor. I agree that 1.1.C's interface was a bit baroque. I think the product is well worth the money, since it is an integrated tool providing measurement, assessment, and expert rule based estimation, based on methodologies that have taken years to develop. How much does a software cancellation cost? How much does attrition of talented personnel cost because goals are set with no real knowledge of your development process or its potential? Checkpoint forces managers to think about these issues and helps them make reasonable decisions. It provides a framework for measurement and tracking improvements in productivity and quality. Those who do not learn from history are doomed to repeat it... From: luckham@dataco.UUCP (Mike Luckham) Subject: Re: Help with function points and feature points Date: 13 Sep 91 14:29:27 GMT Organization: Canadian Marconi Company (Datacomm), Ottawa, Ontario I have used a crude form of function point analysis as an estimating tool, with quite a bit of success. We have started evaluating a pair of tools from GEC Marconi Software Systems, called SIZE-Plus and GECOMO-Plus. GECOMO provides the COCOMO model of estimating project staffing and duration, but requires KLOC (K lines of code) for input. SIZE uses function point analysis to help you figure out KLOC. Prices are reasonable. With these tools, we hope to *really* use function point analysis for our estimates. Both run on PCs or Suns, among others. The address: GEC-Marconi Software Systems 12110 Sunset Hills Road, Suite 450 Reston, Virginia 22090 USA (703)648-1551 (703)476-8035 (fax) From: XANADU/CAPERS Subject: Re: Code Coverage == fewer bugs? Date: 7 Oct 91 12:54:28 There is an interesting but preliminary correlation between the code coverage of a test suite and defect removal efficiency, or the percentage of latent defects actually detected. It appears that defect removal efficiency approximates the 0.75 power of coverage. I.E., 90% coverage equates roughly to a removal efficiency of 29%. Another interesting new correlation is that Function Points provide a direct metric for predicting test case volumes during requirements and design. Civilian projects tend to average about 2 test cases per Function Point, while military software projects tend to average about 3 test cases per Function Point. Capers Jones, SPR, Inc. 77 South Bedford St. Burlington, MA 01803 Tel: 617-273-0140 FAX: 617-273-5176 From: alford@alc.com (Mack Alford) Subject: Re: What the heck's a function point? Date: 9 Dec 91 23:53:56 GMT Organization: Ascent Logic Corporation Refer to "Programming Productivity", by Capers Jones, McGraw-Hill, 1986, page 75. The number of "function points" in a program is equal to * the number of inputs multiplied by 4 * the number of outputs, multiplied by 5 * the number of inquiries, multiplied by 4 * the number of master files, multipled by 10 * the number of interfaces, multiplied by 7 The concept was originally developed by Albrecht at IBM [Albrecht, "Software Function , Source Lines of Code, and Development Effort Prediction: a Software Science Validation, IEEE Trans on Software Engineering, Vol SE-9, No. 6, Nov 1983, pp 639 - 647)], and Behrens [ same issue of IEEE TSE] Jones Assessment: " Although the function-point methodology istelf has sources of ambiguity, such as the uncertainty in just how to count inputs, outputs, data files, and inquiries, it is becoming widely used for information systems and application programs. The function-point meth9od is not widely used for real time systems, military systems, or any other kind of software where algorithmic complexity is high and data complexity is low".... the function-point method has gaps and sources of ambiguities of its own.".. p. 76, 77. So it is used as a cost and size of code predictor in MIS, sort of equivalent to the Boehm COCOMO model with a different size estimator. From: warren@rigel.cs.pdx.edu (Warren Harrison) Subject: Re: What the heck's a function point? Date: 10 Dec 91 17:31:12 GMT Actually, the Function Point model is much more than Boehm's COCOMO Model, and at the same time much less. It doesn't (nor is it meant to) consider things such as the development environment, tools, etc. - in fact it explicitly ignores "technology factors" - a better analogy would be Function Points are like the DSI in Boehm's COCOMO Model ... The absolute best description of Function Points can be found in a book by J. Brian Dreger called "Function Point Analysis", published by Prentice-Hall in 1989 (ISBN 0-13-332321-8). Most papers and other books are very misleading regarding exactly what an input, output, etc. is. At the same time, studies (eg by Chris Kemmerer of MIT) have shown that the FP Model is not as subject to inconsistencies as we have thought in the past (after reading Dreger's book, call Chris up and ask for some papers :-). The major limitation of Function Points is that they don't consider internal processing enough - however, as bigger and bigger pieces of most applications are the user interface, this may not be that big of a problem except in a few areas. If you're seriously interested in metrics, by all means get the Dreger book, Function Points are too popular to not know about them. From: mao@praxis.co.uk (Martyn Ould) Subject: Re: What the heck's a function point? Date: 17 Dec 91 13:46:59 GMT Organization: Praxis, Bath, U.K. In article <4142@pdxgate.UUCP> warren@rigel.cs.pdx.edu (Warren Harrison) writes: [...] > >If you're seriously interested in metrics, by all means get the Dreger book, >Function Points are too popular to not know about them. Readers may like to know that the concept has been updated to (yes) "Mark II Function Points" by Charles Symons. The principal motivation was to provide counting rules that were more applicable to systems being developed using today's methods and tools, in particular the various structured methods, relational databases, forms generators, application generators etc. The new method is fully described in "Software sizing and estimating - Mk II FPA" Charles R Symons John Wiley & Sons ISBN 0-471-92985-9 The book additionally gives full details of a calibration carried out from data on over a hundred recent projects, and points to a tool "Before You Leap"(TM) that runs the method with its calibration. From: hwang@lamar.ColoState.EDU (Bang Hwang) Subject: Re: What is a "function point count"? Date: 27 Mar 92 17:20:58 GMT Organization: Colorado State University, Fort Collins, CO 80523 I just finished a project "Implementing The Functin Point Analysis On The Neural Network". Since the Alberecht's function point analysis is based on the liear regression approach, its accuracy is only up to a certain degree. The purpose of my work is to compare the accuracy of the result of the linear regression approach and that of the neural nework. The data I used is from the reference article #2 listed above. The neural network tool I used is NeuralShell developed by Ward Systems Group, Inc. The result of this experiment shows that the neural networks model can do a better job than the linear regression model. Any request to review or futher verifying the validity of the neural network model is welcome. I can be reached by mailing to hwang@lamar.colostate.edu Hwang, Justin