G-SOFT, DESARROLLO DE APLICACIONES MULTIPROPSITO

SQAP
Software Quality Assurance Plan
Nombre: Gerardo Miranda Cspedes Registro: 200983865

Version del documento: 1.0 Santa Cruz Bolivia, 7 de mayo de 2013

El contenido de este plan de garanta de la calidad del software o SQAP est basado en el IEEE Std 730-2002 Standard for software quality assurance plans publicado por IEEE en fecha 23 de septiembre de 2002

Contenido
1. Objetivo ..................................................................................................................................... 3 1.1. 1.2. 2. 3. Objetivo del SQAP.......................................................................................................... 3 Alcance del SQAP .......................................................................................................... 3

Referencias .............................................................................................................................. 3 Administracin ........................................................................................................................ 4 3.1. Organizacin ................................................................................................................... 4 Organizacin del equipo desarrollador ............................................................ 4 Organizacin del grupo de SQA ......................................................................... 5

3.1.1. 3.1.2. 3.2. 3.2.1. 3.3. 3.4. 4.

Tareas ................................................................................................................................ 6 Tareas de SQA ............................................................................................................ 6 Roles y Responsabilidades ......................................................................................... 8 Estimacin de recursos para SQA............................................................................. 9

Documentacin ....................................................................................................................... 9 4.1. 4.2. 4.3. 4.4. 4.5. Propsito .......................................................................................................................... 9 Especificacin de los requerimientos del software SRS ................................... 10 Descripcin del diseo del software SDD ............................................................. 10 Plan de verificacin y validacin del software ..................................................... 12 Documentacin del usuario ...................................................................................... 13

5.

Estndares, prcticas, convenciones y mtricas ........................................................ 14 5.1. 5.2. Propsito ........................................................................................................................ 14 Contenido ....................................................................................................................... 15 Estndares de documentacin ......................................................................... 15 Estndares de diseo.......................................................................................... 15 Estndares de codificacin ............................................................................... 16 Mtricas................................................................................................................... 16

5.2.1. 5.2.2. 5.2.3. 5.2.4. 6.

Revisiones .............................................................................................................................. 16 6.1. 6.2. 6.2.1. 6.2.2. Objetivo ........................................................................................................................... 16 Evaluacin de la calidad de los productos ........................................................... 17 Objetivo ....................................................................................................................... 17 Mecanismo ................................................................................................................. 17

6.3. 6.3.1. 6.3.2. 6.4. 6.4.1. 6.4.2. 7. 8. 9.

Revisin al ajuste al proceso .................................................................................... 18 Objetivo ....................................................................................................................... 18 Mecanismo ................................................................................................................. 18 Revisin tcnica formal .............................................................................................. 19 Objetivo ....................................................................................................................... 19 Mecanismo ................................................................................................................. 19

Pruebas ................................................................................................................................... 20 Reportes de problemas y acciones correctivas........................................................... 20 Herramientas, tcnicas y metodologas ......................................................................... 28 9.1. 9.2. Herramientas ................................................................................................................. 28 Metodologa ................................................................................................................... 28 Control de contenido multimedia................................................................................. 28 Control de proveedores .................................................................................................. 28 Recoleccin, mantenimiento y retencin de registros .......................................... 29 Entrenamiento ................................................................................................................... 29 Manejo de Riesgos........................................................................................................... 30 Glosario............................................................................................................................... 30 Procedimiento de cambio en el SQAP ........................................................................ 31 Control de versiones ................................................................................................... 31 Casos que requieren modificaciones ..................................................................... 31 Implantacin de modificaciones .............................................................................. 32

10. 11. 12. 13. 14. 15. 16. 16.1. 16.2. 16.3.

ANEXO A......................................................................................................................................... 33 ANEXO B......................................................................................................................................... 38

