Está en la página 1de 33

REPBLICA BOLIVARIANA DE

VENEZUELA
INSTITUTO UNIVERSITARIO POLITCNICO
SANTIAGO MARIO
EXTENSIN MATURIN

RUP y Metodologas para el desarrollo de Sistemas,


Metodologas Agiles.

Maturn, Enero 2015

INTRODUCCIN
Se entiende como Desarrollo gil de Software a un paradigma
de Desarrollo de Software basado en procesos giles. Los procesos
giles de desarrollo

de

software,

conocidos

anteriormente

como metodologas livianas, intentan evitar los tortuosos y burocrticos


caminos de las metodologas tradicionales enfocndose en la gente y los
resultados.
Es un marco de trabajo conceptual de la ingeniera de software
que promueve iteraciones en el desarrollo a lo largo de todo el ciclo de
vida del proyecto. Existen muchos mtodos de desarrollo gil; la mayora
minimiza riesgos desarrollando software en cortos lapsos de tiempo. El
software desarrollado en una unidad de tiempo es llamado una iteracin,
la cual debe durar de una a cuatro semanas. Cada iteracin del ciclo
de

vida

incluye:

planificacin,

anlisis

de

requerimientos,

diseo, codificacin, revisin y documentacin. Una iteracin no


debe agregar demasiada funcionalidad para justificar el lanzamiento del
producto al mercado, pero la meta es tener un demo (sin errores) al final
de cada iteracin. Al final de cada iteracin el equipo vuelve a evaluar
las prioridades del proyecto.
Los mtodos Agiles enfatizan las comunicaciones cara a cara en
vez de la documentacin. La mayora de los equipos Agiles estn
localizados en una simple oficina abierta, a veces llamadas "plataformas
de lanzamiento" (bullpen en ingls). La oficina debe incluir revisores,
diseadores de iteracin, escritores de documentacin y ayuda y
directores de proyecto.
Los mtodos giles tambin enfatizan que el software funcional es
la primera medida del progreso. Combinado con la preferencia por las

comunicaciones cara a cara, generalmente los mtodos giles son


criticados

tratados

documentacin tcnica.

como

"indisciplinados"

por

la

falta

de

La definicin moderna de desarrollo gil de software evolucion a


mediados de los aos 1990 como parte de una reaccin contra los
mtodos de peso pesado, muy estructurado y estricto, extrados del
modelo de desarrollo en cascada. El proceso originado del uso del
modelo en cascada era visto como burocrtico, lento, degradante e
inconsistente con las formas de desarrollo de software que realmente
realizaban un trabajo eficiente. Los mtodos de desarrollos giles e
iterativos pueden ser vistos como un retroceso a las prcticas de
desarrollo observadas en los primeros aos del desarrollo de software
(aunque en ese tiempo no haba metodologas formales). Inicialmente,
los mtodos giles fueron llamados mtodos de "peso liviano". En el ao
2001, miembros prominentes de la comunidad se reunieron en
Sonwbird, Utah, y adoptaron el nombre de "Metodologas giles". Poco
despus, algunas de estas personas formaron la "alianza gil", una
organizacin sin fines de lucro que promueve el desarrollo gil de
aplicaciones. Muchos mtodos similares al gil fueron creados antes del
2000. Entre los ms notables se encuentran: Scrum(1986), Crystal Clear
(cristal transparente), programacin extrema o XP (1996), desarrollo de
software adaptativo, feature driven development, Mtodo de desarrollo
de

sistemas

dinmicos(1995).

Kent

Beck

cre

el

mtodo

de

Programacin Extrema (usualmente conocida como XP) en 1996 como


una

forma

de

rescatar

el

proyecto

del

Sistema

exhaustivo

de

compensaciones de Chrysler (C3). Mientras Chrysler cancelaba ese


proyecto, el mtodo fue refinado por Ron Jeffries.
METODOLOGIA RUP
Siempre que empezamos discutiendo mtodos en la arena OO,
inevitablemente salimos con el papel del Rational Unified Process. El
Proceso Unificado fue desarrollado por Philippe Kruchten, Ivar Jacobson y
otros de la Rational como el proceso complementario al UML. El RUP es
un armazn de proceso y como tal puede acomodar una gran variedad
de procesos. De hecho sta es mi crtica principal al RUP - como puede

ser cualquier cosa acaba siendo nada. Yo prefiero un proceso que dice
qu hacer en lugar de dar opciones infinitas.
Como resultado de esta mentalidad de armazn de procesos, el
RUP puede usarse en un estilo muy tradicional de cascada o de una
manera gil. Como resultado usted puede usar el RUP como un proceso
gil, o como un proceso pesado - todo depende de cmo lo adapte a su
ambiente.
Craig Larman es un fuerte defensor de usar el RUP de una manera
gil. Su excelente libro introductorio sobre desarrollo OO contiene un
proceso que est muy basado en su pensamiento ligero del RUP. Su
visin es que mucho del reciente empujn hacia los mtodos giles no
es nada ms que aceptar desarrollo OO de la corriente principal que ha
sido capturada como RUP. Una de las cosas que hace Craig es pasarse
los primeros dos o tres das de una iteracin mensual con todo el equipo
usando el UML para perfilar el diseo del trabajo a hacerse durante la
iteracin. Esto no es un cianotipo del que no se pueda desviarse, sino un
boceto que da una perspectiva sobre cmo pueden hacerse las cosas en
la iteracin.
Otra tachuela en el RUP gil es el proceso dX de Robert Martin. El
proceso dx es una versin totalmente dcil del RUP que simplemente es
idntico a la XP(voltear dX al revs para verlo). El dX est diseado para
gente que tiene que usar el RUP pero quiere usar XP. Como tal es a la
vez XP y RUP y por tanto un buen ejemplo del uso gil del RUP.
Para m, una de las cosas clave que necesita el RUP es que los
lderes del RUP en la industria enfaticen su acercamiento al desarrollo de
software. Ms de una vez he odo a la gente que usa el RUP que estn
usando un proceso de desarrollo estilo cascada. Gracias a mis contactos
en la industria, s que Philippe Kruchten y su equipo son firmes
creyentes en el desarrollo iterativo. Clarificando estos principios y

