Sqap ejemplos

SCU plan SQA

Control de configuración #

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

Séptimo semestre ingeniería de software

SCU plan SQA


3 de Marzo del 2009

SCU plan SQA


3 de Marzo del 2009

iii

SISTEMA DE CONTROL DE USARIOS

PLAN DE ASEGURAMIENTO DE LA CALIDAD DEL

SOFTWARE

CONTROL DE LA CONFIGURACION #

3 DE DICIEMBRE DEL 2009

Aprobación del plan de SQA:

______________________ ____________

Administrador de SQA Fecha

______________________ ____________

Administrador del proyecto Fecha

SCU plan SQA


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


3 de Marzo del 2009

v

REGISTRO DE CAMBIOS

*A - añadido M - modificado B- Borrado

Numero de version

fecha

Numero de figura, tabla , párrafo o sección

A*

M

B

titulo o una breve descripción

Numero de petición de cambio

0.1 03/03/09 Sección 5.3.1 y 5.3.2

A Se agregaron estándares para la descripción de los requisitos que satisface cada diagrama en el diseño, clase o método

1

SCU plan SQA


3 de Marzo del 2009

SCU plan SQA


3 de Marzo del 2009

vii

TABLA DE CONTENIDO

Sección Página

SECCION 1. PROPOSITO ......................................................................................................................... 1

1.1 alcance .................................................................................................................................................... 1

1.2 Identificación .......................................................................................................................................... 1

1.3 vista general del sistema .......................................................................................................................... 1

1.4 vista general del documento .................................................................................................................... 1

1.5 relación con otros planes ......................................................................................................................... 2

1.6 references ................................................................................................................................................ 3

SECCION 2. ADMINISTRACION ............................................................................................................. 1

2.1 organización ........................................................................................................................................... 1

SECCION 3. TAREAS DE SQA ................................................................................................................ 1

3.1 Tarea: Revisar los productos de software ............................................................................................... 1

3.2 Tarea: EVALUAR las herramientas de software .................................................................................... 1

3.3 Tarea: EVALUAR las instalaciones ....................................................................................................... 1

3.4 Tarea: EVALUAR los productos de software......................................................................................... 1

3.5 Tarea: EVALUAR los planes .................................................................................................................. 2

3.6 Tarea: Evaluar los requerimientos .......................................................................................................... 2

3.7 Tarea: EVALUAR el diseño de software ................................................................................................ 2

3.8 Tarea: Evaluar el desarrollo del software y el proceso de pruebas de unidad ........................................ 3

3.9 Tarea: pruebas de integración. ................................................................................................................ 3

3.10 Tarea: evaluar el proceso de acciones correctivas ................................................................................ 3

3.11 Tarea: evaluar los procesos de administración de la configuración .................................................... 4

3.12 Tarea: EVALUAR las desviaciones ...................................................................................................... 4

3.13 Tarea: LLEVAR a cabo las revisiones del proyecto y las auditorias .................................................... 4

3.13.1 Tarea: llevar a cabo las revisiones técnicas........................................................................................ 4

3.13.1 Tarea: verificar AVANCES DEL PROYECTO. ............................................................................... 5

SECCION 4. DOCUMENTACION ............................................................................................................ 1

SECCIÓN 5: ESTANDARES, METRICAS Y PRACTICAS ...................................................................... 1

5. 3 ESTÁNDARES DE DISEÑO Y CODIFICACION............................................................................... 2

SECCIÓN 6: PRUEBAS .............................................................................................................................. 1

SECCION 7. REPORTAR PROBLEMAS Y RESOLUCION .................................................................... 1

7.1 reporte del proceso de auditorías ............................................................................................................. 1

FIGURA 7-1 .................................................................................................................................................. 3

7.2 reporte de la evaluación herramientas de software ................................................................................. 3

7.3 reporte de la evaluación las instalaciones .............................................................................................. 3

