Pressman, Roger S.; Ingeniería de Software, un enfoque práctico

Tercera edición, 1993 Editorial McGraw-Hill

Segunda Parte

Análisis de Requisitos del Sistema y del Software

5          Ingeniería De Sistemas De Computadora

Hace cuatrocientos cincuenta años, Maquiavelo dijo: "...no hay nada más difícil de conseguir, más arriesgado de mantener ni más inseguro de tener éxito, que estar a la cabeza en la introducción de un nuevo orden de cosas..."

Durante el último cuarto del siglo veinte, los sistemas basados en computadora están introduciendo un nuevo orden de cosas.  Aunque la tecnología ha hecho grandes avances desde Maquiavelo, sus palabras siguen siendo ciertas.

La ingeniería del software y la ingeniería del hardware entran dentro de la amplia categoría que llamaremos ingeniería de sistemas de computadora.  Cada una de estas disciplinas representa un intento de establecer un orden en el desarrollo de sistemas basados en computadora.   Las técnicas de ingeniería para el hardware de computadoras provienen del diseño electrónico y han alcanzado un estado de relativa madurez.  Las técnicas de diseño de hardware están bien establecidas, los métodos de fabricación mejoran continuamente y la fiabilidad es más una expectativa real que una modesta esperanza.  Desafortunadamente, el software de las computadoras todavía padece la descripción maquiavélica anteriormente descrita.  En los sistemas basados en computadora, el software ha reemplazado al hardware en el sentido de ser el elemento del sistema más difícil de planificar, con menos posibilidad de éxito (en tiempo y en dinero) y más peligroso de manejar.  Mientras los sistemas basados en computadora continúan creciendo en número, complejidad y aplicaciones, la demanda de software continúa sin disminuir.

Las técnicas de ingeniería para la producción de software de computadora empiezan ahora a tener una amplia aceptación.  En el primer capítulo discutimos la evolución de una cultura del software que vio la programación de computadoras como una forma de arte.  No existía un precedente de ingeniería ni se aplicó ningún planteamiento de ingeniería.  ¡Los tiempos están cambiando!

5.1.     SISTEMAS BASADOS EN COMPUTADORA

La palabra "sistema" es posiblemente el término más sobreutilizado y del que más se ha abusado en el léxico técnico.  Hablamos de sistemas políticos y educativos, de sistemas aviónicos y de fabricación, de sistemas bancarios y de ferrocarril.  La palabra nos dice poco.   Usamos el adjetivo que la describe para comprender el contexto en el que se usa.  El diccionario Webster la describe así:

1. un conjunto u ordenación de cosas relacionadas de tal manera que forman una unidad o un todo orgánico;  2. un conjunto de hechos, principios, reglas, etc... clasificados y ordenados de tal manera que muestran un plan lógico uniendo las diferentes partes;  3. un método o plan de clasificación u ordenación;  4. una forma establecida de hacer algo; un método; un procedimiento...

El diccionario contiene cinco definiciones pero no cita ningún sinónimo.  "Sistema" es una palabra especial.

Tomando prestada la definición anterior del diccionario Webster, definimos un sistema basado en computadora como:

Un conjunto u ordenación de elementos organizados para llevar a cabo algún método, procedimiento o control mediante el procesamiento de información.

En la Figura 5.1 se muestran los elementos de un sistema basado en computadora, incluyendo los siguientes:

Software.  Los programas de computadora, las estructuras de datos y la documentación asociada, que sirven para realizar el método lógico, procedimiento o control requerido.

Figura 5.1.  Elementos del sistema.

Hardware.  Los dispositivos electrónicos (p.  ej.: UCP, memoria) que proporcionan la capacidad de computación y los dispositivos electromecánicos (p. ej.: sensores, motores, bombas) que proporcionan las funciones del mundo exterior.

Gente.  Los individuos que son usuarios y operadores del software y del hardware.

Bases de datos.  Una colección grande y organizada de información a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema.

Documentación.  Los manuales, los impresos y otra información descriptiva que explica el uso y/o la operación del sistema.

Procedimientos.  Los pasos que definen el uso específico de cada elemento del sistema o el contexto procedimiento en que reside el sistema.

Los elementos se combinan de muchas formas para transformar la información.  Por ejemplo, un robot transforma un archivo de órdenes, que contiene instrucciones concretas, en un conjunto de señales de control que producen alguna acción física concreta.

Una característica compleja de los sistemas basados en computadoras es que los elementos que componen un sistema pueden también representar un macroelemento de un sistema todavía mayor.  Un macroelemento es un sistema basado en computadora que forma parte de un sistema basado en una computadora mayor.  Como ejemplo, consideremos un sistema de automatización de una fábrica, que es, esencialmente, la jerarquía de sistemas que se muestra en la Figura 5.2.  En el nivel más bajo de la jerarquía tenemos máquinas de control numérico (CN), robots y dispositivos de entrada de datos.  Cada uno es por sí mismo un sistema basado en computadora.  Los elementos de las máquinas de CN incluyen hardware electrónico y electromecánico (p. ej.: procesador y memoria, motores, sensores); software (comunicaciones, control de las máquinas, interpolación); gente (operadores de las máquinas); una base de datos (el programa de CN almacenado); documentación y procedimientos.  Se podría aplicar una descomposición similar a los robots y a los dispositivos de entrada de datos.  Cada uno es un sistema basado en computadora.

En el siguiente nivel de la jerarquía (Figura 5.2) se define una célula de fabricación.  La célula de fabricación es un sistema basado en computadora que integra elementos propios (p. ej.: computadoras, fijaciones) y los macroelementos de máquinas de control numérico, robots y dispositivos de entrada de datos.

Resumiendo, la célula de fabricación y sus macroelementos están compuestos por elementos del sistema con las siguientes etiquetas genéricas: software, hardware, gente, base de datos, procedimientos y documentación.  En algunos casos, los macroelementos pueden compartir un elemento genérico.  Por ejemplo, el robot y la máquina de CN pueden ser manejados por un sólo operador (el elemento gente).  En otros casos los elementos genéricos son exclusivos de un sistema.

El papel del ingeniero de sistemas (o analista de sistemas) es el de definir los elementos de un sistema basado en computadora específico dentro del contexto de toda la jerarquía de sistemas (macroelementos).  En las siguientes secciones examinamos las tareas que constituyen la ingeniería de sistemas de computadora.

Figura 5.2.  Un sistema de sistemas.

5.2      INGENIERIA DE SISTEMAS DE COMPUTADORA

La ingeniería de sistemas de computadora[1] es una actividad de resolución de problemas.  Las funciones que se desean para el sistema son descubiertas, analizadas y asignadas a elementos individuales del sistema.  El ingeniero de sistemas de computadora (también llamado analista de sistemas en algunos ámbitos de información) parte de los objetivos y de las restricciones definidas por el usuario y desarrolla una representación de la función, del rendimiento, de las interfaces, de las restricciones de diseño y de la estructura de la información, todo ello pudiendo ser asociado a cada uno de los elementos genéricos del sistema descritos en la sección anterior.

La génesis de la mayoría de los nuevos sistemas comienza con un concepto más bien borroso de la función deseada.  De esa manera, el ingeniero de sistemas debe delimitar el sistema, identificando el ámbito del funcionamiento y el rendimiento deseados.  Por ejemplo, no es suficiente decir que el software de control para el robot del sistema de automatización de fabricación "ha de responder rápidamente si un compartimento de piezas está vacío".  El ingeniero de sistemas debe definir: (1) lo que supone un compartimento vacío para el robot; (2) los límites precisos de tiempo (en segundos) en los que se espera la respuesta del software; (3) qué formato debe tener la respuesta.

Una vez que la función, el rendimiento, las restricciones y las interfaces están delimitadas, el ingeniero de sistemas procede a realizar la tarea denominada asignación.  Durante la asignación, las funciones son asignadas a uno o más elementos genéricos del sistema (esto es, software, hardware, gente, etc.).  A menudo se proponen y evalúan varias asignaciones.  Para ilustrar el proceso de asignación, consideremos otro macro elemento del sistema de automatización de fabricación  el sistema de clasificación en cinta transportadora (SCCT) que se presentó en el Capítulo 3.  Al ingeniero de sistemas se le presenta el siguiente conjunto (un poco borroso) de objetivos para el SCCT:

El SCCT debe ser desarrollado de tal manera que las cajas que se mueven a lo largo de la cinta sean identificadas y clasificadas en uno de los seis compartimentos al final de la cinta.  Las cajas pasarán por una estación de clasificación donde serán identificadas.  Basándose en un número de identificación, impreso en un lado de la caja (incluyendo un código de barras equivalente), las cajas serán dirigidas a los compartimentos correspondientes.  Las cajas pasan en un orden aleatorio y espaciadas uniformemente.  La cinta se mueve despacio.

En la Figura 3.2 se muestra esquemáticamente el sistema SCCT.  Antes de continuar, hagamos una lista de preguntas que haríamos si fuésemos el ingeniero de sistemas.

Entre las muchas preguntas que se deberían plantear y responder están las siguientes:

1.    ¿Cuántos números de identificación diferentes van a ser procesados y cuál es su forma?

2.    ¿Cuál es la velocidad de la línea de transporte en metros/segundo y cuál es la distancia entre cajas en metros?

3.    ¿A qué distancia está la estación de clasificación de los compartimentos?

4.    ¿A qué distancia están los compartimentos entre sí?

5.    ¿Qué debe ocurrir si una caja no tiene el número de identificación o tiene un número incorrecto?

6.    ¿Qué ocurre cuando se llena un compartimento?

7.    ¿Hay que mandar información sobre el destino de la caja y el contenido de los compartimentos a algún otro lugar del sistema de automatización de la fábrica?  ¿Se requiere adquisición de datos en tiempo real?

8.    ¿Qué frecuencia de error/fallo es aceptable?

9.    ¿Qué partes del sistema de cinta transportadora existen actualmente y son operativas?

10.  ¿Qué restricciones de tiempo y presupuesto nos vienen impuestas?

Se puede observar que las cuestiones anteriores se centran en el funcionamiento, rendimiento, flujo de información y contenido.  El ingeniero de sistemas no pregunta al cliente cómo se va a realizar la tarea; en vez de eso, lo que pregunta es qué se necesita.

Asumiendo que las respuestas son razonables, el ingeniero de sistemas desarrolla un número de asignaciones alternativas.  Se puede observar que el funcionamiento y rendimiento están asociados a diferentes elementos genéricos del sistema en cada asignación.

Asignación 1  Se enseña a un operador a clasificar y se le sitúa en la estación de clasificación.  El o ella lee la caja y la sitúa en el compartimento adecuado.

La asignación 1 representa una solución manual (a pesar de todo efectiva) al problema del SCCT.  El elemento primario del sistema es la gente (el operador que clasifica).  La persona realiza todas las funciones de clasificación.  Puede requerirse alguna documentación (en forma de tabla que relacione el número de identificación con el compartimento adecuado y una descripción de procedimientos para el entrenamiento del operador).  Así, esta asignación utiliza sólo los elementos gente y documentación.

