A0043 MAI Calidad de Software ED1 V1 2017

Comercio Exterior y Aduanas
1
MANUAL AUTOFORMATIVO
CALIDAD
DE
SOFTWARE
Autores:
Henry Joe Wong Urquiza
Calidad de Software
Primera edición
Huancayo, febrero de 2017
De esta edición
© Universidad Continental
Av. San Carlos 1980, Huancayo-Perú
Teléfono: (51 64) 481-430 anexo 7361
Correo electrónico: recursosucvirtual@continental.edu.pe
http://www.continental.edu.pe/
Dirección: Emma Barrios Ipenza

Edición: Eliana Gallardo Echenique
Asistente de edición: Andrid Poma Acevedo
Asesora didáctica: Mary Karina Calle Loayza
Corrección de estilo: Diego Martín Eguiguren Salazar
Diseño y diagramación: José Maria Miguel Jáuregui Muñico
Todos los derechos reservados. Cada autor es responsable del contenido de su propio texto.
Este manual autoformativo no puede ser reproducido, total ni parcialmente, ni registrado en o transmitido por
un sistema de recuperación de información, en ninguna forma ni por ningún medio sea mecánico, fotoquímico,
electrónico, magnético, electro-óptico, por fotocopia, o cualquier otro medio, sin el permiso previo de la Universidad
Continental.
ÍNDICE
Introducción 7
Organización de la asignatura 9
Resultado de aprendizaje de la asignatura 9
Unidades didacticas 9
Tiempo minimo de estudio 9
UNIDAD I: “Introducción a la Calidad de Software” 11
TEMA N° 1: ¿Qué es la gestión de Calidad según PMI? 12

1 Definición de calidad 12
1.1. Introducción 12
1.2. Definición de calidad 12
2 Definición de servicios de calidad 12
2.1. Componentes de servicios de calidad 13
2.2. Objetivos de servicios de calidad 13
3 Calidad del producto vs. calidad del servicio 13
4 Planteamiento, aseguramientoy control de calidad 13
5 Modelos y normas de Calidad 14
TEMA N° 2: Modelo y Norma de Procesos 15

1 NTP/ISO 9001: mejora de procesos 15
1.1. Definición de procesos 15
1.2. Mejora de procesos 15
2 Desarrollo del sistema de gestión de la calidad 16
3 Modelo de capacidad de madurez del software CMMI : mejora continua. Niveles de madurez. 16
TEMA N° 3: Fundamentos de calidad 17

1 NTP/ISO/IEC 15504: calidad de software 17
a. Estructura 17
b. Caracteristicas 17
2 Procesos de software y evaluación de procesos de software 18
a. Análisis 18
b. Diseño 18
c. Ejecución 18
3 Estandares y normas 18
4 Modelos de calidad 19
5 NTP/ISO/IEC 12207: metodologías y ciclo de vida del software 19
a. Procesos de Apoyo 19
b. Procesos principales 19
c. Procesos organizativos del ciclo de vida 19
6 NTP/ISO/IEC 9126 20
a. Calidad del producto 20
b. Modelo de calidad 20
c. Calidad interna y externa 20
d. Métricas internas y externas de Calidad 21
TEMA N° 4: Fundamentos de control de calidad 22
1 Pruebas de software 22
2 Defectos 22
Lectura seleccionada N° 1 23
Autoevaluación N° 1 24
Autoevaluación N° 2 24
Glosario de la unidad I 25
Bibliografía de la unidad I 26
Autoevaluación de la unidad I 27
Anexo 28
UNIDAD II: Planificación de la calidad 29
TEMA N° 1: GESTIÓN DE LA CALIDAD DEL SOFTWARE – NTP/ISO/IEC 12119 30

1 Objetivos 30
2 Aplicable a paquetes de software 30
3 Plan de calidad 30
4 Requerimientos de calidad y pruebas 31
TEMA N° 2: Procesos de calidad 32

1 Especificaciones del plan de pruebas 32
2 Trazabilidad 32
TEMA N° 3: Indicadores de gestión 34

1 Definición de indicadores 34
2 Tipos de indicadores y métricas 35
TEMA N° 4: Gestión de riesgos 36

1 Definición de riesgos 36
1.1. Amenaza 36
1.2. Vulnerabilidad 36
2 Plan de gestión de riesgos 36
3 Respuesta a riesgos 37
Lectura seleccionada Nº 1 38
Actividad Nº 1 39
Actividad Nº 2 39
Glosario de la unidad II 40
Bibliografia de la unidad II 41
Autoevaluación de la unidad II 42
Anexo 43
UNIDAD III: Aseguramiento de la calidad 45
TEMA N° 1: Revisiones o inspecciones estáticas relacionadas al ISQTB 46

1 Actividades de control de calidad de software 46
2 La gestión de requisitos 46
3 Meta modelo para la trazabilidad de requisitos 46
4 Usabilidad en el proceso de desarrollo de software 46
4.1. Contexto de aplicación de la usabilidad 46
4.2. Metricas de usabilidad 47
4.3. Métodos de evaluación de la usabilidad 47
TEMA N° 2: Pruebas o inspecciones dinámicas relacionadas al ISQTB 48
1 Proceso de pruebas 48
1.1. Planificación 48
1.2. Control de pruebas 48
1.3. Análisis 49
1.4. Diseño 49
1.5. Implementación 49
1.6. Ejecución 49
1.7. Salida y generación de informes 49
1.8. Actividades de cierre y pruebas 49
2 Tipos de pruebas 50
2.1. Pruebas funcionales 50
2.2. Pruebas de robustez 50
2.3. Pruebas de rendimiento 50
2.4. Pruebas de seguridad 50
2.5. Pruebas de usabilidad 50
Actividad Nº 1 52
Actividad Nº 2 52
Glosario de la unidad III 53
Bibliografía de la unidad III 54
Autoevaluación de la unidad III 55
Anexo 56
UNIDAD IV: Control de calidad 57

CONTENIDOS 57
TEMA N° 1: Pruebas de software 58
1 Ciclo de vida de las pruebas de software 58
1.1. Análisis 58
1.2. Diseño 58
1.3. Ejecución 58
2 Estrategia de las pruebas de software 58
2.1. Usuario humano 59
2.2. Usuario fuente de datos 59
2.3. Usuario de red 59
2.4. Usuario API 59
2.5. Usuario configuración 59
3 Plan de pruebas 59
4 Estimación de pruebas 60
4.1. Estimación por objetos 60
4.2. Estimación por casos de uso 60
5 Calidad de los almacenes y modelos de datos (calidad de datos) 61
6 Creación de la estructura de Calidad de Datos 61
7 Medición de los atributos de calidad 61
TEMA N° 2: Tipos de pruebas 62

1 Pruebas unitarias, integración y de sistemas 62
1.1. Pruebas unitarias 62
1.2. Pruebas integrales 62
1.3. Pruebas de sistemas 62
1.4. Pruebas de aceptación 62
2 Pruebas de caja blanca y caja negra 62
2.1. Pruebas de caja blanca 62
2.2. Pruebas de caja negra 62
3 Pruebas funcionales y no funcionales 63
3.1. Pruebas funcionales 63
3.2. Pruebas no funcionales 63
TEMA N°3: Uso de herramientas y técnicas 64
1 Calidad de los Sistemas Web 64
1.1. El modelo de Navegación 64
1.2. Contexto de Exploración 64
1.3. Calidad en las aplicaciones de los mercados electrónicos 64
1.4. Valoración de la calidad 64
2 Herramienta de Manejo de Plan de Pruebas 64
3 Herramienta de Manejo de Incidencias 65
4 Software de Ejecución de Pruebas 65
Actividad Nº 1 67
Actividad Nº 2 67
Glosario de la unidad IV 68
Bibliografía de la unidad IV 69
Autoevaluación de la unidad IV 70
Anexo 71
INTRODUCCIÓN
C urso de especialidad de calidad en la carrera

de Ingeniería de sistemas e informática de la
modalidad a distancia, de carácter teórico-práctico,
Organiza tu tiempo para que obtengas buenos
resultados. La clave está en encontrar el equilibrio
entre tus actividades personales y las actividades
dirigido a los estudiantes de pregrado. Busca que asumes como estudiante. El estudio a distancia
desarrollar la competencia general del pensamiento requiere constancia, por ello es necesario encontrar
crítico y la competencia específica de participar en la motivación que te impulse a hacerlo mejor cada
equipos multidisciplinarios, desarrollando sus tareas día.
con profesionales de diferentes especialidades o
dominios de aplicación.
En general, los contenidos propuestos en el manual

autoformativo se dividen en cuatro unidades: En la
Unidad I se te dará una introducción a la calidad,
donde conocerás los conceptos relacionados a ella;
luego, en la Unidad II, se te explicará cuáles son los
procesos necesarios para realizar la planificación
de la calidad; en la Unidad III, abordaremos los
conceptos sobre el aseguramiento de la calidad y en
la Unidad IV cuáles son los principales controles de
calidad.
Es recomendable que desarrolles una permanente

lectura de estudio de los contenidos desarrollados
y de los textos seleccionados que amplían o
profundizan el tratamiento de la información, junto
a la elaboración de resúmenes y una minuciosa
investigación vía internet. El desarrollo del manual
se complementa con autoevaluaciones, que son una
preparación para la prueba final de la asignatura.
El Autor
CALIDAD DE SOFTWARE
PRESENTACIÓN DE LA ASIGNATURA
COMPETENCIAS DE LA ASIGNATURA:
Al término de la asignatura el estudiante será capaz de elaborar un correcto Plan de Calidad de Software, basándose en
las normativas que la ISO y el modelo CMMI para su implementación.
UNIDADES DIDACTICAS:
UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
Introducción a la Calidad de
Planificación de la calidad Aseguramiento de la calidad Control de calidad
Software
Resultado de aprendizaje Resultado de aprendizaje Resultado de aprendizaje Resultado de aprendizaje
Al finalizar la unidad, el Al finalizar la unidad, el estudiante Al finalizar la unidad, el estudiante Al finalizar la unidad, el
estudiante describe los conceptos explica la importancia del plan de explica la integración del SQA dentro estudiante explica el ciclo de
de calidad a nivel de produc- calidad en la gestión de un proyecto del proceso de desarrollo de software vida de las pruebas de software
to y servicio, asociándolos a la de software. y cómo contribuye a la calidad del dentro de un proyecto de
Ingeniería de software. mismo. sistemas y lo relaciona con las
actividades que impactan en la
calidad del software.
TIEMPO MINIMO DE ESTUDIO:

UNIDAD I UNIDAD II UNIDAD III UNIDAD IV
1era. semana y 3era. semana y 5ta. semana y 7ma. semana y
2da. semana 4ta. semana 6ta. semana 8va. semana
24 horas 24 horas 24 horas 24 horas
CALIDAD DE SOFTWARE
UNIDAD I: Introducción a la Calidad de Software 11
UNIDAD I: Introducción a la calidad de software
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I
CONTENIDOS EJEMPLOS ACTIVIDADES
AUTOEVALUACIÓN BIBLIOGRAFÍA
ORGANIZACIÓN DE LOS APRENDIZAJES
Resultado de aprendizaje de la Unidad I:

Al finalizar la unidad, el estudiante describe los conceptos de calidad a nivel de producto y servicio, asociándolos a la ingeniería de software.
CONOCIMIENTOS HABILIDADES ACTITUDES

Tema N.º 1: ¿Qué es la gestión de Calidad según PMI? 1. Describe los conceptos de Calidad a nivel de Valora la importancia de la Calidad en el De-
1. Definición de Calidad producto y servicio asociándolo a la Ingenie- sarrollo de Software
2. Definición de Servicios de Calidad ría de Software.
3. Calidad del producto vs calidad del proceso.
4. Planeamiento, Aseguramiento y Control de 2. Describe los principios de la Gestión de Ca-
calidad lidad y explica como la mejora continua de
5. Modelos y normas de calidad procesos permite la calidad en los proyectos y
servicios.
Tema N.º 2: Modelo y Norma de Procesos
4. NTP/ISO 9001: Mejora de Procesos
5. Desarrollo del sistema de Gestión de la Actividad N.º 1
calidad Los estudiantes participan en el foro de discu-
6. Modelo de Capacidad de Madurez del sión sobre los criterios de calidad
Software CMMI : Mejora Continua. Niveles
de madurez. Actividad N.º 2
Los estudiantes participan en el foro de discu-
Lectura seleccionada N.° 1 sión sobre pruebas de software
Tema N.º 3: Fundamentos de calidad Tarea Académica N° 1

7. NTP/ISO/IEC 15504: Calidad del Software
a. Estructura
b. Características
8. Procesos de software y Evaluación de
Procesos de Software
9. Estándares y normas
10. Modelos de calidad
11. NTP/ISO/IEC 12207: Metodologías y Ciclo
de Vida del Software
a. Proceso de apoyo
b. Procesos principales
c. Procesos organizativos del ciclo de vida
12. NTP/ISO/IEC 9126
a. Calidad del producto.
b. Modelo de calidad
c. Calidad interna y externa
d. Métricas internas y externas de Calidad
Tema N.º 4: Fundamentos de Control de Calidad

1. Pruebas de Software
2. Defectos
Lectura seleccionada N.° 2: NTP/ISO/IEEE 15504,

