K2BIM

Plan de Calidad
Versión 2.4

Historia de revisiones
Fecha VersiónDescripción Autor
04/10/2009 2.0 Modificaciones de Forma Completa al Documento Adrián Silveira
05/10/2009 2.1 Pequeñas correciones. Yasim Zeballos
10/10/2009 2.2 Ajuste del Plan. Adrián Silveira
18/10/2009 2.3 Se agrega punto 4.3 y se ajusta la agenda con los Adrián Silveira
productos de Investigación
23/10/2009 2.4 Agrego metrica documentacion y Ajuste del Plan Adrián Silveira
Contenido
1. Propósito ............................................................................................ 3
2. Referencias ......................................................................................... 3
3. Gestión ............................................................................................... 3
1. Organización...................................................................................... 3
1. Líneas de Trabajo ............................................................................ 3
2. Responsables de las líneas de trabajo ................................................. 5
2. Actividades ........................................................................................ 5
1. Ciclo de vida del software cubierto por el Plan ..................................... 5
2. Actividades de Calidad a Realizarse .................................................... 7
1. Revisar cada producto ................................................................... 7
2. Revisar el ajuste al proceso ............................................................ 8
3. Realizar Revisión Técnica Formal (RTF) ............................................ 8
4. Asegurar que las desviaciones son documentadas ............................. 8
3. Relaciones entre las actividades de SQA y la planificación...................... 9
3. Responsables ..................................................................................... 9
4. Atributos de Calidad............................................................................ 9
1. Requerimientos de Calidad del Producto de Software a Construir .............. 9
2. Documentacion ................................................................................. 11
1. Documentación mínima requerida .....................................................11
1. Especificación de requerimientos del software ..................................11
2. Descripción del diseño del software ................................................11
3. Plan de Verificación & Validación ....................................................12
4. Reportes de Verificación & Validación..............................................12
5. Plan de Gestión de configuración ....................................................12
2. Otros documentos .......................................................................... 12
1. Plan de Proyecto .......................................................................... 12
2. Plan de Desarrollo ........................................................................ 12
3. Pautas de Interfaz de Usuario ........................................................ 13
3. Calidad en los Productos de Investigación .............................................13
5. Estándares, prácticas, convenciones y métricas................................ 13
1. Estándar de documentación ................................................................ 13
2. Estándar de Implementación............................................................... 14
3. Estándar de verificación y prácticas......................................................14
4. Métricas a Utilizar .............................................................................. 14
1. Metricas de Adecuación al Estandar de Implementación .......................14
2. Metrica de Adecuación a Pautas de Interfaz de Usuario ........................16
3. Metrica del Cubrimiento de las Pruebas ..............................................16
4. Metrica del Desempeño de las Pruebas contra Version Anterior .............16
5. Metrica del Desempeño de las Pruebas en Version Actual .....................16
6. Revisiones y auditorías ..................................................................... 17
1. Objetivo ........................................................................................... 17
2. Revisiones ........................................................................................ 17
3. Auditorías......................................................................................... 18
4. Agenda ............................................................................................ 18
7. Verificación ....................................................................................... 21
8. Reporte de problemas y acciones correctivas.................................... 21
9. Herramientas, técnicas y metodologías............................................. 21
10. Gestión de riesgos ............................................................................ 21
11. Política de Calidad ............................................................................ 21
1. Propósito
El objetivo de este plan es definir la calidad del software deseado y describir como valorar
esta, estableciendo pautas y actividades que deben desarrollarse para garantizarla.
Identificaremos para cada actividad los atributos de calidad relevantes, los métodos de
evaluación y sus responsables.

Además, este plan brinda elementos de apoyo a la gestión del proyecto para realizar
verificaciones sobre la adecuación al proceso y así detectar desvios que puedan resultar en
acciones correctivas en etapas tempranas.
Este plan abarca las partes del ciclo de vida relacioneadas con: Inicial, Construcción de
Productos de Software, Construccion de Productos de Investigación y Presentación.
Las etapas relacionadas al mantenimiento no están contempladas debido a que no está
en el alcance del proyecto, sin embargo, se tomarán consideraciones acerca del futuro del
producto.

2. Referencias
[1] ANSI/IEEE Std 730.1-1989, IEEE Standard for Software Quality Assurance Plans.
[2] Documento "Estándar de Documentación Técnica"
[3] Documento "Estándar de Implementación"
[4] Documento "Plan de Verificación y Validación"
[5] Documento "Pautas de Interfaz de Usuario"

3. Gestión
La gestión del proyecto está a cargo del Administrador del Proyecto, sin embargo será
monitoreada tanto por este, como por el Responsable de SQA. Se intenta controlar que las
actividades se ajusten al plan propuesto y minimizar posibles desviaciones.

