Proyectos

Actividades Unicas

• Proyecto: es una secuencia de actividades u ´nica, complejas y conectadas que tienen un objetivo o prop´ osito y que deben ser completadas en un tiempo espec´ıfico, dentro del presupuesto y de acuerdo a las especificaciones. • Un proyecto comprende un conjunto de actividades que deben ser completadas con un orden o secuencia especificados. • Informalmente, una actividad es una porci´ on de trabajo. • La secuencia de las actividades est´a definida en base a los requerimientos t´ecnicos. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

375

Proyectos...

• Siempre habr´a algo distinto cada vez que las actividades de un proyecto se repitan. • Generalmente las variaciones ser´an de naturaleza aleatoria. • Existen eventos aleatorios que pueden ocurrir, que nunca podemos estar seguros de cuando, c´omo y qu´e impacto tendr´an en la planificaci´ on. Ejemplo: no hay comunicaciones, Ju´an se enferm´o, .. Constituyen el desaf´ıo de los l´ıderes de proyecto. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

377

Actividades Complejas y Conectadas

• Las actividades que conforman un proyecto de software no son simples, ni son actos repetitivos, como ordenar un estante, lavar el auto, pintar una casa. Son complejas: dise˜ no de la base de datos, dise˜ no de la interface,...

• Para determinar la secuencia es u ´til pensar en: – T´erminos de inputs y outputs. – ¿Qu´e es necesario como input para comenzar esta tarea? – ¿Qu´e actividades producen estos outputs? • El output de una actividad o conjunto de actividades es el input a otra actividad o conjunto de actividades. • Se deben evitar las relaciones artificiales entre actividades. Ejemplo: La actividad i comenzar´a cuando Ju´an regrese de vacaciones.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

• Las actividades dentro de un proyecto son u ´nicas. Un proyecto nunca sucedi´o antes, no suceder´a a futuro bajo las mismas circunstancias.

376

• La conexi´on entre actividades implica que existe una relaci´on l´ ogica o t´ecnica entre pares de actividades. Existe un orden en la secuencia en que se deben realizar las tareas para completar el proyecto. Se consideran conectadas por que el output de una actividad es el input de otra. • Pueden existir conjuntos de actividades que no conformen un proyecto de acuerdo a la definici´ on. Son actividades desconectadas. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

378

Un objetivo

De acuerdo a lo especificado

• Los proyectos deben tener un s´olo objetivo. Ejemplo: desarrollar un sistema de administraci´on de consorcios.

• El cliente espera un determinado nivel de funcionalidad y de calidad como resultado del proyecto.

• Proyectos muy grandes y complejos pueden ser divididos en subproyectos. Cada uno de ellos, en s´ı mismo, constituye un proyecto.

• Estas expectativas pueden ser auto-impuestas por el equipo de desarrollo (calidad en la documentaci´ on de programas fuentes) o impuestas por el usuario (el listado de vencimientos semanal).

• La divisi´ on se hace para una mejor administraci´ on. Simplifica la planificaci´ on de recursos pero existe la interdependencia entre los proyectos. Esto agrega un nivel m´as de complejidad y comunicaci´ on.

• Si bien las especificaciones se tratan como fijas, pueden modificarse y seguramente lo har´an. • Los cambios en las especificaciones tambi´en constituyen un desaf´ıo para los l´ıderes de proyecto.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

379

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

Tiempo Espec´ıfico - Dentro del presupuesto

Par´ ametros de un Proyecto

• Los proyectos tienen una fecha de terminaci´ on. Esta fecha puede ser autoimpuesta por el l´ıder de proyecto o especificada externamente por un cliente o un organismo externo. • La fecha de terminaci´on (deadline) est´a fuera del control de cualquier integrante del proyecto. • Los proyectos tienen recursos limitados, tales como limitada cantidad de personal, dinero, o m´aquinas dedicadas al proyecto. • Si bien los recursos pueden ser ajustados (aumentados o disminuidos) por la alta gerencia, se deben considerar fijos. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

381

380

Existen cinco restricciones que operan sobre un proyecto. Son interdependientes. Un cambio en una, implica un cambio en las dem´as. Debe mantenerse el equilibrio entre ellas. Las restricciones son: 1. Alcance 2. Calidad 3. Costo 4. Tiempo 5. Recursos Administraci´ on y Gesti´ on de Proyectos de Software, UNS

382

Alcance y Calidad

Tri´ angulo de Alcance

