PLAN DE CALIDAD DE UN PROYECTO SOFTWARE

INTRODUCCIN
Esta prctica tiene como objetivo primordial:
1. La realizacin de un Plan de Calidad asociado a] desarrollo del software que se est
desarrollando parcialmente desde el comienzo de este curso (Sistema de Reserva del Hotel
Facultad de informtica)
2. La ejecucin de una de las tarcas planificadas.
Para la realizacin de esta prctica se deben considerar los siguientes supuestos:
Se ha elegido previamente el modelo de ciclo de vida en cascada el aplicado al desarrollo de
ese software, y por lo tanto podis considerar como productos intermedios todos los resultantes
de dichas fases.
El Plan de Calidad se elabora, aunque no sea lo ms habitual, cuando ya se han obtenido
algunos de los productos intermedios del proyecto.
Una parte del Plan de Calidad, la correspondiente al Plan de Gestin de Configuracin, ya ha
sido elaborada como parte de la prctica 2.
En esta prctica se piden tres tipos de trabajos a desarrollar:
* Continuar con la obtencin de ms productos en el desarrollo del sistema Software F-laborar
un Plan de Calidad
* Ejecutar una de las tareas contenidas en el Plan de Calidad propuestos Documentar todo el
Trabajo realizado (planificacin, registro de tiempos)
1. SOBRE EL DESARROLLO DEL SISTEMA SOFTWARE
Nueva versin del documento de ERS
El documento realizado hasta este momento de Especificacin de Requisitos Software es un
documento Incompleto puesto que no contiene la especificacin de aquellos requisitos de
calidad. Por ello, antes de elaborar el Plan de Calidad es necesario obtener una nueva versin de
dicho documento incluyendo la especificacin de este tipo de requisitos.

Para ello, es posible seguir el mismo estndar IEEE Std. 830-1993 utilizado anteriormente, o
utilizar un determinado modelo de calidad. Algunos de estos requisitos podrn ser extrados del
enunciado del caso
Prctico (Enunciado Practica I) y otras pueden ser incorporados espontneamente segn criterios
del equipo de desarrollo.
Diagrama de Flujo de Primer nivel
El Diagrama de Flujo de Primer Nivel correspondiente al refinamiento del Diagrama de Contexto
ya elaborado, adjuntando la descripcin de los flujos de datos. Este diagrama se realizar
siguiendo la notacin de la metodologa Mtrica 3 (ver documento de Tcnicas).
2. PLAN DE CALIDAD
Se debe utilizar como estndar de referencia el estndar IEEE Std, 730-1998. De los apartados
que recoge dicho estndar se deben de proporcionar contenidos relacionados con las siguientes
secciones:
Polticas
Un conjunto de polticas de Calidad propios de la organizacin que desarrolla el software. Esta
informacin, aunque se pide en esta prctica, no forma parte del estndar que se sigue.
Propsito y Alcance
Objetivo, qu productos software van a estar cubiertos por este Plan, qu fases del ciclo de vida
se van a aplicar.
Gestin
Una descripcin de la estructura organizativa del equipo de personas que van a implementar las
tareas de Calidad, especificando las relaciones existentes con el equipo desarrollador, roles y
responsabilidades
Plan de tareas de calidad
Debis reunir la siguiente informacin mnima asociada a cada tarea:
Entradas, salidas, descripcin, plazo de realizacin expresado a partir de las condiciones ci
comienzo y finalizacin de la tarea, recursos responsables.
Documentacin

Documentacin del proyecto de la que se garantizar su calidad, los criterios de comprobacin

de cada uno de los productos, y qu tcnicas se van a emplear para su comprobacin.
Revisiones y Auditorias Descripcin de qu tipos de revisiones y auditorias se van a proponer
Procesos para llevar a cabo los puntos recogidos en este Plan, como las revisiones y auditoria1,,
el informe de problemas detectados, las revisiones, la implementacin de acciones correctivas en
este plan. Necesidades de entrenamiento o el registro de documentos. Hay que identificar y
describir brevemente cada uno de los procedimientos identificados y describir al menos uno de
ellos utilizando la herramienta de workflow FORO. Para este procedimiento debis adjuntar sus
ficheros de modelos de proceso y de informacin
Recomendaciones generales:
No es preciso elaborar secuencial mente el Plan de Calidad de acuerdo a relacin de los puntos
anteriores. Algunos de sus contenidos se pueden ir retinando iterativamente a medida que se
progresa en el trabajo de esta prctica.
Una copia de la herramienta FORO puede ser obtenida a travs de dos medios distintos:
ftp://KpJLupm.es/piib/facultad/dcpartamentos/dlsiis/FORQ34Des214b_sp.zip en el servidor de la
red del Centro de Clculo: G:\dlsis\is\foro34Des214b__SP.zip
Se valorar positivamente que:
El Plan de Calidad recoja ms contenidos que los especificados, siempre y cuando se justifique
su inclusin, de acuerdo a la descripcin y planificacin del proyecto considerado,
El Plan de Calidad cubra una mayor parte del ciclo de vida del producto.
Los procedimientos y tarcas y mtodos propuestos guarden una coherencia con las polticas de
calidad enumeradas.
3. EJECUCIN DE UNA TAREA DEL PLAN DE CALIDAD
Una de las tareas que hayis propuesto en vuestro Plan debe de aplicarse sobre el documento de
ERS (ltima versin incluyendo los requisitos de calidad). Pero no sobre el documento elaborado
por el propio equipo, sino el correspondiente al equipo del que hicisteis una evaluacin en la
prctica I. Para ello todos los equipos deben proporcionar al equipo que le corresponda la versin
del ERS mencionada con al menos 10 das de antelacin al plazo final de entrega del material de
la prctica. Como resultado, el equipo revisor debe generar un informe en eL que se renan los
resultados de la revisin efectuada. Si un equipo no dispone del material a revisar a tiempo