3.1 Organización

3.1.1 Líneas de Trabajo

A continuación identificaremos las distintas líneas de trabajo del proyecto y analizaremos los
distintos objetivos e interrelaciones de estas. De esta forma, comprenderemos las razones
que nos motivan a asegurar la calidad de las mismas e identificaremos sus principales
cometidos para así prestar atención en sus puntos claves.

Primeramente, debemos identificar las siguientes líneas de trabajo, que acompañan a todo el
ciclo de Vida del Proyecto:

• Gestión de Proyecto
 Su principal objetivo es proveer la planificacion del Proyecto, que incluye los objetivos y
mecanismos de interacción entre las distintas fases: Inicial, Construcción de Productos
de Software, Construccion de Productos de Investigación y Presentación. Además,
realiza estimaciones, mediciones y analiza la factibilidad del proyecto.
Es preciso destacar, que el éxito del proyecto depende en gran medida de una buena
Gestión, por lo que se debe prestar especial énfasis en la calidad de esta, destacando
un buen seguimiento del proyecto.

• Gestión de la Configuración y Control de Cambios

Su principal objetivo es identificar, definir y gestionar los elementos del proyecto que
deben estar bajo configuración. Es preciso hacer notar, que esta línea de trabajo resulta
de gran importancia para el desarrollo del proyecto, dado que debe asegurar que no
existan inconsitencias en el Sistema desarrollado, como por ejemplo, resultante de
conflicto de versiones, no notificación de cambios, así como de la realización de ciertos
cambios sin la consideración global de sus impactos.

Además, la línea de trabajo sobre la que está este plan es la Gestión de Calidad, que realiza
y controla la calidad del proceso y del Sistema en desarrollo, asegurando el cumplimiento de
las propiedades de calidad indentificadas en este plan.

A continuación, identificamos las principales líneas de trabajo que transcurren durante el ciclo
de vida natural del proyecto.

• Análisis de Requerimientos

Su principal objetivo es establecer y mantener un contrato con el Cliente que

especifique lo que debe hacer el Sistema a construir, además, define el alcance del
proyecto.
Proporciona mediante distintos productos (Especificación de Requerimientos, Modelo
de Casos de Uso, Alcance del Sistema de Software) la base para las demás disciplinas
según se ve a continuación.

• Diseño

Su principal objetivo es a partir de los requerimientos, diseñar lo que debe ser el

Sistema, definiendo de esta manera una Arquitectura para el mismo.

• Implementación

Su principal objetivo es implementar los distintos Subsistemas que luego se integran

para formar el Sistema. Además, efectúa la verificación unitaria de los componentes
desarrollados. Es relevante resaltar, que también proporciona prototipos para evaluar
riesgos técnicos y representar la arquitectura del Sistema.

• Verificación

Su principal objetivo es verificar la correcta interacción e integración de los

componentes del Sistema y verificar que todos los requerimientos definidos en el
Alcance del Sistema han sido correctamente implementados. Además, debe identificar,
 comunicar y asegurar que los defectos sean corregidos antes de la liberación final del
producto de software.

3.1.2 Responsables de las líneas de trabajo

El equipo de trabajo lo podemos observar en el documento "Plan de Proyecto", a continuación

identificamos los responsables según las distintas líneas de trabajo mencionadas en el punto
anterior:

Línea de Trabajo Responsables

Gestión de Proyecto Juan Saavedra
Gestión de la Configuración y Control de
Yasim Zeballos
Cambios
Análisis de Requerimientos Martín Llofriu
Diseño Guillermo Dotta
Implementación Guillermo Dotta, Martín Llofriou
Verificación Alan Descoins

3.2 Actividades

3.2.1 Ciclo de vida del software cubierto por el Plan

A continuación, identificamos los distintos productos de las etapas mencionadas en el punto

anterior los cuales estarán bajo revisiones de calidad.

Gestión del Proyecto

• Plan de Proyecto
• Informe de Situación de Proyecto
• Plan de iteración
• Documento de Riesgos
• Calendario de Entregas

Configuración y Control de Cambios

• Plan de Configuración
• Manejo del Ambiente Controlado
• Informe de la Línea Base del Proyecto
• Informe Final de Configuración

Requerimientos y Análisis

• Especificación de Requerimientos
• Especificación de Requerimientos de Investigación
• Modelos de Casos de Uso
• Alcance del Sistema
 • Alcance del Trabajo de Investigación
• Pautas para la interfaz del usuario
• Modelo de Dominio
• Glosario

Diseño

• Descripción de la Arquitectura

Implementación

• Estándar de Implementación
• Plan de Desarrollo
• Plan de Integración de la Iteración
• Informe de la Integración
• Notas de la Versión
• KBs desarrolladas.

