Técnicas de Obtencion de Requisitos (Entrevistas, Observación, Prototipos, Escenarios)

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA
Ingeniera en Sistemas Computacionales

FUNDAMENTOS DE INGENIERIA DE SOFTWARE
UNIDAD 2: INGENIERA DE REQUISITOS
Fundamentos de Ingeniera de Software.

Docente:
M.T.I Montserrat Masdefiol Surez
Grupo:
504-A
5to. Semestre
Periodo Escolar:
Agosto 2015 Enero 2016
Integrantes:
Baxn Ruiz Anglica Ruby
Cagal Mlaga Anglica Isabel
Comi Velasco Daniel
Chigo Acua Omar
Colorado Morgado Carolina
Facundo Vicente Miguel Alfredo
Molina Villanueva Carlos Arturo
Obil Ziga Oscar Praxedis
Romn Corts Elfega Denis
Temich Ferman Carolina
Lugar y Fecha:
San Andrs Tuxtla Ver. A 13 de septiembre de 2015
Pgina 1

Contenido
INTRODUCCIN................................................................................................................ 4
ENTREVISTA...................................................................................................................... 5
Pasos para la Planeacin de la Entrevista.......................................................................5
Preguntas Abiertas.......................................................................................................... 5
Preguntas Cerradas.........................................................................................................6
Sondeos.......................................................................................................................... 8
Redaccin del Informe de la Entrevista..........................................................................11
Uso de Cuestionarios.....................................................................................................11
Redaccin de Preguntas................................................................................................13
Uso de Escalas en los Cuestionarios.............................................................................16
Diseo de Cuestionarios................................................................................................19
Aplicacin de Cuestionarios...........................................................................................20
OBSERVACIN................................................................................................................ 22
Muestreo........................................................................................................................ 22
Diseo del muestreo......................................................................................................23
La decisin sobre el tamao de las muestras................................................................25
Investigacin..................................................................................................................27
Anlisis de documentos cuantitativos............................................................................27
Anlisis de los documentos cualitativos.........................................................................28
Memos........................................................................................................................... 29
Sitios Web Corporativos................................................................................................29
Manuales....................................................................................................................... 29
Manuales de Polticas....................................................................................................30
Observacin del Comportamiento del Tomador De Decisiones.....................................30
Observacin de las Actividades de Toma de Decisiones de un Gerente Tpico.............30
Observacin del Entorno Fsico.....................................................................................31
Observacin Estructurada del Entorno (STORBE)........................................................31
PROTOTIPOS...................................................................................................................36
Tipos de prototipos........................................................................................................ 36
Pgina 2

Uso de prototipos como alternativa para el SDLC.........................................................38
Desarrollo de un Prototipo.............................................................................................39
Lineamientos para desarrollar un prototipo....................................................................40
Ventajas de los prototipos..............................................................................................42
Desventajas de los prototipos........................................................................................42
El papel que desempean los usuarios en los prototipos..............................................43
ESCENARIOS...................................................................................................................45
Componentes del Escenario..........................................................................................45
Proceso de construccin de los escenarios...................................................................46
Casos de Uso................................................................................................................51
CONCLUSIN.................................................................................................................. 55
REFERENCIAS.................................................................................................................56
Pgina 3

INTRODUCCIN
Una parte esencial del proceso del desarrollo de sistemas es la ingeniera de
requisitos, sin embargo, para conocer de manera adecuada los requisitos que una
empresa tiene, es necesario realizar un conjunto de tcnicas para as, obtener la
informacin correcta sobre las necesidades, pensamientos, cualidades y datos
estadsticos de la empresa o negocio del cual se crear el software.
Al conocer de manera detallada la informacin de la empresa y de quienes
utilizarn el sistema, reconocer los requerimientos ser una tarea sencilla para el analista,
de esta forma, el sistema creado ser funcional y eficaz.
Pgina 4

ENTREVISTA
Una entrevista para recabar informacin es una conversacin dirigida con un
propsito especfico que utiliza un formato de preguntas y respuestas. En la entrevista se
necesita obtener las opiniones de los entrevistados y su parecer acerca del estado actual
del sistema, metas organizacionales, personales y procedimientos. En la entrevista se
entabla una relacin con alguien que probablemente sea un extrao para el entrevistador,
necesita establecer confianza y entendimiento rpidamente, pero al mismo tiempo debe
mantener el control de la entrevista.
Pasos para la Planeacin de la Entrevista
LEER LOS ANTECEDENTES: Leer y entender tanto como sea
posible los antecedentes de los entrevistados y su organizacin.
ESTABLECER LOS OBJETIVOS DE LA ENTREVISTA: utilice los

antecedentes que haya recopilado as como su propia experiencia para establecer
los objetivos de la entrevista.
DECIDIR A QUIEN ENTREVISTAR: Cuando tenga que decidir a

quin entrevistar, incluya a gente clave de todos los niveles que vayan a ser
afectados por el sistema de alguna manera.
PREPARAR AL ENTREVISTADO: Prepare a la persona que va a

ser entrevistada hablndole por anticipado y dndole tiempo para pensar en la
entrevista.
DECIDIR EL TIPO DE PREGUNTAS Y LA ESTRUCTURA: Escriba
que preguntas que abarquen las reas claves de la toma de decisiones que haya
descubierto al determinar los objetivos de la entrevista.
Preguntas Abiertas
En realidad, abiertas describe las opciones del entrevistado para responder. Las
respuestas pueden ser de dos palabras o dos prrafos.
Pgina 5

Las ventajas de utilizas las preguntas abiertas son muchas e incluyen las
siguientes:
Ventajas:
1.- Hacen que el entrevistado se sienta a gusto.
2.- Permiten al entrevistador entender el vocabulario del entrevistado, el cual
refleja su educacin, valores. Actitudes y creencias.
3.- Proporcionan gran cantidad de detalles.
4.-
Revelan
nuevas
lneas
de
preguntas
que
pudieron
haber
pasado
desapercibidas.
5.- Hacen ms interesante la entrevista para el entrevistado.
6.- Permiten ms espontaneidad.
7.- Facilitan la forma de expresarse al entrevistador.
8.- Son un buen recurso si el entrevistador no est preparado para la entrevista.
Desventajas:
1.- Podran dar como resultado muchos detalles irrelevantes.
2.- Posible prdida del control de la entrevista.
3.- Permiten respuestas que podran tomar ms tiempo del debido para la cantidad
til de informacin obtenida.
4.- Dan la impresin de que el entrevistador es inexperto.
5.- Podran dar la impresin de que el entrevistador anda de pesca sin un
objetivo real en la entrevista.
Preguntas Cerradas
Una pregunta cerrada limita la respuesta disponible para el entrevistado.
Pgina 6

Un tipo especial de pregunta cerrada es la pregunta bipolar. Este tipo de pregunta
limita an ms las opciones del entrevistado pues solo le permite una opcin en cada
polo, como si o no, verdadero o falso, de acuerdo o desacuerdo.
Ventajas:
1.- Ahorrar tiempo
2.- Comparar las entrevistas fcilmente.
3.- Ir al grano.
4.- Mantener el control durante la entrevista.
5.- Cubrir terreno rpidamente.
6.- Conseguir datos relevantes.
Desventajas:
1.- Aburren al entrevistado.
2.- No permiten obtener gran cantidad de detalles (debido a que el entrevistador
proporciona el marco de referencia para el entrevistado).
3.- Olvidar las ideas principales por la razn anterior.
4.- No ayudan a forjar una relacin cercana entre el entrevistador y el entrevistado.
En Calidad de Entrevistador se debe pensar Cuidadosamente los Tipos de

Pregunta que se Utilizaran.
Utilizar las preguntas abiertas y cerradas tiene sus ventajas y desventajas, como
se muestra a continuacin:
Baja
Alta
CONFIABILIDAD DE LOS DATOS
Pgina 7

Baja
USO EFICIENTE DEL TIEMPO
Alta
Baja
PRECISION DE LOS DATOS
Alta
AMPLITUD Y PROFUNDIDAD
HABILIDAD REQUERIDA DEL ENTREVISTADOR
Mucha
Poca
Mucha
Poca
Difcil
FACILIDAD DE ANALISIS
Fcil
Sondeos
Un tercer tipo de pregunta es el sondeo o seguimiento. El sondeo ms profundo es
el ms simple: la pregunta Por qu?
El propsito del sondeo es ir ms all de la respuesta inicial para conseguir mayor
significado, clarificar, obtener y ampliar la opinin del entrevistado.
Los sondeos pueden constar de preguntas abiertas o cerradas. El sondeo es
fundamental. La mayora de los entrevistadores principiantes muestran reticencia al uso
de los sondeos y, por consiguiente, aceptan respuestas superficiales. Por lo regular
agradecen que los empleados les concedan entrevistas y se sienten obligados hasta
cierto punto a aceptar cortsmente las respuestas tajantes.
Cmo Colocar Las Preguntas En Una Secuencia Lgica
As como hay dos formas generalmente reconocidas de razonamiento inductivo
y deductivo, tambin hay dos formas similares de organizar sus entrevistas. Una tercera
combina los mtodos inductivo y deductivo.
Pgina 8

Uso de una estructura de pirmide
La organizacin inductiva de preguntas de la entrevista se puede visualizar como
si se tuviera una forma de pirmide. Con base en esta forma, el entrevistador empieza
con preguntas, a menudo cerradas, muy detalladas. Posteriormente, el entrevistador
extiende los temas permitiendo preguntas abiertas y respuestas ms generalizadas.
Debe utilizar una estructura de pirmide si cree que su entrevistado necesita
motivacin para profundizar en el tema. Tambin es conveniente utilizar una estructura de
pirmide para la secuencia de las preguntas cuando desea una opinin concluyente del
tema. Tal es el caso de la pregunta final: En general, qu opina de la seguridad de los
datos versus la importancia del acceso a Internet?
Uso de una estructura de embudo

En el segundo tipo de estructura, el entrevistador adopta un mtodo deductivo al
iniciar con preguntas generales y abiertas, y luego limitar las posibles respuestas
utilizando preguntas cerradas. Esta estructura de entrevista se puede visualizar como una
forma de embudo. El uso del mtodo de estructura de embudo proporciona una forma
cmoda y sencilla de empezar una entrevista.
La secuencia de preguntas en forma de embudo tambin es til cuando el
entrevistado tiene opiniones fuertes acerca del tema y necesita libertad para expresar sus
emociones.
Pgina 9

Uso de una estructura de diamante

