Software Project Management

1
Software Project Management

• CS 3302

2
Contents

• Project planning scheduling
• Cost and schedule estimation
• Scheduling and tracking

3
Cost Estimation

• Problem
• Late projects
• Cost is notoriously difficult to estimate
• Goal
• Estimate cost reliably in advance
• Warning
• Always approximate
• but should get more accurate over time
• Precision is not accuracy

4
Origin of Costs

• Software development is labor-intensive
• Cost is mainly development cost
• Few capital expenses (except those in overheads)
• Brooks's Law
• Adding more people to a late project will only
  make it later
• Effects of communication overhead, learning
  curve, etc.
• Diseconomies of scale
• Twice the project requires more than twice the
  effort
• (But what does "twice the project" mean?)

5
Poor estimation strategies

• Parkinsonian estimation and pricing to win
• Parkinson's Law
• Work expands to fill the time available
• Therefore estimate according to available
  resources
• Parkinsonian estimation is always optimistic
• Projects are only started if there are funds for
  them
• Therefore estimate within funds available or
  undercut competition
• Informal analogy
• Many projects are similar to each other
• Therefore, estimate from previous experience

6
Better informal estimation techniques

• Bottom-up estimation
• Break project into work items
• Estimate cost of each work item
• Reduces random estimation error
• But does nothing for systematic errors (e.g.
  over-optimism)
• Expert consensus
• Use committee or Delphi-based consensus
• Susceptible to "risky shift"

7
Effort as a function of size
developer experience

• Historical data shows that the best predictor of
  effort is product size
• Size is usually measured in thousands of lines of
  code (KLOC)
• But this replaces one estimate with another
• But prediction formula is different for different
  organizations

size
platform stability
effort
novelty
etc.,...
8
Algorithmic cost estimation

• Requirements
• Set of cost drivers that are believed to
  contribute to cost
• Simplest model has one driver KLOC
• Ways to score a project on each of the drivers
• Formula for predicting cost from the drivers
• Need historical data
• Unambiguous way of measuring each driver (e.g.
  definition of a line of code, person-month)
• Form
• Most are exponential
• (Exponent gt 1 reflects diseconomy of scale)
• Accuracy is poor

9
Function points

• Function points are a measure of system size
• Unlike KLOC, which is sensitive to layout rules
  and difficult to estimate, FPs are derived from a
  specification
• Measuring
• Weighted sum of
• Number of inputs
• Number of outputs
• Number of queries
• Number of files
• Weightings are proprietary
• Applicability
• Most applicable for commercial DP applications

10
Activity Scheduling

• Activity charts show dependencies between
  activities
• Not all are strictly "PERT" charts
• Activities may be on nodes
• dependencies are arcs
• or on arcs
• nodes are states/milestones
• Activities have estimated duration
• therefore latest and earliest start and finish
  times
• First activitys EST and LST both are 0 Last
  activitys EFT and LFT should be same
• If LFT-EFT slack

3
2
3
4
3
1
8
11
Qualitative analysis of activity networks for
risk reduction

• Quantitative critical path analysis is not always
  necessary
• High fan-in indicates risk
• If any of the preconditions slip, the activity
  will be delayed
• High fan-out indicates risk
• If the activity slips, many other activities may
  be affected

12
Activity scheduling for software development

• Standard critical path modeling can be used in
  software projects
• Critical path has no slack
• If any activity on critical path is delayed,
  project will be delayed
• Pure PERT modeling uses statistical approximation
• Activities have three duration estimates
  minimum, expected and maximum
• Minimum and maximum are assumed to be 2SD
  above and below mean, so can calculate Std. Error
  of entire project duration
• Used since 1950s in major construction and
  engineering projects
• But, there are limitations for software systems
• Dependencies are inexact
• Contrast dependencies in building construction
  and software
• Deliverable products are intangible
• When is a product finished?

13
Top 10 risk items (Boehm)

• People
• Personnel shortfalls
• Resources
• Unrealistic schedules and budgets
• Requirements
• Developing wrong functions
• Developing wrong UI
• Gold plating
• Changing requirements

• External risks
• Shortfalls in externally produced components
• Shortfalls in externally performed tasks
• Technology risks
• Real-time performance inadequacies
• Straining CS capabilities