sábado, 2 de febrero de 2013

Estudio de Factibilidad de un Sistema de Informacion.

  • Descripción del Entorno
    • Como quiera que se va a trabajar a posteriori en equipo, los analistas iniciales deben describir el entorno organizacional en donde se va a desarrollar el SI. Se debe hacer una breve reseña de la empresa (fecha de inicio de actividades, domicilio, ramo al cual se dedica, organigrama general), y una breve reseña de la Unidad Funcional específica a la cual se le desarrollará el SI.
    • En las fases de cualquier Metodología de Desarrollo de Sistemas de Información se deben emplear técnicas de recolección de información.
      • Entrevistas
        • Individuales o Grupales
        • Estructuradas o No Estructuradas
      • Cuestionarios
        • Abiertos o Cerrados
      • Observación
  • Identificación del Problema
    • Es primordial que se identifique el problema, para poder tener más claro cuáles pueden ser las posibles soluciones que se van a presentar.
El problema no puede ser que el sistema actual es manual o que no existe.  Se debe hallar el problema real (por ejemplo: lentitud en los procesos, inexactitud en los resultados, retrabajo, procesos engorrosos, etc.).

  • Identificación de los Procedimientos Actuales
    • Se deben identificar, a grosso modo, los procedimientos generales que se llevan a cabo actualmente en la Unidad Funcional.
  • Presentación de las Posibles Soluciones al Problema
    • Se deben presentar al menos tres (03) posibles soluciones al Problema identificado. El presentarle una sola solución al usuario o cliente es forzarle a elegir una única propuesta. Al ofrecer al menos tres (03) posibles soluciones el usuario se sentirá que tiene la libertad para seleccionar la que considere más conveniente.
    • Normalmente en el ámbito de Desarrollo de Sistemas de Información se pueden presentar tres (03) soluciones clásicas:
      • Optimizar el Sistema Actual (quizás mediante la elaboración de procedimientos escritos, formatos, establecimiento de controles)
      • Adquirir una aplicación existente en el mercado y adaptarla a la organización
      • Desarrollar una aplicación hecha a la medida
    • Normalmente el costo del Hardware no es pertinente en un desarrollo de S.I., ya que lo que si es importante es el Software
    • En caso de que el cliente o usuario requiera Hardware, se deberá colocar en otra propuesta aparte
    • Aún, en esta etapa, no se conocen a ciencia cierta los requerimientos exactos de Hardware
  • Validación de las Posibles Soluciones
    • Todas las Posibles Soluciones a presentar deben ser factibles, desde el punto de vista Operativo, Técnico y Económico.
      • Factibilidad Técnica (existe tecnología para realizar el S.I.?)
      • Factibilidad Operativa (habrá resistencia al cambio?)
      • Factibilidad Económica (relación beneficio/costo)
    • No se puede ofrecer una solución que no sea factible.
  • Ventajas y Desventajas de cada Posible Solución
    • Se presentan las ventajas y desventajas de cada Posible Solución, a fin de ofrecerle al cliente una base más sólida para la toma de decisiones y selección de la solución más adecuada.
  • Cuadro comparativo de Costos y Tiempos de Ejecución
    • Se elabora un cuadro comparativo, donde se presenta cada solución, con su respectivo costo y tiempo de ejecución, a fin de presentarle de manera más resumida al usuario las opciones disponibles.
  • Recomendación
    • De acuerdo a la experiencia del equipo de proyecto, se enuncia la solución más recomendada para ser desarrollada.
    • El Estudio de Factibilidad es una especie de “Presupuesto” que se le presenta al cliente o usuario
    • El Estudio de Factibilidad también puede conocerse como “Propuesta del Sistema”
    • Una vez aprobado el Estudio de Factibilidad por el Comité de Sistemas, clientes o usuarios, se procede con las siguientes etapas del Desarrollo.
La Carta Estructurada.

La carta estructurada tambien es conocida como el modelo de producto, es una metodologiá de análisis y diseño de sistemas de análisis estructurado, lo que muestra es un mapa de diseño de arriba hacia abajo (top-down) de tipo jerárquico en el que se asienta cómo será programado el proyecto, construido, integrado y probado.

Hay una herramienta CASE que se llama Visible Analyst y te permite modelar análisis estructurado y orientado a objetos.

