METODOLOGÍA DE

DESARROLLO

Top Group
Technology & Solutions

LAS CLAVES DEL DESARROLLO DE SOFTWARE
El desarrollo de software es un proceso de negocios estratégico que
integra y automatiza otros procesos de negocio siendo, en la
actualidad, una fuente de ventajas competitivas para las
compañías.
Siendo una actividad de equipo, involucra la participación de los
"stakeholders" del negocio, las organizaciones de IT y las áreas
operativas trabajando en pos de un objetivo común. Pero las
estadísticas indican que más del 60% de los proyectos de
desarrollo fallan (fuente: Standish Group - 2003 Chaos Chronicles,
2003) producto de ineficiencias que causan retrasos, frustración y
en definitiva la pérdida de flexibilidad del negocio.
Para poder responder a las exigencias particulares de este modelo
de servicios, las principales consultoras coinciden en que la
adopción de metodologías de desarrollo y "project management"
comprobadas es clave para garantizar el éxito de los proyectos.
EL PROCESO DE DESARROLLO ENFOCADO AL NEGOCIO
La plataforma metodológica que aplicamos en TopGroup apunta a
ofrecer una experiencia común que va del diseño a la implementación
y que involucra a los diferentes "stakeholders":
La línea de negocios de la compañía que conduce las estrategias
del negocio
El equipo de desarrollo que hace factibles dichas estrategias
El equipo de IT operativo requerido para las operaciones del día a día
Pag.1
En TopGroup trabajamos bajo los estándares definidos por una
plataforma metodológica que toma como base las definiciones y
herramientas para administración de proyectos del Project
Management Institute (USA), las mejores prácticas para el
desarrollo de software definidas por Rational Unified Process,
soportadas por una solución tecnológica que aplica los conceptos
de Professional Service Automation.
plataforma metodológica
Project Management Ingeniería de Software
PMI RUP
Proyectos
de desarrollo
Web Portal
Professional Service Automation
Esta "plataforma" metodológica, que combina un conjunto de
herramientas y mejores prácticas comprobadas dan soporte a la
creación, integración, extensión, modernización e implementación
de software en aplicaciones nuevas y existentes, sistemas legacy y
productos de software. Ofrece un enfoque rápido, flexible e
incremental que captura y automatiza procesos de negocio
existentes y nuevos modelos de negocio.
 Pag.2

Modernización
aplicaciones
existentes
ión

int
c
ra

eg
eg

ra
int

ció
Implementación

n
Creación Extensión
aplicaciones sistemas El proceso de desarrollo orientado al negocio se basa en un modelo
nuevas integración legacy iterativo que incluye los siguientes pasos:

Modelar el Proceso
de Negocio

Monitorear Analizar
Requerimientos

Testear e
implementar Analizar y Diseñar

MODELAR EL PROCESO DE NEGOCIOS

Uno de los principales problemas en el desarrollo de software

reside en los problemas de comunicación entre la comunidad de
ingeniería de software y la comunidad de ingeniería de negocios.
Esto genera que la salida de las áreas de negocio no sean
interpretadas correctamente por las áreas de desarrollo de software
y vice-versa. RUP resuelve estas diferencias proponiendo un
lenguaje y un proceso común para ambas comunidades, así como
herramientas que permiten crear y mantener la equivalencia entre
modelos de negocio y modelos de software.

En el modelado de negocios documentamos los procesos de

negocio utilizando los llamados casos de negocio (business use
cases). Esto asegura el entendimiento común entre todos los
"stakeholders" sobre qué procesos de negocio necesitan ser
soportados en la organización. Los casos de negocio son analizados
para comprender cómo el software debería soportar los procesos de
negocio. Esto es documentado en un modelo de objetos de
negocio. Es posible que algunos proyectos decidan no encarar el
modelado de negocios.

