Curso: Software Quality Metrics and Models Part II

Curso: Aseguramiento de la
Calidad del Software:
Parte II- Métricas del Software y Modelos de
Calidad
Prof. Renato R. Gonzalez Disla
Mayo del 2017
Actualizado: Mayo 2019

Measurements in Science and
Engineering
•we can not control or improve
what we can not measure
Parte II- Métricas del Software y Modelos de Calidad 2

Engineering
• A discipline to pass from art to science must be
abridged by quantitative methods.
• It is necessary to know about the "essence" of the
objects under study, in order to quantify and
measure such "essence."
• Physic became a science with the notions of matter
and measurement of length, mass and time;
Thermodynamic with the measure of temperature
and entropy.

Engineering
• From mathematical perspectives metric is a
function that takes two arguments from certain
domain or space whose returned value represents a
difference between the two arguments.
• Software complexity measurements, called
"metrics", are functions which take one argument
whose returned value represents a measurement of
certain aspects of the single argument (Ramamurthy and
Melton, 1988).
• These measures are ordinal quantities of software
complexity.

Software Complexity Measurements: How
is the skills, How big, how many, and how
good
• Cognitive Metrics:
• How is the skills and knowledge of people
involved?
• Software Process Metric:
• How Many resources and time we
spend?.
• Technical Product
Complexity metrics :
• How big is the software?.
• Software Quality Metrics:
• How good is the final product?.
People
Development
Process
Product
Structure
Product
Operation

Software Measurements
• “How big is a program?".
• We must define what "big" means, at least to compare a
program to another to find out the difference of effort
invested.
• Metrics are mechanisms to quantify factors and
characteristics (static or dynamic) of objects and
phenomenon in order to apply it in problems solving
estimating the magnitude of effort required.
• Types of Metrics:
• Objectives
• Subjectives
• Directs
• Derived

Software Measurements: Complexity
Factors
• We can identify internal and external factors as
sources of software complexity.
• Its correlation and interdependence determines the
level of complexity in a software product.
• Although this fact, most metrics are oriented to
measure only one software complexity factor.

Software Measurements: Internal
Complexity Factors

Software Measurements: External
Complexity Factors
• The Problem itself
• Methods and tools used in the development
of solutions;
• The level of people expertise involved in the
development process;
• Network and software environment;
• Project organization and management.
• Quality and economy demands

Software Measurements: Domains,
Dimensions, and Forces of Complexity

Software Measurements: Software
complexity Levels
Higher technical complexity
- Embedded, real-time, distributed, fault-tolerant
- Custom, unprecedented, architecture reengineering
- High performance
Lower technical complexity
- Mostly 4GL, or component-based
- Application reengineering
- Interactive performance
Higher
management
complexity
- Large scale
- Contractual
- Many stake holders
- “Projects”
Lower
management
complexity
- Small scale
- Informal
- Single stakeholder
- “Products”
Defense
MIS System
Defense
Weapon SystemTelecom
Switch
CASE Tool
National Air Traffic
Control System
Enterprise IS
(Family of IS
Applications)
Commercial
Compiler
Business
Spreadsheet
IS Application
Distributed Objects
(Order Entry)
Small Scientific
Simulation
Large-Scale
Organization/Entity
Simulation
An average software project:
- 5-10 people
- 10-15 month duration
- 3-5 external interfaces
- Some unknowns & risks
Embedded
Automotive
Software
IS Application
GUI/RDB
(Order Entry)
Walker Royce

Software Measurements: Forces in
Software
Technology churn
Our enemy is complexity, and it’s our goal to kill it.
Jan Baan
Performance Throughput
Capacity
Availability
Fail safe
Fault tolerance
Functionality
Cost Compatibility
Resilience
The challenge over the next 20 years will not be speed or cost or performance;
it will be a question of complexity.
Bill Raduchel, Chief Strategy Officer, Sun Microsystems

