Monthly Archives: August 2012

Function Point Analysis (FPA) has been proven as a reliable method for measuring the size of computer software.  First made public by Allan Albrecht of IBM in 1979, the FPA technique quantifies the functions contained within software in terms that are meaningful to the software users.  It can be readily applied across a wide range of development environments and throughout the life of a development project, from early requirements definition to full operational use. In addition to measuring output, Function Point Analysis is extremely useful in estimating projects, managing change of scope, measuring productivity, and communicating functional requirements.  The Function Point Analysis technique provides an objective, comparative measure that assists in the evaluation, planning, management and control of software production.

The function point measure itself is derived in a number of stages. Using a standardized set of basic criteria, each of the functions is a numeric index according to its type and complexity. These indices are totaled to give an initial measure of size which is then normalized by incorporating a number of factors relating to the software as a whole. The end result is a single number called the Function Point index which measures the size and complexity of the software product.

There are many benefits in using Function Point Analysis:

  • Function Points can be used to communicate more effectively with user groups.
  • Function Points can be used to reduce overtime.
  • Function points can be used to establish an inventory of all transactions and files of a current project or application.  This inventory can be used as a means of financial evaluation of an application.  If an inventory is conducted for a development project or enhancement project, then this same inventory could be used to help maintain scope creep and to help control project growth.  Even more important this inventory helps understand the magnitude of the problem.
  • Function Points can be used to size software applications. Sizing is an important component in determining productivity (outputs/inputs), predicting effort, understanding unit cost, so on and so forth.
  • Unlike some other software metrics, different people can count function points at different times, to obtain the same measure within a reasonable margin of error. That is, the same conclusion will be drawn from the results.
  • FPA can help organizations understand the unit cost of a software application or project.

Once unit cost is understood tools, languages, platforms can be compared quantitatively instead of subjectively.

Further information can be found at

How often have you cut a board, a piece of material, or even wrapping paper, and guess what? You come up Short Agh! We’ll there may be a few factors in not effectively measuring the material. It can be any of the following: 1) Your measurement system or rule is not accurate enough for the material you measuring. 2) You need to measure in Milimeters and not inches. 3) You don’t have repeatable measurements, and have too much variance in your system.

If number 3 is the case for repeatability, we would suggest a Gage R&R study, and an Ops Ala Carte Consultant can help you here.

Per the 2nd cause, in my recent experience with a Supplier Quality Issue, the manufacturing tech. measured a hi-tech German Cable for medical applications, and found that a couple of pigtail lengths wire were out-of-spec!

We’ll this is an expensive error found, as the whole cable assembly would have to be shipped back to Germany to
the Supplier.

Instead, I Measure the assembly pig tails of the cable the Second Time in mm, and guess what, they all were within spec. +/- 1 mm.

So, measure twice, at least, it will save you money, time, and your company will be more productive with less rejects.

Happy Measuring.

Greg Swartz, CQE

We can’t under-estimate the power of a well laid-out qualification process. We’ve all heard about DVT, the Design Verification Process step that puts one’s product through several testing requirements; but a comprehensive qualification plan requires more than DVT.

My professional experience has shown that  a 3 steps qualification process: EVT, DVT and PMT allows a much more thorough qualification. These acronyms can be stated differently in different organizations, but they have about the same meaning:

  • EVT is for the early stages of product development, when the product is still somewhat imature; for example, for an electronic assembly, one can choose to conduct EVT on just the PCBAs before they are mated to the main system.
  • DVT is for a more mature stage of product development, when the product is complete and functional.
  • PMT is the final qualification step where customer systems and aplications are involved and the product is ready to ship.