Tag Archives: function point analysis

Function Points (Software Size) come of Age: Mature, Stable, and Relevant


It is with pride and honor to share with you news about the upcoming Sept 13-15, 2017 celebratory (and educational) conference: ISMA14 (International Software Measurement and Analysis) – and its happening in just 4 weeks in Cleveland, OH, USA!

It’s the 30th anniversary of the International Function Point Users Group (IFPUG) – a not-for-profit user group I’ve been a part of for over 25 years.

We’re also celebrating 2017 as the International Year of Software Measurement (#IYSM).  It’s a great year for YOU to get involved (or more involved) and gain the benefits of measurement for software and systems projects!

As the Director of Communications and Marketing for IFPUG, I am excited that IFPUG is now mature (age 30!) and at the same time venturing in new directions with non-functional sizing (SNAP.)  We have much to celebrate, AND we also have more work to do (to publicize how Function Points and SNAP points provide objective measures of software size!)

The time is now!

No longer does your organization need to “fumble around in the dark” to find standard, reliable and objective software sizing measures.  Certainly there is an abundance of available units of measure (story points, use case points, source lines of code, hybrid measures, etc.) — BUT, only Function Points are supported by  ISO/IEC world standards and provide consistent, objective and technologically independent assessments of software size based on “user” requirements.  (Soon, the Software Non-functional Assessment Process – SNAP points for non-functional size will also become an international standard.)

Isn’t it time that your company adopts function points as a universal standard for software size?  YOUR timing is perfect because in less than 5 weeks, International Software Measurement and Analysis (#ISMA14) will be in Cleveland and you will have the opportunity to learn from industry experts in an intimate (less than 200 people) setting. (p.s., I’m one of the main conference speakers so you’ll know at least 1 person there!)

FUNCTION POINT proof is “in the pUDDING” (so to speak)…

We have an English proverb “the proof is the pudding”

The modern version of “The proof is in the pudding.” Implies that there is a lot of evidence that I will not go through at this moment and you should take my word for it, or you could go through all of the evidence yourself. Source:  http://tinyurl.com/5uc7eq3 

I can espouse the benefits of function points, as can IFPUG insiders and supporters such as the world-respected author/guru Capers Jones (whose 17 published books use Function Points as a universal software sizing measure). But, when the mainstream media features articles on Function Points – it’s a call to action for senior executives and IT professionals to take note! Here’s a recent example: (click on the image to read the full story!)

Need help selling your boss on the benefits?

I’ve written up the top 10 reasons to attend ISMA14 with us- won’t you join me (and a ton of other measurement professionals) in Cleveland on Sep 13?

Carol Dekkers, CFPS (Fellow), AEC, PMP, P.Eng.
President, Quality Plus Technologies, Inc.
IFPUG Director of Communications and Marketing

 

Advertisements

Function Point Analysis (FPA) – Creating Stability in a Sea of Shifting Metrics


Years ago when Karl Weigers (Software Requirements) introduced his  “No More Models” presentation the IT landscape was rife with new concepts ranging from Extreme Programming to the Agile Manifesto to CMMI’s (multiple models), to Project/Program/Portfolio Management.

Since then, the rapidity of change in software and systems development has slowed, leaving the IT landscape checkered with agile, hybrid, spiral and waterfall projects.  Change is the new black, leaving busy professionals and project estimators stressed to find consistent metrics applicable to the diverse project portfolio.  Velocity, burn rates, story points and other modern metrics apply to agile projects, while defect density, use cases, productivity and duration delivery rates are common on waterfall projects.

What can a prudent estimator or process improvement specialist do to level the playing field when faced with disparate data and the challenge to find the productivity or quality “sweet spot”?  You may be surprised to find out that Function Point Analysis (FPA) is part of the answer and that Function Points are as relevant today as when first invented in the late 1970’s.

What are function points (FP) and how can they be used?

Function points are a unit of measure of software functional size – the size of a piece of software based on its “functional user requirements,” in other words a quantification that answers the question “what are the self-contained functions done by the software?”

Function points are analogous to the square feet of a construction floor plan and are independent of how the software must perform (the non-functional “building code” for the software,) and how the software will be built (the technical requirements.)

As such, functional size, (expressed in FP,) is independent of the programming language and methodology approach:  a 1000 FP piece of software will be the same size no matter if it is developed using Java, C++, or other programming language.

Continuing with the construction analogy, the FP size does not change on a project whether it is done using waterfall or agile or hybrid approaches.  Because it is a consistent and objective measure dependent only on the functional requirements, FP can be used to size the software delivered in a release (a consistent delivery  concept) on agile and waterfall projects alike.

WHy are fp a consistent and stable measure?

The standard methodology to count function points is an ISO standard (ISO/IEC 20926) and supported by the International Function Point User Group (IFPUG.)  Established in 1984, IFPUG maintains the method and publishes case studies to demonstrate how to apply the measurement method regardless of variations in how functional requirements are documented.  FP counting rules are both consistent and easy to apply; for the past decade the rules have not changed.

RELEVANCE OF fp in today’s it environment

No matter what method is used to prepare and document a building floor plan, the square foot size is the same.  Similarly, no matter what development methodology or programming language is used, the function point size is the same.  This means that functional size remains a relevant and important measure across an IT landscape of ever-changing technologies, methods, tools, and programming languages.  FP works as a consistent common denominator for calculating productivity and quality ratios (hours / FP and defects / FP respectively), and facilitates the comparisons of projects developed using different methods (agile, waterfall, hybrid, etc.) and technical architectures.

consistency reigns supreme

THE single most important characteristic of any software measure is consistency of measurement!

This applies to EVERY measure in our estimating or benchmarking efforts, whether we’re talking about effort (project hours), size (functional size), quality (defects), duration (calendar time) or customer satisfaction (using the same questionnaire.)  Consistency is seldom a given and can be easily overlooked – especially in one’s haste to collect data.

It takes planning to ensure that every number that goes into a metric or ratio is measured the same way using the same rules.  As such, definitions for defects, effort (especially who is included, when a project starts/stops, and what is collected), and size (FP) must be documented and used.

For more information about Function Point Analysis (FPA) and how it can be applied to different software environments or if you have any questions or comments, please send me an email (dekkers@qualityplustech.com) or post a comment below.

To a productive 2016!

Carol

Latest installment of “Ask Carol: Sizing Alternatives when Cost is an Issue”


Happy new year 2014!

I present you with the latest installment of the Software Professional’s advice column I pen for QSM, Inc. called “Dear Carol” (click here also for the direct link)

Ask carol - Sizing alternatives when cost is an issue

Enjoy!  Comments are always appreciated and welcome. What do you think of this post?

Carol

Latest installment of Ask Carol: No matter What… in Project Management, Size Matters


Just wanted to share with you my latest installment on the QSM website blog – My Dear Carol advice column.  Enjoy!

Ask Carol - size matters

Here is the link to the rest of the article:  http://www.qsm.com/blog/2013/ask-carol-no-matter-what-project-management-size-matters

Fundamentals of Software Metrics in Two Minutes or Less


 

Fundamentals of SW Metrics in two minutes or lessTo read more click on the link:
http://www.qsm.com/blog/2013/fundamentals-software-metrics-two-minutes-or-less

Estimating Before Requirements with Function Points and Other Metrics… Webinar Replay


On June 7, 2012, I conducted an hour-long webinar on “Estimating Before Requirements with Function Points and Other Metrics” before a worldwide audience spanning a myriad of software development specialties/industries and across many countries.

In the event that you missed the live webinar or would like to listen/view the replay, it is available (at no charge) at http://www.qsm.com/Webinars/Estimating-before-Requirements

At the end of the webinar, I offered to send attendees several papers (also downloadable from this link) as well as a Scope Management primer.  If you are interested, please send an email to me at: dekkers (at) qualityplustech (dot) com.

Let me know what you think of the concepts and the webinar!

Carol

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!

Carol

Whose job is IT anyways?


The title was a purposeful play on the acronym “IT” (information technology) because there is often no one person who takes responsibility for failed IT projects. In addition, it is not as if there are not project failures everywhere.

Notwithstanding one of my least favorite (but often quoted) research studies, the Chaos Report cites that about one-third of projects are successful when it comes to IT.  What gets in the way of project success?  Lots of circumstances and lots of people!

When a software intensive project fails, there is no lack of finger-pointing and blame sharing – yet seldom do teams stand up and confess that the failure (over budget and behind schedule and failing to meet user needs) was due to a combination of over and under factors, along with fears:

  • overzealous and premature announcements (giving a date and budget before the project is defined);
  • over optimistic estimates of how quickly the software could be built;
  • under estimation of the subject complexity;
  • assumptions that the requirements were as solid as the customer professed;
  • under estimation of the overall scope;
  • under estimation of how much testing will be needed;
  • under estimation of how much time it takes to do a good job;
  • under estimation of the learning curve;
  • under estimation of the complexity of the solution;
  • under estimation of the impact of interruptions and delays;
  • over anticipation of user participation;
  • over optimism about the availability of needed resources;
  • over optimism about hardware and software working together;
  • over optimism about how many things one can do at once;
  • risk ignorance (“let’s not talk about risk on this project, it could kill it”);
  • over optimism of teamwork (double the team size doesn’t half the duration);
  • fear of speaking up;
  • fear of canceling a project (even if it is the right thing to do);
  • fear of pointing out errors;
  • fear of being seen as making mistakes;
  • fear of not being a “team player”;
  • fear of not knowing (what you think you should);
  • fear of not delivering fast enough;
  • fear of being labeled unproductive;
  • fear of being caught for being over or under optimistic.

Therefore, I ask you, on a software intensive IT project, whose job is it to point out when there are requirements errors, or something is taking longer than it should, or it is costing more than anticipated. In traditional waterfall development because there’s so much work put into the planning and documenting of requirements, pointing out errors are  either no one’s job or the team’s (collective) job which really relates to no one’s job.

Often it is easier (and results in less conflict) to not say anything when the scope or schedule or budge go awry on a software project. Yet it is this very behavior that results in so much rework and so many failed projects.

Agile and Kanban projects are different

Several of the advantages to using Kanban and Lean and Agile approaches to software and systems development is that the methods address the very items outlined above.  Building better software iteratively becomes every developer’s job rather than no one’s:

  • Fear of pointing out errors is removed because the time that goes into a scrum is days and weeks not months (so participants don’t get defensive about change);
  • Over and under optimism remains but is concentrated on smaller and less costly components of work (i.e. days instead of months or years);
  • Risk is not avoided or ignored because we are no longer dealing with elongated and protracted development cycles (spanning seasons);
  • Assumptions come out with better and more frequent discussions;
  • Over optimism about how many things one can do at once is removed because Kanban limits the amount of work-in-progress;
  • Under estimation of the impact of interruptions and delays is minimized because such factors are addressed in Kanban;
  • Over anticipation of user participation is managed through direct user involvement.

What do you think?  Join us at the Lean Software and Systems Consortium conference LSSC11 from May 3-6, 2011 as participants and speakers address the best ways of advancing software and systems methods including Lean, Kanban, Agile and other exciting new ways to deliver high quality software more efficiently and effectively.

These newer approaches make it easier for everyone in IT to make it their job to build better software.

Wishing you a productive week!

Carol
@caroldekkers (twitter)

Share

The importance of Being There (at work)!


Did you know?

Only 26 percent of IT employees in North America are fully engaged at work, while 22 percent are actually disengaged, according to a global study by consulting firm BlessingWhite.

Being there…

At a time when unemployment is at an all-time high, only one-quarter of IT workers are fully engaged or Wowed by their work, while the remaining 75% just go through the paces or don’t care at all.  When you consider specific industries fraught with frustrations of rework (exceeding 40% in some areas) and impossible deadlines such as in waterfall development, I would bet the excitement factor of going to work is even less.

#Kanban, #Lean, and #Agile communities are exceptions

The Agile Manifesto recently celebrated its 10th anniversary last month, and Kanban, Six Sigma, Lean, and Agile methods now share space with waterfall as leading methods in the software and systems development space.  Agile (in my humble opinion) was one of the first to restore a sense of sanity in software development.  In earlier times, a group of  business customers with rapid fire changing requirements would challenge software developers (tired of the constant change and “jello” like demands) for amorphous software products.  The result too often – failure.

It makes sense, in this type of environment, to do iterative development.  It was illogical to do the opposite: long development cycles to produce products already obsolete before they hit desktop computers.

Approaches like Kanban, Lean, Agile, Personal Kanban and others continue to transform our industry and inspire software developers to become “fully engaged” in the work.

Less head banging… but you have to engage

Certainly there is head banging and more job satisfaction in this new world (if “tweet volume” is any indication, the Kanban/ Lean/ Agile communities are a happier lot!) but it takes commitment to show up and be part of the action.

I believe that the Kanban and Lean and Agile communities know the importance of really being present and engaging at work.  We also know it is critical to create a community of like-minded people who meet in-person – at conferences, local meetings, at social events.

LSSC11 is coming soon!

The landmark Lean Software and Systems conference is only 10 weeks away in Long Beach, CA on May 3-6, 2011.  Make your choice of conference to attend in 2011 the LSSC11 (especially if you can only attend one!)  See my related post Top 10 Reasons to attend LSSC11.

Join the movement of people who know the Importance of Being There in software and systems development: The Lean and Kanban and Agile communities.  I hope I will meet you at LSSC11!

Have a Wow! and engaging week at work,

Carol

Share

Pre-flight email checklist: THINK before you click…


I AM OVERWHELMED BY EMAIL!

There I said it, I am overwhelmed with email and I can’t stand it!

I thought I was the only one until I read Tim Tyrell-Smith’s post today: How to reduce the Quantity of Incoming Email and realized that there should be a pre-flight email checklist to save our sanity… and to encourage Thinking before Clicking!

Since joining the world of social media I realize my “connectivity” has grown exponentially, but not all in a good way. Even with my SPAM filters set to high, I get so much email that it is overwhelming!

I feel like I must have ADD (attention deficit disorder) because my day is interruption after interruption (sorry TweetDeck!) and I need help (and I know I am not the only one!)

Pre-flight email checklist (THINK before you click):

  1. If it takes longer to write an email (to one person) than it does to walk across the hall / call the person, don’t write an email. Pick up the phone or get up from your desk.
  2. If multiple people are involved and you need responses, consider whether a one hour meeting would work better than filling up in baskets with back and forth threads for the next 2 weeks.  If so, schedule a tight meeting and solve the issue in one fell swoop.  (Just because it doesn’t take paper doesn’t mean email is green — it can litter cyberspace!)
  3. If 1 and 2 are not possible, consider other options: Twitter or a blog post or an update at a staff meeting might be better than email.
  4. You’ve thought through 1,2 and 3 and decide your message needs an email.  Never negligently click “Reply all!”  unless you’ve gone through these same steps:Make sure you set aside a dedicated time (10 minutes minimum) to THINK before you click:
  • Consider your recipient: Walk for a moment in their shoes and think: what would be your response to this email? Make sure to emphasize the key points (i.e., make the reason for the email crystal clear). Do not “assume” that everyone shares your knowledge so give necessary background.  In the words of Peter Drucker:  It is important to state the obvious otherwise it may be overlooked.
  • If you expect/need a response, be clear about it. Tell recipients what you need from them (each), by when, and how (call, email, comment, decide…).
  • If it is an information only email, say so. No one has time to read your mind.
  • Consider using the subject line as a filing cabinet: Use tags to identify topics and intent. E.g., ABC Department meeting notice, Feb 17, prep material attached; or Dekkers: Blog Marketing draft – comments needed by Feb 20, 2011.  In this way, recipients can quickly find YOUR email from a pile in their in basket.
  • Consolidate information! If the email is about a meeting: include dial-in information (top and center for easy access!), meeting date and time, and  attach all preparatory material all together in a single email. There is nothing worse than having to pull up 3 emails to get ready for a single meeting!
  • Preview before sending: Spellcheck, attach files, check all recipients are included.
  • If there is emotion involved save the draft email and wait a full day (or at least an hour) before doing the doublecheck and send step below.
  • If it’s a regular email (non-emotional), take a one minute break – stand up, look out the window, anything to clear your head. Then go back and re-read your email, double-check attachments, recipients, bcc’s etc.
  • When you are sure it looks right consciously hit “send”. NEVER hit send when you are multi-tasking (i.e., on the phone). Once an email has been sent it is in cyberspace FOREVER (regardless of rescinds!)

I plan to follow this checklist starting today! What do YOU think? Do you have any additions?

p.s., DON’T forget to sign up for my Feb 17, 2011 (11am – 12:30 pm EST)  FREE Webinar:  Navigating the Minefield – Estimating before Requirements.

Register here: http://tinyurl.com/6flgjwr

To your increased productivity!
Carol

Share