Procesos de Desarollo de Ingeniería de Software

En este post voy a hablar, continuando con lo anterior, sobre Ingeniería de Software y los modelos y metodologías de desarrollo. En este caso me basara y daré mi opinión sobre otro documento llamado "Procesos de desarrollo: RUP, XP y FDD", creado por Alberto Molpeceres.
________________________________________

La verdad es que cuando leí este paper no había oído hablar, ni siquiera mencionar el proceso de desarrollo FDD, pero ahora lo tengo mucho más claro.

En este paper se narra sobre las ventajas y dificultades que se tienen al momento de adoptar un 'Proceso de Desarrollo' o una 'Metodología de Programación', tanto del punto de vista de los programadores como de los Jefes de Desarrollo o Jefes de Proyecto. También se expone el motivo del cual hoy en día existen muchas mutaciones de estos procesos, y es más que nada a que ninguno es posible pasarlo directamente de la teoría a la práctica. Hay ciertos casos que se podría hacer, pero, como por arte de magia, presente en toda área del conocimiento, nunca no salen las cosas como debería, o como muestran los libros o manuales.

Este documento clasifica los procesos de desarrollo en:
  • Ligeros: Aquellos procesos que buscan la calidad del software por medio de la comunicación directa entre desarrolladores y entre el desarrollador o equipo con el cliente.
  • Pesados: A diferencia de los ligeros, estos buscan la calida del software asegurando una buena documentación y ordenando muy bien todo el desarrollo.

Se mencionan además otra clase, como una mezcla entre las dos, que, reflejado en un proceso, seria el FDD, mientras que el ligero y el pesado es XP y RUP respectivamente.

Veamos ahora en que consiste cada uno:

Proceso Unificado Rational o RUP

RUP no solo esta pensado para proyectos de Software, sino para cualquier proyecto, y se divide en las siguientes fases:

  1. Intercepción (Puesta en marcha)
  2. Elaboración (definición, análisis y diseño)
  3. Construcción (Implementación)
  4. Transición (Fin del proyecto y puesta en producción)

Cada fase es iterativa, siguiendo el modelo en cascada para cada etapa mencionada anteriormente.



RUP, además, define nueve actividades a realizar en cada fase del proyecto:

  1. Modelado del negocio
  2. Análisis de requisitos
  3. Análisis de diseño
  4. Implementación
  5. Prueba
  6. Distribución
  7. Gestión de configuración y cambios
  8. Gestión de proyecto
  9. Gestión de entorno

El flujo de trabajo entre las actividades mencionadas se ven en el diagrama de actividad. Este proceso define roles que se asignan entre los miembros del equipo del proyecto, asignando las tareas y el 'artefacto' (resultado) resultante de cada uno.



Para ver que se cumpla lo esperado, RUP ocupa los casos de uso, dejándonos claro de que esta muy enfocado a la estructura del sistema, documentándose lo que mas se pueda, y lógicamente usando UML y su infinidad de diagramas.

Existen versiones reducidas de RUP, ya que por lo descrito, se necesita un proyecto muy grande para poder aplicarlo como lo señala la teoría, y el la practica hay que repartir 31 roles y generar más de 100 artefactos.

Programación Extrema o XP

Completamente diferente al proceso anterior, XP es una metodología ágil, preocupándose principalmente del objetivo, mejorando las relaciones interpersonales y velocidad de reacción, cosa que RUP no hace.

Se intenta minimizar el riesgo de fallar en el proceso usando a un representante del cliente a tiempo completo para el equipo de desarrollo. La función de este es de contestar rápidamente a cualquier duda del equipo y corregir de la misma manera, sin tener que retrasarse en 'absurdas' reuniones de tomas de decisiones.



Algunos instrumentos que usa XP para el proceso, y casi igual que RUP, ocupa UserStories como base de desarrollo, similar a los casos de uso de RUP, las cuales son las historias del cliente frente a diferentes escenarios con el sistema a desarrollar. En base a esto, y a la arquitectura del sistema planteada para el desarrollo se crean planes de releases, que permiten ver el avance del software, y su evaluación por el cliente. En cada release se verán cuanto se han cumplido los objetivos y, junto con el representante del cliente, se definirán las iteraciones, de pocas semanas, necesarias para alcanzar los objetivos la siguiente release.

Tambien, y en base a las UserStories, se encuentras los escenarios de prueba, que permiten evaluar cada pieza de software y ver su trazabilidad.

