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.
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. Programador
 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.
 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...
Además, 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
In g e n ie r ía
d e l s o ftw a re
D e s a r r o llo G e s t ió n d e M e tr ic a s M a n t e n im ie n to
d e S o ftw a re p ro y e c to s d e l s o ftw a re d e s o ftw a re
A n a lis is P la n ific a c ió n F ia b ilid a d C o r r e c c ió n d e E r r o r e s
D is e ñ o O r g a n iz a c ió n U s a b ilid a d M o d ific a c io n e s
C o d ific a c ió n R e c lu t a m ie n to F le x ib ilid a d
P ru e b a s D ir e c c ió n M a n t e n ib ilid a d
C o n tro l R e u s a b ilid a d
E tc .
 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,
también en informática .
 El modelado
• Simplificación del objeto en el mundo real,
pero que es suficientemente realista como
para dar una idea de lo que ocurrirá en la
realidad y usarse como base del desarrollo.
 División del Producto
• Se fracciona el producto de modo que cada
fragmento lo puede realizar un miembro del
grupo de desarrollo.
 División del Proceso
• Implica dividir el desarrollo del artefacto por
fases. Normalmente se habla de
especificación, diseño y fabricación.

¿Que? ¿Como? Realización Pruebas

 En el desarrollo de software nos
encontramos con esto:
Ciclos de Metodologías de
Vida del Desarrollo del
SOFTWARE SOFTWARE
Generalidades de los Proyectos
 ¿Qué es el PMI?
• Project Management Institute
– Organización mundial
– Sin fines de lucro
– Promover la práctica
estandarizada de Gerencia de
Proyectos
• www.pmi.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”.
 ¿Qué es un Proyecto?
• DEFINICIÓN 2
“Un proyecto es un esfuerzo temporal
que se lleva a cabo para crear un
producto , servicio o resultado único”.
 Características de un Proyecto
• El proyecto tiene un objetivo – bien definido:
el resultado o producto esperado.
• Por lo general se define a partir del alcance, el
programa y los costos.
• Prevé que se realice con calidad deseada y
con plena satisfacción del cliente.
 Características de un Proyecto
• El proyecto se lleva a cabo con una serie de
actividades interdependientes.
• Actividades no repetitivas que han de
cumplirse en determinada secuencia a fin de
alcanzar el objetivo del proyecto.
 Características de un Proyecto
• En un proyecto se hace uso de varios recursos:
– Personas
– Dinero
– Equipo
– Materiales
– Instalaciones
– Software
– Vehículos
 Características de un Proyecto
• Un proyecto tiene un marco temporal
específico, conocido también como vida útil
finita.
• 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.
 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, 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
• Los proyectos suponen un grado de
incertidumbre.
• Antes de iniciar el proyecto se prepara a partir
de una serie de suposiciones y estimaciones.
• Es importante anotarlas porque pueden influir
en alguna de las etapas del proyecto, como lo
es el presupuesto y la duración del trabajo.
 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.
 Características según el PMI
• “Alcance”
– Es el trabajo a realizar.
– Es la suma de productos, servicios y resultados
que se proporcionan como resultado de un
proyecto.
 Proyectos
• Para lograr sus objetivos las empresas realizan
trabajo que usualmente se compone de
operaciones permanentes y proyectos.
• Los proyectos son temporales y únicos.
• Las operaciones son continuas y repetitivas.
 Proyectos
• Son realizados por personas.
• Se llevan a cabo en todos los niveles de la
organización y pueden involucrar a una
persona o a miles.
• Restringidos por la limitación de los recursos.
• Planificados, ejecutados y controlados.
 ¿Qué es un Producto?
• DEFINICIÓN 1
Cualquier objeto que puede ser ofrecido a un
mercado que pueda satisfacer un deseo o una
necesidad.
 Diferencias entre
Proyecto y Producto
• Los proyectos son únicos.
• Los proyectos son temporales.

• 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
 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, transmisión
 Portafolios
• Conjunto de programas o subproyectos que se
gestionan conjuntamente.
• Gestión conjunta que tiene el fin de cumplir
objetivos estratégicos del negocio.
 ¿Qué es la Gestión de Proyectos?
