jueves, 12 de julio de 2012

Fundamento de la Ingeniería del software

Fundamento de la Ingeniería del software

El software
Se conoce como software al equipamiento lógico o soporte lógico de un sistema informático, comprende el conjunto de los componentes lógicos necesarios que hacen posible la realización de tareas específicas, en contraposición a los componentes físicos, que son llamados hardware.
Los componentes lógicos incluyen, entre muchos otros, las aplicaciones informáticas; tales como el procesador de texto, que permite al usuario realizar todas las tareas concernientes a la edición de textos; el software realizado, tal como el sistema operativo, que, básicamente, permite al resto de los programas funcionar adecuadamente, facilitando también la interacción entre los componentes físicos y el resto de las aplicaciones, y proporcionando una interfaz con el usuario.

Cualidades de un software

Correcto 
Confiable 
Robusto 
Eficiente 
Amigable 
Verificable 
Reusable 
Portable 
Interoperable 
Productivo 
ATiempo 
Visible 
Coheso 
Desacoplado 
Comprensible 
Mantenible 


Ingeniería del software

Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software, y el estudio de estos enfoques, es decir, la aplicación de la ingeniería al software.1 Es la aplicación de la ingeniería al software, ya que integra matemáticas, ciencias de la computación y prácticas cuyos orígenes se encuentran en la ingeniería

Visión general del proceso de desarrollo de software

El proceso de desarrollo del software
Un proceso de desarrollo de software tiene como propósito la producción eficaz y eficiente de un producto software que reúna los requisitos del cliente. Este proceso es intensamente intelectual, afectado por la creatividad y juicio de las personas involucradas. Aunque un proyecto de desarrollo  de software es equiparable en muchos aspectos a cualquier otro proyecto de ingeniería, en el desarrollo de software hay una serie de desafíos adicionales, relativos esencialmente a la naturaleza del producto obtenido. A continuación se explican algunas particularidades asociadas al desarrollo de software y que influyen en su proceso de construcción.
Un producto software en sí es complejo, es prácticamente inviable conseguir un 100% de confiabilidad de un programa por pequeño que sea. Existe una inmensa combinación de factores que impiden una verificación exhaustiva de las todas posibles situaciones de ejecución que se puedan presentar (entradas, valores de variables, datos almacenados, software del  sistema, otras aplicaciones que intervienen, el hardware sobre el cual se ejecuta, etc.). 
Un producto software es intangible y por lo general muy abstracto, esto dificulta la definición del producto y sus requisitos, sobre todo cuando no se tiene precedentes en productos software similar. Esto hace que los requisitos sean difíciles de consolidar tempranamente. Así, los cambios en los requisitos son  inevitables, no sólo después de entregado en producto sino también durante el proceso de desarrollo.

Participantes en el desarrollo de software

Este Plan de Desarrollo de Software es una versión preliminar preparada para ser incluida en la propuesta elaborada como respuesta al proyecto de práctica de la asignatura de Sistemas de Información II de la Escuela de Ingeniería de Sistemas e Informática de la Universidad Nacional de la Santa. Este documento provee una visión global del enfoque de desarrollo propuesto. El proyecto ha sido ofertado por el grupo de desarrollo de software Softters basado en una metodología de Rational Unified Process en la que se procederá a cumplir con las cuatro fases que marca la metodología. Es importante destacar esto puesto que utilizaremos la terminología RUP en este documento. Se incluirá el detalle para las fases de Inicio, Elaboración, Construcción y Transición para dar una visión global de todo proceso. El enfoque desarrollo propuesto constituye una configuración del proceso RUP de acuerdo a las características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de RUP.