Los casos de prueba son fundamentales para XP, ya que aseguran, de que si en algun momento se requiere escacalar el sisetma, se tendra que evaluar si la pieza de software sigue ogreciendo la misa funcionalidaad inicial. La idea tambien es que sean lo más automatizados posibles, permitiendo evaluar rápidamente si es que se ha perdido funcionalidad o si algo anda mal.

Vista general del XP

En la fase de codificación del sistema, concretando el software, siempre se trabaja en parejas y con un ordenador, permitiendo de que la calidad aumente en tiempo real, a medida de que cada programador crea mejores algoritmos o entrega más funcionalidad. También se insta a rotar las parejas, haciendo de que en un momento cada uno haya trabajado con todo el equipo y que haya pasado por todas las partes del software, entregándole una visión completa del sistema a todo el equipo. De esta forma se evita el problema de que solo algunos conocen todo el sistema y los con menos experiencia se benefician al trabajar con los con mas experiencia, mejorando su nivel y del equipo en general.

XP tiene como objetivo primario el funcionamiento del sistema, y cumplir los planes de releases, para luego trabajar en mejorar los algoritmos. Es decir se ocupa la filosofía KISS (Keep It Simple Stupid), un diseño evolutivo de "conseguir la funcionalidad de la manera más simple posible”. Esto permite ahorrar mucho tiempo en la fase de análisis, dándole menos importancia como fase individual, pero integrándola al final de obtener funcionalidad.

Desarrollo Guiado por la Funcionalidad o FDD

En el documento lo anuncian claramente como un proceso ligero, pero también como a medio camino entre RUP y XP.

Esta pensado para proyectos con tiempo de desarrollo cortos, es decir, menos de un año, e iteraciones cortas, aproximadamente 2 semanas, que a medida que itera va generando, al igual que XP, software funcional que el cliente y/o dirección de empresa pueden ver y monitorizar.

Cada iteración se basa en features o funcionalidades, que son partes del sistema que tiene significado para el cliente. Esto quiere decir de que evitamos explicarle al cliente lo que significa construir el sistema de persistencia, sino que preguntamos cosas más concretas, como 'enviar pedido por e-mail'.

Las fases de desarrollo de FDD son:

  1. Desarrollo de un modelo general
  2. Construcción de una lista de funcionalidades
  3. Plan de releases en base a las funcionalidades a implementar
  4. Diseñar en base a las funcionalidades
  5. Implementar en base a las funcionalidades
  6. En las primeras tres fases se ocupa gran parte del tiempo al inicio del proyecto, pero a medida que se avanza en las iteraciones las otras dos van ocupando más tiempo, y las primeras solo son para el refinamiento del release siguiente.
A diferencia de XP, siempre hay un responsable último con mayor experiencia, que tendrá la ultima palabra en el caso de problemas sin resolver o sin acuerdo, lo cual además permite asignar responsabilidades que todas las empresa exigen, respetando la jerarquía. Ahora, al igual que XP, en FDD se trabaja como grupo, por lo que los menos inexpertos se ven beneficiados de la experiencia de otros.



Los diferentes componentes que se implementaran en una release se dividen en los diferentes sub-grupos y cadaa clase que se escriba tiene un propietario, y es quien puede hacer cambios a su parte del programa. Pueden darse casos de que un programador sea dueño de diferentes funcionalidades.

A diferencia de los otros procesos, el implementar una funcionalidad implica también la preparación y ejecución de los test, revisión del código (distribuir el conocimiento del sistema como un todo y aumentar la calidad) y la integración de las partes, estando en fases diferentes en los otros procesos.

FDD establece algunas medidas útiles que son muy importantes para la dirección de la empresa y muestran el estado actual del desarrollo y realizar, en el futuro, mejores estimaciones.

Comparando procesos

En el documento se señala que es complicado establecer una comparación concreta, sino que se debe realizar según los medios que emplean y el resultado. Lógicamente todos buscan aumentar la calidad del software, pero cada uno ocupa métodos diferentes, todos quieren el mismo fin.

La mayoría de los procesos de desarrollo que nacen hoy en día son orientados a objetos, y RUP, XP y FDD no son la excepción.

El tamaño de los equipos es una variable muy importante, ya que, como se menciono en el método de RUP, repartir esa gran cantidad de roles en un equipo pequeño, resulta imposible. XP y FDD son ideales para equipos pequeños y proyectos cortos. Ahora, el que permite mas escalabilidad de estos dos, es FDD, ya que a mayor tamaño de código y/o equipo, mayor es la necesidad de cierta organización.

Obtención de requisitos

