CAPITULO 23 y 25
EL PROCESO DE SOFTWARE Y METRICAS DEL PROYECTO
Métricas del software: Son medidas para el software de computadora. La medición se puede aplicar: - al proceso (para mejorarlo)
- en el proyecto (para ayudar en la estimación, control de calidad etc).
- El ingeniero del software (para evaluar calidad de productos/ para ayudar en la toma de decisiones)
4.1 MEDIDAS, METRICAS E INDICADORES
Medida: indicación cuantitativa de extensión cantidad, dimensiones, capacidad y tamaño de algunos atributos de un proceso o producto.
Medición: es el acto de determinar una medida.
Metrica: medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado. Indicador: se obtiene de la recopilación de medidas y desarrollo de métricas. Proporciona: visión profunda del proceso de soft, del proyecto de soft y del producto del soft
Las métricas permiten al gestor del proyecto y/o ing. soft la toma de decisiones más fundamentadas.
4.2 METRICAS EN EL PROCESO Y DOMINIOS DEL PROYECTO
Indicadores del proceso: Permite:
- Visión de la eficiencia de un proceso ya existente. - Evaluar lo que funciona y lo que no.
- Las métricas de recopilan de todos los proyectos un largo tiempo.
Indicadores del proyecto: Permite: - Evaluar el estado del proyecto
- Seguir la pista de los riegos potenciales
- Detectar àreas de problemas antes de que se conviertan en criticas - Ajustar flujo y tareas del trabajo
- Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos.
METRICAS DEL PROCESO
La eficiencia de un proceso de soft se mide indirectamente. Se extrae un juego de métricas según los resultados que provienen del proceso. Entre los resultados se incluyen:
- Errores detectados antes de la entrega del soft.
- Defectos detectados e informados por los usuarios finales. - Productos de trabajo entregado
- Esfuerzo humano y tiempo consumido - Ajuste con la planificación
- Características de tareas específicas de la ing del software. Para diferentes tipos de datos de proceso existen métricas de:
Uso privado: entre los ejemplos de métricas que son privadas del individuo se incluyen: - indices de defectos
- índices de defectos por módulos
- errores encontrados durante el desarrollo
Uso público: algunas métricas del proceso son privadas para el equipo del proyecto, pero son públicas para todos los miembros del equipo. Entre los ejemplos se incluyen:
- errores encontrados durante revisiones técnicas formales y líneas de código o puntos de función por módulo y función
A medida que una organización está más a gusto con la recopilación y utiliza métricas de proceso, la derivación de indicadores simples abre el camino hacia un enfoque más riguroso, llamado mejora estadística del proceso del software MEPS. MEPS utiliza: análisis de fallos del software para recopilar información de errores y defectos encontrados al desarrollar y utilizar una aplicación de sistema o producto.
El análisis de fallos funciona de la siguiente manera: 1) todos los errores y defectos se categorizan por origen
2) se registra tanto el coste de corregir cada error como el defecto.
3) El número de errores y de defectos de cada categoría se cuentan y se ordenen en orden descendente. 4) Se computa el coste global de errores y defectos de cada categoría.
5) Los datos resultantes se analizan para detectar las categorías que producen el costo más alto para la organización.
6) Se desarrollan planes para modificar el proceso con el intento de eliminar la clase de errores y defectos que sean más costosos.
La colección de métricas del proceso es el conductor para la creación del diagrama en espina completo desde el cual se puede analizar para extraer los indicadores que permitan a una organización modificar su proceso para reducir la frecuencia de errores y defectos.
METRICAS DEL PROYECTO
- Se deben recopilar métricas de proyectos anteriores que se utilizan como base para estimaciones (medidas de esfuerzo y tiempo).
- Se miden índices de producción. - Se miden horas de revisión - Los puntos de función - Líneas fuentes entregadas.
- Se sigue la pista de los errores detectados
- Se recopilan las métricas técnicas para evaluar la calidad del diseño.
El uso de métricas para el proyecto tiene dos aspectos fundamentales: - Minimizar la planificación de desarrollo
- Evaluar la calidad de los productos en el momento actual
Otro modelo de métricas sugiere que todos los proyectos deberían medir:
- Entradas: la dimensión de los recursos (personas, entorno) que se requieren para realizar el trabajo - Salidas: medidas de las entregas o productos creados durante el proceso de ingeniería del soft. - Resultados: medidas que indican la efectividad de las entregas.
Este modelo se puede aplicar tanto al proceso como al proyecto. Las salidas de una actividad se convierten en las entradas de las siguientes.
- proceso - proyecto
- producto
METRICAS ORIENTADAS AL TAMAÑO
- Provienen de la normalización de las medidas de calidad y/o tamaño productividad considerando el “tamaño” del software que se haya producido.
- Si una organización de soft mantiene registros sencillos, se puede crear una tabla de datos orientados al tamaño. La tabla lista cada proyecto de desarrollo de soft de últimos años y las medidas correspondientes de cada proyecto.
- Se seleccionan líneas de código como valor de normalización (LDC)
Métricas simples orientadas al tamaño:
- errores por KLDC (miles de líneas de código, KiloLDC) - defectos por KLDC
- $ por LDC
- páginas de documentación por KLDC - errores/persona-mes
- LDC por persona-mes - $/página dedocumentación.
METRICAS ORIENTADAS A LA FUNCION
Utilizan una medida de la funcionalidad entregada por la aplicación como valor de normalización. Ya que la funcionalidad no se puede medir directamente, se debe derivar indirectamente mediante otras medidas directas.
Punto de función: se derivan con una relación empírica según las medidas contables (directas) del dominio de información del soft y las evaluaciones de la complejidad del soft. Para aplicaciones de sist de inf de gestión. Se determinan cinco (5) características de dominios de información. Los valores de dominios se definen de la forma siguiente:
- número de entradas de usuario - número de salidas de usuario - número de peticiones de usuario - números de archivos
- número de interfaces externas.
Una vez que se han recopilado los datos, a la cuenta se asocia un valor de complejidad. Las organizaciones que utilizan métodos de punto de función desarrollan criterios para determinar si una entrada en particular es simple, media o compleja.
Para calcular puntos de función (PF) se utilizan la siguiente relación:
METRICAS AMPLIADA DE PUNTO DE FUNCION
Para remediar la medida del punto de función que era inadecuada para muchos sistemas de ingeniería y sistemas empotrados (que enfatizan función y control) se proponen un número de extensiones básicas a la métrica del punto de función básica:
- Punto de característica: se acomoda a aplicaciones dónde la complejidad del algorítmo es alta (soft de tiempo real, control de procesos etc).
Algoritmo: problema de cálculo limitado que se incluye dentro de un programa de computadora específico. - Punto de función 3d: adecuada para aplicaciones que enfatizan capacidades de función y control: sistemas
en tiempo real y productos de ingeniería.
Dimensión de datos: las cuentas de datos internos y los datos externos se utilizan a lo largo de las medidas de complejidad para derivar una cuenta de dimensión de datos.
Dimensión funcional: Se mide considerando el número de operaciones internas requeridas para transformar datos de entrada en datos de salida.
Dimensión de control: se mide contando el número de transiciones entre estados. Un estado presenta algún modo de comportamiento externamente observable y una transición ocurre como resultado de algún suceso que cambia el modo de comportamiento del sistema o del soft.
4.4 RECONCILIACION DE LOS DIFERENTES ENFOQUES DE METRICAS
La relación entre las líneas de código y los puntos de función depende del lenguaje de programación que se utilice para implementar el software y la calidad del diseño.
LDC y PF: se utilizan para extrae métricas de productividad. Cinco factores que inciden en la productividad:
- Factores humanos: El tamaño y la experiencia de la organización en desarrollo.
- Factores del problema: la complejidad del problema que se debe resolver y el número de cambios en las restricciones o los requisitos del diseño.
- Factores del proceso: técnicas de análisis y diseño que se utilizan, lenguajes y herramientas CASE. - Factores del producto: fiabilidad y diseño del sistema basado en computadora.
- Factores del recurso: disponibilidad de herramientas CASE, y recursos de hardware y software.
4.5 METRICAS PARA LA CALIDAD DEL SOFTWARE
El objetivo primordial de la ingeniería del software es producir un sistema, aplicación o producto de alta calidad
VISION GENERAL DE LOS FACTORES QUE AFECTAN A LA CALIDAD.
Los factores de calidad evalúan al software desde tres puntos de vista distintos: 1) operación del producto (utilizándolo)
2) revisión del producto (cambiándolo)
1. Habilidad intelectual y/o física requerida para aprender el sistema.
2. El tiempo requerido para llegar a ser moderadamente eficiente en el uso del sistema. 3. Aumento neto en productividad medida cuando alguien usa el sistema moderadamente y
eficientemente.
4. Valoración subjetiva de la disposición de los usuarios hacia el sistema.
- Integridad: éste atributo mida la habilidad de un sistema para resistir ataques contra su seguridad. Para medir la integridad, se tienen que definir 2 atributos adicionales: amenaza es la probabilidad de que un ataque de un tipo determinado ocurra en un tiempo determinado. La seguridad es la probabilidad de que se pueda repeler el ataque de un tipo determinado.
EFICACIA DE LA ELIMINACION DE DEFECTOS
Una métrica de la calidad que proporciona beneficios tanto a nivel del proyecto como del proceso, es la eficacia de la eliminación de defectos (EDD). En esencia EED es una medida de la habilidad de filtrar las actividades de la garantía de calidad y de control al aplicarse a todas las actividades del marco de trabajo del proceso. Cuando se toma en consideración globalmente para un proyecto, EED se define de la siguiente forma:
E= numero de errores encontrados antes de la entrega del soft al usuario final. D= numero de defectos encontrados después de la entrega.
El valor ideal de EED es 1, esto es, no se han encontrado defectos en el soft.
EED también se puede usar dentro del proyecto para evaluar la habilidad de un equipo en encontrar errores antes de que pasen a la siguiente actividad estructural o tarea de ingeniería del soft.
