El proceso del Software y Métricas del proyecto

Presentación del tema: "El proceso del Software y Métricas del proyecto"— Transcripción de la presentación:

1 El proceso del Software y Métricas del proyecto
Ingeniería del Software Lic. Marisa Gouget UCSA IS - Lic. Marisa Gouget

2 Métricas La medición es fundamental para cualquier disciplina de la ingeniería. Se puede aplicar al proceso de software para mejorar sobre una base continua. Existe preocupación por métricas de calidad y de productividad, medidas de “utilidad” del producto obtenido y medidas “de salida” del desarrollo basadas en el esfuerzo y tiempo utilizados. IS - Lic. Marisa Gouget

3 Medidas, métricas e indicadores
Métrica: “una medida cuantitativa del grado en que un sistema, componente o proceso posee un atributo dado”. IEEE93 Medida: recopilación de un aspecto de los datos, por ejemplo número de errores encontrados en una revisión. Indicador: métrica o conjunto de métricas que el Ingeniero de Software recopila para obtener una visión del proceso de software. IS - Lic. Marisa Gouget

4 Medidas, métricas e indicadores
Proceso de ingeniería del software Medidas Proyecto del software Recopilación se datos Métricas Producto del software Cálculo de métricas Indicadores Evaluación de métricas IS - Lic. Marisa Gouget

5 Ingeniería del Software
Métricas del proceso Ingeniería del Software IS - Lic. Marisa Gouget

6 Métricas del proceso Determinantes de la calidad del software y de la efectividad de la organización
Producto Personas Tecnología Características del cliente Condiciones del negocio Entorno de desarrollo IS - Lic. Marisa Gouget

7 Métricas del proceso Determinantes de la calidad del software y de la efectividad de la organización
Utilizar el sentido común y sensibilidad organizativa al interpretar datos de métricas. Proporcionar una realimentación a particulares y equipos que han trabajado en la recopilación de medidas y métricas. No utilizar métricas para evaluar a individuos. No considerar como “negativos” a los datos de las métricas de un área de problemas, es para mejorar. No obsesionarse con una sola métrica excluyendo otras importantes. IS - Lic. Marisa Gouget

8 Métricas del proceso Ejemplos, errores encontrados antes de la entrega del producto
Métricas privadas: Índice de defectos Índice de defectos por módulo Errores encontrados durante el desarrollo Métricas públicas: Defectos informados de funciones importantes del software Errores encontrados durante revisiones técnicas formales IS - Lic. Marisa Gouget

9 Métricas del proceso Análisis de fallos
Todos los errores y defectos se categorizan por origen: defectos en la especificación, en la lógica, etc. Se registra tanto el costo de corregir cada error como el del defecto. El número de errores y de defectos de cada categoría se cuentan y ordenan en orden descendente. Se computa el costo total de errores y defectos cada categoría. Se analizan los datos resultantes para detectar las categorías que producen los costos más altos para la organización. Se desarrollan planes para modificar el proceso y eliminar la clase de errores y defectos que sean más costosos. IS - Lic. Marisa Gouget

10 Ingeniería del Software
Métricas del Proyecto Ingeniería del Software IS - Lic. Marisa Gouget

11 Indicadores del proyecto Objetivos
Evaluar el estado del proyecto en curso Seguir la pista de los riesgos potenciales Detectar las áreas de problemas antes de que se conviertan en críticas. Ajustar el flujo y las tareas del trabajo. Evaluar la habilidad del equipo del proyecto en controlar la calidad de los productos de trabajo de la IS. IS - Lic. Marisa Gouget

12 Métricas del proyecto Para adaptar el flujo de trabajo
Esfuerzo planificado vs real Tiempo planificado vs real Índices de producción: páginas de documentación, horas de revisión, puntos de función y líneas de código entregadas. Métricas técnicas para evaluar calidad del diseño, generación de código, pruebas, etc. Entradas: dimensión de los recursos, Salidas: entregables, Resultados: efectividad de las entregas. IS - Lic. Marisa Gouget

13 Ingeniería del Software
Métricas del Producto Ingeniería del Software IS - Lic. Marisa Gouget

14 Mediciones del software
Medidas directas: Líneas de código producidas Velocidad de ejecución Tamaño de memoria Defectos informados Medidas indirectas: Funcionalidad Calidad Complejidad Eficiencia Fiabilidad Facilidad de mantenimiento IS - Lic. Marisa Gouget