Verificación

• Plan de Verificación y Validación

• Plan de Verificación de la Iteración
• Registro de Pruebas Unitarias
• Registro de Verificación/Reporte de Pruebas
• Modelo de Casos de Prueba

A continuación, ilustramos como los principales productos interactúan con las distintas
líneas de trabajo, para así entender la entrada y salida de productos de cada línea.
Observación: Las cápsulas con los límites punteados representan los productos. La dirección
y sentido de las flechas indican productos de entrada y salida.

3.2.2 Actividades de Calidad a Realizarse

Las tareas a ser llevadas a cabo deberán reflejar las evaluaciones a realizar, los estándares,
los productos a revisar, los procedimientos a seguir en la elaboración de los distintos
productos y los procedimientos para informar de los defectos detectados a sus responsables
y realizar el seguimiento de los mismos hasta su corrección.

Las actividades que se realizarán son:

• Revisar cada producto
• Revisar el ajuste al proceso
• Realizar Revisión Técnica Formal (RTF)
• Asegurar que las desviaciones son documentadas.

3.2.2.1 Revisar cada producto

En esta actividad se revisan los productos que se definieron como claves para verificar en el
Plan de calidad.
Se debe verificar que no queden correcciones sin resolver en los informes de revisión previos,
si se encuentra alguna no resuelta, debe ser incluida en la siguiente revisión. Se revisan los
productos contra los estándares.
Se debe identificar, documentar y seguir la pista a las desviaciones encontradas y verificar
que se hayan realizado las correcciones.
Como salida se obtiene el Informe de revisión de SQA, este informe debe ser distribuido a
los responsables del producto y se debe asegurar de que son concientes de desviaciones o
discrepancias encontradas.

3.2.2.2 Revisar el ajuste al proceso

En esta actividad se revisan los productos que se definieron como claves para verificar el
cumplimiento de las actividades definidas en el proceso. Con el fin de asegurar la calidad en
el producto final del desarrollo, se deben llevar a cabo revisiones sobre los productos durante
todo el ciclo de vida del software.
Se debe recoger la información necesaria de cada producto, buscando hacia atrás los
productos previos que deberían haberse generado, para poder establecer los criterios de
revisión y evaluar si el producto cumple con las especificaciones.
Esta información se obtiene de los siguientes documentos:
Plan del Proyecto, Plan de la iteración, Plan de Verificación.
Antes de comenzar, se debe verificar en los informes de revisión previos que todas las
desviaciones fueron corregidas, si no es así, las faltantes se incluyen para ser evaluadas.
Como salida se obtiene el Informe de revisión de SQA correspondiente a la evaluación de
ajuste al Proceso, este informe debe ser distribuido a los responsables de las actividades y
se debe asegurar de que son concientes de desviaciones o discrepancias encontradas.

3.2.2.3 Realizar Revisión Técnica Formal (RTF)

El objetivo de la RTF es descubrir errores en la función, la lógica ó la implementación de

cualquier producto del software, verificar que satisface sus especificaciones, que se ajusta a
los estándares establecidos, señalando las posibles desviaciones detectadas. Es un proceso
de revisión 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
característica se adopta esta práctica para productos que son de especial importancia.

En la reunión participan el responsable de SQA y los responsables del producto a analizar, no

excediendo de 5
Al convocar la reunión, se informará con antelación a los involucrados informando del
material que ellos deben preparar por adelantado, además se solicita lleven una lista de
preguntas y dudas que surgen del estudio del producto a ser revisado. La duración de la
reunión no debe ser mayor a dos horas.

El resultado de esta revisión se plasmará en un informe de RTF.

3.2.2.4 Asegurar que las desviaciones son documentadas

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.
3.2.3 Relaciones entre las actividades de SQA y la planificación

Es necesario destacar que el presente calendario se hace a partir de la Iteración 2 de la Fase

2, debido a las desviaciones sufridas por el abandono del anterior Responsable de SQA, como
se explica oportunamente en el documento "Informe de Situación - 20 de setiembre".

La relación entre las actividades de Calidad y el Plan de Gestión se describen a continuación.

Se hace notar que la agenda de revisiones está definida en el punto 6.4.

Actividad Semana cuando se realiza

Elaboración del Plan de Calidad 8y9
Evaluar y ajustar el plan de SQA 8,9,10 y 11
Evaluar la calidad de los entregables 8,9,10,11,12,13 y 14
Revisar el ajuste al proceso 8,9,10,11 y 12
Revisión Técnica Formal (RTF) 8,9, 10,11 y 12
Realizar el informe final de calidad 14

