Metodologías para la Gestión de Proyectos de Software

Agenda
‡ Metodologías de Gestión de Proyectos
± Qué es una Metodología de Gestión de Proyectos ± Tipos de Metodologías de Gestión de Proyectos ± Generalidades de los Proyectos

‡ Metodología de Gestión de Proyectos de BABEL
± Generalidades de la Metodología ± Concepción de un Proyecto ± Proceso de Pre-Venta y Venta

Agenda
‡ Metodología de Gestión de Proyectos de BABEL
± ± ± ± ± ± Fase de Inicialización Fase de Planeación Fase de Ejecución Fase de Control y Seguimiento Fase de Cierre Mantenimiento de Aplicaciones

‡ Modelos basados en madurez de procesos en organizaciones

Evaluación de Conceptos
‡ ‡ ‡ ‡ ‡ ‡ ‡ ¿Qué es UML? ¿Qué es RUP? ¿Qué es PMI? ¿Qué es ISO? ¿Qué es CMMi? ¿Qué es un Caso de Uso? ¿Qué es un Caso de Prueba?

Evaluación de Conceptos
‡ ‡ ‡ ‡ ‡ ‡ ‡ ¿Qué es una línea de código (LDC)? ¿Qué es Gerente de Proyecto? ¿Qué es un Líder Técnico? ¿Qué es un Programador? ¿Qué es un Analista de Requerimientos? ¿Qué es un Ingeniero de Calidad? ¿Qué es un Soportista de Aplicaciones?

Evaluación de Conceptos ‡ ‡ ‡ ‡ ‡ ‡ ‡ ¿Qué es un DBA? ¿Qué es Soportista Técnico? ¿Qué es un Analista de Negocios? ¿Qué es una PMO? ¿Qué es un Cliente? ¿Qué es un Patrocinador? ¿Qué es una Contraparte Técnica? .

Evaluación de Conceptos ‡ ‡ ‡ ‡ ‡ ‡ ‡ ¿Qué es un Diseñador Gráfico? ¿Qué es un Arquitecto de Software? ¿Qué es el Criterio Experto? ¿Qué es un Proyecto? ¿Qué es un Producto? ¿Qué es un Programa? ¿Qué es un Portafolio? .

Evaluación de Conceptos ‡ ‡ ‡ ‡ ‡ ‡ ‡ ¿Qué es un Stakeholder? ¿Qué es un Riesgo? ¿Qué es un Recurso? ¿Qué es Calidad? ¿Qué es un Entregable? ¿Qué es un Ciclo de Desarrollo? ¿Qué es un Plan de Pruebas? .

Desarrollo de Software vs. Programador . Ingeniería de Software ‡ ‡ ‡ ‡ ‡ ‡ ¿Qué es el Desarrollo de Software? ¿Qué es la Ingeniería de Software? ¿Se contradicen? ¿Se complementan? Profesionales involucrados en los procesos Ingeniero de Software vs.

Ingeniería de Software ‡ DEFINICIÓN 1 La ingeniería del software es el establecimiento y uso de principios de ingeniería razonables con el objetivo de obtener software económicamente. . que sea de confianza y trabaje eficientemente en las maquinas reales.

Además. .Ingeniería de Software ‡ DEFINICIÓN 2 Disciplina tecnológica concerniente a la producción y mantenimiento sistemáticos de productos de software que son desarrollados y modificados en el tiempo y con los costes estimados... la Ingeniería del software tiene que ver con cuestiones de gestión que caen fuera del dominio de la programación tradicional.

Ingeniería de Software ‡ Beneficios de implementarla ‡ Consecuencias de su ausencia ‡ Consideraciones de importancia .

Características de la ingeniería del software ‡ ‡ ‡ ‡ ‡ ‡ Construcción de programas grandes Controlar la complejidad Cooperación entre las personas implicadas Evolución del software Eficiencia en el desarrollo Soporte real a los usuarios .

Modelo de la Ingeniería del software Ingeniería del software Desarrollo de Software Analisis Diseño Codificación Pruebas Gestión de proyectos Planificación Organización Reclutamiento Dirección Control Metricas del software Mantenimiento de software Fiabilidad Corrección de Errores Usabilidad Modificaciones Flexibilidad Mantenibilidad Reusabilidad Etc. .

. también en informática .Técnicas básicas utilizadas ‡ Históricamente se han utilizado técnicas como: ± El modelado ± División del Producto ± División del Proceso ‡ En principio se deberían utilizar estas técnicas.

pero que es suficientemente realista como para dar una idea de lo que ocurrirá en la realidad y usarse como base del desarrollo. .El modelado ‡ Simplificación del objeto en el mundo real.

División del Producto ‡ Se fracciona el producto de modo que cada fragmento lo puede realizar un miembro del grupo de desarrollo. .

¿Que? ¿Como? Realización Pruebas . diseño y fabricación. Normalmente se habla de especificación.División del Proceso ‡ Implica dividir el desarrollo del artefacto por fases.

En el desarrollo de software nos encontramos con esto: Ciclos de Vida del SOFTWARE Metodologías de Desarrollo del SOFTWARE .

.

Generalidades de los Proyectos .

pmi.¿Qué es el PMI? ‡ Project Management Institute ± Organización mundial ± Sin fines de lucro ± Promover la práctica estandarizada de Gerencia de Proyectos ‡ www.org .

¿Qué es el PMBOK Guide? ‡ Project Management Body of Knowledge ± Proporciona los fundamentos de la gestión de proyectos. ± Lenguaje común ± Conocimiento requerido. no metodología ‡ Reconocido como las buenas prácticas ± Seleccionar las áreas según proyecto ‡ PMP .

¿Qué es un Proyecto? ‡ DEFINICIÓN 1 Un proyecto es un esfuerzo para lograr un objetivo específico mediante una serie especial de actividades interrelacionadas y la utilización adecuada de los recursos . .

. servicio o resultado único .¿Qué es un Proyecto? ‡ DEFINICIÓN 2 Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto .

‡ Por lo general se define a partir del alcance. ‡ Prevé que se realice con calidad deseada y con plena satisfacción del cliente. el programa y los costos.Características de un Proyecto ‡ El proyecto tiene un objetivo bien definido: el resultado o producto esperado. .

‡ Actividades no repetitivas que han de cumplirse en determinada secuencia a fin de alcanzar el objetivo del proyecto.Características de un Proyecto ‡ El proyecto se lleva a cabo con una serie de actividades interdependientes. .

Características de un Proyecto ‡ En un proyecto se hace uso de varios recursos: ± Personas ± Dinero ± Equipo ± Materiales ± Instalaciones ± Software ± Vehículos .

conocido también como vida útil finita.Características de un Proyecto ‡ Un proyecto tiene un marco temporal específico. ‡ Tiene un tiempo y una fecha en que debe concluirse. . ‡ Por ejemplo: Entre el 1ro de marzo del 2010 y el 30 de junio del 2010.

Características de un Proyecto ‡ Puede ser un esfuerzo único o de una sola vez: ± Es único en virtud de que aunque no sea novedoso. cada proyecto lleva consigo una adaptación particular a las condiciones vigentes. .

una empresa o un grupo de dos o más personas o empresas. . ‡ Depende de quién sea el que aporta los recursos.Características de un Proyecto ‡ Un proyecto tiene un cliente que es aquél que aporta los fondos para que se realice. ‡ Puede ser una persona.

.Características de un Proyecto ‡ Los proyectos suponen un grado de incertidumbre. ‡ Antes de iniciar el proyecto se prepara a partir de una serie de suposiciones y estimaciones. como lo es el presupuesto y la duración del trabajo. ‡ Es importante anotarlas porque pueden influir en alguna de las etapas del proyecto.