SECCION 8. HERRAMIENTAS ................................................................................................................ 1

SECCIÓN 9. CONTROL DE CÓDIGO ....................................................................................................... 1

SECCION 10. ENTRENAMIENTO ........................................................................................................... 1

SECCION 11. ADMINISTRACION DE RIESGOS .................................................................................... 1

APENDICE A: LISTA DE ACRONIMOS .................................................................................................. 1

CHECKLISTS .............................................................................................................................................. 1

SCU plan SQA


3 de Marzo del 2009

1-1

SECCION 1. PROPOSITO

El propósito de este plan es definir un plan de aseguramiento de la calidad del software para el sistema de control de usuarios, asignación de responsabilidades y tareas de SQA, proveer documentos, guías 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 documentación liberados cumpla con todos los requerimientos técnicos establecidos.

1.2 IDENTIFICACION

Los elementos que esta a continuación son a los que se les aplicara el plan de aseguramiento de la configuración.

Al cliente • SRS • Manuales de usuario y de ayuda Trabajos internos • SQAP • SDP • SQM • Especificación del diseño • Planes y Resultados de Pruebas • Estándares y Procedimientos • Índice y bitácora de la línea base Productos adquiridos Herramientas •Sistemas operativos

•Herramientas de programación

1.3 VISTA GENERAL DEL SISTEMA

SCU, de las siglas “Sistema de Control de Usuarios”, es un sistema enfocado a la administración de recursos de Tecnologías de Información.

1.4 VISTA GENERAL DEL DOCUMENTO

Este de documento contiene toda la organización y procedimientos a ser usadas para llevar a cabo en el plan SQA del proyecto SCU.

En la sección 1 se idéntica el sistema al que se le va aplicar este plan, se hace una pequeña descripción del sistema, se identifican otros documentos de administración relacionados con el plan SQA. Se describe el propósito del plan SQA.

En la sección 2 se describe cada elemento de la organización que influye en la calidad del software.

SCU plan SQA


3 de Marzo del 2009

1-2

Sección 3: se describen las tareas de aseguramiento de la calidad del software. Sección 4: lista los documentos que están en la línea base o van a estar en la línea base, durante el desarrollo del proyecto. Sección 5: describe todos los convenios, estándares y prácticas a ser usadas en el desarrollo del proyecto. Sección 6: describe el rol que tiene SQA en las pruebas. Sección 7: describe los reportes de errores y las acciones correctivas. Sección 8: describe herramientas de SQA, técnicas y metodologías. Sección 9: describe la herramienta usada en administración de la configuración para el control del código. Sección 10: describe los entrenamientos requeridos para SQA. Sección 11: describe la evaluación de SQA del proceso de prevención de riesgos.

Apéndice A: contiene una lista de acrónimos. Apéndice 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 configuración 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, están basados en los procesos definidos en el plan de desarrollo del software.

SCU plan SQA


3 de Marzo del 2009

1-3

1.6 RFEFERENCIAS

a) plan de desarrollo de software.

b) Plan de administración de la configuración del software.

c) Plan de administración de riesgos.

SCU plan SQA


3 de Marzo del 2009

2-1

SECCION 2. ADMINISTRACION

Esta sección describe cada elemento o área de la organización que influye en la calidad del software.

2.1 ORGANISAZION

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

Organizacion

SQA

Administración de

proyecto

Probador de

Software

Administración de

riesgos

Administración de

La configuración

Diseño/Desarrollo

de software

Figura 2-1. Organización SCU

A continuación 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 económico.

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

SCU plan SQA


3 de Marzo del 2009

2-2

b. Es el de ejecutar el plan

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 técnicas de los productos de software elaborados.

3) Administración 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 planeación tales

como: el plan de desarrollo de software y el plan de aseguramiento de la calidad

del software.

4) Diseño/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 diseño y el desarrollo de producto.

d. Identificar, implementar y evaluar los factores de calidad a ser implementados

