You are on page 1of 39

G-SOFT, DESARROLLO DE APLICACIONES MULTIPROPÓSITO

SQAP
Software Quality Assurance Plan
Nombre: Gerardo Miranda Céspedes Registro: 200983865

Version del documento: 1.0 Santa Cruz – Bolivia, 7 de mayo de 2013
El contenido de este plan de garantía 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 Administración ........................................................................................................................ 4 3.1. Organización ................................................................................................................... 4 Organización del equipo desarrollador ............................................................ 4 Organización 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 Estimación de recursos para SQA............................................................................. 9

Documentación ....................................................................................................................... 9 4.1. 4.2. 4.3. 4.4. 4.5. Propósito .......................................................................................................................... 9 Especificación de los requerimientos del software SRS ................................... 10 Descripción del diseño del software SDD ............................................................. 10 Plan de verificación y validación del software ..................................................... 12 Documentación del usuario ...................................................................................... 13

5.

Estándares, prácticas, convenciones y métricas ........................................................ 14 5.1. 5.2. Propósito ........................................................................................................................ 14 Contenido ....................................................................................................................... 15 Estándares de documentación ......................................................................... 15 Estándares de diseño.......................................................................................... 15 Estándares de codificación ............................................................................... 16 Métricas................................................................................................................... 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 Evaluación de la calidad de los productos ........................................................... 17 Objetivo ....................................................................................................................... 17 Mecanismo ................................................................................................................. 17

1

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

Revisión al ajuste al proceso .................................................................................... 18 Objetivo ....................................................................................................................... 18 Mecanismo ................................................................................................................. 18 Revisión técnica formal .............................................................................................. 19 Objetivo ....................................................................................................................... 19 Mecanismo ................................................................................................................. 19

Pruebas ................................................................................................................................... 20 Reportes de problemas y acciones correctivas........................................................... 20 Herramientas, técnicas y metodologías ......................................................................... 28 9.1. 9.2. Herramientas ................................................................................................................. 28 Metodología ................................................................................................................... 28 Control de contenido multimedia................................................................................. 28 Control de proveedores .................................................................................................. 28 Recolección, mantenimiento y retención 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 Implantación de modificaciones .............................................................................. 32

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

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

2

2. normas o métodos a aplicar.1.1. los métodos y procedimientos que se utilizarán para revisar que la elaboración de los productos se realice como lo establece el modelo de ciclo de vida del proyecto. Objetivo 1. Referencias  IEEE Std. 1. Objetivo del SQAP El propósito de este plan es especificar las actividades que se deberán realizar para poder asegurar la calidad del software a desarrollar. 2.  Convenciones para el lenguaje de programación Java – revisión de marzo de 2007  Perfil de Proyecto DEFD 3 .Software para que los usuarios puedan definir. guardar. y procedimientos para informar a los responsables de los productos los defectos encontrados y realizar un seguimiento de dichos defectos hasta su corrección. Aquí se detallan los productos que se van a revisar y los estándares. Alcance del SQAP Este plan es aplicable para los siguientes proyectos de software:  DEFD. 730 – 2002 Standard for Software Quality Assurance Plans. compartir y realizar sus propios tipos de diagramas.. El presente SQAP será aplicable a lo largo de todo el proceso de desarrollo.

Las disciplinas de gestión brindan soporte a las disciplinas básicas (Requerimientos. Administración 3.1. Organización El encargado del área de gestión de calidad en el proyecto es el responsable de realizar la gestión 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. debiendo responder por sus actividades ante el Consultor. Su trabajo estará regido en base a las especificaciones establecidas.1. Organización del equipo desarrollador Es la organización desarrolladora del producto de software.1. El equipo desarrollador está conformado por:     Director de equipo de desarrollo Jefe de desarrollo Analista Diseñador 4 . Las organizaciones involucradas en la implementación del producto de software son las siguientes:   Organización del equipo desarrollador Organización del grupo de SQA 3. Análisis.3. Implementación. Implantación y Verificación) y se realizan en forma paralela a ellas. La gestión de calidad es una disciplina de gestión. Diseño.

