Scheduling and Tracking CS 3302 Lecture 5

1
Scheduling and TrackingCS 3302Lecture 5

• David Smith
• dmsmith_at_cc.gatech.edu

2
Course Overview
Week 2 Concept
Weeks 3-4 Requirements
Weeks 5-6 Design
Weeks 7-8 Code
Process Management Analysis Planning
Scheduling Tracking Risk Management SW Design
Week 9 Test
Week 10 Slack Time
OO Concepts OO Design
Measurement Testing Design for Real-Time
Requirements Review
Software Quality Software Re-Use
Design Review
Modeling Summary
Demo
3
Scheduling Tracking

• Basic Principles
• People vs Effort
• Defining the Tasks
• Task Network
• Scheduling
• The Project Plan

Note In the examples used in this lecture, the
names of the tasks are deliberately not
consistent. This might encourage you to choose
tasks and sub-tasks appriopriate to your
particular project.
4
Why is Software Late?
Napoleon Any commander-in-chief who undertakes
to carry out a plan which he considers defective
is at fault he must put forth his reasons,
insist on the plan being changed, and finally
tender his resignation rather than be the
instrument of his armys downfall.

• Unrealistic deadlines established by managers
• Changing requirements not flowed through a
  project plan
• Risks not considered at the beginning
• Miscommunications resulting in re-work
• Honest under-estimation of the job
• Management failure to track progress
• Unaware the project is in trouble
• No corrective action taken

5
Variability of Estimates
6
When Software is Late

• The manager should be the first to know it is
  late How?
• Find out what went wrong with the project plan
• Asking for a project slip is NOT usually a good
  idea!
• Develop an incremental plan for delivering some
  functionality on time
• Meet with the customer
• Explain why the lateness occurred
• Offer the revised program plan

7
Designing a Project for Tracking

• Compartmentalize
• Both the product and the process
• Find the Dependencies
• Allocate the times
• Involve all of the developers
• Validate the Estimates
• Use appropriate, tailored models
• Define responsibilities
• Define task exit criteria
• Define milestones

8
People vs Effort

• If we fall behind schedule, we can always add
  more programmers and catch up later in the
  project!
• Why does this not work?
• learning curve
• teaching takes time away from productive work
• added communication paths
• Effort will still be distributed 40-20-40

Source SW Eqn 30,000 LOC 10,000 LOC/year
9
Defining the Tasks

• Select your Software Engineering tasks
• Concept Definition
• Project Planning
• Risk Analysis
• Implementation
• Integrate and Test
• Demonstrate
• Define Entrance and Exit Criteria
• Define Progress Metrics
• Assign Responsibilities
• Allocate milestones - PDR, peer reviews

40 20 40
10
Spiral Model
Planning
Risk Analysis
Customer Communication
Start Axis
Customer Evaluation
Development
Integration
You will be finished with the task specification
when all team members have agreed exactly what
they are doing for the next 9 weeks, and how they
will measure their progress
11
Typical Work Breakdown Structure
Build communications software
12
Typical Schedule
13
Resource Loading
Load
Overload
Underload
PROJECTED STAFF-DAYS
JAN
FEB
MAR
APR
MAY
JUN
JUL
AUG
SEP
OCT
NOV
DEC
14
Task Network

• Enables the team to see the essentially serial
  nature of the project, but take advantage of
  parallelism where possible.

1.4a Module A Des/Dev
1.2 Project Planning
1.6 Concept Demo
1.4b Module B Des/Dev
PDR
15
Scheduling Example
5
2
Find the critical path
6
3
2
FINISH
START
8
4
3
2
A
2
3
5
3
4
3
1
16
Project Deliverables
Project Plan
1
Week 2 Concept
Weeks 3-4 Requirements
3
2
Weeks 5-6 Design
Weeks 7-8 Code
1
Week 9 Test
2
Requirements Specification
Design Description
Code
Test Report
Personal Activity Reports
17
Project Plan

• 1 Introduction
• copy and paste directly from requirements
  specification
• 2 Project Estimates
• describe estimation technique
• table of module name, estimated effort
• 3 Risk Management NOT YET
• identify all risks
• table of risk, severity, consequences, detection,
  remediation
• 4 Schedule
• identify each task (1 week granularity)
• identify starting and ending triggers for each
  task
• allocate people by name to each task
• list of tasks on project time line
• include opportunities to review work products
• 5 Resources
• 5.1 Resources Available
• table of person name intended hours task
  assignment
• 5.2 Resource Loading NOT EVER
• diagram mapping resource allocation onto the
  schedule

18
Progress Tracking Reporting

• Team must agree to tasking and estimates
• Beginning next week, each team manager will
  present a management report
• Current plan
• Milestones achieved
• Metrics for current phase
• Identify current risks
• We will discuss problem resolutions
• staff reassignments
• reduction in scope
• other ideas for resolving issues

19
Project Grading

• Your team grade will not suffer if you do not
  demonstrate and test all of the requirements IFF
• We all knew that you are behind
• We all knew why you are behind
• You have tried as a team to implement all
  suggestions from the class
• document the suggestion
• show how it was implemented
• show why it didnt work
• However, if you show up at week 10 with stuff
  that wont run, and you have been telling us for
  9 weeks that everything is fine, the whole team
  had better have a really good alibi...

20
Alibis that Wont Work

• There was more code to write than we thought
• The software we wanted to re-use didnt work
• The requirements werent testable
• We couldnt integrate the modules
• The tests were too hard to write
• The ltrolegt on our team didnt do their job
• The design was all messed up
• We didnt have enough time
• Professor Hydes assignment took time away from
  us
• The system crashed last night and we lost all our
  code and test scripts