Plan SQA

Plan de SQA
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

Plan de SQA
Nombre del Proyecto
[Este documento es la plantilla base para elaborar el

documento Plan de SQA. La Calidad del Software tiene
como objetivo brindar la
Los textos que aparecen entre corchetes son explicaciones de
confianza de que el producto
que debe contener cada sección, los cuales se encuentran con
final logrará satisfacer los
estilo “PSI – Comentario”. Dichos textos se deben seleccionar
requisitos del cliente.
y sustituir por el contenido que corresponda en estilo “PSI -
Normal”. En el Plan de SQA se reflejan las
evaluaciones a realizar, los
Para actualizar la tabla de Contenido, haga clic con el botón
estándares a aplicar, los
derecho del ratón sobre cualquier línea del contenido de la
productos a realizar, los
misma y seleccione Actualizar campos, en el cuadro que
procedimientos a seguir en la
aparece seleccione Actualizar toda la tabla y haga clic en el
elaboración de los distintos
botón Aceptar.
productos y los procedimientos
Para actualizar los campos en Microsoft Word (los cuales se para informar de los defectos
muestran sobre un fondo gris cuando se selecciona], ir a detectados a sus responsables y
Archivo > Propiedades > Resumen y reemplazar los campos realizar el seguimiento de los
“Asunto” con el Nombre del Proyecto y “Autor” con el mismos hasta su corrección.
nombre del autor de este documento después ir a
Personalizar y actualizar el valor “Numero de Documento” en
la lista de propiedades del mismo dialogo, por el nuevo
número de versión. Posteriormente cerrar el dialogo
actualizar el documento seleccionando en el menú Editar >
Seleccionar todo o Ctrl–E y presionar F9, o simplemente dar
un clic sobre el campo y presionar F9. Esto debe repetirse
también en el índice, encabezado y pie de página, en todas
sus secciones.]
Calidad en el desarrollo de software Página 2 de 35

Plan de SQA
Nombre del Proyecto
Tabla de contenido
Propósito ...................................................................................................................................................... 5
Referencias ...................................................................................................................................................... 5
Gestión ......................................................................................................................................................... 6
Organización ................................................................................................................................................... 6
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 .................................................................................................................. 10
Evaluar las pruebas de módulos implementados ..................................................................................... 12
Evaluar el proceso de acciones correctivas .............................................................................................. 12
Evaluar la administración de la configuración ......................................................................................... 13
Responsables ................................................................................................................................................. 14
Documentación .......................................................................................................................................... 18
Propósito ....................................................................................................................................................... 18
Documentación mínima requerida ................................................................................................................ 19

Especificación de requerimientos del software ........................................................................................ 19
Descripción del diseño del software ......................................................................................................... 21
Plan de Verificación & Validación ............................................................................................................. 21
Reporte de verificación y validación ......................................................................................................... 22
Documentación de usuario ....................................................................................................................... 22
Plan de Gestión de configuración .................................................................................................................. 23

Propósito................................................................................................................................................... 23
Resumen ................................................................................................................................................... 23
Organización, Responsabilidades ............................................................................................................. 23
Herramientas, Entorno, e Infraestructura ................................................................................................ 23
Forma de trabajo ...................................................................................................................................... 24
Control de Cambios .................................................................................................................................. 24
Reportes y Auditorias ............................................................................................................................... 24
Otros documentos ......................................................................................................................................... 25
Plan del proyecto ........................................................................................................................................... 25
Plan de desarrollo.......................................................................................................................................... 25
Estándares, prácticas, convenciones y métricas .......................................................................................... 25
Objetivos ....................................................................................................................................................... 25
Métricas de proceso ...................................................................................................................................... 26
Métricas de proyecto .................................................................................................................................... 26

