Home > Articles > Software Development & Management

Using Functional Metrics to Effectively Manage Outsourcing Arrangements

📄 Contents

  1. Using Functional Metrics to Effectively Manage Outsourcing Arrangements
  2. Establishing Performance Levels
  3. Monitoring the Deliverable
  4. Summary
  • Print
  • + Share This
Outsourcing contracts are governed by a select set of service-level measures. To effectively manage an outsourced software development effort, you must have a set of service-level measures that can accurately predict and monitor the cost of the software deliverable, and measure the value of the service provided to the customer. The key is to establish an accurate cost-per-unit-of-work measure. A unit of work measure must be capable of accurately quantifying the functionality being delivered to the business user. When a user specifies a desired functionality, the unit of work must measure that functionality in a direct way[md]the user asks for one widget, and that is exactly what gets measured.

Outsourcing contracts are governed by a select set of service-level measures. To effectively manage an outsourced software development effort, you must have a set of service-level measures that can accurately predict and monitor the cost of the software deliverable, and measure the value of the service provided to the customer. The key is to establish an accurate cost-per-unit-of-work measure. A unit of work measure must be capable of accurately quantifying the functionality being delivered to the business user. When a user specifies a desired functionality, the unit of work must measure that functionality in a direct way—the user asks for one widget, and that is exactly what gets measured.

In every outsourcing arrangement, the customer is concerned with monitoring the functionality being delivered, the development time, and the development cost. The ability to monitor these elements is influenced by a myriad of factors, including the complexity of the technology, the availability of skilled resources, and the techniques and methods used. An accurate cost-per-unit-of-work measure will produce results that are affected by all of these factors, but the unit of work itself cannot be altered by these factors—it must remain constant. For example, using source lines of code as a unit-of-work measure is problematic because the deliverable size varies based on language complexity (different languages produce different line-of-code counts for the same work product deliverable). Thus, a line of code measure will not provide a consistent unit-of-work measure across multiple technologies.

Function Points as a Unit-of-Work Measure

The function point method has proven an effective way to establish a meaningful unit-of-work measure and can be used to establish baseline costs and performance-level monitors. Function point analysis centers on its capability to measure the size of any software deliverable in logical, user-oriented terms. Rather than counting lines of code, function point analysis measures the functionality being delivered to the end user.

The function point method evaluates the software deliverable and measures its size based on well-defined functional characteristics of a software system. It accounts for the following:

  1. Data that is entering a system—External inputs such as logical transaction inputs and system feeds

  2. Data that is leaving the system—External outputs and external inquiries such as online displays, reports, and feeds to other systems

  3. Data that is manufactured and stored within the system—Internal logical files such as logical groups of user-defined data

  4. Data that is maintained outside the system but that is necessary to satisfy a particular process requirement—External interfaces such as interfaces to other systems

These five functional elements (see Figure 1) are assessed based on their complexity and are used to evaluate an unadjusted function point count. The next step in the methodology involves evaluating a series of general systems characteristics (GSCs), which include such things as performance, configuration, complexity, and reusability. The evaluation of the GSCs produces an adjustment factor, which is then applied to the unadjusted function point count for a final function point calculation.

Figure 1

Identification of functional elements

The final function point calculation yields a single number that represents the total amount of functionality being delivered. Once completed, the function point size of an application or a new development project can be communicated in a variety of ways. As a standalone value, the function point size of a system tells us how large the overall software deliverable will be. When the function point value is segmented into a more detailed display, it can communicate to end users the functional value of specific components of the system. Finally, organizations that have reached a certain level of software measurement maturity can use function points to predict outcomes and monitor program progress.

As projects are completed and software deliverables are produced, function point sizing, along with the collection of other meaningful measures, are used to produce a baseline of performance. These other measures may include level of effort, cost, duration, and quality. From this baseline, a cost per unit of functionality delivered can be derived. The total number of delivered, enhanced, or supported function points is divided by the cost associated with producing the required deliverable or support service. The result is a cost per function point, or a cost per unit of work.

Throughout the project life cycle, as requests come in for additional system enhancements and new development products, the organization uses the function point method, along with baseline performance data, to determine the cost of the deliverable, manage the expectations of the end user, and manage the delivery of the software product.

  • + Share This
  • 🔖 Save To Your Account

Related Resources

There are currently no related titles. Please check back later.