animando las versiones giles del RUP tales como los trabajos de Craig y
de Robert tendr un efecto importante.
El proceso de ciclo de vida de RUP se divide en cuatro fases bien
conocidas

llamadas Incepcin,

Elaboracin,

Construccin

Transicin. Esas fases se dividen en iteraciones, cada una de las cuales


produce una pieza de software demostrable. La duracin de cada
iteracin puede extenderse desde dos semanas hasta seis meses. Las
fases son:
Incepcin. Significa comienzo, pero la palabra original (de origen
latino y casi en desuso como sustantivo) es sugestiva y por ello la
traducimos as. Se especifican los objetivos del ciclo de vida del
proyecto y las necesidades de cada participante. Esto entraa
establecer el alcance y las condiciones de lmite y los criterios de
aceptabilidad. Se identifican los casos de uso que orientarn la
funcionalidad.
Se disean las arquitecturas candidatas y se estima la agenda y el
presupuesto de todo el proyecto, en particular para la siguiente
fase de elaboracin. Tpicamente es una fase breve que puede
durar unos pocos das o unas pocas semanas.
Elaboracin. Se analiza el dominio del problema y se define el plan
del proyecto. RUP presupone que la fase de elaboracin brinda una
arquitectura suficientemente slida junto con requerimientos y
planes

bastante

estables.

Se

describen

en

detalle

la

infraestructura y el ambiente de desarrollo, as como el soporte de


herramientas de automatizacin. Al cabo de esta fase, debe estar
identificada la mayora de los casos de uso y los actores, debe
quedar descripta la arquitectura de software y se debe crear un
prototipo de ella. Al final de la fase se realiza un anlisis para
determinar los riesgos y se evalan los gastos hechos contra los
originalmente planeados.

Construccin. Se

desarrollan,

integran

verifican

todos

los

componentes y rasgos de la aplicacin. RUP considera que esta


fase es un proceso de manufactura, en el que se debe poner
nfasis en la administracin de los recursos y el control de costos,
agenda y calidad. Los resultados de esta fase (las versiones alfa,
beta y otras versiones de prueba) se crean tan rpido como sea
posible. Se debe compilar tambin una versin de entrega. Es la
fase ms prolongada de todas.
Transicin. Comienza cuando el producto est suficientemente
maduro para ser entregado. Se corrigen los ltimos errores y se
agregan los rasgos pospuestos. La fase consiste en prueba beta,
piloto, entrenamiento a usuarios y despacho del producto a
mercadeo,

distribucin

ventas.

Se

produce

tambin

la

documentacin. Se llama transicin porque se transfiere a las


manos del usuario, pasando del entorno de desarrollo al de
produccin.
A travs de las fases se desarrollan en paralelo nueve workflows o
disciplinas: Modelado de Negocios, Requerimientos, Anlisis & Diseo,
Implementacin, Prueba, Gestin de Configuracin & Cambio, Gestin
del Proyecto y Entorno. Adems de estos workflows, RUP define algunas
prcticas comunes:
Desarrollo iterativo de software. Las iteraciones deben ser breves
y proceder por incrementos pequeos. Esto permite identificar
riesgos y problemas tempranamente y reaccionar frente a ellos en
consecuencia.
Administracin
cambiantes

de
y

administrarlos.

requerimientos.

postula

una

Identifica

estrategia

requerimientos

disciplinada

para

Uso de arquitecturas basadas en componentes. La reutilizacin


de componentes permite asimismo ahorros sustanciales en
tiempo, recursos y esfuerzo.
Modelado

visual

del

software. Se deben construir modelos

visuales, porque los sistemas complejos no podran comprenderse


de otra manera. Utilizando una herramienta como UML, la
arquitectura y el diseo se pueden especificar sin ambigedad y
comunicar a todas las partes involucradas.
Prueba de calidad del software. RUP pone bastante nfasis en la
calidad del producto entregado.
Control de cambios y trazabilidad. La madurez del software se
puede medir por la frecuencia y tipos de cambios realizados.
Aunque RUP es extremadamente locuaz en muchos respectos, no
proporciona

lineamientos

claros

de

implementacin

que

puedan

compararse, por ejemplo, a los mtodos Crystal, en los que se detalla la


documentacin requerida y los roles segn diversas escalas de proyecto.
En RUP esas importantes decisiones de dejan a criterio del usuario. Se
asegura que RUP puede implementarse sacndolo de la caja, pero
dado que el nmero de sus artefactos y herramientas es inmenso,
siempre se dice que hay que recortarlo y adaptarlo a cada caso. El
proceso de implementacin mismo es complejo, dividindose en seis
fases cclicas.
Existe una versin recortada de RUP, dX de Robert Martin, en la cual
se han tomado en consideracin experiencias de diversos MAs,
reduciendo los artefactos de RUP a sus mnimos esenciales y (en un
gesto heroico) usando tarjetas de fichado en lugar de UML. Es como si
fuera RUP imitando los principios de XP; algunos piensan que dX es XP
de cabo a rabo, slo que con algunos nombres cambiados [ASR+02].
RUP se ha combinado con Evo, Scrum, MSF y cualquier metodologa
imaginable. Dado que RUP es suficientemente conocido y su estructura

