Sistemas versus Software

"Un buen científico es una persona con ideas originales. Un buen ingeniero es una persona que hace diseños que funcionan con un mínimo posible de ideas originales"

Freeman Dyson

La ingeniería de sistemas se preocupa del  análisis y modelamiento del sistema que se pretende construir. El trabajo consiste a grandes rasgos en entender el problema, fijar las prioridades y especificarlas en un modelo lógico que normalmente se concreta como un listado exhaustivo de especificaciones sobre que es lo que el programa debe hacer, las entradas, procesos y salidas..

El trabajo de la ingeniería de sistemas tiene que ver con la organización, las necesidades y expectativas de los clientes, la idea es definir y ordenar las prioridades en una capa lógica abstracta, antes de enredarse con los detalles técnicos de la codificación y es por eso que se le da gran importancia al trabajo de encuestas en esta etapa, de manera de tener claras las prioridades y expectativas.

Luego viene el trabajo de ingeniería de software que consiste en codificar las especificaciones entregadas y convertirlas en un programa que funcione. El trabajo en una primera instancia consiste en construir prototipos de las interfases de usuario, es decir un programa "de mentira" para determinar las mejores interfases hombre-máquina y, una vez elegido esto dedicarse a codificar y optimizar los procesos que el sistema debe realizar, todo esto apegado a las especificaciones entregadas por el diseño lógico. La construcción de prototipos semi funcionales es de gran ayuda al momento de probar el comportamiento real de las ideas del diseño.

Esta es la teoría. La construcción de un programa debe ser un proceso en cascada donde el diseño ideal debe preceder a la codificación. En el desarrollo de programas computacionales según se nos ha enseñado, existen dos etapas claramente definidas: el diseño lógico y el diseño físico. En la realidad sin embargo,  esta separación ha sido fuente de diversos problemas

Esta separación entre diseño lógico y el diseño físico es consecuencia de los problemas de crecimiento de tamaño y complejidad en los sistemas. En un principio ambas etapas estaban estrechamente relacionadas, y lo siguen estando en el caso de los sistemas pequeños donde trabaja solo un programador o un pequeño grupo de personas.

Pero al hacer sistemas más complejos y dividir las tareas entre un equipo de programadores era necesario fijar prioridades y criterios de diseño de antemano, de manera que todos trabajen bajo normas claras y criterios comunes. Esto evita el problema de desvíarse de los grandes objetivos por percepciones o necesidades particulares de alguno de sus subsistemas. También divide el trabajo en una parte creativa y normativa (diseño lógico) y otra mecanizada y sujeta a normas (diseño físico). 

El diseño en cascada ha formado una verdadera cultura que separa a analistas y programadores. Harry Boehm de la Universidad de California del Sur cuenta su experiencia al respecto: "Cuando tratamos de introducir el uso de prototipos en proyectos con alta interacción de usuarios en TRW, los ingenieros de software, resistiéndose al cambio, golpeaban la mesa y gritaban, "¡No pueden hacer esto!  ¡hacer prototipos es codificar sin haber pasado la revisión crítica del diseño, esto esta absolutamente prohibido por las políticas corporativas!" , tomó años deshacer las muchas formas en que el modelo de cascada se había infiltrado en varios aspectos de nuestra cultura corporativa tales como el marketing, preparación de propuestas, estimación de costos, contratos, contabilidad y gerenciamiento"

Hay un viejo cuento de un ingeniero de sistemas que decía haber diseñado finalmente un software que podía rivalizar con el cerebro humano. Al pedírsele que lo demostrara entregó una larga lista con las especificaciones comunes de un computador a las que había agregado las especificaciones de "imaginación", "conciencia de si mismo", "lenguaje sofisticado" etc. "Bueno", dijo a modo de explicación "allí tienen el diseño, ahora solo es cosa de los programadores y los ingenieros de hardware implementarla. Lo principal ya esta hecho.

Bueno, ese es uno de los mayores problemas de trabajar en abstracto desentendiéndose de los problemas prosaicos tales como la codificación, los recursos disponibles, costos  y el rendimiento. Los ingenieros de sistema vienen normalmente de las áreas de la ingeniería industrial o de la administración (ingeniería comercial en Chile), no son fuertes en programación y a menudo ven con cierto desprecio la labor del programador, considerándola mecánica y poco creativa.