1. Objetivo 1.1. Objetivo del SQAP El propsito de este plan es especificar las actividades que se debern realizar para poder asegurar la calidad del software a desarrollar. Aqu se detallan los productos que se van a revisar y los estndares, normas o mtodos a aplicar; los mtodos y procedimientos que se utilizarn para revisar que la elaboracin de los productos se realice como lo establece el modelo de ciclo de vida del proyecto; y procedimientos para informar a los responsables de los productos los defectos encontrados y realizar un seguimiento de dichos defectos hasta su correccin. 1.2. Alcance del SQAP Este plan es aplicable para los siguientes proyectos de software: DEFD.- Software para que los usuarios puedan definir, guardar, compartir y realizar sus propios tipos de diagramas. El presente SQAP ser aplicable a lo largo de todo el proceso de desarrollo.

2. Referencias IEEE Std. 730 2002 Standard for Software Quality Assurance Plans. Convenciones para el lenguaje de programacin Java revisin de marzo de 2007 Perfil de Proyecto DEFD

3. Administracin 3.1. Organizacin El encargado del rea de gestin de calidad en el proyecto es el responsable de realizar la gestin que asegura que el proceso establecido sea realmente implementado y que los productos de ese proceso cumplan con los criterios de calidad establecidos en este plan. La gestin de calidad es una disciplina de gestin. Las disciplinas de gestin brindan soporte a las disciplinas bsicas (Requerimientos, Anlisis, Diseo, Implementacin, Implantacin y Verificacin) y se realizan en forma paralela a ellas. Las organizaciones involucradas en la implementacin del producto de software son las siguientes:

Organizacin del equipo desarrollador Organizacin del grupo de SQA

3.1.1. Organizacin del equipo desarrollador Es la organizacin desarrolladora del producto de software. Su trabajo estar regido en base a las especificaciones establecidas, debiendo responder por sus actividades ante el Consultor. El equipo desarrollador est conformado por: Director de equipo de desarrollo Jefe de desarrollo Analista Diseador
4

Programadores Documentadores Equipo de Pruebas

El equipo de desarrollo estar organizado tal y como muestra el siguiente organigrama.

3.1.2. Organizacin del grupo de SQA El grupo de SQA est conformado por miembros del equipo de desarrollo, miembros administrativos de la empresa, un experto en SQA y un experto en proyectos que actuar como consultor. En este grupo se toman decisiones segn las normas establecidas para luego liberar versiones sucesivas del SQAP para el desarrollo del software. Los miembros del grupo de SQA son los siguientes: Gerente Administrativo Director General

 3.2. Tareas

Experto en Proyectos de Software(Consultor) Experto en SQA Director de equipo de Desarrollo Jefe de Desarrollo

3.2.1. Tareas de SQA Actividad Realizar el Plan de SQA Identificar las propiedades de Calidad Evaluar la calidad de los productos Revisar el ajuste al proceso Realizar Revisin Tcnica Formal Evaluar y ajustar el Plan de SQA Resultado Plan de SQA Propiedades de Calidad Informe de revisin de SQA Informe de revisin de SQA Informe de Revisin Tcnica Formal Documento de Evaluacin y Ajustes al Plan de SQA Revisar la entrega semanal Realizar evaluacin final de SQA Reuniones de Apoyo a la calidad Entrega semanal de SQA Evaluacin final de SQA No Aplica

3.2.2. Tareas de SQA durante el proceso de desarrollo de software

Etapas Planificacin

Tareas Elaboracin del plan de proyecto Revisin del plan de proyecto

Requerimientos

Anlisis de requisitos de software Elaboracin de especificaciones Revisin de especificaciones

Diseo

Revisin de adherencia del diseo a los estndares definidos Revisin de los mdulos del software Revisin de las observaciones en el diseo

Implementacin

Revisin del cdigo Revisin y comparacin del cdigo y documentacin del software Elaborar informes sobre desviaciones y las acciones correctivas Revisin de entregables

Pruebas

Revisin de resultados de pruebas de unidad Revisin de los resultados de las pruebas de integracin del software Revisin de las pruebas funcionales y evaluacin de resultados

Mantenimiento

Revisin de resultados de pruebas en ambiente real

3.3. Roles y Responsabilidades Tarea Elaboracin del plan de proyecto Responsable Director del equipo de desarrollo, experto en proyectos

