MODELOS DE DESARROLLO DE SOFTWARE

Para desarrollar un software es importante seguir las siguientes etapas:

1. FUNDAMENTOS DE REQUERIMIENTOS DE ANLISIS
Es el conjunto de tcnicas y procedimientos que nos sirve para conocer los elementos necesarios de proyecto de software,
segn la IEEE sta etapa es la ms importante y se divide en dos:
FUNCIONALES: Son los requerimientos que hace el usuario, el software debe lograr un objetivo.
NO FUNCIONALES: Condicin que se establece en algn documento, el sistema debe cumplir con dichas condiciones.
sta es una etapa muy importante ya que es aqu donde se especifica bien lo que el usuario quiere y es en base a sta
etapa que se desarrollar el software, si el anlisis de requerimientos est mal elaborado entonces todo el proyecto
fracasar, sta labor parece muy sencilla pero no lo es ya que en la formulacin abundan los cambios por mala
interpretacin
2. ANLISIS DE REQUERIMIENTOS
El anlisis de requerimientos dar una clara idea al Ingeniero de sistemas de que es lo que se espera del sistemas, con un
buen anlisis de requerimientos se podr saber todas las caractersticas del sistema, en el grfico muestra la importancia de
sta etapa.

1. TAREAS DEL ANLISIS

Se divide en 4 etapas:
Reconocimiento del problema.
Evaluacin y sntesis.
Especificacin.
Revisin.
El especialista en un inicio debe reconocer el problema luego hacer una evaluacin y desglose del problema para entenderlo
mejor, luego hacer una especificacin del problema identificar lo que realmente se quiere de nuestro sistema y como ltimo
hacer una revisin de todo lo que se ha hecho y verificar que todo est correcto

En la figura se muestra el rol del analista.

4. PRINCIPIOS DEL ANLISIS
Podemos identificar los siguientes principios:
El dominio de la informacin as como el dominio funcional de un problema debe ser representado y comprendido.
El problema debe subdividirse de forma que se descubran los detalles de una manera progresiva.
Deben desarrollarse las representaciones lgicas y fsicas del sistema.
Con estos principios el analista examina el dominio de la informacin de modo que pueda comprenderse su funcin ms
completamente.
5. EL DOMINIO DE LA INFORMACIN
Cuando se construye un software, piensa en que se ingresarn datos, luego estos datos se procesarn y finalmente se
obtendr un dato de salida.
El dominio de la informacin contiene tres visiones diferentes.
El flujo de la informacin.
El contenido de la informacin.
La estructura de la informacin.

El concepto de dominio de la informacin podemos entenderlo mejor en el siguiente grfico

6. PARTICIN
Normalmente los problemas que se quieren resolver mediante el software es muy grande y es por ello que debemos
particionar en partes pequeas y de sta manera sea ms fcil comprender el problema, se debe establecer cmo es que se
relacionan estas pequeas partes.

7. VISIONES LGICAS Y FSICAS

Las visiones lgicas representan las funciones que ha de realizar el software y el tipo de datos con el que se va a trabajar, y
las visiones fsicas trata sobre cmo se concibe el mundo real se podra decir trata de la fase de diseo.
8. CONSTRUCCIN DE PROTOTIPOS DEL SOFTWARE
Trata de hacer una recoleccin de requerimientos, aplicar los principios de diseo y entender las apreciaciones del cliente
para construir un modelo del software.
9. UN ESCENARIO PARA LA CONSTRUCCIN DE PROTOTIPOS
Para desarrollar el software debemos analizar bien el problema, ya que el cliente es una memoria que explica un problema,
o quizs un informe defina los objetivos y requerimientos del sistema es por ello que se debe seguir la siguiente secuencia:

Se debe analizar si el prototipo a desarrollar cumple con los requerimientos y objetivos que se pide, todo esto con el
visto bueno del cliente.

Dado un prototipo aceptable el analista debe hacer una representacin abreviada de sistema.
El software prototipo se prueba y refina, normalmente ello se hace con una hoja y papel definiendo la interaccin que
existir hoja-mquina.

La prueba del prototipo debe ser realizado por el cliente, para mejorar, quitar o aumentar algunos aspectos del
sistema.

10. ESPECIFICACIN
La especificacin tiene mucho que ver con la calidad de solucin ya que de ello depende como trabajar el sistema, que
requerimientos y objetivos realizar; la especificacin es muy importante ya que de ello depende el xito del proyecto.
11. PRINCIPIOS DE ESPECIFICACIN
Baltzer y Goldman proponen los siguientes principios para una buena especificacin:

En funcin una especificacin es una descripcin de lo que se realiza en ves de cmo se implementa.

El problemas puede ser dividido en partes tal que estas partes se relaciones y trabajen colectivamente, es por ello
que nuestro sistema tambin debe estar compuesto por elementos que estn relacionados.

La especificacin del sistema se debe realizar desde el punto de vista del grupo de usuarios que manipularn el
sistema.

La especificacin debe ser operacional, se refiere a que debe ser completa y cumplir con el conjunto de
requerimientos y objetivos.

Nuestra especificacin debe estar aumenta a cambios y aumentos que se puedan realizar de acuerdo al avance.

12. MTODOS DE ANLISIS ORIENTADOS AL FLUJO DE DATOS

Al sistema ingresan datos, los cuales mediantes procesos se transforman e interactan con otros datos que tenemos
almacenados y el resultado es otro dato, todo este proceso debe estar bien establecido.

13 DIAGRAMAS DE FLUJO DE DATOS

Es una tcnica que consiste en la grfica del proceso de los datos conforme se stos datos ingresan al sistema, se procesan
y sales del sistema.

ESARROLLO EN CASCADA
Este tipo de desarrollo lleva ese nombre debido a la similitud que tiene su esquematizacin
con una cascada y es que es de la siguiente forma.

Ingeniera y Anlisis del Sistema

Anlisis de los Requisitos
Diseo
Codificacin
Prueba
Mantenimiento

INGENIERA Y ANLISIS DEL SISTEMA

Se comienza estableciendo los requisitos de todos los elementos del sistema e
identificando a que elemento del software pertenece el requisito.
ANLISIS DE LOS REQUISITOS DEL SOFTWARE
El analista debe comprender el mbito del software el proceso de los datos, el rendimiento
y las interfaces requeridas.
DISEO

El diseo del software se enfoca en cuatro atributos distintos del programa: la estructura de
los datos, la arquitectura del software, el detalle procedimental y la caracterizacin de la
interfaz.
CODIFICACIN
Una ves diseado el software en todos los aspectos mencionados se debe pasar a traducir
este diseo a lenguaje mquina, sta tarea ser ms fcil de realizar si se hizo un buen
diseo.

PRUEBA
Es recomendable que sta etapa la realice el usuario ya que ste debe constatar si al
ingresar los datos establecidos al sistema, ste arroja el resultado esperado.
MANTENIMIENTO
Una ves entregado el sistema al cliente, el sistema sufrir pequeos cambios por peticin
del cliente como puede ser agregar pequeos mdulos, optimizar y obtener ms
rendimiento, etc.
VENTAJAS
Se tiene todo bien organizado y no se mezclan las fases.
Es perfecto para proyectos que son rgidos, y adems donde se especifiquen muy bien
los requerimientos y se conozca muy bien la herramienta a utilizar.
DESVENTAJAS
Un proyecto rara vez sigue una secuencia lineal, esto crea una mala implementacin
del modelo, lo cual hace que lo lleve al fracaso.
El proceso de creacin del software tarda mucho tiempo ya que debe pasar por el
proceso de prueba y hasta que el software no est completo no se opera

DESARROLLO EN ESPIRAL
ste es un tipo de desarrollo evolutivo, las versiones de cada etapa van evolucionando, madurando de acuerdo a cada
iteracin que se haga cabe recalcar que en cada iteracin se desarrollar todas las etapas en orden.
CARACTERSTICAS:
Es ideal para crear productos con diferentes versiones mejoradas como se hace con el software moderno de
microcomputadoras.
puede desarrollarse a travs del ciclo de vida clsico o el de construccin de prototipos.

COMUNICACIN CON EL CLIENTE:

Aqu establecemos los requerimientos y objetivos que se quieren del sistema.
PLANIFICACIN
Seguidamente debemos estructurar nuestro trabajo, planificar tiempo, establecer metas, etc.
ANLISIS DE RIESGOS

