|
Home
ISSUE
Within a development or enhancement project, it is possible for more than one independent business requirement (Change Request) to impact the same transaction. It is also possible that within the scope of one business requirement that the requirement itself changes during development. The IFPUG function point formulas for development and enhancement projects only consider delivered function points, can FPA be used to quantify the rework that may be involved in these two situations?
Functional Overview
Project Teams may be required to revisit or rework a function during the course of a development or enhancement project. Rework on a project may result from:
- Business initiated changed requirements
- Testing errors
In traditional FPA, each function impacted by a project is counted only once as a function point 'delivered', however, in situations where impacted functions are required to be worked upon more than once due to changes initiated by the business, and the project functional size is used to derive project productivity metrics, the function points "worked on" need to be considered.
In the case of rework resulting from testing errors, only function points "delivered" should be considered.
The delivery of a business requirement is a phased discipline. The solution to a business requirement typically observes the following steps, each of which requires the expenditure of effort:
- Functional Specification
- Designing
- Coding
- System Testing
- Acceptance Testing
- Implementation
When requirements change during the course of a project the amount of effort required to deliver a solution depends in part on the delivery strategy adopted. For example:
Multiple changes to the one function are delivered independently of each other. This assumes that the sequence of development steps is repeated multiple times, for each change to the transaction.
Multiple changes to the one function are identified and delivered simultaneously. This assumes that in either Step 1 or 2 the changes have been combined, and Steps 3 to 6 are delivered together for each change to the transaction.
The choice of delivery strategy is typically influenced by:
- The business approach to specifying changes.
- The timing of the change requests.
- Whether the development team adopts a proactive approach to identifying change requests that may be delivered simultaneously.
Regardless of the strategy adopted the required changes are business initiated and beyond the control of the project team and the project productivity metrics should not be negatively impacted.
The above discussion focuses on rework resulting from Change Requests arising from different business requirements. Within the scope of a development or enhancement, it is possible changes will be made to a business requirement after the commencement of the Software Development Life Cycle (SDLC). This may cause the development team to revisit some or all of the SDLC components. (ie. Design, Construction, and Testing.)
General Discussion and Resolution
It is understood that circumstances beyond the control of the project team should not impact productivity metrics. Projects that are significantly impacted by business initiated rework should report two functional size results:
- Function Points Delivered - to be used to update the baseline application size
- Function Points Worked On - to be used in the derivation of productivity metrics
The ease with which the required FPA reporting can be implemented depends in a large part on the functionality provided by the organisation's function point repository tool. SCOPEreports provide a measure of rework as well as a measure of delivered project size. However if you are using an one of the previous generations of function point counting tool such as the Function Point WORKBENCH ™ then it will not measure rework and only measures total delivered project size. The only way around this is a work around using the Labels feature to mark transactions that have been impacted multiple times to be identified but not summed. It then requires manual manipulation of both the count and the report figures.
FPW Work arounds - Not need in SCOPE.A label called MULTICHG, should be introduced to identify transactions that are impacted by more than one business requirement within the project count and to help to overcome a reporting limitation of FPW. | LABEL NAME | LABEL OPTIONS | | MULTICHG | - impacted 2 times
- impacted 3 times
- impacted 4 times
| Further options should be added to this label as required. Note: FPW labels can only be attached to transactions.
Using the MULTICHG label enables appropriate alteration of the delivered size of the project to report function points worked on. A reconciliation is manually undertaken at the conclusion of the count to derive the gross size of the enhancement. For example:
The net enhancement size reported in FPW as the Function Point Summary is shown to be 44 Function Points (30 (6*5) Transaction FPs + 14 File FPs) even though T1 is impacted by change requests CR100, CR103, CR105 and CR106 and T2 is impacted by CR101 and CR105. The reconciled count ('worked on') is 64 FP, as follows (where n is the number of transactions impacted as described):
The MULTICHG label should be used when two or more change requests, which reflect different business requirements, impact the same functional transaction and are worked upon at different times.
| Source |
Calculation |
n |
Size |
Description |
| Function Point Summary |
44
|
UFP size with Files |
| Transactions impacted 2 times |
= 5 x 1 x n |
1
|
5
|
UFP size without Files |
| Transactions impacted 3 times |
= 5 x 2 x n |
0
|
0
|
UFP size without Files |
| Transactions impacted 4 times |
= 5 x 3 x n |
1
|
15
|
UFP size without Files |
| TOTAL |
64
|
The MULTICHG label should not be used when the same functional transaction is being worked on at the same time by the same project team member. This occurs when, in analysis or design, the requirements of the change requests are combined.
Note: It is recognised that the function point FP Analyst may not be aware of how multiple change requests, which impact the same function, have been delivered. When this situation is encountered, the function point FP Analyst is required to ask the application expert/developer. Where the delivery strategy is not known, the default position is to use the MULTICHG label. The issue of multiple changes occurring within the one change request is handled in a similar manner. It is understood that circumstances beyond the control of the project team should not impact productivity metrics. A label called REWORK, should be introduced to identify transactions that are impacted by multiple changes to one business requirement within the project count and to help to overcome a reporting limitation of FPW.
The use of the REWORK label is similar to that of the MULTICHG label with one important difference. The MULTICHG is used in circumstances where separate business requests impact the same transaction whereas the use of the REWORK is designed to apply to those situations where there is a need to re-visit work already commenced or completed by the project team in order to comply with a change to the customer's original requirements. The REWORK label options identify the extent to which work has progressed through the SDLC before the rework commenced.
|
LABEL NAME
|
LABEL OPTIONS
|
| REWORK |
- impacted during Analysis & Design
- impacted during Construction
- impacted during Testing
|
Using the REWORK label enables appropriate alteration of the delivered size of the project to report function points worked on. A reconciliation is manually undertaken at the conclusion of the count to derive the gross size of the enhancement. For example: It has been determined that the following loadings will be applied for the three main components of the SDLC:
Note: These percentages are examples only. Actual figures must be agreed between the software supplier (eg the project team) and their client (eg business sponsors or the consumer of productivity metrics reporting)
Therefore, if work had progressed to the construction stage before a change to the requirements is identified by the customer, then it will be deemed that 85% (36 + 49) of the work has been completed, and a loading of 185% will be applied to the Function Point count of any impacted transactions.
| Analysis and Design |
36% |
| Construction |
49% |
| Testing |
15% |
For example: The following example is worked in Unadjusted Function Points (UFP).
The net enhancement size, reported in FPW as the Function Point Summary, is shown to be 44 UFP (30 Transaction UFPs + 14 File UFPs), even though Transaction 1 is impacted by rework representing 36% of the effort required, Transaction 2 is impacted by rework representing 85% of the effort required, and Transaction 3 is impacted by rework representing 100% of the effort required. The reconciled count ('worked on') is 55 UFP, as follows (where n is the number of transactions impacted as described): | Source | Calculation | n | Size | Description | | Function Point Summary | 44 | UFP size with Files | | Transactions impacted 2 times | = 5 x 0.36 x n | 1 | 1.8 | UFP size without Files | | Transactions impacted 3 times | = 5 x 0.85 x n | 1 | 4.25 | UFP size without Files | | Transactions impacted 4 times | = 5 x 1.0 x n | 1 | 5 | UFP size without Files | | TOTAL | 55.05 | The REWORK label should be used when multiple changes, which reflect the same business requirements, impact the same functional transaction once development of the function has commenced. Accompanying documentation that identifies the specific transactions and evidence of what stage the SDLC had reached when the change/s were received must support the use of this label.
|
