Sistemas De Informacion

INSTITUTO TECNOLOGICO DE CHIHUAHUA II

SISTEMAS DE INFORMACION II

UNIDAD I

ING. MA. EUGENIA CARMONA MUÑOZ

Contenido

1 FUNDAMENTOS DE DISENO 3

1.1 Panorama General Del Diseño Físico y Lógico 3

1.2 CONCEPTOS DE DISEÑO DE SISTEMAS 7

1.2.1 Acoplamiento y Coherencia 7

1.2.2 Arquitectura del Software 20

1.3 HEURISTICAS DE DISENO 20

1.3.1 Tamaño de Módulo 21

1.3.2 Amplitud del Control (Fan-out) 22

1.3.3 Ancho de Entrada (Fan-In) 23

1.3.4 Alcance de Efecto / Alcance de Control 24

Examen 25

1 FUNDAMENTOS DE DISENO

1.1 Panorama General Del Diseño Físico y Lógico

DISEÑO FÍSICO

El diseño físico de sistemas es la forma en que se lograrán las tareas del sistema, lo que incluye la manera de conjuntar sus componentes y las funciones que realizará cada uno de éstos.

En el diseño físico se especifican las características de los componentes del sistema requeridos para poner en práctica el diseño lógico. En esta fase deben delinearse las características de cada uno de los componentes que se enumeran a continuación.

Diseño de hardware. Debe especificarse todo el equipo de cómputo, lo que incluye dispositivos de entrada, procesamiento y salida, con sus características de rendimiento. Por ejemplo, si el diseño lógico especifica que la base de datos debe contener grandes volúmenes de datos históricos, se requerirá que los dispositivos de almacenamiento del sistema sean de gran capacidad.

Diseño de software.

Deben especificarse las características de todo el Software Por ejemplo, si en el diseño lógico se indica la necesidad de que de que los usuarios actualicen al mismo tiempo la base de datos, en el diseño físico deben especificarse un sistema de administración de base de datos que lo permita algunos casos se puede adquirir el software, mientras que en otros se desarrollan internamente. Las especificaciones de diseño lógico, en cuanto a requisitos de salidas, entradas y procesamiento de los programas, también se toman en cuenta durante el diseño físico del software. Así pues, se especificaría la capacidad de acceder a datos almacenados en ciertos archivos de disco que el programa utiliza.

Diseño de bases de datos.

Es necesario detallar el tipo, estructura y funciones de las bases de datos. Las relaciones entre los elementos de datos establecidos en el diseño lógico deben reflejarse también en el diseño físico. Estas relaciones incluyen aspectos tales como las rutas de acceso y la organización de la estructura de archivos. Por fortuna, existen muchos sistemas excelentes de administración de bases de datos que son útiles para esta actividad.

Diseño de telecomunicaciones.

Deben especificarse las características necesarias del software, medios y dispositivos de telecomunicaciones. De tal suerte, si el diseño lógico indica que todo los miembros de un departamento deben compartir datos y software, ha de hacerlo posible la configuración de la red de área local y el software de telecomunicaciones especificados en el diseño físico.

Diseño de personal.

Este paso incluye especificar los antecedentes y experiencia de los individuos que más probablemente satisfagan las descripciones de empleos que se incluyen en el diseño lógico.

Diseño de procedimientos y controles. Comprende detallar la forma en que se ejecuta cada aplicación y las medidas para minimizar las probabilidades de delitos y fraudes. Tales especificaciones incluyen métodos de auditoría, soporte y distribución de salidas.

DISEÑO LOGICO

El diseño lógico de sistemas se refiere a lo que hará el nuevo sistema, es una descripción de los requisitos funcionales de un sistema. En otras palabras, es la expresión conceptual de lo que hará el sistema para resolver los problemas identificados en el análisis previo. A falta de este paso, los aspectos técnicos del sistema (como los dispositivos de hardware que deban adquirirse) con frecuencia oscurecen la solución.

El diseño lógico incluye planear el propósito de cada elemento del sistema, sin relación con consideraciones de hardware y software. Las especificaciones de diseño lógico que se determinar, y documentan se detallan en los párrafos siguientes.

Diseño de salida.

Es una descripción de todas las salidas del sistema e incluye sus tipos, formato, contenido y frecuencia. Por ejemplo, el requisito de que todas las facturas de la compañía incluyan el número de factura original de los clientes es una especificación de diseño lógico. Las herramientas de diseño de pantallas e informes pueden usarse durante la fase de diseño de salidas para satisfacer los requisitos de salidas del sistema.

Diseño de entrada.

Una vez que se completa el diseño de salidas, puede iniciarse el de entradas. En éste se especifican los tipos, formato, contenido sistema capture los números telefónicos de los clientes cuando éstos llaman a la organización y use tal dato para buscar de manera automática la información de su cuenta, es una especificación de diseño lógico. Es posible utilizar diagramas y diseños de pantallas e informes diversos para especificar el tipo, formato y contenido de los datos de entrada.

Diseño de procesamiento.

Los tipos de cálculos, comparaciones y manipulaciones de datos en general que requiere el sistema se determinan durante esta fase. Por ejemplo, un programa de nómina requiere cálculos de los sueldos brutos y netos, retenciones de impuestos federales y locales, y otras deducciones y planes de ahorro.

Diseño de archivos y bases de datos.

En muchos sistemas de información se requieren subsistemas de archivos y bases de datos. Las características de estos subsistemas se especifican también en la fase de diseño lógico. Por ejemplo, la capacidad para obtener la actualización instantánea de los registros de los clientes es una especificación de diseño lógico. En muchos casos, un administrador de bases de datos participa en este aspecto del diseño. Los diagramas de flujo de datos y de entidad relación por lo común se emplean durante el diseño de archivos y bases de datos.

Diseño de telecomunicaciones.

Durante el diseño lógico es necesario especificar los sistemas de redes y telecomunicaciones. Por ejemplo, en un hotel podría especificarse un sistema de cliente/servidor con un cierto número de estaciones de trabajo enlazadas con el servidor. A partir de estos requisitos, podría optarse por una topología híbrida. Los programas de gráficos y las herramientas de CASE son útiles para facilitar el diseño de redes lógicas.

