Chapter 24 Project Scheduling and Tracking

1
Chapter 24Project Scheduling and Tracking
2
Why Are Projects Late?

• an unrealistic deadline established by someone
  outside the software development group
• changing customer requirements that are not
  reflected in schedule changes
• an honest underestimate of the amount of effort
  and/or the number of resources that will be
  required to do the job
• predictable and/or unpredictable risks that were
  not considered when the project commenced
• technical difficulties that could not have been
  foreseen in advance
• human difficulties that could not have been
  foreseen in advance
• miscommunication among project staff that results
  in delays
• a failure by project management to recognize that
  the project is falling behind schedule and a lack
  of action to correct the problem

3
How to Deal With Unrealistic Schedule Demands

• Perform a detailed project estimate for project
  effort and duration using historical data.
• Use an incremental process model that will
  deliver critical functionality imposed by
  deadline, but delay other requested
  functionality.
• Meet with the customer and explain why the
  deadline is unrealistic using your estimates
  based on prior team performance.
• Offer an incremental development and delivery
  strategy as an alternative to increasing
  resources or allowing the schedule to slip beyond
  the deadline.

4
Project Scheduling Perspectives

• One view is that the end-date for the software
  release is set externally and that the software
  organization is constrained to distribute effort
  in the prescribed time frame.
• Another view is that the rough chronological
  bounds have been discussed by the developers and
  customers, but the end-date is best set by the
  developer after carefully considering how to best
  use the resources needed to meet the customer's
  needs.

5
Scheduling Principles

• compartmentalization the product and process
  must be decomposed into a manageable number of
  activities and tasks
• interdependencyindicate task interrelationship
• Time allocation - every task has start and
  completion dates that take the task
  interdependencies into account
• effort validationbe sure resources are available
• defined responsibilities every scheduled task
  needs to be assigned to a specific team member
• defined outcomeseach task must have an output
• defined milestones a milestone is accomplished
  when one or more work products from an
  engineering task have passed quality review

6
Relationship Between People and Effort

• Common myth
• Adding people to a project after it is behind
  schedule often causes the schedule to slip
  further
• The relationship between the number of people on
  a project and overall productivity is not linear
  (e.g., 3 people do not produce 3 times the work
  of 1 person, if the people have to work in
  cooperation with one another)
• The main reasons for using more than 1 person on
  a project are to get the job done more rapidly
  and to improve software quality.

7
Effort and Delivery Time
8
The project scheduling process
9
Effort Allocation

• front end activities
• customer communication
• analysis
• design
• review and modification
• construction activities
• coding or code generation
• testing and installation
• unit, integration
• white-box, black box
• regression

40-50
15-20
30-40
10
Project Effort Distribution

• The 40-20-40 rule (a rule of thumb)
• 40 front-end analysis and design
• 20 coding
• 40 back-end testing
• Generally accepted guidelines are
• 02-03 planning
• 10-25 requirements analysis
• 20-25 design
• 15-20 coding

11
Software Project Types

• Concept development - initiated to explore new
  business concept or new application of technology
  
• New application development - new product
  requested by customer
• Application enhancement - major modifications to
  function, performance, or interfaces (observable
  to user)
• Application maintenance - correcting, adapting,
  or extending existing software (not immediately
  obvious to user)
• Reengineering - rebuilding all (or part) of a
  legacy system

12
Factors Affecting Task Set

• A task set is a collection of software
  engineering work tasks, milestones, and work
  products that must be accomplished to complete a
  particular project
• Size of project
• Number of potential users
• Mission criticality
• Application longevity
• Requirement stability
• Ease of customer/developer communication
• Maturity of applicable technology
• Performance constraints
• Embedded/non-embedded characteristics
• Project staffing
• Reengineering factors

13
Defining Task Sets

• Activity
• Major work unit
• Start date
• End date
• Consumes resources
• Results in work products (and milestones)

Step 1 Step 2
Activity 1 Activity 2 Activity 3
Phase 1
Step 1 Step 2
Activity 1 Activity 2
Task 1 Task 2 Task 3
Project
Phase 2
Step 1 Step 2
Phase N
14
Scheduling

• Task networks (activity networks) are graphic
  representations that can be of the task
  interdependencies and can help define a rough
  schedule for particular project
• Scheduling tools should be used to schedule any
  non-trivial project.
• PERT (program evaluation and review technique)
  and CPM (critical path method) are quantitative
  techniques that allow software planners to
  identify the chain of dependent tasks in the
  project work breakdown structure that determine
  the project duration time.
• Timeline (Gantt) charts enable software planners
  to determine what tasks will need to be conducted
  at a given point in time (based on estimates for
  effort, start time, and duration for each task).
