Primera Fase - Análisis

La determinación de requerimientos es el estudio de un sistema para conocer como trabaja y donde es necesario efectuar mejoras, dando como resultado una evaluación de la forma como trabajan los métodos empleados y si es necesario o posible realizar ajustes.

Un requerimiento es una característica que debe incluirse en un nuevo sistema. Esta puede ser la inclusión de determinada forma para capturar o procesar datos, producir información, controlar una actividad de la empresa o brindar soporte a la gerencia. Es así como la determinación de requerimientos vincula el estudio de un sistema existente con la recopilación de detalles relacionados con él.

Actividades de la determinación de requerimientos

Es útil ver la determinación de requerimientos a través de tres grandes actividades:

Anticipación de requerimientos: La experiencia de los analistas les permite anticipar ciertos problemas o características y requerimientos para un nuevo sistema.

Por un lado, la experiencia de estudios previos puede conducir a la investigación de áreas que no consideraría un analista novato. Tener las bases necesarias para saber que preguntar o que aspectos investigar puede ser de beneficio substancial para la organización.

Por otra parte, si se introducen sesgos o atajos al conducir la investigación entonces es muy probable que la anticipación de requerimientos se convierta en un problema. Por lo tanto, siempre deben darse lineamientos para estructurar una investigación alrededor de cuestiones básicas con la finalidad de evitar consecuencias indeseables de la anticipación de requerimientos.

Investigación de requerimientos: Es la más importante del análisis de sistemas. Los analistas estudian el sistema actual con la ayuda de varias herramientas y habilidades, y documentan características para, mas adelante, emprender el análisis.

La investigación de requerimientos depende de las técnicas para encontrar datos, que serán explicadas mas adelante, e incluyen los métodos para documentar y describir las características de l sistema.

Especificaciones de requerimientos: Los datos obtenidos durante la recopilación de hechos se analizan para determinar las especificaciones de los requerimientos, es decir, la descripción de las características del nuevo sistema. Esta actividad tiene tres partes relacionadas entre sí:

- Análisis de datos basados en hechos reales: Se examinan los datos recopilados durante el estudio, incluidos en la documentación de flujo de datos y análisis de decisiones, para examinar el grado de desempeño del sistema y si cumple con las demandas de la organización.
- Identificación de requerimientos esenciales: Características que deben incluirse en el nuevo sistema y que van desde detalles e operación hasta criterios de desempeño.
- Selección de estrategias para satisfacer los requerimientos: Métodos que serán utilizados para alcanzar los requerimientos establecidos seleccionados. Estos forman la base para el diseño de sistemas, los cuales deben cumplir con la especificación de requerimientos.

La especificación de requerimientos implica gran responsabilidad para los analistas de sistemas, ya que la calidad de trabajo realizado en esta etapa se vera reflejada mas adelante en las características del nuevo sistema.

Requerimientos básicos

Los analistas estructuran su investigación al buscar respuestas a las siguientes cuatro importantes preguntas:

¿Cuál es el proceso básico de la empresa?

¿Qué datos utiliza o produce esta empresa?

¿Cuáles son los limites impuestos por el tiempo y la carga de trabajo?

¿Qué controles de desempeño utiliza?

Comprensión 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 comprensión necesaria:

¿Cual es la finalidad de esta actividad dentro de la empresa?
¿Qué pasos se siguen para llevarla a cabo?
¿Dónde se realizan estos pasos?
¿Quiénes lo realizan?
¿Cuánto tiempo tardan n efectuarlos?
¿Con cuanta frecuencia lo hacen?
¿Quiénes emplean la información resultante?

Identificación de los datos empleados e información 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 articulo la cantidad existente, la demanda esperada, el nombre del proveedor y el costo. Para saber cuando hacer cada pedido, el comprador debe considerar el tiempo de entrega de la mercancía.

Por otra parte, muchas transacciones comerciales producen información útil para los gerentes cuando estos evalúan el desempeño de empleados, negocios y sistemas; esta información también puede ser de utilidad, en otro contexto, para los gerentes y analistas. Por ejemplo, los analistas curiosos encuentran que los datos relacionados con e abasto del inventario y almacenaje también proporcionan información con respecto a demandas del almacén, 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 año 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 información puede llevar al analista a considerar mas preguntas importantes para determinar la razón de esta frecuencia y su efecto sobre las actividades de la empresa.

Muchas veces la forma más fácil de obtener esta información es identificar el objetivo de la actividad: ¿Cuál es la causa de la actividad? En ocasiones los analistas se refieren a la causa directa como la función de iniciación. 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 razón 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.

Identificación de controles

En situaciones donde se ejerce buen control ya sea por parte de la gerencia o por el seguimiento del proceso, quizás no sea problema determinar si una actividad se ha llevado a cabo en forma adecuada. Aun así, los analistas deben examinar los métodos de control durante la etapa de análisis: ¿existen estándares específicos de desempeño?, ¿quién se encarga de comparar el desempeño contra los estándares?, ¿cómo se detectan los errores?, ¿cómo se corrigen los errores?, ¿se cometen demasiados errores?. La falta o debilidad de los controles es un descubrimiento importante en cualquier investigación de sistemas.

Requerimientos de las transacciones de los usuarios

Los sistemas a nivel de transacciones, capturan, procesan y almacenan datos por alguna razón. Por ejemplo, en un sistema de pedidos, los pedidos de los clientes son procesados de forma tal quesea posible enviar los artículos 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 transacción que esta siendo procesada?
¿Qué es lo que inicia la transacción?
¿Quién inicia los pedidos? ¿Con que propósito?
¿Con que frecuencia ocurren los pedidos?
¿Qué volumen esta asociado con cada pedido?
¿Existen diferentes condiciones que pueden afectar la forma en que se procesan los pedidos?
¿Que detalles son necesarios para procesar la transacción?
¿Qué información se genera? ¿Qué datos se guardan?