Complexity Definition
• What is Complexity?
• Complexity describes the behavior of a system
or model whose components interact in multiple ways and
follow local rules, meaning there is no reasonable higher
instruction to define the various possible interactions.
• Complexity is generally used to characterize something with
many parts where those parts interact with each other in
multiple ways, culminating in a higher order of emergence
greater than the sum of its parts.
• Johnson, Steven (2001). Emergence: The Connected Lives of Ants, Brains, Cities. New York:
Scribner. p. 19. ISBN 3411040742.

Complexity Definition
• We will define Software Complexity as a measure of
the resources that must be expended in developing,
testing, debugging, maintenance, users training,
operation and correcting software products.
• The complexity is a property of the software life cycle as
internal and external factors.
• Estimating the measures of the program properties, as final
product of the development process, we might infer the
level of complexity in a software system.
Shooman, 1983

Software Measurements:
Reasons for Software Complexity Metrics
• Projects Goals: Productivity, Quality and
Financials
• Project planning and estimation: Cost, time,
effort, and resources
• People motivation and productivity
• Process and Tools effective evaluation
• Best Practices and standards (Quality and
productivity) evaluation
• Continue Improvement objectives
• Improving Customer satisfaction and confidence

Steps Implementing a Metrics Program
• Software Development Process.
• Establish and document the existing software
development process, as baseline process which will be
measured and incrementally improved.
• Goals.
• Identify the target improvement goals which are derived
from and supportive of the strategic business objectives.
People motivation and productivity
• Responsibility.
• Identify management responsibility for the metrics
program, and provide the organizational cultural support
and visibility.

Steps Implementing a Metrics Program
• Initial Research.
• Validate the goals and customer expectations through
survey and assessment.
• Metrics Definition.
• Define initial basic set of metrics for measuring goal
achievement progress.
• Sell.
• Introduce and communicate the metrics program to the
organization such that high visibility and cooperation is
achieved.
• Feedback and Process Improvement.
• Identify the metrics reporting and feedback mechanisms
such that software development process improvements
actions can be determined and implemented.

Feedback and Process Improvement Steps
• Goals
• Metrics Definition.
• Measure
• Metrics Communication
• Process Improvement
Insights
• Identify Process
Improvement Actions
• Implement Improvements

People
Development
Process
Product
Structure
Product
Operation
Software Measurements: Life Cycle
Complexity
- Knowledge and Project Management:
Learning, Experience, Skills, Productivity
- Process Quality: Methodology, Tools,
Management, Effort, Productivity, Cost,
Schedule
- Product Quality: Functionality,
Reliability, Availability, Performance,
Security, Portability, Configuration
- Technical Complexity: Design,
Code, syntax, Algorithm, Data,
Modularity, Objects and
Components

Software Measurements: Life Cycle
Complexity
• Quality, time,
cost and scope
are important
components in
software projects

How big, how many, and how good
• Technical Product
Complexity:
• How big is the software.
• Software Process
Metric:
• How Many resources we
need.
• Software Quality
Metrics:
• How good is the final
product.

• Technical Product Complexity
Measurements are oriented to determine and
quantify the software size in static state -product
structure and properties- (How big).
• Are characterized as directs metrics because are used
to obtains derived metrics, such as productivity, effort,
fault, etc.

• Type of Technical Product Complexity
Measurements:
• Code Oriented Metrics
• Control Structure Oriented Metrics
• Linguistic and Syntactical Metrics
• Specifications and Design Metrics
• Functional Size Measurement (FSM)

• Technical Complexity Metrics categories:
• Code Oriented Metrics:
• Line of Source Code (SLOC)
• SLOC without comments (SLOC-CM)
• Execute Statements (STMS)
• Program Modules (UNITS)
• Execute Objects statements (TOKEN)
• Control Structure Oriented Metrics
• Cyclomatic Number (McCabe)
• Knots
• Decision Points

Cyclomatic Number (McCabe)
• Cyclomatic complexity is a software metric (measurement), used to
indicate the complexity of a program. It is a quantitative measure of
the number of linearly independent paths through a program's
source code. It was developed by Thomas J. McCabe, Sr. in 1976.
• Cyclomatic complexity is computed using the control flow graph of
the program: the nodes of the graph correspond to indivisible groups
of commands of a program, and a directed edge connects two nodes
if the second command might be executed immediately after the first
command. Cyclomatic complexity may also be applied to individual
functions, modules, methods or classes within a program.
• One testing strategy, called basis path testing by McCabe who first
proposed it.

