Manual del estudiante de Ingeniería en Sistemas de UTN/Ingeniería de requerimientos/Unidad III

Elicitación

Identificación de requisitos

Tarea de identificar los hechos que componen los requisitos del sistema, de modo de proveer el más correcto y completo entendimiento de lo que se le demanda a un software determinado.

Elicitar

Descubrir, explicitar, obtener el máximo de información para el conocimiento del objeto en cuestión.

Proceso de elicitación:

Identificación de Fuentes de Información
Colecta de hechos
Comunicación

Identificación de Fuentes de Información

A través de este paso se define el contexto donde la IR va a trabajar.

El primer paso es la identificación del Universo de Información (UdI), del cual se extraerá la información necesaria en la tarea de elicitación.

Luego deberá elegirse una estrategia de investigación de estas fuentes de información.

Identificación de los actores. Para ello se puede utilizar un árbol abstracto de usuarios ^[1].

Documentos en el UdI que pueden incluir:
- Documentación del Macrosistema
- Políticas de Organización
- Manuales de equipamiento de hard y soft
- Memorandos, actas de reunión, contratos con desarrolladores, etc.
Libros sobre los temas relacionados
Otros sistemas que ya existen en la empresa
Otros sistemas que ya existen en el mercado
Identificar los clientes del sistema, personas o sectores de una organización que son los principales usuarios del sistema a construir.
Identificar los actores que serán impactados en sus rutinas de trabajo.
Procurar establecer la red de comunicación existente entre los componentes del macrosistema.
Tratar de identificar otros actores que puedan aportar datos.
Identificar grupos de interés.
Identificar soluciones disponibles.
Descubrir otras fuentes de información (entrevistas).

Colecta de hechos: Estrategias

Lectura de Documentos

Contacto con el vocabulario de la aplicación y del UdI.

Ventajas: facilidad de acceso a las FI y cantidad de información.

Desventajas: la dispersión de las informaciones y el volumen de trabajo requerido para la identificación de los hechos.

Observación

El analista (IR) tiene una posición pasiva en el UdI observando el ambiente donde el software irá a actuar.

Ventajas: bajo costo y la poca complejidad de la tarea.

Desventajas: dependencia del actor desempeñando el papel de observador y la superficialidad debido a la poca exposición al universo que está siendo observado.

Entrevistas

Son el medio más usual con el cual el analista recoge los hechos.

Ventajas: la posibilidad del contacto directo con los actores que tienen el conocimiento sobre los objetivos del software y la posibilidad de validación inmediata a través de procesos de comunicación que resaltan la confirmación.

Desventajas: el problema del conocimiento tácito y las diferencias de cultura entre entrevistado y entrevistador (lo que es trivial para el entrevistado podría no serlo para el entrevistador).

Existen diferentes tipos de entrevistas: Estructuradas, Informales y Tutorías.

Estructurada: mediante preguntas. Requiere conocimiento del UdI.

Tutoría: el cliente está al mando, es un curso sobre el UdI.

Informal: mayor flexibilidad, se usa en la fase exploratoria.

Cuestionarios

Los cuestionarios son utilizados cuando se tiene un buen conocimiento sobre el problema (aplicación) y se quiere abarcar un número grande de clientes.

Ventajas: enfoque de las preguntas y la posibilidad de tratamiento estadístico de las respuestas.

Desventajas: la limitación del universo de respuestas, poca interacción e iteraciones, viendo lo impersonal de esta técnica.

Análisis de Protocolos

Esta estrategia consiste en analizar el trabajo de determinada persona a través de relatos de esa persona. Normalmente en el tiempo de trabajo. Otro modo es fuera del lugar de trabajo, con situaciones posibles.

Objetivo: Ver la racionalidad del trabajo que se realiza.

Ventajas: posibilidad de elicitar hechos no fácilmente observables y permitir un mejor entendimiento de los hechos, que son explicados y justificados.

Desventajas: centrada principalmente en la performance del entrevistado y sufre del problema de que lo que se dice es diferente a lo que se hace.

Participación Activa de los Actores UdI

