Modelo de Proceso Adaptable

Plantillas de documento:
Plan de SQA

3.2.10 Prueba de revisin de las especificaciones

En la implementacin del software, se deber llevar una revisin bajo las
caractersticas solicitadas por el cliente, cumpliendo principalmente como regla
general las siguientes pruebas dentro de la aplicacin:

El acceso al sistema ser restringido por un usuario y password

asignados por el administrador del sistema.
Los tipos de usuarios para el acceso al sistema son: administrador,
auxiliar, profesor y alumno. Cada tipo de usuario tendr sus restricciones
o permisos para realizar tareas especficas en el sistema.
El sistema permitir realizar los procesos necesarios para el
mantenimiento del sistema.
Dependiendo el tipo de usuario se podrn realizar las siguientes tareas o
procesos.
El usuario de tipo auxiliar tendr acceso a los mdulos de altas, bajas,
modificaciones, consultas, reportes e impresin de certificados. Adems
tendr acceso a mdulos destinados al registro de los alumnos.
El usuario de tipo administrador tendr acceso a los mdulos de altas,
bajas, modificaciones, consultas, reportes e impresin de certificados.
El usuario de tipo profesor slo podr dar de alta, dar de baja, modificar,
consultar y hacer bsqueda de calificaciones.
El usuario de tipo alumno slo tendr acceso para hacer bsqueda de
sus calificaciones.
El equipo del usuario debe tener instalado algn browser de su eleccin
para poder accesar a las pantallas del sistema.
La velocidad de respuesta del sistema, depender de los componentes
del hardware y en gran medida de la velocidad y tipo de conexin del
equipo cliente y del servidor.

3.2.11
Auditoras

Control

de

Revisiones

de

Cambio

Dentro de las especificaciones pactadas en aplicacin se deben de respetar las

caractersticas ya mencionadas para evitar conflictos en el momento del
desarrollo del software, se debe mantener un control especfico entre clientedesarrollador para poder tener un acuerdo comn en la aplicacin final
generada, la cuales se debern apegar a los siguientes trminos:

Requerimientos mnimos
Se especifican las revisiones al momento del desarrollo de la aplicacin y
auditoras que deben realizarse como mnimo, as como la agenda para
la realizacin de las mismas tareas mencionadas.
Los requerimientos mnimos sealan las tareas que dicho software debe
implementar para cumplir su funcin final y satisfacer las necesidades
del cliente a la hora de realizarse la instalacin y uso del mismo
producto, dichas caractersticas se encuentran en el punto 3.2.10.
Revisin de requerimientos
Esta revisin se realiza para asegurar
requerimientos especificados por el Cliente.

que

se

cumpli

con

los

Revisin de diseo preliminar

Esta revisin se realiza para asegurar la consistencia y suficiencia tcnica
del diseo preliminar del software.
Revisin de diseo crtico
Esta revisin se realiza para asegurar la consistencia del diseo detallado
con la especificacin de requerimientos.
Revisin del Plan de Verificacin & Validacin
Esta revisin se realiza para asegurar la consistencia y desarrollo
completo del software, que se generar despus de una serie de pruebas
aplicadas a los requerimientos y caractersticas del software, de cumplirse
dichos puntos sern validados y se revisar que todo cumpla con las
normas necesarias para el uso correcto del sistema de control escolar.

3.3 SQA Auditoras

En esta seccin, se describen las revisiones que sern realizadas, especificando
cmo y cuando se realizarn, que acciones se tomarn a partir de los
resultados obtenidos y como sern implementadas estas acciones.

