DOCUMENTACIN DE METODOLOGA DE SOFTWARE Y PLAN SQA

ELABORADOR POR:
OMER YESID BOTERO
MIGUEL NGEL RODAS
MAURICIO SERNA FLREZ
JESS EMILIO VALDERRAMA

PFORESOR:
JUAN FERNANDO VILLEGAS

POLITCNICO COLOMBIANO JAIME ISAZA CADAVID

FACULTAD DE INGENIERAS
PROGRAMAS INFORMTICOS
GESTIN DE LA CALIDAD EN EL DESARROLLO DE SOFTWARE
MEDELLN
OCTUBRE DE 2016

CONTENIDO
INTRODUCCIN ........................................................................................................................ 3
OBJETIVOS .................................................................................................................................. 4
DOCUMENTACIN Y CARACTERIZACIN DE LOS PROCESOS ................................ 5
ANLISIS ................................................................................................................................... 5
DISEO .................................................................................................................................... 13
CODIFICACIN ...................................................................................................................... 23
PRUEBAS ................................................................................................................................. 26
PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE .............................. 30
1. PROPSITO ........................................................................................................................... 31
2. GESTIN ................................................................................................................................ 31
2.1. Actividades ......................................................................................................................... 32
2.3 Responsables ....................................................................................................................... 35
4. DOCUMENTACIN ............................................................................................................. 36
4.1 Propsito.............................................................................................................................. 36
4.2 Referencias .......................................................................................................................... 36
4.3 Documentacin.................................................................................................................... 36
4.4 Entregables .......................................................................................................................... 36
5. ESTNDARES, PRCTICAS, CONVENCIONES Y MTRICAS ................................. 40
MODELO PARA LA EVALUACIN DE CALIDAD BASADO EN ISO 25000 ................ 50
1. Establecer los requisitos de la evaluacin ............................................................................. 51
2. Especificacin de la evaluacin ............................................................................................ 53
3. Diseo de la evaluacin......................................................................................................... 55
4. Ejecucin de la evaluacin .................................................................................................... 56
5. Conclusin de la evaluacin.................................................................................................. 57
CONCLUSIONES....................................................................................................................... 59
REFRENCIAS............................................................................................................................. 60

Pgina 2 de 60

INTRODUCCIN
En el presenta trabajo se realizar la caracterizacin y documentacin de todos los procesos que
intervienen en una metodologa basada en el ciclo de vida en cascada, se incluir un plan de
aseguramiento de calidad para una empresa dedicada al desarrollo de software, aplicando la
norma IEEE 730.

Pgina 3 de 60

OBJETIVOS
Mostrar el enfoque conceptual y caracterizacin de los distintos procesos de una
metodologa tradicional basada en clico de vida en cascada, incluyendo la documentacin
de un plan de aseguramiento de calidad para la organizacin que implemente dicha
metodologa.
Caracterizar las tareas y fases principales que se van a desarrollar en la metodologa
seleccionada.
Documentar cada uno de los procesos anteriormente caracterizados que hacen parte de la
metodologa en cascada para una mejor comprensin en su funcionamiento.
Construir todo el plan de aseguramiento de calidad basados en un estndar definido como
la IEEE 730 para la identificacin de todos los principios claves de calidad en la
organizacin, teniendo en cuenta los recursos apropiados para la ejecucin de cada uno
de sus procesos.

Pgina 4 de 60

DOCUMENTACIN Y CARACTERIZACIN DE LOS PROCESOS

ANLISIS
Caracterizacin macro proceso anlisis

Pgina 5 de 60

Documentacin del macro proceso anlisis:

Logo

Macro proceso: Anlisis

Anlisis

Fecha: 19/09/2016
Cdigo:
Versin: 1

Realizar un anlisis general del sistema, partiendo de la informacin suministrada por el cliente, para as proceder a
realizar el universo del discurso y posteriormente el levantamiento de requisitos.
El proceso inicia desde que el cliente solicita el desarrollo de un producto de software hasta que se levantan todos los
Alcance
requisitos del sistema.
Responsable Lder del proyecto y analista de requerimientos.
Intervinientes Cliente, lder del proyecto y analista de requerimientos.
Duracin del procedimiento.
Cantidad de reuniones realizadas entre el lder del proyecto y el cliente.
Indicadores
Cantidad de veces que se modificaron los requerimientos.
Solicitud de desarrollo del producto.
Entradas
Requerimientos del cliente (verbal o escrito).
Documento formalizado con requerimientos, contratos y tiempo estimado para la entrega del proyecto.
Salidas
Computadores.
Impresoras.
Recursos
Tiempo del lder del proyecto, analista de requerimientos y cliente.

Objetivo

Actividades
1. Solicitud de desarrollo del producto: El cliente solicita de manera formal la construccin de un producto.
2. Realizar universo del discurso: El lder del proyecto se rene con el cliente para realizar un documento con todas las
necesidades y alcance del sistema a realizar. Existe una retroalimentacin constante con el cliente, estableciendo reuniones
necesarias hasta que todo quede aclarado y formalizado.
3. Especificar requisitos: El analista de requerimientos, teniendo en cuenta el documento realizado por el lder del proyecto,
procede a realizar y formalizar todos los requerimientos del sistema.
4. Revisar requisitos: Estos requerimientos deben ser aprobados y formalizados por el lder del proyecto, de lo contrario se deben
realizar las correcciones pertinentes hasta que los requerimientos sean admitidos tanto por el cliente y el lder del proyecto.
5. Realizar revisin tcnica formal: El lder del proyecto elabora una revisin formal con el analista de requerimientos y el cliente,
donde queda acordado todos los requerimientos y el alcance del producto de software que se va a realizar.

Caracterizacin proceso universo del discurso:

Documentacin proceso universo del discurso:

Logo

Macro proceso: Anlisis

Realizacin universo del discurso

Fecha: 20/09/2016
Cdigo:
Versin: 1

Realizar los documentos con toda la informacin suministrada por el cliente para as entender y conocer el alcance del
producto que se va a realizar.
Este proceso inicia desde que se realiza una reunin con el cliente que solicita el desarrollo de un producto hasta que
Alcance
se formalizan y se aprueban los documentos.
Responsable Lder del proyecto.
Intervinientes Lder del proyecto y el cliente.
Cantidad de tcnicas utilizadas para elaborar el universo del discurso.
Grado de aceptacin del cliente cuando se formalizan los documentos.
Indicadores
Tiempo consumido para la elaboracin del documento.
Solicitud de desarrollo del producto.
Entradas
Requerimientos del cliente (expresados verbalmente o escrito).
Universo del discurso para ser presentado al analista de requisitos.
Salidas
Computadores.
Impresoras.
Recursos
Tiempo del lder del proyecto y cliente.

Objetivo

Actividades
1. Solicitud de desarrollo del producto: El cliente solicita de manera formal la construccin de un producto.
2. Realizar preguntas e inquietudes: El lder del proyecto realiza al cliente todas las dudas e inquietudes acerca de la solicitud que
est realizando el cliente.
3. Elaboracin del universo del discurso: Si todas estas preguntas son contestadas de manera clara por parte del cliente y no
existen dudas, el lder del proyecto tiene toda la informacin necesaria para proceder a realizar el universo del discurso.
Si existen dudas, se realiza toda la retrospectiva necesaria para proceder con la elaboracin del universo del discurso.
4. Presentar universo del discurso: Despus de elaborar el universo del discurso, se realiza una reunin con el cliente para
presentarle formalmente todo lo que se va a realizar y el alcance del sistema.
Si es aprobado por el cliente este documento se formaliza, sino se deben volver a realizar preguntas para proceder con la
elaboracin del nuevo documento.
5. Agrupar y formalizar documentos: Se realiza una agrupacin de todos los documentos, se le presenta al cliente un contrato con
lo acordado en el universo del discurso, valor del proyecto, duracin, etc.
Pgina 8 de 60