RUP y XP usan UseCases y UserStories, los cuales describen los requerimientos del sistema, sin ahondar en detalles de la implementación, a diferencia de FDD, que no los define explícitamente y solo se define el proceder al momento de que se recogen los requisitos, de la forma que se quiera, y dividiéndolos en las tres primeras fases del proyecto.

Carga de trabajo

XP trata de cierta manera alivianar las tareas de los desarrolladores, dejando de lado tareas como el modelado, generación de documentación externa, etc., cuyo efecto se contrarresta con la presencia de un representante del cliente. En el caso de que algo ande mal, o se desea cambiar una funcionalidad, se habla directamente con el representante del cliente y listo.

RUP, en cambio, como proceso pesado, tiene muchísima documentación, y por lo tanto, no es muy deseable hacer algún tipo de cambio, habiendo ya generado esta. RUP se apoya en sus diferentes planes(Plan de desarrollo, plan de iteración, plan de calidad, etc.), cosa de prever de manera anticipada cualquier problema con el desarrollo.

FDD, al ser un proceso intermedio, genera más documentación que en XP, pero menos que RUP. Igual determina que se debe documentar, existen márgenes, y responsabilidades.

Relación con el Cliente

RUP, en cada ciclo entrega diferentes documento al cliente que permiten evaluar los diferentes aspectos del proyecto, como los riesgos, los diferentes planes, prototipos, y calidad.

XP y FDD aseguran calidad y comunicación con el cliente en base a una interacción mas directa y sin formalismo de documentación.. En estos dos metodos, el cliente, después de cada iteración el cliente recibe un rerlease, pudiendo evaluar directamente el estado del proyecto. También, y con respecto a la calidad, se apoyan en test propios, permitiendo su objetivo primario: la funcionalidad.
Desarrollo

Estos tres procesos se basan en e modelo iterativo, orientando a la refinación y que permite llegar de manera progresiva al objetivo.

XP y FDD tienen iteraciones mas cortas que RUP, ya que los desarrolladores tienen una menor carga.

RUP resulta un poco mas completo a la hora de ingresar a empresas grandes y formalistas, ya que cada release que se entrega al cliente, a diferencia de FDD y XP, se apoya en toda su documentación, casi tan completa como el producto final, solo que con menos funcionalidades.

Código Fuente

XP presenta una gran libertad con respecto a esto, ya que es el único que lo comparte con el equipo entero, al ser equipos pequeños y una comunicación rápida y constante. Los otros dos, en cambio, optan por dar propiedad al código, y a pesar de hacer grupos y sesiones de trabajo conjuntos, en los que hay comunicación directa, resulta mucho más engorroso que en XP.

Conocimiento sobre la Arquitectura

Tanto XP y FDD, como los actuales procesos de desarrollo de software, tratan de incentivar las reuniones directas para mejorar la arquitectura, auque XP lo hace con la programación en pares, en donde se revisa el código en tiempo de programación y busca generar una discusión entre compañeros para mejorar los algoritmos, en FDD se hace con reuniones con el programador más experto y ver que se puede mejorar o si hay algo mal.

Evaluación del Estado del Proyecto

Con respecto a las métricas de evaluación y de proyección, FDD es el que tiene la mejor postura, ya que los reportes están distribuidos en la jerarquía con su propio sistema de métricas y en unidades pequeñas.

Debilidades

Ninguno de los procesos puede llevarse a la practica un 100% por lo cual existen varias metodologías alternativas, o bien uno puede crear su propio proceso adaptado a sus circunstancias.

Ejemplo de lo anterior, RUP, podría decirse que solo es aplicable a equipos grandes de trabajo, pero existen procesos derivados de RUP que ocupan los mismos pasos para llegar al producto final, pero con ciertas adaptaciones, dependiendo de las circunstancias,

Con respecto a XP, el contar con un representante competente del cliente, que conozca las reglas del negocio, un 100% para el equipo de desarrollo es casi imposible, puesto que el es parte importante de la empresa. Así mismo, el cliente en si, también dispone, en general, de poco tiempo y el es aun más indispensable en la empresa. Esto dificulta el trabajo en XP generalmente

Un punto a favor de XP es la programación en parejas, que debería implementarse en cualquier proceso de desarrollo de software, pero siempre se debe manejar hasta que punto esto puede ser un beneficio. El programar en parejas, para algunos es algo tonto, ya que uno esta en el PC mientras que el otro observa. Hay muchas dificultades sobre todo cuando hay roses personales entre desarrolladores.

