CAPITULO 10. PREPARACION DE LA PROPUESTA DE SISTEMAS.

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.

CÓMO INVENTARIAR EL HARDWARE DE CÓMPUTO
Empiece por inventariar el hardware de cómputo que ya existe en la organización. Como
podrá 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.

CÁLCULO DE LAS CARGAS DE TRABAJO
El próximo paso en la determinación de las necesidades de hardware es calcular las cargas de trabajo. Así, 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.

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.

Tamaño y uso de la computadora El rápido avance de la tecnología obliga a los analistas de sistemas a investigar qué tipos de computadoras están disponibles en el momento específico en que se escribe la propuesta de sistemas. El tamaño de las computadoras va desde las pequeñas computadoras Palm que caben en una mano hasta las supercomputadoras que podrían ocupar toda una sala.

Evaluación del soporte técnico del fabricante para el hardware de cómputo Diversas
áreas importantes se deben evaluar al analizar los servicios de soporte técnico que los fabricantes ponen a disposición de las empresas. La mayoría de los fabricantes ofrece una prueba de hardware en la entrega y una garantía de 90 días que cubre cualquier defecto de fabricación, pero usted debe averiguar qué más ofrece el fabricante. Los fabricantes de calidad comparable frecuentemente se distinguen de otros por la gama de servicios de soporte técnico que ofrecen.

COMO IDENTIFICAR Y PRONOSTICAR LOS COSTOS Y BENEFICIOS
Siempre se deben considerar en conjunto los costos y beneficios del sistema de cómputo propuesto, debido a que con frecuencia están vinculados y dependen uno del otro.

CÓMO PRONOSTICAR LOS COSTOS Y BENEFICIOS
Se necesita que los analistas de sistemas pronostiquen ciertas variables importantes antes de enviar la propuesta al cliente. Hasta cierto punto, un analista de sistemas se apoyará en un análisis de "qué pasa si", tal como, "¿Qué pasa si los costos de mano de obra suben sólo 5 por ciento por año durante los próximos tres años, en lugar de 10 por ciento?" Sin embargo, el analista de sistemas debe entender que él o ella no se pueden apoyar únicamente en un análisis del tipo "qué pasa si" si quieren que la propuesta sea creíble, significativa y valiosa.

ANÁLISIS DE FLUJO DE EFECTIVO
El análisis de flujo de efectivo examina la dirección, tamaño y modelo del flujo de efectivo que se asocia con el sistema de información propuesto.

CAPITULO 9. DESCRIPCION DE LAS ESPECIFICACIONES DE PROCESOS Y DECISIONES ESTRUCTURADAS.

El analista de sistemas que aborda las especificaciones de procesos y las decisiones y tiene muchas opciones para documentarlas y analizarlas.

FORMATO DE LA ESPECIFICACIÓN DE PROCESOS
las especificaciones de procesos vinculan el proceso al diagrama de flujo de datos y, por consiguiente, al diccionario de datos. La especificación de cada proceso se debe registrar en un formulario especial o en la pantalla de una herramienta CASE como la que utiliza Visible Analyst y que se muestra en el caso de la CPU al final
de este capítulo. Teclee la siguiente información:

1. El número del proceso, el cual debe coincidir con el ID del proceso del diagrama de flujo de datos. Esta especificación permite a un analista trabajar con cualquier proceso o modificarlo y localizar fácilmente el diagrama de flujo de datos donde se encuentra el proceso.
2. El nombre del proceso, el cual nuevamente debe ser el mismo que el asentado en el símbolo del proceso en el diagrama de flujo de datos.
3. Una descripción breve de lo que realiza el proceso.
4. Una lista de flujos de datos de entrada, usando los nombres que están en-el diagrama de flujo de datos. Los nombres de datos que se usan en la fórmula o lógica deben coincidir con los del diccionario de datos para garantizar la consistencia y una buena comunicación.
5. Los flujos de datos de salida, utilizando también los nombres del diagrama de flujo de datos y del diccionario de datos.
6. Una indicación del tipo de proceso: por lote, en línea o manual. Todos los procesos en línea requieren diseños de pantalla, y todos los procesos manuales deben tener procedimientos bien definidos para que los empleados realicen las tareas del proceso.
7. Si el proceso usa código preescrito, incluya el nombre del subprograma o función que contenga al código.
8. Una descripción de la lógica del proceso que indique las políticas y reglas del negocio en lenguaje cotidiano, no en pseudocódigo de lenguaje de computadora. Las reglas del negocio son los procedimientos, o quizás un conjunto de condiciones o fórmulas, que permiten a una corporación dirigir su negocio. Los formatos comunes de las reglas del negocio incluyen lo siguiente:
- Definiciones de los términos del negocio.
- Condiciones y acciones del negocio.
- Restricciones de la integridad de los datos.
- Derivaciones matemáticas y funcionales.
- Inferencias lógicas.
- Secuencias de procesamiento.
• Relaciones entre las circunstancias del negocio.
9. Si no hay suficiente espacio en el formulario para una descripción completa del Español estructurado o si hay una tabla o árbol de decisión que describa la lógica, incluir el nombre de la tabla o árbol correspondiente.
10. Mencione cualquier problema sin resolver, partes incompletas de la lógica u otras consideraciones. Estos problemas constituyen la base de las preguntas usadas para las entrevistas de seguimiento.

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.

