Base de datos

Bases de datos

Definición de Base de datos

Almacén de datos relacionados con diferentes modos de organización. Una base de datos representa algunos aspectos del mundo real, aquellos que le interesan al diseñador. Se diseña y almacena datos con un propósito específico. Con la palabra "datos" se hace referencia a hechos conocidos que pueden registrarse, como ser números telefónicos, direcciones, nombres, etc.Las bases de datos almacenan datos, permitiendo manipularlos fácilmente y mostrarlos de diversas formas.

Características

Independencia lógica y física de los datos: se refiere a la capacidad de modificar una definición de esquema en un nivel de la arquitectura sin que esta modificación afecte al nivel inmediatamente superior. Para ello un registro externo en un esquema externo no tiene por qué ser igual a su registro correspondiente en el esquema conceptual.

Redundancia mínima: se trata de usar la base de datos como repositorio común de datos para distintas aplicaciones.

Acceso concurrente por parte de múltiples usuarios: control de concurrencia mediante técnicas de bloqueo o cerrado de datos accedidos.

Distribución espacial de los datos: la independencia lógica y física facilita la posibilidad de sistemas de bases de datos distribuidas. Los datos pueden encontrarse en otra habitación, otro edificio e incluso otro país. El usuario no tiene por qué preocuparse de la localización espacial de los datos a los que accede.

Integridad de los datos: se refiere a las medidas de seguridad que impiden que se introduzcan datos erróneos. Esto puede suceder tanto por motivos físicos (defectos de hardware, actualización incompleta debido a causas externas), como de operación (introducción de datos incoherentes).

Consultas complejas optimizadas: la optimización de consultas permite la rápida ejecución de las mismas.

Seguridad de acceso y auditoría: se refiere al derecho de acceso a los datos contenidos en la base de datos por parte de personas y organismos. El sistema de auditoría mantiene el control de acceso a la base de datos, con el objeto de saber qué o quién realizó una determinada modificación y en qué momento.

Respaldo y recuperación: se refiere a la capacidad de un sistema de base de datos de recuperar su estado en un momento previo a la pérdida de datos.

Acceso a través de lenguajes de programación estándar: se refiere a la posibilidad ya mencionada de acceder a los datos de una base de datos mediante lenguajes de programación ajenos al sistema de base de datos propiamente dicho.

Redundancia

Control sobre la redundancia de datos. 

Los sistemas de ficheros almacenan varias copias de los mismos datos en ficheros distintos. Esto hace que se desperdicie espacio de almacenamiento, además de provocar la falta de consistencia de datos. En los sistemas de bases de datos todos estos ficheros están integrados, por lo que no se almacenan varias copias de los mismos datos. Sin embargo, en una base de datos no se puede eliminar la redundancia completamente, ya que en ocasiones es necesaria para modelar las relaciones entre los datos, o bien es necesaria para mejorar las prestaciones.

Ventajas

Consistencia de datos.

Eliminando o controlando las redundancias de datos se reduce en gran medida el riesgo de que haya inconsistencias. Si un dato está almacenado una sola vez, cualquier actualización se debe realizar sólo una vez, y está disponible para todos los usuarios inmediatamente. Si un dato está duplicado y el sistema conoce esta redundancia, el propio sistema puede encargarse de garantizar que todas las copias se mantienen consistentes. Desgraciadamente, no todos los SGBD de hoy en día se encargan de mantener automáticamente la consistencia.

Más información sobre la misma cantidad de datos. Al estar todos los datos integrados, se puede extraer información adicional sobre los mismos.

Compartición de datos.

 En los sistemas de ficheros, los ficheros pertenecen a las personas o a los departamentos que los utilizan. Pero en los sistemas de bases de datos, la base de datos pertenece a la empresa y puede ser compartida por todos los usuarios que estén autorizados. Además, las nuevas aplicaciones que se vayan creando pueden utilizar los datos de la base de datos existente.

Mantenimiento de estándares. Gracias a la integración es más fácil respetar los estándares necesarios, tanto los establecidos a nivel de la empresa como los nacionales e internacionales. Estos estándares pueden establecerse sobre el formato de los datos para facilitar su intercambio, pueden ser estándares de documentación, procedimientos de actualización y también reglas de acceso

