ModeloPlanCalidadSQAP PDF

PLAN DE SQA
EMPRESA TERASOFT
SQAP EMPRESA TERASOFT

Contenido
1. INTRODUCCION ......................................................................................................................... 3
1.1.
ANTECEDENTES ...................................................................................................................... 3
1.2.
OBJETIVOS ......................................................................................................................... 3
1.2.1.
OBJETIVO GENERAL ..................................................................................................... 3
1.2.2.
OBJETIVOS ESPECIFICOS .............................................................................................. 4
1.3.
MISION ........................................................................................ Error! Marcador no definido.
1.4.
VISION ......................................................................................... Error! Marcador no definido.
1.5.
POLITICAS DE CALIDAD ........................................................................................................... 4
1.6.
SLOGAN ....................................................................................... Error! Marcador no definido.
2.
PLAN DE ASEGURAMIENTO DE CALIDAD DE SOFTWARE .............................................................. 5

2.1.
PROPOSITO ........................................................................................................................ 5
2.1.1.
OBJETIVO .................................................................................................................... 5
2.1.2.
DESCRIPCIN .............................................................................................................. 5
2.1.3.
ALCANCE ..................................................................................................................... 5
3.
GESTION ................................................................................................................................ 6
3.1.
ORGANIZACIN .............................................................................................................. 6
3.1.1.1.
3.2.
ORGANIGRAMA DE SQA .................................................................................................. 7
3.3.
TAREAS .............................................................................................................................. 7
3.4.
RESPONSABILIDADES .......................................................................................................... 9
3.4.1.
RESPONSABILIDADES DEL GRUPO DE DESARROLLO ...................................................... 9
3.4.2.
RESPONSABILIDADES DEL CLIENTE ............................................................................... 9
3.4.3.
RESPONSABILIDADES DE LA SQA .................................................................................. 9
3.5.
4.
ORGANIZACIN DE LA SQA ...................................................................................... 6
EVOLUCIN DEL SQAP .............................................................. Error! Marcador no definido.
3.5.1.
Control De Cambio ............................................................ Error! Marcador no definido.
3.5.2.
CUANDO HACER MODIFICACIONES .................................... Error! Marcador no definido.
3.5.3.
IMPLANTACIN DE MODIFICACIONES ................................ Error! Marcador no definido.
3.5.4.
PUBLICACIN DEL SQAP .................................................... Error! Marcador no definido.
DOCUMENTACION ................................................................................................................... 10
4.1.2.
DESCRIPCIN DEL DISEO DEL SOFTWARE (DDS) ....................................................... 11
4.1.3.
PLAN DE VERIFICACIN Y VALIDACIN....................................................................... 13

4.1.4.
INFORMACIN DE VERIFICACIN Y VALIDACIN ........................................................ 15
4.1.5.
DOCUMENTACIN DE USUARIO ................................................................................ 18
5.
ESTANDARES, PRACTICAS Y CONVENCIONES ......................................................................... 19

5.1.
ESTNDAR DE CODIFICACIN ........................................................................................ 19
5.2.
ESTNDAR DE COMENTARIO ......................................................................................... 20
5.3.
RESPONSABLES DE VERIFICAR EL CUMPLIMIENTO .......................................................... 20
6.
REVISIONES Y AUDITORIAS ................................................................................................... 21
7.
GESTION DE CONFIGURACION .............................................................................................. 24
8.
INFORMACION DE PROBLEMAS Y ACCIONES CORRELATIVAS ................................................. 24
10.
HERRAMIENTAS, TECINAS Y METODOLOGIAS .................................................................... 26
11.
CONTROL DEL CODIGO...................................................................................................... 26
11.1.
CONTROL DE MEDIOS.................................................................................................... 27
11.2.
CONTROL DE SUMINISTRADORES Y SUBCONTRATOS..................................................... 28
12.
13.
RECOLECCION, MANTENIMIENTO Y RETENCION DE REGISTROS ......................................... 28

REFERENCIAS ....................................................................................................................... 28
1.
INTRODUCCION
Una de las principales fases dentro de la elaboracin de un proyecto es el Aseguramiento de la
Calidad del Software (SQA), es decir, un modelo sistemtico y planeado de todas las acciones
necesarias para proveer la confianza adecuada, segn los requerimientos tcnicos establecidos, de
cada producto e tem del proyecto. Un sinnimo del aseguramiento de la calidad del software es
aseguramiento del producto de software.
El plan de aseguramiento de la calidad del software (SQAP) define cuan adherido a estos
estndares se debe monitorear. El SQAP contiene una lista de comprobacin para las actividades que
se deben llevar a cabo para asegurar la calidad del producto. Para cada actividad, en las que tiene
responsabilidad el SQA, se debe crear un plan para su monitoreo.
En este documento se describen todos los planes y roles que tendr cada elemento de la
organizacin en el proceso de aseguramiento de la calidad del software.
1.1.
ANTECEDENTES
Todo producto de software busca satisfacer a cabalidad el propsito para el cual fue creado, estar
en sintona con el ambiente donde se va a aplicar, cumplir con los requerimientos que se le imponen,
adems de ser mantenible, confiable y estable; el logro de estos factores permite decir que se trata
de un software de calidad, las diversas caractersticas con las que se desea que cumpla un software
varan ampliamente.
Algunas tienen que ver con el usuario que interacta con el sistema, otra con el lder del proyecto
y diseadores, y otras que parecen ser muy abstractas y hasta indefinidas. En definitiva toda empresa
debe complacer a los clientes e ir ms all para entender a fondo sus necesidades presentes y futuras
a fin de sorprenderlos con productos y servicios que ni siquiera imaginen; una vez que son conocidas
estas necesidades deben ser traducidas en trminos cuantitativos y tangibles, este proceso no es
sencillo y requiere de la integracin de conocimientos de marketing, ingeniera de software,
documentacin y auditora informtica, para que las expectativas y las necesidades del consumidor
puedan ser satisfechas completamente.
El desarrollo de todos estos lineamientos recae en manos de un proceso denominado
Aseguramiento de la Calidad del Software (SQA) el cual se desempea mediante un plan (plan SQA)
que le permitir estructurarse por medio de actividades que conlleven al xito de la calidad del
proyecto del software, situacin en la que radica la importancia de la participacin de este plan en el
proceso.
1.2.
OBJETIVOS
1.2.1. OBJETIVO GENERAL