12207 Y 9126
Autoevaluación de la Unidad I
12 UNIDAD I Introducción a la Calidad de Software
TEMA N° 1: ¿Qué es la gestión de Calidad según PMI?
En el siguiente capítulo usted comprenderá los diferentes conceptos sobre Calidad a nivel de producto o servicio asociado a
la Ingeniería de Software y además será capaz de poder describir los principios de la Gestión de la Calidad y explicara como
la mejora continua de procesos permite la Calidad en los proyectos o servicios.
1 Definición de calidad
1.1. Introducción
Para darle una introducción sobre lo que es Calidad, es bueno que analice el siguiente video que nos explica que pasaría
si los programadores hicieran construyeran un avión (La URL del video es la siguiente https://www.youtube.com/wat-
ch?v=UZq4sZz56qM
Figura 1: Si los programadores construyeran aviones

Fuente: (R.M.M., 2007)
Como pudo apreciar en el video a los Ingenieros de Sistemas, Software o carreras afines que construyen algún Software
piensan que construyen Software sin ningún estándar o procedimiento para poder tener un producto que sea de Calidad.
¿Pero que podemos entender sobre Calidad? Para entender dicho concepto le invito a que usted indique porque com-
praría una computadora de marca “AB” con otra computadora de marca “BC” ¿Qué criterio usted escogería para escoger
una computadora de la marca “AB” y no de “BC”?
1.2. Definición de calidad

Según la enciclopedia Larousse a la Calidad lo definen como “Conjunto de cualidades que constituyen la manera de ser
de una persona o cosa” (Larousse, 1999, p. 186), según esta definición podemos concluir que cuando adquirimos un
producto o servicio siempre nos fijamos en las características para poder decir que dicho producto o servicio es Calidad,
entonces la Calidad va a depender mucho de cada persona, porque para lo que uno es de Calidad para otra persona no
lo puede ser.
Según la norma ISO 8402 la Calidad lo define como “La totalidad de propiedades y características de un producto
o servicio que le confieren la capacidad de satisfacer las necesidades del Cliente” es por eso que un producto o
servicio para ser de calidad siempre tiene que satisfacer las necesidades de un Cliente, así el producto o servicio
internamente tenga alguna falla, si satisface la necesidad del Cliente será de Calidad.
Además de que un Producto o Servicio satisfaga la necesidad del Cliente tiene que ser accesible para el Cliente, eso quiero
indicar también para que un Producto o Servicio sea Calidad debe de ser accesible para el Cliente a un costo razonable,
para que de esa forma el Cliente se vuelva nuestro principal vendedor.
2 DEFINICIÓN DE SERVICIOS DE CALIDAD
Para poder explicar el concepto de Servicios de Calidad, primero debemos de explicar que es Servicio:
Se entiende por servicio a cualquier actividad o beneficio que una parte ofrece a otra; son esencialmente intangibles y no
dan lugar a la propiedad de ninguna cosa. En otras palabras, el servicio es una actividad realizada para brindar un beneficio
CALIDAD DE SOFTWARE
o satisfacer una necesidad. Su producción puede estar vinculada o no con un producto físico. (Abadi, 2004)
Con la definición anterior podemos concluir que para realizar un producto de Software debemos de tener un Servicio que
este alineado para poder construir productos de Calidad, porque son los cimientos necesarios para su construcción.
Entonces podemos definir que un Servicio de Calidad consiste en dar un Servicio a un Cliente que cumpla con las
expectativas que él está esperando.
2.1. Componentes de servicios de calidad

Según Abadi (2004), podemos decir que existen los siguientes componentes de servicios de calidad:
• C onfiabilidad: Es la capacidad de ofrecer un servicio sin fallas, de manera exacta y consistente, desde la primera vez
que un cliente solicita algún servicio.
• Accesibilidad: Cuando se ofrece un servicio al cliente, las empresas deben facilitar los accesos necesarios para que los
clientes puedan contactar con ellos fácilmente y puedan recibir el servicio que ellos necesitan de manera rápida y
oportuna.
• Seguridad: Los clientes siempre deben percibir que reciben un servicio con los principios de seguridad y que no hay
riesgo de usarlos: riesgo como que les roben la información personal (número telefónico, cuentas bancarias, etc.).
• Empatía: Cuando se ofrece un servicio, debemos ponernos en el lado del cliente para intuir qué es lo que espera y de
esa manera ofrecerle un servicio de calidad.
2.2. Objetivos de servicios de calidad

Los objetivos principales de una empresa, por lo general, son de poder sobrevivir en el tiempo y no desaparecer. Otra de
sus preocupaciones es la de seguir creciendo y lograr ser una empresa grande y reconocida. Como punto final, su obje-tivo
es generar utilidades.
Pero desde el punto de vista del cliente, los objetivos de un servicio de calidad deben ser los siguientes:
• L a satisfacción del cliente. Esto quiere decir que siempre debemos ponernos en el lugar del cliente para saber qué es
lo que espera y entregarle el servicio que él esté esperando.
• Las empresas que ofrecen servicios siempre deben estar mejorando y actualizándose, porque los procesos siempre
cambian en el tiempo y las necesidades del cliente también.
• Cuando ofrecemos los servicios también debemos ser eficientes para que de esa manera podamos generar productos
o servicios de calidad.
3 Calidad del producto vs. calidad del servicio
Como se explicó en los puntos anteriores, para poder crear un producto de calidad siempre hay que basarse en un proceso que
esté bien definido y normado por instituciones internacionales, como son las normas ISO, CMMI, entre otras, para que de esa
manera el producto que desarrollemos se encuentre avalado por un proceso de calidad.
Y como punto final, para poder ofrecer el producto debemos brindar servicios de calidad. De esa manera, nuestro cliente
percibirá que recibe un producto integral.
4 PLANTEAMIENTO, ASEGURAMIENTOY CONTROL DE CALIDAD
Usualmente cuando buscamos conceptos sobre calidad nos aparecen los siguientes conceptos que muchas de las veces nos
genera confusión, como es el caso de Control de Calidad y Aseguramiento de Calidad y según Abadi (2004) la diferencia seria
la siguiente:
Control de calidad Aseguramiento de calidad

Concepto • La calidad es “controlada” por • La calidad de “asegura” porque no
una sola persona (Administra- hay una sola persona encargada de
dor) mediante la inspección todo el control de calidad. Todo el
del producto depués de com- negocio se enfoca en asegurar la
pletada la producción. calidad de la producción.
Costo • Un cierto % de tasa de recha- • Se esperan cero rechazos - cada
zo se establece, por ejemplo producto debe pasar la inspección
2% de los productos pueden • Producción esbelta
fallar.
• Producción de desecho.
Procesos • Es era que la producción pare • La compañia espr para la produc-

-- ya que es costoso ción para corregir los errores.
• Asociado con la producción en • Se relaciona con la producción
masa celular
• Calidad termina con el trabajo • La calidad involucra los distribui-
dores y servicio postventa
Personas • La calidad es responsabilidad • La calidad es responsabilidad de
de una sola persona un equipo
• Liderazgo autocrático • Cultura de calidad total
• Una vía de comunicación • Liderazgo de consulta
• Comunicación de 360°
Figura 3: Control de Calidad VS Aseguramiento de la Calidad

Fuente: (Abaid, 2014)
5 Modelos y normas de Calidad
Existe diferentes Modelos y Normas de Calidad que se encuentran estipulados en la Norma ISO 9126 que es una estándar
para la evaluación de la calidad que lo pueda descargar de la siguiente ruta: https://www.cse.unsw.edu.au/~cs3710/PMmate-
rials/Resources/9126-1%20Standard.pdf
CALIDAD DE SOFTWARE
TEMA N° 2: Modelo y Norma de Procesos

En el siguiente capítulo usted comprenderá los conceptos referentes a la gestión y mejora de procesos que es uno de los pilares
principales para poder ofrecer productos y/o servicios de Calidad, que son los puntos que vimos en el tema anterior.
1 nTP/ISO 9001: MEJORA DE PROCESOS
1.1. Definición de procesos

Antes de hablar de mejora de procesos, debemos entender qué es un proceso. Podemos decir que un proceso, según la
ISO® 9000, es cualquier conjunto de secuencias repetitivas de actividades en que una o varias personas intervienen para
generar alguna salida, que puede ser un producto o servicio. Por ejemplo, vamos a definir el proceso de desarrollo de un
producto de software:
• L os datos de entrada serían los requerimientos del cliente. Luego, estos se convertirán en requisitos funcionales para
generar un producto de software.
• Las actividades que intervendrían para desarrollar dicho producto de software serian:
o Análisis funcionales
o Análisis técnico
o Construcción del producto de software
o Pruebas del producto de software
o Entrega al cliente
• P
ersonas que intervienen:
o Analistas funcionales
o Programadores
o Analista de calidad
o Cliente
Todos estos conjuntos de actividades se pueden representar en diagramas de flujos o diagramas de procesos (BPM). El pro-
ceso siempre deberá tener unos datos de entrada que pasarán por dicho proceso para generar una salida, como se puede
apreciar en el grafico siguiente:
ENTRADA SALIDA
Figura 3. Diagrama de Procesos

Fuente: (Wong, 2016)
1.2. Mejora de procesos

La Mejora de Procesos define la mejor forma de como ejecutar un proceso con todas las pautas que sean necesarias para
realizar procesos de Calidad, también busca implantar en las instituciones una metodología que sean usados por todos los
colaboradores que trabajan en dicha institución. La mejora de procesos es importante porque (Pragma Consultores, s.f.):
• S irve para asegurar que los procesos que se definen sean congruentes con los objetivos estratégicos de la empresa,
siempre enfocándose en el cliente.
• Nos ayuda a enfocarnos en los procesos importantes del negocio para que sean constantemente revisados y mejorados
en el tiempo.
• Poder usar los recursos de la manera más eficiente dentro de un proceso, para ahorrar costos sin descuidar la calidad
del producto.
• Mejora la entrega del producto o servicio relacionado.
• Garantiza que los procesos de la empresa sean estandarizados para que todos los procesos sean utilizados por todos los
colaboradores de una institución.
• Facilitar la identificación temprana de riesgos en el cumplimiento de objetivos, gracias al seguimiento sistemático del
rendimiento de los procesos.
2 DESARROLLO DEL SISTEMA DE GESTIÓN DE LA CALIDAD
La ISO 9000:2000 define la Gestión de la Calidad como las actividades coordinadas para dirigir y controlar una organización
en lo relativo a la calidad.
En general se puede definir la Gestión de la Calidad como el aspecto de la gestión general de la empresa que determina y
aplica la política de calidad
Con el objetivo de orientar las actividades de la Empresa para obtener y mantener el nivel de calidad del producto o el servi-
cio, de acuerdo con las necesidades del cliente.
Dicha gestión se puede representar en el siguiente diagrama:
PRODUCCIÓN
COMPRAS VENTAS
ASISTENCIA
CALIDAD POST-
LA CADENA VENTA
DE LA
CALIDAD
RR.HH ADMINIS-
TRACIÓN
FINANCIERO
Figura 4: Diagrama de Procesos

3 MODELO DE CAPACIDAD DE MADUREZ DEL SOFTWARE CMMI : MEJORA CONTINUA. NIVELES DE

MADUREZ.
Según la norma ISO 9000 define a la Mejora Continua como “Mejorar la eficacia de su sistema aplicando la política de calidad,
los objetivos de calidad, los resultados de las verificaciones de inspección, el análisis de los datos, las acciones correctivas y
preventivas y la revisión de la Dirección”. Eso quiere indicar que la Mejora Continua es una parte de la Mejora de Procesos y
viene ser los métodos para lograr mejorar los Procesos de una institución.
Ahora que ya sabemos que es la Mejora Continua podemos entender que el CMMI (Capability Maturity Model Integration)
sirve como un modelo para la mejora continua de procesos y nos da ciertos de modelos de madurez para asegurar la calidad
de las productos o servicios que demos. Para descargarle Modelo de CMMI debemos entrar a la siguiente ruta: http://www.
sei.cmu.edu/library/assets/whitepapers/Spanish%20Technical%20Report%20CMMI%20V%201%203.pdf
CALIDAD DE SOFTWARE
TEMA N° 3: Fundamentos de calidad
En el siguiente capítulo usted comprenderá los conceptos referentes a los fundamen-tos de Calidad aplicado para el desarrollo
de Software.
1 NTP/ISO/IEC 15504: CALIDAD DE SOFTWARE
1.1. Estructura
La estructura de la norma es la siguiente (ISO/IEC 15504):
Parte 1 Parte 9
Conceptos y guía introductoria Vocabulario
Parte 7 Parte 8
Guía para usar en un Guía para usar en la
proceso de mejora determinación de la
capacidad de un proveedor
Evaluación de Procesos
Parte 4 Parte 5 Parte 6

Guía para realizar Un modelo de evalución Guia sobre la competencia
evaluaciones y una guia de indicadores de las evaluaciones
Parte 3 Parte 2
Realizar una Un modelo de referencia
evaluación de procesos y de
capacidad de los procesos
Figura 5: Estructura de la ISO 15504

Fuente: (EQA, 2016)
1.2 Caracteristicas
Las principales características de la NTP/ISO/IEC 15504 (IEC 15504, 2014) son las siguientes:
• er aplicable a cualquier organización o empresa.

S
• Ser independiente de la organización, el modelo del ciclo de vida, la metodología y la tecnología.
• Ser un marco para métodos de evaluación, no un método o un modelo en sí.
• Cubrir diferentes objetivos para la evaluación de procesos
Con más detalle sobre las características de dicha norma lo puede descargar de http://www.senasa.gob.pe/senasa/wp-con-
tent/uploads/2014/11/Certificacion-citricos-a-mexico_26_mayo_2105_2.pdf
2 PROCESOS DE SOFTWARE Y EVALUACIÓN DE PROCESOS DE SOFTWARE
Para el proceso de Calidad del Software el ISQTB (ISQTB, 2014) recomienda las si-guientes fases:
Análisis Diseño Ejecución

• Recolección información • Validación técnica de pruebas • Ejecución de pruebas
• Análisis información • Diseño de pruebas • Reproceso
• Planeación pruebas • Construcción de instrumentos • Registro de hallazgo e información de QA
Figura 8: Metodología
2.1. Análisis
En la etapa de Análisis se empieza a recolectar toda la información correspondiente al proceso de desarrollo de Software
y el producto de Software con el fin de realizar el cronograma de actividades de pruebas y planear el personal que parti-
cipara para la validación y verificación del producto de Software.
2.2. Diseño
En la etapa de Diseño se empieza a definir que tipos de Pruebas de Software se va a realizar y la construcción de los scripts
de pruebas ya sea de manera manual o automática.
2.3. Ejecución
En la etapa de Ejecución se comienza a “ejecutar” los scripts que se elaboraron en la etapa de Diseño para encontrar
defectos y reportarlas como hallazgos para que lue-go sean reparadas por el equipo responsable de la implementación.
3 ESTANDARES Y NORMAS

Analicemos la siguiente imagen que explica lo que trata de estándares y normas
• Calidad a Nivel de Proceso

∙ ISO 9001:2000
∙ CMMi
CALIDAD DEL SOFWARE
∙ CobIT
∙ ITIL
∙ TicKIT
∙ ISO 90003:2004
∙ ISO 20000
∙ Bootstrap CALIDAD DEL PROCESO CALIDAD DEL PRODUCTO
• Calidad a Nivel de Producto

∙ Modelo de Boehm
∙ Modelo de Gilb Propiedades Propiedades
∙ Modelo de Dromey del Proceso del Producto
∙ ISO 9126-1
∙ Modelo de McCall
∙ WebQEM Métricas del Métricas del
∙ ISO 25000 Proceso Producto
∙ Portal Quality Model (PQM)
Figura 6: Calidad Procesos VS Calidad Producto

Como podemos analizar en la imagen para poder producir un producto de Calidad debemos de cumplir un procedimiento
que usualmente esta normado, como por ejemplo:
CALIDAD DE SOFTWARE
• ISO 2001
• CMMI
• ITIL
Y para la elaboración de un producto tenemos:
• I SO 25000
• P QM
4 MODELOS DE CALIDAD
Existe actualmente diferentes modelos para la gestión de procesos de software a nivel mundial, uno de ellos es lo que revisamos
en puntos anteriores que es el CMMI, entre los modelos que se platean están los siguientes (SEI, 2016):
• Ingeniería
• Gestión de Proyectos
• Gestión de Procesos
• Soporte
Para entrar a más detalle de cada una de los modelos lo pude visualizar en la siguiente ruta: http://www.sei.cmu.edu/cmmi/
index.cfm
5 NTP/ISO/IEC 12207
En 1995 es el año en que se publicó la norma IEC 12207 para que se pueda definir, controlar y mejorar los procesos del
desarrollo de software o más conocidos como el ciclo de desarrollo de software.
Este proceso define las arquitecturas de los procesos, que se dividen en los siguientes:
5.1. Procesos de Apoyo

Según la norma NTP/ISO/IECC 12207 (IEC 12207, 2008) el proceso de apoyo se sub dividen en:
• Adquisición
• Suministro
• Desarrollo
• Operación
• Mantenimiento
5.2. Procesos principales

Según la norma NTP/ISO/IECC 12207 (IEC 12207, 2008) los procesos principales se sub dividen en:
• Documentación
• Gestión de la Configuración
• Aseguramiento de la Calidad
• Verificación
• Validación
• Revisión Conjunta
• Auditoria
• Solución de Problemas
5.3. Procesos organizativos del ciclo de vida

Según la norma NTP/ISO/IECC 12207 (IEC 12207, 2008) los procesos organizativos del ciclo de vida se sub dividen en:
• Gestion
• Mejora
• Infraestructura
• Recursos Humanos
La norma lo puede descargar de la siguiente ruta: http://disi.unal.edu.co/dacursci/sistemasycomputacion/docs/SystemsEng/

ISO_IEC_12270_2008.pdf
6 NTP/ISO/IEC 9126
6.1. Calidad del producto

La norma ISO 9126 habla sobre que debe de existir una calidad en productos de software que desarrollamos. Dicha
normal nos apoya para indicarnos cuales son las características de la calidad y los lineamientos para su uso
6.2. Modelo de calidad

El modelo de calidad según la norma (ISO 9126, 2000) se encuentra graficada de la siguiente manera
Necesidades de Calidad
Calidad del Usuario en Uso
Uso y retroalimentación
contribuye a especificar Índica
Requerimientos
de Calidad Externa Calidad Externa
Validación
Índica
contribuye a especificar
Requerimientos
de Calidad Interna Calidad Interna
Verificación
Figura 7: Modelo de Calidad
Fuente: (ISO 9126, 2010)
6.3. Calidad interna y externa

Cuando se construye un producto de Software se encuentra conformado por factores internos (código fuente) y por
factores externos (interfaces graficas de las aplicaciones).
Figura 8: Calidad para un producto de Software

Los Factores Internos de un producto de Software se encuentran conformado por las siguientes características:
• S olo lo perciben los diseñadores y desarrolladores, eso quiere decir que no es fácil de percibir por personas que no
tengan conocimiento sobre algún lenguaje de programación.
• Es un medio para conseguir la Calidad externa.
CALIDAD DE SOFTWARE
Los Factores Externos de un producto de Software se encuentran conformado por las siguientes características:
• P uede ser detectado por los usuarios finales, porque es fácil de percibir cuando el usuario está usando el Software.
• La Calidad externa es lo que realmente preocupa dado que es lo que el usuario solicito.
6.4. Métricas internas y externas de Calidad

La norma ISO 9126 (ISO 9126, 2010) estable las siguientes métricas internas y externas de calidad
Figura 9: Métricas internas y externas

Fuente: (ISO 9126, 2010)
TEMA N° 4: Fundamentos de control de calidad
En el siguiente capítulo comprenderás los conceptos referentes a las pruebas de software.
1 Pruebas de software
Según el ISQTB®, las pruebas de software se pueden definir como una actividad en la que un sistema o uno de sus componentes
se ejecuta en circunstancias previamente especificadas (configuración de la prueba), registrándose los resultados obtenidos.
Se debe tener en claro que el objetivo de las pruebas no es asegurar la ausencia de defectos en un software, sino demostrar
que existen defectos en él.
El ISQTB norma que los principios para las pruebas de software son:
• as pruebas dejan al descubierto la presencia de defectos

L
• Pruebas exhaustivas son imposibles
• Pruebas tempranas
• Agrupación de defectos
• Paradoja del pesticida
• Las pruebas son dependientes del contexto en donde se desenvuelvan
• Falacia en la ausencia de errores
2 Defectos
Analicemos los siguientes conceptos para tener clara la diferencia entre defecto, falla y error:
Figura 9: Diferencia entre falla, defecto y error

Entonces podemos decir que:
• E rror (error): Es una decisión incorrecta tomada durante el desarrollo de un sistema de software (usualmente una
suposición incorrecta).
• Defecto (defect, fault, bug): Es una propiedad del software que puede hacer que este se comporte de una manera no
deseada. Por ejemplo: un proceso, una definición de datos o un paso de procesamiento incorrectos son un progra-
ma.
• Fallo (failure): Es la situación en la que un software en ejecución se comporta de una manera no deseada.
CALIDAD DE SOFTWARE
LECTURA SELECCIONADA N° 1
Realizar la lectura desde la página 01 al 30 del PDF adjunto (“Lectura01.pdf”) de la Norma Internacional ISO 9000 para
que le ayude a definir los conceptos sobre lo que es Calidad.
ISO. (2005). Sistema de gestión de la calidad - Fundamentos y vocabulario ISO 9000:2005. Normativa ISO. Ginebra: Secreta-
ría Central de ISO. http://www.uco.es/sae/archivo/normativa/ISO_9000_2005.pdf
Leer el Capítulo 1. Fundamentos de pruebas. (pp. 1-28)
Black, R., & Rueda Sandoval, G. (2011). Fundamentos de pruebas. In Editorial RBCS (Ed.), Fundamentos de Pruebas de
Software (Spanish Edition) (531 p.). Texas: Estados Unidos. Disponible en https://es.slideshare.net/dumethvah/prue-
bas-software-c1
ACTIVIDAD N° 1
Foro de discusión sobre la importancia de la calidad
Instrucciones
• I ngresa al foro y participa con comentarios críticos y analíticos acerca de la calidad.

• Lee y analiza los temas 1 y 2 del manual.
• Responde en el foro:
o ¿Qué es calidad?
o ¿Cuál cree que es la diferencia entre mejora de procesos y mejora continua?
ACTIVIDAD N° 2
Instrucciones
• I ngresa al foro y participa con comentarios críticos y analíticos acerca de la calidad.

• Lee y analiza los temas 3 y 4 del manual.
• Responde en el foro a las preguntas de:
o ¿Qué es calidad de software?
o Menciona cinco tipos de pruebas de software e indica para qué se utilizarían
CALIDAD DE SOFTWARE
GLOSARIO DE LA UNIDAD I
1. Defecto
Es una decisión incorrecta tomada durante el desarrollo de un sistema de software (usualmente una suposición incorrecta).
2. Error
Es una propiedad del software que puede hacer que este se comporte de una manera no deseada, por ejemplo: un proceso,
una definición de datos o un paso de procesamiento incorrectos son un programa.
3. Fallo
Es la situación en la que un software en ejecución se comporta de una manera no deseada.
4. ISO
International Organization for Standardization.
5. ISTQB
International Software Testing Qualifications Board.
6. Validación
Conjunto de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.
7. Verificación
Conjunto de actividades que aseguran que el software implementa correctamente una función específica.
BIBLIOGRAFÍA DE LA UNIDAD I
Abadi, Miguel (2004). La Calidad de Servicio [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web:
www.econ.uba.ar/www/departamentos/.../LA_CALIDAD_DE_SERVICIO.doc
Amo, Fernando (2002). Introducción a la Ingenieria de Software [en linea]* [Consulta: 09 de Setiembre de 2016].
Disponible en https://books.google.com.pe/books?id=rXU-WS4UatYC&pg=PA120&lpg=PA120&dq=Conjun-
to+de+actividades+que+aseguran+que+el+softwa-re+construido+se+ajusta+a+los+requisitos+del+cliente.&sour-
ce=bl&ots=vvwKy74l1V&sig=08G-5aS5JEZavr7KvnLX-5_AKgo&hl=es&sa=X&ved=0ahUKEwiyttWKovHPAhX-
G6yYKHYWmATAQ6AEIIjAB#v=onepa-ge&q=Conjunto%20de%20actividades%20que%20aseguran%20que%20
el%20software%20construido%20se%20ajusta%20a%20los%20requisitos%20del%20cliente.&f=false
Chrissis,M. Konrad,M. y Shrum.S. (2009) CMMI - guía para la integración de procesos y la mejora de productos (2da
Edición). España,Madrid: Person Educación. 664 páginas.
Euskalit (s.f.). Gestión y Mejora de Procesos [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web:
http://www.euskalit.net/pdf/folleto5.pdf
EQA (s.f.). NTP/ISO 15504 [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web: https://eqa.es/
presentaciones/presentacion_ISO_15504.pdf
IEC 12207 (2008), ISO/IEC 12207 [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web: http://disi.
unal.edu.co/dacursci/sistemasycomputacion/docs/SystemsEng/ISO_IEC_12270_2008.pdf
Pressman, Roger (2005). Ingenieria del Software. Españna: Mc Graw Hill
Pragma Consultores (s.f.). Mejora de Procesos de Negocios[en línea]* [Consulta: 09 de Setiembre de 2016]. Disponi-
ble en Web: http://www.pragmaconsultores.com/pe/servicios/consultoria/Paginas/MejoraProcesosNegocio.aspx
R.M.M. (2007, Junio 2). If programmers have make a plane [Archivo de video]* [Consulta: 09 de Setiembre de
2016]. Disponible en Web: https://www.youtube.com/watch?v=UZq4sZz56qM
SEI (s.f.). Software Engineering Insititute [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web:
http://www.sei.cmu.edu/cmmi/index.cfm
CALIDAD DE SOFTWARE
AUTOEVALUACIÓN DE LA UNIDAD I
1. A qué definición corresponde la siguiente pregunta: ¿Se está desarrollando el producto correcto?
a) Verificación
b)Pruebas de software
c) Análisis
d)Complejidad ciclomática
2. ¿En qué etapa se desarrollan los scripts de pruebas?
a) Toma de requerimientos
b)Incepción
c) Diseño
d)Planificación
3. ¿En qué etapa se desarrolla y realiza el cronograma de pruebas?
a) Resumen
b)Pruebas
c) Validación
d)Desarrollo
4. En la fase de construcción se están elaborando los documentos de casos de pruebas de acuerdo a las solicitudes de cam-
bio emitidas y aprobadas por el cliente. ¿Qué tipo de V&V se tendrá que aplicar para estos documentos?
a) V&V Dinámica
b)Revisión
c) V&V Estática
d)Inspección
5. ¿La V&V requiere ser administrada y realizada en forma completa durante qué proceso de desarrollo de software?
a) Planificación
b)Gestión
c) Ejecutar / interpretar
d)Reportar
e) Monitorear
6. La mitigación es:
a) Defecto
b)Una acción preventiva
c) Una acción correctiva
d)Inconsistencia
7. Se define caja negra como:
a) Pruebas funcionales y no funcionales

