Análisis de sistemas de decisiones estructurada

El análisis de decisiones se fundamenta en la lógica de las decisiones, que se llevan a cabo dentro de las organizaciones, con el fin de alcanzar un objetivo. Los métodos con que se cuenta para la documentación y el análisis de la lógica de decisiones son: el lenguaje estructurado, las tablas de decisiones y los árboles de decisiones.

Con el fin de precisar los requisitos de información necesarios para el análisis de decisiones, el analista de sistemas debe identificar los objetivos de la organización, mediante un enfoque descendente.

Las condiciones, las alternativas de las condiciones, las acciones y reglas de acción deben conocerse con el fin de diseñar sistemas para decisiones estructuradas. El analista precisa primero las condiciones. Esto es, aquellos fenómenos que pueden afectar el resultado de algo. En el siguiente paso, el analista de sistemas identifica las opciones a las condiciones específicas por quien toma las decisiones. Estas alternativas pueden ser tan simples como "si", "no", o pueden ser más descriptivas como "menos de $50", "entre $50 y $100" y "mayores de $ 100".

Luego se identifican las acciones. Esto incluye cualquier instrucción que se requiera para alcanzar el resultado de una o más de las condiciones anteriores. Todas las instrucciones para la manipulación o el cálculo de valores, la impresión de los informes, o aún el desglose de las transacciones en preguntas, serían acciones. Las acciones se unen a las condiciones por medio de las reglas de acción, las cuales son los protocolos de ejecución de las acciones requeridas.

Como ejemplo de reglas de acción tenemos en esta página un documento de primas de seguro que se proporciona a los agentes de Compañía de Seguros Fortres:

Los seguros de los dueños de inmuebles dependen, por supuesto del tipo de política y de la ubicación del inmueble, pero una vez que esto se determina existen otros factores que incrementan o disminuyen la prima del seguro. Uno de los factores es la construcción. Una casa de tabique ahorrará al dueño un 10% de la prima anual. Si se cuenta con una alarma sonora, se reducirá un 5% de la tasa y calculada. También el asegurado puede hacer elecciones que incrementarían la prima. Si el dueño desea pagar por reposición, en lugar de valor depreciado, aumenta la base un 10%. El dueño puede elegir el manejo de un deducible de $100 dólares, en lugar de un deducible de $250 dólares; esto incrementará la prima en un 15 %.

El planteamiento anterior puede en primera instancia parase claro, pero un exámen cuidadoso revelará ambigüedades que requieren de una resolución previa a la conclusión del análisis de la decisión.

El documento de primas se analiza para establecer las acciones y las condiciones. Una vez hecho lo anterior, se destacan los términos cuestionables, las ambigüedades, los calificativos poco claros, "sin embargo", "pero" y otros términos similares. Para aclarar todo ello, debería realizarse una entrevista para organizar el proceso de la decisión. Observe que las alternativas se encuentran más explícitas y las acciones son más específicas, se definen la "base", se describen y se ordenan las reglas de acción.

Diagramas de Entidad -Relación

El diagrama de entidad-relación (también conocido como DER, o diagrama E-R) es un modelo de red que describe con un alto nivel de abstracción la distribución de datos almacenados en un sistema.

¿Porque podríamos estar interesados en modelar los datos de un sistema?. Primeramente, porque las estructuras de datos y las relaciones pueden ser tan complejas que se deseará enfatizarlas y examinarlas independientemente del proceso que se llevará a cabo. De hecho, esto se da sobre todo si mostramos el modelo del sistema correspondiente a los usuarios ejecutivos quienes se preocupan más por los datos: ¿Qué dato requerimos para manejar nuestro negocio? ¿Quién lo tiene? ¿Quién tiene acceso a ellos?.

Para el analista, el DER representa un gran beneficio: porque enfatiza las relaciones entre almacenes de datos en el DFD que de otra forma se hubiera visto sólo en la especificación de procesos. Por ejemplo, un DER típico se muestra en la figura siguiente. Cada una de las cajas rectangulares corresponden a un almacén de datos en DFD y puede verse que hay relaciones que normalmente no se aprecian en un DFD.