ANALIZAR REQUERIMIENTOS
El objetivo de esta actividad es describir qué debería hacer el
sistema y permitir que los desarrolladores y el cliente se pongan de
acuerdo en esa descripción. Para lograrlo obtenemos, organizamos
y documentamos la funcionalidad requerida y sus restricciones, se
rastrean y se documentan decisiones.
Se crea el documento con la Visión y se obtienen las necesidades
de los "stakeholders". Se identifican a los Actores, representando a
los usuarios y cualquier otro sistema que pueda interactuar con el
sistema que está siendo desarrollado. Se identifican los casos de
uso a través del lenguaje de modelado UML, representando el
comportamiento del sistema. Dado que los casos de uso son
desarrollados en base a las necesidades de los actores , el sistema
tenderá a ser más relevante para los usuarios. Cada caso de uso se
describe en detalle y esta descripción muestra cómo interactúa el
sistema, paso a paso, con los actores y qué hace el sistema. Los
requerimientos no funcionales se describen en las Especificaciones
Adicionales.
ANALIZAR Y DISEÑAR
El objetivo del Análisis y Diseño es mostrar cómo se realizará el
sistema en la etapa de implementación. Se desea construir un
sistema que :
Ejecute - en un entorno de implementación específico - las tareas
y funciones definidas en las descripciones de los casos de uso
Complete todos los requerimientos
Sea estructurado de manera robusta (fácil de modificar si los
requerimientos funcionales cambian)
Esta etapa genera un modelo de diseño y opcionalmente un modelo
de análisis. El modelo de diseño sirve de abstracción del código
fuente, es decir, actúa como un "plano" de cómo se estructura y
escribe el código fuente.
El modelo de diseño consiste en clases estructuradas en paquetes
y subsistemas diseñados con interfaces bien definidas,
representando lo que serán componentes en la implementación.
Las actividades de diseño se centran en la noción de arquitectura.
La producción y validación de esta arquitectura es el foco principal
de las iteraciones iniciales.
Pag.3
IMPLEMENTAR
El propósito de la implementación es:
Definir la organización del código, en términos de subsistemas
organizados en capas
Implementar clases y objetos en términos de componentes
(archivos fuente, binarios, ejecutables y otros)
Probar los componentes desarrollados como unidades
Integrar los resultados producidos por los desarrolladores
individuales en un sistema ejecutable
El sistema se desarrolla a través de la implementación de
componentes. RUP describe cómo reutilizar los componentes
existentes o implementar nuevos componentes con responsabilidades
bien definidas, alcanzando un sistema fácil de mantener e
incrementando las posibilidades de reutilización.
TESTEAR
El propósito del testing es:
Verificar la interacción entre los objetos
Verificar la apropiada integración de todos los componentes del
software
Verificar que todos los requerimientos han sido correctamente
implementados
Identificar y asegurar que los defectos sean revisados antes de la
implementación del software
RUP propone un enfoque iterativo, lo que implica que se testea a
lo largo de todo el proyecto. Esto permite encontrar defectos lo
antes posible, lo cual reduce radicalmente el costo de corregir
defectos. Las pruebas se realizan a lo largo de tres dimensiones de
calidad: confiabilidad, funcionalidad, performance de la aplicación
y del sistema. Para cada una de estas dimensiones el proceso
describe el ciclo de vida del testing a través de la planificación,
diseño, implementación, ejecución y evaluación.

INSTALAR
El propósito del proceso de despliegue es producir versiones de
producto exitosas y entregar el software a sus usuarios finales.
Incluye las siguientes actividades:
Producir versiones externas del software
Empaquetar el software
Distribuir el software
Instalar el software
Ofrecer ayuda y asistencia a los usuarios
En muchos casos también incluye actividades como:
Planificación y conducción de beta tests
Migración de software o datos existentes
Aceptación formal
MEJORES PRÁCTICAS PARA EL DESARROLLO DE SOFTWARE
En TopGroup trabajamos bajo los procesos de ingeniería de software
definidos por RUP - Rational Unified Process - a fin de asegurar, a
través de sus mejores prácticas, software de alta calidad ajustados
en tiempo y presupuesto. RUP, que incluye una serie de
herramientas y la definición de mejores prácticas para el desarrollo
de software, fue adquirida por IBM y avalada como un estándar en
el ámbito internacional.
RUP es un Proceso de Ingeniería de Software que ofrece una
metodología disciplinada para la asignación de tareas y
responsabilidades en una organización de desarrollo de software.
Su objetivo es asegurar la producción de software de alta calidad
que logre responder a las necesidades de sus usuarios finales en un
cronograma y presupuesto predecibles.
RUP describe la manera de implementar efectivamente "mejores
prácticas" comercialmente probadas para el desarrollo de software.
RUP ofrece a cada miembro del equipo las guías, plantillas y
herramientas necesarias para aprovechar al máximo las siguientes
mejores prácticas:
1. Desarrolle software iterativamente
2. Administre requerimientos
3. Utilice arquitecturas basadas en componentes
4. Modele el software visualmente
5. Verifique la calidad del software
6. Controle los cambios al software
Pag.4
Si bien las actividades de instalación se centran fundamentalmente
en la fase de Transición (ver Fases e Iteraciones), muchas de sus
actividades necesitan ser incluídas en fases precedentes para
preparar el despliegue al final de la fase de Construcción (ver Fases
e Iteraciones).
MONITOREAR
Las organizaciones exitosas no sólo automatizan sus procesos de
negocio, sino que también controlan su ejecución y la ajustan
dinámicamente en respuesta a los resultados en tiempo real.
DESARROLLE SOFTWARE ITERATIVAMENTE
Dada la complejidad de los sistemas de software actuales, no es
posible trabajar de manera secuencial, primero definiendo el
problema completo, diseñando la solución completa, luego
construyendo el software y por último testeando el producto, al
final del proceso. Se requiere un enfoque iterativo que permita un
entendimiento creciente del problema a través de refinamientos
sucesivos haciendo crecer en forma incremental una solución
efectiva a través de múltiples iteraciones.
RUP sugiere el desarrollo iterativo que aborda los riesgos más altos
en cada paso del ciclo de vida, reduciendo en forma significativa
los riesgos del proyecto. Este enfoque iterativo permite atacar
riesgos a través del progreso frecuente y demostrable, versiones
ejecutables que permiten el involucramiento continuo de los
usuarios finales. Dado que cada iteración finaliza con una versión
ejecutable, el equipo de desarrollo se mantiene enfocado en
producir resultados y los controles de estado frecuentes ayudan a
asegurar que el proyecto se mantenga en cronograma.
 Pag.5

