CARACTERSTICAS CASCADA

Se debe comprobar el Software despus de unirlo y antes de operarlo.

Es el ms utilizado

Deben desarrollarse todas las fases

Las fases continan hasta que los objetivos se han cumplido

Las flechas de la iteracin que unen los procesos juntos muestran cmo el desarrollo de un
producto influye en el desarrollo de productos anteriores.
PROGRAMACION EXTREMA XP
HISTORIA
La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de
software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme
Programming Explained: Embrace Change (1999). Es el ms destacado de los procesos giles
de desarrollo de software. Al igual que stos, la programacin extrema se diferencia de las
metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en
la previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la
marcha son un aspecto natural, inevitable e incluso deseable del desarrollo de proyectos.
Creen que ser capaz de adaptarse a los cambios de requisitos en cualquier punto de la vida del
proyecto es una aproximacin mejor y ms realista que intentar definir todos los requisitos al
comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los requisitos.
INTRODUCCION
Es una metodologa gil centrada en potenciar las relaciones interpersonales como clave para
el xito en desarrollo de software, promoviendo el trabajo en equipo, preocupndose por el
aprendizaje de los desarrolladores, y propiciando un buen clima de trabajo. XP se basa en
realimentacin continua entre el cliente y el equipo de desarrollo, comunicacin fluida entre
todos los participantes, simplicidad en las soluciones implementadas y coraje para enfrentar
los cambios. XP se define como especialmente adecuada para proyectos con requisitos
imprecisos y muy cambiantes, y donde existe un alto riesgo tcnico.
QU

ES PROGRAMACIN EXTREMA O XP?

Metodologa liviana de desarrollo de software
Conjunto de practicas y reglas empleadas para desarrollar software
Basada en diferentes ideas acerca de cmo enfrentar ambientes muy cambiantes
Originada en el proyecto C3 para Chrysler
En vez de planificar, analizar y disear para el futuro distante, hacer todo esto un
poco cada vez, a travs de todo el proceso de desarrollo
OBJETIVOS.
Establecer las mejores prcticas de Ingeniera de Software en los desarrollo de
proyectos.
Mejorar la productividad de los proyectos.

