1

Análisis y definición de estrategia para la implementación de un plan de

pruebas que satisfaga los estándares de calidad

Manuel Eduardo Castro Santana

David Ricardo Quiñones
Reynaldo Vargas Gaitán
Mateo Àlvarez García
Adriana Leidy Martínez Beltrán

Septiembre 2019.

POLITÉCNICO GRANCOLOMBIANO
 2

Abstract

The current document considers the analysis phase develop and the definition of a
strategy that allow to implement a test process to each software solution, to satisfy all the
current quality standards and also get a better method to grow up and improve all the
software process to the MASTER LTDA. company.

Resumen

El presente documento contempla el desarrollo de la fase de análisis y definición

de una estrategia que permita la implementación de un plan de pruebas de software, que
satisfaga los estándares de calidad actuales y a su vez faciliten el crecimiento y pronta
mejora en los procesos de software para la compañía MASTER LTDA..

POLITÉCNICO GRANCOLOMBIANO
 3

Tabla de Contenidos

PRIMERA ENTREGA .................................................................................................... 4

Capítulo 1 Introducción ................................................................................................... 4
Objetivos Propuestos ................................................................................................... 4
Acercamiento conceptual ............................................................................................. 5
Capítulo 2 Situación actual de la empresa´ ...................................................................... 8
Análisis DOFA ............................................................................................................ 9
Capítulo 3 Nivel de madurez ........................................................................................ 10
Estado de avance actual ............................................................................................. 10
Definición de modelos ............................................................................................... 10
SEGUNDA ENTREGA ................................................................................................ 11
Capítulo 4 Actividades procesos y procedimientos ....................................................... 11
Capítulo 5 Parámetros de los productos entregables durante las fases de desarrollo de
software ........................................................................................................................ 12
Capítulo 6 Puntos de revisión (hitos) ............................................................................ 17
Lista de referencias ........................................................................................................ 19

POLITÉCNICO GRANCOLOMBIANO
 4

PRIMERA ENTREGA
Capítulo 1
Introducción

Con el presente análisis se pretende determinar el grado de madurez organizacional

en procesos de software llevados a cabo por la empresa Máster LTDA a fin de evaluar la
situación actual y generar recomendaciones de mejora conforme a los resultados. Esto se
desarrolla a través de cuatro capítulos, siendo el primero en el que se describe el problema
actual de la empresa, los objetivos propuestos para dar respuesta a estos y un acercamiento
conceptual acerca de los diversos Modelos de Calidad aplicados a la evaluación de la
madurez de proyectos y desarrollo de productos de software, sobre el que se soportará la
metodología usada. En el segundo capítulo se realiza una descripción de la situación actual
de la empresa, soportado por técnicas como la entrevista y análisis DOFA, seguido por el
tercer capítulo donde se establecen los criterios que permiten validar el estado de avance
de la compañía en función de los modelos definidos en el primer capítulo. Finalmente, se
establece la lista de actividades, procesos y procedimientos a lo largo del ciclo de vida del
desarrollo de productos de software que requieren de definición en la empresa para permitir
la implantación de un proceso de pruebas que aumente la calidad y permita que un plan de
pruebas fluya.

Objetivos Propuestos

1. Describir los elementos de los diversos modelos de calidad de software

2. Determinar las debilidades, fortalezas oportunidades y amenazas de Master
LTDA
3. Identificar el nivel de madurez de los procesos de software de la empresa objeto

POLITÉCNICO GRANCOLOMBIANO
 5

4. Establecer procesos y actividades a lo largo del ciclo de vida del desarrollo del
software

Acercamiento conceptual

Los modelos de calidad de software generalmente están estructurados como se

muestra en la Figura 1 (Scalone, 2006), donde pueden existir diversos factores de calidad
que a su vez están compuestos de criterios que son evaluados por métricas, con el propósito
de abordar la evaluación desde lo general a lo particular, y permitir reducir subjetividad en
la asignación de un valor, ya sea cuantitativo o cualitativo. Así mismo, los modelos de
calidad de software se clasifican de acuerdo con el enfoque de evaluación, ya sea a nivel
de proceso o producto.

Figura 1. Estructura de la calidad de Software

Para el presente análisis se definen los siguientes modelos de acuerdo con su clasificación:

A nivel de proceso:

CMMI: Es un modelo de madurez, práctico y de disciplinas basadas en estándares de la