• Calculating the McCabe Number: Cyclomatic
complexity is derived from the control flow
graph of a program as follows:
• Cyclomatic complexity (CC) = E - N + 2P
• Where:
P = number of disconnected parts of the flow
graph (e.g. a calling program and a
subroutine)
E = number of edges (transfers of control)
N = number of nodes (sequential group of
statements containing only one transfer of
control)

• Technical Complexity Metrics
categories (cont…):
• Linguistic and Syntactical Metrics
• Halstead Science
• Chunks
• Design Metrics
• Modules
• Objects
• Data Structure
• Use Case Metrics

Functional or Semantic Domain
Software is compound coding
in a programing language
that represent functional
modules or objects classes
that have and hierarchy
structure and
interrelationship. They
represent the business and
process rules contains in
specification and design.
Metrica Chunk-Linguistico Cognitivo
Parte II- Métricas del Software y Modelos
de Calidad
30

Syntactical Domain
Program syntax is the
logical structure of
algorithm defined by
structured programming
(sequence, decision, and
iteration) following its
purpose of control
complexity through
theory and discipline
Parte II- Métricas del Software y Modelos de
Calidad
31

Syntactical Domain
In fact, we define the
syntax as the set of
rules or formulas
which defines the set
of sentences.
Parte II- Métricas del Software y Modelos
de Calidad
32

• Chunks or Program Block

• Valor CHL (i) = (nivel logico BCS)*(Peso BCS)*(cant operandos + cant
operadores) i = 1, 2, 3…n-chunks
• Total Valor CHL = Sum (Valor CHL(i))
• Para peso de BCS Ver cuadro del Dr. Wang
• Patra calculo ver template excelParte II- Métricas del Software y Modelos de Calidad 34

Use Case Metrics - UCP
• Use Case Points (UCP) is a software estimation technique used to
forecast the software size for software development projects.
• UCP is used when the Unified Modeling Language (UML) and
Rational Unified Process (RUP) methodologies are being used for
the software design and development.
• The concept of UCP is based on the requirements for the system
being written using use cases, which is part of the UML set of
modeling techniques.
• The software size (UCP) is calculated based on elements of the
system use cases with factoring to account for technical and
environmental considerations.
• The UCP for a project can then be used to calculate the estimated
effort for a project.

• The method for determining the size estimate to
develop a system is based on a calculation with the
following elements:
• Unadjusted Use Case Weight (UUCW) – the point size of
the software that accounts for the number and complexity
of use cases.
• Unadjusted Actor Weight (UAW) – the point size of the
software that accounts for the number and complexity of
actors.
• Technical Complexity Factor (TCF) – factor that is used to
adjust the size based on technical considerations.
• Environmental Complexity Factor (ECF) – factor that is used
to adjust the size based on environmental considerations.

• Calculating The Use Case Points
• The formula to calculate use case points is
described below in terms of the variables from
above: TCF, EF, UUCP, and AW.
• Use Case Points = (UUCP + AW) * TCF * EF.
• Determining Effort From Use Case Points:
• “complex projects” have a higher conversion factor (28 hours
per UCP if total Environmental Factor <15) and “simpler
projects” (20 hours per UCP if >= 15).

• Ver Template Excel para calculo del UCP

• Functional Size Measurement (FSM):
• Function Points Metric (FP) - Allan
Albrecht, IBM 1979
• COSMIC (ISO/IEC 19761:2011)
• IFPUG (ISO/IEC 20926:2009)
• Commercial Tools
• COCOMO II
• KnowledgePlan
• SEER
• SLIM
• Software Risk Master

• Software Process Metrics
characterizes the maturity of the
process which the software
product is developed.
• Can be measured during the
product development for
providing real time feedback to
software project management
• Are often concerned with the
efficient application of people and
resources to software product
development (how many).

