Embed Size (px)
Citation preview
57
CAPÍTULO 3. MARCO METODOLÓGICO
3.1 Introducción
En el presente capítulo se hace un análisis de tres metodologías para la gestión de proyectos de
software: Proceso Unificado (PU), Método de Desarrollo de Sistemas Dinámico (DSDM) y
eXtreme Programming (XP), cuyos requisitos son aplicables al proyecto actual. Posterior al
análisis se realiza la selección de una de estas metodologías para elaborar el proyecto siguiendo
el proceso y lineamientos indicados en la misma.
Tras la selección de la metodología, se hace una introducción al framework metodológico
Desarrollo Dirigido por Modelado Ágil (AMDD, Agile Modeling Driven Development), el cual
proporciona buenas prácticas y principios para el modelado efectivo y la documentación de
sistemas basados en software.
3.2 Metodologías alternativas para el desarrollo de la solución
3.2.1 Proceso Unificado – PU
El Proceso Unificado es una metodología en la cual el proceso de desarrollo de software debe
ser “guiado por los casos de uso, de arquitectura céntrica, iterativo e incremental”. En términos
generales se establece que:
En la actualidad la tendencia en el software se encamina a sistemas mayores
y complejos. Eso se debe en parte al hecho de que las computadoras se
volvían más poderosas cada año, lo que alentaba que los usuarios esperaran
más de ellas. Esta tendencia también la impulsó el uso expandido de Internet
para el intercambio de todo tipo de información. El apetito por un software
cada vez más complejo crece en la medida que se aprende como mejorarse
un producto desde que sale hasta uno que llega el otro. Se necesita un
software que se adapte a las necesidades, pero que, a su vez, hace el software
más complejo. [27]
58
El proceso unificado surge como la combinación de las mejores características de métodos
individuales para la ingeniería de software, en el tiempo en el cual, se iniciaban los lenguajes
orientados a objetos. De la unión de estas características, en adición a otras propuestas por
expertos, se elaboró el lenguaje unificado de modelado (UML, Unified Model Language), el
cual contiene una notación altamente descriptiva y detallada para el desarrollo de sistemas
orientados a objetos.
Mientras que el UML proporciona la tecnología para apoyar la práctica de la ingeniería del
software orientada a objetos, no proporciona el marco de proceso para la aplicación de la
tecnología. De aquí es donde surge el Proceso Unificado, en el cual se trabaja la ingeniería del
software orientada a objetos y utilizando UML. Adicionalmente proporciona una forma de
trabajar bajo el ciclo de vida iterativo e incremental para satisfacer necesidades específicas.
Fases del proceso unificado
El Proceso Unificado consiste en cuatro fases, las cuales se abarcan el inicio del proyecto y se
produce el modelado del negocio, posterior a ello se llega a la elaboración y donde se produce
el modelo en sus detalles mediante la captura de rendimientos, el análisis y el diseño del
software. La tercera fase es la construcción que es donde se hace la implementación del diseño
obtenido durante la elaboración, haciendo correcciones del diseño en caso de ser necesario. Al
finalizar la fase de construcción e iniciar la fase de transición, se efectúan las pruebas del
software y se hace el despliegue del mismo. A continuación, se hará una descripción más
detallada de lass fases del proceso.
La fase de inicio del PU abarca la comunicación con el cliente y las actividades de planeación.
Al colaborar con los clientes y usuarios finales se identifican los requisitos de negocios para el
software, proponiendo una arquitectura aproximada para el sistema y desarrollando un plan para
la naturaleza iterativa e incremental del sistema subsiguiente. Los requisitos fundamentales de
negocios se describen a través de un conjunto preliminar de casos de uso que describen cuáles
características y funciones son deseables para cada clase importante de los usuarios. Los
productos que se obtienen de esta fase son:
59
Documento de la visión.
Modelo inicial de caso de uso.
Glosario inicial del proyecto.
Caso inicial de negocio.
Evaluación inicial del riesgo.
Plan de proyecto, fases e iteraciones.
Modelo del negocio (si es necesario).
Uno o más prototipos.
La fase de elaboración abarca la comunicación con el cliente y las actividades de modelado del
modelo genérico del proceso. Esta fase refina y expande los casos de uso preliminares que se
desarrollaron como una parte de la fase de inicio; además expande la representación para incluir
cinco visiones diferentes del software: el modelo de caso de uso, el modelo de análisis, el modelo
de diseño, el modelo de implementación y el modelo de despliegue. Los productos que se
obtienen de esta fase:
Modelo de casos de uso
Requisitos suplementarios, incluyendo aquellos no funcionales.
Modelo de análisis
Descripción de la arquitectura del software.
Prototipo arquitectónico ejecutable
Modelo de diseño preliminar
Lista de riesgos
Plan de proyecto, incluyendo el plan de iteración, flujos de trabajo adaptados,
fundamentos, productos técnicos del trabajo y el manual preliminar del usuario.
La fase de construcción del PU utiliza el modelo arquitectónico como entrada y desarrolla o
adquiere los componentes del software que harán que cada caso de uso, sea operativo para los
usuarios finales. Para esto se requiere que los modelos de análisis y diseño se completen para
reflejar la versión final del incremento del software.
60
Modelo del diseño.
Componentes del software.
Incremento integrado del software.
Plan y procedimiento de pruebas.
Casos de prueba.
Documentación del soporte, manuales de usuario, manuales de instalación y descripción
del incremento actual.
La fase de transición abarca las últimas etapas de la actividad genérica de construcción y la
primera parte de la actividad genérica de despliegue. El software se entrega a los usuarios finales
para realizar pruebas beta, y los usuarios retroalimentan con sus observaciones, defectos y
cambios necesarios. Al final de esta fase, el incremento de software se convierte en el
lanzamiento del software utilizable.
Incremento del software integrado.
Reportes de las pruebas beta.
Retroalimentación general del usuario.
La fase de producción del PU es aquella que se realiza posterior a la construcción del software,
y se hace un monitoreo para la producción de nuevo software, proporcionando soporte y
evaluando los informes de defectos y requerimientos de cambios.
3.2.2 Método de Desarrollo de Sistemas Dinámico – DSDM
El Método de Desarrollo de Sistemas Dinámico es uno de los principales enfoques ágiles, la
agilidad y la flexibilidad con la que cuenta, es necesaria para las organizaciones de éxito dentro
de un marco de nivel adecuado de gobernanza del proyecto.
El enfoque es la culminación de dos décadas de experiencia práctica de una amplia gama de
proyectos del sector público y privado.
La filosofía DSDM es que cualquier proyecto debe estar alineado a objetivos estratégicos
claramente definidos y enfoque a la entrega temprana de beneficios reales al negocio.
61
DSDM es independiente del proveedor, cubre todo el ciclo de vida de un proyecto y proporciona
una mejor guía práctica para la entrega a tiempo, en el aspecto del presupuesto de proyecto tiene
adaptabilidad comprobada a los proyectos de la dirección de todos los tamaños y en específico,
para cualquier sector empresarial. La filosofía de la metodología se describe:
Los mejores valores de los negocios emergen cuando los proyectos son
alineados a los propósitos claros del negocio, hace entregas frecuentes y
evoluciona la colaboración de gente motivada y fortalecida.
Los ocho principios de DSDM son:
1. Concentrarse en las necesidades del negocio. Cada decisión tomada durante un proyecto
debe ser vista en el propósito de lograr la meta y proporcionar lo que el negocio necesita
cuando lo necesita.
2. Entregar a tiempo. La entrega de la solución se hace a tiempo en un resultado muy
deseable para un proyecto y es a menudo, el factor más importante de éxito. Una entrega
tardía puede afectar la capacidad de un proyecto, especialmente cuando se involucran
oportunidades de mercado o restricciones legales.
3. Colaboración. Los equipos que funcionan con un espíritu de cooperación activa,
siempre sobrepasan a grupos de individuos trabajando en una asociación inestable. La
colaboración fomenta el entendimiento, la velocidad y la propiedad compartida, lo que
permite a los equipos, rendir en un nivel que excede la suma de sus componentes.
4. Nunca comprometer la calidad. La calidad entregada debe ser la misma con la que se
acordó al principio. Todo trabajo debe lograr ese nivel de calidad – ni más ni menos.
Una solución tiene que ser lo ‘suficientemente buena’. Si el negocio concuerda que las
características alcanzaron los criterios de aceptación, entonces la solución debe ser
suficiente para ser utilizada efectivamente.
5. Construir de forma incremental en bases firmes. Se deben establecer bases firmes para
el proyecto antes de comprometerse con un desarrollo significativo. Se involucra al
entendimiento del alcance del problema del negocio a ser solucionado y la propuesta de
62
solución, pero no en qué tanto el proyecto se ve paralizado por detalles exagerados en
los requerimientos.
6. Desarrollo iterativo. Se utiliza una combinación de desarrollo iterativo, con
demostraciones frecuentes y revisiones comprensivas con retroalimentación, basadas en
tiempo. Soportando cambios como parte del proceso de evolución y permitiendo al
equipo converger a una solución precisa del negocio.
7. Comunicación clara y continua. La pobre comunicación se describe usualmente como la
principal causa del fallo en un proyecto. Se fomenta así una comunicación directa e
informal, con sesiones diarias del equipo, utilizando talleres como facilitadores,
utilizando técnicas visuales de comunicación para modelado y prototipo, demostración
de la evolución en breve y frecuente, mantener la documentación limpia y en tiempo, así
como la búsqueda de una comunicación honesta y transparente.
8. Demostración del control. Es necesario de controlar un proyecto durante todas las fases.
Esto sólo puede ser logrado, con la referencia a un plan de trabajo completo, el cual
deberá estar claramente alineado con los objetivos del negocio.
Estos ocho principios ayudan a dirigir y formar la actitud e idiosincrasia del equipo de trabajo.
Al comprometer cualquiera de los principios, afecta la filosofía de DSDM y se anulan los
beneficios potenciales de la misma.
3.2.3 eXtreme Programming – XP
La Programación Extrema (XP, eXtreme Programing) es una metodología basada en modelos
ágiles de proceso, utiliza un enfoque orientado a objetos y abarca un conjunto de reglas y
prácticas que ocurren en el contexto de cuatro actividades del marco de trabajo: planeación,
diseño, codificación y pruebas.
A continuación, se describen las actividades principales que se realizan durante el proceso de
desarrollo de software utilizando la metodología XP.
Planeación. La cual comienza obteniendo una serie de historias de usuario que describen
las características y funcionalidades requeridas para el software que se construirá. Cada
63
historia la describe el cliente y se coloca en una carta índice. El cliente le asigna un valor,
como prioridad, a la historia basándose en los valores generales del negocio respecto de
la característica o la función. Cada historia es analizada por el equipo de trabajo y se le
asigna un costo, el cual se mide en semana de desarrollo. Si la historia requiere más de
tres semanas, se solicita al cliente que la divida en historias de usuario menores y se hace
una nueva asignación de valor y costo.
La decisión de las actividades para las próximas tres semanas se hará en conjunto de los
clientes con el equipo. Posterior a ese compromiso, en el cual se describen las historias
que se incluirán, las fechas de entrega y otras cuestiones del proyecto, las historias se
podrán ordenar según alguna de las siguientes tres maneras:
1) Todas las historias se implementarán de forma inmediata.
2) Las historias con valor más alto se moverán en el programa de prioridades y se
implementarán al principio.
3) Las historias más riesgosas se moverán dentro del programa de prioridades y se
implementarán al principio.
Una vez entregado el primer incremento, se calcula la velocidad del proyecto, es decir,
el número de historias implementadas en el primer lanzamiento. Con esto, es posible
estimar las fechas de entrega, determinar si el compromiso es excesivo, y verificar si el
contenido de los lanzamientos se modifica o se cambian las fechas de las entregas finales.
Conforme se avanza el desarrollo, el cliente puede agregar historias, cambiar el valor de
la historia existente, dividir historias o eliminarlas.
Diseño. Siempre se prefiere un diseño simple respecto de una presentación más
compleja. Además, el diseño ofrece una guía de implementación para una historia como
está escrita, ni más ni menos, desaprobando el diseño de funcionalidad extra.
La Programación Extremas se apoya en el uso de tarjetas Clase-Responsabilidad-
Colaboración (CRC), que describe el diseño en la interacción y colaboración entre
64
distintos objetos, permitiendo visualizar, identificar y organizar las clases orientadas al
objeto que son relevantes para el incremento del software actual.
Aunque la utilización de estas tarjetas es común, también es posible utilizar diferentes
herramientas como lo son representaciones en UML.
Si se encuentra un problema difícil de diseño como parte de una historia, la XP
recomienda la creación inmediata de un prototipo operacional de esa porción del diseño.
El prototipo del diseño, llamado solución pico, se implementa y evalúa con el propósito
de reducir el riesgo en la implementación verdadera.
Asímismo, la XP apoya la refactorización, en la cual se modifica la estructura interna
del código, pero sin modificar el comportamiento del programa, funcionando como una
manera de limpiar el código y mejorar la estructura interna. Además de mejorar la
claridad y facilitar la comprensión del código, también permite la clarificación de
conceptos para ayudar al mantenimiento de implementaciones futuras. Una noción
central en la Programación Extrema es que el diseño ocurre tanto antes como después
del comienzo de la codificación.
Refactorizar significa que el diseño ocurre de manera continua a medida que se construye
el sistema, de hecho, la actividad de construcción misma, le proporciona al equipo de
XP una guía sobre cómo mejorar el diseño.
Codificación. La XP recomienda que después de diseñar las historias y realizar el trabajo
de diseño preliminar el equipo no debe moverse hacia la codificación, sino que debe
desarrollar una serie de pruebas de unidad que ejerciten cada una de las historias que
vayan a incluirse en el lanzamiento actual. Una vez creada la prueba de unidad, el
desarrollador es más capaz de centrarse en lo que debe implementarse para pasar la
prueba de unidad de codificación o de desarrollo.
Cuando el código del componente está completo, la unidad puede probarse de inmediato,
y así proporcionar una retroalimentación instantánea a los desarrolladores. La
65
metodología XP recomienda que dos personas trabajen juntas en una estación de trabajo
para crear el código de una historia. Esto proporciona un mecanismo de para la
resolución de problemas en tiempo real y el aseguramiento de la calidad en las mismas
condiciones. También alienta que los desarrolladores se mantengan centrados en el
problema que se tiene a la mano. En la práctica, cada persona tiene un papel sutilmente
diferente.
Cuando los programadores completan su trabajo, el código que desarrollaron se integra
con el trabajo de otros, en algunos casos esto lo lleva a cabo diariamente el equipo de
integración. Esta tragedia de “integración continua” ayuda a evitar problemas de
compatibilidad e interfaz y proporciona un ambiente de “prueba de humo” que ayuda a
descubrir los errores desde el principio.
Pruebas. Previamente se ha mencionado la creación de pruebas de unidad antes de
comenzar la codificación como un elemento clave. Las pruebas de unidad deben
implementarse con un marco de trabajo que permita automatizarlas (por lo tanto, pueden
ejecutarse de manera fácil y repetida). Esto apoya una estrategia de regresión de prueba
cuando el código se modifica (al cual, a menudo se le confiere la filosofía de XP de
refactorizar).
Cuando las unidades individuales de prueba se organizan en un “conjunto universal de
pruebas”, las pruebas de integración y validación del sistema pueden realizarse a diario.
Esto proporciona al equipo de XP una indicación continua del progreso y también puede
encender luces de emergencia previas, en caso de que las cosas salgan mal.
Las pruebas de aceptación de la XP, también llamadas pruebas del cliente, las define el
cliente y se enfocan en las características generales y la funcionalidad del sistema,
elementos visibles y revisables por el cliente. Las pruebas de aceptación se derivan de
las historias del usuario que se han implementado como parte de un lanzamiento de
software.
66
Cabe destacar que esta metodología se adapta a grupos pequeños y medianos de trabajo, también
con proyectos de software cuyos tiempos de entrega son limitados, debido a que las entregas se
definen mediante una valoración de las diferentes historias de usuario. La implementación se
mejora en cada una de las iteraciones, permitiendo un desarrollo rápido de las funcionalidades,
optimizando el código y el diseño conforme surgen nuevas características o historias de usuario.
3.3 Selección de la metodología apropiada para el proyecto
Tomando como base la Guía de principiantes en la administración de proyectos de Wrike [28],
se tiene que, de las múltiples opciones disponibles para seleccionar la metodología, es necesario
observar las necesidades del equipo y el proyecto, para lo cual, se proporcionan los siguientes
dos consejos:
1. Comenzar con el fin en mente.
Al mirar los requisitos, los objetivos y las metas del proyecto, debe obtenerse una idea clara
de cómo el entregable final deberá visualizarse y los beneficios que proporcionará. Por
ejemplo:
o Si se tratara de un objeto físico como una construcción de un edificio o una vivienda
con materiales definidos y una expectativa clara de los stakeholders, una
metodología secuencial como Cascada o Ruta Crítica es la más adecuada.
o Si es un software o aplicación que no ha sido implementada en lo absoluto, una
metodología ágil puede ser lo que se requiere para el proyecto.
o Si para la organización es importante mantener la sustentabilidad en su producto,
entonces se deberá utilizar una metodología PRiSM (Projects integrating
Sustainable Methods).
o Si el desarrollo rápido de un producto es lo más importante de un producto mínimo,
entonces se deberá considerar metodologías basadas en procesos, como lo son Lean
o Lean Six Sigma.
2. Evaluar lo que ya está funcionando.
67
Al seleccionar la metodología, es importante observar los procesos que ya se están llevando
a cabo, y también los proyectos que el equipo ha completado satisfactoriamente en el pasado.
Es decir, en qué tipo de ambiente de trabajo el equipo sobresale.
o Si prospera la colaboración y la integración de nuevas ideas mientras se trabaja,
incluso durante las últimas etapas, debido a las necesidades cambiantes, entonces se
deberá considerar metodologías como lo son Scrum, KanBan, XP o APF.
o Si el equipo opera ordenadamente en planes estructurados que completen tareas
secuencialmente, entonces las metodologías en cascada, de proceso unificado, de
ruta crítica y de la gestión de proyectos por cadena crítica, son las más apropiadas
para el equipo.
3.3.1 Detección de las variables de selección
Tomando lo anterior en consideración, es posible detectar que GAAPI consiste en un producto
de software que, aunque existan propuestas alternativas similares, sería la primera
implementación en su entorno, teniendo en cuenta lo anterior como punto de partida, es posible
descartar metodologías lineales, considerando las metodologías ágiles.
Dentro de las metodologías ágiles descritas en este mismo capítulo, se encuentran DSDM y XP.
Estas dos metodologías en particular, pueden acoplarse a proyectos de software en web, sin
embargo, tienen diferencias, tal como se describe en el sitio de Cunningham & Cunningham,
una empresa especializada en programación orientada a objetos.
Al comparar entre estas dos metodologías se puede deducir lo siguiente:
DSDM utiliza restricciones de tiempo para controlar los riesgos de la iteración, mientras
que XP utiliza técnicas más responsivas.
DSDM coloca poco énfasis, liberando prototipos concretos de forma inmediata, en lugar
de un producto completo en tiempo.
DSDM carece de la percepción en la reducción de la curva de cambio de costos, es decir,
no considera los cambios en los costos como parte de su modelo de evaluación en cada
una de las iteraciones.
68
Adicional a las diferencias anteriores, se tiene que XP tiene su enfoque más centrado en la
codificación de la aplicación, mediante la aplicación de técnicas de programación en pares,
refactorización de código, integración regular, creación de pruebas unitarias, etc., a diferencia
de DSDM el cual está orientado a la generación de diversos prototipos.
Se puede entonces entender que la metodología XP es mucho más práctica, ya que se enfoca en
la obtención de resultados concretos, en lugar de realizar ensayos que podrían fallar al resolver
la situación, causando más iteraciones para la resolución del problema real.
Para potenciar las capacidades de análisis y diseño de la metodología, se conjuntan los principios
y buenas prácticas del desarrollo dirigido por modelado ágil, descrito en el apartado 3.4.
3.4 Agile Modeling Driven Development (AMDD)
El Agile Modeling Driven Development (AMDD), por su traducción Desarrollo Dirigido por
Modelado Ágil, es un framework metodológico de desarrollo de software, basado en la
aplicación de prácticas para el modelado efectivo y la documentación de sistemas basados en
software.
Proceso de Software
Principios y Prácticas delAgile Modeling(AM)
Otras Técnicas(ej. Scrum, Refactorización)
Un Proceso Base de Software(ej. XP, RUP, AUP, OpenUP, DSDM, FDD, )
Figura 3.1. Complemento AM para la mejora del proceso de software.
Definido como una colección de valores, principios y prácticas para el modelado de software,
que puede ser aplicado al desarrollo de proyectos de software en una forma ligera. Así como se
muestra en la Figura 3.1, estos principios podrán implementarse sobre metodologías completas
para el desarrollo, permitiendo a los desarrolladores producir procesos de software que cubran
verdaderas necesidades de los stakeholders. Este framework forma parte del desarrollo ágil
disciplinado (DAD).
69
Los valores del Agile Modeling (AM), adopta y extiende los valores de la metodología eXtreme
Programming en su primera versión, los cuales son: comunicación, simplicidad,
retroalimentación, coraje y humildad. Las claves del éxito en el modelado son la comunicación
efectiva entre los desarrolladores y los stakeholders, simplificando el desarrollo de una solución
simple y lograr cubrir las necesidades, obteniendo una retroalimentación frecuente e inmediata,
además de desarrollar el coraje y apego a las decisiones, la humildad para admitir que uno podría
ignorar algo, y otros proporcionan valor añadido a la resolución del proyecto.
La colección de principios en los que se basa AM, tienen la importancia de asumir la simplicidad
de cuando se modela y adopta el cambio, debido a que los requisitos varían con el tiempo. Debe
reconocerse que se presentan cambios incrementales del sistema en el transcurso de tiempo,
permitiendo retroalimentación inmediata del trabajo y asegurando que se reflejan las
necesidades precisas de los stakeholders.
El modelado debe elaborarse con un propósito, y si se tiene desconocimiento sobre lo que se
trabaja y la audiencia del modelo o el documento, entonces se deberá evitar trabajar en ello.
Adicionalmente, se requiere el apoyo de múltiples herramientas de modelado para que el
entendimiento del problema sea efectivo. Un concepto importante del modelado es que los
modelos pueden ser diferentes a documentos que se vuelven obsoletos rápidamente al generar
nuevas representaciones del problema. La forma efectiva de modelado es manteniendo una
comunicación abierta y honesta con el equipo de trabajo y los stakeholders.
La implementación de estas prácticas puede aplicarse en la mayoría de los proyectos de
desarrollo, ya que es innecesario utilizar una metodología ágil para obtener las ventajas
derivadas del AM, a pesar de que uno de los principales objetivos de esta metodología, consiste
en explicar la forma de modelar, utilizando la aproximación en XP.
Agile Modeling y eXtreme Programming
El Agile Modeling (AM) es un proceso de software basado en prácticas, cuyo objetivo es escribir
el cómo modelar y documentar de forma efectiva y ágil. Debido a que el alcance de la
metodología eXtreme Programming (XP) es mayor que el de AM, por lo tanto XP es un
70
candidato considerable para designarse como proceso base, mientras se aplican las técnicas de
AM.
Además, XP incluye el modelado como parte de su proceso, aunque la metodología no es muy
explícita sobre el cómo debe llevarse a cabo.
Considerando que tanto XP como AM son metodologías basadas en la práctica, resulta mucho
más sencillo hacer la integración de ambas metodologías, en contraste con otras, como por
ejemplo el Proceso Unificado (PU).
Modelar es parte de XP
En XP, las historias de usuario son un aspecto fundamental, y los artefactos como las tarjetas
CRC son comunes a los esfuerzos de XP.
Las historias de usuario proporcionan un resumen de alto nivel de los requisitos de un sistema,
ya que son recordatorios para conversar con las partes interesadas, permitiendo consultar
requisitos.
También son utilizadas como entrada principal para la estimación y programación, además de
que dirigen al desarrollo en los casos de prueba de aceptación.
Las tarjetas CRC se utilizan para explorar la estructura, quizás con propósitos conceptuales de
modelado con el propósito de entender el dominio del problema o en su defecto, para el diseño
de la estructura de software.
Adicionalmente a los artefactos anteriores, los desarrolladores pueden crear bosquejos, a
menudo en un pizarrón blanco o una hoja de papel, cuando el uso de las historias de usuario y
las tarjetas CRC no son la mejor opción. Estos artefactos pueden incluir diagramas de clases,
mapas mentales o diagramas en forma libre.
La documentación es necesaria
Lo más importante es entender que la mayor parte de la documentación se produce para personas
externas al equipo de trabajo, por mencionar algunos. Asimismo, la comunicación verbal entre
71
los miembros del equipo reduce la necesidad de documentación, razones por las cuales los
miembros del equipo se deben en la misma ubicación, considerando una realización en la
programación por pares y la propiedad colectiva para promover la comunicación entre los
desarrolladores.
Es también de suma importancia, reconocer que ocasionalmente se requiere documentación
interna para el equipo, como lo son el uso de las historias de usuario, o la información obtenida
de los interesados durante alguna conversación. Lo anterior implica que los miembros pueden
generar documentación si fuera necesario.
Cabe destacar que la generación de documentación se reduce, ya que se utilizan prácticas como
desarrollo de pruebas y el enfoque a pruebas de aceptación. Para los desarrolladores, las pruebas
son una documentación significativa, debido a que muestran explícitamente como el código
funciona. Otra característica que reduce la necesidad de documentación es la simplificación y
refactorización del código, ya que, si el código es suficientemente claro, entonces no existe la
necesidad de crear una documentación que lo describa, por el contrario, si carece de claridad
entonces será necesario refactorizar el código para hacerlo más claro y sencillo de entender.
La confusión sobre el tipo de documentación que se debe generar en la metodología XP, se debe
a que no se especifican los documentos potenciales a crear durante el desarrollo del proyecto.
Adicionalmente, la malinterpretación del concepto “desarrollo a la velocidad de la luz”, es para
algunos evitar generar documentación alguna, lo que está bastante alejado de la realidad. A lo
que el concepto se refiera es únicamente desarrollar los modelos esencialmente requeridos,
generar menos o más es riesgoso, es decir, únicamente crear un documento hasta que se requiere
su elaboración, si se elabora más, es posible que se desperdicie tiempo sobre algo que aún no se
requiere.
Adicionalmente, se deduce que XP puede hacer uso de los artefactos de UML como lo son los
diagramas de actividad, clase, colaboración, componentes, implantación, secuencia, estados y
casos de uso. Lo anterior considerando que, para mantener la práctica ágil en el desarrollo, sólo
deben desarrollarse únicamente los que se requieran y sólo cuando es necesario.
72
3.5 Descripción de la metodología seleccionada
Como se mencionó anteriormente, la metodología eXtreme Programming (XP) sigue un modelo
iterativo e incremental para el desarrollo de software. Durante cada una de las iteraciones el
diseño del software, sus funcionalidades, características y componentes se incrementan,
perfeccionan o se modifican, con el propósito de cumplir con lo requerido por el cliente.
Lo anterior permite que, al implementar funcionalidades en forma escalonada, sea posible
comenzar a utilizar el software, produciendo que los usuarios proporcionen retroalimentación
sobre el funcionamiento del mismo, siendo posible realizar ajustes necesarios para cumplir las
expectativas del cliente.
Siguiendo como base el principio del desarrollo dirigido por modelado ágil, el modelo se crea
en conjunto a los interesados en el proyecto, los cuales describirán lo que se requiere mediante,
por ejemplo, historias de usuario, permitiendo obtener una idea clara de lo que se debe trabajar,
asimismo, se puede complementar el desarrollo del modelo utilizando diferentes herramientas
como mapas mentales, diagramas en forma libre, prototipos de interfaces, flujo de interfaces,
entre otros, ya sea en un pizarrón blanco u hojas de papel.
73
Model Storming(minutos)
Iteración 0: Ideación
Ideación de Requisitos Iniciales
(días)
Ideación de la Arquitectura Inicial
(días)
Modelado de la Iteración(horas)
Desarrollo Dirigido por Pruebas (DDP)
(horas)
Revisiones(opcional)
Todas las Iteraciones(horas)
Identificar los alcances de alto nivel Identificar la pila de requisitos iniciales Identificar una visión arquitectónica
Modelar es parte del esfuerzo en la planeación de la iteración Se necesita modelar lo suficiente para hacer buenas estimaciones Se necesita planear el trabajo de la iteración
Trabajar temas específicos justo en su momento Los interesados en el proyecto participarán activamente Los requisitos evolucionan a través del proyecto El modelo es lo suficientemente bueno por el momento, posteriormente
puede revisarse de nuevo
Desarrollar software funcional utilizando la aproximación basada en pruebas Detalles capturados en forma de especificaciones ejecutables
Figura 3.2. Modelado de las actividades a través del ciclo de vida de un proyecto
La Figura 3.2 describe como las actividades del Agile Modeling Driven Development (AMDD),
encaja dentro de múltiples iteraciones en el ciclo de vida del software. Esto es simplemente una
manera distinta de mostrar que el proyecto inicia con un modelado inicial y que continua durante
cada iteración durante su construcción.
0 1 2 3 n-1 n n+1 Liberación Producción
Ideación de Requisitos
Ideación de la Arquitectura
Configuración y Planeación Inicial
Planeación y Modelado de la Iteración
Model Storming
Desarrollo Dirigido por Pruebas
Pruebas de investigación
... ...
Figura 3.3. AMDD a través del ciclo de vida del desarrollo ágil
Con lo anterior es posible decir que el ciclo de vida de desarrollo ágil mediante el AMDD se
compone de una primera iteración, denominada Iteración 0 o Ideación, en la que se modelan los
requisitos de alto nivel, así como la arquitectura. El resto de las iteraciones realizará un análisis
74
detallado de los requisitos y un modelo más explícito de las características a ser implementadas
durante la iteración. Asimismo, se debe incluir una serie de casos de prueba para verificar que
lo desarrollado corresponda al modelo generado durante la iteración.
3.5.1 Iteración 0: Ideación
El esfuerzo de la ideación se realiza típicamente durante la primera semana del proyecto, tiene
como objetivo identificar el alcance del sistema y una potencial arquitectura para cubrirlo. Para
lograr esta ideación, se requiere realizar el modelado de requisitos de alto nivel y el modelado
de la arquitectura en alto nivel. La meta es que la especificación debe ser medianamente escueta,
de no ser así, representa un riesgo increíble en la práctica, en lugar de explorar los requisitos y
proponer una estrategia completa para el proyecto.
Para proyectos pequeños de varias semanas, este trabajo podrá realizarse en un transcurso de
unas cuantas horas y para proyectos largos de más de un año, quizás convenga invertir dos
semanas.
Modelado de los Requisitos Iniciales
Para la primera iteración del sistema se requerirán varios días para identificar los requisitos de
alto nivel, así como el alcance de la liberación (qué se cree que el sistema deberá hacer). Para el
modelo inicial de requisitos se necesita un modelo de uso, explorando la forma en la que los
usuarios utilizarán el sistema, además de desarrollar un modelo inicial de dominio en el cual se
definen las entidades fundamentales del negocio, las relaciones entre ellas, y un modelo inicial
de interfaz de usuario en el que se explora la interfaz de usuario y los problemas de usabilidad.
Si no fuera suficiente decirlo, el objetivo de este modelado, es el entendimiento general del
problema y no el desarrollo de una documentación detallada. Un factor favorable es aplicar
técnicas de modelo inclusivo en las que se permite la participación de los interesados en el
proyecto.
75
Modelado de la arquitectura inicial
El diseño de la arquitectura inicial se produce con el propósito de identificar una arquitectura
que proporcione la mejor oportunidad para trabajar. Esto permite proporcionar un conjunto de
direcciones viables para el proyecto y proporciona información suficiente para organizar al
equipo de trabajo en la arquitectura.
La perspectiva arquitectónica se elabora normalmente utilizando diagramas en forma libre,
mediante los cuales se explora la infraestructura técnica del proyecto, el dominio inicial de los
modelos, las principales entidades de negocio y sus relaciones, y opcionalmente los casos de
cambio que tendrán ciertos requerimientos potenciales para que el sistema los soporte.
En futuras iteraciones se describirán detalles adicionales de los requisitos iniciales y los modelos
arquitectónicos iniciales, conforme el equipo de desarrollo comprenda más del problema.
En liberaciones posteriores el desarrollo de la ideación se podrá reducir en tiempo o incluso
omitirse, según la situación lo amerite.
3.5.2 Iteración n+: Desarrollo
Durante cada una de las iteraciones subsecuentes en el desarrollo del proyecto, se llevarán a
cabo diferentes actividades que abarcan la planeación, en la cual se realiza captura detallada de
las características a ser implementadas durante la iteración, y durante esta misma actividad es
posible hacer algo de modelado básico sobre lo que el stakeholder desea, en caso de ser
necesario se detallarán modelos posteriormente. Finalmente se realizarán pruebas ejecutables
de la implementación, obteniendo retroalimentación y haciendo ajustes según corresponda.
Planeación de la iteración
En cada iteración para el desarrollo del proyecto, el equipo deberá planear el trabajo que se
llevará a cabo. Los equipos ágiles implementan requerimientos en orden prioritario, removiendo
las iteraciones que requieran mayor trabajo del topo de la pila, permitiendo la estimación precisa
de cada requisito, ver la Figura 3.4.
76
Modelado en mayor detalle
Modelado en menor detalle
AltaPrioridad
BajaPrioridad
Cada iteración implementa los elementos de trabajo de máxima prioridad
Cada nuevo elemento de trabajo es priorizado y añadido a la pila
Los elementos de trabajo pueden ser repriorizados en cualquier momento
Los elementos de trabajo pueden ser quitados en cualquier momento
Figura 3.4. Proceso de administración del cambio de requisitos ágiles.
Para estimar el esfuerzo de cada requisito en forma precisa, es necesario considerar todo el
trabajo requerido utilizando el modelado inicial de la iteración como base. En esta faceta de
modelado se definen estrategias de cómo se implementará cada requisito, modelando
únicamente lo necesario para comunicar ideas con los interesados y otros miembros del equipo.
Este modelado es el análisis y diseño de los requisitos implementados en la iteración.
Model Storming: Modelado en el momento
La mayoría de las sesiones de modelado involucran a algunas personas, normalmente dos o tres,
quienes discuten un problema mientras se esboza en papel o un pizarrón blanco. Estas “sesiones
de model storming” son eventos improvisados, un miembro del proyecto puede pedir a otro que
modele en conjunto, típicamente durante cinco o diez minutos. Las personas pueden reunirse
alrededor de una herramienta de modelado en conjunto (ej. Pizarrón blanco) para explorar el
problema hasta que se llegue a un entendimiento satisfactorio del mismo, posterior a ello se
continuará (a menudo codificando).
77
En resumen, el model storming es el modelado en el momento, en el cual se identifica un
problema que debe resolverse. Se toman unos minutos con los miembros del equipo quienes
puedan apoyar, el grupo explora la situación y después de ello, todos regresan a sus actividades
que realizaban anteriormente.
Especificación ejecutable por medio del desarrollo orientado a pruebas
Durante el desarrollo es bastante común realizar el model storming por varios minutos y luego
codificarlo, siguiendo las prácticas ágiles comunes como el diseño orientado a pruebas y
refactorización, esto durante varias horas e incluso días, al mismo tiempo que se implementa lo
que se acaba de modelar. Los equipos ágiles diseñan la mayoría de sus modelos detallados en
especificaciones ejecutables, a menudo, pruebas de los clientes o pruebas de desarrollo.
El diseño orientado a pruebas promueve la ejecución de pruebas en el código de la aplicación y
especificación detallada de dicho código. Las pruebas de cliente, también conocidas como
pruebas ágiles de aceptación, pueden considerarse como un conjunto de requisitos detallados,
mientras que las pruebas de desarrollador, como diseño detallado. Teniendo pruebas de doble
dirección, es un ejemplo perfecto de dirigir la información desde una fuente única y una práctica
que permite a los desarrolladores progresar rápidamente y reducir la cantidad de documentación
final. Sin embargo, las especificaciones detalladas son sólo parte de una imagen completa, la
especificación de alto nivel también es importante para el éxito cuando se lleva a cabo
efectivamente. Esto es porqué se debe ver más allá del diseño orientado a pruebas considerando
el desarrollo dirigido por modelado ágil.
3.6 Conclusiones
En el capítulo se abordó el análisis de tres distintas metodologías para la gestión de proyectos
de tecnologías de la información, tras perpetuar el análisis, se definió que la metodología más
apropiada para el proyecto es eXtreme Programming (XP), debido a que proporciona un ciclo
iterativo de incrementos de software, así como un proceso para el modelado evolutivo evitando
analizar funciones y características de manera sumamente anticipada, y permitiendo enfocarse
en producir un entregable funcional y operable dentro de su definición.
78
También se observó que la utilización de la metodología acompañada del framework del Diseño
Dirigido por el Modelado Ágil, Agile Modeling, en el cual se establecen principios y buenas
prácticas para el modelado de software, facilita el proceso.