Diseño de procedimientos.

Todo sistema de información requiere procedimientos para la ejecución de aplicaciones y la solución de los problemas que surjan. Estos requisitos importantes se capturan durante el diseño de procedimientos. Una vez diseñados, los procedimientos se pueden describir con programas de procesamiento de texto. A manera de ejemplo, los pasos necesarios para añadir una nueva cuenta de cliente podrían incluir una serie de tareas manuales y computarizadas. Deben redactarse procedimientos escritos para que sean eficaces y todo mundo los siga.

Diseño de controles y seguridad.

Otra parte importante del diseño lógico es determinar la frecuencia y características necesarias de los sistemas de respaldo. En general, debe tenerse apoyo de todo, lo que incluye el hardware, software, datos, personal, insumos e instalaciones. Además, en esta fase del diseño lógico ha de considerarse la planeación de cómo prevenir un desastre del equipo de cómputo y la forma de recuperarse de él si ocurre.

Diseño de personal y empleos.

Algunos sistemas requieren contratar empleados adicionales, mientras que con otros es necesario modificar las tareas relacionadas con uno o más empleos de SI existentes. Los nombres y descripciones de los puestos se especifican durante el diseño de personal y empleos. Los organigramas son útiles en el diseño de personal para diagramar los empleos y sus nombres. También se utilizan procesadores de textos para describir las funciones de cada puesto.

1.2 CONCEPTOS DE DISEÑO DE SISTEMAS

1.2.1 Acoplamiento y Coherencia

La tecnología de información y su historia a lo largo de la historia el hombre ha necesitado manejar y transmitir información para ello ha estado creando maquinas y métodos.

La informática surge como la ciencia encargada del estudio y desarrollo de estas maquinas y métodos que constituyen la tecnología de información.

La tecnología de información abarca desde artefactos, como papel, plumas, libros, cámaras, videograbadoras, computadoras, etc., hasta herramientas simbólicas como el lenguaje escrito, símbolos matemáticos, modelos químicos etc.

Sin estas maquinas y métodos no seriamos capaces de visualizar nuestro ambiente, entenderlo ni controlarlo creativamente.

La historia de la tecnología de información se ha seccionado en diferentes eras:

La era premecánica: 3000 a.C. −1450 d.C. (el nacimiento de la información) papel primer sistema de escritura, alfabetos libros, bibliotecas de numeración, ábaco y plumas.

La era mecánica: 1450< −1840 – (la explosión de la información) reglas de cálculo, periódicos, revistas, Imprenta y maquinas analíticas.

La era electromecánica: 1840 – 1940 (telecomunicaciones) telégrafo y teléfono.

La era electrónica 1940 – presente, UNIVAC, ENIAC, primeras computadoras electrónicas digitales, generaciones de computadoras digitales etc.

Los continuos avances en tecnológica de información tienen un fuerte impacto sobre la forma en que las personas trabajan, pues facilita el trabajo en equipo y la comunicación a distancia.

Con frecuencia la información generada por un medio computarizado se trata con menos escepticismo que la obtenida por otros medios.

SISTEMA

Es un conjunto de componentes que interaccionan entre sí para lograr un objetivo común. Nuestra sociedad está rodeada de sistema. Conjunto de componentes que interaccionan entre sí, para lograr un objetivo Es un conjunto de elementos en común. Una organización es un sistema. Es todo aquello con lo cual entramos. Interactúan entre sí para lograr un fin. En contacto durante nuestra vida cotidiana.

Ejemplos:

El sistema digestivo

Las personas se comunican con el lenguaje, que es un sistema muy desarrollado formado por palabras y símbolos que tienen significado para el que habla y para quienes lo escuchan.

El departamento de contabilidad, por ejemplo quizás esté formado por cuentas por pagar, cuentas por cobrar, facturación y auditoria entre otras.

TEORÍA GENERAL SE SISTEMAS (TGS)

Fue desarrollada por Ludwin Von Bertalanffy alrededor de la década de 1920/1930, y se caracteriza por ser una teoría de principios universales aplicables a los sistemas en general. La Teoría General de Sistemas no busca solucionar problemas o intentar soluciones prácticas, pero sí producir teorías y formulaciones conceptuales que pueden crear condiciones de aplicación en la realidad empírica.

Según Bertalanffy los fines principales de la Teoría General de Sistema son:

Conducir hacia la integración en la educación científica.

Desarrollar principios unificadores que vallan verticalmente por el universo de las ciencias individuales.

Centrarse en una Teoría General de Sistemas.

Tendencia general hacia una integración en las varias ciencias, naturales y sociales.

Medio importante para aprender hacia la teoría exacta en los campos no físicos de la ciencia.

PRINCIPIOS DE LA TEORÍA GENERAL DE SISTEMAS

Todos los sistemas crecen.

Cuanto más especializado sea un sistema, menor será su capacidad de adaptarse a los cambios en su ambiente.

Entre más grande sea un sistema, mayor cantidad de recursos consumirá.

Todos los sistemas forman parte de sistemas mayores y, a su vez, son formados por sistemas menores o subsistemas.

La finalidad de un sistema es la razón de su existencia. Para alcanzar sus objetivos, los sistemas interactúan con su ambiente. El ambiente de un sistema está formado por todos los objetos que se encuentran fuera de las fronteras del sistema. Los sistemas que interactúan con su ambiente se denominan sistemas abiertos. Todos los sistemas actuales son abiertos. Los sistemas que no interactúan con su ambiente se denominan sistemas cerrados, pero estos solamente existen en teoría.

La teoría general de sistemas demuestra que tanto los sistemas naturales como los creados por el hombre se comportan de la misma manera y cumplen con los mismos principios, de lo contrario, no serian sistemas.

