1 Software Process and Project Metrics. 2 Normalization for Metrics.
-
Upload
toby-sutton -
Category
Documents
-
view
217 -
download
0
Transcript of 1 Software Process and Project Metrics. 2 Normalization for Metrics.
1
Software Process and Project Software Process and Project MetricsMetrics
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
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
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
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
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
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
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
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!
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
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)
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”
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 ….
14
You still may be late!You still may be late!
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
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
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
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”)
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