Procura incorporar al grupo de analistas los actores que demandan el software. Los actores deben aprender el lenguaje de modelado.

Ventajas: participación de los clientes y usuarios en el proceso de identificación de los hechos y de la elicitación del conocimiento y facilita el proceso de validación. Mayor integración de los actores con los analistas.

Desventajas: el entrenamiento de los clientes y usuarios en técnicas de informática y una falsa impresión de que, por la participación pura y simple de representantes de los clientes y usuarios, el proceso fue ejecutado de manera eficaz.

Enfoque Antropológico

En esta estrategia se usa una técnica inversa de la descripta anteriormente, aquí los ingenieros de software deben procurar integrarse al UdI de forma de tener un conocimiento lo más amplio posible del problema.

Ventaja: posibilidad de una visión de adentro hacia afuera más completa y perfectamente ajustada al contexto.

Desventaja: tiempo insumido en en el proceso de integración.

Reuniones

Son una extensión de las entrevistas.

Ventajas: posibilidad de disponer de múltiples opiniones y de creación colectiva.

Desventajas: la posibilidad de dispersión y el costo.

Reutilización

Reutilizar hechos ya elicitados. Es posible cuando se tiene un dominio^[2].

Ventajas: la productividad y la calidad, ya que los componentes a ser reutilizados ya fueron validados anteriormente.

Desventaja: dificultad de proveer reutilización sin modificación del nivel de abstracción de la definición de requisitos.

Heurísticos generales

Preguntar: ¿Qué? ¿Porqué? ¿Cómo? ¿Quién?
Esclarecer lo que es obvio en el UdI.
Organice las respuestas: Durante vs. Después.
Vuelva a preguntar.
Organice las preguntas, las respuestas, y el método usado.
Viva en el UdI por un tiempo.
Tenga una visión antropológica.
Observe.
Estudie.
Sea humilde. Procure aprender.

Comunicación

Para que la Elicitación tenga éxito es fundamental que los analistas se puedan comunicar eficazmente con los clientes. Existen barreras entre clientes y analistas.

Las diferencias de conocimiento son reflejos de culturas diferentes.

El conocimiento tácito es una de los orígenes de las diferencias.

Técnicas para Comunicación

Presentación: manera de presentar la información.

Entendimiento: El establecimiento del contexto común y del objetivo es fundamental para iniciar un entendimiento mutuo entre clientes e ingenieros de software.

Lenguajes: Cabe al analista procurar entender el lenguaje de sus clientes antes de entender sus necesidades. El conocimiento del lenguaje del cliente es importante como medio de facilitar la comunicación.

Nivel de Abstracción: Así mismo si se trata de una única cultura la comunicación puede ser extremadamente ruidosa si los individuos estuvieran dialogando en diferentes niveles de abstracción.

Retroalimentación: Una de las maneras eficaces de garantizar el paso de la información del emisor al receptor de manera correcta es obligar al receptor confirmar la comunicación hasta que el emisor responda positivamente a la confirmación.

Modelo de Precisión

Su objetivo es reducir los ruidos de comunicación en una reunión de definición de requisitos. Identifica tres grupos de problemas.

Heurísticos para evitarlos

Patrones de referencia (entendimiento). Tipos

Resultados: confirmar los objetivos de la reunión.
Retroceso: verificación de una afirmación anterior.
Si: procura estimular la creatividad, creando situaciones ficticias.

Procedimientos. Son un conjunto de afirmaciones o cuestiones que permiten guiar la dirección de la entrevista y asegurar que la discusión permanezca dentro del patrón de resultados establecido. Tipos

Evidencia: ej.: ¿Cómo sabe si se obtuvo el resultado?
Relevancia: ej.: Gracias, la pregunta es buena, pero no veo la relación directa con este caso.
Punteros: procura clarificar expresiones vagas o mal definidas. Ej.: ¿Podría ser más claro? ¿Cuál es el punto?.

Heurísticos generales

Una buena figura vale 1000 palabras.
Doble tráfico en la comunicación (retroalimentación).
Evitar ruidos.
Evitar metáforas con su área de conocimiento (informática).
Procure identificar el punto de vista de su interlocutor.
Aprenda con humildad.

