The software development industry is one of continuous change — if the development methodology is constant for several months, the technology changes; if the technology stays the same ,the documentation standards change, and so on. It seems that we get so caught up in the pursuit of technology answers that we overlook basic project management tools — perhaps because they are not intertwined with the latest technology. In my travels around the country to speak at industry conferences, I hear project managers lament over their biggest challenges: incomplete requirements, scope changes, estimating and testing. (Year 2000 excepted). As such, many overlook a useful software sizing technique that can objectively quantify requirements and scope changes. In a manner similar to quantifying the size of a building’s pre-construction floor plan using rooms and square feet — there is a method that can quantify the size of software’s pre-construction floor plan using functions and function points. The “floor plan” in software development is represented by the software’s functional user requirements, and like square feet in construction, the FP size of software represents WHAT is to be built, regardless of HOW it is built. (More about the HOW in the following paragraphs).
Function points made their debut in 1979 at an IBM Guide/Share conference where their originator, A. Albrecht presented them to a professional IT audience. Since then, the International Function Point Users Group (IFPUG) has shepherded the function point rules into a solid method to consistently quantify software size. This month marks the release of the newest IFPUG Counting Practices Manual, Release 4.1, which provides both the counting rules together with many examples of how to apply them in various software environments. (For further information about the basics of function points email me a request (firstname.lastname@example.org) and I will forward you a short primer article on the basics of function points or visit the IFPUG website at www.ifpug.org.
With this “square foot” type of measure to quantify WHAT functions the software will provide, a project manager can then assess and compare the merits of various development alternatives. HOW the particular software will be developed (i.e., what language, hardware platform(s), skills, tools, etc.) will greatly affect the work effort and cost required to build the software, however, the functional size of the software will not be affected. Again, think of this in terms of a construction analogy: a 3000 square foot home is a 3000 square foot home whether it is a three-story house, a bungalow, or mobile home. However, the work effort and cost to build the building is a function of the size (3000 square feet) plus the type of building, materials, mode of construction, and many other factors. Can function points assist with your development challenges? Yes, in the same manner as square feet can assist with building construction. While not all of home construction’s problems are solved by knowing the square foot size, the size is a valuable measure on which to normalize and estimate cost, manage change orders, and plan the construction project.
What does your company have to gain by investigating the merits of function points in your development environment? Actually, quite a bit. Regardless of the software type or domain in which you develop, there are always user requirements. Quantifying these requirements using function points absolutely adds rigor and clarity to your development process and can assist in tracking and measuring your software development.