manual de procedimientos de desarrollo de sistemas mediante proceso unificado

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.


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.


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.


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).


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.


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.


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.


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?


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.


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?


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:


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.


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


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


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.


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.


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.


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:


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.


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


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


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


28

Clase con restricciones

explicitas

Nota relacionada a una clase

Asociación entre dos clases (sin

incluir la multiplicidad)

Asociación tripartita


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


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.


31

Diagrama de distribución


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.


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


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


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.


34

Diagrama de 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


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.


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.


36

Diagrama de estados


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.


37

Diagrama de colaboraciones


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.


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.


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].


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:


41


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.


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.


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.


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].


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.


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.


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.

manual de procedimientos de desarrollo de sistemas mediante proceso unificado

Documents