INGENIERIA DEL SOFTWARE II TRAYECTO III FUNDAMENTOS DE INGENIERÍA DE REQUISITOS Y ANÁLISIS

UNIDAD I

REQUERIMIENTOS DEL SOFTWARE

CONTENIDO

1. Requerimientos

1.1. ¿Qué son los requerimientos o Requisitos? 1.2. Necesidades,

1.3. Objetivos, 1.4. Características de los requerimiento

2. Importancia de la Ingeniería de Requisitos en la práctica 3. Actividades de la ingeniería de requerimientos

3.1. Extracción

3.2. Análisis

3.3. Especificación

3.4. Validación

4. Levantamiento y Recolección de Requerimientos. 4.1. Técnicas de Elicitación más usadas

4.1.1. Entrevistas y Cuestionarios 4.1.2. Sistemas existentes 4.1.3. Brainstorming o tormenta de ideas 4.1.4. Prototipos 4.1.5. Casos de Uso 4.1.6. La técnica JAD (Joint Application Development) 4.1.7. Ventajas y desventajas de las técnicas de elicitación

1.- REQUERIMIENTOS.

El proceso de recopilar, analizar y verificar las necesidades del cliente para un sistema

de software es llamado Ingeniería de Requerimientos. La meta de la ingeniería de

requerimientos es entregar una especificación de requerimientos de software correcta

y completa. La ingeniería de requerimientos apunta a mejorar la forma en que

comprendemos y definimos sistemas de software complejos. Existen varias

definiciones de requerimientos, de entre las cuales podemos citar las siguientes:

1.1 ¿Qué son los requerimientos o Requisitos?

Los Requerimientos fueron definidos por la IEEE como [IEEE90]:

1. Condición o capacidad requerida por el usuario para resolver un problema o

alcanzar un objetivo

2. Condición o capacidad que debe satisfacer o poseer un sistema o una componente

de un sistema para satisfacer un contrato, un standard, una especificación u otro

documento formalmente impuesto.

Según Zave:

“Rama de la ingeniería del software que trata con el establecimiento de los objetivos,

funciones y restricciones de los sistemas software. Asimismo, se ocupa de la relación

entre estos factores con el objeto de establecer especificaciones precisas ”.

Según Boehm:

“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 dónde se describen las funciones que realizará

el sistema”.

Según Loucopoulos:

“Trabajo sistemático de desarrollo de requisitos, a través de un proces o iterativo y

cooperativo de análisis del problema, documentando los resultados en una variedad

de formatos y probando la exactitud del conocimiento adquirido”.

Según Leite:

“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.2 Necesidades de los requerimientos

Los Requerimientos cumplen un papel primordial en el proceso de producción

de software, ya que enfoca un área fundamental: la definición de lo que se desea

producir. Su principal tarea consiste en la generación de especificaciones correctas que

describan con claridad, sin ambigüedades, en forma consistente y compacta, el

comportamiento del sistema; de esta manera, se pretende minimizar los problemas

relacionados al desarrollo de sistemas.

1.3 Objetivos de los Requerimientos

El objetivo principal de esta actividad es desarrollar una propuesta de sistema software

como solución a las necesidades de negocio de clientes y usuarios, haciéndolo con la

mayor calidad posible e intentando asegurar que coincide con las expectativas de

clientes y usuarios.

Los principales objetivos que se identifican en la especificación de requisitos software

son [Chalmeta, 2000]:

1. Ayudar a los clientes a describir claramente lo que se desea obtener mediante un

determinado software: El cliente debe participar activamente en la especificación de

requisitos, ya que éste tiene una visión mucho más detallada de los procesos que se

llevan a cabo. Asimismo, el cliente se siente partícipe del propio desarrollo.

2. Ayudar a los desarrolladores a entender qué quiere exactamente el cliente: En

muchas ocasiones el cliente no sabe exactamente qué es lo que quiere. La ERS permite

al cliente definir todos los requisitos que desea y al mismo tiempo los desarrolladores