El diseño modular te permite asentar "los módulos" en los que estará dividida tu aplicación, digamos que ordenas tus módulos de manera que puedas "dividir el trabajo". Por ejemplo, si vas a hacer un sistema administrativo para una empresa a lo mejor tienes tus módulos de nómina, personal, inventario, compras, ventas, etc por decir algo. A lo mejor tu cliente necesita urgentemente primero la nómina; entonces es necesario que hagas el diseño de los módulos de todo el sistema para que desde el principio se tome en cuenta su crecimiento, o para dividir en equipos de trabajo que desarrollen los módulos por separado y pueda existir comunicación, estén acordes los datos, entradas con salidas, etc.


sábado, 5 de enero de 2013

Metodologia de Kendall & Kendall

Metodologia kendall y kendal

Implementación y evaluación del sistema

1. Planificar gradualmente la conversión del sistema anterior.
2. Instalar los equipos de hardware necesarios para el funcionamiento del software creado.
3. Capacitar por medio de talleres a los usuarios en el manejo de equipos y software creados.
4. 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.

Prueba y mantenimiento del sistema

1. Realizar la programación de las pruebas del sistema.
2. Realizar un instrumento para evaluar el sistema de información
3. El programador deberá elaborar un resumen de las pruebas del sistema.
4. El analista deberá realizar un informe de sus pruebas y discutirlo con el programador
5. Elaborar la planificación de las horas del mantenimiento del sistema
6. 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.

Desarrollo y documentación del software
1. Evaluar los procedimientos que va a ser desarrollados por el programador
2. Mostrar y explicar cada procedimiento, función y operación al programador
3. Elaborar manuales de procedimientos internos del sistema.
4. Elaborar manuales externos de ayuda a los usuarios del sistema.
5. Elaborar demostraciones para los usuarios y la interacción con distintas interfaces
6. Elaborar actualizaciones para los diferentes procedimientos
7. 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.
Diseño del sistema recomendado
1. Evaluar las tres fases anteriores.
2. Realizar el diseño lógico de todo el sistema.
3. Elaborar procedimientos precisos para la captura de los datos que van a ingresar al sistema de información
4. Elaborar el diseño de la base de datos.
5. Diseñar las diferentes interfaces de usuarios de cada operación, procedimiento y/o función.
6. Diseñar controles y procedimientos de respaldos que protejan al sistema y a los datos
7. Producir los paquetes específicos de programas para los programadores
8. 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 de los 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.

domingo, 14 de octubre de 2012


EL CICLO DE DESARROLLO DE LOS SISTEMAS

El analista debería aplicar un enfoque sistemático en el análisis y el diseño de los sistemas de información. El ciclo de desarrollo de los sistemas o ciclo de vida de los sistemas (SDLC: Systems Devetopment Life Cycle) es un enfoque por etapas de análisis y de diseño, que postula que el desarrollo de los sistemas mejora cuando existe un ciclo específico de actividades del analista y de los usuarios.
En general, los analistas no están de acuerdo respecto al número exacto de etapas que conforman el ciclo de desarrollo de los sistemas;  sin embargo, se reconoce la importancia de su enfoque sistemático.    Se dividirá   el ciclo de vida en siete etapas, que aunque se presentan de manera discreta, nunca se llevan a cabo    como     un     elemento Independiente. En lugar de ello. se realizan al mismo tiempo diversas actividades, y éstas llegan a repetirse. Por ello es de mayor utilidad suponer que e! ciclo de desarrollo de los sistemas transcurre en etapas (con actividades en acción que luego cesan poco a poco) y no como elementos separados.

1) Identificación de problemas, oportunidades y objetivos.
En esta primera etapa del ciclo de desarrollo de los sistemas, el analista se involucra en la identificación de los problemas, de las oportunidades y de los objetivos.  Esta fase es crucial para el éxito del resto del proyecto, pues  nadie estará dispuesto a desperdiciar su tiempo dedicándolo al problema equivocado.
La primera etapa requiere que el analista observe de forma objetiva lo que ocurre en una empresa. Luego, en conjunto con los otros miembros de la organización hará notar los problemas.  Muchas veces esto ya fue realizado previamente: y por ello. es que se llega a invitar al analista.
Las oportunidades son  acuellas situaciones que el analista considera que pueden perfeccionarse mediante el uso de los sistemas de información computarizados. Al  aprovechar las oportunidades, la empresa puede lograr una ventaja competitiva o llegar a establecer un estándar industrial.
La identificación de objetivos también es un componente importante de la primera fase.  En un comienzo, el analista deberá descubrir lo que la empresa intenta realizar, y luego. estará en posibilidad de determinar si el uso de los sistemas de información apoyaría a la empresa para alcanzar sus   metas,   el   encaminarla   a problemas     u     oportunidades específicas.

