rup - fase de elaboración
TRANSCRIPT
UNIVERSIDAD DE ORIENTENÚCLEO DE ANZOÁTEGUI
ESCUELA DE INGENIERIA Y CIENCIAS APLICADASDEPARTAMENTO DE COMPUTACIÓN Y SISTEMAS
CÁTEDRA: DESARROLLO DE SOFWARE
RUPFASE 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. Prepara una propuesta de la planificación cubierta, personal necesario 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 decisiones de 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
Durante la fase de elaboración solo nos preocuparemos de las 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 una de las formas en 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 de uso cuya comprensión es importante, deben ser refinados en función de estas clases del análisis. Los otros casos de uso, los que no son interesantes desde la perspectiva de la arquitectura o de la comprensión de los 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 de tres estereotipos: de interfaz, 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: proporciona un 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 de componentes diseñ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 una abstracción sin costuras de una 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: se basan en los paquetes de servicios del 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ón de 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 del sistema 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ón de 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: responsable de 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.