Estimating Software Development Using Project Metrics

23
1 Estimating Software Estimating Software Development Development Using Project Metrics Using Project Metrics

description

Estimating Software Development Using Project Metrics. Project Estimating. It is Possible to Estimate Software Projects Accurately Accurate Estimates Take HISTORY and TIME Estimation Procedure Must Be Formal Standards Accurate Estimates Need a Quantitative Tool - PowerPoint PPT Presentation

Transcript of Estimating Software Development Using Project Metrics

Page 1: Estimating Software Development  Using Project Metrics

1

Estimating Software Estimating Software

DevelopmentDevelopment

Using Project Metrics Using Project Metrics

Page 2: Estimating Software Development  Using Project Metrics

2

Project EstimatingProject Estimating It is Possible to Estimate Software Projects It is Possible to Estimate Software Projects

AccuratelyAccurately Accurate Estimates Take HISTORY and TIMEAccurate Estimates Take HISTORY and TIME Estimation Procedure Must Be Formal StandardsEstimation Procedure Must Be Formal Standards Accurate Estimates Need a Quantitative ToolAccurate Estimates Need a Quantitative Tool Estimates Must be Redone After Every Life Cycle Estimates Must be Redone After Every Life Cycle

PhasePhase

Once All Stakeholders agree on estimation procedures, negotiations can involve Inputs (features & resources) NOT Outputs (time & dollars)

Page 3: Estimating Software Development  Using Project Metrics

3

Activities to be EstimatedActivities to be EstimatedObviousObvious

PlanningPlanning DesignDesign CodingCoding ProceduresProcedures TestingTesting ConversionConversion DocumentatioDocumentatio

nn OperationsOperations MaintenanceMaintenance

Not Obvious

•User/Customers Interaction

•Prototype Demonstrations

•Reviews and Approvals

•Problem/Design Fixes

•Prior Project Support

•Documentation redoes

•Training, vacations, sick, ...

Page 4: Estimating Software Development  Using Project Metrics

4

Danger SignsDanger Signs Estimates the Project Team Does NOT Estimates the Project Team Does NOT

AcceptAccept Estimates Your Experts Do Not AcceptEstimates Your Experts Do Not Accept Estimates that Include OvertimeEstimates that Include Overtime Estimates Assuming Over 80% Estimates Assuming Over 80%

UtilizationUtilization Estimates Without Detailed Task PlansEstimates Without Detailed Task Plans Estimates More Than A “Month” OldEstimates More Than A “Month” Old Estimates NOT UNDER CHANGE Estimates NOT UNDER CHANGE

CONTROLCONTROL

Page 5: Estimating Software Development  Using Project Metrics

5

Measurement & Measurement & MetricsMetrics

... collecting metrics is too hard ... ... collecting metrics is too hard ...

it's too time-consuming ... it's too it's too time-consuming ... it's too

political ... it won't prove anything ...political ... it won't prove anything ...

Anything that you need to Anything that you need to quantify can be measured in quantify can be measured in some way that is superior to some way that is superior to not measuring it at all ..not measuring it at all ..

Tom GilbTom Gilb

Page 6: Estimating Software Development  Using Project Metrics

6

Why do we Why do we Measure?Measure?

To To characterizecharacterize

To evaluateTo evaluate To predictTo predict To improveTo improve

Page 7: Estimating Software Development  Using Project Metrics

7

A Good Manager A Good Manager MeasuresMeasures

measurementmeasurement

What do weWhat do weuse as ause as abasis?basis? • • size?size? • • function?function?

project metricsproject metrics

process metricsprocess metricsprocessprocess

productproduct

product metricsproduct metrics

Page 8: Estimating Software Development  Using Project Metrics

8

Process MetricsProcess Metrics

majority focus on quality achieved majority focus on quality achieved as a consequence of a repeatable as a consequence of a repeatable or managed processor managed process

statistical SQA datastatistical SQA data error categorization & analysiserror categorization & analysis

defect removal efficiencydefect removal efficiency propagation from phase to phasepropagation from phase to phase

reuse datareuse data

Page 9: Estimating Software Development  Using Project Metrics

9

Project MetricsProject Metrics

Effort/time per development taskEffort/time per development task Errors uncovered per review hourErrors uncovered per review hour Scheduled vs. actual milestone datesScheduled vs. actual milestone dates Changes (number) and their Changes (number) and their

characteristicscharacteristics Distribution of effort on development Distribution of effort on development

taskstasks

Page 10: Estimating Software Development  Using Project Metrics

10

Product MetricsProduct Metrics focus on the quality of focus on the quality of

deliverablesdeliverables measures of analysis modelmeasures of analysis model complexity of the designcomplexity of the design

