Fase de Elaboración

Fase de Elaboración

1. 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. 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. 3.  Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo razonable.∙ Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas iteraciones. Debe incluir los costes si procede. ∙ Completar la visión. ∙ Definir, validar y cimentar la arquitectura. ∙ 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 ∙ Recopilar casos de usos para aproximadamente el 80% de los requisitos funcionales. ∙ Especificar los niveles a alcanzar por los atributos de calidad. ∙ Identificar los riesgos significativos. ∙ Crear una línea base para la arquitectura. ∙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:
4. 4.  El plan para la fase de construcción es detalla∙ Se ha demostrado mediante la ejecución del prototipo que los principales elementos de riesgo han sido abordados y resueltos. ∙ La arquitectura es estable. ∙ La visión del producto es estable. ∙ Un manual de usuario preliminar (opcional). ∙ Un caso de desarrollo actualizado que especifica el proceso a seguir. ∙ Plan de desarrollo para el proyecto. ∙ Lista de riesgos y caso de negocio revisados. ∙ Un prototipo ejecutable de la arquitectura. ∙ Descripción de la arquitectura software. ∙ Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso específico. ∙ 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. ∙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:  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.∙do y preciso. Las estimaciones son creíbles.
5. 5.  Revisión de Ajuste al Proceso∙ Revisar las entregas. ∙ Revisión Técnica Formal (RTF’s) ∙ Planificar la Calidad ∙ Definir Estándares de Doc. de Usuario. Actividades no críticas ∙ Verificación Unitaria. ∙ Especificar los Casos de Prueba. ∙ Planificar la Verificación. ∙ Definir y generar el ambiente controlado. ∙ Definir la Línea Base del Proyecto. ∙ Estimaciones y Mediciones. ∙ Gestión de Riesgos. ∙ Planificar el Proyecto. ∙ Ajustar y controlar el desarrollo. ∙ Integrar el Sistema. ∙ Planificar la Integración de la Iteración. ∙ Comunicar el Diseño a Implementadores ∙ Describir la Arquitectura del Sistema. ∙ Diseñar el Sistema. ∙ Definir Pautas para la Interface de Usuario ∙ Definir el Alcance del Sistema. ∙ Priorizar los Requerimientos. ∙ Validar con Prototipo. ∙ Validar los Requerimientos. ∙ Especificar los Requerimientos. ∙ 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 ∙ 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. ∙
6. 6.  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∙ Desarrollar los Materiales para Capacitación. ∙ Planificar la Transición. ∙ Documentación de Usuario ∙ Planificar la Configuración ∙
7. 7.  Prototipo de Interfaz de Usuario: sirven para comprender y especificar las interacciones entre los actores humanos y el sistema durante la captura de requisitos.∙ Glosario: para definir términos comunes e importantes que los analistas y otros desarrolladores utilizan al describir el sistema. ∙ Descripción de la Arquitectura: incluyen casos de usos que describan alguna funcionalidad importante y crítica. ∙ Requisitos especiales: los requisitos no funcionales sobre el caso de uso. ∙ Flujo de sucesos: para cada caso de uso puede plasmarse como una descripción textual de la secuencia de acciones del mismo. ∙ Casos de Uso: es cada unadelas formasen las que los actores usan el sistema. ∙ Actor: representan terceros fuera del sistema que colaboran con el sistema, sirven para identificar el entorno externo al sistema. ∙ 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. ∙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
8. 8.  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 pun∙ Diseñador de Interfaz de Usuario: dan forma visual a las interfaces de usuarios. ∙ Especificador de Casos de Uso: responsable de las descripciones detalladas de uno o más casos de usos. ∙ 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. ∙Trabajadores to 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. 9.  Clases de Análisis: representa una abstracción de una a varias clases y/o subsistemas del diseño del sistema. Características:∙ 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. ∙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
10. 10.  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.∙ 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. ∙ Requisitos especiales: descripciones textuales que recogen todos los requisitos no funcionales sobre una realización de caso de uso. ∙ Flujo de Sucesos – Análisis: texto adicional que explican los diagramas (especialmente los de colaboración). ∙ Diagramas de Interacción: muestra las interacciones entre objetos creando enlaces entre ellos y añadiéndole mensajes. ∙ 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. ∙ Clases de Control: encapsular el control de un caso de uso concreto, representan coordinación, secuencia, transacciones y control de otros objetos. ∙ Clases de Entidad: modelan información que posee vida larga y que es a menudo persistente. ∙ Clases de Interfaz: modelan la interacción entre el sistema y sus actores. ∙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.
11. 11.  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 proporciona∙ 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. ∙ Arquitecto: es responsable de la integridad del modelo de análisis, garantizando que este sea correcto, consistente y legible como un todo. ∙ Descripción de la Arquitectura (vista del modelo de análisis): contiene una vista de la arquitectura del modelo de análisis. Trabajadores ∙o Constituyen una entrada fundamenta para las actividades de diseño e implementación. o Son reutilizables. n. 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. 12.  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.∙ Requisitos de la implementación: descripción textual que recoge requisitos tales como los no funcionales. ∙ 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. ∙ 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. ∙ 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. ∙ 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. ∙ 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. ∙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
13. 13.  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.∙ Ingenieros de Casos de Uso: es el responsable de la integridad de una o más realizaciones de caso de uso - diseño. ∙ Arquitecto: responsable de la integridad de los modelos del diseño y de despliegue. ∙ Descripciónde la Arquitectura(vista del modelo de despliegue): contiene una vista de la arquitectura del modelo de despliegue. Trabajadores ∙ 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 diseño): contiene una vista de la arquitectura del modelo de diseño. ∙ Interfaz: para especificar las operaciones que proporcionan las clases y subsistemas de diseño. ∙ 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. ∙
14. 14.  Descripción de la Arquitectura (vista del modelo de implementación): contiene una vista de la arquitectura del modelo de implementación.∙ Interfaz: especificar las operaciones implementadas por componentes y subsistemas de implementación. ∙ 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. ∙ 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. ∙ Modelo de Implementación: describe cómo los elementos del modelo de diseño se implementan en términos de componentes. ∙ 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 ∙ Probar los componentes individualmente y luego integrarlos. ∙ Implementar las clases y subsistemas encontrados durante el diseño. ∙ Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue. ∙ Planificar las integraciones del sistema en cada iteración. ∙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:
15. 15.  Integrador de Sistema: planifica la secuencia de construcciones necesarias en cada iteración (dando lugar al plan de∙ 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. ∙ Arquitecto: responsablede la integridad de los modelos de implementación y despliegue. ∙Trabajadores   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.∙ Modelo de Pruebas: describe cómo se prueban los componentes ejecutables. ∙ Prueban los componentes individualmente para luego integrarlos. Artefactos ∙ Realizan diferentes pruebas y manejan los resultados de estas sistemáticamente. ∙ Diseña e implementa los casos de prueba que especifican que probar. ∙ Planifican las pruebas necesarias en cada iteración. ∙ Verifica el resultado de la implementación. ∙ Busca los defectos a lo largo del ciclo de vida. ∙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:
16. 16.  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.∙ Recopila la mayor parte de los requisitos que aun queden pendientes, formulando los requisitos funcionales como casos de uso. ∙ 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. ∙ 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: ∙ 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 Componentes: responsable de los componentes de prueba que automatizan algunos de los procedimientos de prueba. ∙ Diseñador de Pruebas: responsable de la integridad de pruebas. ∙ Evaluación de Prueba: la evaluación de los resultados de los esfuerzos de prueba. Trabajadores ∙ Defecto: es una anomalía del sistema, como un síntoma de fallo de software. ∙ Plan de Prueba: describe las estrategias, recursos y planificación de la prueba. ∙ Componente de Prueba: automatiza uno o varios procedimientos de prueba prueban componentes en el modelo de implementación. ∙ Procedimiento de Prueba: especifica cómo realizar uno a varios casos de prueba o partes de estos. ∙o Uno que especifique como probar una realización de caso de uso – diseño. Sería una prueba de caja blanca.
17. 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.

...