Dan Horvath explains how function point analysis (FPA), in combination with other metrics, provides reliable and accurate measures that may be invaluable to an agile development organization.
Software development and maintenance can be a challenging endeavor. Whether and how you measure productivity and quality, as well as how you go about doing project estimation, are among the major concerns. Function Point Analysis (FPA), in combination with other metrics, provides reliable and accurate measures that may be invaluable to the organization. Together, these methods can reduce risk and ensure project success by providing an accurate account of the effort required to complete the project. Function points measure the amount of business functionality an information system provides to a user. Such measurement may take place before (as an estimate), during, or after the project development, as required.
Although FPA is recognized by the International Organization for Standardization (ISO) as an industry-standard measurement method, the use of new software tools, methods, and technologies raises questions about whether FPA is applicable as a measurement method. Many organizations use function points as part of their waterfall software or systems lifecycle, and FPA can work just as well with agile. This article, the first of a three-part series on how to use FPA to improve your software development process, will demonstrate that FPA is a valid measurement of agile software development.
History and Definitions
Software metrics and particularly FPA are closely linked with project management; measurement takes place before, during, and after various project phases. Project management, in turn, is intimately concerned with the software development methodology being used. Consequently, in order to produce accurate results when considering estimating techniques and productivity measurement, software metrics are often tied to the software development methodology.
A project is a temporary endeavor that has a defined beginning and end and is undertaken to meet unique, specific goals and objectives, generally for the purpose of causing required changes or adding value. The software product’s output is a product of some kind. Traditional waterfall software development methodologies fit well with this definition of a project. The concept of a beginning and end are essential to both the methodologies and the management of the project. Once a project is defined, software metrics may be gathered and applied to the overall measurement information. Project metrics are meaningless without well-defined projects.
Rapid Application Development
Software development methodologies were originally derived from some form of waterfall process, where one phase followed another. They began to evolve further in the 1990s, when Rapid Application Development (RAD) was developed by Dan Gielan and James Martin and gained popularity. RAD methodology uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. This generally enables RAD projects to be implemented in a shorter period of time.
There are several types of RAD methodologies, some of which are listed below. Although most of the methodologies foster the reuse of software, distributed development, and small team structure, many RAD practitioners recognize that there is no single “rapid” methodology that provides an order of magnitude of improvement over any other development methodology.
Application development using RAD generally favors smaller projects that can be developed in sizeable pieces. This has a considerable influence on the concept of a project, but agile, because of shorter release cycles and more rigorous definition, has an even greater impact.
Some of the “flavors” of RAD methodology include:
- Agile Software Development: Agile software development features extremely small release cycles by breaking up software projects into mini-increments. Real-time, face-to-face communication is ideal for agile software development. Documentation is developed when it needs to be developed, which may be at the completion of a project.
- Extreme Programming (XP): XP is a set of development practices, first defined by Kent Beck in the late 1990s, that features short iterations, close teamwork, and customer satisfaction. Although this terminology predates agile, it is now considered a form of agile.
- Joint Application Design/Development (JAD): JAD is closely related to RAD, the primary difference being that JAD emphasizes the crucial role of the customer, and customers are actively involved in design activities.
- Scrum: Like XP, Scrum terminology and definitions predate those of agile. Scrum is now considered one of the leading agile software development practices. Scrum development practices are reduced to a series of short iterations or sprints, in which teams are self-organized.
This article focuses on applying FPA to agile software development, but the same principles can be applied to all of the above methodologies.