• DEFINICIÓN 1
Es la aplicación de conocimientos, habilidades,
herramientas y técnicas a las actividades de
un proyecto para satisfacer los requisitos del
proyecto.
 ¿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, seguimiento y control, y cierre.
 La Dirección de un Proyecto
incluye
• Identificar los Requerimientos o Requisitos
• Establecer los objetivos claros y posibles de
realizar.
• Equilibrar las demandas concurrentes de
calidad, alcance, tiempo y costos.
• Adaptar las especificaciones, 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.
• La calidad de un proyecto se ve afectada por
el equilibrio de estos tres factores.
• Si un factor cambia es muy probable que
alguno de los otros también cambie.
 Áreas del Conocimiento
• Integración
• Alcance
• Tiempo
• Costo
• Calidad
• Recursos Humanos
• Comunicaciones
• Riesgos
• Aprovisionamiento (subcontrataciones)
 Proyectos de Alta Calidad
• Son aquellos que entregan el producto,
servicio o resultado requerido, con el alcance
solicitado, puntualmente y dentro del
presupuesto.
 Respuesta a la Incertidumbre
• Los Directores también gestionan los
proyectos en respuesta a la incertidumbre.
• El riesgo de un proyecto es un evento o
condición inciertos que, si ocurre, tiene un
efecto positivo o negativo al menos en uno de
los objetivos de dicho proyecto.
 En palabras sencillas…
• RIESGO
– Es el grado en que un determinado proyecto, o
parte de un proyecto, es susceptible de no ser
finalizado a tiempo y dentro de un presupuesto y,
sobre todo, la probabilidad de que el desenlace
deseado no se logre.
 Á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 multi-
disciplinario.
• Construcción de equipos de trabajo efectivos
en varios niveles organizacionales.
• Administrar el cambio a través de un liderazgo
efectivo y destrezas analíticas.
• Comprender el ambiente cultural para
manejar eventuales conflictos y problemas.
 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
 Destrezas Clave
• Negociación
– Alcances, 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
• Influir en la organización
– Hacer que las cosas pasen
– Sobre el comportamiento
 Responsabilidades del
Administrador de Proyectos
• Es ante sus clientes, la organización
ejecutante, los interesados y el público.
• El PMI posee un código de ética que deben
respetar todos sus miembros.
• Son los responsables de la planificación,
supervisión, administración, motivación,
formación, coordinación, comunicación,
reajustes y logros.
 Responsabilidades del
Administrador de Proyectos
• Su éxito está en función de su capacidad de
ofrecer las críticas con eficacia, saber como
organizar una reunión con un equipo de
trabajo, …
 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.
 Características comunes del Ciclo
de Vida del Proyecto
• Fases secuenciales con transferencias de
información técnica.
• La probabilidad de éxito es baja al inicio y alta
al final.
• Riesgo es alto al inicio y bajo al final.
Características comunes del Ciclo
de Vida del Proyecto
Características comunes del Ciclo
de Vida del Proyecto
 El ciclo de vida óptimo de un
Proyecto
• No existe una única manera, que sea la mejor,
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
 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, Cliente, Organización
Ejecutora, Patrocinadores, PMO
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, y en base a este
primer levantamiento, comenzaba la dura
tarea de codificar.
• Estos sistemas crecían, terminado el proyecto
cuando se cumplían todos los requerimientos
del sistema, los originales y los que aparecían
durante el 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, planificar y controlar
un proyecto de desarrollo, que permite
llevarlo a cabo con altas posibilidades de
éxito.
 ¿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. Lo hacen desarrollando un proceso
detallado con un fuerte énfasis en planificar
inspirado por otras disciplinas de la ingeniería.
 Aspectos de una Metodología
• Han estado presentes durante mucho tiempo.
• No se han distinguido precisamente por ser
muy exitosas. Aún menos por su popularidad.
• La crítica más frecuente es que son
burocráticas.
• Han demostrado ser efectivas y necesarias en
un gran número de proyectos, sobre todo
aquellos proyectos de gran tamaño.
 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, porque no están