Características según el PMI
‡ TEMPORAL
± Significa que tienen un comienzo y un final definidos ± ¿Cuándo se alcanza el final? ± Los proyectos no son esfuerzos continuos ± Temporal no se aplica generalmente al producto, servicio o resultado creado por el proyecto

Características según el PMI
‡ TEMPORAL también implica que:
± La oportunidad o ventana de negocio normalmente es temporal para los productos o servicios. ± El equipo de proyecto, como unidad de trabajo, termina su función con la finalización del proyecto.

Características según el PMI
‡ Productos, servicios o resultados únicos
± Un proyecto genera productos entregables únicos ± Productos entregables son productos, servicios o resultados. ± Son únicos porque a pesar de tener características similares, cada proyecto es individual.
‡ Por ejemplo: se han construido miles de edificios de oficinas pero todos poseen diferencias.

En lenguaje sencillo
‡ ENTREGABLE
± Es algo valioso producido por un equipo de gestión de proyectos tal y como ha sido programado y que se ofrece a un superior, a un comité de evaluación, a los clientes, o a cualquier persona afectada.

Características según el PMI
‡ Elaboración gradual
± Significa desarrollar en pasos e ir aumentando mediante incrementos. ± El alcance de un proyecto se define de forma general al comienzo del proyecto, y se hace más explícito y detallado a medida que el equipo de proyecto desarrolla un mejor y más completo entendimiento de los objetivos y de los productos entregables.

± Es la suma de productos.Características según el PMI ‡ Alcance ± Es el trabajo a realizar. servicios y resultados que se proporcionan como resultado de un proyecto. .

‡ Los proyectos son temporales y únicos. .Proyectos ‡ Para lograr sus objetivos las empresas realizan trabajo que usualmente se compone de operaciones permanentes y proyectos. ‡ Las operaciones son continuas y repetitivas.

‡ Se llevan a cabo en todos los niveles de la organización y pueden involucrar a una persona o a miles.Proyectos ‡ Son realizados por personas. ejecutados y controlados. ‡ Planificados. . ‡ Restringidos por la limitación de los recursos.

.¿Qué es un Producto? ‡ DEFINICIÓN 1 Cualquier objeto que puede ser ofrecido a un mercado que pueda satisfacer un deseo o una necesidad.

‡ Los proyectos son temporales. .Diferencias entre Proyecto y Producto ‡ Los proyectos son únicos. ‡ Los productos son el resultado de un proceso de producción.

Sub-Proyectos ‡ Subdivisión de los proyectos para facilitar su gestión ± Considerados como proyectos ± Contratar externamente ± Ser desarrollados por otra unidad funcional ‡ Subproyectos para áreas específicas de conocimiento .

transmisión .Programas ‡ Grupos de proyectos relacionados cuya dirección se realiza de manera coordinada para obtener beneficios y control que no se obtendrían si fueran dirigidos en forma individual. ± Programa para un nuevo modelo de automóvil ‡ Proyectos para cada componente individual ‡ Motor.

.Portafolios ‡ Conjunto de programas o subproyectos que se gestionan conjuntamente. ‡ Gestión conjunta que tiene el fin de cumplir objetivos estratégicos del negocio.

. herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del proyecto. habilidades.¿Qué es la Gestión de Proyectos? ‡ DEFINICIÓN 1 Es la aplicación de conocimientos.

y cierre. . seguimiento y control.¿Qué es la Gestión de Proyectos? ‡ DEFINICIÓN 2 La gestión de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio. planificación. ejecución.

alcance. ‡ Equilibrar las demandas concurrentes de calidad. ‡ Adaptar las especificaciones. .La Dirección de un Proyecto incluye ‡ Identificar los Requerimientos o Requisitos ‡ Establecer los objetivos claros y posibles de realizar. tiempo y costos. los planes y el enfoque a las diversas inquietudes y expectativas de los interesados.

Consideraciones estratégicas que autorizan los Proyectos ‡ ‡ ‡ ‡ ‡ Demanda del mercado Necesidad organizacional Requerimientos del cliente Avance tecnológico Requerimiento legal .

La triple restricción .

La triple restricción ‡ A menudo los Directores de Proyectos hablan de la triple restricción a la hora de gestionar los requerimientos de un proyecto. ‡ Si un factor cambia es muy probable que alguno de los otros también cambie. ‡ La calidad de un proyecto se ve afectada por el equilibrio de estos tres factores. .

Áreas del Conocimiento ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ Integración Alcance Tiempo Costo Calidad Recursos Humanos Comunicaciones Riesgos Aprovisionamiento (subcontrataciones) .

servicio o resultado requerido. puntualmente y dentro del presupuesto.Proyectos de Alta Calidad ‡ Son aquellos que entregan el producto. . con el alcance solicitado.

. si ocurre.Respuesta a la Incertidumbre ‡ Los Directores también gestionan los proyectos en respuesta a la incertidumbre. tiene un efecto positivo o negativo al menos en uno de los objetivos de dicho proyecto. ‡ El riesgo de un proyecto es un evento o condición inciertos que.

es susceptible de no ser finalizado a tiempo y dentro de un presupuesto y.En palabras sencillas ‡ RIESGO ± Es el grado en que un determinado proyecto. sobre todo. la probabilidad de que el desenlace deseado no se logre. o parte de un proyecto. .

Áreas de experiencia ‡ Habilidades interpersonales ‡ Conocimientos y habilidades de dirección general ‡ Comprensión del entorno del proyecto ‡ Conocimientos. normas y regulaciones del área de aplicación .

.Destrezas del Gerente de Proyectos ‡ Efectiva comunicación en un ambiente multidisciplinario. ‡ Comprender el ambiente cultural para manejar eventuales conflictos y problemas. ‡ Administrar el cambio a través de un liderazgo efectivo y destrezas analíticas. ‡ Construcción de equipos de trabajo efectivos en varios niveles organizacionales.

Destrezas Clave ‡ Liderazgo ± Establecer dirección ± Alinear al personal ± Motivar e inspirar ‡ Comunicación ± Escrita u oral ± Interno o externo ± Formal e informal ± Vertical y horizontal .

costo y calendario ± Cambios de alcance. costo y/o calendario ± Términos y condiciones de contrato ± Asignaciones ± Recursos ‡ Resolución de problemas ± Definición del problema ± Toma de decisiones .Destrezas Clave ‡ Negociación ± Alcances.

Destrezas Clave ‡ Influir en la organización ± Hacer que las cosas pasen ± Sobre el comportamiento .

Responsabilidades del Administrador de Proyectos ‡ Es ante sus clientes. ‡ El PMI posee un código de ética que deben respetar todos sus miembros. administración. ‡ Son los responsables de la planificación. . supervisión. la organización ejecutante. motivación. comunicación. formación. los interesados y el público. reajustes y logros. coordinación.

saber como organizar una reunión con un equipo de trabajo.Responsabilidades del Administrador de Proyectos ‡ Su éxito está en función de su capacidad de ofrecer las críticas con eficacia. .

Responsabilidades del Administrador de Proyectos
‡ Conservar la calma y el buen sentido del compañerismo, gestionar bien su tiempo, tener apertura al cambio y los nuevos procedimientos. Además de utilizar las herramientas de apoyo con eficacia y perfeccionar la capacidad para tomar decisiones.

Las 5 Reglas Doradas en la Administración de Proyectos
‡ La Administración del tiempo es crítico ‡ Seguimiento de los costos y administración de las finanzas ‡ Los objetivos del Aseguramiento de la Calidad están fijados. ‡ Controlar el alcance a un nivel micro. ‡ Resolver los incidentes rápido.