Auditora funcional
Esta auditora se realiza previa a la liberacin del software, para verificar
que todos los requerimientos especificados en el documento de
requerimientos fueron cumplidos.
Auditora fsica
Esta revisin se realiza para verificar que el software y la documentacin
son consistentes y estn aptos para la liberacin.
Auditoras internas al proceso
Estas auditoras son para verificar la consistencia: del cdigo versus el
documento de diseo, especificaciones de interface, implementaciones de
diseo versus requerimientos funcionales, requerimientos funcionales
versus descripciones de testeo.
Revisiones de gestin
Estas revisiones se realizan peridicamente para asegurar la ejecucin de
todas las actividades identificadas en este Plan. Deben realizarse por una
persona ajena al grupo de trabajo (en caso de que sea posible).
Revisin del Plan de gestin de configuracin
Esta revisin se realiza para asegurar la consistencia y completitud de los
mtodos especificados en el Plan de gestin de configuracin.
Revisin Post Mortem
Esta revisin se realiza al concluir el proyecto para especificar las
actividades de desarrollo implementadas durante el proyecto y para
proveer recomendaciones.

4.0
Reporte
Accin/Seguimiento

de

Problemas

Correccin

Se implementa esta tarea con el fin de descubrir errores en la funcin, la lgica

la implementacin de cualquier producto del software, verificar que satisface
sus especificaciones, que se ajusta a los estndares establecidos, sealando
las posibles desviaciones detectadas.
Mecanismo:
Es un proceso de revisin riguroso, su objetivo es llegar a detectar lo
antes posible, los posibles defectos o desviaciones en los productos que
se van generando a lo largo del desarrollo. Por esta caracterstica se
adopta esta prctica para productos que son de especial importancia.
En la reunin participan el responsable de SQA e integrantes del equipo
de desarrollo.
Se debe convocar a la reunin formalmente a los involucrados, informar
del material que ellos deben preparar por adelantado, llevar una lista de
preguntas y dudas que surgen del estudio del producto a ser revisado.
Mtricas y Anlisis:
El concepto de mtrica es el trmino que describe muchos y muy variados
casos de medicin. Siendo una mtrica una medida estadstica (no
cuantitativa como en otras disciplinas ejemplo fsica) que se aplica a
todos los aspectos de calidad de software, los cuales deben ser medidos
desde diferentes puntos de vista como el anlisis, construccin, funcional,
documentacin, mtodos, proceso, usuario, entre otros.
Segn la ISO 9126 como medicin de la calidad del software se tendrn
las siguientes mtricas:
El modelo de calidad establecido en la primera parte del estndar, ISO 9126-1,
clasifica la calidad del software en un conjunto estructurado de caractersticas
y subcaractersticas de la siguiente manera:

Funcionalidad - Un conjunto de atributos que se relacionan con la

existencia de un conjunto de funciones y sus propiedades especficas.
Las funciones son aquellas que satisfacen lo indicado o implica
necesidades.
o

Idoneidad

Exactitud

Interoperabilidad

Seguridad

Cumplimiento de normas.

Fiabilidad - Un conjunto de atributos relacionados con la capacidad del

software de mantener su nivel de prestacin bajo condiciones
establecidas durante un perodo de tiempo establecido.
o

Madurez

Recuperabilidad

Tolerancia a fallos

4.1 Mecanismos de Reportes

Esta seccin describe las prcticas y procedimientos que sern seguidos para
informar de los problemas detectados, hacer el seguimiento y resolverlos. Esto
se aplica tanto a desviaciones encontradas en el producto generados como en
el proceso seguido. Tambin deben especificarse las responsabilidades en la
implementacin de estos mecanismos.
Para el proyecto se levantan los registros de no conformidad con las
especificaciones colocando el rea que genero el problema y la accin
correctiva, dando a conocer en primer instancia los fallos encontrados al
equipo del SQA encargado de la programacin, y en dado caso que el error siga
generando conflictos se le informar a los encargados directos de dicho
proyecto para generar una solucin alternativa a la falla y encontrar la manera
de repararla.

