Lecture 05 Measurement

8/11/2019 Lecture 05 Measurement

1/44

SWENG 580: Advanced Software Engineering

Penn State UniversityLast updated: Wednesday, September 03, 2014

ENGINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

Software Measurement

Need for measurementWhat to measure

Popular metrics

Choosing and using metrics


2/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

2

The Need for Measurement

Main motivations for measurement:Increasing quality.

Reducing cost.


3/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

3

Quality

A quality culture depends upon measurement.

Consider:

Statistical Process Control in manufacturingAve. response time for paramedics

% lost calls for a telephone network

There are two aspects to quality in software eng.quality of the process

quality of the product.


4/44


5/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

5

So What Can We Measure?

Lines of code (LOC)

Paths

Error rates

Defect rates

Change ratesTime spent

Money spent


6/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

6

More Formally...

Size

Complexity

Reliability

Correctness

Flexibility / maintainabilityProgrammer hours/KLOC

Cost/KLOC


7/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

7

Can We Measure Software Goodness?

A metric is only useful if it measures somethingthat is demonstrably good.

But the positive properties of software systemsare qualitative not quantitative, and we dont fullyunderstand how such properties manifestthemselves in measurable quantities.

We really have a 3-layer model.


8/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

8

3-Layer Model of Metrics

Qualitative Attributes:Quality features that may be arbitrarily vague.

Quantitative Factors:Quantitative functions that may be arbitrarily difficult to

compute.

Computable Metrics:Numeric factors that are easy to compute from static/

dynamic analysis.


9/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

9

Qualitative Attributes

integrity; completeness; coherence;

feasibility

maintainability; testability; modifiability;

portability; reusability


10/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

10

Quantitative Factors

Error Propagation.

Change Propagation.

Requirements Propagation.

Design Propagation.

Expectation: that theseenable us to apprehendqualitative attributes.


11/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

11

Computable Metrics Coupling and Cohesion.Static vs DynamicData vs Control

Or any other countsDepth of hierarchyNumber of children

Number of operations added (by children)

Need to understanddifference betweencorrelation and causality!

SWENG 80 Ad d S f E i i


12/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

12

Popular Metrics

McCabes cyclomatic complexity

Function points

Feature points

Cohesion and coupling

SWENG 580 Ad d S ft E i i


13/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVERSITY

13

Cyclomatic Complexity

A graph-theoretic complexity measure that highlightsprogram complexity - lack of modularization (McCabe,1976).

Based upon determining the number of linearly independentpaths in a program module; suggesting that the complexityincreases with this number, and reliability reduces.

This metric has two primary uses:

to indicate escalating complexity in a module as it is codedand therefore assisting the coders in determining the size oftheir modules,

to determine the upper bound on the number of tests thatmust be designed and executed.



14/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

14

Calculating Cyclomatic Complexity (1)

Consider this flowgraph:

a

b c d

e

f

First count the graph eleme

EdgesNodes

Regions



15/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

15



a

b c d

e

f

First count the graph eleme

Edges (E) = 9Nodes (N) = 6

Regions = 5R1

R5

R3 R4

R2



16/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

16


Now, the complexity can be calculated in 3 ways:Complexity, V(G), corresponds to the number of

regions.

V(G) = E - N + 2

Complexity, V(G), is also defined asV(G) = P + 1

where P is the number of predicate nodes



17/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

17



a

b c d

e

f

Complexity for this graph is

No. of regions = 5

V(G) = E-N+2 = 5V(G) = P + 1 = 3R1

R5

R3 R4

R2



18/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

18



a

b c d

e

f

Complexity for this graph

is, then:

No. of regions = 5

V(G) = E-N+2 = 5

V(G) = P + 1 = 5

R1

R5

R3 R4

R2

The 2 predicate nodes each have 3

outputs so have degrees of

freedom of 2 and it is these thatmust be added. In most cases

(especially in Pressman) the

graphs have been reduced until

each predicate node has only two

outputs


19/44



20/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

20

FP - Items and Weights

The five items and there weights are:

No. of inputs to the application x 4

No. of outputs x 5

No. of user inquiries x 4

No. of data files x 10No. of external interfaces x 7



21/44


EN

GINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

21

FP Computation

The following relationship is then used to compute the

FP:

FP= Aix Wi) x [0.65 + 0.01xFj]

where: Aiare the item counts

Wiare the weighting factorsFjare the complexity adjustment factors



22/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

22

Complexity Adjustment Factors

A set of 14 questions that are answered on ascale from 0 to 5 where:

0 no influence1 incidental

2 moderate

3 average4 significant

5 essential



23/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

23

Complexity Adjustment Factors

Does the system require reliable backup and recovery? Are data communications required?

Are there distributed processing functions?

Is performance critical?

Will the system run in an existing, heavily utilized operational environment?

Does the system require on-line data entry? Does the on-line data entry require the input trans. to be built over multiple

screens or operations?

Are the master files updated on-line?

Are the inputs, outputs, files, or inquiries complex?

Is the internal processing complex? Is the code designed to be reusable?

Are the conversion and installation included in the design?

Is the system designed for multiple installations in different organizations?

Is the application designed to facilitate change and ease of use by the user?



24/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

24

LOC Per FP

Assembly 320

C 128

COBOL 106

FORTRAN 106Pascal 90

C++ 64

VB 32Smalltalk 22

SQL 12

Capers Jones:Estimating Software CostsMcGraw Hill, 1998.



25/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

25

Feature Points (1)

Feature points are an extension of function pointsdeveloped by Software Productivity Research, Inc. in1986.