Ciclo de Vida de un Proyecto
‡ Los proyectos se dividen en fases para facilitar la gestión. ‡ El conjunto de fases se conoce como el ciclo de vida del proyecto.

Generalidades del Ciclo de Vida del Proyecto
‡ Define el inicio y fin de un proyecto. ‡ Define cuáles actividades de transición se ejecutarán al inicio y al final del proyecto. ‡ Usualmente los entregables de la fase deben ser aprobados antes de que inicie la siguiente.
± A excepción del Fast Tracking (traslape de fases)

Generalidades del Ciclo de Vida del Proyecto
‡ Generalmente define
± Trabajo que se debe hacer en cada fase ± Quién está involucrado en cada fase

‡ El nivel de definición de cada fase depende de la metodología de Gerencia de Proyectos que se emplee.

‡ Riesgo es alto al inicio y bajo al final. ‡ La probabilidad de éxito es baja al inicio y alta al final.Características comunes del Ciclo de Vida del Proyecto ‡ Fases secuenciales con transferencias de información técnica. .

Características comunes del Ciclo de Vida del Proyecto .

Características comunes del Ciclo de Vida del Proyecto .

que sea la mejor.El ciclo de vida óptimo de un Proyecto ‡ No existe una única manera. para definirlo ‡ Las organizaciones ± Estandarizan los proyectos bajo un único Ciclo de Vida ± Permiten al Equipo de Proyecto que defina el Ciclo de Vida que consideren apropiado .

Fases de un Proyecto ‡ Minimizan la incertidumbre y facilitan la gestión ‡ Conjuntamente forman el ciclo de vida de un proyecto ‡ Cada fase tiene uno o más entregables ‡ Entregable: Producto tangible y verificable .

Fases de un Proyecto ‡ El fin de cada fase considera: ± Revisión de entregables -> producto ± Medición del desempeño -> proyecto ‡ Con el propósito de: ± Determinar si el proyecto continúa ± Detectar errores y repararlos al mejor costo .

Fases de un Proyecto ‡ Terminar una fase no implica la autorización para iniciar la siguiente ± Se pueden establecer revisiones en donde se obtiene la autorización para cerrar la fase e iniciar la siguiente ± A las finalizaciones de fase también se les llama ‡ Salidas de fase (Phase exits) ‡ Entradas de fase (Phase gates) ‡ Puntos de cancelación (Kill points) .

Fases en ciclo de vida del proyecto .

Fases en ciclo de vida del producto .

Relación entre ciclos de vida .

Organización Ejecutora. Patrocinadores. PMO . Cliente.Identificación de los Stakeholders ‡ Los actores o stakeholders son individuos y organizaciones que están activamente involucrados en el proyecto ‡ Sus intereses pueden influir positiva o negativamente a la finalización del proyecto ‡ Actores ± Gerente de Proyecto.

Relación entre los involucrados y el Proyecto .

Curva de Costo .

Necesidad de una Metodología ‡ El desarrollador realizaba un levantamiento de las necesidades del usuario. los originales y los que aparecían durante el desarrollo. comenzaba la dura tarea de codificar. . y en base a este primer levantamiento. ‡ Estos sistemas crecían. terminado el proyecto cuando se cumplían todos los requerimientos del sistema.

.

. planificar y controlar un proyecto de desarrollo.¿Qué es una Metodología? ‡ DEFINICIÓN 1 Metodología de desarrollo de software en ingeniería de software es un marco de trabajo usado para estructurar. que permite llevarlo a cabo con altas posibilidades de éxito.

Lo hacen desarrollando un proceso detallado con un fuerte énfasis en planificar inspirado por otras disciplinas de la ingeniería.¿Qué es una Metodología? ‡ DEFINICIÓN 2 Las metodologías imponen un proceso disciplinado sobre el desarrollo de software con el fin de hacerlo más predecible y eficiente. .

sobre todo aquellos proyectos de gran tamaño. ‡ Han demostrado ser efectivas y necesarias en un gran número de proyectos. ‡ No se han distinguido precisamente por ser muy exitosas. ‡ La crítica más frecuente es que son burocráticas. . Aún menos por su popularidad.Aspectos de una Metodología ‡ Han estado presentes durante mucho tiempo.

porque no están pensadas para trabajar con incertidumbre.Aspectos de una Metodología ‡ La experiencia ha demostrado que las metodologías tradicionales no ofrecen una buena solución para proyectos donde el entorno es volátil y donde los requisitos no se conocen con exactitud. .

.Aspectos de una Metodología ‡ Aplicar metodologías pesadas nos obliga a forzar a nuestro cliente a que tome la mayoría de las decisiones al principio. ‡ Hay una alta dependencia de los riesgos detectados al inicio y de negociaciones previas. ‡ El coste de cambio de una decisión tomada puede llegar a ser muy elevado.

Qué restricciones se aplican. . Qué salidas se producen y cuándo se deben producir. Qué herramientas se van a utilizar. Qué tareas se llevan a cabo en cada etapa. Heurísticas para llevar a cabo dichas tareas.Métodos (metodologías) de Desarrollo de Software ‡ Conjunto de pasos y procedimientos que deben seguirse para el desarrollo de software ± ± ± ± ± ± ± Cómo se debe dividir un proyecto en etapas. Cómo se gestiona y controla un proyecto.

Problemas frecuentes
‡ ‡ ‡ ‡ ‡ ‡ ‡ Retrasos en la planificación. Sistemas deteriorados (alto costo de soporte) Tasa de defectos (nadie lo usa) Requisitos mal comprendidos Cambios de negocio Falsa riqueza Cambios de personal

Metodologías Ágiles
‡ Como respuesta a estos problemas han surgido nuevas metodologías, cuyo encanto consiste en la reacción ante la burocracia. ‡ Buscan un punto medio entre ningún proceso y demasiado proceso. ‡ Son menos orientados al documento y más bien orientados al código.

Tipos de Metodologías
‡ Metodologías Ágiles ‡ Metodologías Tradicionales o Estructuradas

Algunas Metodologías
‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ Rational Unified Process (RUP) Extreme Programming (XP) Feature Driven Development (FDD) SCRUM Crystal Methods (CM) Dynamic Solutions Delivery Model (DSDM) Microsoft Solutions Framework (MSF) Rapid Development (RAD) Agile Modeling (AM) Agile RUP (dX)

Detectar defectos en las fases iniciales. intenta anticiparse a futuras necesidades.Características Levantamiento exhaustivo de requerimientos. Reducir los cambios tanto como sea posible. ‡ Diseño genérico. tan completo como sea posible. Análisis y diseño. ‡ ‡ ‡ ‡ .

.

Características ‡ ‡ ‡ ‡ ‡ ‡ ‡ Proceso dirigido por casos de uso Proceso centrado en la arquitectura Proceso iterativo o incremental Modelado visual UML Verificación continua de calidad Gestión de los cambios Administración de los riesgos .

Estructura del Proceso .

.

Metodologías Ágiles ‡ En el 2001 en Utah-EEUU en una reunión de expertos de la industria del software. ‡ El punto de partida fue el Manifiesto Ágil. . un documento que resume la filosofía "ágil". nace el término "ágil" aplicado al desarrollo de software. ‡ Tras esta reunión se creó The Agile Alliance .

Esencia del Manifiesto Ágil PREFERIMOS A las personas y su comunicación El software que funciona La colaboración con el cliente La respuesta al cambio DESCONFIAMOS Los procesos y las herramientas La documentación exhaustiva La negociación contractual Seguimiento de un plan .

