CLOUD COMPUTING

Es un término que se define como una tecnología que ofrece servicios a través de la plataforma de internet. Los usuarios de este servicio tienen acceso de forma gratuita o de pago todo depende del servicio que se necesite usar. 

 El término es una tendencia que responde a múltiples características integradas. Uno de los ejemplos de está “nube” es el servicio que presta Google Apps que incorpora desde un navegador hasta el almacenamiento de datos en sus servidores. Los programas deben estar en los servidores en línea y puedas accesar a los servicios y la información a través de internet.

Características del cloud Computing

Una de las principales diferencias del Could Computing es que no hay necesidad de conocer la infraestructura detrás de esta, pasa a ser “una nube” donde las aplicaciones y servicios pueden fácilmente crecer (escalar), funcionar rápido y casi nunca fallan, sin conocer los detalles del funcionamiento de esta “nube”.
Este tipo de servicio se paga según alguna métrica de consumo, no por el equipo usado en sí, sino por ejemplo en el consumo de electricidad o por uso de CPU/hora como en el caso de Amazon EC2. Entre otras características podemos mencionar:

• Auto Reparable: En caso de fallo, el ultimo backup de la aplicación pasa a ser automáticamente la copia primaria y se genera uno nuevo.
• Escalable: Todo el sistema/arquitectura es predecible y eficiente. Si un servidor maneja 1000 transacciones, 2 servidores manejaran 2000 transacciones.
• Regidos por un acuerdo de nivel de servicio (SLA) que define varias políticas como cuales son los tiempos esperados de rendimiento y en caso de pico, debe crear más instancias. En el caso de AWS aún se pregunta si su SLA es adecuado.
• Virtualizado: las aplicaciones son independientes del hardware en el que corran, incluso varias aplicaciones pueden corren en una misma maquina o una aplicación puede usar varias maquinas a la vez.
• Multiproposito: El sistema está creado de tal forma que permite a diferentes clientes compartir la infraestructura sin preocuparse de ello y sin comprometer su seguridad y privacidad.

Ventajas y desventajas del Cloud Computing

Entre las ventajas de la Clound Computing se pueden mencionar:

• Acceso a la información y los servicios desde cualquier lugar.
• Servicios gratuitos y de pago según las necesidades del usuario.
• Empresas con facilidad de escalabilidad
• Capacidad de procesamiento y almacenamiento sin instalar máquinas localmente.

Entre las desventajas podemos mencionar:

• Acceso de toda la información a terceras empresas.
• Dependencia de los servicios en línea.

¿QUE ES MDA?

Model Driven Architecture (MDA) es una aproximación para el refinamiento o síntesis de software. MDA ha sido propuesto por la OMG  y OMG´S MDA es una arquitectura  estándar creada y utilizada por la industria de manera innovadora. MDA está basado en transformaciones MOF (Meta Object Facility) y específicamente trata del tema de transformaciones entre modelos  y generación automática de código fuente.

MDA define el inicio del proceso de desarrollo bajo modelos PIM (Platform Independent Model), clasificación dada a modelos de software que son completamente independientes de plataformas o tecnologías en las cuales será implementado. Un modelo independiente de plataforma puede representar muchos modelos del tipo PSM (Platform Specific Model), como es para Java un modelo EJB, por ejemplo. Una vez de pose de un PSM, es posible generar el código fuente de la aplicación, siendo la más grande premisa de MDA lo de separar el espacio del problema y el espacio de la solución, es decir: la especificación de los procesos de la implementación de la solución. Dichos conceptos mejoran la calidad del software generado, posibilitando portabilidad e interoperabilidad entre aplicaciones. La calidad final del producto generado también es incrementada cuando la pensamos, mirando hacía un proceso manual y normal de desarrollo, susceptible a fallos y errores humanos. Model Driven Architecture viene a confirmar la necesidad actual de la industria, que busca siempre optimizar el complejo proceso de desarrollo, pues de hecho el número de tecnologías utilizadas en el actual panorama productivo de sistemas es algo que pone aún más complejo su desarrollo, eternamente en busca de mano de obra especializada a cada proyecto en tecnologías que debe abarcar.

