• Author / Uploaded
• Julie Roberts

• Categories
• Proceso de desarrollo de software
• Software
• Calidad (comercial)
• Medición
• Cognición

Citation preview

PLAN DE CALIDAD DE UN PROYECTO SOFTWARE INTRODUCCIÓN Esta práctica tiene como objetivo primordial: 1. La realización 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 informática“) 2. La ejecución de una de las tarcas planificadas. Para la realización de esta práctica 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 podéis considerar como productos intermedios todos los resultantes de dichas fases. • El Plan de Calidad se elabora, aunque no sea lo más habitual, cuando ya se han obtenido algunos de los productos intermedios del proyecto. • Una parte del Plan de Calidad, la correspondiente al Plan de Gestión de Configuración, ya ha sido elaborada como parte de la práctica 2. En esta práctica se piden tres tipos de trabajos a desarrollar: * Continuar con la obtención de más 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 (planificación, registro de tiempos) 1. SOBRE EL DESARROLLO DEL SISTEMA SOFTWARE Nueva versión del documento de ERS El documento realizado hasta este momento de “Especificación de Requisitos Software” es un documento Incompleto puesto que no contiene la especificación de aquellos requisitos de calidad. Por ello, antes de elaborar el Plan de Calidad es necesario obtener una nueva versión de dicho documento incluyendo la especificación de este tipo de requisitos.

1

Para ello, es posible seguir el mismo estándar IEEE Std. 830-1993 utilizado anteriormente, o utilizar un determinado modelo de calidad. Algunos de estos requisitos podrán ser extraídos del enunciado del caso Práctico (Enunciado Practica I) y otras pueden ser incorporados espontáneamente según 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 descripción de los flujos de datos. Este diagrama se realizará siguiendo la notación de la metodología Métrica 3 (ver documento de Técnicas). 2. PLAN DE CALIDAD Se debe utilizar como estándar de referencia el estándar IEEE Std, 730-1998. De los apartados que recoge dicho estándar se deben de proporcionar contenidos relacionados con las siguientes secciones: Políticas Un conjunto de políticas de Calidad propios de la organización que desarrolla el software. Esta información, aunque se pide en esta práctica, no forma parte del estándar que se sigue. Propósito y Alcance Objetivo, qué productos software van a estar cubiertos por este Plan, qué fases del ciclo de vida se van a aplicar. Gestión Una descripción 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 Debéis reunir la siguiente información mínima asociada a cada tarea: Entradas, salidas, descripción, plazo de realización expresado a partir de las condiciones cié comienzo y finalización de la tarea, recursos responsables. Documentación

2

Documentación del proyecto de la que se garantizará su calidad, los criterios de comprobación de cada uno de los productos, y qué técnicas se van a emplear para su comprobación. Revisiones y Auditorias Descripción 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 implementación 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 debéis adjuntar sus ficheros de modelos de proceso y de información Recomendaciones generales: • No es preciso elaborar secuencial mente el Plan de Calidad de acuerdo a relación de los puntos anteriores. Algunos de sus contenidos se pueden ir retinando iterativamente a medida que se progresa en el trabajo de esta práctica. • Una copia de la herramienta FORO puede ser obtenida a través de dos medios distintos: ftp://KpJLupm.es/piib/facultad/dcpartamentos/dlsiis/FORQ34Des214b_sp.zip en el servidor de la red del Centro de Cálculo: G:\dlsis\is\foro34Des214b__SP.zip • Se valorará positivamente que: El Plan de Calidad recoja más contenidos que los especificados, siempre y cuando se justifique su inclusión, de acuerdo a la descripción y planificación del proyecto considerado, El Plan de Calidad cubra una mayor parte del ciclo de vida del producto. Los procedimientos y tarcas y métodos propuestos guarden una coherencia con las políticas de calidad enumeradas. 3. EJECUCIÓN DE UNA TAREA DEL PLAN DE CALIDAD Una de las tareas que hayáis propuesto en vuestro Plan debe de aplicarse sobre el documento de ERS (última versión incluyendo los requisitos de calidad). Pero no sobre el documento elaborado por el propio equipo, sino el correspondiente al equipo del que hicisteis una evaluación en la práctica I. Para ello todos los equipos deben proporcionar al equipo que le corresponda la versión del ERS mencionada con al menos 10 días de antelación al plazo final de entrega del material de la práctica. Como resultado, el equipo revisor debe generar un informe en eL que se reúnan los resultados de la revisión efectuada. Si un equipo no dispone del material a revisar a tiempo

