Software Metrics

Software Metrics

Prof. Wei T. Huang

Department of Computer Science and

Information Engineering

National Central University

2007

Prerequisites

Software Engineering

z

Object-Oriented Software Engineering

Engineering Mathematics

z Note:

– This lecture note is developed for the teaching purpose and is only offered to the senior and graduate students at the National Central University. Any commercial activity using this note is not allowed.

– Most of the materials in this lecture note, including the text, the tables, and the figures, are excerpted from the sources given in the References, especially from [Fenton97].

Objective for Software Measurement

Measurement helps people to understand the world. Without

measurement you cannot manage anything.

z

There are three important activities in software development project:

– Understanding what is happening during development and maintenance – Controlling what is happening on the projects

– Improving the processes and products

z

Thus, people must control their projects and predict the product

attributes not just run them. But

– “You cannot control what you cannot measure.” (DeMarco, 1982) – “You can neither predict nor control what you cannot measure.”

Software Measurement

Software Developers get sense of

– whether the requirements are consistent and complete – whether the design is of high quality

– whether the code is ready to be tested

z

Project Managers measure

– attributes of process

– whether product will be ready for delivery – whether the budget will be exceeded

z

Customers measure

– whether the final product meets the requirements – whether the product is of sufficient quality

z

Maintainers must be able

1.1 What is Measurement? (1)

z

Measurement is essential to our daily life. It is the process by which

numbers or symbols are assigned to attributes of entities in the real

world in such a way as to describe them according to clearly defined

rules.

– Entity: an object or an event in the real world

• A person, a room; a journey; the testing phase of a software project – Attribute: a feature or property of an entity

• The area or color of a room; the cost of a journey; the elapsed time of a testing phase

1.1 What is Measurement? (2)

“What is not measurable make measurable.” (Galileo)

– In the physical science, medicine, economies, and even some social science, we are now able to measure attributes that were previously thought unmeasurable.

• Human intelligence, air quality, and economic inflation form the basis for important decision that affect our everyday life.

• Questions: (1) How can you measure to identify the best (or good) individual soccer player? (2) How can you identify good or bad software developer?

z

There are two kinds of qualification:

– Measurement: a direct quantification

• Examples: the height of a tree or the weight of a shipment of bricks – Calculation: a indirect quantification

z

So, a software engineer may continue to claim that important

software attributes, such as dependability, quality, usability and

maintainability, in order to make software engineering as powerful

1.2 Measurement in Software Engineering

For most software development projects, we

– Fail to set measurement targets for our software products.

• Gilb’s Principle of Fuzzy Target: projects without clear goals will not achieve their goals clearly.

– Fail to understand and quantify the component costs of software projects.

– Do not quantify or predict the quality of the products we produce.

– Do without a carefully controlled study to determine if the technology is sufficient and effective.

1.3 Understand and Control a Project (1)

z Information needed to understand and control a software development

project:

z Managers

– What does each process cost? – How productive is the staff?

– How good is the code being developed? – Will the user be satisfied with the product? – How can we improve?

z Engineers

– Are the requirements testable? – Have we found all the fault?

– Have we met our product or process goals? – What will happen in the future?

Understand and Control a Project (2)

Measurement is important for three basic activities:

– Measures help us to understand what is happening during

development and maintenance – establishing baselines to set goals for future behavior;

– The measurement allows us to control what is happening on our projects – predicting what is likely to happen and make changes to processes and products in order to meet the goals;

– Measurement encourages us to improve our process and products – increasing the number or type of design reviews, for instance.

1.4 The Scope of Software Metrics (1)

z

Cost and effort estimation

– Examples: COCOMO model (Beohm, 1981), SLIM model (Putnam, 1978), Albrecht’s function point model (Albrecht, 1979)

z

Productivity measurements and models

Productivity

Value Cost

Quality Quantity

Reliability Defects Size Functionality

Personnel Resources Complexity

1.4 The Scope of Software Metrics (2)

z Data collection

– The collected data distilled into simple graphs or charts

z Quality models and measures

– Product operation: usability, reliability, efficient

– Product revision: maintainability, portability, testability

z Reliability model

z Performance evaluation and models z Structural and complexity metrics z Management metrics

– Using measurement-based charts or graphs to help customers and developers decide if the project is on track.

z Evaluation of methods and tools

– New methods and tools that may make the organization or project more productive and the products better and cheaper.

Exercises

z

What are metrics? Name the reason why metrics are useful.

Specifications, design and code are entities of software

products.What are the attributes of those entities?

– Hint: see next chapter.

z

Personnel is one of the resources for software development.

Suppose you are a manager. What do you want to measure such an

entity?

2.1 Classifying Software Measures (1)

Software-measurement activity is identifying the entities and

attributes.

– Process: collections of software-related activities • The duration of the process or one of its activities.

• The effort associated with the process or one of its activities.

• The number of incidents of a specified type arising during the process or one of its activities.

– Products: any artifacts, deliverables or documents that result from a process activity.

• External product attributes depending on product behavior and environment: reliability, usability, integrity, efficiency, testability, reusability, portability and interoperability are attributes that we can measure.

• Internal product attributes: size, effort, cost, code complexity, structuredness, module coupling and cohesiveness.

2.1 Classifying Software Measures (2)

– Resources: entities required by a process activity.

• Personnel (individual or team), materials, tools (software and hardware), methods are candidates for measurement.

• Cost and productivity ( = amount of output/effort input) • Staff: experience, age, or intelligence, …

– Attributes

• Internal attributes: measured by examining the product, process or resource its own.

2.1 Classifying Software Measures (3)

Components of software measurement

Entities Attributes

Product Internal External

Specifications size, reuse, modularity, comprehensibility, redundancy, functionality, maintainability, etc. syntactic correctness, etc.

Design size, reuse, modularity, quality, complexity, coupling, cohesiveness, maintainability, etc functionality, etc.

