INTRODUCCIÓN AL FLUJO DE REQUISITOS


DESARROLLO DE APLICACIONES WEB EN MICROSOFT C# .NET MODELADAS EN UML.

Antes de iniciar con esta introducción se presenta la diferencia entre las palabras Requisito y Requerimiento.

clip_image002

Para el texto se toma la palabra de Requisito para expresar los objetivos en el proceso de desarrollo de una aplicación de software. No debe olvidarse que la definición de un requisito debe permitir medir el cumplimiento de este.

Existen dos clases de requisitos, cada una de estas son muy importantes y hay que describirlas de una forma completa. La descripción se la hace por medio de una plantilla que debe ser acordada, previamente, por el grupo de desarrollo o por la empresa. Estas clases son las siguientes:

– Requisitos Funcionales. Una capacidad o condición que la aplicación debe cumplir

– Requisitos no Funcionales. Propiedades o cualidades que el producto de software debe tener.

Existe una clasificación adicional a las descritas anteriormente, estas nos dan una visión más clara de los requisitos que deben ser descritos por el grupo de desarrollo y son:

– Normales (Funcionales). Deben incluir los objetivos y metas para una aplicación, esto significa que si están presentes el cliente está satisfecho, ya que cumplirán con las necesidades del trabajo diario.

– Esperados (No Funciones). Estos serán implícitos a la aplicación, puede que el cliente no los declare, pero si no están puede que esté insatisfecho. Como por ejemplo, la Facilidad de Uso o la Seguridad de transmisión de los datos que realiza la aplicación.

– Innovadores (Funcional y No Funcional). Son requisitos con características que van más allá de las expectativas del cliente. Como por ejemplo, una calculadora o implementar una conversación escrita en tiempo real (Chat) dentro de la aplicación.

Respecto a la experiencia que se tiene se ha podido identificar un conjunto de tipos de requisitos. Estos se pueden ver en el siguiente cuadro.

clip_image004

Cada requisito se puede clasificar de:

– Prueba.

– Flujo de Negocio.

– Usuario.

– Comunicación.

– Flujo de Datos.

– Restricciones.

– Riesgos.

– Estimación.

– Concurrencia.

– Interfaz.

– Hardware.

– Interacción.

– Verificación.

Existen cuatro pasos fundamentales para la determinación de los requisitos, son los siguientes:

– Enumerar los Requisitos Funcionales Candidatos. Se puede listar de forma desordenada que es lo que se quiere que resuelva la aplicación, tomando en cuenta el conocimiento de los futuros usuarios, clientes y desarrolladores.

– Comprender el Contexto de la Aplicación. Los desarrolladores necesitan un fuerte conocimiento del contexto del sistema de información donde se desarrollará la aplicación, así mismo un conocimiento muy acertado de las actividades y procesos que se van a automatizar. Esto se logra gracias al Modelo del Negocio, el cual estudia las actividades desde el punto de vista del negocio.

– Capturar los Requisitos Funcionales. Los requisitos funcionales serán expresados por medio de los Casos de Uso, los cuales describirán el flujo de actividades para el manejo de la aplicación. La descripción de los casos de uso debe realizarse de una forma completa utilizando una plantilla establecida por el grupo de desarrollo o de la empresa. La descripción debe tomar en cuenta los escenarios diversos que puede tener un Caso de Uso, entendiendo como escenario a las situaciones diversas que puede existir al momento de manejar la aplicación. Otra alternativa, para la capturar a los requisitos es a través del Modelo del Negocio, específicamente el Diagrama de Actividad que describe un caso de uso del negocio.

– Capturar los Requisitos no Funcionales. Debe pensarse en estas propiedades como las características que hacen al producto atractivo, usable, rápido o confiable. Estos requisitos incluyen:

o Conjunto de Facilidades

o Capacidades

o Restricciones

o Seguridad

Racional propone realizar un estudio y descripción de los requisitos no funcionales:

o Apariencia o Interfaz Externa

o Facilidad de Uso

