Proceso unificado Capitulo I y II PUDS - Minidefiniciones

Proceso de desarrollo de software: Conjunto de actividades necesarias para convertir los requisitos de un usuario en un sistema software. Usuario: hace referencia tanto a usuarios humanos como a otros sistemas. Representa a algo o alguien que interacta con el sistema. Caso de uso: Interaccin en la cual el sistema, en respuesta a una accin del usuario, realiza un proceso y entrega un resultado de importancia para este. Producto (sistema software): El producto incluye no solo en el ejecutable, sino tambin toda la documentacin y los modelos. Modelo de casos de uso, modelo de anlisis, modelo de implementacin, modelo de despliegue, modelo de prueba y representacin de la arquitectura. Todos esos modelos estn relacionados por dependencias de traza. Proceso: Conjunto secuencial de actividades con un fin determinado. Artefacto: Trmino general para cualquier tipo de informacin creada, producida o utilizada por los trabajadores en el desarrollo del sistema. Los artefactos pueden ser de ingeniera o de gestin. Los artefactos de ingeniera son los creados durante las distintas fases del proyecto. Los artefactos de gestin tienen un tiempo de vida corto, se representan mediante texto o diagramas y sirven para administrar el proyecto. Modelo: Abstraccin de un sistema. Requisitos: Necesidades del usuario. Nota: todo lo que suba referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh. Si estudian sistemas, les recomiendo comprarlo. Es caro pero til.

PUDS (I)
Etiquetas: Sis Administrativos III El proceso unificado de desarrollo de software: Proporciona una gua para ordenar las actividades de un equipo. Dirige las tareas de cada desarrollador por separado y del equipo como un todo Especifica los artefactos que deben desarrollarse. Ofrece criterios para el control y la medicin de los productos y actividades del proyecto. El proceso unificado de desarrollo de software es un marco genrico de desarrollo que puede especializarse para diferentes reas de aplicacin, tipos de organizaciones, niveles de aptitud y tamaos de proyecto. El proceso unificado puede especializarse por que est creado en base a objetos que pueden especializarse o intercambiarse sin cambiar el diseo del proceso.

Los factores principales que influyen en la especializacin del proceso son: Organizativos: Estructura organizativa, cultura de la empresa, aptitudes y habilidades disponibles, experiencia previa y sistemas software disponibles. De Dominio: Dominio de la aplicacin, procesos que debe soportar, comunidad de usuarios y ofertas de la competencia. De Ciclo de vida: Tiempo de salida al mercado, tiempo de vida esperado, tecnologa, versiones planificadas. Tcnicos: Lenguaje de programacin, herramientas de desarrollo, base de datos, marcos de trabajo y arquitecturas estndar, comunicaciones y distribucin. Los aspectos definitorios se resumen en tres puntos clave: Est dirigido por casos de uso, Est centrado en la arquitectura y Es iterativo e incremental.

El proceso unificado est dirigido por casos de uso Los casos de uso guan el diseo, implementacin y prueba del sistema software. Para construir un sistema con xito, debemos conocer lo que sus futuros usuarios necesitan y desean. Los casos de uso representan requisitos funcionales. Todos los casos de uso juntos constituyen un modelo de casos de uso. Dirigido par casos de uso significa que el proceso de desarrollo avanza a travs de una serie de flujos de trabajo que parten de los casos de uso.

El proceso unificado est centrado en la arquitectura La arquitectura en un sistema software se describe mediante diferentes vistas del sistema en construccin. Surge de las necesidades de la empresa y se refleja en los casos de uso. Sin embargo, tambin se influida por muchos otros factores, como la plataforma y los requisitos no funcionales. La arquitectura es una vista de diseo completo con las caractersticas ms importantes resaltadas, dejando los detalles de lado.

El proceso unificado es Iterativo e Incremental El trabajo se divide en iteraciones o mini proyectos, cada una de las cuales resulta en un incremento. Las iteraciones hacen referencia a pasos en el flujo de trabajo, y los incrementos al crecimiento del producto. Las iteraciones deben estar controladas: deben seleccionarse y ejecutarse de manera planificada, por eso se les llama miniproyectos. Cada iteracin trata un grupo de casos de uso que amplan la utilidad del producto, y una serie de riesgos. Las iteraciones sucesivas se construyen sobre los artefactos tal como quedaron de la ltima iteracin. Los equipos de proyecto tratan de seleccionar solo las iteraciones requeridas para lograr el objetivo. En la medida que se aadan ms, el proceso consumir ms tiempo y esfuerzo. La Iteracin controlada: Reduce el coste del riesgo a los costes de un solo incremento. Reduce el riesgo de no sacar el producto al mercado segn el calendario previsto. Acelera el ritmo del esfuerzo de desarrollo. Reconoce que las necesidades del usuario no pueden definirse completamente al principio.

PUDS (II)

Vida del proceso unificado El proceso unificado se repite a lo largo de una serie de ciclos. Cada ciclo produce una nueva versin del sistema, y cada versin es un producto preparado para su entrega. Cada ciclo consta de cuatro fases: Inicio, elaboracin, construccin y transicin. Cada fase se subdivide a su vez en iteraciones. En cada iteracin de cada fase tienen lugar cinco flujos de trabajo: Requisitos, anlisis, diseo, implementacin y prueba. Cada fase termina con un hito. Cada hito se determina por la disponibilidad de un conjunto de artefactos. Los hitos permiten a la direccin y a los mismos desarrolladores controlar el progreso del trabajo. Fase de Inicio: Se desarrolla una descripcin del producto final. Se esboza un modelo de casos de uso simplificado que contenga los casos de uso ms crticos. La arquitectura es provisional. Se identifican y priorizan los riesgos ms importantes. Fase de Elaboracin: Se especifican en detalle la mayora de los casos de uso y se disea la lnea base de la arquitectura. Al final de esta fase, el jefe de proyecto est en condicin de estimar los recursos necesarios y planificar las actividades. Fase de Construccin: Se crea el producto. Al final de esta fase, el producto contiene todos los casos de uso. Fase de Transicin: El producto se convierte en versin beta. Un nmero reducido de usuarios lo prueba e informa de defectos y deficiencias. Se corrigen los defectos del producto y se proporciona una lnea de ayuda y asistencia al cliente. Flujos de trabajo: Requisitos: Lograr una correcta especificacin de los requisitos del sistema y definir sus lmites. Anlisis: Pulir y refinar todos los requisitos obtenidos a travs de los casos de uso. Concluye con la construccin del modelo de anlisis. Diseo: Define la forma del sistema preservando la estructura definida en el modelo de anlisis, para que soporte todos los requisitos, incluso los no funcionales. Implementacin: Empieza con el resultado del diseo e implementa el sistema en trminos de componentes, es decir, cdigo fuente, scripts, ejecutables y similares. Prueba: Verifica el resultado de la implementacin probando cada construccin, tanto internas como intermedias, as como las versiones finales del sistema a ser entregadas a terceros.

PUDS (III)
Etiquetas: Sis Administrativos III Las 4 P (y una H) del desarrollo de Software Personas: Seres humanos que trabajan en un proyecto software. Proyecto: Elemento organizativo a travs del cual se gestiona el desarrollo de software. Producto: Artefactos que se crean durante la vida del proyecto. Proceso: Conjunto de actividades necesarias para transformar los requisitos del usuario en un producto. Especifica la funcionalidad de las herramientas. Herramientas: Software para modelado y programacin. Son buenas para automatizar los procesos repetitivos, mantener las cosas estructuradas, gestionar grandes cantidades de informacin y guiarnos a lo largo de un desarrollo concreto. Si un soporte por herramientas, sera difcil mantener actualizados

los modelos y la implementacin. El equipo tendra que hacer las comprobaciones de consistencia manualmente y se requerira mucho ms tiempo de desarrollo. Deben ser fciles de usar y proporcionar un incremento de productividad.

El Proceso afecta a las Personas El modo en que se organiza y gestiona un proyecto software afecta profundamente a las personas implicadas en l. Viabilidad del proyecto: una aproximacin iterativa en el desarrollo permite juzgar pronto la viabilidad del proyecto. Si no es viable, se lo detiene en una fase temprana, aliviado problemas de moral. Gestin del riesgo: Si la gente siente que los riesgos no han sido analizados y reducidos, se siente incmoda. La exploracin de riesgos en las primeras fases atena ese problema. Estructura de Equipos: La gente trabaja de manera ms eficaz en grupos pequeos. Una buena arquitectura con interfaces bien definidas entre subsistemas y componentes hace posible una divisin del esfuerzo. Planificacin del proyecto: Cuando la gente cree que la planificacin no es realista, el proyecto se hunde. Facilidad de comprensin del proyecto: A las personas les gusta saber que es lo que estn haciendo. Sensacin de cumplimiento: En un ciclo de vida iterativo, la gente recibe retroalimentacin frecuentemente, lo cual hace llegar a conclusiones y aumenta la sensacin de progreso.

PUDS (IV)
Etiquetas: Sis Administrativos III Convertir Recursos en Trabajadores Trabajador: puesto al que se le pueden asignar personas. Puede contener una persona o un equipo completo de personas. Cada trabajador tiene un conjunto de responsabilidades y lleva a cabo un conjunto de actividades en el desarrollo software. Un trabajador puede asumir roles en relacin con otros trabajadores en diferentes flujos de trabajo. Para trabajar eficazmente, los trabajadores necesitan informacin. El jefe de proyecto debe identificar las aptitudes de los recursos (personas) y buscar un trabajador que las requiera.

Un Sistema posee una coleccin de modelos Cada trabajador necesita una perspectiva diferente del sistema. Las perspectivas de los trabajadores se agrupan en modelos. La construccin del sistema, por tanto, es un proceso de construccin de modelos. El proceso unificado proporciona un conjunto de modelos que hace el sistema claro para todos los trabajadores, incluyendo clientes, usuarios y jefes de proyecto. Cada modelo es una vista autocontenida del sistema en el sentido de que un usuario de un modelo no necesita para interpretarlo informacin de otros modelos. Adems del sistema, un modelo debe describir las interacciones entre el sistema y los que le rodean. La mayora de los modelos de ingeniera se definen mediante un subconjunto de UML. Las relaciones entre modelos se llaman dependencias de traza. Las actividades relacionadas conforman flujos de trabajo

