Studies in four different organizations developing different types of software show conclusively that sizes of sprints or iterations measured using standardized COSMIC Function Points correlate much better with effort than Story Points do. This means that standardized size measurements are a better predictor for estimating Agile activities than the commonly used Story Points.

The use of functional size as a measure to make like-for-like comparisons between different software development or maintenance contracts has been common practice in administrative software for decades. In real-time software this practice is now starting to develop. Why did it take the real-time software community so long to catch up?

Estimation for Mobile and Cloud Environments

Estimation of cost, effort and schedule is a very important aspect in commercial software development and maintenance. For most types of development and maintenance, effort is usually the predominant cost driver in software development. Until recently, estimation was not an issue for mobile and cloud software. Mobile was the domain of young developers who crafted the first version of an app and distributed it to the world, bringing software to the cloud was usually a boardroom decision where the result was more important than the estimation of cost and effort.

But mobile and cloud are maturing as fast as they gain market share. For all business software that requires serious computing power, cloud is becoming the standard. Mobile is no longer the exclusive domain of hip young techies, since more and more business software is available on mobile platforms, backed up by the computing power of a back-office in the cloud. Now mobile and cloud has become serious business, the estimation of cost, effort and schedule requires serious attention as well.

For all types of software, the dominant determinant for effort is the size of the software. Organizations engaged in software engineering have struggled for years in search of acceptable quantitative methods for measuring process efficiency and effectiveness, and for managing software costs, for the systems they acquire, develop, enhance or maintain. One critical, and particularly elusive, aspect of this measurement requirement has been the need to determine software size. In the late 1970’s the concept of ‘functional size’ was developed, which enabled companies to build estimates on that figure before any code was written. IFPUG and Nesma established function point analysis methods to formalize the way functional size was calculated. These methods are based on the model that storage, processing and presentation of data takes place within a single application.

Mobile and cloud software use architectures in which these elements are separated. Apps present functionality to end-users without knowledge how this data has been assembled and processed and totally oblivious about where the base data might be stored. In the cloud, storage and processing of data are – at least logically – separated, offering functionality to all or authorized mobile devices by means of an API. Traditional methods to determine functional size have very limited use in these environments.

The basic COSMIC principles

For mobile and cloud environments the COSMIC method is well-suited to serve as a basis for estimating cost, effort and schedule. The basic principles on which the method is built, are architecture-independent. This means that all software, whether it is only a small component or a full-range business system, can be sized with this method. This size can be used to estimate the investment in money, development capacity and time to realize this software. The method is developed and maintained by an open-source community from all over the world and is actively supported by a number of companies and research institutions.

Last week, the latest book in the series on Advances in Systems Analysis, Software Engineering, and High Performance Computing was released: Modern Software Engineering Methodologies for Mobile and Cloud Environments. It also contains a chapter how the development and maintenance of these types of software can be estimated by using the COSMIC method. If you are responsible for estimating mobile or cloud software, this chapter will give you the basics you need, illustrated with examples. 

If you want to know more about the COSMIC method, please visit their website cosmic-sizing.org.

Succesful IT projects really do exist

We regularly encounter failed IT projects in the news headlines, feeding the perception that it is virtually impossible to finish an IT project succesfully.

It is true that still (too) many IT projects fail, but there are plenty examples that have completed succesfully. From those succesful IT projects we could learn a lot about the factors that lead to success, rather than trying to avoid known pitfalls. That's why I have done a retrospect and noted several observations that can support more IT projects to be succesful.

Succesful IT projects really do exist!

Adoption of the EPS-framework for packaged software estimation

 

On the IWSM 2012 conference in Assisi in October last year the NESMA presented the EPS-framework for the estimation of packaged software. A working group of NESMA has developed this estimating framework which supports the estimation of all costs related to the implementation and maintenance of packaged software. This framework can be the reference for comparison and benchmarking of package software estimates. The details for all six stages will be ready at the end of this year, but Comarch from Poland has already adopted the framework for some of their package implementation offers.

 

 

 

From rules to principles : COSMIC