Revisin del plan de proyecto

Grupo de SQA

Anlisis de los requisitos de software Elaboracin de especificaciones

Equipo de desarrollo Equipo de desarrollo

Revisin de especificaciones

Grupo de SQA

Revisin de adherencia del diseo a los estndares definidos Revisin de los mdulos del software

Experto en SQA, Jefe de desarrollo, director del equipo de desarrollo Grupo de SQA

Revisin de las observaciones en el diseo Revisin del cdigo

Experto en SQA, Jefe de desarrollo, director del equipo de desarrollo Jefe de desarrollo

Revisin y comparacin del cdigo con la documentacin Elaborar informes sobre desviaciones y las acciones correctivas Revisin de entregables Revisin de resultados de pruebas de unidad

Jefe de desarrollo

Grupo de SQA Grupo de SQA Jefe de desarrollo

Revisin de los resultados de las pruebas Jefe de desarrollo, director del equipo de de integracin del software desarrollo

Tarea Revisin de las pruebas funcionales y evaluacin de resultados Revisin de resultados de pruebas en ambiente real

Responsable Jefe de desarrollo, director del equipo de desarrollo Grupo de SQA

3.4. Estimacin de recursos para SQA La estimacin de recursos que estarn destinados al cumplimiento de este plan est detallada en el Plan de Administracin del Proyecto de Software, en el apartado de estimaciones. 4. Documentacin 4.1. Propsito El objetivo de esta seccin es especificar los documentos que dirigen el desarrollo del proyecto y que debern ser revisados como parte de las actividades de aseguramiento de la calidad. Para cada documento se indica el objetivo del documento, la plantilla, norma y/o estndar que se usa para elaborar el documento y el contenido mnimo que debe tener dicho documento. Identificar la documentacin que requiera el desarrollo, verificacin y validacin del software, adems de los elementos organizacionales responsables por esta documentacin. Se incluye la siguiente documentacin: Especificacin de los requerimientos del software Descripcin del diseo del software. Plan de verificacin y validacin del software Documentacin del usuario.
9

4.2. Especificacin de los requerimientos del software SRS La generacin y documentacin de las especificaciones de requisitos de software, se realizan conforme se especificado en esta seccin, la tabla que se muestra a continuacin refleja el formato y contenido de las ERS que debe presentar el desarrollador. Este documento estar apoyado en lo propuesto en el estndar [ANSI/IEEE-Std-730] gua para especificaciones de requerimientos de software, y se lo conocer a travs del acrnimo en ingles SRS. La SRS deber describir clara y en forma precisa cada uno de los requerimientos (funciones, rendimiento, restricciones de diseo y atributos) del software. La SRS debe describir clara y precisamente cada uno de los requerimientos (funciones, rendimiento, diseo, restricciones y atributos) del software. Cada requerimiento deber ser definido como para ser capaz de ser evaluarlo objetivamente por una metodologa prescrita, por ejemplo inspeccin, demostracin, anlisis o pruebas. El grupo de SQA deber identificar que estndares o guas se debe aplicar al contenido y formatos de la SRS. Ver el [IEEE-Std-730] el cul describe el contenido necesario de una excelente SRS.

4.3. Descripcin del diseo del software SDD La SDD debe describir los componentes principales del software incluyendo diseo de la base de datos e interfaces. Una expansin de esta descripcin debe describir cada subcomponente de los componentes principales.

10

La SDD es una descripcin tcnica de como el software cumple con los requerimientos especificados anteriormente en la ERS. Su funcin mas importante es describir una descomposicin del sistema dentro de componentes (subsistemas, mdulos, etc.) los cuales deben ser bien definidos. La SDD debe de ser preparado inicialmente como un SDD preliminar (nivel alto), y ser subsecuentemente expandida para producir un SDD detallado. El SDD estar sujeto a una revisin de diseo preliminar (PDR) y luego a la revisin del diseo crtico (CDR). Para cada componente en el sistema, la SDD debe consistir de puntos tales como: 1) Describir los componentes de: a) Entradas b) Salidas c) Secuencias de llamadas d) Funciones o tareas e) Algoritmos f) Interfaces 2) Listar los componentes utilizados (internos) o invocados (externos). 3) Listar los componentes desde donde es invocado. 4) Definir el rango de valores permitidos para las entradas. 5) Definir el rango de valores esperados para todas las salidas. 6) Describir Asunciones, limitaciones y efectos adyacentes.

