0
SE-381
Software Engineering
BEIT - V
Lecture # 25
(Program Size and Cost Estimation
Models)
Metrics - Program Size Estimation
– Program size is a measure of the effort and time
required to develop the product
– Two...
Lines of Code
• Cons
– LOC available when product is ready, and
difficult to estimate before the start of SD
– Favors the ...
Function Point
– Function Point metric is in use since mid 70‟s and published by
Albrecht 1983, and cures the shortcomings...
Computation of Function Points
Description
Level of Information Processing Function
Total
Simple Average Complex
External ...
Computation of FP
– In the second step, first Degree of Influence - DI, is
computed considering fourteen possible factors,...
ID Characteristic DI ID Characteristic DI
C1 Data Communications --- C8 On-Line Update ---
C2 Distributed Functions --- C9...
FP Cons and Improvements
• Shortcomings
– Allocation of parameters is subjective
– Symons 1988 pointed out that the propos...
3 Components of System Size
Project Estimation Techniques
– After determining the Project Size; effort to
develop the sw, project duration and cost ar...
Empirical Estimation Techniques
– Based on educated guess of the project
parameters
– Prior experience of similar products...
Delphi Technique
• Non-Consultative, group consensus technique
• Needs access to several experts
• Experts may be at one o...
Heuristic Techniques
– Assumes that relationships among the
different project parameters can be modelled
using suitable ma...
Single Variable Estimation Models
Multivariable estimation models
Analytical Estimation
Techniques
Software Cost Estimation
• COCOMO
COnstructive COst-estimation MOdel
– A software cost and schedule estimating
method that...
COCOMO
Accommodates three categories of software:
Organic
• Application programs – small well understood, smaller
developm...
Effort and Development Time
• Effort is measured in PM – Person Months
– PM is the effort one can put in one month, taking...
Three Levels of Cost Estimation
• According to Boehm the cost estimation
should be done through three stages:
– Basic COCO...
Basic COCOMO (cont.)
– PM is the area under the person-month plot, the
100 PM is NOT the effort put in by 100 people in
on...
Correlations between variables
• Effort vs. Product Size
– For different program sizes if the Effort is
plotted for all th...
Effort vs. Product Size
Development Time vs. Size
Example – Basic COCOMO
Calculations
Find Effort, Productivity (LOC per Person-
Month), Development Time (in months)
and Av...
• Effort = 2.4 * (KLOC)**1.05
= 392 PM (person-months)
• Productivity = Size / Effort
= 128,000 LOC/392 PM
= 327 LOC/PM
• ...
Intermediate COCOMO
– Intermediate COCOMO is an extension to
Basic COCOMO and provides greater
accuracy and level of detai...
Cost Drivers
– It incorporates 15 predictor variables,
called Cost Drivers, to account for software
project cost variation...
• Each of these attributes have different
ratings and some numerical values are
assigned to each, Eg RELY - Required
Sw Re...
– VIRT – Virtual Memory Volatility
– TURN – Computer Turnaround Time
• Personnel Attributes
– ACAP – Analyst Capability
– ...
Reuse – Adaptation Adjustment
– The previously developed software, code, which
is now reused, or being adapted for reuse i...
References
1. Deanna B Legg, Synopsis of COCOMO from Richard H Thayer (Ed) Software
Engineering Project Management, 2nd Ed...
Upcoming SlideShare
Loading in...5
×

Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models

575

Published on

Software Engineering, Lectures

