Estándares sobre la Seguridad de la Información y Análisis sobre el Caso ATOLAND C.A. (PDF)

Ver Desde Google Drive

Normas ISO/IEC 27001 y Consejos sobre la seguridad en internet.

acá les dejo el link de prezzi...
===> Normas ISO/IEC 27001 y Consejos sobre la seguridad en internet <===

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

Redes - Teleprocesos.

Conclusión

   Para Concluir esta fase del blog, podemos decir que hemos aprendido muchos temas necesarios para el análisis y diseño de sistemas, así como también, técnicas, metodologías y herramientas que podemos tomar para el inicio de un proyecto, cabe destacar que para hacer un sistema debemos basarnos en una metodología,  tomando en cuenta que todo proyecto debe ser diseñado por pasos como los explica kendall y kendall en su ciclo de vida, así como seguimos esos pasos debemos tomar en cuenta los tipos de diagrama de flujo como lo son el diagrama de flujo de datos, diagrama de árbol, diagrama funcional y la carta estructurada, las cuales nos muestra un panorama claro de lo que sera el sistema que deseamos diseñar.
No debe olvidar aplicar un estudio de factibilidad para verificar que el sistema deseado nos sea posible realizarlo como aplicarlo a la organización donde se desea implantar, así como si generara ganancias o perdidas para la misma.

Diagrama funcional y diagrama de árbol.

Diagrama funcional:

un diagrama funcional es una representación gráfica o dibujo de figuras geométricas que sirve para mostrar el funcionamiento de, ya sea, una institución, empresa, equipo, club o una máquina o teoría científica.

el diagrama muestra el conjunto en su totalidad, sus figuras geométricas por lo general están escritas dentro con una letra, nombre o número que las identifica y distingue de las demás.las figuras van acompañadas de líneas que unen a una con otras demostrando así los pasos que envuelven el funcionamiento del objeto que representan. la mayoría de las veces va acompañado con una leyenda o explicación debajo del dibujo, otras veces las explicaciones están contenidas dentro de las figuras geométricas.

en informática es aquel que indica las funciones de las partes principales de un sistema total, y también muestra las relaciones importantes e interacciones entres sus partes, según el diccionario científico en línea de Answers.com.

Ejemplo de diagrama funcional:

Diagrama de Árbol:

En ciencias de la computación, Un árbol es ampliamente utilizado estructura de datos que emula una estructura jerárquica árbol de la estructura con un conjunto de vinculados nodos.

Matemáticamente, se trata de un árbol, Más específicamente un arborescencia: Una relacionada acíclicos gráfico donde cada nodo tiene cero o más los niños nodos y un máximo de los padres nodo. Por otra parte, los hijos de cada nodo tiene un orden específico.

Terminología:

Un nodo es una estructura que puede contener un valor, una condición, o representar una estructura de datos por separado (que podría ser un árbol de su propia). Cada nodo en un árbol tiene cero o más nodos secundarios, Que están debajo de él en el árbol (por convención, los árboles se dibujan cada vez mayor hacia abajo). Un nodo que tiene un hijo que se llama el niño nodo padre (O ancestro del nodoO superior). Un nodo tiene a lo sumo uno de los padres.

¿Para qué sirve? 

Un diagrama de árbol es un método gráfico para identificar todas las partes necesarias para  alcanzar algún objetivo final. 

En mejora de  la calidad, los diagramas de árbol se utilizan  generalmente para identificar todas las tareas necesarias para implantar una solución.  

Se emplea para descomponer una meta u objetivo en una serie de actividades que deban o puedan  hacerse. A través de la representación gráfica de actividades se facilita el entendimiento de las  acciones que intervendrán. 

Permite a los miembros del equipo de trabajo  expandir su pensamiento al crear soluciones sin  perder de vista el objetivo principal o los objetivos secundarios. 

Ubica al equipo para que se dirija a situaciones reales versus teóricas.

Asimismo, se dimensiona el  nivel real de complejidad  de  algún  proyecto  y  se  puede  prever  el encontrarse con soluciones  inviables antes del arranque.

Ejemplos:

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:

Diccionario de datos y sus relaciones en el análisis y diseño de sistemas.

El diccionario de datos.

El diccionario de datos es una aplicación especializada de los tipos de diccionarios usados como referencia en la vida cotidiana. El diccionario de datos es una obra de consulta con información acerca de los datos (es decir, metadatos), compilada por los analistas de sistemas para guiarse en el análisis y diseño. Como un documento, el diccionario de datos recopila y coordina términos de datos específicos, y confirma lo que cada término significa para las diferentes personas en la organización. Los diagramas de flujo de datos tratados en el capítulo 7 son un excelente punto de partida para recopilar entradas para el diccionario de datos.

Una razón importante para mantener un diccionario de datos es guardar datos ordenados.

Esto significa que los datos deben, ser consistentes. Si usted guarda datos acerca del sexo de un hombre como "M" en un registro, "Masculino" en un segundo registro y como el número "1" en un tercer registro, los datos no son consistentes. Un diccionario de datos ayudará en este aspecto.

Los diccionarios de datos automatizados (parte de las herramientas CASE mencionadas anteriormente) son valiosos por su capacidad de hacer referencias cruzadas de los elementos de datos y el lugar donde se utilizan, permitiendo por tanto realizar cambios a todos los programas que comparten un elemento común, si esto fuera necesario. Esta característica suplanta el hacer cambios al azar, y evita el tener que esperar hasta que un programa deje de funcionar porque un cambio no se ha implementado en todos los programas que comparten el elemento que se ha actualizado. Evidentemente, los diccionarios de datos automatizados se vuelven importantes para los sistemas grandes que producen miles de elementos de datos que requieren catalogación y referencias cruzadas.

Relación en el análisis y diseño de sistemas.

La relación fundamental que tiene el diccionario de datos con el análisis y diseños de sistemas, es que cuando se tiene listo el diccionario de datos sirve como guía al analista para el futuro análisis y diseño de un sistema.

Estudio de Factibilidad de un Sistema.

ESTUDIO DE FACTIBILIDAD

Después de definir la problemática presente y establecer las causas que ameritan de un nuevo sistema, es pertinente realizar un estudio de factibilidad para determinar la infraestructura tecnológica y la capacidad técnica que implica la implantación del sistema en cuestión, así como los costos, beneficios y el grado de aceptación que la propuesta genera en la institución. Este análisis permitió determinar las posibilidades de diseñar el sistema propuesto y su puesta en marcha, los aspectos tomados en cuenta para este estudio fueron clasificados en tres áreas, las cuales se describen a continuación:

Factibilidad Técnica.

La Factibilidad Técnica consistió en realizar una evaluación de la tecnología existente en la organización, este estudio estuvo destinado a recolectar información sobre los componentes técnicos que posee la organización y la posibilidad de hacer uso de los mismos en el desarrollo e implementación del sistema propuesto y de ser necesario, los requerimientos tecnológicos que deben ser adquiridos para el desarrollo y puesta en marcha del sistema en cuestión.

Factibilidad Económica.

A continuación se presenta un estudio que dio como resultado la factibilidad económica del desarrollo del nuevo sistema de información. Se determinaron los recursos para desarrollar, implantar, y mantener en operación el sistema programado, haciendo una evaluación donde se puso de manifiesto el equilibrio existente entre los costos intrínsecos del sistema y los beneficios que se derivaron de éste, lo cual permitió observar de una manera más precisa las bondades del sistema propuesto.

Factibilidad Operativa.

La Factibilidad Operativa permite predecir, si se pondrá en marcha el sistema propuesto, aprovechando los beneficios que ofrece, a todos los usuarios involucrados con el mismo, ya sean los que interactúan en forma directa con este, como también aquellos que reciben información producida por el sistema. Por otra parte, el correcto funcionamiento del sistema en cuestión, siempre estará supeditado a la capacidad de los empleados encargados de dicha tarea.

Ejemplo de un estudio de factibilidad:

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.

Diseño de archivo y bases de datos.

