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
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
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
proyecto
(3) revisiones a par
Desarollo de software Productos de
software
(1) auditorias
proyecto
(3) revisions a par
pruebas Documento de
pruebas
(1) auditorias
proyecto
(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 pruebas
Resultados de las
pruebas
Resultados
esperados
Evaluación de
resultados
Errores
Correcciones
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
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/0
9

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

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.

Sqap ejemplos

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Sqap ejemplos

Similar to Sqap ejemplos (20)

Sqap ejemplos