software estimation (in spanish)

1,600 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,600
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
74
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

software estimation (in spanish)

  1. 1. Estimación de tamaño, costos y esfuerzos
  2. 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. 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. 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. 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. 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. 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. 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. 9. ¿Qué debo hacer para poder gestionar mis proyectos de desarrollo? Si no puedes medir no puedes controlar
  10. 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. 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. 12. Predicción Similar a medición indirecta ! Sóloesposiblepredecirsitenemosbuenasmedidasenquébasarnos! Apesardeloobviodeestaafirmaciónmuchasveceslosadministradoresmuestrangraninterésenestimación,peronoenmedicionesdesoftware. Elesfuerzodeestimareldesarrollodeunsoftware, siempreesunaactividaddePREDICCION.Lapredicciónprecisarequieremedicióncuidadosadeatributosclavesenproyectosyacompletados.
  13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 41 Componentes Estándares ElmétododeComponentesEstándares:sebasaenlapremisadequenosotrosnoreinventamoslaruedaencadaproyecto,sinoquemásbienreproducimosnuestrassolucionesexitosas.
  42. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 57 Consideraciones Finales •Esindispensablecontarconlosdatoshistóricosdeproyectosdelaorganización,sinembargo,esmuyfrecuenteencontrarquelascompañíasnofacilitanelaccesoalosmismosdebidoaqueestainformaciónescrítica. •Secuentaconalgunasbasesdedatosinternacionalesqueguardaninformaciónhistóricadeproyectosyquepodríanservircomoreferentesparaafinarelmodelopropio. •Esimportanterealizarestudiosparacaracterizarlosproyectosdelaindustriadesoftwarelatinoamericana
  58. 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. 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. 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…

×