MDA define un ciclo de vida completo para la concepción de software: diseño, desarrollo, integración y manutención haciendo uso de estándares abiertos. MDA representa una grande evolución y utiliza el estándar UML como lenguaje patrón en la definición de modelos transformables y XMI (Xml Metadala Interchange) para gestionar y representar modelos de software bajo el patrón XML.

La productividad y la calidad son ventajas que también deben ser citadas una vez que MDA permite transformaciones que visan ahorrar el trabajo de desarrollo, permitiendo pensar solamente en el espacio del problema, que es lo que de verdad importa. Otros beneficios citados son: Reducir el coste, reducir el tiempo, permitir un retorno más rápido bajo las aplicaciones desarrolladas y rápida inclusión de nuevos tecnologías en software legado.

MDA antes de más nada, fornece la base en nuestra estrategia de desarrollo automático orientado a SOA y teniendo como inicio la especificación de procesos de negocio haciendo uso de MAPS. 

http://www.m40s.com/mdaCast.aspx

¿QUE ES BPM?

BPM es “un conjunto de herramientas, tecnologías, técnicas, métodos y disciplinas de gestión concebidas para diseñar y ejecutar la automatización de procesos empresariales”.

Es decir, el BPM sirve para automatizar el ciclo de vida de los procesos. Todas las organizaciones realizan sus actividades según flujos de trabajo más o menos establecidos, y ese “más o menos” puede suponer el éxito o el fracaso de la empresa. Mediante las herramientas BPM una organización tendrá la posibilidad de definir en una aplicación informática sus procesos, organizar la información y el trabajo de las personas, controlar su ejecución en tiempo real y mediante una monitorización adecuada (indicadores, alertas, informes, cuadros de mandos) extraer conclusiones para alinearse con el objetivo último de lograr una mayor eficiencia.

Hay multitud de aplicaciones en el mercado que pueden ayudar a las empresas a definir y gestionar, de manera más o menos sencilla, sus procesos y contenidos. Destacan en general por ser herramientas ágiles y flexibles, que facilitan la capacidad de adaptación al cambio, sin que normalmente sea requerido un perfil técnico para implementar dichas modificaciones una vez implantado el sistema. La tendencia hace que se trate generalmente de herramientas web, que permiten comunicarse internamente a los empleados de la organización mediante portales empresariales, y que además ofrecen la posibilidad de abrir las puertas de la propia organización a clientes, proveedores, socios, etc., para que también éstos, si es necesario, intervengan de manera más activa en la ejecución de los procesos.


Es fácil intuir que para llevar a cabo una estrategia BPM se necesita tener cierto nivel de madurez empresarial y organizativa. El hecho de plantearse implantar un BPM, implica la necesidad de analizar qué y cómo se están haciendo las cosas en su empresa y si realmente dispone del control que necesita de sus procesos. Este acto de reflexión previo es realmente necesario, y como comentaremos en próximos post a este Blog, le permitirá abordar un proyecto de implantación de una herramienta BPM con mayor garantía de éxito.

http://prodintec.wordpress.com/2010/03/09/%C2%BFque-es-el-bpm/ 

¿QUE ES SOA?

