Mapa sobre Riesgo, amenaza, vulnerabilidad y pasos para proteger un sistema informático.

Diagrama de Flujo de Datos.

Es un gráfico lógico del plan de trabajo que se ejecutara para la solución de un determinado problema. A través de él, se planifica la solución del problema independiente del lenguaje de computación a usar. De esta manera se separa loas instrucción es un lenguaje determinado con todas las reglas.

Las capacidades humanas necesarias para elaborar un diagrama de flujo correcto son: Lógico, Prácticas, y Atención.

El empleo de la maquina en las funciones del procediendo de datos han hecho necesario un flujo ordenado de la información. La secuencia en que deberán ejecutarse las operaciones tendrá que definirse claramente, y cuando se combine con los datos a los que debe aplicarse, esa secuencia creara el flujo de información.

No puede hacerse mucho hincapié en documentación, ósea el registro de Información .Sin Instrucciones escritas y sin representación gráfica del flujo de trabajo seria muy difícil de llevar una tarea de procediendo de datos en forma apropiada. Hay varios métodos mas eficientes organizados y normalizados, es el de los diagramas de Flujo que el Futuro programador comprenda la necesidad de los diagrama de flujo.

Objetivos de un diagrama de flujo:

Estructura la solución del problema independiente del lenguaje a utilizar.

Separar la solución lógica de programación de la parte de reglas y sintaxis de codificación con esta división del trabajo se obtiene mayor eficiencia.

Dar una visión completa del problema al programador ya que pierde en un programa ya codificado.

Permitir una compresión más rápida del programa a otros programadores.

Tipos de diagramas de flujo:

Diagrama de flujo de sistemas: muestra en que forma se procesan los datos, entre as principales funciones o estaciones de trabajo .En este diagrama completo de computadora se presenta con un solo símbolo de procesamiento.

Ejemplo de Diagrama de Flujo de sistema:

Diagrama de flujos de programación:
Son las operaciones y decisiones en la secuencia en que las ejecutará una computadora de procesamiento de datos. Los símbolos representan esas operaciones e indican el orden en que se ejecutaran. Por lo tanto, un diagrama de flujo de programa proporciona una descripción gráfica del programa.

Ejemplo de Diagrama e Flujo de Programa:

Simbologia de los diagramas de flujo:

Las diversas organizaciones usan distintos símbolos, pero el comité sobre computadoras y procesadores de información de la Asociación Norteamericana de Normas ha hecho un gran esfuerzo para normalizar los símbolos de los diagramas de flujo. Esa normalización permite comprender cualquier diagrama de flujo que use los símbolos recomendados.

Cada símbolo normal de diagrama de flujo tiene un significado especial.

Expresa Inicio o Fin de un Programa.

Expresa operación algebraica o de

asignación.

Expresa condiciones y asociaciones alternativas de una decisión lógica.

 Expresa condición y acciones alternativas de una decisión numérica.

Entrada / Salida: Representa cualquier tipo de Fuente de entrada y salida

 Entrada: Lectura de datos por tarjeta perforadas.

Conector dentro de página.

 Representa resultado mediante un reporte impreso

Conector fuera de página.

 Expresa operación cíclica repetitiva.

Expresa proceso de llamada a una subalterna.

Representa datos grabados en una cinta magnética.

Almacenamiento en línea Disco Magnético.

Reglas para estructurar un diagrama de flujo:

• El sentido de un diagrama de flujo generalmente es de arriba hacia abajo.
• Es un símbolo solo puede entrar una flecha de flujo si varias líneas se dirigen al mismo símbolo, se deben unir en una sola flecha.

• Las líneas de flujo no deben cruzarse, para evitar los cruces se utilizan los conectores.
• De un símbolo excepto el de decisión, solo puede salir una línea de flujo.
• Los símbolos Terminal, Conector dentro de página y conector fuera de página solo pueden estar conectados al diagrama por una sola flecha, ya que por su naturaleza es imposible que tenga una entrada y una de salida.
• Los émbolos de decisión tendrán siempre una sola flecha de entrada y dos o tres flechas de salida según la cantidad de alternativas que se presentan.