6. Publicacin universo del discurso: Se procede a publicar el universo del discurso para que todos los miembros del proyecto
conozcan lo que se va a realizar y as proceder con el levantamiento de requisitos.

Pgina 9 de 60

Caracterizacin proceso especificacin de requisitos:

Pgina 10 de 60

Documentacin proceso especificacin de requisitos:

Logo

Nombre macro proceso: Anlisis

Nombre proceso: Especificacin de requisitos

Fecha: 20/09/2016
Cdigo:
Versin:

Definir requisitos funcionales y no funcionales del producto de software que se va a realizar, realizar historias de
usuario con sus respectivas estimaciones.
El proceso empieza desde el universo del discurso hasta que se tiene un documento con todas las historias de usuario
Alcance
y la duracin promedio de entrega del proyecto.
Responsable Lder del proyecto y analista de requerimientos.
Intervinientes Lder del proyecto y analista de requerimientos.
Tiempo de realizacin del documento.
Cantidad de veces que modificaron los requerimientos.
Indicadores
Cantidad de tcnicas utilizadas para obtener el tiempo deseado en la estimacin para la fecha de entrega del
proyecto.
Universo del discurso.
Entradas
Documento con los requisitos funcionales y no funcionales del sistema.
Duracin promedio del tiempo de desarrollo del proyecto.
Salidas
Historias de usuario con su respectiva estimacin, actividades a realizar y criterios de aceptacin.
Computadores.
Impresoras.
Recursos
Tiempo del lder del proyecto y analista de requerimientos.

Objetivo

Actividades
1. Socializar el universo del discurso: El lder del proyecto se rene con el analista de requerimientos para socializar el nuevo
proyecto que va a comenzar.
2. Especificar requisitos: Teniendo en cuenta el universo del discurso, el analista de requerimientos procede a realizar la
especificacin general de los requisitos del producto de software a realizar.
3. Retroalimentacin de requisitos: El analista de requisitos se rene con el lder del proyecto para revisar, corregir y/o
profundizar en los requerimientos presentados.
Estos requerimientos deben ser revisados y aprobados por el lder del proyecto, para proceder a definir los requisitos funcionales
y no funcionales del sistema a realizar, de lo contrario el analista debe volver a especificar requisitos y planear unas reuniones con
el lder del proyecto hasta obtener su aprobacin.
Pgina 11 de 60

4. Definir requisitos funcionales y no funcionales: Se consideran requisitos funcionales aquellas funciones del sistema de software
o sus componentes. Una funcin se describe como conjunto de entradas, comportamientos y salidas. Los requisitos funcionales
pueden ser: clculos, detalles tcnicos, manipulacin de datos, etc.
Los requisitos no funcionales son aquellos que se utilizan para medir la operacin de un sistema, estos pueden ser: rendimiento,
disponibilidad, accesibilidad, disponibilidad, usabilidad, estabilidad, portabilidad, costo, operatividad, interoperabilidad,
concurrencia, mantebilidad, seguridad, interfaz, etc.
5. Definir historias de usuario: Una historia de usuario es un requisito o conjunto de requisitos funcionales del sistema. En ella se
definen todas las tareas que se deben llevar a cabo para desarrollar esta funcionalidad, se determinan los criterios de aceptacin,
responsable o responsables y se realiza una estimacin promedio en horas de lo puede durar uno o varios desarrolladores para
terminar dicha historia de usuario.
6. Estimar duracin promedio de cada historia de usuario: La tcnica de estimacin que se debe utilizar es a juicio de experto,
que consiste en permitir a cada miembro del equipo de trabajo que realice una estimacin de acuerdo a su experiencia, al final
estas estimaciones se promedian y ese resultado ser la duracin en horas para la historia de usuario.
7. Estimar duracin promedio de entrega del proyecto: Cuando se tienen todas las historias de usuario, se realiza una
ponderacin de la duracin de cada una de ellas, el resultado arrojado es la duracin promedio para entregar el proyecto.
8. Formalizar duracin promedio del proyecto: Es una reunin pactada entre el analista de requerimientos y el lder del proyecto,
consiste en presentar la duracin promedio que tardar terminar el proyecto, esta estimacin debe ser aprobada por el lder, de lo
contrario se debe volver a realizar.
9. Priorizar historias de usuario: Despus de ser aprobada la duracin del proyecto, se procede a priorizar cada historia de usuario,
esto se realiza por medio de una puntuacin, siendo 10 de mayor prioridad o riesgo para el negocio y 1 menor prioridad. Las
historias de usuario con mayor riesgo son las primeras en empezarse a desarrollar.
10. Realizar revisin tcnica formal: Se redacta un documento llamado Anlisis de requerimientos donde se consignan las
historias de usuario y duracin del proyecto. El lder del proyecto aprueba este documento y se da inicio al proceso de diseo.

Pgina 12 de 60

DISEO
Caracterizacin macro proceso diseo

Documentacin macro proceso diseo

Logo

Nombre macro proceso: Diseo

Nombre proceso: Diseo

Fecha: 27/09/2016
Cdigo:
Versin:1

Realizar el diseo de software compuesto por modelo de datos, diagrama de clases, diseo de interfaces, diseo
arquitectura; todos estos basados en el documento de levantamiento de requisitos.
Desde que se recibe el documento de ERS hasta que se entrega todo el diseo se software.
Alcance
Responsable Comit de diseo.
Intervinientes Analista, Diseador de base de datos, diseador de interfaces, diseador de arquitectura, diseador de algoritmos.
Tiempo total.
Veces en las que se debe repetir un proceso.
Indicadores
Tiempo en correccin de errores.
Documento ERS.
Entradas
Modelo de datos.
Diagrama de clases.
Diseo arquitectnico.
Salidas
Detalle procedimental.
Diseo de interfaces.
Computadores.
Recursos
Software para modelar.

Objetivo

Actividades
1. Definicin de levantamiento de requisitos: De acuerdo al ERS entregado por el equipo de anlisis se valuar si es suficiente la
informacin o se debe solicitar informacin adicional.
2. Diseo del modelo de datos: De acuerdo a los requerimientos entregados se procede a la generacin del modelo conceptual y a
su vez al modelo relacional que es el resultado final de este proceso.
3. Definir diseo arquitectnico: En base al requerimiento o tipo de aplicacin se define la arquitectura del sistema, definiendo
patrn arquitectnico, diseo arquitectnico, elaborar modelo de componentes, modelo de secuencias y modelo de clases.
4. Diseo de interfaces: Basados en los componentes y su interaccin se procede a elaborar el modulo grafico de cada componente
de ser necesario.
5. Diseo procedimental: Teniendo el modelo de clases y el de componentes se procede a disear los procedimientos que
fundamentan las relaciones entre componentes y clases.

Caracterizacin proceso diseo de modelo de datos

Pgina 15 de 60

Documentacin proceso diseo de modelo de datos

Logo
Objetivo
Alcance
Responsable
Intervinientes
Indicadores
Entradas
Salidas
Recursos

Nombre macro proceso: Diseo

Nombre proceso: Diseo de modelo de datos

Fecha: 27/09/2016
Cdigo:
Versin:1

Realizar el modelo de datos que ser el que soporte los datos de la aplicacin a desarrollar.
Desde que se recibe el ERS hasta que se entrega el modelo relacional.
Equipo de diseo.
Diseador de bases de datos.
Numero de correcciones que se deben hacer a cada versin que se genere del modelo.
Peticiones de cambio al equipo de anlisis cuando no hay claridad.
Correcciones en tiempo de codificacin.
Tiempo de entrega.
Documento ERS
Modelo relacional.
Modelo conceptual.
Computadora.
Software de modelamiento(DataModeler)

Actividades
1. Identificar entidades y propiedades: Con el fin de definir las componentes del modelo conceptual.
2. Construir modelo ER: Basadors en las entidades y propiedades identificadas se construye el modelo conceptual (Modelo ER).
3. Evaluar: Despus de haberse diseado el modelo conceptual se valida si abarca todo lo requerido de acuerdo a lo expuesto en el
ERS.
4. Construir modelo Relacional: Basados en el modelo conceptual se construye el modelo relacional que es la representacin final de
la estructura de la base de datos.