Garantizar la Calidad del Software desarrollando, haciendo que este supere las
expectativas del cliente.
CONTEXTO XP
Cliente bien definido
Los requisitos pueden (y van a) cambiar
Grupo pequeo y muy integrado (mximo 12 personas
Equipo con formacin elevada y capacidad de aprender
CARACTERSTICAS XP
Metodologa basada en prueba y error

Fundamentada en Valores y Prcticas

Expresada en forma de 12 PrcticasConjunto completoSe soportan unas a otrasSon
conocidas desde hace tiempo. La novedad es juntarlas
VALORES XP
Simplicidad XP propone el principio de hacer la cosa ms simple que pueda funcionar,
en relacin al proceso y la codificacin. Es mejor hacer hoy algo simple, que hacerlo
complicado y probablemente nunca usarlo maana.
Comunicacin Algunos problemas en los proyectos tienen origen en que alguien no
dijo algo importante en algn momento. XP hace casi imposible la falta de
comunicacin.
Realimentacin Retralimentacin concreta y frecuente del cliente, del equipo y de los
usuarios finales da una mayor oportunidad de dirigir el esfuerzo eficientemente.
Coraje El coraje (valor) existe en el contexto de los otros 3 valores.(si funciona
mejralo)
EL ESTILO XP
Esta orientada hacia quien produce y usa el software
Reduce el costo del cambio en todas las etapas del ciclo de vida del sistema.
Combina las que han demostrado ser las mejores practicas para desarrollar software,
y las lleva al extremo.
PRCTICAS BSICAS DE LA PROGRAMACIN EXTREMA
Para que todo esto funcione, la programacin extrema se basa en doce "prcticas bsicas" que
deben seguirse al pie de la letra. Dichas prcticas estn definidas (en perfecto ingls) en
www.xprogramming.com/xpmag/whatisxp.htm. Aqu tienes un pequeo resumen de ellas.
Equipo completo: Forman parte del equipo todas las personas que tienen algo que
ver con el proyecto, incluido el cliente y el responsable del proyecto.
Planificacin: Se hacen las historias de usuario y se planifica en qu orden se van a
hacer y las mini-versiones. La planificacin se revisa continuamente.
Test del cliente: El cliente, con la ayuda de los desarrolladores, propone sus propias
pruebas para validar las mini-versiones.
Versiones pequeas: Las mini-versiones deben ser lo suficientemente pequeas
como para poder hacer una cada pocas semanas. Deben ser versiones que ofrezcan
algo til al usuario final y no trozos de cdigo que no pueda ver funcionando.
Diseo simple: Hacer siempre lo mnimo imprescindible de la forma ms sencilla
posible. Mantener siempre sencillo el cdigo.
Pareja de programadores: Los programadores trabajan por parejas (dos delante del
mismo ordenador) y se intercambian las parejas con frecuencia (un cambio diario).
Desarrollo guiado por las pruebas automticas: Se deben realizar programas de
prueba automtica y deben ejecutarse con mucha frecuencia. Cuantas ms pruebas se
hagan, mejor.
Integracin continua: Deben tenerse siempre un ejecutable del proyecto que
funcione y en cuanto se tenga una nueva pequea funcionalidad, debe recompilarse y
probarse. Es un error mantener una versin congelada dos meses mientras se hacen
mejoras y luego integrarlas todas de golpe. Cuando falle algo, no se sabe qu es lo que
falla de todo lo que hemos metido.
El cdigo es de todos: Cualquiera puede y debe tocar y conocer cualquier parte del
cdigo. Para eso se hacen las pruebas automticas.
Normas de codificacin: Debe haber un estilo comn de codificacin (no importa
cual), de forma que parezca que ha sido realizado por una nica persona.
Metforas: Hay que buscar unas frases o nombres que definan cmo funcionan las
distintas partes del programa, de forma que slo con los nombres se pueda uno hacer

una idea de qu es lo que hace cada parte del programa. Un ejemplo claro es el
"recolector de basura" de java. Ayuda a que todos los programadores (y el cliente)
sepan de qu estamos hablando y que no haya mal entendidos.
Ritmo sostenible: Se debe trabajar a un ritmo que se pueda mantener
indefinidamente. Esto quiere decir que no debe haber das muertos en que no se sabe
qu hacer y que no se deben hacer un exceso de horas otros das. Al tener claro
semana a semana lo que debe hacerse, hay que trabajar duro en ello para conseguir el
objetivo cercano de terminar una historia de usuario o mini-versin.
MANEJO COLECTIVO DEL CDIGO
VENTAJAS Y DESVENTAJAS DE EXTREME PROGRAMMING
Ventajas:
Programacin organizada.
Menor taza de errores.
Satisfaccin del programador.
Desventajas:
Es recomendable emplearlo solo en proyectos a corto plazo.
Altas comisiones en caso de fallar.

Metodologas agiles
En febrero de 2001, tras una reunin celebrada en Utah-EEUU, nace el trmino .gil. aplicado al
desarrollo de software. En esta reunin participan un grupo de 17 expertos de la industria del
software, incluyendo algunos de los creadores o impulsores de metodologas de software. Su
objetivo fue esbozar los valores y principios que deberan permitir a los equipos desarrollar
software rpidamente y respondiendo a los cambios que puedan surgir a lo largo del proyecto.
Se pretenda ofrecer una alternativa a los procesos de desarrollo de software tradicionales,
caracterizados por ser rgidos y dirigidos por la documentacin que se genera en cada una de
las actividades desarrolladas.
Tras esta reunin se cre The Agile Alliance3, una organizacin, sin nimo de lucro, dedicada a
promover los conceptos relacionados con el desarrollo gil de software y ayudar a las
organizaciones para que adopten dichos conceptos. El punto de partida es fue el Manifiesto
gil, un documento que resume la filosofa .gil..
El Manifiesto gil.
Segn el Manifiesto se valora:
Al individuo y las interacciones del equipo de desarrollo sobre el proceso y las herramientas.
La gente es el principal factor de xito de un proyecto software. Es ms importante construir un
buen equipo que construir el entorno. Muchas veces se comete el error de construir primero el
entorno y esperar que el equipo se adapte automticamente. Es mejor crear el equipo y que
ste configure su propio entorno de desarrollo en base a sus necesidades.
Desarrollar software que funciona ms que conseguir una buena documentacin. La regla a
seguir es .no producir documentos a menos que sean necesarios de forma inmediata para
tomar un decisin importante.. Estos documentos deben ser cortos y centrarse en lo
fundamental.
La colaboracin con el cliente ms que la negociacin de un contrato. Se propone que exista
una interaccin constante entre el cliente y el equipo de desarrollo. Esta colaboracin entre
ambos ser la que marque la marcha del proyecto y asegure su xito.
Responder a los cambios ms que seguir estrictamente un plan. La habilidad de responder a
los cambios que puedan surgir a los largo del proyecto (cambios en los requisitos, en la
tecnologa, en el equipo, etc.) determina tambin el xito o fracaso del mismo. Por lo tanto, la
planificacin no debe ser estricta sino flexible y abierta.

Los valores anteriores inspiran los doce principios del manifiesto. Son caractersticas que
diferencian un proceso gil de uno tradicional. Los dos primeros principios son generales y
resumen gran parte del espritu gil. El resto tienen que ver con el proceso a seguir y con el
equipo de desarrollo, en cuanto metas a seguir y organizacin del mismo.
PRINCIPIOS:
I. La prioridad es satisfacer al cliente mediante tempranas y continuas entregas de software
que le aporte un valor.
II. Dar la bienvenida a los cambios. Se capturan los cambios para que el cliente tenga una
ventaja competitiva.
III. Entregar frecuentemente software que funcione desde un par de semanas a un par de
meses, con el menor intervalo de tiempo posible entre entregas.
IV. La gente del negocio y los desarrolladores deben trabajar juntos a lo largo del proyecto.
V. Construir el proyecto en torno a individuos motivados. Darles el entorno y el apoyo que
necesitan y confiar en ellos para conseguir finalizar el trabajo.
VI. El dilogo cara a cara es el mtodo ms eficiente y efectivo para comunicar informacin
dentro de un equipo de desarrollo.
VII. El software que funciona es la medida principal de progreso.
VIII. Los procesos giles promueven un desarrollo sostenible. Los promotores, desarrolladores y
usuarios deberan ser capaces de mantener una paz constante.
IX. La atencin continua a la calidad tcnica y al buen diseo mejora la agilidad.
X. La simplicidad es esencial.
XI. Las mejores arquitecturas, requisitos y diseos surgen de los equipos organizados por s
mismos.
XII. En intervalos regulares, el equipo reflexiona respecto a cmo llegar a ser ms efectivo, y
segn esto ajusta su comportamiento
Lista de metodologas giles
En la actualidad se cuentan alrededor de 15 a20 metodologas agiles sin contar los mtodos
hbridos de desarrollo que integran en sus practicas como ejemplo a Xp con Scrum. A
continuacin el listado de metodologas agiles en desarrollo de software ms representativas
con el ao de creacin, acrnimo y autor.

Metodologas que se basan en procesos rpidos, pensados en ser funcionales, adaptables y

adems manejan similitudes entre ellos y pueden complementarse o formar mtodos hbridos.
Metodologas ligeras vs mtodos tradicionales
Aunque las metodologas ligeras se basan en las ideas de los procesos tradicionales estas usan
lo mas importante para el buen desarrollo del proyecto con lgicay dejando atrs el manejo
excesivo de artefactos y burocracia.

Diferencias entre mtodos agiles y metodologas tradicionales.

Uso de mtodos agiles
Desde el surgimiento de estas revolucionarias metodologas que no solo nacen para el
desarrollo de sistemas software sino para el management o desarrollo de productos los
incrementos en adeptos se presentan gradualmente con el tiempo y las tecnologas.
Y los que las usan, Por qu razn o razones lo hacen?:

Para reducir el tiempo de desarrollo: 45%

Para mejorar la calidad: 43%

Para reducir costes: 23%

Para alinear el desarrollo con los objetivos de negocio: 39%

Otras razones: 12%.

Y cul es el ranking de preferencias entre modelos giles? 1.- Extreme Programming (28%)
2.- FDD (26%) 3.- Scrum (20%) 4.- Crystal (6%) gil 5.- DSDM (4%) Fuente: Agile Journal [2],
n1, Marzo-2006.
METODOLOGIAS AGILES RUP
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" (bullpenen 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 y tratados como "indisciplinados" por la falta de documentacin
tcnica.
HISTORIA
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
introductoriosobre 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 ver la
broma). 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 y 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 y 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. Secorrigen 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 y 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 de requerimientos. Identifica requerimientos cambiantes y postula una
estrategia disciplinada para administrarlos.
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.

Qu es UML?
El Lenguaje de Modelado Unificado

Introduccin
Una exigencia de
la gran mayora
de instituciones
dentro de su
Plan Informtico
estratgico, es
que los
desarrollos de
software bajo una
arquitectura en
Capas, se
formalicen con un
lenguaje
estndar y
unificado.
Es decir, se
requiere que
cada una de las
partes que
comprende el
desarrollo de
todo software de
diseo orientado
a objetos, se
visualice,
especifique y
documente con
lenguaje comn.
Se necesitaba un
lenguaje que
fuese grfico, a
fin de especificar
y documentar un
sistema de
software, de un
modo estndar
incluyendo
aspectos

conceptuales
tales como
procesos de
negocios y
funciones del
sistema.
Este lenguaje
unificado que
cumple con estos
requerimientos,
es ciertamente
UML, el cual
cuenta con una
notacin
estndar y
semnticas
esenciales, para
el modelado de
un sistema
orientado a
objetos.
As mismo,
aquellos que
deseen enmarcar
conceptualmente
desde su gnesis
UML, recomiendo
comprender los
Fundamentos de
los Lenguajes
Estructurados.
El UML unido a un
gestin de
calidad, evita
malos
entendidos y
entrega ciertas
precauciones en
la evolucin y
mantencin de
programas.
Especialmente en
lo referente a los
requerimientos
asociados al
levantamiento y
diseo funcional
de un sistema. En
efecto, por
ejemplo con los
Clientes Dilema,

