1 Contenido

2 INTRODUCCION ........................................................................................................................... 4 SQAP .................................................................................................................................................... 5 3 ORGANIZACION ........................................................................................................................... 5

IES (Ingenieros Especializados en Software) ....................................................................................... 5 Mision..6 Visin................................................................................................................................................... 5 Poltica de Calidad .............................................................................................................................. 5 Patrn de Desarrollo .......................................................................................................................... 6 4 5 6 7 8 PROPOSITO .................................................................................................................................. 6 ACRNIMOS ................................................................................................................................ 6 DEFINICIONES .............................................................................................................................. 7 REFERENCIAS ............................................................................................................................... 7 GESTIN ...................................................................................................................................... 8 8.1 Organizacin........................................................................................................................ 8 Organizacin del Grupo de Desarrollo ........................................................................ 8 Organizacin del Especialista en SQA ......................................................................... 9 Organizacin del Cliente.............................................................................................. 9 Organizacin del Grupo SQA ....................................................................................... 9

8.1.1 8.1.2 8.1.3 8.1.4 8.2 8.3 9

Tareas ................................................................................................................................ 10 Responsabilidades ............................................................................................................. 13

Documentacin ......................................................................................................................... 14 9.1 Especificacinoes de Requerimientos (SRS) ........................................................................ 15 MODELO A USAR PARA EL CONTENIDO DEL SRS ...................................................... 15

9.1.1 9.2

Descripcion del Diseo(Arquitectura) DDS ....................................................................... 16 MODELO A USAR PARA EL CONTENIDO DEL DDS ..................................................... 18

9.2.1 9.3

Plan de Validacin y Verificacin(SVVP)............................................................................ 20 MODELO A USAR PARA EL CONTENIDO DEL (SVVP) ................................................. 20 Ciclo de Vida de Verificacin y Validacin................................................................. 20

9.3.1 9.3.2 9.4

Reportes de Verificacion ................................................................................................... 20

6.4.1 Reporte sumario de fases SVVP. .................................................................................. 21

9.4.2 6.4.3 9.5

Reporte de Anomalas. .............................................................................................. 22 Reporte Final SVVP. ................................................................................................... 23

Documento de Usuario ..................................................................................................... 24 Modo Instruccional ................................................................................................... 24 Modo de Referencia .................................................................................................. 24

9.5.1 9.5.2

6.4 Descripcin del uso de documentos ............................................................................ 25 6.5 Documentos relacionados ............................................................................................... 25 6.6 Convenciones ....................................................................................................................... 25 6.7 Instrucciones de reportes de problemas ................................................................... 25 9.6 9.7 Plan de Gestion de Configuracion (SCMP) ........................................................................ 27 Plan de Proyecto ............................................................................................................... 27 MODELO A USAR PARA EL CONTENIDO DEL PLAN DE PROYECTO ............................ 28

9.7.1 10 10.1 10.2 10.3 10.4 11 11.1 11.2 11.3

Estndares, prcticas y convenciones ................................................................................... 29 Estndares para Documentacin. ..................................................................................... 29 Estndar de Codificacin. .................................................................................................. 29 Estndar de Comentario. .................................................................................................. 31 Responsabilidades de Verificar el Cumplimiento.............................................................. 31 Revisiones del software......................................................................................................... 31 Propsito ........................................................................................................................... 31 Requerimientos Mnimos .................................................................................................. 32 Agenda .............................................................................................................................. 32 Revisar cada producto ............................................................................................... 33 Revisar el apego al proceso ....................................................................................... 36

11.3.1 11.3.2

Objetivo: ................................................................................................................................ 36 Mecanismo: ........................................................................................................................... 36 11.3.3 11.3.4 12 13 14 15 Revisar el ajuste al proceso: ...................................................................................... 37 Realizar Revisin Tcnica Formal .............................................................................. 38

Testeo .................................................................................................................................... 38 Informacin sobre problemas y accin correctiva ................................................................ 38 Herramientas, tcnicas y metodologas ................................................................................ 42 Control de cdigo .................................................................................................................. 42

16 17 18 19

Control de medios ................................................................................................................. 43 Recopilacin de registros, mantenimiento y retencin ........................................................ 43 Formacin.............................................................................................................................. 44 Gestin de Riesgos ................................................................................................................ 45

