planSQA

Plan de SQA
SI-Admin Clinic
Sistema de información en ambiente web para
administrar la información de la clínica de salud de la
ciudad de Bogotá
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Plan de SQA
SI-Admin Clinic
Tabla de contenido
Propósito ...................................................................................................................................................... 4
Referencias ...................................................................................................................................................... 4
Gestión ......................................................................................................................................................... 5
Organización ................................................................................................................................................... 5
Actividades ...................................................................................................................................................... 9
Ciclo de vida del software cubierto por el Plan .......................................................................................... 9
Actividades de calidad a realizarse ............................................................................................................. 9
Evaluar los requerimientos ................................................................................................................ 10
Evaluar el diseño del software ........................................................................................................... 11
Evaluar las pruebas de módulos implementados ........................................................................... 12
Evaluar el proceso de acciones correctivas ..................................................................................... 13
Evaluar la administración de la configuración ............................................................................... 14
Relaciones entre las actividades de SQA y la planificación ....................................................................... 15
Responsables ................................................................................................................................................. 15
Documentación .......................................................................................................................................... 19
Propósito ....................................................................................................................................................... 19
Documentación mínima requerida ................................................................................................................ 19
Los documentos mencionados en la siguiente tabla deben de estar bajo la administración de la
configuración, enviando una petición al administrador de aseguramiento de la calidad cuando se
realicen cambios, para que este determine si el documento puede entrar a la línea base. ............. 20
Especificación de requerimientos del software ........................................................................................ 20
Descripción del diseño del software ......................................................................................................... 23
Plan de Verificación & Validación ............................................................................................................. 23
Reporte de verificación y validación ................................................................................................. 24
Documentación de usuario ....................................................................................................................... 24
Plan de Gestión de configuración .................................................................................................................. 25
Propósito................................................................................................................................................... 25
Resumen ................................................................................................................................................... 25
Organización, Responsabilidades ............................................................................................................. 25
Herramientas, Entorno, e Infraestructura ................................................................................................ 26
Forma de trabajo ...................................................................................................................................... 26
Control de Cambios .................................................................................................................................. 26
Reportes y Auditorias ............................................................................................................................... 27
Otros documentos ......................................................................................................................................... 27
Plan del proyecto ........................................................................................................................................ 27
Plan de desarrollo ...................................................................................................................................... 27
Estándares, prácticas, convenciones y métricas .......................................................................................... 27
Objetivos ....................................................................................................................................................... 28
Métricas de proceso ...................................................................................................................................... 28
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 2 de 39
Plan de SQA
SI-Admin Clinic
Métricas de proyecto .................................................................................................................................... 29
Métricas de producto .................................................................................................................................... 29
Estándar de documentación.......................................................................................................................... 30
Estándar de verificación y prácticas .............................................................................................................. 31
Otros Estándares ........................................................................................................................................... 31
Estándar de documentación en general ........................................................................................................ 31
Estándar de documentación en técnica ........................................................................................................ 32
Estándar de implementación ........................................................................................................................ 32
Revisiones y auditorías ............................................................................................................................... 32
Objetivo ......................................................................................................................................................... 32
Requerimientos mínimos ............................................................................................................................... 32
Revisión de requerimientos ...................................................................................................................... 33
Revisión de diseño preliminar .................................................................................................................. 33
Revisión de diseño crítico ......................................................................................................................... 33
Revisión del plan de verificación & validación .......................................................................................... 33
Auditoría funcional ................................................................................................................................... 33
Auditoría física .......................................................................................................................................... 33
Auditorías internas al proceso .................................................................................................................. 33
Revisiones de gestión ............................................................................................................................... 34
Revisión del Plan de gestión de configuración ......................................................................................... 34
Revisión Post Mortem .............................................................................................................................. 34
Agenda ...................................................................................................................................................... 34
Otras revisiones ............................................................................................................................................. 36
Revisión de documentación de usuario .................................................................................................... 36
Revisiones técnicas formales RTF ............................................................................................................. 36
Verificación ................................................................................................................................................ 37
Reporte de problemas y acciones correctivas ............................................................................................. 37
Herramientas, técnicas y metodologías ...................................................................................................... 37
Gestión de riesgos ...................................................................................................................................... 38
Política de calidad....................................................................................................................................... 38
Anexos........................................................................................................................................................ 39
Formulario de Pedidos y Detección de Cambios ........................................................................................... 39
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 3 de 39
Plan de SQA
SI-Admin Clinic
Plan de SQA
Propósito
El propósito de este plan es especificar las actividades que se realizarán para asegurar la calidad
del software a construir. En él se detallan los productos que se van a revisar y los estándares,
normas o métodos a aplicar; los métodos y procedimientos que se utilizarán para revisar que la
elaboración de los productos se realice como lo establece el modelo de ciclo de vida del
proyecto; y procedimientos para informar a los responsables de los productos los defectos
encontrados y realizar un seguimiento de dichos defectos hasta su corrección.
El software a realizar es un sistema de información modular en un ambiente web en el cual se
podrá realizar el registro e ingreso u hospitalización de los pacientes de la clínica de salud de la
ciudad de Bogotá, que permite gestionar la información de los pacientes, de las habitaciones y
camas ocupadas, los materiales y medicamentos utilizados. Calculando el costo de la
hospitalización al momento de dar de alta a los pacientes. Además de, permitir consultar las
camas y habitaciones disponibles, ocupadas y las características del paciente que ocupa la cama.
Con el sistema de información web para la administración de la información de la clínica de salud
se quiere lograr:

Mejorar la calidad y eficiencia en el control de la información de los pacientes de la
clínica.

Gestionar de manera más eficiente la información y utensilios de la clínica como las
habitaciones, las camas y medicamentos utilizados.

Disminuir la carga de trabajo de los administradores.

Disminuir el tiempo el cálculo de los costos de la hospitalización al momento de dar
de alta a los pacientes.

Administrar la información de la infraestructura de la clínica como las habitaciones,
camas ocupadas y disponibles, información de medicamentos y las características
del paciente que ocupa cada cama.
Referencias
[ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance
Documento Plantilla gestión de riesgos
Documento plan de gestión de riesgos
Documento plantilla de revisión de SQA
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 4 de 39
Plan de SQA
SI-Admin Clinic
Documento Informe Final de SQA
Documento plantilla de Revisión técnica formal
SQuaRE, ISO 25000:2005,
Quality management systems – Requirements ISO 9001:2008]
Gestión
En las subsecciones siguientes se especifican los elementos de la organización que tienen
influencia sobre la calidad del software, como está conformada la línea de gestión de calidad, y
de quien es la autoridad y responsabilidad por la calidad del software, la lista de tareas cubiertas
por este plan y las responsabilidades por cada tarea.
Organización
Primeramente, debemos identificar las siguientes líneas de trabajo, que acompañan a todo el
ciclo de vida del proyecto:

Gestión de Proyecto
Su principal objetivo es proveer la planificación del proyecto, que incluye los objetivos y
mecanismos de interacción entre las distintas fases: Inicial, construcción de productos
de software, Construcción de productos de Investigación y Presentación. Además,
realiza estimaciones, mediciones y analiza la factibilidad del proyecto.
Es preciso destacar, que el éxito del proyecto depende en gran medida de una buena
Gestión, por lo que se debe prestar especial énfasis en la calidad de esta, destacando un
buen seguimiento del proyecto.