Se debe identificar los riesgos relacionados con el proyecto, todas aquellas eventualidades que pueden ocurrir, y tratar de
que estos riesgos no se den o en el caso de que lleguen a pasar establecer acciones para resolverlas.
INGENIERA
Las tarea necesarias para construir la aplicacin (la representacin del sistema y debidamente estructurada).
CONSTRUCCIN Y ADAPTACIN
Luego se debe construir el software, realizar las pruebas correspondientes y brindar soporte al usuario.
EVALUACIN DEL CLIENTE
El cliente es quien debe dar la conformidad del avance y si el resultado del trabajo cumple con las expectativas del usuario.
VENTAJAS
A medida que progresa el proceso, el desarrollador y el cliente comprenden y reaccionan mejor ante riesgos en cada uno de
los niveles.
Reduce los riesgos antes de que se conviertan en problemticos.

MODELO DE DESARROLLO DE SOFTWARE INCREMENTAL

Es un proceso de desarrollo de software, creado en respuesta a las debilidades del modelo tradicional de cascada. La idea
principal detrs de mejoramiento iterativo es desarrollar un sistema de programas de manera incremental, permitindole al
desarrollador sacar ventaja de lo que se ha aprendido a lo largo del desarrollo anterior, incrementando versiones de
entregables del sistema. El aprendizaje viene de dos vertientes: el desarrollo del sistema, y su uso (mientras sea posible).
Los pasos claves en el proceso son comenzar con una implementacin simple de los requerimientos del sistema, e
iterativamente mejorar la secuencia evolutiva de versiones hasta que el sistema completo est implementado. En cada
iteracin, se realizan cambios en el diseo y se agregan nuevas funcionalidades y capacidades al sistema.
El proceso en s mismo consta de:

Etapa de inicializacin

Etapa de iteracin

Lista de control de proyecto

Etapa de inicializacin
Se crea una versin del sistema. La meta de esta etapa es crear un producto con el que el usuario pueda interactuar, y por
ende retroalimentar el proceso. Debe ofrecer una muestra de los aspectos claves del problema y proveer una solucin lo
suficientemente simple para ser comprendida e implementada fcilmente.
Lista de control de proyecto
Para guiar el proceso de iteracin, se crea una Lista de Control de Proyecto, esta lista contiene un historial de todas las
tareas que necesitan ser realizadas. Incluye cosas como nuevas funcionalidades para ser implementadas, y reas de
rediseo de la solucin ya existente. Esta lista de control se revisa peridica y constantemente como resultado de la fase de
anlisis.

Etapa de iteracin
Esta etapa involucra el rediseo e implementacin de una tarea de la lista de control de proyecto, y el anlisis de la versin
ms reciente del sistema. La meta del diseo e implementacin de cualquier iteracin es ser simple, directa y modular, para
poder soportar el rediseo de la etapa o como una tarea aadida a la lista de control de proyecto. El cdigo puede en ciertos
casos, representar la mayor fuente de documentacin del sistema. El anlisis de una iteracin se basa en la
retroalimentacin del usuario y en el anlisis de las funcionalidades disponibles del programa. Involucra el anlisis de la
estructura, modularidad, usabilidad, confiabilidad, eficiencia y eficacia (alcanzar las metas). La lista de control del proyecto
se modifica bajo la luz de los resultados del anlisis.

Las guas primarias que guan la implementacin y el anlisis incluyen:

Cualquier dificultad en el diseo, codificacin y prueba de una modificacin debera apuntar a la necesidad de
redisear o recodificar.

Las modificaciones deben ajustarse fcilmente a los mdulos fciles de encontrar y a los aislados. Si no es as,
entonces se requiere algn grado de rediseo.

Las modificaciones a las tablas deben ser especialmente fciles de realizar. Si dicha modificacin no ocurre
rpidamente, se debe aplicar algo de rediseo.

Las modificaciones deben ser ms fciles de hacer conforme avanzan las iteraciones. Si no es as, hay un problema
primordial usualmente encontrado en un diseo dbil o en la proliferacin excesiva de parches al sistema.

Los parches normalmente deben permanecer solo por una o dos iteraciones. Se hacen necesarios para evitar el
rediseo durante una fase de implementacin.

La implementacin existente debe ser analizada frecuentemente para determinar que tan bien se ajusta a las metas
del proyecto.

Las facilidades para analizar el programa deben ser utilizadas cada vez para ayudar en el anlisis de
implementaciones parciales.

La opinin del usuario debe ser solicitada y analizada para indicar deficiencias en la implementacin referida por l.

Caractersticas
Usando anlisis y mediciones como guas para el proceso de mejora es una diferencia mayor entre las mejoras iterativas y el
desarrollo rpido de aplicaciones, principalmente por dos razones:

Provee de soporte para determinar la efectividad de los procesos y de la calidad del producto.

Permite estudiar, despus mejorar y ajustar el proceso para el ambiente en particular.

Estas mediciones y actividades de anlisis pueden ser aadidas a los mtodos de desarrollo rpido existentes.
De hecho, el contexto de iteraciones mltiples conlleva ventajas en el uso de mediciones. Las medidas a veces son difciles
de comprender en su totalidad, aunque en los cambios relativos en las medidas a travs de la evolucin del sistema puede
ser muy informativo porque proveen una base de comparacin. Por ejemplo, un vector de medidas m1, m2,..., mn puede ser
definido para caracterizar varios aspectos del producto en cierto punto, como pueden ser el esfuerzo total realizado, los
cambios, los defectos, los atributos lgico, fsico y dinmico, consideraciones del entorno, etc., as el observador puede decir
como las caractersticas del producto como el tamao, la complejidad, el acoplamiento y la cohesin incrementan o
disminuyen en el tiempo. Tambin puede monitorearse el cambio relativo de varios aspectos de un producto o pueden
proveer los lmites de las medidas para apuntar a problemas potenciales y anomalas.

VENTAJAS

Entre las ventajas del modelo incremental se encuentran:

Los clientes no esperan hasta el fin del desarrollo para utilizar el sistema. Pueden empezar a usarlo desde
el primer incremento.

Los clientes pueden aclarar los requisitos que no tengan claros conforme ven las entregas del sistema.

Se disminuye el riesgo de fracaso de todo el proyecto, ya que se puede distribuir en cada incremento.

Las partes ms importantes del sistema son entregadas primero, por lo cual se realizan ms pruebas en
estos mdulos y se disminuye el riesgo de fallos.
DESVENTAJAS
Algunas de las desventajas identificadas para este modelo son:

Debido a la interaccin con los usuarios finales, cuando sea necesaria la retroalimentacin hacia el grupo de
desarrollo, utilizar este modelo de desarrollo puede llevar a avances extremadamente lentos.

Por la misma razn no es una aplicacin ideal para desarrollos en los que de antemano se sabe que sern grandes
en el consumo de recursos y largos en el tiempo.

Cada incremento debe ser pequeo para limitar el riesgo.

Cada incremento debe aumentar la funcionalidad.

Es difcil establecer las correspondencias de los requisitos contra los incrementos.

Es difcil detectar las unidades o servicios genricos para todo el sistema.

Al requerir constantemente la ayuda de los usuarios finales, se agrega un costo extra a la compaa, pues mientras
estos usuarios evalan el software dejan de ser directamente productivos para la compaa.

Modelo de desarrollo iterativo incremental

Para apoyar el desarrollo de proyectos por medio de este modelo se han creado frameworks, de los cuales los dos ms
famosos son el Rational Unified Process RUP y el Dynamic Systems Development Method. El desarrollo incremental e
iterativo es tambin una parte esencial de un tipo de programacin conocido como Extreme Programming XP y los dems
frameworks de desarrollo rpido de software.

METODOLOGAS PARA DESARROLLO DE SOFTWARE