ADMINISTRE REQUERIMIENTOS

RUP describe como obtener, organizar y documentar la

funcionalidad requerida y sus restricciones; rastrear y documentar
especificaciones y decisiones, capturar y comunicar fácilmente
requerimientos de negocio. La noción de casos de uso y escenarios
involucrados en el proceso han demostrado ser una forma excelente
de capturar requerimientos funcionales y asegurar que dirijan el
diseño, implementación y testing del software, haciéndolo más
probable de que cubra las necesidades de los usuarios finales.

UTILICE ARQUITECTURAS BASADAS EN COMPONENTES

El proceso de enfoca en el desarrollo temprano de una arquitectura

ejecutable robusta, antes de comprometer recursos para un
desarrollo a gran escala. Describe cómo diseñar una arquitectura
elástica que sea flexible, se pueda adaptar a los cambios, sea
comprensible y promueva la reutilización del software.
soporta el desarrollo de software basado en componentes, módulos
o subsistemas que cumplen una función clara.
MODELE EL SOFTWARE VISUALMENTE
VERIFIQUE LA CALIDAD DEL SOFTWARE
RUP La calidad del software debe ser verificada en forma continua con
respecto a su confiabilidad, funcionalidad y performance (de la
aplicación y del sistema). RUP provee asistencia en la
planificación, diseño, implementación, ejecución y evaluación de
este tipo de tests. La evaluación de la calidad se construye dentro
del proceso, en todas las actividades, involucrando a todos los
participantes, utilizando medidas y criterios objetivos y no tratada
como una actividad separada ejecutada por un grupo aislado.

El proceso muestra cómo modelar software visualmente para

capturar la estructura y el comportamiento de arquitecturas y
componentes. Permite, así, esconder los detalles y escribir código
utilizando "bloques de construcción gráficos". Las abstracciones
visuales permiten comunicar diferentes aspectos del software, ver
cómo los diferentes elementos del sistema cuadran juntos,
asegurar que los bloques sean consistentes con el código,
mantener consistencia entre un diseño y su implementación y
promover la comunicación inequívoca. La base para el modelado
visual es el Unified Modeling Language (UML), creado por Rational
software y que se ha convertido en un estándar del mercado.
CONTROLE LOS CAMBIOS DEL SOFTWARE
La posibilidad de administrar el cambio remarca que cada cambio
es aceptable y tener la posibilidad de hacer el seguimiento de los
cambios es esencial en un entorno en el cual el cambio es
inevitable. El proceso describe cómo controlar, seguir y monitorear
cambios para permitir el desarrollo iterativo. También define cómo
establecer espacios de trabajo seguros para cada desarrollador
ofreciendo aislamiento de cambios hechos en otros entornos de
trabajo controlando cambios de todos los "artefactos" y entregables
(ej., modelos. Código, documentos, etc.)
 Pag.6

EL PROCESO DE DESARROLLO DE SOFTWARE

DOS DIMENSIONES

El proceso puede ser descripto en dos dimensiones:

El eje horizontal representa el tiempo y muestra los aspectos

dinámicos del proceso siendo expresados en términos de ciclos,
fases, iteraciones e hitos
El eje vertical representa los aspectos estáticos del proceso, cómo
se describe en términos de actividades, artefactos, empleados y
flujos de trabajo

Fases
Conceptua Elaboración Construcción Transición
lización
Disciplinas de Proceso
Modelamiento del Negocio

Requerimientos

Análisis y Diseño

Implementación
Test

Instalación

Disciplinas de Soporte
Adm. Configuración y Cambios
Administración del Proyecto
Ambiente modelo iterativo
Iteraciones Iter. Iter. Iter. Iter. Iter. Iter. Iter.
Preliminares #1 #2 #n #n+1 #n+2 #m #m+1
Iteraciones

FASES E ITERACIONES - CICLO DE VIDA DEL SOFTWARE

El ciclo de vida del software se divide en ciclos, cada ciclo trabaja

en una nueva generación de producto. RUP divide un ciclo de
desarrollo en cuatro fases consecutivas
 Pag.7

1. Concepción 2. Elaboración
Identificar los requerimientos Diseñar la arquitectura del sistema
Identificar necesidades del cliente Definir los requerimientos
Identificar casos de uso críticos en los casos de uso
Planificar la comunicación
Documentar los casos de uso
RUP
4. Transición
3. Construcción
Migración al entorno de producción
Desarrollo de componentes del sistema
Capacitación a los usuarios basado en la arquitectura definida
Creación de los manuales y los casos de uso
Tareas de configuración necesaria Testing correspondiente