en el software.

e. Implementar las prácticas, procesos y estándares de desarrollo y diseño

especificados en el plan de desarrollo del software y en el plan de SQA.

SCU plan SQA


3 de Marzo del 2009

2-3

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 están implementados en el sistema,

especialmente en el software.

6) Administración de la configuración 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 prácticas, 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.

SCU plan SQA


3 de Marzo del 2009

2-4

3) El conocimiento en diseño, código, análisis estructural y pruebas de software.

4) Debe conocer los planes de:

a. Plan de desarrollo del software

b. Administración de la configuración del software

c. Administración de riesgos

5) Trabajar en equipo.

El administrador de SQA debe dominar los temas ya mencionados.

SCU plan SQA


3 de Marzo del 2009

3-1

SECCION 3. TAREAS DE SQA

En esta sección se listan todas las tareas que el equipo de SQA realizara, estas tareas serán durante todo el ciclo de vida del proyecto, y se realizaran según la calendarización 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 coordinación y cooperación 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 estándares o reglas a seguir. Es necesario que el equipo de SQA ayude a la administración del proyecto, los estándares y los lineamientos a seguir en el desarrollo del proyecto. En la sección 4 se listan los productos de software a ser considerados por SQA y los procesos de revisión 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 podrían ayudar al desarrollo ya sea disminuyendo los tiempos, haciendo que los procesos de desarrollo sean mas fáciles.

Las herramientas de software planeadas para su adquisición deben de cumplir los requisitos mencionados antes es decir de que en realidad sean útiles para el desarrollo del proyecto y que además sean soportados por los sistemas de computo actuales en los que se desarrolla el proyecto. En la sección 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 sección 7 se lista el formato para reportar el resultado de la evaluación de las instalaciones.

3.4 TAREA: EVALUAR LOS PRODUCTOS DE SOFTWARE

Esta tarea se encarga de verificar que los procesos de calidad están presentes en todos los productos de software.

SQA checara que todos los productos que estén listos para su revisión sean revisados y además verificar que los resultado sean reportados y los problemas descubiertos sean resueltos.

SCU plan SQA


3 de Marzo del 2009

3-2

3.5 TAREA: EVALUAR LOS PLANES

El equipo de SQA deberá evaluar todos los planes para el proyecto, deberá ayudar a identificar los estándares, los lineamientos para los planes del proyecto en la sección 1.6 se muestran todos los planes del proyecto.

3.6 TAREA: EVALUAR LOS REQUERIMIENTOS

El análisis 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 estén involucrados en el análisis de los

requisitos para identificar todas las necesidades del usuario.

b) revisa todos los requerimientos para determinar si su implementación es factible.

c) Verificar que los contratos fueron son documentados, comunicados y revisados.

d) Verificar que los requisitos que puedan tener algún tipo de error sean analizados por el

equipo de requerimientos.

e) Verificar que los requisitos estén documentados.

f) Darle seguimientos a los cambios que puedan tener los requerimientos.

g) Verificar que las personas involucradas en el equipo de requisitos estén 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 evaluación.

Todos los resultados se le reportara a la administración del proyecto para que le de seguimiento.

3.7 TAREA: EVALUAR EL DISEÑO DE SOFTWARE

3.7tarea: evaluar el proceso de diseño de software.

Las tareas de SQA en el proceso de diseño son:

a) Verificar que los procesos de diseño de software sigan los estándares determinados.

b) Velicar que todos los elementos que no cumplen con la calidad requerida sean

procesados de acuerdo a los estándares y procedimientos establecidos.

c) Verificar que la matriz de rastreo de los requerimientos al diseño este lista.

SCU plan SQA


3 de Marzo del 2009

3-3

d) Verificar que todos los requerimientos estén presentas en el diseño.

Se usara el checklist B-6 para la evaluación.

Se generara un reporte, a si como las acciones correctivas entonces será decisión de la administración 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 codificación y pruebas de unidas están siendo

