SlideShare uma empresa Scribd logo
1 de 17
Baixar para ler offline
UNIVERSIDAD DE ORIENTE
NÚCLEO DE ANZOÁTEGUI
ESCUELA DE INGENIERIA Y CIENCIAS APLICADAS
DEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS
CÁTEDRA: DESARROLLO DE SOFWARE
RUP
FASE DE ELABORACIÓN
Integrantes:
Alfaro Luis, C.I.: 23.734.470
González Adrián, C.I.: 24.130.307
Barcelona, julio de 2016
INTRODUCCIÓN
El Proceso Unificado Racional es un proceso de ingeniería del software que
proporciona un acercamiento disciplinado a la asignación de tareas y
responsabilidades en una organización de desarrollo. Su propósito es asegurar la
producción de software de alta calidad que se ajuste a las necesidades de sus
usuarios finales con unos costos y calendario predecibles.
El Proceso Unificado Racional es un modelo del proceso moderno y genérico que se
organiza en fases (inicio, elaboración, construcción y transición).
La fase de elaboración es la encargada de determinar la solución técnica del
proyecto. Así como durante la fase de inicio se determinó el qué, ahora es necesario
el cómo. Es también la Fase de Elaboración el punto de no retorno para el proyecto.
Una vez que dejemos atrás a esta fase y entremos en la construcción, los gastos
serán tan elevados que se tendrá que tener muy en claro el alcance de la apuesta
económica; es mejor detener un proyecto aquí, cuando se ha ejecutado menos del
25% del presupuesto que más adelante, donde los gastos son mucho mayores.
En fin, la fase de elaboración se basa en desarrollar una comprensión del dominio
del problema, establecer un marco de trabajo arquitectónico para el sistema,
desarrollar el plan del proyecto e identificar los riegos claves del proyecto.
RUP - FASE DE ELABORACIÓN
Es está la fase durante la cual elaboramos los requisitos al nivel del diseño y, por
tanto, nos pone en posición de saber si el proyecto es técnicamente viable, así como
conocer la tecnología que vamos a utilizar durante la construcción. El foco de la fase
de elaboración se encuentra en las disciplinas de Diseño y Análisis; ya que estas son
las encargadas de dar con la solución técnica.
La fase de elaboración se centra en la factibilidad, su resultado principal es una
arquitectura estable. Se planifica la fase de construcción con gran precisión.
El equipo debe hacer lo siguiente:
 Crear una línea base para la arquitectura.
 Identificar los riesgos significativos.
 Especificar los niveles a alcanzar por los atributos de calidad.
 Recopilar casos de usos para aproximadamente el 80% de los requisitos
funcionales.
 Preparaunapropuestadela planificación cubierta, personalnecesario y coste.
Propósito
El propósito de la fase de elaboración es analizar el dominio del problema,
establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y
eliminar los mayores riesgos. En esta fase se construye un prototipo de la
arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el
sistema final. Este prototipo debe contener los Casos de Uso críticos identificados en
la fase de inicio. También debe demostrarse que se han evitado los riesgos más
graves.
Objetivos
 Definir, validar y cimentar la arquitectura.
 Completar la visión.
 Crear un plan fiable para la fase de construcción. Este plan puede evolucionar
en sucesivas iteraciones. Debe incluir los costes si procede.
 Demostrar que la arquitectura propuesta soportará la visión con un coste
razonable y en un tiempo razonable.
Para lograr estos objetivos, se adoptará un punto de vista general del sistema. En
algunos casos, en los que los riesgos técnicos predominen, o sean los más
significativos, podemos necesitar profundizar para establecer una arquitectura
sólida. En un proyecto de gran tamaño, se puede, por tanto, necesitar adoptar un
punto de vista enfocado sobre los puntos clave del sistema. Los arquitectos del
sistema deben identificar las partes más peliagudas del mismo tan pronto sea
posible, e iniciar experiencias piloto o prototípicas para identificar y gestionar el
riesgo.
Se tomarán decisionesde la arquitectura basándose en la compresión del sistema en
su totalidad: su ámbito, sus requisitos funcionales y no funcionales, como el
rendimiento.
Hitos de la fase de elaboración
Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se
deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la
siguiente fase, ese hito principal de cada fase se compone de hitos menores que
podrían ser los criterios aplicables a cada iteración. Los hitos para la fase de
elaboración son:
 Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y
actores identificados, la mayoría de los casos desarrollados.
 Requisitos adicionales que capturan los requisitos no funcionales y cualquier
requisito no asociado con un Caso de Uso específico.
 Descripción de la arquitectura software.
 Un prototipo ejecutable de la arquitectura.
 Lista de riesgos y caso de negocio revisados.
 Plan de desarrollo para el proyecto.
 Un caso de desarrollo actualizado que especifica el proceso a seguir.
 Un manual de usuario preliminar (opcional).
 La visión del producto es estable.
 La arquitectura es estable.
 Se ha demostrado mediante la ejecución del prototipo que los principales
elementos de riesgo han sido abordados y resueltos.
 El plan para la fase de construcción es detallado y preciso. Las estimaciones
son creíbles.
 Todos los interesados coinciden en que la visión actual será alcanzada si se
siguen los planes actuales en el contexto de la arquitectura actual.
 Los gastos hasta ahora son aceptables, comparados con los previstos. Si no se
superan los criterios de evaluación quizá sea necesario abandonar el proyecto
o replanteárselo considerablemente.
 Plan para la fase de construcción.
El hito arquitectura del ciclo de vida marca el final de la fase.
Actividades de la fase de elaboración
Actividades críticas
 Especificar los Requerimientos.
 Validar los Requerimientos.
 Validar con Prototipo.
 Priorizar los Requerimientos.
 Definir el Alcance del Sistema.
 Definir Pautas para la Interface de Usuario
 Diseñar el Sistema.
 Describir la Arquitectura del Sistema.
 Comunicar el Diseño a Implementadores
 Planificar la Integración de la Iteración.
 Integrar el Sistema.
 Ajustar y controlar el desarrollo.
 Planificar el Proyecto.
 Gestión de Riesgos.
 Estimaciones y Mediciones.
 Definir la Línea Base del Proyecto.
 Definir y generar el ambiente controlado.
 Planificar la Verificación.
 Especificar los Casos de Prueba.
 Verificación Unitaria.
 Definir Estándares de Doc. de Usuario.
Actividades no críticas
 Planificar la Calidad
 Revisión Técnica Formal (RTF’s)
 Revisar las entregas.
 Revisión de Ajuste al Proceso
 Planificar la Configuración
 Documentación de Usuario
 Planificar la Transición.
 Desarrollar los Materiales para Capacitación.
 Seguimiento de la Línea Base del Proyecto.
Flujo de trabajo de una iteración de la fase de elaboración
Flujo de requisitos
Aquí se establecen las prioridades y se estructuran los casos de usos
Encontrar casos de usos y sus actores
El analista de sistemas identifica casos de uso y actores adicionales a aquellos
identificados en la fase de inicio. Aunque es necesario “comprender” alrededor el
80% de los casos de uso para alcanzar los objetivos de esta fase, no es necesario
“detallar” toda esa cantidad. Se puede identificar casi todos (el 80%), describir
solamente una fracción de ellos, y analizar solo partes de aquellos que describimos.
Desarrollar prototipos de interfaces de usuario
Durantela fase deelaboración solo nospreocuparemosdelas interfaces de usuarios
si son interesantes desde un punto de vista de la arquitectura. Sin embargo, esto es
rara vez el caso, solo en unos pocos casos son las interfaces de usuarios únicas en
algún sentido. Si lo son, podemos tener que crear nuestro propio marco de trabajo
de interfaces de usuario.
Hay una razón adicional para hacer una interfaz de usuario incluso si no es
significativa desde un punto de vista de la arquitectura, es para averiguar si
funciona, utilizando para ello los usuarios reales. Por normal general, no es
necesario desarrollar prototipos de las interfaces de usuario durante la elaboración.
Determinar la prioridad de los casos de uso
Al construir sobre el modelo parcial de casos de uso preparado en la fase de inicio,
perseguimos dos objetivos “completar los casos de usos y trabajar en la línea base
de la arquitectura”. Al principio, invertiremos tiempo en encontrar más casos de
uso, para a continuación dirigir nuestra atención sobre la arquitectura. Sin embargo,
debemos coordinar estos dos objetivos, nuestras decisiones están influenciadas por
las prioridades asociadas a los riesgos percibidos, y por el orden en que decidimos
seguir el desarrollo. A partir del modelo de casos de uso, el arquitecto genera una
vista que se incluye en la descripción.
Detallar un caso de uso
Los encargados de especificar los casos de usos completaran los detalles que sean
necesarios para entender completamente los requisitos y para crear la línea base de
la arquitectura. En esta fase limitaremos nuestros esfuerzos a realizar descripciones
preliminares de casos de uso completos y arquitectónicamente significativos.
Estructurar el modelo de casos de uso
El analista de sistemas revisa lo que ha hecho y busca similitudes, simplificaciones y
oportunidades para mejorar la estructura del modelo de casos de uso. El analista
emplea mecanismos como la extensión o la generalización para lograr el modelo
mejor estructurado y más fácil de entender. Podemos lograr que el modelo sea más
fácil de modificar, ampliar y mantener si por ejemplo se reduce la redundancia.
Aunque a veces el analista no logra descubrir en este momento la mejor estructura.
Puede necesitar hasta más adelante en la iteración.
Artefactos
 Modelo de Casos de Uso: permite que los desarrolladores de software y los
