Proyecto de Ingeniería de Software .

Plan de SQA

GUÍA DE SQA

ÍNDICE

1 PROPÓSITO.....................................................................................................................2
2 ACRÓNIMOS Y ABREVIATURAS..........................................................................................2
3 REFERENCIAS.................................................................................................................2
4 BUENAS PRÁCTICAS........................................................................................................ 2
4.1 Prácticas generales.....................................................................................................................2
4.1.1 Riesgos...............................................................................................................................................2
4.1.2 Mediciones y estimaciones...................................................................................................................2
4.1.3 Gestión de configuración......................................................................................................................3
4.1.4 Apego al proceso.................................................................................................................................3
4.2 Recomendaciones.......................................................................................................................3
4.3 Fase Inicial.................................................................................................................................3
4.3.1 Requerimientos funcionales..................................................................................................................3
4.3.2 Requerimientos no funcionales y atributos de calidad............................................................................4
4.3.3 Modelo de calidad................................................................................................................................4
4.3.4 Factibilidad..........................................................................................................................................4
4.3.5 Alcance...............................................................................................................................................4
4.3.6 Visión de la arquitectura......................................................................................................................4
4.3.7 Planes de verificación..........................................................................................................................5
4.3.8 Prototipo.............................................................................................................................................5
4.3.9 Validación de los requerimientos con el cliente......................................................................................5
4.4 Recomendaciones.......................................................................................................................5
4.5 Fase Elaboración........................................................................................................................5
4.5.1 Requerimientos estables......................................................................................................................5
4.5.2 Revisión de Alcance.............................................................................................................................5
4.5.3 Arquitectura estable.............................................................................................................................6
4.5.4 Apego al proceso.................................................................................................................................6
4.5.5 Gestión de proyecto.............................................................................................................................6
4.6 Recomendaciones.......................................................................................................................6
4.7 Fase Construcción......................................................................................................................6
4.7.1 Revisión del producto..........................................................................................................................6
4.7.2 Revisión de informes de validación.......................................................................................................6
4.7.3 Documentación de usuario...................................................................................................................6
4.8 Fase Transición..........................................................................................................................7
4.8.1 Aceptación..........................................................................................................................................7
4.8.2 Detección de riesgos............................................................................................................................7
4.8.3 Plan de desarrollo................................................................................................................................7
4.8.4 Plan de gestión de proyecto.................................................................................................................7
4.8.5 Encuesta de satisfacción......................................................................................................................7
5 MÉTRICAS.......................................................................................................................7
5.1 Tabla de Métricas Internas..........................................................................................................7
5.1.1 Tabla de Métricas Externas..................................................................................................................8
5.1.2 Tabla de Métricas de Calidad en el uso.................................................................................................9
6 CHECKLISTS.................................................................................................................10
7 SUGERENCIAS PARA LAS PROP DE CALIDAD O MODELO DE CALIDAD.......................................10
8 ANEXO REVISIONES......................................................................................................10
8.1 Revisión de Requerimientos:.....................................................................................................10
8.1.1 Revisión del diseño de alto nivel.........................................................................................................11
8.1.2 Revisión del Plan de Verificación y Validación......................................................................................12
8.1.3 Revisión del Plan de SCM...................................................................................................................12
8.1.4 Revisión del Plan del Proyecto............................................................................................................12
8.1.5 Diseño vs. Código, Diseño vs. Requerimientos y Testeo vs. Requerimientos..........................................13

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 1 de 14
Proyecto de Ingeniería de Software . Plan de SQA

1 PROPÓSITO

El objetivo de esta guía es brindar soporte al rol de aseguramiento de la calidad en el marco del curso
“Proyecto de Ingeniería de Software”, [PIS].
Dicho soporte apunta a que las tareas realizadas en el rol del SQA no se conviertan en meras revisiones
sintácticas de los distintos entregables, sino que sea esencial en el éxito del proyecto.

Según se establece en [1], el rol del SQA consiste en monitorear métodos, prácticas y estándares aplicados
por el resto del equipo para verificar que fueron propiamente aplicados.
Llevado al [PIS], esto se traduce en preparar y efectuar las distintas revisiones a los entregables de modo de
asegurar la calidad de los mismos. La guía pretende lograr que además de realizar las revisiones se realice
una fuerte actividad de seguimiento de las tareas que se realizan para construir los entregables que
finalmente serán revisados, basándose en “What is not tracked is not done”, citado en [1] haciendo
referencia a que el SQA debe seguir y monitorear el proceso de construcción de un artefacto además de
realizar revisiones cuando el mismo se ha construido.

