Ideas on Enterprise Information Systems Development

This blog is devoted to ideas on Enterprise Information Systems (EIS) development. It focuses on Lean Thinking, Agile Methods, and Free/Open Source Software, as means of improving EIS development and evolution, under a more practical than academical view. You may find here a lot of "thinking aloud" material, sometimes without scientific treatment... don't worry, this is a blog!
Every post is marked with at least one of Product or Process labels, meaning that they are related to execution techniques (programming and testing) or management techniques (planning and monitoring), respectively.

Sunday, October 31, 2010

Effort Metrics Sophisma - Part I

This a summarization and translation to English of a presentation prepared by me and an associated researcher in 2008. It was used to support our arguments against detailed one-year plans, a demand from the management of a big and interesting project we've been taking part since 2006.

The goal of this presentation was to show that detailed planning (months ahead) in software development either:
1) Force waterfall cycles.
2) Are inaccurate, leading to a lot of changes in the baselines, which in turn lead to high costs of control function.

Planning in the (hard) Industry

Traditionally, the industry follows waterfall cycles (in spite of Concurrent Engineering), as you can see, for instance, in Gera's lifecycle. In the other engineerings, product metrics are well established, in some cases for centuries. If you say that 10 meters of wall will use 500 bricks, it will use 500 bricks in Brazil, China, or Denmark. In other words, in "traditional" engineering, products are tangible - you can measure them, doesn't matter who made them or where you are. A brick is a brick, and that's it.

(before you say that someone can count lines of code, even this metric is not exact, since I can write the same code using more or less lines, or even write different algorithms with different numbers of lines, and even though, they do the same thing - so please forget that LOC can be exact or tangible)


First Logical Chaining

Detailed planning needs → detailed estimates
Detailed estimates needs → detailed product design (for defining activities in detail)
Then
Detailed planning needs → detailed product's design
So we have
Detailed product's design (in the beginning of the project) → waterfall
Then
Detailed planning → waterfall!

First Conclusions

The arguments could stop here since it would fall into a discussion of whether or not using a waterfall cycle, which is already known to be inefficient in software development. 

Still, it could be suggested that in some cases it is necessary to make detailed product design in the beginning, for example, for Government contracts. In the next post I will show that even in that cases - when Law forces Big Design Up Front (BDUF) - the planning won't be accurate.

No comments:

Post a Comment