Ing. Francisco Rodríguez NovoaIng. Francisco Rodríguez Novoa

UNT. INGENIERIA INDUSTRIAL

Ingeniería de Software

Tema 2

ESTIMACION DE PROYECTOS SOFTWARE

Métricas de Software

La medición es fundamental en el desarrollo de cualquier producto.

La medición del software proporciona un mecanismo para la evaluación objetiva.

Las mediciones pueden aplicarse sobre:

• Proceso (permitiendo mejorarlo)

• Proyecto (ayuda en la estimación, control de calidad y

evaluación)

• Producto (análisis de calidad de resultados)

Métricas de Software

Las mediciones permiten:

• caracterizar fijar líneas base para comparar con

evaluaciones futuras

• evaluar controlar avance, desviaciones, impacto

tecnológico, mejoras

• predecir planificar y estimar en base a datos históricos,

• mejorar la calidad del producto

Métricas de Software

Medida: proporciona indicación cuantitativa de extensión,

cantidad, capacidad o tamaño de los atributos de un proceso,

proyecto o producto.

Medición: es el acto que determina una medida.

Métrica: una medida cuantitativa del grado en que un

sistema, componente, o proceso posee un atributo dado.

Indicador: métrica o combinación de métricas que

proporciona una visión profunda del proceso, del proyecto o

del producto.

Métricas de Software

El ingeniero de software recopila medidas

y desarrolla métricas para obtener indicadores

Ejemplo:

Medida # errores encontrados en la revisión de un módulo

Posibles Métricas en base a dicha medida

# medio de errores encontrados por cada revisión

# medio de errores encontrados por persona-hora en revisiones

Un Indicador podría obtenerse del siguiente análisis:

Los equipos que aplicaron una determinada metodología de trabajo obtuvieron un 30% menos de errores que aquellos que no la aplicaron.

Esto puede ser un indicador que permita al Gerente del Proyecto decidir que todos los equipos utilicen dicha metodología.

Métricas del Proceso e Indicadores

Los Indicadores del Proceso permiten obtener información sobre la eficacia de un proceso existente. El gestor puede evaluar lo que funciona y lo que no del proceso.

Métricas del Proceso

• Se recopilan de proyectos anteriores, durante un largo período de tiempo. Permiten lograr indicadores para mejorar los procesos del software.

• Son indirectas. Se extraen según resultados provenientes del proceso.

• Ejemplos: errores detectados antes de la entrega, defectos detectados e informados por los usuarios finales, productos de trabajo entregados, esfuerzo humano y horas consumidas para obtener un producto de trabajo, ajustes con la planificación

Métricas del Proyecto e Indicadores

Los Indicadores de Proyecto permiten:

• evaluar el estado del proyecto en curso

• seguir la pista de los riesgos potenciales

• detectar áreas de problemas antes de que sean críticas

• ajustar el flujo de trabajo y las tareas realizadas

• evaluar habilidad del equipo p/ controlar la calidad de lo producido

Métricas del Proyecto e Indicadores

Métricas del Proyecto

• Se recopilan de proyectos anteriores.

• Permiten estimar esfuerzo, costo y tiempo para el actual proyecto.

• Sirven para supervisar y controlar el avance del proyecto.

• Gobiernan los ajustes necesarios para evitar riesgos, retrasos y atenuar problemas.

Categorías de Mediciones del Software

• Medidas Directas

Costo y esfuerzo requerido para desarrollar el software,

número de líneas de código (LDC) producidas, velocidad de

ejecución, tamaño de memoria, defectos informados durante

un período.

• Medidas Indirectas

Funcionalidad, calidad, complejidad, eficiencia, fiabilidad,

facilidad de mantenimiento, facilidad de uso.

Es necesario normalizar las medidas para crear métricas de software

que permitan comparar diferentes proyectos

Métricas Orientadas al Tamaño

Provienen de normalizar medidas de calidad y/o productividad,

considerando el tamaño del software producido. Se definen métricas que permiten comparar diferentes proyectos.

Ventajas: Se calculan fácilmente, existen modelos de estimación que usan LDC como entrada y hay mucha documentación.

Detractores: el #LDC dependen del lenguaje de programación, perjudican a programas cortos pero bien diseñados, dificulta la planificación porque se deben estimar las LDC mucho antes de que se complete el análisis y diseño

Métricas Orientadas a la Función • Albretch, 1979, sugirió los Puntos de Función como una medida de funcionalidad del software.

• La funcionalidad es una medida indirecta, entonces deben usarse medidas directas para conseguirla.

