CAPITULO 10: PREPARACIÓN DE LA PROPUESTA DE SISTEMA

Cuando se realiza el inventario del equipo disponible de cómputo, los analistas de sistemas podrán determinar mejor si será recomendado el hardware de cómputo nuevo, modificado o actual.

El hardware de cómputo se puede adquirir a través de la compra, arrendamiento financiero o alquiler. Los vendedores proporcionarán servicios de apoyo tales como el mantenimiento preventivo y capacitación de usuario que normalmente se negocian por separado. El software se puede crear como un producto personalizado, comprar como un paquete de software comercial (COTS) o subcontratar a un proveedor de servicios de aplicaciones (ASP).

Con frecuencia se exige a analistas de sistemas desarrollar o evaluar paquetes de software de nivel superior usado por los sistemas de apoyo a la toma de decisiones. El analista puede ayudar a obtener la información necesaria para identificar los objetivos, alternativas, criterios, atributos y prioridades o pesos necesarios para la toma de decisiones criterios múltiples.

COMO DETERMINAR NECESIDADES DE HADWARE Y SOFTWARE

Después de analizar el software y hardware el analista de sistemas necesita trabajar con los usuarios para determinar qué hardware se necesitará. Las determinaciones del hardware sólo se pueden realizar de manera conjunta con la determinación de los requerimientos de información. El conocimiento de la estructura organizacional (como se explicó en el capítulo 2] también puede ser útil para tomar decisiones relativas al hardware. Las opciones de hardware sólo se pueden considerar cuando los analistas de sistemas, los usuarios y los directivos saben bien cuál es el tipo de tareas que se deben realizar.

CÓMO INVENTARIAR EL HARDWARE DE CÓMPUTO

Como se puede observar, algunas de las opciones de hardware involucran la ampliación o el reciclaje del hardware actual, de modo que es importante saber con qué se cuenta. Si no está disponible un inventario actualizado del hardware de cómputo, el analista de sistemas tiene que preparar uno rápidamente y trabajar en él. Usted necesita saber lo siguiente:

1. El tipo de equipo: el número de modelo, el fabricante.

2. El estado de funcionamiento del equipo: en pedido, en funcionamiento, en almacén, con necesidad de reparación.

3. La edad estimada del equipo.

4. La vida proyectada del equipo.

5. La ubicación física del equipo.

6. El departamento o la persona responsable del equipo.

7. La situación financiera del equipo: propio, en arrendamiento financiero, alquilado.

CÁLCULO DE LAS CARGAS DE TRABAJO

Los analistas de sistemas establecen cifras que representan las cargas de trabajo actuales y proyectadas para el sistema con el fin de que cualquier hardware que se adquiera cuente con la capacidad para manejar las cargas de trabajo actuales y futuras.

Si las estimaciones se realizan adecuadamente, la empresa no debe reemplazar el hardware tan sólo por el crecimiento inesperado en el uso del sistema. (Sin embargo, otros eventos, como innovaciones tecnológicas superiores, pueden dictar el reemplazo del hardware si la empresa quiere mantener su ventaja competitiva.)

Aparte de la necesidad, las cargas de trabajo se muestrean en lugar de completarlas realmente en varios sistemas de cómputo.

EVALUACIÓN DEL HARDWARE DE CÓMPUTO

La evaluación del hardware de cómputo es una responsabilidad compartida de los directivos, usuarios y analistas de sistemas. Aunque los fabricantes proporcionarán detalles acerca de los productos que ofrezcan, los analistas necesitan supervisar personalmente el proceso de evaluación porque ellos se preocuparán por los mejores intereses del negocio. Además, tal vez los analistas de sistemas tengan que enseñar a los usuarios y a los directivos las ventajas y desventajas generales del hardware para que puedan evaluarlo de manera eficaz.

Con base en el inventario actual del equipo de cómputo y en las estimaciones adecuadas de las cargas de trabajo actuales y futuras, el siguiente paso en el proceso es considerar los tipos de equipo disponibles que parezcan satisfacer las necesidades proyectadas. La información que los fabricantes ofrezcan acerca de los posibles sistemas y las configuraciones de éstos será más apropiada en esta fase y debe revisarse de manera conjunta con los directivos y los usuarios.

ADQUISICIÓN DEL EQUIPO DE CÓMPUTO

Las tres opciones principales para la adquisición de hardware de cómputo son la compra, el arrendamiento financiero o el alquiler. Como se muestra en la figura 10.3, hay ventajas y desventajas que se deben analizar para cada una de las decisiones. Algunos de los factores que se deben tomar en cuenta al momento de determinar cuál opción es mejor para una instalación en particular incluyen los costos iniciales versus los costos a largo plazo,

EVALUACIÓN DEL SOFTWARE

Al evaluar el software para los proyectos de sistemas de información, los analistas y las organizaciones se enfrentan cada vez más con la disyuntiva de hacer, comprar o subcontratar, particularmente al contemplar las actualizaciones a los sistemas actuales o los heredados. Ya vio las decisiones que los analistas toman cuando tienen que elegir entre alquilar, comprar o arrendar el hardware. Algunas de las decisiones relacionadas con la compra de software comercial, "alquiler" de software de un proveedor de servicios de aplicaciones (ASP] o la creación de software personalizado para el proyecto son análogas a las del proceso de toma de decisiones relativas al hardware.