Cada fase concluye con un hito claramente definido, un punto en el

tiempo en el cual se debe tomar cierta decisión crítica y, por ende,
se debió haber alcanzado un objetivo clave.

FASE CONCEPCIÓN

Durante esta fase se establece el caso de negocios del sistema y se
delimita el alcance del proyecto. Para ello se identifican todas las
entidades externas con las cuales interactúa el sistema (actores) y
se define la naturaleza de esta interacción a alto nivel. Esto
involucra la identificación de todos los casos de uso y la
descripción de los más significativos. El caso de negocios incluye
el criterio de aceptación, la evaluación de riesgos, una estimación
de los recursos necesarios y un plan de fases mostrando fechas de
los principales hitos del proyecto.
Plan de proyecto, mostrando fases e iteraciones
Modelo de negocios, de ser necesario
Uno o más prototipos
Hitos:
Al final de la fase Concepción se llega al primer hito: Los Objetivos
del Proyecto definidos.
El criterio de evaluación para la fase Concepción incluye:

Como resultado de esta fase se obtiene:
Documento de Visión: visión general de los requerimientos
principales del proyecto, características clave y principales
restricciones.
Modelo de casos de uso inicial: (completo al 10% - 20%)
Glosario inicial del proyecto
Caso de negocios inicial, que incluye el contexto de negocios,
criterio de aceptación (pronóstico de ganancias, reconocimiento
del mercado, entre otros) y pronóstico de ventas
Evaluación de riesgos inicial
El acuerdo de los diferentes "stakeholders" en la definición de
alcance y las estimaciones de costo/cronogramas
Entendimiento de los requerimientos como evidencia de la
fidelidad de los casos de uso primarios
Credibilidad de las estimaciones de costos/cronogramas,
prioridades, riesgos y proceso de desarrollo
El alcance de todo tipo de prototipo de arquitectura que se haya
desarrollado
Gastos actuales vs. Gastos planificados

FASE ELABORACIÓN
El propósito de esta fase es analizar el ámbito del problema,
establecer la base de la arquitectura, desarrollar el plan de
proyecto y eliminar los elementos de mayor riesgo del proyecto.
Para lograr estos objetivos se debe tener una visión completa del
sistema. Las decisiones de arquitectura deben ser tomadas con un
entendimiento completo del sistema: su alcance, funcionalidades
principales y requerimientos no funcionales como ser
requerimientos de performance.
Al finalizar esta fase en forma exitosa, se asegura que la
arquitectura, requerimientos y planes son lo suficientemente
estables y que los riesgos han sido mitigados a fin de que sea
posible predecir el costo y cronograma del desarrollo completo.
Durante esta fase se construye un prototipo de la arquitectura
ejecutable en una o más iteraciones dependiendo del alcance,
tamaño, riesgo y lo novedoso del proyecto. Este esfuerzo debería
dar respuesta a los casos de uso crítico planteando en la fase
Concepción que exponen los mayores riesgos técnicos del proyecto.
Como resultado de esta fase se obtiene:
Modelo de casos de uso: (completo al 80%) - se han identificado
todos los casos de uso y actores y se han desarrollado la mayoría
de las descripciones de los casos de uso
Requerimientos adicionales asociados a especificaciones no
funcionales
Descripción de la arquitectura de software
Un prototipo de la arquitectura ejecutable
La lista de riesgos revisada y el caso de negocios revisado
El plan de desarrollo para el proyecto completo, incluyendo el
project plan que las iteraciones y criterios de evaluación para
cada una de ellas
Un caso de desarrollo actualizado especificando los procesos a
ser usados
Un manual del usuario preliminar (opcional)
Hitos:
Al final de la fase Elaboración se llega al segundo hito: La
Arquitectura del Proyecto definida. En este punto se examina los
objetivos y el alcance detallado del proyecto, la elección de
arquitectura y la solución a los principales riesgos.
El criterio de evaluación para la fase Elaboración incluye la
respuesta a estas preguntas:
Pag.8
¿Es estable la visión del producto?
¿Es estable la arquitectura?
¿El prototipo ejecutable llega a demostrar que los elementos de
mayor riesgo han sido considerados y efectivamente resueltos?
¿El plan para la fase Construcción es lo suficientemente detallado
y preciso? ¿Se sustenta en bases de estimación creíbles?
¿Existe acuerdo entre todos los "stakeholders" de que la visión
definida puede ser alcanzada si se ejecuta el plan delineado en el
contexto de la arquitectura actual?
¿Son aceptables los gastos en recursos reales versus los gastos
planificados?
El proyecto puede ser cancelado o re planteado en forma
considerable si no logra pasar este hito.
FASE CONSTRUCCIÓN
Durante esta fase se construyen todos los componentes y
funcionalidades de la aplicación restantes y son integrados al
producto. Asimismo toda la funcionalidad es probada. La fase
construcción es, fundamentalmente, un proceso de manufactura
donde el énfasis está puesto en administrar recursos y controlar las
operaciones para optimizar costos, cronogramas y calidad. Se vive
una transición conceptual que va del desarrollo de propiedad
intelectual durante las dos primeras fases, al desarrollo de
productos implementables durante las dos últimas fases.
Como resultado de esta fase se obtiene un producto listo para
poner en manos de los usuarios finales. Como mínimo consiste de:
El producto de software integrado a las plataformas adecuadas
Los manuales de usuario
La descripción de la versión actual
Hitos:
Al final de la fase Construcción se llega al tercer hito: El Producto
con Capacidad Operativa. En este punto se decide si el software,
los sitios y los usuarios están listos para estar operativo sin exponer
al proyecto a un alto riesgo. Esta versión se denomina
habitualmente "beta".