tienen una base fija en la que trabajar. Si no se realiza una buena especificación de

requisitos, los costes de desarrollo pueden incrementarse considerablemente, ya que

se deben hacer cambios durante la creación de la aplicación.

3. Servir de base para desarrollos de estándares de ERS particulares para cada

organización: Cada entidad puede desarrollar sus propios estándares para definir sus

necesidades. Una buena especificación de requisitos software ofrece una s erie de

ventajas entre las que destacan el contrato entre cliente y desarrolladores (como ya se

ha indicado con anterioridad), la reducción del esfuerzo en el desarrollo, una buena

base para la estimación de costes y planificación, un punto de referencia para procesos

de verificación y validación, y una base para la identificación de posibles mejoras en los

procesos analizados.

Los objetivos son afirmaciones de alto nivel que nos guían hacia la dentificación

de requerimientos ya que siempre debe estar claro y presente el Objetivo de Negocio.

Los ingenieros de requisitos deben elaborar la propuesta en forma de requisitos del

sistema software a desarrollar, usando como entrada la información que se va

generando en el procedimiento Identificar las necesidades de negocio de clientes y

usuarios. Lo habitual es comenzar por los aspectos más generales del sistema (su visión

general), para ir avanzando en el nivel de detalle hasta que se considere suficiente

como para que pueda continuarse el desarrollo sin tener que plantear preguntas

continuas sobre la conducta del sistema a desarrollar.

Durante esta actividad es frecuente que en cualquier momento se identifiquen y

registren diversos tipos de problemas en los requisitos, cuya solución debe gestionarse

por la actividad de Gestionar los problemas en los requisitos dentro del procedimiento

Gestionar los requisitos del sistema software a desarrollar.

1.4 Características de los requerimientos:

Es importante no perder de vista que un requerimiento debe ser:

Especificado por escrito: Como todo contrato o acuerdo entre dos partes.

Posible de probar o verificar. Si un requerimiento no se puede comprobar,

entonces ¿cómo se sabe si se cumplió con él o no?

Conciso: Un requerimiento es conciso 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.

Completo: Un requerimiento está completo si no necesita ampliar detalles en

su redacción, es decir, si se proporciona la información suficiente para su

comprensión.

Consistente: Un requerimiento es consistente si no es contradictorio con otro

requerimiento.

No ambiguo: Un requerimiento no es ambiguo cuando tiene una sola

interpretación. El lenguaje usado en su definición, no debe causar confusiones

al lector.

2.- IMPORTANCIA DE LA INGENIERÍA DE REQUERIMIENTOS

Sabemos que muchos proyectos de Software fracasan porque no se realiza un estudio

previo de los requisitos del usuario, no se hace una definición completa del alcance del

proyecto. No realizamos el modelado del negocio antes de desarrollar el software, esto

significa que el analista no se involucra en el problema; aunque tiene claro que el

sistema debe desarrollarse para dar soporte a los procesos de la organización, sino se

involucra en la problemática corre el riesgo de que los requisitos identificados no

correspondan a las necesidades para lo que se debe crear.

Otro problema que conocemos es el de no involucrar al usuario activamente en el

desarrollo del producto “UNA BUENA PRACTICA SERIA MODELAR JUNTO AL CLIENTE”.

Requerimientos incompletos y el cambio frecuente de los requerimientos establecidos

sabemos que son otros factores que llevan los sistemas al fracaso.

Entonces, es bien importante que no exista carencia de requerimientos bien definidos

porque así evitamos esta lista de problemas:

No se realizan estimaciones realistas.

No se emplean coherentemente herramientas de planeación.

No se pueden realizar revisiones periódicas del progreso en base a las

especificaciones

La Arquitectura, el diseño y el desarrollo del software carecerán de una base firme.

Las pruebas se basaran en supuestos, no en lo que el usuario requiere.

No es posible controlar el crecimiento de los requerimientos.