clientes lleguen a un acuerdo con los requisitos. Contiene actores, casos de
usos (uno para cada tipo de usuario, los que se representan por uno o más
actores) y sus relaciones.
 Actor: representan terceros fuera del sistema que colaboran con el sistema,
sirven para identificar el entorno externo al sistema.
 Casos de Uso: es cada unadelas formasen las que los actores usan el sistema.
 Flujo de sucesos: para cada caso de uso puede plasmarse como una
descripción textual de la secuencia de acciones del mismo.
 Requisitos especiales: los requisitos no funcionales sobre el caso de uso.
 Descripción de la Arquitectura: incluyen casos de usos que describan
alguna funcionalidad importante y crítica.
 Glosario: para definir términos comunes e importantes que los analistas y
otros desarrolladores utilizan al describir el sistema.
 Prototipo de Interfaz de Usuario: sirven para comprender y especificar las
interacciones entre los actores humanos y el sistema durante la captura de
requisitos.
Trabajadores
 Analista de Sistemas: responsable del conjunto de requisitos que están
modelados en los casos de uso, incluyendo los funcionales y no funcionales.
Delimita el sistema encontrando los actores y casos de uso.
 Especificador de Casos de Uso: responsable de las descripciones detalladas
de uno o más casos de usos.
 Diseñador de Interfaz de Usuario: dan forma visual a las interfaces de
usuarios.
 Arquitecto: describir la vista de la arquitectura del modelo de casos de uso.
Flujo de análisis
Durante la fase de inicio, se hizo un borrador del modelo de análisis. Ahora
construiremos sobre este borrador, pero podemos descubrir que es necesario
desechar partes sustanciales de él. En la fase de elaboración, necesitamos trabajar
con los casos de uso que son significativos desde un punto de vista de la
arquitectura, y con aquellos casos de uso complejos que necesitemos refinar para
comprender mejor los detalles de la apuesta económica.
En esta sección se abordan las actividades de análisis de la arquitectura, analizar un
caso de uso, analizar una clase y analizar un paquete. En el análisis, necesitamos
ocuparnos de los casos de uso significativo desde un punto de vista de la
arquitectura. También analizaremos los casos de uso para entenderlos de forma
más precisa y para discernir la interferencia de unos con otros.
Análisis de la arquitectura
En la fase de inicio se realiza el análisis de la arquitectura hasta el extremo de
determinar que había una arquitectura factible. Ahora, en la fase de elaboración,
tenemos que extender el análisis de la arquitectura hasta el extremo de que pueda
servir de base a una línea base de la arquitectura ejecutable.
Con este propósito, el arquitecto realiza una partición inicial del sistema en
paquetes de análisis, trabajando sobre la vista de la arquitectura del modelo de
casos de uso, los requisitos relacionados con ellos, el glosario, y el conocimiento del
dominio. Para ello, puede emplear una arquitectura en capas, identificando los
paquetes específicos de la aplicación y los paquetes generales.
Analizar un caso de uso.
Muchos casos de usos no son claramente comprensibles tal y como están descritos
en el modelo de casos de uso. Los casos de uso deben ser refinados en funciones de
las clases del análisis que existen en el ámbito de los requisitos pero que no se
implementan necesariamente de forma directa. Esta necesidad de refinamiento es
particularmente aguda para los casos de uso complejos, y para aquellos que tienen
impacto en otros, es decir, para los caos de uso que son dependientes unos de otros.
Los casos de uso interesantes desde el punto de vista de la arquitectura, junto con
los casos deuso cuya comprensión esimportante, deben ser refinadosen función de
estas clases del análisis. Los otros casos de uso, los que no son interesantes desde la
perspectivade la arquitectura o dela comprensión delos requisitos, no se refinan ni
se analizan. Para estos casos de uso, los ingenieros de casos de uso solo necesitan
una comprensión de lo que son, y del hecho de que no tendrán impacto. Sabrán
cómo tratar con ellos cuando sea la hora de implementarlos durante la fase de
construcción.
Analizar una clase.
Los ingenieros de componentes deberán refinar las clases identificadas
anteriormente, mezclando las responsabilidades que han sido asignadas a estas
clases desde diferentes casos de uso. También identificaran los mecanismos de
análisis disponibles y averiguaran como son utilizados por cada clase.
Analizar un paquete.
El arquitecto meditara sobre los servicios del sistema y sobre el agrupamiento de
clases en paquetes de servicio. Esto se hará en la actividad de análisis de la
arquitectura, dada esta agrupación en paquetes de servicio, los ingenieros de
componentes asumirán la responsabilidad de los paquetes, su refinamiento y
mantenimiento.
Artefactos
 Modelo de Análisis: se representa mediante un sistema de análisis que
denota el paquete de más alto nivel del modelo. Los casos de uso se
representan mediante clases de análisis y sus objetos.
 Clases de Análisis: representa una abstracción de una a varias clases y/o
subsistemas del diseño del sistema. Características:
o Se centra en el tratamiento de los requisitos funcionales y pospone los
no funcionales.
o Más conceptual.
o Su comportamiento se define mediante responsabilidades (descripción
textual del comportamiento de una clase).
o Define atributos.
o Participa en relaciones, a nivel conceptual.
o Encajan en uno detres estereotipos: deinterfaz, de entidad o de control.
 Clases de Interfaz: modelan la interacción entre el sistema y sus actores.
 Clases de Entidad: modelan información que posee vida larga y que es a
menudo persistente.
 Clases de Control: encapsular el control de un caso de uso concreto,
representan coordinación, secuencia, transacciones y control de otros objetos.
 Diagramas de Clases: una clase de análisis y sus objetos normalmente
participan en varias realizaciones de casos de uso, y algunas
responsabilidades, atributos y asociaciones de una clase concreta suelen ser
solo relevantes para una única realización de caso de uso.
 Diagramas de Interacción: muestra las interacciones entre objetos creando
enlaces entre ellos y añadiéndole mensajes.
 Flujo de Sucesos – Análisis: texto adicional que explican los diagramas
(especialmente los de colaboración).
 Requisitos especiales: descripciones textuales que recogen todos los
requisitos no funcionales sobre una realización de caso de uso.
 Paquete del Análisis: proporcionaun medio para organizar los artefactos del
modelo de análisis. Puede constar de clases de análisis, de realizaciones de
casos de usos y de otros paquetes recursivamente. Características:
o Pueden representar una separación de intereses de análisis.
o Deben crearse basándose en los requisitos funcionales y en el dominio
del problema.
o Probablemente se convertirán en subsistemas en las dos capas de
aplicación superiores.
 Paquetes de Servicio: se utilizan para estructurar el sistema de acuerdo a los
servicios que proporciona el sistema. Características:
o Contiene un conjunto de clases relacionadas funcionalmente.
o Es indivisible.
o En un caso de uso puede participar uno o más paquetes.
o A menudo depende de otro paquete de servicio.
o Normalmente es relevante para uno o unos pocos actores.
o Pueden ser mutuamente excluyentes.
o Constituyen una entrada fundamenta para las actividades de diseño e
implementación.
o Son reutilizables.
 Descripción de la Arquitectura (vista del modelo de análisis): contiene
una vista de la arquitectura del modelo de análisis.
Trabajadores
 Arquitecto: es responsable de la integridad del modelo de análisis,
garantizando que este sea correcto, consistente y legible como un todo.
 Ingeniero de Casos de Uso: es el responsable de la integridad de una o más
realizaciones de caso de uso, garantizando que cumplen los requisitos que
caen sobre ellos.
 Ingeniero de Componentes: define y mantiene las responsabilidades,
atributos, relaciones y requisitos especiales de una o varias clases del análisis.
También mantiene la integridad de uno o varios paquetes del análisis.
Flujo de diseño
En esta fase de elaboración se diseñará desde un punto de vista arquitectónico. Esto
quiere decir que se diseñara los casos de usos, clases y subsistemas que sean
arquitectónicamente significativos.
Diseñar un caso de uso
En el diseño de caso de uso, se especificarán las operaciones usadas para la
comunicación, además, se necesitará tener en cuenta que subsistemas, marcos de
trabajos o sistemas se van a reutilizar, y a continuación que operaciones
proporcionan.
Diseñar una clase
Se diseñará las clases que participaron en las realizaciones de los casos de uso del
paso anterior.
Diseñar un subsistema
Los ingenieros decomponentesdiseñan los subsistemas resultantes del diseño de la
arquitectura. Durante esta fase, el arquitecto actualizara, si es necesaria la vista del
modelo de diseño.
El diseño es el centro de atención al final de la fase de elaboración y al comienzo de
las iteraciones de la construcción. El modelo de diseño está muy cercano al de
implementación.
Artefactos
 Modelo de Diseño: es un modelo de objetos que describe la realización física
