Upload
christian-sifaqui
View
2.622
Download
0
Embed Size (px)
Citation preview
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
Paso 4: inventario de transacciones y archivos
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
Paso 4: inventario de transacciones y archivos
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
Paso 4: inventario de transacciones y archivos
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
Paso 4: inventario de transacciones y archivos
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
Paso 5: clasificación de componentes
Para EO y EQTipos de Archivos Elementos de datos
1-5 6-19 20+
0 ó 1 Alto Alto Promedio
2-3 Bajo Promedio Alto
4+ Promedio Alto Alto
Puntos de función
Paso 5: clasificación de componentes
Para EITipos de archivos Elementos de datos
1-4 5-15 16+
0 ó 1 Bajo Bajo Promedio
2-3 Bajo Promedio Alto
4+ Promedio Alto Alto
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
Modelos estáticos: multivariable
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
Modelos estáticos: multivariable
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
COCOMO 81 intermedio
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)
COCOMO 81 intermedio
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)
COCOMO 81 intermedio
multiplicadores de esfuerzo
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)
COCOMO 81 intermedio
multiplicadores de esfuerzo
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)
COCOMO 81 intermedio
multiplicadores de esfuerzo
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)
COCOMO 81 intermedio
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.
COCOMO 81 intermedio
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
COCOMO 81 intermedio
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á