15 Mediciones del software Métricas orientadas al tamaño
Estas métricas provienen de la normalización de las medidas de calidad y/o productividad considerando el tamaño del software que se haya producido. Se puede comparar entre distintos proyectos si se seleccionan líneas de código como valor de normalización. Proyecto LDC Esfuerzo $ (000) Pp doc Errores Defectos Personas Alfa 24 168 365 134 29 3 Beta 27200 62 440 1224 321 86 5 IS - Lic. Marisa Gouget

16 Mediciones del software Métricas orientadas al tamaño
Errores por KLDC (miles de líneas de código) Defectos por KLDC $ por LDC Páginas de documentación por LDC Errores por personas/mes LDC por personas/mes $ por página de documentación IS - Lic. Marisa Gouget

17 Mediciones del software Métricas orientadas a la función
Utilizan una medida de la funcionalidad entregada por la aplicación como valor de normalización. Fueron propuestas por Albretch en 1979 con el nombre de Puntos de Función, que se derivan de una relación empírica entre las medidas contables directas del software y las evaluaciones de su complejidad. IS - Lic. Marisa Gouget

18 Puntos de Función de Albretch
Los puntos de función se computan a partir de una tabla que considera cinco características de dominios de información: Número de entradas de usuario. Número de salidas de usuario. Número de peticiones de usuario. Número de archivos. Número de interfaces externas (con otros sistemas). A cada cuenta se le asocia un valor de complejidad. IS - Lic. Marisa Gouget

19 Puntos de Función de Albretch
Parámetro Cantidad Simple Medio Complejo Total Entradas N * 3 4 6 Salidas 5 7 Peticiones Archivos 10 15 Interfaces Cuenta total IS - Lic. Marisa Gouget

20 Puntos de Función de Albretch
La fórmula a utilizar luego es: PF= cuenta total * ( * sum Fi) Donde cuenta total es el valor obtenido en la tabla anterior, Fi es la multiplicación de 14 factores de ajuste de la complejidad según la siguiente tabla: No influencia Incidental Moderado Medio Significativo Esencial 1 2 3 4 5 IS - Lic. Marisa Gouget

21 Puntos de Función de Albretch
¿Requiere el sistema copias de seguridad y recuperación fiables? ¿Se requiere comunicación de datos? ¿Existen funciones de procesamiento distribuido? ¿Es crítico el rendimiento? ¿Se ejecutará el sistema en un entorno operativo existente y fuertemente utilizado?. ¿Requiere el sistema entrada de datos interactiva?. ¿Requiere la entrada de datos interactiva que la operación se lleve a cabo sobre múltiples pantallas u operaciones? IS - Lic. Marisa Gouget

22 Puntos de Función de Albretch
¿Se actualizan los archivos maestros en forma interactiva?. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?. ¿Es complejo el procesamiento interno? ¿Se ha diseñado el código para ser reutilizable? ¿Están incluidas en el diseño la conversión y la instalación?. ¿Se ha diseñado el sistema para soportar múltiples intalaciones en diferentes organizaciones?. ¿Se ha diseñado la aplicación para facilitar los cambios y para ser facilmente utilizada por el usuario? IS - Lic. Marisa Gouget

23 Puntos de Función de Albretch
Una vez obtenidos los puntos de función y de acuerdo al lenguaje que se utilizará para el desarrollo se pueden calcular las líneas de código estimadas, por ejemplo: Cobol LDC/PF Orientados a objetos 30 LDC/PF Lenguajes Gráficos 4 LDC/PF ADA 70 LDC/PF IS - Lic. Marisa Gouget

24 El modelo COCOMO El Modelo Constructivo de Costes (Constructive Cost Model) fue desarrollado por B. W. Boehm a finales de los 70 y comienzos de los 80, exponiéndolo detalladamente en su libro "Software Engineering Economics" (Prentice-Hall, 1981). COCOMO es una jerarquía de modelos de estimación de costos software que incluye submodelos básico, intermedio y detallado. IS - Lic. Marisa Gouget

25 El modelo COCOMO Modelo Básico
Este modelo trata de estimar, de una manera rápida y más o menos burda, la mayoría de proyectos pequeños y medianos. Se consideran tres modos de desarrollo en este modelo: orgánico, semiencajado y empotrado. IS - Lic. Marisa Gouget

26 El modelo COCOMO Modelo Básico: Modo orgánico.
Un pequeño grupo de programadores experimentados desarrollan software en un entorno familiar. El tamaño del software varía de unos pocos miles de líneas (tamaño pequeño) a unas decenas de miles de líneas (medio) El coste se incrementa a medida que el tamaño lo hace, y el tiempo de desarrollo se alarga. IS - Lic. Marisa Gouget

27 El modelo COCOMO Modelo Básico: Modo orgánico.
Se utilizan dos ecuaciones para determinar el esfuerzo de personal y el tiempo de desarrollo. El coste es: Km = 2.4 Sk1.05 donde Km se expresa en personas-mes y Sk es el tamaño expresado en miles de líneas de código fuente.   IS - Lic. Marisa Gouget

28 El modelo COCOMO Modelo Básico: Modo orgánico.
El tiempo de desarrollo se da por: td = 2.5 Km0.38 donde Km se obtiene de la ecuación anterior y td es el tiempo de desarrollo en meses. Estas ecuaciones se han obtenido por medio de ajustes de curvas realizado por Boehm sobre 63 proyectos. IS - Lic. Marisa Gouget

29 y el tiempo de desarrollo por
El modelo COCOMO Modelo Básico: Modo Empotrado. En este modo, el proyecto tiene unas fuertes restricciones, que pueden estar relacionadas con el procesador y la interfase hardware. El problema a resolver es único y es difícil basarse en la experiencia, puesto que puede no haberla. Las estimaciones de tiempo y coste se basan en las mismas ecuaciones que en el modo orgánico, pero con diferentes constantes. Así, el coste se da por Km = 3.6 Sk1.20 y el tiempo de desarrollo por td = 2.5 Km0.32 IS - Lic. Marisa Gouget

30 y el tiempo de desarrollo por
El modelo COCOMO Modelo Básico: Modo Semiencajado. Es un modo intermedio entre los dos anteriores. Dependiendo del problema, el grupo puede incluir una mezcla de personas experimentadas y no experimentadas. Las ecuaciones son Km = 3.0 Sk1.12 y el tiempo de desarrollo por td = 2.5 Km0.35. IS - Lic. Marisa Gouget

31 El modelo COCOMO Modelo Intermedio
En este modelo se introducen 15 atributos de coste para tener en cuenta el entorno de trabajo. Estos atributos se utilizan para ajustar el coste nominal del proyecto al entorno real, incrementando la precisión de la estimación. Para cada modo de desarrollo, los 15 atributos del costo intervienen como multiplicadores en el coste nominal, Kn, para producir el coste ajustado. IS - Lic. Marisa Gouget

32 El modelo COCOMO Modelo Intermedio: Atributos de costo.
Estos atributos tratan de capturar el impacto del entorno del proyecto en el coste de desarrollo. De un análisis estadístico de más de 100 factores que influencian el coste, Boehm retuvo 15 de ellos para COCOMO. Estos atributos se agrupan en cuatro categorías: atributos del producto, atributos del ordenador, atributos del personal, atributos del proyecto. IS - Lic. Marisa Gouget

33 El modelo COCOMO Modelo Intermedio: Atributos de costo.
Atributos del producto RELY: garantía de funcionamiento requerida al software DATA: tamaño de la base de datos CPLX: complejidad del producto Atributos del ordenador TIME: restricción de tiempo de ejecución STOR: restricción del almacenamiento principal VIRT: volatilidad de la máquina virtual TURN: tiempo de respuesta del ordenador IS - Lic. Marisa Gouget

34 El modelo COCOMO Modelo Intermedio: Atributos de costo.
Atributos del personal ACAP: capacidad del analista AEXP: experiencia en la aplicación PCAP: capacidad del programador VEXP: experiencia en máquina virtual LEXP: experiencia en lenguaje de programación Atributos del proyecto MODP: prácticas de programación modernas TOOL: utilización de herramientas software SCED: plan de desarrollo requerido IS - Lic. Marisa Gouget

35 El modelo COCOMO Modelo Intermedio
Las ecuaciones nominales de costo para el modelo intermedio son modo orgánico Kn = 3.2 Sk1.05 modo semiencajado Kn = 3.0 Sk1.12 modo empotrado Kn = 2.8 Sk1.20 Cada atributo se cuantifica para un entorno de proyecto. La escala es muy bajo, bajo, nominal alto, muy alto,extremadamente alto. Estos 15 valores, obtenidos según tabla, se multiplican al Kn, y nos proporciona el esfuerzo ajustado al entorno.  IS - Lic. Marisa Gouget

36 El modelo COCOMO Modelo Intermedio: Atributos de costo.
IS - Lic. Marisa Gouget