En la actualidad, la mayoría de estos sistemas incluyen las computadoras, pero es importante señalar que dichos sistemas existían antes de que hubiera computadoras; de hecho, algunos sistemas continúan por completo sin computarizar y podrían permanecer así durante muchas décadas más. Otros contienen a la computadora como componente, pero también incluyen uno o más componentes no computarizados (o manuales).

ELEMENTOS DEL SISTEMA

Los propios elementos y las relaciones entre ellos determinan el funcionamiento del sistema. Los sistemas poseen entradas, procesamiento, mecanismos, salidas y retroalimentación. Piénsese, por ejemplo, en el lavado automático de automóviles. Por supuesto, las entradas tangibles de este proceso son un auto sucio, agua y los diversos ingredientes de limpieza en uso; tiempo, energía, habilidad y conocimiento también son indispensables como entradas de este sistema. Tiempo y energía son necesarios para que el sistema opere; la habilidad sería la capacidad para operar exitosamente el rociado: de líquido, el cepillo espumante y los dispositivos de secado con aire, y el conocimiento interviene para definir los pasos a seguir en la operación de lavado de autos y del orden en que éstos deben ejecutarse.

Los mecanismos de procesamiento consisten en seleccionar primero que nada la opción de limpieza deseada (sólo lavado; lavado y encerado; lavado, encerado > pulido, etc.) y hacérsela saber al operador del servicio de lavado. Observe además la existencia de un mecanismo de retroalimentación (la opinión del cliente acerca del grado de limpieza de su automóvil). Los rociadores expulsan agua, jabón líquido o cera dependiendo en qué paso del proceso esté el automóvil y de las opciones seleccionadas. La salida es un auto limpio. Es importante señalar que para obtener buenos resultados es preciso que los elementos o componentes independientes del sistema (rociador de líquido, cepillo espumante y secador) interactúen entre sí. En la siguiente figura aparecen unos cuantos sistemas con sus elementos y metas.

ENTRADA

Carne, papas, jitomates, lechuga, pan, bebidas, trabajadores, administradores Estudiantes Profesores Administradores Libros de texto Equipo Actores, director, personal técnico, escenarios, equipo.

MECANISMOS DE PROCESAMIENTO

Freído, asado, despacho de bebidas, calentamiento Enseñanza Investigación Servicio Filmación, edición, efectos especiales, distribución.

SALIDA

