para tesis - frlp.utn.edu.ar sobre sistemas.pdf · su génesis se remonta a la teoría general de...

360° sobre sistemas

Habilitación Profesional Mag. Carlos Alberto López 1

360° SOBRE SISTEMAS

La presente contribución pretende realizar una síntesis del marco teórico que

debe asociarse a la buena práctica profesional cuando se encara un sistema de

información.

Asimismo, considero que brinda un conjunto de recomendaciones para acometer

con éxito la tarea antes mencionada y es fruto de la experiencia, intentando que en vez

de desperdiciar tiempo tropezando con las piedras que ya otros tropezamos, empleen ese

tiempo en diseñar mejores y más poderosas soluciones.

360°, una vuelta completa en el

plano, también en el espacio si el rumbo

es constante, por ende, en algún

momento (saben cuando?) volveremos a

ver lo mismo.

Pero si nos vamos trazando nuevos rumbos, que imaginan que iremos viendo?.

Más aún, alguna vez volveremos a ver lo mismo o iremos descubriendo nuevas

facetas?

Si le interesa la respuesta, elija un rumbo en la página 45, de allí en más...

(Si se pierde, no hay problemas, sepa que estamos a su lado)



1. SISTEMA ORGANIZACIÓN

Toda organización moderna, analizada como un sistema, permite reconocer en ella

tres elementos fundamentales:

Cultura.

Integrantes o miembros. (Nuestro caso particular, restringe el conjunto de

miembros al subconjunto de usuarios del Sistema de Información.)

Sistemas de Información.

1.1. Cultura de la Organización

Valores, símbolos, héroes, rituales y actividades componen la denominada

“cultura institucional”.

Algunos autores sobre este particular, hacen referencia al denominado “Iceberg

organizacional”, que se compone de aspectos formales fácilmente observables y

otros informales, que son componentes ocultos de origen afectivo.

Dentro de cada uno de ellos, podemos destacar los siguientes:

Aspectos formales:

Meta – objetivos.

Estructura de la organización.

Políticas y procedimientos.

Recursos financieros.

Tecnología.

Productos.

Aspectos informales:

Percepciones (*).

Actitudes (*).

Sentimientos (*).

Valores.

Interacciones.

Normas grupales.

(*) estos tres aspectos se tienen tanto para personas como para grupos.

1.2. Sistemas de Información

Su génesis se remonta a la Teoría General de Sistemas, enunciada y descripta

por Ludwig von Bertalanffy1 a partir de 1924, a quien, a partir de 1947 se lo

considera su creador, si bien contribuyeron a la misma un gran conjunto de

1 Bertalanffy L., “General System Theory, Foundations, Development, Applications, Ed. Brazilian, 1968.



científicos provenientes de varias disciplinas.

El advenimiento de la era cibernética halló otros mentores para esta teoría

quienes se encargaron de acercarla más a los objetivos de la información, entre

ellos, podemos citar a Russel Ackoff2, Klir

3, Herbert Simon

4, Norbert Wiener

5 y

Shannon6.

1.2.1. Definiciones de Sistemas de Información

Existen varias definiciones contribuyentes de “Sistema de Información”.-

Según Börge Langefors7, “Sistema de Información es un sistema de conjuntos

de información necesarios para la decisión y el señalamiento en un sistema más

amplio (del que es un subsistema), que contiene subsistemas para recolectar,

almacenar, procesar y distribuir conjuntos de información.”

James Senn8 define Sistema de Información como “Sistema de negocios de una

empresa con propósitos de interacción con otros componentes de la compañía.

Su tarea consiste en procesar la entrada, mantener los archivos de datos en

relación con la empresa y producir información, informes y otras salidas”.

Mi amigo, Carlos Tomassino9 entiende que “un Sistema de Información es una

entidad conceptual, consistente en un conjunto de tareas que se relacionan con

un fin predeterminado de obtener información clara, precisa, confiable y

oportuna, para el planeamiento, la conducción y la toma de decisiones de una

organización.”

Laudon10

refiere que “Los sistemas de información son más que

computadoras. El uso eficaz de los sistemas de información implica entender

sobre organización, administración y la tecnología de la información que da

forma a los sistemas. Todos los sistemas de información pueden describirse

como soluciones institucionales y de administración a los retos del entorno.”,

más adelante en la misma obra, define: “Un sistema de información puede

2 Ackoff R., “Theory of communication. Management science”, 1958.

3 Klir G. “Teoría General de Sistemas”, Fondo de Cultura Económica, México, 1960.

4 Simon H., “The new science of Management Decisions”, Ed. Harper, 1960.

5 Wiener N., “Cybernetics”, Ed. John Wiley, New “Cybernetics”, Ed. John Wiley, New York, 1948.

6 Shannon C. y Weaver W., “The mathematical Theory of Communications”, Ed. Urbana, Illinois, 1949.

7 Langefors B., “Theoretical Analysis of Information Systems”, Ed. El Ateneo, Bs. As., 1982.

8 Senn J., “Análisis y Diseño de Sistemas de Información “, Ed. Mc.Graw-HiIl, 1987.

9 Tomassino C. y Casanovas I., “El Proyecto Informático”, Ed. IARA, Bs. As., 2000.

10 Laudon, K., “Administración de los Sistemas de Información”, 3ra. Ed., Prentice Hall, México, 1996.



definirse técnicamente corno un conjunto de componentes interrelacionados

que permiten capturar, procesar, almacenar y distribuir la información para

apoyar la toma de decisiones y el control en una institución. Además, para

apoyar a la toma de decisiones, la coordinación y el control, los sistemas de

información pueden también ayudar a los administradores y al personal a

analizar problemas, visualizar cuestiones complejas y crear nuevos productos.”

Aclara: “Alimentación o (insumo): Captura o recolección de datos primarios

dentro de la institución o de su entorno para procesarlos en un sistema de

información. Procesamiento: Conversión del mismo en forma que sea más

comprensible para los seres humanos. Producto o (salida): Distribución de

información procesada a personas o en las actividades en donde será usada.”

Andreu11

y sus colaboradores, definen los Sistemas de Información como “e1

conjunto integrado de procesos, principalmente formales, desarrollados en un

entorno usuario-ordenador, que operando sobre un conjunto de datos

estructurados de acuerdo con las necesidades de una organización, recopilan,

elaboran y distribuyen selectivamente la información necesaria para la

operatividad habitual de la organización y las actividades propias de la

dirección en la misma”.

Trazando un diagrama de Venn, bajo la idea percibida que “sistema es

sinónimo de orden, arreglo, plan, método...”12

, el subconjunto intersección

contendrá:

Organización.

Necesidades.

Acciones vinculadas a los datos y la información: Recolección,

Almacenamiento, Procesamiento y Distribución.

1.2.2. Tipos de Sistemas de Información

De las definiciones precedentes se aprecia que, bajo la denominación genérica

“Sistemas de Información”, se persiguen diversos objetivos informacionales,

tendientes a satisfacer diferentes niveles de necesidades o propósitos.

11

Andreu, Ricart y Valor, “Estrategia y Sistemas de Información”, Ed. Mc.Graw-HiIl, 2da. Edición, 1991 12

Tomassino et al., op. cit.



En este sentido y de acuerdo con los propósitos a cubrir, según Kendall13

se

desarrollan:

Sistemas de Procesamiento de Datos. (SPD/DPS)

Sistemas de Información para la Administración. (SIA/MIS)

Sistemas de Apoyo a la Toma de Decisiones (SAD/DDS)

A continuación se presenta una breve caracterización de cada uno de ellos,

adicionando ejemplos ligados a nuestro accionar:

1.2.2.1. Sistemas de Procesamiento de Datos: (SPD / DPS)

Se ejecutan periódicamente.

Liberan a sus usuarios de las rutinas.

Solo se toman decisiones si es necesario modificar el algoritmo de cálculo.

Importa la calidad del dato.

Ejemplos:

Procesamiento de notas.

Determinación de la cantidad de aplazados por materia.

Cambio en la modalidad de cálculo de la nota final sobre la base de

notas de oportunidad, de exámenes parciales y finales en

modalidades de promoción sin exámenes finales.

1.2.2.2. Sistemas de Información para la Administración: (SIA / MIS)

Toman en cuenta lo producido por los DPS.

Generan información para los DDS.

Ejemplos:

Generación el calendario de las mesas de exámenes de acuerdo

con la cantidad de alumnos aplazados por materia, adicionando

uno o más criterios (materias más difíciles, disponibilidad de

profesores, disponibilidad de más tiempo para el período de

estudio libre y exámenes, intercalación de materias fáciles con

difíciles). Es dable comprobar que, diversas combinaciones de las

variables enunciadas, darán por resultado diferentes opciones.

13

Kendall, op.cit.



Diseño del esquema de clases de apoyo de acuerdo con el

calendario adoptado para las mesas de exámenes finales.

1.2.2.3. Sistemas de Soporte a la Toma de Decisiones (SSD / DDS)

Similar a los anteriores pero brindando marco de soporte a las decisiones.

Ejemplos:

A partir de la cantidad de aplazados por materia, buscar

antecedentes de los alumnos en materias afines, analizar resultados

de temas fallidos, explorar recursos temporales y/o presupuestarios

adicionales y con todo ello, decidir esquema y contenido de clases

de apoyo.

Esto es importante al demostrar que el procesamiento del mismo conjunto de

datos permite satisfacer diversos requerimientos, independientemente de su

naturaleza, de allí que, algunos autores consideran que los DDS deben

diseñarse para “personas” y no para “objetivos predeterminados”, queriendo

resaltar la particular interrelación entre usuario y sistema.

1.2.3. Interrelación entre los tipos de Sistemas de Información DPS, MIS y DSS

Lo anteriormente expresado, demuestra que existen diferentes interrelaciones

entre los distintos tipos de Sistemas de Información, pudiendo apreciarse en la

siguiente figura:

Figura 1.1. Relaciones entre tipos de Sistemas de Información