es ms amplia y compleja que el de cualquier otro mtodo gil, su


tratamiento en este texto concluye en este punto.
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). Inicialmente fue
llamada UP (Unified Process) y luego cambi su nombre a RUP por el
respaldo de Rational Software de IBM. sta metodologa fue lanzada en
1998 teniendo como sus creadores a Ivar Jacobson, Grady Booch y
James Rumbaugh. El RUP naci del UML (Unified Modeling Language) y
del UP (Sommerville, 2005).
Caractersticas del RUP
El RUP es un proceso basado en los modelos en Cascada y por
Componentes, el cual presenta las siguientes caractersticas: Es dirigido
por los casos de uso, es centrado en la arquitectura, iterativo e
incremental

(Booch,

Rumbaugh

Jacobson,

2000),

lo

cual

es

fundamental para el proceso de desarrollo de software. A continuacin


se explican las tres caractersticas de RUP:
a) Casos de Uso: Describe un servicio que el usuario requiere del
sistema, incluye la secuencia completa de interacciones entre el
usuario y el sistema.
b) Centrado en la arquitectura: Comprende las diferentes vistas del
sistema e desarrollo, que corresponden a los modelos del sistema:
Modelos de casos de uso, de anlisis, de diseo, de despliegue e
implementacin. La arquitectura de software es importante para
comprender el sistema como un todo y a la vez en sus distintas
partes (Abrahamsson, Salo, Ronkainen y Warsta, 2002), sirve para
organizar el desarrollo, fomentar la reutilizacin de componentes y
hacer

evolucionar

el

sistema,

es

decir,

funcionalidad (Pressman y Murrieta, 2006).

agregarle

ms

c) Iterativo e Incremental: 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).
Estructura del RUP
El proceso del RUP se ejecuta en tres perspectivas: La perspectiva
dinmica, la cual contiene las fases del modelo sobre el tiempo; la
esttica que muestra las actividades del proceso y la prctica, que
muestra las buenas prcticas durante el proceso del RUP (IBM, s. f.).
Para aclarar esta relacin, a continuacin se presenta una
descripcin de las tres perspectivas:
a) La perspectiva dinmica se compone por las fases de Inicio,
Elaboracin, Construccin y Transicin, Inventum No. 10 Facultad de
Ingeniera UNIMINUTO - Junio de 2011 - ISSN 1909 - 2520 67 cada
fase se subdivide en iteraciones (Rational Software Corporation,
1998) y comprenden los siguientes objetivos:
Fase de inicio: Su objetivo es la comunicacin con el cliente y las
actividades de planeacin. Se establece el caso del negocio para el
sistema, as como la identificacin de todas las entidades externas
que interactan con el sistema y sus respectivas iteraciones.
Fase de elaboracin: Tiene como fin desarrollar un entendimiento
del dominio del problema, crear un marco de trabajo arquitectnico
para el sistema, desarrollar el plan del proyecto e identificar los
riesgos claves. Al finalizar esta fase se debe tener el modelo de
requerimientos del sistema (UML), una arquitectura y un plan de
desarrollo.

. Fase de construccin: Su objetivo es el diseo del sistema, la


programacin, las pruebas y la integracin de todas las partes del
sistema software. Al final de esta fase se debe tener un software
operativo con su respectiva documentacin.
Fase de transicin: En esta fase el sistema software se entrega a los
usuarios finales para sus respectivas pruebas en un entorno real. Al
terminar esta fase se debe tener un software documentado y
funcionando correctamente.
b) La perspectiva esttica define dentro del proceso de desarrollo de
software el quin hace qu, cmo y cundo (Booch, Jacobsony
Rumbaugh, 2006). El quin corresponden a los roles, el qu y el
cmo corresponde a las actividades y artefactos, y el cundo
corresponde al flujo de trabajo.
Para ello es necesario tener claro los siguientes elementos:
Roles: Definen el comportamiento y las responsabilidades de cada
individuo o de un grupo. Una persona puede desempear varios roles
y un rol puede ser desempeado por varias personas. Los roles
definidos en RUP son: Analistas, desarrolladores, gestores, apoyo,
especialista en pruebas y cualquier otro rol del cual se tuviera
necesidad.
Actividades: Es una unidad de trabajo que una persona que
desempea un rol puede realizar. Las actividades tienen objetivos
concretos tales como: Planear una iteracin, revisar el diseo,
ejecutar pruebas de rendimiento, entre otras.
Artefactos: Tambin denominado producto, es un modelo de
informacin que es producido o modificado durante el proceso de
desarrollo de software.

Los artefactos son los resultados tangibles del proyecto, las cosas
que se van creando y usando hasta tener el producto software
terminado. Algunos artefactos pueden ser: un modelo de casos de
uso, el documento de la arquitectura, etc.
Flujo de trabajo: Es la relacin entre los roles y los artefactos o
productos que producen resultados observable en el desarrollo del
sistema software. Estos se dividen en flujos de trabajo de proceso y
flujos de trabajo de soporte, los primeros reflejan actividades propias
del modelo en cascada y contiene el modelado de negocios,
requerimientos,

anlisis

diseo,

implementacin,

pruebas

despliegue; y los segundos contienen la configuracin y gestin de


cambios, la gestin del proyecto y el entorno.
d) La

perspectiva

prctica

describe

seis

buenas

prcticas

en

Ingeniera de Software que son recomendables en el desarrollo de