En casos donde se requiera documentación externa, más allá del código fuente, XP no es deseado para un desarrollo y mucho menos cuando es documentación por formalismos para con el cliente o empresa. En estos casos RUP y FDD son mejores alternativas.

FDD, que parece no tener problemas, presenta dificultades al requerir de que cada grupo de trabajo sea guiado por un desarrollador mas experto, por lo que se complica aun más la cosa si son un equipo nuevo.


__________________________________

Bueno, ojala les gusten mis comentarios, ya que he dedicado tiempo y esfuerzo (mas tiempo que esfuerzo) en entregarles este documento, que resulta muy interesante, sobre todo para quienes nos gusta la informática y la estudiamos. Saludos.

7 comentarios:

Anónimo dijo...

hola Raul quisiera saber si existe una herramienta "libre" o pagada para documentar de forma fácil todos los artefactos de rup distintos a los de UML

Anónimo dijo...

a olvide enviarte mi mail: guidoe_mail@yahoo.com

Anónimo dijo...

Hola raul quisiera que me digas si existen herramientas para documentar rup diferentes para UML mejor si son libres pero otras tambien pueden ser utiles gracias de antemano y mi correo es guidoe_mail@yahoo.com

Darth Debian - VelociRaulEitor dijo...

Hola, que increíble que alguien lea mi blog :-P Que poco optimista. Bueno, te respondo aquí y te envío una copia a tu mail:

Si, existen herramientas y muy buenas, por cierto. Algunas, empezando por las mas simples a las mas complejas:

DIA: Bueno, es un simple editor de diagramas, pero permite hacer de todo tipo , desde casos de uso hasta de actividades. también tiene un complemento que se llama dia2code, que no es de lo mejor, pero genera código correcto si haces bien los diagramas.
http://es.wikipedia.org/wiki/Dia_(programa)
http://dia2code.sourceforge.net/


Umbrello: es un modelador UML de KDE, por lo que esta pensado mas para C++.
http://uml.sourceforge.net/index.php


NetBeans: Aunque no es 100% GNU, lo puedes ocupar en proyectos comerciales sin problemas. Con esta herramienta es posible hacer el ciclo completo de desarrollo de RUP, e inclusive, aparte de una generación de código y hacer todo tipo de diagramas, permite hacer ingeniería inversa a los proyectos. Hay muy buena documentación y ejemplos
www.netbeans.org

Eclipse: de los mismos desarrolladores de RUP, que ahora son parte de IBM, han puesto mucho empeño en esta IDE, por lo que ahora provee todo para el proceso RUP, así como muchas otras cosas mas. Yo diría que es mas poderosa que NetBeans. Inclusive, te muestra la ejecución de tus programas en un diagrama de actividades, así como verificación de tu modelo UML.
www.eclipse.org
http://www.ibm.com/developerworks/

Bueno, si te interesa lo de RUP, te comento que no es muy ocupado, a menos que trabajes en un proyecto grande o en IBM :-P La verdad es que cada uno adapta el modelo a su medida, o a la medida de tu equipo de trabajo. Saludos!!!

Anónimo dijo...

Antes que nada quiero agradecerte por haber puesto este blog de metodologias de desarrollo se me hiso muy interesante y ademas me permitio escojer la metodologia que creo yo me sera de mucha utilidad para llevar a cabo mi proyecto de un sistema administrativo. La metodologia que escigi fue la FDD no tenia ni idea que existiera y puesto que ya he utilizado XP creo que me resultara facil de usar y me brindara mejores resultados. Nuevamente Gracias!!!

Anónimo dijo...

Hola Raul muy interesante tu comentario me gustaria por favor que me aclararas lo que sepas sobre arquitectura del rup preferentemente lo que pongo a continuacion:
mi email es yezamora@estudiantes.uci.cu
o
yanara_07@yahoo.es

1-que significa que sea un proceso centrado en la arquitectura.

2-pq? es necesaria la arquitectura

3-cuales son los pasos para la arquitectura.

Blogg en Pañales dijo...

Hola Raul, quiero agradecerte el hecho de que hayas publicado el material referente a la comparacion de las metodologias creado por ti, ya que he pasado todo el dia intentando encontrar una metodologia que se adapte al desarrollo de mi sistema como requisito para obtener mi titulo de Ing. de Sistemas, y finalmente consegi algo valioso que va en concordancia con lo que ya habia pensado. De verdad mil gracias y felicitaciones porque este blogg sera parte de mi bibliografia consultada en la tesis.

Yusmary Chacón

Apoyando el Software Libre, a un mundo libre! - Designed by Posicionamiento Web