Un flujo de trabajo es un conjunto de actividades. Para disear la estructura de flujos de trabajo identificamos primero los distintos tipos de trabajadores que participan, despus, los artefactos que necesitamos crear para cada tipo de trabajador. Una vez identificados, podemos describir como fluye el proceso a travs de los distintos trabajadores. El diagrama de actividad describe el flujo de trabajo. Permite identificar fcilmente las actividades que cada trabajador debe realizar, y ver si algn trabajador necesita participar ms de una vez en el flujo de trabajo. Los trabajadores y artefactos pueden participar en ms de un flujo de trabajo. Mritos del proceso unificado de desarrollo de software Todo el equipo puede comprender lo que tiene que hacer. Los desarrolladores pueden comprender lo que los dems estn haciendo. Los supervisores y directores, incluso sin comprender el cdigo, pueden comprender lo que los desarrolladores estn haciendo. Los desarrolladores, supervisores y directores pueden cambiar de proyecto o divisin sin tener que aprender un nuevo proceso. La formacin puede estandarizarse. El devenir puede planificarse y estimarse en coste con suficiente exactitud como para cumplir las expectativas. Soporte de las herramientas al ciclo de vida del software Gestin de requisitos: Almacenan, examinan, revisan, hacen seguimiento y navegan por los diferentes requisitos. Modelado visual: Automatizan el uso de UML. Herramientas de programacin: Editores, Compiladores, depuradores, detectores de errores y analizadores de rendimiento. Aseguramiento de la calidad: Para probar aplicaciones y componentes. Tambin hay herramientas que abarcan todo el ciclo de vida, e incluyen control de versiones, seguimiento de defectos, gestin de proceso, etc.
Capitulos 6 y 7

PUDS- Requisitos (I)

Etiquetas: Sis Administrativos III

Captura de Requisitos
Llamamos captura de requisitos al proceso de averiguar, normalmente en circunstancias difciles, lo que se debe construir. Los desarrolladores de software profesionales normalmente crean cdigos para otros y no para si mismos. Cualquier sistema tiene muchos usuarios (o tipos de usuarios) y ninguno tiene una visin global. Los usuarios no saben como puede hacerse ms eficiente la operacin. La mayora no sabe que partes de su trabajo pueden transformarse en software, con frecuencia no saben cuales son los requisitos ni tampoco como especificarlos de una forma precisa. Es cierto que los sistemas que construimos deberan dar soporte a los usuarios y que podemos aprender de ellos sobre sus interacciones. Sin embargo, es an ms importante que los sistemas den soporte a la misin para la cual se construyen. El sistema debera proporcionar valor al negocio que lo utiliza y a sus clientes.

El objeto del flujo de trabajo requisitos Es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una descripcin de los requisitos del sistema lo bastante buena para que se llegue a un acuerdo entre el cliente y los desarrolladores sobre que debe y que no debe hacer el sistema. El cliente debe ser capaz de leer y comprender el resultado de la captura de requisitos.

Visin general de la captura de requisitos

Enumerar los requisitos candidatos Comprender el contexto del sistema Capturar requisitos funcionales Capturar requisitos no funcionales Enumerar los requisitos candidatos Durante la vida del sistema, los clientes, usuarios, analistas y desarrolladores aparecen con muchas buenas ideas que consideramos como un conjunto de requisitos candidatos. Esta lista de caractersticas crece a medida que se aaden nuevos elementos, y mengua cuando algunas caractersticas se convierten en requisitos y se transforman en otros artefactos, como casos de uso. Cada caracterstica tiene un nombre corto y una breve explicacin o definicin. Cada caracterstica tiene tambin un conjunto de valores de planificacin. Estado (Propuesto, aprobado, includo o validados) Coste estimado de implementacin Prioridad (Crtico, importante o secundario) Nivel de riesgo asociado a la implementacin de la caracterstica (Crtico, significativo u ordinario) Estos valores de planificacin se utilizan para estimar el tamao del proyecto y dividir el proyecto en una secuencia de iteraciones. La prioridad y el nivel de riesgo asociados con una caracterstica se utilizan para decidir la iteracin en la que se implementar la caracterstica.

Comprender el contexto del Sistema Hay por lo menos dos aproximaciones para expresar el contexto de un sistema en una forma utilizable para desarrolladores de software: Modelado del dominio y modelado del negocio. Un modelo del dominio describe los conceptos importantes del contexto como objetos del dominio, y enlaza estos objetos unos con otros. La identificacin y la asignacin de un nombre para estos objetos nos ayuda a desarrollar un glosario de trminos que permitirn comunicarse mejor. Ms adelante, nos ayudarn a identificar algunas de las clases a medida que analizamos y diseamos el sistema. Un modelo del negocio puede describirse como un supraconjunto de un modelo de dominio, e incluye algo ms que solo los objetos del dominio. El objetivo del modelado del negocio es describir los procesos. A medida que los analistas modelan el negocio, aprenden mucho sobre el contexto del sistema software y lo describen en un modelo de negocio. El modelo de negocio especifica que procesos de negocio soportar el sistema, y tambin establece 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. Para el usuario, un caso de uso es un modo de utilizar el sistema. Si los analistas pueden describir todos los casos de uso que necesita el usuario, entonces saben lo que debe hacer el sistema. Los analistas deben especificar tambin cual ser la apariencia de la interface de usuario cuando se

lleven a cabo los casos de uso. La mejor forma de desarrollar esta especificacin de interface de usuario es esbozar varias versiones que muestren la informacin que se transferir, discutir los esbozos de los usuarios y construir visualizaciones o prototipos concretos para que los usuarios los prueben. 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. La fiabilidad hace referencia a caractersticas como la disponibilidad, exactitud, tiempo medio entre fallos, defectos por miles de lneas de cdigo (KLDC) y defectos por clase. La mayora de los requisitos de rendimiento afectan solo a ciertos casos de uso y por tanto deberan conectarse a ese caso de uso. Esto significa que estos requisitos se describirn en la descripcin del caso de uso. Algunos requisitos no funcionales hacen referencia a fenmenos del mundo real, otros son ms genricos y no pueden relacionarse con un caso de uso o clase concretos. Estos ltimos deberan gestionarse aparte en una lista de requisitos adicionales.

PUDS- Requisitos (II)

Etiquetas: Sis Administrativos III

El papel de los requisitos en el ciclo de vida del software

El modelo de casos de uso se desarrolla a lo largo de varios incrementos del desarrollo, donde las iteraciones aadirn nuevos casos de uso y detalle a las descripciones de los existentes. Durante la fase de inicio, los analistas identifican la mayora de los casos de uso para delimitar el sistema y el alcance del proyecto y detallan los ms importantes. Durante la fase de elaboracin, los analistas capturan la mayora de los requisitos restantes para que los desarrolladores puedan estimar el tamao del esfuerzo de desarrollo que se requerir. Los requisitos restantes se capturan (e implementan) durante la fase de construccin.

Modelo de Dominio - Modelo de Negocio

La comprensin del contexto del sistema mediante un modelo de dominio Los objetos del dominio representan las cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los objetos o clases del dominio pueden obtenerse de una especificacin de requisitos o mediante la entrevista con los expertos del dominio. Las clases del dominio aparecen en tres formas: Objetos del negocio, que representan cosas que se manipulan en el negocio. Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento. Sucesos que ocurrirn o han ocurrido. El modelo del dominio se describe mediante diagramas de UML. Desarrollo de un modelo del dominio El modelado del dominio se realiza habitualmente en reuniones organizadas por los analistas del dominio, que utilizan UML y otros lenguajes de modelado para documentar los resultados. El objetivo es comprender y describir las clases ms importantes dentro del contexto del sistema. Algunas veces, en los dominios muy pequeos, no es necesario desarrollar un modelo. En su lugar puede ser suficiente un glosario de trminos. El glosario y el modelo de dominio ayudan a los usuarios, clientes, desarrolladores y otros interesados a utilizar un vocabulario comn. La terminologa comn es

necesaria para compartir el conocimiento. Uso del modelo de dominio Las clases de dominio y el glosario de trmino se utilizan * Al describir los casos de uso * Al disear la interface de usuario. * Para sugerir clases internas al sistema en desarrollo durante el anlisis. Desarrollar un modelo del negocio es una alternativa a desarrollar un modelo de dominio.

Modelo de Negocio Como desarrollar un modelo de negocio: 1. Los modeladores del negocio deben confeccionar un modelo de casos de uso del uso del negocio que identifique los actores de negocio y los casos de uso del negocio que utilicen los actores. 2. Los modeladores deben desarrollar un modelo compuesto por trabajadores, entidades del negocio y unidades de trabajo. Se asocia a estos diferentes objetos las reglas del negocio y otras normas impuestas. 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. Diferencias entre modelo de negocio y modelo de dominio Las clases del dominio se obtienen de la base del conocimiento de unos pocos expertos, mientras que las entidades de negocio se derivan a partir de los clientes de negocio. Cada entidad debe estar motivada por su utilizacin en un caso de uso. Las clases de dominio tienen atributos, pero muy pocas o ninguna operaciones. No es as para las entidades del negocio: no solo identifica las entidades sino tambin todos los trabajadores que participarn en la realizacin de los casos de uso del negocio que las utilizan. Los trabajadores identificados en el modelado de negocio se utilizan como punto de partida para derivar un primer conjunto de actores y casos de uso. Bsqueda de casos de uso a partir de un modelo de negocio El analista identifica un actor por cada trabajador y por cada actor del negocio, 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, de modo que identificamos todas las realizaciones de casos de uso del negocio en las que participa. Una vez que hemos encontrado todos los roles de un trabajador (y de un actor del negocio) podemos encontrar los casos de uso de los actores del sistema. Por cada papel de un trabajador (y de un actor del negocio) necesitamos un caso de uso. Los analistas deben tambin decidir cuantas de las tareas de los trabajadores deberan automatizarse mediante sistemas de informacin y reorganizar los casos de uso. Un modelo de casos de uso captura todos los requisitos funcionales de un sistema y la mayora de los requisitos no funcionales, los requisitos que no pueden asociarse a ningn caso de uso en concreto se conocen como requisitos adicionales.

Requisitos Adicionales
Son fundamentalmente requisitos no funcionales que no pueden asociarse a ningn caso de uso en concreto. Un requisito de interface especifica la interface por medio de la cual el sistema debe interactuar con un

determinado elemento externo o establece restricciones condicionantes en formatos, tiempos u otros factores de relevancia. Un requisito fsico especifica una caracterstica fsica que debe poseer un sistema, como su material, forma, tamao o peso. Este tipo de requisito puede utilizarse para representar requisitos hardware como las configuraciones fsicas de red requeridas. Una restriccin de diseo limita el diseo limita el diseo de un sistema, como lo hacen las restricciones de extensibilidad y mantenibilidad o las restricciones relativas a la reutilizacin de sistemas heredados o partes esenciales de los mismos. 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 recursos y entornos operativos. Adems, existen otros requisitos, como los requisitos legales y las normativas.

PUDS- Requisitos (III)

Etiquetas: Sis Administrativos III
(Reitero: todo lo que subo referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh.)