• Para computar métricas c/PF se definen cinco características:

# Entradas de usuario: contar cada entrada de usuario que

proporciona datos a la aplicación.

# Salidas de usuario: contar cada salida que la aplicación proporciona al usuario. (informes, pantallas, mensajes).

# Peticiones de usuario. petición entrada interactiva que produce alguna respuesta del software inmediata como salida interactiva.

# Archivos: contar cada archivo lógico maestro (agrupación lógica de datos).

# Interfaces externas: contar todas las interfaces que se utilizan para transmitir información a otro sistema

Puntos de Función

Factor de Ponderación: simple, medio o complejo. Valor de complejidad determinado de manera subjetiva por c/ organización.

Puntos de Función: Valores de ajuste de complejidad

Planificación de Proyectos: Estimación

La gestión de proyectos de software comienza con un

conjunto de actividades que globalmente se

denominan

Planificación de Proyectos de Software.

Su principal objetivo es proporcionar un marco de

trabajo que permita al gestor hacer estimaciones

razonables de recursos, costo y tiempos.

Planificación de Proyectos Software

• Definir el Ambito del software.

Evaluar la funcionalidad, el rendimiento y las restricciones requeridas.

Se realizan entrevistas entre el Ingeniero de SW y el Cliente y se aplican técnicas para facilitar las especificaciones de la aplicación.

Ejemplo: FAST: Facilitated Application Specification Techniques, se crean equipos de clientes y desarrolladores para identificar el problema, proponer soluciones, negociar enfoques y especificar un conjunto preliminar de requisitos.

La viabilidad del proyecto se define de acuerdo al ámbito especificado.

¿Es factible contruir el Sw a partir de éste ámbito?

• Estimar los Recursos requeridos.

Estimación de Proyectos Software

Opciones p/ realizar estimaciones seguras de costos y esfuerzos:

• Dejar la estimación para más adelante (será 100% fiable al terminar el proyecto). No puede ser, son necesarias a priori.

• Basarse en proyectos similares ya terminados. Solo si el proyecto actual es muy similar a esfuerzos pasados.

• Utilizar técnicas de descomposición. Método viable para la estimación de proyectos de software que utiliza un enfoque “divide y vencerás”.

• Desarrollar un modelo empírico de estimación. Pueden usarse como complemento a las técnicas de descomposición. Cada modelo se basa en datos históricos. COCOMO y COCOMO II.

Técnicas de Descomposición

• Estimación basada en el problema: se usan LDC y PF como medidas básicas para calcular métricas de productividad. Estimación basada en LDC y en Puntos de Función.

Se descompone el problema en funciones, se basa en los datos históricos, y estima un valor de tamaño optimista, más probable, y pesimista para cada función. Se calcula el valor esperado (VE) de la variable de estimación como la media ponderada de las estimaciones optimistas, más probables y pesimistas.

VE = (Sopt+ 4Sm+ Spes)/6

• Estimación basada en el proceso: Se descompone el proceso en tareas y se estima el esfuerzo (por ej.: persona-mes) que requerirá llevar a cabo cada una de las tareas del proceso en cada función.

Modelos Empíricos de Estimación

COCOMO (COnstructive COst MOdel)

Boehm (81) introduce una jerarquía de modelos:

Modelo 1: COCOMO básico, calcula esfuerzo y costo del desarrollo en función del tamaño del programa, expresados en LDC.

Modelo 2: COCOMO intermedio, calcula esfuerzo y costo en función del tamaño del programa y de un conjunto de conductores de costo con atributos del producto, del HW, del personal y del proyecto.

Modelo 3: COCOMO avanzado, incorpora las características del intermedio + evaluación de los conductores de costo en c/fase del proceso.

COCOMO está definido para tres tipos de proyectos:

•modo orgánico: proyectos de software pequeños y sencillos.

•modo semiacoplado: proyectos de software intermedio en cuanto a tamaño y nivel de complejidad.

•modo empotrado: proyectos muy restringidos

COCOMO Básico

COCOMO Básico

Ej. Con modelo orgánico y suponiendo KLDC=33,2.

• Calcula la cantidad de personas por mes.

E = 2,4 (KLDC)1,05

= 2,4 (33,2) 1,05 = 95 p-m

• Calcula la duración del proyecto.

D = 2,5 E0,38

= 2,5 (95) 0,38 = 14,10 meses

• Calcula número de personas para el proyecto.

N = E / D

= 95 / 14,10

~ 7 personas

FIN