Upload
gustavo-agostini
View
11
Download
1
Embed Size (px)
DESCRIPTION
DISEÑO Y MODELADO DE SISTEMAS BASADOS EN EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE, UTILIZANDO MICROSOFT VISIO 2003 FOR ENTERPRISE ARCHITECTS PARA LA ELABORACIÓN DE DIAGRAMAS UML
Citation preview
MANUAL DE PROCEDIMIENTOS
DISEÑO Y MODELADO DE SISTEMAS BASADOS EN EL PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE, UTILIZANDO MICROSOFT VISIO 2003 FOR ENTERPRISE
ARCHITECTS PARA LA ELABORACIÓN DE DIAGRAMAS UML
Gustavo Federico Agostini
_________ OCTUBRE 2005
Tabla de Contenidos Introducción ................................................................................................................................. 5
CAPÍTULO I .................................................................................................................................. 6
Marco Teórico - Introducción .................................................................................................... 6
CAPÍTULO II ................................................................................................................................. 8
Marco Teórico - Desarrollo ....................................................................................................... 8
El Proceso Unificado ............................................................................................................ 8
Introducción ...................................................................................................................... 8
Aspectos dinámicos ....................................................................................................... 11
Inception ..................................................................................................................... 11
Elaboration ................................................................................................................. 13
Construction ............................................................................................................... 15
Transition ................................................................................................................... 16
Aspectos Estáticos ......................................................................................................... 17
Roles .......................................................................................................................... 18
Activities ..................................................................................................................... 19
Artifacts ...................................................................................................................... 20
Workflows ................................................................................................................... 21
Disciplines .................................................................................................................. 22
Elementos secundarios .............................................................................................. 22
Resumiendo ................................................................................................................... 22
Lenguaje Unificado de Modelado UML .............................................................................. 25
Introducción .................................................................................................................... 25
Diagrama de actividades ................................................................................................ 26
Diagrama de clases ........................................................................................................ 27
Diagrama de distribución ................................................................................................ 31
Diagrama de paquetes funcionales ................................................................................ 32
Diagramas de caso de uso ............................................................................................. 32
Diagrama de componentes ............................................................................................ 34
Diagrama de secuencia .................................................................................................. 34
Diagrama de estados ..................................................................................................... 36
Diagrama de colaboraciones.......................................................................................... 37
Diagrama de objetos ..................................................................................................... 38
Microsoft Visio 2003 for Enterprise Architects .................................................................... 39
Diagramas UML en Microsoft Visio ................................................................................ 39
CAPÍTULO III .............................................................................................................................. 43
Procedimientos de desarrollo ................................................................................................. 43
Captura de los requisitos funcionales del sistema ............................................................. 43
Diagrama de actividades .................................................................................................... 43
Primeros casos de uso ....................................................................................................... 44
Diagrama de clases preliminar ........................................................................................... 44
Plataforma Preliminar ......................................................................................................... 45
Descripción de paquetes de funcionalidad ......................................................................... 45
Diagrama de casos de uso ................................................................................................. 45
Diagramas de secuencias .................................................................................................. 46
Diagramas de distribución y de componentes ................................................................... 46
Diagramas adicionales ....................................................................................................... 46
Anexo I ........................................................................................................................................ 47
Especificación de requisitos .................................................................................................... 47
Estructura Básica ................................................................................................................ 47
Desarrollo resumido ............................................................................................................ 47
Análisis de Requisitos del Sistema ................................................................................ 47
1. Identificación de los usuarios participantes ................................................................ 47
2. Planificación y Realización de Entrevistas. Estudio de Documentación. .................. 48
3. Catálogo de Requisitos del Sistema .......................................................................... 48
3.1. Objetivos y alcance del sistema.......................................................................... 49
3.2. Definiciones, acrónimos y abreviaturas .............................................................. 49
3.3. Descripción general ............................................................................................ 49
3.4. Requisitos funcionales ........................................................................................ 49
3.5. Requisitos de usuario y tecnológicos ................................................................. 49
3.6. Requisitos de interfaces externas ....................................................................... 50
3.7. Requisitos de rendimiento .................................................................................. 50
3.8. Requisitos de desarrollo y restricciones de diseño ............................................ 50
Bibliografía ................................................................................................................................. 51
Capítulo I: Introducción
5
Introducción
Capítulo I: introduce un marco teórico, donde se deja en evidencia la necesidad de la implementación de una metodología de desarrollo, y la necesidad de utilizar UML para plasmar el diseño del sistema.
Capítulo II: trata sobre el Proceso Unificado de Desarrollo de Software, sus fases y principales características, da una descripción de los diversos diagramas utilizados en UML, así como los elementos utilizados en cada uno y muestra un pantallazo sobre Microsoft Visio 2003 for Enterprise Architects.
Capítulo III: da los pasos detallados para la construcción de un sistema de software reuniendo todos los capítulos anteriores.
Capítulo I: Marco Teórico – Introducción
6
CAPÍTULO I
Marco Teórico - Introducción
Un sistema de software surge como solución a la necesidad de alguien que desea manejar algún aspecto de la realidad mediante algún elemento de tecnología. Es aquí donde esta la gran complejidad del desarrollo de software. Plasmar la realidad, por lo general tangible, en algo totalmente intangible. Durante muchos años surgieron muchas técnicas y métodos de programación para ayudar a los desarrolladores a poder modelar mejor la realidad a través del software. Sin duda alguna, el mayor avance lo propició la Orientación a Objetos (OO).
La tendencia actual en el software lleva a la construcción de sistemas más grandes y más complejos. Esto es debido en parte al hecho de que los computadores son más potentes cada año, y los usuarios, por tanto , esperan más de ellos. Queremos un software que este mejor adaptado a nuestras necesidades, pero esto, a su vez, simplemente hace el software más complejo. También lo queremos más rápido. El tiempo de salida al mercado es otro conductor importante [EPUDS00].
Un proyecto de software no solo involucra la complejidad de programar en un lenguaje determinado, sino además debe captar los requisitos que debe cumplir el sistema, adaptarse a las tecnologías actuales, proporcionar herramientas para evolucionar. Generalmente, el desarrollo no esta en manos de una sola persona, por lo que un proyecto de software, además, debe contar con medios para poder comunicar claramente los objetivos y el diseño de software entre los distintos miembros del equipo de desarrollo.
Para manejar de forma ordenada toda esta complejidad involucrada en el desarrollo de un software, es necesario seguir una metodología clara, una guía que diga que hacer, cuando y como. La metodología elegida por el Departamento de Sistemas fue el “Proceso Unificado”, el cual es el resultado de años de experiencia y evolución de distintas metodologías (Figura 1).
Como puede evidenciarse en la Figura 1, UML fue desarrollado en forma paralela al Proceso Unificado. UML es el Lenguaje Unificado de Modelado (Unified Modeling Language). UML es un leguaje visual de propósitos generales usado para especificar, visualizar, construir y documentar los distintos elementos involucrados en un sistema de software. Puede ser usado con cualquier metodología de desarrollo. Tiene cuatro partes que describen aspectos estáticos, dinámicos, de ambiente y organizacionales.
Capítulo I: Marco Teórico – Introducción
7
Figura 1 – Breve historia del Proceso Unificado y de UML
¿Por qué es necesario UML? Simplemente porque no existe un estándar actual en lo que a documentación de sistemas refiere. UML fue adoptado como estándar de hecho (de facto) por la comunidad de desarrolladores de software y tiene el respaldo completo del Grupo de Administración de Objetos (Object Management Group, OMG). De esta forma un sistema puede fácil y claramente ser trasladado de un grupo de desarrollo a otro, sin que se pierdan detalles de diseño, ya que se usa un lenguaje común entre todos.
Capítulo II: Marco Teórico – Desarrollo
8
CAPÍTULO II
Marco Teórico - Desarrollo
El Proceso Unificado
Introducción
El proceso de desarrollo de software tiene 4 roles principales:
1.- Organizar las actividades a ejecutarse por el equipo de desarrolladores. 2.- Especificar que elementos deben ser desarrollados y en que tiempo. 3.- Dirigir las tareas de cada desarrollador así como del equipo completo. 4.- Ofrecer criterios de monitorización y medición del desarrollo.
Existen básicamente dos tipos de ciclos de vida de software:
en cascada (waterfall) o secuencial
iterativo
El principal objetivo de un desarrollo de software como ya vimos es captar con la mayor precisión posible las necesidades o los requisitos de los clientes. El ciclo de vida en cascada, parte de creer que los requisitos pueden ser congelados en el tiempo, es decir, que los clientes no cambian sus necesidades a medida que avanza el proyecto. En la mayoría de los proyectos chicos de software esto es así, pero en general, los requisitos cambian y mucho. Realizar rectificaciones en un proyecto con ciclo de vida en cascada es muy caro, porque estas se realizan cuando el software ya ha sido implementado.
Es por ello que surge el ciclo de vida iterativo. La idea es ir
aproximándose gradualmente al software final mediante varios ciclos o iteraciones. Estas iteraciones no son mas que pequeños ciclos en cascada que se ejecutan uno detrás de otro, lo que permite captar el dinamismo de los requisitos del cliente, y satisfacer así con mayor precisión a sus necesidades. También permite corregir errores desde el principio, lo que es más eficiente y menos costoso. Las tareas se pueden realizar en paralelo, ya que cada área del equipo (planificación, diseño, implementación, etc.) puede ir trabajando con mayor anticipación.
La figura 2 muestra un diagrama de un ciclo de vida iterativo, mientras
que la figura 3 muestra la relación entre un ciclo de vida en cascada y uno iterativo.
Capítulo II: Marco Teórico – Desarrollo
9
Figura 2. Ciclo de Vida Iterativo
Podemos mencionar algunas de las ventajas de usar un ciclo de vida iterativo:
Enfrenta anticipadamente los problemas de alto riesgo (técnicos, de requisitos, de objetivos, etc.)
Progreso visible rápidamente
Realimentación temprana con los distintos participantes del proyecto (stakeholders).
Maneja muy bien la complejidad, el equipo de desarrollo no se ve aplastado por la espera de una etapa muy larga de planificación o de pasos muy largos y complejos.
Se aprende a medida que se desarrolla, lo que permite usar estos conocimientos para ir mejorando de iteración en iteración.
Capítulo II: Marco Teórico – Desarrollo
10
Figura 3. Relación entre un ciclo de vida en cascada y uno iterativo
El Proceso Unificado (UP) o el Proceso Racional Unificado (RUP) es un proceso de ingeniería de software, que provee una asignación disciplinada de tareas y responsabilidades, garantizando la creación de un software de alta calidad, que cubra con todas las expectativas del cliente, acotando tiempo y presupuesto.
Sus principales características son:
ciclo de vida iterativo y evolutivo
administración de requisitos dinámicos
Uso de componentes
Uso de una arquitectura para el desarrollo de software
Modelado visual utilizando UML
Administración de cambios
Desarrollo guiado por casos de usos
RUP se divide en dos dimensiones o dos aspectos:
o Aspectos estáticos: aquellos que no dependen del tiempo como ser los roles, responsabilidades, tareas, etc.
o Aspectos dinámicos: aquellos que dependen del tiempo.
Capítulo II: Marco Teórico – Desarrollo
11
Aspectos dinámicos
RUP se divide en 4 etapas o fases del desarrollo:
1- Inception 2- Elaboration 3- Construction 4- Transition
En cada una de estas etapas se realizan las iteraciones. La figura 4
muestra un diagrama representativo.
Figura 4. Ciclo de desarrollo en RUP
Cada fase o etapa viene seguida de una pequeña etapa de evaluación y decisión (milestone) en donde se evalúa la factibilidad del proyecto de acuerdo a su desarrollo, a la cobertura de las necesidades del cliente, a sus objetivos, etc., y se decide si se sigue adelante con el proyecto o se lo descarta. Ahora explicaremos brevemente cada una de estas fases.
Inception
Aquí se establece la idea, especificando una visión del producto final y su plan de negocio y se define el ámbito del proyecto. Esta fase concluye con el milestone llamado: “Evaluación de los objetivos del ciclo de vida” (LCO).
Capítulo II: Marco Teórico – Desarrollo
12
Los objetivos principales de la fase de inicio incluyen:
Establecer el ámbito y los limites del proyecto de software incluyendo un concepto operacional, criterios de aceptación y una descripción de lo que pretende ser y no ser parte del producto
Discriminar o discernir los principales y más críticos casos de uso, esto es, los principales comportamientos que llevaran a cabo las funcionalidades del software y que darán forma a la mayor parte de sistema.
Exhibir o demostrar al menos una arquitectura para algunos de los escenarios principales.
Estimar la agenda a seguir, y los costos a afrontar a lo largo de todo el proyecto, como así también proveer de estimaciones detalladas para la fase que sigue, la fase de elaboración.
Estimar los posibles riesgos, manifestando las posibles fuentes. Las principales actividades de esta fase son:
Definir el ámbito del proyecto, es decir, capturar el contexto y los requisitos y las restricciones fundamentales para poder generar criterios de aceptación del producto final.
Preparar y planificar un caso de negocio y evaluar las alternativas para el manejo de los posibles riesgos, del staff, del plan de proyecto y de las actividades teniendo en cuenta el costo, tiempo y rentabilidad.
Sintetizar una arquitectura candidata, evaluando las actividades de diseño, analizando la compra/desarrollo/reutilización de componentes a fin de estimar a ciencia cierta los costos, los tiempos y los recursos a invertir.
Los resultados de esta fase concluyen en la creación de los siguientes elementos:
Un documento que enfatice la visión, es decir, una panorámica general de los requisitos fundamentales del proyecto, sus aspectos claves y las principales restricciones.
Un estudio de los casos de uso, que liste todos los casos de usos y sus actores que puedan ser identificados en esta etapa temprana.
Un glosario inicial del proyecto.
Un plan de negocio inicial que incluya: o El contexto del negocio o Criterios de éxito (proyección del rédito, reconocimiento del
mercado, etc.). o Pronostico financiero
Una evaluación inicial de los riesgos
Un plan de proyecto que muestre las fases y las iteraciones.
Capítulo II: Marco Teórico – Desarrollo
13
Un modelo inicial de casos de uso (completo en un 10% a 20%).
Un modelo de dominio, que es más sofisticado que un glosario.
Un modelo de negocio si fuese necesario.
Una descripción preliminar de los casos de desarrollo que especifique los procesos usados.
Milestone LCO: Los criterios de evaluación de la fase inicial son:
Los distintos involucrados en el proyecto concuerdan en la definición del ámbito, y la estimación de los costos y de la agenda a utilizar.
El entendimiento de los requisitos evidenciados por la fidelidad de los principales casos de uso.
Credibilidad de las estimaciones de los costos y tiempos, prioridades, riesgos y procesos de desarrollo.
Profundidad y ancho de cualquier prototipo de arquitectura que fuese desarrollado.
Gastos actuales vs. gastos planificados.
Si el proyecto no pasa esta etapa de prueba puede ser cancelado o repensado considerablemente.
Elaboration
En esta etapa se planifican las actividades necesarias y los recursos requeridos, se especifican las características y el diseño de la arquitectura. Esta fase culmina en una etapa de evaluación llamada: “Arquitectura del ciclo de vida” (LCA). Los principales objetivos de esta fase son:
Definir, validar y referenciar la arquitectura en forma práctica y rápida.
Referenciar (crear una referencia de) la visión.
Referenciar un plan de alta fidelidad para la fase de construcción.
Demostrar que la arquitectura soportara la visión por un costo razonable en un tiempo razonable.
Las principales actividades son:
Se elabora la visión, esto es, se establecen conocimientos sólidos y completamente articulados de la mayoría de los casos de uso críticos que derivan en la arquitectura y las decisiones sobre planificación.
Se elaboran los procesos, la infraestructura y el ambiente de desarrollo y se cuadran los procesos, las herramientas y el soporte de automatización.
Capítulo II: Marco Teórico – Desarrollo
14
La arquitectura es elaborada y los componentes seleccionados. Se evalúan los componentes potenciales y las decisiones de hacer/comprar/reusar son lo suficientemente entendidas como para determinar los costos de la fase de construcción y la agenda a utilizar. Los componentes seleccionados de la arquitectura son integrados y evaluados contra los escenarios primarios. Las lecciones aprendidas de estas actividades pueden lar lugar al rediseño de la arquitectura, tomando en consideración diseños alternativos o reconsiderando los requisitos.
Los resultados de esta fase concluyen en la creación de los siguientes elementos:
Modelo de casos de usos (al menos completo en un 80%) en el cual se hayan identificado todos los casos de uso, todos los actores y la mayoría de la descripción de esos casos de uso haya sido desarrollada.
Requisitos suplementarios que capturen las necesidades no funcionales y cualquier requisito que no este asociado con ningún caso de uso.
Una descripción de la arquitectura del software.
Un prototipo ejecutable de la arquitectura.
Una lista revisada de los riesgos y una revisión del plan de negocios.
Un plan de desarrollo para todo el proyecto, incluyendo un plan granular que muestre las iteraciones y los criterios de evaluación para cada iteración.
Un caso de desarrollo actualizado que especifique el proceso a usar.
Un manual preliminar para el usuario (opcional) Milestone LCA: Esta etapa de evaluación requiere las respuestas a las siguientes preguntas:
La visión del producto, ¿es estable?
La arquitectura, ¿es estable?
¿La demostración ejecutable muestra que la mayoría de los riesgos han sido atendidos y creíblemente resueltos?
La fase de construcción ¿es lo suficientemente detallada y exacta? ¿Es respaldada por estimaciones fundamentadas?
¿Todos los involucrados en el proyecto están de acuerdo en que la visión del producto puede ser alcanzada cuando se ponga en marcha el desarrollo del sistema completo, utilizando la arquitectura actual?
¿Los gastos actuales son aceptables en relación con los gastos propuestos?
Capítulo II: Marco Teórico – Desarrollo
15
Si esta evaluación falla el proyecto puede ser abortado o considerablemente repensado.
Construction
En esta etapa se construye el producto en si, desarrollando la visión, la arquitectura y los planes hasta que el producto esta listo para ser entregado a la comunidad de usuarios. La fase de construcción concluye con la etapa de evaluación denominada: “Capacidad Inicial de Operación” (IOC). Los principales objetivos son:
Minimizar los costos de desarrollo optimizando los recursos y evitando el trabajo innecesario.
Alcanzar una alta calidad tan rápido como sea posible.
Obtener versiones útiles (versiones alpha, beta, etc.) tan rápido como sea posible.
Las principales actividades desarrolladas en esta etapa son:
Administración y control de recursos y optimización de procesos.
Desarrollo y test completo de los componentes, evaluándolos con los criterios antes definidos.
Evaluación del producto completo comparándolo con los criterios de aceptación definidos por la visión.
Los resultados de esta fase concluyen en la creación de los siguientes elementos:
El producto de software integrado en una plataforma adecuada.
Los manuales para el usuario.
Una descripción completa de la última versión conseguida. Milestone IOC: Esta etapa de evaluación requiere las respuestas a las siguientes preguntas:
¿El producto final es lo suficientemente estable y maduro como para ser instalado e introducido en la comunidad de usuarios?
Todos los involucrados con el producto en la comunidad de usuarios ¿están listos para la transición?
Los gastos actuales ¿siguen siendo aceptables con relación a los gastos propuestos?
Capítulo II: Marco Teórico – Desarrollo
16
Si esta evaluación no es satisfactoria, la instalación e introducción del producto en la comunidad de usuarios podrá ser retrasada hasta una revisión del producto.
Transition
En esta etapa el producto es entregado a los usuarios, lo cual incluye instalación, entrenamiento, soporte y mantenimiento del producto hasta que los usuarios estén satisfechos. Esta fase termina en la etapa de evaluación denominada: “Versión de Producto” (PR), la que también concluye el ciclo de desarrollo. Esta etapa incluye:
Tests betas para comparar el rendimiento y desenvolvimiento del producto con las expectativas del usuario.
Operación en forma paralela entre el nuevo sistema desarrollado y el anterior al cual se lo esta reemplazando.
Conversión de las bases de datos operacionales.
Capacitación de usuarios y responsables de mantenimiento.
Entrega del producto a los equipos de marketing, distribución y venta. Los principales objetivos son:
Lograr que el usuario puede ser un auto-soporte.
Lograr reunir el consenso de todos los involucrados con el producto en que el mismo esta completo y es consistente con los criterios de evaluación propuestos por la visión.
Lograr terminar con el ciclo lo antes posible para un manejo de costos efectivo.
Las principales actividades son:
Ingeniería de producto final, esto es, instalación del nuevo sistema teniendo en cuenta el sobrelapamiento con el sistema viejo, paquete comercial, producción, entrega al departamento de venta y capacitación de personal.
Refinamiento de actividades incluyendo el arreglo de “bugs” y mejoras al sistema para alcanzar niveles mas altos de performance y utilización.
Evaluación del nivel de instalación comparándolo con los criterios de aceptación provistos por la visión del producto.
Milestone PR:
Esta etapa de evaluación requiere las respuestas a las siguientes preguntas:
Capítulo II: Marco Teórico – Desarrollo
17
¿El usuario esta satisfecho?
¿Los gastos actuales son aceptables en comparación con los previstos?
Aspectos Estáticos
Un proceso describe quien esta haciendo que, como y cuando. El proceso racional unificado esta representado por cinco elementos primarios:
1) Roles: El “quien” 2) Activities: El “como” 3) Artifacts: el “que” 4) Workflows: el “cuando” 5) Disciplines: El contenedor de todos los anteriores
Los tres primeros están representados en la figura 5.
Figura 5. Roles, Activities y Artifacts.
Un ejemplo de Workflow se da en la figura 6.
Capítulo II: Marco Teórico – Desarrollo
18
Figura 6. Ejemplo de Workflow.
Roles
El concepto central en el proceso es el rol. Un rol define un comportamiento y las responsabilidades de un individuo o de un conjunto de individuos trabajando como un equipo. Este rol esta expresando de acuerdo a las actividades que realiza y las responsabilidades de este rol son referidas a elementos que el individuo crea, modifica o controla. Los roles no son ni individuos, ni títulos de trabajo, son comportamientos, es decir que un individuo puede tener mas de un rol en un determinado proceso. Los roles están organizados en seis categorías principales. Aquí hay una lista de los roles en esas categorías.
1. Rol de Analista a. Analista de procesos de negocio b. Diseñador de negocios c. Analista de Sistemas d. Especificador de Requisitos
2. Rol de Desarrollador
Capítulo II: Marco Teórico – Desarrollo
19
a. Arquitecto de Software b. Diseñador c. Diseñador de la Interfaz de usuario (UI) d. Diseñador de cápsulas e. Diseñador de base de datos f. Implementador g. Integrador
3. Rol de Evaluador a. Analista de evaluaciones b. Diseñador de evaluaciones c. Evaluador
4. Rol de Administrador a. Administrador de proyecto b. Administrador de control de cambios c. Administrador de configuraciones d. Administrador de evaluaciones e. Administrador de despliegue f. Ingeniero de Procesos g. Administrador de revisiones
5. Rol de Producción y soporte a. Administrador del sistema b. Escritor técnico c. Artista grafico d. Especialista de herramientas e. Desarrollador de cursos
6. Roles adicionales a. Revisor b. Coordinador de revisiones c. Cualquier otro rol d. Stakeholder
Activities
Los roles tienen actividades que definen el trabajo que realizan. Una actividad es una unidad de trabajo realizada por un individuo en un rol determinado y que produce resultados significativos en el contexto del proyecto. Las actividades tienen un propósito claro, usualmente creando o actualizando elementos, como un modelo, una clase, o un plan. Algunas actividades son:
Planificación e iteración, realizadas por el rol: Administrador de proyecto
Encontrar los casos de uso y los actores, por el Analista de Sistemas
Rever el diseño, realizado por el Revisor de diseño
Ejecutar una evaluación de performance, por el evaluador de performance
Capítulo II: Marco Teórico – Desarrollo
20
Las actividades se pueden descomponer en una serie de pasos, lo cuales se pueden agrupar en tres categorías:
1) Pasos de análisis 2) Pasos de realización 3) Pasos de evaluación
Artifacts
Las actividades utilizan ciertos artifacts1, de entrada, y generan ciertos otros, de salida. Un artifact es una pieza de información que es producida, modificada o usada por un proceso. Los artifacts son los productos tangibles del proyecto. Toman varias formas:
Un modelo, como el modelo de casos de uso o el modelo de diseño
Un elemento de un modelo, como una clase, un caso de uso o un subsistema
Un documento, como el plan de negocio
Código fuente
Archivos ejecutables
Los artifacts más habituales de RUP se encuentran en la figura 7.
Figura 7. Artifacts habituales en RUP.
1 La traducción exacta de Artifact no existe, pero podría interpretarse como elemento, objeto, etc.
Capítulo II: Marco Teórico – Desarrollo
21
Estos son algunos ejemplos de artifacts:
Un modelo de diseño UML guardado en Rational XDE
Un plan de proyecto guardado en Microsoft Project
Una base de datos de los requisitos del proyecto guardado en Rational Requisite PRO
Los artifacts están agrupados en conjuntos, según la categoría a la que
pertenezcan. Las categorías son:
Conjunto de Administración
Conjunto de Requisitos
Conjunto de Diseño
Conjunto de Implementación
Conjunto de Desarrollo
La evolución de estos conjuntos a lo largo del proyecto se muestra en la figura 8.
Figura 8. Evolución de los conjuntos de elementos.
Workflows
Una simple enumeración de roles, actividades y elementos no constituyen un proceso. Necesitamos describir las secuencias principales de las actividades que producen resultados de valor y muestran las interacción entre los roles. Un Workflow es una secuencia de actividades que produce un resultado de gran valor. Es análogo, en UML, al diagrama de secuencia, de colaboración o de actividad.
Capítulo II: Marco Teórico – Desarrollo
22
Existen tres tipos de Workflows:
Core Workflows o Flujos de trabajos centrales asociados a cada disciplina
Detalles de Workflows, para refinar el Core Workflow
Planes de Iteración
Disciplines
Los disciplines2 son contenedores usados para organizar las actividades del proceso. Hay nueve disciplinas principales en RUP y representan una partición, en grupos lógicos según las especialidades, de todos los roles y las actividades. Se dividen en disciplinas técnicas y de soporte, esto es:
a- Disciplinas técnicas 1. Disciplina de modelado de negocios 2. Disciplina de requisitos 3. Disciplina de análisis y diseño 4. Disciplina de implementación 5. Disciplina de evaluación 6. Disciplina de despliegue
b- Disciplinas de soporte
7. Disciplina de administración de proyecto 8. Disciplina de administración de configuración y cambio 9. Disciplina de ambientación
Elementos secundarios
patrones o guías (donde se une UML con RUP)
plantillas
herramientas instructoras
definición de conceptos
Resumiendo
RUP, o el proceso racional unificado, es un proceso de desarrollo de
software, una metodología, una recomendación de cómo crear un software en forma rápida y eficiente, logrando un producto de gran calidad en la que todos los involucrados participan, mediante la utilización de un ciclo de vida iterativo.
Básicamente se divide en dos dimensiones.
2 Traduciremos disciplines como disciplinas, aunque esta última no engloba todo el significado que se pretende.
Capítulo II: Marco Teórico – Desarrollo
23
La primera dimensión es estática donde se ponen en evidencia las distintas disciplinas del proyecto, que no son ni mas ni menos que un conjunto de roles, actividades, artifacts y Workflows. Existen diversos roles dependiendo del comportamiento que se manifieste, actividades que realizan estos roles y artifacts que consumen y generan en dichas actividades. Todas estas actividades se relacionan entre si en un Workflow o flujo de trabajo.
La segunda dimensión es dinámica y pone en evidencia las distintas
etapas por las que atraviesa un ciclo de desarrollo de software. Se observan cuatro etapas, cada una con una seguida de una etapa de evaluación pertinente.
La primera etapa, inception phase, es la dedicada a verificar mas que
nada la viabilidad del proyecto, identificando los casos de usos principales, captando los principales requisitos pedidos por el cliente, elaborando un cronograma de trabajo completo para generar con todo esto una estimación de los costos a enfrentar.
La segunda etapa, elaboration phase, es la dedicada a crear los distintos
modelos, verificar si el proyecto sigue por el rumbo que el cliente quiere, redefinir el cronograma, y analizar los costos actuales versus los costos previstos. Esta fase allana todo el camino a la siguiente fase, la de construcción.
La tercera etapa, construction phase, es la dedicada a crear los distintos
documentos, como así también una versión final ejecutable del proyecto. La cuarta etapa, transition phase, es la etapa de despliegue, lo que
incluye instalación del producto, evaluación, capacitación de los usuarios, soporte, etc. En esta etapa se captan las posibles mejoras y se replantea otro ciclo de desarrollo para mejoras o corrección de bugs.
Así, RUP queda definido por el siguiente grafico que muestra las dos dimensiones, la estática y la dinámica, y muestra el esfuerzo invertido por cada disciplina en las distintas fases:
Capítulo II: Marco Teórico – Desarrollo
24
Algunos pensamientos contrarios a RUP son:
Usted piensa que la fase de inception es lo mismo que la fase donde se captan los requisitos, la fase de elaboración es igual a la de diseño y la fase de construcción igual a la de implementación (esto es, superponiendo un ciclo de vida en cascada con RUP).
Usted piensa que la fase de elaboration es una etapa de desarrollo minucioso de modelos que serán codificados en la etapa de construcción.
Usted trata de captar la mayoría de los requisitos antes de comenzar con el diseño o la implementación.
Trata de tener un diseño completo antes de programar.
Invierte un largo tiempo en captar los requisitos y diseñar antes de comenzar a programar.
Usted piensa que la duración de cada iteración es de aproximadamente 4 meses y no de 4 semanas (exceptuando proyectos de más de 100 personas).
Piensa que los diagramas UML y el diseño deben ser lo mas precisos posibles y que la programación es una simple traducción de estos diagramas.
Piensa que adoptar RUP significa hacer la mayor cantidad de actividades y documentos, y piensa que RUP es una gran serie de pasos a seguir.
Capítulo II: Marco Teórico – Desarrollo
25
Lenguaje Unificado de Modelado UML
Introducción
Hoy en día la programación de aplicaciones debe manejar la complejidad, creciente, que nos rodea. Una forma de manejar esta complejidad es a través del “Diseño Orientado a Objeto (DOO)”. Este diseño modela el mundo que nos rodea en un conjunto definido de objetos que poseen propiedades y realizan y se les pueden realizar acciones. Estos objetos son clasificados o agrupados en clases que poseen características generales de los objetos, es decir que los objetos son instancias de alguna clase. Claro esta que estas clases no están aisladas e interactúan unas con otras de una determinada manera. Esto conduce a que los objetos estén relacionados y se comuniquen entre ellos a través de mensajes. Esta interrelación de clases conforma una estructura bien definida que puede tornarse compleja de manejar si no se utilizan diagramas pertinentes que simplifiquen y estandaricen un proceso de negocio. Dentro de las fases de desarrollo de un sistema, la etapa de recopilación de información, análisis del dominio, diagramación son fundamentales para captar adecuadamente las necesidades del cliente, satisfacer las expectativas del usuario y facilitar la tarea de los programadores. UML (Unified Modeling Language), provee un lenguaje estándar que permite construir un conjunto de diagramas que modelan un sistema orientado a objetos. Estos diagramas son:
Diagramas de actividades
Diagramas de clases
Diagramas de distribución
Diagramas de paquetes
Diagramas de caso de uso
Diagramas de componentes
Diagramas de secuencias
Diagramas de colaboraciones
Diagramas de objetos
Diagramas de estado
Capítulo II: Marco Teórico – Desarrollo
26
Diagrama de actividades
Principales elementos:
Inicio de diagrama
Fin de diagrama
Bifurcación del flujo
Envío y recepción de indicaciones
Actividades concurrentes
Este diagrama tiene como función mostrar las actividades realizadas en
un proceso de negocio determinado a fin dar una imagen global del proceso e
Capítulo II: Marco Teórico – Desarrollo
27
incorporar términos propios del dominio. Se lo utiliza como una primera medida y generalmente es deducido de entrevistas realizadas con los distintos destinatarios del sistema.
Diagrama de clases
Principales componentes:
Clase
Clase con responsabilidades
explicitas
Capítulo II: Marco Teórico – Desarrollo
28
Clase con restricciones
explicitas
Nota relacionada a una clase
Asociación entre dos clases (sin
incluir la multiplicidad)
Asociación tripartita
Capítulo II: Marco Teórico – Desarrollo
29
Herencia de clases: La
subclase hereda atributo y
acciones de la superclase y
agrega las suyas propias
Dependencia de uso: La clase
dependiente usa la clase de
dependencia
Agregación: La clase total esta compuesta por
sus clases partes, que son no
exclusivas de su clase total.
Composición: La clase total esta compuesta por
todas sus clases partes que son
exclusivas de su clase total
Capítulo II: Marco Teórico – Desarrollo
30
Interfaz: Una clase utiliza un
conjunto de operaciones que se relacionan con
ella
Clase abstracta: es una clase que
no contiene instancias
Clase parametrizada: es
una clase utilizada para crear clases.
El diagrama de clases es el diagrama fundamental de UML. En el se muestran las distintas clases y sus interrelaciones, de modo de aproximar el modelo a la realidad. Se deriva a partir de las entrevistas, de donde se extraen sustantivos, adjetivos y verbos de tal forma que: Sustantivos Clases Adjetivos Atributos Verbos Relaciones
De la lista de sustantivos hay que sacar aquellos sustantivos que son
atributos, aquellos que son sinónimos entre si y los que representes clases fuera del dominio tratado. Por otro lado se pueden agregar clases extras según el criterio del modelador.
En cuanto a las relaciones, primero se establecen las relaciones de
asociación entre las distintas clases involucradas, luego se especifican las etiquetas de esas relaciones (acciones) y por ultimo la multiplicidad. Se utilizan relaciones tripartitas o múltiples (mas de tres) cuando dos o mas clases se interrelacionan. Después se determina que clases son componentes de otras, y se forma un diagrama utilizando relaciones de agregación. De ahí llenamos las clases con sus atributos y acciones. Este diagrama se ira depurando a medida que se realicen nuevas entrevistas.
Capítulo II: Marco Teórico – Desarrollo
31
Diagrama de distribución
Principales componentes:
Nodo
Nodo con información extra
Nota aclaratoria
Relación de comunicación entre nodos
Este diagrama es el más orientado al hardware interviniente en el sistema a desarrollar. Una vez creado el diagrama de clases, se puede determinar en forma preliminar que tecnología se utilizara y como se relacionan los distintos dispositivos involucrados.
Capítulo II: Marco Teórico – Desarrollo
32
Diagrama de paquetes funcionales
Componentes principales:
Paquete funcional
Caso de uso funcional
Este diagrama no es parte de la especificación propia de UML, sino que el paquete es un elemento de extensión de UML, pero puede considerárselo en el análisis ya que resume las principales funcionalidades de un sistema. Una de las formas de describir un sistema es a través de las tareas que los distintos roles realizan. Cada tarea será un caso de uso a considerar, y este diagrama agrupa todos los casos de uso en paquetes funcionales. Se deduce desde las entrevistas.
Diagramas de caso de uso
Principales componentes:
Actor: Quien inicia el caso de uso o quien es el beneficiario del
caso de uso
Caso de uso: Conjunto de escenarios que determinan una
tarea
Relación de inclusión: Un caso de uso incluye a otro
Relación de extensión: Un caso de uso es una extensión de otro
Capítulo II: Marco Teórico – Desarrollo
33
Herencia de casos de usos: Un caso de uso hereda el sentido y comportamiento de otro caso de
uso
Herencia de actores: un actor hereda el sentido y
comportamiento de otro actor
Este diagrama se deriva del diagrama de paquetes, con ayuda de los usuarios correspondientes del sistema. Muestra en forma detallada como se desarrolla cada tarea, mostrando los escenarios que esas tareas incluyen y los pasos necesarios para llevar a cabo cada escenario. UML es orientado a casos de usos, porque de aquí se desprende el diagrama de componentes y el diagrama de secuencias que facilitarán la tarea a los programadores, como así también la interfaz de usuario y el diagrama de distribución que da una idea de la distribución física (hardware) a utilizar. En un diagrama de caso de uso se especifican:
Descripción breve del caso de uso
Conjeturas o Suposiciones (derivaran en componentes de software)
Condiciones previas (como era antes)
Condiciones resultantes (como será después)
Pasos
Actor iniciante
Actor beneficiado
Cada caso de uso es tratado en forma independiente en una nueva hoja.
Capítulo II: Marco Teórico – Desarrollo
34
Diagrama de componentes
Principales componentes:
Componente de software
Interfaz de un componente de software
Dependencia entre componentes
Este diagrama es de gran ayuda para los programadores. En el se detallan todos los componentes de software como ser: bases de datos, tablas, documentos, archivos, ejecutables, etc., y muestra la relación existente entre ellos. También muestra en nombre de la interfaz que interactuará con este componente.
Diagrama de secuencia
Principales componentes:
Nombre del de los objetos (componentes del caso de
uso), línea de vida del objeto y activación (tiempo
que tarda en realizar la actividad)
Relaciones de paso de mensajes entre objetos.
Simple: Transferencia del control de un objeto a otro.
Sincrónico: espera la respuesta al mensaje antes
de continuar. Asincrónico: No espera una
respuesta antes de continuar.
Capítulo II: Marco Teórico – Desarrollo
35
Actor: es el que inicia el caso de uso al que
describe el diagrama de secuencias.
Estado: Se puede incluir el símbolo de estado para mostrar el cambio de un estado en relación con el
tiempo.
Este diagrama muestra la interacción entre los objetos en relación con el tiempo, es decir describe temporalmente un caso de uso. Es de gran utilidad para saber en que momento un objeto se activa y bajo que circunstancias lo hace.
Capítulo II: Marco Teórico – Desarrollo
36
Diagrama de estados
Principales componentes:
Este diagrama es utilizado para mostrar los distintos estados en los que puede encontrarse un sistema, las propiedades de ese estado, sus eventos asociados y las transiciones que conducen a estos estados.
Capítulo II: Marco Teórico – Desarrollo
37
Diagrama de colaboraciones
Principales componentes:
Este diagrama es una mezcla del diagrama de objetos con el diagrama de secuencias. Se muestran las relaciones entre los objetos y la secuencia en que estas interacciones se dan. Se define también el diagrama de colaboración parametrizada que es un diagrama utilizado para crear diagramas de colaboración específicos.
Capítulo II: Marco Teórico – Desarrollo
38
Diagrama de objetos
Principal componente:
El diagrama de objetos es una especificación o instanciación de un diagrama de clases. Se reemplazan las clases por los objetos determinados.
Capítulo II: Marco Teórico – Desarrollo
39
Microsoft Visio 2003 for Enterprise Architects
Aunque Visio nació oficialmente en Noviembre de 1992, realmente comenzó a gestarse desde 1984. Fue creado por un equipo de desarrolladores pertenecientes a Shapeware Corporation. Rápidamente alcanzó popularidad y fue una de las aplicaciones mas utilizadas para la generación de diagramas de distinta índole. Ya en el año 1999 contaba con un equipo de alrededor de 600 personas. En el año 2000 Microsoft advirtió el gran uso de Visio y lo adquirió por la módica suma de 1.5 Billones de dólares. Esta compra promocionó aún más el producto. En el año 2003 comenzó a integrar el paquete Office de Microsoft3. Fundamentalmente, Visio es un paquete de diagramas. Cuando muchos usuarios de software escuchan el nombre Visio automáticamente piensan en diagramas. Esto es comprensible ya que Visio se define como un software para la creación de diagramas de negocios y otros similares. Los desarrolladores de Visio, inteligentemente, expandieron el alcance de los diagramas incluyendo diagramas para dominios o industrias específicas y, en particular, los dibujos y diagramas de las tareas que ocurren dentro de estas industrias. Por ejemplo, Visio puede crear un diagrama de un sitio web completo trazando los hipervínculos desde una página a otra cuando uno le pasa como información la página principal. También puede generar un diagrama de base de datos a partir de las tablas de una base de datos existente. Incluye además herramientas para trazar la jerarquía empresarial de las corporaciones y planos arquitectónicos. Soporta automatización, dando a los desarrolladores COM la posibilidad de incluir diagramas dentro de sus aplicaciones. El punto es que Visio es una aplicación poderosa que ha encontrado diversos usos en una variedad de lugares. Visio no solo ofrece soporte para diagramas UML, sino que también soporta otros diagramas orientados al software como por ejemplo interfaces de usuario de Windows, COM, diagramas OLE y diagramas de flujo de datos. Para concluir con esta breve descripción, Visio 2003 for Enterprise Architects tiene la capacidad de generar código fuente en los lenguajes Visual Basic, C# y C++ a partir de los diagramas de UML4.
Diagramas UML en Microsoft Visio
Microsoft Visio cuenta con una librería de herramientas (Stencil) para cada área. Dentro del área de Software encontramos, entre otros, el Stencil de UML.
3 Para mas información referirse a: http://www.mvps.org/visio/History.htm 4 Existe bibliografía que explica el manejo en si de Microsoft Visio. [BB03], [FLMSSC02], [MIC03].
Capítulo II: Marco Teórico – Desarrollo
40
Figura 9 – Pantalla Inicial del Stencil de UML en Visio
Como vemos en la figura 9, en la parte izquierda del área de trabajo se encuentran ordenados los distintos elementos de UML según los diagramas. A continuación se muestran todos los elementos posibles para UML en Visio:
Capítulo II: Marco Teórico – Desarrollo
42
Figura 10 – Todos los elementos UML que posee Visio
En la figura 9 también se pueden apreciar dos ventanas más: el explorador del modelo y la ventana de salida (output). El primero muestra la estructura, el esqueleto del modelo, mientras que la segunda muestra los errores que se encuentran en el modelado. Los distintos diagramas se realizan arrastrando el elemento que corresponda al área de trabajo. UML permite utilizar elementos de un diagrama en otro, por lo que Visio permite realizar esta tarea también.
Capítulo III: Procedimientos de desarrollo
43
CAPÍTULO III
Procedimientos de desarrollo
Captura de los requisitos funcionales del sistema
El primer paso en el desarrollo de un sistema es la captura de los requisitos funcionales del sistema a partir de entrevistas con el cliente y los futuros usuarios del mismo. La idea no es solo saber que va a hacer el sistema, sino como le gustaría a los usuarios que este se presentase. Se debe elaborar un itinerario de entrevistas, elaborando un bosquejo de las preguntas a realizar. En la primera entrevista se determinara el objetivo del sistema y se planificaran las siguientes entrevistas de acuerdo a los temas discutidos. Si un tema es demasiado complejo o extenso se lo trata en una entrevista aparte con la persona que más entienda en dicho tema. Durante las entrevistas es útil realizar un alto y resumir, a fin de que el cliente vea si los analistas están entendiendo el tema. En definitiva, la entrevista trata de sacar todos los requerimientos del cliente, para describir en forma funcional y no funcional todo el sistema. Es útil y aconsejable realizar un diccionario de términos del dominio analizado, a fin de estandarizar un lenguaje común. Una vez captados los requisitos a través de las entrevistas, se procederá a la realización de la “Especificación de Requisitos” de acuerdo a la IEEE 8305. La estructura de esta especificación se detalla en el Anexo I.
Diagrama de actividades
Una vez realizadas la entrevistas se procederá al desarrollo de los correspondientes diagramas de actividades, que muestran en forma general la secuencia de los procesos en un sistema, como así también las responsabilidades de los distintos roles. Es aconsejable que este diagrama se realice simultáneamente con las entrevistas de forma que sea el mismo cliente el que pueda determinar si el diagrama es correcto o no y, además, sirva como guía para una entrevista estructurada.
5 El IEEE 830 fue desarrollado por el Instituto de Ingenieros Eléctricos y Electrónicos en el año 1998 para estandarizar la especificación de requisitos en desarrollo de sistemas.
Capítulo III: Procedimientos de desarrollo
44
Si el diagrama fuese desarrollado en simultáneo con las entrevistas, se aconseja hacerlo sobre una pizarra, de forma que todos puedan seguir la secuencia de las actividades desarrolladas en los distintos procesos.
Primeros casos de uso
En este momento del diseño se establecen, de acuerdo a las entrevistas, los primeros casos de uso que darán las pautas generales del sistema, de acuerdo a las características generales captadas en las entrevistas. El Proceso Unificado es una metodología basada en casos de uso y es por ello que este el diagrama más importante.
Diagrama de clases preliminar
Aquí el analista realizará una primera aproximación al diagrama de clases del sistema. Para ello se analizarán las entrevistas, listando sustantivos, verbos y construcciones verbales. Algunos de los sustantivos se convertirán en clases dentro del modelo, y algunos otros en atributos. Los verbos y construcciones verbales podrán convertirse en operaciones o las etiquetas de asociaciones. Para ello es útil realizar una lista con todos los sustantivos, verbos y construcciones verbales y de allí comenzar el análisis. Se descartan, primeramente, los sustantivos que sean sinónimos de otros, y luego se separan los sustantivos que sean atributos y no clases. De esta forma quedaran bien diferenciados los sustantivos candidatos a ser clases y que se plasmaran en un modelo inicial. Se agregaran las clases que se consideren necesarias y que no hayan sido listadas. Luego, se agrupan las clases según los distintos procesos, determinando las clases abstractas y las subclases que se relacionaran a esta a través de la generalización. Una vez agrupadas las clases, se determinan las asociaciones simples y múltiples, así como sus multiplicidades, de acuerdo a los verbos o frases verbales que correspondan. Por último, se tratará clase por clase, determinando los atributos y las operaciones que la clase realiza o permite que se realice sobre ella. A medida que se avance sobre el modelo, es posible que sean necesarias entrevistas adicionales para resolver puntos problemáticos o difusos.
Capítulo III: Procedimientos de desarrollo
45
Plataforma Preliminar
Una vez establecido un modelo de clases preliminar, podemos establecer una primera idea de la plataforma de hardware a utilizar mediante el diagrama de distribución. Se tendrá en cuenta tecnología existente, nueva y limitaciones establecidas al hardware.
Descripción de paquetes de funcionalidad
Se intenta mediante este diagrama reunir las funcionalidades en paquetes UML. Dentro de un paquete UML se mencionarán los casos de usos concernientes a un proceso del sistema. De esta forma se logra un avance importante hacia el desarrollo del diagrama de casos de uso definitivo.
Diagrama de casos de uso
Recordemos que cada caso de uso es una colección de situaciones y cada una de éstas es una secuencia de pasos. Para cada escenario en cada caso de uso queremos mostrar:
Una breve descripción del escenario
Conjeturas del escenario
El actor que inicia el caso de uso
Condiciones previas para el caso de uso
Pasos relacionados con el sistema en el escenario
Condiciones resultantes una vez finalizado el escenario
El actor beneficiado del caso de uso
Cada caso de uso será expuesto, según lo anterior, en hojas por separado. Es fundamental desarrollar los casos de usos con los usuarios del sistema, y en especial desarrollar bien los “Pasos relacionados con el sistema”, ya que mostrarán la forma en la que este funcionará. Es importante especificar claramente las conjeturas que se adopten en cada caso de uso. Al finalizar esta etapa se tendrán los diagramas de casos de uso que den soporte a las funcionalidades del sistema y es muy posible que a partir de aquí se deba modificar el diagrama de clases.
Capítulo III: Procedimientos de desarrollo
46
Diagramas de secuencias
Ahora por cada caso de uso se realizará un diagrama de secuencias donde se deje claramente especificada la secuencia (temporal) en la que se desarrollaran las actividades involucradas en cada caso de uso. Si es necesario se reformará el diagrama de clases.
Diagramas de distribución y de componentes
Una vez establecidas y descriptas todas las funcionalidades del sistema, mediante los casos de uso, el orden de las actividades, mediante el diagrama de secuencias, y el total de las clases intervinientes, se podrá proceder a realizar el diagrama de componentes de software que evidenciará la interacción entre los distintos módulos a desarrollar. Asimismo, se realizará el diagrama de distribución completo que mostrará los recursos de hardware necesarios para poder poner en funcionamiento el sistema a desarrollar. Recursos locales y remotos, redes, computadoras, elementos de red, etc, serán mencionados en este diagrama.
Diagramas adicionales
Los restantes diagramas (de estado, de objetos y de colaboraciones), asi como cualquier otro método (como por ejemplo fichas CRC), pueden ser utilizados. UML no es un lenguaje cerrado, solo establece pautas, herramientas que serán usadas por cada desarrollador según él considere necesario.
Anexo I: Especificación de requisitos
47
Anexo I
Especificación de requisitos
Estructura Básica6
Análisis de Requisitos del Sistema
1. Identificación de los usuarios participantes 2. Planificación y realización de entrevistas 3. Catálogo de Requisitos del Sistema
3.1. Objetivos y alcance del sistema 3.2. Definiciones, acrónimos y abreviaturas 3.3. Descripción general 3.4. Requisitos funcionales 3.5. Requisitos de usuario y tecnológicos 3.6. Requisitos de interfaces externas 3.7. Requisitos de rendimiento 3.8. Requisitos de desarrollo y restricciones de diseño
Desarrollo resumido
Análisis de Requisitos del Sistema
Este módulo tiene como objetivo analizar y documentar las necesidades
funcionales que deberán ser soportadas por el sistema a desarrollar. Para ello, se identificarán los requisitos que ha de satisfacer el nuevo sistema mediante entrevistas, el estudio de los problemas de las unidades afectadas y sus necesidades actuales. Además de identificar los requisitos se deberán establecer las prioridades, lo cual proporciona un punto de referencia para validar el sistema final que compruebe que se ajusta a las necesidades del usuario.
1. Identificación de los usuarios participantes
Los objetivos de esta tarea son identificar a los responsables de cada
una de las unidades implicadas y a los principales usuarios implicados. Para ello se consideran los siguientes aspectos:
Incorporación de usuarios al equipo de proyecto.
6 Un detalle completo se puede encontrar en el documento elaborado por el IEEE (IEEE 830) que se encuentra en el departamento de Sistemas [IEEE830].
Anexo I: Especificación de requisitos
48
Conocimiento de los usuarios de las funciones a automatizar.
Repercusión del nuevo sistema sobre las actividades actuales de los usuarios.
Implicaciones legales del nuevo sistema Es de destacar la necesidad de una participación activa de los usuarios del futuro sistema en las actividades de desarrollo del mismo, con objeto de conseguir la máxima adecuación del sistema a sus necesidades y facilitar el conocimiento paulatino de dicho sistema, permitiendo una rápida implantación.
2. Planificación y Realización de Entrevistas. Estudio de Documentación.
Esta tarea tiene como finalidad capturar los requisitos de usuarios para
el desarrollo del sistema. La entrevista consiste en una interacción sistemática con un usuario para extraer los conocimientos de éste. Se deben realizar entrevistas de tipo abierta y estructurada. En una entrevista abierta se plantean preguntas más o menos espontáneas al usuario, mientras que en una entrevista estructurada se planifican las preguntas que se deben plantear al usuario durante la sesión. El proceso comprende:
Planificar las entrevistas a realizar: en la planificación se incluirá fecha, hora y lugar de la entrevista, duración estimada y guión de la entrevista.
Realizar las entrevistas y documentarlas debidamente.
Documentar los requisitos identificados con sus prioridades.
A partir de las entrevistas realizadas con los responsables y usuarios, se identifican los requisitos que debe cumplir el sistema y se establecerá una prioridad para los mismos, de acuerdo a las necesidades expresadas por los usuarios y a los objetivos a cubrir por el nuevo sistema.
El estudio de la documentación consiste en la educción de requisitos de
los documentos e impresos que forman parte del sistema actual.
3. Catálogo de Requisitos del Sistema
El objetivo de la especificación es definir en forma clara, precisa,
completa y verificable todas las funcionalidades y restricciones del sistema que se desea construir. Esta documentación está sujeta a revisiones por el grupo de usuarios que se recogerán por medio de sucesivas versiones del documento, hasta alcanzar su aprobación por parte del grupo de usuarios. Una vez aprobado, servirá de base al equipo de desarrollo para la construcción del nuevo sistema.
Anexo I: Especificación de requisitos
49
3.1. Objetivos y alcance del sistema
En esta etapa se detallan los objetivos del sistema, describiendo
brevemente QUÉ es lo que el sistema debe hacer. En el alcance del sistema se describe en lenguaje natural el ámbito del sistema, su dominio y sus límites.
3.2. Definiciones, acrónimos y abreviaturas
Esta etapa tiene como fin establecer el vocabulario de términos que
forman parte del sistema, de manera que TODOS los participantes "hablen el mismo idioma".
3.3. Descripción general
Esta sección nos presenta una descripción general a grandes rasgos del
sistema con el fin de conocer las principales funciones que debe soportar, los datos asociados, las restricciones impuestas y cualquier otro factor que pueda influir en la construcción del mismo. Una buena manera de realizar la descripción es plantearla con un enfoque descendente; es decir, a nivel subsistemas, detallando las funciones por debajo de los mismos.
3.4. Requisitos funcionales
Descripción en lenguaje natural de las funciones desglosadas en la
etapa anterior, detallando las entradas, las salidas y la descripción del proceso desde el punto de vista del usuario. Las descripciones de entradas y salidas deben ser en lo posible gráficas, o bien los documentos que se usan corrientemente.
3.5. Requisitos de usuario y tecnológicos
Requisitos de usuario: debe describirse el nivel de conocimiento de cada
usuario (novato, intermedio, experto) para la realización de interfaces, manuales de usuario, ayuda y capacitación de los mismos.
Requisitos tecnológicos: se describen las necesidades desde el punto de
vista tecnológico, es decir equipos de clientes y servidores, velocidades de transmisión de datos, características que debe tener el sistema operativo y el sistema gestor de base de datos, y cualquier equipo que forma parte del sistema. Este documento es solamente un conjunto de criterios que me permite luego elegir el software y hardware adecuado para el sistema.
Anexo I: Especificación de requisitos
50
3.6. Requisitos de interfaces externas
En esta etapa se capturan los requerimientos que describen cómo debe
ser la comunicación del sistema con el usuario y el mundo exterior. Se deben capturar las interfaces con el usuario, interfaces hardware, interfaces software e interfaces de comunicación.
3.7. Requisitos de rendimiento
Pretende definir una serie de parámetros MENSURABLES del sistema
que imponen restricciones sobre el mismo. Generalmente están asociados a tiempos de respuesta, tiempos de espera y duración de tareas batch. Estos requerimientos son muy importantes ya que la no-satisfacción de los mismos implica un fracaso del sistema, por lo que deben tener una prioridad alta.
3.8. Requisitos de desarrollo y restricciones de diseño
Requisitos de desarrollo: se definen los requerimientos planteados por el
equipo de trabajo: qué metodología se seguirá, qué ciclo de vida, qué herramientas se utilizarán, etc.
Restricciones de diseño: son requisitos que nos impone la naturaleza del
dominio del problema. Estos son: ajuste a estándares (por ejemplo una determinada manera de codificar un dato), limitaciones hardware (por los equipos disponibles), seguridad (por los distintos niveles de acceso a la información que deben tener los usuarios), mantenimiento (se debe tener en cuenta la ampliación del sistema), adaptación al entorno y políticas de borrado.
Bibliografía
51
Bibliografía
[BJR99] - James Rumbaugh, Ivar Jacobson, Grady Booch . 1999. The Unified Modeling Language Reference Manual. Addison-Wesley. [PK03] - Philippe Kruchten. 2003. The Rational Unified Process An Introduction. Third Edition. Addison-Wesley. [CL02] - Craig Larman. 2002. Applying UML and Patterns. Second Edition. Prentice Hall. [FLMSSC02] - Andrew Filev, Tony Loton, Kevin McNeish, Ben Schoellmann, John Slater, Chaur Wu. 2002. Professional UML with Visual Studio .NET. Unmasking Visio for Enterprise Architects. Wrox Press Ltd. [BJR00] - Ivar Jacobson, Grady Booch, James Rumbaugh. 2000. El Proceso Unificado de Desarrollo de Software. Pearson Addison Wesley. [JS02] - Joseph Schmuller. 2002. Sams Teach Yourself UML in 24 Hours. Second Edition. Sams Publishing. [BB03] - Bonnie Biafore. 2003. Visio 2003 Bible. Wiley Publishing, Inc. [MIC03] - Microsoft Corporation. 2003. Guía del usuario de Microsoft Office Visio 2003. Microsoft Press. [IEEE830] - IEEE (Institute of Electrical and Electronic Engineers). 1998. IEEE Recommended Practice for Software Requirements Specifications.