Modulo 2 - Formulacion y Evaluacion de Proyectos

Estructura para el diseño de cursos virtuales
Versión 1. Noviembre de 2016
MODULE N° 2 : Quality of the product
2. INFORMACIÓN ESPECÍFICA DEL MÓDULO
Program Software engineering

Number and name of the Module 2: Quality of the product
module
Duration of the module 2 weeks
Author of the design Antonio José Segovia Henares
ajsegovia@itauco.com
Updating date 25/08/2016
TABLE OF CONTENT
1.- Quality of the product

1.1.- Introduction
1.2.- Quality of the software product
1.3.- Main standards about the quality of the software product
1.4.- Standards ISO/IEC 25000 (SQuaRE)
1.5.- Tools for the assessment of the quality of the software product
1.6.- Example of an environment for the evaluation of the software product
2.- Quality of the service (ISO 20000)

2.1.- Introduction to ISO/IEC 20000
2.2.- Structure of the ISO/IEC 20000
2.3.- Global management of ISO/IEC 20000
2.4.- Model and key areas
INTRODUCTION TO THE MODULE N° 2
We can consider process for the measurement of the quality, but it is not only the
unique parameter, we can also consider directly the product, and also the service that
the company offers (generally related to the development and maintenance of
software).
So basically during this module we will see new standards that can help us for the
establishment of quality in our product, and in our service.
COMPETENCES OF THE MODULE 2 AND THEMATIC STRUCTURE
Competences of the module Thematic structure to address in the module
Competence 1 and 2: Identify 1.1.- Introduction

models related to the quality of 1.2.- Quality of the software product
the software, from the point of 1.3.- Main standards about the quality of the software product
view of the product. Define 1.4.- Standards ISO/IEC 25000 (SQuaRE)
differences between quality 1.5.- Tools for the assessment of the quality of the software product
models, from the point of view 1.6.- Example of an environment for the evaluation of the software
of the product product
Competence 3 and 4: To know 2.1.- Introduction to ISO/IEC 20000

details about the quality of the 2.2.- Structure of the ISO/IEC 20000
service, and to know concepts 2.3.- Global management of ISO/IEC 20000
basic about the standard ISO 2.4.- Model and key areas
20000
CONTENT OF THE MODULE N° 2
1. Thematic unit 2: Quality of the product

1.1. Introduction (not exceed half a page. Maximum 3 paragraphs)
We have seen in the module 1 that the processes are key to obtain quality, but if
we also focus on the product and the service, considering some new parameters
related to the product, and new processes related to the service, we can obtain
better results.
1.2. Conceptual framework
1.2.1. Introduction
The major interest of any company is to have satisfied customers, and for that, it
is fundamental to offer quality. So, if the company follows an adequate way
focusing into processes, the product, and the service, will be more easy to obtain
the satisfaction of their clients.
Anyway, the more important here is the processes and the product, because can
be specific, although the service can be also interesting, but it is generic, and
there are various quality standards related to the service.
1.2.2. Quality of the software product
For the quality of the software product, we can follow various models, although
most of them have the same origin.
1.2.3. Main standards about the quality of the software product
The most important standards related to the quality of the software product are
ISO 9126 and ISO 25000, and they have a similar structure, based on
characteristics and attributes.
1.2.4. Standard ISO/IEC 25000 (SQuaRE)
One of the most important standards related to the quality of the software
product is ISO/IEC 25000, which is also known as SQuaRE, although really this
standard is composed by various groups of standards.
1.2.5. Tools for the assessment of the quality of the software product
There are various tools that we can use for the assessment of the quality of the
software product, some of them are free.
1.2.6. Example of an environment for the evaluation of the software product
It Is important to know how to evaluate the quality of a software product,

considering the characteristics and attributes defined by ISO/IEC 25000, so we
will see an easy example.
1.2.7. Introduction to ISO/IEC 20000
ISO/IEC is an international standard related to the quality of the IT service, and

can help us to obtain the satisfaction of our clients. It is the best standard for
software companies, because is specifically related to IT.
1.2.8. Structure of the ISO/IEC 20000
ISO/IEC 20000 is composed by various parts, defining each one specifics aspects
about the quality of the service.
1.2.9. Global management of ISO/IEC 20000
For the evaluation of the service, ISO/IEC 20000 uses processes related to the IT
service, and these processes are structured in various groups.
1.3.1. Model and key areas
For the management of the IT service, it is important include the PDCA model, to
keep a continual improvement.
1.3. Examples (not to exceed 2 pages)
Como estandarizar la evaluación de la calidad del producto software - 1:

http://www.javiergarzas.com/2012/10/iso-9126-iso-25000-1.html
Cómo estandarizar la evaluación de la calidad del producto software – 2 :

http://www.javiergarzas.com/2012/10/iso-9126-iso-25000-2.html
1.4. Exercises
1.- The quality of a product is very subjective, so if you buy a software, how can
you evaluate if it has quality?
2.- We can use some standards related to the software product, for the
evaluation of the quality, but we can use an automatic way?
3.- If we think that we can also improve the service, what are the elements
related to the IT service that we need to consider?
1.5. Conclusions
The satisfaction of the client is very important, but all clients are different, but
we can establish a generic way, based on international standards, to give them
quality, from the point of view of the processes, the product, and the service.
1.6. Resources for the study
Bibliographic Location (the link web or the database)

Topics covered
reference (APA)
ISO 9126 and ISO 25000 Jarvier Garzas (2012) http://www.javiergarzas.com/2012/10/iso-9126-
Cómo estandarizar la iso-25000-1.html
evaluación de la calidad
del producto software -
1
ISO 9126 and ISO 25000 Jarvier Garzas (2012) http://www.javiergarzas.com/2012/10/iso-9126-iso-
Cómo estandarizar la 25000-2.html
evaluación de la calidad
del producto software -
2
Software product León, M. Certificación en http://mti.cucea.udg.mx/sites/default/files/Documento de titulacion
Miguel Angel Leon.pdf
Pruebas software
2. Thematic unit 2 – Quality of the product

2.1.1- Introduction
In software engineering is generally accepted that companies improve their

processes software, to improve the final product.
To do this, companies often use CMMI (one of the more widespread, popular and
used worldwide standard), or its equivalent, SPICE, which defines a model of
evaluation of maturity of processes.
As you recall, SPICE saw it in the previous module, and based on a series of levels
of capacity and maturity, we could identify the maturity of an organization (ISO/IEC
15504-7), and we could also identify the ability of each process (ISO/IEC 15504-2).
Now we will see a different approach, but it will also help us to develop software with
quality. Therefore, we will now focus on the quality of the product, which can offer
many guarantees to develop the software with quality, which will obviously result in
customer satisfaction.
Processes
Product
Quality
standards
Final client satisfied

Figure 1 – How to obtain the customer satisfaction
Therefore, the final idea is not to decide between use the model of processes, or
focus only in the quality of the product, the best is to use both perspectives, to get
the development of a software with quality, and obtain the satisfaction of the
customers. So, now we will see the approach of the quality of the product.
2.1.2- Quality of the software product

It is clear that everyone prefers a product with quality that a product without quality.
Imagine that we buy a bicycle that is manufactured with quality controls, and another
in which quality controls have not been established.
Probable, the bicycle that has been produced with quality parameters will give us
less problems, because a company can give us a guarantee of quality. And if we
have problems, a company can give us a support.
But with the bicycle that has been produced without minimum quality parameters,
generally nobody can ensure that the bicycle can run adequately.
Products that have been developed with quality parameters, generally have a higher
cost, and it is logical, because ensure that quality takes time, and generally additional
resources are necessary.
We can also find a product that has been developed with quality parameters, and
which also fails or does not work well, but in principle the probability of failure is low,
and usually we will have a support from the company.
In software occurs something similar, because we also have a product, but in this
case the product is software.
But then, with a software product, how we can determine that has a good quality?
Also think that the software product never fails, but is very difficult to use or
understand.
Therefore, it is necessary to define some criteria or quality parameters, and unify

them, so that they can be used to evaluate the quality of any software product.
In 1977 Mr McCall created a list composed by several parameters that can affect the
quality of the software product, and which can be used to evaluate or measure its
quality.
This list was focused solely on the quality of the software product, i.e. not addressed
anything relating to processes, methodologies, etc.
These parameters of quality of the product, addressed:
 The operation of the software products

 The revision of the software products
 The transition from software products
Operation
Revision
Transition
Figure 2 –McCall model
Subsequently, specifically 1 year later, Boehm developed and published a model