Un proceso de software detallados y completo suele denominarse Metodologa. Las metodologas se
basan en una combinacin de los modelos de proceso genricos (cascada, evolutivo, incremental,
espiral entre otros). Adicionalmente una metodologa debera definir con precisin los artefactos, roles y
actividades involucrados, junto con prcticas y tcnicas recomendadas, guas de adaptacin de la
metodologa al proyecto, guas para uso de herramientas de apoyo, etc. Habitualmente se utiliza el
trmino mtodo para referirse a tcnicas, notaciones y guas asociadas, que son aplicables a una (o
algunas) actividades del proceso de desarrollo, por ejemplo, suele hablarse de mtodos de anlisis y/o
diseo.
La comparacin y/o clasificacin de metodologas no es una tarea sencilla debido a la diversidad de
propuestas y diferencias en el grado de detalle, informacin disponible y alcance de cada una de ellas.
A grandes rasgos, si tomamos como criterio las notaciones utilizadas para especificar artefactos
producidos en actividades de anlisis y diseo, podemos clasificar las metodologas en dos grupos:
Metodologas Estructuradas y Metodologas Orientadas a Objetos. Por otra parte, considerando su
filosofa de desarrollo, aquellas metodologas con mayor nfasis en la planificacin y control del
proyecto, en especificacin precisa de requisitos y modelado, reciben el apelativo de Metodologas
Tradicionales (o tambin denominadas Metodologas Pesadas, o Peso Pesado). Otras metodologas,
denominadas Metodologas giles, estn ms orientadas a la generacin de cdigo con ciclos muy
cortos de desarrollo, se dirigen a equipos de desarrollo pequeos, hacen especial hincapi en aspectos
humanos asociados al trabajo en equipo e involucran activamente al cliente en el proceso .
A continuacin se revisan brevemente cada una de estas categoras de metodologas:

METODOLOGAS ESTRUCTURADAS
Los mtodos estructurados comenzaron a desarrollarse a fines de los 70s con la Programacin
Estructurada, luego a mediados de los 70s aparecieron tcnicas para el Diseo (por ejemplo: el
diagrama de Estructura) primero y posteriormente para el Anlisis (por ejemplo: Diagramas de Flujo de
Datos). Estas metodologas son particularmente apropiadas en proyectos que utilizan para la
implementacin lenguajes de 3ra y 4ta generacin.
Ejemplos de metodologas estructuradas de mbito gubernamental: MERISE (Francia), MTRICA
(Espaa), SSADM (Reino Unido). Ejemplos de propuestas de mtodos estructurados en el mbito
acadmico: Gane & Sarson, Ward & Mellor, Yourdon & DeMarco e Information Engineering.

METODOLOGAS ORIENTADAS A OBJETOS

Su historia va unida a la evolucin de los lenguajes de programacin orientada a objeto, los ms

representativos: a fines de los 60s SIMULA, a fines de los 70s Smalltalk-80, la primera versin de C++
por Bjarne Stroustrup en 1981 y actualmente Java o C# de Microsoft. A fines de los 80s comenzaron a
consolidarse algunos mtodos Orientadas a Objeto.
En 1995 Booch y Rumbaugh proponen el Mtodo Unificado con la ambiciosa idea de conseguir una
unificacin de sus mtodos y notaciones, que posteriormente se reorienta a un objetivo ms modesto,
para dar lugar al Unified Modeling Language (UML), la notacin Orientada a Objetos ms popular en la
actualidad.
Algunas metodologas orientadas a objetos que utilizan la notacin UML son:
Rational Unified Process (RUP),

OPEN,
MTRICA (que tambin soporta la notacin estructurada).

METODOLOGAS TRADICIONALES
Las metodologas no giles son aquellas que estn guiadas por una fuerte planificacin durante
todo el proceso de desarrollo; llamadas tambin metodologas tradicionales o clsicas, donde se
realiza una intensa etapa de anlisis y diseo antes de la construccin del sistema.
Todas las propuestas metodolgicas antes indicadas pueden considerarse como metodologas
tradicionales. Aunque en el caso particular de RUP, por el especial nfasis que presenta en
cuanto a su adaptacin a las condiciones del proyecto (mediante su configuracin previa a
aplicarse), realizando una configuracin adecuada, podra considerarse gil.

METODOLOGAS GILES
Un proceso es gil cuando el desarrollo de software es incremental (entregas pequeas de
software, con ciclos rpidos), cooperativo (cliente y desarrolladores trabajan juntos
constantemente con una cercana comunicacin), sencillo (el mtodo en s mismo es fcil de
aprender y modificar, bien documentado), y adaptable (permite realizar cambios de ltimo
momento).
Entre las metodologas giles identificadas son:

Extreme Programming

Scrum

Familia de Metodologas Crystal

Feature Driven Development

Proceso Unificado Rational, una configuracin gil

Dynamic Systems Development Method

Adaptive Software Development

Open Source Software Development

SEGUIDAMENTE DETALLAREMOS LAS SIGUIENTES METODOLOGAS PARA DESARROLLO DE
SOFTWARE:

Rational Unified Process (RUP)

Extreme Programming (XP)

SCRUM

METODOLOGA RUP (RATIONAL UNIFIED PROCESS)

Es una metodologa cuyo fin es entregar un producto de software. Se estructura todos los procesos y se mide la eficiencia de
la organizacin.
Es un proceso de desarrollo de software el cual utiliza el lenguaje unificado de modelado UML, constituye la metodologa
estndar ms utilizada para el anlisis, implementacin y documentacin de sistemas orientados a objetos.
El RUP es un conjunto de metodologas adaptables al contexto y necesidades de cada organizacin.
Describe como aplicar enfoques para el desarrollo del software, llevando a cabo unos pasos para su realizacin.
Se centra en la produccin y mantenimiento de modelos del sistema.

Principales caractersticas

Forma disciplinada de asignar tareas y responsabilidades (quin hace qu, cundo y cmo)

Pretende implementar las mejores prcticas en Ingeniera de Software

Desarrollo iterativo

Administracin de requisitos

Uso de arquitectura basada en componentes

Control de cambios

Modelado visual del software

Verificacin de la calidad del software

No es confiable la informacin por que se puede editar. Atte. Rebeca Ramrez Ramos
-ya veo, ummmmmm es verdad

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y
guiado por los casos de uso. Incluye artefactos (que son los productos tangibles del proceso como por ejemplo, el modelo de
casos de uso, el cdigo fuente, etc.) y roles (papel que desempea una persona en un determinado momento, una persona
puede desempear distintos roles a lo largo del proceso).

CICLO DE VIDA

Esfuerzo en actividades segn fase del proyecto

El ciclo de vida RUP es una implementacin del Desarrollo en espiral. Fue creado ensamblando los elementos en
secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.
RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el
proyecto y en las que se hace un mayor o menor hincapi en las distintas actividades.
Fases del ciclo de vida del RUP:
1. Fase de Inicio: Esta fase tiene como propsito definir y acordar el alcance del proyecto con los patrocinadores, identificar
los riesgos asociados al proyecto, proponer una visin muy general de la arquitectura de software y producir el plan de las
fases y el de iteraciones posteriores.
2. Fase de elaboracin: En la fase de elaboracin se seleccionan los casos de uso que permiten definir la arquitectura base
del sistema y se desarrollaran en esta fase, se realiza la especificacin de los casos de uso seleccionados y el primer
anlisis del dominio del problema, se disea la solucin preliminar.
3. Fase de Desarrollo: El propsito de esta fase es completar la funcionalidad del sistema, para ello se deben clarificar los
requerimientos pendientes, administrar los cambios de acuerdo a las evaluaciones realizados por los usuarios y se realizan
las mejoras para el proyecto.
4. Fase de Cierre: El propsito de esta fase es asegurar que el software est disponible para los usuarios finales, ajustar los
errores y defectos encontrados en las pruebas de aceptacin, capacitar a los usuarios y proveer el soporte tcnico
necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el
proyecto.

La metodologa RUP tiene 6 principios clave:

1. Adaptacin del proceso: El proceso debe adaptarse a las caractersticas de la organizacin para la que se est
desarrollando el software.
2. Balancear prioridades: Debe encontrarse un balance que satisfaga a todos los inversores del proyecto.
3. Colaboracin entre equipos: Debe haber una comunicacin fluida para coordinar requerimientos, desarrollo,
evaluaciones, planes, resultados, entre otros.
4. Demostrar valor iterativamente: Los proyectos se entregan, aunque sea de una forma interna, en etapas iteradas. En
cada iteracin se evaluar la calidad y estabilidad del producto y analizar la opinin y sugerencias de los inversores.
5. Elevar el nivel de abstraccin: Motivar el uso de de conceptos reutilizables.
6. Enfocarse en la calidad: La calidad del producto debe verificarse en cada aspecto de la produccin.
Disciplina de desarrollo de RUP
Determina las etapas a realizar durante el proyecto de creacin del software.

Ingeniera o modelado del negocio: Analizar y entender las necesidades del negocio para el cual se est
desarrollando el software.

