Este documento trata sobre la planificación de proyectos de software. Explica que la planificación es fundamental y debe incluir la estimación del trabajo requerido, los recursos necesarios y la definición de un plan de proyecto con tareas y fechas clave. También destaca la importancia de la estimación y las técnicas útiles para realizarla, como la descomposición del trabajo en tareas más pequeñas y el uso de datos históricos. Además, resalta que la estimación conlleva incertidumbre inherente.

1. Ingeniería del
Software
ULEAM 2012

2. Planificación de Proyectos de
Software

3. El Comienzo
En el principio se pidieron los proyectos de
Software.
Los proyectos estaban desordenados y
vacíos, y las tinieblas estaban sobre la haz
del abismo, y el Espíritu de Dios se movía
sobre este mar de Caos.
Y dijo Dios: Sea la Planificación: y fue la
Planificación.
Y vio Dios que la Planificación era buena: y
apartó Dios la Planificación del desorden…

4. L a gestión de un proyecto de
software comienza con un conjunto
de actividades que globalmente se
denominan planificación del
proyecto. Antes de que el proyecto
comience.
El gestor y el equipo de software
deben realizar:
 Una estimación del trabajo a
realizar
 De los recursos necesarios y

5. Importancia
Siempre que
estimamos, estamos mirando
hacia el futuro y aceptamos
resignados
cierto grado de
incertidumbre
Existen técnicas Útiles para la
estimación del esfuerzo y del
tiempo.

6. Task
¿Qué es la Estimación?
¿Cuál es la importancia de la
estimación?

7. OBSERVACIONES SOBRE LA ESTIMACIÓN

8. Observaciones sobre la estimación

9. Task
Escribe tus conclusiones y
comentarios

10. ObservaciONES sobre la estimación
A un destacado ejecutivo se le preguntó una vez
por la característica más importante que debe
tener un gestor de proyectos. Respondió:
<< ... una persona con la habilidad de saber qué es
lo que va a ir mal antes de que ocurra...» .
Debemos añadir:
<< ...y con el coraje para hacer estimaciones
cuando el futuro no está claro...».

11. ObservaciONES sobre la estimación
La estimación de recursos, costes y
planificación temporal de un esfuerzo
en el desarrollo de software requiere:
a. Experiencia
b. Acceso a una buena información
histórica
c. Coraje de confiar en predicciones
(medidas) cuantitativas

12. La estimación conlleva un riesgo
inherente y es este riesgo el que lleva a
la incertidumbre.

13. Task
¿Qué entendemos como Incertidumbre?

14. IMPORTANTE
 Antes de comenzar se debe estimar…
 Esfuerzo, tiempo, personal y demás recursos..
 Luego de estimar se debe planificar…
 Establecer un Plan de Proyecto que defina tareas y
fechas clave, identificar responsables por tareas y
especificar dependencias entre tareas.

15. Objetivos
 Resolver problemas corriente arriba a bajo costo.
 La experiencia dice que el proyecto promedio gasta 80 por
ciento de su tiempo en reelaboración: corrigiendo errores
que se cometieron en etapas tempranas del proyecto.

16. Objetivos
 Proporcionar un Marco de
Trabajo que permita al gestor
estimar razonablemente los
recursos, costo y programa de
trabajo.
 Adaptar y actualizar el plan
conforme se avance en el
proyecto.

17. Los expertos dicen
 Nuestras técnicas de estimación están pobremente
desarrolladas. Mas seriamente, reflejan una
suposición no expresada que es bastante incierta, es
decir: que todo ira bien…
 Frederick Brooks, 1975

18. La Estimación
 No necesita realizarse en una forma
improvisada.
 La experiencia es una gran ayuda.
 La estimación implica riesgo inherente, y
este conduce a la incertidumbre.
 El riesgo de la estimación se mide por el
grado de incertidumbre en las
estimaciones cuantitativas para
recursos, costos y programa de trabajo.

19. La Estimación
 Variabilidad en requisitos =
inestabilidad
 Un gestor no debe
obsesionarse con las
estimaciones.