similar to the of McCall, that also considered the "performance" and the "utility" of
the software product, to determine its quality.
Several years more afternoon, on 1991, began to develop the first standards for the
assurance of the quality of the software product, and these standards were used as
reference for the current standards.
2.1.3- Main standards about the quality of the software product
The first standard that was developed, related to the quality of the software product,
based on the models of McCall and Boehm, was the ISO 9126
With the publication of this first ISO standard, companies began to use these models
as a fundamental tool for the development of software product applying quality
parameters.
However, the ISO 9126 today really is not used, since it was updated by the ISO
25000, which actually consists of a set of standards, as we will see in the next
chapter.
ISO
9126
Standards
related to the
quality of the
software
product
ISO
25000
Figure 3 – Standards related to the quality of the software product
These standards define a quality model mainly composed by 3 components:
 Internal: Refers to the quality of the code of the software (development)

 External: This refers to the quality of the execution of the software
(production)
 Use: Refers to the use of the software (use from the point of view of the user)
Use Internal
External
Figure 4 – Quality model of ISO 9126 and ISO 25000
On the other hand, this model also provides other 10 parameters, which are known
as "characteristics", that in turn, each feature, is also composed of multiple attributes.
These 10 characteristics related to the quality of the software product are the
following:
 Functional suitability: Capacity of the software product to provide functions

which meet stated needs, when the product is used under the specified
conditions.
 Performance efficiency: Performance relative to the amount of resources

that are used, under certain conditions.
 Compatibility: Capacity of 1, or various systems or components, to exchange
information and/or perform its functions, when they share the same
environment (software or hardware).
 Usability: Ability that the software product can be understood, understood,
used, and that appeal is for the user, when it is used under certain conditions.
 Reliability: Ability of a system or a component, that can perform their
functions required, when it is used under certain conditions and for a period
of time.
 Security: Ability to protect information, in such a way that persons, or also
the systems, cannot access to information which do not have access.
 Maintainability: Capability of the software product to be modified in a way to
effectively and efficiently, by evolving needs, corrective or perfective.
 Portability: Capacity of the software product, or a component, can be
transferred, in an effective and efficient way, from a hardware, software,
operational or use environment, to another.
Functional Performance
Compatibility Usability
suitability efficiency
Reliability Security Maintainability Portability
Figure 5 – 10 characteristics about the quality of the software product
Each of these characteristics, in addition, has a number of attributes, we are also

going to see below in each case:
Functional suitability
Functional
completeness
Functional
correctness
Functional
appropriateness
Figure 6 – Attributes of the functional suitability
 Functional completeness: Degree in which a set of capabilities covers all

the tasks and objectives of user specified.
 Functional correctness: Capacity of the product, or a system, to provide
correct results, and the level of precision required.
 Functional appropriateness: Capability of the software product, to provide
a set of functions appropriate for the tasks and objectives specified by the
user.
Performance efficiency
Time behaviour
Resource
utilization
Capacity
Figure 7 – Attributes of the performance efficiency

 Time behavior: Response time, and processing, and ratios of throughput of

a system when it performs its functions under certain conditions, in relation to
an established benchmark.
 Resource utilization: Quantities and types of resources used when the
software performs its function under certain conditions.
 Capacity: Degree in which the limits of a parameter of a product or system,
comply with the requirements.
Compatibility Co-existence
Interoperability
Figure 8 – Attributes of the compatibility
 Co-existence: Product capacity to coexist with other software, in a common

environment, sharing resources.
 Interoperability: Ability of two or more systems or components to exchange
information and to use the information exchanged.
Appropriateness
recognizability
Learnability
Usability
Operability
User error
protection
User interface
aesthetics
Accessibility
Figure 9 – Attributes of the usability

 Appropriateness recognizability: Capacity of the product that allows the

user to understand whether the software is suitable for their particular needs.
 Learnability: Product capability that allows the user to learn its application.
 Operability: Product capability that allows the user to use it easily.
 User error protection: Capacity of the system to protect users to commit
errors.
 User interface aesthetics: Capacity that the user interface can satisfy the
interaction of the user.
 Accessibility: Product capability that allows that it can be used by users with
certain characteristics and disabilities.
Maturity
Reliability
Availability
Fault tolerance
Recoverability
Figure 10 – Attributes of the reliability
 Maturity: Capacity of the system to meet the needs of reliability under normal
conditions.
 Availability: Capacity of the system, or component, to be available and
accessible when required.
 Fault tolerance: Ability of the system, or component, to operate according to
provisions against possible failures of hardware or software.
 Recoverability: Capacity of the software product to recover any lost data,
and restore the system in case of interruption or failure.
Confidentiality
Integrity
Security
Non-repudation
Authenticity
Accountability
Figure 11 – Attributes of security
 Confidentiality: Ability to protect information against unauthorized

access.
 Integrity: Capacity of the system, or component, to prevent unauthorized