• Software Process Metrics:
• Schedule (Time)
• Cost
• Productivity and Effort

• Software Process Metrics Schedule:
• Primary data used for project management and as process
quality indicators.
• This metric is calculated as the difference between the planned
and actual work time to achieve the milestone of first customer
delivery divided by the planned work time.
• The metrics is given as a percentage: negative number indicates
a schedule slip and positive indicates the actual date was
achieved earlier than plan:
• (Tp – Ta)/Tp

• Software Process Metrics Effort:
• Primary data used for project management and for productivity
indicators.
• It can be counted as staff-days (staff-hours) or project
components (software volume) delivery per time units.
• It is the intellectual force needed and applied through the time
to achieve a specific task or technical measurement unit.
• KLOC/days-man,
• Chunks/days-man,
• FP/days-man, Information Content(H)/days-man, Objects
Designed/days-man.

• Software Process Metrics Cost:
• Primary data used for project management and financial
indicators.
• It counted as the monetary value of the staff-days (staff-
hours) of effort in the different project phases:
• US$ KLOC/days-man X 10 days
• US$ FP/days-man X 25 days
• US$ Objects Designed/ days-man X 15
• US$ Modules Tested/days-man X 8

• Software Process Metrics Productivity:
• Productivity is concerned with the efficiency of the resources
consumed in producing a given application in a timely
manner, as such, included measuring system quality.
• The main question in productivity is:
• what is the time and computer resources to be invested
in the software process for a quantity of software
volume.
• It is mainly influenced by the capacity of people to do a
particular job and the technical and organization
environment in the different phases of the project.

• Components (project or phases):
• PE = Total Effort Cost
• PM = Total Cost Time Machine
• PA = others resources
• PT = PE + PM + PA
• PS = Total productivity expected based in standards or best
practices
• P = (PS – PT)/PS

• Models
• Constructive Cost Model (COCOMO), developed by Barry Bohm
in 1981.
• Putnam Estimative Model, developed in 1978.
• Function Point Model, developed by Allan Albrecht in 1979.
• Others derived metrics

• Derived Models
• Constructive Cost Model (COCOMO), developed by Barry Bohm
in 1981.
• Putnam Estimative Model, developed in 1978.
• Function Point Model, developed by Allan Albrecht in 1979.
• Others derived metrics

• Software Quality Metrics characterizes the
quality level of the software product or service itself
(how good).
• Are defined during the computational and operational
life of the software in the network environment.
• Are oriented to measure the function, faults, errors,
time, facility, etc.

• What is Software Quality?
• Quality is judged indirectly by focusing on the
effectiveness and usefulness of the delivered system in
performing the task for which it was designed (Scudder and
Kucie, 1991).
• In other words, how the system is actually constructed and
how it performs its functions as opposed to how it should
have been built and how it should perform (Sneed and Merey,
1985).

Software Quality Attributes
• Quality attributes are the overall factors that
affect run-time behavior, system design, and
user experience.
• They represent areas of concern that have the
potential for application wide impact across
domains, layers and tiers.

• When designing applications to meet any of the
quality attributes requirements, it is necessary to
consider the potential impact on other
requirements.
• You must analyze the tradeoffs between multiple
quality attributes.
• The importance or priority of each quality attribute
differs from system to system;

• Software Quality Metrics Models:
• McCall Model
• Boehm Model
• ISO 25010
• Sneed Model

Software Quality Models and Attributes (Sneed
Model)
Domains Objectives Quality Factors
Functional or Semantic Scope and Completeness Functional
Informational
Relational
Managerial and Efficiency
(Process)
Time
Costs
Productivity (effort)
Specifications Completeness
Consistency
Feasibility
Syntactical Technical or Non-Structural Maintainability
Reusability
Scalability
Portability
Interoperability
Testability
Computational Operational or Structural Usability
Availability
Reliability
Performance
Integrity
Security