Asignación 2  Se colocan un lector de código de barras y un controlador en la estación de clasificación.  La salida del lector de barras pasa a un controlador programable que controla un mecanismo de separación.  El separador dirige la caja hacia el compartimento apropiado.

Para la asignación 2, se usan el hardware (lector de códigos de barras, control programable, mecanismo de separación, etc.); el software (para el lector de códigos de barras y el controlador programable) y la base de datos (una tabla donde se relaciona el identificador de las cajas con los compartimentos) para conseguir una solución de automatización total.  Cualquiera de estos elementos del sistema puede tener sus correspondientes manuales y otra documentación, añadiendo otro elemento genérico del sistema.

Asignación 3  Se colocan un lector de código de barras y un controlador en la estación de clasificación.  La salida del lector de códigos de barras pasa a un brazo de robot que coge la caja y la coloca en el compartimento apropiado.

La asignación 3 hace uso de elementos genéricos del sistema y de un macroelemento, el robot.  Al igual que la asignación 2, esta asignación utiliza hardware, software, una base de datos y documentación como elementos genéricos.  El robot es un macro elemento del SCCT y por sí mismo contiene un conjunto de elementos genéricos de sistema.

Examinando las tres asignaciones alternativas para el SCCT, debería resultar obvio que la misma función puede ser asignada a diferentes elementos del sistema.  Para elegir la asignación más efectiva, se debe aplicar un conjunto de criterios de evaluación a cada alternativa.

Los siguientes criterios de evaluación controlan la selección de una configuración del sistema basándose en una asignación específica de funcionalidad y rendimiento a elementos genéricos del sistema:

Consideraciones del proyecto.  ¿Puede ser construida la configuración dentro de los límites preestablecidos de coste y tiempo?  ¿Cuál es el riesgo asociado a las estimaciones de tiempo y coste?

Consideraciones comerciales.  ¿Representa la configuración la solución más beneficiosa?  ¿Puede ser lanzada con éxito?  ¿Compensarán los beneficios a los riesgos del desarrollo?

Análisis técnico.  ¿Existe tecnología para desarrollar todos los elementos del sistema?  ¿Están aseguradas la funcionalidad y el rendimiento?  ¿Podrá mantenerse correctamente la configuración?  ¿Existen recursos técnicos?  ¿Cuál es el riesgo asociado con la tecnología?

Evaluación de la fabricación.  ¿Hay disponibles instalaciones y equipos de fabricación?  ¿Hay escasez de los componentes necesarios?  ¿Puede llevarse a cabo adecuadamente una garantía de calidad?

Aspectos humanos.  ¿Existe personal cualificado disponible para el desarrollo y la fabricación?  ¿Existen problemas políticos?  ¿Comprende el cliente lo que va a hacer el sistema?

Interfaces con el entorno.  ¿Funciona correctamente la interfaz de la configuración propuesta con el entorno externo del sistema?  ¿Se manejan inteligentemente las comunicaciones máquina - máquina y hombre - máquina?

Consideraciones legales.  ¿Introduce esta configuración un riesgo de responsabilidad indebido?  ¿Pueden ser protegidos adecuadamente los aspectos de propiedad?  ¿Existe una infracción potencial?

Examinaremos algunos de estos aspectos con más detalle más adelante en este capítulo.

Es importante hacer notar que el ingeniero de sistemas debe considerar también soluciones estándar al problema del cliente.  ¿Existe un sistema equivalente?  ¿Pueden ser adquiridas las partes más importantes del producto a un tercero?

la aplicación de criterios de evaluación supone la selección de la configuración de un sistema específico y la especificación del funcionamiento y del rendimiento asignados al hardware, al software (y al firmware - microinstrucciones), a la gente, a las bases de datos, a la documentación y a los procedimientos.  Esencialmente, lo que se hace es asignar a cada elemento del sistema un ámbito de funcionamiento y de rendimiento.  La ingeniería del hardware, la ingeniería del software, la ingeniería humana y la ingeniería de bases de datos están para refinar el ámbito y producir un elemento del sistema capaz de funcionar que pueda ser integrado adecuadamente con otros elementos del sistema.

5.2.1.     Hardware e ingeniería del hardware

El ingeniero de sistemas de computadora selecciona alguna combinación de componentes de hardware que constituyen un elemento del sistema basado en computadora.  La selección del hardware, aunque no es una tarea sencilla, que se facilitada por una serie de características: (1) los componentes están empaquetados como bloques constitutivos individuales; (2) las interfaces entre componentes están estandarizadas; (3) están disponibles numerosas alternativas “preparadas"; (4) el rendimiento, coste y disponibilidad son relativamente fáciles de  determinar.

Una configuración del hardware evoluciona de una jerarquía de "bloques constitutivos".  Los componentes discretos (p. ej.: circuitos integrados y  componentes electrónicos tales como resistencias, condensadores, etc.) se ensamblan en una tarjeta de circuito impreso (CI) que realiza un conjunto específico de operaciones.  Las tarjetas se interconectan con un bus (un camino de información y de control) para formar componentes del sistema (p. ej.: una tarjeta de la computadora) que a su vez se integran en un subsistema de hardware o elemento del sistema.  Puesto que la integración a muy gran escala ya es común, funciones que antes estaban disponibles en un conjunto de tarjetas de circuito impreso con docenas de circuitos integrados, ahora están disponibles en un chip.

La ingeniería del hardware para computadoras digitales surgió de los precedentes establecidos en décadas de diseño electrónico.  El proceso de la ingenia del hardware puede verse en tres fases: planificación y especificación; implementación del diseño y del prototipo; fabricación, distribución y mantenimiento.  Las fases se ilustran en la Figura 5.3 a, b y c.

Una vez que se ha definido la ingeniería del sistema (análisis y definición sistema), se asignan funciones al hardware.  La primera fase de la ingeniería hardware (Figura 5.3 a) comprende la planificación del desarrollo y el análisis de los requisitos del hardware.  La planificación del desarrollo se orienta a establecer el alcance del esfuerzo en hardware.  Para esto nos hacemos las siguientes preguntas:

·      ¿Qué clase de hardware se adapta mejor a las funciones especificadas?

·      ¿Qué hardware se puede comprar? ¿cuáles son los proveedores, la disponibilidad y el coste?

·      ¿Qué tipos de interfaces se requieren?

·      ¿Qué tenemos que diseñar y construir?  ¿cuáles son los problemas potenciales y los recursos requeridos?

A partir de estas y otras cuestiones, se deben establecer los costes preliminares y los plazos de realización del sistema de hardware.  Estas estimaciones son revisadas por los responsables y el personal técnico apropiado para ser modificadas si fuese necesario.

A continuación debemos establecer una guía de acciones" para el diseño del hardware y su implementación.  El análisis de los requisitos del hardware se orienta a especificar requisitos funcionales, de rendimiento y de interfaz precisos para todos los componentes del elemento de hardware.  Además, deben establecerse las restricciones del diseño (por ejemplo, tamaño, entorno) y los criterios de prueba.  Frecuentemente se realiza una especificación del hardware.  En esta etapa hay que tomar en consideración muy especialmente las revisiones y las modificaciones.

La popular imagen de la ingeniería en "mangas de camisa" está caracterizada en la segunda fase (Figura 5.3 b).  Se analizan los requisitos y se diseña una configuración preliminar del hardware.  Las revisiones técnicas se suceden a medida que el diseño evoluciona hacia esquemas de ingeniería detallados (especificaciones de diseño).  Hoy en día, el análisis y el diseño se gestionan mediante herramientas de ingeniería asistida por computadora y diseño asistido por computadora (del inglés, CAE/CAD).  Se compran componentes ya hechos, se construyen los componentes a medida y se ensambla un prototipo.  Se prueba el prototipo para asegurar que cumple todos los requisitos.

Figura 5.3.  Ingeniería del hardware.  (a) fase I; (b) fase II; (c) fase III.

El prototipo (a veces denominado modelo de "placa de prueba" en electrónica), normalmente, se parece poco al producto final.  Por tanto, lo que se va derivando son las especificaciones para la fabricación.  Las placas de prueba se convierten en placas de PC; las (EPROM) y (PROM) se convierten en ROM; se diseñan las carcasas; se definen las herramientas y el equipamiento.  El enfoque cambia, de la funcionalidad y el rendimiento, a la facilidad de fabricación.

La tercera fase de la ingeniería del hardware requiere pocas atenciones directas por parte del ingeniero de diseño, pero pone a prueba las habilidades del ingeniero de fabricación.  Antes de que empiece la producción, se deben establecer métodos para garantizar la calidad, así como un mecanismo de distribución del producto.  En el inventario se registran los repuestos y se establece una organización de servicio in situ que se encargue del mantenimiento y de la reparación del producto.  En la Figura 5.3c se ilustra la fase de fabricación de la ingeniería del hardware.

5.2.2.     Software e ingeniería del software

Las características del software y de la ingeniería del software ya se han discutido en detalle en el Capítulo 1.  En esta sección vamos a resumir el estudio anterior dentro del contexto de la ingeniería de sistemas de computadora.

Durante la ingeniería del sistema se asigna la función y el rendimiento al software.  En algunos casos, la función es simplemente la implementación de un procedimiento secuencial de manipulación de datos.  El rendimiento no queda explícitamente definido.  En otros casos, la función es la coordinación y control internos de otros programas concurrentes y el rendimiento está definido de forma explícita en términos de tiempo de espera y de respuesta.

Para conseguir la función y el rendimiento, el ingeniero de software debe construir adquirir una serie de componentes de software.  A diferencia del hardware, los componentes de software están muy poco estandarizados[2].  En la mayoría de los casos, el ingeniero de software crea componentes a medida para satisfacer los requisitos asignados al elemento de software que se va a desarrollar.

El elemento de software de un sistema basado en computadora está compuesto por programas, datos y documentación que constituyen el software de la aplicación y el software del sistema.  El software de la aplicación implementa los procedimientos requeridos para realizar las funciones de procesamiento de la información.  El software del sistema implementa funciones de control que permiten al software de la aplicación comunicarse con otros diversos elementos de software.

Las áreas genéricas de aplicación del software ya han sido descritas en la Sección 1.2.3.  En esta sección consideramos la aplicación del software en el contexto más amplio de los sistemas basados en computadora.  Independientemente de su área de aplicación, un sistema basado en computadora puede ser representado mediante un modelo de entrada – proceso - salida (EPS).  El elemento de software juega un papel en cada aspecto del modelo.

El software se usa para adquirir información que puede ser suministrada por alguna fuente externa o por otro elemento del sistema (incluyendo macroelementos).  Cuando un sistema basado en computadora requiere una interfaz interactiva entre hombre y máquina, el software implementa la "conversación" de E/S.  En el software se implementan los mecanismos de petición y de entrada de datos; con el software se generan las pantallas y los gráficos y, mediante el software, se lleva a cabo la lógica que conduce al usuario a través de la secuencia de pasos interactivos.  Cuando se adquieren los datos desde un dispositivo, el software, en forma de controlador, acomoda las características especiales del hardware.  Por último, el software también se usa para establecer interfaces con las bases de datos, permitiendo a un programa acceder a fuentes de datos pre-existentes.