Ciclo de vida de un software
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren durante el desarrollo de software, intenta determinar el orden de las etapas involucradas y los criterios de transición asociadas entre estas etapas.
Un modelo de ciclo de vida del software:
·         Describe las fases principales de desarrollo de software.
·         Define las fases primarias esperadas de ser ejecutadas durante esas fases.
·         Ayuda a administrar el progreso del desarrollo, y
·         Provee un espacio de trabajo para la definición de un detallado proceso de desarrollo de software.
Así, los modelos por una parte suministran una guía para los ingenieros de software con el fin de ordenar las diversas actividades técnicas en el proyecto, por otra parte suministran un marco para la administración del desarrollo y el mantenimiento, en el sentido en que permiten estimar recursos, definir puntos de control intermedios, monitorear el avance, etc.
Modelo Cascada
Este es el más básico de todos los modelos, y sirve como bloque de construcción para los demás modelos de ciclo de vida. La visión del modelo cascada del desarrollo de software es muy simple; dice que el desarrollo de software puede ser a través de una secuencia simple de fases. Cada fase tiene un conjunto de metas bien definidas, y las actividades dentro de una fase contribuyen a la satisfacción de metas de esa fase o quizás a una subsecuencia de metas de la fase. Las flechas muestran el flujo de información entre las fases. La flecha de avance muestra el flujo normal. Las flechas hacia atrás representan la retroalimentación.
El modelo de ciclo de vida cascada, captura algunos principios básicos:
·         Planear un proyecto antes de embarcarse en él.
·         Definir el comportamiento externo deseado del sistema antes de diseñar su arquitectura interna.
·         Documentar los resultados de cada actividad.
·         Diseñar un sistema antes de codificarlo.
·         Testear un sistema después de construirlo.
Una de las contribuciones más importantes del modelo cascada es para los administradores, posibilitándoles avanzar en el desarrollo, aunque en una escala muy bruta.
Modelo De Desarrollo Incremental
Los riesgos asociados con el desarrollo de sistemas largos y complejos son enormes. Una forma de reducir los riesgos es construir sólo una parte del sistema, reservando otros aspectos para niveles posteriores. El desarrollo incremental es el proceso de construcción siempre incrementando subconjuntos de requerimientos del sistema. Típicamente, un documento de requerimientos es escrito al capturar todos los requerimientos para el sistema completo.
Note que el desarrollo incremental es 100% compatible con el modelo cascada. El desarrollo incremental no demanda una forma específica de observar el desarrollo de algún otro incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo, como se muestra en la figura.
El modelo de desarrollo incremental provee algunos beneficios significativos para los proyectos:
·         Construir un sistema pequeño es siempre menos riesgoso que construir un sistema grande.
·         Al ir desarrollando parte de las funcionalidades, es más fácil determinar si los requerimientos planeados para los niveles subsiguientes son correctos.
·         Si un error importante es realizado, sólo la última iteración necesita ser descartada.
·         Reduciendo el tiempo de desarrollo de un sistema (en este caso en incremento del sistema) decrecen las probabilidades que esos requerimientos de usuarios puedan cambiar durante el desarrollo.
·         Si un error importante es realizado, el incremento previo puede ser usado.
·         Los errores de desarrollo realizados en un incremento, pueden ser arreglados antes del comienzo del próximo incremento.
Modelo De Desarrollo Evolutivo
Como el modelo de desarrollo incremental, el modelo de desarrollo evolutivo (algunas veces denominado como prototipado evolutivo) construye una serie de grandes versiones sucesivas de un producto. Sin embargo, mientras que la aproximación incremental presupone que el conjunto completo de requerimientos es conocido al comenzar, el modelo evolutivo asume que los requerimientos no son completamente conocidos al inicio del proyecto.
En el modelo evolutivo, los requerimientos son cuidadosamente examinados, y sólo esos que son bien comprendidos son seleccionados para el primer incremento. Los desarrolladores construyen una implementación parcial del sistema que recibe sólo estos requerimientos.
El sistema es entonces desarrollado, los usuarios lo usan, y proveen retroalimentación a los desarrolladores. Basada en esta retroalimentación, la especificación de requerimientos es actualizada, y una segunda versión del producto es desarrollada y desplegada. El proceso se repite indefinidamente.
Note que el desarrollo evolutivo es 100% compatible con el modelo cascada. El desarrollo evolutivo no demanda una forma específica de observar el desarrollo de algún incremento. Así, el modelo cascada puede ser usado para administrar cada esfuerzo de desarrollo. Obviamente, el desarrollo incremental y evolutivo puede ser combinado también.
Todo lo que uno tiene que hacer es construir un subconjunto de requerimientos conocidos (incremental), y comprender al principio que muchos nuevos requerimientos es probable que aparezcan cuando el sistema sea desplegado o desarrollado.
El desarrollo de software en forma evolutiva requiere un especial cuidado en la manipulación de documentos, programas, datos de test, etc. desarrollados para distintas versiones del software. Cada paso debe ser registrado, la documentación debe ser recuperada con facilidad, los cambios deben ser efectuados de una manera controlada.
Modelo de Prototipado de Requerimientos
El prototipado de requerimientos es la creación de una implementación parcial de un sistema, para el propósito explícito de aprender sobre los requerimientos del sistema. Un prototipo es construido de una manera rápida tal como sea posible. Esto es dado a los usuarios, clientes o representantes de ellos, posibilitando que ellos experimenten con el prototipo. Estos individuos luego proveen la retroalimentación sobre lo que a ellos les gustó y no les gustó acerca del prototipo proporcionado, quienes capturan en la documentación actual de la especificación de requerimientos la información entregada por los usuarios para el desarrollo del sistema real. El prototipado puede ser usado como parte de la fase de requerimientos (determinar requerimientos) o justo antes de la fase de requerimientos (como predecesor de requerimientos). En otro caso, el prototipado puede servir su papel inmediatamente antes de algún o todo el desarrollo incremental en modelos incremental o evolutivo.
El Prototipado ha sido usado frecuentemente en los 90, porque la especificación de requerimientos para sistemas complejos tiende a ser relativamente dificultoso de cursar. Muchos usuarios y clientes encuentran que es mucho más fácil proveer retroalimentación convenientemente basada en la manipulación, leer una especificación de requerimientos potencialmente ambigua y extensa.
Diferente del modelo evolutivo donde los requerimientos mejor entendidos están incorporados, un prototipo generalmente se construye con los requerimientos entendidos más pobremente.
En caso que ustedes construyan requerimientos bien entendidos, el cliente podría responder con "sí, así es", y nada podría ser aprendido de la experiencia.
Modelo Espiral
El modelo espiral de los procesos software es un modelo del ciclo de meta-vida. En este modelo, el esfuerzo de desarrollo es iterativo. Tan pronto como uno completa un esfuerzo de desarrollo, otro comienza. Además, en cada desarrollo ejecutado, puedes seguir estos cuatros pasos:
  Determinar qué quieres lograr.
  Determinar las rutas alternativas que puedes tomar para lograr estas metas. Por cada una, analizar los riesgos y resultados finales, y seleccionar la mejor.
  Seguir la alternativa seleccionada en el paso 2.
  Establecer qué tienes terminado.