Con frecuencia es mejor una combinacin de las dos estructuras anteriores, lo cual
da como resultado una estructura de diamante. Esta estructura implica empezar de una
manera muy especfica, despus se examinan los aspectos generales y finalmente se
termina con una conclusin muy especfica.
El entrevistador empieza con preguntas cerradas sencillas que permiten calentar el
proceso de la entrevista. A la mitad de la entrevista, se le pide al entrevistado que d su
opinin sobre temas amplios que obviamente no tienen una respuesta correcta.
Posteriormente, el entrevistador limita de nuevo las preguntas para obtener respuestas
especficas, con lo cual propicia, tanto para l como para el entrevistado, una forma de
cerrar la entrevista. La estructura de diamante combina las fortalezas de los otros dos
mtodos, pero tiene la desventaja de tomar mucho ms tiempo que cualquiera de las
otras estructuras.
Pgina 10

Redaccin del Informe de la Entrevista

Aunque la entrevista misma haya concluido, su trabajo de anlisis de los datos de
sta apenas comienza. Necesita captar la esencia de la entrevista a travs de un informe
escrito. Es indispensable que escriba dicho informe lo ms pronto posible despus de la
entrevista. Este paso es otra forma de asegurar la calidad de los datos de la entrevista.
Cuanto ms tiempo espere para hacer el informe de su entrevista, ms dudosa ser la
calidad de sus datos.
Despus de este resumen inicial, entre en mayor detalle, registre los puntos
principales de la entrevista y sus propias opiniones. Repase el informe de la entrevista
con el entrevistado en una reunin de seguimiento. Este paso le ayuda a clarificar lo que
el entrevistado pretenda y le permite a ste saber que se est bastante interesado en
tomarse el tiempo necesario para entender sus puntos de vista y percepciones.
Uso de Cuestionarios
El uso de cuestionarios es una tcnica de recopilacin de informacin que permite
a los analistas de sistemas estudiar las actitudes, creencias, comportamiento y
caractersticas de muchas personas importantes en la organizacin que podran resultar
afectadas por los sistemas actuales y los propuestos.
Las actitudes consisten en lo que las personas de la organizacin dicen que
quieren (en un nuevo sistema, por ejemplo); las creencias son lo que las personas
realmente piensan que es verdad; el comportamiento es lo que los miembros de la
organizacin hacen, y las caractersticas son propiedades de las personas o cosas.
Es posible cuantificar las respuestas conseguidas a travs de cuestionarios
(tambin conocidos como encuestas) que usan preguntas cerradas. Si se encuesta
personas a travs de correo electrnico o la Web, se puede utilizar software para convertir
las respuestas electrnicas directamente a tablas de datos para anlisis mediante una
aplicacin de hoja de clculo o paquetes de software estadsticos.
Pgina 11

Las respuestas a cuestionarios que utilizan preguntas abiertas se analizan e
interpretan de otras maneras. La redaccin que utilice el analista de sistemas influye en
las respuestas a preguntas sobre actitudes y creencias.
Al usar cuestionarios, el analista podra estar buscando cuantificar lo que se haya
descubierto en las entrevistas. Adems, stos podran usarse para determinar qu tan
extendido o limitado es en realidad un sentimiento expresado en una entrevista. Por otra
parte, los cuestionarios se pueden usar para encuestar a una muestra considerable de
usuarios de sistemas con el fin de detectar problemas o poner de manifiesto cuestiones
importantes antes de que se realicen las entrevistas.
Hay muchas similitudes entre las entrevistas y los cuestionarios, y quiz lo ideal
sera usarlas en conjunto, ya sea dando seguimiento en una entrevista a las respuestas
confusas del cuestionario o diseando los cuestionarios con base en lo que se descubra
en las entrevistas.
Sin embargo, cada tcnica tiene sus propias funciones especficas, y no siempre
es necesario o conveniente utilizarlas en combinacin.
Planeacin del Uso de Cuestionarios
A primera vista los cuestionarios podran parecer una manera rpida de recopilar
grandes cantidades de datos sobre la opinin que los usuarios tienen del sistema actual,
sobre los problemas que experimentan con su trabajo y sobre lo que la gente espera de
un sistema nuevo o uno modificado. Aunque es cierto que se puede recopilar mucha
informacin a travs de los cuestionarios sin invertir tiempo en las entrevistas cara a cara,
el desarrollo de un cuestionario til implica una considerable cantidad de tiempo de
planeacin. Cuando el analista decide encuestar a los usuarios por medio del correo
electrnico o la Web, enfrenta aspectos de planeacin adicionales acerca de la
confidencialidad, la autenticacin de identidad y problemas de mltiples respuestas.
Lo primero que se debe decidir es qu fines persigue al utilizar una encuesta. Por
ejemplo, si se desea saber qu porcentaje de usuarios prefiere una pgina de preguntas
frecuentes (FAQ) como un medio de aprender aspectos sobre nuevos paquetes de
Pgina 12

software, un cuestionario podra ser la tcnica correcta. En cambio, si lo que desea es un
anlisis profundo del proceso de toma de decisiones de un gerente, una entrevista es una
mejor opcin.
A continuacin se mencionan algunas directrices que pueden servir para decidir si
es apropiado el uso de cuestionarios.
1. Las personas que se necesita encuestar se encuentran en ubicaciones
dispersas (diferentes instalaciones de la misma corporacin).
2. Una gran cantidad de personas est involucrada en el proyecto de sistemas, y
es importante saber qu proporcin de un grupo dado (por ejemplo, los directivos)
aprueba o desaprueba una caracterstica especfica del sistema propuesto.
3. Est haciendo un estudio preliminar y desea medir la opinin general antes de
que se determine el rumbo que tomar el proyecto de sistemas.
4. Desea tener la certeza de que en las entrevistas de seguimiento se identificar y
abordar cualquier problema relacionado con el sistema actual.
Una vez que se haya determinado que hay buenos motivos para usar un
cuestionario y que se haya precisado los objetivos que se cumplirn por medio de ste, se
puede proceder a elaborar las preguntas.
Redaccin de Preguntas
La diferencia ms importante entre las preguntas que se utilizan para la mayora
de las entrevistas y aquellas usadas en los cuestionarios es que las entrevistas permiten
la interaccin entre las preguntas y sus significados. En una entrevista el analista tiene la
oportunidad de refinar una pregunta, definir un trmino confuso, cambiar el curso de las
preguntas, responder a una mirada desconcertada y controlar generalmente el contexto.
En un cuestionario slo se pueden aprovechar algunas de estas oportunidades.
Por lo tanto, para el analista, las preguntas deben tener suficiente claridad, el flujo del
cuestionario debe ser convincente, las preguntas de los encuestados deben anticiparse y
la aplicacin del cuestionario debe planearse en detalle.
Pgina 13

Los tipos bsicos de preguntas que se utilizan en los cuestionarios son las abiertas
y las cerradas, al igual que en las entrevistas. Debido a las limitaciones propias de los
cuestionarios, se justifica una explicacin adicional de los tipos de preguntas de stos.
Preguntas abiertas
Recordando que las preguntas abiertas son aquellas que dejan abiertas al
encuestado todas las posibles opciones de respuesta.
Por ejemplo, las preguntas abiertas en un cuestionario podran ser: Describa los
problemas que est experimentando actualmente con la impresin de informes o En su
opinin, qu tan tiles son los manuales de usuario para el paquete de contabilidad del
sistema actual?
Cuando redacte preguntas abiertas para un cuestionario, anticipe qu tipo de
respuesta obtendr. Por ejemplo, si hace la pregunta Qu piensa del sistema?, las
respuestas podran ser demasiado amplias para interpretarlas o compararlas con
precisin. En consecuencia, aun cuando se redacte una pregunta abierta, debe ser
suficientemente especfica para guiar al encuestado a responder de una manera
particular.
Las preguntas abiertas son particularmente adecuadas para situaciones en que se
desea descubrir las opiniones de miembros de la organizacin sobre algn aspecto del
sistema, ya sea un producto o un proceso. En estos casos, en los que es imposible listar
eficazmente todas las posibles respuestas a una pregunta, se podra recurrir a las
preguntas abiertas.
Preguntas cerradas
Hay que recordar que las preguntas cerradas son aquellas que limitan o cierran las
opciones de respuesta disponibles para el encuestado. Por ejemplo, el enunciado de la
pregunta Abajo se muestran los seis paquetes de software disponibles actualmente en el
Centro de Informacin. Por favor marque el paquete que use con ms frecuencia, es
cerrado. Se observa que no se pregunta a los encuestados por qu prefieren el paquete,
ni se les pide que seleccionen ms de uno, aun cuando sta sea una respuesta ms
representativa.
Pgina 14

Las preguntas cerradas deben usarse cuando el analista de sistemas puede listar
eficazmente todas las posibles respuestas a la pregunta y cuando todas las respuestas
listadas son mutuamente excluyentes, es decir, que al elegir una se impida la eleccin de
cualquiera de las dems.
Se recomienda el uso de preguntas cerradas cuando se desea encuestar a una
muestra considerable de personas. La razn es obvia cuando se empieza a imaginar la
apariencia que tendrn los datos que recopilar. Si se utiliza slo preguntas abiertas para
centenares de personas, el anlisis y la interpretacin correctos de sus respuestas se
vuelve imposible sin la ayuda de un programa computarizado de anlisis de contenido.
Hay ventajas y desventajas involucradas en la eleccin de las preguntas abiertas o
cerradas que se usan en los cuestionarios. Las respuestas a las preguntas abiertas
pueden ayudar a los analistas a obtener una alta comprensin preliminar, as como una
alta amplitud y profundidad, sobre un tema. Aunque la redaccin de las preguntas abiertas
es sencilla, sus respuestas son difciles y su anlisis toma mucho tiempo.
La eleccin del vocabulario
Al igual que ocurre en las entrevistas, el lenguaje de los cuestionarios es un
aspecto muy importante para su eficacia. Aun cuando el analista de sistemas tenga un
conjunto establecido de preguntas acerca del desarrollo de sistemas, es conveniente que
las redacte en tal forma que reflejen la propia terminologa del negocio.
Los encuestados aprecian el esfuerzo de alguien que se toma el tiempo para
redactar un cuestionario que refleje la manera en que ellos usan el lenguaje. Por ejemplo,
si en el negocio se emplea el trmino supervisores en lugar de gerentes, o unidades en
vez de departamentos, al incorporar estos trminos en el cuestionario facilita a los
encuestados que los asocien con el significado de las preguntas. De esta manera, la
interpretacin precisa de las respuestas ser ms sencilla y los encuestados se
mostrarn, en general, ms entusiasmados.
Para verificar si el lenguaje usado en el cuestionario es similar al de los
encuestados, hay que hacer algunas preguntas de ejemplo en un grupo piloto (grupo de
prueba). Hay que pedirles que pongan especial atencin en el buen uso de la redaccin y
que cambien cualquier palabra que consideren inapropiada.
Pgina 15