miembros administrativos de la empresa. En este grupo se toman decisiones según las normas establecidas para luego liberar versiones sucesivas del SQAP para el desarrollo del software.2. un experto en SQA y un experto en proyectos que actuará como consultor. 3. Los miembros del grupo de SQA son los siguientes:   Gerente Administrativo Director General 5 .   Programadores Documentadores Equipo de Pruebas El equipo de desarrollo estará organizado tal y como muestra el siguiente organigrama.1. Organización del grupo de SQA El grupo de SQA está conformado por miembros del equipo de desarrollo.

    3.1.2. 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 Revisión Técnica Formal Evaluar y ajustar el Plan de SQA Resultado Plan de SQA Propiedades de Calidad Informe de revisión de SQA Informe de revisión de SQA Informe de Revisión Técnica Formal Documento de Evaluación y Ajustes al Plan de SQA Revisar la entrega semanal Realizar evaluación final de SQA Reuniones de Apoyo a la calidad Entrega semanal de SQA Evaluación final de SQA No Aplica 6 . Tareas Experto en Proyectos de Software(Consultor) Experto en SQA Director de equipo de Desarrollo Jefe de Desarrollo 3.2.

2. Tareas de SQA durante el proceso de desarrollo de software Etapas Planificación Tareas Elaboración del plan de proyecto Revisión del plan de proyecto Requerimientos Análisis de requisitos de software Elaboración de especificaciones Revisión de especificaciones Diseño Revisión de adherencia del diseño a los estándares definidos Revisión de los módulos del software Revisión de las observaciones en el diseño Implementación Revisión del código Revisión y comparación del código y documentación del software Elaborar informes sobre desviaciones y las acciones correctivas Revisión de entregables Pruebas Revisión de resultados de pruebas de unidad Revisión de los resultados de las pruebas de integración del software Revisión de las pruebas funcionales y evaluación de resultados Mantenimiento Revisión de resultados de pruebas en ambiente real 7 .2.3.

director del equipo de desarrollo Grupo de SQA Revisión de las observaciones en el diseño Revisión del código Experto en SQA.3.3. Jefe de desarrollo. experto en proyectos Revisión del plan de proyecto Grupo de SQA Análisis de los requisitos de software Elaboración de especificaciones Equipo de desarrollo Equipo de desarrollo Revisión de especificaciones Grupo de SQA Revisión de adherencia del diseño a los estándares definidos Revisión de los módulos del software Experto en SQA. director del equipo de desarrollo Jefe de desarrollo Revisión y comparación del código con la documentación Elaborar informes sobre desviaciones y las acciones correctivas Revisión de entregables Revisión de resultados de pruebas de unidad Jefe de desarrollo Grupo de SQA Grupo de SQA Jefe de desarrollo Revisión de los resultados de las pruebas Jefe de desarrollo. Roles y Responsabilidades Tarea Elaboración del plan de proyecto Responsable Director del equipo de desarrollo. director del equipo de de integración del software desarrollo 8 . Jefe de desarrollo.

Para cada documento se indica el objetivo del documento. 9 .1. además de los elementos organizacionales responsables por esta documentación. norma y/o estándar que se usa para elaborar el documento y el contenido mínimo que debe tener dicho documento. Se incluye la siguiente documentación:     Especificación de los requerimientos del software Descripción del diseño del software. director del equipo de desarrollo Grupo de SQA 3. verificación y validación del software. en el apartado de estimaciones. Plan de verificación y validación del software Documentación del usuario. Estimación de recursos para SQA La estimación de recursos que estarán destinados al cumplimiento de este plan está detallada en el Plan de Administración del Proyecto de Software. la plantilla.Tarea Revisión de las pruebas funcionales y evaluación de resultados Revisión de resultados de pruebas en ambiente real Responsable Jefe de desarrollo. Identificar la documentación que requiera el desarrollo.4. Documentación 4. Propósito El objetivo de esta sección es especificar los documentos que dirigen el desarrollo del proyecto y que deberán ser revisados como parte de las actividades de aseguramiento de la calidad. 4.