implementados de acuerdo a los estándares y procesos establecidos.

b) Verificar que los elementos encontrados en las revisiones del código sean procesados

mediante los estándares 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 estén identificadas, el ambiente

donde se van a llevar a cabo las pruebas ya estén 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 integración

f) Analizar el resultado de las pruebas

3.10 TAREA: EVALUAR EL PROCESO DE ACCIONES CORRECTIVAS

A continuación se describe el proceso de acción correctiva:

1) Identificar el problema

2) Reportar el problema a las autoridades pertinentes

3) Analizar el problema y dar una solución

4) Realizar la acción correctiva

Las actividades de SQA:

SCU plan SQA


3 de Marzo del 2009

3-4

a) Revisar el proceso de acción correctiva perdidamente para estar seguro de que se

esta aplicando con los estándares establecidos.

b) Realizar análisis periódicos a todos los problemas reportados para identificar

tendencias que puedan generar problemas genéricos en las areas. Este análisis

debe tener el estudio de las causas, la magnitud del impacto, la frecuencia en la que

ocurre y medidas de prevención.

SQA debe usar el checklist B11 para esta evaluación.


3.11 TAREA: EVALUAR LOS PROCESOS DE ADMINISITRACION DE LA

CONFIGURACION

a) Verificar que las configuraciones de identificación de documentos, código, y datos de

computadora, han sido establecidos de acuerdo a los estándares de titulo, nombres.

b) Verificar que las líneas base han sido establecidas por medio de los estándares y

procedimientos definidos.

c) Verificar que las personas que van a participar en las auditorias conozcan el sistema y

tengan conocimiento de administración de la configuración.

d) Verificar que los procesos de administración de la configuración se sigan al pie de la

letra.

SQA debe usar el checklist B-17 para esta evaluación.


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 administración 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.

SCU plan SQA


3 de Marzo del 2009

3-5

3.13.1 TAREA: LLEVAR A CABO LAS REVISIONES TECNICAS

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

Los elementos a los que se les aplicara la revisión técnica son las siguientes:

Especificación de requisitos de software. El objetivo es determinar que los requisitos están listos, para que se pueda pasar al diseño arquitectónico.

Arquitectura de software. El objetivo es determinar que los requisitos se encuentran contemplados en el diseño de alto nivel.

Diseño de software. El objetivo es determinar que todos los requisitos estén presentes en el diseño y que el diseño es consistente.

Desarrollo software. El objetivo es determinar que todos los productos de software desarrollados cumplen con los estándares establecidos.

3.13.1 TAREA: VERIFICAR AVANCES DEL PROYECTO.

SQA verificara periódicamente el estado del proyecto, el progreso, los problemas en el proyecto y los riesgos pro viendo una valoración independiente acerca del proyecto. SQA le proveerá ala siguiente información a la administración:

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.

SCU plan SQA


3 de Marzo del 2009

3-6

SCU plan SQA


3 de Marzo del 2009

3-7

TABLA 3-1. REVISIONES Y AUDITORIAS

FASES DE DESARROLLO Productos de software

Auditorias y reviciones

Requisites de software (1) ERS (1) revisión de especificación de software

(2)auditorias

(3) revisión de administrador de proyecto

(4) revisiones a par

Diseño de software Diseño de software (1)auditorias


(3) revisiones a par

Desarollo de software Productos de software

(1) auditorias


(3) revisions a par

pruebas Documento de pruebas

(1) auditorias


(3) revisions a par

Nota: las revisiones a par se explican en la sección 4.

SCU plan SQA


3 de Marzo del 2009

3-8

SCU plan SQA


3 de Marzo del 2009

4-1

SECCION 4. DOCUMENTACION

La documentación 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

Descripción de documento

SRS En este documento se describen todos los requisitos del producto que serán implementados.

SDP Este documento indica todo lo que se va a implementar del producto, las actividades a realizar y la asignación de responsabilidades.

