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

Ingeniería de Software II
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009
 SCU plan SQA
Control de configuración #
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

Aprobación del plan de SQA:

______________________ ____________
Administrador de SQA Fecha

______________________ ____________
Administrador del proyecto Fecha

iii
 SCU plan SQA
Control de configuración #
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 configuración #
3 de Marzo del 2009

REGISTRO DE CAMBIOS (AL PAQS)

*A - añadido M - modificado E- Eliminado
Numero de figura, A* Número
Número
Fecha tabla , párrafo o M titulo o una breve descripción de
de version
sección E 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 1
descripción de los requisitos que
satisface cada diagrama en el diseño,
clase o método
0.2 03/01/10

v
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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
Control de configuración #
3 de Marzo del 2009

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.

1-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

1.6 REFERENCIAS

a) Plan de desarrollo de software.

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

1-2
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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

Administración de
SQA
proyecto

Probador de Diseño/Desarrollo Administración de Administración de

Software de software riesgos La configuración

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

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.

2-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

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.

2-2
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

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.

2-3
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

3-1
 SCU plan SQA
Control de configuración #
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 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 dé
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.

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

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

3-2
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

Se generara un reporte, así 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:

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.
3-3
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

SQA debe usar el checklist B11 para esta 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.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.

Se generara un reporte, así como las acciones correctivas entonces será decisión de la
administración 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 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.

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.

3-4
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

TABLA 3-1. REVISIONES Y AUDITORIAS

FASES DE DESARROLLO Productos de
Auditorias y reviciones
software
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
(2) revisión de administrador de
proyecto
(3) revisiones a par

Desarollo de software Productos de (1) auditorias

software (2) revisión de administrador de
proyecto
(3) revisions a par
pruebas Documento de (1) auditorias
pruebas (2) revisión de administrador de
proyecto
(3) revisions a par
Nota: las revisiones a par se explican en la sección 4.

3-5
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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 Descripción de documento
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 En este documento se encuentra el diseño a bajo nivel
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.

4-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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

5-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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

especifica 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 configuración #
3 de Marzo del 2009

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 especifica el identificador o los identificadores de requisitos que
satisface dicho método.

i. Ejemplo:

// this method implements requirement 452

public void do Transaction(float mount1, float mount1)

5-3
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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
Resultados de las Resultados
por admin de la config pruebas
pruebas esperados

Pruebas para que los

elementos entren bajo
la administración de la Evaluación de
configuración resultados

Correcciones
Errores

Figura 6-1. Flujo del proceso de pruebas

9-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

9-2
 SCU plan SQA
Control de configuración #
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 :___

____________________________________________________________________________
____________________________________________________________________________
____________________________________________________________________________
ACCIÓN DE CORRECCIÓN:
____________________________________________________________________________
ESTADO: APROBADO - CANCELADO - APLAZADO
ADMINISTRADOR DE PROYECTO: _____________________________ FECHA:_________

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

9-3
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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

9-4
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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

9-5
 SCU plan SQA
Control de configuración #
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 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.

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.

9-6
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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 Introducción rápida Dirigido a: 26/Enero 27/Enero/09
SCU. de lo trata el /09
Miguel Ángel Alcocer Flores
proyecto de
desarrollo para el Daniel Iván Cuevas Zamora
SCU, Cuales son Impartido por:
los requerimientos,
casos de uso, Abraham José Rivero Cauich
técnicas y
cualquier otra
información que
resulte relevante
para el desarrollo
del proyecto
Hibernate con Curso para Dirigido a: 28/enero 3/Febrero/0
Oracle 10g aprender a crear /09 9
Miguel Ángel Alcocer Flores
bases de datos y
poder manipular Daniel Iván Cuevas Zamora
las mismas con Omar Estrella Castro
Oracle 10g
Miguel Gonzáles Novelo
Impartido por:
Israel Antonio López Alonso
Augusto Valdez
Abraham José Rivero Cauich

10-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

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.

11-1
 SCU plan SQA
Control de configuración #
3 de Marzo del 2009

APENDICE A: LISTA DE ACRONIMOS

SCM Software Configuration Management

SQA Software Quality Assurance
SRS Software Requirements Specification

A-1
CHECKLISTS / LISTA DE VERIFICACION
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

Checklist para el proceso de auditoría a la 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.

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

Checklist para el proceso de auditoría a la administración de la configuración.
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.

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