Planificacin y Organizacin de Proyectos dirigidas por la Arquitectura

M.C. Mariel Feder

Laboratorio de Ingeniera de Software.

Universidad ORT Uruguay.

Direccin postal:
Universidad ORT Uruguay
Facultad de Ingeniera
ORT Software Factory

Cuareim 1451
11100 Montevideo, Uruguay.
Telfono +598 +2 9021505

Direccin electrnica:
mfeder@netgate.com.uy

Resumen
Gestionar un proyecto de software, consiste en asegurar que se entregar un producto que cumpla
con las especificaciones dentro del plazo y costo acordados, con el nivel de calidad pactado.
Factores clave para lograrlo son la planificacin y organizacin adecuadas del proyecto.

Por otra parte, la definicin de la arquitectura del producto a desarrollar tiene un impacto muy
importante no slamente en el producto final del que es base, sino que tambin debera influir en la
forma en que el proyecto se enfoca desde el punto de vista de su gestin, facilitando as la
integracin de las disciplinas tcnicas y gerenciales que deben interactuar en todo proyecto exitoso.

El objetivo del presente trabajo es analizar la fase de planificacin y organizacin del proyecto y ver
cmo la misma se ve afectada por la arquitectura, o mejor dicho, se ve pautada por sta en forma
natural, en lo que se podra denominar planificacin y organizacin dirigidas por la arquitectura.

Palabras claves
Ingeniera de Software, Gestin de Proyectos, Arquitectura de Software, Planificacin,
Organizacin.
1. INTRODUCCIN
1.1. Qu es la Gestin de Proyectos
Gestionar un proyecto consiste en asegurar que se entregar un producto que cumpla con las
especificaciones dentro del plazo y costo acordados, con el nivel de calidad pactadoi.
Generalmente, los proyectos de software se desarrollan en un mundo de naturaleza cambiante, lo
que implica un nivel importante de incertidumbre relacionada a aspectos tales como recursos
humanos, tecnologa o de negocio.
Las actividades involucradas en la gestin de un proyecto van variando a lo largo del proceso de
desarrollo del ciclo de vida del proyecto1 en relacin directa con el proceso de desarrollo utilizado.ii
Ms all de las particularidades de los proyectos individuales, en su gran mayora los proyectos
evolucionan segn el siguiente ciclo de vida:

Inicializacin: Es el momento en que se reconoce que un proyecto puede comenzar y se consiguen

los compromisos para hacerlo. Las principales actividades de esta fase son:
- Anlisis de las consecuencias de realizar (o no realizar) el proyecto.
- Definicin de las magnitudes necesarias para completarlo.2
- Anlisis de alternativas
- Anlisis tcnicos tales como anlisis de viabilidad, materiales disponibles, recursos geotcnicos,
urbansticos, de impacto ambiental, etc., dependiendo de la naturaleza del proyecto.
- Anlisis de la inversin, volumen, valor presente, rentabilidad futura.
- Anlisis costo/beneficio, incluyendo costos sociales, beneficios no monetarios, etc.
- Anlisis de riesgo, con la informacin de que se dispone hasta el momento.3

Planificacin y Organizacin: Confeccionar y mantener un esquema de trabajo que permita

alcanzar el objetivo. Es en esta etapa en la que se identifican las tareas, se estiman tiempos y
costos, se conforman los equipos, se asignan los recursos (humanos y otros) y se elabora el
plan de trabajo. Debe sealarse que este no es el nico momento del proyecto en que se
realizan tareas de organizacin y planificacin. Generalmente, la organizacin y planificacin
iniciales del proyecto se realizan con un alto nivel de abstraccin, por lo que luego se repite la
actividad para definir estos elementos con un nivel mayor de detalle a medida que se va
avanzando en el proyecto.

Produccin o Implementacin: Durante esta fase se realizan tres grandes actividades:

Administracin: coordinacin de personas y recursos para llevar adelante el plan
Ejecucin: la propia realizacin de las tareas que generan el producto
Control: Controles para asegurar que los objetivos del proyecto son alcanzados, mediante
monitoreo y medicin de avance, tomando las acciones correctivas que correspondan. Este
seguimiento permite retroalimentar la planificacin, por lo que se vuelve un proceso abierto y
cclico. Estas mediciones se realizan tanto del proyecto como de las caractersticas del producto que
se va generando.
Cierre: Formalizacin de la aceptacin del proyecto y realizacin del fin de actividades en forma
ordenada. Se da por concluido el proyecto y se obtiene el producto final. La informacin obtenida
se almacena y se evalan los resultados.

1
Me refiero al Ciclo de Vida del proyecto a diferencia del Ciclo de vida del desarrollo del producto que se
explicar ms adelante.
2
Ntese el uso del trmino magnitud en lugar de valor, ya que en este momento se pretende una
aproximacin que refleje el orden de magnitud de los elementos a estimar.
3
Volver sobre este tema ms adelante.
 Planificacin Planificacin Administracin