Diagrama de entidad-relación típico.

Hay cuatro componentes principales en un diagrama de entidad-relación:

1. Tipos de objetos.
2. Relaciones.
3. Indicadores asociativos de tipo de objeto.
4. Indicadores de supertipo/subtipo.

---

Tipos de objetos

El tipo de objeto se representa en un diagrama de entidad-relación por medio de una caja rectangular; en la figura siguiente se muestra un ejemplo. Representa una colección de objetos (cosas) del mundo real cuyos miembros individuales o instancias tienen las siguientes características:

• Cada una puede identificarse de manera única por algún medio. Por ejemplo, si se tiene un tipo de objeto conocido como cliente, debemos ser capaces de distinguir uno de otro (tal vez por un número de cuenta, por su apellido, o por su número de Seguro Social).

Un tipo de objeto

Cada uno juega un papel necesario en el sistema que se construye. Es decir, para que el tipo de objeto sea legítimo, debe poder decirse que el sistema no puede operar sin tener acceso a esos miembros.

Cada uno puede describirse por uno o más datos. Es decir, un cliente puede describirse por medio de datos tales como nombre, domicilio, límite de crédito y número telefónico.

En muchos de los sistemas que desarrolle, los tipos de objetos serán la representación del sistema de algo material del mundo real. Esto significa que los clientes, artículos de inventario, empleados, partes manufacturadas, etc., son objetos típicos. El objeto es algo material del mundo real, y el tipo de objeto es su representación en el sistema. Sin embargo, un objeto pudiera ser algo no material: por ejemplo, horarios, planes, estándares, estratégias y mapas.

Una persona (o cualquier cosa material) pudiera ser diversos tipos de objetos distintos en distintos modelos de datos, o incluso en un mismo modelo. Juan Pérez, por ejemplo puede ser empleado en un modelo de datos y cliente en otro. También pudiera ser empleado y cliente dentro del mismo modelo.

---

Relaciones

Una relación representa un conjunto de conexiones entre objetos, y se representa por medio de un rombo. La figura 4.2.3 muestra una relación sencilla, que pudiera existir entre dos o más objetos.

Una relación

Cada instancia de la relación representa una asociación entre cero o más ocurrencias de un objeto y cero o más ocurrencias del otro. Así, en la figura anterior, la relación etiquetada como compras puede contener las siguientes instancias individuales:

• Instancia 1: el cliente 1 compra el artículo 1
• Instancia 2: el cliente 2 compra los artículos 2 y 3.
• Instancia 3: el cliente 3 no compra ningún artículo.

La relación representa algo que debe ser recordado por el sistema: algo que no pudo haberse calculado ni derivado mecánicamente. Así, el modelo de datos de la figura anterior indica que existe alguna razón relacionada con el usuario para recordar el hecho de que el cliente 1 compra el artículo 1, etc. Y también indica que no existe nada priori que hubiera permitido determinar que el cliente 1 compró el artículo 1 y nada más.

Notación alternativa para relaciones

El diagrama E-R son multidireccionales, esto es, puede leerse siguiendo cualquier dirección. Y no muestran cardinalidad, es decir, no muestran el número de objetos que participan en la relación.

Una notación alternativa utilizada por algunos analistas muestra tanto la cardinalidad como la ordinalidad.

---

Indicadores asociativos de tipo de objeto

El indicador asociativo de tipo de objeto representa algo que funciona como objeto y como relación. Por ejemplo, un cliente que adquiere un artículo. En donde la relación de compra no hace más que asociar un cliente con uno o más artículos. Pero suponga que existen datos que deseamos recordar acerca de cada instancia de una compra (por ejemplo a qué hora del día se hizo). ¿Dónde se podría almacenar dicha información? "Hora del día" no es un atributo de cliente, ni de artículo. Más bien, se asocia "Hora del día" con la compra misma, y esto se muestra en un diagrama como el que ilustra la figura siguiente.

Indicador asociativo de tipo objeto

Nótese que compra ahora se escribe dentro de una caja rectangular conectada por medio de líneas dirigidas, a un rombo de relación sin nombre. Esto pretende indicar que compra funciona como:

• Un tipo de objeto, algo acerca de lo cual se desea almacenar información. En este caso la hora en la cual se realizó la compra y el descuento, que se dio al cliente.
• Una relación que conecta los dos tipos de objetos cliente y artículo. Lo que significa aquí es que cliente y artículo se mantienen solo. Existirían con o sin la compra.

---

Indicadores de subtipo/supertipo

Los tipos de objetos de subtipo/supertipo consisten en tipos de objeto de una o más subcategorías, conectados por una relación. La figura 4.2.6 muestra un subtipo /supertipo típico: la categoría general es empleado y las subcategorias son empleados asalariados y empleado por horas. Nótese que los subtipos se conectan al supertipo por medio de una relación sin nombre. Note también que el supertipo se conecta con una línea que contiene una barra.

Indicador de subtipo/supertipo

Reglas para la construcción de diagramas de Entidad- Relación.

El primer DER típicamente se creará a apartir de entrevista iniciales con el usuario, y de su conocimiento de la materia en cuanto al negocio del usuario. Después de desarrollar el primer DER, el siguiente paso es asignar los datos del sistema a los diversos tipos de objetos. Se supone, que se sabe cuales son los datos. Esto puede suceder en cualquier de tres maneras:

1. Si el modelo del proceso (DFD) ya se ha desarrollado o se está desarrollando paralelamente al modelo de datos, entonces el diccionario de datos ya existirá.

2. Si el modelo del proceso no se ha desarrollado o no tiene intención de desarrollar, entonces pudiera tener que empezar por entrevistar a todos los usuarios apropiados para construir una lista exhaustiva de datos y sus definiciones.

3. Si está trabajando con un grupo de administración de datos, hay una buena probabilidad de que ya exista un diccionario de datos, que podría obtener durante el proyecto.

Existe un número de situaciones en las que los refinamientos del DER llevan a la eliminación de tipos de objetos y relaciones redundantes o erróneas. Las más comunes son:

1. Tipos de objetos que consisten en un identificador.

2. Tipos de objetos para los cuales existe una sola instancia.

3. Tipos asociativos de objetos flotantes.

4. Relaciones derivadas.

Guía para la construcción de DFD

Además de la regla básica que existen para la elaboración de DFD tal como, los componentes básicos de DFD son: proceso(burbuja) flujo, almacenes y terminadores. Existen otras reglas adicionales que nos permitirán no elaborar DFD erróneos y gratos a la vista de los usuarios.

Las reglas incluyen las siguientes:

1. Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.
2. Numerar los procesos.
3. Evitar los DFD excesivamente complejos
4. Redibujar el DFD tantas veces como sea necesario estéticamente.
5. Asegurarse de que el DFD sea lógicamente consistente y que también sea con cualesquiera DFD relacionados con él.
6. Extensiones del DFD para sistemas de tiempo real

---

1.- Escoger nombres con significado para los procesos, flujos, almacenes y terminadores.

Un proceso en un DFD puede representar una función que se está llevando a cabo, o pudiera indicar cómo se está llevando a cabo, identificando a la persona, grupo o mecanismo involucrado.

Un buen sistema que se puede utilizar para nombrar procesos es usar un verbo y un objeto. Es decir, escoja un verbo activo (un verbo transitivo que tenga objeto) y un objeto apropiado para formar una frase descriptiva para el proceso. Los siguientes son ejemplos de nombres de procesos:

• Calcular trayectoria del proyectil.
• Producir informe de inventario.
• Validar número telefónico.
• Asignar estudiante a la clase.

Los nombres de los procesos (al igual que los nombres de flujos y de terminadores) deben provenir de un vocabulario que tenga algún significado para el usuario.

---

2.- Numerar los procesos.

Como una forma conveniente de referirse a los procesos en un DFD, muchos analistas numeran cada burbuja. No importa mucho como sea haga esto, de izquierda a derecha, de arriba abajo o de cualquier otra manera servirá, mientras haya constancia en la forma de aplicar los números.