quienes no
podrn hacer
pensar que el
cambio que estn
solicitando es
pequeo, cuando
detrs de la
peticin existe
una enorme
cantidad de
tareas
relacionadas al
requerimiento.
Cabe preguntarse
Cules son las
caractersticas
que debe tener
una herramienta
UML?.

Qu es UML?
El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesin de una
serie de mtodos de anlisis y diseo orientadas a objetos que aparecen a fines de los 80's y
principios de los 90s.UML es llamado un lenguaje de modelado, no un mtodo. Los mtodos
consisten de ambos de un lenguaje de modelado y de un proceso.
El UML , fusiona los conceptos de la orientacin a objetos aportados por Booch, OMT y OOSE
(Booch, G. et al., 1999).
UML incrementa la capacidad de lo que se puede hacer con otros mtodos de anlisis y diseo
orientados a objetos. Los autores de UML apuntaron tambin al modelado de sistemas
distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos
dominios.
El lenguaje de modelado es la notacin (principalmente grfica) que usan los mtodos para
expresar un diseo. El proceso indica los pasos que se deben seguir para llegar a un diseo.
La estandarizacin de un lenguaje de modelado es invaluable, ya que es la parte principal del
proceso de comunicacin que requieren todos los agentes involucrados en un proyecto
informtico. Si se quiere discutir un diseo con alguien ms, ambos deben conocer el lenguaje
de modelado y no as el proceso que se sigui para obtenerlo.

Ver RobotDocIRS y Cules son las caractersticas que debe tener una herramienta UML?
Semntica y Notacin
Una de la metas principales de UML es avanzar en el estado de la integracin institucional
proporcionando herramientas de interoperabilidad para el modelado visual de objetos. Sin
embargo para lograr un intercambio exitoso de modelos de informacin entre herramientas, se
requiri definir a UML una semntica y una notacin.
La notacin es la parte grfica que se ve en los modelos y representa la sintaxis del lenguaje
de modelado. Por ejemplo, la notacin del diagrama de clases define como se representan los
elementos y conceptos como son: una clase, una asociacin y una multiplicidad. Y qu
significa exactamente una asociacin o multiplicidad en una clase?. Un metamodelo es la
manera de definir esto (un diagrama, usualmente de clases, que define la notacin).
Para que un proveedor diga que cumple con UML debe cubrir con la semntica y con la
notacin.
Una herramienta de UML debe mantener la consistencia entre los diagramas en un mismo
modelo. Bajo esta definicin una herramienta que solo dibuje, no puede cumplir con la
notacin de UML.
El lenguaje est dotado de mltiples herramientas para lograr la especificacin determinante
del modelo, pero en nuestro caso se trabaja en forma simplificada sobre:

Modelamiento de Clases

Casos de Uso

Diagrama de Interaccin

Los diagramas de clases de UML forman la vista lgica.

Los diagramas de interaccin de UML constituyen la vista de proceso.

La vista de desarrollo captura el software en su entorno de desarrollo.

Los diagramas de despliegue integran la vista fsica .

Los escenarios: el modelo de casos de uso.

(A continuacin partes de un artculo de Patricio Salinas Caro y Nancy Hitschfeld Kahler de

Universidad de Chile, Facultad de Ciencias Fsicas y Matemticas,Departamento de Ciencias de
la Computacin )
Modelamiento de Clases
Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el
sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.
Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, mtodos y visibilidad.

Relaciones: Herencia, Composicin, Agregacin, Asociacin y Uso.

Elementos

Clase

Es la unidad bsica que encapsula toda la informacin de un Objeto (un objeto es una
instancia de una clase). A travs de ella podemos modelar el entorno en estudio (una
Casa, un Auto, una Cuenta Corriente, etc.).
En UML, una clase es representada por un rectngulo que posee tres divisiones:

En donde:

Superior: Contiene el nombre de la Clase

Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la

Clase (pueden ser private, protected o public).

Inferior: Contiene los mtodos u operaciones, los cuales son la forma como interacta
el objeto con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:
Una Cuenta Corriente que posee como caracterstica:

Balance

Puede realizar las operaciones de:

Depositar

Girar

y Balance

El diseo asociado es:

Atributos y Mtodos:

Atributos:

Los atributos o caractersticas de una Clase pueden ser de tres tipos, los que definen el
grado de comunicacin y visibilidad de ellos con el entorno, estos son:
o

public (+): Indica que el atributo ser visible tanto dentro como fuera de la
clase, es decir, es accsesible desde todos lados.

private (-): Indica que el atributo slo ser accesible desde dentro de la clase
(slo sus mtodos lo pueden accesar).

protected (#): Indica que el atributo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de las subclases que

se deriven (ver herencia).

Mtodos:
Los mtodos u operaciones de una clase son la forma en como sta interacta con su
entorno, stos pueden tener las caractersticas:
o

public (+): Indica que el mtodo ser visible tanto dentro como fuera de la
clase, es decir, es accsesible desde todos lados.

private (-): Indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos de la clase lo pueden accesar).

