Let's avoid ambiguity from the very beginning - we will be talking about Business Requirements (BR) that have to be realised by technical means, and about technical specification in the role of IT Requirements (ITR). Functional Points is an instrument of Functional Sizing Methods (FSM); IFPUG explains that the "Function Point Analysis (FPA) is a sizing measure of clear business significance. First made public by Allan Albrecht of IBM in 1979, the FPA technique quantifies the functions contained within software in terms that are meaningful to the software users. The measure relates directly to the business requirements that the software is intended to address. It can therefore be readily applied across a wide range of development environments and throughout the life of a development project, from early requirements definition to full operational use."
For the last 30 years, it became a common believe that FPA is a sizing method of requirements to be implemented by IT. This means that if we have BR gathered, we can size and cost-estimate the IT project up-front. Certainly, as any universal technique, FPA is only an approximation of the size and cost. It's very important to understand the percentile of expected error of the technique - if the error is assumed of 100%, it is not a very practical technique IMO, but if the error is about 15-30% , it might be useful.
For next 15-20 years after the first public appearance, the FPA enjoyed a single model of technical solutions available known as 'client-server'. This solution comprised a GUI based SW client and a database/store based server. Since that time, variety of SW capabilities, especially in multi-tier and distributed computing, has significantly increased leading to dozens of possible technical solutions. Each solution has its size, complexity and associated cost. If FPA is a BR size/cost estimating technique, how it deals with these multiple potential solutions?
As we know, IFPUG FPA operates with Internal Logical Files, External Interface Files and External Inputs, Outputs or Inquiries in the 'application boundaries'. If one has a GUI-client component (an External Interface File) and uses it to retrieve or insert data into the database on the server employing SQL, the complexity of this work is practically the same for 2 data-fields and for 222 data-fields - it is one remote call to the database, i.e. one Functional Point, for example. That is, an abstraction of External Inputs, External Outputs and Internal Logical Files makes a lot of sense for such model of technical solution.
Wait a minute! Why are we talking files, interfaces and applications in FPA? There is nothing about any of them in the BR; Business does not know about them and does not want to know. All these files and applications appear when we construct, imagine or assume particular technical solution to be used to satisfy business requirements. This leads to the first conclusion:
Since IFPUG FPA counts not business functions, features, processes and services but technical means to be used to support Business and meet BR, the IFPUG FPA does not size business requirements but, instead, it sizes possible technical solutions that fit with FPA abstraction model.
Another type of requirements we mentioned is ITR. These are technical requirements to the project expressed in the technical terms of files, interfaces, applications and so on. This kind of requirements can come from technical people only, from out of Technology itself. But even in this case, the requirement may not dictate particular solution because otherwise it is not a requirement by a part of the solution. If we have one dominating technical solution model of user interface and data storage (client-server), then practically all requirements may be viewed 'equal' to such model and we can say that the cost-estimating of this technical model corresponds to the cost-estimating of the requirements. Then, if assumed technical solution fits with the FPA abstraction model, the latter may be sufficient. Otherwise, we have to analyse potential error and, based on it, decide if such estimate is feasible.
Let's take a very simple example - an External Output File measure. It requires one functional call to the database to prepare an External Output File with 2 or with 222 data values if the format of the file is simple coma-delimited sequence of numbers or strings. But in our days more and more files are in the XML format. Is the work for forming an External Output File in XML the same as in the coma-delimited numbers format?
If do it right, to construct an XML file, we have to construct an XML Schema file first and we must construct an XML validating component (otherwise, non-validated XML file has very little reliability and technical value). Then, assume that the amounts of work for the XML Schema and validating component are the same. Also each element of the XML file may have its own XML Schema. Assume, there are three data elements in the XML file. Therefore, to produce one External Output File in XML format, we have to perform 1 unit of work for validating component and 4 units of work for XML Schemas, i.e. 5 units of work together. We see that for coma-delimited-numbers format we needed 1:1 file-to-unit of work ratio and we counted it 1 Function Point. For the XML file format of the same content we need 1:5 file-to-unit of work ratio. If we nonetheless estimate an XML file with the ratio of 1:1, we acquire 400 per cent error. Can we avoid such error in IFPUG FPA? It seems to me that we cannot because IFPUG FPA does not know and does not count the complexity inside the 'application boundaries' assuming it may be described as a set of primitive Internal Logical Files only.
Now, we are in the position to make the second conclusion:
The IFPUG FPA assumes such model of technical solution (for sizing) that is no longer the dominant model in Technology. Modern Technology deals with multi-tier and distributed technical models that are invisible outside of the 'application boundaries'; external interactions with the 'application' do not reflect its internal complexity any more and cannot size the work-to-be-done in the implementation project.
Our daily practice is not optimal and project cost usually is estimated at the IT management level that includes just a few technical architects, if any. Usually, the Programme or Project managers perform the estimate based on personal experience from the projects in the past. The fundamental problem with such organisational approach is that projects in the past dealt with much less set of technical capabilities and PM did not gain the deep understanding why one technical solution was chosen against others, it was not their job because they were responsible for the delivery of the project. This means that just an experience engaged in the new project cost-estimate is not necessary adequate to the task, especially if Technology has many capabilities (or, simpler, many ways to solve the same business problem that might not be available before).
This leads us to the third conclusion:
Technical Architects must be involved into the project cost-estimate. Technical Architects must come up with potential technical high level solutions and cost each variant of them. This is about the project cost-estimate, not about requirements cost-estimate.
Recently, I experienced a situation that demonstrated me that described mismatch between IFPUG FPA and modern technical solutions was recognised by some people in practice, not in theory only. In one engagement, to initiate an IT project, an assumption was done about using MVC model in the implementation because it is one the most universal model suitable for solving the majority of business requirements. The FPA was conducted and a development vendor was invited. The vendor based its price on the price per functional point and everybody was happy. However, when vendor Architects looked closer into the BR it became obvious that MVC is only one aspect of the proper solution, which, BTW, appeared to be a SOA/BPM based system with several points that needed MVC. The vendors surprised me when said that FAP did not really reflect the complexity of the work to be done and referred to the 3-their architecture (not even distributed architecture). Well, another surprise was about initial vendor's cost-estimate related to MVC because MVC assumes, at least, three-tier architectural solution anyway...
We will leave the commercial part of this case aside for now but look into a way to cost-estimate multi-component or service-based projects.
Leave a comment