Temas 03

Captulo 3
Educcin de Requisitos
3.1 El proceso de educir requisitos
Educir, segn la Real Academia de la Lengua, signica sacar algo de algo. En este caso, lo que se educe son los requisitos de diversas fuentes, que ms tarde se distinguirn. El proceso de educir requisitos puede descomponerse en las actividades de: hallazgo, de hechos, reunin e integracin de la informacin. Un procedimiento para obtener la informacin directamente de la gente que usara el sistema consta de los siguientes pasos: Identicacin de las fuentes relevantes de los requisitos, es decir, que usuarios pueden proporcionar informacin acerca de los requisitos. Preguntar cuestiones apropiadas para obtener y comprender sus necesidades. Analizar la informacin reunida buscando implicaciones, inconsistencia o aspectos no resueltos. Conrmar la comprensin de los requisitos con los usuarios. Sintetizar las especicaciones adecuadas para los requisitos. Como se pueden construir las tcnicas de educcin ? Las tcnicas de educcin han evolucionado desde este procedimiento general: 1. Deniendo procesos detallados 2. Proponiendo preguntas o categoras de preguntas 3. Estableciendo formatos estructurado para las reuniones 4. Describiendo comportamiento ideales, individuales o de grupo. 5. Construyendo patrones para organizar y registrar la informacin El resultado tangible de educir requisitos es un conjunto de requisitos que puede ser utilizado por el equipo de desarrollo de software. Sin embargo, hay muchas conductas intangible del proceso que pueden afectar al completo xito del proyecto. Estas conductas dieren, dependiendo de si el proceso de educcin fue conducido bien o pobremente. 59
CAPTULO 3. EDUCCIN DE REQUISITOS
60
3.1.1
Conductas en un buen proceso
El proceso de educir parte de una idea que reeja una necesidad de automatizacin que surge de los usuarios y que, gracias a la tecnologa proporcionada por los ingenieros del software, se distingue con claridad lo que realmente necesitan los usuarios
Idea
Ayuda a la exploracin de requisitos
Los usuarios tienen una idea vaga de lo que necesitan
Proceso de Educcin
Los ingenieros de software dan una idea de lo que la tecnologa puede ofrecer
Distincin entre lo que los usuarios quieren y lo que necesitan
Figura~3.1: Entradas y salidas del proceso de educir
3.1.2
Conductas en un proceso pobre
Cuando la educcin es pobre, lo que ocurre con cierta frecuencia, la insatisfaccin producida en los usuarios conduce a un grave impedimento para el desarrollo normal del proyecto software.
3.1.3
Problemas de la educcin de requisitos
Se pueden agrupar en tres categoras: 1. Problemas de alcance, de forma que los requisitos pueden implicar demasiada o muy poca informacin. Las tcnicas de educcin tienen que ser lo sucientemente amplias como para establecer las condiciones de los limites del sistema objetivo. La determinacin de los limites y objetivos del sistema (con los que se comprobar que los requisitos obtenidos son correctos) se puede realizar a travs de un anlisis de contexto y de la organizacin. Hay al menos tres contextos amplios que afectan al proceso de ingeniera de requisitos para un sistema propuesto:
61
Organizacin: los requisitos de organizacin proporcionan una comprensin de la propia organizacin y del papel que representa el sistema en el contexto de la organizacin. Los factores de organizacin incluyen: las presentaciones de las entradas al sistema los usuarios de las salidas del sistema las formas en las que el sistema cambiar el modo de trabajar en la organizacin. Entorno: para educir requisitos del usuario es necesario disponer de una descripcin precisa de los usuarios y de su entorno. Los factores de entorno incluyen: restricciones de hardware y software madurez del dominio del sistema certeza de las interface del sistema con el sistema que le embebe papel del sistema dentro de otro sistema mas grande. Proyecto: los factores del contexto del proyecto incluyen: atributos de los diferentes grupos, tales como usuarios nales, patrocinadores, desarrolladores o analistas de requisitos. Atributos tales como el estilo , la jerarqua en ese grupo, la experiencia en el dominio, la experiencia en computadoras. restricciones impuestas por la gente implicada. Por ejemplo, la direccin puede imponer restricciones de tiempo, coste, calidad deseada. 1. Problemas de comprensin, dentro de grupos de implicados o entre grupos, como por ejemplo, entre usuarios y desarrolladores. Como consecuencia de una pobre comunicacin entre usuario y analista, los requisitos son ambiguos, incompletos, inconsistentes e incorrectos, porque no responden a las verdaderas necesidades de los usuarios. Puede ser dividido en varios aspectos: Las comunidades implicadas en la educcin (patrocinadores y clientes, desarrolladores, personas de control de calidad, analistas) tienen distintas formaciones y experiencia. La informacin reunida por una de las comunidades esta sesgado por el nivel de abstraccin con el que este grupo ve el problema, objetivos, responsabilidades Por ejemplo: Los desarrolladores del sistema tienen un conocimiento limitado del dominio de la aplicacin Los usuarios no conocen mtodos de diseo para desarrollar sistemas con componentes software Los clientes puede que no comprendan la dicultad para resolver un problema dado.
62
El lenguaje usado para expresar requisitos puede ser demasiado formal o informal para reunir las necesidades de cada uno de los grupo. Inicialmente, se usa lenguaje natural lo que provoca ambigedad y mala interpretacin. La gran cantidad de informacin que se educe tiene que organizarse de alguna forma. Cualquier metodologa requiere una gran cantidad de documentacin que hay que gestionar. La forma en la que se expresan los requisitos, y el tamao del sistema descrito, afecta a la comprensin. 1. Problema de volatilidad, ya que los requisitos evolucionan con el tiempo. Las necesidades del usuario durante el desarrollo de un sistema pueden madurar a causa del conocimiento adicional fruto del desarrollo o de presiones del entorno o de la organizacin que no son previstas. Si no se incorporan estos cambios, los requisitos originales sern incompletos e inconsistentes con la nueva situacin. Algunas de las causas de volatilidad de los requisitos son: Las necesidades del usuario evolucionan. El proceso de educcin, anlisis, especicacin y validacin se debe realizar ms de una vez. Y las especicaciones obtenidas se van renando de acuerdo al nuevo conocimiento obtenido. Los requisitos son resultado de muchas contribuciones con distintas, y a veces contrapuestas, necesidades y objetivos. La priorizacin de las necesidades de las comunidades implicadas en la educcin puede corregir la preponderancia de alguna de ellas durante esta fase de educcin. La complejidad de la organizacin. Los objetivos, polticas, funciones de os usuarios, pueden cambiar a lo largo del proyecto, sobre todo si los usuarios afectados son muchos. El proceso iterativo de desarrollo de requisitos resuelve este problema. Las tcnicas desarrolladas y usadas por los ingenieros de software han sido diseadas para superar las dicultades descriptas anteriormente (alcance, comprensin y volatilidad). Se clasican en dos grupos: Algunas tcnicas son de alto nivel, es decir, amplios entornos que permiten albergar procesos que educen requisitos. Otras tcnicas son de bajo nivel, que proporcionan tcticas especicas para educir detalles de una parte determinada de un sistema o de un usuario particular. En la tabla siguiente se aprecia las distintas tcnicas En sentido genrico, tambin se pueden describir las tcnicas en las siguientes categoras, basndose en la actividad del analista: Preguntar: Una vez identicada la persona se preguntan los requisitos Observar e inferir: Se observa el comportamiento de un sistema existente y a los usuarios del mismo y se ineren sus necesidades desde ese comportamiento.
CAPTULO 3. EDUCCIN DE REQUISITOS Tcnicas de Alto Nivel JAD Entorno de Bucles adaptativos Prototipos Tcnicas Detalladas Entrevistas Cuestionarios Arreglos-Q Baintorming PIECES Anlisis de Mercado Anlisis de factores Crticos STROBE
63
Tabla 3.1: Tcnicas de educcin de requsitos Se discute, con los usuarios, sus necesidades, y juntos, se formula una comprensin comn de los requisitos. Negociar con respecto de un conjunto estndar: Se comienza con un conjunto existente de requisitos, y se negocia con los usuarios si cada una de estas caractersticas se incluye, excluye o modica. Estudiar e identicar problemas: Se realizan investigaciones de problemas que identiquen requisitos que mejoren el sistema. Descubrir a travs de procesos creativos: Cuando no hay soluciones obvias, en problemas complejos Postular: Si no hay acceso al usuario o cliente, o si se est creando un producto que no tiene precedente.
Discutir y formular:
3.2
3.2.1
Tcnicas de educcin de requisitos