Captura de Requisitos como Casos de Uso

Los requisitos funcionales se estructuran de forma natural mediante casos de uso, y la mayora de los requisitos no funcionales son especficos de un nico caso de uso. Los requisitos no funcionales restantes se mantienen en un documento aparte y se denominan requisitos adicionales. Los casos de uso proporcionan un medio intuitivo y sistemtico para la captura de requisitos funcionales. Mediante la utilizacin de casos de uso, los analistas se ven obligados a pensar en trminos de quines son los usuarios y qu necesidades u objetivos de la empresa pueden cumplir.

Artefactos
Los artefactos de la captura de requisitos son el modelo de casos de uso (que incluye los casos de uso, los actores y las relaciones entre ambos) y algn otro artefacto adicional, como un modelo de interfaz de usuario. Modelo de casos de uso Permite que los desarrolladores de software y los clientes lleguen a un acuerdo sobre los requisitos, es decir, sobre las condiciones y posibilidades que debe cumplir el sistema. Sirve como acuerdo entre clientes y desarrolladores y proporciona la entrada fundamental para el anlisis, diseo y pruebas. Si contiene un gran nmero de casos de uso y/o actores, puede ser til introducir paquetes para reducir su tamao. Actor Cada tipo de usuario se representa mediante uno o ms actores. Tambin se representa mediante actores cada sistema externo con el cual interacta el sistema. Los actores representan terceros que colaboran con el sistema. Constituyen el entorno externo del sistema. Los actores suelen corresponderse con trabajadores (o actores del negocio). Una instancia de un actor es un usuario concreto que interacta con el sistema.

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 los actores. Un caso de uso es un clasificador, lo cual quiere decir que tiene operaciones y atributos. Una descripcin de un caso de uso puede incluir diagramas de estado, diagramas de actividad, colaboraciones y diagramas de secuencia. Los diagramas de estado especifican el ciclo de vida de las instancias de los casos de uso en trminos de estados y transiciones entre estados. Cada transicin es una secuencia de acciones. Los diagramas de actividad describen el ciclo de vida con ms detalle, describiendo tambin la secuencia temporal de acciones que tiene lugar en cada transicin. Los diagramas de colaboracin y los de secuencia se utilizan para describir las interacciones entre instancias. Una instancia de caso de uso es la realizacin de un caso de uso. Es lo que el sistema lleva a cabo cuando obedece a un caso de uso: interacta con instancias de actores y ejecuta una serie de acciones segn se especifica en el caso de uso y el diagrama de estados o el diagrama de actividad. Los casos de uso tienen atributos. Estos atributos representan los valores que una instancia de un caso de uso utiliza y manipula durante la ejecucin de un caso de uso. Las instancias de los casos de uso son consideradas atmicas, es decir, cada una de ellas se ejecuta por completo o no se ejecuta nada. Tampoco interactan con otras instancias de casos de uso. Aunque en la realidad existen problemas de interferencia entre casos de uso, estos no pueden resolver aqu, sino que se posponen hasta el anlisis y el diseo. Flujo de sucesos El flujo de sucesos de cada caso de uso puede plasmarse como una descripcin textual de la secuencia de acciones del caso de uso. Requisitos Especiales Descripcin textual que agrupa a todos los requisitos no funcionales del caso de uso. Deben tratarse en flujos de trabajo posteriores como anlisis, diseo o implementacin. Descripcin de la arquitectura La descripcin de la arquitectura contiene una vista de los casos de uso significativos para la arquitectura. Aquellos que describan alguna funcionalidad importante y crtica o que impliquen algn requisito importante que deba desarrollarse pronto dentro del ciclo de vida del software. Glosario Un glosario es muy til para alcanzar consenso entre los desarrolladores con respecto a la definicin de diversos conceptos y nociones y para reducir en general el riesgo de confusiones. Podemos obtener un glosario a partir de un modelo de negocio o de un modelo de dominio, pues, debido a que es menos formal, es ms fcil de mantener y es ms intuitivo para utilizarlo con terceras personas. Prototipo de interfaz de Usuario Nos ayuda a comprender y especificar las interacciones entre actores humanos y el sistema.

PUDS- Requisitos (IV)

Etiquetas: Sis Administrativos III

Trabajadores
Analista de Sistemas Es el responsable del conjunto de requisitos que estn modelados en los casos de uso. Debe delimitar el sistema, encontrando los actores y casos de uso y asegurando que el modelo de casos de uso es completo y consistente. Puede utilizar un glosario para conseguir un acuerdo en los trminos comunes, nociones y conceptos durante la captura de requisitos. Aunque el analista de sistemas es responsable del modelo de casos de uso y de lo que contiene, no es responsable de cada caso de uso en particular. En cambio, dirige el modelado y coordina la captura de requisitos. Hay un analista de sistemas por cada sistema, no obstante, en la prctica, est respaldado por un equipo que incluye a otros analistas. Especificador de casos de uso El trabajo de captura de requisitos puede no estar dirigido por un solo individuo. De hecho, el especificador de casos de uso asiste al analista de sistemas, tomando la responsabilidad de la descripcin detallada de uno o ms casos de uso. Para ello necesita trabajar con los usuarios reales de los casos de uso. Diseador de interfaz de usuario Los diseadores de interfaz de usuario dan forma visual a las interfazs de usuario. Es conveniente que cada diseador de interfaz de usuario de forma a las interfazs de usuario de dos o ms actores. Arquitecto Participa en el flujo de trabajo requisitos para describir la vista de la arquitectura del modelo de casos de uso

PUDS- Requisitos (V)

Etiquetas: Sis Administrativos III

Flujo de Trabajo
Cuando los trabajadores ejecutan las actividades, crean y modifican artefactos. Describimos los flujos de trabajo como una secuencia de actividades ordenadas de tal manera que cada actividad produce una salida que sirve de entrada a la siguiente actividad. No obstante, en el mundo real no es necesario trabajar en secuencia. Una actividad puede ser retomada muchas veces. Primero, el (o los) analista de sistemas ejecuta la actividad encontrar actores y casos de uso. Debe asegurarse de que el modelo de casos de uso captura todos los requisitos que son entradas al flujo de trabajo, es decir, la lista de caractersticas y el modelo de dominio o de negocio. Entonces, el (o los) arquitecto identificar los casos de uso relevantes arquitectnicamente para proporcionar entradas a la priorizacin de casos de uso que van a ser desarrollados en la iteracin actual. Hecho esto, los especificadores de casos de uso describen los casos de uso que se han priorizado. Ms o menos en paralelo, los diseadores de interfaz de usuario sugieren las interfaces de usuario adecuadas para cada actor basndose en los casos de uso. Entonces, el (o los) analista de sistemas reestructura el modelo de casos de uso definiendo generalizaciones entre los casos de uso para hacerlo lo ms comprensible posible.

Encontrar Actores y Casos de uso Para: Delimitar el sistema y su entorno. Esbozar qu y quien interactuar con el sistema y que funcionalidad se espera del sistema. Capturar y definir un glosario de trminos comunes esenciales para la creacin de descripciones detalladas de las funcionalidades del sistema. Pasos: 1. Encontrar los actores 2. Encontrar los casos de uso 3. Describir brevemente cada caso de uso. 4. Describir el modelo de casos de uso completo. Estos pasos a menudo se hacen simultneamente. El resultado de esta actividad es un modelo de casos de uso nuevo o modificado. Encontrar los actores: Primero, debera ser posible identificar al menos un usuario que pueda representar el actor candidato. Segundo, no debera haber coincidencias entre los roles que desempean los actores en relacin con el sistema. Si eso ocurre, deberamos combinar los actores que cumplen los mismos roles o crear un actor generalizado que cumpla los roles comunes. El analista da nombre a los actores y describe brevemente el papel de cada actor (con necesidades y responsabilidades) y para que utiliza el sistema el actor. Encontrar los casos de uso: El analista de sistemas identificar los casos de uso a travs de clientes y usuarios. Repasar los actores uno por uno y propondr casos de uso para cada actor. El actor necesitar casos de uso para soportar su trabajo y para informar al sistema de sucesos externos. Tambin puede haber actores adicionales para el mantenimiento del sistema. Algunos de los candidatos no llegarn a ser casos de uso, sino que se convertirn en partes de casos de uso. El nombre elegido para cada caso de uso debe hacer pensar en la secuencia de acciones concreta, y comenzar con un verbo que refleje el objetivo de la interaccin. Una secuencia de acciones se puede especificar en un caso de uso o en varios casos de uso a los cuales el actor invoca uno tras otro. Cada ejecucin satisfactoria de un caso de uso debe proporcionar algn valor a al actor. Describir brevemente cada caso de uso: No es suficiente con comprender y describir cada caso de uso aisladamente. Tambin necesitamos ver como estn relacionados los casos de uso entre si y con los actores. Descripcin del modelo de casos de uso en su totalidad: No hay una regla estricta sobre qu incluir en el diagrama. Podemos dibujar diagramas para mostrar los casos de uso que participan en un caso de uso de negocio o quiz para ilustrar los casos de uso que ejecuta un actor. Para asegurar la consistencia resulta prctico desarrollar un glosario de trminos. Cuando la descripcin del modelo est preparada, dejamos que clientes y usuarios den el visto bueno del modelo de casos de uso, convocando a una reunin informal para ver si: - Se ha 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. Priorizar casos de uso: El propsito es determinar que casos de uso son necesarios para el desarrollo en las primeras iteraciones y cuales pueden dejarse para ms adelante. Los resultados se recogen en la vista de la arquitectura del modelo de casos de uso. Esta vista se revisa con el jefe de proyecto y se utiliza al hacer la planificacin de lo que debe desarrollarse dentro de una

