1. El documento presenta diferentes métodos para estimar el tamaño, costos y esfuerzos de proyectos de desarrollo de software, incluyendo el método Delphide Banda Ancha, el modelo COCOMO y el método de Puntos de Función. 2. También discute consideraciones importantes para la adopción de métodos de estimación en la industria, como la necesidad de mediciones confiables y el reto de predecir con incertidumbre. 3. Explica conceptos clave como la diferencia entre medición directa, indirecta y predic

1. Estimación de tamaño, costos y esfuerzos

2. •Introducción
•Métodos de Estimación
•Método Delphide 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

3. Reconocimientos
•MaterialpreparadoporprofesorSergioOchoa(UniversidaddeChile)apartirdelnotasdeclase
•Prof. Jaime Navón(www2.ing.puc.cl/~jnavon).
•Prof. Sergio Ochoa (http://www.dcc.uchile.cl/~sochoa/)
•MaterialadaptadoycomplementadoporlaprofesoraRaquelAnaya(UniversidadEAFIT) ranaya@eafit.edu.co.
•Versión3.0:FáberGiraldo

4. 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?

5. •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 costototal?
¿Por qué es importante la estimación de un proyecto de software?

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

7. Ejercicio–Estimacióndel Esfuerzo
En forma INDIVIDUAL….
Estime el esfuerzode 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).

8. En forma INDIVIDUAL….
Estime el esfuerzode desarrollo del sistema de stock
Guardeeldetalledesuestimación,puesloutilizaremosmásadelante.
EntreguealprofesorunpapelanónimoconelnúmerototaldeHoras-Hombre(HH)delproyecto.
Ejercicio–Estimacióndel Esfuerzo

9. ¿Qué debo hacer para poder gestionar mis proyectos
de desarrollo?
Si no puedes medir
no puedes controlar

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

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

12. Predicción
Similar a medición indirecta !
Sóloesposiblepredecirsitenemosbuenasmedidasenquébasarnos!
Apesardeloobviodeestaafirmaciónmuchasveceslosadministradoresmuestrangraninterésenestimación,peronoenmedicionesdesoftware.
Elesfuerzodeestimareldesarrollodeunsoftware, siempreesunaactividaddePREDICCION.Lapredicciónprecisarequieremedicióncuidadosadeatributosclavesenproyectosyacompletados.

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

14. El Reto de la Estimación de Software
Estimar es un proceso con incertidumbre:
Nadie conoce cuál será el tamaño final del producto
La estimación es mas incierta cuanto más temprano se haga
La estimación puede estar sesgada por el negocio y por otras presiones
Estimar es un proceso de aprendizaje
La habilidad para estimar mejora con la experiencia
La estimación es mas confiable si se apoya en datos históricos
Los métodos son poco usados en la industria
No se tiene la disciplina de la medición

15. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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

16. 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 Delphide Banda Ancha, Ley de Parkinson, Planingpoker.
•Aproximaciones paramétricas: Utiliza modelos de predicción obtenidos a partir de datos históricos. Generalmente sonmodelos utilizados para predecir el esfuerzoen 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.

17. 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 Delphide Banda Ancha (Wideband-Delphi): Es una combinación de la técnica Delphiy la de tres puntos.
•PlanningPoker: Técnicausada 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

18. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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

19. Estimación Delphide Banda Ancha
Originado en Rand Corporation, perfeccionado por B.Boehm.
VariantedelmétodoDelphiquepromuevemayorinteracciónentrelosparticipantes.
Laideafundamentalesusarvariosexpertosquehacenestimacionesindependientesyluegoconvergenhaciaunaestimaciónúnica.Lospasosgeneralesdelmétodoson:
1.Cadaexpertorecibelasespecificacionesdelprogramayunformulariodeestimación.
2.Sereúnenaconversarsobresuposiciones,dudas,etc.
3.Cadamiembrodelequipo(porseparado):a)listalasmacro-tareasb)producetresestimaciones:optimista(todosucedesegúnlaplaneado),promedio(duraciónusualdelaactividad),pesimista(fallatodoaquelloqueseprevéquepuedafallar)

20. Estimación Delphide 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).

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

22. Consideraciones para la aplicación
del método Delphide 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.

23. Ojo: las estimaciones grupales heurísticas son
la base de los métodos ágilesde estimación!!!
•Planning Poker
•Team Sort (T-Shirt Sizing)
•One Point One Card (Lean)
Vermásinfo en
http://agile.dzone.com/articles/agile-estimation-practice

24. 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:

25. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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

26. Aproximaciones Paramétricas:
El Modelo COCOMO
Ejemplo 1: El modelo COCOMOsimple 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.

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

28. El Modelo COCOMO
Modelos como COCOMO no consideran las particularidades de cada equipo de desarrollo.
El modelo COCOMOIntermedio 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

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

30. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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

31. Modelo de Puntos de Función
Albrecht(IBM,1979)desarrollólaideadePuntosdeFunció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 BulletinMay2003).
Es uno de los modelos de predicción más populares y se encuentran homologados con el ISO

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

