cocomo model
Post on 20-Jan-2015
12.427 Views
Preview:
DESCRIPTION
TRANSCRIPT
COCOMO ModelBasic
IntroductionCOCOMO is one of the most widely used
software estimation models in the worldIt was developed by Barry Boehm in 1981COCOMO predicts the effort and schedule
for a software product development based on inputs relating to the size of the software and a number of cost drivers that affect productivity
COCOMO ModelsCOCOMO has three different models that
reflect the complexity: the Basic Model the Intermediate Model and the Detailed Model
The Development Modes: Project CharacteristicsOrganic Mode
• Relatively small, simple software projects• Small teams with good application
experience work to a set of less than rigid requirements
• Similar to the previously developed projects• relatively small and requires little innovation
Semidetached Mode• Intermediate (in size and complexity)
software projects in which teams with mixed experience levels must meet a mix of rigid and less than rigid requirements.
Contd…Embedded Mode
• Software projects that must be developed within a set of tight hardware, software, and operational constraints.
COCOMO:Some AssumptionsPrimary cost driver is the number of
Delivered Source Instructions (DSI) / Delivered Line Of Code developed by the project
COCOMO estimates assume that the project will enjoy good management by both the developer and the customer
Assumes the requirements specification is not substantially changed after the plans and requirements phase
Basic COCOMOBasic COCOMO is good for quick, early,
rough order of magnitude estimates of software costs
It does not account for differences in hardware constraints, personnel quality and experience, use of modern tools and techniques, and other project attributes known to have a significant influence on software costs, which limits its accuracy
Basic COCOMO Model: FormulaE=ab (KLOC or KDSI) b
b
D=cb (E) db
P=E/D where E is the effort applied in person-months, D is the development time in chronological months, KLOC / KDSI is the estimated number of delivered lines of code for the project (expressed in thousands), and P is the number of people required. The coefficients ab, bb, cb and db are given in next slide.
Contd…Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38 Semi-detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32
Basic COCOMO Model: Equation
Mode Effort Schedule
Organic E=2.4*(KDSI)1.05 TDEV=2.5*(E)0.38
Semidetached E=3.0*(KDSI)1.12 TDEV=2.5*(E)0.35
Embedded E=3.6*(KDSI)1.20 TDEV=2.5*(E)0.32
Basic COCOMO Model: LimitationIts accuracy is necessarily limited because
of its lack of factors which have a significant influence on software costs
The Basic COCOMO estimates are within a factor of 1.3 only 29% of the time, and within a factor of 2 only 60% of the time
Basic COCOMO Model: Example We have determined our project fits the
characteristics of Semi-Detached mode We estimate our project will have 32,000 Delivered
Source Instructions. Using the formulas, we can estimate:
Effort = 3.0*(32) 1.12 = 146 man-months Schedule = 2.5*(146) 0.35 = 14 months Productivity = 32,000 DSI / 146
MM = 219 DSI/MM
Average Staffing = 146 MM /14 months = 10 FSP
Function Point AnalysisWhat is Function Point Analysis (FPA)? It is designed to estimate and measure the time, and
thereby the cost, of developing new software applications and maintaining existing software applications.
It is also useful in comparing and highlighting opportunities for productivity improvements in software development.
It was developed by A.J. Albrecht of the IBM Corporation in the early 1980s.
The main other approach used for measuring the size, and therefore the time required, of software project is lines of code (LOC) – which has a number of inherent problems.
Function Point AnalysisHow is Function Point Analysis done?Working from the project design
specifications, the following system functions are measured (counted):
Inputs Outputs Files Inquires Interfaces
Function Point AnalysisThese function-point counts are then
weighed (multiplied) by their degree of complexity:
Simple Average ComplexInputs 2 4 6Outputs 3 5 7Files 5 10 15Inquires 2 4 6Interfaces 4 7 10
Function Point AnalysisA simple example:
inputs3 simple X 2 = 6 4 average X 4 = 161 complex X 6 = 6
outputs6 average X 5 = 302 complex X 7 = 14
files5 complex X 15 = 75
inquiries8 average X 4 = 32
interfaces3 average X 7 = 214 complex X 10 = 40
Unadjusted function points 240
Function Point AnalysisIn addition to these individually weighted function points,
there are factors that affect the project and/or system as a whole. There are a number (~35) of these factors that affect the size of the project effort, and each is ranked from “0”- no influence to “5”- essential.
The following are some examples of these factors: Is high performance critical? Is the internal processing complex? Is the system to be used in multiple sites and/or by multiple
organizations? Is the code designed to be reusable? Is the processing to be distributed? and so forth . . .
Function Point AnalysisContinuing our example . . .
Complex internal processing = 3Code to be reusable = 2High performance = 4Multiple sites = 3Distributed processing = 5
Project adjustment factor = 17
Adjustment calculation:Adjusted FP = Unadjusted FP X [0.65 + (adjustment factor X 0.01)] = 240 X [0.65 + ( 17 X
0.01)] = 240 X [0.82] = 197 Adjusted function points
Function Point AnalysisBut how long will the project take and how
much will it cost?As previously measured, programmers in
our organization average 18 function points per month. Thus . . .
197 FP divided by 18 = 11 man-months
If the average programmer is paid $5,200 per month (including benefits), then the [labor] cost of the project will be . . .
11 man-months X $5,200 = $57,200
Function Point AnalysisBecause function point analysis is independent
of language used, development platform, etc. it can be used to identify the productivity benefits of . . .
One programming language over anotherOne development platform over anotherOne development methodology over anotherOne programming department over anotherBefore-and-after gains in investing in
programmer trainingAnd so forth . . .
Function Point AnalysisBut there are problems and criticisms: Function point counts are affected by project size Difficult to apply to massively distributed systems or
to systems with very complex internal processing Difficult to define logical files from physical files The validity of the weights that Albrecht established –
and the consistency of their application – has been challenged
Different companies will calculate function points slightly different, making intercompany comparisons questionable
top related