📄 function point faq.htm
字号:
<html>
<head>
<title>Function Points FAQ</title>
<meta name="GENERATOR" content="Microsoft FrontPage 3.0">
</head>
<body topmargin="0" leftmargin="0">
<img src="tsepm7.gif"><img src="http://www.marotz.com/counter/htmlcount.asp?ref=http://www.tsepm.com/nov99/art5.htm" width="1" height="1" border="0">
<blockquote>
<b><font SIZE="5"><blockquote>
</font></b><p ALIGN="left"><strong><font face="Arial" color="#FF8080" size="3"><em>FAQ</em></font><font face="Arial" color="#FF0000"><br>
</font><font face="Arial" size="6" color="#FF0000">Function Point FAQ </font></strong></p>
<em><p>Frequently Asked Questions (and Answers) Regarding Function Point Analysis</em> <br>
Copyright 1996-1997 by Software Composition Technologies, Inc. </p>
<hr>
<h1><a name="WhatIsThisDocument">What is this document?</a> </h1>
<p>This document contains information regarding function point analysis. It is a
compendium of questions that are often raised on-line or in a business environment,
including the classroom. Variations on these questions often occur on the CompuServe CASE
forum and the USENET comp.software-eng newsgroup. However, because there is no function
point newsgroup, this FAQ is not the official FAQ to any newsgroup. The following
questions relate to the way the FAQ is maintained: </p>
<h2>Who is the editor? </h2>
<p>The editor is Ray Boehm. He has been involved with function point analysis for about
eight years and has been an IFPUG Certified Function Point Specialist (CFPS) for the past
three. Ray spent the past most of that time working for a major systems integrator where
he used function point analysis to monitor productivity and to estimate project effort.
Currently, he is the Principal Consultant at Software Composition Technologies, a firm
involved in function point training and consulting. </p>
<h2>How can the editor be contacted? </h2>
<p>The preferred electronic mail address is rayboehm@cnj.digex.net. </p>
<p>FAX: (732) 906-5728 </p>
<p>Voice: (732) 906-3671 </p>
<h1><a name="WhatAreFunctionPoints">What are function points and why count them?</a> </h1>
<p>In the late seventies, IBM felt the need to develop a language independent approach to
estimating software development effort. It tasked one of its employees, Allan Albrecht,
with developing this approach. The result was the function point technique. </p>
<p>In the early eighties, the function point technique was refined and a counting manual
was produced by IBM's GUIDE organization. The International Function Point Users Group
(IFPUG) was founded in the late eighties. This organization produced its own Counting
Practices Manual. In 1994, IFPUG produced Release 4.0 of its Counting Practices Manual.
While the GUIDE publication and each release of the IFPUG publications contained
refinements to the technique originally presented by Albrecht, they always claimed to be
consistent with his original thinking. In truth, it is still very close considering the
nearly two decades that have elapsed since Albrecht's original publication! </p>
<p>During the eighties and nineties, several people have suggested function point counting
techniques intended to substantially extend or completely replace the work done by
Albrecht. Some of these will be briefly discussed in this FAQ. However, unless otherwise
specified, information in this FAQ is intended to be consistent with IFPUG Release 4.0. <br>
</p>
<b><p>Function points are a measure of the size of computer applications and the projects
that build them. The size is measured from a functional, or user, point of view. It is
independent of the computer language, development methodology, technology or capability of
the project team used to develop the application.</b> The fact that Albrecht originally
used it to predict effort is simply a consequence of the fact that size is usually the
primary driver of development effort. The function points measured size. </p>
<p>It is important to stress what function points do NOT measure. Function points are not
a perfect measure of effort to develop an application or of its business value, although
the size in function points is typically an important factor in measuring each. This is
often illustrated with an analogy to the building trades. A three thousand square foot
house is usually less expensive to build one that is six thousand square feet. However,
many attributes like marble bathrooms and tile floors might actually make the smaller
house more expensive. Other factors, like location and number of bedrooms, might also make
the smaller house more valuable as a residence. </p>
<p>Bill Hufschmidt, a seasoned function point practitioner, always stresses that the first
three letters in function points are FUN. People who enjoy function point counting and can
justify it on that basis should do so. The following are more hard nosed reasons: <ul>
<b>
<li>Measure productivity</b> -- Many executives have come to the conclusion that regardless
of their core business, they are also in the software business. Calculating several
variations on the function points produced per month theme tells them how well they are
doing in this regard. <b></li>
<li>Estimate development and support</b> -- Since the beginning, function points have been
used as an estimating technique. Estimating is obviously necessary for the cost benefit
analysis that justifies application development. Even for strategic projects that need no
quantitative justification, accurate estimation is required for proper staffing. <b></li>
<li>Monitor outsourcing agreements</b> -- Companies outsourcing significant parts of their
IS requirements are concerned that the outsourcing entity deliver the level of support and
productivity gains that they promise. Outsourcers, like CSC and IBM Global Services,
frequently use function points to demonstrate compliance in these areas. <b></li>
<li>Drive IS related business decisions</b> -- Companies must analyze their portfolios of
applications and projects. The size in function points is an attribute that needs to be
tracked for each application and project. Along with other data, this will allow decisions
regarding the retaining, retiring and redesign of applications to be made. <b></li>
<li>Normalize other measures</b> -- To put them in perspective, other measures frequently
require the size in function points. For example, 100 delivered defects on a 100 function
point system is not good news. The same 100 delivered defects on a 10,000 function point
system are much easier to take. </li>
</ul>
<p>There are a number of frequently asked questions that are related to the more general
question of "What are function points?" These questions and answers follow: </p>
<h2>Can function points be used for GUI based systems? </h2>
<p>Yes. When the function point technique was originally developed, it was not applied to
systems with Graphical User Interfaces (GUIs). There were no systems with GUIs! Even as
late as three years ago, there was a certain amount of disagreement between function point
practitioners regarding how to count these systems. </p>
<p>Two years ago, IFPUG completed Release 4.0 of their Function Point Counting Practices
Manual. It contains the official rules for, and extensive examples of, counting GUI based
systems. Subsequently, IFPUG produced a case study that contained the count of an entire
GUI-based system. </p>
<p>Unfortunately, you can still find practitioners who are not familiar with the new rules
and have not updated their course material to reflect current technology. Do not tolerate
this! Just like any other professional you rely on, your function point specialist(s)
should have knowledge that is up to date. </p>
<h2>Can function points be used for client/server systems? </h2>
<p>Yes. In the simplest case, the user may be unaware of whether she is using a program
running on a central computer or a set of programs running on various computers across a
network. In fact, in the wonderful world of client/server, your application can abend
(reach an abnormal end) because of a failure on a computer that you did not even know
existed! This presents a strong argument that client-server systems can be counted just
like any other ones. Unfortunately, client/server does introduce some complications into
the counting process. </p>
<p>Accounting for the development of a technical infrastructure is often a challenge. The
technical infrastructure can be composed of database managers, middleware, APIs and other
components that are used by the developers. Installing this infrastructure is often a
completely separate project. Are there function points associated with this project? If
so, is the count performed as if the application developers are the users of the
infrastructure? Of course, it is possible that some of the business users of the
enterprise will interact directly with this infrastructure when doing end-user application
development. Will this change the answers to any of the preceding questions? </p>
<p>Even when confining our attention to the application programs, identifying the
boundaries in client/server systems development projects can often be tricky. In the
simple case, where an application is developed partially on a client and partially on a
server, the boundary includes them both. However, many projects call for the development
of server applications that will interact with other pre-existing clients and servers in
addition to a client program that is being developed as part of the project. In this case,
multiple boundaries may need to be considered. </p>
<h2>Can function points be used with object oriented development? </h2>
<p>Yes. You probably see the pattern here! The short answer is that they can be used to
measure these applications and their size is the same as if object oriented development
had not been used. This is because the function point count for an application is
independent of the technology used to develop the application. However, the use of object
orientation does tend to impact the function point count of the project that builds the
application. </p>
<p>In the simplest case of software development, an application is built from scratch by a
single project. In this case, the application and project function point counts are the
same. For example, building a 1000 function point system would be a 1000 function point
project. Object orientation is quickly making this simple approach to application building
a thing of the past! </p>
<p>At a minimum, using object oriented development techniques allows the developer to use
pre-built Windows editing controls and the like. When object orientation is fully
embraced, developers can incorporate major chunks of functionality into their
applications. For example, OLE Automation allows an application to completely harness the
power of Microsoft Project version 4.0. Counting in these situations requires good
engineering judgment and experience. </p>
<p>One school of thought has been simply to incorporate all of the functionality into the
application and project counts. This makes sense for minor functionality that would not be
separately recognized by the user anyway, like editing controls. However it is often a
problem for more function rich components. If the user realizes that much of the
functionality that is being provided has actually come from a purchased application, will
he be willing to give the developer "credit" for all of that functionality? If
the developer claims all of the functionality of both the custom written portions and the
acquired portions of the project, will the function point technique still be usable for
estimating? </p>
<p>It should be stressed that these considerations have been around longer than object
oriented development. However, years ago these were the exceptional cases. Now, they are
becoming the norm. The function point community still needs to codify its approach to
handling these situations. </p>
<p>The International Function Point Users Group (IFPUG) has just published a case study
showing the count for an application that was developed using object oriented techniques.
It is Case Study number 3. </p>
<h1><a name="WhenCanYouCountFPs">When can you count function points?</a> </h1>
<p>Like voting, you should count early and often! The sooner you can quantify what a
project is delivering, the sooner it is under control. Traditionally, many practitioners
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -