PlanProyecto (IncWBS) 20050905 CONNOTAS

Ingeniera de Software II
Preparacin de Plan de Proyecto 1

Preparacin de
Plan de Proyecto
Ingeniera de Software II Preparacin de Plan de Proyecto 2
Contenido
Etapas en la Preparacin
Plan de Proyecto
Estructura del Equipo de Proyecto
Pasos en la Preparacin del Work-Plan
Seguimiento y Supervisin
Planificacin del Ciclo de Vida
Ciclo de Vida
Algunos Modelos
Conclusiones
Conclusiones
Project Management
Project
Management
Planning Organizing
Controlling
Leading
Staffing
Project Management
Project
Management
Planning Organizing
Controlling
Leading
Staffing
Planning is deciding in advance what to
do, how to do it, whento do it and who
is to do it.
Desafios
Minimizar Retrabajo
Estabilizar Requerimientos
Poder seguir el estado
Perfecto balance entre Tiempo, Costo, Funcionalidades,
Calidad y Recursos contra las Espectativasdel cliente.
Poder medir impacto de cambios.
Desafos
-Minimizar Retrabajo
Los errores de fases previas encontrados en fases siguientes que deben ser corregidos, generan tareas no previstas. El
volumen de estas tareas depende de la distancia entre fases y dela complejidad del proyecto.
-Estabilizar Requerimientos
Los cambios en los requerimientos fuera de la etapa de blueprint, necesariamente afectan la agenda del proyecto por no haber
sido este esfuerzo contemplado en la planificacin.
Las estrategias a seguir para controlar esta variable contemplan en ciclos de vida como Waterfall el congelar requerimientos (lo
cual es al menos muy difcil en gran parte de proyectos que deben acompaar la dinmica del negocio), o en el otro extremo, XP
propone acompaar la dinmica de requerimientos fragmentando el mismo en pequeas porciones autocontenidas que se
implementan en ciclos de no ms de 2 semanas.
-Poder seguir el estado
Mtricas sobre parmetros de inters (issues). Al menos un milestonepor fase.
-Perfecto balance entre Tiempo, Costo, Funcionalidades, Calidad y Recursos contra las Espectativas del cliente.
El mejor lder de proyecto ser quien consiga el resultado ms parecido a la negociacin acordada en project agreement.
-Poder medir impacto de cambios.
Cada vez que el requerimiento cambia, debemos poder medir el costo del cambio para replanificary renegociar pautas.
Desde el punto de vista de la planificacin, es importante conocer de antemano todas las variables y que sea decisin del equipo
de proyecto los puntos del requerimiento que no sern alcanzados, o hasta qu punto ser aceptable niveles de calidad inferiores
a los definidos inicialmente.
Contenido
Plan de Proyecto
Ciclo de Vida
Algunos Modelos
Conclusiones
Conclusiones
Plan de Proyecto
Qu es un Plan de Proyecto?
Es la fotografa de las acciones que se deben tomar para
alcanzar un objetivo determinado.
Etapas en la preparacin Plan de Proyecto
La palabra Blueprint (sin traduccin breve) refleja lo que un plan de proyecto es:
Una fotografa de las tareas a ser realizadas para alcanzar un objetivo bien definido
Debemos llegar a un acuerdo con los directivos y el patrocinador del proyecto a fin de alinear los
beneficios clave del proyecto con los objetivos del negocio. (BusinessCase)
La eleccin del ciclo de vida se realiza tambin en esta etapa.
Equipo del Proyecto
Roles
Directive Board
Configuration Control Board
Sponsor
Stakeholders
Project Manager
Staff
Etapas en la preparacin Equipo del Proyecto
DirectiveBoard
Compuesto por los directivos ms altos de la corporacin. Son los responsables de aprobar el Business
Case y funciones principales y su justificacin en el contexto del negocio.
ConfigurationControl Board
Equipo de expertos (tcnicos o funcionales) en las reas afectadas del negocio. Deben tener un nivel de
decisin acorde a la envergadura del proyecto. Puede estar solo formado por los stakeholders.
Sponsor
Stakeholders
Cualquier persona con conocimiento requerido para la realizacindel proyecto.
En general el stakeholder es seleccionado de entre los usuarios porque no solo tiene el peso "poltico"
como para contribuir al xito, sino que en general tienen una visin mas global de los procesos de
negocio y los beneficios que el cambio propuesto conlleva.
Entonces, por cada perfil de usuario diferente voy a necesitar un stakeholder para representar
concretamente ese perfil y contrastar mi anlisis contra la realidad.
Project Manager
Staff
Personas pertenecientes al equipo de trabajo del proyecto que seencuentran altamente comprometidas.
Pasos en la Preparacin del Plan
Procesos Clave
Factor Analysis
Project Agreement
Change Control Procedures
Work Breakdown Structures
Estimating Tasks
Schedule Creation
Risk Assessment
Etapas en la preparacin Pasos en la Preparacin del Plan de Proyecto
Una posible metodologa para la construccin de un WorkPlan es explicada en Creatinga Project Plan
de Joseph Launi.
De acuerdo al objetivo y nivel de visibilidad, se distinguen las siguientes etapas:
Factor Analysis
Project Agreement
Estimating Tasks
Schedule Creation
Risk Assessment
Pasos en la preparacin del Plan
Factor Analysis
Detecto aspectos en donde es requerido mayor
conocimiento.
El xito de un proyecto es subjetivo, entonces...
Antes de contraer compromisos debemos
investigar, analizar y entender :
Cul es real alcance?, Estn los verdaderos clientes
involucrados?, Cul es el criterio de aceptacin?, Cules son
los entregables adecuados para seguir el proyecto?
Factor Analysis
To be understood, you must seek to understand Steve Covey.
Lo primeroquedebohacer esinvertir esfuerzoen detectar aquellosaspectosen donde mayor
conocimiento esrequerido.
Antes de negociar con el cliente debemosasegurarnosde entender el requerimiento y suentorno.
Dado queel xito de un proyecto es subjetivoa los stakeholders, analizar y entender cuales son los
factoresdeterminantesde queun proyecto sea consideradoexitosoes fundamental.
A partir del anlisisde factoresidentificamos tambin cualesson losentregablesadecuadosparael
correcto seguimiento de lospuntosrelevantesdel proyecto.
Factor Analysis
Definicin y Alcance
Recursos
Cronograma
Procedimientos
Entorno
Cambios Permitidos
Lneas de Comunicacin
Compromiso
Expectativas
Riesgos
Definicin y Alcance: Se refiere al objetivo primario del proyecto, est definido a travs de sus funciones
principales y entregables. Debemos encontrar dentro de estas funciones los motivos por los cuales se
alinea el proyecto con los objetivos del negocio.
Recursos: Recursos requeridos. Recordar que las estimaciones se hacen sobre los mismos y... No
podemos medir lo que no podemos ver.
Los recursos son asignados de acuerdo a la visin subjetiva de los stakeholdersy sponsor... Debemos
alinear nuestro proyecto a los intereses de la compaa a fin de conseguir dichos recursos.
Cronograma: Tiempo estimado para finalizar el proyecto y ajuste con el cronograma global del negocio.
Procedimientos: Estndares, (polticas y procedimientos), metodologas, programas de calidad, revisin
financiera, requerimiento directivo (sponsor)
Entorno: Contexto dentro del cual se desarrollar el proyecto.
Cambios Permitidos: Pronosticar futuras condiciones que afecten el requerimiento oel dominio de
problema.
Comunicacin: Reuniones, reportes de estado, presentaciones y complejidades que puedan afectar a la
comunicacin.
Compromiso: Soporte del patrocinador y de los correspondientes stakeholders.
Expectativas:Identificar los beneficios del proyecto y asegurar que se condicen con la realidad.
Riesgos: Anlisis de Riesgos.
Project Agreement
Project Diamond: Administrando Expectativas
Recursos
Humanos
Tiempo Costo
Calidad
Funcionalidades
Espectativas
Pasos en la Preparacin del Plan de Proyecto Project Agreement
Con muy pocas excepciones, el estimado inicial de recursos y agenda de proyecto es inaceptable.
Esto no ocurre porque el equipo de proyecto sea ineficiente sinoporque usualmente el usuario pide ms
de lo que puede enfrentar. Tambin ocurre que normalmente las nuevas funciones requeridas son
solicitadas tardamente; es extrao que un usuario pueda prevenir una necesidad con la suficiente
antelacin como para poder construirla a tiempo. Es una buena prctica identificar las funciones
esenciales y dejar las secundarias para futuras entregas; es unabuena regla general que la primera
versin ser extremadamente cara si contiene el 100% de las funciones del producto.
El Administrador del Proyecto debe especificar y entender en conjunto con sus stakeholders, la
dimensin de cada uno de los vrtices del Project Diamond.
Este acuerdo es un contrato entre el administrador y el patrocinador del proyecto. Muchas veces se
expresa a travs de un BusinessCase.
J. Launi fija slo cuatro dimensiones, hemos adaptado la presentacin deacuerdo a la visin de la
ctedra presentada en la clase Basarse en Principios
Actividades
Administracin de Requerimientos
Administracin de Cambios
Project Agreement: Supuestos y dependencias
Debo administrar los cambios en los requisitos de modo que
sean permitidos slo previos al diseo de cada iteracin.
Development from a requirement is as easy as walking on the water...
If both are frozen
Pasos en la Preparacin del Plan de Proyecto Change Control Procedures
Los cambios son inevitables y por consiguiente debemos administrarlos:
Administracin de requerimientos
Administracin de cambios sobre el entorno.
Debemos documentar en el acuerdo del proyecto aquellos supuestos y dependencias sobre los cuales
realizamos nuestra construccin... Cualquier cambio en ellos implica un impacto en el proyecto.
Los procedimientos de cambio incluyen la aprobacin del CCB (ConfigurationControl Board)
Normalmente se analiza el requerimiento de una parte del problema y se comienza con el diseo
acotado a dicha fraccin del sistema, una vez comenzado esto, noes una buena prctica permitir
cambios en el requerimiento durante la implementacin de dicho mdulo; los cambios efectuados en
medio del proceso de diseo e implementacin son normalmente destructivos.
Mtodo para representar jerrquicamente las partes de
un proceso o producto
Se basa en factorizar el entregable principal y medir las
piezas resultantes.
Qu es?
Pasos en la Preparacin del Plan de Proyecto Work Breakdown Structures
Objetivo: Determinar las fases, tareas y dependencias, y entregables a ser
completados para considerar que el proyecto a cumplido con el objetivo.
Idea: El entregable que represente el objetivo es colocado como raizde un arbol
donde se va abriendo en 7 +/- 2 hijos hacia abajo hasta alcanzar el nivel mnimo al
cual es posible medir en forma eficiente y certera.
1. Definir el propsito del WBS
2. Identificar el nodo raz (nombre del proyecto/producto)
3. Dividir cada componente en subcomponentes (hasta 7
+/- 2 elementos)
4. Continuar la divisin hasta que se cumpla con el
objetivo (ej: poder estimar o asignar tareas)
5. Desarrollar un diccionario
Cmo se construye un WBS?
Referirse a Work BreakdownStructures de Richard E. Fairlay.
WBS de proceso
Usado por estimadores
La raz identifica el nombre del proyecto
El segundo nivel identifica elementos mayores
Planificacin, organizacin, anlisis de req., diseo, etc
Particin de un proceso en subprocesos hasta obtener
tareas individuales (1 o 2 personas) a desarrollar en poco
tiempo (1 a 2 semanas)
Tipos de WBS
WBS de producto
Usado por ingenieros de software y sistemas. Altamente
relacionado con la arquitectura del producto.
Identifica componentes e interfaces del producto
Identifica hardware, software y datos
La raz identifica el nombre del producto
Los otros elementos son tems discretos e identificables de
hardware, software y datos
Tipos de WBS
WBS hbrido
Combina elementos de los dos tipos anteriores
La raz es un proceso, alternando elementos de proceso y
producto y termina con elementos de producto
La idea es que los procesos producen productos y los
subproductos requieren procesos para su desarrollo
Utilizado por managers que quieren priorizar la estimacin y
control precisos de cada elementos de producto
Tipos de WBS
Ejemplo de WBS
Cada tarea atmica debe ser especificada por:
Nombre, nmero y descripcin
Duracin estimada
Recursos que necesita
Entregables y productos del trabajo realizado
Criterio de terminacin (incluyendo calidad)
Riesgos asociados a la terminacin con xito
Estimating Tasks
Al recorrer el rbol desde la raz hacia abajo aumentamos el nivel de detalle con lo
cual, nuestra estimacin es ms certera.
Cada nodo medible (generalmente las hojas) se asocia a un Work Packageque
tiene una asignacin directa a un grupo de miembros staff.
Los workpackage representan unidades medidas y seguidas desde el cronograma.
Los milestones sern eventos en los cuales veremos el estado de avance de cada
work package.
Determinar todas las dependencias entre las tareas
Permite optimizar alocacin de recursos y paralelizacin de tareas
Identificacin de Milestones (puntos de revisin)
Rollbacks y ciclos de tareas por chequeos
Ej: el testing puede implicar ajustes en el cdigo
Dependencias externas
Proyectos tcnicos o de negocios
Otros proyectos en la organizacin con impacto en el nuestro
Schedule Creation
Es la secuencia de tareas cuyo atraso provoca atrasos en el fin del
proyecto
Las herramientas lo calculan automticamente
(grafos PERT y Gantt)
Una tarea no crtica tiene un margen de tiempo a partir del cual se
convierte en crtica
Por lo tanto:
El mayor esfuerzo de la estimacin debe ser en las tareas crticas
El anlisis del cronograma tendiente a comprimir tareas debe comenzar
desde las tareas del camino crtico.
Schedule Creation
Camino Crtico
Schedule Creation Camino Crtico
Cada tarea posee un grado de tolerancia denominado floating days que no son
ms que los das que puede excederse la finalizacin de la mismasin producir un
retraso sobre el proyecto en su conjunto.
Las tareas del camino crtico son justamente las que se identifican como 0 floating
days.
Identificar los recursos del proyecto y asignar disponibilidad de
tiempos
OJO: Verificar real disponibilidad y comunicar su asignacin
antes de asignar el recurso al proyecto
Al comienzo del proyecto se debe estimar la duracin de las
tareas asumiendo dedicacin completa de los recursos
Recursos sobre alocados pero se obtiene una estimacin absoluta de
los tiempos del proyecto
Schedule Creation
Alocacin de Recursos
Se identifican y resuelven los conflictos de sobrealocacin
Con cambio del orden y duracin de tareas o asignacin de
recursos
OJO: no olvidar dependencias con otros proyectos
(puede haber recursos compartidos)
Uno de los recursos ms crticos que en general esta
sobrealocado
EL USUARIO
Schedule Creation
Un error muy comn es la sobreestimacin de
la dedicacin completa
Vacaciones/feriados
Enfermedades
Embarazos
Capacitacin
Interferencias por actividades de soporte
Horas reales de trabajo (almuerzos, descansos)
Schedule Creation
Interferencias por actividades de soporte
Se debe buscar organizar los equipos de proyecto de modo que las actividades de
soporte no recaigan sobre los recursos asignados al mismo. De todos modos, dado
que requerimos de usuarios en el equipo, estos recursos difcilmente puedan
desatender la actividad diaria.
Definir en forma dinmica los tiempos de tareas en relacin a las
dependencias
Cada tarea debe tener un entregable que permita la evaluacin de
su concrecin
Establecer milestones (puntos de control) para revisar avance y
plan
Planes de contingencia
Schedule Creation
Consejos
Revisar planes similares y curva de cumplimiento
Integracin: de tareas y como una tarea en s
No olvidarse de las dependencias externas
Otros proyectos
Recursos asignados a otros proyectos
Usuarios
Proveedores
Disponibilidad de hardware y software
Tercerizacin
Schedule Creation
Consejos
Tcnica de control de proyecto que puede ser utilizada
para Scheduling y Plan de recursos
Grfico de barras
Cada barra representa una actividad
Se dibujan contra una lnea de tiempo
La longitud de cada barra representa la longitud de tiempo
de esa actividad
Se le puede asignar a las tareas los recursos
Schedule Creation
Gantt
A
Ejemplo Gantt
A
B
C
D
E
3/4/01 3/5/01 3/6/01 3/7/01 3/8/01
Risk Assessment
El anlisis de riesgos
La ejecucin de Planes de Contingencia.
La evaluacin de nuevos escenarios y consiguientes
nuevos riesgos.
Seguimiento y Supervisin.
Monitorear mediblesdel Proyecto.
Reaccionar en forma temprana a desvos.
Identificar recursos con retrasos y posibles extensiones
en el equipo.
Monitorear riesgos.
Contenido
Plan de Proyecto
Ciclo de Vida
Algunos Modelos
Conclusiones
EUP
Beneficios Clave
Actividades
Relacin entre Core Workflows y Fases del Plan
Conclusiones
Ciclo de Vida
Es el conjunto y la disposicin de las actividades que
suceden desde la concepcin del sistema hasta que el
mismo es desinstalado de la ltima maquina del
usuario.
Tiene como funcin establecer el criterio bajo el cual
proceder de un tipo de tareas a otro.
Ciclo de Vida
Dependiendodel ciclo de vidaqueunoelija, esposiblemejorar la velocidaddel
desarrollo, mejorar la calidad, facilitar el seguimiento, reducir la exposicina riesgoso
mejorar el contacto con el cliente. La eleccinerrneapuedeproducir reduccinen la
productividad, re-trabajo y frustracin.
Code andFix
Especificacin
del sistema (Tal
vez exista)
Release
(Tal vez)
Ciclo de Vida Code and Fix
Esteciclo de vidaes raramente til pero sin embargo altamente utilizado. Si no se ha
explcitamente elejido un ciclo de vidaprobablemente sea steel que estsiendo
usado.
El ciclo comienzacon unaidea general sobre lo quedebeser construido. Es posible
queexistaunaespecificacin, sin ser la mismanecesariaparacomenzar a construir.
Luegose comienzaa usar cualquiercombinacinde metodologas de diseoinformal,
codificaciny testing hastaqueel productoestlistoparaser liberado.
Code andFix
Especificaci
n del
sistema
(Tal vez
exista)
Release
(Tal vez)
Dos ventajas:
No posee overhead.
No requiere ningn tipo de conocimiento.
Muchas desventajas, entre otras:
No tenemos forma de asegurar que existe progreso alguno.
No tenemos forma de controlar la calidad ni de identificar riesgos.
Es muy probable que se alcancen puntos en el proyecto donde sea necesario
descartar absolutamente todo lo realizado.
Puedellegar a ser til parapequeos
proyectosdondese sabede antemano que
el producto serrpidamente descartado.
Ciclo de Vida Code and Fix
El modelo tienedos ventajas. Primero, no poseeoverhead: unosaltadirectamente a
codificar, unocreequeposee inmediatamente signos de progreso. Segundo, no
requiere ningntipode conocimientoexceptosaber programar: cualquiera puede
usarlo.
Para pequeos proyectosque unosabequeserndescartadosrpidamente luegode
ser usados, este modelo puede llegar a ser til (programas de conversinde datos
paraunamigracin, pruebas de conceptoen general, etc.).
Para cualquier otroprojectoestemodeloespeligroso. Puede ser que no tenga
overhead perotampoco tenemos forma de asegurar queexisteprogreso alguno. Uno
codificahastaqueel producto se consideralisto (listo no tienemtricaasociada
tampoco). No tenemos forma de controlar la calidad ni de identificar riesgos. Es muy
probable aqu quese alcancenpuntosen el proyectodonde sea necesariodescartar
absolutamente todolo realizado justamentepor no estar el objetivobiendefinidoy
comprendido.
Pure Waterfall
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificacin y
Debugging
Prueba de
Sistema
Ciclo de Vida Pure Waterfall
Bajoesteciclo de vidael proyectoprogresaa travsde unasecuenciaordenadade
pasosdesde la concepcininicial del Software.
El proyectocontemplaunarevisinal final de cadapasoparadeterminar si se pasar
al siguiente. Esto hacequesea posiblepermanecer por un tiempoindeterminado
sobreunode lospasossi dicharevisinno es alcanzada.
El modelo waterfall esorientadoa la documentacinlo quesignificaquela gran
mayorade losproductos de software queson intercambiados entre etapas son
documentacin. Las etapas no se solapanen este modelo.
Pure Waterfall Salmons Model
Ciclo de Vida Pure Waterfall Salmons Model
Es posible retroceder en las fases pero esto puede costarnos el proyecto
Pure Waterfall
Ventajas
Produce Sistemas Confiables y de alta calidad.
Minimiza el overheadde planning.
Desventajas
Dificultad de obtener requerimientos completamente especificadosal inicio del
proyecto.
La visualizacin de resultados se presenta al finalizar el proyecto.
No es flexible.
No apropiado para desarrollos rpidos por cantidad de documentacin.
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificacin y
Debugging
Pruebade
Sistema
Muy til cuando los requerimientos de calidad
dominanel costo y el cronograma.
Deboconocer muy bienlosrequerimientosy los
mtodos a ser usados.
Ciclo de Vida Pure Waterfall
En proyectosdonde hay altaestabilidad funcionabien. La estabilidadse relacionacon
un granconocimiento de los requerimientosy de losmtodosque sernusados.
En estos casos no slo es un modeloeficientesinoque esel correctoa usar puesto
que tenemos la oportunidadde encontrar erroresde alto impactoen etapas tempranas
y de bajo costo.
El modelo contribuyea a minimizar el overhead en la planificacinporqueesposible
hacer la actividadde planificacinal inicio. Porotraparte, no tenemos resultados
tangibles hastael fin del proyecto. El avancedebeser entoncesmedido a partir de la
documentacingeneradadurante las etapas.
Funcionabiencuando losrequerimientosde calidaddominanel costoy el cronograma.
Las desventajas del modeloradicanen la dificultad de conocer los requerimientos al
100% antes de comenzar a disear.
Sashimi (Waterfall + Overlapping)
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificacin y
Debugging
Prueba de
Sistema
Ciclo de Vida Sashimi
En el modelopuroWaterfall, la documentacinideal es la queespasadade manoen
mano entre losequiposde trabajoqueoperanen lasdiferentes fases. La preguntaes
Por qu?. Si el equipode trabajoesel mismo queopera en cadaunade lasfases,
entonces no es necesariala documentacincreadaparatransmitir el conocimiento
entre fases. Estecambioreduce la documentacina la necesariaparael posterior
mantenimiento del Software.
Sashimi (Waterfall + Overlapping)
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificaciny
Debugging
Pruebade
Sistema
Ventajas
Reduce la documentacin necesaria en el purewaterfall.
Mismas ventajas que el purewaterfall.
Desventajas
Mismas dificultades que el purewaterfall.
Adicionalmente el solapamiento puede ocasionar conflictos relacionados con la
comunicacin entre fases solapadas.
Aplicable en condiciones similares al pure
waterfall pero con equipos ms pequeos.
Asumimosque el mismo equiporealiza
actividades en ms de unafase.
Ciclo de Vida Sashimi
Como existesolpamientoentre fases, los milestones son msambiguos y esto hace
ms difcil realizar el seguimientocon cierto nivel de seguridad.
Efectuar actividades en paralelorequiereque lasactividadessolapadas estnbien
comunicadas, estamosexpuestosa que cambioso novedadesen actividades viejas
no seancomunicadas a las actividades nuevas y por endeexistainconsistenciaa lo
largo del ciclo.
Waterfall with Subprojects
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Prueba de
Sistema
Diseo
Detallado
Codificacin y
Debugging
Prueba de
SubSistema
Diseo
Detallado
Codificacin y
Debugging
Prueba de
SubSistema
Diseo
Detallado
Codificacin y
Debugging
Prueba de
SubSistema
I ntegracin
Ciclo de Vida Waterfall with Subprojects
Otro problemacon el modelo waterfall puro esquese suponequedebemoscompletar
el 100% del diseo arquitectnico antes de comenzar con el diseo detallado, y que a
su vez debemos completar el 100% del diseo detallado antes de comenzar a
codificar. .
Los sistemas tienenciertas reas donde existensorpresas de diseo, pero tambin
existenreas donde la tareaessimple e inclusoen algunos casosconocida. Por qu
entonces retrasar el comienzo de los subsistemas simples a causade la complejidad
de partede la arquitectura?.
Si es posible partir la arquitectura en subsistemas lgicamente independientes se
pueden obtener subproyectos que sean tratados independientemente y en paralelo
hastallegar al momentode integrarlos.
Waterfall with Subprojects
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Pruebade
Sistema
Diseo
Detallado
Codificacin y
Debugging
Pruebade
SubSistema
Diseo
Detallado
Codificacin y
Debugging
Pruebade
SubSistema
Diseo
Detallado
Codificacin y
Debugging
Pruebade
SubSistema
I ntegracin
Ventajas
Permite construir los subsistemas en paralelo.
Desventajas
Posibles problemas de integracin por interdependencias no
identificadas.
Aplicable en condiciones similares al pure
waterfall pero dondeesposible identificar
subsistemas independientes.
El equipode trabajoessuficientemente
grandecomo paraparalelizar el trabajo.
Ciclo de Vida Waterfall with Subprojects
El mayor riesgo de esto es que existan interdependencias no previstas que generen
problemas de integracin. Este riesgo es posible mitigarlo con una actividad de
arquitectura ms intenso que en el caso del pure waterfall, pero nunca podremos
eliminarlopor completo.
Waterfall with Risk Reduction
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificacin y
Debugging
Prueba de
Sistema
Prototipacin
Ciclo de Vida Waterfall with Risk Reduction
Otro de losproblemas del waterfall puro esquees necesario tener unaprecisadeficin
de los requerimientos antes de comenzar con el diseo arquitectnico. Estanecesidad
no solo se encuentraen losrequerimientossinoque es necesario paraingresar en un
fasecontar con granestabilidaden la anterior y con el total de losproductos
requeridosparaingresar en la nuevafase.
Unaposible modificacinleve al pure waterfall es la propuestapor Risk Reduction,
dondese incorporaunaactividad de prototipadode interfaz o de aquellos
componentesde mayor riesgopor la incertidumbre natural al desarrollo de Software.
Estaactividadno necesariamentedebecentrarseen los requerimientossino quees
posible extenderlaal diseoe incluso a la codificacin.
Waterfall with Risk Reduction
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Diseo
Detallado
Codificacin y
Debugging
Pruebade
Sistema
Prototipacin
Ventajas
Reduce el riesgo con respecto al purewaterfall proveniente de los
requerimientos incompletos o mal definidos.
Desventajas
Debo poder identificar las reas donde sea necesaria mayor definicin.
Lo aplicoen loscasosdondeesposible
identificar aquellas reasdonde hacefalta
mayor conocimiento.
(*) Esto no siempre es posible.
Ciclo de Vida Waterfall with Risk Reduction
La actividad de prototipadoes generalmente beneficiosa aunque existe la posibilidad
de no poder recolectar mayor informacin incurriendo en gastos que no tienen rdito
en el proyecto.
Dado que luego de la actividad de prototipadoel ciclo es idntico al pure waterfall
estamos frente a las mismas dificultades que en dicho modelo.
Spiral
Profundidad: 1ero: anlisis, 2do: diseo, 3ero construccin, 4to implementacin
Objetivos Riesgos
Desarrollo Planificacin
Ciclo de Vida Spiral
El ciclo de vidaspiral esun modeloorientadoa riesgos, dondeel proyectoesdividido
en mini-proyectos. Cadaunode losmini-proyectos atiende a uno a ms riesgos
importantes hastaque finalmente todoslos riesgoscon altaexposicinhansido
atendidos.
El conceptode riesgoesel vistoen clase, se refierea requerimientospobremente
entendidos, a arquitecturapobrementedefinidao comprendida, problemas potenciales
de performance, problemas en la tecnologasubyacente, y dems temas del proyecto
dondesea requeridomayor conocimiento.
Unavezquelos riesgos hansido atendidosel ciclo de vidafinalizacomoel pure
waterefall.
La idea detrs del modelo esque unocomienzacon un alcancereducidoen el centro
de la espiral, exploralos riesgos, construyeel plan paraatender los riesgos
encontrados, y luegoplaneael siguienteciclo. Cadaiteracinmueveel proyectohacia
un alcancemsextenso.
Spiral
Inicio
Compromiso
para la siguiente
iteracin
Determinar objetivos,
alternativas y restricciones
A
n
lis
is
d
e
R
ie
s
g
o
s
Prototipo 1, .. 3
Prototipo
O
peracional
Identificar y
resolver riesgos
Evaluar
alternativas
Plan de
Desarrollo
Plan de
Integracin
Plan de
Prueba
Planificar la
siguiente iteracin
Plan de Req.,
Plan de Ciclo
de Vida
Revisin
Simulaciones
Release
Modelos
B
enchm
arks
Construir el
entregable de la
iteracin y verificar
que es correcto.
Diseo
Detallado
Code
Prueba
Unidad Integr.
y
Prueba
Prueba
Acept.
D
ise
o
d
e
P
ro
d
u
c
to
Diseo de
V & V
R
eq
u
er
.
d
e

