garielmm

garielmm

jueves, 27 de mayo de 2010

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.

miércoles, 26 de mayo de 2010

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

domingo, 16 de mayo de 2010

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.

viernes, 14 de mayo de 2010

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.

lunes, 26 de abril de 2010

Recopilación de información: métodos no intrusivos.

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.

LA NECESIDAD DE MUESTREO

Hay muchas razones por las cuales un analista de sistemas tendría que seleccionar una muestra representativa de datos para examinarla o personas representativas para entrevistarlas, aplicarles un cuestionario u observarlas. Entre estas razones se incluyen:
1. Reducir costos.
2. Acelerar la recopilación de datos.
3. Mejorar la efectividad.
4. Reducir la parcialidad.
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.
Cómo decidir el tamaño de la muestra Obviamente, si todos en la población vieran el mundo de la misma forma o si cada uno de los documentos contuviera exactamente la misma información que los demás, sería suficiente un tamaño de uno para la muestra. Puesto que éste no es el caso, es necesario establecer un tamaño de muestra mayor que uno pero menor que el tamaño mismo de la población.
Es importante recordar que en el muestreo es de mayor importancia el número absoluto que el porcentaje de la población. Podemos obtener resultados satisfactorios con un muestreo de 20 personas de 200 o con uno de 20 de 2,000,000.

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.
El analista de sistemas debe seguir siete pasos, algunos de los cuales son juicios subjetivos, para determinar el tamaño de la muestra requerido:
1. Determinar el atributo (en este caso, el tipo de errores que se buscará).
2. Localizar la base de datos o informes en los cuales se puede encontrar el atributo.
3. Examinar el atributo. Calcular p, la proporción de población que tiene el atributo.
4. Tomar la decisión subjetiva con respecto a la estimación del intervalo aceptable, i.
5. Seleccionar el nivel de confianza y buscar el coeficiente de confianza (valor z) en una tabla.
6. Calcular crp, el error estándar de la proporción.

Una buena regla general es entrevistar a por lo menos tres personas de cada nivel de la organización y por lo menos a una de cada área funcional de la organización [como se describió en el capítulo 2) que estarán involucradas directamente con un sistema nuevo o actualizado.
INVESTIGACIÓN

Conforme el analista de sistemas se esfuerza por entender la organización y sus requerimientos de información, es importante que examine los diferentes tipos de datos reales que ofrecen información no disponible a través de ningún otro método de recopilación de datos. Los datos reales revelan en dónde está la organización y hacia dónde creen sus miembros que se dirige. Para conjuntar un panorama preciso, el analista necesita examinar datos reales tanto cuantitativos como cualitativos.


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. Todos estos documentos tienen un propósito y un público específicos a los cuales van dirigidos.

Tales informes ayudan al tomador de decisiones a identificar fácilmente las tendencias.
Los informes de producción incluyen costos recientes, inventario actual, mano de obra reciente e información de las instalaciones.

Informes de desempeño La mayoría de estos informes reflejan el desempeño real versus el desempeño deseado. Una función importante de los informes de desempeño es evaluar la dimensión de la brecha entre el desempeño real y el deseado.
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.
Los formularios en blanco, junto con sus instrucciones de llenado y distribución, se pueden comparar con los formularios contestados para averiguar si alguno de sus elementos de datos queda regularmente sin respuesta.

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. Hay razón para ello. Algunos lineamientos pueden ayudar a los analistas a seguir un enfoque sistemático en esta clase de análisis:
1. Examine los documentos en busca de metáforas clave u orientadoras.
2. Busque una mentalidad de internos contra externos o de "nosotros contra ellos".
3. Liste los términos que caractericen lo bueno o lo malo y que aparezcan repetidamente en los documentos.
4. Busque mensajes y gráficos significativos colocados en áreas comunes o en páginas Web.
5. Identifique el sentido del humor, si lo hay.

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. El examen de las políticas permite al analista de sistemas comprender los valores, actitudes y creencias que guían a la corporación.

OBSERVACIÓN DEL COMPORTAMIENTO DEL TOMADOR DE DECISIONES
La observación del tomador de decisiones y su entorno físico son métodos no intrusivos importantes para el analista de sistemas. Al observar las actividades del tomador de decisiones, el analista busca darse una idea de lo que realmente se hace, no sólo de lo que se documenta o explica. Además, al observar al tomador de decisiones, el analista trata de ver personalmente las relaciones que existen entre el tomador de decisiones y los demás miembros de la organización.