Gestión de la Configuración y control de Cambios
Su principal objetico es identificar, definir y gestionar los elementos del proyecto que
deben estar bajo configuración. Es preciso hacer notar, que esta línea de trabajo resulta
de gran importancia para el desarrollo del proyecto, dado que debe asegurar que no
existan inconsistencias en el sistema desarrollado, como por ejemplo resultante de
conflicto de versiones, la no notificación de cambios, así como la realización de ciertos
cambios sin la consideración global en este plan.
Existen varias líneas de trabajo que influyen en el proyecto para controlar la calidad:

Levantamiento de Requerimientos.

Diseño del sistema de información web.

Gestión del Proyecto establecido.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 5 de 39
Plan de SQA
SI-Admin Clinic

Verificación del proyecto.

Administración de Configuración y control de cambios.

Gestión de la Calidad del software.
Existen algunas dependencias entre las líneas de trabajo antes mencionadas.

Los requerimientos no funcionales son necesarios para el diseño de la arquitectura.

La gestión del proyecto controla el avance del proyecto garantizando que se cumplan
las tareas planificadas en las demás líneas.

La gestión de configuración debe entre otras cosas tener un control de los elementos
generados por el equipo lo que implica una colaboración de las líneas básicas.
Descripción de la estructura organizacional:
1. Administrador del plan SQA: El administrador es el responsable de las siguientes
funciones:
1.1. Establecer un programa de calidad para el proyecto.
1.2. Identificar las actividades de SQA que se llevaran a cabo durante el proyecto.
1.3. Revisar y aprobar el plan de SQA del proyecto.
1.4. Resolver los problemas encontrados relacionados con la calidad.
1.5. Realizar la auditoria y el reporte de las funciones SQA para el proyecto.
1.6. Identificar los factores de calidad a ser implementados en el proyecto.
2. Administración de la configuración del software: El administrador de la configuración
es responsable de las siguientes funciones:
2.1. Realizar la revisión sobre el plan SQA establecido para el proyecto.
2.2. Implementar los factores de la calidad referentes a los procesos de aseguramiento
de la calidad de software, o asegurarse de que están siendo implementados.
2.3. Revisar que los interesados en el proyecto cumplan con el plan SQA para el
proyecto.
2.4. Implementar las actividades definidas de calidad acordadas en el plan de SQA.
3. Administración del proyecto: La administración del proyecto es la responsable de las
siguientes funciones:
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 6 de 39
Plan de SQA
SI-Admin Clinic
3.1. Revisar y aprobar el plan SQA del proyecto para el desarrollo de un sistema de
información web para administrar la información de la clínica de salud de la ciudad
de Bogotá.
3.2. Identificar al personal que realiza las funciones correspondientes del plan SQA.
3.3. Identificar los factores de calidad a ser implementados en el sistema de información
web para administrar la información de la clínica de salud.
3.4. Dar seguimiento a cualquier asunto de calidad obtenido por el plan SQA.
3.5. Asegurar que los factores de calidad sean implementados correctamente en el
sistema de información web.
3.6. Identificar, desarrollar y mantener los documentos de planeación del proyecto.
4. Área de pruebas: El área de pruebas son los responsables de las siguientes funciones:
4.1. Resolver y dar seguimiento a cualquier asunto de calidad que tenga relación con las
pruebas del sistema.
4.2. Implementar las prácticas de pruebas en el sistema de información web, procesos y
procedimientos, como se encuentra definido en el documento de pruebas del
proyecto.
4.3. Realizar la implementación de la calidad en la realización de las pruebas de acuerdo
al plan SQA.
4.4. Comentar acerca del plan SQA.
4.5. Implementar la calidad en las pruebas descuerdo al plan SQA.
5. Área de diseño y codificación: El área de diseño y codificación del sistema son los
responsables de las siguientes funciones:
5.1. Realizar con calidad el diseño y la codificación del sistema de información de
acuerdo a lo establecido en el plan SQA.
5.2. Resolver y dar seguimiento a cualquier asunto de calidad que tenga relación con el
diseño del sistema, su arquitectura y desarrollo.
5.3. Identificar, implementar y evaluar los factores de calidad que serán implementados
en el sistema de información.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 7 de 39
Plan de SQA
SI-Admin Clinic
5.4. Implementar el diseño, la arquitectura, el desarrollo, procesos y procedimientos
necesarios para el sistema de información web, siguiendo los documentos de
planeación para cada uno de estos.
5.5. Comentar acerca del plan SQA.
6. Administración de los riesgos: La administración de los riesgos es la responsable es el
responsable de las siguientes funciones:
6.1. Realizar el seguimiento a los riesgos identificados.
6.2. Buscar medidas de contingencia de los riesgos identificados.
6.3. Realizar comentarios de mejora al plan SQA.
6.4. Notificar a la administración del proyecto cuando un riesgo identificado, se
convierta en una amenaza para el proyecto.
7. Administración de los requerimientos: La administración de los requerimientos es la
responsable de las siguientes funciones:
7.1. Realizar la especificación de los requerimientos del software a desarrollar.
7.2. Implementar la calidad durante la realización de los requerimientos del software.
7.3. Realizar el debido análisis a los requerimientos establecidos para el proyecto.
7.4. Implementar calidad en la especificación de los requerimientos del software.
7.5. Comentar acerca del plan de aseguramiento de la calidad.
8. Área de métricas: El área de métricas es la responsable de las siguientes funciones:
8.1. Realizar el plan de métricas para el proyecto.
8.2. Evaluar las métricas obtenidas a lo largo del proyecto.
8.3. Realizar la implementación de la calidad al realizar el plan de métricas del proyecto
8.4. Comentar acerca del plan de aseguramiento de la calidad.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 8 de 39
Plan de SQA
SI-Admin Clinic
Actividades
Ciclo de vida del software cubierto por el Plan
El alcance del Plan SQA cubre desde la fase correspondiente al levantamiento de los
requerimientos hasta la fase de implementación del producto final en el cliente.
Los productos establecidos que tendrán revisiones son los siguientes:
1. Especificación de los Requerimientos (ERS)
2. Descripción de la Arquitectura del sistema
3. Estándares de Documentación de Usuario
4. Plan de Verificación y Validación
5. Plan del Proyecto
6. Plan de la Configuración
7. Plan de Desarrollo
8. Plan de Implementación
9. Informe final del proyecto
Actividades de calidad a realizarse
Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar, los estándares a
seguir, los productos a revisar, los procedimientos a seguir en la elaboración de los distintos
productos y los procedimientos para informar de los defectos detectados a sus responsables y
realizar el seguimiento de los mismos hasta su corrección.
ACTIVIDAD
ENTREGABLE
Realizar el plan SQA
Plan SQA
Identificar las propiedades de calidad
Propiedades de calidad
Evaluar la calidad de los productos
Informe de revisión SQA
Revisar el ajuste al proceso
Informe de revisión SQA
Realizar revisión técnica formal
Informe de revisión técnica formal
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 9 de 39
Plan de SQA
SI-Admin Clinic
Evaluar y ajustar el plan SQA
Documento de evaluación y ajuste del plan
SQA
Realizar la entrega semanal
Entrega semanal de SQA
Realizar evaluación final de SQA
Evaluación final SQA
Reuniones de apoyo a la calidad
No aplica
Las actividades que se realizarán para llevar a cabo el proyecto correspondiente al sistema de
información web para administrar la información de la clínica de salud de la ciudad de Bogotá
son:

Evaluar los requerimientos

Evaluar el diseño del software

Revisar cada producto

Revisar el ajuste al proceso

Evaluar las pruebas de módulos implementados

Evaluar el proceso de acciones correctivas

Evaluar la administración de la configuración

Realizar Revisión Técnica Formal (RTF)