PROCESAMIENTO DE DATOS

MIS DSS



Otra visión de clasificación de los tipos de sistemas es la aportada por

Anthony14

quien expresa: “Como existen intereses, especialidades y niveles

diferentes en una institución, existen también distintos tipos de sistemas”.

A partir de esta definición, según el nivel a quienes están dirigidos, Laudon15

los agrupa según la siguiente tabla:

TIPO DE SISTEMAS GRUPO SERVIDO NIVEL

Soporte gerencial (SSG / GSS)

Directores o

administradores de

nivel superior.

ESTRATÉGICO

Inform. para la administración (SIA / MIS)

Soporte a decisiones (SSD / DSS)

Gerentes o

administradores

medios.

ADMINISTRACIÓN

Trabajo del conocimiento (STC / KWS)

Automatización de oficinas (SAO / OAS)

Trabajadores del

conocimiento y la

información.

CONOCIMIENTO

Procesamiento de operaciones (SPO /OPS) Gerentes operativos. OPERATIVO

Tabla 1.1. Relación entre sistemas, grupos servidos y nivel.

A efectos de integrar conceptos, utilizando las siglas en castellano, sin

perjuicio que se usen indistintamente en castellano o inglés a lo largo del

presente trabajo, hemos resuelto integrar ambas visiones en la siguiente tabla:

AUTOR EQUIVALENCIA ENTRE CLASIFICACIONES

KENDALL SSD SIA SPD

LAUDON SSG SSD SIA STC SAO SPO

Tabla 1.2. Equivalencia entre clasificaciones de sistemas.

1.2.4. Interrelación entre Soporte Físico y Lógico

Los Sistemas de Información que gestionan la transformación de los datos en

información, deben hallar su soporte natural en alguna Red Informática.

14

Anthony, R. “Planning and control systems: A framework for analysis”, Harvard U. Press, Cambrigde,

MA,1965.



Figura 1.2. Relación entre soportes.

Existe una prelación o criterio de orden en cuanto a que cada bloque es

soportado por el anterior.

2. FASES EN LA SOLUCION DE PROBLEMAS

Según Frischnecht,16

“La solución de problemas es una interpretación pragmática,

prescriptiva del lenguaje natural, destinada a diseñar un proceso”.

Según Simon,17

las fases reconocibles en este proceso son:

Análisis (identificación de oportunidades o problemas o más concisamente,

según Graham,18

“Obtención y descripción del dominio del problema” o según

Gerez Greiser19

, “¿Cuál es el problema?”)

Diseño (generación de alternativas de solución o, según Gerez Greiser “¿Cuáles

son las alternativas?”)

Selección de solución, según Gerez Greiser, “¿Cuál es la mejor?”, pudiendo

incluir la implantación de la selección realizada.

El tránsito desde la detección de un problema hasta su resolución o disolución, que

incluye estas tres grandes etapas, merece algunas reflexiones que ayudarán a

minimizar errores o desalineamientos entre el problema y la solución implantada.

La primera etapa, el análisis, comprende algunas más sutiles como son la idea que

15

Laudon, op. cit. 16

Frischnecht, F., “Dirección recursiva”, El Ateneo, Buenos Aires, 1993. 17

Simon, H., “The shape of Automation for Men and Management”, Harper & Row, New York, 1965. 18

Graham, Ian, “Métodos Orientados a Objetos”, Addison-Wesley Iberoamericana, Wilmington, 1996. 19

Gerez Greiser et al., “Desarrollo y adm. de programas de computadoras”, Continental, México,1984.

RED INFORMATICA

DATOS

INFORMACION



nos hacemos del mismo y la idea que nos formaremos para su solución. Además de

las consabidas preguntas “¿Que?, ¿Porque? y ¿Para que?”, debiéramos incluir “¿Es

realmente así?, „Porque el actor tal adopta una posición tan irreducible?”, “¿Existen

objetivos ulteriores no declarados?” y tantas otras del mismo tenor, de modo tal que

no debiera trasponerse esta etapa sin haber disipado todas estas dudas, cuyas

respuestas, en definitiva, constituirán el marco de alcance o dominio del problema

real y por ende, de su solución.

La segunda, el diseño del campo de posibles soluciones, va muy de la mano de la

capacidad de análisis y síntesis del analista, reconocer que problemas de distintas

apariencias, enunciaciones o génesis tienen soluciones conceptualmente iguales,

demanda conocimientos profundos de las disciplinas básicas, de los métodos

matemáticos aplicables en la Ingeniería en Sistemas de Información, sean estos de

simulación, modelización o de control de procesos. Aquí, a su vez va perfilándose

una idea de la solución para el problema en cuestión pues es donde debe prestarse

especial atención a las restricciones. Esta etapa, por las razones que detallaremos,

se halla intrínsecamente ligada a la próxima.

La tercera, la de elección, según algunos autores puede representarse mediante dar

respuesta positiva a la pregunta acerca de cual es la mejor solución.

Personalmente, considero que no tiene demasiado rigor el expresar el término

“mejor”, si no es con arreglo a las restricciones apreciadas durante la etapa anterior.

Las mismas podrán ser de naturaleza económica, financiera, temporal, de logística,

de personal, de equipamiento, de oportunidad y de tantas razones que

presentándose solas o en concurrencia, explícitas o implícitas, dificultan la

enunciación de una lista exhaustiva.

2.1. Dimensiones de un problema:

El adecuado tratamiento de lo anterior es necesario pues en general, todo

problema tiene dos dimensiones, una intrínseca (lo objetivo, independiente del

observador, de su formación y opinión) y otra extrínseca (correspondiente a la

percepción que del mismo tenemos y la valoración que hacemos de sus

implicancias o consecuencias). Por ende, consideramos al problema como una

entidad con independencia de nosotros.



3. CICLO DE DESARROLLO DEL SISTEMA (CDS/SDLC)

Este enfoque de análisis y diseño por etapas, postula que el desarrollo de los

sistemas mejora cuando existe un ciclo específico de actividades o más

precisamente, etapas:

1. Identificación de problemas, oportunidades y objetivos.

2. Determinación de los requerimientos e información.

3. Análisis de las necesidades del sistema.

4. Diseño del sistema recomendado.

5. Desarrollo y documentación del software.

6. Pruebas y mantenimiento del sistema.

7. Implantación y evaluación del sistema.

KENDALL SENN YOURDON

ET

AP

AS

o

A

CT

IVID

AD

ES

Identificación de problemas,

oportunidades y objetivos.

Investigación

preliminar. Encuesta.

Determinación de los requerimientos e

información.

Determinación de

requerimientos.

Análisis de las necesidades del sistema. Desarrollo del sistema

prototipo. Análisis.

Diseño del sistema recomendado. Diseño del sistema. Diseño.

Desarrollo y documentación del

software. Desarrollo del software. Implantación.

Pruebas y mantenimiento del sistema. Prueba de los sistemas. Generación de pruebas de

aceptación.

Implantación y evaluación del sistema. Puesta en marcha.

Garantía de calidad

Descripción del

procedimiento.

Conversión de bases de datos.

Tabla 3.1. Actividades en ciclos de desarrollo de sistemas

En la tabla anterior se han sintetizado y compatibilizado las visiones de tres autores:

Kendall20

, Senn21

y Yourdon22

con relación a las actividades asociadas al ciclo de

desarrollo de un sistema (CDS/SDLC).

Conforme prolifera la información, se vuelve esencial un enfoque planeado y

sistemático para la introducción, modificación y mantenimiento de los Sistemas de

20

Kendall et al., op. cit. 21

Senn J., op. cit. 22

Yourdon et al., “Structured Design: Fund. and Appl. in Software Engineering”, Yourdon Press, 1988.



Información. El análisis y diseño de sistemas, realizado en un entorno

metodológico se convierte en el primer escalón para satisfacer tales necesidades.

4. METODOLOGÍAS INTEGRALES DE ANÁLISIS, DISEÑO Y

DESARROLLO DE SISTEMAS DE INFORMACIÓN

También existen otras metodologías, que con un soporte herramental adecuado,

permiten abordar el CDS/SDLC, razón por la cual es justo describirlas.

Entre las más divulgadas se encuentran:

Metodología SADT (Structured Analysis and Design Techniques).

Satisface los requerimientos de planeamiento, análisis y diseño. Emplea

diagramas jerárquicos “de arriba abajo” o “top down” y modulares.

Metodología SSADM (Structured System Analysis and Design Method)

Satisface los requerimientos de análisis y diseño. Empleada por el gobierno

británico. Debe cumplir las siguientes etapas:

Estudio de viabilidad

Análisis de requerimientos.

Estudio de opciones.

Especificación de requerimientos.

Especificaciones lógicas del

sistema.

Metodología CASE (Computer Aided/Assisted System/Software Engineering)

Satisface requerimientos de desarrollo utilizando herramientas computacionales.

Metodologías orientadas a objetos

Satisface los requerimientos de análisis, diseño e implementación, haciendo uso

de lenguajes de programación tales como OOD (Object Oriented Design) y

OOPL (Object Oriented Programming Language). Se basa en la consideración

de un sistema como una colección de objetos o entidades intercomunicadas.

Metodología de Ingeniería de la Información

Fue postulada y desarrollada por James Martín23

y se constituyó en el primer

antecedente de los sistemas actualmente denominados “data warehousing”, de

almacenamiento masivo de la información.

23

Martin J., “Information Engineering”, Ed. Prentice Hall, 1990.



Metodología MERISE

Satisface los requerimientos de análisis y diseño. Separa conceptualmente los

niveles de un problema (de acuerdo con su complejidad) de los elementos

estables (datos) y de los inestables (información).

Metodología Euromethod

Satisface los requerimientos de planificación, adquisición, construcción y

gestión de Sistemas de Información, erigiéndose como un regulador de

relaciones entre clientes y proveedores dentro de la Unión Europea.

5. ACTIVIDADES EN UN PROYECTO

