How FPA and COCOMO II play together

As I told you lately there are several ways to estimate the effort for software projects. Most important for all of them is that they don't just create their values through some kind of voodoo magic. They have to use a comprehensible and parameterizable way for their calculation. First this is needed to get a better base for argumentations with you project stakeholders. Second you'll have to review your calculation during the development and when it is finished to adjust those parameters for future calculations.

Instead of thinking about an own, totally new way of estimation it often is much better to use the experiences of others and fall back to well proven methods. It's not only that you can learn from them. But you have also by far less problem when arguing your numbers. I've really often undergone and observed how high values for the first effort estimation based on the developers experience frightened the project management or the customer. As a result the developers are forced to recalculate (!) until the values are low enough. *sigh* What a bad, bad way, almost allways leading into a project failing or at least a strong delay. Estimations based on more academic methods are accepted much more instead.

My favorite methods are the function point analysis (FPA) together with COCOMO II. The first one is a method that examines the software project from five angles. Those are external inputs, external outputs, external inquieries, internal logical files, and external interface files. Based on parameters their complexity is rated as low, medium, or high. At the end they are counted for each type and complexity multiplied with a defined value. Adding all together results into the unadjusted function points, an abstract unit for the size of a software. Too fast? Don't panic, I'll document this here in a later entry and you'll see how simple it is. But the FPA isn't finished here. Non-functional requirements also have influence on the effort. So there are 14 general system characteristics, each one with six descriptions and assigned values from 0 to 5. 0 means that there is no influence, 5 shows a high impact of the characteristic for the project. All together lead to a value adjustment factor between 0.65 and 1.35. Multiplied with the unadjasted function point you now get the total adjusted function points. I'll also cover this in detail later.

And now? How does it help me to know that my project has a size of 2731 total adjusted function points? The next step is to determine the total program size for the used language. There are different tables available, like http://www.qsm.com/FPGearing.html. The values here help you to get a feeling for the size of your application in source lines of code (SLOC). So for our TAF value above we would get 166,591 SLOC in JEE, 161,129 in C#, and 95,585 in Smalltalk. For some this may be astonishing, but not for Smalltalkers with Java and .NET experience. *smile* The table of languages on the page above also shows Notes or SQL. That doesn't mean that all those languages fit for the same problems. Also some of the newer languages like Ruby or Python are missing.

Even if we're now a step further we still don't know the effort. This will be calculated with the help of COCOMO II. This method provides formulars which take the software size as estimated above as an input parameter. Another one is the size of reused code. There are several more input parameters, but the most important are the scaling factors, the product factors, the platform factors, the personnel factors, and the project factors. Alltogether 22 factors have to be rated between very low and extra high by given questions and answers. Playing around with the result values shows how much influence the answers have. As a result you get the total effort and the duration. COCOMO II is more complex than the FPA, but it is also not so difficult to handle. I'll write about it later, too.

Right here the estimation isn't finished. But you allready have got the most important values: How much will it cost (in personnel) and how long will it last. Doing this more often, in different project and with reviews of project in progress or finished projects you'll get more training in estimate the size right and to rate the general system characteristics and the factors better. COCOMO II additionally allows you to adjust the parameters to your company and environment. So you'll get even better estimations.

New malt in collection

As a result of our last tasting on March, 23rd, I've bought a new malt for my collection. This time it has been an Isle of Arran Lepanto PX Brandy Cask Finish. The distillery is very young, opened in Lochranza on the Island of Arran in 1995. I've tasted it because of my good experiences with cask strength malts from the islands. This one matured the last seven months in a brandy cask of the famous Bodega Gonzales Byass after the first years in a sherry cask. Now it is sold in a limited edition with a strength of 61,3%.

The Arran surprises with an intensive aroma of butterscotch and mint-toffee, together with a little note of wood. The palate is fruit-laden with nuts, cinnamon, and some spices. In the finish this malt is very complex and warm. A lot of spicy and fruity flavours suit and it lasts a long time. Together with the real fair price - around 55 Euros - I havn't been able to resist. Now I've got twelve malts. *smile*

