Puds Libro

CAPTURA DE REQUISITOS: DE LA VISIN A LOS REQUISITOS
La captura de requisitos es el proceso de averiguar, normalmente en circunstancias difciles, lo que se debe construir. Proceso que no es nada sencillo y que por lo tanto es muy comn su uso por los equipos de proyectos. 6.1 Por qu la captura de requisitos es complicada La principal razn es que los usuarios del software, que realizan los desarrolladores, son una fuente imperfecta de informacin. Con frecuencia no saben cuales son los requisitos y mucho menos, cmo especificarlos de una forma precisa. Entonces surgi el analista, encargado de obtener una lista de requisitos de cada usuario para componer una, completa, correcta y consistente. A pesar de ello, los usuarios sugeran una gran cantidad de cambios cuando el proyecto haba avanzado ya bastante, lo cual produce un impacto importante en los plazos y el coste. No basta entrevistarnos con los usuarios para saber que quieren, lo ms importe es que nuestro sistema de soporte a la misin para la cual se construye. Aunque claro, este valor cambiar con el tiempo, con el negocio, etc. 6.2 El objeto del flujo de trabajo de los requisitos Su propsito es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una descripcin de los requisitos del sistema (es decir, las condiciones o capacidades que el sistema debe cumplir) suficientemente buena como para que pueda llegarse a un acuerdo entre el cliente y los desarrolladores sobre qu debe y qu no debe hacer el sistema. Para alcanzar este objetivo debemos usar el lenguaje del cliente para describir los resultados, evitando incluir detalles sobre el funcionamiento interno del sistema 6.3 Visin general de la captura de requisitos As como cada proyecto de software es diferente, ya que ste debe acomodarse a los requerimientos de las diferentes empresas que lo puedan necesitar, as tambin la captura de requisitos tiene diferentes puntos de partida. Podemos tener clientes que han podido desarrollar una especificacin de requisitos completa y detallada, y en el otro extremo, clientes que tiene una vaga nocin de lo que debera ser su sistema. Esto hace que los analistas deben ser capaces de adaptar sus tcnicas a la captura de requisitos en cada situacin. Adems deben seguir un flujo de trabajo arquetpico que comprende lo siguiente: Enumerar los requisitos candidatos Un conjunto de requisitos candidatos es una lista de ideas que se puede decidir implementar en una versin futura del sistema. Esta lista de caractersticas crece a medida que se aaden nuevos elementos y mengua cuando algunas caractersticas se conviertes en requisitos y se transforman en casos de uso. Esta lista es usada slo para la planificacin del trabajo. Cada caracterstica tiene un nombre corto y una breve explicacin o definicin, informacin suficiente para poder hablar de ella durante la planificacin del producto. Comprender el contexto del sistema
1
El Proceso Unificado de Desarrollo de Software
Para capturar los requisitos correctos y para construir el sistema correcto los desarrolladores requieren un firme conocimiento del contexto en el que se emplaza el sistema. Existen dos aproximaciones para expresar el contexto de un sistema en una forma utilizable. El modelado del dominio, que describe los conceptos importantes del contexto como objetos del domino y enlaza unos con otros. La identificacin y la asignacin de un nombre para estos objetos nos ayudan a desarrollar un glosario de trminos que permitirn comunicarse mejor a todos lo que estn trabajando en el sistema. Y el modelado del negocio, el cual tiene por objetivo describir los procesos. A medida que se va modelando el negocio, se aprende mucho sobre el contexto del software, y lo describen el un modelado del negocio. ste, especifica que procesos de negocio soportar el sistema, estableciendo tambin las competencias requeridas en cada proceso: sus trabajadores, sus responsabilidades y las operaciones que llevan a cabo. Capturar requisitos funcionales La tcnica inmediata para identificar los requisitos del sistema se basa en los casos de uso. Ya sean funcionales o no funcionales que son especficos de cada caso de uso. Para el usuario, un caso de uso es un modo de utilizar el sistema. En consecuencia, si los analistas pueden descubrir todos los casos de uso que necesita el usuario, entonces saben lo que debe hacer el sistema. Cada caso de uso representa una forma de usar el sistema. Cada usuario necesita varios casos de uso, cada uno de los cuales representa los modos diferentes en los cuales el usuario utiliza el sistema. La captura de los casos de uso que realmente se quieren para el sistema, requiere comprender el contexto del sistema, entrevistar usuarios, discutir propuestas, etc. Capturar requisitos no funcionales Los requisitos no funcionales especifican propiedades del sistema, como restricciones del entorno o de la implementacin, rendimiento, dependencias de la plataforma, facilidad de mantenimiento, extensibilidad, y fiabilidad. Un requisito de rendimiento impone condiciones sobre los requisitos funcionales como la velocidad, rendimiento, tiempo de respuesta, y uso de memoria. La mayora de requisitos de rendimiento afectan slo a ciertos casos de uso y por tanto deberan conectarse a este caso de uso. En la prctica esto significa que estos requisitos se describirn en la parte derecha, es decir, en la descripcin del caso de uso. 6.4 El papel de los requisitos en el ciclo de vida del software Los casos de uso se desarrollan a largo de varios incrementos del desarrollo, donde las iteraciones aadirn nuevos casos de uso y/o detalles a las descripciones de los casos existentes. Fase de Inicio.Se identifican los casos de uso para delimitar el sistema y el alcance del proyecto y para detallar los mas importantes (Menos del 10%).
2
Fase de Elaboracin. Se capturan la mayoria de los requisitos restantes para estimar el tamao del esfuerzo de desarrollo requerido. El objetivo es capturar el 80% de los requisitos y describir la mayora de los casos de uso. Fase de Construccin Los requisitos restantes se capturan e implementan. Fase de Transicin. Hay captura de datos si los requisitos cambian.
6.5 La comprensin del contexto del sistema mediante un modelo del dominio 6.5.1 Modelo de Dominio Captura los tipos ms importantes de objetos en el contexto del sistema. Los objetos del dominio o clases representan las cosas que existen o los sucesos que ocurren en el entorno del sistema, pueden obtenerse de una especificacin de requisitos o por una entrevista con los expertos del dominio, las clases aparecen de 3 formas: Objetos del Negocio Representan cosas que se manipulan en el negocio (pedidos, cuentas, matriculas, reservas, etc). Objetos del Mundo Real y Conceptos El sistema les debe hacer un seguimiento (clientes, paquetes tursticos, comprobantes de compra, venta, fichas de matricula, etc.) Sucesos que ocurrirn o han ocurrido (horas de llegada, fechas de envi, etc)
El modelo del dominio se describe con diagramas de clases, los que muestran los actores, clases y su interaccin. 6.5.2 Desarrollo de un modelo de dominio El modelado del dominio se realiza en reuniones organizadas por los analistas las cuales deben incluir a expertos del dominio y a gente con experiencia en modelado. El objetivo del modelado es comprender y describir las clases ms importantes dentro del contexto del sistema. Los dominios de tamao moderado requieren de 10 a 50 clases, el resto de clases que los analistas extraen del dominio se guardan como definiciones en un glosario de trminos, los cuales pueden ser suficientes para los dominios de negocio muy pequeos. El glosario y el modelado ayudan a utilizar un vocabulario comn para compartir el conocimiento con los otros y el proceso de ingeniera sea ms fcil. El modelado de dominio debera contribuir a la comprensin del problema que el sistema resuelve en relacin a su contexto. 6.5.3 Uso del modelado de dominio Las clases de dominio y el glosario de trminos se usan en el desarrollo de casos de uso y de anlisis. Se usan: Al escribir los casos de usos y al disear la interfaz de usuario. Para sugerir clases internas al sistema en desarrollo durante el anlisis. 3
Sin embargo desarrollar un modelo del negocio es una alternativa ms potente que desarrollar un modelo de dominio 6.6. La comprensin del contexto del sistema mediante un modelo del negocio El modelado del negocio es una tcnica para comprender los procesos de negocio de la organizacin. Participa en casos de uso de ms alto nivel que deberamos esquematizar brevemente. El objetivo es identificar los casos de uso del software y las entidades de negocio relevantes que el software debe soportar, de forma que podramos modelar slo lo necesario para comprender el contexto. El resultado de esta actividad es un modelo del dominio derivado de la comprensin del funcionamiento del sistema de negocio que lo rodea. 6.6.1. Qu es un modelo del negocio? Un modelo de casos de uso del negocio describe los procesos de negocio de una empresa en trminos de casos de uso del negocio y actores del negocio que se corresponden con los procesos del negocio y los clientes respectivamente. Al igual que el modelo de casos de uso para un sistema software, el modelo de casos de uso del negocio presenta un sistema (en este caso, el negocio) desde la perspectiva de su uso y esquematiza cmo proporciona valor a sus usuarios (en este caso, sus clientes y socios). El modelo de casos de uso del negocio se describe mediante diagramas de casos de uso. Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cmo cada caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades del negocio y de unidades de trabajo. Cada realizacin de un caso de uso del negocio puede mostrarse en diagramas de interaccin y diagramas de actividad. Una entidad del negocio representa algo, como una factura, que los trabajadores toman, inspeccionan, manipulan, producen o utilizan en un caso de uso del negocio. Una unidad de trabajo es un conjunto de esas entidades que conforma un todo reconocible para un usuario final. Las entidades del negocio y las unidades de trabajo se utilizan para representar los mismos tipos de conceptos que las clases del dominio. Por tanto podemos confeccionar un diagrama de las entidades del negocio. Tambin tendremos otros diagramas para mostrar los trabajadores, sus interacciones y cmo utilizan las entidades de negocio y las unidades de trabajo. Cada trabajador, entidad del negocio y unidad de trabajo pueden participar en la realizacin de ms de un caso de uso del negocio. 6.6.2. Como desarrollar un modelo del negocio 1. Los modeladores del negocio deben confeccionar un modelo de casos de uso del negocio que identifique los actores del negocio y los casos de uso del negocio que utilicen los actores. Este modelo de casos de uso del negocio permite a los modeladores comprender mejor que valor proporciona el negocio a sus actores. 2. Los modeladores deben desarrollar un modelo de objetos del negocio compuesto por trabajadores, entidades del negocio y unidades de trabajo que juntos realizan los casos 4
de uso del negocio. Se asocian a estos diferentes objetos las reglas del negocio y otras normas impuestas por el negocio. El objetivo es crear trabajadores, entidades del negocio y unidades de trabajo que realicen los casos de uso del negocio de la manera ms eficaz posible es decir rpidamente, con precisin y con un coste bajo. 6.6.3. Bsqueda de casos de uso a partir de un modelo del negocio En primer lugar, el analista identifica un actor por cada trabajador y por cada actor del negocio (es decir cada cliente) que se convertir en usuario del sistema de informacin. Cada trabajador (y cada actor del negocio) que vaya a ser usuario del sistema de informacin requerir un soporte por parte del mismo. Para cada trabajador identificamos todas las realizaciones de casos de uso del negocio diferentes en las que participa. El trabajador cumple un papel en cada una de forma muy parecida al papel que desempea una clase en cada realizacin de caso de uso. Una vez que hemos encontrado todos los roles de un trabajador o de un actor del negocio, uno por cada caso de uso del negocio en el que participa, podemos encontrar los casos de uso de los actores del sistema en el sistema de informacin. Cada trabajador y cada actor del negocio se corresponden con un actor del sistema de informacin. La manera ms directa de identificar un conjunto tentativo de casos de uso es crear un caso de uso para el actor correspondiente a cada rol de cada trabajador y de cada actor del negocio. Como resultado obtendremos para cada caso de uso del negocio un caso de uso por cada trabajador y por cada actor del sistema. 6.7. Requisitos adicionales Son fundamentalmente requisitos no funcionales que no pueden asociarse a ningn caso de uso en concreto en cambio cada uno de estos requisitos tienen impacto en varios casos de uso o en ninguno. Algunos ejemplos son el rendimiento, las interfaces y los requisitos de diseo fsico as como las restricciones arquitectnicas de diseo e implementacin. Los requisitos adicionales se capturan de forma muy parecida a como se haca en la especificacin de requisitos tradicional. Despus se utilizan durante el anlisis y el diseo junto al modelo de casos de uso. Un requisito de interfaz especifica la interfaz con un elemento externo con el cual debe interactuar el sistema o que establece restricciones condicionantes en formatos, tiempos u otros factores de relevancia en esa interaccin. Un requisito fsico especifica una caracterstica fsica que debe poseer un sistema como su material, forma, tamao o peso. Por ejemplo puede utilizarse para representar requisitos hardware como las configuraciones fsicas de red requeridas. Una restriccin de implementacin especifica o limita la codificacin o construccin de un sistema. Son ejemplos los estndares requeridos, las normas de codificacin, los lenguajes de programacin, polticas para la integridad de la base de datos, limitaciones de recurso y entornos operativos. PREGUNTAS 1. Cules son los pasos del flujo de trabajo arquetpico para la captura de requisitos? 2. Qu es un modelo de dominio? 3. Qu es un modelo del negocio? 4. Cules son los pasos para la bsqueda de casos de Uso del Negocio? 5
CAPTURA DE REQUISITOS COMO CASOS DE USO