general especfica Retroalimentacin
Ejecucin
Inicio Planificacin
Control

Produccin

Etapas en la gestin de un proyecto

1.2. Qu es la Arquitectura del Software

La arquitectura de software es una disciplina relativamente joven, por lo que no existe an una
definicin del trmino nica y ampliamente aceptada.
No es el objetivo del presente trabajo adentrarnos en este tipo de discusin filosfica, ya que si bien
las distintas definiciones formales an pugnan entre s en el mundo acadmico, el concepto que est
detrs es bsicamente similar entre todas ellas.
Tomar como definicin la propuesta por Bass, Clements y Kazman: La arquitectura de un
programa o sistema de computacin es la estructura o estructuras del sistema, que comprenden
sus componentes de software, las propiedades externas de los componentes, y la relacin entre
ellosiii, que coincide con la propuesta por Soni, Nord y Hofmeisteriv

1.3. Ciclo de vida del desarrollo del producto

El ciclo de vida es una vista del orden de las actividades que ocurren durante el desarrollo. As, el
software progresa desde una idea inicial a travs de su implementacin, uso y eventualmente su
muertev.
Un ciclo de vida describe las principales fases del desarrollo y las principales actividades que se
espera se realicen durante estas fases. Ayuda a los gerentes a realizar el seguimiento del proyecto y
provee de un marco para la definicin del proceso de desarrollo detallado.
Cascada
El primer ciclo de vida, la cascada fue definido por Winston Roycevi en los comienzos de los aos
70. Desde entonces, muchos equipos de desarrollo han seguido este modelo. En los ltimos 10 o 15
aos la cascada ha sido muy criticada por ser considerada muy rgida para el desarrollo de los
proyectos de software modernos.
El modelo es muy simple, y considera al desarrollo como una secuencia de fases que no se repite.
Cada fase tiene un conjunto definido de objetivos, y las actividades de una fase se realizan para la
consecucin de los mismos. Las normas de la cascada son bsicas:

Requerimientos
Requerimientos
Arquitectura
Arquitectura
Diseo
Diseo Diseo
Codificacin y testing
unitario Codificacin y Codificacin y
testing unitario testing unitario
Integracin Integracin Integracin

Operacin Operaci
Ciclo de vida en Cascada Operacin y
Mantenminiento
Ciclo de vida de desarrollo incremental
 Planificar el proyecto antes de comenzar
Definir el comportamiento externo esperado del sistema antes de definir su funcionamiento
interno.
Documentar los resultados de cada actividad
Disear el sistema antes de codificarlo
Testear el sistema una vez que est construido.

Desarrollo incremental
Los riesgos asociados con sistemas grandes y complejos son muy altos. Una forma de reducir el
riesgo es construyendo solamente una parte del sistema y reservar el resto para sucesivas
liberaciones. El desarrollo incrementalvii plantea la construccin de partes del sistema en forma
secuencial, de forma de ir liberando y probando versiones en forma paulatina. Generalmente, se
parte de la lista de requerimientos de todo el sistema y de una definicin de la arquitectura de alto
nivel que contempla todos estos requerimientos, y luego se divide la funcionalidad en grupos que se
van diseando, implementado, testeando e integrando uno a uno.
Modelo Evolutivo
Como el desarrollo incremental, el modelo evolutivoviii construye una serie sucesiva de versiones
incluyendo en cada una de ellas ms funcionalidad que en la anterior, hasta completar el sistema. La
diferencia es que no se conocen a priori todos los requerimientos, sino que los mismos se van
descubriendo en cada una de las evoluciones. Por lo tanto, tampoco existe una arquitectura de alto
nivel definida desde el principio, sino que la misma va evolucionando hacia la arquitectura final.
En este modelo, los requerimientos son analizados, y slamente se implementan aquellos que se
entienden completamente. El sistema es implantado, los usuarios lo utilizan y retroalimentan al
equipo de desarrollo. En base a esta retroalimentacin se actualizan los requerimientos y comienza
el desarrollo de la versin siguiente y as sucesivamente.

Requerimientos Requerimientos

Diseo Diseo

Codificacin y testing
Codificacin y testing
unitario unitario

Integracin Integracin

Operacin
Operacin
Ciclo de Vida Evolutivo

Otros modelos
El modelo de prototipacinix de requerimientos implica la creacin de una implementacin parcial
del sistema con el propsito de aprender sobre los requerimientos. El prototipo se construye lo ms
rpido posible y luego los usuarios o quien corresponda experimenta con el prototipo y
retroalimenta al equipo que puede as especificar correctamente los requerimientos. Este modelo
puede combinarse con cualquiera de los anteriores, incluyendo la tarea de prototipacin y
validacin del prototipo como parte de las fases de requerimientos. La prototipacin se utiliz
mucho en los aos 90 porque la especificacin de requerimientos de sistemas complejos suele ser
difcil de entender, y es ms fcil para quien debe validar los requerimientos manipular un prototipo
en lugar de leer un documento tedioso y potencialmente ambiguo.
El modelo de espiral de Boehmx, es un meta ciclo de vida. En este modelo, el esfuerzo del
desarrollo es iterativo y guiado por el riesgo. Antes de cada vuelta en la espiral, se realiza un
anlisis de riesgo y se analizan las alternativas. Es adecuado para proyectos de alto riesgo. Sin
embargo, dentro de la espiral puede incluirse cualquiera de los ciclos de vida anteriores, y segn el
que se elija para esto, se configurarn las diferentes tareas de cada vuelta de la espiral.
El modelo concurrente tambin es una meta descripcin del proceso. Provee un mecanismo para
mostrar las actividades concurrentes. Tambin puede combinarse con cualquiera de los ciclos de
vida mencionados.