11

Contents 1. Scope 1.1. 1.2. 1.3. Identification System overview Document overview

2. Referenced documents 3. DEFD-wide design decisions 4. DEFD architectural design 4.1. 4.2. 4.3. CSCI components Concept of execution Interface design

4.3.1. Interface identification and diagrams 4.3.x (Project-unique identifier of interface) 5. DEFD detailed design 6. Requirements traceability 7. Notes A. Appendixes

4.4. Plan de verificacin y validacin del software El SVVP describe los mtodos (por ejemplo para inspeccin, demostracin, anlisis, pruebas) a ser usados: Para verificar que los requerimientos en la SRS son implementados en el diseo expresado en la SDD. Para verificar que el diseo expresado en la SDD es implementado en el cdigo. Para validar que el cdigo, cuando sea ejecutado cumpla con los requerimientos expresado en la SRS.
12

El SVVP describe el plan total para toda la verificacin y validacin del software. Las tareas, mtodos, y criterios para la verificacin y validacin deben ser descritos. Consultar con el [ANSI/IEEE-Std829].

El contenido del SVVP ser evaluado en la revisin del plan de verificacin y validacin del software SVVR El SVVR describe los resultados de la ejecucin del SVVP. Esto incluir los resultados, de todas las revisiones, verificaciones y pruebas requerida por el SQAP. El SVVR muestra el estado de las acciones correctivas planeadas, recomienda si el software esta listo o no para uso operacional. 4.5. Documentacin del usuario La documentacin del usuario (manual, gua, etc.) debe especificar: Tipos de entradas de datos Control de entradas Secuencias de entradas Descripcin de resultados Opciones Limitaciones del software Otras actividades necesarias para el xito en la ejecucin del software. La documentacin debera estar compuesta por los siguientes puntos: 1) Describir instrucciones de usuario la cual contenga: Introduccin

13

 Descripcin de los usuarios que interactan con el software. Descripcin de entrenamiento necesario para el usuario. 2) Describir los objetivos del software. 3) Especificar las entradas y salidas. 4) Presentar ejemplos de todas las formas de ingreso de datos. 5) Presentar ejemplos de todas las salidas. 6) Describir instrucciones de entrada de datos que contiene instrucciones para: Preparar datos Introducir datos Verificacin y validacin del dato Correccin de datos en caso de error. 7) Describir las limitaciones del sistema. 8) Describir todas las situaciones de error los cuales pueden ocurrir y como reaccionar cuando se presente. 5. Estndares, prcticas, convenciones y mtricas 5.1. Propsito Identificar los estndares, prcticas, convenciones, tcnicas estadsticas a ser usadas, requerimientos de calidad y mtricas a ser aplicadas en el desarrollo del proyecto.

14

5.2. Contenido 5.2.1. Estndares de documentacin Con el objetivo de mantener toda la documentacin del proyecto uniforme se definen las siguientes reglas concernientes al formato de la documentacin del proyecto, incluyendo este SQAP: Los documentos deben estar impresos en hojas tamao carta. Debe mantenerse un margen mnimo de 3cm., en el lado izquierdo y de 2cm., mnimo en el lado superior, inferior y derecho. Toda la documentacin debe estar con letra Arial, tamao 12, incluyendo ttulos y subttulos. Se puede hacer una excepcin a esta regla nicamente en la portada del documento. La utilizacin de letra negrita a lo largo del documento est restringida solamente a los ttulos, subttulos y cuadros de contenido. La utilizacin de letra cursiva a lo largo del documento est restringida solamente a referencias a documentos externos, libros, autores, direcciones de pginas web. Todos los documentos deben incluir una portada, un ndice, un glosario y bibliografa. En caso de que alguno de estos no est presente en la estructura del documento, debe ser agregado como anexo. 5.2.2. Estndares de diseo Para el proyecto que abarca este SQAP se ha establecido la utilizacin de los siguientes patrones de diseo: Modelo Vista Controlador
15

