CS451 Lecture 5: Project Management

1
CS451Lecture 5 Project Management
Planning(II)

• Yugi Lee
• STB 555
• [phone]
• yugi_at_cstp.umkc.edu
• www.cstp.umkc.edu/yugi

2
Measurement (Metrics)

• Measurement is fundamental to any engineering
  discipline.
• When you can measure what you are speaking about
  and express it in numbers, you know something
  about it but when you can not measure, when
  you cannot express in numbers, your knowledge is
  of a meagre and unsatisfactory kind it may be
  the beginnings of knowledge, by you have
  scarcely, in your thoughts, advanced to the stage
  of a science.
• Lord Kelvin

3
Software Metrics

• Used to understand and improve the development
  process and quality
• Metric suggested for software
• Technical Metrics (character of software)
• Quality Metrics (fitness for use)
• Productivity Metrics (outputs)
• Within each of these classes can have
• Size oriented metrics (direct measures)
• Function Oriented metrics (indirect measures)
• Human Oriented metrics (process measures)

4
Estimation Guidelines

• Estimate using at least two techniques
• Get estimates from independent sources
• Avoid over-optimism, assume difficulties
• You've arrived at an estimate, sleep on it
• Adjust for the people who'll be doing the
  jobthey have the highest impact

5
Measurements of Programmer Productivity

• Good programmers may be 10 time more productive
  than poor programmers.
• Studies have show that complex (user) interfaces
  cause low productivity (factor of 4?).
• Experience of the team important (factor of 4?)
• Participation in requirements definition (factor
  of 2?).
• Type of system being developed (factor of 20?).

6
Cost Estimation

• Project scope must be explicitly defined
• Task and/or functional decomposition is necessary
• Historical measures (metrics) are very helpful
• At least two different techniques should be used
• Remember that uncertainty is inherent

7
Estimation Techniques

• Past (similar) project experience
• Conventional estimation techniques
• task breakdown and effort estimates
• size (e.g., FP) estimates
• Tools (e.g., Checkpoint)

8
Functional Decomposition
functional decomposition
Statement
perform
of Scope
a
"grammatical
parse"
9
Example SafeHome system (Functional
Decomposition)

• SafeHome system (analyzed in detail in Chapter
  12).
• Function Estimated LOC
• user interaction (2400)
• sensor monitoring (1100)
• message display (850)
• system configuration (1200)
• system control activation/deactivation (400)
• password processing (500)

10
Creating a Task Matrix

• Obtained from process framework

framework activities
application functions
Effort required to accomplish each framework
activity for each application function
11
LOC (Line of Code) Approach

• Direct measurements of the software and process
• KLOC, KLOC/person-month, Defects/KLOC
• Procedures, tasks
• Global data items
• lines of comment per program unit
• Pages of documentation
• Problems with definition and usefulness of some
  size metrics related to LOC
• language dependent better suited to very large
  programs difficult to estimate in advance

12
ExampleLOC Approach
13
SafeHome ExampleLOC Approach

• LOC estimates (in the C language) for each
  function are noted in parentheses.
• A total of 6450 LOC are estimated.
• Using the data noted in the problem
• Time 6450 LOC / 450 LOC/pm 14.3 pm
• Cost 14.3 pm 7,000/pm 100,000

14
Function-oriented metrics (Function Points (FP)
Approach)

• Indirect measures of software and process
• Interested in 'function points', a measure of the
  'information domain' and software complexity
• Number of user inputs/outputs/inquiries
• Number of files/external interfaces
• A linear combination of these values is computed
• Can then measure productivity as function points
  per month, quality by defects per function point
  and so on
• Designed for information systems but suggested
  extensions for other types of systems by
  including 'feature points'

15
ExampleFP Approach
16
SafeHome ExampleFP Approach

• A FP estimate (assuming implemented in C)
• 6450 LOC / 128 LOC/FP 50 FP (approximate)

17
Tool-Based Estimation
project characteristics
calibration factors
LOC/FP data
18
Empirical Estimation Models

• General form

exponent
effort tuning coefficient size
usually derived
empirically
as person-months
derived
of effort required
usually LOC but
may also be
function point
either a constant or
a number derived based
on complexity of project
19
Empirical Estimation Models

• Software Equation using 5.4 (page 136)
• b special skills factor, assuming B0.16,
• P productivity parameter (skill, language level,
  complexity, etc), assuming P 3,000,
• t project duration in months
• t.min 8.14 (6450/3000)0.43 8.14 1.38
  11.31 months
• E effect in person-months
• E 180 0.16 (0.94)3 24 months
• the project is small for the equation5.4 (putting
  this result in doubt), it likely that an estimate
  in the range 15 - 18 p-m

20
Empirical Estimation Model COCOMO

• Using the original COCOMO model
• D 2.5 E 0.35
• 2.5 16.92 0.35
• 6.7 person-months
• It appears that 6 months is aggressive, but
  probably possible, given the results of COCOMO
  and the size/complexity of the SafeHome project.

21
Make-Buy Decision Tree

• If system is built from scratch, there is a 70
  probability that the job will be difficult
• Using estimation techniques, the cost of a
  difficult development effort will be 450,000
• A simple development effort is estimated to cost
  380,000
• expected cost ? (path probability)i x
  (estimated path cost)i where I is the decision
  tree path
• For the build path
• expected cost 0.30 (380,000) 0.70 (450,000)
  429,000

22
The Make-Buy Decision
23
Computing Expected Cost
expected cost
(path probability) x (estimated path cost)
i
i
For example, the expected cost to build is

expected cost 0.30(380K)0.70(450K)

build
429 K

similarly,


expected cost 382K
reuse

expected cost 267K
buy

expected cost 410K
contr
24
When to Estimate Cost/Time

• Costs and schedule are estimated early because
  such information is demanded as early as
  possible.
• If a project is extremely complex with high
  technological risk and a fixed price proposal
  is to be submitted, costing of the project should
  (if possible) be delayed until after requirements
  analysis.
• The cost of requirements analysis alone can be
  estimated early.