modification.
 Non-repudiation: Capacity to demonstrate that actions or events have
taken place, so that these actions or events may not subsequently be
repudiated.
 Authenticity: Ability to trace clearly the actions of an entity.
 Accountability: Ability to demonstrate the identity of a resource, or a
subject.
Modularity
Maintainability
Reusability
Analyzability
Modifiability
Testability
Figure 12 – Attributes of the maintainability
 Modularity: Ability of a system that allows a change in a component to

have a minimum impact on other components.
 Reusability: Capacity of an asset that can permit that it can be used in
more than one software system, or in the construction of other assets.
 Analyzability: Ease with which evaluate the impact that can have a
change, in the rest of the software, diagnosing deficiencies, or the causes
of the failure of the software, or by identifying the parts that must be
modified.
 Modifiability: Product capability that allows that this be modified
effectively and efficiently, without introducing defects, or without degrading
performance.
 Testability: Ease with which you can establish criteria of evidence for a
system or component, and ease with which tests may be done to
determine if these criteria are met.
Portability
Adaptability
Installability
Replaceability
Figure 13 – Attributes of the portability

 Adaptability: Capacity of the product that allows to be adapted effectively,

and efficiently, to different hardware environments, software, operational
or use.
 Installability: Ease with which a product can install or uninstall without
problems in a given environment.
 Replaceability: Capacity of a product so that this can be used instead of
other product software determined, with the same purpose, and in the
same environment.
2.1.4- Standard ISO/IEC 25000 (SQuaRE)
Arrived to this point, already know that the more important standard international,
with recognition world, related to the quality of the software product is the ISO / IEC
25000, that also is often know as SQuaRE, by its initial "Software Quality
REquirements and Evaluation". Therefore, we will see with a little more detail the
structure of this standard.
ISO/IEC 25000 is actually composed by a series of standards, which can be

grouped into 5 groups:
 Division for the quality management: Composed by the group of

standards ISO/IEC 2500n
 Division for quality model: Composed by the group of standards
ISO/IEC 2501n
 Division for the quality measurement: Composed by the group of
standards ISO/IEC 2502n
 Division for the requirements of the quality: Composed by the group
of standards ISO/IEC 2503n
 Division for the quality evaluation: Composed by the group of standards
ISO/IEC 2504n
ISO/IEC 2501n ISO/IEC 2502n
ISO/IEC 2500n
ISO/IEC 2503n ISO/IEC 2504n
Figure 14 – Main groups of ISO/IEC 25000 standards

Then we will see the standards that make up each of these groups.
ISO/IEC
2500n
ISO/IEC
25000
ISO/IEC
25001
Figure 15 – Standards of ISO/IEC 2500n
The series of standards ISO/IEC 2500n basically defines models, terms and
common definitions that may be used or referenced by the standards of ISO/IEC
25000 series. On the other hand, ISO/IEC 2500n is composed by the following
standards:
 ISO/IEC 25000 – Guide to SQuaRE: Defines the architecture of the

SQuaRE, the terminology of the family of standards of this series,
including a summary of each party, as well as reference models.
 ISO/IEC 25001 – Planning and Management: Defines a set of
requirements and guidelines, to manage the assessment and specification
of the software product requirements.
ISO/IEC
2501n
ISO/IEC
25000
ISO/IEC
25001
The series of standards ISO/IEC 2501n includes detailed models of quality,

including features for the internal, external quality and use of the software product.
On the other hand, ISO/IEC 2501n is composed by the following standards:
 ISO/IEC 25010 – System and software quality models: Establishes a

model of quality for the software product, and the quality in use. On the
other hand, it also defines a number of features and quality attributes to
evaluate the software product.
 ISO/IEC 25012 – Data Quality model: Establishes a global model for the
quality of the data, which may be applicable to the data that is stored in a
structured way, and furthermore is a part of an information system.
ISO/IEC
2502n
ISO/IEC
25020
ISO/IEC
25021
ISO/IEC
25022
ISO/IEC
25023
ISO/IEC
25024
The series of standards ISO/IEC 2502n includes a reference model for the
measurement of the quality of the product, including definitions of quality measures
(internal, external and in use), as well as practical guidelines for its implementation.
On the other hand, ISO/IEC 2502n is composed by the following standards:
 ISO/IEC 25020 – Measurement reference model and guide:

Establishes a common model of elements for the measurement of the
quality of the software product, including also a guide to select or develop,
and implement the measures proposed by other ISO (for example,
ISO/IEC 9126).
 ISO/IEC 25021 – Quality measure elements: It is a set of metric base,