Asegurar que las desviaciones son documentadas.
Evaluar los requerimientos
El análisis de requerimientos establece un mutuo acuerdo entre el equipo del proyecto de
software y el cliente. Se deberá mantener y establecer un acuerdo con el cliente para realizar el
análisis de requerimientos del sistema.
Es por esto que se debe tener una línea de comunicación abierta y fiable con el cliente, con la
cual los requerimientos del software sean acordes a los estándares de calidad y a las
expectativas y demandas del cliente.
Las actividades del personal de calidad en esta tarea son:
1. Revisar los requerimientos para determinar si son claros y consistentes.
2. Verificar que los cambios en el documento de requerimientos del sistema, sean
seguidos, revisados y comunicados al equipo de desarrollo.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 10 de 39
Plan de SQA
SI-Admin Clinic
3. Verificar que los compromisos con el cliente sean documentados, y comunicados al
equipo de desarrollo.
4. Verificar que los procesos descritos para definir, documentar y localizar requerimientos
se lleven a cabo.
5. Verificar que los requerimientos están documentados, administrados, controlados y
seguidos (de preferencia mediante una matriz de rastreo).
El resultado de esta tarea se documentará usando el Formato del proceso de auditoría y se
entregará al administrador del proyecto. Las recomendaciones correctivas realizadas por el SQA
requieren la disposición del administrador del proyecto.
Evaluar el diseño del software
El objetivo del proceso de diseño del software es tomar decisiones sobre el comportamiento del
diseño del sistema. Se tendrá que tomar en cuenta la arquitectura del sistema dividiendo el
sistema en subsistemas. El nivel de detalle del diseño debe ser tal que el código de los módulos
pueda ser realizado por otra persona que no sea su diseñador original.
Esto con el fin de prever futuras inspecciones y evaluaciones al diseño del software, para que
pueda ser manipulado por terceros sin la necesidad de acudir a la persona que lo elaboro en
primer lugar.
Las actividades del SQA en esta tarea son:
1. Verificar que los procesos de diseño de software sigan los estándares determinados.
2. Verificar que todos los requerimientos estén presentes en el diseño.
3. Verificar que el diseño se encuentre bajo la administración de la configuración.
4. Revisar y auditar el contenido de los documentos de diseño del sistema.
5. Si se encuentran no cumplimientos de los estándares establecidos, determinar las
acciones correctivas.
El resultado de esta tarea se documentará usando el Formato del proceso de auditoría y se
entregará al administrador del proyecto. Las recomendaciones correctivas realizadas por el SQA
requieren la disposición del administrador del proyecto.
Revisar cada producto
En esta actividad se revisan los productos que se definieron como claves para verificar en el Plan
de calidad.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 11 de 39
Plan de SQA
SI-Admin Clinic
Se debe verificar que no queden correcciones sin resolver en los informes de revisión previos, si
se encuentra alguna no resuelta, debe ser incluida en esta revisión. Se revisan los productos
contra los estándares, utilizando la checklist definida para el producto.
Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que
se hayan realizado las correcciones.
Como salida se obtiene el Informe de revisión de SQA, este informe debe ser distribuido a los
responsables del producto y se debe asegurar de que son conscientes de desviaciones o
discrepancias encontradas.
Revisar el ajuste al proceso
En esta actividad se revisan los productos que de definieron como claves para verificar el
cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en el
producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos durante todo
el ciclo de vida del software.
Se debe recoger la información necesaria de cada producto, buscando hacia atrás los productos
previos que deberían haberse generado, para poder establecer los criterios de revisión y evaluar
si el producto cumple con las especificaciones.
Esta información se obtiene de los siguientes documentos:
Plan del Proyecto, Plan de la iteración, Plan de Verificación.
Antes de comenzar, se debe verificar en los informes de revisión previos que todas las
desviaciones fueron corregidas, si no fuese así, las faltantes se incluyen para ser evaluadas.
Como salida se obtiene el Informe de revisión de ajuste al Proceso, este informe debe ser
distribuido a los responsables de las actividades y se debe asegurar de que son consientes de
desviaciones o discrepancias encontradas.
Evaluar las pruebas de módulos implementados
En esta etapa, las pruebas de integración combinan individualmente componentes ya
encontrados, realizando las pruebas pertinentes para garantizar la calidad de los diferentes
módulos incorporados en el sistema de información.
Garantizando que los procesos que se llevaran a cabo en la aplicación web cumplan con lo
establecido, según las especificaciones del cliente y las normas estándar de calidad de software.
Los encargados de las pruebas prestarán especial atención a:
1. El buen funcionamiento de las interfaces entre los componentes.
2. El flujo de información a través del sistema.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 12 de 39
Plan de SQA
SI-Admin Clinic
3. La satisfacción de los requisitos del sistema.
4. Verificar que las discrepancias descubiertas en la integración de software y pruebas de
rendimiento son identificadas, analizadas, documentadas, y corregidas.
5. Revisar el Plan de Pruebas de Software y que las descripciones de las pruebas de
software cumplan con los requerimientos.
6. Verificar que el software es probado.
7. Monitorear las actividades de pruebas.
8. Verificar que los encargados de las pruebas de unidad se apeguen al plan de pruebas.
9. Confiabilidad al momento de levar a cabo los procesos establecidos, además que se
pueda confiar en la información proporcionada por el software.
10. Facilidad de mantenimiento del software según las pruebas realizadas o discrepancias
encontradas.
Como Resultado de este proceso se obtiene un Informe de revisión de SQA que corresponderá
a la evaluación de ajuste al proceso, este informe debe ser distribuido a los responsables de las
actividades además del administrador del proyecto y se debe asegurar de que son conscientes
de desviaciones y discrepancias encontradas.
Evaluar el proceso de acciones correctivas
El proceso de acción correctiva cumplirá con los pasos para identificar el problema y la
corrección realizada durante el desarrollo del software, reportar el problema a la autoridad
apropiada, analizar el problema para proponer medidas de corrección, realizar la corrección
oportuna y completamente y registrar y dar seguimiento a cada problema. Los problemas bajo
este contexto incluyen errores de documentación, errores de software, no cumplimiento de
estándares y procedimientos.
Las actividades son las siguientes:
1. Revisar periódicamente el proceso de acción correctiva y sus resultados.
2. Realizar periódicamente correcciones basado en los diferentes resultados obtenidos en
los informes.
3. Seguimiento de procesos.
4. Observaciones de auditorías internas y externas.
5. Observaciones de los informes y sugerencias del personal.
6. Quejas del cliente.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 13 de 39
Plan de SQA
SI-Admin Clinic
Como Resultado de este proceso se obtiene un Informe de revisión de SQA que corresponderá
a la evaluación de ajuste al proceso, este informe debe ser distribuido a los responsables de las
actividades además del administrador del proyecto y se debe asegurar de que son consientes
de desviaciones y discrepancias encontradas.
Evaluar la administración de la configuración
La Administración de la configuración es la responsable de Identificar y documentar la
funcionalidad y las características físicas de los ítems de configuración, documentar los cambios
de control de los ítems de configuración, registrar y reportar la información necesaria para
administrar los ítems de configuración efectivamente, incluyendo el status de los cambios
propuestos y los status de implementación de cambios aprobados.
Las actividades a realizar son las siguientes:
1. Verificar que la configuración de los ítems de configuración cumplen con los estándares
establecidos de titulado, nomenclatura y descripción de los cambios.
2. Verificar que las líneas base ha sido establecida en el tiempo establecido por medio de
los estándares y procedimientos
3. Verificar que todos los interesados en el proyecto tengan conocimiento del plan de SQA.
4. Verificar la creación de versiones para el cliente y los usuarios.
5. Verificar el manejo, aprobación y seguimiento de las peticiones de cambio.
6. Verificar las versiones que se pretenden que coexistan.
Como Resultado de este proceso se obtiene un Informe de revisión de SQA que corresponderá
a la evaluación de ajuste al proceso, este informe debe ser distribuido a los responsables de las
actividades además del administrador del proyecto y se debe asegurar de que son conscientes
de desviaciones y discrepancias encontradas.
Realizar Revisión Técnica Formal (RTF)
El objetivo de la RTF es descubrir errores en la función, la lógica ó la implementación de cualquier
producto del software, verificar que satisface sus especificaciones, que se ajusta a los estándares
establecidos, señalando las posibles desviaciones detectadas. Es un proceso de revisión
riguroso, su objetivo es llegar a detectar lo antes posible, los posibles defectos o desviaciones
en los productos que se van generando a lo largo del desarrollo. Por esta característica se adopta
esta práctica para productos que son de especial importancia.
En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo.
Se debe convocar a la reunión formalmente a los involucrados, informar del material que ellos
deben preparar por adelantado, llevar una lista de preguntas y dudas que surgen del estudio del
producto a ser revisado.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 14 de 39
Plan de SQA
SI-Admin Clinic
La duración de la reunión no debe ser mayor a dos horas.
Como salida se obtiene el Informe de RTF.
Asegurar que las desviaciones son documentadas
Las desviaciones encontradas en las actividades y en los productos deben ser documentadas y
manejadas de acuerdo a un procedimiento establecido.
Se debe chequear que los responsables de cada plan los modifiquen cada vez que sea necesario,
basados en las desviaciones encontradas. Relaciones entre las actividades de SQA y la
planificación
Relaciones entre las actividades de SQA y la planificación
Actividad
Semana
Identificación de Propiedades de Calidad
1a5
Revisar la entrega
1 a 14
Elaboración del Plan de Calidad
2y4
Realizar Revisión Técnica Formal
5, 7, 9 y 11
Revisar el ajuste al proceso
3, 5, 7, 9, 11, 13, 14
Evaluación y ajuste del Plan de Calidad
9, 11
Evaluación final de Calidad
14
Responsables
Matriz de responsabilidades:
Actividades/
Responsables
Admón.
SQA
Admón.
proyecto
Asegura
miento
calidad
Desarrollo
y diseño
Pruebas
Riesgos
Admón.
requerimi
entos
Realizar el plan de aseguramiento de la calidad
Desarrollar y
documentar
el plan SQA
X
X
Revisar plan
SQA
X
X
Aprobar plan
SQA
X
X
X
X
X
X
Revisión de productos de software
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 15 de 39
X
Plan de SQA
SI-Admin Clinic
Revisión de
los productos
X
X
Aprobar el
software
X
X
X
X
X
X
X
X
X
X
X
Evaluar las diferentes herramientas de software
Evaluar las
herramientas
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
X
X
X
X
Planificación y seguimiento del proyecto
Documentar
el plan de
desarrollo
Revisar el
plan
X
X
X
Aprobar el
plan
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
X
X
X
Realizar el análisis de los requerimientos del software
Documentar
los rq
X
Rq de admón.
configuración
Revisar rq del
sistema
X
X
Aprobar los
rq
Evaluar el
análisis de los
rq
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
X
X
X
X
X
X
X
X
Proceso de diseño de software
Documentar
el diseño del
software
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
X
X
X
Página 16 de 39
Plan de SQA
SI-Admin Clinic
Asegurar la
calidad en el
diseño
X
Revisar el
diseño
X
Aprobar el
diseño
X
Evaluar el
proceso de
diseño
X
X
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
Implementación del software y pruebas unitarias
Correcciones
de código
Asegurar la
calidad en el
código
X
X
X
Revisar el
código
Pruebas
unitarias
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
X
X
X
X
Proceso de entrega de productos finales
Documentar
entrega
Revisar
documentaci
ón de entrega
X
X
X
Aprobar
documento
de entrega
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
X
Proceso de acciones correctivas
Seguir
proceso de
X
X
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
X
X
X
X
Página 17 de 39
X
Plan de SQA
SI-Admin Clinic
acciones
correctivas
Evaluar el
proceso de
acciones
correctivas
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
Realizar la administración a la configuración
Documentar
el plan de
aseguramient
o de calidad
Revisar el
plan
X
X
X
Aprobar el
plan
Realizar
seguimiento
al proceso
X
X
X
X
X
X
X
X
X
X
X
X
X
X
Documentar
procedimient
os de calidad
Evaluar el
plan
X
X
X
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
Proceso de auditoría y revisión
Realizar
auditorias
X
Evaluar el
proceso de
auditoria
X
Resolver
recomendaci
ones
obtenidas por
la auditoria
X
X
X
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 18 de 39
Plan de SQA
SI-Admin Clinic
Los responsables de llevar a cabo los controles de calidad serán los mismos encargados de SQA
y el Asistente SQA.
Luego de las revisiones de cada producto, se solicitará la atención del responsable del mismo
para su corrección de las acciones tomadas.
Para su corrección y comunicación de las acciones tomadas. Para la puesta en marcha de estas
actividades se deberá seguir el siguiente ciclo de prevención:
 Ejecutar una tarea