Componentes de una base de datos

· Datos del usuario. En la actualidad, casi todas las bases de datos representan los datos del usuario como afinidades que son tablas de datos. No todas las afinidades son igualmente deseables; algunas están mejor estructuradas que otras. Para crear afinidades bien estructuradas se realiza un proceso llamado normalización.

· Metadatos. Debido a que los productos DBMS están diseñados para almacenar y manipular tablas, la mayor parte de ellos almacenan los metadatos en forma de tablas, algunas veces llamadas tablas del sistema.

· Índices. Están encaminados a mejorar el funcionamiento y la accesibilidad de la base de datos. Se usan para ordenar y para obtener un acceso rápido a los datos. Los índices son muy valiosos pero implican un costo. Cada vez que se actualiza una fila en una afinidad o tabla, también deben actualizarse los índices. Esto no es malo; sólo significa que los índices no son gratuitos y que deben reservarse para casos en los que sean de verdad necesarios.

· Metadatos de aplicación. Se usan para almacenar la estructura y el formato de formas, reportes, consultas de usuarios, y otros componentes de aplicación. Normalmente no se accede de forma directa a los metadatos de aplicación sino que se hace a través de herramientas proporcionadas por el DBMS para tal fin.

Read More

Diagrama de flujo de datos

Diagrama de flujo de datos

Un diagrama de flujo de datos o DFD (sus siglas en español e inglés), se utiliza para hacer varias cosas entre ellas trabajos y tareas. Es una representación gráfica del flujo de datos a través de un sistema de información. Un diagrama de flujo de datos también se puede utilizar para la visualización de procesamiento de datos (diseño estructurado). Es una práctica común para un diseñador dibujar un contexto a nivel de DFD que primero muestra la interacción entre el sistema y las entidades externas.

Los diagramas de flujo de datos fueron inventados por Larry Constantine, el desarrollador original del diseño estructurado, basado en el modelo de computación de Martin y Estrin: "flujo gráfico de datos" . Los diagramas de flujo de datos (DFD) son una de las tres perspectivas esenciales de Análisis de Sistemas Estructurados y Diseño por Método SSADM. El patrocinador de un proyecto y los usuarios finales tendrán que ser informados y consultados en todas las etapas de una evolución del sistema. Con un diagrama de flujo de datos, los usuarios van a poder visualizar la forma en que el sistema funcione, lo que el sistema va a lograr, y cómo el sistema se pondrá en práctica. El antiguo sistema de diagramas de flujo de datos puede ser elaborado y se comparó con el nuevo sistema de diagramas de flujo para establecer diferencias y mejoras a aplicar para desarrollar un sistema más eficiente. Los diagramas de flujo de datos pueden ser usados para proporcionar al usuario final una idea física de cómo resultarán los datos a última instancia, y cómo tienen un efecto sobre la estructura de todo el sistema. La manera en que cualquier sistema es desarrollado, puede determinarse a través de un diagrama de flujo de datos.


Los niveles de un DFD son:

Nivel 0: Diagrama de contexto
Nivel 1: Diagrama de nivel superior
Nivel 2: Diagrama de detalle o expansión

Conexiones entre los elementos de un DFD

Conexiones permitidas

ENTIDAD - PROCESO
PROCESO - ALMACÉN

Conexiones prohibidas

ENTIDAD - ENTIDAD
ALMACÉN - ALMACÉN
ENTIDAD - ALMACÉN


Características de los niveles de un DFD

Diagrama de Contexto: Nivel 0
En el diagrama de contexto se caracterizan todas las interacciones que realiza un sistema con su entorno (entidades externas), estas pueden ser otros sistemas, sectores internos a la organización, o factores externos a la misma. Se dibuja un sólo proceso que representa al sistema en cuestión y se escribe su nombre en dicha burbuja como un sustantivo común más adjetivos. De él solamente parten los flujos de datos que denotan las interrelaciones entre el sistema y sus agentes externos, no admitiéndose otros procesos ni almacenamientos en el dibujo.

ya que estos son procesos estructurados y ordenados, además posee una cardinalidad que varia según la función que desempeñe cada diagrama
Resulta de gran utilidad para los niveles posteriores de análisis como herramienta de balanceo. Y es conocido como el Diagrama de Flujo de Datos DFD de Nivel "0".

