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

IS - Lic. Marisa Gouget 1

El proceso del Software y Métricas del proyecto

Ingeniería del SoftwareIngeniería del Software

Lic. Marisa GougetLic. Marisa Gouget

UCSAUCSA


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.


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.


Medidas, métricas e indicadores

Proceso de ingeniería del

software

Proyectodel software

Producto delsoftware

Recopilaciónse datos

Cálculo demétricas

Evaluación demétricas

Medidas

Métricas

Indicadores


Métricas del proceso



Métricas del procesoDeterminantes de la calidad del software y de la efectividad de la organización

Proceso

ProductoProducto

PersonasPersonas TecnologíaTecnología

CaracterísticasCaracterísticasdel clientedel cliente

CondicionesCondicionesdel negociodel negocio

Entorno deEntorno dedesarrollodesarrollo


Métricas del procesoDeterminantes 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.


Métricas del procesoEjemplos, 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


Métricas del procesoAnálisis de fallos1. Todos los errores y defectos se categorizan por origen:

defectos en la especificación, en la lógica, etc.2. Se registra tanto el costo de corregir cada error como el

del defecto.3. El número de errores y de defectos de cada categoría se

cuentan y ordenan en orden descendente.4. Se computa el costo total de errores y defectos cada

categoría.5. Se analizan los datos resultantes para detectar las

categorías que producen los costos más altos para la organización.

6. Se desarrollan planes para modificar el proceso y eliminar la clase de errores y defectos que sean más costosos.


Métricas del Proyecto



Indicadores del proyectoObjetivos 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.


Métricas del proyectoPara 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.


Métricas del Producto



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


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

AlfaAlfa 12.110012.1100 2424 168168 365365 134134 2929 33

BetaBeta 2720027200 6262 440440 12241224 321321 8686 55


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


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.


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.



Parámetro Cantidad Simple Medio Complejo Total

Entradas N * 3 4 6

Salidas N * 4 5 7

Peticiones N * 3 4 6

Archivos N * 7 10 15

Interfaces N * 5 7 10

Cuenta total



La fórmula a utilizar luego es:

PF= cuenta total * (0.65 + 0.01 * 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:

0 1 2 3 4 5

No influencia Incidental Moderado MedioSignificativo Esencial



1. ¿Requiere el sistema copias de seguridad y recuperación fiables?

2. ¿Se requiere comunicación de datos?3. ¿Existen funciones de procesamiento distribuido?4. ¿Es crítico el rendimiento?5. ¿Se ejecutará el sistema en un entorno operativo

existente y fuertemente utilizado?.6. ¿Requiere el sistema entrada de datos interactiva?.7. ¿Requiere la entrada de datos interactiva que la

operación se lleve a cabo sobre múltiples pantallas u operaciones?



8. ¿Se actualizan los archivos maestros en forma interactiva?.

9. ¿Son complejas las entradas, las salidas, los archivos o las peticiones?.

10. ¿Es complejo el procesamiento interno?

11. ¿Se ha diseñado el código para ser reutilizable?

12. ¿Están incluidas en el diseño la conversión y la instalación?.

13. ¿Se ha diseñado el sistema para soportar múltiples intalaciones en diferentes organizaciones?.

14. ¿Se ha diseñado la aplicación para facilitar los cambios y y para ser facilmente utilizada por el usuario?



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 105 LDC/PFOrientados a objetos 30 LDC/PFLenguajes Gráficos 4 LDC/PFADA 70 LDC/PF


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.


El modelo COCOMO

Modelo BásicoEste 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.


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.


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.


El modelo COCOMO

Modelo Básico: Modo orgánico.El tiempo de desarrollo se da por:td = 2.5 Km

0.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.


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


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.


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.


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.


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


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


El modelo COCOMO

Modelo Intermedio Las ecuaciones nominales de costo para el

modelo intermedio son modo orgánico Kn = 3.2 Sk

1.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.


El modelo COCOMO

Modelo Intermedio: Atributos de costo.

Parámetros VL L N H VH XH RELY ,75 ,88 1 1,15 1,4 DATA ,94 1 1,08 1,16 CPLX ,7 ,85 1 1,15 1,3 1,65 TIME 1 1,11 1,3 1,66 STOR 1 1,06 1,21 1,56 VIRT ,87 1 1,15 1,30 TURN ,87 1 1,07 1,15 ACAP 1,46 1,19 1 ,86 ,71 AEXP 1,29 1,13 1 ,91 ,82 PCAP 1,42 1,17 1 ,86 ,7 VEXP 1,21 1,1 1 ,9 LEXP 1,14 1,07 1 ,95 MODP 1,24 1,1 1 ,91 ,82 TOOL 1,24 1,1 1 ,91 ,83 SCED 1,23 1,08 1 1,04 1,1


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.


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 512000 LOC).


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.


Métricas para la calidad del Software

Ingeniería del softwareIngeniería del software


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).


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.


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)


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”.


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.

Documents

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