También se pretende establecer que ésta es una disciplina de soporte y apoyo al resto de las disciplinas
poniendo especial énfasis en el monitoreo de aquellas actividades y artefactos indispensables para asegurar
los hitos de las distintas fases e iteraciones como forma de asegurar el éxito del proyecto.

Estas tareas deben llevarse a cabo cuidadosamente para que el área de SQA no se convierta en algo inútil
que atrase las planificaciones e impacte negativamente en la calidad. Parte del éxito de esta disciplina
consiste en la objetividad a la hora de hacer las revisiones y en elegir una buena política para informar las
desviaciones y reportes de acciones correctivas.

2 ACRÓNIMOS Y ABREVIATURAS

[PIS] Proyecto de Ingeniería de Software.

3 REFERENCIAS

[1] Managing the Software Process, Watts s. Humphrey, Addison-Wesley.

[2] IS2 - Modelo de calidad del curso.
[3] ISO/IEC 9126 Information Technology – Software product quality

4 BUENAS PRÁCTICAS

4.1 Prácticas generales

4.1.1 Riesgos

Se debe poner especial énfasis en asegurar que se realice una correcta gestión de riesgos. El SQA
debe por lo menos asegurar que los mismos sean discutidos en la reunión quincenal y que se
reporten los resultados de cuales fueron detectados y para cuales se establecieron políticas de
prevención, mitigación y contingencia. También debe asegurar que se comparen los costos de
prevenir, eliminar o al menos reducir la probabilidad de ocurrencia e impacto de los riesgos. En caso
de que se tomen acciones para con ellos, se deberán verificar que se ajustaron los planes
pertinentes (Plan del Proyecto, Plan de V&V, Plan de SCM, Plan de SQA, etc.).

Resumiendo el SQA debe asegurar en el transcurso de todo el proyecto que se realiza un

seguimiento de los riesgos dentro de cada área y que estos son discutidos en las reuniones
quincenales. En cada iteración se vuelven a evaluar y priorizar los riesgos de acuerdo al impacto y la
probabilidad de ocurrencia actual.

4.1.2 Mediciones y estimaciones

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 2 de 14
Proyecto de Ingeniería de Software . Plan de SQA

Se debe asegurar que las mediciones que se realizan son fiel reflejo de la realidad y que las
estimaciones se basen en esas mediciones y que esto permita ajustar las sucesivas estimaciones.

4.1.3 Gestión de configuración

El SQA debe asegurar que el SCM entienda su rol, que entienda el significado de la línea base (el
cual suele ser comprendido a fines de la fase de transición), y que realice las actividades de
seguimiento de la línea base, para lo cual además de la investigación pertinente se recomienda
buscar ayuda.

4.1.4 Apego al proceso

Se monitorea selectivamente la realización de las actividades de desarrollo, documentación y

verificación para asegurar la consistencia con los planes y estándares o normas. Se verifica que los
tests especificados y las revisiones por pares son conducidas apropiadamente, que los resultados y
datos requeridos son registrados, y que las acciones correctivas son realizadas.
Se auditan los procedimientos del Comité de Control de Cambios para verificar que son
efectivamente realizados como se especificaron. Se verifica periódicamente que el Responsable de
SCM mantiene apropiadamente el control de la línea base, así como el registro completo de cambios
para requerimientos, diseño, código, verificación y documentación.

4.2 Recomendaciones

 Las actividades a revisar deben ser monitoreadas desde su comienzo. Se recomienda avisar
al responsable de cada artefacto cuando debe comenzar a construirse y que cosas se van a
evaluar del mismo.

 Si en las revisiones se detectan desviaciones que implican cambios que a criterio del
responsable de SQA impactan en el proyecto el informe acerca de las revisiones realizadas
debe dirigirse al Administrados y Arquitecto para que ese impacto se analice y tenga en
cuenta en los planes del proyecto

4.3 Fase Inicial

4.3.1 Requerimientos funcionales

En la fase inicial se deben relevar los requerimientos mínimos que permitan establecer la visión del
producto, determinar los posibles riesgos (sobre todo tecnológicos) que afecten a la planificación y
construcción del producto para así determinar los riesgos más importantes del proyecto.

