clase 6, 5/9/2007

Metodologías de Análisis

Clase 5 – 4/9/2007

Christian Sifaqui

Técnicas de estimación de costos

Modelos algorítmicos de estimación de costos

Juicio experto

Estimación por analogía

Ley de Parkinson

Pricing to win

Subasta holandesa/Subasta inglesa

Técnicas de estimación de costosModelos algorítmicos de costos

Se usa un modelo basado en información histórica de costos que relaciona alguna métrica de software (usualmente su tamaño) al costo del proyecto. Se hace uan estimación de esa métrica y el modelo predice el esfuerzo requerido.

Juicio experto Se consultan algunos expertos en las técnicas de desarrollo de software y el dominio de aplicación propuesto. Ellos estiman el costo del proyecto, estas estimaciones se comparan y discuten. Se itera este proceso de estimación hasta que se logra un acuerdo.

Estimation por analogía Esta técnica se aplica cuando otros proyectos en el mismo dominio de aplicación han sido finalizados. El costo del nuevo proyecto se esiam por analogía a estos proyectos finalziados.

Ley de Parkinson Esta ley establece que el trabajo se expandirá hasta completar el tiempo disponible. El costo se determina por los recursos disponibles en vez de evaluación objetiva. Si el software se entregará en 12 meses y hay 5 personas disponibles, el esfuerzo requerido se estima en 60 meses-hombre.

Pricing to win El costo del software se estima a lo que el cliente tiene disponible para gastar en el proyecto. El esfuerzo estimado depende del presupuesto que el cliente tenga y no de la funcionalidad del software.

Subasta Inglesa Comienza con precio cero y va subiendo. Los participantes comienzan activos deseando comprar a cero. A medida que aumenta el precio, los participantes disminuyen sus demandas. La subasta termina cuando sólo queda un participante activo. Éste es el ganador, paga el precio en el cual el resto de los participantes dejaron de pujar.

Subasta Holandesa Comienza al precio más alto del objeto, el que ningún participante está dispuesto a pagar. Va descendiendo hasta que uno de los participantes anuncia su deseo de pujar. Así obtiene el objeto.

Estimación bottom-up y top-down

En algunas de las aproximaciones anteriores se puede usar top-down o bottom-up

Top-down- Iniciar a nivel de sistema y estimar la funcionalidad total del sistema y cómo esta se entrega a través de sub-sistemas

Bottom-up- iniciar a nivel de componente y estimar el esfuerzo para cada componente. Sume estos esfuerzo para lograr una estimación final

Estimación top-down

Usable sin conocimiento de la arquitectura del sistema y las componentes podrían ser parte del sistema

Toma en cuenta costos como integración, administración de la configuración y documentación

Puede olvidar considerar el costo de resolver difíciles problemas técnicos de bajo nivel

Estimación bottom-up

Usable cuando la arquitectura del sistema es conocida e identificado los componentes

Puede ser un método exacto si el sistema ha sido diseñado en detalle

Podría olvidar considerar las actividades de costos de nivel de sistema como integración y documentación

Métodos de estimación

Cada método tiene fortalezas y debilidades

La estimación debería estar basada en varios métodos

Si no entregan resultados similares, no hay suficiente información disponible para estimar

Juicio experto por analogía

Expertos comparan el producto a realizar con productos ya realizados

Estimaciones pueden guiar a costos incorrectos

Expertos pueden recolectar datos inexactos

Expertos humanos tienen sesgos

Sin embargo, el resultado de una estimación por un grupo amplio de expertos podría ser exacto

La técnica Delphi se podría requerir para lograr consenso

Modelos de estimación algorítmicos de costos

Se usa una métrica del proyecto como entrada a un modelo para calcular costos y duración

- un modelo algorítmico es no sesgado y por lo tanto superior a una opinión experta

- sin embargo, las estimaciones son sólo tan buenas como las suposiciones de fondo

Ejemplos- modelo SLIM

- modelo Price S

- COCOMO

Métricas para el tamaño de un producto

- líneas de código (LOC, KDSI, KLOC)