pensadas para trabajar con incertidumbre.
 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.
• El coste de cambio de una decisión tomada
puede llegar a ser muy elevado.
• Hay una alta dependencia de los riesgos
detectados al inicio y de negociaciones
previas.
 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.
– Qué tareas se llevan a cabo en cada etapa.
– Heurísticas para llevar a cabo dichas tareas.
– Qué salidas se producen y cuándo se deben producir.
– Qué restricciones se aplican.
– Qué herramientas se van a utilizar.
– 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)
 Características
• Levantamiento exhaustivo de requerimientos.
• Detectar defectos en las fases iniciales.
• Reducir los cambios tanto como sea posible.
• Análisis y diseño, tan completo como sea
posible.
• Diseño genérico, intenta anticiparse a futuras
necesidades.
 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, nace el
término "ágil" aplicado al desarrollo de
software.
• Tras esta reunión se creó “The Agile Alliance”.
• El punto de partida fue el Manifiesto Ágil, un
documento que resume la filosofía "ágil".
 Esencia del Manifiesto Ágil
PREFERIMOS DESCONFIAMOS
A las personas y su Los procesos y las
comunicación herramientas

El software que funciona La documentación

exhaustiva
La colaboración con el La negociación contractual
cliente
La respuesta al cambio 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.
 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.
• El método es fácil de aprender y modificar
para el equipo.
• Permite cambios de último momento.
 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 ligeras vs.
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. estándares seguidos por el entorno
de desarrollo.
Especialmente preparados para Cierta resistencia a cambios.
cambios durante el proyecto.
Impuestas internamente por el Impuestas externamente.
equipo de desarrollo.
Proceso menos controlado, con pocos Procesos mucho más controlados,
principios. con muchas políticas/normas.
No existe contrato tradicional o al Existe un contrato prefijado.
menos es bastante flexible.
 Metodologías ligeras vs.
Metodologías tradicionales
Metodologías Ágiles
El cliente es parte del equipo de
desarrollo.
Grupos pequeños (no más de 10)
trabajando en el mismo sitio.
Pocos artefactos.
Pocos roles.
Menos énfasis en la arquitectura de
software.
Metodologías Tradicionales
El cliente interactúa con el equipo de
desarrollo mediante reuniones.
Grupos grandes y posiblemente
distribuidos.
Más artefactos.
Más roles.
La arquitectura del software es
esencial y se expresa mediante
modelos.
“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
 Company’s profile
• 100% Costa Rican investment.
• Customized software development and
complementary services.
• 8 years of experience in more than 10
countries.
• More than 200 projects successed.
• At least 2 of our clients are usually in the top
10 of Fortune Magazine’s ranking.
 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.I. (Cenfotec)
– Universidad Nacional de Costa Rica (UNA)
– Escuela Politécnica del Ejército Ecuatoriano (ESPE)
 Business Areas
• Customized Software Development
• Business Intelligence
• Applications Support and Maintenance
• Outsourcing (consulting time)
• I.T. Infrastructure Support
 Technologies
• Microsoft .Net
• PHP
• Java
• Oracle
• AS/400
• Other technologies…
Clients (International Corporations)
Clients (Local Companies and Institutions)
Clients (Software and I.T. 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
 Estrategia de la Empresa
• Misión
– Brindamos al mundo las soluciones informáticas a
la medida de la más alta calidad, 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, 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
 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, James Rumbaugh, e Ivar Jacobson
trabajaban por separado
– En 1994 Rational contrató a Rumbaugh en donde
ya trabajaba Booch, un año después Jacobson se
unía a ellos en Rational.
– En 1997 salió a la luz la versión 1.0 de UML.
 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, El Objetivo en esta etapa es determinar la visión del
proyecto.
• Elaboración, En esta etapa el objetivo es determinar la
arquitectura óptima.
• Construcción, En esta etapa el objetivo es llevar a obtener la
capacidad operacional inicial.
• Transmisión, El objetivo es llegar a obtener el release 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.
– Se encuentra integrada por más de 260.000
miembros alrededor de 171 países.
– La oficina central está en Filadelfia en
Pennsylvania, Estados Unidos
 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
 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,
entre otras cosas.
– Es la mayor asociación internacional sin fines de
lucro formada por profesionales de las nuevas
tecnologías, como ingenieros electricistas, en
electrónica, en computación, en informática, en
biomédica y en telecomunicación.
 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
 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, 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.
 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
 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, en la cual nuestros business analysts
le dan forma al proyecto y lo cotizan (en
tiempo y dinero).
 Fase de Inicio / Conceptualización
• Una vez que el cliente haya aceptado la
cotización, también llamada propuesta de
negocio, se firma un contrato e inicia el
proyecto
• Cuando inicia el proyecto, se tiene que
conceptualizar y hay que refinar el alcance del
proyecto
 Fase de Inicio / Conceptualización
• Cabe destacar que la especificación está
basada en el estándar IEEE 830, que estipula
el formato de un documento de este tipo
• Una vez, creada la ERS, é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 más, nada
menos).
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
 Estimación de Esfuerzo