Requisitos: Proveer una base para estimar los costos y tiempo de desarrollo del sistema.

Anlisis y diseo: Trasladar los requisitos analizados anteriormente a un sistema automatizado y desarrollar una
arquitectura para el sistema.

Implementacin: Crear software que se ajuste a la arquitectura diseada y que tenga el comportamiento deseado.

Pruebas: Asegurarse de que el comportamiento requerido es correcto y que todo lo solicitado est presente.

Despliegue: Producir distribuciones del producto y distribuirlo a los usuarios.

Disciplina de soporte RUP

Determina la documentacin que es necesaria realizar durante el proyecto.

Configuracin y administracin del cambio: Guardar todas las versiones del proyecto.

Administracin del proyecto: Administrar los horarios y recursos que se deben de emplear.

Ambiente: Administrar el ambiente de desarrollo del software.

Distribucin: Hacer todo lo necesario para la salida del proyecto.

Elementos del RUP

Actividades: Procesos que se han de realizar en cada etapa/iteracin.

Trabajadores: Personas involucradas en cada actividad del proyecto.

Artefactos: Herramientas empleadas para el desarrollo del proyecto. Puede ser un documento, un modelo, un
elemento del modelo.

Artefactos
RUP en cada una de sus fases (pertenecientes a la estructura esttica) realiza una serie de artefactos que sirven para
comprender mejor tanto el anlisis como el diseo del sistema (entre otros). Estos artefactos (entre otros) son los siguientes:
Inicio:

Documento Visin

Especificacin de Requerimientos

Elaboracin:

Diagramas de caso de uso

Construccin:

Documento Arquitectura que trabaja con las siguientes vistas:

VISTA LOGICA:

Diagrama de clases

Modelo E-R (Si el sistema as lo requiere)

VISTA DE IMPLEMENTACION:

Diagrama de Secuencia

Diagrama de estados

Diagrama de Colaboracin

VISTA CONCEPTUAL

Modelo de dominio

VISTA FISICA

Mapa de comportamiento a nivel de hardware.

METODOLOGA SCRUM

Scrum es una metodologa gil de desarrollo, aunque surgi como modelo para el desarrollo de
productos tecnolgicos, tambin se emplea en entornos que trabajan con requisitos inestables y
que requieren rapidez y flexibilidad; situaciones frecuentes en el desarrollo de determinados
sistemas de software.

Es una metodologa de desarrollo muy simple, que requiere trabajo duro porque no se
basa en el seguimiento de un plan, sino en la adaptacin continua a las circunstancias
de la evolucin del proyecto.
Scrum es una metodologa gil, y como tal:

Es un modo de desarrollo de carcter adaptable ms que predictivo.

Orientado a las personas ms que a los procesos.

Emplea la estructura de desarrollo gil: incremental basada en iteraciones y revisiones.

Se comienza con la visin general del producto, especificando y dando detalle a las
funcionalidades o partes que tienen mayor prioridad de desarrollo y que pueden llevarse a cabo
en un periodo de tiempo breve (normalmente de 30 das).

Cada uno de estos periodos de desarrollo es una iteracin que finaliza con la produccin de un
incremento operativo del producto.
Estas iteraciones son la base del desarrollo gil, y Scrum gestiona su evolucin a travs de
reuniones breves diarias en las que todo el equipo revisa el trabajo realizado el da anterior y el
previsto para el da siguiente.

Estructura central de Scrum

Caractersticas

Equipos autodirigidos
Utiliza reglas para crear un entorno gil de administracin de proyectos
No prescribe prcticas especficas de ingeniera
Los requerimientos se capturan como tems de la lista Product Backlog.
El producto se construye en una serie de Sprints de un mes de duracin.

Herramientas y Prcticas
Scrum no requiere ni provee prcticas de Ingeniera. En lugar de eso, especifica prcticas y
herramientas de gerencia que se aplican en sus distintas fases para evitar el caos originado
por la complejidad e imposibilidad de realizar predicciones.
Product Backlog List
Es una lista priorizada que define el trabajo que se va a realizar en el proyecto. Cuando un
proyecto comienza es muy difcil tener claro todos los requerimientos sobre el producto. Sin
embargo, suelen surgir los ms importantes que casi siempre son ms que suficientes para
un Sprint.
El objetivo es asegurar que el producto definido al terminar la lista es el ms correcto, til y
competitivo posible y para esto la lista debe acompaar los cambios en el entorno y el
producto.
Existe un rol asociado con esta lista y es el de Product Owner. Si alguien quiere realizar
cualquier modificacin sobre la lista por ejemplo: agregar o incrementar la prioridad de sus
elementos tiene que convencer al Product Owner.
Sprints
Un Sprint es el procedimiento de adaptacin de las cambiantes variables del entorno
(requerimientos, tiempo, recursos, conocimiento, tecnologa). Son ciclos iterativos en los
cuales se desarrolla o mejora una funcionalidad para producir nuevos incrementos. Durante
un Sprint el producto es diseado, codificado y probado. Y su arquitectura y diseo
evolucionan durante el desarrollo.
El objetivo de un Sprint debe ser expresado en pocas palabras para que sea fcil de recordar
y est siempre presente en el equipo.
Burn down Chart
La burn down chart es una grfica mostrada pblicamente que mide la cantidad de requisitos en
el Backlog del proyecto pendientes al comienzo de cada Sprint. Dibujando una lnea que conecte
los puntos de todos los Sprints completados, podremos ver el progreso del proyecto. Lo normal
es que esta lnea sea descendente (en casos en que todo va bien en el sentido de que los
requisitos estn bien definidos desde el principio y no varan nunca) hasta llegar al eje
horizontal, momento en el cual el proyecto se ha terminado (no hay ms requisitos pendientes
de ser completados en el Backlog). Si durante el proceso se aaden nuevos requisitos la recta
tendr pendiente ascendente en determinados segmentos, y si se modifican algunos requisitos
la pendiente variar o incluso valdr cero en algunos tramos.
Sprint Backlog
Es el punto de entrada de cada Sprint. Es una lista que tiene los tems de la Product Backlog
List que van a ser implementados en el siguiente Sprint.
Los tems son seleccionados por el Scrum Team, el Scrum Master y el Product Owner en la
Sprint Planning Meeting a partir de la priorizacin de los tems y los objetivos que se
marcaron para ese Sprint. A partir de los objetivos a cumplir durante el Sprint el Scrum Team
determina que tareas debe desempear para cumplir el objetivo. De esto surge el Sprint
Backlog.
Stabilization Sprints

En estos Sprints el equipo se concentra en encontrar defectos, no en agregar funcionalidad.

Suelen aplicarse cuando se prepara un producto para el release. Son tiles cuando se estn
realizando pruebas beta, se est introduciendo a un equipo en la metodologa de Scrum o
cuando la calidad de un producto no alcanza los lmites esperados.
No fueron definidos por Scrum pero han sido recomendados por su utilidad al aplicar esta
metodologa.
Scrum of Scrums o MetaScrum
Los equipos de Scrum suelen tener entre 5 y 10 personas, sin embargo est metodologa ha
sido aplicada en proyectos que involucran ms de 600 personas. Esto ha sido llevado a cabo
dividiendo a los accionistas en equipos de pequeos de hasta 10 personas
aproximadamente. Y definiendo jerrquicamente personas que pertenecen a dos equipos, es
decir, adems de su rol especfico dentro de un equipo tienen el rol de enlace en un equipo
superior.
Roles y responsabilidades
Scrum clasifica a todas las personas que intervienen o tienen inters en el desarrollo del
proyecto en: propietario del producto, equipo, gestor de Scrum (tambin Scrum Manager o
Scrum Master) y otros interesados.
Los tres primeros grupos (propietario, equipo y gestor) son los responsables del proyecto,
los que segn la comparacin siguiente (y sin connotaciones peyorativas) seran los
cerdos; mientras que el resto de interesados seran las gallinas.
Cerdos y gallinas.
Esta metfora ilustra de forma muy grfica la diferencia de implicacin en el proyecto entre
ambos grupos:
Una gallina y un cerdo paseaban por la carretera.
La gallina dijo al cerdo: Quieres abrir un restaurante conmigo.
El cerdo consider la propuesta y respondi: S, me gustara. Y cmo lo llamaramos?.
La gallina respondi: Huevos con jamn.
El cerdo se detuvo, hizo una pausa y contest:
Pensndolo mejor, creo que no voy a abrir un restaurante contigo. Yo estara realmente
comprometido, mientras que t estaras slo implicada.
Roles Cerdo
Los Cerdos son los que estn comprometidos con el proyecto y el proceso Scrum; ellos son
los que "ponen el jamn en el plato".
Product Owner
El Product Owner representa la voz del cliente. Se asegura de que el equipo Scrum trabaja
de forma adecuada desde la perspectiva del negocio. El Product Owner escribe historias de
usuario, las prioriza, y las coloca en el Product Backlog.
ScrumMaster (o Facilitador)
El Scrum es facilitado por un ScrumMaster, cuyo trabajo primario es eliminar los obstculos
que impiden que el equipo alcance el objetivo del sprint. El ScrumMaster no es el lder del
equipo (porque ellos se auto-organizan), sino que acta como una proteccin entre el equipo
y cualquier influencia que le distraiga. El ScrumMaster se asegura de que el proceso Scrum
se utiliza como es debido. El ScrumMaster es el que hace que las reglas se cumplan.
Equipo

