Manual de Analisis y Diseño de Sistemas || by Americo Muñoz

Análisis y Diseño de Sistemas II

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Índice Presentación Red de contenidos

5 7

Unidad de Aprendizaje 1

INGENIERÍA DE REQUERIMIENTOS 1.1 Tema 1 : Ingeniería de Requerimientos 1.1.1 : Ingeniería de Requerimientos 1.1.2 : Definición de Ingeniaría de Requerimientos 1.1.3 : Importancia de los requerimientos 1.1.4 : División o tipos de Requerimientos (funcionales y No funcionales 1.1.5 : Características de los requerimientos 1.1.6 : Dificultad para definir los requerimientos

9 11 11 11 12 12 15 16

1.2 Tema 2 : Actividades en Ingeniería de Requerimientos 1.2.1 : Definiciones, Identificación de Participantes o roles en la identificación de los requerimientos 1.2.2 : Obtención de requerimientos 1.2.3 : Análisis y Negoción de requerimientos 1.2.4 : Modelado y especificación de requerimientos 1.2.5 : Validación y verificación 1.2.6 : Administración de requerimientos

17 17

1.3 Tema 3 1.3.1 1.3.2 1.3.3 1.3.4

37 37 41 45 53

: : : : :

Gestión de Requisitos según RUP Pirámide de requisitos Características de un buen requisito Visión General de la gestión de requisitos según RUP Trazabilidad según RUP de los requisitos

20 22 27 34 36

Unidad de Aprendizaje 2

TÉCNICAS Y HERRAMIENTAS PARA LA INGENIERÍA DE REQUERIMIENTOS 2.1 Tema 4 : Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos 2.1.1 : Entrevistas 2.1.2 : Cuestionarios 2.1.3 : Lluvia de ideas 2.1.4 : Proceso de Análisis Jerárquico (AHP) 2.1.5 : Administración de requerimientos con casos de uso 2.1.6 : Ventajas y desventajas de las técnicas 2.1.7 : Comparación entre técnicas

57 59 59 62 64 65 65 67 68

Unidad de Aprendizaje3

ESPECIFICACION DE REQUERIMIENTOS 3.1 Tema 5 : Especificación textual de los requisitos 3.1.1 : Un modelo de especificación de requisitos del software: el estándar IEEE 830-1993/1998 3.1.2 : ¿Qué se incluye en el documento de especificación de

CIBERTEC

71 73 73 73

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

requisitos del software (SRS)? 3.1.3 : Propiedades de un documento de especificación de requisitos 3.1.4 : Estructura del documento SRS del IEEE 830 3.1.5 : Alternativas en la especificación de requisitos específicos, según IEEE 830 3.2 Tema 6 3.2.1 3.2.2 3.2.3 3.2.4 3.2.5 3.2.6

: : : : : : :

Prototipado Prototipado: conceptos, métodos y herramientas Clases de prototipos Validación y Verificación mediante prototipos Prototipado: ventajas e inconvenientes Importancia de la notación a nivel de interfaz Elementos interactivos en la interfaz gráfica

3.3 Tema 7 3.3.1 3.3.2 3.3.3 3.3.4

: : : : :

Especificación de Caso de Uso Importancia de las Especificaciones de caso de uso Consejos Para Escribir Buenos Casos de Uso Detallar la especificaciones de casos de uso Errores comunes que deben ser evitados especificaciones de casos de Uso

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

74 80 84

89 89 90 90 92 93 96

102 102 102 107 114

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Presentación Análisis y Diseño de Sistemas II pertenece a la línea formativa y se dicta en la carrera de Administración y Sistemas. El curso imparte conocimientos relacionados con la disciplina de Gestión de Requerimientos, análisis y diseño, y el modelo de datos. El manual para el curso ha sido diseñado bajo la modalidad de unidades aprendizaje, las que se desarrollan durante semanas determinadas. En cada una ellas, hallará los logros, que debe alcanzar al final de la unidad; el tema tratado, cual será ampliamente desarrollado; y los contenidos, que debe desarrollar, decir, los subtemas. Por último, encontrará las actividades que deberá desarrollar cada sesión, que le permitirán reforzar lo aprendido en la clase.

de de el es en

El curso es teórico - práctico: consiste en un taller de desarrollo de proyectos de software. En primer lugar, se describe el flujo de trabajo del análisis orientado a objetos. A continuación, se explica el modelo de datos. Por último, se presenta el flujo de trabajo del diseño orientado a objetos.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Red de contenidos Análisis y Diseño de Sistemas II

Unidad 1

Ingeniería de requerimi entos

Act. en Ing., de Requeri mientos

Unidad 2

Gestión de Requisi tos según RUP

Tec. Y Herramien tas utilizadas en IR

Especificació n Textual de requisitos

CIBERTEC

Unidad 3

Prototipado

Especificación de casos de Uso

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

UNIDAD

1 INGENIERÍA DE REQUERIMIENTOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno a partir del correcto entendimiento de la ingeniería de requerimientos podrá identificar los tipos de requerimientos, características y podrá gestionar los requerimientos. Además de crear los documentos, tipos de requisitos con sus atributos y las matrices de trazabilidad y controlar los cambios TEMARIO 1.1 Tema 1 1.1.1 1.1.2 1.1.3 1.1.4 1.1.5 1.1.6 1.2.Tema 2 1.2.1

: : : : : : :

1.2.2 1.2.3 1.2.4 1.2.5 1.2.6 1.3 Tema 3 1.3.1 1.3.2 1.3.3 1.3.4

: : : : : : : : : :

Ingeniería de Requerimientos Ingeniería de Requerimientos Definición de Ingeniaría de Requerimientos Importancia de los requerimientos División o tipos de Requerimientos (funcionales y No funcionales) Características de los requerimientos. Dificultad para definir los requerimientos. Actividades en Ingeniería de Requerimientos Definiciones, Identificación de Participantes o roles en la identificación de los requerimientos Obtención de requerimientos Análisis y Negoción de requerimientos Modelado y especificación de requerimientos Validación y verificación Administración de requerimientos Gestión de Requisitos según RUP Pirámide de requisitos Características de un buen requisito Visión General de la gestión de requisitos según RUP Trazabilidad según RUP de los requisitos

ACTIVIDADES PROPUESTAS  Identificar los Requerimientos funcionales y no funcionales del proyecto  Desarrollar la pirámide de requisito del proyecto.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

1.1. INGENIERÍA DE REQUERIMIENTOS 1.1.1. Ingeniería de Requerimientos La Ingeniería de Requerimientos, se utiliza para definir todas las actividades involucradas en el descubrimiento, documentación y mantenimiento de los requerimientos para un producto determinado. EL uso del término “Ingeniería” implica que se deben utilizar técnicas sistemáticas y repetibles para asegurar que los requerimientos del sistema estén completos y sean consistentes y relevantes. Normalmente, un tema dela Ingeniería de Software tiene diferentes significados. De las muchas definiciones que existen para requerimiento, a continuación se presenta la definición que aparece en el glosario de la IEEE. 1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. 2. Una condición o capacidad que debe estar presente en un sistema o componente de sistemas para satisfacer un contrato, estándar, especificación u otro documento formal. 3. Una representación documentada de una condición o capacidad como en los puntos anteriores 1 0 2

1.1.2. Definición de Ingeniaría de Requerimientos ¿Para qué un proceso de Ingeniería de requerimientos? El proceso de Ingeniería de requerimientos es un conjunto estructurado de actividades, mediante las cuales obtenemos, validamos y mantenemos el documento de especificación de requerimientos. Las actividades del proceso incluyen la extracción de requerimientos, el análisis, la negociación y la validación. No existe un proceso único que sea válido de aplicar en todas las organizaciones. Cada organización debe desarrollar su propio proceso de acuerdo al tipo de producto que se está desarrollando, a la cultura organizacional, y al nivel de experiencia y habilidad de las personas involucradas en la ingeniería de requerimientos. La meta de la ingeniería de Requerimientos es entregar una especificación de requisitos de Software correcta y completa. Algunas definiciones de Ingeniería de requerimientos según distintos autores “Ingeniería de requerimientos es la disciplina para desarrollar una especificación completa, consistente y no ambigua, la cual servirá como base para acuerdos comunes entre todas las partes involucradas y en donde se describen las funciones que realizara el sistema “. “2” “Ingeniería de requerimientos es el proceso por el cual se transforman los requerimientos declarados por los clientes, ya sean hablados o escritos, a especificaciones precisas, no ambiguas, consistentes y completas del comportamiento del sistema, incluyendo funciones, interfaces, rendimiento y limitaciones”. “8”

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

“Es el proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar .Este proceso utiliza una combinación de métodos ,herramientas y actores , cuyo producto es un modelo del cual se genera un documento de requerimientos” . ””1” “Ingeniería de requerimientos es un enfoque sistemático para recolectar organizar y documentar los requerimientos del sistema, es también el proceso que establece y mantiene acuerdos sobre los cambios de requerimientos entre los clientes y el equipo del proyecto “. “ 23” Dadas las definiciones anteriores se aporta que la ingeniería de Requerimientos es una sucesión de pasos que ayudan a obtener la definición clara, consistente y compacta de las especificaciones correctas que precisan el comportamiento de la información que requiere el usuario para su sistema.

1.1.3. Importancia de los requerimientos La parte más difícil de construir un sistema es precisamente saber que construir. Ninguna otra parte del trabajo conceptuales tan difícil como establecer los requerimientos técnicos detallados .Incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto al sistema. Ninguna es tan difícil de corregir más adelante. Entonces la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos de producto Los requerimientos se deben descubrir antes empezar a construir un producto, y que puede ser algo que el producto debe hacer o una cualidad que el producto debe tener. Un requerimiento existe ya sea porque el tipo de producto demanda ciertas funciones o cualidades, o porque el cliente quiere que ese requerimiento sea parte del producto final. Así que si no se tienes los requerimientos correctos, no se puede diseñar o construir el producto correcto y, consecuentemente el producto no permite a los usuarios finales realizar su trabajo.

Figura 1.- Origen de los errores en un proyecto de Software Fuente.- Tomado de http://ceisufro.cl/index.php?id=27&no_cache=1

1.1.4. División o tipos de Requerimientos (funcionales y No funcionales) Los requerimientos se pueden dividir en funcionales y no funcionales, a continuación se definen:

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Requerimientos Funcionales Definen las funciones que el sistema será capaz de realizar. Describen las transformaciones que el sistema realiza sobre las entradas para producir salidas, especifican los servicios que debe proporcionar la aplicación ( por ejemplo,” la aplicación debe calcular el valor de los descuentos según tipo de cliente”) Requerimientos no funcionales Son restricciones que especifican propiedades del sistema, tales como facilidad de uso, restricciones del entorno o de implementación, rendimiento, dependencias de plataforma, facilidad de mantenimiento, extensibilidad, fiabilidad y escalabilidad. El incumplimiento de un requerimiento no funcional puede significar que el sistema entero sea inutilizables. Por ejemplo, si un sistema de contabilidad no cumple sus requisitos de fiabilidad, no se certificará como seguro para el funcionamiento; si un sistema de control de tiempo real no cumple sus requisitos de rendimiento, las funciones de control no funcionarían correctamente. Facilidad de Uso Deben incluir subcategorías tales como:  Factores Humanos  Estéticos  Consistencia de Interfaz de Usuario  Ayuda en línea o “context-sensitive”  Asistentes (“wizards”)  Documentación de Usuario  Materiales de Capacitación/Entrenamiento Por ejemplo: R1: El sistema deberá proporcionar ayudas en línea para orientar en el uso de las interfaces. R2: Maximizar eficiencia mediante la navegación con teclado. R3: El sistema debe tener interfaces gráficas de administración y de operación en idioma español y en ambiente 100% Web, para permitir su utilización a través de navegadores de Internet Confiabilidad  Frecuencia de fallos  Capacidad de recuperación a fallos  Posibilidades de predicción del programa  Precisión  Tiempo medio de fallos Por ejemplo: R1: El sistema debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de energía o del equipo. R2: La cuenta del usuario se bloqueará por un lapso de 30 minutos luego de 4 intentos fallidos para evitar vulnerabilidades en la seguridad del sistema.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Rendimiento Condiciones impuestas a requisitos funcionales y son tales como:  Velocidad  Eficiencia  Disponibilidad  Tiempo de Respuesta  Tiempo de Recuperación  Uso de recursos Por ejemplo: R1: El tiempo máximo para mostrar el reporte de cuentas por cobrar mediante un histograma es de 20 segundos. R2: El sistema debe estar disponible al 100% o muy cercano a esta disponibilidad durante el horario hábil laboral de la empresa a nivel nacional, es decir, de lunes a viernes de 8:00 a.m. a 5:00 p.m., con excepción de los días festivos. Soporte Es la capacidad que tiene el software de ser modificado fácilmente para adecuar mejoras o cambios. Incluye:  Adaptabilidad  Facilidad de mantenimiento  Compatibilidad  Configurabilidad  Facilidad de instalación  Internacionalización Por ejemplo: R1: El sistema debe operar de manera independiente del navegador que se utilice (Microsoft Internet Explorer 11.0 o superior, Mozilla Firefox 31.0 o superior. Google Chrome 36.0 o superior. R2: El sistema deberá estar orientado a que las actualizaciones sólo se hagan en el sitio del servidor. Restricciones de Diseño También llamados restricciones de diseño, especifican o restringen el diseño de un sistema. Por ejemplo: R1: El sistema deberá considerar en su arquitectura un modelo tres capas, donde se definen tres componentes lógicos de manera independiente: servicios de presentación o interfaz de usuario, servicios de funcionalidad y servicios de datos. Requisitos de implementación Especifica restricciones de codificación o de construcción del sistema:  Estándares requeridos  Lenguajes de implementación  Políticas para la integridad de Bases de Datos  Límite de recursos  Ambientes de Operación Por ejemplo: R1: El sistema debe desarrollarse con el lenguaje JAVA V1.6.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Requisitos de interfaz Especifica:  Elemento externo con el que el sistema debe interactuar  Restricciones o formatos, tiempos u otros factores usados en tales interacciones Por ejemplo: R1: El sistema deberá proporcionar, para los diferentes reportes solicitados, salidas en documentos electrónicos (Word, Excel o Acrobat Reader). R2: En una visión preliminar de impresión se consideraría que todos los textos estarán relacionados con un visor de PDF, las estadísticas y resultados de consultas estarán relacionados con Excel 2010. Requisitos físicos Especifican características físicas que el sistema debe poseer. Por ejemplo: material, forma, tamaño y peso. Pueden especificarse los requisitos de hardware. Por ejemplo: R1: Para que un cliente de la aplicación pueda ejecutar procesos, en línea, considerados en el sistema el punto de acceso deberá cumplir con los siguientes requisitos mínimos.  Procesador 1.0 GHz.  Memoria 128 MB.  Disco duro 10 GB.  Sistema Operativo Windows Vista o Linux.  Navegador internet Explorer 11.0 o posterior, Mozilla Firefox 31.X con plugins para Macromedia Flash y Java.  Conexión a Internet. mínimo 56Kbps

1.1.5. Características de los requerimientos Las características de los requerimientos son sus propiedades principales. Un conjunto de requerimientos en estado de madurez, deben presentar una serie de atributos tanto individuales como en grupo. Características más importantes Necesario. Si su omisión provoca una deficiencia en el sistema a construir y además su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Conciso. Si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlos en un futuro. Completo. Si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su compresión. Consistente. Si no es contradictorio con otro requerimiento. No ambiguo. Cuando tiene una sola interpretación. El lenguaje usado en su definición, no debe causar confusiones al lector.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

1.1.6. Dificultad para definir los requerimientos Los requerimientos no son obvios y vienen de muchas fuentes. Son difíciles de expresar en palabras (el lenguaje es ambiguo) Existen muchos tipos de requerimientos y diferentes niveles de detalle. La cantidad de requerimientos en un proyecto puede ser difícil de manejar. Nunca son iguales. Algunos son más difíciles, más riesgosos, más importantes o más estables que otros.  Los requerimientos están relacionados unos con otros, y a su vez se relacionan con otras partes del proceso.  Cada requerimiento tiene propiedades únicas y abarcan áreas funcionales específicas.  Un requerimiento puede cambiar a lo largo del ciclo de desarrollo.

    

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

1.2. ACTIVIDADES EN INGENIERÍA DE REQUERIMIENTOS La Ingeniería de Requerimientos como se mencionó anteriormente, consta de 5 actividades: obtención; análisis y negociación; modelado y especificación; validación y verificación; y administración. A continuación se detalla cada una de éstas, con las técnicas y herramientas relacionadas, así como sus participantes.

1.2.1. Definiciones, Identificación de Participantes identificación de los requerimientos

roles

Los involucrados (stakeholders) son los individuos y organizaciones que están relacionados activamente en un proyecto de software, tienen influencia directa o indirecta sobre los requerimientos, o sus intereses se ven afectados por el proyecto. Pueden incluir clientes, usuarios finales, directivos, administradores de proyecto, analistas, programadores, y personal de aseguramiento de la calidad. No existe una terminología única de los distintos roles de las personas involucradas en el desarrollo de software ♦. A continuación se enlistan los más generales con sus términos similares, aunque cabe resaltar que existen leves diferencias entre ellos.      

Líder de Proyecto/Administrador de Proyecto/Gerente de Proyecto Analista/Ingeniero de Requerimientos Ingeniero de Sistemas/Arquitecto Programador/Desarrollador/Ingeniero de Software Probador/Asegurador de la Calidad Administrador de Bases de Datos

Usuario

Líder de proyecto

Analista

CIBERTEC

Representa a la persona u organización que solicita la creación de un sistema a un área de desarrollo y quien lo paga. Es con quien se negocia el tiempo, costo y alcance del proyecto. Pueden o no ser usuarios del sistema. Son las personas que interactuarán con el sistema. Proporcionan información fundamental para el éxito del proyecto, ya que conocen y conviven con los procesos diarios Por parte del equipo de desarrollo, es el representante ante el cliente. Es la persona responsable de completar el proyecto exitosamente con los recursos dados. Su labor se enfoca a la ingeniería de requerimientos, los identifica, analiza, modela y documenta. Establece contacto directo con los usuarios y utiliza diversas técnicas de comunicación y de recopilación de información para lograr su objetivo

Administración

Validación y verificación

Análisis y Negociación

Cliente

Descripción

Obtención

Rol

Modelado y Especificación

Los principales roles involucrados en el proceso de ingeniería de requerimientos, así como las actividades en las que tienen mayor participación se presentan en el siguiente cuadro:

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Programador

Asegurador de la Calidad

Con base en los requerimientos recibidos de los ingenieros de requerimientos, el programador realiza la codificación para producir el sistema deseado Garantiza el cumplimiento del proceso y de los estándares del producto. Enfocado a los requerimientos los verifica y válida para imprimir la calidad desde las primeras etapas del desarrollo. Paralelamente prepara planes de prueba para esos requerimientos del sistema.

Rol de los clientes y usuarios El usuario es el experto en sus necesidades y sus procesos de negocio. Es quien debe comunicar estas necesidades claramente a los desarrolladores de software. Está involucrado directamente con los procesos de la organización y es quien finalmente operará el sistema. Los clientes son quienes financian el proyecto y los que recibirán directa o indirectamente los beneficios de éste. Ellos juegan un papel muy importante en la toma de decisiones y en la negociación del proyecto. Para promover una adecuada participación de los usuarios, es necesario tener en cuenta lo siguiente:   

  



Los usuarios están capacitados en su área de negocio pero no necesariamente en sistemas, cómputo e informática. El usuario pretende facilitar sus tareas, pero también proteger sus intereses. Los usuarios requieren atención periódica. Después de que se obtuvieron todos los requerimientos de su parte, es importante informarles del avance, presentarles entregables y mantenerlos en contacto. A los usuarios básicamente les interesa conocer las generalidades del sistema en términos de los beneficios que van a obtener, sin tecnicismos ni complicaciones. La flexibilidad del sistema y la facilidad de uso son consideraciones clave para los usuarios. Algunas veces lo usuarios solicitan 10 características y realmente necesitan 1. El total de los requerimientos recibidos del usuario debe ser reducido a los que sean necesarios, suficientes, controlables y viables de realizar. A veces no es posible tener contacto con toda la comunidad de usuarios, por lo que se debe tener un representante que presente opiniones consensuadas al equipo de desarrollo y que tenga autoridad suficiente para tomar decisiones relacionadas con el proyecto.

Karl Wiegers, en su artículo “Derechos y responsabilidades de los Usuarios” presenta una entretenida lista de aspectos a considerar con los usuarios:

Derechos de los usuarios:   

Que los analistas hablen su mismo lenguaje. Que los analistas aprendan sobre los objetivos del negocio y del sistema. Que los analistas traduzcan las necesidades presentadas en especificaciones de software.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

      

Contar con desarrolladores que expongan los productos de trabajo de requerimientos. Tratar con desarrolladores que mantengan el respeto y una actitud profesional. Contar con analistas que presenten ideas y alternativas tanto en los requerimientos como en la implementación. Describir características que harán el producto fácil de usar. Ser informado de alternativas y oportunidades para adaptar los requerimientos y permitir la reutilización de modelos ya existentes. Recibir adecuadas estimaciones de costo y acuerdos cuando se requieran cambios en los requerimientos. Recibir un sistema que contenga la funcionalidad y calidad esperadas.

Responsabilidades de los usuarios:          

Instruir a los analistas sobre el negocio y definir el vocabulario de su área. Invertir tiempo en proporcionar requerimientos y aclarar dudas. Ser específico y preciso sobre las necesidades del negocio y los requerimientos del sistema. Tomar decisiones a tiempo sobre los requerimientos. Respetar las estimaciones de costo y viabilidad del equipo de desarrollo. Fijar prioridades para requerimientos individuales, característicos del sistema o casos de uso. Revisar los documentos de requerimientos y los prototipos. Comunicar prontamente los cambios a los requerimientos del producto. Seguir el proceso de cambio de los requerimientos. Respetar el proceso de ingeniería de requerimientos que usan los desarrolladores.

Rol de los analistas El equipo de desarrollo, y en específico los analistas (ingenieros de requerimientos) deben comprender los problemas del usuario, su cultura y su lenguaje, así como presentar propuestas de solución comprensibles a los usuarios que cubran sus necesidades y expectativas. Karl E. Wiegers en su artículo “Hábitos de los analistas efectivos, sugiere las siguientes tareas del analista: 



Mejorar la comunicación entre los clientes y el equipo de desarrollo. El analista es un hombre intermediario en la comunicación. Debe primero comprender las necesidades actuales del usuario para luego definir un conjunto de requerimientos funcionales y objetivos de calidad que permitirán a los diseñadores, programadores y probadores, construir y verificar el sistema. Aprender y usar el vocabulario del dominio del problema, más que forzar a los clientes a comprender la jerga informática. Incluir los términos del negocio en un glosario, el cual deber ser parte de la documentación de requerimientos. Escuchar y comprender a los usuarios para orientar adecuadamente sus puntos de vista en el producto. Tomar en cuenta las expectativas implícitas y características como: desempeño, facilidad de uso, eficiencia y fiabilidad. Escribir requerimientos de alta calidad en documentos bien organizados. Que puedan ser revisados por otros analistas, representantes de los usuarios, desarrolladores y probadores. Hacer preguntas significativas, que permitan obtener información clave para el sistema.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II



 

Priorizar a tiempo y frecuentemente los requerimientos. Tratar de construir primeramente las características más críticas. Aunque para los usuarios todo tiene la máxima prioridad, el analista debe negociarlo e identificar las características realmente necesarias y las características urgentes. Crear un ambiente colaborativo, ya que finalmente los usuarios van a tener lo que necesitan; la organización que desarrolla va a ofrecer un producto adecuado y los desarrolladores van a construir un buen sistema. La participación del usuario es un factor clave. Aplicar eficazmente herramientas y buenas prácticas de ingeniería de requerimientos. Capacitarse y pulir sus habilidades en el uso y aplicación de técnicas de comunicación, escritura, modelado, entre otras. Un analista competente debe combinar habilidades de comunicación y relaciones interpersonales. Por ejemplo, técnicas para liderar mesas de trabajo, para entrevistar y platicar con individuos y grupos; habilidades de escuchar y escribir; habilidades interpersonales para negociar prioridades y resolver conflictos entre los involucrados en el proyecto; tener credibilidad y conversar efectivamente, así como habilidades de modelado.

Rol del líder de proyecto El Líder de Proyecto es el representante ante el cliente, coordina al equipo de trabajo y tiene la responsabilidad de terminar el proyecto satisfactoriamente con los recursos asignados. Algunas de las principales tareas del Líder de Proyecto son            

Coordinar al equipo de trabajo. Estimar el tiempo, el costo y los recursos estimados para realizar el proyecto. Planear y dar seguimiento a dichos planes. Conducir el proceso de obtención de requerimientos. Manejar y resolver los conflictos de los involucrados. Lograr la definición del conjunto de características que proporcionarán el más alto valor a la mayor cantidad de involucrados. Definir la visión del producto. Negociar con los directivos, usuarios y desarrolladores. Mantener una estrecha relación entre lo que el cliente desea y lo que el equipo de desarrollo puede entregar en un tiempo determinado. Ser el canal oficial entre el cliente/usuario y el equipo de desarrollo. Comunicar las características de las versiones a los involucrados. Revisar las especificaciones de software para asegurarse que cumplan con la visión del producto. Administrar los cambios de prioridad en requerimientos, así como la adición y supresión de características

1.2.2. Obtención de requerimientos La obtención de requerimientos es la consecución de los requerimientos y restricciones de los involucrados en el sistema, del dominio de la aplicación, del ambiente operacional del sistema y de la organización.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Fuentes de requerimientos Los requerimientos del sistema son obtenidos de diversos orígenes, por ejemplo de la consulta con los involucrados, de documentos relacionados, del conocimiento del dominio y otras como son:         

Estudios de mercado sobre las necesidades de informatización de las organizaciones similares. Comentarios de los usuarios sobre los sistemas actuales, los procesos de negocio o la problemática de la organización. Especificaciones generales preparadas por los usuarios con las necesidades básicas del área. Documentos de organización y procedimientos. Observaciones, salidas y medidas de los sistemas actuales. Entrevistas con los clientes y usuarios. Documentación de los sistemas actuales. Modelos y prototipos. Información sobre otros productos de software en el mercado que cubran necesidades similares.

Problemática en la obtención de requerimientos La obtención de requerimientos, no es tan fácil. Ian Sommerville, por ejemplo menciona los siguientes problemas: 

   

 



  

La mayoría de las veces, los involucrados no saben lo que realmente quieren del sistema, les es difícil articularlo o hacen peticiones no viables por el costo que ello implica. Los clientes expresan los requerimientos en sus propios términos, que nos son comprendidos por el equipo de desarrollo. Diferentes involucrados tienen diferentes requerimientos y son expresados de diferente manera. Aspectos organizacionales y políticos influyen en los requerimientos del sistema. Estos factores muchas veces no son obvios. El ambiente económico y de negocio del sistema es muy dinámico. Hay cambios durante la obtención de requerimientos. Además agregaríamos otros aspectos como: Algunas veces los clientes y usuarios no están consciente de la importancia de esta actividad y no le dedican el tiempo necesario o no proporcionan información completa y veraz. Las organizaciones no tienen documentados sus procesos, no están actualizados estos documentos o en la realidad no se llevan a cabo como se especifica. Los usuarios desean ver resultados rápidos en términos de código. Internamente en su organización, los usuarios no se ponen de acuerdo en sus necesidades, políticas y estrategias para la incorporación de un sistema. Los usuarios desean la mayor cantidad de características del sistema en tiempo récord y con bajo costo.

No obstante existen técnicas y herramientas que nos ayudan a lograr una identificación y obtención de requerimientos exitosas; algunas de éstas se mencionan más adelante.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Identificación del problema Para la adecuada identificación de los requerimientos es necesario realizar una actividad clave: analizar el problema. El análisis del problema es el proceso de comprender los problemas del mundo real y las necesidades del usuario para posteriormente proponer soluciones que cubran estas necesidades. El objetivo es ganar una mejor comprensión, antes de empezar el desarrollo del problema a resolver. Esta actividad implica comprender el “dominio del problema” para pasar de éste al “dominio de la solución”. Dean Leffingwell y Don Widrig sugieren los siguientes pasos del análisis del problema en el desarrollo de software: 1. Definir del problema. Por escrito, describir el problema, a quién afecta, en qué impacta y ver si todos los involucrados están de acuerdo en que ese es el verdadero problema. 2. Descubrir las causas raíces, “el problema detrás del problema”. Muchas veces se tienen síntomas pero no son los problemas reales. 3. Identificar a los involucrados, es decir cualquier persona que puede ser afectada materialmente por la implementación de un nuevo sistema o aplicación, especialmente a los usuarios. 4. Definir los límites entre la solución y el mundo real. Esto nos ayudará a delimitar el alcance y a precisar las fronteras del sistema. 5. Identificar las restricciones de la solución. Estas restricciones son muy importantes ya que orientan o dictan la solución, y puede ser de tipo: económico, político, técnico, ambiental, de recursos, entre otros. Además, posteriormente se convertirán en requerimientos no funcionales del sistema. Es importante mencionar que no todos los sistemas y aplicaciones son desarrollados para resolver un problema, algunas veces se construyen para tomar ventaja de oportunidades que se presentan en el mercado, para mantenerse actualizados tecnológicamente o para lograr una mayor competitividad. O bien, también hay que considerar que muchas veces la solución del problema no es un sistema nuevo, sino más bien una revisión de los procesos de negocio, capacitación de las personas o cambios en la cultura organizacional.

1.2.3. Análisis y Negoción de requerimientos Después de que se ha identificado un conjunto de requerimientos, es necesario analizarlos para descubrir conflictos, traslapes, omisiones e inconsistencias. El objetivo del análisis y negociación de requerimientos tiene como finalidad obtener un conjunto acordado de requerimientos completos, consistentes y no ambiguos, los cuales se usarán como base para el desarrollo del sistema. Dentro de esta actividad los requerimientos son analizados en detalle y deben pasar por un proceso formal de negociación y resolución de conflictos en el que participen los involucrados para llegar a un acuerdo. Se descubren requerimientos faltantes, conflictos entre los requerimientos y requerimientos no viables, además de que estos deben ser clasificados y priorizados.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

El análisis y negociación de requerimientos aplica generalmente a los requerimientos de alto nivel, es decir a los requerimientos de sistema o de usuario. Para realizar el análisis de requerimientos se requiere habilidad y experiencia para revisar cuidadosamente los documentos y pensar en las características, riesgos e implicaciones de cada uno. El proceso de negociación por su parte tiene como intención establecer compromisos que satisfagan a todos los involucrados. Esta última no es una actividad simple, ya que influyen factores organizacionales, políticos y personales de los involucrados. El análisis y la obtención de requerimientos son procesos estrechamente relacionados. Muchas veces conforme se van obteniendo requerimientos, paralelamente se van analizando y en ese momento se resuelven posibles conflictos, o en su caso se debe volver a la actividad de obtención. Para el análisis y la negociación de requerimientos son fundamentales las siguientes actividades: establecer el alcance del proyecto, así como clasificar y ponderar los requerimientos. El objetivo del análisis es descubrir problemas en los requerimientos; no es propiamente una actividad de administración de la calidad. Definición del alcance del proyecto Definir los límites del sistema es una actividad clave en el análisis y negociación. Se debe establecer un conjunto acordados de requerimientos del sistema a desarrollar. Determinar cuáles son requerimientos de sistema, cuáles son del proceso de negocio y cuáles salen del alcance del sistema. Esto no es siempre fácil, dado que la mayoría de los clientes y usuarios desean que el sistema a desarrollar les ofrezca la mayor funcionalidad como sea posible, comprometiendo con ello la calidad, la viabilidad y el éxito del proyecto. Según Dean Leffingwell y Don Widrig, el alcance del proyecto está en función de tres factores: 1. 2. 3.

La funcionalidad que se debe proporcionar a los usuarios. Los recursos disponibles para el proyecto (equipo de trabajo, tecnología y presupuesto). El tiempo disponible.

Una estrategia para establecer claramente el alcance es establecer líneas base. Una línea base es “Un conjunto detallado de características, o requerimientos que se pretenden entregar en una versión específica de la aplicación”. Una línea base debe ser aceptable por el cliente y tener una probabilidad razonable de éxito, desde el punto de vista del equipo de desarrollo. Para establecerla es importante considerar lo siguiente: Tener una lista de las características identificadas. Clasificar y ponderar cada característica, tanto por los clientes, usuarios, equipo de desarrollo y otros involucrados claves, y mínimo desde las siguientes perspectivas: importancia, esfuerzo requerido y riesgo.



CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Con base en lo anterior, es posible obtener la línea base de un conjunto de características para determinar el alcance del proyecto de acuerdo con los factores mencionados anteriormente: funcionalidad, recursos y tiempo. Para un proyecto se establecen tantas líneas base como se quieran, dependiendo también de la estrategia y la metodología de desarrollo. Se recomienda establecerlas para lograr liberaciones diversas del producto, dividir el proyecto en fases, y minimizar así el riesgo asociado. Línea base Una línea base está integrada por un conjunto de elementos de software generados en una fase del ciclo de vida de un producto, revisados y aprobados que.   

Representan una base acordada para continuar el desarrollo, Pueden ser una especificación o un producto revisado que posteriormente servirán como base en el desarrollo y mantenimiento del producto de software, Pueden ser modificadas mediante procedimiento de control formales tales como la Administración de la Configuración

Una línea base formal es un producto, usualmente documentos que han sido expresamente revisados y acordados por el cliente, el usuario y el equipo de desarrollo, y el cual sirve como fundamento para el desarrollo subsecuente. Un sistema de administración de configuración es precisamente el mecanismo para mantener las diversas líneas base. Clasificación y ponderación de los requerimientos En el proceso de análisis y negociación se establecen valores para un conjunto de atributos de los requerimientos. Los principales atributos son: estado, prioridad y riesgo. El estado nos indica el progreso de los requerimientos durante el ciclo de vida de desarrollo. Desde el punto de vista de la aceptación de los requerimientos, los tres estados más comúnmente utilizados son: 

 

Propuesto. Requerimientos que están bajo discusión o negociación pero que todavía no son revisados y aceptados por el canal oficial, es decir por el conjunto de personas (clientes y equipo de desarrollo) que dan el visto bueno a un requerimiento. Aprobado. Requerimientos útiles y factibles de realizar que han sido aprobados por el canal oficial para su implementación. Incorporado. Requerimientos o características incorporadas dentro de una línea base del producto en un tiempo específico.

El equipo de desarrollo en conjunción con los clientes y otros involucrados deben participar en la clasificación y ponderación de requerimientos. La prioridad debe reflejar la importancia para los involucrados y para el éxito del proyecto. Asignar prioridades permite a los involucrados decidir sobre los requerimientos medulares para el sistema, orientar la arquitectura del sistema, resolver conflictos y establecer líneas base. Las prioridades deben ser acordadas por ambas partes.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

La prioridad, comprende tres posibles valores  Crítico o Esencial. Representan requerimientos esenciales. Si se falla en su implementación significa que el sistema no satisfará las necesidades del usuario. Todas las características críticas deben ser implementadas.  Importante. Representan requerimientos importantes para la efectividad y eficiencia del sistema. La funcionalidad no puede ser fácilmente proveída de otra manera. El no incluirlos puede afectar la satisfacción de los clientes y usuarios, pero una liberación de una versión no será retrasada por la falta de una característica importante.  Deseable. Representan requerimientos de utilidad que serán usados con menor frecuencia. De no ser incluidos, no se tiene un impacto significativo en la satisfacción del usuario. Otro atributo clave es el riesgo asociado a cada requerimiento. El riesgo es la probabilidad de que el requerimiento sea causa de eventos indeseables, como mayores costos, retrasos, o cancelación. Algunos aspectos de riesgo pueden ser: complejidad del requerimiento, tecnología para implementar el requerimiento, tamaño del requerimiento, entre otros. Por cada conjunto de requerimientos es recomendable realizar un análisis de riesgos. El análisis de riesgos es un proceso analítico que implica conocimiento, experiencia y juicio de los involucrados para determinar dos atributos básicos del riesgo: el impacto en el proyecto y la probabilidad de ocurrencia. El impacto del riesgo en los requerimientos puede ser:   

Bajo. El requerimiento representa un riesgo leve para el proyecto. Medio. El requerimiento representa un riesgo considerable para el proyecto. Alto. El requerimiento representa un riesgo grave para el proyecto.

Con base en esta ponderación, los requerimientos que conviene implementar primeramente son los más importantes y de mayor riesgo. Existen otros atributos que también deben ser valorados durante el análisis de requerimientos como son: 



 



Esfuerzo. Estimación del número de personas, horas hombre, líneas de código, puntos de función, entre otras. Este atributo es importante para definir adecuadas líneas de base. Estabilidad. Una medida de la probabilidad de que la característica cambiará o que la comprensión del equipo de desarrollo respecto a la característica cambiará. Permite establecer prioridades y determinar cuáles aspectos retomar en encuentros próximos con los involucrados. Versión destino. Especifica la versión del producto estimada en la cual aparecerá la característica por primera vez. Asignado a. En muchos proyectos, las características son asignadas a “equipos de características” responsables de la obtención, especificación quizá implementación de la misma. Razón. Fuente de la característica requerida. Por ejemplo, la referencia a algún documento, objetivo de negocio, disposición legal o a una importante entrevista con el usuario.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Guía para el análisis de requerimientos A continuación se presenta una breve serie de preguntas útiles para el análisis de requerimientos: GUÍA PARA EL ANÁLISIS DE REQUERIMIENTOS            

¿El requerimiento es acorde con los objetivos del negocio y el alcance del proyecto? ¿El requerimiento entra en conflicto con alguna restricción de dominio, política o regulación? ¿Es necesario el requerimiento? ¿El requerimiento se traslapa o entra en conflicto con otro? ¿El requerimiento es viable económica y técnicamente? ¿El requerimiento exige cumplir con algún estándar de hardware o software? ¿El requerimiento es viable dada la tecnología y recursos disponibles para implementar el sistema? ¿La descripción de un requerimiento describe un solo requerimiento o debe ser dividido en varios requerimientos distintos? ¿A cada requerimiento se le ha asignado un estado, prioridad y riesgo? ¿Se ha considerado la portabilidad confiabilidad, facilidad de uso y facilidad de mantenimiento para el sistema? ¿Están claramente definidos los alcances del proyecto y del sistema? ¿Se han establecido líneas base basadas en requerimientos?

Recomendaciones Algunas recomendaciones en el análisis y negociación de requerimientos se presentan a continuación:  

 



  

Negociar fechas, precio y alcance de forma que sea satisfactorio para el cliente y viable para el equipo de desarrollo. En la medida de lo posible, planear la posible ocurrencia y resolución de conflictos. Favorecer encuentros cara a cara en los que se resuelvan los conflictos. No pasar por alto la ponderación de requerimientos, es un mecanismo importante en la planeación y gestión del riesgo. Clasificar los requerimientos usando un enfoque multidimensional. Esto permite ubicar la relación entre los requerimientos y cuando ocurre un cambio, conocer los requerimientos afectados. Ejemplos de clasificaciones para agrupar requerimientos son: de sistema, de interfaz de usuario, de base de datos, de comunicaciones, de seguridad, entre otras. Usar matrices de interacción para encontrar conflictos y traslapes. Una matriz de interacción es una matriz donde las columnas y renglones son etiquetadas con identificadores de los requerimientos, el valor en la intersección entre dos requerimientos indican la dependencia o conflictos entre estos. Identificar cada requerimiento de manera única. Registrar la fuente de cada requerimiento. (Quién lo propuso, de dónde surgió). Evaluar el riesgo de los requerimientos.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

1.2.4. Modelado y especificación de requerimientos La especificación de requerimientos es la actividad en la cual se genera el documento que contiene la descripción completa de las características y funcionalidades del sistema, así como su alcance. Es por lo tanto la representación y documentación de los requerimientos funcionales y no funcionales del sistema o del software. Comúnmente se le llama especificación de requerimientos de software (SRS por sus siglas en inglés) al documento que contiene la definición completa de los requerimientos de software. Este documento describe de manera clara y precisa cada uno de los requerimientos esenciales (funciones, desempeño, restricciones de diseño y atributos de calidad) del software y sus interfaces externa El documento de requerimientos de sistema es útil para diversas personas:     



Los clientes y usuarios del sistema quienes así validan que los requerimientos son adecuados a sus necesidades. Los líderes de proyecto para planear, costear y calendarizar el desarrollo del sistema. Los ingenieros de software y arquitectos del sistema responsables de diseñar e implementar el sistema. Los probadores, quienes usan el documento para generar pruebas y verificar que el sistema desarrollado satisfaga los requerimientos. El personal que mantiene y modifica el sistema, para comprender las características iniciales del sistema y las relaciones entre las diferentes partes del sistema. Los documentadores que realizan los manuales de usuario y técnicos, con base en la funcionalidad requerida y ofrecida por el sistema.

1.2.4.1. Características deseables en las especificaciones De acuerdo con el estándar 830 de la IEEE, para que las especificaciones de requerimiento cumplan características de calidad, deben ser: Atributo

Correctas Sin ambigüedad Completas

Consistentes

Verificables

CIBERTEC

Descripción

Una especificación de requerimientos de software es correcta sí y solo sí cada requerimiento representa algo realmente necesario del sistema por construir. El usuario también valida que sean correctos. Un requerimiento es no ambiguo si y sólo si puede ser sujeto a una sola interpretación por distintas personas. Un requerimiento está completo si no necesita ampliar detalles para expresar la funcionalidad que expresa; es decir, si proporciona la información suficiente para su comprensión. Un requerimiento es consistente si y sólo si está redactado conforme a su objetivo específico y no entra en conflicto con otros requerimientos. Un requerimiento es verificable si y sólo si cada uno de los componentes contenidos en el requerimiento se pueden probar. Los requerimientos pueden ser considerados verificables si y sólo si existe un proceso finito con el cual una persona o máquina pueden determinar que el sistema de software desarrollado satisfaga los requerimientos

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Un requerimiento es modificable si y sólo si su estructura y estilo son tales que cualquier cambio puede ser hecho de Modificables forma fácil, completa y consistente, conservando la uniformidad y estructura con los demás. Un requerimiento se puede rastrear si y sólo si el origen de Con cada uno de sus componentes es claro, y si existe un posibilidad mecanismo que haga posible referirse al requerimiento a lo de rastreo largo del ciclo de desarrollo. Esta característica es importante para reflejar cambios y evaluar el impacto de éstos. Un conjunto de requerimientos es comprensible si tanto la comunidad de usuarios como de desarrolladores son Comprensibles capaces de comprender plenamente los requerimientos por separado y la funcionalidad total del sistema. Otras características deseables que sugieren otros autores son las siguientes:

Factibles

Debe ser evaluado para que se pueda realizar con los recursos (financieros, tecnológicos, técnicos, legales) disponibles.

Independientes de la Debe indicar el “qué” no el “cómo”. implementación En relación con esta última característica, los requerimientos describen lo que el sistema debe hacer y el diseño describe cómo los requerimientos serán cumplidos. No obstante la relación entre los requerimientos y el diseño puede ser circular. Por ejemplo un requerimiento de sistema (característica) es el “qué” de un requerimiento de software, el cual en este caso puede interpretarse como un “cómo”. Tomando como referencia el mismo requerimiento de software puede ser un “qué” con respecto al diseño detallado. Para asegurar que una sentencia de requerimiento de sistema representa una necesidad y no una implementación, Richard Hardwell recomienda preguntar “por qué” el requerimiento es necesario. La respuesta debe ser una necesidad real. 1.2.4.2. Técnicas para el modelado y especificación Existen varias técnicas para el modelado y especificación de requerimientos tales como:  Casos de Uso  Prototipos  Otras técnicas de especificación Casos de Uso.- Un caso de uso es una descripción de un conjunto de acciones que el sistema realiza para ofrecer algún resultado de valor a un actor en particular. [Booch] “Los Casos de Uso han sido adoptados casi universalmente para la captura de requisitos de sistemas software en general, y de sistemas basados en componentes en particular...” Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al usuario un resultado importante. Los casos de uso representan los requerimientos funcionales. Todos los casos de uso juntos constituyen el modelo de casos de uso, el cual describe la funcionalidad total del sistema.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

El modelo de casos de uso está compuesto por todos los actores y todos los casos de uso de un sistema. Un diagrama de casos de uso describe parte o todo el modelo de casos de uso y muestra un conjunto de casos de uso y actores asociados. Este modelo sirve como un medio de comunicación entre el equipo de desarrollo y puede servir como un contrato entre el cliente, los usuarios y el equipo de desarrollo sobre la funcionalidad total del sistema. Permite que los clientes y usuarios validen que el sistema hará lo que ellos esperan y el equipo de desarrollo construya lo esperado. Normalmente, un sistema tiene muchos tipos de usuarios. Cada tipo de usuario se representa con un actor. Los actores utilizan el sistema interactuando con los casos de uso. 1.

Usuarios de los Casos de Uso

Los Casos de Uso resultan de gran utilidad para:         2.

Los clientes, ya que así visualizan, validan y aprueban lo que el sistema debe hacer. Los usuarios porque ganan entendimiento del sistema. Son los destinatarios de las acciones del sistema y pueden complementar el modelo. Los analistas, ya que les proporciona las bases para el análisis y diseño conceptual. Los desarrolladores, que les sirve como documento del comportamiento del sistema para implementar el software con la funcionalidad de los casos de uso. Los probadores que los usan como base para las pruebas de los distintos escenarios del sistema. El líder del proyecto para establecer el alcance, determinar la planeación y los recursos del proyecto. Al documentador le sirve como base para el manual de usuario. A los demás involucrados del negocio les permite comprender las características del sistema y replicarlas. Beneficios

Existen varios motivos por los cuales los casos de uso son buenos, se han hecho populares y se han adoptado universalmente    

 



Proporcionan un medio sistemático e intuitivo de capturar requerimientos funcionales, centrándose en el valor agregado para el usuario. Dirigen todo el proceso de desarrollo debido a que las actividades subsecuentes toman como base los requerimientos funcionales. La perspectiva que proporcionan los casos de uso apoyan la creación de productos enfocados a los clientes. El modelo de casos de uso se utiliza para conseguir un acuerdo con los usuarios y clientes sobre qué debería hacer el sistema. Esta especificación puede utilizarse como parte del contrato con el cliente. Los casos de uso son intuitivos por lo que los clientes y usuarios no tienen que aprender una notación compleja. Los casos de uso ayudan a los jefes de proyecto a planear, asignar y controlar muchas de las tareas que los desarrolladores realizan. A partir de los casos uso se puede estimar el tamaño del proyecto y los recursos necesarios. Los casos de uso ayudan a llevar a cabo el desarrollo iterativo. Cada incremento del desarrollo es una realización funcional de un conjunto de casos de uso.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

        

Los casos de uso se utilizan como punto de partida para escribir el manual de usuario, ya que cada caso de uso describe una forma de utilizar el sistema. Los casos de uso son un método poderoso para comprender los requerimientos desde un punto de vista del usuario del negocio. Son relativamente fáciles de escribir, escritos en el lenguaje del usuario y comprendidos tanto por el usuario como por el desarrollador. Los escenarios de los casos de uso pueden servir como guía de prueba. Facilitan el re-uso. Se enfocan en el “qué”. Identifican a los usuarios y los límites del sistema. Identifican las interfaces del sistema. El UML en un estándar de la industria y es soportado por diversas herramientas de modelado.

Prototipos Un prototipo es un modelo (representación, demostración o simulación) fácilmente ampliable y modificable de un sistema, probablemente incluyendo su interfaz y su funcionalidad de entradas y salidas. Un prototipo de requerimientos de software es una implementación parcial del sistema de software, que ayuda a los desarrolladores, usuarios y clientes a representar, comprender mejor y validar los requerimientos del sistema. Permiten por un lado identificar que algo no es lo que el usuario quiere, así como nuevos requerimientos. Por ser desarrollados tempranamente pueden ayudar a eliminar el riesgo y son efectivos porque permiten al usuario interactuar con un prototipo en su ambiente, el cual da un acercamiento al mundo real. Los prototipos pueden ser:      

Prospectos o experimentales. Prototipos no reutilizables, utilizados para definir las metas del proyecto, identificar nuevos requerimientos y validarlos. Evolutivos u operacionales. Prototipos iterativos que son progresivamente refinados hasta que se convierten en el sistema final. Verticales. Modelan pocas características de un sistema pero con mucho detalle. Horizontales. Prototipo que modela muchas características de un sistema pero con poco detalle. De interfaces de usuario. Representan el diseño, contenido, organización y secuencia de la interfaces del sistema; no tienen ninguna funcionalidad. Algorítmicos. Implementan todo o alguna una parte de un cálculo o proceso.

Algunas herramientas útiles para el desarrollo de prototipos son:      

Papel y lápiz. Software de diseño como Visio o Corel. Software para desarrollar presentaciones como PowerPoint. Software de animación y presentaciones como Flash, Director y Cinemation. Herramientas visuales para RAD, como Visual Basic y Borland Delphi. Herramientas de mockups.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Otras técnicas de especificación Existen además diversas técnicas de especificación, algunas de las cuales complementan a los casos de uso y prototipos; otras se utilizaron hace algunos años con los lenguajes estructurados. A continuación se da una breve descripción de éstas. 

 



Lenguaje Natural. Redactar en un documento los requerimientos en lenguaje natural y sin formalidad puede ser una alternativa de especificación, no obstante puede resultar incompleto y ambiguo. El lenguaje natural generalmente complementa y hace más explícitas otras técnicas de especificación. Pseudocódigo. Combina la informalidad del lenguaje natural con la sintaxis y las estructuras de control de un lenguaje de programación. Máquinas de estado finito. Una máquina hipotética que puede estar en uno y sólo un número determinado de estados en un tiempo específico. Se representan generalmente con los diagramas de estado. Tablas y árboles de decisión. Cuando se requiere representar el comportamiento de que distintas combinaciones de entradas, ofrecen determinadas salidas. Modelos entidad-relación. Si los requerimientos dentro de un conjunto involucran una descripción de la estructura y relaciones entre datos es conveniente utilizar un modelo entidad-relación. Análisis Estructurado (SA). Especifica los requerimientos mediante procesos, flujos de información y almacenamientos. Utiliza diagramas de contexto, de flujo, de flujo de datos (DFD), diagramas modulares y diagramas entidad-relación. Análisis y Diseño Orientado a Objetos. Mediante la notación de UML, se modela el sistema con una perspectiva de objetos, en la que un objeto es una entidad que conjunta características (datos) y operaciones (procesos). Los casos de uso como parte de UML modelan los requerimientos

1.2.4.3. Modelado del dominio y modelado del negocio Un modelo de dominio captura los tipos más importantes de objetos en el contexto del sistema. Los objetos representan las “cosas” que existen o los eventos que suceden en el entorno en que trabaja el sistema. El modelado del negocio es una técnica para comprender los procesos de negocio de la organización. Un modelo de casos de uso del negocio describe los procesos de negocio de una empresa en términos de casos de uso del negocio y actores del negocio Es una vista externa del negocio. En este caso el sistema es el negocio. Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cómo cada caso de uso de negocio es llevado a cabo por parte de un conjunto de trabajadores que utilizan un conjunto de entidades de negocio y unidades de trabajo. El modelado de negocio se usa en los sistemas de aplicación específica. Su propósito es comprender la estructura y dinámica de la organización y asegurar que los clientes, usuarios finales y desarrolladores tengan una comprensión general de la misma. 1.2.4.4. Guía de contenido para la especificación de requerimientos No existe una guía única para la especificación de requerimientos; muchas veces dependen el tipo de proyecto y del enfoque de la organización. Existen sin embargo diversas propuestas para especificar los requerimientos, por ejemplo: el estándar 830-

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

1984 de la IEEE, las plantillas del Proceso Unificado de Rational, la guía de VOLERE, además de otras que los autores proponen o complementan en sus obras A continuación se presenta una guía general que integra los principales aspectos de todas estas propuestas, considera los Casos de Uso como parte de la especificación de los requerimientos funcionales y además incorpora otros elementos que en la práctica resultan útiles. Considera por ejemplo, algunos aspectos generales de la administración del proyecto, que si bien deben ser detallados en un documento específico, algunas veces conviene incluir aspectos clave para ubicar mejor el contexto. También cabe resaltar que se integró una parte relacionada con el modelado de negocio para comprender la estructura y procesos de la organización. La guía cubre diversos aspectos genéricos, pero puede adaptarse al tipo de organización, al tipo de proyecto, e incluso a quien va dirigido el documento GUÍA DE CONTENIDO PARA LA ESPECIFICACIÓN DE REQUERIMIENTOS I.

INTRODUCCIÓN

1. 2.

Presentación. Presentación y objetivo del documento. Convenciones. Aspectos tipográficos para comprender mejor el documento, así como definiciones, acrónimos y abreviaciones. Propósito y alcance. Objetivo del producto. Breve descripción del producto, alcances y beneficios del mismo. Problemática que resuelve. Necesidades o deficiencias que satisface el producto. Contraste con los beneficios. Justificación. Clientes, usuarios e involucrados. En caso de tratarse de un producto a vender se refiere a los clientes y usuarios potenciales. Para un sistema específico, los roles,

3. 4. 5.

II.

CONTEXTO DE LOS USUARIOS Y LA ORGANIZACIÓN (AMBIENTE OPERACIONAL)

Objetivos de la organización. Antecedentes, misión y objetivos de la organización destinataria del proyecto Estructura de la organización. Organigrama, áreas involucradas, y distribución regional de relevancia para el sistema. Área o usuarios finales del sistema. Modelado del negocio. Procesos actuales de la organización relevantes para el sistema.

7. 8. III.

9. 10. 11. 12.           

REQUERIMIENTOS

Requerimientos Funcionales Modelo de Casos de Uso. Diagrama general de los casos de uso del sistema. Descripción de los Actores. Breve descripción de los actores. Concentrado de los requerimientos funcionales. Matriz concentrada de los casos de uso con sus atributos: tipo, estado, prioridad, riesgo, etc. Especificaciones de los Casos de Uso Casos de Uso 1 Identificador Nombre Pre-condiciones Flujo principal Flujos alternos Flujos de excepción Post-condiciones Casos de Uso 2 Casos de Uso n

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

13. 

  

    14.      

Requerimientos no Funcionales Apariencia y estilo. Descripción de las características de la Interfaces de usuario relacionadas con estándares de despliegue, resolución, distribución, menús, entre otros. Uso. Facilidad de operación y de aprendizaje, dependiendo de las habilidades y experiencia de los usuarios, así como de la complejidad del producto. Confiabilidad. Exactitud de los resultados esperados, tolerancia a fallas, facilidad de recuperación. Desempeño. Permite especificar el tiempo esperado para completar determinadas tareas, así como los volúmenes de procesamiento, de almacenamiento, de usuarios simultáneos, entre otros. Soporte y mantenimiento. Condiciones especiales de mantenimiento, de portabilidad, de configuración. Seguridad. Especificaciones de acceso, control y confidencialidad para conservar la integridad del sistema. Documentación del usuario y ayuda en línea. Lista de los productos de documentación del sistema requeridos. Aspectos de ayuda en línea. Otros. Por ejemplo, requerimientos de migración de información o reemplazo de un sistema anterior. Restricciones Legales. Violación de derechos de autor, contratos o licitaciones. Tiempo. Tiempo máximo de desarrollo. Presupuesto. Presupuesto disponible para el proyecto. De diseño. Plataforma, estándar, arquitectura a cumplir. Estándares. Estándares tanto de los clientes y usuarios como del grupo de desarrollo. Estándares de diseño, codificación y trabajo en grupo. Otras.

15. Requerimientos de Interfaces. Aspectos relacionados con la conectividad, comunicación y acceso hacia o desde componentes externos  Interfaces de hardware. Comunicación con dispositivos de hardware.  Interfaces de software. Compatibilidad con componentes comerciales.  Interfaces de comunicaciones. Protocolos e interfaces de comunicación IV.

   16.

ASPECTOS DEL PROYECTO

Estrategia de desarrollo. Fases del desarrollo, metodología a utilizar. Planeación general, recursos y tiempo estimados, riesgos a considerar Plataforma y requerimientos de desarrollo. Sistema operativo, lenguajes, manejadores de bases de datos y otras herramientas a utilizar. Entrega del producto. Licencias, distribución, instalación, protección del código fuente. Glosario de términos

1.2.4.5. Recomendaciones Además de las características de calidad de las especificaciones de requerimientos mencionadas anteriormente y las técnicas propuestas, se sugiere 17. 18.

Utilizar plantillas para documentar los requerimientos. Usar un lenguaje simple, consistente y conciso.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

19. 20.

    21. 22. 23. 24. 25. 26.

Usar apropiadamente los diagramas. Complementar con lenguaje natural los requerimientos descritos de otras formas. Especificar cuantitativamente los requerimientos, ya que esto sirve como base para las pruebas de aceptación. Es necesario decidir la métrica adecuada para describir el requerimiento y establecerle el valor adecuado. Por ejemplo: Desempeño. Número de transacciones por segundo, tiempo de respuesta para las entradas del usuario Almacenamiento. Tamaño máximo del sistema en KB. Facilidad de uso. Tiempo promedio para aprender el 75% de las facilidades. Robustez. Tiempo para restablecerse después de una falla. Modelar el ambiente del sistema. Hacer un modelado del negocio relacionado con el sistema. Modelar la arquitectura del sistema. Usar un glosario y diccionario de datos. Definir términos especializados. Documentar las ligas entre los requerimientos del sistema y los requerimientos de los involucrados (rastreo). Explicar cómo llenar y usar el documento plantilla Incluir un resumen o matriz de los requerimientos en el documento para facilitar la consulta y obtener una visión del tamaño y estado del proyecto.

1.2.5. Validación y verificación La validación y verificación permiten monitorear el proceso y los productos en el desarrollo de software. La validación y verificación (V&V) juegan un importante papel en el desarrollo de software con calidad. La validación es el proceso de asegurar que lo que se está construyendo corresponde con los realmente requerido, que sea completo, consistente y de acuerdo con los requisitos. La verificación es el proceso de determinar si los productos de una determinada fase del ciclo de desarrollo de software, cumplen o no los requerimientos establecidos durante el inicio de la fase. La validación asegura que el sistema trabaje conforme a los requerimientos especificados. La verificación es un proceso analítico que trabaja a lo largo del proyecto para asegurar que se estén haciendo las cosas bien. 1.2.5.1. Validación La diferencia entre el análisis de requerimientos y la validación, es que el análisis se realiza sobre los requerimientos de sistema iniciales obtenidos de los involucrados, en cambio, la validación comprueba el documento final de requerimientos. Esta última revisión debe realizarse tanto por el equipo de desarrollo como por el cliente. La IEEE define validación como: “El proceso de evaluar un sistema o componente durante o al final del proceso de desarrollo para determinar si satisface los requerimientos especificados “ Es decir, la validación permite confirmar que el sistema se haya implementado conforme a los requerimientos establecidos. Se puede realizar mediante 2 formas principalmente: pruebas de aceptación y pruebas de validación.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

 Pruebas de aceptación. Las pruebas de aceptación involucran al usuario en la actividad de validación final para asegurar que el producto opere en la forma que el usuario realmente necesita.  Pruebas de validación. Las actividades primarias de la validación son las actividades de prueba. Las pruebas de validación se realizan contra las especificaciones acordadas. 1.2.5.2. Verificación La IEEE define verificación como: El proceso de evaluar un sistema o componente para determinar si los productos de una determinada fase satisfacen las condiciones impuestas en el inicio de la fase. La verificación es un proceso continuo que nos ayuda a asegurar que cada paso del desarrollo sea correcto, y satisfaga las necesidades de la actividad siguiente. No es una actividad realizada sólo por el equipo de aseguramiento de la calidad si no que debe ser una filosofía de todos los grupos de trabajo, ya que es posible realizar verificación a todos los niveles: verificar los elementos de requerimientos, los elementos de diseño, los elementos de implementación, los elementos de prueba, etc. Hay un punto de verificación muy importante al final del proceso de desarrollo que casi nunca se considera: que el producto haya demostrado trabajar dentro del ambiente de los usuarios y que los usuarios estén satisfechos con los resultados. Los problemas más comunes en la verificación de requerimientos son referentes a la falta de cumplimiento de los estándares de calidad, la inadecuada especificación (mala redacción, ambigüedad), así como a conflictos entre los requerimientos que no fueron detectados durante el proceso de análisis.

1.2.5.3. Guía de para la validación y especificación de requerimientos Algunas preguntas útiles para la validación y verificación de requerimientos se presentan a continuación: GUÍA PARA LA VALIDACIÓN Y VERIFICACIÓN DE REQUERIMIENTOS              

¿Falta alguna información necesaria de los requerimientos? ¿Están completos? ¿Los requerimientos se encuentran dentro del alcance del proyecto? ¿Cada requerimiento se puede verificar de alguna manera? ¿Se puede probar? ¿Todos los requerimientos son escritos en un consistente y apropiado nivel de detalle? ¿Se ha verificado la gramática y ortografía de los documentos de requerimientos? ¿Son correctas todas las referencias a otros requerimientos? ¿Existen y se encuentran especificados? ¿Está indicada la prioridad de implementación de cada requerimiento? ¿Han sido definidos los algoritmos intrínsecos a los requerimientos funcionales? ¿Las especificaciones incluyen todas las necesidades del sistema y los usuarios? ¿Está documentado todo el comportamiento de las condiciones de error? ¿Algún requerimiento está duplicado o entra en conflicto con otro requerimiento? ¿Cada requerimiento está escrito en un lenguaje claro, conciso y sin ambigüedad? ¿Pueden ser implementados todos los requerimientos dentro de las restricciones conocidas? ¿Cada requerimiento es identificado de manera única?

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II



¿Cada requerimiento funcional de software puede ser trazado a los requerimientos de alto nivel? ¿Existe posibilidad de rastreo? ¿Es posible saber de dónde derivó el requerimiento? ¿Los requerimientos representan aspectos de diseño o soluciones de implementación?

1.2.6. Administración de requerimientos La administración de requerimientos consiste en organizar y mantener la información relacionada con los requerimientos a través de todo el ciclo de vida de desarrollo. Los principales aspectos de la administración de requerimientos son manejar: los cambios en los requerimientos, las relaciones entre requerimientos y sus dependencias Los problemas más comunes relacionados con la administración de requerimientos son: 1) los requerimientos no siempre son obvios y provienen de diversas fuentes, 2) no siempre son fáciles de expresar en palabras, 3) hay muchos tipos diferentes de requerimientos en diferentes niveles de detalle, 4) el número de requerimientos puede llegar a ser incontrolable si no se administra, 5) los requerimientos se relacionan unos con otros y se relacionan con otros artefactos del proceso de ingeniería de software, 6) los requerimientos cambian. Existe una definición muy conocida de Administración de Requerimientos de Rational Software: “Enfoque sistemático para obtener, organizar y documentar los requerimientos de un sistema, y establecer y mantener un acuerdo entre los clientes y el equipo de desarrollo del proyecto, sobre los cambios en los requerimientos del sistema”. No obstante existe una diferencia entre Ingeniería de Requerimientos y Administración de Requerimientos, la administración es una actividad de la ingeniería de requerimientos, y su objetivo es: Organizar y controlar la información y productos relacionados con los requerimientos, sus cambios y sus dependencias con otros a través de todo el ciclo de vida de desarrollo.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