La única cosa que se debe tener en mente es que el sistema de numeración implicará, para algunos lectores casuales de su DFD, una cierta secuencia de ejecución. Esto es, cuando se muestre el DFD a un usuario, él pudiera preguntar: ¿Acaso la burbuja número 1 sucede primero, luego la 2 y luego la 3?. Y esto no es así en absoluto. El modelo de DFD es una red de procesos asincrónicos que se intercomunican, lo cual es, de hecho, una representación precisa de la manera en la que en realidad muchos sistemas operan.

Un ejemplo de la funcionalidad de enumerar las burbujas es el siguiente: Es más fácil en una discusión sobre un DFD decir " burbuja 1" en lugar de "Editar transacción y reportar errores". Pero de mayor importancia aún es el hecho de que los números se convierten en base para la numeración jerárquica.

---

3.- Evitar los DFD excesivamente complejos.

El propósito de un DFD es modelar de manera precisa las funciones que debe llevar a cabo un sistema y las interacciones entre ellas. Pero otro propósito del DFD es ser leído y comprendido, no sólo por el analista que construyó el modelo, sino por los usuarios que sean los expertos en la materia de aplicación.

Existe una regla principal para la elaboración de un DFD, que se debe tener en mente: no cree un DFD con demasiados procesos, flujos, almacenes y terminadores. En la mayoría de los casos, esto significa que no debería haber más de media docena de procesos y almacenes, flujos y terminadores relacionados en un solo diagrama.

Existe una excepción importante a esto, un diagrama especial conocido como diagrama de contexto, que representa el sistema entero como un solo proceso y destaca las interfaces entre el sistema y los terminadores externos.

---

4.- Redibujar el DFD tantas veces como sea necesario estéticamente.

En un proyecto real de análisis de sistemas el DFD debe dibujarse y volver a dibujar a menudo hasta 10 veces o más, antes de 1) ser técnicamente correcto, 2) ser aceptable para el usuario y 3) estar lo suficientemente bien dibujado como para que no sea embarazoso mostrarlo a las dirección de la organización.

¿Qué hace estéticamente agradable a un DFD?. Esto es obviamente una cuestión de gustos y puede determinarse por normas dispuestas por su organización o por las características particulares de cualquier paquete que utilice de diseño de diagramas basado en una estación de trabajo automatizada. Y la opinión de usuario pudiera ser un tanto diferente de la suya; lógicamente, cualesquiera cosas que el usuario encuentre agradable debe determinar la manera de la que se dibuje el diagrama.

---

5.- Asegurese de que el DFD sea lógicamente consistente.

Las principales reglas de consistencia son:

• Evite sumideros infinitos, burbujas que tienen entradas pero no salidas.
• Evite las burbujas de generación espontánea, que tienen salidas sin tener entradas, porque son sumamente sospechosas y generalmente incorrectas.
• Tenga cuidado con los flujos y procesos no etiquetados. Esto suele ser un indicio de falta de esmero, pero puede esconder un error aún más grave: a veces el analista no etiqueta un flujo o un proceso porque simplemente no se le ocurre algún nombre razonable.

---

6.- Extensiones del DFD para sistemas de tiempo real.

Para los sistemas de tiempo real necesitamos alguna manera de modelar flujos de control (es decir señales o interrupciones). Y se requiere una manera de mostrar procesos de control (esto es, burbujas cuya única labor es coordinar y sincronizar las actividades de otras burbujas del DFD). Se muestran gráficamente con líneas punteadas en el DFD.

Diagramas de flujo de datos

El diagrama de flujo de datos (DFD), es una herramienta que permite visualizar un sistema como una red de procesos funcionales, conectados entre sí por "conductos" y "tanques de almacenamiento" de datos. Siendo éste, una de las herramientas más comúnmente usadas, sobre todo por sistemas operacionales en los cuales las funciones del sistema son de gran importancia y son más complejos que los datos que éste maneja.

Es importante tener en mente: los DFD no sólo se pueden utilizar para modelar sistemas de sistemas de proceso de información, sino también como manera de modelar organizaciones enteras, es decir, como una herramienta para la planeación estratégica y de negocios.

Los componentes de un diagrama típico de flujo de datos:

• Proceso.
• Flujo.
• Almacén.
• Terminador.

---

Proceso.

El primer componente del DFD se conoce como proceso. Los sinónimos comunes son burbuja, función, transformación. El proceso muestra una parte del sistema que transforma entradas en salidas. El proceso se representa gráficamente como un círculo. Algunos analistas prefieren usar un óvalo o un rectángulo con esquinas redondeadas. Y otros prefieren usar un rectángulo. Las diferencias entre estas tres formas son puramente cosméticas, aunque obviamente es importante usar la misma forma de manera consistente para representar todas las funciones de un sistema.

Ejemplos de procesos.

Nótese que el proceso se nombra o describe con una sola palabra, frase u oración sencilla. Un buen nombre para un proceso generalmente consiste en una frase verbo-objeto tal como validar entradas o calcular impuesto. En algunos casos, el proceso contendrá el nombre de una persona o un grupo (por ejemplo, un departamento o una división de una organización), o de una computadora o un aparato mecánico.

---

Flujo.

Un flujo se representa gráficamente por medio de una flecha que entra o sale de un proceso; un ejemplo se muestra en la figura siguiente. El flujo se usa para describir el movimiento de bloques o paquetes de información de una parte del sistema a otra.

Ejemplo de un flujo

En la mayoría de los sistemas que modele como analista, los flujos realmente representan datos, es decir, bits, caracteres, mensajes, números de punto flotante y los diversos tipos de información con los que las computadoras pueden tratar.

Nótese que el flujo de la figura anterior tiene nombre. El nombre representa el significado del paquete que se mueve a lo largo del flujo. Un corolario de esto es que el flujo sólo lleva un tipo de paquete, como lo indica su nombre.

Los flujos muestran también la dirección: una cabeza de flecha en cualquier extremo (o posiblemente ambos) del flujo indica si los datos (o el material) se está moviendo hacia adentro o hacia fuera de un proceso (o ambas cosas). El flujo que se muestra en la primer figura siguiente por ejemplo, indica claramente que el número se está mandando hacia el proceso denominado Validar números telefónicos. Y el flujo denominado honorarios de entrega de choferes de la segunda figura siguiente claramente indica que es una salida generada por el proceso Generar honorarios de entrega de choferes. Los datos que se mueven a lo largo de dicho flujo viajarán ya sea a otro proceso (como entrada) o a un almacén o a un terminador. El flujo de dos cabezas que se muestra en la tercera figura figura es un diálogo, es decir, un empacado conveniente de dos paquetes de datos (una pregunta y una respuesta) el mismo flujo. En el caso de un diálogo, los paquetes de cada extremo de la flecha deben nombrarse, como se ilustra en la tercera figura siguiente.

Flujo de entrada.

Flujo de salida.

Flujo de diálogo.

---

Almacén.

El almacén se utiliza para modelar una colección de paquetes de datos en reposo. Se denota por dos líneas paralelas, como lo muestra la figura 4.1.5. De modo característico el nombre que se utiliza para identificar al almacén es el plural del que se utiliza para los paquetes que entran y salen del almacén por medio de flujos.

Representación gráfica de un almacén.

Para el analista con conocimiento de proceso de datos es tentador referirse a los almacenes como archivos o base de datos; pero un almacén también pudiera consistir en datos almacenados en tarjetas perforadas, microfilm, microfichas, discos ópticos, etc. y un almacén también puede ser un conjunto de fichas de papel en una caja de cartón, nombres y domicilios en un directorio, diversos archivos en un archivero, o varias formas no computarizadas.

Aparte de la forma física que toma el almacén, también existe la cuestión de su propósito: ¿Existe el sistema por causa de un requerimiento fundamental del usuario o por algún aspecto conveniente de la realización del sistema?. En el primer caso, la base de datos existe como un área de almacenamiento diferida en el tiempo, necesaria entre dos procesos que ocurren en momentos diferentes.

Los almacenes se conectan por flujos a los procesos. Así, el contexto en el que se muestra en un DFD es uno de los siguientes (o ambos):

• Un flujo desde un almacén.
• Un flujo hacía un almacén.

---

Terminador.

