Estimacion De Proyecto

24,557 views
23,919 views

Published on

bueno.

1 Comment
5 Likes
Statistics
Notes
No Downloads
Views
Total views
24,557
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
613
Comments
1
Likes
5
Embeds 0
No embeds

No notes for slide

Estimacion De Proyecto

  1. 1. DIEGO MAURICIO SUAREZ ARLEY MENDEZ BRICEÑO.
  2. 2. INTRODUCCION Es necesario construir en un tiempo corto, sin un costo excesivo, aplicaciones complejas, de calidad y que soporten las necesidades del usuario. Estas aplicaciones deberían ser fáciles y rápidas de modificar.
  3. 3. ESTIMACION DE PROYECTOS DE SOFTWARE La gestión de todo proyecto de software comienza con la planificación de proyecto y sus actividades. Antes de que se empiece con el proyecto, el gestor y su equipo debe de hacer una estimación del proyecto, es decir, el trabajo, el esfuerzo, los recursos hardware y software que se necesitaran, el costo y el tiempo necesario para culminar el proyecto. En la planificación del proyecto se determinara tareas y tiempo que se deben cumplir, así como también, los responsables de que se cumplan. La estimación del proyecto determinara casi con actitud el verdadero costo y el esfuerzo persona mes que se necesita de un proyecto.
  4. 4. Para realizar estimaciones seguras de costes y esfuerzos tenemos varias opciones posibles: 1. Dejar la estimación para mas adelante. 2. Basar las estimaciones en proyectos similares ya terminados. 3. Utilizar técnicas de descomposición relativamente sencillas para generar las estimaciones de coste y de esfuerzo del proyecto. 4. Utilizar uno o mas modelos empíricos para la estimación del coste y esfuerzo del software.
  5. 5. Tamaño del software Representa un desafío para el planificador del proyecto. El tamaño se refiere a un resultado cuantificable del proyecto del software. El tamaño se puede medir en líneas de código ( LDC) o como puntos de función (PF).
  6. 6. Tamaño en lógica difusa: Este enfoque utiliza las técnicas aproximadas de razonamiento que son la piedra angular de la lógica difusa. Tamaño en punto de función: El planificador desarrolla estimaciones de características del dominio de información. Tamaño de componentes estándar: el software se compone de un numero de componentes estándar que son genéricos para un área en particular de la aplicación. Tamaño del cambio: este enfoque se utiliza cuando un proyecto comprende la utilización de software existente que se debe modificar de alguna manera como parte de un proyecto.
  7. 7. Estimación basada en el problema Las estimaciones de LCD y PF son técnicas de estimación distintas. A pesar de que ambas tienen varias características en común. el planificador del proyecto comienza con un enfoque limitado para el ámbito del software y de este estado intenta descomponer el software en funciones que se puedan estimar individualmente.
  8. 8. Estimación basada en el proceso La técnica mas común para estimar un proyecto es basar la estimación en el proceso que se va a utilizar. Es decir el proceso se descompone en un conjunto relativamente pequeño de actividades o tareas y en el esfuerzo requerido para llevar a cabo la estimación de cada tarea. Para cada función se debe llevar a cabo una serie de actividades del proceso del software, una vez que se mezclan las funciones del problema y las actividades del proceso, el planificador estima el esfuerzo que se requeriría para llevar a cabo cada una de las actividades del proceso del software en cada función.
  9. 9. ¿Que tienen en común la estimación orientada a PF y LCD? Las métricas de productividad de línea base se aplican entonces para la variable de estimación adecuada y se extrae el coste o el esfuerzo de la función. En general, el dominio del proyecto debería calcular las medidas de LDC y PF, es decir los proyectos se deberían agrupar por tamaño de equipo, área de aplicación, complejidad y otros parámetros relevantes.
  10. 10. Problemas derivados • Mantenimiento de alto costo y alto riesgo • Gran dependencia del individuo. • Incumplimiento de plazos de entrega. • No se tiene tiempo de recoger datos sobre el proceso de desarrollo de software que permitan estimaciones y planificaciones fiables. • Insatisfacción de los usuarios con el producto terminado (cuando se termina). • Dudosa calidad del software desarrollado. • Poca importancia a las pruebas.
  11. 11. CONCLUSIONES Y RECOMENDACIONES Se destaca el hecho de que para proyectos pequeños resulta efectivo el lograr un prototipo rápido como técnica de educción de requisitos, que si bien al inicio demanda de un esfuerzo y tiempo adicional, esto se ve claramente compensando al momento de desarrollar el producto final, ya que redunda en conseguir una planificación más real, el tener una documentación efectiva y poco cambiante, arquitecturas y diseños mejor logrados, pero por sobre todo, una mayor certeza de alcanzar lo que el usuario final realmente desea y por lo que está dispuesto a pagar.
  12. 12. MODELO COCOMO  Es un modelo de estimación de costes.  Creado por Barry W. Boehm.  Incluye 3 submodelos con un nivel de detalle cada vez mayor.
  13. 13. Modelos de estimación  Modelo básico  Modelo intermedio  Modelo avanzado
  14. 14. Modos  Orgánico.  Semiacoplado.  Empotrado.
  15. 15. Modo Básico  El modelo básico se usa para obtener una aproximación rápida del esfuerzo.  Usa las variables a, b, c y d, que varían en función de los modos.  Conforme se aumenta la complejidad del modo, aumentan los valores de las variables (esfuerzo).
  16. 16. Modelo básico  Personas necesarias para llevar a cabo el proyecto: (MM) = a*(Klb) • Tiempo de desarrollo del proyecto: (TDEV) = c*(MMd) • Personas necesarias para el proyecto: (CosteH) = MM/TDEV • Coste total del proyecto: (CosteM) = CosteH * Salario medio
  17. 17. Modelo Intermedio  Añade al modelo básico 15 factores de ajuste o guías de coste.  Logramos mayor precisión en la estimación gracias a los nuevos factores.  La fórmula es la misma que la del modelo básico pero con el añadido del factor (multiplicando).
  18. 18. Modelo Intermedio Atributos del modelo: • Software: • RELY: Indica las consecuencias para el usuario si falla el producto. • DATA: Relación Tamaño de la BD / Líneas de código. • CPLX: Complejidad del producto.
  19. 19. Modelo Intermedio Atributos del modelo: • Hardware: • TIME: Limitaciones en el porcentaje del uso de la CPU. • STOR: Limitaciones en el porcentaje del uso de la memoria. • VIRT: Volatilidad de la máquina virtual. • TURN: Tiempo de respuesta.
  20. 20. Modelo Intermedio Atributos del modelo: • Personal: • ACAP: calificación de los analistas. • AEXP: experiencia del personal. • PCAP: calificación de los programadores. • VEXP: experiencia del personal en la máquina virtual. • LEXP: experiencia en el lenguaje.
  21. 21. Modelo Intermedio Atributos del modelo: • Proyecto: • MODP: uso de prácticas modernas de programación. • TOOL: uso de herramientas de desarrollo de software. • SCED: limitaciones en el cumplimiento de la planificación.
  22. 22. Ejemplo estimacion: • Debemos desarrollar un software de no muy elevada dificultad, con las siguientes restricciones: • 3 meses para el desarrollo del proyecto software. • Debe estar implementado en el lenguaje Visual Basic.
  23. 23. Ejemplo estimacion: • Calculo del esfuerzo: Necesitamos hallar la variable KDLC. LENGUAJE LDC/PF Ensamblador 320 C 150 COBOL 105 Pascal 91 Prolog/LISP 64 C++ 64 Visual Basic 32 SQL 12
  24. 24. Ejemplo estimacion:  KLDC = (PF * Líneas de código por cada PF)/1000 = (261,36*32)/1000 = 8,363  Usaremos el tipo Organico ya que núestro proyecto no supera las 50 KLDC, y es el mas a propiado en este caso.
  25. 25. Ejemplo estimacion: • Coeficientes a usar: PROYECTO SOFTWARE a b c d Orgánico 3,2 1,05 2,5 0,38 Semi-acoplado 3,0 1,12 2,5 0,35 Empotrado 2,8 1,20 2,5 0,32
  26. 26. Ejemplo estimacion: • Calculo de la variable FAE: CONDUCTORES DE COSTE VALORACIÓN Muy Bajo Nominal Alto Muy Extr. bajo alto alto Fiabilidad requerida del software 0,75 0,88 1.00 1,15 1,40 - Tamaño de la base de datos - 0,94 1.00 1,08 1,16 - Complejidad del producto 0,70 0,85 1.00 1,15 1,30 1,65 Restricciones del tiempo de ejecución - - 1.00 1,11 1,30 1,66 Restricciones del almacenamiento principal - - 1.00 1,06 1,21 1,56 Volatilidad de la máquina virtual - 0,87 1.00 1,15 1,30 - Tiempo de respuesta del ordenador - 0,87 1.00 1,07 1,15 - Capacidad del analista 1,46 1,19 1.00 0,86 0,71 - Experiencia en la aplicación 1,29 1,13 1.00 0,91 0,82 - Capacidad de los programadores 1,42 1,17 1.00 0,86 0,70 - Experiencia en S.O. utilizado 1,21 1,10 1.00 0,90 - - Experiencia en el lenguaje de programación 1,14 1,07 1.00 0,95 - - Prácticas de programación modernas 1,24 1,10 1.00 0,91 0,82 - Utilización de herramientas software 1,24 1,10 1.00 0,91 0,83 - Limitaciones de planificación del proyecto 1,23 1,08 1.00 1,04 1,10 -
  27. 27. Ejemplo estimacion:  Calculo de la variable FAE:  FAE = 1,15 * 1,00 * 0,85 * 1,11 * 1,00 * 1,00 * 1,07 * 0,86 * 0,82 * 0,70 * 1,00 * 0,95 * 1,00 * 0,91 * 1,08 = 0,53508480  Cálculo del esfuerzo del desarrollo:  E = a KLDC^(b) * FAE = 3,2 * (8.363)^1,05 * 0,53508480 = 15,91 personas /mes
  28. 28. Ejemplo estimacion:  Cálculo tiempo de desarrollo:  T = c Esfuerzo d = 2,5 * (15,91)^0,38 = 7,15 meses  Productividad:  PR = LDC/Esfuerzo = 8363/15,91 = 525 ,64 LDC/personas mes
  29. 29. Ejemplo estimacion:  Personal promedio:  P = E/T = 15,91/7,15 = 2,22 personas  Segun los resultados necesitaremos un equipo de 3 personas trabajando alrededor de 7 meses, pero como una restricción era 3 meses incrementamos a 6 el numero de personas. 1 Jefe de proyecto, 2 Analistas, 2 programadores y 1 Responsable de calidad.

×