CSCI 630 - Software Engineering
Estimation for Software Projects

- project planning involves estimating how much time, effort, money,
and resources will be required
- project scope is determined
- the problem is decomposed into smaller problems
- software managers use historical project data, personal experience,
and intuition, to determine estimates for each
- final estimates are typically adjusted by taking project complexity
and risk into account.
- resulting work product is called a project management plan
- project planning objectives
- a framework that enables a software manager to estimate resources,
cost, and schedule
- 'best case' and 'worst case' scenarios should be used to bound project
outcomes
- estimates should be updated as the project progresses
- estimation reliability factors depend on
- project complexity
- project size
- degree of structural uncertainty
- degree to which requirements have solidified
- the ease with which functions can be compartmentalized
- the hierarchical nature of the information processed
- availability of historical information (metrics from previous projects!)
- project planning process
- software scope
- customer communication and scope
- determine the customer's overall goals for the proposed system
and any expected benefits
- determine the customer's perceptions concerning the nature if a
good solution to the problem
- evaluate the effectiveness of the customer meeting
- examine feasibility
- technical feasibility is not a good enough reason to build a product
- business feasibility is just as important
- the product must meet the customer's needs and not be available
as an off-the-shelf purchase
- estimation of resources
- human resources
- number of people required, and
- skills needed to complete the development project
- reusable software resources
- off-the-shelf components
- full-experience components
- partial-experience components
- new components
- environment resources
- hardware and software required to be accessible by software team
during the development process
- project estimation
- we start with the scope and utilize decomposition techniques
- functions are refined to allow for better estimates of cost and schedule
- problem-based estimation
- using LOC decomposition focuses on software functions
- using FP decomposition focuses on information domain characteristics
- decomposition is essential!
- the average productivity and labor rates come from historical metrics
- they will vary by organization (and domain)
- example for a CAD project
- process-based estimation
- this approach is frequently used
- decomposition based on tasks required to complete the software process
framework
- again, decomposition is essential, and is done to a fairly detailed
level
- use-case estimation
- promising, but controversial due to lack of standardization of use-cases
- estimate LOC from use-case "size"
- empirical estimation models
- derived from analysis of historical software project data
- with estimated person-months as the dependent variable
- KLOC, FP, or object points as independent variables
- must be calibrated locally!
- COCOMO II is a hierarchy of estimation models that take the
process phase into account
- based on its popular predecessor: Constructive Cost Model (COCOMO)
is a static estimation model
- The Software Equation is another dynamic estimation model
- model derived from analysis of over 4000 software projects
- the productivity parameter reflects process maturity, level
of support, skills and experience, problem complexity
- application to the CAD project
- estimation for object-oriented projects
- estimation for agile development
- abbreviated form of estimation useful for small fast projects and
incremental development
- each user scenario is considered separately
- the scenario is decomposed into a set of engineering tasks
- each task is estimated separately
- may use historical data, empirical model, or experience
- scenario volume can be estimated (LOC, FP, use-case count,
etc.)
- total scenario estimate computed
- sum estimates for each task
- translate volume estimate to effort using historical data
- the effort estimates for all scenarios in the increment are
summed to get an increment estimate
- reconciliation
- use more than one of these methods and compare the resulting
estimates
- causes of estimation reconciliation problems
- project scope is not adequately understood or is misinterpreted
by planner
- productivity data used for problem-based estimation techniques is
inappropriate or obsolete
- investigate large discrepancies
- use common sense!
- make-buy decision
- it may be more cost effective to acquire a piece of software rather
than develop it
- as a rule outsourcing software development requires more skillful
management than does in-house development of the same product
- decision tree analysis provides a systematic way to sort through
the make-buy decision
Notes and figures from:
- Software Engineering: A Practitioner's Approach, 6th Edition, by Roger S
Pressman, R.S. Pressman & Associates, McGraw-Hill, 2005