2. 2
Visión General
• La planeación de un proyecto software implica estimar
cuanto tiempo, esfuerzo, dinero y recursos serán necesarios
para construir un sistema.
• Una vez que se definió el ámbito del proyecto y se dividió
el problema en su problemas, los gestores de proyecto usan
datos históricos (como también experiencia personal e
intuición) para realizar la estimación.
• Las estimaciones se ajustan teniendo en cuenta los riesgos
y la complejidad del proyecto.
5. Tareas
5
1. Establecer el ámbito del proyecto.
2. Determinar la factibilidad.
3. Analizar los riesgos.
4. Determinar los recursos necesarios:
• Determinar los recursos humanos necesarios.
• Definir los recursos reusables.
• Identificar recursos del entorno.
5. Estimar costo y esfuerzo:
• Descomponer el problema.
• Desarrollar dos o mas estimaciones.
• Conciliar las estimaciones.
6. 4. Estimación del
esfuerzo
6
6. Desarrollar el plan de proyecto:
• Establecer un conjunto significativo de tareas.
• Definir una red de tareas.
• Usar herramientas de planificación para
desarrollar un cronograma.
• Definir mecanismos de seguimiento de la
planificación.
7. Ámbito del software y
factibilidad
7
Describe:
• los datos que se procesan y producen,
• los parámetros de control,
• las funciones,
• el rendimiento,
• las restricciones,
• las interfaces externas y
• la confiabilidad.
A menudo las funciones descriptas en el ámbito se refinan
con el fin de permitir una mejor estimación.
8. Ámbito y comunicación con el
cliente
4. Estimación del
esfuerzo
8
• Determinar los objetivos globales del cliente para el
sistema propuesto y algunos beneficios esperados.
• Determinar las percepciones del cliente con respecto a la
naturaleza de una buena solución al problema.
• Evaluar la eficacia de la reunión con el cliente.
9. Factibilidad
4. Estimación del
esfuerzo
9
• La factibilidad técnica no es una razón suficiente para
construir un producto.
• El producto debe cumplir las necesidades del cliente y
no estar disponible como un producto de propósito
general.
10. Estimación de recursos
10
• Recursos humanos: cantidad de personas y capacidades
necesarias para completar el proyecto.
• Recursos reusables: componentes ya desarrollados,
componentes experimentados, componentes de
experiencia parcial, componentes nuevos.
• Recursos de entorno: que debe estar disponible
para el equipo durante el proceso de desarrollo.
12. Estimación del proyecto software
12
Opciones:
•Demorar la estimación hasta avanzado el proyecto.
•Basar la estimación en proyectos similares ya concluidos.
•Usar técnicas simples de descomposición para estimar el
costo y esfuerzo del proyecto.
•Usar modelos empíricos para la estimación de costo y
esfuerzo.
•Las herramientas automatizadas pueden ayudar con la
•descomposición y estimación del proyecto.
13. Técnicas de descomposición
13
• Tamaño del software: de lógica fuzzy, de puntos de
función, de componentes estándar, de cambio.
• Estimación basada en el problema: la estimación basada
en LDC se centra en las funciones del software, mientras
que el uso de PF hace énfasis en las características del
dominio de información.
• Estimación basada en el proceso: descomposición basada
en las tareas requeridas para completar el marco de
proceso software.
• Estimación de casos de uso: técnica promisoria pero aun
controversial debido a la falta de estandarización de los
casos de uso.
14. Conciliación de estimaciones
14
Causas de los problemas de conciliación:
•El planificador no entendió adecuadamente o
interpreto mal el ámbito del proyecto.
•El conjunto de datos usados en las técnicas basadas en
el problema eran obsoletos o inadecuados para la
aplicación.
15. Modelos empíricos de estimación
15
Se derivan de análisis de regresión de datos de proyectos
software pasados con persona-mes estimados como
variable dependiente y KLDC o PF como variables
independientes.
COCOMO (Modelo Constructivo de Costos) es un
ejemplo de un modelo estático de estimación.
La Ecuación del Software es un ejemplo de un modelo
dinámico de estimación.
16. COCOMO II
16
• Es una jerarquía de modelos de estimación que
abarca:
• Modelo de composición de la aplicación.
• Modelo de etapa de diseño temprano.
• Modelo de etapa posterior a la arquitectura.
17. Estimación para desarrollo ágil
17
1. Cada escenario de usuario se considera por separado.
2. El escenario se descompone en un conjunto de tareas de
ingeniera.
3. Cada tarea se estima por separado:
• Se puede usar datos históricos, modelos empíricos o
experiencia.
• Se puede estimar el volumen del escenario (LDC,
PF, cantidad de casos de uso, etc.)
18. 18
4. Calcular la estimación del escenario completo:
•Sumar las estimaciones de cada tarea
•Traducir el volumen estimado en esfuerzo usando datos
históricos
5. Se suman los esfuerzos estimados para cada escenario
de un incremento para obtener la estimación del
incremento.
19. Decisión desarrollar-comprar
19
• Puede ser mas rentable comprar un producto software
determinado que construirlo.
• El análisis de un árbol de decisión brinda una manera
sistemática de tomar una decisión desarrollar-
comprar.
• Como regla, la subcontratación requiere mas
habilidad en la gestión que el desarrollo interno del
mismo producto.