OBSERVACIÓN DE LAS ACTIVIDADES DE TOMA DE DECISIONES DE UN GERENTE TÍPICO
El analista de sistemas se vale de entrevistas y cuestionarios interactivos para entender adecuadamente la manera en que los gerentes describen su trabajo. Sin embargo, la observación permite al analista ver personalmente la manera en que un gerente recopila, procesa, comparte y usa la información para realizar su trabajo.

OBSERVACION DEL ENTORNO FISICO
La observación de las actividades de los tomadores de decisiones es sólo una forma de evaluar sus requerimientos de información. La observación del entorno físico en el cual se desempeñan los tomadores de decisiones también pone de manifiesto muchos de sus requerimientos de información.

OBSERVACIÓN ESTRUCTURADA DEL ENTORNO (STROBE)
Los críticos de cine a veces recurren a una forma de crítica estructurada conocida como análisis de escenario para evaluar sistemáticamente lo que hay en una sola toma de la película.
Revisan la edición, el ángulo de la cámara, la decoración del set y a los actores y su vestuario para descubrir si le están dando forma al contenido de la película como el director lo desea. A veces el escenario de la película no corresponde con lo que se dice en el diálogo.
El analista de sistemas puede asumir un papel similar al del crítico de cine para el análisis de los requerimientos de información. A menudo es posible observar las circunstancias del entorno que confirmarán o negarán el discurso

El método para la Observación Estructurada del Entorno (STRuctured OBservation of the Environment) se conoce como STROBE. La aplicación exitosa del STROBE requiere que el analista observe explícitamente siete elementos concretos que por lo general se encuentran en las oficinas.

Ubicación de la oficina
Uno de los primeros elementos que el analista de sistemas debe observar es la ubicación de la oficina de un tomador de decisiones específico con respecto a otras oficinas. Las oficinas accesibles tienden a aumentar la frecuencia de la interacción y los mensajes informales, mientras que las oficinas inaccesibles tienden a disminuir la frecuencia de la interacción y a aumentar los mensajes orientados a las tareas.
Colocación del escritorio
La colocación de un escritorio en la oficina puede ofrecer pistas sobre la manera en que el tomador de decisiones ejerce su autoridad. Los ejecutivos que confinan a un visitante a un espacio reducido y con la espalda a la pared mientras ellos tienen exceso de espacio, adoptan la posición de autoridad más fuerte posible. Un ejecutivo que coloca su escritorio frente a la pared con una silla al lado para un visitante estimula la participación y los intercambios equitativos. El analista de sistemas debe observar la distribución de los muebles de la oficina y en particular la colocación del escritorio.

Equipo fijo de oficina
Archiveros, libreros y otro equipo grande para almacenar artículos se incluyen en la categoría de equipo fijo de oficina. Si no hay tal equipo, es probable que el tomador de decisiones almacene muy pocos artículos de información por sí mismo. Si hay una abundancia de tal equipo, se asume que el tomador de decisiones almacena y valora mucha información.

Accesorios
El término accesorios se refiere a todo el equipo pequeño usado para procesar información, incluso las computadoras de bolsillo, calculadoras, PCs, plumas, lápices y reglas. La presencia de computadoras de bolsillo, calculadoras y PCs sugiere que un tomador de decisiones que posee dicho equipo es más probable que lo use personalmente que uno que debe salir de la oficina para usarlo.

Fuentes externas de información
Un analista de sistemas necesita saber qué tipo de información usa el tomador de decisiones. La observación del tipo de publicaciones almacenadas en la oficina puede revelar si el tomador de decisiones recurre a información externa (en revistas de comercio, recortes de periódico sobre otras compañías de la industria, etc.) o se basa más en la información interna (informes de la compañía, correspondencia de la oficina, manuales de políticas). El analista también debe observar si el tomador de decisiones prefiere conseguir información externa en la Web.

Iluminación y color de la oficina
La iluminación y el color juegan un papel importante en la manera en que un tomador de decisiones recopila información. Una oficina con iluminación cálida y radiante indica una tendencia hacia la comunicación más personal. Un ejecutivo en una oficina iluminada cálidamente recopilará más información de manera informal, mientras que otro miembro de la organización que trabaja en una oficina iluminada con gran colorido podría recopilar información a través de memorandos más formales e informes oficiales.
Vestimenta de los tomadores de decisiones
Se ha escrito mucho sobre la vestimenta de los ejecutivos y demás personal con algún grado de autoridad. El analista de sistemas puede darse una idea de la credibilidad de los gerentes de la organización al observar la vestimenta que usan en el trabajo. El traje de dos piezas para un hombre o el traje con falda para una mujer representan la máxima autoridad, de acuerdo con algunos investigadores que han estudiado las percepciones sobre la apariencia de los ejecutivos. El hecho de que los líderes vistan de manera casual tiende a abrir las puertas para una toma de decisiones más participativa, pero a menudo propicia la pérdida de credibilidad en la organización si la cultura predominante valora la ropa tradicional y conservadora.
Mediante el STROBE, el analista de sistemas puede darse una mejor idea de la manera en que los gerentes recopilan, procesan, almacenan y usan la información.