• Alcance: es un enunciado que define los l´ımites del proyecto. Dice lo que se va a hacer, pero impl´ıcitamente tambi´en dice lo que no se va a hacer. • Es cr´ıtico que el alcance sea correcto. • El alcance puede cambiar. • Detectar el cambio y decidir como acomodar el plan del proyecto es un desaf´ıo del l´ıder de proyecto. • Existen dos calidades: calidad del producto y calidad del proceso. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

383

Recursos

385

Tri´ angulo de Alcance

• Recursos: son activos, tales como personas, equipos, facilidades f´ısicas, o inventarios. Tienen disponibilidad limitada, su uso puede planificarse, o puede ser contratado a una tercera parte. • Algunos son fijos y otros variables a largo plazo. Son centrales a la planificaci´ on de las actividades del proyecto y para la finalizaci´on ordenada del mismo. • Para los proyectos de desarrollo de sistemas, las personas son el recurso m´as importante.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

384

• Los proyectos son sistemas din´amicos que deben ser mantenidos en equilibrio. • Tiempo: es la ventana de tiempo en la cual el proyecto debe terminarse. • Costo: es el presupuesto disponible para completar el proyecto. • Recursos: es cualquier consumible usado en el proyecto. personas, equipos, tinta, papel,...

Ej:

• Son controlados por el l´ıder del proyecto y necesitan ser identificados de manera independiente. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

386

Tri´ angulo de Alcance

Corrimientos

• Cualquier imprevisto hace desbalancear el proyecto. Ej: un recurso menos, un nuevo requerimiento. • El l´ıder de proyecto controla la utilizaci´ on de los recursos y el cronograma de trabajo. • La gerencia controla los niveles de recursos y de costos. • El cliente controla el alcance, los niveles de calidad, y las fechas de entrega.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

387

• Corrimiento de Esfuerzo: es el resultado del trabajo de miembros del equipo, que no representan progresos proporcionales al trabajo realizado. Ej: cada semana el informe de avance muestra progresos pero nunca se termina. • Corrimiento de Rasgos: sucede cuando miembros del equipo arbitrariamente agregan rasgos (caracter´ısticas) que piensan que el usuario desear´ıa tener en su sistema , pero que no especific´o. • El enfoque parece inoccente. ¿Lo es? ¿Qu´e pasa con los eventos de prueba, los datos de prueba, la documentaci´ on del sistema, el programa de entrenamiento? Administraci´ on y Gesti´ on de Proyectos de Software, UNS

Corrimientos

Clasificaci´ on de Proyectos

• Corrimiento de Alcance: cualquier cambio en el proyecto que no estaba en el plan original. • Es responsabilidad del LP acomodar el proyecto para tener en cuenta los cambios. • Corrimiento de Esperanza: informar que no hay demoras, para no dar una mala noticia, pensando que para el pr´ oximo informe de tareas se puede recuperar. • Es responsabilidad del l´ıder de proyecto controlar si los informes de avances son veraces. Se pueden realizar controles aleatorios. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

389

388

• Riesgo • Valor comercial • Longitud • Complejidad • Costo

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

390

Tipo Proyectos

Definici´ on ...

• Independientemente de la metodolog´ıa, debe responder a cinco cuestiones: 1. 2. 3. 4. 5.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

391

Definici´ on

¿Cu´al es el problema u oportunidad a solucionar? ¿Cu´al es la meta del proyecto? ¿Qu´e objetivos se deben satisfacer para llegar a la meta? ¿C´ omo se va a determinar si el proyecto ha sido exitoso? ¿Existe alg´ un riesgo, presunci´on u obst´aculo que puede afectar el ´exito del proyecto?

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

393

Planificaci´ on

• Una de las primeras tareas es definir el trabajo que se necesita realizar en el ´area de responsabilidad.

• Ideas en contra: Es un p´erdida de tiempo!!! Se hace y se archiva en un estante. Se transforma en obsoleto r´apidamente.

• Es una fase preliminar e importante del ciclo de vida de proyectos.

• El plan de proyecto es indispensable.

• El LP y el cliente fijan acuerdos sobre varios aspectos importantes del proyecto.

• El plan sugiere enfoques alternativos, cronogramas, y recursos requeridos de los cuales el LP debe seleccionar la mejor alternativa.

• La etapa de definici´on fija el alcance del proyecto.

• El plan es din´ amico. Esperamos que cambie.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

392

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