iteracin. Detallar un caso de uso: El objetivo principal de detallar cada caso de uso es describir su flujo de sucesos en detalle. Para ellos, cada especificador de casos de uso debe trabajar estrechamente con los usuarios reales de los casos de uso Estructuracin de la descripcin de casos de uso: Un caso de uso define los estados que las instancias de los casos de uso pueden tener y la posible transicin entre estos estados. Cada transicin es una secuencia de acciones que se ejecutan en una instancia del caso de uso cuando esta se dispara. El grafico de transicin de estados puede llegar a ser bastante intrincado. Para describirlo de manera simple y precisa, una tcnica consiste en elegir un camino bsico desde el inicio al fin, y describir camino y entonces, describir en secciones separadas el resto de los caminos. Las alternativas, desviaciones o excepciones pueden ocurrir por que: El actor puede elegir. Est implicado ms de un actor en el caso de uso. El sistema puede detectar entradas errneas de los actores. Algunos recursos del sistema pueden tener un mal funcionamiento. El camino bsico debe ser aqul que proporciona un valor ms obvio al actor. Debido a que los casos de uso deben ser entendidos por los desarrolladores y por los clientes y usuarios, deberan describirse siempre utilizando un castellano corriente. Qu incluir en una descripcin de caso de uso?: Definir un estado inicial como precondicin Cmo y cuando comienza el caso de uso El orden requerido en el que las acciones se deben ejecutar Como y cuando terminan los casos de uso Definir los posibles estados finales como postcondicionadores Caminos de ejecucin que no estn permitidos Descripciones de caminos alternativos que estn incluidos junto con la descripcin del camino bsico Descripciones de caminos alternativos que han sido extradas de la descripcin del camino bsico Interaccin del sistema con los actores y que cambios producen Utilizacin de objetos, valores y recursos de sistema Describir explcitamente que hace el sistema, acciones que ejecuta, responsabilidades del sistema y de los actores Mantenemos simple el modelo de casos de uso prohibiendo las interacciones entre las instancias de caso de uso y el acceso de una instancia a los atributos de las otras. Si el sistema interacta con otros sistemas es necesario especificar esa interaccin. Esto se debe hacer en las primeras iteraciones de la fase de elaboracin, debido a que la realizacin de comunicaciones entre sistemas tiene habitualmente influencia en la arquitectura. Las descripciones de casos de uso se dan por finalizadas cuando se consideran comprensibles, correctas, completas y consistentes. Solamente los clientes y usuarios pueden verificar si los casos de uso son los correctos. Formalizacin de la descripcin de casos de uso: En algunas ocasiones, como cuando tenemos un sistema en tiempo real complejo, los casos de uso pueden ser muy complejos, por eso puede llegar a ser necesaria una tcnica de descripcin ms estructurada. Entonces puede ser til utilizar una tcnica de modelado visual para describir los casos de uso. Pueden utilizarse los diagramas de estado para describir los estados de los casos de uso y las transiciones entre esos estados. Pueden utilizarse los diagramas de actividad para describir las transiciones entre estados con ms detalle como secuencias de acciones.

 Se pueden utilizar los diagramas de interaccin para describir como interacta una instancia de caso de uso con la instancia de un actor. Las descripciones simplemente textuales de los casos de uso son con frecuencia suficientes. En muchos casos, las descripciones textuales y los diagramas pueden complementarse.

Prototipar la interfaz de Usuario Necesitamos disear la interfaz de usuario que permita al usuario llevar a cabo los casos de uso de manera eficiente. Hacemos un diseo lgico de la interfaz de usuario, creamos el diseo fsico y desarrollamos prototipos. El resultado final de esta actividad es un conjunto de esquemas de interfaces de usuario y prototipos de interfaces de usuario que especifican la apariencia de esas interfaces de cara a los actores ms importantes. Crear el diseo lgico de una interfaz de usuario: Cuando los actores interacten con el sistema, utilizarn y manipularn elementos de interfaces. A menudo, estos son trminos del glosario. Los actores pueden experimentas estos elementos de las interfaces de usuario como conos, listas de elementos u objetos en un mapa 2D y pueden manipularlos por seleccin, arrastre o hablando con ellos. El diseador de interfaces de usuario identifica y especifica estos elementos actor por actor, recorriendo todos los casos de uso a los que el actor puede acceder e identificando los elementos apropiados. Un nico elemento de interfaz de usuario puede intervenir en muchos casos de uso. Una forma prctica de trabajo es representar los elementos de la interfaz de usuario mediante una nota adhesiva, pegarlas en una pizarra y ordenarlas para ilustrar la apariencia de la interfaz de usuario. Seguidamente, los diseadores de interfaces de usuario describen como pueden utilizar los actores estos elementos cuando trabajen con los casos de uso. De esta forma, los diseadores de interfaz de usuario aseguran que cada caso de uso es accesible a travs de sus elementos de las interfaces de usuario. No obstante, tambin deben asegurarse de que tiene una interfaz de usuario bien integrada, fcil de utilizar y consistente. Creacin de un diseo y un prototipo fsicos de interfaz de usuario: Los diseadores de interfaz de usuario primero preparan esquemas aproximados de la configuracin de elementos de las interfaces de usuario tiles para los actores. Despus bosquejan elementos adicionales necesarios para combinar elementos (contenedores, ventanas, etc). Estos esquemas pueden prepararse despus del desarrollo de las notas adhesivas. Puede realizarse un prototipo ejecutable o uno para cada actor. La validacin de las interfaces de usuarios a travs de revisiones de prototipos y esquemas puede prevenir muchos errores que sern ms caros de corregir despus. Los prototipos tambin pueden revisarse superficialmente en la descripcin de casos de uso. Los revisores deben verificar que cada interfaz de usuario: Permita que el actor navegue de forma adecuada Proporcione una apariencia agradable y una forma consistente de trabajo Cumpla con estndares relevantes, como color, tamao de botones, etc. La implementacin de las interfaces de usuarios reales se construye en paralelo con el resto del sistema.

Estructurar el modelo de casos de uso El modelo de casos de uso se estructura para: Extraer descripciones de funcionalidad generales y compartidas. Extraer descripciones de funcionalidad adicionales u opcionales. En este punto el analista de sistemas puede reestructurar el conjunto completo de casos de uso para

hacer que el modelo sea ms fcil de entender y de trabajar con l. Debe buscar comportamientos compartidos y extensiones. 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, esta comparticin puede extraerse y describirse en un caso de uso separado por medio de una generalizacin. La generalizacin entre casos de uso es una clase de herencia en la cual las instancias de los casos de uso generalizados pueden ejecutar todo el comportamiento descripto en el caso de uso generalizador. La generalizacin se emplea para simplificar la forma de trabajo y la comprensin del modelo de casos de uso y para reutilizar casos de uso semifabricados. El caso de uso semifabricado existe solamente para que otros casos de uso lo utilicen, y se les llama casos de uso abstractos. Un caso de uso abstracto no puede instanciarse por si mismo. Identificacin de descripciones de funcionalidad adicionales y opcionales: Relacin de extensin (extend relationship) modela la adicin de una secuencia de acciones a un caso de uso. Una extensin se comporta como algo que se aade a la descripcin original de un caso de uso. La relacin de extensin incluye tanto una condicin para la extensin como una referencia a un punto de extensin en el caso de uso destino. Una vez que una instancia de un caso de uso llega al punto de extensin al cual se refiere la relacin, se evala la condicin de la extensin. Si la condicin se cumple, la secuencia seguida por la instancia del caso de uso incluye la secuencia del caso de uso extendido. Los casos de uso reales son aquellos que aportan valor a los usuarios, as que debemos identificar criterios separados para realizar buenos casos de uso concretos, buenos casos de uso abstractos y buenas extensiones de caso de uso. Los concretos no deben describir comportamientos que sean compartidos con otros casos de uso concretos. Una extensin especifica comportamiento adicional para otros casos de uso, independientemente de si su comportamiento es opcional u obligatorio. Una vez que hemos identificado los casos de uso concretos, los abstractos y las extensiones, podemos combinarlos para tener un caso de uso real. No obstante, normalmente seguimos el camino contrario, comenzando por los casos de uso reales e identificando comportamientos comunes que distinguen a los casos de uso concretos de los abstractos y adicionales (que tratamos como extensiones). Identificacin de otras relaciones entre casos de uso: Relaciones de inclusin (Include relationship). Una relacin inversa a la de extensin. Cuando incluimos un caso de uso, la secuencia de comportamiento y los atributos de caso de uso incluidos, se encapsulan y no pueden modificarse o accederse. Precaucin: La estructura de los casos de uso y de sus relaciones debe reflejar los casos de uso reales. Cuanto ms diverjan, ms complicado ser comprender los casos de uso y sus propsitos. Cada caso de uso individual necesita ser tratado como un artefacto separado. Por ese motivo los casos de uso no deberan ser demasiados o demasiado pequeos. Evite descomponer funcionalmente los casos de uso. La funcionalidad que definen los casos de uso se descompondr a su vez de una forma orientada a objetos en colaboraciones de objetos de anlisis conceptuales.
Capitulo 8

PUDS- Anlisis (I)

Etiquetas: Sis Administrativos III Durante el Anlisis analizamos los requisitos que se describieron en la captura de requisitos, refinndolos y estructurndolos. El objetivo es conseguir una comprensin ms precisa de los requisitos y una descripcin que sea fcil de mantener y nos ayude a estructurar el sistema. Para comunicar de manera eficiente las funciones del sistema al cliente: Los casos de uso deben mantenerse tan independientes unos de otros como sea posible. Los aspectos referidos a la interferencia, concurrencia y conflictos entre casos de uso, pueden quedar sin resolver en la captura de requisitos. Los casos de uso deben describirse utilizando el lenguaje del cliente. A causa de esto, perdemos poder expresivo, as que quedan sin tratar muchos detalles. Debe estructurarse cada caso de use para que forme una especificacin de funcionalidad completa e intuitiva. Los aspectos relativos a redundancias entre los requisitos descriptos puede que queden sin resolver durante la captura de requisitos. El propsito fundamental del anlisis es resolver estos temas sin tratar analizando los requisitos con mayor profundidad, pero con la gran diferencia de poder utilizar el lenguaje de los desarrolladores. Modelo de Anlisis Descripto con lenguaje del desarrollador Es una vista interna del sistema Estructurado por clases y paquetes estereotipados. Proporciona la estructura a la vista interna. Utilizado por los desarrolladores para comprender como debera darse forma al sistema, es decir, como debera ser diseado e implementado. No debera contener redundancias ni inconsistencias entre requisitos. Esboza como llevar a cabo la funcionalidad dentro del sistema. Sirve como una primera aproximacin del diseo. Define realizaciones de casos de uso, y cada una de ellas representa el anlisis de un caso de uso del modelo de casos de uso. El anlisis nos ayuda a refinar los requisitos y nos permite razonar sobre los aspectos internos del sistema, incluidos sus recursos compartidos internos. Un recurso interno puede representarse como un objeto en el modelo de anlisis. Esta estructura no solo es til para el mantenimiento de los requisitos como tales, sino que tambin se utiliza como entrada en las actividades de diseo e implementacin. El modelo de anlisis puede considerarse una primera aproximacin al modelo de diseo, aunque es un modelo por si mismo, sin embargo, la conservacin de la estructura no siempre tiene lugar en la prctica: Si resulta econmico, puede modificarse la estructura durante la transicin a modelo de diseo.

PUDS- Anlisis (II)

Etiquetas: Sis Administrativos III Por qu el anlisis no es diseo ni implementacin El diseo y la implementacin son mucho ms que el anlisis, por lo que se requiere una separacin de intereses. El anlisis es refinamiento y estructuracin de requisitos, mientras que en el diseo debemos moldear el sistema y encontrar su forma: una forma con integridad. El diseo y la implementacin se preocupan en dar forma al sistema de manera que de vida a todos los