Plan de SQA
Nombre del Proyecto
Métricas de producto .................................................................................................................................... 27
Estándar de documentación ......................................................................................................................... 27
Estándar de documentación en general ........................................................................................................ 27
Estándar de documentación en técnica ........................................................................................................ 28
Estándar de implementación ........................................................................................................................ 28
Estándar de verificación y prácticas .............................................................................................................. 28
Revisiones y auditorías ............................................................................................................................... 29
Objetivo ......................................................................................................................................................... 29
Requerimientos mínimos ............................................................................................................................... 29

Revisión de requerimientos ...................................................................................................................... 29
Revisión de diseño preliminar .................................................................................................................. 29
Revisión de diseño crítico ......................................................................................................................... 29
Auditoría funcional ................................................................................................................................... 29
Auditoría física .......................................................................................................................................... 29
Auditorías internas al proceso .................................................................................................................. 30
Revisiones de gestión ............................................................................................................................... 30
Revisión del Plan de gestión de configuración ......................................................................................... 30
Revisiones técnicas formales RTF ............................................................................................................. 30
Revisión Post Mortem .............................................................................................................................. 30
Agenda ...................................................................................................................................................... 30
Otras revisiones ............................................................................................................................................. 32

Revisión de documentación de usuario .................................................................................................... 32
Verificación ................................................................................................................................................ 33
Reporte de problemas y acciones correctivas ............................................................................................. 33
Herramientas, técnicas y metodologías ...................................................................................................... 33
Gestión de riesgos ...................................................................................................................................... 34
Anexos........................................................................................................................................................ 35
Formulario de Pedidos y Detección de Cambios ........................................................................................... 35

Plan de SQA
Nombre del Proyecto
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 realicen como lo establece el modelo de ciclo de vida del
proyecto; y procedimientos para informar a los responsables de 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
[1]ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance Plans.

Plan de SQA
Nombre del Proyecto
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
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.
 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.

Plan de SQA
Nombre del 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.
3. Administración del proyecto: La administración del proyecto es la responsable de las

siguientes funciones:
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.

Plan de SQA
Nombre del Proyecto
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.
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.
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.
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.

Plan de SQA
Nombre del 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.
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.
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

Plan de SQA
Nombre del Proyecto
 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.
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.
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

Plan de SQA
Nombre del Proyecto
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.
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 documentara usando el Formato del proceso de auditoría y se

entregara al administrador del proyecto. Las recomendaciones correctivas realizadas por el SQA
Revisar cada producto
En esta actividad se revisan los productos que se definieron como claves para verificar en el Plan
de calidad.
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 la siguiente 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 concientes de desviaciones o
discrepancias encontradas.
Revisar el ajuste al proceso
En esta actividad se revisan los productos que se 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.

Plan de SQA
Nombre del Proyecto
Esta información se obtiene de los siguientes documentos:
Plan del Proyecto, Plan de la iteración, Plan de Verificación y Validación.
Antes de comenzar, se debe verificar en los informes de revisión previos que todas las
desviaciones fueron corregidas, si no es así, las faltantes se incluyen para ser evaluadas.
Como salida se obtiene el Informe de revisión de SQA correspondiente a la evaluación de ajuste

al Proceso, este informe debe ser distribuido a los responsables de las actividades y se debe
asegurar de que son concientes 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.
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.
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.

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

Plan de SQA
Nombre del Proyecto
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.

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.

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

Plan de SQA
Nombre del Proyecto
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. 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
ser 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
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/ Admón. Admón. Asegura Desarrollo Pruebas Riesgos Admón.
Responsables SQA proyecto miento y diseño requerimi
calidad entos
Realizar el plan de aseguramiento de la calidad
Desarrollar y X X
documentar
el plan SQA
Revisar plan X X X X X X X
SQA

Plan de SQA
Nombre del Proyecto
Aprobar plan X X
SQA
Revisión de productos de software
Revisión de X X X X X X X
los productos
Aprobar el X X
software
Evaluar las diferentes herramientas de software
Evaluar las X X X X X X X
herramientas
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Planificación y seguimiento del proyecto
Documentar X
el plan de
desarrollo
Revisar el X X X X X X X
plan
Aprobar el X
plan
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Realizar el análisis de los requerimientos del software
Documentar X
los rq
Rq de admón. X
configuración
Revisar rq del X X X X X X X
sistema
Aprobar los X X
rq
Evaluar el X
análisis de los
rq
Resolver X
recomendaci
ones