sistemas software, las cuales son: Desarrollo iterativo, gestin de
requisitos, desarrollo basado en componentes, modelado visual
UML, verificacin continua de la calidad y control de cambios de
software (Leterlier, s. f.) Estas prcticas se ejecutan durante todo
el proyecto y de manera transversal a las perspectivas dinmica y
esttica.
e) El ciclo de vida del RUP
La metodologa RUP se repite a lo largo de una serie de ciclos que
constituyen la vida de un sistema desde su nacimiento hasta su
muerte. Cada ciclo concluye con una versin del producto para los
clientes (Traa, 2006).
MICROSOFT SOLUTIONS FRAMEWORK (MSF)
MSF es una gua de desarrollo de software flexible que permite
aplicar de manera individual e independiente cada uno de sus
componentes, es escalable pues est diseada para poder expandirse

segn la magnitud del proyecto. La metodologa MSF est basada en


un conjunto de principios, modelos, disciplinas, conceptos, directrices
y practicas aprobadas por Microsoft, que asegura resultados con
menor riesgo y de mayor calidad, centrndose en el proceso y las
personas (Gattaca S. A.)
Microsoft Solutions Framework se introdujo por primera vez en 1994
como un conjunto de las mejores prcticas en los desarrollo de
Software

de

Microsoft

Microsoft

Consulting

Service.

Esta

metodologa ha estado evolucionando y mejorando con la experiencia


de grupos de trabajo reales los cuales contribuyeron a perfeccionar
este Framework (Wilmot et al., 2004). De igual manera, MSF tambin
retoma algunas de las caractersticas propias de metodologas
tradicionales.

Caractersticas de MSF
ste Framework est basado en los modelos espiral y cascada, lo cual
indica que toma elementos de los mtodos tradicionales que an son
referentes importantes para procesos de software. Es adaptable,
flexible y escalable, e independiente de tecnologas, lo cual significa
que no se cierra a un slo modelo de programacin sino ms bien
queda abierto segn la naturaleza del proyecto. Usa como referente
el DSL (Domain-Specific Language) para realizar el modelado, as
como RUP se apoya en UML para hacer el modelado (Microsoft).
Componentes
MSF es un FrameWork que contiene tres componentes:
Los principios fundamentales, los modelos y las disciplinas. Estos
componentes pueden ser utilizados individuamente o adoptados

como un todo integrado segn la naturaleza del proyecto (Microsoft,


2003), a continuacin se explican los tres componentes:
Principios fundamentales
Los principios de MSF son 8 valores y normas que son comunes en
todo el FrameWork, los cuales contribuyen a mejorar el trabajo en
equipo y a centrarse en mantener el objetivo del proyecto siempre en
marcha (Abrahamsson, Salo, Ronkainen y Warsta, 2002), estos
principios son:
Fomentar la comunicacin abierta: El mantener un buen flujo de
informacin entre los integrantes del equipo, pueden reducir las
posibilidades de malentendidos y contribuir a la solucin colectiva de
problemas.
Trabajar hacia una visin compartida: El equipo de trabajo debe
comprender y trabajar hacia las metas y objetivos del proyecto.
Empoderar a los miembros del equipo: Los miembros del equipo
SCRUM deben tener funciones claras, de tal manera que puedan
desenvolverse como un grupo creativo, eficaz y capaz de cumplir sus
propios objetivos, al igual que resolver sus dificultades.
Establecer la rendicin de cuentas claras y la responsabilidad
compartida: Cada equipo tiene funciones claras y son responsables
de una parte de la solucin, as como del xito global del proyecto,
trabajando desde la individualidad en procura de objetivos colectivos.
Centrarse en ofrecer valor empresarial: El equipo de trabajo debe
procurar ofrecer soluciones reales que satisfagan necesidades y
beneficien al comprador del producto, pues entregar un producto bien
elaborado y que cumpla los requerimientos para el cual fue diseado
es el objetivo a alcanzar.

Mantenerse gil, en espera de un cambio: El cambio constante debe


ser aceptado, es decir, el quipo debe estar preparado para afrontar
estas situaciones y ofrecer soluciones eficaces. MSF acepta la
combinacin de caos y orden lo cual deja entrever las altas
posibilidades de que los proyectos software se salgan de control.
Invertir en la calidad: El equipo debe mantener la mentalidad
centrada en la calidad, se debe invertir en las personas, en los
procesos y las herramientas, pues sta inversin puede retribuir en
resultados de mayor calidad.
Aprender de todas las experiencias: Tener una mentalidad abierta
para aprender del xito o fracaso de proyectos propios y ajenos.
Modelos
Los modelos describen esquemas a seguir para la organizacin de los
equipos y los procesos del proyecto (Microsoft, 2003), lo cual
especifica un modelo para el equipo de trabajo y uno para los
procesos:
a) Equipo de trabajo: Este modelo se encarga de organizar las
personas para que realicen el trabajo y se asegura que todas las
metas del proyecto se cumplan. Define los principios, los roles y las
actividades

involucrando

al

equipo

en

todas

las

decisiones

fundamentales que rodean el proyecto.


Principios: Todos los miembros del equipo son compaeros por lo
tanto

no

hay

jefes,

se

deben

tener

las

funciones

las

responsabilidades claras. Procurar evitar los defectos en los procesos


relacionados con a la satisfaccin del cliente, as como tener voluntad
y capacidad de aprender.
Roles y actividades: Un rol define comportamientos y actividades de
cada individuo o grupo, cada persona puede tomar ms de un rol y

mltiples personas pueden tomar un rol, en este modelo se describen