requisitos. El Objeto del Anlisis El modelo de anlisis es importante por que: Ofrece una especificacin ms precisa de los requisitos. Se describe utilizndole lenguaje de los desarrolladores. Estructura los requisitos de un modo que facilita su comprensin, preparacin, modificacin y mantenimiento. Puede considerarse como una primera aproximacin al modelo de diseo. Ejemplos concretos de cuando hacer anlisis El anlisis proporciona una visin general del sistema que puede ser ms difcil de contener mediante el estudio de los resultados de diseo y la implementacin, debido a que contienen demasiados detalles. Una visin general como esta puede ser muy valiosa para formar arquitectos del sistema, proporcionar una vista conceptual, precisa y unificadora de implementaciones alternativas o hacer reingeniera de sistema. El papel del anlisis en el ciclo de vida del software Variantes bsicas en la manera de ver y emplear el anlisis: 1. El proyecto utiliza 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 cuando el diseo y la implementacin estn en marcha durante la fase de construccin, se deja de actualizar el anlisis. 3. El proyecto no utiliza en absoluto el modelo de anlisis, sino que analiza los requisitos como parte integrada en la captura de requisitos. Al elegir entre las dos primeras variantes, debemos sopesar las ventajas de mantener el modelo de anlisis, con el coste que conlleva. En cuanto a la tercera variante, el proyecto puede no solo evitar el coste de mantener el modelo de anlisis, sino tambin el de introducirlo. Sin embargo, normalmente, las ventajas de trabajar con un modelo de anlisis por lo menos al principio del proyecto sobrepasan los costes de emplearlo. Solo deberamos emplear esta variante en casos excepcionales para sistemas extraordinariamente simples.

PUDS- Anlisis (III)

Etiquetas: Sis Administrativos III Modelo de Anlisis El modelo de anlisis se representa mediante un sistema de anlisis (paquete de ms alto nivel del modelo). Los otros paquetes de anlisis son una forma de organizar el modelo en partes ms manejables. Las clases de anlisis representan abstracciones de clases y posiblemente de subsistemas. Los casos de uso se describen mediante clases de anlisis y sus objetos, y se representan mediante colaboraciones dentro del modelo de anlisis que llamamos realizaciones de caso de uso.

Clase de Anlisis Una clase de anlisis se centra en el tratamiento de requisitos funcionales. Esto hace que sea ms conceptual que sus contrapartidas de diseo e implementacin. Una clase de anlisis raramente define u ofrece un interfaz en trmino de operaciones de sus

signaturas. Una clase de anlisis define atributos, aunque esos atributos tambin son de un nivel bastante alto. Los tipos de esos atributos son conceptuales y reconocibles en el dominio del problema: Con frecuencia pasan a ser clases en el diseo y la implementacin. Una clase de anlisis participa en relaciones, aunque esas relaciones son conceptuales. Las clases de anlisis siempre encajan en uno de tres estereotipos bsicos: de interfaz, de control o de entidad. Cada estereotipo implica una semntica especfica, lo cual constituye un mtodo potente y consistente de identificar y describir las clases de anlisis. Clases de Interfaz Las clases de interfaz se utilizan para modelar la interaccin entre el sistema y sus actores. Las clases de interfaz modelan las partes del sistema que dependen de sus actores. Un cambio en un interfaz de usuario o en un interfaz de comunicaciones. Queda normalmente aislado en una o ms clases de interfaz. Las clases de interfaz representan a menudo abstracciones de ventanas, formularios, paneles, interfaces de impresoras, sensores, etc. An as, deberan mantenerse en un nivel alto y conceptual. Es suficiente con que las clases de interfaz describan lo que se obtiene con la interaccin. No es necesario que describan cmo. Clases de Entidad Las clases de entidad se utilizan para modelar informacin que posee una vida larga y que es a menudo persistente. Modelan la informacin y el comportamiento asociado de algn fenmeno o concepto, objeto o suceso del mundo real. Un objeto de entidad no ha de ser necesariamente pasivo y pueden tener un comportamiento complejo relativo a la informacin que representa. Los objetos de entidad aslan los cambios en la informacin que representan. 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 en concreto. Tambin se utilizan para representar derivaciones y clculos complejos que no pueden asociarse con ninguna informacin concreta de larga duracin almacenada por el sistema (es decir, de entidad). Las clases de control manejan y coordinan acciones y flujos de control principales y delegan trabajo a otros objetos. Las clases de control no encapsulan aspectos relacionados con las interacciones, actores ni entidad, eso lo encapsulan las clases de interfaz y de entidad. En cambio, encapsulan los cambios del control, la coordinacin, la secuencia, las transacciones y a veces la lgica del negocio compleja.

PUDS- Anlisis (IV)

Etiquetas: Sis Administrativos III Realizacin de caso uso-anlisis Una realizacin de caso de uso-anlisis describe como se lleva a cabo y se ejecuta un caso de uso determinado en trminos de las clases del anlisis y de sus objetos del anlisis en interaccin. Posee una descripcin textual del flujo de sucesos, diagramas de clase que muestran sus clases de anlisis participantes, y diagramas de interaccin que muestran la realizacin de un flujo o escenario particular del caso de uso. Diagramas de Clase

Una clase de anlisis y sus objetos normalmente participan en varias realizaciones de casos de uso, por tanto es importante adjuntar diagramas de clase a las realizaciones de casos de uso, mostrando sus clases participantes y sus relaciones. Diagramas de interaccin La secuencia de acciones en un caso de uso comienza cuando un actor invoca un caso de uso mediante el envo de algn tipo de mensaje al sistema. Un objeto de interfaz recibir este mensaje. Enviar a su vez un mensaje a algn otro objeto, y de esta forma, los objetos implicados interactuarn para llevar a cabo el caso de uso. En el anlisis, preferimos mostrar esto con diagramas de colaboracin. En los diagramas de colaboracin, mostramos las interacciones entre objetos, creando enlaces entre ellos y aadiendo mensajes a esos enlaces. El nombre de un mensaje debera denotar el propsito del objeto invocante. Los objetos de interfaz a menudo se crean y se finalizan dentro de una sola realizacin de caso de uso. Un objeto de entidad suele tener una vida larga y participa en varias realizaciones de caso de uso antes de su destruccin. Las clases de control suelen encapsular el control asociado con un caso de uso concreto. Sin embargo hay excepciones. Flujo de sucesos-anlisis Los diagramas (especialmente los diagramas de colaboracin) de una realizacin de caso de uso, pueden ser difciles de leer por si mismos, de modo que puede ser til un texto adicional que los explique. El texto no debera mencionar ninguno de los atributos, responsabilidades y asociaciones del objeto, debido a que cambian con bastante frecuencia y sera difcil mantenerlos. Requisitos Especiales Los requisitos especiales son descripciones textuales que recogen todos los requisitos no funcionales sobre una realizacin de caso de uso. Algunos de estos requisitos ya se haban capturado y solo se cambian a una realizacin de caso de uso-anlisis. Sin embargo, algunos puedes ser requisitos nuevos o derivados que se encuentran a medida que avanza el trabajo de anlisis. 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 de anlisis. Los paquetes de anlisis: > Deberan ser cohesivos y dbilmente acoplados. > Pueden representar una separacin de intereses. > Deberan crearse basndonos en los requisitos funcionales y en el dominio del problema. > Deberan ser reconocibles por las personas con conocimiento del dominio. > Probablemente se convertirn en subsistemas o se distribuirn entre ellos.

Paquetes de Servicio Aparte de proporcionar casos de uso a sus actores, todo sistema tambin proporciona un conjunto de servicios. Un caso de uso especifica una secuencia de acciones: Normalmente no existen de manera aislada. Un servicio representa un conjunto coherente de acciones relacionadas funcionalmente que se utiliza en varios casos de uso. Un servicio es indivisible en el sentido de que el sistema necesita ofrecerlo o todo entero o nada en absoluto. Los casos de uso son para los usuarios, y los servicios son para los clientes. Un caso de uso requiere

acciones de varios servicios. En el proceso unificado, el concepto de servicio est soportado por los paquetes de servicio. Los paquetes de servicio se utilizan en un nivel ms bajo de la jerarqua de paquetes del anlisis, para estructurar el sistema de acuerdo a los servicios que proporciona. Un paquete de servicio: Contiene un conjunto de clases relacionadas funcionalmente. Es indivisible. Cuando se lleva a cabo un caso de uso, puede que sea participantes uno o ms de ellos. Depende a menudo de otro paquete de servicio. Normalmente solo es relevante para uno o unos pocos actores. La funcionalidad definida por este cuando se disea e implementa, puede gestionarse como una unidad de distribucin separada. Cuando queda excluido tambin lo queda todo caso de uso cuya realizacin requiera el paquete de servicio. Pueden ser mutuamente excluyentes o representar distintos aspectos o variantes del mismo servicio. Constituyen una entrada fundamental para las actividades de diseo e implementacin subsiguientes. Caractersticas de paquetes de servicio: - Cohesivos - Indivisibles - Dbilmente acoplados - Distribuidos de manera separada Esto hace que los paquetes de servicio sean principales candidatos para la reutilizacin, tanto dentro de un sistema como entre sistemas relacionados. Los paquetes de servicio cuyos servicios se centran alrededor de una o ms clases de entidad son probablemente reutilizables en diferentes sistemas que soporten el mismo negocio o dominio, debido a que las clases de entidad se obtienen a partir de clases de entidad del negocio o de clases del dominio. Los paquetes de servicio y los servicios, son independientes de los casos de uso en el sentido de que un paquete de servicio puede emplearse en varias realizaciones de caso de uso diferentes.

PUDS- Anlisis (V)

Etiquetas: Sis Administrativos III Descripcin de la arquitectura La descripcin de la arquitectura contiene una vista de la arquitectura del modelo de anlisis que muestra sus artefactos significativos para la arquitectura. Artefactos del modelo de anlisis que se consideran significativos para la arquitectura: Descomposicin del modelo de anlisis y sus dependencias: Suele tener efecto en los subsistemas de las capas superiores durante el diseo y la implementacin. Clases fundamentales del anlisis: Clases de entidad que encapsulan un fenmeno importante del dominio del problema, clases de interfaz que encapsulan interfaces de comunicacin importantes, etc. Realizaciones de caso de uso: que describan una funcionalidad importante y crtica, que tengan una cobertura amplia o que se centren en un caso de uso importante. Trabajadores - Arquitecto: Es responsable de la arquitectura e integridad del modelo de anlisis, garantizando que este sea correcto, consistente y legible como un todo. El modelo de anlisis es correcto cuando realiza la funcionalidad descrita en el modelo de casos de uso y solamente esa. - Ingeniero de casos de uso: Es responsable de la integridad y el diseo de una o ms realizaciones de caso de uso, garantizando que cumplen los requisitos que recaen sobre ellos. Una realizacin de caso de