APLICACIÓN DEL STROBE
Una forma de implementar el STROBE es mediante el uso de una lista de verificación anecdótica con símbolos taquigráficos. Este enfoque del STROBE fue útil para determinar los requerimientos de información de cuatro tomadores de decisiones importantes en una tienda de ropa.

martes, 13 de abril de 2010

Recopilación de información: métodos interactivos.

Existen métodos que nos permiten tener acceso, a la recopilación de información necesaria para saber o identificar problemas dentro de una organización. Es importante identificar cuales son esos métodos y como aplicarlos. A continuación explicaremos unos de los más comunes y su forma de ser empleados.

ENTREVISTAS

Para llevar a cavo una entrevista es indispensable primero conocerse así mismo. Necesita conocer sus prejuicios y cómo afectarán éstos sus percepciones. Su educación, intelecto, formación, emociones y marco ético actúan como filtros poderosos de lo que va a oír en sus entrevistas para poder entender lo que es una entrevista.

Una entrevista es utilizada para recabar información, dicho en otros términos es una conversación dirigida con un propósito específico que utiliza un formato de preguntas y respuestas. En la entrevista usted necesita obtener las opiniones de los entrevistados y su parecer acerca del estado actual del sistema, metas organizacionales y personales y procedimientos informales.

Hay cinco pasos para poder preparar una entrevista

Los cinco pasos principales para preparar una entrevista son:

Pasos para la planeación de la entrevista
1. Leer los antecedentes.
2. Establecer los objetivos de la entrevista.
3. Decidir a quién entrevistar.
4. Preparar al entrevistado.
5. Decidir el tipo de preguntas y la estructura.

Estos pasos incluyen un rango de actividades que van desde recopilar antecedentes básicos hasta decidir a quién entrevistar.

Leer los antecedentes Leer y entender tanto como sea posible los antecedentes de los entrevistados y su organización. Con frecuencia este material se puede obtener del sitio Web.

Establecer los objetivos de la entrevista Utilice los antecedentes que haya recopilado así como su propia experiencia para establecer los objetivos de la entrevista. Debe haber de cuatro a seis áreas clave referentes al procesamiento de la información y el comportamiento relacionado con la toma de decisiones acerca de las cuales tendrá usted que hacer preguntas.
Estas áreas incluyen fuentes de información, formatos de información, frecuencia de la toma de decisiones, cualidades de la información y estilo de la toma de decisiones.

Decidir a quién entrevistar Cuando tenga que decidir a quién entrevistar, incluya a gente clave de todos los niveles que vayan a ser afectadas por el sistema de alguna manera. Esfuércese por conseguir el equilibrio de tal manera que atienda las necesidades de tantos usuarios como sea posible. Su persona de contacto en la organización también tendrá algunas ideas sobre quién deba ser entrevistado.

Preparar al entrevistado Prepare a la persona que va a ser entrevistada hablándole por anticipado o enviándole un mensaje de correo electrónico y dándole tiempo para pensar en la entrevista. Si va a realizar una entrevista a profundidad, puede enviar sus preguntas por correo electrónico con antelación para darle tiempo al entrevistado a que piense sus respuestas. Sin embargo, debido a que con la entrevista se pretende satisfacer muchos objetivos (incluyendo la creación de confianza y la observación del lugar de trabajo), normalmente ésta se debe realizar en persona y no por correo electrónico. Las entrevistas se deben llevar a cabo en 45 minutos o una hora a lo mucho. No importa cuánto parezca que sus entrevistados deseen ampliar la entrevista más allá de este límite, recuerde que cuando pasan tiempo con usted, no están haciendo su trabajo. Si las entrevistas duran más de una hora, es probable que los entrevistados se enfaden, aunque quizá oculten su disgusto.