Published in: Education, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
575
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
25
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Se 381 - lec 25 - 32 - 12 may29 - program size and cost estimation models"

  1. 1. SE-381 Software Engineering BEIT - V Lecture # 25 (Program Size and Cost Estimation Models)
  2. 2. Metrics - Program Size Estimation – Program size is a measure of the effort and time required to develop the product – Two prevalent metrics in use are • Lines of Code • Function Points – Lines of Code (LOC) • Historically oldest, evolved and its use propagated by the availability of historical data with the orgs • Simplest and so, popular • Source lines of code counted and comments and headers left out
  3. 3. Lines of Code • Cons – LOC available when product is ready, and difficult to estimate before the start of SD – Favors the (novice) programmers for their poor programming skills as compared to the experienced who write smartly – Biased towards the programming language used – Reflective of only coding phase, which is a fraction of SD process – Complexity not addressed – Penalizes re-usability
  4. 4. Function Point – Function Point metric is in use since mid 70‟s and published by Albrecht 1983, and cures the shortcomings of LOC – FP metric can estimate program size directly from SRS – FP is based on the concept that size of software is directly dependent on the number of different functions and features it supports – Each feature when invoked reads input data and transforms it to output data, Albrecht proposed to include the no of files and no of interfaces as well – FP is computed in two steps, in first step UFP - Unadjusted Function Points are computed then these are corrected UFP = (no of inputs)*w1 + (no of outputs)*w2 + (no of inquiries)*w3 + (no of files)*w4 + (no of interfaces)*w5 Where wi depends on the complexity level of program, according to Rajib Mall (2005), these weights are 4, 5, 4, 10 and 10 respectively. In general these are given in the table below
  5. 5. Computation of Function Points Description Level of Information Processing Function Total Simple Average Complex External Input ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ _____________ External Output ___ x 4 = ___ ___ x 5 = ___ ___ x 7 = ___ _____________ Logical Internal File ___ x 7 = ___ ___ x 10 =___ ___ x 15 = ___ _____________ Ext. Interface File ___ x 5 = ___ ___ x 7 = ___ ___ x 10 = ___ _____________ External Inquiry ___ x 3 = ___ ___ x 4 = ___ ___ x 6 = ___ _____________ Total Unadjusted Fictions Points (UFP) _____________
  6. 6. Computation of FP – In the second step, first Degree of Influence - DI, is computed considering fourteen possible factors, each having influence value varying from 0 - no influence to 5 - maximum influence, so DI can vary from 0 - 70 – The parameters considered for DI computation are shown in the table (on next slide) – Technical Complexity Factor - TCF is computed using TCF = 0.65 + 0.01 * DI – TCF varies from 0.65 to 1.35, and in second step FP is computed by FP = UFP * TCF
  7. 7. ID Characteristic DI ID Characteristic DI C1 Data Communications --- C8 On-Line Update --- C2 Distributed Functions --- C9 Complex Processing --- C3 Performance --- C10 Re-Usability --- C4 Heavily Used Configuration --- C11 Installation Ease --- C5 Transaction Rate --- C12 Operational Ease --- C6 On-Line Data Entry --- C13 Multiple Sites --- C7 End User Efficiency --- C14 Facilitate Change --- Total Degree of Influence TCF = 0.65 + 0.01 x (Total ‘Degree of Influence’) FP = UFP * TCF DI Values Not Present, or not Influence = 0 Insignificant Influence = 1 Moderate Influence = 2 Average Influence = 3 Significant Influence = 4 Strong Influence, throughout = 5
  8. 8. FP Cons and Improvements • Shortcomings – Allocation of parameters is subjective – Symons 1988 pointed out that the proposed FP analysis is based on two „intrinsic‟ factors but did not include the Environmental factors like Project Management Risks, People Skills, Methods and tools used for development etc • His proposed method includes the influence of Environmental factors – Algorithmic complexity not taken into account • Inclusion of Feature Point metric is proposed to cater this shortcomings
  9. 9. 3 Components of System Size
  10. 10. Project Estimation Techniques – After determining the Project Size; effort to develop the sw, project duration and cost are to be estimated – These parameters help in winning the contract, as well as in resource planning, scheduling, monitoring and controlling the project – Estimation Techniques can be categorised as: • Empirical Estimation Techniques • Heuristic Techniques • Analytical Estimation Techniques
  11. 11. Empirical Estimation Techniques – Based on educated guess of the project parameters – Prior experience of similar products helpful – Although based on common sense, different activities involved in estimation have been formalised over the years, – First the estimates are guessed and later, on completion of project these are calibrated i.e. estimates are corrected to reflect the desired – Two such formalisations are • Expert Judgement and • Delphi Technique
  12. 12. Delphi Technique • Non-Consultative, group consensus technique • Needs access to several experts • Experts may be at one or more locations • Operates under the control of a coordinator • Steps in a typical Delphi process – Coordinator explains the task to experts – Specifications are supplied to each expert – Each expert makes estimates anonymously – Coordinator consolidates responses and circulates the summary – Each expert reacts to disagreements giving reason – This process iterates till agreement is reached • Wideband Delphi Approach requires minimal interaction between experts to speed up consensus process
  13. 13. Heuristic Techniques – Assumes that relationships among the different project parameters can be modelled using suitable mathematical expressions – Once basic (independent) parameters are known,the other (dependent) parameters can be determined using basic parameters in mathematical expressions – Heuristic Models can be divided into two classes: • Single variable estimation models • Multivariable estimation models
  14. 14. Single Variable Estimation Models
  15. 15. Multivariable estimation models
  16. 16. Analytical Estimation Techniques
  17. 17. Software Cost Estimation • COCOMO COnstructive COst-estimation MOdel – A software cost and schedule estimating method that was developed by Barry W Boehm and documented in Software Engineering Economics [Boehm 1981]. – The model is an empirically derived, nonproprietary, cost-estimation model, based on a study by Boehm of 63 sw development projects.
  18. 18. COCOMO Accommodates three categories of software: Organic • Application programs – small well understood, smaller development teams needed and team members are experienced in developing similar programs Semidetached • Compilers, linkers etc the utility programs; development teams are mix of experienced and novices, team members may have limited experience on related systems but may be unfamiliar with some aspects of the system to be developed. Embedded • System programs, that interact directly with the hardware and typically involve meeting of timing constraints and concurrent processing, include Operating Systems The developed sw is strongly coupled to complex hw, or stringent regulations on the operational procedures exist.
  19. 19. Effort and Development Time • Effort is measured in PM – Person Months – PM is the effort one can put in one month, taking into account the productivity loss due to holidays, weekly offs, coffee and prayer breaks etc. – One PM is 19 calendar days or 152 working hours – Conforms to the engineers assignments and deadlines of calendar months • Development time is measured in months, i.e. Calendar months
  20. 20. Three Levels of Cost Estimation • According to Boehm the cost estimation should be done through three stages: – Basic COCOMO – Intermediate COCOMO – Complete COCOMO • Basic COCOMO (Single variable model) Effort = a1 * (KLOC)**a2 PM Tdev = b1 * (Effort)**b2 months
  21. 21. Basic COCOMO (cont.) – PM is the area under the person-month plot, the 100 PM is NOT the effort put in by 100 people in one month or effort put in by one person for 100 months – the commonly followed myth – According to Boehm every LOC should be calculated as one LOC, irrespective of actual no of instructions on that line, some authors refer it as DSI delivered Source Instructions a1 a2 b1 b2 Organic 2.4 1.05 2.5 0.38 S-Detached 3.0 1.12 2.5 0.35 Embedded 3.6 1.20 2.5 0.32
  22. 22. Correlations between variables • Effort vs. Product Size – For different program sizes if the Effort is plotted for all the three categories against program size, Effort has super-linear behavior and higher effort for complexity is reflected. That is Embedded Sw needs higher effort than Organic sw for same product size • Development Time vs. Size – Development Time is sub-linear to Size, Because of parallel activities in Sw development process
  23. 23. Effort vs. Product Size
  24. 24. Development Time vs. Size
  25. 25. Example – Basic COCOMO Calculations Find Effort, Productivity (LOC per Person- Month), Development Time (in months) and Average Staffing (full-time staff personnel per month) for a project , which is of Organic type and estimated size of 128,000 Lines of Code.
  26. 26. • Effort = 2.4 * (KLOC)**1.05 = 392 PM (person-months) • Productivity = Size / Effort = 128,000 LOC/392 PM = 327 LOC/PM • Dev Time = 2.5 * (Effort)**0.38 = 2.5 * (392)**0.38 = 24 months • Av. Staffing = Effort / Tdev = 392 PM / 24 months = 16 FSP • FSP = Full-time-equivalent Staff Personnel
  27. 27. Intermediate COCOMO – Intermediate COCOMO is an extension to Basic COCOMO and provides greater accuracy and level of detail which makes it more suitable for cost estimation in more detailed stages of software product definition. – For all three categories it uses the same exponents but the coefficients for Effort computation are 3.2, 3.0 and 2.8 respectively for Organic, Semi-detached and embedded. – Schedule for Intermediate is determined by the same equations as that for Basic model
  28. 28. Cost Drivers – It incorporates 15 predictor variables, called Cost Drivers, to account for software project cost variations, that are not directly correlated to project size. – These Cost Drivers are grouped into four categories • Software Product Attributes • Computer Attributes • Personnel Attributes and • Project Attributes
  29. 29. • Each of these attributes have different ratings and some numerical values are assigned to each, Eg RELY - Required Sw Reliability has ratings as: Very Low, Low, Nominal, High and Very High. • Software Attributes: – RELY – Required Software Reliability – DATA – Database size – CPLX – Software Complexity • Computer Attributes: – TIME – Execution Time Constraint – STOR – Main Storage Constraint
  30. 30. – VIRT – Virtual Memory Volatility – TURN – Computer Turnaround Time • Personnel Attributes – ACAP – Analyst Capability – AEXP – Applications Experience (Team) – PCAP – Programmer Capability – VEXP – Virtual Machine Experience – LEXP – Programming Language Experience • Project Attributes – MODP – Use of Modern Programming Practices – TOOL – Use of Software Tools – SCED – Schedule Constraint
  31. 31. Reuse – Adaptation Adjustment – The previously developed software, code, which is now reused, or being adapted for reuse in the new project. Its effect could be incorporated as EDSI – Equivalent number of Delivered Software Instructions. Calculated as: AAF = Adaptation Adjustment Factor AAF = 0.40(DM) + 0.30(CDM) +0.30 (IM) Where DM = % Design Modified, CDM = % Code Modified and IM = % of Integration required for modified Sw So EDSI = (Adapted DSI) * (AAF / 100)
  32. 32. References 1. Deanna B Legg, Synopsis of COCOMO from Richard H Thayer (Ed) Software Engineering Project Management, 2nd Ed, IEEE Society of Computer Sciences (2000) 2. Barry Boehm et al, Cost Models for future Software Life Cycle Processes: COCOMO 2.0 from Richard H Thayer (Ed) Software Engineering Project Management, 2nd Ed, IEEE Society of Computer Sciences (2000) 3. Rajib Mall (2005); Fundamentals of Software Engineerign, 2nd Ed, Prentice-Hall of India, New Delhi, Ch – 3 Software Project Management, pp:38-84 4. Capers Jones (2007); Estimating software Costs: Bringing Realism to Estimating; 2nd Ed, Tata McGraw-Hill Publishing Company, New Delhi 5. Jalote Pankaj (2005), An Integrated Approach to Software Engineering, Ch - 5 6. A J Albrecht and J E Gaffney; “Software Functions, Source Lines of Code and Development Effort Prediction: A software Science Validation” in IEEE Transactions on Software Engineering, Vol SE-9, no 6, pp 639-47, Nov 1983 7. Charles R Symons, “Function Point Analysis: Difficulties and Improvements” in IEEE Transactions on Software Engineering, Vol 14, no 1, pp:2-11, Jan 1988 8. S A Kelkar (2007); Software Engineering – A Concise Study; Printice Hall of India, New Delhi, Appendix A – Estimation Techniques pp: 641 – 682
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×