El criterio de evaluación para la fase Elaboración incluye la
respuesta a estas preguntas:
¿Es estable esta versión del software y está lo suficientemente
madura para ser implementada en la comunidad de usuarios?
¿Están listos los "stakeholders" para la transición en la comunidad
de usuarios?
¿Siguen siendo aceptables los gastos en recursos reales versus los
planificados?
La transición puede llegar a ser pospuesta a la siguiente versión si
el proyecto no logra alcanzar este hito.
FASE TRANSICIÓN
El propósito de esta fase es lograr la transición del producto de
software a la comunidad de usuarios. Una vez que el producto ha
sido entregado al usuario final, surgen temas que requieren del
desarrollo de nuevas versiones, corregir algunos problemas, o
finalizar las funcionalidades que fueron pospuestas.
Se ingresa a esta fase cuando el producto está lo suficientemente
maduro para ser implementado en el entorno del usuario final.
Típicamente requiere que un subconjunto utilizable del sistema
haya sido completo a un nivel de calidad aceptable y que la
documentación de usuario esté disponible a fin de que la
transición al usuario final de resultados positivos.
Esto incluye:
"beta testing" para validar el nuevo sistema versus las
expectativas de los usuarios
Operación en paralelo con el sistema anterior que está
reemplazando
Conversión de las bases de datos operativas
Entrenamiento de usuarios y personal de mantenimiento
Derivar el producto a los equipos de marketing, distribución y
ventas
La fase de transición se focaliza en las actividades requeridas para
poner el software en manos de los usuarios finales. Típicamente,
esta fase requiere de múltiples iteraciones, versiones beta,
versiones de disponibilidad general y versiones con corrección de
bugs y mejoras funcionales. Se ocupa gran parte del tiempo en
desarrollar la documentación orientada al usuario, educadores y
usuarios de soporte en el uso inicial del producto y en reaccionar a
sus comentarios y sugerencias. En este punto del ciclo de vida, la
respuesta del usuario debería estar confinada a los ajustes del
producto, configuración, instalación y temas de usabilidad.
Pag.9
Los objetivos primarios de esta fase incluyen:
Lograr el "auto-soporte" por parte del usuario
Alcanzar el acuerdo con los "stakeholders" de que la
implementación está completa y es consistente con el criterio de
evaluación de la visión
Lograr un producto final tan rápido y efectivo en costo como sea
posible.
Esta fase puede llegar a ser muy simple o muy compleja,
dependiendo del tipo de producto.
Hitos:
Al final de la fase Transición se alcanza el cuarto hito: La Versión
de Producto. En este punto se decide si se alcanzaron los objetivos
y si resulta necesario comenzar otro ciclo de desarrollo. En algunos
casos este hito puede coincidir con el final de la fase Concepción
del próximo ciclo.
El criterio de evaluación para la fase Transición incluye la
respuesta a estas preguntas:
¿Está satisfecho el usuario?
¿Sigue siendo aceptable los gastos en recursos reales versus los
planificados?
ITERACIONES
Cada fase puede ser dividida, a su vez, en iteraciones. Cada
iteración es un ciclo completo de desarrollo que da como resultado
una versión (interna o externa) de un producto ejecutable, un
subconjunto del producto final bajo desarrollo, que crece
incrementalmente de iteración a iteración para convertirse en el
sistema final.
Beneficios del enfoque iterativo:
Comparado con el proceso en cascada, el proceso iterativo tiene las
siguientes ventajas:
Se mitigan los riesgos más temprano
El cambio es más administrable
Alto nivel de reutilización
El equipo del proyecto puede aprender a lo largo del mismo
Mejor calidad general
 Pag.10

METODOLOGÍA DE ADMINISTRACIÓN DE PROYECTOS

En TopGroup adoptamos las especificaciones definidas por el

Project Management Institute -USA-, una organización posicionada
como líder global en el desarrollo de standards para la práctica de
la administración de proyectos. "A Guide to the Project
Management Body of Knowledge (PMBOK ® Guide)" ha sido
reconocido en todo el mundo como un estándar para la
administración de proyectos. The PMBOK ® Guide ha sido
aprobado como American National Standard (ANS) por el American
National Standard Institute (ANSI).

Nuestros profesionales han sido capacitados en los standards del

PMI a través de cursos de postgrado dictados en nuestro país.