La dimensión radial en la figura refleja costos acumulativos incurridos en el proyecto. Observemos un escenario particular. Digamos que en este proyecto, nosotros viajaremos a resolver un conjunto particular de problemas del cliente. Durante el primer viaje alrededor de la espiral, analizamos la situación y determinamos que los mayores riesgos son la interfaz del usuario. Después de un cuidadoso análisis de las formas alternativas de direccionar esto (por ejemplo, construir un sistema y esperar lo mejor, escribir una especificación de requerimientos y esperar que el cliente lo entienda, y construir un prototipo), determinamos que el mejor curso de acción es construir un prototipo.
Lo realizamos. Luego proveemos el prototipo al cliente quien nos provee con retroalimentación útil. Ahora, comenzamos el segundo viaje alrededor de la espiral. Este tiempo decidimos que el mayor riesgo es ese miedo a que muchos nuevos requerimientos comiencen a aparecer sólo después de que el sistema sea desplegado. Analicemos las rutas alternativas, y decidimos que la mejor aproximación es construir un incremento del sistema que satisfaga sólo los requerimientos mejor entendidos. Hagámoslo ya. Después del despliegue, el cliente nos provee de retroalimentación que dirá si estamos correctos con esos requerimientos, pero 50 nuevos requerimientos ahora se originarán en las cabezas de los clientes. Y el tercer viaje alrededor de la espiral comienza.
El modelo espiral captura algunos principios básicos:
·         Decidir qué problema se quiere resolver antes de viajar a resolverlo.
·         Examinar tus múltiples alternativas de acción y elegir una de las más convenientes.
·         Evaluar qué tienes hecho y qué tienes que haber aprendido después de hacer algo.
·         No ser tan ingenuo para pensar que el sistema que estás construyendo será "EL" sistema que el cliente necesita, y
·         Conocer (comprender) los niveles de riesgo, que tendrás que tolerar.
El modelo espiral no es una alternativa del modelo cascada, ellos son completamente compatible. 
Modelo Concurrente
Como el modelo espiral, el modelo concurrente provee una meta-descripción del proceso software. Mientras que la contribución primaria del modelo espiral es en realidad que esas actividades del software ocurran repetidamente, la contribución del modelo concurrente es su capacidad de describir las múltiples actividades del software ocurriendo simultáneamente.
Esto no sorprende a nadie que ha estado involucrado con las diversas actividades que ocurren en algún tiempo del proceso de desarrollo de software. Discutamos un poco tales casos:
Los requerimientos son usualmente "líneas de base", cuando una mayoría de los requerimientos comienzan a ser bien entendidos, en este tiempo se dedica un esfuerzo considerable al diseño. Sin embargo, una vez que comienza el diseño, cambios a los requerimientos son comunes y frecuentes (después de todo, los problemas reales cambian, y nuestro entendimiento de los problemas desarrollados también). Es desaconsejado detener el diseño en este camino cuando los requerimientos cambian; en su lugar, existe una necesidad de modificar y rehacer líneas de base de los requerimientos mientras progresa el diseño. Por supuesto, dependiendo del impacto de los cambios de los requerimientos el diseño puede no ser afectado, medianamente afectado o se requerirá comenzar todo de nuevo.
Durante el diseño de arquitectura, es posible que algunos componentes comiencen a ser bien definidos antes que la arquitectura completa sea estabilizada. En tales casos, puede ser posible comenzar el diseño detallado en esos componentes estables. Similarmente, durante el diseño detallado, puede ser posible proceder con la codificación y quizás regular testeando en forma unitaria o realizando testeo de integración previo a llevar a cabo el diseño detallado de todos los componentes.
En algunos proyectos, múltiples etapas de un producto se han desarrollado concurrentemente. Por ejemplo, no es inusual estar haciendo mantención de la etapa 1 de un producto, y al mismo tiempo estar haciendo mantención sobre un componente 2, mientras que se está haciendo codificación sobre un componente 3, mientras se realiza diseño sobre una etapa 4, y especificación de requisitos sobre un componente 5.
En todos estos casos, diversas actividades están ocurriendo simultáneamente. Eligiendo seguir un proyecto usando técnicas de modelación concurrente, se posibilita el conocimiento del estado verdadero en el que se encuentra el proyecto.