El desarrollo de un plan de aseguramiento de la calidad de software para la empresa.

1.2.2. OBJETIVOS ESPECIFICOS
Como empresa, se tienen los siguientes objetivos:
Definir los requerimientos de calidad a ser verificados.
Indicar los roles y responsabilidades de cada integrante del equipo y director del plan SQA
Indicar las partes del ciclo vida cubierto por el plan SQA as como las lneas de trabajo que
sern contempladas en el mismo.
Describir las tareas de calidad a realizar.
Especificar los documentos involucrados en el desarrollo del plan.
1.3.
POLITICAS DE CALIDAD
TERASOFT, como empresa de ingeniera de software, asume el compromiso formal de
desarrollar su actividad con los mayores estndares de calidad, adoptando un Sistema de Gestin
de la Calidad basado en la Norma ISO 9001:2008 para todos sus procesos, con el propsito de
mejorar su competitividad, satisfacer plenamente los requerimientos de sus clientes, afianzar su
participacin en el mercado nacional y que permitan actuar en el mercado internacional
La direccin considera esta poltica como elemento integral de sus negocios y se encarga
de su difusin, compresin y cumplimiento, fijando los siguientes lineamientos bsicos:
Suministrar productos tendientes al cero defecto.

Cumplir con las fechas de entrega pactadas con los clientes.
Mejorar los procesos y el sistema de gestin de calidad en forma continua.
Capacitar a todo su personal en base a sus necesidades y a las nuevas tecnologas,
incentivando su integracin.
Interpretar los requerimientos y expectativas del cliente, generando soluciones que
aporten valor.
Establecer una estrategia de mejora continua cuyos pilares son la planificacin,
ejecucin, verificacin en todos sus procesos.
Se deber buscar la certificacin en los estndares para lograr una mejor operacin,
calidad, productividad, innovacin y eficiencia en la operacin y en los productos que
generamos o distribuimos; no se debern buscar la certificacin por el simple
documento.

2.
2.1.
PLAN DE ASEGURAMIENTO DE CALIDAD

PROPOSITO
El propsito de este plan es especificar las actividades que se realizarn para asegurar la calidad
del software a construir. En l se detalla el producto que se va a revisar y los estndares, normas
o mtodos a aplicar, los mtodos y procedimientos que se utilizarn para revisar que la
elaboracin del producto se realice como lo establece el modelo de ciclo de vida del proyecto, y
procedimientos para informar a los responsables del producto los defectos encontrados y realizar
un seguimiento de dichos defectos hasta su correccin.
2.1.1. OBJETIVO
Definir un conjunto de normas y actividades con el fin de asegurar la calidad en el desarrollo de
software.
2.1.2. DESCRIPCIN
Calidad del software es el cumplimiento con los requisitos explcitamente establecidos y
documentados, la concordancia con los estndares de desarrollo aplicados y la agregacin de
requisitos implcitos que se espera de todo producto hecho por profesionales.
A travs de la implantacin del SQAP se pretende cumplir con los elementos de calidad de
software, los cuales son:
Correcto
Eficiente
Fiable
Facilidad de uso
Facilidad de mantenimiento
Seguridad e integridad
Portabilidad
Se pretende la aplicacin del SQAP para cualquier proyecto de software a desarrollarse por la
empresa.
2.1.3. ALCANCE
Este documento presenta enfoques a seguir de manera de asegurar al cliente la calidad deseada.
El alcance de este plan cubre todas las actividades involucradas en el proceso de desarrollo
dejando de lado la etapa de mantenimiento, la cual no ser parte del mismo. La meta del plan de
aseguramiento de la calidad es verificar que todo software y documentacin liberados cumplan
con todos los requerimientos tcnicos establecidos.
El SQAP cubre las fases del ciclo de vida de desarrollo de software. Ciclo de Vida de Desarrollo de
Software XP (Programacin Extrema)

FASES DE XP:
1 Fase: Planificacin del proyecto.

2 Fase: Diseo.
3 Fase: Codificacin.
4 Fase: Pruebas.
Los componentes del software se presentarn de acuerdo al campo de aplicacin del mismo, a
sus especificaciones y requerimientos. Se pretende implementar productos de software capaz de
responder a sus objetivos en cualquier condicin de funcionamiento y operacin, tener una
documentacin completa acerca del desarrollo del mismo con el fin de facilitar su mantenimiento.
3.
GESTION
Seguidamente se especifican los elementos que tienen influencia sobre la calidad del software,
como est conformada la lnea de gestin de calidad, de quien es la autoridad y responsabilidad por la
calidad del software.
3.1.
ORGANIZACIN
Gerente /
Management
Analista /
Developer
3.1.1.1.
SQA
Jefe de proyecto
/ tracker
Team QA
Jefe de
Desarrollo /
Coach
Desarrolladores /
Developer
Diseador /
Developer
Arquitecto de
software /
Developer
Tester
ORGANIZACIN DE LA SQA
Es la organizacin que se obtiene de las anteriores organizaciones. En la que se toman decisiones segn
las normas establecidas para luego liberar versiones sucesivas del SQAP para el desarrollo del software.

Tenemos la lista de la organizacin de SQA:
3.2.
Gerente Administrativo
Jefe de Departamento de Informtica
Director General
Experto en Proyectos
Director de equipo de Desarrollo
ORGANIGRAMA DE SQA
Jefe Administrativo
Jefe dpto. Informtica
Director General
Experto en proyectos
Director de Desarrollo
3.3.
TAREAS
La relacin de tareas asociadas con el ciclo de vida de desarrollo de software (se encuentra basadas en las
4 fases de XP) y las actividades de la SQA son las siguientes, las cuales se ejecutarn durante el desarrollo
del producto de software:
Las actividades de SQA definidas en el modelo de proceso son:

Actividad
Elaboracin del Plan de SQA
Identificar propiedades de Calidad
Evaluacin de la calidad de los productos
Revisar el ajuste al proceso
Entregable Asociado
Plan de SQA
Plan de SQA
Informe de revisin de SQA
Informe de revisin de SQA
Realizar Revisin Tcnica Formal

Evaluar y ajustar el Plan de SQA
Informe de Revisin Tcnica Formal

Documento de Evaluacin y Ajustes al Plan
de SQA
Evaluacin final de SQA

Revisar la entrega semanal
Informe final de SQA

Entrega semanal de SQA
Tabla 1 Actividades de Grupo SQA

3.4.
RESPONSABILIDADES
Las responsabilidades de cada una de las organizaciones involucradas se definen de la siguiente forma:
3.4.1. RESPONSABILIDADES DEL GRUPO DE DESARROLLO
Esta organizacin es responsable de:
Desarrollar un producto de software en base a lo definido en el SQAP y los contratos establecidos

con el cliente.
Generar la debida documentacin definida en la SQAP acerca de cada una de sus actividades con
el fin de llevar un control de las mismas.
Entregar la documentacin de desarrollo que se exige en el plan (SQAP).
3.4.2. RESPONSABILIDADES DEL CLIENTE

Proveer la informacin necesaria para el desarrollo del software con el fin de satisfacer sus
necesidades.
Brindar los recursos y condiciones necesarias para elaborar el software.
Participar activamente en la organizacin del SQA para obtener ptimos resultados.
3.4.3. RESPONSABILIDADES DE LA SQA

Actividades del grupo SQA:
Establecimiento del plan SQA para el proyecto.

Participar en el desarrollo de la descripcin del proceso de software.
Revisin de las actividades de ingeniera del software para verificar su ajuste al proceso del
software.
Auditoria de los productos de software designados para verificar el ajuste con los definidos como
parte del proceso de software.
Asegurar que las desviaciones del trabajo y los productos del software se documentan y se
manejan de acuerdo con un procedimiento establecido.
Registrar lo que no se ajuste a los requisitos e informar a sus superiores.
Coordinar el control y la gestin de cambios.
Analizar las mtricas del software.
Garantizar la calidad del producto de software desarrollado.

Implantar normas y actividades para el desarrollo del software.
Realizar reuniones para resolver los posibles conflictos durante el desarrollo del software.
Aprobar y publicar el SQAP.
Observar las deficiencias en el SQAP.
Mejorar el SQAP, recomendando modificaciones o correcciones con el fin de obtener resultados

ptimos.
Autorizar la implantacin del software.
Enfoque de gestin de calidad.
Tecnologas (mtodos y herramientas).
Revisiones Tcnicas Formales.
Estrategia de pruebas.
Control de la documentacin y de cambios.
Procedimientos que aseguren ajustes a los estndares.
Mecanismos de medicin y generacin de informes.
Como parte de las actividades del Responsable de SQA se revisarn los productos que se consideren
relevantes para la calidad del producto y del proceso. A continuacin se identifican esos productos y el
responsable de las acciones correctivas para eliminar los defectos de cada producto.
Producto
Documento de Requerimientos
Modelo de Casos de Uso
Alcance del Sistema
Descripcin de la Arquitectura
Modelo de Diseo
Modelo de Datos
Estndar de Implementacin
Estndar de documentacin tcnica
Documento de Estimaciones
Documento de Riesgos
Plan del Proyecto
Plan de Verificacin y Validacin
Reporte de pruebas unitarias, de
integracin y del Sistema
Plan de Implantacin
Estndar de Documentacin de Usuario
Documentacin de Usuario
Plan de Gestin de Configuracin
4.
Rol Responsable
Responsable
DOCUMENTACION
Esta documentacin es elaborada por el desarrollador, y se basa en el estndar ANSI / IEEE Std 830 Gua
par especificaciones de requerimientos de software (ERS).
La ERS deber describir claramente y de forma precisa cada uno de los requerimientos del software, tal
como: funciones, rendimiento, restricciones de diseo y atributos.
4.1.1. MODELO A USAR PARA EL CONTENIDO DEL ERS
10

1. INTRODUCION
1.1.1. Objetivo
1.1.2. Alcance
1.1.3. Definiciones, acrnimos y abreviaciones
1.1.4. Referencias
1.1.5. Revisin
2. DESCRIPCION GENERAL
2.1 Perspectiva del producto
2.2 Funciones del producto
2.3 Caractersticas de los usuarios
2.4 Restricciones generales
2.5 Asunciones y dependencias
3. ESPECIFICACION DE REQUERIMIENTOS
3.1 Requerimiento Funcional
3.1.1. Introduccin
3.1.2. Entradas
3.1.3. Procesos
3.1.4. Salidas
3.1.5. Interfaces externas
3.1.5.1. Interfaces del usuario
3.1.5.2. Interfaces del hardware
3.1.5.3. Interfaces del software
3.1.6 Requerimientos de rendimiento
3.1.7 Representacin del diseo
3.1.8 Cumplimientos con estndares
3.1.9 Limitaciones del hardware
3.1.10 Atributos
3.1.10.1. Disponibilidad
3.1.10.2. Seguridad
3.1.10.3. Mantenibilidad
3.1.10.4. Transferencia / Conversin
3.1.10.5 Prevenciones
3.1.11 Otros requerimientos
3.1.11.1. Base de datos
3.1.11.2. Operaciones
3.1.11.3. Adaptaciones
4.1.2. DESCRIPCIN DEL DISEO DEL SOFTWARE (DDS)

La generacin y documentacin de la descripcin del diseo de Software se basa en el estndar ANSI /
IEEE Std 1016 RECOMMENDED PRACTICE FOR SOFTWARE DESCRIPTIONS
VISTA DE
DISEO
ALCANCE
ATRIBUTOS DE
ENTIDAD
EJEMPLOS DE
REPRESENTACIONES
11