Hamburguesas, papas (rilas, bebidas, postres Estudiantes instruidos Investigaciones Servicios a la comunidad, estado y nación Proyección de películas en salas cinematográficas.

META

Preparación rápida de alimentos de bajo costo Adquisición de conocimientos Filmes entretenidos, premios, ganancias.

EJEMPLOS DE SISTEMAS SUS METAS

En la siguiente figura se muestra un diagrama característico de sistemas, un lavado automático simple de automóviles, cuyo principal propósito es la limpieza de vehículos. El límite de un sistema define al sistema y lo distingue de todo lo demás (el entorno).

ENTRADA PROCESAMIENTO SALIDA

RETROALIMENTACIÓN

La forma en que están organizados o dispuestos los elementos del sistema se llama configuración. De modo muy similar a como ocurre con los datos, las relaciones entre los elementos de un sistema se definen por medio del conocimiento. En la mayoría de los casos, conocer el propósito o resultado que se desea obtener de un sistema es el primer paso en la definición de la manera en que se configurarán sus elementos. Por ejemplo, el resultado deseado de nuestro sistema es un auto limpio. Por experiencia sabemos que sería ilógico disponer las cosas en tal forma que el elemento del rociador de líquido precediera al elemento del cepillo espumante, pues los pasos del proceso estarían invertidos (enjuagar y luego enjabonar), con lo cual el automóvil no quedaría precisamente limpio. Tal como se deduce de este ejemplo, el conocimiento es necesario tanto para definir las relaciones entre las entradas de un sistema (el auto sucio y las instrucciones al operador) como para organizar los elementos del sistema que se utilizan para procesar las entradas (el cepillo espumante debe preceder al rociador de líquido).

TIPOS DE SISTEMAS:

Los sistemas pueden clasificarse de acuerdo con numerosas dimensiones; pueden ser simples o complejos, abiertos o cerrados, estables o dinámicos, adaptables o no adaptables, permanentes o temporales.

CLASIFICACIONES DE SISTEMAS Y SUS PRINCIPALES CARACTERISTICAS

Simple: Posee pocos componentes y cuya relación o interacción entre ellos es sencilla y directa

Complejo: Posee muchos elementos estrechamente relacionados e interconectados

Abierto: Interactúa con su entorno CERRADO No interactúa con su entorno

Estable: Sufre escasos cambios al paso del tiempo DINAMICO Sufre rápidos y constantes cambios al paso del tiempo

Adaptable: Es capaz de modificarse en respuesta a cambios en el entorno NO ADAPTABLE Es incapaz de modificarse en respuesta a cambios en el entorno

Permanente: Esta diseñado par existir durante un periodo relativamente largo TEMPORAL Esta diseñado para existir durante un periodo relativamente corto

Naturales: No interviene el ser humano HECHOS POR EL HOMBRE Son construidos, organizados y mantenidos por humanos

ENFOQUE DE SISTEMAS

El enfoque sistémico es, sobre todo, una combinación de filosofía y de metodología general, engranada a una función de planeación y diseño. El análisis de sistema se basa en la metodología interdisciplinaria que integra técnicas y conocimientos de diversos campos fundamentalmente a la hora de planificar y diseñar sistemas complejos y voluminosos que realizan funciones específicas.

Características del Enfoque de Sistemas: o Interdisciplinario o Cualitativo y Cuantitativo a la vez o Organizado o Creativo o Teórico o Empírico o Pragmático El enfoque de sistemas se centra constantemente en sus objetivos totales. Por tal razón es importante definir primeros los objetivos del sistema y examinarlos continuamente y, quizás, redefinirlos a medida que se avanza en el diseño.

UTILIDAD Y ALCANCE DEL ENFOQUE DE SISTEMAS

Podría ser aplicado en el estudio de las organizaciones, instituciones y diversos entes planteando una visión Inter, Multi y Transdisciplinaria que ayudará a analizar y desarrollar a la empresa de manera integral permitiendo identificar y comprender con mayor claridad y profundidad los problemas organizacionales, sus múltiples causas y consecuencias. Así mismo, viendo a la organización como un ente integrado, conformada por partes que se interrelacionan entre sí a través de una estructura que se desenvuelve en un entorno determinado, se estará en capacidad de poder detectar con la amplitud requerida tanto la problemática, como los procesos de cambio que de manera integral, es decir a nivel humano, de recursos y procesos, serían necesarios de implantar en la misma, para tener un crecimiento y desarrollo sostenibles y en términos viables en un tiempo determinado.

Dinámica de Sistemas:

Al hablar de dinámica de un sistema nos referimos a que las distintas variables que podemos asociar a sus partes sufren cambios a lo largo del tiempo, como consecuencia de las interacciones que se producen en ellas. Su comportamiento vendrá dado por el conjunto de trayectorias de todas las variables, que suministra algo así como una narración de lo acaecido en el sistema. Es una metodología ideada para resolver problemas concretos. Los campos de aplicación de la dinámica de sistemas son muy variados. Por ejemplo, para construir modelos de simulación informática, sistemas sociológicos, ecológicos y medioambientales. Otro campo interesante de aplicaciones es el que suministran los sistemas energéticos, en donde se ha empleado para definir estrategias de empleo de los recursos energéticos. Se ha empleado también para problemas de defensa, simulando problemas logísticos de evolución de tropas y otros problemas análogos.

Complejidad de un Sistema:

La complejidad de un sistema depende de las relaciones entre sus elementos y no como una propiedad de un elemento aislado. La complejidad de un sistema se precisa como una propiedad intrínseca de los artefactos y no toma en cuenta la percepción de un observador externo.

La complejidad de un sistema nunca disminuirá cuando las relaciones entre sus componentes aumenten. La complejidad es solo un factor a aplicar para determinar el entendimiento del sistema y puede ayudar a pronosticarlo, pero no es el único elemento que se deba usar para medir el entendimiento del sistema.

Sistemas Abiertos y Sistemas Cerrados:

Sistemas Abiertos: Es aquel que presenta intercambio con el ambiente, a través de entradas y salidas. Son adaptativos para sobrevivir. Su estructura es óptima cuando el conjunto de elementos del sistema se organiza, aproximándose a una operación adaptativa. La adaptabilidad es un continuo proceso de aprendizaje y de auto-organización.

Sistemas Cerrados: Es aquel que no tiene medio ambiente, es decir, no hay sistemas externos que lo violen, por lo mismo un sistema cerrado no es medio ambiente de ningún otro sistema. No presentan intercambio con el medio ambiente que los rodea, son herméticos a cualquier influencia ambiental. No reciben ningún recurso externo y nada producen que sea enviado hacia fuera. En rigor, no existen sistemas cerrados. Se da el nombre de sistema cerrado a aquellos sistemas cuyo comportamiento es determinístico y programado y que opera con muy pequeño intercambio de energía y materia con el ambiente. Se aplica el término a los sistemas completamente estructurados, donde los elementos y relaciones se combinan de una manera peculiar y rígida produciendo una salida invariable, como las máquinas.

Aspectos Estructurales y Funcionales de un Sistema: Como ya es muy bien conocida la definición de sistema, debemos mencionar que para que un sistema sea completamente efectivo, este debe ser estar estructurado conjuntamente a un grupo de aspectos.

Los Aspectos Estructurales comprenden:

Un Límite

Unos elementos

Unos depósitos de reservas

Una red de comunicaciones e informaciones

Los Aspectos Funcionales comprenden:

Flujos de energía

Información

Válvulas que controlan el rendimiento del sistema

Tiempos de duración de las reservas “Stokages”

Bucles de Información

Bucles de retroalimentación (positivos y negativos).

Propiedades de un sistema Descripción

Un conjunto de elementos, así como cada uno de los elementos tienen las siguientes propiedades.

Detalles

Las propiedades y comportamiento de cada elemento, y la forma en que afectan al todo, dependen de las propiedades y comportamiento al menos de otro elemento en el conjunto. En consecuencia, no hay parte alguna que tenga un efecto independiente en el todo y cada una está afectada al menos por alguna otra parte. Por ejemplo, el comportamiento del corazón y el efecto que tiene en el cuerpo dependen del comportamiento de los pulmones… Un conjunto de elementos, así como cada uno de los elementos tienen las siguientes propiedades: Las propiedades o el comportamiento de cada elemento del conjunto tienen un efecto en las propiedades o el comportamiento del conjunto tomado como un todo. Por ejemplo, cada órgano del cuerpo de un animal afecta su funcionamiento global.

Las propiedades y comportamiento de cada elemento, y la forma en que afectan al todo, dependen de las propiedades y comportamiento al menos de otro elemento en el conjunto. En consecuencia, no hay parte alguna que tenga un efecto independiente en el todo y cada una está afectada al menos por alguna otra parte. Por ejemplo, el comportamiento del corazón y el efecto que tiene en el cuerpo dependen del comportamiento de los pulmones. Cada subgrupo posible de elementos del conjunto tiene las dos primeras propiedades: cada uno tiene un efecto no independiente en el total. En consecuencia, no se puede descomponer el total en subconjuntos independientes. Por ejemplo, todos los subsistemas del cuerpo de un animal, tales como los subsistemas nervioso, respiratorio, digestivo y motor, no pueden trabajar de manera independiente, porque entonces no formarían un ser vivo, es decir, afectarían el desempeño del animal.

Jerarquía de los sistemas Al considerar los distintos tipos de sistemas del universo Kennet Boulding proporciona una clasificación útil de los sistemas donde establece los siguientes niveles jerárquicos:

1. Primer nivel, estructura estática. Se le puede llamar nivel de los marcos de referencia.

2. Segundo nivel, sistema dinámico simple. Considera movimientos necesarios y predeterminados. Se puede denominar reloj de trabajo.

3. Tercer nivel, mecanismo de control o sistema cibernético. El sistema se autor regula para mantener su equilibrio.

4. Cuarto nivel, “sistema abierto” o auto estructurado. En este nivel se comienza a diferenciar la vida. Puede de considerarse nivel de célula.

5. Quinto nivel, genético-social. Está caracterizado por las plantas.

6. Sexto nivel, sistema animal. Se caracteriza por su creciente movilidad, comportamiento teleológico y su autoconciencia.

7. Séptimo nivel, sistema humano. Es el nivel del ser individual, considerado como un sistema con conciencia y habilidad para utilizar el lenguaje y símbolos.

8. Octavo nivel, sistema social o sistema de organizaciones humanas constituye el siguiente nivel, y considera el contenido y significado de mensajes, la naturaleza y dimensiones del sistema de valores, la transcripción de imágenes en registros históricos, sutiles simbolizaciones artísticas, música, poesía y la compleja gama de emociones humanas.

9. Noveno nivel, sistemas trascendentales. Completan los niveles de clasificación: estos son los últimos y absolutos, los ineludibles y desconocidos, los cuales también presentan estructuras sistemáticas e interrelaciones.

El arte de construir estructuras tecnológicas sólidas

Las organizaciones cada vez son más conscientes de la necesidad de contar con la mejor infraestructura tecnológica para operar sus negocios de una manera eficiente y competitiva, pero también del alto costo que esto puede representar. Ante esta situación ha surgido la necesidad de crear un rol conocido como Arquitecto de Sistemas en el cual se ha delegado la responsabilidad de investigar, evaluar y seleccionar las mejores alternativas tecnológicas para atender las necesidades específicas del negocio a un costo razonable. Démosle un vistazo al origen de este rol, su analogía con los arquitectos de edificaciones, las competencias y el perfil requerido para desempeñarlo y la importancia que ha venido cobrando en las organizaciones el análisis de la arquitectura de sistemas.

Analogía del arquitecto de sistemas y el arquitecto de edificaciones

Por definición, el énfasis de la arquitectura son las edificaciones y las estructuras habitables; sin embargo, la comunidad de ingeniería del software ha adoptado los términos de “arquitectura” y “arquitecto” y ha intentado extender sus definiciones al campo de los sistemas de información. Es común para los ingenieros de software mencionar la arquitectura de las edificaciones como el modelo a seguir para la construcción de una infraestructura tecnológica. Inevitablemente, el enfoque en el análisis de la arquitectura permite comparar al ingeniero de software como una especie de arquitecto de un sistema de software. Esta analogía también permite entender que la perspectiva del observador (el usuario) es importante y que la infraestructura que se está construyendo puede tener diferentes interpretaciones dependiendo de la motivación que exista para examinarla.

Si bien, la comparación entre la arquitectura tradicional y la arquitectura de sistemas tiene su fundamento dado que en ambos casos los observadores (usuarios) están pendientes de la arquitectura de la edificación y se preocupan de que se cumplan las diferentes dimensiones (p. e. tamaño, mantenibilidad, solidez) a través del ciclo de vida del desarrollo del proyecto; en opinión de algunos autores esta analogía no es del todo precisa pues mientras los arquitectos de edificaciones vienen de diferentes escuelas y reciben diferente entrenamiento al de los ingenieros especializados en ventilación, concreto, calor o aire acondicionado; los ingenieros de software usualmente están familiarizados con una o más tecnologías (p. e. seguridad, comunicaciones, almacenamiento, sistemas operativos) utilizadas para construir un sistema y su formación les permite ser promovidos a arquitectos de sistemas al estar en capacidad de asumir en diferentes proyectos el lugar de expertos en diferentes campos de la tecnología.

Un ingeniero de software que acepte asumir el rol de arquitecto de sistemas debe poseer un talento y conocimiento especiales para llevar a cabo el diseño, construcción e implementación de una arquitectura tecnológica.

Las responsabilidades del arquitecto de sistemas podrían sintetizarse en articular la visión arquitectónica; conceptuar y experimentar con diferentes alternativas tecnológicas; crear modelos, componentes y documentos de especificación de interfaces y validar la arquitectura contra los requerimientos y presunciones del impacto de la alternativa seleccionada sobre la estrategia tecnológica de la organización.

Para cumplir con las responsabilidades señaladas el arquitecto de sistemas debe desarrollar ciertas competencias que le permitan asumir su rol de una manera exitosa. Estas competencias se pueden categorizar en los siguientes dominios: tecnología, estrategia de negocios, política organizacional, consultoría y liderazgo y son descritas a continuación.

Tecnología

El arquitecto debe tener un sólido conocimiento de la razón de ser de la organización, de su infraestructura tecnológica y del proceso de desarrollo de sistemas de información. Sin embargo, a pesar de pertenecer también al ámbito tecnológico las actividades del arquitecto de sistemas difieren de las que comúnmente realizan los desarrolladores. Más allá de tener claridad acerca los requerimientos específicos del sistema, el arquitecto debe preocuparse por las implicaciones de la selección de una solución tecnológica en los objetivos de la organización, para lo cual debe tener la visión general del sistema y construir los modelos necesarios para representar el problema y su mejor solución, explorando diferentes alternativas, preparando documentos y explicando la arquitectura a los involucrados en el proyecto.

Estrategia de negocios

El arquitecto debe poseer un alto conocimiento de la estrategia y la lógica detrás de los negocios de la organización, así como de los procesos operativos de las diferentes áreas del negocio, los ciclos de planeación y los procesos de toma de decisiones; en resumen, un buen entendimiento del contexto del negocio de la organización.

Política organizacional

Las arquitecturas comúnmente están dirigidas a atender las necesidades de varios y diversos usuarios, por lo que usualmente requieren de la participación de diferentes desarrolladores. Es decir, que serán utilizadas a través de las diferentes áreas de la organización y por diferentes equipos de desarrollo que pueden ser internos o externos. En este sentido el arquitecto necesita entender las expectativas de la organización y de los usuarios con respecto a la arquitectura seleccionada, y debe asegurar que permanezcan comprometidos durante el desarrollo del proyecto.

Consultoría

Durante la construcción de una arquitectura participan diferentes proveedores, desarrolladores y usuarios, por lo cual el papel del arquitecto como consultor es fundamental al asistir a los involucrados del proyecto, que se convierten en sus clientes, en la resolución de dudas, en la preparación de presentaciones y en la coordinación de las actividades necesarias para desarrollar el proyecto con éxito.

Liderazgo

En este sentido el arquitecto actúa como el líder que infunde al equipo una visión común del proyecto, y que lo motiva a trabajar comprometido para alcanzar los objetivos propuestos con la implementación de la arquitectura seleccionada.

Análisis de la arquitectura de sistemas

Las competencias y características propias del rol del arquitecto lo capacitan para llevar a cabo el análisis de la arquitectura de los sistemas de una organización. Esta actividad es importante por dos razones principales; en primer lugar porque la arquitectura de un sistema no puede confundirse con el sistema en sí mismo y en segundo lugar porque este análisis permite detectar tan pronto como sea posible si el sistema que se está tratando de construir es tan solo una ilusión o si en realidad se trata de un diseño factible. Sin embargo, realizar el análisis de la arquitectura del sistema no garantiza que el proyecto sea exitoso, pues aunque el análisis de factibilidad resulte favorable es posible que la implementación del sistema no sea la más adecuada. Si bien los resultados positivos obtenidos durante el análisis son una voz de aliento para seguir adelante, todos los resultados deben ser confirmados a través de mecanismos de medición o análisis más detallados durante las diferentes etapas del ciclo de vida del desarrollo del sistema.

Otro aspecto importante que debe tener en cuenta el arquitecto de sistemas al efectuar el análisis de la arquitectura de los sistemas de una organización es evaluar siempre para cada proyecto la posibilidad de reutilizar la arquitectura ya existente, pues en caso de lograrse, es posible casi de manera inmediata aplicar los esquemas de seguridad y administración establecidos para la organización así como reutilizar interfaces con datos comunes como p. e. los datos de los clientes o de los productos.

Conclusión

La complejidad de los sistemas de tecnología de información y la interrelación entre sus componentes puede ser mejor comprendida y modelada si es representada como si se tratase de una estructura arquitectónica; y como tal, es el arquitecto de sistemas quién a través del desarrollo de competencias que combinan sus conocimientos tecnológicos con habilidades gerenciales, está capacitado para asistir a la organización en la selección de la arquitectura más adecuada para responder a las necesidades reales del negocio.

EL CICLO DE VIDA DE UN SISTEMA

Consta de las siguientes actividades

1. Investigación preliminar

2. determinación de requerimientos

3. diseño del sistema

4. desarrollo del software

5. prueba de los sistemas

6. implantación y evaluación

7. documentación

8. mantenimiento

INVESTIGACIÓN PRELIMINAR

La investigación preliminar se inicia siempre con la petición de una persona, administrador empleado o especialista en sistemas.

Esta actividad comprende 3 partes:

1. Aclaración de la solicitud muchas solicitudes de empleados y usuarios no están debidamente formulados de una manera clara. Por consiguiente antes de considerar cualquier investigación la solicitud debe examinarse para determinar con precisión lo que se desea.

2. estudio de factibilidad un resultado importante de la investigación preliminar es la determinación de que el sistema solicitado sea factible. Existen 3 aspectos relacionados con dicho estudio.

a) Factibilidad técnica consiste en determinar si el proyecto puede realizarse con el equipo actual, la tecnología del software y el personal disponible o si necesita nueva tecnología que posibilidad tenemos de desarrollarla.