La Ingeniería de Requerimientos cumple un papel primordial en el proceso productivo

ya que se enfoca en el área fundamental: "LA PRODUCCION", siendo su tarea la

generación de especificaciones correctas que describan con claridad, sin

ambigüedades y en forma compacta las necesidades del cliente, cumpliendo lo antes

expresado se obtendrá un proyecto que minimizará los problemas relacionados con la

gestión de dichos requerimientos.

Respondiendo a la pregunta inicial entonces podemos decir que los requerimientos son importantes debido a que son el hilo conductor de todo desarrollo de software. Obtener requerimientos de calidad demuestra que el trabajo realizado culminará con éxito, esto se debe a dos factores:

1. La utilización adecuada de las técnicas de captura de requerimientos con los clientes.

2. Las experiencias de los analistas del proyecto.

Esto sucede porque la experiencia de trabajo en el rol le permite al equipo de Analistas

del Proyecto establecer que técnicas van a utilizar a la hora de la entrevista con el cliente debido a que los clientes no entienden el lenguaje informático, es por eso que

se debe tener en cuenta el lenguaje el cual se va a aplicar a la hora de la entrevista con el cliente.

Según la autora Lizka Johany Herrera en su documento de la ingeniería de

requerimientos, los principales beneficios que se obtienen de la Ingeniería de

Requerimientos son (2003: 3):

Permite gestionar las necesidades del proyecto en forma estructurada: Cada

actividad de la IR consiste de una serie de pasos organizados y bien definidos.

Mejora la capacidad de predecir cronogramas de proyectos, así como sus

resultados: La IR proporciona un punto de partida para controles subsecuentes

y actividades de mantenimiento, tales como estimación de costos, tiempo y

recursos necesarios.

Disminuye los costos y retrasos del proyecto: es sabido que reparar errores por

un mal desarrollo no descubierto a tiempo, es sumamente caro; especialmente

aquellas decisiones tomadas durante la IR, ya que es una de las etapas de

mayor importancia en el ciclo de desarrollo de software y de las primeras en

llevarse a cabo.

Mejora la calidad del software: La calidad en el software tiene que ver con

cumplir un conjunto de requerimientos (funcionalidad, facilidad de uso,

confiabilidad, desempeño, etc.).

Mejora la comunicación entre equipos: La especificación de requerimientos

representa una forma de consenso entre clientes y desarrolladores. Si este

consenso no ocurre, el proyecto no será exitoso.

Evita rechazos de usuarios finales: La ingeniería de requerimientos obliga al

cliente a considerar sus requerimientos cuidadosamente y revisarlos dentro del

marco del problema, por lo que se le involucra durante todo el desarrollo del

proyecto.

3.- Actividades de la ingeniería de requerimientos

Dentro del mismo documento mencionado anteriormente (Herrera, 2003: 6), se dice

que dentro de la IR existen cuatro actividades básicas que se tienen que llevar a cabo

para completar el proceso. Estas actividades ayudan a reconocer la importancia que

tiene para el desarrollo de un proyecto de software realizar una especificación y

administración adecuada de los requerimientos de los clientes o usuarios.

Las cuatro actividades son: extracción, análisis, especificación y validación, y serán

explicadas a continuación cada una de ellas.

3.1 Extracción

Esta fase representa el comienzo de cada ciclo. Extracción es el nombre comúnmente

dado a las actividades involucradas en el descubrimiento de los requerimientos del

sistema. Aquí, los analistas de requerimientos deben trabajar junto al cliente para

descubrir el problema que el sistema debe resolver, los diferentes servicios que el

sistema debe prestar, las restricciones que se pueden presentar, etc.

Es importante, que la extracción sea efectiva, ya que la aceptación del sistema

dependerá de cuan bien éste satisfaga las necesidades del cliente.

3.2 Análisis

Sobre la base de la extracción realizada previamente, comienza esta fase en la cual se

enfoca en descubrir problemas con los requerimientos del sistema identificados has ta

el momento.