• The best indicator of progress is the completion
  and successful review of a defined software work
  product.

15
Task durations and dependencies
16
Activity network
17
Activity timeline
18
Staff allocation
19
Use Automated Tools toDerive a Timeline Chart
20
Schedule Tracking

• conduct periodic project status meetings in which
  each team member reports progress and problems.
• evaluate the results of all reviews conducted
  throughout the software engineering process.
• determine whether formal project milestones (the
  diamonds shown in Figure 24.3) have been
  accomplished by the scheduled date.
• compare actual start-date to planned start-date
  for each project task listed in the resource
  table (Figure 24.4).
• meet informally with practitioners to obtain
  their subjective assessment of progress to date
  and problems on the horizon.
• use earned value analysis (Section 24.6) to
  assess progress quantitatively.

21
Progress on an OO Project-I

• Technical milestone OO analysis completed
• All classes and the class hierarchy have been
  defined and reviewed.
• Class attributes and operations associated with a
  class have been defined and reviewed.
• Class relationships (Chapter 8) have been
  established and reviewed.
• A behavioral model (Chapter 8) has been created
  and reviewed.
• Reusable classes have been noted.
• Technical milestone OO design completed
• The set of subsystems (Chapter 9) has been
  defined and reviewed.
• Classes are allocated to subsystems and reviewed.
• Task allocation has been established and
  reviewed.
• Responsibilities and collaborations (Chapter 9)
  have been identified.
• Attributes and operations have been designed and
  reviewed.
• The communication model has been created and
  reviewed.

22
Progress on an OO Project-II

• Technical milestone OO programming completed
• Each new class has been implemented in code from
  the design model.
• Extracted classes (from a reuse library) have
  been implemented.
• Prototype or increment has been built.
• Technical milestone OO testing
• The correctness and completeness of OO analysis
  and design models has been reviewed.
• A class-responsibility-collaboration network
  (Chapter 8) has been developed and reviewed.
• Test cases are designed and class-level tests
  (Chapter 14) have been conducted for each class.
• Test cases are designed and cluster testing
  (Chapter 14) is completed and the classes are
  integrated.
• System level tests have been completed.

23
Earned Value Analysis

• Earned Value Analysis is
• a quantitative measure given to each task as a
  percent of project completed so far
• an industry standard way to
• measure a projects progress
• forecast its completion date and final cost, and
• provide schedule and budget variances along the
  way
• rather than rely on a gut feeling
• By integrating three measurements, it provides
  consistent, numerical indicators with which you
  can evaluate and compare projects.

24
Whats more Important?

• Knowing where you are on schedule?
• Knowing where you are on budget?
• Knowing where you are on work accomplished?

25
EVA Integrates All Three

• It compares the PLANNED amount of work with what
  has actually been COMPLETED, to determine if COST
  , SCHEDULE, and WORK ACCOMPLISHED are progressing
  as planned.
• Work is Earned or credited as it is completed.

26
Earned Value needed because...

• Have an accurate estimate of project status
• Provides an Early Warning signal for prompt
  corrective action.
• Bad news does not age well.
• Still time to recover
• Timely request for additional funds

27
Basic Earned Value Measures

• BCWS - Budgeted Cost of Work Scheduled
• Planned cost of the total amount of work
  scheduled to be performed by the milestone date
• ACWP - Actual Cost of Work Performed
• Cost incurred to accomplish the work that has
  been done to date
• BCWP - Budgeted Cost of Work Performed
• The planned (not actual) cost to complete the
  work that has been done
• BAC - Budget At Completion

28
Derived Earned Value Measures continued

• SPI Schedule Performance Index
• SPI BCWP/BCWS
• SPI lt 1 ? project is behind schedule
• The closer SPI to 1 indicates more efficient
  execution of project
• CPI Cost Performance Index
• CPI BCWP/ACWP
• CPI lt 1 ? project is over budget
• CSI Cost Schedule Index
• CSI CPI x SPI
• The further CSI is from 1.0, the less likely
  project recovery becomes.

29
Derived Earned Value Measures

• SV Schedule Variance (BCWP-BCWS)
• A comparison of amount of work performed during a
  given period of time to what was scheduled to be
  performed.
• A negative variance means the project is behind
  schedule
• CV Cost Variance (BCWP-ACWP)
• A comparison of the budgeted cost of work
  performed with actual cost.
• A negative variance means the project is over
  budget.

30
Derived Earned Value Measures continued

• Percent scheduled for completion BCWS/BAC
• provides an indication of the percentage of work
  that should have been completed by time t.
• Percent complete BCWP/BAC
• provides a quantitative indication of the percent
  of completeness of the project at a given point
  in time, t.