INSTITUTO TECNOLGICO SUPERIOR DE SAN ANDRS TUXTLAIngeniera en Sistemas ComputacionalesFUNDAMENTOS DE INGENIERIA DE SOFTWAREUNIDAD 2: INGENIERA DE REQUISITOS

Fundamentos de Ingeniera de Software.Docente:M.T.I Montserrat Masdefiol SurezGrupo:504-A5to. SemestrePeriodo Escolar:Agosto 2015 Enero 2016Integrantes:Baxn Ruiz Anglica RubyCagal Mlaga Anglica IsabelComi Velasco DanielChigo Acua OmarColorado Morgado CarolinaFacundo Vicente Miguel AlfredoMolina Villanueva Carlos ArturoObil Ziga Oscar PraxedisRomn Corts Elfega DenisTemich Ferman CarolinaLugar y Fecha:San Andrs Tuxtla Ver. A 13 de septiembre de 2015

ContenidoINTRODUCCIN4ENTREVISTA5Pasos para la Planeacin de la Entrevista5Preguntas Abiertas5Preguntas Cerradas6Sondeos8Redaccin del Informe de la Entrevista11Uso de Cuestionarios11Redaccin de Preguntas13Uso de Escalas en los Cuestionarios16Diseo de Cuestionarios19Aplicacin de Cuestionarios20OBSERVACIN22Muestreo22Diseo del muestreo23La decisin sobre el tamao de las muestras25Investigacin27Anlisis de documentos cuantitativos27Anlisis de los documentos cualitativos28Memos29Sitios Web Corporativos29Manuales29Manuales de Polticas30Observacin del Comportamiento del Tomador De Decisiones.30Observacin de las Actividades de Toma de Decisiones de un Gerente Tpico.30Observacin del Entorno Fsico.31Observacin Estructurada del Entorno (STORBE).31PROTOTIPOS36Tipos de prototipos36Uso de prototipos como alternativa para el SDLC38Desarrollo de un Prototipo39Lineamientos para desarrollar un prototipo40Ventajas de los prototipos42Desventajas de los prototipos42El papel que desempean los usuarios en los prototipos43ESCENARIOS45Componentes del Escenario45Proceso de construccin de los escenarios46Casos de Uso51CONCLUSIN55REFERENCIAS56

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.

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 AbiertasEn realidad, abiertas describe las opciones del entrevistado para responder. Las respuestas pueden ser de dos palabras o dos prrafos. 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 CerradasUna pregunta cerrada limita la respuesta disponible para el entrevistado.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 tiempo2.- 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:CONFIABILIDAD DE LOS DATOS

Baja Alta

Baja AltaPRECISION DE LOS DATOSUSO EFICIENTE DEL TIEMPO

BajaAlta

Mucha PocaHABILIDAD REQUERIDA DEL ENTREVISTADORAMPLITUD Y PROFUNDIDAD

Mucha PocaFACILIDAD DE ANALISIS

Difcil 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 LgicaAs 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.

Uso de una estructura de pirmideLa 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.

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.

Redaccin del Informe de la EntrevistaAunque 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 CuestionariosEl 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.

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 CuestionariosA 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 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 PreguntasLa 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.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 abiertasRecordando 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.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.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 CuestionariosEl 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).

MedicinPor lo general, los analistas de sistemas utilizan dos diferentes formas de escalas de medicin:1. las escalas nominales y2. 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 texto2 = Una hoja de clculo3 = Una base de datos4 = Un programa de correo electrnicoSe 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 confiabilidadHay 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?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 escalasLa 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.

Diseo de CuestionariosMuchos 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.

Las cuatro reglas anteriores deben ayudar a conseguir una mejor tasa de respuestas al cuestionario.El orden de las preguntasNo 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

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

Mtodos para aplicar el cuestionarioEl 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.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 fsicoLos 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.

MuestreoEl 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 muestreoUn 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.4. Reducir la predisposicinEl 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 precisaAdems, 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 muestreoUn analista de sistemas debe seguir cuatro pasos para disear una buena muestra:

Determinar los Datos a Recolectar o DescribirEl 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 MuestrearEl 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 MuestraEl 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, necesitaobtener 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 deconglomerados.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 subpoblaciones. A menudo, la estratificacin es esencial si el analista desistemas desea recopilar datos con eficienciaDecidir sobre el tamao de la MuestraEn definitiva, si todos en la poblacin vieran el mundo de lamisma 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 muestrasA 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 , el error estndar de la proporcin, de la siguiente manera:

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 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 deconfianza 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 EntrevistasNo hay frmulas mgicas para ayudar al analista de sistemas a establecer el tamao de la muestra para entrevistas; la variable primordial en este caso esel 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, pocosindividuos representarn de manera adecuada a toda la organizacin.InvestigacinInvestigar 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 cuantitativosHay muchos documentos cuantitativos disponibles para su interpretacin en cualquier empresa: informes empleados para la toma de decisiones, informes de rendimiento, registros y variados tipos de formularios. Todosestos documentos tienen un propsito y una audiencia especficos.

Informes para la toma de DecisionesEl analista de sistemas requiere acceso a algunos de los documentosutilizados para dirigir la empresa.Consisten en informes sobre el estado del inventario, las ventas o laproduccin. 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 y las entradas durante ciertos periodos. Dichos informespermiten 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 RendimientoLa 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.RegistrosLos 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 capacidadde 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 cualitativosLos 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 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.MemosEl 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 CorporativosEl 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).ManualesLos 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 PolticasEl 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 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

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.

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.

LISTA ANECDTICA CON SMBOLOS PAR APLICAR EL STROBE.

Discurso de los miembros de la organizacinUbicacin de la oficina y el equipoIluminacin, color y graficas de la oficina.Vestimenta del tomador de decisiones.

La informacin fluye con facilidad por todos los niveles.

Adams dice: yo descubro los porcentajes por m mismo.

Vinnie dice Me gusta enterarme de esas cosas.

Ed dice: La mano derecha no siempre sabe lo que la mano izquierda est haciendo.

Adams dice: Nuestra 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 interesado.

Niega o contradice el discurso. Averiguar con ms detalle.Confirma el discurso. 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.

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 prototiposLa 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 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.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 SDLCAlgunos 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.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 PrototipoLos 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.

Lineamientos para desarrollar un prototipoUna 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 AdministrablesAl 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.

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 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 prototiposLa 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: el potencial de cambiar el sistema durante las primeras etapas de su desarrollo, 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 prototiposAl 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.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 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.

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 EscenarioUn 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. 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 escenariosEl 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.

Proceso de Construccin de los EscenariosSe 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) DerivarEsta 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 actoresSe 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 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 escenariosSe 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 escenariosEn 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) DescribirEsta 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.3) OrganizarEl 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 escenariosLos 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) VerificarEsta actividad se realiza por lo menos dos veces durante el proceso de construccin de escenarios, la primera vez sobre el conjunto de escenarios 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) ValidarLos 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.

Figura 7,5 Escenario para la descarga de artculos en el LIBSYS.Casos de UsoLos 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.

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.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 Impresora- involucradas 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. 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.

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

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