Contenido Herramientas para determinar requerimientos de sistemas ................... 3 Actividades de la determinacin de requerimientos ............................... 3 Requerimientos bsicos ..........................................................................

4 Comprensin del proceso ....................................................................... 4 Identificacin de los datos empleados e informacin generada .............. 5 Frecuencia y volumen del proceso .......................................................... 5 Identificacin de controles ...................................................................... 5 Requerimientos de las transacciones de los usuarios .............................. 6 Requerimientos de decisin de los usuarios............................................ 6 Requerimientos de toda organizacin ..................................................... 7 TCNICAS PARA ENCONTRAR HECHOS .................................................... 8 HERRAMIENTAS PARA DOCUMENTAR PROCEDIMIENTOS Y .................... 9 Conceptos bsicos sobre decisiones...................................................... 10 rboles de decisin ............................................................................... 10 Identificacin de los requerimientos de datos ...................................... 11 Como evitar los problemas que se generan al utilizar rboles de decisin .............................................................................................................. 11 Tablas de decisin ................................................................................. 12 Caractersticas de las tablas de decisin ................................................ 12 Como construir tablas de decisin ........................................................ 12 Verificacin de tablas de decisin ......................................................... 13 Tipos de entradas en una tabla ............................................................. 13 Tablas mltiples .................................................................................... 14 Procesadores de tablas de decisin....................................................... 15 Espaol estructurado ............................................................................ 15 Desarrollo de declaraciones estructuradas ........................................... 15 Beneficios del espaol estructurado ..................................................... 16 ANLISIS ESTRUCTURADO ..................................................................... 16
1

CARACTERSTICAS DE LAS ESTRATEGIAS DE FLUJO DE DATOS ............... 18 Herramientas de la estrategia de flujo de datos .................................... 18 Ventajas del anlisis de flujo de datos ................................................... 19 DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS .............................. 19 Diagramas fsicos de flujo de datos ....................................................... 20 Reglas generales para el dibujo de diagramas lgicos de flujo de datos 20 CARACTERSTICAS DE LOS DICCIONARIOS DE DATOS ............................ 22 FINES DE LOS PROTOTIPOS DE APLICACIONES ...................................... 24 ETAPAS DEL MTODO DE PROTOTIPOS ................................................. 26 USO DE PROTOTIPOS ............................................................................ 27 IMPORTANCIA DE LAS HERRAMIENTAS EN EL DESARROLLO DE ............ 29 CLASIFICACIN DE HERRAMIENTAS AUTOMATIZADAS ......................... 30 HERRAMIENTAS ASISTIDAS POR COMPUTADORA PARA LE ................... 31 USO DE UNA HERRAMIENTA CASE ........................................................ 32

ANLISIS Y DETERMINACIN DE REQUERIMIENTOS Herramientas para determinar requerimientos de sistemas La determinacin de requerimientos es el estudio de un sistema para conocer cmo trabaja y donde es necesario efectuar mejoras, dando como resultado una evaluacin de la forma como trabaja los mtodos empleados y si es necesario o posible realizar ajustes. Un requerimiento es una caracterstica que debe incluirse en un nuevo sistema. Esta puede ser la inclusin de determinada forma para capturar o procesar datos, producir informacin, controlar una actividad de la empresa o brindar soporte a la gerencia. Es as como la determinacin de requerimientos vincula el estudio de un sistema existente con la recopilacin de detalles relacionados con l. Actividades de la determinacin de requerimientos Es til ver la determinacin de requerimientos a travs de tres grandes actividades: Anticipacin de requerimientos: La experiencia de los analistas les permite anticipar ciertos problemas o caractersticas y requerimientos para un nuevo sistema. Por un lado, la experiencia de estudios previos puede conducir a la investigacin de reas que no considerara un analista novato. Tener las bases necesarias para saber que preguntar o que aspectos investigar puede ser de beneficio substancial para la organizacin. Por otra parte, si se introducen sesgos o atajos al conducir la investigacin entonces es muy probable que la anticipacin de requerimientos se convierta en un problema. Por lo tanto, siempre deben darse lineamientos para estructurar una investigacin alrededor de cuestiones bsicas con la finalidad de evitar consecuencias indeseables de la anticipacin de requerimientos. Investigacin de requerimientos: Es la ms importante del anlisis de sistemas. Los analistas estudian el sistema actual con la ayuda de varias herramientas y habilidades, y documentan caractersticas para, ms adelante, emprender el anlisis. La investigacin de requerimientos depende de las tcnicas para encontrar datos, que sern explicadas ms adelante, e incluyen los mtodos para documentar y describir las caractersticas del sistema.

Especificaciones de requerimientos: Los datos obtenidos durante la recopilacin de hechos se analizan para determinar las especificaciones de los requerimientos, es decir, la descripcin de las caractersticas del nuevo sistema. Esta actividad tiene tres partes relacionadas entre s: Anlisis de datos basados en hechos reales: Se examinan los datos recopilados durante el estudio, incluidos en la documentacin de flujo de datos y anlisis de decisiones, para examinar el grado de desempeo del sistema y si cumple con las demandas de la organizacin. Identificacin de requerimientos esenciales: Caractersticas que deben incluirse en el nuevo sistema y que van desde detalles e operacin hasta criterios de desempeo. Seleccin de estrategias para satisfacer los requerimientos: Mtodos que sern utilizados para alcanzar los requerimientos establecidos seleccionados. Estos forman la base para el diseo de sistemas, los cuales deben cumplir con la especificacin de requerimientos. La especificacin de requerimientos implica gran responsabilidad para los analistas de sistemas, ya que la calidad de trabajo realizado en esta etapa se ver reflejada ms adelante en las caractersticas del nuevo sistema. Requerimientos bsicos Los analistas estructuran su investigacin al buscar respuestas a las siguientes cuatro importantes preguntas: Cul es el proceso bsico de la empresa? Qu datos utiliza o produce esta empresa? Cules son los lmites impuestos por el tiempo y la carga de trabajo? Qu controles de desempeo utiliza? Comprensin del proceso Los analistas hacen preguntas que, cuando reciben la respuesta, proporcionan antecedentes sobre detalles fundamentales relacionados con el sistema y que sirven para describirlo. Las siguientes preguntas son de utilidad para adquirir la comprensin necesaria: Cul es la finalidad de esta actividad dentro de la empresa? Qu pasos se siguen para llevarla a cabo? Dnde se realizan estos pasos? Quines lo realizan? Cunto tiempo tardan n efectuarlos? Con cuanta frecuencia lo hacen?
4

Quines emplean la informacin resultante? Identificacin de los datos empleados e informacin generada El siguiente paso es detectar que datos se utilizan para llevar a cabo cada actividad. Por ejemplo, para reabastecer el inventario, el comprador requiere datos que describan para cada artculo la cantidad existente, la demanda esperada, el nombre del proveedor y el costo. Para saber cundo hacer cada pedido, el comprador debe considerar el tiempo de entrega de la mercanca. Por otra parte, muchas transacciones comerciales producen informacin til para los gerentes cuando estos evalan el desempeo de empleados, negocios y sistemas; esta informacin tambin puede ser de utilidad, en otro contexto, para los gerentes y analistas. Por ejemplo, los analistas curiosos encuentran que los datos relacionados con el abasto del inventario y almacenaje tambin proporcionan informacin con respecto a demandas del almacn, practicas de compras, ventas y flujo de efectivo.

Frecuencia y volumen del proceso La frecuencia con la que se presentan actividades en una empresa cambia mucho. Por ejemplo, algunas como el pago de impuestos suceden pocas veces al ao mientras que el pago de la nomina de empleados es algo que ocurre cada semana. Por consiguiente, los analistas deben investigar con cuanta frecuencia se repite una actividad. Conocer esta informacin puede llevar al analista a considerar ms preguntas importantes para determinar la razn de esta frecuencia y su efecto sobre las actividades de la empresa. Muchas veces la forma ms fcil de obtener esta informacin es identificar el objetivo de la actividad: Cul es la causa de la actividad? En ocasiones los analistas se refieren a la causa directa como la funcin de iniciacin. Las actividades pueden ser iniciadas por los clientes por sucesos y por el paso del tiempo. Los analistas corren el riesgo de no comprender adecuadamente la razn de una actividad y darle mayor o menos importancia de la que tiene en el sistema, a menos que conozcan que es lo que inicia la actividad. Identificacin de controles En situaciones donde se ejerce buen control ya sea por parte de la gerencia o por el seguimiento del proceso, quizs no sea problema determinar si una actividad se ha llevado a cabo en forma adecuada. Aun as, los analistas deben examinar los mtodos de control durante la etapa de anlisis: existen estndares especficos de desempeo?, quin se encarga de
5