2 INTRODUCCION
El mundo actual se encuentra inmerso en cambios constantes y ms an tecnolgicos, donde todos y cada uno de los miembros que lo conforman se encuentran interrelacionados convergiendo en una constante competencia para ser sobresalientes, en definitiva en busca de ser los mejores. En efecto este inters hace que busquen el desarrollo integral de todas sus partes y elementos que los constituyen, en el cual dan importancia a un factor importante que es el control de calidad, que maneja el conjunto de tcnicas y actividades que

utilizanpara evaluar los requisitos que se deben cumplir respecto a la calidad del producto o servicio. Esto implica a que surjan nuevas exigencias, cambios y mejoras en su proceso, en el cual las organizaciones tendrn que cumplir con los nuevos requisitos, seguir procesos para satisfacer necesidades ms exigentes, teniendo que demostrar la calidad que tienen.

Muchas veces las entidades desarrolladoras de software tratan de realizar grandes cambios para lograr mejoras sustanciales en la actividad que realizan, sin embargo mediante pequeos cambios podemos incrementar su rendimiento y hacerlas superior, adicionndoles un control a los procesos para obtener resultados ms satisfactorios. Es por esta razn que nosotros tomamos en cuenta la creacin de un manual de calidad para ayudar a nuestra empresa a tomar la calidad como una ventaja competitiva, tomar a la calidad como la estrategia y la planificacin para que pueda mejorar su desempeo y satisfacer a sus clientes para que de esa manera vuelva a usar los servicios de nuestra empresa. Al requerir nuevamente el producto y lo recomiende con seguridad, permitir que la empresa tenga mejor supervivencia en el largo plazo.

Es por eso el presente manual para la empresa desarrolladora de software, el cual se encuentra fundamentado en la norma IEE730 es una recomendacin para elaborar un Plan de Aseguramiento de la Calidad del Software (SQAP, Software Quality Assurance Plan) para los proyectos de desarrollo de software.

Proporciona los requisitos mnimos aceptables para la preparacin y el contenido de los planes de aseguramiento de la calidad de software. Fue escrito para ser utilizado en las fases de desarrollo y mantenimiento del software. El plan SQA sirve como gua de las actividades de SQA en el proyecto.

SQAP
PLAN DE GARANTIA DE CALIDAD DEL SOFTWARE(SQAP)
3 ORGANIZACION
IES (Ingenieros Especializados en Software)

Slogan: No te esfuerces, nosotros lo haremos por ti! Misin

Convertirnos en actores importantes dentro del mercado del software y nuevas tecnologas a nivel nacional e internacional, ofreciendo a nuestros clientes soluciones tecnolgicas de avanzada.

Visin
Consolidarnos como una empresa de Software de la ms alta calidad capaz de brindar a travs de nuestros productos una solucin integral para el control ms eficiente del funcionamiento del rea de negocios de nuestros clientes.

Poltica de Calidad
Somos un equipo de trabajo cuyas acciones diarias las ejecutamos con una elevada vocacin de servicio a los Clientes en nuestra visin de empresa de categora mundial, basadas en los siguientes principios: 1. INTEGRIDAD PERSONAL como expresin de disciplina, orden, respeto, honestidad y entusiasmo.

2. CREATIVIDAD E INNOVACIN como parte de nuestro reto diario para el mejoramiento continuo. 3. PRODUCTIVIDAD en nuestro trabajo y en el empleo de los recursos. 4. CONSCIENCIA en la prctica de un trabajo libre de errores y en el COMPROMISO leal con nuestros clientes y con las realizaciones de calidad.

Patrn de Desarrollo Como patrn de desarrollo, utilizamos el Proceso Unificado de Desarrollo de

Software para crear software robusto de manera que garantice un proyecto correcto, tambin se trabaja con una programacin orientada a objetos para mejorar la estructura de nuestros software y programacin estructural para garantizar el mejor rendimiento posible. De esta forma, generar calidad de aplicaciones y productividad de la empresa.

4 PROPOSITO
El proposito de este plan es especificar las actividades que se realizan para asegurar la calidad de software a construir. En el se detallan los productos que se van a revisar y los estndares, normas o mtodos a aplicar, los mtodos y procedimientos que se utilizaran para revisar que la elaboracin de los productos se realice como lo establece el modelo de ciclo de vida del proyecto: para informar a los responsables de los productos los defectos encontrados y realizar un seguimiento de dichos defectos hasta su correccin.

