Usuario:Gleisermayo

Importancia del levantamiento de requisitos en ISW

Lograr una comunicación efectiva entre los usuarios y el equipo de proyecto así como también entre los miembros de este último, con el objetivo de llegar a un entendimiento de lo que hay que hacer, es la clave del éxito en la producción de un software. Durante muchos años muchas aplicaciones han fallado (no se culminaron o no se usaron) porque existieron incongruencias entre lo que el usuario quería, lo que realmente necesitaba, lo que interpretaba cada miembro del equipo de proyecto y lo que realmente se obtiene. Aquí radica la importancia que en los últimos años se le ha dado a la identificación de los requerimientos como punto de partida en el proceso de desarrollo del software. El flujo de trabajo de modelamiento del negocio nos enseña a describir el negocio actual y a modelar el negocio propuesto, da una visión de qué es necesario hacer para dar respuesta a la solicitud del usuario. El modelamiento del negocio brinda una vía natural para determinar los requerimientos del sistema de información.

Desafíos para la Ingeniería de requisitos

Los sistemas de software grandes deben mejorar su actual situación. Es difícil anticipar los efectos que el sistema tendrá en la organización. Usuarios diferentes tienen Requisitos y prioridades diferentes. Hay constantemente compromiso de cambios en los Requisitos. Los usuarios finales del sistema y la organización que paga por el sistema tienen Requisitos diferentes. El prototipado es requerido para clarificar Requisitos

Objetivos generales de la captura de requisitos:

Guiar el desarrollo de software hacia el sistema correcto, definiendo objetivos generales concretos de manera tal que tanto el negocio como sus actores se beneficien [1]. Durante el proceso de obtención de los requerimientos juega un papel esencial el cliente, que se convierte en un miembro más del equipo de proyecto por lo que el resultado de la captura de requerimientos debe ser escrito en su lenguaje.

Los trabajadores que participan en este flujo de trabajo son:

• Analista del sistema: Define los alcances del sistema e identifica a los actores y casos de uso que permiten modelar completa y consistentemente el sistema.
• Especificador de casos de uso: Describe detalladamente cada caso de uso de acuerdo a las funcionalidades que engloba.
• Arquitecto: Describe la vista de la arquitectura del modelo de casos de uso, definiendo la prioridad de cada caso de uso para decidir en qué iteración será desarrollado cada uno.

Los artefactos que construyen estos trabajadores son: • Modelo de casos de uso: Es un modelo del sistema que contiene actores, casos de uso y sus relaciones.
• Actor: Terceros fuera del sistema que interactúan con él.
• Caso de uso: Fragmentos de funcionalidad que el sistema ofrece para aportar un resultado de valor para sus actores.

• Descripción de la arquitectura (vista del modelo de casos de uso): Representa los casos de uso significativos para la arquitectura ya que describen alguna funcionalidad importante y crítica o algún requisito que deba priorizarse.
•Glosario de términos: Términos comunes que se utilizan para describir el sistema.
• Prototipo de interfaz usuario: Presentación de la interfaz del producto que representa la funcionalidad contenida en los casos de uso; de manera que permita que el usuario verifique que el sistema va a satisfacer sus necesidades.

Los pasos fundamentales del flujo son:

Enumerar los requisitos candidatos.
Comprender el contexto del sistema.
Capturar requisitos funcionales.
Capturar requisitos no funcionales.

El modelamiento del negocio.

Un sistema, por pequeño que sea, generalmente es complicado. Por eso se necesita dividirlo en piezas si se pretende comprenderlo y gestionar su complejidad. Esas piezas se pueden representar a través de modelos que permitan abstraer sus características esenciales [2].

Una técnica para la especificación de los requisitos más importantes del sistema, que da soporte al negocio, es el modelo del negocio, con lo cual se refuerza la idea de que sea el propio negocio lo que determine los requisitos.

De ahí, que en el campo del software también resulte útil la creación de modelos que organicen y presenten los detalles importantes de problemas reales que se vinculan con el sistema informático a construir. Estos modelos deben cumplir una serie de propiedades, entre ellas la de ser coherentes y relacionados. Uno de los modelos útiles previo al desarrollo de un software es el modelo del negocio.

Los objetivos del modelamiento del negocio son [3]:

§ Comprender la estructura y la dinámica de la organización en la cual se va a implantar un sistema. § Comprender los problemas actuales de la organización e identificar las mejoras potenciales. § Asegurar que los consumidores, usuarios finales y desarrolladores tengan un entendimiento común de la organización. § Derivar los requerimientos del sistema que va a soportar la organización.

Para lograr esos propósitos, el proceso de modelamiento permite obtener una visión de la organización que permita definir los procesos, roles y responsabilidades de la organización en los modelos de casos de uso del negocio y de objetos.

De aquí que este proceso esté relacionado con los de obtención de requerimientos y análisis-diseño.

En la primera iteración se hará una evaluación de la organización en la cual se implantará el futuro sistema y, basado en los resultados, se tomarán decisiones sobre cómo continuará esa iteración.

En general, según RUP, el flujo de trabajo se desarrolla según se indica a continuación de manera simplificada, mediante el diagrama de actividad del negocio, siguiendo varias alternativas que gráficamente se muestran:

Referencia:

[1] LEFFINGWELL, Dean; “Features, Use Cases, requirements, Oh My!”.2000. Rational Software. Http://www.rational.com/media/whitepapers/featucreqom.pdf [2] RUMBAUGH, James, JACOBSON, Ivar; BOOCH, Grady, “El lenguaje unificado de modelado”.2000. Addison Wesley. Capítulo 5, 10 y 13 Páginas 55-58, 87-90, 156-162, 120-121, 399-402, 365. [3] PRESSMAN,Roger “Ingeniería del Software. Un enfoque práctico”.2002. McGraw-Hill/Interamericana de España. Páginas 184-186 “Técnicas para facilitar las especificaciones de la aplicación.

.