300+ TOP Function Point Analysis Interview Questions [REAL TIME]

1. What Is Function Point Analysis? What Is Function Point?

Function Point Analysis (FPA) is a software measurement technique based on the users point of view. It measures the software functions and Function Point (FP) is its measuring unit. The method has as an objective to become independent of the technology being used to build the software. In other words, FPA looks to measure what the software does and not how the software was developed.

This being said, the measurement process (also called function point counting) is based on a standard evaluation of the user’s functional requirements. This standard procedure is described by IFPUG in the Counting Practices Manual.

The main estimation techniques used for software development projects assume that the software size is an important driver for the estimation of its development effort. Thus, knowing its size is one of the first steps in the effort, duration and cost estimation. 

At this point it is important to know that function points do not measure effort, productivity nor cost directly. It is exclusively a software functional size unit. This size, along with other variables, is what could be used to derive pro-ductivity, estimate effort and cost of software projects.

2. Who Created Function Points Analysis (fpa)? Why It Was Created?

Function Point Analysis (FPA) was invented in 1970’s as a result of a project develo-ped by the researcher Allan Albrecht of IBM. His job involved a productivity analisys for software projects developed by a service unit of IBM. To do this he developed a method to measure software independently of the programming language used, checking only the external aspects of the software, primarly based on the user’s vision.

You can read the complete and original work in which Function Point Analysis was presented in October of 1979:  Measuring Application Development Productivity — Allan J. Albrecht. This article is much more than just a historical curiosity, and is still applicable today.

3. Is The Function Point Analysis (fpa) Technique Owned By Some Company?

No. Despite having emerged in IBM, the result of this project was opened to the whole software community.

Nowadays, the standard recognized for Function Point Analysis (FPA) is defined in Counting Practices Manual (CPM) mantained by the IFPUG — International Function Point Users Group.

The IFPUG is a nonprofit entity composed by people and companies from all over the world, with the purpose of promoting a better management of the development proces-ses and software maintenance by the use of the Function Point Analysis.

4. What Are Function Point Analysis (fpa) Benefits?

We can highlight several benefits on applying function point analysis in organizations:

• A tool for determining the size of a purchased package by counting all the functions included.
• Provides assistance to users in determination of benefits of a package for their organization, by counting the functions that specifically match their requirements. When assessing the cost of the package, the size of the functions that will be effecti-vely used, the productivity and cost of the staff is possible to perform a “make or buy” analysis.
• Supports the analysis of productivity and quality, either directly or in conjunction with other metrics such as effort, cost and defects. But if the development method of the organization is chaotic (each project is developed in a different way), even if the func-tion points counting of the project and the effort record have been made correctly, the analysis of productivity among the projects would have been impaired.
• Supports the project scope management. A challenge of any project manager is to control “scope creep”, or the increase of the scope. To make estimates and measure-ments of function points of the project at every stage of its life cycle is possible to deter-mine whether the functional requirements increased or decreased, and whether this variation corresponds to new requirements or requirements that already exist and were just more detailed.
• Complements requirements management to assist in verifying the soundness and completeness of the specified requirements. The process of counting function points favors a structured and systematic analysis of the requirements specification and brings similar benefits to a peer review process.
• A tool for estimating costs and resources for software development and maintanance. By carrying out a count or estimate function points early in the lifecycle of a software project, it’s possible to determine its functional size. This measurement can be used as input for many models of effort, time and cost estimation.
• A tool to support contract negotiation. Function points can be used to generate seve-ral service level indicators (SLA – Service Level Agreement) in software development and maintenance contracts. Besides that, it allows contract establishments by using unit price – function points – where a unit represents a tangible asset to the client. This modality allows for a better risk distribution between the client and provider.
• A normalization factor for software comparison or for comparison of productivity in the use of differents methods. Several organizations, such as ISBSG, provide a data repo-sitory of software projects that enable the implementation of benchmarking with similar projects in the market.

5. Is It Necessary To Be A Software Developer (systems Analyst, Programmer, Etc.) To Use The Function Point Analysis (fpa)?

No. The great advantage of the Function Point Analysis is that it is based on the USERS POINT OF VIEW, allowing its concepts to be understood by the developer and the user. The aim of the technique is to measure the functiona-lity that the software provides to the user regardless of technology used for its implementation. This measurement is based only on the requirements that the software must attend to.

6. Is There An Entity Or Organization Responsible For The Standardization Of Fpa?

