dirección de proyectos€¦ · 2 introducción • los que intentan utilizar rup, a menudo dejan...

1

Dirección de Proyectos

Prof. Gustavo J. Sabio

Plan de proyecto en el software

Agenda de la presentación

1. Introducción al Plan de proyecto en el UP

2. ¿Cómo desarrollar un plan de proyecto?

3. ¿Cómo desarrollar un plan de iteración?

4. Conclusiones

2

Introducción

• Los que intentan utilizar RUP, a menudo dejan de lado la disciplina de “Dirección de Proyectos”.

• La planificación del proyecto es una actividad crítica para el desarrollo de software.

• Buenas planificaciones ayudan al equipo de desarrollo a lograr un conjunto de metas establecidas en un período de tiempo determinado.

• Este curso se basa en la disciplina de Dirección de proyectos deRUP.

Introducción

• Objetivos del Curso:

– Colaborar con Líderes de proyecto que estén a punto de embarcarse en el proceso de planear un proyecto de desarrollo de software.

– Describir un acercamiento práctico para el armado de planificaciones basada en al disciplina de Dirección de Proyectos propuesta por RUP.

– Discutir cómo crear un plan de proyecto sólido y un plan de iteración para cada fase del proceso.

– Discutir cómo personalizar el proceso de planificación para que se adaptarse a un entorno de desarrollo en particular

3

Hablemos del plan de proyecto…

• La naturaleza de un proyecto de desarrollo de software presenta 2 problemas: Invisibilidad e intangibilidad

• La solución: la abstracción mediante el uso de modelos!

– Modelo el negocio, modelo los requisitos, otros

– Modelo de la estructura lógica y física del sistema

– Modelo los casos de prueba

– cuenta con un Plan de Proyecto

• Plan de proyecto: Es el modelo con el que trabaja el líder y comparte con el equipo.

Analista

Arquitecto

Tester

Líder de P

Funciones de un buen plan de proyecto:1. Ayudar al gerente a planear el flujo de dinero en efectivo y programado

para el proyecto

2. Comunicar lo que va a ser entregado y cuando

3. Identificar qué recursos deben estar disponibles y cuando son requeridos

4. Ayudar a evitar interferencias entre los recursos compartidos y las diferentes actividades

5. Ayudar al equipo a saber quién está haciendo qué en el proyecto

6. Brindar una base para medir progresos y gastos

7. Proveer una base para poder replanificar actividades si es necesario.

8. Ayudar al cliente y a la dirección a “ver” cualquier contingencia que se presente durante la ejecución del proyecto.

4

Actividades de un buen plan de proyecto:

• Basado en objetivos – identificación de entregables.

• Asignación de Tareas a cargo de los miembros del equipo.

• Vistas con diferente información (clientes, miembros del equipo, y dirección)

• El plan es mensurable desde una perspectiva de tiempo así como de una perspectiva de entregas del proyecto.

• El plan está actualizado. Conexión con las tareas ejecutadas en el proyecto y es el primer lugar en el cual el gerente del proyecto mira al evaluar el progreso. Si un plan del proyecto se vuelve secundario al evaluar su estado, no se está usando correctamente.

Características de un proyecto RUP

Un proyecto según el UP tiene dos aspectos principales que son importantes para el plan de proyecto:

• Los proyectos RUP son iterativos

• El progreso del proyecto es moderado contra

hitos claros

5

Proyecto RUP: Desarrollo iterativo

• El UP es un proceso incremental con el cual el proyecto global es dividido en fases e iteraciones

• Las iteraciones son de riesgo controlado - es decir, orientadas a mitigar los riesgos –

• Cada iteración debe entregar un software ejecutable que sea demostrable y pueda ser probado contra los requisitos del proyecto y casos de uso

• El gerente del proyecto usa el plan de iteración para manejar el proyecto.

Proyecto RUP: Desarrollo iterativoUn PLAN DE ITERACIÓN:

• Proporciona una descripción detallada de la próxima fase de trabajo,

• Define los roles del trabajador, actividades necesarias y artefactos a ser entregados en esa iteración,

• Delinea un conjunto muy claro de criterios de medida para que pueda evaluarse el progreso durante la iteración y determinar suéxito.