Pgina 16 de 60

Caracterizacin proceso diseo arquitectnico

Pgina 17 de 60

Documentacin diseo arquitectnico

Logo
Objetivo
Alcance
Responsable
Intervinientes
Indicadores
Entradas
Salidas
Recursos

Nombre macro proceso: Diseo

Nombre proceso: Diseo Arquitectnico

Fecha: 27/09/2016
Cdigo:
Versin:1

Definir el modelo arquitectnico que soportara la aplicacin.

Desde que se define el modelo de datos hasta entregar el diseo arquitectnico de la aplicacin.
Equipo de diseo.
Diseador arquitectnico.
Correcciones en etapa de construccin.
Tiempo de entrega.
Nmero de veces en que se tuvo que corregir el modelo original.
Modelo de datos.
ERS.
Diseo arquitectnico.
Computadora.
Software de modelamiento.

Actividades
1. Abstraer los requisitos del ERS: Basados en esto buscamos definir las funcionalidades.
2. Identificar el ambiente de la plataforma: Esto con el fin de identificar que patrones y diseo se pueden utilizar.
3. Definir patrn y diseo arquitectnico: Sabiendo el tipo de aplicacin se definir el diseo y patrn que ms contribuya en la
elaboracin y construccin del proyecto.
4. Construir diagrama de componentes: Teniendo el modelo de datos y habiendo identificado la arquitectura del sistema se
construir un diagrama de componentes.
5. Construir modelo de secuencias: All se definirn las relaciones entre componentes.
6. Construir modelo de clases: Es una abstraccin ms baja de cada componente que describe la aplicacin.

Pgina 18 de 60

Caracterizacin del proceso diseo de interfaces

Pgina 19 de 60

Documentacin proceso diseo de interfaces

Logo
Objetivo
Alcance
Responsable
Intervinientes
Indicadores
Entradas
Salidas
Recursos

Nombre macro proceso: Diseo

Nombre proceso: Diseo de interfaz

Fecha: 27/09/2016
Cdigo:
Versin:1

Realizar las interfaces que son la parte fundamental para el intercambio de informacin con el cliente.
Desde que se recibe el modelo de datos y componentes hasta entregar los prototipos de interfaz.
Equipo de diseo.
Diseador de interfaces.
Numero de correcciones que se deben hacer.
Tiempo empleado.
Modelo de datos.
Diseo arquitectnico.
Prototipos de interfaz.
Computadora.
Software de diseo (Ps, Ai, entre otros).

Actividades
1. Identificar funcionalidades: Con base a las funcionalidades identificadas en el ERS se procede a definir las funcionalidades en
cada prototipo.
2. Identificar roles: Con esto se busca saber que usuario puede tener acceso a que contenido en la plataforma y as plasmarlo en la
interfaz.
3. Disear interfaz: Despus de tener todos estos conceptos claros se procede a generar la interfaz.

Pgina 20 de 60

Caracterizacin proceso diseo procedimental

Pgina 21 de 60

Documentacin diseo procedimental

Logo
Objetivo
Alcance
Responsable
Intervinientes
Indicadores
Entradas
Salidas
Recursos

Nombre macro proceso: Diseo

Nombre proceso: Detalle procedimental

Fecha: 27/09/2016
Cdigo:
Versin:1

Realizar la abstraccin de cada objeto y procedimiento para hacer su definicin algortmica.

Desde que se recibe el modelo de clases hasta que se entrega la abstraccin algortmica de cada procedimiento
Equipo de diseo.
Diseador de algoritmos.
Tiempo de entrega.
Lneas de cdigo planteadas.
Correcciones solicitadas.
Diagrama de clases.
Diseo arquitectnico.
Descripcin algortmica de cada procedimiento.
Computadora.

Actividades
1. Identificar objetos y procedimiento: Esto se hace con el fin de identificar los procedimientos y objetos que componen cada clase.
2. Abstraer cada objeto y procedimiento: Esto nos lleva a tener una abstraccin ms baja de cada procedimiento.
3. Plantear algoritmo: Despus de tener identificadas y abstradas cada una de las funcionalidades y objetos se define cada
procedimiento algortmicamente.

Pgina 22 de 60

CODIFICACIN
Caracterizacin proceso de codificacin

Pgina 23 de 60

Documentacin proceso de codificacin:

Logo
Objetivo
Alcance
Responsable
Intervinientes
Indicadores
Entradas
Salidas
Recursos

Nombre macro proceso: Codificacin

Nombre proceso: Codificacin

Fecha: 29/09/2016
Cdigo:
Versin:

Codificar todos los modelos realizados en la fase de diseo, para as poder obtener un software funcional.
Este proceso empieza desde que se realizan los diseos hasta que se procede a realizar las pruebas.
Desarrollador(es).
Lder del proyecto, desarrollador(es).
Tiempo de codificacin de las tareas.
Cantidad de lneas de cdigo realizadas semanalmente.
Documento de diseo con todos los modelos que representan al sistema.
Producto de software funcional para ser probado.
Computadores.
Oficinas.
Lenguaje(s) de programacin

Actividades
1. Analizar nuevamente los requerimientos y plantear solucin sin escribir cdigo: El equipo de trabajo se rene para analizar
los requerimientos del sistema, comprobar que los diseos elaborados satisfagan la necesidad del producto, si se detecta algn
error, plantearle al lder del proyecto y al equipo de diseo una posible solucin.
2. Analizar la(s) historia(s) de usuario asignadas: Cada miembro del equipo de trabajo debe analizar las historias de usuario
asignadas con sus respectivas tareas, si es una pgina esttica agregar a la carpeta de pginas estticas y posteriormente generar su
vista.
3. Agregar a la carpeta de pgina esttica y generar vistas: Se debe generar las vistas correspondientes a esta pgina esttica,
verificar si estas vistas son correctas, si son correctas proceder a crear pruebas para las vistas, de lo contrario disear nuevamente.
4. Crear pruebas para las vistas: Toda vista que se realice debe ser examinada detalladamente, probar su funcionalidad y los
aspectos estticos cumplan con los criterios de aceptacin definidos. Si estas pruebas son exitosas, se procede a revisar los
cambios con el equipo de trabajo.
5. Conectarse con el servicio externo y realizar las peticiones: Si no es una pgina esttica la que se est elaborando, es necesario
definir si se necesita un servicio externo, si este servicio se necesita se deben realizar las peticiones correspondientes para
incluirlo en la aplicacin. La solicitud de este servicio debe ser verificada por el lder del proyecto para evaluar costos y
factibilidad, si el lder del proyecto la aprueba el equipo debe revisar estos cambios.
Pgina 24 de 60

6. Crear modelo con todos los campos: Si la historia de usuario necesita un modelo de datos, este se debe crear con todos los
campos necesarios, despus verificar si esa creacin es exitosa o no, si lo es proceder a crear las clases correspondientes a cada
modelo.
7. Generar clase para cada modelo: Para cada modelo creado es necesario generar una clase, si se requiere entrada de datos, se
debe crear un formulario, de lo contrario proceder a realizar pruebas al modelo.
8. Crear formulario con los campos: Se debe disear un formulario con los campos o datos de entrada que son necesarios para el
modelo creado.
9. Implementar la lgica para cumplir con los requerimientos: Con base a la experiencia de cada desarrollador, elaborar los
mtodos necesarios para cumplir con los requerimientos especificados, teniendo en cuenta los estndares utilizados para la
codificacin de estos.
10. Realizar commit: Despus de verificar que la persistencia y vistas de los modelos creados, se debe realizar commit o guardar
todos los modelos y las vistas realizadas, para que as todos los miembros del equipo de trabajo tengan acceso a los ltimos
avances realizados por cada programador.
11. Equipo revisa los cambios: Cada avance realizado lo debe verificar el equipo de trabajo, para as saber si se est cumpliendo o
no con los objetivos, si se detecta algn error debe ser corregido de inmediato, de lo contrario se procede al despliegue.
12. Correccin de errores: Lo principal en esta actividad es detectar el error, para ello se deben realizar las pruebas unitarias
necesarias para detectar fallos, despus de detectados se procede a corregir y verificar que los errores fueron solucionados.
13. Avances pasan a produccin: Despus de que se realizan todas las pruebas funcionales al producto de software, el equipo de
deploy se encarga de subir los cambios y las nuevas funcionalidades a produccin.