Descripcin de
descomposicin
Particin del sistema dentro

de entidades de diseo.
Identificacin, tipo,
objetivo, funcin,
subordinacin.
Diagrama
de
descomposicin, jerarqua
y lenguaje natural.
Descripcin de
dependencia
Descripcin de las relaciones

entre entidades y recursos
del sistema.
Identificacin, tipo,
objetivo,
dependencias,
recursos.
Diagrama de estructura.
Descripcin de
interfaces
Lista de cada interfaz de

diseador, programador, o
pruebas necesarias para
conocer el uso de la entidad
de diseo que componen el
sistema.
Identificacin,
funcin, interfaces.
Tablas de parmetros.
Descripcin de
detalle
Descripcin de los detalles

de diseo internos en una
entidad.
Identificacin,
procesamiento,
datos.
Diagrama de flujos.
Tabla de Organizacin de la DDS dentro de Vistas de Diseo
MODELO A USAR PARA EL CONTENIDO DEL DDS

1. INTRODUCION
1.1. Objetivo
1.2. Alcance
1.3. Definiciones, acrnimos y abreviaciones
2. REFERENCIAS
3. DESCRIPCION DE DESCOMPOSICION
3.1. Descomposicin de mdulo
3.1.1. Descripcin del mdulo 1
3.1.n. Descripcin del mdulo n
3.2. Descomposicin de procesos concurrentes
3.2.1. Descripcin del proceso 1
3.2.n. Descripcin del proceso n
3.3. Descomposicin de datos
3.3.1. Descripcin de la entidad de datos 1
3.3.n. Descripcin de la entidad de datos n
4. DESCRIPCION DE DEPENDENCIA
4.1.Dependencia entre mdulos
4.2.Dependencia entre procesos
4.3.Dependencia entre datos
5. DESCRIPCION DE INTERFACES
5.1. Interfaces de mdulo
5.1.1. Descripcin del mdulo 1
5.1.n. Descripcin del mdulo n
12

5.2 Interfaces de procesos
5.2.1. Descripcin del proceso 1
5.2.n. Descripcin del proceso n
6. DISEO DETALLADO
6.1. Diseo detallado del mdulo
6.1.1. Detalle del mdulo 1
6.1.n. Detalle del mdulo n
6.2. Diseo detallado de datos
6.2.1. Detalle de entidad de datos 1
6.2.2. Detalle de entidad de datos 2
4.1.3. PLAN DE VERIFICACIN Y VALIDACIN

La generacin y documentacin de la descripcin del Plan de Verificacin y Validacin (V & V) es la
siguiente:
MODELO A USAR PARA EL CONTENIDO DEL V & V
1.
2.
3.
4.
5.
OBJETIVO
ALCANCE
DEFINICIONES, ACRONIMOS Y ABREVIACIONES
ORGANIZACIN RESPONSABLES
CICLO DE VIDA DE VERIFICACION Y VALIDACION
La organizacin responsable por las tareas de verificacin y validacin del software es la organizacin de
SQA comandada por la organizacin del consultor, la cual interacta con la organizacin de desarrollo
para alcanzar los objetivos del plan. En casos necesarios de conflictos extremos entre el consultor y el
desarrollador se recurrir al cliente.
4.1.3.1. CICLO DE VIDA DE VERIFICACIN Y VALIDACIN
El plan se basa en el siguiente ciclo de vida del software:
Fase de concepto
Fase de requerimientos
Fase de diseo
Fase de implementacin
Fase de prueba
Fase de instalacin y prueba
Fase de operacin y mantenimiento
Tareas mnimas de V&V
1 Fase de Concepto V&V

Entradas requeridas
Evaluacin de concepto de documentacin

Evaluar el concepto de documentacin para
determinar si el concepto propuesto satisface las
necesidades del usuario y el objetivo del proyecto.
Concepto de
documentacin:
Planificacin del
Salidas requeridas
Reporte de tareas
Reporte de anomalas
13

Identificar las restricciones principales de interfaces
del sistema y limitaciones de objetivos propuestos.
Fijar credibilidad de cada elemento de software
proyecto, Memo de
iniciacin del proyecto
Tabla de Tareas, entradas y salidas de V&V (Fase 1)
2 Fase de Diseo V&V

Entradas requeridas
Anlisis de seguimiento a los requerimientos de Concepto de
software.
documentacin ERS.
Seguir los requerimientos ERS hacia los Documentacin de
requerimientos del sistema dentro del concepto de requerimientos de
documentacin. Analizar identificando relaciones interfaces.
para correcciones, consistencia, completitud y
optimizacin.
Evaluacin de requerimientos de software.
Concepto de
Evaluar los requerimientos ERS para: precisin, documentacin ERS.
cumplimiento, confiabilidad, y capacidad de ser Documentacin de
probado. Fijar la credibilidad de requerimientos requerimientos de
para identificar rendimiento o rea crticas de interfaces.
software.
Concepto de
documentacin ERS.
Documentacin de
requerimientos de
interfaces.
Concepto de
documentacin ERS.
Documentacin de
requerimientos de
interfaces.
Documentacin de
usuario.
Concepto de
documentacin ERS.
Documentacin de
requerimientos de
interfaces.
Documentacin de
usuario.
Salidas requeridas
Reporte de tareas.
Reporte de anomalas.
Reporte de tareas.
Reporte de tareas.
Plan de pruebas del

sistema.
Plan de pruebas de
aceptacin.
3 Fase de Implementacin V&V

Entradas requeridas
Salidas requeridas
4 Fase de Pruebas V&V

Entradas requeridas
Salidas requeridas
14
5 Fase de Concepto V&V

Entradas requeridas
Salidas requeridas
Tabla de2 Tareas, entradas y salidas de V&V (Fase 5)
6 Fase de Instalacin y Validacin V&V

Entradas requeridas
Salidas requeridas
7 Fase de Operacin y Mantenimiento V&V

Entradas requeridas
Salidas requeridas
4.1.4. INFORMACIN DE VERIFICACIN Y VALIDACIN