The standard recognized by the software industry for FPA is the Counting Practice Manual (CPM) maintained by the IFPUG (International Function Point Users Group).

The IFPUG is a non-profit entity composed of people and companies of various countries whose purpose is to promote better development process management and maintenance of software through FPA.

7. Has There Been Any Enhancements In Function Point Analysis (fpa) After Its Creation?

Yes, since the first publication of Function Point Analysis proposed in 1979, several refinements were incorporated to the technique over the years. -And this process conti-nues. But the gist of the technique has changed very little. This results from the fact that the technique is oriented to measure the functionality that the software provides to the user, regardless of the technological platform on which the software, development methodology or programming language used for its construction.

After the founding of IFPUG in 1986, systematic and consistent development of the Function Point Analysis was created. IFPUG has a committee responsible for the editing and updating of the Counting Practices Manual, which currently is at version 4.3, this version was published in January 2010.

There is no defined frequency for the IFPUG to publish updates to its manual, and the updates do not seek radical changes. They have the intention to provide further clarifi-cations regarding the definitions and counting rules, thus improving the consistency of measurements and reducing the subjectivity in the interpretations.

8. Who Uses Function Point Analysis (fpa) In The World?

The IFPUG has affiliates in more than 40 countries around the world, having a strong presence in Germany, Australia, Brazil, Canada, Korea, United States, India, England, Italy, Colombia, Uruguay, Mexico, Argentina and the Netherlands.

Companies such as IBM, Unisys, Xerox, HP, CitiGroup, Tata Consulting Services, Lockheed Martin EIS, Booz Allen & Hamilton, Nielsen Media Research, Banco do Brasil, Citibank, HSBC, Indra , Bank of Canada, Ralston Purina Co., Banco de la República (Central Bank of Colombia), Northrop Grumman Corp, Samsung SDS Co Ltd, BASF Corporation, Banco Central de Chile, Accenture, IBM, Petrobras, Pepsi Co, Compuware, Pricewaterhouse Cooper, Vale, Banco Santander, Petrobras and Telefonica, among others, are using function points for software project management.

9. Is It Possible To Use Function Point Analysis (fpa) In An Object-oriented Design?

Yes. Function Point Analysis (FPA) is an independent technology technique used to model or implement software. Therefore, a piece of software has the same funcational size in function points, whether it´s developed using OO technology or another appro-ach.

What may be different between the two approaches is that in OO design, productivity (hours/FP) may be better due to reuse. Making an analogy with a construction building: we can build a house of 100m2 in the conventional way or using prefabricated modu-les. In both cases, the size of the house will be the same, the only differing factors will be the construction time or cost.

10. What’s The Size To Consider That A Software Project Is Small, Medium Or Large?

It is desirable within an organization that the project management process be scalable in accordance with the project size. Big projects need more rigorous and formal on its management than small projects. Using the same approach for any size project means burdening smaller projects with a relatively high cost of management, ie, waste of resources.

There is no industry standard definition to define if a project is small, medium or large. This is a relative concept and it must be solved by each organization. In fact, it’s not usually necessary to define a project in 3 levels (small, medium and large). For organi-zations that usually work in a similar way, that classification could be unnecessary and using the same management process for all projects might be the best approach. Some organizations have a management tactics for just two types of projects (small and large). Also, it is not prohibited if an organization wants to define more than 3 levels for the project size; (for example: small, medium, large and extra large). But this is not usual. 

In summary, the concept of small, medium or large is very relative; each organization can establish it own criteria to appoint a project in relation to its size.

11. What Is The Price Of One Function Point ($/fp)?

The value of $/FP will vary in accordance with the work required for the delivery of soft-ware functionality, in accordance with the technical standard and quality required by customers, as well as the amount of deliverables (artifacts, documents, models, etc) required by the customer. In summary, everything that affects significantly the cost but has no direct relation to the size measured by the Function Point Analysis (FPA), is computed on the function point price.

Example 1: when you hire a company just for coding and testing a system, it is expec-ted that the function point price would be lower than if you hire the same firm to con-duct the entire lifecycle of software development, from requirements gathering through development.

Example 2: the function point price only for software delivery is certainly lesser than the function point price where, besides the software, several papers must be delive-red (subproducts) as : UML models, user’s manual, online helpdesk, prototypes, test plans and cases, etc.

