CHAPTER 3: ADMINISTRATION AND PRACTICAL IMPLICATIONS OF THE
4.5 OVERALL CONCLUSION
2.3.1.1 Descripción del Trabajo
En [Byrd et al 1992], los autores demuestran la estrecha relación entre las actividades de análisis de requisitos y adquisición de conocimiento. Para ello, presentan un esquema de categorización basado en tres dimensiones: obstáculos de comunicación, entendimiento del dominio del problema, y control del proceso.
Para la dimensión de obstáculos de comunicación consideran tres tipos:
En: limitaciones cognitivas de los seres humanos, en este caso de los usuarios, expertos, analistas e ingenieros de conocimiento, como procesadores de información y resolutores de problemas.
Entre (dos): problemas cognitivos y falta de un lenguaje común provocan problemas entre el usuario y el analista, y entre el experto y el ingeniero.
Entre (grupo): dificultades asociadas a la necesidad de balancear los requisitos de múltiples personas que provocan competencia y choque de intereses.
Para el caso del entendimiento del dominio del problema, los autores distinguen categorías y entidades como las presentadas en la Tabla 2.2.
Finamente, para el caso del Control del proceso consideran tres tipos, dependiendo de quien controla la actividad de educción de información:
Conducido por el Usuario/Experto
Conducido por el Analista/Ingeniero de Conocimiento
Conducido por la Máquina (sistema de apoyo)
Entonces, utilizando este esquema, comparan un conjunto de técnicas de educción clasificadas en 5 tipos. La relación entre las técnicas y el esquema de categorización se presenta en las Tablas 2.3 y 2.4.
2.3.1.2 Análisis del Trabajo
El trabajo presenta un esquema teórico comparativo, basado en la intuición y experiencia de los autores, y por lo tanto, como también expresan ellos, amerita validación. El esquema considera, ampliamente, características del dominio del problema y, parcialmente, el proceso de captura, pero olvida gran cantidad de atributos relevantes de los participantes. Además, existe poca claridad de cómo determinar los valores asociados a un caso particular.
Una importante cantidad de técnicas es equiparada de acuerdo a la pertinencia para sobrellevar, soportar, o aplicar a las dimensiones del esquema. Esta pertinencia es discreta con valores binarios (Sí, No), por lo que no cabe asignaciones medias. Además, considera la pertinencia en más de un valor de los atributos, pero existe poca claridad de cómo determinar los valores asociados a un atributo en un caso
Categoría de
Dominio
Entidades de Categoría
Definición
Requisitos de Información
Análisis cabal sobre requisitos de información del dominio y sus relaciones.
Información Desplegada Los datos a ser presentados a usuarios finales.
Diseño de Interfaz El lenguaje y formato utilizado en la presentación de información desplegada
a los usuarios finales. Entendimiento
del Proceso
Análisis de la actividad del mundo real.
Especificación del Conocimiento Los hechos, reglas, creencias, algoritmos, procedimientos, etc., pertinentes al
problema.
Dificultades, Restricciones Factores que pueden afectar el desarrollo.
Justificación Explicaciones de porqué acciones específicas son o no realizadas.
Especificación de distancia Comparaciones del estado actual del problema con el estado deseado.
Entendimiento del Comportamiento
Se focaliza sobre la naturaleza dinámica de los datos y conocimiento y la necesidad de analizar y entender los eventos que impactan.
Modelos mentales Representaciones abstractas del dominio del problema mantenidas por
expertos y usuarios.
Modelos operacionales Representación abstracta de procesos de entradas/salidas asociados con el
dominio del problema. Entendimiento
Marco Problema
Entendimiento del contexto global en que el sistema está siendo desarrollado.
Especificación del Estado Meta Las metas globales a ser logradas con el sistema a implementar.
Entorno de soporte existente Descripción del entorno tecnológico existente que apoyará el sistema futuro.
Tabla 2.2. Categoría y Entidades de Dominio del Problema.
Categoría de Técnica
Técnica Origen Enfoque de
Control
Obstáculo de Comunicación
Análisis de Comportamiento Adquisición de conocimiento Usuario/Experto Entre (dos) Análisis de protocolo Adquisición de conocimiento Usuario/Experto Entre (dos) Técnicas de
Observación
Prototipado Adq. de Cto/ Análisis de Req. Analista/Ing. Cto En/Entre (dos)
Entrevista Participativa Adquisición de conocimiento Usuario/Experto Entre (dos)/Entre (grupo) Entrevista Abierta Análisis de Requisitos Usuario/Experto Entre (dos) Tormenta de Ideas Análisis de Requisitos Usuario/Experto En/Entre (grupo) Técnicas de
Educción No Estructurada
Enfoque Orientado a Metas Análisis de Requisitos Analista/Ing. Cto. En/Entre (grupo)
Scaling Multidimensional Adquisición de conocimiento Analista/Ing. Cto. Entre (dos)/Entre (grupo)
Mapeo Cognitivo Análisis de Requisitos Usuario/Experto En/Entre (dos) Técnicas de
Mapeo
Análisis de Varianza Análisis de Requisitos Analista/Ing. Cto. Entre (dos)/Entre (grupo) Máquina Inducción de Reglas Adquisición de conocimiento Máquina Entre (dos)/Entre (grupo) Análisis de textos Adquisición de conocimiento Analista/Ing. Cto. Entre (dos)
Técnicas de Análisis Formal
Emparrillado Adqu. de Cto/ Análisis de Req. Analista/Ing. Cto. En/Entre (dos) Clasificación de Conceptos Adquisición de Conocimiento Analista/Ing. Cto. En/Entre (dos)
Escenarios Adqu. de Cto/ Análisis de Req. Usuario/Experto Entre (dos)/Entre (grupo) Entrevista Estructurada Adqu. de Cto/ Análisis de Req. Analista/Ing. Cto. Entre (dos)
Factores Críticos de Éxito Análisis de Requisitos Analista/Ing. Cto. En/Entre (dos)/Entre (grupo) Técnicas
Educción Estructuradas
Análisis Futuro Análisis de Requisitos Analista/Ing. Cto. En/Entre (dos)/Entre (grupo)
Tabla 2.3. Relación Técnicas de Educción con Obstáculos de Comunicación y Control del Proceso.
Categoría de Dominio Requisitos Información
Entendimiento del proceso Entendimiento
Comportamiento Entendimiento Marco problema ENTIDAD DE DOMINIO
TECNICAS Información Desplegada Diseño de Interfaz Es
pecif ica ción Conocimiento Dificult ades , Re stricc ione s Justifica ción Es pe cif ica ción de dis tanci a Modelos ment ales
Modelos operacionales Especif
ica ción del Estado Meta Entorno de soporte existente Análisis de Comportamiento ● ● ● ● Análisis de protocolo ● ● ● ● ● Prototipado ● ● ● ● ● Entrevista Participativa ● ● ● ● Entrevista Abierta ● ● ● ● Tormenta de Ideas ● ●
Enfoque Orientado a Metas ●
Scaling Multidimensional ●
Mapeo Cognitivo ● ● ● ●
Análisis de Varianza ● ● ● ● ●
Máquina Inducción de Reglas ● ●
Análisis de textos ● ●
Emparrillado ● ●
Clasificación de Conceptos ●
Escenarios ● ● ●
Entrevista Estructurada ● ● ● ● ● ● ● ● ●
Factores Críticos de Éxito ● ● ● ●
Análisis Futuro ● ● ●
Tabla 2.4. Relación Técnicas de Educción con Categorías y Entidades del Dominio del Problema.
El esquema es simple de manipular, por lo que es posible agregar nuevos atributos y técnicas con cierta facilidad.
2.3.2 Keil y Carmel
2.3.2.1 Descripción del Trabajo
En [Keil y Carmel 1995] los autores presentan un estudio sobre las relaciones existentes entre los usuarios/clientes y los desarrolladores para obtener información de requisitos. Estas relaciones son vínculos por medio de técnicas o medios entre ellos para el intercambio de información.
El estudio se ha realizado sobre 31 proyectos de dos entornos: el primero de desarrollo de paquetes software, es decir, productos para ventas (referido en adelante
bajo contrato para uso interno (referido en adelante como Cliente). Además, en este trabajo, se entrevistaron a los jefes de proyectos para conocer su opinión sobre el uso de estas técnicas en sus proyectos.
Según la experiencia y conocimiento de los autores, la pertinencia de uso de las 15 técnicas consideradas es la que se muestra en la Tabla 2.5.
Entre los resultados destacan la correlación encontrada entre el éxito del proyecto y el uso de más cantidad de técnicas. También se ha observado en el estudio que el uso de técnicas directas (sin intermediario) se relaciona con la valoración del éxito del proyecto.
Sin embargo, el resultado más importante se refiere a la opinión de los entrevistados sobre la efectividad de las técnicas utilizadas en sus proyectos. La valoración se hizo en una escala de 1 a 5 (muy inefectiva a muy efectiva) sobre un total de 10 proyectos de Paquete y 6 proyectos de Cliente (se eligieron solo aquellos proyectos estimados exitosos). Las técnicas utilizadas en menos de 3 proyectos fueron también excluidas.
Técnica Descripción Tipo Solución
Equipo Facilitado Una sesión estructurada y facilitada con los clientes (JAD, por ejemplo) Cliente Intermediario MIS Administrador que define necesidades y metas de los clientes Cliente
Línea de Soporte Información de ayudas a clientes en problemas del día a día Cliente/Paquete Cuestionario Lista de preguntas realizadas a una muestra de clientes Cliente/Paquete Prototipo Maqueta Los clientes son expuestos a una demo, o versión temprana,
para descubrir información sobre interfaz de usuario Cliente/Paquete Prototipo Desechable Los clientes son expuestos a una demo, o versión temprana,
para descubrir requisitos del sistema Cliente/Paquete Entrevista Relación uno a uno con el usuario Cliente/Paquete Prueba Nuevos requisitos derivados de pruebas Cliente/Paquete
E-mail/Boletín Problemas, preguntas, sugerencias de clientes a través de boletín o e-mail Cliente/Paquete
Laboratorio de Usabilidad
Laboratorios especialmente construidos para registrar a los
usuarios trabajando Cliente Estudio
Observacional
Clientes son seguidos por largo periodo para conocer lo que
hace (etnografía, análisis de protocolo) Cliente Mercado y Ventas Entrevistas de representantes a (potenciales) clientes para conocer sus sugerencias y necesidades Cliente Grupo de Usuarios Reunión de grupos de usuarios para discutir uso y
mejoramiento de software Cliente
Trade Show Clientes son expuestos a maquetas o prototipos para retroalimentación Cliente/Paquete Focus Group Un pequeño grupo de usuarios y un moderador discuten estructuradamente sobre el software Cliente/Paquete
Las medias de los valores otorgados a las técnicas, son las presentadas en las Tablas 2.6 y 2.7 para cada tipo de proyectos.
Técnica
Valoración Media
Número de proyectos
Equipo Facilitado
5,0
4
Prototipo Maqueta
4,0
5
Prototipo Desechable
3,6
5
Entrevista 3,5 4
Prueba 3,0 3
Intermediario MIS
2,8
4
E-mail/Boletín 2,5
3
Tabla 2.6. Valoración Media de Efectividad de Técnicas en Proyectos Clientes.
Técnica
Valoración Media
Número de proyectos
Línea de Soporte
4,3
8
Entrevista 3,8 6
Prototipo Maqueta
3,3
3
Grupo de Usuarios
3,3
4
Prototipo Desechable
2,8
4
Prueba 2,8 6
Mercado y Ventas
2,8
9
Trade Show
2,5 4
Tabla 2.7. Valoración Media de Efectividad de Técnicas en Proyectos Paquetes.
2.3.2.2 Análisis del Trabajo
El estudio se basa en la opinión personal de los jefes de proyectos de cada desarrollo, y las conclusiones obtenidas, inductivamente, permiten comparar las técnicas de obtención de requisitos. Sin embargo, la reducida muestra utilizada resta confiabilidad y generalidad a los resultados.
Por otro lado, solamente se ha considerado un factor de influencia relacionado con el proceso de desarrollo, concretamente el dominio de solución. Ningún otro factor como características de los participantes en el proceso, del problema atacado, o de la solución desarrollada, fue tomado en cuenta como candidatos a influir en los resultados de educción.
De este factor, solo se considera, y está bien definido, el atributo relacionado con el tipo de desarrollo utilizado. No obstante, está claramente valorada la efectividad de cada técnica para cada valor de este atributo (Cliente/Paquete). El valor es único, pero subjetivo a la apreciación de cada entrevistado.
El estudio considera una importante cantidad de técnicas, pero la agregación de nuevas técnicas o nuevos atributos es difícil pues habría que volver a repetir el
2.3.3 Hudlicka
2.3.3.1 Descripción del Trabajo
En este trabajo, [Hudlicka 1996], se muestran los resultados de un estudio empírico realizado para comparar la efectividad de tres técnicas de adquisición de información indirectas.
El autor midió la cantidad de atributos obtenidos, la facilidad con que se obtuvieron y el grado de análisis e interpretación posterior requerido, al aplicar emparrillado, escala (scaling) multidimensional y clasificación (clustering) al intentar definir indicadores de inspección para la seguridad de aerolíneas, o sea, características de las operaciones de aerolíneas que están ligadas a la seguridad tales como, entrenamiento de personal, estado financiero, frecuencia de incidentes, etc.
Para ello se utilizaron 17 inspectores de la Administración de Aviación Federal de cinco regiones de EE.UU., a quienes se administraron las técnicas. En el análisis de los resultados destaca la efectividad del emparrillado, que produjo 188 atributos, por encima de la escala multidimensional, que dio 17 atributos, y clasificación, que entregó 31. Además, los atributos originados por el emparrillado contemplan los generados por las otras técnicas, y no requiere mayor análisis e interpretación posterior. De esta forma, el emparrillado demuestra su pertinencia en tareas analíticas o cognitivas. También se resalta que se observó informalmente la efectividad del emparrillado sobre técnicas directas, como las entrevistas.
2.3.3.2 Análisis del Trabajo
El resultado ratifica la efectividad del emparrillado sobre otras técnicas, especialmente en dominios de clasificación. Sin embargo, no se establece información sobre las variables supuestamente estables (información sobre las cualidades de los inspectores, los analistas, así como la duración de las sesiones), que al ser diferentes podrían influir sobre los resultados. Aunque los datos obtenidos son concluyentes, no existe análisis estadístico sobre los datos por lo que su validez es dudosa.
El experimento es válido para las condiciones especificadas y se desconoce si lo sería al agregar o al variar atributos. La diferenciación se realiza mediante la cantidad de atributos capturados pero no se analiza la utilidad de éstos.
2.3.4 Maiden y Rugg
2.3.4.1 Descripción del Trabajo
Los autores presentan en [Maiden y Rugg 1996] un marco, denominado ACRE (Acquisition Requirements), para asistir a los Ingenieros de Requisitos en la selección de métodos o técnicas para la adquisición de requisitos. Su objetivo es proveer una guía para seleccionar de entre un amplio rango de métodos con diferentes características y diferentes orígenes.
Considera 12 técnicas o métodos para la educción de requisitos de los interesados en el proyecto (stakeholders) más que para extraer requisitos de documentos. Estos métodos adquieren requisitos tanto del sistema software como del dominio y entorno de él. Las técnicas y su descripción son presentadas en la Tabla 2.8.
Para realizar la elección de la(s) técnica(s) apropiada(s), el estudio considera 6 facetas o atributos:
a.- Propósito de los Requisitos
Para proveer una especificación para diseño e implementación de un sistema a medida (Los autores indican que para este caso todas las técnicas son apropiadas).
Para facilitar la selección de paquetes comerciales (Los autores diferencias entre paquetes conocidos y desconocidos).
Para facilitar los contratos legales. b.- Tipos de conocimientos
Comportamiento.
Procesos.
Datos.
c.- Filtro interno de conocimiento (si las técnicas pueden obtener)
Dominio Conocimiento tácito Conocimiento compilado Conocimiento implícito Conocimiento no tácito Conocimiento semi-tácito Conocimiento reconocido
Conocimiento dado por hecho
Conocimiento de memoria de trabajo
Sistema Nuevo
d.- Fenómenos Observables (para aplicar las técnicas, a diferencia de actividades más bien intelectuales)
e.- Contexto de Adquisición (restricciones de las técnicas)
Se necesitan reuniones
Tiempo para preparar reuniones
Tiempo para sesión de adquisición
Tiempo para obtener requisitos
Número de ingenieros de Requisitos
Número de usuarios
Amistosidad de los usuarios
Gastos no tecnológicos
f.- Interdependencias de los métodos (relación entre los métodos o técnicas que los autores no han considerado del todo por estar incompleta)
Nombre Descripción Precondición Fortalezas Debilidades
OBSERVACION El IR observa la practica actual en el dominio
Pocas, aunque tener acceso a ciertos lugares puede ser problemático
Es simple de hacer y no requiere mucho tiempo de preparación y entrenamiento
Puede capturar gran cantidad de datos irrelevantes
ENTREVISTA ABIERTA
El IR pregunta a los usuarios sobre el dominio sin preparación alguna
Ninguna Simple de aplicar. Es buena para
obtener una agenda del usuario de lo que es relevante.
Se gasta mucho tiempo en hechos irrelevantes. La información capturada puede ser difícil de analizar
ENTREVISTA ESTRUCTURADA
El IR pregunta al usuario sobre una lista de consultas preparadas
Preguntas relevantes deben ser identificadas antes
Sistemática, constante. Variantes disponibles
Impone un marco al usuario, el que puede omitir asuntos importantes
ANALISIS DE PROTOCOLOS
Alguien emprende una tarea y la
explica en voz baja mientras la hace Tareas adecuadas deben ser identificadas Provee acceso a procesos guardados en mente. Provee gran cantidad de
datos de la tarea
Pueden ser difíciles de entender por el encadenamiento natural de ideas. Su transcripción es tediosa y consume tiempo
CARD SORT Los usuarios ordenan en grupos, un conjunto de tarjetas que tienen el nombre de una entidad del dominio y explican los motivos
Entidades adecuadas necesitan
ser identificadas El conocimiento es representado en formato estandarizado. Abierta a la
automatización. No necesita trascripción
El conocimiento educido se refiere a Objeto- atributo-valor. No hay conocimiento de clases, estructuras, procedimientos
LADDERING Se usa un pequeño conjunto de pruebas para adquirir estructuras y contenido del conocimiento del usuario
Requiere saber conocimiento
jerárquico (poli-jerarquías) El conocimiento es representado en formato estandarizado. Puede educir
conocimiento estructural. Adecuada para automatización
Asume conocimiento arreglado jerárquicamente
EMPARRILLADO Se pregunta por los atributos aplicables a un conjunto de entidades y sus valores (matriz de atributos)
Se deben identificar las entidades adecuadas
El conocimiento es representado en formato estandarizado. Abierto a la automatización. Soporta análisis estadístico
El conocimiento educido se refiere a Objeto- atributo-valor. No hay conocimiento de clases, estructuras, procedimientos. Problemas con ciertos tipos de atributos
TORMENTA DE IDEAS
El IR pide a un grupo de usuarios que generan ideas acerca del dominio, sin enfatizar en la evaluación
Adecuado para grupos de
usuarios Bueno para educir entidades de dominio de alto nivel y cuestionar
supuestos. Soporte de herramientas para algunas variantes
Forma clásica no sistemática
PROTOTIPADO RAPIDO
Se consulta al usuario sobre un prototipo del sistema deseado
Se necesita un entorno para prototipo. Se debe generar un prototipo
Bueno para coger resultados dados por hecho
La construcción toma tiempo y esfuerzo
ANALISIS DE ESCENARIOS
Es una descripción de una secuencia de acciones y eventos para un caso específico de una tarea que el sistema debe cumplir.
Se requiere generar un conjunto de escenarios relevantes
Integración con métodos estructurados tales como OOSE. Retroalimentación positiva en el proceso
Demasiado esfuerzo para los resultados
RAD WORKSHOP Reunión de trabajo en la que un grupo de individuos toman decisiones a través de consenso guiado por un moderador externo al sistema
Requiere hasta tres semanas de planificación. Existen actividades
post workshop también
Mejora calidad y rapidez del diseño del sistema. Esta integrado en métodos estructurados actuales y herramientas Case
Amarra a los usuarios por varios días. Sólo es efectivo para sistemas más pequeños
METODOS ETNOGRAFICOS
El IR observa durante largos periodos de tiempo a los usuarios en su lugar de trabajo
El IR necesita considerable entrenamiento en el uso de estos métodos
Bueno para coger resultados dados por hecho y una versión desde dentro del sistema
Consume tiempo. Puede fallar para detectar eventos infrecuentes. Posibles problemas éticos al capturar información confidencial Tabla 2.8. Características de Técnicas y Métodos Considerados en ACRE.
La equiparación de técnicas y facetas para apoyar la selección, presentada en la Tabla 2.9, se realizó sobre la base de la experiencia y conocimiento de los autores y la literatura relacionada. La utilización de la guía consiste en responder a las consultas sobre las facetas y decidir sobre los métodos a elegir. Los autores pretenden desarrollar un sistema software para soportar está guía.
Finalmente, se envió un cuestionario a expertos en requisitos que dieron su opinión sobre la utilidad de la guía, calificándola altamente en su mayoría.
2.3.4.2 Análisis del Trabajo
El marco presentado para la selección está basado sobre información de fundamento teórico de las técnicas consideradas y en la experiencia de los autores. Además, considera una cantidad significativa de técnicas conocidas para educción. Esto confiere una alta confiabilidad a la aproximación conseguida.
No obstante, la propuesta es relativamente pobre con respecto a los factores y atributos definidos, ya que no son tomadas en cuenta las características del objeto de aplicación de la técnica, es decir los usuarios, quienes parecen relevantes en el éxito del proceso de requisitos. Las facetas definen más características de las técnicas, que del entorno del sistema, por lo que necesita más conocimiento sobre ellas para elegir. Esto es poco aplicable, ya que son los factores externos los que deben perfilar las técnicas adecuadas. Por ejemplo el tiempo de preparación de sesión es muy poco relevante comparado con atributos relevantes del entorno del proceso. La mayoría de los factores son considerados en forma parcial, olvidando atributos importantes del problema.
Los atributos son considerados de igual importancia en el problema de selección y la determinación del valor de algunos atributos para un caso particular puede ser difícil y requiere un conocimiento profundo del dominio del problema. Por