Usualmente se hace un análisis luego de haber producido un bosquejo inicial del

documento de requerimientos; en esta etapa se leen los requerimientos, se

conceptúan, se investigan, se intercambian ideas con el resto del equipo, se resaltan

los problemas, se buscan alternativas y soluciones, y luego se van fijando reuniones

con el cliente para discutir los requerimientos.

3.3 Especificación

En esta fase se documentan los requerimientos acordados con el cliente, en un nivel

apropiado de detalle.

En la práctica, esta etapa se va realizando conjuntamente con el análisis, se puede

decir que la especificación es el "pasar en limpio" el análisis realizado previamente

aplicando técnicas y/o estándares de documentación, como la notación UML (Lenguaje

de Modelado Unificado), que es un estándar para el modelado orientado a objetos,

por lo que los casos de uso y la obtención de requerimientos basada en casos de uso se

utiliza cada vez más para la obtención de requerimientos.

3.4 Validación

La validación es la etapa final de la IR. Su objetivo es, ratificar los requerimientos, es

decir, verificar todos los requerimientos que aparecen en el documento especificado

para asegurarse que representan una descripción, por lo menos, aceptable del sistema

que se debe implementar. Esto implica verificar que los requerimientos sean

consistentes y que estén completos.

Se puede apreciar que el proceso de ingeniería de requerimientos es un conjunto

estructurado de actividades, mediante las cuales se obtiene, se valida y se logra dar un

mantenimiento adecuado al documento de especificación de requerimientos, que es el

documento final, de carácter formal, que se obtiene de este proceso. Es necesario

recalcar que 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. Hay muchas maneras de organizar el proceso de ingeniería de

requerimientos y en otras ocasiones se tiene la oportunidad de recurrir a consultores,

ya que ellos tienen una perspectiva más objetiva que las personas involucradas en el

proceso.

4.- LEVANTAMIENTO Y RECOLECCION DE REQUERIMIENTOS

Cuando nos encontramos al frente de un proyecto de desarrollo de software es

importante dejar claramente definidos los requerimientos, en forma consistente y

compacta, esta tarea es difícil básicamente porque consiste en la traducción de unas

ideas vagas de necesidades de software en un conjunto concreto de funciones y

restricciones. Además el analista debe extraer información dialogando con muchas

personas y cada una de ellas se expresará de una forma distinta, tendrá conocimientos

informáticos y técnicos distintos, y tendrá unas necesidades y una idea del proyecto

muy particulares.

Es justamente este último punto uno de los que se atacará en esta tesis: que el usuario

y el desarrollador compartan el mismo lenguaje asegura la comunicación entre ambos.

[Leite89] sugiere que en particular el uso del lenguaje propio del usuario mejora

considerablemente esta comunicación. En el proceso de Ingeniería de Requerimientos

la validación de los diferentes productos requiere una fuerte interacción con el usuario

[Loucopoulos], la que se ve facilitada por el vocabulario común usuario-desarrollador.

Las diferentes representaciones que se construyen en el proceso de desarrollo de

software encuentran en el vocabulario del usuario un marco referencial que permite al

desarrollador, obtener un vocabulario de trabajo que es un subconjunto de la

terminología del cliente, lo que a su vez facilita el acceso a la documentación por parte

de todos los participantes en el desarrollo. En muchos casos es difícil especificar los

requerimientos de un problema, con la mayor calidad posible en una etapa temprana

del proceso de desarrollo.

Uno de los mayores problemas que surgen en la fase de análisis y definición de los

requerimientos en una etapa temprana del desarrollo, es cómo organizar toda la

información que adquiere el analista en sus entrevistas con las personas involucradas

en un proyecto y cómo poner de acuerdo a todas estas personas sobre cuál es la

solución más adecuada. Mientras que los métodos clásicos se basan en entrevistas

bilaterales (el analista y cada una de las partes) con lo que dejan para el analista toda

la labor de organización y obtención de un consenso, recientemente se tiende a