Plan de SQA
Nombre del Proyecto
obtenidas por
la auditoria
Proceso de diseño de software
Documentar X X
el diseño del
software
Asegurar la X
calidad en el
diseño
Revisar el X X X
diseño
Aprobar el X
diseño
Evaluar el X
proceso de
diseño
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Implementación del software y pruebas unitarias
Correcciones X
de código
Asegurar la X X
calidad en el
código
Revisar el X X
código
Pruebas X X X
unitarias
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Proceso de entrega de productos finales
Documentar X
entrega
Revisar X X X
documentaci
ón de entrega
Aprobar X
documento
de entrega

Plan de SQA
Nombre del Proyecto
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Proceso de acciones correctivas
Seguir X X X X X X X
proceso de
acciones
correctivas
Evaluar el X
proceso de
acciones
correctivas
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Realizar la administración a la configuración
Documentar X
el plan de
aseguramient
o de calidad
Revisar el X X X X X X X
plan
Aprobar el X
plan
Realizar X X X X X X X
seguimiento
al proceso
Documentar X
procedimient
os de calidad
Evaluar el X
plan
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Proceso de auditoría y revisión
Realizar X X X X X X
auditorias

Plan de SQA
Nombre del Proyecto
Evaluar el X
proceso de
auditoria
Resolver X
recomendaci
ones
obtenidas por
la auditoria
Los responsables de llevar acabo los controles de calidad serán el Responsable de SQA y el
Asistente de SQA. Luego de las revisiones de cada producto, se solicitará la atención del
responsable del mismo
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
Identificación de la documentación relativa a desarrollo, Verificación & Validación, uso y
mantenimiento del software. Establecer como los documentos van a ser revisados para
chequear consistencia: se confirman criterio e identificación de las revisiones.

Plan de SQA
Nombre del Proyecto
Documentación mínima requerida

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.
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 Describe los requisitos del sistema de
software 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
Los requerimientos de calidad del producto correspondiente al sistema de información web para
administrar la información de la clínica de salud r son considerados dentro de atributos
específicos del software que tienen incidencia sobre la calidad en el uso. Cada uno de estos
atributos se debe cumplir bajo las normas aplicables para cada uno.
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:

Plan de SQA
Nombre del Proyecto
 Ser completa:
a. Externa, respecto al alcance acordado.
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
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.
2. Confiabilidad:
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.
3. Usabilidad:
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.
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.
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.

Plan de SQA
Nombre del Proyecto
Es por ello que se identifican los siguientes atributos que deben involucrarse dentro de la
mantenibilidad del sistema:
4.1. Analizable.
4.2. Modificable: al realizar modificaciones al sistema de información este no debe

presentar alteraciones en la información y mucho menos en la funcionalidad.
4.3. Estable.
4.4. Verificable.
Estos aspectos deben cuidarse y considerarse en cada uno de los componentes del producto
software, prestando atención al código generado.
Descripción del diseño del software
El documento de diseño especifica como el software será construido para satisfacer los
requerimientos.
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.
 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:

Plan de SQA
Nombre del Proyecto
a. Los requerimientos descritos en el documento de requerimientos han sido

aprobados por una autoridad apropiada.
b. Los requerimientos descritos en el documento de requerimientos son
implementados en el diseño expresado en el documento de diseño.
c. El diseño expresado en el documento de diseño esta implementado en código.
 Validar que el código, cuando es ejecutado, se adecua a los requerimientos expresados

en el documento de requerimientos.
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.
Como resultado del proyecto el cliente obtendrá una documentación para el usuario de acuerdo
a los requerimientos específicos del proyecto.

Plan de SQA
Nombre del Proyecto
Plan de Gestión de configuración

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.
Propósito
Realizar el Control 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.
Resumen
La Gestión de Configuración, identifica los elementos de un proyecto de desarrollo de software

