Diseño de Una Metodología Ágil de Desarrollo de Software
Diseño de Una Metodología Ágil de Desarrollo de Software
Metodologa gil de
Desarrollo de Software
Padrn: 75563.
Fecha de Examen:
Autor
Tutor
Marcelo Schenone
Pgina 2 de 184
Abstract
Esta tesis tiene como propsito la construccin de una Metodologa gil de
Desarrollo de Software la cual utiliza UML como notacin. Si bien podr ser empleada
en proyectos de distinto tamao y complejidad, su aplicacin tendr como objetivo
proyectos de pequea escala y riesgo limitado. Tambin ser independiente del lenguaje
o la arquitectura utilizada, as como del tipo de software que se est construyendo.
Marcelo Schenone
Pgina 3 de 184
Tabla de Contenidos
Diseo de una Metodologa gil de Desarrollo de Software.____________________ 1
Abstract _________________________________________________________________ 3
Tabla de Contenidos____________________________________________________ 4
Tabla de Contenidos Detallada ___________________________________________ 5
Prefacio______________________________________________________________ 8
Captulo I - Introduccin _______________________________________________ 10
Captulo II - Descripcin del Problema____________________________________ 39
Captulo III - Solucin Propuesta ________________________________________ 53
Patrones de Desarrollo Recomendados _______________________________________ 93
Enfoque Sistmico _______________________________________________________ 118
Aportes de AgEnD al Espectro Metodolgico_________________________________ 134
Marcelo Schenone
Pgina 4 de 184
Marcelo Schenone
Pgina 5 de 184
Pgina 6 de 184
Marcelo Schenone
Pgina 7 de 184
Prefacio
Esta Tesis de Grado fue realizada durante el perodo que va desde Agosto de
2001 hasta Abril de 2004.
La eleccin del tema surgi a partir de la investigacin del autor en relacin a los
Modelos de Proceso de Desarrollo observados en diversas materias de la carrera. A
medida que comenzaba la exploracin lleg a su conocimiento la metodologa eXtreme
Programming (XP) desarrollada por Kent Beck a las cuales se incorporaron muchas
cuales que conformaran el universo de metodologas giles. Dado el nfasis de las
mismas en cuestiones de Peopleware, Dinmica de Equipos, Psicologa Social, Calidad
del Proceso, el tema fue elegido como base para la construccin de una metodologa que
analizara estos aspectos, basndose en las mejores practicas de la industria e
incorporando aspectos interdisciplinarios tomados de la Psicologa, Sociologa,
Relaciones de Trabajo y Administracin. La idea de la misma era que pudiera ser
utilizada dentro de la realidad de la informtica en nuestro pas. As nace la presente
tesis que describe en detalle AgEnD, la metodologa gil que es motivo del presente
trabajo.
A fines del 2000, manteniendo conversaciones con el docente Sergio Villagra
en ese momento jefe de trabajos prcticos de la ctedra de Proyectos Informticos I de
la FIUBA quien mostr gran inters en el tpico elegido, se plante el ofrecimiento de
ste de trabajar como Tutor de la Tesis. Mediante la formalizacin del trmite de inicio
de la Tesis, comenz el arduo desarrollo que finalizara en el ao 2004.
Organizacin de la Tesis
La Tesis est organizada de la siguiente forma.
Marcelo Schenone
Pgina 8 de 184
Agradecimientos
Quisiera agradecer a las siguientes personas que han contribuido de una u otra
forma durante la elaboracin de la Tesis. Mis agradecimientos son para: Anbal Calligo,
Germn Boccoleri, Alejandro Oliveros, Elvio Nabot, Enrique Vetere, ngel Prez
Puletti, Adriana Yecha, Pablo Sametband, Adrin Lasso, Pablo Cosso. A mi Tutor,
Sergio Villagra.
Finalmente quisiera agradecer a mis padres, Olga y Jorge, quienes me ayudaron
incondicionalmente a que pudiera completar la misma. Asimismo hago extensivo el
agradecimiento a toda mi familia y dems personas que olvido en este momento
mencionar.
Marcelo Schenone
Pgina 9 de 184
Captulo I - Introduccin
Propsito detrs de esta Tesis
Para empezar a hablar de Ingeniera de Software daremos una definicin
aceptada por la industria, esta ha sido tomada de la IEEE Computer Society:
Marcelo Schenone
Pgina 10 de 184
Marcelo Schenone
Pgina 11 de 184
Marcelo Schenone
Pgina 12 de 184
del software (subsanando muchas de las falencias del modelo en cascada) mitigando los
riesgos en forma temprana. Los procesos iterativos de los cuales se desprenderan
diversas instancias, como son el modelo iterativo e incremental, el modelo en espiral, el
modelo basado en prototipo, el modelo SLCD, el MBASE, el RUP, etc.
Bsicamente, la postura de estos modelos es la de basar el desarrollo en
iteraciones e ir construyendo la aplicacin en forma progresiva, agregando
funcionalidad sucesivamente. Las iteraciones representan un mini-proyecto autocontenido el cual est compuesto por todas las fases del desarrollo (requerimientos,
diseo, implementacin, testing). Los incrementos estn dados por la funcionalidad que
se va agregando al software en forma iterativa. Gracias a estas iteraciones se logra entre
otras cosas obtener el feedback necesario del cliente que era frenado en el modelo en
cascada una vez se finalizaba la fase de requerimientos. Consecuentemente podemos
argumentar que los modelos iterativos fomentan el cambio en forma temprana y
proponen un control de cambio disciplinado que permita que el usuario ajuste sobre el
desarrollo sus requerimientos. Esto se contrapone a la intolerancia del modelo en
cascada para lidiar con dichos cambios.
Del modelo en espiral desarrollado por [Boehm, 1988] surgi una de las ideas
fundamentales que las metodologas posteriores adoptaran: el temprano anlisis de
riesgos. Como muestra la Figura 001 este modelo de carcter iterativo en sus primeras
fases, plantea la necesidad de realizar al principio diversas iteraciones dirigidas a
mitigar los riesgos ms crticos relevados en el proyecto mediante la realizacin de
prototipos o simulaciones de tipo desechables tendientes a probar algn concepto. Una
vez que esos prototipos son validados se suceden iteraciones del tipo: determinar
objetivos, evaluar, desarrollar, planear. Mediante estas iteraciones se procuraba el
feedback del que se hablaba anteriormente, en forma temprana. Una vez que se tena el
diseo detallado y validado por el cliente, se implementaba el software siguiendo las
etapas de un modelo en cascada. Esta es una falla importante del modelo ya que no se
acomoda a la posibilidad de cambios una vez que se inicia la construccin. Todas las
crticas que se le hacan al modelo en cascada se aplican a estas fases del modelo en
espiral.
Marcelo Schenone
Pgina 13 de 184
Figura 001. Descripcin de las iteraciones del Modelo en Espiral. Tomada de [Calligo, 2003]
Fue el mismo Barry Boehm, autor de este modelo, quien en su artculo [Boehm,
1995] describe tres hitos crticos a ser utilizados en cualquier proyecto de forma de
poder planificar y controlar el progreso del mismo, dando visibilidad a los stakeholders.
Estos hitos estn relacionados con las etapas de avance que se van dando a lo largo de
un proyecto de acuerdo al pasaje que ocurre de las actividades de ingeniera (que
componen los espirales del modelo en espiral) a las actividades de produccin (que
componen la construccin en cascada del software). Su impacto en la industria del
software ha sido tan importante que uno de los procesos mas utilizados en la actualidad,
el [RUP, 2002], los incorpora. Estos hitos son:
Marcelo Schenone
Pgina 14 de 184
El primer hito finaliza con la definicin del alcance del software a construir, la
identificacin de los stakeholders, y el delineamiento del plan de desarrollo del sistema.
El mismo ocurre al final de la fase de Concepcin segn el RUP.
El segundo hito finaliza con el delineamiento de la arquitectura del sistema, la
resolucin de todos los riesgos crticos del proyecto, y el refinamiento de los objetivos y
el alcance del sistema. A partir de este hito, se comienza la construccin en forma
masiva del sistema, llegndose a utilizar el mximo de recursos en el proyecto.
Asimismo, comienzan las fases ms predecibles en cierta medida del desarrollo. El
mismo corresponde al hito final de la fase de Elaboracin segn el RUP.
El ltimo de los hitos corresponde a la entrega del primer release del software,
que incorpora la funcionalidad definida en la correspondiente iteracin. Tambin se
espera el tener material de entrenamiento, como un Manual del Usuario y Manual de
Operaciones. Este hito se corresponde con el hito final de la fase de Construccin segn
el RUP.
Lo que result interesante de estos hitos propuestos por Boehm es que los
mismos son independientes del proceso de desarrollo elegido. Permiten una
estandarizacin de entregas a ser realizadas en un proyecto, la cual tiene ventajas para
ambas partes comprometidas. Para los clientes, los hitos otorgan visibilidad sobre el
proyecto pudiendo medir el progreso con artefactos que les son de utilidad. Para el
equipo de desarrollo, los hitos proveen una gua de las fases del proyecto orientada a los
entregables necesarios para cada hito as como la posibilidad de recibir feedback de los
clientes/usuarios sobre los productos que son entregados en el tiempo.
Como fue mencionado en los ltimos prrafos, uno de los procesos con ms
influencia en la comunidad del software ha sido el RUP. El mismo, derivado y refinado
por Rational a partir de la absorcin del Objectory de Jacobson tiene diferencias
radicales en comparacin con los procesos que lo han precedido. El RUP es uno de los
primeros procesos que es vendido como un producto1 y que es altamente customizable a
las circunstancias en que es adoptado. La idea de los creadores del RUP es que el
mismo fuera un repositorio de todas las ideas vigentes y las denominadas Best Practices
de la Ingeniera de Software. Dada la complejidad del mismo se presenta mediante los
Marcelo Schenone
Pgina 15 de 184
Marcelo Schenone
Pgina 16 de 184
que se estaba desarrollando, Beck decide tirar todo el cdigo y empezar de cero
utilizando las prcticas que l haba ido definiendo a lo largo del tiempo. El sistema, que
administra la liquidacin de aproximadamente 10.000 empleados, y consiste de 2.000
clases y 30.000 mtodos, es puesto en operacin en Mayo de 1997 casi respetando el
calendario propuesto [C3, 1998] [Williams, 2000]. Como consecuencia del xito de
dicho proyecto, Kent Beck dio origen a XP iniciando el movimiento de metodologas
giles al que se anexaran otras metodologas surgidas mucho antes que el propio Beck
fuera convocado por Chrysler.
Entre las metodologas giles ms destacadas hasta el momento podemos
nombrar:
XP Extreme Programming
Scrum
Crystal Clear
XBreed
Extreme Modeling
XP Extreme Programming
La primera metodologa ya ha sido comentada y es la que le dio conciencia al
movimiento actual de metodologas giles. De la mano de Kent Beck, XP ha
conformado un extenso grupo de seguidores en todo el mundo, disparando una gran
cantidad de libros a los que dio comienzo el mismo Beck en [Beck, 2000]. Inclusive
Addison-Wesley ha creado una serie de libros denominada The XP Series. Fue la misma
gente del proyecto C3 la que produjo tambin otro de los libros importantes de XP
Marcelo Schenone
Pgina 17 de 184
Marcelo Schenone
Pgina 18 de 184
Figura 002. Disposicin fsica de las oficinas bajo la distribucin cavernas y comn. Tomada de [Cockburn, 2001a]
Pgina 19 de 184
en una gran velocidad en el desarrollo. Sin embargo, una desventaja que deviene de esta
falta de documentacin es la incapacidad de persistir la arquitectura y dems cuestiones
de anlisis, diseo e implementacin, an despus de que el proyecto haya concluido.
El nfasis que pone en XP en las personas se manifiesta en las diversas prcticas
que indican que se deben dar ms responsabilidades a los programadores para que
estimen su trabajo, puedan entender el diseo de todo el cdigo producido, y mantengan
una metfora mediante la cual se nombra las clases y mtodos de forma consistente. La
prctica denominada Semana de 40 horas indica la necesidad de mantener un horario
fijo, sin horas extras ya que esto conlleva al desgaste del equipo y a la posible desercin
de sus miembros. Beck afirma que como mximo se podra llegar a trabajar durante una
semana con horas extras, pero si pasando ese tiempo las cosas no han mejorado
entonces se deber hacer un anlisis de las estimaciones de cada iteracin para que estn
acordes a la capacidad de desarrollo del equipo.
Scrum
Scrum define un proceso emprico, iterativo e incremental de desarrollo que
intenta obtener ventajas respecto a los procesos definidos (cascada, espiral, prototipos,
etc.) mediante la aceptacin de la naturaleza catica del desarrollo de software, y la
utilizacin de prcticas tendientes a manejar la impredictibilidad y el riesgo a niveles
aceptables. El mismo surge de un artculo de 1986 de la Harvard Business Review
titulado The New New Product Development Game de Takeuchi y Nonaka, que
introduca las mejores prcticas ms utilizadas en 10 compaas japonesas altamente
innovadoras. A partir de ah y tomando referencias al juego de rugby, Ken Scwaber y
Jeff Sutherland formalizan el proceso conocido como Scrum en el ao 1995.
Marcelo Schenone
Pgina 20 de 184
Marcelo Schenone
Pgina 21 de 184
Roles
Key Artifacts
Product Backlog
PO
Product Owner:
Set priorities
Sprint Goal
One-sentence summary
Declared by Product Owner
Accepted by team
SM
ScrumMaster:
Manage process,
remove blocks
Sprint Backlog
List of tasks
Owned by team
Only team modifies it
Blocks List
SH
Increment
Stakeholders:
observe & advise
Key Meetings
Sprint Planning Meeting
Hosted by ScrumMaster; 1 day
In: Product Backlog, existing
product, business & technology
conditions
1. Select highest priority items in
Product Backlog; declare Sprint Goal
2. Turn selected items into Sprint
Backlog
Out:: Sprint Goal, Sprint Backlog
Development Process
Product
Backlog
Increment
Hosted by ScrumMaster
Attended by all, but Stakeholders
dont speak
Same time every day
Answer: 1) What did you do
yesterday? 2) What will you do
today? 3) Whats in your way?
ScrumMaster updates Sprint
Backlog and Blocks List
Sprint:
30 days each
Sprint
Goal
Daily Scrum
Team: Develop
product
Daily Scrum
Sprint
Backlog
Daily Work
Blocks
List
Product
Increment
Hosted by ScrumMaster
Attended by all
Informal, 4-hour, informational
Team demos Increment
All discuss
Hold retrospective
Announce next Sprint Planning
Meeting
Product
Backlog
Figura 003. Descripcin de roles, artefactos, reuniones y proceso de desarrollo de Scrum. Cortesa de William C. Wake,
[email protected], www.xp123.com
Crystal Clear
Alistair Cockburn es el propulsor detrs de la serie de metodologas Crystal. Las
mismas presentan un enfoque gil, con gran nfasis en la comunicacin, y con cierta
tolerancia que la hace ideal en los casos en que sea inaplicable la disciplina requerida
por XP. Crystal Clear es la encarnacin ms gil de la serie y de la que ms
documentacin se dispone. La misma se define con mucho nfasis en la comunicacin,
Marcelo Schenone
Pgina 22 de 184
y de forma muy liviana en relacin a los entregables [Cockburn, 2001b]. Crystal maneja
iteraciones cortas con feedback frecuente por parte de los usuarios/clientes,
minimizando de esta forma la necesidad de productos intermedios. Otra de las
cuestiones planteadas es la necesidad de disponer de un usuario real aunque sea de
forma part time para realizar validaciones sobre la Interfase del Usuario y para
participar en la definicin de los requerimientos funcionales y no funcionales del
software.
Una cuestin interesante que surge del anlisis de la serie Crystal es el
pragmatismo con que se customiza el proceso. Las personas involucradas escogen
aquellos principios que les resultan efectivos y mediante la aplicacin de la metodologa
en diversos proyectos agregan o remueven principios en base al consenso grupal del
equipo de desarrollo.
Aunque al momento de preparar este trabajo an no se dispone de bibliografa
oficial de Crystal, Cockburn reporta su uso exitoso en diversos proyectos.
Pgina 23 de 184
DSDM define cinco fases en la construccin de un sistema ver Figura 004. Las
mismas son: estudio de factibilidad, estudio del negocio, iteracin del modelo funcional,
iteracin del diseo y construccin, implantacin. El estudio de factibilidad es una
pequea fase que propone DSDM para determinar si la metodologa se ajusta al
proyecto en cuestin. Durante el estudio del negocio se involucra al cliente de forma
temprana, para tratar de entender la operatoria que el sistema deber automatizar. Este
estudio sienta las bases para iniciar el desarrollo, definiendo las features de alto nivel
que deber contener el software. Posteriormente, se inician las iteraciones durante las
cuales: se bajar a detalle los features identificados anteriormente, se realizar el diseo
de los mismos, se construirn los componentes de software, y se implantar el sistema
en produccin previa aceptacin del cliente.
Marcelo Schenone
Pgina 24 de 184
Figura 004. Fases del proceso de desarrollo DSDM. Tomada de [Highsmith, 2002].
Descontando la primera fase que es realizada una nica vez al principio del
proyecto para analizar la factibilidad desde el punto de vista del negocio del desarrollo,
las dems fases presentan las caractersticas del modelo iterativo e incremental ya
tratado. Sin embargo, lo que diferencia a DSDM de dicho modelo son los principios
alrededor de los cuales se estructura y que hacen nfasis en los equipos de desarrollo, en
el feedback con el cliente, en las entregas frecuentes de productos.
Para resolver la cuestin de la aplicabilidad de DSDM a un proyecto convendr
responder las siguientes preguntas:
Ser la funcionalidad razonablemente visible en la interfase del usuario?
Se pueden identificar todas las clases de usuarios finales?
Es la aplicacin computacionalmente compleja?
Es la aplicacin potencialmente grande? Si lo es, puede ser particionada en
componentes funcionales ms pequeos?
Est el proyecto realmente acotado en el tiempo?
Son los requerimientos flexibles y slo especificados a un alto nivel?
Marcelo Schenone
Pgina 25 de 184
Las mismas refieren a las caractersticas que se deben cumplir en los proyectos
para poder utilizar el enfoque RAD de construccin. Se observa que aquellos proyectos
que califiquen afirmativamente de acuerdo a dichas preguntas tendrn las siguientes
caractersticas que refieren a la aplicabilidad de DSDM:
Acotados en el tiempo
De esta forma observamos que DSDM deja las bases sentadas para el anlisis
sobre su aplicabilidad a un espectro bien definido de proyectos de software. Sin
embargo, la metodologa no tiene ninguna prescripcin respecto a las tcnicas a ser
usadas en el proyecto, ni siquiera impone el desarrollo bajo un paradigma especfico
funciona tanto para el modelo de orientacin a objetos como para el modelo
estructurado. Algo que s sugiere el mtodo es la generacin de un conjunto mnimo de
modelos necesarios para la sana progresin de la entrega del software y facilidad en el
mantenimiento. Estos modelos esenciales debern ser definidos antes que comience el
desarrollo, y debern ser revisados en las sucesivas iteraciones para validad su
contenido.
El concepto de timebox es algo que est embebido en DSDM y en todas las
metodologas giles, en las cuales tambin se conocen como iteracin, ciclo, intervalo.
La consecuencia de utilizarlos es el feedback frecuente que brinda visibilidad a los
stakeholders para que verifiquen el progreso y puedan tomar acciones correctivas a
tiempo. Tambin permiten controlar la calidad de los productos intermedios que se van
generando, y realizar estimaciones de esfuerzo ms precisas. Asimismo, cada timebox
esta compuesta por actividades definidas en relacin a entregables en vez de tareas.
Marcelo Schenone
Pgina 26 de 184
Marcelo Schenone
Pgina 27 de 184
Marcelo Schenone
Pgina 28 de 184
Ejemplos:
El ciclo de vida propuesto por FDD se puede observar en la Figura 005 y est
compuesto por cinco procesos, dos de las cuales se realizan tantas veces como
iteraciones se planifiquen en el desarrollo.
Figura 005. Los cinco procesos dentro de FDD. Tomada de [Coad, 2000].
Marcelo Schenone
Pgina 29 de 184
Pgina 30 de 184
Figura 006. Reportando el progreso al management y al cliente en FDD. Tomada de [Coad, 2000].
Pgina 31 de 184
Marcelo Schenone
Pgina 32 de 184
Sin embargo, no es ms que una especulacin ya que el carcter adaptativo del proceso
permite pequeas desviaciones en un sentido por lo que Highsmith sugiere que cada
ciclo se componga de un mix entre funcionalidades crticas, tiles, y opcionales,
previendo los posibles retrasos que puedan existir mediante el movimiento de las
funcionalidades de menor prioridad a futuros ciclos y grandes desviaciones en otro,
las cuales son utilizadas para la exploracin del dominio y de la aplicacin, que puede
llevar a cambiar el rumbo del proyecto estos desvos est representado por las flechas
de divergencia en la Figura 007.
Marcelo Schenone
Pgina 33 de 184
es una propiedad de los sistemas adaptativos complejos que crea alguna propiedad ms
grande del todo (comportamiento del sistema) a partir de la interaccin entre las partes
(comportamiento auto-organizativo de los agentes). Gracias a esta propiedad los grupos
de desarrollo logran sacar lo mejor de si en la el borde del caos.
La fase final de ASD, Aprender, consiste en la revisin de calidad que se realiza
al final de cada ciclo. En la misma se analizan cuatro categoras de cosas para aprender
[Highsmith, 2000]:
Para evaluar la calidad desde el punto de vista del cliente se sugieren utilizar
grupos de enfoque en el cliente, mediante los cuales se explora un modelo de la
aplicacin y se anotan los requerimientos de cambio del cliente.
Las revisiones al diseo, al cdigo o a las pruebas permitirn aprender sobre la
calidad de los mismos. En este caso, el nfasis estar puesto en aprender cuales han sido
los errores o desvos y poder resolverlos, y no en encontrar culpables. Asimismo, est es
la etapa en que se evaluarn las exploraciones que se hayan realizado dando la
capacidad de poder modificar la arquitectura del sistema si se ha encontrado algn
camino que se ajusta mejor a lo que necesita el usuario o si han cambiado los
requerimientos.
El tercer proceso de feedback est relacionado con la interaccin entre las partes,
la dinmica de grupo, y las tcnicas empleadas. Para medir la performance y el grado de
cohesin del mismo, se podrn realizar al final de cada ciclo pequeas reuniones de
postmortem. En las mismas se discuten los aspectos del proceso que contribuyen al
desarrollo y aquellos que deben ser descartados por su influencia negativa.
En relacin al status del proyecto, se realizarn revisiones para determinar el
estado del mismo en relacin a lo planificado. En este momento, se detectarn posibles
diferencias que pueden surgir de la exploracin y que cambiarn el rumbo a que
apuntaba el proyecto.
Marcelo Schenone
Pgina 34 de 184
En la Figura 008 se puede ver el detalle interno de cada fase como ya fue
explicado, mostrndose con una flecha que trasciende las tres fases en sentido inverso,
el bucle de aprendizaje. Este bucle es algo crtico para ASD ya que denota un cambio en
el esquema tradicional de la vista de un sistema en que se tena un bucle de control para
detectar diferencias y corregirlas. Es decir, en las metodologas tradicionales las
diferencias respecto a lo planificado eran vistas como errores que deban ser
enmendados para que cumplieran lo pautado. ASD y las metodologas giles plantean la
necesidad de que el feedback necesario sea para aprender, nos da la posibilidad de
entender ms respecto al dominio y construir la aplicacin que mejor satisfaga las
necesidades del cliente. Highsmith lo expone claramente en la siguiente frase:
Figura 008. Actividades del ciclo de vida adaptativo. Tomada de [Highsmith, 2000].
Marcelo Schenone
Pgina 35 de 184
XBreed ofrece una de las primeras fusiones exitosas entre metodologas giles.
Tomando las fuerzas en el management de Scrum y unindolas con las prcticas de XP
nace una de las ms modernas metodologas alrededor del 2000. Mike Beedle es la
mente detrs de XBreed y su objetivo es tomar las mejores prcticas del universo gil y
unificar estas en un marco de trabajo que permita el desarrollo concurrente de mltiples
proyectos usando metodologas giles.
Al momento de escritura de esta tesis, existe muy poca informacin de XBreed,
salvo el sitio web oficial del mismo.
Pgina 36 de 184
Analizando los factores mencionados en detalle vemos que los mismos forman
parte esencial de las metodologas descriptas. En los mismos se plasman aquellas
razones que impulsaron a Beck, Highsmith, y otros, a construir metodologas giles. El
nfasis sobre las personas esta emblematizado en la primer oracin respecto a los
valores de las metodologas. El nfasis en el cdigo por sobre los documentos es una
propuesta eficaz para lograr el rpido feedback requerido por la agilidad. La
participacin del cliente es fundamental para el xito de los proyectos ya que ellos
definen la funcionalidad a construir y guan el desarrollo de las pruebas funcionales. La
importancia de responder al cambio indica que el desarrollo de software no es ms que
un proceso de aprendizaje en que cada cambio nos permite conocer ms en detalle el
dominio de la aplicacin.
El autor entiende que para que se pueda definir a AgEnD como una metodologa
gil, la misma deber estar completamente circunscripta a los valores detallados en el
Manifiesto. Es por esto que se harn continuas referencias al mismo para comentar la
conformidad del proceso a los principios y valores.
Con esto, damos por concluida la introduccin de este documento. A partir de
ahora, nos centraremos en la descripcin de AgEnD, su aplicabilidad en el desarrollo de
software, sus valores, principios, y toda la informacin necesaria para poder utilizarla en
la prctica; posteriormente, plantearemos un caso de estudio de AgEnD en donde se
pueda observar y analizar sus fuerzas y sus debilidades; finalmente, se llevaran a cabo
aquellas conclusiones relevantes al desarrollo de la AgEnD, analizndose las
limitaciones y alcances de la misma, previendo posibles lneas de trabajo que se puedan
desprender en relacin a las metodologas giles y el Manifiesto que las nuclea.
Presentacin de AgEnD
Marcelo Schenone
Pgina 37 de 184
Marcelo Schenone
Pgina 38 de 184
Marcelo Schenone
Pgina 39 de 184
Es decir, si una empresa est interesada en que cada proyecto sea como una
aventura, en que se desconozca el resultado y existan una gran cantidad de riesgos, no
necesitar proceso alguno. Simplemente dejar en manos de los profesionales de
sistemas el desarrollo de proyectos mediante las tcnicas que utilice cada individuo en
su trabajo. La aleatoriedad de cada proyecto ser una caracterstica inherente. Se
realizarn planificaciones a muy corto plazo, ya que no existe visibilidad para las
personas externas al equipo de desarrollo. En conclusin, estamos hablando de todas las
organizaciones que se encuentran en el nivel 1 del CMM, el denominado nivel Inicial.
Indudablemente, cualquier organizacin que se precie de ser tal jams elegira este
enfoque como primera instancia ya que uno de los objetivos de la misma sera
maximizar ganancias a largo plazo y para esto debera mantener procesos que aseguren
el xito en todos los sectores en que est compuesta. Sin embargo, como veremos ms
adelante la mayora de las empresas termina eligiendo esta opcin sin ser plenamente
conciente de la eleccin y de los resultados que esta acarrea.
Por otro lado, encontramos organizaciones que poseen manuales de
procedimientos para cada una de las tareas relacionadas con el desarrollo de software.
Cada actividad realizada por cada persona est descripta en detalle en forma escrita y en
cualquier momento esta documentacin podr ser consultada si tienen dudas respecto a
algn punto del proceso. En general, estas organizaciones poseen una estructura
Marcelo Schenone
Pgina 40 de 184
Marcelo Schenone
Pgina 41 de 184
RUP
Completo
Modelo en
Cascada
Burocracia
~ Orden
Codificar
y Probar
RUP
Agilizado
RAD
Metodologas
giles
Modelo en
Espiral
Adhocracia
~ Caos
Modelo por
Prototipos
Pgina 42 de 184
estas, las personas son de primera magnitud y se prefiere sacrificar el proceso en pos de
darles libertad a las personas. Sin embargo, esto no significa que se termina en un
proceso de Codificar y Probar, liderado por programadores rebeldes que se pasan el da
generando cdigo. Es por esto que el punto en que se ubican las mismas est bastante
alejado del Caos en que la aleatoriedad es la norma. Otra cuestin que diferencia estos
procesos de los anteriores es el cambio existente entre un proceso emprico y un proceso
determinista o definido. Como mencionbamos antes, los procesos ms burocrticos
tienden a tener definidos todos los aspectos del desarrollo. Esto se contradice con la
naturaleza compleja del software, para lo cual se adaptara con mayor eficiencia un
proceso emprico. Por esto nos referimos a un proceso en que se desconocen muchos
aspectos, se reconocen a las personas como componentes de primer orden totalmente
impredecibles, y simplemente se intenta guiar el desarrollo hacia un objetivo que puede
no permanecer constante en el tiempo a medida que aumenta el conocimiento de la
aplicacin a ser construida. En los procesos empricos se conocen las buenas prcticas
probadas con la experiencia, y los resultados u outputs que surgen generalmente de
tomar ciertos inputs o de realizar ciertas actividades. Estos modelos surgen de la
observacin y la experiencia obtenida a lo largo de los aos, sin basarse en leyes de la
naturaleza o principios tericos fundamentados. Es por esto que se los asocia a un
enfoque pragmtico para desarrollar software.
Siguiendo por la recta nos encontramos con el enfoque RAD propuesto por
[Martin, 1991] en el que se tena un lenguaje de alto nivel lo suficientemente poderoso
como para permitir generar cdigo de forma rpida, un pequeo equipo trabajando en
conjunto con buenos canales de comunicacin, y un plan de entregas de funcionalidad
en forma iterativa. El mismo no posea pautas claras en relacin a la calidad del
producto, la satisfaccin de los requerimientos de los usuarios, la clara definicin de la
arquitectura del sistema. Por estas causas termin siendo asociado con la generacin
rpida de aplicaciones con bajos niveles de calidad, y que resultaban en pesadillas de
mantenimiento. Sin embargo, debemos reconocer el aporte que hicieron a la ingeniera
de software ya que gracias a estas resurgieron las herramientas CASE y comenz el uso
masivo de lenguajes de alto nivel, sirviendo como base para el posterior advenimiento
de las metodologas giles.
Finalmente, nos encontramos justo en las cercanas del Caos, al modelo
Codificar y Probar. Esto modelo, catico por excelencia, se basa en el siguiente flujo de
Marcelo Schenone
Pgina 43 de 184
Corolarios
Del anterior anlisis deberemos tener en cuenta ciertos aspectos inherentes a los
proyectos de desarrollo, que incidirn en forma directa en el grado de predictibilidad de
la metodologa. Es decir, que dadas ciertas variables deberemos movernos en uno u otro
sentido por la recta de la Figura 009.
Una variable muy importante a tener en cuenta es la cantidad de personas
involucradas. Es algo natural pensar que a medida que aumenta la cantidad de personas
asignadas a un proyecto deberemos contar con metodologas ms pesadas tendientes a
suplir la falta de canales anchos de comunicacin entre los integrantes del equipo de
desarrollo. Es por esto que la mayor parte de las metodologas giles dejan claro un
tamao mximo del equipo de desarrollo para utilizarlas exitosamente (en caso de tener
equipos de desarrollo ms grandes se recomienda particionarlos en equipos ms
pequeos). Alistair Cockburn [Cockburn, 2000] muestra este aspecto esencial a la hora
de elegir una metodologa mediante la Figura 010.
Marcelo Schenone
Pgina 44 de 184
Figura 010. Relacin entre cantidad de personas, criticidad, y tamao de la metodologa. Tomada de [Cockburn, 2001a].
Marcelo Schenone
Pgina 45 de 184
Marcelo Schenone
Pgina 46 de 184
Experiencia en aplicaciones
Factores comunicacionales
Experiencia en la plataforma
El nfasis de todas las metodologas giles esta centrado en los individuos y sus
interacciones, a diferencia de las metodologas tradicionales en que impera el proceso y
las herramientas como propulsores de la calidad. AgEnD no es ninguna excepcin a
estos principios y propone destacar en cada una de sus prcticas que las personas son las
Marcelo Schenone
Pgina 47 de 184
que indudablemente decidirn sobre la mejor forma de trabajo para ellas. Tambin de
las personas depender la adopcin de AgEnD o cualquier proceso de desarrollo gil. Es
por esto, que ms adelante se define un rol en particular, el Coordinador, que se encarga
de mantener las prcticas de AgEnD en armona, durante las primeras iteraciones en que
se utiliza el proceso.
Consideraciones Humanas
El hecho que AgEnD base sus principios en las personas no significa que se han
resuelto todos los problemas del desarrollo y que teniendo un buen equipo el xito est
garantizado. Todo lo contrario, el nfasis propuesto requiere tomar ciertas
consideraciones en relacin a la naturaleza de las personas que no son necesarias en las
metodologas tradicionales. Partimos de la base formulada por [Cockburn, 1999] que las
personas son organismos vivientes impredecibles, inconsistentes pero con buena
voluntad y un sentido de hacer las cosas bien. De esto concluimos que la Figura 010
extrada del [RUP, 2002]2 establece ciertas suposiciones que han sido esenciales en las
prcticas tradicionales de management basadas en la ideologa de Command and
Control.
Figura 011. Descripcin de un workflow dentro del RUP. Tomada de [RUP, 2002].
2
La seleccin de la figura del RUP y el comentario posterior no intenta realizar ninguna referencia a la naturaleza de dicho
framework.
Marcelo Schenone
Pgina 48 de 184
Marcelo Schenone
Pgina 49 de 184
Realizando una analoga con el testing, se podra considerar que AgEnD aplica
lo que denominaremos desarrollo de caja negra mientras que las metodologas
tradicionales utilizan el desarrollo de caja blanca. El primero refiere a la nocin de
tomar ciertas entradas y verificar las correspondientes salidas. El segundo refiere a
tomar ciertas entradas, analizar el proceso interno y verificar las correspondientes
salidas. Las metodologas tradicionales al considerar a las personas como partes
reemplazables de un desarrollo, definen en detalle entradas, salidas y tareas necesarias
para llevar a cabo la correspondiente transformacin. Consecuentemente, estas
metodologas proponen que basta con tener una clara definicin de las tareas en un
proyecto para garantizar el xito del mismo. Un WBS nos provee la seguridad necesaria
para avanzar en las sucesivas etapas, en el cual describiremos que tareas son necesarias,
que necesita cada una para comenzar, y con que artefactos finalizan. Considerando a las
personas como componentes predecibles y reemplazables, engranajes de una
maquinaria, el desarrollo de caja blanca se convierte en la forma ms adecuada de
llevar un proyecto al xito en organizaciones orientadas al proceso. Ejemplos de esto se
observan en los proyectos de software encarados por el departamento de defensa y
aquellas grandes organizaciones en las que se tienen niveles de madurez certificados por
el CMM.
Una de las razones principales por la que las metodologas giles son Orientadas
a los Productos es el principio de Mxima Comunicacin descrito en ms detalle en
las Caractersticas de AgEnD. Dada la necesidad de tener un feedback continuo por
parte del cliente, el nfasis de cualquier iteracin esta puesto en los artefactos que esta
genera. Las actividades necesarias para la transformacin de entradas en salidas queda a
discrecin del equipo de desarrollo pudiendo utilizar las tcnicas provistas por AgEnD
que proporcionan agilidad al proceso. Para lograr que el desarrollo de caja negra tenga
xito deberemos tener un equipo integrado, balanceado y altamente motivado. De estos
tres factores, es la motivacin la que nos permitir lograr mejores resultados en la
adopcin de un proceso gil. Es la motivacin la que logra sacar lo mejor de un equipo
de desarrollo; la que nos permite saber que las personas involucradas utilizarn las
tcnicas que les sean ms efectivas para llegar al final de la iteracin con los artefactos
ms crticos construidos de acuerdo a las estimaciones. La motivacin es por lejos la
mayor contribuyente a la productividad [Boehm, 1981].
Marcelo Schenone
Pgina 50 de 184
Desarrollo Iterativo
Dado el avance de la tecnologa, los tiempos en que se manejan los negocios han
ido reducindose abismalmente. Lo que una dcada atrs demoraba una semana de
procesamiento computacional, hoy se resuelve en cuestin de minutos. Los tiempos de
procesamiento han ido disminuyendo, mientras que los sistemas han ido creciendo en
complejidad teniendo cada vez necesidades mayores de distributibilidad, seguridad,
mantenibilidad, flexibilidad, etc.
En el panorama actual en que se encuentra la industria de IS/IT los sistemas
deben contar con atributos jams pensados en sistemas tiempo atrs. Palabras como:
multiprocesamiento, sistemas distribuidos, middleware, web services, modelo en tres
capas, tolerancia 24x7, multiplataforma, Virtual Machine, son requerimientos no
funcionales tpicos de sistemas de software/hardware en la actualidad. Los nuevos
clientes de los actuales sistemas esperan tener su sistema en el menor tiempo posible,
con la mxima calidad y conforme a los requerimientos no funcionales necesarios para
la operatoria diaria del negocio.
Una de las tareas ms complejas en el desarrollo de sistemas representa la
determinacin del alcance de lo que se va a construir. Es decir, qu es lo que recibir el
cliente en cada release del producto. Que funcionalidad estar incluida? Cmo
asegurarnos que es esa la funcionalidad que resuelve las necesidades del cliente?
Existen innumerable cantidad de ejemplos en la industria de sistemas de proyectos con
extensos perodos de relevamiento, que fueron seguidos por tambin extensos perodos
de oscurantismo durante los que el cliente no tena feedback alguno del desarrollo. En
general, el resultado de estos proyectos era el fracaso ya que la aplicacin no cumpla
con las necesidades del usuario. El sndrome del IKIWISI (Ill Know It When I See It)
entraba en juego, y al no tener feedback alguno del lado del cliente la construccin se
llevaba a cabo sobre las especificaciones definidas en forma temprana.
Si tomamos la teora existente detrs del Modelo en Cascada, la misma no haca
ms que reflejar las teoras encontradas en las otras ingenieras. En estas ltimas, los
proyectos comenzaban con fases de ingeniera en que se constataba la factibilidad de los
proyectos, se sentaban las bases para la produccin y se mitigaban los posibles riesgos
que podan ocurrir. Una vez que se tena una cierta masa crtica de conocimiento, se
Marcelo Schenone
Pgina 51 de 184
Marcelo Schenone
Pgina 52 de 184
Caractersticas de la Metodologa
Para dar una primera aproximacin a AgEnD nos basaremos en la propuesta de
Alistair Cockburn [Cockburn, 1998] que desglosa una metodologa en 10 elementos,
como mnimo, enumerados a continuacin:
Marcelo Schenone
Pgina 53 de 184
2. Destrezas las destrezas que presupone poseen los recursos que llevan a cabo el
proyecto. Por ejemplo: social, proactivo, hbil en el manejo de herramientas,
3. Entregables lo que se quiere que cada persona o equipo entregue a otra
persona o equipo: casos de uso, especificaciones de diseo, documentacin de
framework, diagramas de secuencia.
4. Actividades las actividades e hitos de los diferentes equipos, como se integran
para producir los entregables finales.
5. Valores los valores del equipo y de la propia metodologa.
6. Equipos la forma en que se agrupan a las personas.
7. Asignacin de Tareas cmo son asignadas las tareas a los mltiples roles.
8. Tcnicas las tcnicas que se espera que las personas utilicen en su trabajo
diario. Por ejemplo: sesiones JAD, programacin en Java, modelado de
componentes.
9. Herramientas las herramientas que las personas usan a diario, ya sea dentro
de una tcnica o para producir un entregable de acuerdo al estndar.
10. Estndares lo que est o no permitido en el diseo y los entregables. Esto
incluye notacin, convenciones del proyecto y cuestiones de calidad.
Marcelo Schenone
Pgina 54 de 184
Roles definidos
Una de las razones principales de la adopcin de una metodologa para
desarrollo consiste en la definicin de las tareas que sern llevadas a cabo por los
individuos que participan del proyecto. Los roles definen ese conjunto cohesivo de
actividades realizadas y artefactos mantenidos que son llevados a cabo por personas o
por grupos de personas. No slo se refieren a personas internas al desarrollo del
software, sino que tambin involucran a los usuarios u otras personas que se vean
afectadas por el proyecto, cualquiera de los denominados stakeholders.
Los roles recin mencionados no son roles exclusivos asociados a una nica
persona, aunque en algunos casos pueden serlo (Patrocinante). Algunos roles podrn ser
abarcados por ms de una persona (Desarrollador). Asimismo, una persona podr cubrir
ms de un rol (Arquitecto/Escritor Tcnico).
Las asignaciones sern llevadas a cabo por el Lder, el cual en base a las
aptitudes de los recursos que dispone repartir las tareas a ser realizadas en cada
iteracin.
Como punto de partida en la definicin de roles dentro de AgEnD,
enumeraremos brevemente cada uno, con una descripcin concisa de las actividades que
abarcan:
Marcelo Schenone
Pgina 55 de 184
Marcelo Schenone
Pgina 56 de 184
Experto en
el Dominio
Patrocinante
Lder de
Proyecto
Equipo de
Desarrollo
Administrador
del
Conocimiento
Figura 012. Flujos de comunicacin durante el proyecto entre los roles propuestos.
Coordinador (Mentor)
Actividades: tiene a su cargo la supervisin del proceso, y cualquier
actividad orientada al mejoramiento del mismo. Durante las primeras
etapas de utilizacin de AgEnD supervisar la implementacin del
proceso.
Importancia del rol: en las metodologas giles este rol permite reforzar
la adherencia al proceso en aquellos momentos en que se el tiempo
apremia y se suele caer en el modelo Codificar y Probar.
Destrezas: el Experto en el Dominio deber conocer en detalle el negocio
para prestar respuesta a cualquier duda que pueda surgir del mismo.
Marcelo Schenone
Pgina 57 de 184
Arquitecto (Architect):
Actividades: tiene a su cargo la definicin de la arquitectura que guiar el
desarrollo, y de la continua refinacin de la misma en cada iteracin;
deber construir cualquier prototipo necesario para probar aspectos
riesgosos desde el punto de vista tcnico en el proyecto; definir los
lineamientos generales del diseo y la implementacin.
Importancia del rol: la arquitectura es imprescindible en los proyectos de
software actuales en donde cada vez existe mayor complejidad; el
arquitecto puede ser considerado como el Experto en la parte tcnica del
desarrollo y debe mantener a todo el equipo en conocimiento de los
lineamientos fundamentales de la construccin.
Destrezas: el Arquitecto deber tener una buena formacin tcnica,
contar con experiencia en las herramientas y tcnicas utilizadas; aptitudes
comunicacionales son deseadas para que la arquitectura sea comunicada
a todos los miembros del equipo; tambin deber ser perseverante en
conseguir los hitos tcnicos planteados mediante entregables para
asegurar el progreso de la construccin.
Marcelo Schenone
Pgina 58 de 184
Tester:
Actividades: tiene a su cargo la generacin de pruebas funcionales a
partir de los requerimientos extrados por los Analistas.
Importancia del rol: la importancia del Tester radica en la necesidad de
construir un software de calidad que cumpla con los requerimientos del
usuario; mediante la utilizacin de un proceso y el armado de un grupo
cohesivo de desarrollo, se tienen prcticas para garantizar la calidad en el
producto desde el punto de vista tcnico. Sin embargo, para asegurarnos
de que la aplicacin satisface las necesidades del usuario deberemos
realizar todo tipo de pruebas de carcter funcional. Es ah en que entra en
juego el Tester, quien crea, ejecuta, analiza y mantiene el conjunto de
pruebas automatizadas y manuales que son utilizados.
Destrezas: el Tester deber tener amplio conocimiento de tcnicas de
testing, deber conocer a fondo la aplicacin que testear. Asimismo,
Marcelo Schenone
Pgina 59 de 184
Aptitudes Requeridas
Uno de los principios esenciales que mencionamos al principio de esta tesis, era
el de Mxima Comunicacin. Este principio estableca la necesidad de un continuo
aprendizaje del equipo de trabajo, que deba ser transmitido en forma rpida a todos los
involucrados.
Ahora bien, algo que estaba implcito en la enunciacin del principio era el
hecho de disponer de recursos dispuestos y capacitados para aprender. No alcanza con
sentar a todas las personas en una misma habitacin para lograr la fluida comunicacin
3
Como se observa por estudios diversos de Gartner, Forrester, entre otros. Las dos plataformas que eventualmente comprendern el
mayor porcentaje de los futuros desarrollos, Java y .NET, estn construidos sobre lenguajes orientados a objetos los cuales basan su
Marcelo Schenone
Pgina 60 de 184
tpica de los procesos giles. Tambin es necesario que esas personas estn dispuestas a
sacrificar su individualidad en pos de un grupo cohesivo de desarrollo. De esta forma,
se logra un entendimiento que abarca extensamente el alto grado de complejidad
inherente al software.
Suponiendo una situacin hipottica en la que una empresa ha conseguido un
proyecto a ser implementado utilizando AgEnD, y debe contratar a todos los recursos
para el mismo, mencionaremos qu aptitudes seran necesarias segn los roles
propuestos por la metodologa.
Patrocinante
En relacin al Patrocinante, deberemos requerir simplemente un total e
incondicional apoyo al proyecto, debiendo negociar siempre a favor de la construccin
del software y su implantacin en la empresa. En este sentido, no se agrega nada en
particular al conocimiento planteado por la bibliografa existente sobre Ingeniera de
Software.
Experto en el Negocio
El Experto en el Negocio debe ser una persona con amplio conocimiento del
dominio de la aplicacin que pueda concebir una visin lo suficientemente amplia del
producto a ser entregado para poder guiar el proceso de desarrollo. No ser necesario
que el experto en el dominio sepa en detalle toda posible operatoria del sistema; sin
embargo, deber contar con el suficiente conocimiento para poder resolver cualquier
duda o dificultad que tengan los miembros del equipo de desarrollo respecto a los
requerimientos. Tambin deber contar con la autoridad requerida para definir
prioridades respecto a los casos de uso a ser implementados en cada iteracin, pudiendo
agregar funcionalidad que no estaba contemplada o descartando funcionalidad que
perdi valor para el negocio.
Existir una estrecha relacin entre el Experto en el Negocio y los Analistas,
encargados de realizar los casos de uso. Durante las iteraciones del desarrollo, se
necesitar una total disponibilidad del Experto para la redaccin de los casos de uso as
como una frecuente predisposicin a contribuir en el desarrollo subsecuente.
Marcelo Schenone
Pgina 61 de 184
Lder
En el caso del Lder, deberamos contratar a una persona que:
Pgina 62 de 184
Coordinador
El Coordinador es aquella persona que esta ntimamente ligada con el proceso,
que conoce todas las prcticas involucradas y entiende el porqu de los principios de la
misma. AgEnD propone que el nfasis debe centrarse en las personas en vez del
proceso, lo cual parecera contradecir la existencia del Coordinador. Pero esto no es as
ya que en caso que no exista un responsable del proceso, dada la naturaleza gil del
mismo, se puede terminar fcilmente en el modelo de codificar y probar.
Su tarea consiste en reforzar la conviccin de la necesidad de continuar con las
prcticas y principios de AgEnD aun en los momentos ms crticos del proyecto. El
equipo de desarrollo debe estar convencido plenamente de que las prcticas optimizan
el desarrollo, y no que resultan un obstculo del que deben deshacerse rpido. Es en
estos momentos en que se ve la importancia del Coordinador. Otra circunstancia en la
que resulta til su presencia, es ante la incorporacin de nuevos recursos, a los que el
Coordinador capacitar para que puedan ajustarse rpidamente sin que esto perjudique
el normal funcionamiento del grupo. Una vez que el grupo de trabajo se siente ya
cmodo con la metodologa, el Coordinador puede desaparecer como tal y ser
reemplazado por algn miembro del equipo.
Analista
El Analista cumple un rol similar a la figura de Analista Funcional con la que se
define este empleo en la industria del software. Es el encargado de realizar el
relevamiento, identificando previamente a los actores stakeholders que deber relevar
para entender el dominio del problema. En dicho relevamiento se incluir al Experto en
el Negocio, los Usuarios y dems stakeholders del proyecto, y posteriormente se
plasmarn los requerimientos funcionales y no funcionales en especificaciones de casos
de uso.
Una de las aptitudes necesarias del Analista es la de entender a los Usuarios, la
de ser una persona lo suficientemente humilde como para reconocer que no tiene
experiencia en el dominio y que debe pedir que se le explique cmo es la normal
operatoria del negocio para poder capturar su esencia. El Analista es una persona
versada en tpicos de Ingeniera de Software, con amplios conocimientos de tcnicas de
relevamiento, especificacin de requerimientos, y manejo de cambios, que posee
bastante conocimiento sobre el negocio en el que opera el Cliente, quien financia el
Marcelo Schenone
Pgina 63 de 184
proyecto4. En respuesta a esto AgEnD mantiene con firmeza un principio que consiste
en uno de los pilares de las metodologas giles, el de Mxima Comunicacin.
Arquitecto
El arquitecto es aquella persona encargada de dirigir y coordinar los aspectos
tcnicos del desarrollo, proveyendo de coherencia a los diversos artefactos generados en
relacin al anlisis, diseo, implementacin, testing y despliegue. Deber estar
comunicado con el resto del equipo para transferir los conceptos arquitectnicos ms
relevantes a aquellos que los necesiten, y al mismo tiempo para absorber los detalles
tcnicos que debern ser incluidos en la arquitectura. No ser necesario que conozca en
detalle cada componente construido, o documento generado, ya que para ello estn las
personas responsables de los mismos. Si deber mantener una visin general de las
partes tcnicas del desarrollo, permitiendo de esta forma ir ajustando la arquitectura
candidata de acuerdo a lo que la implementacin de los casos de uso revele.
Algunas aptitudes bsicas que se pediran son:
4
Cabe mencionar que si esta condicin no se da, implicar un alto riesgo para el proyecto ya que la persona encargada de
especificar lo que el sistema debe realizar no conoce los procesos del negocio. Una forma de mitigar este riesgo es mediante la
realizacin de una disciplina de Modelado del Negocio [RUP, 2002].
Marcelo Schenone
Pgina 64 de 184
Programador
El Programador es aquella persona que tiene a su cargo la codificacin de los
componentes en cdigo fuente en algn lenguaje de alto nivel, y la correspondiente
prueba unitaria de los servicios que los mismos proveen. Para esto deber tener un
profundo conocimiento del lenguaje, las herramientas utilizadas en la construccin, los
estndares de codificacin, el framework de testing utilizado, patrones de diseo a
aplicar y nociones de refactoring.
El Programador es la persona encargada de la construccin del sistema
propiamente dicha. Deber ser capaz de estimar la duracin de las tareas que le son
asignadas, incluyendo el testing unitario de las clases que genera. Si bien al principio
pueden resultar imprecisas las estimaciones dentro de AgEnD, con el tiempo los
Programadores se acostumbrarn al ritmo gil que imprime el proceso pudiendo lograr
gran precisin en las mismas.
Tester
Dada la importancia del testing en el proceso como forma de asegurarse que la
calidad forme parte del producto, deberemos contar con una persona dedicada a
verificar los requerimientos del usuario mediante casos de prueba que debern ser
creados en forma paralela con el desarrollo.
Si bien una parte del testing de AgEnD ser realizada por los Programadores en
forma de pruebas unitarias sobre el cdigo construido, la porcin de testing ms
relevante para las partes involucradas se refiere a las pruebas funcionales. Y estas
debern ser construidas por el Tester que deber tener una estrecha comunicacin con el
Cliente ya que ser ste quien defina el contenido de las mismas.
Entre otras cosas el Tester deber contar con el suficiente conocimiento tcnico
como para poder entender la arquitectura del sistema, de forma de generar el cdigo
fuente de las pruebas funcionales necesarias para el sistema. Tomando como base los
casos de uso generados por los Analistas su funcin ser la de transformarlos en casos
Marcelo Schenone
Pgina 65 de 184
de prueba. Estos casos de prueba estarn compuestos por dos componentes principales:
cdigo fuente y documentacin. Para el primer enfoque se llevarn a cabo programas
que verificarn la correcta realizacin de los casos de uso va la interaccin de las clases
que lo realizan. El segundo enfoque refiere a documentar procedimientos de prueba, que
consisten en instrucciones tcnicas necesarias para probar un componente.
Tcnicas
Las tcnicas propuestas por AgEnD son tcnicas que han sido adoptadas por la
industria para atacar la complejidad de las distintas fases del desarrollo. Las mismas
sern mencionadas brevemente; en caso que el lector desee profundizar en alguna podr
hacerlo a travs de la bibliografa propuesta al final de la tesis.
Dadas las caractersticas de los proyectos giles, definiremos las tcnicas que
ms se ajustan a esta filosofa y que colaboran al desarrollo de las tareas que son
encaradas en cada iteracin. Debido a esto, no se mencionarn en este resumen tcnicas
que si bien han sido probadas durante los aos son de dudosa trazabilidad en relacin a
las dems fases, o bien generan un overhead demasiado costoso para proyectos de estas
magnitudes.
Las tcnicas propuestas sern mencionadas en relacin a las fases en que se
divide AgEnD.
Fases e Hitos
Marcelo Schenone
Pgina 66 de 184
Marcelo Schenone
Pgina 67 de 184
Kick-off
Concepcin
Elaboracin
Objetivos
Arquitectura
Transicin
Release
Marcelo Schenone
Pgina 68 de 184
Iteracin
Construccin
Marcelo Schenone
Pgina 69 de 184
Kick-off
Factibilidad
Implementacin
Testing
Despliegue
Factibilidad
Durante la disciplina de Factibilidad se produce el primer contacto entre el
equipo de desarrollo y el cliente. Esta disciplina permite al equipo de desarrollo adquirir
todo el conocimiento posible acerca del dominio, las necesidades de los usuarios, los
objetivos y expectativas que debe cumplir el software que est siendo construido.
Mediante las actividades incluidas en esta disciplina, seremos capaces de responder las
siguientes preguntas: Es conveniente construir la aplicacin? Es conveniente para el
cliente el desarrollar un sistema con todas las complejidades inherentes para satisfacer
las necesidades del usuario? Cules son las posibles soluciones que se pueden
plantear?
A medida que se ejecuta esta disciplina, se va realizando el Modelado del
Dominio tendiente a entender las operaciones que forman parte del dominio del
problema, el dominio manejado por el cliente. En forma conjunta, los analistas
comenzarn a entender el problema planteado comenzando a bosquejar cules son los
features que tendr el sistema y el arquitecto comenzar a realizar modelos y diagramas
Marcelo Schenone
Pgina 70 de 184
Diseo
Iteracin
Requerimientos
Anlisis
Exploracin del
Exploracin de la
Problema
Solucin
Modelado del
Dominio
Arquitectura
Preliminar
Aceptacin
del Cliente
Ejecucin
Planificacin
de Iteraciones
Marcelo Schenone
Pgina 71 de 184
Requerimientos-Anlisis
Una vez completadas las actividades dentro de la disciplina de Factibilidad,
comienza el desarrollo netamente iterativo. Las iteraciones se suceden mediante la
realizacin de actividades relacionadas con las subsiguientes disciplinas. A
continuacin, explicaremos en detalle la primera disciplina con que comienzan las
iteraciones de AgEnD.
En la disciplina de Requerimientos-Anlisis se realizan actividades tendientes a
capturar las necesidades de los stakeholders, transformar las mismas en features de alto
nivel y especificarlas posteriormente en casos de uso. Como se observa en la Figura 016
se deber especificar el espectro funcional el cual servir para que los desarrolladores
diseen e implementen los casos de uso y tambin el espectro no funcional que
Marcelo Schenone
Pgina 72 de 184
Espectro
Espectro No
Funcional
Funcional
Captura de
Requerimientos
Requerimientos
No Funcionales
Restricciones
Modelado de
Casos de Uso
Diagramas de
Anlisis/Diseo
Reglas del
Negocio
Documento de
Requerimientos
Suplementarios
Marcelo Schenone
Pgina 73 de 184
Diseo
La disciplina de Diseo consiste en plasmar el problema planteado (que se halla
en forma de casos de uso o requerimientos contenidos implcitamente por Analistas o
Clientes) en el dominio de la solucin. Asimismo, tambin se realiza la definicin de la
arquitectura siendo validada mediante algn prototipo (conocidos como Proof Of
Concept).
Marcelo Schenone
Pgina 74 de 184
Espectro
Espectro No
Funcional
Funcional
Modelo de Casos
de Uso
Documento de
Requerimientos
Suplementarios
Definicin de la
Arquitectura
Diseo Casos de
Uso
Prototipo Proof Of
Concept
Pgina 75 de 184
Implementacin - Testing
En la disciplina de Implementacin-Testing se lleva a cabo la produccin del
software. El equipo de desarrollo se encarga de implementar la funcionalidad
especificada en los casos de uso mediante el lenguaje de programacin elegido.
Dado el nfasis que AgEnD propone en reducir la brecha comunicacional entre
las personas que forman el equipo, esto mismo repercute en la preferencia de elegir para
proyectos de esta envergadura aquellos lenguajes de programacin que minimicen la
brecha entre la realidad y la realizacin de la misma en un lenguaje. Idealmente, AgEnD
fomenta el uso de frameworks o tecnologas bajo el paradigma de orientacin a objetos,
como Java, MS. NET o Smalltalk, los cuales permiten el mximo de eficiencia por lnea
de cdigo para aplicaciones de IS/IT. Segn se observa en la Tabla de Lenguajes de
Programacin incluida dentro de la seccin de Anexos de esta tesis y relevada por
[Jones, 1997], los lenguajes de este tipo permiten una menor cantidad de lneas de
cdigo por puntos de funcin, maximizando as la productividad del desarrollador.
En paralelo a la construccin de los componentes se realiza la revisin de los
mismos mediante el testing, el cual tiene una gran relevancia en AgEnD. Siendo est
una de las maneras en que se llevan a cabo los mecanismos de SQC (Software Quality
Marcelo Schenone
Pgina 76 de 184
Control), la metodologa define diversas pruebas que podrn ser realizadas en las
iteraciones. Las mismas incluyen:
Pruebas Unitarias:
Definicin: las Pruebas Unitarias son pruebas realizadas a nivel de las
clases y mtodos construidos para la aplicacin. Estas pruebas son
implementadas por los mismos programadores en el lenguaje de
programacin utilizando clases de prueba encargadas de verificar el
comportamiento correcto de los mtodos en una clase. Para ello es
conveniente contar con algn framework de testing unitario que le
facilite al equipo de desarrollo la creacin, mantenimiento y ejecucin de
una suite de pruebas automatizadas. Ejemplos de esto pueden leerse en
[Beck, 2002][Crispin, 2002][JUnit, 2001].
Alcance: las mismas son utilizadas para controlar la calidad del cdigo
construido y son ideales para testing de integracin y de regresin.
Pruebas Funcionales:
Definicin: las Pruebas Funcionales verifican el flujo de interaccin de la
funcionalidad definida en los casos de uso. Esta funcionalidad que est
escrita en forma narrativa en los casos de uso y es plasmada mediante la
interaccin de objetos envindose mensajes entre s en los diagramas de
secuencia debe ser especificada en pruebas automatizadas que sern
creadas por el Usuario en conjuncin con la ayuda tcnica del Tester y
sern ejecutadas por el Tester durante cada iteracin. Cabe remarcar que
debe ser el Usuario el que define el contenido de las mismas ya que de
esta forma proveen el feedback que permite al equipo de desarrollo
continuar las iteraciones asegurndose de la calidad del producto
construido.
Alcance: las mismas son utilizadas durante todo el desarrollo y su
alcance est definido por el conjunto completo de requerimientos
funcionales definidos en los casos de uso.
Marcelo Schenone
Pgina 77 de 184
Pruebas de Aceptacin:
Definicin: el objetivo de las Pruebas de Aceptacin es la verificacin
que el software construido en las iteraciones cumple con las
funcionalidades solicitadas por el usuario y est listo para ser utilizado en
el ambiente del Cliente. Estas pruebas revisten gran relevancia porque
implican que el Cliente da conformidad respecto al sistema desarrollado
y lo acepta
Alcance: las mismas son realizadas durante las Iteraciones con Release
en las que se lleva a cabo la transicin de la aplicacin al ambiente de
produccin en el Cliente.
Despliegue
La disciplina de Despliegue permite que el sistema construido sea transferido al
ambiente de produccin para ser utilizado por el usuario. Esto no significa que el
software debe estar implementado en su totalidad, cubriendo el 100% de los aspectos
funcionales y no funcionales sino que en una iteracin determinada se desee liberar una
versin con un porcentaje de los casos de uso implementados. Dado el esquema de
desarrollo iterativo e incremental, durante las iteraciones ya mencionadas se va
agregando funcionalidad y se hace crecer al sistema hasta que cumpla con los
requerimientos que se especificaron al principio, sumados a los cambios surgidos a lo
largo del desarrollo.
Durante esta disciplina, se deben realizar actividades tendientes a hacer una
entrega completa con una funcionalidad previamente determinada la cual ser
desplegada en produccin. Las actividades incluidas dentro de esta disciplina son:
Marcelo Schenone
Pgina 78 de 184
Iteracin
1
Iteracin
2
Iteracin
3
Iteracin
N
Reuniones de
Entrega de
Versin
Figura 018. Esquema cronolgico de reuniones de entrega de una versin del sistema.
Marcelo Schenone
Pgina 79 de 184
Disciplinas de Soporte
Las disciplinas de soporte ocurren a lo largo de todo el ciclo de vida del proyecto
y dan soporte a las actividades relacionadas con la construccin del software. Las
mismas son tan importantes como las disciplinas ya mencionadas pero la diferencia es
que sirven propsitos organizacionales no directamente relacionados con la produccin
de sistemas. Entre estas nuevas disciplinas mencionaremos cuatro como muestra la
Figura 019.
Iteracin
1
Iteracin
2
Iteracin
3
Iteracin
N
Administracin de Proyectos
Administracin de la Configuracin
Administracin del Proceso
Administracin de Personas
Administracin del Conocimiento
Administracin de Proyecto
Marcelo Schenone
Pgina 80 de 184
Marcelo Schenone
Pgina 81 de 184
Administracin de la Configuracin
La disciplina de Administracin de la Configuracin contiene las actividades
relacionadas con la administracin del repositorio que almacena los tems de
configuracin generados en un proyecto. Esta es un rea de conocimiento dentro de la
Ingeniera de Software en la que mayores avances se han realizado y que ha estado
presente en los proyectos de software desde aproximadamente 1980. Actualmente la
mayor parte de los desarrollos incluyen alguna herramienta de manejo de SCM que
automatiza todas las operaciones sobre el versionado.
AgEnD recomienda colocar todos los artefactos generados o consumidos en un
proyecto bajo control de configuracin. Esto permitir que en cualquier momento se
pueda recuperar una versin determinada de un tem o tems de configuracin para
recrear la cronologa del proyecto o volver cambios atrs, o llevar a cabos registros de
trazabilidad y/o auditorias entre otras cosas.
En particular, el uso de una herramienta de SCM le da la posibilidad al equipo
de desarrollo de tener prcticas eficientes al momento de realizar las actividades en un
proyecto. Entre estas prcticas cotidianas presentadas en cualquier desarrollo podemos
mencionar:
Marcelo Schenone
Pgina 82 de 184
Los desarrolladores pueden volver a una versin anterior del sistema para
hacer pruebas contra esta.
Marcelo Schenone
Pgina 83 de 184
estar
informado
sobre
las
novedades
de
la
Alianza
gil
5
El Proceso Unificado de Rational [RUP, 2002] incluye a las actividades de customizacin de proceso dentro de la disciplina de
Ambiente en la que tambin aparecen todas las consideraciones humanas. En AgEnD decidimos dividirla en dos partes:
Administracin de Proceso y Administracin de Personas.
Marcelo Schenone
Pgina 84 de 184
Cabe remarcar que la tarea de adaptacin del proceso es llevada a cabo por el
Coordinador en cooperacin con el equipo de desarrollo. Esto resulta muy relevante ya
que ser este ultimo el usuario final de la metodologa por lo cual el Coordinador
consultar con los miembros ms especializados para entender los mecanismos de
desarrollo involucrados.
Una vez que la metodologa haya sido configurada para un proyecto, se harn
reuniones espordicas (una buena prctica consiste en coordinarlas con el fin de cada
iteracin) en las que se evaluar la adecuacin de AgEnD a las caractersticas del
proyecto. Se analizarn los resultados positivos y negativos, pudiendo el Coordinador
hacer cambios sobre la marcha para mejorar la forma de trabajo.
Finalmente, cuando el proyecto est llegando a su fin, el Coordinador, con la
ayuda del Administrador de Conocimiento, almacenar la informacin acerca de cmo
el proceso fue usado, con el propsito de mantener un historial de adaptaciones
realizadas por tipo de proyecto.
Administracin de Personas
La ltima de las disciplinas recomendadas por AgEnD es la de Administracin
de Personas que agrupa todas aquellas actividades relacionadas con los aspectos
humanos del desarrollo. Nuevamente la figura clave de esta disciplina ser el
Coordinador, con una importante cooperacin del Lder de Proyecto.
Una de las primeras actividades dentro de esta disciplina es la de nivelar a los
miembros del equipo de desarrollo. Es importante que cada uno tenga todos los
conocimientos necesarios para encarar las actividades por las que es responsable. El
Coordinador deber llevar a cabo talleres de capacitacin y mentoring hasta asegurarse
de que las personas han aprendido. Esta capacitacin refiere tanto a aspectos tcnicos
como a los relacionados con las dems disciplinas de AgEnD, incluyendo la descripcin
del proceso.
Otra de las actividades que ser realizada en forma conjunta con el Lder de
Proyecto es mantener la salud del equipo de desarrollo. En otras palabras velar porque
la motivacin del equipo sea alta, garantizar relaciones interpersonales positivas,
minimizar las fricciones debidas a distintos tipos de personalidad, entender a cada
Marcelo Schenone
Pgina 85 de 184
individuo para poder sacar lo mejor de s mismo. Existe un solapamiento entre esta
disciplina y la de Administracin de Proyectos en este punto. Se destaca que el mismo
no es tan importante desde un punto de vista conceptual pero la diferencia est marcada
en que las actividades de esta disciplina tienen como objetivo el bienestar de las
personas en el proyecto mientras que el management se relaciona con la consecucin
exitosa del proyecto.
La prctica recomendada para esta disciplina tiene que ver con el patrn de
Mxima Comunicacin que ser descrito ms delante. Es decir, si tenemos canales de
comunicacin suficientemente ricos las dificultades podrn ser resueltas, en la mayora
de los casos, utilizando el sentido comn y la buena predisposicin de la gente.
Marcelo Schenone
Pgina 86 de 184
Artefactos
Herramienta de administracin de contenido, desarrollada por Ward Cunningham. Permite de manera sencilla la carga, edicin,
borrado y visualizacin de cualquier tipo de contenido a travs de la web. Ms informacin en http://www.swiki.org
Marcelo Schenone
Pgina 87 de 184
Documento de Visin:
Definicin: el Documento de Visin es realizado durante la fase de
Concepcin y sirve como contrato entre el Cliente y el Equipo de
Desarrollo respecto a lo que se va a construir. En la Visin debern
identificarse los stakeholders del proyecto, la totalidad de features del
sistema a ser construido y los requerimientos suplementarios que se
detectaron en forma temprana. En forma optativa podr incluirse un
resumen de los casos de uso crticos del aplicativo.
Responsable: la Visin es construida por un Analista Funcional en
conjunto con el Lder de Proyecto. La misma debe ser mantenida para
reflejar los cambios al alcance durante el proyecto.
Plan de Proyecto:
Definicin: el Plan de Proyecto es un documento mantenido por el Lder
de Proyecto con toda la informacin de gestin. El mismo suele incluir
un Gantt con el cronograma y las tareas del proyecto. Dependiendo del
nivel de formalidad se generar un WBS y/o algn otro tipo de plan a
incluirse dentro de este (plan de testing, de comunicaciones, de
administracin de requerimientos, de administracin de cambios, etc.). El
Plan de Proyecto es creado en forma temprana durante la Concepcin y
actualizado durante las fases posteriores.
Marcelo Schenone
Pgina 88 de 184
Lista de Riesgos:
Definicin: la Lista de Riesgos se utiliza para capturar los riesgos ms
relevantes que se presentan en el proyecto, y para poder monitorearlos,
asignarles prioridad, impacto y probabilidad de ocurrencia. Sirve para
planificar las iteraciones y para tener en vista aquellos riesgos que, por su
criticidad, debern ser mitigados lo ms tempranamente posible.
Responsable: el Lder de Proyecto es el responsable y el principal
consumidor de este documento y deber mantenerlo actualizado hasta la
terminacin del proyecto.
Marcelo Schenone
Pgina 89 de 184
Descripcin de la Arquitectura:
Definicin: el documento de Descripcin de la Arquitectura tambin
conocido como SAD especifica los aspectos tcnicos de la solucin
propuesta por el equipo de desarrollo. Sirve como medio de
comunicacin entre el Arquitecto y el equipo en relacin a cmo debern
ser implementados los casos de uso de la aplicacin.
Responsable: el Arquitecto es el principal responsable por la realizacin
de este artefacto, as como la creacin de un prototipo ejecutable (Proof
of Concept) que valide que la misma cumpla los requerimientos no
funcionales y las cualidades sistmicas que hacen a los atributos de
calidad no relacionados directamente con las necesidades del usuario.
Casos de Prueba:
Definicin: los Casos de Prueba contienen la especificacin de cmo ser
validado el sistema. Estos son realizados basndose en los casos de uso y
planteando todos los escenarios posibles que stos pueden contener.
Dado que puede ser bastante burocrtico realizar la totalidad de Casos de
Prueba existentes en un sistema, se recomienda generar los ms
importantes y despus anotar las variantes en un Caso de Prueba
Estndar.
Marcelo Schenone
Pgina 90 de 184
Scripts de Despliegue:
Definicin: los Scripts de Despliegue son necesarios para la instalacin
del producto en un entorno determinado. El mismo automatiza las tareas
de empaquetamiento, versionado, compilacin, etc. Un ejemplo muy
utilizado baja la plataforma J2SE es la herramienta ANT, que permite
generar scripts de despliegue con bastantes funcionalidades.
Responsable: algn Programador ser responsable de la generacin y
mantenimiento de estos scripts.
Planilla de Incidentes:
Definicin: la Planilla de Incidentes ser utilizada para registrar y tener
seguimiento de aquellos bugs, mejoras, tareas que el Tester o alguna
persona de aseguramiento de la calidad necesite reportar. Son los
denominados sistemas de Issue Tracking
que
pueden
ser
Marcelo Schenone
Pgina 91 de 184
Nota de Entrega:
Definicin: la Nota de Entrega sirve para especificar aquello que se le
entrega al Cliente en un release determinado de la aplicacin. En la
misma se constatar el nmero de versin, los cambios de la versin
anterior, los bugs conocidos y las mejoras efectuadas.
Responsable: cualquier miembro del equipo de desarrollo que vaya a
entregar algn artefacto al Cliente deber crear la correspondiente Nota
de Entrega.
Marcelo Schenone
Pgina 92 de 184
Marcelo Schenone
Pgina 93 de 184
Mxima Comunicacin
Las metodologas giles solo tienen sentido si existe comunicacin entre las
personas. Esto no solo refiere a las personas del equipo de desarrollo, sino a todas las
personas que se vean afectadas en distinta medida por la ejecucin del proyecto; los
denominados durante esta tesis como stakeholders.
Bajo el patrn de Mxima Comunicacin se encuentra uno de los principios
esenciales de AgEnD. Relacionado estrechamente con una de las actividades ms
comunes de los seres humanos: la comunicacin que representa las diversas formas de
transmisin de datos/informacin/conocimiento/experiencia entre individuos.
El software se encuentra entre los elementos de mayor complejidad creados por
el hombre. Dada esta complejidad inherente a su esencia, el software presenta una gran
dificultad en su construccin caracterizada por la aleatoriedad de las posibilidades en el
desarrollo de cualquier sistema y la incapacidad de concebir procesos repetibles como
ocurre en las dems ingenieras. Si bien se han logrado muchos avances en cuanto al
manejo de dicha complejidad, la misma an persiste y genera resultados no deseados
como cronogramas excedidos, baja calidad o funcionalidad incompleta.
Existen dos tipos de comunicaciones que este proceso toma en cuenta para
mejorar el desarrollo. Estas comunicaciones difieren en relacin a las personas
involucradas en las mismas. La primera es la comunicacin interna, es decir la
comunicacin entre todos los integrantes del equipo de desarrollo desde el lder del
proyecto hasta el programador. La segunda comunicacin a la que nos referiremos es la
comunicacin entre los integrantes del equipo de desarrollo y el cliente o usuario del
sistema. Es decir, todas las comunicaciones que el equipo mantenga con los
stakeholders. En la figura 020, tenemos una representacin grfica de los niveles
presentados en este prrafo.
Marcelo Schenone
Pgina 94 de 184
Esta divisin nos permite concentrarnos en las prcticas que podrn ser aplicadas
en cada caso. Analizaremos las formas de atacar el desarrollo de manera de maximizar
la comunicacin entre las partes involucradas acorde al contexto en que se plantean.
Tomando los principios que guan a AgEnD, continuamente se priorizan las
personas sobre el proceso. La metodologa debe proveer mecanismos que fomenten las
interacciones ayudando a mejorar la motivacin y la productividad del equipo de
desarrollo. De esta forma el flujo de informacin entre las mentes de los desarrolladores
ser maximizado permitiendo mayor progreso en el proyecto. Alistair Cockburn
[Cockburn, 2001a] analiz este fenmeno en detalle evaluando el impacto de distintos
modelos comunicacionales. La Figura 021 muestra la influencia en la efectividad de la
comunicacin de acuerdo al canal que se utiliza para establecer la misma.
Marcelo Schenone
Pgina 95 de 184
Comunicacin Interna
La primera recomendacin que podemos tomar tiene que ver con el patrn de
Mnima Dispersin Fsica. Segn este patrn el equipo de desarrollo debe estar
colocado fsicamente en una nica oficina que tenga una distribucin centralizada al
momento de trabajo con lugares privados para cuestiones extra laborales. Esta es la
propuesta de XP la cual no hace ms que obedecer al canal de comunicacin ms rico
que es ver a las personas cara a cara para interactuar con ellas.
Asimismo otro patrn denominado Interrupciones Mnimas que refiere a la
necesidad de liberar al equipo de desarrollo de interrupciones referidas a otros mbitos.
En principio, se recomienda que la oficina del equipo de desarrollo este separada
mediante paredes del resto de la organizacin. Si esto no se logra, se tendrn flujos de
informacin que no refieren al desarrollo y que empeorarn la calidad del ambiente
diseado para maximizar la comunicacin como planteaba el primer patrn
mencionado. Tom DeMarco [DeMarco, 1987] indaga bastante sobre los efectos nocivos
de mantener entornos de trabajo con mucho ruido e informacin innecesaria que atenta
contra el trabajo de las personas.
Marcelo Schenone
Pgina 96 de 184
Diagramas de Arquitectura
Comunicacin Externa
Tan importante como la comunicacin interna resulta la comunicacin con los
stakeholders del proyecto. Primero debemos dividir a los stakeholders en dos franjas:
stakeholders claves para el xito del proyecto y stakeholders normales. Los stakeholders
Marcelo Schenone
Pgina 97 de 184
claves sern aquellos que poseen conocimiento del dominio del sistema a construir. Son
aquellos que aceptarn el sistema en cuestin si el mismo se adeca a sus necesidades.
Por otro lado, tenemos los stakeholders normales con los que el equipo interacta
ocasionalmente para algn propsito del proyecto. Estos ltimos juegan un rol que
puede tener importancia para la salud del proyecto pero que no impacta directamente
sobre la funcionalidad de la aplicacin construida.
AgEnD recomienda maximizar la comunicacin con los stakeholders claves del
proyecto. En el caso ideal se recomienda utilizar el patrn On-Site Customer derivado
de XP que establece que durante todo el proyecto habr un cliente real sentado en la
misma oficina con el equipo de desarrollo, dispuesto a responder preguntas, resolver
disputas, y priorizar las tareas llevadas a cabo. Cabe destacar que en este caso un
cliente real refiere a una persona que utilizar el sistema una vez puesto en
produccin y que conozca la aplicacin en su extensin para resolver distintas
cuestiones que puedan darse.
Ocurre que en la mayora de los casos los clientes tienen que hacer sus propios
trabajos y no disponen de tiempo para estar continuamente formando parte del equipo
de desarrollo. Dadas las realidades impuestas en la mayor parte de los proyectos,
AgEnD propone disponer de un cliente designado con el rol de Experto en el Dominio
mencionado anteriormente. El mismo debe estar dispuesto a contestar cualquier
pregunta del equipo de desarrollo ya sea mediante algn canal de comunicacin ms
fro de acuerdo a la Figura 021 (ej.: telfono, videoconferencia, mail, etc.) en un tiempo
razonable que no debera superar algunas horas. En caso de que el problema requiera de
una comunicacin ms personal, el cliente deber disponer de tiempo para visitar al
equipo de desarrollo y discutir el tema personalmente o bien para recibir a algn
miembro clave en sus propias oficinas.
El nfasis est puesto en mantener el proceso lo ms gil posible, y dado que la
recomendacin es construir casos de uso que manifiesten las interacciones a un nivel no
muy detallado siempre existirn dudas que podrn ser mitigadas por los Expertos en el
Dominio.
Respecto a los stakeholders normales, la recomendacin es que los mismos sean
identificados en forma temprana y sus necesidades sean relevadas para verificar que el
sistema conforme a estos adecuadamente. Si bien no ser necesario tener un canal
Marcelo Schenone
Pgina 98 de 184
abierto tan flexible la comunicacin con estos debe ser fluida y honesta ya que en algn
punto el sistema tendr influencia sobre ellos o viceversa.
involucramiento por parte de los usuarios y el poco apoyo del management estn entre
los factores antes mencionados. Si se analiza este hecho concluimos que es lgico
establecer que si el usuario no participa en la construccin del software nunca este
ltimo va a satisfacer sus necesidades por ser el usuario el nico que las conoce. En
otras palabras,
Para lograr esta activa participacin del usuario deberemos poder contar con
usuarios expertos en el dominio que puedan prestar todo el tiempo necesario para las
necesidades del equipo de proyecto. Entre estas se incluye la posibilidad de que los
analistas puedan delinear requerimientos con el grado de detalle necesario para que los
Marcelo Schenone
Pgina 99 de 184
Estimaciones giles
Al estar Orientadas a los Productos, las metodologas giles permiten realizar
estimaciones de menor granularidad en el da a da para obtener ms precisin en la
estimacin de la entrega de artefactos en cada iteracin, en detrimento de una
visibilidad a largo plazo. Sin embargo, es importante realizar estimaciones realistas de
la duracin de los proyectos sobre todo al principio de los mismos.
La tcnica que propone AgEnD es la estimacin por puntos de caso de uso (use
case points). La misma mide a los sistemas desde una perspectiva funcional y es
independiente de la tecnologa. Sin tener consideracin del lenguaje, mtodo de
desarrollo, o plataforma de hardware utilizada, el nmero de puntos de casos de uso de
un sistema permanecer constante. La nica variable es la cantidad de esfuerzo
necesario para desarrollar un conjunto dado de puntos de caso de uso; por lo tanto el
Anlisis por Puntos de Caso de uso puede ser utilizado para determinar si una
herramienta, un ambiente, un lenguaje es ms productivo comparado con otros dentro
de una organizacin o entre organizaciones. Este es uno de los puntos crticos y uno de
los valores ms importantes de dicho anlisis. El mtodo de puntos de caso de uso est
cubierto y detallado en [Ribu, 2001].
Dentro de los proyecto de implementacin bajo el alcance de AgEnD, el objetivo
es poder hacer una estimacin de la funcionalidad a ser entregada en cada etapa en
funcin de la productividad del equipo de desarrollo. AgEnD requiere que la persona
responsable de un producto, ya sea una clase, un caso de uso o un documento de
administracin de la configuracin, realice la estimacin. Esto va en contra de las
metodologas tradicionales en las que es el lder de proyecto el encargado de realizar
Marcelo Schenone
todas las estimaciones del proyecto. En los procesos giles, al reconocer que las
personas son lo ms importante del desarrollo las mismas adquieren ms
responsabilidad en relacin a los productos que entregan, debiendo estimar la duracin
del desarrollo en cada iteracin. Esto no quiere decir que los Programadores estarn a
cargo de hacer la estimacin del proyecto completo - el Lder ser el que lo realice
consultando a todos los miembros del equipo, ya que este es responsable por la
concrecin del proyecto entero - pero si sern responsables por los productos que
construyen durante las tareas que realizan todos los das.
AgEnD fomenta el concepto de estimacin descentralizada. Cada persona
estimar el fruto de sus tareas por la tcnica que considere necesaria. Una consecuencia
de esto es que las personas no sienten que se les ha impuesto un cronograma al que
deben atenerse pudiendo ser reprendidas en caso de retrasos. El responsable de un
producto es la persona ms adecuada para medir su ritmo y estimar los tiempos
necesarios. Al principio esto podr resultar difcil para aquellas personas acostumbradas
a tener fechas y tareas impuestas desde arriba, pero ah es donde entra en juego el
Coordinador para capacitar a los miembros del equipo y perfeccionarlos en las
estimaciones futuras.
La estimacin para una iteracin dada ser realizada durante la iteracin previa,
de forma de tener la planificacin aprobada por el cliente previo a embarcar en las
actividades correspondientes al equipo en el desarrollo. Esta estimacin ser efectuada
por todo el equipo junto al cliente y en la misma ser validada la funcionalidad a ser
prximamente construida.
Enfoque en la Arquitectura
Una de las ideas propuestas por AgEnD consiste en una temprana definicin de
la arquitectura del sistema. La arquitectura no es un concepto que pueda ser explicado
en un par de palabras. Consiste ms bien en una suma de aspectos que estn
relacionados con el diseo de un sistema.
Ya sea que estemos construyendo un edificio, una prensa hidrulica o un
software empaquetado, debemos tener algn elemento de alto nivel que refleje las
decisiones que se van tomando en relacin al diseo de la construccin. Haciendo un
Marcelo Schenone
organizacin lgica
funcionalidad
concurrencia
Arquitectura gil
A continuacin detallaremos cul es el propsito de la arquitectura en el marco
del proceso gil propuesto, cmo se construye y cmo se mantiene.
Marcelo Schenone
Marcelo Schenone
Figura 021. El costo relativo de reparar un defecto en diferentes fases del ciclo de vida. Tomada de [Leffingwell, 2001].
Figura 022. Curva del costo de cambio a los requerimientos en diferentes fases del ciclo de vida. Tomada de [Beck,
2000].
Marcelo Schenone
Figura 023. Tasas de cambio a los requerimientos en proyectos de software respecto al tamao funcional de los mismos.
Tomada de [Larman, 2003].
La premisa propuesta por AgEnD consiste en tener un proceso gil que tenga
alta tolerancia al cambio y que permita que la curva del costo de cambio propuesta por
Boehm no escale exponencialmente en la mayora de los casos. AgEnD sugiere que en
los proyectos se tenga una grfica como muestra la Figura 024. En la figura hay dos
curvas: la nmero 1 que crece exponencialmente al igual que la original de Boehm y en
la que se manifiestan los cambios relacionados con aspectos que involucran altos
riesgos como la arquitectura candidata del sistema, mientras que en la curva nmero 2
que es bastante achatada pondramos todos los cambios relacionados a la funcionalidad
del sistema los cuales pueden ser absorbidos en las distintas iteraciones mediante el
feedback continuo con el cliente.
La idea de AgEnD es tratar de mover todos los cambios a la curva nmero 2
(idealmente ese el postulado de XP, que plantea que la curva del costo de cualquier
cambio es la curva nmero 2), pero reconoce que existen distintas aspectos que
implican un alto costo al cambio una vez que se avanza en el desarrollo. Para aquellos
factores que revisten las caractersticas de la curva nmero 1 AgEnD sugiere una
definicin previa al inicio del desarrollo en gran escala y establece al Documento de
Arquitectura como el repositorio de estas cuestiones.
Marcelo Schenone
Figura 024. El costo del cambio actualizado para una metodologa gil. Tomada de [Poppendieck, 2003].
Sin embargo, dadas las caractersticas del proceso resulta burocrtico desarrollar
un documento de grandes proporciones que gue el proceso con las decisiones ms
importantes del diseo, que incorpore extractos de los diversos aspectos que son
reconocidos como esenciales para el desarrollo y que sea actualizado en cada iteracin
para servir a su propsito.
Pero antes de esto deberamos analizar, siendo que el propsito de la arquitectura
es la comunicacin de aspectos esenciales del software entre las partes involucradas o
stakeholders, no se ve reducido drsticamente su alcance dada la estrecha
comunicacin propuesta por la metodologa? En otras palabras, al combinar el principio
de Mxima Comunicacin con el de Arquitectura gil, debemos cambiar la definicin
de arquitectura tradicional ya que la misma no coincide con las prcticas propuestas.
El principio de Arquitectura gil en AgEnD consiste en mantener una visin
nica, formulada por el equipo de proyecto de las decisiones consideradas crticas para
el desarrollo. Ser el mismo equipo el encargado de construir, mantener y obtener los
beneficios de la misma. En consecuencia, la arquitectura no va a ser un documento
esttico con una estructura determinada a la cual el equipo se deba ajustar aunque no
contribuya al desarrollo. Ir evolucionando con el desarrollo de los componentes y ser
mantenida hasta el punto que contribuya a la comunicacin de los aspectos tecnolgicos
dentro del grupo. Una vez que el conocimiento est en las mentes de todos, la misma
habr cumplido su funcin y el documento podr ser dejado a un lado. Esto es as
Marcelo Schenone
Marcelo Schenone
Figura 025. Diagrama de Despliegue de alto nivel en UML. Tomada de [Sun, 2003].
Marcelo Schenone
httpd.conf
mod_j k.so
Tomcat 4
Messenger
Database
SQL Serv er
Configuration
JBoss 3.0
messenger.ear
Configure() : void
Restart() : void
Marcelo Schenone
jsp page
servlet
:MessagePage
:SaveMessageServlet
:Message
:TransmissionManager
:Contact
:SmtpGateway
:FaxGateway
:PersistanceManager
Staff Member
Send Message()
doPost(response,request)
setSender(sender)
sendMessage(message)
getRecipients()
getPrimaryContactMethod(contactMethod)
getEmailAddress()
sendMessage(messsage,emailAddress)
getFaxNumber()
sendMessage(message,faxNumber)
makePersistent(message)
The message is In
Transit when it has
left the Messenger
System for an
external recipient.
Compose
Composed
Save
Send
Cancel
Sent
Sav ed
Transmit via
Gateway [External
Contact]
In Transit
Send
Reach Recipient
Discarded
Deliv ered
Read
Read
Restore Delete
This occurs when
the message is
removed from
Deleted Items.
Deleted
Purge
Archiv ed
Purged
Marcelo Schenone
Staff Member
-
Account
+Owner
Name: char
Email Address: char
1
Cell Phone: int
Fax: int
Address Line 1: char
Address Line 2: char
City/Town/Suburb: char
Post Code: char
State/Province: char
Country: char
Public Key: char
IsGranted
+Manages
#ManagedBy
1..*
Name: char
#Recipient
+Stores
Sends
Message
Folder
-
#Sender
Status: char
Receives
+StoredIn
+IsReceivedBy
0..* +IsSentBy 0..*
1..*
0..*
Message
Subject: char = Blank
Body: char
Sender: char
Recipient: char
Marcelo Schenone
Se debe tener en cuenta que debe existir un balance entre el esfuerzo en realizar
estos diagramas y la posibilidad de comunicar dichas ideas en forma directa. De
acuerdo al patrn de Mxima Comunicacin conviene que estos diagramas estn en
algn radiador de informacin ya sea mediante impresiones en hojas grandes colgadas,
en una intranet de administracin de conocimiento, o simplemente dibujados en
pizarrones en los casos que se desee ms informalidad. Una vez que el propsito
comunicacional es servido no tiene sentido seguir detallando y/o manteniendo estos
diagramas.
Integracin Continua
Indudablemente una de las prcticas que hoy se encuentra recomendada por la
mayor parte del espectro de metodologas modernas (no solo giles) es el de Integracin
Continua.
Esta prctica nace a partir de los fracasos acarreados por las fases de integracin
de los modelos tradicionales en que una vez que se tenan todos los mdulos
construidos se iniciaba una intensa y compleja fase en que los mismos se integraban
unos con otros hasta lograr el producto a ser entregado. Era en dicho lapso en que
ocurran los mayores descalabros en materia planificacin, excedindose de manera
desmedida el tiempo, haciendo que fracasen proyectos que haban concluido con xito
sus fases anteriores. Una de las causas principales consista en las complejas
interacciones existentes entre los distintos mdulos, construidos por distintos equipos,
los cuales al ser integrados por vez primera presentaban bugs que eran muy difciles de
encontrar por estar generados por distintas personas.
La industria del software aprendi su leccin, y ya desde hace algn tiempo, la
Integracin Continua es considerada esencial en cualquier proceso moderno de
desarrollo por ms burocrtico o minimalista que resulte. Por dar un ejemplo, la
metodologa eXtreme Programming contiene la Integracin Continua entre sus 12
prcticas claves. Ms an es de pblico conocimiento que desde hace muchos aos
Microsoft viene utilizando esta prctica en su proceso de desarrollo de donde surgi la
nocin del daily build, en que todas las noches se integraba, compilaba y linkeaba el
cdigo generado para ser luego probado por los casos de prueba automatizados. Steve
Marcelo Schenone
McConnell [McConnell, 1996] fue uno de los que ms analiz esta tcnica
recomendndola entre sus conocidas best practices. Martin Fowler [Fowler, 2002]
escribi un artculo bastante descriptivo de los beneficios de esta prctica.
La Integracin Continua en AgEnD consiste en poseer un ambiente
automatizado mediante el cual se pueda realizar el check out de la herramienta de
Administracin de la Configuracin que se este utilizando y posteriormente tener un
entorno que tome el cdigo fuente, genere los builds con todos los pasos intermedios
que esto involucre, corra los suites de tests automatizados, y emita un reporte con el
resultado del proceso. El nfasis est puesto en la automatizacin del proceso de manera
que resulte algo lo ms transparente posible para el equipo de desarrollo. Existen en la
actualidad herramientas muy potentes en algunos casos, gratuitas por ser de cdigo
abierto las cuales permiten que esta prctica pueda ser llevada a la realidad con un
mnimo esfuerzo. Un ejemplo de herramienta Open Source de estas caractersticas es el
Cruise Control que funciona en conjunto con Ant, CVS, y JUnit para llevar a cabo los
builds continuos en una mquina.
Para tener un build exitoso es recomendable que el mismo tenga ciertas
caractersticas que nos den seguridad respecto a la consistencia e integridad del mismo.
En un entorno ideal un build solo podr ser llamado exitoso si se dan todos los
siguientes pasos correctamente sin intervencin humana:
Marcelo Schenone
pruebas unitarias sobre el mismo7 y una vez que pase exitosamente el 100% de las
mismas proceder a integrarlo. Cuando el programador se disponga a integrar lo que ha
construido realiza previamente una actualizacin de la copia local de su repositorio para
chequear que est usando la ltima versin de todos los tems de configuracin y luego
subir sus cambios mediante un check-in al repositorio.
En casos que no se cuente con una herramienta de builds automatizada, el
programador har un check out del mdulo correspondiente en la mquina que ha sido
designada como repositorio de los builds maestros. En la misma ejecutar el script de
deployment8 que se encargar de compilar y empaquetar las clases para su despliegue.
Suponiendo que el resultado del script es exitoso se podr efectuar el test funcional en
caso que se desee liberar la versin. Una vez que el programador deja la mquina de
integracin tendr una sensacin de logro y una inmediata recompensa de un trabajo
bien realizado.
Sin embargo, deberemos recordar que hasta este instante estamos verificando la
sintaxis y semntica del cdigo, pero no sabemos nada respecto a si cumple las
necesidades del usuario. Para esto se tienen las pruebas funcionales automatizadas o
manuales que deber crear o especificar el tester junto con el cliente.
Peopleware
Una de las cuestiones en que se enfoca AgEnD es Peopleware - esto es
consistente con la idea de estar alineada bajo el Agile Manifesto ya mencionado. Este
trmino refiere a las personas involucradas en el desarrollo de software y a todos los
aspectos relacionados con las mismas.
Las primeras nociones de Peopleware surgieron alrededor de 1969, cuando la
industria del software apenas comenzaba a madurar, de manos de Gerald Weinberg en
su libro The Psychology of Computer Programming, posteriormente reeditado en 1998
[Weinberg, 1998]. En el mismo, Weinberg relativizaba los aspectos relacionados con el
proceso y las tcnicas utilizadas para construir software abocando la importancia que
7
Esta idea surge del framework de testing creado por Kent Beck para Smalltalk, posteriormente portado y popularizado por la
versin en Java, denominada JUnit, desarrollada por Beck y Erich Gamma. Ms informacin en http://www.junit.org
Marcelo Schenone
El lugar de trabajo.
La cultura de la empresa.
Una de las herramientas ms populares para despliegue en la plataforma Java es el ANT. Este es un subproyecto dentro de la
comunidad de Jakarta que brinda una herramienta indispensable para despliegue automatizado de aplicaciones complejas. Ms
Marcelo Schenone
Calidad en el Proceso
El referirnos a AgEnD como una metodologa gil no quiere decir que el nfasis
puesto en los entregables y la rapidez del desarrollo no tengan en cuenta el problema de
la calidad.
Tomando como marco de referencia al CMM es sabido que la mayora de las
empresas del pas se encuentran en el nivel 1, denominado Inicial. Una de las razones
informacin en http://www.ant.org
Marcelo Schenone
por las cuales esto ocurre radica en la falta de un proceso de desarrollo maduro y en la
tendencia inherente en la gente de sistemas de seguir el modelo Codificar y Probar.
Esta tendencia se debera modificar de forma de seguir un proceso relativamente
disciplinado, generando documentacin de anlisis/diseo previamente, haciendo el
testing luego de la codificacin, siguiendo entregas definidas. Sin embargo, al momento
en que el tiempo apremia se dejan de lado todas estas prcticas, desapareciendo el
proceso al punto de volver al caos del que se deseaba escapar.
Una de las razones de este fracaso consiste en la falta de convencimiento pleno
por parte del equipo de desarrollo en el proceso que utilizan diariamente. Mientras los
hitos se vayan cumpliendo siendo las entregas aceptadas por los clientes el equipo se
siente confidente de que su proceso los llevar al xito y que adems lo estn siguiendo
correctamente. Todos comentarn la necesidad de mantener un proceso disciplinado
mostrando las experiencias pasadas como demostracin de los resultados y de los
productos entregados.
Podr llegar el momento en que el proyecto comience a retrasarse en las
entregas, a disminuir la calidad o a remover funcionalidad de las mismas. Ser en estos
momentos en que nacer un sentimiento de desesperacin que comenzar en el
management descendiendo en la jerarqua hasta el equipo de desarrollo. Se pedirn
entregas imposibles, las cuales llevarn a los programadores a codificar en forma
masiva, dejando de lado completamente cualquier viso de proceso, erradicando
completamente la calidad del software construido.
Por estas cuestiones es importante que el proceso se tenga en alta estima y que la
gente est convencida de su utilizacin. En caso contrario, el proceso no cumple su
funcin. Para mantener la salubridad del mismo incluimos en la prxima seccin una
serie de disciplinas que permiten tener siempre un proceso de calidad que se adece a
las necesidades de la gente que lo utiliza.
Marcelo Schenone
Enfoque Sistmico
Uno de los motivos principales de desarrollo de esta tesis consiste en una
investigacin extensa en los campos de la psicologa sistmica, la administracin de
empresas y las relaciones laborales; para incorporar el conocimiento de estas reas en el
desarrollo de software.
Marcelo Schenone
necesarias para cada rol, y las distintas formas en que estas contribuyen a que la persona
este satisfecha de su trabajo.
Para encarar este estudio haremos una breve introduccin al cuerpo de
conocimiento que nos provee la Psicologa Sistmica. Esta rama de la Psicologa,
surgida a partir de cuatro pilares surgidos el siglo pasado que dieron el comienzo de la
Ciberntica y la Informtica. Las ideas de Wiener en relacin al feedback, y el
pensamiento circular surgidas a principios del siglo pasado fueron uno de las primeras
influencias de la sistmica. Posteriormente, Turing trajo consigo el trabajo necesario
para atacar la complejidad inherente a cualquier sistema mediante modelos que servan
para reducir dicha complejidad y hacerla comprensible para la mente humana. A partir
de esta teora se comenzaron a atacar los problemas mediante el desglose sistmico en
distintos modelos que reflejaran las partes que se iban a estudiar. Fue Shannon el
encargado de construir la teora de la informacin a partir de la cual se vio la posibilidad
de transmitir cualquier tipo de informacin a travs de un canal de datos. Ese sera el
inicio de lo que actualmente denominamos la globalizacin en materia de
comunicaciones. Por ltimo, Von Neumann trabaj en formas de convertir la
informacin en seales elctricas de manera que las mismas pudieran ser procesadas en
forma automtica. De esta forma, se sentaron las bases para la creacin de las
computadoras que procesaran la informacin que se les cargaba sin requerir de
operatoria manual.
Gracias a estos cuatro marcos tericos se configura la Teora General de
Sistemas, la cual ha cambiado la forma de estudio de todas las ciencias desde las
humansticas hasta las cientficas. En particular, surge una nueva disciplina que es la
Informtica que est relacionada con las actividades que conciernen a los sistemas de
informacin. Es decir, es la consecucin natural de la Teora General de Sistemas y su
aplicacin a todas las actividades humanas en las que existe algn manejo de
informacin.
Es notable el aporte de Roman Jakobson, uno de los creadores de la lingstica
moderna que traslada los postulados de la teora de la informacin de los sistemas a lo
que se denomina la teora de la comunicacin. El modelo planteado por Jakobson, en
que en toda comunicacin existe un Emisor, un Receptor y un mensaje transmitido
sienta las bases para la especificacin de las interacciones entre las personas como un
fenmeno sistmico susceptible de ser analizado. Retornando a la Psicologa, estas
Marcelo Schenone
Marcelo Schenone
Establecimiento
de Criterios
Creacin de
Conciencia
Escrutinio y
Revisin
Anlisis Lgico
Puesta en
Prctica
Generacin y
Evaluacin de
Alternativas
Esta figura identifica los pasos necesarios para un gradual ciclo de mejora de
procesos. Se parte por el establecimiento de criterios en que las partes interesadas
expondrn los problemas existentes que sern motivos de la intervencin. Luego, se
comenzar a crear una conciencia que facilite el cambio, para esto tomaremos el
continuo mencionado anteriormente respecto a la posicin de los individuos respecto al
cambio. A continuacin se efectuar un anlisis de la situacin, entendiendo las causas
Marcelo Schenone
Calidad
(AP)
Proceso
Gente
(AM)
Marcelo Schenone
Actividades
Adaptacin
Metodolgica
Adaptacin de las
Personas
Evaluacin
Iteraciones
Preliminares
Iter.
#1
Iter.
#2
Iter.
#n
Iter. Iter.
#n+1 #n+2
Iter.
#m
Iter.
#m+1
Iteraciones
Figura 034. Actividades desarrolladas durante la implementacin de AgEnD.
Marcelo Schenone
Marcelo Schenone
en paralelo y en forma iterativa, hasta que todos los cambios planificados han sido
ejecutados y existe concurrencia respecto al xito de la adopcin de la metodologa.
Marcelo Schenone
La Organizacin
Una organizacin puede ser observada como un sistema abierto. Existen inputs,
un proceso de transformacin que genera outputs, y un ciclo de feedback que ayuda a
controla que los outputs sean los esperados para poder tomar acciones correctivas. Sin
embargo, pensar que este modelo alcanza para describir las actividades fundamentales
de una organizacin es errneo ya que la organizacin reviste un comportamiento
dinmico resultante de una multiplicidad de factores que confluyen para conformar la
identidad organizacional los cuales no pueden ser tomados linealmente sobre esto se
podr consultar [Etkin, 1989].
En el inicio de la implementacin de AgEnD se efecta un relevamiento del
status organizacional. Para esto se debern identificar aquellos stakeholders claves para
que el proceso de implementacin resulte exitoso. En la Tabla 001 se describen aquellos
stakeholders que resultan importantes incluir al momento de llevar a cabo el
relevamiento.
Stakeholder
Sponsor Ejecutivo
Influencia
Persona responsable de obtener el soporte ejecutivo necesario
para el xito de la implementacin de una metodologa gil
Gerente de Sistemas
Project Manager
Lder de QA
Coordinador
Marcelo Schenone
Marcelo Schenone
El rea de Desarrollo
Sin duda alguna el rea que estar sometida a la mayor influencia ser el rea de
Desarrollo. Aqu se encontrarn los usuarios finales del proceso que sern los que
participarn en la customizacin del mismo. Para ejecutar la implementacin se
evaluar primero el enfoque de la Adaptacin Metodolgica en que cada disciplina,
artefacto y actividad de AgEnD ser contrastada con la forma de trabajo de las personas
para poder elegir la mejor manera en que ests ltimas podrn absorber el proceso.
Teniendo en cuenta las diferentes reas de conocimiento de la Ingeniera de
Software, propuestas en el SWEBOK [SWEBOK, 2002], identificaremos los roles de
cada individuo en relacin a las mismas. Las reas en cuestin son: Requerimientos de
Software (SR), Diseo de Software (SD), Construccin de Software (SC), Testing de
Software (ST), Mantenimiento de Software (SM), Administracin de la Configuracin
del Software (SCM), Administracin de Ingeniera de Software (SEM), Proceso de
Ingeniera de Software (SEP), Mtodos y Herramientas de Ingeniera de Software
(SETM), Calidad de Software (SQ).
Cada una de estas reas puede estar o no contemplada dentro de la organizacin
y ser realizada por uno o ms roles. La realidad del mercado informtico en consultoras
de tamao modesto en la Argentina indica que es comn que la estructura est formada
por un grupo importante de personas en el rea de SD/SC, un pequeo grupo de
personas en SR/ST, grupos de personas dispersas en SM, y un mnimo nmero, o
ninguno en algunos casos, de personas abocadas a SEP/SETM/SQ. Es decir, aquellas
actividades cuyo ROI es ms inmediato concentran la mayor cantidad de recursos en
detrimento de aquellas actividades cuyos beneficios solo son visibles a largo plazo, que
tienden a contar con poco personal.
Marcelo Schenone
Customizacion
del Proceso
Predictibilidad
Marcelo Schenone
Como se observa, muchas de estas cuestiones parten del sentido comn pero
pueden servir para que un equipo de desarrollo que presenta cierta resistencia a AgEnD
comience a alinear sus esfuerzos hacia la implementacin de las prcticas y la
articulacin de los principios. Podemos mencionar que la disciplina de Administracin
de Proyecto dentro de AgEnD debe aportar toda la informacin necesaria para que el
equipo sepa hacia dnde dirigir sus esfuerzos.
El Individuo
El desarrollo de software es una actividad humano-intensiva. Dada la
complejidad inherente al software las personas se ven obligadas a trabajar en forma
grupal interactuando con sus pares. En estas interacciones que ocurren a diario en las
organizaciones se juegan juegos de poder. Estos determinan el comportamiento de las
personas las cuales ejercen su autoridad y son sujetas a las autoridades de otros.
Si recurrimos al Modelo Motivacional de la Figura 037 propuesto por Harold
Leavitt, observamos que las personas estn continuamente buscando el equilibrio
interno; cuando algo desafa este estado de equilibrio, existe un sentimiento de
frustracin que genera alguna accin en la persona y que hace que esta cambie buscando
un nuevo estado de satisfaccin. De hecho, este ciclo contina en todos los mbitos de
la vida humana durante la existencia del individuo y es de utilidad entenderlo ya que la
satisfaccin/motivacin de las personas en su trabajo determinar ulteriormente el
resultado de la implementacin de un proceso gil de software.
Marcelo Schenone
Equilibrio
Interno
Estmulo
Necesidad
Tensin
Accin
Satisfaccin
Desde un punto de management, acorde a las palabras de Tom Peters, una de las
consideraciones principales que tendrn las empresas del maana ser que su valor de
mercado estar dado por los bienes intangibles que esta posee (a diferencia de la visin
tradicional en que se valoran principalmente los tangibles). Los bienes intangibles estn
dados por el intelecto e imaginacin de las personas denominadas knowledge workers
bajo este esquema.
Como ya fue descrito el proceso plantea ciertos principios, prcticas y patrones
que conviene sean utilizados para lograr la satisfaccin continua de la gente que lleva a
cabo la construccin del software. La satisfaccin de cada uno de los individuos
contribuir a la motivacin del equipo y ayudar en la implementacin del proceso.
Dentro del espectro de comportamientos humanos, una metodologa tiene dos
opciones para lidiar con la diversidad de personalidades: ser tolerante a la
individualidad o ser estricta y disciplinada para lograr comportamientos determinados.
Dado que cada individuo es nico y posee una personalidad que lo caracteriza, AgEnD
plantea un marco de implementacin tolerante a la diversidad de personalidades y
formas de trabajo de los individuos. Para que la tolerancia de la metodologa tenga xito
y la construccin del software no sea algo catico se requieren ambientes de
colaboracin, con buenas relaciones interpersonales, y un cierto grado de empata por
hacer el trabajo y ayudar a otros a que lo hagan. En general podemos decir que a veces
la disciplina resulta conveniente y aunque sea difcil de lograr puede resultar ms
Marcelo Schenone
eficiente. La tolerancia puede resultar ms fcil de adoptar pero quizs sea menos
productiva.
Marcelo Schenone
Nomenclatura Estandarizada
Una de las primeras facilidades que una persona se encuentra al aprender
AgEnD es el uso de nombres estandarizados para todos sus elementos. Muchos de los
nombres utilizados han sido tomados del RUP [RUP, 2002] que sirve como base de
conocimiento para procesos de desarrollo. Tambin existieron fuertes influencias del
SWEBOK [SWEBOK, 2001] que comprende el cuerpo de conocimiento de la
ingeniera de software y que es fiel esperanza del autor que dicho proyecto siente las
bases hacia una profesionalizacin de nuestra disciplina.
Gracias a esta estandarizacin, AgEnD contribuye a un global entendimiento de
los conceptos involucrados lo cual habilita una comunicacin ms fluida entre las
personas involucradas.
Administracin de Proceso
AgEnD propone distintos patrones enmarcados en una disciplina que pueden ser
utilizados para customizar el proceso en distintas etapas. Los patrones sirven para que
AgEnD pueda ser implementado exitosamente y para adaptar el mismo a las
necesidades particulares del proyecto. Esto logra captar el feedback de la gente que es
usuaria del proceso y dinmicamente modificarlo para que cumpla mejor sus objetivos.
Administracin de Personas
AgEnD propone distintos patrones enmarcados en una disciplina que pueden ser
utilizados para manejar mejor el factor humano dentro del desarrollo. Los patrones
ayudan a mejorar el ambiente de trabajo de los individuos, mejorar la motivacin de los
Marcelo Schenone
grupos de trabajo y mitigar las fricciones que puedan existir. El resultado ser una
adopcin rpida y eficaz de AgEnD, tolerante a la diversidad de personalidades
existentes.
Marcelo Schenone
Templates de Artefactos
AgEnD ofrece una serie de templates (ver Apndice A) que ayudarn al
Coordinador que lleve a cabo la implementacin a elaborar los artefactos sugeridos.
Estos han sido utilizados en distintos proyectos y plasman de una manera concisa la
informacin que se desea transmitir. La idea de los mismos es adaptarlos de acuerdo a
la realidad de los proyectos manejados por la organizacin.
Marcelo Schenone
Marcelo Schenone
Marcelo Schenone
FIDoNET est comprometido a utilizar AgEnD en todas sus fases pudiendo adaptarlo a
medida se avanza en el desarrollo mediante la intervencin del Coordinador.
Inicialmente los stakeholders del proyecto forman un grupo de considerable
diversidad. En el mismo incluimos a ONGs, Empresas asociadas con FIDoNET,
Instituciones, Usuarios individuales y recursos de FIDoNET. El gran porcentaje de
comunicacin en el desarrollo ser realizado con dos usuarios expertos de la propia
empresa los cuales conocen el sistema a construir en detalle. Ellos recibirn pedidos de
los dems stakeholders y los canalizarn en el proyecto al fin de cada iteracin.
Roles y Recursos
Los roles de AgEnD estn llevados a cabo por distintas personas del proyecto. A
continuacin mencionamos a los trabajadores que participaron en la primera versin del
proyecto:
Marcelo Schenone
Tecnologas
Dadas los objetivos globales de FIDoNET como organizacin de crear unin
entre personas fomentando la solidaridad, se prioriz al momento de seleccin de
tecnologas aquellas que respondan al modelo de desarrollo Open Source y que puedan
usar libremente sin costos de licencias asociados. Conjuntamente, otro de los factores a
Marcelo Schenone
Arquitectura de la Aplicacin
Arquitectura Web: presenta la interfase al usuario mediante un navegador de
internet pudiendo desacoplar las capas de interfase/lgica de negocio/datos en el
servidor mediante frameworks disponibles.
MVC que desacopla esta capa de las capas de lgica del negocio y manejo de
datos. Asimismo, se tuvo especial nfasis en utilizar un medio que permita que
se muestre esta capa en distintos dispositivos (Ej.: PDA, celulares, tablet-pc,
sistemas embebidos, etc.) sin tener que hacer cambios importantes a la
aplicacin.
Marcelo Schenone
Presentacin
Lgica
Datos
<HTML>
<BODY>
...
</BODY>
</HTML>
Web Server
Application
Server
RDBMS
Motores de BD
MySQL: uno de los motores Open Source ms populares, MySQL es utilizado en
la mayora de los sitios web del mundo en forma conjunta con el lenguaje de
scripting PHP. El motor es muy robusto y si bien no posee toda la funcionalidad
de un motor como Oracle, es una opcin ms que interesante por la rapidez y
sencillez del mismo.
Marcelo Schenone
Framework de MVC
Jakarta Struts: framework utilizado para la capa de presentacin de la
aplicacin. El mismo se utiliza para armar el patrn MVC pudiendo desacoplar
la presentacin de la lgica del negocio.
En particular, Struts utiliza JSP para enviar la pgina al cliente que efecta el
request (View Component). En el mismo se podrn usar tags propios de la
librera de Struts que permiten minimizar el cdigo que se escribe en el JSP.
Struts ha madurado y es utilizado en todo el mundo. La comunidad de usuario de
Struts
crece
un
ritmo
considerable.
Existen
muchas
aplicaciones
Marcelo Schenone
poder acotar el campo de funcionalidad que ser incluido en la aplicacin. Esta funcin
es llevada a cabo por las personas Responsables del Negocio que conocen en
profundidad a los stakeholders del futuro sistema y los servicios que sern provistos a
estos. Durante un perodo de 4 meses estas personas mantienen reuniones peridicas en
las que se identifican aquellas ONGs que servirn como referentes al momento de
relevar necesidades.
Se planifican las fases en que el proyecto de FIDoNET ser dividido tomando
como referencia las fases de AgEnD. Se realiza una estimacin inicial de muy alta
granularidad para que los stakeholders vayan teniendo visibilidad y tambin para
asegurar la viabilidad econmica del proyecto.
Marcelo Schenone
Algo similar ocurri con los Casos de Uso que inicialmente fueron basados en el
template de [RUP, 2002]. Los mismos eran especificados por el Analista en conjunto
con los Usuarios Expertos. Durante las primeras iteraciones se observ que los
Desarrolladores los lean por arriba y hacan las preguntas directamente a los Usuarios
Expertos quienes hacan un breve repaso por el flujo de interacciones. A partir de ese
momento se decidi especificar el comportamiento en casos de uso mucho ms
informales que permitieran que los Desarrolladores tuvieran un idea de lo que tenan
que implementar pudiendo profundizar con la comunicacin cara a cara con los
Usuarios Expertos. Finalmente, los casos de uso terminaron siendo bastante parecidos a
las User Stories planteadas por XP [Jeffries, 2001].
Tomando el concepto del Scrum Daily Meeting sugerido por Scrum [Schwaber,
2001], se decidi agregar dentro de la disciplina de Administracin de Proyecto de
AgEnD esta reunin diaria de quince minutos a primera hora de la maana con el
equipo de desarrollo. La misma era coordinada por el Lder de Proyecto quien
preguntaba a cada persona del equipo qu haba hecho de la durante el da anterior, que
iba a hacer durante ese da y que obstculos tena para llevar a cabo sus actividades. En
la reunin poda participar el Cliente pero solo como observador. Esto permiti ir
teniendo un control y monitoreo constante sobre el progreso y los riesgos que se iban
dando.
En relacin a los artefactos sugeridos por AgEnD se dejaron de lado la Lista de
Riesgos ya que con la reunin diaria del Lder con el equipo el control y monitoreo de
los mismos era on-line. Tambin no se vio la necesidad de generar Notas de Entrega ya
que el equipo de desarrollo era parte del Cliente y exista plena confianza e
involucramiento de este ltimo en el proyecto.
Administracin de la Configuracin
Dentro del contexto de un proceso moderno de desarrollo es indispensable
contar con una herramienta que automatice todas las tareas relacionadas con los tems
de configuracin generados durante un proyecto. Para esto se seleccion la herramienta
CVS (Concurrent Versions System) que permite llevar esta tarea a cabo.
De acuerdo a lo recomendado por AgEnD todos los artefactos generados durante
un proyecto sern puestos bajo control de versiones. Para comodidad del equipo de
Marcelo Schenone
Mxima Comunicacin
Una de las prcticas que fue aplicada con mayor xito en el proyecto fue la de
Mxima Comunicacin. Todas las personas involucradas en el proyecto (tanto de parte
de los usuarios expertos como el equipo de desarrollo) estaban en un mismo piso de un
edificio en oficinas adyacentes. Esto permita que cualquier duda planteada por
cualquier parte se resolviera mediante la rpida consulta con el miembro que tena el
conocimiento. Esta es una prctica esencial en AgEnD que es prerrequisito de su
implementacin. Alistair Cockburn [Cockburn, 2001a] identifica como las corrientes
comunicacionales mejoran la transferencia de conocimiento y son una de las causas por
las cuales se pueden minimizar el overhead metodolgico. Esto fue tratado ampliamente
en el captulo anterior.
En caso que esta prctica no se hubiera implementado no se podra haber
implementado una metodologa como AgEnD ya que el grado de ceremonia de esta no
es conforme a ambientes en donde se debe suplir la carencia de comunicacin mediante
comunicacin. Para esto se recomienda usar alguna metodologa como el Unified
Process.
Marcelo Schenone
avance solo como observador y en las reuniones semanales de revisin para validar el
contenido de lo que se construy.
El Cliente junto con el Analista tena a su cargo la especificacin de los casos de
uso. Al final la aplicacin contaba con 42 casos organizados en distintos mdulos que
mapeaban con el formato de la interfase grfica. Otra de las prcticas importantes que se
utiliz en relacin al Cliente fue un Control de Cambios formal. Para esto el Cliente
dejaba en el Gantt del Proyecto distintos pedidos de cambio. Cada uno de estos era
evaluado por el Lder de Proyecto y por el Arquitecto quienes discutan el impacto del
cambio y el costo en recursos/tiempo del mismo. Las posibilidades eran hacer el cambio
en la prxima iteracin, dejarlo para la prxima versin del sistema o desecharlo
completamente. Esto funcionaba como escudo para los Desarrolladores quienes de otra
forma hubieran tenido que estar continuamente cambiando el cdigo que desarrollaban
dado el ambiente de alta volatilidad existente.
Estimaciones giles
Esta prctica fue utilizada frecuentemente al principio del proyecto y luego
continuadamente en cada iteracin. Durante la primera fase se tomaron los features del
documento de Visin del producto los cuales comenzaron a ser pasados a casos de uso.
El Lder de Proyecto en forma conjunta con el Arquitecto y el Cliente, dieron prioridad
a estos casos de uso seleccionando la versin del producto en que cada uno aparecera.
De acuerdo a la propuesta de AgEnD se tomaron los casos de uso seleccionados para la
primera versin de manera de efectuar una estimacin global de la duracin del
proyecto. Se dej en claro que dicha estimacin arrojara un resultado aproximado y
dada la naturaleza de los procesos giles el mismo simplemente servira para planificar
hitos importantes del proyecto.
Usando la metodologa de UCP (Use Case Points) junto con los factores de
ajuste correspondientes, la estimacin arroj un total de 215 UCP no ajustados.
Mediante la utilizacin del factor de ajuste estandar de la industria de 20 horas/persona
por UCP se obtuvo un esfuerzo para el proyecto de 18,78 meses/persona. De acuerdo al
equipo de desarrollo descrito anteriormente se estim la duracin en 5 meses.
Este resultado fue bastante acertado si se tiene en cuenta que la primer versin
fue liberada 6 meses despus. Cabe remarcar que durante el desarrollo hubo grandes
Marcelo Schenone
Enfoque en la Arquitectura
Esta prctica fue de gran ayuda en el desarrollo ya que permiti definir
cuestiones tcnicas que impactara positivamente en la solucin al problema. Una vez
que se comenz con la especificacin de los casos de uso, en paralelo el Arquitecto
junto con los Desarrolladores comenzaron a definir la arquitectura del sistema. Uno de
los requerimientos no funcionales ms importante era el construir un sistema mantenible
y flexible, el cual pudiera incorporar cambios con facilidad. Exista tambin una fuerte
restriccin de diseo de mantener los costos lo ms bajo posibles y de que el sistema no
tuviera licenciamento alguno por lo cual se deban utilizar componentes Open Source.
Tomando como input los casos de uso que se iban teniendo y las cualidades
sistmicas requeridas se fue armando el documento de Descripcin de la Arquitectura.
Un breve resumen del mismo se puede observar en el punto anterior donde se visualizan
los componentes ms importantes de la solucin.
Podemos mencionar que a diferencia de otras metodologas giles (XP entre las
ms conocidas) que plantean el no realizar ningn esfuerzo de arquitectura al principio,
AgEnD sugiere especificar las cuestiones tcnicas ms importantes en forma temprana
de manera de minimizar el impacto del cambio en este sentido. Esto permiti que una
vez elegida la arquitectura, el Arquitecto y los desarrolladores construyeron un
prototipo proof of concept que validara las decisiones tomadas. Se seleccionaron los
casos de uso ms crticos de los que estaban especificados y se implement el prototipo.
El mismo fue exitoso y sent la base para la posterior implementacin de los casos de
uso.
Integracin Continua
De acuerdo a la prctica de AgEnD se configur un entorno de desarrollo que
fomentara la integracin continua. Los Desarrolladores trabajaban en la implementacin
de los casos de uso y peridicamente suban su trabajo al repositorio, en este caso el
CVS. El cdigo slo era subido si las pruebas unitarias pasaban en su totalidad.
Marcelo Schenone
Una vez que estaba subida la aplicacin la misma era testeada unitariamente y
funcionalmente por el desarrollador para verificar que el sistema continuaba en
funcionamiento. Al fin de cada semana el Tester tomaba todo lo construido y guindose
con los casos de uso llevaba a cabo el testing funcional en forma conjunta con el Cliente
en algunos casos.
Gracias a la prctica de Integracin Continua se evitaron los problemas de
modelos anteriores ms rigurosos que posponan la integracin para el final del
proyecto, una vez que todos los mdulos estuvieran codificados, lo cual creaba un alto
riesgo debido a la incompatibilidad de interfases y comportamientos. En el proyecto de
FIDoNET no existieron problemas de este tipo.
Peopleware
El nfasis de AgEnD en la gente fue llevado a la prctica en el proyecto. En todo
momento el Lder de Proyecto fomentaba la motivacin de su equipo. Hubo solamente
un par de semanas con algunos das con horas extras, especialmente en fechas crticas
de entregas pero los mismo fueron seguidos de semanas ms tranquilas con menos carga
laboral.
Las personas del equipo disponan de amplios lugares de trabajo, mquinas
potentes, cmodos escritorios que les permitan llevar a cabo programacin de a pares si
se deseaba. Tambin permita que el Cliente pudiera sentarse con el Analista a evaluar
la aplicacin.
En todo momento se foment la cohesin del grupo llevando a cabo actividades
extra-curriculares que permitieran generar un espritu de grupo. Estas actividades
incluyeron salidas despus del trabajo, asados con el equipo de desarrollo, almuerzos a
cargo de la empresa, etc. Las mismas ayudaron a que la gente entrara en contacto entre
s y se hablarn de cuestiones no concernientes al mbito laboral.
Marcelo Schenone
Artefactos
De acuerdo a la definicin de AgEnD se recomienda especificar al principio del
proyecto aquellos artefactos que sern generados y mantenidos durante el ciclo de vida.
Esta es una de las tareas que el Coordinador de Proceso (tomado en este caso por el
Lder de Proyecto) realiza durante las primeras iteraciones. El resultado de la misma es
el siguiente:
Marcelo Schenone
Marcelo Schenone
Roles y Recursos
Los roles de AgEnD estn llevados a cabo por distintas personas del proyecto. A
continuacin mencionamos a los trabajadores:
10
Marcelo Schenone
Marcelo Schenone
Tecnologas
Al momento de armar la Propuesta Econmica del proyecto se prioriz la
seleccin de tecnologas basadas sobre la plataforma Java 2, prefirindose aquellas que
respondiesen al modelo de desarrollo Open Source y que pudiesen usarse libremente sin
costos de licencias asociados.
Arquitectura de la Aplicacin
Arquitectura Web: arquitectura que presenta la interfase al usuario mediante un
navegador de internet pudiendo desacoplar las capas de interfase/lgica de
negocio/datos en el servidor mediante frameworks disponibles.
Marcelo Schenone
MVC que desacopla esta capa de las capas de lgica del negocio y manejo de
datos.
datos relacional. El mismo ser accedido mediante el patrn DAO (Data Access
Object) que desacopla la persistencia del RDBMS seleccionado.
Motores de BD
Microsoft SQL Server: uno de los motores comerciales ms utilizados en el
mercado. El mismo es estndar del cliente por lo que resulta en una restriccin
de la aplicacin. Tambin se debe acceder al mismo nicamente mediante Stored
Procedures que sern escritos por los desarrolladores.
Framework de MVC
Marcelo Schenone
Marcelo Schenone
Figura 038. Diagrama de secuencia de interacciones en el patrn DAO. Tomada de [Alur, 2001].
Marcelo Schenone
Mxima Comunicacin el Coordinador dedic unos 4 das full time al proyecto para
llevar a cabo un refactoring de la Arquitectura suplantando el documento en s por
cdigo ejecutable que sirviera para gua a los desarrolladores. Los resultados fueron
excelentes.
Al igual que en el proyecto anterior se decidi agregar dentro de la disciplina de
Administracin de Proyecto del proceso al Scrum Daily Meeting. La misma era
coordinada por el Lder de Proyecto quien preguntaba a cada persona del equipo qu
haba hecho la durante el da anterior, que iba a hacer durante ese da y que obstculos
tena para llevar a cabo sus actividades. Esto permiti ir teniendo un control y
monitoreo constante sobre el progreso y los riesgos que se iban dando.
En relacin a los artefactos sugeridos por AgEnD la Visin fue suplantada por la
Propuesta Econmica a partir de la cual el Cliente decida respecto a la ejecucin del
proyecto. Todos los dems artefactos sugeridos fueron realizados incluyndose como
parte de los casos de uso los prototipos de pantalla en HTML correspondientes. Esto
sirvi para obtener un rpido feedback del usuario respecto a aquellas funcionalidades
que resultaban ambiguas.
Administracin de la Configuracin
Se arm el repositorio en CVS que es la herramienta de SCM usada por la
consultora. Todos los artefactos generados durante el proyecto fueron puestos bajo
control de versiones. Para comodidad del equipo de desarrollo se decidi tener dos
mdulos independientes dentro de un mismo repositorio. El repositorio tena el nombre
del proyecto y existan dos mdulos: uno denominado Project y otro Sources. El primer
mdulo inclua toda la documentacin asociada a las distintas disciplinas de AgEnD
categorizadas en directorios con el nombre de la disciplina. El segundo mdulo tena
todo el cdigo de la aplicacin a ser cargado en la IDE utilizada el Eclipse.
El mantener todo el cdigo fuente bajo control de versiones permiti que en un
punto los desarrolladores entregaran una primera versin de demo al cliente para validar
los flujos de los casos de uso, usando el HEAD del repositorio para mantener los tems
de configuracin. En paralelo, el Coordinador que emprendi tareas de Arquitectura
empez a trabajar en un refactoring de la Arquitectura destinado a mejorar la
flexibilidad y mantenibilidad del cdigo generado. Para esto se decidi abrir un branch
Marcelo Schenone
Mxima Comunicacin
La
prctica
de
Mxima
Comunicacin
no
pudo
ser
implementada
Enfoque en la Arquitectura
Esta prctica fue de gran ayuda en el desarrollo ya que permiti definir
cuestiones tcnicas que impactaran positivamente en la solucin al problema. Sin
embargo como ya fue mencionado fue donde se materializaron importantes riesgos que
llevaron al desvo en el cronograma del proyecto.
Una vez que se comenz con la especificacin de los primeros casos de uso, en
paralelo el Coordinador en rol de Arquitecto junto con los Desarrolladores comenzaron
a definir la arquitectura del sistema. Uno de los requerimientos no funcionales ms
importante era el construir un sistema mantenible y flexible, el cual pudiera incorporar
cambios con facilidad y que debera ser interoperable con otras aplicaciones dentro de
los sistemas del Cliente.
Tomando como input los casos de uso que se iban teniendo y las cualidades
sistmicas requeridas se fue armando el documento de Descripcin de la Arquitectura.
Marcelo Schenone
Un breve resumen del mismo se puede observar en el punto anterior donde se visualizan
los componentes ms importantes de la solucin.
El nico comentario que podemos incluir es que la falta de una persona
experimentada desde el punto de vista tcnico guiando al equipo de desarrollo full time,
como establece el rol de Arquitecto en AgEnD, caus problemas debido a la
inexperiencia del equipo de desarrollo. Volvemos a destacar la necesidad de invertir
constantemente en la gente y el riesgo que trae aparejado el no tener recursos a la altura
de las circunstancias.
Estimaciones giles
Esta prctica fue utilizada al principio del proyecto en el armado de la Propuesta.
Durante la primera fase se tomaron los casos de uso del producto y el Lder de Proyecto
en forma conjunta con el Coordinador y el Cliente, dieron prioridad a seleccionando la
versin del producto en que cada uno aparecera. Siguiendo a AgEnD se tomaron los
casos de uso seleccionados para la primera versin de manera de efectuar una
estimacin global de la duracin del proyecto. Se dej en claro que dicha estimacin
arrojara un resultado aproximado y dada la naturaleza de los procesos giles el mismo
simplemente servira para planificar hitos importantes del proyecto.
Usando la metodologa de UCP (Use Case Points) junto con los factores de
ajuste correspondientes y efectuando una estimacin en paralelo basada en la
experiencia de especialistas tcnicos dentro de la consultora la estimacin arroj un
esfuerzo para el proyecto de 12 meses/persona. De acuerdo al equipo de desarrollo
descrito anteriormente se estim la duracin en 3 meses.
Este resultado fue bastante acertado si se tiene en cuenta que la primer versin
fue liberada 3 meses y 3 semanas despus. Cabe remarcar el desvo surgido debido a los
temas antes mencionados respecto a la comunicacin de la arquitectura y a las
dificultades con el paquete de reporting seleccionado.
Integracin Continua
De acuerdo a la prctica de AgEnD se configur un entorno de desarrollo que
fomentara la integracin continua. Los Desarrolladores trabajaban en la implementacin
Marcelo Schenone
Peopleware
El nfasis de AgEnD en la gente fue llevado a la prctica parcialmente en el
proyecto. En todo momento el Lder de Proyecto fomentaba la motivacin de su equipo.
Hubo solamente un par de semanas con algunos das con horas extras, especialmente en
fechas crticas de entregas pero los mismo fueron seguidos de semanas ms tranquilas
con menos carga laboral.
Las personas del equipo disponan de amplios lugares de trabajo, mquinas
potentes, cmodos escritorios que les permitan llevar a cabo programacin de a pares si
se deseaba.
Los mayores inconvenientes en relacin a esta prctica fueron la carencia de una
persona cubriendo el rol de Arquitecto en forma continua y la falta de un alto nivel de
comunicacin con el Cliente. Respecto a esto ltimo toda la comunicacin con el
Cliente era realizada mediante la intermediacin del Analista Funcional con lo cual el
delay resultaba muy ineficiente para el desarrollo. Esto fue notificado por el
Coordinador en forma temprana ya que implicaba un alto riesgo en la implementacin
de una metodologa gil pero sin embargo el Lder de Proyecto no pudo efectuar
ninguna accin correctiva ms que tratar de mantener un canal abierto con un usuario
experto para posibles consultas.
Marcelo Schenone
Artefactos
De acuerdo a la definicin de AgEnD se recomienda especificar al principio del
proyecto aquellos artefactos que sern generados y mantenidos durante el ciclo de vida.
Esta es una de las tareas que el Coordinador de Proceso realiza durante las primeras
iteraciones. El resultado de la misma es el siguiente:
Marcelo Schenone
Casos de Prueba, contienen los flujos de ejecucin que sern utilizados por
los Testers para probar la aplicacin desde un punto de vista funcional; son
creados a partir de los casos de uso
Marcelo Schenone
opinin del autor que estas cuestiones no hubieran sucedido si las circunstancias
hubieran permitido la implementacin completa de las prcticas.
Marcelo Schenone
Capitulo V - Conclusiones
Las metodologas de desarrollo de software giles permiten a los pequeos
grupos de desarrollo concentrarse en la tarea de construir software fomentando prcticas
de fcil adopcin y un entorno ordenado que ayude a que las personas trabajen mejor y
permita que los proyectos finalicen exitosamente. Las mismas estn basadas en los
cuatro principios del Manifiesto gil que fueron mencionados al principio de este
trabajo. AgEnD, la metodologa propuesta en esta tesis, avanza en el conocimiento
terico de estos procesos analizando estos principios mencionados y reuniendo prcticas
y patrones que contribuyen a la implementacin y posterior adaptacin del proceso a la
realidad de cada organizacin.
Para llevar a cabo este trabajo se recab informacin exhaustiva de procesos de
desarrollo, reas de conocimiento de ingeniera de software, metodologas giles,
prcticas de desarrollo gil y otras disciplinas dentro de la informtica. Adems, se ley
bibliografa de temas como Administracin de Empresas, Psicologa Sistmica y
Recursos Humanos. Como se observar en la parte final de bibliografa, la lista que fue
reunida no es menor y representa en gran parte el state-of-the-art de los
conocimientos aplicados en esta tesis. Mencionaremos a continuacin las tareas llevadas
a cabo en el transcurso de este trabajo.
Primeramente, se describi la historia de los procesos de desarrollo de software,
explicando brevemente los distintos modelos que fueron surgiendo y las virtudes /
falencias de cada uno. A esto prosigui una breve historia del surgimiento de las
metodologas giles y una caracterizacin de las ms importantes durante el perodo de
escritura de esta tesis: XP, Scrum, Cristal Clear, DSDM, FDD, ASD, XBreed. Gracias a
este captulo logramos ubicar al lector dentro del universo del cual habramos de
explayarnos ms adelante.
Posteriormente, en el capitulo 2, se describieron las problemticas planteadas
por los modelos de procesos de desarrollo existentes y cmo las metodologas giles, en
particular AgEnD, proponan principios para mitigar los riesgos asociados a la
complejidad inherente del desarrollo de software (descrita por Fred Brooks). Esta
descripcin pretende auxiliar al lector a entender el porqu de los principios sobre los
Marcelo Schenone
cuales se basan las metodologas giles y que dirigirn todos los objetivos de la solucin
propuesta ms adelante.
En el captulo 3 se comenz a desglosar la metodologa propuesta para su
entendimiento en detalle. Partiendo de una definicin de aspectos abarcativos de un
proceso mencionada por Alistair Cockburn, el texto analiza los diversos elementos que
componen AgEnD: roles, artefactos, fases, disciplinas, hitos, patrones de desarrollo.
Manteniendo la ideologa de priorizar a las personas sobre el proceso, se trato de poner
continuamente el nfasis en el factor humano tratando de mantener el overhead
metodolgico al mnimo posible. Asimismo, todos los problemas planteados en el
capitulo anterior tienen una respuesta tangible en la metodologa. Se trat de aprender
de los viejos errores y de generar un repositorio de buenas prcticas.
Avanzando en el captulo se propusieron una serie de tcnicas y estudios que
permiten implementar una metodologa gil dentro de una organizacin. Esta parte
constituye en s uno de los principales aportes al espectro de metodologas giles por no
encontrarse muchas lneas de investigacin hasta el momento y menos que tomen en
cuenta otras ramas del conocimiento distintas a la informtica. Es creencia del autor que
es de suma importancia: empezar a formalizar la mejora del proceso dentro de una
organizacin a consecuencia del incremento continuo en la complejidad de los sistemas
construidos y disponer de personas que se encarguen de velar por mantener y actualizar
un proceso lo ms gil e institucionalizado posible valor estratgico a futuro de los
SEPG (Software Engineering Process Group) que ya se encuentran en las grandes
organizaciones.
En el captulo 4 se presentaron dos casos de xito de implementacin de AgEnD
en distintas organizaciones. Estos proyectos contaron con la presencia constante del
autor de la tesis, quien realiz la capacitacin inicial de las personas respecto a AgEnD
y quien continuamente recab informacin de cmo el proceso era llevado a la prctica,
adaptndolo de ser necesario. Estas puestas en prctica resultaron positivas ya que
dieron una cierta tangibilidad a una tesis de ingeniera de software fuertemente
orientada hacia aspectos conceptuales.
En relacin con puntos de investigacin a futuro el autor evaluar la posibilidad
de crear una herramienta CASE que ayude a customizar un proceso gil para un
proyecto en particular. Asimismo, se iniciaron lneas de investigacin en otras
Marcelo Schenone
Marcelo Schenone
recomendados por AgEnD. Los mismos podrn ser tomados por el Coordinador como
punto de partida al momento de implementar la metodologa en la organizacin.
Los templates que se ofrecen son para los siguientes artefactos:
Visin
Lista de Riesgos
Descripcin de la Arquitectura
Casos de Prueba
Nota de Entrega
Dado que los mismos son documentos totalmente independientes de esta tesis, se
incluyen en los distintos formatos generados por cada herramienta al fin de la misma.
Marcelo Schenone
LANGUAGE LEVEL
PRODUCTIVITY AVERAGE
-------------------------
1-3
5 to 10 Function Points
4-8
10 to 20 Function Points
9 - 15
16 to 23 Function Points
16 - 23
15 to 30 Function Points
24 - 55
30 to 50 Function Points
Above 55
Researching Languages
Counting Function Points And Source Code
Actual counts of Function Points and source code statements were performed. Samples of
counting Function Points and source code statements were done on Ada, several BASIC
Marcelo Schenone
LANGUAGE
1032/AF
LEVEL
AVERAGE SOURCE
STATEMENTS PER
FUNCTION POINT
20.00
16
1.00
320
3.00
107
4.00
80
16.00
20
70.00
Access
8.50
38
Ada 83
4.50
71
Ada 95
6.50
49
AI shell default
6.50
49
ANSI BASIC
5.00
64
ANSI COBOL 74
3.00
107
ANSI COBOL 85
3.50
91
25.00
13
ANSI SQL
Marcelo Schenone
Application Builder
16.00
20
Application Manager
9.00
36
Assembly (Basic)
1.00
320
Assembly (Macro)
1.50
213
Associative default
5.00
64
15.00
21
BASIC
3.00
107
BASIC A
2.50
128
Basic assembly
1.00
320
Berkeley PASCAL
3.50
91
BETTER BASIC
3.50
91
2.50
128
C Set 2
3.50
91
C++
6.00
53
11.00
29
Eclipse
6.50
49
EIFFEL
15.00
21
EXCEL 1-2
51.00
EXCEL 3-4
55.00
EXCEL 5
57.00
9.50
34
21.00
15
8.50
38
HTML 2.0
20.00
16
HTML 3.0
22.00
15
IBM CICS/VS
8.00
40
3.50
91
IBM VS COBOL
3.00
107
IBM VS COBOL II
3.50
91
INFORMIX
8.00
40
JAVA
6.00
53
JCL
1.45
221
LISP
5.00
64
50.00
LOTUS Macros
3.00
107
Machine language
0.50
640
Macro assembly
1.50
213
MATHCAD
60.00
Microsoft C
2.50
128
MODULA 2
4.00
80
50.00
MS C ++ V. 7
6.00
53
MS Compiled BASIC
3.50
91
awk
DELPHI
FOXPRO 2.5
GENEXUS
Haskell
MOSAIC
Marcelo Schenone
Natural language
0.10
3200
Non-procedural default
9.00
36
Notes VIP
9.00
36
11.00
29
5.00
64
Object LISP
11.00
29
Object LOGO
11.00
29
Object PASCAL
11.00
29
8.00
40
14.00
23
PARADOX/PAL
9.00
36
PASCAL
3.50
91
PERL
15.00
21
15.00
21
PILOT
6.00
53
PL/I
4.00
80
PL/M
4.50
71
PL/S
3.50
91
PowerBuilder
20.00
16
POWERHOUSE
23.00
14
8.00
40
12.00
27
PRO-IV
5.50
58
Problem-oriented default
4.50
71
Procedural default
3.00
107
Professional PASCAL
3.50
91
20.00
16
PROGRESS V4
9.00
36
PROLOG
5.00
64
QBasic
5.50
58
QUATTRO
51.00
QUATTRO PRO
51.00
Query default
25.00
13
QUICK BASIC 1
5.00
64
QUICK BASIC 2
5.25
61
QUICK BASIC 3
5.50
58
Quick C
2.50
128
Quickbuild
11.50
28
QUIZ
22.00
15
Reuse default
60.00
REXX (MVS)
4.00
80
REXX (OS/2)
7.00
46
RPG I
4.00
80
Object-Oriented default
OBJECT Assembler
ORACLE
Oracle Developer/2000
PPL (Plus)
Pro-C
Marcelo Schenone
RPG II
5.50
58
RPG III
5.75
56
57.00
SIMULA 67
7.00
46
Simulation default
7.00
46
SMALLTALK 286
15.00
21
SMALLTALK 80
15.00
21
SMALLTALK/V
15.00
21
SQL
25.00
13
SQL-Windows
27.00
12
Statistical default
10.00
32
3.50
91
11.00
29
3.50
91
11.00
29
Turbo C
2.50
128
TURBO C++
6.00
53
TURBO EXPERT
6.50
49
Visual Basic 1
7.00
46
Visual Basic 2
7.50
43
Visual Basic 3
8.00
40
Visual Basic 4
9.00
36
Visual Basic 5
11.00
29
8.00
40
Visual C++
9.50
34
Visual COBOL
16.00
20
Visual Objects
20.00
16
VisualAge
15.00
21
VisualGen
18.00
18
Marcelo Schenone
Anexo C - Glosario
Casos de Uso. Notacin utilizada para representar los requerimientos funcionales de un
sistema basada en el esquema propuesto por Ivar Jacobson a principios de la dcada del
90.
CVS (Concurrent Versions System). Herramienta que permite seguir los cambios a un
conjunto de archivos a lo largo del tiempo. CVS es comnmente usado en el desarrollo
de software para:
Marcelo Schenone
Marcelo Schenone
Referencias Bibliogrficas
[Alexander, 1977] Alexander, Christopher, A Pattern Language, New York, Oxford
University Press, 1977.
[Alexander, 1979] Alexander, Christopher, The Timeless Way of Building, New York,
Oxford University Press, 1979.
[Alur, 2001] Alur, Deepak, John Crupi, Dan Malks, Core J2EE Patterns, New York:
Prentice Hall, 2001.
[Beck, 2000] Beck, Kent, Extreme Programming Explained, Addison-Wesley The XP
Series, 2000.
[Beck, 2002] Beck, Kent, Test-Driven Development By Example, Addison-Wesley,
November 2002.
[Boehm, 1981] Boehm, Barry W., Software Engineering Economics, Prentice Hall,
1981.
[Boehm, 1988] Boehm, Barry W., A Spiral Model of Software Development and
Enhancement, IEEE Computer, Vol. 21, No. 15 (May 1988) pp. 61-72.
[Boehm, 1995] Boehm, Barry W., Anchoring the Software Process, USC, November
1995.
[Boehm, 2000] Boehm, Barry W., Ellis Horowitz, Ray Madachy, Donald Reifer,
Bradford K. Clark, Bert Steece, A. Winsor Brown, Sunita Chulani, Chris Abts, Software
Cost Estimation with Cocomo II, Prentice Hall, 2000.
[Booch, 1999] Booch, Grady, Ivar Jacobson, James Rumbaugh, The Unified Modeling
Language User Guide, Addison-Wesley Object Technology Series, 1999.
[Brooks, 1975] Brooks, Frederick P., The Mythical Man Month, Reading, Mass.:
Addison-Wesley, 1975.
Marcelo Schenone
[Brooks, 1987] Brooks, Frederick P., No Silver Bullet: Essence and Accidents of
Software Engineering, IEEE Computer, Vol. 20, No. 4 (April 1987) pp. 10-19.
[C3, 1998] C3 Team, Chrysler Goes to Extremes, Distributed Computing, (October
1998) pp. 24-28.
[Calligo, 2003] Calligo, Anbal, Marcelo Schenone, Tcnicas de Produccin de
Software I Modelos de Proceso de Desarrollo, Facultad de Ingeniera, UBA, 2003.
[Charvat, 2003] Charvat, Jason, Project Management Methodologies: Selecting,
Implementing, and Supporting Methodologies and Processes for Projects, John Wiley
& Sons, 2003.
[Coad, 1998] Coad, Peter, Eric Lefebvre, Jeff De Luca, Feature-Driven Development,
http://www.cs.jhu.edu/~scott/oos/software/togetherj/help/UsersGuide/Feature_Driven_Development.htm, 1998.
[Coad, 1999] Coad, Peter, Eric Lefebrve, Jeff De Luca, Java Modeling in Color with
UML, Prentice Hall, 1999.
[Coad, 2000] Coad, Peter, Feature-Driven Development and Extreme Programming,
http://www.togethercommunity.com/coad-letter/Coad-Letter-0070.html, Coad Letter,
Issue 70, July 2000.
[Cockburn, 1998] Cockburn, Alistair, Surviving Object Oriented Projects, AddisonWesley Object Technology Series, 1998.
[Cockburn, 1999] Cockburn, Alistair, Characterizing People as Non-Linear, FirstOrder Components in Software Development,
http://members.aol.com/humansandt/papers/nonlinear/nonlinear.htm, October 1999.
[Cockburn, 2000a] Cockburn, Alistair, Writing Effective Use Cases, Addison-Wesley,
2000.
[Cockburn, 2000b] Cockburn, Alistair, Just-In-Time Methodology Construction,
http://crystalmethodologies.org/articles/jmc/justintimemethodologyconstruction.html,
January 2000.
Marcelo Schenone
Marcelo Schenone
Marcelo Schenone
Marcelo Schenone
[Standish, 1999] The Standish Group, CHAOS: A Recipe for Success, The Standish
Group International, 1999.
[Stapleton, 1997] Stapleton, Jennifer, DSDM Dynamic Systems Development Method,
Addison-Wesley, 1997.
[Sun, 2003] Architecting and Designing J2EE Applications, Copyright 2003 Sun
Microsystems Inc., 2003.
[SWEBOK, 2001] Software Engineering Body of Knowledge, http://www.swebok.org/,
2001.
[Wainstein, 2000] Wainstein, Martn, Intervenciones con Individuos, Parejas, Familias
y Organizaciones, EUDEBA, Universidad de Buenos Aires, 2000.
[Weinberg, 1998] Weinberg, Gerald M., The Psychology of Computer Programming,
Silver Edition, Dorset House, 1998.
[Williams, 2000] Williams, Laurie, Robert R. Kessler, Ward Cunningham, Ron Jeffries,
Strengthening the Case for Pair Programming, IEEE Software, Vol. 17, No. 4
(July/August 2000) pp. 19-25.
[Williams, 2002] Williams, Laurie, Robert R. Kessler, Pair Programming Illuminated,
Addison-Wesley, 2002.
Marcelo Schenone
Agile Alliance
Adaptive Software
Development
Crystal
DSDM
dX
Robert Martin:
http://www.objectmentor.com/publications/RUPvsXP.pdf
Extreme Modeling
FDD
SCRUM
XP
Marcelo Schenone
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Introduccin .......................................................................................................................... 2
Referencias .................................................................................................................................................. 2
2. Posicionamiento ................................................................................................................... 2
Situacin Actual ........................................................................................................................................... 2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Introduccin
[Descripcin del documento y del contexto del proyecto de desarrollo. Se identifica al Cliente y el
propsito detrs de la construccin del sistema.]
Referencias
[Indicaremos todos los artefactos relacionados con este documento.]
2. Posicionamiento
Situacin Actual
[Descripcin del problema actual que se presenta y la forma en que el sistema beneficiar a los
usuarios mediante una solucin dada.]
3. Stakeholders y Usuarios
Stakeholders identificados
[Tabla que muestra a los stakeholders involucrados en el proyecto. Se da una breve descripcin
de cada uno y se analiza el impacto de este en la solucin.]
Usuarios identificados
[Tabla que muestra a los usuarios que tendr el sistema. Se da una breve descripcin de cada uno
y se analiza las responsabilidades en relacin al sistema en construccin.]
5. Otros Requerimientos
[A continuacin se detallan las caractersticas del producto en forma de requerimientos no funcionales
de alto nivel, restricciones a ser impuestas a la solucin y reglas del negocio que determinarn la
descripcin de la arquitectura candidata resultante.]
<<Datos de la empresa>>
<<Logo Empresa>>
Requerimientos No Funcionales
[Requerimiento No Funcional 1.]
[Requerimiento No Funcional 2.]
...
[Requerimiento No Funcional X.]
Restricciones
[Restriccin 1.]
[Restriccin 2.]
...
[Restriccin X.]
Reglas del Negocio Clave
[Regla del Negocio 1.]
[Regla del Negocio 2.]
...
[Regla del Negocio X.]
<<Datos de la empresa>>
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
2. Riesgos.................................................................................................................................. 2
<<Identificacin del Primer Riesgo>>.......................................................................................................... 2
Descripcin........................................................................................................................................................2
Criticidad............................................................................................................................................................2
Probabilidad de Ocurrencia...............................................................................................................................2
Impacto..............................................................................................................................................................2
Estrategia de Mitigacin ....................................................................................................................................2
Plan de Contingencia ........................................................................................................................................2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Introduccin
Propsito
[Breve comentario del propsito de este documento. Se puede tomar la descripcin de AgEnD.]
2. Riesgos
[A continuacin se enumerarn todos los riesgos que presenta el proyecto. En dicha lista deben figurar
tanto los riesgos de management identificados por el Lder de Proyecto, como los riesgos ms tcnicos
identificados por el Arquitecto.]
<<Identificacin del Primer Riesgo>>
Descripcin
[Breve descripcin del riesgo.]
Criticidad
[Indicar el nivel de criticidad en caso de que el riesgo se materialice. El rango puede
estar en una escala de alta, media o baja.]
Probabilidad de Ocurrencia
[Indicar la probabilidad de que ocurra el riesgo en el proyecto. El rango puede estar en
una escala de alta, media o baja.]
Impacto
[El impacto est dado por el producto de la criticidad y la probabilidad de ocurrencia.
En base a esto los riesgos sern priorizados y monitoreados por el Lder de Proyecto y el
Arquitecto. Por ejemplo, un riesgo con criticidad alta y probabilidad de ocurrencia alta
deber ser monitoreado frecuentemente.]
Estrategia de Mitigacin
[Indicar la estrategia a ser utilizada para minimizar el impacto del riesgo en caso que
este se materialice.]
Plan de Contingencia
[Indicar el plan de contingencia que ser tenido en cuenta en caso que la estrategia de
mitigacin no tenga xito.]
<<Identificacin del Segundo Riesgo>>
...
<<Datos de la empresa>>
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Breve Descripcin ................................................................................................................ 2
2. Actores .................................................................................................................................. 2
3. Flujo de Eventos ................................................................................................................... 2
3.1. Flujo Bsico........................................................................................................................................... 2
3.2. Flujos Alternativos................................................................................................................................. 2
3.3. Flujos de Excepcin.............................................................................................................................. 2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Breve Descripcin
[Breve descripcin del propsito del caso de uso. Recordar que el mismo debe dar algn valor a algn
actor del sistema.]
2. Actores
[Enumerar los actores que participan en este caso de uso.]
3. Flujo de Eventos
[A continuacin se describe la secuencia de pasos desde que el actor dispara el caso de uso hasta que la
interaccin llega a su fin.]
3.1. Flujo Bsico
[El flujo bsico representa la interaccin normal del caso de uso. Es la situacin en que todos los
pasos se ejecutan normalmente, sin existir excepciones ni errores.]
3.2. Flujos Alternativos
[Los flujos alternativos se dan ante alternativas complejas dentro de la ejecucin del flujo las
cuales ocurren ante ciertos eventos alternos de la interaccin.]
3.3. Flujos de Excepcin
[Los flujos de excepcin ocurren cuando existen excepciones en la ejecucin del flujo bsico
debida a errores internos de la aplicacin o de la interaccin del usuario con esta.]
4. Requerimientos Suplementarios
[Indicar aquellos requerimientos suplementarios relacionados nicamente con este caso de uso.
Recordar que los requerimientos suplementarios globales van en el SRS]
5. Precondiciones
[Indicar las condiciones que deben darse para que se pueda disparar la ejecucin de este caso de uso.]
6. Poscondiciones
[Indicar como quedar el sistema despus que se termine la ejecucin de este caso de uso.]
7. Puntos de Extensin
[Puntos a partir de los cuales se extiende el flujo bsico de este caso de uso. Relacionado con la relacin
<<extends>> de UML.]
8. Diagramas Asociados
[Colocar aquellos diagramas asociados con este caso de uso. En este punto se puede colocar el modelo
de casos de uso afectado a este caso de uso, diagrama de estado, diagrama de actividad, prototipo de
GUI, etc.]
9. Supuestos y Dudas
[Dejar constancia de los supuestos que se han tomado en la especificacin del casos de uso as como las
dudas que el Analista tiene pendiente y debern ser resueltas con el Cliente.]
<<Datos de la empresa>>
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Introduccin
Propsito
[Breve comentario del propsito de este documento. Se puede tomar la descripcin de AgEnD.]
Referencias
[Indicaremos todos los artefactos relacionados con este documento.]
2. Requerimientos Funcionales
Detalle de Requerimientos Funcionales
[A continuacin se enumerarn todos aquellos requerimientos de carcter funcional que tengan
que ver con aspectos ms tcnicos relacionados con la solucin. Los mismos quedan fuera de las
especificaciones de los casos de uso.]
3. Requerimientos Suplementarios
Requerimientos No Funcionales
[A continuacin se enumerarn todos aquellos requerimientos no funcionales que son globales a
la aplicacin. Los mismos refieren a las cualidades sistmicas asociadas con: usabilidad,
performance, mantenibilidad, seguridad, tolerancia, etc.]
Restricciones
[A continuacin se enumerarn todas las restricciones que se aplican a la solucin planteada. Las
mismas restringen los grados de libertad al momento de disear una solucin determinada a un
problema.]
Reglas del Negocio
[A continuacin se enumerarn todas aquellas reglas del negocio globales a la aplicacin. Las
mismas tienen que ver con las polticas y/o condiciones que se dan en los procesos del negocio y
que deben ser implementadas en la solucin.]
<<Datos de la empresa>>
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Introduccin
Propsito
[Breve comentario del propsito de este documento. Se puede tomar la descripcin de AgEnD.]
Referencias
[Indicaremos todos los artefactos relacionados con este documento.]
2. Objetivos Arquitectnicos
[Se mencionarn los requerimientos no funcionales y restricciones que guiaron el trabajo del arquitecto.
Los mismos estarn basados en lo que fue documentado en el SRS, pero haciendo nfasis sobre como la
arquitectura candidata resuelve cada uno de estos.]
4. Vista Lgica
[Es una descripcin de una vista de la arquitectura del software a travs de la evaluacin realizada de
los requerimientos funcionales y no funcionales. Representa la organizacin en paquetes de servicios y
subsistemas y la organizacin de estos subsistemas en layers. Tambin se describen aqu las
realizaciones de caso de uso ms importantes.]
5. Vista de Despliegue
[La vista de despliegue permitir describir la distribucin fsica posible de los diferentes nodos de
procesamiento describiendo adems el modelo de crecimiento de la solucin.]
6. Bibliografa
[En este apartado se podr mencionar la bibliografa de donde se puede obtener ms informacin de los
elementos mencionados en este documento.]
<<Datos de la empresa>>
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Introduccin
Propsito
[Breve comentario del propsito de este documento. Se puede tomar la descripcin de AgEnD.]
Referencias
[Indicaremos todos los artefactos relacionados con este documento.]
<<Datos de la empresa>>
<<Logo Empresa>>
Historia de Revisin
Fecha
Versin
Descripcin
Autor
Tabla de Contenidos
Tabla de Contenidos ................................................................................................................ 1
1. Introduccin .......................................................................................................................... 2
Propsito ...................................................................................................................................................... 2
Referencias .................................................................................................................................................. 2
3. Nuevos Features................................................................................................................... 2
Lista de Nuevos Features ............................................................................................................................ 2
Features ....................................................................................................................................................... 2
<<Datos de la empresa>>
<<Logo Empresa>>
1. Introduccin
Propsito
[Breve comentario del propsito de este documento. Se puede tomar la descripcin de AgEnD.]
Referencias
[Indicaremos todos los artefactos relacionados con este documento.]
2. Informacin de la Entrega
Overview
[Breve descripcin del contenido de la entrega que se lleva a cabo. Se enumeran todos los
artefactos que la misma incluye, identificando el nmero de versin donde corresponda.]
3. Nuevos Features
Lista de Nuevos Features
[Listado de los features que estn contenidos en la versin que se entrega al Cliente. Orientado a
entregables de implementacin.]
Features
[Feature 1.]
[Feature 2.]
...
[Feature X.]
Lista de Limitaciones
[Listado de las limitaciones de la versin entregada. Se detallarn aquellas cuestiones que
quedaron fuera de la implementacin corriente.]
<<Datos de la empresa>>
<<Logo Empresa>>
Limitaciones
[Limitacin 1.]
[Limitacin 2.]
...
[Limitacin X.]
<<Datos de la empresa>>