industria, es una guía para comprobar procesos y comparar la capacidad de un grupo al
ejecutarlos. Este modelo se representa de dos maneras: escalonada y continua, donde el
modelo escalonado está dirigido al software y por su parte el modelo continuo se enfoca al
análisis de la capacidad de cada proceso inmerso en las áreas de la ingeniería de sistemas.

POLITÉCNICO GRANCOLOMBIANO
 6

DROMEY: Se refleja como una definición de métricas estadísticas asociadas al desarrollo

del software y la mejora continua de éste, por lo cual en este caso de estudio se procedió a
la selección del conjunto de atributos a evaluar en la aplicación, realizando después una
lista de chequeo de los componentes y módulos del sistema, para llegar a identificar cada
una de las propiedades de calidad que contienen estos módulos y cómo estas afectan cada
atributo de calidad como lo son los atributos de proceso, de producto y de recurso de
acuerdo a estas métricas se tiene una orientación a la calidad de software .

A nivel de producto:

McCall: Uno de los modelos pioneros en la evaluación de la calidad de software, tiene tres
etapas definidas: factores, criterios y métricas.
Este modelo busca acercar a los desarrolladores con el usuario enfocándose en factores de
calidad como la operación, la revisión y transición del producto.

FURPS: El modelo FURPS ha sido utilizado para el diseño y validación de interfaces para
usuarios finales, evaluando su funcionalidad, usabilidad, confiabilidad, desempeño y
soporte, para tener como salida final un producto que cumpla las reglas del negocio , es así
que se ha utilizado como un clasificador de requisitos, ayudando a la asignación correcta
de requisitos, implementación, y diseño de interfaces; aunque se ha identificado que
implica un amplio número de métricas para su desarrollo, concluyendo de esta manera que
se debe estimar el tiempo necesario para su implementación.

BOEHM: El modelo de Boehm agrega algunas características a las existentes en el modelo

McCall y representa una estructura jerárquica de características, cada una de las cuales
contribuye a la calidad total consiste en un modelo de descomposición de características
de calidad del software en tres niveles: usos principales, componentes intermedios y
componentes primitivos.

GILB: Plantea la creación de una especificación de requisitos de calidad para cada

proyecto que deben escribir conjuntamente el usuario y el analista. Es un modelo que
permite determinar una lista de características que definen la calidad de la aplicación.

En la Tabla 1 se expone una comparativa de las características de calidad y las ventajas y

desventajas de cada modelo en términos de tiempo, costo y beneficios.

POLITÉCNICO GRANCOLOMBIANO
 7

Modelos de
Características de
calidad del Ventajas Desventajas
calidad
software
 Facilidad de uso.
 Falta una asociación
 Integridad.
explicita entre el
 Corrección
 Relación directa modelo y el proceso
 Confiabilidad
entre los  Las características son
 Eficiencia
desarrolladores y el propiedades abstractas
 Facilidad de
usuario. medibles mediante
mantenimiento.
 Evalúa el a nivel bajo. métricas.
 Facilidad de prueba.
 Utiliza niveles  Las características y las
McCall  Flexibilidad
jerárquicos. subcaracterísticas son
 Portabilidad
difíciles que sean
 Reutilización.
independientes
 Evalúa el software sin
tomar en cuenta las
 Funcionalidad. restricciones físicas.
 Se requieren muchas
 Facilidad de uso.  Criterios claros para
métricas lo que implica
 Confiabilidad. su fácil utilización.
mayor esfuerzo en
 Performance.  Tiene en cuenta las
tiempo y costos
FURPS  Facilidad de soporte fallas del producto y
el del proceso para
su mayor corrección.
 Utiliza niveles
jerárquicos.
 Confiabilidad.  No especifica los
 Involucra menos
 Eficiencia. aspectos relacionados
factores y criterios lo
 Facilidad de prueba. con el usuario
que implica menos
 Portabilidad  Genera mucho tiempo
tiempo en su
 Fácil de entender en el desarrollo del
BOEHM  Fácil de modificar
desarrollo
sistema
 Incorpora objetivos
de calidad.
 Evalúa un producto
 Facilidad de uso. de manera
 Confiabilidad. independiente.
 Se basa solo en la
 Eficiencia.  Hay una relación
calidad del producto
 Facilidad de directa entre
mas no en el desarrollo
mantenimiento. atributos y los sub-
y análisis del mismo.
DROMEY  Portabilidad atributos
 Funcionalidad  Utiliza niveles
jerárquicos
 Corrección.
 Existe una relación  Se evalúan muchos
 Facilidad de