o Rendimiento

o Soporte

o Seguridad

o Confiabilidad

o Ayudas y documentación en línea

o Software y Hardware

o Diseño e Implementación

o Políticos y Culturales

Como se ha visto en el documento de introducción, se puede definir los requisitos no funcionales a través de la Normas internacionales como por ejemplo: ISO-9126 (ISO-25000), McCall y Boohem, siendo la primera la más utilizada para este propósito.

CMMI, describe un conjunto de técnicas para la captura de los requisitos, estas son:

– Demostraciones de Tecnología.

– Grupos de trabajo de control técnico.

– Grupos de trabajo de control de la interfaz.

– Revisiones intermedias del proyecto.

– Cuestionarios, entrevistas y escenarios.

– Análisis de tareas del usuario final.

– Prototipos y modelos.

– Tormenta de ideas.

– Despliegue de la función de la calidad.

– Estudios de mercado.

– Pruebas beta.

– Documentos, estándares o especificaciones.

– Patrones de flujo de trabajo.

– Casos de uso.

– Análisis de casos de negocio.

– Ingeniería inversa.

– Encuestas de satisfacción del cliente.

No todas estas técnicas serán utilizadas para la captura de los requisitos. El arquitecto de software debe seleccionar un conjunto de estas para lograr describir de forma completa los objetivos de la aplicación a desarrollar.

Cada requisito estará descrito dentro de un Caso de Uso, como también pueden existir requisitos generales que involucren a toda la aplicación, conocidos como Requisitos Adicionales.

Dentro del Proceso Unificado de Racional una de las herramientas utilizadas para la determinación de requisitos para la aplicación son los Casos de Uso. Esta herramienta, se ha utilizado durante muchos años, ya que describe, de manera óptima, los requisitos de los clientes. Un Caso de Uso debe ser, para el usuario, un modo de utilizar la aplicación, es decir un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza la aplicación para un propósito. La transición de la determinación de las necesidades, pasando por los requisitos del cliente y llegar hasta la implementación no es fácil. Las necesidades de un cliente no son fáciles de discernir o descubrir y mucho más traducirlas a un lenguaje que sirva para desarrollar una aplicación. Esto obliga que se debe tener un modo de descubrir estas necesidades del cliente para poderlas transformar en requisitos de la aplicación, de modo que sea fácil la comunicación entre los involucrados en el proyecto. Después, se debe llevar a cabo la implementación, que debe ajustarse con las necesidades y requisitos. El último problema es comprobar que la implementación cubra de una manera óptima los requisitos del usuario, para esto se utiliza el proceso de prueba que nos garantiza una validación de la aplicación desarrollada para cubrir con las necesidades del cliente.

Los Casos de Uso han sido adoptados en el mundo entero para la captura de requisitos de sistemas de software y sistemas basados en componentes, pero los Casos de Uso son más que para la determinación de los requisitos, dirigen y ayudan, en forma total, el desarrollo.

Es normal que una aplicación cuente con muchos usuarios o actores, lo cuales son los que interactúan con los casos de uso. Un Caso de Uso es una secuencia de acciones que la aplicación lleva a cabo para ofrecer un resultado para el actor. El resultado de estudio de estos da como resultado el Modelo de Casos de Uso. Está compuesto por todos los actores y los Casos de Uso relacionados.

Para realizar la captura de los requisitos se debe iniciar con la determinación de los actores, luego por cada actor determinar los casos de uso. Cada caso de uso tiene que estar debidamente descrito. Por último realizar el Diagrama de Casos de Uso.

Identificar los actores

Para identificar los actores de la aplicación se utiliza la descripción de los Casos de Uso del Negocio, es decir, los Diagramas de Actividad. Ya sea, un Actor o un Trabajador del Negocio se convertirá en un Actor de la Aplicación, esto se determina por medio de:

  • La situación de la Institución. Algunas veces no tiene para invertir en recursos técnicos que permitan desarrollar una aplicación con la última tecnología. Aunque, algunas veces, es un error utilizar la última tecnología por motivos de compatibilidad. Esta situación puede llegar a determinar que los trabajadores del negocio son los candidatos a ser Actores de la Aplicación.
  • Las necesidades de la Institución. Algunas veces por el incremento del manejo de información o por el crecimiento de servicios se necesita desarrollar una aplicación en un entorno Web, que incluye al cliente como posible actor de la aplicación.