prácticas más relacionadas con el brainstorming en el que cada parte expone sus ideas

y propuestas y se produce un debate de forma que las posiciones vayan acercándose

sucesivamente hasta que se llegue a un consenso [Raghavan].

4.1 TECNICAS DE ELICITACIÓN MÁS USADAS

Existen varias técnicas para la IR propuestas para ingeniería de requerimientos

(Herrera, 2003: 12), y de las cuales en este artículo solo se abarcarán cinco de ellas. Es

importante resaltar que estas técnicas pueden ser aplicables a las distintas fases del

proceso de la IR, haciendo la salvedad de que hay que tomar en cuenta las

características propias del proyecto en particular que se esté desarrollándose para

aprovechar al máximo su utilidad.

4.1.1 Entrevistas y Cuestionarios

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.

Por lo común, los encuestados son usuarios de los sistemas existentes o usuarios en

potencia del sistema propuesto. En algunos casos, son gerentes o empleados que

proporcionan datos para el sistema propuesto o que serán afectados por él. El éxito de

esta técnica, depende de la habilidad del entrevistador y de su preparación para la

misma.

Preparación de entrevistas

Las entrevistas no deben improvisarse, por lo que conviene realizar las siguientes

tareas previas:

• Estudiar el dominio del problema: se debe conocer la terminología básica del

dominio del problema, evitando que el cliente tenga que explicar términos que para él

son obvios. Para ello se puede recurrir a la técnica auxiliar de estudio de

documentación, a bibliografía sobre el tema, documentación de proyectos similares

realizados anteriormente, etc.

• 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 seleccionar a las personas a

entrevistar. El orden de realización de las entrevistas también es importante.

Normalmente se aplica un enfoque top–down, comenzando por los directivos, que

pueden ofrecer una visión global, ayudar a determinar los objetivos y reducir ciertas

reticencias en sus subordinados, y terminando por los futuros usuarios, que pueden

aportar información más detallada.

• 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.

• Planificar las entrevistas: la fecha, hora, lugar y duración de las entrevista deben

fijarse teniendo en cuenta siempre la agenda del entrevistado.

Realización de entrevistas

Dentro de la realización de las entrevistas se distinguen tres etapas, tal como se

expone en [Piattini]:

• 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.

• Desarrollo: la entrevista en sí no debería durar más de dos horas, 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.

• Terminación: se debe recapitular sobre la entrevista 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.

Análisis de las entrevistas

Una vez realizada la entrevista es necesario leer las notas tomadas, pasarlas a limpio,

reorganizar la información, contrastarla con otras entrevistas o fuentes de

información, etc. 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.

4.1. 2 Sistemas existentes

Esta técnica consiste en analizar distintos sistemas ya desarrollados que estén

relacionados con el sistema a ser construido. Por un lado, podemos analizar las

interfaces de usuario, observando el tipo de información que se maneja y cómo es

manejada, por otro lado también es útil analizar las distintas salidas que los sistemas

producen (listados, consultas, etc.), porque siempre pueden surgir nuevas ideas sobre

la base de estas.

4.1.3 Lluvia de ideas (Brainstorm)

Este es un modelo que se usa para generar ideas. La intención en su aplicación es la de

generar la máxima cantidad posible de requerimientos para el sistema. No hay que

detenerse en pensar si la idea es o no del todo utilizable. La intención de este ejercicio

es generar, en una primera instancia, muchas ideas.

Luego, se irán eliminando en base a distintos criterios como, por ejemplo, "caro",

"impracticable", "imposible", etc.

Las reglas básicas a seguir son:

Los participantes deben pertenecer a distintas disciplinas y, preferentemente,

deben tener mucha experiencia. Esto trae aparejado la obtención de una

cantidad mayor de ideas creativas.

Conviene suspender el juicio crítico y se debe permitir la evolución de cada una

de las ideas, porque si no se crea un ambiente hostil que no alienta la

generación de ideas.