Paradigma de programación

Es una propuesta tecnológica que es adoptada por una comunidad de programadores cuyo núcleo central es incuestionable en cuanto a que unívocamente trata de resolver uno o varios problemas claramente delimitados. La resolución de estos problemas debe suponer consecuentemente un avance significativo en al menos un parámetro que afecte a la ingeniería de software. Tiene una estrecha relación con la formalización de determinados lenguajes en su momento de definición. Un paradigma de programación está delimitado en el tiempo en cuanto a aceptación y uso ya que nuevos paradigmas aportan nuevas o mejores soluciones que la sustituyen parcial o totalmente

Metodología de desarrollo de software

Una metodología de desarrollo de software se refiere a un framework que es usado para estructurar, planear y controlar el proceso de desarrollo en sistemas de información.
Cascada
Es un proceso secuencial de desarrollo en el que los pasos de desarrollo son vistos hacia abajo (como en una cascada de agua) a través de las fases de análisis de las necesidades, el diseño, implementación, pruebas (validación), la integración, y mantenimiento. La primera descripción formal del modelo de cascada se cita a menudo a un artículo publicado por Winston Royce W. en 1970, aunque Royce no utiliza el término "cascada" de este artículo.
Los principios básicos del modelo de cascada son los siguientes:
§  El proyecto está dividido en fases secuenciales, con cierta superposición y splashback aceptable entre fases.
§  Se hace hincapié en la planificación, los horarios, fechas, presupuestos y ejecución de todo un sistema de una sola vez.
§  Un estricto control se mantiene durante la vida del proyecto a través de la utilización de una amplia documentación escrita, así como a través de comentarios y aprobación / signoff por el usuario y la tecnología de la información de gestión al final de la mayoría de las fases antes de comenzar la próxima fase.
Prototipado
El prototipado es el framework de actividades dedicada al desarrollo de software prototipo, es decir, versiones incompletas del software a desarrollar.
Incremental
Provee una estrategia para controlar la complejidad y los riesgos, desarrollando una parte del producto software reservando el resto de aspectos para el futuro.
Los principios básicos son:
§  Una serie de mini-Cascadas se llevan a cabo, donde todas las fases de la cascada modelo de desarrollo se han completado para una pequeña parte de los sistemas, antes de proceder a la próxima incremental
§  Se definen los requisitos antes de proceder con lo evolutivo, se realiza un mini-Cascada de desarrollo de cada uno de los incrementos del sistema
§  El concepto inicial de software, análisis de las necesidades, y el diseño de la arquitectura y colectiva básicas se definen utilizando el enfoque de cascada, seguida por iterativo de prototipos, que culmina en la instalación del prototipo final.

