SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SISTEMA DE CONTROL DE USUARIOS (SCU) PLAN DE ASEGURAMIENTO DE LA CALIDAD

CONTROL DE LA CONFIGURACION #0 3 DE MARZO DEL 2009

Sptimo semestre ingeniera de software

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SISTEMA DE CONTROL DE USARIOS PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL SOFTWARE

CONTROL DE LA CONFIGURACION # 3 DE DICIEMBRE DEL 2009

Aprobacin del plan de SQA: ______________________ Administrador de SQA ______________________ Administrador del proyecto ____________ Fecha ____________ Fecha

iii

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

PREFACIO
Este documento contiene el plan de aseguramiento de la calidad del proyecto SCU, este documento esta relacionado fuertemente con el plan de desarrollo de software por lo que es consistente con el plan. Este documento solo puede ser modificado por el equipo de SQA

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

REGISTRO DE CAMBIOS
*A - aadido M - modificado B- Borrado Numero de version 0.1 fecha Numero de figura, tabla , prrafo o seccin Seccin 5.3.1 y 5.3.2 A* M B A titulo o una breve descripcin Numero de peticin de cambio 1

03/03/09

Se agregaron estndares para la descripcin de los requisitos que satisface cada diagrama en el diseo, clase o mtodo

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

TABLA DE CONTENIDO
Seccin Pgina

5. 3 ESTNDARES DE DISEO Y CODIFICACION..............................................................................2 SECCIN 6: PRUEBAS.............................................................................................................................1 SECCIN 9. CONTROL DE CDIGO......................................................................................................1 SECCION 11. ADMINISTRACION DE RIESGOS...................................................................................1 CHECKLISTS.............................................................................................................................................1

vii

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 1. PROPOSITO
El propsito de este plan es definir un plan de aseguramiento de la calidad del software para el sistema de control de usuarios, asignacin de responsabilidades y tareas de SQA, proveer documentos, guas para llevar a cabo el plan de SQA., proveer las herramientas para hacer los reportes de SQA.

1.1 ALCANCE
Este documento establece todas las actividades de SQA a ser realizadas durante el ciclo de vida de desarrollo del sistema de control de usuarios (SCU). La meta del plan de aseguramiento es verificar que todo software y documentacin liberados cumpla con todos los requerimientos tcnicos establecidos.

1.2 IDENTIFICACION
Los elementos que esta a continuacin son a los que se les aplicara el plan de aseguramiento de la configuracin.
Al cliente SRS Manuales de usuario y de ayuda Trabajos internos SQAP SDP SQM Especificacin del diseo Planes y Resultados de Pruebas Estndares y Procedimientos ndice y bitcora de la lnea base Productos adquiridos Herramientas Sistemas operativos Herramientas de programacin

1.3 VISTA GENERAL DEL SISTEMA

SCU, de las siglas Sistema de Control de Usuarios, es un sistema enfocado a la administracin de recursos de Tecnologas de Informacin.

1.4 VISTA GENERAL DEL DOCUMENTO

Este de documento contiene toda la organizacin y procedimientos a ser usadas para llevar a cabo en el plan SQA del proyecto SCU. En la seccin 1 se idntica el sistema al que se le va aplicar este plan, se hace una pequea descripcin del sistema, se identifican otros documentos de administracin relacionados con el plan SQA. Se describe el propsito del plan SQA. En la seccin 2 se describe cada elemento de la organizacin que influye en la calidad del software.

1-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

Seccin 3: se describen las tareas de aseguramiento de la calidad del software. Seccin 4: lista los documentos que estn en la lnea base o van a estar en la lnea base, durante el desarrollo del proyecto. Seccin 5: describe todos los convenios, estndares y prcticas a ser usadas en el desarrollo del proyecto. Seccin 6: describe el rol que tiene SQA en las pruebas. Seccin 7: describe los reportes de errores y las acciones correctivas. Seccin 8: describe herramientas de SQA, tcnicas y metodologas. Seccin 9: describe la herramienta usada en administracin de la configuracin para el control del cdigo. Seccin 10: describe los entrenamientos requeridos para SQA. Seccin 11: describe la evaluacin de SQA del proceso de prevencin de riesgos. Apndice A: contiene una lista de acrnimos. Apndice B: contiene checklists a ser usadas durante el desarrollo del proyecto, estos ser para verificar que todos los procesos sea realizados con aseguramiento de la calidad.

1.5 RELACION CON OTROS PLANES

El plan de aseguramiento de la calidad esta implementado de acuerdo al plan de configuracin del software y el plan de desarrollo del software. Todos los procesos definidos en el plan de aseguramiento de la calidad, que se usaran durante el ciclo de vida del proyecto, estn basados en los procesos definidos en el plan de desarrollo del software.

1-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

1.6 RFEFERENCIAS
a) plan de desarrollo de software. b) Plan de administracin de la configuracin del software. c) Plan de administracin de riesgos.

1-3

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 2. ADMINISTRACION
Esta seccin describe cada elemento o rea de la organizacin que influye en la calidad del software.

2.1 ORGANISAZION
En la siguiente figura se muestra la organizacin y los elementos que lo conforman todos estos debe de tener una cierta influencia en el plan de aseguramiento re la calidad.

Figura 2-1. Organizacin SCU

A continuacin se describe el rol que tiene cada elemento en el plan de aseguramiento de la calidad del software. 1) La Gerencia es el responsable de: a. todo el aspecto administrativo y econmico.

b. Es a quien el equipo de SQA debe informar en caso de errores grabes en el producto de trabajo. c. Aprobar el documento SQA.

2) SQA es responsable de: a. Es el encargado de definir el plan SQA b. Es el de ejecutar el plan

2-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

c. De verificar que todo lo establecido se siga al pie de la letra. d. Es el responsable de verificar que todos los productos liberados cumplan con los requisitos de calidad establecidos. e. Realizar las inspecciones. f. Revisiones tcnicas de los productos de software elaborados.

3) Administracin de proyecto es responsable de: a. Implementar el plan de calidad establecidos en el plan de SQA. b. Identificar las actividades de SQA a ser llevadas a cabo por el equipo de SQA. c. Revisar y aprobar el plan de SQA. d. Identificar a una persona o grupo de personas del proyecto para llevar a cabo las tareas de SQA e. Identificar y darle seguimiento a cualquier problema de calidad reportado por SQA. f. Identificar y asegurar todos los factores a ser implementados en el sistema y en el software.

g. Identificar, desarrollar y dar mantenimiento documentos de planeacin tales como: el plan de desarrollo de software y el plan de aseguramiento de la calidad del software.

4) Diseo/desarrollo de software son responsables de: a. Revisar y comentar acerca de plan de SQA. b. Implementar el plan de calidad establecido en el plan. c. Identificar y darle seguimiento a cualquier problema de calidad reportado por SQA, que est relacionado con el diseo y el desarrollo de producto. d. Identificar, implementar y evaluar los factores de calidad a ser implementados en el software. e. Implementar las prcticas, procesos y estndares de desarrollo y diseo especificados en el plan de desarrollo del software y en el plan de SQA.

2-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

5) Pruebas de software es responsable de: a. Revisar y comentar acerca del plan de aseguramiento de la calidad del software. b. El equipo de SQA es el encargado de ejecutar las pruebas c. Implementar el programa de calidad establecidos en el plan de aseguramiento de la calidad. d. Resolver y darle seguimiento a todos los problemas de calidad identificados por SQA relacionados con las pruebas de software. e. Verificar que los factores de calidad estn implementados en el sistema, especialmente en el software.

6) Administracin de la configuracin del software: a. Revisar y comentar acerca del plan de aseguramiento de la calidad del software. b. Implementar el plan de calidad acordado en este document de SQA c. Resolver y darle seguimiento a todos los problemas de calidad identificados por SQA relacionados con ACS. d. Asegurar de que el software cumple con los factores de calidad establecidos por ACS e. Implementar las prcticas, procesos y procedimientos establecidos en el plan de desarrollo de proyecto.

2.2 Recursos 2.2.1 instalaciones y equipos El equipo de SQA tendr acceso a las instalaciones y equipos definidos en el plan de desarrollo del software, el quipo de SQA tendr acceso a los recursos computacionales para realizar las funciones tales como: evaluar los productos o realizar las auditorias. 2.2.2 personal. El perfil de los integrantes de SQA es el siguiente: 1) debe estar familiarizado con las pruebas de software. 2) Debe conocer las partes de un plan de aseguramiento de la calidad de software.

2-3

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

3) El conocimiento en diseo, cdigo, anlisis estructural y pruebas de software. 4) Debe conocer los planes de: a. Plan de desarrollo del software b. Administracin de la configuracin del software c. Administracin de riesgos 5) Trabajar en equipo. El administrador de SQA debe dominar los temas ya mencionados.

2-4

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 3. TAREAS DE SQA

En esta seccin se listan todas las tareas que el equipo de SQA realizara, estas tareas sern durante todo el ciclo de vida del proyecto, y se realizaran segn la calendarizacin descrita en el plan de desarrollo del software. Una tarea se considerara completa si se ha levantado un reporte acerca de esa tarea. Las siguientes tareas requieren de la coordinacin y cooperacin de equipo de desarrollo para ser llevadas a cabo de forma satisfactoria por el equipo de SQA.

3.1 TAREA: REVISAR LOS PRODUCTOS DE SOFTWARE

El plan de desarrollo de software identifica todos los productos de software a ser desarrollados y evaluados e igual que los estndares o reglas a seguir. Es necesario que el equipo de SQA ayude a la administracin del proyecto, los estndares y los lineamientos a seguir en el desarrollo del proyecto. En la seccin 4 se listan los productos de software a ser considerados por SQA y los procesos de revisin a ser seguidos.

3.2 TAREA: EVALUAR LAS HERRAMIENSTAS DE SOFTWARE

SQA deber evaluar las herramientas, tanto existentes como las que se planean obtener, usadas para el desarrollo y soporte, durante el desarrollo del proyecto. Las herramientas son evaluadas teniendo en cuenta si realizan las funciones para los que son consideradas, si en verdad podran ayudar al desarrollo ya sea disminuyendo los tiempos, haciendo que los procesos de desarrollo sean mas fciles. Las herramientas de software planeadas para su adquisicin deben de cumplir los requisitos mencionados antes es decir de que en realidad sean tiles para el desarrollo del proyecto y que adems sean soportados por los sistemas de computo actuales en los que se desarrolla el proyecto. En la seccin 7 se lista el formato para reportar el resultado de las pruebas de las herramientas de software.

3.3 TAREA: EVALUAR LAS ISNTALACIONES

SQA debe de evaluar las instalaciones actuales y las futuras, estos deben de proveer el equipo necesario y el espacio necesario para el desarrollo y soporte. . En la seccin 7 se lista el formato para reportar el resultado de la evaluacin de las instalaciones.

3.4 TAREA: EVALUAR LOS PRODUCTOS DE SOFTWARE

Esta tarea se encarga de verificar que los procesos de calidad estn presentes en todos los productos de software. SQA checara que todos los productos que estn listos para su revisin sean revisados y adems verificar que los resultado sean reportados y los problemas descubiertos sean resueltos.

3-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

3.5 TAREA: EVALUAR LOS PLANES

El equipo de SQA deber evaluar todos los planes para el proyecto, deber ayudar a identificar los estndares, los lineamientos para los planes del proyecto en la seccin 1.6 se muestran todos los planes del proyecto.

3.6 TAREA: EVALUAR LOS REQUERIMIENTOS

El anlisis de requisitos establece un nico entendimiento del problema entre el cliente y el equipo de desarrollo. Un contrato con el cliente sobre los requisitos para el software es establecido y mantenido. Las tareas de SQA para los requerimientos son los siguientes. a) Verificar que todos los participantes correctos estn involucrados en el anlisis de los requisitos para identificar todas las necesidades del usuario. b) revisa todos los requerimientos para determinar si su implementacin es factible. c) Verificar que los contratos fueron son documentados, comunicados y revisados. d) Verificar que los requisitos que puedan tener algn tipo de error sean analizados por el equipo de requerimientos. e) Verificar que los requisitos estn documentados. f) g) Darle seguimientos a los cambios que puedan tener los requerimientos. Verificar que las personas involucradas en el equipo de requisitos estn entrenadas para el trabajo

h) Verificar que los procesos establecidos para definir y documentar requisitos son seguidos y documentados. SQA usara el checklist que se encuentra en la figura 3-B para la realizar la evaluacin. Todos los resultados se le reportara a la administracin del proyecto para que le de seguimiento.

3.7 TAREA: EVALUAR EL DISEO DE SOFTWARE

3.7tarea: evaluar el proceso de diseo de software. Las tareas de SQA en el proceso de diseo son: a) Verificar que los procesos de diseo de software sigan los estndares determinados. b) Velicar que todos los elementos que no cumplen con la calidad requerida sean procesados de acuerdo a los estndares y procedimientos establecidos. c) Verificar que la matriz de rastreo de los requerimientos al diseo este lista.

3-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

d) Verificar que todos los requerimientos estn presentas en el diseo.

Se usara el checklist B-6 para la evaluacin. Se generara un reporte, a si como las acciones correctivas entonces ser decisin de la administracin del proyecto aplicar esas acciones correctivas.

3.8 TAREA: EVALUAR EL DESARROLLO DEL SOFTWARE Y EL PROCESO DE PRUEBAS DE UNIDAD

a) Verificar que los procesos de codificacin y pruebas de unidas estn siendo implementados de acuerdo a los estndares y procesos establecidos. b) Verificar que los elementos encontrados en las revisiones del cdigo sean procesados mediante los estndares y procedimientos establecidos. c) Verificar que las pruebas de unidas se sigan al pie de la letra.

3.9 TAREA: PRUEBAS DE INTEGRACION.

a) Verificar que las actividades de prueba de software estn identificadas, el ambiente donde se van a llevar a cabo las pruebas ya estn identificadas. b) El equipo de SQA llevara a cabo las pruebas c) Los lineamientos para las pruebas ya esta definidas d) Ejecutar las pruebas de unidad e) Ejecutar las pruebas de integracin f) Analizar el resultado de las pruebas

3.10 TAREA: EVALUAR EL PROCESO DE ACCIONES CORRECTIVAS

A continuacin se describe el proceso de accin correctiva: 1) Identificar el problema 2) Reportar el problema a las autoridades pertinentes 3) Analizar el problema y dar una solucin 4) Realizar la accin correctiva Las actividades de SQA:

3-3

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

a) Revisar el proceso de accin correctiva perdidamente para estar seguro de que se esta aplicando con los estndares establecidos. b) Realizar anlisis peridicos a todos los problemas reportados para identificar tendencias que puedan generar problemas genricos en las areas. Este anlisis debe tener el estudio de las causas, la magnitud del impacto, la frecuencia en la que ocurre y medidas de prevencin. SQA debe usar el checklist B11 para esta evaluacin. Se generara un reporte, a si como las acciones correctivas entonces ser decisin de la administracin del proyecto aplicar esas acciones correctivas.

3.11 TAREA: EVALUAR LOS PROCESOS DE ADMINISITRACION DE LA CONFIGURACION

a) Verificar que las configuraciones de identificacin de documentos, cdigo, y datos de computadora, han sido establecidos de acuerdo a los estndares de titulo, nombres. b) Verificar que las lneas base han sido establecidas por medio de los estndares y procedimientos definidos. c) Verificar que las personas que van a participar en las auditorias conozcan el sistema y tengan conocimiento de administracin de la configuracin. d) Verificar que los procesos de administracin de la configuracin se sigan al pie de la letra.

SQA debe usar el checklist B-17 para esta evaluacin. Se generara un reporte, a si como las acciones correctivas entonces ser decisin de la administracin del proyecto aplicar esas acciones correctivas.

3.12 TAREA: EVALUAR LAS DESVIACIONES

En caso de que haya desviaciones en el proyecto el equipo de SQA deber de apoyar o dar soporte a la administracin de proyectos.

3.13 TAREA: LLEVAR A CABO LAS REVICIONES DEL PROYECTO Y LAS AUDITORIAS
El equipo de SQA ser el encargado de llevar a cabo las revisiones y auditorias durante el desarrollo del proyecto.

3.13.1 TAREA: LLEVAR A CABO LAS REVISIONES TECNICAS

El equipo de SQA es el encargado de llevar a cabo todas las revisiones tcnicas, todo el quipo de SQA debe de tener conocimientos acerca del producto que se evaluara.

3-4

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

Los elementos a los que se les aplicara la revisin tcnica son las siguientes: Especificacin de requisitos de software. El objetivo es determinar que los requisitos estn listos, para que se pueda pasar al diseo arquitectnico. Arquitectura de software. El objetivo es determinar que los requisitos se encuentran contemplados en el diseo de alto nivel. Diseo de software. El objetivo es determinar que todos los requisitos estn presentes en el diseo y que el diseo es consistente. Desarrollo software. El objetivo es determinar que todos los productos de software desarrollados cumplen con los estndares establecidos.

3.13.1 TAREA: VERIFICAR AVANCES DEL PROYECTO.

SQA verificara peridicamente el estado del proyecto, el progreso, los problemas en el proyecto y los riesgos pro viendo una valoracin independiente acerca del proyecto. SQA le proveer ala siguiente informacin a la administracin: Cumplimiento: identificara el nivel de cumplimiento actual del proyecto. Problemas: identificara los problemas potenciales o actuales que pueden afectar en el desarrollo del proyecto. Riesgos: identificara los riesgos basado en el estado de avance del proyecto. Entonces los resultados se le deben informar al administrador del proyecto, al equipo de desarrollo.

3-5

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

3-6

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

TABLA 3-1. REVISIONES Y AUDITORIAS FASES DE DESARROLLO Requisites de software Productos de software (1) ERS Auditorias y reviciones (1) revisin de especificacin de software (2)auditorias (3) revisin de administrador de proyecto (4) revisiones a par (1)auditorias (2) revisin de administrador de proyecto (3) revisiones a par (1) auditorias (2) revisin de administrador de proyecto (3) revisions a par (1) auditorias (2) revisin de administrador de proyecto (3) revisions a par

Diseo de software

Diseo de software

Desarollo de software

Productos de software

pruebas

Documento de pruebas

Nota: las revisiones a par se explican en la seccin 4.

3-7

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

3-8

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 4. DOCUMENTACION
La documentacin que describe y da soporte al sistema SCU o en el desarrollo del mismo, deber de ser creada y actualizada en todo el ciclo de vida del usuario. En las siguientes tablas se listan los documentos relacionados con el SCU. Nombre del documento SRS SDP Descripcin de documento En este documento se describen todos los requisitos del producto que sern implementados. Este documento indica todo lo que se va a implementar del producto, las actividades a realizar y la asignacin de responsabilidades. En este documento se describen todos los planes y roles que tendr cada elemento de la organizacin en el proceso de aseguramiento de la calidad del software. En este plan se estable la forma de determinar la lnea base y a si como la nomenclatura de cada producto de trabajo En este documento se encuentra el diseo a bajo nivel del sistema Este documento contiene un esquema acerca de que se va a probar y como se va a probar. Este documento contiene el diseo de alto nivel del SCU

SQAP

SCM

Diseo bajo nivel Plan de pruebas Arquitectura

Nota: Todos los documentos deben de estar bajo la administracin de la configuracin, despus de que el documento se haya creado en su primera versin o se haya modificado se enviara una peticin a administracin de la configuracin y este determinara si el documento entra a la lnea base.

4-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCIN 5: ESTANDARES, METRICAS Y PRACTICAS

En esta seccin se describen los estndares, prcticas y procesos que hay que realizar para que proyecto tenga xito. Los estndares (de cmo un producto puede ingresar a la lnea base), procesos relacionados con administracin de la configuracin estn definidos en el plan de administracin de la configuracin. Los estndares (normas a seguir en el desarrollo de software), mtricas (acerca de en qu estado se encuentra en proyecto) se encuentran en el plan de desarrollo de software. Los estndares (de cmo identificar riesgos) y las prcticas para mitigar los riesgos estn descritos en el plan de administracin de riesgos. Los estndares de codificacin y diseo se encuentran en la seccin 5.3. 5.1 mtricas en SQA Las siguientes medidas sern obtenidas para calcular y determinar el costo y el estado de las actividades SQA. 1) Calendario de trabajo de SQA.(planeado) 2) Calendario de trabajo de SQA(actual). 3) Trabajo de SQA(completo). 4) Gastos de SQA(planeado). 5) Gastos de SQA(actual). 6) Gastos de reserva de SQA(planeados). 7) Gastos de reserva de SQA(actuales) 8) Numero de elementos no resueltos abiertos actualmente. 9) Numero de elementos no resueltos cerrados. 10) Numero de elementos no resueltos

5-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

5. 3 Estndares de diseo y codificacion

5.3.1 a continuacin se listan los estndares de diseo. 1) El desarrollo de software se realizara en java 2) El nombre de las clases deber empezar en maysculas a si como la segunda palabra si es que existe 3) El nombre de los mtodos debe iniciar en minscula y la segunda palabra debe de ser mayscula. 4) El nombre del mtodo debe ser descriptivo con la funcin que realiza. 5) El nombrado de las clases y mtodos ser en ingles. 6) En cada diagrama habr una nota especificando el o los requerimientos que satisface. 5.3.2 a continuacin se listan los estndares de codificacin. 1) La estructura de la clase debe ser igual que las clase especificada en el diseo 2) Todas las clases especificadas en el diseo deben estar presentes en el cdigo 3) Los comentarios se harn antes del inicio cada mtodo o inicio de cada clase. 4) La codificacin ser en ingles. 5) Los comentarios sern en ingles. 6) En la lnea anterior de la declaracin de la clase habr un comentario en el cual se esptica el identificador o los identificadores de requisitos que satisfaces dicha clase. a. Ejemplo 1: //this class implements requirements 123, 124 and 125 public class Person{ ...