Por más locas o salvaje que parezcan algunas ideas, no se las debe descartar,

porque luego de maduradas probablemente se tornen en un requerimiento

sumamente útil.

A veces ocurre que una idea resulta en otra idea, y otras veces podemos

relacionar varias ideas para generar una nueva.

Escribir las ideas sin censura.

4.1.4 Prototipos

Durante la actividad de extracción de requerimientos, puede ocurrir que algunos

requerimientos no estén demasiado claros o que no se esté muy seguro de haber

entendido correctamente los requerimientos obtenidos hasta el momento, todo lo

cual puede llevar a un desarrollo no eficaz del sistema final.

Entonces, para validar los requerimientos hallados, se construyen prototipos. Los

prototipos son simulaciones del posible producto, que luego son utilizados por el

usuario final, permitiéndonos conseguir una importante retroalimentación en cuanto a

si el sistema diseñado con base a los requerimientos recolectados le permite al usuario

realizar su trabajo de manera eficiente y efectiva.

El desarrollo del prototipo comienza con la captura de requerimientos. Desarrolladores

y clientes se reúnen y definen los objetivos globales del software, identifican todos los

requerimientos que son conocidos, y señalan áreas en las que será necesaria la

profundización en las definiciones. Luego de esto, tiene lugar un “diseño rápido”. El

diseño rápido se centra en una representación de aquellos aspectos del software que

serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). El diseño

rápido lleva a la construcción de un prototipo.

4.1.5 Casos de Uso

Los casos de uso son una técnica para especificar el comportamiento de un sis tema. El

sitio en Internet wikipedia.org, define a un caso de uso como: “Un caso de uso es una

secuencia de transacciones que son desarrolladas por un sistema en respuesta a un

evento que inicia un actor sobre el propio sistema. Los diagramas de casos de uso

sirven para especificar la funcionalidad y el comportamiento de un sistema mediante

su interacción con los usuarios y/u otros sistemas”

Los casos de uso permiten entonces describir la posible secuencia de interacciones

entre el sistema y uno o más actores, en respuesta a un estímulo inicial proveniente de

un actor, es una descripción de un conjunto de escenarios, cada uno de ellos

comenzado con un evento inicial desde un actor hacia el sistema. La mayoría de los

requerimientos funcionales, sino todos, se pueden expresar con casos de uso.

Según el autor Sommerville, los casos de uso son una técnica que se basa en

escenarios para la obtención de requerimientos. Actualmente, se han convertido en

una característica fundamental de la notación UML (Lenguaje de modelado unificado),

que se utiliza para describir modelos de sistemas orientados a objetos.

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 (Unified Modeling Language) 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. UML va en camino de convertirse en un estándar

para modelado de sistemas de software de amplia difusión.

A pesar de ser considerada una técnica de Análisis Orientado a Objetos, es importante

destacar que los casos de uso poco tienen que ver con entender a un sistema como un

conjunto de objetos que interactúan, que es la premisa básica del análisis orientado a

objetos “clásico”. En este sentido, el éxito de los casos de uso no hace más que dar la

razón al análisis estructurado, que propone que la mejor forma de empezar a entender

un sistema es a partir de los servicios o funciones que ofrece a su entorno,

independientemente de los objetos que interactúan dentro del sistema para

proveerlos.

Como era de esperar, es probable que en el futuro los métodos de análisis y diseño

que prevalezcan hayan adoptado las principales ventajas de todos los métodos

disponibles en la actualidad (estructurados, métodos formales, métodos orientados a

objetos, etc.).

4.1.6 La técnica del JAD (Joint Application Development)

Desarrollada por IBM en 1977, es una alternativa a las entrevistas individuales que se

desarrolla a lo largo de un conjunto de reuniones en grupo durante un periodo de 2 a 4

días. En estas reuniones se ayuda a los clientes y usuarios a formular problemas y

explorar posibles soluciones, involucrándolos y haciéndolos sentirse partícipes del

desarrollo.