b) Factibilidad económica consiste en determinar si los beneficios que s obtienen serán suficientes para aceptar los costos o si los costos asociados con la decisión de no crear el sistema son tan grandes que se debe aceptar el proyecto.

c) factibilidad operacional aquí se debe determinar el sistema será utilizado o si existe cierta resistencia al cambio por parte de los usuarios que de cómo resultado una disminución de los posibles beneficios de la aplicación.

3. Aprobación de la solicitud

No todos los proyectos son deseados o factibles. Aquellos proyectos que sean deseados o factibles deben incorporarse en los planes.

En algunos casos el desarrollo puede comenzar inmediatamente, aunque lo común es que los miembros del equipo se encuentren ocupados con otros proyectos. Si es así la administración decide que proyectos son los más importantes y el orden en que se llevaran a cabo. Una vez aprobado la solicitud se estima su costo el tiempo para terminarlo y las necesidades del personal.

La empresa

Una empresa es un organismo creado para producir bienes y /o servicios, algunas tienen como finalidad producir utilidades y dividendos para los accionistas o propietarios de la misma, otras no tienen fines lucrativos.

Niveles organizacionales

La mayoría de las empresas se presentan con tres niveles

DETERMINACIÓN DE REQUERIMIENTOS DEL SISTEMA

El aspecto importante del análisis de sistemas es comprender, todas las facetas de la empresa que se encuentra bajo estudio. Se debe dar respuesta a la sig. Preguntas.