Code size, reuse, modularity, reliability, usability, coupling, functionality, maintainability, etc. algorithmic complexity,

2.1 Classifying Software Measures (4)

Process

Constructing time, effort, number of quality, cost, stability, etc. specification requirements changes, etc.

Detailed design time, effort, number of cost, cost-effectiveness, etc. specification faults found, etc.

Testing time, effort, number of coding cost, cost-effectiveness, stability, etc. faults found, etc.

Resources

Personnel age, price, etc. productivity, experience, intelligence, etc. Teams size, communication level, productivity, quality, etc

structuredness, etc.

Software price, size, etc usability, reliability, etc. Hardware price, speed, memory size, etc. reliability, etc.

2.2 Determine What to Measure (1)

The Goal-Question-Metric (GQM) paradigm

In order to decide what your project should measure, you may use

GQM paradigm. The following high-level goals may be identified.

– Improving productivity – Improving quality

– Reducing risk

z

Templates for goal definition

– Purpose

• Example: To evaluate the maintenance process in order to improve it – Perspective

• Example: Examine the cost from the viewpoint of the manager – Environment

• Example: the maintenance staff are poorly motivated programmers who have limited access to tools

2.2 Determine What to Measure (2)

A framework of GQM

– List the major goals of the development or maintenance project. – Derive from each goal the questions that must be answered to

determine if the goals are being met.

– Decide what must be measured in order to be able to answer the questions adequately.

2.2 Determine What to Measure (3)

2.2 Determine What to Measure (4)

z

