One of the challenges of moving towards a service-oriented architecture (SOA) lies in measuring the complexity of existing software systems in a meaningful way. Function points (FPs) measure the size of IT application software associated with the business functionality the application provides to users. The function point count is a critical input for other parameters such as cost effectiveness and productivity.
This is predominantly a manual process today, which has limited function point analysis to new SOA projects. The Object Management Group's (OMG) new Automated Function Point (AFP) specification promises to reduce the time and cost of doing function point analysis. This will make it easier for organizations to accurately assess their current software infrastructure and make better estimates of the time, cost, and risk of new projects, said Dan Galorath, CEO of Galorath Inc., a software cost estimation vendor.
While there are several automated counters on the market, there has never been a standard that ensures they are all counting the same way. AFP provides a standard for automating function points according to the guidelines of the International Function Point User Group.
"The announcement by OMG of a specification for [AFP] counting should dramatically expand the use of function points for sizing IT applications," said Dr. Bill Curtis, director of the Consortium for IT Software Quality in a statement."By dramatically reducing the cost of counting and eliminating the problem of inconsistency among manual counters, automated function point measurement can become a standard component of the software development and maintenance process."
Sizing lets organizations relate effort, cost, and quality to a particular business capability. The plan may be valid and the estimate may be perfect, but the chief financial officer will not understand why the number is what it is. Good metrics can provide a more accurate estimation of cost by business capability or business objectives, making them ideal for optimization or planning.
Manual count chore
The main reason to count your FPs is to figure out the effort and schedule requirements for enhancement, innovation or rework. Organizations have not traditionally counted function points because of the time and cost involved. With an automated approach they can count or approximate the function points in their entire portfolio.
The lack of visibility of the total application has been the Achilles heel of SOA.
An expert can count about 1,500 function points in the course of a day. A large application like the SAP suite is about 65,000 function points and would take several weeks to assess. AFP has the potential to reduce the time and cost of counting by 10-20 times.
Organizations can then use FP data in conjunction with tools like Galorath SEER software, which estimates costs, schedule, risk and reliability of software. When an organization is doing additional development, this helps to make a more accurate assessment.
Galorath said, "A lot of the times people make decisions based on hopes and guesses. The count that comes from an automated tool is a better estimate of what is involved in portfolio maintenance. It will give people visibility into what is behind the SOA."
Getting the most from automation
David Seaver, senior technical analyst at OPS Consulting who is working on a pilot AFP deployment for a large government agency, said, "One way organizations could implement and benefit from AFP for managing SOA infrastructure is to size free and open source software when considering implementing capability."
By having a count of the existing portfolio including internal, open source, and commercial code, an organization can get better visibility into the complexity of its portfolio. When a business is acquired, AFP would make it easier to understand the new software infrastructure and plan for integration and enhancement.
Most practices have counts of ongoing projects, which usually consist of function points added to an application. They don't have counts of the total application, so they are missing the amount of legacy functionality that needs to be integrated with the added functionality.
AFP could also help to better calibrate project estimates with deliverables. Because of the cost, most organizations don't have a lot of capability to validate the size of new code once it is deployed. Seaver explained, "The lack of visibility of the total application has been the Achilles heel of SOA. We see AFP as a way to run analysis on code once delivered, and get a check up on estimates that are made with the requirements."
There are some limits to AFP. You need a code base to develop a function point count with AFP, so you cannot utilize it to do an estimate of a project during the requirements phase. Also, you cannot apply it to commercial off-the-shelf software (where there is no source code).
If AFP ever takes off, Seaver expects it could place pressure on commercial vendors to provide function point analysis runs of their packages. "They may not give you the source code, but they would give you an analysis of it. It will be easier to implement AFP on internal code or open source software because you are not running into those barriers."
Vendors like CAST Software are in the early phases of implementing AFP functionality. But it may be a while before the tools mature and become accessible to a wider audience of users. In the initial implementations, Seaver expects some variations between AFP and manual function point count.
It also may take some time to develop business processes for bringing AFP in effectively. Seaver noted, "For this to be successful, it will have to be something that people can apply even if they are not experts in network and systems integration."