5 ACRNIMOS
SQA: Aseguramiento de la Calidad del Software. SCM: Gestin de Configuracin del Software. GP: Gestin del Proyecto.

6 DEFINICIONES
Funcionalidad: capacidad del software para proporcionar funciones que satisfacen las necesidades fijadas y solicitadas, cuando el software se usa bajo condiciones especificadas. Fiabilidad: capacidad del software para mantener su nivel de funcionamiento, cuando se usa en condiciones especificas. Usabilidad: Capacidad del software para ser entendido, aprendido, usado y aceptado por el usuario. Eficiencia: Capacidad del software para proporcionar el funcionamiento requerido, relativo a la cantidad de recursos usados, bajo condiciones establecidas

7 REFERENCIAS
Para alcanzar la calidad total de los productos y la mejora continua, se utilizan los siguientes estndares: [1] IEEE Std 730-1998, IEEE Standard for Software Quality Assurance Plans. [2] IEEE Std 730.1-1995, IEEE Guide for Software Quality Assurance Planning. [4] IEEE Std 828: Anlisis de requerimientos del software [5] IEEE STD-829: Estndar para documentacin de pruebas de software. [6] IEEE STD-830: Estndar para especificacin de requerimientos de software. [7] IEEE STD-1012: Estndar para la planificacin de verificacin y validacin de software.

[8] IEEE STD-1063: Estndar para los manuales de usuarios de software.

8 GESTIN
El tema de esta seccin es relacionar los elementos de la Gestin de Calidad con las actividades especficas del proyecto y/o de SQA en la institucin, especificando organizacin, tareas y responsabilidades

8.1 Organizacin
La estructura organizativa que influye y controla la calidad del software es de la siguiente manera: 8.1.1 Organizacin de Grupo de Desarrollo de Software (CDS). Organizacin de Especialistas en SQA Organizacin del Cliente. Organizacin del grupo SQA Organizacin del Grupo de Desarrollo Es la organizacin encargada del desarrollo del software, su trabajo est regido de acuerdo a las especificaciones y contratos establecidos por el cliente. Para la empresa se encuentra estructurado de la siguiente forma: Lista de Personas 1 Gestor 2 Analistas 2 Diseador 3 Implementadores o programador 1 Agente de prueba

8.1.2

Organizacin del Especialista en SQA Es la organizacin fiscalizadora del producto de software, teniendo la potestad delegada por el cliente, para establecer normas, supervisar el desarrollo y hacer cumplir con los contratos establecidos. Generalmente el consultor toma el papel de intermediario entre el cliente y el grupo de desarrollo. Presenta la siguiente estructura: Lista de Personas 1 Gerente General 1 Experto en Proyectos 1 Experto en Ciencias de la Computacin 1 Secreataria

Organizacin y Organigrama
Gerente General

Secretaria

Expertos en Proyectos

Departamento de Informatica

Estos tipos de reactivo pueden avaluar muchos datos en un tiempo breve, adems que permiten la evolucin del aprendizaje en todos los niveles de complejidad, pueden ser confiables si se los desarrolla siguiendo los alineamientos establecidos para cada uno de ellos. 8.1.3 Organizacin del Cliente La organizacin del cliente depende de la estructura de su empresa o de la funcin que realice. Vara de acuerdo al proyecto de software que se est desarrollando. Organizacin del Grupo SQA Es la organizacin que discute las normas y sugerencias generadas por el consultor, para luego aceptarlas y liberar versiones sucesivas del SQAP para el desarrollo e implementacin del software, esta

8.1.4

organizacin se obtiene de las tres organizaciones anteriores. La especificacin de la organizacin de la SQA es la siguiente: Lista de Personas 1 Gerente Administrativo 1 Jefe de Departamento de Informtica 1 Experto en Proyectos 1 Experto en Ciencias de la Computacin 1 Director de Equipo de Desarrollo (Gestor)

8.2 Tareas
La relacin de tareas asociadas con el ciclo de vida de desarrollo de software y las actividades de la SQA son las siguientes, las cuales se ejecutarn durante el desarrollo del producto de software:
Actividad

Entregable Asociado Plan de SQA Plan de SQA

Elaboracin del Plan de SQA Identificar propiedades de Calidad

Evaluacin de la calidad de los Informe de revisin de SQA productos Revisar el ajuste al proceso Realizar Revisin Tcnica Formal Informe de revisin de SQA Informe Formal Evaluar y ajustar el Plan de SQA Documento de Evaluacin y de Revisin Tcnica