3.3 Responsables
Los responsables de llevar acabo los controles de calidad será el Responsable de SQA y el
Asistente de SQA.

Luego de las revisiones de cada producto, se solicitará la atención del responsable del mismo
para su corrección y comunicación de las acciones tomadas.

En el caso de las RTF, el grupo estará integrado por los responsables del producto a analizar,
como se especifia en el punto "3.2.2.3: RTF ". Luego de la revisión, el responsable de SQA
elabora un informe que incluya las acciones correctivas que deben ser tomadas, por los
responsables del producto revisado, para solucionar los problemas o desviaciones detectados
en la revisión.

Los responsables de cada producto para cada línea de trabajo se encuentran definidos en las
secciones "3.1.2 : Responsables de las líneas de Trabajo" y "3.2.1 : Ciclo de vida del software
cubierto por el Plan".

4. Atributos de Calidad
4.1 Requerimientos de Calidad del Producto de Software a
Construir
Los requerimientos de calidad del producto de software a construir son considerados dentro
de atributos específicos del software que tienen incidencia sobre la calidad en el uso y
se detallan a continuación. Cada uno de estos atributos debe cumplir con las normas y
regulaciones aplicables a cada uno.

Funcionalidad
Adecuación a las necesidades.
El producto a construír debe satisfacer las necesidades del cliente. Este aspecto debe darse
en todo el producto.

Interoperabilidad.
El sistema interoperará con otro sistema ya existente llamado K2B, por lo que debe utilizar
y proponer interfaces conocidas. En especial en la comunicación con la capa de servicios de
K2B.

Confiabilidad

Tolerancia a faltas.
El sistema debe responder de manera aceptable ante faltas en la programación. Este aspecto
debe ser considerado en todo el producto a construir.

Usabilidad
Desde el punto de vista de la Usabilidad, debemos tener en cuenta que el Producto a construir
no será puesto en producción sino que será tomado como prueba de concepto por los técnicos
de Artech.
Es por ello que se identifican los siguientes atributos:

• Comprensible
Desde el punto de vista interno nos ayudará a lograr otros aspectos de calidad como
la evolucionabilidad y verificabilidad. Además, se debe tener especial énfasis en la
Interfaz de Usuario, dado que esta debe cumplir con la interfaz estándar de K2B.

• Aprendible
Este atributo es uno de los fundamentales, dado que el objetivo de nuestro producto
es ser prueba de concepto, por lo que se debe procurar que el cliente sea capaz de
aprender y entedender la estructura interna del producto.

• Operable

Mantenibilidad
Este aspecto de calidad es fundamental dado que nuestro producto de software debe ser
capaz de que se le realizen modificaciones luego de su entrega para agregarle características
que no estaban dentro del alcance del proyecto (evolucionabilidad), ya que se espera que
Artech continue el desarrollo del mismo en su prueba de concepto.

Es por ello que se identifican los siguientes atributos dentro de este:

• Analizable
• Modificable
• Estable, no se producen efectos inesperados luego de modificaciones
• Verificable
• Evolucionabilidad

Estos aspectos deben ser cuidados en todo el producto, prestando especial atención al código
generado.
4.2 Documentacion
A continuación estableceremos la documentación necesaria para asegurar una buena calidad
en las distintas áreas del ciclo del proyecto, además de explicitar los criterios de las
revisiones.

4.2.1 Documentación mínima requerida

La documentación mínima es la requerida para asegurar que la implementación logrará

satisfacer los requerimientos.

4.2.1.1 Especificación de requerimientos del software

El documento de especificación de requerimientos deberá describir, de forma clara y precisa,

cada uno de los requerimientos esenciales del software además de las interfaces externas.
El cliente deberá obtener como resultado del proyecto una especificación adecuada a sus
necesidades en el área de alcance del proyecto, de acuerdo al compromiso inicial del trabajo
y a los cambios que este haya sufrido a lo largo del proyecto, que cubra aquellos aspectos
que se haya acordado detallar con el cliente.

La especificación debe:
• Ser completa:
a. Externa, respecto al alcance acordado.
b. Internamente, no deben existir elementos sin especificar.
• Ser consistente, no pueden haber elementos contradictorios.
• Ser no ambigua, todo término referido al área de aplicación debe estar definido en
un glosario.
• Ser verificable, debe ser posible verificar siguiendo un método definido, si el producto
final cumple o no con cada requerimiento.
• Estar acompañada de un detalle de los procedimientos adecuados para verificar si el
producto cumple o no con los requerimientos.
• Incluir requerimientos de calidad del producto a construir.

4.2.1.2 Descripción del diseño del software