2. CICLO DE VIDA PARA LA GESTIN DIRIGIDA POR LA

ARQUITECTURA
Algunos autoresxi sostienen que en los ltimos 10 aos ha habido una concientizacin general sobre
la importancia de describir la arquitectura del software antes de implementar el producto.
Si bien existen otras alternativas, como el modelo evolutivo, a mi criterio igualmente vlidas en
determinadas circunstancias, este requerimiento es necesario, si se desea realizar la gestin del
proyecto basada en la arquitectura.
En los casos donde se utilizan los ciclos de vida en los que se define la arquitectura de alto nivel al
comienzo (cascada o desarrollo incremental), es posible aplicar estos principios de gestin en forma
completa, mientras que en los modelos evolutivos es posible hacerlo en forma parcial, aplicando los
conceptos a cada una de las evoluciones.

3. PLANIFICACIN DEL PROYECTO

Los proyectos bien gestionados generalmente comienzan como proyectos bien planificados.
En la gestin de proyectos dirigida por la arquitectura, el momento de realizar la planificacin y
organizacin del proyecto es en paralelo con la definicin de la arquitectura de alto nivel, no antes.
Se debe resistir la presin externa de divulgar estimaciones y planificaciones no confiables para no
comprometerse a metas que luego no podrn cumplirse.
Es bien sabido que las estimaciones de esfuerzo y cronograma realizadas en etapas muy tempranas
del proceso de desarrollo de software suelen ser muy imprecisas. xii xiii
Es muy difcil confeccionar un cronograma viable, identificar metas intermedias y puntos de control
antes de contar con una arquitectura de alto nivel.
Una vez que la arquitectura est completa, es posible crear un plan de proyecto, un cronograma,
organizar el staff y los equipos, todos factores que dependen de la arquitectura delineada.

3.1 Estimacin
Paulishxiv sugiere el siguiente proceso:
Comenzar el proyecto con un pequeo equipo de diseadores que crearn la arquitectura de alto
nivel. En paralelo, utilizar mecanismos de estimacin top-down para estimar el total del proyecto
tales como Puntos Funcin de Albrecht, Cocomo de Boehm, SLIM, PRICE-S, etc., siendo el
gerente de proyecto el responsable de esta tarea.
Los componentes identificados en la arquitectura de software se convierten en las unidades para la
estimacin bottom-up. Estos componentes se deben identificar en el diseo lgico del sistema,
donde se identifican los subsistemas o componentes de alto nivel de abstraccin, en la vista lgica
propuesta en el modelo 4+1 de Krutchenxv o su equivalente si se usa otro modelo para representar la
arquitectura.
El arquitecto o los lderes del equipo de diseo deben ser los responsables de la estimacin bottom-
up ya que son quienes conocen la naturaleza y complejidad de cada una de las unidades. Luego el
gerente de proyecto debe integrar ambas estimaciones, comparando la suma de la estimacin de las
unidades contra la estimacin top-down y tratar de encontrar el punto de equilibrio.
En general, la estimacin bottom-up es ms precisa en relacin a cada uno de los componentes, pero
suelen olvidarse otras actividades que no forman parte del desarrollo de las unidades aisladas, tales
como las actividades de aseguramiento de la calidad (SQA), de integracin, test del sistema,
documentacin de usuarios, comunicacin, etc. Estos elementos s suelen estar incorporados en las
estimaciones top-down
Si bien es posible que existan diferencias entre ambas estimaciones debido a estos factores, ambas
deberan ser razonablemente compatible. De lo contrario debera revisarse el proceso de estimacin.
En general lo que no debe hacerse es aceptar estimaciones top-down menores que la suma de las
unidades, ya que esta ltima incluye ms actividades y no menos.
Considerando estos aspectos, y una vez obtenidas dos estimaciones compatibles, sugiero como
mecanismo de integracin, considerar el total de la estimacin top-down, y las proporciones entre
las unidades que surgen de la estimacin bottom-up.

3.2 Anlisis de Riesgo

Como manifest al comienzo, los proyectos de software suelen ir acompaados de niveles
importantes de incertidumbre. Esta incertidumbre se traduce en riesgos, que son probables efectos
adversos o problemas que se pueden encontrar durante el desarrollo del proyecto. La gestin del
riesgo es una tarea propia del gerente del proyecto y se define como la funcin ejecutiva que se
encarga de mantener bajo control los factores negativos mencionados de forma que estos no
hipotequen el xito del proyecto.