Example 3: Nowadays the range of available technologies for developing systems is huge, and each one can directly influence in the productivity (either positively or nega-tively) of the work to be done. Thus it is quite common in the market to have differentia-tion of $/FP in regards to the technological platform (mainframe, web, client-server, etc) and/or programming language (COBOL, C, Java,. Net, etc).

Example 4: Function Point Analysis, according to the IFPUG standard, measures the maintenance ignoring the size of the maintenance that the function will go through. Usually, the effort to maintain a function tends to be lower than to develop it. Thus, there may be a function point price differentiation in improvement projects for new, modified and deleted features.

In summary, there is not one price for a function point and also there is no public and updated price list available, where the function point price could be seen. Also because this information is considered proprietary or strategic for most organizations. But it is possible to obtain price information from government contracts through a rese-arch on the biddings that occurred in the past, through the official brazilian gazette or directly with the government organanization.

Another possibility to get this price list is using organizations that maintain the histori-cal data of software projects (e.g. ISBSG — www.isbsg.org) and provide a delivery rate indi-cators conversion (H/PF) to price ($/FP). But even if we could get a list of the $/FP value, the variation in numbers is so significant that it is easy to find a range of values whose variation between minimum and maximum can be up to 10 times, for example $ 100/FP to $ 1.000/FP.

For a more realistic price information (or cost) of the FP, it is better to derive this from projects that have already been undertaken. For projects already completed, informa-tion that is certainly available is how much was paid or charged for each project and what activities were included. If the projects functional size (FP) is not available, it could be attained through a measurement or an estimate, just by reviewing the require-ments. Having the price of the project and its size in function points,  the price per func-tion point ($/FP) can be attained. However, it is likely that your organization undertakes projects of different types. In this case, an analysis of the $/FP should be done for each category of projects, because a single price point is hardly representative for projects of different types.

12. Is It Possible To Apply The Function Point Analysis (fpa) On Tasks That Are Not Organized As Projects?

In general, this kind of work involves a very limited scope. As a result, it is difficult to establish a relationship between the functional size and others metrics such as effort, time and cost. However, it´s important to remember that Function Point Analysis (FPA) is not simply a tool for generating estimates, used in project planning. The nature of the work involved in this question is characterized not as a project, but as a continuous operation.

Take as an example the systems maintenance with estimated effort up to 200 hours. Separately, the sizing of orders that represent the requirements (not always functional) object maintenance may not have a linear relationship with the effort involved for its achievement. However, taking into account the knowledge with all of the requests in a given period of time, we can arrive at different conclusions.

For example, a given maintenance request did not involve the addition, modification or elimination of certain system features. In this case, it is useless to know that the main-tenance functional size will have no function points. But the system that gives mainte-nance has a functional size. You can monitor the amount of maintenance hours per function points of this system. This trend helps to evaluate whether or not it is time to replace this system with a new one.

Suppose that there is a process in this organization where, after the service order has been served by the maintenance team, the product goes through an approval process. The feature set in the approval may be scaled in terms of function points. Likewise, the amount of identified defects in the process can be documented. Monitoring the interaction of these two metrics — Function Point and Defects — during a period of time can bring out problems in the maintenance process. Based on this trend it is pos-sible to take actions to reduce this relation.

13. Two Functions, That Are Significantly Different In The Implementation Effort, Are Scaled With The Same Number Of Function Points. Doesn´t It?

Function Point measures the functional size of the software and not the effort involved in its design and construction. The higher the linearity found between functional size and this effort (productivity), higher the practical value of the measurement obtained. The more this relationship is linear, more easily other measures can be extrapolated from the functional size, as the cost and effort, for example.

If it’s looked at a micro level, in assessing the size of two specific transactions, certainly the potential deviation in derived productivity is high, but as we expand our sample size, we realize that the extreme situations compensate themselves and, on average, we can observe higher linearity in the relationship between effort and functional size.

Let’s think about some alternative metrics to the function point, evaluating the impact of these considerations on these metrics, for example, Lines Of Code. In the Organization as a whole, or even in a specific project, there are also situations where the counting of lines of code number is not directly related to the effort involved in the specification, documentation and testing of the project. In other words, there are two projects with dif-ferent quality requirements or increased demand in the specification, where in spite of one being more “complex” and requiring more development effort, the resulting soft-ware has fewer code lines than the other. Not to mention the other limitations inherent in the LOC metric.

14. Why Are There No Tools For Automatic Function Points Counting Of A System?

There are several software products that from a program model or its source code, cal-culate its size in function points. However, comparisons between the results produced by different tools for the same system, frequently have an unacceptable variation. These numbers, also often differ greatly from a manual count.