• Definir las fechas de inicio y término, y fechas de entrega.

6

Proyecto RUP: Hitos claros

El software debe mostrarse a los clientes durante esta fase.

Transición

El software debe construirse en esta faseConstrucción

La arquitectura así como los requisitos del producto que está comenzando a construirse deben entenderse a finales de esta fase.

Elaboración

El enfoque de esta fase es entender el alcance del proyecto.

Inicio

Proyecto RUP: Hitos claros

• Los hitos para una fase mantienen un enfoque para las iteraciones …

• Cada iteración “mueve” el proyecto a través de ciertos hitos

• Los hitos definidos en RUP son por necesidad bastante generales; el líder del proyecto refinará los hitos para enfocar al equipo en las necesidades particulares del proyecto en el contexto organizacional.

• El objetivo de una iteración es mitigar el riesgo y cumplir contra los criterios del hito

7





4. Conclusiones

Cómo construir un Plan de Proyecto

• Para comenzar debemos planificar el proyecto.

Tenemos dos tipos de planificación:

– El Plan de proyecto en su conjuntoDesarrollar un “plan genérico” para el proyecto entero

– El Plan de iteración específicoDesarrollar un “plan refinado” para cada próxima iteración

8

Pasos para desarrollar un plan de proyecto

1. Desarrollar Actividades de Inicio del Proyecto

• Desarrollar un Caso de Negocio

• Identificar y Evaluar Riesgo

• Iniciar el Proyecto

2. Definiendo la Organización del Proyecto y el Equipo de Trabajo

3. Compilar el Plan de Desarrollo de Software

• Definir la Estructura del Proyecto

• Estimar el Tamaño del Proyecto

Desarrollar actividades de Inicio

• ¿El proyecto está entre los intereses de su organización?

• Es necesario determinar la factibilidad económica del proyecto, identificar y evaluar los riesgos, luego dar el puntapié inicial.

1. Desarrollar un Business Case2. Identificar y Evaluar Riesgos3. Iniciar el Proyecto

9

Workflow Disciplina PM










10

Concebir un nuevo proyecto

Desarrollar un Caso de Negocio

• El líder del proyecto documenta el valor económico del producto propuesto.

• El artefacto resultante será el instrumento para fundamentar el proyecto frente a los stakeholders y lograr consenso y acuerdo.

• Asegurarse que en su compañía es necesario emprender este proyecto.

• El tiempo gastado poniendo a punto el Caso de Negocio es tiempo bien gastado.

• El consenso permite lograr compromiso de su organización.

11

Pasos para desarrollar el Caso de Negocio

1. Describir el producto y la necesidad que cubre.

2. Definir los objetivos de negocio y el mercado intencional para el producto.

3. Definir objetivos del producto y del proyecto a un alto nivel.

4. Desarrollar una previsión financiera incluyendo las utilidades y costos del proyecto.

5. Describir las restricciones del proyecto que podrían potencialmente impactar en forma de riesgos y costos.

6. Describir los supuestos que asegurarían el éxito del proyecto. BusinessCase










12


Identificar y Evaluar los riesgos

Es una tarea inicial muy importante!

En la vida cotidiana un riesgo es: “una exposición a una pérdida o lesión; un factor, una cosa, un elemento, o un camino que involucra un peligro incierto”.

En el ámbito del software…

Un riesgo es: “una variable que puede tomar un valor que pone en peligro el éxito de un proyecto”

Es cualquier cosa que se nos interponga en nuestro camino hacia el éxito.

En el presente es desconocido o incierto

13

Análisis de Riesgos

Tipos de RiesgosDirecto: El proyecto tiene un alto grado de control sobre él Indirecto: El control que se tiene sobre él es mínimo o nulo

Atributos de un riesgo: – La probabilidad de ocurrencia– Impacto en el proyecto (la severidad o daño)

– Los dos pueden combinarse a menudo en un solo indicador: Magnitud del riesgo:

• Alto, Significante, Moderado, Menor, Bajo.

Estrategias para abordar los riesgos

La idea clave en la dirección de riesgos es no esperar pasivamenteno esperar pasivamente hasta que un riesgo se materialice y se vuelva un problema para el proyecto.

Para cada uno de los riesgos identificados usted decide de antemano lo que va a hacer.