Decidir el tipo de preguntas y la estructura
Escriba preguntas que abarquen las áreas clave de la toma de decisiones que haya descubierto al determinar los objetivos de la entrevista. Las técnicas apropiadas para preguntar son el corazón de la entrevista. Las preguntas tienen algunas formas básicas que usted debe conocer. Los dos tipos básicos de preguntas son las abiertas y las cerradas. Cada tipo de pregunta puede lograr resultados un poco diferentes a los de la otra, y cada una tiene ventajas y desventajas. Es necesario que usted piense en el efecto que tendrá cada tipo de pregunta.

TIPOS DE PREGUNTAS

Existen diversidad de tipos de preguntas y cada una es usada de acuerdo a las necesidades o que tanto de información es requerida es importante aplicar el método que vamos a usar para realizar dichas preguntas de acuerdo a su tipo.

Preguntas abiertas

Estas preguntas incluyen aquellas como "¿Qué piensa de poner a todos los gerentes en una intranet?" y "Explique por favor cómo toma una decisión de programación de producción". Considere el término abiertas.
En realidad, "abiertas" describe las opciones del entrevistado para responder. Están abiertas.

Preguntas cerradas La alternativa a las preguntas abiertas se encuentra en el otro tipo de pregunta básica: las preguntas cerradas. Tales preguntas son de la forma básica: "¿Cuántos subordinados tiene?" Las respuestas posibles se cierran al entrevistado, debido a que sólo puede contestar con un número finito como "Ninguno", "Uno" o "Quince". Una pregunta cerrada limita la respuesta disponible para el entrevistado.


Uso de una estructura de pirámide

La organización inductiva de preguntas de la entrevista se puede visualizar como si se tuviera una forma de pirámide. Con base en esta forma, el entrevistador empieza con preguntas, a menudo cerradas, muy detalladas. Posteriormente, el entrevistador extiende los temas permitiendo preguntas abiertas y respuestas más generalizadas.
Debe utilizar una estructura de pirámide si cree que su entrevistado necesita motivación para profundizar en el tema. También es conveniente utilizar una estructura de pirámide para la secuencia de las preguntas cuando desea una opinión concluyente del tema. Tal es el caso de la pregunta final: "En general, ¿qué opina de la seguridad de los datos versus la importancia del acceso a Internet?"

Uso de una estructura de embudo

En el segundo tipo de estructura, el entrevistador adopta un método deductivo al iniciar con preguntas generales y abiertas, y luego limitar las posibles respuestas utilizando preguntas cerradas. Esta estructura de entrevista se puede visualizar como una forma de embudo.

Uso de una estructura de diamante
Con frecuencia es mejor una combinación de las dos estructuras anteriores, lo cual da como resultado una estructura de diamante. Esta estructura implica empezar de una manera muy específica, después se examinan los aspectos generales y finalmente se termina con una conclusión muy específica.

El entrevistador empieza con preguntas cerradas sencillas que permiten calentar el proceso de la entrevista. A la mitad de la entrevista, se le pide al entrevistado que dé su opinión sobre temas amplios que obviamente no tienen una respuesta "correcta". Posteriormente, el entrevistador limita de nuevo las preguntas para obtener respuestas específicas, con lo cual propicia, tanto para él como para el entrevistado, una forma de cerrar la entrevista. La estructura de diamante combina las fortalezas de los otros dos métodos, pero tiene la desventaja de tomar mucho más tiempo que cualquiera de las otras estructuras.

viernes, 19 de marzo de 2010

DETERMINACIÓN DE LA VIABILIDAD Y ADMINISTRACIÓN DE LAS ACTIVIDADES DE ANÁLISIS Y DISEÑO

Existen cinco aspectos fundamentales de un proyecto que el analista de sistemas debe dominar los cuales son:

(1) la iniciación de proyectos
(2) la determinación de la viabilidad de un proyecto
(3) la planeación y el control de actividades
(4) la programación de proyectos
(5) la administración de los miembros del equipo de análisis de sistemas.

Los proyectos pueden ser solicitados por diversas personas de la organización o por los mismos analistas de sistemas.

La selección de un proyecto es una decisión difícil, ya que se solicitarán más proyectos de los que se pueden realizar. Cinco criterios importantes para la selección de proyectos son:

(1) que el proyecto solicitado tenga el respaldo de los directivos de la organización

(2) que cuente con un periodo adecuado de compromiso para la terminación del proyecto
(3) que impulse a la organización hacia la consecución de sus metas
(4) que sea factible
(5) que tenga la importancia suficiente para darle mayor prioridad que a otros proyectos.

Determinación de la viabilidad y administración de las actividades de análisis y diseño

