Software estimation techniques


Published on

Published in: Education, Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Software estimation techniques

  1. 1. TanTran – June 2013
  2. 2.  EstimationTechniques Lines of Code estimation Function Point Estimation Three Point Estimation Work break down structure based estimation Use case based estimation Estimation in Agile Projects Q&A2
  3. 3.  Source lines of code (SLOC) is a software metricused to measure the size of a computerprogram by counting the number of lines in thetext of the programs source code. SLOC is typically used to predict the amount ofeffort that will be required to develop aprogram, as well as to estimate programmingproductivity or maintainability once thesoftware is produced.4
  4. 4.  Physical SLOC (LOC): count of lines in thetext of the programs source code includingcomment lines and blank lines (blank lines inexcess of 25% are not counted). Logical SLOC: attempts to measure thenumber of executable "statements“ There are several cost, schedule, and effortestimation models which use SLOC as aninput parameter.5
  5. 5. 6for (i = 0; i < 100; i++) printf("hello"); /* How many lines of code is this? */In this example we have:• 1 | 5 Physical Lines of Code (LOC)• 2 | 2 Logical Line of Code (LLOC) (for statement and printf statement)/* Now how many lines of code is this? */for (i = 0; i < 100; i++){printf("hello");}
  6. 6. 7Operating systems in Microsofts Windows NTVersion of Linux
  7. 7. 8Scope for Automation ofCountingAn Intuitive Metric(trực giác)
  8. 8. 9 Lack of Accountability: coding phase accountsfor only 30% to 35% of the overall effort Lack of Cohesion with Functionality: develop thesame functionality with far less code Difference in Languages Advent of GUITools Problems with Multiple Languages Psychology:A programmer whose productivityis being measured in lines of code will have anincentive to write unnecessarily verbose code
  9. 9.  Function Point Analysis (FPA) is an ISOrecognized method to measure thefunctional size of an information system. Thefunctional size reflects the amount offunctionality that is relevant to andrecognized by the user in the business. It isindependent of the technology used toimplement the system.11
  10. 10.  Following functionalities are counted whilecounting the function points of the system. Data Functionality▪ Internal Logical Files (ILF)▪ External Interface Files (EIF) Transaction Functionality▪ External Inputs (EI)▪ External Outputs (EO)▪ External Queries (EQ)12
  11. 11. 13
  12. 12.  Development Project Function Point Countmeasures the application functions delivered when theproject is complete, and is associated with the initialinstallation or complete rewrite of new software. Application Function Point Countsizes the current functions the application provides tothe end-user. Enhancement Project Function Point Countsizes the functionality added, changed or deleted to anexisting application plus any conversion functionalityneeded14
  13. 13.  Internal Logical Files (ILF) are logically related, useridentifiable data or control information used by theapplication. The primary intent of an ILF is to hold data tobe maintained (modified) and stored within theboundaries of the application being counted. External Interface Files (EIF) are logically related, useridentifiable data or control information used by theapplication, but maintained (modified) and stored byanother application outside the boundaries of the system.The primary intent of an EIF is to hold data to bereferenced by the application being counted. An EIF in theapplication being counted must be an ILF in a differentapplication.15
  14. 14.  External Inputs (EI) are transactions representing an application’s datamaintenance and control processing requirements. It is data that entersthe application from outside its boundaries, is unique in its format or inthe processing logic it initiates. External Outputs (EO) are transactions representing an application’soutput processing requirements. The data is sent outside the boundariesof the application, where the format or the logic creating the output isunique. External Inquiries (EQ) are unique transactions representing anapplication’s inquiry or data retrieval processing requirements. Theprimary intent of an EQ is to present information to a user through aretrieval process.16
  15. 15.  The overall characteristics of a system must be assessed andfactored in to get the total number of Adjusted Function Points.This is done by examining 14 general system characteristics of thesystem, such as the transaction rate, performance, andinstallation ease. Each characteristic is evaluated as to its degreeof influence on the system. The Total Degree of Influence is usedin a formula to give the Adjusted Function Point Count, commonlycalled the Function Point Count.17
  16. 16.  A tool to determine the size of a purchasedapplication package by counting all thefunctions included in the package A tool to help users determine the benefit ofan application package to their organizationby counting functions that specifically matchtheir requirements18
  17. 17.  A tool to measure the units of a softwareproduct to support quality and productivityanalysis A vehicle to estimate cost and resourcesrequired for software development andmaintenance A normalization factor for softwarecomparison19
  18. 18.  Refer to the excel tool…20
  19. 19.  The three-point estimation technique is used inmanagement and information systems applicationsfor the construction of an approximate probabilitydistribution representing the outcome of futureevents, based on very limited information. In three-point estimation, three values are producedinitially for every task based on prior experience orbest-guesses:a = the best-case estimatem = the most likely estimateb = the worst-case estimate.22
  20. 20.  Weighted Average DistributionE = (a + 4m + b) / 6 Standard DeviationSD = (b − a)/6SD value is usually represented with the Greek letter sigma (σ).23
  21. 21.  Task A:a = 3 daysm = 5 daysb = 10 days24E = (3 + (4 x 5) + 10) / 6 = 5.5SD = (10 – 3) / 6 = 1.675.5 days would be our estimation for the given taskWith confidence of 68% we needfrom 3.83 to 7.17 days (5.5 +- 1.67) to finish the task
  22. 22.  The WBS provides the foundation for all projectmanagement work, including, planning, costand effort estimation, resource allocation, andscheduling. Dividing complex projects to simpler andmanageable tasks is the process identified asWork Breakdown Structure (WBS). It defines and groups a projects discrete workelements in a way that helps organize and definethe total work scope of the project.26
  23. 23. 27
  24. 24.  Accurate and readable project organization. Accurate assignment of responsibilities to theproject team. Indicates the project milestones and controlpoints. Helps to estimate the cost, time, and risk. Illustrate the project scope, so the stakeholderscan have a better understanding of the same.28
  25. 25. 29Task List should be S.M.A.R.T
  26. 26.  Use cases are an excellent way of capturing ouruser requirements. It makes sense to base thatestimation on those use cases, given they arethe requirements we are going to implement. The Karner method which was developed on1993 by Gustav Karner. This method involvesthe studying of the system actors and usecases, weighting them according to complexityand then applying technical and environmentfactors.31
  27. 27. 1.Weight the actors2.Weight the use cases3. Calculate the unadjusted use case points (UUCP)4. Determine the technical complexity factors5. Determine the environmental factors6. Calculate the Use Case Points (UCP)32
  28. 28. Analyse the complexity of your actors. The levelof complexity is divided into 3 ActorTypes:33Σ(Number of each Actor type * Appropriate Factor)
  29. 29. 34Analyse the complexity of your actors.The level ofcomplexity is divided into 3 use case types:Σ(Number of each use case type * Appropriate Factor)
  30. 30. 35UUCP = Actor weighting + Use Case Weighting
  31. 31. 36Tfactor = Σ(Rating * Factor)TCF = 0.6 + (0.01 *TFactor)Technical Complexity Factor
  32. 32. 37Efactor = Σ(Rating * Appropriate Factor)Environmental Factor (EF) = 1.4 + (-0.03 * EFactor)
  33. 33. 38UCP = UUCP *TCF * EFWe can use this value to estimate how long the project shouldtake to develop. The Karner process suggests a value of 20man hours per UCP for this estimation, so to estimate projectduration use this formula:Project man-hours = 20 * UCP
  34. 34.  Consensus-based estimationtechnique for estimating First described by JamesGrenningand later popularizedby Mike Cohn in the book AgileEstimating and Planning40
  35. 35.  Estimated in story points foruser stories * It is most commonly used inagile software development41* User stories are user requirements of form "As a <Some Role> I want <SomeNeed> so that <Some Benefit>” For Eg: the deck contains the followingcards: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.
  36. 36. 1. Each person gets a deck of cards.2. The story to be estimated is read to all.3. Attendants ask clarifications for the item.4. Each person selects a card and puts it on the table facing down.5. When everyone is done, cards are exposed.6. If the estimations do not match a short discussion is done.7. Timer is started for discussion and discussion must cease when itruns out -> Goto 4.8. Handle next item.42
  37. 37.  Those who do the work estimate it. Emphasizes relative estimation Reduces anchoring - Everyones opinion isheard. Modeled for open discussion – forcesthinking. It’s quick & fun !43
  38. 38.  ProjectCodeMeter - Source lines of code Wikipedia Three-point estimation technique Function Point Counting Practices Manual Use Case Based Project Estimation Agile Software Estimation - Sunil Kumar
  39. 39. 45