El muestreo
El muestreo es el proceso por el cual se seleccionan de manera sistemtica elementos representativos de una poblacin. Existen numerosos motivos por los cuales un analista de sistema querr seccionar muestras representativas de datos para examinar o personajes que entrevistar, interrogar u observar. El muestreo agiliza el proceso, por medio de la recopilacin de datos seleccionados, y no de todos los datos de la poblacin. El muestro reduce la parcialidad de los datos recopilados. Se deben seguir cuatros pasos para lograr un buen diseo del muestro. 1. Denir con precisin los datos que se van a recopilar o a describir. Se debe saber que se harn con los datos antes de recopilarlos. Se deben identicar las variables, atributos y los datos asociados a los artculos que sern recopilados en el muestreo. Se debe considerar el mtodo de estudio (entrevista, cuestionario, etc), el objetivo y la caractersticas de la informacin que se va a investigar. 2. Delimitar la poblacin sujeta a seleccin de muestras. Se decide sobre las siguientes cuestiones: que tiempo sern sucientes tomar ? . Se incluir un solo nivel de la organizacin ?.
CAPTULO 3. EDUCCIN DE REQUISITOS 3. Elegir el tipo de muestra. Existen cuatro tipos bsicos de muestras:
64
De oportunidad: son deterministicas y no tienen restricciones ni soporte probabilstico.. Dirigidas: se elige a un grupo de individuos que conozca y este interesado en el nuevo sistema de informacin. Aleatorias simples: lista numerada de la poblacin donde cada uno de los integrantes de la lista tienen la misma probabilidad de ser elegidos. Aleatorias complejas: Sistemtico: ensima persona de una lista Estraticado: se identican subpoblaciones (estratos), para luego seleccionar a sujetos de estas subpoblaciones. Por grupos: selecciona a un grupo de gentes o documentos 1. Decidir el tamao de la muestra. Debe ser un nmero absoluto (no un porcentaje). Muchas veces se limita por el costo que involucra, o por el tiempo disponible del analista de sistemas, o de los integrantes de la organizacin. Pasos a seguir para determinar el tamao de muestra: 1. Establecer el atributo que se va a tomar como muestra 2. Localizar la base de datos o el informe donde se encuentran los atributos 3. Examinar el atributo y estimar p (proporcin de la poblacin) que cuente con el atributo 4. Determinar el intervalo estimado aceptable i . 5. Elegir el nivel de conanza y encontrar el coeciente de conabilidad en un tabla 6. Calcular el error estndar de la muestra Vp, vp = i/z.7. Determinar el tamao de la muestra, n, mediante: n = ( p( 1 - p) / Vp2 ) + 1
3.2.2
Tipos de informacin que se obtiene durante la investigacin
Conforme el analista se va adentrando en la organizacin y en sus requerimientos de informacin, se torna importante examinar los diferentes tipos de datos que aportan informacin, que de otra manera no podra obtenerse. Los datos concretos revelan la trayectoria de la organizacin y hacia donde se dirige segn sus miembros. El analista debe examinar los datos cualitativos y cuantitativos. Anlisis de datos cuantitativos Informes corporativos. La ley exige por mandato y regulacin que las rmas proporciones informes corporativos o informes anuales para la emisin de acciones publicas. El estado de resultado es otra forma de estos informes.
65
Informes de desempeo. Comparan los resultados reales con los planeados. Sirve para determinar si la tendencia de la diferencia se acorta o se amplia. Registros. Contienen actualizaciones peridicas de lo que ocurre en la empresa. Formas para la captura de datos. Antes de que se disponga a modicar el ujo de informacin dentro de la organizacin, , debe comprender la operacin del sistema vigente, para ello recopilara y catalogara copias en blanco de cada una de las formas (ociales y extraociales) que se utilizan. Anlisis de documento cualitativo Estos documentos no siguen lineamientos preestablecidos y su anlisis se vuelve fundamental para comprender como los integrantes de la organizacin estn involucrados en el proceso de la organizacin. Incluyen: Memorndum.. Se debe considerar quienes son los emisores y quienes los reciben. Normalmente uyen hacia abajo. El anlisis de su contendido revela valores, actitudes y creencias de los miembros de la organizacin. Avisos pegados en tableros y reas de trabajo. Reejan la cultura ocial de la organizacin. Manuales de procedimientos y de polticas de la empresa. Deben analizarse siguiendo lineamientos preestablecidos. Gran parte de la informacin, tanto cuantitativa como cualitativa, no es de uso corriente; ms bien, se encuentran almacenadas en archiveros. Ejemplo 3.1 Registros actuariales, presupuestos y los informes de ventas.
3.2.3
La entrevista
Es una conversacin dirigida con un propsito especico, que se basa en un formato de preguntas y respuestas. En la entrevista desea conocer tanto las opiniones como los sentimientos del entrevistado acerca del estado actual de los sistemas, sus metas personales, de la organizacin y de los procedimientos informales. En la entrevista necesitara crear un clima de conanza y entendimiento, sin perder en control de la misma. Planeacin de la entrevista Son cinco los pasos para la planeacin de la entrevista. 1. Lectura de antecedentes. Consulte y comprenda el mayor numero posible de antecedentes de los entrevistados y de la organizacin, esto le ayudara a elaborar un vocabulario, que eventualmente, lo capacitara para redactar las preguntas de la entrevista, de manera tal que estas sean comprendidas por su entrevistado y a aprovechar al mximo el tiempo de la entrevista no haciendo preguntas generales sobre antecedentes de la organizacin. 2. Establecimiento de los objetivos de la entrevista. Se establecen con base a los antecedentes que consulte y a su experiencia particular. Deben existir aspectos fundamentales referentes al procesamiento de la informacin y al proceso de la toma de decisiones sobre las cuales se deseara hacer preguntas, estn incluyen: fuentes de informacin, formatos de la informacin, la frecuencia de la toma de decisiones, la calidad de la informacin y el estilo de la toma de decisiones.
CAPTULO 3. EDUCCIN DE REQUISITOS 3. Seleccin de los entrevistados. Se deben incluir a gente clave en cada nivel.
66
4. Preparacin del entrevistado. Prepare a las personas que entrevistara. El tiempo que ellos le dedican a Ud. no se lo dedican a la Organizacin. 5. Seleccin del tipo y estructura de las preguntas. El esencia de la entrevista se basa en uso de tcnicas inquisitivas adecuadas. Las preguntas tienen cierto tipo de estructura. Los dos tipos bsicos son cerradas y abiertas. Es posible estructurar su entrevista bajo tres patrones diferentes: el de estructura de pirmide, de estructura de embudo y la estructura de diamante. Cada uno de ellos adecuado para condiciones particulares. Preguntas abiertas Incluyen a aquellas tales como: Que opina acerca del uso de redes informticas en las pequeas organizaciones ? y Podra explicar el uso de prototipos ?. Abiertas son las opciones que tiene el entrevistado para responder. Algunas de las ventajas de utilizar preguntas abiertas son: simplican las cosas para el entrevistado; permiten al entrevistador, seleccionar el vocabulario del entrevistado, lo que reeja su educacin, valores y creencias.; proporcionan una riqueza de detalla; revelan nuevas alternativas sobre preguntas no consideradas; hace mas interesante la entrevista, permite una mayor espontaneidad; facilita el estilo del entrevistado; se suele utilizar como alternativa cuando el entrevistado no se encuentra preparado. Algunas de las desventajas de las preguntas abiertas son: permiten preguntas que pueden generar demasiada informacin irrelevante; la posible perdida del control de la entrevista; respuesta con demasiado tiempo para la cantidad de informacin que aportan; pueden dar la apariencia de que el entrevistador no se prepara o que el mismo se encuentra expedicionando sin tener claros los objetivos. Preguntas cerradas Podra ser Cuntos especialistas conforman su equipo de trabajo ?. Las posibles respuestas se hallan limitadas. Un tipo especial de pregunta cerrada es la bipolar. Es muy limitada al tener solo dos respuestas alternativas. Algunas ventajas de las preguntas cerradas son: ahorran tiempo; facilitan la comparacin entre entrevistas; llegan al punto de inters; mantienen el control de la entrevista; cubren rpidamente diversos aspectos; obtienen datos de relevancia. Sin embargo las desventajas de la utilizacin de preguntas cerradas son importantes, entre otras, se citan las siguientes: aburren al entrevistado; pierden la riqueza del detalle; se pueden perder ideas centrales por el punto anterior y no favorecen un clima de armona entre el entrevistado y el entrevistador. Sondeos Es un tercer tipo de pregunta. La pregunta mas simple es el Por qu ?.El propsito del sondeo es ir ms all de la respuesta inicial para obtener un mayor signicado, y aclarar o ampliar los puntos del entrevistado. El sondeo se puede realizar mediante preguntas cerradas o abiertas.
67
La mayora de los entrevistadores principiantes son reticentes acerca del sondeo, y en consecuencia, aceptan respuestas superciales. Si el sondeo se hace de una manera sistemtica y determinada, le servir para mostrar a su interlocutor que escucha lo que dice, pensando al respecto y respondiendo adecuadamente. Errores en las preguntas Al formular de antemano las preguntas podemos corregirlas. Dentro de los tipos de preguntas decientes tenemos las tendenciosas y las preguntas dobles. Las preguntas tendenciosas tienden a dirigir al entrevistado hacia la respuesta que Ud. quisiera escuchar. Las preguntas dobles son aquellas que en una sola contienen, de echo, dos preguntas diferentes. Normalmente no deben utilizarse por que se corre el peligro que el entrevistado solo conteste una de ellas. Orden de las preguntas en una secuencia lgica. Existen tres formas de organizar sus preguntas: inductivo (piramidal) deductivo (embudo) combinacin de ambas (diamante) Muchos entrevistadores consideran que las entrevistas se asemejan a conversaciones, y por lo tanto, deberan de carecer de una estructura formal, tanto las preguntas como su secuencia. Para una entrevista ntegramente estructurada todo se planea de antemano y tal plan se sigue de manera estricta.. Las preguntas cerradas son la esencia de una entrevista completamente estructurada. Registro de la Entrevista Registre los aspectos mas importantes de su entrevista. Puede usar grabadora, cuaderno de notas, etc. , lo importante es que se lleve un registro permanente durante la entrevista De avisar al entrevistado del medio de registracin que utilizara, como tambin el objetivo de dicha registracin. Sea honesto y explcito en sus declaraciones y garantice la conabilidad de la registracin. La grabacin posee algunas ventajas: proporciona un registro preciso y completo; libera al entrevistador para escuchar y responder con mayor rapidez; permite reproducir la entrevista, permite un mayor contacto visual, posee las siguientes desventajas: puede poner nervioso al entrevistado; puede reducir la capacidad de atencin del entrevistador; inconvenientes de bsquedas en la cinta de pasajes de la entrevista. El tomar notas tambin tiene sus ventajas: mantiene alerta al entrevistador; sirve para recordar preguntas importantes; muestra el inters del entrevistador en la entrevista y de su preparacin para la misma: Tambin las notas no dejan de tener inconvenientes: perdida de contacto visual; perdida de la continuidad en la conversacin, interrupciones, etc.. Antes de la entrevista comunquese con su entrevistado para conrmar el lugar y la hora. Antes de la entrevistas todo tenga en perfectas condiciones y listo.
CAPTULO 3. EDUCCIN DE REQUISITOS Realizacin de la entrevista
68
Comience en el momento establecido. Saludo ha su entrevistado. Verique que todo este en perfectas condiciones. Recuerde a su interlocutor el grado de detalles que quiere en las respuestas (si fuesen abiertas). Controle el uso del tiempo. Manjelo adecuadamente. Existen algunos problemas que se pueden presentar durante la entrevista, por ejemplo: el entrevistado percibe que su autoestima se encuentra amenazada; puede llegar a tener reacciones emotivas a temas conictivos, puede llegar a malentender las preguntas respecto a la sucesin de los acontecimientos; puede apegarse a formas tradicionales, puede llegar a equivocarse en el momento de inferir sobre lo observado; puede llegar a competir con Ud. Sobre el tiempo de la entrevista. ; puede olvidarse e inclusive mentir sobres hechos importantes. Trate de cubrir todo el material de la entrevista en no mas de 45 minutos (o una hora). Concluya su entrevista en el momento prometido. Solicite al entrevistado si desea acotar algn otro detalle al nalizar la misma. Informe al entrevistado sobre los pasos posteriores. Luego necesita redactar un informe escrito de la entrevista que rescate la esencia de la misma. De esta manera se asegura la calidad de los datos.
3.2.4
Uso de Cuestionarios
Constituyen una tcnica de recopilacin de informacin que permite a los analistas recoger opiniones, posturas, conductas y caractersticas de las diversas personas de una organizacin. Las respuestas que se obtienen de cuestionarios con preguntas cerradas pueden cuanticarse las de preguntas abiertas se pueden analizar e interpretar de maneras distintas. Los cuestionarios pueden servir para determinar que tan difundido o limitado se encuentra un sentimiento. Pueden verse como una forma rpida de recopilar cantidades masivas de datos acerca de la opinin de los usuarios al sistema actual; que problemas experimenta en sus trabajos, que es lo que esperan que se modique o se cambie. Lo primero es denir que buscamos con el uso de cuestionarios, para ello se describen a continuacin una serie de lineamientos para establecer la conveniencia de los cuestionarios: Las personas a quienes se interrogara se encuentran dispersas Los involucrados en el proyecto son muchos y se necesita conocer un porcentaje de aprobacin o no del mismo. Se lleva a cabo un estudio exploratorio y deseamos medir la opinin general Deseamos sondear el problema que presenta el sistema actual. En los cuestionarios no podemos profundizar una pregunta y/o analizar trminos difciles, esto implica para el analista que las preguntas deben ser completamente transparente; el ujo del cuestionario convincente; se debe anticipar a las respuestas de las preguntas, y que el manejo del cuestionario sea planicado con todo detalle.
Al igual que en las entrevista, tambin se cuentan con preguntas abiertas y cerradas. Las preguntas abiertas son adecuadas en aquellas circunstancias en que se desea conocer la
69
opinin de los miembros de una organizacin sobre algunos aspectos del sistema., Tambin son tiles para explorar situaciones. Las preguntas cerradas deben utilizarse cuando somos capaces de enumerar de antemano las respuestas posibles. Las respuestas deben ser mutuamente exclusivas. Tambin podemos utilizar preguntas cerradas cuando queremos explorar una gran muestra de personas. En el uso de cuestionarios tambin es necesario redactar de forma adecuada los mismo para que sean efectivos. En la eleccin del vocabulario utilice uno acorde con el utilizado en la organizacin. Mantenga una redaccin sencilla. Sea especico, evite, sin embargo, evite preguntas especicas Utilice preguntas cortas. Evite preguntas censurables, dirija las preguntas a las personas indicadas (esto es, aquellas que sean capaces de responder). Uso de escalas en los cuestionarios Escala es el proceso de asignar nmeros u otros smbolos a un atributo o caractersticas con el n de poder medirlo. Con frecuencias las escalas son arbitrarias y no llegan a ser nicas. El analista necesita disear escalas para medir actitudes o caractersticas de la gente o contar con un elemento de juicio sobre temas de un cuestionario. Si deseamos medir actitudes de los cuestionarios, las respuestas pueden combinarse o agruparse para que nos informen de tales actitudes. Si no interesamos en la manera de evaluar los balances mensuales, consideraremos entonces como jueces a los consultados. En este caso no importara la magnitud de las diferencias de actitud de los que contestan el cuestionario. Existen cuatro formas de escalas de medicin, cada una de ellas ofrece diferentes grados de precisin: 1. Nominal: se utilizan para clasicar objetos. 2. Ordinal: Tambin permiten la clasicacin, sin embargo, la diferencia es que las escala ordinal implica adems un arreglo por categoras. 3. De intervalo: tienen la caracterstica que la diferencia que existe es la misma entre los intervalos de cada uno de los nmeros. 4. Proporcional: Son similares a las de intervalos porque se supone que los intervalos entre los nmeros son iguales: sin embargo, las escalas proporcionales cuentan con un cero absoluto. Existen dos parmetros de desempeo cuando se construyen las escalas: la validez y la conabilidad. La validez es el grado con el que la pregunta determina lo que el analista intenta medir. La conabilidad es un parmetro de consistencia. Si el cuestionario da el mismo resultado al repetirlo bajo las mismas condiciones, se dice que el instrumento cuento con una consistencia externa. Si el cuestionario contiene fragmentos, y estos generan resultados equivalentes, se dice que tiene una consistencia interna. Ambas son importantes. La elaboracin de una escala es tarea seria. El analista puede elegir entre invertir una parte importante de su tiempo para elaborar escalas que otorguen validez y conabilidad,
70
o bien, solicitar la respuesta a una serie de preguntas y dar seguimiento al cuestionario por medio de entrevistas, investigaciones y observaciones, o bien otra tcnica. Si elaboramos escalas, tenemos las siguientes opciones: Escalas arbitrarias: mide los que se intenta medir Escala por consenso: involucra a un grupo de jueces, quienes ayudan a evaluar los tpicos que el analista eligi para el cuestionario. Anlisis de temas: involucra la evaluacin de los tpicos por un pequeo grupo de quienes respondern, similar al grupo que recibir el cuestionario denitivo. Cada tpico se analiza en funcin de su conveniencia. Factorizacin: es el procedimiento estadstico por medio del cual se agrupan objetos similares. Las escalas mal echas origina problemas de: Indulgencia: los que responden los cuestionarios son pocos evaluadores Tendencia central: cuando el que responde calica todo como promedio. Efecto halo: la impresin que deja un pregunta se acarrea en la siguiente. Diseo y aplicacin de cuestionarios Un cuestionario bien diseado y de relevancia elimina cierta resistencia para responder. Algunos lineamientos para ordenar el contenido del cuestionario y obtener mejores resultados: Para el formato del cuestionario: disponga de suciente espacio en blanco, disponga de suciente espacio para las respuestas, utilice crculos para las respuestas, utilice los objetivos como ayuda para establecer el formato y mantenga un estilo consistente. Para el orden de las preguntas no existe una forma nica pero deber prever que las preguntas de importancia para quien contesta van primero, se deben agrupar las preguntas del mismo tema, use las tendencias asociativas y no olvide de plantear primero los temas de menor controversia. La decisin acerca de a quien se dar el cuestionario se toma al momento de establecer los objetivos de la informacin que se busca. Eventualmente se cuenta con varias alternativas para la aplicacin de un cuestionario; y la eleccin del mtodo con frecuencia lo establecen las circunstancias de la empresa. Dentro de las opciones tenemos : 1. Reunir a todas las personas en un solo sitio 2. Entregar personalmente los cuestionarios en blanco y recogerlos una vez que se encuentren completos. 3. Permitir a quienes contestan el cuestionario que durante las horas de trabajo lo respondan por su cuenta y posteriormente lo depositen en un buzn central 4. Enviar por correo el cuestionario a aquellos empleados de sucursales remotas, estableciendo fechas lmites, proporcionando instrucciones y reembolso postal.
71
3.2.5
Uso de arreglos Q
Una tcnica de recopilacin de informacin, que esta relacionada con los cuestionarios es la llamada metodologa Q. Esta metodologa consiste en la estructuracin de un arreglo-Q, el cual fuerza a que las respuestas se apeguen a una distribucin normal, que es adecuada para agrupar a los que responden, con base en sus opiniones sobre un tpico particular. A partir de las entrevistas, las observaciones y el muestreo de datos de archivos, el analista crea una serie de tarjetas con postulados o conceptos para que los que responden las ordenen. Cada tarjeta contiene por separado un postulado; en teora, al agrupar las tarjetas, se tiene todo el dominio posible de actitudes sobre el tpico en cuestin. Se instruye a quien responde para tomar un paquete de tarjetas y separarlas en varias pilas. Para facilitar lo anterior, el analista prepara entre ocho y diez tableros de arreglo-Q, de tal forma que la seleccin de varios individuos puede procesarse simultneamente. El nmero de pilas que se van a ordenar depende del nmero de postulados; cuanto mayor sea el nmero de postulados, ms pilas debe haber. Se le pide a quien responde que coloque un nmero especico de tarjetas en cada pila. El nmero de tarjetas requerido en cada pila tiene que corresponder a un perl discreto de distribucin normal. Esta tcnica se utiliza para identicar subgrupos dentro de una poblacin. Una de las principales ventajas de la utilizacin del arreglo-Q consiste en que es un tcnica ecaz para la recopilacin de datos, ya que requiere de muy pocas personas para que respondan un cuestionario. Se puede utilizar la metodologa de la siguiente manera: 1. Entrevistar a una muestra de miembros de todos los niveles y reas funcionales de la organizacin, para conocer sus inquietudes. 2. Redactar una serie de premisas que capture de manera adecuada el dominio posible de las actitudes y opiniones de los miembros de la organizacin, y que tenga relevancia para el estudio de sistemas. 3. Construir tableros de arreglos-Q, con una distribucin normal discreta, y tarjetas de 3 x 5 que contengan las premisas ms relevantes. Indicar sobre los tableros el nmero de premisas que correspondan a cada pila. 4. Evaluar el arreglo-Q con un grupo de personas. Volver a escribir cualquiera de las preguntas pera mejorar su claridad 5. Aplicar el arreglo-Q modicado a grupos de 8 a 10 personas 6. Registrar el arreglo de premisas de cada encuestado 7. Llevar a cabo una factortizacin para la determinacin de los subgrupos 8. Observar las premisas que queden en los extremos de la distribucin normal para las personas que quedaron incluidas en un subgrupo. Busque similitudes para obtener un entendimiento de las actitudes y opiniones del subgrupo. Nombre los subgrupos.
72
3.2.6
Brainstorming
Es una tcnica de grupo sencilla para la generacin de ideas. En un ambiente libre de criticas, la gente sugiere ideas. Una sesin de brainstorming funciona bien con 4 a 10 personas. Una persona es el lder, pero el papel del lder se reduce a, prcticamente, abrir la reunin ms que a restringirla o controlarla. Como se aplica el brainstorming para propsitos de educcin de requisitos software ? El brainstorming puede ser til en: La generacin de mltiples puntos de vistas del problema La formulacin del problema en forma diferentes Usando correctamente, puede ayudar a superar algunas de las dicultades de la educcin de requisitos: Estimula la imaginacin contribuyendo a que los usuarios sean consientes de sus necesidades Ayuda a construir una ms completa gura de las necesidades de usuario Evita la tendencia de centrarse en reas estrechas demasiado pronto Es una tcnica fcil de aprender Fases de una sesin Llevar a cabo una sesin de brainstorming conlleva realizar distintas fases: preparacin, generacin de ideas (los participantes ofrecen tantas ideas como puedan, sin discutirlas) y consolidacin (discusin, revisin y organizacin de las ideas). Fase de preparacin La preparacin para una sesin de brainstorming requiere: La identicacin de participantes: clientes, usuarios, e ingenieros de software La designacin del lder. La planicacin de la sesin con los participantes La preparacin de la sala
CAPTULO 3. EDUCCIN DE REQUISITOS Fase de generacin
73
La sesin es iniciada por el lder, que expresa una instruccin general del problema. Los participantes expresan libremente, en turno o espontneamente, dependiendo del criterio del lder. No hay criticas sobre las ideas, se fomentan las ideas no convencionales, as como embellecer o combinar las ideas de otros. Las ideas deben estar visibles durante la sesin, por lo que una persona puede registrar todas las ideas, o bien utilizar otros mtodos, como una pizarra, hojas encima de la mesa, ppelografos, etc. La sesin naliza cuando el lder considera que hay sucientes ideas registradas. Fase de consolidacin Durante esta fase las ideas se organizan segn criterios de uso, en cuatro pasos: 1. Se revisan las ideas para clasicarlas. Puede que sea necesario volver a escribir algunas de las ideas para que sean comprendidas por todos, o tambin, se pueden reconocer dos o ms ideas como esencialmente la misma, en este caso ser necesario agruparlas. 2. Se descartan las ideas que no sean utilizables 3. Se discuten las ideas restantes con el objetivo de ordenarlas imponiendo prioridades: los requisitos que son absolutamente esenciales, los buenos pero no esenciales, los apropiados para posteriores versiones del sistemas, pero no para la que se est construyendo. 4. Despus de la sesin, se registran todas estas ideas, con sus prioridades u otros comentarios.
3.2.7
Entorno PIECES
PIECES proporciona una estructura del proceso de educcin para analistas poco experimentados que consta de seis categoras de aspectos que se deben explorar, y que pueden ser ajustados segn el dominio de la aplicacin PIECES es un acrnimo formado por las iniciales de las seis categoras que propone: Rendimiento, informacin y datos, economa, control, eciencia y servicios. Rendimiento del sistema El rendimiento se mide de dos formas: Throughput, o nmero de tareas completadas en unidad de tiempo. Tiempo de respuesta, o tiempo requerido para ejecutar una nica tarea. Entonces, para educir requisitos de rendimiento hay que identicar las tareas que el sistema debe realizar y medirlas por cada tipo de tarea.
CAPTULO 3. EDUCCIN DE REQUISITOS Informacin y datos a obtener del sistema Un sistema de informacin proporciona: Datos tiles para la toma de decisin.
74
Acceso a la clase correcta de informacin, en el momento adecuado, en la cantidad justa y en forma utilizable. Si los usuarios tienden a no usar el sistema puede que el tipo de informacin proporcionado no sea correcto. Si los usuarios expresan frustracin, o es que hay mucha informacin o es que no se da en el formato adecuado. Economa. Factores de coste relacionados con el uso de un sistema son: Nivel de servicio, que es una medida del rendimiento del sistema. Para algunos de los sistemas, la demanda puede variar en cuestin de minutos o de horas. Pero a los usuarios lo que les gusta es tener un nivel de servicio estable. Exceso de capacidad, que puede implicar procesadores adicionales, redes, estructuras de datos internos, que mantengan un servicio estable de rendimiento, cuando la demanda suele venir a picos. As, comprendiendo cul es la carga esperada sobre el sistema y el nivel de servicio apropiado se podr equilibrar el nivel de servicio y el exceso de capacidad. Control Los procesos normalmente se disean con un rendimiento y unas salidas predecibles. Los sistemas de informacin dan informacin acerca del estado de dichos procesos. Si el proceso se desva de su rendimiento esperado, el control toma una accin correctora. Tipos de control: Seguridad: los accesos al sistema son restringidos segn sea el usuario que intenta acceder o por el tipo de informacin. Auditoria: capacidad de ver, monitorizar o reconstruir el comportamiento del sistema durante o despus de un hecho. Eciencia La eciencia es una ratio de recursos resultantes en trabajo til del total de los recursos empleados. Es una medida del desperdicio de recursos dedicados a realizar una tarea. Algunas ineciencias se maniestan como redundancia innecesarias de llevar a cabo un clculo ms de una vez, de un pobre algoritmo, de adquirir datos La diferencia con la economa es: Para mejorar la economa se debe reducir el total de recursos dedicados Para mejorar la eciencia hay que reducir el desperdicio en el uso de aquellos recursos.
CAPTULO 3. EDUCCIN DE REQUISITOS Servicios proporcionados por el sistema
75
Un sistema software normalmente proporciona servicios a los usuarios, y a su vez estos usuarios proporcionan servicios a los clientes. Por lo tanto, se educen requisitos preguntando: A los usuarios, que clases de servicios necesitan del software y como deberan proporcionarse estos servicios A los clientes, que clases de servicios son necesarios y como el software puede ayudar a proporcionar estos servicios. Adems, el nuevo sistema software puede tambin proporcionar servicios a otros sistemas software, y habra que averiguar sobre las interface entre los sistemas. Un aspecto importante es como el sistema software puede proporcionar estos servicios: Dando asistencia automatizada a los usuarios, quienes seguirn haciendo el mismo trabajo esencialmente de la misma forma, o Proporcionando una oportunidad a los usuarios para hacer un trabajo diferente en diferentes formas.
3.2.8
Anlisis de mercado
Algunos aspectos no pueden ser solo resueltos educiendo requisitos de los usuarios directos del sistema, sino tambin de los directores de los departamentos implicados y de los departamentos que estn por encima. El anlisis de mercado es una actividad comn de la mayora de empresas que venden productos. Las empresas necesitan conocer el mercado antes de construir el producto. Pero, quienes hacen el anlisis de mercado ? En las grandes empresas, los especialistas de anlisis de mercado En las pequeas, se contratan consultores Hay diversos aspectos en el anlisis de mercado: El anlisis de mercado observa cuidadosamente los productos similares de los competidores. Se identica lo bueno a copiar y lo malo a evitar. La investigacin de mercado implica recoger datos estadsticos sobre los productos comprados y se identican las tendencias en esos datos para predecir las necesidad de futuros productos. Cuestionarios de clientes, diseados cuidadosamente por expertos, pueden educir informacin muy detallada de las necesidades de compradores y usuarios potenciales de un paquete de software. En la especicacin de requisitos software, algunos de estos requisitos puede ser obtenidos de la identicacin de las caractersticas de otros productos de la competencia, por ejemplo, a travs de un anlisis de mercado previo.
3.2.9
Anlisis de factores crticos
Esta aproximacin de educcin consiste en identicar y concentrarse en un pequeo conjunto de factores crticos de los que depende la efectividad del sistema. Consta de los siguientes pasos:
CAPTULO 3. EDUCCIN DE REQUISITOS 1. Comprender la operacin del sistema 2. Identicar factores crticos para que el sistema sea efectivo
76
3. Identicar la fuerza y la debilidad del sistema respecto de cada uno de estos factores 4. Identicar reas de problemas y oportunidades 5. Reunir los detalles relevantes de estos factores que mejoren el rendimiento del sistema. Para educir detalles se puede usar un proceso estructurado orientado a objetivos 6. Formular requisitos usando estos detalles Esta tcnica proporciona un proceso de educcin sistemtico, aunque la identicacin de los correctos factores de xito crticos puede convertirse en un reto. Es especialmente til tratando dicultades tcnicas y aspectos tcnicos de la educcin de requisitos.
3.2.10
JAD (Joint Applicatin Design)
Es una tcnica para promover la cooperacin, comprensin, y equipo de trabajo entre compradores, usuarios y desarrolladores. Proporciona un proceso que facilita la creacin de una visin compartida de lo que el sistema debera ser. Principios sobre los que se apoya el JAD Dinmica de grupo, en la que se enriquecen, complementan e integran las visiones parciales que tienen los participantes en el proceso de analizar el problema. Uso, en las reuniones, de ayudas visuales para mejorar la comunicacin y la comprensin Mantenimiento de un proceso organizado racional, en el que los papeles de cada uno de los participantes estn perfectamente denidos. Filosofa de documentacin lo que ves es lo que obtienes con formularios de documentos estndares que se rellenan y se endosan por todos los participantes en una sesin. Fases en un JAD Se distingue cinco fases en un plan JAD: En la que se dene todo aquello que se necesita para gestionar la aplicacin que se esta analizando, incluyendo la perspectiva del usuario y los propsitos, el alcance y los objetivos del proyecto. Las fuentes del proyecto pueden ser distintas: Algunos pueden proceder de las especicaciones de los usuarios Otros proyectos son el resultado de un concianzudo anlisis de mercado
Primera: Denicin del proyecto.
CAPTULO 3. EDUCCIN DE REQUISITOS Tambin hay proyectos originados por el capricho de la direccin
77
Pero no importa cual es el origen del proyecto, si es un capricho o un anlisis detallado. A partir de ese momento hay que convertir los requisitos del proyecto, vengan en la forma que vengan, en una completa especicacin de usuario que pueda ser manejada por el departamento de desarrollo.
Entrevista a la direccin. Antes de reunir, analizar y documentar detalladamente las especicaciones del sistema es necesario conocer que quiere la direccin. Estos requisitos son de muy alto nivel y pueden recogerse en las entrevistas con la direccin. Adquirir informacin para la gua de denicin de gestin. Para adquirir la informacin especicada necesaria en la gua de denicin de gestin. Bsicamente es un formulario de dos columnas, en la primera se describen los propsitos del sistema en cuanto a los tpicos de:; alcance del sistema, objetivos del proyecto, funciones, restricciones, requisitos de recursos adicionales de usuario, supuestos anteriores a la sesin, cuestiones abiertas anteriores a la sesin y lista de participantes; en la segunda columna se describe por que se disea el sistema bajo los mismos tpicos. Para abordar la adquisicin de la informacin de los usuarios lo mejor es comenzar con una breve entrevista con los directores de usuarios Seleccionar el equipo JAD. Es muy importante pues de l depende el xito de una sesin. Consta de un: Patrocinador ejecutivo. Es la persona del rea de usuarios con mayor autoridad para tomar decisiones en todos los aspectos del proyecto, pues ser el ultimo responsable del producto que se construye, y debe tener una personalidad adecuada. Sus funciones son: Dar la estrategia de alto nivel del sistema Tomar decisiones de nivel ejecutivo y compromisos que puedan afectar a los requisitos Asegurar que los participantes de alta direccin se comprometan con el mtodo JAD as como con el proyecto. Antes de la sesin tomar parte de las discusiones con el jefe de JAD para denir los propsitos alcance y objetivos del proyecto. Deber estar en la sesin y disponible cuando lo requiera cualquier integrante de la sesin Supervisa las cuestiones abiertas, que deben ser resueltas por las personas asignadas para ello durante la sesin. El jefe de JAD. Debe ser una persona neutral, que no sea procedente del departamento de usuarios ni de desarrollo. Si no puede ser, mejor que sea del rea de desarrollo. Sus funciones principales son: Responsable de que el esfuerzo empleado con JAD tenga xito: de su realizacin y planicacin.
CAPTULO 3. EDUCCIN DE REQUISITOS Moderador de las reuniones
78
Dirige las entrevistas con el patrocinador y con el director del departamento de usuarios Supervisa la creacin, revisin y distribucin del documento nal Requiere estar familiarizado con todos los aspectos del JAD, tener conocimientos de conceptos de procesamiento de datos, experiencia en el rea de aplicacin y tener capacidad para comprender y facilitar dinmicas de grupo. Escribiente. Es una persona designada en la sesin para registrar las decisiones. Demanda una capacidad analtica y de sus notas evolucionara el documento nal de la sesiones. Sus funciones son: Reunirse con el jefe para hablar de su papel en las reuniones y de los formularios y tipos de registraciones que utilizara Revisar, luego de las sesiones, las notas para poder preparar el documento nal Participantes de dedicacin plena. Se incluye a todos los usuarios y personal de desarrollo involucrados en la toma de decisiones en la especicaciones del sistema. Los usuarios saben lo que necesitan y los del equipo de desarrollo saben como estas necesidades afectan el entorno del ordenador. Es necesario la presencia de todos en todas la reuniones y en estas todos son iguales (la categora de cada uno no da privilegios en la sesin). El rango de los desarrolladores abarca desde programadores a jefes de proyectos y sus funciones son: Proporcionar informacin sobre sistemas existentes y las tecnologas disponibles Responsabilizarse de los documentos resultantes de las reuniones JAD Escuchar a los usuarios para establecer sus requisitos, y asegurarse que son comprendidos y realizables. Los participantes claves son los usuarios, pues tienen una visin del sistema entero y va a determinar gran parte de los requisitos. El rango va desde operadores, pasando por supervisores, hasta los altos mandos de la direccin. Puede llegar a ser importante que tengan conocimientos sobre computacin para evitar problemas de comunicacin. Usuarios de consulta. Son usuarios que se ven afectados por la construccin del sistema, pero solo en un rea particular. Participan si sus conocimientos son requeridos. Construir la gua de gestin. Se dena como aquello que se necesita para gestionar la aplicacin que se esta especicando. En ella se escribe la perspectiva del usuario, y se incluyen los propsitos, alcances y objetivos del proyecto. Esta gua se manda a todos los participantes para que puedan leerla antes de la sesin.
79
Planicar la sesin. El tiempo requerido para completar un JAD depende del alcance del proyecto, y de la restriccin de tiempo. Estas sesiones es aconsejables realizar al medio da en algn lugar destinado para tal n y se debe establecer una fecha tope para la realizacin de la misma. Una vez jada la fecha, lugar y hora de la sesin se comunica a todos los miembros de la sesin.
Segunda: Investigacin
Familiarizacin con el sistema. Hasta este momento se tiene una idea clara de lo que la direccin quiere del sistema, pero no se tiene la misma idea sobre el funcionamiento del sistema que actualmente realzale trabajo. En esta situacin debe familiarizarse con todas las especicaciones que se hayan preparado del nuevo sistema hasta el momento. El mejor camino para familiarizarse con las funciones del sistema actual es establecer reuniones con los usuarios y el equipo de desarrollo. Realizar visitas al lugar de trabajo, observar el ujo de trabajo, mirar los menues, si ya existe un sistema, revisar las salidas y discutir los cambios. En las reuniones con el equipo de desarrollo tratara de conocer tcnicamente como trabaja el sistema, desde la perspectiva del procesamiento de datos, deber discutir la perspectiva del sistema de la gente de desarrollo, con los organigramas del sistema y de la base de datos, discutir el proyecto en general: su historia, opiniones sobre el sistema, cambios que deberan hacerse, debilidades del sistema, etc. Investigar y documentar el ujo de trabajo. Hay distintas formas de documentar. Normalmente se usan diagrama de ujos de datos (DFD). Dependiendo del alcance del proyecto se denir el ujo de trabajo existente, el nuevo o ambos. Se documenta solo los ujos de datos existentes si el nuevo ujo de trabajo depende de algunas decisiones que deben tomarse en la sesin. Se documenta solo los ujos de trabajos nuevos si se esta especicando un sistema nuevo que no reemplaza a otro.. (Enfoque : Tradicional, estructurado o OO). Cuando no se cumple ninguna de las condiciones anteriores se pueden documentar ambos ujos de trabajo. Se muestran los ujos de trabajo existentes a los usuarios para efectuar los cambios adecuados que se reejen las especicacin del nuevo sistema. Reunir especicaciones preliminares. Depende de lo que se quiera lograr en la sesin (denir todos los elementos de una nueva base de datos o unas pocas pantallas nuevas). Pero lo que se debe recopilar son los datos elementales, pantallas e informe Datos elementales existentes en el sistema actual, modicados Flujo de pantallas donde se muestre como se suceden, descripcin de las pantallas, ejemplos de pantallas existentes, prototipos de nuevas pantallas o diseos preliminares y mensajes de pantallas. Descripcin de informes (frecuencia, cantidad, calidad, copias necesarias, lista de distribucin, etc.) ejemplos de informes existentes y prototipo de nuevos informes. Toda esta informacin preliminar del sistema existente se obtiene del equipo de desarrollo. La informacin de nuevos prototipos procede de los usuarios.
80
Preparar la agenda de la sesin. La agenda se basa en lo aprendido de la preparacin de la gua de denicin de gestin, la realizacin de entrevistas para familiarizacin, documentacin del ujo de trabajo y de la recopilacin de especicaciones preliminares.
Tercera: Preparacin
El documento del trabajo. Es algo para comenzar a trabajar en la sesin. Es un punto de partida para denir las especicaciones, en el que todo es propuesto. El documento incluye lo que la gente sugiere antes de la sesin. El documento de trabajo tiene el mismo formato que el documento JAD denitivo. El documento sed enva a todos los participantes al menos una semana antes de que comience la sesin. Cuanto mas clara se presenten las especicaciones propuestas con menos dureza discurrir el proceso de tomar decisiones con todos los participantes reunidos. Preparar el guin para la sesin. Este dice que se tiene que hacer y cuando, y debe tener sentido para una sola persona, el jefe de JAD. El guin gua a travs de los temas de la agenda, recordando los temas que se deben cubrir y que formularios y medios audiovisuales usar. Tiene tres secciones: introduccin; asuntos a tratar; Notas Ayuda Visuales. Se pueden disear esquemas, preparar proyecciones. La reunin previa al JAD. El objetivo es establecer el compromiso con la empresa, resumir la metodologa JAD y distribuir y discutir el documento de trabajo. Preparar la sala de reuniones. El da anterior el jefe organiza la sala para acomodar los medios y los elementos necesarios para la sesin. La sesin JAD. Toda la informacin recopilada en las entrevistas sirve de base para los das de sesin.
Cuarta: Introduccin.
Introduccin. Se revisa los detalles administrativos acerca de cmo se desarrollara el encuentro. Se describe lo que se espera lograr, se realiza una visin global del sistema, se recorre la agenda de la sesin y se revisan los principales puntos de la gua de denicin de gestin. Discusin del documento de trabajo. Como ser: supuestos, ujo de trabajo, datos elementales, pantallas, informes y otros temas. Cierre de la sesin. Cuando se clausura la sesin se necesitara determinar quien recibir el documento nal. Se discute como los participantes van a revisar el documento y tambin, se pueden hacer algunas observaciones nales. El documento nal. El documento JAD es la culminacin de todo el proyecto JAD, sntesis que comprende de los acuerdos hechos durante la sesin.
Quinta: Elaboracin del Documento Final
81
Producir el documento nal. La produccin del documento nal se realiza actualizando el documento de trabajo con los aadidos y las eliminaciones anotadas por el escribiente. Hay que organizar toda la informacin segn el orden deseado. Con los formularios organizados y la tabla de contenidos completa se puede introducir toda la informacin de los formularios en el documento. Se puede crear cheros con plantillas estndares. Revisin del documento por los participantes. Tras introducir toda la informacin de los formularios del escribiente se tiene la primera versin, esta pasa por los controles para asegurarse que es clara y consistente con los formularios que involucra dos revisiones por separado de claridad y de exactitud. Este se distribuye nicamente a las personas que revisaran el documento. La reunin de revisin. A esta reunin asisten todos los participantes, incluso los que nada tengan que cambiar del documento nal. Se recorre el documento y se sugerirn diferentes tipos de revisiones. Si los cambios son mnimos, entonces la versin actual mas los cambios anotados puede servir como copia nal. Si los cambios son signicativos se necesita actualizar el documento y emitirlo de nuevo. El visto bueno nal. La aprobacin signica acuerdo sobre los contenidos del documento nal, incluyendo los cambios discutidos en la reunin de revisin. Las personas que rmaran el formulario de aprobacin fueron ya designadas en la sesin. El cambio de especicaciones despus del JAD. Las especicaciones seguirn cambiando, pero el documento representara un punto en el tiempo. El equipo de desarrollo precisara una forma de actualizar las especicaciones a medida que surjan nuevas requisitos de usuario. Si se usa el documento JAD como base para actualizar las especicaciones segn van cambiando, hay que hacer una copia de los chero del documento nal que ellos se encargaran de mantener.
3.2.11
Entorno de bucles adaptativos
El entorno de bucles adaptativos proporciona un entorno de procesos que enlaza fuertemente a usuarios, desarrolladores y sistemas, como JAD, educiendo los requisitos de los usuarios a travs de ciclos de aprendizajes. Los tres ciclos de aprendizaje se muestran en la gura siguiente. 1. Los desarrolladores son asistidos por los usuarios que, de esta forma, obtiene nuevos puntos de vista de sus requisitos. Mientras que, a travs de la reformulacin de los requisitos, los usuarios aprenden ms sobre los requisitos. 2. El sistema recibe presin para que evolucione a medida que los usuarios aprenden mas sobre como se puede usar el sistema. Y el sistema induce ese aprendizaje sobre los usuarios. 3. El sistema evoluciona por acciones de los desarrolladores que, por otra parte, obtienen una mejor comprensin del sistema a lo largo de su evolucin.
82
Sistema
Induce aprendisaje
Mejora la comprensin
Presin para evaluar
Acciones que hacen evolucioonar el sistema
Nuevas visiones
Usuario Desarrollador
Reformulacin de requisitos
Figura~3.2: Bucles Adaptativos
3.2.12
Observacin al comportamiento de la toma de decisiones y al ambiente de ocina
Se hace uso de la observacin para obtener informacin de los tomadores de decisin y su ambiente, tambin auxilia a conrmar lo que las entrevistas y los cuestionarios hubieran detectado, o para rebatir o anular lo que otros mtodos encontraron. Observacin de las actividades de toma de decisiones de un gerente tpico. Lo que un gerente hace no es otra cosa ms que proposiciones astutas en la mejor de la circunstancias. La observacin permiten saber como los gerentes procesan, comparten y utilizan la informacin en el cumplimiento de sus tareas. Pasos para identicar las actividades tpicas de toma de decisiones de un gerente: 1. Decida que observara 2. Decida el nivel de concrecin de las actividades observadas 3. Cree categoras que capturen de manera adecuada las actividades clave 4. Prepara escalas apropiadas, listas de vericacin u otros materiales para la observacin 5. Decida el momento de la observacin Cada uno de los enfoques de observacin tiene sus ventajas e inconvenientes. El muestreo por intervalos permite denir periodos especcos en los cuales observa las actividades de la gerencia. La ventaja de este tipo de muestreo es que minimiza la parcialidad, que de otra manera afectara las observaciones, si estas se realizaran en cualquier momento. El
83
muestreo por intervalo tambin favorece una visin representativa de las actividades ms frecuentes. Dentro de los inconvenientes del muestreo por intervalo se tiene la recopilacin fragmentada de datos de la observacin, que impedir ver la expresin completa de aquellos eventos largos. Un segundo problema del muestreo por intervalo consiste en no llegar a observar eventos pocos frecuentes, pero importantes. El muestreo por eventos aborda ambos aspectos, seleccionando mediante el muestreo dirigido eventos completos tales como una reunin de consejo, a diferencia del muestreo aleatorio de intervalo. El muestreo por evento permite observar el comportamiento en su contexto natural. Un inconveniente del muestreo por eventos es que llega a ser imposible alcanzar una muestra representativa de hechos frecuentes. La mejor tcnica a aplicar seria una combinacin de ambos muestreo. Observacin del lenguaje corporal La comprensin del lenguaje corporal permite comprender mejor las necesidades de informacin del tomador de decisiones, al considerar la dimensin de lo que ha sido expuesto. El lenguaje corporal se integra con mltiples elementos, que conducen a un signicado cuando se interpretan dentro de un contexto. observacin del contacto visual de los tomadores de decisiones observacin de la postura observacin de los movimientos de brazos y piernas observacin del uso de las manos Registro del comportamiento Con el n de capitalizar las observaciones se deber registrar las mismas de alguna manera. La registracin se puede hacer in situ o a posteriori.. Existen varias opciones para el registro de las observaciones, dependiendo de la magnitud de la estructura que requiera el analista. Pareja de adjetivos, categoras y escalas Escalas likert Notas de campo estructuradas Uso de guin La observacin del ambiente fsico El ambiente fsico tambin revela requerimientos de informacin. Se debe observar de manera sistemtica el ambiente fsico. Con frecuencia se observaran particularidades acerca del ambiente, que conrmaran o negaran la narracin de la organizacin (o dialogo) que se obtuvo por medio de las entrevistas o los cuestionarios.
84
Al mtodo de Observacin Estructurada del Ambiente se le denomina como STROBE (STRucture Observation of the Environment). Como toda metodologa el Strobe es sistemtico: 1. Porque proporciona un mtodo y clasicacin estndar para el anlisis de los elementos de la organizacin que participan en la toma de decisiones. 2. Permite que cualquier otro analista aplique la misma estructura analtica a la misma organizacin. 3. Limita el anlisis de la organizacin a su existencia en la etapa actual de su ciclo de vida. Los elementos del STROBE son siete: Ubicacin de la ocina Ubicacin del escritorio Equipo jo de ocina Artculos personales Revistas y peridicos Iluminacin y color de la ocina Vestimenta La aplicacin del STROBE tiene muchas opciones. Puede ser altamente estructurada (tales como toma de fotografas para el anlisis posteriores) o sin estructurar. A continuacin se enuncian cuatro mtodos: 1. Anlisis de fotografas 2. Lista de vericacin/escala de Likert 3. Listas anecdticas 4. Comparacin de la observacin/narracin
3.2.13
Prototipos
El enfoque de prototipos popularizado por Bernard Boar, James Martn y otros, es una alternativa de enfoque para la denicin de los requerimientos consistente en capturar un conjunto de necesidades e implementarlas rpidamente con la intencin declarada de expandirlas y renarlas iterativammente al ir aumentando la comprensin que del sistema tienen el usuarios y quien lo desarrolla. La denicin del sistema se realiza mediante el descubrimiento evolutivo y gradual y no a travs de la previsin omnisciente Este tipo de enfoque se llama tambin de desarrollo heurstica.. Ofrece una alternativa atractiva y practicable a los mtodos de especicacin para tratar mejor la incertidumbre, la ambigedad y la volubilidad de los proyectos reales.
85
El modelo de prototipos supone que el modelo ser operante, es decir, una coleccin de programas de computadoras que simularn algunas o todas las funciones que el usuario desea. El desarrollo de prototipos es una metodologa valiosa para identicar con rapidez, las necesidades particulares de informacin del usuario. De manera simultnea a la presentacin del prototipo de un sistema de informacin que hace como analista de sistemas, tambin estar interesado en enterarse de las reacciones de los usuarios y de la gerencia ante este prototipo. Estas reacciones se obtienen por medio de la observacin, la evaluacin y cuestionarios. Al presentar el prototipo tambin se encontrara interesado en las sugerencias de los usuarios acerca de su renamiento o modicacin, estas sugerencias son el fruto de la relacin de los usuarios con el prototipo y deben ser utilizadas para indicar por que caminos dirigirnos para renar el prototipo. Las innovaciones del prototipo forman parte de la informacin que se encuentra indagando el equipo de analista de sistemas. Las innovaciones son las caractersticas nuevas del sistema que no fueron contempladas previamente a la interaccin con el prototipo. El desarrollo de prototipos necesita de la ejecucin de planes de revisin, estos permiten identicar las prioridades que debern considerarse prximamente en el desarrollo de los mismos. Enfoques para el desarrollo de los prototipos Las diferentes concepciones de la palabra prototipo pueden aplicarse de manera practica a situaciones particulares. Las cuatro deniciones que son ms comunes para el desarrollo de prototipos son: 1. Prototipos de remiendo. Tiene que ver con las construccin de un sistema que si bien funciona, se encuentra remendado o parchado. Un ejemplo sera la creacin de un modelo operable, el cual cuenta con todas sus caractersticas necesarias, aunque pudiera ser ineciente. 2. Modelo a escala no funcional. Son modelos no funcionales que se construyen a escala, con el objeto de evaluar ciertos aspectos de diseo. Un ejemplo sera la construccin de un modelo de un avin a escala para evaluarlo en vuelos de cabotaje. Si bien el tamao y la forma del avin son precisos, el mismo no funciona. 3. Primer modelo a escala completa. Comnmente llamado piloto. Un ejemplo sera el desarrollo del prototipo del primer automvil de una serie. El prototipo es completamente funcional y es la realizacin de lo que segn el diseador ser una serie de automviles con caractersticas idnticas. 4. Un modelo que cuenta con caractersticas esenciales. Construimos un prototipo que incluya algunas, pero no todas las caractersticas que tendr el sistema nal. Los prototipos que se desarrollan de esta manera, se contemplan ciertas caractersticas esenciales, mas no todas.
CAPTULO 3. EDUCCIN DE REQUISITOS Desarrollo de Prototipos
86
Los prototipos se consideran dentro del contexto de la ultima denicin, y que eventualmente, el prototipo funcional llegar a formar parte del sistema principal que se entregue al nal. Para decidir si el prototipo debe incluirse o no en el ciclo de desarrollo del sistema, el analista debe considerar que tipo de problema va a solucionarse y analizar de que manera un sistema ofrecera una solucin. Un sistema de informacin para le procesamiento de datos resuelven problemas muy estructurados, desde un punto de vista muy tradicional, y non seran candidatos a incluir prototipos durante su desarrollo. Esto es debido a que las salidas de estos sistemas son predecibles y se encuentran perfectamente denidas. Un sistema que se oriente a problemas poco o nada estructurado, sera adecuado para desarrollarse a partir de prototipos. El sistema prototipo es solo una parte del sistema que eventualmente se instalara. No es un sistema completo, ya que al desarrollarlo con rapidez, puede quedar limitado, contando con solo ciertas funciones elementales. Uno de los primeros pasos en el desarrollo de un prototipo es la estimacin de los costos involucrados para su construccin, considerndolo como uno de los mdulos del sistema. Una vez que se ha tomado la decisin, deben observarse cuatro lineamientos bsicos al integrar prototipos al SDLC, dentro de la etapa de determinacin de requerimientos. Trabajar con mdulos manipulables. Un mdulo manipulable es aquel que nos permite relacionarnos con sus caractersticas, y adems su construccin es independiente de otros mdulos del sistema. Construir el prototipo con rapidez. Es la esencia del uso de prototipos. Una vez realizado un breve anlisis sobre los requerimientos de informacin por medio de mtodos tradicionales (entrevista, cuestionarios, observacin), se construye los mdulos funcionales de prototipos. Al desarrollar el prototipo con rapidez, en el inicio del ciclo de desarrollo de sistemas, el analista contara con un excelente visin sobre la manera en que deber desarrollar el resto del proyecto. Al mostrar a los usuarios, desde un principio, la operacin de los elementos del sistema, mediante un desarrollo rpido del prototipo, puede evitar la asignacin de recursos a un proyecto, que eventualmente podra descartarse. Modicaciones en el prototipo. Los mdulos deben tener baja dependencia para que sean fcilmente modicables. El prototipo se modica varias ocasiones por medio de varias interacciones. . Las modicaciones deben realizarse de inmediato. Enfatizar la interface con el usuario. La interface es fundamental. Lo que se trata de obtener es que el usuario planteen ms all sus requerimientos de informacin. Por ello deben ser capaces de interactuar, sin complicaciones con el prototipo del sistema. Se tiene que disear una interface que permita al usuario interactuar con el mnimo de adiestramiento, y adems contar con el mximo control sobre las funciones presentadas.
CAPTULO 3. EDUCCIN DE REQUISITOS Ventajas y desventajas de los prototipos
87
Su principal desventaja es que su administracin llega a ser difcil como un proyecto. Otra desventaja es que muchas veces se lo considera un sistema , tanto por los usuarios como los analistas. Como ventaja podemos enumerar la modicacin del sistema en etapas tempranas de su desarrollo, la oportunidad de detener el desarrollo de un sistema que no sirve y la posibilidad de desarrollar otro sistema que se ajuste mejor a las necesidades y a las expectativas del usuario. Estas tres ventajas se encuentran relacionadas entre si. Papel del usuario en el prototipo El papel de usuario en el prototipo se resume en honestidad y compromiso. Si se carece del compromiso del usuario, pocos son los motivos para desarrollar un prototipo. La conducta del usuario es el pivote del proceso de desarrollo y evaluacin del prototipo. Hay tres formas principales segn las cuales el usuario puede apoyar la evaluacin del prototipo: Experimentar con el prototipo los usuarios deben sentir la libertad de experimentar con el prototipo. Plantear sin restricciones, reacciones hacia el prototipo. Si el usuario percibe cierto enfrentamiento al comentar sus opiniones sobre un sistema que patrocinan sus superiores dentro de la organizacin, es poco probable que se planteen las reacciones y que stas llegaran a ser fructferas. Sugerir mejorar o recortes al prototipo. El analista deber identicar las sugerencias del usuario, para ello deber asegurarse que la retroalimentacin del usuario se tomar en serio, observando la manera de relacin del usuario, al concluir y realizar entrevistas.
3.3
Anlisis de decisiones
Con el n de precisar los requisitos de informacin necesario para el anlisis de decisiones, el analista debe identicar los objetivos de la Organizacin, mediante un enfoque descendente, deber conocer la base de la organizacin y tener conocimiento de las tcnicas de recopilacin de datos. El enfoque de lo general a lo particular es decisivo, pues deben relacionarse todas las decisiones con sus objetivos. Los objetivos del nivel superior son muy amplios e inclusive ambiguos, la compaa desea crecer, promoverse y existen diferentes maneras de alcanzar esos objetivos. En este nivel, las decisiones que van a tomarse por lo general carecen de estructura, o se encuentran semiestructurada. Los objetivos del segundo nivel tienen una mayor precisin, objetivos tales como el incremento de las utilidades, la minimicen de los costos, el establecimiento de polticas claras, etc. En este segundo nivel es donde se llevan a cabo decisiones semiestructuradas, debido a la existencia de mltiples objetivos y a las diversas opciones de que disponen los gerentes de mandos medios.
88
En el tercer nivel se cuenta con objetivos mas precisos: clasicaciones efectivas, determinacin de intereses, reglas de cobro y de cancelacin, cobranzas y polticas de cancelacin. En este nivel, los gerentes deciden que variables incluir y cuales no en los procesos de clasicacin, el establecimiento de intereses, la facturacin y la cancelacin. Puesto que existen opciones variadas y de gran trascendencia, las decisiones todava son de carcter semiestructurado. Una de las maneras por las cuales los analistas de sistemas pueden apoyar a la gerencia de cada uno de los niveles, es mediante el desarrollo de sistemas para el soporte de las decisiones.Las condiciones, las alternativas de las condiciones, las acciones, y reglas de accin deben conocerse con el n de disear sistemas para decisiones estructuradas. Las condiciones son aquellos fenmenos que pueden afectar el resultado de algo. Luego se identica las opciones a las condiciones especicadas por quien toma las decisiones. Luego se identican las acciones, esto incluye cualquier instruccin que se requiera para alcanzar el resultado de una o mas de las condiciones anteriores. Todas las instrucciones para la manipulacin o el calculo de valores, la impresin de los informes, seran acciones. Las acciones se unen a las condiciones por medio de reglas de accin.Tres alternativas para el anlisis de decisiones son: Lenguaje estructurado Tabla de decisiones rboles de decisiones
3.3.1
Lenguaje estructurado
Cuando las decisiones no son complejas se aconseja el uso de lenguaje estructurado, se basa en: la lgica estructurada, o en instrucciones que se organizan en procesos agrupados y cclicos planteamientos sencillos del idioma espaol tales como sumar, multiplicar, mover y otros similares Con el n de escribir en lenguaje estructurado, es conveniente apegarse a las siguientes convecciones: 1. Exprese toda la lgica en trminos de estructuras secuenciales, estructuras de decisin, estructuras case (decisin mltiple) o iteraciones. 2. Utilice trminos tales como: IF, THEN, ELSE, DO, DO WHILE, DO UNTIL y PERFORM. 3. Para mostrar con claridad la jerarqua (anidado), utilice sangras en los bloques de proposiciones.
89
4. Cuando las palabras o frases utilizadas hayan sido denidas en un diccionario de datos, destaque tales frases para indicar que tienen una connotacin reservada y especializada. 5. Sea cuidadoso cuando utilice los operadores lgicos y y o, evitando la confusin al distinguirse entre mayor que e igual que de relaciones similares. Aclare los planteamientos lgicos en el momento y no espere hasta la etapa de codicacin del programa.
3.3.2
Tabla de decisiones
Es una tabla de renglones y columnas que contiene cuatro cuadrantes. El cuadrante superior izquierdo contiene la condicin, el cuadrante superior derecho opciones a la condicin. La mitad inferior de la tabla contiene las acciones que se van a tomar (en el extremo izquierdo) y las reglas para ejecutar las acciones (en el derecho). Cuando una tabla se utiliza para determinar las acciones que se llevaron a cabo, la lgica sigue el sentido del reloj, comenzando en el extremo superior izquierdo. El ingrediente nal que le da valor a una tabla de decisiones es el establecimiento de reglas para cada accin. Las reglas son combinaciones de alternativas de condiciones que redundan en una accin. Para construir una tabla, el analista necesita denir el tamao mximo de la tabla, eliminar cualquier situacin imposible, inconsistencia o redundancia, y simplicar la tabla lo mejor posible. Los siguientes pasos proveen un mtodo sistemtico para el desarrollo de tablas de decisiones: Determinar el numero de condiciones que pudieran afectar la decisin. Combine renglones que se sobrepongan. El numero de condiciones ser igual al numero de renglones presentes en la mitad superior de la tabla. Determine el numero de acciones posibles que realizarse. Este ser igual al numero de renglones de la parte inferior de la tabla. Determine el numero de opciones para cada condicin. En la forma mas sencilla, habr dos alternativas (S o N ) para cada condicin. En una tabla de tipo extendida, puede llegar a haber muchas opciones para cada condicin. Calcule el numero mximo de columnas de la tabla multiplicando el numero de alternativas para cada condicin. Llene las alterativas de la condicin. Comience con la primera condicin y divida el numero de columnas con el numero de alternativas para tal condicin. Luego, elija una de las opciones y escriba S en cada una de las columnas de la primera parte, concluya anotando N en las restantes columnas. CONDICIONES 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Condicin nmero 1 S S S S S S S S N N N N N N N N repita lo anterior para cada una de las condiciones, utilizando un subconjunto de la tabla
CAPTULO 3. EDUCCIN DE REQUISITOS CONDICIONES Condicin nmero Condicin nmero Condicin nmero Condicin nmero 1 S S S S 2 S S S N 3 S S N S 4 S S N N 5 S N S S 6 S N S N 7 S N N S 8 S N N N 9 N S S S 10 N S S N 11 N S N S 12 N S N N 13 N N S S 14 N N S N
90 15 N N N S 16 N N N N
1 2 3 4
Concluya la tabla insertando una X donde las reglas sugieran cierta accin. CONDICIONES Condicin nmero Condicin nmero Condicin nmero Condicin nmero ACCIONES Accin nmero 1 Accin nmero 2 1 2 3 4 1 S S S S 2 S S S N X X X X X X X X X X 3 S S N S 4 S S N N 5 S N S S 6 S N S N 7 S N N S 8 S N N N 9 N S S S 10 N S S N 11 N S N S 12 N S N N 13 N N S S 14 N N S N 15 N N N S 16 N N N N
Combine las reglas donde sea aparente que una alternativa no implique diferencias en la salida. A esto tambin se lo conoce como condensacin de reglas. Verique la tabla para situaciones imposibles, contradicciones y redundancias. Vuelva a arreglar las condiciones y las acciones si esto redunda en una mayor compresin. Vericacin de la precisin y la integridad En el desarrollo de tablas se pueden presentar cuatro problemas principales: tablas incompletas, situaciones imposibles, contradicciones y redundancia. Es fundamental que queden completas todas las decisiones, condiciones alternativas de la condicin, acciones y reglas. Cuando se construyen tablas, en ocasiones se presentan situaciones imposibles. Las contradicciones se presentan cuando las reglas sugieren acciones distintas, pero satisfacen las mismas condiciones. Las contradicciones ocurren con frecuencias si los guiones se insertan de manera incorrecta en la tabla. La redundancia ocurre cuando un conjunto idntico de alternativas requiere exactamente de la misma accin.
3.3.3
Tablas mltiples
Las tablas de decisiones pueden llegar a volverse muy sosticado pues crecen con rapidez, conforme se incremento el numero de condiciones y de alternativas. Una tabla con solo siete condiciones y con opciones SI o NO, puede llegar a tener 28 columnas. Una de las formas de reducir la complejidad y el desorden de la tabla es mediante el uso de tablas extendidas, el uso de la regla ELSE (de lo contrario) o la construccin de tablas mltiples. Otra tcnica til para construir tablas de decisiones es el uso de la columna ELSE. Esta tcnica es til para auxiliar y eliminar las mltiples reglas repetitivas que requieren de la misma accin. Tambin sirve para prevenir errores de omisin.
91
Los enfoques estructurados en la construccin de tablas evitan el uso de la instruccin GO TO y en su lugar permiten la utilizacin de la instruccin PERFORM, que permite transferir a otra tabla y regresar a la original, una vez que se concluya con la misma. Las tablas de decisiones son un instrumento importante en el anlisis de las decisiones estructuradas. Una gran ventaja, es que asegura la integridad, es decir, evita excluir alguna condicin. Tambin es fcil vericar posibles errores, tales como situaciones imposibles, contradicciones y redundancias.
3.3.4
rboles de decisiones
Cuando un proceso de decisin estructurada se integra con ramicaciones complejas, es aconsejable el uso de rboles de decisiones, tambin son tiles cuando se quiere mantener una cadena de decisiones con una secuencia particular. Los rboles se dibujan con mayor frecuencia en el plano horizontal, con la raz del rbol del lado izquierdo del papel y las ramas hacia la derecha. Esto permite al analista describir las condiciones de acciones sobre las ramas. Los rboles de decisin que se utilizan como herramienta en el anlisis de sistemas sirven para identicar y organizar condiciones y acciones de un proceso de decisiones plenamente estructurado. Para identicar las acciones en un diagrama de rbol se utiliza un nodo cuadrado, y el circulo identica una condicin, o en otras palabras, el circulo signica un IF (SI), mientras que un cuadrado signica THEN (ENTONSES). Al dibujar el rbol: Identique todas las condiciones y las acciones, as como el orden y el momento de su ejecucin. Comience a construir el rbol de izquierda a derecha, y cuando este seguro de haber anotado todas las alternativas posibles, pase a la derecha. El rbol de decisiones tiene tres ventajas principales sobre una tabla de decisiones: 1. Es que toma las ventajas de la estructura consecutiva de las ramas del rbol de decisiones, de tal forma que se identica de manera inmediata el orden de vericacin de las condiciones y las acciones que se deben llevar a cabo. 2. Las condiciones y las acciones del rbol de decisiones se encuentran en ciertas ramas pero no en otras, a diferencias de las tablas, donde todas forman parte de la misma tabla.- Aquellas que son decisivas se conectan de manera directa con otras condiciones y acciones, mientras que las condiciones no importantes no se incluyen; por consiguiente, el rbol no mantiene una simetra. 3. Al compararse con las tablas, los rboles se entienden con mas facilidad en una organizacin y son apropiados como mtodo de comunicacin. Hemos examinado las tres tcnicas, aunque no se utilizan de manera exclusiva, es costumbre elegir solo una tcnica de anlisis para una decisin, mas que emplearlas todas.
92
3.3.5
Los siguientes lineamientos sirven para la eleccin de la tcnica a utilizar.
Utilice el lenguaje estructurado cuando : Haya muchas acciones repetitivas La comunicacin con los usuarios nales sea relevante Utilice una tabla de decisin cuando: Se cuenten con combinaciones complejas de condiciones, acciones y reglas. Requiera un mtodo que efectivamente evite situaciones imposibles, redundancias y contradicciones. Utilice un rbol de decisiones cuando: A secuencia de las condiciones y las acciones sea decisiva. Cuando no sea relevante cada condicin sobre cada accin (las ramas son diferentes).
3.4
Anlisis de los Sistemas de apoyo para las decisiones semiestructurada
Los sistemas de apoyo para la toma de decisiones (DSS) tienen muchas caractersticas que los hacen diferentes de otros sistemas mas tradicionales de manejo de la informacin, los usuarios de estos sistemas poseen caractersticas especiales, debido al tipo de problemas que enfrentan. Ante todo un DSS es un instrumento que sirve para organizar la informacin que eventualmente se usara en la toma de decisin. Involucra el uso de una base de datos para un propsito especico de toma de decisiones. Un DSS no solo automatiza las transformaciones de los datos, ni solo proporciona una salida en forma de reportes, mas bien, el DSS apoya el proceso de toma de decisiones mediante la presentacin de la informacin deseada, para el alcance de la solucin de los problemas de toma de decisiones y de sus necesidades de aplicacin. Tampoco reemplazara el juicio del usuario, ni llegara a tomar las decisiones por l. Un sistema DSS permite que el tomador de decisiones se relacione de manera natural, por medio de un diseo cuidadoso de la interfaces con el usuario. El DSS eventualmente cambia el proceso de toma de decisiones, ya que le proporciona nuevas formas de ver los problemas y las oportunidades; y tal cambio tambin incide sobre el usuario mismo. Los DSS se disean para apoyar aquellas decisiones formuladas como problemas semiestructurados complejos. Estos problemas se resisten a computarizarse por completo. La bsqueda de una solucin no es el objetivo de un DSS, sino mas bien, apoya el proceso de decisiones que desembocara en la solucin. Un sistema de apoyo para la toma de decisiones puede construirse para apoyar decisiones que se toman de una sola vez, o aquellas que son pocos frecuentes, o bien aquellas que ocurren de manera rutinaria. Sin embargo, el tipo de problema o de oportunidad que
93
mejor enfrenta un DSS es aquel que requiere del juicio humano; ya sea porque los humanos sientan inapropiado delegar su juicio (decisiones de vida o muerte) o bien, porque el problema no puede automatizarse por completo. Se disean para un tipo de persona en particular, o bien para un grupo de personas (tomadores de decisiones), esto permite que el diseador estandarice caractersticas bsicas del sistema para adaptarlo al tipo de representaciones e interface que el usuario comprenda mejor. Tambin los analistas pueden utilizar generadores de sistemas de apoyo para la toma de decisiones (Decisin Support System Generator, DSSG), es un paquete que interrelaciona el hard con el Soft. Su comercializacin ha crecido enormemente, debido a que reducen el tiempo y costo de la construccin de un DSS. Por ultimo, es necesario concebir un DSS como un proceso, mas que un producto.
3.4.1
Conceptos de toma de decisiones relevantes para el DSS
La teora clsica de la toma de decisiones supone que las decisiones se llevan a cabo segn tres tipos de condiciones: certeza, incertidumbre y riesgo. La certeza signica que la hacer una eleccin, conocemos todo de antemano (Programacin lineal en ciencias administrativas). La incertidumbre implica lo opuesto; no sabemos nada acerca de las probabilidades o las consecuencias de nuestras decisiones. Entre las condiciones extremas de incertidumbre y certeza se encuentra un conjunto de condiciones denominadas riesgo. Las decisiones echa bajo riesgo consideran cierto conocimiento de nuestras alternativas (variables controlables), de lo que no podemos controlar sino solo estimar (variables ambientales) y de lo que sern las consecuencias (variables dependientes). La forma de recopilar, procesar y utilizar la informacin dene los parmetros del estilo de toma de decisiones, adems de la manera como se comunican y toman decisiones. Es comn que los tomadores de decisiones se caractericen por ser analticos o heurstica.. EL tomador de decisin analtico se basa en la informacin que se adquiere y evala de manera sistemtica para reducir alternativas y elegir con base en tal informacin. Los tomadores de decisiones analticos evalan la informacin cuantitativa, as como los modelos que la generan y usan. Hacen uso de las matemticas para modelar problemas y de los algoritmo para resolverlos. Normalmente busca soluciones ptimas mas que satisfactorias, hace uso de grcas, modelos probabilsticas y otras tcnicas matemticas para asegurar una toma de decisiones slida, sin embargo se requiere que la informacin este disponible, sea razonable, completa y precisa. El tomador de decisin que hace uso de la heurstica, decide con la ayuda de ciertos lineamientos, y se basa fundamentalmente en la experiencia. Aprenden a actuar, utilizan el ensayo y el error para encontrar la solucin, ya que se basan en su experiencia, su sentido comn les sirve de gua. Un DSS para un individuo analtico debe incluir diversos modelos grcos y matemticos que permitan el anlisis deseado. Para quienes abordan la toma de decisiones con enfoque heurstica son algo sistemticos, pero utilizan reglas practicas como lineamientos, mas que el razonamiento cuidadoso de cada alternativa, cada vez que se presenta, un DSS que apoye al heuristico, tal vez presente un resumen de las alternativas, mas que detallar los pro y contra en voluminosas
94
salidas, tambin podra informar de decisiones pasadas y de sus resultados. La toma de decisin es todo un proceso, y se lo puede concebir en fases, estas fases pueden llegar a sobreponerse entre si. Las tres fases de la solucin de problemas son: Anlisis Diseo Seleccin.
Anlisis: es la identicacin de una oportunidad o de un problema. Se incursiona en los ambientes externos e internos buscando la decisin que tomar, las oportunidades que examinar o el problema que solucionar. Diseo: el tomador de decisiones formula un problema y analiza varias alternativas. Esta fase permite al tomador de decisiones generar y analizar alternativas con base en su aplicabilidad potencial. Seleccin: selecciona una solucin para el problema o la oportunidad identicada en la fase de anlisis.
3.4.2 Decisiones semiestructuradas
Las decisiones estructuradas son aquellas donde todas o la mayora de las variables se conocen y pueden programarse en forma total. Las decisiones estructuradas son de rutina y requieren poca evaluacin humana una vez que se programan las variables. Las decisiones no estructuradas son aquellas que hasta la fecha se resisten a la computarizacin y bsicamente dependen de la intuicin. Las decisiones semiestructuradas son aquellas que pueden programarse de manera parcial, pero todava requieren de la participacin del criterio humano. Los sistemas de apoyo para la toma de decisiones son muy ecaces cuando se orientan a decisiones semiestructuradas, pues el DSS apoya al tomador de decisiones en todas las fases de la toma de decisiones sin restringirlo con una respuesta nal. Las decisiones se denominan semiestructuradas o no estructuradas por diferentes motivos, desde el punto de vista: Grado de habilidad requerido en la toma de decisiones La magnitud de la complejidad del problema El numero de criterios de decisin por considerar Grado de habilidad EL grado de habilidad se asocia con los conceptos de decisin analtica y heurstica.- La habilidad de toma de decisiones se mide en la madurez del tomador de decisiones, la cual se basa en la experiencia y en el anlisis.
CAPTULO 3. EDUCCIN DE REQUISITOS Magnitud de la complejidad
95
Si un problema es demasiado complejo parece ser semiestructurado o sin estructura. Un DSS auxilia al tomador de decisiones al inducirle a denir los limites del sistema, esto es, a denir con claridad el problema y a limitar el numero de variables.- Los DSS son utilices para organizar la informacin, dar seguimiento a las variables y presentar los problemas, las alternativas y las elecciones para que el gerente los comprenda con facilidad. Numero de criterios de decisin a considerar La mayora de los problemas reales cuentan con mltiples metas conictivas entre si, o bien, con criterios de decisin mltiple; y en consecuencia, por naturaleza son semiestructurado. Los DSS son valuables porque ayudan al tomador de decisiones para que manipule criterio mltiples. Sin importar el tipo de decisin, quien decide debe pasar por cada una de las tres fases (anlisis, diseo, seleccin) durante el proceso de toma de decisin. La toma de decisiones se diculta con frecuencia, si el problema en si es difcil de identicar. Los problemas destacan solo si se realizan mediciones de desempeo apropiadas para demostrar la existencia del problema. Un DSS efectivo debe incluir mecanismos para reconocer problemas. Una vez que se identica el problema, este necesita denirse. El DSS que apoya al tomador de decisiones determina el alcance del problema y le evita una decisin sumamente compleja. El ultimo paso en la fase de anlisis consiste en asignar una prioridad al problema. El problema puede ser de tipo inmediato, o bien una oportunidad futura de alcanzar, si otros problemas de mayor relevancia se atacaran prioritariamente. De una manera similar deben identicarse las alternativas. Un DSS puede generar alternativas que el tomador de decisiones pudiera haber pasado por alto. Los DSS basados en la experiencia pueden comparar la situacin actual con otras similares, y con ello, guiar al gerente a travs de innumerables alternativas. Despus deben cuanticarse las alternativas. Un tomador de decisiones analtico recopilara nuevos datos y los manipulara a partir de un banco de datos. Un tomador de decisiones heurstico podra pensar en un enfoque extraorganizacin, en establecer analogas y en obtener opiniones respecto a diferentes situaciones. Una vez que se generan y organizan las alternativas se necesita establecer criterios de desempeos. Entonces el tomador de decisiones podr asignar valores, riesgos y/o ponderar cada una de las alternativas. En esta fase es fuerte la relacin entre el DSS y el tomador de decisiones. Es posible elaborar un sistema de apoyo para la toma de decisiones que simule diferentes situaciones con mltiples variables. Obviamente es importante la eleccin de una solucin, y en las decisiones semiestructuradas tal eleccin debe dejarse al criterio del tomador de decisiones con el apoyo de un DSS. El DSS auxilia al tomador de decisiones en la organizacin y presentacin de la informacin. El DSS idealmente realizara manipulaciones sosticadas, pero dejara al criterio del analista las decisiones trascendente.
96
3.4.3
Toma de decisiones de criterio mltiple
Los enfoques de criterio mltiple permiten al tomador de decisiones establecer sus propias prioridades, y en la mayora de los casos permiten al tomador de decisiones realizar un anlisis de sensibilidad cuando plantea preguntas del tipo Que sucedera si ...?. Cuando los modelos de toma de decisiones de criterio mltiple se incluyen en un DSS o en un MIS, permiten que el tomador de decisiones cuente con un ecaz instrumento para evaluar alternativas durante la fase de diseo de la toma de decisiones. Dentro de esos mtodos se incluyen: Uso de anlisis de ventajas y desventajas Se divide una hoja de papel en dos columnas mediante una lnea. En un lado, se escriben todas las razones a favor (ventajas), y en el otro todas las razones en contra (desventajas). Luego se tacha cualquier elemento positivo que fuera equivalente a otro en contra, o viceversa. Inclusive en una versin actualizada se utilizan dos columnas mas, una para las ventajas y otra para las desventajas, en esta columnas se coloca con un 1 o 0 , 1 si la alternativa todava esta sujeta a consideracin, 0, si se considera que las ventajas son equivalentes. El proceso continua hasta que una de las columnas llega a 0. Uso de mtodo de ponderacin Se le asigna un valor a cada uno de los atributos de cada opcin (generalmente del 1 a 10). Finalmente, la calicacin total se calcula y se anota, y con base en tal calicacin el tomador de decisiones recomienda una de las opciones. Uso de la eliminacin consecutiva por lexicografa Este mtodo caracteriza la importancia de los atributos individuales, es menos exigente que la ponderacin, pues los atributos se anotan simplemente en orden de importancia, sin llegar a asignarles pesos. Se construye una matriz de atributos y de alternativas. Los renglones se ordenan, primero por atributos de arriba (mas importantes) hacia abajo (menos importantes). Luego, las alternativas se orden rengln por rengln. Solo aquellas alternativas que cuentan con mayor calicacin (10) para el primer atributo se consideraran mas adelante, despus, se considera el segundo atributo, y as sucesivamente hasta considerar el ultimo atributo. Uso de la eliminacin consecutiva por restricciones conjuntivas Se establecen restricciones o especicaciones y luego procede a eliminar aquellas alternativas que no satisfacen el conjunto de todas las restricciones. Si las restricciones son demasiadas estrictas, se eliminaran todas las alternativas, pero si no son lo sucientemente estrictas, aun permanecern muchas alternativas. Uso de la programacin por objetivos
97
Es similar en estructura a la programacin lineal y en consecuencia, tiene los mismos supuestos y limitaciones. Un modelo de programacin por objetivos contiene variables de decisin, variables de desviacin, prioridades y, en ocasiones, pesos de ponderacin. Por ello se deben de establecer metas para cada una de las ecuaciones de objetivos dentro del problema y tambin elegir prioridades para minimizar las variables de desviacin. Es una tcnica de gran vala cuando la informacin que se requiere es fcilmente accesible y el tomador de decisiones esta al tanto y tiene conanza acerca de las metas y prioridades y tener habilidad para formular las ecuaciones de las metas.
98
3.5
Preguntas y Ejercicios de Revisin
1. Que pasos debemos seguir para obtener informacin directamente de la gente. 2. Explique la conducta de un buen proceso de educcin. 3. Enumere y describa los problemas que se presentan en la educcin de requisitos. 4. Clacique las tcnicas de educcin. 5. Que entiende por muestreo. 6. Cuales son los pasos para contar con un buen diseo de muestreo. 7. De un ejemplo de muestra de oportunidad. 8. Por que es practico utilizar muestras aleatorias simples para el muestreo de documentos e informes. 9. Enumere algunos documentos cuantitativos que el analista de sistema examinara para comprender una organizacin. 10. Que tipo de informacin debe obtenerse en una entrevista. 11. Enumere y describa las cinco etapas de la preparacin de la entrevista. 12. Que entiende por preguntas cerradas, abiertas y de sondeo. 13. Que entiende por estructura piramidel, enbudo y diamante. 14. Cuales son lo problemas que se presenta durante una entrevista. 15. Enumere casos que haga apropiado el uso de cuestionarios. 16. Cual es la diferencia entre la escla nominal y la escala ordial. 17. Describa las diferencias entre las escalas de intervalo y la proporcional. 18. Enumere y describa los problemas que se pueden presentar en la construccin de escalas. 19. Enumere y describa las siguientes tcnicas de educcin: PIECES, Braintorming, Anisis de Mercado. 20. Enumere algunas razones por lo cual es util la observacin de la organizacin. 21. Cuales son las ventajas de utilizar el muestreo por intervalo de las observaciones. 22. Compare el uso de parejas de adjetivos con las notas de campo estructuradas para el registro de la observacin. 23. Enumere siete elementos de ambiente sico del toamdor de decisiones que el analista de sistemas pueda examinar por medio del STROBE.
CAPTULO 3. EDUCCIN DE REQUISITOS 24. Cuales son las dioferentes estrategias de aplicacin para el uso del ESTROBE.
99
25. Realizar un cuestionario a eleccin con preguntas abiertas y cerradas, para calicar el nivel educativo de la facultad. Utilizar tems como edad del encuestado, ao que cursa, procedencia, etc. Considerar problemas como ser falta de capacitacin, falta de recursos, planicacin de las materias, etc. 26. Realizar una entrevista con un profesor de la facultad evaluando un rea de inters dentro de la facultad.
100
[15] Kennet Kendall y Julie Kendall. Anlisis y Diseo de Sistemas. Prentice Hall, 1991. [7] E. Yourdon. Anlisis y Diseo Estructurado. Yourden Press, 1980.
Referencia Bibliogrcas
Parte II
Anlisis Estructurado
101