El software implementa los algoritmos de procesamiento requeridos para realizar las funciones del sistema.  En general, un algoritmo de procesamiento transforma datos de entrada y produce información o control como salida para otro elemento del sistema o macroelementos.  Hoy en día, el tipo más común de procesamiento es el procedimiento numérico o no numérico en el que todos los pasos, bucles y condiciones están predefinidos.  Sin embargo, en algunos sistemas basados en computadora se están introduciendo nuevas categorías de algoritmos de procesamiento, como el software de sistemas expertos y las redes neuronales artificiales.  A diferencia de los algoritmos convencionales, los sistemas expertos [RAE9O] utilizan hechos específicos y reglas para inferir, permitiendo al software mostrar habilidades de diagnosis parecidas a las humanas, en un ámbito de problemas limitado.  A diferencia dei software de sistemas expertos, una red neuronal artificial [WAS89] imita las funciones de las neuronas del cerebro humano y han mostrado buenas expectativas en el reconocimiento de patrones y el aprendizaje automático.

Para que un sistema basado en computadora sea de uso práctico, el software debe proporcionar información o control a otro elemento del sistema o a una fuente externa.  Para producir la información de salida, el software debe dar un formato a los datos que resulte apropiado para el medio de salida y saber cómo comunicarse con el dispositivo de salida (p. ej.: impresora, disco óptico, dispositivo de visualización de una estación de trabajo).

La ingeniería del software es una disciplina para el desarrollo de software de alta calidad para sistemas basados en computadora.  En el Capítulo 1 tratamos la ingeniería del software con detalle e identificamos cuatro paradigmas para la ingeniería del software, el ciclo de vida clásico, la creación de prototipos, el modelo en espiral y las técnicas de cuarta generación.  Cada uno es distinto de los otros, pero todos contemplan tres grandes fases.  Examinaremos estas fases en base al flujo de sucesos que se producen, de forma análoga a como lo hicimos con el proceso de ingeniería del hardware.

Las Figuras 5.4 a, b y c ilustran los pasos genéricos del proceso de ingeniería del software.  Las distintas partes de la Figura ilustran los pasos que se deben llevar a cabo y las distintas representaciones del software que se derivan según se evoluciona del concepto a la realización.

Fase de definición.  La fase de definición de la ingeniería del software, representada en la Figura 5.4a, comienza con la etapa de planificación del software.  Durante esta etapa se desarrolla una descripción bien delimitada del ámbito del esfuerzo de software; se lleva a cabo un análisis del riesgo; se definen los recursos necesarios para desarrollar el software; se establecen las estimaciones de tiempos y costes.  El propósito de la etapa de planificación del software es proporcionar una indicación preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se hayan establecido.  La gestión del proyecto realiza y revisa un plan del proyecto de software.

El siguiente paso en la fase de definición es el análisis y la definición de los requisitos del software.  En este paso se define en detalle el elemento del sistema asignado al software.  Los requisitos se analizan y se definen de una de dos maneras.  Se puede hacer un análisis formal del ámbito de información para establecer modelos del flujo y la estructura de la información.  Luego, se amplían esos modelos para convertirlos en una especificación del software.  Alternativamente, se puede construir un prototipo del software, que será evaluado por el cliente para intentar consolidar los requisitos.  Los requisitos de rendimiento y las limitaciones de recursos se traducen en características para el diseño del software.  El análisis global del elemento de software define los criterios de validación que se utilizarán para demostrar que se han podido conseguir los requisitos.

El análisis y definición de los requisitos del software es un esfuerzo conjunto llevado a cabo por el desarrollador del software y el cliente.  La especificación de requisitos del software es el documento distribuible que se produce como resultado de esta etapa.

La fase de definición culmina con una revisión técnica de la especificación de requisitos del software (o, en lugar de la especificación, del prototipo del software) realizada por el desarrollador y el cliente.  Una vez que se han definido los requisitos, se vuelve a revisar el plan del software con el fin de comprobar que sigue siendo correcto.  La información no cubierta durante el análisis de requisitos puede influir en las estimaciones hechas durante la planificación.  Los elementos distribuibles desarrollados durante la fase de definición constituyen la base de partida para la segunda fase del proceso de desarrollo de software.

Fase de desarrollo.  La fase de desarrollo (Figura 5.4b) traduce un conjunto de requisitos en el elemento operativo del sistema que llamamos software.  En las primeras etapas del desarrollo, el ingeniero de hardware no utiliza un soldador.  El ingeniero de software no pasa a utilizar un compilador.  Primero se debe realizar el diseño.

El primer paso de la fase de desarrollo se centra en el diseño.  El proceso de diseño del software comienza con una descripción del diseño arquitectónico y de datos.  Es decir, se desarrolla una estructura modular, se definen las interfaces y se establece la estructura de los datos.  Se siguen criterios de diseño que aseguren la calidad.  Se revisa el paso preliminar de diseño para garantizar la completitud y el seguimiento de los requisitos del software.  Se produce un primer borrador de la especificación del diseño[3], convirtiéndose en una parte de la configuración del software.

Figura 5.4.  Ingeniería del software – (a) Fase de definición; (b) Fase de desarrollo; (c) Fase de verificación, lanzamiento y mantenimiento.

A continuación, se consideran los aspectos procedimentales de cada componente modular del diseño del software.  Cada descripción procedimental detallada se añade a la especificación del diseño, una vez revisada.

Una vez terminado el diseño, se lleva a cabo la codificación - la generación de un programa que use un lenguaje de programación apropiado o una herramienta CASE.  La metodología de la ingeniería del software contempla la codificación como la consecuencia de un buen diseño.  En cuanto al código, se revisa su estilo y su claridad, y se comprueba que haya una correspondencia directa con la descripción detallada del diseño.  El listado en lenguaje fuente de cada componente modular constituye el documento de configuración de la etapa de codificación.

Fase de verificación, lanzamiento y mantenimiento.  Durante la última fase del proceso de ingeniería del software (Figura 5.4c), el ingeniero de software prueba el software para encontrar el mayor número posible de errores antes de que sea puesto en circulación, lo prepara para su lanzamiento y lo mantiene a lo largo de toda su vida útil.

Después de haber generado el código fuente, se lleva a cabo una serie de actividades de verificación y validación.  Las pruebas de unidad intentan verificar el rendimiento funcional de cada componente modular individual del software.  La prueba de integración constituye un medio de construcción de la arquitectura del software y de prueba de su funcionamiento y de sus interfaces.  La prueba de validación comprueba que se han conseguido todos los requisitos.  Tras cada uno de estos pasos de prueba, puede que haya de realizarse una depuración - diagnóstico y corrección de defectos.  Para los pasos de prueba, se puede desarrollar un plan y procedimiento de prueba.  Siempre se realiza una revisión de la documentación, de los casos de prueba y de los resultados de las pruebas.

Una vez terminada la prueba del software, éste está casi preparado para ser entregado a los usuarios finales.  Sin embargo, antes de la entrega se lleva a cabo una serie de actividades de garantía de calidad (GC) para asegurar que se han generado y catalogado los registros y los documentos internos adecuados, que se ha desarrollado una documentación de alta calidad para el usuario y que se han establecido los mecanismos apropiados de control de configuraciones.  Entonces, el software ya puede ser distribuido a los usuarios finales.

Tan pronto como se entregue el software a los usuarios finales, el trabajo del ingeniero del software cambia.  En ese momento, el enfoque cambia de la construcción al mantenimiento - corrección de errores, adaptación al entorno y mejora de la función.  El reconocimiento de este hecho es el primer paso hacia una disminución del impacto de una tarea que consume entre el 50 y el 70 por 100 del presupuesto de muchas grandes empresas de software.  Las tareas asociadas con el mantenimiento del software dependen del tipo de mantenimiento a realizar.  En todos los casos, la modificación del software no sólo afecta al código, sino a la configuración entera (es decir, todos los documentos, datos y programas desarrollados en las fases de planificación y desarrollo).

5.2.3.     Factores humanos e ingeniería humana

Un sistema basado en computadora casi siempre tiene un elemento humano.  Puede que una persona interactúe directamente con el hardware y con el software, manteniendo un diálogo que dirija el funcionamiento del sistema; en cualquier caso, la responsable del desarrollo y del mantenimiento del sistema es la gente.

Nuestra percepción del elemento humano de los sistemas basados en computadora ha cambiado en los últimos años.  Los primeros sistemas basados en computadora forzaban al usuario a comunicarse de una forma que fuera fácil de implementar en hardware y en software (si bien no siempre fuera fácil la comunicación en el contexto humano).  Hoy, la expresión "amigable con el usuario" tiene un nuevo significado.  La ingeniería humana para los sistemas basados en computadora es considerada como un paso importante del desarrollo de sistemas.

Cuando la gente interactúa con otra gente, un conjunto de reglas, esperas y respuestas, culturalmente definidas, permiten que la interacción se realice suavemente.  Desgraciadamente, los convenios existentes para la interacción entre personas, no están presentes cuando lo que se pretende es una interacción hombre maquina (IHM).

Antes de que el ingeniero de sistemas pueda asignar una función al elemento humano, se debe especificar la interacción que es necesaria para poder realizar la función.  Para hacerlo, se deben entender los "componentes" del elemento humano.  Entre los muchos componentes que constituyen el elemento humano se encuentran: la memoria humana y la representación del conocimiento, el pensamiento y el razonamiento, la percepción visual y la construcción del diálogo humano.

La ingeniería humana es una actividad multidisciplinaria que aplica un conocimiento derivado de la psicología para especificar y diseñar IHM de alta calidad.  El proceso de la ingeniería humana comprende los siguientes pasos:

Análisis de actividad.  Cada actividad asignada a un elemento humano se evalúa en el contexto de la interacción requerida con otros elementos.  Cada actividad se subdivide en tareas que son analizadas en etapas posteriores.

Análisis y diseño semántico.  Se define el significado preciso de cada acción requerida del usuario y de cada acción producida por la máquina.  Se establece el diseño de un "diálogo" que comunique adecuadamente la semántica.

Diseño léxico y sintáctico.  Se identifica y representa la forma específica de las acciones y las órdenes.  Después, se diseña la implementación en software y en hardware de cada acción u orden.

Diseño del entorno de usuario.  El hardware, software y otros elementos del sistema se combinan para formar un entorno de usuario.  El entorno puede incluir facilidades físicas (brillo, utilización del espacio, etc.), además de la propia IHM.

Creación de prototipos.  Es difícil, si no imposible, especificar formalmente una IHM sin usar un prototipo.  La creación de prototipos permite evaluar la IHM desde una perspectiva humana, con una participación activa en lugar de una evaluación pasiva.  La creación de prototipos supone una evaluación y una aplicación iterativa de todos los pasos de ingeniería humana anteriores.

En el Capítulo 14 se incluye un tratamiento más detallado de los factores humanos y de la ingeniería humana (aplicada al diseño de interfaces de usuario).