20. Conjunto de Tareas para la
Planificación de un Proyecto
 Establecer el ámbito del proyecto.
 Determinar Factibilidad
 Analizar Riesgos.
 Definir los recursos requeridos
(humanos, software, etc).
 Estimar costo y Esfuerzo
 Descomponer el problema
 Desarrollar 2 o mas estimaciones (Ej: puntos de
función, casos de uso, etc…)
 Desarrollar un Plan de Proyecto
 Establecer un conjunto de tareas significativas.
 Definir una red de tareas.

21. ÁMBITO DEL SOFTWARE

22. Ambito del Software
Describe:
 Funciones
 Características
 Entradas
 Salidas
 Contenido a Presentar
 Desempeño
Task
 Restricciones
 Interfaces
Confiabilidad a entregar al Usuario final.

23. Obtención de la información
necesaria para el ámbito
El primer conjunto de cuestiones de contexto libre se centran en
el cliente, en los objetivos globales y en los beneficios. Por
ejemplo, el analista podría preguntar:
1. ¿Quién está detrás de la solicitud de este trabajo?
2. ¿Quién utilizará la solución?
3. ¿Cuál será el beneficio económico de una buena solución?
4. ¿Hay otro camino para la solución?

24. Las preguntas siguientes permiten que el analista comprenda
mejor el problema y que el cliente exprese sus percepciones
sobre una solución:
1. ¿Cómo caracterizaría [el cliente] un resultado «correcto»
que se generaría con una solución satisfactoria?
2. ¿Con qué problema(s) se afrontará esta solución?
3. ¿Puede mostrarme (o describirme) el entorno en el que se
utilizará la solución?
4. ¿Hay aspectos o limitaciones especiales de rendimiento
que afecten a la forma en que se aborde la solución?

25. La última serie de preguntas se centra en la efectividad de
la reunión. Gause y Weinberg las llaman «metacuestiones» y
proponen la lista siguiente (abreviada):
1. ¿Es usted la persona apropiada para responder a estas
2. preguntas?iSon «oficiales» sus respuestas?
3. ¿Son relevantes mis preguntas para su problema?
4. ¿Estoy realizando muchas preguntas?
5. ¿Hay alguien más que pueda proporcionar información
6. adicional?
7. ¿Hay algo más que debiera preguntarle?

27. Ambito del Software
Divide y Vencerás
 Muchas veces es bueno refinar.
 Las estimaciones de costo y el programa
de trabajo están funcionalmente
orientadas, por eso es útil cierto grado de
descomposición.

28. VIABILIDAD
Cuatro elementos esenciales:
 Tecnología
 Finanzas
 Tiempo
 Recursos
Lectura página 80 viabilidad

29. Recursos
Divididos en Tres Grandes
Categorías:
 Personal
 Componentes de
Software
Reutilizables
 Entorno

30. La Trinidad
Personal
Proyecto
Software
Entorno
Reutilizable

31. Recursos Humanos
 El planificador debe especificar:
 Habilidades Requeridas
 Posición Organizacional
 Especialidad
El personal puede estar Geográficamente
disperso.
Determinar el número de personas (p/m)

32. Recursos de Software Reutilizables
Ingeniería de Software basada en Componentes. Énfasis
en la reutilización.
Categorías de software:
 Componentes ya desarrollados.
 Adquirir componentes de Terceros.
 Componentes Experimentados
 Componentes de Experiencia
Parcial
No inventar el Agua Tibia

33. Para que la reutilización sea
eficiente, los componentes
de software deben estar
catalogados, estandarizados y
validados.

34. Recursos del Entorno
Hardware
Software (Herramientas de
Desarrollo)

35. Recuerde
 Un gran error en la estimación puede
hacer la diferencia entre Ganancia o
Perdida.
Mala Desastre para
Estimación el
Desarrollador

36. La Estimación del proyecto de software
a. La estimación nunca es exacta, en un principio el
costo era mínimo hoy en día es el elemento más
caro de un S.I.
b. Mientras más se conozca menos errores serios se
cometerán.
c. La estimación nunca es exacta, implica muchas
variables
 Humanas
 Técnicas
 Ambientales
 Políticas
 etc

