sábado, 5 de mayo de 2007

Metodologias RUP y XP - [PROCESOS DE DESAROLLO]

Usualmente, al escuchar la palabra "metodología" suamada al ya tan famoso concepto de "procesos de desarrollo de software", lo primero que se nos viene a la mente son 3 preguntas fundamentales, ¿qué es?, ¿Para que sirve?, ¿debo tomarlo en cuenta?, bueno a decir verdad desde que escuche metodologías para el proceso de desarollo de software se me vinieron a la mente más de 3 preguntas, pero todas convergen en estas 3.

Bueno el motivo de este post, es intentar aclarar estas 3 preguntas para poder tener una idea global del concepto en referencia, pero trataré de hacerlo con palabras menos técnicas y muy cotidianas para entenderlas y familiarizarnos con el tema.

¿Qué es?
Es el conjunto de técnicas y procedimientos que nos permiten conocer los elementos necesarios para definir un proyecto de software; en palabras sencillas es la base para la edificación de un proyecto de software, la etapa fundamental para lograr los objetivos buscados con dicho proyecto.

¿Para que sirve?
Básicamente, sirve para subir la "calidad" del software, ese es nuestro objetivo controlar de manera transparente todo el proceso de desarrollo, fundamentalmente nos permite producir lo esperado en el tiempo esperado y con el costo esperado, esto es básico pues muchas veces planeamos hacer algo que finalmente nos toma mas tiempo de lo planeado, por tanto nos produce mas costos y por ellos no logramos completar el proyecto según lo esperado.

¿Debemos tomarlo en Cuenta?
A decir verdad muchos quisieramos no tomarlo en cuenta, pero se han puesto a pensar si un proyecto rindiera los resultados esperados en el tiempo esperado y con los costos estimados y además de eso pudieramos controlarlo de manera clara pensando siempre en la escalabilidad o en los nuevos requerimientos que el negocio pueda necesitar? Pues bien, si queremos que un proyecto sea escalable y flexible a los cambios es lógico pensar que para lograr eso necesitamos tomar en cuenta una de las muchas metodologías para el proceso de desarrollo de software.

Teniendo la idea un poco más clara, la duda que se nos presenta de inmediato es: ¿y cual es la mejor metodología, cual debo de utilizar y porque?, bien talvez podamos resolver esa duda si conocemos que tipos de metodologías existen y cuales son sus principales características, ventajas y desventajas y así podamos inclinarnos por alguna de ellas.

Antes de ir a los conceptos, vale la pena aclarar que implantar un proceso de desarrollo es una labor de mediano a largo plazo, que cuesta tiempo hacer que el equipo involucrado se adapte al proceso pero que es compensado con los resultados obtenidos, es por ello que no tiene sentido ajustarse a un proceso al pie de la letra, sino que hay que adecuarlo a las necesidades de cada empresa.

PROCESOS DE DESARROLLO
Actualmente con el creciente desarrollo tecnológico y la aparición de nuevos modelos de producción, han ido apareciendo nuevas metodologías de proceso de desarrollo, estos procesos han ido tomado características marcadas, lo que ha conllevado en agruparlos en dos grandes grupos, los llamados "métodos pesados" y los "métodos ligeros", la diferencia más saltante entre estos dos grandes grupos es que mientras los métodos pesados intentan obtener los resultados ayudandose proncipalmente de la documentacón ordenada, los métodos ligeros tienen como base de sus resultados a la comunicación e interacción directa con todos los usuarios involucrados en el proceso.

RUP (Rational Unified Process)
Este es uno de los procesos más generales que existe, esta enfocado a cualquier tipo de proyecto así no sea de software, se basa en la documentación generada en cada uno de sus cuatro fases: 1. Intercepción(puesta en marchar), 2. Ealboración(definición, análisis y diseño), 3. Construcción(implementación) y 4. Transición(fin del proyecto y puesta en produccíon) en las cuales se ejecutarán varias iteraciones (según el tamaño del proyecto).

RUP se basa en UseCase(casos de uso) para describir lo que se tiene y lo que se espera del software, está muy orientado a la arquitectura del sistema a implementarse, documentandose de la mejor manera, basandose en UML (Unified Modeling Language - Lenguage de Modelado Unificado).

Para poder usar RUP antes hay que adaptarlo a las características de la empresa, y medir de manera exacta el tiempo, costos y todos los demás recursos involucrados en el proceso.

XP (eXtrme Programing - Programación Extrema)
XP, se basa en el trabajo orientado directamente al objetivo, basandose para esto en las relaciones interpersonales y en la velocidad de reacción para la implementación y para los cambios que puedan surgir durante el desarrollo del proceso.

Esto se logra, minimizando el riesgo de fallo del proceso manteniendo dentro del equipo a un representante "competente" del cliente, este representante es quién responderá a todas las preguntas y dudas que surjan por parte del equipo de desarrollo durante el proceso, de forma que no se retrase la toma de decisiones.