Sintetizando, en un proyecto cuyo objetivo es la concreción de un Sistema de

Información, podemos describir la siguiente descomposición de actividades:

Análisis (*):

Recopilación de procesos y datos asociados.

Análisis de decisión.

Análisis el flujo de datos.

Preparación de la propuesta.

Diseño(*):

Diseño general de la entrada de información.

Diseño específico de las entradas.

Diseño de las salidas.

Organización de los datos.

Desarrollo

Implantación

Evaluación

(*) son las que se presentan en este trabajo.

A su vez, cada etapa, al someterla a un proceso de refinamientos sucesivos, se ha

desgranado en actividades tal cual lo muestra la siguiente tabla:



ETAPA DETALLE DE ACTIVIDADES

RECOPILACIÓN DE DATOS.

Realizar entrevistas.

Proporcionar cuestionarios.

Lectura de informes de la organización.

ANÁLISIS DE DECISIÓN Y

DEL FLUJO DE DATOS. Análisis del flujo de datos.

PREPARACIÓN DE LA

PROPUESTA.

Preparación de la propuesta.

Presentación de la propuesta.

Tabla 5.1. Etapas de un proyecto y detalle de actividades

6. EL PROCESO DE RELEVAMIENTO

Una de las etapas fundamentales para el diseño de un sistema es la que hace al

relevamiento del estado actual de los procesos involucrados en los procedimientos

y las necesidades insatisfechas, presentes y previsibles a futuro, con vistas a su

resolución.

Utilizando la técnica de triángulos invertidos, puede visualizarse que en general, la

necesidad de información y la generación de datos guardan relación inversa dentro

de la estructura jerárquica de una organización.

Figura 6.1. Niveles de generación de datos y necesidades de información.

Es conveniente hacer uso intensivo del concepto de datos aditivos / contribuyentes

y si bien la literatura recomienda realizar los mismos de modo ascendente “bottom

up”, se debe recurrir “un nivel atrás” cada vez que se considere importante la

necesidad de volver a recabar información a fin de disipar dudas o ambigüedades,

ampliar los alcances del sistema o establecer mecanismos de cooperación no

conocidos o previstos inicialmente.

Los requerimientos de los usuarios deben recibir adecuada atención por parte de los

Niveles de alta gerencia gran escala de integración de datos

Niveles de mandos medios moderada escala de integración

Niveles iniciales generación y/o recopilación de datos Generación

de datos

Necesidad de

información



analistas, pues de allí se derivarán las especificaciones de las producciones del

Sistemas de Información. Para llevar adelante los relevamientos, se presentan

diversas recomendaciones que se detallan seguidamente.

6.1. Recomendaciones para las entrevistas:

Debido a los diferentes niveles que ocupan los futuros usuarios dentro de la

orgánica, para llevar adelante la etapa de entrevistas, sugiero seguir los cinco

pasos sugeridos por Kendall24

:

Lectura de antecedentes.

Establecimiento de los objetivos de la entrevista.

Selección de los entrevistados.

Preparación del entrevistado.

Selección del tipo y estructura de las preguntas.

Asimismo, previo a cada entrevista se tomaron decisiones en cuanto a tres

tópicos fundamentales tal cual se muestra en la siguiente figura:

Figura 6.2. Decisiones del analista antes de la entrevista

Durante las mismas, se deben tener presentes los detalles sugeridos por

24

Kendall et al., op. cit.

Tipo de preguntas:

Abiertas

Cerradas

Exploratorias

Documentación:

Grabación

Cuaderno de notas

DECISIONES

IMPORTANTES

DEL

ENTREVISTADOR

Estructura de la Entrevista:

No estructurada.

Estructurada: Pirámide

Embudo

Diamante



Graham25

en cuanto a lo que este autor denomina “Investigación del problema y

captura de requisitos: contacto uno a uno, no aburrir a los usuarios o expertos en

el dominio, definir y estipular prioridades de los objetivos, efectuar predicción

aproximada de los beneficios esperados y demás.”

6.2. Tipos de preguntas:

Los tipos de preguntas según las opciones de respuestas que brindan los

entrevistados, se pueden clasificar en:

Abiertas.

Cerradas.

Sondeos o exploratorias.

En las preguntas se han tratado de minimizar los errores tales como: evitar las

preguntas tendenciosas y/o las denominadas múltiples (dobles cuanto menos)

que son las que en un solo enunciado contienen diferentes interrogantes.

Asimismo se ha establecido en las mismas una secuencia lógica y con relación a

su estructura, se ha empleado cada una de ellas de acuerdo con el fin perseguido

en cada entrevista, realizando las del:

Tipo piramidal: cuando hubo necesidad de ir desde lo específico hacia lo general

a efectos de llegar a una conclusión final.

Tipo embudo: cuando el cometido era el inverso.

Tipo diamante: cuando luego de haber avanzado en modo piramidal, fue

necesario recurrir a mayor precisión o detalle en las respuestas.

Cada tipo presenta ventajas y desventajas que se considera oportuno presentar en

la siguiente tabla:

25

Graham, op. cit.



TIPO VENTAJAS DESVENTAJAS

AB

IER

TA

S

1. Simplifican las cosas para el

entrevistado

1. Permiten preguntas que pueden

generar demasiada información

irrelevante.

2. Permiten al entrevistador seleccionar el

vocabulario del entrevistado, lo que

refleja su educación, valores y creencias.

2. Puede producirse la posible pérdida de

control de la entrevista.

3. Proporcionan una gran riqueza de

detalle.

3. Permiten respuestas que pueden llevar

demasiado tiempo para la cantidad de

información que aportan.

4. Revelan nuevas alternativas sobre

preguntas no consideradas.

4. Pueden dar la apariencia que el

entrevistador no se preparó.

5. Hacen más interesante la entrevista.

5. La posible apariencia que el

entrevistador se encuentra sin

objetivos reales de la entrevista.

6. Permiten una mayor espontaneidad.

7. Facilitan el estilo del entrevistador, sin

interrumpirlo.

Se utilizan como una alternativa, cuando el

entrevistado no se encuentra preparado.

CE

RR

AD

AS

1. Ahorran tiempo. 1. Aburren al entrevistado.

2. Facilitan la comparación entre

entrevistas.

2. Pierden la riqueza del detalle al

plantear un marco de referencia.

3. Llegan al punto de interés. 3. Se pueden perder ideas centrales por el

punto anterior.

4. Mantienen el control de la entrevista. 4. No favorecen un clima de armonía

entre el entrevistado y el entrevistador.

5. Cubren rápidamente diversos aspectos.

6. Obtienen datos de relevancia.

SO

ND

EO

S

1. Permite obtener mayor detalles, aclarar

y/o ampliar respuestas del entrevistado.

1. Que el entrevistado crea estar frente a

un investigador.

2. Se pueden realizar mediante preguntas

abiertas y cerradas.

2. Que por desconocimiento, el

entrevistado se sienta incómodo ante

preguntas tipo ¿puede dar más

detalles? o ¿puede ejemplificar? ,

3. Permite mostrar al entrevistado que el

entrevistador está atento a sus

respuestas.

Tabla 6.1. Ventajas y desventajas según tipo de pregunta.

6.3. Recomendaciones para los cuestionarios:

En las organizaciones es frecuente el uso de cuestionarios, sobre los cuales, tal

vez por falta de suficiente difusión o explicación de objetivos, los destinatarios

tienen prejuicios negativos, no los reciben con beneplácito, dudan de su utilidad

ulterior y descreen que sus opiniones vayan a ser tenidas en cuenta.



Por ello, optamos por la metodología de entrevistas personales en las que se

trata de recopilar actitudes, opiniones, conductas y características propias de

cada sector, más allá de obtener datos específicos acerca de los procesos y datos

asociados.

Al no existir un modelo único para el diseño de instrumentos específicos, hemos

pergeñado un “Modelo de Instrumento para obtención de Información a través

de Entrevistas”.

El mismo debe contener al menos los siguientes ejes temáticos o descriptores:

Ubicación dentro de la orgánica funcional.

Denominación del proceso.

Marco legal en el cual se sustenta. (si corresponde)

Descripción del procedimiento con identificación precisa de los actores.

Plazos a cumplimentar dentro del procedimiento administrativo.

Validez del mismo.

Observaciones generales y/o particulares.

Nivel presente de sistematización.

Indicación sobre necesidad de sistematización.

Prestaciones básicas deseables al tiempo de sistematización.

Datos de interés para el Sistema de Información del Área Cursos.

Recomendación para optimización actual. (En caso de proceder)

Tablas comparativas y esquemas resúmenes. (En caso de proceder)

Previsiones sobre atributos de los datos tales como calidad, completitud,

frecuencias de recepción y demás . (En caso de proceder)

Adecuada valoración de los estados transitorios y estables del sistema.

6.4. Recomendaciones para las dimensiones de la información:

En la primera página del libro de Kendall puede leerse: “La información puede

llegar a ser el elemento decisivo que en un momento dado, determine el éxito o

el fracaso”, de allí que, tanto para la formulación del cuestionario “Entrevistas a

Usuarios” derivado del “Modelo de Instrumento para obtención de Información

a través de Entrevistas” citado precedentemente, como para la recopilación de la



información requerida en el mismo, se debe tener especialmente en cuenta los

siguientes atributos o dimensiones de la información:

Enfoque.

Nivel de detalle.

Grado de resumen.

Antigüedad.

Precisión.

Tipo.

Fuente.

6.5. Recomendaciones para las escalas:

En los casos de intentos de sistematización de cuestionarios, poniendo énfasis en

la necesidad de asegurar los parámetros de validez y confiabilidad, se debiera

ofrecer a los entrevistados las cuatro formas básicas sugeridas por Stevens y

descriptas por Pavesi26

:

Nominal: se utilizan para clasificar objetos sin establecer niveles.

Ordinal: permiten la clasificación pero implica un arreglo por categorías sin que

la diferencia entre las mismas sea igual.

De intervalo: se pueden operar matemáticamente pues las diferencias entre