that can be used throughout the software life cycle.
 ISO/IEC 25022 – Measurement of quality in use: Establishes specific

metrics to measure the quality of use of the product.
 ISO/IEC 25023 – Measurement of system and software product
quality: Establishes specific metrics for the measurement of the quality of
products and software systems.
 ISO/IEC 25024 – Measurement of data quality: Establishes specific
metrics for the measurement of the quality of the data.
ISO/IEC
2503n
ISO/IEC
25030
The series of standards ISO/IEC 2503n allows you to specify quality requirements
which may be used in the process of definition of the software product quality
requirements. On the other hand, ISO/IEC 2503n is composed by the following
standard:
 ISO/IEC 25030 – Quality requirements: Provides a series of
recommendations for the establishment of quality requirements for the
software product.
ISO/IEC
2504n
ISO/IEC
25040
ISO/IEC
25041
ISO/IEC
25042
ISO/IEC
25045
The series of standards ISO/IEC 2504n provides a set of requirements,

recommendations and guidelines to perform the process of evaluation of the
software product. On the other hand, ISO/IEC 2504n is composed by the following
standards:
 ISO/IEC 25040 – Evaluation reference model and guide: Defines a

generic reference model for evaluation.
 ISO/IEC 25041 – Evaluation guide for developers, acquirers and
independent evaluators: Sets a number of requirements and
recommendations for the implementation of the evaluation of the software
product, from the point of view of the developers, from the point of view of
customers (entity that buys the software), and from the point of view of the
independent evaluators.
 ISO/IEC 25042 – Evaluation modules: Sets the content of the
documentation that will be used to describe the evaluation module.
 ISO/IEC 25045 – Evaluation module for recoverability: Provides a
module for the assessment of the recoverability.
Moreover, also there is a set of standards that are used as extension, which contain
aspects more specific, and can be used as complement to the standards seen until
now.
These complementary standards, are defined between the number ISO/IEC 25050
- ISO/IEC 25099, the most noteworthy being the following:
 ISO/IEC 25051 – Requirements for quality of Commercial Off-The-

Shelf (COTS) software product and instructions for testing:
Establishes requirements for the product software COTS.
 ISO/IEC 25062 – Common industry format for usability test reports:
Provides basic information on how to report the results of a test of usability
in a specific context of use.
2.1.5- Tools for the assessment of the quality of the software product
Some tools that you can use to ensure the quality of the software product are the
following:
 ChecKing QA: Allows to control elements of the software development

process, and also allows you to control the elements that can be analyzed,
as for example the source code, documentation, scripts, etc.
 Kiuwan: Lets analyze code and measure the technical quality of the
software. It has a scorecard based on the ISO/IEC 9126, it runs in the
cloud, in SaaS mode.
 PMD: Allows to analyze statically source code, identifying problems, such
as for example the repetition of code, or the use of nested ifs, etc. Mainly
be used for Java.
 Check Style: Also allows analysis of static source code, checking if there
are style rules. Mainly it is also used for Java.
 SONAR: Allows you to collect, analyze, and visualize source code metrics.
Mainly used for Java, although it provides support for other languages.
 Google CodePro Analytix: Allows you to evaluate code, defining metrics,
analyze dependencies, generate unit testing, etc.
 Simian: Allows to detect duplicated code.
2.1.6- Example of an environment for the evaluation of the software product
Now that you know which are the parameters that can be used to measure the
quality of a software product, we can see a small example, very simple, about how
to assess a software product.
Imagine that we have developed a software, and we want to assess their quality
based on the characteristics and the attributes that we have seen in a previous
section.
If we want to evaluate each of the characteristics and attributes, we can use a table
such as the following:
Characteristic Attribute Complies Not Not

complies required
Functional Functional completeness
suitability Functional correctness
Functional appropriateness
Performance Time behavior
efficiency Resource utilization
Capacity
Compatibility Co-existence
Interoperability
Usability Appropriateness
Learnability
Operability
User error protection
User interface aesthetics
Accessibility
Reliability Maturity
Availability
Fault tolerance
Recoverability
Security Confidentiality
Integrity
Non-repudiation
Authenticity
Accountability
Maintainability Modularity
Reusability
Analyzability
Modifiability
Testability
Portability Adaptability
Installability
Replaceability
Table 1 – Evaluation of characteristics and attributes
So, we will assess for each attribute of each characteristic, the software that you
want to evaluate.
So, after completing the table with data:
Characteristic Attribute Complies Not Not