Requerimientos de decisión de los usuarios

A diferencia de las actividades de transacción, las relacionadas con decisiones no siguen un procedimiento especifico. Las rutinas no son muy claras y es posible que los controles sean vagos. Las decisiones se toman al integrar la información en forma tal que los gerentes puedan saber que acciones emprender. Es probable que los sistemas de decisión 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 volumen mencionadas anteriormente, pero también deben hacer otras para determinar los requerimientos de las decisiones:

1- ¿Qué información se utiliza para tomar la decisión?

2- ¿Cuál es la fuente de información? ¿Qué sistemas de transacciones producen los datos en el proceso de decisión? ¿Qué otros datos son necesarios y no es posible obtener del procesamiento de transacciones? ¿Qué datos se originan en fuentes externas a la organización?

3- ¿Cómo se deben procesar los datos para producir la información necesaria?

4- ¿Cómo debe plantearse la información?

Estas preguntas también señalan la relación entre los sistemas de transacciones y los de decisiones. Información muy valiosa puede perderse si los sistemas de transacciones no capturan y guardan los datos necesarios para las decisiones. Los sistemas de inventario capturan información relacionada con los continuos pedidos, recepciones, ventas y envió de artículos. Los datos que estos sistemas almacenan son procesados nuevamente para generar información de manera periódica para analizar ventas, determinar políticas de procesos o decidir planes de mercadotecnia para líneas 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 organización

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 también deben evaluar las implicaciones para los demás departamentos con los que interactúa el sistema bajo investigación. Es responsabilidad del analista identificar las dependencias entre departamentos y determinar como los afecta un proyecto de sistemas.

En muchas ocasiones, cuando trabajan con usuarios, los analistas escuchan como deberían manejarse las excepciones. Claro esta que una aplicación debe diseñarse para dar cabida a los eventos rutinarios. Pero los analistas deben abordar lo que esta 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 hacer una excepción al procedimiento? ¿Todos los empleados siguen el mismo procedimiento?

TÉCNICAS PARA ENCONTRAR HECHOS

Los analistas utilizan métodos específicos, denominados técnicas para encontrar hechos, con el objeto de reunir datos relacionados con los requerimientos. Entre estos se incluyen la entrevista, el cuestionario, la revisión de los registros y la observación. En general, los analistas emplean mas de una de estas técnicas para llevar a cabo una investigación amplia y exacta.

Entrevistas:

Los analistas emplean la entrevista para reunir información proveniente de personas o de grupos. Por lo común, 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 serán afectados por el. Aunque algunos analistas prefieren la entrevista sobre otras técnicas, esta no siempre es la mejor fuente de datos sobre la aplicación. Dado que la entrevista lleva tiempo, es necesario utilizar otros métodos para obtener la información necesaria para conducir una investigación.

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 información general del sistema. Este formato anima a los entrevistados a compartir sus sentimientos, ideas y creencias. Por otro lado, las entrevistas estructuradas utilizan preguntas estándar 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 información 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 mas confiables que otras técnicas; por otra parte, su amplia distribución asegura el anonimato de los encuestados, situación que puede conducir a respuestas mas honestas. Sin embargo, este método 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 especificas para escoger.

Revisión de los registros

Varios tipos de registros y reportes pueden proporcionar al analista información valiosa con respecto a las organizaciones y a sus operaciones. Al revisar los registros, el analista examina la información asentada en ellos relacionada con el sistema y los usuarios. La revisión de los registros puede efectuarse al comienzo del estudio, como introducción, o también después, y sirve de base para completar las operaciones actuales. Por lo tanto los registros pueden indicar que esta sucediendo.

Los registros incluyen manuales de políticas, reglamentos y procedimientos estándares de operación utilizados por la mayor parte de las organizaciones como guías 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 afán de comprender el sistema al familiarizarlo con aquellas operaciones que necesitan apoyo con las relaciones formales dentro de la organización.

Observación

La observación permite al analista ganar información que no se puede obtener por otras técnicas. Por medio de la observación el analista obtiene información de primera mano sobre la forma en que se efectúan las actividades. El método es mas ú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 investigación de sistemas dentro de la empresa.

Las herramientas ayudan al analista a integrar los datos recopilados por los diversos métodos 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 decisión, tablas de decisión y español estructurado.

Conceptos básicos 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 decisión

Cuando se observa un sistema y se pregunta ¿cuáles son las posibilidades? O ¿qué puede suceder?, en realidad se esta 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 decisión.

Al documentar la decisión de cómo procesar un procedimiento, el investigador debe identificar tanto las condiciones permisibles como las relevantes que pueden presentarse en determinada situación. 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 tamaño de la hija de papel sobre la que esta impresa probablemente no lo sea.

Acciones

Cuando se conocen todas las posibles condiciones, el siguiente paso del analista es determinar que 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 decisión, tablas de decisión y el español estructurado.

Árboles de decisión

Las personas pueden tener diferentes formas de decir lo mismo. Tener diferentes formas e decir la misma cosa pueden crear dificultades de comunicación durante los estudios de sistemas. Por consiguiente, el analista busca evitar las malas interpretaciones. Asimismo, el analista necesita organizar la información recopilada con respecto a la toma de decisiones.

Características de los árboles de decisión

El árbol de decisión es un diagrama que representa en forma secuencial condiciones y acciones; muestra que condiciones se consideran en primer lugar, cuales en segundo y así sucesivamente. Este método también permite mostrar la relación que existe entre cada condición y el grupo de acciones permisibles asociado con ella.