de los casos de uso centrándose en cómo los requisitos funcionales y no
funcionales tienen un impacto en el sistema.
 Clase del Diseño: es unaabstracción sin costuras deuna clase. Es sin costuras
en el siguiente sentido:
o El lenguaje utilizado para especificarla es el mismo que el lenguaje de
programación.
o La visibilidad de los atributos y las operaciones se especifican con
frecuencia.
o Los métodos tienen correspondencia directa con el correspondiente
método en la implementación de las clases.
 Realización de Casos de Uso - Diseño: es una colaboración que describe
cómo se realiza un caso de uso específico y como se ejecuta en términos de
clases de diseño y sus objetos.
 Diagramas de Clases: una clase de diseño con sus objetos, además de los
subsistemas que contienen las clases de diseño, que participan en las
realizaciones de casos de uso.
 Diagramas de Interacción: es preferible representarlo con el diagrama de
secuencia en donde se muestre las interacciones entre objetos mediante
transferencia de mensajes entre objetos o subsistemas.
 Requisitos de la implementación: descripción textual que recoge requisitos
tales como los no funcionales.
 Subsistema de Diseño: forma de organizar los artefactos del modelo de
diseño en piezas más manejables. Características:
o Pueden representar una separación de aspectos del diseño.
o Los subsistemas de las dos capas de aplicación de más alto nivel tienen
trazas directas hacia paquetes y/o clases del análisis.
o Pueden representar componentes de grano grueso en la
implementación.
o Pueden representar productos software reutilizados.
o Pueden representar sistemas heredados.
 Subsistemas de servicio: sebasan en los paquetes de serviciosdel modelo de
análisis, y normalmente existe una traza uno a uno. Tratan más aspectos que
los paquetes por:
o Pueden tener que ofrecer sus servicios en términos de interfaces y de
sus operaciones.
o Contienen clases de diseño en vez de clase de análisis.
o Suele dar lugar a un componente ejecutable o binario en la
implementación.
 Interfaz: para especificar las operaciones que proporcionan las clases y
subsistemas de diseño.
 Descripciónde la Arquitectura(vista del modelo de diseño): contiene una
vista de la arquitectura del modelo de diseño.
 Modelo de Despliegue: es un modelo de objetos que describe la distribución
física delsistema en términos de cómo se distribuye la funcionalidad entre los
nodos del cómputo. Se puede observar:
o Cada nodo representa un recurso de computo.
o Los nodos poseen relaciones que representan medios de comunicación
entre ellos.
o Puede describir diferentes configuraciones de red.
o La funcionalidad de un nodo se define por los componentes que se
distribuyen sobre él.
o Representa una correspondencia entre a arquitectura software y la
arquitectura del sistema.
 Descripciónde la Arquitectura(vista del modelo de despliegue): contiene
una vista de la arquitectura del modelo de despliegue.
Trabajadores
 Arquitecto: responsable de la integridad de los modelos del diseño y de
despliegue.
 Ingenieros de Casos de Uso: es el responsable de la integridad de una o más
realizaciones de caso de uso - diseño.
 Ingeniero de Componentes: define y mantiene las operaciones, atributos,
relaciones y requisitos especiales de una o varias clases del diseño. También
mantiene la integridad de uno o varios subsistemas del diseño.
Flujo de implementación
Este flujo de trabajo implementa y prueba los componentes arquitectónicamente
significativos a partir de los elementos de diseño significativos. El resultado es la
base de la arquitectura, implementada normalmente a partir de menos del 10 por
ciento de los casos de uso. El responsable de integrar el sistema establece la
secuencia de integración en un plan de integración y a continuación integra los
subsistemas y los componentes correspondientes en una línea base de la
arquitectura ejecutable. Su propósito es:
 Planificar las integraciones del sistema en cada iteración.
 Distribuir el sistema asignando componentes ejecutables a nodos en el
diagrama de despliegue.
 Implementar las clases y subsistemas encontrados durante el diseño.
 Probar los componentes individualmente y luego integrarlos.
 La implementación es el centro durante las iteraciones de construcción,
aunque también se lleva a cabo en la fase de elaboración (para crear la línea
base ejecutable de la arquitectura) y durante la transición (para tratar
defectos tardíos).
Artefactos
 Modelo de Implementación: describe cómo los elementos del modelo de
diseño se implementan en términos de componentes.
 Componente: es el empaquetamiento físico de los elementos de un modelo.
Características:
o Tienen relaciones de traza con los elementos del modelo que
implementan.
o Normalmente implementan varios elementos.
 Subsistema de Implementación: proporcionan una forma de organizar los
artefactos del modelo de implementación en trozos más manejables. Se
manifiesta a través de un mecanismo de empaquetamiento. Deberá:
o Definir dependencias análogas hacia otros subsistemas de
implementación.
o Proporcionar las mismas interfaces.
 Interfaz: especificar las operaciones implementadas por componentes y
subsistemas de implementación.
 Descripción de la Arquitectura (vista del modelo de implementación):
contiene una vista de la arquitectura del modelo de implementación.
Trabajadores
 Arquitecto: responsablede la integridad de los modelos de implementación y
despliegue.
 Ingeniero de Componentes: define y mantiene el código fuente de uno o
varios componentes. También mantiene la integridad de uno o varios
subsistemas de implementación. Realiza pruebas de unidad.
 Integrador de Sistema: planifica la secuencia de construcciones necesarias
en cada iteración (dando lugar al plan de integración) y la integración de cada
construcción.
Flujo de prueba
Aquí el objetivo es asegurarse de que los subsistemas de todos los niveles
(subsistemas de servicio y subsistemas del diseño) y de todas las capas (desde la
capa del sistema hasta las capas específicas de la aplicación) funcionen. Por
supuesto, sólo podemos probar los componentes ejecutables.
Durante este flujo se:
 Busca los defectos a lo largo del ciclo de vida.
 Verifica el resultado de la implementación.
 Planifican las pruebas necesarias en cada iteración.
 Diseña e implementa los casos de prueba que especifican que probar.
 Realizan diferentes pruebas y manejan los resultados de estas
sistemáticamente.
 Prueban los componentes individualmente para luego integrarlos.
Artefactos
 Modelo de Pruebas: describe cómo se prueban los componentes ejecutables.
 Caso de Prueba: especifica una forma de probar el sistema, incluyendo la
entrada o resultado con la que sea de probar. Casos de prueba:
o Uno que especifique como probar un caso de uso o un escenario
especifico de un caso de uso. Sería una prueba del sistema como caja
negra.
o Uno que especifique como probar una realización de caso de uso –
diseño. Sería una prueba de caja blanca.
 Procedimiento de Prueba: especifica cómo realizar uno a varios casos de
prueba o partes de estos.
 Componente de Prueba: automatiza uno o varios procedimientos de prueba
prueban componentes en el modelo de implementación.
 Plan de Prueba: describe las estrategias, recursos y planificación de la
prueba.
 Defecto: es una anomalía del sistema, como un síntoma de fallo de software.
 Evaluación de Prueba: la evaluación de los resultados de los esfuerzos de
prueba.
Trabajadores
 Diseñador de Pruebas: responsable de la integridad de pruebas.
 Ingeniero de Componentes: responsable de los componentes de prueba que
automatizan algunos de los procedimientos de prueba.
 Ingeniero de Pruebas de Integración: responsables de realizar las pruebas
de integración que se necesitan para cada construcción producida en el flujo
de trabajo de implementación.
 Ingeniero de Pruebas de Sistema: responsable de realizar las pruebas de
sistema necesarias sobre una construcción que muestra el resultado de una
iteración completa.
Importancia de la fase de elaboración en el desarrollo de software
Esta fase es importante porque:
 Establece una base de la arquitectura sólida para guiar el trabajo durante las
fases de construcción y transición, así como en las posteriores generaciones
del sistema.
 Recopila la mayor parte de los requisitos que aun queden pendientes,
formulando los requisitos funcionales como casos de uso.
 Continua la observación y control de los riesgos críticos que aun queden, e
