COSMIC Method ‘Measurement Manual’ Version 4.0

COSMIC

As you well know, DCG provides a number of solutions and services around quantitative sizing, including Function Point Analysis, FP Lite, Quick and Early Function Points (QEFP), SNAP and COSMIC.

So, we're happy to announce that version 4.0 of the COSMIC method ‘Measurement Manual’ is now available for download from The Common Software Measurement International Consortium. Version 4.0 is taking the place of the previous version, 3.0.1.

Version 4.0 includes some significant updates, with the objectives of:

  1. Improving the explanation of the method by re-writing some of the text, using more diagrams, adding more examples and clarifying some definitions and rules.
  2. Including the proposals from Method Update Bulletins 7-11, which were published over the last four years. These Bulletins are used to announce proposed improvements to the method between major releases.

The updated manual should be of use to all those interested in quantitative sizing, so be sure to check it out. If you have any questions about COSMIC or the updated manual, let us know!

 

Written by Default at 05:00
Categories :

DCG and CAST: Getting Started with Function Points

As we've previously mentioned, we have a series of videos up on our YouTube channel that we’ve created with CAST to explain some of the nuances of automated function point counting.

Watch the video below to hear from Mike Harris, President and CEO of DCG, as he discusses the criteria that you should consider when choosing between manual function point counting (for example, if you're using estimation) and automated function point counting (for example, when you'll be repeatedly counting the same code over a series of releases). He also explains how you can begin to implement an automated function point counting program.

DCG provides both manual and automated counting services, and our automated counting services are carried out via our partnership with CAST.

Written by Default at 05:00
Categories :

Software Analytics Training

David Consulting Group is well-known throughout the industry for our expertise in Function Point Analysis and Software Estimation. As such, we offer a number of classes to share what we’ve learned over the years and to help your organization improve its Software Analytics practice, no matter your current level of implementation.

Here’s what we currently offer:

  • Function Point Fundamentals - A two-day course to teach you how to apply function point counting techniques. This class can be deployed on-site or via DCG University, our online learning platform.
  • Function Points: Advanced - A one-day course to accelerate your comprehension of the Function Point Analysis technique through intensive instruction and hands-on practical application.
  • CFPS Preparation - A one-day course to prepare participants for their certification exam. This class can be deployed on-site or via DCG University, our online learning platform.
  • Quick and Early Function Points - A one-day class that provides quick techniques for sizing units of work to support estimating and measuring progress.
  • Estimation Techniques Workshop - A two-day course to help you to understand estimation and sizing as it applies to your organization.

All of our classes can be customized to meet your needs, so if you have specific goals or questions, just ask! We’re happy to work with you in any way that we can to help you implement or improve a Function Point Analysis or Estimation program. If training isn’t what you’re looking for, we provide Advisory Services as well!

David
Contact:

David Herron, Vice President
d.herron@davidconsultinggroup.com

 

David Herron
Vice President, Software Performance Management

Written by David Herron at 05:00

A Simpler Life Without Function Points?

DavidWe have been using function points for the past 18 months. I am responsible for our function point program and I am beginning to think that life was much simpler without them. Function Point Analysis is a technique used for measuring the functional size of a delivered piece of software. Simply stated, it provides the quantification of features and functions that my user has asked me to deliver. The methodology is pretty straightforward, using techniques and terms that are easy to understand and mathematical formulas that we learned in the third grade. I have been using function points for two purposes: to estimate / predict software delivery outcomes and to measure performance (i.e. productivity and quality).

In my shop, everyone is asked to estimate their projects. The project estimates are to include predicted levels of effort, cost and delivery schedules. We use function points as a size indicator because it makes sense that if you have to accurately predict how long and how much effort developing a piece of software is going to take, that you should have some sense of its size. Of course, there are other variables you have to solve for, like complexity and how you plan to manage the development of a particular piece of software given its size and complexity. I actually find function points to be a good indicator of size and very useful in helping me articulate exactly which features and functions we are actually going to deliver to our end user. This ultimately makes it easier to discuss estimates with our end user and to manage their expectations. So, what's the problem?

In my shop, things are always changing. Customers are frequently making last minute changes to what they want delivered or a project’s key resources are being borrowed for other projects that are in trouble. It makes it very difficult to accurately predict outcomes, and ultimately, projects are occasionally not delivered on time or within budget. And every time one of these failures occurs, it seems like folks are quick to blame function points. Function points become the convenient focal point of all that is wrong with a failed project. The logic behind this thinking is that function points must not have accurately sized the project and therefore, we could not properly predict the outcomes. I find myself constantly defending function points and pointing out what the real culprit(s) for these occasional failures are; e.g. ambiguous requirements, changing priorities, resource constraints (take your pick!).  Without function points to blame, everyone could go back to blaming each other for the project failures that occur, and my life would be much simpler.

As I mentioned earlier, we are also using function points to measure things like productivity and product quality. It is pretty cool. We measure the function points we deliver and use effort and cost to determine a rate of delivery and a cost per function point, two key performance indicators. We can also show a comparative value across projects by using function points as a normalizing factor when assessing the number of defects delivered for a piece of software, a measure known as defect density.

Sounds pretty good, doesn't it!? You would think that these measures would be good information to have. Well, here's the issue. In my shop, people are not held accountable for properly recording their time; therefore, we don't do a very good job of accurately recording time spent on our projects.  And so what happens is, once people know that performance is being measured, they get a little crazy. They start changing their behavior. They find that they can “game” the system and start recording their time such that they can make their performance numbers look better. In addition, folks aren't held accountable for recording defects, and so getting any kind of consistent or accurate defect information is a challenge as well.  Obviously, all of this distorts the measures and impacts their credibility. 

So, once again, if we stopped using these darn function points, we could find any number of alternative excuses for our project mishaps – just like we used to. It would allow for greater creativity and resourcefulness on the part of project managers that are trying to save their rear-ends. Rather than use their fingers to count function points, they could use their fingers to point at and to blame others. That way they can't be held accountable (or learn from their failures).  And it would make my life so much simpler.

 
David Herron
Vice President, Software Performance Management

Written by David Herron at 05:00

DCG and CAST: Automated Function Point Counting

Automated counting is fairly new, which has some people skeptical about its “accuracy." Given that there is no universally agreed unit of measure for software size (no block of metal in a French standards institute), the real test of a new way to measure is if it has broadly linear proportionality to things we care about (e.g. software project effort), and if they can be measured consistently. So, over the last few years, DCG and CAST have worked together to perfect the algorithms and processes that we use for the automated counting of applications.

Automated counting creates consistency in the counts because once the algorithms are set up and the applications are calibrated, each count will be carried out the same way.

Of course, DCG provides both manual and automated counting services, but our automated counting services are carried out via our partnership with CAST.

Both manual and automated counting techniques can be useful and consistent for sizing software, but there are times when one technique may be better for a particular situation than the other. For instance, if you have a lot of applications to count repeatedly, automated counting may be a more economical choice.

We have a series of videos up on our YouTube channel that we’ve created with CAST to provide a better understanding of automated function point counting, such as where it can be useful and where it cannot be used (e.g. measuring size before source code is available).

Watch the video below to hear from Mike Harris, President and CEO of DCG, as to when automated counting may be preferable over manual counting and what benefits exist in utilizing automated counting techniques with CAST.

Written by Default at 05:00
Categories :

"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!