seis roles con sus respectivas actividades.
b) Proceso:
ste modelo se encarga de organizar los procesos necesarios para
lograr llevar a trmino una solucin.
Esto se logra dividiendo las tareas del proyecto en cinco fases, las
cuales proporcionan herramientas para mejorar el control sobre el
proyecto, minimizar el riesgo y aumentar la calidad del producto. Al
igual que el proceso RUP, MSF tambin tiene sus prcticas inherentes
al desarrollo de software, tales como la especificacin, el desarrollo,
la validacin y la evolucin del software.
De lo anterior se desprenden unos principios relacionados con el
proceso MSF, los cuales son: el manejo de versiones, la gestin del
riesgo, dividir el proyecto en partes y realizar construcciones diarias.
Por otra parte, la metodologa MSF establece 5 fases con sus
respectivas tareas. En las caractersticas de MSF se mencion que la
metodologa se poda aplicar de manera flexible, es decir, que los
componentes no eran dependientes unas de otras.
Fase visin: Se debe tener el objetivo y limitaciones del proyecto, el
anlisis de los problemas de negocios, el mbito de la aplicacin, la
evaluacin del riesgo y panificacin del producto.
Fase planificacin: Se debe tener la ingeniera de requerimientos,
planificacin y gestin de riesgos.
Fase desarrollo: En esta fase se codifica y se realizan las respectivas
pruebas, tambin se identifican y mitigan los riesgos existentes.

Fase estabilizacin: Se realizan pruebas beta, se crea un plan de


gestin de incidencias, se revisa la documentacin final de la
arquitectura y se elabora un plan de despliegue.
Fase implantacin: Se libera la solucin software, se crea un registro
de mejoras y sugerencias, se revisan las guas y manuales de usuario
y se entrega el proyecto final.
Gestin de requerimientos
En todo proceso de desarrollo de software es fundamental el proceso
de gestin de requerimientos. MSF incluye dentro del modelo de
proceso un documento de visin, y documentos de especificacin
funcional.
De igual forma se incluye tambin un acuerdo inicial sobre la
funcionalidad con el cliente, se toman los resultados para verificar
que se cumplen los requisitos y se hace seguimiento a cada elemento
al final de la ejecucin.
El ciclo de vida de MSF
El proceso del MSF se puede llevar a cabo de forma iterativa, tal
como se aprecia en la figura 8, de tal forma que al liberar una
solucin, se puede iniciar nuevamente la metodologa para darle ms
funcionalidad al producto (Llorens, 2005).
Disciplinas
MSF presenta un conjunto de mtodos para la gestin del proyecto, la
gestin del riesgo y la gestin de preparacin para el cambio (Del
Maschi et al., 2008). Dentro de las cuales comprende:
Gestin

de

proyecto:

Tiene

como

objetivo

permitir

mayor

escalabilidad en proyectos pequeos, grandes y complejos, basado


en la planificacin sobre las entregas cortas, la incorporacin de

nuevas

caractersticas

sucesivamente,

identificar

cambios

ajustando el cronograma.
Gestin del riesgo: la disciplina se encarga de ayudar al equipo a
tomar las decisiones correctas y controlar las emergencias que
puedan presentarse, por medio de un entorno estructurado para la
toma de decisiones y acciones, valorando los riesgos que puedan
provocar.
Gestin de cambios: Esta disciplina tiene como objetivo lograr que el
equipo sea proactivo en lugar de reactivo (Microsoft, 2003), teniendo
en cuenta que los cambios deben considerase riesgos y por lo tanto
se deben registrar y hacer evidentes.
En conclusin, la metodologa propuesta por MSF tiene como
propsito lograr entregas con un margen amplio de xito, basados en
la calidad del producto software, teniendo presente las necesidades
del cliente y el principio de flexibilidad, as como el cumplimiento con
los

compromisos

adquiridos,

la

gestin

de

los

costos

la

minimizacin de los riesgos inherentes en todo proyecto de desarrollo


de software.
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.
Los principios XP comprenden diez buenas prcticas que involucran al
equipo de trabajo, los procesos y el cliente; los cuales son:
Planificacin incremental: Se toman los requerimientos en Historias
de Usuario, las cuales son negociadas progresivamente con el cliente.
Entregas pequeas: Se desarrolla primero la ms mnima parte til
que le proporcione funcionalidad al sistema, y poco a poco se
efectan incrementos que aaden funcionalidad a la primera entrega,
cada ciclo termina con una entrega del sistema.
Al igual que en el ciclo de vida de RUP y MSF, en XP el ciclo de vida
termina cuando ya no hay ms ciclos de entrega y el sistema ha
cumplido con el objetivo para el cual fue diseado, de no ser as, se
deber continuar con el ciclo especificado hasta que la funcionalidad
del sistema sea la deseada.
Diseo sencillo: Solo se efecta el diseo necesario para cumplir con
los requerimientos actuales, es decir no se abordan requerimientos
futuros.
Desarrollo previamente aprobado: Una de las caractersticas
relevantes y propias de XP es que primero se escriben las pruebas y
luego se da la codificacin, esto con la finalidad de asegurar la
satisfaccin del requerimiento.
Limpieza del cdigo o refactorizacin: Consiste en simplificar y
optimizar el programa sin perder funcionalidad, es decir, alterar su
estructura

interna

sin

afectar

su

comportamiento

extern

(Abrahamsson, Salo, Ronkainen y Warsta, 2002).


Programacin en parejas: Es otra de las caractersticas de sta
metodologa, que propone que los desarrolladores trabajen en parejas

en una terminal, verificando cada uno el trabajo del otro y


