Project Planning and Estimation

							Project Planning and Estimation

                                 Chapters 23, 24
     Software Engineering: A Practitioner’s Approach
                                      Roger S. Pressman
           Project Planning
 When: need for software has already been
  established; stakeholders are on-board;
  coding is ready to begin
 What: project planning spans five major
  activities—estimation, scheduling, risk
  analysis, quality management planning, and
  change management planning
 Who: software project managers, with
  information from stakeholders and
  engineers
               Estimation
 Planning requires estimation early-on, even
  though it is likely this “commitment” will
  be proven wrong
 Some degree of uncertainty is unavoidable
  when predicting into the future
 Solid techniques and concrete procedures
  help reduce the inaccuracy of estimates
      Process-based estimation
 Most commonly-used technique for project
  estimation
 Project is broken down into a relatively
  small set of tasks and the effort required to
  accomplish each task is estimated
 Begins with a delineation of software
  functions obtained from the project scope
       Process-based estimation
 A series of framework activities must be
  performed for each function
 Representative framework activities:
     Customer communication
     Planning / risk analysis
     Engineering
     Construction / release
 Functions and activities may be shown
  together as a table:
           Process-based estimation table
                               Risk
Activity    CC    Planning               Engineering        Release       CE   Totals
                             analysis
Function                                Anal.   Design   Code   Test


UICF                                    0.75    2.50     0.40   5.00    n/a    8.65

3DGA                                    0.50    4.00     0.60   2.00    n/a    7.10

GCDF                                    0.50    4.00     1.00   3.00    n/a    8.50

DBM                                     0.50    3.00     1.00   1.50    n/a    6.00

PCF                                     0.25    2.00     0.75   1.50    n/a    4.50

DAM                                     0.50    2.00     0.50   2.00    n/a    5.00

Totals      .25   .25        .25        3.00    17.50    4.25   15.00          34.80

% effort    1%    1%         1%         7%      45%      12%    40%
      Process-based estimation
 Once functions and activities are melded,
  the planner estimates the effort (person-
  months) required to accomplish each
  activity per function
 Average labor rates are then applied to the
  estimated efforts (may vary per task)
 Cost and effort for each function and
  activity (row and column totals) are
  computed as the last step
      Estimation with use-cases
 Use-cases provide insight into software scope and
  requirements
 However, developing an estimation approach with
  use-cases is problematic:
    There is no standard form for use-cases
    They represent an external view (the user’s view) of the
     software, and vary in levels of abstraction
    Use-cases do not address the complexity of a feature
    Use-cases do not describe complex interactions
     between many functions and features
     Estimation with use-cases
 One person’s “use-case” could require
  months of effort, another just a day or two
 Estimation using use-cases has been
  investigated, but no proven method has
  emerged to date.
 Smith suggests a method for using use-
  cases, but in a strict, hierarchical manner
         Use-case estimation
 A structural hierarchy is described for the
  project
 Any level of the hierarchy can be described
  by no more than 10 use-cases
 Each of the use-cases would encompass no
  more than 30 distinct scenarios
            Use-case estimation
 Use-cases for a large system are described at a
  much higher level of abstraction then use-cases for
  individual sub-systems
 Before use-cases can be used:
    The level within the structural hierarchy is established
    Average length (in pages) of each use-case is
     determined
    The type of software (business, scientific, etc) is
     defined
    Rough architecture for the system is considered
         Use-case estimation
 Once those characteristics are established,
  empirical data can be used to determine
  estimated LOC or FP per each use-case for
  each level of the hierarchy
 Historical data are then used to calculate the
  effort required to develop the system
      Sample use-case estimation
LOC = N × LOCavg + [(Sa/Sh - 1) + (Pa/Ph - 1)] ×
  LOCadjust

N        = actual number of use-cases
LOCavg = historical average LOC per use-case for this type of system
Sa       = actual scenarios per use-case
Sh       = average scenarios per use-case for this type of system
Pa       = actual pages per use-case
Ph       = average pages per use-case for this type of system
LOCadjust= represents an adjustment based on n percent of LOC where
                n is defined locally and represents the difference
                between this project and “average” projects
         Reconciling estimates
 The various estimation methods encountered
  result in multiple estimates which must be
  reconciled
 The goal of a reconciliation process is to produce
  a single estimate of effort, project duration, or cost
 “Complicated methods might not yield a more
  accurate estimate, particularly when developers
  can incorporate their own intuition into the
  estimate.” -- Philip Johnson, et al.
        Reconciling estimates
 Widely divergent estimates can often be
  traced to one of two causes:
   The scope of the project is not adequately
    understood or has been misinterpreted by the
    planner
   Productivity data used for problem-based
    estimation is inappropriate for the application,
    obsolete, or has been misapplied.
 The planner must determine the cause of the
  divergence to reconcile the estimates
   Estimation for Agile projects
 Requirements for an agile project are
  defined as a set of user scenarios (e.g.,
  “stories” in Extreme Programming)
 It is possible to develop an estimation
  approach that is informal, but reasonable
  disciplined for each software increment
 This approach uses a decomposition method
  with the following steps:
   Estimation for Agile projects