37. ¿Como lograr estimaciones Confiables?
Hacer una estimación al 100 %
Basarse en proyectos similares
Descomposición Simple
Uso de Modelos Empíricos

38. Usar Datos Históricos
d = f (Vi)
Donde d es uno de los valores estimados
(por ejemplo, esfuerzo, coste, duración del
proyecto) y los vi, son determinados
parámetros independientes (por
ejemplo, LDC o PF estimados).

39. Técnicas de
Descomposición

40. Técnicas de Descomposición
¿Porqué utilizarla?
 El problema a resolver es muy complejo para
considerarlo una sola pieza
 Descomponer el problema en problemas mas
pequeños
 Hacer el problema mas MANEJABLE

41. Tamaño del Software
La precisión de una estimación del proyecto de software se
predice basándose en:
El grado con el cual se ha estimado adecuadamente
el tamaño
Habilidad para traducir estimación en esfuerzo
humano, cronograma y dinero
Grado en el que la planificación refleja las
habilidades del equipo de Software
La estabilidad de los requisitos del software y el
entorno que soporta el esfuerzo de la ingeniería del
software.

42.  El «tamaño» del software o construir puede
estimarse utilizando una medida
directa, LDC, o uno medida indirecta, PF.

43. Estimación basada en el Problema

44. Estimación basada en el Problema
Métricas basadas en la Productividad
 LDC/pm
 PF/pm
 Combinaciones
El «tamaño» del software o construir puede
estimarse utilizando una medida
directa, LDC, o uno medida indirecta, PF.

45. Estimación Basada en el Problema

46. Estimación basada en el Problema
Para estimaciones de PF
La descomposición se centra en las
características del dominio de
información:
 Entradas,
 Salidas,
 Archivos de Datos,
 Peticiones,
 Interfaces Externas
 y los catorce valores de ajuste de la

47. calculo media ponderada
Mas Valor
Optimista Pesimista
Probable Esperado

48. Estimación basada en LDC
 Descomposición funcional absolutamente
esencial
 considerables niveles de detalle
 LDC se estima directamente.
Página No. 88

49. Ejemplo E. basada en el
proyecto

50. Estimación basada en PF
 Los datos requeridos para estimar los
Puntos de Función son más
macroscópicos que en LDC.
 Nivel de descomposición
considerablemente menos detallado
que en LDC.
 PF se determina indirectamente
mediante la estimación del número de
entradas, salidas, archivos de
datos, peticiones e interfaces
externas, entre otras.

51. Ejemplo: Estimación basa en PF
Factor de ajuste
de la complejidad

52. FACTOR DE AJUSTE DE LA COMPLEJIDAD:
Características generales del sistema Nivel de influencia
1- Comunicación de datos 4
2- Procesamiento distribuido 0
3- Perfomance (desempeño) 0
4-Configuración del equipamiento 1
5- Volumen de transacciones 1
6- Entrada de datos on-line 5
7- Interfase con el usuario 1
8- Actualización on-line 5
9- Procesamiento complejo 0
10- Reusabilidad 0
11-Facilidad de implementación 0
12- Facilidad de operación 0
13- Múltiples locales 0
14- Facilidad de cambios 0
Nivel de influencia 17
El factor de ajuste se calcula mediante la fórmula:
Factor de ajuste = (Nivel de influencia * 0,01) + 0,65
Utilizando la fórmula en el ejemplo:
Factor de ajuste = (17 * 0,01) + 0,65 = 0,82

53. LDC o PF Esperados
 A partir de los datos históricos o (cuando
todo lo demás falla) usando su intuición, el
planificador estima los valores
optimista, más probable y pesimista de LDC o
de PF para cada función. Cuando lo que se
especifica es un rango de
valores, implícitamente se proporciona una
indicación del grado de incertidumbre.
 Entonces, se calcula el valor esperado de LDC
o de PF. El valor esperado para la variable de
estimación, E, se obtiene como una medida
ponderada de las estimaciones LDC o PF
óptima (a), más probable (m) y pesimista (b).

