Upload
faber-d-giraldo
View
1.274
Download
2
Embed Size (px)
DESCRIPTION
Citation preview
Estimación de tamaño, costos y
esfuerzos
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
Reconocimientos
• Material preparado por profesor Sergio Ochoa
(Universidad de Chile) a partir del notas de clase
• Prof. Jaime Navón (www2.ing.puc.cl/~jnavon).
• Prof. Sergio Ochoa
(http://www.dcc.uchile.cl/~sochoa/)
• Material adaptado y complementado por la
profesora Raquel Anaya (Universidad EAFIT)
• Versión 3.0: Fáber Giraldo
Evaluar, calcular, dar valor a una actividad
de manera anticipada.
¿Qué es estimar?
¿Cómo estimas el tiempo que requieres
para preparar un parcial? ¿Cuánto tiempo estimas para
Ir de tu casa a la universidad?
¿Estimación intuitiva o basada en datos?
¿Qué tan precisa es la estimación?
• La estimación forma parte de la planificación de un proyecto
• Permite resolver tres preguntas básicas para el
desarrollo del software
– ¿Cuánto esfuerzo (Por ejemplo Horas-Hombre)se requiere para desarrollarlo?
– ¿Cuánto tiempo, de calendario, se necesita para
realizarlo?
– ¿Cuál es el costo total?
¿Por qué es importante la estimación de un
proyecto de software?
1. Desestimar el tiempo y esfuerzo necesario para hacer una buena
estimación.
2. Requisitos imprecisos. Requisitos van creciendo.
3. Muchas veces el plazo de desarrollo es fijado por gente del área
comercial o por ejecutivos, sin efectuar ningún tipo de cálculo serio.
4. El tamaño suele ser estimado por debajo.
5. Estimaciones forzadas por los recursos disponibles (Si hay que
acabar el proyecto en 12 meses y se dispone de 5 técnicos, se
estima en esfuerzo como 60 técnicos-día).
6. Usar la estimación del precio ganador. Estimar de acuerdo a lo que el
cliente esta dispuesto a pagar por el proyecto.
7. Cuando finaliza el proyecto, no hay tiempo de analizar los valores
estimados contra los valores reales.
Errores mas frecuentes al estimar (Sommeville)
Ejercicio – Estimación del Esfuerzo
En forma INDIVIDUAL….
Estime el esfuerzo de desarrollo del sistema de stock, para una Farmacia… El sistema debe llevar:
Los artículos (con el stock actual, ingresos y egresos).
Los proveedores.
Dos tipos de usuarios (actualizador y consultor).
En forma INDIVIDUAL….
Estime el esfuerzo de desarrollo del sistema de stock
Guarde el detalle de su estimación, pues loutilizaremos más adelante.
Entregue al profesor un papel anónimo con elnúmero total de Horas-Hombre (HH) delproyecto.
Ejercicio – Estimación del Esfuerzo
¿Qué debo hacer para poder
gestionar mis proyectos
de desarrollo?
Si no puedes medir
no puedes controlar
Tipos de Medidas
Medida directa, indirecta o predicción
Medida directa: se observa la entidad y se aplica el
instrumento de medida directamente (peso,
estatura).
Medida indirecta: se mide en forma directa otra entidad (o
más de una) y luego se usan relaciones conocidas
entre ellas (velocidad = distancia/tiempo).
Predicción: queremos estimar una característica (por ej.
tamaño) de una entidad que puede no existir en
este momento.
Similar a medición indirecta!
• Establecer una conexión ó relación entre las
entidades medidas directamente y las entidades cuya
medida será predicha.
• Refinar la conexión ó relación hasta llegar a una o más
fórmulas que permitan traducir las medidas directas en
predicciones confiables (medidas indirectas
aproximadas).
La diferencia clave está en que en la predicción no es
posible establecer una conexión completa => sólo se
puede aproximar a la medida correcta.
Predicción
Predicción
Similar a medición indirecta !
Sólo es posible predecir si tenemos buenas medidas en
qué basarnos!
A pesar de lo obvio de esta afirmación muchas veces
los administradores muestran gran interés en
estimación, pero no en mediciones de software.
El esfuerzo de estimar el desarrollo de un software,
siempre es una actividad de PREDICCION. La
predicción precisa requiere medición cuidadosa de
atributos claves en proyectos ya completados.
Predicción en software
Similar al proceso de diagnóstico de un médico.
El médico se basa en los análisis o estudios (medidas directas) y en su experiencia en casos anteriores o documentación relevante (relación entre medidas directas e indirectas) para poder realizar un diagnóstico y proponer una solución (estimación del proyecto de solución).
– Muchas veces se requiere una interconsulta, para determinar la relación entre las medidas directas y las indirectas (chequeo con pares).
El Reto de la Estimación de Software
Estimar es un proceso con incertidumbre:Nadie conoce cuál será el tamaño final del productoLa estimación es mas incierta cuanto más temprano
se hagaLa estimación puede estar sesgada por el negocio y
por otras presionesEstimar es un proceso de aprendizaje
La habilidad para estimar mejora con la experienciaLa estimación es mas confiable si se apoya en datos históricos Los métodos son poco usados en la industriaNo se tiene la disciplina de la medición
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
Aproximaciones para Estimar(Nasir, M. Ahmad, F, 2006)
• Aproximaciones heurísticas: Basadas en la experiencia de las personas
y orientadas a su aprendizaje. Algunos ejemplos: Juicio de Experto,
Técnica Delphi, Técnica Delphi de Banda Ancha, Ley de Parkinson, Planing
poker.
• Aproximaciones paramétricas: Utiliza modelos de predicción obtenidos a
partir de datos históricos. Generalmente son modelos utilizados para
predecir el esfuerzo en función del tamaño. Algunos ejemplos: Líneas
de código, Puntos de Función con sus variantes, COCOMO y COCOMO-II, Puntos de Objeto, Puntos de casos de uso.
• Aproximaciones no paramétricas (Capretz,Marza, 2009): Soportadas en
algoritmos o modelos matemáticos: Algunos ejemplos: Modelo de lógica
difusa, modelo de red neuronal, modelo NeuroFuzzy, modelo de regresión múltiple, modelo estadístico.
Aproximaciones Heurísticas
• Juicio de experto: Basado en la experiencia de las personas y orientadas
a su aprendizaje
• Técnica Delphi: Es una técnica de grupo que extrae y resume el conocimiento del grupo para arribar a una estimación.
• Técnica de tres puntos: Utiliza tres 3 estimaciones de la duración de la
actividad: optimista, pesimista, media. Estimación final = (optimista + 4*
media + pesimista) /6
• Técnica Delphi de Banda Ancha (Wideband-Delphi): Es una
combinación de la técnica Delphi y la de tres puntos.
• Planning Poker: Técnica usada en estimación en conjunción con Delphide Banda Ancha, para lograr consenso de estimaciones de tamaño de los
requisitos de un proyecto de una manera rápida y ágil
• Ley de Parkynson: El proyecto cuesta según los recursos disponibles y el
ciclo de vida del proyecto se expandirá según el número de recursos disponibles en la organización
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
Estimación Delphi de Banda Ancha
Originado en Rand Corporation, perfeccionado por B.Boehm.
Variante del método Delphi que promueve mayor interacción entre losparticipantes.
La idea fundamental es usar varios expertos que hacen estimacionesindependientes y luego convergen hacia una estimación única. Lospasos generales del método son:
1. Cada experto recibe las especificaciones del programa y unformulario de estimación.
2. Se reúnen a conversar sobre suposiciones, dudas, etc.
3. Cada miembro del equipo (por separado): a) lista las macro-tareasb) produce tres estimaciones: optimista (todo sucede según laplaneado), promedio (duración usual de la actividad), pesimista(falla todo aquello que se prevé que pueda fallar)
Estimación Delphi de Banda Ancha (cont.)
4. Las estimaciones son recogidas por un moderador quien tabula los resultados y obtiene un promedio de las estimaciones pesimista, optimista, mediana y un promedio general utilizando la fórmula de los tres puntos:
Promedio general: (optimista + 4* media + pesimista) /6
5. Se reúnen nuevamente, se entregan los resultados y discuten las tareas (si no hay consenso).
6. Se vuelve a la tercera etapa (nueva estimación).
Repita el Ejercicio – Estimación del Esfuerzo
Usando Wideband-Delphi, en grupos de 4-5 personas….
En grupo: Resuelvan dudas y hagan suposiciones sobre
la estimación (2 minutos)
Individual: Haga una lista de tareas y Vuelva a estimar el
tiempo (pesimista, optimista, medio) de desarrollo del
sistema de stock (3 minutos).
En grupo: Obtengan el promedio general según el paso 4.
Cada grupo entrega al profesor un papel anónimo con el
número total de Horas-Hombre (HH) del proyecto (2
minutos).
Consideraciones para la aplicación
del método Delphi de Banda Ancha
Las discusiones entre los expertos a menudo clarifican aspectos y producen cambios en las estimaciones para la etapa siguiente.
El método produce estimaciones bastante precisas…pero es caro y lento.
El costo depende de lo que a usted le cuesten los expertos… y de cuán alineados estén ellos respecto de sus estimaciones.
Usted podría aplicar esto en su organización, utilizando a sus colegas como posibles expertos.
Ojo: las estimaciones grupales heurísticas son
la base de los métodos ágiles de estimación!!!
• Planning Poker
• Team Sort (T-Shirt Sizing)
• One Point One Card (Lean)
Ver más info en
http://agile.dzone.com/articles/agile-estimation-practice
El principio de los modelos Paramétricos
Estos modelos utilizan fórmulas derivadas empíricamente para predecir los datos que se requieren para la
planificación del proyecto de software:
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
Aproximaciones Paramétricas:
El Modelo COCOMO
Ejemplo 1: El modelo COCOMO simple relaciona el esfuerzo E (meses-hombre) con el tamaño S (MLOCS) y el tiempo con el esfuerzo de acuerdo a:
E (esfuerzo) = a * Sb
T (tiempo) = p * Et
Donde a, b, p y t son parámetros determinados por el tipo de software a ser desarrollado (están tabulados en bases a estudios estadísticos).
Para usar este modelo para predecir el esfuerzo en la etapa de captura de requisitos, necesitamos primero determinar (predecir) los parámetros y luego el tamaño del eventual sistema.
El Modelo COCOMO
Los modelos COCOMO están definidos para tres tipos de
proyectos de software:
(1) modo orgánico: proyectos relativamente pequeños y
sencillos en los que trabajan pequeños equipos, con buena
experiencia en la aplicación, sobre un conjunto de requisitos poco
rígidos;
(2) modo semiacoplado: proyectos intermedios (en tamaño
y complejidad) en los que equipos, con variados niveles de
experiencia, deben satisfacer requisitos poco o medio rígidos;
(3) modo empotrado: proyectos que deben ser
desarrollados en un conjunto de hardware, software y
restricciones operativas muy restringido.
El Modelo COCOMO
Modelos como COCOMO no consideran las
particularidades de cada equipo de desarrollo.
El modelo COCOMO Intermedio y Avanzado
introducen un multiplicador:
E (esfuerzo) = a * Sb * m(x)
T (tiempo) = p * Et
M(x) en un multiplicador que depende de 15 puntos
Mediciones de Software
Multiplicadores para COCOMO:
(1) Atributos del producto
• RELY: garantía de funcionamiento requerida al software
• DATA: tamaño de la base de datos
• CPLX: complejidad del producto
(2) Atributos del computador (Server)
• TIME: restricción de tiempos de ejecución (Tiempo de Servicio y Uptime)
• STOR: restricción del almacenamiento principal
• VIRT: volatilidad de la máquina virtual
• TURN: tiempo de respuesta del computador
(3) 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 el lenguaje de programación
(4) Atributos del proyecto
• MODP: prácticas de programación modernas
• TOOL: utilización de herramientas software
• SCED: plan de desarrollo requerido
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
Modelo de Puntos de Función
Albrecht (IBM, 1979) desarrolló la idea de Puntos de Función
(FPs).
La métrica de Puntos de Función sirve para establecer el
tamaño y complejidad de los sistemas informáticos basada
en la cantidad de funcionalidad requerida y entregada a los
usuarios” (ISO Bulletin May 2003).
Es uno de los modelos de predicción más populares y se
encuentran homologados con el ISO
Modelo de Puntos de Función
The terms functional size (FS), functional size measurement
(FSM), and functional user requirements (FUR) are defined by
the ISO/IEC 14143-1:2007 Functional Size Measurement: Part 1
Definition of Concepts: (ISO/IEC, 2007)
ISO/IEC 14143-6:2006. Information technology—Software
measurement— Functional size measurement—Part 6: Guide
for use of ISO/IEC 14143 series and related International
Standards.l
Modelo de Puntos de Función
Existen diferentes variantes de método:◦ ISO/IEC 20926:2003. IFPUG 4.1 Unadjusted functional size
measurement method. Es el mas conocido y utilizado en Estados
Unidos
◦ ISO/IEC 24570. NESMA -- Function Point Analysis. Estándar
definido para NEtherlands Software Metrics Users Association. Esta
es una pequeña variante del método del IFPUG
◦ ISO/IEC 20968:2002. Mk II Function Point Analysis. Desarrollado
por la United Kingdom Software MetricsAssociation, simplificando el
método y haciéndolo compatible con ideas de análisis y diseño
estructurado
◦ ISO/IEC 19761:2003. COSMIC-FFP - integrado por expertos de
Europa y Canadá, para adecuarlo a sistemas en tiempo real
Modelo de Puntos de Función
La propuesta original identifica 5 tipos de funciones básicas
Funciones transaccionales:
Inputs: Entrada externa. Proceso para mantener uno o mas archivos lógicos internos. Cuenta las pantallas o formularios usados para captura. Ejemplos:
- Ingresar un nuevo producto
- Ingresar el pedido de un cliente
Outputs: Salida Externa. Proceso para presentar información al usuario que requiere operaciones adicionales al de solo recuperar datos . Cuenta pantallas o reportes que la aplicación produce. Ejemplos:
- Informe semanal de ventas
- Lista de pedidos pendientes por despachar
Consultas. Procesos para presentar información leída de uno o más grupos de datos (no requieren procesamiento adicional). Ejemplos:
- Consultar estado de un pedido
- Consultar existencia de un producto
Modelo de Puntos de Función
La propuesta original identifica 5 tipos de funciones básicas
Funciones de Datos:
Archivo Lógico Interno: número de almacenamiento de datos mantenidos a través de alguna transacción. Ejemplos:
Entidad pedido
Entidad producto
Entidad detalle de pedidos
Interfaces. Archivo de interfaz externa. Grupos de datos relacionados y referenciados que son mantenidos por otro sistema (archivos compartidos de entrada o salida, parámetros, etc). Ejemplos:
Entidad Cliente (el cliente es consultado desde un sistema externo)
Interfaz con componente de mensajería (se invocan servicios de mensajería)
Modelo de Puntos de Función
Número Tipo Peso Total
8 Inputs (EI) x4 32
12 Outputs (EO) x5 60
4 Consultas (EQ) x4 16
2 Archivos (ILF) x10 20
1 Interfaz (EIF) x7 7
Total Sin Ajustar: 135 PF
Factor de Complejidad: 1.06
Puntos de Función: 143 PF
El modelo define un peso diferente (PF) para cada tipo de función básica
Peso asignado a cada
tipo de función según
datos históricos
(viene dado por el modelo)
Valores estimados
según descripción
del sistema
Identificando la Función Básica
Tomado de S. E. Durán “Puntos por Función Una métrica
estándar para establecer el tamaño del software”. Boletín de
Política Informática Núm. 6, 2003
Factor de Complejidad
Para calcular el factor de complejidad se consideran 14
aspectos, otorgándosele a cada uno, una influencia de 0 a
5, generándose así un puntaje que va de 0 a 70.
El factor de complejidad estará dado por:
FC = 0.65 + 0.01 * Puntaje
El FC se mueve en el rango de 0.65 hasta 1.35.
Esto contempla hasta un 35% de aumento o reducción del
esfuerzo de desarrollo.
Factor de Complejidad
Los factores que influencian la complejidad son:
- Comunicaciones. - Funciones distribuidas.
- Objetivos de desempeño - Configuración. (sobrecarga).
- Tasa de transacciones. - Entrada de datos on-line
- Eficiencia para usuario. - Actualización en línea.
- Proceso complejo. - Reuso.
- Facilidad de instalación. - Facilidad de operación.
- Varios sitios. - Facilidad de mantención
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
41
Componentes Estándares
El método de Componentes
Estándares: se basa en la
premisa de que nosotros no
reinventamos la rueda en
cada proyecto, sino que más
bien reproducimos nuestras
soluciones exitosas.
Ejemplos de Componentes Estándares
42
Ejemplos de Componentes
Estándares son:• Mantenedores (Operaciones
básicas sobre entidades de
referencia).
• Transacciones (Actualizaciones
sobre mas de una entidad, que contempla reglas de negocio)
• Menús de Navegación.
• Consultas de registros individuales
• Consultas de múltiples registros.
• Informes por Impresora.
• Procesos en Background.
• Notificaciones..
• Autorización / Autenticación
43
Componentes Estándares
El método de Componentes Estándares se basa en mantener
una base de datos histórica con información de componentes
usados en proyectos previos, en varios niveles de abstracción:
subsistemas completos, módulos, interfaces de usuario, etc.
Se estima cuántos componentes estándares habrá, por cada
tipo, en el nuevo proyecto, utilizando puntos (estimado,
máximo y mínimo).
Se combina esto, ponderando 4 veces el más probable
(estimado) y una vez el máximo y el mínimo: (4*est + máx +
min) / 6.
Ejemplo:
Componente LOC min est max prob LOC
Módulo A 932 11 18 22 17.5 16310
Módulo B 543 35 40 44 39.8 21611
... ... ... ... ... ...
... ... ... ... ... ...
Total: 546359
… Se puede o no llevar esta estimación a líneas de código. 44
Componentes Estándares
45
Componentes Estándares y FPs
El primer desafío es construir y mantener esta tabla:
Componente FP
Mantenedor………………….. 5
Transacciones…………………7
Menu/navegación…...…..….. 6
Consultas……………...…..… 2
Informes por Impresora.….... 2
Procesos en Background….. 8
Notificaciones………………. 2
Autorización / Autenticación. 3
46
Componentes Estándares y FPs
El segundo desafío es ponerle costos y tiempos:
Componente FP Costo Tiempo
Mantenedor………………… 5 M$ 750 100HH
Menu/navegación…...…….. 7 M$1050 140HH
Consultas……………...…… 2 M$ 300 40HH
Informes por
Impresora…………………...2 M$ 300 40HH
Procesos en Background… 8 M$1200 160HH
Tablas………………………. 1 M$ 150 20HH
Notificaciones……………… 2 M$ 300 40HH
Aut./Autenticación ………… 3 M$ 450 60HH
Ref: 1 PF = $150.000 = 20HH
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
Aplicación de los métodos de estimación
• Cada uno de nosotros tiene que construir su propio sistema de
predicción de costos.
• Podemos inventar uno nuevo, o modificar o parametrizar alguno
ya existente.
• Lo importante es que el sistema de predicción nos represente
(tenga en cuenta nuestra realidad).
• También hay que identificar la precisión y el contexto en el cual
mi sistema arroja valores creíbles (tamaño y tipo de proyectos,
tamaño de grupos, etc.).
Validación de la Predicción
Validación de un Sistema de Predicción
• Se debe establecer empíricamente la precisión de la predicción (comparando el modelo con puntos conocidos).
• Involucra experimentación y testeo de la relación entre las variables observadas.
Validación de una Medida
• Se debe asegurar que la medida es una caracterización numérica adecuada del atributo en cuestión.
La Validación genera confianza en el sistema
¿Qué y cómo medir? He aquí el dilema…
Medir sólo aquellos aspectos del proceso o del producto, que son relevantes para mi.
¿Relevantes para qué?
• Mejorar mi proceso
• Mejorar mis productos
• Mejorar mis estimaciones
Guardar información para todo esto puede ser una tarea demasiado pesada, y podría entorpecer los desarrollos.
Medir y guardar la información, sólo si yo soy capaz de confiar en ella.
Las mediciones no deberían entorpecer el trabajo de la gente.
Dominio de Mediciones
¿Medir para Mejorar? o ¿para Estimar Mejor?
Medir cada fase (Análisis, Diseño, ….) => Medir para mejorar.
Medir a paquete completo (el proyecto como un todo) => Medir para estimar mejor.
52
¿Cómo saber cuánto le cuesta a mi equipo de trabajo implantar un FP?
1. Arme y valide su tabla de componentes estándares.
2. Busque en su información histórica (de los contratos): tiempo total y costo
total de un proyecto.
3. Haga una tabla con la distribución de componentes estándares que usted
tiene en cada proyecto:
Componente PF x Unidad Cant. PF Total
Mantenedor 5PF 20 100PF
Menu/Navegac. 7PF 3 21PF
Consultas 2PF 10 20PF
Reportes Impres. 2PF 3 6PF
Proc.Background 8PF 7 56PF
Tablas 1PF 20 20PF
TOTAL 223PF
Entendiendo la historia
53
¿Cómo saber cuánto le cuesta a mi organización implantar un FP?
4. Divida el costo total del proyecto por los PFs asociados al él. Por ejemplo:
Costo PF = $ 38.000.000 / 223 PF = $ 170.403
5. Divida la cantidad total de HH del proyecto por los PFs asociados al él. Por ejemplo:
Tiempo PF = 5.320HH / 223 PF = 23,9 HH
- Estos valores son referenciales y dependen del tamaño ycaracterísticas del equipo de trabajo.
- Cuanto más muestras estadísticas tenga, más ajustados estaránmis números.
Entendiendo la historia
54
¿Cómo saber cuál es la velocidad de desarrollo (aprox.) de un equipode mi organización?
En proyectos terminados, divida la cantidad total de HH del proyectopor el tiempo lineal de duración del proyecto (en horas). Por ejemplo:
Veloc. Desarr. = 5.320HH / 4.5 meses
= 5.320HH / 720 Horas = 7.4
NOTA: Este valor no tiene unidad, sin embargo puede entendersecomo si fuera “velocidad de desplazamiento” del proyecto.
- Estos valores también son referenciales, y deben manejarse dentrodel mismo contexto.
Entendiendo la historia
55
Entendiendo la historia
Para que los datos históricos sean válidos o tengan alguna utilidad:
1. El tamaño y composición del equipo de trabajo debe ser similar.
2. Si no es similar, debemos conocer la relación aproximada entre los escenarios anteriores y el actual.
3. La información histórica deberá ser creíble para las personas.
4. Deberá estar disponible (tal vez en carpetas) la información histórica detallada usada como base.
5. El producto a desarrollar deberá ser de un tipo, tamaño y complejidad acorde a nuestras experiencias previas.
56
Conclusiones Finales
• Los modelos de estimación son útiles pero deben ser adaptados a las condiciones de cada empresa / proyecto.
• Una de las competencias que debo adquirir como desarrollador es poder estimar el esfuerzo invertido en el desarrollo de una aplicación.
• Se necesita disciplina para crear información histórica de mi desempeño como desarrollador
57
Consideraciones Finales
• Es indispensable contar con los datos históricos deproyectos de la organización, sin embargo, es muyfrecuente encontrar que las compañías no facilitan elacceso a los mismos debido a que esta información escrítica.
• Se cuenta con algunas bases de datos internacionalesque guardan información histórica de proyectos y quepodrían servir como referentes para afinar el modelopropio.
• Es importante realizar estudios para caracterizar losproyectos de la industria de software latinoamericana
Agenda
• Introducción
• Métodos de Estimación
• Método Delphi de Banda Ancha
• Método COCOMO
• Método de Puntos de Función
• Método de Componentes Estándares
• Consideraciones para adopción de métodos en la
industria
• Explicación de la práctica
• Ian Sommerville. Ingenieria De Software. 7ª Edición. México : Pearson
Educacion, 2005. Capítulo 25
• Nasir, M. Ahmad, F. “An Empirical Study to Investigate Software Estimation Trend in Organizations Targeting CMMI”. Proceedings of the 5th IEEE/ACIS
International Conference on Computer and Information Science and 1st
IEEE/ACIS International Workshop on Component-Based Software
Engineering, Software Architecture and Reuse, 2006.
• S.E. Durán Rubio. Puntos por Función. Una métrica estándar para
establecer el tamaño del software. Boletín de Política Informática Num 6,
2003.
• L. F. Capretz, V. Marza. Improving Effort Estimation by Voting Software EstimationModels. Advances in Software Engineering Volume 2009, Article
ID 829725, 8 pages
Bibliografía
• http://www.javiergarzas.com/2012/03/puntos-funcion.html
• http://www.ibm.com/developerworks/rational/library/edge/09/mar09/collaris_
dekker/
• http://www.ifpug.org/
• http://www.devdaily.com/FunctionPoints/
More…