uso debe llevar a cabo correctamente el comportamiento de su caso de uso y slo ese comportamiento. - 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 de anlisis cumple los requisitos que se esperan de ella de acuerdo a las realizaciones de caso de uso de las que participa. Tambin mantiene la integridad de uno o varios paquetes de anlisis. Suele ser responsable de un paquete de anlisis, as como de las clases contenidas en l. Si existe una correspondencia directa entre un paquete de anlisis y los subsistemas de diseo correspondientes, debera ser tambin responsable de estos subsistemas. -------------------------Flujo de trabajo Los arquitectos comienzan la creacin del modelo de anlisis identificando los paquetes de anlisis principales, las clases de entidad evidentes y los requisitos comunes. Despus, los ingenieros de casos de uso realizan cada caso de uso en trminos de las clases de anlisis participantes, exponiendo los requisitos de comportamiento de cada clase. Los ingenieros de componentes especifican posteriormente estos requisitos y los integran dentro de cada clase creando responsabilidades, atributos y relaciones consistentes para cada clase. El arquitecto identifica de manera continua nuevos paquetes de anlisis, clases y requisitos comunes a medida que el modelo de anlisis evoluciona, y los ingenieros de componentes responsables de los paquetes de anlisis concretos continuamente los refinan y mantienen. Anlisis de la arquitectura: Su propsito es esbozar el modelo de anlisis y la arquitectura. -Identificacin de los paquetes de anlisis: Se hace basndonos en los requisitos funcionales y el dominio. Proporciona un medio para organizar el modelo de anlisis en piezas ms pequeas y manejables. Una forma directa de identificar paquetes de anlisis es asignar un nmero de casos de uso a un paquete y despus realizar la funcionalidad correspondiente: Casos de uso requeridos para dar soporte a un determinado proceso de negocio. Casos de uso requeridos para dar soporte a un determinado actor del sistema. Casos de uso relacionados (este conjunto es coherente cuando cada uno especializa o extiende a otro). -Gestin de los aspectos comunes entre paquetes de anlisis: Encontrar aspectos comunes entre los paquetes identificados. -Identificacin de paquetes de servicio: Se suele hacer cuando los requisitos funcionales se comprenden bien y existen la mayora de las clases del anlisis. Pasos: Identificar un paquete de servicio por cada servicio opcional. Identificar un paquete de servicio por cada servicio proporcionado por clases relacionadas funcionalmente. Una clase A y una clase B estn relacionadas funcionalmente cuando: Un cambio en A requiere un cambio en B. La eliminacin de A hace que B sea superflua. Los objetos de A interactan intensamente con los de B. -Definicin de las dependencias entre paquetes de anlisis: Definir dependencias entre los paquetes de anlisis que estn relacionados. La cohesin alta y el acoplamiento dbil hacen que los paquetes sean fciles de mantener debido a que cambiar algunas clases del paquete afectar principalmente a clases dentro del propio paquete. Por tanto, hay que intentar reducir el nmero de relaciones entre clases de distintos paquetes. Tambin puede ser til estratificar el modelo de anlisis haciendo que los paquetes especficos de la aplicacin queden en una capa superior y los generales en una capa inferior. -Identificacin de clases de entidad obvias: Debera ser bastante con un esbozo inicial de las clases significativas para la arquitectura. En otro caso, probablemente tendremos que rehacer gran parte del trabajo cuando se utilicen los casos de uso para identificar las clases de entidad realmente necesarias. Una clase de entidad que no participa en una realizacin de caso de uso no es necesaria. -Identificacin de requisitos especiales comunes: Un requisito especial es un requisito que aparece

durante el anlisis. El arquitecto es el responsable de identificar los requisitos especiales. En algunos casos, los requisitos especiales aparecen a medida que se exploran las realizaciones de casos de uso y las clases del anlisis. Analizar Un Caso de Uso: Analizamos un caso de uso para > Identificar las clases de anlisis cuyos objetos son necesarios para llevar a cabo el flujo de sucesos del caso de uso. > Distribuir el comportamiento de los casos de uso entre los objetos de anlisis que interactan. > Capturar requisitos especiales sobre la realizacin de casos de uso. -Identificacin de clases de anlisis: Identificamos las clases de control, entidad e interfaz necesarias para realizar los casos de uso y esbozamos sus nombres, responsabilidades, atributos y relaciones. Normas generales para identificar las clases de anlisis: > Identificar las clases de entidad mediante un estudio en detalle de la descripcin del caso de uso y de cualquier modelo de dominio que se tenga. Considerar que informacin debe utilizarse y manipularse en la realizacin del caso de uso y cual es mejor capturar como atributo. > Identificar una clase de interfaz para cada actor humano. > Identificar una clase de interfaz primitiva para cada clase de entidad encontrada. > Identificar una clase de interfaz central para cada actor que sea un sistema. > Identificar una clase de control responsable del tratamiento de control y coordinacin de la realizacin de caso de uso y despus refinarla -Descripcin de interacciones entre objetos del anlisis: Esto se hace mediante diagramas de colaboracin que contienen instancias de actores participantes, objetos de anlisis y sus enlaces. Si el caso de uso tiene flujos o subflujos diferenciados y distintos, crear un diagrama de colaboracin para cada flujo. Un diagrama de colaboracin se crea comenzando por el principio del flujo del caso de uso y continuando paso a paso a travs de los objetos de anlisis e instancias de actor que sean necesarias para realizarlo. Tener en cuenta que: > Cada clase de anlisis identificada en el paso anterior debera tener al menos un objeto que participase en un diagrama de colaboracin. > Los mensajes deberan reflejar el propsito del objeto invocante en la relacin con el invocado. > Los enlaces de diagrama deben ser instancias de asociaciones entre clases de anlisis. > El diagrama de colaboracin debera tratar todas las relaciones del caso de uso que se est realizando. En algunos casos es apropiado complementar el diagrama con descripciones textuales. Estas deberan recogerse en el artefacto flujo de sucesos- anlisis de la realizacin de caso de uso. -Captura de requisitos especiales Analizar una clase: Objetivos: > 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 realizaciones de la clase de anlisis. > Capturar requisitos especiales sobre la realizacin de la clase de anlisis. -Identificar responsabilidades: Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple. Una tcnica simple es extraer las responsabilidades de cada rol, uno tras otro, aadiendo responsabilidades adicionales o modificando las existentes basndonos en una realizacin de caso de uso tras otra. -Identificacin de atributos: Un atributo especifica una propiedad de una clase del anlisis. Tener en cuenta: > El nombre debe ser sustantivo. > El tipo debe ser conceptual. > Al decidir un tipo, deberamos reutilizar tipos ya existentes siempre que sea posible.

> Una instancia de atributo no puede compartirse por varios objetos de anlisis. Si se necesita hacer esto, el atributo debe definirse como clase. > Si una clase de anlisis se hace demasiado difcil de entender por sus atributos, estos pueden separarse en clases independientes. > Si una clase de entidad tiene traza con una clase de dominio o de entidad de negocio, los atributos de esas clases son una entrada til. > Los atributos de clase de interfaz que interactan con actores humanos suelen representar elementos de informacin manipulados con por los actores. > Los atributos de clase de interfaz que interactan con actores que representan sistemas suelen representar propiedades de interfaz de comunicacin. > Las clases de control pueden poseer atributos que representan valores acumulados o calculados. > Si la clase tiene muchos atributos o atributos complejos, podemos mostrarlos en un diagrama de clases aparte que solo muestre la seccin de atributos. -Identificacin de asociaciones y agregaciones: Deberamos minimizar el nmero de relaciones entre clases. No son las relaciones del mundo real lo que deberamos modelar como agregaciones o asociaciones, si no las relaciones que deben existir en respuesta a las demandas de realizaciones de caso de uso. Las agregaciones deberan utilizarse cuando los objetos representan: > Conceptos que se contienen fsicamente uno al otro. > Conceptos que estn compuestos el uno del otro. > Conceptos que forman parte de una coleccin conceptual de objetos. -Identificacin de generalizaciones: Las generalizaciones deberan utilizarse durante el anlisis para extraer comportamiento compartido y comn entre clases del anlisis. Las generalizaciones deberan mantenerse en un nivel alto y conceptual, y su objetivo debera ser hacerle modelo de anlisis ms fcil de comprender. Durante el diseo, una generalizacin podra desaparecer y convertirse en otra relacin, como una asociacin. -Captura de requisitos especiales: Recogeremos todos los requisitos de una clase anlisis que se han identificado. Debemos asegurarnos de estudiar los requisitos especiales de la realizacin de caso de uso, que pueden contener requisitos adicionales (no funcionales) sobre la clase anlisis. Analizar un paquete: Objetivos: > Garantizar que el paquete de anlisis es tan independiente de otros paquetes como sea posible. > Garantizar que el paquete de anlisis 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. Normas generales: > Definir y mantener las dependencias del paquete con otros paquetes cuyas clases contenidas estn asociadas a l. > Asegurarnos de que el paquete contiene las clases correctas. Intentar hacer cohesivo el paquete incluyendo solo objetos relacionados funcionalmente. > Limitar las dependencias con otros paquetes. Considerar la reubicacin de clases dependientes de otros paquetes.
Capitulo 13

PUDS - Fase de Inicio (I)

Etiquetas: Sis Administrativos III

Fase de Inicio El objetivo global de la fase de inicio es desarrollar el anlisis de negocio hasta el punto necesario para justificar la puesta en marcha del proyecto. Despus de ella se habr delimitado el problema que se quiere resolver y se habr visto con cierto grado de confianza que es a la vez posible y deseable desarrollar un sistema. Tenemos que Delimitar el alcance (mbito) para discernir qu es lo que debemos cubrir con el proyecto de desarrollo. Definir los lmites. Delimitar las estimaciones de coste, agenda y recuperacin de inversin. Asegurarnos de que existe una arquitectura que pueda soportar el mbito del sistema (arquitectura candidata). Mitigar riesgos. Antes de comenzar la fase Antes de empezar la fase de inicio, ya se tiene alguna nocin de lo que se va a hacer. Alguien tuvo una idea y la justific lo suficiente como para poner algo en marcha. Planificacin de la fase Reunir la informacin recogida antes de que el proyecto comenzase. Organizarla de forma que pueda ser utilizada. Reunir un grupo de gente que sepa cmo utilizarla. Descubrir lo que falta para completar los objetivos de la fase. Planificar lo necesario para cumplir esos objetivos Modificar el plan segn vaya recopilando ms informacin