comparar el desempeo contra los estndares?, cmo se detectan los errores?, cmo se corrigen los errores?, se cometen demasiados errores? La falta o debilidad de los controles es un descubrimiento importante en cualquier investigacin de sistemas.

Requerimientos de las transacciones de los usuarios Los sistemas a nivel de transacciones, capturan, procesan y almacenan datos por alguna razn. Por ejemplo, en un sistema de pedidos, los pedidos de los clientes son procesados de forma tal quesea posible enviar los artculos indicados. Este proceso se aplica a todos los pedidos que se reciben. Los analistas seleccionados para trabajar en un sistema de procesamiento de pedidos, deben conocer todo lo relacionado con la forma en que se procesan estas transacciones. Para entender los requerimientos de las transacciones, los analistas sin lugar a dudas formularan preguntas como las siguientes: Qu es lo que forma parte de la transaccin que est siendo procesada? Qu es lo que inicia la transaccin? Quin inicia los pedidos? Con que propsito? Con que frecuencia ocurren los pedidos? Qu volumen est asociado con cada pedido? Existen diferentes condiciones que pueden afectar la forma en que se procesan los pedidos? Qu detalles son necesarios para procesar la transaccin? Qu informacin se genera? Qu datos se guardan? Requerimientos de decisin de los usuarios A diferencia de las actividades de transaccin, las relacionadas con decisiones no siguen un procedimiento especfico. Las rutinas no son muy claras y es posible que los controles sean vagos. Las decisiones se toman al integrar la informacin en forma tal que los gerentes puedan saber que acciones emprender. Es probable que los sistemas de decisin tengan que ver con el pasado, el presente y el futuro. Algunos brindan soporte para decisiones recurrentes mientras que otros son nicos y no recurrentes. Los analistas que investigan sistemas para el soporte de decisiones, deben formular las mismas preguntas sobre frecuencia y volmenes mencionados anteriormente, pero tambin deben hacer otras para determinar los requerimientos de las decisiones:

12-

Qu informacin se utiliza para tomar la decisin? Cul es la fuente de informacin? Qu sistemas de transacciones producen los datos en el proceso de decisin? Qu otros datos son necesarios y no es posible obtener del procesamiento de transacciones? Qu datos se originan en fuentes externas a la organizacin? 3- Cmo se deben procesar los datos para producir la informacin necesaria? 4- Cmo debe plantearse la informacin? Estas preguntas tambin sealan la relacin entre los sistemas de transacciones y los de decisiones. Informacin muy valiosa puede perderse si los sistemas de transacciones no capturan y guardan los datos necesarios para las decisiones. Los sistemas de inventario capturan informacin relacionada con los continuos pedidos, recepciones, ventas y envi de artculos. Los datos que estos sistemas almacenan son procesados nuevamente para generar informacin de manera peridica para analizar ventas, determinar polticas de procesos o decidir planes de mercadotecnia para lneas de productos. Todo esto significa que: 1) los analistas que investigan sistemas para el soporte de decisiones deben considerar los sistemas de procesamiento de transacciones y 2) que los sistemas eficaces para el soporte de decisiones requieren primero de procedimientos adecuados para el procesamiento de transacciones. Requerimientos de toda organizacin En las empresas, los departamentos dependen unos de otros para brindar servicios, fabricar productos y satisfacer a los clientes. Por consiguiente, el trabajo hecho en un departamento afecta al de los otros. Cuando los analistas estudian sistemas para un departamento tambin deben evaluar las implicaciones para los dems departamentos con los que interacta el sistema bajo investigacin. Es responsabilidad del analista identificar las dependencias entre departamentos y determinar cmo los afecta un proyecto de sistemas. En muchas ocasiones, cuando trabajan con usuarios, los analistas escuchan como deberan manejarse las excepciones. Claro est que una aplicacin debe disearse para dar cabida a los eventos rutinarios. Pero los analistas deben abordar lo que est fuera de la rutina ya que estos sucesos son una prueba de fuego para el sistema. Deben asegurarse de hacer preguntas a los usuarios que saquen a luz los casos excepcionales: El procedimiento que emplea el usuario siempre trabaja? Con cuanta frecuencia es necesario
7

hacer una excepcin al procedimiento? Todos los empleados siguen el mismo procedimiento? TCNICAS PARA ENCONTRAR HECHOS Los analistas utilizan mtodos especficos, denominados tcnicas para encontrar hechos, con el objeto de reunir datos relacionados con los requerimientos. Entre estos se incluyen la entrevista, el cuestionario, la revisin de los registros y la observacin. En general, los analistas emplean ms de una de estas tcnicas para llevar a cabo una investigacin amplia y exacta. Entrevistas: Los analistas emplean la entrevista para reunir informacin proveniente de personas o de grupos. Por lo comn, los entrevistados son usuarios de los sistemas existentes o usuarios en potencia del sistema propuesto. En algunos casos, los entrevistados son gerentes o empleados que proporcionan datos para el sistema propuesto o que sern afectados por el. Aunque algunos analistas prefieren la entrevista sobre otras tcnicas, esta no siempre es la mejor fuente de datos sobre la aplicacin. Dado que la entrevista lleva tiempo, es necesario utilizar otros mtodos para obtener la informacin necesaria para conducir una investigacin. Las entrevistas pueden clasificarse como estructuradas o no estructuradas. Las entrevistas no estructuradas utilizan un formato pregunta-respuesta y son apropiadas cuando el analista desea adquirir informacin general del sistema. Este formato anima a los entrevistados a compartir sus sentimientos, ideas y creencias. Por otro lado, las entrevistas estructuradas utilizan preguntas estndar en un formato de respuesta abierta o cerrada. El primero permite que el entrevistado de respuesta a las preguntas con sus propias palabras; el segundo utiliza un conjunto anticipado de respuestas. Cada enfoque tiene sus ventajas y desventajas. Cuestionarios: El uso de los cuestionarios permite a los analistas reunir informacin proveniente relacionada con varios aspectos de un sistema de un grupo grande de personas. El empleo de formatos estandarizados para las preguntas puede proporcionar datos ms confiables que otras tcnicas; por otra parte, su amplia distribucin asegura el anonimato de los encuestados, situacin que puede conducir a respuestas ms honestas. Sin embargo, este mtodo permite al analista observar las excepciones o reacciones de los encuestados. Asimismo, la respuesta puede ser limitada ya que es posible que no tenga mucha importancia para los encuestados llenar el cuestionario.

Con frecuencia los analistas utilizan cuestionarios abiertos para descubrir sentimientos, opiniones y experiencias generales o para explotar un proceso o problema. Los cuestionarios cerrados controlan el marco de referencia al presentar a los encuestados respuestas especficas para escoger. Revisin de los registros Varios tipos de registros y reportes pueden proporcionar al analista informacin valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la informacin asentada en ellos relacionada con el sistema y los usuarios. La revisin de los registros puede efectuarse al comienzo del estudio, como introduccin, o tambin despus, y sirve de base para completar las operaciones actuales. Por lo tanto los registros pueden indicar que est sucediendo. Los registros incluyen manuales de polticas, reglamentos y procedimientos estndares de operacin utilizados por la mayor parte de las organizaciones como guas para los gerentes y empleados. Estos registros no indican la forma en la que se desarrollan las actividades en realidad, donde se encuentra todo el poder de la toma de decisiones, o como se realizan todas las tareas. Sin embargo, pueden ser de gran ayuda para el analista en su afn de comprender el sistema al familiarizarlo con aquellas operaciones que necesitan apoyo con las relaciones formales dentro de la organizacin. Observacin La observacin permite al analista ganar informacin que no se puede obtener por otras tcnicas. Por medio de la observacin el analista obtiene informacin de primera mano sobre la forma en que se efectan las actividades. El mtodo es ms til cuando el analista necesita observas, por un lado, la forma en que se manejan los documentos y se llevan a cabo los procesos y, por otro, si se siguen todos los pasos especificados. Los observadores experimentados saben que buscar y como evaluar la significancia de lo que observan. HERRAMIENTAS PARA DOCUMENTAR PROCEDIMIENTOS Y DECISIONES Seguir procedimientos y tomar decisiones son aspectos importantes de cualquier empresa. Las decisiones y procedimientos son de importancia para el analista cuando este conduce una investigacin de sistemas dentro de la empresa. Las herramientas ayudan al analista a integrar los datos recopilados por los diversos mtodos estudiados anteriormente. Pero, como sucede con todas las herramientas, la que emplea el analista para documentar procedimientos y decisiones deben utilizarse adecuadamente.