54. Estimación basada en el Proceso

55. La técnica más 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.

56. Estimación basada en el
Proceso
 Técnica más habitual
 El proceso se descompone en actividades o
tareas y el esfuerzo requerido para llevar a
cabo cada tarea
 Se presentan las tareas en forma de tabla

57. Pasos de la Estimación basada en el
Proceso
 Delimitar las funciones obtenidas a partir del ámbito del
software
 Actividades del proceso para cada función
 Estimación de esfuerzo (persona-mes) para cada actividad
 En cada función
 Aplicación de índices de trabajo medios (esfuerzo
coste/unidad) al esfuerzo estimado para cada actividad
 Cálculo de costes y esfuerzo de cada función y de la
actividad

58. Ejemplo

59. Modelos Empíricos de
Estimación
Modelos empíricos de estimación:
 Utilizan fórmulas derivadas empíricamente para predecir el esfuerzo como
una función de LDC o PF.
 Datos empíricos obtenidos de una muestra de proyectos:
 difíciles de usar para todas las clases de software y todos los entornos de
desarrollo
 se deben calibrar para las condiciones específicas de una organización

60. Ecuaciones de los Modelos
Empíricos

61. Observaciones
 Se nota claramente que cada uno de los modelos
(ecuaciones) producirá un resultado diferente para los
mismos valores de LDC o PF.
 Los modelos deben CALIBRARSE para las necesidades
locales

62. Cocomo
El Modelo Constructivo de Costos (COnstructive COst Model) es una
jerarquía de modelos de estimación para el software.
Las ecuaciones del modelo COCOMO básico tienen la siguiente forma:
E = ab (KLDC) exp (bb)
D = cb (E) exp (db)
Donde E es el esfuerzo aplicado en personas-mes, D es el tiempo de
desarrollo en meses cronológicos y KLDC es el número estimado de
Líneas de Código distribuídas (en miles) para el proyecto.
Las ecuaciones del modelo COCOMO intermedio toma la forma:
E = ai (KLDC) exp (bi) x FAE
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.

63. Jerarquías de Cocomo
 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.
 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.
 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.

64. Cocomo Orientado a los Tipos
de proyecto de software
 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).
 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).
 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).

66. COCOMO II
 Es una Evolución del COCOMO original propuesto por
Boehm
 Aborda las siguientes áreas:
 Modelo de composición de la aplicación
 Modelo de la etapa de diseño temprano
 Modelo de etapa posterior a la arquitectura
 Tres opciones de Tamaño:
 Puntos de Función PF
 Líneas de Código Fuente LDC
 Puntos Objeto PO

67. ¡Analice el siguiente ejemplo!

68. Puntos Objeto
 Son una manera indirecta de calcular el tamaño del
software por medio de conteo de:
 Pantallas de interfaz de usuario
 Reportes
 Componente requeridos para las construcción de la
aplicación.
 Las ponderaciones se basan en una tabla
 Se determina el numero de PO y se multiplica por la
ponderación
 Se suman todos los resultados para obtener una cuenta
total de PO.

69. Puntos Objeto
 Estimando el % de reutilización se ajusta la cuenta de
PO
 NPO = (PO) * [(100- %reut)/100]
 Para obtener la estimación de esfuerzo se debe calcular
la tasa de Productividad
 PROD = NPO/persona-mes
 Una vez obtenida pasamos a estimar el esfuerzo
 Esfuerzo Estimado = NPO/PROD

70. La Ecuación del Software
 Es un modelo multivariable
 Supone una distribución especifica del esfuerzo a lo
largo de la vida del proyecto
E = [LDC * B0.333/P]3 * (1/t4)
 E = Esfuerzo en Personas-mes o Personas-año
 T = duración del proyecto en meses o años
 B = “Factor especial de habilidades”
 P = Parámetro de productividad

71. Técnicas de
Estimación
especializadas

72. Estimación Orientada a
Objetos en PF o LDC
Estimaciones
 Aplicar el modelado de análisis OO.
 Determinar el numero de Clases Clave
 Categorizar el tipo de interfaz para la
