GESTIN DE PROYECTOS DE TI

Introduccin

TEMAS

I. Proyectos
Definicin Gestin de proyectos

II. Desarrollo de Software

Problemtica. 36 errores tpicos 6 Mejores prcticas

TEMA N 1
PROYECTOS

QU ES UN PROYECTO?

Las organizaciones ejecutan trabajos, ya sea en la forma de proyectos o de operaciones. Ambos tienen en comn:
Ejecutados por personas Recursos restringidos

Se planifican, ejecutan y controlan

Se diferencian en:
Las operaciones son continuas y repetitivas Los proyectos son nicos y temporales.

QU ES UN PROYECTO?

Un proyecto es un esfuerzo temporal llevado a cabo para crear un producto o servicio nico.
Gua del PMBOX 2004 Project Management Institute

Temporal quiere decir que todo proyecto tiene un inicio y un final definidos. nico quiere decir que el producto o servicio es diferente a otros productos o servicios similares.

QU ES UN PROYECTO?

Los proyectos pueden ser ejecutados por 1 persona o por 10,000 personas. Los proyectos pueden 10000,000 de horas. tomar 100 horas o

Los proyectos pueden involucrar a distintas reas de una organizacin.

QU ES UN PROYECTO?

Ejemplos de proyectos:
Desarrollo de un nuevo producto o servicio Llevar a cabo un cambio dentro de la organizacin Disear un nuevo vehculo de transporte Construir un edificio de viviendas. Organizar un congreso de estudiantes Desarrollar un software para el manejo de una agencia bancaria Realizar un cambio organizacional

NATURALEZA TEMPORAL DE UN PROYECTO

Todo proyecto tiene un inicio y un fin. Se llega al fin cuando se cumplen los objetivos del proyecto o cuando se determina que no se pueden cumplir. Temporal no quiere decir en un corto tiempo, quiere decir que tiene una duracin finita. Lo temporal no aplica al servicio o producto generado por el proyecto. Ejemplo: un monumento nacional que ser visitado por muchos aos.

PRODUCTO O SERVICIO NICO (I)

Los proyectos tienen que ver con hacer algo que no se ha hecho antes, y por lo tanto es algo nico.
Por ejemplo, la construccin de un edificio de oficinas puede parecer repetitivo, pero para cada desarrollo podemos tener un nuevo cliente, otro lugar, leyes distintas, distinto contratista, etc..

El hecho de ser nico, requiere que las caractersticas finales se van elaborando y refinando poco a poco, mediante una buena definicin de los alcances

SUB-PROYECTO

Los proyectos se pueden dividir en componentes ms manejables, tambin llamados subproyectos. Los sub-proyectos muchas veces se subcontratan a empresas externas o a otras unidades funcionales en la organizacin ejecutante.

Recursos del Proyecto

Recursos
Resultados / Tecnologa

Fuente: Harold Kezner

Recursos del Proyecto Personas

Informacin y Tecnologa

Liderazgo del Proyecto

Necesidad del Liderazgo Dinmica cambiante del entorno Presiones de tiempo Complejidad de los problemas Interacciones personales internas y externas Multiplicidad de factores intervinientes

Liderazgo del Proyecto

Perfil del Gerente de Proyecto Visin integradora Capacidad conduccin Planificador Organizador Capacidad determinar necesidades Negociador amplio Manejo de conflictos Capacidad tcnica Motivador

Qu es la Gestin del Proyecto ?

La gestin de proyecto es la aplicacin de conocimientos, habilidades herramientas y tcnicas en el sentido de concluir actividades que atiendan o excedan a las necesidades y expectativas de los stakeholders de este proyecto.

Proceso de Gestin del Proyecto

Los procesos de direccin de proyectos se pueden organizar en cinco grupos. Procesos de Iniciacin. Autorizacin del proyecto o de una fase del mismo Procesos de Planificacin. Definicin y refinamiento de objetivos, seleccin de la mejor alternativa entre posibles cursos de accin para lograr los objetivos del proyecto