(especificaciones, requisitos, arquitecturas, código, planes, entre otros.) 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.
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.
Herramientas, Entorno, e Infraestructura
Se utilizara 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 cuando y como 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, entre otros. Como así también llevar un balance histórico de
las diferentes versiones del sistema.

Plan de SQA
Nombre del Proyecto
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
Reportes y Auditorias
Se realizará las siguientes auditorias:
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.

Plan de SQA
Nombre del Proyecto
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ínea 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:
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
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.

Plan de SQA
Nombre del Proyecto
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
 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

Plan de SQA
Nombre del Proyecto
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
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
 Volatilidad 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
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:

Plan de SQA
Nombre del Proyecto
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.
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.
Estándar de verificación y prácticas

Se utilizaran 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.

Plan de SQA
Nombre del Proyecto
Revisiones y auditorías
Objetivo
Definir las revisiones y auditorias técnicas y de gestión que se realizaran, especificando como se
llevaran a cabo cada una de ellas.
Requerimientos mínimos
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.
Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió 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.
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. Esta
Auditoría la realizará un equipo integrado por el Responsable de SQA, Responsable de
Verificación, Arquitecto, Analista y un Implementador.
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.

Plan de SQA
Nombre del Proyecto
Auditorías internas al proceso
Estas auditorías son para verificar la consistencia: del código versus el documento de diseño,
especificaciones de interface, implementaciones de diseño versus requerimientos funcionales,
requerimientos funcionales versus descripciones de testeo.
Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las actividades
identificadas en este Plan. La revisión se hará cada fin de iteración por el Responsable de SQA.
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.
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.
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.
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á.

Plan de SQA
Nombre del Proyecto
Fase Iteración Semana Actividad Producto

2 1 8 Revisión RTF Arquitectura
Revisión Producto Plan de Proyecto
Descripción de la
Revisión Producto
Arquitectura
Plan de la gestión de la
Revisión plan de gestión
Configuración
de la configuración
Elaboración plan de
Plan aseguramiento de la
aseguramiento de
calidad del software
calidad
Revisión de Documentación
requerimientos levantamiento de
requerimientos
Revisión de gestión Plan SQA
9 Servicios
Revisión RTF
Avanzados
Revisión de diseño Interfaz de Usuario
preliminar
Revisión del diseño Interfaz de Usuario
crítico
Revisión de Pruebas Salida: Informe de Revisión
de Pruebas.
Evaluar y Ajustar el
Plan de aseguramiento de la
Plan de Calidad
calidad
3 1 10 Descripción de la
Revisión Producto
Arquitectura
Plan de la gestión de la
Revisión plan de gestión
Configuración
de la configuración
Manejo del
Revisión Producto Ambiente
Controlado
Revisión de Salida: Informe de Revisión
Pruebas de Pruebas.
Revisión de Salida: Informe de Revisión

11 Pruebas de Pruebas.
Servicios
Revisión RTF
Avanzados

Plan de SQA
Nombre del Proyecto
Revisión de Proceso
Carga Masiva
Revisión Productos Líneas de Investigación
Revisión RTF Interfaz de usuario
2 12 Revisión Productos Líneas de Investigación
Revisión de Pruebas Salida: Informe de Revisión

de Pruebas.
Carga Masiva
Modelo de Casos de Uso
Revisión Producto
Sistema de información
Auditoria interna al web, documentación y
proceso requerimientos funcionales
y no funcionales
Auditoria Funcional Sistema de información
13 web, requerimientos
funcionales y no funcionales
Atributos de calidad del
sistema de información
web
Carga Masiva
Revisión de Proceso Ambiente modular del
sistema de información web
Revisión Productos Líneas de Investigación
Auditoria física Producto software y

documentación
4 1 14 Revisión PostMortem
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