internal algorithmic complexityinternal algorithmic complexity architectural complexityarchitectural complexity data flow complexitydata flow complexity

code measures (e.g., Halstead)code measures (e.g., Halstead) measures of process effectivenessmeasures of process effectiveness

e.g., defect removal efficiencye.g., defect removal efficiency

Page 11: Estimating Software Development  Using Project Metrics

11

Metrics Metrics GuidelinesGuidelines Use common sense and organizational sensitivity Use common sense and organizational sensitivity

when interpreting metrics data.when interpreting metrics data. Provide regular feedback to the individuals and teams Provide regular feedback to the individuals and teams

who have worked to collect measures and metrics.who have worked to collect measures and metrics. Don’t use metrics to appraise individuals.Don’t use metrics to appraise individuals. Work with practitioners and teams to set clear goals Work with practitioners and teams to set clear goals

and metrics that will be used to achieve them.and metrics that will be used to achieve them. Never use metrics to threaten individuals or teams.Never use metrics to threaten individuals or teams. Metrics data that indicate a problem area should not Metrics data that indicate a problem area should not

be considered “negative.” These data are merely an be considered “negative.” These data are merely an indicator for process improvement.indicator for process improvement.

Don’t obsess on a single metric to the exclusion of Don’t obsess on a single metric to the exclusion of other important metrics.other important metrics.

Page 12: Estimating Software Development  Using Project Metrics

12

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 13: Estimating Software Development  Using Project Metrics

13

Typical Size-Oriented Typical Size-Oriented MetricsMetrics errors per KLOC (thousand lines errors per KLOC (thousand lines

of code)of code) defects per KLOCdefects per KLOC $ per LOC$ per LOC page of documentation per KLOCpage of documentation per KLOC errors / person-montherrors / person-month LOC per person-monthLOC per person-month $ / page of documentation$ / page of documentation

Page 14: Estimating Software Development  Using Project Metrics

14

Typical Function-Oriented Typical Function-Oriented MetricsMetrics

$ per FP$ per FP FP per person-monthFP per person-month errors per Function Point (FP)errors per Function Point (FP) defects per FPdefects per FP pages of documentation per pages of documentation per

FPFP

Page 15: Estimating Software Development  Using Project Metrics

15

Why Opt for FP Why Opt for 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 16: Estimating Software Development  Using Project Metrics

16

Computing Function Computing Function PointsPointsAnalyze information

domain of the application and develop counts

Weight each count by assessing complexity

Assess influence of global factors that affect the application

Compute function points

Establish count for input domain and system interfaces

Assign level of complexity or weight to each count

Grade significance of external factors, F such as reuse, concurrency, OS, ...

degree of influence: N = Fi

complexity multiplier: C = (0.65 + 0.01 x N)

function points = (count x weight) x C

where:

i

Page 17: Estimating Software Development  Using Project Metrics

17

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 18: Estimating Software Development  Using Project Metrics

18

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 19: Estimating Software Development  Using Project Metrics

19

Typical CalculationTypical CalculationFP CountFP Count 300300

Complexity FactorComplexity Factor 1.2 1.2

FP (Estimated)FP (Estimated) 360 360

Productivity Factor (measured) Productivity Factor (measured) 8 FP/pm 8 FP/pm

$/pm$/pm $8,000$8,000

$/FP$/FP $1,000 $1,000

Estimated Cost of ProjectEstimated Cost of Project $360,000$360,000

Page 20: Estimating Software Development  Using Project Metrics

20

Program Size/Function Program Size/Function PointPoint

Programming LanguageProgramming Language LOC/FPLOC/FP

CC 128128

C++C++ 64 64

COBOLCOBOL 106106

Visual BasicVisual Basic 32 32

SmalltalkSmalltalk 22 22

PowerBuilderPowerBuilder 16 16

SQLSQL 12 12

Page 21: Estimating Software Development  Using Project Metrics

21

Measuring QualityMeasuring Quality

Correctness — the degree to which a Correctness — the degree to which a program operates according to program operates according to specificationspecification

Maintainability—the degree to which a Maintainability—the degree to which a program is amenable to changeprogram is amenable to change

Integrity—the degree to which a Integrity—the degree to which a program is impervious to outside program is impervious to outside attackattack

Usability—the degree to which a Usability—the degree to which a program is easy to useprogram is easy to use

Page 22: Estimating Software Development  Using Project Metrics

22

Defect Removal Defect Removal EfficiencyEfficiency

DRE = (errors) / (errors + defects)

where

errors = problems found before release

defects = problems found after release

Page 23: Estimating Software Development  Using Project Metrics

23

Managing VariationManaging Variation

0

1

2

3

4

5

6

1 3 5 7 9 11 13 15 17 19

Projects

Er, Er

rors

foun

d/

revie

who

urThe mR Control Chart