7.1 Introduccin En la fase de requisitos se necesito un modelo, y para construir ese modelo, se usan los casos de uso debido a que los casos de uso nos permiten representar los requisitos funcionales de un Sistema. Mediante la utilizacin de Casos de uso los analistas estn obligados a pensar en trminos de quienes son los usuarios y que necesidades u objetivos de la empresa pueden cumplir. Adems los Casos de Uso permiten dirigir el resto de los trabajos de software haciendo de esta caracterstica la principal razn para ser aceptado por la mayora de los mtodos de la ingeniera moderna del software. Se describir el flujo de trabajos en tres pasos: 1.-Los artefactos creados en el flujo de los requisitos. 2.-Los trabajadores participantes en el flujo de los requisitos. 3.-El flujo de trabajo de captura de requisitos, incluyendo cada actividad en mas detalle. Se comenzara a analizar los Artefactos y Trabajadores. 7.2 Artefacto: Es un trmino general para cualquier tipo de descripcin o informacin creada, producida, cambiada o utilizada por los trabajadores durante su trabajo con el sistema. Un artefacto puede ser un modelo, un elemento de un modelo o un documento. En el flujo de trabajo de los requisitos, los artefactos son fundamentalmente el modelo de casos de uso y sus casos de uso ya que estos permiten la captura de requisitos funcionales. 7.2.1 Artefacto: Modelo de Casos de Uso El modelo de casos de uso permite determinar a los usuarios y analistas que condiciones y posibilidades deben cumplir nuestro sistema, constituye la entrada fundamental para el anlisis el diseo y las pruebas. Este modelo esta formado por un conjunto de actores y casos de uso. Si el modelo es grande se puede dividir en paquetes o en otros casos de uso. 7.2.2 Artefacto: Actor El modelo de Casos de Uso tambin representan los roles de los usuarios a travs de los actores, es decir modela lo que un usuario hace en el sistema esto determinando el entorno externo al Sistema. 7.2.3 Caso de Uso Cada forma en que los actores usan el sistema se representa con un caso de uso. Los casos de uso son fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores. Es un conjunto de acciones que realiza el sistema produciendo un resultado valioso para alguien en el sistema. Los casos de uso son verbos Una instancia de un caso de uso es lo que el sistema lleva a cabo cuando obedece a un caso de uso, normalmente un instancia de un actor invoca una instancia de caso de uso, pero la instancia de caso de uso no interacta con otras instancias de caso de uso. Cada instancia es atmica ( se ejecuta en su totalidad o no se ejecuta) 6
7.2.3.1 Flujo de sucesos Viene a ser la secuencia de acciones para cada caso de uso, especifica lo que el sistema hace y como el sistema interacta con los actores cuando se lleva a cabo un caso de uso. 7.2.3.2 Requisitos especiales Es la descripcin textual que agrupa los requisitos del tipo de los requisitos funcionales sobre el caso de uso
no
7.2.4 Artefacto: Descripcin de la arquitectura (Vista del modelo de casos de uso) Contiene una vista de la arquitectura del modelo de casos de uso, que representa los casos de uso significativos para la arquitectura. 7.2.5 Artefacto: glosario Sirven para definir trminos comunes e importantes, conceptos y nociones que los analistas usan al describir el sistema para evitar confusiones. Se puede obtener de un modelo de negocios o de un modelo del dominio, ya estn centrados en el sistema y no el contexto. 7.2.6 Artefacto: Prototipo de interfaz de usuario Nos ayudan a comprender y especificar las interacciones entre los actores humanos y el sistema durante la captura de los requisitos, nos ayuda a comprender mejor los casos de uso y a desarrollar un interfaz grafica mejor.
7.3 Trabajadores Es la representacin de un ser humano con ciertas capacidades que se requiere en un caso de uso para el desarrollo de software. Un trabajador no corresponde a un cargo especfico dentro de la empresa y una misma persona puede estar asignada a diferentes trabajadores durante un proyecto. Los trabajadores pueden ser: 7.3.1 Trabajador Analista de Sistema. Es el encargado de la captura de los requerimiento funcionales del sistema es decir es el responsable de encontrar los actores y casos de uso, tambin es responsable del glosario y de los los requisitos no funcionales. Para cada Sistema hay un analista pero el analista no es responsable de cada caso en particular. 7.3.2 Trabajador: Especificador de caso de uso El analista esta acompaado de otros trabajadores para detallar los casos de uso a estos trabajadores se les denomina Especificadores de casos de uso. Cada especificar necesita trabajar estrechamente con los usuarios reales de sus casos de uso 7.3.3 Diseador de interfaz de usuario Es el encargado de la forma visual de la interfaces de usuario, lo cual puede implicar el desarrollo de prototipos para cada actor. El diseador esta encargado del diseo de la interfaz de usuario pero no de la implementacin. 7.3.4 Trabajador: arquitecto.- Participa en el flujo de trabajo de los requisitos para describir la vista de arquitectura del modelo de casos de uso (es duna entrada importante para planificar las iteraciones).
7
7.4. Flujo de trabajo.Es una secuencia de actividades que estn ordenadas, as que una actividad produce una salida que sirve de entrada a la siguiente actividad, donde el orden no es estricto.
Analista de Sistemas Encontrar Actores y casos de uso Encontrar el modelo de casos de uso
Arquitecto
Priorizar los casos de uso
Especificador de casos de
Detallar un caso de uso
Diseador de interfaces de usuario
Prototipar la interface de usuario
Esta figura muestra la captura de requisitos en forma de casos de uso, incluyendo trabajadores participantes y sus actividades. El analista de sistemas se asegurara que todas listar todas las caractersticas y el modelo de dominio o de negocio, entonces el arquitecto identificara los casos de uso relevantes, hecho esto los especificadores de casos de uso describen todos los casos de uso que se han priorizado, los diseadores de interfaces sugieren las interfaces de usuario segn los casos de uso, entonces el analista de sistemas reestructurara el modelo de casos de uso definiendo generalizaciones para su entendimiento. Esta primera iteracin produce una primera versin del modelo de casos de uso, la cual se completa y se mejora a travs de las iteraciones. 7.4.1. Actividad: encontrar actores y casos de uso.- El analista ejecuta esta actividad para: o Delimitar el sistema de su entorno. o Esbozar quin y qu interactan con el sistema, y que funcionalidad se espera con el sistema. o Captura y definir un glosario de trminos comunes esenciales para la creacin descripciones detalladas de las funcionalidades del sistema. Esta actividad consta de 4 pasos: Encontrar los actores. Encontrar los casos de uso. Describir brevemente cada caso de uso. Describir el modelo de caso uso completo (este pasos tambin incluye la preparacin de un glosario de trminos). Estos pasos no tienen ningn orden en particular, por ejemplo el diagrama de casos de uso puede actualizarse tan pronto como se identifique un actor o un caso de uso. 7.4.1.1.- Encontrar los actores.- El analista puede asignar un actor a cada actor del negocio y un actor a cada cliente de negocio que utilizar la informacin del sistema, se debe identificar los actores que representan sistemas externos y los actores para el mantenimiento y operacin del sistema. Hay 2 criterios a la hora de elegir candidatos a actores: primero, identificar un usuario que pueda representar al actor candidato, esto nos ayudara a encontrar a los actores relevantes y eliminar los actores fantasmas, segundo, Debera existir una coincidencia mnima entre los roles que desempean las instancias de los diferentes actores en relacin con el sistema, en caso de que existan actores con los mismos roles, entonces se deber inatentar combinar los papeles en un conjunto de roles que asignaremos a un 8
actor, o encontrar un actor generalizado que tenga los roles a los actores que se solapan, Por ejemplo el comprador y el vendedor pueden ser especializaciones del actor cliente del banco. El analista de sistemas da nombre a los actores y describe a brevemente sus papeles, esta debe esbozar sus necesidades y responsabilidades. 7.4.1.2.- Encontrar los casos de uso.- Se propone un caso de uso para cada rol del trabajador que participa en realizacin de casos de uso del negocio y que utilizara la informacin del sistema, o los identificara a travs de los talleres con los clientes y usuarios, tambin puede utilizar las entrevistas, el actor necesita normalmente casos de uso para soportar su trabajo de creacin, cambio, rastreo, eliminacin o estudio de los objetos de negocio, o en otras formas de representacin el actor puede necesitar informarle al sistema de algunos sucesos que a realizado. Hay recordar que intentamos crear casos de uso fciles de modificar, revisar probar y manejar unitariamente, Elegimos el nombre para cada caso de uso de forma que nos haga pensar en la secuencia de acciones que aade valores a un actor, y debe reflejar cual es el objetivo de la interaccin entre el actor y el sistema, las cuales pueden especificarse en un caso de uso o varios. Existen criterios tiles para identificacin de casos de uso: -Resultado de valor: Cada ejecucin satisfactoria de un caso de uso debe proporcionar algn valor al actor para alcanzar su objetivo. -Un actor en concreto: Identificando casos de uso que proporcionen valores a usuarios individuales reales, nos aseguramos que los casos de uso no se harn grandes al igual que con los actores. 7.4.1.3.-Describir brevemente cada caso de uso.- Esto se puede realizar con algunas frases que resumen las acciones con algunos anotes en los casos de uso y mas tarde con una descripcin paso a paso de lo que el sistema requiere. 7.4.1.4.-Descripcin del modelo de casos de uso en su totalidad.- En este paso necesitamos explicar como estn relacionados entre si los casos de uso y los actores y como juntos constituyen el modelo de casos de uso, se elige los diagramas que describen mas claramente el sistema. Para asegurar la consistencia cuando se describen varios casos de uso concurrentemente, resulta prctico desarrollar un glosario de trminos. Luego terminado la descripcin general se convoca a una revisin informal con los que no forman parte del equipo de desarrollo (cliente, usuario) para determinar: -Se han capturado como casos de uso todos los requisitos funcionales necesarios. -La secuencia de acciones es correcta, completa y comprensible para cada caso de uso. -Se identifica algn caso de uso que no proporcione valor. Si es as ese caso de uso deber reconsiderarse. 7.4.2. Actividad: priorizar casos de uso.- El propsito de esta actividad es proporcionar entradas a la priorizacion de los casos de uso para determinar cuales son necesarios para el desarrollo en las primeras iteraciones, y cuales pueden dejarse para ms tarde. La vista de la arquitectura del modelo de casos de uso significativos desde el punto de vista de la arquitectura. 7.4.3. Detallar un caso de uso.- El objetivo principal de detallar cada caso de uso es describir su flujo de sucesos en detalle, incluyendo como comienza, termina e interacta con los actores, con el modelo de casos de uso y los diagramas de casos de uso asociados como punto de comienzo el especificador de casos de uso individual puede describir cada caso de uso a 9
detalle en una especificacin precisa de la secuencia de acciones. El especificador de casos de uso deber precisar la siguiente secuencia de acciones. -Como estructurar la descripcin de para especificar todas las vas alternativas del caso de uso. -Que incluir en la descripcin de caso de uso. -Como formalizar la descripcin de caso de uso cuando sea necesario. Cada especificador de casos de uso debe trabajar estrechamente con los usuarios reales de los casos de uso, para lo cual les entrevistara y solicitarles que revisen la descripcin de los casos de uso. El resultado de esta actividad es la descripcin detallada de un caso de uso en particular en forma de texto y diagrama. 7.4.3.1.- Estructuracin de la descripcin de casos de uso.- Ya hemos mencionado que un caso de uso los estados que las instancias de los casos de uso pueden tener y la posible transicin entre estos estados, As mismo un caso de uso puede imaginarse como un diagrama de estados con su estado de comienzo, estados intermedios, estados finales y sus transiciones de un estado a otro. 7.4.3.2 Formalizacin de la Descripciones de Casos de Uso Para mejorar el entendimiento de los CU se debe puede utilizar un Diagrama de Estados, un Diagrama de Actividad o un Diagrama de Interaccin Ejm El Diagrama de Estados para el CU pagar Factura muestra como la instancia del CU transita por los diferentes estados un secuencia de transiciones. 7.4.4 Actividad: Prototipar la Interfaz de Usuario El objetivo de esta actividad es construir un prototipo la interfaz de usuario el cual le permita al usuario llevar a cabo los casos de uso de manera eficiente, para esto se debe seguir los sgtes pasos: Diseo lgico de la interfaz de usuario. Diseo fsico de la interfaz de usuario. Despus de realizar estas dos etapas nos da como resultado un conjunto de esquemas de interfaces de usuario que cuentan con una apariencia amistosa hacia los actores. 7.4.4.1 Creacin del Diseo Lgico de la Interfaz de Usuario Cuando lo actores interactan con el sistema, utilizaran y manipularan elementos de interfaces de usuario que representan atributos. En si el Diseador de los Interfaces de Usuario debe identificar y especificar estos elementos actor por actor, recorriendo todos los casos de uso que los actores pueden acceder, y tambin determinando los atributos para cado Caso de Uso. 10
Ejm Elementos de la interfaz de usuario para Cuenta y Factura, con algunos de sus atributos 7.4.4.1 Creacin del Diseo Fsico de la Interfaz de Usuario Los diseadores de interfaz de usuario primero preparan unos esquemas aproximados de la configuracin de los elementos de interfaces de usuario que constituyen interfaces de usuario tiles para los actores. Despus, bosquejan elementos adicionales (herramientas, controles, etc.) necesarios para combinar varios elementos de interfaces de usuario en interfaces de usuario completos. Ejm Para un mejor manejo de todas los CU su puede disear herramientas, controlas, mens etc.
7.4.5 Actividad: Estructurar el Modelo de Casos de Uso El modelo de Casos de Uso se estructura para: Extraer descripciones de funcionalidad generales y compartidas que pueden ser utilizados por descripciones mas especificas (relacin de Generalizacin entre CU). Extraer descripciones de funcionalidad adicionales u opcionales que pueden ser extender descripciones mas especificas (relacin de Extensin entre CU). 7.4.5.1 Identificacin de Descripciones de funcionalidad Compartidas A medida que identificamos y esbozamos las acciones de cada caso de uso, debemos tambin ir buscando acciones o parte de acciones comunes o compartidas por varios Casos de Uso con el fin de reducir la redundancia. Relacin de Generalizacin.- Esta relacin entre Casos de Uso es una clase de Herencia, en la que las instancias de los Casos de Uso generalizados pueden ejecutar todo el comportamiento descrito en el caso de uso generalizador. Ejm La Relacin de Generalizacin entre los CU, toda las acciones descritas por Ejecutar Transaccin es heredada en la secuencia descrita por Pagar Factura. 7.4.5.1 Identificacin de Descripciones de funcionalidad Adicionales Una de las relaciones entre Casos de Uso es la Relacin de Extensin. Relacin de Extensin (extend relationship).- Esta relacin modela la adicin de una secuencia de acciones a un Caso de Uso. Esta relacin se comporta como si fuera algo que se aade a la descripcin original de un Caso de Uso, esta relacin incluye una condicin para la extensin como una referencia a un punto de extensin en el Caso de Uso. Vase el sgte grafico
11
Ejm La fecha entrecortada representa la relacin de Extensin entre los CU. Como esta relacin es de condicin se debe verificar si el Comprador es un deudor del Vendedor para as poder ejecutar la nueva operacin. 7.4.5.3 Identificacin de otras Relaciones entre Casos de Uso Existen otras relacin entre los CU, como las Relaciones de Inclusin (include relationship), esta es una relacin inversa a la relacin de Extensin., que le proporciona un extensin explicita e incondicional a un CU. En este libro no se encontrara muchos detalles sobre este tipo de Relacin. 7.5 Resumen del Flujo de Trabajo de los Requisitos En este capitulo y en el anterior, se ha descrito como capturar los requisitos de un sistema en forma de: Un modelo de l negocio o un modelo del dominio para establecer el contexto del Sistema. Un modelo de CU que capture los requisitos funcionales. Un conjunto de esbozos de interfaces de usuario y de prototipos para cada actor. Una especificacin de requisitos generales y adicionales. Estos resultados son un buen inicio para los sgtes flujos de trabajo: anlisis, diseo, implementacin y prueba.
Preguntas: Qu se debe determinar una vez terminada la descripcin general del modelo de casos de uso? Qu se debe tomar en cuenta para prototipar una Intefaz de usuario? Cules son los cargos que puede adoptar un trabajador? Qu son los flujos de trabajo, mencione las actividades?
12
ANLISIS
8.1 Introduccin En la etapa del anlisis se analizan los requisitos obtenidos en la captura de requisitos del sistema, refinndolos y estructurndolos, cuyo objetivo es facilitar su comprensin para que nos ayude a estructurar el sistema entero- incluyendo su arquitectura. La regla numero uno de la captura de requisitos es usar el lenguaje del cliente, y los casos de uso nos ayudan a eso. Pero esto implica algunos riesgos como por ejemplo que algunos aspectos queden sin describir o que su descripcin no sea muy legible a los ojos de los diseadores. Para comunicar de manera eficiente las funciones del sistema al cliente: 1. Los casos de uso deben mantenerse tan independientes unos de otros como sea posible.- Se logra no quedndose atrapado en detalles como interferencias, concurrencia y conflictos. 2. Los casos de uso deben describirse utilizando el lenguaje del cliente, y ser cuidadosos al utilizar notaciones mas formales. 3. Debe estructurarse cada caso de uso para que forme una especificacin de funcionalidad completa e intuitiva. Esto se logra estructurando los casos de uso de manera que reflejen intuitivamente los casos de uso reales que el sistema proporciona El objetivo del anlisis es encontrar solucin a los detalles que aun no han sido resueltos, analizando con mayor profundidad los requisitos, con la diferencia que puede usarse el lenguaje de los desarrolladores. Es decir se puede usar el lenguaje natural para algunos casos de uso y el lenguaje formal para otros casos de uso que lo requieran (a esto le denominaremos refinar los requisitos). COMPARACIN DEL MODELO DE CASOS DE USO CON EL MODELO DE ANLISIS Modelo de Casos de Uso Descrito con el lenguaje del Cliente Vista Externa del Sistema Modelo de Anlisis Descrito con el lenguaje del desarrollador. Vista Interna del Sistema
Estructurado por los C.U. proporciona la Estructurado por Clases y paquetes estructura a la vista externa estereotipados, proporciona la estructura a la vista interna Utilizado fundamentalmente como contrato Utilizado por los desarrolladores para entre el usuario y los desarrolladores sobre comprender como deberia darse forma al que deberia y que no deberia hacer el sistema sistema Puede contener redundancias incosistencias, etc. entre requisitos e No deberia contener redundancias incosistencias, etc. entre requisitos e
Define C.U. que se analizaran con mas Define realizaciones de C.U. y cada una de profundidad en el modelo del Anlisis. ellas representa el anlisis de un C.U. del modelo de C.U.
8.2 El anlisis en pocas palabras 13