Cada requerimiento deberá ser definido como para ser capaz de ser evaluarlo objetivamente por una metodología prescrita.4. Este documento estará apoyado en lo propuesto en el estándar [ANSI/IEEE-Std-730] – guía para especificaciones de requerimientos de software. demostración. rendimiento. se realizan conforme se especificado en esta sección.2. El grupo de SQA deberá identificar que estándares o guías se debe aplicar al contenido y formatos de la SRS. Descripción del diseño del software SDD La SDD debe describir los componentes principales del software incluyendo diseño de la base de datos e interfaces. y se lo conocerá a través del acrónimo en ingles SRS. análisis o pruebas. 10 . La SRS debe describir clara y precisamente cada uno de los requerimientos (funciones. restricciones de diseño y atributos) del software.3. la tabla que se muestra a continuación refleja el formato y contenido de las ERS que debe presentar el desarrollador. diseño. 4. Especificación de los requerimientos del software SRS La generación y documentación de las especificaciones de requisitos de software. rendimiento. Ver el [IEEE-Std-730] el cuál describe el contenido necesario de una excelente SRS. restricciones y atributos) del software. La SRS deberá describir clara y en forma precisa cada uno de los requerimientos (funciones. Una expansión de esta descripción debe describir cada subcomponente de los componentes principales. por ejemplo inspección.

3) Listar los componentes desde donde es invocado. limitaciones y efectos adyacentes. 11 . etc. 5) Definir el rango de valores esperados para todas las salidas. La SDD debe de ser preparado inicialmente como un SDD preliminar (nivel alto). Su función mas importante es describir una descomposición del sistema dentro de componentes (subsistemas. Para cada componente en el sistema. módulos.La SDD es una descripción técnica de como el software cumple con los requerimientos especificados anteriormente en la ERS. 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). 4) Definir el rango de valores permitidos para las entradas. El SDD estará sujeto a una revisión de diseño preliminar (PDR) y luego a la revisión del diseño crítico (CDR). 6) Describir Asunciones. y será subsecuentemente expandida para producir un SDD detallado.) los cuales deben ser bien definidos.

3. Referenced documents 3.1. ó pruebas) a ser usados:  Para verificar que los requerimientos en la SRS son implementados en el diseño expresado en la SDD.  Para verificar que el diseño expresado en la SDD es implementado en el código. Interface identification and diagrams 4. Requirements traceability 7.4. CSCI components Concept of execution Interface design 4. Appendixes 4.3. Scope 1. Identification System overview Document overview 2.1.2. DEFD-wide design decisions 4. DEFD architectural design 4. 1.3. 1.3.  Para validar que el código. demostración. 4. Plan de verificación y validación del software El SVVP describe los métodos (por ejemplo para inspección. análisis.2.1. DEFD detailed design 6. 4. cuando sea ejecutado cumpla con los requerimientos expresado en la SRS. Notes A. 12 .Contents 1.x (Project-unique identifier of interface) 5.

Esto incluirá los resultados. El contenido del SVVP será evaluado en la revisión del plan de verificación y validación del software SVVR El SVVR describe los resultados de la ejecución del SVVP. La documentación debería estar compuesta por los siguientes puntos: 1) Describir instrucciones de usuario la cual contenga: • Introducción 13 . verificaciones y pruebas requerida por el SQAP. métodos. Documentación del usuario La documentación del usuario (manual. guía. Las tareas. Consultar con el [ANSI/IEEE-Std829]. 4. y criterios para la verificación y validación deben ser descritos. etc. de todas las revisiones.5.) debe especificar: • Tipos de entradas de datos • Control de entradas • Secuencias de entradas • Descripción de resultados • Opciones • Limitaciones del software • Otras actividades necesarias para el éxito en la ejecución del software. El SVVP describe el plan total para toda la verificación y validación del software. El SVVR muestra el estado de las acciones correctivas planeadas. recomienda si el software esta listo o no para uso operacional.

5. convenciones y métricas 5. 14 . técnicas estadísticas a ser usadas. 4) Presentar ejemplos de todas las formas de ingreso de datos. • Descripción de entrenamiento necesario para el usuario. 2) Describir los objetivos del software. 6) Describir instrucciones de entrada de datos que contiene instrucciones para: • Preparar datos • Introducir datos • Verificación y validación del dato • Corrección de datos en caso de error. Propósito Identificar los estándares. 3) Especificar las entradas y salidas. prácticas. requerimientos de calidad y métricas a ser aplicadas en el desarrollo del proyecto. convenciones.1. 5) Presentar ejemplos de todas las salidas. 8) Describir todas las situaciones de error los cuales pueden ocurrir y como reaccionar cuando se presente.• Descripción de los usuarios que interactúan con el software. 7) Describir las limitaciones del sistema. Estándares. prácticas.