Espiral
Los principios básicos son:
§  La atención se centra en la evaluación y reducción del riesgo del proyecto dividiendo el proyecto en segmentos más pequeños y proporcionar más facilidad de cambio durante el proceso de desarrollo, así como ofrecer la oportunidad de evaluar los riesgos y con un peso de la consideración de la continuación del proyecto durante todo el ciclo de vida.
§  Cada viaje alrededor de la espiral atraviesa cuatro cuadrantes básicos: (1) determinar objetivos, alternativas, y desencadenantes de la iteración; (2) Evaluar alternativas; Identificar y resolver los riesgos; (3) desarrollar y verificar los resultados de la iteración, y (4) plan de la próxima iteración.
§  Cada ciclo comienza con la identificación de los interesados y sus condiciones de ganancia, y termina con la revisión y examinación.

Modelado de sistema de leguaje Unificado de modelado UML

La falta de estandarización en la manera de representar gráficamente un modelo, un lenguaje no sólo para comunicar las ideas a otros desarrolladores sino también para servir de apoyo en los procesos de análisis de un problema. Se creó el Lenguaje Unificado de Modelado (UML: Unified Modeling Language). UML.

El lenguaje UML comenzó, cuando Rumbaugh se unió a la compañía Rational fundada por Booch, para unificar dos métodos que habían desarrollado: el método Booch y el OMT (Object Modelling Tool ). En octubre de 1995, Jacobson, se unió a Rational y la colaboración de otras empresas para que aportaran sus ideas. Condujeron a la definición de la primera versión de UML. El 14 de noviembre de 1997 cuando el Grupo Administrador de Objetos (Object Management Group, OMG) publicó como estándar la versión 1.1 del Lenguaje Unificado de Modelado (Unified Modeling Language, UML)

UML es un lenguaje, que proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar.

Los elementos de UML se clasifican en estructurales (Clases, interfaces. Colaboraciones, casos de uso, clases activas, componentes y nodos), de comportamiento (interacciones y máquinas de estado), de agrupación (paquetes) y de anotación (notas). A su vez, hay cuatro tipos de relaciones: De Dependencia, de asociación, de agrupación y de realización. Para construir un plano de software que tenga sentido, lo que se hace es combinar los elementos estructurales con sus respectivas relaciones, según sea el caso, obteniendo como resultado uno de los nueve diagramas que existen en UML, a saber: De clases, De objetos, de casos de uso, de secuencia, de colaboración, de estados, de actividades, de componentes y de despliegue.

UML nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo.

Fundamentos de sistemas

Fundamentos de sistemas
Introducción a los sistemas