b. Ejemplo 2: //this class implements requirements 222, 223 and 224 public class ConectionManager{

5-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

... }

7) Este estndar solo se aplicara a mtodos pblicos de las clases de la lgica de negocios a. En la lnea anterior de la declaracin de un metodo habr un comentario en el cual se esptica el identificador o los identificadores de requisitos que satisfaces dicho mtodo. i. Ejemplo: // this method implements requirement 452 public void do Transaction(float mount1, float mount1) }

5-3

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

Seccin 6: pruebas
Las actividades de pruebas en el SCU incluyen las: pruebas de unidad, pruebas de integracin, pruebas de performance y pruebas de aceptacin. El equipo de SQA sern los encargados de ejecutar las pruebas, de anotar los resultados de las pruebas a si como analizar el resultado de las pruebas y de recomendar acciones correctivas en caso de que en los elementos probados tengan algn tipo de defecto. En la figura 6-1 se muestra el proceso de las pruebas, cabe destacar que todos los elementos a probar deben de estar bajo la proteccin de administracin de la configuracin. En el documento del plan de pruebas se describe ms a detalle el proceso de las pruebas.

Figura 6-1. Flujo del proceso de pruebas

6-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

6-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 7. REPORTAR PROBLEMAS Y RESOLUCION

En esta seccin se describe los procesos a seguir para reportar, dar seguimiento, y la resolucin de problemas tanto en los productos de software y en el desarrollo.

7.1 REPORTE DEL PROCESO DE AUDITORIAS

SQA reporta los resultados del proceso de auditora y provee recomendaciones, si es necesario debe usar el proceso de reporte de auditoras. El proceso de reporte de auditoras es usado para reportar los siguientes (1 )al proceso se le est dando seguimiento correcto y el proceso funciona correcto, al proceso se le est dando seguimiento pero este no funciona correctamente. Al proceso no se le esta dando seguimiento. En la figura 7-1 se muestra el formato para el reporte de un proceso de auditora. 7.1.1 presentacin y disposicin del reporte del proceso de auditora. El equipo de SQA le entregara dicho reporte a: a) Al administrador del proyecto: el administrador del proyecto utilizara el reporte de la siguiente forma. a. Para saber si los procesos de desarrollo son acatados y si estos son efectivos para cumplir con las metas del proyecto. Cuando sea necesario y apropiado el administrador del proyecto puede iniciar cambios a los procesos ,mediante los procedimientos establecidos, para que los procesos queden estables b. Para indicar su acuerdo, desacuerdo o aplazamiento de las recomendaciones mencionadas en el reporte de la auditoria. El administrador deber indicar su desacuerdo con las recomendaciones mencionadas en el reporte del proceso de las auditorias.

7-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

Reporte de procesos de auditoria NUMERO DE REPORTE:____________ LIDER DE LA AUDITORIA:______________________________________ FECHA DREPORTE:_____________ EQUIPO DE AUDITORIA:________________________________________________________ __________________________________________________________________________ ____ NOMBRE DEL PROYECTO:__________________________________________________________ FECHA DE LA AUDITORIA:________________________ PROCESOS/PROCEDIMIENTOS AUDITADOS:_____________________________________________________ CHECKLIST USADO(S): _____________________________________________________ RESULTADOS DELA AUDITORIA: (SELECCIONAR UNA) _____ Procesos/Procedimientos Aceptado _____ Procesos/Procedimientos Condicionalmente aceptados Condiciones: _____ Procesos/Procedimientos no aceptados Condiciones:
____________________________________________________________________________________ ________ELEMENTO(ELE):
ELE # TITULO ASIGNADO A

FECHA DE ASIGNACION:

FECHA DE FIN :___

__________________________________________________________________________ __________ __________________________________________________________________________ __________ __________________________________________________________________________ __________ ACCCION DE CORRECCION: __________________________________________________________________________ __________ ESTADO: APPROVADO CANCELADO APLAZADO FECHA: ADMINISTRADOR DE PROYECTO:

7-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

FIGURA 7-1