3.2.1 Proceso de gestin de riesgos

La gestin del riesgo se realiza siguiendo un proceso bien definido que implica xvi xvii:

Identificacin: Existen diferentes mecanismos para la identificacin y ponderacin de los riesgos

tales como check lists, taxonomas (conocimientos transmitidos por terceros, ej. Karolak xviii),
analoga con casos conocidos, aplicacin del sentido comn, resultados de experimentos entre otras.

Anlisis: Una vez identificados, es necesario ponderarlos en lo que refiere a su probabilidad de

ocurrencia y su impacto en el proyecto, de forma de encontrar los ms importantes y gestionar
slamente aquellos que puedan llegar a afectar significativamente el proyecto. Este es el momento
de decidir no continuar con el proyecto si el mismo es demasiado riesgoso, dependiendo de la
cultura de riesgo de la organizacin.

Planificacin: Frente a los riesgos identificados, se puede decidir asumirlos, es decir, no tomar
ninguna accin para evitar que sucedan o que afecten al proyecto o mitigarlos. Mitigar un riesgo
significa realizar acciones para disminuir su probabilidad o su impacto, denominadas acciones
preventivas. Las acciones preventivas se transforman en tareas a realizar que deben ser incluidas en
el cronograma y en la planificacin del proyecto (ejemplo: realizar prototipo de comunicacin de
las plataformas); o en decisiones de gestin o de negocio (ejemplo: incrementar en un 20% el precio
de la propuesta para cubrir posibles prdidas identificadas).
Los riesgos asumidos siempre pueden materializarse. Debe tenerse en cuenta que tambin pueden
hacerlo aquellos que trataron de mitigarse, si las acciones preventivas no fueron exitosas, o quizs
hacerlo con un impacto menor. En ambos casos, debe planificarse un conjunto de acciones
correctivas o planes de contingencia en los que se establece cmo reaccionar frente al problema
previsto si este sucede. Ejemplos interesantes de planes de contingencia se vieron en muchas
organizaciones durante el cambio de siglo.

Seguimiento: Peridicamente se realiza un seguimiento de la evolucin de los riesgos en base a

indicadores definidos y una evaluacin de las actividades de prevencin realizadas. Adems, debe
monitorearse constantemente la aparicin de nuevos riesgos que surgen durante el desarrollo del
proyecto.

Evaluacin: Al fin del proyecto se realiza una evaluacin de la gestin de riesgos y sus resultados
de forma de extrapolar la experiencia obtenida a otros proyectos. En caso de haberla, es el momento
de alimentar la base de datos de conocimiento de la organizacin.

Identificacin

Anlisis

Planificacin

Seguimiento

Ciclo de gestin de Riesgo Evaluacin

3.2.2 Anlisis de riesgo y arquitectura del Software

La arquitectura de software es una entrada muy importante para el proceso de anlisis de riesgo.
Los riesgos tcnicosxix suelen ser un porcentaje importante en los riesgos inherentes al desarrollo de
productos de software y la fuente para identificarlos es el documento de arquitectura, ya que es all
donde se especifican las decisiones tcnicas tomadas y los paquetes que deben desarrollarse. Por lo
tanto, el documento de arquitectura debe ser un origen que no se puede pasar por alto en la fase de
identificacin de los riesgos.
Recomiendo no dejar de analizar los siguientes factores, aunque lo que se presenta no es una lista
exhaustiva:
Experiencia de los equipos de desarrollo en las plataformas, lenguajes y herramientas
seleccionadas
Estabilidad de las herramientas y plataformas
Disponibilidad de las herramientas y plataformas
Integrabilidad de las plataformas seleccionadas
Interoperabilidad entre los componentes diseados
Nivel de complejidad, testeabilidad y acoplamiento de los componentes
Identificacin de los componentes crticos ya sea por su importancia para el funcionamiento del
producto o por su complejidad.
Atributos de calidad requeridos que resulten crticos para el producto (ej.: performance,
seguridad, amigabilidad, etc.) y que la arquitectura debe garantizar xx xxi xxii xxiii.
Del anlisis de la arquitectura del software propuesto surgen entonces una serie de riesgos que
deben ser incluidos en el anlisis de riesgo. Por supuesto que esta identificacin no puede ser
realizada por el gerente de proyecto solamente sino que deber hacerlo en conjunto con el
arquitecto.
Los riesgos que se identifiquen a partir de la arquitectura, tambin deben ser ponderados y
planificados al igual que los riesgos que surgen de otras fuentes. En algunos casos, se transformarn
en actividades preventivas simples (ejemplo: capacitacin en alguna herramienta, prototipacin de
algn componente), en otros casos impactarn en las decisiones de gestin o del propio proceso de
desarrollo (ejemplo: incorporacin de una fase de beta testing), pueden influir en el cronograma en
lo que respecta a la secuencia en que los paquetes o componentes sern desarrollados4, o incluso
pueden transformase en decisiones que modifiquen la arquitectura planteada inicialmente (ejemplo:
cambio de plataforma), por lo que es necesario volver a analizar los riesgos que la nueva
arquitectura plantea, transformndose el proceso en un ciclo.