La teoría de la organización y la práctica administrativa han experimentado cambios sustanciales en años recientes. La información proporcionada por las ciencias de la administración y la conducta ha enriquecido a la teoría tradicional. Estos esfuerzos de investigación y de conceptualización a veces han llevado a descubrimientos divergentes. Sin embargo, surgió un enfoque que puede servir como base para lograrla convergencia, el enfoque de sistemas, que facilita la unificación de muchos campos del conocimiento. Dicho enfoque ha sido usado por las ciencias físicas, biológicas y sociales, como marco de referencia para la integración de la teoría organizacional moderna.
El primer expositor de la Teoría General de los Sistemas fue Ludwing von Bertalanffy, en el intento de lograr una metodología integradora para el tratamiento de problemas científicos. La meta de la Teoría General de los Sistemas no es buscar analogías entre las ciencias, sino tratar de evitar la superficialidad científica que ha estancado a las ciencias. Para ello emplea como instrumento, modelos utilizables y transferibles entre varios continentes científicos, toda vez que dicha extrapolación sea posible e integrable a las respectivas disciplinas.
La Teoría General de los Sistemas se basa en dos pilares básicos: aportes semánticos y aportes metodológicos.

Concepto básico

Sistema es un conjunto de partes que están integradas con el propósito de lograr un objetivo. Un sistema tiene más de un elemento. Un volante no es un sistema, pero es una parte vital de un sistema muy conocido que se llama automóvil.

Organizaciones como sistemas

Las organizaciones son unidades sociales intencionalmente construidas y reconstruidas para lograr objetivos específicos.
Existen dos tipos de sistemas:


·         Sistema Abierto:
Conjunto de elementos dinámicamente relacionados, en interacción que desarrollan una actividad para lograr un objetivo o propósito, operando condatos, energía, materia, unidos al ambiente que rodea el sistema y para suministrar informacion, energía, materia.
Posee numerosas entradas y salidas. Para relacionarse con el ambiente externo, sus relaciones de causa y efecto son indeterminadas.
Un sistema consta de cuatro elementos primordiales:
Entradas: Mediante ellas el sistema consigue los recursos e insumos necesarios para su alimentacion y nutrición
Procesamiento: Transforma las entradas en salidas o resultados
Salidas: Resultado de la operación del sistema. Por medio de ella el sistema envía el producto resultante al ambiente externo.
Retroalimentación: Constituye una acción de retorno; es positiva cuando la salida por ser mayor estimula y amplía las entradas para incrementar el funcionamiento del sistema, es negativa cuando la salida por ser menor restringe y reduce la entrada para disminuir la marcha del sistema.
·         Sistema Cerrado:
Tienen pocas entradas y salidas en relación con el ambiente externo, que son bien conocidas y guardan entre sí una razón de causa y efecto: a una entrada determinada (causa) sigue una salida determinada (efecto). Denominado también mecánico o determinista.
No existe un sistema totalmente cerrado, ni uno totalmente abierto.
Todo sistema depende en alguna medida del ambiente. La Organización como sistema abierto es antigua.

Funciones del Sistema

·         Definir bases de datos conteniendo los datos elementales requeridos 
·         Agregar nuevos registros en una base de datos 
·         Modificar, corregir o borrar registros existentes
·         Construir automáticamente y mantener archivos para acceso rápido a los registros de cada base de datos de modo que haya una recuperación muy veloz
·         Recuperar registros por su contenido mediante un lenguaje de recuperación amplio y poderoso
·         Visualizar los registros o partes de los mismos de acuerdo a las necesidades del usuario
·         Ordenar o clasificar los registros en cualquier secuencia deseada
·         Imprimir catálogos completos, parciales y/o índices
·         Desarrollar aplicaciones especiales usando las facilidades integradas de programación
Estas funciones se obtienen a través de 8 programas que proveen los servicios correspondientes, clasificados en dos grandes categorías: Servicios para el usuario que emplea bases de datos ya existentes; y servicios del sistema, diseñados para el administrador de las bases de datos, para crear nuevas bases o realizar actividades diversas en relación al sistema. Los servicios para el usuario requieren sólo un conocimiento básico del programa CDS/ISIS, en tanto que los servicios del sistema presuponen un conocimiento más profundo de los componentes del sistema, incluyendo la capacidad para programar computadoras. 

Los cuatro servicios previstos para el usuario son los siguientes: 
·         ISISENT Ingreso y edición de datos
·         ISISRET Recuperación de información
·         ISISPRT Producción de impresos y reportes, tales como catálogos e índices
·         ISISINV Mantenimiento del archivo invertido y funciones utilitarias 