Diagrama de Nivel Superior: Nivel 1
En el diagrama de nivel superior se plasman todos los procesos que describen al proceso principal. En este nivel los procesos no suelen interrelacionarse directamente, sino que entre ellos debe existir algún almacenamiento o entidad externa que los una. Esta regla de construcción sirve como ayuda al analista para contemplar que en un nivel tan elevado de abstracción (DFD Nivel 1) es altamente probable que la información que se maneja requiera ser almacenada en el sistema aunque no esté especificado por un Requisito funcional, siendo en realidad un requisito no-funcional.

Diagrama de Detalle o Expansión: Nivel 2
En un diagrama de nivel 3 o mayor, comienzan a explotarse las excepciones a los caminos principales de la información dado que aumenta progresivamente el nivel de detalle. De aquí en adelante se permiten los flujos entre procesos.

El DFD (Diagrama De Flujo De Datos) nivel 2 puede considerarse el máximo para ser validado en forma conjunta con el usuario dado que en los niveles posteriores el alto grado de complejidad del diagrama puede resultar de muy difícil lectura para personas ajenas al equipo de sistemas. También se recomienda el diagrama de nivel superior.

Read More

Fases de vida de un sistema

Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificación del problema, la segunda identificación de requisitos de información, la tercera es el análisis de las necesidades del sistema, la cuarta es el diseño del sistema recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y la última implementación y evaluación. Cada fase se explica por separado pero nunca se realizan como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse.

FASE I: Identificación de problemas, oportunidades y objetivos

Observación directa del entorno 

Aplicación de entrevista para recolectar información. 

Sintetizar la información recolectada para construir objetivos 

Estimar el alcance del proyecto 

Identificar si existe una necesidad, problema u oportunidad argumentada 

Documentar resultados 

Estudiar los riesgos del proyecto 

Presentar un informe de vialidad 

En la primera fase el analista es el encargado de identificar los problemas de la organización, detallarlos, examinar, evaluar las oportunidades y objetivos.

El analista debe identificar y evaluar los problemas existentes en la organización de manera critica y precisa. Mayormente los problemas son detectados por alguien más y es cuando el analista es solicitado a fin de precisarlos.

Las oportunidades son situaciones que el analista considera susceptibles de mejorar utilizando sistemas de información computarizados, lo cual le da mayor seguridad y eficacia a las organizaciones además de obtener una ventaja competitiva. El analista debe identificar los objetivos, es decir, el analista debe averiguar lo que la empresa trata de conseguir, se podrá determinar si algunas funciones de as aplicaciones de los sistemas de información pueden contribuir a que el negocio alcance sus objetivos aplicándolas a problemas u oportunidades específicos. Los usuarios, los analistas y los administradores de sistemas que coordinan el proyecto son los involucrados en la primera fase. Las actividades de esta fase son las entrevistas a los encargados de coordinar a los usuarios, sintetizar el conocimiento obtenido, estimar el alcance del proyecto y documentar los resultados. El resultado de esta fase en un informe de viabilidad que incluye la definición del problema y un resumen de los objetivos. La administración debe decidir si se sigue adelante o si se cancela el proyecto propuesto.

FASE II: Determinación de los requerimientos de información

Revisión de los objetivos 

Identificar el dominio 

Investigar la razón por la cual se implementa el sistema actual 

Recolectar información sobre los procedimientos y operaciones que se desempeñan actualmente.

Detallar específicamente: Quiénes son los involucrados, cuál es la actividad, regla y restricciones del negocio, entorno de desarrollo de las actividades, momentos oportunos de desarrollo de cada función, la manera en que se desempeñan los procedimientos actuales.

Elaborar una lista detallada y organizada de todos los procedimientos.

Separar requerimientos funcionales y no funcionales

Adicionar al informe de la primera fase, esta nueva información

En esta fase el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación 

de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar 

las decisiones y sus entornos e oficina, al igual que métodos de amplio alcance como la elaboración de prototipos.

Esta fase es útil para que el analista confirme la idea que tiene de la organización y sus objetivos.

Los implicados en esta fase son el analista y los usuarios, por lo general los trabajadores y gerentes del área de operaciones.