El diseño de archivos y bases de datos incluye decisiones con respecto a la naturaleza y contenido del propio archivo, como si se fuera a emplear para guardar detalles de las transacciones, datos históricos, o información de referencia. Entre las decisiones que se toman durante el diseño de archivos, se encuentran las siguientes:

a) Los datos que deben incluirse en el formato de registros contenidos en el archivo.

b) La longitud de cada registro, con base en las características de los datos que contenga.

c) La secuencia a disposición de los registros dentro del archivo (la estructura de almacenamiento que puede ser secuencial, indexada o relativa).

No todos los sistemas requieren del diseño de todos los archivos, ya que pueden existir archivos de un sistema anterior que pueden ser utilizados para el nuevo sistema y probablemente solo tenga que enlazarse el nuevo sistema al archivo maestro donde se encuentran los registros.

En lo que se refiere a las bases de datos, la mayoría de los sistemas de información ya se han implantado en sistemas de cómputos grandes o pequeños, por lo que utilizan una base de datos que puede abarcar varias aplicaciones, por esta razón estos sistemas utilizan un administrador de base de datos. En este caso el diseñador no construye la base de datos sino que consulta a su administrador para ponerse de acuerdo en el uso de esta base de datos en el sistema.

EL MODELO RELACIONAL.

• Todos los datos se representan en tablas.

           o    Incluso los resultados de cualquier consulta son otra tabla.

• Las tablas están compuestas por filas y columnas.

• Las filas y las columnas, en principio, carecen de orden (p.ej., el orden en el que se muestren las filas y las columnas no importa).

           o    Las filas sólo se ordenan si se le indica a la base de datos que lo haga, mediante el correspondiente comando. De no ser así, el orden será arbitrario, y puede cambiar en caso de tratarse de una base datos dinámica.

           o    El orden de las columnas lo determina cada consulta.

• Cada tabla tiene una clave primaria, un identificador único, compuesto por una o más columnas.

• La mayoría de las claves primarias están formadas por una única columna (p.ej., CIUDAD_ID). 

• Para establecer una relación entre dos tablas es necesario incluir, en forma de columna, en una de ellas la clave primaria de la otra. A esta columna se le llama clave secundaria.

• Estos dos conceptos --clave primaria y secundaria-- son los más importantes en el diseño de bases de datos. Es importante dedicarles tiempo, para entender bien en qué consisten y cómo funcionan.

• Cualidades de un buen diseño de base de datos.
• Reflejar la estructura del problema en el mundo real.
• Ser capaz de representar todos los datos esperados, incluso con el paso del tiempo.
• Evitar el almacenamiento de información redundante.
• Proporcionar un acceso eficaz a los datos.
• Mantener la integridad de los datos a lo largo del tiempo.
• Ser claro, coherente y de fácil comprensión.
• Nota: A veces, estos objetivos pueden ser contradictorios.

INTRODUCCIÓN AL MODELO ENTIDAD/RELACIÓN.

• El modelo Entidad/Interrelación (E/R): un método de diseño de bases de datos.
• Muestra de una versión simplificada.
• Representa los datos mediante una serie de entidades que disponen de atributos.
• Una entidad es una clase de objetos o conceptos claramente dentificable.
• Las entidades establecen interrelaciones con otras entidades.
• El resultado de este proceso es una base de datos normalizada que facilita el acceso a los datos y evita su duplicado. 

Nota: en su mayor parte, el diseño formal de una base de datos se centra en la normalización de la base y en asegurar que el diseño se ajuste a un nivel de normalización (p.ej., first normal form, second normal form,etc.). Este nivel de formalidad va mucho más allá, pero es importante saber que existen tales formalidades.

Nota: en su mayor parte, el diseño formal de una base de datos se centra en la normalización de la base y en asegurar que el diseño se ajuste a un nivel de normalización (p.ej., first normal form, second normal form,etc.). Este nivel de formalidad va mucho más allá, pero es importante saber que existen tales formalidades.

PROCESO DEL DISEÑO EN MODELO ENTIDAD / RELACIÓN.