A NÁ L I SI S Y DI SE ÑO D E SI S TE MA S I I

1.3. GESTIÓN DE REQUISITOS SEGÚN RUP En RUP, una descripción simplificada del proceso de gestión de requisitos contiene los siguientes pasos:        

Establecimiento de un plan de gestión de requisitos Captura de requisitos Desarrollo del documento Visión Creación de casos de uso Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema.

El primer paso, el plan de gestión de los requisitos, define los requisitos de la pirámide. En cada uno de los siguientes siete pasos, uno de los elementos de la pirámide es construido. Lo primero que debemos saber antes de iniciar la gestión de requisitos según RUP es la pirámide de requisitos de RUP.

1.3.1. Pirámide de requisitos Un requisito se define como una condición o capacidad a la que debe ajustarse el sistema que se construye para satisfacer un contrato, norma, especificación u otro documento formalmente impuesto. Dependiendo del formato, fuente y características comunes, los requisitos pueden dividirse en diferentes tipos. A continuación se indican los tipos de requisitos que son usados en los proyectos:      

Necesidades del stakeholder Características Casos de uso Requisitos suplementarios Casos de prueba Escenarios.

Estos tipos de requisitos pueden ser presentados en la forma de una pirámide, tal como se muestra en la Figura 2.1

Figura 2.1 - Pirámide de Requisitos

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