Es necesario equilibrar el esfuerzo en detallar los requerimientos junto con la disponibilidad del
cliente, es decir, la idea es priorizarlos y detallar solamente aquellos que resulten críticos. Luego a
fines de la fase de elaboración todos y cada uno de los requerimientos estarán detallados logrando
así atacar los mismos en forma iterativa logrando una retroalimentación por parte del equipo de
desarrollo que ya implementó el prototipo y los requerimientos críticos. Por eso es necesario que el
SQA establezca el equilibrio en la obtención de los requerimientos que realiza junto con el grupo de
analistas.

4.3.1.1 Revisión de Requerimientos funcionales

Esta revisión se utiliza para asegurar la adecuación, factibilidad técnica y completitud de los
requerimientos definidos en la Especificación de Requerimientos y verificar que se cumplan los
atributos del estándar IEEE 830-1993 para los Requerimientos funcionales y no funcionales
(completos, consistentes, trazables, verificables, modificables, priorizados).
Ver el detalle de esta revisión en el documento Anexo [Revisiones].

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 3 de 14
Proyecto de Ingeniería de Software . Plan de SQA

4.3.2 Requerimientos no funcionales y atributos de calidad

El SQA también es responsable de asegurar el relevamiento de los requerimientos no funcionales e

identificar las propiedades de calidad del producto que repetidamente son olvidados. Para realizar
esta tarea se sugiere primero leer [IS-1], [IS-2] para luego definir los atributos de calidad del
producto a desarrollar. Es importante que el relevamiento de cada requerimiento no funcional o
atributo de calidad esté siempre definido dentro de un contexto.

A continuación se muestra un ejemplo en el cual un atributo de calidad ha sido mal relevado:

“el producto debe tener buena performance”, faltaría aquí definir que es buena performance y se
debería relevar algo como “en condiciones de carga elevada, es decir 100 usuarios accediendo al
sistema en forma concurrente, la respuesta del sistema a los requerimientos establecidos como
críticos debe ser a lo sumo de 7 segundos” (indicando también las características técnicas del
sistema si corresponde).

La siguiente lista intenta brindar apoyo en la detección de dichos requerimientos:

 FURPS(funcionalidad, usabilidad, confiabilidad, performance, soporte)

 Modificabilidad, adaptabilidad, subsetability
 Reportes del sistema
 Restricciones de software y hardware
 Restricciones de desarrollo(proceso, herramientas de desarrollo)
 Restricciones de implementación y diseño
 Internacionalización
 Licencias y restricciones legales
 Políticas sobre manejo de errores o respaldo en operación
 Reglas del negocio o dominio
 Información interesante referente al dominio

Este tipo de requerimientos o restricciones tendrán mucha importancia a la hora de detectar riesgos
y analizar la arquitectura del sistema. Seguramente algunos de ellos sean ambiguos o inconsistentes
por lo cual deben ser corregidos y priorizados.

4.3.3 Modelo de calidad

Como referencia se utilizará el Modelo de Calidad [2] ajustado a las características particulares del
proyecto.

4.3.4 Factibilidad

Para este proyecto la factibilidad no es una opción pero en un proyecto “real” debe ser evaluada la
conveniencia o no de seguir con el proyecto.

4.3.5 Alcance

Se debe asegurar que para determinar el alcance se realizaron estimaciones basadas en varios
métodos, pero sobretodo basadas en proyecciones realizadas sobre la productividad del equipo
(medida por ejemplo al realizar prototipos). Se debe tener presente que las estimaciones realizadas
en esta fase seguramente no serán acertadas, y se afinaran en la fase de elaboración, para que al
final de esta fase se esté en condiciones de negociar acertadamente el alcance final.

4.3.6 Visión de la arquitectura

Se debe haber realizado un diseño preliminar de la arquitectura basado en los requerimientos o

casos de uso críticos, los requerimientos no funcionales, en las restricciones de calidad y en los
resultados de la prototipación.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 4 de 14
Proyecto de Ingeniería de Software . Plan de SQA

4.3.7 Planes de verificación

Ver el detalle de esta revisión en el documento Anexo [Revisiones].

4.3.8 Prototipo

Es importante que se realice una demo del prototipo, ya sea con el cliente o director del proyecto
para demostrar que se han mitigado todos los riesgos tecnológicos y que exista un resultado visible
del mismo.
El prototipo sirve para ir estableciendo la coordinación y comunicación entre el grupo de especialistas
técnicos y asegurarse que se estudiaron realmente las tecnologías a aplicar en el proyecto. Además
es vital que se tomen medidas acerca de la productividad del grupo e individual de modo de poder
ajustar las estimaciones y tener elementos para decidir a quien asignar tareas especificas.
También se debe intentar tomar registro acerca de la proporción de errores en el prototipo para
poder estimar la densidad de defectos a buscar en las próximas fases.

