Changing the way you learn

COMPRENSIÓN DE LOS REQUERIMIENTOS

5.1 INGENIERÍA DE REQUERIMIENTOS
1. El espectro amplio de tareas y técnicas que llevan a entender los requerimientos se denomina ingeniería de requerimientos. Desde la perspectiva del proceso del software, la ingeniería de requerimientos es una de las acciones importantes de la ingeniería de software que comienza durante la actividad de comunicación y continúa en la de modelado. Debe adaptarse a las necesidades del proceso, del proyecto, del producto y de las personas que hacen el trabajo.
  1. Concepción.
    1. En la concepción del proyecto,3 se establece el entendimiento básico del problema, las personas que quieren una solución, la naturaleza de la solución que se desea, así como la eficacia de la comunicación y colaboración preliminares entre los otros participantes y el equipo de software.
  2. Indagación.
    1. En verdad que parece muy simple: preguntar al cliente, a los usuarios y a otras personas cuáles son los objetivos para el sistema o producto, qué es lo que va a lograrse, cómo se ajusta el sistema o producto a las necesidades del negocio y, finalmente, cómo va a usarse el sistema o producto en las operaciones cotidianas. Pero no es simple: es muy difícil.
    2. Problemas que se encuentran cuando ocurre la indagación:
      1. • Problemas de alcance.
        La frontera de los sistemas está mal definida o los clientes o usuarios finales especifican detalles técnicos innecesarios que confunden, más que clarifican, los objetivos generales del sistema.
        • Problemas de entendimiento.
        Los clientes o usuarios no están completamente seguros de lo que se necesita, comprenden mal las capacidades y limitaciones de su ambiente de computación, no entienden todo el dominio del problema, tienen problemas para comunicar las necesidades al ingeniero de sistemas, omiten información que creen que es “obvia”, especifican requerimientos que están en conflicto con las necesidades de otros clientes o usuarios, o solicitan requerimientos ambiguos o que no pueden someterse a prueba.
        • Problemas de volatilidad.
        Los requerimientos cambian con el tiempo.
  3. Elaboración.
    1. La elaboración está motivada por la creación y mejora de escenarios de usuario que describan cómo interactuará el usuario final (y otros actores) con el sistema. Cada escenario de usuario se enuncia con sintaxis apropiada para extraer clases de análisis, que son entidades del dominio del negocio visibles para el usuario final.
  4. Negociación.
    1. Se pide a clientes, usuarios y otros participantes que ordenen sus requerimientos según su prioridad y que después analicen los conflictos. Con el empleo de un enfoque iterativo que da prioridad a los requerimientos, se evalúa su costo y riesgo, y se enfrentan los conflictos internos; algunos requerimientos se eliminan, se combinan o se modifican de modo que cada parte logre cierto grado de satisfacción.
  5. Especificación.
    1. Una especificación puede ser un documento escrito, un conjunto de modelos gráficos, un modelo matemático formal, un conjunto de escenarios de uso, un prototipo o cualquier combinación de éstos.
  6. Validación.
    1. La validación de los requerimientos analiza la especificación5 a fin de garantizar que todos ellos han sido enunciados sin ambigüedades; que se detectaron y corrigieron las inconsistencias, las omisiones y los errores, y que los productos del trabajo se presentan conforme a los estándares establecidos para el proceso, el proyecto y el producto.
  7. Administración de los requerimientos.
    1. La administración de los requerimientos es el conjunto de actividades que ayudan al equipo del proyecto a identificar, controlar y dar seguimiento a los requerimientos y a sus cambios en cualquier momento del desarrollo del proyecto.