aplicación y desarrollar un multiplicador
 Multiplicar el numero total de clases por el Tipo de Multiplicador
Interfaz
numero promedio de unidades de trabajo por
Sin GUI 2.0
clase.
Interfaz basada 2.25
en texto
GUI 2.25
GUI Compleja 3.0

73. Estimación para Desarrollo
Ágil
 Los requerimiento en este tipo de proyectos se
presentan como un conjunto de escenarios de usuario.
 Se puede estimar de manera mas informal.
 Se usan los enfoques de LDC o PF orientados a
escenarios

74. Los Expertos Dicen
 Es mejor Comprender el trasfondo de una estimación
antes de utilizarla.

75. Estimación para Ingeniería
 Web
Los proyectos WEB adoptan el modelo de desarrollo ágil
 Se usa un enfoque de puntos de función modificado
 Entradas: Cada pantalla o formato de entrada incluidas las de mantenimiento (CGI o
JAVA)
 Salidas: Cada pagina Web estática, cada guion de pagina Web dinámica y cada
reporte (ASP, DHTML)
 Tablas: Cada tabla lógica en la DB y cada objeto XML
 Consultas: Cada interfaz publicada externamente (referencias externas DCOM o
COM)
 Los PF son un indicador razonable del volumen para un WebApp

76. ¿Desarrollar o
Comprar?

77. Árbol de Decisión
 La organización tiene estas opciones:
1. Construir el Sistema desde 0
2. Reutilizar Componentes existentes de “experiencia parcial”
3. Comprar un Producto disponible y modificarlo.
4. Contratar una empresa externa para el desarrollo.

78. Árbol de Decisión
Simple (0.30) $ 380000
Construir
Difícil (0.70)
$ 450000
Cambios $ 275000
Menores (0.40)
Reutilizar Simple (0.2) $
Cambios 310000
Mayores (0.6)
Sistema X Complejo (0.8) $
Cambios
Menores (0.70) 490000
Comprar
$
Cambios
210000
Mayores (0.30) $
400000
Sin Cambios $
(0.60)
Contratar 350000
Con Cambios
(0.40) $
500000

79. Subcontratación
 Es extremadamente simple.
 Las actividades de ingeniería del software se contratan
con una tercera parte que realiza el trabajo a un costo
mas bajo
 Efecto negativo que la compañía pierde cierto control
sobre el software
 Corre el riesgo de poner el destino de su competitividad
en manos de una tercera parte

80. PLANIFICACION TEMPORAL
Y
SEGUIMIENTO DEL PROYECTO

83. ¿Por qué se entrega el
software con retraso?
 Fecha limite irrealizable establecida por externo e
impuesta
 Cambio en los requisitos no reflejados en
modificaciones en la calendarización
 Subestimación de la cantidad de esfuerzo y recursos
 Riesgos no considerados (Predecibles y no Predecibles)
 Dificultades humanas imprevisibles
 Dificultades técnicas no previstas
 Falta de Comunicación entre el personal
 Falla en la Gestión del Proyecto

84. “Adoro las Fechas limite. Me
gusta cuando pasan como una
exhalación cuando se alejan.”
Douglas Adams

85. Lo que no se debe hacer
 Presentarse ante el cliente y demandarle que cambie la
fecha de entrega impuesta por el mercado.
 Rechazar el trabajo
¿Que hacer?
 Estimación Detallada
 Aplicar un Modelo de proceso Incremental
 Explicar al cliente por que la fecha es irrealizable con la
estimación detallada
 Funcionalidad faltante se entregara después

86. Generalidades
 Objetivo del gestor
 Definir tareas
 Construir la red de tareas
 Bosquejar las interdependencias entre las tareas
 Identificar las tareas cruciales y darles seguimiento
 La calendarización evoluciona a lo largo del tiempo.
 Una calendarización Macroscópica se realiza durante las
primeras etapas de la planificación

87. Generalidades
 Cientos de tareas deben realizarse para completar la