3.3 Plan de Versiones

En general, y ms especialmente para los proyectos de mayor porte, no es posible ni razonable
desarrollar todos los componentes y funcionalidades simultneamente.
Existen por lo tanto, desarrollos en paralelo pero tambin en secuencia, independientemente del
ciclo de vida elegido, ya que lo afirmado es cierto incluso para los ciclos de vida en cascada.
Se vuelve entonces importante identificar los componentes o paquetes que deben ser desarrollados
para luego determinar el orden en que se har. En estas secuencias, se suelen definir puntos
intermedios de control, que permitan subdividir el proyecto, dando la posibilidad de establecer
objetivos a corto plazo. Esto es necesario para darle al gerente puntos visibles donde medir el
avance del proyecto y poder tomar acciones en caso de desviaciones.
En particular, para los proyectos que evolucionan en versiones (ciclos de vida iterativos o
evolutivos), en estos hitos se suele incluir una versin del sistema con el desarrollo completo de un
grupo funcional que compone una versin del sistema, de donde surge el nombre de plan de
versiones. En estos planes se identifican versiones pre-release, que son internas al proyecto, y
versiones release o liberaciones, que son las versiones que se van entregando al cliente durante el
desarrollo del producto.
Para el caso del ciclo de vida en cascada, existir una sola versin release al final del desarrollo.
El documento de arquitectura y el anlisis de riesgo, adems de los acuerdos con el cliente o las
necesidades del mercado, deben ser las entradas a considerar para la confeccin del plan de
versiones.
Suelo identificar los siguientes criterios utilizados para establecer el orden y contenido de las
versiones:
Dirigido por el riesgo: Se desarrollan primero los componentes o funciones de mayor riesgo, para
encontrar las dificultades lo antes posible, y evitar as sorpresas luego de haber realizado una
inversin mayor en el proyecto o de haber tomado una serie de decisiones sobre las que ya se ha
recorrido un buen trecho.
Dirigido por las necesidades del usuario/mercado: Se incluyen primero las funcionalidades ms
urgentes segn el criterio del usuario o cliente, y es este quien fija las prioridades que luego pautan
la definicin de las versiones a liberar.
Secuencia lgica: Se realizan primero las funciones o componentes necesarios para el
funcionamiento de otras funciones o componentes, es decir las funciones o componentes invocados
por otras funciones o componentes de ms alto nivel, evitando as el uso de stubs5 que exigen un
mayor esfuerzo de testing cuando se sustituyen por los verdaderos componentes.
Dirigido por la capacitacin: En algunos casos donde los desarrolladores no estn familiarizados
con las herramientas a utilizar, se suelen desarrollar primero las funciones o componentes ms
sencillos para ir aprendiendo el uso de la herramienta e ir progresivamente enfrentando opciones
ms complejas.

4
Ver captulo Plan de Versiones
5
Stubs: Funciones o rutinas vacas, que nicamente implementan la interfase y generalmente devuelven
valores fijos, para que se puedan compilar y probar las funciones o rutinas que las invocan mientras no se
hayan desarrollado las verdaderas funciones o rutinas a invocar. Los stubs son temporales y luego se
reemplazan por las verdaderas funciones cuando estas son implementadas.
Combinacin: Como en tantos otros aspectos, en general no se utiliza solo uno de los criterios sino
que es posible utilizar opciones hbridas para distintos momentos en diferentes partes del producto.
La arquitectura del software es una entrada fundamental a la hora de confeccionar el plan de
versiones. En primer lugar, identifica los componentes que habrn de ser distribuidos a lo largo de
las versiones e identifica qu funcionalidad o requerimiento del usuario dicho componente
implementa (o colabora en su implementacin). De esta forma, es posible identificar qu paquetes o
componentes es necesario desarrollar para poder incluir cierta funcionalidad en una versin, y
aplicar el criterio dirigido por el usuario.
Por otra parte, tambin es de la arquitectura desde donde se identifican los componentes ms
crticos, los ms complejos y los ms importantes para el sistema en caso de utilizar el criterio
dirigido por el riesgo, o el nivel de prestacin de servicios entre componentes para aplicar el criterio
de secuencia lgica.
Como la arquitectura es el documento donde es posible identificar los componentes ms crticos o
complejos del software, sta no slo debe utilizarse para la confeccin del plan de versiones, sino
tambin para la definicin de las estrategias de pruebas e integracin.

3.4 Recursos Humanos