En el nivel superior están las necesidades de stakeholders. En los niveles inferiores, las características, casos de uso y requisitos suplementarios. Los diferentes niveles marcan el nivel de detalle, pues cuanto menor sea el nivel, la exigencia de detalle de un requisito será mayor. Por ejemplo, una necesidad de stakeholder podría ser: "Los datos deben ser persistentes." La característica puede refinar este requisito así: "El sistema debe utilizar una base de datos relacional." Y, en el nivel de requisito suplementario, es aún más específico: "El sistema debe usar el motor de base de datos Oracle 9i." Esto pone de manifiesto que cuanto más se avance a los niveles inferiores de la pirámide, más detallado será el requisito. Una de las mejores prácticas de gestión de requisitos es tener por lo menos dos niveles de abstracción de requisitos. 1.3.1.1. Necesidad del stakeholder Describe lo que el sistema debería hacer para mejorar o reducir el costo de un proceso de negocio, incrementar ganancias o alcanzar regulaciones y otras obligaciones. Es proporcionado por un stakeholder. Ejemplo: ID STRQ1 STRQ2 STRQ3

Necesidad “Necesito notificar al jefe de soporte cuando una solicitud de soporte es iniciada” “Necesito asignar solicitudes de soporte a un ingeniero de soporte específico” “Necesito mantener informado al cliente del progreso de una solicitud de soporte”

Stakeholder Jefe de soporte Jefe de soporte Cliente

1.3.1.2. Característica del sistema Es un servicio que el sistema provee para satisfacer una o más necesidades del afectado. Formulada por el analista del negocio. Están descritas en el documento Visión. Estos son algunos ejemplos ID característica FEAT1 El sistema funcionará orientado al trabajo en flujo FEAT2 Capacidad de notificación por e-mail

Descripción La solicitud de soporte pasará por una serie de etapas y asignaciones Un sistema de notificación de correo centralizado será utilizado por el flujo de trabajo

1.3.1.3. Caso de uso Es la descripción del comportamiento del sistema en términos de secuencia de acciones entre el actor y el sistema. El formato de un caso de uso creado por el analista de sistemas y puede ser revisado por el usuario o stakeholder. El propósito de un caso de uso es facilitar los acuerdos (contrato) entre los desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. También es la base para las realizaciones de casos de uso, las cuales juegan un papel importante en las disciplinas de análisis y diseño. Los casos de uso son un buen camino para expresar los requisitos funcionales del sistema; por ello, son utilizados para representar las funcionalidades del sistema mediante un diagrama conocido como Diagrama de casos de uso, en el cual contiene

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

actores (roles de usuarios), casos de uso (funcionalidades) y las relaciones entre ellos. Este diagrama se crea en la disciplina Captura de Requisitos.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

A continuación se muestra algunos ejemplos de casos de uso para un sistema de control de reservaciones y hospedaje de un hotel: ID UC1

UC2

UC3

Caso de Uso Generar reserva de habitaciones Consultar disponibilidad de habitaciones Buscar clientes

Descripción Este caso de uso permite registrar la reserva de uno o más habitaciones disponibles para un cliente que lo solicita. El caso de uso permite consultar la disponibilidad de una habitación por algún criterio de búsqueda: categoría, tipo y/o rango de precios. El caso de uso permite realizar la búsqueda de un cliente por algún criterio de búsqueda: nombres, apellido paterno y/o apellido materno.

1.3.1.4. Requisito suplementario También conocido como requisito de arquitectura e implementación o factores de calidad en el contexto de desarrollo de software. Son todos los requisitos no funcionales que no pueden ser expresados con casos de uso. Para capturar requisitos suplementarios se debe usar el enfoque sugerido por Peter Eeles7:     

Crear una lista de categorías de los requisitos suplementarios (según FURPS+, por ejemplo). Crear preguntas para cada categoría. Explicar al cliente el impacto y costo de cada decisión. Capturar la respuesta del cliente a cada pregunta. Asignar prioridad y peso a cada requisito.

Por otro lado, estos tipos de requisitos también se obtienen a partir de las características (features) del sistema identificado en un nivel anterior de la pirámide de requisitos. Cabe aclarar que existen varios tipos de clasificaciones para los requisitos suplementarios, como McCall and Matsumoto (1984), la clasificación utilizada por ISO (1991), FURSP+ (1992 – adoptado por Rational Software). Nuestro curso sigue las categorías FURSP+, que se muestran en la siguiente tabla. Se consideran los requisitos Funcionalidad (Funcionality), Usabilidad (Usability) Confiabilidad (Reliability), Rendimiento (Performance) y Soportabilidad (Supportability) en categorías. Además de requisitos Plus (+) (requerimientos de diseño, implementación, interfaz, operaciones, empaquetamiento y legales).

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Categoría Facilidad de uso Confiabilidad

Rendimiento

De soporte

Sub categoría Accesibilidad, Ergonomía, Fácil de usar y Consistencia de Interfaz de usuario Disponibilidad, Robustez, Precisión, Recuperación, Tolerancia a fallos, Seguro, Seguridad y Corrección Rendimiento, Tiempo de respuesta, Tiempo de recuperación, Tiempo de Inicio/Apagado Capacidad, Utilización de recursos Comprobabilidad, Adaptabilidad, Mantenibilidad. Configurabilidad, Actualización, Fácil de instalar, Escalabilidad, Portabilidad, Reutilización, Interoperabilidad. Conformidad, Fácil de reemplazar, Mutabilidad, Fácil de analizar y Fácil de localizar

Restricciones de diseño Requisitos de Interfaz Documentación de usuario en línea y sistema de ayuda 1.3.1.5. Caso de prueba Consiste en una especificación de entradas de pruebas, ejecución de condiciones y resultados esperados. Los casos de prueba pueden ir anexos a un Plan de Pruebas Integral. Los casos de prueba son creados para determinar si el requisito de un sistema, funcional o no funcional, es parcial o completamente satisfactorio. Algunos casos de prueba los puede crear el analista (desarrollador), otros los testers (encargados de las pruebas en calidad) y otros los clientes o usuarios (expertos del negocio). Los casos de prueba que se crean pueden ser utilizados para las pruebas manuales, así como para pruebas automatizadas utilizando herramientas, tales como IBM Rational Robot e IBM Rational Functional Tester. 1.3.1.6. Escenario Un escenario es una instancia de un caso de uso. Es una secuencia específica de acciones obtenidas del flujo de eventos de un caso de uso (flujo básico – subflujos – flujos alternativos). Por ejemplo, a continuación se muestra los posibles escenarios de un caso de uso que tiene cuatro flujos alternativos A1, A2, A3 y A4. Para encontrar un escenario, se necesita dibujar las posibles líneas que siguen un camino desde el flujo básico B.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

1.3.2. Características de un buen requisito Un requisito debe cumplir varios criterios para ser considerado un "buen requisito". Las características que deben tener los requisitos son:     

No ambiguo Claro Comprensible Independiente Necesario

    

Verificable Correcto Factible Atómico Abstracto

Además de estos criterios para los requisitos individuales, tres criterios se aplican al conjunto de requisitos. El conjunto debe reunir las siguientes condiciones:  Consistente  No redundante  Completo. A continuación, se muestran ejemplos de cada uno de las características de un buen requisito. 1.3.2.1. No ambiguo Un requisito no es ambiguo cuando tiene una sola interpretación. El lenguaje usado en su definición no debe causar confusiones al lector. A veces la ambigüedad se introduce por utilizar acrónimos o siglas sin definir:

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

REQ1: El sistema será implementado utilizando ASP. En este ejemplo ¿ASP se refiere a Active Server Pages o Application Service Provider? Para solucionar este problema, es mejor indicar el nombre completo y especificar el acrónimo entre paréntesis: REQ1: El sistema será implementado utilizando Active Server Pages (ASP). REQ2: El sistema no aceptará contraseñas con más de 15 caracteres. No está claro lo que el sistema se supone debe hacer:  ¿El sistema no permitirá al usuario ingresar más de 15 caracteres?  ¿El sistema truncará la cadena ingresada a 15 caracteres?  ¿El sistema mostrará un mensaje de error si el usuario ingresa más de 15 caracteres? El enunciado correcto para este requisito debe ser así: REQ2: El sistema no aceptará las contraseñas de más de 15 caracteres. Si el usuario ingresa más de 15 caracteres, al digitar su contraseña, un mensaje de error le pedirá al usuario que debe corregirlo. 1.3.2.2. Verificable Un requisito es verificable cuando puede ser cuantificado de manera que permita hacer uso de los siguientes métodos de verificación: inspección, análisis, demostración o pruebas. Para que un requisito sea verificable, éste debe ser claro, preciso y no ambiguo. Algunas de estas palabras pueden hacer que un requisito no sea verificable:      

Algunos adjetivos: robusto, seguro, preciso, eficaz, eficiente, ampliable, flexible, fácil de mantener, confiable, amigable y adecuada. Algunos adverbios y frases adverbiales: rápido, seguro o de manera oportuna. Palabras o acrónimos no específicos: etc., y/o, TBD. Pronombres indefinidos: algunos, muchos, más, mucho, varios, cualquier, cualquiera, cualquier cosa, algunos, alguien, etc. Algunos verbos en infinitivo: gestionar, controlar´… Voz pasiva: el sujeto de la oración recibe la acción del verbo en lugar de su realización.

El requisito que se enuncia a continuación presenta un pronombre indefinido: REQ4: El sistema deberá resistir el uso concurrente por muchos usuarios. La pregunta es ¿qué número debe ser considerado "muchos" -10, 100, 1000? Una mejor alternativa de enunciarlo: REQ4: El sistema deberá resistir el uso concurrente de a lo más 500 usuarios. REQ5: “La facilidad de búsqueda debería permitir al usuario encontrar una reserva basada en el apellido, día, etc.” En este ejemplo, todos los criterios de búsqueda deberían ser listados explícitamente. El desarrollador no puede adivinar lo que significa “etc.”.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

1.3.2.3. Claro Un requisito es claro si es fácil de leer y entender. Su redacción debe ser simple y clara para aquellos que vayan a consultarlo en un futuro. Por ejemplo esta es una frase compleja para un requisito: REQ7: A veces el usuario introducirá Código del aeropuerto, que el sistema comprenderá, pero, a veces, será sustituida por el nombre de la ciudad más cercana, por lo que el usuario no necesita saber cuál es el código del aeropuerto, y seguirá siendo entendido por el sistema. Esta frase puede ser sustituida por una más sencilla: REQ7: El sistema deberá identificar el aeropuerto por el Código de Aeropuerto o el Nombre de Ciudad. 1.3.2.4. Correcto Si un requisito contiene hechos, éstos deben ser ciertos. Por ejemplo, este requisito no está escrito correctamente: REQ8: El sistema deberá aplicar descuentos en las planillas de los trabajadores (incluyendo el 18% de los aportes del sistema de pensiones). El porcentaje de aportación depende de la entidad administradora de fondos de pensiones, por lo que la cifra indicada del 18% es incorrecta. 1.3.2.5. Comprensible Los requisitos deberían ser gramaticalmente correctos y escritos en un estilo consistente. Un estándar de convenciones debe ser utilizada. Tal es así que la palabra "deberá" se debe utilizar en lugar de "podrá", "debe", o "puede". 1.3.2.6. Factible El requisito debería ser factible dentro de las limitaciones existentes, tales como tiempo, dinero y recursos disponibles: REQ9: El sistema tendrá una interfaz de lenguaje natural que comprenderá comandos dados en el idioma Inglés. Este requisito puede no ser factible en un corto lapso de tiempo de desarrollo (traducir un comando). 1.3.2.7. Independiente Para entender un requisito, no debería haber necesidad de conocer a ningún otro requisito: REQ10: La lista de vuelos disponibles incluirá el número de vuelo, hora de salida y tiempo de llegada del vuelo. REQ11: Esta debería ser ordenada por precio. La palabra "Esta" en la segunda frase se refiere al requisito anterior. Sin embargo, si se cambia el orden de los requisitos, el REQ11no será comprensible.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

1.3.2.8. Atómico El requisito debe contener un elemento de trazabilidad individual: REQ12: El sistema deberá proporcionar la posibilidad de reservar el vuelo, comprar un ticket, reservar una habitación de hotel, reservar un auto, y proporcionar información sobre lugares de interés. Este requisito se compone de cinco requisitos atómicos, lo que hace muy difícil la trazabilidad. Las oraciones que incluyen las palabras "y" o "pero" debería revisarse para ver si se puede romper en varios requisitos atómicos. Lo correcto sería: REQ12: El sistema deberá proporcionar la posibilidad de reservar el vuelo. REQ13: El sistema deberá permitir comprar un ticket. REQ14: El sistema deberá proporcionar la opción de reservar una habitación de hotel. REQ15: El sistema deberá permitir reservar un auto. REQ16: El sistema deberá proporcionar información sobre lugares de interés. 1.3.2.9. Necesario Un requisito es necesario si su omisión provoca una deficiencia en el sistema a construir, y, además, su capacidad, características físicas o factor de calidad no pueden ser reemplazados por otras capacidades del producto o del proceso. Por ejemplo, el siguiente requisito debe ser removido porque no proporciona ninguna información adicional de lo que el sistema debe hacer: REQ17: Todos los requisitos especificados en el documento Visión deberían ser implementados y probados. 1.3.2.10.

Abstracto

Los requisitos no deben contener información innecesaria de diseño e implementación: REQ18: La información del sistema deberá ser almacenada en un archivo de texto. En el ejemplo, cómo se almacena la información, es transparente para el usuario y debe ser decisión del diseñador o del arquitecto 1.3.2.11.

Consistente

Un requisito es consistente si no es contradictorio con otro requisito. Por ejemplo puede darse el caso en que dos requisitos utilicen términos diferentes para un mismo concepto: REQ19: El sistema deberá permitir reservar una habitación. REQ20: El sistema deberá permitir registrar el hospedaje a partir de una separación de habitación registrada. 1.3.2.12.

No redundante

Cada requisito debe ser expresado una sola vez y no debe solaparse con otro requisito: REQ23: Un calendario estará disponible para ayudar a la entrada de la fecha de vuelo.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

REQ24: El sistema deberá mostrar un calendario pop-up para ingresar cualquier fecha. En estos ejemplos es fácil darse cuenta que el primer requisito (en relación con la fecha, sólo del vuelo) es un subconjunto del segundo (en relación con cualquier fecha introducida por el usuario).

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

1.3.2.13.

Completo

Un requisito está completo si no necesita ampliar detalles en su redacción, es decir, si se proporciona la información suficiente para su comprensión sin necesidad de agregar otro requisito para su entendimiento.

1.3.3. Visión General de la gestión de requisitos según RUP Los siguientes tipos de documentos se utilizan comúnmente en la gestión de requisitos: Plan de Gestión de Requisitos. Este documento establece los lineamientos para el establecimiento de los documentos de requisitos, tipos, características y la trazabilidad con el fin de gestionar los requisitos del proyecto. Peticiones de los stakeholders. En este documento se especifican las necesidades de los stakeholders. Visión. Este documento da la visión total del sistema: principales características, necesidades de los stakeholders y servicios esenciales proporcionados. Glosario. Es importante que todos los stakeholders utilicen términos consistentes para expresar sus necesidades. El glosario es una herramienta para capturar y definir los términos utilizados en el proyecto. Especificación de casos de uso. Las especificaciones de casos de uso sirven como un formato para expresar el flujo de eventos de los requisitos funcionales Un caso de uso es una secuencia de acciones llevadas a cabo por un sistema que produce un resultado observable (una salida de trabajo) de valor a un actor en particular. Especificación de requisitos suplementarios. Este documento captura los requisitos que no pueden vincularse directamente a cualquier caso de uso específico y, sobre todo si se trata de los requisitos no funcionales y restricciones de diseño. Especificación de requisitos de software. Este documento captura todos los requisitos del sistema software, es decir, contiene la lista de los requisitos funcionales y no funcionales. Plan de pruebas. Este documento describe el objetivo de las pruebas (componentes, aplicaciones, sistemas), las etapas de la prueba, y los tipos de pruebas que serán abordados por este plan.



  



Captura de requisitos

Necesidades de stakeholders

Documentos Plan de gestión de requisitos Peticiones de stakeholders

Desarrollo del documento Visión

Características

Visión, Glosario

Creación de casos de uso

Casos de uso, escenarios

Paso 1

5 6 7

Descripción Establecimiento de un plan de gestión de requisitos

Especificación suplementaria Creación de casos de prueba de casos de uso Creación de casos de prueba de la especificación suplementaria Diseño del sistema

CIBERTEC

Tipo de requisito --------------------

Requisitos suplementarios Casos de prueba

Especificación de caso de uso Especificación suplementaria Plan de casos de prueba

Casos de prueba

Plan de casos de prueba

Diagrama de clases,

Diagramas UML

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

diagramas de interacción Requisitos y documentos creados en el proceso de gestión de requisitos según RUP La gestión de requisitos es un proceso iterativo. En una iteración típica, se pasa por todos los niveles de la pirámide. Incluso en la misma iteración, podemos retornar a pasos anteriores y repetir la actividad. Por ejemplo, durante la creación de un caso de prueba, podemos descubrir que aún nos falta información, y necesitamos más información de los stakeholders, por lo tanto retrocedemos un paso a la “captura de requisitos". Para mantener la integridad del modelo, es importante actualizar todos los requisitos afectados. En las iteraciones iniciales se da énfasis en los primeros pasos (nivel superior de la pirámide), y en las últimas iteraciones se pasa más tiempo en el nivel inferior de la pirámide. A continuación se describe brevemente estos pasos. 1.3.3.1. Establecimiento de un plan de gestión de requisitos Una de las primeras tareas en el proyecto es el desarrollo de un “Plan de Gestión de Requisitos” 1. Este plan describe el enfoque global de la gestión de requisitos en el proyecto. El documento da detalles de cómo los requisitos son creados, organizados, modificados y rastreados durante el ciclo de vida del proyecto. También se describen todos los tipos de requisitos y sus atributos utilizados en el proyecto ¿Cuándo se crea el PGR (Plan de Gestión de Requisitos)? La PGR se puede crear a partir de una plantilla incluida en RequisitePro. Sin embargo para crear un proyecto en RequisitePro tenemos que tomar decisiones documentadas en el PGR. Tomar en cuenta los siguientes aspectos: 1. Todas las decisiones sobre el plan se documentan. 2. Un proyecto de RequisitePro se crea sobre la base al PGR. 3. El PGR es creado a partir de una plantilla de RequisitePro. 4. El documento de Microsoft Word con el PGR se importa en RequisitePro. Aquí hay algunas preguntas que pueden ser contestadas en el plan:  ¿Se utilizará alguna herramienta de gestión de requisitos?  ¿Qué tipos de requisitos serán rastreados en el proyecto?  ¿Cuáles son los atributos de estos requisitos?  ¿Dónde se crearán los requisitos, únicamente en una base de datos o en documentos?  ¿Entre qué requisitos necesitamos aplicar la trazabilidad?  ¿Qué documentos se requieren?  ¿Qué requisitos y documentos se utilizarán como un contrato con los clientes?  Si una parte del proyecto se subcontrata, ¿qué requisitos y documentos serán utilizados como un contrato con un vendedor?  ¿Vamos a seguir la metodología RUP o alguna otra?  ¿El cliente necesita documentos específicos para cumplir con su proceso de desarrollo?  ¿Cómo la gestión de cambios se llevará a cabo?  Suponiendo que se utiliza RequisitePro, ¿todo el sistema se almacenará en un Proyecto RequisitePro o se crearán varios proyectos?  ¿Qué proceso garantizará que todos los requisitos serán implementados y verificados?

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II



¿Para qué requisitos o vistas tenemos que generar informes?

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

1.3.3.2. Captura de requisitos Este paso se concentra en capturar todas las necesidades de los stakeholders, utilizando una o más técnicas para recolectar requerimientos que se citan a continuación: 

 



 

  

Entrevistas: Son utilizadas para recopilar información de los interesados (stakeholders). Es conveniente la utilización de preguntas abiertas que no sugieran una determinada respuesta. Cuestionarios: Un conjunto de preguntas preparadas para un gran grupo de stakeholders. Workshops (talleres): Reunión de stakeholders por un periodo intensivo. Son coordinados por un experto y a menudo se consigue alentar el compromiso de los participantes, fomentando el espíritu de grupo. Storyboards (guiones gráficos): Uso de una herramienta visual gráfica para mostrar el comportamiento del sistema. Son un conjunto de dibujos que representan las actividades del usuario. Son una especie de prototipos a papel. Role-playing (Juego de roles): A cada miembro del grupo se le asigna un rol, usualmente uno de los usuarios. Sesiones de lluvias de ideas (brainstorming): Presentación de ideas durante una sesión breve e intensiva. Es eficaz porque las ideas más creativas y efectivas son el resultado de la combinación de ideas. Prototipos: Desarrollo de un prototipo para obtener retroalimentación. Consiste de una versión rápida del sistema o parte del mismo. Casos de uso: Descripción de la interacción del usuario con el sistema presentado como una secuencia de pasos. Análisis de documentos: Implica un estudio de documentos que definen la razón de ser del proyecto, tales como planes de negocio, estudio de mercado, contratos, etc.

La técnica a usar dependerá de la naturaleza de los requisitos y el tipo de stakeholder. Es buena práctica especificar el resultado de esta tarea en el documento Peticiones de stakeholder y almacenar cada uno de los requisitos en una base de datos. Esto permitirá asignarles varios atributos, como la prioridad o dificultad. También permite realizar el seguimiento de los requisitos y derivarlos a otros tipos de requisitos. Un punto importante que resaltar es que se debe tener cuidado de no perder o mal interpretar un requisito en este nivel, de lo contrario este problema se propagará durante todo el ciclo de desarrollo. Las necesidades de stakeholders no necesariamente tienen los atributos de un buen requisito mencionados en la sesión anterior; pero los requisitos que se encuentran en niveles inferiores a estas, sí los presentan. Este tipo de requisito se encuentra en el nivel superior de la pirámide, tal como se ilustra en la figura 3.1.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

A NÁ L I SI S Y DI SE ÑO D E SI S TE MA S I I

Figura 3.1 - Necesidades de stakeholders en la pirámide

1.3.3.3. Desarrollo del documento Visión El documento Visión es uno de documentos más importantes creados en la gestión de requisitos con RUP y el cual puede ser utilizado como un contrato entre los desarrolladores y clientes para los requisitos técnicos. Los propósitos del documento Visión son los siguientes:    

Definir los límites del sistema Identificar restricciones impuestas en el sistema Conseguir acuerdos con los clientes sobre el alcance del proyecto Crear una base sobre la cual se definen los documentos: especificaciones de casos de uso y especificaciones de requisitos suplementarios.

La Visión es un repositorio de los requisititos del tipo “Característica” (Feature) y son listados en la sección “Características del Producto” del documento. Este tipo de requisitos se muestra en la pirámide en la figura 3.2.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Figura 3.2 - Características del sistema en la pirámide

Las características se derivan de las necesidades de los stakeholders. Es importante no perder de vista qué característica fue derivada de las necesidades de stakeholders. Para crear uno o varios requisitos FEAT (Features) a partir de los requisitos STRQ (Stakeholders request) se aplica alguna de las siguientes estrategias de transformación:    

    

 

Copiar: Si no se requieren cambios, el STRQ puede ser copiado a FEAT exactamente como está. Dividir: Si el requisito no es atómico, podemos dividirlo en dos o más requisitos. Aclaración: Aclaración o explicación, se puede aplicar cuando el requisito inicial es poco claro o ambiguo. Cualificación: Logramos cualificar (cuantificar) mediante la adición de restricciones o condiciones al requisito. Puede ayudar a resolver las necesidades contradictorias. Combinación: Si los requisitos son redundantes o se superponen se pueden combinar en un solo requisito. Generalización: Si la necesidad no es abstracta, e incluye algunos detalles innecesarios, podemos aplicar la generalización. Cancelación: A veces un requisito debe ser eliminado. Esto puede suceder cuando el requisito es no viable, innecesario, o incompatible con otro requisito. Completar: Si el conjunto de requisitos es incompleto, puede ser necesario añadir requisitos en esta etapa. Corrección: Corrección puede significar una nueva redacción del requisito para corregir la gramática, ortografía o puntuación; o cambiar una parte de la necesidad que no es cierta. Unificación: Los requisitos que usan un vocabulario inconsistente pueden ser unificados (estandarizados). Adición de detalles: Si el requisito no es lo suficientemente preciso, podemos añadir más detalles. Esta técnica se utiliza a menudo para obtener requisitos verificables de los que no han sido especificados como tal.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Una vez creados los requisitos del tipo características (FEAT), se debe especificar sus atributos. Los atributos son las propiedades de un requisito: Ayudan a organizar y analizar los requisitos del proyecto. Se pueden crear reglas para decidir, en base a los atributos, cuáles de los requisitos se implementarán en la siguiente iteración, fase o lanzamiento (release). A continuación, se indican los atributos que usualmente se asignan a los tipos de requisitos FEAT:             