A continuacin se mencionan algunos lineamientos tiles para la eleccin del
lenguaje del cuestionario:
1. Usar el lenguaje de los encuestados siempre que sea posible. Utilizar una
redaccin sencilla.
2. Esforzarse por ser especfico en lugar de divagar en la redaccin. Tambin
evitar las preguntas demasiado especficas.
3. Hacer preguntas breves.
4. No ser condescendiente con los encuestados ni subestimarlos con opciones de
lenguaje de bajo nivel.
5. Evitar la parcialidad en la redaccin. Evitar la parcialidad implica tambin evitar
preguntas ofensivas.
6. Dirigir las preguntas a los encuestados adecuados (es decir, aquellos que las
puedan responder). No dar por sentado que stos tendrn demasiado conocimiento.
7. Asegurarse de que el aspecto tcnico de las preguntas es preciso antes de
incluirlas.
8. Usar software para verificar que el nivel de redaccin de las preguntas sea
apropiado para los encuestados.
Uso de Escalas en los Cuestionarios

El escalamiento es el proceso consistente en asignar nmeros u otros smbolos a
un atributo o caracterstica con propsitos de medicin. Las escalas son a menudo
arbitrarias y en algunos casos no son nicas. Por ejemplo, la temperatura se mide de
varias maneras; los dos ms comunes son la escala Fahrenheit (donde el punto de
congelamiento del agua ocurre a 32 grados y el de ebullicin a 212 grados) y la escala
Celsius (donde el punto de congelamiento ocurre a 0 grados y el de ebullicin a 100
grados).
Pgina 16

Medicin
Por lo general, los analistas de sistemas utilizan dos diferentes formas de escalas
de medicin:
1. las escalas nominales y
2. las escalas de intervalos.
Las escalas nominales se utilizan para clasificar cosas. Una pregunta como:
Qu tipo de software usa ms?
1 = Un procesador de texto
2 = Una hoja de clculo
3 = Una base de datos
4 = Un programa de correo electrnico
Se vale de una escala nominal. Obviamente, las escalas nominales son las formas
de medicin ms dbiles. Por lo general, todo lo que el analista puede hacer con ellas es
obtener los totales para cada clasificacin.
Las escalas de intervalos poseen la caracterstica de que los intervalos entre cada
uno de los nmeros son iguales. Debido a esta caracterstica pueden realizarse
operaciones matemticas en los datos del cuestionario, lo cual da lugar a un anlisis ms
completo. Las escalas Fahrenheit y Celsius, que miden la temperatura, son ejemplos de
escalas de intervalos.
Validez y confiabilidad
Hay dos medidas de desempeo en la construccin de escalas: la validez y la
confiabilidad. El analista de sistemas debe estar consciente de estas medidas.
La validez es el grado en que la pregunta mide lo que el analista pretende medir.
Por ejemplo, si el propsito del cuestionario es determinar si la organizacin est lista
para un cambio trascendental en las operaciones por computadora, las preguntas miden
ese aspecto?
Pgina 17

La confiabilidad mide la consistencia. Si el cuestionario se aplica una vez y a
continuacin se aplica nuevamente bajo las mismas circunstancias y en ambos casos se
obtienen los mismos resultados, se dice que el instrumento tiene consistencia externa. Si
el cuestionario contiene apartados y stos tienen resultados equivalentes, se dice que el
instrumento tiene consistencia interna. Ambos tipos de consistencia, la externa y la
interna, son importantes.
Construccin de escalas
La construccin real de escalas es una tarea seria. La construccin negligente de
escalas puede originar alguno de los siguientes problemas:
1. Condescendencia.
2. Tendencia central.
3. Efecto de halo.
La condescendencia es un problema causado por encuestados que califican a la
ligera. Un analista de sistemas puede evitar el problema de la condescendencia moviendo
la categora promedio a la izquierda (o derecha) del centro.
La tendencia central es un problema que ocurre cuando los encuestados califican
todo como promedio. El analista puede mejorar la escala (1) haciendo ms pequeas las
diferencias en los dos extremos, (2) ajustando la fuerza de los descriptores o (3) creando
una escala con ms puntos.
El efecto de halo es un problema que surge cuando la impresin que se genera en
una pregunta influye en la prxima pregunta. Por ejemplo, si se est evaluando a un
empleado sobre quien tiene una impresin muy favorable, podra darle una calificacin
alta en cada categora o caracterstica, sin tomar en cuenta si es un punto fuerte del
empleado. La solucin es poner una caracterstica y varios empleados en cada pgina, en
lugar de un empleado y varias caractersticas en una pgina.
Pgina 18

Diseo de Cuestionarios
Muchos de los mismos principios que se aplican al diseo de formularios para la
captura de datos tambin son importantes aqu. A pesar de que el propsito de un
cuestionario es recopilar informacin sobre actitudes, creencias, comportamiento y
caractersticas cuyo impacto puede alterar sustancialmente el trabajo de los usuarios, los
encuestados no siempre muestran inters en responder. Hay que recordar que, en
conjunto, los miembros de una organizacin a menudo reciben demasiadas encuestas,
muchas de las cuales estn mal planteadas y son triviales.
Un cuestionario bien diseado puede ayudar a superar parte de esta reticencia a
responder. A continuacin se mencionan algunas reglas para disear un buen
cuestionario:
1. Dejar bastante espacio en blanco.
2. Proporcionar suficiente espacio para escribir las respuestas.
3. Facilitar a los encuestados que marquen con claridad sus respuestas.
4. Mantener un estilo consistente.
Cuando se diseen cuestionarios para la Web, hay que aplicar las mismas reglas
que se utilicen al disear cuestionarios impresos. La mayora de los paquetes de software
permiten insertar alguno de los formatos de captura de datos ms comunes que se
muestran en la siguiente figura.
Pgina 19

Las cuatro reglas anteriores deben ayudar a conseguir una mejor tasa de
respuestas al cuestionario.
El orden de las preguntas
No hay una manera de ordenar las preguntas del cuestionario que se considere
como la mejor. Una vez ms, conforme se ordenen las preguntas, hay que pensar en los
objetivos que persigue el cuestionario y a continuacin, determinar la funcin de cada
pregunta en la consecucin de sus objetivos. Tambin es importante considerar el
cuestionario desde el punto de vista del encuestado. Algunos lineamientos para ordenar
las preguntas son:
1. Colocar primero las preguntas ms importantes para los encuestados.
2. Agrupar los elementos de contenido similar.
3. Incorporar primero las preguntas menos polmicas.
Es necesario que los encuestados se sientan lo ms cmodos e interesados
posibles con las preguntas que les haga, sin que los abrume algn tema en particular.
Aplicacin de Cuestionarios
Encuestados
La decisin sobre quin recibir el cuestionario se toma en conjunto con la tarea
de establecer los objetivos que se persiguen con los resultados del mismo. El muestreo,
ayuda al analista de sistemas a determinar la clase de representacin que se necesita y el
tipo de encuestados que deben recibir el cuestionario.
Los destinatarios a menudo son escogidos como representativos debido a su
jerarqua, tiempo de servicio en la compaa, deberes, o inters especial en el sistema
actual o propuesto. Hay que asegurarse de incluir suficientes encuestados para conseguir
una muestra razonable en caso de que algunos cuestionarios no sean devueltos o
algunas hojas de respuestas sean completadas incorrectamente y tengan que
desecharse.
Pgina 20

Mtodos para aplicar el cuestionario
El analista de sistemas tiene varias opciones para aplicar el cuestionario, y el
mtodo de administracin es a menudo determinado por el estado de la empresa. Entre
las opciones para aplicar el cuestionario se encuentran las siguientes:
1. Citar al mismo tiempo a todos los encuestados.
2. Entregar personalmente los cuestionarios en blanco y recogerlos cuando estn
terminados.
3. Permitir a los encuestados que llenen el cuestionario por s mismos en su
trabajo y que lo dejen en una caja colocada en algn punto central.
4. Mandar por correo los cuestionarios a los empleados de las sucursales e
indicarles una fecha lmite, instrucciones y enviarles sobres con envo prepagado para
que devuelvan los cuestionarios llenos.
5. Aplicar el cuestionario a travs de correo electrnico o la Web.
La aplicacin electrnica del cuestionario, va el correo electrnico o colocado en
la Web, constituye una manera de llegar rpidamente a los usuarios actuales del sistema.
Los costos de duplicacin son mnimos. Adems, el encuestado puede responder cuando
lo prefiera y sus respuestas se pueden recopilar automticamente y almacenar por
medios electrnicos. Algunos tipos de software permiten al encuestado empezar a
responder una encuesta, guardar sus respuestas y regresar a terminarlas si tuvo que
interrumpir el proceso. Es posible enviar recordatorios a los encuestados, a travs de
correo electrnico, de manera fcil y econmica, al igual que notificaciones al analista con
la fecha en que el encuestado haya abierto el mensaje de correo electrnico. Algunos
tipos de software ya convierten los datos del correo electrnico en tablas de datos que se
utilizan en software de hoja de clculo o de anlisis estadstico.
Los estudios muestran que los encuestados tienen disposicin para responder
preguntas a travs de Internet sobre temas muy delicados. As, preguntas que sera muy
difcil plantear en persona acerca de problemas de sistemas podran responderse
fcilmente a travs de una encuesta en la Web.
Pgina 21

OBSERVACIN
Hay mtodos discretos como el muestreo, la investigacin y la observacin del
comportamiento del encargado de las decisiones y su interaccin con su entorno fsico
Los mtodos discretos se consideran insuficientes para recopilar informacin
cuando se utilizan por s solos, por lo que deben utilizarse junto con uno o varios de los
mtodos interactivos. A esto se le conoce como metodologa mixta. Utilizar mtodos
interactivos y discretos para acercarse a la organizacin es una prctica inteligente
mediante la cual podr formarse un panorama ms completo de los requerimientos
humanos de informacin.
Muestreo
El muestreo es el proceso de seleccionar sistemticamente elementos
representativos de una poblacin. Cuando se examinan con detalle estos elementos
seleccionados, se asume que el anlisis revela informacin til sobre la poblacin en
general. El analista de sistemas debe decidir con respecto a dos cuestiones clave. En
primer lugar hay muchos informes, formularios, documentos de resultados, memos y sitios
Web que las personas en la organizacin han generado. A cules de ellos debe el
analista poner atencin y cules debe ignorar?
En segundo lugar A quines debera entrevistar el analista de sistemas?, de
quienes debera buscar informacin por medio de cuestionarios?, a quienes debera
observar en el proceso de llevar a cabo sus roles de toma de decisiones?
La necesidad del muestreo
Un analista de sistemas debe seleccionar una muestra representativa de datos
para examinarlos o de personas representativas para entrevistarlas, interrogarlas u
observarlas por varias razones:
1. Contener los costos.
2. Agilizar el proceso de recopilacin de datos.
3. Mejorar la efectividad.
Pgina 22