5.2 ESTABLECER LAS BASES
1. 5.2.1 Identificación de los participantes
  1. participante como “cualquier persona que se beneficie en forma directa o indirecta del sistema en desarrollo”.
  2. 5.2.2 Reconocer los múltiples puntos de vista
    1. Debido a que existen muchos participantes distintos, los requerimientos del sistema se explorarán desde muchos puntos de vista diferentes.
    2. 5.2.3 Trabajar hacia la colaboración
      1. El trabajo del ingeniero de requerimientos es identificar las áreas de interés común (por ejemplo, requerimientos en los que todos los participantes estén de acuerdo) y las de conflicto o incongruencia (por ejemplo, requerimientos que desea un participante, pero que están en conflicto con las necesidades de otro).
      2. 5.2.4 Hacer las primeras preguntas
        El primer conjunto de ellas se centran en el cliente y en otros participantes, en las metas y beneficios generales.
        • ¿Quién está detrás de la solicitud de este trabajo? • ¿Quién usará la solución? • ¿Cuál será el beneficio económico de una solución exitosa? • ¿Hay otro origen para la solución que se necesita?
        Permiten entender mejor el problema y hacen que el cliente exprese sus percepciones respecto de la solución:
        • ¿Cuál sería una “buena” salida generada por una solución exitosa? • ¿Qué problemas resolvería esta solución? • ¿Puede mostrar (o describir) el ambiente de negocios en el que se usaría la solución? • ¿Hay aspectos especiales del desempeño o restricciones que afecten el modo en el que se enfoque la solución?
        Las preguntas finales se centran en la eficacia de la actividad de comunicación en sí.
        • ¿Es usted la persona indicada para responder estas preguntas? ¿Sus respuestas son “oficiales”? • ¿Mis preguntas son relevantes para el problema que se tiene? • ¿Estoy haciendo demasiadas preguntas? • ¿Puede otra persona dar información adicional? • ¿Debería yo preguntarle algo más?
5.3 INDAGACIÓN DE LOS REQUERIMIENTOS
1. La indagación de los requerimientos (actividad también llamada recabación de los requerimientos) combina elementos de la solución de problemas, elaboración, negociación y especificación.
  1. 5.3.1 Recabación de los requerimientos en forma colaborativa
    1. • Tanto ingenieros de software como otros participantes dirigen o intervienen en las reuniones. • Se establecen reglas para la preparación y participación. • Se sugiere una agenda con suficiente formalidad para cubrir todos los puntos importantes, pero con la suficiente informalidad para que estimule el libre flujo de ideas. • Un “facilitador” (cliente, desarrollador o participante externo) controla la reunión. • Se utiliza un “mecanismo de definición” (que pueden ser hojas de trabajo, tablas sueltas, etiquetas adhesivas, pizarrón electrónico, grupos de conversación o foro virtual).
    2. 5.3.2 Despliegue de la función de calidad
      1. El despliegue de la función de calidad (DFC) es una técnica de administración de la calidad que traduce las necesidades del cliente en requerimientos técnicos para el software y satisface al cliente a partir del proceso de ingeniería del software. El DFC identifica tres tipos de requerimientos:
        Requerimientos normales.
        Objetivos y metas que se establecen para un producto o sistema durante las reuniones con el cliente. Si estos requerimientos están presentes, el cliente queda satisfecho. Ejemplos de requerimientos normales son los tipos de gráficos pedidos para aparecer en la pantalla, funciones específicas del sistema y niveles de rendimiento definidos.
        Requerimientos esperados.
        Están implícitos en el producto o sistema y quizá sean tan importantes que el cliente no los mencione de manera explícita. Su ausencia causará mucha insatisfacción. Algunos ejemplos de requerimientos esperados son: fácil interacción humano/máquina, operación general correcta y confiable, y facilidad para instalar el software.
        Requerimientos emocionantes.
        Estas características van más allá de las expectativas del cliente y son muy satisfactorias si están presentes. Por ejemplo, el software para un nuevo teléfono móvil viene con características estándar, pero si incluye capacidades inesperadas (como pantalla sensible al tacto, correo de voz visual, etc.) agrada a todos los usuarios del producto
      2. 5.3.3 Escenarios de uso
        A medida que se reúnen los requerimientos, comienza a materializarse la visión general de funciones y características del sistema. Para lograr esto, los desarrolladores y usuarios crean un conjunto de escenarios que identifican la naturaleza de los usos para el sistema que se va a construir. Los escenarios, que a menudo se llaman casos de uso proporcionan la descripción de la manera en la que se utilizará el sistema.
        5.3.4 Indagación de los productos del trabajo
        Los productos del trabajo generados como consecuencia de la indagación de los requerimientos variarán en función del tamaño del sistema o producto que se va a construir.
        • Un enunciado de la necesidad y su factibilidad. • Un enunciado acotado del alcance del sistema o producto. • Una lista de clientes, usuarios y otros participantes que intervienen en la indagación de los requerimientos. • Una descripción del ambiente técnico del sistema. • Una lista de requerimientos (de preferencia organizados por función) y las restricciones del dominio que se aplican a cada uno. • Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o producto en diferentes condiciones de operación. • Cualesquiera prototipos desarrollados para definir requerimientos.