Realizar un control de revisiones, para decidir la aceptación o necesidad de
corrección de dicha tarea.

En caso de que en la revisión se presenten errores se realizara un análisis causal para
determinar el motivo de estos. Se analiza un determinado error, se establece una
hipótesis de su posible causa, se trata de deducir en qué momento se produjo y por
qué. Luego se deberá realizar la corrección del mismo y tomar una acción correctiva
con el fin de eliminar la causa del problema.

El resultado del análisis causal es ingresado a una base de datos para mantener un
registro y poder obtener métricas.

Se comienza nuevamente el ciclo ejecutando la tarea.
Documentación
Propósito
La documentación que describe el software y el desarrollo de software se creara y actualizara
periódicamente en todo el ciclo de desarrollo del software.
Los documentos mencionados en a la siguiente tabla deben estar bajo la administración de la
configuración, enviando una petición al administrador del proyecto cuando se realicen cambios,
para que este determine si el documento puede entrar a la línea base.
Documentación mínima requerida
La documentación mínima requerida para asegurar que la implementación lograra satisfacer los
requerimientos.
La documentación que describe el software y el proceso de desarrollo de software se creará y
actualizará periódicamente en todo el ciclo de desarrollo del software.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 19 de 39
Plan de SQA
SI-Admin Clinic
Los documentos mencionados en la siguiente tabla deben de estar bajo la administración de la
configuración, enviando una petición al administrador de aseguramiento de la calidad cuando
se realicen cambios, para que este determine si el documento puede entrar a la línea base.
Documento
Descripción
Especificación de requerimientos del
software
Describe los requisitos del sistema de
información web para administrar la
información de la clínica de salud, tanto
funcional como no funcional.
Plan SQA
Describe los planes y roles que adoptara cada
uno de los interesados en el desarrollo del
sistema de información web para administrar
la información de la clínica de salud.
Plan de pruebas del software
Describe los módulos a ser probados, así como
las pruebas que se utilizaran, entradas y salidas
esperadas para cada prueba.
Administración de la configuración
Describe la nomenclatura utilizada en el
proyecto, así como la forma en que se
determina la línea base.
Plan de desarrollo del software
Describe lo que se va a implementar, los
calendarios, actividades y responsabilidades
de los miembros del equipo de desarrollo.
Especificación de requerimientos del software
El documento de especificación de requerimientos deberá describir, de forma clara y precisa,
cada uno de los requerimientos esenciales del software además de las interfaces externas. El
cliente deberá obtener como resultado del proyecto una especificación adecuada a sus
necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y
a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se
haya acordado detallar con el cliente.
El documento de especificación de requerimientos deberá describir, de forma clara y precisa,
cada uno de los requerimientos esenciales del software además de las interfaces externas. El
cliente deberá obtener como resultado del proyecto una especificación adecuada a sus
necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo y
a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos que se
haya acordado detallar con el cliente.
La especificación debe:

Ser completa:
a. Externa, respecto al alcance acordado.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 20 de 39
Plan de SQA
SI-Admin Clinic
b. Internamente, no deben existir elementos sin especificar.

Ser consistente, no puede haber elementos contradictorios.

Ser no ambigua, todo término referido al área de aplicación debe estar definido en un
glosario.

Ser verificable, debe ser posible verificar siguiendo un método definido, si el producto
final cumple o no con cada requerimiento.

Estar acompañada de un detalle de los procedimientos adecuados para verificar si el
producto cumple o no con los requerimientos.

Incluir requerimientos de calidad del producto a construir.
1. Funcionalidad: Asegurar que las personas saben utilizar las funciones del software para
cumplir sus objetivos.
1.1. Adecuación a las necesidades: El producto a construir debe satisfacer la necesidad
o problemática principal del cliente. Este aspecto debe darse en todos los
componentes o partes que constituyan dicho producto.
1.2. Interoperabilidad: El sistema de información manejará una interoperabilidad con
otros sistemas por lo que deberá utilizar y proponer interfaces conocidas.
1.3. Preciso: El sistema de información debe ser preciso en cuanto a los resultados
esperados.
1.4. Seguridad: El sistema podrá proteger la información contenida en él, además de los
datos que las personas o sistemas sin relación alguna puedan obtenerlos y
modificarlos.
2. Confiabilidad: Esta sería la habilidad que tiene un sistema o componente de realizar sus
funciones requeridas bajo condiciones especificas en periodos de tiempo determinados.
2.1. Tolerancia a fallos: El sistema de información para la clínica de salud debe
responder de manera aceptable ante faltas en la programación. Este aspecto debe
ser considerado en todos los componentes y partes del sistema.
2.2. Efectividad en sus tareas: el sistema de información deberá cumplir con las tareas
que el usuario quiera realizar, cuando el así lo requiera.
3. Usabilidad: Este aspecto se refiere a la calidad de la experiencia que tiene un usuario
cuando interactúa con un producto o sistema.
3.1. Comprensible: Desde el punto de vista interno, nos ayudará a lograr los aspectos de
calidad la evolución y la verificación. Además, se debe tener especial atención en la
interfaz del cliente.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 21 de 39
Plan de SQA
SI-Admin Clinic
3.2. Operable: El sistema debe ser operable, es decir, las funciones que se especifiquen
en el sistema deben funcionar de manera correcta para una mejor usabilidad por
parte de los administradores de la clínica.
3.3. Asistencia: El sistema debe plantear la ayuda que se le entrega a los usuarios para
apoyarlos cuando deban enfrentar los posibles errores que cometan al usar el
sistema.
3.4. Encontrable: los Sitios Web deben ser navegables y permitir que los usuarios
puedan encontrar lo que necesitan.
3.5. Creíble: la credibilidad es uno de los factores más importantes de tener en cuenta y
por ello se deben revisar los elementos de diseño que afectan la confianza que nos
tienen los usuarios.
3.6. Útil: es necesario preguntarnos si nuestros productos y sistemas son útiles, y aplicar
nuestro conocimiento para definir soluciones innovadoras que apoyan la utilidad.
4. Mantenibilidad: Este aspecto de calidad es fundamental dado que nuestro producto de
software debe ser capaz de que se le realicen modificaciones luego de su entrega para
agregarle características que no estaban dentro del alcance del proyecto.
Es por ello que se identifican los siguientes atributos que deben involucrarse dentro de la
mantenibilidad del sistema:
4.1. Analizable: El software debe ser capas de ser diagnosticado di hay deficiencias o
fallos e identificar las partes que deben ser cambiadas.
4.2. Modificable: El sistema de información al ser modificado, este no debe presentar
alteraciones en la información y mucho menos en la funcionalidad.
4.3. Estable: El software deberá evitar efectos inesperados debido a modificaciones del
software.
4.4. Verificable: El software debe ser valido al momento de realizársele pruebas.
4.5. Estabilidad: Evitar efectos inesperados debido a modificaciones del software.
5. Fiabilidad: Un aspecto en el cual es software debe tener la habilidad para mantenerse
funcionando dentro de las condiciones normales.
5.1. Madurez: el sistema de información debe poder evitar fallos como resultado de
fallos anteriores en el sistema.
5.2. Recuperable: El sistema de información debe ser capaz de restablecer el nivel de
prestaciones especificados y de recuperar datos afectados en el fallo.
Estos aspectos deben cuidarse y considerarse en cada uno de los componentes del producto
software, prestando atención al código generado.
Cada uno de estos atributos debe cumplir con las normas y regulaciones aplicables a cada uno.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 22 de 39
Plan de SQA
SI-Admin Clinic
Descripción del diseño del software
El documento de diseño especifica como el software será construido para satisfacer los
requerimientos del cliente.
Deberá describir los componentes y subcomponentes del diseño del software, incluyendo
interfaces internas. Este documento deberá ser elaborado primero como Preliminar y luego será
gradualmente extendido hasta llegar a obtener el Detallado.
El cliente deberá obtener como resultado del proyecto el diseño de un producto de software
que cubra aquellos aspectos que se haya acordado con el cliente incorporar al diseño, en función
de la importancia que estos presenten y de sus conexiones lógicas.
El diseño debe:

Corresponder a los requerimientos a incorporar:
a. Todo elemento del diseño debe contribuir a algún requerimiento.
b. La implementación de todo requerimiento a incorporar debe estar contemplada en
por lo menos un elemento del diseño.
c. Describir estructuras que residen dentro del software.
d. Uso de características de flujos de información, relacionándolos en un mapeo
dentro de la estructura del programa.

Ser consistente con la calidad del producto
Plan de Verificación & Validación
El Plan de verificación y de validación deberá identificar y describir los métodos a ser utilizados
en:

La verificación de que:
a. Los requerimientos descritos en el documento de requerimientos han sido
aprobados por una autoridad apropiada.
b. El diseño expresado en el documento de diseño esta implementado en código.
c. El diseño expresado en el documento de diseño esta implementado en el código.