categorías es igual pero se carece de un cero absoluto.

Proporcional: Ídem anterior, con la existencia de un cero absoluto o referencial.

Sobre las mismas existe suficiente bibliografía, permitiéndonos sugerir a

Churchman27

para aspectos convencionales y a Nilsson28

para métricas de

calidad en Inteligencia Artificial.

7. EL PROCESO DE ANALISIS DEL SISTEMA

Producida la recopilación descriptiva de procesos y datos asociados, procede

sistematizar su análisis. Este proceso posee características distintivas según el

análisis se oriente a los datos o a las decisiones. Esta fase se concluye con la

preparación de la propuesta del sistema.

26

Pavesi, P., “La medición del universo”, Ficha 156, FCE, Buenos Aires, 1996. 27

Churchman & Ratoosh, “Measurement: Definitions and Theories”, Wiley, New York, 1969. 28

Nilsson N., “Inteligencia artificial, una nueva síntesis”, Mc. Graw Hill, Madrid, 2001.



7.1. Análisis de Sistemas Orientado a Datos

Los métodos disponibles son los diagramas de flujo de datos y el diccionario de

datos.

Los primeros, afirma Kendall29

: “Permiten concebir de manera visual a los

sistemas y subsistemas como un conjunto de flujo de datos relacionados entre

sí.” A partir de los mismos, se generan los segundos como elemento referencial

acerca de los atributos de los datos descriptos en la instancia precedente.

Prosiguiendo con el derrotero trazado, se puntualizan las recomendaciones más

importantes a fin de avanzar sobre terreno seguro.

7.2. Recomendaciones para los diagramas Entidad – Relación (y atributos):

Estos diagramas ayudan a comprender la organización, a determinar las

dimensiones del problema y a discernir si el problema abordado es el correcto.

Permiten visualizar las relaciones entre entidades, definidas estas como objeto o

evento sobre el cual se obtienen datos. Las asociaciones pueden ser del tipo 1:1,

1:N, N:1 y N:M, donde N y M significan “muchos”.

Para su construcción se deben enumerar las entidades, elegir las entidades claves

para reducir la visión del problema, identificar la principal, confirmar lo anterior

mediante otros métodos de captura de información. Los símbolos utilizados son

rectángulos para las entidades y rombos para las relaciones.

Si por ejemplo, las bases de datos existentes o diseñadas se hallan construidas en

el aplicativo MS Access, los diagramas se deberán obtener mediante el

documentador de relaciones del citado producto.

7.3. Recomendaciones para analizar el flujo de datos:

Existen diversas técnicas para analizar los orígenes y reservorios de datos, como

así también su tránsito; entre ellas, podemos citar: IDEFO (Integration

Definition for Function Modeling) y DFD (Diagrama de Flujo de Datos) :

Los mismos permiten mostrar: Entrada – Proceso – Salidas.

Caracterizan gráficamente el flujo de datos dentro del sistema.

Presentan una visión, lo más amplia posible, de las entradas al sistema, los

procesos y las salidas.

Se utilizan para catalogar procesos, el flujo, los almacenamientos, las estructuras



y los elementos en un diccionario de datos.

El enfoque de flujo de datos enfatiza la lógica que sustenta al sistema. Es una

herramienta poderosa pues con sólo cuatro símbolos: Entidad, Flujo de datos,

Proceso y Almacén de datos, permite crear una descripción “pictórica de la

información que eventualmente proporcionará una documentación sólida del

sistema”.30

Ventajas:

Frente a la descripción narrativa, el enfoque de flujo de datos tiene tres ventajas:

Libertad conceptual, independizándose de los aspectos físicos e la

implantación.

Permite comprender mejor la relación entre sistemas y subsistemas.

Mejora la interacción con los usuarios al exhibirles clara y concisamente la

visión que el analista tiene sobre sus tareas y necesidades de información.

Símbolos:

Los símbolos de la siguiente figura, fueron introducidos en un trabajo de Gane y

Sarson31

.

Entidad Proceso Flujo de datos Almacén de datos

Figura 7.1. Símbolos utilizados en un Diagrama de Flujo de Datos

También Yourdon32

ha propuesto una simbología que no varía sustancialmente

de la descripta precedentemente, tan solo utiliza un círculo para el proceso (en

vez del rectángulo de bordes curvos) y dos líneas paralelas para el

almacenamiento (en vez de estar cerradas por su lado izquierdo).

Convenciones:

El cuadrado representa una entidad externa (empresa, persona o máquina) que

da y recibe datos del sistema. Otros términos son fuente o destino de datos, se la

29

Kendall et al., op, cit. 30

Kendall y Kendall, op. cit. 31

Gane C. y Sarson T., “Structured Analyisis and Design Techniques”, Prentice Hall, New Jersey, 1979. 32

Yourdon et al, op. cit.



reconoce por el nombre que se le ha asignado.

El rectángulo con bordes curvos indica un proceso de transformación de datos,

por ende, el flujo de información que sale, siempre tendrá un nombre diferente al

que hubiera tenido al entrar.

La flecha representa el movimiento de datos de un punto a otro.

El rectángulo abierto en su extremo derecho representa el almacenamiento de

los datos, sin especificar el tipo de soporte físico en el que se produce el

almacenamiento.

Convenciones suplementarias:

Dado que en la descripción de procesos complejos la repetición de cuatro

símbolos puede resultar algo confusa, con la intención de clarificar y simplificar,

se cuenta con una serie de convenciones suplementarias que se aprecian en la

siguiente figura:

Entidad Identificación de Líneas de flujo Almacén de datos duplicada Procesos entrecruzadas duplicados

Figura 7.2. Símbolos suplementarios utilizados en un Diagrama de Flujo de Datos

Pasos a seguir en un DFD:

Básicamente es recomendable seguir la siguiente secuencia:

1. Enfoque de lo general a lo particular, haciendo uso de los cuatro símbolos:

entidad externa, flujo de datos, proceso y almacén de datos. Finalizado esto,

se puede bosquejar el diagrama de contexto que, siendo el nivel “cero”, debe

contener lo básico de las entradas, los procesos y las salidas.

2. Cubrir detalles, aquí comienza la etapa de refinamientos sucesivos. Resulta

interesante reflexionar acerca de cuál es el nivel de “explosiones” de los

diagramas, pues poco puede llevar a futuros errores por omisión y mucho, a

confusión. Esta problemática está asociada con la de los niveles de

especificación cuando se da respuesta positiva a la pregunta “¿como?”; de



hecho, un ejemplo permitirá clarificar más que un conjunto de teoremas.

Suponga que debe cambiar la rueda de un automóvil y le alcanzan parte de la

solución en metalenguaje o seudo código como el que sigue:

Mientras (condición es verdadera)

hacer conjunto de acciones _ 1

fin_hacer

fin_mientras

Donde la condición es “la tuerca / tornillo permanece en su alojamiento” y el

conjunto de acciones _ 1 es “tomarlo, girarlo un cierto ángulo, soltarlo”

Piense como se sentiría según sea Ud. quien debe cambiar la rueda o quien

ha de programar un robot para que ejecute rutinariamente esta tarea en un

taller computarizado.

La experiencia sugiere, por las consecuencias expuestas, que la mejor sintonía

se obtiene cuando se conoce para quién se especifica.

3. Volver a dibujar los diagramas , definiendo los símbolos con suma precisión.

Diagrama de contexto:

Por su sencillez, debiera ser el primer diagrama que se realiza ya que, según

Kendall33

: “Un diagrama de contexto presenta un esbozo del sistema”.

7.4. Recomendaciones para el Diccionario de Datos:

Se utiliza para aportar claridad unívoca en la definición de los atributos de los

datos involucrados en el Sistema de Información, bien podríamos expresar que

su contenido son meta datos (datos acerca de los datos).

Pasos para la creación de un diccionario de datos:

Para un primer esbozo manual de un diccionario de datos es altamente ventajoso

seguir los siguientes pasos:

1. Incorporar los procesos.

2. Catalogar los flujos básicos y los almacenes de datos.

33




3. Describir la estructura de datos.

4. Desglosar la estructura de datos en datos elementales.

Atributos a registrar:

Siendo el diccionario de datos una completa y unívoca descripción de los datos

asociados, deberá contener los siguientes elementos:

Nombre y sinónimo.

Descripción textual informativa.

Rangos permitido.

Longitud.

Codificación adecuada.

Información adicional de relevancia.

Cabe citar que en las etapas de desarrollo o prototipación, al emplear aplicativos

informáticos, los mismos contienen elementos de guía y documentación para facilitar

esta tarea.

Más aún, han aparecido los denominados Sistemas Basados en Conocimiento o KBS

(Knowledge Based Systems), que poseen facilidades documentación incorporadas.

7.5. Estilos de Toma de Decisiones:

Según la forma de utilizar la información y la manera de tomar decisiones, los

tomadores de las mismas se clasifican en analíticos y heurísticos, siendo sus

principales características las que se sintetizan en la siguiente tabla:

HEURÍSTICO ANALÍTICO

Aprende mediante la acción.

Se vale de la prueba y el error.

Aprecia la experiencia.

Confía en el sentido común.

Busca soluciones satisfactorias.

Aprende mediante el estudio.

Usa procedimientos paso por paso.

Evalúa información cuantitativa y modelos.

Construye modelos matemáticos y algoritmos.

Busca la solución óptima.

Tabla 7.1. Estilos de toma de decisiones



Información y certeza

Independientemente de la concepción actitudinal desde la cual se tomen las

decisiones, la información debe cumplir los atributos de: disponibilidad,

razonabilidad, completitud y precisión, debiendo prestarse especial atención a la

saturación de la misma que a menudo se produce tratando de asegurar el mayor

detalle posible.

Si bien Kendall considera que: “La información y la experiencia incrementan la

certeza”, a nuestro juicio es una aseveración que puede conducir a error, razón

por la cual hemos preferido analizar ambos componentes por separado, dado que