Un diagrama de flujo debe estar complemente cerrado, teniendo una continuidad de principio a fin, no pueden quedar flechas en el aire ni símbolos sin conexión al diagrama pues el flujo seria interrumpido.

Consideraciones sobre el diagrama de flujo:

Un diagrama de flujo, puede tener tipos de errores diferentes:

DE FORMA: Se genera por no seguir las reglas establecidas, puede hacer el diagrama difícil interpretación, confundir el diagrama y hasta convertirlo en errado en cuanto ser lógica.

DE LÓGICA: Son errores de estructura del diagrama en cuanto al arden puede ser de distinta gravedad, desde dejar de mostrar el resultado. O falta un cálculo hasta un error que determine que un programa nunca llegue a su fin.

DE OBJETIVO: Es cuando un diagrama de flujo esta correcto en cuanto a su estructura y forma pero no soluciona el problema propuesto sino otro.

Una vez terminado e diagrama de flujo, es necesario asegurarse de que funcione correctamente cumpliendo el objetivo fundamental, las condiciones especificas y las excepciones del problema propuesto a esto se le llama generalmente "corrida en frió" prueba de escritorio.

Para ellos e selecciona algunos datos (creadas por el programador para fines de la prueba) que cubran todos los casos posibles en todas las condiciones. Tomando estos datos se recorre el diagrama de flujo símbolo a símbolo siguiendo la orden de cada uno de ellos, todo esto se hará a un lado del diagrama o en una hoja aparte dándole valores a variables y ejecutando operación que se indique .Ejemplo:

Diseño de las pruebas y documentación del sistema.

Diseño de las pruebas.

Calidad, errores y pruebas

La calidad no es algo que se pueda agregar al software después de desarrollado si no se hizo todo el desarrollo con la calidad en mente. Muchas veces parece que el software de calidad es aquél que brinda lo que se necesita con adecuada velocidad de procesamiento. En realidad, es mucho más que eso. Tiene que ver con la corrección, pero también con usabilidad, costo, consistencia, confiabilidad, compatibilidad, utilidad, eficiencia y apego a los estándares.

Todos estos aspectos de la calidad pueden ser objeto de tests o pruebas que determinen el grado de calidad. Incluso la documentación para el usuario debe ser probada.

Como en todo proyecto de cualquier índole, siempre se debe tratar que las fallas sean mínimas y poco costosas, durante todo el desarrollo. Y además, es sabido que cuanto más tarde se encuentra una falla, más caro resulta eliminarla. Es claro que si un error es descubierto en la mitad del desarrollo de un sistema, el costo de su corrección será mucho menor al que se debería enfrentar en caso de descubrirlo con el sistema instalado y en funcionamiento.

Desde el punto de vista de la programación, nos interesa la ausencia de errores (corrección), la confiabilidad y la eficiencia. Dejando de lado las dos últimas, nos concentraremos en este capítulo en las pruebas que determinen que un programa está libre de errores.

Un error es un comportamiento distinto del que espera un usuario razonable. Puede haber errores aunque se hayan seguido todos los pasos indicados en el análisis y en el diseño, y hasta en los requisitos aprobados por el usuario. Por lo tanto, no necesariamente un apego a los requisitos y un perfecto seguimiento de las etapas nos lleva a un producto sin errores, porque aún en la mente de un usuario pudo haber estado mal concebida la idea desde el comienzo. De allí la importancia del desarrollo incremental, que permite ir viendo versiones incompletas del sistema.

Por lo tanto, una primera fuente de errores ocurre antes de los requerimientos o en el propio proceso de análisis. Pero también hay errores que se introducen durante el proceso de desarrollo posterior. Así, puede haber errores de diseño y errores de implementación. Finalmente, puede haber incluso errores en la propia etapa de pruebas y depuración.