El equipo tiene la responsabilidad de entregar el producto. Un pequeo equipo de 5 a 9

personas con las habilidades transversales necesarias para realizar el trabajo (diseador,
desarrollador, etc).
Roles "Gallina"

Los roles gallina en realidad no son parte del proceso Scrum, pero deben tenerse en cuenta.
Un aspecto importante de una aproximacin gil es la prctica de involucrar en el proceso a
los usuarios, expertos del negocio y otros interesados (stakeholders). Es importante que esa
gente participe y entregue retroalimentacin con respecto a la salida del proceso a fin de
revisar y planear cada sprint.
Usuarios
Es el destinatario final del producto. Como bien lo dice la paradoja, El rbol cae en el bosque
cuando no hay nadie Hace ruido? Aqui la definicion sera Si el software no es usado fue
alguna vez escrito?.
Stakeholders (Clientes, Proveedores).
Se refiere a la gente que hace posible el proyecto y para quienes el proyecto producir el
beneficio acordado que lo justifica. Slo participan directamente durante las revisiones del
sprint.
Managers
Es la gente que establece el ambiente para el desarrollo del producto.
Reuniones en Scrum
Daily Scrum

Cada da de un sprint, se realiza la reunin sobre el estado de un proyecto. Esto se llama

"daily standup". El scrum tiene unas guas especficas:

La reunin comienza puntualmente a su hora. A menudo hay castigos -acordados por el equipo- para
quin llega tarde (por ejemplo: dinero, flexiones, llevar colgando una gallina de plstico del cuello, etc)
Todos son bienvenidos, pero solo los "cerdos" pueden hablar.
La reunin tiene una duracin fija de 15 minutos, de forma independiente del tamao del equipo.
Todos los asistentes deben mantenerse de pie (esto ayuda a mantener la reunin corta)
La reunin debe ocurrir en la misma ubicacin y a la misma hora todos los das.

Durante la reunin, cada miembro del equipo contesta a tres preguntas:[]

Qu has hecho desde ayer?

Qu es lo que ests planeando hacer hoy?
Has tenido algn problema que te haya impedido alcanzar tu objetivo? (Es el papel del ScrumMaster
recordar estos impedimentos).

Scrum de Scrum

Cada da normalmente despus del Daily Scrum

Estas reuniones permiten a los grupos de equipos discutir su trabajo, enfocndose especialmente en
reas de solapamiento e integracin.
Asiste una persona asignada por cada equipo.

La agenda ser la misma como del Daily Scrum, adems de las siguientes cuatro preguntas:

Qu ha hecho tu equipo desde nuestra ltima reunin?

Qu har tu equipo antes que nos volvamos a reunir?
Hay algo que demora o estorba a tu equipo?
Ests a punto de poner algo en el camino del otro equipo?

Reunin de Planificacin del Sprint (Sprint Planning Meeting)

Al inicio del ciclo Sprint (cada 15 o 30 das), una Reunin de Planificacin del Sprint se
lleva a cabo.

Seleccionar que trabajo se har

Preparar, con el equipo completo, el Sprint Backlog que detalla el tiempo que tomara hacer el trabajo.
Identificar y comunicar cunto del trabajo es probable que se realice durante el actual Sprint
Ocho horas como limite

Al final del ciclo Sprint, dos reuniones se llevaran a cabo: la Reunin de Revisin del
Sprint y la Retrospectiva del Sprint

Reunin de Revisin del Sprint (Sprint Review Meeting)

Revisar el trabajo que fue completado y no completado
Presentar el trabajo completado a los interesados (alias demo)
El trabajo incompleto no puede ser demostrado
Cuatro horas como lmite
Retrospectiva del Sprint (Sprint Retrospective)

Despus de cada sprint, se lleva a cabo una retrospectiva del sprint, en la cual todos los
miembros del equipo dejan sus impresiones sobre el sprint recin superado. El propsito de
la retrospectiva es realizar una mejora continua del proceso. Esta reunin tiene un tiempo
fijo de cuatro horas.
Visin general del modelo SCRUM

METODOLOGIA XP
3. Entregas pequeas: colocan un sistema sencillo en produccin rpidamente que se actualiza de forma rpida y
constante permitiendo que el verdadero valor de negocio del producto sea evaluado en un ambiente real. Estas entregas no
pueden pasar las 2 o 3 semanas como mximo.
Entendimi
1. Diseo simple: se basa en la filosofa de que el mayor valor de negocio es entregado por el programa ms sencillo que
cumpla los requerimientos. Simple Design se enfoca en proporcionar un sistema que cubra las necesidades inmediatas del
cliente, ni ms ni menos. Este proceso permite eliminar redundancias y rejuvenecer los diseos obsoletos de forma sencilla.
2. Metfora: desarrollada por los programadores al inicio del proyecto, define una historia de cmo funciona el sistema
completo. XP estimula historias, que son breves descripciones de un trabajo de un sistema en lugar de los tradicionales
diagramas y modelos UML (Unified Modeling Language). La metfora expresa la visin evolutiva del proyecto que define el
alcance y propsito del sistema. Las tarjetas CRC (Clase, Responsabilidad y Colaboracin) tambin ayudarn al equipo a
definir actividades durante el diseo del sistema. Cada tarjeta representa una clase en la programacin orientada a objetos y
define sus responsabilidades (lo que ha de hacer) y las colaboraciones con las otras clases (cmo se comunica con ellas).
3. Propiedad colectiva del cdigo: un cdigo con propiedad compartida. Nadie es el propietario de nada, todos son el
propietario de todo. Este mtodo difiere en mucho a los mtodos tradicionales en los que un simple programador posee un
conjunto de cdigo. Los defensores de XP argumentan que mientras haya ms gente trabajando en una pieza, menos
errores aparecern.
4. Estndar de codificacin: define la propiedad del cdigo compartido as como las reglas para escribir y documentar el

cdigo y la comunicacin entre diferentes piezas de cdigo desarrolladas por diferentes equipos. Los programadores las han
de seguir de tal manera que el cdigo en el sistema se vea como si hubiera estado escrito por una sola persona.
Bienestar del programador.
1. La semana de 40 horas: la programacin extrema sostiene que los programadores cansados escriben cdigo de menor
cualidad. Minimizar las horas extras y mantener los programadores frescos, generar cdigo de mayor calidad. Como
dice Beck, est bien trabajar tiempos extra cuando es necesario, pero no se ha de hacer durante dos semanas seguidas.