CUÁNDO CREAR SOFTWARE PERSONALIZADO

Hay varias situaciones que requieren la creación de software original o componentes de software. El caso más común es cuando no se encuentren

Las ventajas de crear su propio software incluyen la capacidad de responder a las necesidades especializadas del negocio, ganar una ventaja competitiva al crear software innovador, disponer de personal interno para dar mantenimiento al software y el orgullo de poseer algo que uno mismo ha creado.

Las desventajas de desarrollar su propio software están la posibilidad de un costo inicial significativamente más alto comparado con la compra de software comercial o con la contratación de un ASP, la necesidad de contratar o trabajar con un equipo de desarrollo y el hecho de que usted es responsable del mantenimiento continuo porque usted creó el software.

CAPITULO 9: DESCRIPCIÓN DE LAS ESPECIFICACIONS DE PROCESOS Y DECISIONES ESTRUCTURADAS.

En primer lugar el analista identifica los flujos de datos y empieza a construir un diccionario de datos, para posteriormente pasar a la especificación de procesos y el análisis de decisión.

Los tres métodos para el análisis de decisión y para describir la lógica del proceso son español estructurado, tablas de decisión y árboles de decisión.

Las especificaciones de procesos (o miniespecificaciones) se crean para procesos primitivos de un diagrama de flujo de datos así como también para algunos procesos de alto nivel que se amplían a un diagrama hijo.

Una forma de describir decisiones estructuradas es usar el método llamado Español estructurado, en el cual la lógica se expresa en estructuras secuenciales, estructuras de decisión, estructuras de caso o iteraciones. El Español estructurado usa palabras clave aceptadas tales como IF, THEN, ELSE, DO, DO WHILE y DO UNTIL para describir la lógica usada y se vale de sangrías para indicar la estructura jerárquica del proceso de decisión.

Las tablas de decisión proporcionan otra forma de examinar, describir y documentar decisiones. Cuatro cuadrantes (en el sentido de las manecillas del reloj, empezando desde la esquina superior izquierda) se usan para:

(1) describir las condiciones;

(2) identificar las posibles alternativas de decisión (como S o N);

(3) indicar qué acciones se deben realizar, y

(4) describir las acciones.

Las tablas de decisión son provechosas porque las reglas para desarrollar la propia tabla, así como las reglas para eliminar redundancia, contradicciones y situaciones imposibles, son directas y manejables.

El uso de tablas de decisión promueve la completitud y exactitud al analizar decisiones estructuradas.

El tercer método para el análisis de decisión es el árbol de decisión, que está integrado por nodos (un cuadrado para las acciones y un círculo para las condiciones) y ramas.

Los árboles de decisión son apropiados cuando las acciones se deben realizar en una cierta secuencia.

No hay necesidad de que el árbol sea simétrico, de modo que en una rama específica sólo se encuentran aquellas condiciones y acciones que son críticas para las decisiones.

Cada uno de los métodos de análisis de decisión tiene sus propias ventajas y se deben usar según sea el caso. El Español estructurado es útil cuando se repiten muchas acciones y cuando la comunicación con otros es importante.

Las tablas de decisión proporcionan un análisis completo de situaciones complejas y limitan la necesidad de cambios atribuibles a situaciones imposibles, redundancias o contradicciones. Los árboles de decisión son importantes cuando la secuencia apropiada de condiciones y acciones es crítica y cuando cada condición no es relevante para cada acción.


PANORAMA GENERAL DE LAS ESPECIFICACIONES DE PROCESOS

Para determinar los requerimientos de información de una estrategia de análisis de decisión, el analista de sistemas debe determinar primero los objetivos organizacionales mediante un enfoque de jerarquización de arriba hacia abajo.

El analista de sistemas debe entender los principios organizacionales y debe contar con experiencia en las técnicas de recopilación de datos.

Las especificaciones de procesos representan una parte pequeña de las especificaciones del proyecto total se crean para los procesos primitivos en un diagrama de flujo de datos así como también para algunos procesos de nivel superior que se amplían a un diagrama hijo. Estas especificaciones explican la lógica de la toma de decisiones y las fórmulas que transformarán los datos de entrada de un proceso en salidas. Cada elemento derivado debe tener lógica del proceso para mostrar cómo se origina de los elementos base u otros elementos derivados previamente creados que se alimentan del proceso primitivo.

Las tres metas para producir especificaciones de procesos son las siguientes:

1. Reducir la ambigüedad del proceso. Esta meta obliga al analista a aprender los detalles acerca del funcionamiento de un proceso. Es necesario detectar, anotar e integrar las áreas indefinidas de todas las especificaciones de procesos. Estas observaciones constituyen una base y proporcionan las preguntas para las entrevistas de seguimiento con la comunidad de usuarios.

2. Obtener una descripción precisa de lo que se está realizando, lo cual normalmente se incluye en un paquete de especificaciones para el programador.

3. Validar el diseño del sistema. Esta meta incluye garantizar que un proceso tenga todo el flujo de datos de entrada necesario para producir la salida. Además, todas las entradas y salidas deben representarse en el diagrama de flujo de datos


ESPAÑOL ESTRUCTURADO