4. Reducir la predisposicin
El muestreo ayuda a acelerar el proceso de recoleccin de informacin mediante
la recopilacin de datos seleccionados, en vez de recopilar todos los datos de toda la
poblacin. Adems, el analista de sistemas se evita la molestia de tener que analizar los
datos de toda la poblacin.
La efectividad en la recopilacin de los datos tambin es un factor importante. El
muestreo ayuda a mejorar la efectividad si se permite obtener informacin ms precisa
Adems, si se entrevista a menos personas, el analista tendr tiempo para dar
seguimiento a la informacin incompleta o faltante, con lo cual se mejorar la efectividad
de la recopilacin de datos. Por ltimo, el muestreo permite reducir la predisposicin
durante el proceso de recopilacin de datos.
Cuando el analista de sistemas pide una opinin sobre una caracterstica
permanente del sistema de informacin instalado, el ejecutivo tal vez provea una
evaluacin predispuesta, ya que hay poca probabilidad de cambiar esa caracterstica.
Diseo del muestreo

Un analista de sistemas debe seguir cuatro pasos para disear una buena
muestra:
Determinar los Datos a Recolectar o Describir
El analista de sistemas necesita elaborar un plan realista en cuanto a lo que debe
hacer con los datos despus de recolectarlos. Si se recopilan datos irrelevantes se
desperdicia tiempo y dinero en la recoleccin, el almacenamiento y el anlisis de datos
intiles. Los deberes y responsabilidades del analista de sistemas en esta etapa consisten
en identificar las variables, atributos y elementos de datos asociados a recopilar en la
muestra. Hay que considerar los objetivos del estudio, as como el tipo de mtodo de
recopilacin de datos (investigacin, entrevistas, cuestionarios, observacin) a utilizar.
Determinar la Poblacin a Muestrear
Pgina 23

El analista de sistemas debe determinar cul es la poblacin; en caso de
muestrear datos rigurosos, necesita decidir, por ejemplo, si basta con los ltimos dos
meses o si se requiere todo un ao de informes para el anlisis. De manera similar, al
decidir a quin va a entrevistar, el analista de sistemas tiene que determinar si la
poblacin incluir uno o todos los niveles de la organizacin, o incluso si debe considerar
a clientes, distribuidores, proveedores o competidores.
Elegir el Tipo de Muestra
El analista de sistemas puede usar uno de cuatro tipos principales de muestras: de
conveniencia, intencionada, simple y compleja. Las de conveniencia son muestras sin
restricciones ni probabilidades.
El analista de sistemas puede elegir un grupo de individuos que parezcan expertos

y estn interesados en el nuevo sistema de informacin. Aqu, el muestreo se basa en los
criterios de conocimiento e inters sobre el nuevo sistema, pero de todas formas es un
muestreo sin probabilidad. Por ende, el muestreo intencionado es confiable slo en un
nivel
moderado.
Si
elige
realizar
un
muestreo
aleatorio
simple,
necesita
obtener una lista numerada de la poblacin para asegurar que cada documento o persona
en la poblacin tenga la misma probabilidad de ser seleccionada. A menudo este paso no
es prctico, en especial cuando el muestreo involucra documentos e informes. Las
muestras aleatorias complejas ms apropiadas para el analista de sistemas se obtienen
mediante 1) muestreo sistemtico, 2) muestreo estratificado y 3) muestreo de
conglomerados.
El muestreo estratificado tal vez sea el ms importante para el analista de
sistemas. La estratificacin es el proceso de identificar subpoblaciones o estratos, para
despus seleccionar objetos o personas con los que se realicen muestras de estas
Pgina 24

subpoblaciones.
A menudo,
la
estratificacin
es
esencial
si
el
analista
vieran
el
mundo
de
sistemas desea recopilar datos con eficiencia

Decidir sobre el tamao de la Muestra
En definitiva, si todos en la poblacin
de
la
misma forma, o si cada uno de los documentos de una poblacin tuviera exactamente la
misma informacin que cualquier otro, sera suficiente una muestra con tamao de uno.
Como no es as, es necesario establecer un tamao de muestra mayor, pero menor que el
de la poblacin.
La decisin sobre el tamao de las muestras

A menudo, el tamao de las muestras depende del costo o el tiempo requerido por
el analista de sistemas, o incluso del tiempo disponible de las personas en la
organizacin. Hay que tener en cuenta varios lineamientos para determinar el tamao de
muestra requerido en condiciones ideales; por ejemplo, para determinar el porcentaje de
formas de entrada que contienen errores, o qu proporcin de personas hay que
entrevistar.
Para definir el tamao de muestra requerido, el analista de sistemas debe seguir
siete pasos, algunos de los cuales implican juicios subjetivos:
1. Determinar el atributo (en este caso, el tipo de errores a buscar).
2. Localizar la base de datos o los informes en los que se pueda encontrar el
atributo.
3. Examinar el atributo. Estimar p, la proporcin de la poblacin que cuenta con el
atributo.
4. Tomar la decisin subjetiva en relacin con la estimacin del intervalo aceptable,
i.
5. Elegir el nivel de confianza y buscar el coeficiente de confianza (valor z) en una
tabla.
6. Calcular
p , el error estndar de la proporcin, de la siguiente manera:
Pgina 25

p=
i
z
7. Determinar el tamao de muestra necesario, n, mediante la siguiente frmula:
n=
p(1p)
+1
2p
Desde luego, el primer paso es determinar el atributo a muestrear; despus se

puede averiguar dnde se almacenan estos datos: una base de datos, un formulario, un
informe, etctera.
Es importante estimar p, la proporcin de la poblacin que tiene el atributo, para
establecer el tamao de muestra apropiado. Muchos libros de texto sobre anlisis de
sistemas sugieren utilizar un heurstico de 0.25 para p (1 - p).
Este valor casi siempre produce muestra de tamao mayor que el necesario, ya
que 0.25 es el valor mximo de p(1 - p), que ocurre slo cuando p = 0.50. Cuando p =
0.10, como es ms comnmente el caso, p (1 - p) se convierte en 0.09, con lo cual se
obtiene un tamao de muestra mucho menor.
Los pasos 4 y 5 implican decisiones subjetivas. La estimacin de intervalo
aceptable de 10 significa que est dispuesto a aceptar un error de no ms de 0.10 en
cualquier
direccin
de
la
proporcin
actual,
p.
El
nivel
de
confianza es el grado deseado de certidumbre; por ejemplo, del 95 por ciento. Una vez
elegido el nivel de confianza, puede buscar el coeficiente de confianza (tambin conocido
como valor z) en una tabla.
Los pasos 6 y 7 completan el proceso al recibir los parmetros de los pasos 3 al 5
e introducirlos en dos ecuaciones para resolver el tamao de muestra requerido.
Determinacin del Tamao de las Muestras para Entrevistas
No hay frmulas mgicas para ayudar al analista de sistemas a establecer el
tamao de la muestra para entrevistas; la variable primordial en este caso es
Pgina 26

el tiempo que tarda una entrevista. Una entrevista profunda y una de seguimiento
consumen mucho tiempo, tanto del entrevistador como del participante.
Una buena regla general es entrevistar a por lo menos tres personas en todos los
niveles de la organizacin, y a por lo menos una de cada una de las reas funcionales
que trabajen directamente con un sistema nuevo o actualizado. Recordando tambin que
no es necesario entrevistar a ms personas slo porque se trate de una empresa ms
grande. Si el muestreo estratificado se lleva a cabo en forma apropiada, pocos
individuos representarn de manera adecuada a toda la organizacin.
Investigacin
Investigar es descubrir y analizar informacin. A medida que el analista de
sistemas trabaja para entender a los usuarios, su organizacin y sus requerimientos de
informacin, debe examinar los distintos tipos de datos duros que ofrecen informacin
no disponible por cualquier otro medio de recopilacin. Estos datos revelan dnde ha
estado la organizacin y hacia dnde creen sus miembros que se dirige. Para formarse
una imagen precisa, el analista necesita examinar datos tanto cuantitativos como
cualitativos.
Anlisis de documentos cuantitativos

Hay muchos documentos cuantitativos disponibles para su interpretacin en
cualquier empresa: informes empleados para la toma de decisiones, informes de
rendimiento,
registros
variados
tipos
de
formularios.
Todos
estos documentos tienen un propsito y una audiencia especficos.

Informes para la toma de Decisiones
El analista de sistemas requiere acceso a algunos de los documentos
utilizados para dirigir la empresa.
Consisten en informes sobre el estado del inventario, las ventas o la
produccin. Muchos de ellos son simples y su funcin es dar apoyo a una accin rpida.
Un informe de ventas puede sintetizar la cantidad que se vendi y el tipo de
ventas. Adems, los informes de ventas podran incluir resultados grficos para comparar
los
ingresos
las
entradas
durante
ciertos
periodos.
Dichos
informes
Pgina 27

permiten que el encargado de tomar las decisiones reconozca fcilmente las tendencias.
Los informes de produccin incluyen los costos recientes, el inventario actual, la mano de
obra reciente y la informacin de la planta.
Adems de estos informes clave, los encargados de tomar las decisiones utilizan
muchos informes sintetizados para proveer informacin de apoyo, detectar las
excepciones a las ocurrencias normales y obtener vistas generales estratgicas de los
planes de la organizacin.
Informes de Rendimiento
La mayora de los informes de rendimiento consisten en una comparacin entre el
rendimiento actual y el esperado. Una funcin importante de ellos es medir la brecha entre
el rendimiento actual y el esperado. Tambin es importante poder determinar si ese hueco
se est ensanchando o estrechando como una tendencia general en cualquier
rendimiento en evaluacin.
Registros
Los registros proveen actualizaciones peridicas de lo que ocurre en la empresa.
Si el encargado del registro es cuidadoso y lo actualiza en forma oportuna, puede proveer
mucha informacin til para el analista. Hay varias formas en que el analista puede
inspeccionar un registro, muchas de las cuales son indicativas de su capacidad
de uso:
1. Revisar errores en montos y totales.
2. Buscar oportunidades para mejorar el diseo de los formularios de registro.
3. Observar el nmero y tipo de transacciones.
4. Estar al tanto de los casos en los que la computadora pueda simplificar el
trabajo (por ejemplo, los clculos y otras formas de manipular los datos).
Anlisis de los documentos cualitativos

