bueno.

1. DIEGO MAURICIO SUAREZ
ARLEY MENDEZ BRICEÑO.

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

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

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

14. Modelos de estimación
 Modelo básico
 Modelo intermedio
 Modelo avanzado

15. Modos
 Orgánico.
 Semiacoplado.
 Empotrado.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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