1. ¿Qué es lo que se hace?

2. ¿Cómo se hace?

3. ¿Con que frecuencia se presenta?

4. ¿Qué tan grande es el volumen de transacciones o de decisiones?

5. ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?

6. ¿Existe algún problema?

7. ¿Si existe que tan serio es?

8. Si existe un problema ¿cuál es la causa que la origina?

DISEÑO DEL SISTEMA

El diseño del sistema produce los detalles que establece la forma en que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los analistas de sistemas comienzan el proceso de diseño identificado los reportes y de mas salidas que deben producir el sistema. Este diseño también nos indica los datos de entrada aquellos que serán calculados y los que deben ser almacenados.

DESARROLLO DEL SOFTWARE

Los encargados de desarrollar el software pueden instalar (o modificar y después instalar) software comprado a terceros o escribir programas diseñados a la medida del solicitante. Los programadores también son responsables de la documentación de los programas y de proporcionar una explicación de cómo? Y ¿por qué? Se codifican en determinada forma.

PRUEBA DE LOS SISTEMAS

Durante esta fase el sistema se emplea de manera experimental para asegurarse de que el software no tenga fallas, es decir, que funcione de acuerdo con las especificaciones y en la forma en que los usuarios esperan que lo haga. En muchas organizaciones las pruebas lo realizan personas ajenas al grupo que escribió los programas originales; con esto se persigue asegurar que las pruebas sean completas e imparciales y por otra que el software sea mas confiable.