Proceso de Gestin del Proyecto

Procesos de Control. Supervisar y medir el avance Identificar variaciones con respecto al plan Tomar las acciones correctivas cuando sea necesario. Procesos de Cierrre. Formalizacin de la aceptacin del proyecto o de una fase y organizacin de un fin ordenado.

Contexto de la Gestin del Proyecto

Estructura enfocada a proyectos

Ciclo de vida de un proyecto

Los niveles de coste y RRHH son bajos al comienzo, creciendo hasta el final del proyecto y cayendo rpidamente en la conclusin del mismo. La probabilidad de terminar con xito el proyecto es pequea, con riesgos eincertidumbres, al comienzo. La capacidad de los gestores para variar las caractersticas del proyecto es mayor al principio, vindose disminuida segn va avanzando el proyecto. El coste de los cambios y la correccin de posibles errores es mayor segn va progresando el proyecto.

Proyecto exitoso
Cuando finaliza en el tiempo previsto cumpliendo el presupuesto con los resultados y especificaciones esperadas con la aceptacin del cliente nos permite usar al cliente como referencia sin perturbar el flujo de trabajo de la organizacin sin conflictos con la cultura de la organizacin

QU ES GESTIN DE PROYECTOS?

Es la aplicacin de conocimientos, habilidades, herramientas y tcnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto.
Gua del PMBOX 2004 Project Management Institute

Interfase de Gestin
Relaciones humanas en la Organizacin del Proyecto Balance entre las funciones tcnicas y de administracin Enfrentar los riesgos asociados al proyecto Superar las limitaciones de la Organizacin

Procesos en la Gestin de Proyectos

Iniciacin Planeamiento

Control

Ejecucin

Cierre

QU ES GESTIN DE PROYECTOS?

La gestin de un proyecto incluye:

Identificar los requisitos Establecer unos objetivos claros y posibles de realizar Equilibrar las demandas alcance, tiempo y costos. concurrentes de calidad,

Adaptar las especificaciones, los planes y el enfoque a las diversas inquietudes y expectativas de los diferentes interesados.

QU ES GESTIN DE PROYECTOS?

El conocimiento sobre gestin de Proyectos puede organizarse en muchas maneras. El documento PMBOK est organizado en tres grandes secciones: El Marco Proyectos Conceptual de la Direccin de

Norma para la Direccin de Proyectos de un proyecto.

Las reas de conocimiento de la Direccin de Proyectos

Project Management Institute

Fundado en 1969 por cinco miembros en Pennsylvania, con el propsito de difundir las prcticas de Project Management Durante 1980 se llev a cabo el primer exmen para la certificacin PMP (Project Management Profesional) que actualmente posee reconocimiento ISO. En 1990 public los primeros estndares en PM: The Guide to tje Project Management Body of Knowledge. PMPBOK Hoy circulan en el mundo ms de 250000 copias Posee ms de 100000 asociados en 125 paises Han certificado como PMPs ms de 10000 miembros

AREAS DE CONOCIMIENTO DE LA GESTIN DE PROYECTOS

Modelo segn Project Management Institute

Gestin de Proyectos

Visin Integral

Alcance

Tiempos

Costos

Calidad

Recursos Humanos

Comunicacin

Riesgos

Adquisiciones

Modelo segn Project Management Institute

Procesos
Areas de
Conocimiento

Iniciacin

Planeamiento

Ejecucin

Control

Cierre

1.- Integracin 2.- Alcance 3.- Tiempos 4.- Costos 5.- Calidad 6.- Recursos Humanos 7.- Comunicacin 8.- Riesgos 9.-Adquisiciones

SECCIN I: Marco Conceptual de la Gestin de Proyectos

Proporciona una estructura bsica para entender la direccin de proyectos. El Captulo 1, Introduccin, define los trminos clave y proporciona una descripcin general del resto de la Gua del PMBOK.

El Captulo 2, Ciclo de Vida del Proyecto y Organizacin describe el entorno en el cual operan los proyectos. El equipo de direccin del proyecto debe comprender este amplio contexto.