Prioridad: generalmente se usa para determinar el orden de implementación. Estado: seguimiento del progreso del desarrollo del requisito: propuesto, aprobado, incorporado y validado. Dificultad: lo difícil que puede ser la implementación de este requisito, los valores por defecto son de alta, media y baja. Estabilidad: la probabilidad de que el requisito no va a cambiar durante el proyecto. Riesgo: la probabilidad de resultados relacionados con este requisito: problemas con su implementación, incumplimiento de los plazos, etc. Planificación de la iteración: por ejemplo, E1-la primera iteración en la fase de elaboración. Iteración actual. Origen: fuente del requisito. Nombre del contacto: normalmente la persona responsable de este requisito. Mejora de Requisito. Defecto. Autor. Localización: documento en el que el que se encuentra.

Aparte de los atributos enunciados en la lista anterior, el equipo de desarrollo puede agregar otros atributos si así lo prefiere. Por ejemplo, el atributo Importancia, el cual incluye los valores: obligatorio y deseable. En situaciones extremas, múltiples atributos pueden almacenar estos valores de importancia, los cuales no son los mismos que prioridad, porque la importancia según el usuario puede no ser la misma importancia según el gerente del proyecto. 1.3.3.4. Creación de casos de uso Los requisitos funcionales son mejor descritos en forma de casos de uso. Ellos son derivados de características del sistema y a partir de los casos de uso se derivan sus escenarios, tal como se ilustra en la figura 3.3.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Figura 3.3: Casos de uso y sus escenarios en la pirámide

El propósito de los casos de uso es facilitar acuerdos entre desarrolladores, clientes y usuarios acerca de lo que el sistema debe hacer. De este modo, un caso de uso puede ser usado como un contrato entre los desarrolladores y clientes. Este también es la base para las realizaciones de casos de uso, los cuales juegan un papel importante en análisis y diseño; implementación y casos de prueba. Las características de casos de uso son las siguientes:      

Son iniciados por un actor. Modelan una interacción entre el actor y el sistema. Describen una secuencia de acciones. Capturan requisitos funcionales. Proporcionan algún valor a un actor. Representan un completo y significativo flujo de eventos

La creación de casos de uso incluye las siguientes actividades: 1. 2. 3.

Encontrar actores Encontrar casos de uso y detallarlos Estructurar el modelo de casos de uso.

1.3.3.5. Especificación suplementaria La especificación suplementaria captura todos los requisitos que no pueden ser expresados en casos de uso. Sin embargo, esto no significa que todos los requisitos funcionales están en los casos de uso y que todos los requisitos no funcionales están en la Especificación suplementaria. La Especificación de casos de uso también contiene los requisitos no funcionales, si se aplican a un solo caso de uso. La Especificación suplementaria contiene todos los requisitos funcionales genéricos que no están asociadas con ningún caso de uso específico. La tabla ilustra qué tipo de requisito se encuentra en un documento.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

A NÁ L I SI S Y DI SE ÑO D E SI S TE MA S I I

Tipo de requisito Funcional No Funcional

Especificación de caso de uso Flujo básico y flujos alternativos relacionados a un caso de uso específico. Especificación no funcional relacionada a un solo caso de uso.

Especificación suplementaria Requisitos funcionales relacionados a más de un caso de uso. Requisitos no funcionales relacionados a muchos casos de uso.

Recientemente, el nombre del artefacto fue cambiado en Rational Unified Process (RUP) de "Especificación Complementaria" al plural "Especificaciones suplementarias" para reflejar el hecho de que podemos usar más de un documento para capturar requisitos suplementarios. En la pirámide, los requisitos suplementarios están en el mismo nivel que los casos uso, como se muestra en la figura 3.4.

Figura 3.4: Requisitos suplementarios en la pirámide

Muchas características que se definen en el documento Visión se convierten en requisitos suplementarios. Su inclusión en la Especificación Suplementaria proporciona una oportunidad para añadir más detalles y organizar los requisitos en la sección apropiada del documento, de acuerdo a la categoría FURPS+ a la que pertenecen. Un método consiste en ir a través de todas las características, identificar cuáles no se abordaron en los casos de uso, y traducirlos a requisitos suplementarios, los cuales son descritos con más detalle y más específicos. Muy a menudo no se necesitan cambios, 1.3.3.6. Creación de casos de prueba de casos de uso En muchos proyectos la importancia de este paso no es reconocido. A menudo, a los testers se les da una impresión de Especificación de caso de uso y, a continuación, ellos realizan las pruebas manuales. Sin embargo, si descuidamos la creación formal de los casos de prueba, se puede terminar con una cobertura pobre de un universo de pruebas ejecutando muchas pruebas duplicadas.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Casos de prueba para verificar casos de uso

Cuando tengamos todos los escenarios derivados de un caso de uso, se crean los casos de prueba. Para ello, se sigue cuatro pasos 1. 2. 3. 4.

Identificar las variables para cada paso del caso de uso. Identificar opciones significativamente diferentes para cada variable. Combinar opciones en estudio en los casos de prueba. Asignar valores a las variables.

1.3.4. Trazabilidad según RUP de los requisitos La trazabilidad es una técnica que proporciona una relación entre los diferentes niveles de requisitos en el sistema. Esta técnica ayuda a determinar el origen de cualquier requisito. La siguiente figura ilustra cómo los requisitos se trazan desde el nivel superior hacia abajo. Todas las necesidades por lo general se asignan a algunas características. En general, es una relación de muchos a muchos, porque una necesidad puede rastrear a muchas características, y una característica puede obtenerse de muchas necesidades. Un caso común también es que una necesidad rastrea a una característica. En el siguiente nivel también notamos que las características mapean a los casos de uso en una relación de muchos a muchos. Las características también trazan a los requisitos suplementarios en una relación de muchos a muchos.

Trazabilidad de Requisitos

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

A NÁ L I SI S Y DI SE ÑO D E SI S TE MA S I I

Cada caso de uso traza a uno o más escenarios, así es que existe una relación de uno a muchos entre los casos de uso y escenarios. Los escenarios también tienen una relación de uno a muchos con los casos de prueba. La trazabilidad desempeña varios roles importantes porque permite: 1. 2. 3. 4.

Verificar si la aplicación cumple con todos los requisitos: Todo lo que el cliente pidió fue implementado. Verificar si la aplicación hace sólo lo que se pidió: No implementa algo que el cliente nunca solicitó. Realizar un análisis de impacto: ¿Qué elementos se verán afectados si se considera la adición de un nuevo requisito o cambiar una ya existente? Ayudar con la gestión del cambio: Cuando algún requisito cambia, queremos saber qué casos de prueba deben rehacerse para probar este cambio.

La trazabilidad es una propiedad de los requisitos aplicable al resto del desarrollo que permite conocer las dependencias entre los distintos artefactos que se van generando. Cada vez que se crea o cambia un nuevo artefacto (un objetivo, un requisito, un elemento de modelado, un módulo, un fichero de código fuente, una prueba, etc.) se debe registrar de qué elementos de nivel superior y de su mismo nivel depende. Esta tarea es la única forma de poder realizar un análisis de impacto cuando se solicita un cambio, pues todos los que dependen del artefacto, tanto directa como indirectamente, están expuestos a posibles cambios. La siguiente figura muestra la estructura de trazabilidad utilizada en un proyecto.

Diagrama de Trazabilidad

Un elemento de la trazabilidad es un elemento del proyecto que debe ser explícitamente trazado a partir de otro elemento textual o modelo para hacer un seguimiento de las dependencias entre ellos. La siguiente tabla describe todos los tipos de requisitos a utilizar en el proyecto.

Tabla de descripción de elementos de trazabilidad

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Actividades propuestas De acuerdo a la pirámide de requisitos, a qué tipo de requisito corresponde cada uno de los siguientes enunciados: NOTA: Utilice STRQ, FEAT, UC o SUPL para indicar si se trata de una necesidad de stakeholder, característica del sistema, caso de uso o requisito suplementario respectivamente. 



  

 



R01. El sistema deberá garantizar que su despliegue se pueda realizar, ya sea en el lado del servidor o del cliente, sobre plataforma hardware de 32 bits o de 64 bits sin que esto afecte el rendimiento del mismo. R02. El sistema deberá contar con un Manual Técnico de Referencia para la Aplicación, el cual estará orientado a profesionales capacitados en aspectos técnicos del área de sistemas. R03. La clave de los usuarios considerará las siguientes políticas: - Expirar según parametrización del sistema - Tener mínimo una longitud de 8 caracteres - Contener letras y números - No puede contener espacios - No pueden repetirse las 3 últimas contraseñas - No contendrá el nombre o apellido de la persona dueña del usuario R04. El código fuente del sistema deberá cumplir con el estándar de codificación definido en el documento “Estándares y Nomenclaturas de Código Fuente”. R05. El sistema utilizará el idioma castellano para los mensajes y textos en la pantalla. R06. El sistema será utilizado por clientes de todo el mundo. Adicionalmente, la Organización Pro-Turismo exige que para anunciar servicios en su portal, éstos deben estar provistos en español, inglés y portugués. Estos tres idiomas deben ser soportados por el producto desarrollado. R07. El sistema deberá permitir la creación, modificación, activación, desactivación y autorización de los roles de usuarios definidos. R08. El sistema deberá prever contingencias que pueden afectar la prestación estable y permanente del servicio. La siguiente es la lista de las contingencias que se deben tener en cuenta y se pueden considerar críticas: - Sobrecarga del sistema por volumen de usuarios. Caída del sistema por sobrecarga de procesos. Caída del sistema por sobrecarga de transacciones. Caída del sistema por volumen de datos excedido en la base de datos. R09. El sistema deberá contar con el manual de FAQ (Frequent Asked Questions), en línea e impreso, que es un resumen con las respuestas a las preguntas más frecuentes que se hacen los usuarios. R10. El sistema deberá utilizar una base de datos relacional Oracle.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

A NÁ L I SI S Y DI SE ÑO D E SI S TE MA S I I

Resumen 1.

La pirámide de requisitos muestra una jerarquía de requisitos de acuerdo al nivel de detalle en que se expresan. En los niveles inferiores de la pirámide se encuentran los requisitos con mayor nivel de detalle.

Un requisito debe presentar las características de un "buen requisito".

Los requisitos suplementarios son todos los requisitos que no pueden ser expresados con casos de uso.

Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  “REQUIREMENTS MANAGEMENT USING IBM RATIONAL REQUISITE PRO” de Peter Zielczynski. El primer capítulo trata la gestión de requisitos, el cual empieza con la descripción de la pirámide de requisitos y características de un buen requisito y termina con una descripción breve del proceso de gestión de requisitos Además, puede consultar las siguientes páginas. http://www.ibm.com/developerworks/rational/library/04/r-3217/index.html Este artículo ilustra un método formal de derivación de casos de prueba funcional de casos de uso, incluyendo cómo crear un caso de uso, derivar todos los escenarios, y crear casos de prueba razonable, así como el uso de IBM Rational Requisite Pro para la trazabilidad de los casos de uso con escenarios y casos de prueba.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

UNIDAD

[

TECNICAS Y HERRAMIENTAS PARA LA INGENIERIA DE REQUISITOS LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno podrá identificar adecuadamente todos los requerimientos a partir del correcto entendimiento de las técnicas y herramientas de requerimientos de software TEMARIO 2.1 Tema 4 : Técnicas y herramientas utilizadas en la Ingeniería de Requerimientos 2.1.1 : Entrevistas 2.1.2 : Cuestionarios 2.1.3 : Lluvia de ideas 2.1.4 : Proceso de Análisis Jerárquico (AHP) 2.1.5 : Administración de requerimientos con casos de uso 2.1.6 : Ventajas y desventajas de las técnicas 2.1.7 : Comparación entre técnicas

ACTIVIDADES PROPUESTAS  Elaborar una entrevista o cuestionario sobre su proyecto.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

2.1. TÉCNICAS Y HERRAMIENTAS UTILIZADAS INGENIERÍA DE REQUERIMIENTOS

Existen varias técnicas para la Ingeniería de requerimientos, sin embargo, se mencionaran algunas de las más importantes. Cada técnica puede aplicarse en una o más actividades de la Ingeniería de requerimientos, en la práctica, la técnica más apropiada para cada actividad dependerá del proyecto que esté desarrollándose.

2.1.1.

Entrevistas

Las entrevistas son la técnica de elicitación más utilizada, y de hecho son prácticamente inevitables en cualquier desarrollo ya que es una de las formas de comunicación más natural entre personas. La entre vista es buena para obtener conocimientos acerca del trabajo actual en el dominio dado y los problemas presentes. No es tan buena para la identificación de las metas críticas. Pueden dar, también, algunas ideas sobre el sistema futuro 2.1.1.1.

Tipos de entrevistas:

a) Entrevistas no estructuradas: permite que el entrevistador formule preguntas no previstas durante la conversación. El entrevistador inquiere sobre diferentes temas a medida que se presentan. En este tipo de entrevistas el entrevistador tiene poco control sobre el proceso y las conversaciones son enfocadas hacia un tema particular. b) Entrevistas estructuradas: se basan en un marco de preguntas predeterminadas. Las preguntas se establecen antes de que inicie la entrevista y todo solicitante debe responderla. Este enfoque mejora la calidad de la entrevista, pero no permite que el entrevistador explore las respuestas interesantes o poco comunes. Por eso la impresión del entrevistado y entrevistador es la de estar sometidos a un proceso mecánico. Es posible incluso que muchos solicitantes se sientan desalentados al participar en este tipo de proceso c) Entrevistas semiestructuradas: es una estrategia mixta, con preguntas estructurales y con preguntas no estructurales. La parte estructurada proporciona una base informativa. La parte no estructurada añade interés al proceso y permite un conocimiento inicial de características específicas 2.1.1.2.

Fases de la entrevista:

En las entrevistas se pueden identificar tres fases: preparación, realización y análisis 2.1.1.2.1. Preparación de entrevistas.- Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes tareas previas:

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

A NÁ L I SI S Y DI SE ÑO D E SI S TE MA S I I

Estudiar el dominio del problema

Conocer las categorías y conceptos de los usuarios y la comunidad interesada es fundamental para poder entender las necesidades de dicha comunidad y su forma de expresarlas. Para conocer el dominio del problema se puede recurrir a técnicas de estudio de documentación, a bibliografía sobre el tema, documentación de proyectos similares realizados anteriormente, la inmersión dentro de la organización para la que se va a desarrollar o a periodos de aprendizaje por partes de los analistas de requerimientos. o

Seleccionar a las personas a las que se va a entrevistar

Se debe minimizar el número de entrevistas a realizar, por lo que es fundamental un proceso de selección. Normalmente se comienza por los actores que puedan ofrecer una visión global, y se continúa con los futuros usuarios, que pueden aportar información más detallada, y con el personal técnico, que aporta detalles sobre el entorno operacional de la organización. Conviene también estudiar el perfil de los entrevistados, buscando puntos en común con el entrevistador que ayuden a romper el hielo. ¿A quién entrevistar para obtener información acerca del trabajo actual y los problemas presentes? Preferiblemente algunos miembros de cada grupo de actores. Hay que entrevistar no solo a representantes oficiales, la experiencia demuestra que muchos de estos representantes desconocen lo que realmente sucede en la organización diariamente. Obtener información del verdadero usuario final es importante. o

Determinar el objetivo y contenido de las entrevistas

Para minimizar el tiempo de la entrevista es fundamental fijar el objetivo que se pretende alcanzar y determinar previamente su contenido. Previamente a su realización, se pueden enviar cuestionarios que los futuros entrevistados deben rellenar y devolver, y un pequeño documento de introducción al proyecto de desarrollo, de forma que el entrevistado conozca los temas que se van a tratar y el entrevistador recoja información para preparar la entrevista. Es importante que los cuestionarios, si se usan, se preparen cuidadosamente teniendo en cuenta quién los va a responder y no incluir conceptos que se asuman conocidos cuando puedan no serlo o

Planificar las entrevistas:

La fecha, hora, lugar y duración de las entrevista deben fijarse teniendo en cuenta siempre la agenda del entrevistado. En general, se deben buscar sitios agradables donde no se produzcan interrupciones y que resulten naturales a los entrevistados. La puntualidad es importante

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

2.1.1.2.2. Realización de entrevistas.- Dentro de la realización de las entrevistas se distinguen tres etapas: Apertura, desarrollo y terminación. o Apertura: el entrevistador debe presentarse e informar al entrevistado sobre la razón de la entrevista, qué se espera conseguir, cómo se utilizará la información, la mecánica de las preguntas, etc. Si se va a utilizar algún tipo de notación gráfica o matemática que el entrevistado no conozca, debe explicarse antes de utilizarse. Es fundamental causar buena impresión en la primera entrevista. o Desarrollo: la entrevista debe tener un lapso prefijado, distribuyendo el tiempo en un 20% para el entrevistador y un 80% para el entrevistado. Se deben evitar los monólogos y mantener el control por parte del entrevistador, contemplando la posibilidad de que una tercera persona tome notas durante la entrevista o grabar la entrevista en cinta de vídeo o audio, siempre que el entrevistado esté de acuerdo. Hay aspectos éticos a considerar: si se va a grabar la entrevista, se debe tener muy presente que el equipo de grabación debe estar en perfecto estado y el entrevistador debe saber manejarlo y cuando se reproduce la grabación no se pueden cambiar ni corregir las respuestas suministradas por los entrevistas, bajo ninguna circunstancia. ¿Qué preguntar? Inicialmente, formular preguntas abiertas acerca del trabajo diario, y otros aspectos de la lista de cosas a elicitar. Asegurándose de preguntar sobre las tareas críticas: ¿cuándo es realmente importante que los resultados sean 100% correctos? Difícilmente se pueden identificar estos detalles con la observación, hay que preguntarles a los usuarios. Durante esta fase se deben considerar los siguientes aspectos:  Realizar preguntas abiertas, también denominadas de libre contexto, estas preguntas no pueden responderse con un "sí" o un "no", permiten una mayor comunicación y evitan la sensación de interrogatorio. Estas preguntas se suelen realizar al comienzo de la entrevista, pasando posteriormente a preguntas más concretas. En general, se debe evitar la tendencia a anticipar una respuesta a las preguntas que se formulan.  Utilizar palabras apropiadas, evitando tecnicismos que no conozca el entrevistado y palabras o frases que puedan perturbar la comunicación.  Mostrar interés en todo momento, cuidando la comunicación gestual durante la entrevista: movimiento, expresión facial, etc. Por ejemplo, para animar a alguien a hablar puede asentirse con la cabeza, decir "ya entiendo", "sí", repetir algunas respuestas dadas, hacer pausas, poner una postura de atención, etc. Debe evitarse bostezar, reclinarse en el sillón, mirar hacia otro lado, etc. o Terminación: al terminar la entrevista se debe recapitular para confirmar que no ha habido confusiones en la información recogida, agradecer al entrevistado su colaboración y citarle para una nueva entrevista si fuera necesario, dejando siempre abierta la posibilidad de volver a contactar para aclarar dudas que surjan al estudiar la información o al contrastarla con otros entrevistados. 2.1.1.2.3. Análisis de las entrevistas Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas en limpio, reorganizar la información, contrastarla con otras entrevistas o fuentes de información, entre otros. Una vez elaborada la información, se puede enviar al entrevistado para confirmar los contenidos. También es importante evaluar la propia entrevista para determinar los aspectos mejorables.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Una variante es la entrevista en grupos. Un grupo de usuarios de la misma área puede decir más del trabajo actual, problemas, situaciones críticas que las entrevistas individuales. El grupo inspira a los otros a recordar situaciones críticas, describir el trabajo diario, etc. Una cosa importante cuando se conduce esta clase de entrevistas es mantener un equilibrio entre participantes de modo que nadie domine y todos se sientan seguros dando su opinión.

2.1.2.

Cuestionarios

Los cuestionarios pueden ser un suplemento de utilidad para las entrevistas. Son excelentes para conseguir respuestas a preguntas cerradas. Puede descubrir preguntas claves a partir de las entrevistas e incorporar éstas en un cuestionario que puede distribuir a una audiencia más amplia. Esto le puede ayudar a validar su entendimiento de los requisitos. Por el tipo de preguntas que contiene, existen dos tipos de cuestionarios: abiertos y cerrados.  Abiertos: No presuponen ninguna respuesta particular y animan al entrevistado a hablar sobre el problema para obtener opiniones y/o referencias.  Cerrados: Limitan las respuestas posibles a través de un estilo cuidadoso en la pregunta. Los tipos de respuestas de un cuestionario cerrado podrían ser los siguientes:  SI/NO ¿Cree que se cometen muchos errores en la codificación de los números de cuenta en las facturas? SI NO  DE ACUERDO/EN DESACUERDO ¿Se cometen muchos errores al codificar os números de cuenta en las facturas? DE ACUERDO EN DESACUERDO  ESCALAS ¿Se cometen muchos errores al codificar los números de cuenta en las facturas? TOTALMENTE DE ACUERDO DE ACUERDO NO ESTOY SEGURO EN DESACUERDO TOTALMENTE EN DESACUERDO  NÚMERO De cada 100 facturas que se procesan ¿cuántas tienen errores? Anote el número: ____________

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II



RANGO

De cada 100 facturas que se procesan ¿cuántas tienen errores?

0-5 6 - 10 11 - 15 16 - 20 21 - 25 26 - 30 31 - 40 41 - 50 Más de 50

 SELECCIÓN DE RESPUESTAS LIMITADAS Cuando se presentan errores en la codificación de los números de cuenta en las facturas, ¿cuál es la causa más frecuente? (Anote el número de la respuesta apropiada. También la segunda razón más común y la menos común). 1.... 2.... Los buenos cuestionarios se deben diseñar previamente. Un pensamiento cuidadoso, acompañado de una prueba previa, tanto del formato como de las preguntas, son la base de una recopilación de datos significativa a través de cuestionarios. Pautas que le ayudarán a confeccionar un buen cuestionario: 1.

4. a. b. c. d. e. f. g. 5. 6.

7. 8.

Determine qué datos necesitan recopilarse y qué personas son las más calificadas para proporcionarlos. Si otros grupos pueden proporcionar datos variantes y mayor visión identifíquelos también. Seleccione el tipo de cuestionario (abierto o cerrado). Reconozca cuáles pueden ser más útiles, si contienen una sección de respuestas cerradas y otras de respuestas abiertas. Desarrolle un Grupo de preguntas para incluirlas en el cuestionario. Las preguntas extras que son intencionalmente redundantes, pueden ser útiles al asegurar respuestas consistentes por parte de quien responda. Examine el cuestionario para encontrarle fallas y defectos como: Interrogantes innecesarias. Preguntas que puedan ser mal interpretadas debido a su enfoque o forma de escritura. Preguntas que el sujeto no pueda responder. Preguntas que están escritas de forma que se escogerá la respuesta preferida. Preguntas que se interpretaran en forma diferente dependiendo del marco de referencia de cada entrevistado. Preguntas que no proporcionan opciones adecuadas de respuesta. Un ordenamiento no adecuado de las preguntas y respuestas. Pruébelo previamente en un Grupo pequeño para detectar otros problemas posibles. Analice la respuesta del Grupo de prueba para asegurar que el análisis de los datos que se busca se puede llevar a cabo con los datos recopilados. Si los datos no revelan algo que el analista no conoce, el cuestionario puede no ser necesario. Realice cambios finales de edición e imprímalo en una forma legible. Distribuya el cuestionario. Cuando sea posible anote el nombre de cada persona.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

2.1.3.

Lluvia de ideas (Brainstorming)

La tormenta de ideas es una técnica de reuniones en grupo cuyo objetivo es la generación de ideas en un ambiente libre de críticas o juicios. Las sesiones suelen estar formadas por un número de cuatro a diez participantes, uno de los cuales es el facilitador de la sesión, encargado más de comenzar la sesión que de controlarla. Como técnica de elicitación de requerimientos, puede ayudar a generar una gran variedad de vistas del problema y a formularlo de diferentes formas, sobre todo al comienzo del proceso de elicitación, cuando los requerimientos son todavía muy difusos El facilitador anota todas las ideas en una pizarra. Pronto cada idea generará otras ideas, algunas interesantes, otras prometedoras y otras sin sentido común. Una regla importante del juego es no criticar ningún planteamiento. Incluso ideas aparentemente descartables pueden convertirse en la semilla de otras ideas interesantes Durante la elicitación, el interés está puesto en ideas para el nuevo sistema. Si la creatividad no surge en la sesión, el analista puede introducir ideas que han surgido mediante otras técnicas El facilitador puede culminar la sesión con una ronda donde se prioricen las ideas. Por otro lado, al ser un proceso poco estructurado, puede no producir resultados con la misma calidad o nivel de detalle que otras técnicas. Pero estimula fuertemente la creatividad y pueden salir ideas innovadoras. 2.1.3.1.

Fases de la Tormenta de ideas

En la tormenta de ideas se distinguen las siguientes fases: a.

Preparación: la preparación para una sesión requiere que se seleccione a los participantes y al jefe de la sesión, citarlos y preparar la sala donde se llevará a cabo la sesión. Los participantes en una sesión de tormenta de ideas para elicitación de requerimientos son normalmente los usuarios y otros beneficiarios, y, si es necesario, algún experto en el dominio del problema

Generación: el facilitador abre la sesión exponiendo un enunciado general del problema a tratar, que hace de semilla para que se vayan generando ideas. Los participantes aportan libremente nuevas ideas sobre el problema semilla, bien por un orden establecido por el facilitador, bien aleatoriamente. El facilitador es siempre el responsable de dar la palabra a cada participante. Este proceso continúa hasta que el facilitador decide parar, bien porque no se están generando suficientes ideas, en cuyo caso la reunión se pospone, bien porque el número de ideas sea suficiente para pasar a la siguiente fase.

Durante esta fase se deben observar las siguientes reglas:  Se prohíbe la crítica, de forma que los participantes se sientan libres de formular cualquier idea.  Se fomentan las ideas más innovadoras, que, aunque no sean factibles, estimulan a los demás participantes a explorar nuevas soluciones más creativas.  Se debe generar un gran número de ideas, ya que cuantas más ideas se presenten, más posibilidades de análisis se tendrá.  Se debe alentar a los participantes a combinar o completar las ideas de otros participantes. Para ello, es necesario que todas las ideas generadas estén visibles a todos los participantes en todo momento. Una posibilidad es utilizar como semilla objetivos del sistema e ir identificando requerimientos. Estos

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

c.    d.

requerimientos se deben recoger en plantillas para que los participantes tengan visibles las ideas que se van generando Consolidación: en esta fase se deben organizar y evaluar las ideas generadas durante la fase anterior. Se suelen seguir tres pasos: Revisar ideas: se revisan las ideas generadas para clarificarlas. Es habitual identificar ideas similares, en cuyo caso se unifican en un solo enunciado. Descartar ideas: aquellas ideas que los participantes consideren no adecuadas se descartan. Priorizar ideas: se priorizan las ideas restantes, identificando las absolutamente esenciales, las que estarían bien pero que no son esenciales y las que podrían ser descartarse. Documentación: después de la sesión, el facilitador produce la documentación oportuna, conteniendo las ideas priorizadas y comentarios generados durante la consolidación.

2.1.4.

Proceso de Análisis jerárquicos (AHP)

Esta técnica tiene por objetivo resolver problemas cuantitativos, para facilitar pensamiento analítico y las métricas. Consiste en una serie de pasos, a saber:      

Encontrar los requerimientos que van a ser priorizados. Combinar los requerimientos en las filas y columnas de la matriz n x n de AHP. Hacer algunas comparaciones de los requerimientos en la matriz. Sumar columnas. Normalizar la suma de las filas. Calcular los promedios.

Estos pasos pueden aplicarse fácilmente a una cantidad pequeña de requerimientos, sin embargo, para un volumen grande, esta técnica no es la más adecuada.

2.1.5.

Administración de requerimientos con casos de uso

2.1.5.1.

Definición de casos de uso

Los casos de uso son una técnica para especificar el comportamiento de un sistema “Un caso de uso es una secuencia de iteraciones entre un sistema y alguien o algo que usa alguno de sus servicios” Todo sistema de software ofrece a su entorno una serie de servicios. Un caso de uso es una forma de expresar como alguien o algo externo a un sistema lo usa. Cuando se dice “alguien o algo” se hace referencia a que los sistemas son usados no solo por personas, sino también por otros sistemas de hardware y software. Los casos de Uso fueron introducidos por Jacobson en 1992. Sin embargo la idea de especificar un sistema a partir de su interacción con el entorno es original de McMenamin y Palmer, dos precursores del análisis estructurado que en 1984 definieron un concepto muy parecido al del caso de uso: el evento. Para McMenamin y Palmer, un evento es algo que ocurre fuera de los límites del sistema, ante lo cual el sistema debe responder.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Sin embargo, existen algunas diferencias entre los casos de uso y los eventos. principales diferencias son: 

 

Las

Los eventos se centran en describir que hace el sistema cuando el evento ocurre, mientras que los casos de uso se centran en describir cono es el dialogo entre el usuario y el sistema. Los eventos son “atómicos” se recibe una entrada, la procesa y se genera una salida, mientras que los casos de uso se prolongan a lo largo del tiempo. Para los eventos, lomas importante es que datos ingresan al sistema o salen de él cuando ocurre el evento (estos datos se llaman datos esenciales), mientras que para los casos de uso la importancia del detalle sobre la información que se intercambia es secundaria. Según esta técnica ya habrá tiempo más adelante en el desarrollo del sistema para ocuparse de este tema.

