Documento-Informe-de-Tecnicas-de-Elicitacion-GA1-220501092-AA2-EV01

1
Informe de Técnicas de Elicitación
2
Introducción.
Se busca en este trabajo es conocer el uso de la elicitación de requisitos, en el que se
busca la interacción de dos o más personas con técnicas, con el objetivo de encontrar y
desarrollar un tema en específico. Aquí se ve la importancia que tiene una buena comunicación
entre desarrolladores y clientes; de esta comunicación con el cliente depende que sus
necesidades queden claras. El propósito de la elicitación de requerimientos es ganar
conocimientos relevantes del problema, que se utilizan para producir una especificación formal
del software necesario para resolverlo.
3
Levantamiento de Requerimientos
Una etapa fundamental en proyectos de ingeniería de software, es la identificación y
documentación de los requerimientos del futuro sistema al comienzo del proyecto, pues en
numerosas ocasiones se ha demostrado que es cuando pueden prevenirse errores que puedan
significar el fracaso del proyecto.
En la Ingeniería de requisitos, el levantamiento de requerimientos se refiere a la identificación
y documentación de los requerimientos de un sistema, a partir de los usuarios, clientes o
interesados (Stakeholders). A la práctica también se le conoce como Recopilación de
requerimientos.
Existen diversas técnicas para realizar el Levantamiento de los requerimientos a
continuación mencionaremos algunas:
AHP (PROCESO DE ANÁLISIS JERÁRQUICO)
Fue desarrollado a finales de los 60 por Thomas Saaty, quien a partir de sus
investigaciones en el campo militar y su experiencia docente formuló una herramienta sencilla
para ayudar a las personas responsables de la toma de decisiones.
Su simplicidad y su poder han sido evidenciados en los cientos de aplicaciones en las cuales
se han obtenido importantes resultados y en la actualidad, es la base de muchos paquetes de
software diseñados para los procesos de tomas de decisiones complejas. Además, ha sido
adoptado por numerosas compañías para el soporte de los procesos de toma de decisiones
complejas e importantes.
El AHP es una metodología para estructurar, medir y sintetizar. Ha sido aplicado ampliamente
4
en la solución de una gran variedad de problemas. Es un método matemático creado para
evaluar alternativas cuando se tienen en consideración varios criterios y está basado en el
principio que la experiencia y el conocimiento de los actores son tan importantes como los
datos utilizados en el proceso.
Los primeros usos del AHP fueron dados en la solución de problemas de decisión en
ambientes multicriterio.
Entre sus principales ventajas se pueden comentar:
• Se puede analizar el efecto de los cambios en un nivel superior sobre el nivel inferior.
• Da información sobre el sistema y permite una vista panorámica de los actores, sus
objetivos y propósitos.
• Permite flexibilidad para encarar cambios en los elementos de manera que no afecten la
estructura total.
El AHP utiliza comparaciones entre pares de elementos, construyendo matrices a partir
de estas comparaciones, y usando elementos del álgebra matricial para establecer
prioridades entre los elementos de un nivel, con respecto a un elemento del nivel
inmediatamente superior.
5
CASOS DE USO
Los casos de uso se han convertido en la técnica más utilizada a nivel mundial para el
levantamiento y la comunicación clara y eficiente de los requisitos (mejor conocidos como
“requerimientos”) para el desarrollo de sistemas.
Los casos de uso son parte del Lenguaje Unificado de Modelado (UML®), que es el
estándar más importante y más ampliamente reconocido para la especificación, diagramación y
documentación de software de calidad. El UML es un estándar abierto (es decir, que no es
propiedad de una empresa en particular), y es administrado por el Object Management Group
(OMG®) con el acuerdo y participación de prácticamente todas las principales organizaciones
dedicadas al desarrollo de software.
Propósito
El diagrama de casos de uso es utilizado durante la fase de análisis de un proyecto para
identificar la funcionalidad de un sistema. Describe la interacción de las personas o dispositivos
externos con el sistema en diseño. No muestra muchos detalles, solo resume algunas
relaciones entre los casos de uso, actores y sistemas.
Uso
Básicamente se necesita incluir cuatro (4) elementos en un diagrama de casos de uso.
Ellos son los actores, sistema, casos de uso y relaciones. Los actores representan quien sea lo
que sea que interactúe con el sistema. Pueden ser humanos, otras computadoras u otros
softwares de sistemas. Los casos de uso representas las acciones que desempeña uno o más
actores para una meta particular. El sistema es lo que sea que estés desarrollando.
6
ENTREVISTAS
Según [Pressman , 2006], las entrevistas que se realizan al inicio del proyecto deben
contener preguntas “libres de contexto” divididas en tres conjuntos de preguntas. Estas
preguntas ayudan a iniciar la conversación esencial para la obtención exitosa. Sin embargo, la
sesión de preguntas y respuestas se debe usar sólo para los primeros encuentros.
El primer conjunto de preguntas se enfoca en los usuarios, otros interesados, metas generales
y en los beneficios medibles de una implementación exitosa.
Algunos ejemplos de estas preguntas son: [Pressman , 2006]
• ¿Quién usará el sistema?
• ¿Cuál será el beneficio de la solución propuesta?
• ¿Hay otra solución posible (que no sea automatizar?
El segundo conjunto de preguntas permite comprender mejor el problema y que los
usuarios expresen sus percepciones sobre una solución. Algunos ejemplos de estas preguntas
son: [Pressman , 2006]
• ¿Cómo sería un buen resultado generado por una solución exitosa?
• ¿Cuáles problemas podrían surgir con la solución propuesta?
• ¿Puede describir el ambiente en el que se usará la solución?
• ¿Qué aspectos especiales de desempeño o restricciones afectarán la forma en que se
busque la solución?
El tercer conjunto de preguntas se enfoca en la efectividad de la entrevista en sí.
Algunos ejemplos de estas preguntas son: [Pressman , 2006]
• ¿Es Usted la persona adecuada para contestar las preguntas?
7
• ¿Alguien más puede proporcionar información adicional?
• ¿Existe información adicional que desee aportar?
El éxito de las entrevistas depende del grado de conocimiento del entrevistador y
entrevistado, disposición del entrevistado de suministrar información, buena documentación de
la discusión y en definitiva de una buena relación entre las partes.
JAD
JAD es una técnica de definición de requisitos y de diseño de la interfaz de usuario,
basada en reuniones participativas entre clientes, directiva y desarrolladores. En dicha reunión
los temas a tratar se centran más en el negocio que en el asunto técnico. Lógicamente está
más orientado a proyectos de cliente (o bien sistemas a medida, como también se los conoce),
y permite recolectar requisitos eficientemente.
Hay que tener cuidado porque estas reuniones pueden hacer ver a los clientes una falsa
realidad en cuanto al progreso del proyecto o la productividad. Además, hay que prestar
especial cuidado con las estimaciones tempranas, aquellas que entrañan un mayor riesgo por
el mayor desconocimiento del sistema y que deben ofrecer una amplitud de rango mayor entre
mejor estimación y estimación pesimista.
*Para reducir tanto el tiempo como el costo de las entrevistas personales, tal vez los
analistas quieran considerar el diseño de aplicaciones conjuntas (JAD) como alternativa.
Mediante el uso de JAD los analistas pueden analizar los requerimientos humanos de
información y diseñar una interfaz de usuario con los usuarios en un ambiente de grupo. Una
evaluación cuidadosa de la cultura específica de la organización ayudará al analista a juzgar si
es adecuado usar JAD.
8
*El uso de JAD fue más efectivo en pequeños y claramente enfocados proyectos y
menos efectivo en proyectos largos y complejos.
*Al final, este proceso resultará en un nuevo Sistema de Información viable y orientado
tanto a diseñadores como a usuarios.
PROTOTIPOS
Los prototipos y los modelos son mecanismos excelentes para presentar ideas a los
usuarios porque ellos pueden ver inmediatamente algunos aspectos claves del sistema.
Mostrar los Prototipos puede provocar que el usuario brinde un mayor número de
requerimientos o cambie de idea acerca de los requerimientos existentes depurándolos.
Los prototipos también pueden ilustrar como la solución podría funcionar o dar a los
usuarios un vistazo de lo que podrían hacer con el sistema. Muchos más requerimientos salen
a la vista cuando el usuario puede comprobar los que están proponiendo.
Una presentación puede incluir un grupo de diapositivas, un concepto elaborado por un
artista o un diseñador, una presentación o una animación que brinde a los usuarios una visión
de las posibilidades del sistema. Cuando se creen prototipos de software se puede hacer una
maqueta compuesta por pantallazos enfatizados que no existe código asociado y que el
sistema aún no ha sido especificado, diseñado o desarrollado
Advertencia: Una maqueta puede crear un conjunto de expectativas difíciles de ser
cubiertas.
Estos prototipos tienen como objetivo fomentar que los usuarios mencionen
requerimiento que faltan, no se supone que se esta vendiendo una idea o un producto. Es
decir, se debe centrar la presentación en determinar lo que realmente se requiere del sistema.
9
Ver un prototipo que, invariablemente tiene problemas, en algún sentido puede ser un
estímulo para que los usuarios comiencen a decir lo que necesitan. Si ellos expresan
demasiados problemas con el prototipo es señal de que se está logrando el cometido ya que
cada problema puede conducir a un nuevo requerimiento.
LLUVIA O TORMENTAS DE IDEAS
Una tormenta de ideas es una sesión de trabajo en la que un pequeño grupo de
personas proponen ideas acerca de lo que consideren importante en el
área o tópico de interés.
Inicialmente las ideas se recogen, pero no se discute. Después de esto un facilitador
gua al grupo para que los resultados de la sesión sean organizados y priorizados.
Las siguientes reglas básicas pueden asegurar unos mejores resultados:

Comenzar declarando claramente el objetivo de la sesión de tormenta de ideas.

Generar el mayor número de ideas posible.

Permitir que la imaginación vuele.
10

Evitar y disuadir cualquier forma de crítica o de debate mientras se están captura
ndo las ideas

Después de que se hayan capturado las ideas reformularlas y combinarlas
ESCENARIOS
Son descripciones de ejemplos de las sesiones de interacción con el sistema. Inicia con
un bosquejo y durante la obtención de agregan detalles.
Un escenario incluye:

Una descripción del estado del sistema al inicio del escenario

Una descripción del flujo normal de eventos en el escenario

Una descripción de lo que puede ir mal y cómo manejarlo

Información de otras actividades que se podrían llevar al mismo tiempo

Una descripción del estado del sistema después de completar el escenario
CUESTIONARIOS
El cuestionario es una técnica de recolección de datos y está conformado por un
conjunto de preguntas escritas que el investigador administra o aplica a las personas o
unidades de análisis, a fin de obtener la información empírica necesaria para determinar los
valores o respuestas de las variables es motivo de estudio.
11
Planeamiento
El cuestionario, tanto para su elaboración como aplicación, debe considerar las
siguientes fases:

Determinación de los objetivos del cuestionario, que están referidos a obtener
información para analizar el problema motivo de la investigación.

Identificación de los variables a investigar, que orientan el tipo e información que
debe ser recolectado.

Delimitación del universo o población bajo estudio, donde será aplicado el
cuestionario; las unidades de análisis o personas que deben responder al
cuestionario; y el tamaño y tipo de muestra de unidades de análisis que permita
identificar a los informantes y al número de ellos.

Selección del tipo de cuestionario y forma de administración.

Elaboración del cuestionario como instrumento de recolección de datos.

El pre- test o prueba piloto.

Aplicación del cuestionario o trabajo de campo para la recolección de los datos.

Crítica y codificación de la información recolectada.

Plan de procesamiento y análisis estadística de la información recolectada.

Estructura o partes del cuestionario
El cuestionario, por lo general, tiene la siguiente estructura:

Título, específica a quien va dirigido el cuestionario.
12

Introducción o presentación; resume los objetivos del cuestionario, la población
bajo estudio, la institución que lleva a cabo la investigación y el carácter anónimo
y científico de la información requerida para motivar la colaboración del
informante.

Identificación del cuestionario; específica un número para cada cuestionario
aplicado, lugar y fecha de aplicación, dirección y teléfono del informante.

Estos datos son necesarios para cuando se realice el proceso de control de
calidad de la información recolectada.

Una última parte, donde se debe especificar el nombre, la dirección y el teléfono
del que aplicó el cuestionario (cuando no es auto-administrado); así como las
observaciones que este desee hacer.

En algunos estudios, en esta parte del cuestionario, también se incluyen
preguntas que deben ser respondidas por el entrevistador, cuando no ha sido
posible ubicar al informante. Estas preguntas, incluso, pueden ser respondidas
con la colaboración de terceras personas.
Tipos de cuestionario
El tipo de preguntas determina el tipo de cuestionarios.
Así, estos pueden ser:

Cuestionarios con preguntas cerradas.

Cuestionarios con preguntas abiertos.
13

Cuestionarios mixtos, que combinan preguntas cerradas con preguntas abiertas.
Este tipo de cuestionario es el más usual en la investigación social para la
recolección de datos.
Sin embargo, otros tipos de clasificación de cuestionarios estarían en función de la
forma de administrarlo (auto-administrado y administrado por terceras personas); así mismo,
los cuestionarios pueden ser simples o pre – codificados.