Categorías de pruebas:

Según la naturaleza de lo que se esté controlando, las pruebas se pueden dividir en dos categorías:

• Pruebas centradas en la verificación.

• Pruebas centradas en la validación.

Las primeras sirven para determinar la consistencia entre los requerimientos y el programa terminado. Soporta metodologías formales de testeo, de mucho componente matemático. De todas maneras, hay que ser cuidadoso, porque no suele ser fácil encontrar qué es lo que hay que demostrar. La verificación consiste en determinar si estamos construyendo el sistema correctamente, a partir de los requisitos.

En general a los informáticos no les gustan las pruebas formales, en parte porque no las entienden y en parte porque requieren un proceso matemático relativamente complejo.

La validación consiste en saber si estamos construyendo el sistema correcto. Las tareas de validación son más informales. Las pruebas suelen mostrar la presencia de errores, pero nunca demuestran su ausencia.

Las pruebas y el desarrollo de software.

La etapa de pruebas es una de las fases del ciclo de vida de los proyectos. Se la podría ubicar después del análisis, el diseño y la programación, pero dependiendo del proyecto en cuestión y del modelo de proceso elegido, su realización podría ser en forma paralela a las fases citadas o inclusive repetirse varias veces durante la duración del proyecto.

La importancia de esta fase será mayor o menor según las características del sistema desarrollado, llegando a ser vital en sistemas de tiempo real u otros en los que los errores sean irrecuperables.

Las pruebas no tienen el objeto de prevenir errores sino de detectarlos5. Se efectúan sobre el trabajo realizado y se deben encarar con la intención de descubrir la mayor cantidad de errores posible.

Para realizar las pruebas se requiere gente que disfrute encontrando errores, por eso no es bueno que sea el mismo equipo de desarrollo el que lleve a cabo este trabajo. Además, es un principio fundamental de las auditorías. Por otro lado, es bastante común que a quien le guste programar no le guste probar, y viceversa.

A veces se dan por terminadas las pruebas antes de tiempo. En las pruebas de caja blanca (ver más adelante) no es mala idea probar un 85% de las ramas y dar por terminado luego de esto.

Otra posibilidad es la siembra de errores y seguir las pruebas hasta que se encuentren un 85% de los errores sembrados, lo que presumiblemente implica que se encontró un 85% de los no

sembrados6. Otros métodos se basan en la estadística y las comparaciones, ya sea por similitud con otro sistema en cantidad de errores o por el tiempo de prueba usado en otro sistema.

En un proyecto ideal, podríamos generar casos de prueba para cubrir todas las posibles entradas y todas las posibles situaciones por las que podría atravesar el sistema. Examinaríamos así exhaustivamente el sistema para asegurar que su comportamiento sea perfecto. Pero hay un problema con esto: el número de casos de prueba para un sistema complejo es tan grande que no alcanzaría una vida para terminar con las pruebas. Como consecuencia, nadie realiza una prueba exhaustiva de nada salvo en sistemas triviales.

En un sistema real, los casos de prueba se deben hacer sobre las partes del sistema en los cuales una buena prueba brinde un mayor retorno de la inversión o en las cuales un error represente un riesgo mayor.

Las pruebas cuestan mucho dinero. Pero para ello existe una máxima: “pague por la prueba ahora o pague el doble por el mantenimiento después”.

Todo esto lleva a que se deban planificar bien las pruebas, con suficiente anticipación, y determinar desde el comienzo los resultados que se deben obtener.

La idea de extreme programming es más radical: propone primero escribir los programas de prueba y después la aplicación, obligando a correr las pruebas siempre antes de una integración.

Se basa en la idea bastante acertada de que los programas de prueba son la mejor descripción de los requerimientos. Esto lo analizamos en un ítem especial.

Tipos de pruebas:

Analizaremos 5 tipos de pruebas:

• Revisiones de código
• Pruebas unitarias
• Pruebas de integración
• Pruebas de sistema
• Pruebas de aceptación
• No son tipos de pruebas intercambiables, ya que testean cosas distintas. En el ítem siguiente analizamos cada tipo.

