Project Planning and Estimation

1
Project Planning and Estimation

• Chapters 23, 24
• Software Engineering A Practitioners Approach
• Roger S. Pressman

2
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
  activitiesestimation, scheduling, risk analysis,
  quality management planning, and change
  management planning
• Who software project managers, with information
  from stakeholders and engineers

3
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

4
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

5
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

6
Process-based estimation table
7
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

8
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 users 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

9
Estimation with use-cases

• One persons 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

10
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

11
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

12
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

13
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

14
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.

15
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

16
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

17
Estimation for Agile projects

• Each user scenario is considered separately for
  estimation purposes
• The scenario is decomposed into the set of
  functions and engineering tasks required to
  develop them
• Each task is estimated separately, based on
  historical data, an empirical model, or
  experience
• Estimates for each task are summed to obtain an
  estimate for the scenario

18
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

19
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

20
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)

21
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

22
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

23
Software project scheduling

• Creating a network of software engineering tasks
  enabling you to get the job done on time
• Responsibility is assigned for each task,
  progress is tracked, and the network is adapted
  to changes in the process as they occur

24
Software project scheduling

• I love deadlines. I like the whooshing sound
  they make as they fly by.
• Douglas Adams

25
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

26
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.
• Smiths law Adding more people to a late
  software project always makes it later.

27
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

28
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

29
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

30
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

31
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

32
(No Transcript)