Plan de SQA
Nombre del Proyecto
que puedan ser mal interpretados por los usuarios, evitando que el mal entendimiento de la
documentación técnica y general del proyecto.
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.
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 realizaran para cada revisión y se tomaran 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 o Postgres
Herramientas de Casos de Uso: StartUML
Herramienta de procesamiento de texto: Microsoft Word
Herramientas de apoyo: Internet, Excel, Photoshop.
Herramientas de desarrollo: Netbeans, Dreamweaver.

Plan de SQA
Nombre del Proyecto
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".

Plan de SQA
Nombre del Proyecto
Anexos
Formulario de Pedidos y Detección de Cambios
Formulario de Pedidos y Detección de Cambios
Fecha de Petición:
Nombre y Versión del

Elemento
Nombre del Solicitante:
Necesidad de Cambio:
Descripción del cambio pedido:
Prioridad:
Estado:
Fecha del cambio:
Identificador de la nueva
versión:
Que fue afectado por este

cambio

Plan SQA

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Plan SQA

Caricato da

Copyright:

Formati disponibili

Plan de SQA

Sistema de información en ambiente web para

Calidad en el desarrollo de software

[Este documento es la plantilla base para elaborar el

Calidad en el desarrollo de software Página 2 de 35

Documentación mínima requerida ................................................................................................................ 19

Plan de Gestión de configuración .................................................................................................................. 23

Otros documentos ......................................................................................................................................... 25

Plan del proyecto ........................................................................................................................................... 25

Estándares, prácticas, convenciones y métricas .......................................................................................... 25

Métricas de proceso ...................................................................................................................................... 26

Métricas de proyecto .................................................................................................................................... 26

Calidad en el desarrollo de software Página 3 de 35

Métricas de producto .................................................................................................................................... 27

Estándar de documentación ......................................................................................................................... 27

Estándar de documentación en general ........................................................................................................ 27

Estándar de documentación en técnica ........................................................................................................ 28

Estándar de implementación ........................................................................................................................ 28

Estándar de verificación y prácticas .............................................................................................................. 28

Revisiones y auditorías ............................................................................................................................... 29

Requerimientos mínimos ............................................................................................................................... 29

Otras revisiones ............................................................................................................................................. 32

Reporte de problemas y acciones correctivas ............................................................................................. 33

Herramientas, técnicas y metodologías ...................................................................................................... 33

Gestión de riesgos ...................................................................................................................................... 34

Formulario de Pedidos y Detección de Cambios ........................................................................................... 35

Calidad en el desarrollo de software Página 4 de 35

[El software a realizar es un sistema de información modular en un ambiente web en el cual se

Con el sistema de información web para la administración de la información de la clínica de salud

 Mejorar la calidad y eficiencia en el control de la información de los pacientes de la

 Gestionar de manera más eficiente la información y utensilios de la clínica como las

 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

 Administrar la información de la infraestructura de la clínica como las habitaciones,

Calidad en el desarrollo de software Página 5 de 35

 Diseño del sistema de información web.

 Gestión del Proyecto establecido.

 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.

Descripción de la estructura organizacional:

1. Administrador del plan SQA: El administrador es el responsable de las siguientes

1.1. Establecer un programa de calidad para 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.

Calidad en el desarrollo de software Página 6 de 35

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

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

3. Administración del proyecto: La administración del proyecto es la responsable de las

3.3. Identificar los factores de calidad a ser implementados en el sistema de información

3.5. Asegurar que los factores de calidad sean implementados correctamente en el

3.6. Identificar, desarrollar y mantener los documentos de planeación del proyecto.

4.2. Implementar las prácticas de pruebas en el sistema de información web, procesos y

4.3. Realizar la implementación de la calidad en la realización de las pruebas de acuerdo

Calidad en el desarrollo de software Página 7 de 35

5.1. Realizar con calidad el diseño y la codificación del sistema de información de

5.4. Implementar el diseño, la arquitectura, el desarrollo, procesos y procedimientos

6. Administración de los riesgos: La administración de los riesgos es la responsable es el

6.1. Realizar el seguimiento a los riesgos identificados.