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:
- Number of connection on sender side (read Sender Interface).
- Number of connection on receiver side (read Receiver Interface).
- Estimated Number of fields in Sender Interface, accurate count not required for example "Vendor Master" can have 10-15 fields.
- Estimated Number of fields in Receiver Interface, again accurate count not required.
Cautions:
- For accurate results count recurring fields once. For Example Address may appear in Vendor Master, Customer Master, and Employee Master then count it as one in either of interfaces (see table for example).
- Do not count data fields if it is reused (see table below).
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)
Table for computation: Unadjusted Function Point (UFP)
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)
Final table structure will look like:
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)
Global System Characteristics (GSC):
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. | ||
Calculate Value Added Factor (VAF)
Calculate Adjusted Function Point
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.
Tips for quick computation
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.
- - Instead of creating table of interface to save time you can simple count Low, Medium, High for respecting connections (Sender or Receiver Interface), and then multiply by rating score.
- - Idocs and EDI messages are always counted as High.
- - Count rest of them as Medium and then review this list again where you certainly figure out possibility of field count as Low or High.
- - Sometime customer is able to tell you percentage of complexity in connections i.e. 30% simple, 50% Medium and 20% complex, use this formula to compute interface FP and then try to verify with quick scan of documents provided.
- - For Global System Characteristics count everything as 2.5 or 3 points and then review list if you can make them accurate (higher or lower). For example if no performance requirement stated by user then you can make it 0.
Benefits:
- Quick estimation of project size and effort required, without knowing too much detail.
- Function point of given project will remain same, irrespective of who is calculating (+/- acceptable range).
- Accurate productivity can be measured in term of Hrs/FP (Hours per Function Point) or FP/Hr (Function Point per Hour).
- This model is generic and can be used for any middleware project i.e. Tibco, XI, Biztalk etc.
Limitations:
- Trial run on XI was successful and still trying to review this model for other middleware products.
- Certain level of technical details must be known in order to use this model effectively.
- Description for calculating rating of GSC can be refined further.
- XI/PI support high level of reusability of various objects which can affect FP count in initial stage (normally higher FPs).
- Suitable for development projects only.
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.
3 Comments