TABLAS DE DECISIÓN MÁS AVANZADAS
Las tablas de decisión pueden ser muy difíciles de manejar porque crecen rápidamente conforme se incrementa el número de condiciones y alternativas. Una tabla con tan sólo siete condiciones y con alternativas sí o no tendría 128 columnas.

ÁRBOLES DE DECISIÓN
Los árboles de decisión se usan cuando ocurre una bifurcación compleja en un proceso de decisión estructurada. Los árboles también son útiles cuando es necesario mantener una cadena de decisiones en una secuencia particular. Aunque el nombre del árbol de decisión se deriva de los árboles naturales, en la mayoría de los casos los árboles de decisión se construyen de manera lateral, con la raíz del árbol del lado izquierdo del papel; a partir de allí, el árbol extiende sus ramas hacia el lado derecho. Esta orientación permite al analista escribir en las ramas para describir condiciones y acciones.

CAPITULO 8. ANALISIS DE SISTEMAS MEDIANTE DICCIONARIOS DE DATOS.

El diccionario de datos es una aplicación especializada de los tipos de diccionarios usados como referencia en la vida cotidiana. El diccionario de datos es una obra de consulta con información acerca de los datos (es decir, metadatos), compilada por los analistas de sistemas para guiarse en el análisis y diseño. Como un documento, el diccionario de datos recopila y coordina términos de datos específicos, y confirma lo que cada término significa para las diferentes personas en la organización.

NECESIDAD DE ENTENDER EL DICCIONARIO DE DATOS
Muchos sistemas de administración de base de datos están equipados con un diccionario
de datos automatizado. Estos diccionarios pueden ser complejos o sencillos. Algunos diccionarios de datos computarizados catalogan automáticamente los elementos de datos
cuando se hace la programación; otros simplemente proporcionan una plantilla para motivar a la persona que llene el diccionario a que lo haga de una manera uniforme para cada entrada.

ESTRUCTURAS DE DATOS LÓGICAS Y FÍSICAS
Cuando las estructuras de datos se definen primero, sólo se incluyen los elementos de datos que el usuario vería, tal como un nombre, dirección y saldo a pagar. Esta fase es el diseño lógico, el cual muestra qué datos necesita el negocio para sus operaciones diarias.

ALMACENES DE DATOS
Todos 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. Los almacenes de datos se crean para cada entidad de datos diferente que se almacenará. Es decir, cuando los elementos base de un flujo de datos se agrupan para formar un registro estructural, se crea un almacén de datos para cada registro estructural único.

CREACIÓN DEL DICCIONARIO DE DATOS
Las entradas del diccionario de datos se podrían crear después de completar el diagrama de flujo de datos, o se podrían construir conforme se desarrolle el diagrama de flujo de datos. El uso de notación algebraica y registros estructurales permite al analista desarrollar el diccionario de datos y los diagramas de flujo de datos mediante un enfoque jerárquico de arriba hacia abajo. Por ejemplo, el analista podría crear un flujo de datos de un Diagrama 0 después de las primeras entrevistas y, al mismo tiempo, hacer las entradas preliminares del diccionario de datos. Típicamente, estas entradas consisten en los nombres de los flujos
de datos encontrados en el diagrama de flujo de datos y sus estructuras de datos correspondientes.

USO DEL DICCIONARIO DE DATOS
El diccionario de datos ideal es automatizado, interactivo, en línea y evolutivo. Conforme el analista de sistemas descubre cosas nuevas de los sistemas de la organización, se agregan elementos de datos al diccionario de datos. Por otro lado, el diccionario de datos no es un fin en sí mismo y nunca debe serlo. Para evitar desviarse del propósito principal con la construcción de un diccionario de datos completo, el analista de sistemas debe verlo como una actividad paralela al análisis y diseño de sistemas.

CAPITULO 7. USO DE DIAGRAMAS DE FLUJO DE DATOS.

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

El cuadrado doble se usa para describir una entidad externa (otro departamento, un
negocio, una persona o una máquina] que puede enviar datos al sistema o recibirlos de él.
La entidad externa, o sólo entidad, también se llama origen o destino de datos, y se considera externa al sistema descrito. A cada entidad se le asigna un nombre adecuado. Aunque interactúa con el sistema, se considera fuera de los límites de éste.
Las entidades se deben designar con un nombre. La misma entidad se podría usar más de una vez en un diagrama de flujo de datos en particular para evitar que las líneas se crucen en el flujo de datos.
La flecha muestra el movimiento de los datos de un punto a otro, con la punta de la flecha señalando hacia el destino de los datos. Los flujos de datos que ocurren simultáneamente se pueden describir mediante flechas paralelas.
Una flecha también se debe describir con un nombre, debido a que representa los datos de una persona, lugar o cosa.
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.

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. Por el contrario, 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.

