Functional Size Measurements
Functional size measurement is the corner-stone of software economics, from portfolio management to project planning, benchmarking, or assessing ROI. Given that software has no physical features, relevant metrics can only be rooted in the functional value of the software under consideration, i.e functional requirements.
Since the seminal work of Allan Albrecht more than 30 years ago, most approaches have been based upon his design of function points. Yet, as thoroughly explained by Alain Abran (“Software Metrics & Software Metrology”), Albrecht original design was undermined by mixed inputs and procedures:
- Different inputs: business contents, system functionalities, general systems characteristics.
- Different procedures: objective tally, subjective guesses, and statistical regression.
Since then, and despite the radical changes in communication and information technologies, not much has been done to correct those drawbacks. And yet, new approaches focusing on architectures should open new perspectives:
- Service oriented architectures should support objective and unbiased description of systems functionalities.
- Model driven development should provide for a clear mapping between functionalities and development flows.
Taking advantage of both approaches, the aim is to anchor functional size metrics to stereotyped requirements and redesign function points computation along architectural layers.
Problems and Solutions
Requirements metrics are usually impacted by external factors set by different stakeholders along different time-frames. If projects are to be planned and managed accordingly, estimators should be designed along the different layers concerned.
As already noted, measurements are tools designed on purpose. Regarding systems engineering the aim is to estimate the size and complexity of problems and solutions.
- Problems are defined by requirements: business, functional, or non functional.
- The size and complexity of solutions depend on problems on one hand, development means and strategies on the other hand.
Functional size metrics deal with the problem perspective, namely how to assess the functionalities supported by a system independently of the technology and tools used to implement it. Those functionalities can only be set in their business and operational contexts, and must be assessed accordingly.
Business domains can be measured by the number of entities together with associated taxonomies and dependencies. Business processes can be measured by the number of transactions weighted by the complexity of execution paths (extension points and dependencies).
Metrics of system functionalities are set along two axes: the first one is defined by their business footprint, i.e entities and transactions supported by the system (as defined by use cases); the second one deal with the nature of system boundaries for users, events, or devices.
Finally functional measurements must be adjusted for transverse (aka non functional) requirements, i.e operational or regulatory constraints that cannot be allocated to any specific business unit.
Function Points Principles and Limitations
The standard computation of function points distinguishes between data and transaction functions. Data function points include:
- Internal Logical files (ILFs) are symbolic objects whose life-cycle is bound to applications using them.
- External Interface Files (EIFs) are symbolic objects used or referenced by the application yet whose life-cycle is managed independently.
Transaction function points take into account:
- External Inputs (EIs) are local (non shared) activities processing information from outside application boundaries.
- External Outputs (EOs) are local (non shared) activities providing derived information outside application boundaries.
- External Inquiries (EQs) are local (non shared) activities providing non derived information outside application boundaries.
While based on sound principles, standard computations still reflect traditional system architectures. As a consequence, the focus is on files size and structure while critical aspects are lumped together or relegated as adjustment factors.
Functional Requirements Metrics
Functional Points computation can be redefined as to distinguish between domain and use case metrics:
- The footprint of supporting functionalities is marked out by roles to be supported, active physical objects to be interfaced, events to be managed, and processes to be executed. As for symbolic representations, corresponding artifacts are to be qualified as primary or secondary depending on their identification, with accuracy and reliability of metrics weighted by the completeness of qualifications.
- Functional artifacts (objects, processes, events, and roles) are associated with anchors and features (attributes or operations) defined by business requirements.
Functional metrics can then be computed for use cases:
- Interactions with users, identified by roles and weighted by activities and flows (a).
- Access to business (aka persistent) objects, weighted by complexity and features (b).
- Control of execution, weighted by variants and couplings (c).
- Processing of objects, weighted by variants and features (d).
- Processing of actual (analog) events, weighted by features (e).
- Processing of physical objects, weighted by features (f).
Additional adjustments are to be considered for distributed locations and synchronous execution.
Whereas complexity is clearly another primary factor when development strategies are considered, measurements are generally based upon educated guesses at best, arbitrary assessments otherwise. That may prove a fateful obstacle to the use of function points when subjective estimates bring statistical variance to disproportionate levels.
From a functional point of view, complexity depends on interconnections, their degree of coupling, and their distribution.
- The complexity of interconnections can be directly measured on models.
- Those connections may support loose or strong couplings depending on synchronization constraints for objects and activities.
- Couplings may have to be managed centrally or across distributed systems.
Those criteria could be organized within a complexity matrix and associated with statistical estimator.
Functional Size Metrics & Model Driven Development
On that basis computations of problem and solution metrics can be sequenced in accordance with development contexts and life-cycles.
- Application domain function points (ADFPs) are directly computed from models.
- Use case function points (UCFPs) are derived from use case specifications.
- Non adjusted function points (NAFPs) combine use case and application domain function points.
- Gross adjusted function points (GAFPs) are estimated by weighting non adjusted function points with relevant transverse (aka non functional) requirements.
- Net adjusted function points (NAFPs) are estimated by taking into account current functional architecture.
- Design points are estimated by taking into account targeted technical architecture.
- Implementation points are estimated by taking into account development environment.
Functional Size Metrics & Project Outsourcing
As demonstrated by the Victorian State government in Australia, functional metrics can be directly used to price outsourced projects. Combined with Agile approaches to project management, that may provide a sound non-zero sum game framework.