ayudndose para buscar las mejores soluciones. Se entiende que de
esta forma el trabajo ser ms eficiente y de mayor calidad.
Propiedad colectiva: El conocimiento y la informacin deben ser de
todos, por lo tanto no se desarrollan islas de conocimiento, todos los
programadores poseen todo el cdigo y cualquiera puede sugerir y
realizar mejoras.
Integracin continua: Al terminar una tarea, sta se integra al
sistema entero y se realizan pruebas de unidad a todo el sistema,
sta prctica permite que la aplicacin sea ms funcional en cada
iteracin y garantiza su funcionamiento con los dems mdulos del
sistema.
Ritmo sostenible: No es aceptable trabajar durante grandes
cantidades de horas ya que se considera que puede reducir la calidad
del cdigo y la productividad del equipo a mediano plazo, se sugieren
40 horas semanales.
Cliente presente: Se debe tener un representante (Cliente o usuario
final) tiempo completo, ya que en XP ste hace parte del equipo de
desarrollo y es responsable de formular los requerimientos para el
desarrollo del sistema.
Valores en XP
En todo desarrollo de un proyecto de software, los cambios sern algo
inevitable, los requerimientos cambiarn, las reglas del negocio, el
equipo de trabajo y la tecnologa, entre otros elementos involucrados
en el proyecto. Por esta razn XP propone valores, que permitirn
afrontar y sortear de una manera ms efectiva los cambios en el
proyecto (Wellington, 2005) los cuales se enfocan al equipo de
trabajo de la siguiente manera:

Comunicacin: Aunque hay circunstancias que conducen a la


ruptura de la comunicacin, se debe procurar por comunicar
cualquier cambio con el resto del equipo ya sean desarrolladores,
cliente o jefe.
Sencillez: Iniciar desde lo parte ms simple que pueda darle
funcionalidad al sistema, es decir abordar el problema con el mayor
nivel de granularidad.
Retroalimentacin: La mejor manera de conocer el estado actual del
sistema

es

hacindole

pruebas

funcionales

al

software,

esto

proporcionar informacin real y confiable sobre el grado de fiabilidad


del sistema.
Valenta: El equipo de trabajo debe estar presto para asumir retos,
ser valiente ante los problemas y afrontarlos, no tapar los errores, ya
que tarde o temprano saldrn a flote y todo el sistema colapsar no
se puede avanzar sobre los errores. Se recomienda tomar acciones
correctivas a tiempo a fin de lograr el objetivo del proyecto.
Objetivos de XP
Aunque las metodologas RUP y MSF no lo muestran de una manera
explcita, tambin para ellas la satisfaccin del cliente y el trabajo en
equipo es un objetivo.
La metodologa XP tiene dos objetivos primordiales para el correcto
desarrollo del proyecto (Jeffries, s. f.):
La satisfaccin de cliente: Entendida como dar al cliente lo que
necesita y cuando lo necesita, respondiendo rpidamente a las
necesidades de este. Uno de los factores importantes en todo
proyecto de software es que el sistema software logre el objetivo para
el cual fue diseado y que el equipo de trabajo logre el objetivo para

el cual fue contratado, de ah que el incumplimiento de esto termine


con un producto incompleto y un cliente insatisfecho.
Potenciar al mximo el trabajo en grupo: Todos estn involucrados y
comprometidos con el desarrollo del software tanto los jefes como los
desarrolladores y los clientes, no hay agentes individuales o aislados
al proyecto.
El proceso de XP
El proceso de XP al igual que RUP y MSF se presenta en fases, en XP
se ejecuta en cuatro fases teniendo presente los principios y valores
antes mencionados, los cuales son un eje fundamental para el
correcto desarrollo de cada fase durante el ciclo.

Al igual que en las metodologas antes mencionadas, en el proceso


XP, se observan una serie de fases que al ser concluidas dan origen a
una versin del producto software, y cada versin es un ciclo, el cual
hace parte del ciclo de vida del software.
Al no tener ms ciclos a ejecutar se entiende que los sistemas han
cumplido con su objetivo, en caso contrario se deben seguir
desarrollando ciclos para agregar la funcionalidad deseada. Cada fase
del ciclo comprende lo siguiente:
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 (ColaboradorResponsabilidad-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

validacin

diarias,

esto

proporcionar al equipo un indicador del progreso y revelarn a


tiempo si existe alguna falla en el sistema. Las pruebas (Sommerville,
2005) tienen las siguientes caractersticas:
- Desarrollo previamente aprobado: Significa que primero se escriben
las pruebas y luego el cdigo. Las pruebas deben simular el envo de
la entrada a probar y deben verificar que el resultado cumpla con las
especificaciones de salida.
- Desarrollo de pruebas incremental: Los requerimientos del usuario
se expresan como historias, el equipo de desarrollo evala cada
historia y la divide en tareas. Cada una representa una caracterstica
distinta del sistema y se pueden disear pruebas de unidad para esa
tarea.
- Participacin del usuario en el desarrollo de las pruebas: El usuario
ayuda a desarrollar las pruebas de aceptacin, las cuales son pruebas
que se implementan con los datos reales del cliente para verificar el
cumplimiento real de sus necesidades.

- Uso de bancos de pruebas automatizados: Sedebe usar un sistema


que enve a ejecucin las pruebas automatizadas y de esta forma
probar constantemente el sistema software.
Artefactos
En todo proceso de desarrollo de software se generan modelos de
informacin. En XP se generan varios artefactos como las tarjetas de
historias de usuario (Story Card), las tarjetas de tareas para la
descarga de documentos, el cdigo, las pruebas unitarias y de
integracin

y las

pruebas

de aceptacin.

Los

artefactos

son

importantes para conocer cul fue el proceso de desarrollo del


software y lograr entender cmo est construido el sistema, as como
la ruta a seguir para agregar funcionalidad al sistema.
Roles
Los miembros de un equipo trabajan mejor cuando hay roles
establecidos, cada rol tiene consigo responsabilidades que tienen
como finalidad cumplir con los objetivos del proyecto. Algunos
proyecto necesitan de mltiples roles como tsteres o probadores,
ingenieros de calidad, analista de requerimientos, administrador del
proyecto, administrador del producto, profesionales de marketing. El
nmero de roles vara de acuerdo con el proyecto. A continuacin se
explican algunos de los ms relevantes:
Programador: Es el corazn de XP, el programador con base en su
experiencia puede tomar decisiones que afecten el desarrollo del
proyecto. Su tarea es lograr que la computadora comprenda y haga
todo segn los requerimientos del usuario, el programador debe
conocer cmo hacer el programa y trabajar de la mano con el cliente.
Clientes: El cliente dirige y conoce las metas a alcanzar en el
proyecto. Debe conocer qu debe hacer el programa, para que de
sta forma gue y trabaje de la mano con los programadores, por lo

tanto debe aprender a escribir las historias de usuario. El cliente y los


desarrolladores tienen gran responsabilidad en el proyecto.
Tester (probadores): Su responsabilidad es correr las pruebas
funcionales con regularidad y dar a conocer los resultados de esta,
as como elaborar las pruebas junto con el cliente.
Tracker (responsable del seguimiento): Debe conocer el alcance
funcional del equipo, controla los tiempos de desarrollo, controlar los
hitos y entregas, puede tomar decisiones estratgicas para el equipo
y debe asegurar el alcance y despliegue de la aplicacin.
En sntesis, actualmente XP es una de las metodologas de mayor
aceptacin en la industria del software, su enfoque basado en los
mtodos giles, su nfasis en la gestin del recurso humano el cul
es uno de los puntos ms crticos en todo proyecto, y sus principios
de previsibilidad y adaptabilidad hacen de esta metodologa una
buena opcin a seguir.
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).
SCRUM fue desarrollado en 1986 por Hirotaka Takeuchi e Ikujiro
Nonaka quienes describieron una nueva aproximacin metodolgica
que incrementa la rapidez y la flexibilidad en el desarrollo de nuevos
productos comerciales. El enfoque de sta metodologa es como en el
rugby, donde el proceso es similar a un equipo entero que acta
como un slo hombre para intentar llegar al otro lado del campo,
pasando el baln de uno a otro. sta metodologa se inici en el
campo de las industrias automovilsticas y de tecnologa, pero a