no existe una relación estrictamente creciente entre información y certeza.

Expresado de otro modo, aumentar la información no es garantía de disminuir la

incertidumbre.

Por lo expuesto, nos permitimos reformular la primera aserción del siguiente

modo “La experiencia, además de la información, nos apoya para la toma de

decisiones” , más allá que diferentes estilos de decisores prefieran una por sobre

la otra, reconociendo que la habilidad de toma de decisiones se mide en la

madurez del tomador de decisiones, la cual se basa en la experiencia y el

análisis, la abstracción y la síntesis.

Mas allá de las preferencias, algunos decisores deben comportarse como

heurísticos porque a veces es muy difícil, cuando no imposible, la adquisición

oportuna de la información.

Producto de la aseveración anterior creemos que, para la generación de

indicadores, se podría iniciar con su formulación y desarrollo de modo heurístico

y a medida que se crece en el conocimiento de los mismos y en el

entendimiento de las interacciones que rigen entre sus variables componentes,

migrar a lo analítico.

Indicadores

Sobre este particular, conviene destacar que tal vez, la dificultad mayor para la

operatoria integral de los mismos radica en:

1. Su formulación:

Determinar el conjunto de variables relevantes al objeto de análisis.

Postular un modelo de integración conceptual de las mismas.

Adoptar una escala de medición adecuada.



2. Búsqueda y elección de pares para su análisis comparativo.

3. Su empleo como elemento contribuyente a la política institucional de calidad.

7.5.1. Decisiones Semiestructuradas

Este tipo de decisiones, al presente no son completamente resolubles por

aplicación de algoritmos, necesitan de la intervención humana, de allí que los

DSS contribuyan grandemente a la toma de decisiones.

Antiguamente se consideraba que la habilidad de una persona para resolver

problemas era una condición innata, genética o tan simplemente de inspiración.

Estudios posteriores, dando por tierra con antiguas teorías y/o creencias,

demostraron que cuantos más problemas diferentes se resuelven, cuanto más

se analizan todos los factores intervinientes en una problemática, mejor

preparado se estará para el próximo desafío.

En síntesis, la aptitud para resolver problemas se basa en la capacidad de

abstracción y síntesis, conceptos plenamente interrelacionados, según

Kendall34

con que “La habilidad de toma de decisiones se mide en la madurez

del decisor, la cual se basa en la experiencia y el análisis”.

Figura 7.5. Dimensiones de las decisiones.

Las decisiones se pueden visualizar en la figura anterior mediante un cubo

cuyas dimensiones o ejes son:

34


No estructurado Semiestructurado

Semiestructurado

Semiestructurado Semiestructurado

Semiestructurado Estructurado

Semiestructurado



EJE DENOMINACIÓN

TIPO DE DECISIÓN

ESTRUCTURADA SEMIESTRUCTURADA

X Grado de habilidad requerido en la

toma de decisiones.

No requiere destreza Requiere gran destreza.

Y Magnitud de la complejidad del

problema.

Muy sencillo. Muy complejo.

Z Número de criterios de decisión

por considerar.

Criterio simple. Criterio múltiple.

Cuando reflexionamos sobre el interrogante ¿Todos tomamos decisiones?,

resulta de vital importancia reconocer que nuestros esfuerzos deben estar

destinados en primera instancia, a que no queden librados al albur de una

decisión, todas aquellas acciones que puedan poseer solución programada.

Es posible y puede resultar de utilidad, elaborar un DSS que simule diferentes

situaciones con múltiples variables; p.e. Si varío la incidencia del contenido

práctico o la cantidad de horas de una materia, ¿como se afectarán las

correlativas?; y ¿estos resultados parciales, como influirán sobre el producto

final?

7.5.2. Decisiones de Criterio u Objetivo Múltiple

Los problemas a resolver tienen numerosos objetivos que, adicionalmente,

pueden estar en conflictos. Dependiendo del nivel donde se aprecie el

problema, aún persiguiendo un objetivo político o estratégico común, al

intentar cumplir los objetivos particulares contribuyentes, estos pueden arrojar

soluciones contrapuestas. Valga tan sólo recordar como en algunas empresas,

más allá que todos pretenden lo mejor para ella (y obviamente para ellos), las

maneras que entienden los distintos Dptos. Son distintas, Producción (mucho

de pocos modelos), Comercial (muchos modelos), Publicidad (hacer

campañas), Contable (no gastar) y así siguiendo.

Según Pavesi35

“En general, todo decididor ostenta varios objetivos

simultáneos, los que denominaremos objetivos múltiples”. En particular, para

el alumno, los que pretende la Escuela Naval Militar son lo académico, lo

35

Pavesi, Pedro, “Objetivos múltiples y en conflicto”, F.C.E. Ficha 171, Buenos Aires, 1997.



militar y lo físico; más aún, dentro de ellos pueden reconocerse otros objetivos

de segundo orden, contribuyentes y que también pueden hallarse en conflicto;

p.e., dentro de lo académico, que aprenda materias básicas y a la vez, que

pueda entrenarse adecuadamente en el simulador de navegación.

Este enfoque permite establecer prioridades y realizar análisis de sensibilidad

por medio del planteo de interrogantes tales como “¿Qué sucedería si...?” o

“What if?” .

Para salvar estos escollos, existen diversos métodos que a continuación se

citan. Para los interesados en detalles, sugerimos consultar a autores como

Kendall, Laudon, Onitcanschi y Pavesi, oportunamente citados.

Métodos para evaluar problemas de criterios u objetivos múltiples:

Dentro de estos métodos se incluyen:

Ventaja desventaja.

Ponderación.

Eliminación consecutiva por lexicografía (es menos exigente que el

anterior porque se asigna importancia y no peso).

Eliminación consecutiva por restricciones conjuntivas.

Programación por objetivos (similar en estructura a la programación lineal,

pero al estar desde el inicio, limita el análisis de sensibilidad).

7.6. Análisis de Sistemas con Decisiones Estructuradas

Concluida la identificación y el conocimiento de los flujos de datos necesarios

para la conformación del diccionario de datos, resulta oportuno realizar el

análisis de las decisiones, para el cual existen métodos perfectamente definidos.

Métodos:

1. Lenguaje estructurado.

2. Matrices o Tablas de decisión.

3. Árboles de decisión.

4. Checkerboard.

5. Fixture.



Son para el análisis de la lógica de decisiones, que pueden ser estructuradas y

semi estructuradas.

Resulta importante reconocer que las decisiones estructuradas se adaptan al

análisis sistémico permitiendo, según Kendall, “la obtención de conclusiones, un

alto grado de precisión y favorece las comunicaciones”.36

1. Lenguaje estructurado:

A partir de un teorema de Böhm y Jacopini37

, dentro de la programación imperativa,

quedó demostrado que todo problema puede ser resuelto utilizando, sea en forma

única o mediante alguna combinación de las mismas, solo tres estructuras de control:

Secuencia.

Decisión.

Repetición.

A los interesados en estas tres estructuras básicas, dado que se hallan suficientemente

descriptas en la literatura, sugerimos la lectura de Dijkstra38

, Wirth39

, Gioia y

Braunstein40

, Galve , González, Sánchez y Velázquez41

y Brookshear42

entre otros.

2. Matrices o Tablas de decisión.

Las mismas, “son cuadros que indican los resultados esperados de adoptar las

alternativas consideradas ante los diferentes estados naturales que pueden

producirse”.43

Como se aprecia en la figura, contienen condiciones, acciones y reglas.

CONDICIONES y ACCIONES REGLAS

Condiciones Alternativas de la condición

Acciones Registro de las acciones

Figura 7.6. Acciones, condiciones y reglas en la decisión.

36


Böhm et al., “Flow Diagrams, Turing Machines and …”, Communications of the ACM, mayo de 1966. 38

Dijkstra, E., “A discipline of Programming”, Prentice Hall, Englewood Clifs, 1976. 39

Witrh, N., “Algorithms + Data Structures = Programs”, Prentice Hall, Englewood Clifs, 1976. 40

Gioia A. Et al., “Intr. a la programación y a las estructuras de datos”, Eudeba, Buenos Aires, 1987 41

Galve, J. et al. “Algorítmica, diseño y análisis...”, Addison-Wesley Iberoamericana, Wilmington, 1993 42

Brookshear, G., “Intr. a las Ciencias de la Computación”, Addison-Wesley., Wilmington, 1995. 43

Onitcanschi, G. et al., “Notas sobre elementos de la decisión”, Ficha 151, FCE, Buenos Aires, 1984.



Para su construcción, se deben seguir los siguientes pasos:

Determinar el número de condiciones que pudieran afectar la decisión.

Determinar el número de acciones posibles que puedan realizarse.

Determinar el número de opciones para cada condición.

Calcular el número máximo de columnas de la tabla.

Llenar las alternativas de la condición.

Concluir la tabla colocando “X” donde las reglas sugieran cierta acción.

Combinar las reglas donde se aparente que una alternativa no implique diferencias

en la salida.

Verificar la tabla para situaciones imposibles, contradicciones o redundancias.

Volver a arreglar las condiciones y las acciones y aún las reglas, de ser necesario,

si ello contribuye a una mayor comprensión.

Los problemas más importantes que se detectan al tratar de certificar su precisión e

integridad son:

Tablas incompletas.

Situaciones imposibles.

Contradicciones.

Redundancias.

3. Árboles de decisión:

Conviene su uso cuando el proceso decisorio conlleva ramificaciones complejas.

Según Magee44

“Puede aclarar, como no consigue ningún otro procedimiento de

análisis, las alternativas, los riesgos, los objetivos, las ganancias y las necesidades de

información que están presentes en un problema...”

Al igual que con las tablas de decisión, los pasos para desarrollar un árbol son:

Identificar las condiciones, Identificar las opciones de la condición, Identificar las

acciones, Identificar las reglas de acción.

Previo a su construcción de izquierda a derecha, deben identificarse todas las