El analista necesita conocer los detalles de las funciones del sistema actual: 

el quién (la gente involucrada), el qué (la actividad del negocio), el dónde (el entorno donde se desarrollan las actividades), el cuándo (el momento oportuno) y el cómo (la manera en que se realizan los procedimientos actuales) del negocio que se estudia.

Al término de esta fase, el analista debe conocer el funcionamiento del negocio y poseer información muy completa acerca de la gente, los objetivos, los datos y los procedimientos implicados.

FASE III: Análisis de las necesidades

Evaluar las dos fases anteriores. 

Modelar las entradas, los procesos y las salidas de las funciones ya identificadas. 

Elaborar diccionario de datos y sus especificaciones. 

Elaborar diagramas de procesos de cada función. 

Elaborar propuesta del sistema con todos los diagramas de operaciones y de procesos. 

Realizar el análisis del riesgo sobre el realizado en las fases anteriores, tomando en cuenta el aspecto económico, técnico y operacional (estudio de factibilidad) 

Estimar en un diagrama de Gantt el tiempo que tomará desarrollar el sistema. 

En esta fase el analista evalúa las dos fases anteriores, usa herramientas y técnicas como el uso de diagramas de flujo de datos para graficar las entradas, los procesos y las salidas de las funciones del negocio en una forma gráfica estructurada. 

A partir de los diagramas de flujo de datos se desarrolla un diccionario de datos que enlista todos los datos utilizados en el sistema así como sus respectivas especificaciones.

El analista prepara en esta fase, una propuesta de sistemas que sintetiza sus hallazgos, proporciona un análisis de costo/beneficio de las alternativas y ofrece, en su caso, recomendaciones sobre lo que se debe hacer.

FASE IV: Diseño del sistema recomendado 

Evaluar las tres fases anteriores. 

Realizar el diseño lógico de todo el sistema. 

Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de información 

Elaborar el diseño de la base de datos. 

Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función. 

Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos. 

Producir los paquetes específicos de programas para los programadores. 

Elaborar una lista de las funciones genéricas y de las que será obligatorio crear. 

En esta fase el analista utiliza la información recopilada en las primeras fases para realizar el diseño lógico del sistema de información.

El analista diseña procedimientos precisos para la captura de datos que aseguran que los datos que ingresen al sistema de información sean correctos.

Facilita la entrada eficiente de datos al sistema de información mediantes técnicas adecuadas de diseño de formularios y pantallas.

La concepción de la interfaz de usuario forma parte del diseño lógico del sistema de información. 

La interfaz conecta al usuario con el sistema y por tanto es sumamente importante.

También incluye el diseño de archivos o bases de datos que almacenarán gran parte delos datos indispensables para los encargados de tomar las decisiones en la organización. 

En esta fase el analista interactúa con los usuarios para diseñar la salida (en pantalla o impresa) que satisfaga las necesidades de información de estos últimos.

Finalmente el analista debe diseñar controles y procedimientos de respaldo que protejan al sistema y a los datos y producir paquetes de especificaciones de programa para los programadores. 

Cada paquete debe contener esquemas para la entrada y la salida, especificaciones de archivos y detalles del procesamiento. 

FASE V: Desarrollo y documentación del software 

Evaluar los procedimientos que va a ser desarrollados por el programador. 

Mostrar y explicar cada procedimiento, función y operación al programador. 

Elaborar manuales de procedimientos internos del sistema. 

Elaborar manuales externos de ayuda a los usuarios del sistema. 

Elaborar demostraciones para los usuarios y la interacción con distintas interfaces 

Elaborar actualizaciones para los diferentes procedimientos 

Elaborar un informe con el tiempo que se llevó construir cada procedimiento. 

En la quinta fase del ciclo del desarrollo de sistemas, el analista trabaja de manera conjunta con los programadores para desarrollar cualquier software original necesario. Entre las técnicas estructuradas para diseñar y documentar software se encuentran los diagramas de estructuras, los diagramas de Nassi-Shneiderman y el pseudocódigo.

Durante esta fase el analista trabaja con los usuarios para desarrollar documentación efectiva para el software, como manuales de procedimientos, ayuda en línea y sitios web que incluyan respuestas a preguntas frecuentes en archivos “léame” que se integrarán al nuevo software.

