1 Software Process and Project Metrics. 2 Normalization for Metrics.

19
1 Software Process and Project Software Process and Project Metrics Metrics

Transcript of 1 Software Process and Project Metrics. 2 Normalization for Metrics.

Page 1: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

1

Software Process and Project Software Process and Project MetricsMetrics

Page 2: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

2

Normalization for Normalization for MetricsMetricsNormalized data are used to evaluate the process

and the product (but never individual people)

size-oriented normalization —the line of code approach function-oriented normalization —the function point approach

Page 3: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

3

Typical Size-Oriented Typical Size-Oriented MetricsMetrics

errors per KLOC (thousand lines of code) errors per KLOC (thousand lines of code) or FPor FP

defects per KLOC or FPdefects per KLOC or FP $ per LOC or FP$ per LOC or FP page of documentation per KLOC or FPpage of documentation per KLOC or FP errors / person-montherrors / person-month LOC per person-monthLOC per person-month $ / page of documentation$ / page of documentation

Page 4: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

4

Why Opt for Function Why Opt for Function Point (FP)Point (FP)

Measures? Measures?independent of programming language uses readily countable characteristics of the "information domain" of the problem does not "penalize" inventive implementations that require fewer LOC than others makes it easier to accommodate reuse and the trend toward object-oriented approaches

Page 5: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

5

Analyzing the Information Analyzing the Information DomainDomain

complexity multiplier

function points

number of user inputs number of user outputs number of user inquiries number of files number of ext.interfaces

measurement parameter

3 4 3 7 5

countweighting factor

simple avg. complex

4 5 4 10 7

6 7 6 15 10

= = = = =

count-total

X X X X X

Page 6: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

6

Taking Complexity into Taking Complexity into AccountAccount

Factors are rated on a scale of 0 (not important) to 5 (very important):

data communications distributed functions heavily used configuration transaction rate on-line data entry end user efficiency

on-line update complex processing installation ease operational ease multiple sites facilitate change

Page 7: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

7

LOC per Function LOC per Function PointPoint

Assembly language 320Assembly language 320 C 128C 128 COBOL 106COBOL 106 Fortran 106Fortran 106 C++ 64C++ 64 Visual Basic 32Visual Basic 32 Smalltalk 22Smalltalk 22 SQL 12SQL 12

Page 8: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

8

Criticism of Function Criticism of Function Point Point

measurementmeasurementThe weighting factor makes the FP The weighting factor makes the FP number highly dependent on the number highly dependent on the

developer’s experience:developer’s experience:

The developer can essentially set The developer can essentially set the FP number to what the the FP number to what the

developer wantsdeveloper wants

Page 9: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

9

(All? Most?) Projects are (All? Most?) Projects are LateLate

Project estimation is difficultProject estimation is difficult Effort is not progressEffort is not progress Management sets unrealistic goalsManagement sets unrealistic goals Schedules poorly monitoredSchedules poorly monitored Brooks law: adding persons to a late Brooks law: adding persons to a late

project makes it laterproject makes it later

NOTE: Your project will note be late!NOTE: Your project will note be late!

Page 10: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

10

Partitioning Partitioning Tasks Tasks

Perfectly partitionable taskPerfectly partitionable task Unpartitionable taskUnpartitionable task Partitionable task requiring Partitionable task requiring

communicationcommunication Task with complex interelelationshipsTask with complex interelelationships

Page 11: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

11

Programmers are Programmers are OptimistsOptimists

All will go well (Murphy’s Law doesn’t All will go well (Murphy’s Law doesn’t apply to our project)apply to our project)

Each task will only take as long as it Each task will only take as long as it ought to takeought to take

No one (on our project) will ever get No one (on our project) will ever get sick, take vacation time, or have sick, take vacation time, or have family emergenciesfamily emergencies

Programmers get to spend all their Programmers get to spend all their time programming (never in meetings, time programming (never in meetings, conferences, travel)conferences, travel)

Page 12: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

12

Brooks Scheduling Rule of Brooks Scheduling Rule of ThumbThumb

1/3 Planning1/3 Planning 1/6 Coding1/6 Coding 1/4 component and early system test1/4 component and early system test 1/4 system test1/4 system test 40-20-40 rule (40% design, 20% code, 40-20-40 rule (40% design, 20% code,

40% test) 40% test) ““Testing is usually the most mis-Testing is usually the most mis-

scheduled part of programming” scheduled part of programming”

Page 13: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

13

Piwowarski Scheduling Piwowarski Scheduling AlgorithmAlgorithm

Estimate all tasks assuming the Estimate all tasks assuming the experience of the person doing it (not experience of the person doing it (not yourself)yourself)

Add 25% to this for overhead Add 25% to this for overhead (meetings, vacation, travel, etc.)(meetings, vacation, travel, etc.)

Add 25% of the previous step for Add 25% of the previous step for contingency (nothing ever goes right)contingency (nothing ever goes right)

If you do the above …. If you do the above ….

Page 14: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

14

You still may be late!You still may be late!

Page 15: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

15

Scheduling Scheduling ExampleExample

All tasks to be done by your team All tasks to be done by your team (including testing documentation, (including testing documentation, etc.) 160 PMetc.) 160 PM

Add 25% for overhead 200 PMAdd 25% for overhead 200 PM Add 25% for contingency 250 PMAdd 25% for contingency 250 PM The final number is over 50% greater The final number is over 50% greater

than the original estimate of “actual” than the original estimate of “actual” work that needs to be donework that needs to be done

Page 16: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

16

Programmer Programmer ProductivityProductivity

Is lower (in LOC per PM) than you Is lower (in LOC per PM) than you think!think!

Studies and models (Brooks, Studies and models (Brooks, Pressman) vary widelyPressman) vary widely

Some projects at IBM used a rule of Some projects at IBM used a rule of thumb of 100-200 lines per person thumb of 100-200 lines per person monthmonth

Page 17: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

17

ProductiviProductivityty

Reasons for low LOC/PM: (see Reasons for low LOC/PM: (see Programmers are Optimists) Programmers are Optimists)

Productivity highly dependent on the Productivity highly dependent on the task:task:System Code vs. application codeSystem Code vs. application codeNew programs vs. modification to current programsNew programs vs. modification to current programs Experience of programmersExperience of programmers 10 to 1 difference in programmer productivity10 to 1 difference in programmer productivity

No “formula” will workNo “formula” will work You must make adjustments for your You must make adjustments for your

projectproject

Page 18: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

18

Brooks Advice for Late Brooks Advice for Late ProjectsProjects

DON’T ADD PERSONS TO A LATE DON’T ADD PERSONS TO A LATE PROJECTPROJECT

But you can:But you can: Reschedule (but “take no small slips”) Reschedule (but “take no small slips”)

– Can’t be done for your project– Can’t be done for your project Trim the task (drop the unneeded Trim the task (drop the unneeded

features - the “bells and whistles”)features - the “bells and whistles”)

Page 19: 1 Software Process and Project Metrics. 2 Normalization for Metrics.

19

What can be done What can be done for for

CS499 projectsCS499 projects START ON TIME AND KEEP TO YOUR START ON TIME AND KEEP TO YOUR SCHEDULESCHEDULE

Have project checkpoints during the Have project checkpoints during the semester to keep you to your semester to keep you to your scheduleschedule

Drop the “bells and whistles” (but Drop the “bells and whistles” (but check with your customer first), BUT:check with your customer first), BUT:

Make sure essential customer Make sure essential customer requirements are metrequirements are met