Ajustes al Plan de SQA Evaluacion final de SQA Revisar la entrega semanal Informe final de SQA Entrega semanal de SQA

CICLO DE VIDA DEL SOFTWARE (PUDS)

TAREAS Y ACTIVIDADES ASOCIADAS AL CICLO DE VIDA DEL SOFTWARE Capturar de requisitos de software Generacin de especificaciones

Requerimientos

Revisin de especificaciones Revisin de las especificaciones de software Anlisis de las especificaciones Revisin del anlisis

Anlisis

Anlisis detallado Revisin del anlisis detallado del software Diseo preliminar Generacin de especificaciones de diseo preliminar Revisin del diseo preliminar Diseo detallado

Diseo

Generacin de especificaciones de diseo detallado Revisin del diseo detallado Revisin del diseo preliminar Revisin del diseo detallado del software (Ambos versus las especificaciones) Codificacin Generacin de cdigo

Implementacin

Revisin de cdigo

Revisin de cdigo versus la documentacin generada Elaboracin de pruebas de unidad y generacin de resultados Revisin de resultados Elaboracin de las pruebas de unidad y de integracin del software Revisin de los resultados de las pruebas Revisin de las pruebas funcionales y evaluacin de los resultados Instalacin del producto software Prueba final bajo ambiente real Generacin de resultados de prueba Instalacin y Prueba Final Revisin de resultados Revisin de la instalacin del software y evaluacin de Resultados

Pruebas

Las actividades de SQA definidas en el modelo de proceso son: Entregable Asociado Plan de SQA Plan de SQA Informe de revisin de SQA Informe de revisin de SQA Informe de Revisin Tcnica Formal Documento de Evaluacin y Ajustes al Plan de SQA Informe final de SQA Entrega semanal de SQA

Actividad
Elaboracin del Plan de SQA Identificar propiedades de Calidad Evaluacin de la calidad de los productos Revisar el ajuste al proceso

Realizar Revisin Tcnica Formal

Evaluar y ajustar el Plan de SQA

Evaluacin final de SQA Revisar la entrega semanal

8.3 Responsabilidades
El responsable de SQA es el responsable de realizar las actividades y entregables mencionados en la seccin anterior. 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

Rol responsable

Responsable

9 Documentacin
se debe identificar la documentacin que asegura que la implementacin del software satisface los requerimientos planteados, la cual est compuesta segn el std. 730-1 como mnimo por la siguiente: Especificacin de Requerimientos (SRS) Descripcin del Diseo (Arquitectura) Plan de Verificacin y Validacin (SVVP) Reportes de Verificacin Documentacin de Usuario Plan de Gestin de Configuracin (SCMP) Plan del Proyecto Se identifica toda la documentacin que gobernar el desarrollo, validacin y verificacin, mantenimiento y uso del software.

9.1 Especificacinoes de Requerimientos (SRS)

Es elaborada por el desarrollador, y se basa en el estndar ANSI / IEEE Std 830 Gua par especificaciones de requerimientos de software (SRS). La SRS deber describir claramente y de forma precisa cada uno de los requerimientos del software, tal como: funciones, rendimiento, restricciones de diseo y atributos. 9.1.1 MODELO A USAR PARA EL CONTENIDO DEL SRS 1. INTRODUCION 1.1Objetivo 1.2Alcance 1.3Definiciones, acrnimos y abreviaciones 1.4Referencias 1.5Revisin 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. APENDICES 5. INDICE 6. ANEXOS

9.2 Descripcion del Diseo(Arquitectura) 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

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

Identificacin, tipo, objetivo, dependencias, recursos.

Diagrama de estructura.

Descripcin de interfaces

Lista de cada interfaz de diseador, programador, o pruebas Descripcin de los detalles de diseo internos en una entidad.

Identificacin, funcin, interfaces.

Tablas de parmetros.

Descripcin de detalle

Identificacin, procesamiento, datos.

Diagrama de flujos.

9.2.1

