Tag Archives: Standards

Function Points for Mere Mortals… Part 1: NOT Rocket Science

Does this sound familiar?  Your project completed under the “radar” (no major mishaps) and management wants more, more, more!  As part of the quest for faster, better, cheaper, someone in management decides that you ought to be reporting metrics and suggests that everything be built around “Function Points.”  A sponsor (the VP) appoints you the project manager for the Metrics Implementation (aka Function Points) and everything you thought you knew simply vanishes as soon as he walks out the door.

The Internet is Schizophrenic

If you are like most people, your first step is to ask your network (social media, peers, friends, etc.) what these “function points” are all about.  I have written about the simplicity and straight forward nature of Function Points for over 15 years (see downloadable articles below) and yet confusion still abounds in the IT industry!

As you begin to research the topic, thousands of internet links come up offering “Function” or “Points” or variations thereof. Once you find “Function+Points”, the filtered results create confusion as some sources elevate function points to a scientific treatise with the complexity to match.  This is simply not the case – Function Points are a unit of measure used to size the “functionality” of a piece of software that can be used to normalize measurement.  While certain consultants want to elevate Function Points to a mystical religion where only a handful of elders can do a count – this is not the case at all.  (These consultants seek to create an exclusive club where you have to hire them to count – this is utter hogwash!)

This is the point of this post:

Part 1: FUNCTION POINTS ARE not Rocket Science

As I mentioned, I and others publish (and continue to publish) articles and books about function points, yet software metrics is not yet a mainstream practice.  Confusion, disdain, and even downright misinformation abounds about this simple concept – creating a size of software that can be used as a basis (like square feet in a building) for estimating.  This is not Rocket Science!

In Project Management terminology, Function Points are the size of the overall work product for a project whose product is Software.  The WBS (work breakdown structure) for a software project includes all of the software deliverables, and function points is one way of sizing the functionality of the delivered software.  While there are additional things to be considered when doing a project estimate (such as quality, how the software will be built, critical path, resource constraints, risks, etc.) but a fundamental item is the scope.

Function points provides us with a measure of the scope of the software project.  Furthermore, the fundamentals of function points or FP (like the fundamentals of measuring square feet) have not changed in 15 years and counting methods are stable!  Certainly how we implement software has changed, but the functionality and scope have not – so why have FP not become maintream?

Capers Jones published a primer on function points (“Sizing up Software“)  in the December 1998 issue of Scientific American for which the abstract is below:

Modern society has become increasingly reliant on software–and thankfully so. Computer programs routinely execute operations that would be extraordinarily laborious for an unaided person– handling payrolls, recording bank transactions, shuffling airline reservations. They can also complete tasks that are beyond human abilities–for example, searching through massive amounts of information on the Internet.

Yet for all its importance, software is an intangible quantity that has been devilishly tricky to measure. Exactly how should people determine the size of software?

Want more basic information?  Here are four downloadable articles (PDF format) to further introduce you to function points:  (The content is still timely!)

Long and short oN function points? 

They are NOT rocket science and can be fundamental building blocks to a successful software estimating and metrics program.

Was this post useful?  Let me know!

Stay tuned for Part 2:  Getting started with Function Point basics.

Have a productive week!



TLAs, Emoticons, and other Communicata…

textingTexting has gone viral and with it has come a veritable flood of TLAs and FLAs (three-letter acronyms and four letter acronyms), shortcuts, and emoticons.  When it comes to acronyms, it’s no big surprise to us in the IT (information technology) industry – we’ve been inundated with acronyms since IT was first coined.  (I remember smiling years ago when a “senior” consultant I worked with in Telecommunications asked why we’d capitalize ‘it’.)

Most niche industries use acronyms as a communication short-cut.  But acronyms also create confusion and communication obstruction when used outside of their knowledge circle, with few exceptions.  One exception I can think of is the universal acronym is “Rx” (short form for Radix, the derivative of Prescription) — seldom is this shortcut questioned or confused.

The same cannot be said for other acronyms. Take AMA for an example… this is used variously to mean the American Medical Association, the American Marketing Association, the American Music Awards, the American Management Association, the Alberta Motor Association, and others.  So when you see the acronym AMA – what does it stand for?

acronymsI got caught in an acronym fiasco yesterday – unwittingly!  I got a call and spent an hour on the phone with a prospective client who was looking for someone with exactly my “ISO” standards experience.  (I’ve been on the US delegation to ISO software engineering standards since 1994, both as a project editor writing international standards and as a national subject matter expert.)  The client told me that her firm had recently acquired a contract to provide insurance software to ISO and she knew that they would have to comply with all necessary ISO standards.

The hour-long discussion turned out to be for naught – the ISO she was looking for was the Insurance Services Organization, not the International Standards Organization (based in Geneva Switzerland) to which my experience pertained.  In retrospect, the conversation reminded me of a scene out of the old situation-comedy “Three’s Company” (which was a weekly satire filled with double entendres!)  Here I was talking about ISO standards as they might pertain to insurance (and knowing that insurance is both state regulated and nationally regulated… AND it did seem strange that an US-based insurance software company would be retained by such an international entity.  Nonetheless, I played along…) — and the firm was looking for someone in the Insurance Standards Organization based firmly in the US.