Observer Singleton

5.2.3. Estndares de codificacin Se ha elegido Java como el lenguaje de programacin que utilizar el proyecto abordado en este SQAP. Con ello se adopta de la misma manera el estndar de codificacin descrito en el documento Convenciones de cdigo para el lenguaje de programacin Java 5.2.4. Mtricas El objetivo del presente SQAP es asegurar la calidad del software desarrollado bajo l, con este objetivo se utilizarn los siguientes indicadores para medir la calidad del software: 6. Revisiones 6.1. Objetivo Esta seccin tiene por objetivo definir las revisiones al software que sern llevadas a cabo, incluyendo revisiones gerenciales, tcnicas, inspecciones, paseos virtuales y auditoras. Sern descritos tanto sus objetivos como sus mecanismos. Para este documento en particular se definirn tres tipos de revisiones: Evaluacin de la calidad de los productos, revisin al ajuste al proceso y revisin tcnica formal. Correccin Facilidad de mantenimiento Integridad Facilidad de uso

16

6.2. Evaluacin de la calidad de los productos 6.2.1. Objetivo Revisar los productos que se definieron como claves para asegurar la calidad. Detectar desviaciones en los objetivos de calidad definidos e informar a los responsables para que sean corregidas. 6.2.2. Mecanismo Se revisan los productos que se definen como claves para verificar el cumplimiento de las actividades definidas en el proceso, durante todo el ciclo de vida del software. Se debe recoger la informacin necesaria de cada producto, buscando hacia atrs los productos previos que deberan haberse generado y son entradas para el producto objeto de revisin, para poder establecer los criterios de revisin y evaluar si el producto cumple con las especificaciones. Esta informacin se obtiene de los siguientes documentos: Plan del Proyecto Plan de la iteracin Plan de Verificacin

Se debe verificar si todos los pasos del proceso de desarrollo son seguidos apropiadamente. Antes de comenzar, se debe verificar en los informes de revisin 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 revisin de SQA correspondiente a la evaluacin de ajuste al Proceso, que contiene todas las
17

desviaciones o defectos encontrados durante la revisin. Este informe debe ser distribuido a los responsables de las actividades y se debe asegurar que ellos son conscientes de las desviaciones o discrepancias encontradas y de las acciones correctivas que deben realizar. 6.3. Revisin al ajuste al proceso 6.3.1. Objetivo Revisar si los productos se obtuvieron realizando las actividades que se indican en el Modelo de Proceso. 6.3.2. Mecanismo Se revisan los productos que se definen como claves para verificar el cumplimiento de las actividades definidas en el proceso, durante todo el ciclo de vida del software. Se debe recoger la informacin necesaria de cada producto, buscando hacia atrs los productos previos que deberan haberse generado y son las entradas para el producto objeto de revisin, para poder establecer los criterios de revisin y evaluar si el producto cumple con las especificaciones. Esta informacin se obtiene de los siguientes documentos: Plan del Proyecto Plan de la iteracin Plan de Verificacin

Se debe verificar si todos los pasos del proceso de desarrollo son seguidos apropiadamente.

18

Antes de comenzar, se debe verificar en los informes de revisin 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 revisin de SQA correspondiente a la evaluacin de ajuste al Proceso, que contiene todas las desviaciones o defectos encontrados durante la revisin. Este informe debe ser distribuido a los responsables de las actividades y se debe asegurar que ellos son conscientes de las desviaciones o discrepancias encontradas y de las acciones correctivas que deben realizar. 6.4. Revisin tcnica formal 6.4.1. 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. 6.4.2. 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

19