Validar que el código, cuando es ejecutado, se adecua a los requerimientos expresados
en el documento de requerimientos.
Adicionalmente la validación es para demostrar que el producto lograr satisfacer su uso
esperado cuando sea puesto en funcionamiento.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 23 de 39
Plan de SQA
SI-Admin Clinic
Reporte de verificación y validación
Estos documentos deben especificar los resultados obtenidos de la ejecución de los procesos
descritos en el plan de verificación y validación.
Documentación de usuario
La documentación de usuario debe especificar y describir los datos y entradas de control
requeridos, así como la secuencia de entradas, opciones, limitaciones de programa y otros ítems
necesarios para la ejecución exitosa del software.
Todos los errores deben ser identificados y las acciones correctivas descritas.
Un elemento muy importante de consulta para toda aquella persona que va a usar el programa
por primero vez o que trata de saber si el programa servirá a sus objetivos. Igualmente es útil
para usuarios que ya realizan un manejo básico y quieren profundizar hacia un conocimiento
avanzado.
Como resultado del proyecto el cliente obtendrá una documentación para el usuario de acuerdo
a los requerimientos específicos del proyecto.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 24 de 39
Plan de SQA
SI-Admin Clinic
Plan de Gestión de configuración
El objetivo del SQA en esta área es asegurar que se realizan las actividades de gestión de
configuración establecidas en el Plan de Configuración y que se realizan tal como están
establecidas en el proceso.
El Plan de gestión de configuración debe contener métodos para identificar componentes de
software, control e implementación de cambios, y registro y reporte del estado de los cambios
implementados.
La Gestión de Configuraciones permite controlar el sistema como producto global a lo largo de
su creación, obtener informes sobre el estado de desarrollo en que se encuentra y reducir el
número de errores durante el mismo, lo que se traduce en un aumento de calidad del proceso
de desarrollo y de mejora de la productividad en la organización.
La gestión de configuración facilita además el mantenimiento del sistema, aportando
información precisa para valorar el impacto de los cambios solicitados y reduciendo el tiempo
de implementación de un cambio, tanto evolutivo como correctivo.
Propósito
Controlar la entrega y el cambio de los elementos a través del ciclo de vida del sistema.
Almacenar el estado de los elementos y de las peticiones de cambio.
Establece y mantiene la integridad de los productos de software a través del ciclo de vida del
proceso de software. Proporcionar además visibilidad sobre los procesos utilizados por el
proyecto de software y sobre los productos que genera.
Resumen
La Gestión de Configuración, en resumen, identifica los elementos de un proyecto de desarrollo
de software (especificaciones, requisitos, arquitecturas, código, planes, etc.) proporcionando el
control de los elementos identificados y la generación de informes de estado de la configuración,
consiguiendo, al mismo tiempo, claridad de gestión, al asignar responsabilidades al personal
encargado de las tareas de control a lo largo del ciclo de vida del producto.
Esto debido a que es uno de los procesos clave para toda la organización década a la ingeniería
del software, posibilitando una mejor organización del desarrollo y mantenimiento, producto,
facilitando el resto de procesos de producción.
Organización, Responsabilidades
Se designará a un integrante del grupo para la administración de gestión de versiones, el cual se
encargará de administrar y dar los permisos en el gestor. Pudiendo cualquier integrante
solicitarle al grupo algún cambio para que el mismo estudie su necesidad.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 25 de 39
Plan de SQA
SI-Admin Clinic
Como parte de las actividades del responsable de SQA se revisarán los productos que se
consideren relevantes para la calidad del producto y del proceso.
Herramientas, Entorno, e Infraestructura
Se utilizará la herramienta de Gestión de Configuraciones (CGS) GitHub y TortoiseSVN. Este
maneja ficheros y directorios a lo largo del ciclo de vida del proyecto. Los ficheros se almacenan
en un repositorio central, recordando todos los cambios que se hayan realizado, permitiendo a
los integrantes del grupo poder recuperar versiones anteriormente guardadas, examinar la
historia de cuándo y cómo fueron modificados los datos, quien hizo los mismos y así poder
coordinar el trabajo.
Siendo la misma especialmente útil para los documentos revisados frecuentemente, como el
código fuente, la documentación, etc., como así también llevar un balance histórico de las
diferentes versiones del sistema.
Forma de trabajo
Durante el proceso de gestión de configuración se utilizará la herramienta GitHub para el control
de versiones del producto. Cuando algún miembro haga una modificación en el proyecto, deberá
acceder al repositorio en donde está alojada esta aplicación para realizar la incorporación de la
parte modificada en la rama principal del proyecto, teniendo el resto del equipo de desarrollo
la última versión actualizada al realizar la actualización del proyecto desde Git. Esta gestión de
acceso al servidor para la actualización se hará mediante la herramienta Tortoise para los
documentos y el GitHub de escritorio para el código fuente.
Control de Cambios
Se efectúa una solicitud de cambio utilizando el Formulario de Pedido y Detección de Cambio.
Especifica los procedimientos para solicitar un cambio a una línea base y la documentación
necesaria.
El mismo contiene:
1. Nombre y versión del Elemento de Configuración de Software a cambiar.
2. Nombre del peticionario.
3. Fecha de petición
4. Necesidad del cambio
5. Descripción del cambio pedido
6. Prioridad
7. Estado
8. Fecha del cambio
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 26 de 39
Plan de SQA
SI-Admin Clinic
Esto deberá ser realizado gracias a los mecanismos para solicitar los cambios, para aprobar o
rechazar las solicitudes de cambio, además de el seguimiento de los cambios además de gestión
de problemas.
Reportes y Auditorias
Estas auditorías son para verificar la consistencia del código versus el documento de diseño,
especificaciones de interfase, implementaciones de diseño versus requerimientos funcionales,
requerimientos funcionales versus descripciones de testeo
El personal de calidad reportara el resultado de las auditorias y las recomendaciones
proporcionadas. Estos reportes se usan para asegurarse que el proceso:
Auditoria Funcional: Cuyo objetivo es comprobar que se han completado todas las pruebas
necesarias para el / los ECS auditados, y que, teniendo en cuenta los resultados de los test, se
puede afirmar que el / los ECS satisfacen los requisitos que se impusieron sobre él.
Revisión formal de certificación: Cuyo objetivo es certificar que el / los ECS se comportan
correctamente en su entorno operativo.
Otros documentos
Plan del proyecto
El plan de gestión de proyecto debe describir la planificación de forma completa del proyecto,
de manera que pueda desarrollarse de forma controlada. Debe analizar su factibilidad, definir el
alcance, describir las actividades de gestión que deben ser llevadas a cabo durante el proceso
de desarrollo, definir mecanismos de control y ajuste para las distintas áreas del proyecto,
establecer las líneas de trabajo, distribución de recursos humanos juntos con sus
responsabilidades y cronograma de trabajo. Además, debe analizar los riesgos del proyecto con
estrategias de mitigación, controles y planes de contingencia.
Plan de desarrollo
El plan de desarrollo debe describir la planificación de forma completa de la fase de desarrollo
del Sistema de Software, describiendo las actividades que se realizaran, su duración y quienes
son los responsables.
Estándares, prácticas, convenciones y métricas
Identificar los estándares, prácticas, convenciones y métricas que serán aplicadas. Indicar como
será monitoreado y asegurado el cumplimiento con estos ítems:
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 27 de 39
Plan de SQA
SI-Admin Clinic
El IEEE “Standard Glosary of Software Engering Terms” define como métrica: “una medida
cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado”.
Las métricas son una herramienta poderosa y fundamental para el trabajo en SQA. Su aporte
fundamental son las medidas preventivas que pueden surgir a raíz de su estudio. Sin duda
aportan conclusiones que muchas veces no se aprecian a simple vista y que ayudan a mejorar la
eficiencia del grupo de trabajo y la calidad de los productos. Aportan un caudal de información
para hacer controles estadísticos de la calidad. Además, cabe resaltar que nunca debe dejarse
de buscar nuevas métricas de acuerdo a las nuevas variaciones y tendencias de las estadísticas.
Objetivos
Existen dos objetivos importantes que se persiguen dentro del programa de métricas:
1. Documentar las metas a la hora de establecer un programa de métricas. Esto tiene
sentido a la hora de decidir exactamente qué debe lograrse antes de gastar recursos
estableciendo un programa de este tipo.
2. Identificar la información (la métrica) necesaria para lograr estas metas y establecer el
marco de referencia de donde puede ser obtenida.
3. Medir la calidad de análisis y modelos de desafío, el código fuente y los casos de prueba
que se han creado al aplicar la ingeniería del software.
4. Identificar y medir los errores y defectos. Estas medidas proporcionan una indicación de
la efectividad de las actividades de control y de la garantía de calidad.
El cometido de los ocho pasos es crear un proceso a través del cual un programa corriente de
métrica puede ser utilizado como una herramienta estratégica de gestión.
Métricas de proceso
Se recopilan de todos los proyectos y durante un largo periodo de tiempo
Caracterizados por:
 Control y ejecución del proyecto.

