UNIVERSIDAD ESTATAL A DISTANCIA

VICERRECTORA ACADMICA
ESCUELA DE CIENCIAS EXACTAS Y NATURALES




Tarea Corta 1
RUP y Metodologas giles

3074 Herramientas de Produccin Avanzada II
Prof. Jorge Alvarado Zamora

Ricardo Brenes Serrano.
3-454-584

Centro Universitario Cartago
22 Junio 2014

II CUATRIMESTRE 2014


En la actualidad en el desarrollo de software y en muchas tareas cotidianas necesita que
se realicen con una rapidez y alta calidad. Es por esta razn que las metodologas giles
han tomado tanta importancia en este momento.

Parte fundamental de utilizar metodologas giles es porque el cliente y el equipo del
proyecto puede realizar cambios sobre la marcha del producto, beneficiando al cliente, ya
que, puede ser que en el momento de recoleccin de requisitos se le haya escapado algn
detalle, y por consecuencia es beneficio para el equipo debido a que la metodologa le
permite hacer dicho cambio. Esto es importante debido a que cliente puede terne una
mayor participacin y as el producto tome la forma que l desea, esto es importante
debido a que al concluir el sistema

A continuacin una breve explicacin sobre metodologas giles, programacin extrema y
SCRUM para poder abordar sobre esta base el tema de esta investigacin.

Las metodologas giles (como por ejemplo XP, SCRUM, DSDM, Crystal, entre otros.)
forman parte del movimiento de desarrollo gil de sotfware, que se basan en la
adaptabilidad de cualquier cambio como medio para aumentar las posibilidades de xito
de un proyecto.
De forma que una metodologa gil es la que tiene como principios que:
Los individuos y sus interacciones son ms importantes que los procesos y las
herramientas.
El software que funciona es ms importante que la documentacin exhaustiva.
La colaboracin con el cliente en lugar de la negociacin de contratos.
La respuesta delante del cambio en lugar de seguir un plan cerrado.
(Desconocido, s.f.)

Programacin extrema

La programacin extrema o Extreme Programming, es una disciplina de desarrollo de
software basada en los mtodos giles, que evidencia principios tales como el desarrollo
incremental, la participacin activa del cliente, el inters en las personas y no en los
procesos como elemento principal, y aceptar el cambio y la simplicidad (Beck et al., 2001).
El trabajo fundamental se public por Kent Beck en 1999, y tom el nombre de
Programacin Extrema por las prcticas reconocidas en el desarrollo de software y por la
participacin del cliente en niveles extremos (Wells, 2009). ste mtodo, al igual que RUP
y MSF, tambin tiene principios los cuales son buenas prcticas a tener presente en el
desarrollo del software.

Principios de programacin extrema:

Planificacin incremental: Se toman los requerimientos en Historias de Usuario, las
cuales son negociadas progresivamente con el cliente.
Entregas pequeas
Diseo sencillo
Desarrollo previamente aprobado
Limpieza del cdigo o refactorizacin
Programacin en parejas
Propiedad colectiva
Integracin continua: Al terminar una tarea, sta se integra al sistema entero y se
realizan pruebas de unidad a todo el sistema.
Cliente presente.
La semana de 40 horas.

Esta metodologa tiene como base la simplicidad y como objetivo principal la satisfaccin
del cliente; para lograrlo se deben tomar en cuenta cuatro valores fundamentales:

Comunicacin
Es muy importante que haya una comunicacin constante con el cliente y dentro de
todo el equipo de trabajo, de esto depender que el desarrollo se lleve a cabo de una
manera sencilla, entendible y que se entregue al cliente lo que necesita.

Simplicidad
En la XP se refiere que ante todo y sin importar qu funcionalidad requiera el usuario
en su sistema, ste debe ser fcil. El diseo debe ser sencillo y amigable al usuario, el
cdigo debe ser simple y entendible, programando slo lo necesario y lo que se
utilizar.

Retroalimentacin
Es la comunicacin constante entre el desarrollador y el usuario.

Valenta
Se refiere a la valenta que se debe tener al modificar o eliminar el cdigo que se
realiz con tanto esfuerzo; el desarrollador debe saber cundo el cdigo que
desarroll no es til en el sistema y, por lo mismo, debe ser eliminado.

SCRUM

SCRUM es un marco de trabajo basado en los mtodos giles, que tiene como objetivo el
control continuo sobre el estado actual del software, en el cual el cliente establece las
prioridades y el equipo SCRUM se auto-organiza para determinar la mejor forma de
entregar resultados (Abrahamsson, Salo, Ronkainen y Warsta, 2002).

En SCRUM se realizan entregas parciales y regulares del producto final (se muestra en la
figura 1 con las sincronizaciones diarias y con la iteracin completa), priorizadas por el
beneficio que aportan al receptor del proyecto. Por ello, SCRUM est especialmente
indicado para proyectos en entornos complejos, donde se necesita obtener resultados
pronto, donde los requisitos son cambiantes o poco definidos, donde la innovacin,
la competitividad, la flexibilidad y la productividad son fundamentales.

Proceso SCRUM