identifica los riesgos significativos hasta el punto de que podamos estimar su
impacto en el análisis de negocio, y en particular en la apuesta económica.
CONCLUSIÓN
En esta fase, se obtiene un entendimiento más detallado de los requerimientos, se
procede a diseñar, implementar, validar y generar una línea base para la
arquitectura. Se definen los subsistemas, los componentes clave y sus interfaces; se
usan los casos de uso significantes arquitectónicamente para dirigir la arquitectura.
Se consolidan y empaquetan las clases identificadas. Se diseña la Base de datos. Se
implementan y prueban los escenarios críticos. Se debe mitigar los riesgos
esenciales y producir un plan de desarrollo más preciso. Se elabora el artefacto de
arquitectura el cual contempla todo el diseño de la arquitectura.
La fase de elaboración es tan importante como las otras fases en el proceso de
desarrollo de software, vemos que en esta fase se acrecienta el entorno de
desarrollo, no solo para llevar a cabo las actividades de esta fase, sino para estar
preparados para la fase de construcción.
Los flujos de trabajo que más importancia y presencia tienen en esta fase son las de
análisis y diseño. Además, en esta fase se habrá acumulado la información necesaria
para planificar la fase de construcción.
También, tendremos información suficiente para realizar un análisis de negocio
fiable, trabajo que se comienza durante la fase de inicio, para evaluar si el proyecto
vale la pena, recordemos que luego de esta fase, no hay vuelta atrás, ya que los
gastos generados serán mucho mayores, a diferencia de dejarlo en este punto.

Mais conteúdo relacionado

Mais procurados

Calidad de Software
Calidad de SoftwareCalidad de Software
Calidad de SoftwareAnaMelba MH
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónYare LoZada
 
Cuadro comparativo metodos
Cuadro comparativo metodosCuadro comparativo metodos
Cuadro comparativo metodosivansierra20
 
Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2David Motta Baldarrago
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicoslandeta_p
 
Modelo basado en prototipos - Ingeniería de Software
Modelo basado en prototipos - Ingeniería de SoftwareModelo basado en prototipos - Ingeniería de Software
Modelo basado en prototipos - Ingeniería de SoftwareJoan Fernando Chipia Lobo
 
UML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseUML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseGuillermo Díaz
 
Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)programadorjavablog
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional CristobalFicaV
 
Tabla comparativa- metodologías de desarrollo
Tabla comparativa-  metodologías de desarrolloTabla comparativa-  metodologías de desarrollo
Tabla comparativa- metodologías de desarrolloitsarellano
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoJuan Pablo Bustos Thames
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRequisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRene Guaman-Quinche
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 CapasFani Calle
 

Mais procurados (20)

Calidad de Software
Calidad de SoftwareCalidad de Software
Calidad de Software
 
Requerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicaciónRequerimientos funcionales y no funcionales de la aplicación
Requerimientos funcionales y no funcionales de la aplicación
 
Ingeniería de software modelo incremental
Ingeniería de software  modelo incrementalIngeniería de software  modelo incremental
Ingeniería de software modelo incremental
 
Cuadro comparativo metodos
Cuadro comparativo metodosCuadro comparativo metodos
Cuadro comparativo metodos
 
Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2Modelo Del Negocio con RUP y UML Parte 2
Modelo Del Negocio con RUP y UML Parte 2
 
Casos de uso
Casos de usoCasos de uso
Casos de uso
 
2 2 estilos arquitectonicos
2 2 estilos arquitectonicos2 2 estilos arquitectonicos
2 2 estilos arquitectonicos
 
Modelo basado en prototipos - Ingeniería de Software
Modelo basado en prototipos - Ingeniería de SoftwareModelo basado en prototipos - Ingeniería de Software
Modelo basado en prototipos - Ingeniería de Software
 
UML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de ClaseUML - Casos de Uso y Diagramas de Clase
UML - Casos de Uso y Diagramas de Clase
 
Modelos de dominio
Modelos de dominioModelos de dominio
Modelos de dominio
 
Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)Patrones de diseño(presentación 7)
Patrones de diseño(presentación 7)
 
Estimación Software por Puntos de Función
Estimación Software por Puntos de FunciónEstimación Software por Puntos de Función
Estimación Software por Puntos de Función
 
Metodologia Incremental
Metodologia IncrementalMetodologia Incremental
Metodologia Incremental
 
Requerimiento funcional y no funcional
Requerimiento funcional y no funcional Requerimiento funcional y no funcional
Requerimiento funcional y no funcional
 
Tabla comparativa- metodologías de desarrollo
Tabla comparativa-  metodologías de desarrolloTabla comparativa-  metodologías de desarrollo
Tabla comparativa- metodologías de desarrollo
 
Scrum vs RUP
Scrum vs RUPScrum vs RUP
Scrum vs RUP
 
Primeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de usoPrimeros artefactos de análisis. casos de uso
Primeros artefactos de análisis. casos de uso
 
Requisitos funcionales y no funcionales
Requisitos funcionales y no funcionalesRequisitos funcionales y no funcionales
Requisitos funcionales y no funcionales
 
Ejemplo rup
Ejemplo rupEjemplo rup
Ejemplo rup
 
Arquitectura 3 Capas
Arquitectura 3 CapasArquitectura 3 Capas
Arquitectura 3 Capas
 

Destaque

(02 2011) eis-pead-is-(ep virtual) (rezagados 02)
(02 2011) eis-pead-is-(ep virtual) (rezagados 02)(02 2011) eis-pead-is-(ep virtual) (rezagados 02)
(02 2011) eis-pead-is-(ep virtual) (rezagados 02)Jaime Javier Campos Vega
 
Gestion por procesos con mediciones y mejora
Gestion por procesos con mediciones y mejoraGestion por procesos con mediciones y mejora
Gestion por procesos con mediciones y mejoramixilupe
 
Sistemas críticos - Ingeniería de Sistemas
Sistemas críticos - Ingeniería de SistemasSistemas críticos - Ingeniería de Sistemas
Sistemas críticos - Ingeniería de SistemasUniminuto - San Francisco
 
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motorsIso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motorsEduhardo Rodrigez Rosales
 
Errores Clasicos
Errores ClasicosErrores Clasicos
Errores ClasicosActimel
 
Inge.de.software clase 2
Inge.de.software  clase 2Inge.de.software  clase 2
Inge.de.software clase 2Oscar Martinez
 
Métricas de Seguridad
Métricas de Seguridad Métricas de Seguridad
Métricas de Seguridad jose_calero
 
Trabajo ciclo de vida del software
Trabajo ciclo de vida del softwareTrabajo ciclo de vida del software
Trabajo ciclo de vida del softwareagtagt
 
Computacion i examen parcial pead 2013 0 huaroto yupanqui maribel
Computacion i examen parcial pead 2013 0 huaroto yupanqui maribelComputacion i examen parcial pead 2013 0 huaroto yupanqui maribel
Computacion i examen parcial pead 2013 0 huaroto yupanqui maribelHYUPANQUIM
 
Fases de RUP - PDF
Fases de RUP - PDFFases de RUP - PDF
Fases de RUP - PDFradoslawkb
 
Ejemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupEjemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupXochitl Saucedo Muñoz
 

Destaque (13)

Metodologia rup
Metodologia rupMetodologia rup
Metodologia rup
 
(02 2011) eis-pead-is-(ep virtual) (rezagados 02)
(02 2011) eis-pead-is-(ep virtual) (rezagados 02)(02 2011) eis-pead-is-(ep virtual) (rezagados 02)
(02 2011) eis-pead-is-(ep virtual) (rezagados 02)
 
Gestion por procesos con mediciones y mejora
Gestion por procesos con mediciones y mejoraGestion por procesos con mediciones y mejora
Gestion por procesos con mediciones y mejora
 
Sistemas críticos - Ingeniería de Sistemas
Sistemas críticos - Ingeniería de SistemasSistemas críticos - Ingeniería de Sistemas
Sistemas críticos - Ingeniería de Sistemas
 
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motorsIso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
Iso112 evaluacion a distancia (2012 0) (ed 02) (rpta) mundo motors
 
Errores Clasicos
Errores ClasicosErrores Clasicos
Errores Clasicos
 
Inge.de.software clase 2
Inge.de.software  clase 2Inge.de.software  clase 2
Inge.de.software clase 2
 
Métricas de Seguridad
Métricas de Seguridad Métricas de Seguridad
Métricas de Seguridad
 
Trabajo ciclo de vida del software
Trabajo ciclo de vida del softwareTrabajo ciclo de vida del software
Trabajo ciclo de vida del software
 
Computacion i examen parcial pead 2013 0 huaroto yupanqui maribel
Computacion i examen parcial pead 2013 0 huaroto yupanqui maribelComputacion i examen parcial pead 2013 0 huaroto yupanqui maribel
Computacion i examen parcial pead 2013 0 huaroto yupanqui maribel
 
Fases de RUP - PDF
Fases de RUP - PDFFases de RUP - PDF
Fases de RUP - PDF
 
Ejemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rupEjemplo plan de desarrollo de software rup
Ejemplo plan de desarrollo de software rup
 
Cis 1 05
Cis 1 05Cis 1 05
Cis 1 05
 

Semelhante a RUP - Fase de Elaboración

Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de softJazmin Cr
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareClare Rodriguez
 
Unidad 4 Modelos de Procesos del Software
Unidad 4 Modelos de Procesos del SoftwareUnidad 4 Modelos de Procesos del Software
Unidad 4 Modelos de Procesos del Softwarerezzaca
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de softwareAdes27
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaamendez45
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de softwareUVM
 
Metodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacionMetodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacioncaroyu
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareAndhy H Palma
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareAndhy H Palma
 
Métodos de la ingeniería
Métodos de la ingenieríaMétodos de la ingeniería
Métodos de la ingenieríaSam Stgo
 
Carrera de informatica_educativa
Carrera de informatica_educativaCarrera de informatica_educativa
Carrera de informatica_educativaDiego Sinche
 

Semelhante a RUP - Fase de Elaboración (20)

Rup
RupRup
Rup
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Metodologia msf
Metodologia msfMetodologia msf
Metodologia msf
 
Desarrollo de Sistemas de Información
Desarrollo de Sistemas de InformaciónDesarrollo de Sistemas de Información
Desarrollo de Sistemas de Información
 
Modelos de Ing de soft
Modelos de Ing de softModelos de Ing de soft
Modelos de Ing de soft
 
Rup
RupRup
Rup
 
Metodologia merinde y rup
Metodologia merinde y rupMetodologia merinde y rup
Metodologia merinde y rup
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
Unidad 4 Modelos de Procesos del Software
Unidad 4 Modelos de Procesos del SoftwareUnidad 4 Modelos de Procesos del Software
Unidad 4 Modelos de Procesos del Software
 
Tecnicas de estimacion de software
Tecnicas de estimacion de softwareTecnicas de estimacion de software
Tecnicas de estimacion de software
 
RUP
RUPRUP
RUP
 
Proceso unificado
Proceso unificadoProceso unificado
Proceso unificado
 
Modelo de cascadaa
Modelo de cascadaaModelo de cascadaa
Modelo de cascadaa
 
1 ingeniería de software
1 ingeniería de software1 ingeniería de software
1 ingeniería de software
 
Metodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacionMetodos del desarrollo de sistema de informacion
Metodos del desarrollo de sistema de informacion
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
 
Unidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de softwareUnidad 3 los modelos de procesos de software
Unidad 3 los modelos de procesos de software
 
Métodos de la ingeniería
Métodos de la ingenieríaMétodos de la ingeniería
Métodos de la ingeniería
 
Carrera de informatica_educativa
Carrera de informatica_educativaCarrera de informatica_educativa
Carrera de informatica_educativa
 

Último

Reglamento de Relevamientos estructurales 2023.pdf
Reglamento de Relevamientos estructurales 2023.pdfReglamento de Relevamientos estructurales 2023.pdf
Reglamento de Relevamientos estructurales 2023.pdfAndyMarcaFuentes
 
2.8 Comandos generales de alta y baja del SGBD
2.8 Comandos generales de alta y baja del SGBD2.8 Comandos generales de alta y baja del SGBD
2.8 Comandos generales de alta y baja del SGBDEmanuelMuoz11
 
2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...
2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...
2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...PedroSantos958708
 
Prueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñ
Prueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñPrueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñ
Prueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñElvisEnrique7
 
COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1
COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1
COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1NatashaSolano5
 
SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)
SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)
SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)aluque
 
BLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSAS
BLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSASBLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSAS
BLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSASseguridadindustrial51
 
Trabajo para el 2do1111111111. examen.pdf
Trabajo para el 2do1111111111. examen.pdfTrabajo para el 2do1111111111. examen.pdf
Trabajo para el 2do1111111111. examen.pdffredyflores58
 
GUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptx
GUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptxGUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptx
GUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptxDilmer Eddy Laime Ramos
 
Iniciaciòn y Aprendizaje del idioma cobol
Iniciaciòn y Aprendizaje del  idioma cobolIniciaciòn y Aprendizaje del  idioma cobol
Iniciaciòn y Aprendizaje del idioma cobolRoberto Bellido
 
solucionario chopra 4ta edicion solucionario
solucionario chopra 4ta edicion solucionariosolucionario chopra 4ta edicion solucionario
solucionario chopra 4ta edicion solucionarioMarvin Flores
 
EQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIA
EQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIAEQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIA
EQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIASELENEGUZMAN4
 
CONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDAD
CONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDADCONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDAD
CONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDADMaestroMatematicas
 
Turismo-Comunitario. casckkjaskkakaskkaskkas
Turismo-Comunitario. casckkjaskkakaskkaskkasTurismo-Comunitario. casckkjaskkakaskkaskkas
Turismo-Comunitario. casckkjaskkakaskkaskkasingestoracultural1
 
1.3 Captura básica de cadenas en ensamblador.pptx
1.3 Captura básica de cadenas en ensamblador.pptx1.3 Captura básica de cadenas en ensamblador.pptx
1.3 Captura básica de cadenas en ensamblador.pptxEmanuelMuoz11
 
l12_sistemas_de_tiempos_predeterminados.pdf
l12_sistemas_de_tiempos_predeterminados.pdfl12_sistemas_de_tiempos_predeterminados.pdf
l12_sistemas_de_tiempos_predeterminados.pdfdulcemartinezalmenda
 
Introducción a la Informática Forensemelissa - copia.pptx
Introducción a la Informática Forensemelissa - copia.pptxIntroducción a la Informática Forensemelissa - copia.pptx
Introducción a la Informática Forensemelissa - copia.pptxKarinaRamirez16146
 
PENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLE
PENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLEPENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLE
PENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLErene2105
 
Este método de ensayo cubre la estimación de la capacidad portante del suelo ...
Este método de ensayo cubre la estimación de la capacidad portante del suelo ...Este método de ensayo cubre la estimación de la capacidad portante del suelo ...
Este método de ensayo cubre la estimación de la capacidad portante del suelo ...josetuanama2
 

Último (20)

Reglamento de Relevamientos estructurales 2023.pdf
Reglamento de Relevamientos estructurales 2023.pdfReglamento de Relevamientos estructurales 2023.pdf
Reglamento de Relevamientos estructurales 2023.pdf
 
2.8 Comandos generales de alta y baja del SGBD
2.8 Comandos generales de alta y baja del SGBD2.8 Comandos generales de alta y baja del SGBD
2.8 Comandos generales de alta y baja del SGBD
 
2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...
2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...
2.5y 2.6.pptx maquinaria pesada para pavimentación y maquinaria pesada para c...
 
Prueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñ
Prueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñPrueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñ
Prueba-modelo-de-CTA (2).pdfkmkldklcmdaslñmcdñlamcñldmcñ
 
COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1
COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1
COMUNICACION ARQUITECTONICA 1 INTRODUCCION A LA COMUNICACION ARQUITECTONICA 1 1
 
SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)
SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)
SDH: Synchronous Digital Hierarchy (Jerarquía Digital Sincrónica)
 
BLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSAS
BLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSASBLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSAS
BLOQUEO Y ETIQUETADO DE ENERGIAS PELIGROSAS
 
Trabajo para el 2do1111111111. examen.pdf
Trabajo para el 2do1111111111. examen.pdfTrabajo para el 2do1111111111. examen.pdf
Trabajo para el 2do1111111111. examen.pdf
 
GUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptx
GUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptxGUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptx
GUIA DEL PROGRAMA AUTODESK INVENTOR 2020.pptx
 
Iniciaciòn y Aprendizaje del idioma cobol
Iniciaciòn y Aprendizaje del  idioma cobolIniciaciòn y Aprendizaje del  idioma cobol
Iniciaciòn y Aprendizaje del idioma cobol
 
solucionario chopra 4ta edicion solucionario
solucionario chopra 4ta edicion solucionariosolucionario chopra 4ta edicion solucionario
solucionario chopra 4ta edicion solucionario
 
EQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIA
EQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIAEQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIA
EQUIPOS E IMPLEMENTOS PARA LABRANZA PRIMARIA
 
CONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDAD
CONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDADCONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDAD
CONCEPTOS BASICOS DE ARDUINO EN ELECTRICIDAD
 
Turismo-Comunitario. casckkjaskkakaskkaskkas
Turismo-Comunitario. casckkjaskkakaskkaskkasTurismo-Comunitario. casckkjaskkakaskkaskkas
Turismo-Comunitario. casckkjaskkakaskkaskkas
 
REGULARIZACIONES CASABLANCA +56941055309
REGULARIZACIONES CASABLANCA +56941055309REGULARIZACIONES CASABLANCA +56941055309
REGULARIZACIONES CASABLANCA +56941055309
 
1.3 Captura básica de cadenas en ensamblador.pptx
1.3 Captura básica de cadenas en ensamblador.pptx1.3 Captura básica de cadenas en ensamblador.pptx
1.3 Captura básica de cadenas en ensamblador.pptx
 
l12_sistemas_de_tiempos_predeterminados.pdf
l12_sistemas_de_tiempos_predeterminados.pdfl12_sistemas_de_tiempos_predeterminados.pdf
l12_sistemas_de_tiempos_predeterminados.pdf
 