PROCESO DE DESARROLLO
La programacin extrema parte del caso habitual de una compaa que desarrolla software normalmente a medida, en la
que hay diferentes roles: un equipo de gestin (o diseo), uno de desarrollo y los clientes finales. La relacin entre el equipo
de diseo, los que desarrollan el software y clientes es totalmente diferente al que se ha producido en las metodologas
tradicionales, que se basaba en una fase de captura de los requisitos previa al desarrollo, y de una fase de validacin
posterior al mismo.
1. Interaccin con el cliente.
En este tipo de programacin el cliente pasa a ser parte implicada en el equipo de desarrollo. Su importancia es mxima en
el momento de tratar con los usuarios y en efectuar las reuniones de planificacin. Tiene un papel importante de interaccin
con el equipo de programadores, sobre todo despus de cada cambio, y de cada posible problema localizado, mostrando las
prioridades, expresando sus sensaciones... En este tipo de programacin existirn pruebas de aceptacin de la
programacin que ayudarn a que su labor sea lo ms provechosa posible.
Al fin y al cabo, el cliente se encuentra mucho ms cerca del proceso de desarrollo. Se elimina la fase inicial de recopilacin
de requerimientos, y se permite que stos se vayan cogiendo a lo largo del proyecto, de una manera ordenada. De esta
forma se posibilita que el cliente pueda ir cambiando de opinin sobre la marcha, pero a cambio han de estar siempre
disponibles para solucionar las dudas del equipo de desarrollo.
En XP aparece un nuevo concepto llamado Historia de usuario. Se trata de una lista de caractersticas que el cliente
necesita que existan en el producto final. Estas constan de dos fases:
o En la primera fase, el cliente describe con sus propias palabras las caractersticas y, es el responsable del equipo, el
encargado de informarlo de las dificultades tcnicas de cada una de ellas y de su coste. A consecuencia de este dilogo, el
cliente deja por escrito un conjunto de historias y las ordena en funcin de la prioridad que tienen pera l. De esta manera ya
es posible definir unas fechas aproximadas para ellos.
o En la segunda fase, el cliente coger las primeras historias a implementar y las dividir en trabajos a realizar. El cliente
tambin participa, pero hay ms peso por parte del equipo de desarrolladores, esto dar como resultado una planificacin
ms exacta. Este mtodo se repetir para cada historia.
A diferencia de otras tcnicas, como puede ser UML, en el caso de XP, se exige que sea el cliente el encargado de escribir
los documentos con las especificaciones de lo que realmente quiere, como un documento de requisitos de usuario.
En esta fase, el equipo tcnico ser el 'encargado de catalogar las historias del cliente y asignarles una duracin. La norma
es que cada historia de usuario tiene que poder ser realizable en un espacio entre una y tres semanas de programacin. Las
que requieran menos tiempo sern agrupadas, y las que necesiten ms sern modificadas o divididas.
Finalmente decir que las historias de los usuarios sern escritas en tarjetas, lo que facilitar que el cliente pueda especificar

la importancia relativa entre las diferentes historias de usuario, as como el trabajo de los programadores que podrn
catalogarlas correctamente. Este formato tambin es muy til en el momento de las pruebas de aceptacin.
PLANIFICACIN DEL PROYECTO
En este punto se tendr que elaborar la planificacin por etapas, donde se aplicarn diferentes iteraciones. Para hacerlo
ser necesaria la existencia de reglas que se han de seguir por las partes implicadas en el proyecto para que todas las
partes tengan voz y se sientan realmente partcipes de la decisin tomada.
Las entregas se tienen que hacer cuanto antes mejor, y con cada iteracin, el cliente ha de recibir una nueva versin. Cuanto
ms tiempo se tarde en introducir una parte esencial, menos tiempo se tendr para trabajar con ella despus. Se aconseja
muchas entregas y muy frecuentes. De esta manera un error en la parte inicial del sistema tiene ms posibilidades de
detectarse rpidamente.
Una de las mximas a aplicar es, los cambios, no han de suponer ms horas de programacin para el programador, ya que
el que no se termina en un da, se deja para el da siguiente.
Se ha de tener asumido que en el proceso de planificacin habrn errores, es ms, sern comunes, y por esto esta
metodologa ya los tiene previstos, por lo tanto se establecern mecanismos de revisin. Cada tres o cinco iteraciones es
normal revisar las historias de los usuarios, y renegociar la planificacin.
Cada iteracin necesita tambin ser planificada, es lo que se llama planificacin iterativa, en la que se anotarn las historias
de usuarios que se consideren esenciales y las que no han pasado las pruebas de aceptacin. Estas planificaciones tambin
se harn en tarjetas, en las que se escribirn los trabajos que durarn entre uno y tres das.
Es por esto que el diseo se puede clasificar como continuo. Aade agilidad al proceso de desarrollo y evita que se mire
demasiado hacia delante, desarrollando trabajos que an no han estado programados.
Este tipo de planificacin en iteraciones y el diseo iterativo, hace que aparezca una prctica que no exista en la
programacin tradicional. Se trata de las discusiones diarias informales, para fomentar la comunicacin, y para hacer que los
desarrolladores tengan tiempo de hablar de los problemas a los que se enfrentan y de ver cmo van con sus trabajos.
DISEO, DESARROLLO Y PRUEBAS
El desarrollo es la parte ms importante en el proceso de la programacin extrema. Todos los trabajos tienen como objetivo
que se programen lo ms rpidamente posible, sin interrupciones y en direccin correcta.
Tambin es muy importante el diseo, y se establecen los mecanismos, para que ste sea revisado y mejorado de manera
continuada a lo largo del proyecto, segn se van aadiendo funcionalidades al mismo.
La clave del proceso de desarrollar XP es la comunicacin. La mayora de los problemas en los proyectos son por falta de
comunicacin en el equipo.
En XP, aparece un nuevo concepto llamado Metfora. Su principal objetivo es mejorar la comunicacin entre todos los
integrantes del equipo, al crear una visin global y comn de lo que se quiere desarrollar. La metfora tiene que ser
expresada en trminos conocidos por los integrantes del equipo, por ejemplo comparando el sistema que se desarrollar con
alguna cosa de la vida real.
Antes de empezar a codificar se tienen que hacer pruebas unitarias, es decir:
Cada vez que se quiere implementar una parte de cdigo, en XP, se tiene que escribir una prueba sencilla, y despus
escribir el cdigo para que la pase. Una vez pasada se ampla y se contina. En XP hay una mxima que dice "Todo el
cdigo que puede fallar tiene que tener una prueba".
Con estas normas se obtiene un cdigo simple y funcional de manera bastante rpida. Por esto es importante pasar las
pruebas al 100%.
Respecto a la integracin del soft, en XP se ha de hacer una integracin continua, es decir, cada vez se tienen que ir
integrando pequeos fragmentos de cdigo, para evitar que al finalizar el proyecto se tenga que invertir grandes esfuerzos
en la integracin final. En todo buen proyecto de XP, tendra que existir una versin al da integrada, de manera que los
cambios siempre se realicen en esta ltima versin.
Otra peculiaridad de XP es que cada programador puede trabajar en cualquier parte del programa.
De esta manera se evita que haya partes "propietarias de cada programador". Por esto es tan importante la integracin
diaria.
Para terminar, otra peculiaridad que tiene la XP. La de fomentar la programacin en parejas, es decir, hacer que los
programadores no trabajen en solitario, sino que siempre estarn con otra persona. Una pareja de programadores ha de
compartir el teclado, el monitor y el ratn. El principio fundamental de este hecho es realizar de manera continua y sin parar
el desarrollo de cdigo. Las parejas tienen que ir cambiando de manera peridica, para hacer que el conocimiento se difunda

en el grupo. Est demostrado que de esta manera el trabajo es ms eficaz y tambin se consigue ms y mejor cdigo.

LENGUAJE UNIFICADO DE MODELADO - UML

El Lenguaje Unificado de Modelado preescribe un conjunto de notaciones y diagramas estndar para modelar sistemas
orientados a objetos, y describe la semntica esencial de lo que estos diagramas y smbolos significan. Mientras que ha
habido muchas notaciones y mtodos usados para el diseo orientado a objetos, ahora los modeladores slo tienen que
aprender una nica notacin.
UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware,
y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas.

1.

Diagramas de Casos de Uso para modelar los procesos business.

2.

Diagramas de Secuencia para modelar el paso de mensajes entre objetos.

3.

Diagramas de Colaboracin para modelar interacciones entre objetos.

4.

Diagramas de Estado para modelar el comportamiento de los objetos en el sistema.

5.

Diagramas de Actividad para modelar el comportamiento de los Casos de Uso, objetos u operaciones.

6.

Diagramas de Clases para modelar la estructura esttica de las clases en el sistema.

7.

Diagramas de Objetos para modelar la estructura esttica de los objetos en el sistema.

8.

Diagramas de Componentes para modelar componentes.

9.

Diagramas de Implementacin para modelar la distribucin del sistema.

UML es una consolidacin de muchas de las notaciones y conceptos ms usadas orientados a objetos.
Empez como una consolidacin del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson,
creadores de tres de las metodologas orientadas a objetos ms populares.