Pila del producto: Es el corazn de SCRUM, es la relacin de requisitos del
producto, en la cual no es necesario excesivo detalle pero s deben estar
priorizados. sta lista o pila del producto est en constante evolucin y abierta a
todos los roles, pero es el propietario del producto el responsable y quien decide
sobre esta.

Pila del SPRINT: Son los requisitos comprometidos por el equipo para el Sprint, se
construyen con el nivel de detalle suficiente para lograr su ejecucin por el equipo
de trabajo.

Incremento: Es una parte del producto desarrollado en un Sprint, y que es factible
de ser usado, contiene las pruebas, una codificacin limpia y documentada.



Figura 1. El proceso scrum. Fuente: http://www.proyectosgiles.org/sites/default/files/image/diagrama-proceso-
scrum.gif


Scrum es un mtodo iterativo e incremental que enfatiza prcticas y valores de Project
management por sobre las dems disciplinas del desarrollo. Al principio del proyecto se
define el Product Backlog, que contiene todos los requerimientos funcionales y no
funcionales que deber satisfacer el sistema a construir. Los mismos estarn especificados
de acuerdo a las convenciones de la organizacin ya sea mediante: features, casos de uso,
diagramas de flujo de datos, incidentes, tareas, etc. El Product Backlog ser definido
durante reuniones de planeamiento con los stakeholders. A partir de ah se definirn las
iteraciones, conocidas como Sprint en la juerga de SCRUM, en las que se ir
evolucionando la aplicacin evolutivamente. Cada Sprint tendr su propio Sprint Backlog
que ser un subconjunto del Product Backlog con los requerimientos a ser construidos en
el Sprint correspondiente. La duracin recomendada del Sprint es de 1 mes. (Hernn,
2004)
La programacin extrema o Extreme Programming, es una disciplina de desarrollo de
software basada en los mtodos giles, que evidencia principios tales como el desarrollo
incremental, la participacin activa del cliente, el inters en las personas y no en los
procesos como elemento principal, y aceptar el cambio y la simplicidad (Beck et al., 2001).

Es por esto, que existe ciertas similitudes y tambin diferencias con respecto a RUP;
puesto que RUP es una metodologa que tiene como objetivo ordenar y estructurar el
desarrollo de software, en la cual se tienen un conjunto de actividades necesarias para
transformar los requisitos del usuario en un sistema Software (Amo, Martnez y Segovia,
2005). Y estas metodologas comparten el concepto de desarrollo Iterativo e Incremental
lo cual significa que la aplicacin se divide en pequeos proyectos, los cuales incorporan
una parte de las especificaciones, y el desarrollo de la misma es una iteracin que va
incrementando la funcionalidad del sistema de manera progresiva (Silva, Barrera,
Arroyave y Pineda, 2007)

Es por esto que RUP y UML pueden utilizar dentro de esta metodologa gil, debido a que
como el desarrollo es incremental y tambin proporcionan una divisin del proyecto en
iteraciones, lo cual permite que el cliente o usuario tenga una participacin ms activa
sobre el ciclo de vida de cada iteracin. Tomando en cuenta la figura 1, la iteracin en RUP
consta de varias etapas, es aqu donde la combinacin de RUP y programacin extrema se
pueden acoplar, debido a que una iteracin de RUP se puede convertir en una actividad
de la programacin extrema, permitiendo que la actividad sea de una manera ms
eficiente y que tenga una base slida para esa entrega. Esto porque las fases del ciclo
que comprende la programacin extrema son las siguientes:

Fase de planeacin: sta fase inicia con las historias de usuario que describen las
caractersticas y funcionalidades del software. El cliente asigna un valor o prioridad
a la historia, los desarrolladores evalan cada historia y le asignan un costo el cual
se mide en semanas de desarrollo.

Fase de diseo: El proceso de diseo debe procurar diseos simples y sencillos
para facilitar el desarrollo. Se recomienda elaborar un glosario de trminos y la
correcta especificacin de mtodos y clases para facilitar posteriores
modificaciones, ampliaciones o reutilizacin del cdigo. Anteriormente este
proceso se apoyaba en el uso de tarjetas CRC (Colaborador-Responsabilidad-Clase)
la cual identifica las clases orientadas a objetos que son relevantes para el
incremento del software.

Fase de codificacin: En sta fase los desarrolladores deben disear las pruebas de
unidad que ejercitarn cada historia de usuario. Despus de tener las pruebas, los
desarrolladores trabajarn en parejas para concentrarse en lo que debe
implementarse para pasar la prueba de unidad.

Fase de pruebas: Las pruebas de unidad deben implementarse con un marco de
trabajo que permita automatizarlas, con la finalidad de realizar pruebas de
integracin y validacin diarias, esto proporcionar al equipo un indicador del
progreso y revelarn a tiempo si existe alguna falla en el sistema. (A., 2011)


Figura 2. Las Iteraciones en RUP. Fuente: Adaptado de RUP (Booch, Rumbaugh y Jacobson, 2000)