La raíz del árbol es el punto donde comienza la secuencia de decisión. La rama a seguir depende de las condiciones existentes y de la decisión que debe tomarse. Al avanzar de izquierda a derecha por una rama en particular, se obtiene una serie de toma de decisiones. Después de cada punto de decisión, se encuentra el siguiente conjunto de decisiones a considerar. De esta forma, los nodos del árbol representan condiciones y señalan la necesidad de tomar una determinación 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 decisión

El desarrollo de árboles de decisión 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 difícil para ellos pasar por alto cualquier etapa del proceso de decisión, sin importar que este dependa de variables cualitativas o cuantitativas.

Los árboles de decisión también obligan a los analistas a considerar la secuencia de las decisiones.

Identificación de los requerimientos de datos

Los árboles de decisión también son útiles para identificar los requerimientos de datos críticos que rodean al proceso de decisión; 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 después de completar el análisis de flujo de datos, entonces es posible que los datos críticos se encuentren ya definidos en el diccionario de datos. Si únicamente se utilizan árboles de decisión, entonces el analista debe tener la certeza de identificar con precisión cada dato necesario para tomar la decisión.

Los analistas necesitan describir y definir todos los datos utilizados en la toma de decisiones para que sea posible diseñar el sistema de forma tal que los genere apropiadamente.

Como evitar los problemas que se generan al utilizar árboles de decisión

Los árboles de decisión no siempre son la mejor herramienta para el análisis de decisiones. El árbol de decisión de un sistema complejo con muchas secuencias de pasos y combinaciones de condiciones puede tener un tamaño considerable. El gran numero de ramas que pertenecen a varias trayectorias constituye mas un problema que una ayuda para el análisis. En estos casos el analista corre el riesgo de no determinar que políticas o estrategias de la empresa son la guía para la toma de decisiones especificas.

Tablas de decisión

La tabla de decisión es una matriz de renglones y columnas que indican condiciones y acciones. Las reglas de decisión, incluidas en una tabla de decisión, establecen el procedimiento a seguir cuando existen ciertas condiciones.

Características de las tablas de decisión

La taba de decisión esta integrada por cuatro secciones: identificación de condiciones, entradas de condiciones, identificación de acciones y entradas de acciones. La identificación de condiciones señala aquellas que son relevantes. Las entradas de condiciones indican que valor, si es que lo hay, se debe asociar para una determinada condición. La identificación de acciones enlista el conjunto de todos los pasos que se deben seguir cuando se presenta cierta condición. 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 añaden notas en la parte inferior de la tabla para indicar cuando utilizar la tabla o para diferenciarla de otras tablas de decisión.

Las columnas del lado derecho de la tabla enlazan condiciones y acciones, forman reglas de decisión que establecen condiciones que deben satisfacerse para emprender un determinado conjunto de acciones. La regla de decisión incorpora todas las condiciones que deben ser ciertas y no solo una a la vez.

Como construir tablas de decisión

Para desarrollar tablas de decisión, los analistas deben emprender los siguientes pasos:

1- Determinar los factores determinados como más relevantes en la toma de decisiones. Esto permite identificar las condiciones en la decisión. Cada condición seleccionada debe tener la característica de ocurrir o no ocurrir; en este caso no es posible la ocurrencia parcial.

2- Determinar los pasos o actividades más factibles bajo condiciones que cambian. Esto permite identificar las acciones.

3- Estudiar las diferentes posibilidades de combinaciones de condiciones. Para cualquier numero n de condiciones, existen 2a la n combinaciones a considerar.

4- Llenar la tabla con las reglas de decisión. Existen dos formas para hacerlo.

La primera, y más larga, es llenar los renglones de condición con valores si o no para cada combinación posible de condiciones. Esto es, llenar la primera mitad del renglón con Si y la segunda con No. El siguiente renglón se llena alternando con S y N cada 25% del renglón; es decir, 25% Si, 25% No, 25% Si y 25% No. Se repite de nuevo este proceso: se llena ada renglón faltante en forma alterna con S y con N, dividiendo cada vez por potencias sucesivas de 2.

El otro método para llenar la tabla considera una condición a la vez y, por cada condición adicional le añade una tabla pero sin considerar las combinaciones de condiciones y acciones duplicadas.

Verificación de tablas de decisión

Después 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 decisión que las relacionan con las acciones. Asimismo, los analistas también deben examinar la tabla para encontrar redundancias y contradicciones.

Eliminación de la redundancia: Las tablas de decisión pueden volverse muy grandes y difíciles de manejar si se permite que crezcan sin ningún control. Remover las entradas redundantes puede ser de ayuda para manejar el tamaño de la tabla. La redundancia se presenta cuando las siguientes condiciones son verdaderas al mismo tiempo: 1) dos reglas de decisión son idénticas salvo para una condición del renglón y 2) las acciones para las dos reglas son idénticas.

Supresión de contradicciones: las reglas de decisión son contradictorias entre si cuando dos o más reglas tienen el mismo conjunto de contradicciones pero sus acciones son diferentes.

Las contradicciones indican que la información que tiene el analista es incorrecta o bien existe un error en la construcción de la tabla. Sin embargo, muchas veces la contradicción es resultado de las dependencias en la información que recibe el analista de diferentes personas con respecto a la forma en que estas toman decisiones. Se puede tomar una decisión especifica utilizando diferentes reglas. Encontrar tales discrepancias puede ser de gran utilidad para el analista que trabaja con la finalidad de mejorar una situación de decisión.

Tipos de entradas en una tabla

Forma de entrada limitada: La estructura básica de la tabla consistentes en S y N y entradas en blanco, es la forma de entrada limitada. Este es uno de los formatos mas comunes. Existen otros dos que también se emplean de manera amplia.

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 condición y acción no están completos y es la razón por la que las entradas contienen mas detalles que una S y N.