La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso.

Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo.

FASE VI: Prueba y mantenimiento del sistema 

Realizar la programación de las pruebas del sistema. 

Realizar un instrumento para evaluar el sistema de información. 

El programador deberá elaborar un resumen de las pruebas del sistema. 

El analista deberá realizar un informe de sus pruebas y discutirlo con el programador 

Elaborar la planificación de las horas del mantenimiento del sistema. 

Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos

Antes de poner en funcionamiento el sistema es necesario probarlo es mucho menos costoso encontrar los problemas antes que el sistema se entregue a los usuarios.

Una parte de la pruebas la realizan los programadores solos, y otra la llevan a cabo de manera conjunta con los analistas de sistemas. Primero se realizan las pruebas con datos de muestra para determinar con precisión cuáles son los problemas y posteriormente se realiza otra con datos reales del sistema actual.

El mantenimiento del sistema de información y su documentación empiezan en esta fase y se llevan de manera rutinaria durante toda su vida útil. 

FASE VII: Implementación y evaluación del sistema

Planificar gradualmente la conversión del sistema anterior. 

Instalar los equipos de hardware necesarios para el funcionamiento del software creado. 

Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados 

Evaluar la adaptabilidad de los usuarios al sistema.

Esta es la última fase del desarrollo de sistemas, y aquí el analista participa en la implementación del sistema de información. En esta fase se capacita a los usuarios en el manejo del sistema. Parte de la capacitación la imparten los fabricantes, pero la supervisión de ésta es responsabilidad del analista de sistemas.

Se menciona la evaluación como la fase final del ciclo de vida del desarrollo de sistemas principalmente en áreas del debate. En realidad, la evaluación se lleva a cabo durante cada una de las fases.

El trabajo de sistemas es cíclico, cuando un analista termina una fase del desarrollo de sistemas y pasa a la siguiente, el surgimiento de un problema podría obligar a regresar a la fase previa y modificar el trabajo realizado.

Read More

Roles Del Ingeniero Analisita

Rol Del Ingeneniero En Sistema Como Analista

TIPOS DE SISTEMAS 

Los sistemas de información se desarrollan con diversos propósitos, según las necesidades de la empresa. Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) funcionan al nivel operativo de una organización, los sistemas de automatización de la oficina (OAS, Office Automañon Systems) y los sistemas de trabajo del conocimiento (KWS, Knowledge Work Systems) apoyan el trabajo al nivel del conocimiento. Los sistemas de información gerencial (MIS, Management Information Systems) y los sistemas de apoyo a la toma de decisiones (DSS, Decisión Support Systems) se encuentran entre los sistemas de alto nivel. Los sistemas expertos aplican el conocimiento de los encargados de la toma de decisiones para solucionar problemas estructurados específicos. Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) se encuentran en el nivel estratégico de la administración. Los sistemas de apoyo a la toma de decisiones en grupo (GDSS, Group Decisión Support Systems) y los sistemas de trabajo corporativo apoyados por computadora (CSCWS, Computer-Supported Collaborative Work Systems), descritos de manera más general, auxilian la toma de decisiones semiestructuradas o no estructuradas a nivel de grupo. En la figura 1.1 se muestra la diversidad de sistemas de información que podrían desarrollar los analistas. Observe que en la figura estos sistemas se representan de abajo hacia arriba, indicando que los TPS apoyan el nivel operativo, o más bajo, de la organización, mientras que los ESS, GDSS y CSCWS soportan el nivel estratégico, o más alto, apoyando la toma de decisiones semiestructuradas o las no estructuradas. En este libro se emplean de manera indistinta los términos sistemas de información gerencia!, sistemas de información (IS, Information Systems), sistemas de información computarizados y sistemas de información de negocios computarizados, para denotar sistemas de información computarizados que apoyan el rango de actividades de negocios más amplio mediante la información que producen. 

SISTEMAS DE PROCESAMIENTO DE TRANSACCIONES