1. Anular el riesgo: reorganice el proyecto para que no pueda ser afectado por ese riesgo.

2. Trasladar el riesgo: reorganice el proyecto para que alguien (o algo) más lleve el riesgo (cliente, vendedor, etc.)

3. Aceptar el riesgo: decida vivir con el riesgo como una contingencia. Debe monitorear el estado del riesgo

• Mitigar el riesgo: tomar alguna acción inmediata, en forma proactiva para reducir la probabilidad o el impacto del riesgo

• Definir un plan de contingencia: Es el curso de acción que debería tomar si el riesgo se a vuelto un problema real.

14

Pasos para Identificar y Evaluar los riesgos

1. Identificar riesgos potenciales que atenten contra el nivel especificado de calidad, el tiempo y el presupuesto.

2. Analizar y priorizar los riesgos estimando el impacto de cada uno y su probabilidad de ocurrencia.

3. Identificar las estrategias de anulación del riesgo.

4. Identificar las estrategias de mitigación de riesgo.

5. Identificar las estrategias de contingencia de riesgo.

6. Revisar frecuentemente los riesgos dentro de las iteraciones y las fases subsecuentes.

ActividadActividadIyEIyE

RiegosRiegos

MatrizMatrizdede

RiesgosRiesgos

Niveles de la gestión de Riesgos

1. Controlar la crisis• Apagar el incendio. Controlar los riesgos una vez que son problemas

2. Arreglar los imprevistos• El riesgo ya se produjo. Hay que reaccionar lo más rápido posible

3. Mitigar los riesgos• Planificar con antelación que hacer si sucede el riesgo.

4. Prevención• Tener una política de Riesgos como parte del plan de proyecto

5. Eliminación de causas raíz• Analizar el problema detrás del problema y anular el riesgo

15

Composición de la gestión de Riesgos

Identificación de Riesgos

Análisis de Riesgos

Priorización de Riesgos

Planificación de la GR

Resolución de Riesgos

Monitorización de Riesgos

Estimación de Riesgos

Control de Riesgos

Gestión de Riesgos

Dimensiones de un desarrollo efectivo

Personas

Proceso Producto

Tecnología

Trabajan rápida o lentamenteSe destacan en lo que hacen o no

Supone una mejora en las actividades de las personas o burocratiza la situación

Está definido de tal manera que se construye casi solo o pone trabas a los mejores esfuerzos de quienes lo construyen

Ayuda al esfuerzo del desarrollo u obstaculiza los mejores intentos de los desarrolladores

Se deberían potenciar entre cada una de ellas

16

PROYECTOPROYECTO

PROCESOPROCESO

PERSONASPERSONAS

TECNOLOGÍATECNOLOGÍA

PRODUCTOPRODUCTO

....participantes...

....plantilla...

....resultado...

....automatización...

¿Qué comprende el desarrollo de software?

Relación entre las dimensiones

Errores clásicos y los Riesgos!

• ¿Qué es un error clásico?– Hay que salvar un proyecto retrasado…– Hay que acortar el plan…– Algunos de los miembros claves incomoda al equipo…– Debemos acelerar para terminar…– Etc…

Analogía con “La Isla de Gilligan”

17

La importancia de las personas

• motivación débil• Personal no capacitado• Personal problemático incontrolado• Creer en hazañas• Agregar personal a un proyecto retrasado• Fricciones entre clientes y desarrolladores• Expectativas poco realistas• Falta de participación del usuario

Errores Errores clásicosclásicos

La importancia del proceso

• Planificación excesivamente optimista• Gestión de riesgos insuficiente• Pobre comunicación con mis proveedores• Planificación insuficiente• Abandono de los planes bajo presión• Diseño inadecuado• escatimar en el control de calidad• Falta de supervisión de quién dirige• Omitir tareas necesarias para la estimación• Programación a destajo


18

La importancia del producto

• Exceso de requerimientos• Cambio de funcionalidad• Desarrolladores meticulosos• Desarrollo orientado a la investigación


La importancia de la Tecnología

• Síndrome de la panacea• Sobre estimación de las ventajas de usar nuevas herramientas o métodos• Cambiar de herramienta a mitad de proyecto• Falta de control de versiones del código fuente


19