Up to 1998 all methods to express functional size of software were rule-based. Performing the measurement rules led to a number of points that we call the size. Whether they were object points, use case points or function points, all these methods have a measurement procedure to award a part of the Fuctional User Requirements that satisfies a number of assessment criteria, with a defined number of points. To determine the number of points you must apply the rules. A group of people who were involved in the conception of ISO/IEC 14143 wanted to use the principles they had described to create a new generation of Functional Size Measurement method with a clear and defined measurement unit. Based on that unit a method could be created, based on principles to identify instances of that unit, rather than on rules. Out of that process, COSMIC was born.

Here is a piece of COSMIC history.

What is a second generation FSM method

Every now and again there is debate amongst practitioners of Functional Size Measurement about the best Functional Size Measurement method. In essence there is nothing wrong with such a debate.

Professionals should always be seeking ways to improve their profession. Discussions about the best way to do so are a logical part of such a quest. But they should be done based on the right arguments. And one of those arguments is often wrong in my point of view. That is the generation argument. I notice that there is a lot of misconception about what is meant with generation in relation to Functional Size Measurement. In my blogpost of January I discussed the first generation. In this one I will discuss the second generation of Functional Size Measurement.

The first generation of Functional Size Measurement

Every now and again there is debate amongst the practitioners of Functional Size Measurement about the best Functional Size Measurement method. In essence there is nothing wrong with such a debate.

Professionals should always be seeking ways to improve their profession. Discussions about the best way to do so are a logical part of such a quest. But they should be done based on the right arguments. And one of those arguments is often wrong in my point of view. That is the generation argument. I notice that there is a lot of misconception about what is meant with generation in relation to Functional Size Measurement.

 

Most used Functional Size Measurement methods

What are the most used Functional Size Measurement methods. Most people can quickly come up with the five methods that are standardized by ISO, but what else is there. Here is the Top 20 - in alphabetical order from Capers Jones, taken from the third edition of Applied Software Measurement. Since this book was published in 2008, I have added some new kids on the block.

Budget overrun or estimation deficit

The messages about budget overrun by IT projects are becoming more frequent again. Usually the tone is that IT projects are just runaway trains and that budget overrun is something that we just have to live with. An important source of this type of messages is the CHAOS series of reports that are carried out annually by Standish. In most of these types of reports one important aspect is systematically overlooked and that is the quality of the original estimate the project started with.

The best way to estimate the cost of IT services

Every now and again I get involved in discussions about what is the best way to estimate the cost of IT services. Should you have a dedicated calculation team that makes all the cost estimates, or should you train the whole project management community and all senior delivery staff to make good cost estimates. It is a question I have been struggling with for the past decade.

The best answer is: It depends. But there are some universal truths on this subject:

1. One estimate is no estimate
2. An estimate always contains uncertainty
3. Don't mix a cost estimate with a price offering

 

A cost model for software in capital projects

A growing number of capital projects, like a motorway tunnel or a specialised MRI scanner, needs software to make it a useful investment. To determine the investments in time, money and resources a number of key cost-drivers is essential:

• Delivery schedule
• Productivity
• Size of the software
• Required resource effort
• Quality

Each of these key cost-drivers has its own merits that should be taken into account to make the right decisions on how to integrate software in capital projects.

Estimating the Functional Size of Oracle eBS applications

For custom developed software functional size estimation method can be done with reasonable accuracy. I have developed an approach, based on NESMA function points, that has proven to be very useful for portfolio sizing.

Estimating the functional size of applications that were built in the Oracle e-Business Suite (eBS) package appeared to be difficult. Available eBS modules contain of a huge amount of functionality that can be used to configure or construct desired functionality for the end-users. But how do you determine the amount of functionality that is available to the end-user?

Factors of influence for approximate COSMIC size measurement

Over the last few weeks I have received much more requests than usual from fellow metrics professionals if I can provide a copy of an article I have written. I have recently discovered that LinkedIn now has the possibility to add publications to my profile. So when I received a request for a copy of the article