condiciones y acciones, así como su precedencia y momento de ejecución si

correspondiere.

44

Magee, J., “Árboles de decisión: técnicas de aplicación”,ed. Nueva Técnica, Buenos Aires, 1998



Chekerboard:

También es una matriz con alternativas (en las filas) y criterios (en las columnas).

En cada celda se indica si la alternativa cumple o no el criterio, pudiendo agregarse

escalas de valores numéricos o porcentuales.

4. Fixture:

Es otra variante de las matrices descriptas anteriormente donde, las alternativas

figuran en filas y columnas para obtener una visión de cada una de ellas con respecto

a las demás, asignando puntaje a la que resulte más beneficiosa.

Cerrando este repaso por las técnicas para el análisis de decisiones estructuradas, es

oportuno citar que, si bien no son excluyentes, se recomienda hacer uso de solo una de

ellas, según los criterios enunciados por Kendall45

del siguiente modo:

1. Utilice el lenguaje estructurado cuando:

a) Haya muchas acciones repetitivas.

o

b) La comunicación con los usuarios finales sea relevante.

2. Utilice una tabla de decisión cuando:

a) Se cuenten con combinaciones complejas de condiciones, acciones y reglas.

o

b) Requiera un método que efectivamente evite situaciones imposibles, redundancias

y contradicciones.

3. Utilice un árbol de decisiones cuando:

a) La secuencia de las condiciones y las acciones sea decisiva.

o

b) Cuando no sea relevante cada condición sobre cada acción (las ramas son

diferentes).

7.7. Análisis de Sistemas de Apoyo para Decisiones Semiestructuradas:

Por la naturaleza de las decisiones, resulta de sumo interés conocer si en los

tomadores de decisiones predomina una conducta analítica o heurística, la

manera en que se toman las decisiones durante las fases de resolución del

problema y los métodos de criterio múltiple que permiten resolver problemas

semiestructurados.

45




Para que sirven:

Teniendo en claro que no reemplazan el juicio del usuario ni decide por él,

básicamente:

Organizan la información requerida apoyando el proceso para la toma de

decisiones, dan seguimiento a las variables y presentan problemas o

proyectos, las alternativas y las elecciones realizadas para aportar mayor y

más fácil comprensión.

Permiten la resolución de “cuellos de botella” comunes durante las fases en la

solución de problemas, oportunamente citadas en este trabajo en el acápite

homónimo, conformados por las siguientes incapacidades:

En el análisis: Incapacidad para identificar, definir y categorizar el

problema.

En el diseño: Incapacidad para generar, cuantificar o describir, asignar

criterios, valorizar, ponderar y categorizar alternativas.

En la selección: Incapacidad para identificar el método de selección, para

organizar y presentar la información y para seleccionar las alternativas.

Amplían la visión y el panorama del tomador de decisiones para mejorar su

comprensión, de allí que provoque cambios en su estilo de acción. Según

Kendall: “Un tomador de decisiones cambia cuando se lo relaciona con un

DDS, que en cierta manera es novedoso e implica un reto”.

Crean una estructura para la toma de decisiones y usan modelos a tal fin,

siendo usados en problemas semiestructurados complejos cuya completa

computarización resulta muy engorrosa, cuando no, inviable.

Poseen la ventaja de poder incluir sugerencias de técnicas analíticas “en que

modelo apoyarse” o heurísticas “mejor forma de presentar la información

luego de tomada una decisión”.

Asimismo debe tenerse en cuenta que la búsqueda de una solución no es el

objetivo del DDS, sino que este es un sistema que apoya el proceso de decisión

que conducirá a la solución de problemas que, por su complejidad, tornan difícil

su completo tratamiento informatizado; sumado al hecho que, en general, los

humanos somos reacios a delegar el juicio.



Donde se aplican:

En decisiones, tanto que se apliquen una sola vez, rara vez o frecuentemente.

También en los casos donde sea necesario manejar criterios múltiples.

Son importantes porque satisfacen requerimientos de personas con distintas

actitudes o habilidades frente a la toma de decisiones, brindando tanto modelos

fáciles de comprender para los pensadores analíticos como analogías para los

heurísticos.

Deben concebirse, según Kendall46

“como un proceso más que un producto”,

sea tanto para uso específico como para ser aplicado como motor generador de

otros tipos de sistemas, denominados DSSG Decisions Supports Systems

Generator.

8. PREPARACION DE LA PROPUESTA DEL SISTEMA

Que es:

Kendall47

propone que “La propuesta del sistema es un resumen de todo lo que el

analista de sistemas ha aprendido acerca de la empresa y de lo que esta requiere

para mejorar su desempeño.”

Las necesidades de información y los procesos que conducen a la obtención segura

en tiempo y forma de los datos necesarios, la estimación de tiempos para pasar del

estado transitorio al estable del sistema, los volúmenes de datos a migrar de soporte

y tantos otros elementos son los que deberán figurar en la propuesta.

Si el tema costos interesa o se está al inicio, donde la implantación del Sistema de

Información depende de la adquisición de equipos informáticos o el alquiler de

equipos y/o servicios, en la preparación de la propuesta del sistema deberán tenerse

en cuenta los beneficios:

1. Tangibles: ventajas económicas cuantificables.

2. Intangibles: difíciles de cuantificar pero no de percibir, que incluyen, entre otras:

La mejora del proceso de toma de decisiones.

El llegar a ser más competitivo en los servicios al cliente.

El mejoramiento de la imagen del negocio.

El incremento de la satisfacción de los empleados al eliminar tareas de

naturaleza odiosa.

46





Desde otra perspectiva que no contemple exclusivamente la valoración económica,

creo que podemos medir estas ventajas a través de encuestas de satisfacción de

clientes y empleados, análisis de informes de posicionamiento de empresas y tantos

otros instrumentos que, mediante el empleo de escalas especialmente diseñadas,

permitan ponderar adecuadamente estas ventajas.

9. DISEÑO Y DESARROLLO DE SISTEMAS

Dado que cada problema presenta particularidades, hecho que determina la

inexistencia de un único criterio para resolver como no sea el de hacer las cosas

bien, resulta útil pasar somera revista a los mecanismos de diseño (enfoque

ascendente o descendente) y desarrollo (modular), poniendo énfasis en sus ventajas

y desventajas.

9.1. Diseño Ascendente o bottom-up:

Ventajas: Rápida aplicación en los niveles inferiores o para satisfacer la

resolución de un problema de inmediato.

Desventajas: Difícil integración de subsistemas, duplicación de esfuerzos,

redundancia en la carga de datos, desconocimiento de los objetivos globales

de la organización, que lleva a no tenerlos en cuenta al tiempo del diseño.

9.2. Diseño Descendente o top-down:

Ventajas:

Obliga a los analista a comenzar por conocer los objetivos globales de la

organización, evita el caos de diseñar un sistema en un solo paso, se puede

trabajar simultáneamente con diferentes grupos de programadores, previene

el que se entre en detalles perdiendo los objetivos centrales.

Inconvenientes: Riesgos de particionar el sistema en subsistemas

incorrectos, descuido de las interfases, olvido del concepto de reuso de

aplicaciones.

9.3. Desarrollo modular:

Adoptada la decisión de diseño descendente, se debe proceder con un desarrollo

modular pues posee tres ventajas:



1. Los módulos son más fáciles de:

Codificar.

Revisar.

Probar.

Documentar.

2. El mantenimiento es más sencillo.

3. Es más fácil comprender tramos auto contenidos que retener la atención

sobre todo el sistema simultáneamente.

No obstante estas ventajas, resulta de utilidad presentar algunos lineamientos

para su desarrollo:

El tamaño de los módulos debe ser manejable, de ser posible debieran dar

respuesta sólo a una función.

Debe prestarse especial atención a las interfases en lo que a datos y

parámetros transferidos y/o recibidos se refiere.

Mantener las relaciones jerárquicas establecidas inicialmente, a menos que

nuevos elementos de juicio o la detección de aspectos inadvertidos

inicialmente aconsejen su alteración.

9.4. Diagrama Estructural:

Es un instrumento recomendado para el diseño modular descendente porque:

Estimula el diseño descendente.

Apoya el diseño de módulos.

Identifica y limita los datos y los elementos de control que se pasan entre

módulos.

Pero no pueden por sí solos constituirse en una técnica de diseño o

documentación porque, a diferencia de un DFD, no precisa el orden en que se

deberán ejecutar los módulos y además no brindan suficiente nivel de detalle

como un seudo código o los diagramas de Warnier-Orr o Nassi-Schneiderman.

Finalmente, en la elección de una técnica de diseño y documentación, los

analistas debieran tener en cuenta que la misma reúna los siguiente atributos:

1. Sea compatible con la documentación existente.

2. Sea comprensible dentro de la organización.



3. Permita regresar a trabajar en el sistema aún cuando haya estado ausente del

mismo por un prolongado lapso.

4. Sea adecuada para el sistema que se pretende resolver.

5. Permita un enfoque de diseño estructurado si se considerase que esto es

relevante.

6. Permita hacer fácil las modificaciones a que hubiere lugar.

A efectos de completar esta visión, debemos citar que existen otra técnicas de

diseño tales como:

Diagramas Jackson.

Diagramas Warnier-Orr.

Diagramas Nassi-Schneiderman.

Diagramas Transición de estado.

Diagramas SADT.(Structured Analysis and Design Techniques)

Diagramas de acción.

Normalizaciones.

HIPO (Hierarchy Input Process Output)

10. ELEMENTOS ESENCIALES DE DISEÑO

Los relevamientos efectuados han permitido resolver el interrogante acerca de

para quien / quienes se diseñará el Sistema de Información con sus diferentes

alcances y modalidades.

La siguiente figura permite apreciar que, a mayor nivel en la escala jerárquica de

una organización, mayor será el nivel de integración de la información.

Figura 10.1. Relación entre niveles jerárquicos e integración de la información.

DDS Estrategia Alta conducción.

MIS Administración Mandos / niveles medios