Metodologías Ágiles ‡ En la actualidad se cuentan alrededor de 15 a 20 metodologías ágiles sin contar los métodos híbridos de desarrollo que integran en sus practicas como ejemplo a XP con Scrum. .

.

Prácticas Esenciales ‡ ‡ ‡ ‡ ‡ ‡ Pruebas Refabricación Programación en pares Juego de planeación Liberaciones pequeñas Integración continua .

.

Historias de Usuario .

.

.

Características ‡ Cuatro principios fundamentales: ± Los individuos e interacciones son más importantes que los procesos y las herramientas. ± Que el software funcione es más importante que la documentación exhaustiva. ± La colaboración con el cliente es más importante que la negociación de contratos. ± La respuesta ante el cambio es más importante que el seguimiento de un plan. .

‡ El método es fácil de aprender y modificar para el equipo. . ‡ Permite cambios de último momento.Características ‡ Pequeños y frecuentes releases o entregas con ciclos rápidos (1 a 4 semanas). ‡ Clientes y desarrolladores trabajan constantemente con una comunicación muy fina y constante.

Características
‡ Cada iteración del ciclo de vida incluye: planificación, análisis de requerimientos, diseño, codificación, revisión y documentación. ‡ La meta es tener un demo (sin errores) al final de cada iteración. ‡ Criticados y tratados como "indisciplinados" por la falta de documentación técnica.

Uso de Metodologías Ágiles

Empresas que utilizan Metodologías Ágiles

¿Por qué razón o razones lo hacen?
Para reducir el tiempo de desarrollo: 45% Para mejorar la calidad: 43% Para reducir costes: 23% Para alinear el desarrollo con los objetivos de negocio: 39% ‡ Otras razones: 12%. ‡ ‡ ‡ ‡

Ranking entre modelos ágiles
1º.- Extreme Programming (28%) 2º.- FDD (26%) 3º.- Scrum (20%) 4º.- Crystal Agil (6%) 5º.- DSDM (4%)

. Metodologías tradicionales Metodologías Ágiles Metodologías Tradicionales Basadas en heurísticas provenientes Basadas en normas provenientes de de prácticas de producción de código. con pocos Procesos mucho más controlados. Cierta resistencia a cambios.Metodologías ligeras vs. Existe un contrato prefijado. Proceso menos controlado. Especialmente preparados para cambios durante el proyecto. estándares seguidos por el entorno de desarrollo. Impuestas internamente por el equipo de desarrollo. No existe contrato tradicional o al menos es bastante flexible. Impuestas externamente. con muchas políticas/normas. principios.

Más artefactos. La arquitectura del software es esencial y se expresa mediante modelos.Metodologías ligeras vs. Menos énfasis en la arquitectura de software. Pocos artefactos. . Grupos pequeños (no más de 10) trabajando en el mismo sitio. Metodologías tradicionales Metodologías Ágiles El cliente es parte del equipo de desarrollo. Grupos grandes y posiblemente distribuidos. Metodologías Tradicionales El cliente interactúa con el equipo de desarrollo mediante reuniones. Pocos roles. Más roles.

El punto de partida de cualquier metodología de desarrollo de software es la definición de los requerimientos .

Tipos de Organizaciones .

Organización funcional .

Organización funcional .

Organización orientada a proyectos .

Organización orientada a proyectos .

Organización matricial débil .

Organización matricial débil .

Organización matricial equilibrada .

Organización matricial equilibrada .

Organización matricial fuerte PMO .

Organización matricial fuerte .

Organización combinada PMO .

¿Qué es una PMO? ‡ Unidad operacional utilizada para centralizar y coordinar los proyectos bajo su dominio. ‡ Se le conoce también como: ± Oficina de Gerencia de Proyectos ± Oficina de Proyectos ± Oficina de Programas .

Grupos de Procesos de la Gerencia de Proyectos .

Interacción de los Grupos de Procesos .

Metodología para la Gestión de Proyectos de BABEL Software .

.

‡ At least 2 of our clients are usually in the top 10 of Fortune Magazine s ranking. . ‡ 8 years of experience in more than 10 countries. ‡ Customized software development and complementary services.Company s profile ‡ 100% Costa Rican investment. ‡ More than 200 projects successed.

I. (Cenfotec) Universidad Nacional de Costa Rica (UNA) Escuela Politécnica del Ejército Ecuatoriano (ESPE) .Personnel ‡ 4 offices in 3 countries ± Costa Rica (San José and Pérez Zeledón) ± Ecuador (Cotopaxi) ± USA (Florida partner) ‡ 80 collaborators. graduated from: ± ± ± ± Instituto Tecnológico de Costa Rica (ITCR) Centro de Formación en T.

Infrastructure Support .Business Areas ‡ ‡ ‡ ‡ ‡ Customized Software Development Business Intelligence Applications Support and Maintenance Outsourcing (consulting time) I.T.

Net PHP Java Oracle AS/400 Other technologies .Technologies ‡ ‡ ‡ ‡ ‡ ‡ Microsoft .

Clients (International Corporations) Corporations) .

Clients (Local Companies and Institutions) Institutions) .

Clients (Software and I.T. Companies) Companies) FWY Consulting Services .

Estrategia de la Empresa ‡ Visión ± Ser reconocida internacionalmente como una compañía costarricense consolidada y confiable. que brinda las mejores soluciones en el área de la Tecnología de Información .

haciendo uso de las tecnologías más modernas disponibles y el personal más calificado del mercado. satisfaciendo plenamente y de manera eficiente y ordenada.Estrategia de la Empresa ‡ Misión ± Brindamos al mundo las soluciones informáticas a la medida de la más alta calidad. las necesidades informáticas de nuestros clientes .

.

Estrategia de la Empresa ‡ ¿Cómo alinear los proyectos a la estrategia? .

Estrategia de la Empresa ‡ Evaluación y formulación de proyectos ‡ La rentabilidad de un proyecto debe ser mayor a cualquier opción disponible en el mercado .

± En 1997 salió a la luz la versión 1. un año después Jacobson se unía a ellos en Rational. . James Rumbaugh.Generalidades de la Metodología ‡ ¿Qué es UML? Lenguaje Unificado de Modelado ± UML no es un método de desarrollo ± Durante los ochenta y principios de los noventa Grady Booch.0 de UML. e Ivar Jacobson trabajaban por separado ± En 1994 Rational contrató a Rumbaugh en donde ya trabajaba Booch.

‡ Elaboración. En esta etapa el objetivo es llevar a obtener la capacidad operacional inicial. ‡ Construcción.Generalidades de la Metodología ‡ ¿Qué es RUP? Rational Unified Process ± Es una metodología para el desarrollo de software. Se divide en 4 fases: ‡ Inicio. En esta etapa el objetivo es determinar la arquitectura óptima. El objetivo es llegar a obtener el release del proyecto. ‡ Transmisión. El Objetivo en esta etapa es determinar la visión del proyecto. .

Generalidades de la Metodología ‡ ¿Qué es el PMI? Project Management Institute ± Es la organización internacional sin fines de lucro que asocia a profesionales para la gestión de proyectos. Estados Unidos .000 miembros alrededor de 171 países. ± Se encuentra integrada por más de 260. ± La oficina central está en Filadelfia en Pennsylvania.

Generalidades de la Metodología ‡ ¿Qué es el PMI? Project Management Institute ± Sus principales objetivos son: ‡ Formular estándares profesionales ‡ Generar conocimiento a través de la investigación ‡ Promover la Gestión de Proyectos como profesión a través de sus programas de certificación .

