COSMIC Method ‘Measurement Manual’ Version 4.0


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 :



I attended IFPUG’s ISMA 9 conference in Madrid on the 27th of March. There were over 150 delegates with, as you might expect, a strong percentage of Spanish attendees.

The conference offered the opportunity to take both the CFPS (FP) and CSP (SNAP) examinations, and both Tom Cagley and I took the challenging CSP exam. DCG is an authorized provider of Software Non-functional Assessment Process (SNAP) consulting and training, and it was interesting to see that other companies are noticing the benefits of the framework as well.

The key message of the conference was “Measuring for Business,” and a number of thought provoking speakers really drilled home the importance of why clients need to find some measure of size to inform and validate provider estimates, and that benchmarking provides valuable insight into getting value for money for your organisation.

Another interactive demonstration focused on why estimates improve with the more information that you have – amazing what you can do with a pair of scissors and paper rings!

Overall, the conference really emphasized the use of function points as the recognised industry measure, allowing you to look not only at your own organisational data, but also at the wider community to understand where you are in terms of productivity, cost and quality. DCG follows this approach with our “Measure. Optimise. Deliver.” approach to delivery.

The only lowpoint of the trip was a number of delegates, including Tom Cagley and myself, caught Spanish Flu! Otherwise, it was a successful trip to Madrid and a great conference from IFPUG.


Steve Kitching
Measurement and Estimating Specialist

Written by Steve Kitching at 05:00
Categories :

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

Using Automated Function Points in Software ADM Contracts

MikeAs some of our readers may know, DCG has been involved in the development of Automated Function Points (AFPs) for many years – from the early days of experimentation to industry-recognized OMG/CISQ specifications with growing use in a number of beneficial niches. However, as usage is growing, we have received more and more questions from our clients, prospects and partners about contracts and how to incorporate an agreement for the delivery of software development and/or maintenance. 

Of course, it is relatively easy to have a conversation on this topic about what can and can’t be measured with AFPs and what the expectations on both sides of the agreement should be. It is not necessarily easy to move from that conversation to specific contract terms. So, we decided to produce a template of contract terms that can be used to start discussions about what to include on this topic in a broader outsourcing or one-off Master Services Agreement (MSA) or Statement of Work (SoW). 

Our ideas are published on our website here. Our template is not intended to be lifted directly into an agreement “as is,” but rather to form the basis of a discussion between the parties about what they want and need in their agreement. Our template is intended to be inserted into an existing MSA or SoW – we have not attempted to cover all the terms that such a document needs – only those specifically related to AFPs. 

You may disagree with our ideas and we may have missed some things. That said, we’d love to hear from you so that we can build on our idea and continue to update this document over time with newer versions.


Mike Harris
DCG President

Written by Michael D. Harris 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!