Software Quality Attributes:
Functional
• Scope and Completeness: Proportion of
possible entities, artifacts and his
relationship designed, specified and
implemented in the software systems:
• Functional: process automated by the system
• Informational: proportion of data entities and
object classes, managed, accessed or stored by the
software
• Relational: relevant relationship between entities
and object classes.

Functional
• Managerial and Efficiency: Needed to
control the software process development
and the effectiveness and efficient of
resources.
• Time: is given by the complexity of the
problem, the technical resources and quality
of human resources
• Costs: are related to the amount of resources
invested and the times of use of resources in
the project implementation.
• Productivity (effort): is a function of cost, time,
effectiveness and efficiency achieved.

Functional
• Specifications: Relative to the requirements of
business, users, system and operational
specified.
• Completeness: is defined in the context of the
specification as the proportion of entities, artifacts,
processes and planned relevant relationships, which
have been fully specified.
• Consistence: the lack of contradiction between
different parts and relationships defined in the
specifications.
• Feasibility: is the probability that the specified
software can be implemented within the constraints
of time and costs established.

Software Quality Attributes: Non-
Structural
• Technical factors: Technical factors are used to
measure the adequacy of the design to the
implementation.
• Usability: The application interfaces must be
designed with the user and consumer in mind so
that they are intuitive to use, can be localized and
globalized, provide access for disabled users, and
provide a good overall user experience.

Structural
• Technical factors (Cont.):
• Maintainability: Maintainability is the ability of the
system to undergo changes with a degree of ease.
• These changes could impact components, services, features,
and interfaces when adding or changing the application’s
functionality in order to fix errors, or to meet new business
requirements.
• Maintainability can also affect the time it takes to restore the
system to its operational status following a failure or removal
from operation for an upgrade.

Structural
• Maintainability (cont.):
• Improving system maintainability can increase availability and
reduce the effects of run-time defects.
• An application’s maintainability is often a function of its overall
quality attributes but there a number of key issues that can
directly affect.

Structural
• Reusability: Reusability is the probability that a
component will be used in other components or
scenarios to add new functionality with little or no
change.
• Reusability minimizes the duplication of components
and the implementation time.
• Identifying the common attributes between various
components is the first step in building small reusable
components for use in a larger system.

Structural
• Scalability: Scalability is ability of a system to
either handle increases in load without impact on
the performance of the system, or the ability to be
readily enlarged.
• There are two methods for improving scalability:
• scaling vertically (scale up), and scaling horizontally
(scale out).
• To scale vertically, you add more resources such as CPU,
memory, and disk to a single system.
• To scale horizontally, you add more machines to a farm
that runs the application and shares the load.

Structural
• Portability: It is the measure of amount of
effort required to transfer software from one
operating environment to another in relation to
the development effort in the original
environment.

Structural
• Interoperability: Interoperability is the ability of a
system or different systems to operate successfully
by communicating and exchanging information
with other external systems written and run by
external parties.
• An interoperable system makes it easier to exchange
and reuse information internally as well as externally.
• Communication protocols, interfaces, and data formats
are the key considerations for interoperability (XML,
SOAP, ETC).
• Standardization is also an important aspect to be
considered when designing an interoperable system

Structural
• Testability: Testability is a measure of how well
system or components allow you to create test
criteria and execute tests to determine if the
criteria are met. Testability allows faults in a
system to be isolated in a timely and effective
manner.
• Supportability: is the ability of the system to
provide information helpful for identifying and
resolving issues when it fails to work correctly.

Structural
• Manageability: Manageability defines how easy it
is for system administrators to manage the
application, usually through sufficient and useful
instrumentation exposed for use in monitoring
systems and for debugging and performance
tuning.
• Design your application to be easy to manage, by
exposing sufficient and useful instrumentation for
use in monitoring systems and for debugging and
performance tuning.

Structural
• Operational or Structural factors: essentials
to measure the efficiency and quality of the
implementation of software
• Availability: defines the proportion of time that
the system is functional and working.
• It can be measured as a percentage of the total system
downtime over a predefined period.
• Availability will be affected by system errors,
infrastructure problems, malicious attacks, and system
load.