¿QUÉ ES LA DIRECCIÓN DE PROYECTOS?

Consiste en la aplicación del conocimiento, capacidades, EL ROL DEL PROJECT MANAGER

herramientas y técnicas a las actividades de un proyecto, con el UNA POSICIÓN CLAVE PARA EL ÉXITO DEL PROYECTO
objetivo de satisfacer o exceder las necesidades y expectativas de
los interesados.
La base metodológica del PMI apunta a formar Project Managers
La dirección de proyectos se ocupa de lograr que los trabajos se capaces de analizar y sopesar el entorno, identificando
hagan: participantes, bases de poder y objetivos, y analizar sus propias
capacidades, relaciones personales, valores personales y
Dentro de los plazos habilidades para las comunicaciones, con el objetivo fundamental
Dentro del presupuesto de lograr que el trabajo se realice, en el plazo establecido, dentro
Y de acuerdo a las especificaciones del presupuesto y de acuerdo a las especificaciones, desarrollando
los equipos que mejor servirán a la organización, siendo el vínculo
entre los niveles más altos de la Dirección y el equipo de proyecto y
transmitiendo las lecciones aprendidas.
elementos fundamentales
¿Cuáles son las características de nuestro Equipo de Project
Managers?
Tiempo Recursos
Son capaces de entender a la gente

Calidad Detallistas
Se comprometen fuertemente con los proyectos
Alcance Customer Son capaces de convivir con la ambigüedad, retrocesos y
Satisfaction desilusiones
Reconocen los objetivos de la organización
Actúan orientados a los resultados
Son concientes de los costos
Políticamente inteligentes -saben cómo influir en otros
Poseen buenas habilidades de negociación
Son competentes
 Pag.11

PROCESOS EN LA DIRECCIÓN DE PROYECTOS

La dirección de proyectos tiene una marcada naturaleza

integradora, según la cual las acciones o errores cometidos en un
área afectan indefectiblemente a otras áreas. Dichas interacciones,
en el seno del proyecto, pueden ser directas y evidentes o bien
sutiles e inciertas. Por esta razón la dirección exitosa de proyectos
exige, muchas veces, el balance entre varios objetivos del proyecto
y el manejo activo de estas interacciones.

Tiempo RRHH

Alcance Comunicaciones
Integración
Costos Riesgos

Calidad Adquisiciones
PM es integración

La dirección de proyectos involucra la interrelación de Procesos,

definiendo proceso como una serie de acciones llevadas a cabo
para lograr un resultado. En la dirección de proyectos, los procesos
tienen que ver con la descripción y organización de los trabajos.

Iniciación Planeamiento

Contro Ejecución

Cierre grupos de procesos

dentro de una fase

Proceso de iniciación
La metodología comienza con una etapa conceptual donde se
analiza la factibilidad del proyecto a encarar. Se realizan estudios
económicos, de riesgos, de oportunidades y estratégicos. Sus
resultados sirven como elementos importantes para decidir
proseguir o no con el proyecto.
Una decisión positiva en el proceso de selección implica
comprometer recursos humanos y materiales para el planeamiento
del proyecto. La autorización para construir el plan da lugar al
Project Charter que define:
La necesidad de negocio que dio origen al proyecto
La descripción del producto
El responsable del proyecto
Su autoridad y responsabilidad para el uso de los recursos
organizaciones en el proyecto, etc.
La emisión del mismo es normalmente realizada por una persona
externa al proyecto con autoridad organizacional reconocida.
Asimismo se confecciona el "enunciado del alcance" también
conocido como Documento de Requerimientos del Proyecto (DRP)
que presenta información tal como nivel de riesgo, criterio de éxito
y/o aceptación, medidas de costo, tiempo, alcance y calidad,
niveles de comunicación, etc.
Esta información que sirve de base para comenzar a planear el
proyecto no permanece inalterable sino que es enriquecida y
refinada a medida que se avanza en dicho planeamiento.
Proceso de planeamiento
En esta etapa se avanza en la consolidación de los requerimientos,
inicialmente los funcionales, basado en lo descripto en el DRP.
Estos requerimientos se van afinando para servir como base de los
requerimientos técnicos que finalmente se materializan en lo que
se denomina una estructura de trabajo detallada (WBS), donde se
desagrega el trabajo hasta llegar a elementos que se puedan
asignar a organizaciones o individuos (definiendo su responsabilidad
en la ejecución de la/s tarea/s) dando respuesta a preguntas tales
como: ¿ qué hay que hacer ? ¿quién es responsable? ¿cómo o con
que recursos? ¿cuándo hay que entregarlo? ¿cuánto costará?
Este documento contiene el alcance del proyecto y es la base para
obtener el cronograma, realizar el presupuesto y obtener el flujo de
caja. Se comienza con la identificación de riesgos dentro de su
proceso de gerenciamiento.
Pag.12
Tomando las tareas del WBS y teniendo en cuenta dependencias,
recursos y restricciones surge el cronograma, de él la duración total
del proyecto medida en su camino crítico. Para realizar el
presupuesto del proyecto se suman todos los costos de las tareas
del WBS obteniendo un presupuesto denominado por el PMI como
definitivo (por su grado de detalle). La conjunción de los costos por
tarea y el momento de efectivizarse la erogación (obtenido del
cronograma), permite conocer el flujo de caja necesario para el
proyecto.
Una vez logrado el conocimiento del alcance, del tiempo y del
costo del proyecto, estamos en condiciones de realizar el proceso
de gerenciamiento de riesgos, el cual comienza con la
identificación, sigue con la cuantificación y priorización y culmina
en esta etapa del proyecto con el planeamiento de las posibles
respuestas a dichos riesgos.
Es excluyente la firma de un documento de aceptación del plan
para continuar con el proyecto.
La metodología propone una serie de documentos que
complementan los ya enunciados y que conforman el plan total del
proyecto:
Plan de calidad: define cómo se efectuará el control y la mejora
continua tanto del proyecto como del producto o servicio creado
por el mismo. Se definen una serie de auditorías y revisiones
pautadas a lo largo del ciclo de vida del proyecto.
Plan de comunicaciones: fundamentalmente establece Qué
comunicar, a quién, cómo y cuándo.
Plan de Recursos Humanos: presenta una clara definición de los
roles y responsabilidades de los participantes del proyecto, quienes
son los mismos y como se desarrollará y fortalecerá el trabajo en
equipo (team building)
Finalmente los tres últimos documentos apuntan al control durante
las etapas de implementación y cierre del proyecto.
El primero es el control de cambios. Apunta a implementar un
proceso que permita evaluar impactos y realizar sólo aquellos
cambios que sean aprobados. El proceso establece que los pedidos
deben ser realizados en forma escrita, en formulario preestablecido
y con la firma del solicitante. Esta información es presentada a un
cuerpo colegiado (formado por el representante del cliente, el
gerente de proyectos y una autoridad superior a este último), el
cual evalúa el impacto de los cambios (tiempos, costos, alcance,
riesgos, etc.) y decide su implementación. La decisión se guarda
en un registro de control.
 Pag.13

