- 1 -
RUP/Easy
GUÍA METODOLÓGICA DE DESARROLLO DE
SISTEMAS
Documento basado en THE ITSC SYSTEM DEVELOPMENT
METHODOLOGY GUI...
- 2 -
Histórico de cambios
Fecha Versión Descripción Autor
Setiembre 2004 1.0 Creación del documento Oswaldo Canchumani
Ma...
- 3 -
RUP/Easy
GUÍA METODOLÓGICA DE DESARROLLO DE
SISTEMAS
Marzo del 2006
TABLA DE CONTENIDO
1 INTRODUCCIÓN..................
- 4 -
3.3.3 Artefactos para Análisis y Diseño ...............................................................................
- 5 -
RUP / Easy
GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS
1 INTRODUCCIÓN
Durante los últimos años, una de las metodolog...
- 6 -
Cada workflow descrito en la Sección 3 contiene las siguientes subsecciones:
• Configuración y Notas sobre el Workfl...
- 7 -
Revisar Detalles Define el nivel de revisión;
procedimientos de revisión que
van a ser aplicados al artefacto.
Decid...
- 8 -
Tabla 4. Guías de Niveles de Revisión del RUP
Nivel de Revisión Explicación Comentarios
Formal-Externo
Este artefact...
- 9 -
3.1 MODELAMIENTO DE NEGOCIOS
El Modelamiento de Negocios se efectúa para valorar el negocio para el cual el sistema
...
- 10 -
modelo de diseño del Workflow de Análisis y Diseño.
La Figura 1 ilustra las actividades efectuadas durante el Model...
- 11 -
• Explorar la Automatización de Procesos (Explore Process Automation)
• Desarrollar un Modelo de Dominio (Workflow ...
- 12 -
• Identificar las Metas del Negocio. Identificar los objetivos con los cuales el negocio
puede ser planeado y manej...
- 13 -
fronteras del negocio que están modelando. También, necesitan decidir cuáles procesos
dentro de esas fronteras será...
- 14 -
posteriores. Encontrar nuevos actores del negocio que definen roles que son
compartidos por varios actores del nego...
- 15 -
proveer del comportamiento requerido. Identificar los eventos del negocio
disparados por la entidad del negocio. Ev...
- 16 -
eventos en el negocio. Describir cómo las realizaciones de Casos de Uso del
Negocio son efectuadas por los trabajad...
- 17 -
Unidad de la
Organización
X
Rational Rose
Especificación
Suplementaria del
Negocio
X
Formal -Externo Requisite Pro,...
- 18 -
Sin embargo, el Modelamiento del Negocio sólo debe ser efectuado si se está
cambiando la manera en que se hace nego...
- 19 -
mecanismos de control de cambios para los requerimientos.
Los workflows de Requerimientos consisten de los siguient...
- 20 -
que están tratando de resolver con el nuevo sistema. Para evitar malos entendidos, un
glosario es creado para prove...
- 21 -
como reglas del negocio, requerimientos de mejora, entrevistas y workshops de
requerimientos.
Comprende las siguien...
- 22 -
• Efectuar un análisis de alto nivel a los resultados de los requerimientos recolectados
a los stakeholder.
• Refin...
- 23 -
• Definir el conjunto de Casos de Uso (o Escenarios) que representan la funcionalidad
central.
• Definir cuáles atr...
- 24 -
Comprende las siguientes actividades:
• Detallar los Casos de uso. Describir uno o más de los flujos de eventos de ...
- 25 -
son establecidas para identificar las relaciones entre los requerimientos y otros
artefactos. Las relaciones de ras...
- 26 -
La Visión debe dejar en claro a los stakeholders lo siguiente:
• Los beneficios y las oportunidades que obtendrán d...
- 27 -
La variación metodológica de RUP/Easy no incluye la creación del reporte Storyboard
de Casos de Uso.
Tampoco incluy...
- 28 -
Workflow de Análisis y Diseño
Definir una Arquitectura candidata
Este workflow es efectuado durante las iteraciones...
- 29 -
modelamiento para el sistema.
• Análisis de Casos de Uso. Identificar las clases que efectúan el flujo de eventos d...
- 30 -
implementación de los Subsistemas y sus contenidos.
• Describir la Arquitectura de Run-Time. Analizar requerimiento...
- 31 -
• Implementar los elementos de diseño como componentes
Comprende las siguientes actividades:
• Diseñar las Cápsulas...
- 32 -
• Diseñar la Base de Datos. Asegurar que los datos persistentes estén almacenados
consistentemente y eficientemente...
- 33 -
3.3.4 Notas sobre los Artefactos para Análisis y Diseño
El Modelo de Análisis y Diseño puede ser mantenido como dos...
- 34 -
conjunto de patrones previamente desarrollados y disponible para reusar. El propósito
de una Arquitectura de Refere...
- 35 -
• Análisis y Diseño: El modelo de diseño desarrollado durante este workflow
representa el intento de la implementac...
- 36 -
hasta que el producto final sea obtenido
Comprende las siguientes actividades:
• Estructurar el Modelo de Implement...
- 37 -
• Analizar el Comportamiento en Run-time. Comprender el comportamiento de un
componente durante su ejecución. Ident...
- 38 -
Comprende las siguientes actividades:
• Integrar el Sistema. Integrar los subsistemas de implementación por pedazos...
- 39 -
• Aconsejando acerca de la calidad percibida en el software
• Proveyendo la validación de los supuestos hechos en l...
- 40 -
Prueba: de Datos funcionan apropiadamente y sin corrupción de datos.
Técnica: • Invocar a cada método de acceso y p...
- 41 -
• Todos los defectos identificados han sido corregidos.
Consideraciones
Especiales:
• Para ejecutar estas pruebas p...
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Rupeasy guia v2
Upcoming SlideShare
Loading in …5
×

Rupeasy guia v2

475 views

Published on

RUP/Easy v2. Guía metodológica de desarrollo de sistemas

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
475
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
11
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Rupeasy guia v2

  1. 1. - 1 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Documento basado en THE ITSC SYSTEM DEVELOPMENT METHODOLOGY GUIDEBOOK Prepared by the Information Technology Support Center September 2002 Oswaldo Canchumani Grillo, PMP Marzo del 2006
  2. 2. - 2 - Histórico de cambios Fecha Versión Descripción Autor Setiembre 2004 1.0 Creación del documento Oswaldo Canchumani Marzo 2006 2.0 Se extendió a todos los procesos Oswaldo Canchumani
  3. 3. - 3 - RUP/Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS Marzo del 2006 TABLA DE CONTENIDO 1 INTRODUCCIÓN.................................................................................................................................5 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP.................................................5 2.1 WORKFLOWS ESENCIALES DEL RUP ...................................................................................5 2.2 VISTA GENERAL DEL WORKFLOW DEL RUP ......................................................................5 2.2.1 Configuración y Notas sobre el Workflow del RUP ...............................................................6 2.2.2.1 Explicación de la Tabla Artefacto RUP................................................................................6 2.3 PROCEDIMIENTOS DE REVISIÓN ...........................................................................................7 3 VERSIÓN ADECUADA DE RUP/Easy DE LOS WORKFLOWS ESENCIALES DEL RUP...........8 3.1 MODELAMIENTO DE NEGOCIOS ............................................................................................9 Valorizar el Estado del Negocio.................................................................................................11 Describir el Negocio Actual .......................................................................................................12 Identificar los Procesos del Negocio ..........................................................................................12 Refinar las Definiciones de los Procesos del Negocio................................................................13 Diseñar las Realizaciones de los Procesos del Negocio .............................................................14 Refinar los Roles y las Responsabilidades .................................................................................14 Explorar la Automatización de Procesos....................................................................................15 Desarrollar un Modelo de Dominio............................................................................................15 3.2 REQUERIMIENTOS...................................................................................................................18 3.2.1 Vista general del Workflow de Requerimientos....................................................................18 Analizar el Problema ..................................................................................................................19 Entender las Necesidades del Stakeholder..................................................................................20 Definir el Sistema.......................................................................................................................21 Administrar el Alcance del Sistema ...........................................................................................22 Refinar la Definición del Sistema...............................................................................................23 Administrar los Requerimientos de Cambios .............................................................................24 3.2.2 Configuración y Notas sobre el Workflow de Requerimientos .............................................25 3.2.3 Artefactos de Requerimientos................................................................................................25 3.2.4 Notas sobre los Artefactos de Requerimientos ......................................................................25 3.2.5 Reportes de Requerimientos..................................................................................................26 3.2.6 Notas sobre los Reportes de Requerimientos.........................................................................26 3.3 ANÁLISIS Y DISEÑO ................................................................................................................27 3.3.1 Vista General del Workflow de Análisis y Diseño................................................................27 Definir una Arquitectura candidata ............................................................................................28 Refinar la Arquitectura ...............................................................................................................29 Analizar el Comportamiento.......................................................................................................30 Diseñar los Componentes ...........................................................................................................30 Diseñar la base de Datos (Opcional)...........................................................................................31 3.3.2 Configuración y Notas sobre el Workflow de Análisis y Diseño ..........................................32
  4. 4. - 4 - 3.3.3 Artefactos para Análisis y Diseño .........................................................................................32 3.3.4 Notas sobre los Artefactos para Análisis y Diseño................................................................33 3.3.5 Reportes para Análisis y Diseño............................................................................................34 3.4 IMPLEMENTACIÓN ..................................................................................................................34 3.4.1 Vista general del Workflow de Implementación ...................................................................34 Estructurar el Modelo de Implementación..................................................................................35 Planificar la Integración..............................................................................................................36 Implementar los Componentes ...................................................................................................36 Integrar cada Subsistema............................................................................................................37 Integrar el Sistema......................................................................................................................37 3.4.2 Configuración y Notas sobre el Workflow de Implementación.............................................38 3.4.3 Artefactos para la Implementación........................................................................................38 3.4.4 Notas sobre los Artefactos para la Implementación ..............................................................38 3.4.5 Reportes para la Implementación ..........................................................................................38 3.5 PRUEBAS....................................................................................................................................38 3.5.1 Vista General del Workflow de Pruebas................................................................................39 Planificar las Pruebas..................................................................................................................51 Diseñar las Pruebas.....................................................................................................................52 Implementar las Pruebas.............................................................................................................53 Ejecutar las Pruebas en la etapa de Integración de Pruebas........................................................54 Ejecutar las Pruebas en la etapa de Pruebas del Sistema............................................................54 Evaluar las Pruebas.....................................................................................................................55 3.5.2 Configuración y Notas sobre el Workflow de Pruebas..........................................................56 3.5.3 Artefactos de Pruebas............................................................................................................56 3.5.4 Notas sobre los Artefactos para Pruebas................................................................................56 3.5.5 Reportes para las Pruebas......................................................................................................57 3.6 DESPLIEGUE..............................................................................................................................57 3.6.1 Vista General del Workflow de Despliegue ..........................................................................57 Planificar el Despliegue..............................................................................................................59 Desarrollar Material de Soporte..................................................................................................59 Manejar las Pruebas de Aceptación............................................................................................59 Producir la Unidad de Despliegue ..............................................................................................60 Empaquetar el Producto..............................................................................................................60 Proveer Acceso al Site de Descarga ...........................................................................................61 Producto en Beta.........................................................................................................................61 3.6.2 Configuración y Notas sobre el Workflow de Despliegue ....................................................61 3.6.3 Artefactos para el Despliegue................................................................................................61 3.6.4 Notas sobre los Artefactos para el Despliegue ......................................................................62 3.6.5 Reportes para el Despliegue ..................................................................................................62 3.7 ADMINISTRACIÓN DE CONFIGURACIÓN Y CAMBIOS ....................................................62 3.7.1 Por qué implementar Administración de Configuración y Cambios .....................................62 3.7.2 Vista general del Workflow de Administración de Configuración y Cambios......................64 Planificar la Configuración del Proyecto y el Control de Cambios...........................................74 Crear un Ambiente CM para el Proyecto....................................................................................75 Cambiar y Enviar los Items de la Configuración........................................................................76 Manejar Versiones Congeladas (Baselines) y Liberaciones.......................................................76 Monitorear y Reportar el estado de la Configuración.................................................................77 Administrar los Requerimientos de Cambio...............................................................................77 3.7.3 Notas sobre el Workflow de Administración de Configuración y Cambios..........................78 3.7.4 RUP Artefactos de Administración de Configuración y Cambios.........................................78 3.7.5 Notas sobre los Artefactos para la Administración de Configuración y Cambios.................78 3.7.6 Notas sobre los reportes de Administración de Configuración y Cambios............................79 4 PASOS SIGUIENTES PARA LAS EMPRESAS CLIENTE .............................................................79
  5. 5. - 5 - RUP / Easy GUÍA METODOLÓGICA DE DESARROLLO DE SISTEMAS 1 INTRODUCCIÓN Durante los últimos años, una de las metodologías más populares ha sido el Rational Unified Process (RUP). RUP, desarrollado por Rational Software Corporation, es un proceso de ingeniería de software que ofrece un enfoque disciplinado para asignar tareas y responsabilidades dentro de la organización del desarrollo. RUP captura algunas de las mejores prácticas de la industria para el desarrollo de software las cuales son para desarrollar el software en iteraciones, administrar requerimientos, usar arquitecturas basadas en componentes, verificar la calidad del software, controlar los cambios al software y modelar el software visualmente usando el Unified Modeling Language (UML). "El Unified Modeling Language (UML) es un método orientado a objetos y el lenguaje estándar de la industria para especificar, visualizar, construir y documentar los artefactos de sistemas de software.". Un Artefacto es una pieza de información que es creada, modificada o usada por un proceso tal como un modelo, un Caso de Uso, un documento, código fuente o archivo ejecutable. Esta guía documenta los pasos para aplicar correctamente la metodología RUP en el proceso de desarrollo de software. RUP es muy amplio y la mayoría de proyectos no necesitan seguir todo lo que está en el RUP. Esta guía demuestra la variación hecha en el RUP por RUP/Easy para su aplicación en las empresas del Perú. 2 ADECUACIÓN DE LOS WORKFLOWS ESENCIALES DEL RUP Esta sección explica cómo leer la adecuación de los Workflows esenciales del RUP detallados en la sección 3 de este documento. 2.1 WORKFLOWS ESENCIALES DEL RUP Esta guía metodológica cubre la adecuación para los nueve (9) workflows: Modelamiento de Negocios, Requerimientos, Análisis y Diseño, Implementación, Pruebas, Administración de Configuración y Cambios, Despliegue. Esta guía metodológica excluye los workflows esenciales del RUP para Administración de Proyectos y Ambiente. 2.2 VISTA GENERAL DEL WORKFLOW DEL RUP La Sección 3 da una vista general a cada Workflow esencial del RUP y explica por qué es importante incluir ése particular Workflow esencial del RUP en su ciclo de vida de desarrollo de software.. Se presenta un Diagrama de Actividades que detalla la estructura del los workflows esenciales del RUP. Cada Workflow de detalle dentro del Workflow esencial del RUP es explicado al igual que los artefactos clave producidos por cada Workflow de detalle. Este documento no describe a los trabajadores durante la explicación de cada Workflow esencial del RUP.
  6. 6. - 6 - Cada workflow descrito en la Sección 3 contiene las siguientes subsecciones: • Configuración y Notas sobre el Workflow del RUP • Artefactos • Notas sobre los Artefactos • Reportes • Notas sobre los Reportes 2.2.1 Configuración y Notas sobre el Workflow del RUP Estas subsecciones detallan los cambios aplicados a la estructura de workflows del RUP en la variación de la metodología de RUP/Easy. 2.2.2 Artefactos Un artefacto es un pedazo de información que es creado, modificado o usado por un proceso tal como un modelo, un Caso de Uso, un documento, código fuente o un archivo ejecutable. Estas subsecciones listan los artefactos que deberían ser producidos por cada Workflow esencial del RUP en un formato de tabla. RUP provee templates, guías y ejemplos para todos los artefactos. Si usted no está usando RUP, entonces deberán desarrollarse los templates que puedan ser usadas en toda su organización para lograr consistencia al capturar el mismo tipo de información. La Tabla 2 identifica las columnas usadas para definir los artefactos producidos por cada workflow del RUP; las entradas en las columnas son explicadas en la Tabla 1. Tabla 1. Artefacto RUP Artefactos Created/Revised Revisar Detalles Herramientas Usadas RUP Artefacto 1 Incep Elab Const Trans 2.2.2.1 Explicación de la Tabla Artefacto RUP La Tabla 2 da una explicación de las columnas en la Tabla Artefacto RUP mostrada en la Tabla 1. Tabla 2. Explicación de la Tabla Artefacto RUP Nombre de Columna Propósito Contenidos/Comentarios Artefactos El nombre del artefacto. Un artefacto es un entregable del proceso. Una referencia al artefacto en el Rational Unified Process. Creado / Revisado Califica cómo es usado el artefacto a través del ciclo de vida Una 'X' en una o más de las celdas Fase, significa que planeamos congelar ese artefacto en esa fase particular: Incepción, Elaboración, Construcción y Transición.
  7. 7. - 7 - Revisar Detalles Define el nivel de revisión; procedimientos de revisión que van a ser aplicados al artefacto. Decidir el nivel de revisión: • Formal-Externo • Formal-Interno • Informal • Ninguno Para detalles vea la Sección 2.3, Procedimientos de Revisión Herramientas Usadas Definición de la herramienta (o herramientas) usadas para producir el artefacto. Referencia a los detalles de las herramientas usadas para desarrollar y mantener el artefacto. 2.2.3 Notas sobre los Artefactos RUP viene con una lista de artefactos que se pueden producir en cada Workflow esencial del RUP. Usar el RUP efectivamente en su organización, podría no ser necesario que produzca todos los artefactos. La Sección 3 identifica esos artefactos del RUP que no son producidos en cada Workflow esencial del RUP en la variación de la metodología de RUP/Easy. Cuando lea esta sección use el glosario para comprender mejor el propósito de los artefactos listados. 2.2.4 Reportes Esta subsección lista los reportes a ser usados por cada Workflow esencial del RUP. La Tabla 3 muestra el formato que es usado para definir los reportes producidos por cada Workflow esencial del RUP. Tabla 3. Tabla de Reportes Reportes Herramientas usadas 2.2.5 Notas sobre los Reportes Un reporte extrae información acerca de modelos y elementos de los modelos desde una herramienta. RUP viene con una lista de reportes que pueden ser producidos para cada Workflow esencial del RUP. Usar el RUP efectivamente en su organización, podría no ser necesario que produzca todos los reportes. La Sección 5 identifica esos reportes del RUP que no son producidos en cada Workflow esencial del RUP en la variación de la metodología de RUP/Easy.. 2.3 PROCEDIMIENTOS DE REVISIÓN Durante el ciclo de vida de un proyecto, una revisión de un artefacto o conjunto de artefactos es presentada al usuario, cliente u otras partes interesadas para comentarios y aprobación. Cuando se hacen estas revisiones, usted debe tener en consideración que las revisiones para el equipo de desarrollo “de casa” son diferentes a las revisiones para el equipo de desarrollo de un contratista. Si las revisiones son “de casa” mayormente son informales. Cuando el trabajo lo hace un contratista normalmente se hace una revisión formal del trabajo del contratista. RUP/Easy ha adoptado los niveles de revisión indicados en la Tabla 4.
  8. 8. - 8 - Tabla 4. Guías de Niveles de Revisión del RUP Nivel de Revisión Explicación Comentarios Formal-Externo Este artefacto es un entregable en un hito específico. Requiere algún tipo de aprobación del cliente, el patrocinador o algún otro stakeholder externo. Por ejemplo, la Visión y el Caso de Negocio son artefactos que deberían ser revisados por stakeholders. Los resultados de la revisión son manejados en la configuración junto con el artefacto. Formal-Interno El artefacto es revisado formalmente por el equipo del proyecto. Por ejemplo, las interfases de diseño de subsistemas deberían ser revisados y aprobados por varios miembros del equipo del proyecto. Los resultados de la revisión son manejados en la configuración junto con el artefacto. Informal El artefacto es revisado; pero no es aprobado formalmente. Las Clases de Diseño y los Componentes son ejemplos de artefacto que no son aprobados formalmente. El artefacto es desarrollado y mantenido. Normalmente no es descartado luego que el proyecto termina. Los resultados de la revisión no son manejados en la configuración con el artefacto. Ninguno Este artefacto no necesita ser revisado ni aprobado. El artefacto es creado como información de trabajo. A menudo es un artefacto temporal que es descartado luego que el proyecto termina. 3 VERSIÓN ADECUADA DE RUP/Easy DE LOS WORKFLOWS ESENCIALES DEL RUP La suite de herramientas de Rational (Rational Rose, RequisitePro, Rational Robot, ClearCase, ClearQuest) y el RUP, desarrollados por Rational Software, fueron escogidos para demostrar un enfoque iterativo del ciclo de vida de desarrollo de software. RUP/Easy usó el marco metodológico del RUP para adecuar los siguientes Workflows esenciales del RUP: • Modelamiento de Negocios – Una técnica de análisis para modelar los procesos del negocio y entender mejor las complejidades de éste. • Requerimientos – Una condición o capacidad que el sistema debe cumplir. • Análisis y Diseño - Muestra cómo los casos del uso del sistema se realizarán en la implementación. • Implementación – Implementar y probar las clases. • Pruebas – Integrar y probar el sistema. • Despliegue – Asegura una transición exitosa del sistema desarrollado a sus usuarios. • Administración de la Configuración y Cambios –Identifica, define y estandariza ítems; controla las modificaciones y releases de ítems. Las organizaciones típicamente usan enfoques de administración de proyectos para sus proyectos de desarrollo de software. Las organizaciones necesitarán incluir administración de proyectos con RUP y adecuarse según sea necesario. Un Plan de Iteración es algo que debe ser producido durante la Control de Proyectos.
  9. 9. - 9 - 3.1 MODELAMIENTO DE NEGOCIOS El Modelamiento de Negocios se efectúa para valorar el negocio para el cual el sistema de información se está construyendo y para determinar mejor las necesidades y problemas a ser resueltos por los sistemas de información. Los modelos del negocio proveen una base para la comunicación entre los analistas de sistemas y los desarrolladores para incrementar su entendimiento del negocio y para identificar oportunidades de mejorar el negocio. También, los gerentes de proyecto usan los modelos del negocio para ayudarse a estimar los costos del proyecto. 3.1.1 Porqué modelar el negocio Ya que los negocios están siendo cada vez más automatizados y los sistemas de computadora están tocando cada aspecto del negocio, la clave para implementar exitosamente un nuevo sistema de computadora es entender el negocio. También con la evolución de los negocios existentes y nuevos negocios requiriendo muchas piezas complejas interconectadas, el modelamiento de negocios provee una vista interna de si el negocio está haciendo, o no, las cosas correctas y cómo el valor del negocio puede ser mejorado. El modelo del negocio provee un salto de inicio para capturar los requerimientos del sistema (Más detalles acerca de capturar los requerimientos se encuentran en la Sección 3.2.). 3.1.2 Vista general del Workflow de Modelamiento de Negocios El propósito del Workflow de Modelamiento de Negocios es: • Entender la estructura y las dinámicas de la organización en la cual un sistema va a ser desplegado (la organización objetivo). • Entender los problemas actuales en la organización objetivo e identificar mejoras potenciales. • Asegurar que los clientes, usuarios finales y desarrolladores tiene un entendimiento común de la organización objetivo. • Derivar los requerimientos necesarios para soportar la organización objetivo. Los artefactos clave del Workflow de Modelamiento de Negocios son la Visión del Negocio (Business Vision), Modelo de Caso de Uso del Negocio (Business Use-Case Model) y el Modelo de Objetos del Negocio (Business Object Model). Otros artefactos del Workflow de Modelamiento de Negocios son el Reglas del Negocio (Bussines Rules), Especificaciones Suplementarias del Negocio (Business Supplementary Specification) y el Glosario del Negocio (Business Glossary). El Workflow de Modelamiento de Negocios está relacionado a otros Workflows del RUP, como sigue: • El Workflow de Requerimientos usa modelos del negocio como un input importante para entender los requerimientos del sistema. • Las entidades del negocio son usadas como un input para identificar clases en el
  10. 10. - 10 - modelo de diseño del Workflow de Análisis y Diseño. La Figura 1 ilustra las actividades efectuadas durante el Modelamiento de Negocios . Figura 1. Workflow de Modelamiento de Negocios El Workflow de Modelamiento de Negocios consiste de los siguientes Workflows de detalle: • Valorizar el Estado del Negocio (Assess Business Status) • Describir el negocio Actual (Describe Current Business) • Identificar los Procesos del Negocio (Identificar Business Processes) • Refinar las Definiciones de los Procesos del Negocio (Refine Business Process Definitions) • Diseñar las Realizaciones de los Procesos del Negocio (Design Business Process Realizations) • Refinar los Roles y las Responsabilidades (Refine Roles y Responsibilities)
  11. 11. - 11 - • Explorar la Automatización de Procesos (Explore Process Automation) • Desarrollar un Modelo de Dominio (Workflow de detalle alternativo) (Develop a Domain Model -alternative Workflow detail-) Valorizar el Estado del Negocio El propósito de este Workflow de detalle es: • Valorizar el estado de la organización en la cual el nuevo sistema va a ser desplegado (la organización objetivo). • Entender cómo categorizar el proyecto y cual escenario de Modelamiento de Negocios, listado a continuación, se adecua más a su proyecto: − Gráfico de la Organización – un mapa simple de la organización para entender mejor los requerimientos. − Modelamiento de Dominio – es usado para construir aplicaciones cuyo propósito principal es manejar y presentar información. − Un negocio, muchos sistemas – un modelo del negocio para un sistema grande o una familia de aplicaciones. − Modelo de negocios genérico – para una aplicación usada por muchas organizaciones. − Negocio nuevo – para una línea completamente nueva de negocios y los sistemas que la soportan. − Renovar el negocio existente – para cambiar completamente la forma de hacer negocios (reingeniería de procesos de negocios) • Tomar decisiones acerca de cómo continuar trabajando en la iteración actual y delinear cómo trabajar en iteraciones siguientes con los artefactos de modelamiento de negocios. Comprende las siguientes actividades: • Capturar un Vocabulario de Negocios común. Definir un vocabulario común que pueda ser usado en todas las descripciones textual el negocio, especialmente en las descripciones de los Casos de Uso. • Mantener las Reglas del Negocio. Determinar qué reglas del negocio se van a considerar en el proyecto. Dar definiciones detalladas a las reglas del negocio. • Definir la Arquitectura del Negocio. Comprender las fuerzas que afectan al negocio significativamente. Definir una arquitectura para el negocio. Definir los patrones, mecanismos clave y convenciones de modelamiento para el negocio. • Evaluar la Organización Objetivo. Describir es estado actual de la organización la cual la aplicación va a ser desplegada en términos de sus procesos actuales, herramientas, competencias de la gente, actitudes de la gente, clientes, competidores, tendencias técnicas, problemas y áreas de movimiento. Motivar porqué la organización objetivo debe ser mejorada y; para identificar a los stakeholders el esfuerzo del modelamiento del negocio. • Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento. Desarrollar una visión de la futura organización objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders.
  12. 12. - 12 - • Identificar las Metas del Negocio. Identificar los objetivos con los cuales el negocio puede ser planeado y manejado. Alinear entre los objetivos a largo plazo y los objetivos a corto plazo. Trasladar la estrategia del negocio a la acción y; para proveer de una base para medir y mejorar las actividades del negocio. El principal artefacto producido es la Visión del Negocio. Describir el Negocio Actual El propósito de este Workflow de detalle es entender los procesos y estructura de la organización para describir la organización objetivo brevemente y priorizar las partes de la organización objetivo en que se enfocarán por el resto del proyecto. Comprende las siguientes actividades: • Evaluar la Organización Objetivo. Describir el estado actual de la organización la cual la aplicación va a ser desplegada en términos de sus procesos actuales, herramientas, competencias de la gente, actitudes de la gente, clientes, competidores, tendencias técnicas, problemas y áreas de movimiento. Motivar porqué la organización objetivo debe ser mejorada y; para identificar a los stakeholders el esfuerzo del modelamiento del negocio. • Capturar un Vocabulario de Negocios común. Definir un vocabulario común que pueda ser usado en todas las descripciones textual el negocio, especialmente en las descripciones de los Casos de Uso. • Definir la Arquitectura del Negocio. Comprender las fuerzas que afectan al negocio significativamente. Definir una arquitectura para el negocio. Definir los patrones, mecanismos clave y convenciones de modelamiento para el negocio. • Mantener las Reglas del Negocio. Determinar qué reglas del negocio se van a considerar en el proyecto. Dar definiciones detalladas a las reglas del negocio. • Identificar los Objetivos del Negocio. Identificar los objetivos con los cuales el negocio puede ser planeado y manejado. Alinear entre los objetivos a largo plazo y los objetivos a corto plazo. Trasladar la estrategia del negocio a la acción y; para proveer de una base para medir y mejorar las actividades del negocio. • Encontrar Actores y Casos de Uso del Negocio. Definir las fronteras el negocio a ser modelado. Definir quién y qué va a interactuar con el negocio. Bosquejar los procesos en el negocio. Crear diagramas del Modelo de Caso de Uso del Negocio. Desarrollar un panorama del Modelo de Caso de Uso del Negocio. • Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento. Desarrollar una visión de la futura organización objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders. • Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y eventos en el negocio. Describir cómo las realizaciones de Casos de Uso del Negocio son efectuadas por los trabajadores y las entidades del negocio. El principal artefacto producido es una Visión del Negocio refinada. Identificar los Procesos del Negocio Dentro del equipo, los miembros deberían llegar a un entendimiento común de las
  13. 13. - 13 - fronteras del negocio que están modelando. También, necesitan decidir cuáles procesos dentro de esas fronteras serán descritos en más detalle. El propósito de este Workflow de detalle es decidir la terminología, delinear el Modelo de Caso de Uso del Negocio y priorizar cuáles Casos de Uso del Negocio serán descritos en detalle. Comprende las siguientes actividades: • Mantener las Reglas del Negocio. Determinar qué reglas del negocio se van a considerar en el proyecto. Dar definiciones detalladas a las reglas del negocio. • Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento. Desarrollar una visión de la futura organización objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders. • Definir la Arquitectura del Negocio. Comprender las fuerzas que afectan al negocio significativamente. Definir una arquitectura para el negocio. Definir los patrones, mecanismos clave y convenciones de modelamiento para el negocio. • Capturar un Vocabulario de Negocios común. Definir un vocabulario común que pueda ser usado en todas las descripciones textual el negocio, especialmente en las descripciones de los Casos de Uso. • Identificar los Objetivos del Negocio. Identificar los objetivos con los cuales el negocio puede ser planeado y manejado. Alinear entre los objetivos a largo plazo y los objetivos a corto plazo. Trasladar la estrategia del negocio a la acción y; para proveer de una base para medir y mejorar las actividades del negocio. • Encontrar Actores y Casos de Uso del Negocio. Definir las fronteras el negocio a ser modelado. Definir quién y qué va a interactuar con el negocio. Bosquejar los procesos en el negocio. Crear diagramas del Modelo de Caso de Uso del Negocio. Desarrollar un panorama del Modelo de Caso de Uso del Negocio. Los principales artefactos producidos son el Glosario del Negocio y los Casos de Uso del Negocio del alto nivel. Refinar las Definiciones de los Procesos del Negocio Cada Caso de Uso del Negocio será asignado a un miembro del equipo. Esa persona completará la definición del Caso de Uso del Negocio y liderará una sesión de revisión para el Caso de Uso del Negocio. El propósito de este Workflow de detalle es describir los casos de uso del negocio en detalle y verificar que el Caso de Uso del Negocio refleja correctamente cómo se hace el negocio. Comprende las siguientes actividades: • Estructurar el Modelo de Caso de Uso del Negocio. Extraer el comportamiento en los Casos de Uso del Negocio que necesitan ser considerados como Casos de Uso del Negocio abstractos. Ejemplos de tales comportamientos con comportamientos comunes, opcionales y comportamientos que van a ser desarrollados en iteraciones
  14. 14. - 14 - posteriores. Encontrar nuevos actores del negocio que definen roles que son compartidos por varios actores del negocio. • Detallar el Caso de Uso del Negocio. Describir en detalle el workflow del Caso de Uso del Negocio. Asegurar que el Caso de Uso del Negocio soporta la estrategia del negocio. Asegurar que los clientes, usuarios y stakeholders puedan entender el workflow del Caso de Uso del Negocio. • Revisar el Modelo de Caso de Uso del Negocio. Verificar formalmente que los resultados del modelamiento de Casos de Uso del Negocio estén conforme a los puntos de vista de los stakeholders. El principal artefacto producido son los Casos de Uso del Negocio detallados. Diseñar las Realizaciones de los Procesos del Negocio El propósito de este Workflow de detalle es identificar los roles, productos, entregables y eventos en el negocio y describir cómo un Caso de Uso del Negocio en particular es realizado dentro del Modelo de Objetos del Negocio en términos de objetos colaboradores (instancias de trabajadores y entidades del negocio). Comprende las siguientes actividades: • Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y eventos en el negocio. Describir cómo las realizaciones de Casos de Uso del Negocio son efectuadas por los trabajadores y las entidades del negocio. • Capturar un Vocabulario de Negocios común. Definir un vocabulario común que pueda ser usado en todas las descripciones textual el negocio, especialmente en las descripciones de los Casos de Uso. • Mantener las Reglas del Negocio. Determinar qué reglas del negocio se van a considerar en el proyecto. Dar definiciones detalladas a las reglas del negocio. • Definir la Arquitectura del Negocio. Comprender las fuerzas que afectan al negocio significativamente. Definir una arquitectura para el negocio. Definir los patrones, mecanismos clave y convenciones de modelamiento para el negocio. El principal artefacto producido es el Modelo de Objetos del Negocio. Refinar los Roles y las Responsabilidades El propósito de este Workflow de detalle es detallar la definición de una entidad del negocio para detallar las responsabilidades de un trabajador del negocio y verificar formalmente que los resultados del modelamiento del objetivo del negocio estén conforme con la visión que tienen los stakeholders del negocio. Comprende las siguientes actividades: • Detallar a los Trabajadores del Negocio. Describir las responsabilidades de los trabajadores del negocio. Identificar los requerimientos de competencia de un trabajador del negocio para que el trabajador del negocio sea capaz de cumplir con sus responsabilidades. • Detallar las Entidades del Negocio. Asegurar que la entidad del negocio es capaz de
  15. 15. - 15 - proveer del comportamiento requerido. Identificar los eventos del negocio disparados por la entidad del negocio. Evaluar las relaciones estructurales entre las entidades del negocio. • Revisar el Modelo de Análisis del Negocio. Verificar formalmente que los resultados del modelamiento de análisis del negocio estén conforme a los puntos de vista del negocio de los stakeholders. Los principales artefactos producidos son los Trabajadores del Negocio y las Entidades del Negocio, en detalle. Explorar la Automatización de Procesos El propósito de este Workflow de detalle es explorar qué partes de los procesos del negocio serán automatizados, entender cómo los sistemas existentes encajan en la organización y derivar los requerimientos del sistema. Comprende las siguientes actividades: • Preparar y ajustar los Objetivos. Delimitar el esfuerzo del modelamiento. Desarrollar una visión de la futura organización objetivo. Ganar acuerdos en los objetivos del esfuerzo del modelamiento del negocio y; para definir expectativas realistas de los stakeholders. • Definir los requerimientos de Automatización. Comprender cómo las nuevas tecnologías pueden ser usadas para hacer que la organización objetivo sea más eficiente. Determinar el nivel de automatización en la organización objetivo. Derivar los requerimientos del sistema desde los artefactos de modelamiento del negocio.. El principal artefacto producido es las Especificaciones Suplementarias del Negocio. Desarrollar un Modelo de Dominio Usted puede decidir elaborar un Modelo de Objetos del Negocio “incompleto”, enfocándose en explicar productos, entregables o eventos que son importantes para el dominio del negocio. Este modelo no incluye las responsabilidades que tiene la gente y a menudo es referido como un modelo de dominio. El propósito de este Workflow de detalle alternativo es identificar todos los productos, entregables y eventos importantes para el dominio del negocio, describir la entidad negocio en detalle y verificar formalmente que los resultados del modelamiento del objetivo del negocio estén conforme con la visión que tienen los stakeholders del negocio. Comprende las siguientes actividades: • Capturar un Vocabulario de Negocios común. Definir un vocabulario común que pueda ser usado en todas las descripciones textual el negocio, especialmente en las descripciones de los Casos de Uso. • Mantener las Reglas del Negocio. Determinar qué reglas del negocio se van a considerar en el proyecto. Dar definiciones detalladas a las reglas del negocio. • Encontrar Trabajadores y Entidades del Negocio. Identificar los roles, entregables y
  16. 16. - 16 - eventos en el negocio. Describir cómo las realizaciones de Casos de Uso del Negocio son efectuadas por los trabajadores y las entidades del negocio. • Detallar las Entidades del Negocio. Asegurar que la entidad del negocio es capaz de proveer del comportamiento requerido. Identificar los eventos del negocio disparados por la entidad del negocio. Evaluar las relaciones estructurales entre las entidades del negocio. • Revisar el Modelo de Análisis del Negocio. Verificar formalmente que los resultados del modelamiento de análisis del negocio estén conforme a los puntos de vista del negocio de los stakeholders. El principal artefacto producido es el Modelo de Dominio. 3.1.3 Configuración y Notas sobre el Workflow de Modelamiento de Negocios RUP/Easy adoptó por el escenario renovar el negocio (reingeniería de procesos de negocios). Renovar es un escenario de modelamiento de negocios. Es una de las opciones listadas en la Sección 3.1.2. esta opción fue escogida porque RUP/Easy típicamente asiste a las organizaciones con reingeniería en sus procesos de negocio para que provean un mejor servicio a sus clientes. La variación metodológica de RUP/Easy al Workflow de Modelamiento de Negocios no incluye las actividades Desarrollar las Realizaciones de Diseño de los Procesos del Negocio (Develop the Design Business Process Realizations), Refinar los Roles y las Responsabilidades (Refine Roles y Responsibilities), Desarrollar un Artefacto de Diseño de Dominio (Develop a Domain Model artefacto) y actividades y artefactos relativos al Modelo de Objetos del Negocio. La variación metodológica de RUP/Easy no incluye el desarrollo del Modelo de Objetivo durante el Workflow de Requerimientos (ver la Sección 3.2). 3.1.4 Artefactos para el Modelamiento de Negocios Los artefactos para el Modelamiento de Negocios sirven como input a, y referenciados por, los requerimientos del sistema. La Tabla 5 identifica los artefactos que deberían ser desarrollados cuando se hace modelamiento de negocios. Tabla 5. Artefactos para el Modelamiento de Negocios Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Actor del Negocio X Formal - Interno Rational Rose Glosario del Negocio X Formal - Externo Requisite Pro, MS Word Reglas del Negocio X Formal - Externo Requisite Pro, MS Word Caso de Uso del Negocio X Formal - Externo Requisite Pro, MS Word Modelo de Casos de Uso del Negocio X Formal - Externo Rational Rose Visión del Negocio X Formal - Externo Requisite Pro, MS Word
  17. 17. - 17 - Unidad de la Organización X Rational Rose Especificación Suplementaria del Negocio X Formal -Externo Requisite Pro, MS Word Valorización de la Organización Objetivo X Formal -Externo Requisite Pro, MS Word 3.1.5 Notas sobre los Artefactos para el Modelamiento de Negocios La variación metodológica de RUP/Easy no incluye la creación de estos Artefactos para el Modelamiento de Negocios: Documento de Arquitectura del Negocio (Business Architecture Document), Entidad del Negocio (Business Entity), Modelo de Objetos del Negocio (Business Object Model), Realización del Caso de Uso del Negocio (Business Use-Case Realization) y Trabajador del Negocio (Business Worker). El artefacto Unidad de la Organización (Organization Unit) no necesita incluir a las Entidades del Negocio y a los Trabajadores del Negocio. 3.1.6 Reportes para el Modelamiento de Negocios La Tabla 6 identifica los reportes que la metodología de RUP/Easy recomienda que sean elaborados durante el Modelamiento de Negocios. Tabla 6. Reportes para el Workflow de Modelamiento de Negocios Reportes Herramientas Usadas Panorama del Modelo de Casos de Uso del Negocio Rational SoDA, MS Word 3.1.7 Notas sobre los Reportes para el Modelamiento de Negocios La variación metodológica de RUP/Easy no incluye la creación de estos Reportes para el Modelamiento de Negocios: Entidad del Negocio (Business Entity), Caso de Uso del Negocio (Business Use-Case), Realización del Caso de Uso del Negocio (Business Use- Case Model Realization) y Trabajador del Negocio (Bussines Worker). En RUP/Easy creemos que el Panorama del Modelo de Caso de Uso del Negocio (Business Use-Case Model Survey) cubre todo acerca del esfuerzo para el Modelamiento de Negocios. 3.1.8 Sumario El Modelamiento del Negocio debería hacerse antes del desarrollo de software para obtener un buen entendimiento de sus procesos del negocio. Si los arquitectos y los desarrolladores no entienden los procesos del negocio, ellos no podrán construir el sistema apropiado. El Modelamiento de Negocios con UML permite a los analistas modelar los procesos del negocio usando los mismos símbolos, diagramas y otras formas de notación que los equipos de desarrollo de software utilizan para modelar los sistemas para crear o automatizar los procesos del negocio. La habilidad de trabajar usando un lenguaje común permite algo que antes no era posible en el desarrollo de software: comunicación entre la gente del negocio y la gente de sistemas.
  18. 18. - 18 - Sin embargo, el Modelamiento del Negocio sólo debe ser efectuado si se está cambiando la manera en que se hace negocio. Si sólo se está añadiendo una nueva característica a un sistema existente, entonces RUP/Easy no recomienda que usted empiece con un modelamiento del negocio. En ese caso, RUP/Easy recomienda que usted empiece con la Sección 3.2, Requerimientos. 3.2 REQUERIMIENTOS Se debería manejar las generaciones (versiones) de requerimientos y su documentación. La Administración de Requerimientos incorpora la identificación, organización y documentación de los cambios a los requerimientos en un proyecto. Es una parte integral de la actividad de desarrollo de software. La Administración de Requerimientos establece un entendimiento común y acuerdo entre el cliente y el equipo del proyecto acerca de los requerimientos del cliente. Una Administración de Requerimientos efectiva incluye el mantener requerimientos claros. Mantener atributos acerca de los requerimientos (tales como estado, prioridad), proveer seguimiento a otros requerimientos y componentes y, proveer de los recursos adecuados y fondos para administrar los requerimientos. 3.2.1 Vista general del Workflow de Requerimientos El propósito del Workflow de Requerimientos es: • Establecer y mantener acuerdos con los clientes y otros stakeholders acerca de lo que el sistema debe hacer • Proveer a los desarrolladores del sistema con un mejor entendimientos de los requerimientos del sistema • Definir las fronteras del sistema (delimitarlo) • Proveer de una base para planificar el contenido técnico de la iteraciones • Proveer de una base para estimar el costo y el tiempo para desarrollar el sistema • Definirle al sistema una interfase para el usuario enfocándose en las necesidades y objetivos de los usuarios Los artefactos clave a desarrollar son: Visión, Modelo de Casos de Uso, Casos de Uso y Especificaciones Suplementarias. Estos artefactos describen lo que el sistema debe hacer. El Workflow de Requerimientos está relacionado a otros workflows del RUP: • El Workflow de Modelamiento de Negocios provee las reglas del negocio y un Modelo de Caso de Uso del Negocio. • El input principal para el Workflow de Análisis y Diseño son el Modelo de Casos de Uso y el Glosario creados durante el Workflow de Requerimientos. Por las fallas que se descubran en el Modelo de Casos de Uso, se generará Requerimientos de Cambio. • El Workflow de Pruebas prueba el sistema para verificar el código contra el Modelo de Casos de Uso, los Casos de Uso y las Especificaciones Suplementarias. • El Workflow de Administración de Configuración y Cambios provee los
  19. 19. - 19 - mecanismos de control de cambios para los requerimientos. Los workflows de Requerimientos consisten de los siguientes workflows de detalle: • Analizar el Problema • Entender las Necesidades del Stakeholder • Definir el Sistema • Administrar el Alcance del Sistema • Refinar la Definición del Sistema • Administrar los Requerimientos de Cambios Workflow de Requerimientos Analizar el Problema El propósito de este Workflow de detalle es: • Obtener control y acuerdos sobre el problema que se va a resolver • Identificar a los stakeholders, quienes son las personas que pueden ser afectadas materialmente por la implementación de un sistema o aplicación y, a los usuarios • Definir las fronteras del sistema, las cuales son los bordes entre la solución del problema y el mundo real que rodea a la solución. • Identificar las restricciones impuestas al sistema tales como horarios y recursos, decisiones técnicas, restricciones económicas, etc. El primer paso es asegurarse que todas las partes involucradas acuerdan en el problema
  20. 20. - 20 - que están tratando de resolver con el nuevo sistema. Para evitar malos entendidos, un glosario es creado para proveer de una terminología común, el cual será utilizado durante todo el proyecto. Este glosario será mantenido durante todo el ciclo de vida del proyecto. Para entender completamente los problemas que están siendo considerados, es importante que conozca a sus stakeholders. Los Actores en sus Casos de Uso representarán a algunos de los stakeholders – los usuarios del sistema. Comprende las siguientes actividades: • Capturar un vocabulario común. Definir un vocabulario común que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los Casos de Uso. • Desarrollar el Plan de Administración de Requerimientos. Desarrollar un plan para documentar los requerimientos, sus atributos y guías para rastreabilidad y administración de los requerimientos el producto. • Encontrar Actores y Casos de Uso. Definir el alcance del sistema, es decir, qué será manejado por el sistema y qué será manejado fuera del sistema. Definir quién y qué va a interactuar con el sistema. Bosquejar la funcionalidad del sistema. • Asignar los Casos de Uso a los Analistas para que describan en detalle los más importantes. Los menos importantes serán revisados en las fases posteriores. No olvidar que los Casos de Uso menos importantes, no necesariamente deben ser descritos en detalle pues, podría bastar con la descripción inicial. • Desarrollar la Visión. Obtener un acuerdo sobre qué problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las características primarias del sistema. La Visión debe dejar en claro a los stakeholders lo siguiente: − Los beneficios y las oportunidades que obtendrán desarrollando el sistema. − El (Los) problema(s) que resolverá el sistema. − Se define a los usuarios objetivo?. − A muy alto nivel, se define lo que hará el sistema expresado en términos muy generales o explicando unos pocos casos de uso importantes. − Algunos de los requerimientos no funcionales que sean esenciales, tales como Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad, escalabilidad y calidad. − Licenciamiento y precios, si es aplicable. La Visión debe estar completa y estable al finalizar la Fase de Incepción; sin embargo, se puede afinar durante la Fase de Elaboración. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conocía o no sabía nada. El documento Visión es el principal artefacto en el cual el análisis del problema es documentado. Entender las Necesidades del Stakeholder El propósito de este Workflow de detalle es coleccionar y obtener la información de los stakeholders para entender cuáles son sus necesidades. La actividad clave es obtener los requerimientos de los stakeholder usando input tales
  21. 21. - 21 - como reglas del negocio, requerimientos de mejora, entrevistas y workshops de requerimientos. Comprende las siguientes actividades: • Capturar un vocabulario común. Definir un vocabulario común que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los Casos de Uso. • Desarrollar la Visión. Obtener un acuerdo sobre qué problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las características primarias del sistema. La Visión debe dejar en claro a los stakeholders lo siguiente: − Los beneficios y las oportunidades que obtendrán desarrollando el sistema. − El (Los) problema(s) que resolverá el sistema. − Se define a los usuarios objetivo?. − A muy alto nivel, se define lo que hará el sistema expresado en términos muy generales o explicando unos pocos casos de uso importantes. − Algunos de los requerimientos no funcionales que sean esenciales, tales como Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad, escalabilidad y calidad. − Licenciamiento y precios, si es aplicable. La Visión debe estar completa y estable al finalizar la Fase de Incepción; sin embargo, se puede afinar durante la Fase de Elaboración. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conocía o no sabía nada. • Obtener los Requerimientos de los Stakeholders. Comprender quienes son los stakeholders del proyecto. Recolectar los requerimientos de qué necesidades el sistema debe cubrir. Priorizar los requerimientos de los stakeholders. • Encontrar Actores y Casos de Uso. Definir el alcance del sistema, es decir, qué será manejado por el sistema y qué será manejado fuera del sistema. Definir quién y qué va a interactuar con el sistema. Bosquejar la funcionalidad del sistema. • Asignar los Casos de Uso a los Analistas para que describan en detalle los más importantes. Los menos importantes serán revisados en las fases posteriores. No olvidar que los Casos de Uso menos importantes, no necesariamente deben ser descritos en detalle pues, podría bastar con la descripción inicial. • Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administración del alcance del proyecto y administración de cambios en los requerimientos. El artefacto principal es un documento refinado de la Visión. También los requerimientos son discutidos y expresados en términos de Casos de Uso y Actores. Los requerimientos no funcionales, que no caen fácilmente en el Modelo de Casos de Uso deberán ser documentados en los documentos de Especificaciones Suplementarias. Definir el Sistema El propósito de este Workflow de detalle es: • Alinear al equipo del proyecto en su comprensión del nuevo sistema.
  22. 22. - 22 - • Efectuar un análisis de alto nivel a los resultados de los requerimientos recolectados a los stakeholder. • Refinar el documento Visión para incluir todas las características el nuevo sistema. • Refinar el Modelo de Caso de Uso y incluir los casos de uso bosquejados. • Documentar formalmente los resultados en modelo s y documentos. Comprende las siguientes actividades: • Capturar un vocabulario común. Definir un vocabulario común que pueda ser usado en todas las descripciones textuales del sistema, especialmente en las descripciones de los Casos de Uso. • Desarrollar la Visión. Obtener un acuerdo sobre qué problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las características primarias del sistema. La Visión debe dejar en claro a los stakeholders lo siguiente: − Los beneficios y las oportunidades que obtendrán desarrollando el sistema. − El (Los) problema(s) que resolverá el sistema. − Se define a los usuarios objetivo?. − A muy alto nivel, se define lo que hará el sistema expresado en términos muy generales o explicando unos pocos casos de uso importantes. − Algunos de los requerimientos no funcionales que sean esenciales, tales como Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad, escalabilidad y calidad. − Licenciamiento y precios, si es aplicable. La Visión debe estar completa y estable al finalizar la Fase de Incepción; sin embargo, se puede afinar durante la Fase de Elaboración. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conocía o no sabía nada. • Encontrar Actores y Casos de Uso. Definir el alcance del sistema, es decir, qué será manejado por el sistema y qué será manejado fuera del sistema. Definir quién y qué va a interactuar con el sistema. Bosquejar la funcionalidad del sistema. Asignar los Casos de Uso a los Analistas para que describan en detalle los más importantes. Los menos importantes serán revisados en las fases posteriores. No olvidar que los Casos de Uso menos importantes, no necesariamente deben ser descritos en detalle pues, podría bastar con la descripción inicial. • Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administración del alcance del proyecto y administración de cambios en los requerimientos. En Definir el Sistema, se enfoca en identificar a los actores y los casos de uso más completamente y expandir los requerimientos no funcionales definidos en los documentos de especificaciones suplementarias. Administrar el Alcance del Sistema El propósito de este Workflow de detalle es: • Priorizar y refinar la selección de características y requerimientos que van a ser incluidos en la iteración actual.
  23. 23. - 23 - • Definir el conjunto de Casos de Uso (o Escenarios) que representan la funcionalidad central. • Definir cuáles atributos de requerimientos y características de rastreo serán mantenidos. El alcance del proyecto es definido por el conjunto de requerimientos definidos para éste. La clave para manejar un proyecto exitoso es administrar el alcance del proyecto para cumpliendo con los recursos disponibles tales como el tiempo, la gente y el dinero. Los atributos de requerimientos, tales como prioridad, esfuerzo y riesgo, son una técnica útil para manejar el alcance del proyecto. Comprende las siguientes actividades: • Priorizar los Casos de Uso. Definir el input a la selección o al conjunto de escenarios y Casos de Uso que van a ser analizados en la iteración actual. Definir el conjunto de escenarios y casos de Uso que representan alguna funcionalidad central y significativa. Definir el conjunto de escenarios y Casos de Uso que tienen una cobertura arquitectural sustancial (que ejercitan muchos elementos arquitecturales) o que realzan o ilustran un punto específico, delicado de la arquitectura. • Desarrollar la Visión. Obtener un acuerdo sobre qué problemas necesitan ser resueltos. Identificar a los stakeholders del sistema. Definir las fronteras del sistema. Describir las características primarias del sistema. La Visión debe dejar en claro a los stakeholders lo siguiente: − Los beneficios y las oportunidades que obtendrán desarrollando el sistema. − El (Los) problema(s) que resolverá el sistema. − Se define a los usuarios objetivo?. − A muy alto nivel, se define lo que hará el sistema expresado en términos muy generales o explicando unos pocos casos de uso importantes. − Algunos de los requerimientos no funcionales que sean esenciales, tales como Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad, escalabilidad y calidad. − Licenciamiento y precios, si es aplicable. La Visión debe estar completa y estable al finalizar la Fase de Incepción; sin embargo, se puede afinar durante la Fase de Elaboración. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conocía o no sabía nada. • Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administración del alcance del proyecto y administración de cambios en los requerimientos. Refinar la Definición del Sistema El propósito de este Workflow de detalle es: • Refinar aún más los requerimientos para describir el flujo de eventos de los Casos de Uso en detalle, detallar las Especificaciones Suplementarias, desarrollar una Especificación de requerimientos de Software, si se necesita más detalle • Modelar y prototipear la interfase con el usuario.
  24. 24. - 24 - Comprende las siguientes actividades: • Detallar los Casos de uso. Describir uno o más de los flujos de eventos de los casos de uso en suficiente detalle para permitir que empiece el desarrollo de software en él. Describir la especificación de Caso de Uso para el entendimiento y satisfacción del actor representativo o cliente. • Detallar los Requerimientos de Software. Coleccionar, detallar y organizar el conjunto (paquete) de artefactos que describen completamente los requerimientos de software del sistema o subsistema. Refinar la Definición del Sistema comienza con detallar los Casos de Uso, describiendo los Actores y profundizar el entendimiento del alcance del proyecto. El output de este Workflow del RUP es una comprensión más profunda de la funcionalidad del sistema expresada en Casos de Uso detallados y documentos de Especificaciones Suplementarias detallados. Si es necesario, una Especificación de Requerimientos de Software formal puede ser desarrollado, además de los documentos detallados de Casos de Uso y Especificaciones Suplementarias. Administrar los Requerimientos de Cambios El propósito de este Workflow de detalle es: • Evaluar los requerimientos de cambio enviados para determinar su impacto en los requerimientos existentes • Construir el Modelo de Casos de Uso • Desarrollar la relación entre los atributos y la rastreabilidad de los requerimientos. • Verificar que los resultados del Workflow de Requerimientos estén conforme con la visión del sistema que tiene el usuario. Comprende las siguientes actividades: • Estructurar el Modelo de Caso de Uso. Extraer el comportamiento en los Casos de Uso que necesitan ser considerados como Casos de Uso abstractos. Ejemplos de tales comportamientos con comportamientos comunes, opcionales y comportamientos que van a ser desarrollados en iteraciones posteriores. Encontrar nuevos actores que definen roles que son compartidos por varios actores. El Modelo de Caso de Uso es un modelo de las funciones del sistema y su ambiente; sirve como un contrato entre el cliente y los desarrolladores. El Modelo de Caso de Uso es usado como un input esencial para las actividades de análisis, diseño y pruebas. • Manejar las Dependencias. Usar atributos y rastreabilidad de los requerimientos del proyecto para asistir en la administración del alcance del proyecto y administración de cambios en los requerimientos. • Revisar los requerimientos. Verificar formalmente que los resultados de los requerimientos estén conforme con el punto de vista que los clientes tienen del sistema. Los cambios a los requerimientos impactan los modelos producidos en el Workflow de Análisis y Diseño, el modelo de pruebas creado en el Workflow de Pruebas y el material de soporte al usuario final del Workflow de Despliegue. Las relaciones de rastreabilidad
  25. 25. - 25 - son establecidas para identificar las relaciones entre los requerimientos y otros artefactos. Las relaciones de rastreabilidad son la clave para entender el impacto del cambio de los requerimientos. 3.2.2 Configuración y Notas sobre el Workflow de Requerimientos Cada actividad en el Workflow de Requerimientos es esencial para una implementación exitosa. Ninguna actividad debe ser removida del Workflow de Requerimientos. 3.2.3 Artefactos de Requerimientos Los Artefactos de Requerimientos capturan y presentan información usada en definir las capacidades requeridas por el sistema. La Tabla 7 identifica los artefactos que debe ser desarrollados cuando se captura los requerimientos del sistema. Tabla 7. Artefactos para el Workflow de Requerimientos Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Actor X X Informal Rational Rose Glosario X X Formal-Externo Requisite Pro; MS Word Lista de Riesgos X Formal-Externo Requisite Pro Especificación Suplementaria X X Formal-Externo Requisite Pro; MS Word Caso de Uso X X Formal-Externo Rational Rose; Requisite Pro; MS Word Modelo de Caso de Uso X X Formal-Externo Rational Rose Vision Formal-Externo Requisite Pro; MS Word 3.2.4 Notas sobre los Artefactos de Requerimientos La Lista de Riesgos es un artefacto independiente; pero en un proyecto pequeño se puede incluir en el Plan de Desarrollo de Software con todo el detalle correspondiente: . Magnitud del Riesgo o Ranking . Descripción . Impactos . Indicadores . Estrategia de Mitigación . Plan de Contingencia La Lista de Riesgos se va actualizando a los largo del proyecto según los riesgos se vayan eliminando o, aparezcan nuevos riesgos. Tomar en cuenta lo siguiente: • Actualizarla al término de una iteración. • Mayormente un requerimiento de cambio implica un riesgo el cual deberá incluirse en la Lista de Riesgos. • Conforme avanza el proyecto se van eliminando los riesgos, es necesario actualizar la lista para indicarlo.
  26. 26. - 26 - La Visión debe dejar en claro a los stakeholders lo siguiente: • Los beneficios y las oportunidades que obtendrán desarrollando el sistema. • El (Los) problema(s) que resolverá el sistema. • Se define a los usuarios objetivo?. • A muy alto nivel, se define lo que hará el sistema expresado en términos muy generales o explicando unos pocos casos de uso importantes. Es decir, una Lista de Requerimientos del software. • Algunos de los requerimientos no funcionales que sean esenciales, tales como Sistemas Operativos, Manejador de Base de datos, requerimientos de seguridad, escalabilidad y calidad. Esto es, equivalente a los artefactos Infraestructura de Desarrollo (Development Infraestructura) y Herramientas (Tools). • Licenciamiento y precios, si es aplicable. La Visión contiene los requerimientos generales; pero los requerimientos detallados del software se encuentran definidos en el Documento de Arquitectura del Software. La Visión debe estar completa y estable al finalizar esta Fase de Inicio; sin embargo, se puede afinar durante la Fase de Elaboración. Este documento debe ser enviado a todos los stakeholder y usuarios principales, de tal manera que ninguno pueda decir que no lo conocía o no sabía nada. La variación metodológica de RUP/Easy no incluye la creación de estos Artefactos de Requerimientos: Clase Frontera (Boundary Class), Storyboard de Casos de Uso (Use- Case Storyboard) y Prototipo de la Interfase con el Usuario (User-Interfase Prototype). Tampoco incluye: Atributos de Requerimientos (Requeriment Attributes), Plan de Administración de Requerimientos (Requeriment Management Plan), Requerimientos del Stakeholder (Stakeholder Requeriments), Paquete de Caso de Uso (Use-Case Package), Especificación de Requerimientos de Software (Software Requeriments Specification). Este último no es necesario debido a que los requerimientos globales se definen en la Visión y los requerimientos del software se definen en el Documento de Arquitectura del Software. 3.2.5 Reportes de Requerimientos La variación metodológica de RUP/Easy considera opcionales todos los reportes de requerimientos; sin embargo, si van a usarse, la Tabla 8 identifica los reportes que deben ser producidos durante el Workflow de Requerimientos. El Panorama del Modelo de Casos de Uso (Use-Case Model Survey) es muy comprensible y cubre la mayoría de la información contenida en los reportes de Actores y Casos de Uso. Tabla 8. Reportes para el Workflow de Requerimientos Reportes Herramientas Usadas Panorama del Modelo de Caso de Uso Rational SoDA; MS Word 3.2.6 Notas sobre los Reportes de Requerimientos
  27. 27. - 27 - La variación metodológica de RUP/Easy no incluye la creación del reporte Storyboard de Casos de Uso. Tampoco incluye Los reportes de Actores y Casos de Uso. 3.3 ANÁLISIS Y DISEÑO El propósito del Workflow de Análisis y Diseño es empezar a realizar los casos de uso desarrollados durante el Workflow de Requerimientos. Es decir, tomar el Modelo de Casos de Uso, el Glosario y las Especificaciones Suplementarias creadas en el Workflow de Requerimientos y generar un modelo de diseño que pueda ser usado por los desarrolladores durante el Workflow de Implementación. El Análisis se enfoca en trasladar los requerimientos funcionales a conceptos de software. 3.3.1 Vista General del Workflow de Análisis y Diseño El propósito del Workflow de Análisis y Diseño es: • Transformar los requerimientos en un diseño del sistema a crear • Definir una arquitectura robusta para el sistema • Adaptar el diseño para que funcione en el ambiente de implementación diseñándolo para obtener buena performance El Workflow de Análisis y Diseño toma los casos de uso documentados del Workflow de Requerimientos y del Workflow de Modelamiento de Negocios y los traslada a elementos de diseño que serán usados para construir el sistema. Por medio de usar varias actividades y modelos el Workflow de Análisis y Diseño busca destilar la información recogida de los stakeholders en información que los programadores podrán usar. Al final, un Modelo de Diseño y el documento de Arquitectura del Software describirán el sistema. El Workflow de Análisis y Diseño está relacionado a otros workflow del RUP como sigue: • El Workflow de Implementación usará el Modelo de Diseño y el documento de Arquitectura del Software como inputs en la construcción e implementación del sistema. • El Workflow de Pruebas usará las realizaciones de casos de Uso y el documento de Arquitectura del Software para probar la funcionalidad y la compatibilidad de los componentes. • El documento de Arquitectura del Software será usado por el Workflow de Despliegue para desplegar el sistema final. El Workflow de Análisis y Diseño consiste de los siguientes workflows de detalle: • Definir una Arquitectura candidata • Refinar la Arquitectura • Analizar el Comportamiento • Diseñar los Componentes • Diseñar la Base de Datos (opcional) - es efectuado durante cualquier iteración que requiere la demostración de datos persistentes
  28. 28. - 28 - Workflow de Análisis y Diseño Definir una Arquitectura candidata Este workflow es efectuado durante las iteraciones de las fases de Incepción y al inicio de la Elaboración. El propósito de este Workflow de detalle es: • Definir las fronteras arquitecturales a ser usada durante el análisis • Definir los mecanismos de análisis que serán importantes para el sistema (por ejemplo, persistencia, distribución, seguridad) • Definir cualquier Patrón de Arquitectura a ser usado. Esto proveerá de una arquitectura organizacional desde la cual los subsistemas, sus responsabilidades y sus relaciones con otros subsistemas pueden ser definidos. Comprende las siguientes actividades: • Análisis Arquitectural. Definir una arquitectura candidata para el sistema basada en la experiencia ganada de sistemas similares o dominios de problemas similares. Definir los patrones arquitecturales, mecanismos clave y convenciones de
  29. 29. - 29 - modelamiento para el sistema. • Análisis de Casos de Uso. Identificar las clases que efectúan el flujo de eventos de un Caso de Uso. Distribuir el comportamiento del Caso de Uso a esas clases, usando realizaciones de Caso de Uso. Identificar las responsabilidades, atributos y asociaciones de las clases. Notar el uso de los mecanismos arquitecturales. Refinar la Arquitectura Este workflow es efectuado durante las iteraciones del final de la fase de Elaboración y la fase de Construcción. El propósito de este Workflow de detalle es: • Identificar e incorporar elementos de diseño − Identificar clases de diseño y subsistemas. − Definir mecanismos de diseño e inventariar los mecanismos de implementación. − Refinar la arquitectura incorporando la reusabilidad siempre que sea posible. − Identificar interfases, clases de diseño y subsistemas de diseño. − Actualizar la arquitectura basado en los hallazgos en el modelo de diseño. • Describir la arquitectura de run-time y su distribución − Identificar y diseñar los procesos (ambiente de ejecución en el cual las clases y subsistemas residen y corren) y threads (ejecuciones computacionales independientes dentro del ambiente de ejecución). − Modelar procesos para el Plan de implementación de la configuración de la red por medio de identificar qué parte o partes del sistema serán ejecutados en nodos específicos o procesadores de cómputo. − Modelar la configuración de la red para describir la comunicación y el flujo de procesos entre los nodos. Identificar todos los recursos disponibles para correr el sistema. − Definir y modelar cómo, los procesos, pueden ser distribuidos en la configuración de la red para alcanzar los requerimientos tales como performance del sistema y disponibilidad. Comprende las siguientes actividades: • Identificar los Mecanismos de Diseño. Refinar los mecanismos de análisis en mecanismos de diseño basados en las restricciones impuestas por el ambiente de implementación. • Identificar los Elementos de Diseño. Analizar las interacciones de las clases de análisis para identificar los elementos del modelo de diseño. • Incorporar los Elementos de Diseño existentes. Analizar las interacciones de las clases de análisis para encontrar interfases, clases de diseño y subsistemas de diseño. Refinar la arquitectura, incorporar el reuso donde sea posible. Identificar soluciones comunes encontradas durante los problemas. Incluir arquitecturalmente elementos significativos del modelo de diseño en la sección Vista Lógica del Documentos de Arquitectura de Software. • Estructurar el Modelo de Implementación (desde la Implementación). Establecer la estructura en la cual la implementación residirá. Asignar responsabilidades para la
  30. 30. - 30 - implementación de los Subsistemas y sus contenidos. • Describir la Arquitectura de Run-Time. Analizar requerimientos de concurrencia, identificar procesos, identificar mecanismos de comunicación entre procesos, separa recursos de coordinación entre procesos, identificar ciclos de vida de procesos y distribuir elementos del modelo entre los procesos. • Describir la Distribución. Describir cómo la funcionalidad des sistema es distribuida entre los nodos físicos. Esta actividad se aplica sólo a los sistemas distribuidos. Analizar el Comportamiento Este workflow es efectuado durante las iteraciones en las fases de Incepción, Elaboración y Construcción. El propósito de este Workflow de detalle es: • Identificar las Clases de Análisis desde los Diagramas de Caso de Uso y las especificaciones de Caso de Uso. • Crear Diagramas de Interacción que modelen el comportamiento de los Casos de Uso. • Crear el Diagrama de Clases • Describir las relaciones y dependencias entre las Clases. Comprende las siguientes actividades: • Análisis de Casos de Uso. Identificar las clases que efectúan el flujo de eventos de un Caso de Uso. Distribuir el comportamiento del Caso de Uso a esas clases, usando realizaciones de Caso de Uso. Identificar las responsabilidades, atributos y asociaciones de las clases. Notar el uso de los mecanismos arquitecturales. • Identificar los Elementos de Diseño. Analizar las interacciones de las clases de análisis para identificar los elementos del modelo de diseño. • Revisar el Diseño. Verificar que el modelo de diseño cumple con los requerimientos del sistema y que sirve como una buena base para su implementación. Asegurar que el modelo de diseño es consistente con respecto a las guías de diseño general. Asegurar que las guías de diseño cumplen sus objetivos. • Diseñar la Interfase con el Usuario. Producir un diseño de la interfase con el usuario que soporte el razonamiento y las mejoras de su usabilidad. • Prototipear la Interfase con el Usuario. Prototipear la interfase con el usuario en un intento de validar el diseño de la interfase con el usuario contra los requerimientos funcionales y de uso. Diseñar los Componentes Este workflow es efectuado durante las iteraciones en las fases de Incepción, Elaboración y Construcción. Durante las iteraciones iniciales este workflow se enfocará más en los comportamientos significativos de la arquitectura. En las iteraciones de la fase de Construcción, el enfoque se mueve hacia completar y diseñar la consistencia de todos los comportamientos. El propósito de este Workflow de detalle es: • Refinar los Diagramas de Diseño usando subsistemas • Describir el comportamiento relativo a la persistencia • Unificar clases y subsistemas para posible reuso • Definir y distribuir el comportamiento y las dependencia de los subsistemas
  31. 31. - 31 - • Implementar los elementos de diseño como componentes Comprende las siguientes actividades: • Diseñar las Cápsulas. Elaborar y refinar las descripciones de una cápsula. • Diseñar los Casos de Uso. Refinar las Realizaciones de Casos de Uso en términos de interacciones. Refinar los requerimientos para las operaciones de las clases de diseño. Refinar los requerimientos para las operaciones de diseño de subsistemas y/o sus interfases. Refinar los requerimientos para las operaciones de las cápsulas. • Diseñar las Clases. Asegurar que las clases proveen el comportamiento que requieren las realizaciones de Casos de Uso. Asegurar que se tiene la suficiente información para implementar la clase sin ambigüedad. Manejar los requerimientos no funcionales relativos a la clase. Incorporar los mecanismos de diseño usados por la clase. • Diseñar los Elementos de Pruebas. Diseñar la funcionalidad específica para las pruebas. • Diseñar los Subsistemas. Definir los comportamientos especificados en las interfases del subsistema en términos de colaboraciones de elementos de diseño contenidos y subsistemas o interfases externas. Documentar la estructura interna del subsistema. Definir las realizaciones entre las interfases de los subsistemas y las clases contenidas. • Revisar el Diseño. Verificar que el modelo de diseño cumple con los requerimientos del sistema y que sirve como una buena base para su implementación. Asegurar que el modelo de diseño es consistente con respecto a las guías de diseño general. Asegurar que las guías de diseño cumplen sus objetivos. • Definir los Elementos de Pruebas. Definir los elementos necesarios para soportar los ítems de prueba objetivo. Identificar los elementos físicos de la infraestructura de implementación de las pruebas requeridos para posibilitar las pruebas bajo cada Configuración de Ambiente de Pruebas. Definir los requerimientos de software que serán necesarios para lograr que el software sea físicamente probado. Diseñar la base de Datos (Opcional) Este workflow del RUP es efectuado durante cualquier iteración que requiere la demostración de datos persistentes. El propósito de este Workflow de detalle es: • Crear el modelo de datos • Mapear las clases de diseño que contienen datos que van a ser persistentes, almacenados por más tiempo que la ejecución actual del sistema, con el modelo de datos • Distribuir el comportamiento de clase a la base de datos Comprende las siguientes actividades: • Diseñar las Clases. Asegurar que las clases proveen el comportamiento que requieren las realizaciones de Casos de Uso. Asegurar que se tiene la suficiente información para implementar la clase sin ambigüedad. Manejar los requerimientos no funcionales relativos a la clase. Incorporar los mecanismos de diseño usados por la clase.
  32. 32. - 32 - • Diseñar la Base de Datos. Asegurar que los datos persistentes estén almacenados consistentemente y eficientemente. Definir el comportamiento que debe ser implementado en la base de datos. • Revisar el Diseño. Verificar que el modelo de diseño cumple con los requerimientos del sistema y que sirve como una buena base para su implementación. Asegurar que el modelo de diseño es consistente con respecto a las guías de diseño general. Asegurar que las guías de diseño cumplen sus objetivos. 3.3.2 Configuración y Notas sobre el Workflow de Análisis y Diseño El Workflow de detalle Refinar la Arquitectura puede ser saltado si hay relativamente pocos riesgos arquitecturales. Esto es, el diseño, la implementación y la distribución del sistema no producen problemas arquitecturales significativos o el arquitecto de software tiene suficiente experiencia para manejar tales hechos. El Workflow de detalle Efectuar Síntesis Arquitectural puede ser saltado. Este Workflow de detalle puede ser efectuado si es que se necesita profundizar los conceptos. Los workflows de detalle Diseñar Componente de Tiempo Real y Diseñar Componente [No – Tiempo Real] son similares con la excepción de que el primero se enfoca en componentes que son para sistemas en tiempo real y el otro para sistemas reactivos. 3.3.3 Artefactos para Análisis y Diseño Los Artefactos para Análisis y Diseño capturan y presentan información relativa a la solución de los problemas planteados durante el Workflow de Requerimientos. La Tabla 9 identifica los artefactos que deberán producirse durante el Workflow de Análisis y Diseño. Tabla 9. Artefactos para el Workflow de Análisis y Diseño Artefactos Creado / Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Clase de Análisis X X Informal - Interno Rational Rose Modelo de Análisis y Diseño X X X Formal - Externo Rational Rose Modelo de Despliegue X X Formal - Externo RequistePro; MS Word Modelo de Datos X X Informal - Interno Rational Rose Clase de Diseño X X Informal - Interno Rational Rose Paquete de Diseño X X Informal - Interno Rational Rose Subsistema de Diseño X X Informal - Interno Rational Rose Documento de Arquitectura del Software X X X Formal - Externo RequistePro; MS Word Realización de Caso de Uso X X Informal - Interno RequistePro; MS Word; Rational Rose
  33. 33. - 33 - 3.3.4 Notas sobre los Artefactos para Análisis y Diseño El Modelo de Análisis y Diseño puede ser mantenido como dos modelos separados, donde el modelo de análisis muestra sólo nombres de clases de análisis y, el modelo de diseño muestra clases de análisis detalladas y clases de diseño arquitectural. Mantener los modelos por separado se convierte en una tarea más retadora conforme avanza el desarrollo del sistema. Usar un solo modelo y “evolucionarlo” durante las iteraciones es una práctica aceptable para reducir la tarea de mantener dos modelos separados. El Modelo de Diseño comprende los siguientes artefactos: • Protocolo • Cápsula • Realización de Caso de Uso • Signal • Evento • Subsistema de Diseño • Paquete de Diseño • Interfase • Clase de Diseño. Entre las clases se considera también, las Interfases con otros componentes o subsistemas. • Clase de Pruebas • Diseño de Prueba Los artefactos de diseño Cápsula (Capsule), Evento (Event), Interfase (Interfase), Protocolo (Protocol) y Señal (Signal) ayudan en un mayor detalle de los comportamientos específicos del sistema tales como una ocurrencia particular a la cual el sistema debe responder o un comportamiento particular que debe realizar una clase. Estos ítems pueden ser mostrados en los diagramas de clases y el modelo de diseño. A menos que haya una buena razón para detallarlos separadamente, estos pueden ser saltados en la variación metodológica de RUP/Easy. El Documento de Arquitectura del Software hace mucho uso de los diagramas de UML. Comprende los siguientes artefactos: • Introducción • Representación Arquitectural • Metas Arquitecturales y Restricciones. Aquí considerar los requerimientos detallados del software. • Vista de Caso de Uso • Vista Lógica • Vista de Proceso • Vista de Despliegue • Vista de Implementación • Tamaño y Performance • Calidad Una Arquitectura de Referencia (Reference Architecture) es un patrón predefinido o
  34. 34. - 34 - conjunto de patrones previamente desarrollados y disponible para reusar. El propósito de una Arquitectura de Referencia es servir como un punto de partida para desarrollar el sistema propuesto. Una Arquitectura de Referencia puede incluir modelos de diseño usados en proyectos exitosos previos. También puede incluir notas o obstáculos resueltos o evitados en proyectos previos. La Arquitectura de Referencia puede incluir soluciones útiles que pueden ser aplicadas ampliamente al sistema propuesto o simplemente que sea aplicable a un problema específico. Este es un artefacto opcional; si no existe una arquitectura previa entonces se puede saltar. 3.3.5 Reportes para Análisis y Diseño La variación metodológica de RUP/Easy considera opcionales todos los reportes de Análisis y Diseño; sin embargo, si van a usarse, la Tabla 10 identifica los siguientes reportes opcionales: Tabla 10. Reportes para el Workflow de Análisis y Diseño Reportes Herramientas Usadas Clase Rational SoDA Panorama del Modelo de Diseño Rational SoDA Paquete de Diseño/Subsistema Rational SoDA Realización de Caso de Uso Rational SoDA 3.4 IMPLEMENTACIÓN La Implementación es donde empieza el código. El Modelo de Diseño del Workflow de Análisis y Diseño es mapeado con el Modelo de Implementación y entonces se escribe el código en un lenguaje de programación tal como Java, C++ o Visual Basic. Un Plan de Integración de Construcciones define el Caso de Uso a ser diseñado y las clases a implementar, al igual que el orden en el que las clases son implementadas. 3.4.1 Vista general del Workflow de Implementación El propósito del Workflow de Implementación es: • Definir la organización del código, en términos de Subsistemas de Implementación. Los Subsistemas de Implementación son colecciones de componentes y otros modelos de implementación usados para estructurar el modelo de implementación. • Implementar las clases y objetos definidos en el modelo de diseño en la forma de componentes de software tales como archivos fuente, binarios o ejecutables • Probar los componentes desarrollados como unidades • Crear un sistema ejecutable El Workflow de Implementación está relacionado a otros workflows del RUP como sigue: • Requerimientos: Este workflow del RUP captura los requerimientos que deberían ser cumplidos durante la Implementación.
  35. 35. - 35 - • Análisis y Diseño: El modelo de diseño desarrollado durante este workflow representa el intento de la implementación y es el input principal para el Workflow de Implementación. • Pruebas: Este workflow describe cómo probar cada Construcción durante la integración del sistema. Para cada iteración, empezando en la fase de Elaboración, se efectúan los siguientes workflows de detalle: • Estructurar el Modelo de Implementación • Planificar la Integración • Implementar los Componentes • Integrar cada Subsistema • Integrar el Sistema Workflow de Implementación Estructurar el Modelo de Implementación El propósito de este Workflow de detalle es: • Asegurar que el modelo de implementación está bien organizado para prevenir problemas en la administración de la configuración • Permitir que cada versión operacional el sistema sea construido según sea necesario
  36. 36. - 36 - hasta que el producto final sea obtenido Comprende las siguientes actividades: • Estructurar el Modelo de Implementación. Establecer la estructura en la cual la implementación va a residir. Asignar responsabilidades para los Subsistemas de Implementación y sus contenidos. El artefacto principal producido es el Modelo de Implementación. Planificar la Integración El propósito de este Workflow de detalle es: • Planificar cuáles subsistemas van a ser implementados • Definir el orden en el que los subsistemas serán integrados en la iteración actual Comprende las siguientes actividades: • Planificar la Integración del Sistema. Definir el conjunto de la Construcción y evaluar el Plan de Integración de Construcciones. El artefacto principal producido es el Plan de Integración de Construcciones. Según la arquitectura y el diseño evolucionan, el Plan de Integración de Construcciones es examinado y actualizado para asegurar que no quede obsoleto debido a los cambios en la arquitectura o en el diseño del nuevo sistema. Implementar los Componentes El propósito de este Workflow de detalle es: • Desarrollar el código fuente • Adaptar los componentes existentes para que trabajen con los nuevos componentes creados • Compilar, linkeditar y efectuar las pruebas unitarias • Evaluar el código fuente contra las guías de programación identificadas en el proyecto • Identificar los defectos en el diseño y retroalimentar el trabajo en el diseño • Corregir los defectos del código identificados durante el diseño • Efectuar las pruebas unitarias en ítems retrabajados para: − Verificar que los cambios fueron implementados correctamente − Asegurarse que los cambios no causan que otros ítems tengan defectos La Implementación debería estar unida muy de cerca al Diseño. Comprende las siguientes actividades: • Implementar los Elementos de Diseño. Producir una implementación por parte del diseño (tal como una Clase de Diseño, Subsistema de Diseño o Realización de Caso de Uso) o corregir uno o más defectos. El resultado es el código fuente o actualizaciones al código fuente en la forma de Elementos de Implementación.
  37. 37. - 37 - • Analizar el Comportamiento en Run-time. Comprender el comportamiento de un componente durante su ejecución. Identificar comportamientos anómalos y cualquier acción correctiva requerida. • Implementar los Elementos de Pruebas. Implementar la funcionalidad especializada para soportar los requerimientos específicos de pruebas. • Implementar las Pruebas del Desarrollador. Implementar una o más pruebas que permitan la validación de los componentes individuales a través de su ejecución física. Desarrollar las pruebas que puedan ser ejecutadas junto con otras pruebas como parte de una infraestructura de pruebas más grande. • Ejecutar las Pruebas del Desarrollador. Verificar la especificación de una unidad. Verificar la estructura interna de una unidad. • Revisar el Código. Verificar la implementación. • Planificar la Integración de los Subsistemas. Planificar el orden en el cual los elementos contenidos en un subsistema de implementación deberán ser integrados. El artefacto principal producido es el Componente. Integrar cada Subsistema El propósito de este Workflow de detalle es integrar los componentes nuevos y modificados en la nueva versión del subsistema de implementación. La integración consiste de Construcciones múltiples. Cada Construcción pasa por las Pruebas de Integración. Luego de las pruebas, el subsistema de implementación está listo para la integración del subsistema (ver detalles abajo). Comprende las siguientes actividades: • Implementar las Pruebas del Desarrollador. Implementar una o más pruebas que permitan la validación de los componentes individuales a través de su ejecución física. Desarrollar las pruebas que puedan ser ejecutadas junto con otras pruebas como parte de una infraestructura de pruebas más grande. • Ejecutar las Pruebas del Desarrollador. Verificar la especificación de una unidad. Verificar la estructura interna de una unidad. • Integrar los Subsistemas. Integrar los elementos en un subsistema de implementación, luego enviarlo para su integración en el sistema. Los principales artefactos producidos son la Construcción y el Subsistema de Implementación. Integrar el Sistema El propósito de este Workflow de detalle es: • Integrar el sistema, de acuerdo al Plan de Integración de Construcciones, añadiendo los subsistemas de implementación. • Crear Construcciones del nuevo sistema • Efectuar las pruebas de integración del nuevo sistema La Integración a menudo envuelve un alto grado de automatización, experiencia en sistemas operativos o lenguajes script y herramientas como 'make' (en Unix).
  38. 38. - 38 - Comprende las siguientes actividades: • Integrar el Sistema. Integrar los subsistemas de implementación por pedazos en una construcción (build). El artefacto principal producido es la Construcción. 3.4.2 Configuración y Notas sobre el Workflow de Implementación Cada actividad en el Workflow de Implementación es esencial para una implementación exitosa. Ninguna actividad debe removerse del Workflow de Implementación. 3.4.3 Artefactos para la Implementación Los Artefactos para la Implementación capturan y presentan la realización de la solución presentada en el Workflow de Análisis y Diseño. La Tabla 11 identifica los artefactos que deben producirse durante el Workflow de Implementación. Tabla 11. Artefactos para el Workflow de Implementación Artefactos Creado/Revisado Revisar Detalles Herramientas Usadas Incep Elab Const Trans Construcción X X X Formal - Externo Rational Rose Por este artefacto se entiende al Prototipo o Producto, según la fase en que se encuentre el proyecto, resultante de cada iteración. 3.4.4 Notas sobre los Artefactos para la Implementación Cuando la Construcción es un prototipo inicial debe contener la interfase con el usuario; esto permite visualizar el flujo de eventos asegurando que los usuarios y otros stakeholders entiendan y aprueben el flujo de eventos. Este prototipo funcional permitirá identificar algunos componentes clave en la arquitectura incluyendo aquellos que deberán ser comprados. No incluye: Componente (Component), Modelo de Implementación (Implementation Model), Subsistema de Implementación (Implementation Subsystem), Plan de Integración de Construcciones (Build Integration Plan). 3.4.5 Reportes para la Implementación Ningún reporte será producido durante el Workflow de Implementación. Sin embargo, se efectuarán revisiones informales del código. 3.5 PRUEBAS Rational ofrece su enfoque de pruebas usando el RUP para valorar la calidad del software por medio de: • Encontrar y documentar los defectos en la calidad del software
  39. 39. - 39 - • Aconsejando acerca de la calidad percibida en el software • Proveyendo la validación de los supuestos hechos en las especificaciones de diseño y los requerimientos a través de demostraciones concretas • Validando las funciones del producto de software según sean diseñadas • Validando que los requerimientos hayan sido implementados apropiadamente 3.5.1 Vista General del Workflow de Pruebas En el RUP, las pruebas son enfocadas a través del uso de un proceso iterativo y de herramientas. Un enfoque iterativo para probar permite a la organización tratar las pruebas casi de la misma forma que el desarrollo de software es enfocado. Cada Construcción de software es un objetivo para las pruebas. Según se vayan produciendo nuevas Construcciones, el cuerpo de pruebas será añadido y refinado. Eventualmente, todas las pruebas en el cuerpo de pruebas serán acumuladas de tal manera que pueden ser usadas para las posteriores pruebas de regresión en el ciclo de vida del desarrollo de software. Este enfoque permite a una organización identificar posibles riesgos al inicio de un proyecto, reducir el costo de corregir fallas enfocando los recursos cuando y donde tendrán el mayor impacto, acercarse a los gaps de calidad tempranamente en el proceso de desarrollo y maximizar la efectividad por medio de adaptar el enfoque, el proceso o el presupuesto según va progresando el proyecto. Estrategia de Pruebas La Estrategia de Pruebas presenta el enfoque recomendado para las Pruebas de la Aplicación, es decir, describe el cómo será probado los requerimientos funcionales y no funcionales del sistema. Las consideraciones principales para la estrategia de pruebas son la técnicas a usarse y los criterios para saber cuándo las pruebas están completas. Además de las consideraciones que describimos a continuación, provistas para cada tipo de prueba, las pruebas sólo deben efectuarse usando Bases de Datos conocidas y controladas en ambientes seguros. La siguiente estrategia de pruebas es por cada tipo de prueba existente y se va a aplicar a los requerimientos del sistema. Pruebas de Integridad de Datos y Base de Datos La Base de Datos y los procesos de Base de Datos deberán ser probados como sistemas separados. Estos sistemas deberán ser probados sin las aplicaciones (como la interfase a los datos). Se deberá hacer una investigación adicional en el DBMS para identificar las herramientas y técnicas que puedan existir para soportar las pruebas identificadas a continuación: Objetivo de la Asegurar que los métodos de acceso y los procedimientos de Base
  40. 40. - 40 - Prueba: de Datos funcionan apropiadamente y sin corrupción de datos. Técnica: • Invocar a cada método de acceso y procedimiento de Base de Datos con datos válidos e inválidos (o que pidan los datos). • Inspeccionar la Base de Datos para asegurarse que los datos han sido cargados como se deseaba, que todos los eventos de Base de Datos ocurrieron apropiadamente o revisar los datos de retorno para asegurarse que se ha leído los datos correctos (por las razones correctas) Criterios de Finalización: • Todos los métodos de acceso y procedimientos de Base de Datos funcionan tal como fueron diseñados y que no hay corrupción de datos. Consideraciones Especiales: • Las pruebas pueden requerir un ambiente de desarrollo del DBMS o drivers para ingresar o modificar datos directamente en la Base de Datos. • Los procesos deberán ser invocados manualmente. • Deberá usarse Bases de Datos pequeñas (con un número de limitado de registros) para mejorar la visibilidad de cualquier evento que no sea aceptable. Pruebas de la Aplicación Las pruebas a la aplicación deben enfocarse en cualquier requerimiento objetivo que pueda ser rastreado directamente a los casos de uso (o funciones del negocio) y reglas del negocio. Las metas de estas pruebas son verificar la aceptación, procesamiento y lectura apropiada de los datos y la implementación apropiada de las reglas del negocio. Este tipo de pruebas se basan en pruebas de “caja negra”, es decir, verificando la aplicación (y sus procesamientos internos) por medio de interactuar con la aplicación vía el GUI y analizando el output (resultados). A continuación identificamos un bosquejo de las pruebas recomendadas para cada aplicación: Objetivo de la Prueba: Asegurar la navegación de la aplicación, entrada de datos, procesamiento y lectura apropiados. Técnica: • Ejecutar cada Caso de Uso, flujo de Caso de Uso o función usando datos válidos e inválidos para verificar lo siguiente: o Los resultados esperados ocurren cuando se usa datos válidos. o El error o mensaje de advertencia apropiado es mostrado cuando se usa datos inválidos. o Cada regla del negocio está aplicada apropiadamente. Criterios de Finalización: • Todas las pruebas planeadas han sido ejecutadas.
  41. 41. - 41 - • Todos los defectos identificados han sido corregidos. Consideraciones Especiales: • Para ejecutar estas pruebas podría ser necesario el acceso a las instalaciones de los stakeholders. Pruebas del Ciclo del Negocio Las Pruebas del Ciclo del Negocio deben emular las actividades en el sistema en algún momento. Se debe identificar un período de tiempo, tal como un mes y se deben ejecutar las transacciones y actividades que ocurrirían durante ese mes. Esto incluye todo los ciclos y eventos diarios, semanales y mensuales que son sensitivos a las fechas. Objectivo de la Prueba: Asegurar que los procesos de la aplicación y de background funcionan de acuerdo a los plazos y modelos del negocio requeridos. Técnica: • Las pruebas simularán varios ciclos del negocio por medio de efectuar lo siguiente: o Las pruebas usadas para probar las funciones de la aplicación deberán ser modificadas / mejoradas para incrementar el número de veces que cada función es ejecutada para simular varios usuarios diferentes durante un período específico de tiempo. o Todas las funciones sensitivas a fechas y horas serán ejecutadas usando períodos de fechas y horas válidos e inválidos. o Todas las funciones que ocurren en un horario periódico serán ejecutadas / lanzadas en el momento apropiado. • Las pruebas se efectuarán usando daos válidos e inválidos para verificar lo siguiente: o Los resultados esperados ocurren cuando se usa datos válidos o El error o mensaje de advertencia apropiado es mostrado cuando se usa datos inválidos . Criterios de Finalización: • Todas las pruebas planeadas han sido ejecutadas. • Todos los defectos identificados han sido corregidos. Consideraciones Especiales: • Eventos basados en fechas del sistema podrían requerir actividades especiales de soporte. Pruebas de Interfase con el Usuario Las Pruebas de Interfase con el Usuario verifican una interacción del usuario con el software. La meta de las Prueba de la UI es asegurar que la interfase con el usuario

×