In software development, acronyms are commonly used to name software systems – and we even joke about having acronym naming meetings whereby a team creates a seemingly sensible system name to fit into a clever acronym like “ACES” (Access Claims Eligibility System).  Ultimately, the clever long form meaning is lost once the acronym is in place, and people then only remember the acronym.

Certainly, acronyms can shorten redundant and repetitive phraseology – but they do not make sense if they introduce communication barriers.  Texting shortcuts cause the same situation – if someone has to spend extra time figuring out what you are saying, you are NOT communicating.  LOL (laugh out loud), Gr8 (great), 2morro (tomorrow), L8R (later) and other shortcuts sometimes save only a couple of keystrokes so one wonders why they would be used.  In some cases, I’ve seen writings where scholars fear the dumbing down of America through texting.  They wonder if texters will lose their ability to spell (if they knew how to do so before they started texting…)

Emoticons serve to create more casual bonding between texters.  <>():- ; and other punctuation marks serve to create emotion signals and sometimes even show up in once formal written business correspondence and emails.  With emoticons there is not as much danger in being misunderstood – rather it is the introduction of “casual” language into traditionally formal settings.

If your industry needs to create an acronym dictionary to decode the meanings of the many shortcuts in use– then things may have gone too far.  Acronyms, abbreviations and other shortcuts should enable communication — not trip it up.

To your communication success!

TTFN (ta ta for now), TTYL (talk to you later), :-).



American software development – guidance or prescriptions needed?

Greetings from Japan and the ISO software engineering standards meetings this week! Writing ISO standards can be fun as well as challenging (among other things) and as I give advice to our project editors, I often wonder what will best serve our  American software development needs – guidance or prescriptions?

What do you think?  What will keep us ahead of the rest of the world for the forseeable future?  What actions can ISO take to reduce the 40% or more rework that is the software development of today – by providing useful standards with proven practices and processes?

Guidance (e.g., here’s some suggestions and processes you might want to try at your organization) or Prescriptions (e.g., Here’s the model to follow to improve requirements and minimize costly rework?)

To your successful projects!


Carol Dekkers
email: dekkers@qualityplustech.com

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Copenhagen, Dusseldorf, Helsinki and other locations in 2010, visit www.qualityplustech.com.
=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======

What comes first – estimates or requirements?

We’ve seen many advancements of late in process improvement, better software estimating models, introducing flexibility and agility into software development, formal project management, limiting work-in-progress, etc. – all which incrementally advance projects forward and promise to reduce costly rework.  However, none of these methods addresses one of the most fundamental questions in software development:  what comes first estimates or requirements?

Chicken or Egg?If estimates come first… It seems like putting the cart before the horse if estimate precede requirements, but that is precisely how a good number of software projects go.  To begin with, someone has an idea or a business problem that software can solve but before any work even one dollar can be spent, the work has to go into next year’s budget and get funded.  This means figuring out some sort of estimate of work that has yet to be scoped out.  “Is it going to be bigger than a bread box and smaller than a football field?” is one way of saying – we need a “rough ball park” (guesstimate) that we can use in the budgeting process. Unfortunately this guesstimate process is clearly flawed because it is based on invisible and ether-like requirements. As such, the guesstimate is prone to + or – 500% or more variance once the real requirements are known.

This is like saying – how much will it cost to build a house for my family, just give me a rough estimate so I can go to the bank and arrange a mortgage.  This would be an absurd behavior – especially when one usually doesn’t get a mortgage in advance, and especially because the cost will vary depending on where, how big, how custom, and how the house will be built.  If  one secures a $500K mortgage amount – it gives an upper limit but doesn’t guarantee that a suitable house can actually be done for that amount.  Yet, we engage in this behavior in IT all the time – we guess(timate) for the budget cycle, the amount gets slashed during meetings, and ultimately the fixed price (based on little information) becomes the project budget!

If requirements come first… then in many companies nothing will ever get built and problems will remain the same forever.  Analysis paralysis is common (especially with shifting new business requirements) which gives rise to the support of agile and extreme programming approaches to requirements.  Many companies shifted their support from the arduous front end heavy “waterfall” methods of software development in favor of “progressive requirements elaboration” whereby requirements are discovered along the way. As such, requirements are always evolving with new user stories emerging only after the earlier ones are delivered in software.  So what happens when requirements are needed to build a better estimate (and thereby make sure the project has enough budget) yet an estimate is required before one can begin to scope out the requirements that will fit the budget?  It is a circular situation akin to the chicken and egg conundrum that has plagued humankind for years.

Pathway to cooperative results…One method that proves to work well with this dilemma is scope management – whereby a business “project” (more likely a program of work) is divided into sub-projects, scoped out at the highest level, quality requirements are thought about, and traceable estimates ensue.  More to come on this topic in the next post…

To your successful projects!


Carol Dekkers
email: dekkers@qualityplustech.com

Carol Dekkers provides realistic, honest, and transparent approaches to software measurement, software estimating, process improvement and scope management.  Call her office (727 393 6048) or email her (dekkers@qualityplustech.com) for a free initial consultation on how to get started to solve your IT project management and development issues.

For more information on northernSCOPE(TM) visit www.fisma.fi (in English pages) and for upcoming training in Tampa, Florida  — April 26-30, 2010, visit www.qualityplustech.com.

=======Copyright 2010, Carol Dekkers ALL RIGHTS RESERVED =======