- FFP

- Puntos de función

Líneas de código

- métrica alternativa: miles de instrucciones fuente entregadas (KDSI)- código fuente es sólo una pequeña parte del esfuerzo de software- diferentes lenguajes entregan diferentes largos de código- LOC no está definido para lenguajes no-procedurales (LISP o 4GL)

Líneas de código

- no es claro cómo contar líneas de código- ejecutables- definiciones de datos- comentarios- sentencias de lenguaje de job control- líneas cambiadas y/o borradas

- no todo lo escrito se entrega- un generador de reportes, pantallas o GUI puede generar miles de líneas de código en minutos

Líneas de código

- LOC se conoce exactamente cuando el proyecto finaliza- estimaciones basadas en LOC por lo tanto son poco confiables

- para iniciar un proceso de estimación, se debe estimar las LOC del producto final

- y esta estimación LOC se utiliza para estimar el costo del producto (es decir, una estimación basada en una estimación)

Líneas de código

Paradoja de las métricas de líneas de código

ACTIVITY CASE A CASE B ASSEMBLER FORTRAN VERSION VERSION (10,000 LINES) (3,000 LINES) DIFFERENCE -------------- -------------- -------------- Requirements 2 Months 2 Months 0 Design 3 Months 3 Months 0 Coding 10 Months 3 Months - 7 Integration/Test 5 Months 3 Months - 2 User Documentation 2 Months 2 Months 0 Management/Support 3 Months 2 Months - 1 -------------- -------------- -------------- Total 25 Months 15 Months - 10 -------------- -------------- -------------- Total Costs $125,000 $75,000 - $50,000 Cost Per Source Line $12.50 $25.00 + $12.50 Lines Per Person Month 400 200 - 200

Métricas para el tamaño de un producto

- se han propuesto aproximaciones alternativas para estimar el tamaño de un producto

- FFP (files, flows y processes) ‘83- Puntos de función ‘79

FFP

- para estimación de costos de productos de procesamiento de datos de tamaño medio

- file: colección de registros lógica o físicamente relacionados permanentemente residentes en el producto (se excluyen archivos de transacción y temporales)- flow: interfaz de datos entre el producto y el ambiente, como una pantalla o un reporte- process: manipulación de datos lógica o aritmética, definida funcionalmente

FFP

- dado el número de files (Fi), flows (Fl) y processes (Pr)

el tamaño (s) y el costo (c) se calculan:s = Fi + Fl + Prc = d * s

- d: es una constante de eficiencia o productividad dentro de cada organización

- esta métrica no incluye bases de datos

Puntos de función

- método para medir desarrollo de software desde el punto de vista del usuario

Puntos de función

Entregables

– conteo total de Unadjusted Function Point

– Unadjusted Function Point (EI, EO, EQ, ILF, EIF)

– Value Adjustment Factor (VAF)– conteo total de Adjusted Function Point– reportes de validación

Puntos de función

- UFP (unadjusted function point)- funciones de datos:

- ILF: internal logical files- EIF: external interface files

- funciones transaccionales:- EI: external input- EO: external output- EQ: external inquiries

Puntos de función

Entradas:

• Documentación de los objetivos percibidos, problemas y deseos del usuario

• Documentación recolectada respecto del sistema actual, si es que tal sistema (automático o manual) existiera

• Cualquier objetivo y restricción refinado para el sistema propuesto• Cualquier otra documentación de requerimientos completada a la

fecha• Formatos y diálogos de pantalla• Layouts de reportes• Layouts de formularios de ingreso• Interfaces con otros sistemas y entre sistemas• Modelos de datos lógicos y/o físicos preliminares

Puntos de función

Paso 1: planificar el conteo de puntos de función (FP)

El trabajo de contar FP debiera estar incluido en el plan general del proyecto. Contar FP se debe agendar y planificar. El primer conteo debiera usarse para estimar el tamaño.

