Planificacion Proyecto Software
Transcript of Planificacion Proyecto Software
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 1/103
Planificación de Proyectos de
Software
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 2/103
¿Por qué Planificar?
Boehm, 1975: 45% de los errores tienen su origen en los requisitos y en el diseño preliminar. DeMarco, 1984: 56% de los errores que tienen
lugar en un proyecto software se deben a una mala especificación de requisitos. Chaos Report, 1995: Los factores principales que conducen al fracaso en los proyectos software son:
Falta de comunicación con los usuarios. Requisitos incompletos. Cambios a los requisitos.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 3/103
¿Es lo Mismo?
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 4/103
Introducción
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.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 5/103
Objetivos
Resolver problemas corriente arriba a bajocosto.
La experiencia dice que el proyecto promediogasta 80 por ciento de su tiempo enreelaboración: corrigiendo errores que secometieron en etapas tempranas del
proyecto.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 6/103
Objetivos
Proporcionar un Marco de Trabajoque permita al gestor estimar
razonablemente los recursos, costo yprograma de trabajo.
Adaptar y actualizar el plan conformese avance en el proyecto.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 7/103
Actividades
La planificación del proyecto del softwareabarca 5 grandes actividades:
EstimaciónPrograma de Trabajo
Análisis de Riesgos
Planificación de la Gestión de CalidadPlanificación de la Gestión del Cambio
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 8/103
La Estimación
No necesita realizarse en una formaimprovisada.
La experiencia es una gran ayuda.
La estimación implica riesgo inherente, y esteconduce a la incertidumbre.
El riesgo de la estimación se mide por el grado
de incertidumbre en las estimacionescuantitativas para recursos, costos y programade trabajo.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 9/103
La Estimación
Variabilidad en requisitos = inestabilidad
Un gestor no debe obsesionarse con las
estimaciones.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 10/103
Recursos
Divididos en Tres Grandes Categorías:
Personal
Componentes de Software Reutilizables Entorno
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 11/103
La Trinidad
Proyecto
Personal
EntornoSoftware
Reutilizable
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 12/103
Recursos Humanos
El planificador debe especificar:
± Habilidades Requeridas
±
PosiciónO
rganizacional ± Especialidad
E
l personal puede estar Geográficamentedisperso.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 13/103
Recursos de Software Reutilizables
Ingeniería de Software basada enComponentes.
Énfasis en la reutilización
Componentes ya desarrollados.
Adquirir componentes de Terceros.
Componentes Experimentados
Componentes de Experiencia Parcial No inventar el Agua Tibia
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 14/103
Recursos del Entorno
Hardware
Software (Herramientas de Desarrollo)
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 15/103
Estimación
Un gran error en la estimación puede hacer ladiferencia entre Ganancia o Perdida.
Mala
Estimación
Desastre parael
Desarrollador
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 16/103
Estimación
Nunca es exacta
Mientras más se conozca menos errores seriosse cometerán.
Implica muchas variables ± Humanas
± Técnicas
± Ambientales ± Políticas
± etc
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 17/103
¿Como lograr estimaciones Confiables?
Basarse en proyectos similares
Descomposición Simple
Uso de Modelos Empíricos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 18/103
Estimación
Usar Datos
Históricos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 19/103
Técnicas de Descomposición
El problema a resolver es muy complejo paraconsiderarlo una sola pieza
Descomponer el problema en problemas máspequeños
Hacer el problema más MANEJABLE
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 20/103
Tamaño del Software
El grado con elcual se haestimado
adecuadamenteel tamaño
Habilidad para
traducirestimación enesfuerzohumano,
cronograma y
Dinero
Grado en el que
la planificaciónrefleja las
habilidades delequipo de
Software
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 21/103
Estimación Basada en el Problema
Métricas basadas en la Productividad
LDC/pm
PF/pm Combinaciones
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 22/103
Estimación Basada en el Problema
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 23/103
Estimación
OptimistaMas
ProbablePesimista
ValorEsperado
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 24/103
Estimación basada en LDC(Líneas de Código)
Descomposición funcional absolutamenteesencial
considerables niveles de detalle LDC se estima directamente.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 25/103
E jemplo
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 26/103
Estimación basada en PF(Puntos de Función)
Los datos requeridos para estimar los Puntosde Función son más macroscópicos que enLDC.
Nivel de descomposición considerablementemenos detallado que en LDC.
PF se determina indirectamente mediante la
estimación del número de entradas, salidas,archivos de datos, peticiones e interfacesexternas, entre otras.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 27/103
E jemplo
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 28/103
LDC o PF Esperados
A partir de los datos históricos o (cuando todo lodemás falla) usando su intuición, el planificador estimalos valores optimista, más probable y pesimista de LDCo de PF para cada función. Cuando lo que se especificaes un rango de valores, implícitamente se proporcionauna 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 lasestimaciones LDC o PF óptima (a), más probable (m) ypesimista (b).
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 29/103
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 acabo cada tarea
Se presentan las tareas en forma de tabla
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 30/103
Pasos de la Estimación basada en elProceso
Delimitar las funciones obtenidas a partir del ámbitodel software
Actividades del proceso para cada función
Estimación de esfuerzo (persona-mes) para cadaactividad
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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 31/103
E jemplo
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 32/103
Estimación basada en Casos de Uso
Permiten que el equipo de software comprendamejor el ámbito y los requisitos.
El uso de casos de uso es a veces problemático
porque: ± no existe un formato estándar. ± Representan una visión externa con diferentes grados
de abstracción ± No abordan la complejidad de las funciones ni de las
características Los expertos recomiendan no usar mas de 10 casos
de Uso con no mas de 30 escenarios
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 33/103
Metodología General a Usar conEstimación de Casos de Uso
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 34/103
¿CómoEstimar
usandoCasos de
Uso?
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 35/103
Reconciliación de Estimaciones
La estimacion por LDC, PF y basadas en elproceso se realizan independientemente.
Cuando se tienen algunas estimaciones de costoy esfuerzo se pueden comparar y armonizar.
Si tienen un buen grado de concordancia sonconfiables las estimaciones.
Si son poco concordantes los resultados de lasestimaciones, entonces se debe investigar yanalizar mejor
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 36/103
Técnicas Delfi
Desarrolladas con el fin de obtener el consenso de un grupo de expertos sin contarcon los efectos negativos de las reuniones de grupos. La técnica puede adaptarse a laestimación de costos de la siguiente manera:
Un coordinador proporciona a cada experto la documentación con la definición delsistema y una papeleta para que escriba su estimación.
Cada experto estudia la definición y determina su estimación en forma anónima; los
expertos pueden consultar con el coordinador, pero no entre ellos. El coordinador prepara y distribuye un resumen de las estimaciones efectuadas,
incluyendo cualquier razonamiento extraño efectuado por alguno de los expertos. Los expertos realizan una segunda ronda de estimaciones, otra vez anónimamente,
utilizando los resultados de la estimación anterior. En los casos que una estimacióndifiera mucho de las demás, se podrá solicitar que también en forma anónima elexperto justifique su estimación.
El proceso se repite varias veces como se juzgue necesario, impidiendo una discusióngrupal durante el proceso.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 37/103
Modelos Empíricos de Estimación
Modelos empíricos de estimación:
Utilizan fórmulas derivadas empíricamente parapredecir el esfuerzo como una función de LDC o PF.
Datos empíricos obtenidos de una muestra deproyectos:
± 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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 38/103
Ecuaciones de los Modelos Empíricos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 39/103
Observaciones
Se nota claramente que cada uno de losmodelos (ecuaciones) producirá un resultadodiferente para los mismos valores de LDC o PF.
Los modelos deben CALIBRARSE para lasnecesidades locales
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 40/103
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 siguienteforma:
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 deLí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.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 41/103
Jerarquías de Cocomo
El modelo COCOMO básico es un modelo univariableestático que calcula el esfuerzo (y el costo) del desarrollode software en función del tamaño del programaexpresando en líneas de código (LDC) estimadas.
El modelo CO
CO
MO
intermedio calcula el esfuerzo deldesarrollo de software en función del tamaño del programay de un conjunto de conductores de costo, que incluyen laevaluación subjetiva del producto, del hardware, delpersonal y de los atributos del proyecto.
El modelo COCOMO avanzado incorpora todas lascaracterísticas de la versión intermedia y lleva a cabo unaevaluación de impacto de los conductores de costo en cadafase (análisis, diseño, etc.) del proceso de ingeniería desoftware.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 42/103
Cocomo Orientado a los Tipos deproyecto de software
Modelo Orgánico. Proyectos de software relativamente pequeños ysencillos en los que trabajan pequeños equipos, con buenaexperiencia en la aplicación, sobre el conjunto de requisitos pocorígidos (por ejemplo, un programa de análisis termal desarrolladopara un grupo calórico).
Modelo Semiacoplado. Proyectos de software intermedios (entamaño y complejidad) en los que los equipos, con variados nivelesde experiencia, deben satisfacer requisitos poco o medio rígidos(por ejemplo, un sistema de procesamiento de transacciones conrequisitos fijos para un hardware de terminal o un software degestión de base de datos).
Modelo Empotrado. Proyectos de software que deben serdesarrollados en un conjunto de hardware, software y restriccionesoperativas muy restringidas (por ejemplo, software de control denavegación para un avión).
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 43/103
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 44/103
COCOMO II
Es una Evolución del COCOMO original propuestopor 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 Funcion PF ± Lineas de Codigo Fuente LDC ± Puntos Objeto PO
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 45/103
Puntos Objeto
Son una manera indirecta de calcular el tamañodel 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 ponderacion Se suman todos los resultados para obtener una
cuenta total de PO.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 46/103
Puntos Objeto
Estimando el % de reutilizacion se ajusta lacuenta de PO
NPO = (PO) * [(100- %reut)/100]
Para obtener la estimacion de esfuerzo sedebe calcular la tasa de ProductividadPROD = NPO/persona-mes
Una vez obtenida pasamos a estimar elesfuerzoEsfuerzo Estimado = NPO/PROD
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 47/103
La Ecuación del Software
Es un modelo multivariable
Supone una distribución especifica delesfuerzo 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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 48/103
TÉCNICAS DE
ESTIMACIÓNESPECIALIZADAS
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 49/103
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 unmultiplicador
Multiplicar el numero total declases por el numero promedio deunidades de trabajo por clase.
Tipo de Interfaz Multiplicador
Sin GUI 2.0
Interfaz basadaen texto
2.25
GUI 2.25
GUI Compleja 3.0
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 50/103
Estimación para Desarrollo Ágil
Los requerimiento en este tipo de proyectosse presentan como un conjunto de escenariosde usuario.
Se puede estimar de manera mas informal.
Se usan los enfoques de LDC o PF orientados aescenarios
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 51/103
Los Expertos Dicen
Es mejor Comprender el trasfondo de unaestimación antes de utilizarla.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 52/103
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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 53/103
¿DESARROLLAR
O COMPRAR?
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 54/103
Á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 ymodificarlo.
4. Contratar una empresa externa para eldesarrollo.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 55/103
Árbol de Decisión
Sistema X
Construir
Simple (0.30)
Difícil (0.70)
Reutilizar
CambiosMenores (0.40)
CambiosMayores (0.6)
Simple (0.2)
Complejo (0.8)
Comprar
CambiosMenores (0.70)
CambiosMayores (0.30)
Contratar
Sin Cambios(0.60)
Con Cambios(0.40)
$ 380000
$ 450000
$ 275000
$ 310000
$ 490000
$ 210000
$ 400000
$ 350000
$ 500000
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 56/103
Subcontratación
Es extremadamente simple.
Las actividades de ingeniería del software secontratan con una tercera parte que realiza eltrabajo a un costo mas bajo
Efecto negativo que la compañía pierde ciertocontrol sobre el software
Corre el riesgo de poner el destino de sucompetitividad en manos de una tercera parte
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 57/103
¿Cuáles son las claves del éxito?
Q: What are the most exciting/promising
software engineering ideas or techniques on
the horizon?
A: I dont think that the most promising ideas
are on the horizon. They are already here and
have been here for years but are not being
used properly. David L. Parnas
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 58/103
¿A qué se refiere Parnas?
PRÁCTICAS EN PLANIFICACIÓN GESTIÓN DE PROYECTOS Automated estimation tools (1973) Evolutionary delivery (1988) Measurement (1977) Productivity environments (1984) Risk management planning (1981)PRÁCTICAS EN INGENIERÍA DE REQUISITOS Change board (1979)
Throwaway user interface prototyping (1975) JAD sessions (1985) Requirements (1989)
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 59/103
CALENDARIZACIÓN
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 60/103
En que consiste la Calendarización
En crear una rede de tareas de ingeniería quele permitirán tener el trabajo listo a tiempo.
Una vez creada la red debe asignarresponsabilidades a cada tarea
Asegurarse que las tareas se realicen
Adaptar la red conforme los riesgos se vuelvanrealidad
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 61/103
¿Por qué es importante?
Construcción de un sistema complejo
Tareas de ingeniería ocurren en paralelo
Resultado de trabajo realizado durante unatarea pude tener un profundo efecto en eltrabajo llevado a cabo en otra tarea.
Interdependencia difíciles de entender sincalendarización
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 62/103
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 poderseguir el progreso
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 63/103
¿Por qué se entregan el software conretraso?
Fecha limite irrealizable establecida por externo eimpuesta
Cambio en los requisitos no reflejados enmodificaciones 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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 64/103
Los Expertos dicen
Cualquier comandante en jefe que pretendalleva a cabo un plan que considera defectuosocomete un error; debe exponer sus razones,
insistir en que el plan debe cambiarse yfinalmente presentar su renuncia en lugar deser el instrumento de la destrucción de su
ejercito Napoleón
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 65/103
Adoro las Fechas limite. Me gustacuando pasan como una
exhalación cuando se alejan.Douglas Adams
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 66/103
Lo que no se debe hacer
Presentarse ante el cliente y demandarle quecambie la fecha de entrega impuesta por elmercado.
Rechazar el trabajo¿Que hacer? Estimación Detallada Aplicar un Modelo de proceso Incremental
Explicar al cliente por que la fecha es irrealizablecon la estimación detallada Funcionalidad faltante se entregara despues
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 67/103
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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 68/103
Generalidades
Cientos de tareas deben realizarse paracompletar la meta mayor
Algunas tareas se pueden completar sinpreocuparse de su impacto sobre la fecha determinación del proyecto
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 69/103
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
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 70/103
Interdependencia
Algunas tareas deben ocurrir en secuencia
Otras pueden ocurrir en paralelo
Algunas tareas no pueden comenzar mientrasel producto de trabajo producido por otrastareas no este disponible
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 71/103
Asignación de Tiempo
A cada tarea se debe asignar cierto numero deunidades de trabajo (personas días deesfuerzo)
Asignar fecha de inicio y terminación enfunción de las interdependencias
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 72/103
Relación entre Personal y Esfuerzo
Mito: Si nos retrasamos en la calendarizaciónsiempre podemos incorporar mas programadoresy recuperarnos mas adelante en el proyecto.
Esto tiene un efecto perturbador en el equipo detrabajo
Provoca mas desfases
Las personas agregadas recientemente debenaprender el sistema y la gente que les enseña esla misma que estaba trabajando
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 73/103
Relación entre Personal y Esfuerzo
Las calendarizaciones de proyecto sonelásticas.
Es posible comprimir en cierta medida la fechade terminación deseada del proyecto (alañadir recursos adicionales).
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 74/103
Curva Putnam-Norden-Rayleigh (PNR)
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 75/103
Curva Putnam-Norden-Rayleigh (PNR)
Indica que un proyecto no se puedecomprimir mas allá de 0.75 td
Si se intenta mayor compresión el proyecto
cae en la región imposible y el riesgo defracaso se eleva mucho
La opcion de entrega de menor costo es ± t
o= 2t
d Esto implica que la demora en la entrega
puede reducir los costos significativamente
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 76/103
Curva Putnam-Norden-Rayleigh (PNR)
La ecuación del software se obtiene de la curvaPNR
Relación enormemente lineal entre el tiempo
cronológico para completar un proyecto y elesfuerzo humano aplicado a este.
L = P * E1/3t4/3
E = L3/(P3t4) es el esfuerzo humano en personas
año durante el ciclo de vida para el desarrollo T es el tiempo en años
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 77/103
Conclusiones de PNR
Se pueden obtener beneficios al emplearmenos personal durante un periodo un pocomas largo para lograr el mismo objetivo
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 78/103
Distribución del Esfuerzo
Regla 40-20-40
40% de todos los esfuerzos se asignan al análisis yel diseño de sistemas de entrada.
40% en poner a prueba los sistemas de salida 20% en codificación
Esta distribución de esfuerzo es solo una guía.
Las características del proyecto deben dictar ladistribución del esfuerzo.
Planeación = 2% 3%
10 CLAVES
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 79/103
10 CLAVESDE UN PROYECTO CON ÉXITO
Evitar los errores clásicos
No ignorar las bases del desarrollo
Gestión activa del riesgo Métodos de Planificación
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 80/103
PLANIFICACIÓN
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 81/103
Visión Clara del Proyecto
Sin una clara visión un proyecto puede terminar en cualquier punto.
Los equipos trabajan para lograr las metas que seles fijan.
Muchos Objetivos = no Objetivos Una buena visión establece prioridades¿Qué tipo de desarrollo rápido quiere?
Speed oriented Schedule-risk oriented Visibility oriented
Req isitos estables completos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 82/103
Requisitos estables, completos yescritos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 83/103
Los cambios en los requisitos
Riesgo más común en un proyecto
Requisitos estables al 100% es casi imposible
La mayoría de los cambios en los requisitosvienen de requisitos que definidos de formaincompleta la primera vez, y no por cambiosde mercado u otras razones similares.
Técnicas para definir Requisitos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 84/103
Técnicas para definir Requisitosestables
Requirements workshop
User interface prototyping
User interview
Use cases
User manual
Usability studies
Incremental delivery Requirements reviews/inspections
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 85/103
Prototipos de Interfaz de Ususario
Técnica Orientada al riesgo más común en un
proyecto... El cambio en los requisitos
Implican a los usuarios de forma amigable
Bajo coste, corta planificación y altasatisfacción del usuario
Es necesario tener habilidad para desarrollar
prototipos exitosos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 86/103
Gestión de Proyectos Efectiva
La pobre gestión planificación es el
segundo riesgo más común.
Responsabilidades de un Jefe de
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 87/103
Responsabilidades de un Jefe deProyecto
U na buena gestión software requiere(NECE SITA) significativas habilidades.
Estimación del Alcance
Análisis de Tiempo, Esfuerzo y Coste Selección del Ciclo de Vida
Planificación de la Calidad
Personal Técnico Gestión de Riesgos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 88/103
Estimaciones Precisas
Las expectativas Injustificadas o no realistasson la mayor causa de los problemas
El estado del arte es dramáticamente mejorque el estado de la práctica
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 89/103
Exactitud de la Estimación y mejora
Resultados Reales como Porcentaje
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 90/103
Resultados Reales como Porcentajede
Resultados Estimados
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 91/103
Efecto de la Estimación
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 92/103
Estimación Precisa
La estimación es una habilidad técnica
especializada
Tratar la estimación como un mini proyecto
Tener un plan de reestimación periódica
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 93/103
No morir por la planificación
Evitar las dos causas de sobre planificación...
Planes inamovibles
Planes excesivamente detallados
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 94/103
Ajuste en la Planificación
Tiempo
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 95/103
Enfoque en la Calidad
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 96/103
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 97/103
¿Por qué centrarse en la calidad?
En la mayoría de los proyectos, el trabajo decorregir defectos no previstos es el mayorcoste (40 80 % del total)
Centrarnos en la calidad tiene un impacto
económico positivo
La calidad debe ser planificada durante el
proyecto, no puede añadirse al final
No olvidar las bases del desarrollo
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 98/103
No olvidar las bases del desarrollosoftware
Los f undamentos de Gestión
Siempre antes que los de Ingeniería
Estimación, Planificación, Seguimiento y
Medición Las Bases Técnicas
Requisitos, Diseño, Construcción, Gest.Configuración, etc.
Las Bases del Control de Calidad
Pruebas, Inspecciones, etc.
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 99/103
Gestión Activa de los Riesgos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 100/103
Sobre la Gestión de Riesgos
Según un estudio de KPMG 55% de los proyectos descontrolados no tenían gestión de
riesgos
38% tenían algo, pero la mitad de estos no usó los riesgos
hallados una vez que el proyecto comenzó 7 % no sabe si utilizó gestión de riesgos
sobre un 80% de los proyectos comenzados no manteníanuna gestión de riesgos significativa
Más del 50% de los proyectos muestran sus problemas
durante el inicio del desarrollo Sobre el 25% muestran sus problemas durante la
planificación inicial
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 101/103
Gestión de Riesgos
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 102/103
i á ( i )
8/8/2019 Planificacion Proyecto Software
http://slidepdf.com/reader/full/planificacion-proyecto-software 103/103
Riesgos más comunes (Best Hits)
Cambio en los Requisitos Meticulosidad en Requisitos o Desarrollo Escatimar en Calidad Planificaciones Demasiado Optimistas Diseño Inadecuado Síndrome de la "Bala de Plata Desarrollo Orientado a la Investigación
PersonalMediocre No definición de Roles y Responsables Error en la Contratación Diferencias entre Desarrolladores y Clientes Falta de Sponsor Falta de información del Usuario Añadir gente a un proyecto retrasado
Sobreestimar de nuevas herramientas o mé
todos Cambio de herramientas en mitad del proyecto Falta de control automatizado del código f uente