The answer to this variation is in how these tools calculate the number of function points. Some are based on files, screens, reports and other elements to derive a num-ber. Although there is often a direct relationship between these objects and data functi-ons and transactions functions of Function Point Analysis (FPA), it must be remembe-red that the technique measures only the logical functions of the system. And these tools have difficulties in differentiating logic functions from physical functions. For example, not every file or table from a program file corresponds to an internal logical file or external interface file. Or even an elementary process can be implemented through multiple screens. To do the measurement in a correct way, the software should have enough intelligence to make this judgment. That is, this software would have to have the skill to read the program and interpret the user´s requirements. However, there is no software with this artificial intelligence.

Other tools are based on the backfiring technique, which is to derive the number of function points from the program number of lines of code, based on a previous relati-onship established between LOC and FP. However, this is a technique that has been widely criticized, and whose application is restricted.

There are software products to support the process of counting function points that automate a part of the process, but the decision and analysis of that should be consi-dered, remains as the responsibility of the human user who enters the data, and not of the software.

15. What Is Backfiring?

This method consists in deriving the number of function points according to the application from its physical size, measured in lines of code (LOC), using a constant conversion factor depending on the programming language. The idea has much appeal, since the counting of lines of code can be done through automatic tools and consequently, the number of function points could be derived immediately. For example, using a conversion factor of 80 LOC / FP for Java and having an application written in 80,000 lines of Java code, we get to 1,000 function points for that same application.

However, often, this technique has considerable errors when confronted with a manual count of function points of an application. This is because it assumes a linear relationship between functional size (in function points) and the physical size of the program (in lines of code), which are different concepts. Another aspect is that there is no consensus in the various organizations that publish these relationships. The numbers shown may differ as much as 100%. 

When you have a developed system scenario with a mix of programming languages, the issue is more complicated. 

Some of the reasons for this wide variation are: different assumptions in defining what is a line of code, and projects databases with many different features. Hence the necessity to calibrate the conversion factor for the reality of the projects developed by the organization. However, to make this adjustment, there must be a representative sample of projects developed by the organization in a particular language and an experienced and qualified professional to interpret the results and understand the reasons for this possible distortion for this conversion factor.

Due to these factors, applying backfiring to obtain the size in function points from lines of code is a risky technique and characterized by a large margin of error. Hence, IFPUG highlights in their FAQ, that it can even be used (with caution) in legacy systems, where a manual count is unworkable in practice and accuracy is not a critical factor. Some professionals argue that backfiring is a quick and cheap way to get the size in function points of an organization applications portfolio. Others, argue that cheap comes out expensive: it is better to invest in a manual counting of function points and have reliability of these data, with compensation in the long term.

On the other hand, many models of software estimating such as COCOMO II, use as primary data their size in lines of code. In these cases, it is very often to do the opposite: get the number of lines of code from the size in function points. This is because in the early stages of a software project, is easier to estimate or measure its size in function points than in lines of code. Even then, the above considerations remain valid on backfiring.

16. What Does Functional Size Mean In Relation To The Iso/iec Standard?

Aiming to solve the inconsistencies between various methods arising from the model of Function Point Analysis, proposed by Allan Albrecht, and to establish a more rigorous method of measuring functional size, a group called WG12 (Working Group 12) was formed, subject to SC7 ( SubCommittee Seven) of JTC1 (Joint Technical Committee One) established by ISO (International Organization for Standardization) in conjunction with the IEC (International Engineering Consortium).

As a result of the work of WG12, the standard 14.143 was established, which is split into five parts:

14143–1: Concepts Definition 

14143–2: Conformity Assessment of Software Measurement Methods in Relation to ISO/ IEC 14.143–1

14143–3: Verification of a Functional Size Measurement Method

14143–4: Reference Model for Functional Size Measurement

14143–5: Determination of Functional Domains for use with Functional Size Measurement

ISO / IEC 14.143 was developed to ensure that all the functional size measurement methods are based on similar concepts and can be tested to ensure that they behave similarly and as expected by a method of measurement, depending on the functional domains that they are applied.

At the end of 2002 the technique of Function Point Analysis, as defined in version 4.x of the IFPUG manual, was approved (under the standard 20.926) as a Functional Size Measurement Method, adhering to ISO / IEC 14143.

17. In Addition To The Ifpug Function Points, Are There Any Other Methods Of Functional Measurement?