• Identificar las entidades que debe presentar la base de datos.
• Determinar las cardinalidades de las interrelaciones establecidas entre las distintas entidades y clasificar estas interrelaciones entre los siguientes tipos:

             o    Uno a uno (p.ej., una parcela sólo tiene una dirección).

             o    Uno a muchos (p.ej., en una parcela pueden ocurrir varios incendios).

             o    Muchos a muchos (p.ej., la venta de parcelas: una misma parcela la pueden vender varios propietarios y cada propietario puede vender varias parcelas).

• Dibujar el diagrama Entidad/Interrelación.
• Determinar los atributos de cada entidad.
• Definir la clave primaria (única) de cada entidad.

PASO DEL MODELO E/R AL DISEÑO DE LA BASE DE DATOS.

• Las entidades entre las que hay una interrelación uno a uno se deben fusionar en una sola entidad.
• Una vez hecho esto, cada una de las entidades que quedan se convierte en una tabla con una clave primaria y una serie de atributos, de los cuales algunos pueden ser claves secundarias. 
• Las interrelaciones uno a muchos se transforman en atributo y clave secundaria de la tabla que representa a la entidad situada del lado de la interrelación correspondiente a muchos.
• Las interrelaciones muchos a muchos entre dos entidades pasan a ser una tercera tabla con claves secundarias procedentes de ambas entidades. Estas claves secundarias deberán formar parte de la clave primaria de la tabla en la que se convierte la interrelación, cuando corresponda.
• Hay una serie de herramientas disponibles en el mercado que pueden automatizar el proceso de conversión de un modelo E/R en un esquema de base de datos.

Diseño de archivo y bases de datos por Kendall y Kendall:

Diseño de entradas, procesos y salidas.

Diseño de entradas: 

(Diseñar el sistema de recopilación de datos)

Las especificaciones de entrada describen la manera en que los datos ingresarán al sistema para su procesamiento.  Las características de diseño de la entrada pueden asegurar la confiabilidad del sistema y producir resultados a partir de datos exactos, o también pueden dar como resultado la producción de información errónea.  Asimismo, el diseño de la entrada determina sí el usuario puede interactuar con el sistema de manera eficiente.  El diseño de la entrada es el enlace que une al sistema de información con el mundo y sus usuarios.  Algunos aspectos del diseño cambian, lo que depende si el sistema está orientado hacia lotes o en línea.  Pero sin considerar el sistema, existen aspectos generales en la entrada que todos los analistas deben tener en cuenta.

El diseño de la entrada consiste en el desarrollo de especificaciones y procedimientos para la preparación de datos, la realización de los pasos necesarios para poner los datos de una transacción en una forma utilizable para su procesamiento, así como la entrada de éstos.  La entrada de estos los datos se logra al instruir la computadora para que los lea ya sea de documentos escritos o impresos, o por personas que los escriben directamente en el sistema.

Controles de la cantidad de entrada. 
Existen varias razones que explican por qué un buen diseño debe controlar la cantidad de datos en la entrada.  Primero, las operaciones de preparación y entrada dependen de las personas.  Dado que los costos de la mano de obra son altos, los asociados con la preparación e ingreso de los datos también lo son altos.  Disminuir los requerimientos de datos puede reducir los costos y ocurrir lo mismo con los costos de mano de obra.  Segundo, la fase de entrada puede ser un proceso lento que toma mucho más tiempo que el que necesitan las computadoras para llevar a cabo sus tareas.  De hecho, la computadora quizá permanezca sin hacer nada durante el tiempo en que se preparan los datos y la entrada para su procesamiento.  Al disminuir los requerimientos de la entrada, el analista puede acelerar todo el proceso desde la captura de datos hasta que los resultados llegan a manos de los usuarios.

• Evitar Retrasos. Un retraso en el procesamiento, que es un resultado de las operaciones de preparación o de entrada de datos, recibe el nombre de cuello de botella.  Evitar los cuellos de botella debe ser siempre uno de los objetivos que el analista persiga al diseñar la entrada.