XP se basa en UseStories (historias de uso), estas historias las escrinbe el cliente o su representante dentro de equipo y describen los escenarios claves del funcionamiento del software, a partir de estas se generan los releases (entregas) entre el equipo y el cliente. Estos releases son los que permiten definir las iteraciones necesarias para cumplir con los objetivos, de manera que cada resultado de la iteración sea un programa aprobado por el cliente de quien depende la definición de las siguientes iteraciones.

Una característica saltante de XP, es que el código siempre se produce en parejas, parejas que van cambiando constantemente para lograr así que todo el equipo sepa y pueda modificar según necesidades el código generado, esto logra en el equipo que los integrantes aprendan entre sí y compartan todo el código

FDD (Feature Driven Development)
Este proceso se considera como punto medio entre los procesos pesados y ágiles, aunque en la práctica es más similar a este último. Pensado para proyectos relativamente cortos, al igual que los anteriores también esta basado en iteraciones que producen un software funcional que puede ser visto, probado y monitorizado por el cliente.

Estas iteraciones son decididas en base a las funcionalidades que el software debe tener, funcionalidades definidias por el cliente, este proceso está dividido en cinco fases: 1. Desarrollo de un Modelo General, 2. Construcción de la Lista de Funcionalidades, 3. Plan de releases basadas en las funcionalidades a implementar, 4. Diseñar en base a las funcionalidades definidas y 5. Implementar en base a las mismas funcionalidades.

Aquí en el equipo de trabajo si existen jerarquias, siempre debe haber un jefe de proyecto, y aunque es un proceso considerado ligero también incluye documentación (la mínima necesaria para que algún nuevo integrante pueda entender el desarrollo de inmediato).


COMPARANDO LOS PROCESOS

Esto es más que necesario, pues es lo que nos ayudará a elegir el mejor proceso a implementar para el desarrollo de un software, aquí lo necesario es saber con que recursos contamos (tiempo, dinero, personal) pues depende mucho de estos recursos el poder saber elegir un proceso y claro está debemos tener muy en claro el alcance de nuestro proyecto y los resultados que deseamos obtener y en que tiempo. Es por eso que propondremos una característica del proyecto y en base a ella evaluaremos cada proceso.

TAMAÑO DE LOS EQUIPOS

  • RUP: pensado para proyectos y equipos grandes, con roles desigandos y con una duración extendida.
  • XP : proyectos cortos con equipos pequeños y rotables en cuanto a roles.
  • FDD: pensado para prpyectos y equipos medianos a pequeños, con la flexibilidad que a mayor necesidad de código, mayor organización.
OBTENCIÓN DE REQUISITOS

  • RUP: Se basa en los UseCase (casos de uso) donde se describen los requerimientos de la aplicación desde el punto de vista del usuario.
  • XP: Se Basa en los UseStories (historias de uso), que al igual que el anterior definen los detalles técnicos sin meterse con los detalles de implementación.
  • FDD: Define como se va a proceder despues de recoger los requisitos definidos por el usuario.

CARGA DE TRABAJO

  • RUP: proceso pesado por estar basado mucho en la documentación, documentación que se ve afectada con los posibles cambios volatiles que a los clientes se les ocurre en cuanto a funcionalidades del software, la justificación de esto es que gracias a su plan de desarrollo con el que se controla el desarrollo se pueden reconocer los problemas y fallos de forma temprana y corregirlos.
  • XP: proceso ligero porque no se les asignan roles organizativos al equipo, roles como el modelado o generación de la documentación, esto es reemplazado por la prescencia de un representante especializado del cliente, haciendo así más flexibles los posibles cambios que se presenten durante el desarrollo del software.
  • FDD: Aunque también genera documentación es la mínima necesaria para comprender el código, si bien es cierto el quipo cuenta con cierta libertad también es cierto que estos dependen directamente del jefe de proyecto quien es el responsable directo de proyecto.

RELACION CON EL CLIENTE

  • RUP: Al final de cada fase, se les presenta al cliente los artefactos finales de dicha fase, para que sean evaluados por este y se puedan generar las iteraciones necesarias para la siguiente fase.
  • XP: La comunicación con el cliente es fluída (a través de su representante) después de cada iteración el cliente recibe un pedazo de programa funcional, así el cliente está informado permanentemente y puede intervenir rapidamente si el desarrollo se aleja de sus necesidades.
  • FDD: A diferecia del XP, aquí además de lo antes mencionado, existe el modelo general desarrollado en primera fase, la que provee un marco general dentro de cual evolucionará el proyecto (mientras no sea necesario cambiarlo claro)

DESARROLLO

Aquí los tres procesos están basados en iteraciones, lo que les permite acercarse poco a poco a la solución sin tener que entrar demasiado rápido a los detales, la diferencia está en que los programadores de XP y FDD tienen menor carga a parte del desarrollo del software entonces les permite hacer las iteraciones con una menor duración.

