Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Spm software effort estimation

798 views

Published on

Spm software effort estimation

Published in: Engineering
  • Be the first to comment

Spm software effort estimation

  1. 1. SOFTWARE PROJECT MANAGEMENT Prof. Kanchana Devi V
  2. 2. Software Effort Estimation  Successful project is that the system is delivered on time and within budget and with the required quality.
  3. 3. Software effort estimation Difficulties in Software estimation  Subjective Nature of estimating  Political Implications  Changing Technology  Lack of homogeneity of project experience
  4. 4. Project Data Note: SLOC - Source Number of Lines of Code WM -Work in Month
  5. 5. Where are estimates done?  Estimates are carried out at various stages of software project.  Strategic Planning  Decide priority to each project.  Feasibility Study  Benefits of potential system  System Specification  Detailed requirement analysis at design stage.  Evaluation of Suppliers Proposals  Tender Management  Project Planning  Detailed estimates of smaller work components during implementation.
  6. 6. Software Effort Estimation Techniques  Algorithmic Models  Expert Judgment  Analogy – Similar Completed Project  Parkinson – Staff Effort available to do project  Price to Win – Sufficiently low to win a contract.  Top-down – Overall estimate is formulated  Bottom-up – Individual components are aggregated
  7. 7. Bottom-up Estimating  Work Breakdown Structure  Assumptions about characteristics of final system  Number and Size of software modules.  Appropriate at detailed stages of project planning.  When a project is completely novel or no historical data available.
  8. 8. Top-down Approach and Parametric Models  Effort = (system size ) * (productivity rate)  System size in the form of KLOC  Productivity rate 40 days per KLOC  Software module to be constructed is 2 KLOC  Effort = 2 * 80 = 160 days Note: KLOC- Thousands of Lines of Code
  9. 9. Expert Judgment  Asking for estimate of task effort from someone who is knowledgeable about either application or development environment.  Experts use the combination of informal analogy approach where similar projects from past are identified and bottom up estimating.
  10. 10. Estimating by Analogy  Called “Case Based Analogy”  Estimator identifies completed projects source cases with similar characteristics to new project (target case)  Effort of the source case used as base estimate for target.  TOOL – ANGEL software tool  Measuring Euclidean Distance between the cases
  11. 11. Euclidean Distance
  12. 12. Problems with Over and Under Estimates  Parkinson’s Law  “Given an easy target staff will work less hard”  Brook’s Law  Effort required to implement a project will go up disproportionately with the number of staff assigned to the project  “ Putting more people on a late job makes it later”
  13. 13. Measure of Work  Measure such as  SLOC ( Source Lines of Code)  KLOC ( Thousand Lines of Code)
  14. 14. Albrecht Function Point Analysis  Top - down method devised by Allan Albrecht(IBM)  Developed the idea of Function Points(FPs)  Basis of function point analysis has five components:  External Input Types  External Output Types  External Inquiry Types – US spelling inquiry  Logical Internal File Types – Data store  External Interface File Types – To & Fro (BACS) BACS-Bank Automation Clearing System
  15. 15. Albrecht Complexity Multipliers
  16. 16. IFPUG File Type Complexity
  17. 17. Example:  A logical Internal File contain:  Purchase order organized into two separate record types:  Main purchase order details  Purchase order number, supplier reference, purchase order date  Purchase order item details  product code, unit price and number ordered.  No. of record types = 2  No. of data types = 6  File type would be rated as low  FP Count=7
  18. 18. Function Points Mark II  Sponsored by CCTA(Central Computer and Telecommunications Agency)  Mark II – Improvement and replacement in Albrecht method  In Albrecht method  Information Processing Size is measured in UFPs(Unadjusted Functional Points)  Then TCA(Technical Complexity Adjustment) is applied
  19. 19. Model of Transaction Data Store ProcessFrom User Return to User Input Output
  20. 20. For each transaction UFPs are calculated  UFPs = Wi * (number of input data element types)+ We * (number of entity types referenced)+ Wo * (number of output data element types)  Wi We Wo are weightings derived by asking the developers the proportions of effort spent.  FP counters use industry averages which are:  Wi = 0.58  We = 1.66  Wo = 0.26
  21. 21. COSMIC Full Function Points  Cosmic deals with decomposing the system architecture into hierarchy of software layers.  Inputs and outputs are aggregated into data groups  Each data group brings together data items that relate to the same object of interest.  Data Groups can be moved in 4 ways:  Entries(E)  Exits(X)  Reads ( R)  Writes(W)
  22. 22. COCOMO II  COCOMO (Constructive Cost Model)-Boehm  Formula :  (effort)=c(size)k  Effort measured in pm(number of person-month)  Size in kdsi (Thousands of delivered source code instructions)  C,K constants  C and K are from System Type C K Organic 2.4 1.05 Semi-detached 3.0 1.12 Embedded 3.6 1.20
  23. 23.  Organic Mode:  Small teams develop software in a highly familiar environment (Small & Flexible)  Embedded Mode:  Operate within very tight constraints and changes to the system very costly  Semi-Detached Mode:  Combined elements of both
  24. 24. COCOMO II - Models  It has three stages  Application Composition  Early Design  Post Architecture
  25. 25. Estimate of person-months  pm=A(size)(sf)*(em1) *(em2) *(em3)*.. *(emn)  Pm  Effort in person-months  A  Constant (In 2000 - 2.94)  Size  kdsi  sf  Exponent Scale Factor  Exponent Scale Factor is derived as  Sf= B+0.01*∑(Exponent driver ratings)  B Constant (0.91)
  26. 26. Exponent Driver Ratings  Precedentedness(PREC)  Development Flexibility(FLEX)  Risk Resolution(RESL)  Team Cohesion(TEAM)  Process Maturity(PMAT) Driver Very low Low Nominal High Very High Extra High PREC 6.20 4.96 3.72 2.48 1.24 0.00 FLEX 5.07 4.05 3.04 2.03 1.01 0.00 RESL 7.07 5.65 4.24 2.83 1.41 0.00 TEAM 5.48 4.38 3.29 2.19 1.10 0.00 PMAT 7.80 6.24 4.68 3.12 1.56 0.00
  27. 27. Capers Jones Estimating Rules of Thumb  Rule1: SLOC Function Point Equivalence  One Function Point = 125 SLOC For C Programs  Rule2: Project duration estimation  Function points raised to the power 0.4 predicts the approximate development time in calendar months.  Rule3: Rate of requirements creep  User requirements creep in at average rate of 2% per month from the design through coding phases.  Rule4: Defect Removal Efficiency  Each software review, inspection, or test step will find and remove 30% of the bugs that are present
  28. 28. ……  Rule5: Project ManPower Estimation  The size of the software divided by 150 predicts the approximate number of the personnel required for developing the application.  Rule6: Software development effort estimation  The approximate number of staff months of effort required to develop a software is given by software development time multiplied with the number of personnel required.  Rule7: Function points divided by 500 predicts the approximate number of personnel required for regular maintenance activity.
  29. 29.  http://www.youtube.com/watch?v=9LSnINgl kQA

×