Otra posible clasificación de las pruebas es:

• De caja blanca o de código.
• De caja negra o de especificación.

En las primeras se evalúa el contenido de los módulos, mientras en las segundas se trata al módulo como una caja cerrada y se lo prueba con valores de entrada, evaluando los valores de salida.

Vistas de este modo, las pruebas de caja negra sirven para verificar especificaciones.

Las pruebas unitarias suelen ser de caja blanca o de caja negra, mientras que las de integración, sistema y aceptación son de caja negra. Las tareas de depuración luego de encontrar errores son más bien técnicas de caja blanca, así como las revisiones de código. En todos los casos, uno de los mayores desafíos es encontrar los datos de prueba: hay que encontrar un subconjunto de todas las entradas que tengan alta probabilidad de detectar el mayor número de errores.

Revisiones de código:

Las revisiones de código son las únicas que se podrían omitir de todos los tipos de pruebas, pero tal vez sea buena idea por lo menos hacer alguna de ellas:

• Pruebas de escritorio
• Recorridos de código
• Inspecciones de código

La prueba de escritorio rinde muy poco, tal vez menos de lo que cuesta, pero es una costumbre difícil de desterrar. Es bueno concentrarse en buscar anomalías típicas, como variables u objetos no inicializados o que no se usan, ciclos infinitos y demás.

Los recorridos rinden mucho más. Son exposiciones del código escrito frente a pares. El programador, exponiendo su código, encuentra muchos errores. Además da ideas avanzadas a programadores nuevos que se lleva a recorrer.

Las llamadas inspecciones de código consisten en reuniones en conjunto entre los responsables de la programación y los responsables de la revisión. Tienen como objetivo revisar el código escrito por los programadores para chequear que cumpla con las normas que se hayan fijado y para verificar la eficiencia del mismo. Se realizan siguiendo el código de un pequeño porcentaje de módulos seleccionados al azar o según su grado de complejidad. Las inspecciones se pueden usar en sistemas grandes, pero con cuidado para no dar idea de estar evaluando al programador.

Suelen servir porque los revisores están más acostumbrados a ver determinados tipos de errores comunes a todos los programadores. Además, después de una inspección a un programador, de la que surge un tipo de error, pueden volver a inspeccionar a otro para ver si no cayó en el mismo error.

El concepto de extreme programming propone programar de a dos, de modo que uno escribe y el otro observa el trabajo. Si el que está programando no puede avanzar en algún momento, sigue el que miraba. Y si ambos se traban pueden pedir ayuda a otro par. Esta no sólo es una forma más social de programación, sino que aprovecha las mismas ventajas de los recorridos e inspecciones de código, y puede prescindir de ellos.

Pruebas unitarias:

Las pruebas unitarias se realizan para controlar el funcionamiento de pequeñas porciones de código como ser subprogramas (en la programación estructurada) o métodos (en POO).

Generalmente son realizadas por los mismos programadores puesto que al conocer con mayor detalle el código, se les simplifica la tarea de elaborar conjuntos de datos de prueba para testearlo.

Si bien una prueba exhaustiva sería impensada teniendo en cuenta recursos, plazos, etc., es posible y necesario elegir cuidadosamente los casos de prueba para recorrer tantos caminos lógicos como sea posible. Inclusive procediendo de esta manera, deberemos estar preparados para manejar un gran volumen de datos de prueba.

Los métodos de cobertura de caja blanca tratan de recorrer todos los caminos posibles por lo menos una vez, lo que no garantiza que no haya errores pero pretende encontrar la mayor parte.

El tipo de prueba a la cual se someterá a cada uno de los módulos dependerá de su complejidad. Recordemos que nuestro objetivo aquí es encontrar la mayor cantidad de errores posible. Si se pretende realizar una prueba estructurada, se puede confeccionar un grafo de flujo con la lógica del código a probar. De esta manera se podrán determinar todos los caminos por los que el hilo de ejecución pueda llegar a pasar, y por consecuente elaborar los juegos de valores de pruebas para aplicar al módulo, con mayor facilidad y seguridad.

