You are on page 1of 30

‡ Failure to properly estimate what you are building is a recipe for a complete and unmitigated disaster of Biblical proportions

.

‡ Cost and Schedule estimation
± The first Software Engineering task is the estimation of the cost and schedule for the development of a software system.
‡ The development of software is an economic activity first and foremost.

± Economic activities have to result in a net gain to the sponsoring entity. ± The basis of capitalism is to realize a return on a product sale that exceeds the cost of the product. ± To realize a return the developed product has to meet a market expectation that is moving at high velocity.
‡ Late to market is effectively to be out of the market.

‡ Software Cost/Schedule estimation
± To render a valid business decision the individuals planning to develop software first have to determine how much the proposed system will cost and how long it will take to develop it.
‡ This is critical to the basic business equation for how else can market criticality and selling price be determined?

± This implies that there must be some way to translate a set of requirements into man-months of effort (cost and time). ± Most project managers use µguestimation¶ techniques to determine the answer to the how long/how much question.
‡ For smaller efforts this approach, when provided by an experienced, domain expert can be quit effective.

± The worst way to cost/schedule software development is to use the ³we have to have it by this time for this much money therefore make it happen´ approach.

‡ Cost Estimation
± Unfortunately our understanding of software is so poor that we are not even sure how to size it (or measure it). ± LOC? (Lines of Code) ± FP? (Function Points) ± The problem with the LOC approach is that certain languages and coding styles are more wordy than others.
‡ One line of µc¶ code can do the same work as 100 lines of Assembly Language ( fprintf )

± In addition if effort is measured by LOC then how do you measure an µimprovement¶ to the design that reduces the LOC?
‡ Is a NOP the same as JMPR?

‡ Guestimation ± A very useful technique when the sales staff first bring a client to the corporation. ± The Software Engineer must actively participate in the initial sales consultation meetings. ± From the joint work of the Project Manager and Software Engineer will come the decision of whether or not the particular project is economically viable. ± From these first meetings the project will receive a µrough¶ sizing. ± These guestimates are essential and often quite accurate (within 15% of final size).

‡ Software Engineering ± "You cannot manage what you cannot measure." In order for any process to be manageable, there must exist sizing metrics that can be put to good use. ± Development effort is exponentially proportional to size: Software size is an important metric when it comes to process measurement. This size metric is often related and compared to other metrics in the process. Many calculated metrics like productivity and defect rates are functions that have software size as one of their domains. The metrics data from previous projects is stored in a database and can be applied in estimating future projects. ± Better project tracking: A quality size estimation process provides the ability us to track the progress of the project through techniques like the earned value analysis.

‡ Software Cost/Schedule

± Better planning: However, the most important reason to estimate software size is to provide the ability to make better project plans. A proper size estimate leads to a quality development plan. With a proper estimate of a project size, there exists the base for determining the effort required and the calculation of a price quotation. Once the required effort is determined, a schedule can then be produced accordingly. ± Probably the most effective direct measurement for software size is to do a count of the number of lines of source code that have been implemented. Lines of Code, or SLOC, is the metric that has been adopted by the Software Engineering Institute and in turn, it has shown in the Personal Software Process, or PSP.

‡ Software Cost/Schedule Analysis
± Historical databases from many programmers and firms show that the time and effort involved in implementing a software program is exponentially related to the software size in lines of code. This linear relationship is strongest for lower level programming languages like C, but is still extant for the highest level fourth generation languages. ± Lines of code can also be easily applied to company statistics such as productivity (LOC per programmer hour), defect rates (number per 1000 LOC). LOC can also be used in determining the effectiveness of product reviews and inspections. Choose ONE below:
‡ Only new and modified LOC should counted towards productivity. ‡ Allowing all code lines to be countable brings in a psychological factor to maximize productivity through reuse.

‡ Software Cost/Schedule Estimation

± ± ± ± ± ± ± ±

± ± ± ±

Advantages of using LOC as a metric. LOC is a direct measure of software size. LOC is easily counted. Counting can be easily automated. Simplicity of categorizing code into reusable, new, changed, and reused. Disadvantages of LOC as a metric. A lack of agreement on standards in the software industry. LOC counts vary with language. ‡ 100 lines 4 G L may equal 1500 lines C and 15000 lines of assembler. It is very difficult to visualize Lines of code early in the development. The same automatic counter may not work for all programming styles in the same language. A line of code is a strange term to most clients. Some stats using LOC can be misleading.

± Are SLOC a useful way to determine software cost and

development schedule?

± Source lines of code (SLOC) is perhaps the oldest of software metrics, and still a benchmark for evaluating new ones. ± Despite the extensive experience with the SLOC metric, there are still a number of misconceptions about it. ± (1) that the format of SLOC is relevant to how to properly count it (a simple experiment shows that, in fact, it does not matter), ± (2) that SLOC is most useful as a predictor of software quality (in fact, it is most useful as a covariate of other predictors), and ± (3) that there is an important inverse relationship between defect density and code size (in fact, this is an arithmetic artifact of plotting bugs-per-SLOC against SLOC).

