Cost and Effort Estimation 2

Parkinson's Law

n "Work expands so as to fill the time available for its completion" Cyril Northcote Parkinson (1909-1993), British historian n Cost of project is determined by all resources available rather than by objective assessment n Advantages: no overspending possible n Disadvantages: system is usually unfinished at scheduled completion date n Valid in other realms: n The amount of stuff one has expands to fill available cupboard space" n IT: "Data expands to fill the space available for storage" n "Network traffic expands to fill the available bandwidth"

Top-down & Bottom-up Estimation

n Any of these approaches may be used top- down or bottom-up. n Top-down n Start at the system level and assess the overall system functionality and how this is delivered through sub-systems. n Bottom-up n Start at the component level and estimate the effort required for each component. Add these efforts to reach a final estimate.

COCOMO 2 Models

n COCOMO 2 incorporates a range of sub-models that produce increasingly detailed software estimates n The sub-models in COCOMO 2 are: n Application composition model. Used when software is composed from existing parts. n Early design model. Used when requirements are available but design has not yet started. n Reuse model. Used to compute the effort of integrating reusable components. n Post-architecture model. Used once the system architecture has been designed and more information about the system is available. n Use set of 17 multipliers to reflect personnel capability, product and project characteristics

COCOMO 2

n COCOMO 81 was developed with the assumption that a waterfall process would be used and that all software would be developed from scratch n Since its formulation, there have been many changes in software engineering practice and COCOMO 2 is designed to accommodate different approaches to software development n COCOMO 2 supports a spiral model of development

COCOMO Model

n COCOMO: COnstructive COst MOdel (Barry Boehm, USC; 1981) n An empirical model based on project experience. n Well-documented, 'independent' model which is not tied to a specific software vendor. n Long history from initial version published in 1981 (COCOMO-81) through various instantiations to COCOMO 2. n COCOMO 2 takes into account different approaches to software development, reuse, etc. Published in 2000

Estimation by Analogy

n Comparison to similar project in same application domain n Advantages: accurate if data available n Disadvantages: impossible if no comparable project has been tackled or no data available

Algorithmic Cost Modeling -1

n Cost is estimated as a mathematical function of product, project and process attributes (e.g. project size, # of software engineers ) whose values are estimated by project managers: n Effort=A ×SizeB ×M" n A is constant, an organization-dependent, and the type of software n Size : LOC or FP n B reflects the disproportionate effort for large projects, between (1, 1.5) n M is a multiplier reflecting product, process and people attributes (e.g.. Experience of the development team)

Pricing to Win

n Cost is estimated to be whatever customer has to spend n The estimated effort depends on the customer's budget, not software functionality n Advantages: likely to win the contract n Disadvantages: costs do not accurately reflect the work required; customer satisfaction low

Algorithmic Cost Modeling -2

n Derived from historical costing data n The most commonly used product attribute for cost estimation is code size (LOC) n Most models are similar but they use different values for A, B and M

Estimation Methods

n Each method has strengths and weaknesses. n Estimation should be based on several methods n If these do not return approximately the same result, then you have insufficient information available to make an estimate n Some action should be taken to find out more in order to make more accurate estimates n Pricing to win is sometimes the only applicable method

Summary

n Estimation is a key management activity n Many factors affect productivity; LOC still used due to simplicity n Estimation should be based on several methods, not single measures n Pricing to win is often the only viable approach to winning a contract n COCOMO is a well-known algorithmic method used by mature organizations

COCOMO 81 three stages?

n Exists in three stages: n Basic: estimate based on product attributes n Intermediate: modifies basic estimate using project and process attributes n Advanced: estimates project phases and parts separate Assume waterfall model is used in software development, and using standard imperative program languages (C, FORTRAN)

Estimation Techniques

n Expert judgment n Estimation by analogy n Parkinson's Law n Pricing to win n Top-down estimation n Bottom-up estimation n Algorithmic cost modeling

Expert Judgment

n Experts in both software development and the application domain use their experience to predict software costs n Each estimate are compared and discussed, until an agreed estimate is reached n Advantages: relatively inexpensive; can be accurate if experts have direct experience with similar systems n Disadvantages: need experts

Quality and Productivity -1

n Measures based on volume/unit time are flawed —don't take quality into account n Generally: n productivityé=> qualityê n productivity * quality = constant n Unclear how productivity and quality measures are related n If requirements are constantly changing then an approach based on counting lines of code is not meaningful as the program itself is not static n The measures also did not take into account the possibility of reusing the software produced, using code generators

Changing Technologies

n Most estimation techniques rely on experience- based judgments by project managers n Changing technologies may mean that previous estimating experience does not carry over to new systems n Distributed object systems rather than mainframe systems n Use of web services; n Use of ERP or database-centered systems n Use of off-the-shelf software n Development for and with reuse n Development using scripting languages n The use of CASE tools and program generators

Outline

n Quality and Productivity n Estimation Techniques n Algorithmic Cost Modeling (COCOMO)

Estimation Accuracy

n The size of a software system can only be known accurately when it is finished n Several factors influence the final size n Use of COTS and components n Programming language n Distribution of system n As the development process progresses then the size estimate becomes more accurate n B and M are subjective, depends on persons background, experience and type of system

Estimation Techniques

n There is no simple way to make an accurate estimate of the effort required to develop a software system n Initial estimates are based on inadequate information in a user requirements definition n The software may run on unfamiliar computers or use new technology n The people in the project may be unknown n Project cost estimates may be self-fulfilling n The estimate defines the budget and the product is adjusted to meet the budget

Price to Win

n This approach may seem unethical and un- businesslike n However, when detailed information is lacking it may be the only appropriate strategy n The project cost is agreed on the basis of an outline proposal and the development is constrained by that cost n A detailed specification may be negotiated or an evolutionary approach used for system development n Buyer and seller agree on what is acceptable functionality n The fixed factor in many projects is not the requirements but the cost - the requirements may be changed so that the cost is not exceeded

Bottom-up Estimation

n Usable when the architecture of the system is known and components identified n Advantages: accurate if the system has been designed in detail n Disadvantages: may underestimate costs of system-level activities like integration

Top-down Estimation

n Usable without knowledge of the system architecture and the components that might be part of the system. n Start at system level and work out how the system functionality is provided n Advantages: takes into account costs such as integration, configuration management, and documentation n Disadvantages: can underestimate the cost of solving difficult low-level technical problems

Quality and Productivity -2

n What really need to estimate is the cost of deriving a particular system with given certain functionality, quality, performance etc n This is only indirectly related to tangible measures (e.g. LOC) FManager should use productivity measures as partial information about programmer productivity, also take quality into consideration (more reliable code - easy to understand and cheaper to maintain)