Documentación del sistema.

En general se habla mucho de la documentación, pero no se la hace, no se le asigna presupuesto, no se la mantiene y casi nunca está al día en los proyectos de desarrollo de software.

Lo importante es la disponibilidad de la documentación que se necesita en el momento en que se la necesita.

Muchas veces se hace porque hay que hacerla y se escribe, con pocas ganas, largos textos, a la vez que se está convencido de estar haciendo un trabajo inútil. A veces se peca por exceso y otras por defecto. Ocurre mucho en la Web y con productos RAD. En ocasiones se olvida que el mantenimiento también debe llegar a la documentación.

La documentación se suele clasificar en función de las personas o grupos a los cuales está dirigida:

• Documentación para los desarrolladores.
• Documentación para los usuarios.
• Documentación para los administradores o soporte técnico.

La documentación para desarrolladores es aquélla que se utiliza para el propio desarrollo del producto y, sobre todo, para su mantenimiento futuro. Se documenta para comunicar estructura y comportamiento del sistema o de sus partes, para visualizar y controlar la arquitectura del sistema, para comprender mejor el mismo y para controlar el riesgo, entre otras cosas.

Obviamente, cuanto más complejo es el sistema, más importante es la documentación.

En este sentido, todas las fases de un desarrollo deben documentarse: requerimientos, análisis, diseño, programación, pruebas, etc... Una herramienta muy útil en este sentido es una notación estándar de modelado, de modo que mediante ciertos diagramas se puedan comunicar ideas entre grupos de trabajo.

Hay decenas de notaciones, tanto estructuradas como orientadas a objetos. Un caso particular es el de UML, que analizamos en otra obra. De todas maneras, los diagramas son muy útiles, pero siempre y cuando se mantengan actualizados, por lo que más vale calidad que cantidad.

La documentación para desarrolladores a menudo es llamada modelo, pues es una simplificación de la realidad para comprender mejor el sistema como un todo.

Otro aspecto a tener en cuenta cuando se documenta o modela, es el del nivel de detalle.

Así como cuando construimos planos de un edificio podemos hacer planos generales, de arquitectura, de instalaciones y demás, también al documentar el software debemos cuidar el nivel de detalle y hacer diagramas diferentes en función del usuario de la documentación, concentrándonos en un aspecto a la vez.

De toda la documentación para los desarrolladores, nos interesa especialmente en esta obra aquella que se utiliza para documentar la programación, y en particular hemos analizado la que se usa para documentar desarrollos orientados a objetos en el capítulo respectivo.

La documentación para usuarios es todo aquello que necesita el usuario para la instalación, aprendizaje y uso del producto. Puede consistir en guías de instalación, guías del usuario, manuales de referencia3 y guías de mensajes.

En el caso de los usuarios que son programadores, verbigracia los clientes de nuestras clases, esta documentación se debe acompañar con ejemplos de uso recomendados o de muestra y una reseña de efectos no evidentes de las bibliotecas.

Más allá de todo esto, debemos tener en cuenta que la estadística demuestra que los usuarios no leen los manuales a menos que nos les quede otra opción. Las razones pueden ser varias, pero un análisis de la realidad muestra que se recurre a los manuales solamente cuando se produce un error o se desconoce cómo lograr algo muy puntual, y recién cuando la ayuda en línea no satisface las necesidades del usuario. Por lo tanto, si bien es cierto que debemos realizar manuales, la existencia de un buen manual nunca nos libera de hacer un producto amigable para el usuario, que incluso contenga ayuda en línea. Es incluso deseable proveer un software tutorial que guíe al usuario en el uso del sistema, con apoyo multimedia, y que puede llegar a ser un curso online.