Los casos de uso combinan el concepto de evento del análisis estructurado con otra técnica de especificación de requerimientos poco difundida: aquella que dice que una buena forma de expresar los requerimientos de un sistema es escribir su manual de usuario antes de construirlo. Esta técnica, si bien gano pocos adeptos, se base en un concepto muy interesante: al definir requerimientos, es importante describir al sistema desde el punto de vista de aquel que lo va a usar, y no desde el punto de vista del que lo va a construir. De esta forma, es más fácil validar que los requerimientos documentados son los verdaderos requerimientos de los usuarios, ya que estos comprenderán fácilmente la forma en la que están expresados. 2.1.5.2.

Los casos de uso y UML

A partir de la publicación del libro de Jacobson, gran parte de los más reconocidos especialistas en métodos orientados a Objetos coincidieron en considerar a los casos de uso como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML propuesto por Ivar Jacobson, James Rumbaugh y Grady Booch, tres de los precursores de las metodologías de Análisis y Diseño Orientado a Objetos y avalado por las principales empresas que desarrollan software en el mundo. 2.1.5.3.

Definiciones y Notaciones

a. Actores Un actor es una agrupación uniforme de personas, sistemas o maquinas que interactúan con el sistema que estamos construyendo. Los actores son externos al sistema que se va a desarrollar. Por lo tanto, al identificar actores se está empezando a delimitar el sistema, y a definir su alcance. Esto debe ser el primer objetivo de todo analista ya que un proyecto sin alcance definido nunca podría alcanzar sus objetivos. b.

Casos de uso

Es una secuencia de interacciones entre un sistema y alguien o algo que usa alguno de sus servicios. Un caso de uso es iniciado por un actor. A partir de ese momento ese actor, junto con otros actores, intercambia datos o control con el sistema, participando de ese caso de uso.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

El nombre de un caso de uso se expresa con un verbo en gerundio, seguido generalmente por el principal objetos o entidad del sistema que es afectado por el caso.

Es importante notar que el nombre del caso siempre esta expresado desde el punto de vista del actor y no desde el punto de vista del sistema. Características de los casos de uso:  Están expresados desde el punto de vista del actor  Se documentan con texto informal  Describen tanto lo que hace el actor como lo que hace el sistema cuando interactúa con él, aunque el énfasis esta puesto en la interacción.  Son iniciados por un único actor.  Están acotados al uso de una determinada funcionalidad del sistema claramente diferenciada.

2.1.6. Ventajas Requerimientos

y desventajas

las técnicas

Ingeniería

La tabla 2 muestra las ventajas y desventajas encontradas de las técnicas y herramientas utilizadas en la Ingeniería de los Requerimientos. Técnica

Entrevistas y Cuestionarios

Lluvia de Ideas

Análisis jerárquico

Ventajas  Mediante estas se obtiene una gran cantidad de información correcta a través del usuario.  Pueden ser usadas para obtener un pantallazo del dominio del problema.  Son flexibles  Permite combina con otras técnicas,  Los diferentes puntos de vista y las confusiones en cuanto a terminología son aclarados por expertos.  Ayuda a desarrollar ideas unificadas basadas en la experiencia de un experto  Permite determinar el grado de importancia de cada

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

Desventajas  La información al principio puede ser redundante o incompleta.  Si el volumen de información es alto, requiere mucha organización de parte del analista, así como la habilidad de comprender a todos los involucrados.  Es necesaria una buena compenetración del grupo de participantes.

 Debe construirse un estándar claro de evaluación

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

requerimiento.  Ayuda a identificar conflictos en los requerimientos.  Muestra el orden en que deben ser implementados los requerimientos.  Representa los requerimientos desde el punto de vista del usuario.  Permiten representar más de un rol para cada afectado.  Identifica requerimientos estancados dentro de un conjunto de requerimientos

Casos de uso

2.1.7.

que incluya la participación del cliente

 En sistemas grandes, toma mucho tiempo definir todos los casos de uso.  El análisis de la calidad depende de la calidad con que se haya hecho la descripción inicial.

Comparación entre técnicas

Entrevista vs. Casos de uso: un alto porcentaje de la información recolectada durante una entrevista, puede ser usada para construir casos de uso. Mediante esto, el equipo de desarrollo puede entender mejor el ambiente de trabajo de los involucrados. Cuando el analista sienta que tiene dificultades para entender una tarea, pueden recurrir al uso de un cuestionario y mostrar los detalles obtenidos en un caso de uso. De hecho, durante las entrevistas cualquier usuario puede utilizar diagramas de casos de uso para explicar su entorno de trabajo. Entrevista vs. Lluvias de ideas: muchas de las ideas planteadas en el grupo provienen de la información recopilada en entrevistas o cuestionarios previos. Realmente la lluvia de ideas trata de encontrar las dificultades que existen para la comprensión de términos y conceptos por parte de los participantes; de esta formase llega a un consenso. Casos de uso vs. Lluvia de ideas: la lista de ideas provienen del brainstorm puede ser representada gráficamente mediante casos de uso. La tabla muestra las técnicas que pueden ser utilizadas en las actividades de la Ingeniería de requerimientos. Análisis del problema Entrevista Y cuestionario Lluvias de ideas Prototipos Análisis jerárquico Casos de uso

Evaluación y negociación

Especificación de Requisitos

Validación

Evolución X

X X

Actividades en donde pueden ser utilizadas las técnicas de IR

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Actividades propuestas 1.

Elaborar un cuestionario sobre so proyecto, tratando de identificar si la solución planteada tiene todas las necesidades obtenidas en este cuestionario.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Resumen 1.

Las entrevistas y cuestionarios se emplean para reunir información proveniente de personas o de grupos. Durante la entrevista, el analista conversa con el encuestado; el cuestionario consiste en una serie de preguntas relacionadas con varios aspectos de un sistema.

Lluvia de Ideas busca que los involucrados en un proyecto desarrollen su creatividad, promoviendo la introducción de los principios creativos Leer más: http://www.monografias.com/trabajos6/resof/resof2.shtml

Si desea saber más acerca de estos temas, puede consultar el siguiente libro:  “Yourdon E., Análisis Estructurado Moderno, Prentice Hall Hispanoamericana, México, 2011.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

UNIDAD

[

ESPECIFICACIÓN REQUERIMIENTOS

3 DE

LOGRO DE LA UNIDAD DE APRENDIZAJE Al término de la unidad, el alumno a partir del correcto entendimiento de las especificaciones de software podrá documentar y modelar los requerimientos adecuadamente TEMARIO 3.1 Tema 5 : Especificación textual de los requisitos 3.1.1 : Un modelo de especificación de requisitos del software: el estándar IEEE 830-1993/1998 3.1.2 : ¿Qué se incluye en el documento de especificación de requisitos del software (SRS)? 3.1.3 : Propiedades de un documento de especificación de requisitos 3.1.4 : Estructura del documento SRS del IEEE 830 3.1.5 : Alternativas en la especificación de requisitos específicos, según IEEE 830 3.2.Tema 6 : Prototipado 3.2.1 : Prototipado: conceptos, métodos y herramientas 3.2.2 : Clases de prototipos 3.2.3 : Validación y Verificación mediante prototipos 3.2.4 : Prototipado: ventajas e inconvenientes 3.2.5 : Importancia de la notación a nivel de interfaz 3.2.6 : Elementos interactivos en la interfaz gráfica 3.3 Tema 7 : Especificación de Caso de Uso 3.3.1 : Importancia de las Especificaciones de caso de uso 3.3.2 : Consejos Para Escribir Buenos Casos de Uso 3.3.3 : Detallar la especificaciones de casos de uso 3.3.4 : Errores comunes que deben ser evitados en la especificaciones de casos de Uso

ACTIVIDADES PROPUESTAS  Elaborar especificaciones de casos de uso de su proyecto creando prototipos según la especificación.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

3.1. ESPECIFICACIÓN TEXTUAL DE LOS REQUISITOS 3.1.1. Un modelo de especificación de requisitos del software: el estándar IEEE 830-1993/1998 En primer lugar es importante determinar algunas definiciones generales que serán ayuda a lo largo del desarrollo del presente manual. En general las definiciones de los términos usados en estas especificaciones están conforme a las definiciones proporcionadas en IEEE. Contrato: Un documento es legalmente obligatorio y en el estarán de acuerdo las partes del cliente y proveedor. Esto incluye los requisitos técnicos y requerimientos de la organización, costo y tiempo para un producto. Un contrato también puede contener la información informal pero útil como los compromisos o expectativas de las partes involucradas. Cliente: La persona(s) que pagan por el producto y normalmente (pero no necesariamente) define los requisitos. En la práctica el cliente y el proveedor pueden ser miembros de la misma organización. Proveedor: La persona(s) que producen un producto para un cliente. Usuario: La persona(s) que operan o actúan recíprocamente directamente con el producto. El usuario(s) y el cliente (s) no es (son) a menudo las mismas persona(s).

3.1.2. ¿Qué se incluye en el documento de especificación de requisitos del software (SRS)? Estas cláusulas proporcionan información a fondo que deben ser consideradas al momento de producir un SRS. Esto incluye lo siguiente: a) La Naturaleza del SRS b) El Ambiente del SRS c) Las Características de un buen SRS d) La preparación de los Joins del SRS e) La evolución de SRS f) Prototipos g) Generando el diseño en el SRS h) Generando los requisitos del proyecto en el SRS 3.1.2.1.

Naturaleza del SRS

El SRS son especificaciones para un producto del software en particular, programa, o juego de programas que realizan ciertas funciones en un ambiente específico. El SRS puede escribirse por uno o más representantes del proveedor, uno o más representantes del cliente, o por ambos.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Los problemas básicos que se presentan al escribir un SRS van dirigidos a lo siguiente: a) La Funcionalidad. ¿Qué se supone va hacer el software? b) Las interfaces Externas. ¿Cómo el software actúa recíprocamente con las personas, el hardware de los sistemas, otro hardware, y otro software? c) La Actuación. ¿Cuál es la velocidad, la disponibilidad, tiempo de la contestación, tiempo de la recuperación de varias funciones del software, etc.? d) Los Atributos. ¿Qué portabilidad tiene, exactitud, el mantenimiento, la seguridad, las consideraciones etc.? e) Las restricciones del diseño que impusieron en una aplicación. ¿Hay algún requerimiento Standard, idioma de aplicación, las políticas para la integridad del banco de datos, los límites de los recursos, operando en qué ambiente (s) etc.? 3.1.2.2.

Ambiente del SRS

Es importante considerar la parte que el SRS representa en el diseño del proyecto total que se define en IEEE. El software puede contener toda la funcionalidad del proyecto esencialmente o puede ser parte de un sistema más grande. En el último caso habrá un SRS que declarará las interfaces entre el sistema y su software modular, y pondrá qué función externa y requisitos de funcionalidad tiene con el software modular. Otras normas, relacionan a otras partes del ciclo de vida de software para que pueda complementar los requisitos del software. Desde que el SRS tiene un papel específico en el proceso de desarrollo de software, el que define el SRS debe tener el cuidado para no ir más allá de los límites de ese papel. Esto significa que a) Debe definir todos los requisitos del software correctamente Un requisito del software puede existir debido a la naturaleza de la tarea a ser resuelta o debido a una característica especial del proyecto. b) No debe describir cualquier plan o detalles de aplicación Éstos deben describirse en la fase del diseño del proyecto. c) No debe imponer las restricciones adicionales en el software Éstos se especifican propiamente en otros documentos.

3.1.3. Propiedades de un documento de especificación de requisitos Un documento de especificación de Requisitos (SRS) debe ser: a) Correcto b) Inequívoco c) Completo d) Consistente e) Delinear que tiene importancia y/o estabilidad f) Comprobable g) Modificable h) Identificable

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

3.1.3.1.

Correcto

Un SRS es correcto si, y sólo si, cada requisito declarado se encuentra en el software. No hay ninguna herramienta o procedimiento que aseguran la exactitud. Alternativamente el cliente o el usuario pueden determinar si el SRS refleja las necesidades reales correctamente. Identificando los requerimientos hace este procedimiento más fácil y hay menos probabilidad al error. 3.1.3.2.

Inequívoco

Un SRS es inequívoco si, y sólo si, cada requisito declarado tiene sólo una interpretación. Como un mínimo, se requiere que cada característica de la última versión del producto se describa usando un único término. En casos dónde un término en un contexto particular tenga significados múltiples, el término debe ser incluido en un glosario dónde su significado es hecho más específico. Un SRS es una parte importante del proceso de requisitos del ciclo de vida de software y se usa en el diseño, aplicación, supervisión, comprobación, aprobación y pruebas como está descrito en IEEE. El SRS debe ser inequívoco para aquéllos que lo crean y para aquéllos que lo usan. Sin embargo, estos grupos no tienen a menudo el mismo fondo y por consiguiente no tienden a describir los requisitos del software de la misma manera. Trampas del idioma natural. Los requisitos son a menudo escritos en el idioma natural (por ejemplo, inglés) el idioma natural es inherentemente ambiguo. Un idioma natural que SRS podría ser revisado por una parte independiente para identificar el uso ambiguo del idioma para que pueda corregirse. Idiomas de especificación de requisitos Una manera de evitar la ambigüedad inherente en el idioma natural es escribir el SRS en un idioma de especificación de requisitos particular. Sus procesadores del idioma descubren muchos errores léxicos, sintácticos, y semánticos automáticamente. Una desventaja en el uso de tales idiomas es que la premura de tiempo exigió aprenderlos. También, muchos usuarios no-técnicos los encuentran ininteligible. Es más, estos idiomas tienden a ser buenos a expresar ciertos tipos de requisitos y dirigirse a ciertos tipos de sistemas. Así, ellos pueden influir en los requisitos de las maneras sutiles. Representación hecha con herramientas En general, los métodos de requisitos e idiomas y las herramientas que los apoyan entran en tres categorías generales - el objeto, procesos y conductual. El término objetos-orientados organizan los requisitos en lo que se refiere a los objetos en el mundo real, sus atributos, y los servicios realizados por esos objetos. El término procesos organizan los requisitos en las jerarquías de funciones que comunican vía el flujo de datos. Los términos conductuales describen conducta externa del sistema por lo que se refiere a alguna noción de lo abstracto, las funciones matemáticas o el estado de las máquinas. El grado en que se usan estas herramientas y los métodos puede ser útil preparando un SRS pero depende del tamaño y complejidad del programa. Aun usando cualquiera de estos términos es mejor retener las descripciones del idioma natural. Así, cliente poco familiar con las anotaciones el SRS puede entender todavía

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

3.1.3.3.

Completo

Un SRS está completo si, y sólo si, incluye los elementos siguientes: a. Los requisitos están relacionados a la funcionalidad, el desarrollo, las restricciones del diseño, los atributos y las interfaces externas. En particular debe reconocerse cualquier requisito externo impuesto por una especificación del sistema y debe tratarse. b. La definición de las respuestas del software a todos los posibles datos de la entrada del sistema y a toda clase de situaciones. Una nota que es importante especificar son las contestaciones a las entradas válidas e inválidas a ciertos valores. c. Tener todas las etiquetas llenas y referencias a todas las figuras, tablas, diagramas en el SRS y definición de todas las condiciones y unidades de medida. Uso de TBDs Cualquier SRS que usa la frase "para ser determinado" (TBD) no es un SRS completo. El TBD es, sin embargo, ocasionalmente necesario y debe acompañarse por: a. Una descripción de las condiciones que causan el TBD (por ejemplo, por qué una respuesta no es conocida) para que la situación pueda resolverse; b. Una descripción de lo que debe hacerse para eliminar el TBD que es responsable para su eliminación y por cómo debe eliminarse

3.1.3.4.

Consistente

La consistencia se refiere a la consistencia interior. Si un SRS no está de acuerdo con algún documento del superior-nivel, como una especificación de requisitos de sistema, entonces no es correcto. Consistencia interior Un SRS es internamente consistente si, y sólo si, ningún subconjunto de requisitos individuales genero conflicto en él. Los tres tipos de conflictos probables en un SRS son: a) Las características especificadas en el mundo real de los objetos pueden chocar. Por ejemplo,  El formato de un informe del rendimiento puede describirse en un requisito como tabular pero en otro como textual.  Un requisito puede declarar que todas las luces serán verdes mientras otro puede declarar que todas las luces sean azules. b) Puede haber conflicto lógico o temporal entre dos acciones especificadas. Por ejemplo,  Un requisito puede especificar que el programa sumará dos entradas y otro puede especificar que el programa los multiplicará.  Un requisito puede declarar que "A" siempre debe seguir "B", mientras otro puede requerir que "A” y B" ocurran simultáneamente. c) Dos o más requisitos pueden describir el mismo mundo real del objeto pero uso las condiciones diferentes para ese objeto. Por ejemplo, una demanda del programa para una entrada del usuario puede llamarse una "sugerencia" en un requisito y una "señal" en otro. El uso de terminología normal y definiciones promueve la consistencia.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

3.1.3.5.

Delinear que tiene importancia y/o estabilidad

Un SRS debe delinear la importancia y/o estabilidad si cada requisito en él tiene un identificador para indicar la importancia o estabilidad de ese requisito en particular. Típicamente, todos los requisitos que relacionan a un producto del software no son igualmente importantes. Algunos requisitos pueden ser esenciales, sobre todo para las aplicaciones de vida crítica, mientras otros pueden ser deseables. Cada requisito en el SRS debe identificarse para representar estas diferencias, aclarar y ser explícito. Identificando los requisitos de la manera siguientes: a. Tienen los clientes que dar las consideraciones muy cuidadosamente a cada requisito para que se clarifique cualquier omisión que ellos pueden tener. b. Tener diseñadores que hagan diseños correctos y pongan el mismo esfuerzo en todos los niveles del producto del software. Grado de estabilidad Puede expresarse la estabilidad por lo que se refiere al número de cambios esperados a cualquier requisito basado en experiencia o conocimiento de eventos venideros que afectan la organización, funciones y a las personas que apoyan el sistema del software. Grado de necesidad Otra manera de alinear los requisitos es distinguir las clases de requisitos que hay el esencial, el condicional y optativo. a. Esencial Implica que el software no será aceptable a menos que estos requisitos se proporcionan de una manera convenida. b.

Condicional Implica que éstos son requisitos que reforzarían el producto del software, pero no lo haría inaceptable si ellos están ausentes.

Optativo Implica una clase de funciones que pueden o no pueden valer la pena. Esto le da la oportunidad de proponer algo que excede el SRS al proveedor

3.1.3.6.

Comprobable

Un SRS es comprobable si, y sólo si, cada requisito declarado es comprobable. Un requisito es comprobable si, y sólo si, allí existe algún proceso rentable finito con que una persona o la máquina puede verificar que el producto del software reúne el requisito. En general cualquier requisito ambiguo no es comprobable. Los requisitos de No-verificable incluyen las declaraciones como "trabaja bien", "interface humana buena" y "normalmente pasará" no pueden verificarse los requisitos de esos porque es imposible de definir las condiciones "bueno," "bien" o "normalmente". La declaración que "el programa nunca entrará en una vuelta infinita" es el no-verificable porque la comprobación de esta calidad es teóricamente imposible Un ejemplo de una declaración comprobable es:  El rendimiento del programa se producirá dentro de 20 segundos de evento 60% del tiempo; y se producirá dentro de 30 segundos de evento 100% del tiempo. Esta declaración puede verificarse porque usa condiciones concretas y las cantidades mensurables. Si un método no puede inventarse para determinar si el software reúne un requisito particular, entonces ese requisito debe quitarse o debe revisarse.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

3.1.3.7.

Modificable

Un SRS es modificable si, y sólo si, su estructura y estilo son tales que puede hacerse cualquier cambio a los requisitos fácilmente, completamente y de forma consistente mientras conserva la estructura y estilo. Para que sea modificable se requiere un SRS que contenga: a) Tiene un coherente y fácil de usar en la organización de volúmenes de información, un índice y las referencias cruzadas explícitas b) No sea redundante (es decir, el mismo requisito no debe aparecer en más de un lugar en el SRS) c) Exprese cada requisito separadamente, en lugar de intercalarlas con otros requisitos. La redundancia no es un error, pero puede llevar fácilmente a los errores. La redundancia puede ayudar hacer un SRS más leíble de vez en cuando, pero un problema puede generarse cuando el documento redundante se actualiza. Por ejemplo, un requisito puede alterarse en un solo lugar dónde aparece. El SRS se pone incoherente entonces. Siempre que la redundancia sea necesaria, el SRS debe incluir la cruz explícita - las referencias para hacerlo modificable. 3.1.3.8.

Identificable

Un SRS es identificable si el origen de cada uno de sus requisitos está claro y si facilita las referencias de cada requisito en el desarrollo futuro o documentación del mismo. Lo siguiente que se recomiendan dos tipos de identificabilidad: a) El identificable dirigido hacia atrás (es decir, a las fases anteriores de desarrollo). Esto depende explícitamente en cada requisito las referencias de su fuente en los documentos más antiguos. b) El identificable delantero (es decir, a todos los documentos desovados por el SRS). Esto depende en cada requisito en el SRS que tiene un único nombre o número de la referencia. El identificable delantero del SRS es especialmente importante cuando el producto del software entra en el funcionamiento y fase de mantenimiento. Como el código y documentos del plan se modifican, es esencial poder determinar el juego completo de requisitos que pueden afectarse por esas modificaciones. 3.1.3.9.

Preparación de los join del SRS

El proceso de desarrollo de software debe empezar con el proveedor y con el acuerdo del cliente en lo que el software completado debe hacer. Este acuerdo, en la forma de un SRS, debe prepararse juntamente. Esto es importante porque ni el cliente ni el proveedor son calificables para escribir exclusivamente un buen SRS a) Clientes normalmente no entienden bien el diseño del software y proceso de desarrollo bastante bien como para escribir un SRS utilizable. b) Los Proveedores normalmente no entienden bien el problema de los clientes y campo de acción bastante bien como para que especifique los requisitos para un sistema satisfactorio. Por consiguiente, el cliente y el proveedor deben trabajar para producir juntos un buen escrito y completamente entendible SRS. Una situación especial existe cuando el sistema y su software los dos se están definiéndose concurrentemente. Entonces la funcionalidad, interfaces, desarrollo y otros atributos, restricciones del software no son los predefinidos, sino se definen juntamente y están sujetos a la negociación y al cambio. Esto lo hace más difícil, pero no menos importante, para encontrar las características declaradas, un SRS que no obedece los requisitos de su especificación de sistema de padre es incorrecto.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

3.1.3.10.

Evolución de SRS

El SRS puede necesitar evolucionar así como el desarrollo de las actualizaciones del producto de software. Puede ser imposible de especificar un poco a detalle en el momento que el proyecto se inicia (por ejemplo, puede ser imposible de definir toda la estructura de la pantalla para un programa interactivo durante la fase de requisitos). Los cambios adicionales pueden suceder según como las deficiencias se vayan descubriendo, las limitaciones e inexactitudes en el SRS Dos consideraciones en este proceso son las siguientes: a. Deben especificarse los requisitos completamente como se es conocido en el momento, aun cuando las revisiones evolutivas pueden preverse como inevitable. El hecho que ellos están incompletos debe ser anotado. b. Un proceso de cambio formal debe comenzarse para identificarse, el control, dejar huella e informe de lo que proyectaron los cambios. Los cambios aprobados en los requisitos deben incorporarse en el SRS de semejante manera acerca de que: a. Proporcione un lineamiento de la auditoria exacta y completa de cambios b. El permiso de la revisión actual y reemplazó de los cambios en el SRS. 3.1.3.11.

Prototipos

Los prototipos frecuentemente se usan durante una fase de los requisitos de un proyecto. Muchas herramientas existen para generar un prototipo para exhibir algunas características de un sistema, ser creado muy rápidamente y fácilmente. Los prototipos son útiles por las razones siguientes: a) b)

El cliente puede ver el prototipo y reaccionar a él que leer el SRS y reaccionar a él. Así, el prototipo proporciona la regeneración rápida. El prototipo despliega aspectos de anticiparse a la conducta de los sistemas. Así, no sólo produce las respuestas sino también las nuevas preguntas. Esto ayuda a ver el alcance en el SRS. Un SRS basado en un prototipo tiende a sufrir menos cambios durante el desarrollo, así se acorta el tiempo de desarrollo. Un prototipo debe usarse como una manera de sacar los requisitos del software. Pueden extraerse algunas características como pantalla o formatos del reporte directamente del prototipo. Otros requisitos pueden ser inferidos ejecutando los experimentos con el prototipo.

3.1.3.12.

Generando el diseño en el SRS

Un requisito especifica una función externa visible o atributo de un sistema. Un diseño describe un subcomponente particular de un sistema y/o sus interfaces con otros subcomponentes. El diseñador del SRS debe distinguir claramente entre identificar las restricciones del diseño requeridos y proyectar un plan específico. La nota es que cada requisito en el SRS limita las alternativas del plan. Esto no significa, sin embargo, que cada requisito es el plan. El SRS debe especificar qué funciones serán realizadas, con qué datos, para producir qué resultados, en qué situación y para quien. El SRS se debe enfocar en los servicios a ser realizados. El SRS normalmente no debe especificar los puntos del plan como lo siguiente: a) Partir el software en módulos; b) Asignando las funciones a los módulos; c) Describiendo el flujo de información o controles entre los módulos; d) Escogiendo las estructuras de los datos.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Requisitos del plan necesarios En casos especiales algunos requisitos pueden restringir el plan severamente. Por ejemplo, seguridad o requisitos de seguridad pueden reflejarse directamente en el plan como la necesidad a: a) Guarde ciertas funciones en los módulos separadamente; b) El permiso sólo limitó la comunicación entre algunas áreas del programa; c) La integridad de datos mediante chequeos para las variables críticas. Los ejemplos de restricciones del diseño válidos son requisitos físicos, requisitos del desarrollo, normas de desarrollo de software y software de calidad según los estándares. Por consiguiente, los requisitos deben declararse de un punto de vista completamente externo. Al usar a modelos para ilustrar los requisitos, recuerda que el modelo sólo indica la conducta externa, y no especifica un plan. 3.1.3.13.

Requisitos del proyecto generados en el SRS

El SRS debe dirigir el producto del software, no el proceso de producir el producto del software. Los requisitos del proyecto representan una comprensión entre el cliente y el proveedor sobre materias contractuales que pertenecen a la producción de software y así no deben ser incluidos en el SRS. Éstos normalmente incluyen los puntos como: a) El Costo b) Los tiempos de la entrega c) Informando los procedimientos d) Los métodos de desarrollo de Software e) La convicción de Calidad f) La Aprobación y criterio de la comprobación g) Los procedimientos de aceptación Se especifican los requisitos del proyecto en otros documentos, generalmente en un plan de desarrollo de software, un software de calidad o una declaración de trabajo

3.1.4.

Estructura del documento SRS del IEEE 830

3.1.4.1.

Las partes de un SRS