Seccin II: Norma para la Gestin de Proyectos

Especifica todos los procesos de direccin de proyectos que usa el equipo del proyecto para gestionar un proyecto. El Captulo 3, describe los cinco Grupos de Procesos de Direccin de Proyectos aplicables a cualquier proyecto y los procesos de direccin de proyectos que componen tales grupos. Este captulo describe la naturaleza multidimensional de la direccin de proyectos.

Seccin III: reas de Conocimiento de la Gestin de Proyectos

Organiza los 44 procesos de direccin de proyectos de los Grupos de Procesos de Direccin de Proyectos del Captulo 3 en nueve reas de Conocimiento. La introduccin de la Seccin III describe la leyenda de los diagramas de flujo de procesos que se usan en cada captulo de rea de Conocimiento y en la introduccin de todas las reas de conocimiento.

Seccin III: reas de Conocimiento de la Gestin de Proyectos

El Captulo 4, Gestin de la Integracin del Proyecto, describe los procesos y actividades que forman parte de los diversos elementos de la direccin de proyectos. El Captulo 5, Gestin del Alcance del Proyecto, describe los procesos necesarios para asegurarse de que el proyecto incluya todo el trabajo requerido, y slo el trabajo requerido, para completar el proyecto satisfactoriamente.

El Captulo 6, Gestin del Tiempo del Proyecto, describe los procesos relativos a la puntualidad en la conclusin del proyecto.
El Captulo 7, Gestin de los Costes del Proyecto, describe los procesos involucrados en la planificacin, estimacin, presupuesto y control de costes de forma que el proyecto se complete dentro del presupuesto aprobado.

Seccin III: reas de Conocimiento de la Gestin de Proyectos

El Captulo 8, Gestin de la Calidad del Proyecto, describe los procesos necesarios para asegurarse de que el proyecto cumpla con los objetivos por los cuales ha sido emprendido.
El Captulo 9, Gestin de los Recursos Humanos del Proyecto, describe los procesos que organizan y dirigen el equipo del proyecto. El Captulo 10, Gestin de las Comunicaciones del Proyecto, describe los procesos relacionados con la generacin, recogida, distribucin, almacenamiento y destino final de la informacin del proyecto en tiempo y forma. El Captulo 11, Gestin de los Riesgos del Proyecto, describe los procesos relacionados con el desarrollo de la gestin de riesgos de un proyecto.

Seccin III: reas de Conocimiento de la Gestin de Proyectos

El Captulo 12, Gestin de las Adquisiciones del Proyecto, describe los procesos para comprar o adquirir productos, servicios o resultados, as como para contratar procesos de direccin.

TEMA N 2
DESARROLLO DE SOFTWARE:
Los 36 errores clsicos del desarrollo del software

ESTADSTICAS SOBRE DESARROLLO DE SW

31% de los proyectos son cancelados antes de completarse.

53% de los proyectos cuestan 190% del costo estimado. En las grandes empresas el costo se desva aprox. un 9%. En las PYMES el costo se desva aprox. un 16%.

INTERROGANTES EN EL DESARROLLO DE SW

Por qu se consume tanto tiempo en culminar los sistemas informticos?

Por qu no se identifican todos los errores del software antes de entregarlo al cliente?

Por qu es tan elevado el costo de los proyectos de sistemas?

Por qu es tan difcil medir el avance del desarrollo del software?

Los usuarios finales estn totalmente satisfechos con los sistemas informticos que utilizan?

36 ERRORES CLSICOS

Tipos:
De la Gente Del Proceso Del Producto De la tecnologa

GENTE

Baja motivacin Personal dbil

Dbil vs. Junior

Empleados problemticos no controlados Hroes Agregar gente a un proyecto atrasado

GENTE

Ruido, hacinamiento Roces con el cliente Expectativas no realistas Politizacin Soadores

GENTE

Falta de auspiciadores efectivos Falta de Stakeholders interesados No tener el punto de vista del usuario

