function point faq.htm

不晓得干嘛用的

    believed that function point counting could not occur until product design (or external
    design, another name for the same thing) was complete. IFPUG members have long realized
    the importance of being able to count function points earlier in the development life
    cycle. Under IFPUG 4.0, there are rules and guidelines that make it possible to count
    function points once the requirements have been finalized. Many practitioners use
    heuristics that allow them to estimate function point size even earlier in the life cycle.
    The paragraphs below discuss the function point estimating and counting that can occur at
    various points in the life cycle. Since everyone uses different live cycles, the stages
    will be described in terms of the project's progress on related deliverables. </p>
    <p>If the life cycle begins with something like a feasibility study, it is usually
    impossible to count function points at this time. However, the number of function points
    can be estimated using the same techniques currently being used to estimate lines of code
    or effort. If a similar project was 2,000 function points, the best guess at this time is
    that this project is also 2,000 function points. </p>
    <p>During requirements gathering the estimate of size in function points can be refined
    continuously. For many projects, a logical data model is developed. People's definitions
    of a logical data model vary, but at some point, this model is not attributed, nor is it
    in third normal form. However, at this point the analyst can start to identify which
    entities will need processes to add, change, delete and display them. If the equivalent of
    a Yourdon context diagram has been produced, then the interactions with users and external
    systems specified. At this point, a good estimate of function point size can be made
    assuming that the transactions identified are all of average complexity. Even at this
    point of the life cycle, it is usually possible to predict the Value Adjustment Factors
    with fair accuracy. </p>
    <p>Once the business requirements have been completed it is possible to accurately count
    the function points for the application. At this point, the logical data model should be
    fully attributed. All of the system interactions, including screens and reports, should be
    identified and the data items associated with them specified. There is no need for the
    screens or reports to be formatted at this time. </p>
    <p>As was already stated, following external design or product design it is possible to
    get an accurate function point count. Of course, you should have gotten an accurate count
    at the completion of requirements. This is the time to start considering requirements'
    volatility and its impact on the project. The simplest type of requirements' volatility is
    scope creep. If, at the end of requirements, you measured the project as 1,000 function
    points, and then, after product design, it measures 1,500 function points, you have at
    least a 50% scope creep. </p>
    <p>Other forms of requirements' volatility can be more insidious. For example, you might
    measure 1,000 function points at the end of requirements and 1,000 function points at the
    end of project design. Unfortunately, most of these later function points are for
    functions that are completely different from the ones identified in the requirements. Some
    people refer to this as breakage. Whatever it is called, it needs to be tracked. The
    farther into the life cycle this occurs, the more expensive each such change becomes.
    However, since the function point size did not change, the impact of these changes is
    often ignored. These changes need to be tracked as enhancement function points. In this
    way their impact can be properly considered when the project needs to be re-estimated. </p>
    <p>In theory, there should be no changes in function point count between the end of
    product design and the end of acceptance testing. Of course, in theory, there is no
    difference between theory and practice; in practice, there is a big difference! It is
    during this time of implementation and testing that changes become progressively more
    expensive to make. Very often, users and project managers horse-trade change requests,
    features, costs and schedules throughout this time. Function points can be used to
    quantify these negotiations. However, they must be used properly. It is not wise to
    exchange a 100 function point enhancement for a 100 function point reduction in
    functionality. The work already expended on the 100 function points to be dropped must
    also be considered. Again, using enhancement function points can make this process easier
    on all participants. </p>
    <p>It makes sense to update the function point count at the end of the project. The
    project should be reviewed with the idea of making future project estimates more accurate.
    Application size is also a factor that determines the required level of support. The user
    community needs to decide whether the business value associated with an application is
    worth the effort that will be required to support it. </p>

    <h2><a name="HowDoYouCountFPs">What are the steps to counting function points?</a></h2>
    <p>The current IFPUG manual is organized in such a way that chapters two through eight
    correspond to the steps necessary to perform a function point count. The following steps
    will give an equivalent count, but stress some practical considerations. Deviations from
    the IFPUG presentation are explained. <br>
    </p>
    <b><p>Plan the Count.</b> This step includes two IFPUG steps: determine the type of count,
    and identify counting boundary. It also includes critical logistics around the
    identification and assignment of a system expert. </p>
    <p>Currently, IFPUG identifies three types of counts: development project counts,
    enhancement project counts and application counts. They are related. The development
    project count also yields the first application count for an application. In any event,
    identifying the type of count you are being asked to perform is usually not too
    complicated. <ol>
      <li>On the other hand, identifying the counting boundary can be complicated. Proper
        identification can require advice given in the IFPUG manual, any training that you might
        have received and hints from other parts of this FAQ. In some cases, changing the counting
        boundary will make it necessary to do a different type of function point count. For
        example, it may make it clear that what appeared to be a development project count was
        actually an application count followed by an enhancement project count.<br>
        The IFPUG manual does not really mention it, but there are three sources of counting
        information: the system to be counted, its documentation and the system expert. These
        sources are presented in increasing order of value to the counting process. You can
        perform a count if you only have access to the software, but this is usually very time
        consuming. Counting from the documentation if usually fast enough if the documentation is
        complete and easy to understand. It never is! The system expert can walk you through the
        other information and answer questions as they arise during the count. Fight to get the
        system expert assigned to work directly with you for the entire count.<br>
        Identification of the system expert is not always easy. It also depends on the counting
        boundary. An expert for one component of an application may be unaware of the particulars
        of other components. Nevertheless, the system expert is often called an application
        architect or lead designer. It may be a user who is very familiar with the application. It
        is usually not the project manager. Interestingly enough, the project manager is usually
        more willing to work with you directly than to assign the system expert. This may be the
        best heuristic for system expert identification! <b></li>
      <li>Explain counting process.</b> This is not discussed in the IFPUG manual at all. If you
        are using a system expert, you may need to explain what you intend to do, why you are
        counting, what you plan to do with the information and things of that nature. Of course,
        if you are working in a company with an established metrics program, this may not be
        necessary. It is important to bring this to closure quickly. You cannot spend the day
        doing training. Likewise, you cannot allow you count to be interrupted continuously to
        defend the use of function points. This step must be quick and fairly final in nature. <b></li>
      <li>Calculate the Value Adjustment Factor (VAF).</b> The IFPUG manual describes this step
        closer to the end of the counting process. That is where the value is needed from a
        calculation perspective. There is another reason why some practitioners like to postpone
        this step. During the main count, there are often times when the system expert will
        complain that some feature is not getting enough function points credited because of it.
        The counter often claims that that feature will be revisited when the VAF is calculated. <br>
        There are also arguments for performing this step in the beginning. It is a fast step, and
        sets a fast pace for the remainder of the count. In addition, the VAF gives insight into
        the complexity of the overall system. It is a piece of information that can be shared with
        the system expert at that point. This type of feedback keeps the system expert interested
        in the counting process. <b></li>
      <li>Count data function types.</b> This is straight out of IFPUG. Data functions are either
        Internal Logical Files (ILFs) or External Interfaces Files (EIFs). The count is done by
        examining a data model or asking the system expert about the application's main categories
        of data. This must be done before the transactions, since the complexity of the
        transactions is dependent upon the way the data functions are identified. <b></li>
      <li>Identify transaction function types</b>. This is also straight out of IFPUG. Transaction
        function types are External Inputs (EIs), External Outputs (EOs) or External Queries
        (EQs). This is typically the longest part of the count, and the part where the system
        expert's assistance really saves time. Complexity of each transaction is based, in part,
        on the number of data types it references. The system expert can usually make this
        determination without consulting any documentation. <b></li>
      <li>Perform calculations.</b> This is thoroughly explained in the IFPUG manual and has never
        been a source of confusion for anyone! <b></li>
      <li>Verify counts.</b> The IFPUG manual does not mention this. It makes sense to give the
        system expert a copy of the counting sheets and ask that they be reviewed. The system
        expert should not be expected to check for correct rule interpretation or calculations.
        The expert should be instructed to review to see if any areas of functionality have not
        been considered. It is usually best to do this right after the count, even if you intend
        to review the count yourself for some tricky rule interpretations. <b></li>
      <li>Review results.</b> One of the most common reasons that metrics programs fail is that
        people are forced to wait too long for program results. In the day or two following the
        count, the results should be shared with project personnel and any corporate sponsor of
        the measurement. </li>
    </ol>
    <h2>How long should the count take? </h2>
    <p>This is something most people do not want to discuss. IBM expects someone to be able to
    count 100 function points per hour. Most function point consultants feel that this is much
    too low. Some consultants claim to count as many as 4,000 per day. However, the 100
    function points per day counting rate may be right if it includes the preparation and
    possible presentation of a complete project review. </p>
    <p>There are usually some tasks in a count that take a fixed amount of time, independent
    of the size of the count. For this reason, some consultants feel that most applications
    can be counted in one day. Some use the same logic and indicate that an application can be
    completed in one half day. </p>
    <p><br>
    <br>
    </p>
    <b><font SIZE="5">
  </blockquote>
  </font></b>
<p align="center">
<MAP NAME="FrontPageMap">
<AREA SHAPE="RECT" COORDS="361, 4, 423, 32" HREF="nov99.htm">
<AREA SHAPE="RECT" COORDS="29, 1, 160, 30" HREF="mailto:[e-mail]">
<AREA SHAPE="RECT" COORDS="217, 3, 296, 29" HREF="nov99.htm"></MAP>
<img ismap usemap="#FrontPageMap" border="0" height="43" alt="News_letter_copy3.gif (6435 bytes)" src="News_letter_copy3.gif" width="521"></a>
</blockquote>
</body>
</html>