Ranking de Riesgos semanal

El proyecto anterior ha sido derivado a otro responsable

Dispersión del LP en otro proyecto

56-

Se ha terminado a tiempo el primer hitoPlanificación demasiado optimista

547

Se han identificado las causas. Se discutirán en la próxima reunión de los

lunes.

Lenta Revisión de la Dirección

1-6

En evaluaciónLenta Revisión del cliente

1-5

Contamos con 5/7 herram.Contrataciones ha reclamado el resto.

Retraso en entrega de herr. desarrollo

234

Se inició proceso de búsqueda y selección. Estamos a la espera

Falta contratar un tester funcional

423

Diseño en marcha. Seleccionar e incorporar expertos de dominio

Diseño inadecuado. Volver a diseñar

552

Emplear entregas por etapas. Explicar a los consultores comerciales

Cambio de funcionalidad

511

Progreso de la Resolución del riesgoRiesgoSem enlista

Sempasada

Semactual










20


Iniciar el proyecto

• La actividad de iniciar un Proyecto se lleva a cabo después de que el caso de negocio del proyecto es aceptado.

• Objetivos:

1. Definir el comité de Dirección del proyecto

2. Designar el líder de proyecto

3. Designar el equipo de planificación del proyecto.(Project Manager, Software Architect , System Analysts, Development Lead, Test Lead, Configuration Management Manager, Customer representative)

4. Identificar los criterios de aceptación final del proyecto

ActividadActividadIniciarIniciar

ProyectoProyecto

21

Iniciar el proyecto

Consiste en estos pasos:

• Asignar una autoridad de revisión de proyecto responsable de vigilarlo. Para los proyectos pequeños, esta autoridad puede ser una sola persona.

• Asignar un equipo de planificación de proyecto, un grupo de miembros del equipo de proyecto que llevarán a cabo el trabajo de planeamiento, manteniendo y que continuamente informará su estado.

• Aprobar los criterios de aceptación del proyecto - Aquellos objetivo que será usado por el cliente o las partes involucradas importantes para determinar cuando los artefactos entregados por el proyecto son aceptables.










22


Planear el proyecto

23

Definir la Organiz. del proyecto y Equipo

1. Definir la organización del proyecto • Basado en las características del proyecto y restricciones.• En términos de posiciones, responsabilidades, jerarquías,

comités y equipos de trabajo.

2. Definir el equipo de proyecto.• Definir los requisitos del personal (habilidades,

competencias, experiencia)• Tipo y número• Basarse en las estimaciones del esfuerzo realizadas• Ajustarlo a medida que se avance en el ciclo de vida

• (inicio: funciones de dirección, elaboración: analistas y arquitectos, construcción: desarrolladores; y transición: analistas funcionales)

Gestión con estructuras de Comités

Se deben proveer las condiciones necesarias que garanticen una eficiente administración del proyecto. Por lo que es aconsejable establecer los siguientes comités:

Comité de proyectoSe deberá integrar un comité de proyecto que establecerá una serie de reuniones semanales a fin de llevar el control del proyecto en cada paso. Este comité contará, entre otros, con:

– Por Proveedor: un líder de proyecto; un líder de QA (aseguramiento de la calidad); un líder de desarrollo

– Por Organismo: un usuario clave por parte para cada área del Organismo; un miembro de QA; el patrocinador

Comité de riesgosTiene como finalidad contemplar todos los riesgos que pudieran afectar al proyecto, establecer cuáles son los principales riesgos de entre los detectados, actualizar semanalmente la lista de principales riesgos, establecer la forma de mitigación de cada riesgo, determinar los planes de contingencia.

– Estará integrado por miembros del Proveedor y del Organismo, pero de ningún modo estará involucrado el líder del proyecto.

24

Estructura de comités…

Comité de administración de requisitosMuy probablemente los requisitos cambien durante la vida del proyecto, por lo que deberá haber un comité que decida cuáles de todos los cambios deberán ser contemplados en el proyecto y evaluar su impacto.

– Estará integrado por miembros del Organismo y del Proveedor: usuarios claves, líder del proyecto, miembros de QA, miembros de desarrollo, etc.