SQAP En este documento se describen todos los planes y roles que tendrá cada elemento de la organización en el proceso de aseguramiento de la calidad del software.

SCM En este plan se estable la forma de determinar la línea base y a si como la nomenclatura de cada producto de trabajo

Diseño bajo

nivel

En este documento se encuentra el diseño a bajo nivel del sistema

Plan de pruebas Este documento contiene un esquema acerca de que se va a probar y como se va a probar.

Arquitectura Este documento contiene el diseño de alto nivel del SCU

Nota:

Todos los documentos deben de estar bajo la administración de la configuración, después de que el documento se haya creado en su primera versión o se haya modificado se enviara una petición a administración de la configuración y este determinara si el documento entra a la línea base.

SCU plan SQA


3 de Marzo del 2009

5-1

SECCIÓN 5: ESTANDARES, METRICAS Y PRACTICAS

En esta sección se describen los estándares, prácticas y procesos que hay que realizar para que proyecto tenga éxito.

Los estándares (de cómo un producto puede ingresar a la línea base), procesos relacionados con administración de la configuración están definidos en el plan de administración de la configuración.

Los estándares (normas a seguir en el desarrollo de software), métricas (acerca de en qué estado se encuentra en proyecto) se encuentran en el plan de desarrollo de software.

Los estándares (de cómo identificar riesgos) y las prácticas para mitigar los riesgos están descritos en el plan de administración de riesgos.

Los estándares de codificación y diseño se encuentran en la sección 5.3.

5.1 métricas en SQA

Las siguientes medidas serán 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

SCU plan SQA


3 de Marzo del 2009

5-2

5. 3 Estándares de diseño y codificacion

5.3.1 a continuación se listan los estándares de diseño.

1) El desarrollo de software se realizara en java

2) El nombre de las clases deberá empezar en mayúsculas a si como la segunda palabra

si es que existe

3) El nombre de los métodos debe iniciar en minúscula y la segunda palabra debe de ser

mayúscula.

4) El nombre del método debe ser descriptivo con la función que realiza.

5) El nombrado de las clases y métodos será en ingles.

6) En cada diagrama habrá una nota especificando el o los requerimientos que satisface.

5.3.2 a continuación se listan los estándares de codificación.

1) La estructura de la clase debe ser igual que las clase especificada en el diseño

2) Todas las clases especificadas en el diseño deben estar presentes en el código

3) Los comentarios se harán antes del inicio cada método o inicio de cada clase.

4) La codificación será en ingles.

5) Los comentarios serán en ingles.

6) En la línea anterior de la declaración de la clase habrá un comentario en el cual se

espática 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:

SCU plan SQA


3 de Marzo del 2009

5-3

//this class implements requirements 222, 223 and 224

public class ConectionManager{

...

…

…

}

7) Este estándar solo se aplicara a métodos públicos de las clases de la lógica de

negocios

a. En la línea anterior de la declaración de un metodo habrá un comentario en el

cual se espática el identificador o los identificadores de requisitos que satisfaces

dicho método.

i. Ejemplo:

// this method implements requirement 452

public void do Transaction(float mount1, float mount1)

…

…

…

}

SCU plan SQA


3 de Marzo del 2009

6-1

Sección 6: pruebas

Las actividades de pruebas en el SCU incluyen las: pruebas de unidad, pruebas de integración, pruebas de performance y pruebas de aceptación.

El equipo de SQA serán 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 algún 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 protección de administración de la configuración.

En el documento del plan de pruebas se describe más a detalle el proceso de las pruebas.

Elemento protegido

por admin de la config pruebasResultados de las

pruebas

Resultados

esperados

Evaluación de

resultados

ErroresCorrecciones

Pruebas para que los

elementos entren bajo

la administración de la

configuración

Figura 6-1. Flujo del proceso de pruebas

SCU plan SQA