‡ Function Points as a sizing metric
± In the late seventies, IBM felt the need to develop a language independent approach to estimating software development effort. It tasked one of its employees, Allan Albrecht, with developing this approach. The result was the function point technique. ± Function points are a measure of the size of computer applications and the projects that build them. The size is measured from a functional, or user, point of view. ± It is independent of the computer language, development methodology, technology or capability of the project team used to develop the application. ± The fact that Albrecht originally used it to predict effort is simply a consequence of the fact that size is usually the primary driver of development effort. The function points measured size.

‡ How does the use of function points compare to the use of SLOC? ‡ The number of lines of code is the traditional way of gauging application size. Some people claim it is still relevant because it measures what software developers actually do, that is, write lines of code. They will use lines of code either instead of or in addition to function points. ‡ Other practitioners say lines of code are irrelevant. Capers Jones has declared "the use of lines of code metrics for productivity and quality studies to be regarded as professional malpractice starting in 1995."

‡ When the number of lines of code is your primary measure of productivity, you often get it by having developers use less powerful languages and ignore opportunities for reuse. When the number of function points is your primary measure of productivity, you tend to get increased and often unnecessary additions of functionality.

‡
‡ No matter which metric you use people will work to excel at that metric
± Russian Nail factories ± Metric Factories.

‡ In reality the best solution is to use the strong points of both approaches.

‡ Capers Jones has produced tables that indicate how many statements of code it takes to implement a function point. Obviously, this figure varies by computer language ‡ For example, if you had an application consisting of 91,000 line COBOL program, these tables would lead you to believe that you had a 1,000 function point system. This is the backfiring technique. Many people use it to get a rough size measure for a portfolio of applications. .

‡ This approach is often the basis for guestimations

‡ Now that a ground on software size metrics has been covered, it is time to look at the actual size estimation process. ‡ The size estimation is the first and most important part of the project planning phase. ‡ This size estimate will dictate the rest of the project plans, including the cost quote, time, and scheduling of human and machine resources to complete the task. ‡ The question that is most important is: How do I perform a size estimation when I do not even have a requirements document?

‡ COCOMO

Constructive Cost Model.

± COCOMO II is a model that allows one to estimate the cost, effort, and schedule when planning a new software development activity. ± It consists of three submodels, each one offering increased fidelity the further along one is in the project planning and design process. ± Listed in increasing fidelity, these submodels are:

‡ Applications Composition, ‡ Early Design ‡ Post-Engineerure models.

±

‡ Rule of the World:
± The worst estimates are made at precisely the time when we need the best. ± The COCOMO model is based on a set of equations that reflect the non-linear communication overhead associated with software development. ± LARGE PROJECTS

EFFORT = a * SIZEb
± SMALL PROJECTS

EFFORT = a * SIZE + b