Yes, there are three others standard methods of functional measurement:

NESMA — The association of metrics from Netherlands has its own counting manual, currently at version 2.0, whose the first version in 1990 was based on IFPUG manual. It uses the same philosophy, concepts, terms and rules of IFPUG, with some different guidelines. The measurement of a development project or an application produces results very similar under both approaches – IFPUG and NESMA. However, both organizations have different approaches to function point analysis application in software improvement projects.

Mark II — was created by Charles Symons in the mid80s. Its spread has been hampered initially because the method was owned by KPMG consultant for several years. Today is a public domain metrics method maintained by the UK Association of Metrics —UKSMA. It’s a method wich its application is restricted to the UK.

COSMIC — In 1997 a group of researchers from the University of Quebec developed a new method for measuring functional realtime systems, called Full Function Points (FFP). In 1998 a group of experts in software measurement constituted the COSMIC (Common Software Measurement International Consortium) in order to develop a new method of measuring functional size based on the best features of existing methods and incorporating new ideas. This new method proposed in 2000, called COSMICFFP, in practice was a refinement of the FFP method. It is not a technique as widespread as the IFPUG, but there is much research being conducted on this method.

18. What Are The First Steps Towards Implementation Of The Function Point Analysis (fpa) In My Organization?

The first step is to clearly identify what are the goals of the organization. Function Point Analysis can be used for several purposes: estimation of software projects, unit of contracts measurement, support for quality and productivity control, benchmarking and metrics program.

Each approach has its specific peculiarities; however there are aspects common to all them, highlighted below:

1. Gain the support of the organization’s direction. Keep in mind that the results of the use of Function Point Analysis in the organization are not always immediate and that the success of its use will depend on the dedication and use of human and financial resources, as well as any program that focuses on processes improvement.
2. Take advantage of existing opportunities in the organization that may have some common goals. Examples of these initiatives are: ISO, Six Sigma, CMM, PMI, Balanced Scorecard. Taking these initiatives and knowing how to relate (and show to sponsors) Function Point Analysis may contribute to some of the organization´s goals, and will make it easier to accept.
3. Empower yourself. Knowing the correct technique is essential. It’s amazing the number of cases that Function Point Analysis has being applied incorrectly, and that, invariably ends in failure. The official reference of the technique is the IFPUG — CPM (Counting Practices Manual). Interesting actions in this regard can be:

   Hire a closed class for the whole team involved, so you can adjust the load or summary of the course with the objectives of the process and the reality of the organization. In this case, FATTO usually holds a service package with one week duration: two days to teach the course Training Function Point Analysis; and three days for consulting the beginning of the process and mentoring on the application of the technique in organization’s practical cases.

   Sign up key people that are involved in the process in open Function Point classes. FATTO regularly teaches open courses in several cities in Brazil. See our course schedule for more information.

4. Set modest initial goals. Start with a pilot project in a simple system. Evaluate the results, make adjustments, review the objectives and move on.
5. Be aware of technique limitations. There are domains where Function Point Analysis is is restricted. For example, in systems optimization, the technique is not suitable for measuring parts with high algorithmic complexity.
6. In doubt, make an analogy with the square meter. In general, it is sufficient to solve the issue.
7. Seek help if necessary. An outside consultant can avoid unnecessary troubles, hasting the process, bringing experience and helping to correct the directions.
8. Do not compare apples with oranges. Comparisons should only be made between projects that have similarities (development process, technology platform, business area, etc).

19. What Is The Initial Guidance For The Application Of Function Point Analysis (fpa) In Software Projects Estimations?

Besides the general considerations presented in the previous post, the following are some specific guidelines to use the function point in estimates.

Although some authors quote the use of function points directly to derive initial estimates of duration, defects and team size, the most common use is for effort estimation (usually amount of hours).

The process to estimate effort is very simple: Given a productivity (hours per function point) in a given development environment, simply multiply it by the functional size of software to obtain the desired estimate.

However, the key question is: which productivity should be employed? Many people use market indicators published by various organizations. But many of these people are frustrated with the outcome.

The answer is: there are no magic numbers. The productivity to be employed is specific to each organization and not a market average. It must reflect the reality of the development process of the organization in a particular context: development tool, business area or technology platform.

To obtain its own numbers, the organization may use the data from previous projects and recover information such as effort and size in function points. Grouping similar projects, it is possible to obtain a reliable indicator of productivity.

20. What Is The Initial Guidance For The Application Of Function Point Analysis (fpa) In Systems Development Contracts?