Realized that FP were developed for classicalManagement Information Systems and were, therefore,not particularly applicable to many other systems, suchas:

Real time software, Embedded systems

Communications systems

Process control software



26/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

26

Feature Points (2)

The main reason for this is that these systems exhibit highlevels of algorithmic complexity, but sparse inputs andoutputs. The SPR Feature point method is, then:

Significant parameter Empirical weight

No. of algorithms x 3

No. of inputs x 4

No. of outputs x 5

No. of inquiries x 4

No. of data files x 7No. of interfaces x 7

Unadjusted total

Complexity adjustment

Adjusted feature point total



27/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

27

Object Points

Alternative to function points when 4GLs are

used.

Not Object classes, rather a weighted estimate of:# of separate screens {1|2|3}

# of reports {2|5|8}

# of 3GL modules needed to support 4GL code {10}



28/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

28

Cohesion and Coupling

Cohesion and coupling are two properties of

system models that can be measured during

analysis and design, and reflect how well the modelis being developed.Cohesion: A measure of the closeness of the

relationships within a component.

Coupling: An indication of the strength ofinterconnections between components in a model



29/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

29

CohesionConstantine & Yourdon identified 7 levels of cohesion in order of strength: Coincidental- Parts of module are not related, but simply bundled into a single

module.

Logical- Parts that perform similar tasks are put together in a module

Temporal- Tasks that execute within the same timespan are brought together.

Procedural- The elements of a module make up a single control sequence. Communicational- All elements of a module act on the same area of a data

structure.

Sequential- The output of one part in a module serves as input for some

other part.

Functional- Each part of the module is necessary for the execution of a singlefunction.


30/44



31/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

31

Cohesion and Coupling - Good or Bad?

Generally speaking we strive for high cohesionas this

means that each module represents a single part of the

problem solution. If the system ever needs modification, that part exists in a

single place making it easier to change.

Additionally, we strive for low coupling. This limits the effects of errors in a module (lower ripple-

effect) and reduces the likelihood of data integrity problems.

These are guidelines, however; in most GUIs control

coupling is unavoidable, and indeed desirable!



32/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

32

McCalls Software Quality Factors (1)

Correctness

Reliability

Efficiency Integrity

Usability

Maintainability

Flexibility

Testability Portability

Reusability

Interoperability



33/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

33


Correctnesssatisfies a specification

Reliabilityperforms with precision

Efficiency

utilization of system resources Integritycontrol of access by the unauthorized



34/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

34


Usabilityeffort required to learn, operate, etc.

Maintainabilityeffort required to correct

Flexibility

effort required to modifyTestabilityeffort required to test



35/44


ENGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

35


Portabilitydependency on hardware and operating

environments

Reusabilitydegree to which program can be used in other

applications

Interoperabilityeffort required for 2 systems to communicate



36/44


E

NGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

36

HP FURPS (1)

Functionality

Usability

Reliability

Performance

Supportability



37/44


E

NGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

37

HP FURPS (2)

FunctionalityFeature set and capabilities

Security

UsabilityAesthetics

ConsistencyDocumentation



38/44


E

NGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

38

HP FURPS (3)

ReliabilityFrequency of failure

Mean time between failure

PerformanceProcessing speed

Response timeResource consumption



39/44


E

NGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

39

HP FURPS (4)

SupportabilityExtensibility

Maintainability



40/44


E

NGINEERINGD

IVISION

,PENN

STATE

UNIVE

RSITY

40

Goal/ Question/ Metric

The GQM paradigm is a framework for the systematicspecification of metrics appropriate for an identified needfor an information consumer.

That means, you follow three simple steps that assist in theselection of metrics that meet your goals.

State the goals: what the organization is trying toachieve.

Derive from each goal the questionsthat must beanswered to determine if the goals are being met.

Decide what must be measuredin order to be able toanswer the questions.



41/44


E

NGINEERINGD

IVISION,PENN

STATE

UNIVE

RSITY

41

GQM- Example Goal: Evaluate effectiveness of coding standard. Questions:

Who is using the standard?

What is coder productivity?

What is code quality? Metrics:

Proportion of coders using standard

Experience of coders

Code size (LOC, FP) Effort

Errors



42/44


E

NGINEERINGD

IVISION,PENN

STATE

UNIVE

RSITY

42

Research Areas

Lifecycle metrics

Develop quality metrics that can be used throughout the lifecycle,

not just at the end.

Quality metric interpretationQuality metrics often yield absolute values that are difficult (or

impossible) to interpret: is CC of 21 bad!? Work needs to be done

in applying metrics to various application domains and then

possibly producing some fuzzy-sets to help users determine if aproject is getting out of bounds.



43/44


E

NGINEERINGD

IVISION,PENN

STATE

UNIVE

RSITY

43

Key Points

A quality system must include measurement. This ensures that the

process and products are subject to some quality criteria.

Collecting software metrics must not be an isolated goal. They must

be part of an overall strategy for software product and processimprovement.

Metrics are also used to measure productivity; but this can

sometimes be misleading.

Software engineering is struggling with the use of metrics. Thequestions of what to measure, how to measure and what to do with

the results are still unresolved. Further work is needed.



44/44


NGINEERINGD

IVISION,PENN

STATE

UNIVE

RSITY

References

Pressman, R. Software Engineering: A Practitioners Approach, New

York, NY: McGraw-Hill, 6thEd, 2004.

Grady, R. Practical Software Metrics for Project Management &

Process Improvement, Englewood Cliffs, NJ: Prentice Hall, 1992.

Lecture 05 Measurement

Documents

Transcript of Lecture 05 Measurement