una lista de preguntas y dudas que surgen del estudio del producto a ser revisado. Para llevar a cabo las RTF se debe utilizar los formularios elegidos para este propsito, descritos en el anexo A. Como salida se obtiene el Informe de RTF. 7. Pruebas No aplicable a este documento. Todas las pruebas estarn descritas en el Plan de Verificacin y Validacin del Proyecto. 8. Reportes de problemas y acciones correctivas Son las actividades que se realizan para hacer el seguimiento de los errores luego de haberlos encontrado durante las revisiones tcnicas formales que son dirigidas por un moderador. Durante la correccin de cualquier artefacto, el autor del mismo es el encargado de corregir todos los defectos encontrados y el moderador es el encargado de verificar las correcciones del autor. En cada una de las fases del proceso (inicio, elaboracin, construccin y transicin) se realizaran las siguientes actividades para realizar el seguimiento de los errores:

20

a) Captura de requisitos como casos de uso i) Modelo de casos de uso Autor: Analista de sistemas, especificador de casos de uso Proceso: (1) Revisar el modelo de casos de uso segn la descripcin de los defectos encontrados. (2) Corregir los defectos. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor

ii) Prototipo de interfaz de usuario Autor: Diseador de interfaz de usuario Proceso: (1) Revisar el prototipo de interfaz de usuario segn la descripcin de los defectos encontrados. (2) Corregir los defectos del prototipo de interfaz de usuario. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados.
21

(5) El moderador certifica las correcciones del autor

b) Anlisis i) Clases del anlisis Autor: Ingeniero de componentes Proceso: (1) Revisar las clases segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados con respecto a las responsabilidades, atributos y relaciones de las clases. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor ii) Realizacin de casos de uso Autor: Ingeniero de casos de uso Proceso: (1) Revisar las realizaciones de casos de uso segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados. (3) Notificar la terminacin de la correccin al moderador.

22

(4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor iii) Paquetes del anlisis Autor: Ingeniero de Componentes Proceso: (1) Revisar las los paquetes segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor iv) Descripcin de la arquitectura del modelo de anlisis Autor: Arquitecto Proceso: (1) Revisar la vista de la arquitectura del modelo de anlisis segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados. (3) Notificar la terminacin de la correccin al moderador.

23

(4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor c) Diseo i) Clases del diseo Autor: Ingeniero de componentes. Proceso: (1) Revisar las clases del diseo segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor ii) Realizacin de casos de uso Autor: Ingeniero de casos de uso Proceso: (1) Revisar las realizaciones de casos de uso segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados en los diagramas de clases y de interaccin.
24

(3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor iii) Descripcin de la arquitectura del modelo de diseo Autor: Arquitecto Proceso: (1) Revisar la vista de la arquitectura del modelo de diseo segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor d) Implementacin i) Descripcin de la arquitectura del modelo de implementacin Autor: Arquitecto Proceso: (1) Revisar la vista de la arquitectura del modelo de implementacin segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados.
25

(3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor ii) Cdigo fuente de componentes Autor: Ingeniero de componentes Proceso: (1) Revisar el cdigo fuente de los componentes segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados en el cdigo fuente. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor iii) Plan de integracin del sistema Autor: Integrador de sistemas Proceso: (1) Revisar el plan de integracin del sistema segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados en el plan. (3) Notificar la terminacin de la correccin al moderador.
26

(4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor e) Pruebas i) Caso de prueba Autor: Diseador de pruebas Proceso: (1) Revisar los casos de prueba del sistema segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados en los casos de prueba. (3) Notificar la terminacin de la correccin al moderador. (4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor ii) Plan de pruebas Autor: Diseador de pruebas Proceso: (1) Revisar el plan de prueba del sistema segn la descripcin de los defectos encontrados. (2) Corregir los defectos encontrados en el plan. (3) Notificar la terminacin de la correccin al moderador.
27

