Estimation Techniques

ON LINQ

IOI'94 - Day 1 - Problem 1: The Triangle

IOI'94 - Day 1 - Problem 2: The Castle

IOI'94 - Day 1 - Problem 3: The Primes

IOI'94 - Day 2 - Problem 1: The Clocks

Lines of Code (LOC): This is a a formal method to measure size. Source lines of Code is estimated with Physical and Logical lines . To avoid significant variation in estimates , comparison and previous experience factors need to be factored.and clear guideline must be laid out for the organization.
 

IFPUG FPA: To measure size of business applications. Introduces complexity factor for size defined as

  • function of input
  • output
  • query
  • external input file and
  • internal logical file.
  •  
  • Mark II FPA: Proposed and developed by Mark Simons
  • useful for finging size for functionality in real time systems where transactions have embedded data
  • COSMIC Full Function Point (FFP):
  • Proposed in 1999, compliant to ISO 14143.
  • Applicable for estimating business applications that have data rich processing where complexity is determined by capability to handle large chunks of data and real time applications where functionality is expressed in terms of logics and algorithms.
  • Quick Function Point (QFP): Derived out of FPA and uses expert judgment.
  • Mostly useful for arriving at a ballpark estimate for budgetary and marketing purposes or where go-no go decision is required during project selection process.

  • Object Points: Best suited for estimating customizations. Based on count of raw objects, complexity of each object and weighted points.
  • COCOMO 2.0: Based on COCOMO 81 which was developed by Barry Boehme.
  • Model is based on the motivation of
  • software reuse,
  • application generators,
  • economies or diseconomies of scale and process maturity and helps estimate
  • effort for sizes calculated in terms of SLOC, FPA, Mark IIFP or any other method.
  • Predictive Object Points: Tuned towards estimation of the object oriented software projects. This method is similar to finding area of a rectangle with length and breadth (Number of entities on one side and depth of inheritance other side. Do we have class digram by the time of estimation?).  Calculated based on
  • weighted methods per class,
  • count of top level classes,
  • average number of children, and
  • depth of inheritance.
  • Estimation by Analogy: Cost of project is computed by comparing the project to a similar project in the same domain. The estimate is accurate if similar project data is available.
  • Previous experience will help estimation and also execution due to domain expertise.
    • Estimation Techniques
      • past (similar) project experience
      • Reusability / customisation of components
      • Other conventional estimation techniques
      • Componentization, Task breakdown and effort estimates
      • SIZE (e.g., FP) estimates
        •   “Fuzzy logic” sizing
        •   Function point sizing
        •   Standard component sizing
        •   Change sizing  
      • Tools (e.g., Checkpoint)
    • Examples of Problem-based Estimation
      •     LOC-based estimation  
      •       FP-based estimation
    • Process-Based Estimation
      •       Based on the process that will be used
    •  Estimation Models

      •  E = A + B x (ev)c
         E – effort in person-months
         A, B, C are empirically derived constants
         ev is the estimation variable (either LOC or FP)
         Examples of LOC-oriented
         E = 5.2 x (KLOC)0.91  - Walston-Flix model
         E = 5.5 + 0.73 x (KLOC)1.16 – Bailey-Basili model
         E = 2.4 x (KLOC)1.05 – Boehm simple model
    Multipliers reflect the capability of the developers, the non-functional requirements, the familiarity with the development platform, etc.
    RCPX - product reliability and complexity
    RUSE - the reuse required
    PDIF - platform difficulty
    PREX - personnel experience
    PERS - personnel capability
    SCED - required schedule
    FCIL - the team support facilities
    PM reflects the amount of automatically generated codev

    Some cost Factors

    • TEAM
    • Personnel/ team capability
    • Personel Experience
    • Process capability
    • Multisite coordination requirements
    • Tools support on coordination

     

    • Installation complexity
    • Migration complexity
    • Requirement understanding
    • Architecture understanding

    Complexity

    • Technology Risk
    • Documentation
    • Recursive levels of design
    • Conceptualization cost

     

    • Development cost
    • OperationalTesting cost
    • Transition cost
    • Labour rates
    • Requirement volatilityv