• Evitar errores de datos. En cierto sentido la tasa de errores depende de la cantidad de datos, ya que entre más pequeña sea ésta, menores serán las oportunidades para cometer errores.  Es común encontrar en las operaciones de venta al por menor una tasa promedio del 3% de error en las operaciones de entrada de datos.  Si el volumen de datos es de 10,000 transacciones por semana, entonces se presentarán aproximadamente 300 errores.  A pesar de lo anterior, el analista puede reducir el número de errores al disminuir el volumen de datos que deben ingresarse por cada transacción.  El analista también puede modificar las tasas de error de una operación a través del diseño de la entrada, ya que la forma en que deben ingresar los datos puede tener efectos sobre la incidencia de los errores.  Otro aspecto del control de errores es la necesidad de detectarlos cuando éstos se presentan.  Las verificaciones y balances en los programas para entrada de datos, denominadas técnicas de validación de entradas, también descubren errores en la entrada.

• Evitar pasos adicionales. Algunas veces el volumen de transacciones y la cantidad de datos en preparación, o en el trabajo de entrada de datos, es algo que no se puede controlar.  Cuando no es posible reducir el volumen de transacciones, el analista debe asegurar que el proceso sea lo más eficiente posible.  El analista experimentado también evitará diseños para la entrada que traigan como consecuencia una mayor cantidad de pasos a seguir.  El efecto que trae consigo ya sea añadir o quitar un paso cuando se alimentan los cheques al proceso bancario, será multiplicado muchas veces en el transcurso de un día de trabajo.

• Mantener la sencillez del proceso. Quizá el mejor consejo para los analistas es alcanzar todos los objetivos ya mencionados en la forma más sencilla posible.  Claro está que al incluir tantos controles sobre los errores las personas puedan tener dificultades al emplear el sistema.  En otras palabras. el control de los errores puede obstruir la tarea.  El sistema mejor diseñado se ajusta a las personas que lo utilizarán y al mismo tiempo, proporcionarán métodos para el control de los errores.  La simplicidad funciona y es aceptada por los usuarios.  En contraste, cuesta trabajo que los usuarios acepten diseños para la entrada que sean complejos o confusos, y no existe ninguna garantía para el éxito al instalar un sistema complejo.  En consecuencia, es aconsejable evitar la complejidad cuando hay opciones más sencillas.

• Validación dela entrada. Los diseños de las entradas tienen como finalidad reducir la posibilidad de cometer errores o equivocaciones durante la entrada de datos.  Sin embargo, siempre debe suponer que se presentarán errores. Estos deben detectarse durante la entrada y corregirse antes de guardar los datos o procesarlos.  Es mucho más difícil corregir datos equivocados después de almacenarlos que antes de hacerlo.  De hecho los datos equivocados se olvidan con frecuencia hasta que alguien utilice un reporte basado en esos datos y cuestiona su exactitud y validez.

Los analistas de sistemas deciden los siguientes detalles del diseño de entradas.

1. Qué datos ingresan al sistema.
2. Qué medios utilizar.
3. La forma en que se deben disponer o codificar los datos.
4. El diálogo que servirá de guía a los usuarios para dar entrada a los datos.
5. Validación necesaria de datos y transacciones para detectar errores.
6. Métodos para llevar a cabo la validación de las entradas y los pasos a seguir cuando se presentan errores.

Las decisiones de diseño para el manejo de entradas, especifican la forma en que serán aceptados los datos para su procesamiento por computadora. Los analistas deciden si los datos serán proporcionados directamente, quizá a través de una estación de trabajo, o por el uso de documentos, como talones de venta, cheques bancarios o facturas, donde los datos a su vez son transferidos hacia la computadora para su procesamiento.

Diseño de procedimientos: 
(Diseñar el sistema de procesamiento de datos)

Los procedimientos especifican qué tareas deben efectuarse al utilizar en sistema y quiénes son los responsables de llevarlas a cabo. Entre los procedimientos importantes se encuentran:

• Procedimientos para entrada de datos. Métodos para la captura de datos de las transacciones y su ingreso en el sistema de información.

• Procedimientos durante la ejecución. Pasos y acciones emprendidos por los operadores del sistema y, en ciertos casos, por los usuarios finales que interactúan con el sistema para alcanzar los resultados deseados.

• Procedimientos para el manejo de errores. Acciones a seguir cuando se presentan resultados inesperados.