4.2 Responsabilidades
Se deben identificar herramientas de software, tcnicas, y metodologas de
soporte para las actividades de aseguramiento de calidad.
En esta seccin se indican las herramientas especiales de software, tcnicas y
metodologas que apoyarn la gestin del Responsable de Calidad. En esta
seccin se incluirn las checklist que sern utilizadas para hacer las revisiones
detalladas en la seccin 4 Revisiones
Control de cdigo

Se indican los mtodos que se utilizarn para mantener, almacenar, asegurar y

documentar las versiones controladas identificadas en las fases de desarrollo,
lo cual ser definido en conjunto con el Arquitecto de Software

4.3 Recopilacin y evaluacin

Se describen los tipos de registros que sern generados, mantenidos y

almacenados por el Responsable de SQA y el objetivo de los mismos,
adjuntando el formato que tendrn dichos documentos.
Se debe convocar a la reunin formalmente a los involucrados, informar del
material que ellos deben preparar por adelantado, llevar una lista de preguntas
y dudas que surgen del estudio del producto a ser revisado.
Para este proyecto los registros que generan las actividades de SQA estn
indicados por los entregables asociados: Entrega semanal de SQA, Informe de
revisin de SQA, Informe de Revisin Tcnica Formal, Registros de SQA.

4.4 Estadstica SQA

Se indican los mtodos que se utilizarn para proteger el almacenamiento
adecuado de los programas, documentacin, etc., as como tambin la
prevencin de acceso sin autorizacin, dao, etc., lo cual ser definido en
conjunto con el Arquitecto de Software.
Las desviaciones encontradas en las actividades y en los productos deben ser
documentadas y ser manejadas de acuerdo a un procedimiento establecido.
Se debe chequear que los responsables de cada plan los modifiquen cada vez que sea
necesario, basados en las desviaciones encontradas.

5.0 Mejora de Procesos de las Actividades del

Software
Durante el proceso del desarrollo del software, se harn verificaciones para determinar
los mtodos necesarios en los que la aplicacin pueda evolucionar con mejoras
implementadas, tales como:
La verificacin de que:

a. los requerimientos descritos en el documento de requerimientos han

sido aprobados por una autoridad apropiada. En este caso sera
que cumplan con el acuerdo logrado entre el cliente y el equipo.
b. los requerimientos descritos en el documento de requerimientos son
implementados en el diseo expresado en el documento de diseo.
c. el diseo expresado en el documento de diseo esta implementado
en cdigo.
Validar que el cdigo, cuando es ejecutado, se adecua a los requerimientos expresados
en el documento de requerimientos.

5.1 Metas y objetivos del SPI

Generar el desarrollo del Software en tiempo y forma estipulado.

Cumplir con las especificaciones generadas por el cliente.
Cubrir los requerimientos mnimos para la instalacin y uso del software

creado.
El software ser capaz de soportar actualizaciones para su evolucin de

cdigo.
Mnima tolerancia de fallos capas de ser solucionada a corto tiempo.

5.2 Tareas y Responsabilidades SPI

El equipo del SQA tendr como nico fin cumplir con las acciones necesarias
para que el software pueda adaptarse a las necesidades del cliente, tiene como
responsabilidad la entrega en tiempo y forma del producto asegurando que
este cumpla con la calidad y confiabilidad requerida para el uso seguro de las
instituciones sin el riesgo de filtracin de informacin
Los responsables, tambin tendrn la labor de asegurarse que todos los puntos
acordados se cumplan adecuadamente dentro del desarrollo del cdigo y bajo
los requerimientos pactados asegurando la calidad del producto.
Es responsabilidad asegurar el soporte necesario para corregir errores dentro
del software que hayan sido producto por un error de cdigo.

6.0 Configuracin del Software de Administracin

General

Este plan debe contener mtodos para identificar componentes de software, control e
implementacin de cambios, y registro y reporte del estado de los cambios
implementados.

Para cada uno de los planes se revisar su correccin con respecto a los
estndares impuestos. El proceso de generacin de documentos es el
siguiente:

Equipo revisa el documento, y lo entrega con las indicaciones al