Los
documentos
cualitativos
incluyen
mensajes
de
correo
electrnico,
memorandos, anuncios en tableros y reas de trabajo, pginas Web, manuales de

procedimientos y de polticas. Muchos de estos documentos contienen gran cantidad de
detalles que revelan las expectativas de los autores con respecto al comportamiento de
Pgina 28

los dems, junto con las formas en que los usuarios esperan interactuar con las
tecnologas de informacin. A continuacin se muestran algunos lineamientos que pueden
ayudar a los analistas a seguir un enfoque sistemtico:
1.- Examinar los documentos en busca de metforas clave o que sirvan como
gua.
2.- Buscar discrepancias entre internos contra externos o una mentalidad del tipo
nosotros contra ellos.
3.- Hacer una lista de los trminos que caractericen el bien o el mal y que
aparezcan varias veces en los documentos.
4.- Buscar el uso de mensajes y grficos significativos que se publiquen en reas
comunes o en pginas Web.
5.- Reconocer un sentido del humor, si es que lo hay.
El proceso de examinar documentos en busca de metforas clave o de gua se
lleva a cabo debido a que el lenguaje da forma al comportamiento; por ende, las
metforas que se emplean son imprescindibles.
Memos
El analista debe considerar quin enva los memos y quin los recibe. Por lo
general, en una organizacin, la mayor parte de la informacin fluye hacia abajo y en
sentido horizontal, en vez de hacerlo hacia arriba, por lo que se envan muchos mensajes
por medio de los sistemas de correo electrnico a grupos de trabajo e individuos. Los
memos revelan un dilogo activo y continuo en la organizacin. El anlisis del contenido
de los memos le proveer una clara idea de los valores, posturas y creencias de los
miembros de la organizacin.
Sitios Web Corporativos

El analista tambin debe examinar los sitios Web que se utilizan para el comercio
de negocio a consumidor (B2C), as como los que se utilizan para las transacciones de
negocio a negocio (B2B).
Pgina 29

Manuales
Los manuales de la organizacin son otros documentos cualitativos que el analista
debe examinar.
Entre stos se incluyen los manuales para los procedimientos de operacin del
equipo de cmputo y los manuales en lnea. Hay que analizar los manuales con base en
los cinco lineamientos mencionados anteriormente. Recordando que los manuales
presentan lo ideal, la forma en que se espera que se comporten las mquinas y las
personas.
Manuales de Polticas
El ltimo tipo de documento cualitativo que se puede considerar es el manual de
polticas.
Aunque
por
lo
general
estos
documentos
abarcan
amplias
reas
de
comportamiento de los empleados y la empresa, se debe enfocar principalmente en

aquellos que traten sobre las polticas relacionadas con los servicios de cmputo, su uso,
acceso, seguridad y cuotas.
Al examinar las polticas, el analista de sistemas puede obtener una buena idea de
los valores, posturas y creencias que guan a la empresa.
Observacin del Comportamiento del Tomador De Decisiones.

La observacin del tomador de decisiones y su entorno son mtodos no intrusivos
importantes para el analista de sistemas. Al observar las actividades del tomador de
decisiones, el analista busca darse una idea de lo que realmente se hace, no solo de lo
que se documenta o explica, el analista trata de ver personalmente las relaciones que
existen entre el tomador de decisiones y los dems miembros de la organizacin.
Observacin de las Actividades de Toma de Decisiones de un Gerente

Tpico.
El analista de sistemas se vale de entrevistas y cuestionarios interactivos para
entender adecuadamente la manera en que los gerentes describen su trabajo. Sin
embargo la observacin permite al analista ver personalmente la manera en que un
gerente recopila, procesa, comparte y usa la informacin para realizar su trabajo.
Se sugiere que los analistas de sistemas usen un mtodo humanstico para
describir lo que hacen los gerentes, este mtodo se conoce como el guion del analista. En
Pgina 30

esta tcnica el actor es el tomador de decisiones quien es observado actuando o
tomando decisiones.
Al crear un guion el actor se pone en la columna izquierda y todas sus acciones en
la columna derecha, las actividades se registran con verbos conjugados de manera que
un tomador de decisiones podra describir como hablando tomando muestras
correspondiendo y decidiendo.
El guion es un mtodo organizado y sistemtico que exige al analista entender y
estructurar la accin asumida por cada uno de los tomadores de decisiones que haya
observado, este mtodo ayudara al analista de sistemas a determinar qu informacin
necesitan las personas observadas para tomar las decisiones ms importantes o
frecuentes.
Observacin del Entorno Fsico.

La observacin del entorno en el cual se desempean los tomadores de
decisiones tambin pone de manifiesto muchos de sus requerimientos de informacin.
Con mucha frecuencia dicha observacin implica examinar sistemticamente las oficinas
de los tomadores de decisiones, ya que estas constituyen su principal lugar de trabajo.
Los tomadores de decisiones influyen en, y a su vez reciben influencia de sus entornos
fsicos.
Observacin Estructurada del Entorno (STORBE).

A menudo es posible observar las circunstancias del entorno que confirmaran o
negaran el discurso (o dialogo) de la organizacin que se refleja en las entrevistas o
cuestionarios.
El mtodo para la observacin estructurada del entorno (STRuctured OBservation
of the Environment) se conoce como STORBE, requiere que el analista observe
explcitamente siete elementos concretos que pueden revelar mucho sobre la forma en
que el tomador de decisiones recopila, procesa, almacena, y comparte la informacin, as
como tambin sobre su credibilidad en el lugar de trabajo
Pgina 31

Ubicacin de la oficina. Es uno de los elementos que el analista de sistemas debe
observar en la ubicacin de la oficina de un tomador de decisiones especifico con
respecto a otras oficinas. Las oficinas accesibles tienden a aumentar la frecuencia de la
interaccin y los mensajes informales, mientras que las oficinas inaccesibles tienden a
disminuir la frecuencia de la interaccin y a aumentar los mensajes orientados a las
tareas, las personas cuyas oficinas estn separadas de las de los dems pudieran ver a la
organizacin de forma diferente y sus objetivos podran alejarse de los de otros miembros
de la organizacin.
Colocacin del escritorio: Puede ofrecer pistas
sobre
la manera en que el
tomador de decisiones ejerce su autoridad. El analista de sistemas debe observar la

distribucin de los muebles de la oficina y en particular la colocacin del escritorio, los
ejecutivos que confinan a un visitante a un espacio reducido y con la espalda a la pared
mientras ellos tienen exceso de espacio, adoptan la posicin de autoridad ms fuerte
posible. Un ejecutivo que coloca su escritorio frente a la pared con una silla al lado para
un visitante estimula la participacin y los intercambios equitativos.
Equipo fijo de oficina. Archiveros libreros y otro equipo grande para almacenar
artculos entran en la categora. Si no hay tal equipo es probable que el tomador de
decisiones almacene muy pocos artculos de informacin por s mismo. Si hay una
abundancia se asume que el tomador de decisiones almacena y valora mucha
informacin.
Accesorios: Se refiere a todo el equipo pequeo usado para procesar informacin
incluso las computadoras de bolsillo, calculadoras, Pcs, plumas, lpices, etc. Sugiere que
un tomador de decisiones que posee dicho equipo es ms probable que lo use
personalmente que uno que debe salir de la oficina para usarlo.
Fuentes externas de informacin: Un analista de sistemas necesita saber qu tipo
de informacin usa el tomador de decisiones. La observacin del tipo de publicacin
almacenada en la oficina puede revelar si el tomador de decisiones recurre a informacin
externa o se basa en la informacin interna. El analista tambin debe observar si el
tomador de decisiones prefiere conseguir informacin externa en la web.
Pgina 32

Iluminacin y color de la oficina. La iluminacin y el color juegan un papel

importante en la manera en que un tomador de decisiones recopila informacin. Un
ejecutivo en una oficina iluminada clidamente recopilara ms informacin de manera
informal, mientras que otro miembro de la organizacin que trabaja en una oficina
iluminada con gran colorido podra recopilar informacin a travs de memorandos
formales e informes oficiales.
Vestimenta de los tomadores de decisiones. El analista de sistemas puede darse
una idea de la credibilidad de los gerentes de la organizacin al observar la vestimenta
que usan en el trabajo. El hecho de que los lderes vistan de manera casual tiende a abrir
las puertas para una toma de decisiones ms participativa, pero a menudo propicia la
prdida de credibilidad en la organizacin
si la cultura predominante valora la ropa
tradicional y conservadora.
Mediante el STROBE el analista de sistemas puede darse una mejor idea de la
manera en que los gerentes recopilan procesan almacenan y usan la informacin.
Los analistas de sistemas utilizan cinco smbolos taquigrficos para evaluar cmo
se compara la observacin de los elementos STROBE con el discurso organizacional
derivado de las entrevistas.
1.- Una marca de verificacin significa que el discurso est confirmado.
2.- Una X significa que el discurso se contradice.
3.- Un smbolo de ovalo o forma de ojo es una seal para que el analista de
sistemas ahonde en el asunto.
4.- Un cuadro significa que la observacin de los elementos del STROBE modifica
el discurso.
5.- Un crculo significa que el discurso se complementa por lo que se observa.
Pgina 33

LISTA ANECDTICA CON SMBOLOS PAR APLICAR EL STROBE.
Discurso de los
miembros
de
la
organizacin
La informacin
Ubicacin
Iluminacin,
Vestimenta
de la oficina y el
color y graficas de la
del
tomador
equipo
oficina.
decisiones.
de
fluye con facilidad por

todos los niveles.
Adams dice: yo
descubro
los
porcentajes
por
mismo.
Vinnie dice Me
gusta
enterarme
de
esas cosas.
Ed
mano
dice:
La
derecha
no
siempre sabe lo que la

mano
izquierda
est
haciendo.
Adams
Nuestra
dice:
empresa
no
cambia mucho.
Algunas veces el
personal de operaciones
trabaja toda la noche.
Vinnie
dice:
Nosotros hacemos las
cosas como el seor
Adams quiere.
Julie
dice:
Algunas veces Stanley

parece
no
estar
Pgina 34