Entre muchas de las capacidades fundamentales que debe dominar un analista de sistemas se incluye la iniciación de proyectos, la determinación de la viabilidad de un proyecto, la programación de proyectos, y la planeación y administración de las actividades y los miembros de un equipo para optimizar la productividad.

Estas capacidades se consideran aspectos fundamentales de un proyecto.
Un proyecto de sistemas comienza con problemas o con oportunidades de realizar mejoras en un negocio, que surgen con frecuencia conforme la organización se adapta al cambio.

PROBLEMAS EN LA ORGANIZACIÓN

Los problemas surgen de diversas maneras. Una forma de averiguar que hay problemas y cómo se originaron, es considerarlos como situaciones en las cuales ya no se alcanzan o nunca se han alcanzado las metas fijadas.

En algunos casos, los problemas que requieren la atención del analista de sistemas permanecen ocultos porque no se realizan mediciones del desempeño. Los problemas (o síntomas de problemas) en procesos cuyos resultados son visibles y que podrían requerir la ayuda de un analista de sistemas incluyen errores excesivos y trabajo realizado con demasiada lentitud, incompleto, incorrecto o que no se hace. Otros síntomas de problemas se vuelven evidentes cuando los individuos no cumplen las metas de desempeño establecidas.

SELECCIÓN DE PROYECTOS

Se debe tener bien presentes las razones para recomendar el estudio de sistemas de un proyecto que parezca resolver un problema o propiciar una mejora. Tome en cuenta los motivos que impulsen una propuesta de proyecto. Debe asegurarse de que el proyecto no tiene como propósito mejorar su propia imagen política o su poder, o el poder de la persona o grupo que lo proponga, porque hay una alta probabilidad de que el proyecto sea mal concebido y, con el tiempo, no tenga una buena aceptación.


A pesar de que los encargados de la toma de decisiones son quienes en última instancia establecen las fronteras del proyecto de sistemas, éste no se debe considerar o seleccionar de manera aislada del resto de la organización.


Más allá de estas consideraciones generales, existen cinco criterios específicos para la selección de proyectos:


1. El respaldo de los directivos de la organización.

2. Un periodo adecuado de compromiso para terminar el proyecto.
3. La posibilidad de mejorar la consecución de las metas organizacionales.
4. Factibilidad en cuanto a recursos para el analista de sistemas y la organización.
5. La rentabilidad del proyecto en comparación con otras formas en que la organización podría invertir sus recursos.

DETERMINACIÓN DE LA VIABILIDAD

La definición de viabilidad es mucho más profunda que la que se le da comúnmente, puesto que la viabilidad de los proyectos de sistemas se evalúa de tres maneras principales:


Operativa

Técnica

Económicamente

El estudio de viabilidad no consiste en un estudio completo de los sistemas. Más bien, se trata de recopilar suficientes datos para que los directivos, a su vez, tengan los elementos necesarios para decidir si debe procederse a realizar un estudio de sistemas.

Los datos para el estudio de viabilidad se pueden recopilar mediante entrevistas.
El tipo de entrevista apropiado se relaciona directamente con el problema o la oportunidad bajo análisis. Por lo general, el analista de sistemas entrevista a quienes requieren ayuda y a los involucrados en el proceso de toma de decisiones, que comúnmente son los directivos. Aunque es importante abordar el problema correcto, el analista de sistemas no debe invertir demasiado tiempo en los estudios de viabilidad, porque le solicitarán muchos proyectos y sólo unos cuantos podrán o deberán ser realizados. El tiempo dedicado al estudio de viabilidad deberá ser bastante reducido y abarcar diversas actividades.

DEFINICIÓN DE OBJETIVOS

Las mejoras a los sistemas se pueden definir como cambios que darán como resultado beneficios crecientes y valiosos. Las mejoras pueden ser de muchos tipos, por ejemplo:


1. Aceleración de un proceso.

2. Optimización de un proceso al eliminar pasos innecesarios o duplicados.
3. Combinación de procesos.
4. Reducción de errores en la captura de información mediante la modificación de formularios y pantallas de despliegue.
5. Reducción de almacenamiento redundante.
6. Reducción de salidas redundantes.
7. Mejora en la integración de sistemas y subsistemas.

Es importante que el analista de sistemas tenga habilidad para reconocer las oportunidades de mejora. Sin embargo, quienes están en contacto diario con el sistema podrían ser fuentes de información más eficaces sobre las mejoras por realizar. Si ya se han sugerido mejoras, son necesarios sus conocimientos como analista para contribuir a determinar si vale la pena la mejora y cómo se debe implementar.