4.3.9 Validación de los requerimientos con el cliente

Esta actividad se debe basar fuertemente en la validación de aquellos requerimientos más

importantes. Se debe validar la visión del sistema sin entrar en detalles específicos que se validaran
en la fase de elaboración.

4.4 Recomendaciones

 Las actividades a revisar deben ser monitoreadas desde su comienzo. Se recomienda avisar
al responsable de cada artefacto cuando debe comenzar a construirse y que cosas se van a
evaluar del mismo.

 El informe acerca de las revisiones realizadas debe dirigirse al responsable del área, al
administrador y al arquitecto (para contemplar en la planificación, de proyecto y desarrollo,
las acciones correctivas necesarias).

 No se deben intentar detallar todos los casos de uso en la fase inicial.

 Las estimaciones y planes realizados en la fase inicial no se pueden considerar reales.

 No se puede asumir que la arquitectura va a ser definida en la fase inicial y tomarla como
estable en ese entonces.

 En esta fase se deben elegir los casos de uso que van a guiar la fase de elaboración.

4.5 Fase Elaboración

4.5.1 Requerimientos estables

Los requerimientos deben quedar en un 80% detallados para fines de esta fase y además se
requiere que los mismos sean estables. Esto requiere que los mismos sean validados con el cliente
nuevamente ahora poniendo énfasis en aquellos en los cuales no se profundizó en la fase inicial. El
tener estables los requerimientos es necesario para poder también lograr que la arquitectura sea
estable.

4.5.2 Revisión de Alcance

Se debe asegurar que el alcance se negocie nuevamente tomando ahora resultados concretos sobre
la productividad del grupo.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 5 de 14
Proyecto de Ingeniería de Software . Plan de SQA

4.5.3 Arquitectura estable

Para fines de la fase se debe tener una arquitectura estable mediante la implementación de los
casos de uso críticos, permitiendo cumplir con los requerimientos no funcionales y de calidad.
También se debe considerar la capacidad de soportar los casos de uso que se implementarán en la
fase de construcción.

4.5.4 Apego al proceso

Lo más importante para fin de esta fase es que se tenga un producto con capacidad funcionalidad
básica que se pueda validar contra el cliente. El tener ese resultado asegura que el resto de las
tareas se están llevando en forma aceptable. Esto permite definir la línea base sobre algo funcional,
permite planificar mejor las pruebas y poder realizar en algún momento en caso de ser necesario
pruebas de regresión. El no tener un producto funcional no permite tener visión sobre el avance real
del proyecto.

4.5.5 Gestión de proyecto

Se debe asegurar que en los informes de situación se calculen los datos necesarios para conocer los
gastos incurridos sobre planificados, para poder afinar planes y asignar tareas. Asegurar que el
Administrador cumpla un rol activo en la gestión.

4.6 Recomendaciones

 Se deben tener productos funcionales luego de cada integración.

 Se deben implementar los casos de uso críticos para la arquitectura.

 No se debe detallar el diseño de todo el sistema.

 Se deben modificar todos los planes según las mediciones de esta fase.

4.7 Fase Construcción

4.7.1 Revisión del producto

Se debe tener una nueva versión del producto para luego de cada iteración y se debe realizar una
demo al director del proyecto de modo de ir asegurando el avance del mismo. Las funcionalidades
planificadas que no fueron desarrolladas se deben agregar en próximas iteraciones.
Ver terminado el producto. El cliente debe conocer el avance del producto por medio de demos.

4.7.2 Revisión de informes de validación

Asegurar que se realicen los informes sobre los resultados de las validaciones con el cliente por
medio de demos.

4.7.3 Documentación de usuario

Para fines de esta fase se debe tener finalizado la documentación de usuario por lo cual se sugiere
que se monitoree esta actividad para que el responsable realice esta actividad y no sea una tarea
para la fase de transición.

4.7.4 Gestión de configuración

Asegurarse que se controla la línea base y que se utilizan los métodos definidos para el control de
código.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 6 de 14
Proyecto de Ingeniería de Software . Plan de SQA

4.7.5 Revisiones por pares