37 El modelo COCOMO Modelo Detallado
Este modelo puede procesar todas las características del proyecto para construir una estimación. Introduce dos características principales: Multiplicadores de esfuerzo sensitivos a la fase. Algunas fases se ven más afectadas que otras por los atributos. El modelo detallado proporciona un conjunto de multiplicadores de esfuerzo para cada atributo. Esto ayuda a determinar la asignación del personal para cada fase del proyecto. Jerarquía del producto a tres niveles. Se definen tres niveles de producto. Estos son módulo, subsistema y sistema. La cuantificación se realiza al nivel apropiado, esto es, al nivel al que es más susceptible la variación.  IS - Lic. Marisa Gouget

38 El modelo COCOMO Modelo Detallado: Estimación del esfuerzo.
A. Fases de desarrollo El desarrollo del software se lleva a cabo a través de cuatro fases consecutivas: requerimientos/planes, diseño del producto, programación y prueba/integración. Requerimientos/planes. Esta es la primera fase del ciclo de desarrollo. Se analiza el requerimiento, se muestra un Plan de Producto y se genera una especificación completa del producto. Esta fase consume del 6% al 8% del esfuerzo nominal Kn, y dura del 10% al 40% del tiempo nominal de desarrollo td. Estos porcentajes dependen del modo y del tamaño (de 2000 LOC a LOC). IS - Lic. Marisa Gouget

39 El modelo COCOMO Modelo Detallado: Estimación del esfuerzo.
Diseño del producto. La segunda fase del ciclo de desarrollo COCOMO se preocupa de la determinación de la arquitectura del producto y de las especificaciones de los subsistemas. Esta fase requiere del 16% al 18% del esfuerzo nominal Kn, y puede durar del 19% al 38% del tiempo nominal de desarrollo td. Programación.La tercera fase del ciclo de desarrollo COCOMO se subdivide en dos subfases: diseño detallado y prueba del código. Esta fase requiere del 48% al 68% del esfuerzo nominal Kn, y dura del 24% Al 64% del tiempo nominal de desarrollo. Prueba/Integración. Esta última fase consiste principalmente en unir las diferentes unidades ya probadas. Se utiliza del 16% al 34% del coste nominal Kn y dura del 18% al 34% del td. IS - Lic. Marisa Gouget

40 Métricas para la calidad del Software
Ingeniería del software IS - Lic. Marisa Gouget

41 3 Factores de la calidad de un software
Operación del producto (utilizándolo) Revisión del producto (cambiándolo) Transición del producto (modificándolo para que funcione en otro entorno). IS - Lic. Marisa Gouget

42 Medidas de la calidad de software
Corrección: el grado en el que el software lleva a cabo su función requerida. Facilidad de mantenimiento: facilidad con la que se puede corregir el soft si se encuentra un error, se puede adaptar a los cambios o mejorar si el cliente lo pide. Facilidad de uso: Habilidad físico y/o intelectual requerida para aprender el sistema. Tiempo requerido para llegar a hacer un uso eficiente del sistema. Aumento en productividad sobre el sistema que reemplaza. Valoración subjetiva de los usuarios. IS - Lic. Marisa Gouget

43 Eficacia de la eliminación de defectos: EED
Es un indicador de calidad del proyecto y del proceso. EED = E/(E+D), donde E es el número de errores encontrados antes de la entrega del proyecto, D es el número de defectos encontrados después de la entrega. El ideal sería EED = 1, no se han encontrado defectos. Puede utilizarse por fases en el proceso, EEDi= Ei/(Ei+Di+1) IS - Lic. Marisa Gouget

44 Integración de las métricas dentro del proceso de software
La mayoría de los desarrolladores de software no miden ni desean comenzar, es un problema cultural. Lo que no se mide no se controla, lo que no se controla no se mejora. La recopilación de datos requiere una investigación, el cálculo de las métricas es posible, la evaluación de las métricas pueden producir un grupo de indicadores que guíen el proceso y ayuden a curar “el mal del software”. IS - Lic. Marisa Gouget

45 Integración de las métricas dentro del proceso de software Razones iniciales para medir
Obtener claridad y consenso con respecto a los objetivos, el proceso, el proyecto y el producto. Conseguir el enfoque, para optimizar la dedicación de los recursos a los temas estratégicos del proceso-proyecto-producto. Descentralización y desarrollo del liderazgo. Intervención estratégica. IS - Lic. Marisa Gouget