Como su nombre implica, el español estructurado se basa en

[1] lógica estructurada o instrucciones organizadas en procedimientos anidados y agrupados, y

(2) enunciados simples del español tales como sumar, multiplicar y mover.

Un problema de expresión se puede transformar en Español estructurado, poniendo las reglas de decisión en su secuencia adecuada y usando en todo momento la convención de instrucciones IF-THEN-ELSE. Como se muestra en la figura 9.4, el español estructurado puede ser más complejo si se anidan bloques de instrucciones dentro de otros bloques de instrucciones.

CÓMO ESCRIBIR ESPAÑOL ESTRUCTURADO

Para escribir español estructurado, podría seguir las convenciones siguientes:

1. Exprese toda la lógica en uno de estos cuatro tipos: estructuras secuenciales, estructuras de decisión, estructuras de caso o iteraciones (véanse los ejemplos de la figura 9.5).

2. Use en mayúsculas las palabras clave aceptadas como IF, THEN, ELSE, DO, DO WHILE, DO UNTIL y PERFORM.

3. Ponga sangría en los bloques de enunciados para mostrar claramente su jerarquía (anidamiento).

4. Cuando las palabras o frases se han definido en un diccionario de datos (como en el capítulo

5. Tenga cuidado al usar "y" y "o", y evite la confusión al distinguir entre "mayor que" y
"mayor que o igual a"


DICCIONARIO DE DATOS Y ESPECIFICACIONES DE PROCESOS

Todos los programas de computadora se podrían codificar mediante tres estructuras básicas: secuencia, selección (IE..THEN... ELSE y la estructura de casos) e iteración o ciclos. El diccionario de datos indica cuál de estas estructuras se debe incluir en las especificaciones del proceso.

CAPITULO 8.- ANALISIS DE SISTEMAS MEDIANTE DICCIONARIO DE DATOS

NECESIDAD DE ENTENDER EL DICCIONARIO DE DATOS

Muchos de los sistemas de administración de base de datos están equipados con un diccionario de datos automatizado.
Los diccionarios de datos pueden ser complejos o sencillos, también pueden catalogarse automáticamente ciertos elementos, otros programas proporcionan solo una plantilla para implementar al sistema un diccionario de datos, para registrar o mantener de cirta manera un informe por cada entrada.

Entender el proceso de un diccionario de datos puede ayudar al analista de sistemas a visualizar el sistema y su funcionamiento. Además de proporcionar documentación y eliminar la redundancia, el diccionario de datos se podría usar para:

1. Validar la integridad y exactitud del diagrama de flujo de datos.

2. Proporcionar un punto de partida para desarrollar pantallas e informes.

3. Determinar el contenido de los datos almacenados en archivos.

4. Desarrollar la lógica para los procesos del diagrama de flujo de datos.

EL DEPOSITO DE DATOS

El depósito de datos es similar al diccionario de datos solo que de mayor extensión es uno de los muchos impactos de las herramientas CASE y podría contener (por mencionar algunos puntos) lo siguiente:

1. Información sobre los datos mantenidos por el sistema, incluyendo flujos de datos, almacenes de datos, estructuras de registros y elementos.

2. Lógica de procedimientos.

3. Diseño de pantallas e informes.

4. Relaciones entre datos, por ejemplo cómo se vincula una estructura de datos con otra.


DEFINICIÓN DE LOS FLUJOS DE DATOS

La mayoría de los casos los flujos de datos son los primeros elementos que se definen. Las entradas y salidas del sistema se determinan mediante las entrevistas y la observación de los usuarios, y el análisis de documentos y de otros sistemas existentes. La información capturada para cada flujo de datos se podría resumir usando un formulario que contenga por lo menos la siguiente información:

1. ID, un número de identificación opcional. A veces éste se codifica usando un esquema para identificar el sistema y la aplicación del sistema.

2. Un solo nombre descriptivo para este flujo de datos. Este nombre es el texto que debe aparecer en el diagrama.

3. Una descripción general del flujo de datos.

4. La fuente del flujo de datos. Ésta podría ser una entidad externa, un proceso o un flujo de datos proveniente de un almacén de datos.

5. El destino del flujo de datos (los mismos elementos que se describieron en la fuente).

DESCRIPCIÓN DE LAS ESTRUCTURAS DE DATOS

Este método permite al analista producir una vista de los elementos que constituyen la estructura de datos junto con información referente a dichos elementos. Por ejemplo, el analista indicará si hay muchos elementos iguales en la estructura de datos (un grupo de repetición), o si dos elementos podrían excluirse mutuamente.

La notación algebraica usa alguno de los siguientes símbolos:

1. Un signo de igual (-) significa "está compuesto de".

2. Un signo de suma (+) significa "y".

3. Las llaves {} indican elementos repetitivos, también llamados grupos de repetición o tablas.

4. Los corchetes [ ] representan una situación de uno u otro. Se podría representar un elemento u otro, pero no ambos.

ELEMENTOS DE DATOS

Cada elemento de datos se debe definir una vez en el diccionario de datos y también se podría introducir previamente en un formulario de descripción del elemento, como el que se ilustra en la figura 8.7. Las siguientes son las características que comúnmente se incluyen en el formulario de descripción del elemento:

1. ID del elemento. Esta entrada opcional permite al analista construir entradas de diccionario de datos automatizadas.

2. El nombre del elemento. El nombre debe ser descriptivo, único y basado en el propósito al cual está destinado el elemento en la mayoría de los programas o por el usuario principal del elemento.

ALMACENES BE DATOS

Los elementos base se deben almacenar en el sistema. También los elementos derivados se podrían almacenar en el sistema, tal como, para un empleado, el sueldo bruto acumulado a la fecha.

Mediante un enfoque jerárquico de arriba hacia abajo, el analista de sistemas usa los diagramas de flujo de datos para empezar a compilar un diccionario de datos, el cual es un trabajo de referencia que contiene datos acerca de datos, o metadatos, de todos los procesos de datos, almacenes, flujos, estructuras y elementos lógicos y físicos del sistema bajo estudio. Una forma de empezar es incluir todos los elementos de datos que contengan los diagramas de flujo de datos.

Una colección más grande de información del proyecto se llama depósito.
Las herramientas CASE permiten al analista crear un depósito que podría incluir información acerca de los flujos de datos, almacenes, estructuras de registro y elementos; de las pantallas de lógica de procedimientos y diseño de informes; de las relaciones de datos; de los requerimientos del proyecto y de las liberaciones del sistema final, y acerca de la información de administración del proyecto.
Cada entrada en el diccionario de datos contiene el nombre del elemento, una descripción en español, alias, elementos de datos relacionados, el rango, la longitud, codificación y la información de edición necesaria.

El diccionario de datos es útil en todas las fases del análisis, diseño y por último de la documentación, debido a que es la fuente autorizada de cómo se usan y definen los elementos de datos en el sistema. Muchos sistemas grandes tienen diccionarios de datos computarizados que incluyen referencias cruzadas de todos los programas contenidos en la base de datos que usan un elemento de datos en particular.

De cierta forma Podemos usar los diagramas de flujo de datos que elaboramos al crear las entradas de diccionario de datos para todos los flujos de datos y los almacenes de datos

Uso de diagrama de datos

ENFOQUE DEL FLUJO DE DATOS PARA DETERMINAR LOS REQUERIMIENTOS

El analista de sistemas puede elaborar una representación grafica de los procesos que se realizan con los datos en toda la organización, mediante una técnica de análisis estructurada llamada diagramas de flujo de datos (DFDs). Con el uso de tan sólo cuatro símbolos, el analista de sistemas puede crear una descripción gráfica de los procesos que, con el tiempo, contribuirán a desarrollar una sólida documentación del sistema.

VENTAJAS DEL ENFOQUE DEL FLUJO DE DATOS

El enfoque del flujo de datos posee cuatro ventajas principales sobre las explicaciones descriptivas en relación con la forma en que los datos se mueven a través del sistema:

1. Libertad para emprender la implementación técnica del sistema en las etapas tempranas.

2. Una comprensión más profunda de la interrelación entre sistemas y subsistemas.

3. Comunicar a los usuarios el conocimiento sobre el sistema actual mediante diagramas de flujo de datos.

4. Análisis de un sistema propuesto para determinar si se han definido los datos y procesos necesarios.

CONVENCIONES USADAS EN LOS DIAGRAMAS DE FLUJO DE DATOS

En los diagramas de flujo de datos se usan cuatro símbolos básicos para graficar el movimiento de los datos: un cuadrado doble, una flecha, un rectángulo con esquinas redondeadas y un rectángulo abierto (cerrado en el lado izquierdo y abierto en el derecho),
Con la combinación de estos cuatro símbolos se puede describir gráficamente un sistema completo y varios subsistemas.

Un rectángulo con esquinas redondeadas se usa para mostrar la presencia de un proceso de transformación. Los procesos siempre denotan un cambio en los datos o una transformación de éstos; por lo tanto, el flujo de datos que sale de un proceso siempre se designa de forma diferente al que entra en él. Los procesos representan trabajo que se realiza en el sistema y se deben nombrar usando uno de los formatos siguientes.

Un nombre claro permite reconocer fácilmente lo que hace un proceso.

1. A los procesos de alto nivel asígneles el nombre del sistema. Por ejemplo, SISTEMA DE CONTROL DE INVENTARIOS.

2. Para nombrar un subsistema principal, use un nombre como SUBSISTEMA DE INFORMACIÓN DE INVENTARIOS o SISTEMA DE CUMPLIMIENTO DE PEDIDOS DEL CLIENTE EN INTERNET

3. Para los procesos detallados use un formato de sustantivo-verbo-adjetivo. El sustantivo indica cuál es el resultado principal del proceso, tal como INFORME o REGISTRO. El verbo describe el tipo de actividad, tal como CALCULAR, VERIFICAR, PREPARAR,
IMPRIMIR o AGREGAR.

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS

Los diagramas de flujo de datos se pueden y deben dibujar de manera sistemática para desarrollar eficazmente diagramas de flujo de datos. Primero, el analista de sistemas necesita visualizar los flujos de datos desde una perspectiva jerárquica de arriba hacia abajo.

CREACIÓN DEL DIAGRAMA DE CONTEXTO

El diagrama de contexto es el nivel más alto en un diagrama de flujo de datos y contiene un solo proceso, que representa a todo el sistema. Al proceso se le asigna el número cero.
En el diagrama de contexto se muestran todas las entidades externas, así como también los flujos de datos principales que van desde y hacia dichas entidades.

DIBUJO DEL DIAGRAMA 0 (EL SIGUIENTE NIVEL)

El Diagrama 0 es la ampliación del diagrama de contexto y puede incluir hasta nueve procesos. Si se incluyen más procesos en este nivel se producirá un diagrama difícil de entender.
Por lo general, cada proceso se numera con un entero, empezando en la esquina superior izquierda del diagrama y terminando en la esquina inferior derecha. En el Diagrama 0 se incluyen los principales almacenes de datos del sistema (que representan a los archivos maestros) y todas las entidades externas. La figura 7.3 representa gráficamente el diagrama de contexto y el Diagrama 0.

Debido a que un diagrama de flujo de datos es bidimensional (en lugar de lineal), usted puede empezar en cualquier punto del diagrama e ir hacia adelante o hacia atrás. Si no está seguro de lo que podría incluir en cualquier punto, tome una entidad externa, un proceso o un almacén de datos diferente y empiece a dibujar el flujo a partir de él:

1. Empiece con el flujo de datos de una entidad en el lado de la entrada. Haga preguntas tales como: "¿Qué sucede con los datos que entran en el sistema?" "¿Se almacenan?" "¿Esta entrada es para varios procesos?"

2. Trabaje hacia atrás a partir de un flujo de datos de salida. Examine los campos de salida de un documento o pantalla.

3. Examine el flujo de datos desde o hacia un almacén de datos. Pregunte: "¿Qué procesos ponen los datos en el almacén?" o "¿Qué procesos usan los datos?" Observe que un almacén de datos utilizado en el sistema en el que esté usted trabajando podría ser producido por un sistema diferente.

4. Analize un proceso bien definido. Vea qué entrada de datos necesita el proceso y qué salida produce. Después vincule la entrada y la salida con los almacenes de datos y las entidades adecuadas.

5. Tome nota de cualquier área confusa en donde no esté seguro de lo que se debe incluir o de la entrada o la salida que se requiera. Al conocer las áreas problemáticas podrá realizar una lista de preguntas para las entrevistas de seguimiento con los usuarios clave.

CREACIÓN DE DIAGRAMAS HIJOS (NIVELES MÁS DETALLADOS)

El proceso del Diagrama 0 a partir del cual se realiza la ampliación se llama proceso padre, y el diagrama que se produce se llama diagrama hijo. La regla principal para crear diagramas hijos, el equilibrio vertical, estipula que un diagrama hijo no puede producir salida o no puede recibir entrada que el proceso padre no produzca o reciba también.

Los procesos se podrían ampliar o no ampliar, dependiendo de su nivel de complejidad. Cuando no se amplía un proceso, se dice que es funcionalmente primitivo y se llama proceso primitivo.

REVISIÓN DE ERRORES EN LOS DIAGRAMAS

Cuando se dibujan diagramas de flujo de datos se pueden cometer varios errores comunes como los siguientes:

1. Olvidar incluir un flujo de datos o apuntar con una flecha en la dirección incorrecta.
Un ejemplo es un proceso dibujado que muestra todos sus flujos de datos como entrada o salida. Cada proceso transforma datos y debe recibir una entrada y producir una salida.

2. Conectar directamente entre sí almacenes de datos y entidades externas. Los almacenes de datos y las entidades externas no se deben conectar entre sí; sólo se deben conectar con un proceso.

3. Asignar nombres incorrectos a los procesos o al flujo de datos. Revise el diagrama de flujo de datos para asegurar que cada objeto o flujo de datos tiene un nombre adecua-

4. Incluir más de nueve procesos en un diagrama de flujo de datos. La inclusión de demasiados procesos origina un diagrama confuso difícil de entender y obstaculiza la comunicación en lugar de facilitarla.

5. Omitir un flujo de datos. Examine su diagrama en busca de flujo lineal, es decir, flujo de datos en el cual cada proceso tiene sólo una entrada y una salida. El flujo de datos lineal no es muy común, excepto en los diagramas de flujo de datos hijos muy detallados.

6. Crear una separación (o ampliación) desequilibrada en los diagramas hijos. Cada diagrama hijo debe tener el mismo flujo de datos de entrada y salida que el proceso padre.


DIAGRAMAS DE FLUJO DE DATOS LÓGICOS Y FÍSICOS

Los diagramas de flujo de datos se catalogan como lógicos o físicos.

Un diagrama de flujo de datos lógico se enfoca en el negocio y en el funcionamiento de éste. No se ocupa de la manera en que se construirá el sistema. Más bien, describe los eventos que ocurren en el negocio y los datos requeridos y producidos por cada evento.

Un diagrama de flujo de datos físico muestra cómo se implementará el sistema, incluyendo el hardware, el software, los archivos y las personas involucradas en el sistema.

En teoría, los sistemas se desarrollan mediante el análisis del sistema actual (DFD lógico actual) y después se agregan características que el nuevo sistema debe incluir (DFD lógico propuesto). Por último, se deben desarrollar los mejores métodos para implementar el nuevo sistema (DFD físico).

El desarrollo de un diagrama de flujo de datos lógico para el sistema actual ofrece un entendimiento claro de su funcionamiento, y por lo tanto un buen punto de partida para desarrollar el modelo lógico del mismo. Con frecuencia este paso, que requiere una considerable cantidad de tiempo, se omite para ir directamente al DFD lógico propuesto.

Una ventaja de construir el diagrama de flujo de datos lógico del sistema actual es que se puede usar para crear el diagrama de flujo de datos lógico del nuevo sistema. Además, el uso del modelo lógico del sistema actual como base para el sistema propuesto ofrece una transición gradual para el diseño del nuevo sistema. Una vez desarrollado el modelo lógico

DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS LÓGICOS

Para desarrollar un diagrama de este tipo, primero construya un diagrama de flujo de datos para el sistema actual. Hay varias ventajas al usar un modelo lógico, entre ellas:

1. Mejor comunicación con los usuarios.

2. Sistemas más estables.

3. Mejor entendimiento del negocio por parte de los analistas.

4. Flexibilidad y mantenimiento.

5. Eliminación de redundancias y creación más sencilla del modelo físico.

Es más fácil usar un modelo lógico al comunicarse con los usuarios del sistema porque se centra en las actividades del negocio. En consecuencia, los usuarios estarán familiarizados con las actividades principales y con muchos de los requerimientos de información de cada actividad.


DESARROLLO DE DIAGRAMAS DE FLUJO DE DATOS FÍSICOS

Después de desarrollar el modelo lógico del nuevo sistema, usted lo podría usar para crear un diagrama de flujo de datos físico. El diagrama de flujo de datos físico muestra cómo se creará el sistema, y generalmente contiene la mayoría. Así como los diagramas de flujo de datos lógicos tienen ciertas ventajas, los diagramas de flujo de datos físicos tienen otras, entre ellas:

1. Aclarar qué procesos son manuales y cuáles son automatizados.

2. Describir los procesos con mayor detalle los DFDs lógicos.

3. Distribuir en un orden particular los procesos que se deben realizar.

4. Identificar los almacenes de datos temporales.

5. Especificar los nombres reales de archivos y documentos impresos.

6. Agregar controles para asegurar que los procesos se realicen adecuadamente.

Modelación de eventos y diagramas de flujo de datos Los eventos propician que el sistema realice alguna actividad y actúan como detonadores del sistema. Un ejemplo de evento es el de un cliente que reserva un vuelo en la Web. Cada vez que se envía un formulario Web, se activan procesos, como validar y almacenar los datos, y dar formato y desplegar la siguiente página. Por lo general, los eventos se sintetizan en una tabla de respuestas de eventos.


PARTICIONAMIENTO COMPORTAMIENT0 DE LOS DIAGRAMAS DE FLUJO DE DATOS

El particionamiento es el proceso de examinar un diagrama de flujo de datos y determinar cómo se debe dividir en colecciones de procedimientos manuales y colecciones de programas de cómputo. Analice cada proceso para determinar si debe ser un proceso manual o automatizado. Agrupe los procedimientos automatizados en una serie de programas de cómputo.

Existen seis razones para particionar diagramas de flujo de datos:

1. Diferentes grupos de usuarios. ¿Los procesos son realizados por varios grupos de usuarios diferentes, con frecuencia en distintas ubicaciones físicas de la compañía? Si es así, se deben particionar en diferentes programas de cómputo. Un ejemplo es la necesidad de procesar devoluciones de los clientes y pagos de los clientes en un almacén de departamentos.

2. Sincronización. Examine la sincronización de los procesos. Si dos procesos se realizan en diferentes momentos, no se pueden agrupar en un programa. Los aspectos de la sincronización también podrían involucrar qué cantidad de datos se presenta en un periodo determinado en una página Web.

3. Tareas similares. Si dos procesos ejecutan tareas similares, es posible agruparlos en un solo programa de cómputo.

4. Eficiencia. En un programa se podrían combinar varios procesos para realizar un procesamiento eficiente. Por ejemplo, si una serie de informes requieren utilizar los mismos archivos de entrada grandes, producirlos en conjunto podría ahorrar una cantidad considerable de tiempo de ejecución de la computadora.

5. Consistencia de los datos. Los procesos se podrían combinar en un solo programa para mantener la consistencia de los datos.

6. Seguridad. Los procesos se podrían particionar en diferentes programas por razones de seguridad.

Elaboracion de prototipos, RAD y programacion extrema

ELABORACIÓN DE PROTOTIPOS

Cuando el analista de sistemas presenta un prototipo del sistema de información, se interesa en las reacciones de los usuarios y los directivos de la organización hacia el prototipo. Las reacciones se recopilan a través de la observación, las entrevistas y las hojas de retroalimentación (posiblemente los cuestionarios) diseñados para obtener la opinión de cada persona sobre el prototipo después de que interactúan con él.

CLASES DE PROTOTIPOS

La palabra prototipo se usa de muchas formas diferentes.

Prototipo corregido La primera clase de elaboración de prototipos tiene que ver con la construcción de un sistema que funciona pero se corrige simultáneamente. En la ingeniería a este enfoque se le llama elaboración de una tabla experimental: la creación, en una tableta de pruebas, de un modelo funcional de un circuito integrado (que en la vida real sería microscópico).

Prototipo no funcional El segundo tipo de prototipo es un modelo no funcional a escala configurado para probar ciertos aspectos del diseño.

Primer prototipo de una serie Un tercer tipo de prototipos involucra la creación de un primer modelo a escala completa de un sistema, con frecuencia llamado piloto.
El prototipo es completamente funcional y es una materialización de lo que el diseñador espera será una serie de aviones con características idénticas.
Este tipo de elaboración de prototipos es útil cuando se planean muchas instalaciones del mismo sistema de información.

Prototipo de características seleccionadas Una cuarta concepción de la elaboración de prototipos involucra la creación de un modelo funcional que incluya algunas, pero no todas, de las características que tendrá el sistema final.

Cuando se elaboran prototipos de los sistemas de información de esta manera, se incluyen algunas de las características principales, aunque no todas. Por ejemplo, en la pantalla podría aparecer un menú del sistema que muestre seis características: agregar un registro, actualizar un registro, eliminar un registro, buscar una palabra clave en un registro, listar un registro o examinar un registro. Sin embargo, en el prototipo del sistema tal vez sólo estén disponibles tres de las seis características, de manera que el usuario podría agregar un registro (característica 1), eliminar un registro (característica 3} y listar un registro (característica 5).

ELABORACIÓN DE PROTOTIPOS COMO UNA ALTERNATIVA AL CICLO DE VIDA DEL DESARROLLO DE SISTEMAS

Algunos analistas argumentan que la elaboración de prototipos se debe considerar como una alternativa para el ciclo de vida del desarrollo de sistemas (SDLC). Recuerde que el SDLC, es un enfoque lógico y sistemático que se sigue en el desarrollo de sistemas de información.

COMO DESARROLLAR UN PROTOTIPO

Los lineamientos de esta sección para desarrollar un prototipo son avanzados. El término elaboración de prototipos se interpreta en el sentido de la última definición que se explicó, es decir, un prototipo de características seleccionadas que incluirá algunas pero no todas las características; uno que, si tiene éxito, será parte del sistema final que se entregue.

LINEAMIENTOS PARA DESARROLLAR UN PROTOTIPO

Una vez que se ha tomado la decisión de elaborar un prototipo, se deben observar cuatro lineamientos principales al integrar la elaboración de prototipos con la fase de determinación de requerimientos del SDLC:

1. Trabajar en módulos manejables.

Cuando el prototipo de algunas de las características de un sistema se integra para formar un modelo funcional, es indispensable que el analista trabaje en módulos manejables. Una ventaja evidente de la elaboración de prototipos es que no es necesario ni deseable construir un sistema operativo completo para los propósitos del prototipo.

2. Construir rápidamente el prototipo.

La rapidez es esencial para la elaboración exitosa del prototipo de un sistema de información. Recuerde que una de las quejas expresadas en contra del SDLC tradicional es que el intervalo entre la determinación de requerimientos y la entrega de un sistema completo es demasiado largo para satisfacer eficazmente las cambiantes necesidades del usuario.

3. Modificar el prototipo en iteraciones sucesivas.

Hacer modificable el prototipo significa crearlo en módulos que no sean demasiado interdependientes. Si se observa este lineamiento, se encontrará menos resistencia cuando sea necesario realizar cambios al prototipo. Los cambios en el prototipo deben propiciar que el sistema se acerque cada vez más a lo que los usuarios consideren importante. Cada modificación necesita otra evaluación por parte de los usuarios.


4. Poner énfasis en la interfaz de usuario.

La interfaz de usuario con el prototipo (y posteriormente con el sistema) es muy importante. Puesto que en realidad su principal objetivo con el prototipo es conseguir que los usuarios expresen mucho mejor sus requerimientos de información, éstos deben interactuar fácilmente con el prototipo del sistema.

DESVENTAJAS DE LA ELABORACIÓN DE PROTOTIPOS

Como en cualquier técnica de recopilación de información, la elaboración de prototipos tiene varias desventajas. La primera es que puede ser bastante difícil manejar la elaboración de prototipos como un proyecto en el esfuerzo de sistemas más grandes. La segunda desventaja es que los usuarios y los analistas podrían adoptar un prototipo como si fuera un sistema final cuando de hecho es deficiente y su propósito nunca fue el de servir como sistema terminado.


VENTAJAS DE LA ELABORACIÓN DE PROTOTIPOS

Las tres ventajas principales de la elaboración de prototipos son la posibilidad de modificar el sistema en las primeras etapas del desarrollo, la oportunidad de suspender el desarrollo de un sistema que no sea funcional y la posibilidad de desarrollar un sistema que se acerque más a satisfacer las necesidades y expectativas de los usuarios.

La elaboración exitosa de prototipos depende de una retroalimentación del usuario frecuente y oportuna, lo que sirve para modificar el sistema y hacerlo más receptivo a las necesidades reales. Al igual que cualquier esfuerzo de sistemas, los cambios oportunos son menos costosos que los cambios que se hacen más tarde en el desarrollo del proyecto.

ELABORACIÓN DE PROTOTIPOS USANDO SOFTWARE COTS

La manera más rápida de elaborar un prototipo es a través de la instalación modular de software COTS ("Comercial Off-The-Shelf", o software comercial). Aunque el concepto de software COTS se puede entender con facilidad al mirar paquetes conocidos y relativamente económicos como los productos de Microsoft Office, otro software COTS es más complejo y costoso, pero muy útil.

EL PAPEL DEL USUARIO EN LA ELABORACIÓN DE PROTOTIPOS.

El papel del usuario en la elaboración de prototipos se puede resumir en dos palabras: intervención honrada. Sin la intervención del usuario hay poca razón para elaborar el prototipo. Comprendiendo la importancia que tiene el usuario en el éxito del proceso, los miembros del equipo de análisis de sistemas deben propiciar y recibir de buena manera la retroalimentación y deben evitar su propia resistencia natural a cambiar el prototipo.

INTERACCIÓN CON EL PROTOTIPO

Hay tres formas principales en las que un usuario puede ayudar en la elaboración de prototipos:

1. Experimentando con el prototipo.

2. Dando reacciones sinceras sobre el prototipo.

3. Sugiriendo adiciones o eliminaciones al prototipo.

Los usuarios deben tener libertad para experimentar con el prototipo. En contraste con una simple lista de características de sistemas, el prototipo permite a los usuarios la interacción real. Una forma de facilitar esta interacción es instalar un prototipo en un sitio
Web interactivo.

DESARROLLO RÁPIDO DE APLICACIONES

El desarrollo rápido de aplicaciones (RAD) es un enfoque orientado a objetos para el desarrollo de sistemas que incluye un método de desarrollo así como también herramientas de software. El RAD y la elaboración de prototipos se enfocan en satisfacer más de cerca los requerimientos cambiantes de los negocios. Una vez que ha aprendido los conceptos de la elaboración de prototipos, es mucho más fácil entender la esencia del RAD, que se puede considerar como una implementación específica de la elaboración de prototipos.

FASES DEL RAD

Hay tres fases amplias del RAD que vinculan a usuarios y analistas en la evaluación, diseño e implementación.

Fase de planeación de requerimientos

En esta fase, usuarios y analistas se reúnen para identificar los objetivos de la aplicación o sistema y para identificar los requerimientos de información que surgen de dichos objetivos. Esta fase requiere que ambos grupos se involucren intensamente; no se trata simplemente de firmar una propuesta o documento. Además, esto podría involucrar a usuarios de los diferentes niveles de la organización.

Taller de diseño del RAD

El proceso de diseñar y refinar los prototipos se puede representar mejor como un taller. Cuando imagina un taller, sabe que la participación es intensa, no pasiva, y que generalmente se hace con las manos.

Fase de implementación

Tan pronto como sean convenidos estos aspectos y los sistemas sean construidos y se refinen, los nuevos sistemas, o parte de ellos, son probados e introducidos en la organización. Debido a que el RAD se puede usar para crear las nuevas aplicaciones de comercio electrónico para las cuales no hay ningún sistema viejo, por lo general no se necesita ejecutar los sistemas viejos y nuevos en paralelo antes de la implementación (además que no hay forma real de hacerlo).

Cuándo utilizar el RAD En su función de analista, necesita aprender tantos enfoques y herramientas como sea posible que lo ayuden a hacer mejor su trabajo. Ciertas aplicaciones y trabajo de sistemas darán lugar a ciertas metodologías. Considere utilizar RAD cuando:

1. su equipo incluya a programadores y analistas que tengan experiencia con él, y

2. haya razones de negocios urgentes para acelerar una parte del desarrollo de la aplicación;

3. cuando esté trabajando con una nueva aplicación de comercio electrónico y su equipo de desarrollo crea que el negocio puede beneficiarse ampliamente sobre sus competidores siendo innovador si esta aplicación está entre las primeras en aparecer en la Web; o

4. cuando los usuarios sean maduros y estén altamente comprometidos con las metas organizacionales.


Desventajas del RAD Las dificultades con el RAD, como con otras clases de elaboración de prototipos, se originan debido a que los analistas de sistemas intentan apresurar demasiado el proyecto.

PROGRAMACIÓN EXTREMA

La programación extrema (XP) es un enfoque de desarrollo de software que adopta lo que generalmente designamos como prácticas de desarrollo de software aceptable y las lleva al extremo. Por ejemplo, la retroalimentación es importante para los programadores, analistas, diseñadores, usuarios y computadoras

La administración de proyectos es importante, de tal manera que la programación extrema intenta definir rápidamente un plan global del sistema, desarrollar y liberar rápidamente el software y posteriormente revisarlo continuamente para incorporarle características adicionales. Pero la programación extrema no sólo se basa en los resultados. Se basa en los valores, principios y prácticas. Ahora examinaremos cómo los valores y principios de XP dan forma al desarrollo de sistemas extremos.

VALORES Y PRINCIPIOS DE LA PROGRAMACIÓN EXTREMA

Para la programación extrema es importante que se declaren los valores y principios que crean el contexto para la colaboración entre programadores y clientes. Para considerarse analista de XP, se debe apegar a los siguientes valores y principios desarrollados por Beck.

Cuatro valores de XP Hay cuatro valores que crean un entorno en el cual se pueden servir adecuadamente diseñadores y negocios. Los cuatro valores son comunicación, sencillez, retroalimentación y valentía.