directa entre los factores que provocan
mantenimiento
desarrolladores y el un mayor trabajo en
 Integridad
usuario. tiempos y costos.
 Facilidad de uso
7

POLITÉCNICO GRANCOLOMBIANO
 8

GILB  Hay una relación

 Utiliza niveles
jerárquicos.
 Clasifica las empresas
en niveles según su
madurez.
 Permite guiar paso a
paso para mejorar a
través de niveles o
etapas.
 Específico para el
CMMI desarrollo y
mantenimiento de
software.
 Definido como un
conjunto de áreas
clave de procesos.
 Tiene un modelo de
evaluación
Tabla 1. Comparativa de modelos de calidad de software
directa entre
atributos y los sub-
atributos
 Es posible especificar
los atributos de la
calidad de software
en forma cuantitativa
 Reducción del coste
de desarrollo.
 Localización y
resolución de
defectos.
 Mejora en la
fiabilidad de la
planificación en
términos de
 Falta de adecuación al
dedicación y de
enfoque de servicio
calendario.
que está
 Aumento de la
experimentando el
productividad
sector de la TI en todas
 Reducción de
sus líneas de actividad.
trabajos de
 Exige un alto esfuerzo
correcciones tras las
de implantación.
fases de prueba.
 Mejora en la calidad
del producto.
 Reducción de
defectos.
 Detección en las
fases tempranas de
su ciclo de vida
 Mejora la imagen de
la marca

Capítulo 2
Situación actual de la empresa´

Para identificar la situación actual de Master Ltda. en cuanto a la implementación

de modelos de calidad de software, se realizaron entrevistas (ver apéndice) con personas
de diversas áreas y diversos perfiles, para poder tener perspectivas diferentes.
A partir de estas entrevistas se pudo extraer la siguiente matriz DOFA (Figura 2), donde
se evidencia el estado actual de la compañía.
8

POLITÉCNICO GRANCOLOMBIANO
 9

Análisis DOFA

DEBILIDADES (-) AMENAZAS (-)

Desconocimiento de los modelos de calidad
No aplican ningun estándar o modelo
1 1 de software que se podrian aplicar dentro
de calidad de software
de la entidad.
Algunas personas desconocen el
Desconocimiento de los sistemas de
2 proceso para la solicitud y gestion de 2
pruebas unitarias existentes
una solucion tecnologica
Se presentan frecuentemente
3 incumplimiento en los objetivos
establecidos en los proyectos.

FORTALEZAS (+) OPORTUNIDADES (+)

Cuentan con una estructura y personal
con la disposición y los conocimientos Implementación un modelo de calidad de
1 1
fundamentales para establecer un software
modelo de calidad de software
Aunque no tienen un modelo de
gestión de calidad de software si
Alta disponibilidad por cada uno de los
tienen establecido un proceso para la
2 2 agentes involucrados para aprender e
ejecución de una solución informática
implementar nuevas tecnologias y standars
y manejan una metodologia ágil
SCRUM
Cuentan con documentos claros y
estructurados que facilitan la
3
ejecucion de el desarrollo de la
solucion de software
Cuentan con ambientes de desarrollo
4
y producción separados
Cuentan con un comité de cambios
que valida y aprueba los cambios a
5
realizar evitando afectaciones en las
operaciones vitales para la compañía
Figura 2 Análisis DOFA

POLITÉCNICO GRANCOLOMBIANO
 10

Capítulo 3
Nivel de madurez

El problema fundamental en las organizaciones es la inhabilidad para la

administración de sus procesos. El modelo CMM se convierte en una guía que permite el
control de los procesos y el desarrollo y mantenimiento de un mejor software, a través de
prácticas de planeación, ingeniería y administración.
La madurez de un proceso de software consiste en el punto en el que determinado proceso
es explícitamente definido, administrado, medido, controlado y efectivo, la madurez
implica a su vez que la capacidad del proceso de software va en crecimiento y debe ser
definido, documentado, entrenado, practicado, soportado, mantenido, controlado,
verificado, validado, medido y capaz de mejorar en el tiempo.

Estado de avance actual

A partir de los hallazgos evidenciados a través de la técnica de entrevista y análisis

DOFA del capítulo 2 y a partir de los criterios definidos en el modelo CMM para evaluar
el nivel de madurez, se evidencia que actualmente la empresa se encuentra en un nivel de
madurez 1 inicial donde no existe un ambiente estable en cual se pueda desarrollar o
mantener un software, puesto que las metas de tiempo, costo y recurso no son alcanzadas.

