Software Metrics

Quantifiable measures that could be used to

measure different characteristics of a software

system or the software development process.

Why measure?

You cannot control what you cannot measure

Required for effective management

Managers need quantifiable information, and not subjective

information

Required in all phases

To understand what is happening during development and maintenance.

To control what is happening on our projects.

To improve our process and products.

Categories of Metrics

Product Metrics

Process Metrics

Project Metrics

Product Metrics

Quantify the characteristics of the product being

developed such as size, complexity , design

features, performance, efficiency, reliability,

portability etc.

Process Metrics

Quantify the characteristics of the process being

used to develop the software product

Example

Effectiveness of defect removal during

development

Process maturity

Project Metrics

Focus on specific attributes of the project

Examples

Number of software developers

Schedule

Resource utilization

LOC (Lines of Code)

Size –oriented metrics

Explain how comments, blank lines, declarations,

more statements on one line are handled

Function Point

Proposed by Allan Albrecht

Function Points measure software size by

quantifying the functionality provided to the user

based solely on logical design and functional

specifications

Components of FP Count

Data Functions:

1. Internal logical files

2. External interface files

Transactional Functions:

1. External Inputs

2. External Outputs

3. External Inquiries

Important terms and definitions used in

describing the five functions

User identifiable This term refers to defined requirements for processes and/or groups

of data that are agreed upon, and understood by, both the users and software developers.

Control information This is data that influences and elementary process of the application

being counted. It specifies what, when, or how data is to be processed.

Elementary process An elementary process is the smallest unit of activity that is

meaningful to the user. An elementary process must be self-contained and leave the business of the application being counted in a consistent state.

Data Element Type, or DET A data element type is a unique, user recognizable, non-repeated

field. This definition applies to both analyses of data functions and transactional functions.

Record Element Type, or RET A record element type is a user recognizable subgroup of data

elements within an Internal Logical File or External Interface File.

Internal Logical Files (ILF)

An ILF is a user-identifiable group of logically

related data or control information that is stored

and maintained within the boundary of the

application

Example

Tables in a relational database.

Flat files.

Application control information, perhaps thingslike user preferences that are stored by theapplication

External Interface File (EIF)

An external interface file (EIF) is a user

identifiable group of logically related data or

control information referenced by the application,

but maintained within the boundary of another

application

External Input (EI)

An external input (EI) is an elementary process in

which data or control information crosses the

boundary from outside to inside

Example

Data entry by users.

Data or file feeds by external applications

External Output (EO)

An elementary process in which derived data

crosses the boundary from inside to outside.

Example

Reports created by the application being

counted, where the reports include derived

information.

External Inquiry (EQ)

An elementary process in which retrieved data

crosses the boundary from inside to outside.

Example

Reports created by the application beingcounted, where the report does not includeany derived data.

Functional Complexity

Using a complexity table, each of the 5 basic entity is

evaluated as : low ,average ,high

Complexity table uses 3 attributes for decisions

# of Record Element Types (RET): e.g. employee data type,

student record type

# of unique attributes (fields) or Data Element Types (DET)

for each record : e.g. name, address, employee number, and

hiring date would make 4 DETs for employee data stype

# of File Type Referenced (FTR): e.g an external payroll

record file that needs to be accessed

Basic Entity Types uses the RET, DET, and FTR

for Complexity Evaluation

For Logical Files and External Interfaces (DATA):

For Input/Output/Query (TRANSACTIONS):

# of RET 1-19 DET 20-50 DET 50+ DET

1 Low Low Ave

2 -5 Low Avg High

6+ Avg High High

# of FTR 1-4 DET 5 -15 DET 16+ DET

0 - 1 Low Low Ave

2 Low Avg High

3+ Avg High High

Functional Complexity - EO

Functional Complexity - ILF

Weighting Factor

Unadjusted Function Point =

Unadjusted Function Point- Example

Weighting Factor

Parameter Count Simple Average Complex Weight

# of EI 3 4 6 =

# of EO 4 5 7 =

#EQ 3 4 6 =

# LIF 7 10 15 =

# EIF 5 7 10 =

Total_weight =

Total function point formula

FP = UAF (0.65 + 0.01 Fi)

where

Fi = sum of 14 value adjustment factors

General System Characteristics1. Does with system require reliable backup and recovery?2. Are data communications required?3. Are there distributed processing functions?4. Is performance critical?5. Will the system run in an existing, heavily utilized operational

environment.6. Does the system require on-line data entry?7. Does the on-line data entry require the input transaction to be

built over multiple screens or operations?8. Are the master files updated on-line?9. Are the inputs, outputs,files or inquiries complex?10. Is the internal processing complex?11. Is the code designed to be reusable?12. Are conversion and installation included in the design?13. Is the system designed for multiple installations in different

organizations14. Is the application designed to facilitate change and ease of use by

the user?

Rating of Value Adjustment Factors

Rate each factor on a scale of 0 to 5