Examples of AT&T goals, questions and metrics (Barnard and Price

2.3 Applying the Framework (1)

Cost and effort estimation

– Focusing on predicting the attributes of cost or effort for the development process.

z

Productivity measures and model

– Measuring a resource attribute.

z

Data collection

– Gathering accurate and consistent measures of process and resource attributes.

z

Quality model and measures

– Predicting product model – cost and productivity are dependent on the quality of products output during various processes.

– Measuring internal product attributes: such as complexity and structure – Measuring external product attributes: attributes with respect to how the

2.3 Applying the Framework (2)

Reliability model

– Successful operation during a given period of time.

z

Performance evaluation and models

– Measuring efficiency of the product.

z

Structural and complexity metrics

– Measuring internal attributes of products which suggest what the external measures might be.

z

Capability-maturity assessment

2.3 Applying the Framework (3)

Management by metrics

– Use metrics to set targets for the development projects. – Example: US defense projects (NetFocus 1995)

Item Target Malpractice level

Defect removal efficiency > 95% < 70%

Original defect density < 4/function point > 7/function points (*)

Slip or cost overrun in excess 0% > 10% of risk reserve

Total requirements creep < 1%/month > 50% (function points or equivalent) average

Total program documentation < 3 pages/function > 6 pages/function point point

2.3 Applying the Framework (4)

Evaluation of methods and tools

– Using the proposed tool or method on a small project at first, and evaluating the results

– Example: Code inspection statistics from AT&T (Barnar and Price 94)

Metric First sample Second sample

project project Number of inspections in sample 27 55

Total KLOC inspected 9.3 22.5

Average LOC inspected (module size) 343 409 Average preparation rate (LOC/hour) 194 121.9 Average inspection rate (LOC/hour) 172 154.8 Total faults detected (observable and 106 89.7

non-observable)/KLOC

2.4 Software Measurement Validation (1)

The measurement pattern.

2.4 Software Measurement Validation (2)

Two types of measuring

– Measures or measurement systems: used to assess an existing entity by numerically characterizing one or more its attributes.

– Prediction systems: used to predict some attribute of a future entity involving a mathematical model with associated prediction procedure

z

Validating prediction systems

– Deterministic prediction systems: always get the same output for a given input

– Stochastic prediction systems: the output for a given input will vary probabilistically

– Example: Using COCOMO (to be explained later) • Acceptance range within 20% for predicted effort

z

Validating software measures

– Measures should reflect the behavior of entities in the real world. – Example: program length

Exercises

z

You are now taking the course “Software Metrics”. What are the

goals you take this course.

– Hints: Using the template of goal definitions

z

Use the GQM approach to explain the reason you take the

3. Measuring Internal Product

Attributes (1)

3.1 Measuring Size (1)

z

Simple measures of size are often rejected because they do not

adequately reflect:

– Effort

– Productivity – Cost

z

The important aspects (attributes) of software size

– Length: physical size ( including specifications, design and final code) – Functionality: functions supplied by the product to the user

3.1 Measuring Size (2)

– Complexity: underline problem that the software is solving • Problem complexity: the complexity of the underlying problem

• Algorithmic complexity: the complexity of the algorithm to solve the problem (measuring the efficient of the software)

• Structural complexity: the structure of the software used to implement the algorithm

• Cognitive complexity: the effort required to understand the software

– Reuse: how much of a product was copied or modified from a previous version of an existing product (including off-the-shell products).

3.2 Software Size (1)

Software size

– Specification

• a useful indicator of how the design is likely to be – Design

• a predictor of code length – Code

3.2 Software Size (2)

Traditional code measures

– Number of line of code (LOC)

– HP definition: NCLOC (non-commented line) or ELOC – Total length (LOC) = NCLOC + CLOC

3.3 Software Science (1)

Maurice Halstead’s software science

– A program P is a collection of tokens. – Tokens are

μ₁ = number of unique operators μ₂ = number of unique operands

N₁= total occurrences of operators N₂ = total occurrences of operands – The length of P: N = N₁ + N₂

– The vocabulary of P: μ = μ₁ + μ₂

– The volume of P (a suitable metric for the size of any implementation of any algorithm): V = N × ㏑ μ

– The program level of P of volume V (the implementation of an algorithm) : L = V*/V (L ≦ 1),

3.3 Software Science (2)

– The difficulty: D = 1/L

– The estimate of L: Ĺ = 1/D = (2/μ₁) × (μ₂/N₂)

– The estimated program length: Ń = μ₁ × ㏑ μ₁ + μ₂ × ㏑ μ₂

– The effort required to generate P: E = V/ Ĺ = μ₁ N₂ N ㏑ μ / 2 μ₂ where the unit of measurement of E is elementary mental

discriminations needed to understand P. John Stroud claimed that the human mind is capable of making a limited number ß of elementary discriminations per second, thus, 20≥ ß≥5. Halstead claimed that ß = 18. So the time required for programming is

3.3 Software Science (3)

Halstead’s sample FORTRN program

SUBROUTINE SORT (A, N)

INTEGER A(100), N, I, J, SAVE, M

C ROUTINE SORTS ARRAY A INTO DESCENDING ORDER IF (N.LT.2) GOTO 40

DO 30 I = 2, N N = N₁ + N₂ = 93 M = I – 1 μ= μ₁ + μ₂ = 27

DO 20 J = 1, M V = N × ㏑μ= 93 × 4.75 = 442 bits IF (A(I).GT.A(J)) GOTO 10 V* = 11.6 bits (V > V*)

GOTO 20 L = V*/V = 11.6/442 = 0.026 10 SAVE = A(I) D = 1/L = 38.5

A(I) = A(J) Ĺ = 1/D = (2/μ₁) × (μ₂/N₂) = (2/14) × (13/42) = 0.044 A(J) = SAVE E = V/Ĺ = 442/0.044 = 10045

20 CONTINUE T = E/β = 10045/18 = 558 seconds = 10 minutes 30 CONTINUE

3.4 “Object” Programming Environment (1)

An example

– In the Visual Basic™ programming environment, you can create a sophisticated Windows program, complete with menus, icons, and graphic, with almost no code in traditional sense. For example, you point at a scrollbar object in the programming environment. In this

environment, the executable code to produce a scrollbar is constructed automatically. You need to write code only to perform the specific

actions that result from a click on a specific command button. In this kind of environment, it is not clear how you would measure length of the “program”. Thus, a program with just five BASIC statements, say, can easily generate an executable program of 200 Kb. This is the same case by using component-based software construction technique.

z

There are two separate measurement issues

– How do we account in our length measures for objects that are not textual?

3.4 “Object” Programming Environment (2)

In object-oriented development, a count of objects and methods led

to more accurate productivity estimates than those using lines of

code (Pfleeger 1989).

z

“Ontological principles” (Bunge’s ontological terms)

– Two objects are coupled if and only if at least one of them acts upon the other. X is said to act upon Y if the history of Y is affected by X.

(*) Ontology: the common words and concepts (the meaning) used to describe and represent an area of knowledge. Suppose you look up ontology in the dictionary, you will find that the metaphysics are: (1) A branch of philosophy that seeks to explain the nature of being and reality; (2) speculative philosophy in general (Webster’s New World Dictionary).

3.4 “Object” Programming Environment (3)

The Metrics Suite for OOD [Chidamber/Kemerer] using the notion

mentioned above.

– Metric 1. Weighted Methods Per Class (WMC) = ∑ c_i (i=1 to n)

where consider a Class C, with methods M₁…..M_n that are defined in the class. c_i…..c_n be the complexity of the methods. If all method

complexities are considered to be unity, then WMC = n, the number of methods.

– Metric 2. Depth of Inheritance Tree (DIT): The length from the node to the root of the inheritance tree.

3.4 “Object” Programming Environment (4)

– Metric 3. Number of Children (NOC): The number of immediate successors of the class.

– Metric 4. Coupling between Object Classes (CBO): The number of other classes to which the class is coupled.

– Metric 5. Response for Class (RFC): The number of local methods plus the number of methods called by local methods.

– Metrics 6. Lack of Cohesion Metric (LCOM): The number of non-intersecting of local methods.

3.5 Specification and Design (1)

z

A document of specification and design may consist of both text and

diagrams, where diagrams have a uniform syntax, such as DFD,

Z-schema or class diagrams. We can define appropriate atomic

objects for the different type of diagrams and symbols.

z

The well-known method for handle these atomic objects, for

instance:

– For data flow diagram, the atomic objects are process, external entities, data stores, and data flows.

– For algebraic specification, the atomic entities are sorts, functions, operations, and axioms, etc.

– For Z schemas, the atomic entities are various lines appearing in the specification, such as type declaration or a predicate.

3.5 Specification and Design (2)

Example: Structured analysis components (DeMarco 1978)

View Diagram Atomic objects Functional Data flow diagram Bubbles

Data dictionary Data elements Data Entity relation diagram Objects, relations State State transition diagram States, transitions

Supplement to Section 3.5 (1)

Supplement to Section 3.5 (2)

Algebraic specification: Coord as an example

COORD Spec Name → (Generic Parameter) sort Coord sort <name>

Imports INTEGER, BOOLEAN imports <List of Spec Name>

Create (Integer, Integer) → Coord;

X (Coord) →Integer; Operation signatures setting out the names

Y (Coord) →Integer; and the types of the parameters to the operations Eq (Coord, Coord) → Boolean; defined over the sort

X (Create (x,y)) = x Y (Create (x,y)) = y

Supplement to Section 3.5 (3)

z

Z schema: a Phone DB as an example

Δ Phone DB

members, members’: P Person

telephones, telephones’ : Person ↔ Phone dom telephones ⊆ members

dom telephones’ ⊆ members’

Δ state

declaration

predicate

new state

telephones’ = telephones ∪ {huang |→ 0543}

3.6 Predicting Length

Example: Halstead’s software science

LOC = N / c_k

where c_k is a constant depending on programming language K, for

FORTRAN c_k = 7. The example in slid 48, N = 93, LOC = 93/7 ≈ 13. It is 16 in fact, so,13 is a reasonable estimate.

z

Length may be predicted by considering the median expansion ratio

from spec or design length to code length

Expansion ratio (design to code) = size of design / size of code

z

For the module design phase:

LOC = α ∑ S_i (i = 1 to m)

where S_i is the size of module i, m is the number of modules, and α is the design-to-code expansion ratio

3.7 Reuse (1)

z

The reuse of software (including requirements, designs,

documentation, test data, scripts, code, etc.) improves the

productivity and quality, allowing the developer to concentrate on

new problems.

z

HP’s example (Lim 1994):

Organization Manufacturing productivity San Diego technical graphics Quality 51% defect reduction 24% defect reduction

Productivity 57% increase 40% increase Time to NA 42% reduction

market

z

Extent of reuse (NASA/Goddard’s SE Lab.)

– Reused verbatim: the code in the unit reused without any change – Slightly modified: fewer than 25% of lines of code in the unit modified – Extensively modified: ≥ 25% of the lines of code modified

3.7 Reuse (2)

Example: Software Engineering Laboratory

– 20% reused lines of code – 30% reused lines of Ada code

z

Reuse at HP

non-3.7 Reuse (3)

Example: Programming Research Ltd.

Product (%) Reusable LOC Total LOC Reuse ratio QAC 40 900 82 300 50

QA Fortran 34 000 73 000 47 QA Manager(X) 18 300 50 100 37 QA Manager (Motif) 18 300 52 700 35

3.8 Functionality (1)

z

Albrecht’s approach: Function points that are intended to measure

the amount of functionality in a system as described by a

specification. Using the following items of types to compute an

unadjusted function point count (UFC):

– External inputs: items provided by the user that describe distinct application-oriented data (such as files), not including inquiries. – External output: items provided to the user that generate distinct

application-data (such as reports and messages).

– External inquiries: interactive inputs requiring a response. – External files: machine-readable interfaces to other systems. – Internal files: logical master files in the system.

3.8 Functionality (2)

Unadjusted function point (FP) count, UFC

– FP complexity weight (w_i):

Item Low Medium High Complexity Complexity Complexity

External inputs 3 4 6

External outputs 4 5 7

External inquiries 3 4 6

External files 7 10 15

3.8 Functionality (3)

Example: A simple spelling checker.

– The DFD

A = # external inputs = 2, B = # external outputs = 3, C = # inquiries = 2, D = # external files = 2, E = # internal files = 1

3.8 Functionality (4)

z

For the example of the spelling checker, the items are identified as

follows:

– 2 external inputs: document filename, personal dictionary-name – 3 external outputs: misspelled word report, # of words processed

message, # of errors message

– 2 external inquiries: words processed, errors

– 2 external files: document file, personal dictionary – 1 internal file: dictionary

3.8 Functionality (5)

The complexity rates: simple, average, or complex

z

For the spelling checker example, we assume that the complexity is

average, then

UFC = 4A +5B +4C +10D +10E = 61

z

If the dictionary file and the misspelled word report are complex,

then

UFC = 4A + (5 × 2 + 7 × 1) + 4C + 10D + 10E = 63

z

Technical complexity factor, TCF = 0.93 (0.65 to 1.35 see next slide)

for the spelling checker, then

FP = 63 × 0.93 = 59

z

What is the FP for? Suppose a task takes a developer an average of

two person days of effort to implement a function point. Then we

may estimate the effort to complete the spelling checker is 118

person days (59 × 2).

3.8 Functionality (6)

Converting from function points to lines of code.

– Programming language statements per function point

Minimum Mode Maximum

(- 1 standard (most common (+ 1 standard Language deviation) value) deviation)

C 60 128 170 C# 40 55 80 C++ 40 55 140 Java 40 55 80 Smalltalk 10 20 40 Visual Basic 15 32 41

3.8 Simplified FP Techniques

The Durch method.

IndicativeFunctionPointCount =

(35 x Internal files) + (15 x External files)

The numbers 35 and 15 are derived through calibration. However,

you can come up with your own calibrations for use in your

environment.

– Use the Dutch Method of counting function points to attain a low-cost ballpark estimate early in the project.

– Example: For the spelling checker UFC = 35 x 1 + 15 x 2 = 65

Supplement to Section 3.8

z Components of the technical

complexity factors:

F₁ Reliable back-up and recovery

F₂ Data communications

F₃ Distributed functions

F₄ Performance

F₅ Heavily used configuration

F₆ Online data entry

F₇ Operational ease F₈ Online update F₉ Complex interface F₁₀ Complex processing F₁₁ Reusability F₁₂ Installation ease F₁₃ Multiple sites F₁₄ Facilitate change TCF = 0.65 + 0.01 F_i

For the spelling checker:

− F₃F₅F₉F₁₁F₁₂ F₁₃ are 0 (sub-factor is irrelevant),

− F₁F₂F₆F₇F₈F₁₄ are 3 (average)

F₄ and F₁₀ are 5 (it is essential to the systems being built). So,

TCF = 0.65 + 0.01(18 + 10) = 0.93

∑

3.9 Complexity

We define

– Complexity of a problem: the amount of resources required for an optimal solution to the problem.

– Complexity of a solution: be regarded in terms of the resources needed to implement a particular solution.

• Time complexity: where the resource is computer time

• Space complexity: where the resource is computer memory

z

In order to measure and express complexity, we measure the

efficiency of a solution, that is, measuring algorithmic efficiency.

– Example: Binary search

• For a list of n elements, the binary search algorithm terminates after at most (㏑ n) comparisons.

z

Big-O notation

– Example: the problem of searching a sorted list for a single item can be shown to have complexity O(㏒ n), that is, the fastest algorithm necessary to solve the problem requires at least (㏒ n).

Exercise

1.

Explain very briefly the idea behind Albrecht’s function points

measure.

2.

List the main applications of function points.

4. Measuring Internal Product

Attributes (2)

4.1 Structure

z

The structure of requirements, design, and code may help the

developers to understand the difficulty they sometimes have in

converting one product to another, in testing a product, or in

predicting external software attributes from early internal product

measures, such as maintainability, testability, reusability, and

reliability.

z

The structure of a product plays a part, not only in requiring

development effort but also in how the product is maintained.

z

Types of structural measures

– Control-flow structure: the sequence in which instructions are executed in a program.

– Data-flow structure: the trail of a data item created or handled by a program.

– Data structure: the organization of the data itself, independent of the program.

4.2 Control-Flow Structure (1)

McCabe’s cyclomatic complexity measure

– Definition: The cyclomatic number V(G) of a graph G with n vertices, e edges, and p connected components is

V(G) = e – n ＋ p

– Theorem: In a strongly connected graph G, the cyclomatic number is equal to the maximum number of linearly independent circuits.

4.2 Control-Flow Structure (2)

Properties of cyclomatic complexity

– V(G) ≧ 1

– V(G) is the maximum number of linearly independent paths in G; it is the size of a basis set.

– Inserting or deleting functional statements to G does not affect V(G). – G has only on path it and only if V(g) = 1.

– Inserting a new edge in G increases V(G) by unity. – V(G) depends only on the decision structure of G.

z

The control graphs of the usual constructs in structured

4.2 Control-Flow Structure (3)

z

The cyclomatic number is a useful indicator of how difficult a

program or module will be to test and maintain. When V exceeds 10

in any one module, the module may be problematic.

z

Example: Channel Tunnel Rail System

– The module be rejected if its V exceed 20 or if it has more than 50 statements (Bennet 1994).

4.3 Modularity and Information Flow Attributes (1)

z

Module: a contiguous sequence of program statements, bounded by

boundary elements, having an aggregate identifier (Yourdon and

Constantine 1979).

– A module can be any object.

– A program, unit, procedure, or function.

z

Inter-module attributes.

4.3 Modularity and Information Flow Attributes (2)

z

Module call-graph: an abstract model of the design.

– Module a calls b, c – Module b calls d – Module c calls d, e

4.3 Modularity and Information Flow Attributes (3)

z

Coupling is the degree of interdependence between modules

(Yourdon and Constantine 1979).

z

Classification for coupling (R

> R

for i > j):

– R₀: module x and module y have no communication.

– R₁ Data coupling relation: x and y communicate by parameters, where each parameter is either a single data element or a homogeneous set of data items (no control element). This type of coupling is necessary for any communication between modules.

– R₂ Stamp coupling relation: x and y accept the same record type as a parameter.

– R₃ Control coupling relation: x passes a parameter (flag) to y with the intention of controlling its behavior.

– R₄ Common coupling relation: x and y refer to the same global data. – R₅ Content coupling relation: x refers to the inside of y

4.3 Modularity and Information Flow Attributes (4)

z

Example: Coupling-model graph

– Level: (n.m)

• n means coupling relation Ri m is parameter (flag)

– M₁ and M₂ share two common record types: R₂

– M₁ passes to M₃ a parameter that acts as a flag in M₃: R₁

– M₂ branches into module M₄ and passes two parameters that act as flags in M₄: R₃ and R₅

z

Measuring coupling between x and y: c(x, y) = i + n/(n+1), where i is

the number corresponding to the worst coupling relation R

between

x and y, and n is the number of interconnections between x and y

4.3 Modularity and Information Flow Attributes (5)

z

Cohesion (Yourdon and Constantine 1979):

– Functional: the module performs a single well-defined function. – Sequential: the module performs more than one function.

– Communication: the module performs multiple functions, but not on the same body of data.

– Procedural: the module performs more than one function, and they are related only to a general procedure.

– Temporal: the module performs more than one function within the same time span.

– Coincidental: the module performs more than one function, and they are unrelated.

z

Cohesion ratio

4.3 Modularity and Information Flow Attributes (6)

z

Information flow (Henry-Kafura’s measure 1981).

Information flow complexity = length (M) x ((fan-in(M) x fan-out(m))2

4.4 Data Structure

The amount of data

– Halstead’s software science:

μ₂ (# of distinct operands) or N₂ (total number of occurrences of operands) as the data measure

– COCOMO (Constructive Cost Model):

D/P = Database size in bytes or characters/Program size in DSI where DSI is the number of delivered source instructions.

Data Multiplier Low (D/P < 10) 0.94 Nominal (10≦D/P<100) 1.00 High(100≦D/P<1000) 1.08 Very high(D/P≧1000) 1.16 Example:

• If DATA is rated “very high”, then the cost of a project is increased by 16%. • If DATA is low, the cost is reduced to 94%.

Exercises

1.

The following flowgraph is a truly unstructured “spaghetti” prime.

What is the essential complexity.

2.

“A good design should exhibit high module cohesion and low

module coupling.” Briefly describe what you understand this

assertion to mean.

3.

McCabe’s cyclomatic number is a classic example of a software

metric. Which software entity and attribute do you believe it really

measures?

5. Measuring External Product

Attributes

5.1 External Attributes

External attributes

– Software quality – Quality impacts:

z

Predicting external attributes via measuring and analyzing internal

attributes, because

– The internal attributes are often available for measurement early in the life cycle, whereas external attributes are measurable only when the product is complete.

– Internal attributes are often easier to measure than external ones.

Quality

Functionality

5.2 Quality Model

ISO 9126 standard

5.3 Definitions (1)

z

Functionality: the functions supplied by the product to the user

Portability

:

“A set of attributes that bear on the capability of software to be transferred from one environment to another.”

Portability = 1 – ET/ER

where ET is a measurement of the resources needed to move the

system to the target environment, and ER is a measure of the resources needed to create the system for the resident environment.

5.3 Definitions (2)

Reliability

：

”A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions and a stated period of time.”

defect density = # of known defects/product size

where product size is measured in terms of LOC, and the known defects are discovered through testing, inspection or other techniques.

z

Other quality measures

system spoilage = time to fix post-release defects

/total system development time

5.3 Definitions (3)

Efficiency.

– Example: Suppose we implement the Heapsort sorting algorithm in a machine environment where comparison operations are performed at the rate of 220_{/sec. If we sort a list of n = 2}25 _{items, we need nln(n) (n=25}

in this case) comparisons, that is, we need 25 x 225 _{comparisons. The}

response time of the machine must at leat 800 seconds (13.3 minutes). – In software, the efficiency can be expressed by the response time.

5.3 Definitions (4)

Usability:

The extent to which the software product is convenient and practical to use (Boehm 1978). Good usability includes:

– Well-structured manuals

– Good use of menus and graphics – Information error messages

– Help function

5.3 Definitions (5)

Maintainability:

Many measures of maintainability are expressed in term of MTTR (mean time to repair). Records needed to calculate this measure:

– Problem recognition time – Administrative delay time

– Maintenance tools collection time – Problem analysis time

– Change specification time

– Change time (including testing and review)

z

The guideline: Cyclomatic number < 10.

z

Thus, maintainability in a real software system is affected by a wide

Exercise

z

The most commonly used software quality measure in industry is

the number of faults per thousand lines of product source code.

Compare the usefulness of this measure for developers and users.

List some possible problems with this measure.

6. Software Reliability

• Software reliability is a key concern of many users and developers of software.

• Reliability is defined in terms of failures; it is impossible to measure before development is complete. However, there are

several software reliability growth models may aid the estimation, by carefully collecting data on inter-failure times.

6.1 Probability Density Function (1)

z

Probability density function (pdf) f(t) describes the uncertainty about

when the component will fail :

Probability of failure between t₁ and t₂ =

∫

t₁ t₂

6.1 Probability Density Function (2)

– Example: Uniform pdf f(t) = 1/x for t ε [0, x] , failure time is bounded • Example: t ε[0,t]

A component has a maximum life span of 10 hours, e.g., it is certain fail within 10 hours of use. Suppose that the component is equally likely to fail during any two time periods of equal length within the 10 hours. It is just as likely to fail in the first two minutes as in the last two minutes. We can

illustrate this behavior with the pdf f(t) as shown in the above figure. The function is defined to be 1/10 for any t between 0 to 10, and 0 for any t>10. We say it is uniform in the interval of time from t=0 to t=10. For any x we can define the uniform pdf over the interval [0,x] to be 1/x for any t ime the

6.1 Probability Density Function (3)

– Example: Failure time occurs purely randomly, that is, failure is

statistically independent of the past. The following figure shows the pdf:

f(t) = λe –λt

• The component fails in a given interval [t₁,t₂]. Probability of failure between time t₁ and t₂ = ∫f(t) dt tε[t₁, t₂]

• For example, the probability of failure during time 0 and time 2 hours is: 1-e2λ _{when λ=1 this probability failure = 0.63, when λ=3, it is equal to 0.998}

6.1 Probability Density Function (4)

z

The distribution function. The probability of failure from time 0 to a

given time t, that is, the cumulative density function F(t) is the

probability of failure between time 0 and t.

F(t) = ∫f(t) dt where t ε[0,t]

z

The reliability function (called the survival function).

6.1 Probability Density Function (5)

z

Example: Distribution function and reliability function for uniform

density function: Consider the pdf that is uniform over the interval

[0,t]. Then f(t) = 1 for each t between 0 and 1. The cumulative

density function F(t) and the survival function R(t) are shown as

follows:

F(t)

=

∫

∫

t

0 0

6.1 Probability Density Function (6)

z

Example: Distribution function and reliability function for f(t) = λe

.

6.2 Mean Time to Failure (1)

z

The mean time to failure (MTTF): the mean of the probability density

function, or called expected value E(t) of T:

E(T) = ∫tf(t)dt

z

Examples:

– For the uniform pdf: 1/x, the MTTF is 5 hours.

– For the pdf as the exponential function: f(t) =

_{, the MTTF is}

6.2 Mean Time to Failure (2)

To fix failure after each occurrence:

6.2 Mean Time to Failure (3)

z

Reliability growth: the new component should fail less than the old

one, that is, the mean f

> f

z

Mean time between failure (MTBF) = MTTF +MTTR, where MTTR

us the mean time to repair.

z

Availability: the probability that a component is operating at a given

point in time

Exercises

1.

Why is reliability an external attribute of software?

2.

List three internal software product attributes that could affect

reliability.

3.

Suppose you can remove 50% of all faults resident in an operational

software system. What corresponding improvements would you

7.1 Productivity (1)

Productivity

– Productivity equation:

productivity = size(lines of code)/effort (person-months) • Difficulty of measuring effort

– Measuring productivity based on function-points

# of function points implemented/person months • Function points: a review

External inputs, External output, External inquiries, External files, Internal files

• The function-based measure more accurately reflects the value of output • It can be used to assess the productivity of software development staff at

any stage in the life cycle

• Measuring progress by comparing completed function points with incomplete ones

7.1 Productivity (2)

z

Example: Distribution of US software project size in function points

(Jones, 1991)

Application size in function points

7.1 Productivity (3)

z

Productivity ranges and modes for selected s/w project sizes

Productivity rate 100 FPs 1000 FPs 10000 FPs in FP per P-M >100 1.0 % 0.01 % 0.0 % 75-100 3.0 % 0.1 % 0.0 % 50-75 7.0 % 1.0 % 0.0 % 25-50 15.0 % 5.0 % 0.1 % 15-25 40.0 % 10.0 % 1.4 % 5-15 25.0 % 50.0 % 13.5 % 1-5 10.0 % 30.0 % 70.0 % <1 4.0 % 4.0 % 15.0 %

7.2 Method and Tool (1)

z

The original COCOMO model

is included two cost drivers:

– Use of software tools

– Example: For the project rated “low” in use of tools, COCOMO includes an 8% increase in project effort compared to the “normal” (value 1.00) use of tools.

7.2 Method and Tool (2)

– Use of modern programming practices

Exercise

z

Other than personnel, which software development resources can

be assessed in terms of productivity? How would you define and

measure productivity for these entities?

Good Estimates

z

The process predictions guide the decision-making, from before the

development begins, through the development process, during the

transition of product to customer, and while the software is being

maintained.

8.1 Making Process Predictions

What is an estimate?

– An ideal case: the probability density is normal distribution.

– For example, the probability of completing the project in

[8 months,16months] is 0.9, while in less than 12 months is 0.5

Estimate (median)

Number of months to complete project

Estimate (median)

8.2 Models of Effort and Cost

z

Regression-based models: E = (aS

)F (without adjusting log E = log

a + b log S)

– Low experience (say <8years): F = 1.3 (F is the effort adjustment factor) Medium experience (8 – 10 years): F = 1.0

8.3 COCOMO – Effort (1)

z

Constructive Cost Model (Barry Boehm, 1970s), there are three

models:

– Basic model: when little about the project is known. – Intermediate model: after requirements are specified. – Advanced model: when design is complete.

E = aSb _F

where E is effort in person months, S is size in thousands of delivered source instruction (KDSI), F is an adjust factor (= 1 in the basic model).

8.3 COCOMO – Effort (2)

The values of a and b depend on the development mode:

– Organic system: data processing (using databases and focusing on transactions and data retrieving), e.g., banking and accounting system. – Embedded system: real-time software, e.g., a missile guidance system. – Semi-detached system: between organic and embedded system.

Mode a b

Organic 2.4 1.05 Semi-detached 3.0 1.12 Embedded 3.6 1.20

z

Example: Telephone switching system. E = 3.6 (5000)

≈ 100 000

P-M (the system will require approximately 5000 thousand of

delivered source instructions – KDSI)

8.3 COCOMO – Effort (3)

Cost drivers for original COCOMO

Product attributes: Required software reliability Database size

Product complexity

Process attributes: Use of modern programming practices Use of software tools

8.3 COCOMO – Effort (4)

Resource attributes:

Computer attributes: Execution time constrains Main storage constrains Virtual machine volatility Computer turnaround time Virtual machine experience Personnel attributes: Analyst capability

Applications experience Programming capability Language experience

8.4 COCOMO - Duration

The duration model: D = a E

where D is duration in months, E is effort in person months. The coefficients depend on the development mode.

Mode a b

Organic 2.5 0.38 Embedded 2.5 0.35 Semi-detached 2.5 0.32

z

Suppose the development time for a 3000 person months

embedded project:

2.5 (3000)0.35 _{= 52 months}

That is, the project requires 58 (≈3000/52) staff working for 52 months to complete the software.

8.5 COCOMO II (1)

z

Boehm and his colleagues have defined an updated COCOMO,

called COCOMO II, because COCOMO is inflexible and inaccurate

for new techniques, such as use of tools, reengineering, application

generators, object-oriented approaches.

8.5 COCOMO II (2)

COCOMO II estimation process:

– Stage 1: The project usually builds prototypes to resolve high-risk issues involving user interfaces, software and system interaction, performance, or technological maturity. So, little is known about the likely size of the final product under consideration, that is, COCOMO II estimates size in object points.

– Stage 2: A decision has been made to move forward with development. There is not enough information to support fine-grained effort and

duration estimation. COCOMO II employs function points as a size

measure, since function points estimate the functionality captured in the requirements, so they offer a richer system description than object

points.

– Stage 3: This stage corresponds to the original COCOMO model, in that size can be done in terms of line of code, and many cost factors can be estimated with some degree of comfort.

8.5 COCOMO II (3)

Comparison of original and COCOMO II models

Model aspect Original COCOMO II

COCOMO Stage 1 Stage 2 Stage 3

Size Delivered source Object points FP and FP and lang. instruction or SLOC language or SLOC Reuse Equivalence SLOC Implicit in model % unmodified Equivalence

reuse, % modified SLOC as reuse (determined function of by function) other variables Scale Organic: 1.05 1.0 1.02 to 1.26 1.02 to 1.26

Semi-detached: 1.12, depending on depending on

Embedded: 1.20 conformity, conformity, precedent, precedent,

early architecture early architecture

Product cost Reliability None Complexity, Reliability drivers db size required db size,

product reusability documentation complexity needs, product

complexity Platform cost Execution time None Platform Execution time

drivers constraints, difficulty constraints, main storage main storage constraints, constraints, computer

turnaround time

Personnel cost Analyst None Personnel Analyst drivers capability capability capability

applications and experience applications experience, experience, programmer programmer capability, capability, programming language and

lang. experience tool experience,

continuity Project cost Use of modern None Required Use of

8.6 Putnam’s SLIM Model (1)

Customer Perspective at Start of Project

– A set of general functional requirements the system is supposed to perform;

– A desired schedule; – A desired cost.

z

Certain things are unknown or very “fuzzy”

– Size of the system; – Feasible schedule;

8.6 Putnam’s SLIM Model (2)

z

Assuming that technical feasibility has been established, the

customer really wants to know:

– Product size ± a reasonable percentage variation; – A “do-able” schedule ± a reasonable variation;

– The person power and dollar cost for development ± reasonable variation;

– Projection of the software modification and maintenance cost during the operational life of the system.

8.6 Putnam’s SLIM Model (3)

4 parameters concerned by a manager:

– Effort

– Development time – Elapsed time

– A state-of-technology parameter

These parameters provide sufficient information to assess the

financial risk and investment value of a new software development project.

8.6 Putnam’s SLIM Model (4)

Rayleigh curves for SLIM model

8.6 Putnam’s SLIM Model (5)

SLIM uses separate Rayleigh curves for

– Design and code – Test and validation – Maintenance

8.6 Putnam’s SLIM Model (6)

The Effort-Time Tradeoff Law

Size = C

K

_t

where C

is the state of technology which depends on the

development environment, e.g., C

= 10040 by an environment with

on-line interactive development, structured coding, less “fuzzy”

requirements, and machine access fairly unconstrained.

z

Example: The SLIM software equation implies that a 10% decrease

8.6 Putnam’s SLIM Model (7)

z

To allow effort or duration estimation, introducing equation (Putnam):

D

= K / t

_{, where D}

0

is a constant called manpower acceleration.

– Example: the manpower acceleration = 12.3 for new software with many interfaces and interactions with other system, 15 for stand-alone

systems, 27 for re-implementations of existing system.

– We can derive by using the two equations (s/w equation and manpower acceleration equation), the effort or duration are:

K = (Size/C_k)9/7_D 04/7

8.6 Putnam’s SLIM Model (8)

The software differential equation

– The rate of accomplishment is proportional to the pace of the work times the amount of work remaining to be done, that is,

dy/dt = 2at(K-y)

where 2at is the pace and (K-y) is the work remaining to be done. Differentiate once more with respect to time, we get the software differential equation as:

d2_y/dt2 _{+ t/t}

8.6 Putnam’s SLIM Model (9)

z

The software differential equation is very useful because it can be

solved step-by-step using the Runge-Kutta solution. For example,

for SIDPERS, a DoD’s the “Army’s Standard Installation-Division

Personnel System”:

t (year) Coding rate Cumulative code (size/yr in 000) (in 000) 0 0 0 .5 52.8 13.6 1.0 89.2 50.0 1.5 101.0 98.6 2.0 90.8 147.0 3.0 44.2 215.0 3.5 24.9 232.5 3.65 20.33 236.0 Actual size is 256K 4.0 12.3 241.0 which is pretty close

Supplement

z

The overall life-cycle manpower curve can be well represented by

the Norden/Rayleigh form:

dy/dt = 2K a t e

_MY/YR

where a=(1/2t

_{), t}

d

is the time at which dy/dt

/dt

is a maximum, K is the

is a maximum, K is the

area under the curve from t to infinity and represents the nomin

area under the curve from t to infinity and represents the nomin

al

al

life

life

-

-

cycle effort in man-

cycle effort in man

-years. The cumulative number of people used

years. The cumulative number of people used

by the system at any time t is:

by the system at any time t is:

y = K(1

Neglecting the cost of computer test time, inflation overtime, etc., the

development cost is simply the $COST/MY (average). That is,

$DEV = $COST/MY * (0.3944 K) = 40% $LC,

where $LC is life-cycle cost.

Exercises

1.

According to the Rayleigh curve model, what is the effect of

extending the delivery date by 20%?

2.

Suppose that you are developing the software for a nuclear power

plant control system. Select the most appropriate mode for the

project, and use the COCOMO model to give a crude estimate of

the total number of person months required for the development,

assuming that the estimated software size is 10,000 delivered

source instructions.

9.1 Object-Oriented Metrics (1)

z

OO Metrics can provide insight into software size.

– Number of scenario scripts (NSS): The number of scripts or use cases is directly proportional to the number of classes required to meet

requirements; the number of states for each class; and the number of methods, attributes.

– Number of key classes (NKC): A key class focuses directly on the business domain for the problem and will have a lower probability of being implemented via reuse. High values for NKC indicate substantial development work. It is suggested that between 20 and 40 percent of all classes in a typical OO system are key classes.

– Number of subsystems (NSUB): The NSUB provides insight into resource allocation, schedule and overall integration effort.

9.1 Object-Oriented Metrics (2)

Number of scenario scripts.

– To measure the amount of work on project.

– Scenario scripts are written in certain OO methodologies to document and leverage the expected uses of the system.

– Scenario scripts should directly relate to satisfying requirements, since scripts exercise major functionality of the system being built.

– An example: Inventory management system

Initiator Action Participant

User request item info. on InventoryQueryWin. InventoryQueryWin sends item: aNumber to Inventory

Inventory returns anItem to InventoryQueryWin InventoryQueryWin requests price from Item…..

9.1 Object-Oriented Metrics (3)

– The number of scenario scripts is an indication of the size of the

application to be developed. Scripts steps should relate to the public responsibilities of the subsystem and classes to be developed.

z

Number of key classes

– Key classes are central to the business domain being developed.

– The number of key classes is an indicator of the volume of work needed in order to develop an application.

– The number of key classes is indicator of the amount of long-term reusable objects.

9.1 Object-Oriented Metrics (4)

z

How to determine if a class is key by asking the following questions

– Could I easily develop applications in this domain without this class ? – Would a customer consider this object important ?

– Do many scenarios involve this class ?

z

Examples of key classes for some problem domains:

Retail Telephony Banking

SalesTransaction Call SavingAccount LineItem Connection Currency

9.1 Object-Oriented Metrics (5)

Number of support classes

– Support classes, include user interface classes. They are not the central to the business domain ( UI, communications, database, file, collection, string, and so on).

– Support classes give us a handle on estimating the size of the effort. – Type of user interface

• Number of support classes varies one to three times the number of key classes (in experience). The variance is primarily affected by the type of UI.

– UI intensive projects have two to three times as many support classes as key classes.

– Non-UI intensive projects have none to two times as many support classes as key classes.

• Example: If there are 100 key classes and a GUI is used, and early estimate might be for 300 total classes in the application.