394

Planificaci´ on...

Control

• Como parte de la planificaci´ on, se crea un cronograma inicial. Este cronograma debe especificar:

• Existen 3 beneficios al confeccionar un plan: 1. Reduce la incertidumbre: nos permite evaluar los hechos y tomar las acciones correctivas necesarias. 2. Aumenta la comprensi´on: permite aclarar las metas y objetivos. 3. Mejora la eficiencia: podemos planificar para sacar ventaja de la disponibilidad de los recursos. Desarrollar tareas en paralelo o concurrentemente. • El plan tambi´en permite medir el trabajo planificado versus el trabajo realizado.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

395

Ejecuci´ on

Qu´e debe realizarse en el proyecto. Cuando debe realizarse cada tarea. Qui´en es el responsable de ejecutar la tarea. Qu´e entregables se esperan como resultado de la terminaci´on del proyecto.

• No importa lo precavido del grupo, el proyecto nunca va a ir de acuerdo al plan. Se debe tener herramientas que muestren el avance, incluso que detecten problemas potenciales. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

397

Terminaci´ on

• Ejecutar el plan es equivalente a autorizar al personal a realizar las tareas que definen sus respectivos trabajos. • Cada miembro del equipo sabe qu´e debe hacer, c´omo realizar el trabajo y c´ omo sabe que lo termin´o. • La ejecuci´on del plan del proyecto involucra 4 etapas: 1. Identificar los recursos espec´ıficos requeridos para realizar el trabajo definido en el plan. 2. Asignar presonas a las actividades. 3. Planificar las tareas con fechas espec´ıficas de comienzo y fin. 4. Lanzar el plan.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

1. 2. 3. 4.

396

• La terminaci´on es un medio formal de mostrar la finalizaci´ on de un proyecto con los resultados entregados al cliente. Para la administraci´ on de recursos significa liberarlos y asignarlos a otras tareas. • La etapa de terminaci´on debe evaluar todo lo sucedido en el proyecto y documentarlo para usarlo en planificaciones futuras. • Una buena terminaci´ on, provee respuestas a las siguientes preguntas: 1. Los entregables, conformaron las expectativas de los usuarios? 2. Los entregables, conformaron las expectativas del LP?

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

398

Terminaci´ on

Definir el Proyecto

3. Termin´ o el equipo, el proyecto de acuerdo al plan? 4. Qu´e informaci´ on se recolect´o que ser´a u ´til para otros proyectos? 5. C´ omo funcion´ o la metodolog´ıa de administraci´ on de proyectos y en cuanto fue respetada por el equipo? 6. Qu´e lecciones se han aprendido de este proyecto? • Muchas veces no se hace y se presiona al LP para que comience con un nuevo proyecto.

• Enunciar el problema/oportunidad. • Establecer la meta del proyecto. • Definir los objetivos del proyecto. • Identificar los factores cr´ıticos de ´exito. • Listar presunciones, riesgos, obst´aculos.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

399

Ciclo de Vida de Proyectos

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

401

Definir el Proyecto...

• Cada proyecto tiene una meta: acuerdo entre el cliente y el LP sobre que se va a entregar. • La meta est´a limitada por un n´ umero de enunciados de objetivos. • Estos objetivos clarifican la impresici´on del enunciado de la meta. • (Meta, Objetivos) = definen el alcance del proyecto. • Enunciado General del Proyecto (POS: Project Overview Statement) = Enunciado del problema + Meta y Objetivos + FCE (Factores Cr´ıticos de Exito) + Presunciones-Riesgos-Obst´aculos. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

400

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

402

Desarrollar el Plan Detallado

Desarrollar el Plan Detallado...

• Identificar las actividades del proyecto.

• El plan del proyecto es una descripci´ on de eventos que van a suceder.

• Estimar la duraci´ on de las actividades.

• Es un modelo del proyecto.

• Determinar requerimientos de recursos.

• Cuando un evento ocurre, el modelo es afectado, y puede ser modificado para mostrar como van a ocurrir los pr´ oximos eventos.

• Construir y analizar el plan del proyecto.

• Como el plan del proyecto es un modelo, se puede utilizar para testear estrategias alternativas para redirigir los futuros eventos.

• Preparar la propuesta del proyecto.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

403

Desarrollar el Plan Detallado...

Una descripci´on detallada de cada actividad. Los recursos requeridos para completar la actividad. Las fechas de inicio y fin de cada actividad. El costo estimado y la fecha de terminaci´on del proyecto.