b)Se despliega en el ambiente de producción
c) Se despliega en un ambiente controlado
d)Revisa la estructura interna
e) Se hace uso de documentación de estándares y procesos
8. Es la capacidad de los productos software de reaccionar apropiadamente ante condiciones excepcionales:
a) Compatibilidad
b)Facilidad de uso
c) Integridad
d)Robustez
9. ¿Cómo se define software development (desarrollo de software)?
a) Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un computador (or-
denador)
b)La definición de un caso de prueba debe incluir: Precondiciones, conjunto de valores de entrada, conjunto de
resultados esperados, forma en la cual se debe ejecutar el caso de prueba y verificación de resultados y postcon-
diciones
c) Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como referencia para
el desarrollo de casos de prueba
10. ¿Cuál es la principal ventaja del diseño de pruebas tempranas en el ciclo de vida?
a) Es más barato que el diseño de pruebas durante las fases de prueba

b)Ayuda a prevenir los defectos que se introduzcan en el código
c) Las pruebas diseñadas al principio son más eficaces que pruebas diseñadas después
d)Se ahorra tiempo en las fases de prueba cuando los probadores están ocupados
Anexo
Respuestas a la autoevaluación de la Unidad I
Preguntas Respuesta
1 B
2 B
3 A
4 C
5 A
6 B
7 A
8 D
9 A
10 C
CALIDAD DE SOFTWARE
UNIDAD II: Planificación de la calidad
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD II
Resultado de aprendizaje de la Unidad II:

Explica la importancia del plan de calidad en la gestión de un proyecto de software.

Tema N.º 1: Gestión de la Calidad del Software - 1. Explica la importancia del plan de calidad Valora la importancia de la calidad en el de-
NTP/ISO/IEC 12119 en la gestión de un proyecto de software. sarrollo de software
1. Objetivos
2. Plan de calidad 2. Explica la importancia del plan de pruebas
3. Requisitos de calidad en la gestión de calidad del software.
Tema N.º 2: Procesos de calidad 3. Explica la importancia de los indicadores o

1. Especificaciones del plan de pruebas métricas de gestión para establecer un ade-
2. Trazabilidad cuado plan de gestión de calidad.
Lectura seleccionada N.° 1 4. Describe las características del plan de ges-

tión de riesgos y el procedimiento para mi-
Tema N.º 3: Indicadores de gestión tigar o desaparecer estos riesgos.
1. Definición de indicadores
2. Tipos de indicadores y métricas Actividad N.º 1
Tema N.º 4: Gestión de riesgo sión sobre lo que es un plan de pruebas
1. Definición de riesgo
2. Plan de gestión de riesgo Actividad N.º 2
3. Respuesta a riesgo Los estudiantes participan en el foro de discu-
sión sobre gestión de riesgos
Lectura seleccionada N.° 4
Tarea Académica Nº 2
Autoevaluación de la Unidad II
30 UNIDAD II Planificación de la calidad
TEMA N° 1: GESTIÓN DE LA CALIDAD DEL SOFTWARE – NTP/ISO/IEC 12119

En el siguiente capítulo usted comprenderá la importancia del Plan de Calidad en la Gestión de un proyecto de Software
1 Objetivos
En capítulos anteriores ya vimos que «calidad de software» consiste en desarrollar un producto que satisfaga la necesidad de un
cliente. Los objetivos de la gestión de calidad de un software serían (Corochano, 2013):
• ertificar la calidad de los productos aplicando un Plan de Aseguramiento de la Calidad (SQAP).

C
• Entregar productos estables y validados.
• Controlar la calidad de los entregables de los servicios de factorías y de-partamentos de desarrollo.
• Obtener informes y estadísticas de calidad para monitorizar el proceso.
• Asegurar:
• Que el producto software cumple con los requisitos especificados por el usuario.
• Que el producto funcionará de acuerdo a lo esperado: de manera correcta y eficiente.
• Que la operación del producto no afectará al resto de sistemas existentes.
• Que la evolución del producto a lo largo de su vida será viable y sencilla, garantizando la calidad de toda la información
técnica necesaria para su evolución.
Todas las actividades anteriores serían recomendable que se encuentren integradas dentro de un proceso de Integración
Continua, donde se ejecute todas las pruebas de un producto de software de manera automática, para que de esa manera el
control de la calidad se dé de manera rápida y eficaz.
2 APLICABLE A PAQUETES DE SOFTWARE
LA ISO / IEC 12119 especifica cómo probar un paquete de software en contra de los requisitos de calidad y las instrucciones de
prueba están relacionados, en particular, a las pruebas de terceros.
Ellos incluyen pruebas mediante la inspección de los documentos y las pruebas de recuadro negro de programas y datos. Se
presta especial atención a la selección de casos de prueba, repetición de pruebas y presentación de informes de prueba.
3 PLAN DE CALIDAD
La adecuada definición de Plan de Calidad siempre apoyara para que un Proyecto de Software genere un producto de calidad
aceptable. Es por eso que desde el inicio del desarrollo de un Proyecto de Software se debe de realizar dicho Plan.
Las actividades que involucra un Plan de Calidad son las siguientes (Alvarez y Lopez, 2005):
• Identificar el ambiente o entorno del proyecto y sus características