Comité de calidadRealizará dos tareas básicas: asegurar y controlar la calidad del proyecto y del producto. El aseguramiento se realizará mediante tareas normales de verificación de la calidad, mientras que el control se llevará a cabo a través de controles aleatorios sobre todo lo realizado y lo que se está realizando.

– Estará integrado por miembros del Gobierno y del Proveedor. No estará involucrado el líder de desarrollo.

Ver QA

Estructura de comités…

Comité de administración de versionesCustodiará las diferentes versiones de los artefactos (productos, documentos, modelos, etc.) que el desarrollador entregue, manteniendo la traza de las versiones de cada uno de ellos.

– Estará integrado por miembros del Proveedor y deberá informar periódicamente al líder de QA (aseguramiento de la calidad) del Organismo, además de mantener absolutamente disponibles todas las versiones en todo momento.

Comité de administración de configuracionesTanto el producto final como los ambientes de desarrollo y prueba deben funcionar sobre las configuraciones adecuadas.

– Estará integrado por miembros del Organismo y del Proveedor

25











26

Planear el proyecto

Compilar el Plan de Desarrollo de Software

El próximo paso crítico del desarrollo de un plan de proyecto es la creación del plan de desarrollo de software (SDP).

• Sirve para coordinar todos los planes y contenidos que se handesarrollado hasta aquí y colocarlos en un único documento, el SDP.

• Se ejecuta durante la fase de inicio y temprano en la elaboración. En las siguientes fases se lo revisa al comienzo.

• El líder de proyecto se debe asegurar que el SDP contiene o hacereferencia a la información apropiada. Ej:

• Measurement Plan • Requirements Management Plan • Risk Management Plan • Product Acceptance Plan • Problem Resolution Plan

ActividadActividadCompilarCompilar

el SDPel SDP

27

Algunos planes de soporte

Puede suceder que por la magnitud y relevancia que alcancen a tener cada uno de estos temas, amerite que sean tratados en planes por separado.

- Plan de control de cambios:Para llevar el control de los cambios en los requisitos que surgen a lo largo del proyecto y así poder administrar cuáles se implementarán, cuáles no y en qué orden se realizarán las implementaciones de los cambios.

- Plan de administración de versiones:Para mantener la versión de cada uno de los documentos, modelos,programas, en otras palabras, de todos los productos intermedios que se vayan produciendo.

- Plan de aseguramiento de la calidadPara asegurar la calidad de cada uno de los productos intermedios (documentos, programas, planillas en general, etc.) y para realizar control sobre diferentes versiones intermedias

Algunos planes de soporte (cont…)

- Plan de pruebasContiene estrategias de pruebas unitarias (se prueba cada programa individualmente), de integración (se prueba cada programa integrado al resto), de aceptación (se prueba cada programa con el usuario para que lo acepte), de regresión (cada vez que se detectan errores en las pruebas y se corrigen, existe la posibilidad de que se afecte a programas que antes funcionaban bien).

- Plan de trazabilidad de los requisitosTiene el objeto de asegurar que cada requisito de software esté vinculado a su respectivo requisito del negocio. Es menester poder seguir la pista de los requerimientos de software, desde su origen en alguna necesidad del negocio hasta su implementación en el software

- Matriz de riesgosPermite la identificación de cada riesgo, con sus respectivos responsables, estrategias de mitigación y planes de contingencia. Se deben mantener permanentemente actualizados los riesgos del proyecto, estableciendo semanalmente los que aparezcan y cambiando las prioridades a medida que cambia la realidad.

Ver ej trazabilidad

28

SDP: Definir estructura del proyecto

Podemos apreciar que el SDP tiene muchas secciones.

Veamos distintas plantillas propuestas para un SDP

La mayoría de las actividades del SDP hablan fundamentalmente dedos cosas:

1. Definir la Estructura del Proyecto2. Estimar el Tamaño del Proyecto

SDPSDP# 1# 1

SDPSDP# 2# 2

SDPSDP# 3# 3

SDPSDP# 4# 4

SDPSDP# 3# 3

SDPSDP# 4# 4










29


¿Cuánto esfuerzo hay que dedicarle a cada fase?

Se plantea la siguiente estimación aproximada:Fase Inicio: 5%Fase Elaboración: 20%Fase Construcción: 65%Fase Transición: 10%