El documento de diseño especifica como el software será construido para satisfacer los
requerimientos.
Deberá describir los componentes y subcomponentes del diseño del software, incluyendo
interfaces internas. Este documento deberá ser elaborado primero como Preliminar y luego
será gradualmente extendido hasta llegar a obtener el Detallado.

El cliente deberá obtener como resultado del proyecto el diseño de un producto de software
que cubra aquellos aspectos que se haya acordado con el cliente incorporar al diseño, en
función de la importancia que estos presenten y de sus conexiones lógicas.

El diseño debe:
• Corresponder a los requerimientos a incorporar:
a. Todo elemento del diseño debe contribuir a algún requerimiento
 b. La implementación de todo requerimiento a incorporar debe estar contemplada
en por lo menos un elemento del diseño.
• Ser consistente con la calidad del producto

4.2.1.3 Plan de Verificación & Validación

El Plan de V & V deberá identificar y describir los métodos a ser utilizados en

• La verificación de que:
a. los requerimientos descritos en el documento de requerimientos han sido
aprobados por una autoridad apropiada. En este caso sería 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 diseño expresado en el documento de diseño.
c. el diseño expresado en el documento de diseño esta implementado en código.
• Validar que el código, cuando es ejecutado, se adecua a los requerimientos
expresados en el documento de requerimientos.

4.2.1.4 Reportes de Verificación & Validación

Estos documentos deben especificar los resultados de la ejecución de los procesos descritos
en el Plan de V & V.

4.2.1.5 Plan de Gestión de configuración

El Plan de gestión de configuración debe contener métodos para identificar componentes

de software, control e implementación de cambios, y registro y reporte del estado de los
cambios implementados.

4.2.2 Otros documentos

4.2.2.1 Plan de Proyecto

El plan de gestión de proyecto debe describir la planificación de forma completa del proyecto,
de manera que pueda desarrollarse de forma controlada. Debe analizar su factibilidad, definir
el alcance, describir las actividades de gestión que deben ser llevadas a cabo durante el
proceso de desarrollo, definir mecanismos de control y ajuste para las distintas áreas del
proyecto, establecer las línea de trabajo, distribución de recursos humanos juntos con sus
responsabilidades y cronograma de trabajo. Además debe analizar los riesgos del proyecto
con estrategias de mitigación, controles y planes de contingencia.

4.2.2.2 Plan de Desarrollo

El plan de desarrollo debe describir la planificación de forma completa de la fase de desarrollo

del Sistema de Software, describiendo las actividades que se realizaran, su duración y
quienes son los responsables.
4.2.2.3 Pautas de Interfaz de Usuario

Este documento debe contener el relevamiento de las necesidades del cliente en cuanto a la
interfaz de Usuario. Debe cumplir los atributos de usabilidad y amigabilidad de acuerdo a las
pautas de interfaz que establezca K2B, dado la intención del Cliente es que el producto de
software se integre con K2B en un futuro.

4.3 Calidad en los Productos de Investigación

La Fase 3 del proyectos es de Construcción de Productos de Investigación cuyos objetivos se
pueden dividir en dos etapas:

1. Investigar sobre las siguientes líneas: Comparación de K2BIM con otros,

Relevamiento de Parametrización y Carga Masiva.
2. De llegar a resultados factibles de investigación en la etapa anterior, se procedería
implementarlos.

Como vimos, la etapa 1 se basa en investigación y el Cliente estableció que cualquier

resultado (se implemente o no) resultará de gran beneficio; por lo que se pondrá énfasis
en asegurar la calidad en el proceso de esta etapa, prestando especial atención que los
documentos generados cumplan los atributos de calidad de documentación definidos en el
presente plan.
El proceso será determinado por los documentos "Plan de Proyecto" y "Plan de Desarrollo e
Investigación". Además cada línea tiene su propio plan: "Plan de Investigación - Comparación
de K2BIM con otros", "Plan de Investigación - Relevamiento de Parametrización" y "Plan de
Investigación - Carga Masiva".
Se hace notar que asegurar la calidad en el proceso y de los documentos generados, se
complementa con el "Plan de Verificación y Validación de la Fase de Construcción" que
asegura que los resultados arrivados cumplan con los objetivos planteados en el plan de
investigación.

La etapa 2 es de construcción de software por lo que se regirá con los atributos de calidad
definidos en este plan anteriormente. Se observa claramente que la etapa 2, depende
fuertemente de los resultados obtenidos por la 1, inclusive, pueden alcanzarse resultados no
factibles de implementación para dicha etapa.

5. Estándares, prácticas, convenciones y

métricas
5.1 Estándar de documentación

Estándar de Documentos en General

Para la elaboración del documento se han definido plantillas para todos los documentos a
realizar. En ellos se definen:
 • Fuente: Verdana - Tamaño: 10 - Color: Negro - Estilos: Normal, Titulo1, Titulo2,