0 = No influence

1 = Incidental

2 = Moderate

3 = Average

4 = Significant

5 = Essential

Example

Total of FPs = 341

F4 = 4, F10 = 4, other Fi’s are set to 0. Sum of all

Fi’s = 8.

FP = 341 x (0.65 + 0.01 x 8) = 248.93

Steps to compute FP

Identify and count ILF, EIF, EI , EO and EQ

For each ILF and EIF, identify the number of RETs and the number of DETs

For each EI, EO and EQ, identify the number of FTRs and DETs

Using the complexity matrices, assign complexity values to EI, EO, EQ, ILF and EIF items.

Compute the total unadjusted function points

Determine the values of the fourteen general system characteristics

Sum the total characteristics

Determine the total function points with the Total Function Point Formula

Lines of Code per Function Point

Source Code Language (SLOC/FP)

Assembly (Basic) 320

C 165

C++ 72

Database Language 40.0

Java 52

Software Cost Estimation

COCOMO

Constructive Cost Model

COCOMO is one of the most widely used software cost

estimation model introduced by Barry Boehm in 1981

COCOMO predicts the cost, effort and schedule for a

software product development based on inputs relating to

the size of the software and a number of cost drivers that

affect productivity

The Development Modes

Organic Mode

Semidetached Mode

Embedded Mode

Organic Mode

Working to develop well understood application

size of the development team is reasonably small

developed in a familiar, stable environment,

relatively small and requires little innovation

Example – a payroll system

Semidetached Mode

intermediate between Organic and Embedded

Developers have an intermediate level of

experience with related systems

Mixture of experienced and inexperienced

developers

Team can have experience relative only in some

project aspects

Example – interactive banking system

Embedded Mode

The software is strongly coupled to complex

hardware, or real-time systems.

Project developed within tight constraints

Project on not very known fields

The product requires great innovation

Example – Nuclear Reactor Control System

Types of Project

Levels of COCOMO

Basic

Intermediate

Complete

Basic COCOMO

Static single model that computes software

development effort (and cost) as a function of

program size expressed in estimated thousands

of delivered lines of code (KDLOC).

Formula

Effort = a1 * (KDLOC)a2 PM

Tdev= b1 * (Effort)b2 Months

KDLOC is the estimated size of software product expressed

in Kilo Delivered lines of code

Tdev is the estimated time to develop the software

a1 , a2 ,b1,b2 are constants for each category of product.

Software project

a1 a2 b1 b2

Organic mode 2.4 1.05 2.5 0.38

Semidetached mode 3.0 1.12 2.5 0.35

Embedded mode 3.6 1.20 2.5 0.32

Example

A project size of 32 KLOC is to be developed.

Software development team has average

experience on similar type of projects. The

project schedule is not very tight. Calculate the

effort, development time, average staff size of

the project.

Example - answer

Effort = 3.0*(32) 1.12 = 146 PM

Schedule = 2.5*(146) 0.35 = 14 months

Average Staffing = 146 PM /14 months

= 10 FSP

Intermediate COCOMO model

The intermediate COCOMO is an extension of the basic

COCOMO model

The Intermediate Model estimates the software

development effort by using fifteen cost driver variables

besides the size variable used in Basic COCOMO

refines the initial estimate obtained using the basic

COCOMO expressions by using a set of 15 cost drivers

(multipliers) based on various attributes of software

development

Cost Drivers COSTDRIVE

R

DESCRIPTION

RELY Required software reliability

DATA Database size

CPLX Product complexity

TIME Execution time constraints

STOR Main storage constraints

VIRT Virtual machine volatility- degree to which the operating system changes

TURN Computer turn around time

ACAP Analyst capability

AEXP Application experience

PCAP Programmer capability

VEXP Virtual machine (i.e. operating system) experience

LEXP Programming language experience

MODP Use of modern programming practices

TOOL Use of software tools e.g. CASE tools

SCED Required development schedule

COCOMO – Cost Drivers Rating COST DRIVER

RATING

v.low low nominal high v.high ex. high

(Product) RELY 0.75 0.88 1.00 1.15 1.40 .

DATA . 0.94 1.00 1.08 1.16 .

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

(Computer) TIME . . 1.00 1.11 1.30 1.66

STOR . . 1.00 1.06 1.21 1.56

VIRT . 0.87 1.00 1.15 1.30 .

TURN . 0.87 1.00 1.07 1.15 .

(Personnel) ACAP 1.46 1.19 1.00 0.86 0.71 .

AEXP 1.29 1.13 1.00 0.91 0.82 .

PCAP 1.42 1.17 1.00 0.86 0.70 .

VEXP 1.21 1.10 1.00 0.90 . .

LEXP 1.14 1.07 1.00 0.95 . .

(Project) MODP 1.24 1.10 1.00 0.91 0.82 .

TOOL 1.24 1.10 1.00 0.91 0.83 .

SCED 1.23 1.08 1.00 1.04 1.10 .