Extensiones UML
Los mecanismos de de extensibilidad incorporados permiten a UML ser una especie de especificacin
abierta que puede cubrir aspectos de modelado no especificados en el documento 1.1. Estos mecanismos
permiten extender la notacin y semtica de UML.
Esteroetipos
Los estereotipos son el mecanismo de extensibilidad incorporado ms utilizado dentro de UML. Un estereotipo respresenta
una distincin de uso. Puede ser aplicado a cualquier elemento de modelado, incluyendo clases, paquetes, relaciones de
herencia, etc. Por ejemplo, una clase con estereotipo actor es una clase usada como un agente externo en el modelado de
negocio. Una clase patrn es modelada como una clase con estereotipo parametrizado, lo que significa que puede contener
parmetros.
Extensiones de Modelado de Negocio
Un documento separado dentro de la especificacin UML define clases y estereotipos de asociacin especficos que
extienden UML hasta cubrir conceptos de modelado de negocio. Esto incluye stereotyping una clase como un actor, un
trabajador (both internal and case), o una entidad, y stereotyping una asociacin como una comunicacin simple, o una
subcripcin entre un origen y un objetivo.
Lenguaje restrictivo (constraint) de objetos (OCL)
Una imagen puede describir muchas palabras. De igual modo, un modelo grfico puede describir una cierta parte del
comportamiento, despus de la cual es necesario rellenar detalles adicionales con palabras. Describiendo algo con palabras,
sin embargo, casi siempre desemboca en ambiguedades; por ejemplo, "que quera decir cuando escribi eso?". El
Lenguaje Restrictivo (constraint) de Objetos (OCL) est incorporado en UML como un estndar para especificar detalles
adicionales, o precisar detalles en la estrucutura de los modelos.
Desarrollado dentro de la IBM Insurace Division como un lenguaje de modelado de negocio, el OCL es
un lenguaje formal diseado para ser fcil de leer y de escribir. OCL es ms funcional que el lenguaje
natural, pero no tan preciso como un lenguaje de programacin - no puede ser usado para escribir lgicas
de lgica de programacin o control de flujo. Puesto que OCL es un lenguaje para la expresin pura, sus
declaraciones estn garantizadas de no tener efectos laterales - simplemente transportan un valor y nunca
pueden cambiar el estado del sistema.
Una perspectiva general de UML
Una vuelta por un caso de uso
Una vez ms, UML es una notacin, no un mtodo. No preescribe un proceso para modelar un sistema.
No obstante, como UML incluye los diagramas de casos de uso, se le considera estar dotado de una aproximacin al diseo
centrada en el problema con los casos de uso. El Diagrama de Caso de Uso nos da el punto de entrada para analizar los
requisitos del sistema, y el problema que necesitamos solucionar.
Casos de Uso y Diagramas de Interaccin
Un caso de uso se modela para todos los procesos que el sistema debe llevar a cabo. Los procesos se describen dentro de
el caso de uso por una descripcin textual o una secuencia de pasos ejecutados. Los Diagramas de Actividad se pueden
usar tambin para modelar escenarios grficamente. Una vez que el
comportamiento del sistema est captado de esta manera, los caos de uso se examinan y amplian para mostrar qu objetos
se interrelacionan para que ocurra este comportamiento. Los Diagramas de Colaboracin y de Secuencia se usan para
mostrar las relaciones entre los objetos.
Clases y Diagramas de Implementacin
Conforme se van encontrando los objetos, pueden ser agrupados por tipo y clasificados en un Diagrama de Clase. Es el
diagrama de clase el que se combierte en el diagrama central del anlisis del diseo orientado a objetos, y el que muestra la
estructura esttica del sistema. El diagrama de clase puede ser dividido en capas: aplicacin, y datos, las cuales muestran
las clases que intervienen con la interfaz de usuario, la lgica del software de la aplicacin, y el almacentamiento de datos
respectivamente. Los Diagramas de Componentes se usan para agrupar clases en componentes o mdulos. La distribucin
general del hardware del sistema se modela usando el Diagrama de Implementacin.
Tarjetas CRC (CRC cards) - Una extensin informal de UML
Como una extensin informal a UML, la tcnica de las tarjetas CRC se puede usar para guiar el sistema a travs de anlisis
guiados por la responsabilidad. Las clases se examinan, se filtran y se refinan en base a sus responsabilidades con respecto
al sistema, y las clases con las que necesitan colaborar para completar sus responsabilidades.

Diagramas de Estado
El comportamiento en tiempo real de cada clase que tiene comportamiento dinmico y significativo, se modela usando un
Diagrama de Estado. El diagrama de actividad puede ser usado tambin aqu, esta vez como una extensin del diagrama de
estado, para mostrar los detalles de las acciones llevadas a cabo por los objetos en respuesta a eventos internos. El
diagrama de actividad se puede usar tambin para representar grficamente las acciones de mtodos de clases.
Implementando el diseo
La implementacin del sistema trata de traducir informacin desde mltiples modelos UML en cdigo y estructura de bases
de datos. Cuando se modela un sistema grande, es til fragmentar el sistema en su capa business (incluyendo los objetos
de la interfaz de usuario), su capa de aplicacin (incluyendo los objetos de implementacin), y su capa de datos (incluyendo
la estrucutra de la base de datos y el acceso a objetos).
Implementando la aplicacin
El Diagrama de Clase se usa para generar una estructura base del cdigo en el lenguaje escogido. Informacin de los
diagramas de interaccin, estado, y actividad, puede ofrecer detalles de la parte procedimental del cdigo de
implementacin.
Implementando el diseo de Bases de Datos
La capa de datos del diagrama de clase se puede usar para implementar direcatmente un diseo orientado a objetos de una
base de datos, o, como extensin de UML, puede ser referenciado en un diagrama de relacin de entidad para ms anlisis
de relaciones de entidad. Est en el diagrama de relacin de entidad (ER diagram, entity relationship) el cual relaciona entre
entidades que pueden ser modeladas basadas en atributos clave. El diagrama de relacin de entidad lgico ofrece una base
desde la cual construir un diagrama fsico representando las tablas y relaciones actuales de la base de datos relacional.
Probar teniendo en cuenta los requisitos
Los casos de uso se utilizan tambin para probar el sistema y ver si satisface los requisitos iniciales. Los pasos de los casos
de uso van llevando a cabo para determinar si el sistema est satisfacciendo los requisitos del usuario.
Un estudio a fondo de UML
Las siguientes secciones presentan una vista ms detallada al modelado con UML. Un sistema de reserva de aerolneas
simple se va a usar para mostrar los diagramas y tcnicas de modelado con UML. Se cubren los siguientes puntos:

Organizando tu sistema con paquetes

Modelando con Casos de Uso, y usndolos para averiguar los requisitos del sistema

Modelando con Diagramas de Secuencia y Colaboracin

Analizando y diseando con el Diagrama de Clase, y extendiendo UML con la tcnica de las tarjetas CRC

Modelando comportamiento con Diagramas de Actividad y de Estado

Modelando componentes de software, distribucin e implementacin

Extendiendo UML con el diseo de Bases de Datos relacionales

Una de las tareas clave para modelar un sistema de sofware de grandes dimensiones es dividirlo primero en reas
manejables. Aunque estas reas se llaman dominios, categoras o subsistemas, la idea es la
misma: dividir el sistema en reas que tengan competencias parecidas.
UML introduce la nocin de un paquete como el tem universal para agrupar elementos, permitiendo a los modeladores
subdividir y categorizar sistemas. Los paquetes pueden ser usados en cualquier nivel, desde el nivel ms alto, donde son
usados para subdividir el sistema en dominios, hasta el nivel ms bajo, donde son usados para agrupar casos de uso
individuales, clases, o componentes.

Modelado de Casos de Uso