Forma de entrada mixta: En ocasiones los analistas prefieren combinar en la misma tabla las características de los dos métodos anteriores. En general, debe utilizarse solo una forma en cada sección 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 decisión que tiene como finalidad omitir la repetición por medio de reglas ELSE . Para construir una tabla de decisión en la forma ELSE, se especifican las reglas, junto con las entradas de condiciones, que cubren todo el conjunto de acciones con excepción de una que se convierte en la regla a seguir cando ninguna de las demás 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 valida, entonces se sigue la regla de decisión ELSE. Esta regla elimina la necesidad de repetir condiciones que conducen a las mismas acciones.

Tablas múltiples

La forma ELSE es una alternativa para controlar el tamaño de las tablas de decisión. Otra manera de hacer esto es enlazando varias tablas de decisión. De acuerdo con las acciones seleccionadas en la primera tabla, otras se explican en una o más tablas adicionales; cada tabla proporciona mayores detalles relacionados con las acciones a emprender. Por otra parte, las tablas múltiples permiten al analista establecer las acciones repetitivas que deben realizarse después de tomar las decisiones y que continúan hasta que se alcanza determinada condición.

Para utilizar este método los analistas construyen, por separado, tablas de decisión que satisfacen todos los requerimientos normales y que están relacionadas con una decisión especifica. Las tablas de enlazan en forma jerárquica: 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 proposición “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 proposición “PERFORM tabla 2”. Al final de la tabla 2 la proposición RETURN regresa de nuevo el control a la proposición que sigue al GO TO en la tabla 1.

Procesadores de tablas de decisión

Las tablas de decisión han sido parcialmente automatizadas. Los procesadores de tablas de decisión son programas para computadora que manejan la formulación actual de una tabla con base en la información de entrada proporcionada por el analista. Estos procesadores también emprenden todas las verificaciones necesarias para detectar inconsistencias y redundancias.

La utilidad de los procesadores de tablas de decisión radica en el ahorro de tiempo de programación y detección de errores.

Español estructurado

El español estructurado es otro método para evitar los problemas de ambigüedad del lenguaje al establecer condiciones y acciones, tanto en procedimientos como en decisiones. Este método no hace uso de árboles o tablas; en su lugar utiliza declaraciones para describir el proceso. El proceso no muestra reglas de decisión; las declara.

Aun con esta característica, las especificaciones en español 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 método también permite hacer una lista de todos los pasos en el orden que se llevan a cabo. Para ello no se utilizan símbolos y formatos especiales, características de los árboles y las tablas de decisión que par algunos resultan incómodos. Además, es posible describir con rapidez los procedimientos en su totalidad ya que para ello de emplean declaraciones muy similares al español.

La terminología utilizada en la descripción estructurada de una aplicación consiste, en gran medida, en nombres de datos para los elementos que están definidos en el diccionario de datos desarrollado para el proyecto.

Desarrollo de declaraciones estructuradas

El español estructurado emplea tres tipos básicos de declaraciones para describir un proceso: estructuras de secuencia, estructuras de decisión y estructuras de iteración.

Estructuras de secuencia: Una estructura de secuencia es un solo paso o acción incluido en un proceso. Este no depende de la existencia de ninguna condición y, cuando se encuentra, siempre se lleva a cabo. En general, se emplean varias instrucciones en secuencia para describir un proceso.

Estructuras de decisión: El español estructurado es otro camino para mostrar el análisis de decisión. Por tanto, a menudo se incluyen las secuencias de acciones dentro de estructuras de decisión que sirven para identificar condiciones. Es así como las estructuras de decisión aparecen cuando se pueden emprender dos o más acciones, lo que depende del valor de una condición especifica. Para esto primero se evalúa la condición y después se toma la decisión de emprender las acciones o el grupo de acciones asociados con esta condición. Una vez determinada la condición las acciones son incondicionales.

Estructuras de iteración: En las actividades rutinarias de operación, es común encontrar que algunas de ellas se repiten mientras existen ciertas condiciones o hasta que estas se presentan. Las instrucciones de iteración permiten al analista describir estos casos.

Beneficios del español estructurado

Como puede observarse, el español 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 español estructurado para declarar las reglas de decisión que se aplican en este medio. Si los analistas no pueden declarar que acción emprender cuando se toma una decisión, entonces necesitan adquirir mayor información para descubrir la situación. Por otro lado, después de describir las actividades en forma estructurada, los analistas pueden pedir a otras personas que revisen la descripción y determinen con rapidez los errores u omisiones cometidos al establecer los procesos de decisión.

ANÁLISIS ESTRUCTURADO

Cuando los analistas comienzan a trabajar sobre un proyecto de sistemas de información, a profundo tienden a profundizar en un área de la organización 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 organización como resultado del crecimiento, del aumento de la competencia en el mercado, de los cambios en las necesidades de los consumidores, de la evolución de las estructuras financieras, de la introducción de la nueva tecnología y cambios en las políticas del gobierno entre otros.
- Documentar detalles del sistema actual para su revisión y discusión 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, señalando su justificación. Si es apropiado, quizá la propuesta de un nuevo sistema completo.
- Documentar las características 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 participación 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 común de preguntas por contestar cuando las emprenden.

El análisis estructurado es un método para el análisis 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 situación poco familiar, siempre existe una pregunta sobre donde comenzar el análisis. Una situación dinámica siempre puede ser vista como abrumadora debido a que muchas de las actividades se llevan a cabo constantemente. El análisis estructurado permite al analista conocer un sistema o proceso en forma lógica y manejable al mismo tiempo que proporciona la base para asegurar que no se omite ningún detalle pertinente.

¿Qué es lo que se desea estructurar? ¿Qué significa “estructura”? El objetivo que persigue el análisis estructurado es organizar las tareas asociadas con la determinación de requerimientos para obtener comprensión completa y exacta de una situación dada.