Estructura de un sistema
Un sistema de computación moderno consiste de uno o más procesadores, memoria principal, relojes, terminales, discos, interfaces de red y otros dispositivos de entrada/salida. Sin embargo, hardware sin software es simplemente inútil. El sistema de operación es una parte importante de un sistema de computación.
Veamos la estructura general de un sistema de computación y el papel que juega el sistema de operación.
Software:
Programas del Sistema: Administran la operación del computador.
Programas de Aplicación: Resuelven problemas de usuarios particulares.
Hardware
Ahora bien, dentro del tipo de Programas del Sistema, el más importante es el Sistema de Operación, el cual controla todos los recursos del computador y provee la base o plataforma sobre la cual los Programas de Aplicación pueden ser escritos.
Desplegando un nivel más estos dos componentes (Hardware y Software) tenemos la siguiente estructura:

Planificación de la información

La planificación de los Sistemas de Información (SI) se entiende como un procedimiento sistemático de toma de decisiones sobre qué hacer con los sistemas de información en el futuro. Esto ha evolucionado de tal manera a lo largo de los años que se pueden distinguir cuatro fases:

·         La introducción de la informática en las organizaciones
·         La expansión anárquica de las aplicaciones informáticas
·         La coordinación de los SI con los objetivos de la empresa
·         La interdependencia estratégica entre las compañías y los SI

Requerimientos funcionales y no funcionales del sistema



Los requisitos funcionales son aquellos que especifican lo que va a tener que hacer tu aplicación, sus funcionalidades. Por ejemplo, loguear usuarios, generar informes, entre otros.



Los requisitos no funcionales son aquellos relacionados con atributos de calidad, es decir, rendimiento, escalabilidad, fiabilidad, disponibilidad, mantenimientos, usabilidad, entre otros.

Generalmente, a la hora de escoger una arquitectura para diseñar el sistema, se hace a partir de los requisitos no funcionales. Y los diagramas y vistas de diseño se hacen a partir de los requisitos funcionales.


Fundamento de sistemas de información

Un sistema de información (SI) es un conjunto de elementos orientados al tratamiento y administración de datos e información, organizados y listos para su uso posterior, generados para cubrir una necesidad u objetivo. Dichos elementos formarán parte de alguna de las siguientes categorías:
§  Personas
§  Datos
§    Actividades o técnicas de trabajo
§  Recursos materiales en general (generalmente recursos informáticos y de comunicación, aunque no necesariamente).
Todos estos elementos interactúan para procesar los datos (incluidos los procesos manuales y automáticos) y dan lugar a información más elaborada, que se distribuye de la manera más adecuada posible en una determinada organización, en función de sus objetivos.
Habitualmente el término se usa de manera errónea como sinónimo de sistema de información informático, en parte porque en la mayor parte de los casos los recursos materiales de un sistema de información están constituidos casi en su totalidad por sistemas informáticos. Estrictamente hablando, un sistema de información no tiene por qué disponer de dichos recursos (aunque en la práctica esto no suela ocurrir). Se podría decir entonces que los sistemas de información informáticos son una subclase o un subconjunto de los sistemas de información en general.

Información
En sentido general, la información es un conjunto organizado de datosprocesados, que constituyen un mensaje que cambia el estado de conocimiento del sujeto o sistema que recibe dicho mensaje.