o Se tiene que analizar cuál es el ambiente (personal que participara, experiencia del equipo en pruebas, herramien-
tas de automatización que se tenga, etc) en donde se ejecutara las pruebas para en función a ello realizar las estima-
ciones
• Seleccionar el proceso y las actividades a realizar.

o En la actualidad existen más de 200 métodos de pruebas, es por eso que es importante definir qué tipo de pruebas
se van aplicar en un Plan de Calidad.
o También se tiene que determinar
▪▪ Las actividades que se realizaran.
▪▪ El esfuerzo que demandara dicha actividad.
▪▪ La fecha de inicio y fecha de fin de inicio de cada actividad.
• Documentar el plan de la calidad

o Es importante que se documenten las decisiones más importantes al seleccionar las prácticas que se van a utilizar en
el proyecto. El documento donde se va a guardar esa información además de los aspectos que el equipo de proyecto
considera que es importante comunicar interna o externamente al proyecto es el Plan de la Calidad.
• Mantener el plan de la calidad

o Los proyectos involucran un cierto grado de incertidumbre que conlleva la imposibilidad de prever todos los esce-
narios posibles al definir el proceso de software, por lo que será necesario revisar la aplicación y adecuación del plan
de la calidad a la realidad del proyecto para mantenerlo actualizado a medida que se va a avanzando en la ejecución
del proyecto.
CALIDAD DE SOFTWARE
4 REQUERIMIENTOS DE CALIDAD Y PRUEBAS
Los requisitos de calidad vienen a ser los requerimientos funcionales y no funcionales que se deben de probar de una aplicación
y dichos requerimientos se representan en el siguiente diagrama:
¿ Esta disponible y están bien

Funcionalidad hechas las reglas de negocio ?
¿ Funciona sin ¿ Es fácil de

errores ? aprender,
¿ Son frecuentes
Confiabilidad Requisitos Usabilidad
entender y usar ?
los errores ? de la calidad
de un
producto
¿ Cuánto tiempo ¿ Es fácil instalarlo ?
tarda? ¿ qué tan fácil es
Desempeño Portabilidad
¿ Qué recurso pasarlo a otro
utiliza ? ambiente ?
Figura 10: Requisitos de Calidad de un Producto

A continuación, pasaremos a explicar cada uno de ellos, según la definición que plantea el ISTQB®:
• Funcionalidad
o Todo producto que se desarrolle debe cumplir los requerimientos funcionales que le solicitó el cliente.
• Usabilidad
o Los sistemas actualmente deben ser capaces de entender de manera rápida, es por eso que los sistemas que se de-
sarrollen deben ser usables.
• Portabilidad
o Es la facilidad que tiene un producto de software de poder instalarse en diferentes entornos, por ejemplo: las apli-
caciones que se desarrollan en Java se pueden instalar en diferentes entornos operativos.
• Desempeño
o Es la capacidad que tiene un sistema de responder de manera rápida a peticiones.
• Confiabilidad
o Los sistemas siempre se ejecutan sin errores.
TEMA N° 2: Procesos de calidad
En el siguiente capítulo comprenderás la importancia del plan de pruebas en la gestión de calidad del software.
1 Especificaciones del plan de pruebas
Según la IEEE® 829, se define que el propósito del plan de pruebas es explicitar el alcance, enfoque, recursos requeridos,
calendario y responsables del proceso de pruebas. El objetivo principal de este documento es guiar el proceso de pruebas de los
distintos proyectos del área y ser una herramienta que sirva para:
• B rindar información que será de utilidad para definir el plan de pruebas de cada sistema concerniente al área PAS.
• Guiar en el diseño de los casos de prueba, definición del ambiente de prueba a utilizar, aspectos a probar del software,
condiciones de finalización, suspensión o repetición, artefactos que se confeccionarán y responsables de la creación y
revisión de los mismos.
• Guiar a la gerencia colaborativa en el seguimiento y control de los proyectos desde los aspectos de las pruebas.
Las partes de un documento de plan de pruebas, como mínimo, son las siguientes (IEEE 829, 2008):
• A
lcance del acercamiento de las pruebas
o Qué funcionalidades de un aplicativo se van a probar
o Qué funcionalidades de un aplicativo no se van a probar
• T
ipos de pruebas a aplicar
o Se tiene que especificar cuál de los más de 200 métodos de pruebas que existen actualmente se van a aplicar
• C
ronograma de pruebas
o Se especifica qué actividades se van a realizar, con qué esfuerzo y en qué fechas se ejecutarán
• R
ecursos de pruebas
o Recursos humanos
▪▪ Personas involucradas
▪▪ Fechas de responsabilidades
o Recursos de hardware
▪▪ Especificaciones de hardware
o Recursos de software
▪▪ Entorno de pruebas
• C
asos de pruebas
o Los planes de pruebas hacen mención o incluyen una lista detallada de todos los casos de pruebas:
▪▪ Listado de pruebas (título de cada caso de prueba, por tipo)
▪▪ Detalle de pruebas (catálogo de pruebas). Incluye:
▪▪ ID de caso de prueba
▪▪ Nombre de caso
▪▪ Prioridad
▪▪ Precondiciones
▪▪ Pasos de pruebas
▪▪ Resultados esperados
• Riesgos y asunciones
• Firmas
• Apéndices
• Documentación de control
2 Trazabilidad
La matriz de trazabilidad es una herramienta que es utilizada para saber qué requerimientos están quedando y con qué casos de
pruebas se van a probar. (Softqatest, 2010).
Un ejemplo de matriz de trazabilidad:
• E
l caso de prueba T1 cubre los requerimientos R1 y R4
• El caso de prueba T2 cubre los requerimientos R3 y R5
CALIDAD DE SOFTWARE
• El caso de prueba T3 cubre el requerimiento R3
Su matriz de trazabilidad sería la siguiente:
T1 T2 T3
R1 X X
R2
R3 X X
R4 X
R5 X
Figura 11: Matriz de Trazabilidad

TEMA N° 3: Indicadores de gestión
En el siguiente capítulo usted comprenderá la importancia de los indicadores o métricas de gestión para establecer un adecuado
plan de gestión de calidad.
1 Definición de indicadores
Para definir lo que es un indicador debemos especificar los siguientes conceptos (INDECOPI, 2015):
• Medición
o Es el acto de determinar una medida.
Por ejemplo:
▪▪ El tester recopila la cantidad de defectos hallados en un módulo.
▪▪ El programado recopila la cantidad de líneas de código de cada módulo del sistema.
• Medida
o Proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos
atributos de un proceso o producto.
Por ejemplo:
▪▪ Número de defectos encontrados en un módulo.
▪▪ Cantidad de líneas de código en un módulo.
• Métrica
o Una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado.
Por ejemplo:
▪▪ La productividad por tester fue de 3 errores/hora.
• Indicador
o Un indicador es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del
software, del proyecto de software o del producto en sí.
o Un ingeniero de software recopila mediadas y desarrolla métricas para obtener indicadores.
En resumen, podemos definir los anteriores conceptos de la siguiente manera:
Pruebas • Realizó la
de Medición
Sofware
Recopilación • Obtengo
de
Medidas
Datos
Cálculo de • Obtengo
las
Métricas
Métricas
Evaluación • Obtengo
de las Indicadores
Métricas
Figura 12: Resumen de Indicadores

CALIDAD DE SOFTWARE
2 Tipos de indicadores y métricas
INDECOPI (2015) propone las siguientes métricas para aplicar a un producto de software:
• Corrección
o Es la capacidad del software de operar correctamente según las instrucciones dadas
• F
acilidad de mantenimiento
o Es la habilidad con la que se puede corregir un programa si se encuentra un error
• Integridad
o Mide la habilidad de un software de soportar ataques de seguridad (tanto accidentales como intencionados) contra
su seguridad.
• F
acilidad de uso
o Se considera que un programa de software debe ser amigable para todos los usuarios; es decir, que sea fácil de en-
tender por las personas que utilizarán el software.
TEMA N° 4: Gestión de riesgos
En el siguiente capítulo comprenderás las características del plan de gestión de riesgos y el procedimiento para mitigar o
desaparecer estos riesgos.
1 Definición de riesgos
El riesgo (UNISDR, 2009) se define como la combinación de la probabilidad de que se produzca un evento y sus consecuencias
negativas. Los factores que lo componen son la amenaza y la vulnerabilidad.
1.1. Amenaza
Es un fenómeno, sustancia, actividad humana o condición peligrosa que puede ocasionar la muerte, lesiones u otros im-
pactos a la salud, al igual que daños a la propiedad, la pérdida de medios de sustento y de servicios, trastornos sociales y
económicos, o daños ambientales. La amenaza se determina en función de la intensidad y la frecuencia.
1.2. Vulnerabilidad
Son las características y las circunstancias de una comunidad, sistema o bien que los hacen susceptibles a los efectos dañinos
de una amenaza. Con los factores mencionados se compone la siguiente fórmula de riesgo:
RIESGO = AMENAZA x VULNERABILIDAD
Los factores que componen la vulnerabilidad son la exposición, susceptibilidad y resiliencia, expresando su relación en la si-
guiente fórmula:
VULNERABILIDAD = EXPOSICIÓN x SUSCEPTIBILIDAD / RESILIENCIA
1.2.1.Exposición
Es la condición de desventaja debido a la ubicación, posición o localización de un sujeto, objeto o sistema expuesto al
riesgo.
1.2.2.Susceptibilidad
Es el grado de fragilidad interna de un sujeto, objeto o sistema para enfrentar una amenaza y recibir un posible impacto
debido a la ocurrencia de un evento adverso.
1.2.3.Resiliencia
Es la capacidad de un sistema, comunidad o sociedad expuestos a una amenaza para resistir, absorber, adaptarse y recu-
perarse de sus efectos de manera oportuna y eficaz, lo que incluye la preservación y la restauración de sus estructuras y
funciones básicas.
2 Plan de gestión de riesgos
La gestión de riesgo es importante cuando se quiere realizar productos de calidad y además para poder ser competitivos de
manera internacional. Se debe de tener en cuenta que uno puede gestionar el riesgo si no podemos medirlo.
Según la ISO ® 27001 un plan de Gestión de Riesgos debe de tener en cuenta el siguiente proceso:
Identificación de Evaluación de la
Identificación y Requerimientos Posibilidad de
Tasación de de que las Amenazas
Activos Seguridad y bulnerabilidades
ocuarran
Selección de Selección de
Cálculo de los Opciones de Controles para
Riesgos de Tratamiento de Reducir el
Seguridad Riesgo Riesgo a Nivel
Apropiado Aceptable
Figura 13: Proceso de Plan de Gestión de Riesgos
Fuente: (ISO 27001, 2005)
CALIDAD DE SOFTWARE
• I dentificación y tasación de activos

o Un activo es algo que tiene valor para una empresa, y cada activo de una empresa debe estar valorado e identificado
claramente.
• I dentificación de requerimientos de seguridad

o Se tiene que especificar cuáles son los criterios de seguridad que deben tener los activos.
• I dentificación de amenazas y vulnerabilidades

o Los activos de las empresas están sujetos a muchas amenazas, como virus, pérdida de información, etc. Se debe
identificar cuáles son las vulnerabilidades para mitigar las amenazas.
• C
álculo de los riesgos de seguridad
o Los riesgos son calculados de una combinación de valores de activos y niveles de requerimientos de seguridad.
• S
elección de opciones apropiadas de tratamiento de riesgo
o Después de que los riesgos son identificados, las empresas deben identificar y evaluar la acción más apropiada de
cómo tratar los riesgos.
3 Respuesta a riesgos
El PMBOK® (2014) define a la respuesta de riesgo de la siguiente forma:
Este proceso desarrolla las opciones y acciones para mejorar las oportunidades y reducir las amenazas a los objetivos del
proyecto. Se realiza después de los procesos «Realizar el análisis cualitativo de riesgos» y «Realizar el análisis cuantitativo
de riesgos (en el caso de que este se aplique)».
LECTURA SELECCIONADA Nº 1
IEEE. (2008). Std. 829-2008: Standard for software and system test documentation. Autor, 30-59. Disponible en https://goo.gl/
UBf7JN
Alexander, A. (2005). Análisis del riesgo y el sistema de gestión de seguridad de información: El enfoque ISO 27001:2005. Infor-
mation security. Disponible en http://www.iso27000.es/download/Analisis_del_Riesgo_y_el_ISO_27001_2005.pdf
CALIDAD DE SOFTWARE
ACTIVIDAD Nº 1
Foro de discusión sobre la importancia de la calidad.
Instrucciones
Participa en el desarrollo y resolución de las preguntas y ejercicios planteados. Foro debate N.° 1: foro de participación
sobre plan de pruebas con la orientación de tu docente.
Las preguntas que debes responder en el foro son las siguientes:
• ¿ Qué es un plan de pruebas?

• ¿Cuáles son las partes principales para definir casos de pruebas de software?
ACTIVIDAD Nº 2
Instrucciones
Participa en el desarrollo y resolución de las preguntas y ejercicios planteados. Foro debate n.° 2: foro de participación
sobre pruebas de software con la orientación de tu docente.
• D efine con tus propias palabras lo que es riesgo.