Los sistemas de procesamiento de transacciones (TPS, Transaction Processing Systems) son sistemas de información computarizada creados para procesar grandes cantidades de datos relacionadas con transacciones rutinarias de negocios, como las nóminas y los inventarios. Un TPS elimina el fastidio que representa la realización de transacciones operativas necesarias y reduce el tiempo que una vez fue requerido para llevarlas a cabo de manera manual, aunque los usuarios aún tienen que capturar datos en los sistemas computarizados. Los sistemas de procesamiento de transacciones expanden los límites de la organización dado que le permiten interactuar con entornos externos. Es importante para las operaciones cotidianas de un negocio, que estos sistemas funcionen sin ningún tipo de interrupción, puesto que 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. 

SISTEMAS DE AUTOMATIZACIÓN DE LA OFICINA Y SISTEMAS DE TRABAJO DEL CONOCIMIENTO 

Existen dos clases de sistemas en el nivel del conocimiento de una organización. Los sistemas de automatización de la oficina [OAS, Office Automation Systems] apoyan a los trabajadores de datos, quienes por lo general no generan conocimientos nuevos, sino más bien analizan la información con el propósito de transformar los datos o manipularlos de alguna manera antes de compartirlos o, en su caso, distribuirlos formalmente con el resto de la organización y en ocasiones más allá de ésta. Entre los componentes más comunes de un OAS están el procesamiento de texto, las hojas de cálculo, la autoedición, la calendarización electrónica y las comunicaciones mediante correo de voz, correo electrónico y videoconferencia. Los sistemas de trabajo del conocimiento (KWS, Knowledge Work Systems] sirven de apoyo a los trabajadores profesionales, como los científicos, ingenieros y médicos, en sus esfuerzos de creación de nuevo conocimiento y dan a éstos la posibilidad de compartirlo con sus organizaciones o con la sociedad.

SISTEMAS DE INFORMACIÓN GERENCIAL

Los sistemas de información gerencial (MIS, Management Information Systems] no reemplazan a los sistemas de procesamiento de transacciones, más bien, incluyen el procesamiento de transacciones. Los MIS son sistemas de información computarizados cuyo propósito es contribuir a la correcta interacción entre los usuarios y las computadoras. Debido a que requieren que los usuarios, el software [los programas de cómputo] y el hardware (las computadoras, impresoras, etc.), funcionen de manera coordinada, los sistemas de información gerencial dan apoyo a un espectro de tareas organizacionales mucho más amplio que los sistemas de procesamiento de transacciones, como el análisis y la toma de decisiones. Para acceder a la información, los usuarios de un sistema de información gerencial comparten una base de datos común. Ésta almacena datos y modelos que ayudan al usuario a interpretar y aplicar los datos. Los sistemas de información gerencial producen información que se emplea en la toma de decisiones. Un sistema de información gerencial también puede contribuir a unificar algunas de las funciones de información computarizadas de una empresa, a pesar de que no existe como una estructura individual en ninguna parte de ésta. 

SISTEMAS DE APOYO A LA TOMA DE DECISIONES

Los sistemas de apoyo a la toma de decisiones (DSS, Decisión Support Systems] constituyen una clase de alto nivel de sistemas de información computarizada. Los DSS coinciden con los sistemas de información gerencial en que ambos dependen de una base de datos para abastecerse de datos. Sin embargo, difieren en que el DSS pone énfasis en el apoyo a la toma de decisiones en todas sus fases, aunque la decisión definitiva es responsabilidad exclusiva del encargado de tomarla. Los sistemas de apoyo a la toma de decisiones se ajustan más al gusto de la persona o grupo que los utiliza que a los sistemas de información gerencial tradicionales. En ocasiones se hace referencia a ellos como sistemas que se enfocan en la inteligencia de negocios. 

SISTEMAS EXPERTOS E INTELIGENCIA ARTIFICIAL

La inteligencia artificial (AI, Artificial Intelligence] se puede considerar como el campo general para los sistemas expertos. La motivación principal de la AI ha sido desarrollar máquinas que tengan un comportamiento inteligente. Dos de las líneas de investigación de la AI son la comprensión del lenguaje natural y el análisis de la capacidad para razonar un problema hasta su conclusión lógica. Los sistemas expertos utilizan las técnicas de razonamiento de la AI para solucionar los problemas que les plantean los usuarios de negocios (y de otras áreas]. Los sistemas expertos conforman una clase muy especial de sistema de información que se ha puesto a disposición de usuarios de negocios gracias a la amplia disponibilidad de 

