lOMoARcPSD|269 057 80

INFORME DE TÉCNICAS DE ELICITACIÓN

JOSE WILMAR GRANADOS MUÑOZ

SERVICIO NACIONAL DE APRENDIZAJE SENA

FICHA: 2758547

TECNICO EN PROCESAMIENTO DE PRUEBAS DE SOFTWARE

 lOMoARcPSD|269 057 80

Introducción.

Se busca en este trabajo 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.

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
 lOMoARcPSD|269 057 80

en la solución de una gran variedad de problemas. Es un método matemático creado

paraevaluar alternativas cuando se tienen en consideración varios criterios y está basado
en elprincipio que la experiencia y el conocimiento de los actores son tan importantes
como losdatos utilizados en el proceso.
Los primeros usos del AHP fueron dados en la solución de problemas de decisión en
ambientesmulticriterio.

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.
 lOMoARcPSD|269 057 80

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 ydocumentació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.
 lOMoARcPSD|269 057 80

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?

 lOMoARcPSD|269 057 80

¿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 dela 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 sies adecuado usar JAD.
 lOMoARcPSD|269 057 80

*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.
 lOMoARcPSD|269 057 80

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
quecada 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 depersonas
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.
Evitar y disuadir cualquier forma de crítica o de debate mientras se están captura ndo las
ideas
 lOMoARcPSD|269 057 80

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.

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 quedebe 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
 lOMoARcPSD|269 057 80

10

El cuestionario, por lo general, tiene la siguiente estructura:

Título, específica a quien va dirigido el cuestionario.

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