5.2.4.     Bases de datos e ingeniería de bases de datos

No todos los sistemas basados en computadora hacen uso de una base de datos, pero para aquellos que sí lo hacen, ese almacén de información a menudo es crucial para el funcionamiento general del sistema.  La ingeniería de bases de datos (término relativamente nuevo que comprende análisis, diseño e implementación de bases de datos) es una disciplina técnica que se aplica una vez que se ha definido el ámbito de la información.  Por ello, el papel del ingeniero de sistemas es el de definir la información que va a contener la base de datos, los tipos de peticiones que se podrán procesar, la manera en que se accederá a los datos y la capacidad de la base de datos.   Aunque la ingeniería de bases de datos es un tema que requiere un estudio en profundidad (véase [DAT86], IEEE89]), el análisis y el diseño de los datos son actividades fundamentales de la ingeniería del software, independientemente de la presencia o no de una base de datos formal.  Estos temas de la ingeniería de bases de datos, llamados colectivamente diseño de datos, se estudian en los Capítulos 8, 9 y 10.

5.3.     ANALISIS DEL SISTEMA

El análisis del sistema es una actividad que engloba la  mayoría de las tareas que hemos llamado colectivamente ingeniería de sistemas basados en computadora.  Algunas veces se incurre en confusión porque el término se usa a menudo en un contexto que alude sólo a las actividades de análisis de los requisitos del software (véanse los Capítulos 6 al 9).  Para el propósito de este estudio, el análisis del sistema se centra en todos los elementos del sistema - no sólo en el software.

El análisis del sistema se realiza teniendo presentes los siguientes objetivos: (1) identificar las necesidades del cliente; (2) evaluar la viabilidad del sistema; (3) realizar un análisis técnico y económico; (4) asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema; (5) establecer restricciones de coste y tiempo; (6) crear una definición del sistema que sea la base para todo el trabajo posterior de ingeniería.  Para alcanzar con éxito esos objetivos, se requiere experiencia, tanto en hardware como en software (así como en ingeniería humana y en bases de datos).  Aunque la mayoría de los profesionales de la industria reconocen que el tiempo y el esfuerzo gastado en el análisis de sistemas producen dividendos importantes más adelante en el proceso de desarrollo del sistema, todavía surgen tres preguntas:

·      ¿Cuánto esfuerzo se debe emplear en el análisis y en la definición de sistemas y de software?  Es difícil establecer unas directrices definitivas para determinar el esfuerzo de análisis.  El tamaño del sistema y su complejidad, el área de aplicación, el uso final y las obligaciones del contrato son sólo unas pocas de las muchas variables que afectan al esfuerzo total dedicado al análisis.  Una regla de "andar por casa" usada a menudo es que se debe dedicar entre el 10 y el 20 por 100 de todo el esfuerzo de desarrollo al análisis del sistema y aplicar otro 10 o 20 por 100 del esfuerzo de la ingeniería del software del análisis de los requisitos del software.

·   ¿Quién lo hace? Todas las tareas han de ser dirigidas por un analista bien formado y con experiencia.  El analista trabaja en contacto con el personal técnico y administrativo, tanto del cliente como del que desarrolla el sistema.  Para muchos proyectos grandes, debe crearse un equipo para cada tarea de análisis.

·   ¿Por qué es tan difícil? Se trata de una transformación de un concepto dudoso en un conjunto concreto de elementos tangibles.  Debido a que durante el análisis la comunicación es excepcionalmente densa, abundan las oportunidades de mal entendimiento, omisiones, inconsistencias y errores.  Finalmente, la percepción del sistema puede cambiar a medida que avanza la actividad, invalidando, de esta manera, el trabajo anterior.

5.3.1 Identificación de las necesidades

El primer paso del proceso de análisis del sistema implica la identificación de las necesidades.  El analista (ingeniero de sistemas) se entrevista con el cliente o su representante.  El cliente puede ser un representante de una compañía externa, del departamento de marketing de la compañía del analista (cuando se está definiendo un producto) o de otro departamento técnico (cuando se va a desarrollar un sistema interno).

La identificación de las necesidades es el punto de partida en la evolución de un sistema basado en computadora.  La Figura 5.5 muestra las entradas que se le suministran al analista como parte de este paso.  Para empezar, el analista da asistencia al cliente definiendo los objetivos del sistema (producto): la información que se va a obtener, la información que se va a suministrar, las funciones y el rendimiento requerido.  El analista se asegura de distinguir entre lo que "necesita" el cliente (elementos críticos para la realización) y lo que el cliente "quiere" (elementos deseables pero no esenciales).

Una vez que se han identificado todos los objetivos, el analista pasa a una evaluación de la información suplementaria: ¿existe la tecnología necesaria para construir el sistema?  ¿qué recursos de fabricación y de desarrollo especiales se requerirán?  ¿qué límites se han impuesto a los costes y a la agenda?  Si el nuevo sistema es un producto que va a ser desarrollado para venderlo a muchos clientes, también se hacen las siguientes preguntas: ¿cuál es el mercado potencial para el producto? ¿cómo se compara este producto con los de la competencia? ¿qué lugar ocupa este producto dentro de la línea global de la compañía?

La información recogida durante la etapa de identificación de las necesidades se especifica en un documento de conceptos del sistema.  A veces, es el cliente el que prepara un documento de conceptos inicial antes de reunirse con el analista.  Invariablemente, los resultados de la comunicación analista - cliente producen modificaciones en el documento.

5.3.2.     Estudio de viabilidad

Todos los proyectos son realizables  ¡con recursos ilimitados y un tiempo infinito!  Desafortunadamente, el desarrollo de un sistema basado en computadora se caracteriza por la escasez de recursos y la dificultad (si no imposibilidad) de cumplir los plazos de entrega.  Es necesario y prudente evaluar la viabilidad de un proyecto lo antes posible.  Se pueden evitar meses o años de esfuerzo, miles de millones de pesetas y una inversión profesional incalculable, si un sistema mal concebido es reconocido como tal al principio de la etapa de definición.

Figura 5.5.  Información requerida por el analista.

El análisis de viabilidad y el análisis del riesgo (Capítulo 4) están relacionados de varias maneras.  Si el riesgo del proyecto es grande (por cualquiera de las razones vistas en el Capítulo 4), se reduce la posibilidad de producir software de calidad.  Sin embargo, durante la ingeniería del sistema centramos nuestra atención en cuatro áreas de interés básico:

Viabilidad económica.  Una evaluación del coste de desarrollo frente al beneficio final producido por el sistema desarrollado.

Viabilidad técnica.  Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realización de un sistema aceptable.

Viabilidad legal.  Una determinación de cualquier infracción, violación o ilegalidad que pudiera resultar del desarrollo del sistema.

Alternativas.  Una evaluación de los enfoques alternativos para el desarrollo del sistema

No será necesario llevar a cabo un estudio de viabilidad para sistemas en los que la justificación económica es obvia, el riesgo técnico es bajo, se esperan pocos problemas legales y no existe una alternativa razonable.  Sin embargo, cuando no se da alguna de las anteriores condiciones, debe realizarse el estudio.

La justificación económica es normalmente la principal consideración para la mayoría de los sistemas (excepciones notables son los sistemas de defensa nacional, los sistemas impuestos por la ley y las aplicaciones de alta tecnología, como el programa espacial).  La justificación económica comprende un amplio rango de aspectos, entre los que se encuentran el análisis de coste - beneficio (tratado en la siguiente sección), las estrategias de ingresos a largo plazo, el impacto en otros productos o en centros de explotación, el coste de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado.

La viabilidad técnica es frecuentemente el área más difícil de evaluar en esta etapa del proceso de desarrollo del sistema.  Debido a que los objetivos, las funciones y el rendimiento son de alguna manera confusos, cualquier cosa puede parecer posible si se hacen las consideraciones adecuadas.  Es esencial que el proceso de análisis y de definición se realice en paralelo con el análisis de viabilidad técnica.  De esta forma, se pueden juzgar las especificaciones concretas según se van determinando.

Las consideraciones que van asociadas normalmente a la viabilidad técnica son:

Riesgo del desarrollo.  ¿Puede el elemento del sistema ser diseñado de tal forma que las funciones y el rendimiento necesarios se consigan dentro de las restricciones determinadas en el análisis?

Disponibilidad de recursos.  ¿Hay personal cualificado para desarrollar el elemento del sistema en cuestión?  ¿Están disponibles para el sistema otros recursos necesarios (de hardware y de software)?

Tecnología.  ¿Ha progresado la tecnología relevante lo suficiente como para poder soportar el sistema?

Los desarrolladores de los sistemas basados en computadora son optimistas por naturaleza.  (¿Quién más tiene el suficiente coraje para intentar hacer aquello a lo que nosotros frecuentemente nos comprometemos sin pensarlo mucho?)  Sin embargo, durante una evaluación de viabilidad técnica debería prevalecer una actitud cínica, si no pesimista.  Las equivocaciones en esta etapa pueden ser desastrosas.

La viabilidad legal comprende un amplio rango de aspectos que incluyen los contratos, la responsabilidad, las infracciones y un millar de otros detalles frecuentemente desconocidos para el personal técnico.  Un estudio de los aspectos legales del software va más allá del alcance de este libro.  El lector interesado puede acudir a Gemignani [GEM81], Harris [HAR85] o Scott [SC089].

El grado en el que se consideran las alternativas muchas veces está limitado por restricciones de tiempo y de dinero; sin embargo, no se debería descartar cualquier alternativa legítima, aunque no tenga quien "la financie".

El estudio de viabilidad puede documentarse en un informe separado de los otros documentos importantes de gestión e incluirse como apéndice en la especificación del sistema.  Aunque el formato del informe de viabilidad puede variar, el esquema de la tabla 5.1 cubre la mayoría de los aspectos importantes.

Tabla 5.1.  Esquema del estudio de viabilidad

        I.  Introducción

            A.    Declaración del problema

            B.   Entorno de implementación

            C.   Restricciones

       II.  Resumen y recomendaciones de gestión

            A.    Hallazgos importantes

            B.   Comentarios

            C.   Recomendaciones

            D.   Impacto

      III.  Alternativas

            A.    Configuraciones del sistema alternativas

            B.   Criterio utilizado en la selección del enfoque definitivo

     IV.  Descripción del sistema

            A.    Declaración resumida del ámbito

            B.   Viabilidad de los elementos asignados

      V.  Análisis de coste beneficio

     VI.  Evaluación del riesgo técnico

    VII.  Consideraciones legales

   VIII.  Otros asuntos específicos del proyecto

La revisión del estudio de viabilidad ha de llevarla a cabo primero el gestor del proyecto (para asegurar la fiabilidad de su contenido) y luego por el director administrativo (para determinar el estado del proyecto).  El estudio debe provocar una decisión de "seguir/no seguir".  Debe tenerse en cuenta que durante las etapas de planificación, especificación y desarrollo de la ingeniería del hardware y del software, se tomarán otras decisiones del tipo seguir/no seguir.

5.3.3.   Análisis económico