Casos de Uso
Req. 1 5
Req. 2 10
Req. 3 7
Req. 4 8
TOTAL 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
 Cronograma
• Diagrama de Gantt con las actividades
interrelacionadas que componen el proyecto.
• Marcan el compromiso inicial adquirido con el
cliente en cuanto a la distribución del esfuerzo
y la entrega de productos.
 Estimación de Costos y Gastos
• Incluye
– Salarios por perfil
– Cargas sociales
• Seguro social (12.15%)
• Aguinaldo (13vo salario = 8.33%)
• 14vo salario ($20 x mes)
• Vacaciones (4.16%)
• Fondo de reserva (8.33%)
– Viáticos y otros gastos
– Gastos Administrativos
– Utilidad Neta de la empresa
 Proyección del Flujo de caja
• Preferiblemente semanal o diario
• Incluye todo el movimiento de recursos
económicos, tanto en entradas como en
salidas del proyecto
• Debe contemplar los momentos de inversión
 Análisis preliminar de riesgos
• Consiste en la aplicación de los conocimientos
existentes en los activos de procesos, que se
pueden identificar como posibles riesgos en el
nuevo proyecto.
• Pretende que los riesgos sean tomados en
cuenta desde antes de iniciar el proyecto y de
ser posible que se consideren en el contrato.
 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
Levantamiento de Requerimientos
• Se deben efectuar todas las reuniones
posibles y necesarias con los usuarios finales y
la contraparte técnica.
• Es ideal tener activos de procesos que faciliten
la toma de requerimientos.
• Se puede presentar el rechazo al cambio por
parte de varios usuarios.
 Especificación de Requerimientos
de Software (ERS)
• Consiste en la declaración del alcance,
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)
• 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
 Fase de planeación
• Una vez que se conoce el alcance del
proyecto, se crea un Cronograma de Trabajo,
el cual da a conocer a todos los involucrados
fechas importantes del proyecto, así como,
formalmente, el trabajo a realizar
• Además se tiene que pensar en los riesgos
asociados con el proyecto, es decir, crear un
Plan de Riesgos
 Fase de planeación
• El Plan de Riesgos se basa en el
estándar IEEE 1540
• Además, se planea la integración de lo que
está por desarrollarse, es decir, cómo se
conjuntarán las piezas de software y su orden
para crear el producto del proyecto, por
medio de un Plan de Integración
 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
 Cronograma de Trabajo
• Se implementa sobre Microsoft Project
• Conjunto de actividades interrelacionadas que
por tanto dependerán unas de otras
• Conjunto de recursos (humano, material y
dinero)
• En esta herramienta se registra el avance
diariamente y de ahí se obtienen los
indicadores de avance general
 Plan de Riesgos
• La gestión de riesgos del proyecto es el proceso de
identificar, analizar y responder a los riesgos del
proyecto
– Estimando y planeando las actividades análisis, 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
 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, 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
Gestión de Riesgos
Del Proyecto

Análisis Cualitativo de Análisis Cuantitativo de Monitoreo y control del

Planeación de Riesgos
Riesgos Riesgos Riesgo