2) Determinación de los requerimientos de información.
La siguiente etapa que aborda el analista, es la determinación de los requerimientos de información a partir de  los  usuarios  particularmente involucrados.   Para identificar los requerimientos de información dentro de ¡a empresa, pueden utilizarse diversos instrumentos, los cuales incluyen: el muestreo, el estudio de los datos y formas usadas por la organización,   la   entrevista,   los cuestionarios: la observación de la conducta   de   quien   toma   las decisiones, asi como de su ambiente: y también el desarrollo de prototipos.
En esta etapa el analista hace todo lo posible por identificar qué información requiere el usuario para desempeñar sus tareas. Puede ver, cómo varios de los métodos para establecer las necesidades  de  información,   lo obligan a relacionarse directamente con los usuarios. Esta etapa sirve para elaborar la imagen que el analista tiene de la organización y de sus objetivos. En ocasiones, se llegan a concluir sólo las primeras dos etapas del ciclo de desarrollo de los sistemas.      El analista  es  e! especialista que emprende esta clase de estudios.

3) Análisis de las necesidades del sistema.
La siguiente etapa que ejecuta el analista de sistemas consiste en analizar las necesidades propias del sistema.    Una vez más, existen herramientas y técnicas especiales que facilitan al analista la realización de las determinaciones requeridas. Estas incluyen  el  uso de losdiagramas de flujo de datos (DFD)que cuentan con una técnica estructurada para representar en forma gráfica la entrada de datos de la empresa, los procesos y la salida de la información. A partir del diagrama de flujo de datos se desarrolla un diccionario de datos que contiene todos los elementos que utiliza el sistema, así como sus especificaciones,       si       son alfanuméricos,   descripción,   clave primaria, entre otros.
Durante esta fase. el analista de sistemas   también   analiza   las decisiones estructuradas por realizar, que  son  decisiones  donde  las condiciones, condiciones alternativas, acciones y reglas de acción podrán determinarse. Existen tres métodos para el análisis de las decisiones estructuradas:      el      lenguaje estructurado (en nuestro caso el español), las tablas de decisión y los árboles de decisión.

No todas   las decisiones en las empresas      se      encuentran estructuradas;   no   obstante,   es importante que las comprenda e! analista de sistemas. Las decisiones semiestructuradas (decisiones que se toman bajo nesgo) con frecuencia se apoyan en los Sistemas de Toma de Decisiones.    Cuando analiza las decisiones   semiestructuradas.   el analista las examina de acuerdo con el grado de complejidad del problema y con el  número de criterios considerados al llevar a cabo las decisiones.
El análisis de decisiones de criterio múltiple (aquellas decisiones donde numerosos  factores  tienen   que equilibrarse) también es parte de esta etapa.   Se disponen de muchas técnicas para e' análisis de decisiones de criterio múltiple; incluyendo entre otras, e! proceso de intercambio y la aplicación de métodos de ponderado.
A esta altura del ciclo de desarrollo del sistema, el analista prepara una propuesta del sistema que resume todo lo que ha encontrado, presenta un análisis costo / beneficio de las alternativas    y    plantea    las recomendaciones (si es que existen) de lo que deberá realizarse.  Si la dirección acepta alguna de las recomendaciones,     el     analista procederá de acuerdo con ella.

4)    Diseño    del sistema recomendado.
En esta etapa del ciclo de desarrollo de los sistemas, el analista de sistemas usa la información que recolectó con anterioridad y elabora el diseño  lógico   del   sistema   de
información.    El analista diseña procedimientos precisos de captura de datos, con el fin de que los datos que se introducen al sistema sean los correctos. Ei analista también diseña accesos   efectivos al sistema de información, mediante el uso de las técnicas de diseño de formularios y de pantallas.
Una parte del diseño lógico del sistema de información es el diseño de la interfaz con el usuario.   La interfaz conecta al usuario con el sistema, y evidentemente, es de suma importancia. Serían ejemplos de interfaces para el usuario: el uso del teclado para introducir preguntas o respuestas, el uso de menús en la pantalla, con las opciones que tiene el usuario, el uso de dispositivos como el ratón (mouse) y muchos otros.
La etapa del diseño también incluye e! diseño de los archivos o la base de datos que almacenará aquellos datos requeridos  por quien toma  las decisiones en la organización. Una base de datos bien organizada es fundamental para cualquier sistema de información.  En esta etapa, el analista diseña la salida (en pantalla o impresa) hacia el usuario, de acuerdo con sus necesidades de información.
5) Desarrollo y documentación del software
En esta etapa del ciclo de desarrollo de los sistemas, el analista trabaja con    los   programadores    para desarrollar todo el software original