Buena parte de la documentación para los usuarios puede empezar a generarse desde que comienza el estudio de requisitos del sistema. Esto está bastante en consonancia con las ideas de extreme programming y con metodologías basadas en casos de uso.

La documentación para administradores o soporte técnico, a veces llamada manual de operaciones, contiene toda la información sobre el sistema terminado que no hace al uso por un usuario final. Es necesario que tenga una descripción de los errores posibles del sistema, así como los procedimientos de recuperación. Como esto no es algo estático, pues la aparición de nuevos errores, problemas de compatibilidad y demás nunca se puede descartar, en general el manual de operaciones es un documento que va engrosándose con el tiempo.

Metodología Kendall & Kendall.

“El ciclo de vida de vida del desarrollo de sistemas es un enfoque por fases para el análisis y el diseño cuya premisa principal consiste en que los sistemas se desarrollan mejor utilizando un ciclo especifico de actividades del analista y el usuario.” (Kendall & Kendall) Según la metodología de Kendall & Kendall el ciclo de vida de un sistema consta de siete partes: siendo la primera la identificación del problema, la segunda identificación de requisitos de información, la tercera es el análisis de las necesidades del sistema, la cuarta es el diseño del sistema recomendado, la quinta desarrollo y documentación del sistema, la sexta prueba y mantenimiento y la última implementación y evaluación. Cada fase se explica por separado pero nunca se realizan como pasos aislados, más bien es posible que algunas actividades se realicen de manera simultánea, y algunas de ellas podrían repetirse. 

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

Observación directa del entorno. 

Aplicación de entrevista para recolectar información. 

Sintetizar la información recolectada para construir objetivos. 

Estimar el alcance del proyecto. 

Identificar si existe una necesidad, problema u oportunidad argumentada. 

Documentar resultados. 

Estudiar los riesgos del proyecto. 

Presentar un informe de vialidad. 

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

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

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

Revisión de los objetivos. 

Identificar el dominio. 

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

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

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

Elaborar una lista detallada y organizada de todos los procedimientos. 

Separar requerimientos funcionales y no funcionales. Adicionar al informe de la primera fase, esta nueva información.

En esta fase el analista se esfuerza por comprender la información que necesitan los usuarios para llevar a cabo sus actividades. Entre las herramientas que se utilizan para determinar los requerimientos de información de un negocio se encuentran métodos interactivos como las entrevistas, los muestreos, la investigación de datos impresos y la aplicación de cuestionarios; métodos que no interfieren con el usuario como la observación del comportamiento de los encargados de tomar las decisiones y sus entornos e oficina, al igual que métodos de amplio alcance como la elaboración de prototipos. 

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

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

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

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

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

FASE III: Análisis de las necesidades.

Evaluar las dos fases anteriores. 

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

Elaborar diccionario de datos y sus especificaciones. 

Elaborar diagramas de procesos de cada función. 

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

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

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

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

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

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

FASE IV: Diseño del sistema recomendado.

Evaluar las tres fases anteriores. 

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

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

Elaborar el diseño de la base de datos. 

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

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

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

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

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

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

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

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

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

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

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

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

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

FASE V: Desarrollo y documentación del software.

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

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

Elaborar manuales de procedimientos internos del sistema. 

Elaborar manuales externos de ayuda a los usuarios del sistema. 

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

Elaborar actualizaciones para los diferentes procedimientos. Elaborar un informe con el tiempo que se llevó construir cada procedimiento.

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

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

La documentación indica a los usuarios cómo utilizar el sistema y qué hacer en caso de que surjan problemas derivados de este uso. Los programadores desempeñan un rol clave en esta fase porque diseñan, codifican y eliminan errores sintácticos de los programas de cómputo.

FASE VI: Prueba y mantenimiento del sistema.

Realizar la programación de las pruebas del sistema. 

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

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

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

Elaborar la planificación de las horas del mantenimiento del sistema. Elaborar la lista de las operaciones que pudieran sufrir modificaciones de códigos.

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

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

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

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