Plan - Estándar

Acción Correción Cierre

Análisis
Plan - Real = Variación control de avance

El segundo es el de control de avance mediante la aplicación de un Se lleva a cabo el gerenciamiento de riesgos implementando las
proceso que dado los estandares establecidos y los resultados estrategias establecidas para hacer frente a los riesgos que se
obtenidos en la ejecución del proyecto (performance), analiza los materializan, identificando nuevos riesgos y revaluando
desvíos y toma las medidas correctivas necesarias. continuamente los riesgos vigentes.

Por último se establecen los criterios de aceptación del entregable

final del proyecto.
Proceso de cierre
En esta etapa existen dos áreas claramente marcadas:

Proceso de ejecución
La que atiende a la aceptación del producto o servicio por parte
En esta etapa se comienza con el "kickoff" o primera reunión del cliente (y su grado de satisfacción con lo realizado) que
conjunta del equipo que ejecutará el proyecto. Aquí se terminan de posibilita la facturación del trabajo y el cierre administrativo del
definir los roles y responsabilidades de sus miembros con el nivel proyecto.
de información necesario para la ejecución del proyecto. La que atiende a la organización ejecutora del proyecto en lo que
También se comienza a realizar, dentro del Plan de Recursos hace a la evaluación del proyecto realizado, a los beneficios que
Humanos, el desarrollo del equipo. En definitiva todos los le dejó la ejecución del mismo:
componentes del plan de gerenciamiento del proyecto son llevados a
Equipo experimentado
cabo en forma simultánea (Calidad, Comunicaciones, Riesgos, etc.)
Gente con nuevas aptitudes adquiridas durante la ejecución del
mismo
Lecciones aprendidas basadas en el análisis de la
Proceso de control documentación actualizada del proyecto

Se realiza el gerenciamiento de los cambios documentando las

solicitudes, análisis y decisiones. Se realizan las revisiones
programadas y las auditorías de ejecución, las cuales tienen como
objetivo verificar la marcha real del proyecto contra el plan y en el
caso de desvíos tomar las acciones correctivas correspondientes.

Se ejecuta también el proceso de Control de Calidad, el cual

verifica el cumplimiento de los estándares de calidad previamente
definidos e identifica formas de eliminar las causas de resultados
insatisfactorios.