DPS Operación Administrativos / personal de apoyo

Pirámide Jerárquica Nivel de integración de información



Pasaremos revista a algunos de los elementos más importantes a tener en cuenta

al tiempo de diseñar el sistema.

Ellos son:

Diseño Efectivo de Salidas.

Diseño Efectivo de Entradas.

Lineamientos de Pantallas.

Aseguramiento de la Calidad de los Datos.

Bases de Datos.

Enfoque del Aseguramiento de la Calidad Total.

Diseño y Desarrollo de Sistemas (*).

(*) Se incluyen referencias sobre el desarrollo al tiempo del diseño pues

existe una dupla “Diseño descendente y desarrollo modular”, la cual,

por las razones expresadas en el acápite anterior, hemos considerado

que deben presentarse conjuntamente.

10.1. Diseño Efectivo de Salidas

Recordando los atributos comunes que deben reunir algoritmos, programas y

sistemas tales como ser: útiles, confiables, eficientes, mantenibles y demás, y

dado que “las salidas” son aquello que han de recibir los usuarios, resulta

importante destacar sus seis objetivos:

1. Diseñar salidas para satisfacer los objetivos planteados.

Su presentación debe venir dada como producto de una necesidad real y no

como un producto adicional derivado de las facilidades que brindan las

actuales tecnologías.

2. Diseñar salidas que se adapten al usuario.

Si bien es más fácil diseñar salidas de uso generalizado, resulta más

productivo ajustar las mismas de acuerdo con lo oportunamente relevado a

través de encuestas, de allí la elección que hemos realizado para este

cometido.



3. Proveer la cantidad adecuada de información.

Desde la simple confusión entre nómina y cantidad (en muchas

organizaciones, hemos apreciado que un gran número de usuarios solicitan

largos listados con identificación de casos detectados para luego efectuar un

conteo a mano!) hasta el proveer lo solicitado y observar caras de extrañeza

ante la profusión de información, existe la necesidad de acordar en ocasión

de realizar los relevamientos, cuales serán los “cuantos” o “cuotas” de

información que serán realmente de utilidad al tiempo del uso del sistema, ya

que poco generará insatisfacción y mucho, abrumará, no será de aplicación al

par de insumir tiempo y esfuerzo adicional de analistas y programadores.

4. Asegurar que las salidas estén disponibles donde se necesitan.

Habitualmente se generan en un lugar y se distribuyen, por procedimientos o

costumbres entre un conjunto de usuarios no siempre debidamente validado y

actualizado, agravado por el hecho que a veces no llegan a los tomadores de

decisiones. En nuestro caso, la Red Informática contribuirá a que cada usuario

disponga de sus “cuantos” o “cuotas” de información, ventaja que se ha de

potenciar mediante la capacitación a los mismos en las facilidades de los

genéricamente denominados SQL (System Query Language).

5. Proporcionarlas oportunamente.

Una de las quejas más usuales de los usuarios es que no reciben a tiempo la

información demandada. Tiempo y forma son dos parámetros indisociables al

momento de delinear las salidas del sistema.

Con respecto al tiempo de satisfacción de las mismas, se deberán tener

presente todos los actores involucrados y sus tiempos pues, recordando el

consabido refrán que ninguna cadena es más fuerte que su eslabón más débil,

de nada sirve p.e. que los tiempos de procesamiento sean los adecuados si los

que proveen los datos primarios lo hacen a destiempo; este es un problema

que es más fácil que aparezca durante la operatoria del sistema que durante su

relevamiento. Para una adecuada valoración de los mismos, resultarán de

suma utilidad los aportes de la Investigación Operativa en este sentido.

Con respecto a las formas, la dificultad puede residir en una inadecuada

especificación del requerimiento, en una migración conceptual no declarada o



en la aparición repentina de imposiciones o imprevistos con cotas temporales

muy cercanas.

6. Elegir el método correcto.

Si bien el producto informativo es el mismo, su presentación puede originar

diferentes impactos globales sobre el usuario, por razones de costos,

flexibilidad, vida media, distribución, almacenamiento y posibilidades de

acceso y transporte.

Con el fin de elegir adecuadamente la tecnología de salida, resulta oportuno citar

algunas de las consideraciones descriptas como más frecuentes:

1. Quien usará las salidas? (requisito de calidad)

2. Cuantos usuarios necesitan la salida?

3. Donde se necesita la salida? (distribución / logística)

4. Cual es el propósito?

5. Con que velocidad se requiere?

6. Con que frecuencia?

7. Durante cuanto tiempo debe ser almacenada?

8. Bajo que relaciones especiales se produce la salida, almacenamiento y

distribución?

9. Cuales son los costos iniciales y posteriores de mantenimiento y de

suministros?

10.2. Diseño Efectivo de Entradas

Uno de los mecanismos más difundidos para la captura de datos es el empleo de

formas.

Kendall48

define: “Las formas o planillas son aquellos instrumentos que a través

de documentos duplicados o preimpresos son llenados por personas en respuesta

a un procedimiento estandarizado”.

Siendo elementos tan importantes, en su diseño deben tenerse presente cuatro

lineamientos:



1. Deben ser fáciles de llenar.

2. Deben cumplir con el propósito para el cual fueron diseñadas.

3. Deben asegurar un llenado preciso sin lugar a ambigüedades.

4. Su diseño debe ser atractivo.

Desde el punto de vista de la estructuración del contenido, son siete las

secciones que le otorgan solidez a una forma:

48


1. Encabezado.

2. Identificación y acceso.

3. Instrucciones.

4. Cuerpo de la forma.

5. Firma y verificación.

6. Totales.

7. Comentarios.

Una de las tareas contribuyentes a todo trabajo, es revisar las formas de que se

dispone actualmente, a fin de verificar su performance con respecto a si

cumplen con los lineamientos y las secciones descriptas, hecho que en algunos

casos implicará la sugerencia de rediseños.

10.3. Lineamientos de Pantallas

Si bien no es objeto de este aporte, a fin de completar el marco teórico, resulta

oportuno definir algunos lineamientos para el diseño de las pantallas :

1. Sencillez.

2. Presentación consistente.

3. Facilidad de “navegación” o movimiento entre las mismas.

4. Diseño atractivo.

Asimismo, deberá maximizarse el uso de opciones predeterminadas para los

datos bajo la estructura de los denominados “combos”, con una codificación

semántica efectiva a efectos de minimizar errores de carga, como así también la

utilización de menús desplegables y mensajes en lenguaje natural a fin de que la

interfaz con el usuario resulte segura, eficiente y agradable.



Simultáneamente, deberá lograrse el objetivo de una clara estrategia de

mecanismos de programación destinados a lograr una efectiva retroalimentación

para el usuario a fin de que este pueda conocer claramente que:

Ha ingresado correctamente un dato.

Existen datos inexcusables sin cuya carga no se puede continuar.

Otros datos son deseables pero no excluyentes.

El proceso demanda un tiempo importante.

La transacción en curso ha sido cancelada.

Resulta obvio destacar la importancia de mecanismos de ayuda en línea,

sensibles al contexto, para evitar la cancelación innecesaria de la operación en

curso o para brindar información acerca de los atributos requeridos a un dato.

10.4. Aseguramiento de la Calidad de los Datos

Si se toma en consideración el modelo simplificado de resolución de problemas

en términos de Entrada, Proceso y Salida, se aprecia claramente la importancia

de asegurar los mecanismos de entrada para garantizar que sean eliminados los

problemas más habituales que pueden presentarse en esta etapa. En la misma se

conjugan dos aspectos, el de las transacciones y el de los datos. En el primer

caso, los inconvenientes principales suelen ser tres:

1. Capturar datos equivocados.

2. Permitir el acceso a los datos a personas no autorizadas.

3. Pedir al sistema que realice una función incorrecta.

Con relación a los datos, resulta oportuno que las aplicaciones incluyan

procedimientos que exploren y garanticen:

Evaluación de los atributos de los mismos en cuanto a tipo de datos,

longitud, precisión y toda otra característica proveniente de la información

descriptiva disponible, comúnmente denominados metadatos o “datos

acerca de los datos”.

Completitud de los mismos.



Análisis de consistencia y congruencia.

Nuestra experiencia demuestra que ante resultados adversos, es bastante común

que se hagan cuestionamientos a la información recibida. Dado que esta es el

resultado de aplicar diferentes “funciones de transformación” a los datos, resulta

imprescindible garantizar que las funciones son las adecuadas (objetivo más

sencillo de lograr) y que los datos son correctos en tiempo, forma y contenido.

Lo anteriormente expresado, permite exhibir sólidos argumentos acerca de la

calidad de los datos ante los embates mencionados.

10.5. Bases de Datos:

Siendo el sustrato donde descansará la exactitud de las producciones de

información, resulta importante destacar que, desde la concepción del modelo de

datos hasta su concreción en bases de datos relacionales, deben tenerse presentes

los siguientes objetivos de eficacia:

1. Asegurar que los datos puedan ser compartidos por los usuarios para una

variedad de aplicaciones.

2. Que el mantenimiento de los datos sea preciso y consistente.

3. Asegurar que todos los datos requeridos para las aplicaciones presentes y

futuras se encuentren siempre disponibles.

4. Permitir que la base de datos evolucione y se adapte a las necesidades

crecientes de los usuarios.

5. Permitir que los usuarios desarrollen su propia visión de los datos, sin

preocuparse por la manera en que los datos se encuentren almacenados

físicamente.

Una relación entre realidad, datos y metadatos se aprecia en la siguiente figura:



Figura 10.2. Relación entre realidad, datos y metadatos.

10.5.1. Normalización del modelo de datos:

En lo que a datos se refiere, todo el diseño debe estar normalizado,

respetándose los tres pasos de la normalización (tanto como resulte

operativamente posible), a fin de obtener estructuras de datos de menor

tamaño.

A modo de recordatorio, citemos que existen tres formas normales resultantes

de cada uno de los siguientes pasos:

1. Eliminar los grupos repetidos y establecer la clave primaria.

2. Asegurar que todos los atributos que no sean clave, sean completamente

dependientes de la misma.

3. Eliminar cualquier dependencia transitoria de atributos no claves de otros

que tampoco lo son.

10.5.2. Tipos de consulta:

Se denomina “consulta” a las preguntas a las que se pretende dar respuesta

con sustento en el contenido de la base de datos.

La literatura reconoce seis tipos básicos de consultas, cada una de ellas

involucra tres elementos: entidad, atributos y valor según se aprecia en la

siguiente tabla resumen:

TIPO DE

CONSULTA ENTRADA SALIDA NOTACIÓN (*)

Entidades Atributos

Registro de

Ocurrencias

Datos de

Ocurrencias

Definición de

registros Definición de

los datos

REALIDAD

DATOS

METADATOS



TIPO DE

CONSULTA ENTRADA SALIDA NOTACIÓN (*)

Tipo 1 Entidad, Atributo Valor V = f (E,A)

Tipo 2 Valor, Atributo Entidad E = f (V,A)

Tipo 3 Valor, Entidad Atributo A = f (V,E)

Tipo 4 (similar a 1) Entidad, Atributos (todos) Valores (todos) TodoV = f (E,todosA)

Tipo 5 (similar a 2) Valor, Atributos (todos) Entidades (todas) TodaE = f (V,todosA)

Tipo 6 (similar a 3) Valor, Entidades (todas) Atributos (todos) TodoA = f (V,todasE)

(*) Por razones de prolijidad, hemos reemplazado con “ = f ” el símbolo “ ”

Tabla 10.1. Tipos de consulta según relaciones entre entidad, atributos y valor.

Consultas más complejas pueden construirse utilizando como elementos las descriptas

anteriormente.

10.6. Enfoque del Aseguramiento de la Calidad Total

El uso del aseguramiento de la calidad debe ser un objetivo a lograr pues, a lo

largo del proceso del desarrollo de un sistema, reduce riesgos y ayuda para que

el producto resultante sea el que deseamos y necesitamos, en definitiva, que

demuestre su valía al incidir en el desempeño de la organización.

A menudo se usan términos tales como: control de calidad, aseguramiento de la

calidad y calidad total, para marcar sus diferencias, Tomassino49

, en su obra

oportunamente citada, presenta la siguiente tabla comparativa:

Control de calidad Aseguramiento de la calidad Calidad total

No existe una política

de calidad

Existe una política que se aplica

a las funciones relacionadas con

el producto o servicio.

Se aplica a toda la empresa y a las

organizaciones relacionadas con

ella.

Se realiza sobre el

producto o servicio

terminado.

Su objetivo es la prevención para

evitar defectos.

Su objetivo es la mejora continua.

Considera al costo de

detectar errores

cometidos.

Alto costo.

Favorece el ahorro ya que evita

la realización de errores.

Considera los costos de todas las

funciones, pero la fundamental es la

satisfacción del cliente.

Considera al recurso

humano como pasible

Considera los recursos humanos

en relación con su formación y

Considera los recursos humanos

como factor fundamental del éxito

49

Tomassino et al., op. cit.



Control de calidad Aseguramiento de la calidad Calidad total

de sanciones por los

errores cometidos.

capacitación. del método. No es tan importante la

capacitación como la motivación.

Tabla 10.2. Comparación entre control, aseguramiento y calidad total.

Debe existir un esfuerzo sincronizado entre la calidad y los Centros de

Desarrollo de Sistemas a fin de evitar al final del proyecto, invertir un gran

esfuerzo para resolver problemas.

Por lo tanto, resulta importante el establecer con los usuarios los estándares de

calidad de los Sistemas de Información y una vez implantados, actualizarlos

periódicamente para nuevos sistemas o modificaciones relevantes a los

existentes.

11. MEDIDA DEL ÉXITO DEL SISTEMA

Laudon50

, al preguntarse “¿Cómo se puede saber si un sistema tiene o no éxito?”

asevera que “Ésta no es siempre una pregunta fácil de responder. No todos

pueden estar de acuerdo con el valor de la eficacia de un sistema de información

en particular. Las personas con diferentes estilos de toma de decisiones o modos

de enfocar un problema pueden tener opiniones totalmente diferentes acerca del

mismo sistema. Un sistema calificado muy alto por un usuario analítico orientado

cuantitativamente puede ser totalmente rechazado por un pensador intuitivo que

está más preocupado por los sentimientos y las impresiones generales.”

Concurre a esta visión Henry Lucas51

cuando concluye que “La percepción y uso

de los sistemas de información puede quedar fuertemente condicionado por

variables personales y situacionales.”

Si bien los beneficios de un sistema de información pueden no ser totalmente

cuantificables, dificultad a la que se suma que los beneficios tangibles, en su

totalidad, a veces, son difícilmente demostrables para las aplicaciones de sistemas

más avanzados de soporte a decisiones, una recopilación a través de diversos

autores permite concluir que se consideran como las más importantes medidas del

éxito de un sistema las siguientes:

50

Laudon, op. cit.



Nivel elevado del uso del sistema.

Satisfacción de los usuarios con el sistema.

Actitudes favorables.

Objetivos alcanzados.

Recuperación financiera.

En todo caso, la mínima aspiración debiera ser cubrir plenamente los primeros

cuatro puntos.

51

Lucas H., “Toward Creative System Design”, Columbia Univ. Press, New York, 1974



INDICE:

360° SOBRE SISTEMAS ............................................................................................................................ 1

1. SISTEMA ORGANIZACIÓN ................................................................................................................. 2

1.1. Cultura de la Organización .............................................................................................................. 2

1.2. Sistemas de Información .................................................................................................................. 2

1.2.1. Definiciones de Sistemas de Información .................................................................................. 2

1.2.2. Tipos de Sistemas de Información ............................................................................................. 3

1.2.3. Interrelación entre los tipos de Sistemas de Información DPS, MIS y DSS .............................. 5

1.2.4. Interrelación entre Soporte Físico y Lógico ............................................................................... 6

2. FASES EN LA SOLUCION DE PROBLEMAS ..................................................................................... 7

2.1. Dimensiones de un problema: .......................................................................................................... 8

3. CICLO DE DESARROLLO DEL SISTEMA (CDS/SDLC) .................................................................. 9

4. METODOLOGÍAS INTEGRALES DE ANÁLISIS, DISEÑO Y DESARROLLO DE SISTEMAS

DE INFORMACIÓN ................................................................................................................................. 10

5. ACTIVIDADES EN UN PROYECTO.................................................................................................. 11

6. EL PROCESO DE RELEVAMIENTO ................................................................................................. 12

6.1. Recomendaciones para las entrevistas: .......................................................................................... 13

6.2. Tipos de preguntas: ........................................................................................................................ 14

6.3. Recomendaciones para los cuestionarios: ...................................................................................... 15

6.4. Recomendaciones para las dimensiones de la información: .......................................................... 16

6.5. Recomendaciones para las escalas: ................................................................................................ 17

7. EL PROCESO DE ANALISIS DEL SISTEMA ................................................................................... 17

7.1. Análisis de Sistemas Orientado a Datos ......................................................................................... 18

7.2. Recomendaciones para los diagramas Entidad – Relación (y atributos): ....................................... 18

7.3. Recomendaciones para analizar el flujo de datos: ......................................................................... 18

Ventajas: ............................................................................................................................................ 19

Símbolos: ........................................................................................................................................... 19

Convenciones: .................................................................................................................................... 19

Convenciones suplementarias: ........................................................................................................... 20

Pasos a seguir en un DFD: ................................................................................................................. 20

Diagrama de contexto: ....................................................................................................................... 21

7.4. Recomendaciones para el Diccionario de Datos: ........................................................................... 21

Pasos para la creación de un diccionario de datos: ............................................................................ 21

Atributos a registrar: .......................................................................................................................... 22

7.5. Estilos de Toma de Decisiones: ..................................................................................................... 22

Información y certeza ............................................................................................................................ 23

Indicadores ............................................................................................................................................. 23

7.5.1. Decisiones Semiestructuradas ...................................................................................................... 24

7.5.2. Decisiones de Criterio u Objetivo Múltiple ................................................................................. 25



Métodos para evaluar problemas de criterios u objetivos múltiples: ..................................................... 26

7.6. Análisis de Sistemas con Decisiones Estructuradas ...................................................................... 26

Métodos: ................................................................................................................................................ 26

7.7. Análisis de Sistemas de Apoyo para Decisiones Semiestructuradas: ............................................ 29

8. PREPARACION DE LA PROPUESTA DEL SISTEMA ..................................................................... 31

9. DISEÑO Y DESARROLLO DE SISTEMAS ....................................................................................... 32

9.1. Diseño Ascendente o bottom-up: ................................................................................................... 32

9.2. Diseño Descendente o top-down: .................................................................................................. 32

9.3. Desarrollo modular: ....................................................................................................................... 32

9.4. Diagrama Estructural: .................................................................................................................... 33

10. ELEMENTOS ESENCIALES DE DISEÑO ...................................................................................... 34

10.1. Diseño Efectivo de Salidas ........................................................................................................... 35

10.2. Diseño Efectivo de Entradas ......................................................................................................... 37

10.3. Lineamientos de Pantallas ............................................................................................................. 38

10.4. Aseguramiento de la Calidad de los Datos ................................................................................... 39

10.5. Bases de Datos: ............................................................................................................................. 40

10.5.1. Normalización del modelo de datos: ......................................................................................... 41

10.5.2. Tipos de consulta: ..................................................................................................................... 41

10.6. Enfoque del Aseguramiento de la Calidad Total .......................................................................... 42

11. MEDIDA DEL ÉXITO DEL SISTEMA ............................................................................................. 43

INDICE: ..................................................................................................................................................... 45

para tesis - frlp.utn.edu.ar sobre sistemas.pdf · su génesis se remonta a la teoría general de...

Documents