Asegurar que las revisiones por pares se realizan de forma efectiva teniéndose como indicador el
contraste entre los errores encontrados en las revisiones con los encontrados por Verificación.

4.7.6 Reportes de verificación

Se debe asegurar que se cumplan con los planes de verificación y que los resultados sean
informados de manera inmediata.
Se puede también contrastar las tasas de defectos encontrados en la fase de elaboración contra los
de construcción para tomarlo como indicador.

4.7.7 Gestión del proyecto

En la primera iteración se debe asegurar que se mida esfuerzo planificado sobre el incurrido para
afinar la planificación de la próxima iteración.

4.8 Fase Transición

4.8.1 Evaluación final del producto

Para realizar la evaluación final del área se debe tomar en cuenta el transcurso de todo el proyecto,
evaluándose lo planificado en el área contra lo realizado, el apego al proceso en todo el transcurso
del proyecto y el cumplimiento o no de las propiedades de calidad identificadas al inicio. Es por esto
que se recomienda realizar la evaluación final de SQA a medida que el proyecto avanza.

4.8.2 Aceptación

Se debe asegurar que se realice la encuesta de satisfacción del cliente.

5 MÉTRICAS
Se sugiere que para las propiedades de calidad que se identifiquen en el proyecto se definan métricas para
evaluarlas. En las secciones siguientes se muestran ejemplos de métricas y como se definen para
determinadas propiedades de calidad.
Estas métricas se basan en el borrador de estándar ISO/IEC 9126 [3].

5.1 Tabla de Métricas Internas

Característica: Funcionalidad
Subcaracterística: Conveniencia
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Completitud de la ¿Cuán completa es la implementación X=1–A/B
implementación funcional. funcional? A = Número de casos de uso (o funciones) no
implementadas
B = Número de casos de uso (o funciones) descriptas en el
Alcance del sistema final (último compromiso de alcance, fin
de fase de elaboración)

Y=1–A/C
A = Número de casos de uso (o funciones) no
implementadas
C = Número de casos de uso (o funciones) descriptas en el
Alcance del sistema al final de la fase inicial

Z=1–A/D
A = Número de casos de uso (o funciones) no
implementadas
D = Número de casos de uso (o funciones) descriptas en la

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 7 de 14
Proyecto de Ingeniería de Software . Plan de SQA

Especificación de Requerimientos

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 8 de 14
Proyecto de Ingeniería de Software . Plan de SQA

Característica: Fiabilidad
Subcaracterística: Madurez
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Levantamiento de ¿Cuántos defectos han sido X = A
defectos (atributo para corregidos? A = Número de defectos corregidos en diseño /
medir la calidad del ¿Cuál es la proporción de defectos codificación.
proceso) corregidos?
Y=A/B
A = Número de defectos corregidos en diseño /
codificación.
B = Número de defectos detectados en las
revisiones.
Densidad de defectos ¿Cuál es la proporción de defectos X = 1 – A / B
respecto al tamaño del producto? A = Número de defectos que no fueron corregidos.
B = Tamaño del producto.

NOTA: El tamaño del producto se mide en líneas de

código.
Característica: Usabilidad
Subcaracterística: Capacidad de ser entendido
(Understandability)
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Completitud de la ¿Qué proporción de las funciones X=A/B
descripción (casos de uso) o tipos de funciones A = Número de funciones (casos de uso) o tipos de
se describen en la descripción del funciones descriptas en la descripción del producto.
producto (documentación de
usuario, ayuda, etc)? B = Número total de funciones (casos de uso) o tipos
de funciones.

NOTA: Esta medida indica si los usuarios

potenciales entenderán la capacidad del
producto luego de leer la descripción del
producto.
Subcaracterística Operabilidad
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Consistencia operacional ¿Qué proporción de las operaciones X = 1 - A / B
se comportan de manera similar a A = Número de instancias de operaciones con
operaciones similares en otras partes comportamiento inconsistente.
del sistema?
B = Número total de operaciones.

5.1.1 Tabla de Métricas Externas

Característica: Funcionalidad
Subcaracterística: Conveniencia
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Adecuación funcional ¿Cuán adecuadas son las funciones X = 1 - A / B
evaluadas? A = Número de funciones (casos de uso) en las cuales
se detectaron problemas en la evaluación.
B = Número de funciones (casos de uso) evaluadas.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 9 de 14
Proyecto de Ingeniería de Software . Plan de SQA