principios de los aos 1990 Ken Schwaber la llev a la prctica en su


compaa Advanced Development Methods (Mountain Goat Software,
s.f.) al 74 Inventum No. 10 Facultad de Ingeniera UNIMINUTO - Junio
de 2011 - ISSN 1909 2520 igual que XP, en SCRUM se hace bastante
nfasis en la gestin del recurso humano, esto se puede apreciar
mejor en las caractersticas del mtodo SCRUM, que se explican a
continuacin.
Caractersticas
SCRUM da prioridad a los individuos y las interacciones sobre los
procesos y las tareas, lo cual significa que gran parte del xito del
proyecto radica en la forma cmo el equipo se organice para trabajar.
Se debe tener una cohesin fuerte de equipo ya que el triunfo de un
hito no es de un slo miembro sino de todo el equipo SCRUM, todos
se colaboran entre s, y empujan a los integrantes que no estn a la
par con el equipo (Beck, K. et al., 2001).

CONCLUSIONES
1. No existe una metodologa universal para hacer frente con xito a
cualquier proyecto de desarrollo de software. Las metodologas
tradicionales histricamente han intentado abordar la mayor
cantidad de situaciones del contexto del proyecto, exigiendo un
esfuerzo considerable para ser adaptadas, sobre todo en proyectos
pequeos y de requisitos cambiantes.
2. Las metodologas giles ofrecen una solucin casi a medida para
una gran cantidad de proyectos. Las metodologas giles se
caracterizan por su sencillez, tanto en su aprendizaje como en su
aplicacin; sin embargo, gozan tanto de ventajas como de
inconvenientes. Las metodologas giles permiten a los pequeos
grupos de desarrollo concentrarse en la tarea de construir software
fomentando prcticas de fcil adopcin y en un entorno ordenado
que permiten que los proyectos finalicen exitosamente.
3. Se pueden distinguir dos rangos distintos de conjuntos de
metodologas giles. Por un lado estn las metodologas ms
declarativas y programticas como XP, Scrum, LD, entre otras; y
por

otro

lado

se

encuentran

las

metodologas

finamente

elaboradas como DSDM, Cristal, etc.


4. XP es una de las metodologas giles ms extendidas y populares,
adems es considerada como una metodologa posmoderna cuyas
grandes

capacidades

se

generan

travs

de

procesos

emergentes. Scrum implementa en sus prcticas de desarrollo una


estrategia

de

caos

controlado,

permitiendo

maximizar

la

realimentacin sobre el desarrollo pudiendo corregir problemas y


mitigar riesgos de forma temprana.
5. A pesar de las continuas crticas que las metodologas giles
sufren, son usadas por muchas grandes empresas y se han
utilizado en grandes sistemas, lo que hace prever que estas

metodologas han llegado para quedarse. RUP es una metodologa


que usa algunas de las mejores prcticas en desarrollo de
software, se adapta perfectamente a proyectos de gran escala y
complejidad, as como de grandes equipos de trabajo, tambin
cuenta con un gran nivel de aceptacin entre desarrolladores.
6. Por su parte MSF proporciona herramientas para llevar a cabo el
xito del proyecto, esto en cuanto a personas y procesos. Sus
principios, modelos, disciplinas, conceptos y prcticas contribuyen
a prevenir las causas de fracaso en el desarrollo de proyectos de
software.
7. Los mtodos tradicionales como RUP y MSF entre otros, son
bastante sistemticos en su proceso, los cual implica altos niveles
de

dedicacin

en

la

planificacin

documentacin

para

posteriormente lograr el desarrollo deseado, an as, stos


mtodos han ido evolucionando a versiones de la metodologa
enfocada a procesos agiles, tales como RUP gil y MSF gil, ya que
el mercado y la industria de desarrollo procura obtener resultados
a poco tiempo y dispuestos al cambio constante.
8. Todos los mtodos tienen sus limitaciones,