• Procedimientos de seguridad y respaldo. Acciones para proteger al sistema y sus recursos contra posibles daños.

Diseño de las salidas:
(Diseño del sistema de informes y producción de documentos)

El término salida, como es probable que el lector lo conozca, se refiere a los resultados e información generados por el sistema. Para muchos usuarios finales, la salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación. En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresas datos en él, pero utilizan la salida generada por el sistema. Cuando diseñan la salida, los analistas deben de realizar lo siguiente:

• Determinar qué información presentar.
• Decidir si la información será presentada en forma visual, verbal o impresa y seleccionar el medio de salida.
• Disponer la presentación de la información en un formato aceptable.
• Decidir cómo distribuir la salida entre los posibles destinatarios.

Para llevar a cabo las actividades antes mencionadas, se requieren decisiones específicas tales como el empleo de formatos ya impresos cuando se preparan reportes, cuántas líneas planear sobre una página impresa o si se debe emplear gráficas y colores.

 La salida es la única razón para el desarrollo del sistema y la base sobre la que ellos evaluarán la utilidad de la aplicación.  En la realidad, muchos usuarios no operan el sistema de información y tampoco ingresan datos en él, pero utilizan la salida generada por el sistema.

El diseño de la salida de la computadora debe avanzar en una forma organizada y bien pensada: tiene que desarrollarse correctamente mientras que al mismo tiempo se garantice que cada elemento de la salida está diseñado para que las personas encuentren que el sistema es fácil de emplear.

El termino salida se utiliza para denotar cualquier información, ya sea impresa o en una pantalla.  Cuando los analistas diseñan la salida:

• Identifican la salida específica que es necesaria para satisfacer los requerimientos de la información.
• Seleccionan los métodos para presentar la información.
• Crean los documentos, reportes u otros formatos que contienen la información producida por el sistema.

Un sistema de información debe alcanzar uno o más de los siguientes objetivos:

1. Expresar información relacionada con actividades pasadas, estado actual o protecciones para el futuro.
2. Señalar eventos importantes, oportunidades, problemas o advertencias.
3. Iniciar una acción.
4. Confirmar una acción.

El buen diseño de la salida de los sistemas, no puede ser desarrollado en forma independiente del uso que se dará a la salida.  En otras palabras, no se puede clasificar como buena una salida estéticamente atractiva o que haga uso de una nueva tecnología, a menos que satisfaga las necesidades de la organización y de sus usuarios.  El propio proceso de diseño comienza cuando el analista de sistemas identifica la salida que debe producir el sistema (un proceso que se inicia durante la determinación de requerimientos).

Aspectos importantes de las Salidas.
Cuatro preguntas, a las que debe darse respuestas en forma completa y apropiada, ayudan a los expertos de diseño de sistemas a comprender mejor lo que debe ser la salida de un nuevo sistema:

¿Quiénes Recibirán La Salida?
El usuario, ¿forma o no parte de la organización?, Quizá los usuarios externos tengan requerimientos específicos que no se pueden cambiar y que dictan los requerimientos de contenido, formato y medio de presentación.  Tal vez las organizaciones decidan presentar la misma información en forma diferente cuando ésta es enviada a los usuarios tanto externos como internos.

¿Cuántos Detalles Son Necesarios?
Pocos detalles son necesarios para indicarle a alguien que renové una licencia de manejo (nombre, dirección, fecha de renovación, cuota y una identificación de la salida como aviso de renovación).  Sin embargo, un informe trimestral de venta de ventas contiene muchos detalles con formatos diferentes que son de ayuda para trasmitir un mensaje (qué sucedió, cómo ocurrió y cuál fue el resultado) a todos los usuarios.  Asimismo, la cantidad de datos también sugiere si deben emplear métodos de impresión o de presentación en una pantalla.

¿Cuántos Y Que Tan Frecuente Es La Salida?
El calendario junto con la oportunidad de la salida, son guías específicas del diseño.  Algunas salidas se producen con poca frecuencia y sólo cuando aparecen ciertas condiciones: la emisión del aviso de renovación de licencia puede ocurrir cada 4 años, la emisión de una notificación de pago sucede cuando el saldo de la cuenta está vencido. sin embargo, la organización puede requerir cada mes una salida que indique todas las licencias que deben renovarse el próximo mes, o una salida cada semana que señale todas aquellas cuentas cuyo saldo se venció durante la semana. 