El formato para la documentacin de los resultados de la implementacin del plan de verificacin y
validacin del software (V & V) es la siguiente:
4.1.4.1. REPORTE SUMARIO DE FASE V&V
REPORTE SUMARIO DE FASE V&V
Pg.
FASE:
# De Reporte:
......
.......................
Lugar:
a)
Fecha:
Hora:
Descripcin de las tareas de V&V realizadas:
b) Sumario de resultados de tareas:
15

c)
Sumario de anomalas y resolucin:
d) Evaluacin de calidad del software:
e)
Recomendaciones:
Equipo de Trabajo:
Nombre:
Firma
4.1.4.2. REPORTE DE ANOMALAS

REPORTE DE ANOMALIAS
FASE:
# De Reporte:
Lugar:
Pg.
......
Fecha:
Hora:
a) Descripcin y ubicacin:
b) Impacto:
c) Causa:
d) Critibilidad:
16

e)
Recomendaciones:
Equipo de Trabajo:
Nombre:
Firma
4.1.4.3. REPORTE FINAL V&V
REPORTE FINAL DE V&V

Pg.
FASE:
......
# De Reporte:
Lugar:
Fecha:
Hora:
a) Resumen de todas las tareas V&V, durante el ciclo de vida del software:
b) Resumen de resultados de tareas:
17

c) Resumen de anomalas, resolucin:
d) Evaluacin total de la calidad del software:
e) Recomendaciones:
Equipo de Trabajo:
Nombre:
Firma
4.1.5. DOCUMENTACIN DE USUARIO

Esta descripcin de documentacin de usuario (UD) se basa en el estndar ANSI / IEEE Std 1036
STANDARD FOR SOFTWARE USER DOCUMENTATION.
La informacin especificada debe ser incluida en la documentacin del usuario, esta
documentacin de usuario comprender de un conjunto. En cada documento se debe tomar en cuenta y
describir los siguientes puntos.
Los documentos de usuario sern presentados en dos modos: instruccional y de referencia. Los
usuarios del software utilizarn los documentos ya sea para aprender acerca del software (modo
instruccional) o para refrescar su memoria acerca del software (modo de referencia).
Modo Instruccional
Un modo instruccional de documento debe:
Proveer el ambiente y la informacin necesaria para entender el sistema.
Proveer la informacin necesaria para aprender lo que puede hacer con el software y como lo
puede usar.
Proveer ejemplos para reforzar el proceso de aprendizaje.
18

Modo de Referencia
Un documento de modo de referencia debe:
Organizar y proveer informacin necesaria.
Facilitar accesos aleatorios a la informacin.
Los documentos de modo de referencia que debe ser incluido son:
a. Manual de comandos.
b. Manual de mensajes de error.
c. Manual de llamadas de programas.
d. Gua de referencia rpida.
e. Manual de Herramientas del software.
f. Manual de utilitarios.
5.
ESTANDARES, PRACTICAS Y CONVENCIONES
5.1.
ESTNDAR DE CODIFICACIN
La codificacin del software se realizar en la plataforma Java. Las normas de codificacin se definen de
la siguiente forma:
El software debe ser subdividido en mdulos independientes, de acuerdo al diseo establecido.

La documentacin de un programa debe tener el siguiente formato:
o
o
o
Nombre del programa

Objetivo
Nombre de las entradas:
Base de Datos
Archivos
Registros
Formatos de pantalla
Nombre de las salidas:

Base de Datos
Archivos
Registros
Formatos de pantalla
Reportes
Nombre de los archivos de actualizacin:

Base de Datos
Archivos
Registros
o
o
o
Nombre del autor

Fecha de creacin
Historial de actualizaciones
Versin
Fecha de cambio
19
Objetivo de cambio
Cada mdulo debe explicar sus funciones

La declaracin de cualquier variable debe estar comentada, explicando su funcin.
Debe existir una sola instruccin por cada lnea de cdigo.
Cada funcin debe de estar debidamente documentada, explicar la funcionalidad, la funcin de
cada parmetro.
Cada mensaje de error o excepciones deben de indicar el lugar donde se origin y la funcin o
procedimiento en el cual se produjo.
Para asignar nombres a las variables debe de realizarse de la siguiente forma:
o
o
o
xNombreCliente
xSaldo
xFechaInicio
Donde x = indica el tipo de dato, puede representar: enteros, reales, cadenas, etc.
Los nombres de las funciones deben de indicar su funcionalidad.

Cada clase implementada debe de estar comentada de la siguiente forma:
o
o
o
o
o
5.2.
Nombre
Fecha y hora de creacin
Autor
Nombre del mdulo al que pertenece
Funcionalidad
Se utilizarn las Convenciones de Codificacin en Java de Sun Microsystems, Inc.
ESTNDAR DE COMENTARIO
Un comentario debe explicar porque se realiza alguna accin.

Los comentarios dentro de un mdulo deben estar separados del cdigo.
Utilizar comentarios de ms de una lnea para realizar descripciones, y comentarios de una lnea
para realizar especificaciones.
Estndares para documentacin

Entregable
5.3.
Estndar
RESPONSABLES DE VERIFICAR EL CUMPLIMIENTO
Los responsables de realizar la verificacin del cumplimiento con los estndares definidos son:
20
6.
El jefe del equipo de desarrollo.

La organizacin del SQA.
REVISIONES Y AUDITORIAS
Los responsables de estas revisiones es la organizacin del SQA, con la participacin de todo elemento de
la organizacin que tengan que ver con los requerimientos, tales como: los diseadores del software,
agentes de pruebas.
6.1.
Propsito
Las revisiones y auditorias de los resultados del desarrollo se realizan a medida que se terminan cada una
de las fases del ciclo de vida de desarrollo de software, con el fin de:
6.2.
Conocer el progreso alcanzado en el desarrollo.

Evaluar el ajuste a los requerimientos del sistema.
Evaluar la eficiencia en el trabajo.
Requisitos Mnimos
Se deben llevar a cabo, al menos, las siguientes revisiones y auditorias:

Revisin de los Requisitos de Software (RRS):
La RRS se genera para:
Evaluar las especificaciones de requerimientos del software (ERS).
Asegurar que los requerimientos establecidos en la ERS, sean los correctos y estn completos.
Garantizar la calidad, viabilidad e integridad de los requerimientos establecidos.
Los requerimientos de revisiones de ERS en la RRS son los siguientes:
a.
b.
c.
d.
e.
f.
g.
h.
Fiable
Completo
Depurable
Modificable
Consistente
Libre de ambigedades
Utilizable durante la fase de operacin y mantenimiento.
Inspeccionar que la relacin entre los requerimientos y sus derivados sea la adecuada.
Revisin del Diseo Preliminar (PDR):

La PDR es realizada para evaluar la suficiencia tcnica del DDS preliminar, antes de comenzar con el diseo
detallado, define los siguientes puntos:
Evaluar el progreso, consistencia y suficiencia tcnica del alcance de diseo con los
requerimientos funcionales de la ERS.
Verificar la existencia y compatibilidad de las interfaces entre el software, el hardware y los
usuarios finales.
21
Determinar un diseo de software que cumpla con los requerimientos.
Para la PDR se toman como requerimientos de revisiones los siguientes puntos:
Revisar que se detallen todas las interfaces con otro software, sistemas de comunicacin, etc.
Para una adecuada identificacin de interfaces y de un diseo ptimo.
Revisar que exista un anlisis del diseo para verificar la compatibilidad con los requerimientos
crticos.
Revisar que se establece los requerimientos del factor humano.
Revisin del Diseo Crtico (CDR):

La CDR es generada para determinar la aceptabilidad de cmo la DDS cumple con la ERS. Evala la
suficiencia tcnica, integridad del diseo detallado del software, antes de comenzar a codificar para
establecer que el diseo detallado satisface los requerimientos de la SRS.
Para la CDR se toman como requerimientos de revisin los siguientes puntos:
Evaluar la compatibilidad del diseo detallado con la ERS.

Examinar la representacin de datos en forma de diagramas lgicos, algoritmos, almacenamiento
y representacin de datos.
Determinar la compatibilidad e integridad de requerimientos de interfaces.
Establecer que todas las interfaces internas y externas incluyendo interacciones con la base de
datos sean expresadas.
Revisin Tcnica Formal (RTF):

Objetivo:
Descubrir errores en la funcin, la lgica la implementacin de cualquier producto del software, verificar
que satisface sus especificaciones, que se ajusta a los estndares establecidos, sealando las posibles
desviaciones detectadas.
Mecanismo:
Es un proceso de revisin 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 caracterstica se
adopta esta prctica para productos que son de especial importancia.
En la reunin participan el responsable de SQA e integrantes del equipo de desarrollo.
Se debe convocar a la reunin 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.
22

Requerimientos Mnimos:
Los elementos que debern ser revisados son:
6.3.
Especificacin de Requerimientos
Modelo de Diseo y Descripcin de la Arquitectura
Plan de Verificacin y Validacin
Plan de Gestin del Proyecto
Plan de Gestin de Configuracin
Diseo vs. Especificacin de requerimientos
Implementacin vs. Diseo
Verificacin vs. Especificacin de requerimientos
Agenda
En esta seccin se detallan todas las revisiones de calidad que se realizarn durante todo el proyecto,
organizadas por fase e iteracin.
Fase I Inicial
Iteracin I
Entregable
Realizado
Nombre del entregable

producto a revisar
o Fase,
iteracin
y
semana en que se
debe realizar la versin
del producto a revisar
Revisin
Tipo de revisin
Semana, si se quiere
tambin la fecha, en la
que se realizar la
revisin del entregable
o producto
Tipo de revisin que se

realizar: Evaluacin
de la calidad de los
productos, Revisar el
ajuste al proceso o
Revisin
Tcnica
Formal
.
Iteracin N
Fase II Elaboracin
Iteracin I
Iteracin N
Fase III Construccin
Iteracin I
Iteracin N
Fase IV Transicin
Iteracin I
..
Iteracin N
Y as sucesivamente para cada una de las fases del ciclo de vida de desarrollo de software.
23

7.
GESTION DE CONFIGURACION
El objetivo del SQA en esta rea es asegurar que se realizan las actividades de gestin de configuracin
establecidas en el Plan de Configuracin y que se realizan segn lo establecido en el proceso.
Se pueden definir las siguientes actividades mnimas que se deberan realizar:
8.
Asegurar que se gener la Lnea Base del proyecto en el momento establecido en el modelo de
proceso.
Asegurar que la Lnea Base del proyecto generada es correcta.
Se verifica peridicamente que el Responsable de SCM mantiene apropiadamente el control de
la lnea base, as como el registro completo de cambios para requerimientos, diseo, cdigo,
verificacin y documentacin.
Se monitorean los procedimientos del Comit de Control de Cambios para verificar que son
efectivamente realizados como se especificaron en el Plan de configuracin.
INFORMACION DE PROBLEMAS Y ACCIONES CORRELATIVAS
En esta seccin se describen las prcticas y procedimientos que se van a utilizar para la notificacin,
seguimiento y resolucin de problemas de software, as como las responsabilidades organizativas.
El propsito de un sistema de Gestin de Problemas y Acciones Correlativas es:
Asegurar que todos los problemas de documentan, se corrigen y no caen en el olvido.