El lenguaje que se usa en el anlisis esa basado en un modelo de objetos conceptual denominado modelo de anlisis. Dicho modelo nos ayuda a refinar los requisitos. Adems ofrece un mayor poder expresivo y mayor formalizacin, y proporciona una estructura centrada en el mantenimiento, como la flexibilidad ante los cambios y la reutilizacin. Adems este modelo puede servir como entrada en las actividades de diseo e implementacin. En resumen el modelo de anlisis se puede considerar como una aproximacin al modelo de diseo. Debemos aclarar que en algunos casos quedan algunos detalles sin resolver, los cuales se dejan a la etapa de diseo e implementacin para su resolucin. 8.2.1 Por que el anlisis no es diseo ni implementacin El diseo tiene como fin el modelamiento del sistema y arquitectura y su forma real. hallar su forma, incluyendo su
Al respecto podemos decir:El diseo e implementacin son mucho mas que un simple anlisis y refinamiento y estructuracin de requisitos, pues hace realidad la forma del sistema. Por eso es recomendable que antes de pasar a un diseo e implementacin, se debe de contar con la comprensin detallada y precisa de los requisitos, y todo esto se consigue mediante el anlisis. El anlisis ayuda mucho en la divisin de los intereses, facilitando de esta manera el proceso de diseo e implementacin. 8.2.2 El objeto del anlisis: resumen La importancia de analizar los requisitos en la forma de un modelo de anlisis es importante por varios motivos: Un modelo de anlisis ofrece una especificacin mas precisa de los requisitos que la tenemos como resultado de la captura de requisitos, incluyendo el modelo de casos de uso. El modelo de anlisis es descrito con el lenguaje del desarrollador, e introduce mayor formalismo. Un modelo de anlisis estructura los requisitos de modo que facilita su comprensin, separacin, modificacin y mantenimiento. Un modelo de anlisis puede considerarse como primera aproximacin al modelo de diseo. 8.2.3 El papel del anlisis en el ciclo de vida del software Las primeras iteraciones de la elaboracin se centran en el anlisis. Eso contribuye a obtener una arquitectura estable y facilita una comprensin en profundidad de los requisitos. El propsito y objetivo del anlisis debe alcanzarse de algn modo en todo proyecto. Pero como los proyectos difieren unos de otros, segn el autor se distinguen tres tipos: 1. El proyecto usa el modelo de anlisis para describir los resultados del anlisis, y mantiene la consistencia de este modelo a lo largo de todo el ciclo de vida del software. 2. El proyecto utiliza el modelo de anlisis para describir los resultados del anlisis pero lo usa como herramienta transitoria e intermedia, es decir se puede actualizar el anlisis en la fase de diseo e implementacin. 3. El proyecto no utiliza en absoluto el modelo de anlisis para describir los resultados del anlisis. En cambio, el proyecto analiza los requisitos en el proceso de captura de requisitos o en el diseo. 8.4 Artefactos 14
8.4.1 Artefacto: modelo de anlisis La estructura impuesta por el modelo de anlisis se define mediante una jerarqua como se muestra en la siguiente figura.
Modelo de anlisis
Sistema de anlisis
Paquete de anlisis
Clase de anlisis
Realizacin de caso de uso-anlisis
El modelo de anlisis se representa mediante un sistema de anlisis que denota el paquete de ms alto nivel del modelo. La utilizacin de otros paquetes de anlisis es por tanto una forma de organizar el modelo de anlisis en partes ms manejables que representan abstracciones de subsistemas y posiblemente capas completas del diseo del sistema. 8.4.2 Artefactos: Clase del anlisis Una clase de anlisis representa una abstraccin de una o varias clases y/o subsistemas del diseo del sistema. Posee las siguientes caractersticas: Se centra en el tratamiento de los requisitos funcionales y pospone los no funcionales, denominndolos requisitos funcionales, hasta llegar a las actividades de diseo e implementacin subsiguientes. Raramente define u ofrece una interfaz en trminos de operaciones y de sus signaturas. Su comportamiento se rige mediante responsabilidades en una nivel ms alto y menos formal. Una responsabilidad es una descripcin textual de un conjunto cohesivo del comportamiento de una clase. Una clase de anlisis define atributos, aunque esos atributos tambin son de un nivelo bastante alto. Estos atributos son conceptuales y reconocibles en el dominio del problema. Participa en relaciones, aunque esas relaciones son ms conceptuales que sus contrapartidas de diseo e implementacin. Siempre encajan dentro de los 3 estereotipos bsicos: Interfaz, Control o Entidad, y cada estereotipo implica una semntica especifica Estos tres estereotipos estn estandarizados en UML y se utilizan para ayudar a los desarrolladores a distinguir el mbito de las diferentes clases, cada uno de estos estereotipos tiene una representacin diferente, como se ve en el siguiente grafico.
15
Clase de Entidad
Clase de interfaz
Clase de Control
8.4.2.1 Clase de Interfaz.- Las clases de interfaz se utilizaran para modelar la interaccin entre el sistema y sus actores. La interaccin puede ser de recibir(y presentar) informacin y recibir peticiones de (y a) los usuarios. Modelan las partes del sistemas que dependen de sus actores. Por lo general representan interfaces graficas de usuario (formularios, paneles,
interfaces de impresin etc.). 8.4.2.2 Clases de Entidad.- las clases de entidad se usan para modelar informacin que posee una vida larga y que es a menudo persistente. Las clases de entidad modelan la informacin y el comportamiento asociado de algn fenmeno o concepto, como una persona, un objeto del mundo real, o un suceso del mundo real. 8.4.2.3. Clases de Control.- Las clases de control representan coordinacin, secuencia, transacciones y control de otros objetos y se usan con frecuencia para encapsular el control de un caso de uso. Las clases de control tambin se utilizan para representar derivaciones y clculos complejos, como la lgica del negocio, que no puede asociarse con ninguna informacin concreta, de larga duracin y almacenada por el sistema. 8.4.3. Artefactos: realizacin de caso de uso-anlisis Es una colaboracin dentro del modelo de anlisis que describe cmo se lleva a cabo y se ejecuta un caso de uso determinado en trminos de las clases de anlisis y de sus objetos del anlisis en interaccin. 8.4.3.1. Diagrama de clases.- Una clase de anlisis y sus objetos participan en varias realizaciones de casos de uso, y algunas de las responsabilidades, atributos, y asociaciones de una clase suelen ser relevantes para una nica realizacin de caso de uso. Por tanto es importante durante el anlisis coordinar todos los requisitos sobre una clase y sus objetos que puedan tener diferentes casos de uso.
Modelo de casos de uso Modelo de anlisis <<trace>> Caso de uso Realizacin de caso de uso-anlisis Realizacin de caso de uso-anlisis Flujo de suceso-anlisis diagramas de clases diagramas de interaccin requisitos especiales
Participantes
Clase de anlisis
8.4.3.2. Diagramas de interaccin.- La secuencia de acciones en un caso de uso comienza cuando un actor invoca el caso de uso mediante el envi de algn tipo de mensaje al sistema. En un sistema, un objeto de interfaz recibir el mensaje del actor, el cual a su vez ser enviado a algn otro objeto, de esta manera los objetos implicados interactan para la realizacin del caso de uso. En esta se identifica secuencia de interaccin detallada y ordenadas cronolgicamente. En los diagramas de colaboracin se muestra las interacciones entre objetos creando enlaces entre estos y aadiendo mensajes a estos enlaces. En el anlisis se prefiere modelar 16
con diagramas de colaboracin ya el objetivo principal es identificar requisitos y responsabilidades. 8.4.3.3. Flujo de sucesos-anlisis.- En una realizacin de caso de uso pueden ser difciles de leer por si mismos, especialmente el los diagramas de colaboracin; de modo que puede ser til un texto adicional que lo explique. Este objeto debera escribirse en trminos de objetos de control.
8.4.3.4. Requisitos especiales.- Son descripciones textuales que recogen todos los requisitos no funcionales sobre una realizacin de caso de uso. 8.4.4. Artefacto: paquete del anlisis Los paquetes de anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas manejables. Un paquete de anlisis puede constar de clases de anlisis, de realizaciones de casos de uso, y de otros paquetes del anlisis (recursivamente) 8.4.4.1. Paquetes de servicio.- Aparte de proporcionar casos de uso a sus actores, todo sistema tambin proporciona un conjunto de servicios a sus clientes. Un cliente adquiere una combinacin de adecuada de servicios para ofrecer a sus usuarios los casos de uso necesarios para llevar a cabo un negocio. Estos servicios son un conjunto coherente de acciones relacionadas funcionalmente con un paquete de funcionalidad, que se utiliza en varios casos de uso. Los paquetes de servicio presentan algunas caractersticas: Contenido de un paquete de anlisis Paquete del anlisis Contiene un conjunto de clases relacionadas funcionalmente. Es indivisible. Depende de otro paquete de servicio. Normalmente slo es relevante para uno o unos pocos actores. Puede ser mutuamente excluyente con otro paquete. Son reutilizables.
Clase de anlisis
Realizacin de caso de uso-anlisis
8.4.5. Artefacto: descripcin de la arquitectura (vista del modelo de anlisis)
La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de anlisis, que muestra sus artefactos significativos para la arquitectura.
8.5. Trabajadores 8.5.1. Trabajador: arquitecto
17
Responsable de la integridad del modelo de anlisis, garantizando que ste sea correcto, consistente y legible como un todo. En sistemas grandes y complejos el arquitecto puede delegar el mantenimiento a otro trabajador, posiblemente a un ingeniero de componentes.
Arquitecto Responsable de
Ingeniero de casos de uso Responsable de
Vista de la arquitectura Descripcin de la arquitectura
Modelo de anlisis Responsabilidade s del arquitecto en el anlisis
Realizacin de caso de uso-Anlisis Responsabilidades del Ing. De casos de uso anlisis
8.5.2. Trabajador: ingeniero de casos de uso Responsable de la integridad de una o ms realizaciones de caso de uso, garantizando que cumplan los requisitos que recaen sobre ellos. Tambin es responsable del anlisis. 8.5.3. Trabajador: ingeniero de componentes Define y mantiene las responsabilidades, atributos relaciones, y requisitos especiales de una o varias clases de anlisis, asegurndose de que cada clase del anlisis cumpla los requisitos de acuerdo a las realizaciones de caso de uso en las que participa. Tambin mantiene la integridad de uno o varios paquetes del anlisis. 8.6. Flujo de trabajo
Es el comportamiento dinmico y ordenado y evolutivo del modelo de anlisis. 8.6.1. Actividad: anlisis de la arquitectura El propsito del anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identificacin de paquetes del anlisis, clases de anlisis evidentes y requisitos especiales comunes. 8.6.1.1 Identificacin de paquetes de anlisis (dividir el trabajo de anlisis).- los paquetes del anlisis proporcionan un medio para organizar el modelo de anlisis en piezas mas pequeas y mas manejables. Y posee las siguientes caractersticas: Gestin de los aspectos comunes entre paquetes del anlisis. Identificacin de paquetes de servicio. Definicin de dependencias entre paquetes del anlisis.
18
8.6.1.2 Identificacin de clases de entidad obvias.- Se identifican las clases principales que no necesitan de un anlisis muy profundo, es decir que estas clases se pueden identificar fcilmente. 8.6.1.3 Identificacin de requisitos especiales comunes.- Son requisitos que aparecen durante la fase del anlisis, que es necesario dar importancia para las fases de diseo e implementacin. Y presentan las siguientes restricciones. Persistencia Distribucin y concurrencia Caractersticas de seguridad Tolerancia a fallos Gestin de transacciones. 8.6.2 Actividad: analizar un caso de uso Se analiza un caso de uso para: Identificar las clases del anlisis cuyos objetos son necesarios para llevar a cabo el flujo de sucesos. Distribuir el comportamiento de caso de uso entre los objetos del anlisis que interactan. Capturar requisitos especiales sobre el caso de uso. Tambin a este proceso se le denomina: refinamiento de casos de uso. 8.6.2.1 Identificacin de clases del anlisis.- En este paso se identifican las clases de control, entidad e interfaz necesarias para realizar los casos de uso y esbozamos sus nombres, responsabilidades, atributos, y relaciones. 8.6.2.2 Descripcin de interacciones entre el objeto del anlisis.- Teniendo un esbozo de las clases necesarias, se debe hacer una descripcin de la interaccin de los objetos del anlisis, y se hacen mediante los diagramas de colaboracin, que contienen las instancias de los actores participantes, los objetos del anlisis y sus enlaces. 8.6.2.3 Captura de requisitos especiales.- En este paso recogeremos todos los requisitos sobre una realizacin de caso de uso que se identifican en el anlisis pero deberan tratarse en el diseo y en la implementacin, tales como los requisitos no funcionales. 8.6.3 Actividad: Analizar una clase Los objetivos de analizar de una clase son: Identificar y mantener las responsabilidades de una clase de anlisis, basadas en su papel en las realizaciones de caso de uso. Identificar y mantener los atributos y relaciones de la clase de anlisis. Capturar requisitos especiales sobre la realizacin de la clase de anlisis. 8.6.3.1 Identificar responsabilidades.- Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en diferentes realizaciones de caso de uso. Podemos identificar toas las realizaciones de caso de uso en las cuales participan las clases mediante el estudio de diagrama de clases y de interaccin. 8.6.3.2 Identificacin de atributos.responsabilidades de la clase. Los atributos son esenciales para definir las
8.6.3.3 Identificaciones de asociaciones y agregaciones.- Los diagramas de colaboracin estn compuestos de los objetos del anlisis y los enlaces, estos ltimos son instancias de 19
asociaciones entre las clases. Los enlaces pueden implicar la necesidad de referencias y agregaciones entre objetos. 8.6.3.4 Identificacin de generalizaciones.- Las generalizaciones se usan para extraer el comportamiento compartido y comn entre varias de las clases del anlisis diferentes. 8.6.3.5 Captura de requisitos especiales.- En este paso se recogen los requisitos de una clase del anlisis que se han identificado en el anlisis y sern tratados en la fase de diseo e implementacin (es decir requisitos no funcionales). 8.6.4 Actividad: Analizar un paquete Sus objetivos son: Garantizar que el paquete es lo ms independientemente posible de otros paquetes. Garantizar que el paquete cumple su objetivo de realizar algunas clases del dominio o casos de uso. Describir las dependencias de forma que pueda estimarse el efecto de los cambios futuros. Las siguientes son normas para realizar esta actividad: Definir y mantener las dependencias del paquete con otros paquetes cuyas clases contenidas estn asociadas con l. Asegurarse de que el paquete contiene las clases correctas, es decir que contenga clases que se relacionan funcionalmente. Limitar la dependencia con otros paquetes.
20
Preguntas: 1. Cuales son los estereotipos de una clase de anlisis: a) Comunicate, extends e include. b) Clase de Interfaz, clase de control, clase de entidad * c) Generalizacin, agregacin y dependencia. d) Asociacin, Generalizacin, include. 2. En un paquete de servicio, dos de sus caractersticas son: a) Es indivisible y reutilizable.* b) Depende de otros paquetes y no es divisible. c) No es excluyente con otro paquete. d) Son reutilizables y no dependen de otro paquete. 3. Los objetivos de analizar de una clase son: a) Identificacin de paquetes, identificacin de clases de entidad obvias e identificacin de requisitos especiales. b) Identificacin de de clases de anlisis, descripcin de interacciones, captura de requisitos especiales. c) Garantizar la independencia de paquetes, definir y mantener las dependencias del paquete, y describir la dependencia de paquetes. d) Identificacin de responsabilidades, identificacin de atributos, identificacin de generalizaciones.*
21
DISEO
9.1 INTRODUCCION Lo que se hace en el diseo es modelar el sistema, encontrar el modelo descuerdo al modelo que se realizo en el anlisis y debemos preocuparnos por conservarlo lo mas fielmente posible. El diseo tiene los siguientes propsitos: -Descomponer la implementacin por partes mas manejables que sean designados a equipos. Visualizar el diseo y tratar de encontrar una interfaz bien familiar para el usuario. 9.2 EL PAPEL DEL DISEO EN EL CICLO DE VIDA DEL SOFWARE El diseo es el centro de atencin al final de la fase de elaboracin y comienzo de las iteraciones de construccin. El modelo de diseo esta muy cercano ala implementacin. 9.3 ARTEFACTOS Artefacto :modelo de diseo Es un modelo de objetos describe la realizacin de los casos de uso centrndose en los requisitos y las restricciones que tenemos que tener en cuenta para nuestro sistema Se divide el sistema en subsistemas para hacer el modelo de diseo en porciones mas manejables. Artefacto: clase de diseo
Es una abstraccin sin costuras de una clase o construccin similar en la implementacin del sistema. El lenguaje que se utiliza es el mismo para especificar las clases del diseo y para el desarrollo del sistema en si. Se especifica de manera clara la visibilidad de nuestros atributos y mtodos es decir si es privado ,publico o protegido. Los mtodos de operacin de una clase de diseo tienen correspondencia directa con el correspondiente mtodo en la implementacin de clases .En la implementacin del mtodo se debe poner en pseudo cdigo o en lenguaje natural los comentarios. En una clase del diseo puede tener interfaces si el lenguaje de programacin se presta para ello . Artefacto: realizacin de caso de uso-diseo Es una colaboracin en el modelo del diseo que describe como se realiza un caso de uso especifico y como se ejecuta en trminos de clases de diseo y sus objetos. Una realizacin de casos de uso tiene una descripcin de flujo de eventos texual. Una realizacin de casos de uso diseo es la realizacin fsica de la realizacin de casos de uso anlisis teniendo en cuenta los requisitos y restricciones que se encontraron en el anlisis. a) Diagrama de clases :Las clases constan de atributos y operaciones estas participan en varias realizaciones de caso de uso donde se muestra las relaciones que exciten entre estas. b) Diagrama de interaccin: La secuencia de acciones de un caso de uso comienza cuando un actor invoca un caso de uso mediante un mensaje al sistema. En los diagramas de 22
secuencia se muestra la interaccin entre objetos o subsistemas que se envan mensajes, cada mensaje vendra a ser un procedimiento o una funcin con sus respectivos parmetros. c) Flujo de sucesos diseo: Los diagramas de realizacin de caso de uso, y especialmente los diagramas de interaccin ,son difciles de interpretar por si solos .por esto puede ser til este artefacto ,que es una descripcin textual que explica y complementa a los diagramas y a sus etiquetas .Este artefacto es til tambin cuando hay diagrama que representan flujos complejos o cuando la realizacin de casos de uso esta descrita por mltiples diagramas de interaccin. d) Requisitos de implementacin: es una descripcin textual de los requisitos dichos requisitos se capturan en la face de diseo pero que es mejor tratar en al implementacin Artefacto: subsistema del diseo :Estos artefactos son una forma de organizar los artefactos del modelo de diseo en piezas mas manejables, un subsistema puede constar en clases de diseo ,realizaciones de casos de uso, interfaces y otros subsistemas . Artefacto :interfaz: Se utiliza para especificar las operaciones que proporciona las clases y los subsistemas del diseo. Artefacto :descripcin de la arquitectura (vista del modelo del diseo):: La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de diseo que muestra sus artefactos relevantes para la arquitectura . Artefacto :modelo de despliegue: El modelo de despliegue es un modelo de objetos que describe la distribucin fsica del sistema en trminos de cmo se distribuye la funcionalidad ente los nodos de computo. Artefacto :descripcin de la arquitectura (vista del modelo de despliegue):Esta descripcin contiene una vista de la arquitectura del modelo de despliegue ,que muestra sus artefactos relevantes para la arquitectura . 9.4 TRABAJADORES 9.4.1 Trabajador :arquitecto.-es el encargado y responsable de la integridad de los modelos de diseo 9.4.2 Trabajador: ingeniero de casos de uso: es el encargado y responsable de la realizacin de uno o mas casos de uso diseo. 9.4.3 Trabajador :ingeniero de componentes: El ingeniero de componentes define y mantiene la operaciones ,mtodos ,atributos ,relaciones y requisitos en la implementacin de las clases.
9.5 Flujo de trabajo Veamos el siguiente diagrama de actividad para razonar sobre el comportamiento dinmico del trabajo
23
Los arquitectos crean los modelos de diseo y despliegue, es decir, los nodos, subsistemas y clases que estos implican. Despus, los ingenieros de casos de uso realizan cada caso de uso en trminos de clases y/o subsistemas y sus interfaces. Los ingenieros de componentes especifican luego los requisitos y los integran dentro de cada clase. La identificacin de nuevos subsistemas, interfaces, clases y mecanismos de diseo genrico se da a medida que evolucione el diseo, a lo largo del flujo de trabajo, por los desarrolladores, y los ingenieros de componentes responsables, debern refinarlos y mantenerlos. 9.5.1 Actividad: diseo de la arquitectura Su objetivo es esbozar los modelos de diseo y despliegue, y su arquitectura mediante la identificacin de los siguientes elementos: Nodos y sus configuraciones de red Subsistemas y sus interfaces Clases del diseo significativas (clases activas) Mecanismos de diseo genricos que tratan requisitos comunes Los arquitectos pueden considerar distintas posibilidades de reutilizacin de partes de sistemas parecidos, o de productos de software generales, tambin mantienen, refinan y actualizan la descripcin y vistas arquitectnicas de los modelos de diseo y despliegue. 9.5.1.1 Identificacin de nodos y configuraciones de red Las configuraciones de red habituales utilizan un patrn de tres capas en el cual los clientes se dejan en una capa, la funcionalidad de base de datos en otra, y la lgica del negocio o de la aplicacin en la tercera, entre sus aspectos podemos resaltar: Qu nodos se necesitan, y cul debe ser su potencia en trminos de potencia de proceso y tamao de memoria? Qu tipo de conexiones debe haber entre nodos, y que protocolos se han de utilizar? Qu caractersticas deben tener las conexiones y los protocolos de comunicaciones (ancho de banda, disponibilidad y calidad)? 24
Es necesario alguna capacidad de proceso redundante, modos de fallo, migracin de procesos o mantenimiento de copias de seguridad? Gracia a estas consideraciones, el arquitecto puede incorporar nuevas tecnologas que puedan hacer ms fcil la realizacin de la distribucin del sistema. 9.5.1.2 Identificacin de subsistemas y de sus interfaces Los subsistemas constituyen un medio para organizar el modelo de diseo en piezas manejables. Pueden identificarse inicialmente como forma de dividir el trabajo de diseo, o se pueden encontrar a medida que el modelo evoluciona; algunos subsistemas representan productos reutilizados y otros son recursos existentes en la empresa. 9.5.1.2.1 Identificacin de subsistemas de aplicacin.- En este paso identificamos los subsistemas de las capas especfica y general de la aplicacin. Si se hizo durante el anlisis una descomposicin adecuada en paquetes, podemos utilizar estos tanto como sea posible e identificar los correspondientes subsistemas dentro del modelo de diseo; puede ser necesario un refinamiento de esta descomposicin en los siguientes casos: Una parte de un paquete puede ser compartida y utilizada por otros subsistemas. Algunas partes de un paquete se realizan mediante software reutilizados. Los paquetes del anlisis no representan una divisin del trabajo adecuada. Los paquetes del anlisis no representan la incorporacin de un sistema heredado. Los paquetes del anlisis no estn preparados para una distribucin directa sobre los nodos. 9.5.1.2.2 Identificacin de subsistemas intermedios y de software del sistema.- El software del sistema y la capa intermedia constituyen los cimientos de un sistema. La seleccin e integracin de productos software son dos de los objetivos fundamentales durante las fases de inicio y elaboracin. El arquitecto verifica que los productos software encajan en la arquitectura y permiten una implementacin econmica del sistema. Es importante mantener una adecuada libertad de accin y evitar hacernos dependientes de un determinado producto de software, en caso que cambien en el futuro, o bien ser capaces de cambiar de fabricante si es necesario. 9.5.1.2.3 Definicin de dependencias entre subsistemas.- Las dependencias entre subsistemas se dan cuando sus contenidos tienen relaciones unos con otros, si no conocemos estos contenidos, consideraremos las dependencias entre los paquetes del anlisis que se corresponden con los subsistemas del diseo. La direccin de esta dependencia debe ser la misma que la direccin de la relacin (navegabilidad). 9.5.1.2.4 Identificacin de interfaces entre subsistemas.- Las interfaces proporcionadas por un subsistema definen operaciones que son accesibles desde fuera del subsistema, estas interfaces los proporcionan las clases u otros subsistemas dentro del subsistema (recursividad), adems de identificarlas, debemos conocer las operaciones que deben definirse sobre cada una de ellas, esto se hace mediante el diseo de casos de uso en trminos de subsistemas y de sus interfaces. 9.5.1.3 Identificacin de clases del diseo relevantes para la arquitectura Es prctico identificar las clases del diseo relevantes para la arquitectura dentro del ciclo de vida del software, sin embargo la mayora de las clases se identificarn durante el diseo de clases, y se refinarn de acuerdo a los resultados obtenidos en el diseo de casos de uso. Por esta razn, los desarrolladores deben evitar mucho detalle al 25
identificar las clases, una clase del diseo que no participe en ninguna realizacin de caso de uso es innecesaria. 9.5.1.3.1 Identificacin de clases del diseo a partir de clases de anlisis.Podemos esbozar inicialmente algunas clases del diseo partir de las clases del anlisis significativas para la arquitectura, tambin podemos usar las relaciones entre esas clases para identificar un conjunto de relaciones entre las correspondientes clases de diseo. 9.5.1.3.2 Identificacin de clases activas.- El arquitecto identifica las clases activas considerando requisitos de ocurrencia del sistema como: Rendimiento, tiempo de respuesta y disponibilidad en la interaccin de los actores con el sistema. Distribucin del sistema sobre los nodos Otros como el arranque y la terminacin del sistema, progresin, evitacin del interbloqueo y la inanicin, reconfiguracin y capacidad de los nodos. Cada clase activa se esboza mediante la consideracin del ciclo de vida y de, cmo deberan comunicarse, sincronizarse y compartir informacin sus objetos activos. Luego, se asignan los objetos activos a los nodos del modelo de despliegue. Para esbozar las clases activas, se puede usar resultados del anlisis y el modelo de despliegue como entradas y despus hacer corresponder los diseos de las respectivas clases del anlisis con los nodos. Cualquier clase activa que represente un proceso pesado es candidata para la identificacin de un componente ejecutable dentro de la implementacin. 9.5.1.4 Identificacin de mecanismos genricos de diseo En este paso estudiamos requisitos comunes y decidimos cmo tratarlos, teniendo en cuenta las tecnologas de diseo e implementacin disponibles. Los requisitos que deben tratarse suelen estar relacionados en aspectos como: Persistencia Distribucin transparente de objetos Caractersticas de seguridad Deteccin y recuperacin de errores Gestin de transacciones La mayora de los mecanismos genricos deberan ser identificados y diseados en la fase de elaboracin.
9.5.2. Actividad: Diseo de un caso de uso Los objetivos del diseo de un caso de uso son: Identificar las clases de diseo y/o los subsistemas que son necesaria para llevar acabo el flujo del caso de uso. Distribuir el comportamiento del caso de uso entre los objetos de diseo que interactan entre los subsistemas participantes. Definir los requisitos sobre las operaciones de las clases del diseo. 9.5.2.1. Identificacin de clases del diseo participantes.Para identificar las clases del diseo que se necesitan para realizar el caso de uso debemos hacer lo siguiente: 26
Estudiar las clases del anlisis que participan en la correspondiente realizacin del caso de uso-anlisis. Identificar las clases del diseo que realizan requisitos especiales. Identificar las clases necesarias y asignar una tarea al ingeniero de componentes. Si faltase alguna clase del diseo para un caso de uso en particular, el ingeniero de caso de uso debera comunicrselo a los arquitectos o ingeniero de componentes.
9.5.2.2. Descripcin de las interacciones entre objetos del diseo Cuando tenemos un esquema de las clases del diseo necesarias para realizar el caso de uso, debemos describir como interactan sus correspondientes objetos del diseo, esto se hace mediante diagramas de secuencia que contienen las instancias de los actores, los objetos del diseo y las transmisiones de mensajes entre estos, que participan en el caso de uso. Si los casos de uso suelen tener varios flujos o subflujos distintos, es til crear un diagrama de secuencia para cada uno de ellos. Para crear un diagrama de secuencia, debemos comenzar por el principio del flujo del caso de uso, y despus seguir ese flujo paso a paso decidiendo que objetos del diseo e interacciones son necesarias para realizar cada paso. Debemos observar lo siguiente sobre estos diagramas de secuencia. El causante de la invocacin del caso de uso es un mensaje de una instancia de un actor hacia un objeto del diseo. Cada clase del diseo identificada en el paso anterior debera tener al menos un objeto del diseo participante en el diagrama de secuencia. Los mensajes que realizan el caso de uso se envan entre lneas de vida de los objetos. La secuencia en el diagrama debera ser la principal preocupacin, ya que la realizacin del caso de uso-diseo es la entada principal para la implementacin del caso de uso. El diagrama de secuencias debera tratar todas las relaciones del caso de uso que realiza.
9.5.2.3. Identificacin de subsistemas e interfaces participantes Alguna veces es mas apropiado disear un caso de uso en trminos de los subsistemas o interfaces que participan en el. Por ejemplo, en el desarrollo descendente, puede que sea necesario captura los requisitos sobre los subsistemas y sus interfaces antes de haber diseado sus contenidos, o en algunos casos debera ser fcil sustituir un subsistema y su diseo interno particular por oto sistema que tenga otro diseo distinto. Para comenzar, es necesario identificar los subsistemas necesarios para realizar el caso de uso mediante los siguientes pasos: Identificar los paquetes del anlisis que contienen a esas clases del anlisis y luego identificar los subsistemas del diseo que poseen una traza hacia esos paquetes del anlisis. Identificar las clases que realizan requisitos especiales y los subsistemas que los contienes a esas clases.
9.5.2.4. Descripcin de interacciones ente subsistemas
27
Cuando tenemos un esbozo de los subsistemas necesarios para realizar el caso de uso, debemos describir como interactan los objetos de las clases que contiene en el nivel de subsistema, lo haremos mediante diagramas de secuencia que contengan las instancias de actores, subsistemas y transmisiones de mensajes entre estos que participan. Al hacerlo, utilizaremos una tcnica similar a la descrita en la seccin 5.2.2 con las siguientes diferencias: Las lneas de vida, en los diagramas de secuencia denotan subsistemas en lugar de objetos de diseo. Cada subsistema identificado en la seccin 5.2.3 debera tener al menos una lnea de vida que lo denote en un diagrama de secuencia. Si asignamos un mensaje a una operacin de una interfaz, puede resultar ser apropiado cualificar el mensaje con el interfaz que proporciona la operacin.
9.5.2.5. Captura de requisitos de implementacin En este paso incluimos en la realizacin del caso de uso todos los requisitos identificados guante el diseo que deberan tratarse en la implementacin, como los requisitos no funcionales. 9.5.3. Actividad: diseo de una clase El propsito de disear una clase es crear una clase del diseo que cumpla su papel en la realizacin de los casos de uso y los requisitos no funcionales que se aplican a estos. Esto incluye el mantenimiento del diseo de clase en si mismo y los siguientes aspectos de este: Sus operaciones Sus atributos Las relaciones en las que participa Sus mtodos Los estados impuestos Sus dependencias con cualquier mecanismo del diseo genrico Los requisitos relevantes a su implantacin La correcta realizacin de cualquier interfaz requerida
9.5.3.1 Esbozar la clase del diseo Como un primer paso necesitamos esbozar una o varias clases del diseo, dada la entrada en trminos de clases de anlisis cuando tomamos una interfaz como entrada, suele se simple y directo el asignar a una clase de diseo para que proporcione esa interfaz. Cuando se dan como entrada una o varias clases del anlisis los mtodos utilizados dependen del estereotipo de la clase de anlisis: Disear clases de interfaz es dependiente de la tecnologa de interfaz que se utilice. Disear las clases de entidad que representan informacin persistente a menudo implica el uso de tecnologas de bases de datos especficas. Disear clases de control es una tarea delicada, debido a que encapsulan secuencias, coordinacin de otos objetos, es necesario considerar los siguientes aspectos: 28
1. Aspectos de distribucin, si la secuencia necesita ser distribuida y manejada por diferentes nodos de una red. 2. Aspectos de rendimiento, puede que no sea justificable tener clases del diseo separadas para realizar la clase de control. 3. Aspectos de transaccin, las clases de control a menudo encapsulan transacciones, sus correspondientes diseos deben incorporar cualquier tecnologa de manejo de transaccin existente que se este utilizando. 9.5.3.2 Identificar Operaciones En esta etapa identificaremos las operaciones que las clases de diseo va a necesitar y describimos esas operaciones utilizando la sintaxis de los lenguajes de programacin y algunas entradas importantes en esta etapa son: Las responsabilidades de cualquier clase del anlisis que tenga una traza con la clase del diseo, una responsabilidad implica una o varias operaciones. Los requisitos especiales de cualquier clase de anlisis que tenga una traza con la clase del diseo. Las interfaces que las clases de diseo necesita proporcionar. La realizacin del caso de uso-diseo en las que la clase participa.
9.5.3.3 Identificar Atributos En este paso identificamos los atributos requeridos por la clase de diseo y los describimos usando la sintaxis del lenguaje de programacin usada. Un atributo especifica una propiedad de una clase de diseo, para identificar los atributos tomamos en cuenta las siguientes normas: Considerar los atributos sobre cualquier clase de anlisis que tenga una traza con la clase de diseo. los tipos de atributos disponibles estn restringidos por le lenguaje de programacin. Cuando se elige un tipo de atributo, intentar reutilizar uno que ya exista. Una simple instancia de atributo no puede ser compartida por varios objetos de diseo. Si una clase de diseo llega a ser muy complicada de comprender por culpa de sus atributos, algunos de estos atributos pueden ser separados en clase independientes. Si hay muchos atributos o son complejos los atributos de una clase, se puede ilustrar esta en un diagrama de clases separado que muestre solamente el apartado de atributos.
9.5.3.4 Identificar Asociaciones y Agregaciones Los objetos de diseo interactan unos con otros en los diagramas de secuencia estas interacciones a menudo requieren asociaciones entre las clases correspondientes. Las instancias de las asociaciones deben ser utilizadas para abarcar las referencias con otros objetos y para agregar operaciones en agregaciones con el propsito de enviarles mensajes. El nmero de relaciones entre clases debe estar minimizado. Deben tenerse en cuenta las siguientes: a la hora de definir y redefinir las asociaciones y agregaciones:
29
9.5.3.5 Identificar las generalizaciones
Considerar la agregaciones y asociaciones involucrando la correspondiente clase de anlisis Refinar la multiplicidad de las asociaciones, Nombres de rol, clases de asociacin, roles d ordenacin, roles de cualificacin y asociaciones n-arias de acuerdo con el soporte de lenguaje de programacin utilizada. Considerar los diagramas de interaccin en los que se emplea asociaciones
Las generalizaciones deben ser utilizadas con la misma semntica definida en lenguaje de programacin, si el lenguaje de programacin no admite generalizacin o herencia, las asociaciones y agregaciones deben utilizarse en lugar de este. 9.5.3.6.-Describir los mtodos Los Mtodos pueden ser utilizados durante el diseo para especificar como se deben realizar las operaciones. 9.5.3.7.-Describir los Estados Algunos objetos de diseo son estados controlados, lo que significa que sus estados determinan su comportamiento cuando reciben un mensaje. 9.5.3.8.-Tratar requisitos especiales En esta fase debe ser tratado cualquier requisito que no haya sido considerado en pasos anteriores, cuando se hace esto debemos estudiar los requisitos formulados en la realizacin de los casos de uso en lo que la clase participa. 9.5.4.-Actividad: Diseo de un Subsistema Los Objetos de diseo de un subsistema son: Garantizar que el subsistema sea independiente como sea posible de otros subsistemas. Garantizar que el subsistema proporcione las interfaces correctos. Garantizar que el subsistema cumpla con su propsito de ofrecer una realizacin correcta. 9.5.4.1.-Mantenimiento de las dependencias entre subsistemas Se definen y mantienen dependencias de en un subsistema respecto otros cuando los elemento s contenidos en estos estn asociados con el elemento dentro de aquel otro. Las dependencias de usos deberan declararse hacia a los interfaces que en vez de hacia los propios subsistemas. 9.5.4.2.-Mantenimiento de Interfaces proporcionados por el Subsistema Las Operaciones definidas por la s interfaces que proporciona un subsistema deben soportar todos los roles que cumple el subsistema en las diferentes realizaciones de un caso de uso. 9.5.4.3.-Mantenimiento de los contenidos de los subsistemas Un subsistema cumple sus objetivos cuando ofrece una realizacin correcta de las operaciones tal y como estn descritas por las interfaces que proporciona. An cuando haya sido realizado por el arquitecto los contenidos de los subsistema.
Preguntas: 1.-Que es un diagrama de clases? 30