Temas 03

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Temas 03

Загружено:

Авторское право:

Доступные форматы

Captulo 3

CAPTULO 3. EDUCCIN DE REQUISITOS

Conductas en un buen proceso

Ayuda a la exploracin de requisitos

Los usuarios tienen una idea vaga de lo que necesitan

Distincin entre lo que los usuarios quieren y lo que necesitan

Figura~3.1: Entradas y salidas del proceso de educir

Conductas en un proceso pobre

Problemas de la educcin de requisitos

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

Tcnicas de educcin de requisitos

Tipos de informacin que se obtiene durante la investigacin

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS Realizacin de la entrevista

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS Fase de generacin

CAPTULO 3. EDUCCIN DE REQUISITOS Servicios proporcionados por el sistema

Anlisis de factores crticos

JAD (Joint Applicatin Design)

Primera: Denicin del proyecto.

CAPTULO 3. EDUCCIN DE REQUISITOS Moderador de las reuniones

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

Quinta: Elaboracin del Documento Final

CAPTULO 3. EDUCCIN DE REQUISITOS

Entorno de bucles adaptativos

CAPTULO 3. EDUCCIN DE REQUISITOS

Presin para evaluar

Acciones que hacen evolucioonar el sistema

Figura~3.2: Bucles Adaptativos

Observacin al comportamiento de la toma de decisiones y al ambiente de ocina

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS Desarrollo de Prototipos

CAPTULO 3. EDUCCIN DE REQUISITOS Ventajas y desventajas de los prototipos

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

Los siguientes lineamientos sirven para la eleccin de la tcnica a utilizar.

Anlisis de los Sistemas de apoyo para las decisiones semiestructurada

CAPTULO 3. EDUCCIN DE REQUISITOS

Conceptos de toma de decisiones relevantes para el DSS

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS Magnitud de la complejidad

CAPTULO 3. EDUCCIN DE REQUISITOS

Toma de decisiones de criterio mltiple

CAPTULO 3. EDUCCIN DE REQUISITOS

CAPTULO 3. EDUCCIN DE REQUISITOS

Preguntas y Ejercicios de Revisin

CAPTULO 3. EDUCCIN DE REQUISITOS

Вам также может понравиться