Definición de modelos

A partir de esta premisa en concordancia con el comparativo de los modelos (Tabla

1) se propone que los modelos de calidad adecuados para lograr la calidad esperada son:
El modelo CMM enfocado al proceso y el modelo BOHEM con enfoque al producto.

10

POLITÉCNICO GRANCOLOMBIANO
 11

SEGUNDA ENTREGA
Capítulo 4
Actividades procesos y procedimientos

Finalmente se establece la lista de procesos, procedimientos y actividades a lo largo

del ciclo de vida del desarrollo del software que requieren de definición en la empresa para
permitir la implantación de un proceso de pruebas que aumente la calidad y permita la
fluidez de un plan de pruebas.

Procesos Actividades

 Definición del Sistema

Análisis del Sistema
 Establecimiento de Requisitos
 Análisis de los Casos de Uso
 Elaboración del Modelo de Procesos
 Análisis de Consistencia y Especificación de Requisitos
 Especificación del Plan de Pruebas
 Aprobación del Análisis del Sistema de Información

 Diseño de Casos de Uso Reales

 Diseño de la Arquitectura de Módulos del Sistema
 Verificación y Aceptación de la Arquitectura del Sistema
Diseño del Sistema
 Especificación Técnica del Plan de Pruebas
 Aprobación del Diseño del Sistema de Información

 Preparación del Entorno de Generación y Construcción

Construcción del Sistema
 Generación del Código de los Componentes y Procedimientos
 Ejecución de las Pruebas Unitarias
 Ejecución de las Pruebas de Integración
 Ejecución de las Pruebas del Sistema
 Elaboración de los Manuales de Usuario
 Definición de la Formación de Usuarios Finales
 Aprobación del Sistema de Información

11

POLITÉCNICO GRANCOLOMBIANO
 12

 Establecimiento del Plan de Implantación

 Formación Necesaria para la Implantación
 Incorporación del Sistema al Entorno de Operación
Implantación y Aceptación del  Pruebas de Implantación del Sistema
 Pruebas de Aceptación del Sistema
Sistema  Preparación del Mantenimiento del Sistema
 Establecimiento del Acuerdo de Nivel de Servicio
 Presentación y Aprobación del Sistema
 Paso a Producción

 Registro de la Petición
 Análisis de la Petición
Mantenimiento del Sistema
Preparación de la Implementación de la Modificación
 Seguimiento y Evaluación de los Cambios hasta la Aceptación

Tabla 1 Procesos y actividades

Capítulo 5
Parámetros de los productos entregables durante las fases de desarrollo
de software

En las siguientes tablas se definen las directrices para cada uno de los productos, a fin de
crear un estándar que permita su replicación en cada nuevo desarrollo. Donde se describen
los responsables, participantes y requerimientos mínimos que deberán ser validados en
cada fase.

Producto Planificación
Objetivo Cuantificable  La Planificación del proyecto debe respetar los
plazos establecidos.
 Se requiere la participación del cliente.

Atributos de Calidad Claridad, Mantenimiento, Flexibilidad, Confiabilidad,

Corrección, Facilidad de uso, Eficiencia, Integridad.
Encargado (s) revisión final Gerente de Proyecto, Jefe de Proyecto, Cliente
Tabla 2: Planificación

12

POLITÉCNICO GRANCOLOMBIANO
 13

Producto Especificación de Requerimientos (Definición)

Objetivo Cuantificable  Se requiere la participación del cliente.
 No se debe consumir más de un 20% del tiempo total
del proyecto.
 Deben estar identificados los problemas o necesidades
de Negocios en un 90%.
 Las metas de la organización, sus objetivos y factores
críticos de éxito deben ser analizados en un 100%.
 Los Procesos de Negocios y flujos de información
actuales deben ser analizados en un 100%.
 Los Requerimientos de la Solución, en términos de
Procesos y principios de negocios, estructura
organizacional y arquitectura tecnológica, deben ser
analizados en un 100%
 Los beneficios de la Solución e impacto en la
organización, recursos humanos y ambiente tecnológico
deben ser analizados en un 100%.

Nota: En esta etapa no se debe pensar en posibles soluciones,

sino solamente en el problema, es decir, se debe describir el
problema en forma de Requerimientos
Atributos de Calidad Claridad, Mantenimiento, Flexibilidad, Corrección,
Confiabilidad, Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final Cliente, Jefe de Proyectos