En el análisis estructurado, la palabra estructura significa que: 1) el método intenta estructurar el proceso de determinación de los requerimientos comenzando con la documentación del sistema existente; 2) el proceso esta organizado de tal forma que intenta incluir todos los detalles relevantes que describen el sistema en uso; 3) es fácil verificar cuando se han omitido detalles relevantes; 4) la identificación 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 documentación eficiente.

Componentes del análisis estructurado

El análisis estructurado hace uso de los siguientes componentes:

1- Símbolos gráficos: 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 técnicas y lenguajes que permiten a los analistas describir actividades importantes que forman parte del sistema.

4- Reglas: estándares para describir y documentar el sistema en forma correcta y completa.

Los analistas desean conocer las respuestas a cuatro preguntas especificas: ¿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 guía de actividades de la empresa. Ellos pueden iniciar eventos y ser procesados para dar información ú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 como se alcanzan los objetivos de la organización. El análisis 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 relación 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.

CARACTERÍSTICAS DE LAS ESTRATEGIAS DE FLUJO DE DATOS

El análisis de flujo de datos analiza el empleo de los datos para llevar acabo procesos específicos de la empresa dentro del ámbito de una investigación de sistemas. El análisis 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

La estrategia de flujo de datos muestra el empleo de estos en forma grafica. Las herramientas utilizadas al seguir esta estrategia muestran todas las características esenciales del sistema y la forma en que se ajustan entre si.

El análisis 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 través 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 mas importante y la base sobre la cual se desarrollan otros componentes. La transformación de datos de entrada en salida por medio de procesos puede describirse en forma lógica e independiente de los componentes físicos asociados con el sistema. Estos diagramas reciben el nombre de diagramas lógicos de flujos de datos.

2- Diccionario de datos: el diccionario contiene las características lógicas de los sitios donde se almacenan los datos del sistema, incluyendo nombre, descripción, alias, contenido y organización. también identifica los procesos donde se emplean los datos y los sitios donde se necesita el acceso inmediato a la información.

3- Diagrama de estructura de datos: es una descripción de la relación entre las entidades de un sistema y el conjunto de información relacionado con la entidad. No considera el almacenamiento físico de los datos.

4- Grafica de estructura: herramienta de diseño que muestra con símbolos la relación entre los módulos de procesamiento y el software de la computadora. Describen la jerarquía de los módulos componentes y los datos que serán transmitidos entre ellos. Incluye el análisis de las transformaciones entrada-salida y el análisis de transacciones.

Ventajas del análisis de flujo de datos

El análisis de flujo de datos permite a los analistas aislar áreas de interés en la organización y estudiarlas al examinar los datos que están en el proceso, de tal manera que puedan observar la manera en que cambian cuando lo abandonan. A medida que los analistas reúnen hechos y detalles, comprenden mejor el proceso; esto los conduce a formular preguntas relacionadas con aspectos específicos del mismo y los lleva a una investigación adicional.

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS

Para que sean de utilidad y proporcionen información, los diagramas de flujo de datos deben dibujarse de forma adecuada.

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 terminología del análisis estructurado, este es el estudio del sistema físico. El sistema físico se transada en una descripción lógica que se centra en datos y procesos.

Durante el análisis de flujo de datos se evalúan todos los detalles en términos de los componentes lógicos de flujos de datos, procesos, almacenes de datos, orígenes y destinos.

En todas las etapas de diseño que siguen, los requerimientos del sistema se trasladan en detalles de diseño lógico. En las fases de construcción, como la programación del software para computadora, las especificaciones lógicas son trasladadas en características físicas y en un sistemas de información que trabaja.

Diagramas físicos de flujo de datos

Los diagramas de flujo de datos son de dos tipos:

Diagramas físicos de flujo de datos: proporcionan un panorama del sistema en uso, que es dependiente de la implantación, que muestra que tareas se llevan a cabo y como. Las características físicas incluyen:

- Nombre de personas
- Nombres o números de formatos y documentos
- Nombres de departamentos
- Archivos maestros de transacciones
- Equipo y dispositivos utilizados
- Ubicaciones
- Nombres de procedimientos

Diagramas lógicos de flujos de datos: proporcionan un panorama del sistema independiente de la implantación, que se centra en el flujo de datos entre los procesos sin considerar los dispositivos específicos y la localización de almacenes de datos o personas en el sistema. En este tipo de diagramas no se indican las características físicas.

Reglas generales para el dibujo de diagramas lógicos de flujo de datos

1- Cualquier 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.

3- Solo deben entrar al proceso los datos necesarios para llevarlo a cabo.

4- Un proceso no debe ser nada de ningún otro sistema, es decir, debe ser independiente; la única dependencia que debe existir es aquella que esta basada en sus propios datos de entrada y salida.

5- Los procesos siempre están en continua ejecución; no se indican ni tampoco de detienen. Los analistas deben suponer que un proceso siempre esta listo para funcionar o realizar e trabajo necesario.

6- La salida de los procesos puede tomar las siguientes formas:

a- Flujo de datos con información añadida por el proceso.

b- Una respuesta o cambio en la forma de los datos.

c- Un cambio de decisión.

d- Un cambio de contenido.

e- Cambios en la organización.

Seguir convenciones de nivelación significativa

Nivelación es un termino 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 esta ocurriendo. Todos los flujos de datos deben tener un nombre que refleje con exactitud su contenido.

Asignación de nombre al flujo de datos: los nombres dados a los flujos de datos deben reflejar los datos de interés 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.

Asignación de nombre a los procesos: se deben asignar nombres a todos los procesos que les digan a los usuarios algo especifico 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 análisis y diseño:

1- Seleccionar nombres que indiquen la acción que se lleva a cabo.

2- Asegurar que el nombre describa completamente al proceso.

3- 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 mas específicos 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.