(4) El moderador verifica la correccin satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor 9. Herramientas, tcnicas y metodologas 9.1. Herramientas Para la realizacin del software que abarca este SQAP se utilizarn las siguientes herramientas de software: Netbeans 7.1, entorno de desarrollo. Motodev, entorno de desarrollo. JDK 1.7, kit de desarrollo para java. Android SDK, kit de desarrollo para android. Microsoft Office Word, editor de texto. Enterprise Architect, herramienta CASE.

9.2. Metodologa La metodologa de desarrollo elegida es el Proceso Unificado de Desarrollo de Software, que es descrito con detalle en el perfil del proyecto DEFD. 10. Control de contenido multimedia No aplicable al presente documento, porque la cantidad de contenido multimedia incluido en el software es prcticamente nula. 11. Control de proveedores No aplicable a este documento, porque el proyecto no har uso de otro software comercial desarrollado por terceros.

28

12. Recoleccin, mantenimiento y retencin de registros Una parte importante dentro del SQA es conocer el estado del proceso, y que ste pueda ser gestionado, para ello todos los registros generados por el proyecto deben ser correctamente administrados. Con este propsito se definen a continuacin reglas para el manejo de los registros. Todas ellas son aplicables para la toda la documentacin descrita en la seccin 4 de este SQAP, para todos los registros detallados en la seccin 6 de este SQAP y para el presente documento, a lo largo del desarrollo del proyecto hasta su conclusin: Debe existir al menos una copia fsica alojada en la seccin de archivos de la empresa. Debe existir una copia digital, o escaneada en caso de ser documentacin fsica, en el servidor FTP de la empresa. Se debe proveer de una copia fsica al grupo de SQA. El autor del documento o registro debe mantener una copia, en este caso puede ser fsica o digital. Si se obtuviera una nueva versin de un documento, la versin anterior debe mantenerse bajo las mismas condiciones descritas en los puntos anteriores Una vez finalizado el proyecto an siguen vigentes los dos primeros puntos descritos anteriormente. 13. Entrenamiento Para una correcta aplicacin del presente SQAP, se realizar de manera obligatoria el siguiente curso: Conceptos Bsicos de SQA.

29

Impartido por el Experto en SQA al resto del grupo de SQA y al equipo de desarrollo. Otros cursos podrn ser programados en caso de ser necesarios, bajo criterio nica y exclusivamente del experto en SQA. 14. Manejo de Riesgos La planificacin del manejo de riesgos debe estar incluida en el Plan de Administracin del Proyecto de Software del proyecto. Para realizar la planificacin de los riesgos se deben realizar y registrar los resultados de las siguientes tareas: Identificar todos los riesgos potenciales Estimar el impacto de ocurrencia de cada riesgo identificado Estimar la probabilidad de ocurrencia de cada riesgo identificado Por cada riesgo identificado se debe elaborar un plan de aversin que indique cmo reducir la probabilidad de ocurrencia y cmo reducir el impacto en caso de presentarse una ocurrencia. 15. Glosario SQA Garanta de la calidad del software SQAP Plan de garanta de la calidad del software IEEE Instituto de ingenieros en electricidad y en electrnica Observer Patrn de diseo y comportamiento de software Singleton Patrn de diseo de software Servidor FTP Software ejecutado en un servidor para almacenar y compartir archivos.

30

16. Procedimiento de cambio en el SQAP 16.1. Control de versiones El control de cambio del SQAP, ser realizado utilizando versiones evolutivas as por ejemplo al presente SQAP, se denomina como la versin 1.0, los siguientes puntos describen el criterio a seguir para la asignacin de versin a las modificaciones del SQAP. Si los cambios solo afectan a secciones especificas del SQAP, y las mismas no modifican la lnea base del SQAP, la versin asignada ser la suma de ms 0.1, a la versin actual, los cambios se realizan insertando y/o eliminando hojas en le SQAP vigente. Si los cambios son significativos la versin asignada ser la suma de cualquier valor entre [0,1,2,....,9,8,9.9,1] para alcanzar el prximo numero entero, a la versin actual del SQAP y se imprimir completamente el nuevo SQAP. Si se quiere con frecuencia el punto, y no se imprimi completamente el SQAP modificado ya varias veces, entonces para contar con un SQAP consistente y mantenible se debe imprimir completamente el plan, con todas las modificaciones realizadas previamente, para la asignacin de versin se utilizar el criterio descrito en el punto anterior. 16.2. Casos que requieren modificaciones Las modificaciones al SQAP sern realizadas cuando se presenten las siguientes situaciones: En las relaciones y evaluaciones establecidas en este Plan. Otras situaciones pueden ser: Surgen nuevos cambios necesarios en los requerimientos.