Se presentan tres herramientas para documentar procedimientos: rboles de decisin, tablas de decisin y espaol estructurado. Conceptos bsicos sobre decisiones Cuando se analizan procedimientos y decisiones el primer paso es identificar condiciones y acciones, conceptos comunes a todas las actividades. Condiciones y variables de decisin Cuando se observa un sistema y se pregunta cules son las posibilidades? O qu puede suceder?, en realidad se est preguntando por las condiciones, que son los posibles estados de una entidad. Las condiciones cambian, y es por eso que el analista se refiere a ellas como variables de decisin. Al documentar la decisin de cmo procesar un procedimiento, el investigador debe identificar tanto las condiciones permisibles como las relevantes que pueden presentarse en determinada situacin. Solo deben incluirse en el estudio aquellas condiciones que son relevantes. El hecho de que una factura este firmada o no es una variable relevante. Sin embargo, el tamao de la hija de papel sobre la que est impresa probablemente no lo sea. Acciones Cuando se conocen todas las posibles condiciones, el siguiente paso del analista es determinar qu hacer cuando se presentan algunas de estas. Las acciones son opciones, que comprenden pasos, actividades o requerimientos, que puede elegir una persona cuando se enfrenta ante un conjunto de condiciones. En muchos procedimientos el analista debe considerar combinaciones de condiciones y acciones. Como ayuda para comprender y adaptar estas combinaciones, emplean rboles de decisin, tablas de decisin y el espaol estructurado. rboles de decisin Las personas pueden tener diferentes formas de decir lo mismo. Tener diferentes formas e decir la misma cosa pueden crear dificultades de comunicacin durante los estudios de sistemas. Por consiguiente, el analista busca evitar las malas interpretaciones. Asimismo, el analista necesita organizar la informacin recopilada con respecto a la toma de decisiones. Caractersticas de los rboles de decisin El rbol de decisin es un diagrama que representa en forma secuencial condiciones y acciones; muestra qu condiciones se consideran en primer
10

lugar, cuales en segundo y as sucesivamente. Este mtodo tambin permite mostrar la relacin que existe entre cada condicin y el grupo de acciones permisibles asociado con ella. La raz del rbol es el punto donde comienza la secuencia de decisin. La rama a seguir depende de las condiciones existentes y de la decisin que debe tomarse. Al avanzar de izquierda a derecha por una rama en particular, se obtiene una serie de toma de decisiones. Despus de cada punto de decisin, se encuentra el siguiente conjunto de decisiones a considerar. De esta forma, los nodos del rbol representan condiciones y sealan la necesidad de tomar una determinacin relacionada con la existencia de alguna de estas, antes de seleccionar la siguiente trayectoria. La parte que se encuentra a la derecha del rbol indica las acciones que deben realizarse, las que a su vez dependen de la secuencia de condiciones que las proceden. Uso de rboles de decisin El desarrollo de rboles de decisin beneficia al analista en dos formas. Primero que todo, la necesidad de describir condiciones y acciones llevan a los analistas a identificar de manera formal las decisiones que actualmente deben tomarse. De esta forma, es difcil para ellos pasar por alto cualquier etapa del proceso de decisin, sin importar que este dependa de variables cualitativas o cuantitativas. Los rboles de decisin tambin obligan a los analistas a considerar la secuencia de las decisiones. Identificacin de los requerimientos de datos Los rboles de decisin tambin son tiles para identificar los requerimientos de datos crticos que rodean al proceso de decisin; es decir, los rboles indican los conjuntos de datos que la gerencia requiere para formular decisiones o tomar acciones. Los rboles de decisiones se construyen despus de completar el anlisis de flujo de datos, entonces es posible que los datos crticos se encuentren ya definidos en el diccionario de datos. Si nicamente se utilizan rboles de decisin, entonces el analista debe tener la certeza de identificar con precisin cada dato necesario para tomar la decisin. Los analistas necesitan describir y definir todos los datos utilizados en la toma de decisiones para que sea posible disear el sistema de forma tal que los genere apropiadamente. Como evitar los problemas que se generan al utilizar rboles de decisin Los rboles de decisin no siempre son la mejor herramienta para el anlisis de decisiones. El rbol de decisin de un sistema complejo con
11

muchas secuencias de pasos y combinaciones de condiciones puede tener un tamao considerable. El gran nmero de ramas que pertenecen a varias trayectorias constituye ms un problema que una ayuda para el anlisis. En estos casos el analista corre el riesgo de no determinar qu polticas o estrategias de la empresa son la gua para la toma de decisiones especficas. Tablas de decisin La tabla de decisin es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de decisin, incluidas en una tabla de decisin, establecen el procedimiento a seguir cuando existen ciertas condiciones. Caractersticas de las tablas de decisin La taba de decisin est integrada por cuatro secciones: identificacin de condiciones, entradas de condiciones, identificacin de acciones y entradas de acciones. La identificacin de condiciones seala aquellas que son relevantes. Las entradas de condiciones indican que valor, si es que lo hay, se debe asociar para una determinada condicin. La identificacin de acciones enlista el conjunto de todos los pasos que se deben seguir cuando se presenta cierta condicin. Las entradas de acciones muestran las acciones especificas del conjunto que deben emprenderse cuando ciertas condiciones o combinaciones de estas son verdaderas. En ocasiones se aaden notas en la parte inferior de la tabla para indicar cundo utilizar la tabla o para diferenciarla de otras tablas de decisin. Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisin que establecen condiciones que deben satisfacerse para emprender un determinado conjunto de acciones. La regla de decisin incorpora todas las condiciones que deben ser ciertas y no solo una a la vez. Como construir tablas de decisin Para desarrollar tablas de decisin, los analistas deben emprender los siguientes pasos: 1Determinar los factores determinados como ms relevantes en la toma de decisiones. Esto permite identificar las condiciones en la decisin. Cada condicin seleccionada debe tener la caracterstica de ocurrir o no ocurrir; en este caso no es posible la ocurrencia parcial. 2- Determinar los pasos o actividades ms factibles bajo condiciones que cambian. Esto permite identificar las acciones. 3Estudiar las diferentes posibilidades de combinaciones de condiciones. Para cualquier nmero n de condiciones, existen 2 a la n combinaciones a considerar.
12

Llenar la tabla con las reglas de decisin. Existen dos formas para hacerlo. La primera, y ms largan, es llenar los renglones de condicin con valores s o no para cada combinacin posible de condiciones. Esto es, llenar la primera mitad del rengln con Si y la segunda con No. El siguiente rengln se llena alternando con S y N cada 25% del rengln; es decir, 25% Si, 25% No, 25% Si y 25% No. Se repite de nuevo este proceso: se llena cada rengln faltante en forma alterna con S y con N, dividiendo cada vez por potencias sucesivas de 2. El otro mtodo para llenar la tabla considera una condicin a la vez y, por cada condicin adicional le aade una tabla pero sin considerar las combinaciones de condiciones y acciones duplicadas. Verificacin de tablas de decisin Despus de construir una tabla, los analistas verifican que sea correcta y completa con la finalidad de asegurar que la tabla incluye todas las condiciones junto con las reglas de decisin que las relacionan con las acciones. Asimismo, los analistas tambin deben examinar la tabla para encontrar redundancias y contradicciones. Eliminacin de la redundancia: Las tablas de decisin pueden volverse muy grandes y difciles de manejar si se permite que crezcan sin ningn control. Remover las entradas redundantes puede ser de ayuda para manejar el tamao de la tabla. La redundancia se presenta cuando las siguientes condiciones son verdaderas al mismo tiempo: 1) dos reglas de decisin son idnticas salvo para una condicin del rengln y 2) las acciones para las dos reglas son idnticas. Supresin de contradicciones: las reglas de decisin son contradictorias entre s cuando dos o ms reglas tienen el mismo conjunto de contradicciones pero sus acciones son diferentes. Las contradicciones indican que la informacin que tiene el analista es incorrecta o bien existe un error en la construccin de la tabla. Sin embargo, muchas veces la contradiccin es resultado de las dependencias en la informacin que recibe el analista de diferentes personas con respecto a la forma en que estas toman decisiones. Se puede tomar una decisin especfica utilizando diferentes reglas. Encontrar tales discrepancias puede ser de gran utilidad para el analista que trabaja con la finalidad de mejorar una situacin de decisin. Tipos de entradas en una tabla Forma de entrada limitada: La estructura bsica de la tabla consistentes en S y N y entradas en blanco, es la forma de entrada limitada. Este es uno de los formatos ms comunes. Existen otros dos que tambin se emplean de manera amplia.
13