33. Modelo de Puntos de Función
Existen diferentes variantesde método:
◦ISO/IEC 20926:2003. IFPUG 4.1 Unadjustedfunctionalsizemeasurementmethod. Es el mas conocido y utilizado en Estados Unidos
◦ISO/IEC 24570. NESMA--FunctionPoint Analysis. Estándar definido para NEtherlandsSoftware MetricsUsersAssociation. Esta es una pequeña variante del método del IFPUG
◦ISO/IEC 20968:2002. MkII FunctionPoint Analysis. Desarrollado por la UnitedKingdomSoftware 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

34. 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. Cuentapantallas 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

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

36. Modelo de Puntos de Función
NúmeroTipoPesoTotal
8Inputs (EI) x432
12Outputs (EO) x560
4Consultas (EQ) x416
2 Archivos (ILF) x1020
1 Interfaz (EIF) x77
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

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

38. 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 puntajeque 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.

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

40. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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. 41
Componentes Estándares
ElmétododeComponentesEstándares:sebasaenlapremisadequenosotrosnoreinventamoslaruedaencadaproyecto,sinoquemásbienreproducimosnuestrassolucionesexitosas.

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

44. Ejemplo:
Componente LOC min estmaxprobLOC
Módulo A 932 11 18 22 17.516310
Módulo B 543 35 40 44 39.821611
... ... ... ... ......
... ... ... ... ... ...
Total: 546359
… Se puede o no llevar esta estimación a líneas de código. 44
Componentes Estándares

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

47. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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

48. Aplicación de los métodos de estimación
•Cadaunodenosotrostienequeconstruirsupropiosistemadeprediccióndecostos.
• Podemos inventar uno nuevo, o modificar o parametrizaralguno ya existente.
•Loimportanteesqueelsistemadepredicciónnosrepresente(tengaencuentanuestrarealidad).
•Tambiénhayqueidentificarlaprecisiónyelcontextoenelcualmisistemaarrojavalorescreíbles(tamañoytipodeproyectos, tamañodegrupos,etc.).

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

50. ¿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.

51. Dominio de Mediciones
¿Medir para Mejorar? o ¿para Estimar Mejor?
Medir cada fase (Análisis, Diseño, ….) => Medir para mejorar.
Medira paquetecompleto(el proyectocomoun todo) => Medirparaestimarmejor.

52. 52
¿Cómosaber cuántole cuesta a mi equipode trabajoimplantarun FP?
1.Armey validesutablade componentesestándares.
2.Busqueen suinformaciónhistórica(de los contratos): tiempototal y costototal de un proyecto.
3.Hagaunatablacon la distribuciónde componentesestándaresqueustedtieneen cadaproyecto:
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
Entendiendola historia

53. 53
¿Cómosaber cuántole cuestaa mi organizaciónimplantarun FP?
4. Dividael costototal del proyectoporlos PFs asociadosal él. Porejemplo:
CostoPF = $ 38.000.000 / 223 PF = $ 170.403
5. Dividala cantidadtotal de HH del proyectoporlos PFs asociadosal él. Porejemplo:
TiempoPF = 5.320HH / 223 PF = 23,9 HH
-Estosvaloressonreferencialesydependendeltamañoycaracterísticasdelequipodetrabajo.
-Cuantomásmuestrasestadísticastenga,másajustadosestaránmisnúmeros.
Entendiendo la historia

54. 54
¿Cómosaber cuálesla velocidadde desarrollo(aprox.) de un equipode mi organización?
Enproyectosterminados,dividalacantidadtotaldeHHdelproyectoporeltiempolinealdeduracióndelproyecto(enhoras).Porejemplo:
Veloc. Desarr. = 5.320HH / 4.5 meses
= 5.320HH / 720 Horas= 7.4
NOTA: Este valor no tieneunidad, sin embargo puedeentendersecomosifuera“velocidadde desplazamiento” del proyecto.
-Estosvalorestambiénsonreferenciales,ydebenmanejarsedentrodelmismocontexto.
Entendiendola historia

55. 55
Entendiendola 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. 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. 57
Consideraciones Finales
•Esindispensablecontarconlosdatoshistóricosdeproyectosdelaorganización,sinembargo,esmuyfrecuenteencontrarquelascompañíasnofacilitanelaccesoalosmismosdebidoaqueestainformaciónescrítica.
•Secuentaconalgunasbasesdedatosinternacionalesqueguardaninformaciónhistóricadeproyectosyquepodríanservircomoreferentesparaafinarelmodelopropio.
•Esimportanterealizarestudiosparacaracterizarlosproyectosdelaindustriadesoftwarelatinoamericana

58. Agenda
•Introducción
•Métodos de Estimación
•Método Delphide 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

59. •IanSommerville. Ingenieria De Software. 7ª Edición. México : PearsonEducacion, 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 Num6, 2003.
•L. F. Capretz, V. Marza. Improving Effort Estimation by Voting Software EstimationModels. Advancesin Software EngineeringVolume 2009, Article ID 829725, 8 pages
Bibliografía

60. •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…