‡ COCOMO
± The COCOMO cost estimation model is used by thousands of software project managers, and is based on a study of hundreds of software projects. Unlike other cost estimation models, COCOMO is an open model, so all of the details are published, including:
‡ The underlying cost estimation equations ‡ Every assumption made in the model (e.g. "the project will enjoy good management") ‡ Every definition (e.g. the precise definition of the Product Design phase of a project) ‡ The costs included in an estimate are explicitly stated (e.g. project managers are included, secretaries aren't)

‡ COCOMO
± Because COCOMO is well defined, and because it doesn't rely upon proprietary estimation algorithms COCOMO offers these advantages to its users:
‡ COCOMO estimates are more objective and repeatable than estimates made by methods relying on proprietary models ‡ COCOMO can be calibrated to reflect your software development environment, and to produce more accurate estimates

± Typically, you'll start with only a rough description of the software system that you'll be developing, and you'll use COCOMO to give you early estimates about the proper schedule and staffing levels. ± As you refine your knowledge of the problem, and as you design more of the system, you can use COCOMO to produce more and more refined estimates.

Introduction to the COCOMO Model
‡ The most fundamental calculation in the COCOMO model is the use of the Effort Equation to estimate the number of PersonMonths required to develop a project. Most of the other COCOMO results, including the estimates for Requirements and Maintenance, are derived from this quantity.

± Source Lines of Code
‡ The COCOMO calculations are based on your estimates of a project's size in Source Lines of Code (SLOC). SLOC is defined such that: ‡ Only Source lines that are DELIVERED as part of the product are included -- test drivers and other support software is excluded ‡ SOURCE lines are created by the project staff -- code created by applications generators is excluded ‡ One SLOC is one logical line of code ‡ Declarations are counted as SLOC ‡ Comments are not counted as SLOC

COCOMO
± In the COCOMO II model, some of the most important factors contributing to a project's duration and cost are the Scale Drivers. The 5 Scale Drivers are set to describe the project; these Scale Drivers determine the exponent used in the Effort Equation. ± The 5 Scale Drivers are:
‡ ‡ ‡ ‡ ‡ Precedentedness Development Flexibility Engineerure / Risk Resolution Team Cohesion Process Maturity

‡ COCOMO
± Cost Drivers ± COCOMO II has 17 cost drivers. ± Assess the project, development environment, and team to set each cost driver. ± The cost drivers are multiplicative factors that determine the effort required to complete a software project. ± For example, if the project will develop software that controls an airplane's flight, the Required Software Reliability (RELY) cost driver would be set to Very High. That rating corresponds to an effort multiplier of 1.26, meaning that the project will require 26% more effort than a typical software project.

‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡

Analyst Capability Applications Experience Programmer Capability Programming Language Experience Virtual Machine Experience Personnel Capability Personnel Experience Personnel Continuity Platform Experience Language and Tool Experience Product Factors Required Software Reliability Database Size Software Product Complexity Required Reusability Documentation Match to Life-Cycle Needs Product Reliability and Complexity

‡Platform Factors ‡Execution Time Constraint ‡Main Storage Constraint ‡Computer Turnaround Time ‡Virtual Machine Volatility ‡Virtual Machine Volatility: Host ‡Virtual Machine Volatility: Target ‡Platform Volatility ‡Platform Difficulty ‡Platform

‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡

Project Factors Use of Software Tools Modern Programming Practices Required Development Schedule Classified Security Application Multisite Development Facilities Requirements Volatility

‡ COCOMO II Effort Equation
± The COCOMO II model makes its estimates of required effort (measured in Person-Months ± PM) based primarily on the estimate of the software project's size (as measured in thousands of SLOC, KSLOC)): Effort = 2.94 * EAF * (KSLOC)E Where EAF Is the Effort Adjustment Factor derived from the Cost Drivers E Is an exponent derived from the five Scale Drivers As an example, a project with all Nominal Cost Drivers and Scale Drivers would have an EAF of 1.00 and exponent, E, of 1.0997. Assuming that the project is projected to consist of 8,000 source lines of code, COCOMO II estimates that 28.9 Person-Months of effort is required to complete it: Effort = 2.94 * (1.0) * (8)1.0997 = 28.9 Person-Months

‡ Effort Adjustment Factor
‡ The Effort Adjustment Factor in the effort equation is simply the product of the effort multipliers corresponding to each of the cost drivers for a project. For example, if the project is rated Very High for Complexity (effort multiplier of 1.34), and Low for Language & Tools Experience (effort multiplier of 1.09), and all of the other cost drivers are rated to be Nominal (effort multiplier of 1.00), the EAF is the product of 1.34 and 1.09. Effort Adjustment Factor = EAF = 1.34 * 1.09 = 1.46 Effort = 2.94 * (1.46) * (8)1.0997 = 42.3 Person-Months

‡ The COCOMO II schedule equation predicts the number of months required to complete a software project. The duration of a project is based on the effort predicted by the effort equation: Duration = 3.67 * (Effort)SE Effort Is the effort from the COCOMO II effort equation SE Is the schedule equation exponent derived from the five Scale Drivers Substituting the exponent of 0.3179 that is calculated from the scale drivers, yields an estimate of just over a year, and an average staffing of between 3 and 4 people: Duration = 3.67 * (42.3)0.3179 = 12.1 months Average staffing = (42.3 Person-Months) / (12.1 Months) = 3.5 people

± The SCED Cost Driver ± The COCOMO cost driver for Required Development Schedule (SCED) is unique, and requires a special explanation. The SCED cost driver is used to account for the observation that a project developed on an accelerated schedule will require more effort than a project developed on its optimum schedule. ± A SCED rating of Very Low corresponds to an Effort Multiplier of 1.43 (in the COCOMO II.2000 model) and means that you intend to finish your project in 75% of the optimum schedule (as determined by a previous COCOMO estimate).

‡ SCED COST DRIVER
± Continuing the example used earlier, but assuming that SCED has a rating of Very Low, COCOMO produces these estimates: Duration = 75% * 12.1 Months = 9.1 Months Effort Adjustment Factor = EAF = 1.34 * 1.09 * 1.43 = 2.09 Effort = 2.94 * (2.09) * (8)1.0997 = 60.4 Person-Months Average staffing = (60.4 Person-Months) / (9.1 Months) = 6.7 people

‡ Assignment
± Develop a program which will scan another program and develop a µcomplexity¶ evaluation. ± Obvious candidates for increasing complexity are the number of calls, number of calls to other objects, depth of nesting of program sequence control instructions. ± Use your imagination. ± Complexity is NOT a linear relationship ± it is exponential O Nn