Planificacion de proyectos
-
Upload
leonel-ibarra -
Category
Education
-
view
1.981 -
download
0
Transcript of Planificacion de proyectos
Ingeniería del Software
ULEAM 2012
Planificación de Proyectos de Software
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…
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 Tiempo que transcurrirá desde el comienzo
hasta el final de su realización.
Siempre que estimamos, estamos mirando hacia el futuro y aceptamos resignadoscierto grado de incertidumbre
Existen técnicas Útiles para la estimación del esfuerzo y del tiempo.
Importancia
¿Qué es la Estimación?
¿Cuál es la importancia de la estimación?
Task
OBSERVACIONES SOBRE LA ESTIMACIÓN
Observaciones sobre la estimación
Escribe tus conclusiones y comentarios
Task
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...».
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
La estimación conlleva un riesgo inherente y es este riesgo el que lleva a la incertidumbre.
Incertidumbre y Estimación
1. La complejidad del
proyecto
2. El tamaño del proyecto
3. El grado de incertidumbre
estructural
La experiencia,
PFImposibilidad de descomposiciónGrado de análisis de requisitos
Task
¿Qué entendemos como Incertidumbre?
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.
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.
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.
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
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.
La Estimación
Variabilidad en requisitos = inestabilidad
Un gestor no debe obsesionarse con las estimaciones.
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.
Desarrollar un cronograma con Herramientas de Planificación
Definir mecanismos de seguimiento del programa de trabajo.
ÁMBITO DEL SOFTWARE
Ambito del Software
Describe: Funciones Características Entradas Salidas Contenido a Presentar Desempeño Restricciones Interfaces
Confiabilidad a entregar al Usuario final.
Task
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?
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?
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?
TaskAnalizar ejemplo de
ÁmbitoPág. 80 y encontrar:
FuncionesCaracterísticasEntradasSalidasContenido a PresentarDesempeñoRestriccionesInterfaces
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.
VIABILIDAD
Cuatro elementos esenciales:TecnologíaFinanzasTiempoRecursos
Lectura página 80 viabilidad
Recursos
Divididos en Tres Grandes Categorías:
Personal Componentes de
Software Reutilizables
Entorno
La Trinidad
Proyecto
Personal
EntornoSoftware
Reutilizable
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)
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
Para que la reutilización sea eficiente, los
componentes de software deben estar catalogados,
estandarizados y
validados.
Recursos del Entorno
HardwareSoftware (Herramientas de Desarrollo)
Recuerde
Un gran error en la estimación puede hacer la diferencia entre Ganancia o Perdida.
Mala Estimación
Desastre para el
Desarrollador
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
¿Como lograr estimaciones Confiables?
Hacer una estimación al 100 %
Basarse en proyectos similares
Descomposición Simple
Uso de Modelos Empíricos
Usar Datos Históricosd = 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).
Técnicas de Descomposición
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
Tamaño del Software
El grado con el cual se ha estimado adecuadamente el tamaño
Habilidad para traducir estimación en esfuerzo humano, cronograma y dineroGrado 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.
La precisión de una estimación del proyecto de software se predice basándose en:
El «tamaño» del software o construir puede estimarse utilizando una medida directa, LDC, o uno medida indirecta, PF.
Estimación basada en el Problema
Estimación basada en el Problema
Métricas basadas en la ProductividadLDC/pmPF/pm
Combinaciones
El «tamaño» del software o construir puede estimarse utilizando una medida directa, LDC, o uno medida indirecta, PF.
Estimación Basada en el Problema
Ámbito
Estimación basada en el Problema
Para estimaciones de PFLa 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 complejidad
calculo media ponderada
Optimista
Mas Probable
Pesimista
Valor Esperad
o
Una mejor estimación viene dada por:
VE = (Sopt + 4Smed + Spes)/6
cálculo de la desviación de las estimaciones
Estimación basada en LDC
Descomposición funcional absolutamente esencial
considerables niveles de detalle LDC se estima directamente.
EJEMPLOS
Página No. 88
Ejemplo E. basada en el proyecto
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.
Ejemplo: Estimación basa en PF
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,65Utilizando la fórmula en el ejemplo:
Factor de ajuste = (17 * 0,01) + 0,65 = 0,82
FACTOR DE AJUSTE DE LA COMPLEJIDAD:
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).
Estimación basada en el Proceso
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.
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
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
Ejemplo
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
Ecuaciones de los Modelos Empíricos
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
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.
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.
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).
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
¡Analice el siguiente ejemplo!
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.
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
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
Técnicas de Estimación
especializadas
Estimación Orientada a Objetos Estimaciones en PF o LDC
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 numero promedio de unidades de trabajo por clase.
Tipo de Interfaz
Multiplicador
Sin GUI 2.0
Interfaz basada en
texto
2.25
GUI 2.25
GUI Compleja 3.0
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
Los Expertos Dicen
Es mejor Comprender el trasfondo de una estimación antes de utilizarla.
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
¿Desarrollar o Comprar?
Á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.
Árbol de Decisión
Sistema X
Construir
Simple (0.30)
Difícil (0.70)
Reutilizar
Cambios Menores (0.40)
Cambios Mayores (0.6)
Simple (0.2)
Complejo (0.8)
Comprar
Cambios Menores (0.70)
Cambios Mayores (0.30)
Contratar
Sin Cambios (0.60)
Con Cambios (0.40)
$ 380000
$ 450000
$ 275000
$ 310000
$ 490000
$ 210000$ 400000
$ 350000
$ 500000
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
PLANIFICACION TEMPORAL
Y
SEGUIMIENTO DEL PROYECTO
Una pequeña historia
¿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
“Adoro las Fechas limite. Me gusta cuando pasan
como una exhalación cuando se alejan.”
Douglas Adams
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
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
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
Calendarización
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
¿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
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.
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
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
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
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
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).
Curva Putnam-Norden-Rayleigh (PNR)
Lectura ejemplo
Capitulo 7 pág. 115
Diagrama Pert
LITERAL
Actividad Predecesor Duració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 beneficios
D 3
H Preparar propuesta F,G 2
I Presentar propuesta H 2
Tabla de actividades
Ejercicio
Esquema de proyecto final
CarátulaÍndice1. 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ón3.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 actividadesDiagrama de Pert-Ruta CriticaAnálisis Costo Beneficio Cronograma (carta Grant) Anexos