deber comunicarlo urgentemente al profesor encargado de la materia por email

1etovarjttfi.upm.es junto con la identificacin del grupo que se lo debera haber proporcionado.
4. DOCUMENTACIN DEL TRABAJO DEL EQUIPO
Al igual que en la prctica anterior se debe incorporar los documentos de Registro (formulario
LOGT), y planes de actividades semanales, formatos B-12 y B-33 del libro Gestin del
Software, respectivamente.

Estructura para las Mtricas del Software

La medicin asigna nmeros o smbolos a atributos de entidades en el mundo

real. Para conseguirlo se necesita un modelo de medicin que comprenda un
conjunto consistente de reglas.
Existe la necesidad de medir y controlar la complejidad del software. Y si es
difcil de obtener un solo valor de esta mtrica de calidad, si debera ser
posible desarrollar medidas de diferentes atributos internos del programa (por
ejemplo, modularidad efectiva, independencia funcional y otros atributos).
Estas medidas y las mtricas obtenidas de ellas pueden usarse como
indicadores independientes de la calidad de los modelos de anlisis y diseo.
Los principios bsicos de la medicin, sugeridos por Roche, pueden
caracterizarse mediante cinco actividades:

Formulacin. La obtencin de medidas y mtricas del software

apropiadas para la representacin del software en cuestin.
Coleccin. El mecanismo empleado para acumular datos necesarios
para obtener las mtricas formuladas.
Anlisis. El clculo de las mtricas y la aplicacin de herramientas
matemticas.
Interpretacin. La evaluacin de los resultados de las mtricas en un
esfuerzo por conseguir una visin interna de la calidad de la
representacin.
Realimentacin (feedback). Recomendaciones obtenidas de la
interpretacin de mtricas tcnicas transmitidas al equipo que construye
el software.

Los principios que se pueden asociar con la formulacin de las mtricas

tcnicas son los siguientes:
Los objetivos de la medicin deberan establecerse antes de empezar la
recogida de datos.
Todas las tcnicas sobre mtricas deberan definirse sin ambigedades.
4

Las mtricas deberan obtenerse basndose en una teora vlida para el

dominio de aplicacin (por ejemplo, las mtricas para el diseo han de
dibujarse sobre conceptos y principios bsicos de diseo y deberan intentar
proporcionar una indicacin de la presencia de un atributo que se considera
beneficioso).
Hay que hacer las mtricas a medida para acomodar mejor los productos y
procesos especficos.
Aunque la formulacin es un punto de arranque crtico, la recogida y anlisis
son las actividades que dirigen el proceso de medicin. Roche sugiere los
siguientes principios para estas actividades:

Siempre que sea posible, la recogida de datos y el anlisis debe

automatizarse.
Se deberan aplicar tcnicas estadsticas vlidas para establecer las
relaciones entre los atributos internos del producto y las caractersticas
externas de la calidad (por ejemplo, est correlacionado el nivel de
complejidad arquitectnico con el nmero de defectos descubiertos en la
produccin?).
Se deberan establecer unas directrices de interpretacin y
recomendaciones para todas las mtricas.

Ejiogu define un conjunto de atributos que deberan acompaar a las mtricas

efectivas del software.
La mtrica obtenida y las medidas que conducen a ello deberan ser:
-

Simples y fciles de calcular.

Emprica e intuitivamente persuasiva.
Consistente y objetiva.
Consistente en el empleo de unidades y tamaos.
Independiente del lenguaje de programacin.
Un eficaz mecanismo para la realimentacin de calidad.

La experiencia indica que una mtrica tcnica se usa nicamente si es intuitivo

y fcil de calcular. Si se requiere docenas de cantadores y se han de utilizar
complejos clculos, la mtrica no ser ampliamente utilizada.