También es importante la manera en que las mejoras a los sistemas de información afectan los objetivos corporativos. Estos objetivos incluyen:


1. Mejora de las ganancias corporativas.

2. Apoyo a la estrategia competitiva de la organización.
3. Mayor cooperación con distribuidores y socios.
4. Incremento del apoyo a las operaciones internas con el fin de producir bienes y servicios de manera más eficiente y eficaz.
5. Incremento del apoyo a la toma de decisiones internas para que éstas sean más eficaces.
6. Mejora del servicio al cliente.
7. Incremento en la moral de los empleados.

Una vez más, una cuadrícula de impacto de la viabilidad es útil para incrementar la conciencia de los impactos en el logro de los objetivos corporativos.


DETERMINACIÓN DE RECURSOS

La determinación de recursos para el estudio de viabilidad sigue el mismo patrón general.

El proyecto debe satisfacer tres criterios de viabilidad para pasar a una siguiente fase de desarrollo. Los recursos se analizan desde la perspectiva de tres áreas de viabilidad: técnica, económica y operativa.

Viabilidad técnica Gran parte de la determinación de recursos tiene que ver con la evaluación de la viabilidad técnica. El analista debe averiguar si es posible actualizar o incrementar los recursos técnicos actuales de tal manera que satisfagan los requerimientos bajo consideración.

Sin embargo, en ocasiones los "agregados" a los sistemas existentes son costosos y no redituables, simplemente porque no cumplen las necesidades con eficiencia. Si no es posible actualizar los sistemas existentes, la siguiente pregunta es si hay tecnología disponible que cumpla las especificaciones.

Viabilidad técnica

Agregados al sistema actual
Tecnología disponible para satisfacer las necesidades dé los usuarios :

Viabilidad económica
Tiempo de los analistas de sistemas
Costo del estudio de sistemas
Costo del tiempo que los empleados dedicarán al estudio
Costo estimado del hardware
Costo del software comercial o del desarrollo de software

Viabilidad operativa
El Sistema funcionara cuando se instale
El Sistema será utilizado


EVALUACIÓN DE LA VIABILIDAD

La evaluación de la viabilidad de los proyectos de sistemas nunca es una tarea sencilla o bien definida. La viabilidad de un proyecto no es una decisión a cargo del analista de sistemas sino de los directivos de la organización. Las decisiones se toman con base en los datos sobre viabilidad recopilados y presentados de una manera experta y profesional por el analista.

El analista de sistemas debe asegurarse de abordar en el estudio preliminar las tres áreas de viabilidad técnica, económica y operativa. El estudio de un proyecto de sistemas solicitado debe realizarse con rapidez con el fin de que los recursos que se dediquen a éste sean mínimos, la información arrojada por el estudio sea sólida y el interés hacia el proyecto siga vigente.
Por lo general, el proceso de evaluación de la viabilidad es útil para desechar los proyectos que se contraponen con los objetivos de la organización, que desde el punto de vista técnico no son factibles y que no ofrecen un aliciente económico. Aunque es muy laborioso, el estudio de la viabilidad vale la pena y al final ahorra a las empresas y los analistas de sistemas una considerable cantidad de tiempo y dinero.

PLANEACION Y CONTROL DE ACTIVIDADES

La administración de proyectos abarca las tareas generales de planeación y control.

La planeación incluye todas las actividades requeridas para seleccionar un equipo de análisis de sistemas, asignar miembros del equipo a proyectos adecuados, calcular el tiempo necesario para realizar cada tarea y programar el proyecto de tal manera que las tareas se terminen a tiempo. El control implica el uso de retroalimentación para monitorear el proyecto, incluyendo la comparación del plan original del proyecto con su evolución real. Además, el control significa emprender las acciones apropiadas para agilizar o reprogramar actividades para terminar en tiempo, a la vez que estimulen a los miembros del equipo a realizar el trabajo de manera profesional.

USO DE GRÁFICAS DE GANTT PARA LA PROGRAMACIÓN DE PROYECTOS

Una gráfica de Gantt es una forma fácil de programar tareas. En este tipo de gráfica las barras representan cada tarea o actividad. La longitud de cada barra representa la duración relativa de dicha tarea.