My other tastings last friday have been a Glenrothes 1972 Signatory, a Glenkinchie 1987 Signatory, a Clynelish 1973 Signatory, and as a classic to fill my card a Lagavulin 16y. The three signatories are also cask strength malts. The Glenrothes is also a real good one, with honey and oranges in the aroma, and additionally vanilla, chocolate, and malt in the palate. The finish is warm, soft and creamy, and long lasting. Unfortunately it costs about 190 Euros. *sigh*

Enterprise "fun" with the Wii

Edward Herrmann from Colgate-Palmolive described in his SAP network blog how the playing with the Wii led to an integration of the Wii - OK, the Wii remote - into a Ruby on Rails application connected to a SAP BW backend. The application is a resource planner providing a drag and drop interface which is now controlled by the Wii remote. A video shows how it is used with the controller. A funny idea.

Finished reading of "Siddhartha"

Yesterday I've finished my reading of "Siddhartha" by Herman Hesse. You've read about my book order. What shall I say? I'm absolutely impressed. Such a wonderful writing, his poetry, and the idea behind it. What a great piece of literature. It is no wonder that this book is sold many million times around the world.

As a result I'll start to take a deeper look into the ideas of Buddhism. I've allways planned this. From what I've heard until now it contains many ideas that I've also got in my mind. OK, there are also some thoughts I can't share. But that won't hinder me in learning from it.

Why research labs fail at innovation

Scott Berkun added an interesting article on why research labs fail at innovation. Even if he admits to never have worked in a R&D team his observations are to the point.

The role of software cost estimation

One great and important question of customers is how much it will cost what they get. This naturally applies for software projects too. But due to the nature of software development that it is often unclear what exactly is wanted and that the requirements are typically changing about two to three percent each month. So software development is no simple production process. Like in every other technological development costs can't be calculated. They have to be estimated based on the determinant factors.

Very often those estimations are done through just asking the developers. But they've got only their small view on the whole work. A closer look at the tables of Capers Jones shows number from 60% for coding and unit testing in web projects down to 19% for both in military projects. Over all web projects consist out of seven activities while military projects separate between 25 different tasks. There are also other types of development projects listed. The average of coding and unit testing is about 28%, without web projects only about 22%. So even the typical practice of just doubling the developers estimation is by far too low. Additionally most developers see less effort for coding and testing as it is needed in reality. The experienced programmers are asked, but they map their performance on all team members, also the slower ones.

Based on the estimation the project planing will be done. Staffing and timeline, resources and actions. But if the basic numbers are too low the whole planing is not coherent. Sooner or later this will be detected, but correcting it will be expensive. Additionally very often the project vastly delays. As a solution to handle this, a comprehensible process for the software cost estimation is needed. It has to offer methods to cover all the aspects of a software system in a common understandable way, to transpose the results into the target environment, and to regard the influence hard and soft constraints for the project. It also has to offer setscrews for later adjustments after comparing the estimation with current review results. So you'll get a learning and self improving system.

An approved combination for this work is the function point analysis in combination with COCOCMO II. I'll start a series of articles here where I'll give a managable introduction how to use those two methods together and improve your estimations through later justification.

Take a look over the horizon

Martin Fowlers latest blog entry covers the transaction handling of eBay. It shows how it is worth to take a look over the horizon and use uncommon solutions if it helps you. Solutions like taking Smalltalk for developing.

The world isn't black and white

I'm allways astonished why people tend to seperate the world into black and white, why they devide it into their position and the rest as one uniformed adversarial belief. That's one of the reasons why discussions often get acute and controversial. Those people only know black and white.

With everything in black you don't see anything. No light, the total absence of light. And as a contrast everything is by far to bright when white is the only color you know. It will hinder you to perceive any nuances.

One way to cope with this is to allow the fact that there are millions of small steps between bacl and white. All those greys - even if the human eye can't differ between them all. There are so many nuances and it would be a waste to ignore them.

And it even gets better if we all accept that there is an incredible large number of colors in the spectrum of light.

And we people, our lives, our opinions, our goals, our pleasures and sufferings, everything that makes the human being, is somewhere inside this spectrum. So don't seal yourself, enjoy the colors of live.