Pgina 25 de 60

PRUEBAS
Caracterizacin proceso de pruebas

Pgina 26 de 60

Pgina 27 de 60

Documentacin proceso de pruebas

Logo
Objetivo
Alcance
Responsable
Intervinientes
Indicadores
Entradas
Salidas
Recursos

Nombre macro proceso: Pruebas

Nombre proceso:

Fecha: 27/09/2016
Cdigo:
Versin:1

Realizar el plan para Disear, Ejecutar, Elaborar y Revisar pruebas que se aplicaran en el desarrollo del proyecto.
Desde que se reciben los prototipos sujetos a prueba hasta que se elabora el soporte de pruebas.
Equipo de pruebas.
Diseador de pruebas, lder del proyecto, tester.
Tiempo de entrega.
Pruebas ejecutadas por da.
Fallos detectados.
Correcciones solicitadas.
Mdulo de software codificado.
Diseo de pruebas.
Computadora.
ERS

Actividades
1. Elaborar plan de pruebas: All se definen aspectos como: Alcance de pruebas, Tipos de prueba, Estrategia de prueba, criterios de
salida, as mismo se definen tiempos, roles, entre otros.
2. Diseo de pruebas: Estando ya listo en plan de pruebas el equipo empieza a analizar toda la documentacin existente respecto al
sistema y disea los casos de prueba.
3. Definicin de datos de prueba: Teniendo diseados los casos de prueba se procede a escoger los datos con los que ser probado
el sistema.
4. Ejecucin de pruebas: Ya definidos los datos que se utilizarn se procede a ejecutar las pruebas ya sean manuales o automatizadas,
a su vez los fallos detectados debern ser documentados.
5. Evaluacin de criterios de salida: De acuerdo a las salidas generadas en la ejecucin de las pruebas estas debern ser enfrentadas
con las mtricas que se haban definido para las salidas.
6. Cierre de procesos: En esta etapa se cierran las incidencias reportadas, se debe evaluar si los entregables planteados efectivamente
fueron entregados, entre otros; y lo ms importante se hace una reunin de retrospectiva.

Pgina 28 de 60

Pgina 29 de 60

PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

1. PROPSITO
En el presente plan de SQA para el proyecto JOMM cubrir la fase de planificacin del proyecto,
diseo, codificacin y pruebas de la metodologa de programacin XP con el fin de asegurar la
calidad en cada una de estas fases.
Los procedimientos definidos en este documento se utilizarn para examinar las prestaciones que
dar el software, as como para examinar la documentacin y determinar que ambos cumplieron
con los requerimientos tcnicos y de rendimiento del sistema a ser desarrollado.

2. GESTIN
3.1 Organizacin
Organizacin: En la metodologa XP, el equipo de trabajo est compuesto principalmente por el
cliente, jefe del proyecto, consultor, entrenador, programador(es), encargado(s) de pruebas,
encargado de seguimiento y el consultor. A continuacin, se describe las funciones de cada uno
de los miembros del equipo de trabajo.
Cliente

Definir especificaciones

Influir sin controlar

Confiar en el equipo de desarrollo

Definir criterios de aceptacin (pruebas funcionales)

Jefe del proyecto

Favorecer la relacin entre usuarios y desarrolladores

Cubrir las necesidades del equipo

Asegurar el alcance de los objetivos

Consultor

Apoyar al equipo en funciones puntuales

Entrenador

Experto en XP
Pgina 31 de 60

Responsable del proceso en su conjunto

Identificar desviaciones y exigir atenciones a estas

Guiar al grupo de forma indirecta

Intervenir directamente en algn proceso si es necesario

Atender rpidamente un problema

Programador(es)

Capacidad de comunicacin

Responsable del cdigo fuente

Responsable sobre la integridad del sistema

Cdigo colectivo

Encargado de pruebas

Disear pruebas

Ejecutar pruebas funcionales

Publicar resultados de las pruebas

Encargado del seguimiento (Tracker)

Recoge, analiza y publica informacin sobre el avance del proyecto, sin afectar el
proceso.

Supervisa el cumplimiento de la estimacin en cada iteracin.

Informa sobre el avance de la iteracin en curso.

Controla el avance de las pruebas funcionales, de los errores reportados, de las

responsabilidades aceptadas y de la gestin de cambios.

2.1. Actividades
Ciclo de vida del software
Se realizan las principales actividades de la metodologa, ellas son: anlisis o planeacin, diseo,
codificacin y pruebas.
Planeacin

Pgina 32 de 60