Una actividad crucial para el xito de un proyecto de desarrollo de software es el reclutamiento,
capacitacin y organizacin en equipos de los recursos humanos. No est dentro del alcance del
presente trabajo analizar las estrategias de reclutamiento o capacitacin, ni la necesidad de trabajar
en equipos en el desarrollo de software, concepto que ya est arraigado en la industria xxiv xxv.
En cuanto al reclutamiento, la arquitectura permite ver claramente los distintos perfiles que sern
necesarios en el proyecto, as como los diferentes conocimientos tcnicos que se requerirn.
Por ejemplo, en un sistema que utiliza fuertemente bases de datos, se puede deducir la necesidad de
contar con un equipo con conocimiento de diseo y administracin de base de datos.
Lo mismo aplica para las distintas plataformas, lenguajes o herramientas que se identifican.
De la arquitectura por lo tanto, surgen los distintos perfiles tcnicos con los que se habr de contar
para el desarrollo del producto, criterios que deben marcar el reclutamiento de nuevo personal o
plasmarse en planes de capacitacin para el personal existente.
Una vez seleccionados los perfiles, es necesario organizar los equipos.
La arquitectura puede ser la base para la organizacin de los equipos, destacndose dos alternativas:
en forma vertical y horizontal.

3.4.1 Organizacin horizontal

Para los sistemas diseados en capas o para aquellos con componentes funcionales claramente
diferenciados, es posible tener equipos asignados a cada uno de estas capas o paquetes.
Por ejemplo, para un sistema en capas (interfase de usuario, dominio y persistencia), podra existir
un equipo para cada una de ellas.
O en un sistema de operacin de una red compuesta por paquetes para la representacin geogrfica
de la red en forma visual, paquetes para la manipulacin de los nodos de la red y paquetes para
interaccin con dispositivos de telecontrol, cada equipo podra especializarse en uno de estos
paquetes.

La ventaja de esta organizacin es que cada uno de los equipos se vuelve un experto en el paquete o
capa en la que est trabajando. Adems, como slo un equipo trabaja en una capa o componente, el
mismo es diseado e implementado siguiendo siempre el mismo criterio, con lo que se logra que
sea ms uniforme y estandarizado.
Como desventajas, es necesario tener varios equipos trabajando simultneamente para realizar las
porciones de todas las capas o paquetes necesarios para implementar una versin.
Adems, los equipos tienen una vista parcial del sistema y es ms difcil encontrar luego
desarrolladores con una visin general del sistema para las fases de mantenimiento, en caso de que
se desee reducir los equipos que participarn en esta etapa

Equipo 3 Equipo 1 Equipo 2 Equipo 3

Capa/componente 3
Capa/componente 3

Equipo 2
Capa/componente 2
Capa/componente 2
Equipo 1
Capa/componente 1
Capa/componente 1

Organizacin de equipos horizontal Organizacin de equipos vertical

3.4.2 Organizacin vertical

La organizacin vertical implica la divisin del sistema en grupos funcionales o subsistemas que
atraviesan varias capas o componentes.
Se forman equipos para cada uno de estos subsistemas o grupos funcionales, que trabajarn en todas
las capas o componentes necesarios.
Una de las ventajas es que es posible llegar a desarrollar las sucesivas versiones de un producto con
un solo equipo trabajando, simplemente serializando los grupos funcionales o subsistemas en varias
versiones (condicionado por el tamao del proyecto).
Otra ventaja es que se evitan los problemas de comunicacin entre los equipos de distintos paquetes
o capas que deben comunicarse o prestarse servicios mutuamente. Si bien esto puede representar
una ventaja, tambin puede incorporar un problema colateral si al conocer el equipo el
funcionamiento interno de la capa que provee los servicios, viola el encapsulamiento y accede
directamente a las capas subyacentes, lo que no es tan probable que suceda cuando esta fue
desarrollada por otro equipo y no se conocen sus detalles de diseo o implementacin.
En tercer lugar, los desarrolladores de los distintos grupos funcionales tienen una visin ms
completa de la funcionalidad en la que estn trabajando, ya que participaron del diseo y la
implementacin de todos los componentes involucrados, en contraposicin con la otra posibilidad.
Como desventaja, si varios equipos trabajan en una misma capa o componente, puede que los
mismos no resulten lo cohesivos que debieran ser, que exista redundancia (funciones
implementadas varias veces), o que no se apliquen los mismos criterios frente a alternativas
similares.
En mi opinin, en proyectos de cierta magnitud donde se dispone del personal suficiente para armar
los equipos necesarios, es preferible la organizacin horizontal, ya que se logran paquetes ms
cohesivos y optimizados y menos acoplados. Adems, debido a la no duplicacin de esfuerzo para
desarrollar funcionalidades o servicios similares, se disminuye el esfuerzo de desarrollo. Por otra
parte al tener un equipo responsable de cada componente en particular, en caso de algn problema o
falla, es fcilmente identificable cul es el equipo que tiene un conocimiento integral del paquete
para localizarla y solucionarla.
En proyectos de gran porte, es posible utilizar combinaciones de ambos enfoques donde
corresponda, definiendo equipos verticales y sub-equipos horizontales o viceversa, segn surja de la
arquitectura definida.
A la hora de configurar los equipos, es importante que en cada equipo se incluya alguno de los
participantes del diseo de la arquitectura, generalmente estos suelen ocupar el rol de jefe de
equipo.
Ellos tienen un conocimiento ms profundo de la arquitectura que ayudaron a definir y de los
motivos por los que se tomaron las decisiones, por lo que su visin no se concentra en el paquete a
desarrollar, visin que pueden transmitir al resto del equipo. Adems, estn en mejores condiciones
de tomar decisiones con respecto a un componente en particular, pues conocen mejor sus
repercusiones en el resto del sistema.
Por otro lado, participaron en el proceso de estimacin bottom-up de los componentes, por lo que se
encuentran comprometidos con esta planificacin, compromiso que deben cumplir como jefes de
equipo por el que son responsables.