meta mayor
 Algunas tareas se pueden completar sin preocuparse de
su impacto sobre la fecha de terminación del proyecto

88. Calendarización

89. En que consiste la
Calendarización
 En crear una red de tareas de ingeniería que le
permitirán tener el trabajo listo a tiempo.
 Una vez creada la red debe asignar responsabilidades a
cada tarea
 Asegurarse que las tareas se realicen
 Adaptar la red conforme los riesgos se vuelvan realidad

90. ¿Por qué es importante?
 Construcción de un sistema complejo
 Tareas de ingeniería ocurren en paralelo
 Resultado de trabajo realizado durante una tarea pude
tener un profundo efecto en el trabajo llevado a cabo
en otra tarea.
 Interdependencia difíciles de entender sin
calendarización

91. Calendarización Adecuada
Requiere:
 Que todas las tareas aparezcan en la red.
 Esfuerzo y tiempo asignados inteligentemente por
tarea.
 Interdependencias entre tareas indicadas
adecuadamente.
 Recursos asignados para el trabajo.
 Hitos espaciados de modo cercano para poder seguir el
progreso.

92. Principios Básicos de
Calendarización
 Compartimentación
 Interdependencia
 Asignación de Tiempo
 Validación del Esfuerzo
 Definición de Responsabilidades
 Definición de Resultados
 Definición de Hitos

93. Interdependencia
 Algunas tareas deben ocurrir en secuencia
 Otras pueden ocurrir en paralelo
 Algunas tareas no pueden comenzar mientras el
producto de trabajo producido por otras tareas no este
disponible

94. Asignación de Tiempo
 A cada tarea se debe asignar cierto numero de unidades
de trabajo (personas – días de esfuerzo)
 Asignar fecha de inicio y terminación en función de las
interdependencias

95. Relación entre Personal y
Esfuerzo
 Mito: “Si nos retrasamos en la calendarización siempre
podemos incorporar mas programadores y recuperarnos
mas adelante en el proyecto”.
 Esto tiene un efecto perturbador en el equipo de
trabajo
 Provoca mas desfases
 Las personas agregadas recientemente deben aprender
el sistema y la gente que les enseña es la misma que
estaba trabajando

96. Relación entre Personal y
Esfuerzo
 Las calendarizaciones de proyecto son elásticas.
 Es posible comprimir en cierta medida la fecha de
terminación deseada del proyecto (al añadir recursos
adicionales).

97. Curva Putnam-Norden-
Rayleigh (PNR)

98. Lectura ejemplo
Capitulo 7 pág. 115

107. LITERA Actividad Predecesor Duraci
L ón
A Realizar entrevistas Ninguno 3
B Aplicar cuestionarios A 4
C Leer informes de la compañía Ninguno 4
D Analizar el flujo de datos B,C 8
E Introducir prototipos B,C 5
F Observar reacciones a prototipos E 3
G Realizar análisis de costo y D 3
beneficios
H Preparar propuesta F,G 2
I Presentar propuesta H 2

109. Ejercicio

111. Carátula
Índice
1. Introducción (análisis de la necesidad) (1-2 caras)
1.1. Problema (1 cara)
1.2. Objetivos (General – Específicos)
1.3. Justificación (1 cara)
1.4. Ámbito y Alcance (2 caras)
1.5. Estudio de Viabilidad (1.5 caras)
1.6. Responsables (Matriz) (1 cara)
1.7. Estimaciones de Tiempo y Esfuerzo (Cocomo) (2-3 caras)
1.8 Matriz de gestión de riesgos (1-2 caras)
2.-Marco de referencia
Marco Teórico (Teorías de aprendizaje – Docentes- Tecnologías-Software
Educativo..) (6-10 caras)
3. Metodología (3 caras)
3.1. Introducción
3.1. Metodología de Desarrollo (justificar) (rup, xp, scrum, Prototipos)
4. Recursos (1 cara)
Humanos
Tecnológicos
Entorno
5. Planificación temporal (4-5)
Matriz de actividades
Diagrama de Pert-Ruta Critica
Análisis Costo Beneficio