complies required
Functional Functional completeness 1
suitability Functional correctness 1
Functional appropriateness 1
Performance Time behavior 1
efficiency Resource utilization 1
Capacity 1
Compatibility Co-existence 1
Interoperability 1
Usability Appropriateness 1
Learnability 1
Operability 1
User error protection 1

User interface aesthetics 1
Accessibility 1
Reliability Maturity 1
Availability 1
Fault tolerance 1
Recoverability 1
Security Confidentiality 1
Integrity 1
Non-repudiation 1
Authenticity 1
Accountability 1
Maintainability Modularity 1
Reusability 1
Analyzability 1
Modifiability 1
Testability 1
Portability Adaptability 1
Installability 1
Replaceability 1
Table 2 – Evaluation of characteristics and attributes with data
If we now make an analysis of the results obtained, classified by features, we have

the following:
Characteristic Complies Not complies Not required Total

Functional 3 3
suitability
Performance 3 3
efficiency
Compatibility 1 1 2
Usability 5 1 6
Reliability 2 1 1 4
Security 2 2 1 5
Maintainability 1 3 1 5
Portability 1 1 1 3
Total 18 9 4 31
Table 3 – Results of the evaluation
We see, therefore, that we have evaluated a total of 31 attributes, of which 18 comply

with their duties (58% of the total), 9 do not meet (29% of the total), and 4 are not
required (13% of the total).
With these results, and the definition of an acceptance criteria:
Range Value Acceptance

0% - 30% Does not complies No
requirements
31% - 50% Minimally complies No
requirements
51% - 70% Complies properly Yes
71% - 100% Exceeds the Yes
requirements
Table 4 – Acceptance criteria
Given that the degree of compliance is 58%, and according to the defined
acceptance criteria table, is within the margin of 51% - 70%, we can conclude that
software adequately meets a minimum quality, so that we can accept it as well.
However, it should be noted that these tables are indicative, and can be developed
with other values.
2.2.1- Quality of the service (ISO 20000)
We have talked about improvement of processes, and improving quality of the

software product, but we need also see the quality from the point of view of the
service.
I.e., if we consider that we need to provide a service to a client, which can be the
development and maintenance of a software product, we can also improve the
quality.
There are several international standards, but we are going to focus on ISO/IEC
20000, because it is one of the international standards with greater recognition,
related to the management of IT services.
2.2.2- Introduction to ISO/IEC 20000
The ISO/IEC 20000 is very similar to ITIL standard, although ITIL mainly defines a
set of best practices for IT service management and ISO 20000 in addition clearly
defines a model of continuous improvement, based on the PDCA cycle.
On the other hand, the companies can be certified in ISO/IEC 20000, as they can be
also certified ISO 27001, ISO 15504, or ISO 9001, etc. But they cannot be certified
in ITIL, because it is not an ISO standard (you can certify individuals in ITIL, but not
companies, because ITIL does not have a scheme of certification for companies).
ISO 20000, like other management system, has many common points with other
ISOs, and shares many elements with the ISO 27001 (in fact, one of the processes
included in ISO 20000, is the process of information security management).
This standard aims to improve or ensure the quality of the service, so is intended
primarily for companies that provide technology services, such as for example
companies which develop software, and offer a service of maintenance of this
software.
ISO 20000 was developed in 2005, and was subsequently revised in 2011, which is
now the current version of this standard. For the development of the first version,
was used as a basis the BS 15000, which was a British standard developed by BSI
(British Standards Institution).
2.2.3- Structure of the ISO/IEC 20000
This standard, similar to the ISO 15504 we saw in module 1, consists of several
parts, which are detailed below:
 ISO 20000-1 – Service management system requirements: This is

actually the standard that is certifiable, since it defines requirements for
the establishment of a service management system.
 ISO 20000-2 – Guidance on the application of service management
systems: Offers a guide to the implementation of a service management
system, based on the requirements of ISO/IEC 20000-1.
 ISO 20000-3 – Service providers: Provides a guide for the definition of
the scope and applicability of the standard.
 ISO 20000-4 – Process assessment model: Offers a process reference
model.
 ISO 20000-5 – Exemplar implementation plan for ISO/IEC 20000-1:
Provides an example about the implementation of the requirements of the
ISO/IEC 20000-1.
 ISO 20000-9 – Guidance on the application of ISO/IEC 20000-1 to
cloud services: Offers a guide for the implementation of the ISO 20000-
1 in service providers that offer cloud services.
 ISO 20000-10 – Concepts and terminology: Offers a list of concepts and