Titulo3, Titulo4 hasta el nivel que sea necesario.
• Cada documento debe contar con una carátula al principio que debe contener:
◦ Título explicativo del contenido del documento
◦ Versión del Documento
◦ Historial de versiones, que incluye el número de versón, la fecha, Asunto de
la modificación, Responsable que la realizó.
Se observa, que la versión del documento debe coincidir con el último campo de
esta tabla.
• índice del contenido del documento y por consiguiente todas las páginas
deben estar numeradas.
• Es deseable, que incluya al comienzo cual es el objetivo del documento.

Estándar de Documentación Técnica

Por documentación Técnica se entiende Modelo de Dominio, Diagrama de Casos de Uso,
Diagramas de Sistema en general. En el documento "Estándar de Documentación Técnica"
[2]
se define el programa de software a utilizar y algunas convenciones.

5.2 Estándar de Implementación

Como ya hemos mencionado, el producto de software a construir se utilizará como prueba de
concepto por parte del cliente, y es de gran importancia su mantenibilidad, comprensibilidad
, evolucionabilidad y aprendizaje. Es por ello, que debemos seguir las convenciones de
implementación que el Cliente utiliza, para lograr cumplir con estos atributos de calidad.

Otro factor de Calidad relevante, como ya mencionamos, es la interoperabilidad, por lo

que tal documento define las convenciones necesarias para realizar de forma correcta la
comunicacion con el Sistema K2B a través de Servicios.

Las convenciones de implementación se definen en el documento "Estándar de

[3]
Implementación"
y se solicita especial atención del mismo por parte del equipo de desarrolladores.

5.3 Estándar de verificación y prácticas

[4]
Se utilizaran las prácticas definidas en el documento "Plan de Verificación y Validación" .

5.4 Métricas a Utilizar

A continuación se definen las métricas a utilizar para medir el cumplimiento de los atributos
de calidad definidos en el punto 4.

5.4.1 Metricas de Adecuación al Estandar de Implementación

En las revisiones del código mediante las Revisiones Técnicas Formales se prestará especial
enfásis en el cumplimiento de los estandares de implementación definidos en "Estándar de
[3]
Implementación" . Se realizará exahustivamente un análisis de los items definidos en el
documento, tal como se describe en los puntos siguientes.

Se esperá que los siguientes indicadores se cumplan en un cien porciento, de lo contrario, se

solicitará acciones correctivas para alcanzar el nivel de satisfacción deseado.

Métrica de Adecuación a la Nomenclatura

Sea N la cantidad total de identificadores definidos en el desarrollo del Sistema y llamemos
C a la cantidad de identificadores que cumplen con los estándares definidos en el punto 1 del
documento.

Entonces,
Porcentaje de Adecuacion a la Nomenclatura = (C / N ) * 100.

Métrica de Adecuación a las Convenciones de los Servicios

Sea N la cantidad total de especificacion de servicios y llamemos C a la cantidad de
especificaciones que cumplen con los estándares definidos en el punto 2 del documento.

Entonces,
Porcentaje de Adecuación a la Convencion de los Servicios = (C / N ) * 100.

Métrica de Adecuación a Niveles de Transacciones

Sea N la cantidad total de transacciones y llamemos C a la cantidad de transacciones que
tienen a lo sumo dos niveles según especificado en el punto 3.1 en el documento.

Entonces,
Porcentaje de Adecuación a los Niveles de Transaccion = (C / N ) * 100.

Métrica de Adecuación a la Documentación

El objetivo de esta métrica es medir el grado de documentación de los objetos.

Se medirán la adecuación según los siguientes liniamientos:

• En la pestaña "Documentation" se debe indicar el cometido del objeto. Además,

explicar la semántica de las variables que así lo ameriten, atributos, etc. Aquí debe ir
toda la documentación adicional que ayude a entender al objeto.
• En "Rules" se deben comentar la semántica de las reglas. Por ejemplo, para la regla
parm se debe explicar sus parámetros. Se hace notar que no es necesario para
aquellas reglas donde su semántica es clara, por ejemplo, error, noaccept, etc.
• En el "Code" documentar el código, por ejemplo, la tabla que recorre el for each.

Por lo tanto definimos el porcentaje, que medirá la adecuación a la documentación de los

objetos que así lo ameriten.
5.4.2 Metrica de Adecuación a Pautas de Interfaz de Usuario

El documento de "Pautas de Interfaz de Usuario" define las políticas de interfaz a ser

utilizadas teniendo en cuenta los tipos de usuarios, el sistema K2B y el conjunto de patrones
K2BTools.

Se espera un cumplimiento del cien porciento de estas pautas, de lo contrario, se solicitarán