CAPITULO 6. ELABORACION DE PROTOTIPOS, RAD Y PROGRAMACION EXTREMA.

ELABORACIÓN DE PROTOTIPOS
Como analista de sistemas que presenta un prototipo del sistema de información, usted está bastante interesado en las reacciones de los usuarios y los directivos de la organización hacia el prototipo.

CLASES DE PROTOTIPOS
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.

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. Un ejemplo es la elaboración de un prototipo del primer avión de una serie.

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.

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). El
SDLC es un enfoque lógico y sistemático que se sigue en el desarrollo
de sistemas de información.

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
La elaboración de prototipos no es necesaria o apropiada en todos los proyectos de sistemas, como hemos visto. Sin embargo, también se deben considerar las ventajas al momento de decidir si se hace el prototipo. 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.

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.

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

RAD EN COMPARACIÓN CON EL SDLC
El SDLC toma un enfoque más metódico y sistemático que asegura
la integridad y exactitud y tiene como propósito la creación de sistemas que se integran bien en los procedimientos estándar de negocio y en la cultura.
La fase del taller de diseño del RAD difiere de las fases de diseño estándar del SDLC, debido a que las herramientas de software del RAD se usan para generar pantallas y exhibirel flujo global del funcionamiento de la aplicación.

CAPITULO 5. RECOPILACION DE INFORMACION: METODOS NO INTRUSIVOS

Tan sólo con su presencia en una organización, el analista de sistemas la cambia. Sin embargo,los métodos no intrusivos como el muestreo, la investigación y la observación del comportamiento y el entorno físico de un tomador de decisiones, son menos molestos que otras formas de obtener los requerimientos de información.

MUESTREO
El muestreo es el proceso consistente en seleccionar sistemáticamente elementos representativos de una población. Cuando dichos elementos se examinan con cuidado, se da por hecho que el análisis revelará información útil de la población en general.

DISEÑO DEL MUESTREO
Un analista de sistemas debe seguir cuatro pasos para diseñar una buena muestra:
1. Determinar qué datos van a ser recopilados o descritos.
2. Determinar de qué población se van a tomar muestras.
3. Escoger el tipo de muestra.
4. Decidir el tamaño de la muestra.

DECISIÓN DEL TAMAÑO DE LA MUESTRA
Con frecuencia, el tamaño de la muestra depende del costo involucrado o del tiempo requerido por él analista de sistemas, o incluso del tiempo que tengan las personas de la organización.
Esta subsección proporciona al analista de sistemas algunos lineamientos para determinar el tamaño de la muestra requerido bajo condiciones ideales, por ejemplo, para determinar qué porcentaje de formularios contestados contiene errores, o en otro caso, qué proporción de personas entrevistar.


Cómo determinar el tamaño de la muestra al entrevistar. No hay una fórmula mágica que
le ayude al analista de sistemas a establecer el tamaño de la muestra para entrevistar.


ANÁLISIS DE DOCUMENTOS CUANTITATIVOS
En todas las empresas existen muchos documentos cuantitativos disponibles para su interpretación, y entre ellos se incluyen informes usados para la toma de decisiones, informes de desempeño, registros y una variedad de formularios.

Informes usados para la toma de decisiones.
Un analista de sistemas necesita obtener algunos de los documentos que se usan para dirigir un negocio.

Informes de desempeño.
La mayoría de estos informes reflejan el desempeño real versus el desempeño deseado.

Registros.
Los registros proporcionan actualizaciones periódicas de lo que ocurre en el negocio.

Formularios de captura de datos.
Antes de que empiece a cambiar los flujos de información en la organización,necesita entender el sistema actual.

ANÁLISIS DE LOS DOCUMENTOS CUALITATIVOS
Los documentos cualitativos incluyen mensajes de correo electrónico, memorandos, carteles en los tableros de anuncios y en las áreas de trabajo, páginas Web, manuales de procedimientos y manuales de políticas.

Carteles o pancartas en los tableros de anuncios o en las áreas de trabajo.
Aunque los carteles podrían parecer circunstanciales en relación con lo que ocurre en la organización, sirven como reforzadores sutiles de valores para aquellos que los leen.

Sitios Web corporativos.
El analista también debe poner atención en los sitios Web que se usan en el comercio electrónico negocio a cliente.

Manuales.
Otros documentos cualitativos que el analista debe examinar son los manuales
de la organización, incluyendo los manuales de procedimientos de operación de las computadoras y los manuales en línea.

Manuales de políticas.
El último tipo de documento cualitativo que consideraremos es el manual de políticas.