PUDS - Fase de Inicio (II)

Ampliacin de la descripcin del sistema Esta descripcin contendr una serie de caractersticas, informacin acerca de rendimiento, conocimiento sobre los riesgos con que pueden encontrarse, alguna vaga referencia sobre una posible arquitectura y unas cifras redondas estimando los aspectos econmicos. Establecimiento de los Criterios de Evaluacin Criterios generales de evaluacin para los cuatro objetivos de la fase de inicio: Decidir el mbito del sistema: Est claro qu va a formar parte del sistema?, Se ha identificado a todos los actores?, Se ha expuesto la naturaleza general de las interfaces con estos actores?, Puede lo que est incluido en el mbito constituir por si mismo un sistema completo que funcione? Resolver Ambigedades en Requisitos: Se han identificado y detallado los requisitos funcionales y no funcionales de los pocos casos de uso necesarios para los objetivos de esta fase? Se han identificado y detallado los requisitos adicionales? Determinar arquitectura candidata: Satisface esta arquitectura las necesidades de los usuarios? Es verosmil que funcione? Mitigar riesgos Crticos: Se han identificado todos los riesgos crticos?, Se han mitigado los riesgos identificados o existe un plan para mitigarlos?

Flujo de trabajo La mayor parte del trabajo de la fase de inicio se lleva a cabo en el primer flujo de trabajo: el de

requisitos, seguido de algo de trabajo en los flujos de Anlisis y Diseo y muy poco en Implementacin y Pruebas. - Requisitos El analista de sistemas identifica los casos de uso y actores que definen el mbito del sistema. El arquitecto selecciona aquellos que son relevantes para la arquitectura candidata y prepara una descripcin inicial de dicha arquitectura. Los casos de uso que se describe detalladamente son aquellos relevantes para la comprensin del mbito del sistema y la arquitectura candidata y para entender los riesgos. Un resultado de esta tarea es el primer modelo de casos de uso. - Anlisis En el flujo de anlisis creamos un modelo de anlisis inicial para la mayora de los casos de uso y escenarios de casos de uso. Si el sistema es nuevo o novedoso, el equipo puede preparar de forma rpida un prototipo exploratorio para mostrar ideas clave. La iteracin puede acabar con la descripcin de la arquitectura candidata tan pronto como el jefe de proyecto determine que la arquitectura candidata se muestre capaz de funcionar y que el riesgo es menos que crtico o mitigable.

PUDS - Fase de Inicio (III)

Etiquetas: Sis Administrativos III Ajuste del proyecto al entorno de desarrollo El entorno de desarrollo consiste en un proceso, las herramientas para llevarlo a cabo y una serie de servicios para los proyectos. Incluye la configuracin y mejora del proceso, la seleccin y adquisicin de herramientas, los servicios tcnicos, formacin y asesora. La organizacin de proyecto gestiona su entorno de desarrollo en paralelo con el resto del trabajo a realizar en esta fase.

Ejecucin de los flujos de trabajo Requisitos Enumerar Actores y Casos de Uso: Hay que detallar solo aquellos casos de uso que afecten a los objetivos de la fase, normalmente son un 10% del total. El jefe de proyecto debe colaborar con el analista de sistemas y el arquitecto. Determinar la prioridad de los casos de uso: El arquitecto determinar la prioridad de cada caso de uso escogido. Detallar un caso de uso: Completar todas las alternativas pertinentes en los casos de uso que tengan que ver con la fase de inicio. Construir un prototipo de interfaz de usuario: No es de inters en esta fase. Estructurar el modelo de casos de uso: No es de inters en esta fase. Anlisis El objetivo general del flujo de trabajo es analizar los requisitos, refinarlos y estructurarlos en un modelo de objetos que sirva como primera impresin del modelo de diseo. Solo una parte muy pequea del modelo de anlisis se completa en la fase de inicio. Anlisis de Arquitectura: Clasificar los casos de uso o escenarios que necesitamos analizar para el propsito de esta fase. Analizar un caso de uso: Algunos casos de uso comparten recursos en el sistema. El modelo de anlisis revela esos recursos compartidos. Necesitamos realizar el anlisis hasta el punto de resolver

esos conflictos. Se puede analizar y refinar algunos casos de uso (10%) y detallar la mitad de ellos (5%) Analizar una clase y un paquete: Si se realiza, es mnimamente. Diseo El objetivo principal es esbozar un modelo de diseo de la arquitectura candidata. Si necesitamos desarrollar un prototipo de demostracin, lo haremos utilizando cualquier tcnica de desarrollo rpido que simplemente muestre la idea. Mostraremos este prototipo a usuarios representativos, para asegurarnos que satisface sus necesidades. Diseo de la arquitectura: La intencin es desarrollar un esbozo inicial. Debemos ser perspicaces al identificar interfaces entre los subsistemas o clases, incluso si se trata simplemente de un esbozo del diseo, por que forman el ncleo de la arquitectura. El modelo de diseo lleva a cabo no solo los requisitos funcionales representados por casos de uso designados, sino tambin los requisitos no funcionales que puedan ser un riesgo. Disear un caso de uso: Mnimo. Disear una clase y Disear un Subsistema: Si se realiza, es mnimamente. Pruebas No se realiza un trabajo significativo de pruebas durante la fase de inicio, ya que el prototipo exploratorio de demostracin tiene, por lo general, carcter ilustrativo.

PUDS - Fase de Inicio (IV)

Etiquetas: Sis Administrativos III

Anlisis Inicial Del Negocio

Al final de la fase de inicio, se traduce el sistema a trminos econmicos. Esbozar la Apuesta Econmica La cantidad de horas-persona necesarias para disear, implementar y probar un caso de uso depende de: Estilo: Si los encargados de desarrollo incluyen ms caractersticas, costar ms horas persona. Complejidad del sistema: Cuanto ms complejo sea, ms costoso resultar para un tamao dado. Tamao del sistema: Un caso de uso de un sistema pequeo es ms fcil de implementar que el de un sistema grande. Tipo de aplicacin: Algunos sistemas de tiempo real sobre entornos distribuidos tienen un significativo impacto sobre el coste por caso de uso. Este anlisis inicial del negocio solo debe ser lo bastante preciso como para justificar entrar en la fase de elaboracin. Estimar la recuperacin de la inversin No existe una frmula clara para calcular las ganancias que proporcionar un software. Los expertos en ventas considerarn para el clculo el nmero de unidades vendidas, el precio al que se vender el producto y el perodo que se extendern las ventas. En caso de ser un software de uso interno, deber solicitar a los departamentos afectados que calculen el ahorro que esperan conseguir. --

Evaluacin de la iteracin o iteraciones

Al llegar la fase de inicio a su fin, el jefe de proyecto designa un nmero de personas para evaluarla.

Normalmente se incluye a representantes del cliente o usuarios. Algunos de los criterios pueden mostrarse como no alcanzables: Ampliacin del modelo de casos de uso hasta el nivel necesario Desarrollo de un prototipo exploratorio hasta el punto de demostracin Identificacin de riesgos crticos: Sospecha de que no se los ha encontrado todos. Mitigacin de riesgos crticos: no todos han sido mitigados o cubiertos por un plan de emergencia. El jefe de proyecto traslada los criterios an no satisfechos a posteriores iteraciones y modifica los planes y agendas. Un resultado crucial de la evaluacin de la fase de inicio es la decisin de seguir adelante con el proyecto o abandonarlo. Se debera abandonar tan pronto como se conozcan hechos que justifiquen hacerlo, sin embargo esta decisin requiere la conformidad de las personas involucradas, en particular de los inversores y usuarios. Planificacin de la Fase de Elaboracin Hacia el fin de la fase de inicio, a medida que vamos siendo conscientes de los costes y agenda de la fase de elaboracin, comenzamos a planificarla. En ella, intentaremos identificar alrededor del 80% de los requisitos. De ese 80% seleccionaremos la parte significativa del conjunto total, sobre la que basar el diseo de la lnea base de la arquitectura. De esa forma encaminaremos nuestros pasos hacia las iteraciones necesarias en la fase de elaboracin. Podemos asumir una iteracin, pero puede haber ms en casos complejos. Decidiremos lo que es conveniente hacer en cada iteracin, que requisitos implementar y probar y, de ese modo, que riesgos mitigar. Productos de la fase de inicio Lista de caractersticas Primera versin del modelo de negocio (o de dominio) que describe el contexto del sistema. Un esbozo del modelo de casos de uso, del modelo de anlisis y del modelo de diseo. Primera versin de los requisitos adicionales. Primer esquema de la descripcin de la arquitectura candidata. Prototipo exploratorio (si se requiere) Lista inicial de riesgos y clasificacin de casos de uso Rudimentos del plan de proyecto, incluyendo plan general de fases Primer borrador del anlisis de negocio, con contexto de negocio y criterios de xito.
Capitulo 14

Fase de Elaboracin (I)

Etiquetas: Sis Administrativos III (Reitero: todo lo que subo referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh.) Al entrar en fase de elaboracin ya hemos: - Formulado la arquitectura inicial - Identificado los riesgos ms serios - Realizado el anlisis de negocio

Los objetivos de esta fase son: - Recopilar requisitos que an queden pendientes - Establecer la lnea base de la arquitectura - Continuar la observacin y control de los riesgos crticos que an queden - Completar los detalles del plan del proyecto

Para lograr habr que adoptar un punto de vista general del sistema. Formular la lnea base de la arquitectura implica desarrollar alrededor del 80% de los casos de uso y abordar riesgos que interfieran en la consecucin de ese objetivo. La planificacin de la fase de elaboracin, realizada al terminar la fase de inicio, puede no estar completa. En algunos casos hay un lapso de tiempo entre ambas. Como no todo lo descubierto durante la fase anterior queda registrado, el jefe de proyecto deber mantener en la fase de elaboracin tantos miembros de equipo como sea necesario. El equipo de elaboracin es por lo general algo ms grande. Durante la elaboracin, como el equipo es an pequeo, hay oportunidad de iterar y de ensayar soluciones alternativas. Una nica iteracin puede ser suficiente si el sistema es pequeo y sencillo, pero puede tratarse solo del primer paso si el sistema es grande y complejo. Las iteraciones continan hasta que la arquitectura alcance un nivel estable. No resulta prctico trabajar en esta fase sin herramientas.

Fase de Elaboracin (II)

Etiquetas: Sis Administrativos III
(Reitero: todo lo que subo referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh.)

Flujo de trabajo Requisitos: -Encontrar casos de uso y actores faltantes y establecer su prioridad -Describir entre el 40% y el 80% de los casos de uso. -Desarrollar prototipos de las interfaces de usuario que sean relevantes para la arquitectura -Detallar los casos de uso arquitectnicamente significativos