acciones correctivas para llegar al nivel de satisfacción deseado.

5.4.3 Metrica del Cubrimiento de las Pruebas

Se realizarán pruebas Unitarias y de Sistema por lo que este punto tiene el objetivo de
cuantificar la cantidad de pruebas realizadas sobre el total, lo cual nos sugiere una noción de
verificación del sistema.

Sea N la cantidad total de pruebas a desarrollar y llamemos C a la cantidad de pruebas

efectivamente realizadas.

Entonces,
Porcentaje de Cubrimiento de las Pruebas de Iteración = (C / N ) * 100

5.4.4 Metrica del Desempeño de las Pruebas contra Version Anterior

Este punto nos permitirá tener la noción de cuanto se han corregido los errores detectado en
las pruebas de una versión anterior.

Sea N la cantidad total de errores detectados en la versión X del Sistema y llamemos C a la

cantidad de errores arreglados en la versión X+1 del Sistema.
Entonces,
Porcentaje del Desempeño de las Pruebas contra Version Anterior = (C / N ) * 100

5.4.5 Metrica del Desempeño de las Pruebas en Version Actual

Este punto nos permitirá tener la noción de cuan correcto es el Sistema que se está
construyendo.

Sea N la cantidad total de pruebas efectuadas y C la cantidad total de pruebas realizadas con
resultado de exito.
Entonces,
Porcentaje del Desempeño de las Pruebas de Version Actual = (C / N ) * 100
6. Revisiones y auditorías
6.1 Objetivo
A continuación se definen las revisiones y auditorías técnicas y de gestión que se realizaran,
especificando como se llevaran a cabo.

6.2 Revisiones
La salida de cada revisión será el "Informe de Revisión" sobre cada producto. Estas revisiones
serán llevadas a cabo tanto por el Responsable de SQA como por el Asistente de SQA y según
las técnicas explicitadas en el punto 3.2.2.

Revisión de requerimientos
Esta revisión se realiza para asegurar que se cumplió con los requerimientos especificados
por el Cliente.

Revisión de diseño crítico

Esta revisión se realiza para asegurar la consistencia del diseño detallado con la
especificación de requerimientos.

Revisión del Plan de Verificación & Validación

Esta revisión se realiza para asegurar la consistencia y completitud de los métodos
especificados en el Plan de V & V.

Revisiones de gestión
Estas revisiones se realizan periódicamente para asegurar la ejecución de todas las
actividades identificadas en este Plan. La revisión se hará cada fin de iteración por el
Responsable de SQA.

Revisión del Plan de gestión de configuración

Esta revisión se realiza para asegurar la consistencia y completitud de los métodos
especificados en el Plan de gestión de configuración.

Revisión del Código Generado mediante RTF

Esta revisión tendrá por objetivo revisar el código generado para verificar el cumplimiento
de los Estándares de Implementación definidos en [3]. Estas revisiones se llevaran a cabo
mediante la metodología de Revisión Técnica Formal según las pautas que se definen en
3.2.2.3.

Revisión del Cubrimiento de Pruebas mediante RTF

Esta revisión tendrá por objetivo estudiar el cubrimiento de las pruebas realizadas para así
obtener de esa manera una noción de prueba del Sistema. La métrica se explica en 5.4.2.
Revisión del Desempeño de las Pruebas mediante RTF
Esta revisión tendrá por objetivo estudiar el desempeño de las pruebas realizadas para así
obtener de esa manera una noción de la correctitud del Sistema en base a los errores
detectados en las pruebas de una versión anterior. La métrica se explica en 5.4.3.

Revisión Post Mortem

Esta revisión se realiza al concluir el proyecto para especificar las actividades de desarrollo
implementadas durante el proyecto y para proveer recomendaciones.

6.3 Auditorías
Auditoría funcional
Esta auditoría se realiza previa a la liberación del software, para verificar que todos los
requerimientos especificados en el documento de requerimientos fueron cumplidos. Esta
Auditoría la realizará un equipo integrado por el Responsable de SQA, Responsable de
Verificación, Arquitecto, Analista y un Implementador.

Auditorías internas al proceso

Estas auditorías son para verificar la consistencia: del código versus el documento de diseño,
especificaciones de interfase, implementaciones de diseño versus requerimientos funcionales,
requerimientos funcionales versus descripciones de testeo.

6.4 Agenda
Es necesario destacar que el presente calendario se hace a partir de la Iteración 2 Fase 2,
debido a las desviaciones sufridas por el abandono del anterior Responsable de SQA, como
se explica oportunamente en el documento "Informe de Situación - 20/09".

Anteriormente, la actividad de calidad formal era casi nula, limitandose a comunicaciones y