un índice. un glosario y bibliografía. Se puede hacer una excepción a esta regla únicamente en la portada del documento.  La utilización de letra cursiva a lo largo del documento está restringida solamente a referencias a documentos externos. direcciones de páginas web.. Estándares de documentación Con el objetivo de mantener toda la documentación del proyecto uniforme se definen las siguientes reglas concernientes al formato de la documentación del proyecto. en el lado izquierdo y de 2cm. tamaño 12.2.  La utilización de letra negrita a lo largo del documento está restringida solamente a los títulos.2.  Toda la documentación debe estar con letra Arial. incluyendo títulos y subtítulos.. mínimo en el lado superior.1. subtítulos y cuadros de contenido. debe ser agregado como anexo. Debe mantenerse un margen mínimo de 3cm. Estándares de diseño Para el proyecto que abarca este SQAP se ha establecido la utilización de los siguientes patrones de diseño:  Modelo Vista Controlador 15 . libros. En caso de que alguno de estos no esté presente en la estructura del documento. incluyendo este SQAP:   Los documentos deben estar impresos en hojas tamaño carta.2.2.5. 5. inferior y derecho. Contenido 5. autores.  Todos los documentos deben incluir una portada.

2. Revisiones 6. inspecciones. Con ello se adopta de la misma manera el estándar de codificación descrito en el documento Convenciones de código para el lenguaje de programación Java 5.2. Objetivo Esta sección tiene por objetivo definir las revisiones al software que serán llevadas a cabo.1.3. Para este documento en particular se definirán tres tipos de revisiones: Evaluación de la calidad de los productos. Métricas El objetivo del presente SQAP es asegurar la calidad del software desarrollado bajo él. paseos virtuales y auditorías. Corrección Facilidad de mantenimiento Integridad Facilidad de uso 16 . técnicas.  Observer Singleton 5. con este objetivo se utilizarán los siguientes indicadores para medir la calidad del software:     6. Estándares de codificación Se ha elegido Java como el lenguaje de programación que utilizará el proyecto abordado en este SQAP. revisión al ajuste al proceso y revisión técnica formal.4. Serán descritos tanto sus objetivos como sus mecanismos. incluyendo revisiones gerenciales.

para poder establecer los criterios de revisión y evaluar si el producto cumple con las especificaciones. 6.2. buscando hacia atrás los productos previos que deberían haberse generado y son entradas para el producto objeto de revisión.6. se debe verificar en los informes de revisión previos que todas las desviaciones fueron corregidas. que contiene todas las 17 . Objetivo Revisar los productos que se definieron como claves para asegurar la calidad.1. durante todo el ciclo de vida del software. las faltantes se incluyen para ser evaluadas. Antes de comenzar. Mecanismo Se revisan los productos que se definen como claves para verificar el cumplimiento de las actividades definidas en el proceso. Como salida se obtiene el Informe de revisión de SQA correspondiente a la evaluación de ajuste al Proceso.2. Se debe recoger la información necesaria de cada producto. Detectar desviaciones en los objetivos de calidad definidos e informar a los responsables para que sean corregidas. si no es así.2.2. Evaluación de la calidad de los productos 6. Esta información se obtiene de los siguientes documentos:    Plan del Proyecto Plan de la iteración Plan de Verificación Se debe verificar si todos los pasos del proceso de desarrollo son seguidos apropiadamente.

3. Revisión al ajuste al proceso 6. 6. 6. Objetivo Revisar si los productos se obtuvieron realizando las actividades que se indican en el Modelo de Proceso. 18 .desviaciones o defectos encontrados durante la revisión.1.2. para poder establecer los criterios de revisión y evaluar si el producto cumple con las especificaciones. Se debe recoger la información necesaria de cada producto.3.3. durante todo el ciclo de vida del software. 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. buscando hacia atrás los productos previos que deberían haberse generado y son las entradas para el producto objeto de revisión. Esta información se obtiene de los siguientes documentos:    Plan del Proyecto Plan de la iteración Plan de Verificación Se debe verificar si todos los pasos del proceso de desarrollo son seguidos apropiadamente. Mecanismo Se revisan los productos que se definen como claves para verificar el cumplimiento de las actividades definidas en el proceso.