Debemos analizar las condiciones particulares de nuestro proyecto.

la estructura puede cambiar si no se pasan los hitos de la fase o si los proyectos encuentran problemas.


¿Fase de Inicio compleja?

¿Se realizará Modelado de

negocios y modelado de software ?

Considerar el esfuerzo de la reingeniería de procesos del negocio.

¿ Es necesario entender un sistema

existente ?

se necesitan dos iteraciones -una enfocada en el sistema existente y la otra en el nuevo sistema.

Fase de inicio compleja = aumentar 5% de esfuerzo !

30


¿Fase de Elaboración compleja?

¿Se cuenta con algo similar al sistema a

construir?

Llevará tiempo construir la nueva arquitectura.

¿Se reutilizarán componentes

preconstruidos?

Existen supuestos sobre la arquitectura. Se reduce el esfuerzo

¿el equipo trabajará con tecnología

nueva?

Contemplar la curva de aprendizaje

Fase de Elaboración compleja = aumentar 5% de esfuerzo !


¿Fase de Construcción compleja?

¿Existe ambiente de prueba?

Se pueden realizar múltiples pruebas de integración.

¿Equipo de desarrollo distribuido?

Se aumenta la complejidad en el proceso de construcción

¿Metodología de desarrollo familiar?

No sentirse a gusto con el lenguaje y tecnología empleada

Fase de Construcción compleja = aumentar 5% de esfuerzo !

31


¿Fase de Construcción compleja?

¿Correr una versión beta?

Al menos se necesitarán 2 iteraciones.

¿Despliegue incremental?

Se deben determinar los incrementos. Por ejemplo primero casa matriz, luego sucursales.

Fase de Transición compleja = aumentar hasta el 15%!










32

SDP: Estimar tamaño del proyecto

Generalmente los patrocinadores desean estimaciones de tiempos y presupuesto en etapas tempranas.

• Dificultades para la estimación:– Invisibilidad– Complejidad– Flexibilidad

• Proceso esencial de estimación– Estimación del tamaño– Estimación del esfuerzo– Estimación de la planificación

Gestión del proyecto

Estimación del proyecto

1

1. Modelo de CU 2.Estimar complejidad 3.Ajuste personalizado 4. Estimación Factores

Actores(simple:1; medio:2;

complejo:3)

Casos de Uso(simple:10; medio:20;

complejo:30)

Ambos tienen:Valor: “Influencia”Peso: “dificultad”

UAW

UUCW

UUCP

UAW: Peso de todos los actores sin ajustar.UUCW: Peso de todos los CU sin ajustar.UUCP: Peso del modelo de CU sin ajustarTCF: Factores Técnicos (su valor * su peso = su peso en el proyecto) ECF: Factores de entorno (idem anterior)UTV: Valor de todos los TCFs sin AjustarUEV: Valor de todos los ECFs sin Ajustar

TCF ECFSuma todos

TCF

Suma todos

ECF

UTV UEV

33

Gestión del proyecto

Estimación del proyecto

1

5. Ajuste de los factores

UUCP: Peso del modelo de CU sin ajustarTCF: Factores Técnicos (su valor * su peso = su peso en el proyecto) ECF: Factores de entorno (idem anterior)UTV: Valor de todos los TCFs sin Ajustar.UEV: Valor de todos los ECFs sin Ajustar.TC: Cantidad en que influyen los factores técnicos en el ajuste de estimaciónTWF: El peso del factor TCFEC: Cantidad en que influyen los factores de entorno en el ajuste de estimaciónEWF: El peso del factor ECF.Unid. Hora: Son las horas por punto de CU (entre 10 y 30)

TCFTCF: TC + (TWF x UTV)

…

ECFECF: TC + (EWF x UTV)

6. Ajuste del UUCP

UCP = UUCP x TCF x ECF

7. Estimación en horas

Horas = UCP x Unid. hora





4. Conclusiones

34


Planear próxima iteración

35

Desarrollar el Plan de Iteración

• Se desarrolla antes de cada iteración.

• Determina objetivos claros en búsqueda de los objetivos de la fase.

• Asocia las actividades requeridas para lograr el objetivo.