Son las relaciones que existen entre las clases ,las clases constan de atributos y operaciones estas participan en varias realizaciones de caso de uso donde se muestra las relaciones que exciten entre estas.
2.-De que se encarga el ingeniero de casos de uso.? Es el encargado y responsable de la realizacin de uno o mas casos de uso diseo. 3.-Cul es el objetivo del diseo de la arquitectura? Esbozar los modelos de diseo, de despliegue y su arquitectura. 4.- Qu son los casos de usos reales? 5.- Qu normas tomamos para identificar los atributos?
31
Captulo X Implementacin 10.1.- Introduccin En la implementacin empezamos con el resultado del diseo e implementamos el sistema en trminos de componentes, es decir, ficheros de cdigo fuente, scripts, ficheros de cdigo binario, ejecutables y similares. Afortunadamente, la mayor parte de la arquitectura del sistema es capturada durante el diseo, siendo el propsito principal de la implementacin el desarrollar la arquitectura y el sistema como un todo. Deforma ms especfica, los propsitos de la implementacin son: Planificar las integraciones de sistema necesarias en cada iteraccin. Seguimos para ello un enfoque incremental, lo que da lugar a un sistema que se implementa en una sucesin de pasos y manejables. Distribuir el sistema asignando componentes ejecutables a nodos en el diagrama de despliegue. Esto se basa fundamentalmente en las clases activas encontradas durante el diseo. Implementar las clases y subsistemas encontrados durante el diseo. En particular, las clases se implementan como componentes de fichero que contienen cdigo fuente. Probar los componentes individualmente, y a continuacin integrarlos compilndolos y enlazndolos en uno o ms ejecutables, antes de ser enviados para ser integrados y llevar a cabo las comprobaciones de sistema.
10.2.- El Papel de la Implementacin en el Ciclo de Vida del Software La implementacin es el centro durante las iteraciones de construccin, aunque tambin se lleva acabo de implementacin durante la fase de elaboracin, para crear la lnea base ejecutable de la arquitectura, y durante la fase de transicin, para tratar defectos tardos como los encontrados con distribuciones beta del sistema. Ya que el modelo de implementacin denota la implementacin actual del sistema en trminos de componentes y subsistemas de implementacin, es natural mantener el modelo de implementacin a lo largo de todo el ciclo de vida del software. 10.3.- Artefactos 10.3.1.- Artefacto: Modelo de Implementacin El modelo de implementacin describe cmo los elementos del modelo de diseo, como las clases, se implementan en trminos de componentes, como ficheros de cdigo fuente, ejecutables, etctera. El modelo de implementacin describe tambin cmo se organizan los componentes de acuerdo con los mecanismos de estructuracin y modularizacin disponibles en el entorno de implementacin y en el lenguaje o lenguajes de programacin utilizados, y cmo dependen los componentes unos de otros. El modelo de implementacin de fine una jerarqua.
32
El modelo de implementacin se representa con un sistema de implementacin que denota el subsistema de nivel superior del modelo. El utilizar otros subsistemas es pro tanto una forma de organizar el modelo de implementacin en trozos ms manejables.
10.3.2.- Artefacto: Componente Un componente es le empaquetamiento Fsico de los elementos de un modelo, como son las clases en el modelo de diseo. Algunos estereotipos estndar de componentes son los siguientes: executable es un programa que puede ser ejecutado en un nodo. file es un fichero que contiene cdigo fuente o datos. library es una librera esttica o dinmica. table es una tabla de base de datos. document es un documento.
10.3.3.- Artefacto: Subsistema de Implementacin Los subsistemas de implementacin proporcionan una forma de organizar los artefactos del modelote implementacin en trozos ms manejables. Un subsistema puede estar formado por componentes, interfaces y otros subsistemas (recursivamente). Adems, un subsistema puede implementar y as proporcionar las interfaces que representan la funcionalidad que exportan en forma de operaciones. Es importante entender que un subsistema de implementacin se manifiesta a travs de un mecanismo de empaquetamiento concreto en un entorno de implementacin determinado, tales como: Un paquete en Java. Un proyecto en Visual Basic. Un directorio de ficheros en un proyecto de C++. Un subsistema en un entorno de desarrollo integrado como Rational Apex. Un paquete en una herramienta de modelado visual como Rational Rose.
10.3.4.- Artefacto: Interfaz Las interfaces pueden ser utilizadas en el modelo de implementacin para especificar las operaciones implementadas por componentes y subsistemas de implementacin. Adems, como se mencion anteriormente, los componentes y los subsistemas de implementacin pueden tener dependencias de uso sobre interfaces. Un componente que implementa (y por tanto proporciona) una interfaz ha de implementar correctamente todas las operaciones definidas por la interfaz. Un subsistema de implementacin que proporciona una interfaz tiene tambin que contener componentes que proporcionen la interfaz u otros subsistemas (recursivamente) que proporcionen la interfaz. 10.3.5.- Artefacto: Descripcin de Arquitectura (Vista del Modelo de Implementacin) La descripcin de arquitectura contiene una visin de la arquitectura del modelo de implementacin, el cual representa sus artefactos significativos arquitectnicamente. 33
Los siguientes artefactos son usualmente considerados en el modelo de implementacin significativos arquitectnicamente: La descomposicin del modelo de implementacin en subsistemas, su interfaces y las dependencias entre ellos. En general, esta descomposicin es muy significativa para la arquitectura. Sin embargo, ya que los subsistemas de implementacin siguen la traza de los subsistemas de diseo uno a uno y los subsistemas de diseo sern muy probablemente representados en la vista de la arquitectura del modelo de diseo, usualmente es innecesario representar los subsistemas de implementacin en la vista de la arquitectura del modelo de implementacin. Componentes clave, como los componentes que siguen la traza de las clases de diseo significativas arquitectnicamente, los componentes ejecutables y los componentes que son generales , centrales, que implementan mecanismos de diseo genricos de los que dependen muchos otros componentes.
10.3.6.- Artefacto: Plan de Integracin de Construcciones Es importante construir el software incrementalmente en pasos manejables, de forma que cada paso de lugar a pequeos problemas de integracin o prueba. El resultado de cada paso es llamado construccin, que es una versin ejecutable del sistema, usualmente una parte especfica del sistema. Cada construccin es entonces sometida a pruebas de integracin antes de que se cree ninguna otra construccin (por ejemplo, si no pasa las pruebas de integracin) se lleva un control de versiones de forma que pueda volver atrs a una construccin anterior. Los beneficios de este enfoque incremental son los siguientes: Se puede crear una versin ejecutable del sistema muy pronto, en lugar de tener que esperar a una versin ms completa. Las pruebas de integracin comienzan pronto, y las versiones ejecutables pueden ser utilizadas para hacer demostraciones de las caractersticas del sistema tanto a los participantes directos en el proyecto como a otras personas involucradas en l. Es ms fcil localizar defectos durante las pruebas de integracin, porque slo se aade o refina en una construccin existente una parte pequea y manejable del sistema. Incluso mejor, los defectos sern muy probablemente (aunque no siempre) relacionados con la parte nueva o refinada. Las pruebas de integracin tienden a ser ms minuciosas que las pruebas del sistema completo porque se centran en partes ms pequeas y ms manejables.
10.4.- Trabajadores 10.4.1.- Trabajador: Arquitecto Durante la fase de implementacin, el arquitecto es responsable de la integridad del modelo de implementacin y asegura que el modelo como un todo es correcto, completo y legible. Como el anlisis y el diseo, para sistemas grandes y complejos puede introducirse un trabajador adicional para asumir la responsabilidad del subsistema de nivel ms alto (es decir, el sistema de implementacin) del modelo de implementacin. El modelo es correcto cuando implementa la funcionalidad descrita en le modelo de diseo y en los requisitos adicionales (relevantes), y slo esta funcionalidad. El arquitecto es responsable tambin de la arquitectura del modelo de implementacin, es decir, de la existencia de sus partes significativas arquitectnicamente como se represent en 34
la vista de la arquitectura del modelo de despliegue. Recordemos que esta vista es parte de la descripcin de la arquitectura del sistema. Por ltimo, un resultado importante de la implementacin es la asignacin de componentes ejecutables a nodos. El arquitecto es responsable de esta asignacin, la cual se representa en la vista de la arquitectura del modelo de despliegue. Obsrvese que el arquitecto no es responsable del desarrollo en marcha ni del mantenimiento de los diversos artefactos en el modelo de implementacin; por el contrario, esto es responsabilidad del ingeniero de componentes correspondiente. 10.4.2.- Trabajador: Ingeniero de componentes El ingeniero de componentes define y mantiene el cdigo fuente de uno o varios componentes garantizando que cada componente implementa la funcionalidad correcta (por ejemplo, como especifican las clases de diseo) . A menudo, el ingeniero de componentes tambin mantiene la integridad de uno o varios subsistemas de implementacin. Ya que los subsistemas de implementacin siguen la traza uno a uno a los subsistemas de diseo, la mayora de los cambios en estos subsistemas tienen lugar durante el diseo. Sin embargo, el ingenierote componentes necesita garantizar que los contenidos (por ejemplo, los componentes) de los subsistemas de implementacin son correctos, que sus dependencias con otros subsistemas o interfaces son correctas y que implementan correctamente las interfaces que proporcionan. 10.4.3.- Trabajador: Integrador de Sistemas La integracin del sistema est ms all del mbito de cada ingeniero de componentes individual. Por el contrario, esta responsabilidad recae sobre el integrador de sistemas. Entre sus responsabilidades se incluye el planificar la secuencia de construcciones necesarias en cada interaccin y la integracin de cada construccin cuando sus partes han sido implementadas. La planificacin da lugar a un plan de integracin de construcciones. 10.5.- Flujo de Trabajo En las secciones anteriores hemos descrito el trabajo de implementacin de forma esttica. A continuacin utilizaremos un diagrama de actividades para razonar su comportamiento dinmico. El objetivo principal de la implementacin es implementar el sistema. Este proceso es iniciado por el arquitecto esbozando los componentes clave en el modelo de implementacin. A continuacin, el integrador de sistemas planea las integraciones de sistema necesarias en la presente iteracin como una secuencia de construcciones. Para cada construccin, el integrador de sistemas describe la funcionalidad que debera ser implementada y que partes del modelo de implementacin (es decir, subsistemas y componentes) se vern afectadas. 10.5.1.- Actividad: implementacin de la arquitectura El propsito de la implementacin de la arquitectura es esbozar el modelo de implementacin y su arquitectura mediante: La identificacin de componentes significativos arquitectnicamente, tales como componentes ejecutables. La asignacin de componentes a los nodos en las configuraciones de redes relevantes. 35
10.5.1.1.- Identificacin de los componentes significativos arquitectnicamente A menudo resulta prctico identificar pronto en el ciclo de vida del software los componentes significativos arquitectnicamente, para iniciar as el trabajo de implementacin. Los desarrolladores deberan tener cuidado de no identificar demasiados componentes en esta etapa ni ahondar en demasiados detalles. De lo contrario, gran parte del trabajo habr de volverse a hacer cuando se implementen las clases. Tambin es importante la identificacin de componentes ejecutables y asignacin a nodos.
10.5.1.- Actividad: integrar el sistema Los objetivos de la integracin del sistema son: Crear un plan de integracin de construcciones que describa las construcciones necesarias en una iteracin y los requisitos de cada construccin. Integrar cada construccin antes de que sea sometida a pruebas de integracin.
10.5.2.- Planificacin de una construccin En esta seccin discutimos como planificar los contenidos de una construccin, independientemente de que partamos de una construccin previa o de que no partamos de ninguna. Suponemos que tenemos un numero de casos de uso o escenarios (es decir, camino a travs de casos de uso) y otros requisitos que han de ser implementados en la iteracin actual. Entre los criterios para crear una construccin tenemos: Una construccin debera aadir funcionalidad a la construccin previa implementando casos de uso completos o escenarios de stos. Una construccin no debera incluir demasiados componentes nuevos refinados. Si no es as, puede ser muy difcil integrar la construccin y llevar a cabo las pruebas de integracin. Una construccin debera estar basada en la construccin anterior, y debera expandirse hacia arriba y hacia los lados en la jerarqua de subsistemas. Manteniendo estos criterios en mente, uno puede empezar a evaluar los requisitos, tales como los casos de uso, que han de ser implementados. Obsrvese probablemente ser necesario un compromiso para cumplir de forma apropiada estos criterios. Para cada caso de uso que pueda ser implementado hgase lo siguiente: 1. Considera el diseo del caso de uso, identificando su realizacin de caso de uso-diseo correspondiente en el modelo de diseo. 2. Identificar los subsistemas y clases de diseo que participan en la realizacin de caso de uso-diseo. 3. Identificar los subsistemas y componentes de implementacin en el modelo de implementacin que siguen la traza de los subsistemas y clases de diseo encontrados en el paso 2. 4. Considerar el impacto de implementar los requisitos de estos subsistemas de implementacin y de los componentes sobre la construccin en cuestin. Obsrvese que estos requisitos se especifican como subsistemas y clases de diseo, como se hizo notar en el paso 3. 36
Los resultados deberan estar recogidos en el plan de integracin de la construccin y ser comunicados a los ingenieros de componentes responsables de los subsistemas y componentes de implementacin afectados. 10.5.2.2.- Integracin de una construccin Si la construccin ha sido planificada cuidadosamente como se describe en la seccin anterior debera ser fcil integrar la construccin. 10.5.3.- Integracin de una construccin El propsito de implementar un subsistema es el de asegurar que un subsistema cumple su papel en cada construccin, tal y como se especifica en el plan de integracin de la construccin. 10.5.3.1.- Mantenimiento de los contenidos de los subsistemas Un subsistema cumple su propsito cuando los requisitos a ser implementados en la construccin actual y aquellos que afectan al subsistema estn implementados correctamente por componentes dentro del subsistema. 10.5.4.- Actividad: Implementar una clase El propsito de la implementacin de una clase es implementar una clase de diseo en un componente fichero. Esto incluye lo siguiente: Esbozo de un componente fichero que contendr el cdigo fuente. Generacin de cdigo fuente a partir de la clase de diseo y de las relaciones en que participa. implementacin de las operaciones de la clase de diseo en forma de mtodos. Comprobacin de que el componente proporciona las mismas interfaces que la clase de diseo.
10.5.5.- Actividad: Realizar prueba de unidad El propsito de realizar la prueba de unidad es probar los componentes implementados como unidades individuales. Se levan a cabo los siguientes tipos de pruebas de unidad: La prueba de especificacin, o prueba de caja negra, que verifica el comport amiento de la unidad observable externamente La prueba de estructura, o prueba de caja blanca, que verifica la implementacin interna de la unidad.
Obsrvese que puede haber tambin otras pruebas que realizar sobre las unidades, como pruebas de rendimiento, utilizacin de memoria, carga y capacidad. Adems, han de ser realizadas las pruebas de integracin y sistema para asegurar que los diversos componentes se comportan correctamente cuando se integran. Preguntas propuestas: 1. Cules son los artefactos de la implementacin? 2. Cules son los estereotipos estndar de los componentes? 37
3. Quines son los trabajadores durante la fase de implementacin?
38
Capitulo XI: Prueba INTRODUCCION: En este capitulo se verifica el resultado de la Implementacin probando cada construccin incluyendo tanto construcciones internas como intermedias. Mas concretamente los objetivos de la prueba son: -Planificar las pruebas necesarias en cada iteracin, incluyendo las pruebas de integracin y de sistema. Las pruebas de integracin son necesarias para cada construccin dentro de cada iteracin, mientras que las pruebas de sistema son necesarias solo al final de la iteracin. -Disear e implementar las pruebas creando los casos de prueba, procedimientos de prueba y si es posible los componentes de prueba. -Realizar las diferentes pruebas y manejar los resultados de cada prueba sistemticamente y si se encuentra algn error ser probada de nuevo o sino sern devueltas a otro flujo. EL PAPEL DE LA PRUEBA EN EL CICLO DE VIDA DEL SOFTWARE: Durante la fase de inicio se puede hacer la planificacin inicial de las pruebas cuando se define el mbito del sistema, y llevara a cabo las pruebas cuando una construccin es sometida a pruebas de integracin y de sistema. Es por eso que las pruebas se centran en la fase de elaboracin y construccin. Por consiguiente, es natural mantener el modelo de pruebas a lo largo del ciclo de vida del software completo, las pruebas cambian constantemente debido a: -La eliminacin de casos de prueba obsoletos. -El refinamiento de algunos casos de prueba en casos de prueba de regresin. -La creacin de nuevos caso de uso para cada nueva construccin. ARTEFACTOS ARTEFACTO: MODELO DE PRUEBAS Describe como se prueban los componentes ejecutables (como las construcciones) en el modelo de implementacin con pruebas de integracin y de sistema, este describe tambin como han de ser probadas aspectos especficos del sistema. El modelo de prueba es una coleccin de casos de prueba, procedimientos de prueba y componentes de prueba. ARTEFACTO: CASO DE PRUEBA Especifican una forma de probar el sistema incluyendo la entrada o resultado con la que se ha de probar y las condiciones bajo las cuales hay que probar, los casos de prueba comunes son: -Un caso de prueba que especifica como probar un caso de uso o el escenario del caso de uso, este analiza el comportamiento observable externamente del sistema. -Otro que especifique como probar la realizacin de un caso de uso o un escenario especifico del caso de uso, es decir es una prueba de interaccin interna entre los componentes del sistema. Hay otros tipos de casos de uso de prueba, para probar el sistema como un todo: -Pruebas de Instalacin, verifican que el sistema puede ser instalado en la plataforma de cliente, y que el sistema puede funcionar correctamente cuando sea instalado. -Las pruebas de configuracin, verifican si el sistema funciona correctamente en diferentes configuraciones. 39
-las pruebas negativas, intentan provocar que el sistema falle para poder as revelar sus debilidades. -Las pruebas de tensin o de estrs, identifican problemas con el sistema cuando hay recursos insuficientes. ARTEFACTO: PROCEDIMIENTO DE PRUEBA Especifica como realizar uno o varios casos de prueba o partes de estos. El como llevara a cabo un caso de prueba puede ser especificado por u procedimiento de prueba para varios casos de prueba o un caso de prueba.
1..*
1..*
X Caso de Prueba
Procedimiento de Prueba
ARTEFACTO: COMPONENTE DE PRUEBA Este automatiza uno o varios procedimientos de prueba o partes de ellos, pueden ser desarrollados utilizando un lenguaje de programacin o puede ser grabados utilizando una herramienta de pruebas. Se usan para probar los componentes en el modulo de implementacin, proporcionando entradas de prueba informando los resultados de las pruebas. En ingles se le llama Test Drivers.
1..*
1..* X
Componente de prueba de prueba
Procedimiento
ARTEFACTO: PLAN DE PRUEBA El plan de prueba describe las estrategias, recursos y planificacin de la prueba, la estrategia de prueba incluye la definicin del tipo de pruebas a realizar para cada iteracin y sus objetivos. ARTEFACTO: DEFECTO Un defecto es una anomala del sistema, este es utilizado para localizar cualquier cosa que lo desarrolladores necesitan como sntoma de un problema. ARTEFACTO: EVALUACION DE PRUEBA Es una evaluacin de resultados de los esfuerzos de prueba, tales como la cobertura del caso de prueba y otros.
TRABAJADORES TRABAJADOR: DISEADOR DE PRUEBA Es el responsable de la integridad del modelo de pruebas asegurando que el modelo cumpla con el propsito. Estos deciden los objetivos de prueba apropiados y la planificacin de pruebas. 40
Estos se dedican a la preparacin y evaluacin de las mismas. Otros dos tipos de trabajadores, los Ingenieros de prueba de integracin y los Ingenieros de pruebas de sistema, son los encargados de llevarlas acabo. TRABAJADOR: INGENIERO DE COMPONENTES Son responsables de los componentes de prueba que automatizan algunos de los procedimientos de prueba. Se realizan para verificar que los componentes integrados en una construccin funcionan correctamente juntos. Estos derivan a menudo de los casos de prueba. El Ingeniero de pruebas documenta los defectos en los resultados de las pruebas de Integracin. TRABAJADOR: INGENIERO DE PRUEBAS DE SISTEMAS Se lleva a cabo para verificar las interacciones entre los actores y el sistema por eso estos se derivan de los casos de prueba que especifican como probar los casos de uso. El Ingeniero documenta los defectos en los resultados de prueba de Sistemas, estos deben conocer el funcionamiento interno del sistema, alguna pruebas pueden ser realizados por otrazo miembros del proyecto. FLUJO DE TRABAJO Ahora utilizaremos los diagramas de Actividad para razonar su comportamiento dinmico. El principal objetivo de la prueba es realizar y evaluar las pruebas como se describe en el modelo de pruebas. ACTIVIDAD: PLANIFICAR PRUEBA El propsito de planificacin de la prueba es planificar los esfuerzos de prueba en una iteracin llevando a cabo las siguientes tareas: -Describiendo una estrategia de prueba. -Estimando los requisitos para el esfuerzo de la prueba. -Planificando el esfuerzo de la prueba. ACTIVIDAD: DISEAR PRUEBA Los propsitos de disear las pruebas son: -Identificar y describir los casos de prueba para cada construccin. -Identificar y estructurar los procedimientos de prueba especificando como realizar los casos de prueba. A) Diseo de los Casos de Prueba de Integracin Se utilizan para verificar que los componentes interacciona entre si de la forma apropiada despus de haber sido integrados en una construccin. Estos pueden ser derivados de las realizaciones de casos de uso-diseo. Cuando los diseadores crean los casos de prueba de integracin consideran como entrada en primer orden a los diagramas de interaccin de las realizaciones de casos de uso. B) Diseo de los Casos de Prueba de Sistema Se usan para probar que el sistema funciona correctamente como un todo, cada prueba de sistema prueba principalmente combinaciones de casos instanciados bajo condiciones diferentes. Los diseadores de prueba deberan dar prioridad a las combinaciones de los casos de uso que: -Se necesita que funcione en paralelo. -Posiblemente funcione en paralelo. -Posiblemente se influencian mutuamente si se ejecutan en paralelo. -Involucran varios procesadores 41
-Usan frecuentemente recursos del sistema. C) Diseo de los Casos de Prueba de Regresin Algunos casos de uso implementados anteriormente pueden ser usados para pruebas de regresin en construcciones. Para que este diseo funcione bien y sea de calidad el sistema, estos deben ser los suficientemente flexibles, solo se debe convertir a casos de prueba de regresin cuando el esfuerzo merezca la pena. D) Identificacin y Estructuracin de los Procedimientos de Prueba Los diseadores de prueba tambin intentan crea procedimientos de prueba que puedan ser reutilizados en varios casos de prueba, esto permite usar un conjunto reducido de procedimientos de prueba con rapidez y precisin para muchos casos de prueba. Cada caso de prueba precisara varios procedimientos de prueba, quizs uno por cada subsistema de servicio probado en el caso de pruebas. ACTIVIDAD: IMPLEMENTAR PRUEBA El propsito es automatizar los procedimientos de prueba creando componentes de prueba si esto es posible, pero no todos pueden ser automatizados. Los componentes de prueba se crean usando procedimientos e prueba como entrada. -Cuando usamos las herramientas de automatizacin de pruebas realizamos o especificamos las acciones como se describe en los procedimientos de prueba. -Cuando programamos los componentes de prueba explcitamente usamos los procedimientos de prueba como especificaciones iniciales. Los componentes de prueba usan casi siempre grandes cantidades de datos de entrada para ser probados y producen grandes cantidades de datos de salida como resultado de las pruebas. ACTIVIDAD: REALIZAR PRUEBAS DE INTEGRACION Se realizan las pruebas de integracin necesarias para cada una de las construcciones realizadas en una iteraron y se recopilan los resultados de las pruebas. Las pruebas de integracin se llevan a cabo con los siguientes pasos: -Realizar dichas pruebas relevantes a la construccin realizando los procedimientos de prueba manualmente para cada caso de prueba. -Compara los resultados de las pruebas con los resultados esperados. -Informar de los defectos a los ingenieros de componentes. -Informar de los defectos a los diseadores de pruebas quienes usan los defectos para evaluar los resultados del esfuerzo de prueba. ACTIVIDAD: REALIZAR PRUEBA DE SISTEMA El propsito es realizar las pruebas de sistema necesarias en cada iteracin y el recopilar el resultado de las pruebas. Estas empiezan cuando las pruebas de integracin indican que el sistema satisface los objetivos de calidad de integracin, esta se realiza de forma anloga a la forma en que se realiza la prueba de integracin. ACTIVIDAD: EVALUAR PRUEBA El propsito es el evaluar los resultados de prueba en una iteracin, los diseadores evalan comparando los resultados obtenidos con los objetivos esbozados en el plan de prueba. En concreto los ingenieros observan dos mtricas: -Complecion de la prueba, indica el porcentaje de casos de prueba que han sido ejecutados y el porcentaje de cdigo que ha sido probado. -Fiabilidad, la cual se basa en el anlisis de las tendencias en los defectos detectados, para determinar esto los diseadores crean diagramas de tendencias de defectos donde se representa la distribucin de tipos especficos de defectos. 42
Basando se en el anlisis de la tendencia de los defectos los diseadores de pruebas pueden seguir otras acciones: -Realizar pruebas adicionales para localizar mas defectos. -Relajar el criterio para las pruebas. -Aislar las partes del sistema que parecen tener una calidad aceptable y entregarlas como resultado de la iteracin actual, las que no han de ser probadas de nuevo Las tres preguntas de este tema son: 1.-Cules son los objetivos de la Prueba? 2.-Mencionar las fases en la que se centran las Pruebas? 3.-En que consiste el Trabajador: Diseador de Pruebas?
43
Capitulo XII Introduccin: El flujo de trabajo de iteracin gentica incluye los cinco flujos de trabajo: requisitos, anlisis, diseo, implementacin y prueba. Este tambin incluye la planificacin, que precede de trabajo, y la evaluacin, que va detrs de ellos. La planificacin es necesaria a lo largo de todo el ciclo de desarrollo, pero antes de que podamos planear es necesario saber que es lo que tenemos los cinco flujos de trabajo fundamentales proporcionan un punto de partida. Otro aspecto clave de la planificacin es la administracin de riesgos, es decir, la identificacin y mitigacin de riesgos realizando el correspondiente conjunto de casos de uso. Por supuesto. Un plan no estar completo sin la estimacin de recursos que ste requerida y, por ltimo, tambin llevarse a cabo la evaluacin de la ejecucin de caca iteracin y fase. 12.1. La necesidad de equilibrio. En cada uno de los momentos del ciclo de vida de los proyectos de desarrollo software estn activas muchas secuencias de actividades diferentes. Debemos equilibrar y sincronizar en todo momento estas secuencias de actividades diferentes para controlar as esta complejidad. Los desarrolladores dividen el trabajo, que es abrumadoramente complejo como un todo, en partes ms pequeas y comprensibles. A lo largo de ciclo de vida de desarrollo dividen el trabajo en fases. Y casa una de estas fases en iteraciones. Dentro de cada iteracin el proyecto se esfuerza en alcanzar un equilibrio entre las secuencias de actividad que se ejecutan a lo largo de la iteracin, lo que significa que deberamos trabajar en cosas apropiadas en cada iteracin. Determinar el punto de equilibrio de las secuencias de actividades es tambin importante para asegurar que son de una importancia parecida, de forma que queda asignrseles una prioridad de sincronizarlas con facilidad. E las primeras iteraciones trabajamos con riesgos crticos, casos de uso fundamentales, cuestiones arquitectnicas, las elecciones del entorno de desarrollo, todas las cuestiones orientadas a la investigacin, mientras que en las ltimas iteraciones trabajamos en actividades orientadas al desarrollo, como la implementacin y la prueba, problemas del rendimiento y despliegue del sistema. Lo que hacemos en la iteracin es entender estas secuencias de actividades diferentes y buscar el equilibrio entre ellas. 12.2. Las fases son la primera divisin del trabajo El primer paso hacia la divisin del proceso de desarrollo de software consiste en separar las partes en cuatro fases atendiendo al momento en que se realizan: inicio, elaboracin, construccin y transicin. Cada una de estas fases de divide entonces en una o ms iteraciones. 12.2.1. La fase de inicio establece la viabilidad El objetivo principal de esta fase es establecer el anlisis de negocio- el anlisis para decidir si se sigue adelante con el proyecto-, aunque este anlisis se desarrollando en la fase de elaboracin conforme se vaya disponiendo de mas informacin. Para realizar este anlisis seguimos cuatro pasos: 1. Delimitar el mbito del sistema propuesto, es decir, definir los lmites del sistema y empezar a identificar las interfaces con sistemas relacionados que estn fuera de lmites. 2. describir o esbozar una propuesta de la arquitectura del sistema, y en especial de aquellas partes del sistema que son nuevas, arriesgadas o difciles. 3. identificar riesgos crticos, es decir, los que afectan a la capacidad de construir el sistema, y determinar si podemos encontrar una forma de mitigarlos, quizs en una etapa posterior. 44
4. demostrar a usuarios o clientes potenciales que el sistema propuesto es capaz de solventar sus problemas o de mejorar sus objetivos de negocio construyendo un prototipo. Continuamos con estos esfuerzos hasta el momento en que desarrollar el sistema parece ser rentable econmicamente, es decir, hasta que se concluye que el sistema proporcionara ntegramente u otros beneficios proporcionales a la investigacin necesaria con un margen suficiente para construirlo. La intencin es minimizar los gastos en tiempo de planificacin, esfuerzo y fondos en esta fase hasta que decidimos si el sistema es viable o no. 12.2.2. La fase de elaboracin se centra en l factibilidad El resultado principal de la fase de elaboracin es una arquitectura estable para guiar el sistema a lo largo de su vida futura. Esta fase lleva el estudio del sistema propuesto al punto de planificar la fase de construccin con gran precisin. Con estos dos grandes objetivos la arquitectura y la estimacin de gran precisin el quipo hace lo siguiente: 1. Crea una lnea base para la arquitectura que cubre la funcionalidad del sistema significativa arquitectnicamente y las caractersticas importantes para las personas involucradas. 2. Identifica los riesgos significativos, es decir, los riegos que podran perturbar los planes, costes y planificaciones de fases posteriores, y los reduce a actividades que puedes ser medidas y presupuestadas. 3. Especificar los niveles a alcanzar por los atributos de calidad, como la fiabilidad (porcentajes de defectos) y los tiempos de respuesta 4. Recopila casos de uso para aproximadamente el 80 por ciento de los requisitos funcionales, suficiente para planificar la fase de construccin. 5. Prepara una propuesta de la planificacin cubierta, personal necesario y coste dentro de los lmites establecidos por las prcticas de negocio. 12.2.3. La fase de construccin construye el sistema El objetivo general de la fase de construccin viene indicado por su tarea fundamental; la capacidad de operacin inicial. Entre las actividades de la fase de construccin tenemos: 1. La extensin de la identificacin, descripcin y realizacin de casos de uso a todos los casos de uso. 2. La finalizacin del anlisis (posiblemente queden todava ms de la mitad de los casos de uso por ser analizados cuando comienza la fase de construccin), del diseo, de la implementacin y de la prueba (posiblemente quede un 90 por ciento). 3. El mantenimiento de la integridad de la arquitectura, modificndola cuando sea necesario. 4. La monitorizacin de los riesgos crticos y significativos arrastrados desde las dos primeras fases, y su mitigacin si se materializan. 12.2.4. La fase de transicin se mete dentro del entorno del usuario La fase de transicin comienza a menudo con la entrega de la versin beta del sistema, es decir, la organizacin distribuye un producto software capaz ya de un funcionamiento inicial a una muestra representativa de la comunidad de usuarios. Entre las actividades de transicin se incluyen: Preparar las actividades, como la preparacin del lugar. Aconsejar al cliente sobre la actualizacin el entorno (hardware, sistemas operativos, protocolos de comunicaciones, etc.) en los que se supone que el software va a versiones beta. Prepara los manuales y otros documentos para la entrega del producto. 45
Ajustar el software para que funcione con los parmetros actuales del entorno del usuario. Corregir los defectos encontrados a lo largo de las pruebas realizadas a la versin beta. Modificar el software al detectar problemas que no haban sido previstos. La fase de transicin termina con la entrega del producto final. 12.3. La iteracin genrica En el proceso Unificado estos flujos de trabajo fundamentales no ocurren solo una vez, como sucede tericamente en el modelo en cascada, sino que se repiten ms bien en cada iteracin, una y otra vez, como flujos de trabajo iterativo. En cada repeticin, sin embargo, se diferencian en lis detalles, se enfrentan a los asuntos centrales de cada iteracin. 12.3.1. Los Flujos de trabajo fundamentales se repiten en cada iteracin La iteracin gentica consiste en los cinco flujos de trabajo: requisitos, anlisis, diseo, implementacin y prueba, e incluye tambin planificacin y evaluacin. 12.3.2. Los trabajadores participan en los flujos e trabajo Un analista de sistemas identifica los casos de uso y los actores y los estructura dentro de un modelo de casos de uso. A continuacin, un especificador de casos de uso detalla cada uno de los casos de uso y un diseador de interfaces de usuario construye un prototipo de interfaces de usuario. El arquitecto asigna prioridades a los casos de uso a ser desarrollados dentro de las iteraciones teniendo en cuenta los riesgos. Los tres trabajadores involucrados en el anlisis continan con su trabajo en el flujo de diseo. La prueba, sin embargo, comienza muy pronto, cuando el ingeniero d pruebas planifica lo que hay que hacer. Tan pronto como hay disponibles detalles suficientes en el flujo de implementacin, el ingeniero de pruebas disea las pruebas. Conforme son integrados los componentes que han pasado las pruebas de unida, los ingenieros de pruebas de sistemas y los de integracin prueban los resultados de varios niveles de integracin. El ingeniero de pruebas evala si la prueba que haba solicitado ha sido adecuada o no. 12.4. El planificar precede al hacer Cuando comenzamos la fase de inicio sabemos tres cosas: Vamos a llevar a cabo el proyecto en una serie de iteraciones en cuatro fases. Tenemos la informacin sobre el sistema propuesto que nuestros predecesores recopilaron (y que llevaron a comenzar un proyecto). Tenemos muestra propia informacin bsica sobre el dominio y sobre sistemas similares en los que trabajamos en el pasado. Partiendo de esta informacin hemos de planear el proyecto (plan de proyecto) y cada iteracin (plan de iteracin). 12.4.1. Planear las cuatro fases Gracias a las indicaciones del proceso Unificado sabemos que hay que hacer en cada una de las fases. Nuestra tarea, en el plan del proyecto, es reducir estas indicaciones a trminos concretos: Asignaciones de tiempo. Deducimos cuanto tiempo asignar a cada fase y la fecha en la que cada fase ha de haber sido completada. Hitos principales. Una fase termina cuando ha sido alcanzado el criterio actual. Iteraciones por fase. Dentro de cada fase el trabajo se lleva a cabo a lo largo de varias iteraciones.
46
Plan de proyecto. El plan de proyecto esboza un mapa de caracteres global, que cubre la planificacin, las fechas y criterios de los objetivos principales y la divisin de las fases en iteraciones.
12.4.2. Plan de iteraciones Cada fase esta formada por una o ms iteraciones. La planificacin de iteraciones pasa por un conjunto de pasos comparables con los seguidos en la planificacin de las fases: Planificacin de iteracin. Decimos cuanto tiempo puede requerir cada iteracin y su fecha de terminacin. Contenido de Iteraciones. Mientras que el plan de proyecto esboza las iteraciones planeadas en trminos generales, cuando la fecha de comienzo de una iteracin se acerca, planeamos lo que ha de hacerse ms en detalle. El contenido se basa en lo siguiente. - Los casos de uso que tienes que ser completados al menos parcialmente durante la iteracin. - Los riesgos tcnicos que han de ser identificados, transformados en casos de uso y mitigados en ese momento. - Los cambios que han sufrido los requisitos o los defectos que pueden haber sido corregidos. - Los subsistemas que han de ser implementados parcial o completamente. 12.4.3. Pensar a largo plazo Durante el largo plazo de tiempo que el sistema puede durar, este puede presenciar grandes cambios, como nuevas tecnologas, nuevas interfases con el entorno del sistema o plataformas avanzadas. 12.4.4. Planear los criterios de evaluacin Le jefe de proyecto establece criterios de evaluacin para cada iteracin y para la fase misma por adelanto. A grandes rasgos, los criterios de evaluacin pueden clasificarse en dos categoras: requisitos verificables y criterios ms generales. Los criterios de evaluacin dicen como verificar que los requisitos para una iteracin has sido desarrolladas correctamente. 12.5. Los riesgos influyen en la planificacin del proyecto En modo en los que se planifica el desarrollo de un nuevo sistema influyendo en gran medida por riesgos que se perciben. Por tanto, uno de los primeros pasos, al principio de la fase de inicio, es crear una lista de riesgos. 12.5.1. Administrar la lista de riesgos Una cosa es saber de una forma vaga el desarrollo de software implica riesgos y otra distinta ponerlos donde todo el mundo pueda verlos, ser guiados por ellos y hacer algo con ellos. se es el propsito de la lista de riesgos. Esta lista incluye: Descripcin: comienza con una breve descripcin y se van aadiendo detalles conforme se va aprendiendo. Prioridad: se le asigna prioridad al riesgo. Impacto: indica que partes del proyecto o del sistema se varan afectadas por el riesgo. Monitor: indica quin es responsable del seguimiento de un riesgo persistente. Responsabilidad: indica qu individuo o unidad de la organizacin es responsable de eliminar el riesgo. Contingencia: indica lo que ha de hacerse en caso de que el riesgo se materialice. La lista de riesgos no es un instrumento esttico, la lista crece conforme se descubren riesgos. 47
12.5.2. Los riesgos influyen en el plan de iteraciones Durante la fase de inicio se identifican los riesgos crticos y el equipo intenta mitigarlos. Exploran su naturaleza hasta el punto de prepara un plan de iteracin. Para saber lo suficiente para hacer un plan, por ejemplo, se ha de desarrollar el pequeo conjunto de casos de uso relacionados con el riesgo e implementarlo en un prototipo. Adems de las influencias que pueden tener los riesgos ms serios sobre el xito de un proyecto, todos los riesgos tienen algn impacto en la planificacin, el coste o la calidad. 12.5.3. Planificar la accin sobre los riesgos El principio general es tener un plan de accin a seguir sobre lo riesgos. Las fases y las iteraciones dentro de las fases proporcionan el medio de planificar las acciones sobre los riesgos. Cuando no exista un esfuerzo consistente para actuar pronto sobre los riesgos, estos se manifiestan usualmente al final de la planificacin, mientras se realizan las pruebas de integracin y de sistema. Resolver a esa altura cualquier problema serio, que pueden requerir amplias modificaciones del sistema, puede retrasar la entrega durante varias semanas o incluso ms. En el enfoque iterativo la construccin de prototipos, construcciones y artefactos descubre desde la primera fase los riesgos mientras hay an tiempo para tratarlos. 12.6. Asignacin de prioridades a los casos de uso Las prioridades son asignadas a los casos de uso o a escenarios de ellos- segn deberan ser estos considerados en las iteraciones. stos son clasificados a lo largo de varias iteraciones; en las primeras iteraciones se clasifican algunos casos de uso (o escenarios de ellos), pero muchos no han sido identificarlos en ella y por tanto no han sido clasificados todava. Todos los casos de uso que se identifican son tambin clasificados. El resultado de la clasificacin es una lista ordenada de casos de uso. El control de esta clasificacin es difcil. Ordenamos los casos de uso de acuerdo con el riesgo de conllevan. El proceso de seleccin esta por tanto guiado por los riesgos. En las primeras iteraciones dedicamos los casos de uso con mayor prioridad a los riesgos relacionando con el mbito del sistema y con la arquitectura. En las ltimas iteraciones seleccionamos nuevos casos de uso para completar la arquitectura ya seleccionada con ms funcionalidad. 12.6.1 riesgos especficos de un producto partcula Cada uno de estos riesgos es transformado en un caso de uso que, una vez implementado correctamente, mitiga el riesgo. Tenemos que identificar estos riesgos uno por uno, pues el tratar con ellos no es formalmente parte del proceso. Con formalmente parte del proceso queremos decir que el proceso proporciona un lugar especifico en el que tratar con cierto tipo de riesgo. 12.6.2 Riesgo de o conseguir la arquitectura correcta Cmo determinamos cuales son los casos de uso ms importantes para la arquitectura correcta? Cmo mitigamos el riesgo de no conseguir una arquitectura estable? La respuesta se encuentra en los casos de uso crticos aquellos que son ms importantes para los usuarios del sistema-. Adems, los casos de uso que tienes requisitos no funcionales importantes, como de rendimiento, tiempos de respuesta, etc., entran en esta categora. Otras categoras de caso de uso son: Secundarios. Estos casos de uso sirven de apoyo a los casos de uso crticos. Involucran funciones secundarias, como las de superacin y compilacin de estadistas operativas. Auxiliares. Estos casos de uso son claves para la arquitectura o para riesgos crticos.
48
Opcionales. Puede que necesitemos trabajar con ellos porque afecten a la arquitectura cuando estn presentes. Adems, queremos estar seguros de que hemos considerado todos los casos de uso que podran tener algn impacto sobre la arquitectura. Este es la razn por la que necesitamos cubrir alrededor del 80 por ciento de los casos de uso en la fase de elaboracin. Con cubrir queremos decir que entendemos los casos de uso y el impacto que pueden tener sobre el sistema. 12.6.3. Riesgo de no conseguir los requisitos correctos Cules son los casos de uso necesarios para asegurar que estamos desarrollando el sistema correcto para los usuarios? Cules son los casos de uso que aseguran que el sistema puede evolucionar en las otras fases de forma que podemos aadir todos los requisitos necesarios para la primera entrega? Por supuesto, la primera parte de la respuesta es hacer el flujo de trabajo de los requisitos bien. La segunda parte de la respuesta es, basndose en las iteraciones iniciales y el la construccin de prototipos, construir el sistema que quieren los usuarios y obtener informacin sobre el tan pronto como sea posible. 12.7 Recursos necesitados Uno puede pensar que el plan iterativo del desarrollo de software basado en fases tiene un merito considerable, pero varias cuestiones pueden importunarnos: Cunto van a costar las fases de inicio y de la elaboracin, tanto en trminos de esfuerzo como en trminos de calificacin del personal necesario? De donde va a venir el dinero necesario para pagar estas fases? Cunto tiempo van a durar estas dos fases? Por cuntos meses van a retrasar las primeras fases lo que mucha gente considera como el negocio real del desarrollo de software, es decir, la construccin? 12.7.1 Los proyectos difieren enormemente Por supuesto, no es un secreto que los sistemas de software difieren enormemente en su preparacin para empezar el desarrollo. Veamos cuatro ejemplos. 1. Un producto completamente nuevo o sin software es un dominio inexplorado una tierra virgen-. 2. Un producto de un tiempo que ha sido realizado anteriormente en un campo en el cual productos anteriores proporcionan ejemplos pero no componentes reutilizables. 3. Hay un producto ya existente, pero este ha de ser actualizado, por ejemplo pasando de funcionar en un mainframe a funcionar en una arquitectura de cliente/servidor. 4. Existen los componentes, ya sea en el mercado o en la misma empresa. 12.7.2. Un proyecto tpico tiene este aspecto A pesar de las incertidumbres que introducen diferentes estados de comienzo, el ciclo de desarrollo inicial de un proyecto de tamao medio podra tener, aproximadamente, una distribucin de esfuerzo y planificacin. 12.7.3. Los Proyectos ms grandes tienen mayores necesidades Cul es el resultado de suponer un proyecto ms grande y ms complejo uno con, por ejemplo, funcionalidad nueva, arquitectura distribuida u operaciones en real- que usa tambin nueva tecnologa? Probablemente, tenemos que realizar un mayor nmero de iteraciones y tendremos que poner mas tiempo y esfuerzo en las fases de inicio y elaboracin. 12.7.4. Una nueva lnea de productos requiere experiencia Cuando una compaa planea desarrollar una nueva lnea de productos sta sabe en una parte de su mente colectiva que este trabajo requiere su gente ms competente y experimentada. 49
12.7.5. El pago de coste de los recursos utilizados Mantener el equipo que trabaja en las dos fases, aunque sea pequeo, cuesta dinero. De hecho, la dificultad de conseguir fondos para costear estas dos primeras fases ha sido una de las causas que han llevado a las organizaciones fabricantes de software a cometer la fase de construccin prematuramente, dando lugar a veces a fallos bien conocidos. En caso de una organizacin fabricante de software que produce un producto para vender, los fondos son parte de los gastos generales y, como tales, estn bajo control de la direccin. En el caso de una organizacin fabricante de software que producen un producto para un cliente dentro de la misma empresa, el coste de la primeras dos fases es parte de los gastos generales de la compaa, de los fondos transferidos a ella por el cliente o de los fondos asignados a ella por la alta direccin de la empresa. En el caso de una organizacin fabricante de software que produce un producto para una corporacin distinta, el coste de las dos primeras fases puede venir de sus gastos generales propios. 12.8. Evaluar las iteraciones y las fases El primer objetivo de una evaluacin es examinar lo que ha sido realizado en trminos del criterio de evaluacin actual. El segundo objetivo es el de comparar el proceso realizando con el plan de la iteracin o del proyecto: Avanza el proyecto dentro del presupuesto y siguiendo la planificacin? Est alcanzando los requisitos de calidad, de acuerdo con los resultados de las pruebas o las observaciones de los prototipos, componentes y construcciones? Idealmente, el proyecto cumplir los criterios. 12.8.1 Criterios no alcanzados Frecuentemente alguna iteracin no alcanza los criterios satisfactoriamente. El proyecto puede tener que prolongar este trabajo durante la siguiente iteracin (o hasta la iteracin apropiada). Tambin es posible que, simplemente, se necesite ms tiempo para poder llevar a cabo el plan existente. 12.8.2. Los criterios mismos El equipo puede haber establecido los criterios en un momento en que todava no tenia disponible toda la informacin relevante. Por tanto, los evaluadores podran tener que cambiar los criterios, y no solo comprobar si se alcanzan estos criterios. 12.8.3. La siguiente iteracin Sobre la base de la evaluacin, el jefe de proyecto (asistido por algunas de las personas que trabajaron en la iteracin o en la fase y por alguna de las personas que participaran en la siguiente fase) hace lo siguiente: Determina que el trabajo esta listo pata pasar a la siguiente iteracin. Si se necesita rehacer algn trabajo asigna en cuales de las siguientes iteraciones debera realizarse. Planea en detalle la siguiente iteracin. Actualiza el plan, en menos detalle, de las iteraciones posteriores a la siguiente. Actualiza la lista de riesgos y el plan del proyecto. Compara el coste y la planificaron de la iteracin con los planeados. 12.8.4. Evolucin del conjunto de modelos En el desarrollo iterativo, los modelos crecen juntos a travs de las fases. En las primeras iteraciones unos modelos van por delante de otros, por ejemplo, el modelo de casos de uso va por delante del modelo de implementacin. En lugar de que un modelo evolucione casi independientemente del siguiente modelo pensamos en trminos de un estado del sistema 50
entero que evoluciona a un estado mas avanzado del sistema entero. Cada iteracin quizs cada construccin dentro de una iteracin- representa un avance en le estado del sistema completo, el cual se refleja en el movimiento gradual hacia la complecin del conjunto de modelos. Considerar el grado en que esta evolucin ha progresado en cada evaluacin ser un indicador importante para el grupo evaluador.
Preguntas formuladas: 1. Cules son las fases en que se dividen las partes en el proceso de desarrollo de software? a. Fase de inicio. b. Fase de elaboracin. c. Fase de construccin. d. Fase de transicin. 2. Cules son las categoras de riesgos? a. Riesgos especficos. b. Riesgos arquitectnicos. c. Riesgos de requisitos. 3. Cules son los cinco flujos de trabajo? a. Requisitos. b. Anlisis. c. Diseo. d. Implementacin. e. Prueba.
51
Capitulo XVII
COMO HACER QUE EL PROCESO UNIFICADO FUNCIONE El desarrollo de software para sistemas crticos sigue siendo excesivamente complejo, como hemos podido ver en los captulos anteriores. 17.1.- El Proceso Unificado ayuda a manejar la complejidad En primer lugar, tenemos las cuatro fases: inicio, elaboracin, construccin y transicin. Con el continuo desarrollo de sistemas de software llegan versiones posteriores y nuevas generaciones. Dentro de estas fases se entremezclan los flujos de trabajo, la arquitectura, la gestin de riesgos, las iteraciones e incrementos como: El desarrollo de software guiado por los casos de uso a travs de los flujos de trabajo: requisitos, anlisis, diseo, implementacin y pruebas. El desarrollo guiado por la arquitectura el esqueleto de los elementos estructurales y de comportamiento que permite que el sistema evolucione sin sobresaltos. El desarrollo con riesgos controlados. El desarrollo visualizado y registrado usando el Lenguaje Unificado de Modelado (UML). El desarrollo evaluado en los hitos. Cuatro hitos controlan el proceso: los objetivos del ciclo de vida, la arquitectura del ciclo de vida, la capacidad operativa inicial y el lanzamiento del producto. 17.1.1.- Los objetivos del ciclo de vida El primer hito clarifica los objetivos del ciclo de vida de producto al plantear cuestiones como: Se ha determinado con claridad el mbito del sistema? Se ha determinado lo que va a estar dentro del sistema y lo que va a estar fuera de el? El uso del producto generara beneficios que justifiquen lo invertido en su construccin? Y as una serie de preguntas relacionada a los objetivos del ciclo de vida. Contestar a estas preguntas es asunto de la fase de inicio. 17.1.2.- La arquitectura del ciclo de vida El segundo hito clarifica la arquitectura para el ciclo de vida del producto a travs de cuestionarios como: Se ha creado una lnea base de la arquitectura? Es adaptable y robusta? Puede evolucionar a lo largo de la vida de producto? Se ha obtenido la aprobacin de los inversores? Y una serie de preguntas ms relacionadas a la arquitectura del ciclo de vida. Contestar estas preguntas es asunto de la fase de elaboracin. 17.1.3.- Capacidad operativa inicial El tercer hito establece que el proyecto a alcanzado la capacidad operativa inicial: El producto a alcanzado un nivel de capacidad adecuada para su operacin inicial en el entorno del usuario, en particular para realizar las pruebas beta? Esta es la pregunta clave del tercer hito, hemos investigado los riesgos, tenemos un plan de proyecto y tenemos recursos. De modo que construimos el producto. Una labor importante en esta fase es el secuenciamiento de construcciones e iteraciones. Una buena secuencia indica que los prerrequisitos de cada iteracin son los correctos. No obstante, a pesar de nuestros esfuerzos para evitar problemas, algunos seguirn apareciendo. Lo que hay que hacer aqu es superar los problemas del da a da. La construccin del sistema es el objetivo de la fase de construccin. 17.1.4.- Lanzamiento del producto
52
El cuarto hito determina que el producto esta listo para su lanzamiento sin restricciones a la comunidad de usuarios: Es el producto capaz de operar con xito en entorno de usuarios tpicos? Aun hay trabajo que hacer una vez alcanzada la capacidad operativa inicial: en concreto las pruebas beta y todas la pruebas posibles. Cuando tengamos algo con lo que los usuarios se sientan satisfechos, distribuiremos el producto. Esta tareas son asunto de la fase de transicin. 17.2.- Los temas importantes Estos temas son el recorrido a travs de los cuatro hitos principales y la vinculacin de unos con otros. Todos son importantes. Obtenga correctamente los requisitos.- Obtngalos correctamente a travs del modelado de casos de uso, el anlisis, etc. El mejor comienzo del proceso Unificado esta guiado por los casos de uso. Obtenga correctamente la arquitectura.- Cualquier proyecto de tamao considerable tiene que estar centrado en la arquitectura. La arquitectura permite la particin del sistema y el que estas particiones colaboren entre si. Use componentes.- Las firmes interfaces de la arquitectura, son uno de los elementos que hacen posible el desarrollo basado en componentes. Piense y comunquese en UML.- El desarrollo de software es algo mas que escribir cdigo UML (Junto con otras caractersticas del Proceso Unificado) convierte el desarrollo de software en una disciplina de ingeniera. Itere.- Las iteraciones u construcciones proporcionan ventajas: tareas pequeas, grupos de trabajos pequeos. Gestione los riesgos.- Identifique los riesgos, crticos, significativos, rutinarios etc. 17.3.- La direccin lidera la conversin al Proceso Unificado Mas halla de la tarea de gestionar y controlar un proceso en curso, esta la de llevar una empresa, publica o privad, de los viejos mtodos a la nueva senda. El mbito empresarial y gubernamental tiene, en la actualidad, muchas organizaciones que han avanzado poco en la senda del proceso de software. Algunos utilizan software desfasados o insuficientes en su procedimiento. El profesional capacitado en el desarrollo de software ser quien lleve la senda de la empresa, es quien debe liderar, porque esta afecta a toda la organizacin. 17.3.1.- La necesidad de actuar Debido a que el nuevo camino afectara a otras partes de la organizacin de desarrollo de software y a toda la empresa, el primer ejecutivo debe buscar el apoyo de otros ejecutivos. Puede hacer esto a travs de una declaracin de necesidad de actuar. Bsicamente, esta declaracin establece que la forma en la que se estn haciendo las cosas ya no es valida. La declaracin de la necesidad de actuar lleva a lo que debe ser esta accin, a las falencias de nuestro sistema. Aqu se hace uso de sistemas prefabricados, un sistema prefabricado es un gran marco de trabajo en el cual el cliente, con la ayuda del proveedor, realiza pequeas adaptaciones para satisfacer las necesidades especificas de su negocio. La labor del ejecutivo del software es descubrir donde puede conseguir la ayuda que su organizacin necesita. Para la mayora de las organizaciones solo hay un camino: el desarrollo de software basado en componentes. Decidir si tratamos de hacer mucho por nuestra propia cuenta un software o de construir sobre bloques de construccin reutilizables, es un problema que debe resolver el ejecutivo del software en funcin de su propia situacin. 17.3.2.- La directriz de Reingeniera El ejecutivo inicial explicara cuidadosamente y extensamente, y sin exagerar en la directriz de reingeniera, por que la empresa esta cambiando a un proceso software mejorado. La directriz cubre: La situacin actual del negocio y el hecho de que esta cambiando. Lo que esperan los clientes en la actualidad. La competencia a la que se enfrenta la empresa. 53
Los retos que afronta la empresa. El diagnostico al que llevan estos retos. Los riesgos que traer el no realizar cambios. Garanta de apoyo.- Los jefes de proyecto tienen que tener confianza en obtener apoyo financiero continuado. El comenzar un nuevo proyecto con un nuevo proceso depende de la plena integracin de cuatro apoyos: proceso, herramientas, formacin y asesoria. Continuidad de los proyectos existentes.- Es una empresa de cierto tamao, con muchos proyectos en curso, los proyectos actuales y la mayora de los que aparezcan en un futuro inmediato tendrn que continuar con el proceso actual. Confianza en el propio futuro.- Si se sienten razonablemente confiados en su propio futuro, esto ayudara a la transicin. Las empresas que tradicionalmente han cuidado de si mismas tienen ventaja en esto, pero todas tienen que ser consientes de su importancia. 17.3.3.- Implementacin de la transicin El ejecutivo del software se enfrenta con los problemas de implementacin. El Lder.- Es implementar la transicin, ya que el ejecutivo tiene el tiempo ocupado necesita un ingeniero tcnicamente calificado. Este lder debe comprender el Proceso Unificado y, para lograr tal compresin, debe realizar alguna formacin y conseguir asesoria personalizada. Pero al mismo tiempo ser lo suficientemente maduro como para no comenzar desde cero con su propio y exclusivo mtodo. Al contrario, adaptar Proceso Unificado a las necesidades particulares del primer proyecto. Solo es necesario que comprenda lo que significa hacerlo y deseosos de trabajar de lo que hablamos a continuacin: El jefe del primer proyecto Adems de este lder, el ejecutivo del software responsable tambin necesitara un jefe de proyecto excepcionalmente capaz. El asesor.- Necesitara dos talentos especiales. Uno es la habilidad para anticipar problemas en el proyecto. Segundo, tiene que ser capaz de colaborar con la variada gente con la que se encontrara el lder, pero tambin el jefe del proyecto, el personal del proyecto y el ejecutivo que lo financia. Por donde empezar El primer proyecto debera ser uno real cuyos resultados fuesen importantes. El primer proyecto debera ser critico, pero su agenda no debera ser demasiada critica. Aja, dir alguien, todos los proyectos importantes tienen agendas apretadas. Lo sabemos. En realidad, el trabajo bajo el proceso unificado discurre de forma ms rpida que bajo mtodos ms antiguos. Adems el primer proyecto estar guiado por asesores. En la prctica, aplicar la propuesta completa en un proyecto real es seguro, aunque esto no significa hacer demasiadas cosas al mismo tiempo. 17.4.- Especializacin del Proceso Unificado El Proceso Unificado, tal y como se presenta en este libro, no es lo nico que se puede decir a este respecto. Primero es un marco de trabajo, el tamao del sistema en curso, el dominio en el que ese sistema ha de trabajar, la complejidad del sistema y la experiencia, pericia y nivel de proceso de la organizacin del proyecto y sus miembros. Segundo para aplicarlo se necesita una considerable informacin adicional. 17.4.1.- Adaptacin del proceso Los sistemas y productos software y las organizaciones que los construyen siguen siendo diversos como siempre. Consiguientemente, aunque hay ciertas constantes en el Proceso Unificado, como las cuatro fases y los cinco flujos de trabajo, existen tambin numerosos factores variables. Por ejemplo. Cul debera ser la longitud relativa de las fases? Cuntas iteraciones son las adecuadas? L a respuesta a preguntas como estas depende del tamao del sistema, de la naturaleza de la aplicacin, de la experiencia de la organizacin del proyecto en el dominio, de la complejidad del sistema, de la experiencia del equipo del proyecto. Por poner un ejemplo, si el sistema es relativamente pequeo, y el equipo del proyecto tiene experiencia en el dominio, la fase de inicio puede ser muy breve. 54
Por poner otro ejemplo, si el sistema es grande, complejo y novedoso para el equipo del proyecto, podemos suponer que la fase de inicio, as como la fase de elaboracin, ser mucho mas larga y discurrirn a travs de ms iteraciones. El nmero de variaciones sobre estos temas es tan gran de cmo el nmero de sistemas a construir. Aqu es donde la experiencia desempea su papel. 17.4.2.- Completando el marco del trabajo del proceso No proporciona a los miembros del equipo las indicaciones detalladas que necesitan para guiar su trabajo diario. En esencia, el libro cubre las ideas bsicas. Describe algunos flujos de trabajo, algunos artefactos, algunos trabajadores y algunas de sus actividades, as como los usos del Lenguaje Unificado de Modelado. 17.5.- Relacin de comunidades mas amplias Adems de dotar de un entorno de trabajo mas efectivo al proyecto y de relaciones mas efectivas con los usuarios e inversores, el Proceso Unificado proporciona una interfaz mas satisfactoria a comunidades aun mas amplias: La comunidad educativa.- Los educadores centran sus cursos en lo que los estudiantes necesitan saber para trabajar con el Proceso Unificado y para pensar y visualizar usando el Lenguaje Unificado de Modelado. La comunidad de software.- Los arquitectos, desarrolladores, etc. Pueden cambiar de proyecto, e incluso de empresa, sin un largo periodo de adaptacin a prctica exclusivas de la nueva empresa. La comunidad de reutilizacin.- Los proyectos pueden reutilizar subsistemas y de componentes de forma mas fcil, puesto que estn representados en UML. La comunidad de herramientas.- Los proyectos estarn respaldados por herramientas mas efectivas, ya que el amplio mercado del Proceso Unificado permite mejor soporte financiero para el desarrollo de herramientas. 17.6.- Obtenga los beneficios del Proceso Unificado Basado en 30 aos de trabajo en la prctica, el Proceso Unificado rene la experiencia de varios lderes de pensamiento y organizaciones experimentadas. Esta unificado a partir de muchas aplicaciones y tcnicas, tales como: Visualizable.- Los modelos visuales y artefactos empleados en el proceso Unificado se expresan en el Lenguaje Unificado de Modelado, lo que nos conduce a sus muchas ventajas, tales como una gran reutilizacin del software y a esquemas del software. Mecanizable.- Un proceso unificado y un lenguaje estndar dotan de soporte financiero para herramientas mas completas, lo que a su vez hace el proceso mas efectivo. Adaptable.- Es un marco de trabajo de proceso, no un proceso rgido. Es especializable a diferentes campos de aplicacin y necesidades organizativas. Extensible.- El proceso Unificado no limita a sus usuarios a una nica forma de llevar a cabo una actividad. El Proceso Unificado capacita a las organizaciones de muchas maneras. La ms importante es que proporciona la forma en la que el equipo de proyecto puede trabajar conjuntamente. Adems proporciona la forma en la que el equipo del proyecto puede trabajar con los usuarios y con el resto de los implicados. PREGUNTAS: 1. Cuales son los cuatro hitos que controlan el proceso unificado y que ayudan a manejar la complejidad? 2. Describa que indica el cuarto hito del proceso unificado. 3. En la implementacin de la transicin el ejecutivo de software se enfrenta con dos problemas de implementacin indique cuales son. 4. Indique las tcnicas y aplicaciones que se obtienen en los Beneficios de proceso Unificado
55