3 de Marzo del 2009

6-2

SCU plan SQA


3 de Marzo del 2009

7-1

SECCION 7. REPORTAR PROBLEMAS Y RESOLUCION

En esta sección se describe los procesos a seguir para reportar, dar seguimiento, y la resolución 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 auditoría y provee recomendaciones, si es necesario debe usar el proceso de reporte de auditorías. El proceso de reporte de auditorías 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 auditoría.

7.1.1 presentación y disposición del reporte del proceso de auditoría.

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.

SCU plan SQA


3 de Marzo del 2009

7-2

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

ADMINISTRADOR DE PROYECTO: FECHA:

SCU plan SQA


3 de Marzo del 2009

7-3

FIGURA 7-1

7.1.2 procedimiento de escalamiento para la resolución de problemas de no acuerdo en

el proceso del reporte de auditorías.

Al encontrase un problema de calidad en algún elemento de trabajo ya sea documento, código o producto de software, primero se tratara con el creador de ese elemento, si entonces existen problemas, ya sea que el dueño 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 solución 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 sección 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 sección 3.3

SCU plan SQA


3 de Marzo del 2009

7-4

EVALUACION DE HERRAMIENTA DE SOFTWARE

SQA:_________________________ FECHA:___________

Herramienta de software evaluada:

Métodos o criterio usados en la evaluación:

Resultados de la evaluación:

Acciones correctivas recomendadas

Acciones correctivas tomadas

Figura 7-2 Evaluación de herramientas de software.

SCU plan SQA


3 de Marzo del 2009

7-5

Evaluacion de las instalaciones

SQA:_________________________ FECHA DE LA EVALUACION:__________

Instalación evaluada (equipo, espacio):

Métodos o criterio usados en la evaluación:

Resultados de la evaluación:

Acciones correctivas recomendadas:

Acciones correctivas tomadas:

Figura 7-3 evaluación de instalaciones

SCU plan SQA


3 de Marzo del 2009

7-6

SCU plan SQA


3 de Marzo del 2009

8-1

SECCION 8. HERRAMIENTAS

Las herramientas a usar en el desarrollo del producto son:

Net Beans.- Entorno de Desarrollo Integrado, que soporta varios lenguajes de programación, como: perl, php, python, ruby, java, c and c++

Eclipse.- es un Entorno de Desarrollo Integrado de Código 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 líneas de comando SQL y PL/ SQL

Jude.- Aplicación que se utiliza para elaborar los diagramas del Estándar UML.

Microsoft office Word.- Es un procesador de texto

Microsoft Project.- Su función básica es para ayudar a administrar proyecto.

SCU plan SQA


3 de Marzo del 2009

8-2

SCU plan SQA


3 de Marzo del 2009

9-1

Sección 9. Control de código

En la sección 5.3 se discuten los estándares que debe tener el código generado durante el desarrollo del proyecto.

A continuación se listan algunos tareas a ser realizadas la descripción más detallada del control de versiones de código se encuentra en el documento de administración de configuración.

a) Identificar, etiquetar y clasificar el software a se controlado.

b) Identificar la ubicación física del software a ser controlado.

c) Identificar el lugar donde se encuentran las copias de seguridad.

d) Distribución de copias de código

e) Identificar los documentos afectados por cambios en el código

f) Establecimiento de versiones nuevas

g) Administrar a los usuarios que tiene acceso al código

La tarea del equipo de SQA es determinar que estos procesos se están llevando a cabo de forma correcta por el equipo de administración de la configuración.

SCU plan SQA


3 de Marzo del 2009

9-2

SCU plan SQA


3 de Marzo del 2009

10-1

SECCION 10. ENTRENAMIENTO

En la siguiente tabla se listan las capacitaciones necesarias para el equipo de desarrollo.

Capacitación Descripción Dirigido a/impartido por Fecha

Inicio Finalización

Introducción al SCU.

Introducción rápida de lo trata el proyecto de