su objetivo es llegar a detectar lo antes posible. Como salida se obtiene el Informe de revisión de SQA correspondiente a la evaluación de ajuste al Proceso. Se debe convocar a la reunión formalmente a los involucrados. informar del material que ellos deben preparar por adelantado. que contiene todas las desviaciones o defectos encontrados durante la revisión. verificar que satisface sus especificaciones. las faltantes se incluyen para ser evaluadas. Mecanismo Es un proceso de revisión riguroso. Objetivo Descubrir errores en la función. Revisión técnica formal 6. 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. En la reunión participan el responsable de SQA e integrantes del equipo de desarrollo.1. que se ajusta a los estándares establecidos. 6. señalando las posibles desviaciones detectadas.2.4. llevar 19 . 6. si no es así. los posibles defectos o desviaciones en los productos que se van generando a lo largo del desarrollo. se debe verificar en los informes de revisión previos que todas las desviaciones fueron corregidas.Antes de comenzar. Por esta característica se adopta esta práctica para productos que son de especial importancia. la lógica ó la implementación de cualquier producto del software.4.4.

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 técnicas formales que son dirigidas por un moderador. Todas las pruebas estarán descritas en el Plan de Verificación y Validación del Proyecto. descritos en el anexo A. Durante la corrección de cualquier artefacto. Como salida se obtiene el Informe de RTF.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 propósito. elaboración. 8. En cada una de las fases del proceso (inicio. Pruebas No aplicable a este documento. 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. construcción y transición) se realizaran las siguientes actividades para realizar el seguimiento de los errores: 20 . 7.

21 . especificador de casos de uso Proceso: (1) Revisar el modelo de casos de uso según la descripción de los defectos encontrados. (3) Notificar la terminación de la corrección al moderador. (5) El moderador certifica las correcciones del autor ii) Prototipo de interfaz de usuario Autor: Diseñador de interfaz de usuario Proceso: (1) Revisar el prototipo de interfaz de usuario según la descripción de los defectos encontrados. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (3) Notificar la terminación de la corrección al moderador.a) Captura de requisitos como casos de uso i) Modelo de casos de uso Autor: Analista de sistemas. (2) Corregir los defectos. (2) Corregir los defectos del prototipo de interfaz de usuario.

22 . (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor ii) Realización de casos de uso Autor: Ingeniero de casos de uso Proceso: (1) Revisar las realizaciones de casos de uso según la descripción de los defectos encontrados. (2) Corregir los defectos encontrados con respecto a las responsabilidades. (2) Corregir los defectos encontrados. (3) Notificar la terminación de la corrección al moderador.(5) El moderador certifica las correcciones del autor b) Análisis i) Clases del análisis Autor: Ingeniero de componentes Proceso: (1) Revisar las clases según la descripción de los defectos encontrados. (3) Notificar la terminación de la corrección al moderador. atributos y relaciones de las clases.

(3) Notificar la terminación de la corrección al moderador. (5) El moderador certifica las correcciones del autor iii) Paquetes del análisis Autor: Ingeniero de Componentes Proceso: (1) Revisar las los paquetes según la descripción de los defectos encontrados. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor iv) Descripción de la arquitectura del modelo de análisis Autor: Arquitecto Proceso: (1) Revisar la vista de la arquitectura del modelo de análisis según la descripción de los defectos encontrados. (2) Corregir los defectos encontrados. 23 . (2) Corregir los defectos encontrados. (3) Notificar la terminación de la corrección al moderador.(4) El moderador verifica la corrección satisfactoria de los defectos encontrados.

(4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (3) Notificar la terminación de la corrección al moderador. (5) El moderador certifica las correcciones del autor ii) Realización de casos de uso Autor: Ingeniero de casos de uso Proceso: (1) Revisar las realizaciones de casos de uso según la descripción de los defectos encontrados. 24 . (2) Corregir los defectos encontrados en los diagramas de clases y de interacción. (2) Corregir los defectos encontrados. (5) El moderador certifica las correcciones del autor c) Diseño i) Clases del diseño Autor: Ingeniero de componentes. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. Proceso: (1) Revisar las clases del diseño según la descripción de los defectos encontrados.