MODELO A USAR PARA EL CONTENIDO DEL DDS 1. INTRODUCION Objetivo Alcance Definiciones, acrnimos y abreviaciones 2. REFERENCIAS 3. DESCRIPCION DE DESCOMPOSICION 3.1. Descomposicin de mdulo 3.1.1. Descripcin del mdulo 1 3.1.2. Descripcin del mdulo 2 3.1.n. Descripcin del mdulo n 3.2. Descomposicin de procesos concurrentes 3.2.1. Descripcin del proceso 1 3.2.2. Descripcin del proceso 2 3.2.n. Descripcin del proceso n 3.3. Descomposicin de datos 3.3.1. Descripcin de la entidad de datos 1 3.3.2. Descripcin de la entidad de datos 2 3.3.n. Descripcin de la entidad de datos n 4. DESCRIPCION DE DEPENDENCIA Dependencia entre mdulos Dependencia entre procesos Dependencia entre datos 5. DESCRIPCION DE INTERFACES Interfaces de mdulo 5.1.1. Descripcin del mdulo 1 5.1.2. Descripcin del mdulo 2

 5.1.n. Descripcin del mdulo n

5.2 Interfaces de procesos 5.2.1. Descripcin del proceso 1 5.2.2. Descripcin del proceso 2 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.2. Detalle del mdulo 2 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 6.2.n. Detalle de entidad de datos n APENDICES INDICE ANEXOS

9.3 Plan de Validacin y Verificacin(SVVP)

La generacin y documentacin del Plan de Verificacin y Validacin (SVVP) es la siguiente: 9.3.1 MODELO A USAR PARA EL CONTENIDO DEL (SVVP) 1. OBJETIVO 2. ALCANCE 3. DEFINICIONES, ACRONIMOS Y ABREVIACIONES 4. ORGANIZACIN RESPONSABLES 5. CICLO DE VIDA DE VERIFICACION Y VALIDACION APENDICE INDICE 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. 9.3.2 Ciclo de Vida de Verificacin y Validacin. El plan se basa en el siguiente ciclo de vida del software: Fase Fase Fase Fase Fase Fase de de de de de de requerimientos diseo implementacin prueba instalacin y prueba operacin y mantenimiento

9.4 Reportes de Verificacion

El formato para los reportes de los resultados de la implementacin del plan de verificacin y validacin del software es la siguiente:

6.4.1 Reporte sumario de fases SVVP.

9.4.2

Reporte de Anomalas.

6.4.3

Reporte Final SVVP.

9.5

Documento de Usuario

Esta descripcin de documentacin de usuario 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). 9.5.1 Modo Instruccional

Un modo instruccional de documento debe: 9.5.2 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.

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. MODELO A USAR PARA EL CONTENIDO DE LA DOCUENTACION DE USUARIO TITULO DE LA PAGINA RESTRICCIONES GARANTIAS Y OBLIGACIONES CONTRACTUALES TABLA DE CONTENIDO LISTA DE ILUSTRACIONES INTRODUCCION Descripcin de audiencia Declaracin de aplicacin Declaracin de objetivos 6.4 Descripcin del uso de documentos 6.5 Documentos relacionados 6.6 Convenciones 6.6.1 Smbolos 6.6.2 Convenciones de estilo 6.6.3 Convenciones de sintaxis de comandos 6.7 Instrucciones de reportes de problemas CUERPO DEL DOCUMENTO

7.1. Cuerpo del documento en modo instruccional 7.1.1 Alcance 7.1.2 Materiales 7.1.3 Preparaciones 7.1.4 Precauciones y prevenciones 7.1.5 Mtodos 7.1.6 Informacin relacionada 7.2. Cuerpo del documento en modo de referencia 7.2.1 Objetivo 7.2.2 Materiales 7.2.3 Preparaciones 7.2.4 Entradas 7.2.5 Precauciones y prevenciones 7.2.6 Invocacin 7.2.7 Operaciones de suspensin 7.2.8 Operaciones de terminacin 7.2.9 Salidas 7.2.10 Condiciones de error 7.2.11 Informacin relacionada MENSAJES DE ERROR, CONOCIMIENTO DE PROBLEMAS, RECUPERACION DE ERROR ANEXOS 10. BIBLIOGRAFIA 11. GLOSARIO 12. INDICE

9.6 Plan de Gestion de Configuracion (SCMP)

La gestin de configuracin del software es una actividad de autoproteccin que se aplica durante el proceso del software. Como el cambio se puede producir en cualquier momento, las actividades de GCS sirven para: Identificar el cambio. Controlar el cambio. Garantizar que el cambio se implementa adecuadamente. Informar del cambio a todos aquellos que puedan estar interesados.