Planificar gradualmente la conversión del sistema anterior. 

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

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

Evaluar la adaptabilidad de los usuarios al sistema.

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

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

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

Sistemas de Información

Definición de Sistemas de Información.

  Un sistema de información es un conjunto de componentes que interaccionan entre sí para alcanzar un fin determinado, el cual es satisfacer las necesidades de información de dicha organización. Estos componentes pueden ser personas, datos, actividades o recursos materiales en general, los cuales procesan la información y la distribuyen de manera adecuada, buscando satisfacer las necesidades de la organización.

  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 interfaz automática de salida. Por ejemplo, el Sistema de Control de Clientes tiene una interfaz automática de salida con el Sistema de Contabilidad, ya que genera las pólizas contables de los movimientos procesales de los clientes.

Clasificación de los Sistemas de Información.

Sistemas transaccionales: Son Sistemas de Información que logran la automatización de procesos operativos dentro de una organización ya que su función primordial consiste en procesar transacciones tales como pagos, cobros, entradas, salidas, etc.

Sistemas de soporte a la toma de decisiones: Son Sistemas de Información que apoyan el proceso de toma de decisiones.

Sistemas estratégicos: Son sistemas de información desarrollado en las organizaciones con el fin de lograr ventajas competitivas, a través del uso de la tecnología de información.

Video explicativo:

Características del sistema de información.

  Un SI tiene diversas características dependiendo de la perspectiva con la que se observa, lo dividiremos en dos grupos (1) desde la naturaleza:

Propósito u objetivo: todo sistema tiene uno o algunos propósitos u objetivos Las unidades o elementos (u objetos), como también las relaciones, definen una distribución que trata siempre de alcanzar un objetivo.

Globalismo o totalidad:  todo sistema tiene una naturaleza orgánica, por la cual una acción que produzca cambio en una de las unidades del sistema, con mucha probabilidad producirá cambios en todas las otras unidades de éste. En otros términos, cualquier estimulación en cualquier unidad del sistema afectará todas las demás unidades, debido a la relación existente entre ellas. El efecto total de esos cambios o alteraciones se presentará como un ajuste del todo al sistema. El sistema siempre reaccionará globalmente a cualquier estímulo producido en cualquier parte o unidad. Existe una relación de causa y efecto entre las diferentes partes del sistema. Así, el sistema sufre cambios y el ajuste sistemático es continuo. De los cambios y de los ajustes continuos del sistema se derivan dos fenómenos el de la entropía y el de la homeostasia.

Entropía: es la tendencia que los sistemas tienen al desgaste, a la desintegración, para el relajamiento de los estándares y para un aumento de la aleatoriedad. A medida que la entropía aumenta, los sistemas se descomponen en estados más simples. La segunda ley de la termodinámica explica que la entropía en los sistemas aumenta con el correr del tiempo, como ya se vio en el capítulo sobre cibernética. 

  A medida que aumenta la información, disminuye la entropía, pues la información es la base de la configuración y del orden. Si por falta de comunicación o, por ignorancia, los estándares de autoridad, las funciones, la jerarquía, etc. de una organización formal pasan a ser gradualmente abandonados, la entropía aumenta y la organización se va reduciendo a formas gradualmente más simples y rudimentarias de individuos y de grupos. De ahí el concepto de negentropía o sea, la información como medio o instrumento de ordenación del sistema.

Homeostasis: es el equilibrio dinámico entre las partes del sistema. Los sistemas tienen una tendencia a adaptarse con el fin de alcanzar un equilibrio interno frente a los cambios externos del medio ambiente.

Aunque también se pueden ver las características que tienen desde el (2) tipo de sistema:

Sistemas Transaccionales:

Agilizar las tareas operacionales de la organización.

Alta transaccionabilidad (entradas y salidas de información).

Nivel de cálculo bajo.

Sistemas de Apoyo de las Decisiones:

Baja transaccionabilidad (entradas y salidas de información).

Nivel alto de cálculo, y operaciones complejas.