Estas partes se colocan en Figura 1 en un contorno que puede servir como un ejemplo por escribir un SRS. Un SRS no tiene que seguir este contorno o usar los nombres dado aquí para sus partes, un buen SRS debe incluir toda la información que se mencionó aquí Tabla de Contenidos 1. Introducción 1.1 Propósito 1.2 Alcance 1.3 Definiciones, siglas, y abreviaciones 1.4 Referencias 1.5 Apreciación global 2. Descripción global 2.1 Perspectiva del producto 2.2 Funciones del producto 2.3 Características del usuario 2.4 Restricciones 2.5 Atención y dependencias 3. Los requisitos específicos Apéndices Índice

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Introducción La introducción del SRS debe proporcionar una apreciación global del SRS completo. Debe contener las subdivisiones siguientes: a) Propósito b) Alcance c) Definiciones, siglas, y abreviaciones d) Referencias e) Apreciación global Propósito (1.1 del SRS) Esta subdivisión debe: a) Delinear el propósito del SRS; b) Especifique a que público intencional va dirigido el SRS. Alcance (1.2 del SRS) Esta subdivisión debe: a) Identifique el producto (s) del software para ser diseñado por el nombre (por ejemplo, Anfitrión DBMS, el Generador del Reporte, etc.); b) Explique eso que el producto (s) del software que hará y que no hará. c) Describe la aplicación del software especificándose los beneficios pertinentes, objetivos, y metas; d) Sea consistente con las declaraciones similares en las especificaciones de niveles superiores (por ejemplo, las especificaciones de los requisitos del sistema), si ellos existen. Definiciones, siglas, y abreviaciones (1.3 del SRS) Esta subdivisión debe proporcionar las definiciones de todas las condiciones, las siglas, y abreviaciones que exigen interpretar el SRS propiamente. Esta información puede proporcionarse por la referencia a uno o más apéndices en el SRS o por la referencia a otros documentos. Referencias (1.4 del SRS) Esta subdivisión debe: a) Proporcione una lista completa de todas las referencias de los documentos en otra parte en el SRS b) Identifique cada documento por el título, número del reporte (si es aplicable), fecha, y publicación de la organización c) Especifique las fuentes de las referencias de donde se obtuvieron Esta información puede proporcionarse por la referencia a un apéndice o a otro documento. Apreciación global (1.5 del SRS) Esta subdivisión debe: a) Describa lo que el resto del SRS contiene b) Explica cómo el SRS es organizado Descripción global Esta sección del SRS debe describir los factores generales que afectan el producto y sus requisitos. Esta sección no declara los requisitos específicos. En cambio, mantiene un fondo de esos requisitos que se definen en detalle en Sección 3 del SRS y les hacen más fácil entender.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Esta sección normalmente consiste en seis subdivisiones, como sigue: a) La perspectiva del Producto; b) Las funciones del Producto; c) Las características del Usuario; d) Las restricciones; e) Las Asunciones y dependencias; f) Prorrateando de requisitos. Perspectiva del producto (2.1 del SRS) Esta subdivisión del SRS debe poner el producto en la perspectiva con otros productos relacionados. Si el producto es independiente y totalmente autónomo, debe declararse que así es. Si el SRS define un producto que es un componente de un sistema más grande, como frecuentemente ocurre, entonces esta subdivisión debe relacionar los requisitos de ese sistema más grande a la funcionalidad del software y debe identificar las interfaces entre ese sistema y el software. Un diagrama del bloque que muestra los componentes mayores del sistema más grande, las interconexiones, y las interfaces externas pueden ser útiles. Esta subdivisión también debe describir cómo el software opera dentro de las varias restricciones. Por ejemplo, estas restricciones podrían incluir: a) las interfaces del Sistema; b) las interfaces del Usuario; c) las interfaces del Hardware; d) las interfaces del Software; e) las interfaces de Comunicaciones; f) la Memoria; g) los Funcionamientos; h) los requisitos de adaptación del Site.  Interfaces del sistema. Esto debe listar cada interfaz del sistema y debe identificar la funcionalidad del software para lograr el requisito del sistema y la descripción de la interfaz para empatar el sistema.  Interfaces con el usuario. Esto debe especificar a lo siguiente: a) Las características lógicas de cada interfaz entre el producto del software y sus usuarios. Esto incluye las características de la configuración (por ejemplo, formatos de la pantalla requeridos, página o esquemas de la ventana, los reportes o menús o disponibilidad de llaves de la función programables) necesario para lograr los requisitos del software. b) Todos los aspectos para perfeccionar la interfaz con la persona que debe usar el sistema. Esto puede comprender una lista de lo que hace y no hace simplemente delante de cómo el sistema aparecerá al usuario. Un ejemplo puede ser un requisito para la opción de mensajes de error largos o cortos. Como todos, estos requisitos deben ser comprobables, debe especificarse en los Atributos de Sistema de Software bajo una sección tituló Facilidad de Uso.  Interfaces con el hardware. Esto debe especificar las características lógicas de cada interfaz entre el producto del software y los componentes del hardware del sistema. Esto incluye las características de la configuración (el número de puertos, la instrucción set, etc.), también cubre como qué dispositivos serán apoyados, cómo ellos serán apoyados y protocolos. Por ejemplo, el apoyo de las terminales puede especificarse cuando tienen full-screen.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

 Interfaces con el software. Esto debe especificar el uso de otros productos del software requeridos (por ejemplo, un sistema de dirección de datos, un sistema operativo o un paquete matemático) e interfaces con otros sistemas de la aplicación (por ejemplo, la unión entre el Sistema de Cuentas, el Sistema por Cobrar y un Sistema del Mayor General). Para cada uno el producto del software requirió proporcionarse:  El nombre  El código nemotécnico  El número de la especificación  El número de la versión  La fuente Para cada interfaz, lo siguiente debe proporcionarse: La discusión del propósito de la interfaz del software en relación con el producto del software. La definición de la interfaz por lo que se refiere a los mensajes contenidos y formatos. No es necesario detallar cualquiera bien la documentación de la interfaz, pero una referencia al documento que define la interfaz se requiere.  Interfaces de comunicaciones Esto debe especificar las varias interfaces a las comunicaciones como los protocolos de las redes locales, etc.  Restricciones de memoria Esto debe especificar cualquier característica aplicable y límites en la memoria primaria y la memoria secundaria.  Funcionamientos Esto debe especificar los funcionamientos normales y especiales requeridos por el usuario como: a) Los varios modos de funcionamientos en la organización del usuario (por ejemplo, los funcionamientos de iniciar el usuario) b) los Periodo de funcionamientos interactivos y periodo de funcionamientos desatendido c) Datos que procesan las funciones de apoyo d) el Apoyo y funcionamientos de la recuperación  Requisitos de adaptación del Site. Esto debe: a) Defina los requisitos para cualquier dato o la secuencia de inicialización que son específico a un sitio dado, la misión o el modo operacional (por ejemplo, los límites de seguridad, etc.); b) Especifique el sitio o los rasgos que se deben relacionar que deben modificarse para adaptar el software a una instalación particular. Funciones del Producto (2.2 del SRS) Esta subdivisión del SRS debe proporcionar un resumen de las funciones mayores que el software realizará. Por ejemplo, un SRS para un programa de contabilidad puede acostumbrar esta parte a dirigirse al mantenimiento de Cuenta de Cliente, declaración del cliente y preparación de la factura sin mencionar la inmensa cantidad de detalle que cada uno de esas funciones requiere.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

A veces el resumen de la función que es necesario para esta parte puede tomarse directamente de la sección de la especificación en el nivel superior (si uno existe) eso asigna las funciones particulares al producto del software. Note que eso es por causa de la claridad. a) Las funciones deben organizarse en cierto modo eso hace la lista de funciones entendible al cliente o a cualquiera nada más leyendo el documento la primera vez. b) Pueden usarse los métodos Textuales o gráficos para mostrar las funciones diferentes y sus relaciones. No se piensa que el diagrama muestra un diseño de un producto, sino simplemente muestra la relación lógica entre las variables. Características del usuario (2.3 del SRS) Esta subdivisión del SRS debe describir esas características generales de los usuarios intencionales del producto que incluye nivel educativo, experiencia, y la especialización técnica. Restricciones (2.4 del SRS) Esta subdivisión del SRS debe proporcionar una descripción general de cualquier otro punto que limitará las opciones de los diseñadores. Éstos incluyen: a) Las políticas reguladoras b) Las limitaciones del Hardware c) Las Interfaces a otras aplicaciones d) El funcionamiento Paralelo e) Las funciones de la Auditoría f) Las funciones de Control g) Los requisitos de lenguaje h) Los protocolos Señalados (por ejemplo, XON-XOFF, ACK-NACK) i) Los requisitos de Fiabilidad j) Credibilidad de la aplicación k) La Seguridad y consideraciones de seguridad. Atenciones y dependencias (2.5 del SRS) Esta subdivisión del SRS debe listar cada uno de los factores que afectan los requisitos declarados en el SRS. Estos factores no son las restricciones del diseño en el software pero son, más bien, cualquier cambio a ellos eso puede afectar los requisitos en el SRS. Por ejemplo, una suposición puede ser que un sistema operativo específico estará disponible en el hardware designado para el producto del software. Si, de hecho, el sistema operativo no está disponible, los SRS tendrían que cambiar de acuerdo con entonces. Prorratear los requisitos (2.6 del SRS) Esta subdivisión del SRS debe identificar requisitos que pueden tardarse hasta las versiones futuras del sistema.

3.1.5. Alternativas en la especificación de requisitos específicos, según IEEE 830 Esta sección del SRS debe contener todos los requisitos del software a un nivel de detalle suficiente para permitirles a los diseñadores diseñar un sistema para satisfacer esos requisitos, y a los auditores a probar que el sistema satisface esos requisitos. A lo largo de esta sección, cada requisito declarado debe ser externamente perceptible por los usuarios, operadores u otros sistemas externos.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Estos requisitos deben incluir por lo menos una descripción de cada entrada (el estímulo) en el sistema, cada salida (la contestación) del sistema, y todas las funciones realizadas por el sistema en la salida a una entrada o en el apoyo de la salida. Esta es la parte más grande y más importante del SRS, los principios siguientes aplican: a) Deben declararse los requisitos específicos en la conformidad con todas las características descritas. b) Los requisitos específicos deben tener referencias cruzadas a documentos más actuales que los relacionan. c) Todos los requisitos deben ser singularmente identificables. d) Debe prestarse la atención debida a organizar los requisitos para aumentar al máximo la legibilidad. Interfaces externas Ésta debe ser una descripción detallada de todas las entradas y salidas del sistema del software. Debe complementar las descripciones de la interfaz en 3.2 y no debe repetirse la información allí. Debe incluir ambas entradas/salidas y debe estructurarse como sigue: a) El nombre de artículo; b) La descripción de propósito; c) La fuente de entrada o destino de salida; d) El rango válido, exactitud, y/o tolerancia; e) Las unidades de medida; f) tiempos; g) Las relaciones a otras entradas/salidas; h) El formato de pantalla /organización; i) El formato de ventanas/organización; j) Los formatos de los datos; k) Los formatos de los comandos; l) Fin de mensajes. Funciones Los requisitos funcionales deben definir las acciones fundamentales que deben tener lugar en el software, aceptando y procesando las entradas, procesando y generando las salidas. Éstos generalmente se listan como "debe" declaraciones que empiezan con "El sistema debe…." Éstos incluyen: a) verificar la validez sobre las entradas b) la secuencia exacta de las operaciones c) las contestaciones a las situaciones anormales, incluyendo  Overflow  Facilidades de comunicación  Manejo de errores y recuperación d) el efecto de parámetros e) la relación de salidas a las entradas, incluyendo  Las secuencias de entrada/salidas  Las fórmulas de entrada y su conversión a la salida Puede ser apropiado dividir los requisitos funcionales en subfunciones o subprocesos. Esto no implica que el plan del software también se dividirá así. Requisitos del desarrollo Esta subdivisión debe especificar los requerimientos estáticos y dinámicos que se pusieron en el software o en la interacción humana con el software en conjunto. Los requisitos estáticos pueden incluir a lo siguiente: a) El número de terminales a ser apoyadas

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

b) El número de usuarios simultáneos ser apoyados c) La cantidad y tipo de información que se manejara A veces se identifican los requisitos estáticos bajo una sección separada titulada la Capacidad. Por ejemplo, los requisitos dinámicos pueden incluir los números de transacciones, tareas y la cantidad de datos a ser procesado dentro de ciertos periodos de tiempo para las condiciones del trabajo normales y máximas. Todos que estos requisitos deben declararse en las condiciones mensurables. Por ejemplo: 95% de las transacciones se procesarán en menos de 1 seg. Requisitos del banco de datos lógicos Esto debe especificar los requisitos lógicos para cualquier información que será puesta en un banco de datos. Esto puede incluir a lo siguiente: a) los tipos de información usadas por varias funciones b) la frecuencia de uso c) accediendo las capacidades d) las entidades de los datos y sus relaciones e) las restricciones de integridad f) requerimientos en la retención de datos. Restricciones del diseño Esto debe especificar las restricciones del diseño que pueden imponerse por otros estándares, las limitaciones del hardware, etc. Aceptación de las normas Esta subdivisión debe especificar los requisitos derivados de estándares existentes o regulaciones. Ellos pueden incluir a lo siguiente: a) el formato del reporte; b) los nombres de los datos; c) los procedimientos de contabilidad; d) los lineamientos de la Auditoría. Por ejemplo, esto podría especificar el requisito para el software y rastrear la actividad del proceso. Se necesita rastrear algunas aplicaciones para encontrarse al menos las normas reguladoras o financieras. Por ejemplo, un requisito de rastro de auditoría puede declarar que deben grabarse todos los cambios a un banco de datos de la nómina en un archivo del rastro con los valores antes del proceso y después del proceso. Atributos del software del sistema Hay varios atributos del software que puede servir como los requisitos. Es importante que los atributos se especifiquen para que su logro pueda verificarse objetivamente. Fiabilidad Esto debe especificar que los factores exigieron establecer la fiabilidad requerida del sistema del software al momento de la entrega. Disponibilidad Esto debe especificar que los factores exigieron garantizar un nivel de disponibilidad definido para el sistema como un punto de control, la recuperación y al iniciar. Seguridad Esto debe especificar los factores que protegen el software del acceso accidental o malévolo, uso, modificación, destrucción o descubrimiento. Los requisitos específicos en esta área podrían incluir la necesidad a: a) Utilice ciertas técnicas de encriptamiento b) Tenga Log de entrada o históricos de datos c) Asigne ciertas funciones a módulos diferentes d) Restrinja las comunicaciones entre algunas áreas del programa e) La integridad de datos se verifique para variables críticas.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Mantenimiento Esto debe especificar atributos de software que relaciona a la facilidad de mantenimiento del propio software. Puede haber algún requisito con toda seguridad de modularidad, interfaces, la complejidad, etc. no deben ponerse los requisitos aquí. Portabilidad Esto debe especificar atributos de software que relaciona a la facilidad de poner el software a otro servidor y/o sistemas operativos. Esto puede incluir a lo siguiente: a) el Porcentaje de componentes con código cliente-servidor; b) el Porcentaje de código del cliente-servidor; c) el Uso de un idioma portátil probado; d) el Uso de un compilador particular o subconjunto de lenguajes; e) el Uso de un sistema operativo particular. Organizar los requisitos específicos Por algo los requisitos detallados de los sistemas triviales tienden a ser extenso. Por esta razón, se recomienda que sean cuidadosos de organizar éstos de una manera óptima para que sean entendibles. Modo del sistema Algunos sistemas se comportan diferentes dependiendo del modo de operación. Por ejemplo, un sistema de control puede tener juegos diferentes de funciones que dependen de su control: entrenando, normal o emergencia. Al organizar esta sección por el modo. La opción depende de las interfaces y del desarrollo que son dependientes del modo de acceso. Clases de usuario Algunos sistemas proporcionan juegos diferentes de funciones a las clases diferentes de usuarios. Por ejemplo, un sistema de mando de ascensor presenta las capacidades diferentes a los pasajeros, obreros de mantenimiento y bomberos. Al organizar esta sección por la clase del usuario. Objetos Los objetos son entidades del mundo real que tienen una contraparte dentro del sistema. Por ejemplo, en un sistema que supervisa pacientes, los objetos incluyen a los pacientes, los sensores, enfermeras, los cuartos, médicos, las medicinas, etc. Asociado con cada objeto un juego de atributos a está (de ese objeto) y funciones (realizadas por ese objeto). Estas funciones también se llaman servicios, métodos o procesos. Al organizar esta sección por el objeto. Nota que al poner los objetos puede compartir atributos y servicios. Éstos se agrupan como las clases. Rasgo Un rasgo es un servicio externamente deseado por el sistema que puede exigir a una secuencia de entradas efectuar el resultado deseado. Por ejemplo, en un sistema del teléfono, los rasgos incluyen la llamada local, llamada remitida y llamada en conferencia. Cada rasgo generalmente se describe en una secuencia de estímulocontestación. Estímulo Algunos sistemas pueden organizarse mejor describiendo sus funciones por lo que se refiere a los estímulos. Por ejemplo, pueden organizarse las funciones de un avión automático que aterriza, el sistema en las secciones para la pérdida del control, el cambio súbito en el destino, la velocidad vertical excesiva, etc.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Contestación Algunos sistemas pueden organizarse mejor describiendo todas las funciones en el apoyo de la generación de una contestación. Por ejemplo, pueden organizarse las funciones de un sistema del personal en secciones que corresponden a todas las funciones asociadas con los sueldos generados, todas las funciones asociadas con generar una lista actual de empleados, etc. Jerarquía Funcional Cuando ninguno de los esquemas orgánicos anteriores demuestra ser útil, la funcionalidad global puede organizarse en una jerarquía de funciones organizada por cualesquier entradas común, rendimientos comunes o el acceso de los datos interiores común. Los datos fluyen pueden usarse diagramas y diccionarios de datos para mostrar las relaciones entre las funciones y datos. Al organizar esta sección por la jerarquía funcional. Comentarios adicionales Siempre que un nuevo SRS se contemple, más de una de las técnicas organizacionales dadas pueden ser apropiadas. En tal caso, organice los requisitos específicos para jerarquías múltiples detalladas a las necesidades específicas del sistema bajo la especificación. Hay muchas anotaciones, métodos y herramientas de apoyo automatizadas disponibles para ayudar en la documentación de requisitos. La mayor parte, su utilidad es una función de organización. Por ejemplo, al organizar por el modo, máquinas de estado finitas o los mapas estatales pueden demostrar utilidad; al organizar por el objeto, el análisis objeto-orientado puede demostrar utilidad; al organizar por el rasgo, las secuencias de estímulo-contestación pueden demostrar utilidad y al organizar por la jerarquía funcional, los datos fluyen según los diagramas y los diccionarios de datos pueden demostrar también utilidad. 3.1.5.1.

Información de apoyo

La información de apoyo hace más fácil al SRS para usarse. Incluye a lo siguiente: a) Tabla de contenidos b) Índice c) Apéndice Tabla de contenidos e índice La tabla de contenidos e índice es bastante importante y debe seguir las prácticas de las composiciones generales. Apéndices Los apéndices no siempre son considerados parte del SRS real y no siempre son necesarios. Ellos pueden incluir: a) Ejemplos de formatos de las entradas/salidas, las descripciones del análisis del costo que se estudiaron o resultados de estudios del usuario b) Apoyando o dando información a fondo que puede ayudar a los lectores del SRS c) Una descripción de los problemas a ser resuelto por el software Las instrucciones del empaquetamiento especiales para el código y los medios de comunicación para reunir la seguridad, exportar la carga inicial u otros requisitos. Cuando los apéndices son incluidos, el SRS debe declarar explícitamente sí o no los apéndices serán considerados parte de los requisitos.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

3.2. PROTOTIPADO 3.2.1. Prototipado: conceptos, métodos y herramientas 3.2.1.1.Concepto Los prototipos son una visión preliminar del sistema futuro que se implantara. La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información específica a cerca de los requerimientos de información de los usuarios. Los prototipos efectivos deben hacerse tempranamente en el ciclo de vida del desarrollo de sistemas, durante la fase de determinación de requerimientos. En esta forma el analista está buscando las reacciones iniciales de los usuarios y de la administración hacia el prototipo, sugerencias de los usuarios sobre cambios o limpieza del sistema para el que construye un prototipo, posibles innovaciones y planes de revisión que detallan que parte del sistema necesita realizarse primero. 3.2.1.2.Métodos y Herramientas Tipos de Información que busca el Analista durante la Elaboración de Prototipos.  Reacciones del usuario.  Innovaciones.  Sugerencias del usuario.  Plan de revisión. Reacciones: Son recopiladas por medio de observaciones, entrevista y formas de retroalimentación, diseñadas para recoger la opinión de cada persona acerca del prototipo cuando interactúa con él. Por medio de estas reacciones el analista descubre muchas perspectivas en el prototipo incluyendo el agrado que tenga el usuario al sistema. Sugerencias: El analista también está interesado en las sugerencias de los usuarios y la administración acerca como refinar o cambiar el prototipo presentado. Las sugerencias son recolectadas de aquellos que experimenta con el prototipo, mediante un periodo de tiempo específico. El tiempo que pasan los usuarios con el prototipo depende por lo general de su dedicación e interés en el proyecto de sistemas. Las sugerencias son el producto de la interacción de los usuarios con el prototipo. Estas sugerencias deben apuntar al analista hacia formas de refinación, cambio o limpieza del prototipo para que se ajuste mejor a las necesidades de los usuarios. Innovaciones: Son parte de las informaciones buscada por el equipo de análisis de sistema. Son capacidades nuevas del sistema que no habían sido pensadas antes de la interacción con el prototipo. Van más allá de las características prototípicas actuales añadiendo algo nuevo e innovador.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Plan de Revisión: Ayuda a identificar prioridades para lo que se debe construir un prototipo a continuación. En situaciones donde están involucradas muchas ramas de la organización, los planes de revisión ayuda a determinar para cuáles hay que construir un prototipo a continuación. La información recolectada en la fase de confección del prototipo permite al analista asignar prioridades y redirigir los planes sin realizar gastos con un mínimo de ruptura. La elaboración de prototipo y la planeación van mano a mano.

3.2.2. Clases de prototipos Los prototipos pueden ser de las siguientes clases:  Prototipo Parchado  Prototipo no Operacional  Prototipo Primero de una Serie  Prototipo de Características Seleccionadas Prototipo Parchado: Es un sistema que tiene todas las características propuestas pero es realmente un modelo básico que eventualmente será mejorado. Este tipo de prototipo trabaja pero no es eficiente ni elegante. Prototipo no Operacional: La segunda concepción de un prototipo es la de un modelo o escala no funcional para objeto de probar determinados aspectos del diseño. Este puede ser hecho cuando la codificación requerida por las aplicaciones es muy amplia para hacerse el prototipo y, sin embargo se puede obtener una idea útil del sistema por medio de la elaboración de prototipos de la entrada y salido solamente. Puede buscar las opiniones de los usuarios sobre la interfaces (entrada y salida). Debido al costo y tiempo excesivo podría no ser realizado, sin embargo se puede tomar algunas de las utilidades del sistema con base en la entrada y salida ya en el prototipo. Prototipo Primero de una Serie: Una tercera concepción de la elaboración de prototipos involucrados la creación de un primer modelo o escala completa de un sistema, llamado también piloto. Este tipo de prototipo es útil cuando se tiene planeadas muchas instalaciones del mismo sistema. El modelo funcional o escala completa permite la interacción realista con el nuevo sistema, pero minimiza el costo de superar cualquier problema que presente. Prototipo de Características Seleccionadas: Un prototipo de características seleccionada permite que el sistema sea puesto en su lugar mientras otras características pueden ser añadidas en fecha posterior. Se refiere a la construcción de un modelo operacional que incluye algunas, pero no todas, de las características que tendrá el sistema final. Cuando se construye este tipo de prototipo, el sistema se va construyendo por módulos, de modo que si las características reciben una evaluación satisfactoria, éstas puedan incorporarse en el sistema final, mucho más grande sin tener que hacer un trabajo inmenso en interfaces. Los prototipos hechos en esta forma son parte del sistema actual, no son simplemente una maqueta.

3.2.3. Validación y Verificación mediante prototipos

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

Cuando haya que decidir si hay que incluir la elaboración de prototipos como parte del ciclo de vida de desarrollo de sistemas, el analista necesita considerar cuál tipo de problema está siendo resuelto y en qué forma el sistema presenta la solución.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Los lineamientos para la verificación y validación del Desarrollo de un Prototipo son: a) Trabajar en módulos manejables. b) Construir el prototipo rápidamente. c) Modificar el prototipo en interacción sucesiva. d) Enfatizar la interfaz del usuario. Trabajar en Módulos Manejables: Es bueno que el analista en modelos manejables cuando se realiza el prototipo de algunas de las características de un sistema para obtener un modelo funcional. Un modelo manejable es aquel que permite la interacción con sus características principales, pero todavía puede ser construido por separado de otros módulos del sistema. Las características del módulo que se consideran menos importantes son intencionalmente dejadas fuera del prototipo inicial. Construcción Rápida del Prototipo: La velocidad es esencial para la elaboración satisfactoria de un prototipo en un sistema. El prototipo ayuda a acortar el tiempo de la interacción del sistema con el usuario para que pueda empezar a experimentar con él. Se usan técnicas de recolección de información tradicional tales como: entrevistas, las observaciones e investigaciones de datos de archivo. La elaboración de un prototipo debe llevarse a cabo en una semana, para construir un prototipo tan rápidamente se deben de usar herramientas especiales tales como: Los sistemas de administración de las base de datos y software, existente que permitan la entrada y salida generalizada. En esta etapa del ciclo de vida el analista sigue recopilando información acerca de lo que se necesita y quieren los usuarios del sistema. El poner un prototipo operacional rápidamente junto a las primeras etapas del ciclo de vida de desarrollo de sistemas, permite obtener observaciones valiosas sobre la manera en que se debe realizar el resto del proyecto. De este modo se le va mostrando al usuario como actúan las partes del sistema. Modificaciones del Prototipo: Un tercer lineamiento para el desarrollo del prototipo es que debe ser flexible para futura modificaciones. Esto significa crearlo en módulos que no sean muy interdependientes. Por lo general el prototipo es modificado varias veces pasando a través de varias interacciones. Los cambios al prototipo deben mover al sistema más cerca a lo que los usuarios dicen que es importante. Cada modificación necesitan otras evaluaciones de los usuarios, estas modificaciones se deben realizar velozmente en uno o dos días, esto depende también del usuario y que tan rápido sea su evaluación. Enfatizar la Interfaz de Usuarios: La interfaz del usuario con el prototipo (y eventualmente con el sistema) es muy importante debido que lo que se está tratando realmente de lograr con el prototipo es hacer que los usuarios muestren cada vez más sus requerimientos de información, debe ser capaz de interactuar fácilmente con el prototipo del sistema. El objetivo del analista es diseñar una interfaz que permita al usuario interactuar con el sistema con un mínimo de entrenamiento y que permita el máximo de control del usuario sobre las funciones representadas.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

3.2.4. Prototipado: ventajas e inconvenientes 3.2.4.1.Ventajas de los prototipos Cambio de un Sistema en Etapas Tempranas de sus Desarrollo: La elaboración de prototipos satisfactoria depende de la retroalimentación temprana y frecuente de los usuarios para que ayuden a modificar el sistema y hagan que tenga una respuesta más ágil a las necesidades actuales. Los cambios tempranos son menos caros que los cambios hechos posteriormente en el desarrollo del proyecto. Desechado de Sistemas Indeseables: Una segunda ventaja del uso de prototipos como una técnica para la recopilación de información es la posibilidad de desechar un sistema que no es lo que los usuarios y analistas esperaban. Diseño de un Sistema para las Necesidades y Expectativas de los Usuarios: Una tercera ventaja de la elaboración de prototipos es que el sistema que está siendo desarrollado debe ajustarse mejor a las necesidades y expectativas de los usuarios. Esto quiere decir que se pueden atacar las necesidades de usuarios y expectativas más de cerca. 3.2.4.2.Desventajas de los prototipos Puede ser bastante difícil el manejar el prototipo como un proyecto dentro de un esfuerzo para un sistema más grande. Es que si un sistema es muy necesario y es bienvenido rápidamente, puede ser aceptado el prototipo en sus estado sin terminar y presionando para que sea puesto en servicio sin los refinamientos necesarios. En este caso el prototipo no tendrá las funciones necesarias y eventualmente cuando se dé cuenta de las deficiencias se puede desarrollar un rechazo del usuario. 3.2.4.3.Papel del usuario en los prototipos Hay tres formas principales en que un usuario puede ser de ayuda en la elaboración del Prototipo. a) Experimentando con el Prototipo. b) Reaccionar abiertamente ante el Prototipo. c) Sugiriendo adiciones y/o eliminaciones del prototipo. Experimentando con el Prototipo: Los usuarios deben tener libertad para experimentar con el prototipo, y no una simple lista de características del sistema, el prototipo permite a los usuarios la realidad de la interacción real. El analista debe estar presente la mayor parte del tiempo en que se esté experimentando con el prototipo. Reaccionar Abiertamente ante el Prototipo: Si los usuarios se siente temerosos de hacer comentarios, o criticar lo que puede ser un proyecto consentido de superiores o iguales dentro de la organización, es poco probable que se dé reacciones abiertas ante el prototipo. Una forma para aislarlos de influencias organizacionales no deseada es proporcionar un periodo privado, para que los usuarios interactúen con y respondan al prototipo. El hacer que los usuarios se sienta lo suficientemente seguros para dar una reacción abierta es parte de la realización entre los analista y usuarios que el equipo tiene que construir.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

Sugerencias de Cambios al Prototipo: Un tercer aspecto del papel de los usuarios en la elaboración de los prototipos es sugerir adiciones y/o eliminaciones a las características que se están probando. El papel del analista es deducir tales sugerencias, asegurando a los usuarios que tal retroalimentación que proporciona es tomada en serio, observando a los usuarios mientras interactúan y realizando entrevistas cortas y específicas en relación con su experiencia con el prototipo.

3.2.5. Importancia de la notación a nivel de interfaz Como parte del artefacto, los elementos del interfaz suponen dentro de los procesos interactivos, elementos simbólicos que están inscritos en las gramáticas visuales que operan en el lenguaje humano. Desde esta perspectiva el interfaz ha generado su propia gramática de representación e interacción, suponiendo actualmente un modelo que debe ser aprendido por cualquier persona dispuesta a interaccionar con un ordenador. Desde este punto de vista, el análisis de sus elementos supone una introducción a la gramática interactiva en el contexto de las interfaces gráficas. Esta parte del trabajo está dividido en dos apartados, por un lado tenemos la definición de una serie de recursos interactivos que han sido materializados a través de la historia de la interfaz, y por lo tanto, fundamentales para entender los mecanismos de interacción actuales. La otra parte analiza y define los elementos interactivos estandarizados actualmente en las interfaces gráficas buscando definir de algún modo la gramática interactiva actual que subyace en la interacción con ordenadores. 3.2.5.1.Recursos interactivos en la interfaz gráfica El paradigma W.I.M.P. WIMP es una abreviación, de los conceptos de ventanas, iconos, menús y dispositivos de interfaz humano. Designa de un modo genérico el primer modelo interactivo desarrollado por el PARC para interactuar con los ordenadores a través de las interfaces gráficas de usuario. Como se verá más adelante, en este apartado, las ventanas, los iconos y los menús, son elementos interactivos, que pertenecen a la parte simbólico-lingüística de la interfaz. El ratón pertenece al lado de interfaz humana o física del interfaz gráfico. Juntos constituyen el paradigma más potente y eficiente alcanzado hasta el momento para interactuar con los ordenadores personales. Aunque en la actualidad se intenta superar este paradigma desde la combinación de dispositivos de interfaz humano novedosos (pantallas táctiles) en combinación con nuevas metáforas visuales, el paradigma WIMP es el que está actualmente vigente en el grueso de los ordenadores personales que operan en la actualidad y dispositivos interactivos introducidos en el mercado. La metáfora del escritorio La metáfora de escritorio es un tipo de metáfora visual desarrollada igualmente en el centro de investigación del PARC, para facilitar el proceso de interacción con los ordenadores. Consiste en representar recursos y elementos y funciones del sistema informático como ficheros, datos, archivos, a través de iconos sobre los cuales es posible interactuar. El escritorio es la metáfora más global y primaria de las que gobierna la interfaz gráfica de usuario. El escritorio es la primera metáfora, representa el espacio de trabajo donde se manipula, se mueve, y organiza la información. En base a la metáfora del espacio-escritorio se desarrollan el resto de las metáforas, como son las carpetas, los documentos, las herramientas, lápices y tinteros. La metáfora del escritorio constituye un recurso potente que posibilita al usuario relacionar de forma intuitiva, a través de signos, elementos y funciones del sistema que de otro modo serían bastante complejas de entender y ejecutar. Permite el

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