Puds Libro

Diunggah oleh

Informasi Dokumen

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Puds Libro

Diunggah oleh

Hak Cipta:

Format Tersedia

CAPTURA DE REQUISITOS: DE LA VISIN A LOS REQUISITOS

CAPTURA DE REQUISITOS COMO CASOS DE USO

Priorizar los casos de uso

Detallar un caso de uso

Diseador de interfaces de usuario

Prototipar la interface de usuario

8.2 El anlisis en pocas palabras 13

Realizacin de caso de uso-anlisis

Realizacin de caso de uso-anlisis

8.4.5. Artefacto: descripcin de la arquitectura (vista del modelo de anlisis)

8.5. Trabajadores 8.5.1. Trabajador: arquitecto

Ingeniero de casos de uso Responsable de

Vista de la arquitectura Descripcin de la arquitectura

Modelo de anlisis Responsabilidade s del arquitecto en el anlisis

Realizacin de caso de uso-Anlisis Responsabilidades del Ing. De casos de uso anlisis

9.5.2.4. Descripcin de interacciones ente subsistemas

9.5.3.5 Identificar las generalizaciones

Preguntas: 1.-Que es un diagrama de clases? 30

El Proceso Unificado de Desarrollo de Software

3. Quines son los trabajadores durante la fase de implementacin?

Componente de prueba de prueba

Anda mungkin juga menyukai