como ingenieros electricistas. en computación. en informática.Generalidades de la Metodología ‡ ¿Qué es el IEEE? Instituto de Ingenieros Eléctricos y Electrónicos ± Es una asociación técnico-profesional mundial dedicada a la estandarización. en electrónica. . en biomédica y en telecomunicación. ± Es la mayor asociación internacional sin fines de lucro formada por profesionales de las nuevas tecnologías. entre otras cosas.

Generalidades de la Metodología ‡ ¿Qué es CMMi? Capability Maturity Model Integration ± CMMi es el modelo para la mejora o evaluación de los procesos de desarrollo y mantenimiento de sistemas y productos de software. ± Desarrollado por el Instituto de Ingeniería del Software de la Universidad Carneige Mellon (SEI). y publicado en su primera versión en enero de 2002. .

Generalidades de la Metodología ‡ ¿Qué es CMMi? Capability Maturity Model Integration .

mezclada con la propuesta de los grupos de procesos del PMI. ‡ Todos los documentos siguen un mismo formato. solicitado por los estándares del IEEE.Generalidades de la Metodología ‡ ¿Cómo intervienen todos estos conceptos en la Metodología de BABEL? ‡ Todos los documentos técnicos están basados en UML ‡ La metodología de desarrollo se basa en la propuesta de ciclo de vida de Rational. .

Descripción de la Metodología de BABEL ‡ Nace de la necesidad de una organización formal (documentada) de su forma de trabajar ‡ Objetivo estratégico de certificar la empresa como CMMi nivel 3 ‡ Se toma también como base las mejores prácticas del PMI. así como la forma de documentar usando UML y los formatos estándar de IEEE e ISO .

Metodología de Desarrollo .

Proceso Pre-venta & Venta ‡ Actividades de búsqueda de posibles prospectos ‡ Lograr contacto con los prospectos ‡ Ofrecer servicios ‡ Generar propuestas de proyectos ‡ Dar seguimiento a las propuestas ‡ Dar seguimiento a los clientes .

Administración de Pipelines .

CRM .

Sector Privado ‡ Contactos ‡ Tele-Mercadeo ‡ Visita a Clientes .

Sector Gobierno ‡ Monitoreo de Concursos Públicos ‡ Participación en Licitaciones .

. en la cual nuestros business analysts le dan forma al proyecto y lo cotizan (en tiempo y dinero).Fase de Inicio / Conceptualización ‡ Esta fase es la que da inicio (como su nombre lo indica) al proceso de crear un proyecto de software a la medida. ‡ Todo comienza con una negociación de proyecto.

Fase de Inicio / Conceptualización ‡ Una vez que el cliente haya aceptado la cotización. se firma un contrato e inicia el proyecto ‡ Cuando inicia el proyecto. también llamada propuesta de negocio. se tiene que conceptualizar y hay que refinar el alcance del proyecto .

ésta pasa por QA y luego al cliente (constando que ese es el alcance y que lo que está en la especificación es lo que se va a hacer. nada menos). que estipula el formato de un documento de este tipo ‡ Una vez. . nada más.Fase de Inicio / Conceptualización ‡ Cabe destacar que la especificación está basada en el estándar IEEE 830. creada la ERS.

.

Fase de Inicio / Conceptualización ‡ ENTREGABLES ± Declaración preliminar de trabajo (SOW) ± Estructura Desglosada de Trabajo (WBS) ± Cronograma ± Propuesta ± Contrato de Servicios ± Carta Constitutiva ± Especificación de Requerimientos de Software (ERS) .

Declaración preliminar de trabajo (SOW) ‡ Las características y fronteras del proyecto ‡ Sus productos y servicios asociados ‡ Los métodos de aceptación y control del alcance .

Declaración preliminar de trabajo (SOW) ‡ Debe contener: ± Objetivos del proyecto y del producto ± Requerimientos y características del producto/servicio ± Criterios de aceptación del producto ± Fronteras del proyecto ± Requerimientos y entregables del proyecto ± Limitaciones o restricciones del proyecto .

Declaración preliminar de trabajo (SOW) ‡ Debe contener: ± Supuestos del proyecto ± Organización inicial del proyecto ± Riesgos iniciales ± Hitos (milestones) ± WBS inicial ± Costos estimados ± Requerimientos de aprobación .

Estructura Desglosada de Trabajo (WBS) .

Estructura Desglosada de Trabajo (WBS) ‡ Apoya al Gerente del Proyecto y Patrocinadores en el desarrollo de una clara visión del producto final del proyecto .

Estructura Desglosada de Trabajo (WBS) ‡ Es la descomposición jerárquica del trabajo que será ejecutado ± Definen el alcance del proyecto ± Enfoque en entregables ± Niveles detallan entregables .

Estructura Desglosada de Trabajo (WBS) ‡ Permite ± Pensar en el proyecto como un todo ± Estimar claramente los entregables ± Pensar en las mejores metodologías para la generación y obtención de los entregables ‡ Cuáles son las partes componentes? ‡ Cómo trabajan juntas estas partes? (Integración) ‡ Qué requiere ser realizado? .

Estructura Desglosada de Trabajo (WBS) ‡ Reglas para su elaboración ± El WBS evoluciona a través del proyecto interactuando entre elementos como: ‡ ‡ ‡ ‡ ‡ Propósito Objetivos Criterios en la formulación del desempeño funcional Alcance del proyecto Requerimientos técnicos y otros aspectos .

Estructura Desglosada de Trabajo (WBS) ‡ Reglas para su elaboración ± ¿Cómo se puede comer a un elefante? ‡ De mordisco a mordisco ± El WBS es la técnica para (descomponer) dividir el elefante en piezas pequeñas .

Estructura Desglosada de Trabajo (WBS) ‡ Reglas para su elaboración ± Paso 1: Identificar el producto final para tener éxito en el proyecto ± Paso 2: Definir los entregables más significativos y la precedencia correspondiente ± Paso 3: Descomponer los mayores entregables a un nivel de detalle ± Paso 4: Revisar y redefinir el WBS hasta que los patrocinadores estén de acuerdo .

Estructura Desglosada de Trabajo (WBS) ‡ Supuestos ± Cada entregable del WBS debe representar un único entregable tangible ± Cada elemento del WBS debe representar la suma de todos los elementos subordinados ± Cada elemento subordinado debe pertenecer a solo un elemento superior .

Estructura Desglosada de Trabajo (WBS) ‡ Respecto a los entregables: ± Lógicamente desagregados a un nivel que presente como deben ser los recursos ± Únicos y diferenciados de sus pares y descompuestos a nivel de detalle para que sean manejables ± Bien definidos para eliminar la duplicación de esfuerzos ± De un tamaño limitado ‡ Deben actualizarse. cuando el alcance cambia .

Estimación de Esfuerzo ‡ Necesita de los activos de procesos de la empresa y consiste en el siguiente proceso: ± Identificación de requerimientos ± Desglose de requerimientos en casos de uso ± Sumatoria del total de los casos de uso ± Multiplicación de casos de uso por el tiempo promedio de los desarrolladores por caso de uso ± Identificación de recursos necesarios para entregar el proyecto a tiempo .

1 Req. 2 Req. 4 TOTAL 5 10 7 8 30 30 CU * 2 días / CU = 60 días 60 días / 3 programadores = 20 días / programador Levantamiento de requerimientos (25%): 15 días Proceso de cierre: 10 días TOTAL: 45 días = 2 meses .Estimación de Esfuerzo Casos de Uso Req. 3 Req.

‡ Marcan el compromiso inicial adquirido con el cliente en cuanto a la distribución del esfuerzo y la entrega de productos.Cronograma ‡ Diagrama de Gantt con las actividades interrelacionadas que componen el proyecto. .