Cabe destacar que el tiempo utilizado en las metodologas puede variar, por ejemplo una
actividad de programacin extrema abarca de 2 semanas a 2 meses, mientras que en
SCRUM la actividad dura aproximadamente de una semana a un mes. Adems se puede
mencionar que la cantidad de personas que participan en cada metodologa vara con
respecto a la utilizada.


Entre la ventajas de usar RUP y UML en estas metodologas es que podemos recolectar
requerimientos de una manera adecuada y muy eficiente, pero a su vez se puede
convertir en desventaja debido a que en estas metodologas se busca rapidez y realizar las
tareas con la mayor fluidez, provocando que RUP en el sentido de la documentacin
pueda provocar ms bien un retraso en el desarrollo. Comparando RUP con programacin
extrema genera una desventaja debido a que en programacin extrema se puede
desechar una tarea y en el caso de RUP y todo su ciclo de vida en una iteracin, sera un
fuerte impacto en el desarrollo en perder esa iteracin, por la prdida de tiempo y
esfuerzo comparados a los utilizados en las metodologas giles. Y como la principal
ventaja de RUP en metodologas giles es que por medio de la recoleccin de requisitos ya
sea al inicio, en medio o al ir finalizando el proyecto, por medio de los casos de uso se
pueden asignar tareas al grupo de trabajo para que se puedan repartir las
responsabilidades y as se pueda desarrollar cada requerimiento de una manera ms
expedita.
Entre las consideraciones que debemos tomar en cuenta para usar RUP y UML dentro de
las metodologas giles son el tamao del proyecto que se va a desarrollar; debido a que
las metodologas giles son utilizadas mayoritariamente en productos medianos o
pequeos. Tambin hay que tomar en cuenta la cantidad de personas que componen el
proyecto, debido a que las metodologas giles se componen de equipos de trabajo de 2 o
ms trabajadores para desarrollar. Desde luego es muy importante el tiempo que se tiene
para la entrega del proyecto, debido a que en caso de que el proyecto se necesite en poco
tiempo, entonces es mejor utilizar metodologas giles debido a que hay aspectos sobre
las metodologas giles que hace que la programacin del producto sea una de las fases
ms intensas y por ende donde se centra el desarrollo del producto.
Aunque, se puede pensar que las metodologas giles tienen un gran porcentaje de
codificacin, y no toman tanto en cuenta la documentacin que se puede realizar en las
etapas antes de codificacin, es por medio de RUP que se puede realizar diagramas que
documenten los requerimientos del cliente y as se pueda generar valor agregado para
que ya cuando inicie el proceso de codificacin se tengan esos diagramas y se pueda
utilizar la metodologa gil que ms se adecue al equipo y al tipo de problemas que se
tenga en ese momento.

Como se ha mencionado en el documento RUP Y UML se pueden adaptar a las
metodologas giles, pero hay que tomar en cuenta las ventajas y desventajas que
conlleva utilizar RUP en las diferentes en estas. Es por esto permite que RUP se adapta
dependiendo del equipo de trabajo, del problema que se tenga, de la mejor solucin que
se pueda adaptar a ese problema, los riesgo que conlleva utilizar RUP en las metodologas
giles; en fin a muchas variables que se obtienen por esta combinacin.

Tambin a lo largo del documento se ha enfatizado la buena solucin de utilizar RUP en
las primeras etapas o iteraciones de la metodologa gil seleccionada (dicho sea de paso,
dependiendo de muchos factores se pueden combinar diferentes metodologas giles).
Entonces se puede decir que con la combinacin que se haya escogido se puede alcanzar
una solucin, pero eso no garantiza que esa solucin se la ptima para otros problemas a
futuro, pero s puede ayudar a tratar una posible solucin a problemas similares o quiz
de una magnitud mayor.




Bibliografa

Beck, K. et al. (2001), Manifesto for Agile Software Development, disponible en:
http://agilemanifesto.org/, recuperado: 18 de Junio de 2014.

Wells, D. (2009), Extreme Programming: A gentle introduction, disponible en:
http://www.extremeprogramming.org/, recuperado: 18 de Junio de 2014.

Booch, G.; Jacobson, I. & Rumbaugh, J.(2006), El lenguaje Unificado de Modelado 2.0. 2
Edicin. Addison Wesley Iberoamericana, Madrid.

A., O. A. (2011). Cuatro enfoque metodolgicos para el desarrollo de Software RUP MSF
XP - SCRUM.

Desc. (03 de Julio de 2011). Gestin de proyectos y desarrollo de software. Obtenido de
http://jummp.wordpress.com/2011/07/03/rup-rational-unified-process-vs-desarrollos-
%C3%A1giles/

Desconocido. (s.f.). eisc.univalle.edu.co. Obtenido de
http://eisc.univalle.edu.co/materias/WWW/material/lecturas/xp.pdf

Hernn, S. M. (2004). Diseo de una Metodologa gil de Desarrollo de Software. Buenos
Aires, Argentina. Obtenido de http://materias.fi.uba.ar/7500/schenone-
tesisdegradoingenieriainformatica.pdf

Universidad Veracruzana. (11 de Junio de 2012). Universo. Obtenido de El peridico de los
universitarios: http://www.uv.mx/universo/486/infgral/infgral_15.html