La principal ventaja de la gráfica de Gantt es su sencillez. El analista de sistemas esta técnica no sólo es fácil de utilizar, sino que también es adecuada para establecer una comunicación satisfactoria con los usuarios finales. Otra ventaja de utilizar la gráfica de Gantt es que las barras representan actividades o tareas a escala; es decir, el tamaño de las barras indica el tiempo relativo que tomará completar cada tarea.

USO DE DIAGRAMAS PERT

PERT es un acrónimo de Program Evaluation and Review Techniques (Técnicas de Evaluación y Revisión de Programas). Un programa (sinónimo de proyecto) se representa mediante una red de nodos y flechas que se evalúa para determinar las actividades críticas, mejorar la programación de fechas si es necesario y revisar el progreso una vez que se aborda el proyecto.

PERT es muy útil cuando las actividades se pueden hacer en paralelo en lugar de en secuencia.
El analista de sistemas se puede beneficiar con PERT al aplicarlo a los proyectos de sistemas en una escala más pequeña, especialmente cuando algunos miembros de un equipo pueden trabajar en ciertas actividades al mismo tiempo que otros miembros del mismo equipo trabajan en otras tareas.

PROGRAMACIÓN DE PROYECTOS POR COMPUTADORA

La programación de proyectos con ayuda de las computadoras se ha convertido en una tarea práctica y sencilla. Microsoft Project es un buen ejemplo de un programa muy eficaz.

La administración de proyectos de comercio electrónico
Es semejante en varios aspectos a la administración de proyectos tradicionales de sistemas de información, pero hay cuatro aspectos en los cuales difieren significativamente.
El primero es que los datos que usted tendrá que coordinar están dispersos por toda la organización (lo cual tiene implicaciones políticas); otro es que los miembros especializados del equipo se tienen que reclutar de todas las áreas de la organización (aquí también podrían verse implicadas las políticas de la organización); un tercer aspecto es que el gerente de un proyecto de comercio electrónico debe resaltar la integración estratégica del comercio electrónico con todos los sistemas de la organización, y el cuarto aspecto es que al establecer un sitio de comercio electrónico primero se deben abordar las cuestiones de seguridad.

miércoles, 3 de marzo de 2010

El estilo organizacional y su impacto en los sistemas de información cap 2

Los analistas de sistemas para poder analizar y diseñar un sistema de información deben visualizar las organizaciones en las que laboran como sistemas formados por las interacciones de tres fuerzas principales como lo son:
Los niveles de administración, el diseño de las organizaciones y las culturas de dichas organizaciones.
Las organizaciones pueden ser sistemas complejos que asu vez se puede componer de subsistemas que interconecten o sean independientes. Estos subsistemas se caracterizan por su entorno que va de un continuo abierto y cerrado. Por lo general es sistema abierto permite el libre transito de recursos (gente información material) al contrario de los sistemas cerrados o permiten que la información fluya de manera libre no existe entradas ni salidas.
Los analistas usan los diagramas de entidad-relación para comprender las entidades y sus relaciones , las cuales conforma el sistema organizacional. Estos diagramas so los que conforman el sistema organizacional ya que pueden describir relaciones uno a uno, uno a muchos y muchos a muchos.
Hay tres niveles de control administrativo:
* El operativo
* El nivel medio
* El estratégico
El tiempo para la toma de decisiones es distinto en cada nivel.
Culturas y subculturas detro de las organizaciones son factores importantes determinan la manera de cómo la gente utiliza la información asi como los sistemas de infrmacion.

jueves, 18 de febrero de 2010

capitulo 1 fundamentos del analisis de sistemas

Los sistemas de información se desarrollan con una diversidad de propósitos, dependiendo de las necesidades que tenga una empresa. Toda empresa cuenta con información que es considerada como un recurso, tiene una valiosa importancia, por lo que debe ser manejada con mucho cuidado. Para un mejor manejo y control de esta información, se requiere de ciertos sistemas de cómputo actualizados, que propicien un eficaz manejo de la información manejada en la empresa (ya sea en grandes o pocas magnitudes).


Existen diversidad de sistemas, entre los cuales podemos mencionar algunos:


*Sistemas de procesamiento de transacciones (TPS):
Son sistemas de información computarizada creadas para procesar grandes cantidades de datos relacionadas con transacciones rutinarias de negocios. Como por ejemplo: nominas y los inventarios. Los administradores recurren a los datos producidos por los TPS con el propósito de obtener información actualizada sobre el funcionamiento de sus empresas.