Formula

E = Enom * EAF,

EAF = RELY * DATA * CPLX * TIME * STOR * VIRT *

TURN * ACAP * AEXP * PCAP * VEXP * LEXP * MODP *

TOOL * SCED

The coefficients a, b, c and d are given below :

Software project

a1 a2 b1 b2

Organic mode 3.2 1.05 2.5 0.38

Semidetached mode 3.0 1.12 2.5 0.35

Embedded mode 2.8 1.20 2.5 0.32

Complete COCOMO

Detailed Model uses the same equations for

estimations as the Intermediate Model

Cost of each sub-system is estimated separately.

Costs of the sub-systems are added to obtain

total cost.

Reduces the margin of error in the final estimate.

Example

A Management Information System (MIS) for an

organization having offices at several places across the

country:

Database part (semi-detached)

Graphical User Interface (GUI) part (organic)

Communication part (embedded)

Costs of the components are estimated separately:

summed up to give the overall cost of the system.

Steps in using COCOMO model

Identify the ‘mode’ of development for the new project.

Estimate the size of the project in KDSI to derive a nominal

effort prediction.

Adjust the 15 cost drivers to reflect your project, producing

an effort adjustment factor.

Calculate the predicted project effort using equation 1 and

the effort adjustment factor.

Calculate the project duration using equation 2.

Risk Management

Risk

A project risk is any unanticipated event , which

if they occur will have an unexpected usually

negative impact on the project objective

Risk Management

Risk management include activities that are

undertaken to reduce the impact of risk on cost,

quality and schedule.

Software risk management is the formal process

in which risk factors are systematically identified,

assessed and mitigated

Boehm’s Project Risk Management Model

Risk Management Activities

risk assessment, consisting of

identification of those risks likely to cause

problems

analysis to determine the loss probability and

loss magnitude for each risk and to develop a

compound risk

prioritization to rank the identified risk items

“Top Ten List” of Risk Items

1. Personnel shortfalls

2. Unrealistic schedules and budgets

3. Developing the wrong software functions

4. Developing the wrong user interface

5. Gold plating (cost overrun)

6. Continuing stream of requirements changes

7. Shortfalls in externally (other groups or co.) performed tasks

8. Shortfalls in externally furnished components

9. Real-time performance shortfalls

10. Straining computer science capabilities

Risk Exposure

Risk exposure (impact/factor)

RE = P(UO) L(UO)

RE: risk exposure

UO: unsatisfactory outcome

P(UO): probability of UO

L(UO): loss due to UO

Risk Management Activities

risk control, consisting of

management planning to bring the risk items

under control

resolution to eliminate or resolve the risk items

monitoring to track the project's risk reduction

progress and to apply corrective action where

necessary

Risk Management Planning

Risk Avoidance

Transfer Risk

Risk reduction

Actions that reduce the likelihood that the risk will occur

Actions that reduce the impact of the risk should it occur

Example

The subcontractor may not deliver the software at the required reliabilitylevel and as a result the reliability of the total system may not meetperformance specifications.

Develop all software in-house. (Avoidance)

Switch to a subcontractor with a proven reliability track record eventhough they are more expensive. Avoidance)

Transfer the risk to the subcontractor by building penalties into thecontract for delivered software that does not have the requiredreliability. (transfer)

Assign a project engineer to participate in the requirements & designinspection and to conduct alpha testing at the subcontractor’s site.reduction)

Assign an engineer to liaison with the subcontractor on defectresolution and implement our regression test plan for maintenancereleases from the subcontractor.( reduction)

Risk resolution

Implement the risk management plan to

resolve the risk factors

Risk monitoring

Monitoring the status of various risks and

their control activities

Table 1. Boehm’s Top Ten Risk

Items

1.Personnel Shortfalls: Staffing with top talent; job matching; team-building; morale-building;

cross-training; pre-scheduling key people.

2.Unrealistic Schedules and Budgets: Detailed, multi-source cost and schedule estimation;

design to cost; incremental development; software reuse; requirements scrubbing.

3.Developing the wrong software functions: Organizational analysis; mission analysis;

operational concept formulation; user surveys; prototyping; early users’ manuals.

4.Developing the wrong user interface: Prototyping; scenarios; task analysis.

5.Gold-plating. Requirements scrubbing: prototyping; cost-benefit analysis; design to cost.

6.Continuing stream of requirements changes: High change threshold; information-hiding;

incremental development (defer changes to later increments).

7.Shortfalls in externally-performed tasks: Reference-checking; pre-award audits; award-fee

contracts; competitive design or prototyping; team-building.

8.Shortfalls in externally-furnished components: Benchmarking; inspections; reference

checking; compatibility analysis.

9.Real-time performance shortfalls: Simulation; benchmarking; modelling; prototyping;

instrumentation; tuning.

10.Straining computer science capabilities: Technical analysis; cost-benefit analysis;

prototyping; reference checking.