Project Management Software
Specialists in Project Infrastructure
Software Development Metrics
Prior to 1980, there was no method to estimate the size of IT developments other than to guess based on comparable developments. An IBM employee came up with a concept called Function Points. Since 1980, Function Points have been refined and developed to the point where they can be accurate within a few percent.
Counting Function Points
To build any system, you need to spend time building files to hold information, and interfaces to other systems (Files and Interfaces).
You need to spend time building input screens (Inputs), enquiry screens (Enquiries) and reports (Outputs). If you count the:
you have the start of a measure of the work to be undertaken.
Adjust for Technical Complexity
This of course does not take into account the complexity of the application being built. Is it a simple listing of names and addresses, or is it calculating the orbit of a satellite around Mars? A further adjustment to the unadjusted function point count needs to take place for the Technical Complexity of the application.
Adjust for Environmental Complexity
The final adjustment relates to Environmental Complexity. Is the application to run on a single PC, or over a wide area network? Does it need to cope with 1 user or 1,000 users? Is it designed for on line update or is it batch processing.
Adjusted Function Point Count
The Adjusted Function Point Count is the final figure. It is derived by multiplying the Unadjusted Function Point Count by the Technical Complexity and the Environmental Complexity. Depending on what sort of language is being used, different productivity figures exist. For example, a Cobol programmer may be able to deliver 10 function points per man month. A VB programmer 40 function points.
Calculating Function Points
To calculate how long it will take:
e.g. for a VB development which can deliver 40 Function Points per man month
Another value of function points is managing project scope. As all the screens, reports, files and interfaces have been counted early in the development lifecycle, we have an inventory of what is in scope. If later in the development, 10 more reports are requested, it may equate to another 60 Adjusted Function Points. In real terms it means another 6 man weeks work costing $10.5k. It can either be justified and additional resources and/or time added to the project, or rejected for the present.
By benchmarking completed or existing developments, a model can be established. It will show the relationship between the language, the skills of the developers, the completeness of the requirements, the development tools and all the other variables that normally exist in a project. The more information gathered, the more accurate the estimate of productivity will be for new projects.
Function Points Summary
Function Points are not absolutely precise. There is no absolutely precise measure for sizing developments. Function Points are open to some interpretation and often not comparable between organisations. If they are used consistently within an organisation they provide the only way to measure the size of a development effort and should be accurate within 5%.
For further information see the International Function Point Users Group (IFPUG)
For more information on Project Management visit www.projectperfect.com.au