terminology of the ISO/IEC 20000.
 ISO 20000-11 – Guidance on the relationship between ISO/IEC 20000-

1:2011 and service management frameworks: ITIL@: Provides a guide
to the relationship between the ISO/IEC 20000-1 and ITIL.
ISO 20000-1 • Service management system requirements
• Guidance on the application of service

ISO 20000-2 management systems
ISO 20000-3 • Service providers
ISO 20000-4 • Process assessment model
• Exemplar implementation plan for ISO/IEC

ISO 20000-5 20000-1
• Guidance on the application of ISO/IEC 20000-

ISO 20000-9 1 to cloud services
ISO 20000-10 • Concepts and terminology
• Guidance on the relationship between ISO/IEC

ISO 20000-11 20000-1:2011 and service management
frameworks: ITIL@
Figure 20 – Parts of ISO/IEC 20000

2.2.4- Global management of ISO/IEC 20000
The most important part of ISO/IEC 20000 is the part 1 (requirements definition),
and the part 2 (best practices for implementing the processes).
Therefore, to be able to manage an IT service, we need the requirements of

ISO/IEC 20000-1 (requirements for the establishment of a PDCA and processes),
and best practices of the ISO/IEC 20000-2 for the implementation of the
processes.
These processes that are based on the ISO/IEC 20000, are mainly grouped into 4
groups:
 Service delivery processes

 Control processes
 Resolution processes
 Relationship processes
Each of which contains a series of processes, which we can see below:
Service delivery processes
Capacity management
Service continuity and availability

management
Service level management
Service reporting
Information security management
Budgeting and accounting for

services
Figure 21 – Service delivery processes

 Capacity management: This process tries to manage that the service is

provided with the agreed capacity. Therefore, in addition to constantly
monitor the service, you perform a trend analysis, i.e. measure the current
capacity, and estimate how it will evolve in the future.
 Service continuity and availability management: This process allows
mechanisms so that, in the event that an unforeseen event occurs, the
service is not interrupted, or if it is interrupted, there is a plan to retrieve it.
With respect to availability, it is important that the service is available in
the conditions in which has been established by contract (usually in
service level agreements).
 Service level management: Allows you to define service levels, from
which the service will be provided. These levels must agree formally
between customer and the company that provides the service.
 Service reporting: The idea of this process is to keep informed, on a
regular basis, the customer about the status of the service by notifying
potential incidents, complaints, etc.
 Information security management: The main objective of this process
is to manage all matters related to the information security, considering
the risk management, the information security policy, security information
incidents, etc.
 Budgeting and accounting for services: The main objective of this
process is to bring control over budgets and basic accounting related to
the service. I.e. basically aims to take control of the expenses incurred by
the service, and the budgets of possible improvements that may be
needed (this process does not address the economic benefits of the
service).
Control processes
Configuration management
Change management
Release and deployment

management
Figure 22 – Control processes

- Configuration management: This process sets out a number of elements of

the service configuration, which we can consider as configuration items to
provide the service. For the registration of these configuration items, it is
necessary to define a CMDB, which must ensure its integrity through periodic
revisions. Before launching a new service, it is usually set a base line with the
current configuration of the configuration items of the service.
- Change management: This process manages any change that is produce in
the service. To do this, this process should consist of a stage of request for
change, another stage of review, another of approval, and finally another
stage of implementation of the change. During the change, something goes
wrong, we can have a procedure of roll-back.
- Release and deployment management: The Mission of this process is to
manage everything concerning to the delivery of the service and their
subsequent deployment. For example, if we need to deliver a software
product, first we need to deliver an executable, and after we need to install it
in the production environment of the customer. In this case, can exist a
delivery of emergency, that the client requires with maximum priority.
Resolution
processes
Incident and
service request
management
Problem
management
Figure 23 – Resolution processes
- Incident and service request management: With this process we can

identify possible issues related to the service. In this case, it is also important
to have a knowledge base of the incidents registered and treated, because if
we have an incident that have been treated in the past, the information
registered can help us. It is also important to define different levels of
incidents, and you can assign to each level resolution times (example: If the
incidence is High, resolution time must be less than 24 hours, but if it is Low,
the resolution time can be more than 48 hours, etc.)
- Problem management: This process is similar to the previous one, with the
difference that when an incidence is repeated and is unable to close
permanently, is considered a problem, and in that case we need to search the
origin of the problem. Here is also important to have a knowledge base.
Relationship
processes
Business
relationship
management
Supplier
management
Figure 24 – Relationship processes
 Business relationship management: This process is related to the