PROFESSIONAL SERVICE AUTOMATION
La plataforma metodológica descripta se sustenta en herramientas
tecnológicas que nos permiten agilizar y hacer más eficientes
nuestros procesos de administración de proyectos. En tal sentido
contamos con una solución Automatización de Servicios
Profesionales orientadas a Gerencias de Sistemas y Empresas de
Servicios organizadas por proyecto a través de un Portal Web de
gestión del portfolio de proyectos para una o múltiples empresas.
Se trata de una solución integrada diseñada para organizaciones
basadas en servicios que permiten a su personal ser más
productivo y rentable incrementando su eficiencia a través de una
mayor utilización de su tiempo, la mejora en la planificación y la
gestión del conocimiento integrados.
Gartner Dataquest se refiere a este tipo de soluciones con el
nombre de Project Portfolio Management - PPM - a fin de
diferenciar el software de organización de proyectos (generalmente
orientados a administrar pocos proyectos) de las aplicaciones
orientadas a organizaciones que literalmente administran un
portfolio de múltiples proyectos, los cuales pueden abarcar
diferentes geografías y clientes. Aberdeen Group, por su parte, lo
denomina soluciones de Professional Service Automation -PSA-.
Como parte de su alcance se destaca:
Administración de Múltiples Empresas: Este módulo provee la
posibilidad de administrar en forma centralizada información de
múltiples empresas. En caso de ser aplicado a una única
empresa esta división puede adaptarse a áreas, departamentos o
sucursales de dicha compañía.
Administración del "Pipeline": para oportunidades externas o
prospectos internos. Administración integral de contactos,
calificación y seguimiento de oportunidades, del ciclo de ventas y
del forecast.
Administración de Alcance: definiciones del proyecto, tiempos,
tamaño y entregables. Puede incluir el seguimiento de propuestas
para monitorear los porcentajes de éxito y seguir las diferencias
entre ofertas anteriores y los costos actuales del proyecto.
Administración de tiempos: tiempos de los entregables, fechas
límite del proyecto, tareas, asignaciones, alcance y objetivos.
Administración de recursos: asignación de recursos disponibles,
carga y categorización de los recursos (directa o vía integración
con terceras- partes)
Pag.14
Administración de habilidades: repositorio de recursos y
habilidades que incluye experiencia laboral, certificaciones,
ubicación geográfica, tarifas, intereses y objetivos de carrera.
Administración de Costos: estima los costos de recursos y
materiales y obtiene las aprobaciones necesarias para los gastos
del proyecto
Administración de Compras: herramientas que soportan el
proceso de compra de recursos externos y bienes relacionados
con el proyecto
Administración de las Comunicaciones: facilita la distribución de
información (discusiones, e-mail y chat) y permite a los
empleados y asociados de negocio colaborar, administrar,
mantener y compartir conocimiento obtenido en proyectos
anteriores y el actual.
Reportes y pronósticos (forecasting): almacenar, consultar y
pronosticar el progreso del proyecto, crear programas de trabajo
actualizados y predecir el ingreso potencial.
Administración de Riesgos: monitorea y analiza vistas macro de
múltiples proyectos dentro de la organización para identificar y
cuantificar riesgos y valorizar costos para seleccionar la
combinación más adecuada de proyectos.
Administración de la Integración: integración de información
acerca de la planificación del proyecto, ejecución y cambios a los
entregables a través de metodología de planificación de proyectos
y un sistema de autorización de cambios.
Gestión de Incidentes y Requerimientos: Constituye una flexible
solución para la administración de consultas, reclamos, quejas
incidentes y requerimientos a través de un modelo de workflow
configurable. Cuenta con servicios de atención online via
herramientas de comunicación e integración (discusiones, e-mail,
chat)
Administrador de Roles y Perfiles: Cada usuario posee un perfil
de seguridad que restringe su actividad dentro del portal. Los
perfiles de usuarios tendrán restricciones a nivel de empresa y
proyecto, y en cada caso permisos de lectura o modificación
 Pag.15

BENEFICIOS

Dentro de los beneficios clave de este tipo de soluciones se

destacan:

Incremento en la eficiencia y la productividad que genera una

reducción de costos por asignaciones y la posibilidad de tomar
más proyectos
Ganar una visibilidad de 360 grados utilizando herramientas de
información que incluyen un mejor pronóstico - forecasting - y
planeamiento
La posibilidad de colaborar efectivamente
El reconocimiento y seguimiento de oportunidades de manera
sencilla
Administración global que resulta en una reducción de gastos
Mayor profesionalismo
Empleados más motivados lo cual deriva en un aumento de la
retención y en una reducción de los costos de reclutamiento y
capacitación
Mejor administración del conocimiento, a través de la
reutilización del trabajo realizado en otros proyectos y clientes
Control de calidad en gastos y facturación

Aberdeen Group, en su reporte "What Works in Profesional Services

Automation", destaca que PSA muestra un ROI significativo. Las
organizaciones que implementaron Professional Service Automation
reportaron un ROI anualizado en 5 años del 96.7 %, resultado de
sus dos principales beneficios: un incremento en la utilización de
recursos facturables de un 8.1% y una reducción en el ciclo de
facturación de las PSOs (professional service organizations) de 1.6
semanas (11 días).

Fuentes

*What Works in Professional Services Automation - Aberdeen

Group - 2003
*Software Market Definitions for Project Portfolio Management -
Gartner Dataquest - 2003
*Infrastructure Software Market Definitions for Application
Development - Gartner Dataquest - 2003
*IBM Rational Unified Process: Best Practices for software
development teams
*Una metodología básica para la dirección de proyectos - Alberto
López PMP certificado del PMI