¿Cómo desarrollarlo?1. Considerar la Fase actual2. Determinar los Entregables3. Seleccionar una Plantilla de flujo de Trabajo apropiada 4. Asociar los Recursos con las Actividades5. Definir procesos de Monitoreo y Control6. .Evaluar las Iteraciones

PlanPlanIteraciónIteración

Plan Plan IteraciónIteración(informal)(informal)

PDI: 1. Según la Fase actual…• Ej: Fase de INICIO - Objetivos:

1. Establecer el alcance y límites del proyecto, y una visión que marque el “norte” del proyecto.

2. Lograr definir una arquitectura candidata.

3. Determinar los casos de uso críticos del sistema.

4. Estimar el costo global del proyecto completo (e inmediatamente con más detalle para la fase de la elaboración).

5. Estimar los riesgos potenciales (las fuentes de impredecibilidad).

6. Preparar el entorno de soporte para el proyecto.

Cada uno de estos objetivos se asocia por lo general con un Cada uno de estos objetivos se asocia por lo general con un entregable.entregable.

36

PDI: 2. Determinar Entregables

• Comprendiendo los objetivos, se tiene que artefactos se deben conseguir.

Un artefacto tiene asociado:– Una actividad: con ciertos pasos para lograr el artefacto– Una plantilla: Estructura sobre la que se construye el

artefacto– Un Rol: Responsable por la actividad y el artefacto.– Otros artefactos: necesarios como entrada para la

actividad – Un estado: que refleje su condición

……Ir a objetivos de FaseIr a objetivos de Fase

PDI: 2. Determinar Entregables

Lista de entregables de un proyecto “estándar”:

• Arquitectura del Negocio Describe los procesos del negocio. Es necesario sólo si se está emprendiendo el negocio planeando.

• Modelo del NegocioInformación del producto a construirse y criterios de éxito para el proyecto.

• VisiónDefine lo que el producto hace, el mercado al que apunta, y los rasgos principales del producto.

• Modelo de CUDefine los requisitos funcionales del sistema.

• Requisitos ComplementariosDefine requisitos complementarios o no funcionales del sistema.

• Caso de Uso - Describe un servicio proporcionado por el sistema.

• Prototipo de interfaz de Usuario - Simula la interfaz del usuario, como definirlas y probarlas por los usuarios. Esto es muy importante si el sistema tiene una GUI muy compleja o tiene una serie de requisitos no funcionales relacionados a la interfaz

37

PDI: 2. Determinar EntregablesLista de entregables de un proyecto “estándar” – continuación - :

• Modelo de Análisis - Identifica abstracciones importantes que constituyen el sistema.

• Lista de Riesgo - Describe los riesgos a ser mitigados durante cada iteración.

• Componente - Consiste en una unidad ejecutable de código a ser desplegado en el sistema ejecutable.

• Construcción - Grupos y una serie de componentes dentro de un sistema entero.

• Prueba Funcional - Prueba la funcionalidad necesitada para cumplir un requisito particular.

• Solicitud de Cambio – Es una petición, proveniente de un problema u oportunidad de mejora sobre la funcionalidad determinada al inicio.

• Entorno de Prueba - configura el entorno de prueba para una iteración.

• Entorno de Desarrollo - Configura el entorno de desarrollo y maneja los cambios a este ambiente.

PDI: 3. Seleccionar flujo de trabajo

Tiene mucho que ver con el “ciclo de vida” que hayamos elegido.

Ej: Iterativo e incremental por etapas

Con un plan de versiones a entregar que estarán definidas en forma consensuada por el comité de proyecto.

– El modelo consiste en aplicar “cascada con retorno” en las primeras etapas del proyecto para luego profundizar en los aspectos de cada versión a entregar mediante un modelo iterativo e incremental.

– Se conocen las prestaciones principales que se desean del software.– Un análisis y diseño de “toda” la solución permitirá asegurar la integridad

del software– Al no ser “cascada pura”, se prevé poder redefinir etapas tempranas sin

costos ni retrasos– Las entregas por etapas minimizan los riesgos y permite que se visualizan

“tangibles” durante toda la vida del proyecto– Se cuenta con el compromiso de la gente que puede ir observando

resultados

38

PDI: 3. Seleccionar flujo de trabajo

Ciclo de vida iterativo e incremental por etapa

PDI: 3. Seleccionar plantilla de trabajo

