project management

1. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT1
MANAGING SOFTWAREMANAGING SOFTWARE
DEVELOPMENTDEVELOPMENT
MANAGING SOFTWAREMANAGING SOFTWARE
DEVELOPMENTDEVELOPMENT
COMP 211COMP 211
INTRODUCTION TOINTRODUCTION TO
SOFTWARE ENGINEERINGSOFTWARE ENGINEERING
COMP 211COMP 211
INTRODUCTION TOINTRODUCTION TO
SOFTWARE ENGINEERINGSOFTWARE ENGINEERING

2. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT2
MANAGING SOFTWARE DEVELOPMENT —MANAGING SOFTWARE DEVELOPMENT —
THE CHALLENGETHE CHALLENGE
up front we need to:
come up with a plan for software development with
– incomplete knowledge (requirements, people, etc.)
– limited resources (time, money, skills, etc.)
decide
– what features are required – tasks to be done
– whether to build or buy – effort to be expended
– what resources are required – schedule to follow
– what are the risks – what development tools to use...
continuous process: “plan the work” and “work the plan”

3. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT3
THE SOFTWARE DEVELOPMENT PLAN (SDP)THE SOFTWARE DEVELOPMENT PLAN (SDP)
the SDP documents exactly how the project will be managed
it defines the project
first need to define the scope of the development
– define the problem → agree on what constitutes success
– analyze the requirements → so you can make sizing estimates
– prepare a top-level package diagram → overall view of the system
– estimate the time and effort needed to deliver the product
input needed from:
– development manager → project organization, WBS, budget
– experienced system architect → top-level package diagram,
project sizing
– expert user or domain expert → requirements understanding
outcome is a go/no-go decision

4. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT5
DELIVERABLESDELIVERABLES
Customer products → given to the customer
– executable code – tutorials
– user manuals – examples
– help files – templates
– installation scripts – developer manuals
– installation manuals – license managers
Process artifacts → outcomes of the development process
– use-case databases – requirements, analysis, design specs
– object design files – source code
Internal deliverables → of value to organization beyond this project
– source code libraries – make files
– test libraries – problem report database
Services → additional deliverables for the customer
– training – on-site support
– consulting – customization
– installation

5. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT6
DEVELOPMENT ENVIRONMENTDEVELOPMENT ENVIRONMENT
need to choose hardware and software development tools
appropriate for the project
development tools development process≠
tools are effective only if they make well-understood processes
more efficient
in choosing a development support tool evaluate:
– support of the lifecycle: UML; management oversight and control;
architectural control; collaboration support;
developer efficiency; library integration;
documentation support
– risk of adoption to both cost and schedule:
external cost; internal cost; time loss;
product instability; investment protection

6. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT7
SIZE AND EFFORT ESTIMATESSIZE AND EFFORT ESTIMATES
EstimatingEstimating:: trying to quantify something before it occursEstimatingEstimating:: trying to quantify something before it occurs
we usually need to estimate:
– size – effort – duration
– productivity – development cost
based on:
– experience – historical data – courage!
which is facilitated if we:
– establish project scope in advance
– use software metrics from past projects
– divide and conquer
estimating carries inherent risk

7. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT8
SOFTWARE METRICS FOR ESTIMATINGSOFTWARE METRICS FOR ESTIMATING
We can collect many types metrics about many aspects of
software.
Question: What metrics are useful for estimating and
how can they be used for estimating?
Technical metrics
Quality metrics
Productivity metrics
Size-oriented metrics
Function-oriented metrics
Human-oriented metrics
Productivity metrics
Size-oriented metrics
Function-oriented metrics

8. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT10
SIZE-ORIENTED METRICSSIZE-ORIENTED METRICS
and use it to calculate:
Productivity = KLOC/effort Quality = errors/KLOC
Cost = $K/KLOC Documentation = pages/KLOC
project effort $K KLOC pages errors people
A 24 168 12.1 365 29 3
B 62 440 27.2 1224 86 5
C 43 314 20.2 1050 54 6
We collect:
What is the problem with this approach?

9. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT11
FUNCTION-ORIENTED METRICSFUNCTION-ORIENTED METRICS
FP = count-total * [0.65 + 0.01 * sum(Fi)]
Productivity = FP/effort Quality = errors/FP
Cost = $/FP Documentation = pages/FP
Weighting factor
Measurement parameter Count Simple Average Complex
Number of user inputs x 3 4 6 =
Number of user outputs x 4 5 7 =
Number of user inquiries x 3 4 6 =
Number of files x 7 10 15 =
Number of external interfaces x 5 7 10 =
Count - total

10. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT14
ESTIMATION METHODSESTIMATION METHODS
System/Package-level analogy
– use experience from a previous similar development
may use Delphi technique - average 3 or more estimates
Pert estimation
each expert provides a range of values, typically
– optimistic – most likely – pessimistic
expected value computed as a weighted average of optimistic
(o), most likely (m) and pessimistic (p)
E = (o + 4m + p)/6 SD = (p - o)/6
actual size between E-SD and E+SD 68% of the time
SD is a measure of schedule and budget risk

11. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT15
ESTIMATION METHODS (cont’d)ESTIMATION METHODS (cont’d)
Parametric models
use parametric formulas empirically derived from a limited
sample of projects to predict effort, project duration, etc.
static single-variable models (e.g., COCOMO)
Resource = c1 x (estimated characteristic)C2
static multi-variable models
Resource = c11e1 + c12e2 + ...
dynamic multi-variable models (e.g., Putnam)
– estimates resource requirements as a function of time
c - empirically derived constants e - ith
software characteristic

12. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT16
COCOMO—COCOMO—COCONSTRUCTIVENSTRUCTIVE COCOSTST MOMODELDEL
Model 1 - Basic COCOMO
E = ab(KLOC)**(bb) effort in person-month
D = cb(E)**(db) development time in months
Software project ab bb cb db
Organic 2.4 1.05 2.5 0.38
Semi-detached 3.0 1.12 2.5 0.35
Embedded 3.6 1.20 2.5 0.32
organic – relatively small, simple software projects, non-rigid requirements
small teams with good application experience
semi-detached – an intermediate project;
teams with mixed experience levels;
must meet a mix of rigid and less rigid requirements
embedded – project must meet set of tight hardware, software and
operational constraints

13. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT17
COCOMO—COCOMO—COCONSTRUCTIVENSTRUCTIVE COCOSTST MOMODELDEL
Model 2 - Intermediate COCOMO
E = ai(KLOC)**bi x EAF effort in person-month
Software project ai bi
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20
Model 3 - Advanced COCOMO
– Model 2 plus an assessment of each cost driver’s impact on each
step of the software engineering process

14. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT19
PUTNAM ESTIMATION MODELPUTNAM ESTIMATION MODEL
E = L3
Ck
3
td
4
L = LOC
Ck = state-of-technology constant
td = development time in years
Requirements Analysis & Design Implementation Operation & Maintenance
Coding
Test & validation
Installation
Time →
Manpower(person/year)→

15. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT20
ESTIMATION — FINAL THOUGHTSESTIMATION — FINAL THOUGHTS
incomplete and imprecise requirements hinder accurate cost
estimation
under uncertainty, develop resource requirements incrementally
a cost estimation model is doing well if it can estimate software
development costs within 20% of actual costs, 70% of the time
on its “own turf”
always perform estimation in more than one way and do cross-
checks on your results
essential to have experienced developers do estimating
automated tools can help

16. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT21
RISK PLANNINGRISK PLANNING
If you do not actively attack risks, they will actively
attack you!
T. Gilb
If you do not actively attack risks, they will actively
attack you!
T. Gilb
try to:
– determine what can go wrong, before it happens
– determine its impact
– determine the likelihood that it could happen
– develop cost-effective contingency plans (what to do if it happens)
the ability to do this well is one of the important qualities of a good
manager
related to preventive management (i.e., determine the risk and
execute preventive action before the problem can take place)

17. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT22
RISK ANALYSISRISK ANALYSIS
Risk is one of the few certainties of
life!
Risk is one of the few certainties of
life!
project risks
– budget, schedule, personnel, resource, customer, requirements
problems, …
technical risks
– design, implementation, interfacing, testing, maintenance, …
business risks
– no market, no need, sales force can’t sell, no management
support, ...
it is important to identify all the risks that we can
use a risk checklist

18. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT23
RISK PROJECTION (ESTIMATION)RISK PROJECTION (ESTIMATION)
likelihood (li) of the risk (ri)
– establish a scale → Boolean, subjective, probabilities
consequences and impact (xi) of the risk
– its nature → what is likely to happen
– its scope → what is likely to be affected and to what degree
– its timing → when and duration
accuracy of projection
– basis for likelihood and impact
prioritize risks

19. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT24
RISK ASSESSMENTRISK ASSESSMENT
for each risk identified attempt to define the referent point
– project will be terminated above referent point
try to avoid/manage risks which could lead to project termination
Projected cost overrun
Projectedscheduleoverrun Project termination
will occur in this
region
referent point

20. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT25
RISK MANAGEMENT AND MONITORINGRISK MANAGEMENT AND MONITORING
Example: ri=high staff turnover li=0.7
xi=“increase duration by 15% and overall cost by 12%”
What steps can be taken to mitigate this risk?
“If you know the enemy and you know yourself, you
need not fear the result of a hundred battles.”
The Art of War, Sun Tzu
“If you know the enemy and you know yourself, you
need not fear the result of a hundred battles.”
The Art of War, Sun Tzu
need to perform cost/benefit analysis of countermeasures
Do they cost more than the consequences
of the risk itself?
apply 80:20 rule: 80% of all project risk is accounted for by
20% of identified risks

21. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT26
WORK BREAKDOWN STRUCTURE (WBS)WORK BREAKDOWN STRUCTURE (WBS)
breaks the project into tasks, sub-tasks, … → divide and
conquer
– usually shown in a tree structure
– identify all the activities/tasks required to complete the project
– estimate resources required for each leaf node and then “roll-up” to
get estimate for the entire project
– used in both budgets (cost of task) and schedules (time to do task)
WBS should allow each task to be:
– easily planned → has a well-defined start and end
– easily assigned → to individuals/teams
– tracked → can monitor progress and know who is working on it
– budgeted → has an associated cost
– of the right granularity → not too small and not too large

22. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT28
SCHEDULESSCHEDULES
need to determine schedule items and when they happen
– task ordering → dependencies (sequential, parallel)
– time estimates for each task → start time, duration (range?)
– resource assignment → people, hardware, software
– milestones → important management decision points
– deliverables → specifications, documents, code, etc.
– critical path → chain of tasks which determine project duration
prioritize by risk, criticality, resource utilization
usually three levels of schedule needed:
– master schedule → for communicating with management, customer
– macroschedule → for day-to-day management of project
– microschedule → for team management
Gantt and PERT charts commonly used

23. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT29
SCHEDULES — GANTT CHART EXAMPLESCHEDULES — GANTT CHART EXAMPLE
Task
Prepare project plan
Capture Requirements
Build System Prototype
Database Design
Implementation
Testing and Evaluation
Deployment
Post Project Review
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21
WeekCurrent Week
Incomplete Task
Partially Complete Task
Completed Task

24. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT30
SCHEDULES — PERT CHART EXAMPLESCHEDULES — PERT CHART EXAMPLE
4
A B
C
D E
F
G H
1 3
4
5 9
10
2 1
critical path 7
1 2 3 5 6 8 9
overall schedule depends on critical path

25. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT32
STAFFING AND ORGANIZATIONSTAFFING AND ORGANIZATION
create a (hierarchical) project organization chart that:
– identifies project roles and responsibilities
– plans the number of staff in each role
– establishes product teams as needed
interdisciplinary teams to coordinate certain efforts
team organization should:
– be modular to limit communication and complexity of interaction
– invest each team member with a clear sense of ownership
this implies that:
– teams should be formed to “own” the design and implementation of
one or more packages
– classes should be assigned to individuals for design and
implementation
– owners (leads) should be identified for packages and the system
achieving right level of communication is key to success

26. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT33
TIME-PHASED BUDGETTIME-PHASED BUDGET
a time-phased budget details
– when the project’s budget is planned to be spent
– what is expected to have been accomplished at each level of
expenditure
manpower will likely be your major cost
– to each WBS item assign costs based on duration, staffing level,
and cost for each type of staff
BUT, don’t forget other costs!
– travel – software licenses
– hardware – etc.
– plus some reserve (between 10-15%)
track your spending!
– compare planned and actual money spent against planned and
actual completion monthly

27. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT34
METRICS PLANMETRICS PLAN
for purposes of project management we need to:
– identify which development metrics to collect
– provide a plan for how to collect each of them
– describe procedures and tools the will be used to collect them
project management metrics are usually related to size:
– number of use cases
– number of classes
– lines of source code
compare planned sizes with current sizes to determine:
– progress: how much of the planned development is in place
– stability: how much change has there been in project requirements
and change estimates

28. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT35
PROJECT TRACKING AND CONTROLPROJECT TRACKING AND CONTROL
““software projects fall behind schedule one day at asoftware projects fall behind schedule one day at a
timetime””
““software projects fall behind schedule one day at asoftware projects fall behind schedule one day at a
timetime””
need to have constant, consistent, inoffensive monitoring of
project activities
primary purpose is to make sure the project is
meeting the budget and schedule
change is nearly inevitable despite best efforts to minimize it
key is to handle it in a controlled manner → SCM
““Adding manpower to a late software project makes itAdding manpower to a late software project makes it
later.”later.”
Frederick P. Brooks The Mythical Man-Month
““Adding manpower to a late software project makes itAdding manpower to a late software project makes it
later.”later.”
Frederick P. Brooks The Mythical Man-Month

29. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT36
METHODS OF PROJECT TRACKING & CONTROLMETHODS OF PROJECT TRACKING & CONTROL
project status meetings → weekly, monthly
doing project reviews and evaluating the results of each review
check if milestones are accomplished as planned
compare actual budget with planned budget and actual start
dates with planned start dates for activities
informal chats with project staff
if slipping
– diagnose and recover as best you can: reorganize, change
schedule, etc.

30. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT37
PROJECT TRACKING & CONTROL – FINAL THOUGHTSPROJECT TRACKING & CONTROL – FINAL THOUGHTS
need to identify what tasks in the WBS need to be done by when
and by who, AHEAD OF TIME
its the only way to know what you are doing and what else can
be changed (reordered) to try to stay on track
even if the schedule changes, you should identify why first and
incorporate knowledge into measurements for next time
a schedule slip is not good, but understandable, if you know why
it happened
BUT, missed deadlines with no schedule or knowledge of why
things are happening that way is INCOMPETENCE

31. COMP 211COMP 211 MANAGING DEVELOPMENTMANAGING DEVELOPMENT38
MANAGING SOFTWARE DEVELOPMENT SUMMARYMANAGING SOFTWARE DEVELOPMENT SUMMARY
“Manage the process, don’t let the process manage
you.”
Khoa Nguyen, CEO Videoserver