• Prev
  • Next

Function Points in the Philippines?

David LambertI know what you are thinking – and I was thinking the same thing. Is there really a company using function points in the Philippines? Yes, there is. In fact, I recently traveled to the Philippines to train a lean development team on the use of function points as a measure for their metrics program.

I’d never been to the Philippines before, so it was an interesting experience to be in a new place, but it was also interesting to see how function points are being used around the world.

This particular team is way above the curve as far as their processes and documentation is concerned. They were looking for a standardized process to size their change requests in order to measure productivity and quality and help forecast future projects. Their intent is to start sizing those small change requests and establish some benchmarks for their applications. Once those benchmarks are in place and they have gathered some valuable data, the team intends to start using the data to help size their larger projects. The sizing for those projects will allow them to better manage staffing, cost, and quality related to those projects.

This, of course, is something we encourage and espouse as a best practice for development teams. So, it was great to see that this mentality has really taken hold in this organization, and that they truly understand the benefits of sizing.

I also learned while I was there that several larger technology companies are starting to use the Philippines as a source to locate their infrastructure and development teams. So you may not think of the Philippines when it comes to the IT domain, but the country is starting to make some strides towards closing the gap on the rest of IT world. I know for sure that one lean development team has closed the gap and function points have allowed them to standardize their process even further.

I look forward to seeing how the use of function points continues to develop in the country – and beyond. Is your organization using function points? If not, it’s time to catch up!

 

David Lambert
Managing Consultant

Written by David Lambert at 05:00

The Origins of Function Point Measures

Trusted Advisor

Note of Thanks

We’re pleased to share this month’s Trusted Advisor, which was written by Capers Jones. Capers is a well-known author and speaker on topics related to software estimation. He is the co-founder, Vice President, and Chief Technology Officer of Namcook Analytics LLC, which builds patent-pending advanced risk, quality, and cost estimation tools. Many thanks to Capers for participating in Trusted Advisor and allowing us to publish his report!

Scope of Report

The 30th anniversary of the International Function Point User’s Group (IFPUG) is approaching. As such, this report addresses a brief history of the origin of function points. The author, Capers Jones, was working at IBM in the 1960’s and 1970’s, observing the origins of several IBM technologies, such as inspections, parametric estimation tools, and function point metrics. This report discusses the origins and evolution of function point metrics.

Introduction

In the 1960’s and 1970’s IBM was developing new programming languages, such as APL, PL/I, PL/S etc. IBM executives wanted to attract customers to these new languages by showing clients higher productivity rates. As it happens, the compilers for various languages were identical in scope and had the same features. Some older compilers were coded in assembly language, while newer compilers were coded in PL/S, which was a new IBM language for systems software. When we measured productivity of assembly-language compilers versus PL/S compilers using “lines of code (LOC),” we found that even though PL/S took less effort, LOC per month favored assembly language. This problem is easiest to see when comparing products that are almost identical but merely coded in different languages. Compilers, of course, are very similar. Other products, besides compilers, that are close enough in feature sets to have their productivity negatively impacted by LOC metrics are PBX switches, ATM banking controls, insurance claims handling, and sorts.

A Better Metric

To show the value of higher-level languages, the first IBM approach was to convert high-level languages into “equivalent assembly language.” In other words, we measured productivity against a synthetic size based on assembly language instead of against true LOC size in the actual higher level languages. This method was used by IBM from around 1968 through 1972.

An IBM Vice President, Ted Climis, said that IBM was investing a lot of money into new and better programming languages. Neither he nor clients could understand why we had to use the old assembly language as the metric to show productivity gains for new languages. This was counter-productive to the IBM strategy of moving customers to better programming languages. He wanted a better metric that was language independent and could be used to show the value of all IBM high-level languages. This led to the IBM investment in function point metrics and to the creation of a function-point development team under Al Albrecht at IBM White Plains. 

The Origin of Function Points

Function point metrics were developed by the IBM team by around 1975 and used internally and successfully. In 1978, IBM placed function point metrics in the public domain and announced them via a technical paper given by Al Albrecht at a joint IBM/SHARE/Guide conference in Monterey, California. Table 1 shows the underlying reason for the IBM function point invention based on the early comparison of assembly language and PL/S for IBM compilers. Table 1 shows productivity in four separate flavors:

1. Actual lines of code in the true languages.
2. Productivity based on “equivalent assembly code.”
3. Productivity based on “function points per month.”
4. Productivity based on “work hours per function point.”

Function Point Evolution

The creation and evolution of function point metrics was based on a need to show IBM clients the value of IBM’s emerging family of high-level programming languages, such as PL/I, APL, and others. This is still a valuable use of function points, since there are more than 2,500 programming languages in 2016 and new languages are being created at a rate of more than one per month.

Another advantage of function point metrics vis a vis LOC metrics is that function points can measure the productivity of non-coding tasks, such as creation of requirements and design documents. In fact, function points can measure all software activities, while LOC can only measure coding.

Up until the explosion of higher-level programming languages occurred, assembly language was the only language used for systems software (the author programmed in assembly for several years when starting out as a young programmer).

With only one programming language, LOC metrics worked reasonably well. It was only when higher-level programming languages appeared that the LOC problems became apparent. It was soon realized that the essential problem with the LOC metric is really nothing more than a basic issue of manufacturing economics that had been understood by other industries for over 200 years.

This is a fundamental law of manufacturing economics: “When a manufacturing process has a high percentage of fixed costs and there is a decline in the number of units produced, the cost per unit will go up.”

The software non-coding work of requirements, design, and documentation acts like fixed costs. When there is a move from a low-level language, such as assembly, to a higher-level language, such as PL/S, the cost-per-unit will go up, assuming that LOC is the “unit” selected for measuring the product. This is because of the fixed costs of the non-code work and the reduction of code “units” for higher-level programming languages.

Function point metrics are not based on code at all, but are an abstract metric that defines the essence of the features that the software provides to users. This means that applications with the same feature sets will be the same size in terms of function points no matter what languages they are coded in. Productivity and quality can go up and down, of course, but they change in response to team skills.

The Expansion of Function Points

Function points were released by IBM in 1978 and other companies began to use them, and soon the International Function Point User’s Group (IFPUG) was formed in Canada.

Today, in 2016, there are hundreds of thousands of function point users and hundreds of thousands of benchmarks based on function points. There are also several other varieties of function points, such as COSMIC, FISMA, NESMA, etc.

Overall, function points have proven to be a successful metric and are now widely used for productivity studies, quality studies, and economic analysis of software trends. Function point metrics are supported by parametric estimation tools and also by benchmark studies. There are several flavors of automatic function point tools. There are function point associations in most industrialized countries. There are also ISO standards for functional size measurement.

(There was never an ISO standard for code counting, and counting methods vary widely from company to company and project to project. In a benchmark study performed for a “LOC” shop, we found four sets of counting rules for LOC that varied by over 500%).

Table 2 shows countries with increasing function point usage circa 2016, and it also shows the countries where function point metrics are now required for government software projects.

Expanding Use of Function Points

Several other countries will probably also mandate function points for government software contracts by 2017. Eventually most countries will do this. In retrospect, function point metrics have proven to be a powerful tool for software economic and quality analysis.

Trusted Advisor Guest Author

Again, our sincere thanks are extended to our guest author, Capers Jones.

You can download this report here

Written by Default at 05:00

Estimating Software Maintenance

DavidI recently read an interesting and informative article that presents a unique and proven approach for estimating maintenance and support activities using a new type of "sizing" model. The authors, Anjali Mogre and Penelope Estrada Nava, share their experience based on the work they have done at Atos worldwide.

The article opens with a positioning statement identifying issues with estimating software maintenance and support activities. Simply put, there is no reliable standard for sizing and estimating the effort associated with maintenance and support activities. Examples of software maintenance are described as correcting faults, software migrations, design improvements, adapting to different technical environments, etc.

Noted in the article are existing standards and practices, such as ISO/IEC standard 15939, IFPUG Function Point Analysis, lines of code measures and benchmark data from the International Software Benchmarking Standards Group (ISBSG). While valuable in their own right, the author points out the shortcomings of each in being able to properly size and forecast the size and complexity of a maintenance effort.