3

deberá comunicarlo urgentemente al profesor encargado de la materia por email 1’etovarjtt’fi.upm.es junto con la identificación del grupo que se lo debería haber proporcionado. 4. DOCUMENTACIÓN DEL TRABAJO DEL EQUIPO Al igual que en la práctica anterior se debe incorporar los documentos de Registro (formulario LOGT), y planes de actividades semanales, formatos B-12 y B-33 del libro “Gestión del Software”, respectivamente.

Estructura para las Métricas del Software

La medición asigna números o símbolos a atributos de entidades en el mundo real. Para conseguirlo se necesita un modelo de medición que comprenda un conjunto consistente de reglas. Existe la necesidad de medir y controlar la complejidad del software. Y si es difícil de obtener un solo valor de esta «métrica de calidad», si debería ser posible desarrollar medidas de diferentes atributos internos del programa (por ejemplo, modularidad efectiva, independencia funcional y otros atributos). Estas medidas y las métricas obtenidas de ellas pueden usarse como indicadores independientes de la calidad de los modelos de análisis y diseño. Los principios básicos de la medición, sugeridos por Roche, pueden caracterizarse mediante cinco actividades:     

Formulación. La obtención de medidas y métricas del software apropiadas para la representación del software en cuestión. Colección. El mecanismo empleado para acumular datos necesarios para obtener las métricas formuladas. Análisis. El cálculo de las métricas y la aplicación de herramientas matemáticas. Interpretación. La evaluación de los resultados de las métricas en un esfuerzo por conseguir una visión interna de la calidad de la representación. Realimentación (feedback). Recomendaciones obtenidas de la interpretación de métricas técnicas transmitidas al equipo que construye el software.

Los principios que se pueden asociar con la formulación de las métricas técnicas son los siguientes: Los objetivos de la medición deberían establecerse antes de empezar la recogida de datos. Todas las técnicas sobre métricas deberían definirse sin ambigüedades. 4

Las métricas deberían obtenerse basándose en una teoría válida para el dominio de aplicación (por ejemplo, las métricas para el diseño han de dibujarse sobre conceptos y principios básicos de diseño y deberían intentar proporcionar una indicación de la presencia de un atributo que se considera beneficioso). Hay que hacer las métricas a medida para acomodar mejor los productos y procesos específicos. Aunque la formulación es un punto de arranque crítico, la recogida y análisis son las actividades que dirigen el proceso de medición. Roche sugiere los siguientes principios para estas actividades:

-

-

Siempre que sea posible, la recogida de datos y el análisis debe automatizarse. Se deberían aplicar técnicas estadísticas válidas para establecer las relaciones entre los atributos internos del producto y las características externas de la calidad (por ejemplo, ¿está correlacionado el nivel de complejidad arquitectónico con el número de defectos descubiertos en la producción?). Se deberían establecer unas directrices de interpretación y recomendaciones para todas las métricas.

Ejiogu define un conjunto de atributos que deberían acompañar a las métricas efectivas del software. La métrica obtenida y las medidas que conducen a ello deberían ser: -

Simples y fáciles de calcular. Empírica e intuitivamente persuasiva. Consistente y objetiva. Consistente en el empleo de unidades y tamaños. Independiente del lenguaje de programación. Un eficaz mecanismo para la realimentación de calidad.

La experiencia indica que una métrica técnica se usa únicamente si es intuitivo y fácil de calcular. Si se requiere docenas de «cantadores» y se han de utilizar complejos cálculos, la métrica no será ampliamente utilizada.

5