Evaluación del flujo de datos para verificar que es correcto

Las siguientes preguntas son de utilidad para evaluar los diagramas de flujo de datos:

1- ¿Existen 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?

7- ¿Es el flujo de datos que llega a un proceso adecuado para realizarlo?

8- ¿Existen demasiados datos en el almacén 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 descripción del sistema? ¿Aparecen en el diccionario de datos?

11- ¿Los procesos son independientes entre sí? ¿Dependen solo de los datos que reciben como entrada?

CARACTERÍSTICAS DE LOS DICCIONARIOS DE DATOS

Los diccionarios de datos son un componente importante del análisis estructurado ya que por si solos los diagramas de flujo de datos no describen el objeto de la investigación. El diccionario de datos proporciona mas información 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 están estructurados para satisfacer los requerimientos de los usuarios y las necesidades de la organización. Los elementos mas 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 común para todos los elementos del sistema
Para documentar las características del sistema
Para facilitar el análisis de los detalles con la finalidad de evaluar las características 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 información dependen de loas datos. El diccionario contiene dos tipos de descripciones para flujo de datos dentro del sistema:

Elementos dato: son los bloques básicos para todos los demás datos del sistema. Por si mismo no conllevan suficiente significado para ningún usuario.

Estructuras de datos: es un grupo de datos elementales que están relacionados con otros y que en conjunto describen un componente del sistema.

Descripción 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 esta identificado con un nombre, descripción, alias y longitud, junto con el intervalo de valores específicos 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.

Descripción de los datos: La descripción de un dato describe de manera breve lo que este representa en el sistema.

Las descripciones de los datos deben escribirse con la suposición de que la persona que las leerá no sabe nada con respecto al sistema.

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 numero de espacios necesarios para cada dato pero sin considerar la forma en que serán almacenados.

Valores de los datos: En algunos procesos solo son permitidos valores muy específicos para los datos. Todos los detalles serán de utilidad a los analistas mas adelante, cuando diseñen los controles del sistema.

Descripción de las estructuras de datos

Las estructuras de datos se construyen sobre cuatro relaciones de componentes:

- Relación secuencial: define los componentes que siempre se incluyen en una estructura de datos en particular; concatenación de dos o más datos.
- Relación de selección: define alternativa para datos o estructuras de datos incluidas en una estructura de datos.
- Relación de iteración: define la repetición de un componente cero o más veces.
- Relación opcional: caso especial de la iteración; los datos pueden estar o no incluidos, esto es, una o ninguna iteración.

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 también se explora la naturaleza de las aplicaciones que son buenos candidatos para desarrollo con el método del prototipo.

Usos de los prototipos de aplicaciones

El desarrollo de prototipos de aplicación 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 vehículos para describir las características y requerimientos que debe satisfacer la aplicación.

El segundo uso del prototipo de aplicación es verificar la factibilidad del diseño de un sistema. Los analistas pueden experimentar con diferentes características de la aplicación y evaluar la reacción y respuesta por parte del usuario.

Razones para el empleo de prototipos

Las razones para el uso de prototipos son el resultado directo de la necesidad de diseñar y desarrollar sistemas de información con rapidez, eficiencia y eficacia.

Aumento de la productividad

La productividad es importante para los analistas de sistemas y para la organización en la que trabajan. Los analistas de sistemas son más productivos si toman precauciones que:

- Minimicen el tiempo que se pierde debido al desarrollo incorrecto.
- Minimicen los errores del diseño.
- Garanticen que los esfuerzos realizados por ellos sean fructíferos.
- Garanticen que los usuarios reciban la aplicación que necesitan.
- Garanticen que no tendrá que volverse a hacer el trabajo de desarrollo.

Al mismo tiempo, los analistas se enfrentan a muchos obstáculos para alcanzar sus objetivos de desarrollo. A continuación se mencionan varios hechos que deben considerarse:

- Los usuarios tienen gran dificultad para especificar con anticipación sus necesidades de información, en especial cuando la situación es nueva o cambia con rapidez.
- La especificación completa de los requerimientos de información depende en particular de la forma en que debe utilizarse la tecnología.
- A menudo las descripciones estáticas de sistemas no son suficientes para proporcionar detalles sobre situaciones dinámicas.
- La mala comunicación, que siempre es una posibilidad, parece que siempre se presenta en el momento menos oportuno.

Aplicaciones para candidatos

Los prototipos son más eficaces en el desarrollo de sistemas de información cuando se cumples ciertas condiciones- Cualquiera de las siguientes cinco condiciones sugieren la necesidad de utilizar un prototipo.

- No se conocen los requerimientos: La naturaleza de la aplicación es tal que existe poca información disponible con respecto a las características que debe tener l sistema para satisfacer los requerimientos el usuario.
- Los requerimientos necesitan evaluarse: Se conocen los requerimientos aparentes de información, tanto de los usuarios finales como de la organización, pero es necesario verificarlos y evaluarlos.
- Costos altos: La inversión de recursos financieros y humanos así como el tiempo necesario para generar la aplicación es sustancial. Existen otros proyectos que también compiten por los mismos recursos.
- Alto riesgo: La evaluación inexacta de los requerimientos del sistema o el desarrollo incorrecto de una aplicación ponen en peligro a la organización, a sus empleados y también a sus propios recursos.
- Nueva tecnología: El deseo de instalar nueva tecnología ya sea con los campos de la computación, de las comunicaciones de datos u otras áreas relacionadas, abre nuevas fronteras para la organización. Muchas compañías no tienen experiencia en el uso de cierta tecnología ni tampoco las demás organizaciones con las que se comunican.

ETAPAS DEL MÉTODO DE PROTOTIPOS

Identificación de requerimientos conocidos