Elementos y actividades de un sistema de información
Un sistema de información es un conjunto de elementos que interactúan entre sí con el fin de apoyar las actividades de una empresa o negocio.
El equipo computacional: el hardware necesario para que el sistema de información pueda operar. El recurso humano que interactúa con el Sistema de Información, el cual está formado por las personas que utilizan el sistema.
Un sistema de información realiza cuatro actividades básicas: entrada, almacenamiento, procesamiento y salida 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 interfaces 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 interface automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interface automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.
A continuación se muestran las diferentes actividades que puede realizar un Sistema de Información de Control de Clientes:
Actividades que realiza un Sistema de Información:
Entradas:
• Datos generales del cliente: nombre, dirección, tipo de cliente, etc.
• Políticas de créditos: límite de crédito, plazo de pago, etc.
• Facturas (interfase automático).
• Pagos, depuraciones, etc.
Proceso:
• Cálculo de antigüedad de saldos.
• Cálculo de intereses moratorios.
• Cálculo del saldo de un cliente.
Almacenamiento:
• Movimientos del mes (pagos, depuraciones).
• Catálogo de clientes.
• Facturas.
Salidas:
• Reporte de pagos.
• Estados de cuenta.
• Pólizas contables (interface automática)
• Consultas de saldos en pantalla de una terminal.
Tipos de sistemas de información
·         Sistemas naturales: Son los existentes en el ambiente.
·         Sistemas artificiales: Son los creados por el hombre.
·         Sistemas sociales: Integrados por personas cuyo objetivo tiene un fin común.
·         Sistemas hombre-máquina: Emplean equipo u otra clase de objetivos, que a veces se quiere lograr la autosuficiencia.
·         Sistemas abiertos: Intercambian materia y energía con el ambiente continuamente.
·         Sistemas cerrados: No presentan intercambio con el ambiente que los rodea, son herméticos a cualquier influencia ambiental.
·         Sistemas temporales: Duran cierto periodo de tiempo y posteriormente desaparecen.
·         Sistemas permanentes: Duran mucho más que las operaciones que en ellos realiza el ser humano, es decir, el factor tiempo es más constante.
·         Sistemas estables: Sus propiedades y operaciones no varían o lo hacen solo en ciclos repetitivos.
·         Sistemas no estables: No siempre es constante y cambia o se ajusta al tiempo y a los recursos.
·         Sistemas adaptativos: Reacciona con su ambiente mejora su funcionamiento, logro y supervivencia.
·         Sistemas no adaptativos: tienen problemas con su integración, de tal modo que pueden ser eliminados o bien fracasar.
·         Sistemas determinanticos: Interactúan en forma predecible.
·         Sistemas probabilísticos: Presentan incertidumbre.
·         Subsistemas: Sistemas más pequeños incorporados al sistema original.
·         Supersistemas: sistemas extremadamente grandes y complejos, que pueden referirse a una parte del sistema original.
Importancia de los sistemas de información
Cuando muchas personas se preguntan por qué estudiar sobre los sistemas de información, es lo mismo que preguntar por qué debería estudiar alguien contabilidad, fianza, gestión de operaciones, marketingadministración de recursos humanos cualquier otra función empresarial importante. Lo que si les puedo asegurar es que muchas empresas y organizaciones tienen éxitos en sus objetivos por la implantación y uso de los Sistemas de Información. De esta forma, constituyen un campo esencial de estudio en administración y gerencia de empresas. Es por esta razón que todos los profesionales en el área de administración de Empresas deberían o más bien deben, tomar un curso de sistemas de información. Por otro lado es importante tener una comprensión básica de los sistemas de información para entender cualquier otra área funcional en la empresa, por eso es importante también, tener una cultura informática en nuestras organizaciones que permitan y den las condiciones necesarias para que los sistemas de información logren los objetivos citados anteriormente. Muchas veces las organizaciones no han entrado en la etapa de cambio hacía la era de la información sin saber que es un riesgo muy grande de fracaso debido a las amenazas del mercad y su incapacidad de competir, por ejemplo, las TI que se basan en Internet se están convirtiendo rápidamente en un ingrediente necesario par el éxito empresarial en el entorno global y dinámico de hoy.
Por lo tanto, la administración apropiada de los sistemas de información es un desafío importante para los gerentes. Así la función de los SI representa:
·         Un área funcional principal dentro de la empresa, que es tan importante para el éxito empresarial como las funciones de contabilidad, finanzas, administración de operaciones,  marketing, y administración de recursos humanos.
·         Una colaboración importante para le eficiencia operacional, la productividad y la moral del empleado, y el servicio y satisfacción del cliente.
·         Una fuente importante de información y respaldo importante para la toma de decisiones efectivas por parte de los gerentes.
·         Un ingrediente importante para el desarrollo de productos y servicios competitivos que den a las organizaciones una ventaja estratégica en el mercado global.
·         Una oportunidad profesional esencial, dinámica y retadora para millones de hombres y mujeres.