1. Each user scenario is considered
   separately for estimation purposes
2. The scenario is decomposed into the set of
   functions and engineering tasks required
   to develop them
3. Each task is estimated separately, based
   on historical data, an empirical model, or
   “experience”
4. Estimates for each task are summed to
   obtain an estimate for the scenario
   Estimation for Agile projects
5. The effort estimates for all scenarios are
  summed for a given increment to obtain the
  increment estimate
 Because the project duration of an
  increment is short (3-6 weeks), the
  estimation approach serves two purposes:
   Ensure that the number of scenarios conforms
    to available resources
   Establish a basis for allocating effort as the
    increment is developed
Estimation for web engineering projects

 Web engineering projects often adopt the
  Agile process model
 Along with the Agile estimation approach, a
  modified function point (FP) measure can
  be used to develop an estimate for a web
  application
 Roetzheim suggests the following
  information domain values when adopting
  function points:
 Web application domain values
 Inputs are each input screen or form, each
  maintenance screen, and each tab (if that
  design metaphor is used anywhere)
 Outputs are each static web page, each
  dynamic page (script), and each report
  (whether web-based or administrative)
 Tables are each logical table in the
  database, or each XML object or collection
  of XML attributes (if XML is used for
  storage)
 Web application domain values
 Interfaces retain their definition as logical
  files (for example, unique record formats)
  into our out-of-the-system boundaries
 Queries are each externally published or use
  a message-oriented interface. A typical
  example is DCOM or COM external
  references
 Function points computed with these values
  are a reasonable indicator of volume for a
  web application
       Web application estimation
 Mendes suggests that the volume of a web
  application is best determined by collecting
  measures associated with the application called
  “predictor variables”
 These include:
      Application level: page, media, and function count
      Page level: page, linking, and graphic complexity
      Media level: media size, duration
      Functional characteristics: code length, reused code
       length
   Software project scheduling
 Creating a network of software engineering
  tasks enabling you to get the job dome on
  time
 Responsibility is assigned for each task,
  progress is tracked, and the network is
  adapted to changes in the process as they
  occur
   Software project scheduling


“I love deadlines. I like the whooshing sound
           they make as they fly by.”

                     -- Douglas Adams
Relationship between people and effort

 For small software projects, one person can
  analyze requirements, perform design,
  generate code, and conduct tests
 As the projects grow in size, more people
  most become involved
 As this happens, more and more time is
  spent managing the interaction and
  communication among the people involved
Relationship between people and effort

 Common myth still believed by many
  software managers:
  “If we fall behind schedule we can always
  add more programmers to catch up.”

 Smith’s law: Adding more people to a late
  software project always makes it later.
Relationship between people and effort

 People added to the project must learn the
  system, and the people who can teach them
  are the people currently producing code
 In addition to learning time, more people
  means more communication paths and
  increasing the complexity of
  communication throughout the project
  Elasticity of project schedules
 Empirical data and analysis has
  demonstrated that project schedules are
  elastic
 It is possible to compress a desired project
  completion date to some degree by adding
  resources
 Conversely, removing resources can extend
  a completion date
Putnum-Norden-Rayleigh Curve
 The PNR Curve provides an indication of
  the relationship between effort applied and
  delivery time for a software project
 There is a highly non-linear relationship
  between chronological time to complete a
  project and human effort applied
Putnum-Norden-Rayleigh Curve
 The number of delivered lines of code L is
  related to effort and development time by
  the equation:
      L = P × E1/3t4/3
E is development effort in person-months
P is a productivity parameter that reflects that
   result in high quality (typically 2,000-12,000)
t is the project duration in calendar months
Putnum-Norden-Rayleigh Curve
 Rearranged to solve for development effort:
            E = L3/(P3t3)

E is effort expended (in person-years) over the
   entire project life-cycle
L is lines of code (source statements)
P is a productivity parameter that reflects that
   result in high quality (typically 2,000-12,000)
t is the development time in years