as

como

las

metodologas giles son las ms adecuadas para proyectos


pequeos y medianos, no son las ms adecuadas para sistemas de
gran escala que requieran de interacciones complejas con otros
sistemas, esto debido a que estos sistemas requieren de un nivel
de precisin bastante alto, aunque no todos los mtodos giles se
basan en el desarrollo y entrega incremental, si comparten los
principios del manifiesto gil para el desarrollo de software.
9. No sera conveniente implementar una metodologa gil para el
desarrollo de un sistema crtico en el cual es necesario el anlisis
detallado de todos los requerimientos para comprender su
complejidad e implicaciones, esto debido a la complejidad y la
extrema precisin que pueda tener la captura de requerimientos,

en los cules las metodologas XP y SCRUM ofrecen demasiada


flexibilidad.
10.
Dado que los mtodos giles hacen ms explcita la
importancia en el manejo del equipo y personas, se pueden pensar
cmo un complemento para las metodologas que estn ms
inclinadas a los procesos y la documentacin, tales como RUP y
MSF.

REFERENCIAS
1. Abrahamsson, P.; Salo, O.; Ronkainen, J. & Warsta, J. (2002), Agile
software development methods: Review and analysis, Espoo 2002,
VTT Publications 478, Oulu.
2. Amo, F,; Martnez, L, & Segovia, F, (2005). Introduccin a la
ingeniera del software: Modelos de desarrollo de programas, 1
Edicin. Madrid (Espaa), Delta Publicaciones. pp 335-349.
3. Beck, K. et al. (2001), Manifesto for Agile Software Development,
disponible

en:

http://agilemanifesto.org/,

recuperado:

18

de

Febrero de 2011.
4. Booch, G.; Rumbaugh, J. & Jacobson, I. (2000), EI proceso unificado
de desarrollo de software, Pearson Educacin, Madrid.
5. Booch, G.; Jacobson, I. & Rumbaugh, J.(2006), El lenguaje
Unificado

de

Modelado

2.0.

Edicin.

Addison

Wesley

Iberoamericana, Madrid.
6. Del Maschi, V. et al. (2007), Practical Experience in Customization
of a Software Development Process for Small Companies Based on
RUP Processes and MSF, en Portland International Center for
Management of Engineering and Technology, pp. 24402457.
7. Gattaca S. A., Presentacin Metodologa MSF, s. d.,disponible en:
http://www.e-gattaca.com/eContent/home2.asp, recuperado:10 de
Febrero de 2011.
8. International Business Machines (s.f.), Rational Unified Process.
IBM

[citado

01

Febrero

2011]

Disponible

en

ftp://public.dhe.ibm.com/software/rational/web/datasheets/RUP_DS
.pdf
9. Jeffries, R. (s. f.), Extreme Programming: An agile software
Development

Resource,

disponible

en:

http://xprogramming.com/index.php , recuperado:20 de Febrero de


2011.
10.
Leterlier, P. (s. f.), Introduccin a RUP, Departamento de
Sistemas
Politcnica

informticos
de

Computacin

Valencia

(UPV),

(DSIC),

Universidad

disponible

en:

https://pid.dsic.upv.es/C1/Material/

Documentos

%20Disponibles/Introducci%C3%B3n%

0a%20RUP.doc,

recuperado: 01 de Febrero de 2011.


11.
Llorens, J. (2005), Gerencia de proyectos de tecnologa de
informacin, Caracas, Los libros de EL NACIONAL.
12.
Microsoft, Microsoft Solutions Framework (MSF): Disciplinas
y

buenas

prcticas

proyectos,

para

literatura

el

gris,

desarrollo
Microsoft,

implantacin

de

s.d.,

disponible

en:

http://www.microsoft.com/colombia/portafolio/msf.htm,
recuperado: 09 de Febrero de 2011.
13.
Microsoft (2003), MSF Team Model Overview, white Paper,
Microsoft,

disponible

en:

http://technet.microsoft.com/es-

es/library/cc784945%28WS.10%29.

aspx,

recuperado:

11

de

Febrero de 2011.
14.
Microsoft (2003), Microsoft Solutions Framework, White
Paper,

Microsoft,

disponible

en:

http://www.microsoft.com/downloads/en/details.aspx?
FamilyID=A71AC896-1D28-45A4-880C-8B0CC8265C63,
recuperado: 09 de Febrero de2011.
15.
Mountain Goat Software (s.f.), Introduction to SCRUM - An
Agile

Process,

disponible

en:

mountaingoatsoftware.com/topics/SCRUM,
Febrero de 2011.
16.
Oktaba, H.

&

Piattini,

M.

http://www.

recuperado:18

(comps.),

Software

de

Process

Improvement for Small and Medium Enterprises: Techniques and


Case Studies, Hershey, ed. IG Global, pp. 7193.
17.
Pressman, R. & Murrieta, J. (2006), Ingeniera del software un
enfoque prctico. 6 Edicin. McGrawHill, pp. 67-73.
18.
Programacin
Extrema
(s.
d.),
disponible

en:

http://www.programacionextrema.org/, recuperado: 19 de Febrero


2011.
19.
Rational
Process
Teams

Software

Best

Corporation

Practices

for

(1998),
Software

,disponible

Rational

Unified

Development
en:

http://www.ibm.com/developerworks/rational/library/content/03July
/1000/1251/1251_bestpractices_TP026B.pdf,

citado

03

Febrero

2011.
20. Rising, L, & Janoff, N. (2000),The SCRUM software development

process for Small Teams, en SOFTWARE, IEEE, Vol. 17, No. 4,


July/August 2000, pp. 2632.