16%) Fondo de reserva (8.Estimación de Costos y Gastos ‡ Incluye ± Salarios por perfil ± Cargas sociales ‡ ‡ ‡ ‡ ‡ Seguro social (12.33%) 14vo salario ($20 x mes) Vacaciones (4.33%) ± Viáticos y otros gastos ± Gastos Administrativos ± Utilidad Neta de la empresa .15%) Aguinaldo (13vo salario = 8.

tanto en entradas como en salidas del proyecto ‡ Debe contemplar los momentos de inversión .Proyección del Flujo de caja ‡ Preferiblemente semanal o diario ‡ Incluye todo el movimiento de recursos económicos.

Análisis preliminar de riesgos ‡ Consiste en la aplicación de los conocimientos existentes en los activos de procesos. . ‡ Pretende que los riesgos sean tomados en cuenta desde antes de iniciar el proyecto y de ser posible que se consideren en el contrato. que se pueden identificar como posibles riesgos en el nuevo proyecto.

Propuesta ‡ Basada en el SOW ‡ Incluye el cronograma de trabajo ‡ Forma de pago basada en el flujo de caja proyectado ‡ Cláusulas de garantía y calidad ‡ Puede ser la preparación de un Cartel de Licitación Pública .

Contrato de Servicios ‡ Se debe aclarar el alcance acordado ‡ Incluir plan preliminar de riesgos ‡ Firmado por Representante Legal de la Empresa ‡ Marca el inicio formal del compromiso ‡ En ocasiones no existe contrato pero existe una Orden de Compra .

Reunión de arranque (kick-off) ‡ Deben asistir: ± Analista de Negocios ± Gerente Financiero ± PMO Manager ± Gerente de Proyecto ± Gerente de Calidad ± Gerente de Soporte de Aplicaciones ± Involucrados en la Gestión interna .

Reunión de arranque (kick-off) ‡ Agenda de la reunión: ± ± ± ± ± ± ± ± ± Descripción del proyecto Tiempo del proyecto Presupuesto del proyecto Flujo de caja del proyecto Calendario de actividades Forma de pago Hitos o entregables Riesgos Otros .

Carta Constitutiva de Proyecto ‡ Identifica los principales stakeholders ‡ Establece los parámetros del proyecto: ± Presupuesto ± Tiempo .

‡ Se puede presentar el rechazo al cambio por parte de varios usuarios. . ‡ Es ideal tener activos de procesos que faciliten la toma de requerimientos.Levantamiento de Requerimientos ‡ Se deben efectuar todas las reuniones posibles y necesarias con los usuarios finales y la contraparte técnica.

mediante el modelado en UML de las funcionalidades que conforman el sistema ‡ Es una descripción completa del comportamiento del sistema que se va a desarrollar ‡ Basado en el estándar IEEE 830 .Especificación de Requerimientos de Software (ERS) ‡ Consiste en la declaración del alcance.

Especificación de Requerimientos de Software (ERS) ‡ Se describe el sistema y sus objetivos ‡ Se describen los actores ‡ Se describen los requerimientos ± Funcionales ± No funcionales ‡ Se modelan todos los casos de uso ‡ Se establecen las relaciones entre los casos de uso .

crear un Plan de Riesgos . es decir. el cual da a conocer a todos los involucrados fechas importantes del proyecto. el trabajo a realizar ‡ Además se tiene que pensar en los riesgos asociados con el proyecto. así como. formalmente. se crea un Cronograma de Trabajo.Fase de planeación ‡ Una vez que se conoce el alcance del proyecto.

se planea la integración de lo que está por desarrollarse. es decir. por medio de un Plan de Integración .Fase de planeación ‡ El Plan de Riesgos se basa en el estándar IEEE 1540 ‡ Además. cómo se conjuntarán las piezas de software y su orden para crear el producto del proyecto.

.

Fase de planeación ‡ ENTREGABLES ± Cronograma de Trabajo ± Plan de Riesgos ± Matriz de Responsabilidades ± Plan de Integración ± Plan de Pruebas (QA) ± Plan de Implantación ± Plan de Capacitación .

material y dinero) ‡ En esta herramienta se registra el avance diariamente y de ahí se obtienen los indicadores de avance general .Cronograma de Trabajo ‡ Se implementa sobre Microsoft Project ‡ Conjunto de actividades interrelacionadas que por tanto dependerán unas de otras ‡ Conjunto de recursos (humano.

analizar y responder a los riesgos del proyecto ± Estimando y planeando las actividades análisis.Plan de Riesgos ‡ La gestión de riesgos del proyecto es el proceso de identificar. planeación y gestión del riesgo para el proyecto ± Determinando cuáles riesgos pueden afectar el proyecto y documentándolos con sus características ± Realizando un análisis cualitativo del riesgo y de las condiciones para priorizar sus efectos sobre los objetivos del proyecto .

identificando nuevos riesgos. ejecutando planes de reducción de riesgos. y evaluando la efectividad a través del ciclo de vida del proyecto .Plan de Riesgos ± Midiendo la probabilidad y las consecuencias de los riesgos y estimando sus implicaciones en los objetivos del proyecto ± Desarrollando procedimientos y técnicas para aumentar las oportunidades y disminuir las amenazas en los objetivos del proyecto ± Monitoreando riesgos residuales.

Plan de Riesgos Gestión de Riesgos Del Proyecto Planeación de Riesgos Análisis Cualitativo de Riesgos Análisis Cuantitativo de Riesgos Monitoreo y control del Riesgo Identificación de Riesgos Planeación de la Respuesta al Riesgo .

Plan de Riesgos PROBABILIDAD DE OCURRENCIA Alta Media Baja Por ejemplo: probabilidad de ocurrencia > 70 % Por ejemplo: Probabilidad de ocurrencia entre el 30 % y el 70 % Por ejemplo: Probabilidad de ocurrencia < 30 % .

inundaciones etc.Plan de Riesgos CATEGORIAS DE RIESGOS Categoría Codificación 01-01 01-02 01-03 01-04 01-05 01-06 01-07 01-08 01-09 02-01 02-02 02-03 02-04 02-05 03-01 03-02 03-03 04-01 04-02 04-03 04-04 04-05 04-06 05-01 05-02 05-03 05-04 06-01 06-02 06-03 06-04 07-01 07-02 07-03 Factor de Riesgo Alcance y Entregables del Proyecto Ampliación del cronograma Cambios en el Alcance Roles & Responsabilidades no Definidas Completamente Administración de la Calidad Administración del Cambio Métodos de Estimación Uso inadecuado de las disciplinas del proyecto Calidad inadecuada en el plan del proyecto Deficiencia en la asignación de recursos Habilidades del Equipo Desviación de Recursos No Disponibilidad de Determinado Bien o Servicio Conflictos de recursos con otros proyectos Integración de Productos Prioridades del Proyecto en Conflicto Prioridades del Proveedor en Conflicto Nueva Tecnología Infraestructura requerida Ambiente de Desarrollo Ambiente de Producción Objetivos de desempeño no reales Confianza en tecnología no probada o compleja Ocultación de la información Influencias Políticas Resistencia al Cambio Compromiso Gerencial Objetivos de costos. técnicos o calidad Codigo: 04 Cultura Codigo:05 Organizacionales Codigo: 06 Externos Codigo: 07 . terremotos. clima. Administración Codigo:01 Recursos Codigo: 02 Complejidad Codigo: 03 Desempeño. tiempo y alcance inconsistentes Deficiencia en la definición del alcance Falta de priorización de los proyectos Fondos inadecuados o interrumpidos Cambio del ambiente legal o regulatorio Cambio de prioridades del dueño Riesgos del pais.

Plan de Riesgos CUANTIFICACIÓN DE RIESGOS Probabilidad Severidad Catastrófico Crítico Marginal Alta Alto Alto Medio Media Alto Medio Bajo Baja Medio Bajo Bajo .

o tiene alta posibilidad de impactar moderadamente uno o más de los siguientes factores: costos cronograma y/o producto del proyecto. o tiene alta posibilidad de impactar severamente uno o más de los siguientes factores: costos cronograma y/o producto del proyecto. Crítico Marginal .Plan de Riesgos CLASIFICACIÓN DEL IMPACTO Catastrófico Detiene la implementación del proyecto. Retrasa la implementación del proyecto y afecta directamente la fecha de entrega del proyecto. Retrasa el cronograma interno del proyecto pero no afecta su fecha de entrega. o tiene posibilidad de impactar muy poco uno o más de los siguientes factores: costos cronograma y/o producto del proyecto.

Matriz de Responsabilidades ‡ Tiene el objetivo de asignar las responsabilidades sobre los involucrados en el proceso de ejecución y aprobación ‡ Debe ser firmado por todas las personas a quienes se les está asignando una responsabilidad .

Plan de Integración ‡ Define cómo se conjuntarán las piezas de software y su orden para crear el producto del proyecto ‡ Se identifican los ciclos de desarrollo y los sets de casos de uso que los componen ‡ Se planifican las fechas de entrega. revisión y corrección de cada ciclo ‡ Intervienen el PM y el departamento de QA .

Plan de Pruebas ‡ Incluye las tareas. el tiempo de corrección de incidentes y el tiempo de liberación ‡ Se describen los analistas y técnicos de QA a cargo de las tareas ‡ Se explican las técnicas y herramientas que se utilizarán ‡ No incluye los casos de pruebas . el tiempo de pruebas de cada ciclo.

Plan de Implantación ‡ Se crea en la fase de cierre del proyecto pero pertenece a los procesos de planeación ‡ Se identifican los stakeholders técnicos responsables de la implantación y se genera una agenda de actividades para la instalación y puesta en producción de la aplicación ‡ Se incluyen los requerimientos de los equipos y del software requerido .

Plan de Capacitación ‡ Incluye: ± Objetivos de cada capacitación ± Los temas de capacitación ± Las fechas de las capacitaciones ± Usuarios requeridos ± Equipos requeridos ± Configuración de los equipos ± Material adicional .

Fase de ejecución ‡ En esta fase es donde se da el proceso de fabricación del software ‡ Se aplican todas las técnicas de control de calidad que la empresa posee ‡ Es la fase más gruesa de la metodología. existe un error de utilización de la metodología . si no.

‡ Termina con la última aprobación del software por parte del departamento de QA. ‡ Consiste en un desarrollo iterativo e incremental a base de ciclos que contienen sets de casos de uso ‡ Comunicación constante con los usuarios .Fase de ejecución ‡ Inicia con la creación del ambiente de trabajo por parte del Soportista Técnico.

Fase de ejecución ‡ Por parte de BABEL participan: ± PMO ± Gerente de proyectos ± Soportista técnico ± Líderes técnicos ± Analistas / Programadores ± Soportistas de aplicaciones ± Analistas de QA .

Fase de ejecución ‡ Por parte del Cliente participan: ± Patrocinador ± Contraparte técnica ± Usuarios finales ± Involucrados solo los que se vean afectados directamente con el resultado del proyecto .

.

Fase de ejecución ‡ ENTREGABLES ± Especificación de Diseño de Software ± Prototipo de la aplicación ± Ciclos de desarrollo (avances) ± Software o entregable programado .

Infraestructura del Cliente ‡ Visita al Cliente para analizar las características técnicas del ambiente de pruebas y producción donde residirá el sistema ‡ Replicación del ambiente de pruebas y producción en la Empresa ‡ Configuración de computadoras para los programadores .

Especificación de Diseño de Software (EDS) ‡ Documento técnico basado en UML: ± Diagrama de Clases ± Diagrama de Base de Datos ± Casos de Uso en formato expandido ± Arquitectura del sistema ± Diagramas de interacción ± Diccionario de Datos ± Otros diagramas opcionales .

Prototipo ‡ Diseño gráfico de la concepción del producto que el equipo obtuvo durante la fase de conceptualización ‡ Preferiblemente no debe ser funcional para evitar retrabajo .

Ciclos de Desarrollo ‡ El Gerente de Proyecto asigna las tareas de programación a cada programador ‡ Los Programadores implementan los casos de uso y realizan sus pruebas unitarias ‡ Los Programadores reportan el tiempo invertido en cada tarea realizada mediante el ACWP .

en caso de que se hayan modificado los casos de uso durante el desarrollo .Ciclos de Desarrollo ‡ El PM debe encargarse de coordinar con el departamento de Soporte de Aplicaciones para realizar la instalación ‡ Además el PM deberá pasar una actualización del Plan de Integración.

¿Y QA? ‡ Por su parte los Técnicos de Calidad preparan los casos de prueba (test-cases) que serán aplicados al entregable del ciclo en proceso ‡ Una vez que reciben el entregable parcial o final. le aplican los casos de prueba y recogen los resultados ‡ Finalmente pasan un informe de ciclo al PM .

Entregable Programado ‡ Son los avances programados que van recibiendo el visto bueno de QA para ser liberados e instalados donde el cliente ‡ El PM debe gestionar la instalación temprana de estos entregables para evitar sorpresas en la entrega final .

Fase de control ‡ Mientras se desarrolla el software. debe de crear informes de avances. para así llevar al día el proyecto y estar pendiente de los riesgos ‡ El administrador asignado al proyecto. los cuales están compuestos por métricas que describen el avance y comportamiento del proyecto . se tiene que ir llevando un control detallado del avance.

.

Fase de control ‡ ENTREGABLES ± Informes periódicos de avance ± Informes de riesgos ± Informes de ciclo ± Estadísticas de rendimiento (QA) ± Informes periódicos de seguimiento .

Informes periódicos de avance ‡ Tienen la intensión de informar al Cliente sobre el avance en las actividades. ‡ Su estructura consiste en: ± ± ± ± ± ± ± Estado Actual (semáforo) Actividades realizadas en el pperíodo anterior Observaciones con respecto a las actividades realizadas Análisis de la situación actual Actividades por realizar en el siguiente período Observaciones con respecto a las actividades por realizar Indicadores de avance .

se debe indicar cuál fue el plan de mitigación tomado y su impacto ‡ Si un riesgo está activo.Informes de Riesgos ‡ Es una descripción de los riesgos que se han materializado en el período anterior y su estado ‡ Si un riesgo está cerrado. se debe indicar las acciones de reducción que se están tomando y su impacto .

‡ La intensión es informar a QA sobre el tiempo reportado por cada desarrollador para cada la implementación de cada caso de uso ‡ Luego de la revisión de los casos de prueba correspondientes QA emitirá un informe de resultado .Informes de ciclos ‡ El PM entrega este informe a QA cada vez que finaliza un ciclo de desarrollo.

Estadísticas de rendimiento ‡ Alimentan los activos de procesos de la empresa ‡ Lanzan alertas a tiempo sobre cualquier irregularidad positiva o negativa en el desempeño del personal ‡ Permiten tomar decisiones en relación con el futuro del proyecto .

por caso de uso ‡ El rendimiento también toma en cuenta el tiempo inicial estimado para la tarea .Estadísticas de rendimiento ‡ Recibe como entrada el tiempo de desarrollo de cada caso de uso ‡ El re-trabajo consiste en una comparación entre el tiempo de desarrollo y el tiempo de corrección de incidentes.

Antecedentes ‡ Los productos de los proyectos no se logran a tiempo ‡ La calidad de los productos es inadecuada ‡ El gasto escapa del control de los diferentes niveles operativos y gerenciales ‡ Existe un alto grado de frustración en los usuarios directos e indirectos del proyecto ‡ La organización pierde oportunidades estratégicas ‡ Se producen gastos excesivos que no responden al rédito producido ‡ No se cuenta con metodologías ni estándares para identificación y medición del riesgo .

debido a un inadecuado inicio del mismo ± Inapropiada definición de objetivos ± Alcance desconocido ó pobremente definido ± Mala definición de los miembros del equipo ± Débil comunicación ‡ 50% de los proyectos con un sobrepresupuesto entre el 100%-400% .Hechos de la industria ‡ 85% de los proyectos falla.

6% en la estimación de la calidad .8% en la estimación del costo/hora 32.6% en la estimación del cronograma 32.Hechos de la industria ‡ Al incorporar las mejores prácticas en Administración de Proyectos las empresas han logrado una mejora del: ± ± ± ± ± ± ± 37.8% en la productividad del equipo 38.6% en la satisfacción del cliente 37% en el alineamiento estratégico 22.5% en presupuesto y cronograma al día 7.

Control de Costos ‡ Una vez que se inicia el proyecto se debe monitorear el costo real y el desempeño del trabajo y comparar con el presupuesto ‡ Se deben revisar de forma periódica: ± Cantidad real acumulada y gastada desde el inicio del proyecto ± Valor del trabajo realizado desde el inicio del proyecto ± Cantidad presupuestada y acumulada que se planea gastar ± Flujo de caja .

proyectado . cuanto me falta para completar .Informes periódicos de seguimiento ‡ Utilizan los indicadores del Earned Value como base: ± ± ± ± ± ± ± ± ± ± ACWP: Actual Cost Work Performed suma de costos a la fecha BCWP: Budget Cost Work Performed BCWS: Budget Cost Work Scheduled CV: Cost Variance variación en costo SV: Schedule Variance variación en tiempo SPI: Schedule Performance Indicator CPI: Cost Performance Indicator CSI: Cost Schedule Indicator ETC: Estimated To Complete ($).proyectado EAC: Estimated At Completion ($) cuanto va a costar al terminar .

Earned Value ‡ El Earned Value o Valor del Trabajo Realizado es utilizado para la administración y control de los calendarios y costos de los proyectos ‡ Se puede considerar como un indicador que cuantifica cuánto trabajo ha sido completado en un proyecto y ayuda a calcular un estimado. tanto del tiempo como del costo faltantes. .

Cálculo del Earned Value ‡ Involucra el cálculo de 3 Valores Claves para cada actividad: ± Presupuesto ‡ También llamado Costo Presupuestado del Trabajo Planeado (CPTP o BCWS) ± Costo Real ‡ También llamado Costo Real del Trabajo Realizado (CRTR o ACWP) ± Valor del Trabajo Realizado (Earned Value) ‡ También llamado Costo Presupuestado del Trabajo Realizado (CPTR o BCWP) .

00 $0.0916233006132027Set.000.Oct.00 $15.00 $20.Ago.000.Nov09 09 09 09 09 09 09 09 09 09 BCWP(EV) ACWP(AC) .000.2-Oct.000.00 14212804Ago.Análisis Gráfico $30.00 $5.Oct.00 $10.000.Set09 09 09 09 BCWS(PV) 11Set09 1825.Ago.Nov.Sep.Nov.09 Oct.00 $25.Nov.000.Oct.

Earned Value .

Earned Value .

Earned Value .

BCWS CPI = BCWP / ACWP SPI = BCWP / BCWS CSI = CPI * SPI ETC = (BCWS BCWP) / CPI EAT = ACWP + ETC .Indicadores del Earned Value ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ ‡ BCWS = suma del costo de las tareas planeadas a hoy BCWP = BCWS * %Avance de cada tarea ACWP = suma de costos a la fecha CV = BCWP ACWP SV = BCWP .

Control de cambios en requerimientos ‡ Se debe hacer una estimación del esfuerzo necesario. tomando en cuenta las implicaciones en otras actividades ‡ Se debe estimar el costo que implica realizar el cambio y determinar quién lo asume ‡ Hay que cuidar el control del presupuesto de manera que no se pierda rentabilidad y sobretodo. poner el ojo en el flujo de caja .

manual de usuario. se procede a implantar el mismo ‡ Se entrega al cliente la documentación final del sistema. es decir.Fase de cierre ‡ Una vez terminado el desarrollo y pruebas del sistema de software. manual de instalación. manual técnico. así como un informe final del proyecto .

internamente se realiza una reunión llamada reunión post-mortem . se crea un plan de capacitación ‡ Se tramita el cierre formal del proyecto.Fase de cierre ‡ Como parte de esta fase. mediante una carta emitida por Babel y firmada por el cliente ‡ Terminado formalmente el proyecto.

.

Fase de cierre ‡ ENTREGABLES ± Manual de Usuario ± Manual Técnico ± Manual de Instalación ± Informe Final ± Disco con instaladores ± Carta de cierre .

Manuales del sistema ‡ Se generan los siguientes manuales: ± Manual de usuario: Explica la funcionalidad a nivel de usuario final del sistema ± Manual Técnico: Incluye toda la documentación técnica que se ha generado durante el proyecto ± Manual de Instalación: Describe los pasos necesarios para instalar la aplicación y cualquier componente adicional que se requiera .

Informe Final ‡ Es el informe que debe levantar el PM donde describe el resultado del proyecto en términos de: ± ± ± ± ± ± ± Calidad Satisfacción del Cliente Rentabilidad Tiempo Recurso Humano Aprendizaje / Riesgos Otros .

Disco con instaladores ‡ Como resultado de la gestión de configuración. se deben recuperar las últimas versiones de los documentos y del código fuente e incluirlo en el disco ‡ Preferiblemente se debe mantener una copia física de los discos para efectos de respaldo .

el patrocinador y cualquier otra autoridad por parte del cliente que se haya manifestado como un stakeholder de alta relevancia durante el proyecto .Carta de cierre ‡ Marca el final del proyecto ante el cliente ‡ Debe ser firmada por la contraparte técnica.

Reunión Post-Mortem Marca el final del proyecto a lo interno Se discute lo bueno y lo malo del proyecto Se alimentan los activos de procesos Se liman asperezas entre los miembros del equipo de trabajo ‡ Se retroalimenta a todas las personas ‡ Se pasa el proyecto a Soporte de Aplicaciones ‡ ‡ ‡ ‡ .

Soporte de Aplicaciones ‡ Brinda el servicio de soporte y garantía adquirido como responsabilidad en el proyecto ‡ Utiliza una metodología basada en eXtreme Programming para la atención de incidentes ‡ Esta oficina brinda el servicio de Mantenimiento de Aplicaciones una vez que la garantía termina .

o sistemas desarrollados por terceros ‡ El cliente cuenta con los fuentes de la aplicación ‡ Metodología mixta entre RUP y XP .Mantenimiento de Aplicaciones ‡ Brinda el servicio de mantenimiento a aplicaciones que se encuentran en producción ‡ Sistemas desarrollados por BABEL y cuya garantía expiró.

Modelos basados en madurez de procesos en orgnizaciones .

CMMi .

ISO .

OPM3 .

¡MUCHAS GRACIAS POR SU ATENCIÓN! .

Sign up to vote on this title
UsefulNot useful