Característica: Fiabilidad
Subcaracterística: Madurez
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Densidad de defectos ¿Cuántos defectos fueron detectados X = A / B
durante el período de prueba? A = Número de defectos detectados.
B = Tamaño del producto.

NOTA: El tamaño del producto se mide en líneas de

código.
Característica: Usabilidad
Subcaracterística: Operabilidad
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Consistencia ¿Cuán consistentes son los X = 1 - A / B
operacional en el uso componentes de la interfase de A = Número de funciones que el usuario encontró
usuario? inaceptablemente inconsistentes según sus
expectativas.
B = Número de funciones usadas por el usuario durante
el período de prueba.

Y = A / UOT
A = Número de funciones que el usuario encontró
inaceptablemente inconsistentes según sus
expectativas.
UOT = Tiempo de operación del usuario (durante el
período de observación).
Característica: Portabilidad
Subcaracterística: Facilidad de instalación
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Facilidad de ¿Puede el usuario o quien mantiene X = A / B
instalación el software fácilmente instalar el A = Número de casos en que el usuario es exitoso en la
software en un ambiente operación de instalación.
operacional?
B = Número total de casos en que el usuario intenta
ejecutar la operación de instalación.

5.1.2 Tabla de Métricas de Calidad en el uso

Característica: Efectividad
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Tareas completadas ¿Qué proporción de las tareas son X = A / B
completadas? A = Número de tareas completadas
B = Número total de tareas que se intentaron realizar
Frecuencia de errores ¿Cuál es la frecuencia de errores? X=A/T
A = Número de errores del usuario
T = Tiempo de la prueba o número de tareas
Característica: Satisfacción
Métricas
Nombre Propósito de la métrica Medición o fórmula de cálculo
Escala de satisfacción ¿Cuán satisfecho está el usuario? X=A/B
A = Valor producida por el cuestionario
B = Mayor valor de la escala que puede producir el
cuestionario

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 10 de 14
Proyecto de Ingeniería de Software . Plan de SQA

6 ANEXO REVISIONES

6.1 Revisión de Requerimientos:

Entradas:
 Especificación de Requerimientos.
 Plan de Verificación y Validación.

Esta revisión se utiliza para asegurar la adecuación, factibilidad técnica y completitud de los
requerimientos definidos en la Especificación de Requerimientos. Se deberá evaluar la Especificación
de Requerimientos para los atributos definidos en el estándard IEEE 830-1993 (no ambiguos,
completos, verificables, consistentes, modificables, trazables, etc.) y asegurar que hay un detalle
suficiente para realizar por completo el diseño.
Los resultados de la Revisión de Requerimientos deberá ser documentada en el reporte
correspondiente, donde se identificarán todas las deficiencias y se proveerá un plan y una agenda
para la acción correctiva. Asimismo, debe tomarse una decisión sobre si se debe proceder o no a
corregir la Especificación de Requerimientos y para esto se debe tomar en cuenta las estimaciones
de costos, factibilidad y estudio de riesgos. Luego de tomada la decisión de proceder y la
Especificación de Requerimientos se actualiza para corregir las deficiencias, debería ser puesta bajo
control de configuración para establecer la línea base a ser usada por el diseño. Es importante que
se coloque la Especificación de Requerimientos en la línea base, ya que el SQA debería utilizar este
documento para la trazabilidad a lo largo de todo el desarrollo, de modo de validar la satisfacción de
los requerimientos contra el diseño, la codificación y la verificación.

Los atributos del estándar IEEE 830-1993 para los Requerimientos funcionales y no funcionales son:

1) Completos interna (de acuerdo al alcance) y externamente (todos los elementos están
definidos).
2) Consistentes (Ausencia absoluta de elementos contradictorios).
3) No Ambiguos (Debe existir un glosario para los términos del negocio).
4) Trazables (Mediante una matriz o cualquier otro artefacto).
5) Verificables (Existencia de métodos para verificar si se cumplen o no).
6) Modificables (No deben existir grandes dificultades para cambiarlos, como abuso de referencias
cruzadas).
7) Priorizados (Los requerimientos están ordenados por su importancia en el alcance).

La siguiente es una lista de defectos, de un orden más gramatical que técnico, pero que resulta de
gran utilidad para que no ocurran confusiones a la hora interpretar los Requerimientos, es decir, que
no haya ambigüedad en la especificación:

1) Términos persuasivos:
 Ciertamente, por lo tanto, claramente, obviamente, se deduce que.