No es raro que los diseños lógicos, al desentenderse de los detalles del mundo real tales como las limitaciones de hardware o la complicación excesiva en el código terminen en una serie de especificaciones y requisitos que no es factible de implementar con éxito. Esos son los conocidos "desastres informáticos" o sistemas que llevan mucho tiempo, esfuerzo y dinero en desarrollarse y que nunca llegan a funcionar del todo bien (muchos simplemente jamás funcionan).

"A comienzos de los 80, una gran organización del gobierno contrató a TRW para desarrollar un ambicioso sistema de consultas y análisis. El sistema proveería a más de 1.000 usuarios, dentro de un gran complejo de edificios, con poderosas capacidades de análisis y consultas para una gran base de datos dinámica.

TRW y el cliente especificaron el sistema usando el modelo clásico de cascada de la ingeniería de sistemas, basado principalmente en encuestas a usuarios y análisis de rendimiento de alto nivel, llegaron  a establecer como requisito fundamental la respuesta a cualquier consulta en menos de un segundo.

Dos mil páginas de especificaciones más tarde, los arquitectos de software encontraron que este rendimiento solo podía alcanzarse con un diseño muy especializado, que intentara anticipar patrones de búsqueda y hacer uso extensivo de cachés de datos. Como resultado se estableció que se requerían al menos 25 super-midi computadores, para hacer los cachés y un algoritmo cuya complejidad desafiaba cualquier clase de análisis simple. Esto llevó a un costo estimado de 100 millones de dólares, debido principalmente al requisito de respuesta en menos de un segundo.

Encarando este poco atractivo prospecto, se decidió desarrollar un prototipo de la interface de usuario y las capacidades representativas para probarlas. Como resultado se vio que un tiempo de respuesta de cuatro segundos sería satisfactoria para los usuarios el 90 por ciento de las veces. Un sistema con respuesta de cuatro segundos bajó los costos de implementación a solo 30 millones de dólares."

(Barry Boehm, "A Large Secuencial-Engineering Near-Disaster" Revista "Computer" marzo 2000, pag. 115)

La historia anterior muestra los peligros de tener diseñadores lógicos absolutamente separados de las consideraciones físicas de codificación, limitaciones del hardware, rendimiento y costo de los sistemas. Es necesario volver a revisar muchos conceptos que se daban por inamovibles, debe existir una interaccion y realimentación entre el diseño lógico y el físico y si se puede codificar y construir prototipos antes de completar las especificaciones del diseño lógico. La idea de una cascada con una etapa tras otra esta siendo reemplazada por un modelo espiral, los ingenieros de software ya no se quedan sentados esperando las especificaciones de la ingeniería de sistemas, sino que participan activamente en el proceso de creación y definición de especificaciones, agregando el trabajo con prototipos a las tradicionales encuestas para lograr productos con mayor base en el mundo real y no solo ejercicios teóricos de optimización.

En USA ya hay varias iniciativas para promover este cambio cultural en el diseño de sistemas, partiendo por el Integrated _Capability Maturity Model de la FAA y la iniciativa del SEI y el Departamento de Defensa llamado proyecto de integración CMM I (la I es de Integration). Más información sobre estas iniciativas conocidas como desarrollo unificado o integrado de sistemas (en oposición al tradicional modelo de desarrollo en cascada) puede encontrarse en http://www.sei.cmu.edu/cmm/cmmi/ 

Bastante, la herramienta por excelencia para desarrollar prototipos es el Visual Basic y la experiencia de los desarrolladores de sistemas pequeños, acostumbrados a encarar los aspectos lógicos y físico de los sistemas es muy valiosa a la hora de desarrollar prototipos e interfases hombre-maquina. Un nicho más de desarrollo para los especialistas en sistemas pequeños

El contenido de ésta nota le debe mucho al artículo "Unifying Software Engineering and Systems Engineering" de Barry Bohem, aparecido en la revista "Computing" de marzo del 2000