La determinación de los requerimientos de una aplicación es tan importante para el método de desarrollo de prototipos como lo es para los métodos del ciclo clásico de desarrollo de sistemas o análisis 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 construcción de un prototipo es un proceso iterativo de desarrollo. Antes de la primera iteración, los analistas de sistemas explican el método a los usuarios, las actividades a realizar, la secuencia en la que se llevaran a cabo y también discuten las responsabilidades de cada participante. Un cronograma para el inicio y fin de la primera iteración 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 conversación entre el usuario y el sistema.
- Pantallas y formatos para la entrada de datos.
- Módulos esenciales de procesamiento.
- Salida del sistema.

USO DE PROTOTIPOS

Cuando el prototipo esta terminado, el siguiente paso es tomar la decisión sobre como proceder. Existen cuatro caminos a seguir después de evaluar la información obtenida con el desarrollo y uso del prototipo:

Abandono de la aplicación

En algunos casos, la decisión es descartar el prototipo y abandonar el desarrollo de la aplicación. Esta conclusión no significa que fuese un error emprender el proceso de desarrollo del prototipo o un desperdicio de recursos. Mas bien, la información y experiencia ganada con el desarrollo y empleo del prototipo condujo hacia una decisión de desarrollo. Es probable que los usuarios y analistas hayan aprendido que el sistema era innecesario o hayan descubierto otra solución durante el proceso.

Implantación del prototipo

Algunas veces el prototipo se convierte en el sistema que se necesita. En este caso, se implanta sin ninguna modificación y no se emprenden mas esfuerzos de desarrollo. Esta decisión es más probable tomarse bajo una o más de las siguientes circunstancias:

- La evolución de prototipo condujo a una aplicación que tiene las características, capacidades y desempeño requeridos.
- La aplicación será utilizada con poca frecuencia y no es importante su rapidez o eficiencia operacional.
- La aplicación no tiene efecto sobre otras aplicaciones o datos de la organización y tampoco interacciona con ellos; además satisface las necesidades de os usuarios inmediatos.
- El medio ambiente de la aplicación se encuentra en un estado de flujo; es difícil determinar necesidades a largo plazo o condiciones de operación mas estables. En consecuencia no es posible justificar otras actividades de desarrollo. El prototipo es de utilidad para las condiciones actuales.

Desarrollo de la aplicación

Cuando un prototipo tiene éxito puede proporcionar información muy amplia con respecto a los requerimientos de la aplicación y conducir a su completo desarrollo. Terminar el prototipo n significa finalizar el proceso de desarrollo. Mas bien señala el comienzo de la siguiente actividad: el desarrollo completo de la aplicación.

El desarrollo de una aplicación puede presentarse como parte del método de ciclo de vida de los sistemas de información. Las dos formas más comunes de incorporar la construcción de un prototipo para la aplicación son las siguientes:

- El prototipo se emplea como una opción para la determinación de requerimientos; las características del prototipo son consideradas como los requerimientos a satisfacer en subsecuentes actividades de desarrollo.
- El prototipo se utiliza como sustituto para el diseño e implantación de la aplicación, es decir, como un esqueleto a partir del que se construye el resto del sistema.

Inicio de un nuevo prototipo

Algunas veces la información ganada con el desarrollo y uso del prototipo, sugiere el empleo de un enfoque muy diferente para satisfacer las necesidades de la organización. En este caso es posible encontrar que las características de la aplicación con muy diferentes si el prototipo es inadecuado para demostrarlas y evaluarlas.

HERRAMIENTAS PARA EL DESARROLLO DE PROTOTIPOS

Lenguajes de cuarta generación

Los lenguajes de cuarta generación fueron creados para ayudar a satisfacer la necesidad de desarrollar un software con mayor eficiencia. Los lenguajes de cuarta generación incluyen un amplio espectro de lenguajes de computadora que hacen hincapié sobre lo que debe hacerse mas que sobre como realizar la tarea.

Los lenguajes de cuarta generación se clasifican en tres categorías:

Lenguajes no orientados hacia procedimientos: El lenguaje con el que trabajan los analistas y usuarios finales no esta orientado hacia procedimientos. Algunas veces el lenguaje recibe l nombre de lenguajes no-procedurales. Un solo mandato lleva a cabo una función completa. No es raro encontrar que el mandato de un lenguaje no orientado hacia procedimientos remplace al equivalente de mas de cien instrucciones de un lenguaje de tercera generación.

Lenguajes de consulta y recuperación: Estos lenguajes facilitan la recuperación 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

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 comparación con los lenguajes de consulta y recuperación, 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 automática por software, o el usuario también puede proporcionar las especificaciones que instruyan al sistema para preparar títulos específicos, descripciones de pagina y encabezados de columnas.

Generadores de aplicaciones

Los generadores de aplicaciones son programas de software que permiten la especificación de toda una aplicación de un nivel muy alto. Ellos proporcionan las condiciones para desarrollar aplicaciones que acepten datos, efectúen cálculos, sigan complicadas rutinas de procesamiento lógico y produzcan reportes y salidas. El generador de aplicaciones produce el código fuente. Algunos producen programas completos. Otros, denominados generadores de programas, reparan el código del programa, como módulos individuales, y permiten al usuario enlazar otros módulos con los producidos por el generador.

Generadores de pantalla

Un generador de pantalla es una herramienta interactiva para dibujar pantallas y efectuar la validación automática de la entrada y procesamiento. Es posible seleccionar con respuestas sencillas preferencias sobre el presentar con mayor brillantez la información más importante, el utilizar determinados colores o hacer uso del video inverso.

Los generadores de pantalla también permiten que los usuarios preparen automáticamente componentes que sean de ayuda en la interacción usuario-maquina, incluyendo la localización 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 análisis 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 más productivo; se pueden completar las mismas actividades de desarrollo en un tiempo menor que el que se necesita usando no se utilizan las herramientas.