• En algunas organizaciones se puede adjuntar: estudio de factibilidad, enunciados de impactos en el entorno, an´alisis de costo-beneficios, an´alisis de alternativas...

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

405

Desarrollar el Plan Detallado...

• El entregable de esta etapa es la propuesta del proyecto que incluye: – – – –

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

404

• Algunos temas a tener en cuenta para reformular el plan: – Si una actividad termina antes o despu´es de la fecha prevista, ¿se puede ajustar la planificaci´on de recursos para actividades posteriores de acuerdo a este hecho? – Si una o m´as actividades terminan retrasadas, ¿se pueden reasignar recursos del proyecto para restaurar la planificaci´ on original del proyecto? – ¿C´omo puede el LP resolver simult´aneamente comprimir la planificaci´ on del proyecto y adem´as evitar conflictos de asignaci´ on de recursos? – ¿C´omo pueden asignarse recursos de un proyecto a otro, sin afectar las planificaciones de ambos proyectos? Administraci´ on y Gesti´ on de Proyectos de Software, UNS

406

Lanzar el Proyecto

Monitorear/Controlar el Avance

• Reclutar y organizar el equipo de proyecto.

• Establecer sistema de informes de avances.

• Establecer las reglas de funcionamiento del equipo.

• Instalar herramientas/procesos de control de cambios.

• Nivelar los recursos del proyecto

• Definir el proceso para escalar problemas.

• Planificar paquetes de trabajo.

• Monitorear el avance del proyecto versus el plan.

• Documentar paquetes de trabajo.

• Revisar los planes del proyecto.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

407

Lanzar el Proyecto...

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

409

Monitorear/Controlar el Avance...

• En esta etapa se especifica el equipo del proyecto. Es importante eliminar la noci´ on de que una sola persona ser´a el responsable por el ´exito (o fracaso) del proyecto.

• Se definir´an los informes de estado del proyecto, que se utilizar´an para monitorear el avance del proyecto. Algunos ser´an usados por el equipo y otros se entregar´an a la gerencia y al cliente.

• La conformaci´on del equipo cruza funcionalmente los l´ımites de la organizaci´ on. Los integrantes pueden depender funcionalmente de distintas ´areas.

• La administraci´on de cambios juega un rol importante en esta etapa. Los requerimientos de cambios pueden causar que una parte del proyecto se replanifique.

• La participaci´on de algunos integrantes claves puede haber sido definida en la etapa anterior.

• Cuando se recibe un requerimiento de cambio, se debe revisar si afecta la planificaci´ on del proyecto. Si ocurren problemas que afectan las fechas de terminaci´on de actividades, se debe definir el procedimiento para escalar estas situaciones.

• En esta etapa se establecen las reglas del equipo, requerimientos de informes, reuniones de control del proyecto. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

408

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

410

Calidad y Riesgos

Terminaci´ on/Cierre

• Adem´as de la calidad del producto y del proceso, se deber´a tener en cuenta la calidad de la administraci´ on del proyecto.

• Instalar los entregables. • Archivar informes finales y documentaci´ on.

• Existen varios modelos. Cada organizaci´ on elige el que considera adecuado.

• Ejecutar una auditor´ıa post-instalaci´on.

• Est´an por encima de la administraci´ on de proyectos. Los resultados de la aplicaci´on de estos modelos dan origen a los nuevos proyectos.

• Celebrar!!! (Tomarse vacaciones)

• Para cada proyecto se debe realizar un an´alisis de riesgo. Ya visto anteriormente. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

411

Niveles de Administraci´ on de Proyectos

413

Definici´ on

• El output es el Enunciado General del Proyecto (POS: Project Overview Statement).

• Existen variaciones a este ciclo de vida de proyectos: 1. Definici´ on, planificaci´ on, organizaci´ on: es para una o dos personas. No existe inter´es en el control. Sirve para planificar y tener idea de tiempos. Similar a una lista de tareas. 2. Definici´ on, planificaci´ on, organizaci´ on y control: lanzar el proyecto es s´olo el 50%. El control es un mecanismo de anticipar problemas y tomar las medidas correctivas necesarias. 3. Definici´ on, planificaci´ on, organizaci´ on, control y cierre: la astucia del LP har´a que desee aprender de la experiencia del proyecto que termin´o.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

412