4-

Forma de entrada extendida: Esta forma reemplaza las S y las N con acciones que le indican al lector como decidir. En este formato, los identificadores de condicin y accin no estn completos y es la razn por la que las entradas contienen ms detalles que una S y N. Forma de entrada mixta: En ocasiones los analistas prefieren combinar en la misma tabla las caractersticas de los dos mtodos anteriores. En general, debe utilizarse solo una forma en cada seccin de la tabla, pero entre las secciones de condiciones y acciones se puede utilizar cualquier forma. Forma ELSE: Esta es otra variante de las tablas de decisin que tiene como finalidad omitir la repeticin por medio de reglas ELSE. Para construir una tabla de decisin en la forma ELSE, se especifican las reglas, junto con las entradas de condiciones, que cubren todo el conjunto de acciones con excepcin de una que se convierte en la regla a seguir cando ninguna de las dems condiciones explicitas es verdadera. Esta regla e encuentra en la columna final del margen derecho, que es la columna ELSE. Si ninguna de las otras condiciones es vlida, entonces se sigue la regla de decisin ELSE. Esta regla elimina la necesidad de repetir condiciones que conducen a las mismas acciones. Tablas mltiples La forma ELSE es una alternativa para controlar el tamao de las tablas de decisin. Otra manera de hacer esto es enlazando varias tablas de decisin. De acuerdo con las acciones seleccionadas en la primera tabla, otras se explican en una o ms tablas adicionales; cada tabla proporciona mayores detalles relacionados con las acciones a emprender. Por otra parte, las tablas mltiples permiten al analista establecer las acciones repetitivas que deben realizarse despus de tomar las decisiones y que continan hasta que se alcanza determinada condicin. Para utilizar este mtodo los analistas construyen, por separado, tablas de decisin que satisfacen todos los requerimientos normales y que estn relacionadas con una decisin especfica. Las tablas de enlazan en forma jerrquica: Una tabla de nivel-alto contiene las condiciones principales que, cuando son seleccionadas, determinan las tablas y acciones adicionales donde se encuentran otros detalles. Existen dos tipos de transferencia: directa y temporal. Transferencia directa: La transferencia directa se emplea una sola vez; la tabla que es seleccionada de esta manera no vuelve a referirse a la tabla original. La proposicin GO TO (nombre de la tabla) indica cual es la siguiente tabla que se va a examinar. Transferencia temporal: En contraste con la tabla anterior, la tabla 1 se enlaza con la proposicin PERFORM tabla 2. Al final de la tabla 2 la
14

proposicin RETURN regresa de nuevo el control a la proposicin que sigue al GO TO en la tabla 1. Procesadores de tablas de decisin Las tablas de decisin han sido parcialmente automatizadas. Los procesadores de tablas de decisin son programas para computadora que manejan la formulacin actual de una tabla con base en la informacin de entrada proporcionada por el analista. Estos procesadores tambin emprenden todas las verificaciones necesarias para detectar inconsistencias y redundancias. La utilidad de los procesadores de tablas de decisin radica en el ahorro de tiempo de programacin y deteccin de errores. Espaol estructurado El espaol estructurado es otro mtodo para evitar los problemas de ambigedad del lenguaje al establecer condiciones y acciones, tanto en procedimientos como en decisiones. Este mtodo no hace uso de rboles o tablas; en su lugar utiliza declaraciones para describir el proceso. El proceso no muestra reglas de decisin; las declara. Aun con esta caracterstica, las especificaciones en espaol estructurado requieren que el analista primero identifique las condiciones que se presentan en un proceso y las decisiones que se deben tomar cuando esto sucede, junto con las acciones correspondientes. Sin embargo, el mtodo tambin permite hacer una lista de todos los pasos en el orden que se llevan a cabo. Para ello no se utilizan smbolos y formatos especiales, caractersticas de los rboles y las tablas de decisin que para algunos resultan incmodos. Adems, es posible describir con rapidez los procedimientos en su totalidad ya que para ello de emplean declaraciones muy similares al espaol. La terminologa utilizada en la descripcin estructurada de una aplicacin consiste, en gran medida, en nombres de datos para los elementos que estn definidos en el diccionario de datos desarrollado para el proyecto. Desarrollo de declaraciones estructuradas El espaol estructurado emplea tres tipos bsicos de declaraciones para describir un proceso: estructuras de secuencia, estructuras de decisin y estructuras de iteracin. Estructuras de secuencia: Una estructura de secuencia es un solo paso o accin incluido en un proceso. Este no depende de la existencia de ninguna condicin y, cuando se encuentra, siempre se lleva a cabo. En general, se emplean varias instrucciones en secuencia para describir un proceso. Estructuras de decisin: El espaol estructurado es otro camino para mostrar el anlisis de decisin. Por tanto, a menudo se incluyen las
15

secuencias de acciones dentro de estructuras de decisin que sirven para identificar condiciones. Es as como las estructuras de decisin aparecen cuando se pueden emprender dos o ms acciones, lo que depende del valor de una condicin especfica. Para esto primero se evala la condicin y despus se toma la decisin de emprender las acciones o el grupo de acciones asociados con esta condicin. Una vez determinada la condicin las acciones son incondicionales. Estructuras de iteracin: En las actividades rutinarias de operacin, es comn encontrar que algunas de ellas se repiten mientras existen ciertas condiciones o hasta que estas se presentan. Las instrucciones de iteracin permiten al analista describir estos casos. Beneficios del espaol estructurado Como puede observarse, el espaol estructurado puede ser de utilidad para describir con claridad condiciones y acciones. Cuando se examina el ambiente de una empresa, los analistas pueden usar el espaol estructurado para declarar las reglas de decisin que se aplican en este medio. Si los analistas no pueden declarar que accin emprender cuando se toma una decisin, entonces necesitan adquirir mayor informacin para descubrir la situacin. Por otro lado, despus de describir las actividades en forma estructurada, los analistas pueden pedir a otras personas que revisen la descripcin y determinen con rapidez los errores u omisiones cometidos al establecer los procesos de decisin. ANLISIS ESTRUCTURADO Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de informacin, a profundo tienden a profundizar en un rea de la organizacin con la que tienen poca familiaridad. A pesar de esto, deben desarrollar un sistema que ayude a los gerentes y personal los futuros usuarios- de esta rea. Cualquier nuevo sistema o conjunto de recomendaciones para cambios en el sistema existente, ya sea este manual o automatizado, debe conducir hacia la mejora. Para alcanzar este resultado, se espera que los analistas de sistemas hagan lo siguiente: Aprendan los detalles y procedimientos del sistema en uso Obtengan una idea de las demandas futuras de la organizacin como resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolucin de las estructuras financieras, de la introduccin de la nueva tecnologa y cambios en las polticas del gobierno entre otros.

16