relationship that exists between the company that and its clients. So, it is
necessary that the company establish a channel for possible claims, and
also need to measure the satisfaction of customers with respect to the
service provided.
 Supplier management: With this process we can evaluate suppliers that
we need to offer the service, i.e. if we provide a software maintenance
service, we can need to outsource a service cloud, so, we will need to
establish quality requirements, and select a provider based on these
requirements.
2.2.5- Model and key areas
In addition to the processes you have seen until now, ISO 20000 is based on a model
of continual improvement, like any other ISO management system, for example ISO
9001, ISO 27001, ISO 22301, etc.
This model of continual improvement, is based on 4 stages or key areas:

Plan Do
Act Check
Figure 25 – Continual improvement model
This model is also commonly known as the Deming cycle, and in the case of the
management of a IT service, you can start with planning (Plan) of the service (project
plan, definition of activities/resources, development of documentation, resources),
subsequently you need to implement everything that has been planned in the
previous stage (Do), then checked that everything that has been implemented is
according to what we planned (Check), and finally if any inconsistency is detected
during the review, you need to perform corrective actions for the treatment and
resolution (Act).

Modulo 2 - Formulacion y Evaluacion de Proyectos

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Modulo 2 - Formulacion y Evaluacion de Proyectos

Hochgeladen von

Copyright:

Verfügbare Formate

Estructura para el diseño de cursos virtuales

Versión 1. Noviembre de 2016

MODULE N° 2 : Quality of the product

2. INFORMACIÓN ESPECÍFICA DEL MÓDULO

Program Software engineering

1.- Quality of the product

2.- Quality of the service (ISO 20000)

INTRODUCTION TO THE MODULE N° 2

COMPETENCES OF THE MODULE 2 AND THEMATIC STRUCTURE

Competences of the module Thematic structure to address in the module

Competence 1 and 2: Identify 1.1.- Introduction

Competence 3 and 4: To know 2.1.- Introduction to ISO/IEC 20000

CONTENT OF THE MODULE N° 2

1. Thematic unit 2: Quality of the product

1.2. Conceptual framework

1.2.2. Quality of the software product

1.2.3. Main standards about the quality of the software product

1.2.4. Standard ISO/IEC 25000 (SQuaRE)

1.2.6. Example of an environment for the evaluation of the software product

It Is important to know how to evaluate the quality of a software product,

1.2.7. Introduction to ISO/IEC 20000

ISO/IEC is an international standard related to the quality of the IT service, and

1.2.8. Structure of the ISO/IEC 20000

1.2.9. Global management of ISO/IEC 20000

1.3.1. Model and key areas

Como estandarizar la evaluación de la calidad del producto software - 1:

Cómo estandarizar la evaluación de la calidad del producto software – 2 :

1.6. Resources for the study

Bibliographic Location (the link web or the database)

2. Thematic unit 2 – Quality of the product

In software engineering is generally accepted that companies improve their

Final client satisfied

2.1.2- Quality of the software product

Therefore, it is necessary to define some criteria or quality parameters, and unify

These parameters of quality of the product, addressed:

 The operation of the software products

Figure 2 –McCall model

Subsequently, specifically 1 year later, Boehm developed and published a model

2.1.3- Main standards about the quality of the software product

Figure 3 – Standards related to the quality of the software product

These standards define a quality model mainly composed by 3 components:

 Internal: Refers to the quality of the code of the software (development)

Figure 4 – Quality model of ISO 9126 and ISO 25000

 Functional suitability: Capacity of the software product to provide functions

 Performance efficiency: Performance relative to the amount of resources

Reliability Security Maintainability Portability

Figure 5 – 10 characteristics about the quality of the software product

Each of these characteristics, in addition, has a number of attributes, we are also

Figure 6 – Attributes of the functional suitability

 Functional completeness: Degree in which a set of capabilities covers all

Figure 7 – Attributes of the performance efficiency

 Time behavior: Response time, and processing, and ratios of throughput of

Figure 8 – Attributes of the compatibility

 Co-existence: Product capacity to coexist with other software, in a common

Figure 9 – Attributes of the usability

 Appropriateness recognizability: Capacity of the product that allows the

Figure 10 – Attributes of the reliability

Figure 11 – Attributes of security

 Confidentiality: Ability to protect information against unauthorized

 Modularity: Ability of a system that allows a change in a component to

Figure 13 – Attributes of the portability

 Adaptability: Capacity of the product that allows to be adapted effectively,

2.1.4- Standard ISO/IEC 25000 (SQuaRE)