Introducción a la Informática Forensemelissa - copia.pptx
Introducción a la Informática Forensemelissa - copia.pptxIntroducción a la Informática Forensemelissa - copia.pptx
Introducción a la Informática Forensemelissa - copia.pptx
 
PENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLE
PENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLEPENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLE
PENDOLADOS ADIF.pdf NORMAS DE CATENARIA FLEXIBLE
 
Este método de ensayo cubre la estimación de la capacidad portante del suelo ...
Este método de ensayo cubre la estimación de la capacidad portante del suelo ...Este método de ensayo cubre la estimación de la capacidad portante del suelo ...
Este método de ensayo cubre la estimación de la capacidad portante del suelo ...
 

RUP - Fase de Elaboración

  • 1. UNIVERSIDAD DE ORIENTE NÚCLEO DE ANZOÁTEGUI ESCUELA DE INGENIERIA Y CIENCIAS APLICADAS DEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS CÁTEDRA: DESARROLLO DE SOFWARE RUP FASE DE ELABORACIÓN Integrantes: Alfaro Luis, C.I.: 23.734.470 González Adrián, C.I.: 24.130.307 Barcelona, julio de 2016
  • 2. INTRODUCCIÓN El Proceso Unificado Racional es un proceso de ingeniería del software que proporciona un acercamiento disciplinado a la asignación de tareas y responsabilidades en una organización de desarrollo. Su propósito es asegurar la producción de software de alta calidad que se ajuste a las necesidades de sus usuarios finales con unos costos y calendario predecibles. El Proceso Unificado Racional es un modelo del proceso moderno y genérico que se organiza en fases (inicio, elaboración, construcción y transición). La fase de elaboración es la encargada de determinar la solución técnica del proyecto. Así como durante la fase de inicio se determinó el qué, ahora es necesario el cómo. Es también la Fase de Elaboración el punto de no retorno para el proyecto. Una vez que dejemos atrás a esta fase y entremos en la construcción, los gastos serán tan elevados que se tendrá que tener muy en claro el alcance de la apuesta económica; es mejor detener un proyecto aquí, cuando se ha ejecutado menos del 25% del presupuesto que más adelante, donde los gastos son mucho mayores. En fin, la fase de elaboración se basa en desarrollar una comprensión del dominio del problema, establecer un marco de trabajo arquitectónico para el sistema, desarrollar el plan del proyecto e identificar los riegos claves del proyecto.
  • 3. RUP - FASE DE ELABORACIÓN Es está la fase durante la cual elaboramos los requisitos al nivel del diseño y, por tanto, nos pone en posición de saber si el proyecto es técnicamente viable, así como conocer la tecnología que vamos a utilizar durante la construcción. El foco de la fase de elaboración se encuentra en las disciplinas de Diseño y Análisis; ya que estas son las encargadas de dar con la solución técnica. La fase de elaboración se centra en la factibilidad, su resultado principal es una arquitectura estable. Se planifica la fase de construcción con gran precisión. El equipo debe hacer lo siguiente:  Crear una línea base para la arquitectura.  Identificar los riesgos significativos.  Especificar los niveles a alcanzar por los atributos de calidad.  Recopilar casos de usos para aproximadamente el 80% de los requisitos funcionales.  Preparaunapropuestadela planificación cubierta, personalnecesario y coste. Propósito El propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves. Objetivos  Definir, validar y cimentar la arquitectura.  Completar la visión.  Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede.  Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable.
  • 4. Para lograr estos objetivos, se adoptará un punto de vista general del sistema. En algunos casos, en los que los riesgos técnicos predominen, o sean los más significativos, podemos necesitar profundizar para establecer una arquitectura sólida. En un proyecto de gran tamaño, se puede, por tanto, necesitar adoptar un punto de vista enfocado sobre los puntos clave del sistema. Los arquitectos del sistema deben identificar las partes más peliagudas del mismo tan pronto sea posible, e iniciar experiencias piloto o prototípicas para identificar y gestionar el riesgo. Se tomarán decisionesde la arquitectura basándose en la compresión del sistema en su totalidad: su ámbito, sus requisitos funcionales y no funcionales, como el rendimiento. Hitos de la fase de elaboración Cada fase se concluye con un hito bien definido, un punto en el tiempo en el cual se deben tomar ciertas decisiones críticas y alcanzar las metas clave antes de pasar a la siguiente fase, ese hito principal de cada fase se compone de hitos menores que podrían ser los criterios aplicables a cada iteración. Los hitos para la fase de elaboración son:  Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y actores identificados, la mayoría de los casos desarrollados.  Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso específico.  Descripción de la arquitectura software.  Un prototipo ejecutable de la arquitectura.  Lista de riesgos y caso de negocio revisados.  Plan de desarrollo para el proyecto.  Un caso de desarrollo actualizado que especifica el proceso a seguir.  Un manual de usuario preliminar (opcional).  La visión del producto es estable.  La arquitectura es estable.  Se ha demostrado mediante la ejecución del prototipo que los principales elementos de riesgo han sido abordados y resueltos.  El plan para la fase de construcción es detallado y preciso. Las estimaciones son creíbles.  Todos los interesados coinciden en que la visión actual será alcanzada si se siguen los planes actuales en el contexto de la arquitectura actual.
  • 5.  Los gastos hasta ahora son aceptables, comparados con los previstos. Si no se superan los criterios de evaluación quizá sea necesario abandonar el proyecto o replanteárselo considerablemente.  Plan para la fase de construcción. El hito arquitectura del ciclo de vida marca el final de la fase. Actividades de la fase de elaboración Actividades críticas  Especificar los Requerimientos.  Validar los Requerimientos.  Validar con Prototipo.  Priorizar los Requerimientos.  Definir el Alcance del Sistema.  Definir Pautas para la Interface de Usuario  Diseñar el Sistema.  Describir la Arquitectura del Sistema.  Comunicar el Diseño a Implementadores  Planificar la Integración de la Iteración.  Integrar el Sistema.  Ajustar y controlar el desarrollo.  Planificar el Proyecto.  Gestión de Riesgos.  Estimaciones y Mediciones.  Definir la Línea Base del Proyecto.  Definir y generar el ambiente controlado.  Planificar la Verificación.  Especificar los Casos de Prueba.  Verificación Unitaria.  Definir Estándares de Doc. de Usuario. Actividades no críticas  Planificar la Calidad  Revisión Técnica Formal (RTF’s)  Revisar las entregas.  Revisión de Ajuste al Proceso
  • 6.  Planificar la Configuración  Documentación de Usuario  Planificar la Transición.  Desarrollar los Materiales para Capacitación.  Seguimiento de la Línea Base del Proyecto. Flujo de trabajo de una iteración de la fase de elaboración Flujo de requisitos Aquí se establecen las prioridades y se estructuran los casos de usos Encontrar casos de usos y sus actores El analista de sistemas identifica casos de uso y actores adicionales a aquellos identificados en la fase de inicio. Aunque es necesario “comprender” alrededor el 80% de los casos de uso para alcanzar los objetivos de esta fase, no es necesario “detallar” toda esa cantidad. Se puede identificar casi todos (el 80%), describir solamente una fracción de ellos, y analizar solo partes de aquellos que describimos. Desarrollar prototipos de interfaces de usuario Durantela fase deelaboración solo nospreocuparemosdelas interfaces de usuarios si son interesantes desde un punto de vista de la arquitectura. Sin embargo, esto es rara vez el caso, solo en unos pocos casos son las interfaces de usuarios únicas en algún sentido. Si lo son, podemos tener que crear nuestro propio marco de trabajo de interfaces de usuario. Hay una razón adicional para hacer una interfaz de usuario incluso si no es significativa desde un punto de vista de la arquitectura, es para averiguar si funciona, utilizando para ello los usuarios reales. Por normal general, no es necesario desarrollar prototipos de las interfaces de usuario durante la elaboración. Determinar la prioridad de los casos de uso Al construir sobre el modelo parcial de casos de uso preparado en la fase de inicio, perseguimos dos objetivos “completar los casos de usos y trabajar en la línea base de la arquitectura”. Al principio, invertiremos tiempo en encontrar más casos de uso, para a continuación dirigir nuestra atención sobre la arquitectura. Sin embargo, debemos coordinar estos dos objetivos, nuestras decisiones están influenciadas por
  • 7. las prioridades asociadas a los riesgos percibidos, y por el orden en que decidimos seguir el desarrollo. A partir del modelo de casos de uso, el arquitecto genera una vista que se incluye en la descripción. Detallar un caso de uso Los encargados de especificar los casos de usos completaran los detalles que sean necesarios para entender completamente los requisitos y para crear la línea base de la arquitectura. En esta fase limitaremos nuestros esfuerzos a realizar descripciones preliminares de casos de uso completos y arquitectónicamente significativos. Estructurar el modelo de casos de uso El analista de sistemas revisa lo que ha hecho y busca similitudes, simplificaciones y oportunidades para mejorar la estructura del modelo de casos de uso. El analista emplea mecanismos como la extensión o la generalización para lograr el modelo mejor estructurado y más fácil de entender. Podemos lograr que el modelo sea más fácil de modificar, ampliar y mantener si por ejemplo se reduce la redundancia. Aunque a veces el analista no logra descubrir en este momento la mejor estructura. Puede necesitar hasta más adelante en la iteración. Artefactos  Modelo de Casos de Uso: permite que los desarrolladores de software y los clientes lleguen a un acuerdo con los requisitos. Contiene actores, casos de usos (uno para cada tipo de usuario, los que se representan por uno o más actores) y sus relaciones.  Actor: representan terceros fuera del sistema que colaboran con el sistema, sirven para identificar el entorno externo al sistema.  Casos de Uso: es cada unadelas formasen las que los actores usan el sistema.  Flujo de sucesos: para cada caso de uso puede plasmarse como una descripción textual de la secuencia de acciones del mismo.  Requisitos especiales: los requisitos no funcionales sobre el caso de uso.  Descripción de la Arquitectura: incluyen casos de usos que describan alguna funcionalidad importante y crítica.  Glosario: para definir términos comunes e importantes que los analistas y otros desarrolladores utilizan al describir el sistema.  Prototipo de Interfaz de Usuario: sirven para comprender y especificar las interacciones entre los actores humanos y el sistema durante la captura de requisitos.
  • 8. Trabajadores  Analista de Sistemas: responsable del conjunto de requisitos que están modelados en los casos de uso, incluyendo los funcionales y no funcionales. Delimita el sistema encontrando los actores y casos de uso.  Especificador de Casos de Uso: responsable de las descripciones detalladas de uno o más casos de usos.  Diseñador de Interfaz de Usuario: dan forma visual a las interfaces de usuarios.  Arquitecto: describir la vista de la arquitectura del modelo de casos de uso. Flujo de análisis Durante la fase de inicio, se hizo un borrador del modelo de análisis. Ahora construiremos sobre este borrador, pero podemos descubrir que es necesario desechar partes sustanciales de él. En la fase de elaboración, necesitamos trabajar con los casos de uso que son significativos desde un punto de vista de la arquitectura, y con aquellos casos de uso complejos que necesitemos refinar para comprender mejor los detalles de la apuesta económica. En esta sección se abordan las actividades de análisis de la arquitectura, analizar un caso de uso, analizar una clase y analizar un paquete. En el análisis, necesitamos ocuparnos de los casos de uso significativo desde un punto de vista de la arquitectura. También analizaremos los casos de uso para entenderlos de forma más precisa y para discernir la interferencia de unos con otros. Análisis de la arquitectura En la fase de inicio se realiza el análisis de la arquitectura hasta el extremo de determinar que había una arquitectura factible. Ahora, en la fase de elaboración, tenemos que extender el análisis de la arquitectura hasta el extremo de que pueda servir de base a una línea base de la arquitectura ejecutable. Con este propósito, el arquitecto realiza una partición inicial del sistema en paquetes de análisis, trabajando sobre la vista de la arquitectura del modelo de casos de uso, los requisitos relacionados con ellos, el glosario, y el conocimiento del dominio. Para ello, puede emplear una arquitectura en capas, identificando los paquetes específicos de la aplicación y los paquetes generales.
  • 9. Analizar un caso de uso. Muchos casos de usos no son claramente comprensibles tal y como están descritos en el modelo de casos de uso. Los casos de uso deben ser refinados en funciones de las clases del análisis que existen en el ámbito de los requisitos pero que no se implementan necesariamente de forma directa. Esta necesidad de refinamiento es particularmente aguda para los casos de uso complejos, y para aquellos que tienen impacto en otros, es decir, para los caos de uso que son dependientes unos de otros. Los casos de uso interesantes desde el punto de vista de la arquitectura, junto con los casos deuso cuya comprensión esimportante, deben ser refinadosen función de estas clases del análisis. Los otros casos de uso, los que no son interesantes desde la perspectivade la arquitectura o dela comprensión delos requisitos, no se refinan ni se analizan. Para estos casos de uso, los ingenieros de casos de uso solo necesitan una comprensión de lo que son, y del hecho de que no tendrán impacto. Sabrán cómo tratar con ellos cuando sea la hora de implementarlos durante la fase de construcción. Analizar una clase. Los ingenieros de componentes deberán refinar las clases identificadas anteriormente, mezclando las responsabilidades que han sido asignadas a estas clases desde diferentes casos de uso. También identificaran los mecanismos de análisis disponibles y averiguaran como son utilizados por cada clase. Analizar un paquete. El arquitecto meditara sobre los servicios del sistema y sobre el agrupamiento de clases en paquetes de servicio. Esto se hará en la actividad de análisis de la arquitectura, dada esta agrupación en paquetes de servicio, los ingenieros de componentes asumirán la responsabilidad de los paquetes, su refinamiento y mantenimiento. Artefactos  Modelo de Análisis: se representa mediante un sistema de análisis que denota el paquete de más alto nivel del modelo. Los casos de uso se representan mediante clases de análisis y sus objetos.  Clases de Análisis: representa una abstracción de una a varias clases y/o subsistemas del diseño del sistema. Características:
  • 10. o Se centra en el tratamiento de los requisitos funcionales y pospone los no funcionales. o Más conceptual. o Su comportamiento se define mediante responsabilidades (descripción textual del comportamiento de una clase). o Define atributos. o Participa en relaciones, a nivel conceptual. o Encajan en uno detres estereotipos: deinterfaz, de entidad o de control.  Clases de Interfaz: modelan la interacción entre el sistema y sus actores.  Clases de Entidad: modelan información que posee vida larga y que es a menudo persistente.  Clases de Control: encapsular el control de un caso de uso concreto, representan coordinación, secuencia, transacciones y control de otros objetos.  Diagramas de Clases: una clase de análisis y sus objetos normalmente participan en varias realizaciones de casos de uso, y algunas responsabilidades, atributos y asociaciones de una clase concreta suelen ser solo relevantes para una única realización de caso de uso.  Diagramas de Interacción: muestra las interacciones entre objetos creando enlaces entre ellos y añadiéndole mensajes.  Flujo de Sucesos – Análisis: texto adicional que explican los diagramas (especialmente los de colaboración).  Requisitos especiales: descripciones textuales que recogen todos los requisitos no funcionales sobre una realización de caso de uso.  Paquete del Análisis: proporcionaun medio para organizar los artefactos del modelo de análisis. Puede constar de clases de análisis, de realizaciones de casos de usos y de otros paquetes recursivamente. Características: o Pueden representar una separación de intereses de análisis. o Deben crearse basándose en los requisitos funcionales y en el dominio del problema. o Probablemente se convertirán en subsistemas en las dos capas de aplicación superiores.  Paquetes de Servicio: se utilizan para estructurar el sistema de acuerdo a los servicios que proporciona el sistema. Características: o Contiene un conjunto de clases relacionadas funcionalmente. o Es indivisible. o En un caso de uso puede participar uno o más paquetes. o A menudo depende de otro paquete de servicio. o Normalmente es relevante para uno o unos pocos actores. o Pueden ser mutuamente excluyentes.
  • 11. o Constituyen una entrada fundamenta para las actividades de diseño e implementación. o Son reutilizables.  Descripción de la Arquitectura (vista del modelo de análisis): contiene una vista de la arquitectura del modelo de análisis. Trabajadores  Arquitecto: es responsable de la integridad del modelo de análisis, garantizando que este sea correcto, consistente y legible como un todo.  Ingeniero de Casos de Uso: es el responsable de la integridad de una o más realizaciones de caso de uso, garantizando que cumplen los requisitos que caen sobre ellos.  Ingeniero de Componentes: define y mantiene las responsabilidades, atributos, relaciones y requisitos especiales de una o varias clases del análisis. También mantiene la integridad de uno o varios paquetes del análisis. Flujo de diseño En esta fase de elaboración se diseñará desde un punto de vista arquitectónico. Esto quiere decir que se diseñara los casos de usos, clases y subsistemas que sean arquitectónicamente significativos. Diseñar un caso de uso En el diseño de caso de uso, se especificarán las operaciones usadas para la comunicación, además, se necesitará tener en cuenta que subsistemas, marcos de trabajos o sistemas se van a reutilizar, y a continuación que operaciones proporcionan. Diseñar una clase Se diseñará las clases que participaron en las realizaciones de los casos de uso del paso anterior. Diseñar un subsistema Los ingenieros decomponentesdiseñan los subsistemas resultantes del diseño de la arquitectura. Durante esta fase, el arquitecto actualizara, si es necesaria la vista del modelo de diseño.
  • 12. El diseño es el centro de atención al final de la fase de elaboración y al comienzo de las iteraciones de la construcción. El modelo de diseño está muy cercano al de implementación. Artefactos  Modelo de Diseño: es un modelo de objetos que describe la realización física de los casos de uso centrándose en cómo los requisitos funcionales y no funcionales tienen un impacto en el sistema.  Clase del Diseño: es unaabstracción sin costuras deuna clase. Es sin costuras en el siguiente sentido: o El lenguaje utilizado para especificarla es el mismo que el lenguaje de programación. o La visibilidad de los atributos y las operaciones se especifican con frecuencia. o Los métodos tienen correspondencia directa con el correspondiente método en la implementación de las clases.  Realización de Casos de Uso - Diseño: es una colaboración que describe cómo se realiza un caso de uso específico y como se ejecuta en términos de clases de diseño y sus objetos.  Diagramas de Clases: una clase de diseño con sus objetos, además de los subsistemas que contienen las clases de diseño, que participan en las realizaciones de casos de uso.  Diagramas de Interacción: es preferible representarlo con el diagrama de secuencia en donde se muestre las interacciones entre objetos mediante transferencia de mensajes entre objetos o subsistemas.  Requisitos de la implementación: descripción textual que recoge requisitos tales como los no funcionales.  Subsistema de Diseño: forma de organizar los artefactos del modelo de diseño en piezas más manejables. Características: o Pueden representar una separación de aspectos del diseño. o Los subsistemas de las dos capas de aplicación de más alto nivel tienen trazas directas hacia paquetes y/o clases del análisis. o Pueden representar componentes de grano grueso en la implementación. o Pueden representar productos software reutilizados. o Pueden representar sistemas heredados.
  • 13.  Subsistemas de servicio: sebasan en los paquetes de serviciosdel modelo de análisis, y normalmente existe una traza uno a uno. Tratan más aspectos que los paquetes por: o Pueden tener que ofrecer sus servicios en términos de interfaces y de sus operaciones. o Contienen clases de diseño en vez de clase de análisis. o Suele dar lugar a un componente ejecutable o binario en la implementación.  Interfaz: para especificar las operaciones que proporcionan las clases y subsistemas de diseño.  Descripciónde la Arquitectura(vista del modelo de diseño): contiene una vista de la arquitectura del modelo de diseño.  Modelo de Despliegue: es un modelo de objetos que describe la distribución física delsistema en términos de cómo se distribuye la funcionalidad entre los nodos del cómputo. Se puede observar: o Cada nodo representa un recurso de computo. o Los nodos poseen relaciones que representan medios de comunicación entre ellos. o Puede describir diferentes configuraciones de red. o La funcionalidad de un nodo se define por los componentes que se distribuyen sobre él. o Representa una correspondencia entre a arquitectura software y la arquitectura del sistema.  Descripciónde la Arquitectura(vista del modelo de despliegue): contiene una vista de la arquitectura del modelo de despliegue. Trabajadores  Arquitecto: responsable de la integridad de los modelos del diseño y de despliegue.  Ingenieros de Casos de Uso: es el responsable de la integridad de una o más realizaciones de caso de uso - diseño.  Ingeniero de Componentes: define y mantiene las operaciones, atributos, relaciones y requisitos especiales de una o varias clases del diseño. También mantiene la integridad de uno o varios subsistemas del diseño.
  • 14. Flujo de implementación Este flujo de trabajo implementa y prueba los componentes arquitectónicamente significativos a partir de los elementos de diseño significativos. El resultado es la base de la arquitectura, implementada normalmente a partir de menos del 10 por ciento de los casos de uso. El responsable de integrar el sistema establece la secuencia de integración en un plan de integración y a continuación integra los subsistemas y los componentes correspondientes en una línea base de la arquitectura ejecutable. Su propósito es:  Planificar las integraciones del sistema en cada iteración.  Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue.  Implementar las clases y subsistemas encontrados durante el diseño.  Probar los componentes individualmente y luego integrarlos.  La implementación es el centro durante las iteraciones de construcción, aunque también se lleva a cabo en la fase de elaboración (para crear la línea base ejecutable de la arquitectura) y durante la transición (para tratar defectos tardíos). Artefactos  Modelo de Implementación: describe cómo los elementos del modelo de diseño se implementan en términos de componentes.  Componente: es el empaquetamiento físico de los elementos de un modelo. Características: o Tienen relaciones de traza con los elementos del modelo que implementan. o Normalmente implementan varios elementos.  Subsistema de Implementación: proporcionan una forma de organizar los artefactos del modelo de implementación en trozos más manejables. Se manifiesta a través de un mecanismo de empaquetamiento. Deberá: o Definir dependencias análogas hacia otros subsistemas de implementación. o Proporcionar las mismas interfaces.  Interfaz: especificar las operaciones implementadas por componentes y subsistemas de implementación.  Descripción de la Arquitectura (vista del modelo de implementación): contiene una vista de la arquitectura del modelo de implementación.
  • 15. Trabajadores  Arquitecto: responsablede la integridad de los modelos de implementación y despliegue.  Ingeniero de Componentes: define y mantiene el código fuente de uno o varios componentes. También mantiene la integridad de uno o varios subsistemas de implementación. Realiza pruebas de unidad.  Integrador de Sistema: planifica la secuencia de construcciones necesarias en cada iteración (dando lugar al plan de integración) y la integración de cada construcción. Flujo de prueba Aquí el objetivo es asegurarse de que los subsistemas de todos los niveles (subsistemas de servicio y subsistemas del diseño) y de todas las capas (desde la capa del sistema hasta las capas específicas de la aplicación) funcionen. Por supuesto, sólo podemos probar los componentes ejecutables. Durante este flujo se:  Busca los defectos a lo largo del ciclo de vida.  Verifica el resultado de la implementación.  Planifican las pruebas necesarias en cada iteración.  Diseña e implementa los casos de prueba que especifican que probar.  Realizan diferentes pruebas y manejan los resultados de estas sistemáticamente.  Prueban los componentes individualmente para luego integrarlos. Artefactos  Modelo de Pruebas: describe cómo se prueban los componentes ejecutables.  Caso de Prueba: especifica una forma de probar el sistema, incluyendo la entrada o resultado con la que sea de probar. Casos de prueba: o Uno que especifique como probar un caso de uso o un escenario especifico de un caso de uso. Sería una prueba del sistema como caja negra.
  • 16. o Uno que especifique como probar una realización de caso de uso – diseño. Sería una prueba de caja blanca.  Procedimiento de Prueba: especifica cómo realizar uno a varios casos de prueba o partes de estos.  Componente de Prueba: automatiza uno o varios procedimientos de prueba prueban componentes en el modelo de implementación.  Plan de Prueba: describe las estrategias, recursos y planificación de la prueba.  Defecto: es una anomalía del sistema, como un síntoma de fallo de software.  Evaluación de Prueba: la evaluación de los resultados de los esfuerzos de prueba. Trabajadores  Diseñador de Pruebas: responsable de la integridad de pruebas.  Ingeniero de Componentes: responsable de los componentes de prueba que automatizan algunos de los procedimientos de prueba.  Ingeniero de Pruebas de Integración: responsables de realizar las pruebas de integración que se necesitan para cada construcción producida en el flujo de trabajo de implementación.  Ingeniero de Pruebas de Sistema: responsable de realizar las pruebas de sistema necesarias sobre una construcción que muestra el resultado de una iteración completa. Importancia de la fase de elaboración en el desarrollo de software Esta fase es importante porque:  Establece una base de la arquitectura sólida para guiar el trabajo durante las fases de construcción y transición, así como en las posteriores generaciones del sistema.  Recopila la mayor parte de los requisitos que aun queden pendientes, formulando los requisitos funcionales como casos de uso.  Continua la observación y control de los riesgos críticos que aun queden, e identifica los riesgos significativos hasta el punto de que podamos estimar su impacto en el análisis de negocio, y en particular en la apuesta económica.
  • 17. CONCLUSIÓN En esta fase, se obtiene un entendimiento más detallado de los requerimientos, se procede a diseñar, implementar, validar y generar una línea base para la arquitectura. Se definen los subsistemas, los componentes clave y sus interfaces; se usan los casos de uso significantes arquitectónicamente para dirigir la arquitectura. Se consolidan y empaquetan las clases identificadas. Se diseña la Base de datos. Se implementan y prueban los escenarios críticos. Se debe mitigar los riesgos esenciales y producir un plan de desarrollo más preciso. Se elabora el artefacto de arquitectura el cual contempla todo el diseño de la arquitectura. La fase de elaboración es tan importante como las otras fases en el proceso de desarrollo de software, vemos que en esta fase se acrecienta el entorno de desarrollo, no solo para llevar a cabo las actividades de esta fase, sino para estar preparados para la fase de construcción. Los flujos de trabajo que más importancia y presencia tienen en esta fase son las de análisis y diseño. Además, en esta fase se habrá acumulado la información necesaria para planificar la fase de construcción. También, tendremos información suficiente para realizar un análisis de negocio fiable, trabajo que se comienza durante la fase de inicio, para evaluar si el proyecto vale la pena, recordemos que luego de esta fase, no hay vuelta atrás, ya que los gastos generados serán mucho mayores, a diferencia de dejarlo en este punto.