• ¿Cómo se calcula el riesgo?
• Desarrolla cinco ejemplos de riesgos que pueden suceder al momento del desarrollo de un software. Llenar la
tabla siguiente:
Nombre Causas Consecuencias Tipo Etapa Impacto Contingencia
Se le pide que llene el documento de «Plantilla de casos de pruebas» para dar por validada la funcionalidad de «Registrar
categoría» del sistema TAtiendo.
Instrucciones
• T odos los puntos de la rúbrica deberán ser subidos a la plataforma en formato ZIP. El nombre del archivo deberá
tener el siguiente formato: APELLIDO_NOMBRE.zip
• En caso de plagio, el trabajo será invalidado y la nota será de 00.
GLOSARIO DE LA UNIDAD II
1. Funcionalidad
Las funcioanalidades de un producto estan y estan bien hechas las reglas de negocios.
2. Usabilidad
Requerimiento no funcional que esta asociado a que ten facil de aprender y de usar es un producto de software.
3. Portabilidad
Facilidad de un producto de software de ser instalado en diferentes entornos.
4. Desempeño
Cuanto tiempo tarde un producto de software en responder a una petición.
5. Riesgo
Evento incierto que puede afectar positiva o negativamente a un proyecto.
6. Medicion
Es el acto de determinar una medida
7. Medida
Proporciona una indicación cuantitativa de la extensión, cantidad, dimensiones, capacidad o tamaño de algunos atributos
de un proceso o producto.
8. Metrica
Una mediada cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado
9. Indicador
Un indicador es una métrica o una combinación de métricas que proporcionan una visión profunda del proceso del softwa-
re, del proyecto de software o del producto en sí.
CALIDAD DE SOFTWARE
BIBLIOGRAFIA DE LA UNIDAD II
Alvarez, Amalia y Lopez, Matilde (2005). Elaboración de planes de la calidad en proyectos de Software [en lí-
nea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web: http://sedici.unlp.edu.ar/bitstream/hand-
le/10915/23062/Documento_completo.pdf?sequence=1
Corrochano, Jesus (2013). La Calidad del Producto de Software [en línea]* [Consulta: 09 de Setiembre de 2016].
Disponible en Web: http://atsistemas.com/wp-con-tent/uploads/2013/12/20121201_articulo_calidad_produc-
to_software_jesus_hernando_corrochano.pdf
IEEE® 829 (2008). IEEE Standard for Software and System Test Documentation [en línea]* [Consulta: 09 de Se-
tiembre de 2016]. Disponible en Web: https://www.google.com.pe/url?sa=t&rct=j&q=&esrc=s&source=web&c-
d=1&cad=rja&uact=8&ved=0ahUKEwjqp_vBq6fQAhUK4iYKHWLqDtMQFggZMAA&url=https%3A%2F%2Fcow.
ceng.metu.edu.tr%2FCourses%2Fdownload_courseFile.php%3Fid%3D4046&usg=AFQjCNG1JelvGoehvJiaujd-
BB-2-T4Sxcg&sig2=UfYjzzyg_Lpnk47EBC7now
INDECOPI (2005). Ingeniería de Software. Calidad del producto. Parte 3: Métricas internas. 1a. ed. NTP ISO/IEC
9126.
Leon, Nelson; Aguilar, Luis; Vega, Edgar y Gomez, Luis (2013). Herramienta computacional para la documentación
de pruebas de software enmarcado en actividades de investigación [en línea]* [Consulta: 09 de Setiembre de
2016]. Disponible en Web: http://atsistemas.com/wp-con-tent/uploads/2013/12/20121201_articulo_calidad_pro-
ducto_software_jesus_hernando_corrochano.pdf
Mondragon, Angelica (2002). ¿Que son los Indicadores? [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponi-
ble en Web: http://www.orion2020.org/archivo/sistema_mec/10_indicadores2.pdf
Software, Calidad y Test - Softqatest (2010). Matriz de Trazabilidad [en línea]* [Consulta: 09 de Setiembre de 2016].
Disponible en Web: http://www.softqatest.net/?p=77
UNISDR (2009), Terminología sobre Reducción de Riesgo de Desastres para los conceptos de Amenaza, vulnerabili-
dad y riesgo [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web: http://www.ciifen.org/index.
php?option=com_content&view=category&id=84&layout=blog&Itemid=111&lang=es

AUTOEVALUACIÓN DE LA UNIDAD II
1. La siguiente pregunta: ¿Se está desarrollando el producto correcto? Responde a:
a. Verificación
b. Chequeo
c. Validación
d. Revisión
e. Pruebas de software
2. En la fase de construcción se están elaborando los documentos de casos de pruebas de acuerdo a las solicitudes de cambio
emitidas y aprobadas por el cliente. Qué tipo de V&V se tendrá que aplicar para estos documentos:
a. V&V Dinámica
b. Revisión
c. V&V Estática
d. Inspección
3. La V&V requiere ser administrada y realizada en forma completa durante qué proceso de desarrollo de software:
a. Planificación
b. Gestión
c. Ejecutar / interpretar
d. Reportar
e. Monitorear
a. Defecto
b. Una acción preventiva
c. Una acción correctiva
d. Inconsistencia
a. Pruebas funcionales y no funcionales

b. Se despliega en el ambiente de producción
c. Se despliega en un ambiente controlado
d. Revisa la estructura interna
e. Se hace uso de documentación de estándares y procesos
6. Se define caja blanca como:
a. Compara lo especificado con el producto entregado

b. No interesa el proceso de construcción
c. Se hace uso de documentación de estándares y procesos
d. Pruebas funcionales y no funcionales
e. Pruebas de robustez
7. Se define pruebas alfa como:
a. Realizadas por el programador

b. Realizadas en un ambiente no controlado
c. Realizadas en un ambiente controlado
d. Se despliegan en el ambiente de producción
e. Se realizan sin el cliente
8. En un proyecto de implementación de SAP, el gerente de finanzas (interesado) descubre una inconsistencia en el producto
y reporta al área de sistema que su auxiliar definió mal el requisito a implementar. Bajo esta premisa, ¿que debe registrar
el área de calidad en su sistema de incidencias?
a. Falla
b. Error
CALIDAD DE SOFTWARE
c. Defecto
d. Inconsistencia
9. Se puede decir de las pruebas alfa:
a. Son realizadas por el usuario

b. Son realizadas en un ambiente no controlado
c. Se despliegan en el ambiente de producción
d. Ninguna de las anteriores
10. ¿Se está construyendo de forma adecuada el producto? Esta pregunta se refiere a:
a. Validación
b. Verificación
c. Chequeo
d. Monitorear
Anexo
Respuestas a la autoevaluación de la Unidad II
Preguntas Respuesta
1 C
2 C
3 A
4 B
5 A
6 C
7 C
8 B
9 A
10 B
CALIDAD DE SOFTWARE
UNIDAD III: Aseguramiento de la calidad
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD III
Resultado de aprendizaje de la Unidad III:

Explica la importancia de la validación y verificación estática en la gestión de calidad de software.

Tema N° 1: Revisiones o inspecciones estáticas rela- 1. Conoce revisiones estáticas para seleccionar Valora la importancia de la Calidad en el Desa-
cionadas a ISTQB el tipo de revisión idóneo en el proceso de rrollo de Software
1. Actividades de control de calidad de desarrollo.
Software
2. Gestión de requisitos 2. Explica la importancia de la Validación y Ve-
3. Meta modelo para la trazabilidad de rificación Estática en la gestión de calidad del
requisitos software.
4. Usabilidad en el proceso de desarrollo de
software 3. Conoce los diferentes tipos de revisiones di-
4.1. Contexto de aplicación de la usabilidad námicas para seleccionar el tipo de revisión
4.2. Métricas de usabilidad idóneo en el proceso de desarrollo.
4.3. Métodos de evaluación de la usabilidad
4. Explica la importancia de la Validación y Ve-
Lectura seleccionada N.° 5 rificación Dinámica en la gestión de calidad
del software.
Tema N° 2: Pruebas o inspecciones dinámicas rela-
cionadas a ISTQB Actividad N° 1
1. Proceso de pruebas Los estudiantes participan en el foro de discu-
2. Tipos de pruebas sión sobre lo que es un plan de pruebas
Lectura seleccionada N.° 6 Actividad N.º 2

Autoevaluación de la Unidad III sión sobre pruebas de software
Control de Lectura Nº 3
46 UNIDAD III Aseguramiento de la calidad
TEMA N° 1: Revisiones o inspecciones estáticas relacionadas al ISQTB

En el siguiente capítulo comprenderás la importancia de la Validación y Verificación Estática en la gestión de calidad del
software.
1 ACTIVIDADES DE CONTROL DE CALIDAD DE SOFTWARE
Las Inspecciones son un proceso bien definido y disciplinado donde un equipo de personas cualificadas analiza un producto
software usando una técnica de lectura con el propósito de detectar defectos (Jurito, Moreno y Vegas, 2006).
El proceso de inspección según la ISTQB® consta de las siguientes fases:
• Inicio
• Detección de Defectos
• Colección de Defectos
• Corrección y Seguimiento
DETECCIÓN DE CORRECCIÓN Y
• Preparar la DEFECTOS • Compilado de SEGUIMIENTO
Inspección • Lectura faltas • Corrección por
• Proporcionar Individual • Discusión de el Autor
Información • Detección de Grupo • Informe de
Faltas Cambio
INICIO COLECCIÓN DE
DEFECTOS
Figura 16: Proceso de Inspección

Fuente: (ISQTB, 2014)
2 LA GESTIÓN DE REQUISITOS
La gestión de requisitos es una metodología que se encuentra orientada para poder gestionar los requisitos de software que nos
indica un usuario para implementarlo en su sistema. En cursos anteriores usted ha visto diferentes metodologías que apoyan a
esta actividad, entre los cuales se encuentra RUP, SCRUM, XP, etc.
Su objetivo principal es de identificar la consistencia que existe entre los requisitos y los planes de desarrollo de software (Overti,
2016)

3 META MODELO PARA LA TRAZABILIDAD DE REQUISITOS
Para que exista una buena gestión de requisitos debe de existir una correcta trazabilidad de requisitos y para eso es imprescindible
poder contar con diferentes herramientas.
Para el CMMI (Overti, 2016) la trazabilidad de requisitos importante en la Gestión de Requisitos, porque es importante evaluar
el impacto que sucede cuando se realiza un cambio especifico.
4 USABILIDAD EN EL PROCESO DE DESARROLLO DE SOFTWARE
Según Xavier Ferre (Ferre, 2005) en el mundo de software esta que se le da mucho valor a los atributos de Usabilidad que
deben de tener los sistemas para el lograr el éxito deseado, sin embargo las actividades relacionadas a la Interacción Hombre
Computador aun no llegan a tener los niveles adecuados. Es por eso que en este punto evaluaremos todo lo referente a la
usabilidad
4.1. Contexto de aplicación de la usabilidad

El contesto de uso de la usabilidad (Ferre, 2005) viene a ser bien amplio, dado que se debe de aplicar siempre en todos los
requerimientos de desarrollo de software, ya sea para aplicaciones de tipo escritorio, web o móvil. Ahora incluso la usabili-
dad se utilizara para el desarrollo de aplicaciones en el uso del Internet de las Cosas.
CALIDAD DE SOFTWARE
4.2. Metricas de usabilidad

Según Xavier Ferre (Ferre, 2005) las principales métricas de usabilidad son las siguientes:
• antidad de palabras por páginas

C
• Promedio de palabras por páginas
• Promedio de longitud de párrafos
• Validadores HTML
• Cantidad de objetos Javascipt
• Tiempo de descarga de las aplicaciones
• Cantidad de imágenes por titulo
4.3. Métodos de evaluación de la usabilidad

Según Xavier Ferre (Ferre, 2005) los principales métodos de evaluación de usabilidad:
• Inspección
o Este método se utiliza cuando un experto se encuentra evaluando las pantallas para indicar la calidad de la usabilidad.
• Indagación
o El proceso de indagación trata de llegar al conocimiento de una cosa discurriendo o por conjeturas y señales. En este
tipo de métodos de evaluación de la usabilidad una parte muy significativa del trabajo a realizar consiste en hablar
con los usuarios y observarlos detenidamente usando el sistema en trabajo real y obteniendo respuestas a preguntas
formuladas verbalmente o por escrito.
• Test
o En los métodos de usabilidad por test usuarios representativos trabajan en tareas utilizando el sistema o el prototipo
y los evaluadores utilizan los resultados para ver cómo la interfaz de usuario soporta a los usuarios con sus tareas.
TEMA N° 2: Pruebas o inspecciones dinámicas relacionadas al ISQTB

En el siguiente capítulo comprenderás la importancia de la Validación y Verificación Dinámica en la gestión de calidad del
software.
1 Proceso de pruebas
Las actividades del proceso de pruebas generalmente se desarrollan de manera secuencial, pero en algunos proyectos toman
lugar de manera concurrente o incluso se repiten. El proceso de pruebas es más que la ejecución de pruebas, ya que se deben
tener actividades de planificación y control durante todo el ciclo de pruebas.
Cada fase del proceso de pruebas tiene lugar de forma concurrente con las fases del proceso de desarrollo de software, que se
pueden representar de la siguiente forma (ISTQB, 2014):
PLANIFICACIÓN
( Nivel de detalle )
C
O Especificación
N Análisis de Pruebas y
T Diseño de Pruebas
R
O
L Implementación
y
Ejecución
D
E
Registro
P Evaluación de
R Criterio de Salida y
Generación de Informes
U
E
B Comprobación
A Actividad de
S Cierre de Pruebas
Figura 17: Proceso de Pruebas

Fuente: (ISTQB, 2014)
1.1. Planificación
En la etapa de planificación se realizan las siguientes actividades (ISTQB, 2014):
• eterminar el alcance y riesgos

D
• Identificar los objetivos de las pruebas y el criterio de finalización de pruebas
• Determinar el test approach (enfoque de pruebas)
• Técnicas de pruebas, elementos a probar, cobertura, identificación de las interfaces entre los equipos involucrados en
las pruebas, y testware (artefactos producidos durante el proceso de pruebas)
• Implementar las políticas de pruebas y/o la estrategia de pruebas
• Planificar las tareas de análisis y diseño; implementación y ejecución de
• pruebas; y evaluación
• Adquirir / obtener y programar recursos requeridos por las pruebas: per-sonal, entorno de pruebas, herramientas,
presupuesto de pruebas
• Definir el exit criteria (criterio de salida)
1.2. Control de pruebas

El control de pruebas es una actividad continua que influye en la planificación de las pruebas. El plan de pruebas puede ser
modificado en función de la retroalimentación proporcionada por la actividad de control de pruebas.
El estado del proceso de pruebas se determina comparando el progreso logrado con respecto al plan de pruebas. Se inicia-
rán aquellas actividades que se considerarán consecuentemente necesarias. (ISTQB, 2014).
Las principales actividades que se realizan son:

CALIDAD DE SOFTWARE
• M edir y analizar los resultados de las revisiones y pruebas

• Monitorear el progreso de las pruebas, la cobertura de las pruebas y el cumplimiento del exit criteria (criterio de finali-
zación)
• Proveer información de las pruebas
• Iniciar medidas correctivas en caso exista incumplimiento de actividades
1.3. Análisis
En la etapa de análisis se realizan las siguientes actividades (ISTQB, 2014):
• R evisión de los test base (requisitos, arquitectura del sistema. diseño, interfaces), analizando las especificaciones del sof-
tware a probar
• Identificar los test conditions (condiciones de prueba) basándose en:
o el análisis de los objetos de pruebas
o Sus especificaciones
o Conocimiento del comportamiento y estructura
1.4. Diseño
En la etapa de diseño se realizan las siguientes actividades (ISTQB, 2014):
• S e definen los casos y procedimientos de prueba

• Crear casos de prueba lógicos (casos de prueba con datos de prueba sin valores específicos) y establecer un orden de
prioridad para los mismos
• Los casos de prueba positivos comprueban la funcionalidad, los casos de prueba negativos comprueban situaciones en las
cuales se debe realizar un tratamiento a los errores
• Evaluar la testability (característica que define la capacidad que posee un software de ser probado) de los requerimientos
y el sistema
• Diseñar la configuración del ambiente de pruebas e identificar la infraestructura y herramientas
1.5. Implementación
En la etapa de implementación se realizan las siguientes actividades (ISTQB, 2014):
• esarrollar y priorizar los casos de prueba

D
• Crear los datos de prueba
• Elaborar los procedimientos de prueba
• Crear las test suites desde los casos de prueba para definir una ejecución de las pruebas eficientes
• Implementar y verificar el ambiente
1.6. Ejecución
En la etapa de ejecución se realizan las siguientes actividades (ISTQB, 2014):
• E jecutar las test suite y los casos de pruebas individuales, siguiendo la secuencia definida en los test procedures (procedi-
mientos de pruebas). La ejecución de las pruebas puede ser de forma manual o automática
• Registrar el resultado de la ejecución de las pruebas, la identificación y versión del software probado, herramientas de
pruebas y testware
• Comparar los resultados actuales con los resultados esperados
• Reportar las discrepancias entre los resultados actuales y esperados como incidentes
• Repetir las pruebas para cada incidente
• Luego de una corrección se repiten las pruebas con el objeto de asegurar que los defectos han sido corregidos y que la
corrección no introduce nuevos defectos
1.7. Salida y generación de informes

En esta etapa se empiezan a evaluar los resultados de la ejecución de pruebas contra los valores esperados y criterios de acep-
tación definidos en la planificación de las pruebas. Se puede evaluar si es necesario realizar más actividades de pruebas o si el
criterio de aceptación debe ser cambiado. Cuando se termina de realizar el análisis de la ejecución de los resultados se reali-
zará un reporte-resumen de las pruebas. (ISTQB, 2014).
1.8. Actividades de cierre y pruebas

En la etapa de cierre y pruebas se realizan las siguientes actividades (ISTQB, 2014):
• C omprobar qué entregables planificados han sido entregados

• Informe de las incidencias cerradas y diferidas
• Cerrar y archivar los testware (artefactos generados en el proceso de pruebas), tales como scripts, el entorno de pruebas
y la infraestructura de pruebas
• Analizar y registrar las lecciones aprendidas para futuros proyectos
• Documentar la aceptación del sistema
2 Tipos de pruebas
2.1. Pruebas funcionales

El objetivo de las pruebas funcionales es validar que la aplicación funcione como esta especificada. Están basadas en escena-
rios de negocios. Son realizadas desde el punto de vista del usuario final, que es la persona que utilizará el sistema. (ISTQB,
2014).

Se pueden automatizar usando scripts manuales o automáticos, como:
• S
elenium IDE
• R ational Functional Tester
2.2. Pruebas de robustez

Validan que la aplicación no falle al recibir comandos inesperados. Los errores que buscan encontrar es que el software ter-
mine abruptamente, se cuelgue o exhiba salidas (output) indeseadas. (ISTQB, 2014).
Cubren métodos de caja negra, incluyendo:
• Valores límite
• Corrupción de data
• Tipos erróneos
• Inyección de faltas
Automatizables usando scripts o herramientas como:

• Rational Robot - pruebas a través del entorno GUI
• Holodeck – pruebas a través de diferentes interfaces del software
2.3. Pruebas de rendimiento

Analizan diferentes factores de rendimiento del software en diferentes escenarios de uso, como por ejemplo (ISTQB, 2014):
• t iempos de respuesta
• consumo de recursos
• habilidad de soportar cargas
Mayormente automatizadas con scripts y herramientas como:

• Web Application Stress Tool (Microsoft)
• Rational Performance Tester
• JMeter
2.4. Pruebas de seguridad

Prueban que el software no sea víctima de ataques cibernéticos. Están basadas en modelos de amenazas de software. Usual-
mente se realizan usando métodos de caja blanca y caja negra. (ISTQB, 2014).
Usan depuradores, scripts y diferentes herramientas como:
• W ireshark: Monitorea paquetes de diferentes protocolos de red

• Burp Proxy: Proxy de HTTP que permite modificar los paquetes de red HTTP que envía y recibe un cliente web, como
un browser web
• Cain: Permite la ejecución de ataques a credenciales como ataque de fuerza bruta y ataque de diccionario
• Kali Linux: Sistema operativo que viene con un conjunto de herramientas para ejecutar diferentes tipos de pruebas de
seguridad
2.5. Pruebas de usabilidad

Verifican que la aplicación sea fácil de usar, buscan que el usuario se lleve una primera buena impresión del software y
comúnmente involucran un grupo de usuarios reales del software para validar que se dieron por aprobadas las pruebas.
(ISTQB, 2014).
Los errores que incluyen son los siguientes:

• Navegación compleja
• Botones mal posicionados
• Menú incongruente
• Textos ilegibles
CALIDAD DE SOFTWARE
Macchi, D., & Solari, M. (2013). Diagnóstico del Uso de Técnicas de Revisión de Software en Uruguay. In XVI Congreso Iberoamerica-
no en Ingeniería de Software (CI-bSE 2013) (p. 486). Montevideo: Congreso Iberoamericano en Ingeniería de Software. Disponi-
ble en http://fi.ort.edu.uy/innovaportal/file/2038/4/diagnosticorevision_macchisolari.pdf
Gonzáles Palacios, L. (2009). Método para generar casos de prueba funcional en el desarrollo de software. Revista Ingenierías Uni-
versidad de Medellín, 8(15), 29–36. Disponible en http://revistas.udem.edu.co/index.php/ingenierias/article/view/175/164
ACTIVIDAD Nº 1
Foro de discusión sobre la importancia de la V&V Estática.
Instrucciones
Participa en el desarrollo y resolución de las preguntas y ejercicios planteados. Foro debate n.° 1: foro de participación sobre
V&V Estática con la orientación de tu docente.
• ¿ Qué es la V&V Estática?

• ¿Qué tipos de técnicas de revisión existen?
ACTIVIDAD Nº 2
Foro de discusión sobre la importancia de las pruebas de software.
Instrucciones
pruebas de software con la orientación de tu docente.
• D efine con tus propias palabras lo que son pruebas de software

• Menciona cinco tipos de pruebas de software y da ejemplos de en qué caso los utilizarías.
CALIDAD DE SOFTWARE
GLOSARIO DE LA UNIDAD III

1. Acceso Desautorizado
Ingresar a la aplicación sin credenciales válidas (nombre de usuario y contraseña)
2. Elevación de privilegios
Ejecutar código malicioso en el sistema como un virus o caballo troyano
3. Robo de data privada
Robar data sensible de la aplicación o sus usuarios
4. Negación de servicios del software
Impedir que los demás usuarios puedan usar la aplicación
5. Pérdida o corrupción de data
Eliminar o corromper los contenidos de una base de datos o archivos del usuario
6. Módulo Independiente
Requerimientos específicos al módulo
7. Integración de Módulos
Requerimientos que cubren varios módulos
8. Escenarios de Negocios
Escenarios complejos con distintos actores

BIBLIOGRAFÍA DE LA UNIDAD III

Juristo, Natalia; Moreno, Ana; Vegas, Sira (2006). Técnicas de Evaluación de Soft-ware. [en línea]* [Consulta: 09 de
Setiembre de 2016]. Disponible en Web: http://www.grise.upm.es/htdocs/sites/extras/12/pdf/Documentacion_
Evaluacion_7.pdf
ECURED (2016). Técnicas de Evaluación de Software. [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en
Web: https://www.ecured.cu/Revisiones_T%C3%A9cnicas_Formales
FERRE, XAVIER (2005). Marco de Integración de la Usabilidad en el Proceso de Desarrollo de Software [en línea]*
[Consulta: 09 de Setiembre de 2016]. Disponible en Web: http://oa.upm.es/440/1/XAVIER_FERRE_GRAU.PDF
IBM (2016). Software Product Assurance . [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web:
http://www.ibm.com
ISTQB (2014). International Software Testing Qualifications Board. [en línea]* [Consulta: 09 de Setiembre de 2016].
Disponible en Web: http://www.ibm.com
OVERTI (2016). Gestión de Requisitos. [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web: http://
www.overti.es/gestion-requisitos
CALIDAD DE SOFTWARE
AUTOEVALUACIÓN DE LA UNIDAD III

a. Una acción preventiva

b. Una acción correctiva
c. Defecto
d. Inconsistencia
2. En un proyecto de implementación de SAP, el gerente de finanzas (interesado) descubre una inconsistencia en el producto
y reporta al área de sistema que su auxiliar definió mal el requisito a implementar. Bajo esta premisa, ¿qué debe registrar el
área de calidad en su sistema de incidencias?
a. Falla
b. Error
c. Defecto
d. Inconsistencia
3. En la fase de construcción se están elaborando los documentos de casos de pruebas de acuerdo a las solicitudes de cambio
emitidas y aprobadas por el cliente. ¿Qué tipo de V&V se tendrá que aplicar para estos documentos? (0.5 ptos)
a. V&V Dinámica
b. Revisión
c. V&V Estática
d. Inspección
4. La V&V requiere ser administrada y realizada en forma completa durante qué proceso de desarrollo de software:
a. Planificación
b. Gestión
c. Ejecutar / interpretar
d. Reportar
e. Monitorear
a. Se despliega en el ambiente de producción

b. Pruebas funcionales y no funcionales
c. Se despliega en un ambiente controlado
d. Revisa la estructura interna
e. Se hace uso de documentación de estándares y procesos
6. Se define caja blanca como:
a. No interesa el proceso de construcción

b. Compara lo especificado con el producto entregado
d. Pruebas funcionales y no funcionales
7. Se define pruebas alfa como:

b. Realizadas en un ambiente controlado
c. Realizadas en un ambiente no controlado
d. Se despliegan en el ambiente de producción
8. Se define pruebas beta como:

b. Se despliegan en el ambiente de producción
c. Se despliegan en un ambiente controlado
d. Se despliegan en un ambiente de prueba
9. ¿Se está desarrollando el producto correcto? Responde a:
a. Verificación
b. Chequeo
c. Validación
d. Inspección
e. Auditoría
10. ¿Se está construyendo de forma adecuada el producto? Se refiere a:
a. Validación
b. Verificación
c. Chequeo
d. Monitorear
Anexo
Respuestas a la autoevaluación de la Unidad III
Preguntas Respuesta
1 A
2 B
3 C
4 B
5 B
6 C
7 B
8 B
9 C
10 B
CALIDAD DE SOFTWARE
UNIDAD IV: Control de calidad
DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD IV
Resultado de aprendizaje de la Unidad IV:

Al finalizar la unidad, el estudiante describe el ciclo de vida de las pruebas de software dentro de un proyecto de sistemas y lo relaciona con las actividades
que impactan en la calidad del software.

Tema N° 1: Pruebas de software 1. Describe los conceptos de calidad a nivel de Valora la importancia de la calidad en el desa-
1. Ciclo de vida de las pruebas de software producto y servicio asociándolos a la Ingenie- rrollo de software.
2. Estrategias de las Pruebas de Software ría de software.
3. Plan de pruebas
4. Estimación de pruebas 2. Describe los principios de la gestión de ca-
5. Calidad de los almacenes y modelos de datos lidad y explica cómo la mejora continua de
(calidad de datos) procesos permite la calidad en los proyectos
6. Creación de la estructura de Calidad y servicios.
7. Medición de los atributos de calidad
Actividad N° 1
Tema N° 2: Tipos de pruebas Los estudiantes participan en el foro de discu-
1. Pruebas unitarias, de integración y de sistema sión sobre técnicas de pruebas
2. Pruebas de caja blanca y caja negra
3. Pruebas funcionales y no funcionales Actividad N.º 2
Lectura seleccionada N° 7 sión sobre herramientas de software
Tema N° 3: Uso de herramientas y técnicas

1. Calidad de los sistemas web
1.1.El modelo de navegación
1.2.Contexto de exploración
1.3.Calidad en las aplicaciones de los mercados
electrónicos
1.4.Valoración de la calidad
2. Herramientas de manejo de Plan de Pruebas
3. Herramientas de manejo de Incidencias
4. Software de ejecución de pruebas
Lectura seleccionada N°8
Autoevaluación de la Unidad IV
58 UNIDAD IV Control de calidad
TEMA N° 1: Pruebas de software
En el siguiente capítulo comprenderás la importancia de las pruebas de software en la gestión de calidad del software.
1 Ciclo de vida de las pruebas de software
El ciclo de vida de las pruebas de software se puede representar de la siguiente manera (Juristo, Moreno & Vegas, 2006):
Análisis Diseño Ejecución

• Recolección información • Validación técnica de pruebas • Ejecución de pruebas
• Análisis información • Diseño de pruebas • Reproceso
• Planeación pruebas • Construcción de instrumentos • Registro de hallazgo e información de QA
Figura 18: CMMI®

Fuente: (CMMI, 2014)
1.1. Análisis
En la etapa de análisis se realizan las siguientes actividades (CMMI, 2014):
• R evisar los requerimientos funcionales del producto de software, para que en función a ello se pueda comenzar a des-
componer el producto en diferentes funciones.
• Se recibe información técnica del producto de software para que se puedan solicitar los requerimientos de hardware y
software para desplegar el producto.
• Cronograma de actividades del componente de desarrollo, para que de esa manera se pueda especificar en qué momen-
to se empezará el ciclo de pruebas.
1.2. Diseño
En la etapa de diseño se realizan las siguientes actividades (CMMI, 2014):
• I dentificar técnicas de pruebas apropiadas a tipos de pruebas definidas en el plan de pruebas.

• Se empiezan a construir los scripts de pruebas, tanto los scripts manuales como los automatizados.
1.3. Ejecución
En la etapa de ejecución se realizan las siguientes actividades (CMMI, 2014):
• E jecución de requerimientos de pruebas para que de esa manera se pueda realizar el registro de hallazgos.
• Se realiza el análisis de resultados de pruebas para que se pueda generar el documento de informe de pruebas que será
entregado al cliente.
2 Estrategia de las pruebas de software
Define el contexto de la aplicación en relación a sus usuarios humanos y de siste-mas. También define en un alto nivel las fuentes
de entrada y salida (input / output) de la aplicación. Es una forma de cómo guiar las pruebas de software. Siempre se debe
tener presenta que las pruebas de software consisten en ingresar comandos y data a una aplicación para que de esa manera las
respuestas que nos devuelva la aplicación las comparemos con un resultado que estamos esperando. El modelo de fallas ayuda a
definir todos los puntos de entradas y salidas de la aplicación y es usado como una estrategia de pruebas. Dicho modelo se puede
representar de la siguiente manera (CMMI, 2014):
CALIDAD DE SOFTWARE
Configuración
Humano
Aplicación
APIs de software Fuentes de
Data
Entorno
Red Operativo
Figura 19: Modelo de Fallas

Fuente: (CMMI, 2014)
2.1. Usuario humano

Es el más notorio dentro de los usuarios de la aplicación, porque ejecuta comandos a través de la interface del usuario y a la
par influye directamente sobre el comportamiento de aplicación. Usualmente puede tomar diferentes roles. Y es común que
utilice aplicaciones de escritorio, de consola, aplicaciones web y aplicaciones móviles. (ISTQB, 2014).
2.2. Usuario fuente de datos

Provee input a la aplicación en forma de data almacenada e influye indirectamente en el comportamiento de la aplicación
(usuario invisible). Se debe tener en cuenta qué data corrupta puede generar errores. (ISTQB, 2014).
2.3. Usuario de red

Provee input a la aplicación en forma de conexiones y paquetes de red. Se debe tener en consideración que los valores de este
usuario son menos confiables. Común en aplicaciones de lado-servidor, distribuidas y cliente-servidor. Emplea protocolos de
red públicos y privados. (ISTQB, 2014).
2.4. Usuario API

API significa Application Programming Interface (Interface de Programación de la Aplicación). El comportamiento dentro
de APIs, tanto como valores de retorno, afectan el comportamiento de la aplicación que las invoca. Este usuario genera erro-
res que no podemos controlar, dado que el API pertenece a un tercero. (ISTQB, 2014).
2.5. Usuario configuración

Afecta el comportamiento inicial de la aplicación, dado que se configuran parámetros iniciales para que la aplicación pueda
trabajar. Muchas de las veces utilizan configuración por defecto y otras son controladas por usuarios. Este usuario es crítico
para el funcionamiento correcto de aplicaciones (mala configuración = aplicación inoperativa) (ISTQB, 2014).
3 Plan de pruebas
Un plan de pruebas sirve por muchas razones, pero principalmente organiza el esfuerzo de pruebas (proyecto) dentro o después
de un proyecto de desarrollo. Es necesario que todos los involucrados en las pruebas tengan una guía para realizar sus funciones.
Las partes principales que debe tener un plan de pruebas son las siguientes (IEEE 829, 2010):
• lcance de las pruebas (tipos y métodos a usar, partes del producto que se probarán)
A
• Proceso de pruebas (desarrollo, ejecución, reportes)
• Criterio de entrada y salida
• Cronograma
• Recursos
• Roles y responsabilidades
• Riesgos y precondiciones
• Firmas
• Documentación de controles
4 Estimación de pruebas
4.1. Estimación por objetos

La estimación por objetos se basa en la clasificación del tipo de objeto según lenguaje de programación, es por eso que di-
cho método presenta un progreso más lento que la utilización de otros métodos. La estimación basada en objetos depende
mucho de la experiencia con la que cuenta el gestor de proyecto y de los datos que este posea. Esta técnica es útil al estimar,
pero no es confiable al 100 % (OEI, 2008).
Se debe tener en cuenta que no proporciona resultados fiables en proyectos demasiado pequeños, pues está pensado para
proyectos de mayor envergadura y se requiere usar datos de proyectos anteriores, los cuales no siempre están disponibles.
A continuación, un ejemplo de una herramienta de estimación por objetos:

TIPO DE COMPLEJIDAD DEL COMPLEJIDAD DEL Esfuerzo ESTIMADO
LENGUAJE DESCRIPCIÓN DE OBJETO C/M CANTIDAD
OBJETO OBJETO CAMBIO ( Horas )
SHAREPOINT JS Javascript M Complejo Medio 1 3.0000000
PB INI Archivo Configuración M Medio Complejo 2 2.71875000
SHAREPOINT CSS Hoja de Estilos C Simple Simple 3 6.00000000
Archivo de configuración C
JAVA CFG Medio Medio 2 15.82500000
XML / Texto
Fase / Actividad Porcentaje Esfuerzo (HH)

Porcentaje TOTAL
Esfuerzo Horas - Hombre
Implementación y Pruebas 5.00% 3.33
70% 28.00 Incepción
Unitarias
Pruebas Integrales 15% 6.00 Elaboración 25.00% 16.67
15% 6.00 Construcción 60.00% 40.00

Pruebas de Calidad
ESFUERZO FASE CONSTRUCCIÓN 100% 40.00 Transición 10.00% 6.67
Total ( Horas ) 66.67
Figura 20: Estimación por Objetos

4.2. Estimación por casos de uso

Este es un método de estimación de esfuerzo para proyectos de software. Su objetivo es estimar las horas necesarias para eje-
cutar un conjunto de casos de uso; es decir, necesitamos predecir cuánto tiempo llevará el desarrollo de software y cuántas
personas se requieren para realizarlo. Para ello es necesario cuantificar la complejidad del sistema y el tiempo necesario para
producir una unidad de complejidad (García, 2010).
A continuación, un ejemplo de una herramienta de estimación por casos de uso:
Total de Actores Valor Estabilidad

Tipo de Actor Peso Factores del Valor Asignado Valor
Ingresar cantidad ponderado Peso de la Porcentaje TOTAL
ambiente y equipo ( 0 al 5 ) Ponderado experiencia
Actor Simple 1 2 2 Implementación y Pruebas
A1 Familia con el modelo 70% 373.07
1.5 3 4.5 Unitarias
del proyectoutilizado 0
3 Pruebas Integrales 15% 79.94
Actor Medio 2 6
A2 experiencia en la
aplicación 0.5 5 2.5 0 Pruebas de Calidad 15% 79.94
Actor Completo 3 2 6 A3 Experiencia en el ESFUERZO FASE CONSTRUCCIÓN 100% 532.96
lenguaje de programación 1 4 4 0
Total de Actores
Identificados
14
A4 Capacidad del
0.5 3 1.5 0 Esfuerzo requerido
Analista Líder
Fase / Actividad
Porcentaje Esfuerzo (HH)
A5 Motivación 1 4 4 0 esfuerzo Horas - Hombre
Tipo de Total Casos de Uso Valor
Peso Incepción
Pruebas de Calidad 5.00% 48.45
Caso de Ingresar cantidad ponderado
A6 Requerimientos
2 3 6 0
Caso de estables Elaboración
1 2 2 30.00% 290.70
Uso Simple
A7 personal de medio
-1 5 -5 1 Construcción 55.00% 532.96
tiempo
Caso de 2
Uso Medio 5 10
A8 dificultad del lenguaje Transición 10.00% 96.90
de programación -1 2 -2 0
Caso de 3
Uso Completo 4 12
Factores ESFUERZO TOTAL 100.00% 969.01
Ambientales 15.50 1
Total Casos de Uso ESFUERZO TOTAL + RESERVA DE
Identificadores 24 Factores de Complejidad Ambiental (FA) 982.21
CONTINGENCIA
(FPCUSA) =1.4 + (-0.03* Factores Ambientales) 0.94
Figura 21: Estimación por Casos de Uso

CALIDAD DE SOFTWARE
5 Calidad de los almacenes y modelos de datos (calidad de datos)
La calidad de los almacenes de datos se encuentra muy relacionados a los modelos de datos que se definan en la etapa de
requerimientos del software, este modelo nos ayudara a determinar que buena calidad de datos tenemos para luego poder obtener
información sobre ella (Estupiñan,2014).
Los almacenes de datos (AD) se han convertido en los últimos años en una de las más importantes herramientas de trabajo
para investigadores, analistas y planificadores, y son usados en todas las actividades que tienen como insumo el manejo de datos
relacionados con las diversas áreas de un entorno
6 Creación de la estructura de Calidad de Datos
En todos los tiempos y más aún en la era en que vivimos, el hombre tiene cada vez más necesidad de consultar una mayor cantidad
de información para poder desarrollar sus actividades. El gran cúmulo de información ha hecho necesario que ésta tenga que ser
almacenada y organizada correctamente para acceder a ella rápidamente.
Según lo visto hasta el momento, la única forma que tiene el ordenador de almace-nar la información es mediante variables,
que no son más que porciones de la memoria central del mismo. Pero al ser la memoria central un conjunto de dispositivos
electrónicos que funcionan mediante la alimentación eléctrica, cuando se apaga el ordenador, toda la información que había en
su memoria central desaparece.
7 Medición de los atributos de calidad
Según Alonso Amo (Amo, 2002) algunas métricas para medir atributos de calidad son:
• Fiabilidad: Se calcula con la fórmula de Tiempo medio entre Fallos, que nos indica cuanto es el tiempo que demora un
Software en encontrar el error y repararlo.
• Mantenibilidad: Se calcula con la fórmula de Tiempo medio de Reparación, que nos indica cuanto es el tiempo que de-
mora un Software en repararlo.
• Disponible: Es el tiempo que un software permanece sin fallas.
• Modificabilidad: Es la capacidad que tiene un software de agregar cambios sin que afecte su funcionalidad.
• Integridad: Se mide calculando que tan exacto son los números al momento de realizar operaciones.
• Eficiencia: Es la capacidad que tiene un Software de usar los recursos de Hadware y Sotfaware de manera adecuada.
• Robustez: Es la capacidad que tiene un Software de soportar una carga de peticiones esperadas
TEMA N° 2: Tipos de pruebas
En el siguiente capítulo serás capaz de comprender los distintos tipos de pruebas de software de acuerdo a los roles y resultados
que se esperan obtener.
1 Pruebas unitarias, integración y de sistemas
1.1. Pruebas unitarias

Evalúan el correcto funcionamiento de un módulo (función) de código. Esto quiere decir que es código probando código.
Las características que debe tener una prueba unitaria son (ISTQB, 2014):
• Automatizables
• Completas
• Reutilizables
• Independientes
1.2. Pruebas integrales

La prueba de integración es una técnica sistemática para construir la estructura del programa mientras que, al mismo tiem-
po, se llevan a cabo pruebas para detectar errores asociados con la interacción. Se realizan dentro del ámbito de desarrollo
de software y posterior a las pruebas unitarias. Se prueban varios elementos unitarios que participan en un proceso (ISTQB,
2014).
1.3. Pruebas de sistemas

Buscan probar a la aplicación (o sistema) como un todo y están basadas en requerimientos (funcionales y no funcionales).
Este tipo de pruebas siempre se realizarán dentro del ámbito de testing (ISTQB, 2014).
1.4. Pruebas de aceptación

El objetivo de las pruebas de aceptación es validar que un sistema cumple con el funcionamiento esperado y permitir al
usuario de dicho sistema que determine su aceptación, desde el punto de vista funcional y no funcional. El único encargado
de realizar este tipo de pruebas es el cliente final, el que utilizará el producto. (ISTQB, 2014)
2 Pruebas de caja blanca y caja negra
2.1. Pruebas de caja blanca

Las pruebas de caja blanca usan conocimiento interno del desarrollo del software para validar el producto, es por eso que
mayormente utilizan técnicas de veri-ficación. Se requiere que las personas que realizan este tipo de pruebas tengan ha-bi-
lidades de programador.
Son aplicables a los diferentes niveles de pruebas (unitarias, integración, sis-temas), pero son incapaces de detectar:
• Falta de funcionalidad (errores de omisión de código)

• Caminos inesperados
Los tipos de pruebas de caja blanca más usados son los siguientes:

• P ruebas de caminos básicos
• Pruebas de flujo de control / cobertura
• Pruebas de falla («sucias»)
2.2. Pruebas de caja negra

Estas pruebas permiten obtener un conjunto de condiciones de entrada que ejerciten completamente todos los requisitos
funcionales de un programa. En ellas se ignora la estructura de control, concentrándose en los requisitos funcionales del
sistema y ejercitándolos.
La prueba de caja negra no es una alternativa a las técnicas de prueba de la caja blanca, sino un enfoque complementario
que intenta descubrir diferentes tipos de errores a los encontrados en los métodos de la caja blanca. (ECURED, 2016).
Los tipos de pruebas de caja negra más usados son los siguientes:
• Particiones equivalentes
• Todos los pares
• Testeo en base a modelos
• Pruebas difusas.
CALIDAD DE SOFTWARE
3 Pruebas funcionales y no funcionales
3.1. Pruebas funcionales

Las pruebas funcionales se basan en realizar pruebas a los requisitos de un cliente. Están muy asociadas al negocio del cliente,
es por eso que mayormente se utilizan pruebas del tipo de caja negra.
Este tipo de pruebas son las que más valor tienen, ya que es el usuario quien dará el visto de la ejecución de las mismas (IS-
QTB, 2014).
3.2. Pruebas no funcionales

Las pruebas no funcionales son pruebas que validan la estructura interna y externa de un producto de software. Son prue-
bas que se complementan con las pruebas funcionales para poder crear productos de calidad. Entre las principales pruebas
tenemos (ISQTB, 2014):
• ruebas de estrés
P
• Pruebas de carga
• Pruebas de volumen
• Pruebas de usabilidad
TEMA N°3: Uso de herramientas y técnicas
En el siguiente capítulo serás capaz de comprender los distintos tipos de pruebas de software de acuerdo a los roles y resultados
que se esperan obtener.
1 Calidad de los Sistemas Web
1.1. El modelo de Navegación

El modelo de navegación ayuda a que podamos representar de manera facilidad la navegación dentro de un portal Web, es
por eso que se encuentra considerado como un atributo de calidad de las aplicaciones (Cueva, 2015).
1.2. Contexto de Exploración

Se debe de tener cuenta que para realizar un buen modelo de navegación se debe de tener correctamente el mapeo del
sitio de las paginas, bajo los siguientes criterios (Cueva, 2015)
• E squema de Organización Global

o Creación de tablas de contenido
o Mapa de sitio
o Índices
• Visita guiada
• Mapa de imagen
1.3. Calidad en las aplicaciones de los mercados electrónicos

Actualmente el mercado electrónico está teniendo mucho crecimiento, aplicaciones usando billeteras electrónicas, Block-
Chain, entre otros esta haciendo que las aplicaciones se tengan que realizar de manera más segura (Cueva, 2015)
Bajo este esquema se propone que las aplicaciones se les apliquen políticas de seguridad de las aplicaciones.
Para aplicar estas pruebas de seguridad se tiene que cumplir con los lineamientos del OWASP que lo podemos encontrar
en la siguiente ruta: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
1.4. Valoración de la calidad

La valoración de calidad de software se logra medir con todo lo visto durante estas sesiones y aplicando las diferentes nor-
mas, que nos ayudan a tener calidad de procesos y de productos, que son los siguientes
• I SO 9000, gestión y aseguramiento de calidad (conceptos y directrices gene-rales).

• Recomendaciones externas para aseguramiento de la calidad (ISO 9001, ISO 9002, ISO 9003).
• Recomendaciones externas internas para aseguramiento de la calidad (ISO 9004).
• Malcom Baldridge national quality award.
• Software Engineering Institute (SEI).
• Capability Maturity Model (CMM).
• Six Sigma.
2 Herramienta de Manejo de Plan de Pruebas (Testlink)
El Testlink® es una herramienta Open Source que nos permite la Gestión de un Plan de Prueba en un entorno Web que fue
desarrollado en el Lenguaje de Programación PHP y soporta distintas Base de Datos
El beneficio de utilizar esta herramienta es (Testlink, 2016)
• E limina el desorden y dependencia de varios documentos por separado.

• Es gratuito
• Mantenimiento de proyectos múltiples. No es necesario escribir casos de pruebas iguales para diferentes proyectos con
escenarios similares.
• Repositorio centralizado para todos los casos de prueba.
• Repositorio centralizado para los resultados de las pruebas
• Existe trazabilidad entre requerimientos y casos de prueba
• Es posible visualizar multiples reportes y de diferente tipo.
Se debe de tener en cuenta las siguientes definiciones para su utilización.
• T est Project: Unidad sobre la cual se gestionan los siguientes módulos -> Test Specification, Test Cases, Requirements y
Keywords.
• Test Plan: Es la unidad que permite gestionar los test cases, builds, usuarios asignados y test results.
• Test Suite: Se refiere a paquetes o carpetas que contienen test cases.
CALIDAD DE SOFTWARE
• T est Case: Se refiere al espacio en el cual la herramienta permite crear, editar y eliminar test cases y sus versiones.
• Users: Se refiere a los roles que pueden ejecutar ciertas funciones de la herramienta.
3 Herramienta de Manejo de Incidencias (MantisBT)
El MantisBT® es una herramienta opensource, cuya finalidad es gestionar de forma ordenada y eficiente las incidencias de
diversos proyectos de software.
El ciclo de vida de una incidencia inicia con su creación. Por lo tanto una incidencia puede ser creado por una de las siguientes
vías (Mantisbt, 2016):
• I nterfaz Web de MantisBT: Un usuario ingresa a la aplicación y reporta una nueva incidencia.
• SOAP API: Usando servicios web una aplicación externa puede registrar una nueva incidencia.
• Otros: Aplicaciones / Scripts que registran directamente una nueva incidencia dentro de la base de datos de MantisBT
o scripts PHP.
4 Software de Ejecución de Pruebas (Selenium)
Conjunto de herramientas para automatizar pruebas funcionales sobre sistemas ba-sados en web a través de diferentes plataformas.
Y se encuentra conformado por los siguientes productos (Selenium, 2010)
Selenium Web Driver

Puede ejecutar un srcipt en un navegador de forma nativa ,
sin necesidad de usar Selenium Server.
Selenium IDE
Es un plugin para Firefox, que permite grabar un script y
reproducirlo.
Selenium Remote Control

Es una aplicación de tipo cliente /servidor que permite
ejecutar aplicaciones remotas, usando el Selenium Server.
Selenium Grid
Puede ejecutar aplicaciones remotas de manera concurrente .
Figura 22: Suite Selenium

Fuente: (Selenium, 2016)
Torres, M. (s.f.). Técnicas de prueba. Almería, España: Universidad de Almería. Disponible en http://indalog.ual.es/mtorres/
LP/Prueba.pdf
Esmite, I., Farías, M., Farías, N. & Pérez, B. (2007). Automatización y gestión de las pruebas funcionales usando herramientas
open source. Anales del XIII Congreso argentino de ciencias en la computación. Corrientes, Argentina: Universidad Nacional del
Nordeste, 294–305. Disponile en http://libros.unlp.edu.ar/index.php/unlp/catalog/view/313/293/956-1
CALIDAD DE SOFTWARE
ACTIVIDAD Nº 1
Foro de discusión sobre la importancia de las técnicas de pruebas.
Instrucciones
Participa en el desarrollo y resolución de las preguntas y ejercicios planteados. Foro debate N.° 1: foro de participación sobre
técnicas de pruebas con la orientación de tu docente.
• M encione 05 técnicas de pruebas para Caja Blanca e investigue con que herramienta se puede automatizar las prue-
bas de Caja Blanca
• Mencione 05 técnicas de pruebas para Caja Negra e investigue con que herramienta se puede automatizar las pruebas
de Caja Negra
•
ACTIVIDAD Nº 2
Foro de discusión sobre la importancia de las herramientas de pruebas de software.
Instrucciones
herramientas de software con la orientación de tu docente.
• M encione 03 herramientas para la Gestión de Plan de Pruebas y cuáles son sus principales ventajas
• Mencione 03 herramientas para la Automatización de Pruebas Funcionales y cuáles son sus principales ventajas
GLOSARIO DE LA UNIDAD IV
1. Pruebas de Software
Es el proceso de ejecutar un programa o sistema con la intención de encontrar errores.
2. Pruebas Unitarias
Pruebas que la valida la funcionalidades de un método.
3. Pruebas de Integración
La prueba de Integración es una técnica sistemática para construir la estructura del programa mientras que al mismo
tiempo, se llevan a cabo pruebas para detectar errores asociados con la interacción
4. Pruebas de Sistemas
Buscan probar a la aplicación (o sistema) como un todo y se realizan en el ambiente de Testing.
5. Pruebas de Aceptación
Son Pruebas Funcionales y No Funcionales que realiza el cliente.
6. Prueba de Caja Blanca
Valida la estructura interna del programa.
7. Prueba de Caja Negra
Valida la estructura externa del programa.

CALIDAD DE SOFTWARE
BIBLIOGRAFÍA DE LA UNIDAD IV
Juristo, Natalia; Moreno, Ana; Vegas, Sira (2006). Técnicas de Evaluación de Software. [en línea]* [Consulta: 09 de Se-
tiembre de 2016]. Disponible en Web: http://www.grise.upm.es/htdocs/sites/extras/12/pdf/Documentacion_Eva-
luacion_7.pdf
CMMI (2014). Capability Maturity Model Integration. [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en
Web: https://www.sei.cmu.edu/cmmi/
Cueva, J. (2005). Capability Maturity Model Integration. [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible
en Web: http://di002.edv.uniovi.es/~cueva/asignaturas/masters/2005/MetricasUsabilidad.pdf
ECURED (2016). Técnicas de Evaluación de Software. [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en
Web: https://www.ecured.cu/Pruebas_de_caja_negra
ESTUPIÑAN JOSE (2014). La Calidad en Almacenes de Datos: Estrategia para Aseguramiento de la Calidad en Proyec-
tos de Almacenes de Datos (Spanish Edition) Disponible en Web: https://www.amazon.com/Calidad-Almacenes-Da-
tos-Estrategia-Aseguramiento/dp/3659084867
IBM (2016). Software Product Assurance . [en línea]* [Consulta: 09 de Setiembre de 2016]. Disponible en Web:
http://www.ibm.com
ISTQB (2014). International Software Testing Qualifications Board. [en línea]* [Consulta: 09 de Setiembre de 2016].
Disponible en Web: http://www.ibm.com
AUTOEVALUACIÓN DE LA UNIDAD IV
1. ¿Cuál de las siguientes es la PRINCIPAL tarea en la planificación de las pruebas?
a. Calendarizar las tareas de análisis y diseño de pruebas

b. Iniciar las acciones correctivas
c. Monitorear el progreso y la cobertura de pruebas
d. Medir y analizar los resultados
2. ¿Cuál de las siguientes es una tarea IMPORTANTE en la implementación y ejecución de pruebas?
a. Medición y análisis de resultados

b. Informar las discrepancias como incidentes
c. Identificación de las condiciones de prueba o requisitos de la prueba
d. Evaluación de si son necesarias más pruebas
3. ¿Cuál de las siguientes es una ventaja de la independencia de las pruebas?
a. No requiere familiaridad con el código

b. Es más barata que utilizar a los desarrolladores para probar su propio código
c. Se evita el sesgo del autor en la definición de las pruebas eficaces
d. Los testers son mejores para encontrar defectos que los desarrolladores
4. ¿Cuál no es un principio de pruebas?
a. Pruebas tempranas
b. Agrupamiento de defectos
c. Paradoja del pesticida
d. Las pruebas exhaustivas
5. Un defecto es:
a. Encontrado en el software; el resultado de un error

b. Un desperfecto en un componente o sistema que puede ser la causa por la cual el sistema o componente no logre
llevar a cabo su función especificada
c. Un paso incorrecto en un proceso o definición de datos en un programa informático
d. Una acción humana que produce un resultado incorrecto
6. Cómo se define lo siguiente: Test strategy (estrategia de pruebas):
a. Descripción sucinta de los niveles de pruebas a realizar y las pruebas asociadas a una organización o programa (uno o
más proyectos)
b. Inconformidad con el enfoque local, los esfuerzos requeridos para las pruebas se distribuyen entre los diferentes obje-
tos de prueba y objetivos de las pruebas
d. Una acción correctiva
7. Cómo se define lo siguiente: Test case (caso de prueba):
a. Debe incluir precondiciones, conjunto de valores de entrada, conjunto de resultados esperados, forma en la cual se
debe ejecutar el caso de prueba, verificación de resultados y postcondiciones
b. Programa de computadora escrito en un lenguaje de programación que puede ser leído por una persona
c. Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como referencia para el
desarrollo de casos de prueba
d. Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un computador (ordena-
dor)
8. Cómo se define lo siguiente: Test base o test basis (fundamentos de pruebas):
a. Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como referencia para el
desarrollo de casos de prueba
b. Programa de computadora escrito en un lenguaje de programación que puede ser leído por una persona
c. Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un computador (ordena-
CALIDAD DE SOFTWARE
dor)
d. La definición de un caso de prueba debe incluir precondiciones, conjunto de valores de entrada, conjunto de resultados
esperados, forma en la cual se debe ejecutar el caso de prueba, verificación de resultados y postcondiciones
9. Cómo se define lo siguiente: Software development (desarrollo de software):
a. Es un proceso / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un computador (ordenador)
b. La definición de un caso de prueba debe incluir precondiciones, conjunto de valores de entrada, conjunto de resultados
esperados, forma en la cual se debe ejecutar el caso de prueba, verificación de resultados y postcondiciones
c. Conjunto de documentos que definen los requisitos de un componente o sistema utilizado como referencia para el de-
sarrollo de casos de prueba
10. ¿Cuál es la principal ventaja del diseño de pruebas tempranas en el ciclo de vida?
a. Es más barato que el diseño de pruebas durante las fases de prueba

b. Ayuda a prevenir los defectos que se introduzcan en el código
c. Las pruebas diseñadas al principio son más eficaces que pruebas diseñadas después
d. Se ahorra tiempo en las fases de prueba cuando los probadores están ocupados
Anexo
Respuestas a la autoevaluación de la Unidad IV
Preguntas Respuesta
1 A
2 B
3 D
4 D
5 B
6 C
7 A
8 A
9 A
10 B
E ste manual autoformativo es el material didáctico más importante de la
presente asignatura. Elaborado por el docente, orienta y facilita el auto
aprendizaje de los contenidos y el desarrollo de las actividades propuestas en el
sílabo.
Los demás recursos educativos del aula virtual complementan y se derivan del
manual. Los contenidos multimedia ofrecidos utilizando videos, presentaciones,
audios, clases interactivas, se corresponden a los contenidos del presente
manual. La educación a distancia en entornos virtuales te permite estudiar desde
el lugar donde te encuentres y a la hora que más te convenga. Basta conectarse al
Internet, ingresar al campus virtual donde encontrarás todos tus servicios: aulas,
videoclases, presentaciones animadas, biblioteca de recursos, muro y las tareas,
siempre acompañado de tus docentes y amigos.
El modelo educativo de la Universidad Continental a distancia es innovador,

interactivo e integral, conjugando el conocimiento, la investigación y la innovación.
Su estructura, organización y funcionamiento están de acuerdo a los estándares
internacionales. Es innovador, porque desarrolla las mejores prácticas del e-learning
universitario global; interactivo, porque proporciona recursos para la comunicación
y colaboración síncrona y asíncrona con docentes y estudiantes; e integral, pues
articula contenidos, medios y recursos para el aprendizaje permanente y en
espacios flexibles. Ahora podrás estar en la universidad en tiempo real sin ir a la
universidad.

A0043 MAI Calidad de Software ED1 V1 2017

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

A0043 MAI Calidad de Software ED1 V1 2017

Cargado por

Copyright:

Formatos disponibles

Comercio Exterior y Aduanas

Dirección: Emma Barrios Ipenza

UNIDAD I: “Introducción a la Calidad de Software” 11

TEMA N° 1: ¿Qué es la gestión de Calidad según PMI? 12

TEMA N° 2: Modelo y Norma de Procesos 15

TEMA N° 3: Fundamentos de calidad 17

UNIDAD II: Planificación de la calidad 29

TEMA N° 1: GESTIÓN DE LA CALIDAD DEL SOFTWARE – NTP/ISO/IEC 12119 30

TEMA N° 2: Procesos de calidad 32

TEMA N° 3: Indicadores de gestión 34

TEMA N° 4: Gestión de riesgos 36

TEMA N° 1: Revisiones o inspecciones estáticas relacionadas al ISQTB 46

Glosario de la unidad III 53

Bibliografía de la unidad III 54

Autoevaluación de la unidad III 55

UNIDAD IV: Control de calidad 57

TEMA N° 2: Tipos de pruebas 62

C urso de especialidad de calidad en la carrera

En general, los contenidos propuestos en el manual

Es recomendable que desarrolles una permanente

Resultado de aprendizaje Resultado de aprendizaje Resultado de aprendizaje Resultado de aprendizaje

TIEMPO MINIMO DE ESTUDIO:

UNIDAD I: Introducción a la calidad de software

DIAGRAMA DE PRESENTACIÓN DE LA UNIDAD I

CONTENIDOS EJEMPLOS ACTIVIDADES

ORGANIZACIÓN DE LOS APRENDIZAJES

Resultado de aprendizaje de la Unidad I:

CONOCIMIENTOS HABILIDADES ACTITUDES

Tema N.º 3: Fundamentos de calidad Tarea Académica N° 1

Tema N.º 4: Fundamentos de Control de Calidad

Lectura seleccionada N.° 2: NTP/ISO/IEEE 15504,

TEMA N° 1: ¿Qué es la gestión de Calidad según PMI?

Figura 1: Si los programadores construyeran aviones

1.2. Definición de calidad

2 DEFINICIÓN DE SERVICIOS DE CALIDAD

2.1. Componentes de servicios de calidad

2.2. Objetivos de servicios de calidad

3 Calidad del producto vs. calidad del servicio

4 PLANTEAMIENTO, ASEGURAMIENTOY CONTROL DE CALIDAD

Control de calidad Aseguramiento de calidad

Procesos • Es era que la producción pare • La compañia espr para la produc-

Figura 3: Control de Calidad VS Aseguramiento de la Calidad

5 Modelos y normas de Calidad

TEMA N° 2: Modelo y Norma de Procesos

1 nTP/ISO 9001: MEJORA DE PROCESOS

1.1. Definición de procesos

Figura 3. Diagrama de Procesos

1.2. Mejora de procesos

2 DESARROLLO DEL SISTEMA DE GESTIÓN DE LA CALIDAD

Dicha gestión se puede representar en el siguiente diagrama:

Figura 4: Diagrama de Procesos

3 MODELO DE CAPACIDAD DE MADUREZ DEL SOFTWARE CMMI : MEJORA CONTINUA. NIVELES DE

TEMA N° 3: Fundamentos de calidad

1 NTP/ISO/IEC 15504: CALIDAD DE SOFTWARE

Parte 4 Parte 5 Parte 6

Figura 5: Estructura de la ISO 15504

• er aplicable a cualquier organización o empresa.

2 PROCESOS DE SOFTWARE Y EVALUACIÓN DE PROCESOS DE SOFTWARE

Análisis Diseño Ejecución

• Calidad a Nivel de Proceso

• Calidad a Nivel de Producto

Figura 6: Calidad Procesos VS Calidad Producto

5.1. Procesos de Apoyo

5.2. Procesos principales