Se pueden contar FP antes de completar los requerimientos. El conteo de FP inicial debiera estar documentado, para así mantenerlo y actualizarlo. Se puede completar el conteo antes de tener el conjunto completo de requrimientos, pero el conteo de FP debiera completarse después que se hayan finalizado los requerimientos y de nuevo al finalizar la implementación.

Después de haber completado el conteo de FP, éste debiera compararse con los valores previos de FP para verificar componentes nuevas o cambiadas. Cada adición al conteo de FP debiera indicar si la actualización se debe a nueva funcionalidad o a una mejora en el conteo.

Puntos de función

Paso 2: recolectar la documentación

Documentación de los objetivos, problemas y necesidades percibidas por el usuario.

Documentación recolectada respecto del sistema actual, si es que tal sistema (automático o manual) existiera

Cualquier objetivo y restricción refinado para el sistema propuesto

Descripción y o modelo del framework general del sistema

Cualquier otra documentación de requerimientos completada a la fecha

Puntos de función

Paso 2: recolectar la documentación

Se puede completar un FP más detallado después de análisis y diseño

Se recomienda la siguiente documentación durante y después del completar el diseño.

Fomatos y diálogos de pantalla

Formatos y diálogos de pantalla

Layouts de reportes

Layouts de formularios de ingreso

Interfaces con otros sistemas y entre sistemas

Modelos de datos lógicos y/o físicos preliminares

Tamaños y formatos de archivos

Opciones de menús

Puntos de función

Paso 3: determinar las 14 características generales del sistema

Los grados de influencia varían en un escala de 0 a 5 (sin influencia-influencia fuerte)

Valor Influencia al sistema

0 No presente o sin influencia

1 Influencia incidental

2 Influencia moderada

3 Influencia promedio

4 Influencia significativa

5 Fuerte influencia

Puntos de función

Característica general del sistema (CGS) Breve descripción

Data communications ¿Cuántos servicios de comunicación existen para ayudar en la transferencia o intercambio de información con la aplicación o sistema?

Distributed data processing ¿Cómo son manejados datos y funciones de procesamiento distribuidos?

Performance ¿Solicitó el usuario tiempo de respuesta o rendimiento?

Heavily used configuration ¿Cuánta carga de uso tiene la plataforma de hardware actual donde la aplicación correrá?

Transaction rate ¿Cuán frecuentemente se ejecutan las transacciones?¿ dirariamente, semanalmente, mensualmente, etc.?

On-line data entry ¿Qué porcentaje de la información se ingresa en línea?

End-user efficienciy ¿Se diseñó la aplicación para eficiencia al usuario final?

Puntos de función

Característica general del sistema (CGS) Breve descripción

On-line update ¿Cuántos ILFs se actualizan por transacciones en línea?

Complex processing ¿La aplicación tiene extensivos procesamientos lógicos o matemáticos?

Reusability ¿Fue desarrollada la aplicación para solucionar las necesidades de uno o más usuarioas?

Installation ease ¿Cuán difícil es la conversión e instalación?

Operational ease ¿Cuán efectivos o automáticos son los procedimientos de inicio, respaldo y recuperación?

Multiple sites ¿Se diseñó, desarrolló y soportó la aplicación para ser instalada en múltiples sitios para múltiples organizaciones?

Facilitate change ¿Se diseñó, desarrolló y soportó específicamente para facilitar el cambio?

Puntos de función

Paso 4: inventario de transacciones y archivos

External Inputs (EI)

External Outputs (EO)

External Inquiries (EQ)

Internal Logical Files (ILF)

External Interface Files (EIF)

Puntos de función


External Inputs (EI): es un proceso elemental que procesa datos o control de información que proviene desde afuera de la frontera de la aplicación. La primera intención de un EI es mantener uno o más ILF y/o alterar la conducta del sistema

ILFA

ILFBEI

Puntos de función


External Outputs (EO): es un proceso elemental que envía datos o información de control afuera de la frontera de la aplicación. La intención primaria de un EO es presentar información a un usuario mediante procesamiento lógico en vez de o adicionalmente a la recuperación de datos o control de información. La lógica de procesamiento debe contener al menos una fórmula matemática o cálculo o crear datos derivados. Un EO también puede mantener uno o más ILFs y/o alterar la conducta del sistema