3.5 Cronograma
Las herramientas para representar cronogramas que se utilizan hoy en da, generalmente permiten
agrupar y desagrupar las tareas en distintos niveles de abstraccin, por lo que ofician tambin de
WBS (Work Breakdown Structure).6
Por lo tanto, se mencionarn en forma indistinta las formas de organizar el cronograma y la WBS,
ya que ambas se representan en forma conjunta.
Las alternativas a la hora de organizar una WBS o un cronograma siguen diferentes criterios xxvi:
Orientada a la fase: Permiten identificar las fases del desarrollo. Se divide el sistema primero en
grandes fases, luego dentro de las fases se detallan las tareas particulares.
Orientadas al producto: Permiten identificar los componentes. Se descompone el producto en
partes y luego se representan las tareas para realizar cada una de las partes del producto.
Orientadas a la funcin: Se organizan segn los distintos actores del sistema
Existen alternativas hbridas que permiten mezclar los dos criterios para distintas partes o diferentes
momentos en el desarrollo del producto.
La forma ms til de representar el cronograma es que el mismo se parezca lo ms posible al ciclo
de vida. Por ejemplo para los ciclos de vida iterativos o evolutivos, resulta muy conveniente que el
mismo refleje directamente el plan de versiones. De esta forma, se contarn con grandes tareas que
representan cada una de las versiones, que a su vez se descompondrn en tareas concretas para
alcanzar estas metas. De esta forma, es posible acceder al nivel de detalle de la fase o tarea del ciclo
de vida que se est ejecutando en este momento (por ejemplo, la iteracin que genera la versin X
del producto), y manejar el resto del proyecto con un nivel de abstraccin mayor. Por otra parte, los
hitos o mojones que marcan el fin de cada una de las fases identificadas en el ciclo de vida, se
corresponden con el fin de las tareas de mayor nivel de abstraccin del cronograma, que son a su
vez el primer nivel de la WBS asociada.
Una vez definida la estructura del cronograma deben planificarse las distintas iteraciones y dentro
de cada una de ellas deben identificarse los componentes sobre los que se va a trabajar y los
recursos que se asignarn a dichas tareas xxvii.

6
WBS= Work Breakdown Structure: Representacin grfica en forma de rbol donde se subdividen grandes
tareas en tareas ms concretas en forma recursiva, de forma de obtener unidades ms manejables que puedan
ser estimadas y asignadas a los responsables de ejecutarlas. Permite acceder a representaciones de distinto
nivel de agregacin para obtener vistas con distinto nivel de abstraccin.
 enero f ebrero marzo abril may o junio julio agosto septiembre octubre nov iembre diciembre enero
Id Nombre de tarea F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M F P M
1 Ing. 'Requerimient os
2 Arquitectura

3 Version pre-release 1
4 Componente 1
5 Componente 2
6 Integracin

7 Fin 26/06
8 Version release 2
9 Componente 4
10 Componente 5

11 Componente 6
12 Componente 7
13 Integracin
14 Fin 30/08
15 Version pre-release 3

Para esto deben considerarse factores como:

Estimacin del esfuerzo necesario para cada uno de los componentes.
Cantidad de recursos humanos disponibles y sus perfiles para definir qu tareas se pueden
realizar en paralelo y asignarlos a las tareas.
Secuencia de desarrollo segn el plan de versiones.
Comienzan a jugar aqu otras restricciones tales como el tiempo mximo de desarrollo, el
presupuesto disponible, el flujo de caja, etc.
Esto puede implicar que sea necesario redimensionar algunos de los equipos o paralelizar/serializar
algunas de las actividades
Por ejemplo, es posible que sea necesario aumentar el tamao de algn equipo para acortar la
duracin de alguna iteracin, o que sea necesario serializar tareas que lgicamente podran
realizarse en paralelo debido a la cantidad de recursos humanos disponibles, etc.
Esto adems debe compatibilizarse con una gran cantidad de otros factores externos que puedan
tener algn grado de influencia.

3.6 Proceso
Como conclusin, el proceso que planteo para la planificacin y gestin de un proyecto dirigido por
la arquitectura es el siguiente (ver figura final):

A partir de los requerimientos funcionales y no funcionales se disea la arquitectura del

