Tecnicas de estimacion de costos de proyecto software

66,629 views

Published on

Técnicas de estimación de costos de proyecto software.

Published in: Technology
6 Comments
25 Likes
Statistics
Notes
No Downloads
Views
Total views
66,629
On SlideShare
0
From Embeds
0
Number of Embeds
85
Actions
Shares
0
Downloads
2,260
Comments
6
Likes
25
Embeds 0
No embeds

No notes for slide

Tecnicas de estimacion de costos de proyecto software

  1. 1. TECNICAS DE ESTIMACION DE COSTOS DE PROYECTO SOFTWARE<br />JENNIFER ANDREA CANO GUEVARA<br />INGENIERIA DE SISTEMAS<br />
  2. 2. La Estimación<br />No necesita realizarse en una forma improvisada.<br />La experiencia es una gran ayuda.<br />La estimación implica riesgo inherente, y este conduce a la incertidumbre.<br />El riesgo de la estimación se mide por el grado de incertidumbre en las estimaciones cuantitativas para recursos, costos y programa de trabajo.<br />
  3. 3. La dificiltarea de estimar<br />La estimación de software es difícil. Los jefes, directivos, clientes y desarrolladores no parecen entender por qué la estimación es tan difícil. <br />No se puede estimar con precisión el costo de un programa hasta que se comprendan con detalle cada una de las funciones que realizará el sistema. La incertidumbre sobre la naturaleza del producto aporta incertidumbre a la estimación. <br />
  4. 4. Estimación<br />Un gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.<br />
  5. 5. FACTORES QUE INFLUYEN EN EL COSTO DEL SOFTWARE <br />La estimación de lo que costará el desarrollo de un software es una de las actividades de planeación que reviste especial importancia, ya que una de las características que debe tener un producto de software es que su costo sea adecuado, de lo contrario el proyecto puede fracasar. <br />
  6. 6. Los factores que afectan el costo del software<br />1. Capacidad del programador <br />2. Complejidad del producto <br />3. Tamaño del programa <br />4. Tiempo disponible <br />5. Confiabilidad requerida <br />
  7. 7. El Proceso de Estimación <br />1. Estimar el tamaño del producto ( en número de líneas de código fuente o puntos de función ). <br />2. Estimar el esfuerzo ( personas - mes ). <br />3. Estimar el plan ( meses ). <br />
  8. 8. Técnicas de Descomposición<br />La técnica de descomposición basada en el problema, se basa en la descomposición del producto en funciones y estimar el tamaño del software<br />• Por tanto, la primera estimación que sirve de base para todas las demás, es la estimación del tamaño del software<br />
  9. 9. Estimación Basada en el Problema<br />
  10. 10. Técnicas de DescomposiciónTamaño del Software<br />Podemos considerar dos tamaños del software:<br />Tamaño en LDC.<br />Tamaño en PF.<br />• En cualquier caso, la precisión de la estimación depende de:<br />El grado en el que el planificador ha estimado adecuadamente el tamaño del producto a construir.<br />
  11. 11. Técnicas de DescomposiciónTamaño del Software<br />- La habilidad para traducir la estimación del tamaño en esfuerzo y dinero. Depende fundamentalmente de la existencia de métricas.<br />El grado en que el plan del proyecto refleja las habilidades del equipo de software.<br />
  12. 12. Técnicas de descomposiciónBasadas en el Problema<br />• Dicha estimación puede basarse en:<br />Datos históricos.<br />Experiencia/intuición.<br />• Con estos valores se calcula un valor esperado:<br /> VE = (Vo + 4Vm + Vp)/6<br />• Una vez estimado el tamaño se aplican los datos históricos de productividad LDC<br />
  13. 13. Técnicas de DescomposiciónBasadas en el Proceso<br />• La técnica más común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar<br />• Utilizando el proceso identificamos un conjunto pequeño de actividades de trabajo o tareas de trabajo y se estima el esfuerzo requerido para llevar a cabo cada tarea<br />
  14. 14. METRICA<br />“Un Método y una escala cuantitativos que pueden ser usados para determinar el valor que toma cierta característica en un producto de software concreto.”<br />
  15. 15. Ecuaciones de los Modelos Empiricos<br />
  16. 16. CLASIFICACION DE LAS METRICAS<br />MÉTRICAS TÉCNICAS: Se centran en las características de software.<br />MÉTRICAS DE CALIDAD: proporcionan una indicación de cómo se ajusta el software a los requisitos implícitos y explícitos del cliente. <br />MÉTRICAS DE PRODUCTIVIDAD. Se centran en el rendimiento del proceso de la ingeniería del software. <br />
  17. 17. CLASIFICACION DE LAS METRICAS<br />MÉTRICAS ORIENTADAS A LA PERSONA. Proporcionan medidas e información sobre la forma que la gente desarrolla el software de computadoras y sobre todo el punto de vista humano de la efectividad de las herramientas y métodos.<br />MÉTRICAS ORIENTADAS AL TAMAÑO. Es para saber en que tiempo voy a terminar el software y cuantas personas voy a necesitar. <br />
  18. 18. CLASIFICACION DE LAS METRICAS<br />MÉTRICAS ORIENTADAS A LA FUNCIÓN. Son medidas indirectas del software y del proceso por el cual se desarrolla. <br />
  19. 19. Métricas del Software<br />Métricas Orientadas al tamaño<br />Medidas directas del resultado<br />y del proceso<br />Métricas Orientadas a la función<br />Medidas indirectas del <br />software y del proceso<br />
  20. 20. Métricas orientadas al tamaño<br />Páginas de documentación<br />Esfuerzo humano (persona - mes)<br />N° de errores<br />LDC<br />N° de defectos<br />Coste (USD)<br />Productividad =KLDC / persona-mes<br />Calidad =N° de errores (defectos) / KLDC<br />Coste medio =USD / KLDC<br />Documentación =KLDC / persona-mes<br />
  21. 21. METRICA LDC<br />Calcular la productividad, calidad, coste medio y documentación de acuerdo a la información proporcionada en la tabla que se muestra a continuación:<br /><ul><li>Productividad = KLDC / personas-mes
  22. 22. Calidad = Nº errores (defectos) / KLDC
  23. 23. Coste medio = Dólares / KLDC
  24. 24. Documentación = Páginas de documentación / KLDC</li></li></ul><li>METRICAS LDC<br />Con los datos contenidos en la tabla se puede obtener un conjunto de métricas simples adicionales: <br />No. De Errores por LDC 134 / 12,100 0.01 Errores / LDC <br />No. De Defectos por LDC 29/12,100 0.002 Defectos / LDC <br />Costo por LDC 168,000 / 12,100 $ 13.88 / LDC <br />LDC por persona-mes 12,100 / 24 904 LDC/p-m <br />
  25. 25. METRICA LDC<br />Ventajas: <br />- Es una métrica fácil de comprender. <br />- Muchos modelos, herramientas automáticas y literatura de estimación se basan en LDC. <br />
  26. 26. METRICA LDC<br />Desventajas: <br />Las LDC son dependientes del lenguaje. Escribir el mismo programa en lenguajes diferentes puede arrojar una diferencia en LCF bastante grande. <br />Resulta difícil que el planificador estime las LCF a producirse mucho antes de que se complete el análisis y el diseño, más aún si no tiene datos históricos. <br />
  27. 27. -25-<br />Hay que desarrollar un software CAD que aceptará datos geométricos de 2 o 3 dimensiones por parte del ingeniero. Éste controlará el sistema CAD por medio de una interfaz que debe tener un diseño de buena calidad. Una base de datos CAD contiene todos los datos geométricos y la información de soporte. Se desarrollarán módulos de análisis de diseño para producir la salida requerida que se va a visualizar en varios dispositivos gráficos.<br />El software se diseñará para controlar e interconectar diversos periféricos, como un ratón, un digitalizador y una impresora láser.<br />Funciones identificadas:<br />interfaz de usuario y facilidades de control (IUFC)<br />análisis geométrico de dos dimensiones (AG2D)<br />análisis geométrico de tres dimensiones (AG3D)<br />gestión de base de datos (GBD)<br />facilidades de la interfaz gráfica (FIG)<br />control periféricos (CP)<br />módulos de análisis del diseño (MAD)<br />Estimación en LDC de AG3D:<br />optimista: 4600<br />más probable: 6900<br />pesimista: 8600<br />descomposición<br />de funciones<br />VE = (Sopt + 4Sm + Spes)/6<br />Datos históricos:<br />productividad media de la organización en proyectos similares: 620 LDC/pm<br />Tarifa laboral: 8000 $ /mes<br />Coste LDC:$ 13 ($12.90)<br />Función LDC estimada<br />IUFC 2300<br />AG2D 5300<br />AG3D 6800<br />GBD 3350<br />FIG 4950<br />CP 2100<br />MAD 8400 <br />Total33200<br />métricas de<br />proyectos anteriores<br />Coste total proyecto:$431.600<br />Esfuerzo estimado: 54 personas-mes<br />
  28. 28. Métricas orientadas a la función<br />consultas<br />salidas<br />Ficheros logicos internos<br />PF<br />entradas<br />Ficheros de interfaz<br />
  29. 29. Estimación<br />Una mejor estimación viene dada por:<br />S = (Sopt + 4Smed + Spes)/6<br />cálculo de la desviación de las estimaciones<br />
  30. 30. Entradas<br />Informaciones que llegan a la aplicación desde el exterior.<br />Tienen una sola dirección (Exterior à Interior)<br />Siempre actualizan algún fichero interno. <br />4. Apendice, Métrica de los puntos de función.<br />28<br />
  31. 31. Clasificación de las salidas<br />
  32. 32. Salidas<br />Informaciones elaboradas por la aplicación que son transmitidas al usuario.<br />Tienen una sola dirección (Interior a Exterior)<br />4. Apendice, Métrica de los puntos de función.<br />30<br />
  33. 33. Consultas<br />Entradas que producen inmediatamente una salida<br />No modifica los datos del sistema<br />4. Apendice, Métrica de los puntos de función.<br />31<br />
  34. 34. 4. Apendice, Métrica de los puntos de función.<br />32<br />Clasificación de las consultas<br />Calculamos la complejidad de la parte de entrada<br />Calculamos la complejidad de la parte de salida<br />Nos quedamos sólo con la complejidad mayor de las dos.<br />
  35. 35. Ficheros Lógicos o Internos<br />4. Apendice, Métrica de los puntos de función.<br />33<br />Agrupaciones de datos, tal y como los percibe el usuario<br />Es diferente de:<br />Entidades y Relaciones<br />Tablas o archivos resultantes del diseño físico<br />Los grupos de datos serán accedidos y actualizados por la aplicación<br />
  36. 36. Clasificación de los Ficheros Lógicos o Internos<br />
  37. 37. Ficheros de Interfaz<br />Ficheros a los que accede la aplicación con el único objetivo de obtener información.<br />Son mantenidos por otras aplicaciones<br />Nunca los actualiza la aplicación.<br />4. Apendice, Métrica de los puntos de función.<br />35<br />DIAGRAMA DE CONTEXTO<br />
  38. 38. Clasificación de los Ficheros de Interfaz<br />
  39. 39. TABLA PARA CALCULAR PUNTOS DED FUNCION<br />
  40. 40. FACTORES DE COMPLEJIDAD<br />Son catorce factores que completan la visión externa de la aplicación.<br />No están recogidos en la funcionalidad de la aplicación.<br />Toman un valor entre 0 y 5<br />
  41. 41. Factores de Ajuste de Complejidad: evaluar cada factor de 0 a 5<br />0- Sin influencia 3- Medio<br /> 1- Incidental 4- Significativo<br /> 2- Moderado 5- Esencial<br />¿Requiere el sistema copias de seguridad fiables?<br />¿Se requieren comunicaciones de datos?<br />¿Existen funciones de procesamiento distribuido?<br />¿Es crítico el rendimiento?<br />¿Será ejecutado el sistema en un entorno operativo existente y utilizado?<br />¿Se requiere entrada de datos interactiva?<br />¿Requiere la entrada interactiva que las transacciones de entrada se hagan sobre múltiples pantallas o variadas operaciones?<br />¿Se actualizan los archivos maestros de forma interactiva?<br />¿Son complejas las entradas, las salidas, los archivos o las peticiones?<br />¿Es complejo el procesamiento interno?<br />¿Se ha diseñado el código para ser reutilizable?<br />¿Están incluidas en el diseño la conversión y la instalación?<br />¿Se ha diseñado el sistema para soportar múltiples instalaciones en diferentes organizaciones?<br />¿Se ha diseñado la aplicación para facilitar los cambios y ser fácilmente utilizada por el usuario?<br />
  42. 42. Métricas orientadas a la función<br />PF = cuentatotalX [0,65 + 0,01 * Sumatoria (Fi) ]<br />Punto de función<br />Sumatoria total resultante de la ejecutar las operaciones en la tabla siguiente<br />En función de un cuestionario de 14 preguntas <br />Valores de ajuste de complejidad<br />
  43. 43. Para el ejemplo descrito se asume que la Fi es 46 (un producto moderadamente complejo), por consiguiente:<br />      PF = 50 x (0,65 + 0,01 x 46) = 55.5 ≈ 56<br />Donde cuenta-total es la suma de todas las entradas PF obtenidas de la figura 9.2 y Fi (i=1 a 14) son los "valores de ajuste de complejidad".<br /> <br />
  44. 44. -42-<br />Copia de seguridad y recuperación 4<br />Comunicaciones 2<br />Proceso distribuido 0<br />Rendimiento crítico 4<br />Entorno operativo existente 3<br />Entrada de datos online 4<br />Transacciones entrada en varias pant. 5<br />Archivos maestros actualizados online 3<br />Complejidad valores dominio información 5<br />Complejidad procesamiento interno 5<br />Código diseñado para reutilización 4<br />Conversión en diseño 3<br />Instalaciones múltiples 5<br />Aplicación diseñada para cambios 5<br />PF estimado = cuenta total x (0,65 + 0,01 x Suma (Fi)<br />PF estimado = 372<br />Coste total proyecto:$ 457.843<br />Esfuerzo estimado: 58 personas-mes<br />Datos históricos:<br />productividad media de la organización en proyectos similares: 6,5 PF/pm<br />Tarifa laboral:8000 $ /mes<br />Coste por PF:$ 1.230 ($1230,76)<br />métricas de<br />proyectos anteriores<br />
  45. 45. 4. Apendice, Métrica de los puntos de función.<br />43<br />UTILIDADES DE LOS PUNTOS DE FUNCIÓN.<br />Comparar lo que solicitó el cliente con lo que recibió.<br />Comparar la productividad de los diferentes entornos de desarrollo.<br />Comparar la calidad que se obtiene mediante las diferentes técnicas de desarrollo.<br />
  46. 46. TECNICAS DE ESTIMACION DE COSTOS <br />JUICIO EXPERTO <br />La técnica más utilizada para la estimación de costos es el uso del juicio experto. El juicio experto se basa en la experiencia, en el conocimiento anterior y en el sentido comercial de uno o mas individuos dentro de la organización. <br />
  47. 47. JUICIO EXPERTO <br />El experto, por ejemplo, puede hacer una estimación de costos razonando de la siguiente manera: <br />- El sistema que se va a desarrollar es muy similar a uno que se desarrollo anteriormente y que costó $ 8,000.00 y tardó 4 meses. <br />- Se puede reutilizar la base del proyecto anterior. <br />- Se utilizará el mismo equipo de cómputo y a muchos de los programadores que participaron en el proyecto anterior, por lo que la estimación se puede reducir en un 20 %. <br />
  48. 48. JUICIO EXPERTO <br />- Mucho código y rutinas comunes se podrán reutilizar por lo que el esfuerzo se reduce otro 20%. <br />- Por lo tanto el nuevo proyecto puede ser un 20% más económico que el anterior. <br />
  49. 49. JUICIO EXPERTO<br />Ventajas <br />Se obtiene una estimación en corto tiempo.<br />Desventajas <br />1. El experto puede confiarse y olvidar algunos factores importantes del Nuevo proyecto, creyendo que es casi igual al anterior. <br />2. El experto puede no tener familiaridad con el área del proyecto. <br />
  50. 50. TECNICAS DE ESTIMACION DE COSTOS <br />TECNICA DELFI <br />Se desarrollo en la corporación Rand en 1948, con el fin de lograr un acuerdo de un grupo de expertos sin contar con los efectos negativos de las reuniones de grupos. La técnica se lleva a cabo de la siguiente manera: <br />
  51. 51. TECNICA DELFI <br />1. Un coordinador proporciona a cada experto la documentación con la Definición del Sistema y una papeleta para que escriba su estimación.<br />2. Cada experto estudia la definición y determina su estimación en forma anónima; los expertos pueden consultar al coordinador, pero no entre ellos. <br />
  52. 52. DELFI<br />3. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas, incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos. <br />4. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente, utilizando los resultados de la estimación anterior. En los casos en que una estimación difiera mucho de las demás, se podrá solicitar que también en forma anónima el experto justifique su estimación. <br />
  53. 53. TECNICA DELFI <br />5. El proceso se repite tantas veces como se juzgue necesario, impidiendo una discusión grupal durante el proceso. <br />
  54. 54. ECUACION DE PRIMER ORDEN DE JONES <br />Carpes Jones propone una ecuación derivada del análisis de su base de datos de cientos de proyectos. <br />Este es también un modelo empírico de estimación. <br />Con la suma total de puntos de función , se puede realizar a partir de ellos un cálculo aproximado de la planificación. <br />
  55. 55. ECUACION DE JONES<br />La ecuación de Jones tiene la forma: <br /> TDEV = #PF n <br /> Donde TDEV = Tiempo de planificación ( meses ) <br /> #PF = No. de Puntos de Función <br /> n = Exponente según la tabla siguiente <br />
  56. 56. ECUACION DE JONES<br />
  57. 57. TECNICA ITERATIVA <br />Se basa en la entrega evolutiva del software ( por etapas o iteraciones ). <br />En cada etapa se construye un pequeño conjunto de funciones del software ( miniproyecto ), que implica análisis, diseño, codificación, pruebas, documentación y evaluación del cliente. <br />La técnica permite determinar el número de iteraciones y su longitud necesaria para desarrollar el proyecto completo.<br />NOTA: Las estimaciones son de los desarrolladores, no de los gerentes. <br />
  58. 58. TECNICA ITERATIVA<br />1.- Estimar el esfuerzo de cada función del software. <br />Asegurarse de que quien haga la estimación sea el desarrollador que posea el mayor conocimiento de la función dada. <br />
  59. 59. TECNICA ITERATIVA<br />2.- Determine el número de programadores. <br />Utilizando los registros de proyectos anteriores, busque una aproximación con el Esfuerzo del proyecto actual y deduzca el número de programadores que convendría utilizar. <br />Ejemplo: <br />Si en un proyecto anterior de 38 semanas-programador requirió 4 programadores, puede ser razonable que el nuevo proyecto requiera de 5. <br />
  60. 60. TECNICA ITERATIVA<br />3.- Determine el factor de eficiencia de los programadores ( productividad ). <br />Aunque los desarrolladores sean de tiempo completo, no dedicarán el 100% de la jornada en trabajo productivo. <br />Investigaciones de cómo usan su tiempo los programadores indican QUE:<br />Ejemplo: Suponga una productividad del 50% para este ejemplo. <br />
  61. 61. TECNICA ITERATIVA<br />4.- Determine la longitud de la iteración. <br />Se busca una longitud de iteración fija para todo el proyecto, de modo que se pueda lograr un ritmo regular de entrega del proyecto. Cada iteración debe ser lo suficientemente larga para realizar varias funciones del software. <br />Puede considerar longitudes de iteración de 2 a 8 semanas. <br />Ejemplo: Suponer para este ejemplo que se implementará en un lenguaje conocido, por lo que una longitud de iteración de 3 semanas permitirá implementar de 2 a 4 funciones del software por iteración <br />
  62. 62. TECNICA ITERATIVA<br />5.- Calcular el esfuerzo por iteración. <br />Esfuerzo por iteración ( semanas-programador ) = No. Programadores * Long. Iteración * Factor de Productividad <br />Ejemplo: <br />Esfuerzo por iteración = 5 * 3 * 0.5 = 7.5 semanas-programador <br />
  63. 63. TECNICA ITERATIVA<br />6.- Calcular el número de iteraciones. <br />No. Iteraciones = ( Esfuerzo Total / Esfuerzo por Iteración ) + 1 <br />Ejemplo: <br />No. Iteraciones = ( 50 / 7.5 ) + 1 = 7.6 aprox. 8 iteraciones <br />
  64. 64. 7.- Calcular el tiempo de desarrollo. <br />Teniendo la longitud y el número de iteraciones es fácil determinar el tiempo de desarrollo <br />Tdev = Long. Iteración * No. Iteraciones <br />Ejemplo: <br />Tdev = 3 * 8 = 24 semanas = 6 meses. <br />
  65. 65. 8.- Considerar un factor de contingencia. <br />Agregue un factor del 10% al 20% del tiempo de construcción, dependiendo de lo arriesgada que parezca la situación. <br />Ejemplo: <br />Considerando el factor 40-20-40, es decir, el 40% de esfuerzo es Analisis-Diseño, 20% Codificación y 40% Pruebas, calculamos que el tiempo posible de construcción ( codificación ) es el 20% de las 24 semanas totales. <br />Tcodif = 0.2 * 24 = 4.8 aprox. 5 semanas <br />
  66. 66. Suponiendo que nuestro factor de contingencia es del 15% entonces el tiempo de contingencia será <br />Tconting = 0.15 * 5 = 0.75 semanas o aprox. 4 dias. <br />Por lo tanto el plan debe ser formulado para desarrollar el producto en 24 semanas, pero el compromiso de entrega final sería para 24.75 semanas, 4 días más. <br />
  67. 67. TECNICAS DE ESTIMACION DE COSTOS <br />METODO HISTORICO <br />Este método se basa en registros cuidadosos que se mantienen de esfuerzos de desarrollo previos. <br />MODELO DE COSTOS COCOMO <br />El modelo de costos COCOMO ( Modelo Constructivo de Costos ), se basa en el uso de ecuaciones que se utilizan de acuerdo a la complejidad del sistema a desarrollar: <br />
  68. 68. Cocomo<br /><ul><li>El Modelo Constructivo de Costos (COnstructiveCOstModel) es una jerarquía de modelos de estimación para el software.
  69. 69. Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:
  70. 70. E = ab (KLDC) exp (bb)
  71. 71. D = cb (E) exp (db)
  72. 72. Las ecuaciones del modelo COCOMO intermedio toma la forma:
  73. 73. E = ai (KLDC) exp (bi) x FAE
  74. 74. donde E es el esfuerzo aplicado en personas-mes, KLDC es el número estimado de Líneas de Código distribuídas para el proyecto.</li></li></ul><li>Jerarquías de Cocomo<br /><ul><li>El modelo COCOMO básico es un modelo univariable estático que calcula el esfuerzo (y el costo) del desarrollo de software en función del tamaño del programa expresando en líneas de código (LDC) estimadas.</li></li></ul><li>COCOMO<br />El modelo COCOMO intermedio calcula el esfuerzo del desarrollo de software en función del tamaño del programa y de un conjunto de “conductores de costo”, que incluyen la evaluación subjetiva del producto, del hardware, del personal y de los atributos del proyecto.<br />
  75. 75. cocomo<br />El modelo COCOMO avanzado incorpora todas las características de la versión intermedia y lleva a cabo una evaluación de impacto de los conductores de costo en cada fase (análisis, diseño, etc.) del proceso de ingeniería de software.<br />
  76. 76. Cocomo Orientado a los Tipos de proyecto de software <br /><ul><li>Modelo Orgánico. Proyectos de software relativamente pequeños y sencillos en los que trabajan pequeños equipos, con buena experiencia en la aplicación, sobre el conjunto de requisitos poco rígidos (por ejemplo, un programa de análisis termal desarrollado para un grupo calórico).</li></li></ul><li>Cocomo Orientado a los Tipos de proyecto de software <br />Modelo Semiacoplado. Proyectos de software intermedios (en tamaño y complejidad) en los que los equipos, con variados niveles de experiencia, deben satisfacer requisitos poco o medio rígidos (por ejemplo, un sistema de procesamiento de transacciones con requisitos fijos para un hardware de terminal o un software de gestión de base de datos).<br />
  77. 77. Cocomo Orientado a los Tipos de proyecto de software <br />Modelo Empotrado. Proyectos de software que deben ser desarrollados en un conjunto de hardware, software y restricciones operativas muy restringidas (por ejemplo, software de control de navegación para un avión).<br />
  78. 78.
  79. 79. COCOMO<br />Las ecuaciones son de la forma: <br />PM = a * ( KDSI ) b ; TDEV = c * ( PM ) d <br />Programas de Aplicación: PM = 2.4 * ( KDSI ) 1.05; TDEV = 2.5 * ( PM ) 0.38 <br />Programas de Apoyo: PM = 3.0 * ( KDSI ) 1.12; TDEV = 2.5 * ( PM ) 0.35 <br />Programas de Sistemas: PM = 3.6 * ( KDSI ) 1.20; TDEV = 2.5 * ( PM ) 0.32 <br />
  80. 80. Calendarización <br />Fundamentos<br />La realidad de un proyecto técnico, tal como uno de software, es que hay que realizar cientos de tareas pequeñas en un orden determinado antes de poder alcanzar la meta final. Las tareas están interrelacionadas en una secuencia lógica en el sentido de que algunas de ellas no pueden empezar hasta que otras se hayan terminado. <br />
  81. 81. -76-<br />Calendario<br />Dividir el proyecto en actividades o tareas<br />Estimar el tiempo necesario para realizarlas (algunas se harán en paralelo)<br />Los administradores <br />Coordinan las actividades <br />Organizan el trabajo para optimizar la mano de obra<br />Asignan y planifican recursos (personal, hardware, software, presupuesto para viajes,...)<br />Duración aconsejable de una actividad: entre 1 y 8 semanas<br />
  82. 82. -77-<br />Calendario (cont.) <br />Importante tener en cuenta posibles problemas (personal, hardware, software,...) que provocan retrasos.<br />Problemas previstos: incrementar un 30% la estimación inicial.<br />Problemas no previstos: incrementar un 20%.<br />Utilización de diagramas de Gantty redes de actividades<br />
  83. 83. Herramientas Automáticas de Calendarización <br />
  84. 84. CONSEJOS SOBRE ESTIMACIONES <br />1. Evite estimaciones improvisadas ( ojo de buen cubero ). <br />2. Use datos de proyectos anteriores ( método histórico ). <br />3. Las estimaciones las debe hacer el desarrollador, no el directivo. <br />4. Estime por concenso ( técnica delfi ). <br />5. Evite estimar el proyecto como un todo. <br />6. Estime por descomposición, es decir, estime cada función o requisito del software individualmente. Luego la suma de ellos será la estimación del proyecto total. <br />7. Utilice diferentes técnicas de estimación, compare los resultados y resuelva las diferencias. <br />8. Si es posible use una herramienta automática de estimación. Con esto tendrá otro punto de comparación. <br />9. Refine sus estimaciones a medida que conozca más detalles del proyecto. <br />
  85. 85. 10. Emita una estimación preliminar después de revisar la Definición del Sistema. Refinela durante el Análisis y de una estimación definitiva después de revisar el Diseño. Si esto no es posible, trate de emitir su estimación definitiva al terminar el Análisis. Si aún esto no es posible, deberá formularla solo con la Definición del Sistema pero considere un factor de seguridad adecuado. <br />11. Presente sus estimaciones usando rangos o casos ( mejor, más probable, peor ). <br />12. Defienda sus estimaciones. <br />Finalmente Ud. y su equipo son los que conocen el proyecto y lo desarrollarán. En lo posible evite que un directivo le imponga una estimación que no esté justificada, para esto debe prepararse para defender sus estimaciones. <br />13. Negocíe con el cliente. <br />
  86. 86. ¿Preguntas?<br />

×