Esta actividad comienza escuchando a los clientes, para entender el contexto del negocio y
definir las caractersticas principales y funcionalidad que se requiere, estas caractersticas se
transforman en requerimientos del negocio que se especifican mediante Historias de Usuario; las
cuales recogen la interaccin hablada entre desarrolladores y usuarios. Una vez hechas las
Historias de Usuario, el equipo de desarrollo las divide en tareas, estima el esfuerzo, recursos
requeridos para su implementacin, se genera el plan de entregas, las iteraciones, la rotacin de
parejas y las reuniones diarias.
Diseo
Es la etapa en donde son evaluadas las historias de usuario por el equipo del proyecto para
dividirlas en tareas, cada tarea representa una caracterstica distinta del sistema y se puede
disear una prueba de unitaria que verifique cada tarea (estas tareas se representan por medio de
las tarjetas CRC (Clase-Responsabilidad-Colaborador). Las tarjetas CRC identifican y organizan
las clases bajo el paradigma orientado a objetos (lo que incluye asignacin de responsabilidades),
cada tarjeta contiene el nombre de la clase (que representa una o ms historias de usuario), una
descripcin de las responsabilidades o mtodos asociados con la clase, as como la lista de las
clases con que se relaciona o que colaboran con ella.
Codificacin o desarrollo
Se lleva a cabo la programacin (individual o en parejas, dependiendo la dificultad), la unidad de
pruebas y la integracin del cdigo. Durante esta etapa se espera la disponibilidad del cliente
para que ste pueda resolver cualquier duda que se presente durante una jornada de trabajo.

Pruebas
Cada tarea que se identifica en las historias de usuario, representa una caracterstica distinta del
sistema y se realizan unas pruebas de unidad a cada una de ellas, existen pruebas unitarias las
cuales son diseadas para probar cada uno de los mtodos y clases, dichas pruebas son realizadas
por los programadores, se procede con el cliente a verificar los criterios de aceptacin para cada
historia de usuario. Se deben realizar pruebas de integracin para verificar el funcionamiento
total del sistema.

Pgina 33 de 60

2.1.1 Actividades de calidad a realizarse

Las tareas que se realizan debern reflejar buena aceptacin en las evaluaciones a realizarse, los
estndares a seguir, los productos a revisar, los procedimientos a seguir en la elaboracin de los
distintos productos y los procedimientos para informar de los defectos detectados a sus
responsables, se debe realizar el seguimiento de los mismos hasta su correccin.
Las actividades que se realizarn son:
Revisar cada producto
Revisar el ajuste al proceso
Realizar Revisin Tcnica Formal (RTF)
Asegurar que los errores son documentados
2.1.2 Revisar cada producto
En esta actividad se revisan los productos que se definieron como claves o de mayor riesgo para
el negocio. Se debe verificar que no queden errores funcionales sin resolver en el informe de
revisin previo, si se encuentra que algn error no ha sido solucionado, se debe incluir en la
prxima revisin.
Se revisan los estndares utilizados en la codificacin, documentacin, modelamiento, utilizando
una lista de chequeo defina para ese producto en especfico.
Es necesario identificar, documentar y seguir detenidamente los errores encontrados, verificar
que estos fueron solucionados y reportarlo al rea encargada. Se obtiene un informe de revisin
de acuerdo al plan SQA, el informe debe ser distribuido a los responsables del producto.
2.1.3 Revisar el ajuste al proceso
Se revisan los productos que se definieron como claves para verificar el cumplimiento de las
actividades definidas durante el proceso, con el objetivo de asegurar la calidad en el producto
final del desarrollo, se deben realizar revisiones sobre los productos durante todo el ciclo de vida
del desarrollo del producto software. Establecer los criterios de revisin y evaluacin del
producto, teniendo en cuenta productos previos que se generaron, para as comprobar que
cumple con las especificaciones. Esta informacin se obtiene de los siguientes documentos: Plan
Pgina 34 de 60

del Proyecto, Plan de historias de usuarios y plan de verificacin para poder ser evaluadas. Este
informe debe ser distribuido a los responsables de las actividades.
2.1.4 Realizar revisin tcnica formal
Es un proceso de revisin riguroso, que consiste en identificar errores de funcionamiento, lgicos
o de implementacin en el producto de software, se debe verificar que satisface las
especificaciones y que cumpla con los estndares establecidos. En la revisin participan el
responsable SQA y los integrantes del equipo de desarrollo. La duracin de esta reunin no debe
ser mayor a tres horas y se genera un informe de revisin tcnica formal RTF.
2.1.5 Asegurar que los errores son documentados
Es necesario que los errores encontrados en las actividades y en los productos sean
documentados y manipulados de acuerdo a los mecanismos establecidos. Se deben a revisar que
los responsables corrijan las veces que sea necesario hasta solucionar las desviaciones
encontradas, basados en los planes correspondientes.
2.3 Responsables

Rol

Actividad

Jefe del proyecto

Plan de levantamiento de requisitos

Jefe del proyecto

Gestin de riesgos

Jefe del proyecto

Plan de iteraciones

Analista

Modelo de casos de uso

Analista

Modelo de domino

Arquitecto

Describir arquitectura del sistema

Desarrollador(es)

Equipo de trabajo

Verificacin y validacin

Encargado de pruebas

Pgina 35 de 60

4. DOCUMENTACIN
4.1 Propsito
El propsito principal de este plan es generar la documentacin requerida para asegurar,
revisar y generar todos los prototipos necesarios para el proceso de calidad dentro de un
proyecto de software.
Dentro de todos estos procesos se establecen actividades, procesos, metodologas y dems
herramientas que sern aplicados al ciclo de vida del software, todo este proceso estar basado
de acuerdo a las normas IEEE para los productos de software.
Para este caso en especfico nos centraremos en la norma IEEE 730 para el aseguramiento de
la calidad de los productos de software y la elaboracin del plan de SQA.
4.2 Referencias
[1] ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance Plans.
[2] ANSI/IEEE Std 830-1998, 830-1998 - IEEE Recommended Practice for Software
Requirements Specifications.
4.3 Documentacin
De acuerdo a la metodologa que soporta el proceso se han detectado diferentes entregables,
y cada uno de ellos generan una documentacin respectiva, tanto para el anlisis de calidad,
como para el proceso de trazabilidad.
A continuacin, se exponen por cada una de las fases del ciclo, las actividades y procesos y
de la misma manera el documento respectivo que estas genera, y lo ms importante es de
que manera y con que se evaluara el prototipo.
4.4 Entregables

ENTREGABLE

ACTIVIDADES

DOCUMENTO QUE
LO SOPORTA

Pgina 36 de 60

DOCUMENTO
DE
EVALUACION

Planificacin del
proyecto

Cronograma

Historias de
usuario.
Release planning.
Iteraciones.
Reuniones
diarias.
Incluir
requerimientos de
calidad.
Detallar los
procedimientos
vinculados a cada
requerimiento.
Definir
funcionalidad de
uso:
Funcionalidad,
confiabilidad,
usabilidad,
eficiencia,
mantenibilidad y
portabilidad.

Estimacin de
tareas.
Definicin de
entregas.

Actas de
reunin.
Archivo en
Word o excel.

Documento de Word.

Pgina 37 de 60

IEEE Std. 830-1998

PMBOK

Diseo o
Arquitectura

Plan de verificacin
y validacin(SVVP)

Glosario de
trminos.
Diagramas
(clases, modelo
de datos, de
actividades).
Tarjetas C.R.C.
Describir
componentes y
subcomponentes
de software.
Diseo de
interfaces.
Asociar cada
componente de
diseo a un
requerimiento.

Diagramas
UML.
Documento de
Word.
Documento de
diseo.

Requerimientos a Documento de
validacin(Word).
verificar.
Estrategia de
verificacin.
Recursos.
Hitos del
proyecto.
Lista de chequeo
para documento
de levantamiento
de requisitos.
Aseguramiento
del uso del ERS
en el diseo.
-Validacin del
uso del diseo en
la codificacin.

Pgina 38 de 60

BPM,
IEEE 1471-2000

IEEE
Std. 1012 - 1986 .

Actas de reporte.

Documento de
Identificar
Manual de usuario.
versin.
Nombre del
sistema.
mbitos.
Identificar datos y
entradas de
control.
Identificar
limitaciones del
programa.
Descripcin de
acciones
correctivas.

Documento de Word.

Reportes de
verificacin.

Documentacin de
usuario.

Plan de gestin de la
configuracin(SCM
P).

Plan del proyecto.

Identificar
entregables.
Plan de gestin de
cambios.
Reporte y estado
de cambios.
Identificar
componentes de
software.

Identificar
responsables.
Identificar
actividades.

Pgina 39 de 60

IEC 29110 Parte 51-2,PMBOK

El IEEE Std 10632001

Documento de
Word.
Plan para la
gestin de
cambios
(Formato
PMBOK).

PMBOK, IEEE
828.

Documento de
Word.
Organigrama
del proyecto.

PMBOK, IEEE
1058.1.

5. ESTNDARES, PRCTICAS, CONVENCIONES Y MTRICAS

5.1 PLANIFICACIN
Estndares para la planificacin en un proyecto de software
La fase de planificacin de un proyecto de software es quizs una de las ms cruciales, ya que si
los requerimientos en esta etapa son mal levantados el proyecto no va a satisfacer al cliente (el
cul es el alma de la empresa)
En esta etapa utilizaremos estndares en la documentacin, todo esto con el fin de tener un
esquema histrico definido y ordenado de: reuniones, requisitos, actas, entre otros
El diagrama a utilizar para la documentacin ser el siguiente.

CONTROL DE LA DOCUMENTACIN
Ttulo del documento Documento de planificacin para la construccin adecuada
del producto de software
HISTRICO DE VERSIONES
Cdigo

Versin

Fecha

Resumen

0001

01/10/2016

En esta etapa de planificacin realizamos

reuniones con el cliente para as tener una
mayor claridad de todo el proceso, adems
de ser un paso inicial para el levantamiento
de requisitos

CAMBIOS PRODUCIDOS DESDE LA LTIMA VERSIN

-

Cambios en los requerimientos

Reduccin o aumento de los costos
Reduccin o aumento de los recursos
Se han revisado todos los requerimientos y se ha documentado debidamente cada cambio
CONTROL DE DIFUSIN

Responsable

Mauricio Serna Flrez

Aprobado por

Juan Fernando Villegas

Firma

Fecha

03/10/2016

REFERENCIAS DEL ARCHIVO

Pgina 40 de 60

Autor

Mauricio Serna Flrez

Nombre del archivo

planificacion_0001_1

Localizacin

Medelln, Colombia

Prcticas para la planificacin en un proyecto de software

Las prcticas ms generales aplicables a este proyecto son: las reuniones diarias, documentacin
adecuada, aplicacin de estndares de calidad como lo son ISO 9001 y ISO 25000, utilizar software
de control de versiones para ayudarnos con los cambios en la documentacin se debe tener muy
presente que es tan solo en procesos de documentacin ya que el control de versiones se utiliza
bastante para la etapa de codificacin.
No debemos perder de vista el objetivo principal de la planificacin que es crear un marco de
trabajo para as permitirle al lder del proyecto hacer unas estimaciones mucho ms confiables y
que lleven al proyecto por el camino correcto. Cabe recordar que todas las prcticas pueden ir
variando a medica que se est progresando en el proyecto.
La etapa de planificacin es un constante aprendizaje e investigacin para encontrar puntos
cruciales del proyecto de software y as poder llegar a unas estimaciones que nos brinden una
calidad en todas las etapas del proyecto.
La planificacin adems de ser un proceso repetitivo lo cul es muy importante para generar
mejoras constantemente, tambin puede ser un proceso automatizado, a este podemos llegar
mediante el uso de herramientas las cuales nos pueden ser de mucha utilidad, algunas de estas
herramientas que

se

usarn

son: Basecamp,

TaskJuggler entre otras.

Pgina 41 de 60

GanttProject,

Todas estas herramientas nos llevan por el camino de las buenas prcticas, adems de ser sistemas
ya consolidados y que se siguen desarrollando da a da entonces podemos confiar nuestro proyecto
utilizando estas herramientas para la planificacin del mismo.
Convenciones para la planificacin en un proyecto de software
La definicin formal es que una convencin es una norma o prctica aceptada socialmente por un
acuerdo o por la costumbre
Desde aos atrs en el desarrollo de software se implementan convenciones, tanto a la hora de la
planificacin, el diseo, codificacin, etc.
En la etapa que nos concierne es este momento, existen convenciones con solo son la correcta
documentacin, con unas normas ya establecidas, adems de unos estndares internacionales que
se rigen por convenciones, todo esto lo que hace es aumentar la calidad del proyecto, para as poder
elaborar un plan de acuerdo con las necesidades.
Mtricas para la planificacin en un proyecto de software
Las matrices las podemos considerar como un conjunto de medidas destinadas a conocer o estimar
el tamao o caracterstica de un software, as entonces, las mtricas en la etapa de planificacin
seran la cantidad de reuniones que se hicieron con el cliente, la cantidad de actas generadas,
cantidad de historias de usuario, tiempo gastado en la recoleccin de la informacin.
En esta etapa tambin nos podemos valer de herramientas para el control de mtricas, con
documentacin, tipos de estimacin en las mtricas, todas estas partes son medibles. que es lo que
realmente nos interesa; adems de generar frmulas matemticas que nos ayuden en la exactitud
de los requerimientos y sus tiempos.
Hay razones cruciales por las que debemos medir un producto
1. Indicar calidad del producto
Pgina 42 de 60

2. Evaluacin de la productividad de las personas encargadas de desarrollar dicho

producto
3. Evaluar beneficios, gastos, productividad, calidad
4. Establecer una lnea base para la estimacin
5.2 DISEO
Estndares para el diseo en un proyecto de software
En esta fase deberemos empezar a EJECUTAR las tareas que fueron planificadas en la fase anterior
estas se debern realizar considerando el uso de slo las herramientas, libreras y sistemas
especificados en el documento de estndares tecnolgicos.
Para la generacin de documentacin podemos se utilizar herramientas ya conocidas como
Microsoft Office (Microsoft (NASDAQ: MSFT)) Pages (Apple Inc.)
Adems, como es ya conocido en esta etapa le damos una estructura a la planificacin, mediante
diagramas y modelos de diferentes tipos. Para la creacin de estos modelos (UML,Diagrama
entidad relacin) utilizaremos herramientas como Enterprise Architect
Cada una de las etapas del diseo deber ser discutida entre el equipo de desarrollo, adems
probada, para establecer estas pruebas se utilizar la herramienta de gestin de pruebas estndar
TestLink.
Prcticas para el diseo en un proyecto de software
1. Una de las buenas prcticas que se va a utilizar a lo largo de todo el proyecto es utilizar
una metodologa de desarrollo, en este caso, utilizaremos XP (Extreme programming)
2. Tener previamente un punto de parte, es decir, especificacin de requisitos (SRS)
3. Manejar versiones
4. Pruebas
5. Uso de diagramas y modelos, esquemas que nos ayuden a una mejor compresin del
problema
Convenciones para el diseo en un proyecto de software
1. Documentar cada cambio realizado, el nombre del documento debera empezar por el
nmero del cambio seguido por una breve descripcin del mismo.
Pgina 43 de 60

Ejemplo: Se realiz un cambio en el diseo del diagrama de clases

0003_cambio_clase_usuario.docx
2. Reuniones previas con el equipo y el cliente antes de implementar un cambio o una
nueva funcionalidad
Mtricas para el diseo en un proyecto de software
Como bien sabemos las mtricas se basan en mediciones, a la hora de disear tendremos mtricas
como, nmero de reuniones, actas, cantidad de horas trabajadas en el diseo de la base de datos,
el diseo de diagramas, efectividad a posteriori del diseo de la base de datos; para as al final
poder tomar decisiones que beneficien el proyecto. El siguiente diagrama ser de mucha utilidad
para cuantificar y calificar las mtricas.

5.3 CODIFICACIN
Estndares para la codificacin en un proyecto de software
Un estndar de codificacin completo comprende todos los aspectos de la generacin de cdigo.
Si bien los programadores deben implementar un estndar de forma prudente, ste debe tender
siempre a lo prctico. Un cdigo fuente completo debe reflejar un estilo armonioso, como si un
nico programador hubiera escrito todo el cdigo de una sola vez. Al comenzar un proyecto de
software, establezca un estndar de codificacin para asegurarse de que todos los programadores
del proyecto trabajen de forma coordinada. Cuando el proyecto de software incorpore cdigo
fuente previo, o bien cuando realice el mantenimiento de un sistema de software creado

Pgina 44 de 60

anteriormente, el estndar de codificacin debera establecer cmo operar con la base de cdigo
existente.
Tomado de Microsoft
Viendo esto se tendrn estndares a la hora de codificar, como lo son la identacin con 2 (dos)
espacios, nombrar las clases con el estndar CAMEL CASE, y los mtodos con el estndar
SNAKE_CASE
Ejemplo:

Prcticas para la codificacin en un proyecto de software

La codificacin estar basada en el principio DRY (Dont repeat yourself), es decir, no te repitas
a ti mismo. Trataremos de hacer todo el cdigo ms reusable y con la menor cantidad de
repeticiones, cuando algo se est repitiendo demasiadas veces se buscar la manera de abstraerlo
Tambin otra buena prctica que se aplicar ser nuevamente la documentacin, cada cambio que
se realice deber ser documentando, por ms mnimo que sea este puede afectar todo el proceso
de desarrollo.
Tambin se aplicarn otros principios como lo son: El principio de abstraccin, KISS (Keep it
simple, stupid), Dont make me think
Convenciones codificacin el diseo en un proyecto de software
Documentacin detallada a la hora de codificar, solamente las constantes irn en MAYSCULA,
los nombres de las clases en la base de datos deben ir en singular.
Mtricas para la codificacin en un proyecto de software
Cantidad de horas de codificacin, nmero de lneas de cdigo, cantidad de horas de trabajo, estas
sern algunas de las mtricas, pero la ms importante ser el impacto que generan todas estas

Pgina 45 de 60

juntas, no importa si se trabaja una, dos, tres u ocho horas, lo importante sern los resultados
finales, que se cumpla con los requerimientos en un determinado tiempo.
5.4 PRUEBAS
Estndares en el proceso de pruebas en un proyecto de software
Como estndar se utilizar lo siguiente: ISO/IEC/IEEE 29119
Este estndar no provee un alcance y un propsito, adems se divide en cuatro partes
fundamentales que nos ayudarn a que nuestro software sea ms confiable
Alcance: Este producto producir un software para pruebas de cualquier tipo, adems cualquier
nivel de software, desde el ms pequeo hasta el software a gran escala.
Propsito: Unificar e integrar todos los fragmentos corporativos y normativos de la literatura
reciente, que son ofrecidos actualmente por tres estndares del mercado: BSI, IEEE, and ISO/IEC
JTC 1/SC
El resultado ser un proyecto, consistente, unificado y que nos brindar una solidez y confianza en
cada una de las etapas de nuestro ciclo de vida.
Las cuatro partes en que estar dividido son:
1. Conceptos

Pruebas basadas en riesgos

Estrategias de prueba

Automatizacin de las pruebas

Las pruebas de software en las organizaciones

2. Procesos
3. Documentacin
4. Diseo de pruebas
A continuacin, se podr observar un modelo de procesos a implementar en la etapa de pruebas
Prcticas en el proceso de pruebas en un proyecto de software

Pgina 46 de 60

Utilizacin de libreras tales como minitest, RSpec para hacer pruebas en el cdigo (pruebas
unitarias, pruebas de integracin)
Adems de utilizar herramientas que nos ayuden a obtener una integracin continua en todo el
ciclo hasta llegar a las pruebas, ests herramientas sern, Circle CI, Travis CI, Jenkins.
Con todas estas prcticas y herramientas lograremos que todo el proceso sea ms armonioso y
mucho ms fcil de entender.

Convenciones en el proceso de pruebas en un proyecto de software

1. Documentacin de las pruebas
2. Documentacin de los cambios realizados
3. Orden en las pruebas

Mtricas en el proceso de pruebas en un proyecto de software

1. Cuantas pruebas han fallado
2. Por qu estn fallando?
3. Cantidad de pruebas que pasan
4. Implicacin en produccin de las pruebas que fallan

Pgina 47 de 60

6. REVISIONES Y AUDITORIAS
6.1 Objetivo
Definir las revisiones y auditorias tcnicas que se realizarn durante el desarrollo del software,
especificar cmo se llevarn a cabo cada una de estas
6.2 Requerimientos mnimo
Consiste en revisar semanalmente los avances realizados, basndose en los estndares definidos
en el presente plan. Estas revisiones sern revisadas por el responsable del cumplimiento del plan
SQA.
6.2.1 Revisin de requerimientos
Esta revisin se realiza principalmente en la etapa de anlisis y de pruebas, consiste en verificar
por parte del cliente que lo pactado en el documento de requisitos se haya cumplido
satisfactoriamente.
6.2.2 Revisin de diseos preliminares
Se realiza en la etapa de diseo, consiste en revisar que los diseos preliminares satisfagan la
necesidad del cliente, se asegura una consistencia y suficiencia tcnica en el diseo del producto
de software.
6.2.3 Revisin del plan de verificacin y validacin
Consiste en verificar que se cumplan los procedimientos especificados en el plan SQA, por
medio de esta revisin se garantiza un producto de software con calidad y estndares en cada
etapa del ciclo de vida del desarrollo de software.
6.2.4 Auditora funcional
Se realiza la auditoria funcional del producto antes de la liberacin del software, el cliente junto
al jefe del proyecto verifica que los requerimientos plasmados en el documento de requisitos se
cumplieron.

6.2.5 Auditoria fsica

Pgina 48 de 60

Se realiza para constatar que la documentacin y el software sean consistentes, los manuales de
usuario, manuales de procedimientos y registros deben coincidir con el producto de software a
ser liberado.
6.2.6 Auditoras internas al proceso
Se verifica la consistencia entre el cdigo realizado y los modelos de diseo y de interfaces, la
implementacin de esos diseos con los requisitos funcionales, y por ltimo los requisitos
funcionales frente a las descripciones del plan pruebas.
6.2.7 Revisin de documentacin del usuario
Se revisa que la documentacin realizada acerca del producto de software realizado, sea
completa, clara, correcta y aplicable a su uso.
6.2.7 Revisin postmortem
Esta actividad se realiza para revisar que el equipo de trabajo realiz todas las tareas, analizar los
resultados, evaluar a los equipos de desarrollo. Verificar los objetivos del plan de calidad, qu
metas se cumplieron y cules no?, inconvenientes que no permitieron cumplir estas metas,
evaluar las metas de cada uno de los lderes, por ltimo, se evala la participacin de cada uno de
los miembros del equipo, trabajo individual y trabajo en equipo.

Pgina 49 de 60

MODELO PARA LA EVALUACIN DE CALIDAD BASADO EN ISO

25000
El modelo establece el conjunto de actividades que se deben llevar a cabo para evaluar la calidad
de un producto software.
En el presente modelo se hace referencia a las pruebas como evaluaciones al producto software.
Este modelo cuenta con los siguientes procesos:
1. Establecer los requisitos de la evaluacin
2. Especificacin de la evaluacin
3. Diseo de la evaluacin
4. Ejecucin de la evaluacin
5. Conclusin de la evaluacin
A continuacin, se muestran las entradas y salidas de cada uno de los procesos

Pgina 50 de 60

1. Establecer los requisitos de la evaluacin

Se deben definir los aspectos del producto software que se evaluarn y las caractersticas y sub
caractersticas de calidad que se van a considerar en la evaluacin.
1.2. Precondiciones
Debe existir previamente una solicitud de evaluacin
1.2. Entradas
Necesidad de evaluacin de calidad
Se deben especificar las necesidades de evaluacin de calidad del producto definidas por quien
solicita la evaluacin

Tabla de necesidades de evaluacin

Nombre de la necesidad

Descripcin de la necesidad

Partes a evaluar
En caso de ser un producto software extenso, donde un mdulo no depende de otro, se puede
aplicar el proceso de evaluacin de software a slo una parte del producto.
1.3. Actividades
1.3.1 Elaborar los requisitos para la evaluacin
Utilizando la tabla de necesidades de evaluacin se elaboran los requerimientos de calidad
para la evaluacin, se especifican las caractersticas y subcaractersticas.
Utilizando las partes a evaluar (Entrada) y la tabla de necesidades de evaluacin, se define el
propsito y el alcance de la evaluacin
Junto con quien solicita la evaluacin se establece el motivo por el cual se llevar a cabo dicha
evaluacin.
1.3.2 Definir el rigor de la evaluacin
Se define qu tan rigurosa sern las pruebas
En la siguiente tabla se define los porcentajes de rigor para los indicadores de la evaluacin.
Un porcentaje 99% de rigor, es decir, muy elevado, indica que todas las pruebas no sern
aceptadas si su medidor o indicador es menor al 99%
Pgina 51 de 60

Rigor para las evaluaciones del producto software

Rigor

Porcentaje de aceptacin para los

indicadores

Muy elevado

99 %

Elevado

80 %

Medio

70 %

Bajo

60 %

Un porcentaje 80% de rigor, es decir, elevado, indica que todas las pruebas no sern aceptadas si
su medidor o indicador es menor al 80
Un porcentaje 70% de rigor, es decir, medio, indica que todas las pruebas no sern aceptadas si
su medidor o indicador es menor al 70%
Un porcentaje 60% de rigor, es decir, bajo, indica que todas las pruebas no sern aceptadas si su
medidor o indicador es menor al 60%
Cabe destacar que para los indicadores cualitativos no aplica el porcentaje, pero s se pueden
clasificar en muy elevado, elevado, medio y bajo.
1.3.3 Documentar los requisitos y el rigor de la evaluacin
Se debe diligenciar los siguientes formatos
Descripcin general de la evaluacin
Propsito
Necesidades de
evaluacin

Alcance
Motivo
Nivel de rigor

Lista de requerimientos de calidad

Requerimiento de
calidad

Nivel de
importacin

Caracterstica
de calidad

Pgina 52 de 60

Subcaracterstica de
calidad

En caso de estarse evaluando un mdulo o parte del producto software se debe especificar las
partes evaluadas
1.3.4 Aprobacin de la documentacin
Se verifica la documentacin generada por parte del solicitante y del evaluador o diseador de la
prueba.
Requisitos de evaluacin de calidad
Propsito de la evaluacin
Lista de requerimientos de
calidad
Producto o partes a ser
evaluados
Control de cambios

Esta seccin contiene el control de cambios del documento, con la

versin, la persona que cre o modific el documento y la fecha de
creacin o modificacin.

Aprobaciones

Esta seccin contiene el detalle de las aprobaciones del documento

1.4 Herramientas
Lista de caractersticas y sub caractersticas de calidad proporcionadas por la ISO 25000
1.5 Salida
Requisitos de la evaluacin de calidad
2. Especificacin de la evaluacin
Se especifican las medidas para la evaluacin que se llevar a cabo y se analizan los criterios de
decisin con base al nivel de rigor de la prueba definido en los requisitos de evaluacin
2.1 Precondiciones
Haber aprobado los requisitos de la evaluacin y su documentacin
2.2 Entradas
Para este proceso es necesario hacer uso de los requisitos de la evaluacin
2.3 Actividades
Pgina 53 de 60

2.3.1 Elaborar la especificacin de la evaluacin

Se debe analizar las relaciones entre componentes o partes del producto implicados en la
evaluacin

El evaluador debe seleccionar las mtricas para cada uno de estos componentes, esto debe
hacerlo teniendo en cuenta todos los requerimientos de calidad (caractersticas y
subcaractersticas de calidad)

En caso de ser necesitado algn mecanismo para interpretar las mtricas, este debe ser
documentado

Establecer los criterios de decisin utilizando el nivel de rigor para la evaluacin, en caso
Especificacin de la evaluacin de calidad
Relaciones entre componentes del producto
software

Especificacin de las mtricas y sus criterios de

decisin

Anexos para el nivel de rigor

Control de cambios

Aprobacin

de agregarse una excepcin, es decir, que no cumpla el nivel de rigor para la prueba por
factores externos a este, ser necesario entonces que el evaluador soporte esto en un acta
en donde se especifique la excepcin
Pgina 54 de 60

2.3.2 Documentar la especificacin de la evaluacin

Documentar las relaciones entre los componentes del producto

Tabla de mtricas para el producto discriminado por partes, si la prueba se est haciendo
por partes

Si fueron acordadas excepciones en el nivel de rigor para un indicador, se deben incluir

en el proceso de documentacin

Tablas de criterios de decisin, aqu se especifica segn el indicador, qu decisin tomar.

2.3.3 Aprobacin

Se analiza la especificacin de la evaluacin documentada.

Se verifican cada una de las actividades realizadas

Finalmente, se procede a la aprobacin de la especificacin de la evaluacin

2.4 Salidas
Especificacin de la evaluacin
3. Diseo de la evaluacin
Se elabora un plan de evaluacin
3.1 Precondiciones
Aprobacin de mtricas de calidad y sus criterios de decisin para la evaluacin de un producto.
3.2 Entradas
Documento de especificacin de la evaluacin
3.3 Actividades
3.3.1 Elaborar el plan de evaluacin
Se deben programar las acciones teniendo en cuenta los recursos disponibles, estos recursos
pueden ser personas, equipos, etc.
Seguidamente se deben identificar los riegos para que el plan de evaluacin no se d de forma
normal
Agendar capacitaciones de personal
3.3.2 Documentar el plan de evaluacin
Se documenta el plan de evaluacin del producto

Pgina 55 de 60

Responsabilidades y riesgos
Persona o grupo responsable
de la prueba

Prueba

Riesgos

Acciones afectadas

Control de cambios

Plan de pruebas
Prueba

Tipo de prueba

Componente
evaluado

Horas
empleadas

Fecha inicio

Fecha final

3.3.3. Aprobacin
Se toman cada uno de los formatos generados en la documentacin, se analizan por parte del
evaluador y, por consiguiente, se procede a la evaluacin
3.4 Salidas
Plan de pruebas
4. Ejecucin de la evaluacin
Se ejecutan las pruebas al producto software
4.1 Precondiciones
Plan de pruebas
4.2 Entradas
Pgina 56 de 60

Requerimientos de evaluacin

Especificacin de la evaluacin

Plan de pruebas

4.3 Actividades
4.3.1 Ejecutar las acciones del plan de pruebas

Segn el plan definido se ejecutar las pruebas, estas irn acompaadas de los resultados
para cada una de ellas

Producto de las acciones de evaluacin se obtienen datos para producir los resultados que
sern incluidos en el reporte de evaluacin, estos datos pueden ser nmeros, grficos,
diagramas entre otros

Cuando una herramienta de software es necesaria para recolectar datos o interpretarlos,

una referencia a esta herramienta debe ser incluida en el reporte de evaluacin; la
informacin mnima ser: el nombre de la herramienta, el fabricante, y la versin.

Se debe incluir las tcnicas especficas; por ejemplo, el uso de listas de verificacin
cuando una accin de evaluacin requiere la inspeccin de un documento.

4.3.2 Documentar la ejecucin del plan de pruebas

Se debe detallar los componentes del producto evaluados

Se debe detallar el software utilizado para la evaluacin de calidad

Para cada evaluacin de calidad de las partes del producto o de la totalidad del producto,
se deben guardar los datos de acuerdo a las tcnicas especficas utilizadas

Se debe elaborar diligenciar el siguiente formato para los requisitos

Elaborar el borrador completo del reporte de evaluacin de calidad

4.3.3 Revisin e informe

Una vez revisados los resultados de la evaluacin, estos deben ser incluidos en el reporte de
evaluacin de calidad.
4.4 Salidas
Borrador completo del reporte de evaluacin de calidad
5. Conclusin de la evaluacin
Se revisa y se presenta el informe de la evaluacin
5.1 Precondiciones
Haberse generado el borrador del reporte de la evaluacin
Pgina 57 de 60

5.2 Entradas
Borrador del reporte de la evaluacin
5.3 Actividades
5.3.1 Revisin conjunta del reporte de evaluacin del producto
Se hace una socializacin del resultado de las pruebas con el equipo de desarrollo.
Se establece una agenda para aquellas inconformidades con el borrador del reporte de
evaluacin
Luego de haber terminado la agenda, se resocializan los resultados, especificando los cambios
hechos
5.3.2 Elaborar el reporte de la evaluacin del producto
Se procede a elaborar el reporte ya revisado por parte del equipo de desarrollo

5.4 Salidas
Reporte final de la evaluacin del producto

Pgina 58 de 60

CONCLUSIONES

El proceso de diseo de software est caracterizado por ser un modelo por fases, ya que
las salidas que van generando los micro procesos van siendo el insumo o las entradas de
otros procesos que componen toda esta fase.
El estndar IEEE 1045 se encarga de proporcionar criterios de medicin, y mtricas que
lo que hacen es definir puntos de evaluacin en los procesos del ciclo de vida del
software, esto con el fin de proporcionar evidencias para el mejoramiento continuo de los
procesos.
Toda empresa deber tener un plan de medicin de calidad para as poder garantizar que se
est realizando un producto que satisface las necesidades de los requerimientos, pero
tambin tiene calidad en todas las fases de su construccin.

Pgina 59 de 60

REFRENCIAS

http://es.slideshare.net/guest0071c1/fase-postmortem
https://sites.google.com/site/xpmetodologia/marco-teorico/funcionamiento
http://www.fing.edu.uy/inco/cursos/ingsoft/pis/memoria/dvd02/experiencia2009/mate
rial/grupo5/sqa/inicial/iter1/SQAPLAG5v1.1.pdf
http://ingenieriacesmag.blogspot.com.co/p/diseno-procedimental.html
https://msdn.microsoft.com/es-co/library/dd490886.aspx
https://msdn.microsoft.com/es-es/library/dd409377.aspx
https://sistemasumma.com/2011/06/11/diseno-procedimental/

Pgina 60 de 60