seguimientos informales de los errores encontrados en los productos. De todas formas, se
obtuvo una noción general de una buena calidad en ese proceso.

Al confeccionar el siguiente calendario, se seleccionaron para la Fase 2 - Iteracion 2 -

Semanas 8 y 9 aquellos productos de especial importancia para todas las líneas de trabajo,
de forma tal, de tener un informe de situación actual de la calidad del proyecto y poder
estimar un calendario en base a esta situación.

El calendario está sujeto a cambios que puedan originarse por desviaciones en el proyecto
como se explicitó anteriormente. Además, se observa que para la fase de construcción de
productos de investigación todavía no está determinado, dado que aún no se determinó el
mecanismo que se seguirá durante la investigación.

Fase Iteración Semana Actividad Producto

2 2 8 RTF Arquitectura
Revisión Producto Plan de Proyecto
Descripción de la
Revisión Producto
Arquitectura
Plan de
Revisión Producto
Configuración
Elaboración del
Plan de Calidad
Plan de Calidad
Manejo del
Revisión Producto Ambiente
Controlado
Servicios
9 RTF
Avanzados
K2BIM (+ Pautas
RTF de Interfaz de
Usuario )
Salida: Informe
de Revisión de
Revisión de
Pruebas (métricas
Pruebas
de cubrimiento,
desempeño, etc)
Evaluar y Ajustar
Plan de Calidad
el Plan de Calidad

Descripción de la
3 1 10 Revisión Producto
Arquitectura
Plan de
Revisión Producto
Configuración
Manejo del
Revisión Producto Ambiente
Controlado
Salida: Informe
de Revisión de
Revisión de
Pruebas (métricas
Pruebas
de cubrimiento,
desempeño, etc)
Salida: Informe
de Revisión de
Revisión de
11 Pruebas
Pruebas (métricas
de cubrimiento,
desempeño, etc)
Servicios
RTF
Avanzados
 Comparacion
Revisión de
K2BIM con otras
Proceso
ERP
Revisión de
Carga Masiva
Proceso
Revisión de Relevamiento de
Proceso Parametrizacion
Revision Lineas de
Productos Investigación
K2BIM (+ Pautas
RTF de Interfaz de
Usuario )
Revision Lineas de
2 12 Productos Investigacion
Salida: Informe
de Revisión de
Revisión de
Pruebas (métricas
Pruebas
de cubrimiento,
desempeño, etc)
Comparacion
Revisión de
K2BIM con otras
Proceso
ERP
Revisión de
Carga Masiva
Proceso
Revisión de Relevamiento de
Proceso Parametrizacion
Modelo de Casos
Revisión Producto
de Uso
K2BIM +
Auditoria Servicios
13
Funcional Avanzados +
PlugIns
Comparacion
Revisión de
K2BIM con otras
Proceso
ERP
Revisión de
Carga Masiva
Proceso
Revisión de Relevamiento de
Proceso Parametrizacion
Revisión Lineas de
Productos Investigación

Revision
4 1 14 PostMortem
7. Verificación
La verificación se hará conforme a lo expresado en el documento "Plan de Verificación y
Validación", sin embargo, este punto puede surguir modificaciones luego de las revisiones
agendadas para la próxima semana.

8. Reporte de problemas y acciones

correctivas
Luego de tener el Informe de la Revisión se solicitará, mediante el envío de un mail, la
atención de los responsables sobre el documento. Además, se les solicitará que comuniquen
las discrepancias encontradas en el informe tanto como las correcciones hechas en el
producto. Luego, se planifica una nueva revisión para corroborar las acciones correctivas
hechas por los responsables del producto.

9. Herramientas, técnicas y metodologías

Las técnicas a utilizar se definieron en el punto 3, además se utilizará listas de comprobación
como apoyo a estas técnicas. Dichas listas se realizaran para cada revisión y se tomaran
como base las definidas en el curso.

10. Gestión de riesgos

Los riesgos identificados, la estrategia de mitigación, monitoreo y plan de contingencia a ser
llevados a cabo, están definidos en el documento de "Gestión de Riesgos".

11. Política de Calidad

Consideraremos que el producto está en un nivel aceptable de calidad si se cumplen el cien

por ciento de los atributos de calidad identificados en el punto "4 : Atributos de Calidad".
Utilizaremos las métricas definidas en el punto "5: Estándares, prácticas, convenciones y
métricas" de forma tal de medir dichos atributos, para así tener una noción general de calidad
del producto y consecuentemente solicitar las acciones correctivas que sean necesarias.
Este proceso se llevará a cabo con las revisiones y auditorias definidas en el punto "7 :
Revisiones y auditorias" según el cronograma definido en "7.4 : Agenda".