producto mientras en paralelo se realiza la estimacin top-down del proyecto.
A partir de la arquitectura se realiza una estimacin bottom-up de cada uno de los componentes
identificados.
Se integran ambas estimaciones en la que se utilizar para la planificacin del proyecto.
Se realiza un nuevo anlisis de riesgo, incorporando a la arquitectura como fuente de posibles
riesgos que pueden afectar al proyecto. Algunos de los riesgos identificados pueden ocasionar
la toma de decisiones que afecten la arquitectura con lo que se repite el ciclo.
A partir de la arquitectura, los requerimientos o necesidades del usuario y del anlisis de riesgo,
se confecciona el plan de versiones.
A partir de la arquitectura, se organizan los equipos que participarn en el proyecto.
A partir del plan de versiones, del resultado del proceso de estimacin, de las tareas de
prevencin y de las decisiones tomadas a partir del anlisis de riesgo, y de los equipos previstos
se confecciona el cronograma. Algunas consideraciones en el momento de confeccionar el
cronograma para tener en cuenta todas las restricciones del proyecto pueden afectar la
organizacin de los equipos, con lo que se vuelve a iterar el ciclo hasta encontrar el punto de
equilibro.
Una vez definidos el plan de versiones y el cronograma, comienza la construccin del producto,
el cual se gestionar para mantenerlo dentro de lo previsto en los documentos obtenidos como
resultado del proceso descripto xxviii.
 Ing. de Proceso de planificacin y organizacin del proyecto basado en la arquitectura
Requerimientos
Integracin
de
Estimacin Top- estimaciones
Down

Estimacin Bottom-
Arquitectura Up

Plan de
Versiones Confeccin del Ejecucin
cronograma

Anlisis de
Riesgo

Organizacin de
los equipos

i
A guide to the Project Management Body of Knowledge (PMBOK), Project Management Institute
ii
Humphrey, W.S, Managing the software process
iii
Bass, Clements y Kazman 1998. Software Architecture in Practice. Massachusetts, USA. Addison Wesley.
iv
Soni D, Nord R y Hofmeister C, Software Architecture in Industrial Applications, en Proceedings of the
17th International Conference on Software Engineering, New York: ACM Press, 1995.
v
Davis Alan M., Software Life Cycle Models. Software Engineering project management, editado por
Richard H Thayer, 2 edicin. IEEE Computer Society Press, 1988
vi
Royce W.W., Managing the Development of Large Software Systems: Concepts and Techniques, Proc.
1970 WESCON Technical Papers, Vol. 14, 1970
vii
Hirsch E., Evolutionary Acquisition of Command and Control Systems, Program Manager, Nov. 1985.
viii
Giddings R.V, Accommodating Uncertainty in Software Design, Comm ACM, Vol 27, N 5, May 1984.
ix
Gomaa H y Scott D, Prototyping as a Tool in the Specification of User Requirements, Proc. 5th IEEE
International Conference on Software Engineering, IEEE CS Press, Los Alamitos, California, 1981.
x
Boehm B.W. A Spiral Model of Software Development and Enhancement, Computer, May 1988.
xi
Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon,
Software Engineering Institute, 2002.
xii
Boehm B, Software Engineering Economics, E Englewood Cliffs, NJ, Prentice Hall 1981.
xiii
Boehm B. et al, Software Cost Estimation with Cocomo II, Upper Saddel River, NJ, Prentice Hall, 2000.
xiv
Paulish D.J, Architecture-Centric Software Project Management, A practical guide, Carnegie Mellon,
Software Engineering Institute, 2002.
xv
KRUTCHEN Philippe. Noviembre 1995. The 4+1 View Model of Architecture. IEEE Software, 12(6).
xvi
Higuera R.P, Software Risk Management, CMU/SEI-96-TR-012 ESC-TR-96-012, Software Engineering
Institute (SEI), www.sei.cmu.edu
xvii
Grey S, Practical Risk Assessment for Project Management, John Wiley & Sons
xviii
Karolak D.W, Software Engineering Risk Management, IEEE Computer Society Press
xix
Michaels J.V, Technical Risk Management, Prentice Hall
xx
BASS L. et al. Quality Attribute Design Primitives. Technical Note CMU/SEI-2000-TN-017. Dic. 2000
xxi
BASS L., et al. Quality Attribute Design Primitives and the Attribute Drive Design Method. SEI, Carnegie
Mellon University, Pittsburgh.
xxii
MOUSQUES G. 2002. Transp. Curso de Arquitectura. Ing. de Sistemas, Universidad ORT, Uruguay.
xxiii
KAZMAN R. et al. Oct. 1999. Attribute Based Architectural Styles. Techn. Report CMU/SEI-99-TR022.
xxiv
Thayer R, Software Engineering Project Management
xxv
Rees F, Equipos de trabajo, Prentice Hall 1997
xxvi
Simons, Lucarelli, Work Breakdown Structures
xxvii
Gido, Clements, Network Planning and Scheduling
xxviii
Pinto J, Project Management Handbook, PMI