Happy St. Patrick's Day

To all Irish people and friends of the Irish culture around the world a happy St. Patrick's Day. Have fun and enjoy the day.

I just remember my great St. Patrick's Day in Boston six years ago. *sigh*

Aston Martin back in British hands

Ford has sold Aston Martin to a UK-led group for £479m ($924m).

Welcome back home. *smile*

Restarted drawing

It has been a long time since having art as an intensive course on high school. I haven't done very much during this time. Only drawing little penguins for my wive. But after my very intensive talks to Hans N. Beck I really want to draw again. Thanks Hans.

So today I've buyed two sketch blocks, six artist sketching pencils, and a Faber-Castell pitt monochrome set with different pencils (graphite, chalk, white chalk, sepia, and sanguine) and pastels (black, white, sepia, and sanguine). It also contains a kneadable eraser. All I allready have had over 20 years ago.

Now I'll start to train drawing architecture and impressions of cities, villages, and nature. I hope I can soo present you my first results here.

Featured book: The Art of Program Management

I've just read the book The Art of Project Management by Scott Berkun, a former Microsoft project manager and now working as a consultant and author. It is full of plain experience, covers all the important areas if you're responsible for software projects, and doesn't slays you with information overload and too much formalism. A must read for software project managers.

Other interesting places to look are his site and his blog.

Which ideal justifies the means?

As I drove to work this mornig I saw a scientologist Jehovah's Witnesses standing with his magazine "The Watchtower" at the wayside. I've often seen this man, and I thought about how his ideal is to convince others to believe like he does. At the same moment I've thought about two news of yesterday: the NATO is starting their offensive in southern Afghanistan and two islamists blowed themselves up and killed about 120 people. And a part of the current song of Herbert Grönemeyer came into my mind. In this song which holds a mirror up to the mankind one phrase is "Which ideal justifies the means? Who puts the fire out? Legions of crusaders got uniformed on the wrong track.".

We all have ideals, different ideals. Me too. But does any ideal justify the means? Even if an ideal could be met, is it the ideal of everyone? And why should any ideal be better than another one? I don't know the answer. But since people are one earth they're fighting for their ideals. Some silent, some loud, some by killing themselves, some by killing others. It is crazy, so useless. Why is it so difficult to have respect for each other and let each one live their own life?

What do you think about it? Please leave a comment. I would really like to know if think whether this insanity will stop sometime of if we've got to accept this as a port of the human nature? *sigh*

First LAS design documentation

The first design documentation of the Tideland Lightweight Application Server can be read here. You can see how the LAS provides an infrastraucture for the dynamic, client-dependend instantiation of components and services. Components work synchronous in their context or shared and services work asynchronous.

Tasting Notes Bowmore 1970 and Bunnahabhain 1978

Last friday we've had our first tasting at Kottkamp in 2007. It has been a great pleasure and beside well known single malts some new upper class whiskys were provided. One of them has been the 34 years old Bowmore 1970 Signatory matured in a oloroso sherry butt, cask strength (56,6%) and limited to 440 bottles. it hasn't been cheap, but really worth the money. The colour is a very deep amber, the nose is a complex mixture of sherry, vanilla, and few notes of terpentin. But as the whisky gets warme while you're holding it in your hand the nose gets more peaty. The palate is also complex, warm, and spicy. It has some subdued notes of hazelnuts, bitter chocolate, and smoke. The long finish of the Bowmore is warm and soft with some smoke. I really would loke to compare thes malt dictly against the Springbank 1969.

The second one has been a great surprise. OK, it is also not cheap, but by far less expensive than the Bowmore. It has been our last malt this evening, the Bunnahabhain 1978 Signatory. 27 years old, matured in a sherry butt and also cask strength (55,6%). The colour is nature, the nose warm and complex, mostly sherry with strong notes of vanilla, toffee and nuts. The palate of the Bunnahabhain is warm and soft, with flavours of nuts, malt, raisins, and a little bit toffee. The epicure ends his treat with a very long lasting finish, again overwhelming complex, warm, and soft. This whisky will definitly find its way into my collection.