Tutorial: Estimation and Planning Examples
Friday, October 25th
Overview
Task Integration Example Pert/CPM Graph Gantt Chart COCOMO Quick SDL refresher
Task Integration
Modules taken from design doc Integration tasks taken from architecture doc Should reinforce architecture chosen
Be wary of odd dependencies
Integration Task Diagram
Task Integration Matrix
Test Plan Notes
Give reasons for why test plan was chosen
Creating Pert/CPM Graph
Integration task diagram often shows what tasks can be done concurrently In real world setting, priorities not necessarily follow ITG
This is why we need schedule priority charts Certain tasks may need to be done by certain people (domain knowledge, etc)
Vaguely Familiar Ground
CPM Graph
Earliest Completion Times
Latest Completion Times
Fixed CPM Graph
Missing labels: [0](0) [0](3) [0](5)
Coming up with Gantt Chart
Try to pick reasonable timelines
Usually earliest completion time is chosen Factor in vacations, breaks, etc
Make note of critical path
Helpful to indicate on Gantt chart
Try to evenly divide up workload
Gantt Chart Example 1
Gantt Chart Example 2
Why are we doing this?
Poor management is the downfall of many software projects. Delivered software may be late, unreliable, cost several times the original estimates and often exhibits poor performance characteristics. Software project management is different from other engineering management. Product is intangible to a certain extent. Most software projects are new and technically innovative. (myth?) Good management cannot guarantee project success but bad management usually results in project failure.
COCOMO
COnstructive COst MOdel Created by Barry Boehm in 1981 Essentially: EFF = a * SIZEb Based on a large number of projects from the 70s Very simple estimation tool which may or may not work depending on how closely project fits in with original study
Estimating Is Hard To Do
Basic Idea
Small Projects
Small teams (2-3 people) Easy to have mental model Fewer things in the way of completion EFFORT = a * SIZE + b
Large Projects
The more people there are, the harder it becomes EFFORT = a * SIZEb
a and b are scaling factors
Project Types
Organic
Routine project Well understood domain Team works well and efficiently together Project expected to run smoothly Typically a smaller system
Project Types
Embedded
Difficulties expected Project that is hard (control software for a nuclear plant, or spacecraft) Team has little experience in domain New or inexperienced team Tend to be large projects with lots of constraints
Project Types
Semi-Detached
In the middle Complex system, but something the company is familiar with Teams may be made up of experienced and inexperienced members System not huge, but not small either
What is a and b?
Organic
Person months = 2.4 * KDSI1.05
Semi-Detached
Person months = 3.0 * KDSI1.12
Embedded
Person months = 3.6 * KDSI1.20
Slightly More Advanced
Add in an adjustment factor
EFFORT = EAF * a * SIZEb Adjustment factors cover wide range of development aspects Factor all adjustment factors together to get EAF
Slightly More Advanced
The factors a and b differ Organic
a = 3.2, b = 1.05
Semi-Detached
a = 3.0, b = 1.12
Embedded
a = 2.8, b = 1.20
How to use COCOMO
Simply: Plug and Chug What if it doesnt work?
Play with adjustment factors Tweak a and b to make the equation fit the result Use a more complex metric
In Reality
Estimating comes with experience Using something like Function Points to come up with code size doesnt really work
(personal belief)
COCOMO is too simple and too old to really be of use
Good starting point, more advanced models available Tweaking formulas might yield good results
Quick Look At SDL
Credits
Lots of COCOMO info taken from
http://www.cs.unc.edu/~stotts/COMP1 45/cocomo.html
CPM slide Why Are We Doing This taken from another presentation (cant find URL)