interesado.
Niega o contradice el discurso.
Confirma el discurso.
Averiguar con ms detalle.
Modificar el discurso.
Complementar el discurso.
Temas importantes de la organizacin que se originan de las entrevistas,

posteriormente se observan los elementos del STROBE y se registra. Una vez que se
comparan el discurso y las observaciones, se usa uno de los cinco smbolos apropiados
para representar la relacin. De esta manera el analista crea una tabla que primero
documenta y luego ayuda en el anlisis de las observaciones.
Mediante la observacin se dan una idea de lo que realmente se hace. Una forma
de describir cmo se comportan los tomadores de decisiones es utilizar un guion de
analista para documentar las actividades de cada uno de los actores principales. Adems
de observar la conducta de un tomador de decisiones el analista de sistemas debe
observar el entorno del tomador de decisiones. Un mtodo es la observacin estructurada
del entorno o STROBE. Un analista de sistemas usa el STROBE del mismo modo que un
crtico de cine.
Pgina 35

PROTOTIPOS
La creacin de prototipos de sistemas de informacin es una tcnica valiosa para
recopilar rpidamente informacin especfica sobre los requerimientos de informacin de
los usuarios.
En general, la creacin de prototipos efectivos se debe llevar a cabo en las
primeras etapas del SDLC, durante la fase de determinacin de requerimientos.
La informacin que se recopila en la fase de prototipos permite al analista
establecer prioridades y redirigir los planes sin sufrir repercusiones graves, con un mnimo
de interrupcin. Debido a esta caracterstica, la creacin de prototipos y la planeacin van
de la mano.
Tipos de prototipos
La palabra prototipo se utiliza en muchas formas; en vez de intentar una definicin
sintetizada de ellos, o de tratar de forzar una metodologa correcta para este tema
controversial, se va a ilustrar cmo se puede aplicar con xito cada una de las diversas
concepciones de los prototipos en una situacin especfica.
Prototipo de Parches
Pgina 36

El primer tipo alude a la construccin de un sistema funcional, parchado o
construido totalmente con parches. En ingeniera, a esta metodologa se le conoce como
breadboarding: crear un modelo funcional de un circuito integrado (cuya forma final ser
microscpica) uniendo partes.
En trminos de sistemas de informacin, se trata de un modelo funcional, con
todas las caractersticas necesarias, pero que es ineficiente. En esta instancia del
prototipo, los usuarios pueden interactuar con el sistema y acostumbrarse a la interfaz y a
los tipos de salidas disponibles. Sin embargo, los procesos de recuperacin y
almacenamiento de informacin pueden ser ineficientes debido a que los programas se
escribieron con rapidez, con el objetivo de que fuera funcional en vez de eficiente.
Prototipo no Operacional
La segunda concepcin de prototipo es la del modelo a escala no funcional,
empleado para probar ciertos aspectos del diseo. Un ejemplo es el modelo a escala
completa de un automvil que se utiliza en pruebas de tnel de viento. El tamao y la
forma del automvil son precisos, pero el automvil no es funcional; se incluyen slo las
caractersticas esenciales para una prueba especfica.
Sera pertinente un modelo de escala no funcional para un sistema de informacin
cuyas aplicaciones requirieran una codificacin demasiado extensa como para incluirla en
el prototipo, pero fuera til hacerse una idea de la entrada y la salida necesarias
solamente. En este caso, no se creara un prototipo del procesamiento, debido al excesivo
costo y tiempo requeridos. Los usuarios de todas formas podran tomar decisiones en
cuanto a la utilidad del sistema con base en el prototipo de la entrada y la salida.
Prototipo primero de una serie.
La tercera concepcin de los prototipos es la creacin de un modelo a escala
completa de un sistema, a lo que comnmente se le conoce como piloto. Un ejemplo sera
crear el prototipo del primer aeroplano de una serie y despus ver si puede volar antes de
construir un segundo aeroplano. El prototipo es completamente funcional; es una
realizacin de lo que el diseador espera sea una serie de aeroplanos con caractersticas
idnticas.
Este tipo de prototipo es til cuando se planean muchas instalaciones del mismo
sistema de informacin.
Pgina 37

El modelo funcional a escala completa permite a los usuarios experimentar una
interaccin realista con el nuevo sistema, al tiempo que minimiza el costo de solucionar
los problemas que presenta.
Prototipo de Caractersticas Selectas
La cuarta concepcin de los prototipos es la creacin de un modelo operacional
que incluya slo algunas caractersticas del sistema final. Una analoga sera un nuevo
centro comercial que abra antes de terminar de construir todas las tiendas.
Al crear prototipos de sistemas de informacin de esta forma, es posible incluir
slo algunas caractersticas esenciales.
La retroalimentacin de los usuarios puede ayudar a los analistas a comprender lo
que funciona y lo que no. Tambin puede ayudar con las sugerencias sobre cules
pueden ser las siguientes caractersticas a agregar.
Mediante este tipo de creacin de prototipos, el sistema se desarrolla en mdulos,
de manera que si los usuarios evaluaron positivamente las caractersticas presentadas, se
pueden incorporar al sistema final sin tener que trabajar mucho para interconectar los
mdulos. Los prototipos que se realizan de esta manera forman parte del sistema actual.
Uso de prototipos como alternativa para el SDLC

Algunos analistas argumentan que es necesario considerar a los prototipos como
una alternativa al SDLC.
El SDLC es una metodologa lgica y sistemtica para
desarrollar sistemas de informacin.

Las quejas sobre tener que pasar por el proceso del SDLC se concentran en dos
aspectos interrelacionados. El primero es el largo tiempo requerido para pasar por el ciclo
de vida de desarrollo.
La segunda es que los requerimientos del usuario cambian con el tiempo. Durante
el extenso intervalo entre el momento en que se analizan los requerimientos de los
usuarios y el momento en el que se entrega el sistema terminado, los requerimientos de
los usuarios evolucionan.
Adems del problema de no estar al corriente con los requerimientos de
informacin de los usuarios, se sugiere que stos no son conscientes de lo que desean o
detestan sino hasta que conocen una propuesta concreta. En el SDLC tradicional, a
menudo es demasiado tarde para cambiar un sistema no deseado una vez que se entreg
al cliente.
Pgina 38

Para lidiar con estos problemas, algunos analistas proponen utilizar los prototipos
como alternativa al SDLC, pues el analista recorta efectivamente el tiempo entre el
proceso de averiguar los requerimientos humanos de informacin y la entrega de un
sistema funcional.
Una desventaja de sustituir el SDLC con la creacin de prototipos deriva de dar
forma al sistema antes de comprender perfectamente el problema o la oportunidad
pertinente. Adems, al usar los prototipos como alternativa se podra producir un sistema
que sea aceptado por ciertos grupos especficos de usuarios, pero que sea inadecuado
para las necesidades del sistema en general.
Podemos considerar a los prototipos como un mtodo adicional especializado para
averiguar los requerimientos de informacin de los usuarios a medida que interactan con
los prototipos y proveen retroalimentacin para el analista.
Desarrollo de un Prototipo
Los prototipos son un medio excelente para obtener retroalimentacin sobre el
sistema propuesto y el grado en que cumple con las necesidades de informacin de sus
usuarios, como se muestra en la figura 6.2. El primer paso de la creacin de un prototipo
es estimar los costos involucrados en la construccin de un mdulo del sistema. Si los
costos del tiempo de los programadores y del analista, as como los costos del equipo
estn dentro del presupuesto, se puede continuar con la construccin del prototipo. sta
es una excelente manera de facilitar la integracin del sistema de informacin en la
cultura y sistema, ms extensos, de la organizacin.
Pgina 39

Lineamientos para desarrollar un prototipo

Una vez tomada la decisin de crear un prototipo, hay que cumplir con cuatro
lineamientos para integrar el prototipo en la fase de determinacin de requerimientos del
SDLC:
1. Trabajar en mdulos administrables.
2. Crear el prototipo con rapidez.
3. Modificar el prototipo.
4. Hacer nfasis en la interfaz de usuario.
Como se puede ver, los lineamientos sugieren formas de proceder necesariamente
interrelacionadas.
Trabajar en Mdulos Administrables
Al crear prototipos de algunas de las caractersticas de un sistema y convertirlos
en un modelo funcional, es imperativo que el analista trabaje en mdulos administrables.
Una de las ventajas nicas de los prototipos es que no es necesario ni conveniente
construir todo un sistema funcional para usarlos.
Un mdulo administrable permite a los usuarios interactuar con sus caractersticas
clave y se puede construir por separado. Las caractersticas del mdulo que se
consideran menos importantes se dejan intencionalmente fuera del prototipo inicial.
Pgina 40

Crear el Prototipo con Rapidez

La velocidad es esencial para la creacin de un prototipo exitoso de un sistema de
informacin.
Los analistas pueden usar prototipos para acortar este hueco mediante el uso de
tcnicas tradicionales de recopilacin de informacin para sealar los requerimientos
salientes de informacin, y despus tomar decisiones rpidas que produzcan un modelo
funcional. En efecto, el usuario ve y utiliza el sistema desde las primeras etapas del
SDLC, en vez de tener que esperar un sistema terminado para obtener experiencia
prctica.
Al ensamblar un prototipo operacional con la mayor rapidez y anticipacin en el
SDLC, el analista puede obtener una valiosa comprensin acerca de cmo proceder con
el resto del proyecto. Al mostrar a los usuarios en las primeras etapas del proceso el
desempeo real de las partes del sistema, la creacin rpida de prototipos evita
comprometer recursos excesivos en un proyecto que tal vez llegue a fracasar.
Modificar el Prototipo
Un tercer lineamiento para desarrollar el prototipo es que su construccin debe
admitir modificaciones. Para lograr esto hay que crearlo en mdulos que no tengan un alto
grado de interdependencia. Si cumplimos con este lineamiento encontraremos menos
resistencia cuando haya que modificar el prototipo.
Por lo general el prototipo se modifica varias veces, para lo cual pasa a travs de
varias iteraciones. Los cambios en el prototipo deben acercar ms el sistema a lo que los
usuarios dicen que es importante. Cada modificacin requiere de otra evaluacin por
parte de los usuarios.
Entrar a la fase de creacin del prototipo con la idea de que requerir
modificaciones es una postura til que demuestra a los usuarios qu tan necesaria es su
retroalimentacin para mejorar el sistema.
Hacer nfasis en la Interfaz de Usuario

La interfaz del usuario con el prototipo (y con el sistema, en ltima instancia) es
muy importante. Como lo que realmente se trata de lograr con el prototipo es hacer que
Pgina 41