Ingeniero de Calidad.
Ingeniero de Calidad proceder a formatear las indicaciones para
que correspondan a la plantilla.
Ingeniero de Calidad devolver los documentos.
Todo esto ser monitoreado en forma constante por el Lder del
Proyecto.

Planificacin para la generacin de los documentos

Para generar cada uno de los documentos, se seguir el siguiente proceso:

El
Lder
del
Proyecto
tomar
todos
los
documentos
correspondientes al plan en cuestin, y los juntar en un
documento inicial de formato libre.
El Lder del Proyecto luego redacta un informe en formato libre que
contenga los puntos de contenido general de los documentos y se
lo enva al ingeniero de Calidad.
El ingeniero de Calidad toma el documento y lo formatea segn la
plantilla de los documentos de transicin que aparece en este
documento, en el anexo.
El ingeniero de Calidad dar el visto bueno al documento para
entregarlo.

7.0 Herramientas, Tcnicas y Mtodos del SQA

Se deben identificar herramientas de software, tcnicas, y metodologas de
soporte para las actividades de aseguramiento de calidad.
Se deben especificar los mtodos y procedimientos utilizados para especificar,
monitorear, y controlar las reas de riesgo durante el proyecto.

Los riesgos identificados, la estrategia de mitigacin, monitoreo y plan de

contingencia a ser llevados a cabo, sern descritos en el Documento de
Gestin de Riesgos, con lo cual se podr hacer referencia a l.
Implementacin de la base de datos se realizar con el DBMS (Data Base
Management System) MySQL standard; dado que el sistema se ejecutar en
Web, se utilizar tecnologa Web como: PHP, sobre una plataforma Apache web
HTML, Javascript y CSS para el desarrollo de interfaz de usuario.

Administrador: permitidos todos los privilegios.

Auxiliar: bloqueados todos los privilegios de estructura y administracin,

activados todos los privilegios de Datos.

Profesor: bloqueados todos los privilegios de estructura y administracin,

activados todos los privilegios de Datos.

Alumno: bloqueados todos los privilegios de estructura, administracin.

En datos se bloquean las opciones de INSERT, UPDATE y DELETE.

8.0 Apndice
Como anexo a la documentacin proporcionada para el cliente, se
agregaran estndares para asegurar la calidad del producto, done se aplican a
la documentacin entregada:
Como estndares de documentacin se definirn dos documentos:

Estndar de documentacin tcnica y

Estndar de documentacin de usuario.

La documentacin tcnica del producto debe:

Ser adecuada para que un grupo independiente del de desarrollo

pueda encarar el mantenimiento del producto.

Incluir fuentes, Modelos de Casos de Uso, Objetos

Para la escritura de documentos se han definido plantillas para ser

utilizadas en la elaboracin de entregables.
En estas plantillas se definen:

encabezado y pie de pgina.

fuente y tamao de fuente para estilo normal

fuente y tamao de fuente para los ttulos a utilizar

datos mnimos
responsables.

que

se

deben

incluir:

fecha,

versin

Estndar de verificacin y prcticas

Se utilizan las prcticas definidas en el Plan de Verificacin y Validacin.
Como estndar se utiliza el documento de:
Std 1012-1986 IEEE Standard for Software Verification and Validation
Plans.

Recomendaciones
Respecto a las revisiones por parte de los desarrolladores y supervisores de
recomienda seguir los siguientes puntos para asegurar la entrega adecuada del
producto desarrollado:

Las actividades descritas en el documento a revisar deben ser

monitoreadas desde su comienzo.
Comunicar al responsable del artefacto, cuando debe comenzar y que
cosas se van a evaluar.
Si se detectan desviaciones que impactan en el proyecto, el informe
acerca de las revisiones realizadas debe dirigirse al Lder y Arquitecto
para que ese impacto se analice y tenga en cuenta en los planes del
proyecto. Lo ms importante es evitar que se ignoren.