¿Qué Método Utilizar?
¿Debe ser impresa o presentada en pantalla?  La salida impresa se emplea con bastante frecuencia.  Sin embargo, si un sistema da respuestas del tipo sí o no a las consultas, a menudo es apropiado presentar la respuesta en una pantalla, algunos sistemas emplean una salida de audio para informarles sobre un nuevo número telefónico o el cambio de éste.

Carta estructurada

La carta estructurada también es conocida como el modelo de producto, es una metodología 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.

Pasos para obtener una apropiada carta estructurada:

1) Fraccionar el sistema en unidades apropiadas a través del análisis de transacciones.
2) Convertir cada uno de esas unidades en una carta de estructura a través del análisis de transformaciones.
3) Refinar cada una de las cartas de estructuras obtenidas y vinculadas en la implantación del sistema.

Transacción: Es un componente del sistema que nace de algún evento que tiene lugar en el ambiente (fuera del sistema) y culmina con algún efecto o resultado sobre el ambiente.

Tiene 5 pasos:
1) Evento.
2) Estimulo sobre el sistema.
3) Actividad que realiza el sistema de acuerdo con el estimulo.
4) Respuesta del sistema.
5) Efecto sobre el ambiente.

Cada transacción pertenece a una clase o tipo de transacción, se identifican a través de los eventos del sistema.

Cada unidad física del sistema surge a partir de un evento.

Análisis de Transformaciones:

Es el método (estrategia) que permite darle una forma apropiada a la carta de estructura a través de la identificación de la transformación central.

Pasos para el análisis de transformación:

1) Construir el DFD (diagrama de flujo de datos) para la transacción que pretendemos graficar.
2) Encontrar la transformación central dentro del DFD.
3) Convertir a esa unidad del DFD en una carta de estructura.
4) Refinar a la carta de estructura a través de los criterios del diseño estructurado.
5) Verificar que la carta de estructura cumpla con todos los requisitos planteados para el modelo esencial.

Para encontrar la transformación central (2º PASO) debemos buscar:
- Que la transformación central sea la parte del DFD que contiene las actividades principales del sistema…

*Recorremos los flujos de entrada (saltando los que depuran las entradas)
**Recorremos los procesos de salida (salteando todo lo que forma parte de la salida, formateos, impresiones etc).

Flujo de datos esencial (sin la entrada ni la validación ni formateos).

Transformación central: Concatenamos la transformación central en el nivel más alto y subordinamos las demás burbujas/ramas.

Promoviendo: Debemos encontrar una burbuja que cumpla con las características, si hay mas de una, hay que ver cual de ellas es mas adecuada.

Comentarios de los gráficos:
• Agregar los módulos de leer/imprimir/grabar.
• Reorganizar los módulos aferente y eferentes manteniendo el balance (si resulta muy difícil es porque esta mal hecho el DFD).
• Agregar los módulos de tratamiento de errores.
• Factorizar la transformación central si corresponde.

Más comentarios:
• Asegurarse de que todos los módulos tienen nombres concordantes con su rol jerárquico.
• Incluir las señales que correspondan a funcionamiento de la transacción.
• Tratar de que el acoplamiento sea el adecuado (identificar los datos e interfaces).
• mejorar la calidad de la carta de estructura.

Ejemplo de una carta estructurada:

Descomposición y modularizacion.

La descomposición y modularidad son consecuencia de la complejidad de los problemas, y de la necesidad de hacer manejable el desarrollo de la solución de los mismos. Para abarcar el desarrollo del sistema complejo, el problema se divide en subproblemas más fácilmente manejables, que integrados formaran la solución al sistema completo. Más formalmente, Meyer [30] ha definido una serie de propiedades para evaluar la modularidad:

Descomposición Esta propiedad permite definir componentes de alto nivel en otros de bajo nivel. Esta descomposición puede ser recursiva, es decir, aplicando la máxima de divide y vencerás.