los usuarios articulen con ms detalle sus requerimientos de informacin, deben ser
capaces de interactuar con facilidad con el prototipo del sistema. Tambin deben ser
capaces de ver cmo el prototipo les permitir realizar sus tareas. Para muchos usuarios,
la interfaz es el sistema.
Los sistemas interactivos en lnea que utilizan interfaces de GUI se adaptan de
manera ideal a los prototipos.
Ventajas de los prototipos

La utilizacin de prototipos no es necesaria o apropiada en todos los proyectos de
sistemas. Sin embargo, las ventajas tambin se deben tener en consideracin al decidir si
se deben o no crear.
Las tres principales ventajas de los prototipos son:
desarrollo,
el potencial de cambiar el sistema durante las primeras etapas de su

la oportunidad de detener el desarrollo en un sistema que no est
funcionando y
la posibilidad de desarrollar un sistema que cumpla mejor con las

necesidades y expectativas de los usuarios.
La creacin de prototipos exitosos depende de la retroalimentacin oportuna y
frecuente de los usuarios, que los analistas pueden usar para modificar el sistema y
hacerlo ms sensible a las necesidades actuales.
Desventajas de los prototipos

Al igual que sucede con cualquier otra tcnica de recopilacin de informacin, el
uso de prototipos presenta varias desventajas.
Puede ser bastante difcil administrar la creacin de un prototipo
como un proyecto dentro del esfuerzo ms grande de sistemas.
Los usuarios y analistas pueden adoptar un prototipo como sistema

completo cuando todava es inadecuado.
El analista debe comparar estas desventajas contra las ventajas conocidas al
decidir si va a crear un prototipo, cundo se va a crear y qu tanto del sistema se va a
incluir en el prototipo.
Pgina 42

El papel que desempean los usuarios en los prototipos

El papel de los usuarios en los prototipos se puede resumir en dos palabras:
participacin honesta. Sin la participacin de los usuarios, los prototipos no tienen mucho
sentido. Los comportamientos precisos necesarios para interactuar con un prototipo
pueden variar, pero est claro que el usuario es fundamental para el proceso de creacin
de prototipos. Teniendo en cuenta la importancia del usuario para el xito del proceso, los
miembros del equipo de anlisis de sistemas deben fomentar y agradecer la entrada y
protegerse contra su propia resistencia natural a cambiar el prototipo.
Hay tres formas principales en las que un usuario puede ayudar con los prototipos:
1. Experimentar con el prototipo.
2. Ofrecer reacciones abiertas al prototipo.
3. Sugerir lo que se puede agregar o quitar en el prototipo.
Los usuarios deben tener la libertad de experimentar con el prototipo. A diferencia
de una simple lista de caractersticas del sistema, el prototipo permite a los usuarios
interactuar en forma prctica con el sistema.
Otro aspecto del papel de los usuarios en los prototipos es que se requiere que
expresen reacciones abiertas al mismo. Los analistas tienen que estar presentes por lo
menos parte del tiempo cuando ocurre la experimentacin. Algunas de las variables a
observar son las reacciones de los usuarios al prototipo, sus sugerencias para cambiar o
expandir el prototipo, sus innovaciones para usar el sistema en formas completamente
nuevas y cualquier plan de revisin para el prototipo que ayude a establecer las
prioridades.
Tambin es importante el papel que desempean los usuarios en los prototipos es
su disposicin para sugerir elementos que se puedan agregar o quitar en base a las
caractersticas que hayan experimentado. La funcin del
analista es obtener tales
sugerencias al asegurar a los usuarios que la retroalimentacin que ellos proveen se toma
en serio, al observar a los usuarios a medida que interactan con el sistema y al llevar a
cabo entrevistas cortas y especficas con los usuarios en relacin con sus experiencias
con el prototipo. Para facilitar el proceso de creacin del prototipo, el analista debe
Pgina 43

comunicar con claridad los propsitos de la creacin de prototipos a los usuarios, junto
con la idea de que los prototipos son valiosos slo cuando los usuarios se involucran en
forma significativa.
Pgina 44

ESCENARIOS
Normalmente, las personas encuentran ms fcil dar ejemplos de la vida real que
descripciones abstractas. Pueden comprender y criticar un escenario de cmo podra
interactuar con un sistema software. Los ingenieros de requerimientos pueden utilizar la
informacin obtenida de esta discusin para formular los requerimientos reales del
sistema.
Los escenarios pueden ser especialmente tiles para agregar detalles a un esbozo
de la descripcin de requerimientos. Son descripciones de ejemplos de las sesiones de
interaccin. Cada escenario abarca una o ms posibles interacciones. Se han
desarrollado varias formas de escenarios, cada una de las cuales proporciona diferentes
tipos de informacin en diferentes niveles de detalle sobre el sistema. Utilizar escenarios
para descubrir requerimientos es una parte fundamental de los mtodos giles, como la
programacin extrema.
Componentes del Escenario

Un escenario consta de componentes que se describen a continuacin. A algunas
de ellas pueden asignrseles las nociones de Restriccin y/o Excepcin. Una restriccin
es el alcance o un requisito de calidad y es aplicada a contexto, recurso, episodio. Una
excepcin marca una situacin singular aplicable a un episodio.
Ttulo: Identifica a un escenario. El ttulo es el mismo que la sentencia que
contiene al episodio.
Objetivo: Establece la finalidad del escenario describiendo cmo se alcanza ese
objetivo.
Contexto: Describe el estado inicial del escenario, las precondiciones, la ubicacin
fsica y temporal.
Recursos: Identifica las entidades pasivas con las cuales los actores trabajan.
Pgina 45

Actores: Detalla las entidades que se involucran activamente en el escenario,
generalmente una persona o una organizacin.
Secuencia de Episodios: Los episodios se presentan ordenadamente. Cada uno
de ellos representa una accin realizada por un actor, con la participacin de otros actores
y la utilizacin de recursos. Un episodio puede ser expresado como un sub-escenario.
El escenario comienza con un esbozo de la interaccin y, durante la obtencin, se
agregan detalles para crear una descripcin completa de esta interaccin. De forma
general, un escenario puede incluir:
1.
Una descripcin de lo que esperan el sistema y los usuarios cuando
el escenario comienza.
2.
Una descripcin del flujo normal de eventos en el escenario.
3.
Una descripcin de lo que puede ir mal y cmo manejarlo.
4.
Informacin de otras actividades que se podran llevar a cabo al
mismo tiempo.
5.
Una descripcin del estado del sistema cuando el escenario
termina.
Es posible llevar a cabo de manera informal la obtencin de requerimientos
basada en escenarios cuando los ingenieros de requerimientos trabajan con los
stakeholders en la identificacin de escenarios y en la captura de detalles de dichos
escenarios. Los escenarios se pueden redactar como texto, complementados por
diagramas, fotografas de las pantallas, etc. De forma alternativa, se puede adoptar un
enfoque ms estructurado, como escenarios de eventos o los casos de uso.
Proceso de construccin de los escenarios

El proceso de construccin de los Escenarios parte del lxico del dominio de la
aplicacin pues el lenguaje lxico extendido contiene informacin que puede ser utilizada
en los escenarios, produciendo entonces una primera versin de los escenarios derivados
exclusivamente del lenguaje lxico extendido.
Pgina 46

Proceso de Construccin de los Escenarios

Se muestra un flujo principal compuesto de tres actividades: Derivar, Describir y
Organizar, stas no son estrictamente secuenciales. Algunas actividades se realizan
concurrentemente como condicin intrnseca del proceso mismo. Adicionalmente, existe
un mecanismo de retroalimentacin entre ellas, que aporta una segunda instancia de para
el lenguaje lxico extendido mismo. Esto ocurre cuando se realizan las actividades
Verificar y Validar, retornando a la actividad Describir, donde las correcciones son
realizadas en base a las listas de discrepancias, errores y omisiones. La actividad
Verificar ocurre despus de describir los escenarios y tambin despus de organizarlos,
cuando aparecen nuevos escenarios o se generan los escenarios integradores. Los
escenarios son validados con los usuarios despus de la verificacin.
El proceso presenta las siguientes actividades:
1) Derivar
Esta actividad tiene como propsito generar escenarios candidatos utilizando
informacin contenida en el lenguaje lxico extendido, basndose en el modelo de
escenario y aplicando las heursticas apropiadas. El proceso de derivacin consiste en
tres pasos: identificar los actores del diagrama de uso, identificar escenarios candidatos y
por ltimo crearlos extrayendo informacin almacenada en el lenguaje lxico extendido.
Identificar actores
Se genera una lista preliminar de actores, a partir de informacin contenida en el
lenguaje lxico extendido, con el fin de guiar las siguientes sub-actividades. Todo smbolo
clasificado como Sujeto en el lenguaje lxico extendido se considera como un posible
actor. Es esperado que esto ocurra salvo contadas ocasiones, como puede ser el caso de
Pgina 47

actores off-stage, es decir, aquellos que son mencionados en el curso de accin del
escenario pero que no interactan directamente con otros actores.
Identificar escenarios
Se extraen del lenguaje lxico extendido los impactos de los smbolos elegidos
como actores. Cada impacto representa un posible escenario y, por lo tanto, se crea un
ttulo preliminar para el mismo y se lo incorpora a la lista de escenarios candidatos. El
ttulo del escenario se compone con la accin (verbo) incluida en el impacto, expresada
en infinitivo, ms un predicado tambin obtenido del impacto. Se debe descartar aqul
impacto que involucra un punto de vista formal pues dicho impacto no representa un
hecho de lo actual.
Crear escenarios
En este paso se construyen los escenarios con tanta informacin como sea posible
extrada del lenguaje lxico extendido. El producto de este paso es un conjunto de
escenarios candidatos derivados. Si el impacto mencionado contiene otros smbolos del
lenguaje lxico extendido, los mismos son a su vez una fuente valiosa de informacin
para componentes tales como el contexto, los actores y los recursos, entre otros.
2) Describir
Esta actividad tiene por objetivo completar la descripcin de los escenarios
candidatos, agregando informacin del diagrama de uso, basndose en el modelo de
escenario, utilizando en la descripcin los smbolos del lenguaje lxico extendido y
aplicando las heursticas de descripcin. El resultado es un conjunto de escenarios
descriptos completamente.
Esta actividad debe planearse y generalmente se realiza aplicando las tcnicas de
entrevistas estructuradas, observacin y lectura de documentos, pero en general casi
todas las tcnicas de licitacin son aplicables, lo que debe identificarse es la vigencia de
la informacin que brinda la fuente, pues en esta etapa se requiere estrictamente
informacin actual. Primero, la recoleccin de informacin apunta a confirmar y mejorar
los cursos normales de eventos.
Pgina 48