Asegurar que se evala la validez de los informes de problemas.
Realimentar al desarrollador y el usuario sobre el estado de los problemas.
Proporcionar datos para medir y predecir la calidad y fiabilidad del software.
Cualquier problema en el producto de software que sea encontrado durante el ciclo de vida de
desarrollo de software, debe ser reportado a travs de un reporte en el cual se detalla la fecha de cuando
fue encontrado el problema, una identificacin preliminar del mismo, descripcin, etc., este reporte debe
ser firmado por los que identificaron el problema, debe ser entregado a la organizacin responsable de
los problemas.
La organizacin responsable de los problemas del software, es la organizacin del SQA, comandada
por la organizacin del consultor, estas organizaciones son las encargadas de determinar el cronograma,
lugar y temario, para llevar a fijar la accin correctiva del problema.
REPORTE FINAL DE PROBLEMAS
Pg.......
24
# De Reporte:
Fecha: /
Lugar:
/.
Hora: ..
a) Identificacin del problema:
b) Descripcin:
c) El evento ejecutado cuando se present el problema es:
d) Posibles orgenes del problema:
Equipo de Trabajo:
Nombre:
Firma
Las acciones a seguir para corregir los problemas presentados se describen de la siguiente manera:
Antes de la identificacin de la presencia de un problema se debe buscar los posibles orgenes del
mismo sin desechar ninguna de las posibilidades, para esto se debe tomar dos rutas para generar
el reporte de problema completo y consistente.
o
o
o
o
Registrar las causas sospechosas del origen del problema, esto asegura que no se
descarta ninguna situacin posible.
Registrar causas adicionales
Registrar causas plenamente identificadas, esto es, causas verificadas por detectores
del problema
Registrar otras causas externas o relacionadas a las identificadas anteriormente
25
9.
Generar el reporte del problema, este debe estar completamente detallado y de acuerdo a los
puntos que contiene el mismo, este reporte debe ser entregado a la organizacin responsable por
los problemas.
La organizacin responsable por los problemas, convocan a una reunin tcnica, en la cual
participarn adems de la organizacin responsable, los elementos de las organizaciones
afectadas por el problema, quienes describirn el problema y darn recomendaciones necesarias
para solucionar el problema.
La especificacin de acciones correctivas generada en la reunin tcnica, ser entregada a los
elementos organizacionales afectados por el problema para que estos implementen las acciones
correctivas respectivas.
TESTEO
Revisin del Plan de Verificacin y Validacin (RP V & V):

La RP V & V es generado para la evaluacin de:
Los mtodos de Verificacin y Validacin definidos en el V & V.
El cumplimiento durante el desarrollo del software con el V & V.
10. HERRAMIENTAS, TECINAS Y METODOLOGIAS
En esta seccin se identifican todas las herramientas, tcnicas y metodologas que se van a utilizar en el
desarrollo que apoyan el Aseguramiento de Calidad.
Algunas de las herramientas son:
Utilidades del sistema operativo WINDOWS XP.

Utilidades del sistema operativo LINUX.
Documentacin de ayuda.
Instaladores.
Las tcnicas que ayudan a la evaluacin o mejora de la calidad son:
ANSI / IEEE STD 830

ANSI / IEEE STD 1016
Guide for Software Requirements Specifications

Recommended Practice for Software Design Descriptions
Standard for Software Unit Testing
Standard for Software User Documentation
Standard for Software Reviews and Audits
Las metodologas de Aseguramiento de Calidad sern conjuntos integrados de tcnicas, de entre los
anteriores.
11. CONTROL DEL CODIGO
En esta seccin se definen los mtodos, tcnicas y facilidades que se van a utilizar para controlar el
almacenamiento y mantenimiento de versiones del cdigo.
26

Se especifica un procedimiento de control del Cdigo que:
11.1.
Defina cul es el software que se va a controlar.

Describa un mtodo estndar para identificar, etiquetar y catalogar el software.
Liste la localizacin fsica del software bajo control.
Describa la localizacin, forma de mantenimiento y de uso de las copias de seguridad.
Describa los procedimientos para distribucin de copias.
Identifique la documentacin que se ver afectada por los cambios.
Describa los procedimientos para la construccin de una nueva versin.
CONTROL DE MEDIOS
En esta seccin se definen los mtodos y facilidades que se van a utilizar para proteger el medio fsico de
accesos no autorizados y daos y degradaciones inesperadas, y las organizaciones responsables para
realizar este control.
La organizacin responsable por esta tarea es la organizacin de desarrollo, con la supervisin de la
organizacin de la SQA.
Se debera asegurar que:
Est garantizado el almacenamiento y recuperacin de software.
El software est accesible nicamente para aquellos que lo necesitan.
Se controla el entorno para que no se degrade el medio fsico en el que se almacena el software.
Se almacenan copias del software crtico y del cdigo en lnea base fuera de las instalaciones de
la organizacin.
Medio de Almacenamiento
El medio del programa de computadora se define como aquellos medios sobre los cuales los datos son
almacenados.
Se utilizarn los siguientes medios:
Los discos duros como dispositivos primarios.
Los CDs como almacenamiento secundario, para guardar las copias de seguridad.
La documentacin respectiva sobre el desarrollo de software (papel).
Proceso de copias de seguridad
Las copias de seguridad sern realizadas a la finalizacin de cada sesin de trabajo, registrndose la fecha
y hora de copia de seguridad.
Puntos de Control
Para el acceso no autorizado, se debe asignar cuentas privilegiadas, cada usuario que interacta con el
software tendr su propia cuenta de acuerdo al cargo que desempee.
Se cuenta con la integridad de la Base de Datos para la proteccin de los datos.
Se realizar una revisin peridica del software con el fin de que funcione ptimamente
27

11.2.
CONTROL DE SUMINISTRADORES Y SUBCONTRATOS
En esta seccin se explica de qu forma se va a asegurar que el software comprado o subcontratado

cumple los requisitos tcnicos.
12. RECOLECCION, MANTENIMIENTO Y RETENCION DE REGISTROS
Las organizaciones responsables por las tareas de esta seccin, es la organizacin del consultor, en
coordinacin con la organizacin de la SQA.
Se identifica aquella documentacin que se debe retener, y se especifican los mtodos y facilidades que
se utilizarn para recolectar, proteger y mantener esta documentacin.
Tambin se especificar el perodo de retencin para cada tipo de registro.
Se puede registrar no slo documentacin, sino tambin los medios fsicos que contienen las versiones
de los programas y los materiales utilizados en las pruebas, para asegurar la repetibilidad de los tests en
el futuro.
Los documentos que son requeridos son los siguientes:
Plan de garanta de calidad del software.