Análisis

Identificación de partes

Antes de la tarea de análisis es importante que sepamos como está organizado y almacenado el modelo objeto de nuestro análisis.

Muchas veces la mayoría de los problemas se encuentran en una pequeña parte del sistema.

Verificación

Su objetivo es determinar si se está construyendo el producto correcto (contra productos). La verificación se realiza entre modelos.

Si quisiéramos ser estrictos, solo podríamos entender verificación entre modelos y si es posible sin ayuda humana. En tanto vamos a considerar verificación de un análisis de modelos sin que haya una comparación directa con el Universo de Informaciones. Este análisis podría ser desempeñado tanto por el hombre como por software con reglas bien definidas.

Estrategias de Verificación

Inspecciones

Es un método de revisión de software que puede ser aplicada a la definición de requisitos.

Ventaja: Estructura de trabajo cooperativo. No usa el software sino los documentos del software, por ende se puede aplicar al DR. Las inspecciones son hechas basadas en criterios predeterminados y en un conjunto de preguntas claves.

Delta= defectos(hechos, checklist, información)

Uso de formalismos

En el uso de formalismos, donde el ingeniero de software hace el papel de un probador de teoremas, la verificación ocurre dando una posibilidad de identificar inconsistencias.

Delta = inconsistencias(hechos, información)

Reusando Dominios

Es una técnica en la cual se usan las estrategias y heurísticas de Inteligencia Artificial. Se debe tener un dominio previamente codificado. Entonces es posible verificar hechos incorrectos y hechos faltantes:

Delta = hechos incorrectos(hechos del dominio, hechos)
        U
        hechos faltantes(hechos del dominio, hechos)

Se pueden ver problemas de certeza y completitud.

Desventajas: alto costo, y complejidad.

Validación

Su objetivo también es determinar si se está construyendo el producto correcto (respecto de la intención). La validación se realiza entre el UdI y un modelo.

La validación de software, o sea la confirmación de que el producto es aquel deseado por el usuario, ocurre, normalmente, al final del ciclo de vida. A esta validación se la conoce como El test del sistema y es el test integrado de los programas del sistema por el usuario.

En nuestro caso la validación es hecha en el propio proceso de elicitación de requisitos, será una validación anterior a la propia especificación.

Estrategias de Validación

Comprobación informal

La validación o la revisión de los requisitos es básicamente una tarea de lectura de descripciones en lenguaje natural y de uso de los clientes para detectar problemas en la expresión de los requisitos, no es automatizado.

Delta = lista de errores(información, hechos)

Prototipo

La idea básica es que por el prototipo es posible validar los requisitos/especificaciones contra las expectativas el usuario.

Delta = comportamientos de los hechos(expectativas del usuario, hechos)

Usando puntos de vista

Delta = inconsistencias(hechosa, hechosb)
         U
        hechos incorrectos(hechosa, hechosb)
         U
        hechos faltantes(hechosa, hechosb)

Inspección de Requisitos

Método gerencial de reuniones que objetivan el descubrimiento de defectos en documentos.

Objetivo: verificar si el producto producido por un proceso de producción, está de acuerdo con los criterios de éxito del proceso.

Pasos

Planeamiento: define los participantes, verifica si el producto satisface los criterios de entrada.

Visión General: da la visión de contexto para todos.

Preparación: lectura de los documentos a verificar.

Inspección: Constituye el proceso de identificar errores en los documentos utilizando las listas de preguntas claves.

Consenso: elimina los defectos del método.

Acompañamiento: procura que los defectos sean realmente eliminados.

Nota: primer y último paso se hacen fuera de reuniones.

Papeles previstos para las inspecciones

Fagan: moderador, autor, codificador y tester. Muy orientados a la codificación de software.

Requisitos: el codificador se cambia por un especificador.

Una variación es usar más de un equipo en el proceso de inspecciones. Tienen un único moderador y trabajan en paralelo. Aumenta sensiblemente el número de errores detectados.

^ An abstract user tree consists of a main actor with underlying actors, which again can have underlying actors themselves.

^ Encapsulamiento del conocimiento de un área de aplicación.