IMPLANTACIÓN Y EVALUACIÓN

La implantación es el proceso de verificar e instalar nuevo equipo, entrenar a los usuarios, instalar la aplicación y construir todos los archivos de datos necesarios para utilizarlos.

DOCUMENTACIÓN

Son las anotaciones organizadas y estructuradas de manera secuencial que describen todas las características del sistema o proyecto creado.

Existen 2 tipos de documentación :

1. manual de usuario. Donde se describe cómo va a funcionar el sistema

2. Manual técnico. Donde describe como se hizo el sistema

MANTENIMIENTO

Esta actividad consiste en realizar los cambios necesarios para mantener actualizado el sistema.

Nota: todo este proceso se debe emplear cada vez que se realice un programa

1.2.2 Arquitectura del Software

Una Arquitectura de Software, también denominada Arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan el marco de referencia necesario para guiar la construcción del software para un sistema de información.

La Arquitectura de Software establece los fundamentos para que analistas, diseñadores, programadores, etc. trabajen en una línea común que permita alcanzar los objetivos del sistema de información, cubriendo todas las necesidades.

Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.

La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación ente ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

1.3 HEURISTICAS DE DISENO

Las heurísticas de diseño son un conjunto de datos que ayudan a mejorar la estructura del sistema, optimizando la secuencia.

La generación de estas recomendaciones depende en gran medida del diseño específico, así como de las características del equipo físico donde se desarrolla la probabilidad estadística del sistema.

Introducción

En este capítulo, desarrollaremos algunas heurísticas con las cuales las estructuras de sistemas pueden mejorarse. Entenderemos por heurísticas, ciertos “trucos”, los cuales nos permitirán incrementar la modularidad del sistema. Las heurísticas no son reglas rígidas. Son útiles porque sirven como indicadores para examinar y verificar las estructuras, para potenciales mejoras.

1.3.1 Tamaño de Módulo

El tamaño del módulo está relacionado con la modularidad, más no solo de manera simple de “cortar en programa en más piezas”. Esto es, la modularidad técnica no se incrementa simplemente cuando el tamaño de módulo decrece, mientras otros aspectos permanecen igual.

Para la mayoría de los propósitos, módulos de mucho más de cien sentencias, están fuera del tamaño óptimo con respecto a la economía de detección y corrección de errores. En el otro extremo de la escala el límite es menos obvio. Excepto para ocasionales programadores “descarrilados”, que piensan que modularidad es equivalente a partir un programa en módulos de una sentencia, encontraremos que los módulos muy pequeños, han sido diseñados concisa y deliberadamente, y usualmente por razones funcionales. Sin embargo, normalmente, módulos menores a cinco a nueve líneas, deben considerarse para un replanteo. Esto es especialmente relevante cuando existen muchos de estos módulos muy pequeños en el sistema.

Sugerencias para el tamaño óptimo de un módulo han provenido de diferentes fuentes en el transcurso de los años. Una de las sugerencias conocidas es la de Baker quién recomienda que un módulo debe consistir de aproximadamente cincuenta líneas, lo que coincide con el número de líneas que se pueden poner en una hoja de listado común.

Otra recomendación proviene de Weinberg, cuyos estudios muestran que la comprensión de un programador se disipa fácilmente si el módulo tiene más de treinta líneas.

No siempre módulos muy grandes o muy pequeños son necesariamente malos. La cuestión importante es que los módulos reflejen la estructura del problema lo más fielmente posible. Descomponer un módulo simplemente para llevarlo a un tamaño óptimo, aún perdiendo su significado con respecto a la estructura del problema, no es una buena estrategia.

Debemos examinar separadamente cada caso de módulos muy grandes o muy pequeños.

Un módulo demasiado grande a menudo puede deberse a dos razones principales:

Una factorización incompleta en módulos subordinados apropiados

Dos o más funciones han sido combinadas (frecuentemente con cohesión lógica) en un mismo módulo.

En el primer caso, se puede realizar una reducción a través de la identificación y extracción de subsunciones.

En el segundo caso, podemos descomponer el módulo en sus funciones constitutivas.

En cualquier caso, los diagramas de estructura pueden usarse como herramienta, y las modificaciones estructurales deben probarse sobre papel.

Recalcamos que lo importe es dar sentido a la nueva estructura dentro del contexto del problema. Si no es posible dar una interpretación razonable a la nueva estructura, debe mantenerse la original.

Cuando tratamos con módulos muy pequeños, debemos distinguir dos casos:

El módulo atómico (nivel más bajo)

Módulo no atómico

En el caso de módulos atómicos, las cuestiones a considerar son: la cantidad de llamadas desde módulos superiores que recibe el módulo (fan-in), y la sobrecarga (overead) producido por el proceso de llamada a subrutina.

Un módulo muy pequeño puede ser comprimido en sus módulos superiores. Cuando el módulo tiene un uso simple (fan-in = 1) esta es una alternativa a considerar. Pero si el módulo tiene usos múltiples (alto fan-in) puede ser muy peligroso absorberlo en sus módulos superiores, porque se duplicará el esfuerzo de implementación y mantenimiento del mismo.

En el caso de que la sobrecarga producida por el mecanismo de llamada a subrutina sea intolerable, se puede testear y depurar el módulo independientemente y luego utilizar la inclusión en línea del módulo subordinado en sus superiores (ligado en tiempo de compilación). La mayoría de los lenguajes dan facilidades para esto como ser el COPY del Cobol, #include del C, %INCLUDE del PL/I, las macros de la mayoría de los assembler., etc., o utilizar facilidades de los preprocesadores de compilación.