Entre la información más relevante que contiene el estudio de viabilidad se encuentra el análisis de coste - beneficio una evaluación de la justificación económica para un proyecto de sistema basado en computadora.  El análisis de coste beneficio señala los costes del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es, medibles directamente en pesetas) e intangibles del sistema.

El análisis de coste beneficio es complicado porque los criterios varían según las características del sistema a desarrollar, el tamaño relativo del proyecto y la recuperación esperada de la inversión como parte del plan estratégico de la compañía.  Además, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles (p. ej.: una mejor calidad del diseño mediante una optimización iterativa, una mayor satisfacción del cliente debida a un control programable y unas mejores decisiones comerciales a partir de datos de ventas con formato previamente analizados).  Puede ser difícil lograr comparaciones directas cuantitativas.

Como hemos visto anteriormente, el análisis de los beneficios diferirá dependiendo de las características del sistema.  Para ilustrar este hecho, consideremos los beneficios de los sistemas de información de gestión [KIN78] mostrados en la Tabla 5.2.  La mayoría de los sistemas de proceso de datos se desarrollan teniendo como principal objetivo una mejor cantidad, calidad, rapidez y organización de la información.  Así, los beneficios de la Tabla 5.2 se centran en el acceso a la información y su impacto en el entorno del usuario.  Los beneficios que se pueden asociar a programas de análisis científico y de ingeniería o a un producto basado en microprocesador pueden diferir substancialmente.

Los beneficios de un sistema nuevo siempre se determinan de acuerdo con el modo de trabajo ya existente.  Por ejemplo, consideremos un sistema de diseño asistido por computadora (CAD) que vaya a reemplazar a elementos del proceso manual de diseño en ingeniería.  El analista de sistemas debe definir características ponderables del sistema existente (diseño manual) y del sistema propuesto (CAD).  Seleccionando el tiempo de producción de un dibujo completo y detallado (t-dibujo) entre las muchas cantidades medibles, el analista llega a la conclusión de que el sistema CAD supondrá una reducción de 4 a 1 en ese t-dibujo.  Para cuantificar con más detalle este beneficio, determina los siguientes datos:

t-dibujo, tiempo medio de dibujo = 4 horas

d, coste por hora de dibujo = 2.000 ptas.

n, número de dibujos por año = 8.000

p, porcentaje de dibujo que se va a realizar en el sistema CAD = 60 por 100

Tabla 5.2.  Posibles beneficios del sistema de información*

Beneficios de las contribuciones a las tareas de cálculo e impresión

          Reducción del coste en cálculos e impresiones (RC)

          Mejora en la exactitud de las tareas de cálculo (RE)

          Posibilidad de cambiar rápidamente las variables y los valores en los programas de cálculo (AF)

          Gran incremento en la velocidad de los cálculos y las impresiones (AV)

Beneficios de las contribuciones a las tareas de mantenimiento de registros

          Posibilidad de recoger y guardar "automáticamente" datos de los registros (RC, AV, RE)

          Mantenimiento de registros más completo y más sistemático (RC, RE)

          Aumento de la capacidad para el mantenimiento de registros en términos de espacio y coste (RC)

          Estandarización del mantenimiento de registros (RC, AV)

          Aumento de la cantidad de datos que se pueden guardar por registro (RC, AV)

          Mejora en la seguridad en el almacenamiento de registros (RE, RC, MG)

          Mejora en la portabilidad de los registros (AF, RC, AV)

Beneficios de las contribuciones a las tareas de búsqueda de registros

          Obtención de registros más rápida (AV)

          Mejores posibilidades de acceso a registros de grandes bases de datos (AF)

          Mejores posibilidades de cambio de registros en bases de datos (AF, RC)

          Posibilidad de enlazar lugares que precisan poder efectuar búsquedas a través de telecomunicaciones (AF, AV)

          Mejores posibilidades de mantener un registro sobre los accesos a los registros y por quién (RE, MG)

          Posibilidad de auditar y analizar la actividad de búsqueda de registros (MG, RE)

Beneficios de las contribuciones a la posibilidad de reestructuración del sistema

          Posibilidad de cambiar simultáneamente clases enteras de registros (AV, AF, RC)

          Posibilidad de mover de lugar grandes archivos de datos (AV, Al)

          Posibilidad de crear nuevos archivos, mezclando partes de otros archivos (AV, AF)

Beneficios de las contribuciones a las posibilidades de análisis y de simulación

          Posibilidad de llevar a cabo rápidamente complejos cálculos simultáneos (AV, AF, RE)

          Posibilidad de crear simulaciones de fenómenos complejos con el fin de responder  a preguntas del tipo "¿qué pasa si...?" (MG, AF)

          Posibilidad de agregar grandes cantidades de datos de distintas formas que sean útiles para la planificación y la toma de decisiones (MG, AF)

Beneficios de las contribuciones al control de procesos y de recursos

          Reducción de la necesidad de trabajo forzado en el control de procesos y de recursos (RC)

          Mejores posibilidades de "afinar" procesos tales como la línea de ensamblaje (RC, MG, AV, RE)

          Mejores posibilidades de mantener una continua monitorización de los procesos y los recursos disponibles (MG, RE, AF)

*    Abreviaturas: RC= reducción o eliminación de costes; RE= reducción de errores; AF= aumento en fiabilidad;  AV= aumento en la velocidad de la actividad;  MG = mejoras en el control o en la planificación de la gestión.

     Fuente: King y Schrems [KIN78], pág. 23. Reimpreso con permiso.

Conocidos los datos anteriores, puede establecer una estimación del ahorro anual - el beneficio:

Ahorro en el coste del tiempo de dibujo = reducción x t-dibujo x n x c x p

                 = 9.600.000 ptas. por año