Besides the general considerations presented in previous posts, below are presented some specific guidelines for the use of function points in the three main models used for hiring: ManHour, Global Fixed Price and Unit Price.

In case the contracting model used is that of manhour, where the provider remuneration is not based on presented results, yet in the quantity of work hours in an established period, FPA can be used, for example, for monitoring productivity for the team. To do so, just measure the result data (function points) and the effort data (hours) together and make evaluations relating to both pieces of information.

When hiring is based on global fixed price, the Function Point Analysis (FPA) can be used as a normalization factor of price in order to ensure that the amount charged for additional functionality not provided, or during the maintenance phase, is consistent with the amount charged at the time that the service was hired.

The project’s size is measured in function points and, from the total amount charged by the supplier for the project, the value of the function point is calculated. The new proposals are measured regarding its size and then the value of the function point to obtain the amount of new features is applied . Then this value can be compared to the value proposed by the supplier.

However, the model that can better balance the deficiencies in hiring manhours and the global fixed price is based on unit price (function points). If the supplier delivers a low productivity, he will not be paid for the extra time consumed. Otherwise they will incur more profit in regards to the service provided. If there is an increase in  the scope of service, stressful negotiations will not be required to establish the value for the additional service.

In this mode, an important factor is to properly define the value of the function point, as we can see in this post.

In any of the types of contracts adopted, we must be careful with interest conflicts: the measurement of service in function points should never be performed only by the supplier, because it will be paid precisely by the measuring result! You can observe this undesirable practice in some organizations (including government). Internal staff can be used to perform the measurement, or worst case scenario, validate the measurements made by sampling. Another option is to hire an outside company for this service.

21. In What Situations Can Be Interesting To Outsource The Function Points Counting?

The evaluation made to outsource the function point counting services involves basically the same questions to outsource any other activity. Specific situations are highlighted below where the outsourcing may be favorable to the contracting organization:

In the initial period of implementation of the technique in the organization, the counting of some projects by an experienced professional with the shadowing by the client team can haste the process and also help in absorption of practical knowledge by the team. Its a type of mentoring of sorts.

An experienced professional has more agility in the counting process. If the organization does not have anyone with this profile and when the counting scope is too large and the time to do it is restricted, it could be beneficial to hire an outside expert in counting. This would be done with interaction with a professional from inside the organization that knows the systems to be counted.

When the counting needs are sporadic, the costbenefit to train a professional inhome and keep him updated may be disadvantageous in regards to hiring an experienced professional.

When the function point counting is a systematic need, is important to have internal professionals trained for the task. In this case, outsourcing can be convenient during a peak demand for this activity.

When it is necessary that the counting must be done (or audited) by a certified professional (CFPS).

FATTO has a team of certified experts that can help your organization not only in the process of function point counting , but also in the correct application of the Function Point Analysis (FPA) on estimates, the measurement program and contracting software. Please contact us for more information.

22. What Are The Use Case Points?

Until a few years ago (early 90s) there was a false notion that Function Point Analysis (FPA) was not adequate to measure objectoriented systems. Those who shared this concept, in practice, don´t really know Function Point Analysis.

With the spread of construction and design of objectoriented systems, there was also a change in the way in which specifying and modeling systems was done. The UML and Use Cases quickly became industry standard of software.

Within this context, in 1993 Gustav Karner proposed the methodology of the Use Case Points (based on Function Point Analysis) in an academic article  with a view of estimating resources for software projects using objectoriented development and using the Objectory process.

The PCU measurement process is summarized in:

1 — Count the Actors and identify their complexity
2 — Count the Use Cases and identify their complexity
3 — Calculate the unadjusted PCU
4 — Determine the Technical Complexity Factor
5 — Determine the Environmental Complexity Factor
6 — Calculate the adjusted PCU

With the results of these measurements and knowing the average productivity of the organization to produce a PCU, the total effort for the project could be estimated.

23. What Kind Of Software Can Be Measured By Function Points?

FPA is a technique to measure the functionalities given by a software to the users; and this measurement is always made on an external perspective, the users’ perspective. However, it is important to say that the concept of user for FPA is not only the one of the enduser of the software. The user for the FPA is any person or thing that interacts with the software at any time. In other words, the user for FPA can be both the person acting as enduser to the software and another software that uses the services of the software in analysis.

Considering that every and any software exists to offer one or more services (functions) to someone (person or thing); it is concluded that every and any software can be measured by Function Points.