Sistemas Estratégicos:

La complejidad de estos SI es alta.

Generalmente su implementación en la organizacional va precedida de los anteriores.

Apuntan a “apuntar” a otros horizontes la organización.

Importancia de los Sistemas de Información de las Organizaciones.

  Las organizaciones siempre utilizaron sistemas que les permitieron administrar el manejo de su información, con lo cual no necesariamente debe existir una computadora para reconocer la existencia de estos tipos de sistemas pues estos pueden ser también del tipo manuales; por ejemplo una distribuidora pequeña que no tenga informatizada la totalidad de sus esquemas de logística y comercialización. Lo importante es que el sistema permita almacenar, recuperar, procesar y distribuir información.

  Sin embargo, es cada vez más necesario el disponer de sistemas de información basados en computadoras por los beneficios que estos proporcionan: reducción de errores provocados por las personas a través del control de las entradas, velocidad en el procesamiento de datos, posibilidad de realizar tediosos análisis sobre los mismos, reducción de espacio físico destinado a su almacenamiento, agilidad al momento de buscar algún dato en particular, y otros tipos de ventajas que podrían lograrse en caso de enfocarse en el uso estratégico de los mismos.

  En los entornos de negocio actuales, el disponer de una buena gestión en el uso de los sistemas de información se convierte en una estrategia que pueden utilizar las empresas para hacer frente a sus fuerzas competitivas.

Ciclo de vida de los Sistemas de Información.

  Existen pautas básicas para el desarrollo de un SI para una organización:

Conocimiento de la Organización: analizar y conocer todos los sistemas que forman parte de la organización, así como los futuros usuarios del SI. En las empresas (fin de lucro presente), se analiza el proceso de negocio y los procesos transaccionales a los que dará soporte el SI.

Identificación de problemas y oportunidades: el segundo paso es relevar las situaciones que tiene la organización y de las cuales se puede sacar una ventaja competitiva(Por ejemplo: una empresa con un personal capacitado en manejo informático reduce el costo de capacitación de los usuarios), así como las situaciones desventajosas o limitaciones que hay que sortear o que tomar en cuenta(Por ejemplo: el edificio de una empresa que cuenta con un espacio muy reducido y no permitirá instalar más de dos computadoras).

Determinar las necesidades: este proceso también se denomina elicitación de requerimientos. En el mismo, se procede identificar a través de algún método de recolección de información (el que más se ajuste a cada caso) la información relevante para el SI que se propondrá.

Diagnóstico: En este paso se elabora un informe resaltando los aspectos positivos y negativos de la organización. Este informe formará parte de la propuesta del SI y, también, será tomado en cuenta a la hora del diseño.

Propuesta: contando ya con toda la información necesaria acerca de la organización es posible elaborar una propuesta formal dirigida hacia la organización donde se detalle el presupuesto, relación costo-beneficio, presentación del proyecto de desarrollo del SI.

Diseño del sistema: Una vez aprobado el proyecto, se comienza con la elaboración del diseño lógico del SI; la misma incluye el diseño del flujo de la información dentro del sistema, los procesos que se realizarán dentro del sistema, etc. En este paso es importante seleccionar la plataforma donde se apoyará el SI y el lenguaje de programación a utilizar.

Codificación: con el algoritmo ya diseñado, se procede a su reescritura en un lenguaje de programación establecido (programación), es decir, en códigos que la máquina pueda interpretar y ejecutar.

Implementación: Este paso consta de todas las actividades requeridas para la instalación de los equipos informáticos, redes y la instalación del programa generado en el paso anterior.

Mantenimiento: proceso de retroalimentación, a través del cual se puede solicitar la corrección, el mejoramiento o la adaptación del SI ya creado a otro entorno. Este paso incluye el soporte técnico acordado anteriormente.

enlaces de interés:

Introducción a la Teoría General de Sistemas [PDF]
La Teoría General de Sistemas (M. en C. Eduardo Bustos Farías) [PDF]