Otros beneficios tangibles del sistema CAD serían tratados de una manera similar.  A los beneficios intangibles (p. ej.: mejor calidad de diseño y mayor estímulo para los empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una recomendación de "seguir", si fuese oportuna.

En la Tabla 5.3 se exponen los costes asociados con el desarrollo de un sistema basado en computadora [KlN8].  El analista estima cada coste y luego utiliza los costes del desarrollo y los que surjan sobre la marcha para determinar la recuperación de la inversión, el punto de igualdad y el período de amortización.  El gráfico que muestra la Figura 5.6 ilustra estas características para el ejemplo del sistema CAD expuesto anteriormente.  Asumimos que el ahorro total por año ha sido estimado en 9.600.000 ptas., que el coste total del desarrollo se ha estimado en 20.400.000 ptas. y que los costes anuales se han estimado en 3.200.000 ptas.

Por el gráfico de la Figura 5.6 determinamos que el período de amortización es de 3,1 años.  En realidad, la recuperación de la inversión se determina con un análisis más detallado que considera el cambio del valor del dinero a lo largo del tiempo, las consecuencias de los impuestos y otros usos potenciales de la inversión.  Contabilizando los beneficios intangibles, el director administrativo decide silos resultados económicos justifican el sistema.

Figura 5.6.  Análisis de coste beneficio

Tabla 5.3.  Posibles costes del sistema de información

___________________________________________________________________

Costes de avituallamiento

            Coste de consultoría

            Coste de la compra o alquiler del equipo actual

            Coste de la instalación del equipo

          Coste del acondicionamiento del lugar destinado al equipo (aire acondicionado, seguridad, etc.)

          Coste del capital

          Coste de los gestores y el personal encargados del avituallamiento

Costes de puesta a punto

          Coste del software del sistema operativo

          Coste de la instalación del equipo de comunicaciones (líneas telefónicas, líneas de datos, etc.)

          Coste del personal dedicado a la puesta a punto

          Coste de las actividades de búsqueda y contratación de personal

          Coste de los trastornos al resto de la organización

          Coste de la gestión requerida para dirigir la actividad de puesta a punto

Costes relativos al proyecto

          Coste de la compra de software de aplicación

          Coste de modificaciones del software para ajustarse a los sistemas locales

          Coste de personal, generales, etc., del desarrollo interno de aplicaciones

          Coste de la formación del personal en el uso de las aplicaciones

          Coste de los procedimientos de recolección de datos y de recolección de datos de instalación

          Coste de la preparación de documentación

          Coste de la gestión del desarrollo

Costes continuos

          Coste del mantenimiento del sistema (hardware, software y utilidades)

          Coste de los alquileres (electricidad, teléfono, etc.)

          Coste de la depreciación del hardware

          Coste de la plantilla involucrada en las actividades de gestión, operación y planificación del sistema de información.

___________________________________________________

Fuente: King y Schrems [KIN78], pág. 24.  Reimpreso con permiso.

Otro aspecto del análisis de coste beneficio es la consideración de los costes incrementales asociados con los beneficios añadidos (mayor o mejor funcionalidad y rendimiento).  Para los sistemas basados en computadora, la relación incremental de coste - beneficio se puede representar como en la Figura 5.7.

En algunos casos (curva AA’) los costes se incrementan proporcionalmente a los beneficios hasta un determinado punto.  Después de ese punto, cada beneficio adicional es demasiado caro.  Por ejemplo, consideremos una función de sondeo en tiempo real que tiene 500 milisegundos de tiempo muerto.   Se pueden añadir nuevas tareas a un coste relativamente bajo;  sin embargo, si la ejecución total de la tarea se aproxima a los 500 milisegundos, el coste de implementación aumenta drásticamente, ya que se debe mejorar el rendimiento global.

Figura 5.7.  Incremento de la relación coste beneficio.

En otros casos (curva ABCC'), los costes aumentan proporcionalmente hasta A y después se nivelan a favor de los beneficios añadidos (hasta B), antes de aumentar drásticamente (en C) para los posteriores beneficios.  Como ejemplo, consideremos un sistema operativo monousuario que se va mejorando hasta soportar finalmente varios usuarios.  Una vez que se dispone del soporte multiusuario, la tasa de aumento del coste al añadir funciones multiusuario puede bajar un poco.  Sin embargo, una vez que se alcance la capacidad máxima del procesador, las nuevas funciones requerirán un procesador más potente, con el consiguiente gran incremento en el coste.

La siguiente cita [FRI77] caracteriza mejor el análisis de coste beneficio:

Al igual que se olvida la retórica política después de las elecciones, puede que se olvide el análisis de coste beneficio una vez que comienza la implementación del proyecto.  Sin embargo, es extremadamente importante, ya que ha sido el vehículo con el que se ha conseguido la aprobación por parte de la gestión.

Sólo gastando el tiempo necesario para evaluar la viabilidad, reducimos las oportunidades de situaciones extremadamente embarazosas (o más que embarazosas) en etapas posteriores de un proyecto de un sistema.  El esfuerzo gastado en el análisis de viabilidad que resulta en la cancelación de un proyecto propuesto no es un esfuerzo desaprovechado.

5.3.4.  Análisis técnico

Durante el análisis técnico, el analista evalúa los méritos técnicos del concepto de sistema, mientras que al mismo tiempo recoge información adicional sobre el rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de producción.  En algunos casos la etapa de análisis del sistema también incluye una cantidad limitada de investigación y de diseño.

El análisis técnico empieza con una definición de la viabilidad técnica del sistema propuesto.  ¿Qué tecnologías se requieren para conseguir la funcionalidad y el rendimiento del sistema?  ¿Qué nuevos materiales, métodos, algoritmos o procesos se requieren y cuál es el riesgo de su desarrollo?  ¿Cómo afectarán al coste estos elementos de tecnología?

Las herramientas de que se puede disponer para el análisis técnico se encuentran en las técnicas matemáticas de modelización y optimización, en la probabilidad y la estadística, en la teoría de colas y en la teoría de control - por nombrar unas cuantas[4].  Sin embargo, es importante tener en cuenta que la evaluación analítica no es siempre posible.  La modelización (bien matemática o física) es un mecanismo efectivo para el análisis técnico de sistemas basados en computadora.  La Figura 5.8 ilustra el flujo global de información del proceso de modelización.  El modelo se crea a partir de la observación del mundo real o de una aproximación basada en los objetivos del sistema.  El analista comprueba el comportamiento del modelo y lo compara con el del mundo real o con el del sistema esperado, obteniendo información de viabilidad técnica para el sistema propuesto.

Figura 5.8.  Modelización del sistema.

Blanchard y Fabrycky [BLA81, pág. 270] definen un conjunto de criterios para el uso de modelos durante el análisis técnico de sistemas:

1.   El modelo debe representar la dinámica de la configuración del sistema que está siendo evaluado, de una forma que sea suficientemente simple de comprender y manipular, y también que esté lo suficientemente cerca de la realidad operativa como para obtener resultados satisfactorios.

2.   El modelo debe realzar aquellos factores que sean más relevantes para el problema en cuestión y suprimir (con discreción) aquellos que no sean importantes.

3.   El modelo debe ser amplio, incluyendo todos los factores relevantes, y fiable en cuanto a repetición de resultados.

4.   El diseño del modelo debe ser lo suficientemente simple como para permitir una rápida implementación de la resolución del problema.  A no ser que la herramienta pueda ser utilizada de una manera rápida y eficiente por el analista o por el gestor, será de poca utilidad.  Si el modelo es grande y muy complejo, puede ser apropiado desarrollar una serie de modelos en los que la salida de uno pueda ser conectada a la entrada de otro.  También puede ser deseable evaluar un elemento específico de un sistema independientemente del resto de los elementos.

5.   El diseño del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo fácilmente y permitir la evaluación de factores adicionales si se requieren.  En un desarrollo satisfactorio del modelo, a menudo se hace una serie de intentos antes de alcanzar el objetivo final.  Los intentos iniciales pueden hacer evidentes ciertas lagunas en la información que no se hayan detectado a primera vista y, consecuentemente, sugerir cambios beneficiosos.

Los resultados del análisis técnico son la base de otra decisión del tipo "seguir / no seguir" con el sistema.  Si el riesgo técnico es alto, silos modelos indican que la funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas no encajan bien - ¡hay que volver a la mesa de trabajo!

5.3.5      Asignación y compromisos

Una vez que se ha respondido a las cuestiones relativas a la tarea de análisis, hay que considerar soluciones alternativas.  Cada función del sistema, con su rendimiento requerido y sus características de interfaz, es asignada a uno o más elementos del sistema.

Por ejemplo, el análisis de un nuevo sistema de gráficos de computadora indica que una función importante es la transformación espacial de las imágenes gráficas tridimensionales.  Una investigación de soluciones alternativas para la función de transformación revela las siguientes opciones:

1.     Todas las transformaciones tridimensionales realizadas por el software.

2.     Las transformaciones "simples" (p. ej.: cambio de escala, translación y rotación) realizadas por el hardware y las transformaciones "complejas" (p. ej.: perspectiva y sombreado) realizadas por el software.

3.     Todas las transformaciones realizadas por un procesador gráfico implementado con hardware.

El proceso general de evaluación de las configuraciones alternativas para el sistema está ilustrado en las Figuras 5.9 y 5.10 [BLA81].  De acuerdo con la Figura 5.9, se evalúa cada alternativa de configuración para el sistema de acuerdo con un conjunto de "parámetros de evaluación" (criterios de compromiso) que han sido ordenados de acuerdo con su importancia (Figura 5.10).  En general, los parámetros de evaluación están relacionados con los factores económicos (p. ej.: el coste del ciclo de vida).  Cuando dos o más parámetros de evaluación del sistema de bajo orden (p. ej.: el tiempo de respuesta o la resolución de la pantalla) pueden variar (en diferentes asignaciones), permitiendo que se siga alcanzando un parámetro deseable de alto orden (p. ej.: el coste o la fiabilidad), se aísla un área de compromiso (Figura 5.11).

5.4.     MODELIZACION DE LA ARQUITECTURA DEL SISTEMA

Una vez asignadas las funciones del sistema basado en computadora, el ingeniero de sistemas puede crear un modelo que represente las interrelaciones entre los distintos elementos del sistema y establezca una base para los posteriores pasos de análisis de requisitos y de diseño.  Ya hemos visto que cada sistema basado en computadora se puede modelar como una transformación de información mediante una arquitectura de entrada - proceso - salida.  Hatley y Pirbhai [HAT87] han ampliado este enfoque, incluyendo dos características adicionales del sistema - el procesamiento de la interfaz de usuario y el procesamiento de mantenimiento y de autocomprobación.  Aunque estas características adicionales no están presentes para todos los sistemas basados en computadora, son muy comunes y su especificación hace que cada modelo de sistema sea más robusto.

 5.4.1.    Diagramas de arquitectura

Para desarrollar el modelo del sistema se utiliza una plantilla de arquitectura [HAT87].  El ingeniero de sistemas asigna elementos del sistema a cada una de las cinco regiones de procesamiento dentro de la plantilla: (1) interfaz de usuario, (2) entrada, (3) función y control del sistema, (4) salida y (5) mantenimiento y autocomprobación.  El formato de la plantilla de arquitectura aparece en la Figura 5.12.

Como casi todas las técnicas de modelización utilizadas en la ingeniería del software y de sistemas, la plantilla de arquitectura permite al analista crear una jerarquía de detalles.  En el nivel superior de la jerarquía está el diagrama de contexto de la arquitectura (DCA).

Figura 5.9.  Evaluación de alternativas.  (Reimpreso con permiso de Prentice Hall, EngleWood Cliffs, NJ)

El diagrama de contexto establece los límites de información entre los que se está implementando el sistema y el entorno en el que va a funcionar el sistema [HAT87].  Es decir, el DCA define todos los productores de información externos utilizados por el sistema, todos los consumidores de información externos creados por el sistema y todas las entidades que se comunican a través de la interfaz o realizan mantenimiento o autocomprobación.

Figura 5.10.  Orden de los parámetros de evaluación.  (Reimpreso con permiso de Prentice Hall, Englewood Cliffs, NJ)

Figura 5.11.  Area de compromiso.

Para ilustrar el uso del DCA, consideremos una versión ampliada del sistema de clasificación de cinta transportadora visto anteriormente en este capítulo.  La versión ampliada utiliza una computadora personal (PC) como esta de clasificación.  El PC ejecuta todo el software del SCCT; está conectado al lector de códigos de barras para leer los números de serie de cada caja; está conectado al equipo de supervisión de la cinta transportadora para obtener la velocidad; guarda todos los números de serie clasificados; interactúa con un operador de la estación de clasificación produciendo una serie de informes y diagnósticos; manda señales de control al hardware encargado de la maniobra para clasificar las cajas y se comunica con la computadora central de la fábrica de automatización.  En la Figura 5.13 se muestra el DCA para la versión ampliada del SCCT.

Figura 5.12.  Plantilla de arquitectura.

Cada cuadro de la Figura 5.13 representa una entidad externa - es decir, un productor o un consumidor de información del sistema.  Por ejemplo, el lector de códigos de barras produce información que entra en el sistema SCCT.  El símbolo que representa el sistema completo (o, a niveles más bajos, los subsistemas principales) es un rectángulo con esquinas redondeadas.  Aquí, el SCCT está representado en la región de proceso y control, en el centro del DCA.  Las flechas etiquetadas del DCA representan la información (de datos y de control) que se fluye entre el entorno externo y el sistema SCCT.  La entidad externa lector de códigos de barras produce información de entrada que está etiquetada como código de barras.  En esencia, el DCA ubica el sistema en el contexto de su entorno externo.

El ingeniero de sistemas refina el diagrama de contexto de la arquitectura considerando con más detalle el rectángulo sombreado de la Figura 5.13.  Identifica los subsistemas principales que permiten el funcionamiento del sistema de clasificación de cinta transportadora en el contexto definido por el DCA.  De acuerdo con la Figura 5.14, se definen los subsistemas principales[5] en un diagrama de flujo de la arquitectura (DFA), que se obtiene a partir del DCA.  Como guía para el desarrollo del DFA un "esquema" más detallado del SCCT, el ingeniero de software utiliza la información que fluye a través de las regiones de DCA.  El diagrama de flujo de la arquitectura muestra los subsistemas principales y las líneas importantes de flujo de información (control y datos).  Además, la plantilla de la arquitectura clasifica el procesamiento de los subsistemas en una de las cinco regiones de procesamiento vistas anteriormente.  En esta etapa, cada uno de los subsistemas pueden contener uno o más elementos del sistema (p. ej.: hardware, software, gente) según hayan sido asignados por el ingeniero de sistemas.

Figura 5.13.  Diagrama de contexto de la arquitectura del sistema SCCT (ampliado).

Figura 5.14.  Diagrama de flujo de la arquitectura para el SCCT (ampliado).

El diagrama inicial de flujo de la arquitectura se constituye en el nodo raíz de la jerarquía de DFAs.  Se puede ampliar cada rectángulo redondeado del DFA inicial en otra plantilla de arquitectura dedicada exclusivamente a él.  Este proceso se ilustra esquemáticamente en la Figura 5.15.  Cada uno de los DFAs del sistema se puede utilizar como punto de partida para los posteriores pasos de ingeniería del subsistema que describe.

Figura 5.15.   Construcción de una jerarquía de DFAs.

5.4.2.     Especificación de la arquitectura del sistema

Se pueden especificar (limitar) los subsistemas y la información que fluye entre ellos para que esté disponible en los posteriores trabajos de ingeniería.  La especificación del diagrama de arquitectura[6] (EDA) presenta la información sobre cada subsistema y el flujo de información entre los subsistemas.  La EDA contiene una descripción - denominada narrativa de módulo del sistema - de cada subsistema.  La narrativa de módulo del sistema describe qué hace el subsistema, qué información procesa y cómo está relacionado con otros subsistemas.  Además de las narrativas, la EDA puede contener un diccionario de arquitectura - una lista con los elementos de información que aparecen en el DFA y sus descripciones.  Por ejemplo el elemento de información número de serie de la Figura 5.14 podría describirse tal como muestra la Figura 5.16.

Como se puede ver en la figura, se utiliza una notación especial para representar la descripción del elemento de información.  La notación (que se describe en el Capítulo 7) indica qué número de serie es un elemento de datos compuesto - es decir, un elemento de datos que está compuesto por otros tres elementos de datos: prefijo de tipo de producto, identificador numérico y categoría de coste.  En realidad, en el diccionario también estará definido cada uno de esos tres elementos.  Los datos sobre el tipo, el origen y el destino se obtienen directamente del DFA (Figura 5.14) y el camino de comunicación indica la manera en que se transfiere físicamente la información desde el origen y el destino.  En otras circunstancias, el camino de comunicación puede estar definido como un bus o un canal que tendrá que ser implementado como parte del diseño del sistema.  El diccionario de la arquitectura es una versión a nivel de sistema del diccionario de requisitos - una importante notación de análisis del software que se trata en detalle en el Capítulo 7.

El último elemento de la especificación del diagrama de arquitectura es el diagrama de interconexión de la arquitectura (DIA) y la correspondiente descripción de la interconexión.  Las flechas del DFA indican el flujo del control y de los datos, sin describir cómo se efectúa ese flujo de información.  El DIA y la especificación correspondiente, describen cómo se transfiere la información - electrónicamente (p. ej.: por un bus), ópticamente (p. ej.: por un enlace óptico de tal ancho de banda) o mecánicamente (p. ej.: mediante un actuador o una articulación mecánica).  Para desarrollar el DIA, el ingeniero de sistemas tiene que tomar decisiones de implementación que es mejor dejarlas para la etapa de diseño.  Por esta razón, posponemos el estudio de los aspectos de interconexión hasta el Capítulo 15.

Figura 5.16.  Una entrada del diccionario de la arquitectura.

5.5.     SIMULACION Y MODELIZACION DEL SISTEMA

Hace dos décadas, R. M. Graham [GRA69] hizo un comentario angustioso sobre la forma de construir sistemas basados en computadora: "Construimos los sistemas igual que los hermanos Wright construyeron sus aviones - construyendo todo de una vez, soltándolo desde un acantilado, dejando que se estrelle y comenzando de nuevo".  De hecho, actualmente seguimos haciéndolo así con al menos un tipo de sistema - el sistema reactivo.

Muchos sistemas basados en computadora interactúan con el mundo real de una forma reactiva.  Es decir, el sistema basado en computadora supervisa los sucesos del mundo real mediante el hardware y el software y, basándose en esos sucesos, el sistema impone un control sobre las máquinas, los procesos e incluso la gente que hace que se produzcan los sucesos.  Los sistemas de tiempo real y los sistemas empotrados muchas veces se encuentran en la categoría de los temas reactivos.

Desgraciadamente, los desarrolladores de sistemas reactivos a veces tienen que luchar para conseguir que funcionen correctamente.  Hasta hace poco, era difícil predecir el rendimiento, la eficiencia y el comportamiento de dichos sistemas antes de construirlos.  En cierto sentido, la construcción de sistemas de tiempo real era muchas veces como una aventura "de vuelo".  No se encontraban sorpresas (la mayoría desagradables) hasta que no se construía el sistema y se "soltaba desde un acantilado".  Si el sistema fallaba debido a una función incorrecta, a un comportamiento inapropiado o a un rendimiento pobre, se recogían las piezas y se empezaba de nuevo.

Muchos sistemas de la categoría de los reactivos controlan máquinas y/o procesos (p. ej.: refinerías de petróleo o líneas aéreas comerciales) que han de funcionar con un grado de fiabilidad extremadamente alto.  Si el sistema falla, pueden producirse pérdidas humanas o económicas importantes.  Por esta razón, el panorama descrito por Graham es lamentable y peligroso.

Hoy en día, se usan herramientas CASE para la modelización y la simulación, con el fin de eliminar sorpresas en la construcción de sistemas reactivos basados en computadora.  Estas herramientas se aplican durante el proceso de ingeniería del software, durante la especificación de los papeles del hardware, del software, de las bases de datos y de la gente.  El papel de la herramienta de modelización y de simulación de sistemas ha sido resumido por i-Logix, Inc., un vendedor de herramientas de ingeniería del sistema [ILO90]:

En un proyecto, cuando más frecuentemente nos centramos en el entendimiento del comportamiento de un sistema en su entorno, es durante las fases de diseño, de implementación y de prueba, mediante un proceso iterativo de prueba y error.  El método Statemate [una herramienta de modelización y simulación] es una alternativa para este costoso proceso.  Permite construir un modelo completo que... se centra en los aspectos funcionales y de flujo de datos usuales, pero cubriendo también los aspectos de la dinámica y del comportamiento del sistema.  Luego, se puede probar el modelo con... herramientas que proporcionan varios mecanismos para inspeccionar y depurar la especificación y para recuperar la información que contiene.  Mediante la prueba del modelo de especificación, el ingeniero de sistemas puede ver cómo se comportará el sistema especificado una vez que se implemente.  Se pueden plantear preguntas del tipo "¿qué pasa si...?"  seguir guiones específicos, comprobar que se van a producir determinadas situaciones deseables... y que otras no deseables no se encontrarán.  En este sentido, se puede decir que el ingeniero de sistemas juega el papel de usuario eventual del sistema y de su entorno...

Las herramientas de modelización y simulación permiten al ingeniero de sistemas "conducir la prueba" de una especificación del sistema.  Los detalles técnicos y las técnicas especializadas de modelización que se utilizan para conducir la prueba se presentan en el Capítulo 15.

5.6.     LA ESPECIFICACION DEL SISTEMA

La especificación del sistema es un documento que sirve como base para la ingeniería del hardware, la ingeniería del software, la ingeniería de bases de datos y la ingeniería humana.  Describe la función y el rendimiento de un sistema balado en computadora y las restricciones que gobernarán su desarrollo.  La especificación limita cada uno de los elementos del sistema asignados.  Por ejemplo, proporciona al ingeniero de software una indicación del papel del software dentro del contexto del sistema como un todo y dentro de los subsistemas descritos en los diagramas de flujo de la arquitectura.  La especificación del sistema también describe la información (control y datos) que sirve de entrada y de salida al sistema.

La tabla 5.4 muestra un esquema recomendado para la especificación del sistema.  Sin embargo, téngase en cuenta que se trata sólo de uno de los muchos esquemas que se pueden seguir para definir un documento de descripción del sistema.  El contenido o el formato actual puede venir impuesto por algún estándar de la ingeniería del software o de la ingeniería de sistemas (p. ej.: DoD/STD 2167A) o por las preferencias y gustos particulares.

5.7.     REVISION DE LA ESPECIFICACION DEL SISTEMA

Durante la ingeniería del sistema hay una tendencia natural a pasar por alto la revisión e ir rápidamente al desarrollo.  Los gestores tienden a ponerse cada vez más nerviosos cuando lo que se hace no es soldar componentes ni escribir código.  El personal técnico quiere pasar a las "tareas creativas de la ingeniería" tan pronto como sea posible.  ¡No se debe ceder ante estas actitudes!

La revisión de la especificación del sistema evalúa la corrección de la definición contenida en la especificación del sistema.  La revisión ha de ser realizada por el técnico y por el cliente, para asegurar que (1) se ha perfilado adecuadamente el ámbito del proyecto; (2) se ha definido correctamente la funcionalidad, el rendimiento y las interfaces; (3) el análisis del entorno y del riesgo del desarrollo justifican el sistema y (4) el desarrollador y el cliente tienen la misma percepción de los objetivos del sistema.  La revisión de la especificación del sistema se realiza en dos partes.  Inicialmente se aplica un punto de vista de gestión.  Después se realiza una evaluación técnica de los elementos y funciones del sistema.

Tabla 5.4.  Esquema de la especificación del sistema

        I.     Introducción

              A.   Ambito y propósito del documento

              B.   Visión general

                     1.           Objetivos

                     2.           Restricciones

       II.     Descripción funcional y de datos

              A.   Arquitectura del sistema

                     1.           Diagrama de contexto de la arquitectura

                     2.           Descripción del DCA

      III.     Descripción de los subsistemas

              A.   Especificación del diagrama de arquitectura para el subsistema n

                     1.           Diagrama de flujo de la arquitectura

                     2.           Narrativa de módulo del sistema

                     3.           Aspecto de rendimiento

                     4.           Restricciones de diseño

                     5.           Asignación de componentes del sistema

              B.   Diccionario de la arquitectura

              C.   Diagramas y descripción de la interconexión de la arquitectura

     IV.     Resultados de la modelización y la simulación del sistema

              A.   Modelo del sistema utilizado para la simulación

              B.   Resultados de la simulación

              C.   Aspectos especiales del rendimiento

      V.     Aspectos del proyecto

              A.   Costes de desarrollo proyectados

              B.   Agenda proyectada

     VI.     Apéndices

Las consideraciones claves de la gestión generan las siguientes cuestiones:

·   ¿Se ha establecido una necesidad comercial en firme?  ¿Tiene sentido la justificación del sistema?

·   ¿Necesita el entorno especificado (o el mercado) el sistema descrito?

·   ¿Qué alternativas has se han considerado?

·   ¿Cuál es el riesgo de desarrollo de cada elemento del sistema?

·   ¿Están disponible los recursos necesarios para el desarrollo?

·   ¿Tienen sentido las restricciones de coste y de agenda?

Realmente, se debe haber planteado y respondido a estas cuestiones regularmente durante la tarea de análisis.  En este momento, lo que hacemos es volver a examinarlas.

El nivel de detalle considerado durante la etapa técnica de la revisión del sistema varía de acuerdo con el nivel de detalle considerado durante la tarea de asignación.  La revisión debe cubrir los siguientes aspectos:

·   ¿Se corresponde la complejidad funcional del sistema con el riesgo de desarrollo, el coste y la agenda?

·   ¿Está definida la asignación de funciones con suficiente detalle?

·   ¿Se han definido con suficiente detalle las interfaces entre los elementos del sistema y el entorno?

·   ¿Se han planteado los aspectos de rendimiento, fiabilidad y facilidad de mantenimiento en la especificación?

·   ¿Proporciona la especificación del sistema una base suficiente para los siguientes pasos de ingeniería del software y del hardware?

Una vez que ha terminado la revisión del sistema, comienzan los caminos paralelos de ingeniería.  Los elementos de hardware, humanos y de base de datos de un sistema se consideran dentro de sus correspondientes procesos de ingeniería.  En el resto de este libro, seguiremos el camino de la ingeniería del software.

5.8.     RESUMEN

La ingeniería de sistemas de computadora es el primer paso en la evolución de un producto o sistema basado en computadora nuevo.  Mediante los pasos que hemos denominado colectivamente análisis del sistema, el ingeniero de sistemas identifica las necesidades del usuario, determina la viabilidad técnica y económica, y asigna las funciones y el rendimiento al software, al hardware, a la gente y a las bases de datos  los elementos clave del sistema.  Se crea un modelo arquitectónico del sistema y se desarrolla una representación de cada uno de los principales subsistemas.  Por último, la ingeniería de sistemas puede utilizar herramientas CASE para crear un modelo reactivo del sistema que se pueda utilizar como base para la simulación del funcionamiento y del comportamiento.  La tarea de ingeniería de sistemas culmina con la creación de la especificación del sistema un documento que es la base de todo el trabajo de ingeniería que viene a continuación.

La ingeniería de sistemas requiere una comunicación intensa entre el cliente y el analista.  El cliente debe comprender los objetivos del sistema y ser capaz de exponerlos claramente.  El analista debe saber qué preguntas hacer, qué consejos dar y qué investigación realizar.  Si la comunicación se rompe en esta fase, el éxito del proyecto entero estará en peligro.

REFERENCIAS

[ALL89]     Allman, W.  F., Apprentices of Wonder, Bantam, 1989.

[BLA81]     Blanchard, B. S., and W. J. Fabrycky, Systems Engineering and Analysis, Prentice Hall, 1981.

[DAT86]     Date, C.  J., An Introduction to Data Base Systems, 4th ed., Addison Wesley, 1986.

[FRI77]      Fried, L., "Performing Cost Benefit Analysis", Systems Development Management, Auerbarch Publishers, 1977

[GEM81]    Gemignani, M., Law and the Computer, CBI Publishing Co., 1981.

[GRA69]    Graham, R. M., in Proceedings 1969 NATO Conference on Software Engineering, 1969.

[HAR85]    Harris, T. D., Computer Software Protection, Prentice Halí, 1985.

[HAT87]     Hatley, D. J., and I. A. Pirbhai, Strategies for Real Time Systems Specification, Dorset House, 1987.

[IEE89]      Database Engineering, Vol. 7, IEEE Computer Society Press, 1989.

[ILO90]      The Statemate Approach to Complex Systems, i-Logix, Inc., 1990.

[KIN78]      King, J., and E. Schrems, "Cost Benefit analysis in Information Systems Development and Operation", ACM Computing Surveys, vol. 10, no. 1, March 1978, pp. 19-34.

[RAE9O]   Raeth, P. G., Expert Systems: A Software Methodology for Modern Applications, IEEE Computer Society Press, 1990.

[SC089]     Scott, M.  D., Computer Law, Wiley, 1989.

[WAS89]   Wasserman, P.  D., Neural Computing: Theory and Practice, Van Nostrand Reinhold, 1989.

PROBLEMAS Y PUNTOS A CONSIDERAR

5.1.   Encuentre tantos sinónimos como pueda de la palabra sistema.  ¡Suerte!

5.2.   Construya un "sistema de sistemas" similar al de la Figura 5.2, para un sistema grande (diferente al del ejemplo).  La jerarquía debe llegar hasta los elementos más sencillos del sistema (hardware, software, etc.), al menos por una rama del "árbol".

5.3.   Intente dibujar el equivalente de la Figura 5.1 para un sistema (preferiblemente basado en computadora) con el que esté familiarizado.  Muestre las entradas y las salidas principales, cada elemento del sistema y la interconectividad entre los elementos.

5.4.   Un analista de sistemas puede ser: el que desarrolla el sistema, el cliente o alguien de una organización externa.  Discuta los pros y los contras de cada uno.  Describa al analista "ideal".

5.5.   Los elementos comunes a todos los sistemas son el hardware, el software y la gente.  ¿Qué otros elementos se encuentran frecuentemente en los sistemas basados en computadora?

5.6.   Añada al menos cinco cuestiones más a la lista desarrollada para el sistema SCCT en la Sección 5.2.  Aborde el problema con dos asignaciones adicionales para el SCCT.

5.7.   Su profesor le proporcionará una descripción de alto nivel de un sistema basado en computadora.

(a)   Desarrolle un conjunto de preguntas que pudiera proponer un analista.

(b)   Proponga por lo menos dos conjuntos diferentes de asignaciones para el sistema, de acuerdo con las respuestas del profesor a las preguntas planteadas.

(c)   En clase, compare sus asignaciones con las realizadas por otros compañeros.

5.8.   Intente desarrollar una clasificación jerárquica para el hardware de computadoras.  Identifique cada clase de hardware; proporcione ejemplos de dispositivos reales de cada clase.

5.9    Intente desarrollar una clasificación jerárquica para el software de computadoras.  Identifique cada clase de software; proporcione ejemplos de programas reales de cada clase.

      5.10. Hemos observado similitudes entre los procesos de ingeniería del hardware y del software.  ¿En qué difieren las fases de estos procesos?

      5.11. La ingeniería humana intenta construir sistemas "amigables con el usuario".  Defina el concepto “amigable con el usuario” con sus propias palabras.

5.12   Desarrolle una lista de comprobación de atributos que haya que considerar cuando se vaya a evaluar la "viabilidad" de un sistema.  Discuta la interrelación entre los atributos e intente aportar un método para clasificarlos de tal forma que se pueda obtener un “número de viabilidad” cuantitativo.

      5.13.                                                                                                                               Investigue sobre las técnicas de contabilidad que se usan para el análisis detallado de coste beneficio de un sistema basado en computadora que requiera fabricación de hardware y ensamblaje.  Intente escribir un conjunto de directrices tipo de “receta" que pudiese seguir un gestor técnico.

      5.14. Desarrolle un análisis de coste beneficio equivalente al que se muestra en las Tablas 5.2 y 5.3, para sistemas científicos/de ingeniería.  Amplíe las tablas para incluir aplicaciones de tiempo real y empotradas.

      5.15. Desarrolle un diagrama de contexto de la arquitectura y los diagramas de flujo de la arquitectura para un sistema basado en computadoras de su elección (o uno asignado por su profesor).

      5.16. Escriba una narrativa de módulo de sistema que pudiera encontrarse en la especificación del diagrama de arquitectura de uno o más de los subsistemas definidos en los DFAs del Problema 5.15.

      5.17. Investigue en la literatura sobre herramientas CASE y escriba un breve artículo describiendo cómo funcionan las herramientas de modelización y simulación.  Alternativa: recopile información de dos o más vendedores de herramientas CASE que suministren herramientas de modelización y simulación, y evalúe las similitudes y las diferencias.

      5.18. Basándose en los documentos suministrados por su profesor, desarrolle una especificación del sistema abreviada, para uno de los siguientes sistemas basados en computadora:

(a)   Un sistema de procesamiento de textos de bajo coste.

(b)   Un digitalizador óptico para una computadora personal.

(c)   Un sistema de correo electrónico.

(d)   Un sistema de matrícula para la universidad.

(e)   Un sistema de análisis de ingeniería.

(f)    Un sistema interactivo de reservas.

g)    Un sistema de interés local.

           Asegúrese de crear los modelos de arquitectura descritos en la Sección 5.4.

5.19.   ¿Existen características de un sistema que no se puedan establecer en el momento de la definición?  Describa esas características, si las hay, y explique por qué su consideración debe ser postergada para más adelante en el proceso de ingeniería.

5.20.   ¿Existen situaciones en las que la especificación formal del sistema pueda ser abreviada o eliminada por completo? Explique su respuesta.

OTRAS LECTURAS

Debido a que se trata de un tema interdisciplinario, la ingeniería de sistemas basados en computadora es una materia difícil y, por ello, se han publicado pocos libros verdaderamente buenos.  Los libros de Blanchard y Fabrycky [BLA81] y de Athey (Systematic Systems Approach, Prentice Hall, 1982) presentan el proceso de la ingeniería de sistemas (con un enfoque de ingeniería distinto) y constituyen una valiosa guía.  IEEE Computer Society ha puesto empeño en desarrollar una estructura educativa para la ingeniería de sistemas basados en computadora.  Sus primeros descubrimientos se han publicado en los Proceedings of Computer Based System Engineering Workshop (IEEE, 1990).

Un excelente tutorial del IEEE por Thayer y Dorfman (System and Software Requirements Engineering, IEEE Computer Society Press, 1990) trata las interrelaciones entre los aspectos del análisis de requisitos a nivel de software y a nivel de sistema.  Un manual de los mismos autores (Standars. Guidelines and Examples: System and Software Requirements Engineering, IEEE Computer Society Press, 1990) presenta un estudio detallado de los estándares y las directrices para el trabajo de análisis.

Los libros de Lesson (Systems Analysis and Design, SRA, 1981), McMenamin y Palmer (Essential Systems Analysis, Yourdon Press, 1984) y Silver (Systems Analysis and Design, Addison Wesley, 1989), proporcionan útiles tratamientos de la tarea de análisis de sistemas tal y como se aplica en el mundo de los sistemas de información.  Los libros contienen casos de estudio suplementarios que ilustran los problemas, los métodos y las soluciones que se pueden aplicar durante el análisis de sistemas.  Se han publicado muchos otros libros de texto en el área general del análisis y la definición de sistemas.  Entre las incorporaciones más recientes a la literatura se encuentran:

Dickinson, B., Developing Quality Systems, McGraw Hill, 1988.

Gause, D.A, y G.M Weinberg, Exploring Requirements, Dorset House, 1989.

ModeIl, M.E., A Professional's Guide to System Analysis, McGraw Hill, 1988.

Para aquellos lectores involucrados activamente en el trabajo con sistemas o interesados en un tratamiento sofisticado del tema, los libros de Gerald Weinberg (An Introduction to General System Thinking, Wiley Interscience, 1976 y On the design of Stable Systems, Wiley Interscience, 1979) se han convertido ya en clásicos y proporcionan un tratamiento excelente de la "concepción de sistemas generales" que conduce implícitamente a un enfoque general del análisis y del diseño de sistemas.  Los libros más recientes de Weinberg (General Principies of System Design, Dorset House, 1988 y Rethinking Systems Analysis and Design, Dorset House, 1988) continúan en la tradición de sus anteriores trabajos.

Las series de Auerbach, System Development Management (Auerbach Publishers, actualizadas cada año), proporcionan un tratamiento excelente de la planificación y la definición de sistemas de información a gran escala.  El enfoque pragmático de Auerbach será especialmente útil a los profesionales de la industria.

---

[1]     No se deben confundir los términos “ingeniería de sistemas de computadora” e “ingeniería de computadoras”.  La ingeniería de computadoras se centra exclusivamente en el diseño y la implementación del hardware de computadora y su software de sistema asociado, mientras que la ingeniería de sistemas de computadora se aplica a todos los productos y sistemas que contienen computadoras.

[2]     El uso de las técnicas orientadas a los objetos (capítulos 8 y 12) puede llevarnos a disponer de una amplia serie de “CIs de software” - bloques de construcción de software reutilizables.

[3]     Actualmente se puede crear la especificación del diseño con herramientas CASE especializadas (p. ej.: Teamwork, de Cadre) y mantenerlo en forma legible para la máquina.  En algunos casos, la documentación del diseño, denominada lenguaje de diseño de programa, se incluye directamente en los archivos del código fuente.

[4]     Hay un tipo de herramientas CASE, denominadas herramientas de simulación y creación de prototipos, que pueden ayudar bastante en el análisis técnico.  Estas herramientas se tratan en los capítulos 15 y 22.

[5]  Hatley y Pirbhai [HAT87] los denominan módulos del sistema.

[6]     La EDA es una adaptación de varias especificaciones diferentes sugeridas por Hartley y Pirbhai [HAT87].  Para  Simplificar, lo hemos combinado en un único documento