• Embed Doc
  • Copy Link
  • Readcast
  • Collections
  • 1
    CommentGo Back
Download
 
Paradoxes of Software Estimation
Murali ChemuturiChemuturi ConsultantsWikepedia defines Paradox as “A
paradox
(in Greek - "aside belief") is an apparentlytrue statement or group of statements that leads to a contradiction or a situation whichdefies intuition. Typically, either the statements in question do not really imply thecontradiction, the puzzling result is not really a contradiction, or the premises themselvesare not all really true or cannot all be true together. The recognition of ambiguities,equivocations, and unstated assumptions underlying known paradoxes has led tosignificant advances in science, philosophy and mathematics.”The software development has spawned into an independent industry with organizationsoffering exclusively software development service. As it is, perhaps, in the nascentstages, the process of asking for service, offering a service and pricing are somewhathaphazard. Software development falls into the category of 
Services
industry as opposedto
Product
industry – that is a service is offered and not a product. Many parallels can bedrawn with similar service industries. The major difference between
software service
industry and other service industries is that software is much more highly priced andcomplex.. Where there is complexity and money, academics step in – research isconducted – jargon is developed – concepts are proposed and a new branch of science orengineering comes to life.Initially there are many paradoxes. This paper discusses some of those paradoxes – whynot – all? Reason is simple – there is no comprehensive document on the total paradoxesand the work is still going on.
Paradox of “Why” of Estimation?
Why do we carry out software estimation?1. For pricing of software development / maintenance contracts2. Resource estimation3. Delivery CommitmentsWhen we estimate for resource estimation or delivery commitments, we can alwaysestimate for each of the activities – say – for coding, for code-walk-thru, for testing andso on to arrive at the resource requirements for each of these activities. By summing upthe individual requirements, we can arrive at the resource requirements for the project.The software estimation becomes contentious, when we estimate for software pricing.We need to arrive at an estimate that is understood by the client’s purchaser, who is to beassumed
not
to be a software developer and is expected to be unfamiliar with softwareestimation. Typically, the scenario is like this –1. There are multiple bidders
 
2. The capability levels of the bidders vary – in some cases – they vary vastly3. There will be techno-commercial negotiations – which are mostly commercial innature4. The technical question is something like “How did you arrive at this price?”5. The expected answer is to be in non-technical terms and is expected to befacilitate comparison with other bidsThis is the scenario – that poses the issue, as the negotiators want one universal norm thatcan be applied across platforms, across organizations, across technologies and acrossboard.This is the crux of software estimation concerns.
Paradox of software size
There is ample literature on sizing software. They try to size software the way distance issized (measured) or weight is measured. They want to have a unit of measure that isacceptable to all. Result is, we have many measures of software size – Lines of Code,Function Points, Use Case Points, Object Points, Feature Points, Internet Points, TestPoints, to my knowledge and there may be more. True, there are multiple measures fordistance – mile and Kilometer – for weight – Pound and Kilogram – but you can convertPounds into Kilograms and Miles into Kilometers! There is no formula that says one UseCase Point is equal to 1.2 Function Points or something like that!Now every one agrees that some things are not amenable to measurement – such asbeauty and love. Each person is beautiful in one’s own way and every one loves the otherin one’s own way. We don’t attempt to measure them in beauty points or love points – dowe?There are many examples in the industry too. We do not measure a car – do we have carpoints to say that BMW car has 25 car points and Toyota car has 15 car points –therefore, BMW is superior by 10 car points? How does one compare different cars? Wedon’t have a measure for cars so that comparison can be made.We don’t attempt to measure software products too. What is the size of SQL Server orOracle? Both are multi-user RDBMS’ – while buying, do we ask their sizes to get a faircomparison?We do not also have a fair measure for computer hardware too. How do we compare aAS/400 with RS/6000 – are there any computer-points to measure their sizes?Is there any measure for buildings? A ten thousand square foot building – one a gym,another a theatre, another a home – would they all have the same measure? Do we have asize measure to compare them?
 
Lastly, let us take catering service. The same menu to be served at the same place getsvastly different pricing – it depends on the caterer and other specifications. Can we ask them the size of their meals – say in meal-points?The fact of the matter is that every thing is not amenable to measurement. To be able tomeasure, the flowing criteria should be satisfied –1. It (that is being measured) must be homogenous2. It needs to be physical and tangible3. It should be monolithic – not an assembly of multiple parts (physical or meta-physical)4. It should not have any
qualitative
features5. The measure also must be physical and tangible6. When there are multiple units of measure, it must be possible to have conversionfactor to convert one measurement into other units of measureThe how are the others mentioned above measured – they are sized up using the list of features, qualitatively described.
Paradox of Software Productivity
Productivity is roughly defined as “X units of Output per one Unit of Time.The definition of standard time (productivity) goes thus –
“Standard time is the unit of time taken to accomplish a unit of defined work carried  out by a qualified worker after adjustment using a given method in specified working conditions at a pace that can be maintained day after day without any physical harmful effects” 
This definition is specified by the AIIE (American Institution of Industrial Engineers).Thus, in manufacturing industry, productivity cannot be stated in a stand-alone mode – ithas to be accompanied by specification of –1. Defined Unit of Work 2. Work environment3. Working methods4. Tools & technologies used5. Qualified worker, after acclimatizationIt is needless to say that productivity varies from organization to organization even inwell-established measures of productivity.
of 00

Leave a Comment

You must be to leave a comment.
Submit
Characters: ...
ramyasomayajula

very nice article good questions nice descripton

reply01 / 24 / 2009
You must be to leave a comment.
Submit
Characters: ...