The proposed solution is based on an internally developed size measure and the ITIL definition of a service request (problem ticket). The size measure is called a "Work Point," and it is defined as a function of the type and complexity of a ticket (as defined by ITIL).

However, the best parts of the article are the details that follow. An in-depth review of the practices used in this method are presented with detailed examples and explanations. The practical application of this approach allows one to imagine and consider how these techniques could be applied to one's own needs to improve one's ability to manage their maintenance work load.

At the conclusion of the article we learn that not only is this an effective technique for sizing and estimating maintenance activities, but it has also been used to baseline productivity, measure performance improvements and set productivity targets.

If you are struggling with your maintenance and support work stream (and who isn’t), then this is a must read.

Download the article here.


David Herron
VP Software Performance Management

Written by David Herron at 05:00
Categories :

Why You Need To Size Your Software

DavidAre you sizing your software? Do you know the size of your projects or applications? I assume that most people would think to answer that question with a “yes.” After all, you have estimated the effort, duration and cost, and once the project is complete and in production, you know the real cost and you can measure the cost of maintaining the application. But does that information really tell you anything about the size of the software? Isn’t it a bit like me telling you that I bought a new house for $x and that it took n number of months to build – but you really don’t know anything about the size, the number of square feet for example.

When sizing your software, you should want to accurately know how big or small it is so you can properly plan, estimate and manage the delivery of that software. Sizing software requires a size measure that is ideally meaningful to both the development team as well as to the end user, and it should be a measure that can be applied consistently across all projects and all applications.

The development team will want to have an accurate measure of size so that they can properly estimate the level of effort and duration. They can also use the size measure to monitor changing requirements (scope creep) as features or functions are added to the original requirements document. The end user will want a measure of size so that they can understand the relative business value of what is being delivered: what features and functions the user is actually getting. Therefore, we would want a size measure that will satisfy both developers and end users.

The best size measure that satisfies the needs of both the developer and the end user is Function Point Analysis (FPA). FPA is an industry standard for measuring the size of software. It provides a quantitative measure for estimating the size of the software deliverable and it measures the functions and features that are important to the business end user.

In brief, the FPA method defines the size of a software project or application by evaluating five key elements: unique inputs, outputs, inquiries, interfaces and internally maintained data. The methodology clearly defines the characteristics of each of these five elements making it easy to identify and classify. Each unique element is evaluated and assigned a value based on its complexity. The result is a numeric value of size. The cumulative size of all five elements thus represents the total “size” of all the unique business functions.

As a simple example, let’s imagine that a user has requested the addition of five new reports to be included as part of an existing application.  A requirements document is produced describing the five reports as new and unique outputs. The function point analyst would identify those five reports as five unique transactional outputs and assign a number of function points to each report based on their relative complexity. The end result is a functional size that represents the enhancements being made to the application.

To continue with our example, the developer can now use this size indicator to estimate how much effort this particular enhancement project will take. By knowing how many hours it takes to produce a function point, the project estimator can use that value and make a calculation to estimate the effort required for this particular enhancement based on its size.

Now, let’s imagine that the user, midway through the project, suddenly realizes that they want to add an additional output report. No problem. The function point size is now recalculated including this additional report and a new estimate is generated. Of course, the project will now take longer, but the user understands that the size of their original request has increased and therefore more time is required to complete the project.

This is, of course, a simple example. But you can begin to see how the function point sizing measure may be used to size and to monitor or control the overall project. It also can serve as an excellent way to help manage customers’ expectations. When the requirements change, that change can be sized and measures can be developed to show scope creep over time. This should help project managers communicate the size of the change and the overall impact to the project.

Function point size can also be applied at the application level. Organizations can size their application portfolio. The resulting size of each individual application, as well as the entire portfolio, can serve to monitor and manage application maintenance support. For example, application and portfolio growth can be tracked for more efficient resource loading and budget planning. 

The key to successful software management is having the right information available to make the best possible decisions. Knowing the size of your software deliverable is one of the key indicators that contribute to improved decision making.

 
David Herron
Vice President, Software Performance Management

Written by David Herron at 11:00

"It's frustrating that there are so many failed software projects when I know from personal experience that it's possible to do so much better - and we can help." 
- Mike Harris, DCG Owner

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!