Documentar detalles del sistema actual para su revisin y discusin por otros. Evaluar la eficiencia y efectividad del sistema actual y sus procedimientos, tomando en cuenta el impacto sobre las demandas anticipadas para el futuro. Recomendar todas las revisiones y ampliaciones del sistema actual, sealando su justificacin. Si es apropiado, quiz la propuesta de un nuevo sistema completo. Documentar las caractersticas del nuevo sistema con un nivel de detalle que permita comprender a otros sus componentes, y de una manera que permita manejar el desarrollo del nuevo sistema. Fomentar la participacin de gerentes y empleados en todo el proceso, tanto para aprovechar su experiencia y conocimiento del sistema actual, como para conocer sus ideas, sentimientos y opiniones relacionadas con los requerimientos de un nuevo sistema o de los cambios para el actual. Para tener xito, los buenos analistas de sistemas estructuran el proceso que siguen para el desarrollo de un nuevo sistema. Aunque cada lugar donde trabaja l analista es diferente, las tareas que llevan a cabo son similares y existe un conjunto comn de preguntas por contestar cuando las emprenden. El anlisis estructurado es un mtodo para el anlisis de sistemas manuales o automatizados, que conduce al desarrollo de especificaciones para sistemas nuevos o para efectuar modificaciones a los ya existentes. Cuando los analistas de sistemas abordan una situacin poco familiar, siempre existe una pregunta sobre donde comenzar el anlisis. Una situacin dinmica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente. El anlisis estructurado permite al analista conocer un sistema o proceso en forma lgica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningn detalle pertinente. Qu es lo que se desea estructurar? Qu significa estructura? El objetivo que persigue el anlisis estructurado es organizar las tareas asociadas con la determinacin de requerimientos para obtener comprensin completa y exacta de una situacin dada. En el anlisis estructurado, la palabra estructura significa que: 1) el mtodo intenta estructurar el proceso de determinacin de los requerimientos comenzando con la documentacin del sistema existente; 2) el proceso est organizado de tal forma que intenta incluir todos los detalles relevantes que
17

describen el sistema en uso; 3) es fcil verificar cuando se han omitido detalles relevantes; 4) la identificacin de los requerimientos ser similar entre varios analistas e incluir mejores soluciones y estrategias para las oportunidades de desarrollo de sistemas; y 5) los documentos de trabajo generados para documentar los sistemas existente y propuesto son dispositivos de documentacin eficiente. Componentes del anlisis estructurado El anlisis estructurado hace uso de los siguientes componentes: 1Smbolos grficos: iconos y convenciones para identificar y describir los componentes de un sistema junto con las relaciones entre estos componentes. 2- Diccionario de datos: descripciones de todos los datos utilizados en el sistema. Puede ser manual o automatizado. 3- Descripciones de procesos y procedimientos: declaraciones formales que emplean tcnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema. 4- Reglas: estndares para describir y documentar el sistema en forma correcta y completa. Los analistas desean conocer las respuestas a cuatro preguntas especficas: qu procesos integran el sistema?, qu datos emplea cada proceso?, qu datos son almacenados? y qu datos ingresan y abandonan el sistema? Los datos son la gua de actividades de la empresa. Ellos pueden iniciar eventos y ser procesados para dar informacin til al personal que desean saber que tan bien se han manejado los eventos. Seguir el flujo de datos por todos los procesos de la empresa les dice mucho a los analistas sobre cmo se alcanzan los objetivos de la organizacin. El anlisis de flujo de datos estudia el empleo de los datos en cada actividad. Documenta los hallazgos con diagramas de flujo de datos que muestran en forma grafica la relacin entre procesos y datos, y en los diccionarios de datos que describen de manera formal los datos del sistema y los sitios donde son utilizados. CARACTERSTICAS DE LAS ESTRATEGIAS DE FLUJO DE DATOS El anlisis de flujo de datos analiza el empleo de los datos para llevar acabo procesos especficos de la empresa dentro del mbito de una investigacin de sistemas. El anlisis puede pensarse de tal manera que se estudien las actividades del sistema desde el punto de vista de los datos: donde se originan, donde se utilizan o cambian, hacia donde van, incluyendo las paradas a lo largo del camino que siguen desde su origen hasta su destino. Herramientas de la estrategia de flujo de datos

18

La estrategia de flujo de datos muestra el empleo de estos en forma grafica. Las herramientas utilizadas al seguir esta estrategia muestran todas las caractersticas esenciales del sistema y la forma en que se ajustan entre s. El anlisis de flujo de datos utiliza las siguientes herramientas: 1- Diagrama de flujo de datos: una herramienta grafica se emplea para describir y analizar el movimiento de datos a travs de un sistema, ya sea que este fuera manual o automatizado, incluyendo procesos, lugares para almacenar datos y retrasos en el sistema. Los diagramas de flujo de datos son la herramienta ms importante y la base sobre la cual se desarrollan otros componentes. La transformacin de datos de entrada en salida por medio de procesos puede describirse en forma lgica e independiente de los componentes fsicos asociados con el sistema. Estos diagramas reciben el nombre de diagramas lgicos de flujos de datos. 2- Diccionario de datos: el diccionario contiene las caractersticas lgicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripcin, alias, contenido y organizacin. Tambin identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la informacin. 3- Diagrama de estructura de datos: es una descripcin de la relacin entre las entidades de un sistema y el conjunto de informacin relacionado con la entidad. No considera el almacenamiento fsico de los datos. 4- Grafica de estructura: herramienta de diseo que muestra con smbolos la relacin entre los mdulos de procesamiento y el software de la computadora. Describen la jerarqua de los mdulos componentes y los datos que sern transmitidos entre ellos. Incluye el anlisis de las transformaciones entrada-salida y el anlisis de transacciones. Ventajas del anlisis de flujo de datos El anlisis de flujo de datos permite a los analistas aislar reas de inters en la organizacin y estudiarlas al examinar los datos que estn en el proceso, de tal manera que puedan observar la manera en que cambian cuando lo abandonan. A medida que los analistas renen hechos y detalles, comprenden mejor el proceso; esto los conduce a formular preguntas relacionadas con aspectos especficos del mismo y los lleva a una investigacin adicional. DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS Para que sean de utilidad y proporcionen informacin, los diagramas de flujo de datos deben dibujarse de forma adecuada.
19

Proceso de desarrollo Los analistas de sistemas estudian primero el sistema en uso, esto es, las actividades y procesos que ocurren en el presente. En la terminologa del anlisis estructurado, este es el estudio del sistema fsico. El sistema fsico se transada en una descripcin lgica que se centra en datos y procesos. Durante el anlisis de flujo de datos se evalan todos los detalles en trminos de los componentes lgicos de flujos de datos, procesos, almacenes de datos, orgenes y destinos. En todas las etapas de diseo que siguen, los requerimientos del sistema se trasladan en detalles de diseo lgico. En las fases de construccin, como la programacin del software para computadora, las especificaciones lgicas son trasladadas en caractersticas fsicas y en un sistemas de informacin que trabaja. Diagramas fsicos de flujo de datos Los diagramas de flujo de datos son de dos tipos: Diagramas fsicos de flujo de datos: proporcionan un panorama del sistema en uso, que es dependiente de la implantacin, que muestra que tareas se llevan a cabo y como. Las caractersticas fsicas incluyen: Nombre de personas Nombres o nmeros de formatos y documentos Nombres de departamentos Archivos maestros de transacciones Equipo y dispositivos utilizados Ubicaciones Nombres de procedimientos Diagramas lgicos de flujos de datos: proporcionan un panorama del sistema independiente de la implantacin, que se centra en el flujo de datos entre los procesos sin considerar los dispositivos especficos y la localizacin de almacenes de datos o personas en el sistema. En este tipo de diagramas no se indican las caractersticas fsicas. Reglas generales para el dibujo de diagramas lgicos de flujo de datos 1Cualquier flujo de datos que abandone un proceso debe estar basado en los datos que entran al proceso. 2- Todos los flujos de datos reciben un nombre, el nombre refleja los datos que influyen entre procesos, almacenes de datos, fuentes o destinos.

20

Solo deben entrar al proceso los datos necesarios para llevarlo a cabo. 4- Un proceso no debe ser nada de ningn otro sistema, es decir, debe ser independiente; la nica dependencia que debe existir es aquella que est basada en sus propios datos de entrada y salida. 5- Los procesos siempre estn en continua ejecucin; no se indican ni tampoco de detienen. Los analistas deben suponer que un proceso siempre est listo para funcionar o realizar el trabajo necesario. 6- La salida de los procesos puede tomar las siguientes formas: a- Flujo de datos con informacin aadida por el proceso. b- Una respuesta o cambio en la forma de los datos. c- Un cambio de decisin. d- Un cambio de contenido. e- Cambios en la organizacin. Seguir convenciones de nivelacin significativa Nivelacin es un trmino que se refiere al manejo de archivos locales. Los detalles relacionados con un solo proceso en un determinado nivel, deben permanecer dentro del proceso. Los almacenes y flujos de datos que son relevantes nicamente para el interior del proceso, son ocultados hasta que el proceso se extiende con mayor detalle. Asignar etiquetas significativas Las descripciones asignadas a los flujos de datos y procesos deben decirle al lector que est ocurriendo. Todos los flujos de datos deben tener un nombre que refleje con exactitud su contenido. Asignacin de nombre al flujo de datos: los nombres dados a los flujos de datos deben reflejar los datos de inters para los analistas, no los documentos o el lugar donde residen. Los datos que fluyen hacia los procesos experimentan cambios. Por consiguiente, el flujo de datos de salida tiene un nombre diferente al de entrada. Asignacin de nombre a los procesos: se deben asignar nombres a todos los procesos que les digan a los usuarios algo especfico con respecto a la naturaleza de las actividades del proceso. Los siguientes lineamientos tienen como finalidad servir de ayuda para identificar los procesos de forma tal que sean tiles a las actividades subsecuentes de anlisis y diseo: 1Seleccionar nombres que indiquen la accin que se lleva a cabo.
21