*Sistema de automatización de la oficina (OAS):
Apoyan a los trabajadores de datos, que analizan la información con el propósito de transformar los datos o manipularlos de alguna manera antes de compartirlos, o distribuirlos formalmente con el resto de la organización y en ocasiones más allá de ellas. Algunos de los componentes son: procesador de textos, hojas de calculo , la autoedición, la calendarización electrónica y las comunicaciones mediante correo de voz. Correo electrónico y videoconferencia.


*Sistema de trabajo de conocimiento (KWS):
Sirven de apoyo a los trabajadores profesionales, para nuevos conocimientos y compartirlos con sus organizaciones o con la sociedad.


*Sistemas de información gerencial (MIS):
Son sistemas de información, con el propósito de contribuir a la correcta interacción entre los usuarios y las computadoras. Es muy similar al sistema de procesamiento de transacciones que este sistema da apoyo a un espectro de tareas organizadas mucho más amplios. Para tener acceso ala información el sistema esta conectado a una base de datos común. Almacenan datos y modelos que ayudan al usuario a interpretar y aplicar los datos.

Existen algunos otros los cuales son sistemas orientados a la toma de decisiones como lo son:


*Sistemas de apoyo ala toma de decisiones en grupo (GDSS):
Puede ser una solución usar GDSS cuando usa los grupos requieren trabajar en conjunto para tomar decisiones semiestructuradas o no estructuradas. Casi siempre se usa con software especializado. Tienen el propósito de unir a un grupo en la búsqueda de la solución a un problema con la ayuda de diversas herramientas como los sondeos, los cuestionarios, la lluvia de ideas y la creación de escenarios.


*Sistemas de trabajo colaborativo apoyados por computadora (CSCWS)
Pueden contener un respaldo de un tipo de software denominado groupware para la colaboración en equipo a través de computadoras conectadas en red.


*Sistemas de apoyo a ejecutivos (ESS)
Ayudan a los ejecutivos a organizar sus actividades relacionadas con el entorno externo mediante herramientas graficas y de comunicaciones.
Algunas aplicaciones se originan para la ayuda al comercio electrónico (WEB).


El trabajo de los analistas es recomendar, diseñar y dar mantenimiento a diversos tipos de sistemas como los vistos anteriormente.


Dos de estos puntos (análisis y diseño) dan un enfoque para poder identificar problemas, oportunidades y objetivos, ayudan a realizar los flujos de información y de esa manera diseñar sistemas de información por computadora. De manera que puedan dar solución a los problemas que se presenten.



Un analista no solo se enfoca a desempeñar un trabajo dentro de su área si no que puede desempeñar diversos “roles”:


1.- Consultor externo para el negocio, puede ser una ventaja por la ideas nuevas que puede introducir ala empresa y una desventaja si la persona externa no conoce la verdadera cultura organizacional de la organización.


2.- Experto en el apoyo técnico dentro del negocio, no esta a cargo de ningún proyecto solo actúa como recursor para aquellos que si lo están.


3.- Agente de cambio en situaciones ya sean internas o externas es el mas completo y de mayor responsabilidad es el agente de cambio si desempeña cualquiera de las actividades relacionadas con el ciclo de vida del desarrollo del sistema.


Funciones del analista:
Detección de problemas. Debe dar soluciones factibles, debe ser hábil para mantener una buena comunicación, permitiendo relacionarse con diversas personas, saber manejar un sistema de computación.


Para que un sistema se lleve a cabo el analista debe tomar en cuenta un ciclo de vida del desarrollo de sistemas (SDLC). Puede dividirse en siete fases secuenciales:


Oportunidades y objetivos se enfoca a la Identificación del problema.


Determinación de los requerimientos de información


Análisis de las necesidades del sistema


Diseño de sistema recomendado


Desarrollo y documentación del software


Prueba y mantenimiento del sistema


Implementación y evaluación del sistema.


Muchos de estas faces interactúan y se relacionan de manera simultánea.
Existen paquetes de software automatizados, es decir de PC, para el análisis y diseño de sistemas estos son conocidos como herramientas de ingeniería de software asistida por computadora (CASE) existen razones para propiciar el uso de esta herramienta, como lo son: la posibilidad de realizar la planeación, análisis y diseño por medios graficos, con un propósito, permitir modelar los datos, procesos y objetivos en diferentes formatos. estas nos ayudan a incrementar la productividad del analista, mejorar la comunicación entre analista y usuarios, integrar actividades del siglo de vida, analizar y valorar el impacto de los cambios en el mantenimiento. Para ello se usan diversas herramientas sistematizadas (computarizadas) para el mejor rendimiento y eficacia de la utilización de los datos manejados en una organización.