desarrollo para el SCU, Cuales son

los requerimientos, casos de uso,

técnicas y cualquier otra

información que resulte relevante

para el desarrollo del proyecto

Dirigido a:

Miguel Ángel Alcocer Flores

Daniel Iván Cuevas Zamora

Impartido por:

Abraham José Rivero Cauich

26/Enero/09

27/Enero/09

Hibernate con Oracle 10g

Curso para aprender a crear bases de datos y poder manipular las mismas con

Oracle 10g

Dirigido a:

Miguel Ángel Alcocer Flores

Daniel Iván Cuevas Zamora

Omar Estrella Castro

Miguel Gonzáles Novelo

Impartido por:

Israel Antonio López Alonso

Augusto Valdez

Abraham José Rivero Cauich

28/enero/09

3/Febrero/09

SCU plan SQA


3 de Marzo del 2009

10-2

SCU plan SQA


3 de Marzo del 2009

11-1

SECCION 11. ADMINISTRACION DE RIESGOS

En el proyecto SCU se ha desarrollado un plan de administración de riesgos llamado PAR SCU.DOC el equipo de SQA revisar y evaluara el análisis técnico de riesgos y cualquier plan para la reducción 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.

SCU plan SQA


3 de Marzo del 2009

A-1

APENDICE A: LISTA DE ACRONIMOS

SCM Software Configuration Management

SQA Software Quality Assurance

SRS Software Requirements Specification

CHECKLISTS

Checklist para el proceso de auditoría a la planeación

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 análisis del proyecto.

____el lider del proyecto revisa los avances del proyecto bisemanalmente

Figura B-2. seguimiento del proyecto.

reporte del análisis del proceso de auditoría a los requisitos

Proyecto:

Fecha:

Preparado por:

Procedimientos:

Part 1. Requerimientos de software

____los requerimientos de software están documentados e incluyen la matriz de rastreo.

____el SRS esta bajo al administración de la configuración

____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 administración de requisitos.

Figura B-5. reporte del análisis del proceso de auditoría a lo requisitos.

Checklist del proceso de auditorías al diseño de software

Proyecto:

Fecha:

Preparado por:

Procedimientos:

Parte 1. diseño

____los documentos de diseño y la matriz de rastreo esta listos.

____las caminatas evalúan si todos los requerimientos están plasmadas en el diseño, a si como el de tratar de encontrar errores

____el diseño esta actualizado con respecto a los últimos cambios en los requisitos.

____los cambios en el diseño seguidas, evaluadas.

____el diseño de software es consistente con la metodología de diseño propuesta en el SDP.

Checklist para el proceso de auditoría a la administración de la configuración.

Proyecto:

Fecha:

Preparado por:

Procedimientos:

Parte 1. SCM Plan

____las secciones de este documento están organizados de acuerdo al estándar.

____existe un grupo designado para implementar este plan.

____el documento del plan SCM es usado como base para todas las actividades de administración de la configuración

____los cambios a la línea base son manejadas de acuerdo al plan de SCM

____se ha establecido un repositorio para guardar la línea base.

____el acceso a los elementos de la línea 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 configuración en el plan SCM.

____los cambios a la línea base son controlados de acuerdo a los establecidos en el plan SCM

Figura B-17. reporte del proceso de auditorías a administración de la configuración


Proyecto:

Fecha:

Preparado por:

Parte 2. Identificacion de la configuracion

____la línea base puede ser identificada

____si, describe la metodología usada para identificar la línea base

____cada elemento de la configuración pueden ser identificadas a si como sus componentes

____si, describe los métodos para identificarlos

____un método es usado para identificar en nombre, versión, cambio de estado, y cualquier otro detalle de identificación de cada elemento liberado.

____si, describe el método usado.



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 línea base están establecidos en el plan SCM.

____en el plan existen procesos para aprobar los cambios.


Documents

Sqap ejemplos