reconocimiento intuitivo a través de signos, normalmente familiares al usuario. Permite la manipulación de los signos de modo que su representación simbólica da orientación sobre qué tipo de objeto es y qué tipo de acciones podemos realizar sobre él. Posibilita establecer relaciones lógicas entre datos que de otra forma serían complicadas de expresar, comprender y ejecutar. Actualmente la metáfora del escritorio, es usada en el grueso de los ordenadores que trabajan con interfaces gráficas aunque sus elementos han tardado tiempo en ser definidos y actualmente continúan en constante evolución en cuanto están sujetos a los procesos de diseño y al acondicionamiento de la semántica humana. La manipulación directa Uno de los elementos de interacción posibles dentro del contexto de las interfaces gráficas a través de la metáfora de escritorio, es el de manipulación directa sobre la interfaz. Fue desarrollada por primera vez por las investigaciones del PARC, e introducidas con el ordenador XEROX STAR. Cuando los datos informáticos han sido transformados en iconos a través de la representación metafórica del escritorio, los objetos se convierten en datos reales que pueden ser manipulados de forma virtual. Las acciones más habituales a través de la manipulación directa de iconos en el escritorio, consiste en mover, arrastrar desde un área a otra, seleccionar, y eliminar. Dependiendo del software sobre el que se trabaje la manipulación directa sobre los elementos representados pueden formalizar diferentes acciones en el interfaz. El proceso de manipulación directa, parte de dos principios fundamentales: 1.El usuario en primer lugar puede interactuar con todos aquellos elementos que ve y que disponen de la condición de objeto interactivo. 2. El usuario puede observar de forma instantánea y directa el efecto de las acciones que produce en el interfaz. Obtiene feedback instantáneo de sus acciones. Estos dos principios basados en poder actuar sobre lo que se ve, y ver sobre lo que se actúa, da al interfaz la propiedad de ser manipulable como podría ser cualquier objeto de la vida real y es a esta propiedad a lo que se llama manipulación directa. Sintaxis de interacción: nombre, luego verbo. El escritorio es el espacio metafórico habilitado para la interacción del sujeto con los objetos interactivos que dispone el sistema. El principio de “nombre, luego verbo” indica un proceso de interacción con el ordenador. Cuando el usuario interacciona dentro del interfaz lo primero que debe hacer en base a este principio, es seleccionar un objeto – icono (nombre) y posteriormente asignarle una acción a realizar (verbo). Como podemos observar esta sintaxis es acorde con el uso que hacemos en ocasiones con el lenguaje verbal. El principio de nombre, luego verbo, está inscrito como hemos visto dentro de la metáfora del escritorio, hace uso del proceso de manipulación directa, y tiene dos formas de ser ejecutado sobre el interfaz: En el primer modelo de ejecución, el usuario selecciona un objeto de interés (nombre) y asigna una acción concreta al objeto (verbo). Todas las acciones posibles están sistematizadas en los menús, donde sólo aparecen aquellas acciones asociadas al objeto interactivo. Este procedimiento, tiene ventajas significativas al respecto de la interfaz de línea de comandos, a niveles de memorización y aprendizaje en cuanto se le presentan de forma clara al usuario las posibles acciones sobre el objeto y por lo tanto no está obligado a memorizar comandos y sus posibles sintaxis de ejecución. El segundo modelo de ejecución de este principio está basado en el mismo principio nombre- verbo, pero esta vez, el usuario selecciona el objeto (nombre), y a través de la manipulación directa, arrastra el objeto sobre otro, de modo que la asociación semántica de ambos objetos, constituyen la definición de la acción (verbo). Un ejemplo de este tipo de paradigma, lo constituye el documento que va a la papelera. En base a este paradigma, asociar un documento de texto (nombre), y arrastrarlo a la papelera, supone una acción definida (verbo) sin necesidad de indicar al ordenador más acciones de las que se han realizado.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

100

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

101

3.2.5.2.WYSIWYG, Obtienes lo que ves El concepto de WYSIWYG es un principio de diseño en sistemas interactivos, que intenta hacer coincidir los signos representados en la interfaz, con el resultado final que se obtiene a través de algún dispositivo de salida. Nació conjuntamente con la metáfora de escritorio, en el contexto de la impresión, donde hace referencia más concretamente a la relación entre un documento en pantalla y el resultado final impreso. Normalmente, lo que uno ve en la pantalla del ordenador y lo que uno obtiene en una impresión tienen naturalezas tecnológicas muy diferentes. En los mismo términos, conseguir que una cosa que se ve en la pantalla y algo que es impreso a través de una impresora sean próximos, entraña un conjunto de problemas técnicos nada fácil de lidiar. Algunas cuestiones problemáticas relacionadas con el diseño WYSIWYG en el interfaz podrían ser las siguientes:  Escalabilidad: Consistiría en hacer coincidir y coordinar la representación de las escalas del objeto en pantalla de modo que se acerque a las expectativas del sujeto en la vida real.  Similitud: Consiste en acercar en forma, color y textura los signos que se recrean en pantalla y los signos que posteriormente serán impresos en el medio, por ejemplo la representación de imágenes o tipografía en pantalla y su reproducción final.  Modelado: La simulación de modelos tridimensionales, y sus posibles resultados están dentro de las problemáticas que este principio de diseño debe contemplar dentro de un sistema interactivo. El principio WYSIWYG fue primordial en los primeros diseños de Xerox, que buscaban un ordenador capaz de sustituir una oficina de trabajo en el ámbito de la impresión. Actualmente el principio WYSIWYG constituye uno de los fundamentos del diseño ocultos tras la metáfora del escritorio. No sólo abrimos y cerramos “documentos”, sino además escribimos en “procesadores de texto” donde podemos observar “las páginas” y los márgenes que luego configurarán nuestro documento final. Actualmente el principio WYSIWYG es el que ha modelado el espacio metafórico de la interfaz, haciéndonos creer que lo que vemos es tan real como lo que obtendremos posteriormente. La consistencia en el diseño La consistencia en el diseño es el proceso mediante el cual se establece a la hora de estructurar menús, comandos y elementos de navegación en la interfaz, un orden común y coherente. De este modo, el usuario sólo tiene que aprender una sola vez donde localizar las acciones en los menús, y aunque se produzca un cambio en la aplicación, sepa localizarlos sin problemas. La consistencia en el diseño de interfaces, es un elemento muy importante porque reduce la curva de aprendizaje del sistema por parte del usuario. Aunque la consistencia tenga una relación con las gramáticas del diseño visual, en cuanto es aplicada a través de su lenguaje, está inscrita dentro de la arquitectura de la información, la cual tiene como objetivo la “planificación, estudio y análisis de la selección, organización, disposición y presentación de los datos contenidos en los sistemas de información interactivos. Es la encargada de establecer pautas generales, macroscópicas, desde las cuales sea posible establecer las guías de diseño para toda la interfaz. Fue Apple quien aplicó este concepto en el diseño de las interfaces gráficas, se puede observar especialmente en el menú que mantiene en el escritorio para acceder de forma global a las variables del sistema.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

102

3.2.6. Elementos interactivos en la interfaz gráfica 3.2.6.1.Dispositivos de interfaz humana Los dispositivos de interfaz humana son los diseñados para conectar alguna parte del cuerpo del ser humano con la interfaz gráfica de modo que puedan ser introducidos datos en el sistema. Normalmente son dispositivos que permiten introducir directamente, y en tiempo real, información de “orientación” y “acción” al ordenador sincronizado simultáneamente con una interfaz gráfica. Los dispositivos de interfaz humana como el ratón, pueden representar en la interfaz gráfica gestos físicos y movimientos, como “apuntar”, “pulsar”, “arrastrar”, “trasladar”, “mover” de forma metafórica que de otro modo sería muy complejo simular. La interfaz humana forma actualmente, una parte indisoluble respecto a la interfaz gráfica de usuario. Son partes interconectadas de un mismo paradigma de interacción, donde se necesitan uno al otro indispensablemente para que la interacción con el sistema se realice adecuadamente. Existen diferentes tipos de interfaces humanas los cuales han sido desarrollados paralelamente a lo largo de la historia de la interfaz gráfica. Los más importantes han sido, el teclado, el ratón de ordenador, el trackball (bola), el cursor táctil (touchpad), la tableta gráfica y el Joystick. Cada uno de estos dispositivos sirve para introducir un tipo de información específica en el sistema a través de la interfaz gráfica. 3.2.6.2.Ventanas Las ventanas son recursos interactivos usados para la visualización, jerarquización y navegación de la información en un interfaz gráfico de usuario. A través de las ventanas, pueden ser visualizados un conjunto de documentos, aplicaciones e iconos, sobre los cuales es posible realizar diversas acciones. Las ventanas permiten una forma relativamente fácil de interacción con la información. Su comportamiento es como el de un objeto, y pueden ser abiertas, cerradas, movidas, escaladas, ampliadas (zoom) y navegadas (scrolling). Las ventanas fueron uno de los primeros recursos interactivos desarrollado en el contexto de la interfaz WIMP en el PARC. Constituye un marco, a través del cual es posible visualizar y manipular información del sistema. Han sido definidas dos tipos generales de ventanas. Las ventanas de aplicación y las ventanas de ficheros. Ambas atienden a una diferenciación semántica, esto es relacionado con el contenido de la ventana y no de la ventana en sí misma. Las ventanas de aplicación son aquellas que surgen para representar las variables de una aplicación concreta en el sistema. En el paradigma WIMP cada una de las aplicaciones se representa en un espacio delimitado por una ventana. Es una forma de establecer niveles jerárquicos dentro de la interfaz y de posibilitar la representación y manipulación independiente de aplicaciones. Las ventanas de ficheros son normalmente usadas por los gestores de archivos en el sistema y sirven para visualizar un conjunto de documentos, aplicaciones, iconos posibilitando diversas acciones sobre estos elementos.  Anatomía general de una ventana Las ventanas se han ido definiendo a lo largo del tiempo, de modo que al día de hoy, podríamos hablar de una anatomía de las ventanas, formada principalmente por cinco elementos básicos: Marco, cabecera de ventana, área de contenido, barra de scroll, y pie de ventana. El marco lo forman el conjunto de recursos gráficos que ayudan a marcar el límite visual entre la ventana y el resto del interfaz. Normalmente sobre ciertas partes del marco se posibilitan acciones de redimensionamiento de la ventana por parte del usuario. Ha variado estilísticamente y está sujeto a las modificaciones de customización por parte del usuario. La cabecera de ventana es un área dispuesta de forma horizontal que sirve para posicionar los iconos que representan y ejecutan acciones generales sobre la el comportamiento de la ventana. Actualmente han sido estandarizadas tres acciones básicas: maximizar, minimizar y cerrar. Hay una cuarta

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

103

aún no estandarizada pero que es usada por algún software, y consiste en ocultar la ventana, sin cerrar la aplicación, pero sin ser minimizada en la barra de tareas. El espacio de contenido está sujeto al tamaño de la ventana normalmente. Hay contenidos que se adaptan al contenido, y si el contenido de la información representada supera el tamaño de la ventana, entonces la ventana muestra la barra de scroll, que servirá para movernos por el contenido. La barra de scroll de las ventanas ha tenido varios posicionamientos a lo largo de la historia, pero actualmente los sistemas operativos más importantes la localizan en la vertical derecha, para mover el contenido en dirección vertical, y en lado horizontal inferior para posicionar el menú de scroll horizontal. Normalmente está formado por un conjunto de cuatro elementos. Dos flechas-botones situadas a los dos lados de la barra, y un elemento deslizador el cual puede ser arrastrado y actualmente muy usado en navegadores web. El pie de ventana es usado para visualizar información básica de la aplicación o del contenido de esa ventana.  Tipos de ventanas Podemos hacer una catalogación de ciertos tipos de ventanas, desde un punto de vista semántico, esto es, atendiendo al tipo de significados asociados a la ventana: Ventana Modal Las ventanas modales son aquellas ventanas específicas que han sido diseñadas como medio de prevención de alguna acción del usuario sobre el sistema. Surgen allí donde el sistema prevé algún error por parte del usuario. Suelen contener un mensaje de advertencia y un botón de confirmación de la acción a realizar. Ventana de Confirmación Las ventanas de confirmación son aquellas que surgen de modo preventivo igualmente, pero esta vez dan al usuario una serie de posibilidades de acción. La ventana de confirmación más habitual es aquella que surge cuando intentamos guardar un documento que ya tenemos creado en el sistema. Suelen contener el mensaje de advertencia, un icono indicando la gravedad del asunto, y una serie de botones donde se le pide al usuario una decisión al respecto. 3.2.6.3.Menús Los menús son listas de comandos, atributos, o cualquier tipo de elementos, agrupados de forma estructurada normalmente inscritos dentro de una barra de menús o de un área específica en la interfaz, los cuales pueden ser activados y posibilitan la ejecución de los ítems que contienen obteniendo una respuesta inmediata al respecto. Los ítems del menú normalmente constituyen descripciones textuales, aunque también incluye en ocasiones signos adicionales que dan información sobre la posibilidad de ser ejecutado (apagado-encendido), el estado del ítem (activado - desactivado) o el tipo o clase a la que pertenece siendo acompañada de un icono. Normalmente los menús sintetizan una estructura de elementos de forma jerárquica por niveles, representados de modo que se muestra una lista, tanto de forma horizontal como vertical de los elementos de un menú, y a continuación, se accede a cada uno de los subelementos de cada elemento del menú.  Estados de un Menú Los ítems de un menú suelen tener estados. Los estados son los posibles comportamientos que dispone un ítem del menú en relación a la interacción por parte del usuario. Los estados habituales de un ítem de un menú suelen ser: Activo: Es el estado normal de un ítem sin que el usuario interactúe con él, aunque debe mostrar claramente la posibilidad de poder hacerlo.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

104

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

105

Inactivo: El ítem muestra una apariencia difusa indicando que no puede ser seleccionado por el usuario en ese momento, pero que puede hacerlo bajo otras condiciones de selección de parámetros en el sistema. Seleccionado (rollover): Cuando el usuario ha posicionado o elegido esa opción, sin haberlo activado, el ítem suele cambiar de estado, normalmente indicando que está seleccionado en ese momento. Activado: El estado corresponde al momento en que el ítem seleccionado es activado, normalmente ocurre cuando el usuario indica que ha seleccionado cliqueando sobre él o pulsando una tecla que haga esta indicación al sistema (intro). Pulsado: Cuando el ítem ha sido activado con posterioridad. En una página web suele mostrar un color diferente para indicar que el ítem ha sido pulsado con anterioridad.  Tipos de Menús Existen varias tipologías de menús, según el contexto en el que se ubiquen, conteniendo una gramática particular y un objeto concreto dentro de la interacción con el usuario. Se comentan a continuación los tipos de menús más habituales en la interacción con ordenadores: Menús contextuales Menú contextual, es aquel que muestra una lista de ítems posible de ejecutar sobre un objeto concreto en el contexto definido. Un objeto o icono en el interfaz, puede tener varios estados y diferentes contextos. Los menús contextuales normalmente están ocultos, y son activados por el usuario sobre un objeto en concreto. Éste muestra las opciones que se pueden aplicar sobre el objeto en ese preciso momento. En el sistema Windows son activados con el botón derecho del ratón, y son representados de forma flotante al lado del objeto interrogado. Menús de navegación (scroll) Un menú de scroll, es un menú que combina en su interior la posibilidad de realizar movimientos de navegación sobre sus ítems. Cuando las opciones de un menú son demasiadas para mostrar de una sola vez en la interfaz, se usan diversos recursos de navegación con los ítems, uno de ellos es posicionar una barra en el interior del menú de modo que se pueda navegar usando la barra adecuada. No son muy habitables estos menús, Apple los usó en su sistema operativo y Windows lo usa en su menú de inicio cuando las aplicaciones instaladas son demasiadas para mostrar. Menús jerárquicos Un menú Jerárquico es un menú representado en forma de árbol, cuyos ítems de un mismo nivel, abren un nuevo menú con nuevas opciones correspondientes a un siguiente nivel. Son usados con frecuencia para sintetizar un árbol amplio de ítems, sin perder la jerarquía de su organización. Este menú es el usado por Windows en su menú de inicio. Menú de inicio Un menú de inicio es un tipo de menú jerárquico desarrollado inicialmente por Microsoft para Windows y actualmente implementado en las interfaces de los sistemas operativos GNU/ LINUX. Es un menú jerárquico que intenta recoger un acceso global a todas las variables y elementos y aplicaciones del sistema.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

106

Usabilidad en menús Actualmente, y debido a la repercusión tan fuerte que ha tenido el diseño de interfaces para páginas web, el elemento menú textual se ha convertido en uno de los elementos más usado para interaccionar con la documentación en línea. La usabilidad de los menús ha sido estudiada por psicólogos e ingenieros y se ha podido comprobar que los menús entrañan algunos problemas que vale la pena mencionar: • Por un lado los menús tienen problemas en relación a la visualización de la información ya que normalmente sólo es posible ver el primer nivel de la jerarquía del menú, pero no el resto de los ítems. • Una vez se ha accedido a sus opciones es necesario poder memorizarlas, ya que no están siempre visibles, por lo tanto ofrece problemas a gente que dispone de capacidades psicomotrices afectadas, como las personas llegadas a una cierta edad. Estas son algunas cuestiones básicas que invitan a diseñar menús de forma visible atendiendo a la mejor usabilidad por parte del usuario. 3.2.6.4.Íconos Los iconos en el contexto de las interfaces gráficas son signos esquemáticos que representan algún tipo de fichero, carpeta, aplicación, o dispositivos de un sistema informático. Los iconos, tal cual se ha defendido en la primera parte de este trabajo, son signos interactivos y por lo tanto inscritos en una gramática especial que debe ser aprendida por el usuario. Los iconos usados en el interfaz, provienen principalmente de la representación metafórica realizada en el PARC inscritos dentro de la metáfora del escritorio. A su vez éstos se inspiran en los signos desarrollados en la comunicación gráfica de las señales viales y demás signos codificados por la cultura occidental hasta hoy. Los iconos son importantes y uno de los elementos fundamentales en el desarrollo de las interfaces gráficas por varias razones:  Las personas reconocen iconos e imágenes más rápido de lo que tardarían en comprender el mismo concepto a través de la representación verbal. A ciertas distancias pueden ser mejor reconocidos que signos textuales.  Los iconos cruzan la barrera de la cultura de mejor modo que el lenguaje verbal. Existen algunos signos que tienen reconocimiento internacional.  Los iconos son capaces de trasmitir conceptos en menos espacio que en lo que lo describiría una palabra a través del lenguaje verbal. • El icono como imagen, tiene la capacidad de trasmitir información espacial, relacional, multivariable y representar objetos del mundo real. 3.2.6.5.Tipografía digital Un elemento no menos importante en la interacción con los ordenadores a través de las interfaces gráficas son los signos textuales. La tipografía digital podría constituir un trabajo de investigación en sí y constituye un campo relativamente reciente aún no excesivamente investigado. Las empresas que precisamente se lanzaron a investigar cuestiones relacionadas con la legibilidad en la pantalla, fueron Microsoft y Apple. Apple desarrolló las primeras fuentes exclusivas para la pantalla, de modo que fueran legibles en el entorno digital de su sistema operativo. Microsoft se ha preocupado por desarrollar su propio sistema de fuentes y ha encargado el diseño de ciertas fuentes específicas para la pantalla, también con la intención de mejorar la visualización de texto en sus sistemas operativos. Encargó al diseñador Matthew Carter una fuente tipográfica especialmente adaptada para pantalla, la fuente Verdana (1994). Uno de los tipos más usados actualmente en la world wide web. Uno de los principales problemas para la tipografía digital es la legibilidad en pantalla, ya que en este medio tiene una serie de limitaciones y particularidades que la afectan:  Por un lado la pantalla tiene límites de representación tecnológicos que afectan a la apreciación de los signos textuales. Esto hace que en la pantalla, los signos de palo seco ofrezcan normalmente más limpieza visual que los tipos con remate, por lo que la preferencia se decanta por tipos de palo seco.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

107

 Por otro lado existen problemas relacionados con la naturaleza del signo: el tipo en la pantalla está compuesto como signo luz, frente al tipo en papel constituido como signo materia. La legibilidad del tipo luz ofrece mayor dificultad sobre el ojo, ralentiza la lectura y dificulta la compresión. Todos estos elementos deberían ser tomados en cuenta por una persona que diseñe para el medio digital. Uno de los recursos textuales más trascendentes en la actualidad en sistemas digitales y especialmente para los sistemas de información en línea, es el hipertexto. El hipertexto es un tipo especial de texto, que contiene propiedades interactivas en el contexto de los sistemas digitales, con un funcionamiento muy similar al de un botón. Dispone también de su propia gramática. Su gramática por defecto corresponde a la adición de texto azul y subrayado sobre el signo textual para indicar que puede ser accionado sobre el mismo. Dispone de estados como cualquier otro recurso interactivo. La hipertextualidad supone el recurso interactivo de enorme trascendencia que está afectando e influyendo sobre las gramáticas desarrolladas en las interfaces gráficas de los sistemas operativos. 3.2.6.6.Controles Botones Un botón es un objeto de control sobre la interfaz que posibilita introducir un dato de confirmación al sistema. Actúa como metáfora visual y funcional de los botones incluidos en los dispositivos tecnológicos. Su gramática visual tiene ya un recorrido histórico con posibilidad de ser estudiada. Han sido catalogados varios tipos de botones en relación a sus formas: Botón en Relieve Es el más común y el más usado en los sistemas operativos. Imita la gramática visual de un botón de un dispositivo físico, por lo que se suele usar un tratamiento cuidado de los bordes, de modo que simule volumen. Suele incluir una descripción breve en el interior, y suele soportar diversos estados al igual que el comportamiento de las ventanas. Botones en forma de radio Son botones redondos que posibilitan ser señalados a través de la acción del usuario. Normalmente son usados en formularios o menús, para dar elección a elegir un ítem de una lista. El interfaz de Mac lo usó con frecuencia en su sistema operativo. Botones de confirmación (checkbox) Son botones similares a los botones de radio, pero con forma cuadrada. Se representan de forma hueca, y suelen ser usados para seleccionar ítems en una lista. Elementos de entrada de texto Los elementos de entrada de texto, nos indican en qué lugar del interfaz puede ser usado el teclado. Cuando todo el interfaz se convierte en escritorio, surgen las aplicaciones específicas que permiten introducir texto. Pero existen partes de ciertas aplicaciones que requieren un área que posibilite la introducción de información textual por parte del usuario. En este contexto es en el que los campos de texto cobran sentido. Campo de texto El campo de texto ha desarrollado también su propia gramática visual. Normalmente delimita un área en blanco, e indica a través del borde la posibilidad de introducir texto en la misma. 3.2.6.7.Elementos de información de salida

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

108

Los elementos de salida, tienen que ver con elementos que se han ido configurando para dar información de estado del sistema al usuario en un momento dado.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

109

Normalmente las aplicaciones reservan un área de la ventana, donde posicionan estos datos. Existen varios elementos de información de salida, que vale la pena mencionar: Barra de progreso La barra de progreso es un elemento que indica al usuario el progreso de la acción que realiza el sistema. Todas las acciones del sistema, no son realizadas de forma instantánea. Cuando el sistema requiere tiempo para realizar una acción, es fundamental dar feedback al usuario a través de la representación del proceso y por lo tanto del progreso de la acción. Cuadro de consejo [tip box] Es un recurso gráfico inspirado en los bocadillos de los cómics, que surge en ciertos elementos de la interfaz para indicar información adicional sobre algún elemento u acción del usuario sobre el sistema. Barra de estado [Status Bar] La barra de estado ofrece información variada al usuario sobre diferentes variables de la aplicación o del sistema. Normalmente es posicionada en la parte inferior de la ventana de aplicación. Suele estar divida en varias áreas de modo que en una misma horizontal se muestran varios campos con diferentes informaciones. Suelen ofrecer información técnica específica, muy útil cuando el usuario la necesita. 3.2.6.8. Elementos Compuestos Barra de tareas La barra de tareas es un elemento bien definido en sistemas operativos Windows, que posteriormente han sido implementados en sistemas Unix a través de sus respectivos entornos gráficos. Consisten en una barra dispuesta de forma horizontal, en la que se posicionan diversos elementos interactivos, normalmente iconos, que activan aplicaciones y sirve además para ir añadiendo y alojando aplicaciones útiles para el usuario. Suelen estar dividido cuanto menos en cuatro partes: o Botón de Inicio: Sirve para activar el menú de inicio y poder acceder a sus funciones. o Área de aplicaciones más usadas: Muestra de forma sintética iconos de las aplicaciones más usadas en el sistema como puedan ser el escritorio y el navegador de internet o navegador de archivos. o Área de descanso: En un principio desocupada, es la parte de la barra de tareas destinada a disponer los elementos minimizados cuando el usuario ejecuta más de una tarea en el sistema. o Área de aplicaciones del sistema: Muestra de forma sintética, a través de iconos, diferentes aplicaciones relacionadas con cuestiones técnicas del sistema que operan en el momento de su ejecución. Combo de texto (combo box) El combo de texto, es un elemento formado en un estado inicial por un campo de texto y una pestaña. El usuario puede introducir texto sobre el campo, pero si pulsa la pestaña despliega una ventana completa con elementos de navegación incluida. Es un elemento combinado que dispone de varias posibilidades de interacción y de acceso a la información introducida.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

3.3.

ESPECIFICACIÓN DE CASO DE USO

3.3.1.

Importancia de las Especificaciones de caso de uso

110

En mayor o menor medida, todos conocemos lo que es un caso de uso y para que se utiliza. Muchos profesionales ven la tarea de definir casos de uso como algo tedioso y aburrido que al final, no vale para nada. Redactar la especificación de casos de uso es tarea fundamental a la hora de defender nuestros proyectos y legitimar los cambios a los mismos. El objetivo primario y fundamental de la definición de la especificación de casos de uso es el de cerrar la funcionalidad y el diseño de una aplicación con el suficiente detalle como para crear un marco de trabajo donde vayamos desarrollando y cerrando casos de uso o escenarios, y el cliente vaya revisándolos y enviando observaciones si encuentra algún tipo de bug o error en el comportamiento de la aplicación. La especificación de casos de uso ha de servir como guía tanto al desarrollo como al testeo de la aplicación. Nosotros escribiremos código que cumpla con las especificaciones de los casos de uso o escenarios y el cliente deberá de ejecutar esos casos de uso o escenarios y comprobar que la aplicación se comporta como se espera y sin errores según el enunciado del mismo. Si no disponemos de un documento guía validado por el cliente en el que apoyarnos,

3.3.2.

Consejos para escribir buenos casos de uso

Escribir un buen caso de uso no es fácil, a continuación se detallaran principios y conceptos que ayudaran a redactarlos adecuadamente, estos conceptos forman un fundamento de mejores prácticas probadas para escribir casos de uso.

Entendiendo qué es un Caso de Uso (y qué no lo es) Los Casos de Uso se han vuelto muy populares para establecer el esquema de la lógica de negocios del desarrollo de proyectos. Esta popularidad, desafortunadamente, puede resultar también en confusión y en variedad de opiniones respecto a qué son y a cómo deberían ser estructurados y escritos. Sin un estilo estándar y sin el establecimiento de pautas para escribir casos de uso, los escritores de casos de uso dentro de su organización escribirán los casos de uso a su manera, posiblemente confundiendo a los lectores y haciendo peligrar los proyectos así como también al resultado deseado de una solución de calidad que provea valor de negocio inmediato. Los casos de uso son parte del Estándar Del Lenguaje Unificado de Modelado del Grupo de Gestión de Objetos (OMG). Este estándar nos dice qué significan las partes de los diagramas de casos de uso, las figuras de palos (monitos), óvalos y líneas, y nos da una definición de un caso de uso. Pero no nos dice cómo estructurarlos o escribirlos. Por lo que debemos leer libros, para tratar de imaginarnos la forma correcta. Así que, ¿cuál es la forma correcta?, La mejor forma es la que funcione mejor para ti, sin salirse mucho de la definición de lo que es un caso de uso: Un caso de uso es una especificación de una serie de acciones realizadas por un sistema, el cual produce un resultado observable que es, típicamente, de valor para uno o más actores u otros grupos de interés dentro del sistema (UML 2) Una definición menos formal podría ser la siguiente: Un caso de uso es una lista de pasos que especifican como un usuario interactúa con el negocio o sistema, teniendo en cuenta el valor que esta interacción le da al usuario o a otros grupos de interés.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

111