La arquitectura orientada a servicios (SOA) no se trata de software o de un lenguaje de programación, SOA es un marco de trabajo conceptual que permite a las organizaciones unir los objetivos de negocio con la infraestructura de TI integrando los datos y la lógica de negocio de sus sistemas separados.
Desarrollada a finales de los ´90, SOA establece un marco de trabajo para servicios de red – o tareas comunes de negocios – para identificar el uno al otro y comunicarlo.
La necesidad de tal marco se deriva de la evolución del software de negocio. En los comienzos, los desarrollos de aplicaciones de negocio se concentraban en necesidades específicas: contabilidad, compras, nómina de sueldos, transporte. Cada aplicación fue desarrollada sin consideración de otros sistemas en la empresa y como comunicarse con ellos. Porque las aplicaciones eran auto suficientes, la información común a toda la empresa (como por ejemplo: la dirección del cliente) y funciones específicas de negocios (como por ejemplo: buscar un nombre) aparecían en todas partes y requerían un código complejo para, todos o muchos de los sistemas independientes.
Por consiguiente, los diversos sistemas de TI de la mayoría de las empresas hoy no pueden acceder o procesar los datos desde el uno al otro. Un simple proceso de negocio (como una venta para un pedido a un depósito enviado a una cuenta por cobrar) que tomaría segundos si los sistemas se podrían comunicar, ahora puede tomar semanas.
¿Qué puede hacer una empresa? Debería tener inversiones masivas en hardware, software y perfiles de individuos involucrados en la ejecución de cada una de las aplicaciones separadas? Con SOA, una empresa puede mantener sus inversiones en los sistemas legacy y la gente necesaria para mantenerlos. Esto evita continuos y costosos proyectos "de integración", como las mejoras a cualquier aplicación son transparentes a todas las otras. La información de negocio es siempre "hasta el último minuto", permitiendo mejores decisiones de negocio y mejorar las relaciones entre clientes y partners.
A menudo, SOA es una solución prometedora para los problemas de integración. El desafío es cómo llegar ahí.
Cómo crear un ambiente SOA El desarrollo de un ambiente SOA involucra un número de pasos. El primer paso es asegurar que todo el software nuevo que se instale sea compatible con SOA. El segundo paso es identificar las funciones dentro de los sistemas legacy que desean integrar y publicarlas como servicios. Por supuesto, esto no es tan fácil como suena. El desarrollo de estos servicios puede requerir de perfiles que no existen en la empresa. Y las herramientas necesarias para examinar los desarrollos y las etapas de despliegue pueden venir de diferentes proveedores, cada uno con su propia instalación, entrenamiento y temas de comunicación.

El Desarrollo de Aplicaciones Orientadas a Servicios (SODA) está diseñado para vencer muchos de los problemas de lenguajes de software inherentes en los sistemas legacy. SODA permite reutilizar aplicaciones existentes y proveer un camino para construir nuevas, basadas en estándares, con interfases flexibles.
Esta adopción habilita un alto nivel de abstracción tecnológica. Es decir, SODA encapsula y abstrae tecnologías tales como bases de datos, J2EE, .NET y CORBA de modo que los desarrolladores no afronten la complejidad técnica de la interacción con aplicaciones heterogéneas y sistemas de infraestructura. SODA así reduce significativamente el esfuerzo requerido para traducir nuevos desafíos de negocios dentro de aplicaciones funcionales.

http://tecnologia.iprofesional.com/notas/46399-Qu-es-SOA-la-arquitectura-orientada-a-servicios

¿QUE ES MDD?

El Desarrollo de Software Dirigido por Modelos (DSDM, también denominado MDD por su acrónimo en inglés, Model-Driven Development) es una propuesta para el desarrollo de software en la que se le atribuye a los modelos el papel principal de todo el proceso, frente a las propuestas tradicionales basadas en lenguajes de programación y plataformas de objetos y componentes de software.

Son varias las razones que han motivado la aparición de este nuevo paradigma. En primer lugar nos encontramos con la creciente complejidad de las aplicaciones de software, que han de satisfacer un mayor número de requisitos (heterogeneidad, distribución, alta disponibilidad, adaptabilidad, etc.) con mejores prestaciones y menores tiempos de desarrollo. Por otro lado, las nuevas tecnologías evolucionan demasiado deprisa (COM, DCOM, COM+, CORBA, CCM, J2EE, .NET, Web Services, SOA...), lo que hace que las inversiones en tecnologías concretas sean demasiado volátiles. Si bien es cierto que esos problemas no son nuevos en el campo de la Ingeniería de Software, está comprobado que la mejor forma de tratar con ellos es elevando el nivel de abstracción de los modelos desde las primeras etapas del desarrollo.

De hecho, el DSDM no es el primer intento por resolver este tipo de problemas. A lo largo de la evolución de la Ingeniería de Software hemos asistido a muchas propuestas para que los programas reflejen de una forma mejor y a más alto nivel, no sólo el dominio del problema, sino también para que traten de ocultar la complejidad de la tecnología sofware subyacente. Normalmente esto se ha llevado a cabo mediante la definición de lenguajes de programación, cada vez de más alto nivel (COBOL, Pascal, C, C++, Eiffel, Java, Python, Ruby, etc.), y la aparición de nuevas técnicas y mecanismos, por ejemplo los marcos de trabajo (frameworks) como Struts o Rails. Sin embargo, estos intentos no han conseguido lograr del todo su objetivo. Quizás una de las razones de su aparente fracaso es que estaban basados en las propias tecnologías del software, cuando es precisamente ahí donde residen la mayoría de los problemas.