Datos derivados

ILFA

ILFB

EO

Puntos de función


External Inquiries (EQ): es un proceso elemental que envía datos o información de control afuera de la frontera de la aplicación. La intención primara de un EQ es presentar información a un usuario a través de la recuperación de datos o información de control desde un ILF o EIF. La lógica de proceso no contiene fórmulas matemáticas ni cálculos y no crea datos derivados. Ningún ILF se mantiene durante el procesamiento ni se altera la conducta del sistema

ILFA

ILFB

EQ

Puntos de función


Internal Logical Files (ILF): es un grupo de datos relacionados lógicamente o de información de control identificable por el usuario mantenida dentro de la frontera de la aplicación

External Interface Files (EIF): es un grupo de datos -identificable por el usuario- relacionados lógicamente o de información de control referenciado por la aplicación, pero mantenido dentro de la frontera del sistema por otra aplicación. Esto significa que un EIF en una aplicación debe ser un ILF en otra aplicación

Puntos de función

Paso 5: clasificación de componentes

Clasificar cada función como de nivel de complejidad baja, promedio o alta, dependiendo del número de tipo de elementos de datos contenidos y el número de tipos de archivos referenciados

Para ILF e EIFElementos de registro

Elementos de datos

1-19 20-50 51+

1 Bajo Bajo Promedio

2-5 Bajo Promedio Alto

6+ Promedio Alto Alto

Puntos de función


Para EO y EQTipos de Archivos Elementos de datos

1-5 6-19 20+

0 ó 1 Alto Alto Promedio



Puntos de función


Para EITipos de archivos Elementos de datos

1-4 5-15 16+

0 ó 1 Bajo Bajo Promedio



Puntos de función

Paso 6: determinar el value adjustment factor (VAF)

- los 14 CGS se deben revisar para asegurar exactitud (a cada CGS se le asigna un valor entre 0 a 5)

- sumar todos los resultados de los CSG, dividir ese número por 100 y sumarle 0,65

- es importante revisar los CSG y VAF, ya que su influencia es de ± 35% en el conteo de FP

0,65 ≤ VAF ≤ 1,35

100

CGS65.0VAF

14

1 i

i

Puntos de función

Paso 7: tabular los resultados

Tipo de componente Complejidad de componentes

Bajo Promedio Alto Total

External Inputs (EI) * 3 = * 4 = * 6 =

External Outputs (EO) * 4 = * 5 = * 7=

External Inquiries (EQ) * 3 = * 4 = * 6 =

Internal Logical Files (ILF)

* 7 = * 10 = * 15 =

External Interface Files (EIF)

* 5 = * 7 = * 10 =

Número total de Unajusted Function Points (UFP)

Multiplied Value Adjustement Factor (VAF)

Total Adjusted Function Points (FP) VAF * UFP

Puntos de función

Paso 8: validar los resultados

Los resultados del conteo de FP deben ser revisados por el equipo entero del proyecto y validado por el coordinador de métricas. Las grandes fuentes de errores en el análisis de FP son errores de omisión. Otros errores surgen cuando construcciones físicas se sustituyen por construciones lógicas y son contadas como componentes. El equipo del proyecto debe revisar el análisis de FP por completitud y debe verificar que todos los componentes (EI, EO, EQ, ILF, and EIF) se han incluido. El coordinador de métricas debe trabajar con el contador de FP para asegurar que el proceso ha sido seguido apropiadamente y se ha seguido el proceso de validación.

Los conteos de FP completados antes del diseño deben ser comparados a los conteos de FP después del diseño completo. Esto será un indicador de cuánto ha crecido la aplicación desde los requerimientos.

La documentación recomendada al final del proyecto o en la implementación del proyecto debe incluir toda la documentacion mencionada o cualquier documentación adicional del sistema.

Puntos de función

Los puntos de función son mejores que los KDSI, pero hay problemas

“Errors in excess of 800% counting KDSI, but only 200% in counting function points”, Jones ’87

