Read an Excerpt
CHAPTER 1
SOFTWARE ESTIMATION
BACKGROUND
Before IBM launched the personal computer (PC), software as an independent business was not widespread. The computer manufacturer provided the system software and development tool kit to the computer buyers, and the computer buyers developed whatever application software they needed. If someone wanted the programs developed on one computer system to run on another computer system, it was difficult — if not impossible — to achieve. As the industry grew and competition with it, computer manufacturers began to include rudimentary application software packages with their computers, often with source code too. The software in those days was tightly tied to the hardware. Software could not be sold off-the-shelf in stores; software was an appendage to hardware.
Apple Computer, however, was one company that sold software and hardware separately, thus pioneering off-the-shelf software and spawning a hitherto nonexistent commercial off-the-shelf (COTS) software market. In 1982, the IBM PC (and later its clones) took COTS software to a new high, and in doing so, IBM created a huge market for this new area of technology. Soon after, COTS software developers sprouted up and flourished. As software development companies came into existence, the umbilical cord between hardware and software was severed. In time, organizations began to outsource software development work to companies that specialized in this area alone.
While it was unthinkable in the 1970s, before the advent of the IBM PC, that software developers could compel hardware manufacturers to design computers to suit the software, today this is a reality! It may not be an exaggeration to say that for today's computer buyers, the choice of software precedes the choice of hardware. Earlier the question was, "Will the software work with my hardware?" Now the question is, "Will your hardware support the software I selected?"
When a service is subcontracted, mutual acceptance of the service fee by both provider and buyer enters the picture. Traditionally, service providers, like doctors and lawyers, charged by the hour, meaning the fee was determined by how much time was spent on the client assignment. Time and material was the norm providers used to determine their price for software development work outsourced to them, much like doctors charged for their time and for any medicines they provided to the patient.
The time and material method for calculating a service fee put service buyers at a disadvantage: they would not know beforehand how much the service would end up costing them and therefore could not budget for the service. Buyers thus began to ask for fixed bids from service providers, and providers began to offer them. But as close relationships formed between buyers and their preferred providers, buyers began to request that the process for determining the price of the software be more transparent, and providers had to oblige buyers once again.
Thus came about the need for software cost estimation and software effort estimation.
WHAT IS SOFTWARE ESTIMATION?
While it is difficult to define software estimation, the term estimation itself is readily defined as follows:
Estimation is the intelligent anticipation of the quantum of work that needs to be performed and the resources (human resources, monetary resources, equipment resources, and time resources) required to perform the work at a future date, in a defined environment, using specified methods.
The key terms and phrases in this definition are
* Anticipation — Indicates that estimation precedes performance and that it uses a "best-guess" approach.
* At a future date — The work has not yet been performed, but it is planned.
* In a defined environment — The environment where the work is going to be performed is known and its characteristics specified. Any variation that occurs to this environment will have an effect on the estimate.
* Using specified methods — The methods to perform the work are also defined. Any deviation from these methods will also have an effect on the estimate.
An estimate is the result of estimation.
I define software estimation as follows:
Software estimation is that estimation of the software size, software development effort, software development cost, and software development schedule for a specified software project in a specified environment, using defined methods, tools, and techniques.
In this definition, the key terms are
* Estimation — Defined above
* Software size — The amount (quantity) of software that needs to be developed
* Software development effort — The amount of effort, in either person-days or person-hours, necessary for developing the software product of an estimated size
* Software development cost — The expenses necessary for developing software of a defined size, including the expense of human effort
* Software development schedule — The duration, in calendar days or months, that is necessary for developing the defined amount of software
Thus we have the following deliverables from software estimation:
* Components that make up the software, as well as their sizes
* Effort required to develop the software
* Monetary cost of developing the software
* Duration (schedule) required for developing the software
WHY IS SOFTWARE ESTIMATION IMPORTANT?
Software estimation is assuming more importance as a natural consequence of increased outsourcing of software development work. When any work is outsourced, it is necessary to come to an agreement with the supplier on the price to be paid for the assigned work. In an outsourcing scenario, software estimation is needed for the following reasons:
1. To set a budget for the assignment
2. To evaluate proposals received from different vendors for software development
3. To reach an agreement with the selected supplier on the size of the software to be developed and the fee for developing the agreed-upon size of the software
Further, when competition is intense among providers, margins become slim and resources become scarce. Even if a business develops software in-house, estimation is necessary to evaluate competing demands for the software and to apportion the available resources to the highest priority work. For internal software development, software estimation is needed for the following reasons:
1. To allocate a budget
2. To evaluate competing demands for software
3. To monitor the progress of the development work
WHEN IS SOFTWARE ESTIMATION CARRIED OUT?
Software estimation needs to be carried out at least twice within a software development project:
1. At the time of project acquisition for external projects — This is in order to provide a basis for the price decision when preparing a quotation against a request for proposal (RFP). For internal projects, software estimation is carried out at the time of project approval for budgeting purposes.
2. After the software is developed and delivered — This is in order to analyze the variance between the software size as estimated at the project acquisition stage and the actual size delivered. Unfortunately, this practice is absent in many organizations. If an organization sincerely wants to improve software estimation, it is necessary to compare the as-built estimate with the original estimate, analyze the variance between the two, and effect necessary improvements.
Software estimation is carried out at these other stages too:
1. During the project planning stage, after the project is acquired, in order to estimate the required resources
2. When the work is allocated to a person, in order to set a target for completion of the allocated work
3. Optionally, after requirements specification is finalized, in order to validate the delivery commitments and, if necessary, to either effect corrections to the delivery commitments or to look for ways to meet the delivery commitments
4. Optionally, after software design is completed, in order to validate the delivery commitments and, if necessary, to either effect corrections to the delivery commitments or to look for ways to meet the delivery commitments
5. In large projects especially, the balance of work to be done is also periodically estimated to ensure that the project is on track and the delivery commitments can be met and to take corrective actions if necessary to meet the delivery commitments
TRADITIONAL COST ESTIMATION
Cost estimation has traditionally been a finance function, specifically of cost accountants, and effort estimation specifically has been an industrial engineering function. All manufacturing and service industries, including airlines, postal services, banks, and so on, use these specialists for costing and effort estimation. The software industry, however, has never employed either of these specialists and does not to this day. The result is that we have an untenable scenario with "holy cows" that cannot be criticized without being condemned.
To the best of my knowledge, the software development industry is the only industry that tries to estimate size first and arrive at effort after. All other industries that use a project-based methodology go by the traditional cost accounting route of cost estimation, outlined as follows:
1. Determine material cost (direct and indirect).
2. Calculate labor cost (direct and indirect).
3. Add factory overhead to the sum of material and labor costs to arrive at the ex-factory cost.
4. Add marketing and distribution costs to arrive at the organizational cost.
5. Add profit to arrive at a price using the cost-plus pricing method, the steps of which are performed by cost accountants.
6. Make a commercial decision on pricing to win the order, a decision that belongs in the marketing and management domains.
Industries that do not use a project-based methodology use any one of the many costing methods, such as standard costing, opportunity costing, marginal costing, incremental costing, product costing, service costing, and so on.
Go to an honest architect and say, "I want to build a deluxe house of 3,000 square feet. Give me a quote that you will stand by. Mind you, I may ask for changes after seeing the house." Most likely, the architect will ask for a host of specifications before offering you a quote.* Go to an honest caterer and say, "I need food for a hundred guests. The food must be good. Give me a fixed bid."The caterer will no doubt ask for the number of courses, specifications for each course, and many more details before offering you a quote.
All service providers, apart from those in the software industry, cost the RFP item by item to arrive at the cost, add in their profit, weigh the opportunity, and price the RFP. Their estimate follows the traditional approach to costing and pricing:
1. Calculate direct personnel cost.
2. Calculate indirect personnel cost.
3. Calculate direct material cost.
4. Calculate indirect material cost.
5. Sum the above four costs to arrive at the exfacility cost.
6. Add organizational overhead to the ex-facility cost to arrive at cost before profit.
7. Add profit to cost before profit to arrive at a minimum price.
8. Add a negotiation margin, if required, to arrive at the final price.
9. Weigh the opportunity and adjust the price upward or downward, to arrive at the final quote.
It is perhaps only in the software industry where RFPs are issued with just one paragraph of specifications that would ultimately take 10 person-years to deliver! The software industry, by and large, is following the method outlined below to arrive at prices for software. Of course, there can be exceptions.
1. Estimate the software size using any of the popular software-sizing techniques.
2. Convert the software size into effort in person-hours (or person-days) using a conversion factor (popularly known as the productivity figure).
3. Convert the effort into money using a conversion factor (person-hour rate or person-day rate).
4. Offer this result as the price, with a provision for billing other expenses at actual cost incurred.
It has not been possible to achieve an undisputed, universally accepted software size measure; such a standard has remained elusive. True, there are some popular size measures, but each has its own set of limitations. This scenario has given rise to some paradoxes in software estimation.
SUMMARY
The introduction of the IBM PC was the harbinger of software development's growth into the specialist activity it is today. The outsourcing of software development has made requesting and offering fixed bids the norm within this new industry, which in turn has necessitated better methods for accurate software estimation. Software estimation is the estimation of the software size, software development effort, software development cost, and software development schedule for a specified software project in a specified environment, using defined methods, tools, and techniques. Software estimation is carried out to set a price for a bid or to evaluate a bid, set a budget, predict the resources required, and make intelligent delivery commitments, in addition to monitoring the project's progress during its execution. However, the software development industry does not follow traditional cost estimation, nor does it employ specialists for this purpose, and this has given rise to some paradoxes.
CHAPTER 2
PARADOXES OF SOFTWARE ESTIMATION
Wikepedia defines paradox as follows:
A paradox I is a statement or group of statements that leads to a contradiction or a situation which defies intuition. ... Typically, either the statements in question do not really imply the contradiction, the puzzling result is not really a contradiction, or the premises themselves are not all really true or cannot all be true together. ... The recognition of ambiguities, equivocations, and unstated assumptions underlying known paradoxes has led to significant advances in science, philosophy and mathematics.
Since the software development industry is still in its nascent stages, the processes for asking for software development service, offering the service, and pricing are somewhat haphazard. The software development industry falls under the umbrella of the services industry, as opposed to the product industry, meaning it offers a service, not a product. Many parallels can be drawn between the software development industry and other service industries, but the major difference between the software development industry and other service industries is that software is much more highly priced and is difficult to comprehend by nonsoftware professionals. Where there is lack of comprehension and money, academics step in, research is conducted, jargon is developed, concepts are propounded, and a new branch of science or engineering comes into being. Software estimation is one such area.
At first glance, there are many paradoxes in software estimation. This chapter discusses some of those paradoxes.
THE PARADOX OF WHY SOFTWARE ESTIMATION IS PERFORMED
To reiterate from chapter 1, software estimation is carried out for the following reasons:
* To price software development and maintenance contracts (for budgeting and approval in the case of internal projects)
* To determine resource requirements
* To arrive at delivery commitments
When we estimate for resource requirements or delivery commitments, we can always do so for each of the activities involved — coding, code walk-through, testing, and so on — to arrive at the requirements for each. By summing up the individual requirements, we can arrive at the resource requirements for the project. The best way to arrive at delivery commitments is through scheduling the project.
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 we cannot assume is well versed in software development and software estimation. Typically, the scenario looks like this:
* There are multiple bidders.
* The capability of the bidders varies, in some cases vastly.
* There will be, in most cases, techno-commercial negotiations, which are mostly commercial in nature, between client and bidder before the contract is awarded.
* The most common question asked by the buyer is something like, "How did you arrive at this price?"
* The answer is expected to be given in nontechnical terms and is expected to facilitate the buyer's comparison with other bids.
It is this scenario that poses the issue, as the negotiators want one universal norm that can be applied across platforms, across organizations, across technologies — across the board. This is the crux of software estimation concerns.
(Continues…)
Excerpted from "Software Estimation Best Practices, Tools, & Techniques"
by .
Copyright © 2009 Murali Chemuturi.
Excerpted by permission of J. Ross Publishing, Inc..
All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.