Tabla 3: Especificación de Requerimientos

Producto Análisis
Objetivo Cuantificable  Se requiere la participación del cliente.
 Se requiere la participación del Analista de
Negocios
 No se debe consumir más de un 30% del tiempo
total del proyecto.
 Se deben identificar las soluciones que satisfagan
la Especificación de Requerimientos, en un 100%,
y seleccionar solo una.
 Se debe documentar la Solución Propuesta en un
100%.
 Se debe preparar el Plan inicial del Proyecto en un
70% del total y de QA en un 80%, basado en la
Solución Propuesta.

13

POLITÉCNICO GRANCOLOMBIANO
 14

Atributos de Calidad Completitud, Claridad, Mantenimiento, Flexibilidad,

Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia
Encargado (s) revisión final Cliente, Jefe de Proyectos
Tabla 4: Análisis

Producto Diseño
Objetivo Cuantificable  No se debe consumir más de un 60% del tiempo
total del Proyecto.
 Se requiere de la participación del Arquitecto de
Sistema.
 Se requiere la participación del Diseñador.
 Se requiere de la participación del Jefe de
Proyectos.
 Se requiere participación del Analista de Negocios
 Se debe definir la Funcionalidad y Solución Física
que va a satisfacer los Requerimientos en un 90%.
 Se debe planificar cómo se va a implementar y
aceptar la Solución Propuesta en un 90%.

Atributos de Calidad Claridad, Completitud, Mantenimiento, Flexibilidad,

Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia
Encargado (s) revisión final Arquitecto de Sistema, Jefe de Proyectos, Cliente
Tabla 5: Diseño

Producto Implementación
Objetivo Cuantificable  No se debe consumir más de un 60% del total del
Proyecto.
 Las Pruebas no deben superar más del 30% del
total del Proyecto.
 Los componentes de la Solución deben ser
construidos en un 100%.
 Las Pruebas deben cubrir el 100% de los
Componentes construidos.

Atributos de Calidad Corrección, Claridad, Mantenimiento, Integridad,

Completitud, Facilidad de uso, Integridad, Eficiencia
Encargado (s) revisión final Jefe de Proyecto, Cliente, Arquitecto de Sistema
Tabla 6: Implementación

Producto Instalación (Aceptación y Entrega)

Objetivo Cuantificable  Se requiere la participación del cliente.

14

POLITÉCNICO GRANCOLOMBIANO
 15

 La Solución se prueba 100% en un ambiente

operacional hasta que esté lista para la prueba de
aceptación formal por parte del cliente.
 El cliente debe estar de acuerdo en que la Solución
cumple la Especificación Funcional, que la Solución ha
sido distribuida y que la Organización acepta la
propiedad de la Solución, en un 100%.
 Se debe registrar, revisar y corregir la Solución para los
defectos identificados en un 100%.
 Se debe involucrar al personal de Soporte para facilitar
el traspaso exitoso, en un 80%.

Atributos de Calidad Mantenimiento, Corrección, Claridad, Confiabilidad,

Integridad, Completitud, Facilidad de uso, Eficiencia
Encargado (s) revisión final Cliente

Tabla 7: Instalación (Aceptación y Entrega)

Producto Operación (Mantenimiento)

Objetivo Cuantificable  Se requiere la participación del cliente.
 Se debe hacer una revisión para registrar datos
estadísticos y discutir sobre áreas de experiencia
que puedan ser útiles para otros proyectos en el
futuro, en un 80%.
 Se debe archivar el contenido del Proyecto y
considerar el proyecto como terminado, en un
100%.
 Se debe proveer soporte para la Mantención de la
Solución en un 100%.

Atributos de Calidad Corrección, Flexibilidad, Facilidad de uso,

Corrección, Confiabilidad, Claridad
Encargado (s) revisión final Cliente
Tabla 8: Operación (Mantenimiento)

Producto Plan de Pruebas

Objetivo Cuantificable  Se requiere participación del cliente.
 Se requiere participación del Jefe de Proyectos.
 Se requiere participación del Arquitecto de
Sistemas.
 Se requiere participación del Analista de
Negocios.
 El plan de pruebas debe abarcar todos los módulos
de la aplicación.

15

POLITÉCNICO GRANCOLOMBIANO
 16

 Las Pruebas deben cubrir el 100% de la

Aplicación.
 Las Pruebas deben abordar en un 100% los tipos