que sea necesario.  Dentro de las técnicas estructuradas para el diseño y documentación de! software se tienen:   el   método   HIPO,   los diagramas de flujo. ios diagramas Nassi-Schneiderman, ios diagramas Warnier-Orr y el pseudocódigo. Aquí es donde, el analista de sistemas transmite   al   programador   los requerimientos de programación.
Durante esta fase, el analista también colabora con los usuarios para desarrollar    la    documentación indispensable     del     software, incluyendo los  manuales     de procedimientos. La documentación le dirá al usuario como operar el software, y así también, qué hacer en caso de presentarse algún problema.
6) Pruebas v mantenimiento del sistema.
El sistema de información debe probarse antes de utilizarlo. E! costo es  menor  si  se  detectan  los problemas antes cié la entrega del sistema.   El programador realiza algunas pruebas por su cuenta, otras se llevan a cabo en colaboración con el analista de sistemas.   En un principio, se hace una serie de pruebas,  con  datos  tipo,   para identificar las posibles fallas del sistema: más adelante, se utilizarán los datos reales.
El mantenimiento del sistema y de su documentación empiezan justamente en esta etapa: y después,   esta función se realizará de forma rutinaria a lo largo de toda la vida del sistema. Las actividades de mantenimiento integran una buena parte de la rutina
del programador, que para las empresas    llegan    a    implicar importantes sumas de dinero.  Sin embargo, el costo del mantenimiento disminuye de manera importante cuando    el    analista    aplica procedimientos sistemáticos en el desarrollo de los sistemas.
7) Implantación v evaluación de sistema.
En esta última etapa del desarrollo del sistema, el analista ayuda a implantar el sistema de   información.   Esto incluye el adiestramiento que el usuario requerirá. Si bien, parte de esta capacitación la dan las casas comerciales,   la   supervisión   del adiestramiento        es        una responsabilidad   del   analista   de sistemas.    Más aún, el analista necesita planear la suave transición que trae consigo un cambio de sistemas.
Aunque la evaluación del sistema se plantea como parte integrante de la última etapa del ciclo de desarrollo de los sistemas; realmente, la evaluación toma parte en cada una de las etapas.     Uno de los criterios fundamentales que debe satisfacerse, es que ei futuro usuario utilice el sistema desarrollado.


martes, 25 de septiembre de 2012

Teoría general de sistema

Echa un vistazo a este vídeo en Youtube:

http://www.youtube.com/watch?v=6KzJ737P8Xs&feature=youtube_gdata_player

lunes, 24 de septiembre de 2012

Teoría general de los Sistemas

Concepto de Sistema

El concepto de sistema en general está sustentado sobre el hecho de que ningún sistema puede existir aislado completamente y siempre tendrá factores externos que lo rodean y pueden afectarlo, por lo tanto podemos referir a Muir citado en Puleo (1985) que dijo: "Cuando tratamos de tomar algo, siempre lo encontramos unido a algo más en el Universo". (p. 26).

Puleo define sistema como " un conjunto de entidades caracterizadas por ciertos atributos, que tienen relaciones entre sí y están localizadas en un cierto ambiente, de acuerdo con un cierto objetivo". (p. 29).

Una Entidad es lo que constituye la esencia de algo y por lo tanto es un concepto básico. Las entidades pueden tener una existencia concreta , si sus atributos pueden percibirse por los sentidos y por lo tanto son medibles y una existencia abstracta si sus atributos están relacionados con cualidades inherentes o propiedades de un concepto.

Los Atributos determinan las propiedades de una entidad al distinguirlas por la característica de estar presentes en una forma cuantitativa o cualitativa.