Principios básicos del DSDM

Uno de los términos claves en la filosofía del DSDM es el concepto de modelo. De forma sencilla podríamos definir un modelo como una abstracción simplificada de un sistema o concepto del mundo real. Como tal, el modelo contiene un menor nivel de detalle que su correspondiente artefacto de la vida real. Sin embargo, ésta no es la única definición que encontraremos en la literatura sobre el término "modelo". A modo de ejemplo, las siguientes citas muestran algunas de las acepciones más comunes de este concepto en el ámbito de la Ingeniería de Software y del DSDM:

Un modelo es una descripción de un sistema, o parte de éste, escrito en un lenguaje bien definido. (Warmer y Kleppe, 2003).

Un modelo es una representación de una parte de la funcionalidad, estructura y/o comportamiento de un sistema (OMG, 2001).

Un modelo es una descripción o especificación de un sistema y su entorno definida para cierto propósito. Un modelo es representado habitualmente como una combinación de elementos gráficos y de texto. (Miller y Mukerji, 2003).

Según Wermer y Kleppe (2003), cada modelo se centra en la descripción de un único aspecto del sistema, de acuerdo a un propósito específico, y descrito hasta un cierto nivel de abstracción adecuado para el problema modelado. Tal descripción puede facilitarse de forma gráfica o textual (Miller y Mukerji, 2003), haciendo uso generalmente de lenguajes de modelado cuya semántica esté bien definida. A este respecto, la idea compartida por todos los paradigmas englobados dentro del DSDM es la conveniencia de utilizar para el modelado lenguajes de mayor nivel de abstracción que los lenguajes de programación habituales, esto es, lenguajes que manejen conceptos más cercanos al dominio de la aplicación. Así pues, dependiendo del ámbito DSDM que se trate, estos lenguajes que proporcionan mayor nivel de abstracción se denominanlenguajes de modelado (contexto de MDA) o lenguajes específicos del dominio (contexto de DSM y SF).

MODELO FLOR

El propósito del desarrollo de software es el desarrollo de un producto de software.
Los equipos no deben estar preocupados por el proceso de desarrollo del mismo.
Deben de desarrollarse todas las etapas un poco al mismo tiempo hasta que el producto final es alcanzado.
Construcción de prototipos
* Identificación de requerimientos
* Diseño rápido
* Utilizar el prototipo
* Revisar y mejorar
VENTAJAS Y DESVENTAJAS

• Útiles cuando los requerimientos son cambiables. 
• No se conoce cuando tengamos un producto aceptable.
• Cuando el usuario no se quiere comprometer con los requerimientos 
•  No se sabe cuántas iteraciones serán necesarias. 
• Cuando no se conoce bien la aplicación 
•  Dan una falsa ilusión al usuario sobre la velocidad del desarrollo. 
• Cuando se quiere probar una arquitectura o tecnología 
• Se puede volver al producto aun y cando no esté con los estándares . 
• Cuando se requiera rapidez en el desarrollo.  

http://es.scribd.com/doc/56609536/ModelosD
http://www.cepeu.edu.py/LIBROS_ELECTRONICOS_3/lpcu097%20-%2001.pdf

MODELO EN V

El modelo en V es una variación del modelo en cascada que muestra cómo se relacionan las actividades de prueba con el análisis y el diseño. la codificación forma el vértice de la V, con el análisis y el diseño a la izquierda y las pruebas y el mantenimiento a la derecha.

Ventajas y desventajas  del Modelo en “V”

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

"MODELO UML"

¿Qué es UML?

El Lenguaje de Modelado Unificado (UML:Unified Modeling Language) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos, es llamado un lenguaje de modelado, no un método. Los métodos consisten de ambos de un lenguaje de modelado y de un proceso. El UML , fusiona los conceptos de la orientación a objetos aportados por Booch, OMT y OOSE. UML incrementa la capacidad de lo que se puede hacer con otros métodos de análisis y diseño orientados a objetos. Los autores de UML apuntaron también al modelado de sistemas distribuidos y concurrentes para asegurar que el lenguaje maneje adecuadamente estos dominios.

El lenguaje de modelado es la notación (principalmente gráfica) que usan los métodos para expresar un diseño. El proceso indica los pasos que se deben seguir para llegar a un diseño.

La estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal del proceso de comunicación que requieren todos los agentes involucrados en un proyecto informático. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo.

UML es una técnica para la especificación sistemas en todas sus fases. Nació en 1994 cubriendo los aspectos principales de todos los métodos de diseño antecesores y, precisamente, los padres de UML son Grady Booch, autor del método Booch; James Rumbaugh, autor del método OMT e Ivar Jacobson, autor de los métodos OOSE y Objectory. La versión 1.0 de UML fue liberada en Enero de 1997 y ha sido utilizado con éxito en sistemas construidos para toda clase de industrias alrededor del mundo: hospitales, bancos, comunicaciones, aeronáutica, finanzas, etc.

Los principales beneficios de UML son:

• Mejores tiempos totales de desarrollo (de 50 % o más).
• Modelar sistemas (y no sólo de software) utilizando conceptos orientados a objetos.
• Establecer conceptos y artefactos ejecutables.
• Encaminar el desarrollo del escalamiento en sistemas complejos de misión crítica.
• Crear un lenguaje de modelado utilizado tanto por humanos como por máquinas.
• Mejor soporte a la planeación y al control de proyectos.
• Alta reutilización y minimización de costos.

Vistas: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo. Las diferentes vistas que UML tiene son:

  Vista Use-Case: Una vista que muestra la funcionalidad del sistema como la perciben los actores externos.

• Vista Lógica: Muestra cómo se diseña la funcionalidad dentro del sistema, en términos de la estructura estática y la conducta dinámica del sistema.

• Vista de Componentes: Muestra la organización de los componentes de código.

• Vista Concurrente: Muestra la concurrencia en el sistema, direccionando los problemas con la comunicación y sincronización que están presentes en un sistema concurrente.

• Vista de Distribución: muestra la distribución del sistema en la arquitectura física con computadoras y dispositivos llamados nodos.

Diagramas: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.

Símbolos o Elementos de modelo: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización.

Reglas o Mecanismos generales: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

FASES DEL DESARROLLO DE UN SISTEMA

Las fases del desarrollo de sistemas que soporta UML son: Análisis de requerimientos, Análisis, Diseño, Programación y Pruebas.

Análisis de Requerimientos

UML tiene casos de uso (use-cases) para capturar los requerimientos del cliente. A través del modelado de casos de uso, los actores externos que tienen interés en el sistema son modelados con la funcionalidad que ellos requieren del sistema (los casos de uso).

Análisis

La fase de análisis abarca las abstracciones primarias (clases y objetos) y mecanismos que están presentes en el dominio del problema. Las clases que se modelan son identificadas, con sus relaciones y descritas en un diagrama de clases. Las colaboraciones entre las clases para ejecutar los casos de uso también se consideran en esta fase a través de los modelos dinámicos en UML.

Diseño

En la fase de diseño, el resultado del análisis es expandido a una solución técnica. Se agregan nuevas clases que proveen de la infraestructura técnica: interfaces de usuario, manejo de bases de datos para almacenar objetos en una base de datos, comunicaciones con otros sistemas, etc.

Programación

En esta fase las clases del diseño son convertidas a código en un lenguaje de programación orientado a objetos. Cuando se crean los modelos de análisis y diseño en UML, lo más aconsejable es trasladar mentalmente esos modelos a código.

Pruebas

Normalmente, un sistema es tratado en pruebas de unidades, pruebas de integración, pruebas de sistema, pruebas de aceptación, etc. Las pruebas de unidades se realizan a clases individuales o a un grupo de clases y son típicamente ejecutadas por el programador. Las pruebas de integración integran componentes y clases en orden para verificar que se ejecutan como se especificó.

http://profesores.fi-b.unam.mx/carlos/aydoo/uml.html 

"MOTODOLOGIA RUP"

METODOLOGIA RUP

El  Proceso Unificado de Racional. Es un proceso de ingeniería de software que suministra un enfoque para asignar tareas y responsabilidades dentro de una organización de desarrollo. Su objetivo es asegurar la producción de software de alta calidad que satisfaga la necesidad del usuario final dentro de un tiempo y presupuesto previsible. Es una metodología de desarrollo iterativo enfocada hacia “los casos de uso, manejo de riesgos y el manejo de la arquitectura”.

