-
Notifications
You must be signed in to change notification settings - Fork 1
Estimation
An important skill to learn is how to construct estimates for a software project. Why? First, you need an estimate of the effort in order to estimate the cost and amount of time you'll need to complete the project.
Second, during the project you will want to track your actual progress. Late software projects are a common cause of failure (project is cancelled or loses money). So you want to know as early as possible if your progress is "falling behind" your plan. Without a planned schedule, you don't have any basis for tracking your progress.
Before creating a schedule, you need to estimate effort.
Top-Down:
-
Function Points - a widely used, recognized standard. You count characteristics of the application from an external point of view, and rate them according to complexity.
Then apply a formula that estimates effort based on weighted function points. -
Use Case Points - Use Cases are scored according to complexity. The weighted use case points, a technical complexity factor, and an environmental factor are used in a formula to compute a quantity called Adjusted Use Case Points. To estimate effort from this, you need historical data for how many hours are required per Use Case Point. This method (with example) is given in the week4 slides, and in the book Software Project Management in Practice by Jalote.
Bottoms-Up:
The bottoms up approaches all involve breaking the work down into pieces small enough to estimate individually, then assignment estimates. So, the first step is breaking the work down.
-
Work Breakdown Structure - starting from the products you must produce, subdivide each product into parts, and subdivide each of the parts into its parts until you have pieces small enough to estimate. Then estimate the effort for each part, using a technique like Wide Band Delphi or by estimating
-
Estimate from Conceptual Design - create a conceptual design for the solution, in terms of components, classes, and views. Then estimate the size or complexity of each one. Use historical data to estimate the development time for each item based on its size or complexity.
In the bottoms-up approach you estimate the effort for the products you'll produce, but that doesn't include support effort or project management effort. To get the total effort, organizations often multiple the development effort by a factor to include all the other effort (time) that goes into a software project -- planning, meetings, tracking, control, etc.
The top-down methods use historical project effort data to estimate effort based on the number from the top-down estimate. The historical data includes total effort, not just development effort.