Se debería aclarar el por qué de la obviedad.
2) Términos vagos:
 Algún (os), a veces, a menudo, usualmente, en general
Se deberían definir más precisamente.
3) Listas incompletas:
 Etc., y así sucesivamente, tales como.
Debería quedar claro en el contexto que se entiende de forma adecuada.
4) Rangos definidos que contienen supuestos no definidos:
 Los valores varían entre 10 y 100. (¿Enteros, Reales, Hexadecimales?)
Debería indicarse.
5) Términos frecuentes que se pueden interpretar de diversas maneras:
 Manejado, rechazado, procesado, eliminado, etc..
6) Pronombres ambiguos:

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 11 de 14
Proyecto de Ingeniería de Software . Plan de SQA

 “El módulo A se comunica con B y se activa su bandera de control” (¿La bandera es del
módulo A o del B?).
7) Comparaciones sin medida:
 Más alto, más bajo, mayor, menor, máximo, mínimo.
8) Afirmaciones que impliquen certeza:
 Siempre, cada, todos, ninguno, nunca.
Asegurarse de que sean verificables.
9) Cuando un término está definido en un lugar, tratar de no sustituir por la definición cada
aparición del término, más aún si el término está en el Glosario.
10) Cuando una estructura se define mediante palabras, se debería utilizar un sistema (diagrama,
especificación formal) para especificarla libre de ambigüedades.
11) Lista de palabras que a menudo son entendidas de forma diferente por cliente y desarrollador:
 Instantáneo, Simultáneo, Realizable, Terminar, Completo, Mínimo, Nominal, Normal,
Promedio, Valor Pico, de acuerdo a lo requerido/especificado/indicado.
12) Medidas no cuantificables que pueden indicar que un requerimiento no puede ser verificable:
 Flexible, Modular, Eficiente, Adecuado, Posible, Mínimo requerido/aceptable/razonable,
Mejor, Más alto/bajo, Más rápido/lento, Infrecuente, Usualmente, A menudo, De acuerdo
a lo especificado/requerido, Compatible con.

6.1.1 Revisión del diseño de alto nivel.

Entradas:
 Descripción de la Arquitectura.
 Modelo de Casos de Uso.
 Modelo de Diseño

La Revisión del Diseño de Alto Nivel se utiliza para evaluar la adecuación técnica del Diseño de Alto
Nivel (Descripción de la Arquitectura, Modelo de Caso de Uso, etc.), antes de comenzar con el diseño
detallado. La Revisión del Diseño de Alto Nivel debe chequear la compatibilidad del Diseño de Alto
Nivel con los Requerimientos funcionales, no funcionales y atributos de calidad de la Especificación
de Requerimientos y verificar la compatibilidad existente entre las interfaces de Software, Hardware
y usuarios. En definitiva, la Revisión del Diseño de Alto Nivel tiene como objetivo asegurar que todos
los requerimientos de la Especificación de Requerimientos se diseñan a alto nivel en forma completa
y factible.
Los resultados de la Revisión del Diseño de Alto Nivel deberá ser documentada en el reporte
correspondiente, donde se identificarán todas las deficiencias y se proveerá un plan y una agenda
para la acción correctiva, procediéndose de igual forma que con la Especificación de Requerimientos
en cuanto a la línea base.

Una lista de las propiedades a verificar del Diseño de Alto Nivel es la siguiente:

 Todos los Casos de Uso se identificaron y se priorizaron, identificándose los más relevantes.
 Las Interfaces funcionales con otros sistemas de software se definieron completamente.
 El diseño se ha realizado como un todo, definiéndose claramente la localización de los
componentes del software (capas, módulos, etc.), flujos de información y funcional,
requerimientos de almacenamiento y diseño de la base de datos.
 El diseño es verificable (por ejemplo, es posible construir un prototipo).
 Las interfaces máquina – humano son adecuadas y consistentes con el diseño.

Una consideración especial en la Revisión del Diseño de Alto Nivel es la Revisión de la Arquitectura,
debiéndose asegurar que se verifican las propiedades de Alta cohesión y Bajo Acoplamiento.
Entendiéndose por Alta Cohesión, que los módulos realicen una tarea específica y no estén
recargados con tareas que podrían hacer otros módulos. Por bajo acoplamiento se entiende que los
módulos se relacionen “lo necesario” con otros módulos.
Por último, es una buena práctica el tener como resultado de la Revisión de la Arquitectura una lista
con las fortalezas y debilidades de la misma.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 12 de 14
Proyecto de Ingeniería de Software . Plan de SQA

