In my previous blog: Estimation using FP (Funtion Point) for XI? , I discussed why it is not possible to use Function Points and we need to tweak function points a bit for accurate estimation.
Teaching Function Point Analysis is not an objective of this blog, those who wish to know more about Function point can download free tutorial from here: http://www.softwaremetrics.com/files/FPManual.pdf
This blog summarily present how you can quickly size middleware projects (XI/PI in our case but this is generic model) in term of Function Point.
To use following table for estimation you must know following details:
From System | From Message | Field Count | To System | To Message | Count |
System1 | Message1 | 14 | System2 | Message2 | 23 |
System1 | Message1 | 0 | System 3 | Message2 | 0 |
System1 | Message1 | 0 | System4 | Message3 | 5 |
System4 | Message5 | 45 | System2 | Message1 | 0 |
(Message1 and Message2 counted only once)
Field count range | UFP (Sender) | UFP (Receiver) |
1-19 (Low) | 11 | 11 |
20-50 (Medium) | 14 | 15 |
>50 (High) | 19 | 20 |
* if fieldcount=0 then FP=0
Receiver Interface (Equivalent to 1 External Output and 1 FTR with 2 - 5 RET + 1 ILF)
Sender Interface (Equivalent to 1 External Input and 1 FTR with 2 - 5 RET + 1 ILF)
From System | From Message | Field Count | FP | To System | To Message | Field Count | FP |
System1 | Message1 | 14 | 11 | System2 | Message2 | 23 | 15 |
System1 | Message1 | 0 | 0 | System 3 | Message2 | 0 | 0 |
System1 | Message1 | 0 | 0 | System4 | Message3 | 5 | 11 |
System4 | Message5 | 45 | 14 | System2 | Message1 | 0 | 0 |
Total Sender FP | 25 | Total Receiver FP | 26 |
Un-adjusted function point (UFP)= Total Sender FP (SFP) + Total Receiver FP (RFP)
In order to have accurate estimation we must ask and analyze following questions and rate them accordingly:
S.N. | GSC | Rating |
1. | Mapping complexity: Estimate the complexity of mapping in overall integration landscape.
| 0 = No mapping used 1 = Mapping often used but mostly one-to-one mapping 2 = Mapping always used mostly with one-to-one mapping 3 = In addition includes few complex mapping 4 = Mapping is often complex and ratio of one-to-one and complex mapping is 50:50 5 = Ratio of complex mapping and simple mapping is more than 50% |
2. | Configuration simplicity
| 0 = No configuration required. 1 = Only few configuration requirement exist. 2 = all interface required simple configuration. 3 = In addition complex configuration required by less than 10% of interfaces. 4 = complex configuration required by more than 10% of interfaces. 5 = additionally job scheduling and OS level scripting required to fulfil security and/or configuration requirement. |
3.* | Complex processing (read BPM)
| Possible values to evaluate (1 point for each selected item)
|
4.* | Transaction Rate: describe the degree to which the rate of business transactions influenced the development of the application | 0 = No peak transaction period is anticipated. 1 = Low transaction rates have minimal effect on the design, development and installation (deployment). 2 = Average transaction rates have some effect on the design, development, and/or installation phases. 3 = High transaction rate affect the design, development, and/or installation phases. 4 = High transaction rate(s) stated by the user in the application requirements or service level agreements are high enough to require performance analysis tasks in the design, development, and/or installation phases. 5 = High transaction rate(s) stated by user in the application requirements or service level agreements are high enough to require performance analysis tasks and, in addition, require the use of performance analysis tools in the design, development, and/or installation phases. |
5. | Use of Adapters
| 0 = Only file adapters used. 1 = Standard packaged adapters are used. 2 = In addition, additional adapter required for development and procured from third party. 3 = In addition to standard packaged adapter, custom simple adapter module need to be developed. 4 = In addition to standard packaged adapter, custom complex adapter module need to be developed. 5 = New adapter developed to fulfil development requirement. |
6. | Multiple sites: describe how multiple sites pose challenge during development in effort to do distributed configuration and coordination.
*Site is separate entity which is direct party of integration project, if project is implemented on multiple sites but not involved coordination and distributed implementation then it should be considered as 1 site only. | 1 point for 2 sites. Additional 1 point for every additional site. |
8** | Client communication: describe how difficult and challenging client communication will be. | 1 = No difficulty at all, single point of contact is identified and response is within agreed time frame. 3 = Different contact person per site/ per department, communication is reasonably ok. 5 = Multiple contact person on client side, no process/procedure available for communication, escalation and ad-hoc communication required most of the time. Response time is not within agreed time frame. |
9. | B2B communication | 1 = only A2A communication 3 = if B2B communication is less than 5% of integration project. 4 = if B2B communication is within 5% to 8% of integration project. 5 = if B2B communication is more than 8% of integration project. |
10. | Quality/availability of documentation | 1 = All documentation required for project execution available and upto date. 2 = Most of the documents available but need clarity on some aspects. 3 = Only half of the required documents available with reasonable quality. 4 = Few documents available. 5 = No documentation available and whatever available required lot of clarification from customer side. |
11. | Special operational requirement | 0 = No operational/monitoring requirement anticipated 1 = minimal operational/monitoring requirement specified. 3 = Monitoring and exception handling mechanism for critical interface demanded. 5 = In addition high transaction/peak time is stated by user and required special design/configuration/installation considerations. |
13* | Performance: describes the degree to which response time and throughput performance consideration influenced development | 0 = No special performance requirements were stated by user. 1 = Performance and design requirements were stated and reviewed but no special actions were required. 2 = response time or throughput is critical during peak hours, processing deadline is for the next business cycle. 3 = response time or throughput is critical during all business hours. Processing deadlines with interfacing systems are constraining. 4 = In addition, stated user performance requirements are stringent enough to require performance analysis task in design phase. 5 = In addition, performance analysis tools were used in the design, development, and/or implementation phases to meet the stated user performance requirements. |
14** | Documentation of application: describes documents delivered to user on completion of phase of project. | 0 = No documentation done for development 1 = basic list of interface is generated. 2 = basic documentation for critical interface created. 3 = All interface documented with basic detail. 4 = All interface documented with extensive detail. 5 = In addition, support and troubleshooting manual developed for all interfaces. |
*Standard GSC is used with slight or no change in language. **Will impact effort of project, no direct impact on size. |
AFP = VAF x UFP
AFP is size of project in Function point and based on some initial sampling you can calculate and verify "hours/FP" and "FP/Hours" which will help you to estimate effort required for particular project.
Since initially you are not aware of fields details and other important details required to assess correct size of project you can use following tricks for quick and dirty calculation.
Function Point for Middleware is still in very primitive shape and I am running trials to see how I can improve it further, still this is the better way to calculate size of projects then by using reverse engineering method.