3-

23-

Asegurar que el nombre describa completamente al proceso. Seleccionar nombres para los procesos que expliquen el enlace entre los flujos de entrada y los de salida. 4- Evitar nombres vagos para los procesos. 5- Utilizar los nombres de los procesos de bajo nivel ya que estos son ms especficos y descriptivos que los asociados con los procesos de alto nivel. 6- Asignar nombres a los procesos que sean nicos para la actividad que ellos describen. Evaluacin del flujo de datos para verificar que es correcto Las siguientes preguntas son de utilidad para evaluar los diagramas de flujo de datos: 1Existen en el diagrama de flujo de datos componentes que no tienen nombre? 2- Existen almacenes de datos que son entradas y a los que nunca se les hace referencia? 3- Existen procesos que no reciben entradas? 4- Existen procesos que no generan salidas? 5- Existen procesos que tienen varias finalidades? 6- Existen almacenes de datos a los que nunca se les hace referencia? 7Es el flujo de datos que llega a un proceso adecuado para realizarlo? 8- Existen demasiados datos en el almacn de datos? 9- El flujo de datos que llega a un proceso es demasiado extenso para la salida que este produce? 10- Se introducen alias en la descripcin del sistema? Aparecen en el diccionario de datos? 11- Los procesos son independientes entre s? Dependen solo de los datos que reciben como entrada? CARACTERSTICAS DE LOS DICCIONARIOS DE DATOS Los diccionarios de datos son un componente importante del anlisis estructurado ya que por s solos los diagramas de flujo de datos no describen el objeto de la investigacin. El diccionario de datos proporciona ms informacin relacionada con el sistema. Un diccionario de datos es un catalogo, un deposito, de los elementos en un sistema. Como su nombre lo sugiere, estos elementos se centran alrededor de los datos y la forma en que estn estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organizacin. Los

22

elementos ms importantes son flujos de datos, almacenes de datos y procesos. Importancia del diccionario Los analistas utilizan el diccionario de datos por cinco razones importantes: Para manejar los detalles en sistemas grandes. Para comunicar un significado comn para todos los elementos del sistema Para documentar las caractersticas del sistema Para facilitar el anlisis de los detalles con la finalidad de evaluar las caractersticas y determinar donde efectuar cambios en el sistema Localizar errores y omisiones en el sistema. Contenido de un registro del diccionario Todas las partes de un sistema de informacin dependen de los datos. El diccionario contiene dos tipos de descripciones para flujo de datos dentro del sistema: Elementos dato: son los bloques bsicos para todos los dems datos del sistema. Por si mismo no conllevan suficiente significado para ningn usuario. Estructuras de datos: es un grupo de datos elementales que estn relacionados con otros y que en conjunto describen un componente del sistema. Descripcin de los elementos dato Cada entrada en el diccionario de datos consiste de un conjunto de detalles que describen los datos utilizados o producidos por el sistema. Cada uno est identificado con un nombre, descripcin, alias y longitud, junto con el intervalo de valores especficos para el dato permitidos por el sistema bajo estudio. Nombre de los datos: Para distinguir un dato del otro, los analistas les asignan nombres que sean significativos. Los nombres se emplean para hacer referencia a cada elemento durante todo el proceso de desarrollo de sistemas. Descripcin de los datos: La descripcin de un dato describe de manera breve lo que este representa en el sistema. Las descripciones de los datos deben escribirse con la suposicin de que la persona que las leer no sabe nada con respecto al sistema.
23

Alias: Con frecuencia el mismo dato recibe varios nombres, mismos que dependen e quien haga uso del dato. Estos nombres se denominan alias. Un diccionario significativo debe incluir todos los alias. Longitud: La longitud identifica el nmero de espacios necesarios para cada dato pero sin considerar la forma en que sern almacenados. Valores de los datos: En algunos procesos solo son permitidos valores muy especficos para los datos. Todos los detalles sern de utilidad a los analistas ms adelante, cuando diseen los controles del sistema. Descripcin de las estructuras de datos Las estructuras de datos se construyen sobre cuatro relaciones de componentes: Relacin secuencial: define los componentes que siempre se incluyen en una estructura de datos en particular; concatenacin de dos o ms datos. Relacin de seleccin: define alternativa para datos o estructuras de datos incluidas en una estructura de datos. Relacin de iteracin: define la repeticin de un componente cero o ms veces. Relacin opcional: caso especial de la iteracin; los datos pueden estar o no incluidos, esto es, una o ninguna iteracin. FINES DE LOS PROTOTIPOS DE APLICACIONES La finalidad del desarrollo de prototipos se entiende mejor al examinar las razones para seleccionar esta estrategia y la forma en la que incrementa el nivel de productividad en el desarrollo de sistemas. Por otra parte tambin se explora la naturaleza de las aplicaciones que son buenos candidatos para desarrollo con el mtodo del prototipo. Usos de los prototipos de aplicaciones El desarrollo de prototipos de aplicacin tiene dos usos principales. Por un lado, es un medio eficaz para aclarar los requerimientos de os usuarios. Las especificaciones por escrito se crean, en general, como vehculos para describir las caractersticas y requerimientos que debe satisfacer la aplicacin. El segundo uso del prototipo de aplicacin es verificar la factibilidad del diseo de un sistema. Los analistas pueden experimentar con diferentes caractersticas de la aplicacin y evaluar la reaccin y respuesta por parte del usuario.
24

Razones para el empleo de prototipos Las razones para el uso de prototipos son el resultado directo de la necesidad de disear y desarrollar sistemas de informacin con rapidez, eficiencia y eficacia. Aumento de la productividad La productividad es importante para los analistas de sistemas y para la organizacin en la que trabajan. Los analistas de sistemas son ms productivos si toman precauciones que: Minimicen el tiempo que se pierde debido al desarrollo incorrecto. Minimicen los errores del diseo. Garanticen que los esfuerzos realizados por ellos sean fructferos. Garanticen que los usuarios reciban la aplicacin que necesitan. Garanticen que no tendr que volverse a hacer el trabajo de desarrollo. Al mismo tiempo, los analistas se enfrentan a muchos obstculos para alcanzar sus objetivos de desarrollo. A continuacin se mencionan varios hechos que deben considerarse: Los usuarios tienen gran dificultad para especificar con anticipacin sus necesidades de informacin, en especial cuando la situacin es nueva o cambia con rapidez. La especificacin completa de los requerimientos de informacin depende en particular de la forma en que debe utilizarse la tecnologa. A menudo las descripciones estticas de sistemas no son suficientes para proporcionar detalles sobre situaciones dinmicas. La mala comunicacin, que siempre es una posibilidad, parece que siempre se presenta en el momento menos oportuno. Aplicaciones para candidatos Los prototipos son ms eficaces en el desarrollo de sistemas de informacin cuando se cumples ciertas condiciones- Cualquiera de las siguientes cinco condiciones sugieren la necesidad de utilizar un prototipo.
25