(3) Notificar la terminación de la corrección al moderador. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados.(3) Notificar la terminación de la corrección al moderador. (2) Corregir los defectos encontrados. (5) El moderador certifica las correcciones del autor iii) Descripción de la arquitectura del modelo de diseño Autor: Arquitecto Proceso: (1) Revisar la vista de la arquitectura del modelo de diseño según la descripción de los defectos encontrados. (5) El moderador certifica las correcciones del autor d) Implementación i) Descripción de la arquitectura del modelo de implementación Autor: Arquitecto Proceso: (1) Revisar la vista de la arquitectura del modelo de implementación según la descripción de los defectos encontrados. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. 25 . (2) Corregir los defectos encontrados.

(2) Corregir los defectos encontrados en el código fuente. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados.(3) Notificar la terminación de la corrección al moderador. (5) El moderador certifica las correcciones del autor ii) Código fuente de componentes Autor: Ingeniero de componentes Proceso: (1) Revisar el código fuente de los componentes según la descripción de los defectos encontrados. (2) Corregir los defectos encontrados en el plan. 26 . (3) Notificar la terminación de la corrección al moderador. (3) Notificar la terminación de la corrección al moderador. (5) El moderador certifica las correcciones del autor iii) Plan de integración del sistema Autor: Integrador de sistemas Proceso: (1) Revisar el plan de integración del sistema según la descripción de los defectos encontrados.

27 . (3) Notificar la terminación de la corrección al moderador. (2) Corregir los defectos encontrados en el plan. (5) El moderador certifica las correcciones del autor e) Pruebas i) Caso de prueba Autor: Diseñador de pruebas Proceso: (1) Revisar los casos de prueba del sistema según la descripción de los defectos encontrados.(4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (4) El moderador verifica la corrección satisfactoria de los defectos encontrados. (5) El moderador certifica las correcciones del autor ii) Plan de pruebas Autor: Diseñador de pruebas Proceso: (1) Revisar el plan de prueba del sistema según la descripción de los defectos encontrados. (3) Notificar la terminación de la corrección al moderador. (2) Corregir los defectos encontrados en los casos de prueba.

herramienta CASE. kit de desarrollo para java. Android SDK. Enterprise Architect. entorno de desarrollo.(4) El moderador verifica la corrección satisfactoria de los defectos encontrados. 28 . Herramientas. Control de proveedores No aplicable a este documento. 10. (5) El moderador certifica las correcciones del autor 9. entorno de desarrollo. técnicas y metodologías 9.7. Control de contenido multimedia No aplicable al presente documento. Herramientas Para la realización del software que abarca este SQAP se utilizarán las siguientes herramientas de software:       Netbeans 7. Motodev. porque el proyecto no hará uso de otro software comercial desarrollado por terceros.2. que es descrito con detalle en el perfil del proyecto DEFD.1. kit de desarrollo para android.1. Metodología La metodología de desarrollo elegida es el Proceso Unificado de Desarrollo de Software. editor de texto. porque la cantidad de contenido multimedia incluido en el software es prácticamente nula. 11. 9. Microsoft Office Word. JDK 1.

  Se debe proveer de una copia física al grupo de SQA. en este caso puede ser física o digital. 29 . 13. Con este propósito se definen a continuación reglas para el manejo de los registros. Entrenamiento Para una correcta aplicación del presente SQAP. la versión anterior debe mantenerse bajo las mismas condiciones descritas en los puntos anteriores Una vez finalizado el proyecto aún siguen vigentes los dos primeros puntos descritos anteriormente. para ello todos los registros generados por el proyecto deben ser correctamente administrados.  Debe existir una copia digital. se realizará de manera obligatoria el siguiente curso:  Conceptos Básicos de SQA. o escaneada en caso de ser documentación física. a lo largo del desarrollo del proyecto hasta su conclusión:  Debe existir al menos una copia física alojada en la sección de archivos de la empresa. El autor del documento o registro debe mantener una copia. Todas ellas son aplicables para la toda la documentación descrita en la sección 4 de este SQAP. mantenimiento y retención de registros Una parte importante dentro del SQA es conocer el estado del proceso. y que éste pueda ser gestionado. para todos los registros detallados en la sección 6 de este SQAP y para el presente documento. en el servidor FTP de la empresa. Recolección.12.  Si se obtuviera una nueva versión de un documento.