Puntos de función

La validez económica de la métrica de punto de función

ACTIVITY CASE A CASE B ASSEMBLER FORTRAN VERSION VERSION (30 F.P.) (30 F.P.) DIFFERENCE -------------- -------------- -------------- Requirements 2 Months 2 Months 0 Design 3 Months 3 Months 0 Coding 10 Months 3 Months - 7 Integration/Test 5 Months 3 Months - 2 User Documentation 2 Months 2 Months 0 Management/Support 3 Months 2 Months - 1 -------------- -------------- -------------- Total 25 Months 15 Months - 10 -------------- -------------- -------------- Total Costs $125,000 $75,000 - $50,000 Cost Per F.P. $4,166.67 $2,500.00 - $1,666.67 F.P. Per Person Month 1.2 2.0 + 0.8

Análisis de puntos de función

Como FFP, la mantención puede medirse en forma inexacta

Es posible hacer cambios grandes sin cambiarel número de archivos, flujos y processes

el número de EI, EO, EQ, ILF, EIF

En teoría, es posible cambiar cada línea de código sin cambiar el número de líneas de código

Otros

MkII FPA, ISO/IEC 20968:2002(E)

COSMIC-FFP, ISO/IEC 19761:2003

Modelos algorítmicos de costos

Costo se estima como una función matemática de atributos del producto, proyecto y proceso

Esfuerzo = A * TamañoB * M

A es una constante dependiente de la organización, B refleja el esfuerzo desproporcionado para proyecto grandes y M es un multiplicador que refleja atributos del producto, proceso y personas

El atributo más usado para estimación de costos es tamaño del código

Modelos de estimación de costos

Clasificación de V. R. Basili (‘80s)

Modelo

DinámicoEstático

Una variable Multivariable

Guiado por tablaajustada

Línea baseajustada

Modelos estáticos: una variable

Modelo SEL, Universidad de Maryland (‘80)

Esfuerzo = 1,4 L0,93 [H-M]

Documentación = 30,4 L0,90 [página]

Duración = 4,6 L0,26 [mes]

L = número de líneas de código fuente (en miles)

Modelos estáticos: multivariable

Walston-Felix, IBM (‘77)

– Esfuerzo = 5,2 L0,91 [H-M]– Duración = 4,1 L0,36 [mes]– L = KLOC entregadas

A estas ecuaciones se les asocia un método para estimar la productividad, este índice usa 29 variables

29

1iiXWI

i


I = índice productividad

Wi = peso para la variable Xi

Xi = {-1,0,1} si decrementa, no tiene efecto o incrementa la productividad.

Esto se aplica a la ecuación de esfuerzo y refina la estimación


Otros– COCOMO– Dot y Associates Model– GRC– …

Modelos dinámicos, multivariable

• Putnam’78: relaciona tamaño, tiempo y costo en la ecuación de software

• Parr’80

El modelo COCOMO

Boehm’s COnstructive COst MOdel

es un modelo empírico basado en experiencia de proyectos

tiene una larga historia desde la versión publicada en 1981 (COCOMO 81) hasta COCOMO II.

COCOMO II toma en cuenta diferentes aproximaciones respecto del desarrollo de software, reuso, etc.

COCOMO 81

Es un modelo que apoya en la planificación de presupuesto y cronograma, antes de iniciar el trabajo

Es un modelo no lineal de una variable

esfuerzo = a * TAMAÑO b

tiempo = c * esfuerzo d

COCOMO 81

Esfuerzo se entrega en unidades [H-M], es decir el número de meses que una persona necesitaría para desarrollar el proyecto

Tipos:• Básico• Intermedio• Detallado

COCOMO 81 básico

Estima rápida y burdamente proyectos pequeños a medianos

3 modos:– orgánico

– semi-desconectado

– empotrado

COCOMO 81 básico

orgánicoprogramadores expertos desarrollan software en ambiente familiar

Em = 2,4 Lk1,05 [H-M]

td = 2,5 Em0,38 [mes]

Lk= miles de líneas fuente entregadas

COCOMO 81 básico