– Para cada entregable, hay en el RUP una plantilla de flujo de trabajo asociada que identifica las actividades requeridas para comprender este entregable.

– Una actividad incluye papeles, artefactos, y guía (pasos de ayuda).

– Ciertas actividades pueden no ser apropiadas para su proyecto particular o iteración, y éstas pueden omitirse.

– La cantidad de tiempo permitido para las actividades dependerá del total de tiempo asignado para esta iteración en el plan del proyecto.

39


Administrar la Iteración

40

PDI: 4. Asociar recursos con actividades

• Las actividades comprendidas en la iteración, deberán ser asignadas a un responsable determinado.

• El líder de proyecto debe reemplazar los roles con los nombres de las personas que los cumplirán de acuerdo a sus competencias y habilidades


41

Control y monitorear el proyecto

PDI: 5. Monitorear y controlar

¿Cómo saber si el proyecto va por buen camino? ¿Qué hacer para retornar un proyecto desviado?

El líder del proyecto necesita contar con señales vitales del proyecto mediante observaciones sobre el SDP.

El RUP sugiere que los líderes del proyecto hagan lo siguiente:

1. Definir indicadores del proyecto que permitan oportunas acciones correctivas.

2. Definir las fuentes para alimentar los indicadores del proyecto.3. Definir y comunicar al equipo un procedimiento para informar

regularmente sobre el estado de los indicadores4. Definir niveles de alerta para los indicadores del proyecto. 5. Definir un procedimiento para informar del estado del proyecto

ActividadActividadMonitorearMonitorear

el SDPel SDP

42


Administrar la Iteración

43

PDI: 6. Evaluar la iteración

Después de completar una iteración, el líder del proyecto y el equipo deberían evaluar la iteración y capturar las

lecciones aprendidas.

• Recopilar información y medir el progreso del proyecto para la toma de decisiones.

• Evaluar los resultados reales de la iteración contra los resultados esperados según la planificación

• Examinar el criterio de evaluación para asegurar metas realistas.

• Usar los resultados de la valoración para generar demandas de cambio para la visión, la lista de riesgo, el plan del proyecto, planes de iteraciones subsecuentes, o el caso de desarrollo y requisitos si es requerido.





4. Conclusiones

44

Relación entre PMBOK y UP

Puede ser adaptado para usarlo en proyectos de software de cualquier tamaño

Describe guías para proyectos de cualquier tamaño

Prescribe un proceso de desarrollo de software incluyendo un ciclo de vida de proyecto

Describe un ciclo de vida de proyectos genérico

RUP ayuda al equipo de desarrollo a implementar las mejores prácticas de la IS

Describe una guía basada en las mejores prácticas de la industria

RUPPMBOK

Relación entre los modelos

El framework del PMBOK es implementado durante cada iteración. Adopta las mejores prácticas en la disciplina de la Dirección de Proyecto.Es necesario adaptar el RUP para incorporar los elementos claves del PMBOK.

45

Conclusiones finales

46

Skills

The following skills are recommended to fulfill the Project Manager role:

• experience in the software development lifecycle, the domain of the application and platform

• scope estimation, planning, time management, scheduling, project costing, and budget management

• resource planning, resource management, and procurement

• risk analysis, dependencies, and decision analysis skills

• presentation, communication, and negotiation skills

• experience in Project Management

• leadership and team building capabilities

• conflict resolution, problem solving skills, and the ability to make sound decisions under stress

• deliverables based management, a focus on the delivery of customer value, in the form of executing software that meets (or exceeds) the customer's needs.

Role assignment approaches

• For smaller projects, a single person can act as project managerand also take on a development role, such as software architect.However, if at all possible, it is generally better for the project manager to avoid taking on development responsibilities, in order to ensure that time pressure on management responsibilities doesn't cause development tasks to suffer, and vice versa.

• The project manager role can usually be combined successfully with other management-type roles, such as Change Control Manager, Deployment Manager, and Process Engineer.

• The project manager may require support for tasks such as gathering project status information, generating metrics, and preparing reports. When staffing the project, consider includingsupport staff to help with these activities.

dirección de proyectos€¦ · 2 introducción • los que intentan utilizar rup, a menudo dejan...

Documents