Medición de tiempos de las fases.
Para este proyecto se trabajará con las siguientes métricas del proceso:
 Costo de remoción de defectos

Cantidad de código rehusado

Distribución de esfuerzo por fase

Efectividad para remover defectos entre fases
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 28 de 39
Plan de SQA
SI-Admin Clinic

Soporte de herramientas para procesos propuestos
Métricas de proyecto

Permiten evaluar el estado del proyecto.

Permiten seguir la pista de los riesgos.
Para este proyecto se trabajará con las siguientes métricas del proyecto:
 Cantidad de puntos de función liberados por unidad de tiempo

Costo del desarrollo

Costo del soporte

Horas trabajadas

Tiempo (calendario) transcurrido

Distribución del esfuerzo por fase

Cambios sobre requerimientos durante el desarrollo

Cambio sobre requerimientos en operación

Origen de los cambios sobre requerimientos

Cronograma Vs Estimado

Costo sobre valor agregado

Porcentaje de requerimientos implementados por unidad de tiempo
Las métricas del proyecto permiten que un gestor del proyecto de software:

Valore los riesgos de un proyecto en curso

Rastree los riesgos potenciales

Descubra las áreas problema

Ajuste el flujo de trabajo o las tareas

Evalué la habilidad del equipo del proyecto para controlar la calidad de los productos
de software.
Métricas de producto

Se centran en las características del software y no en cómo fue producido.

También son productos los artefactos, documentos, modelos, y componentes que
conforman el software.

Se miden cosas como el tamaño, la calidad, la totalidad, la volatilidad, y el esfuerzo
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 29 de 39
Plan de SQA
SI-Admin Clinic
Para este proyecto se trabajará con las siguientes métricas del producto:
 Puntos de Caso de Uso

Puntos de función

Complejidad de diseño (acoplamiento)

Complejidad de código

Métodos por clase

Profundidad y ancho de jerarquías

Cantidad de objetos y cantidad de relaciones de colaboración diferentes

Volatibilidad de componentes

Complejidad de despliegue

Densidad de defectos

Tipo y origen de defectos

Cantidad de problemas reportados

Tiempo transcurrido entre fallas

Tiempo esperado para la siguiente falla

Tiempo requerido para reparar

SLOC

Facilidad de aprendizaje de uso
Estándar de documentación
Como estándares de documentación se definirán dos documentos:
 Estándar de documentación técnica

Estándar de documentación de usuario.
La documentación técnica del producto debe:

Ser adecuada para que un grupo independiente del de desarrollo pueda encarar el
mantenimiento del producto.

Incluir fuentes, Modelos de Casos de Uso, Objetos de diseño.
Para la escritura de documentos se han definido plantillas para ser utilizadas en la elaboración
de entregables.
En estas plantillas se definen:
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 30 de 39
Plan de SQA
SI-Admin Clinic

Encabezado y pie de página.

Fuente y tamaño de fuente para estilo normal.

Fuente y tamaño de fuente para los títulos a utilizar.

Datos mínimos que se deben incluir: fecha, versión y responsables.
Estándar de verificación y prácticas
Se utilizarán las prácticas definidas en el documento correspondiente al plan de verificación y
validación especificado anteriormente.
Como estándar se utiliza el documento de: Std 1012-1986 IEEE Standard for Software
Verification and Validation Plans.
Otros Estándares
Estándar de documentación en general
Para la elaboración del documento se han definido plantillas para todos los documentos a
realizar. En ellos se definen:

Fuente: Calibri - Tamaño: 11 - Color: Negro - Estilos: Normal, Titulo1, Titulo2, Titulo3,
Titulo4 hasta el nivel que sea necesario.

Cada documento debe contar con una carátula al principio que debe contener:
a. Título explicativo del contenido del documento.
b. Versión del Documento.
c. Historial de versiones, que incluye el número de versión, la fecha, Asunto de la
modificación, Responsable que la realizó.
Se observa, que la versión del documento debe coincidir con el último campo de esta tabla.

