In this example, we suggest that the project has started properly - the business requirements were gathered to some level of details and Architects produced a few alternative architectural and high-level design solutions. Practice shows that even if the technical task of the project is a simple, modern economical environment requires compliance with multiple business and security policies, i.e. it is more likely than not that the project solution utilise/affects several components and/or services. It is well known fact that IFPUG FPA methodology associates with higher error for 3-tier architecture than for 2-tier architecture, and the error is higher for 4-tier than for 3-tier architecture, and so on. The more distributed architecture is used the less accurate the IFPUG FPA estimate is.
To realistically size and cost-estimate distributed architectural solution we need to 'look under the hood' and considering the estimated 'application' as an almost white-box. The 'application' comprises multiple components or services, each of which as a solution or application on its own for its task. In other words, when doing estimation of the solution, we need to disassemble it into meaningful functional sub-elements and estimate them first. The composition of the estimates will give us the whole complexity/cost picture later. In 2007, David Linthicum described the "very 'general' guidelines" on how to estimate a budget for SOA based technical solutions. Also, 10 years ago, the COSMIC Method of Full Functional Points estimation was formulated.
The COSMIC Method does not pretend to be a method for the business requirements cost-estimate; it proposes to partition the solution-system into functional parts first of all, counting Functional Points for the parts separately and addressing the integration between the parts with the corresponding number of additional Functional Points . Luca Santillo, a President at GUFPI-ISMA, said: "The COSMIC method allows for an architecture-based partitioning of the overall software system being measured. In such a partition... any layer (and equivalently , any peer item at the same abstraction level) is a collection of software 'units' (that is, services, in a SOA environment) that may be invoked or accessed. The relation among layers or peer items is 'allowed to use'".
Well, the COSMIC Method appears as the proper Functional Sizing Method for modern multi-tiered and distributed technical systems. However, don't you see that by shifting from BR 'estimate' into a potential technical solution estimate we are getting a problem in the project life-cycle management?
In the Project Management practice, when Business or Technology identifies a need to do something new or modify an existing solutions, two questions must be answered first of all: what is this and how much it would cost (now and in the future). The 'what' question is not usually that difficult to answer. At the same time, it is impossible to answer the 'how much' question with reasonable confidence if skipping a preliminary BR gathering, architectural analysis and solution design work. So, who is going to pay for the size/cost estimate that includes architectural and design work before the project has started (and funded)?
Probably, there are several different solutions for this problem available and all of them require a change in the structure of the project process. From the old IT days, someone, perhaps, remembers Research and Development (R&D) groups in IT that looked 'into the future'. In our days, such a group may be tasked with the architectural reviews of BR and cost-estimate depending on the possible solutions using the COSMIC Method. This group must have a dedicated budget to construct potential solutions and to size the work outside of the project budgets. I do expect that accurate estimate of some requirements or ideas will result in such a high cost-estimate that Business would not be happy. Nonetheless, an accurate estimate before investing resources is usually more feasible than the opposite.
The logic of potential solution estimate also includes an aspect that totally overlooked by any Functional Sizing Method - confidence in the solution implementation. Here is the logical chain: an identified business function has to be defined in the terms that allow sizing the efforts of its implementation; the efforts include technology capabilities and technical skills, as a minimum; technology capabilities and technical skills correlate to different delivery risks that must be addressed by the degree of efforts and, correspondingly, by the sizing. That is, the higher delivery risks are the bigger 'size' of the project's required because additional risk mitigation efforts to be considered. But how the skills relate to the Functional Points?
The theory of counting Functional Points for the purpose of estimating the size of the work to be done recognises two types: Business Functional Points and System Functional Points. Number of Business Functional Points certainly does not depend on the skills. In the contrast, the System Functional Points as a means of the project sizing do depend on the skills of developers. More accurately, the skills affect an impact of each System Functional Point on the size/cost estimate. Here is a real life example.
In a company, Solution Architects reviewed BR and estimated possible solutions for the project. Since it was a very preliminary estimate based on minimal BR, the business required about 25 per cent confidence. It meant that 75 per cent of estimated architectural solutions might be changed in the implementation. The System Functional Points identified based on the 25 per cent of the solution were enough for estimating the project budget because the development team was able to provide quality implementation for the whole solution. In a while, the development was outsourced overseas.
The effect was immediate - quality of implementation dropped. It was found that development teams were not able to construct left 75 per cent of architectural solution in line with the estimated 25 per cent. The development team experienced significant business knowledge downgrade, frequent stuff rotation, the significant portion of junior developers (vs. previous skill-set). All these resulted in the longer time-to-market and much higher cost (matter of times) than was estimated.
It was obvious that the most direct mitigation of all these factors might be the creation of architectural solutions with much higher confidence, up to 70 to 80 per cent, that left much less uncertainty for the development team. As a result, much more BR had to be gathered and analysed up-front, much more solution details had to be worked out and more low level Functional Points had to be identified (while the impact of each System Functional Point became smaller).
The complexity/size -quality balance was re-established but it was not the end of the story. To provide 70 to 80 per cent confidence, the Solution Architecture team needed much longer time and much more details of the BR. This required changing the organisation of the project process by adding an architectural/cost-estimation step positioned right after the BR gathering. During this step, the work described above must be conducted. This related to all projects, large and just enhancements, in spite of used project execution method like DSDM or Scrum. This architectural/cost-estimation step had to be budgeted explicitly because, depending on the complexity of the business tasks, it could take several weeks of work of high-paid experts.
Thus, the final third conclusion is:
Architectural / high level design analysis and cost-estimate of possible technical solutions must precede project budgeting
This analysis is the key factor to the decision of which FSM to use - IFPUG FPA for monolithic or two-tier applications or COSMIC Method for SOA, BPM and other distributed types of applications.
Additionally, if anybody is interested in ROI for SOA, you can find several use-cases on service creation/reuse and related calculation formulas in the book "Ladder to SOE".
Hi,
a few things truck me as unknown territory, for example "IFPUG FPA estimate". As we know, FPA is not an estimating method, rather a base size used by estimating methods.
When you say " It is well known fact that IFPUG FPA methodology associates with higher error for 3-tier architecture..", are you saying that the FPA size is smaller, larger or that the % tolerance is increased, or are you talking about the code errors or are you referring to an estimate that you developed using an unnamed method?
Thanks
Hi,
a few things truck me as unknown territory, for example "IFPUG FPA estimate". As we know, FPA is not an estimating method, rather a base size used by estimating methods.
When you say " It is well known fact that IFPUG FPA methodology associates with higher error for 3-tier architecture..", are you saying that the FPA size is smaller, larger or that the % tolerance is increased, or are you talking about the code errors or are you referring to an estimate that you developed using an unnamed method?
Thanks
Hi Dominique,
To your first question – you are right, my expression was inaccurate; FPA is not an estimating but sizing method.
To your second question – I did mean the higher error level in sizing (calculated number of FP vs. actual size of development expressed in FP).
Actually, based on my current experience, both IFPUG FPA and COSMIC sizing methods make potentially incorrect assumptions about the future solution, e.g. solutions architecture, they count and can become a problem for real development work. In distributed systems, not all functionality is exposed to the end-users, especially in service- and process-oriented solutions, and not all of it clearly represented in the business requirements. Thus, the architects must be called for performing FP calculations rather than other types of specialists because the architects can easier anticipate functional elements in the distributed model for the potential solution making less mistakes that FP specialists who are unaware of described specifics.