A common mistake for beginners with FPA is to only consider the endusers´point of view. In this case some types of software will be partially (or completely) “invisible” to this user. Then they mistakenly conclude that FPA does not work for that kind of software. The most common is for the person to learn the principles of the FPA applied to systems with screens and reports. However, when this person faces some software domain which do not have screens, like batch processing, middlewares, basic softwares, it is natural to have some difficulties on measuring it.

Let’s imagine that the goal was to measure a printer’s driver. Well, there is no enduser (person) for this kind of software. In this perspective, the printer’s driver is invisible to the enduser. However it exists to offer services to someone; in this case, the operating system. Thus, analyzing the printer’s driver in the perspective of the operating system, it is possible to see functions, for example: to start the the printer, inform the general situation of the device, eject a sheet of paper, print, alert the level of the ink, etc…

24. Can Fpa Be Used To Produce Estimates For Acceptance And System Testing?

In some articles, we frequently face many distorted statements and questions regarding the technique of function point analysis, which does not show anything besides a lack of knowledge about the subject. Who has not heard the false statement “function point analysis doesn’t serve to measure objectoriented systems”?

More recently, with the consolidation of the UML as the standard market language for analysis and objectoriented design, another frequent false claim is that the function point analysis is not meant to measure systems whose requirements were expressed according to specifications of use cases. A specific discussion of this issue was presented in the March 2004 Bulletin.

Since the late 90’s a test management technique that originated in Holland, called “TMap — Test Management Approach” is gaining traction, driven by the wave of process improvement initiatives based on quality standards such as ISO and CMM. Its implementation is supported by a test estimation technique called Test Point Analysis (TPA) which, in turn, is based on Function Point Analysis (FPA).

TPA is used specifically to estimate the effort requiredin the execution of acceptance and system testing. For this, the TPA considers relevant, besides the functional size determined by function points, two other elements: the testing strategy and the productivity. Even when the element is “size”, it adds more factors that have more influence on the effort than specifically on functional size, as algorithmic complexity,  degree of integration with other functions and functional uniformity.

Although it is a consistent and useful technique for increasing the quality of the process and software product, TPA preaches one more fuzzy concept on the analysis of function points when it says that this cannot be used to estimate the effort in activities involving acceptance and system testing. Nevertheless , this means that the Function Point Analysis (FPA) considers the particularities of the development process while applying the technique of counting. Which is not true.

The result of TPA application is measured in a unit of effort (hours), unlike the function point analysis, which measures the functional size of software project. Thus, as indeed does not directly measure the effort used in the tests, the FPA also does not measure the effort used in the analysis phase, design or construction of the software. Its main function is to measure the functionality delivered by the software project. However, function points can be used perfectly well as an input to a process of effort estimation of different stages of development, as discussed in the January 2004 Bulletin.

The biggest benefit of TPA is being able to gather, in a systematic way, the factors that influence the effort of a specific stage of the development process, producing more accurate results.

25. What Does The Term “user” Mean In Terms Of Function Point Analysis (fpa)?

When it comes to the information technology area the term “user” is usually referring to the person who uses or interacts with software.

Being that Function Point Analysis (FPA) is a standard method for measuring software from the user’s point of view, in this context, the term “user” has a broader meaning. According to the Counting Practices Manual, a user is any person or thing that communicates or interacts with the software at any time. That is, beyond one person, a user may be a group of people who have a specific role during their interaction with the software, the department manager, another software or equipment. And for the Function Point Analysis (FPA), interacting with the software means sending data to the application or receiving data from it.

It should be noted that this definition of user has a meaning very close to the concept of an actor in a use case: any person or thing that interacts with the system and expects an observable value result produced by executing one or more cases of use.

Taking this widely defined user concept into consideration, during a function point count, it is appropriate to look at the set of possible users whose vision better represents the functions that the application provides. For example, an ATM application has the following users: the bank customer, the agency official, the department manager. Base the count of this application only from the point of view of the end customer and the bank’s selfservice user is to have a limited view of the application. Also It is essential to consider the view of the user who specifies the requirements and business rules, in this case, the department manager.

26. How Does Function Point Analysis (fpa) Define The Term “application”?

In the information technology field in general, the term “application” is used to appoint an executable program that meets a set of specific objectives or one objective for the users. As classical example that we can quote is the Windows Calculator, Word, etc.