Es importante distinguir claramente entre el mantenimiento del software y la gestin de configuracin del software. El mantenimiento es un conjunto de actividades de ingeniera del software que se producen despus de que el software se haya entregado al cliente y est en funcionamiento. La gestin de configuracin del software es un conjunto de actividades de seguimiento y control que comienzan cuando se inicia el proyecto de ingeniera del software y termina slo cuando el software queda fuera de la circulacin. Para controlar y gestionar los elementos de configuracin, se debe identificar cada uno de forma nica y luego organizarlos mediante un enfoque orientado a objetos. Se pueden identificar dos tipos de objetos: objetos bsicos y objetos compuestos.

9.7

Plan de Proyecto

La gestin de un proyecto de software comienza con un conjunto de actividades que globalmente se denominan planificacin del proyecto. Antes de que el proyecto comience, el gestor y el equipo de software deben realizar una estimacin del trabajo a realizar, de recursos necesarios y del tiempo que transcurrir desde el comienzo hasta el final de su realizacin. Siempre que

estimamos, estamos mirando hacia el futuro y aceptamos resignados cierto grado de incertidumbre. 9.7.1 MODELO A USAR PARA EL CONTENIDO DEL PLAN DE PROYECTO 1 PLAN DE PROYECTO 2 INTRODUCCIN 2.1 Propsito del Plan 2.2 mbito del Proyecto y Objetivos 2.2.1 2.2.2 2.2.3 2.2.4 2.2.5 2.2.6 2.2.7 2.2.8 2.2.9 Antecedentes Descripcin del problema Situacin Problemtica Objetivos Justificacin Funciones Principales Alcance del Proyecto Aspectos de Rendimiento Restricciones Tcnicas y de Gestin

3 Estimaciones del Proyecto 3.1 Datos Histricos usados para las estimaciones 3.1.1 3.1.2 3.2.5 Mtricas Orientadas al Tamao Mtricas Orientadas a la Funcin Ecuacin del Software

3.3 Conciliacin de las Estimaciones 3.2.1 3.2.2 3.2.3 3.2.4 Riesgo 4 GESTIN DE RIESGO 4.1 Tabla de Riesgos 4.2 Plan RSGR para cada 4.2.1 Reduccin de Riesgo Estimaciones Basadas en Lneas de Cdigo COCOMO I COCOMO II Calculo del Esfuerzo

4.2.1 Supervisor del Riesgo 5 PLANIFICACIN TEMPORAL 6 RECURSOS DEL PROYECTO 7 ORGANIZACIN DEL PERSONAL 7.1 Estructura del Equipo 8 MECANISMOS DE SEGUIMIENTO Y CONTROL 8.1 Formularios para RTF 8.2 Recurso

10 Estndares, prcticas y convenciones

se identifican los estndares definidos para el proyecto, como normas de documentacin, de cdificacin, notacin UML, normas IEEE que aplican, etc. y de que forma se asegurar el cumplimiento de los mismos.

10.1 Estndares para Documentacin.

La documentacin del software se realizara en Word que estar compuesta por: un ndice Desarrollo de este Con determinada sangra, interlineado Separado por partes

10.2 Estndar de Codificacin.

La codificacin del software se realizar en la plataforma Java. Que 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 o Nombre de las salidas: - Base de Datos - Archivos - Registros - Formatos de pantalla - Reportes o Nombre de los archivos de actualizacin: - Base de Datos - Archivos - Registros o Nombre del autor o Fecha de creacin o Historial de actualizaciones - Versin - Fecha de cambio - 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. 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 Nombre Fecha y hora de creacin Autor Nombre del mdulo al que pertenece Funcionalidad

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

10.4 Responsabilidades de Verificar el Cumplimiento.

Los responsables de realizar la verificacin del cumplimiento con los estndares definidos son: El jefe del equipo de desarrollo. La organizacin del SQA.

11 Revisiones del software

11.1 Propsito
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. 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: Se deben llevar a cabo, al menos, las siguientes revisiones y auditorias: Conocer el progreso alcanzado en el desarrollo. Evaluar el ajuste a los requerimientos del sistema. Evaluar la eficiencia en el trabajo.

11.2 Requerimientos Mnimos

Los elementos mnimos que debern ser revisados son: 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

11.3 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

Revisin

Tipo de revisin

Nombre del entregable o producto a revisar