No se conocen los requerimientos: La naturaleza de la aplicacin es tal que existe poca informacin disponible con respecto a las caractersticas que debe tener l sistema para satisfacer los requerimientos el usuario. Los requerimientos necesitan evaluarse: Se conocen los requerimientos aparentes de informacin, tanto de los usuarios finales como de la organizacin, pero es necesario verificarlos y evaluarlos. Costos altos: La inversin de recursos financieros y humanos as como el tiempo necesario para generar la aplicacin es sustancial. Existen otros proyectos que tambin compiten por los mismos recursos. Alto riesgo: La evaluacin inexacta de los requerimientos del sistema o el desarrollo incorrecto de una aplicacin ponen en peligro a la organizacin, a sus empleados y tambin a sus propios recursos. Nueva tecnologa: El deseo de instalar nueva tecnologa ya sea con los campos de la computacin, de las comunicaciones de datos u otras reas relacionadas, abre nuevas fronteras para la organizacin. Muchas compaas no tienen experiencia en el uso de cierta tecnologa ni tampoco las dems organizaciones con las que se comunican. ETAPAS DEL MTODO DE PROTOTIPOS Identificacin de requerimientos conocidos La determinacin de los requerimientos de una aplicacin es tan importante para el mtodo de desarrollo de prototipos como lo es para los mtodos del ciclo clsico de desarrollo de sistemas o anlisis estructurado. Por consiguiente, antes de crear el prototipo, los analistas y usuarios deben trabajar juntos para identificar los requerimientos conocidos que tienen que satisfacerse. Desarrollo de un modelo de trabajo La construccin de un prototipo es un proceso iterativo de desarrollo. Antes de la primera iteracin, los analistas de sistemas explican el mtodo a los usuarios, las actividades a realizar, la secuencia en la que se llevaran a cabo y tambin discuten las responsabilidades de cada participante. Un cronograma para el inicio y fin de la primera iteracin es de gran ayuda, por tanto, debe elaborarse justo antes de iniciar las actividades. En el desarrollo de un prototipo se preparan los siguientes componentes: El lenguaje para el dialogo o conversacin entre el usuario y el sistema.
26

Pantallas y formatos para la entrada de datos. Mdulos esenciales de procesamiento. Salida del sistema.

USO DE PROTOTIPOS Cuando el prototipo est terminado, el siguiente paso es tomar la decisin sobre cmo proceder. Existen cuatro caminos a seguir despus de evaluar la informacin obtenida con el desarrollo y uso del prototipo: Abandono de la aplicacin En algunos casos, la decisin es descartar el prototipo y abandonar el desarrollo de la aplicacin. Esta conclusin no significa que fuese un error emprender el proceso de desarrollo del prototipo o un desperdicio de recursos. Ms bien, la informacin y experiencia ganada con el desarrollo y empleo del prototipo condujo hacia una decisin de desarrollo. Es probable que los usuarios y analistas hayan aprendido que el sistema era innecesario o hayan descubierto otra solucin durante el proceso. Implantacin del prototipo Algunas veces el prototipo se convierte en el sistema que se necesita. En este caso, se implanta sin ninguna modificacin y no se emprenden ms esfuerzos de desarrollo. Esta decisin es ms probable tomarse bajo una o ms de las siguientes circunstancias: La evolucin de prototipo condujo a una aplicacin que tiene las caractersticas, capacidades y desempeo requeridos. La aplicacin ser utilizada con poca frecuencia y no es importante su rapidez o eficiencia operacional. La aplicacin no tiene efecto sobre otras aplicaciones o datos de la organizacin y tampoco interacciona con ellos; adems satisface las necesidades de os usuarios inmediatos. El medio ambiente de la aplicacin se encuentra en un estado de flujo; es difcil determinar necesidades a largo plazo o condiciones de operacin ms estables. En consecuencia no es posible justificar otras actividades de desarrollo. El prototipo es de utilidad para las condiciones actuales. Desarrollo de la aplicacin Cuando un prototipo tiene xito puede proporcionar informacin muy amplia con respecto a los requerimientos de la aplicacin y conducir a su completo desarrollo. Terminar el prototipo n significa finalizar el proceso de desarrollo. Ms bien seala el comienzo de la siguiente actividad: el desarrollo completo de la aplicacin.
27

El desarrollo de una aplicacin puede presentarse como parte del mtodo de ciclo de vida de los sistemas de informacin. Las dos formas ms comunes de incorporar la construccin de un prototipo para la aplicacin son las siguientes: El prototipo se emplea como una opcin para la determinacin de requerimientos; las caractersticas del prototipo son consideradas como los requerimientos a satisfacer en subsecuentes actividades de desarrollo. El prototipo se utiliza como sustituto para el diseo e implantacin de la aplicacin, es decir, como un esqueleto a partir del que se construye el resto del sistema. Inicio de un nuevo prototipo Algunas veces la informacin ganada con el desarrollo y uso del prototipo, sugiere el empleo de un enfoque muy diferente para satisfacer las necesidades de la organizacin. En este caso es posible encontrar que las caractersticas de la aplicacin con muy diferentes si el prototipo es inadecuado para demostrarlas y evaluarlas. HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS Lenguajes de cuarta generacin Los lenguajes de cuarta generacin fueron creados para ayudar a satisfacer la necesidad de desarrollar un software con mayor eficiencia. Los lenguajes de cuarta generacin incluyen un amplio espectro de lenguajes de computadora que hacen hincapi sobre lo que debe hacerse ms que sobre cmo realizar la tarea. Los lenguajes de cuarta generacin se clasifican en tres categoras: Lenguajes no orientados hacia procedimientos: El lenguaje con el que trabajan los analistas y usuarios finales no est orientado hacia procedimientos. Algunas veces el lenguaje recibe l nombre de lenguajes no-procedurales. Un solo mandato lleva a cabo una funcin completa. No es raro encontrar que el mandato de un lenguaje no orientado hacia procedimientos remplace al equivalente de ms de cien instrucciones de un lenguaje de tercera generacin. Lenguajes de consulta y recuperacin: Estos lenguajes facilitan la recuperacin de datos almacenados sin necesidad de escribir muchas instrucciones orientadas hacia procedimientos, o especificar el formato de los datos. Estos lenguajes permiten a los usuarios formular preguntas en formatos tabulares o parecidos al ingles. Generadores de reportes
28

Los generadores de reportes permiten a los usuarios obtener con facilidad datos de archivos o bases de datos. Se puede obtener el contenido parcial o total de los registros. En comparacin con los lenguajes de consulta y recuperacin, los generadores de reportes dan a los usuarios mayor control sobre la apariencia y contenido de la salida. Los resultados se pueden presentar en un formato de reporte que se establece en forma automtica por software, o el usuario tambin puede proporcionar las especificaciones que instruyan al sistema para preparar ttulos especficos, descripciones de pgina y encabezados de columnas. Generadores de aplicaciones Los generadores de aplicaciones son programas de software que permiten la especificacin de toda una aplicacin de un nivel muy alto. Ellos proporcionan las condiciones para desarrollar aplicaciones que acepten datos, efecten clculos, sigan complicadas rutinas de procesamiento lgico y produzcan reportes y salidas. El generador de aplicaciones produce el cdigo fuente. Algunos producen programas completos. Otros, denominados generadores de programas, reparan el cdigo del programa, como mdulos individuales, y permiten al usuario enlazar otros mdulos con los producidos por el generador. Generadores de pantalla Un generador de pantalla es una herramienta interactiva para dibujar pantallas y efectuar la validacin automtica de la entrada y procesamiento. Es posible seleccionar con respuestas sencillas preferencias sobre el presentar con mayor brillantez la informacin ms importante, el utilizar determinados colores o hacer uso del video inverso. Los generadores de pantalla tambin permiten que los usuarios preparen automticamente componentes que sean de ayuda en la interaccin usuariomaquina, incluyendo la localizacin de campos para entrada de datos, campos para presentar datos, encabezados de columna, etiquetas y mensajes. IMPORTANCIA DE LAS HERRAMIENTAS EN EL DESARROLLO DE SISTEMAS Las herramientas son esenciales para el anlisis de sistemas. Ellas mejoran la forma en que ocurre el desarrollo y tienen influencia sobre la calidad del resultado final. Beneficios del empleo de herramientas Con las herramientas, el analista tiene el potencial de ser ms productivo; se pueden completar las mismas actividades de desarrollo en un tiempo menor que el que se necesita usando no se utilizan las herramientas.
29

