Estimating Software-Intensive Systems

Numerous conjectures exist about the waste of software project estimates. Most are based on personal opinions divorced from the business processes of writing software for money.

From the Introduction of this book

Reasonable estimates are crucial to project (and product) success. Estimates provide information to make decisions and define feasible performance objectives and plans. Measurements provide data to gauge adherence to performance specifications and plans, make decisions, revise designs and plans, and improve future estimates and processes.

Engineers use estimates and measurements to evaluate the feasibility and affordability of proposed products, choose among alternative designs, assess risk, and support business decisions. Engineers and planners estimate the resources needed to develop, maintain, enhance, and deploy a product. Project planners use the estimated staffing level to identify required facilities.

Planners and managers use resource estimates to compute project costs and schedules and prepare budgets and plans. Estimates of product, project, and process characteristics provide "baselines" to assess progress in project execution. Managers compare estimates and actual values to identify deviations from the project plan and understand the causes of the variation.

Engineers compare estimates of the technical baseline to observed product performance to decide if the product meets its functional and operational requirements. Process capability baselines establish norms for process performance. Managers use these norms to control the process and detect compliance problems, and process engineers use capability baselines to improve the production process.

Wrong estimates affect everyone associated with the project - the engineers and managers, the customer who buys the product, and sometimes even the company's stockholders responsible for delivering the software. Only complete or accurate resource estimates for a project mean that the project may have enough time and money to complete the required work.

If you work in a domain where none of these conditions are in place, then by all means don't estimate.

If you recognize some or all of these conditions, here's a summary of the reasons to estimate and measure from the book.

Product Size, Performance, and Quality

• Evaluate the feasibility of requirements
• Analyze alternative product designs
• Determine the required capacity and performance of hardware.
• Evaluate product performance - accuracy, speed, reliability, availability, and all the?...ilities.?(The ACA website should have answered this question).
• Identify and assess technical risks. Provide technical baselines for tracking and controlling—this is called Closed-Loop Control. No steering targets with measures of actual performance assessed against desired performance is called Open-Loop Control.

Project Effort, Cost, and Schedule—yes, Virginia, real business managers need to know when they'll be done, how much it will cost, and what they'll deliver on that day for that cost.?And yes, Virginia, there is no Santa Claus.

• Determine project feasibility in terms of cost and time
• Identify and assess project risks -?Risk Management is How Adults Manage Projects? - Tim Lister
• Negotiate achievable commitments
• Prepare realistic plans and budgets
• Evaluate business value - the cost versus benefit is how a business stays in business.
• Provide cost and schedule baseline for tracking and controlling

Process Capability and Performance

• Predict resource consumption and efficiency
• Establish norms of expected performance -?back to the steering targets
• Identify opportunities for improvement.

A Compendium of Estimating Resources