7.1.2 procedimiento de escalamiento para la resolucin de problemas de no acuerdo en el proceso del reporte de auditoras. Al encontrase un problema de calidad en algn elemento de trabajo ya sea documento, cdigo o producto de software, primero se tratara con el creador de ese elemento, si entonces existen problemas, ya sea que el dueo de ese producto no quiera corregir el error, o problemas de entendimiento, entonces el equipo de SQA le notificara al administrador del proyecto para que este tome cartas en el asunto y de una solucin al problema.

7.2 REPORTE DE LA EVALUACION HERRAMIENTAS DE SOFTWARE

La figura 7-2 provee el formato para el reporte de las herramientas de software discutidos en la seccin 3.2

7.3 REPORTE DE LA EVALUACION LAS INSTALACIONES

La figura 7-2 provee el formato para el reporte de las instalaciones discutidos en la seccin 3.3

7-3

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

EVALUACION DE HERRAMIENTA DE SOFTWARE SQA:_________________________ Herramienta de software evaluada: FECHA:___________

Mtodos o criterio usados en la evaluacin:

Resultados de la evaluacin:

Acciones correctivas recomendadas

Acciones correctivas tomadas

Figura 7-2 Evaluacin de herramientas de software.

7-4

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

Evaluacion de las instalaciones SQA:_________________________ EVALUACION:__________ Instalacin evaluada (equipo, espacio): FECHA DE LA

Mtodos o criterio usados en la evaluacin:

Resultados de la evaluacin:

Acciones correctivas recomendadas:

Acciones correctivas tomadas:

Figura 7-3 evaluacin de instalaciones

7-5

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

7-6

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 8. HERRAMIENTAS
Las herramientas a usar en el desarrollo del producto son: Net Beans.- Entorno de Desarrollo Integrado, que soporta varios lenguajes de programacin, como: perl, php, python, ruby, java, c and c++ Eclipse.- es un Entorno de Desarrollo Integrado de Cdigo Abierto multiplataforma para desarrollar lo que el proyecto llama "Aplicaciones de Cliente Enriquecido". Lenguajes que Acepta: Java, ANSI C, C++, JSP, sh, perl, php, sed. ISQL Plus.- Herramienta Web que sirve para ejecutar lneas de comando SQL y PL/ SQL Jude.- Aplicacin que se utiliza para elaborar los diagramas del Estndar UML. Microsoft office Word.- Es un procesador de texto Microsoft Project.- Su funcin bsica es para ayudar a administrar proyecto.

8-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

8-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

Seccin 9. Control de cdigo

En la seccin 5.3 se discuten los estndares que debe tener el cdigo generado durante el desarrollo del proyecto. A continuacin se listan algunos tareas a ser realizadas la descripcin ms detallada del control de versiones de cdigo se encuentra en el documento de administracin de configuracin. a) Identificar, etiquetar y clasificar el software a se controlado. b) Identificar la ubicacin fsica del software a ser controlado. c) Identificar el lugar donde se encuentran las copias de seguridad. d) Distribucin de copias de cdigo e) Identificar los documentos afectados por cambios en el cdigo f) Establecimiento de versiones nuevas

g) Administrar a los usuarios que tiene acceso al cdigo La tarea del equipo de SQA es determinar que estos procesos se estn llevando a cabo de forma correcta por el equipo de administracin de la configuracin.

9-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

9-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 10. ENTRENAMIENTO

En la siguiente tabla se listan las capacitaciones necesarias para el equipo de desarrollo. Capacitacin Introduccin al SCU. Descripcin Introduccin rpida de lo trata el proyecto de desarrollo para el SCU, Cuales son los requerimientos, casos de uso, tcnicas y cualquier otra informacin que resulte relevante para el desarrollo del proyecto Curso para aprender a crear bases de datos y poder manipular las mismas con Oracle 10g Dirigido a/impartido por Dirigido a: Miguel ngel Alcocer Flores Daniel Ivn Cuevas Zamora Impartido por: Abraham Jos Rivero Cauich Fecha Inicio Finalizacin 26/Enero 27/Enero/09 /09

Hibernate con Oracle 10g

Dirigido a: Miguel ngel Alcocer Flores Daniel Ivn Cuevas Zamora Omar Estrella Castro Miguel Gonzles Novelo Impartido por: Israel Antonio Lpez Alonso Augusto Valdez Abraham Jos Rivero Cauich

28/enero /09

3/Febrero/0 9

10-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

10-2

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

SECCION 11. ADMINISTRACION DE RIESGOS