EL ROL DEL ANALISTA DE SISTEMAS

hardware y software como computadoras personales (PCs) y generadores de sistemas expertos. Un sistema experto [también conocido como sistema basado en el conocimiento) captura y utiliza el conocimiento de un experto para solucionar un problema específico en una organización. Observe que a diferencia de un DSS, que cede al responsable la toma de la decisión definitiva, un sistema experto selecciona la mejor solución para un problema o una clase específica de problemas. Los componentes básicos de un sistema experto son la base de conocimientos, un motor de inferencia que conecta al usuario con el sistema mediante el procesamiento de consultas realizadas con lenguajes como SQL [Structured Query Language, lenguaje de consultas estructurado) y la interfaz de usuario. Profesionales conocidos como ingenieros de conocimiento capturan la pericia de los expertos, construyen un sistema de cómputo que contiene este conocimiento experto y lo implementan. Es muy factible que la construcción e implementación de sistemas expertos se constituya en el trabajo futuro de muchos analistas de sistemas. 

SISTEMAS DE APOYO A LA TOMA DE DECISIONES EN GRUPO Y SISTEMAS DE TRABAJO COLABORATIVO APOYADOS POR COMPUTADORA

Cuando los grupos requieren trabajar en conjunto para tomar decisiones semiestructuradas o no estructuradas, un sistema de apoyo a la toma de decisiones en grupo (GDSS, Group Decisión Support System) podría ser la solución. Este tipo de sistemas, que se utilizan en salones especiales equipados con diversas configuraciones, faculta a los miembros del grupo a interactuar con apoyo electrónico —casi siempre software especializado— y la asistencia de un facilitador especial. Los sistemas de apoyo a la toma de decisiones en grupo 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. El software GDSS puede diseñarse con el fin de minimizar las conductas negativas de grupo comunes, como la falta de participación originada por el miedo a las represalias si se expresa un punto de vista impopular o contrario, el control por parte de miembros elocuentes del grupo y la toma de decisiones conformista. En ocasiones se hace referencia a los GDSS con el término más general sistemas de trabajo colaborativo apoyados por computadora (CSCWS, Computer-Supported Collaborative Work Systems], que pueden contener el 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

Cuando los ejecutivos recurren a la computadora, por lo general lo hacen en busca de mé- todos que los auxilien en la toma de decisiones de nivel estratégico. Los sistemas de apoyo a ejecutivos (ESS, Executive Support Systems) ayudan a estos últimos a organizar sus actividades relacionadas con el entorno externo mediante herramientas gráficas y de comunicaciones, que por lo general se encuentran en salas de juntas o en oficinas corporativas personales. A pesar de que los ESS dependen de la información producida por los TPS y los MIS, ayudan a los usuarios a resolver problemas de toma de decisiones no estructuradas, que no tienen una aplicación específica, mediante la creación de un entorno que contribuye a pensar en problemas estratégicos de una manera bien informada. Los ESS amplían y apoyan las capacidades de los ejecutivos al darles la posibilidad de comprender sus entornos.

Bibliography:Kendall, K. E., Kendall, J. E., Ramos, A. N., & Kendall (2005). Analisis y Diseno de Sistemas - 6b: Edicion (6th ed.). United States: Pearson Educacion.In-line Citation:(Kendall, Kendall, Ramos, & Kendall, 2005)

Read More

DISEÑAR UNA SALIDA EFICAZ

DISEÑO DE LA SALIDA PARA SATISFACER UN PROPÓSITO ESPECÍFICO

Toda la salida debe tener un propósito. No es suficiente poner a disposición de los usuarios un informe, una pantalla o una página Web sólo porque la tecnología permite hacerlo. Durante la fase de determinación de los requerimientos de información, el analista de sistemas averigua qué propósitos se deben satisfacer. A continuación diseña la salida con base en esos propósitos. Usted verá que tiene numerosas oportunidades de proporcionar salida simplemente porque la aplicación le permite hacerlo. Sin embargo, recuerde la regla del propósito. Si la salida no es funcional, no debe crearse, porque toda salida del sistema representa costos de tiempo y recursos

.

DISEÑO DE SALIDA PARA SATISFACER AL USUARIO