6.1.2 Revisión del Plan de Verificación y Validación.

Entradas:
 Plan de Verificación y Validación.
 Especificación de Requerimientos.

Esta Revisión se utiliza para evaluar la adecuación y completitud del Plan de Verificación y
Validación. Se debe asegurar que los métodos de Verificación y Validación del Plan son adecuados y
proveen una completa evaluación del producto. Los puntos a cubrir son:

 Todos los métodos de Verificación y Validación aseguran completitud y compatibilidad de

los Requerimientos funcionales y no funcionales especificados.
 Los reportes de Verificación y Validación documentan los resultados de las verificaciones
y validaciones de acuerdo al Plan de Verificación y Validación.
 La configuración del Software a ser testeado, como así también los elementos de
Software y Hardware de soporte están definidos y se adecúan a los Requerimientos.
 Las pruebas están diseñadas, definidas, son completas y son consistentes con los
Requerimientos.
 Los casos y procedimientos de prueba tienen instrucciones definidas, claras y concisas.
 La agenda del Plan de Verificación y Validación está definida, indicando que prueba se
hará a que, cuando y por que.

A lo largo del proceso de desarrollo se deberían realizar varias revisiones al Plan de Verificación y
Validación, dado que éste es un Plan que se incrementa a lo largo del proceso.

6.1.3 Revisión del Plan de SCM.

Entradas:
 Plan de SCM.

Esta Revisión se utiliza para evaluar la adecuación y completitud de los métodos definidos en el Plan
de SCM. Se debe evaluar el Plan de SCM una vez completo, debiéndose asegurar que los métodos
definidos provean el control necesario sobre la documentación y el código. Los puntos a cubrir son:

 El Plan de SCM define su propósito y alcance.

 Se provee una agenda, donde se identifican las actividades, responsabilidades de éstas y
las herramientas y recursos para llevarlas a cabo.
 Identificación completa de los Items de Configuración y los métodos utilizados para
definirlos.
 Descripción de los métodos para reportar problemas y cambios.

6.1.4 Revisión del Plan del Proyecto.

Entradas:
 Plan de Gestión del Proyecto.

Esta Revisión se utiliza para evaluar la adecuación y completitud del Plan del Proyecto. Los puntos a
cubrir son:

 Existe una descripción del proceso de desarrollo de SW a alto y bajo nivel.

 Existe una agenda de las actividades, incluyendo sus interrelaciones y dependencias.
 Se definen responsabilidades dentro de la organización y la comunicación entre las áreas
y sus integrantes.
 Se provee una identificación de los recursos disponibles (humanos, herramientas,
hardware, etc.).
 Descripción de los mecanismos de control de la gestión del proyecto.
 Las estimaciones realizadas para el producto y el proceso son realistas y se adecúan a
los recursos disponibles.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 13 de 14
Proyecto de Ingeniería de Software . Plan de SQA

 La identificación de riesgos se realizó teniendo en cuenta todas las áreas y se definieron

mecanismos para su control y actualización a lo largo del proyecto.

6.1.5 Diseño vs. Código, Diseño vs. Requerimientos y Testeo vs. Requerimientos

Estas revisiones se realizan sobre muestras estadísticas de los productos a revisar. El objetivo de
estas revisiones es asegurar la consistencia del producto a través del desarrollo. Los items
importantes a cubrir son:

 Las interfaces de Hardware y Software diseñadas son consistentes con los

Requerimientos y las implementadas son consistentes con el Diseño.
 Los requerimientos funcionales cubiertos por el Plan de Verificación y Validación son
completos de acuerdo a la Especificación de Requerimientos; los reportes de Verificación
y Validación son completos, cumplen con estándar y describen los resultados de las
pruebas realizadas.
 El diseño del producto (en la medida de su evolución) satisface los Requerimientos
funcionales.
 El código es consistente con el diseño y con el estándar de implementación.

Estas revisiones deben indicar en que medida el proceso de desarrollo está funcionando bien; se
deben documentar todas las discrepancias y errores encontrados en los planes y agendas y
comunicarlos para su corrección.

U n i v e r s i d a d de la R e p ú b l i c a – F a c u l t a d de I n g e n i e r í a – I n s t i t u t o de C o m p u t a c i ó n
Página 14 de 14