de prueba: unitaria, integración, y usuario.
 Las Pruebas deben abordar en un 100% los
enfoques: Funcional, Seguridad, Calidad,
Rendimiento, Aceptación, e Instalación.

Atributos de Calidad Claridad, Completitud, Mantenimiento, Flexibilidad,

Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia
Encargado (s) revisión final Cliente, Jefe de Proyectos, Analista de Negocios

Tabla 9: Plan de Pruebas

Producto Manual de Usuario

Objetivo Cuantificable El manual no debe manejar un lenguaje técnico, debe
ser entendido en un 95% por los usuarios finales
No debe superar las 50 hojas
Atributos de Calidad Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia
Encargado (s) revisión final Desarrollador, Jefe de Proyectos

Tabla 10: Manual de Usuario

Producto Manual de Instalación del Sistema

Objetivo Cuantificable El manual no debe superar las 50 hojas
Atributos de Calidad Completitud, Mantenimiento, Claridad, Flexibilidad,
Corrección, Confiabilidad, Facilidad de uso,
Integridad, Eficiencia
Encargado (s) revisión final Desarrollador, Jefe de Proyectos

Tabla 11: Manual de Instalación del Sistema

16

POLITÉCNICO GRANCOLOMBIANO
 17

Capítulo 6
Puntos de revisión (hitos)

Se identifican como puntos de revisión aquellos que permiten validar y controlar las tareas
realizadas dentro de cada etapa del ciclo de desarrollo y por cada cambio producido en
mantención. Debe ser utilizado por la unidad de SQA durante la planificación para verificar
el correcto establecimiento de los hitos de calidad.

 Planificación

 Revisión y aprobación del plan de SQA.

 Revisión y aprobación del plan de proyecto.
 Revisión y aprobación del plan de riesgos.
 Reporte del estado y los resultados de las actividades de SQA.

 Especificación de requerimientos (Definición)

 Revisión y aprobación de la especificación de requerimientos.

 Reporte del estado y los resultados de las actividades de SQA.

 Análisis

 Revisión y Aprobación de la Especificación del Sistema (Solución Propuesta).

 Reporte del estado y los resultados de las actividades de SQA.

 Diseño

 Revisión y aprobación de la Especificación de Diseño de Sistema.

 Revisión y aprobación de la Especificación Funcional del Sistema.
 Revisión y aprobación de la Especificación de Diseño de Soporte del
Sistema.
 Revisión y aprobación del Plan de Pruebas del sistema
17

POLITÉCNICO GRANCOLOMBIANO
 18

 Reporte del estado y los resultados de las actividades de SQA.

 Implementación

 Revisión y aprobación de los casos de prueba.

 Revisión y aprobación de la especificación de los procedimientos de prueba.
 Revisión y aprobación del código y su documentación.
 Revisión y aprobación de los resultados de la prueba de unidad, integración, y
sistema
 Reporte del estado y los resultados de las actividades de SQA.
 Reporte del estado y los resultados de las actividades de SQA.
 Revisión y aprobación del Manual de Usuario.
 Revisión y Aprobación del Manual de Instalación del Sistema

 Instalación (Aceptación y entrega)

 Revisión y aprobación el software y su documentación.

 Reporte del estado y los resultados de las actividades de SQA.

 Operación (Mantención)

 Revisión y aprobación de cada cambio producido durante la mantención en su

especificación, diseño, implementación y prueba.
 Revisión y aprobación de la documentación asociada a los cambios.
 Revisión y aprobación de la nueva versión del software y de su documentación.
 Reporte del estado y los resultados de las actividades de SQA.

18

POLITÉCNICO GRANCOLOMBIANO
 19

Lista de referencias

Cuervo Callejas Mauro (2009-2019). Procesos principales de métrica. España.

https://manuel.cillero.es/doc/metrica-3/procesos-principales/

Cillero Manuel (2017-2019). Modelos de calidad del software , un estado del arte.
Colombia. http://www.scielo.org.co/pdf/entra/v13n1/1900-3803-entra-13-01-00236.pdf

PRESSMAN, Roger S. “Ingeniería del Software” – Un Enfoque Práctico. Sexta Edición.

México – Editorial McGraw-Hill Interamericana, 2007. P. 395

SOMMERVILLE, Ian. “Ingeniería de Software” – Novena Edición. México: Editorial

Pearson, 2011. P. 42, 50, 51, 78,223

19

POLITÉCNICO GRANCOLOMBIANO