Fase, iteracin y semana en que se debe realizar la versin del producto a revisar

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 Y as sucesivamente para cada una de las fases del ciclo de vida de desarrollo de software. 11.3.1 Revisar cada producto 11.3.1.1 Auditoria Funcional: Esta verificacin es realizada antes de la entrega del software, para verificar que todos los requerimientos especificados en la ERS fueron alcanzados. La verificacin funcional compara el cdigo con los requerimientos documentados del software, como se estableci en ERS. Su propsito es asegurar que el cdigo hace todo y solo lo que se indica en la documentacin establecida por la ERS. Se definen los siguientes puntos: Nomenclatura Nmero de identificacin de la especificacin Nmero de tem de configuracin La especificacin de requerimientos de software Copia de cdigo objeto

Listado actualizado de tems de configuracin especificados El reporte de verificacin y validacin del software Listado del cumplimiento exitoso de pruebas funcionales Listado de todo lo planificado y pruebas que no fueron ejecutadas Actualizaciones para la documentacin previamente liberada deber ser revisada para asegurar su exactitud y consistencia

11.3.1.2 Auditoria Fsica: Esta verificacin es realizada para verificar que el software y su documentacin son internamente consistentes y estn listas para su entrega. La verificacin fsica compara el cdigo con su documentacin de soporte, su propsito es asegurar que la documentacin a ser entregada describa correctamente el cdigo. La documentacin necesaria para realizar la verificacin fsica es la siguiente: Descripcin del diseo del software DDS Productos de software Documentacin asociada

Para proveer evidencia de un adecuado control del contenido del sistema y consistencia del equipo de auditoria se examina lo siguiente: Los documentos de especificacin del sistema para formatos y cumplimientos Reportes funcionales para discrepancia y acciones tomadas Descripcin del diseo para smbolos, etiquetas, referencias y descripcin de datos Los manuales para formatos de completitud y cumplimiento con la descripcin de datos. Los elementos de software liberados en el medio son ptimos para transferir y transmitir Identificar los cambios en los tems de configuracin de datos

11.3.1.3 Auditorias del Proceso: Estas verificaciones sern desarrolladas dentro de los procesos de desarrollo del software, como ser el diseo para verificar la consistencia del diseo incluyendo: Cdigo versus documentacin del diseo Especificaciones de interfaces hardware / software. Implementacin de diseo versus requerimientos funcionales

El objetivo es verificar la consistencia del producto a travs del proceso del desarrollo para determinar que: Las interfaces hardware/software sean consistentes con el diseo de requerimientos en la ERS. Los requerimientos funcionales de la ERS, sean completamente probados por el SVVP. El diseo del producto especificado en la DDS, satisface los requerimientos funcionales del ERS. El cdigo es consistente con la DDS.

11.3.1.4 Revisiones de gestin: Estas revisiones son realizadas peridicamente para evaluar la ejecucin del SQAP. Estas revisiones debern ser realizadas por el elemento organizacional del consultor. Para cada tipo de revisin, se debe explicar: Su objetivo. Qu producto es el que se evala. Sus propsitos. Cul es el elemento organizativo responsable de llevar a cabo la revisin. Cules son los elementos organizativos que deben tomar parte de la revisin. Cules son los requisitos de revisin.

Dnde deben documentarse los resultados de la revisin.

Para cada tipo de auditoria se debe explicar: Su objetivo. Cul es el elemento organizativo responsable de llevar a cabo la auditoria. Dnde deben documentarse los resultados de la auditoria. Cules son las entradas para la auditoria.

Se definen los tres tipos de revisiones (Evaluacin de la calidad de los productos, Revisar el ajuste al proceso y Revisin Tcnica Formal RTF), sus objetivos y mecanismos. 11.3.2 Revisar el apego al proceso 11.3.2.1 Evaluacin de la calidad de los productos: 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. Mecanismo: Se revisan los productos para verificar que cumplan con los estndares y con los objetivos de calidad definidas para el producto. Se debe verificar que no queden correcciones sin resolver en los informes de revisin previos, si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisin. Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar que se hayan realizado las correcciones. Como salida se obtiene el Informe de revisin de SQA, que contiene todas las desviaciones o defectos encontrados durante la revisin. Este informe debe ser distribuido a los responsables del producto y se debe

asegurar que ellos son conscientes de las desviaciones o discrepancias encontradas y de las acciones correctivas que deben realizar. 11.3.3 Revisar el ajuste al proceso: Objetivo: Revisar si los productos se obtuvieron realizando las actividades que se indican en el Modelo de Proceso. 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 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.