PROCESO

Schedule optimista Manejo insuficiente del riesgo Falla de proveedores Planeamiento Insuficiente Planes que ceden a la presin

PROCESO

Tiempo desperdiciado al inicio Actividades fundamentales acortadas Diseo inadecuado Aseguramiento de la calidad recortado

PROCESO

Control insuficiente Convergencia frecuente o prematura Omisin de tareas al estimar Planear recuperarse despus Programacin codificar) Code-like-hell (Ir directo a

PRODUCTO

Exceso en los requerimientos Plantear demasiados objetivos a la vez Desarrolladores dorados (fascinacin por los avances tecnolgicos) Mala Negociacin Desarrollo investigativo

TECNOLOGIA

Sndrome de la Panacea Sobre-estimacin herramientas Capricho Snobismo Cambio de herramientas a mitad del proyecto Falta de control de fuentes de ahorros por nuevas

TEMA N 2
DESARROLLO DE SOFTWARE: Las 6 mejores prcticas

LAS 6 MEJORES PRCTICAS

ADMINISTRAR REQUERIMIENTOS

Desarrollar Iterativamente

Verificar Calidad

Modelizar Visualmente

Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

1. DESARROLLAR SOFTWARE ITERATIVAMENTE

ADMINISTRAR REQUERIMIENTOS Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

Cada iteracin resulta en un release ejecutable

Requerimientos

Anlisis y Diseo
Planeamiento Planeamiento Inicial Implementacin Ambiente de Administracin Distribucin Evaluacin Prueba

1. DESARROLLAR SOFTWARE ITERATIVAMENTE

Los desentendimientos importantes se evidencian tempranamente Se alienta el feedback del usuario Focalizacin en distracciones los temas ms crticos, sin

Testing continuo e iterativo: evaluacin objetiva

Inconsistencias entre requerimientos, diseos e implementaciones se detectan tempranamente

1. DESARROLLAR SOFTWARE ITERATIVAMENTE

Carga de trabajo mejor repartida en el tiempo El equipo puede analizar las lecciones aprendidas en las primeras iteraciones Integracin progresiva en lugar de Big Bang Evidencias concretas a los sponsors Se facilita la reutilizacin Arquitectura ms robusta

2. ADMINISTRAR LOS REQUERIMIENTOS

ADMINISTRAR REQUERIMIENTOS Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

Requirements Management, enfoque sistemtico que involucra:

Obtener, organizar y documentar la funcionalidad y restricciones requeridas a un sistema Analizar los cambios solicitados y evaluar impactos Registrar y documentar las alternativas y decisiones tomadas

2. ADMINISTRAR LOS REQUERIMIENTOS

Los requerimientos pueden ser adecuadamente capturados y comunicados a travs de Casos de Uso Los Casos de Uso son importantes instrumentos de planificacin
Modelo de Casos de Uso

Los Casos de Uso direccionan el trabajo desde el anlisis hasta el test

Realizacin

influenciados por

verifica

Modelo de Diseo

Modelo de Implementacin

Modelo de Test

2. ADMINISTRAR LOS REQUERIMIENTOS

Las comunicaciones estn requerimientos bien definidos Los requerimientos pueden filtrados y monitoreados

basadas ser

en

priorizados,

Es posible realizar evaluaciones objetivas acerca del xito de un proyecto Las inconsistencias se detectan fcilmente Con herramientas adecuadas: repositorio requerimientos, con atributos y relaciones de

Cmo son interpretados los requerimientos?

Necesito algo para balancearme bajo un rbol

Cmo lo explic el cliente?

Cmo son interpretados los requerimientos?

Cmo lo entendi el lder del proyecto?

Cmo fue descrito por el consultor?

Cmo fue

analizado

y diseado?

Cmo son interpretados los requerimientos?

Cmo fue programado?

Cmo fue documentado?

Cmo fue instalado?

Cmo son interpretados los requerimientos?

Cmo fue cobrado? Divisin de Alta Tecnologa

Qu soporte se brind?

Qu necesitaba realmente el cliente?

3. UTILIZAR ARQUITECTURAS BASADAS EN COMPONENTES

ADMINISTRAR REQUERIMIENTOS

Desarrollar Iterativamente

Verificar Calidad

Modelizar Visualmente

Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

La Arquitectura de Software representa el conjunto de decisiones significativas sobre la organizacin de un sistema de software
Seleccin de los elementos estructurales, y sus interfaces, por los cuales el sistema est compuesto Comportamiento, especificado entre los elementos como colaboraciones los elementos

Composicin en subsistemas de estructurales y de comportamiento

Estilo de arquitectura que gua a la organizacin

3. UTILIZAR ARQUITECTURAS BASADAS EN COMPONENTES

Un componente de software puede definirse como una pieza no trivial de software, un mdulo o un subsistema que completa una funcin clara, tiene lmites claros y puede ser integrado en una arquitectura bien definida
Aplicacin Negocio Middleware Systemsoftware

Arquitectura basada en componentes

3. UTILIZAR ARQUITECTURAS BASADAS EN COMPONENTES

Definir arquitecturas muy modulares e identificar, aislar, disear, desarrollar y probar componentes bien formados

Desarrollar componentes para ser reutilizados. Formar la base de reuso de la organizacin

Industria de infraestructura de componentes
COM+ - Microsoft Component Object Model - SUN

CORBA - Common Object Request Broker Architecture - OMG

JavaBeans Assemblys .NET Servicios Web

4. MODELAR SOFTWARE VISUALMENTE

ADMINISTRAR REQUERIMIENTOS Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

Subsistemas
La Modelizacin Visual eleva el nivel de abstraccin

Clases Cdigo

BENEFICIOS

Los casos de uso permiten especificar comportamiento sin ambigedades

Quedan expuestas modulares

las

arquitecturas

inflexibles

no

El diseo refleja sus inconsistencias ms rpidamente Existen herramientas modelizacin visual que proveen soporte para la

U cP a g a rS e r v i c i o

R e g is t r a rP a g o

C a je r o

5. VERIFICAR LA CALIDAD DEL SOFTWARE

ADMINISTRAR REQUERIMIENTOS Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

La actividad fundamental de esta prctica es el testing Evaluar continuamente la calidad de un sistema con respecto a funcionalidad, confiabilidad, performance

Encontrar y reparar un problema de software despus de la implementacin puede resultar de 100 a 1000 veces ms costoso

Costo

Desarrollo

Implementacin

BENEFICIOS

La evaluacin del estado del proyecto es objetiva, se evalan resultados de test. Se exponen inconsistencias en requerimientos, diseos e implementaciones Se focaliza en las reas de riesgo ms alto

Los defectos se identifican en forma temprana

Existen herramientas automatizadas para testing de funcionalidad, confiabilidad performance el y

6. CONTROLAR LOS CAMBIOS AL SOFTWARE

ADMINISTRAR REQUERIMIENTOS Desarrollar Iterativamente Verificar Calidad Modelizar Visualmente
Arquitecturas Basadas en Componentes

CONTROLAR CAMBIOS

El manejo del cambio es ms que apenas comprobar dentro y fuera de archivos. Incluye el manejo de espacios de trabajo, del desarrollo paralelo, de la integracin y de construcciones.

6. CONTROLAR LOS CAMBIOS AL SOFTWARE

Controlar, registrar y monitorear los cambios para posibilitar el desarrollo iterativo Establecer workspaces desarrollador seguros para cada

Automatizar la integracin y la administracin de construcciones.

BENEFICIOS

Las solicitudes de cambios formales facilitan la claridad de comunicacin Los espacios de trabajo aislados reducen la interferencia entre los miembros del equipo que trabajan en paralelo Las estadsticas de cantidad de cambios proveen buenas mtricas para evaluar objetivamente el estado del proyecto La propagacin del cambio es evaluable y controlable Los cambios pueden ser mantenidos en sistemas automticos