Composición La composición se puede ver como el problema inverso a la descomposición. Un módulo de programación preserva la composición modular si facilita el diseño de elementos de programación que se pueden ensamblar entre sí para desarrollar aplicaciones. Un ejemplo de composición modular son los componentes ya desarrollados (COTS, Commercial-off-the-Shelf). La composición modular está directamente vinculada con la reutilización, mediante mecanismos que permitan diseñar elementos que respondan a funcionalidades bien definidas y reutilizables en diversos de contextos.

Comprensión Un método de programación preserva la comprensión modular si facilita el diseño de elementos de programación que se pueden interpretar fácilmente sin tener que conocer el resto de los módulos.

Un aspecto fundamental de la comprensión es la documentación y en el caso particular de los componentes COTS, la gestión e indexación de los mismos para facilitar su reutilización.

Continuidad La continuidad se refiere a que un pequeño cambio en la especificación debe conllevar en la implementación un cambio igualmente pequeño. Una de las leyes de Lehman sobre la evolución del software, afirma que si un proyecto está vivo inevitablemente evolucionara y cambiara. Por tanto, es importante que los cambios en los requisitos repercutan en un número limitado y localizado de módulos.

Protección Esta propiedad consiste en que los efectos de las anomalías de ejecución queden confinados al módulo donde se produjo el error, o que se propaguen a un número limitado de módulos con los que interactúan directamente. Un ejemplo de protección se da en la validación de datos introducidos por parte del usuario, dicha validación debería hacerse en los módulos que tratan la entrada, sin permitir que los datos incorrectos se propaguen a aquellos módulos donde se procesan.

Medición de la modularidad.

Las propiedades y reglas mencionadas anteriormente buscan que las dependencias entre módulos sean mínimas. La modularidad se suelen medir con los conceptos de acoplamiento y cohesión definidos a continuación.

Acoplamiento:

El acoplamiento mide el grado de interconexión existente entre los módulos en los que se ha dividido el diseño de la arquitectura de un sistema software.

El objetivo es conseguir un acoplamiento bajo entre módulos, también llamado débil, genera sistemas más fáciles de entender, mantener y modificar, ya que cambios en la interfaz de un componente afectarían un número reducido de cambios en otros componentes. Por tanto, debemos acercarnos al mínimo número de relaciones posibles entre todos los módulos en la que un módulo sólo se comunicaría con otro módulo, es decir, (n-1) comunicaciones entre módulos, donde n es el número de módulos de un sistema (figura 1(a)).

Por el contrario debemos alejarnos del máximo número de conexiones, (n(n- 1)/2), donde se produce un acoplamiento fuerte (figura 1 (b)).

Además del número de conexiones, el grado de acoplamiento puede depender de la complejidad de las conexiones, los lugares donde se realicen

Figura 1: (a) Acoplamiento débil; (b) Acoplamiento fuerte

Las referencias a los módulos, el volumen y tipo de datos que intercambian los módulos.

Cohesión:

Otro aspecto fundamental del diseño, también derivado de una concepción modular del mismo, es la cohesión. Un subsistema o módulo tiene un alto grado de cohesión si mantiene unida funcionalidad común. Por ejemplo, una clase dedicada al manejo de fechas, tiene sólo operaciones relacionadas con las fechas y no otras funcionalidades que usen fechas como podrían ser la gestión de cumpleaños, etc.

Por tanto, el objetivo es diseñar módulos robustos y altamente cohesionados cuyos elementos estén fuertes relacionados entre sí buscando la cohesión funcional, en la que un módulo realiza operaciones bien definidas y suscritas a una funcionalidad requerida facilitando las propiedades compresibilidad, reutilización.

Cuando los módulos agrupan funcionalidad por otros motivos que no sean funcionalidad la cohesión no será óptima. Por ejemplo, cohesión secuencial en la que la funcionalidad se agrupa por la secuencia de ejecución, cohesión por comunicación al compartir los mismos datos, o la peor de todas, cohesión por coincidencia agrupando funcionalidad sin orden (cajón desastre).