bajo criterio única y exclusivamente del experto en SQA. Otros cursos podrán ser programados en caso de ser necesarios. Glosario       SQA – Garantía de la calidad del software SQAP – Plan de garantía de la calidad del software IEEE – Instituto de ingenieros en electricidad y en electrónica Observer – Patrón de diseño y comportamiento de software Singleton – Patrón de diseño de software Servidor FTP – Software ejecutado en un servidor para almacenar y compartir archivos. Para realizar la planificación 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 aversión que indique cómo reducir la probabilidad de ocurrencia y cómo reducir el impacto en caso de presentarse una ocurrencia. 30 . Manejo de Riesgos La planificación del manejo de riesgos debe estar incluida en el Plan de Administración del Proyecto de Software del proyecto. 14.Impartido por el Experto en SQA al resto del grupo de SQA y al equipo de desarrollo. 15.

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

La modificación al SQAP. Implementar la modificación correspondiente. 32 . Realizar reuniones técnicas con las áreas involucradas en la modificación del SQAP. este trabajo estará a cargo del grupo de SQA. se harán en función al problema presentado de la siguiente manera:    Detectar uno de los puntos especificados.  Incumplimiento con alguna de las secciones establecidas en el SQAP.3.  Por observación de cualquiera de las organizaciones. en alguna de las fases de la Implementación del SQAP. Implantación de modificaciones Las modificaciones al SQAP. 16. Realizar un análisis del problema. Una vez finalizada la Implementación se evaluará si fue correcta la modificación y se promulgará la nueva versión del SQAP. estas áreas además de exponer problemas. solo se realiza en las secciones del SQAP que sean afectadas por la observación. darán recomendaciones para la modificación correspondiente.   Hacer la modificación. Se detectan problemas que modifican la línea base del SQAP.

ANEXO A Formulario de RTF PROYECTO DEFD REPORTE DE TRABAJOS ASIGNADOS Nro. Reporte: Flujo de trabajo: a) Material revisado Fase: b) Breve descripción c) Material revisado (detallado por ítem) d) Aprobación del producto Aceptado como esta No aceptado e) Recomendaciones Con modificaciones menores Revisión 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) Descripción de tareas realizadas en la fase indicada b) Sumario de resultados de tareas c) Sumario de anomalías y resolución d) Evaluación 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) Descripción y ubicación b) Impacto c) Causa d) Credibilidad Aceptado como esta No aceptado e) Recomendaciones Con modificaciones menores Revisión no terminada (explicar) Equipo de trabajo: Integrante: Firma: 35 .

Reporte: Flujo de trabajo: Fecha: __/__/__ Hora: __:__ Fase: Lugar: a) Resumen de todas las tareas PUDS.PROYECTO DEFD REPORTE FINAL DE PUDS Nro. durante el ciclo de vida del software b) Resumen de resultados de tareas c) Resumen de anomalías resolución d) Evaluación total de la calidad del software e) Recomendaciones Equipo de trabajo: Integrante: Firma: 36 .

Reporte: Flujo de trabajo: Fecha: __/__/__ Hora: __:__ Fase: Lugar: a) Identificación del problema b) Descripción c) El evento ejecutado cuando se presento el problema es: d) Posibles eventos del problema Equipo de trabajo: Integrante: Firma 37 .PROYECTO DEFD REPORTE DE PROBLEMAS Nro.

Curso Calidad y Mejoramiento de Procesos de Software. Meigen 2005-2006.  Rumbaugh James.ANEXO B Bibliografía  IEEE Std. 730 – 2002 Standard for Software Quality Assurance Plans. Booch Grady ‘’ El Proceso Unificado de Desarrollo de Software ‘’. Jacobson Ivar.  Fundamentos de SQA . Universidad Técnica Federico Santa María 38 .