Los atributos cuantitativos tienen dos percepciones: La dimensión y la magnitud. La dimensión es una percepción que no cambia y que identifica al atributo, para lo cual se utilizan sistemas de medida basado en unidades o patrones, tales como el CGS, MKS, etc.; ejemplos de dimensión son Kg., tamaño, sexo, color, etc. La magnitud es la percepción que varía y que determina la intensidad del atributo en un instante dado de tiempo, para lo cual se utilizan escalas de medida, tales como: la nominal, la ordinal, la de intervalo y la de razón, ejemplos de magnitud son: 30 Kg., 20 empleados, etc.

Las Relaciones determinan la asociación natural entre dos o más entidades o entre sus atributos. Estas relaciones pueden ser estructurales, si tratan con la organización, configuración, estado o propiedades de elementos, partes o constituyentes de una entidad y son funcionales, si tratan con la acción propia o natural mediante la cual se le puede asignar a una entidad una actividad en base a un cierto objetivo o propósito, de acuerdo con sus aspectos formales (normas y procedimientos) y modales (criterios y evaluaciones).

El Ambiente es el conjunto de todas aquellas entidades, que al determinarse un cambio en sus atributos o relaciones pueden modificar el sistema.

El Objetivo es aquella actividad proyectada o planeada que se ha seleccionado antes de su ejecución y está basada tanto en apreciaciones subjetivas como en razonamientos técnicos de acuerdo con las características que posee el sistema.

Teoría General de Sistemas

La idea de la teoría general de sistemas fue desarrollada por L. Von Bertalanffy alrededor de 1930, posteriormente un grupo de personas unieron sus inquietudes en lo que se llamó la Sociedad para la Investigación de Sistemas Generales, establecidas en 1954 junto con Anatol Rapoport, Kenneth Boulding, Ralph Gerard y otros.

Al estudiar la teoría de sistemas se debe comenzar por las premisas o los supuestos subyacentes en la teoría general de los sistemas. Boulding (1964) intentó una síntesis de los supuestos subyacentes en la teoría general de los sistemas y señala cinco premisas básicas. Dichas premisas se podrían denominar igualmente postulados (P), presuposiciones o juicios de valor.

P1. El orden, la regularidad y la carencia de azar son preferibles a la carencia de orden o a la irregularidad (caos) y a la existencia de un estado aleatorio.

P2. El carácter ordenado del mundo empírico hace que el mundo sea bueno, interesante y atrayente para el teórico de los sistemas.

P3. Hay orden en el ordenamiento del mundo exterior o empírico (orden en segundo grado): una ley de leyes.

P4. Para establecer el orden, la cuantificación y la matematización son auxiliares altamente valiosos.

P5. La búsqueda de la ley y el orden implica necesariamente la búsqueda de los referentes empíricos de este orden y de esta ley.

El teórico general de sistemas no es tan sólo un investigador del orden en el orden y de las leyes de leyes; busca las materializaciones concretas y particularistas del orden abstracto y de la ley formal que descubre.

La búsqueda de referentes empíricos para abstraer un orden y leyes formales puede partir de uno u otro de los dos puntos iniciales, el origen teórico y el empírico. El teórico de sistemas puede comenzar con alguna relación matemática elegante y luego indagar a su alrededor el mundo empírico para ver si puede encontrar algo que encaje en esa relación, o puede comenzar con algún orden empírico cuidadosa y pacientemente elaborado en el mundo de la experiencia y luego registrar el mundo abstracto de la matemática hasta encontrar alguna relación que lo ayude a simplificar ese orden o a relacionarlo con otras leyes con los cuales esta familiarizado.

En consecuencia, la teoría general de los sistemas, al igual que todas las ciencias verdaderas, se basa en una búsqueda sistemática de la ley y el orden en el universo; pero a diferencia de las otras ciencias, tiende a ampliar su búsqueda, convirtiéndola en una búsqueda de un orden de órdenes, de una ley de leyes. Este es el motivo por el cual se le ha denominado la teoría general de sistemas.

Características de la Teoría General de Sistemas

Según Schoderbek y otros (1993) las características que los teóricos han atribuido a la teoría general de los sistemas son las siguientes:

Interrelación e interdependencia de objetos, atributos, acontecimientos y otros aspectos similares. Toda teoría de los sistemas debe tener en cuenta los elementos del sistema, la interrelación existente entre los mismos y la interdependencia de los componentes del sistema. Los elementos no relacionados e independientes no pueden constituir nunca un sistema.
Totalidad. El enfoque de los sistemas no es un enfoque analítico, en el cual el todo se descompone en sus partes constituyentes para luego estudiar en forma aislada cada uno de los elementos descompuestos: se trata más bien de un tipo gestáltico de enfoque, que trata de encarar el todo con todas sus partes interrelacionadas e interdependientes en interacción.
Búsqueda de objetivos. Todos los sistemas incluyen componentes que interactúan, y la interacción hace que se alcance alguna meta, un estado final o una posición de equilibrio.
Insumos y productos. Todos los sistemas dependen de algunos insumos para generar las actividades que finalmente originaran el logro de una meta. Todos los sistemas originan algunos productos que otros sistemas necesitan.
Transformación. Todos los sistemas son transformadores de entradas en salidas. Entre las entradas se pueden incluir informaciones, actividades, una fuente de energía, conferencias, lecturas, materias primas, etc. Lo que recibe el sistema es modificado por éste de tal modo que la forma de la salida difiere de la forma de entrada.
Entropía. La entropía está relacionada con la tendencia natural de los objetos a caer en un estado de desorden. Todos los sistemas no vivos tienden hacia el desorden; si los deja aislados, perderán con el tiempo todo movimiento y degenerarán, convirtiéndose en una masa inerte.
Regulación. Si los sistemas son conjuntos de componentes interrelacionados e interdependientes en interacción, los componentes interactuantes deben ser regulados (manejados) de alguna manera para que los objetivos (las metas) del sistema finalmente se realicen.
Jerarquía. Generalmente todos los sistemas son complejos, integrados por subsistemas más pequeños. El término "jerarquía" implica la introducción de sistemas en otros sistemas.
Diferenciación. En los sistemas complejos las unidades especializadas desempeñan funciones especializadas. Esta diferenciación de las funciones por componentes es una característica de todos los sistemas y permite al sistema focal adaptarse a su ambiente.
Equifinalidad. Esta característica de los sistemas abiertos afirma que los resultados finales se pueden lograr con diferentes condiciones iniciales y de maneras diferentes. Contrasta con la relación de causa y efecto del sistema cerrado, que indica que sólo existe un camino óptimo para lograr un objetivo dado. Para las organizaciones complejas implica la existencia de una diversidad de entradas que se pueden utilizar y la posibilidad de transformar las mismas de diversas maneras. (pp.

Entrada , Proceso y Salida de un Sistema de Información

Entrada de Información: Es el proceso mediante el cual el Sistema de Información toma los datos que requiere para procesar la información. Las entradas pueden ser manuales o automáticas. Las manuales son aquellas que se proporcionan en forma directa por el usuario, mientras que las automáticas son datos o información que provienen o son tomados de otros sistemas o módulos. Esto último se denomina interfases automáticas.

Las unidades típicas de entrada de datos a las computadoras son las terminales, las cintas magnéticas, las unidades de diskette, los códigos de barras, los escáners, la voz, los monitores sensibles al tacto, el teclado y el mouse, entre otras.

Almacenamiento de información: El almacenamiento es una de las actividades o capacidades más importantes que tiene una computadora, ya que a través de esta propiedad el sistema puede recordar la información guardada en la sección o proceso anterior. Esta información suele ser almacenada en estructuras de información denominadas archivos. La unidad típica de almacenamiento son los discos magnéticos o discos duros, los discos flexibles o diskettes y los discos compactos (CD-ROM).

Procesamiento de Información: Es la capacidad del Sistema de Información para efectuar cálculos de acuerdo con una secuencia de operaciones preestablecida. Estos cálculos pueden efectuarse con datos introducidos recientemente en el sistema o bien con datos que están almacenados. Esta característica de los sistemas permite la transformación de datos fuente en información que puede ser utilizada para la toma de decisiones, lo que hace posible, entre otras cosas, que un tomador de decisiones genere una proyección financiera a partir de los datos que contiene un estado de resultados o un balance general de un año base.

Salida de Información: La salida es la capacidad de un Sistema de Información para sacar la información procesada o bien datos de entrada al exterior. Las unidades típicas de salida son las impresoras, terminales, diskettes, cintas magnéticas, la voz, los graficadores y los plotters, entre otros. Es importante aclarar que la salida de un Sistema de Información puede constituir la entrada a otro Sistema de Información o módulo. En este caso, también existe una interfase automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interfase automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.