semi-desconectado

mezcla de gente experta e inexperta

Em = 3,0 Lk1,12 [H-M]

td = 2,5 Em0,35 [mes]

COCOMO 81 básico

empotrado

hay fuertes restricciones (procesador y hardware) y no han habido proyectos anteriores comparables

Em = 3,6 Lk1,20 [H-M]

td = 2,5 Em0,32 [mes]

COCOMO 81 básico

promedio de personas

Em / td

COCOMO 81 intermedio

En, esfuerzo nominal

• Orgánico– En = 3,2 Lk

1,05 [H-M]• Semi-desconectado

– En = 3,0 Lk1,12 [H-M]

• Empotrado– En = 2,8 Lk

1,20 [H-M]• 15 multiplicadores de esfuerzo afectan En

entregando Et

• td = 2,5 Et0,32


EjemploUn sistema de comunicaciones hecho en microprocesadores en red y como requerimientos de desarrollo, rendimiento e interfaces modo empotrado10000 líneas de código fuente entregadas 10 KDSI

Esfuerzo nominal: En = 2,8 (10)1,20 = 44 [H-M]

Et = En * (multiplicadores de esfuerzo)


multiplicadores de esfuerzo

Atributos del producto: restricciones y requerimientos para el proyecto

– confiabilidad requerida del software (RELY)– tamaño de la base de datos (DATA)– complejidad del producto (CPLX)



Atributos del computador: limitaciones del hardware y sistema operativo

– restricción del tiempo de ejecución (TIME)– restricción de almacenamiento principal (STOR)– volatilidad de la máquina virtual (VIRT)– tiempo turnaround del computador (TURN)



Atributos del personal: nivel de habilidad

– capacidades de analista (ACAP)– experiencia en aplicaciones (AEXP)– capacidades de programador (PCAP)– experiencia en máquina virtual (VEXP)– experiencia en lenguaje de programación (LEXP)



Atributos del proyecto: restricciones y condiciones respecto del desarrollo del proyecto

– prácticas modernas de programación (MODP)– uso de herramientas de software (TOOL)– cronograma de desarrollo requerido (SCED)


Estos 15 multiplicadores se clasifican como muy bajo, bajo, nominal, alto, muy alto y extra alto.

Una valor menor que 1 puede decrementar el cronograma y esfuerzo, un valor mayor que 1 extiende el cronograma o esfuerzo.


multiplicadores de esfuerzoMuy bajo Bajo Nominal Alto Muy alto Extra alto

RELY 0.75 0.88 1.00 1.15 1.40

DATA 0.94 1.00 1.08 1.16

CPLX 0.70 0.85 1.00 1.15 1.30 1.65

TIME 1.00 1.11 1.30 1.66

STOR 1.00 1.06 1.21 1.56

VIRT 0.87 1.00 1.15 1.30

TURN 0.87 1.00 1.07 1.15

ACAP 1.46 1.19 1.00 0.86 0.71

AEXP 1.29 1.13 1.00 0.91 0.82

PCAP 1.42 1.17 1.00 0.86 0.70

VEXP 1.21 1.10 1.00 0.90

LEXP 1.14 1.07 1.00 0.95

MODP 1.24 1.10 1.00 0.91 0.82

TOOL 1.24 1.10 1.00 0.91 0.83

SCED 1.23 1.08 1.00 1.04 1.10


Costo Situación Rating Multiplicador

Configuración del software requerido Serias consecuencias financieras o fallas de software Alto 1,15

Tamaño de la base de datos 20.000 bytes bajo 0,94

Complejidad producto Procesamiento de comunicaciones muy alto 1,30

.

.

.

.

.

.

.

.

.

.

.

.

TOTAL 1,35

Ejemplo

Esfuerzo nominal: En = 2,8 (10)1,20 = 44 [H-M]

Et = En * multiplicadores

Et = 44 * 1,35 = 59 [H-M]

td = 2,5 Et0,32 = 9,21 [M]

COCOMO 81 detallado

No se verá

clase 6, 5/9/2007

Technology