• Debe ser 1 hoja y puede tener documentos adjuntos. Especifica claramente qu´e es lo que se va a realizar. • Se desarrolla una propuesta: Condiciones de Satisfacci´ on, a partir de un requerimiento del cliente, o de que se nos ha asignado esa tarea. • El proceso para desarrollar la propuesta tiene 4 etapas: Requerimiento - Clarificaci´ on - Respuesta - Acuerdo. El resultado es un input al POS. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

414

Definici´ on...

Establecer la Meta

• La intenci´on es dar una idea del valor del proyecto de tal modo que la alta gerencia decida seguir leyendo. • Todo proyecto tiene una sola meta, que le da el prop´ osito y la direcci´on al proyecto. Define el resultado final de tal forma que todos entiendan que es lo que se va a realizar. • Debe ser corto y conciso. No contiene fechas. • Si se hacen estimaciones tempranas, dejar constancia que se corregir´an cuando se tenga una mayor comprensi´ on del trabajo a realizar. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

415

Definici´ on

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

417

Establecer la Meta...

• El POS es un documento corto (idealmente una p´agina) que especifica de manera concisa que es lo que se va a hacer en el proyecto, por que se va a hacer, que valor comercial tendr´a para la empresa.

• Espec´ıfica: ser espec´ıfico en apuntar a un objetivo.

• Sirve para que la gerencia apruebe el proyecto y autorice los recursos necesarios.

• Asignable: asignar el objetivo a una persona para que lo complete.

• Es estudiado por un comit´e o por el responsable de asignar prioridades y decidir que proyectos se realizar´an.

• Realista: enunciar lo que realmente se puede hacer con los recursos disponibles.

• Sirve para: la base y referencia para la planificaci´ on, solicitud de iniciativas individuales.

• Limitada en el tiempo: enunciar la duraci´ on.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

416

• Medible: establecer un indicador medible de progreso.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

418

Definir los Objetivos del Proyecto

• Son una descomposici´on detallada de la meta. conjunto de objetivos necesarios y suficientes.

Identificar FCE

Constituyen un

• ¿Qu´e debiera sucedernos a nosotros y al cliente para decir que el proyecto fue un ´exito?

• Todo objetivo debe completarse para lograr la meta, ning´ un objetivo es superfluo.

• Proveen una base para que la alta gerencia autorice los recursos para que se haga la planificaci´ on detallada.

• Es importante tener en cuenta que son los objetivos actuales.

• Es esencial que los factores sean medibles y cuantificables, y en lo posible expresados en t´erminos del negocio.

• Permanentemente, controlar si est´an dentro de los l´ımites del proyecto o no.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

419

Definir los Objetivos del Proyecto

• Se est´a tratando de vender la idea a los decision-makers.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

421

Proceso de Aprobaci´ on

• Una vez que el POS est´a completo, se le env´ıa a la gerencia para su aprobaci´ on.

Un enunciado de objetivos debe incluir: • Una salida: un enunciado de qu´e es lo que se va a realizar.

• Se debe intentar que el POS sea autoexplicativo. A pesar de esto, se debe esperar la consuta.

• Un marco de tiempo: la fecha esperada de finalizaci´on.

• La aprobaci´ on del POS sirve para 3 audiencias: alta gerencia (dedicar recursos), cliente (el proyecto est´a claramente definido), el equipo (el proyecto es claro para la alta gerencia y el cliente).

• Una medida: m´etricas que medir´an el ´exito. • Una acci´ on: c´omo se lograr´a el objetivo.

• Es una aprobaci´ on para confeccionar el plan detallado. La aprobaci´ on del proyecto es luego de analizar el plan detallado. Administraci´ on y Gesti´ on de Proyectos de Software, UNS

420

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

422

Participantes en el Proceso de Aprobaci´ on

• Equipo principal del proyecto: gerentes, profesionales de sistemas, y probablemente el cliente. • Equipo del proyecto: algunos potenciales integrantes del equipo. • LP (Project Manager): un rol importante en la aprobaci´ on. • Gerentes de usuarios: gerentes de recursos que participar´an en el proyecto.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

423

Participantes en el Proceso de Aprobaci´ on...

• Gerentes de Procesos/Funciones: gerentes del contexto (recibenenv´ıan) • Cliente: puede desempe˜ nar hasta el rol de LP. • Alta Gerencia: el soporte de la alta gerencia puede ser cr´ıtico.

Administraci´ on y Gesti´ on de Proyectos de Software, UNS

424