El modelado de Casos de Uso es la tcnica ms efectiva y a la vez la ms simple para modelar los requisitos del sistema
desde la perspectiva del usuario. Los Casos de Uso se utilizan para modelar cmo un sistema o negocio funciona
actualmente, o cmo los usuarios desean que funcione. No es realmente una aproximacin a la orientacin a objetos; es
realmente una forma de modelar procesos. Es, sin embargo, una manera muy buena de dirigirse hacia el anlisis de
sistemas orientado a objetos. Los casos de uso son generalmente el punto de partida del anlisis orientado a objetos con
UML.
El modelo de casos de uso consiste en actores y casos de uso. Los actores representan usuarios y otros sistemas que
interaccionan con el sistema. Se dibujan como "muecos" de palo. Actualmente representan el tipo de usuario, no una
instancia de usuario. Los casos de uso representan el comportamiento del sistema, los escenarios que el sistema atraviesa
en respuesta a un estmulo desde un actor. Se dibujan como elipses.
Cada caso de uso se documenta por una descripcin del escenario. La descripcin puede ser escrita en modo de texto o en
un formato paso a paso. Cada caso de uso puede ser tambin definido por otras propiedades, como las condiciones pre- y
post- del escenario --- condiciones que existen antes de que el escenario comience, y condiciones que existen despus de
que el escenario se completa. Los Diagramas de Actividad ofrecen una herramienta grfica para modelar el proceso de un
Caso de Uso.
Estudiar y descubrir los requisitos
El objetivo final en cualquier diseo de software es satisfacer los requisitos del usuario para el sistema. Estos requisitos
pueden ser requisitos de software, requisitos de productos, o requisitos de pruebas. La meta de capturar y comprobar los
requisitos del usuario es asegurar que todos los requisitos son completados por el diseo, y que el diseo es acorde con los
requisitos especificados. Muchas veces los requisitos del sistema ya existen en forma de documentos de requisitos. Los
casos de uso se utilizan para correlacionar cada escenario con los requisitos que completa. Si los requisitos no existen,
modelar el sistema a travs de los Casos de Uso, permite el descubrimiento de estos requisitos.
Organizacin de Diagramas de Casos de Uso
Durante el anlisis de negocio (business) del sistema, puedes desarrollar un modelo de caso de uso para este sistema, y
construir paquetes para representar los varios dominios de negocio (business) del sistema. Puedes descomponer cada
paquete con un Diagrama de Caso de Uso que contenga los Casos de Uso de un dominio, con interacciones de actor.
Un Caso de Uso para cada escenario
El objetivo es construir un Diagrama de Caso de Uso para cada tipo de escenario diferente en el sistema. Cada escenario
muestra una secuencia diferente de interacciones entre actores y el sistema, sin condiciones or.
Modelar secuencias alternas a travs de la relacin "Extiende" (extends)
Tpicamente, uno modela cada Caso de Uso con una secuencia normal de acciones. El usuario entonces considera
condiciones "que si" para cada paso, y desarrolla Casos de Uso basados en estas secuencias alternas de eventos. Las
secuencias alternas se modelan en casos de uso separados, los cuales estn relacionados con el caso de uso original
mediante una relacin "Extiende" (extends). Las relacciones Extiende (extends) pueden ser pensadas como un caso de uso
equivalente a herencia, en el cual el caso de uso extendido, hereda y modifica el comportamiento del caso de uso original.
Eliminar el modelado redundante a travs de la relacin "Usa"
(uses)
Para eliminar el modelado redundante de buena parte del comportamiento que aparezca en varios casos de uso, la parte del
comportamiento puede ser modelada en un caso de uso separado que est relacionado con los otros casos de uso mediante
la relacin "Usa" (uses). La relacin Usa (uses) se puede pensar como un caso de uso equivalente of aggregation.

Ayuda en casos de uso probando el sistema frente a los requisitos

Los Casos de Uso tambin se utilizan para constriur scripts de prueba que se usan a su vez para comprobar que la

aplicacin satisface los requisitos de negocio y de sistema. Cuando has llegado al caso de uso del nivel ms bajo, podras
crear un Diagrama de Secuencia para el Caso de Uso. Con los Diagramas de Secuencia y de Colaboracin puedes modelar
la implementacin del escenario.
Diagramas de Secuencia
El Diagrama de Secuencia es uno de los diagramas ms efectivos para modelar interaccin entre objetos en un sistema. Un
diagrama de secuencia se modela para cada caso de uso. Mientras que el diagrama de caso de uso permite el modelado de
una vista business del escenario, el diagrama de secuencia contiene detalles de implementacin del escenario, incluyendo
los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos. Tpicamente uno
examina la descripcin de un caso de uso para determinar qu objetos son necesariospara la implementacin del escenario.
Si tienes modelada la descripcin de cada caso de uso como una secuencia de varios pasos, entonces puedes "caminar
sobre" esos pasos para descubrir qu objetos son necesarios para que se puedan seguir los pasos.
Un diagrama de secuencia muestra los objetos que intervienen en el escenario con lneas discontinuas verticales, y los
mensajes pasados entre los objetos como vectores horizontales. Los mensajes se dibujan cronolgicamente desde la parte
superior del diagrama a la parte inferior; la distribucin horizontal de Durante el anlisis inicial, el modelador tpicamente
coloca el nombre business de un mensaje en la lnea del mensaje. Ms tarde, durante el diseo, el nombre business es
reemplazado con el nombre del mtodo que est siendo llamado por un objeto en el otro. El mtodo llamado, o invocado,
pertenece a la definicin de la case instanciada por el objeto en la recepcin final del mensaje.

UNA PERSPECTIVA GENERAL DE UML

UNA VUELTA PARA UN CASO DE USO
El diagrama de caso de uso sirve para determinar los requerimientos del sistema, entender como
es que funciona, para que sirve el software, etc.
CASOS DE USO Y DIAGRAMAS DE ITERACIN
Un caso de uso se modela para cada proceso que el sistema debe llevar a cabo, los diagramas
sirven para mostrar las relaciones que existen entre los elementos del software.
CLASES
Conforme se va avanzando y se van determinando los requerimientos, estos requerimientos
pueden ser agrupados de acuerdo a su similitud, tambin podemos decir que se agruparn en
clases.
DIAGRAMAS DE ESTADO
Las clases que representen alguna actividad del software en tiempo real se puede representar
mediante diagramas de clase as podemos conocer mejor como es que trabaja el sistema.
IMPLEMENTANDO EL DISEO
Una ves definidas las clases y como interactas unas con otras debemos implementar un diseo
tentativo del sistema.
IMPLEMENTANDO LA APLICACIN
Con el diagrama de clase bien establecido podemos proceder a implementar la aplicacin en el
lenguaje escogido.
IMPLEMENTANDO EL DISEO DE BASE DE DATOS
Con el diagrama de datos del sistema se puede implementar una base de datos orientados a
objetos.
UN ESTUDIO A FONDO DE UML
MODELADO DE CASOS DE USO
El modelado de casos de uso es la forma ms sencilla de identificar los requerimientos del sistema,
este modelado es el principio para hacer un modelado orientado a objetos con UML.
ESTUDIAR Y DESCUBRIR LOS REQUISITOS
La meta es identificar todos los requisitos ya sean requisitos del sistema, requisitos del software y
requisitos del productos, todo esto se lleva a cabo con la ayuda del cliente.

UN CASO DE USO PARA CADA ESCENARIO

Aqu lo importante es determinar cual ser el uso que recibir cada mdulo del sistema, debe ser
diferente entre los otros mdulos, no se debe usar condiciones or.
ELIMINAR EL MODELO REDUNDANTE
Se debe buscar aquel proceso que se realiza en varios casos de uso para optimizar al trabajo del
sistema.
DIAGRAMAS DE SECUENCIA
Los diagramas de secuencia ayudan mucho a entender como es la iteracin entre los procesos.
DIAGRAMAS DE COLABORACIN
Los diagramas de colaboracin ayudan a los diagramas de secuencia ya que mientras los
diagramas de secuencia estudian el centro del proceso, los diagramas de colaboracin estudian los
efectos que causan cada proceso en un objeto.
ANALISIS Y DISEO CON EL DIAGRAMA DE CLASE
El diagrama de clase es el diagrama principal de diseo e implementacin del software:
DESARROLLO DE DIGRAMAS DE CLASE DURANTE EL ANLISIS
Diseo del sistema con diagramas de clase: Los diagramas de clase sirven para tener en
forma concreta los objetos del sistema y con ello elaborar un diseo del sistema ms acertado.
Diseo de componentes: Los componentes estn formados por subprocesos o subcomponentes,
un componente se muestra al cliente mediante la interfaz del sistema sin mostrar las lneas de
cdigo.
MODELANDO COMPONENTES DEL SOFTWARE
Aqu modelamos la estructura del software, los elementos e indicando la dependencia entre ellas.
DISEO DE BASE DE DATOS RELACIONALES
El diagrama de clase de UML se puede usar para elaborar algunas partes de la base relacional pero
UML no cubre toda la semntica involucrada en el modelo relacional.