En un sistema de información grande que atiende a muchos usuarios con muchos propósitos diferentes, a menudo es difícil personalizar la salida. Con base en las entrevistas, las observaciones, los costos y tal vez los prototipos, será posible diseñar una salida que satisfaga lo que muchos usuarios, si no es que todos, necesitan y prefieren. En términos generales, es más práctico crear salida específica para el usuario, o que él pueda personalizar, cuando ésta se diseña para un sistema de apoyo a la toma de decisiones u otras aplicaciones sumamente interactivas, como las que se desarrollan para la Web. Sin embargo, aun así es posible diseñar salidas que satisfagan una función del usuario en la organización, lo cual nos lleva al siguiente objetivo. 

ENTREGA DE LA CANTIDAD ADECUADA DE SALIDA 

Más no siempre es mejor, en particular cuando se trata de la cantidad de salida. La decisión sobre qué cantidad de salida es correcta para los usuarios forma parte de la tarea del diseño de la salida. Un heurístico útil consiste en que el sistema debe proporcionar lo que cada persona necesita para completar su trabajo. Sin embargo, esta respuesta aún está lejos de ser una solución total, porque podría ser conveniente desplegar un subconjunto de esa información al principio y después proporcionar al usuario una manera de acceder fácilmente a información adicional. El problema referente a la sobrecarga de información es tan predominante que se ha vuelto un cliché, pero sigue siendo una preocupación válida. No se le da un buen servicio a nadie si se ofrece información excesiva sólo para hacer alarde de las capacidades del sistema. Siempre tenga en cuenta a los tomadores de decisiones. A menudo ellos no necesitarán grandes cantidades de salida, especialmente si hay una manera fácil de acceder a más información a través de algún hipervínculo o una característica de extracción de información. 

ASEGÚRESE DE QUE LA SALIDA ESTÉ DONDE SE NECESITA

A menudo la salida se produce en un lugar [por ejemplo, en el departamento de procesamiento de datos) y después se distribuye al usuario. El aumento de la salida en línea, desplegada en pantalla, que se puede acceder de manera individual, ha reducido en parte el problema de la distribución, pero la distribución apropiada continúa como un objetivo primordial para el analista de sistemas. Para que sea usada y que sirva de algo, la salida se debe presentar al usuario correcto. No importa qué tan bien diseñados estén los informes, si no llegan a los tomadores de decisiones que los requieren, no tienen valor. 

SUMINISTRO DE LA SALIDA A TIEMPO 

Una de las quejas más comunes de los usuarios es que no reciben la información a tiempo para tomar las decisiones necesarias. Aunque el tiempo no lo es todo, representa una parte importante de la utilidad que tendrá la salida para los tomadores de decisiones. Muchos informes son requeridos en forma diaria, algunos sólo mensualmente, otros anualmente y otros pocos sólo de manera ocasional. El uso de salida bien publicada y basada en la Web también puede solucionar en parte el problema de la distribución a tiempo de la salida. La entrega a tiempo de la salida puede ser crucial para las operaciones de negocios.

ELECCIÓN DEL MÉTODO DE SALIDA CORRECTO

Como se mencionó antes, la salida puede tomar muchas formas, incluyendo informes impresos, información en pantalla, audio con sonidos digitalizados que simulan la voz humana, microformas y documentos Web. Elegir el método de salida correcto para cada usuario es otro de los objetivos que deben tomarse en el diseño. En la actualidad, gran parte de la salida aparece en las pantallas de las computadoras y los usuarios tienen la opción de imprimirla con su propia impresora. El analista necesita reconocer los pros y contras al elegir un método de salida. Los costos difieren; para el usuario, también hay diferencias en la accesibilidad, flexibilidad, durabilidad, distribución, posibilidades de almacenamiento y recuperación, transportabilidad e impacto global de los datos. Por lo general, la elección de los métodos de salida no se debe tomar a la ligera, ni tampoco se puede determinar de antemano.

Bibliography:Kendall, K. E., Kendall, J. E., Ramos, A. N., & Kendall (2005). Analisis y Diseno de Sistemas - 6b: Edicion (6th ed.). United States: Pearson Educacion.In-line Citation:(Kendall, Kendall, Ramos, & Kendall, 2005)

Read More