Structural
• Operational factors (cont.):
• Performance: Performance is an indication of the
responsiveness of a system to execute specific
actions in a given time interval. It can be measured
in terms of latency or throughput.

Structural
• Performance:
• Latency is the time taken to respond to any event.
Throughput is the number of events that take place in a
given amount of time.
• An application’s performance can directly affect its
scalability, and lack of scalability can affect
performance.
• Improving an application’s performance often improves
its scalability by reducing the likelihood of contention
for shared resources.
• Factors affecting system performance include the
demand for a specific action and the system’s response
to the demand.

Structural
• Security: is the capability of a system to reduce the
chance of malicious or accidental actions outside
of the designed usage affecting the system, and
prevent disclosure or loss of information.
• Improving security can also increase the reliability of the
system by reducing the chances of an attack succeeding
and impairing system operation.
• Securing a system should protect assets and prevent
unauthorized access to or modification of information.
• The factors affecting system security are confidentiality,
integrity, and availability.
• The features used to secure systems are authentication,
encryption, auditing, and logging.

Structural
• Integrity: measure of the data and resources
accessibility and the fault recovery without human
intervention.

Structural
• Reliability: Reliability is the ability of a system to
continue operating in the expected way over time.
Reliability is measured as the probability that a
system will not fail and that it will perform its
intended function for a specified time interval.

Structural
• Software Quality Metrics Reliability
• In Software reliability the quantity of code developed
(volume), the number of instructions added or modified is
directly related with the quantity of faults or coding errors
introduced in the software (Musa, 1989).

Structural
• Software Quality Metrics Reliability
• A fault is any situation in software operation that causes an
incorrect result or malfunction for a valid input or event.
• Error or Bug is a software defect that produce a fault.
• Program fault is the overall result of total software
complexity factors reveled in operation time.
• Faults are reveling as a program failure occurs during the
execution due to certain data event not predicted in
design or coding (bug).

Structural
• Software Quality Metrics Reliability:
• Taxonomy of Faults or Failures
 Specification
 Functional
 Structural
 Data Errors
 Coding
 Implementation
 Integration
 Systems and Architectures
 Testing

Structural
• Software Quality Metrics Reliability:
• Measurements
• Mean numbers of failures experienced as a function of time while
software is executed: FM = Fi / T
• Mean Time Between Failure:
MBTF= MTF + MTR
MTF is mean time of failure
MTR is mean time of repair
Availability: TAvail = MTF/MBTF

Structural
• Software Quality Metrics Reliability Models:
• Poisson Distribution Model
• Markov Stochastic Model

Bibliography
• Philippe Kruchten, The Rational Unified Process - An Introduction, Addison-
Wesley, 1999.
• Renato R. Gonzalez; “A unified metric of software complexity: Measuring
productivity, quality, and value”; The Journal of Systems and Software, Vol.
29, Number 1, April 1995.
• M. L. Shooman, Software Engineering: Design, Reliability and Management,
New York, McGraw Hill, 1983, pp. 150-151.
• B. Curtis, Foundations for a Measurement Discipline, Quality Time, IEEE
Software, November 1987.
• J. S. Davis and R. J. LeBlanc, A Study of the Applicability of Complexity
Measures, IEEE Trans. Software Engineering SE-14(9):1366-1372(1988).
• Grady Booch, Object Oriented Design with Applications, The
benjamín/Cummings Publishing Company, Inc. 1991.
• Stephen Gilbert and Bill McCarty, Object Oriented Design in Java, Mitchel
Waite, 2000.
• Roger Pressman, Ingeniería del Software, Un Enfoque Práctico, McGraw Hill,
1998.

GRACIAS POR SU
ATENCION
P&R

Curso: Software Quality Metrics and Models Part II

Recommended

Recommended

More Related Content

What's hot

What's hot (17)

Similar to Curso: Software Quality Metrics and Models Part II

Similar to Curso: Software Quality Metrics and Models Part II (20)

Recently uploaded

Recently uploaded (20)

Curso: Software Quality Metrics and Models Part II