PUNTOS FLACOS
Es lógico pensar que si existen varios procesos de desarrollo de software es sencillamente que cada uno presenta deficiencias o carencias según el punto de vista del equipo de desarrollo o las necesidades que el cliente presente, es por ellos que vamos a reconocer algunas de cada uno de estos tres procesos aquí mencionados.

  • RUP: Dado que este es un proceso general y cubre todas las posibles espectativas tanto del cliente como del equipo de desarrollo, es precisamente esa característica su mayor punto flaco, pues es muy grande para proyectos y equipos pequeños ya que deben repartirse 32 roles y generar muchos artefactos finales, los cuales pueden ser aprovechados en una reutilización de productos, modelos o procesos pero también significa un incemento de tiempos y costos.
  • XP:Esteproceso está muy orientado a la implementación, esto lo hace bueno para el equipo de desarrollo ya q no debe preocuparse de la documentación y ya que los equipos rotan todos aprenden de todos, por otro lado el cliente también se siente satisfecho pues recibe un software que se adapta exactamente a sus deseas, pero esto implica que para esto debió designar a una persona totalmente involucrada en el negocio, lo que podría implicar que esta persona deje de hacer sus funciones para estar totalmente disponible al equipo de desarrollo, razón por la cual se considera mejor la utilización de este proceso para desarrollos internos, pues debe haber una gran confianza entre el cliente y el equipo de desarrollo, como mencionamos antes era poco probable que el cliente pueda prescindir de sus empleados esto incurriría en un coste adicional para el cliente. Por último como podríamos representar todo lo que se debe sin documentación alguna (dependencia entre componentes por ejemplo) si no se anota ni se archiva nada, como alguien más puede tomar el lugar de uno de los miembros del equipo, o hacer mejoras en el sistema, esto crearía una dependencia para con el equipo de desarrollo.
  • FDD: El principal problema de este proceso esta representado por la necesidad de contar con miembros experimentados en el equipo, miembros que puedan definir los roles y funciones de cada uno, que marquen el camino a seguir desde el principio con la elaboración del modelo global, el hecho de ser una combinación de XP y RUP es lo que lo hace más atractivo a la implementación, claro siempre y cuando la experiencia de esa gente de mayor jerarquía no cree dependencias .

Y bueno, con esto cualquier aclara las dudas que uno tiene cuando recien entra a este mundillo, por cierto este es un resumen de un documento que encontre por ahí, sumado a la experiencia y práctica que fui acumulando (que no es mucha por cierto), cualquier duda, comentario que nos pueda ayudar a todos a entender mejor esto seía muy bueno, hasta una nueva oportunidad.

Jack.

5 comentarios:

luismarcel dijo...

Pues, estoy proximo a iniciar un proyecto pequeño, pero quiero tener más documentacion que las historias de usuario y los diarios de los intervinientes ^^, así que creo que optaré por FDD... ouch!, se necesita alguien que guíe el proceso... mmm, pues aunque novato tratare de cumplir con ese papel, y veremos qué se aprende xD.

Saludos Jack

Jª¢K dijo...

si bueno pero estos conceptos se aplican a desarollos de soluciones integrales, ya sabes las que usan a menudo las fabricas de software (consultoras) por otro lado eso no significa que uno pueda empezar un proyecto de este tipo siendo solo uno, simplemente tendrías que considerar que por cumplir varios roles dentro del desarrollo mismo tendrías que repartir las tareas y tiempos, esto es más que beneficioso para los autodidactas pues cuando te toque desarrollar para un equipo ya habras tenido de alguna manera experiencia en los distitntos roles y nos sería mucho más fácil el iniciar un proyecto así.

Saludos.

Unknown dijo...

"...Este es uno de los procesos más generales que existe, esta enfocado a cualquier tipo de proyecto así no sea de software, se basa en la documentación generada en cada uno de sus cuatro fases: 1. Intercepción(puesta en marchar)..."

Esto es FALSO!!!!! RUP es una metodología para desarrollo de Software. No se puede hacer un carro con RUP, ni un edificio, ni una fábrica. Eso sólo para Software!!!. Por favor, cuando escriban algo públicamente documéntense primero. RUP tiene 9 disciplinas, si bien algunas son de apoyo hay otras que aplican sólo para la Ingeniería del Software como Implementación, Implantación, Pruebas, etc.

Respuestas como la anterior son las que hacen de Internet un lugar poco fiable. A todos los lectores, si quieren saber de RUP o de cualquier otra cosa, váyanse a las fuentes originales, no crean en todo lo que dicen los foros.

Además, es un error horroroso decir que la primera fase de RUP se llama INTERCEPCIÓN. Es una muy mala traducción de Inception, que literalmente es Incepción o coloquialmente INICIO!!!! además para terminar de rematar coloca entre paréntesis (Puesta en Marchar)... por favor.

Hermosa como la noche dijo...

Hola:
Me parece muy bueno tu aporte sobre estas metodologías, sobre todo por las personas novatas en el tema (como es mi caso).
Muy agradecida por tu gentiliza.

Saludos desde El Salvador

Gree_Dony dijo...

Enrique que man tan raboncito! Pero gracias, uno confia en lo primero y es bueno que nos haga abrir los ojos.