Approximate size measurement with the COSMIC method - Factors of influence



that I wrote, together with Theo Prins, for the SMEF 2007 conference, I put that copy on my LinkedIn profile. And it has been downloaded more than a dozen times already. Apparently it is a topic of interest. Why?

Successful outsourcing begins with a contract

Contracts are the key to successful outsourcing. If you don’t define what is being measured for success, or what the expectations are, then you are only asking for trouble with misunderstandings. Where one person might determine an “incident” to be changing a password another might not. How important do you think good contracts are to successful outsourcing? Has the wording in contracts had an impact in projects you’ve been involved with?

Contracts can also be terrific places to create incentives to deliver great quality or beat schedules, by offering bonuses and other inducements. For example, in maintenance agreements it can be a great idea to pay bonuses for smaller number of over-all incidents rather than pay on a per-incident basis. If developers are getting paid for fewer hours worked, it is in their interests to build things right the first time and to take steps to reduce the number of support issues that could arise.

Scope Management : A case that sailed the seas of change

We all hear stories about failed IT projects and how hard it is to manage those projects properly. But we hardly hear why those projects failed. Many IT projects fail because they had to live up to unrealistic expectations. A lot of research has been done about the dynamics of software projects and a great deal about the dynamic behaviour of software projects is already known. All too often we do not use this knowledge and all too often succeeding software projects goes wrong. With the northernSCOPE approach we are able to manage the scope of a software project by making sensible use of experience from the past and what research has taught us about the dynamic behaviour of software projects.

In 2008 I have written a paper that I presented at the SMEF conference that describes the journey of a project across the seas of change, all the way from idea to implementation. In this paper I demonstrate that northernSCOPE is not a complicated academic endeavour, but a straightforward, down-to-earth approach that helps the project manager manage the scope of a software project the same way explorers like Columbus managed their journeys into the unknown.

For each of the twelve steps of the northernSCOPE approach the practical steps that have been taken to navigate the project out of possible danger zones are described. For each step the underlying theory is translated to practical use to the project manager and his customer. Each time the project ran into new requests that were out of scope or added new requirements or constraints to the project, the northernSCOPE approach was used to demonstrate the effect of giving in to these new requirements and of not giving in. It is not a story of a great success with a textbook project, but that of a project that could prove all along the way to deliver value for money for the customer.

Excellent knowledge exchange on IT estimating

Last week I had the honour of presenting the opening keynote on the Galorath Conference. Although organised by a vendor of Cost Estimating Software it was an excellent and open knowledge exchange on IT estimating. The conference had a well balanced line-up of speakers who presented different pieces of the puzzle to estimate the cost of different aspects of IT cost estimation. All presentations should be available on the Galorath website soon, but here is my personal impression:

Estimating & Pricing Application Management for Oracle EBS

Although Application Management consumes 70-80% of the Total Cost of Ownership, estimating and benchmarking the related effort still receives little attention. Apparently, estimating Application Management is not so simple. One of the main reasons for this, is the fact that the scope of Application Management is more diffuse than the scope of a project.

When we have defined what activities are in scope for an Application Management service offering, we are able to model this and use this model as a basis to estimate the related effort and cost. To be able to do this in a transparent way, based on experience data, we have combined the vision of our Service Component Model with the estimating power and references of SEER IT.

Next week I will present this on the 2011 SEER International Conference in Eindhoven. Although it is organised by Galorath it will have a general focus on the advancement of software estimation. Therefore this conference is proudly sponsored by Ordina.

The Price of IT

We are far beyond the days of the internet bubble where you could ask any price for anything that had to do with IT. Most of us realize that IT consists of products and services like in any other industry. Because of the less tangible nature of our products and services the IT industry still has a mystical aura to a lot of people. Claims that IT would become a commodity shocked the world a few years ago. From that perspective it is only logical that one of the most popular books on software estimation, written by Steve McConnell, has a subtitle: Demystifying the Black Art.

To share my experiences in making IT estimation and pricing a more mature topic I started this blog. I hope it helps in demystifying the subject of the price of IT.