-Estructurar el modelo de casos de uso: El analista revisa el trabajo y busca similitudes, simplificaciones y oportunidades de mejorar la estructura del modelo de casos de uso Anlisis: -Analizar la arquitectura: el arquitecto trabajar sobre modelo de casos de uso, requisitos relacionados, glosario y modelo de negocio. Emplear una arquitectura de capas, identificando los paquetes especficos de aplicacin y los paquetes generales. Adems, al trabajar con las necesidades colectivas de los casos de uso, el arquitecto identificar los mecanismos genricos del anlisis que se necesiten (colaboraciones genricas, como recuperacin de errores, paquetes genricos, como interfaces de usuario, etc) -Analizar casos de uso: Muchos casos de uso no son claramente comprensibles tal y como estn descriptos y deben ser refinados en funcin de clases de anlisis. Los casos de uso que no son interesantes desde la perspectiva de la arquitectura o de la comprensin de los requisitos no se refinan ni analizan, los ingenieros de casos de uso sabrn tratar con ellos cuando sea hora de implementarlos. -Analizar clases y paquetes: Los ingenieros de componentes debern refinar las clases identificadas en pasos anteriores. El arquitecto meditar sobre los servicios del sistema y el agrupamiento de clases en servicios. Diseo: -Diseo de la arquitectura: El arquitecto identificar la arquitectura en capas, los subsistemas y sus interfaces. Seleccionar los productos que va a utilizar y los mecanismos de diseo (lenguajes de programacin, sistemas de base de datos, etc). Tratar de convertir cada subsistema de anlisis en uno de diseo, traducir las clases del anlisis significativas para la arquitectura a clases de diseo y las describir en la descripcin de la arquitectura. -Disear casos de uso, clases y subsistemas: En esta fase, se disea los casos de uso arquitectnicamente significativos (menos del 10%). Implementacin: -Implementacin de la arquitectura: Se identifican los componentes necesarios para implementar los subsistemas de servicio. Los componentes ejecutables se asignan a nodos de la red en la que van a ejecutarse. El arquitecto ilustrar esto en la vista de arquitectura de implementacin. -Implementacin de clases y subsistemas: Los ingenieros de componentes implementan las clases significativas en trminos de componentes para crear una versin ejecutable preliminar del sistema. -Integrar el sistema: Sobre la base del pequeo porcentaje de casos de uso que se va a implementar, el responsable de integrar el sistema establece la secuencia de integracin en un plan de integracin y a continuacin integra los subsistemas y los componentes en una lnea base de la arquitectura ejecutable. Pruebas: -Planificar las pruebas: El ingeniero de pruebas seleccionar los objetivos que evaluarn la lnea base de la arquitectura para asegurarse de que todos los subsistemas de todos los niveles y capas funcionen. -Disear las pruebas: El ingeniero de pruebas identificar los casos de prueba necesarios.

-Realizar pruebas de integracin: Los encargados comprobarn cada construccin. -Realizar pruebas de sistema: El ingeniero de pruebas notificar los defectos a los ingenieros de componentes o al arquitecto para su correccin.

Fase de Elaboracin (III)

Etiquetas: Sis Administrativos III
(Reitero: todo lo que subo referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh.)

Apuesta Econmica Se supone que el equipo de desarrollo desarrollar la fase de construccin desde una perspectiva de negocio. Las estimaciones de software se basan a menudo en le tamao del proyecto y la productividad de la organizacin de desarrollo. La productividad depende de la experiencia en proyectos anteriores, pero el tamao estimado se basa en lo que se ha aprendido en la fase de elaboracin. Productos clave -Modelo completo de negocio (o de dominio) -Nueva versin de todos los modelos -Lnea base de la arquitectura -Descripcin de la arquitectura -Lista de riesgos actualizada -Plan de proyecto de las fases de construccin y Transicin -Manual de usuario preliminar (opcional) -Anlisis de negocio completo
Capitulo 15

Fase de Construccin (I)

Etiquetas: Sis Administrativos III
(Reitero: todo lo que subo referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh.)

El propsito primordial de esta fase es dejar listo un producto software en su versin operativa inicial, a veces llamada versin beta. El producto debera tener la calidad adecuada para su aplicacin y asegurarse de cumplir los requisitos.

El equipo que trabaja en la fase de construccin detalla los casos de uso y escenarios faltantes, modifica si es necesario la descripcin de la arquitectura, y contina los flujos de trabajo a travs de iteraciones adicionales. Adems, integra los subsistemas y los prueba, e integra todo el sistema y lo prueba. La fase de construccin es anloga al desarrollo. El jefe de proyecto, el arquitecto y los desarrolladores mantendrn actualizada la lista de riesgos. Su objetivo es acabar esta fase con todos los riesgos mitigados. El arquitecto vigila que la construccin se ajuste a la arquitectura y modifica dicha arquitectura para incorporar los cambios que surjan. Al comienzo de la fase hay dos posibilidades: La primera es que los responsables financieros autoricen inmediatamente la fase, habilitando al equipo a continuar sin interrupcin, o que se de esa autorizacin tras un lapso de meses. En el peor caso, la responsabilidad cae sobre un equipo mayoritariamente nuevo. La segunda es que los fondos y la agenda otorgados sean menores de lo planificado para el proyecto. El mbito del sistema puede haberse visto reducido para ajustarse a los fondos y la agenda o no. El jefe de proyecto tendr que rehacer en cierta medida la planificacin. En casi todos los casos, tendr que adaptar el plan de proyecto de la fase de elaboracin para ajustarse a los recursos de personal disponibles y a la agenda que han fijado los inversores. Cada subsistema se convierte en responsabilidad de un desarrollador, que actuar como ingeniero de componentes. Normalmente, el desarrollador responsable de un subsistema es tambin responsable de las clases de dicho subsistema. No es habitual que un desarrollador sea responsable de una sola clase. Esta fase requiere aproximadamente el doble de trabajadores que la de elaboracin. El arquitecto debe continuar disponible, aunque el tiempo que dedica a esta fase es, por lo general, menor. El analista de sistemas y el encargado de especificar casos de uso continan su trabajo; Quedan por recopilar alrededor del 20% de los requisitos. Los ingenieros de pruebas debern estar presentes para ofrecer asistencia tcnica, sin embargo, los ingenieros de componentes y sus colaboradores, el encargado de pruebas de integracin y el encargado de pruebas de sistema, son los responsables de probar las construcciones. Los requisitos y la arquitectura son estables. El nfasis se pone en completar las realizaciones de casos de uso, disear los subsistemas y clases necesarios, implementarlos como componentes y probarlos tanto de forma individual como en construcciones. Construir el software en varias iteraciones pequeas lo har ms manejable.

Fase de Construccin (II)

Etiquetas: Sis Administrativos III

(Reitero: todo lo que subo referente a 'proceso unificado de desarrollo de software' (PUDS) lo he recolectado y resumido de distintos captulos del libro del mismo nombre, escrito por Ivar Jacobson, Grady Booch y James Rumbaugh.)

Flujo de Trabajo Requisitos: -Desarrollar un prototipo de interfaz de usuario: Para algunos sistemas es difcil comprender la interfaz de usuario sin tener un prototipo, as que construiremos uno o varios y haremos que los usuarios los prueben. Basndonos en sus respuestas, amoldaremos el prototipo hasta que satisfaga las necesidades. Para sistemas en los cuales se espere un gran nmero de ventas, se construir un prototipo aunque la interfaz no sea muy compleja. -Detallar todos los casos y escenarios de caso de uso de uso que queden -Estructurar el modelo de casos de uso: Esta fase ya tiene una arquitectura estable, cualquier cambio debe referirse preferiblemente a casos de uso que an no han sido desarrollados. Cada caso de uso modificado implica la correspondiente realizacin de caso de uso en los modelos de anlisis y diseo. Anlisis: -Analizar casos de uso y clases faltantes Diseo: -Diseo de la arquitectura: El arquitecto puede aadir subsistemas si son similares, puede que alternativos, a los que ya estn en la arquitectura. -Disear el 90% restante de los casos de uso Implementacin: -Implementacin de la arquitectura: La arquitectura est firmemente asentada. El papel del arquitecto ser solo el de actualizarla si es necesario. -Implementar clases y subsistemas -Realizar pruebas de unidad -Integrar el sistema: El responsable de la integracin crear un plan de integracin de construcciones. Reunir clases completas y stubs en una construccin ejecutable. Har construcciones cada vez mayores mientras los encargados de pruebas de integracin y regresin las comprueban. En el paso final de cada iteracin y de la propia fase, el responsable de integracin conectar el sistema en su conjunto y los responsables de pruebas y regresin lo probarn. Pruebas: -Planificar las pruebas: Seleccionar objetivos -Disear las pruebas: determinar como probar los requisitos en el conjunto de construcciones.

-Realizar pruebas de integracin: Si la construccin supera las pruebas, el responsable de integracin aadir ms subsistemas. Si detectan fallos, los encargados de pruebas los registrarn y notificarn al jefe de proyecto. -Realizar pruebas de sistema: El encargado de pruebas de sistema ejecutar los casos de prueba de sistema, si estas comprobaciones detectan fallos el encargado de pruebas de sistema los registrar y notificar al jefe de proyecto. Al final de la ltima iteracin de la fase, comprobar la versin operativa inicial. -Evaluar las pruebas: Si una prueba no alcanza sus objetivos, los casos y procedimientos de prueba debern ser modificados. Control del anlisis de negocio El jefe de proyecto comparar el progreso real al final de cada iteracin con la agenda, esfuerzo y costes planificados. Revisar los datos de productividad del proyecto, cantidad de cdigo desarrollado y otras mtricas. Si hay discrepancias no muy pequeas, el jefe de proyecto deber tomar medidas. Si las discrepancias son grandes, deber realizar una reunin de revisin con los inversores. A medida que el jefe de proyecto adquiere un mayor conocimiento sobre los costes y capacidades del producto durante la fase de construccin, puede encontrar necesario actualizar el anlisis de negocio y comunicar el nuevo anlisis a los inversores. Planificacin de la fase de Transicin El equipo de proyecto no puede esperar planificar de antemano la fase de transicin con tanto detalle como hizo para las fases anteriores. Sus miembros saben que van a producir versiones beta para que las evalen usuarios seleccionados. La respuesta recibida difcilmente puede predecirse. Productos clave - Plan de proyecto para la fase de transicin - Sistema Software Ejecutable - Todos los artefactos, incluyendo modelos de sistema - Descripcin de la arquitectura - Versin preliminar de manual de usuario - Anlisis de negocio