Planeación de la
Identificación de Riesgos
Respuesta al Riesgo
 Plan de Riesgos

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

CUANTIFICACIÓN DE RIESGOS
Probabilidad
Alta Media Baja
Severidad
Catastrófico Alto Alto Medio

Crítico Alto Medio Bajo

Marginal Medio Bajo Bajo

 Plan de Riesgos
CLASIFICACIÓN DEL IMPACTO
Detiene la implementación del proyecto, o tiene alta
posibilidad de impactar severamente uno o más de los
Catastrófico
siguientes factores: costos cronograma y/o producto del
proyecto.
Retrasa la implementación del proyecto y afecta
directamente la fecha de entrega del proyecto, o tiene
Crítico alta posibilidad de impactar moderadamente uno o más
de los siguientes factores: costos cronograma y/o
producto del proyecto.
Retrasa el cronograma interno del proyecto pero no
afecta su fecha de entrega, o tiene posibilidad de
Marginal
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 pruebas de
cada ciclo, 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
 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, si no,
existe un error de utilización de la
metodología
 Fase de ejecución
• Inicia con la creación del ambiente de trabajo
por parte del Soportista Técnico.
• 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
• 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
 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, en caso de que se
hayan modificado los casos de uso durante el
desarrollo
 ¿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, se tiene
que ir llevando un control detallado del
avance, para así llevar al día el proyecto y
estar pendiente de los riesgos
• El administrador asignado al proyecto, debe
de crear informes de avances, los cuales están
compuestos por métricas que describen el
avance y comportamiento del proyecto
 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
 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 cuál
fue el plan de mitigación tomado y su impacto
• Si un riesgo está activo, se debe indicar las
acciones de reducción que se están tomando
y su impacto
 Informes de ciclos
• El PM entrega este informe a QA cada vez que
finaliza un ciclo de desarrollo.
• 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
 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
 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, por caso de uso
• El rendimiento también toma en cuenta el
tiempo inicial estimado para la tarea
 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
 Hechos de la industria
• 85% de los proyectos falla, 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
• Al incorporar las mejores prácticas en Administración de
Proyectos las empresas han logrado una mejora del:
– 37.6% en la satisfacción del cliente
– 37% en el alineamiento estratégico
– 22.8% en la productividad del equipo
– 38.6% en la estimación del cronograma
– 32.8% en la estimación del costo/hora
– 32.5% en presupuesto y cronograma al día
– 7.6% en la estimación de la calidad
 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
 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 ($), cuanto me falta para completar - proyectado
– EAC: Estimated At Completion ($) cuanto va a costar al terminar - proyectado
 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)
Análisis Gráfico
Earned Value
Earned Value
Earned Value
 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 - BCWS
• CPI = BCWP / ACWP
• SPI = BCWP / BCWS
• CSI = CPI * SPI
• ETC = (BCWS – BCWP) / CPI
• EAT = ACWP + ETC
 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
 Fase de cierre
• Una vez terminado el desarrollo y pruebas del
sistema de software, se procede a implantar el
mismo
• Se entrega al cliente la documentación final
del sistema, es decir, manual de usuario,
manual técnico, manual de instalación, así
como un informe final del proyecto
 Fase de cierre
• Como parte de esta fase, se crea un plan de
capacitación
• Se tramita el cierre formal del proyecto,
mediante una carta emitida por Babel y
firmada por el cliente
• Terminado formalmente el proyecto,
internamente se realiza una reunión llamada
reunión post-mortem
 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
 Carta de cierre
• Marca el final del proyecto ante el cliente
• Debe ser firmada por la contraparte técnica, el
patrocinador y cualquier otra autoridad por
parte del cliente que se haya manifestado
como un stakeholder de alta relevancia
durante el proyecto
 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
 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ó, o sistemas desarrollados por
terceros
• El cliente cuenta con los fuentes de la
aplicación
• Metodología mixta entre RUP y XP
Modelos basados en madurez de
procesos en orgnizaciones
CMMi
ISO
OPM3
¡MUCHAS GRACIAS POR SU
ATENCIÓN!