Las herramientas sugieren procedimientos que conducen al empleo de procesos ms eficaces. Si la productividad significa realizar la tarea correcta, la eficacia significa hacer la tarea en forma correcta. Cuando las herramientas mejoran los procesos, por lo general tambin ocurre lo mismo con los resultados. Beneficios de las herramientas asistidas por la computadora La introduccin de herramientas asistidas por la computadora en los esfuerzos de anlisis y desarrollo aumentan los beneficios que se derivan del uso de las herramientas. Las herramientas del anlisis asistido por la computadora mejoran la velocidad y disminuyen el tiempo necesario para completar la tarea de desarrollo. La automatizacin tambin se hace cargo de algunas tareas que son pesadas. El desarrollo de diagramas de flujo de datos es una tarea que puede consumir mucho tiempo. Las herramientas automatizadas para flujo de datos hacen posible dejar al software de la computadora el proceso de dibujo. Cuando los procedimientos forman parte del software, estos se realizan en forma ms consistente. Se convierten en rutinas. La consistencia que pueden ofrecer los procedimientos es una excelente razn para ampliar el conjunto de herramientas asistidas por computadora para el desarrollo de sistemas. Una ventaja que distingue a muchos sistemas automatizados es la captura, almacenamiento, procesamiento y recuperacin de los detalles de un sistema. Una vez en forma procesable por la computadora, los detalles del sistema pueden utilizarse para muchas finalidades. CLASIFICACIN DE HERRAMIENTAS AUTOMATIZADAS Herramientas de tipo front-end Las herramientas de tipo front-end automatizan las primeras actividades del proceso de desarrollo de sistemas. Entre los muchos aspectos que se toman en cuenta al desarrollar herramientas para esta fase, se hallan tcnicas de soporte para ayudar al analista a preparar especificaciones formales que carezcan de ambigedades, a validar las descripciones del sistema con el objeto de determinar su consistencia y completez, y a seguir la evolucin de los requerimientos de la aplicacin en caractersticas que formen parte del sistema que finalmente ser implantado. Herramientas de tipo back-end Las herramientas de tipo back-end tienen como finalidad ayudar al analista a formular la lgica del programa, los algoritmos de procesamiento y la descripcin fsica de los datos, tambin ayudan a la interaccin con los
30

dispositivos, etc. Estas actividades convierten los diseos lgicos del software en un cdigo de programacin que es el que finalmente da existencia a la aplicacin. Herramientas integrales Las actividades de anlisis abordan los detalles de alto nivel mientras que las actividades de desarrollo dan mayor importancia a los detalles de bajo nivel. Las especificaciones de alto nivel describen los requerimientos del usuario, como entradas, salidas y expectativas de funcionamiento. Las especificaciones de bajo nivel indican la forma en que sern satisfechos estos requerimientos por medio de detalles que son especficos de la computadora. HERRAMIENTAS ASISTIDAS POR COMPUTADORA PARA LE INGENIERA DE SISTEMAS (CASE) Las herramientas de tipo CASE incluyen los siguientes cinco componentes: Herramientas para diagramacin: Estas herramientas dan soporte al anlisis y documentacin de los requerimientos de una aplicacin. Por lo general, incluyen facilidades para producir diagramas de flujo de datos. Las herramientas ofrecen la capacidad de dibujar diagramas y cartas, adems de guardar los detalles en forma interna. Depsito centralizado de informacin: La captura, anlisis, procesamiento y distribucin de todos los sistemas de informacin es asistida por un depsito de informacin centralizado o diccionario de datos. Aunque los diccionarios son diseados para que el acceso a la informacin sea sencillo, tambin incluyen controles y medidas de proteccin que preservan la exactitud y consistencia de los detalles del sistema. Generador de interfaces: Los generadores de interfaces ofrecen la capacidad para preparar imitaciones y prototipos para las interfaces con los usuarios. Por lo general, soportan la rpida creacin de mens de demostracin para el sistema, de pantallas de presentacin y del formato de los informes. Generadores de cdigo: Los generadores de cdigo automatizan la preparacin del software. Estos incorporan mtodos que permiten convertir las especificaciones del sistema en cdigo ejecutable. Herramientas de administracin: Algunas herramientas CASE para administracin permiten que los gerentes de proyecto especifiquen elementos de su propia eleccin. Otras permiten definir metodologas de desarrollo propias, incluyendo las reglas de validacin y los estndares para datos nombres de procedimientos.

31

Integracin de la herramientas CASE La integracin de la herramientas ocurre en tres formas: Interface uniforme: Significa que todas las herramientas en el sistema CASE son activadas de la misma manera y desde un lugar comn en el sistema. Facilidad para la transferencia de datos: Significa que los detalles desarrollados con una herramienta pueden estar disponibles para otras. El diccionario de datos es el elemento crtico que hace posible la transferencia de datos entre herramientas distintas. Unir de las actividades de desarrollo: La facilidad para transferir datos y la unin de las fases de desarrollo se encuentran relacionadas, ya que se pueden utilizar una y otra vez los datos transferidos entre herramientas a travs de todo el proceso de desarrollo. USO DE UNA HERRAMIENTA CASE Operaciones inciales Los sistemas CASE almacenan informacin por proyecto. Cada aplicacin de sistemas de informacin es considerada como un proyecto. Antes de iniciar el trabajo, el analista debe proporcionar su nombre y contrasea. Si es correcta, Excelerator presenta sobre la pantalla una lista de todos los proyectos para los que el analista tiene autorizado el acceso. Men principal de funciones El men principal presenta los nombres de las siete funciones ms importantes d Excelerator: graficas, XLDicionario, pantallas y reportes, documentacin, anlisis, interfaces y utileras. Dibujo de diagramas de flujo de datos Cuando se selecciona la funcin de graficas, aparece otro men que muestra las opciones disponibles para l analista. Los diagramas de flujo de datos son uno de los muchos tipos de diagramas y cartas disponibles en el men de graficas. Diccionario por proyecto A medida que se formulan las especificaciones y la documentacin, toda la informacin con respecto al proyecto se acumula en el diccionario de datos que Excelerator mantiene para dicho proyecto. Parte de la informacin, como el flujo de datos entre procesos, la graba directamente la persona que hace uso de la herramienta. Pantallas e informes Excelerator, como muchas otras herramientas de tipo CASE, proporciona un mtodo rpido y sencillo para desarrollar prototipos de pantallas para que los usuarios finales trabajen con ellas. El analista puede disear y
32

ejecutar pantallas y reportes con el apoyo de un men, e incluso desarrollar el prototipo de una base de datos. Herramientas para el anlisis y documentacin Excelerator ofrece caractersticas tales como un conjunto de reportes que validan las descripciones del sistema. Los reportes del anlisis contienen una lista de relaciones inconsistentes o ilegales entre datos, flujos de datos y procesos, as como consistencias al seguir las convenciones para asignar nombres. Tambin es posible detectar y notificar diagramas no balanceados. Utileras La informacin utilizada por el sistema Excelerator se encuentra descrita por las funciones de utilera. Existe tambin una funcin especial para el manejo de proyectos que los analistas emplean para dar nombre al proyecto, proporcionar descripciones del mismo y definir la notacin que utilizaran para los diagramas de flujo de datos. Beneficios de CASE Entre los beneficios ofrecidos por la tecnologa CASE se encuentran los siguientes: Facilidad para llevar a cabo la tarea de revisin de especificaciones del sistema as como de representaciones graficas. Facilidad para desarrollar prototipos de sistemas para desarrollar prototipos de sistemas por medio de la capacidad para cambiar especificaciones y, por otro lado, para determinar el efecto que sobre el desempeo del sistema tendrn otras alternativas. Generacin de cdigo. Soporte para mantenimiento como resultado de haber guardado las especificaciones del sistema en un depsito central de informacin. Aumentar las posibilidades de satisfacer los requerimientos del usuario.

Debilidades de CASE Entre las debilidades de CASE se encuentran las siguientes: Muchas herramientas CASE estn construidas teniendo como base las metodologas del anlisis estructurado y del
33

ciclo de vida de desarrollo de sistemas. Por si sola, esta caracterstica puede convertirse en la principal limitante ya que no todas las organizaciones emplean mtodos de anlisis estructurado. Falta de niveles estndar para el soporte de tecnologa. Conflictos en el uso de diagramas. Diagramas no utilizados. En algunos casos las herramientas graficas automatizadas o manuales no se emplean del todo. Aunque una herramienta puede apoyar varias fases del ciclo de vida de desarrollo de sistemas o adaptarse a diferentes metodologas de desarrollo, por lo general su enfoque primario est dirigido hacia una fase o mtodo especifico. Aunque muchas herramientas basadas en computadora incluyen la capacidad de verificar las especificaciones para determinar su completez o consistencia, virtualmente no llevan a cabo ningn anlisis de los requerimientos de la aplicacin. Las tareas humanas siguen siendo crticas. Las herramientas deben adaptarse a la arquitectura de la informacin as como a las metodologas de desarrollo utilizadas por la organizacin.

34