Esta técnica se base en cuatro principios [Raghavan]: dinámica de grupo, el uso de

ayudas visuales para mejorar la comunicación (diagramas, transparencias, mul timedia,

herramientas CASE, etc.), mantener un proceso organizado y racional y una filosofía de

documentación WYSIWYG (What You See Is What You Get, lo que se ve es lo que se

obtiene), por la que durante las reuniones se trabaja directamente sobre los

documentos a generar.

Debido a las necesidades de organización que requiere y a que no suele adaptarse bien

a los horarios de trabajo de los clientes y usuarios, esta técnica no suele emplearse con

frecuencia, aunque cuando se aplica suele tener buenos resultados, especialmente

para elicitar requerimientos en el campo de los sistemas de información [Raghavan].

En comparación con las entrevistas individuales, presenta las siguientes ventajas:

• Ahorra tiempo al evitar que las opiniones de los clientes se contrasten

• por separado.

• Todo el grupo, incluyendo los clientes y los futuros usuarios, revisa la

documentación generada, no sólo los ingenieros de requerimientos.

• Implica más a los clientes y usuarios en el desarrollo.

Podríamos analizar muchos métodos que ofrece esta técnica, pero todos enfocan hacia

las siguientes directrices básicas:

Se efectúa una reunión en un lugar neutral, se establecen reglas para la preparación y

participación, se elabora una agenda, se elige un facilitador, se utiliza un mecanismo

de comunicación y primeramente el objetivo principal debe ser identificar el problema.

4.1.7 Ventajas y desventajas de las técnicas de elicitación

En el cuadro 1 resumimos Como resumen podemos presentar las principales ventajas y

desventajas de cada una de las técnicas utilizadas en las etapas de la Ingeniería de

Requerimientos.

Técnica Ventajas Desventajas

Entrevistas y

Cuestionarios

• Mediante ellas se obtiene una gran cantidad de información adecuada a

través del usuario. • Pueden ser usadas para obtener una

visión general del dominio del problema.

• La información obtenida al principio puede ser

redundante o incompleta. • Si el volumen de

información manejado es

• Son flexibles. • Permiten combinarse con otras técnicas.

alto, requiere mucha organización de parte del analista, así como la habilidad para tratar y comprender el comportamiento de todos los

involucrados.

Tormenta de

Ideas

• La producción de ideas en grupos puede ser más efectiva que la individual.

• Aflora una gran cantidad de ideas sin ataduras.

• Es necesaria una buena compenetración del grupo

participante.

Casos de Uso

• Representan los requerimientos desde el punto de vista del usuario. • Permiten representar más de un rol para cada afectado. • Identifica nuevos requerimientos, dentro de un conjunto de requerimientos.

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

JAD

• Ahorra tiempo, elimina retrasos del proceso y mejora la calidad del sistema. • Es una de las mejores maneras de reducir los errores arrastrados de los resultados de los requerimientos iniciales. • Con la participación de gerentes y usuarios apropiados, el riesgo cultural

típico se mitiga.

• Evita funcionalidad sobredimensionada.

• Evita que los requerimientos sean demasiado específicos o demasiados

vagos, que son dos problemas comunes en el análisis.

• Es costoso Involucrar al patrocinador del proyecto y gerente, experto en la tecnología, y expertos de la materia, como parte del equipo del proyecto.

Cuadro 1: Principales ventajas y desventajas de las técnicas de elicitación.

Es importante destacar, que independientemente a la técnica de elicitación que se

utilice y durante todo el proceso de desarrollo del software es indispensable mantener

una adecuada comunicación entre los participantes.

Para esto, un enfoque valioso es la utilización del mismo léxico. En la fase de

elicitación, será tarea del analista ocuparse de homogeneizar el vocabulario,

centrándolo en el léxico propio del cliente [Leite89], esto evitará que el analista utilice

el lenguaje común en su medio ambiente. Simultáneamente, el cliente trasmitirá sus

necesidades en su lenguaje habitual.