Cuando el módulo es no atómico, el análisis es más complicado. Las opciones son comprimir el módulo hacia arriba en su superior, o hacia abajo en un subordinado. Ambas opciones deben ser consideradas.

Un caso especial es el llamado módulo fantasma, un módulo que lo único que contiene son llamadas a otros módulos subordinados. Obviamente estos módulos son el caso límite de módulos muy pequeños.

A través de esta discusión, se asumió que el diseñador conoce previo a la implementación el tamaño que tendrán los módulos. Normalmente esto no requiere un proceso de estimación sustancial. La experiencia ha demostrado que el tamaño comparativamente pequeño de módulos en sistemas razonablemente modulares simplifica el proceso de estimación. En adición, el proceso de estimación se torna más exacto cuando el diseñador tiene experiencia con la función que realizarán varios módulos.

1.3.2 Amplitud del Control (Fan-out)

La amplitud del control o ancho de salida (fan-out), es el número de subordinados inmediatos de un módulo. Al igual que en con el tamaño de módulo, amplitudes de control muy altas o muy bajas, son indicadores de un posible diseño pobre.

Ya se ha visto anteriormente que la función de un administrador se torna muy compleja si el número de subordinados excede 7± 2 subordinados inmediatos. En general deben verificarse anchos de salida mayores a 10 y aquellos de solamente 1 o 2. También observaremos que una amplitud de control muy alta es más peligrosa que una baja.

Una amplitud de control demasiado baja puede incrementarse en la mayoría de los casos descomponiendo el módulo en subfunciones subordinadas adicionales, o comprimiendo el módulo en sus superiores. Como se dijo en el punto anterior, esto es válido si se puede dar a los nuevos módulos un sentido dentro de la estructura del problema.

Una amplitud de control demasiado alta puede ser un indicativo de una reticencia por parte del diseñador a delegar responsabilidades en módulos subordinados. Sin embargo en la mayoría de los casos, esto proviene de estructuras “panqueque” o fallas en la definición de niveles intermedios. Para solucionar este problema, debe considerarse la posibilidad de agruparse varios subordinados en una función combinada. El principio de cohesión debe guiar este proceso para evitar módulos de baja cohesión.

1.3.3 Ancho de Entrada (Fan-In)

Siempre que sea posible, desearemos maximizar el ancho de entrada de un módulo (fan-in) durante el proceso de diseño. Cada instancia de múltiples entradas de un módulo, representa que ha podido evitarse duplicidad de código.

Sin embargo, un gran ancho de entrada no es algo que deba buscarse a cualquier costo. Por ejemplo, es ridículo combinar muchas funciones “no relacionadas” en un módulo bajamente cohesivo, con el propósito de incrementar el fan-in.

Un gran ancho de entrada es alcanzado a través de un proceso analítico que acompaña los pasos del proceso de diseño estructurado. Cada vez que vamos a dibujar un nuevo módulo en el diagrama de estructura, primero debemos verificar si no existe ya algún otro módulo que realice la función requerida. Si es así, dibujaremos una flecha hacia la caja del módulo ya existente en el diagrama, en lugar de dibujar una nueva. En orden de evitar un “enredo” de flechas en el diagrama, pueden utilizarse conectores dentro de la página (un círculo) y fuera de página (un polígono), similarmente a la que se hace en los diagramas de flujo.

Es importante notar que la especificación del fan-in es una tarea del diseñador, no del implementador (codificador).

Un problema puede producirse cuando el nuevo módulo es parecido pero no exactamente igual al módulo existente. Si el diseñador no distingue la diferencia subyacente entre ambos módulos, pueden generarse problemas durante la integración del sistema. Podrán fallar el nuevo módulo, el anterior uso del módulo existente.

La clave está en comprender cuál es la parte común de ambos módulos, y aislarlo en un nuevo módulo. Por ejemplo, supongamos que tenemos una función Q1 que parece ser similar a Q2. Si Q es la parte común de ambas funciones, podemos reestructurar nuestro diseño de la siguiente manera:

Las porciones remanentes Q1’ y Q2’ pueden reestructurarse absorbiéndolas en sus módulos superiores si fueran pequeñas. Podemos tener así una serie de alternativas diferentes.

1.3.4 Alcance de Efecto / Alcance de Control

Cada decisión o sentencia condicional (if-then-else) en un sistema tiene algunas consecuencias: ciertos procesos se realizarán o no como resultado de una decisión. Equivalentemente podemos decir que cierto procesamiento es condicional en base a la salida o resultado de una decisión. Es importante aprender donde se encuentran los resultados de una determinada decisión, dentro de una estructura modular. En orden de este estudio, introduciremos dos términos nuevos: alcance de efecto y alcance de control.

El alcance de efecto de una decisión es la colección de todos los módulos que contienen algún procesamiento que está condicionado por dicha decisión.

Aunque solo una pequeña parte del procesamiento de un módulo se vea afectada por la decisión. Si la activación de un módulo completo está condicionada por la decisión, el módulo superior (invocador) también se incluye dentro del alcance de efecto.

El alcance de control de un módulo es el módulo mismo y todos sus subordinados.

El alcance de control es un parámetro puramente estructural independiente de las funciones del módulo.

Estamos en condiciones ahora de plantear la siguiente heurística de diseño que involucra al alcance de efecto y al alcance de control:

Para una decisión dada, el alcance de efecto debe ser un subconjunto del alcance de control del módulo en el cual se encuentra la decisión.

En otras palabras, todos los módulos que son afectados o influenciados por una determinada decisión deben estar subordinados finalmente al módulo que toma la decisión. La toma de decisiones y la estructura modular se interrelacionan mejor cuando las decisiones se toman a un nivel no más alto que lo necesario dentro de estructura jerárquica, con el objetivo de ubicar el alcance de efecto dentro del alcance de control. En el caso ideal, el alcance de efecto debe estar limitado al módulo en el cual se realiza la decisión y a aquellos módulos inmediatamente subordinados al mismo.

...