S
o
ft
.
Validacin
de Requer .
Cadaiteracincomprende 6 pasosrepresentados en loscuadros que rodeanla espiral
del slide.
1. Determinar objetivos, alternativas y restricciones.
2. Identificar y resolver riesgos.
3. Evaluar alternativas.
4. Desarrollar losentregablesde la iteraciny verificar queson correctos.
5. Planificar la siguiente iteracin.
6. Si se decide continuar, obtenercompromisoparala siguiente iteracin.
Objetivos Riesgos
Desarrollo Planificacin
Spiral
Ventajas
Equilibrio ptimo entre exposicin al riesgo e inversin.
Mayor o equivalente control que en el modelo purewaterfall.
Desventajas
Requiere gran conocimiento de gestin por parte de quien dirige el proyecto.
Es posible que si en un momento del proyecto la exposicin al riesgo es baja,
el modelo se vuelva innecesariamente caro.
Modelo orientadoa manejo de riesgos. A medida
queavanzael tiempoy dineroinvertidos, la
exposicinal riesgodisminuye.
En el modeloespiral lasetapas tempranas son las mseconmicas. Unogastamenos
desarrollandoel conceptode operacindel Software de losquegastaen la ingeniera
de requerimientos, y menosen losrequerimientosde lo quegastaen el diseo,
desarrollandoel productoy probndolo.
Unade lasventajas ms importantes del modelo esque el costo aumentaa medida
queel riesgodecrece. A mayor tiempoy dinero invertido, menor la exposicinal
riesgo. Estoesjustamente unode los atributos msbuscados en un proyectode
Software.
El modelo espiral provee igual o mayor control en la gestindel proyectode la provista
por el modelotradicional pure waterfall. Uno cuentacon puntosde control al finalizar
cadaiteracin. Si el proyectoesinviable debido a razones tcnicas o funcionales, es
descubierto stoen forma temprana.
La nicadesventajadel modeloradicaen sucomplejidad.
Requiere de quingestionael proyectoconciencia, atenciny conocimientoen
gestin. Puedellegar a ser difcil definir milestones objetivosy verificables, que
indiquencuando unoesten condicionesde agregar unanuevaiteracin.
En algunoscasosel producto alcanzadoessuficiente, y los riesgos a losque estamos
expuesto moderadoslo suficiente como paraque no sea requerido continuar
pensandoen riesgos, con lo queel modelo orientadoa riesgospropuestoporel ciclo
de vidaespiral se vuelve redundante.
Evolutionary Delivery
Concepto
I nicial
Diseo e
implementacin
del prototipo
Inicial.
Refinamiento
del prototipo
Hasta que sea
aceptable
Completar y
lanzar el
prototipo
Ciclo de Vida Evolutionary Delivery
En estemodelo unodesarrollael conceptodel sistemaa medidaqueavanzosobreel
proyecto.
Usualmente comenzamosdesarrollando los aspectosms visibles del sistema. El
resultadoes mostradoal clientey el productoevolucionaen base a la informacin
obtenidopor parte de ste. En determinadomomento el clienteindicaque el prototipo
essuficientemente bueno, se completanlas tareas remanentes, especialmente las
relacionadas con performance, y el prototipose convierte as en el release.
Evolutionary Delivery
Concepto
I nicial
Diseo e
implementacin
del prototipo
I nicial.
Refinamiento
del prototipo
Hastaquesea
aceptable
Completar y
lanzar el
prototipo
Ventajas
Extraccin de requerimientos incremental y buena interaccin conel
cliente.
Desventajas
Peligro de que se convierta en Code& Fix.
Puede no converger a una solucin.
Modelo orientadoa proyectosdonde
no existe unabuenadefinicinde
requerimientos
Ciclo de Vida Evolutionary Delivery
Este modelo esespecialmetne til cuandolos requerimientosson dinmicos o
pobrementedefinidos. Tambines til cuandoel cliente no tiene la capacidado
voluntad paracomprometersecon un requerimiento mejordefinido, o no existenadie
queconozcabienel dominio de problema.
La mayor desventajade estemodeloradicaen que no esposible saber en qu
momentoel productoconvergera la solucin. Unodesconocecuantas iteraciones
debernser necesarias paraobtener finalmente el producto.
Otradesventajaesqueel modelo fcilmentese convierteen Code & Fix. Distinguimos
evolutionary delivery de code & fix principalmenteporquela actividadde
especificaciny diseoexistenen el primer modelo.
Staged Delivery
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Etapa 1:
Diseo detallado, Codificacin, Prueba, entrega.
Etapa 2:
Etapa n:
Ciclo de Vida Staged Delivery
El ciclo de vidastaged delivery esun modeloen el cual uno muestrael producto al
cliente en etapas sucesivas, aumentandoen cadaunael nivel de refinamiento. En este
modelo unoconoceexactamente lo que vaa construir desdeel comienzo, pero
planificala entregaen etapas (diferenciacon el modelo evolutionary delivery).
Staged Delivery
Concepto
Anlisis de
Requerimientos
Diseo
Arquitectnico
Etapa 1:
Etapa 2:
Etapa n:
Ventajas
Las funciones principales sen entregan antes.
El feed-back del cliente aumenta a medida que la funcin es ms
esencial para el producto...
Signos tempranos y tangibles de avance.
Desventajas
Posibles interdependencias entre etapas no identificadas.
Modelo orientadoa dividir el
requerimientoy realizar un despliegue
incremental.
Ciclo de Vida Staged Delivery
A nivel de gerenciamiento, se debeestar seguroquelasetapas tienensentidocon
respecto al usoqueel clientele dar, y que el entregable de cadaunade ellas est
autocontenido
A nivel tcnico, se debeasegurar quelasdependencias entre losentregablesde las
etapas no impidenqueel productosea construidoindependientemente.
La ventajaprincipal del modelo radicaen que nospermite entregar la funcionalidad
pricipal al principio del proyecto. Si lasetapas son planeadas con cuidado, podemos
reducir el riesgoen lospuntoscentrales del Software entregndolosprimeroy
pudiendo as obtener feed-back operacional antes del fin del proyecto, cuandoan
podemos toamar medidas correctivas. Otraventajaesqueproveesignos tangibles de
avancedesdeetapas tempranas, lo que facilitael control sobrepresinque pueda
ejercerel cliente.
Contenido
Plan de Proyecto
Ciclo de Vida
Algunos Modelos
Conclusiones
Conclusiones
Contenido
Plan de Proyecto
Ciclo de Vida
Algunos Modelos
Conclusiones
EUP
Beneficios Clave
Actividades
Relacin entre Core Workflows y Fases del Plan
Conclusiones
Contenido
La clase se centrar sobre los pasos para la preparacin del work-plan. Se debe tener una nocin acerca
del resto de las actividades que desarrollamos durante la creacin del Plan.
Conclusiones
Un Plan de Proyecto requiere gran cantidad de
informacin.
No contamos con toda ella en el momento de la
construccin.
No es posible hacer un seguimiento sin un plan de
trabajo acorde.

PlanProyecto (IncWBS) 20050905 CONNOTAS

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

PlanProyecto (IncWBS) 20050905 CONNOTAS

Cargado por

Copyright:

Formatos disponibles

Ingeniera de Software II

Preparacin de Plan de Proyecto 1

También podría gustarte