En el proyecto SCU se ha desarrollado un plan de administracin de riesgos llamado PAR SCU.DOC el equipo de SQA revisar y evaluara el anlisis tcnico de riesgos y cualquier plan para la reduccin de riesgos. Es responsabilidad de SQA verificar que los proceso para mitigar los riesgos definidos en el plan de de riesgos sean seguidos al pie de la letra.

11-1

SCU plan SQA Control de configuracin # 3 de Marzo del 2009

APENDICE A: LISTA DE ACRONIMOS

SCM SQA SRS Software Configuration Management Software Quality Assurance Software Requirements Specification

A-1

CHECKLISTS

Checklist para el proceso de auditora a la planeacin

Proyecto: Fecha: Preparado por: procedimientos: ____los planes del proyecto existe y estan documentados en el SDP. ____los estandares estan documentados y estan presents en el SDP. ____el contenido del SDP tiene cosistencia el la implementacion de los estandares de procesos de software. ____el SDP esta bajo la administracion de la configuracion. ____los requerimientos del software son la base de los planes, productos de trabajo y las actividades ____existe el SCM ya sea en el SDP o en un document aparte ____el plan de SCM esta bajo la proteccion de la configuracion. ____el plan de SQA existe. ____existen planes par alas pruebas integracion de software. . Figura B-1. checklist para el proceso de auditoria a la planeacion

Seguimiento del proyecto

Proyecto: fehca: preparado por: Procedimientos: ____los hitos estas identificados ____los hitos son usados para el re anlisis del proyecto. ____el lider del proyecto revisa los avances del proyecto bisemanalmente Figura B-2. seguimiento del proyecto.

reporte del anlisis del proceso de auditora a los requisitos

Proyecto: Fecha: Preparado por: Procedimientos: Part 1. Requerimientos de software ____los requerimientos de software estn documentados e incluyen la matriz de rastreo. ____el SRS esta bajo al administracin de la configuracin ____los planes de desarrollo de software y otros productos son modificados si se modifica el SRS para que estos sean consistentes. ___se han usado mediciones para determinar el estado de la administracin de requisitos.

Figura B-5. reporte del anlisis del proceso de auditora a lo requisitos.

Checklist del proceso de auditoras al diseo de software

Proyecto: Fecha: Preparado por: Procedimientos: Parte 1. diseo ____los documentos de diseo y la matriz de rastreo esta listos. ____las caminatas evalan si todos los requerimientos estn plasmadas en el diseo, a si como el de tratar de encontrar errores ____el diseo esta actualizado con respecto a los ltimos cambios en los requisitos. ____los cambios en el diseo seguidas, evaluadas. ____el diseo de software es consistente con la metodologa de diseo propuesta en el SDP.

Checklist para el proceso de auditora a la administracin de la configuracin.

Proyecto: Fecha: Preparado por: Procedimientos: Parte 1. SCM Plan ____las secciones de este documento estn organizados de acuerdo al estndar. ____existe un grupo designado para implementar este plan. ____el documento del plan SCM es usado como base para todas las actividades de administracin de la configuracin ____los cambios a la lnea base son manejadas de acuerdo al plan de SCM ____se ha establecido un repositorio para guardar la lnea base. ____el acceso a los elementos de la lnea base alojados en el repositorio son de acuerdo a los procedimientos establecidos en el plan SCM. ____los productos de software alojados en el repositorio deben de estar identificados como elementos de configuracin en el plan SCM. ____los cambios a la lnea base son controlados de acuerdo a los establecidos en el plan SCM

Figura B-17. reporte del proceso de auditoras a administracin de la configuracin

Checklist para el proceso de auditora a la administracin de la configuracin.

Proyecto: Fecha: Preparado por: Parte 2. Identificacion de la configuracion ____la lnea base puede ser identificada ____si, describe la metodologa usada para identificar la lnea base ____cada elemento de la configuracin pueden ser identificadas a si como sus componentes ____si, describe los mtodos para identificarlos ____un mtodo es usado para identificar en nombre, versin, cambio de estado, y cualquier otro detalle de identificacin de cada elemento liberado. ____si, describe el mtodo usado.

Figura B-17. reporte del proceso de auditoras a administracin de la configuracin

Checklist para el proceso de auditora a la administracin de la configuracin.

Proyecto: Fecha: Preparado por: Parte 3. Propuesta de cambios ____existe un formato para una propuesta de cambio. ____el proceso para los cambios a realizar en la lnea base estn establecidos en el plan SCM. ____en el plan existen procesos para aprobar los cambios. Figura B-17. reporte del proceso de auditoras a administracin de la configuracin