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

Elicitación editar

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 editar

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 editar

Lectura de Documentos editar

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 editar

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 editar

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 editar

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 editar

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 editar

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 editar

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 editar

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 editar

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 editar

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

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 editar

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 editar

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 editar

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 editar

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

Identificación de partes editar

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 editar

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 editar

Inspecciones editar

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 editar

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 editar

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 editar

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 editar

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 editar

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 editar

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 editar

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.