11.3.4 Realizar Revisin Tcnica Formal 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.

12 Testeo
se deben detallar, si existieran, las pruebas que se realizarn sobre el software cubierto por el SQAP y que no estn includas en el Plan de Verificacin y Validacin (SVVP), por ejemplo de propiedades de calidad identificadas que as lo requieran

13 Informacin sobre problemas y accin correctiva

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

# De Reporte: Lugar:

Fecha: 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 Registrar las causas sospechosas del origen del problema, esto asegura que no se descarta ninguna situacin posible. o o Registrar causas adicionales Registrar causas plenamente identificadas, esto es, causas verificadas por detectores del problema o Registrar otras causas externas o relacionadas a las identificadas anteriormente 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.

14 Herramientas, tcnicas y metodologas

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 Specifications ANSI / IEEE STD 1016 Descriptions ANSI / IEEE STD 1008 Standard for Software Unit Testing ANSI / IEEE STD 1063 Standard for Software User Documentation ANSI / IEEE STD 1028 Standard for Software Reviews and Audits Recommended Practice for Software Design Guide for Software Requirements

Las metodologas de Aseguramiento de Calidad sern conjuntos integrados de tcnicas, de entre los anteriores.

15 Control de cdigo
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. Se especifica un procedimiento de control del Cdigo que: 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.

16 Control de medios
El medio del programa de computadora se define como aquellos medios sobre los cuales los datos 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.

17 Recopilacin de registros, mantenimiento y retencin

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.

18 Formacin
CIS 740 Software Engineering CIS 748 Software Management CIS 771 Software Specifications CIS 890 Agent-Oriented Software Engineerin

19 Gestin de Riesgos
Riesgos Probabilidad de Presencia Probabilida d de Impacto Influyente

R1. El tamao estimado es menor al tamao real del software. R2. El personal no cuenta con la debida experiencia. R3. La fecha de entrega es muy limitada. R4. El cliente no est contento con el sistema. R5. El cliente no est preparado para la utilizacin del sistema. R6. La reutilizacin es menor a la prevista. R7. Habr muchos cambios de personal. R8. La complejidad del Software es mayor a la prevista

45%

60% 50% 30% 40% 70% 20%

Crtico Influyente Crtico Moderado Influyente Moderado

25%

Influyente

Reduccin de Riesgo Riesgo N1:

Contar con datos histricos fiables y que sean proporcionadas por empresas similares en el medio.
Riesgo N2:

Durante el transcurso del desarrollo del software, capacitar al personal en las herramientas que se utilizarn durante la fase de codificacin. Riesgo N3:

Negociar con el cliente un tiempo adicional para la entrega del producto en caso de presentarse algunas dificultades en el proceso de desarrollo.
Riesgo N4:

Durante el transcurso del desarrollo del software, tener una estrecha comunicacin con el cliente. Riesgo N5:

Planificar cursos de capacitacin a los usuarios finales ya sea durante la fase de pruebas o mantenimiento.
Riesgo N6:

Poner mayor atencin en la recopilacin de requisitos durante la fase inicial o Ingeniera del Software.
Riesgo N7:

Pedir al personal alguna garanta o compromiso por escrito de que cumplir con sus obligaciones. Riesgo N8:

Utilizar componentes ya desarrollados y acomodarlos al proyecto.

Supervisin de Riesgos
Riesgo N1: Nombrar una persona del equipo de desarrollo que se encargue de las estadsticas propias de los proyectos ya realizados mediante la creacin de una base da datos amplios y confiables. Riesgo N2: Fijar horarios dentro de los cules, el personal estar obligado a aprender el uso de una herramienta especfica. Riesgo N3: El gestor de proyectos se har cargo de la negociacin de un tiempo de holgura para la entrega del producto. Riesgo N4: El gestor deber planificar la cantidad necesaria de reuniones con el cliente a fin de que recabar todos los requisitos.

Riesgo N5: Fijar horarios para un curso de capacitar a los usuarios finales del sistema. Riesgo N6: l gestor se encargar de la redaccin de los contratos para el personal restante. Riesgo N7: Obligar a los desarrolladores que se programe utilizando estndares de codificacin. Riesgo N8: Modularizar el proyecto al mximo posible y as reducir los problemas que se presenten para que sean mas fciles de encarar.