protected (#): Indica que el mtodo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de mtodos de las
subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar
dos o ms clases (cada uno con caractersticas y objetivos diferentes).
Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad
de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la
relacin y stas pueden ser:

uno o muchos: 1..* (1..n)

0 o muchos: 0..* (0..n)

nmero fijo: m (m denota el nmero).

i. Herencia (Especializacin/Generalizacin):
Indica que una subclase hereda los mtodos y atributos especificados por una Super Clase, por
ende la Subclase adems de poseer sus propios mtodos y atributos, poseer las
caractersticas y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camin heredan de Vehculo, es decir, Auto posee las
Caractersticas de Vehculo (Precio, VelMax, etc) adems posee algo particular que es
Descapotable, en cambio Camin tambin hereda las caractersticas de Vehiculo (Precio,
VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo nico "visible" es el mtodo Caractersticas
aplicable a instancias de Vehculo, Auto y Camin, pues tiene definicin publica, en cambio
atributos como Descapotable no son visibles por ser privados.
Agregacin:
Para modelar objetos complejos, n bastan los tipos de datos bsicos que proveen los lenguajes:
enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son
instancias de clases definidas por el desarrollador de la aplicacin, tenemos dos posibilidades:

Por Valor: Es un tipo de relacin esttica, en donde el tiempo de vida del objeto
incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relacin
es comnmente llamada Composicin (el Objeto base se construye a partir del objeto
incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relacin dinmica, en donde el tiempo de vida del objeto
incluido es independiente del que lo incluye. Este tipo de relacin es comnmente
llamada Agregacin (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las
referencias).

Cuando se destruye el Objeto Almacn tambin son destruidos los objetos Cuenta
asociados, en cambio no son afectados los objetos Cliente asociados.

La composicin (por Valor) se destaca por un rombo relleno.

La agregacin (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relacin indica la navegabilidad del objeto refereniado. Cuando no
existe este tipo de particularidad la flecha se elimina.
Asociacin:
La relacin entre clases conocida como Asociacin, permite asociar objetos que colaboran
entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de vida de un objeto
no depende del otro.
Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de
compra solo puede tener asociado un cliente.
Dependencia o Instanciacin (uso):
Representa un tipo de relacin muy particular, en la que una clase es instanciada (su
instanciacin es dependiente de otro objeto/clase). Se denota por una flecha punteada.
El uso ms particular de este tipo de relacin es para denotar la dependencia que tiene una
clase de otra, como por ejemplo una aplicacin grafica que instancia una ventana (la creacin
del Objeto Ventana esta condicionado a la instanciacin proveniente desde el objeto
Aplicacin):

Cabe destacar que el objeto creado (en este caso la Ventana grfica) no se almacena dentro
del objeto que lo crea (en este caso la Aplicacin).
Casos Particulares:

Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los mtodos con letra "itlica".
Esto indica que la clase definida no puede ser instanciada pues posee mtodos abstractos (an
no han sido definidos, es decir, sin implementacin). La nica forma de utilizarla es definiendo
subclases, que implementan los mtodos abstractos definidos.
Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en

donde se especifican los parmetros que deben ser pasados a la clase para que esta pueda ser
instanciada. El ejemplo ms tpico es el caso de un Diccionario en donde una llave o palabra
tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genricos.
La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna
estructura predefinida (especializacin a travs de clases).
En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependern
exclusivamente de la implementacin que se le quiera dar.

Ejemplo:
Supongamos que tenemos tenemos un el caso del Diccionario implementado mediante un
rbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la bsqueda, puede ser genrica.

item: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo tambin

puede ser genrico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las
cuales pueden funcionar como llaves o como item, solo se mostrarn las relaciones para la
implementacin del Diccionario:

Casos de Uso (Use Case)

Introduccin
El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el
sistema en desarrollo, adems de la forma, tipo y orden en como los elementos interactuan
(operaciones o casos de uso).
Un diagrama de casos de uso consta de los siguientes elementos:

Actor.

Casos de Uso.

Relaciones de Uso, Herencia y Comunicacin.

Elementos

Actor:

Una definicin previa, es que un Actor es un rol que un usuario juega con respecto al sistema.
Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no
necesariamente representa a una persona en particular, sino ms bien la labor que realiza

frente al sistema.
Como ejemplo a la definicin anterior, tenemos el caso de un sistema de ventas en que el rol
de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de
Local.

Caso de Uso:

Es una operacin/tarea especfica que se realiza tras una orden de algn agente
externo, sea desde una peticin de un actor o bien desde la invocacin desde otro caso
de uso.

Relaciones:

Asociacin

Es el tipo de relacin ms bsica que indica la invocacin desde un actor o caso

de uso a otra operacin (caso de uso). Dicha relacin se denota con una flecha
simple.

Dependencia o Instanciacin
Es una forma muy particular de relacin entre clases, en la cual una clase
depende de otra, es decir, se instancia (se crea). Dicha relacin se denota con
una flecha punteada.

Generalizacin
Este tipo de relacin es uno de los ms utilizados, cumple una doble funcin
dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de
Herencia (<<extends>>).
Este tipo de relacin esta orientado exclusivamente para casos de uso (y no para
actores).
extends: Se recomienda utilizar cuando un caso de uso es similar a otro
(caractersticas).
uses: Se recomienda utilizar cuando se tiene un conjunto de caractersticas que
son similares en ms de un caso de uso y no se desea mantener copiada la
descripcin de la caracterstica.
De lo anterior cabe mencionar que tiene el mismo paradigma en diseo y
modelamiento de clases, en donde esta la duda clsica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Mquina Recicladora:

Sistema que controla una mquina de reciclamiento de botellas, tarros y jabas. El sistema debe
controlar y/o aceptar:

Registrar el nmero de temes ingresados.

Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado
b. El valor de cada item
c. Total

El usuario/cliente presiona el botn de comienzo

Existe un operador que desea saber lo siguiente:

a. Cuantos temes han sido retornados en el da.
b. Al final de cada da el operador solicita un resumen de todo lo depositado en el
da.

El operador debe adems poder cambiar:

a. Informacin asociada a temes.
b. Dar una alarma en el caso de que:
i.

Item se atora.

ii.

No hay ms papel.

Como una primera aproximacin identificamos a los actores que interactuan con el sistema:

Luego, tenemos que un Cliente puede Depositar Itemes y un Operador puede cambiar la
informacin de un Item o bien puede Imprimir un informe:

Adems podemos notar que un item puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresin de comprobantes, que puede ser realizada despus de depositar
algn item por un cliente o bien puede ser realizada a peticin de un operador.

Entonces, el diseo completo del diagrama Use Case es:

Diagrama de Interaccin
Introduccin
El diagrama de interaccin, representa la forma en como un Cliente (Actor) u Objetos (Clases)
se comunican entre si en peticin a un evento. Esto implica recorrer toda la secuencia de
llamadas, de donde se obtienen las responsabilidades claramente.
Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Esttico de Clases o el
de Casos de Uso (son diferentes).
Los componentes de un digrama de interaccin son:

Un Objeto o Actor.

Mensaje de un objeto a otro objeto.

Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectngulo representa una instancia de un Objeto en particular, y la lnea punteada

representa las llamadas a mtodos del objeto.

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un
mtodo (operacin) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a mtodos de objetos externos pueden realizarse, tambin es posible

visualizar llamadas a mtodos desde el mismo objeto en estudio.
Ejemplo
En el presente ejemplo, tenemos el diagrama de interaccin proveniente del siguiente modelo
estatico:

Aqu se representa una aplicacin que posee una Ventana grfica, y sta a su vez posee
internamente un botn.
Entonces el diagrama de interaccin para dicho modelo es:

En donde se hacen notar las sucesivas llamadas a Draw() (entre objetos) y la llamada a Paint()
por el objeto Botn.
Bibliografa:

http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html

Autores: Diana Palliotto; Gabriel Romano Universidad Nacional de Santiago del Estero
Facultad de Ciencias Exactas y Tecnologas Direccin: Departamento de Informtica Av. Belgrano (S) 1912, (4200) Santiago del Estero, Argentina.- E-Mail:

UML Tools
By Mandar Chitnis, Pravin Tiwari, & Lakshmi Ananthamurthy

Los beneficios del Modelador Bizagi

MODELO DE PROTOTIPOS Y MODELO EN ESPIRAL, CARACTERISTICAS Y DIFERENCIAS,

Y SU PAPEL EN EL CICLO DE VIDA CLASICO
MODELO DE PROTOTIPO:
Es un modelo del ciclo de vida del software el cual se utiliza para dar al usuario una vista
preliminar de cmo se encuentra el software. Este modelo es bsicamente prueba y error ya
que si al usuario no le gusta una parte del prototipo significa que la prueba fallo por lo cual se
debe corregir el error que se tenga hasta que el usuario quede satisfecho.
CARACERISTICAS
<!--[if !supportLists]--> <!--[endif]-->Describe las fases principales de desarrollo de software.
<!--[if !supportLists]--> <!--[endif]-->Define las fases primarias esperadas de ser ejecutadas
durante esas fases.
<!--[if !supportLists]-->
software

<!--[endif]-->Ayuda a administrar el progreso del desarrollo del

<!--[if !supportLists]--> <!--[endif]-->Provee un espacio de trabajo para la definicin de un

detallado proceso de desarrollo de software.
VENTAJAS
<!--[if !supportLists]--> <!--[endif]-->Ser fcilmente modificable.
<!--[if !supportLists]--> <!--[endif]-->Reducir los costos de rediseo si los problemas se
detectan pronto y cuando son fciles de localizar.
<!--[if !supportLists]--> <!--[endif]-->Este modelo es til cuando el cliente conoce los
objetivos generales para el software.

DESVENTAJAS
<!--[if !supportLists]--> <!--[endif]-->Hacer pensar a los usuarios que el producto final est
prcticamente terminado.
<!--[if !supportLists]--> <!--[endif]-->Llevar a un nmero de cambios excesivo.
MODELO EN ESPIRAL:

Es un modelo de proceso de software evolutivo el cual es a base de una serie de ciclos los
cuales se repiten en forma de espiral, esta orientados a evitar riesgos de trabajo. Cada vez que
se avanza un ciclo se va alcanzando un nivel superior hasta concluir el proyecto.
CARACTERISTICAS
<!--[if !supportLists]--> <!--[endif]-->Es un modelo que puede combinarse con otros modelos
de procesos de desarrollo (cascada y evolutivo).
<!--[if !supportLists]--> <!--[endif]-->Es el mejor modelo que se utiliza para desarrollar
grandes sistemas.
<!--[if !supportLists]-->
personal con experiencia.

<!--[endif]-->El anlisis de riesgo requiere la participacin de

VENTAJAS
<!--[if !supportLists]--> <!--[endif]-->Modelo de proceso adaptable.
<!--[if !supportLists]--> <!--[endif]-->El modelo de espiral puede aplicarse a lo largo de la
vida del software.
<!--[if !supportLists]--> <!--[endif]-->Es apropiado para desarrollar Sistemas Operativos.
DESVENTAJAS
<!--[if !supportLists]--> <!--[endif]-->No se ha utilizado mucho ya que es un modelo nuevo.
<!--[if !supportLists]--> <!--[endif]-->Debido a la complejidad no se recomienda utilizarlo en
sistemas pequeos.
<!--[if !supportLists]--> <!--[endif]-->Es un modelo costoso.
COMPARACION ENTRE MODELOS PROTOTIPO Y ESPIRAL
CRITERIO

PROTOTIPADO

ESPIRAL

Disponibilidad de recursos

Algunos

Algunos

Complejidad del proyecto

Media

Alta

Entendimiento de requerimientos

Vago

Vago

Tecnologa del producto

Vago

Vago

de

Si

Si

de

Regular

Pobre

Manejo
riesgo

de

Conocimiento
problemas

la

perspectiva

del

dominio

UWE - UML-based WEB Engineering

UME es un mtodo, de ingeniera WEB orientada a objetos basada en UML, que puede ser utilizado para
la especificacin de aplicaciones WEB.
La aproximacin propuesta por UWE provee:
1. una notacin especfica de dominio
2. un proceso de desarrollo basado en el modelo, y
3. una herramienta de soporte para la ingeniera de aplicaciones WEB.
La principal caracteristica de UWE es el hecho de ser una aproximacin basada en estndares, la cual no
se lmita al uso de UML, adems integra:
1. XMI como modelo de intercambio de formatos,
2. MOF para los metamodelos
3. los principios de la aproximacin MDA (dirigida por el modelo),
4. el modelo de transformacin del lenguaje QVT y
5. XML
La razn principal para extender UML en lugar de crear una tcnica de modelamiento propietaria, es la
aceptacin de UML en el proceso de desarrollo de software, la flexibilidad para la definicin de un lenguaje
de modelamiento especfico en el dominio WEB, tambin llamado perfil UML, y un gran soporte del modelo
de visualizacin con las herramientas existentes de UML CASE.
UWE hace uso de notacion UML pura y los tipos de diagramas UML en donde sea posible para el anlisis y
diseo de aplicaciones WEB. Para las caractersticas de aplicaciones WEB especficas, como nodos y
vnculos de la estructura de hyper-texto, el perfil UWE incluye:

estereotipos,

valores marcados y

limitaciones definidas para los elementos de modelamiento.

La extensin de UWE cubre la navegacin, presentacin, lgica del negocio y aspectos de adaptacin. La
notacin UWE se define como una extensin "ligera" de UML.
La aproximacin de diseo UWE para los procesos del negocio consiste en introducir clases especficas
del proceso, que son parte de un modelo de proceso separado con una interfaz definida para el modelo de
navegacin.
El modelamiento de las caractersticas adaptativas de las aplicaciones WEB se hace de manera no
invasiva, es decir, UWE usa tcnicas de modelamiento orientadas por aspectos (AOM), siguiendo el
principio separacin de preocupaciones UWE propone construir un modelo adaptativo para sistemas
personalizados o dependientes del contexto y despus entrelazar los modelos.

5 beneficios de aplicar metodologas giles en el desarrollo de software

El desarrollo gil de software refiere a mtodos de ingeniera del software basados en el desarrollo
iterativo e incremental, estas metodologas son imprescindibles en un mundo en el que nos
exponemos a cambios recurrentemente. Siempre hay que tener en cuenta como programadores que
lo que es la ltima tendencia hoy puede que no exista maana y por esto existe la metodologa gil

donde los requisitos y soluciones evolucionan mediante la colaboracin de grupos auto organizados y
multidisciplinarios.

Mtodos y Procesos en la Metodologa gil

De entre todos los mtodos de desarrollo gil, estos son los 3 que actualmente dominan el
panorama:
1. SCRUM

El Scrum es un proceso de la Metodologa gil que se usa para minimizar los riesgos durante la

realizacin de un proyecto, pero de manera colaborativa.

Entre las ventajas se encuentran la productividad, calidad y que se realiza un seguimiento diario
de los avances del proyecto, logrando que los integrantes estn unidos, comunicados y que el cliente
vaya viendo los avances. La profundidad de las tareas que se asignan en SCRUM tiende a ser
incremental, caso que coincide exactamente con el devenir normal de un desarrollo.
Es perfecto para empresas de desarrollo de software orientadas a varios clientes. Esta por otro lado
es la metodologa que se utiliza en I2B.
2. XP o Extreme Programming
La programacin extrema es un proceso de la Metodologa gil que se aplica en equipos con muy
pocos programadores quienes llevan muy pocos procesos en paralelo. Consiste entonces en disear,
implementar y programar lo ms rpido posible, hasta en casos se recomienda saltar la
documentacin y los procedimientos tradicionales. Se fundamenta en la capacidad del equipo para
comunicarse entre s y las ganas de aprender de los errores propios inherentes en un programador.
La gran ventaja de XP es su increble capacidad de respuesta ante imprevistos, aunque por diseo es
una metodologa que no construye para el largo plazo y para la cual es difcil documentar.
XP es un mtodo estupendo para equipos extremadamente pequeos que se centran en un solo
cliente.
3. Desarrollo Ligero o Lean
Tambin conocido como Lean Programming, este es un conjunto de tcnicas que engloban un
proceso de la Metodologa gil en desarrollo de software orientado a conseguir exactamente lo que

necesita el cliente. Es una evolucin del Mtodo Toyota de Produccin aplicado al desarrollo y que
est muy de moda entre los equipos de desarrollo en startups.
Principalmente se identifica por hacer uso de ciclos de evolucin de software incrementales en los
que se alejan las decisiones lo ms posible hasta no tener retroalimentacin por parte del cliente y
con esto reaccionar de modo ms flexible posible contra sus posibles necesidades. Por esto mismo de
provenir de una metodologa Japonesa de trabajo se fundamenta en tener un equipo muy capaz y
comprometido al principio del aprendizaje continuo.
El Desarrollo Lean una metodologa fantstica para empresas que estn desarrollando un software
B2C orientado a tener xito en el mercado.

Beneficios de aplicar la Metodologa gil

1. RSI superior
Cuando se lidia con proyectos mltiples y no se aplican metodologas gil, lo normal es
esperar a que se complete un proceso antes de arrancar con el segundo. Para poder lidiar con
este tipo de operacin de proyectos se estila buscar el cmo finalizar entregas lo ms pronto
posibles lo cual significa un inmenso riesgo de recorte de funcionalidades o calidad.
El desarrollo con metodologa gil refuerza las entregas mltiples lo cual contra el cliente es
un indicador operante y de cierto modo representara un capital en trabajo. Como tal se
refuerza ms bien la lista de funcionalidades del acuerdo de entrega y en el promedio implica
un enfoque en desarrollar la funcionalidad que se considere ms vital para el proyecto desde
el simple inicio.
2. El desarrollo gil aumenta la productividad
La produccin de software que trabaja alrededor de las necesidades de negocio implica
ingresar conocimiento multidisciplinario en etapas simultneas. La metodologa gil sirve para
enfocar la atencin de los partidos por disciplina en el espacio que se les necesita e
inmediatamente liberar el talento para que puedan moverse entre zonas de trabajo.
Aplicar un sistema de tarea discretas contra las personas que las ejecutan simplifican la
distribucin de entrega de informacin y consecuentemente del mismo sentido de capacidad
de control del mismo empleado lo cual resulta en un deseo inherente de procesar las tareas
lo ms simple y rpidamente posible.
3. Simplifica el manejo de la sobrecarga de procesos
Los equipos que trabajan sobre normas y regulaciones han de validar su trabajo
constantemente lo cual representa un doble sentido de trabajo. Las metodologas por
iteracin simplifican el proceso de entrega versus validacin lo cual adems permite adoptar
cambios sobre la marcha del alcance del proyecto.
4. Mejor perfil de productividad
Los equipos giles son ms productivos que aquellos que utilizan mtodos tradicionales a lo
largo de todo el ciclo de desarrollo. Si no se aplica un sistema gil se presenta un patrn de
desarrollo tipo palo de hockey donde la mayora del trabajo sucede en las primeras etapas y
ya que anden los equipos se van haciendo ajustes sobre el trabajo anterior. La realidad es que
casi nunca suele suceder que las piezas en equipo terminan trabajando juntos de manera
coherente.
Los equipos giles que mantienen un nivel de revisin por unidades discretas de entrega de
trabajo con cada iteracin permiten realizar pruebas de rendimiento y sistemas desde el
principio. De este modo, defectos crticos como problemas de integracin se descubren antes,
la calidad general del producto es mayor y el equipo funciona de manera ms productiva
durante todo el ciclo de desarrollo.

5. Una mejor gestin del riesgo

No siempre se logra cumplir con las metas de lanzamiento cuando se trabaja con software,
mientras ms lejanas sean las entregas contra cliente o equipo ms se maximiza el riesgo de
potencial desviacin de la entrega contra la definicin del proyecto inicial. Las metodologas
gil permiten repasar en ciclos continuos progreso in media res de entregables y productos
semi-cerrados. Cuando fallan las entregas la metodologa gil permite ajustar el ciclo de
trabajo para enfocar el talento en zonas de mayor o menor riesgo a justificacin de defender
un proyecto en su totalidad.
Modelo Incremental
El modelo incremental fue propuesto por Harlan Mills en el ao 1980. Surgi el enfoque
incremental de desarrollocomo una forma de reducir la repeticin del trabajo en el proceso de
desarrollo y dar oportunidad de retrasar la toma de decisiones en los requisitos hasta
adquirirexperiencia con el sistema. Este modelo se conoce tambin bajo las siguientes
denominaciones:

Mtodo de las comparaciones limitadas sucesivas.

Ciencia de salir del paso.

Mtodo de atacar el problema por ramas.

El Modelo Incremental combina elementos del Modelo Lineal Secuencial con la filosofa
interactiva de Construccin de Prototipos. Como se muestra en la Figura 1, el modelo
incremental aplica secuencias lineales de forma escalonada mientras progresa el tiempo en el
calendario. Cada secuencia lineal produce un incremento del software. El primer incremento
generalmente
es
un
producto
esencial
denominado
ncleo.
En una visin genrica, el proceso se divide en 4 partes:

Anlisis

Diseo

Cdigo

Prueba

Sin embargo, para la produccin del Software, se usa el principio de trabajo en cadena o
Pipeline. Con esto se mantiene al cliente en constante contacto con los resultados obtenidos en
cada incremento. Es el mismo cliente el que incluye o desecha elementos al final de cada
incremento a fin de que el software se adapte mejor a sus necesidades reales. El proceso se
repite hasta que se elabora el producto completo. De esta forma el tiempo de entrega se
reduce considerablemente.
El Modelo Incremental es de naturaleza interactiva brindando al final de cada incremento la
entrega de un producto completamente operacional. Este modelo es particularmente til
cuando no se cuenta con una dotacin de personal suficiente. Los primeros pasos los pueden
realizar un grupo reducido de personas y en cada incremento se aadir personal, de ser
necesario. Por otro lado los incrementos se pueden planear para gestionar riesgos tcnicos.

Durante el proceso se trata de llevar a cabo al proyecto en diferentes partes que al

final terminar siendo la solucin completa requerida por el cliente, pero stas
partes no se pueden realizar en cualquier orden, sino que dependen de lo que el
cliente este necesitando con ms urgencia, de los puntos ms importantes del
proyecto, los requerimientos ms bsicos, difciles y con mayor grado de riesgo, ya
que estos se deben hacer al comienzo, de manera que se disminuya la dificultad y el
riesgo en cada versin.
De este modo podemos terminar una aplicacin ejecutable (primera versin) que podr ser
entregada al cliente para que ste pueda trabajar en ella y el programador pueda considerar
las recomendaciones que el cliente efecte para hacer mejoras en el producto. Estas nuevas
mejoras debern esperar a ser integradas en la siguiente versin junto con los dems
requerimientos
que
no
fueron
tomados
en
cuenta
en
la
versin
anterior.
El modelo incremental consiste en un desarrollo inicial de la arquitectura completa del sistema,
seguido de sucesivos incrementos funcionales. Cada incremento tiene su propio ciclo de vida y
se basa en el anterior, sin cambiar su funcionalidad ni sus interfaces. Una vez entregado un
incremento, no se realizan cambios sobre el mismo, sino nicamente correccin de errores.
Dado que la arquitectura completa se desarrolla en la etapa inicial, es necesario conocer los
requerimientos
completos
al
comienzo
del
desarrollo.
Al iniciar del desarrollo, los clientes o los usuarios, identifican a grandes rasgos, las
funcionalidades que proporcionar el sistema. Se confecciona un bosquejo de requisitos
funcionales y ser el cliente quien se encarga de priorizar que funcionalidades son mas
importantes. Con las funcionalidades priorizadas, se puede confeccionar un plan de
incrementos, donde en cada incremento se indica un subconjunto de funcionalidades que el
sistema entregar. La asignacin de funcionalidades a los incrementos depende de la prioridad
dada a los requisitos. Finalizado el plan de incrementos, se puede comenzar con el primer
incremento.
Caractersticas:

Se evitan proyectos largos y se entrega "algo de valor" a los usuarios con cierta
frecuencia.

El usuario se involucra mas.

Dificil de evaluar el costo total.

Dificil de aplicar a los sistemas transaccionales que tienden a ser integrados y a operar
como un todo.

Requiere gestores experimentados.

Los errores en los requisitos se detectan tarde.

El resultado puede ser positivo.

Ventajas:

Con un paradigma incremental se reduce el tiempo de desarrollo inicial, ya que se

implementa la funcionalidad parcial.

Tambin provee un impacto ventajoso frente al cliente, que es la entrega temprana de

partes operativas del software.

El modelo proporciona todas las ventajas del modelo en Cascada realimentado,

reduciendo sus desventajas slo al mbito de cada incremento.

Resulta ms sencillo acomodar cambios al acotar el tamao de los incrementos.

Desventajas:

El modelo incremental no es recomendable para casos de sistemas de tiempo real, de

alto nivel de seguridad, de procesamiento distribuido y/o de alto ndice de riesgos.

Requiere de mucha planeacin, tanto administrativa como tcnica.

Requiere de metas claras para conocer el estado del proyecto.

Lxico Extendido del Lenguaje (LEL)

Nmero
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

Smbolo
Anlisis
Analista
Codificacin
Desarrollador
Diseador
Diseo
Entregar el incremento
Especificacin de requisitos
Incremento
Incremento rechazado
Incremento validado
Modelo de arquitectura de software
Modelo de diseo
Ncleo
Plan de incremento
Producto
Producto completo
Producto incompleto
Prueba
Prueba de aceptacin
Prueba de integracin
Prueba unitaria
Tester

Tipo
Verbo
Sujeto
Verbo
Sujeto
Sujeto
Verbo
Verbo
Objeto
Objeto
Estado
Estado
Objeto
Objeto
Objeto
Objeto
Objeto
Estado
Estado
Verbo
Verbo
Verbo
Verbo
Sujeto

Definicin de Smbolos
Smbolo
N: 1
Nombre/s
Nocin

Impacto

Smbolo
N: 2
Nombre/s
Nocin
Impacto

Tipo: Verbo
Anlisis
Es la actividad en la que se obtienen e interpretan los requisitos de un
incremento.
Es llevada a cabo por el analista.
Se elicitan los requisitos del incremento con el cliente.
Se interpretan los requisitos obtenidos.
Se realiza el documento de especificacin de requisitos.
Se validan los requisitos elicitados con cliente.
Tipo: Sujeto
Analista
Es el encargado de realizar el anlisis de los requisitos que
corresponden a un incremento.
Define cuales son las necesidades del cliente.
Se encarga de elicitar requisitos con el cliente.
Realiza el anlisis de los requisitos de cada incremento.
Se encarga de realizar el documento de especificacin de requisitos.

Smbolo
N: 3
Nombre/s
Nocin

Impacto

Smbolo
N: 4
Nombre/s
Nocin
Impacto

Smbolo
N: 5
Nombre/s
Nocin
Impacto

Smbolo
N: 6
Nombre/s
Nocin

Impacto

Tipo: Verbo
Codificacin
Es la actividad en la que se elabora la funcionalidad de un incremento.
Es realizada por el desarrollador.
Sucede luego de la actividad de anlisis.
Se desarrolla en base a los requisitos registrados en el documento de
especificacin de requisitos que corresponden a un incremento.
Agrega funcionalidad al producto.
Tipo: Sujeto
Desarrollador
Es el encargado de realizar la codificacin que corresponde a un
incremento.
Toma los requisitos del documento de especificacin de requisitos que
corresponden al incremento que se est elaborando.
Revisa el documento de especificacin de requisitos.
Revisa el documento de modelo de diseo.
Realiza la codificacin correspondiente a los requisitos de un incremento
teniendo en cuenta el modelo de diseo detallado.
Tipo: Sujeto
Diseador
Es el encargado de realizar el modelo de diseo.
Es el encargado de realizar el modelo de arquitectura de software.
Define el modelo de diseo en base al documento de especificacin de
requisitos.
Define el modelo de arquitectura del software en base al documento de
especificacin de requisitos.
Toma los requisitos que corresponden al incremento que se est
elaborando.
Revisa el documento de especificacin de requisitos.
Se encarga de llevar a cabo la actividad de diseo.
Tipo: Verbo
Diseo
Es la actividad que permite llevar a cabo el modelo de diseo de un
incremento.
Es la actividad que permite llevar a cabo el modelo de arquitectura de
software de un incremento.
Es realizada por el diseador.
Sucede luego de la actividad de anlisis.
Se revisan los requisitos del incremento que se encuentran en el
documento de especificacin de requisitos.
Se determina la estructura requerida para el incremento, la cual es
realizada con el modelo de arquitectura de software.
Se detallan los componentes que se van utilizar para el incremento, los
cuales se realizan con el modelo de arquitectura de software.

Smbolo
N: 7
Nombre/s
Nocin
Impacto

Smbolo
N: 8
Nombre/s
Nocin

Impacto

Smbolo
N: 9
Nombre/s
Nocin

Impacto

Smbolo
N: 10
Nombre/s
Nocin
Impacto

Se definen los diagramas a utilizar para el modelo de diseo del

incremento.
Tipo: Verbo

Entregar el incremento
Es la actividad que corresponde a la entrega del producto al cliente de la
funcionalidad solicitada.
Se realiza la instalacin del incremento en el cliente.
Se realiza la prueba de aceptacin con el cliente.
Se verifica que los requisitos del documento de especificacin de
requisitos coincidan con el incremento entregado.
El incremento es utilizado por el cliente.
Tipo: Objeto
Especificacin de requisitos
Es un documento que se confecciona durante la actividad de anlisis.
Es toda la informacin necesaria para comprender la necesidad del
cliente.
Es confeccionado por el analista.
Contiene los requisitos del sistema que surgen en cada incremento.
El primer documento generado da origen al ncleo.
Es utilizado por el desarrollador para la codificacin.
Es utilizado por el diseador para realizar el modelo de diseo.
Es utilizado por el diseador para realizar el modelo de arquitectura de
software.
Tipo: Objeto
Incremento
Es una porcin del software que cumple con un conjunto de
funcionalidades requeridas por el cliente.
Toda la documentacin relevante del incremento y que es proporcionada
por el cliente se vuelca en el plan de incremento.
Cada incremento pasa por las siguientes actividades: anlisis, diseo,
codificacin y prueba.
Es aceptado o rechazado en base a los resultados de la prueba de
aceptacin.
Cumple con un conjunto de requisitos solicitados por el cliente y que se
encuentran documentados en la especificacin de requisitos.
Tipo: Estado
Incremento rechazado
Indica que un incremento no representa lo esperado por el cliente.
Se determina luego de realizar las pruebas de aceptacin con el cliente.
Se deben redefinir los requisitos que no fueron bien interpretados hasta
que el incremento pase a ser un incremento validado.
Se vuelven a realizar las actividades de anlisis y codificacin.

Smbolo
N:11
Nombre/s
Nocin
Impacto

Tipo: Estado
Incremento validado
Indica que un incremento representa lo esperado por el cliente.
Se determina luego de realizar las pruebas de aceptacin con el cliente.
Se puede proceder a la elaboracin del siguiente incremento.
Si luego surgen nuevos requisitos los mismos se tendrn en cuenta en
futuros incrementos y se deber armar un nuevo plan de incremento.

Smbolo
N: 12
Nombre/s
Nocin

Tipo: Objeto
Modelo de arquitectura del software
Es un documento donde se indica la estructura e interaccin entre las
partes que componen el producto software.
Es realizada por el diseador.
Se realiza durante la actividad de diseo.
Se utiliza para elaborar la estructura general de la implementacin del
producto.
Define la relacin entre los elementos estructurales del producto
software.
Es utilizado para la actividad de codificacin.

Impacto

Smbolo
N: 13
Nombre/s
Nocin
Impacto

Smbolo
N: 14
Nombre/s
Nocin

Impacto

Tipo: Objeto
Modelo de diseo
Es la representacin de la solucin en el desarrollo del producto.
Es creado por el diseador.
Se realiza durante la actividad de diseo.
Define las funcionalidades, los componentes y las interfaces que
forman parte del producto.
Es utilizado para la actividad de codificacin.
Tipo: Objeto
Ncleo
Es el primer incremento entregado.
Es la base para futuros incrementos.
Contiene las principales funcionalidades del sistema.
Genera una versin estable del producto.
Genera un producto completo.
Es determinado por el cliente luego de que ste haya seleccionado
cuales requisitos de la especificacin de requisitos formarn parte del
primer incremento.

Smbolo N:
15
Nombre/s
Nocin

Tipo: Objeto
Plan de incremento
Documento que contiene toda la informacin del incremento a
elaborar.


Impacto

Smbolo
N:16
Nombre/s
Nocin

Impacto

Smbolo
N:17
Nombre/s
Nocin
Impacto

Smbolo
N:18
Nombre/s
Nocin

Impacto

Smbolo
N:19
Nombre/s
Nocin

Impacto

Contiene las funcionalidades, fechas y responsables a incluir en el

incremento.
Se utiliza para organizar el prximo incremento a elaborar.
Lo lleva a cabo el analista.
Se elabora en conjunto con el cliente.
Tipo: Objeto

Producto
Es el software construido por el desarrollador.
Es la documentacin que acompaa al software.
Son los datos que configuran el software.
Es lo que se entrega al finalizar un incremento.
Se lo puede modificar en cualquiera de las fases del proceso de
software.
Su creacin comienza desde la actividad de anlisis.
Si las pruebas de aceptacin con el cliente son exitosas se lo considera
producto completo.
Si las pruebas de aceptacin con el cliente no son exitosas se lo
considera producto incompleto.
Tipo: Estado
Producto completo
Sucede luego de que el producto cumple
establecidos por el cliente.
El producto puede ser entregado al cliente.
El producto es utilizado por el cliente.

con

los

requisitos

Tipo: Estado
Producto incompleto
Sucede luego de que el producto no cumple con los requisitos
establecidos por el cliente.
Indica que el producto no se encuentra apto para ser entregado.
El producto no puede ser entregado al cliente.
El producto se debe corregir para poder concluir el incremento.
Una vez corregido, probado y aceptado por el cliente mediante las
pruebas de aceptacin, pasa a ser un producto completo y el incremento
pasa a ser un incremento validado.
Tipo: Verbo
Prueba
Es la actividad que permite evaluar el funcionamiento del producto.
Sucede luego de la actividad de codificacin.
Es realizada por el desarrollador.
Es realizada por el tester.
Es realizada por el cliente.
El desarrollador puede llevar a cabo una prueba unitaria del

Smbolo
N:20
Nombre/s
Nocin

Impacto

Smbolo
N:21
Nombre/s
Nocin

producto.
El tester puede llevar a cabo una prueba de integracin del producto.
El cliente puede llevar a cabo una prueba de aceptacin del
producto.
Tipo: Verbo

Prueba de aceptacin
Sucede al momento de hacer la entrega del incremento al cliente.
Permite validar si el producto cumple con el funcionamiento esperado
por el cliente.
Es realizada por el cliente.
Identificar errores en el producto.
Utiliza diversos juegos de datos para llevar a cabo el ensayo.
Si el producto cumple con todos los requisitos esperados por el cliente,
entonces el incremento pasa a ser un incremento validado.
Si el producto no cumple con todos los requisitos esperados por el
cliente, entonces el incremento pasa a ser un incremento rechazado.
Tipo: Verbo

Prueba de integracin
Sucede durante la actividad de codificacin.
Se lleva a cabo sobre el producto a entregar teniendo en cuenta que la
nueva funcionalidad se integre con lo que actualmente se encuentra
funcionando.
Es realizada por el tester.
Impacto
Identificar errores en el producto.
Utiliza diversos juegos de datos para llevar a cabo el ensayo.
Los errores detectados son reportados al desarrollador para su
correccin.
Smbolo N:22
Tipo: Verbo
Nombre/s
Prueba unitaria
Nocin
Sucede durante la actividad de codificacin.
Se lleva a cabo sobre el producto a entregar teniendo en
cuenta solamente la funcionalidad que se agrega.
Es la actividad realizada por el desarrollador.
Impacto
Identifica errores en el producto.
Utiliza diversos juegos de datos para llevar a cabo el ensayo.
El desarrollador se encarga de corregir los errores detectados.
Smbolo N:23
Tipo: Sujeto
Nombre/s
Tester
Nocin
Es el encargado de realizar las pruebas de integracin del
producto.
Impacto
Asegura que la funcionalidad que est probando se integre
correctamente con el resto del producto.
Realiza la documentacin de las pruebas de integracin.
Informa los errores detectados para luego ser corregidos por
el desarrollador.
Verifica las correcciones realizadas al producto por el
desarrollador.

UML DIAGRAMAS CUANDO SE APLICA EN LINK JAJAJAJ

https://msdn.microsoft.com/es-MX/library/dd409432.aspx