3) Organizar
El conjunto de escenarios actuales obtenidos de la actividad Describir puede
presentar dos tipos de debilidades: i) los ingenieros de requisitos estn sumergidos en
detalles, perdiendo la visin global del diagrama de uso, y ii) existe un riesgo de
inconsistencias entre los escenarios, tales como la existencia de sub-escenarios
irrelevantes o escenarios con alta similitud. La primera se encara por medio del uso de
escenarios
integradores
actuales,
los
cuales
describen
situaciones
artificiales
presentadas slo con el propsito de hacer ms entendible y manejable el conjunto de

escenarios. Los escenarios integradores brindan una visin global de la aplicacin. La
segunda debilidad se maneja componiendo o descomponiendo escenarios, para atacar
bsicamente problemas de falta de homogeneidad en la descripcin de las situaciones y
algunos problemas menores de semntica.
Cuando se encaran aplicaciones medianas a grandes, la cantidad de escenarios
suele tornarse inmanejable. Luego, los escenarios integradores dan un panorama de las
relaciones entre varias situaciones, dado que cada episodio de un escenario integrador es
el ttulo de un escenario ya descripto. El propsito principal de los escenarios integradores
es vincular escenarios dispersos, proveyendo un panorama completo de la aplicacin.
Reorganizar escenarios
Los escenarios pueden tener distinto grado de detalle o superposicin,
especialmente cuando son construidos por ms de un ingeniero de requisitos. Esto se
torna ms complejo a medida que se tienen ms escenarios y un grupo de trabajo ms
grande. Bsicamente la reorganizacin de escenarios consiste en componer dos o ms
escenarios en uno, o en fragmentar un escenario en dos o ms. La composicin se realiza
cuando una nica situacin fue artificialmente repartida en varios escenarios durante las
actividades Derivar o Describir. Por otro lado, se fragmenta o descompone un escenario
cuando ste contiene ms de una situacin.
4) Verificar
Esta actividad se realiza por lo menos dos veces durante el proceso de
construccin de escenarios, la primera vez sobre el conjunto de escenarios
Pgina 49

completamente descriptos generados en la actividad Describir y la segunda despus de la
actividad Organizar. Se realiza siguiendo una gua con heursticas de verificacin.
La verificacin se divide en dos pasos: Verificacin Intra- Escenarios y Verificacin
Inter-Escenarios. La primera consiste en realizar una consistencia interna de cada
escenario, contrastando sus distintos componentes. La segunda se ocupa de realizar una
consistencia entre los escenarios, analizando la integridad del conjunto de escenarios
producido.
5) Validar
Los escenarios son validados con los usuarios, generalmente realizando
entrevistas estructuradas o reuniones. Durante la validacin, debe considerarse
especialmente el componente Dudas de aquellos escenarios que lo presenten. Este
componente del escenario pudo agregarse durante la actividad Describir y se debe
eliminar durante la validacin.
Esta actividad se ve facilitada pues los escenarios son escritos en lenguaje natural,
empleando el vocabulario propio de los usuarios y describiendo una situacin especfica
bien limitada en la que los propios usuarios estn involucrados.
Como ejemplo de escenario de texto sencillo, considere cmo un usuario del
sistema de biblioteca LIBSYS puede utilizar el sistema. Se muestra este escenario en la
Figura 7,5. El usuario desea imprimir una copia personal de un artculo de una revista
mdica. Esta revista hace copias de artculos disponibles gratuitamente para los
suscriptores, pero las personas que no estn suscritas tienen que pagar una cantidad por
artculo. El usuario conoce el artculo, el ttulo y la fecha de publicacin.
Pgina 50

Figura 7,5 Escenario para la descarga de artculos en el LIBSYS.
Casos de Uso
Los casos de uso son una tcnica que se basa en escenarios para la obtencin de
requerimientos que se introdujeron por primera vez en el mtodo Objetory (Jacobsen et
al., 1993). Actualmente se han convertido en una caracterstica fundamental de la
notacin de UML, que se utiliza para describir modelos de sistemas orientados a objetos.
En su forma ms simple, un caso de uso identifica el tipo de interaccin y los actores
involucrados. Por ejemplo, la Figura 7,6 muestra el caso de uso de alto nivel de la funcin
de impresin de artculos en el LIBSYS descrita en la Figura 7,5.
Pgina 51

Figura 7.6 Un caso de uso sencillo para la impresin de artculos.

La Figura 7.6 ilustra la esencia de la notacin para los casos de uso. Los actores
en el proceso se representan como figuras delineadas, y cada clase de interaccin se
representa como una elipse con su nombre. El conjunto de casos de uso representa todas
las posibles interacciones a representar en los requerimientos del sistema. La Figura 7.7
extiende el ejemplo del LIBSYS y muestra otros casos de uso en ese entorno. Algunas
veces existe confusin sobre si un caso es un escenario o, como sugiere Fowler (Fowler
Scott 1997), un caso de uso encierra un conjunto de escenarios, y cada uno de stos es
un hilo nico a travs del caso de uso. Si un escenario incluye mltiples hilos, habr un
escenario para la interaccin normal y escenarios adicionales para las posibles
excepciones.
Figura 7.7 Casos de uso para el sistema de biblioteca.
Pgina 52

Los casos de uso identifican las interacciones particulares con el sistema. Pueden
ser documentadas con texto o vinculadas a modelos UML que desarrollan el escenario en
ms detalle. Los diagramas de secuencia se utilizan a menudo para aadir informacin a
un caso de uso. stos muestran los actores involucrados en la interaccin, los objetos con
los que interactan y las operaciones asociadas con estos objetos.
Como ejemplo de esto, la Figura 7,8 muestra las interacciones involucradas en la
utilizacin del LIBSYS para la descargar e impresin de un artculo. En la Figura 7.8,
existen cuatro objetos de clases Articulo, Formulario, Espacio de trabajo e Impresorainvolucradas en esta interaccin. La secuencia de acciones des de arriba abajo, y las
etiquetas de las fechas entre los actores y objetos indican los nombres de las
operaciones. Fundamentalmente, una peticin de un artculo por parte de un usuario
provoca una peticin de un formulario de derechos de autor. Una vez que el usuario ha
completado el formulario, se descarga el artculo y se enva a la impresora. Cuando
termina la impresin, se elimina el artculo del espacio de trabajo del LIBSYS.
Figura 7.8 Interacciones del sistema para la impresin de artculos.
Pgina 53

UML es un estndar del factor para el modelo orientado a objetos, por lo que los
casos de uso y la obtencin de requerimientos basada en caso de uso se utilizan cada
vez ms para la obtencin de requerimientos.
Los escenarios y los casos de uso son tcnicas eficaces para obtener
requerimientos para los puntos de vista de los interactuadores donde cada tipo de
interaccin se puede representar como un caso de uso. Tambin se pueden utilizar
conjuntamente con algunos puntos de vista indirectos cuando estos reciben resultados
(como un informa de gestin) del sistema. Sin embargo, debido a que se centran en las
interacciones, no son tan eficaces para obtener restricciones y requerimientos de
negocios y no funcionales de alto nivel de puntos de vista indirectos o para descubrir
requerimientos del dominio.
Pgina 54

CONCLUSIN
Las tcnicas de obtencin de requisitos son una herramienta excelente para
reconocer los datos importantes de una empresa, siendo posibles objetos de estudio las
personas, objetos, fenmenos o situaciones.
Conocer la informacin relevante permite al analista, hacerse una idea clara de lo
que el software debe contener, a pesar de que existen diversas tcnicas de recoleccin de
datos, es frecuente utilizar varias a la vez, aunque esto depender de la situacin, de la
empresa o de los requisitos iniciales de los clientes (como el tiempo o el costo).
Pgina 55

REFERENCIAS
-Pressman, R.S., Ingienera Del Software UN ENFOQUE PRCTICO. Mxico. M
Graw-Hill.
-Sommerville, Ian., Ingeniera de Software, 7ma. Edicin., Pearson Educacin,
S.A., Madrid, 2005.
-Kendall, Kennethe y Kendall, Julie E., Anlisis y Diseo de Sistemas., 8va.
Edicin., Pearson Educacin, Mxico, 2011.
Pgina 56

Técnicas de Obtencion de Requisitos (Entrevistas, Observación, Prototipos, Escenarios)

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Técnicas de Obtencion de Requisitos (Entrevistas, Observación, Prototipos, Escenarios)

Cargado por

Copyright:

Formatos disponibles

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Ingeniera en Sistemas Computacionales

Fundamentos de Ingeniera de Software.

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Pasos para la Planeacin de la Entrevista

LEER LOS ANTECEDENTES: Leer y entender tanto como sea

posible los antecedentes de los entrevistados y su organizacin.

ESTABLECER LOS OBJETIVOS DE LA ENTREVISTA: utilice los

DECIDIR A QUIEN ENTREVISTAR: Cuando tenga que decidir a

PREPARAR AL ENTREVISTADO: Prepare a la persona que va a

DECIDIR EL TIPO DE PREGUNTAS Y LA ESTRUCTURA: Escriba

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

En Calidad de Entrevistador se debe pensar Cuidadosamente los Tipos de

CONFIABILIDAD DE LOS DATOS

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

USO EFICIENTE DEL TIEMPO

PRECISION DE LOS DATOS

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Uso de una estructura de embudo

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Uso de una estructura de diamante

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Redaccin del Informe de la Entrevista

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Uso de Escalas en los Cuestionarios

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Diseo del muestreo

Determinar la Poblacin a Muestrear

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

El analista de sistemas puede elegir un grupo de individuos que parezcan expertos

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

sistemas desea recopilar datos con eficiencia

La decisin sobre el tamao de las muestras

p , el error estndar de la proporcin, de la siguiente manera:

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

7. Determinar el tamao de muestra necesario, n, mediante la siguiente frmula:

Desde luego, el primer paso es determinar el atributo a muestrear; despus se

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Anlisis de documentos cuantitativos

estos documentos tienen un propsito y una audiencia especficos.

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Anlisis de los documentos cualitativos

memorandos, anuncios en tableros y reas de trabajo, pginas Web, manuales de

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

Sitios Web Corporativos

INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLA

comportamiento de los empleados y la empresa, se debe enfocar principalmente en

Observacin del Comportamiento del Tomador De Decisiones.

Observacin de las Actividades de Toma de Decisiones de un Gerente