Estos factores son los que se deben tomar en cuenta para determinar a los actores de la aplicación. Sin embargo, como se ha explicado en anteriores documentos, el Modelo del Negocio se puede obviar, en este caso los actores de la aplicación serán determinados de distinta forma, que se explica a continuación.

Los actores se caracterizan por:

· No son parte de la aplicación, son roles de un usuario

· Pueden intercambiar información con el sistema

· Pueden ser un recipiente pasivo de información

· Pueden representar a un humano a una máquina o un software

Para identificar los actores en el contexto de la aplicación deben realizarse las siguientes preguntas:

· ¿Quién está interesado en cierto requisito?

· ¿Dónde en la organización es usado el sistema?

· ¿Quiénes usan, eliminan o suministran información?

· ¿Quién usará una funcionalidad de la aplicación?

· ¿Quién soporta y mantiene el sistema?

· ¿Usa el sistema un recurso externo?

· ¿Cuáles actores necesitan el caso de uso?

· ¿Un actor juega diferentes roles o varios actores juegan el mismo rol?

Identificar los casos de uso

De igual forma que para determinar a los actores de la aplicación se debe estudiar los Diagramas de Actividad de los Casos de Uso del Negocio y sus actividades. Este estudio nos permitirá identificar a los Casos de Uso de la aplicación. Las actividades que están dentro de los diagramas de actividades deben ser analizadas y resumidas, de esta forma se puedan convertir en Requisitos de la aplicación. No todas las actividades que se presentan en un diagrama de actividad serán automatizadas.

Se tiene dos métodos para identificar los casos de uso si no se cuenta con el Modelo del Negocio:

· Método basado en los Actores

· Método basado en Eventos

En el método basado en los actores se tiene en cuenta lo siguiente:

· Se relacionan los actores con un sistema o empresa

· Para cada actor, se identifican los procesos que inician o en que participan

En el método basado en los eventos se tiene en cuenta lo siguiente:

· Se identifican los eventos externos a los que un sistema debe responder

· Se relacionan los eventos con los actores y con los casos de uso

Una vez que se hayan determinado los Actores y Casos de Uso de la Aplicación se debe describir cada uno de estos. Esta descripción se verá más adelante con mucho detalle, ya que es la parte más importante dentro del desarrollo de software.

El siguiente paso es realizar el Diagrama de Casos de Uso de la aplicación, el cual nos dará una vista muy resumida y completa de la magnitud del desarrollo. Este diagrama se desarrolla con los estereotipos de Casos de Uso y Actores. En este momento, se puede determinar los posibles Ciclos de Desarrollo y los Paquetes que ayudan a entender mucho mejor el modelo de requisitos.

Una vez desarrollado el Diagrama de Casos de Uso, se procede a describir cada uno de los casos de uso que están dentro del diagrama, de una forma resumida, lo cual nos da una visión de las operaciones y transacciones que se realizarán en la aplicación, esto último nos permite poder estimar el esfuerzo, tiempo y costo del desarrollo, lo cual nos permitirá, posteriormente, desarrollar un Plan de Desarrollo.

El último paso es la determinación de los Requisitos no Funcionales, los cuales deben estar de acuerdo a un estándar, ya sea interno, nacional o internacional. Estos requisitos son muy importantes, ya que con estos se podrá medir, en gran parte la calidad. Estos requisitos demostrarán el trabajo que se realizará o que se ha realizado durante el desarrollo, ya que obligará a los desarrolladores a medir y controlar el desarrollo. En estos documentos se ve, muy poco, respecto a la definición, control y seguimiento de estos requisitos.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s