Índice del contenido del documento y por consiguiente todas las páginas deben estar
numeradas.
Es deseable, que incluya al comienzo cual es el objetivo del documento.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 31 de 39
Plan de SQA
SI-Admin Clinic
Estándar de documentación en técnica
Por documentación Técnica se entiende Modelo de Dominio, Diagrama de Casos de Uso,
Diagramas de Sistema en general. En el documento "Estándar de documentación Técnica" se
define el programa de software a utilizar y algunas convenciones.
Estándar de implementación
Como ya hemos mencionado, el producto de software a construir se utilizará como prueba de
concepto por parte del cliente, y es de gran importancia su mantenibilidad, compresión,
evolución, y aprendizaje. Es por ello, que debemos seguir las recomendaciones de
implementación que el Cliente utiliza, para lograr cumplir con estos atributos de calidad.
Otro factor de Calidad relevante, como ya mencionamos, es la interoperabilidad, por lo que tal
documento define las convenciones necesarias para realizar de forma correcta la comunicación
con el Sistema.
Las convenciones de implementación se definen en el documento "Estándar de
Implementación" y se solicita especial atención del mismo por parte del equipo de
desarrolladores.
Revisiones y auditorías
Objetivo
Definición de las revisiones y auditorías técnicas y de gestión que se realizarán, especificando
cómo se llevarán a cabo dichas revisiones y auditorías.
Requerimientos mínimos
Como mínimo deberán revisarse todas las entregas semanales, basado en los estándares
definidos anteriormente. Estas revisiones serán realizadas por el responsable del plan SQA y/o
el asistente del plan.
Se especifican las revisiones y auditorías que deben realizarse como mínimo, así como la agenda
para la realización de las mismas, especificación de requerimientos, modelo de diseño y
descripción de la arquitectura, plan de verificación y validación, plan de gestión del proyecto,
plan de gestión de configuración, diseño vs. Especificación de requerimientos, implementación
vs. Diseño, verificación vs. Especificación de requerimientos.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 32 de 39
Plan de SQA
SI-Admin Clinic
Revisión de requerimientos
Esta revisión se realiza para asegurar que se ha cumplido con los requerimientos especificados
por el Cliente.
Revisión de diseño preliminar
Esta revisión se realiza para asegurar la consistencia y suficiencia técnica del diseño preliminar
del software.
Revisión de diseño crítico
Esta revisión se realiza para asegurar la consistencia del diseño detallado con la especificación
de requerimientos.
Revisión del plan de verificación & validación
Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados
en el plan.
Auditoría funcional
Esta auditoría se realiza previa a la liberación del software, para verificar que todos los
requerimientos especificados en el documento de requerimientos fueron cumplidos.
Auditoría física
Esta revisión se realiza para verificar que el software y la documentación son consistentes y
están aptos para la liberación.
Auditorías internas al proceso
Estas auditorías sirven para verificar la consistencia: del código versus el documento de diseño,
especificaciones de interfase, implementaciones de diseño versus requerimientos funcionales,
requerimientos funcionales versus descripciones de testeo.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 33 de 39
Plan de SQA
SI-Admin Clinic
Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las actitudes
identificadas en este Plan. Deben realizarse por una persona ajena al grupo de trabajo (en caso
de que sea posible).
Revisión del Plan de gestión de configuración
Esta revisión se realiza para asegurar la consistencia y completitud de los métodos especificados
en el Plan de gestión de configuración.
Revisión Post Mortem
Esta revisión se realiza al concluir el proyecto para especificar las actividades de desarrollo
implementadas durante el proyecto y para proveer recomendaciones.
Agenda
En esta sección se especifica la agenda para las revisiones y auditorías detalladas
correspondientes al proyecto del sistema de información web para la administración de la
información de la clínica de salud de la ciudad de Bogotá.
El calendario está sujeto a cambios que puedan originarse por desviaciones en el proyecto como
se explico anteriormente. Además, se observa que para la fase de construcción de productos de
investigación todavía no esta determinado, dado que aun se determino el mecanismo que se
seguirá durante la investigación.
Fase
Iteración
Semana
Actividad
Producto
2
1
8
Revisión RTF
Arquitectura
Revisión Producto
Plan de Proyecto
Revisión Producto
Revisión plan de gestión
de la configuración
Elaboración plan de
aseguramiento de
calidad
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Descripción de la
Arquitectura
Plan de la gestión de la
Configuración
Plan aseguramiento de la
calidad del software
Página 34 de 39
Plan de SQA
SI-Admin Clinic
Revisión de
requerimientos
Documentación
levantamiento de
requerimientos
Plan SQA
Revisión de gestión
9
Servicios
Avanzados
Interfaz de Usuario
Revisión RTF
Revisión de diseño
preliminar
Revisión del diseño
crítico
Revisión de Pruebas
Interfaz de Usuario
Salida: Informe de Revisión
de Pruebas.
Evaluar y Ajustar el
Plan de Calidad
Plan de aseguramiento de la
calidad
Plan SQA
Revisión de gestión
3
1
10
Revisión Producto
Revisión plan de gestión
de la configuración
Revisión Producto
Revisión de
Pruebas
Revisión de gestión
11
Revisión de
Pruebas
Revisión RTF
Revisión de Proceso
Revisión Productos
2
12
Manejo del
Ambiente
Controlado
Salida: Informe de Revisión
de Pruebas.
Plan SQA
Salida: Informe de Revisión
de Pruebas.
Servicios
Avanzados
Carga Masiva
Líneas de Investigación
Revisión RTF
Interfaz de usuario
Revisión de gestión
Plan SQA
Revisión Productos
Líneas de Investigación
Revisión de Pruebas
Salida: Informe de Revisión
de Pruebas.
Revisión de Proceso
Revisión Producto
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Descripción de la
Arquitectura
Plan de la gestión de la
Configuración
Carga Masiva
Modelo de Casos de Uso
Página 35 de 39
Plan de SQA
SI-Admin Clinic
Revisión de gestión
Auditoría interna al
proceso
Auditoria Funcional
13
Revisión de Proceso
Revisión de Proceso
Revisión de Proceso
Revisión Productos
Auditoria física
4
1
14
Plan SQA
Sistema de información
web, documentación y
requerimientos funcionales
y no funcionales
Sistema de información
web, requerimientos
funcionales y no funcionales
Atributos de calidad del
sistema de información
web
Carga Masiva
Ambiente modular del
sistema de información web
Líneas de Investigación
Producto software y
documentación
Revisión Post
Mortem
Otras revisiones
Revisión de documentación de usuario
Esta revisión se verifica que la documentación de usuario se encuentre en un nivel de
completitud, claridad y aplicación de uso. Aceptable para que, al momento de realizar la entrega
de esta a los usuarios finales como los administradores de la clínica, se maneje un estándar
universal para los conceptos entre los desarrolladores y le cliente final. Unificando los conceptos
que puedan ser mal interpretados por los usuarios, evitando que el mal entendimiento de la
documentación técnica y general del proyecto.
Revisiones técnicas formales RTF
Esta revisión tendrá por objetivo estudiar el desempeño de las pruebas realizadas para así
obtener de esa manera una noción de la correctitud del Sistema en base a los errores detectados
en las pruebas de una versión anterior.
Mecanismo:
Es un proceso de revisión riguroso, su objetivo es llegar a detectar lo antes posible, los posibles
defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. Por
esta característica se adopta esta práctica para productos que son de especial importancia.
En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 36 de 39
Plan de SQA
SI-Admin Clinic
Se debe convocar a la reunión formalmente a los involucrados, informar del material que ellos
deben preparar por adelantado, llevar una lista de preguntas y dudas que surgen del estudio del
producto a ser revisado.
Como salida se obtiene el Informe de RTF.
Verificación
La verificación se hará conforme a lo expresado en el documento "Plan de Verificación y
Validación", sin embargo, este punto puede seguir modificaciones luego de las revisiones
agendadas para la próxima semana.
Reporte de problemas y acciones correctivas
Luego de tener el Informe de la Revisión se solicitará, mediante el envío de un mail, la atención
de los responsables sobre el documento. Además, se les solicitará que comuniquen las
discrepancias encontradas en el informe tanto como las correcciones hechas en el producto.
Luego, se planifica una nueva revisión para corroborar las acciones correctivas hechas por los
responsables del producto.
Ante la detección de un error en la documentación se informará a él o los responsables de dicho
documento para que sea corregido. Esto se hará mediante el uso del grupo del proyecto. En caso
de que el error se repita reiteradas veces se tratara el tema en alguna reunión de grupo, ya sea
ordinaria o, en caso que la situación lo amerite, en una reunión extraordinaria.
Herramientas, técnicas y metodologías
Las técnicas a utilizar se definieron en el punto 3, además se utilizará listas de comprobación
como apoyo a estas técnicas. Dichas listas se realizarán para cada revisión y se tomarán como
base las definidas en el curso. Utilidades del sistema operativo, documentos de ayuda, checklist,
analizadores de estructuras, analizadores de código, auditorias de estándares, monitoreo de
rendimiento, software de desarrollo, matrices de seguimiento de software, pruebas de
generadores de casos.
Como lenguajes de programación: JAVA, HTML, CSS, J2EE.
Herramientas de diagramas UML: StartUML, DB Designer
Herramientas de bases de datos: MYSQL, Postgres o php myadmin.
Herramientas de Casos de Uso: StartUML, lucidchart.
Herramienta de procesamiento de texto: Microsoft Word
Herramientas de apoyo: Internet, Excel, Photoshop.
Herramientas de desarrollo: Netbeans, Dreamweaver, sublime text.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 37 de 39
Plan de SQA
SI-Admin Clinic
Gestión de riesgos
Los riesgos identificados, la estrategia de mitigación, monitoreo y plan de contingencia a ser
llevados a cabo, están definidos en el documento de "Gestión de Riesgos", con lo cual se podrá
hacer referencia a él.
Política de calidad
Consideramos que el producto esta en un nivel aceptable de calidad si se cumplen el cien por
ciento de los atributos de calidad identificados en la pagina 20: “Especificación de requisitos de
software”. Utilizando las métricas definidas en la pagina 27: “Estándares, practicas,
convenciones y métricas”, de forma tal de medir dichosos atributos, para así tener una noción
general de calidad del producto y consecuentemente solicitar las acciones definidas en la pagina
33: “revisiones y auditorias”, según el cronograma definido en la pagina 34: “Agenda”.
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 38 de 39
Plan de SQA
SI-Admin Clinic
Anexos
Formulario de Pedidos y Detección de Cambios
Formulario de Pedidos y Detección de Cambios
Fecha de Petición:
Nombre y
Elemento
Versión
del
Nombre del Solicitante:
Necesidad de Cambio:
Descripción
pedido:
del
cambio
Prioridad:
Estado:
Alta:
Normal:
Baja:
Muy Baja:
Fecha del cambio:
Identificador
versión:
de
la
nueva
Que fue afectado por este
cambio
Calidad en el desarrollo de software
ANYELO OBANDO ABRIL
Página 39 de 39