Aún más simple: Un Caso de uso es la historia de cómo un negocio o un sistema interactúa con el usuario Un caso de uso no debe ser confundido con la historia de un usuario, por ejemplo un requerimiento del sistema de software formulado en una o dos frases en el lenguaje cotidiano del usuario. Los casos de uso son requerimientos formales con contexto y estructura que definen claramente el valor resultante. Esto aún deja a los escritores de casos de uso un gran trabajo, descubrir realmente la mejor manera de escribir casos de uso, dada la significante ambigüedad incorporada en la definición. El objetivo de este manual es ayudarle a tomar las decisiones correctas para que pueda realizar de forma exitosa ese trabajo. Los Casos de uso son requerimientos de software que especifican funcionalidad Las personas a menudo hablan de requerimientos y de casos de uso, implicando que son cosas diferentes. Los casos de uso son simplemente un método diferente para organizar los requerimientos funcionales, ellos aún son requerimientos. Tradicionalmente, los requerimientos capturan la funcionalidad de un sistema usando una larga lista de declaraciones “deberá”, muchas veces cercanas a las miles. El objetivo de crear un caso de uso es transformar estas declaraciones “deberá” en pequeños grupos que provean valores y contextos observables, organizados desde una perspectiva del usuario. Los casos de uso se refieren a comportamientos (al menos las salidas) que son observables por el usuario. Existen otro tipo de requerimientos aparte de los funcionales, usualmente llamados no funcionales o requerimientos suplementarios. Estos requerimientos son normalmente especificados como declaraciones “deberá”, pero ellos contienen información diferente a la que están en los casos de uso. Ellos describen las calidades necesarias del sistema: cuán rápido debe ser, cuan confiable debería ser, cuan seguro debe ser y otra cualidades. Los casos de uso necesitan describir los que el sistema “debería” hacer. Ellos deberían expresar los pasos interactivos que un usuario debería tomar para obtener un resultado valorable. Un caso de uso describe funcionalidad pero también debe describir un resultado. Esto es lo más importante, y está mencionado en la primera definición que los casos de uso dan “Valor a uno o más actores o grupos de interés del sistema”. Uno de los problemas observados más comunes en organizaciones que están recién comenzando con casos de uso es que ellos no entienden esta focalización en el valor. Y, como resultado, terminan escribiendo casos de uso más pequeños que no incrementan a la historia total. Ellos no se centra en las interacciones que conducen valor y que son de interés para los actores involucrados en los casos de uso. Este acercamiento puede ser visto usualmente en la fase de pruebas de un proyecto. Si los casos de prueba están basados en casos de uso que reflejan unidades de prueba, en vez de pruebas de aceptación del usuario, probablemente existan muchos y sean de un nivel muy bajo. Como ejemplo, un cliente con el que IBM se ha involucrado, tenía alrededor de 10 personas trabajando en un proyecto que estaba programado para durar alrededor de un año. Inicialmente, la organización tenía aproximadamente 150 casos de uso, porque había una falta de entendimiento de su propósito. Después de una examinación más profunda, se determinó que muchos de sus casos de uso eran realmente especificaciones de diseño, no requerimientos, y otros estaban centrados en interacciones tan pequeñas que nos mostraban ningún valor al actor o al grupo de interés. Se tuvo que realizar un esfuerzo para tomar un paso atrás y centrarse en revisar sus casos de uso. Después de remover los casos inapropiados y combinando otros, el cliente terminó con menos de 10 casos de uso, cada uno centrado partes complementarias o comprensibles de la visión general, y mostrando valores significantes para cada actor o grupo de interés. Para este cliente, fue un momento de “ajá” cuando los desarrolladores de la compañía vieron como este nuevo, gran, y más

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

112

completo caso de uso, serían más fácil de usar y de un gran uso para el diseño, desarrollo y prueba del sistema. Consejo: No olvide el Diagrama Los casos de uso son representados gráficamente como óvalos en los diagramas de casos de uso, y estos son también expresados como especificaciones textuales (ver Figuras 1 y 2). El texto es definitivamente la esencia del modelo de caso de uso, y ciertamente puede beneficiarse de escribir el texto sin dibujar el diagrama. Sin embargo, el diagrama puede ayudar a comunicar los requerimientos a un alto nivel. También ayuda a los grupos de interés a ver qué está dentro del alcance y qué esta fuera. Los actores están fuera del sistema que está siendo desarrollado, y los casos de uso están dentro. Esto es especialmente importante para el diagrama de reconocimiento de los casos de uso, el cual muestra a todos los actores y a los casos de uso en un solo diagrama. Consejo: Los actores humanos son el elemento más importante Las figuras de palo utilizadas en los diagramas de caso de uso son aludidos como los actores. Ellos indican cualquier persona (o rol), otro sistema o quizás inclusive un dispositivo fuera del sistema que se está construyendo y que interactúa con él. Es el actor humano el que representa las interacciones más interesantes y difíciles para la mayoría de los sistemas, y las interacciones humano/sistema son donde el verdadero valor de los casos de uso viene a la perspectiva. La funcionalidad puesta en un caso de uso ayudará a los actores a realizar su trabajo o tarea mejor- en una forma significativa. A menos que el sistema que esté diseñando tenga una fuerte dependencia en otros sistemas o dispositivos, su tiempo y esfuerzo es mucho mejor que los utilice en orientarse a las necesidades de los actores humanos. Consejo: Vaya con la corriente Buenos casos de uso no son sólo párrafos de texto claro y conciso. Ellos poseen una estructura que definen como las partes de un caso de uso calzan juntas. Y ellos pueden ser estructurados en muchas formas- referidos como un estilo de casos de uso. Una técnica estructural común al crear casos de uso es tener una larga lista de pasos de principio a fin. Este acercamiento puede causar problemas, ya que existen comportamientos condicionales y/o procesos de error que se benefician de la modularización – rompiendo cada pieza lógica para una parte específica de un caso de uso. Modularizar facilita escribir y leer, pero sólo si las piezas calzan juntas para describir la imagen completa. Un caso de uso debería tener un único flujo principal y múltiples flujos alternativos. El flujo principal explica que sucede cuando todo sucede de forma correcta y el caso de uso cumple con su objetivo. Esto es llamado a veces el escenario del “camino feliz”, y ocurre la mayor parte del tiempo. A veces los escritores de casos de uso tratan de tener múltiples flujos principales, pero esto puede diluir el entendimiento del caso de uso ya que hace más difícil al lector el trabajo de entender el objetivo real. Consejo: Colocar referencias en los flujos alternativos, no en los flujos principales El flujo principal muestra que sucede cuando todo en el caso de uso sucede de la forma correcta, y el usuario alcanza su objetivo. Incluye una serie de pasos (eventos) ordenados en orden cronológico que explican los que el sistema hace y lo que el actor realiza para llevar a cabo el caso de uso. Las referencias son simples sentencias sobre donde inicia un flujo y como y donde termina. Es recomendado que no utilice referencias en el flujo principal, que podrían llevar al usuario a un flujo alternativo o a otro caso de uso si una condición específica ocurre. Centrarse en el “camino feliz” mantiene el flujo simple y fácil de leer, y comunica

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

113

claramente qué sucede cuando el caso de uso ha sido exitoso. Algunos estilos de casos de uso utilizan referencias en el flujo principal, los que usualmente se muestran como sentencias “if –then” y como ramas de muchos otros lugares en el caso de uso o fuera de él. Pero esta técnica puede resultar confusa, y es recomendado que todas las referencias ocurran en flujos alternativos. Los flujos alternativos contienen las referencias (los flujos alternativos explican que sucede cuando ocurren errores o cuando ocurren resultados esperados, sin embargo ellos no son tan importantes como el flujo principal). Aquí es cuando aparece la importancia de las referencias. Cada flujo alternativo comienza en algún otro lugar dentro del caso de uso. Puede ramificarse en alguno de los pasos del flujo principal o extenderse desde otro flujo alternativo. Y cuando un flujo alternativo termina, el caso de uso usualmente continuará en algún otro lado. Los flujos alternativos explican que causó su inicio y que es lo que el sistema hace en respuesta al flujo alternativo. Los flujos alternativos no sólo contienen las referencias de donde comenzaron y donde se reanudan, ellos también dicen que causó su inicio y qué es lo que el sistema hace en respuesta. Mirando río abajo en el proceso de desarrollo, esta información va a ser útil cuando se escriban los casos de prueba. Consejo: Los escenarios cuentan la historia completa Los actores no pueden ejecutar flujos alternativos, pero pueden ejecutar escenarios. El concepto de escenario puede ser confuso porque las personas definen los escenarios de maneras muy distintas. En IBM, nosotros los definimos simplemente como los caminos a través de un caso de uso o como una serie de pasos y flujos que un actor podría tomar – de inicio a fin- a través de un caso de uso para proveer un resultado. Dados los muchos flujos alternativos posibles, habrá muchos escenarios, con muchos resultados –ambos, positivos y negativos-. El proceso de avanzar a través de los escenarios e identificar estos resultados negativos, brindan grandes plataformas para conversaciones de los grupos de interés, mientras los equipos tratan de satisfacer los requerimientos del negocio a través de todos los posibles escenarios. Tenga en mente que una completa serie de escenarios cuentan la historia completa de un caso de uso. Es esta completa serie de escenarios lo que será utilizado por los diseñadores y “testeadores”, como la base de su trabajo. Consejo: Sea cuidadoso con las sentencias “if” Los profesionales de las Tecnologías de Información (TI), particularmente aquellos con experiencia en programación, están familiarizados con las sentencias “if”, y por lo general puede observar dichas sentencias usadas en casos de uso. Un “if” en lenguajes de programación especifican comportamientos condicionales, y eso usualmente es verdad en los casos de uso también. Los problemas surgen cuando existen uno o más “if” en un flujo, ya que usualmente significa que se están especificando múltiples requerimientos. Esto puede resultar negativo para la legibilidad - puede resultar difícil seguir un flujo de múltiples sentencias “if” a través del texto. También resulta negativo para el diseño y prueba del sistema. Es mejor, tanto para el lector, como para el proyecto, que rompa cada “if” en su propio flujo. Se obtienen más flujos, pero el cambio vale la pena. Consejo: Especificar elecciones (opciones) del actor Los actores generalmente realizan elecciones en los casos de uso. Considere el ejemplo de un sistema de registro de una universidad siendo definido en caso de uso “Registro para cursos”. En este ejemplo, un flujo principal podría ser: 1) Crear un horario, 2) modificar un horario y 3) Eliminar un horario. A menudo los escritores de casos de uso tratarán de usar sentencias “if” para mostrar al actor tomar una elección, pero por razones indicadas anteriormente, está podría no ser la mejor idea. Una mejor alternativa es tener todas las elecciones (opciones) del actor listadas en el punto apropiado, y tener una opción seleccionada y asignada al flujo actual y las otras

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

114

repartirlas en flujos alternativos. Esta técnica mantiene cada flujo simple y reduce las ramificaciones.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

115

Consejo: Aleja el CRUD A menudo vemos a escritores dirigir las opciones del actor creando casos de uso separados para cada opción. Es una solución tentadora pero a la vez peligrosa. El peligro es la necesidad de manejar la complejidad exponencial que a menudo se crea, resultando en comportamientos repetitivos innecesarios, y, a la larga, casos de uso con valor mínimo. En vez de eso, trate de centrarse en lo que el actor realmente quiere hacer, lo que generalmente no tiene relación con las acciones de Crear, Leer, Actualizar y Borrar (CRUD). En nuestro ejemplo del sistema de registro de la universidad, hay opciones para 1) Crear un Horario, 2) Modificar un Horario y 3) Borrar un Horario. Todas están en el caso de uso “registro para cursos” porque al estudiante realmente no le interesa crear o modificar horarios, el estudiante sólo quiere registrarse. Tomando el camino fácil y listando todas las actividades CRUD, da como resultado 3 hasta 4 veces más casos de usos de los necesarios, y puede fácilmente hacer el proceso más complicado y difícil de manejar. Consejo: La secuencia de los eventos puede ser opcional Hemos dicho que los pasos en los casos de uso, usualmente están ordenado cronológicamente, pero se debe considerar si el orden de los pasos es un requerimiento. Por ejemplo, ¿El actor tiene que haber completado el paso cuatro antes de completar el paso cinco?, generalmente la respuesta sería SI, pero no siempre. Es una cosa muy simple, al desarrollar el texto de un caso de uso, para aclarar cualquier restricción temporal, agregue comentarios como este “Este paso pude ocurrir en cualquier orden” o “Este paso puede ocurrir en cualquier momento antes que este paso” a una línea. El punto es, usted no quiere restringir a los diseñadores del sistema teniendo requerimientos temporales implícitos cuando no son realmente necesarios. Consejo: Utilice el nivel correcto de detalle Una de las preguntas más comunes es “¿Cuánto detalle debe haber en un caso de uso?” Recuerde, los casos de uso son requerimientos. No son documentos de diseño, y ciertamente no son diseños de interfaz de usuario. Uno nunca debería referencias elementos de la interfaz de usuario, tales como página principal, pantalla de ingreso o “clickear” botones en un caso de uso. De manera similar, los detalles arquitectónicos deben ser evitados. Por ejemplo, en el modelo de registro de cursos, una sentencia como “el horario es guardado en la base de datos SQL Server” no debería ir en un caso de uso. La parte de guardar el horario es apropiada, pero dónde se almacena es un detalle de arquitectura, que podría ser modificado después si el administrador de la base de datos decide que el horario debería ser guardado en una base de datos diferente. Consejo: Póngase en los zapatos del actor Los casos de uso son diferentes con respecto al uso de sentencia “deberá”. Dado que ellos especifican pasos ordenados cronológicamente, ellos crean más contexto que las autónomas sentencias “deberá”, las cuales no son temporales. Es por esto que ellos son más reflexivos para la experiencia de los usuarios planeados. Tenga esto en mente. Si los casos de uso son requerimientos (y lo son), los diseñadores y desarrolladores estarán restringidos por lo que ellos dicen. Recuerde esto, sienta pena por el actor y escriba sus casos de uso de una forma que haga que el sistema sea lo más simple posible para el usuario. Conclusión Cuando se escribe bien y con un acercamiento consistente, los casos de uso pueden ser una gran manera de especificar los requerimientos de una forma que sea entendible por los usuarios y los grupos de interés, y a la vez, directamente usables

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

116

por el equipo de desarrollo. Pero la calidad y consistencia sólo puede ser alcanzada si existe un acuerdo en la estructura del caso de uso y los procesos. Por lo que aquí está el consejo final: Documente las decisiones que usted y su organización realicen sobre cómo realizar buenos casos de uso. Cree una guía de estilos para caso de uso o una presentación, dar a los escritores muchos ejemplos de buenos casos de uso y respete las guías establecidas. Como todo el esfuerzo puesto en un caso de uso resultará (esperadamente) en un exitoso desarrollo del proyecto, el esfuerzo puesto en establecer prácticas estándares y en seguir estos consejos, resultará en mejores casos de uso que serán valorados por todos los involucrados en el proceso. 3.3.3.

Detallar la especificaciones de casos de uso

No existe estándar UML para una especificación de caso de uso. Sin embargo, una plantilla para una especificación sencilla de caso de uso utilizada comúnmente contiene la siguiente información:  Nombre del caso de uso  Breve descripción  Actores implicados en el caso de uso  Flujo de eventos. Incluye el flujo básico, sub flujos y flujos alternativos  Precondiciones  Poscondiciones  Puntos de extensión  Requisitos especiales  Prototipos A continuación se detalla cómo se debe de registrar la Especificación de caso de Uso:

Nombre del caso de uso El nombre del caso de uso debe empezar con un verbo en infinitivo que plasme la funcionalidad del caso de uso. Veamos algunos casos:  Para el mantenimiento de datos maestros, los cuales poseen subflujos como: Agregar, Modificar, Eliminar, etc. Mantener <Nombre de la información que mantiene> Por ejemplo: “Mantener Productos”, “Mantener Cliente”. 

Para el tratamiento de documentos legales, formales o de transacciones. Para tener el control adecuado de los perfiles de los usuarios y niveles de seguridad se suelen crear varios casos de uso que manipulan este tipo de documento. En caso de agregar: Registrar/Generar <Nombre del documento formal> Por ejemplo: “Generar Factura”, “Generar Contrato”. En caso de modificar o eliminar dependerá del documento y de cómo es tratado en la organización. Por ejemplo: Para eliminar una factura se crearía el caso de uso “Anular Facturar” que registra el motivo de la anulación y que cambia el estado de la factura a anulada y para modificar una factura se creará el caso de uso “Generar Nota de Crédito”, ya que legalmente una factura no se puede modificar sin un documento que sustente el cambio.



Para el tratamiento de la búsqueda de información. Buscar/Consultar <Información a buscar> Por ejemplo: “Buscar Productos”, “Consultar Clientes”.

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

117



Para el tratamiento de la verificación de la información, la cual retorna un valor de verdadero o falso dependiendo de si encontró o no la información. Verificar/Validar <información a verificar> Por ejemplo: “Verificar Existencia de Producto”, “Validar Existencia de Usuario”.



Para el tratamiento de documentos informales o de uso interno, el cual incluye las opciones de mantenimiento en un sólo caso de uso. Gestionar/Administrar <Nombre del documento informal> Por ejemplo: “Administrar Cotización”, “Gestionar Nota de Pedido”. Es necesario aclarar que si uno de los documentos informales originó un documento formal ya no se puede modificar o anular. Por ejemplo, una cotización que se aprueba y genera una factura ya no podría modificarse o anularse.

Breve descripción Debería ser un solo párrafo que resuma el objetivo del caso de uso.

Actores

Desde el punto de vista de un caso de uso específico, existen dos tipos de actores:  Actores primarios o principales: Activan el caso de uso.  Actores secundarios: Interactúan con el caso de uso después de haberse activado.

Flujo de eventos

Es una secuencia enumerada de pasos que describe la interacción del actor con el caso de uso. Incluye: Flujo básico, subflujos y flujos alternativos. Flujo básico Es el flujo principal del caso de uso y presenta las siguientes reglas: a) El primer paso Empieza por el actor primario haciendo algo para activar el caso de uso. Así: 1. El Caso de uso se inicia cuando <actor> <función> Por ejemplo: 1. El Caso de uso se inicia cuando la Recepcionista selecciona la opción “Generar Reserva” en la interfaz del menú principal. Si el tiempo es el actor, se empieza así: 1. El Caso de uso se inicia cuando es el fin de semana. Si el caso de uso es abstracto, comienza así: 1. El Caso de Uso se inicia cuando es invocado por otro caso de uso base. b) Centrase en el qué, no en el cómo Mantenga los detalles de diseño fuera del caso de uso. Por ejemplo, el siguiente paso es incorrecto. 5. El Cliente pulsa el botón Aceptar. La mejor forma de expresar ese paso es la siguiente: 4. El Cliente selecciona “Aceptar Pedido”. c)

Referencia a un caso de uso incluido

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

118

Para especificar la invocación a un caso de uso incluido se utiliza la siguiente expresión: El sistema Incluye el CU Buscar Habitación. Por ejemplo: 7. 8.

La recepcionista solicita “Buscar Habitaciones” disponibles. El sistema Incluye el CU Buscar Habitación.

d) Ramificación dentro de un flujo Para indicar una ramificación en el flujo se utiliza la palabra Si. La condición sujeta puede llevar a un conjunto de sub-acciones (desviaciones simples) o a un subflujo (desviaciones complejas). El siguiente ejemplo utiliza ramificaciones. 5. Si la Recepcionista elige un cliente a. Si selecciona “Modificar” ver el Subflujo Modificar Cliente b. Si selecciona “Eliminar” ver el Subflujo Eliminar Cliente. e) Repetición dentro de un flujo Para indicar la repetición de un conjunto de acciones se utiliza al final de la acción la siguiente expresión: Si <actor> <función>, repite los pasos del <X1> al <X2>. Por ejemplo: ... 7. La recepcionista solicita “Buscar Habitaciones” disponibles. 8. El sistema Incluye el CU Buscar Habitación. 9. El sistema muestra las habitaciones disponibles. 10. La Recepcionista ingresa la cantidad de personas para la habitación seleccionada. 11. El sistema valida la cantidad de personas ingresada. 12. El sistema calcula y muestra el subtotal del precio a pagar y el monto total. 13. Si la Recepcionista quiere seleccionar otra habitación, repite los pasos del 7 al 12. ... Subflujos Es opcional en un caso de uso. Pueden presentarse varios subflujos y cada uno de ellos sigue las mismas reglas del flujo básico. Flujos alternativos Son rutas de acceso alternativas a través del caso de uso que capturan errores, ramificaciones e interrupciones en el flujo principal. En la figura 11.1 se ilustran los caminos posibles de una instancia de caso de uso (escenario).

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

119

11.1. Caminos del Flujo de eventos. A continuación se muestra dos flujos alternativos para el caso de uso “Generar Orden de Reparación”. <Automóvil no Registrado> En el punto 8, si el sistema verifica que el Automóvil no está registrado muestra el MSG “Automóvil no registrado”, la Secretaria puede ir a “Registrar Automóvil” y continuar con el paso 9. <Cancelar> Si la Secretaria solicita “Cancelar” antes de Grabar la Orden de Reparación, el sistema cierra la interfaz y el caso de uso finaliza.

Precondiciones Las precondiciones restringen el estado del sistema antes de que el caso de uso pueda empezar. Si un caso de uso no tiene ninguna precondición se debería escribir “Ninguna”. Por ejemplo: 1. 2. 3.

El Recepcionista está logeado en el sistema. Lista de Clientes disponibles. Lista de Habitaciones disponibles.

Poscondiciones Las poscondiciones restringen el estado del sistema después de que el caso de uso se ha ejecutado. Si un caso de uso no tiene ninguna poscondición se debería escribir “Ninguna”. Por ejemplo: 4. 5.

En el sistema queda registrado la reserva con su detalle. Las habitaciones seleccionadas se actualizan al “Reservadas”.

estado

Puntos de extensión Se utiliza para hacer referencia a un caso de uso extendido. Pueden existir varios puntos de extensión. Por ejemplo: En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo básico “Agregar Cliente”.

Requisitos especiales En esta sección se especifican los requisitos no funcionales asociados a este caso de uso. A continuación se muestra un requerimiento físico para el caso de uso “Generar Factura”: Contar con Formato especial para imprimir las facturas, con el Logo de la empresa.

Prototipos En esta sección se muestran las interfaces gráficas de usuario diseñadas para el caso de uso. No es relevante mostrar las interfaces de los mensajes de advertencias o error.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

120

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

121

Ejemplo de especificación de casos de uso

Especificación de caso de uso: Generar Reserva de Habitación 1. Breve Descripción El caso de uso permite a la Recepcionista de un Hotel generar una reserva de habitación(es).Además de saber en qué estado se encuentra la habitación: reservado, ocupado o disponible. 2. Actor(es) Recepcionista 3. Flujo de Eventos 3.1. Flujo Básico 1. El Caso de uso se inicia cuando la Recepcionista selecciona la opción “Generar Reserva” en la interfaz del menú principal. 2. El sistema muestra la interfase RESERVA con los siguientes datos: Datos del cliente: Código y Nombres y Apellidos. Datos de la Reserva: fecha de la reserva y cantidad de días a hospedarse. Datos de las habitaciones: Número de habitación, Tipo, Categoría, capacidad, monto por día, Sub Total y Monto Total. Además incluye las opciones: Buscar Cliente, Buscar Habitaciones, Agregar, Eliminar, Grabar Reserva y Salir. 3. La Recepcionista selecciona “Buscar Cliente”. 4. El sistema Incluye el CU Buscar Cliente. 5. El sistema muestra los datos del cliente. 6. La recepcionista ingresa la fecha de reserva y cantidad de días. 7. La recepcionista solicita “Buscar Habitaciones” disponibles. 8. El sistema Incluye el CU Buscar Habitación. 9. El sistema muestra datos de habitación disponible. 10. La Recepcionista ingresa la cantidad de personas para la habitación seleccionada y selecciona Agregar. 11. El sistema valida la cantidad de personas ingresada. 12. El sistema calcula y muestra subtotal y monto total a pagar. 13. Si la Recepcionista quiere seleccionar otra habitación, se repite del paso 7 al 12. 14. La Recepcionista selecciona “Grabar Reserva”. 15. El sistema autogenera un número de reserva, graba la reserva con su detalle y actualiza la(s) habitación(es) en estado “Reservado”. 16. El sistema muestra el número de reserva y el MSG “Reserva generada con el Nro. 99999”. 17. La Recepcionista cierra la interfaz RESERVA y regresa a la interfaz del menú principal del sistema y finaliza el caso de uso. 3.2. Subflujos Ninguno. 3.3. Flujos Alternativos <Cliente no existe> En el paso 5, si el sistema detecta que el cliente no existe muestra el MSG: “Cliente no existe” y ofrecerá la posibilidad de registrar al nuevo cliente. <Habitaciones no disponibles>

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

122

En el paso 9, si el sistema detecta que no hay habitaciones disponibles muestra el MSG: “No hay habitaciones disponibles” y finaliza el caso de uso. <Cantidad de Personas incorrecta> En el paso 12, si la Recepcionista ingresó una cantidad mayor a la capacidad de la habitación seleccionada, el sistema muestra el MSG “Ingrese una cantidad de personas menor o igual a la capacidad de la habitación” y continúa con el paso 10. <Eliminar habitación> Si la Recepcionista solicita “Eliminar” una habitación seleccionada, antes de Grabar, el sistema lo borra del detalle y el caso de uso continúa en el paso 13. 4. Precondiciones 4.1. El Recepcionista está logueado en el sistema. 4.2. Lista de Clientes disponibles. 4.3. Lista de habitaciones disponibles. 5. Poscondiciones 5.1. En el sistema queda registrado la reserva con su detalle. 5.2. Las habitaciones seleccionadas se actualizan en estado “Reservadas”. 6. Puntos de Extensión En el paso 5, el sistema extiende al caso de uso Mantener Clientes – Flujo básico “Agregar Cliente. 7. Requisitos Especiales Ninguno. 8. Prototipos

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

CIBERTEC

123

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

124

3.3.4. Errores comunes en las especificaciones de requisitos usando casos de Uso Durante toda la etapa de identificación de requisitos se producen y generan errores. A continuación se incluyen algunos de los más frecuentes. Errores en la identificación de actores Los errores introducidos en esta etapa se deben principalmente a no comprender quienes son los actores del sistema. En algunos casos se incluyen actores que realmente no lo son; por ejemplo, en un sistema en el que se realizan pedidos de productos, se considera al cliente como un actor Realmente quien ingresa los pedidos en el sistema es el vendedor y no el cliente, por lo tanto el vendedor serıa el actor del sistema.

Errores en la identificación de casos de uso Un error muy extendido, y que es cometido en la mayoría de la bibliografía sobre casos de uso, es considerar las opciones del menú o funciones del sistema como casos de uso (puede revisar el libro de Larman [6] y podrá encontrar este tipo de errores). Kurt Bittner señala que los casos de uso deben mostrar lo que el usuario necesita del sistema y no mostrar las funciones u opciones del menú que permitirán realizar lo solicitado; por ejemplo, en un sistema donde se debe almacenar la información de los clientes, lo que al usuario le importa es actualizar la información de clientes. Esta actividad la podrá realizar accediendo a las opciones del menú agregar, modificar y eliminar clientes; por lo tanto la funcionalidad del sistema será representada con el caso de uso ”Actualizar cliente” o “Mantener Cliente”

Errores en la especificación de los casos de uso. La técnica de casos de uso se debe utilizar para la especificación de requisitos del sistema, mas no para el diseño del sistema. Los errores que se producen en esta actividad se deben a la inclusión de cuestiones de diseño en la especificación de casos de uso. Algunos de los errores que se cometen son los siguientes:  Introducir palabras que se refieran a componentes de ventanas como: botones, listas desplegables, opciones de menú, etc. En la especificación de casos de uso debe incluirse la información que será ingresada o será mostrada, pero no que componente de la ventana se va a utilizar para mostrar dicha información, sino se

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II



 

125

estaría realizando el diseño o de pantallas en el proceso de especificación de requisitos, lo cual serıa incorrecto. Mencionar elementos correspondientes al diseño de algoritmos o de base de datos en la especificación de casos de uso; por ejemplo, ”grabar en la tabla clientes en la base de datos„ u ” ordena los datos con el algoritmo de la burbuja„ son oraciones que no deben incluirse en una especificación; ya que son elementos que se determinan en la etapa de diseño. Otro error es incluir “etc.” o “así sucesivamente”, cuando se indica la información que se debe ingresar o mostrar. La especificación de casos de uso debe contener información exacta y precisa que permita realizar una buena estimación del esfuerzo requerido para realizar las etapas de análisis, diseño y codificación n. Si la información n no es exacta, se pueden producir retrasos debido a modificaciones de la base de datos, cambios en el diseño de las pantallas o en el código fuente producto de las especificaciones tardías de requisitos.

Errores en el uso de las relaciones entre casos de uso. Los errores que se producen al incluir relaciones entre los casos de uso se deben principalmente a confundir los casos de uso con los procesos de los diagramas de flujo de datos (DFD) de Yourdon. Es por eso que se ven diagramas de casos de uso que parecen DFDs, de manera similar al diagrama que se muestra a continuación. Para evitar cometer este error, se aconseja que no haya más de dos niveles de relaciones de tipo ” include„ o ” extend„ en un diagrama de casos de uso.

Se puede encontrar bibliografía en la que se emplea la relación ” use„ entre casos de uso. Se debe tener en cuenta que dicha relación corresponde a versiones anteriores a UML versión 1.3, por lo que su utilización debe evitarse

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

ANÁLISIS Y DISEÑO DE SISTEMAS II

126

Actividades propuestas  Redactar adecuadamente 1 especificación de casos de uso, siguiendo las recomendaciones y su prototipo

CARRERA DE ADMINISTRACIÓN Y SISTEMAS

CIBERTEC

ANÁ LISIS Y DISE ÑO DE SISTE MAS II

127

Resumen 1.

Los prototipos son una visión preliminar del sistema futuro que se implantara. La elaboración de prototipos de un sistema de información es una técnica valiosa para la recopilación rápida de información específica a cerca de los requerimientos de información de los usuarios.

Siempre se debe de tener una plantilla de especificación de casos de uso.

Durante toda la etapa de identificación de requisitos se producen y generan errores, tales como: Errores en la identificación de actores Errores en la identificación de casos de uso Errores en la especificación de los casos de uso. Errores en el uso de las relaciones entre casos de uso.

a. b. c. d.

CIBERTEC

CARRERA DE ADMINISTRACIÓN Y SISTEMAS