5.4 DESARROLLO DE CASOS DE USO
1. Un caso de uso narra una historia estilizada sobre cómo interactúa un usuario final (que tiene cierto número de roles posibles) con el sistema en circunstancias específicas. El primer paso para escribir un caso de uso es definir un conjunto de “actores” que estarán involucrados en la historia. Los actores son las distintas personas (o dispositivos) que usan el sistema o producto en el contexto de la función y comportamiento que va a describirse.
5.5 ELABORACIÓN DEL MODELO DE LOS REQUERIMIENTOS
1. El objetivo del modelo del análisis es describir los dominios de información, función y comportamiento que se requieren para un sistema basado en computadora.
  1. 5.5.1 Elementos del modelo de requerimientos
    1. Elementos basados en el escenario.
      1. El sistema se describe desde el punto de vista del usuario con el empleo de un enfoque basado en el escenario. Por ejemplo, los casos de uso básico y sus diagramas correspondientes de casos de uso evolucionan hacia otros más elaborados que se basan en formatos.
      2. Elementos basados en clases.
        Cada escenario de uso implica un conjunto de objetos que se manipulan cuando un actor interactúa con el sistema. Estos objetos se clasifican en clases: conjunto de objetos que tienen atributos similares y comportamientos comunes.
        Elementos de comportamiento.
        El comportamiento de un sistema basado en computadora tiene un efecto profundo en el diseño que se elija y en el enfoque de implementación que se aplique. El diagrama de estado es un método de representación del comportamiento de un sistema que ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado. Un estado es cualquier modo de comportamiento observable desde el exterior.
        Elementos orientados al flujo.
        La información se transforma cuando fluye a través de un sistema basado en computadora. El sistema acepta entradas en varias formas, aplica funciones para transformarla y produce salidas en distintos modos.
  2. 5.5.2 Patrones de análisis
    1. Estos patrones de análisis sugieren soluciones (por ejemplo, una clase, función o comportamiento) dentro del dominio de la aplicación que pueden volverse a utilizar cuando se modelen muchas aplicaciones.
5.6 REQUERIMIENTOS DE LAS NEGOCIACIONES
1. En un contexto ideal de la ingeniería de los requerimientos, las tareas de concepción, indagación y elaboración determinan los requerimientos del cliente con suficiente detalle como para avanzar hacia las siguientes actividades de la ingeniería de software. El objetivo de esta negociación es desarrollar un plan del proyecto que satisfaga las necesidades del participante y que al mismo tiempo refleje las restricciones del mundo real (por ejemplo, tiempo, personas, presupuesto, etc.) que se hayan establecido al equipo del software.
5.7 VALIDACIÓN DE LOS REQUERIMIENTOS
1. A medida que se crea cada elemento del modelo de requerimientos, se estudia para detectar inconsistencias, omisiones y ambigüedades. Los participantes asignan prioridades a los requerimientos representados por el modelo y se agrupan en paquetes de requerimientos que se implementarán como incrementos del software.

Next up

COMPRENSIÓN DE LOS REQUERIMIENTOS

Description

Resource summary

Media attachments

Similar

	Created by richard simbaña over 10 years ago