31

Se detectan problemas que modifican la lnea base del SQAP, en alguna de las fases de la Implementacin del SQAP.

Incumplimiento con alguna de las secciones establecidas en el SQAP.

Por observacin de cualquiera de las organizaciones.

16.3. Implantacin de modificaciones Las modificaciones al SQAP, se harn en funcin al problema presentado de la siguiente manera: Detectar uno de los puntos especificados. Realizar un anlisis del problema. Realizar reuniones tcnicas con las reas involucradas en la modificacin del SQAP, estas reas adems de exponer problemas, darn recomendaciones para la modificacin correspondiente. Hacer la modificacin. Implementar la modificacin correspondiente.

Una vez finalizada la Implementacin se evaluar si fue correcta la modificacin y se promulgar la nueva versin del SQAP. La modificacin al SQAP, solo se realiza en las secciones del SQAP que sean afectadas por la observacin, este trabajo estar a cargo del grupo de SQA.

32

ANEXO A Formulario de RTF

PROYECTO DEFD REPORTE DE TRABAJOS ASIGNADOS Nro. Reporte: Flujo de trabajo: a) Material revisado Fase:

b) Breve descripcin

c) Material revisado (detallado por tem)

d) Aprobacin del producto Aceptado como esta No aceptado e) Recomendaciones Con modificaciones menores Revisin no terminada (explicar)

Equipo de trabajo: Integrante: Firma:

33

PROYECTO DEFD REPORTE SUMARIO DE FASES DEL PUDS Nro. Reporte: Flujo de trabajo: Fecha: __/__/__ Hora: __:__ Fase: Lugar:

a) Descripcin de tareas realizadas en la fase indicada

b) Sumario de resultados de tareas

c) Sumario de anomalas y resolucin

d) Evaluacin de calidad del software

e) Recomendaciones

Equipo de trabajo: Integrante: Firma:

34

PROYECTO DEFD REPORTE DE ANOMALIAS Nro. Reporte: Flujo de trabajo: Fecha: __/__/__ Hora: __:__ Fase: Lugar:

a) Descripcin y ubicacin

b) Impacto

c) Causa

d) Credibilidad Aceptado como esta No aceptado e) Recomendaciones Con modificaciones menores Revisin no terminada (explicar)

Equipo de trabajo: Integrante: Firma:

35

PROYECTO DEFD REPORTE FINAL DE PUDS Nro. Reporte: Flujo de trabajo: Fecha: __/__/__ Hora: __:__ Fase: Lugar:

a) Resumen de todas las tareas PUDS, durante el ciclo de vida del software

b) Resumen de resultados de tareas

c) Resumen de anomalas resolucin

d) Evaluacin total de la calidad del software

e) Recomendaciones

Equipo de trabajo: Integrante: Firma:

36

PROYECTO DEFD REPORTE DE PROBLEMAS Nro. Reporte: Flujo de trabajo: Fecha: __/__/__ Hora: __:__ Fase: Lugar:

a) Identificacin del problema

b) Descripcin

c) El evento ejecutado cuando se presento el problema es:

d) Posibles eventos del problema

Equipo de trabajo: Integrante: Firma

37

ANEXO B Bibliografa IEEE Std. 730 2002 Standard for Software Quality Assurance Plans. Rumbaugh James; Jacobson Ivar; Booch Grady El Proceso Unificado de Desarrollo de Software . Fundamentos de SQA - Curso Calidad y Mejoramiento de Procesos de Software, Meigen 2005-2006, Universidad Tcnica Federico Santa Mara

38