El RUP mejora la productividad del equipo ya que permite que cada miembro del grupo sin importar su responsabilidad específica acceda a la misma base de datos de conocimiento. Esto hace que todos compartan el mismo lenguaje, la misma visión y el mismo proceso acerca de cómo desarrollar software.

CICLO DE VIDA. 

En el ciclo de vida RUP es una implementación del desarrollo en espiral.

Con el ciclo de vida se establecen tareas en fases e iteraciones. El RUP maneja el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable. 

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una base de inicio. 

FASES

FASE DE INICIO

Durante esta fase de inicio las iteraciones se centran con mayor énfasis en las actividades de modelamiento de la empresa y en sus requerimientos

FASE DE ELABORACIÓN

Durante esta fase de elaboración, las iteraciones se centran al desarrollo de la base de la diseño, encierran más los flujos de trabajo de requerimientos, modelo de la organización, análisis, diseño y una parte de implementación orientada a la base de la construcción

FASE DE CONSTRUCCIÓN

Durante esta fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones las cuales se seleccionan algunos Casos de Uso, se redefine su análisis y diseño y se procede a su implantación y pruebas. En esta fase se realiza una pequeña cascada  para cada ciclo, se realizan tantas iteraciones hasta que se termine la nueva implementación del producto.

FASE DE TRANSICIÓN

Durante esta fase de transición busca garantizar que se tiene un producto preparado para su entrega al usuario.

PRINCIPALES CARACTERISTICAS

• Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo)
• Pretende implementar las mejores prácticas en Ingeniería de Software
• Desarrollo iterativo
• Administración de requisitos
• Uso de arquitectura basada en componentes 
• Control de cambios
• Modelado visual del software
• Verificación de la calidad del software

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 código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso).

Especificación de las Fases

• Establece oportunidad y alcance
• Identifica las entidades externas o actores con las que se trata
• Identifica los casos de uso

RUP comprende 2 aspectos importantes por los cuales se establecen las disciplinas:

Proceso: Las etapas de esta sección son:

• Modelado de negocio
• Requisitos
• Análisis y Diseño
• Implementación
• Pruebas
• Despliegue

Soporte: En esta parte nos conseguimos con las siguientes etapas:

• Gestión del cambio y configuraciones
• Gestión del proyecto
• Entorno

La estructura dinámica de RUP es la que permite que este sea un proceso de desarrollo fundamentalmente iterativo, y en esta parte se ven inmersas las 4 fases descritas anteriormente:

• Inicio(También llamado Incepción)
• Elaboración
• Desarrollo(También llamado Implementación, Construcción)
• Cierre (También llamado Transición)

Artefactos

RUP en cada una de sus fases (pertenecientes a la estructura estática) realiza una serie de artefactos que sirven para comprender mejor tanto el análisis como el diseño del sistema estos artefactos son los siguientes:

Inicio:

• Documento Visión
• Especificación de Requerimientos

Elaboración:

• Diagramas de caso de uso

Construcción:

• Documento Arquitectura que trabaja con las siguientes vistas:

   Vista Lógica:

• Diagrama de clases
• Modelo E-R (Si el sistema así lo requiere)

   Vista de Implementación:

• Diagrama de Secuencia
• Diagrama de estados
• Diagrama de Colaboración

   Vista Conceptual: 

• Modelo de dominio

   Vista física:

• Mapa de comportamiento a nivel de hardware.

Implementación del RUP para el proyecto

La metodología RUP es más apropiada para proyectos grandes (Aunque también pequeños), dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no se puedan cubrir los costos de dedicación del equipo de profesionales necesarios.

https://docs.google.com/viewer?a=v&q=cache:vddiq_I3l54J:ingenieriasoftwaredos.wikispaces.com/file/view/METODOLOGIA%2BRUP%2Btrabajo1.doc+&hl=es-419&gl=mx&pid=bl&srcid=ADGEEShsuu4lOb2UXKq1Up5LDa5-zo8cnWcXp-TAzeT7PedZV1y4Q9WZWv2qCIpr5JQJfBGQ8lScxRmaqGZZDGTmEDMqa3fTyf7k-y8EsaTUHN4063KWUsImh88u32v9wvSGG4XcRucI&sig=AHIEtbSAVtuYkilaoda1V15u1qQURLkUdA