Las herramientas sugieren procedimientos que conducen al empleo de procesos más 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 también ocurre lo mismo con los resultados.

Beneficios de las herramientas asistidas por la computadora

La introducción de herramientas asistidas por la computadora en los esfuerzos de análisis y desarrollo aumentan los beneficios que se derivan del uso de las herramientas. Las herramientas del análisis asistido por la computadora mejoran la velocidad y disminuyen el tiempo necesario para completar la tarea de desarrollo.

La automatización también 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 más consistente. Se convierten en rutinas. La consistencia que pueden ofrecer los procedimientos es una excelente razón 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 recuperación de los detalles de un sistema. Una vez en forma procesable por la computadora, los detalles del sistema pueden utilizarse para muchas finalidades.

CLASIFICACIÓN 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 técnicas de soporte para ayudar al analista a preparar especificaciones formales que carezcan de ambigüedades, a validar las descripciones del sistema con el objeto de determinar su consistencia y completez, y a seguir la evolución de los requerimientos de la aplicación en características 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 lógica del programa, los algoritmos de procesamiento y la descripción física de los datos, también ayudan a la interacción con los dispositivos, etc. Estas actividades convierten los diseños lógicos del software en un código de programación que es el que finalmente da existencia a la aplicación.

Herramientas integrales

Las actividades de análisis 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 serán satisfechos estos requerimientos por medio de detalles que son específicos de la computadora.

HERRAMIENTAS ASISTIDAS POR COMPUTADORA PARA LE INGENIERÍA DE SISTEMAS (CASE)

Las herramientas de tipo CASE incluyen los siguientes cinco componentes:

Herramientas para diagramación: Estas herramientas dan soporte al análisis y documentación de los requerimientos de una aplicación. Por lo general, incluyen facilidades para producir diagramas de flujo de datos.

Las herramientas ofrecen la capacidad de dibujar diagramas y cartas, además de guardar los detalles en forma interna.

Deposito centralizado de información: La captura, análisis, procesamiento y distribución de todos los sistemas de información es asistida por un deposito de información centralizado o diccionario de datos.

Aunque los diccionarios son diseñados para que el acceso a la información sea sencillo, también incluyen controles y medidas de protección 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 rápida creación de menús de demostración para el sistema, de pantallas de presentación y del formato de los informes.

Generadores de código: Los generadores de código automatizan la preparación del software. Estos incorporan métodos que permiten convertir las especificaciones del sistema en código ejecutable.

Herramientas de administración: Algunas herramientas CASE para administración permiten que los gerentes de proyecto especifiquen elementos de su propia elección.

Otras permiten definir metodologías de desarrollo propias, incluyendo las reglas de validación y los estándares para datos nombres de procedimientos.

Integración de la herramientas CASE

La integración de la herramientas ocurre en tres formas:

Interfase uniforme: Significa que todas las herramientas en el sistema CASE son activadas de la misma manera y desde un lugar común 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 critico que hace posible la transferencia de datos entre herramientas distintas.

Unir de las actividades de desarrollo: La facilidad para transferir datos y la unión de las fases de desarrollo se encuentran relacionadas, ya que se pueden utilizar una y otra vez los datos transferidos entre herramientas a través de todo el proceso de desarrollo.

USO DE UNA HERRAMIENTA CASE

Operaciones iniciales

Los sistemas CASE almacenan información por proyecto. Cada aplicación de sistemas de información es considerada como un proyecto.

Antes de iniciar el trabajo, el analista debe proporcionar su nombre y contraseña. 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 mas importantes d Excelerator: graficas, XLDicionario, pantallas y reportes, documentación, análisis, interfaces y utilerías.

Dibujo de diagramas de flujo de datos

Cuando se selecciona la función 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 documentación, toda la información con respecto al proyecto se acumula en el diccionario de datos que Excelerator mantiene para dicho proyecto. Parte de la información, 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 método rápido y sencillo para desarrollar prototipos de pantallas para que los usuarios finales trabajen con ellas. El analista puede diseñar y ejecutar pantallas y reportes con el apoyo de un menú, e incluso desarrollar el prototipo de una base de datos.

Herramientas para el análisis y documentación

Excelerator ofrece características tales como un conjunto de reportes que validan las descripciones del sistema. Los reportes del análisis 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. también es posible detectar y notificar diagramas no balanceados.

Utilerías

La información utilizada por el sistema Excelerator se encuentra descrita por las funciones de utilería. Existe también una función especial para el manejo de proyectos que los analistas emplean para dar nombre al proyecto, proporcionar descripciones del mismo y definir la notación que utilizaran para los diagramas de flujo de datos.

Beneficios de CASE

Entre los beneficios ofrecidos por la tecnología CASE se encuentran los siguientes:

- Facilidad para llevar a cabo la tarea de revisión 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 desempeño del sistema tendrán otras alternativas.
- Generación de código.
- Soporte para mantenimiento como resultado de haber guardado las especificaciones del sistema en un deposito central de información.
- Aumentar las posibilidades de satisfacer los requerimientos del usuario.

Debilidades de CASE

Entre las debilidades de CASE se encuentran las siguientes:

- Muchas herramientas CASE están construidas teniendo como base las metodologías del análisis estructurado y del ciclo de vida de desarrollo de sistemas. Por si sola, esta característica puede convertirse en la principal limitante ya que no todas las organizaciones emplean métodos de análisis estructurado.
- Falta de niveles estándar para el soporte de tecnología.
- 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 metodologías de desarrollo, por lo general su enfoque primario esta dirigido hacia una fase o método 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 ningún análisis de los requerimientos de la aplicación.
- Las tareas humanas siguen siendo criticas. Las herramientas deben adaptarse a la arquitectura de la información así como a las metodologías de desarrollo utilizadas por la organización.