Especificacin de requerimientos del software.
Descripcin del diseo del software.
Plan de verificacin y validacin del software.
Documentacin del usuario.
El mantenimiento de los registros del software, ser realizado por versiones sucesivas de actualizaciones
de las mismas, para esto se lleva un registro de actualizaciones de la documentacin.
Los documentos verificados y validados, deben ser documentados en libros impresos, con tres copias de
cada documento y almacenado en lugares diferentes y ambiente adecuados.
La retencin de registros se realizar en cada finalizacin de las fases del ciclo de vida de desarrollo de
software y segn los puntos de verificacin y validacin.
13. REFERENCIAS
[1].[RJB-1999]
James Rumbaugh, Ivar Jacobson, Grady Booch, El proceso Unificado de

Desarrollo de Software, Editorial ADISSON WESLEY, 1999, Ciudad de
Madrid Espaa.
[2]
[PRESSMAN-2002] Roger S. Pressman, Ingeniera de Software. Un Enfoque Prctico Quinta
Edicin, Editorial McGRAW-HIL, 2002, Espaa
[3]
28

[MOORE-1998]
James W. Moore, Software Engineering Standrards, Cap 6, IEEE

Computer Society, 1998.
[4]
[FFMD-1998]
Finkelstein A., Fuggetta A., Montangero C., Derniame J.C., Software

Process: Principals, Methodology and Technology, Cap 2, SpringerVerlag, 1998.
[5]
[WWW-01]
Laboratorio de Sistemas de Informacin Facultad de Informtica

Universidad Politcnica de Valencia
http://campus.fortunecity.com/defiant/114/index.html
[6]
Direccin de tecnologa y sistemas
<HTTP://WWW.SISTEMAS.EDU.BO/JBERMUDEZ/SIS3502A/ESTANDARESIEEE.PPT>
29

ModeloPlanCalidadSQAP PDF

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ModeloPlanCalidadSQAP PDF

Cargado por

Copyright:

Formatos disponibles

PLAN DE SQA

SQAP EMPRESA TERASOFT

OBJETIVO GENERAL ..................................................................................................... 3

OBJETIVOS ESPECIFICOS .............................................................................................. 4

MISION ........................................................................................ Error! Marcador no definido.

VISION ......................................................................................... Error! Marcador no definido.

POLITICAS DE CALIDAD ........................................................................................................... 4

SLOGAN ....................................................................................... Error! Marcador no definido.

PLAN DE ASEGURAMIENTO DE CALIDAD DE SOFTWARE .............................................................. 5

ORGANIGRAMA DE SQA .................................................................................................. 7

RESPONSABILIDADES DEL GRUPO DE DESARROLLO ...................................................... 9

RESPONSABILIDADES DEL CLIENTE ............................................................................... 9

RESPONSABILIDADES DE LA SQA .................................................................................. 9

ORGANIZACIN DE LA SQA ...................................................................................... 6

EVOLUCIN DEL SQAP .............................................................. Error! Marcador no definido.

Control De Cambio ............................................................ Error! Marcador no definido.

CUANDO HACER MODIFICACIONES .................................... Error! Marcador no definido.

IMPLANTACIN DE MODIFICACIONES ................................ Error! Marcador no definido.

PUBLICACIN DEL SQAP .................................................... Error! Marcador no definido.

DESCRIPCIN DEL DISEO DEL SOFTWARE (DDS) ....................................................... 11

PLAN DE VERIFICACIN Y VALIDACIN....................................................................... 13

SQAP EMPRESA TERASOFT

INFORMACIN DE VERIFICACIN Y VALIDACIN ........................................................ 15

DOCUMENTACIN DE USUARIO ................................................................................ 18

ESTANDARES, PRACTICAS Y CONVENCIONES ......................................................................... 19

ESTNDAR DE CODIFICACIN ........................................................................................ 19

ESTNDAR DE COMENTARIO ......................................................................................... 20

RESPONSABLES DE VERIFICAR EL CUMPLIMIENTO .......................................................... 20

REVISIONES Y AUDITORIAS ................................................................................................... 21

GESTION DE CONFIGURACION .............................................................................................. 24

INFORMACION DE PROBLEMAS Y ACCIONES CORRELATIVAS ................................................. 24

HERRAMIENTAS, TECINAS Y METODOLOGIAS .................................................................... 26

CONTROL DEL CODIGO...................................................................................................... 26

CONTROL DE SUMINISTRADORES Y SUBCONTRATOS..................................................... 28

RECOLECCION, MANTENIMIENTO Y RETENCION DE REGISTROS ......................................... 28

SQAP EMPRESA TERASOFT

1.2.1. OBJETIVO GENERAL

SQAP EMPRESA TERASOFT

Suministrar productos tendientes al cero defecto.

SQAP EMPRESA TERASOFT

PLAN DE ASEGURAMIENTO DE CALIDAD

SQAP EMPRESA TERASOFT

1 Fase: Planificacin del proyecto.

SQAP EMPRESA TERASOFT

SQAP EMPRESA TERASOFT

Las actividades de SQA definidas en el modelo de proceso son:

Realizar Revisin Tcnica Formal

Informe de Revisin Tcnica Formal

Evaluacin final de SQA

Informe final de SQA

SQAP EMPRESA TERASOFT

Desarrollar un producto de software en base a lo definido en el SQAP y los contratos establecidos

3.4.2. RESPONSABILIDADES DEL CLIENTE

3.4.3. RESPONSABILIDADES DE LA SQA

Establecimiento del plan SQA para el proyecto.

Esta organizacin es responsable de:

Garantizar la calidad del producto de software desarrollado.

SQAP EMPRESA TERASOFT

Mejorar el SQAP, recomendando modificaciones o correcciones con el fin de obtener resultados

SQAP EMPRESA TERASOFT

4.1.2. DESCRIPCIN DEL DISEO DEL SOFTWARE (DDS)

SQAP EMPRESA TERASOFT

Particin del sistema dentro