Developers, in turn, tend to determine the scope of applications under the physical segmentation of the software. Thus, a single set of related functions is separate according to the following technological issues:

1. The physical implementation methods. For example, batch or online performed functions
2. The physical platform on which subsets of functions reside. For example, mainframe or PC (low deck)
3. The architectures under which the applications are designed. For example, desktop, clientserver, web, or 3tier.

On Function Point Analysis (FPA) , an application is defined according to the user’s view and according to business considerations and not to technical components. According to the Counting Practices Manual (CPM), an application is a cohesive set of data and automated procedures that support a business objective, which may consist of one or more components, modules or subsystems. Often, the term “application” is used as a synonym for system, application system or information system.

For the function points analysis the correct understanding of the term and, in turn, the correct identification of an application (enclosed by its boundary) is the basis for the consistent use of the technique, avoiding oversizing or undersizing during the counts.

27. What Are The Objectives Of The Ifpug’s Counting Practices Manual (cpm)?

The Counting Practices Manual  CPM, of the IFPUG has the following objectives:

• Provide a clear and detailed description on how to count function points.
• Ensure that the counts are consistent with the practices of counting reached by IFPUGaffiliated members.
• Provide guidance on how to perform function points counts based on artifacts of the techniques and methodologies commonly used in software development.
• Provide a common understanding so that developers of tools provide automated suppport to the function points counting.
• Be compliant to the ISO / IEC 14143–1 Measurement of functional software.

28. What Tools Are Suitable For Support And/or Automate The Use Of Function Point Analysis (fpa)?

The first point to note in this issue is that there are no tools available that automatically count function points reliably. However there are tools available that can support and partially automate the process of function point counts and also to store and manage the results of the counts.

The simplest tool to be used to record a function point count is a spread sheet. In the “resources” section of our website, there is a free and formatted spreadsheet for function point counts available for download. Despite being the first and simplest tool to be used by many professionals, its use begins to be impractical as the number of counts increases. The control of the count repository is usually manual, and with the increasing amount of data, the task becomes costly.

When the organization realizes that the spreadsheet no longer meets it needs, a natural course of action is to search tools with more capabilities on the market. The IFPUG has a certification process for the tools to support the function point counts. The list of tools currently certified can be viewed here: http://www.ifpug.org/?page_id=316. According to this process, the tools can be classified into three categories:

Type 1: The user does the function points count manually and the software provides functionalities for data collection and calculations.

Type 2: The software provides the functionalities for data collection and calculations, and the user and the system do the interactive function points count, using questions submitted by the system and actions being taken automatically depending on the answers provided.

Type 3: The software automatically produces a function point count using various sources of information such as the database application, the application itself and artifacts of the development tools. The user can enter the data interactively, but his involvement is minimal during the count. It is important to note that there are no such tools certified.

Although there are several options of tools on the market to support the use of function points, many organizations choose to develop an inhouse tool integrated with its systems of internal control. Some reasons for this may be:

• The cost to develop an internal solution is less than the cost of acquisition and maintenance of packages available on the marke.
• Lack of local support for the solution, due to the fact that most tools on the market are foreign
• Needs to integrate with internal systems

29. Is The Size Of A Software’s Unadjusted Function Points Determinant For The Specification Of The Hardware Needed For Its Execution? Why?

When it comes to hardware requirements for the execution environment of a particular software, the focus of the issue is on the technical or quality requirements, as processing power, volume and transaction data, number of users, security, etc… The functional requirements do not affect anything in this regard. Therefore, there is no direct relationship between the size of a software in function points (whether it’s adjusted or not) with the necessary hardware required for its implementation.

But the adjustment factor, analyzed by itself from the functional size, includes many general system features  (Distributed Processing, Performance, Heavily Used Configuration, Volume Transaction) that could assist in the  definition  of the hardware requirements of a  software, but it would be an insufficient analysis to define the hardware.

30. Is It Possible To Apply Function Point Analysis (fpa) For System Maintenance Projects?

Yes, but not all of the software maintenances are likely to be measured with Function Point Analysis (FPA). Only the maintenances that change the software functional requirements can be measured by the Function Point Analysis (FPA), in this case IFPUG uses the term “improvement” instead of “maintenance”, exactly to make the point that the improvement is not any kind of maintenance. In IFPUG’s concept, the improvement measures all the functions that will be added, changed or excluded from the application, as well as eventual functions of data conversion.

Maintenance for correction of defects or to keep only nonfunctional requirements are not measured by Function Point Analysis (FPA).