El terminador gráficamente se representa como un rectángulo, como se muestra en la figura 4.1.6. Los terminadores representan entidades externas con las cuales el sistema se comunica. Comúnmente, puede ser una persona, o un grupo, por ejemplo, una organización externa o una agencia gubernamental, o un grupo o departamento que esté dentro de la misma compañía u organización, pero fuera del control del sistema que se está modelando. En algunos casos, un terminador puede ser otro sistema, como algún otro sistema computacional con el cual se comunica éste.

Representación gráfica de un terminador .

Existen tres cosas importantes que debemos recordar acerca de los terminadores:

• Son externos al sistema que se está modelando.
• Es evidente que ni el analista ni el diseñador del sistema están en posibilidades de cambiar los contenidos de un terminador o la manera en que trabaja.
• Las relaciones que existan entre los terminadores no se muestran en el modelo de DFD.

Prueba

En muchos casos, el analista trabaja de manera cercana con el usuario para desarrollar un conjunto eficaz y de gran alcance de casos de prueba basados en el modelo esencial y el modelo de implantación del usuario. Este proceso puede llevarse a cabo en paralelo con las actividades de implantación del diseño y de la programación, para que, cuando los programadores terminen de escribir sus programas y de realizar sus propias pruebas locales, el equipo del analista/usuario esté listo con sus propios casos de prueba.

Existen distintas estrategias de prueba, las dos más comunes se conocen como prueba ascendente y descendente. El enfoque ascendente empieza por probar módulos individuales separadamente (prueba de módulos). Luego, los módulos individuales se combinan para forma unidades que se probaran en masas (pruebas de subsistemas). Finalmente, todos los componentes del sistema se combinan para probarse (prueba del sistema).

El enfoque de prueba descendente empieza con un esqueleto del sistema; es decir, la estrategia de prueba supone que se han desarrollado los módulos ejecutivos de alto nivel del sistema, pero que los de bajo nivel existen sólo como módulos vacíos; un ejemplo de módulo vacío es uno que no procesa nada, sino que simplemente termina luego de ser llamado.

También existen diferentes tipos de pruebas, tales como:

• Prueba funcional: Su propósito es asegurar que el sistema realiza sus funciones normales de manera correcta. Así, los casos de prueba se desarrollan y se alimentan al sistema; las salidas se examinan para ver si son correctos.

• Prueba de recuperación: El propósito de este tipo de prueba es asegurar que el sistema pueda recuperarse adecuadamente de diversos tipos de fallas, como: fallas de hardware, fallas de corriente, fallas en el sistema operativo, etc.

• Prueba de desempeño: El propósito de este tipo de prueba es asegurar que el sistema pueda manejar el volúmen de datos y transacciones de entrada especificados en el módulo de implantación del usuario, además de asegurar que tenga el tiempo de respuesta requerido.

Para poder realizar una excelente prueba se necesita de tres cosas: un plan de prueba, descripciones de pruebas y procedimiento de prueba. Un plan de prueba es un documento organizado que describe las actividades de prueba. Un documento de planeación de pruebas típico contendrá la siguiente información:

• Propósito de la prueba: cuál es el objetivo de la prueba, y qué parte del sistema se está probando.
• Localización y horario de la prueba: dónde y cuando se hará.
• Descripción de la prueba: descripción de las entradas que se proporcionarán al sistema, y las salidas y resultados que se anticipan.
• Procedimiento de prueba: descripción de cómo se deben preparar y presentar los datos de prueba al sistema; cómo capturar los resultados de salida, cómo analizar los resultados de las pruebas, y cualesquiera otros procedimientos operacionales que se deben observar.

Programación

La programación comienza cuando termina la actividad de diseño. En esta fase se involucra la escritura de instrucciones en C++, Pascal, o algún otro lenguaje de programación para implantar lo que el analista ha especificado y el diseñador ha organizado en módulos.

Como programadores se pueden enfrentar a los siguientes problemas:

• Productividad: esto es escribir más software, más rápidamente. La principal razón de esto es la enorme cantidad de sistemas y aplicaciones que siguen en espera en las grandes organizaciones.
• Eficiencia: la eficiencia es de gran importancia en muchos sistemas de tiempo real, y en sistemas que procesan grandes volúmenes de datos (ejemplo, sistemas en bancos, reservación en aerolíneas, compañías de bolsas y compañías de seguro). La meta de eficiencia usualmente entra en conflicto con otras metas discutidas: si se emplea mucho tiempo en la construcción de un sistema eficiente, es probable que sea menos mantenible y menos transportable, y que tenga más errores residuales sutiles, además de que tal vez reduzca la productividad de la persona que escribió el programa.
• Corrección: se podría argumentar que esto es lo más importante. Después de todo, si el programa no funciona correctamente, no importa que tan eficiente sea. Por ejemplo, se prefieren lenguajes de programación como Ada y Pascal si la corrección es de importancia crítica, en caso de que se estuviera construyendo sistemas de la Guerra de las Galaxias o el sistema de control para un reactor nuclear, porque son de "tipos rígidos".
• Portabilidad: en algunos ambientes esto es importante; el usuario puede desear ejecutar el mismo sistema en varios tipos distintos de computadoras. Los lenguajes de tercera generación (C, Pascal, FORTRAN, COBOL, etc.) son más portátiles que los de cuarta generación; aunque no existe un lenguaje universalmente portátil. Por ello, además del lenguaje de programación debemos preocuparnos por el estilo de programación, sí la portabilidad es un factor importante.
• Mantenibilidad: como los sistemas viven durante mucho tiempo, por lo tanto el software debe mantenerse.

Diseño de Sistemas

Como analista, puede no sentir interés por los detalles del diseño de sistemas o de programas; sin embargo, la labor de analista y la del diseñador no siempre se pueden separar debido a que, el analista debe asegurarse de entender los requerimientos del usuario, mientras que el diseñador debe asegurar que dichos requerimientos se puedan implantar de manera realista con la tecnología computacional actual.

Existe otra razón para tener interés en el diseño de sistemas: tal vez le toque hacerlo. Sobre todo en los sistemas pequeños y medianos, a menudo se espera que el mismo individuo documente los requerimientos del usuario y además desarrolle el diseño.

La actividad de diseño involucra el desarrollo de una serie de modelos. Los modelos más importantes para el diseñador son el modelo de implementación de sistemas y el modelo de implementación de programas. El modelo de implantación de sistemas se divide luego en un modelo de procesador, y uno de tareas.

En el nivel del modelo del procesador, el diseñador del sistema trata principalmente de decidir como asignar el modelo esencial a los distintos procesadores(CPU) y como deben comunicarse entre sí. Existe típicamente una variedad de opciones:

• El modelo esencial completo se le puede asignar a un solo procesador (solución de computadora principal).
• Cada burbuja de la figura 0 del DFD del modelo esencial se puede asignar a un procesador distinto (solución distribuida).
• Se pude escoger una combinación de computadoras principales, minis y micros para minimizar costos, maximizar confiabialidad o lograr algún otro objetivo.

Así como se deben asignar procesos a los componentes apropiados de hardware, los almacenes de datos se deben igualmente asignar. El diseñador debe de decidir si un almacén se realizará como base de datos en el procesador 1 o el 2. Dado que la mayor parte de los almacenes se comparten entre muchos procesos, también debe decidir si se deben asignar copias del almacén a diferentes procesadores.

En el nivel del modelo de tarea, el diseñador debe, procesador por procesador, asignar procesos y almacenes a las tareas individuales de cada uno.

Obsérvese que los procesos dentro de un mismo procesador pueden tener necesidad de comunicarse mediante alguna forma de protocolo de comunicación entre tareas. El mecanismo para hacerlo varía de un proveedor a otro, pero casi siempre se realiza através del sistema operativo del proveedor.

En el modelo de implementación de programas se llega al nivel de una tarea individual. Dentro de una tarea individual, la computadora opera de una manera no sincronizada: sólo se pueden llevar a cabo una actividad a la vez. El modelo más común de organización de la actividad en una sola unidad sincronizada es el diagrama de estructura, que muestra la organización jerárquica de módulos dentro de una tarea.