Ingenieria de Sistemas

La palabra sistema es posiblemente el término más usado y abusado del léxico técnico. Hablamos de sistemas políticos y de sistemas educativos, de sistemas de aviación y de sistemas de fabricación, de sistemas bancarios y de sistemas de locomoción. La palabra no nos dice gran cosa. Usamos el adjetivo para describir el sistema y para entender el contexto en que se emplea. El diccionario Webster define sistema como: 

1. Un conjunto o disposición de cosas relacionadas de manera que forman una unidad o un todo orgánico.

2. Un conjunto de hechos, principios, reglas, etc., clasificadas y dispuestas de manera ordenada mostrando un plan lógico de unión de las partes; 3. un método o plan de clasificación o disposición; 4.una manera establecida de hacer algo; método; procedimiento ...

3. Un conjunto o disposición de elementos que están organizados para realizar un objetivo prevenido procesando información.

 

El objetivo puede ser soportar alguna función de negocio o desarrollar un producto que pueda venderse para generar beneficios. Para conseguir el objetivo, un sistema basado en computadora hace uso de varios elementos del sistema:

•      Software. Programas de computadora, estructuras de datos y su documentación que sirven para hacer efectivo el método     lógico, procedimiento o control requerido. 

•      Hardware. Dispositivos electrónicos que proporcionan capacidad de cálculo, dispositivos de interconexión (por ejemplo, conmutadores de red, dispositivos de telecomunicación) y dispositivos electromecánicos (por ejemplo, sensores, motores, bombas) que proporcionan una función externa, del mundo real. 

•      Personas. Usuarios y operadores del hardware y software. 

•      Documentación. Manuales, formularios y otra información descriptiva que plasma el empleo y/o funcionamiento del sistema. 

•      Procedimientos. Los pasos que definen el empleo específico de cada elemento del sistema o el contexto procedimental en que reside el sistema. 

Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macro elemento de un sistema aún más grande. El macro elemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora. 

Los elementos de la máquina de control numérico incluyen hardware electrónico y electromecánico (por ejemplo, procesador y memoria, motores, sensores); software (para comunicaciones, control de la máquina e interpolación); personas (el operador de la máquina); una base de datos (el programa CN almacenado); documentación y procedimientos. Se podría aplicar una descomposición similar a los dispositivos de entrada de información y al robot. Todos son sistemas basados en computadora.

En el siguiente nivel de la jerarquía, se define una célula de fabricación. La célula de fabricación es un sistema basado en computadora que puede tener elementos propios (por ejemplo, computadoras, fijaciones mecánicas) y también integra los macro elementos que hemos denominado máquina de control numérico, robot y dispositivo de entrada de información. Para resumir, la célula de fabricación y sus macro elementos están compuestos de elementos del sistema con las etiquetas genéricas: software, hardware, personas, base de datos, procedimientos y documentación.

Modelado del sistema

La ingeniería de sistemas de computadora es un proceso de modelado. Tanto si el punto de mira está en la visión global o en la visión detallada, el ingeniero crea modelos que: 

Definan los procesos que satisfagan las necesidades de la visión en consideración. 

Representen el comportamiento de los procesos y los supuestos en los que se basa el comportamiento.

 

Definan explícitamente las entradas exógenas3 y endógenas de información al modelo. 

Representen todos las uniones (incluyendo las salidas) que permitan al ingeniero entender mejor la visión. 

Restricciones que deben considerarse para construir un modelo del sistema:

1. Supuestos que reducen el número de permutaciones y variaciones posibles, permitiendo así al modelo reflejar el problema de manera razonable. Por ejemplo considere un producto de representación en tres dimensiones usado por la industria de entretenimiento para crear animaciones realistas. Un dominio del producto permite la representación de formas humanas en 3D. Las entradas a este dominio comprenden la habilidad de introducir movimiento de un «actor» humano vivo, desde vídeo o creando modelos gráficos. El ingeniero del sistema hace ciertos supuestos sobre el rango de movimientos humanos permitidos de manera que puede limitarse el proceso y el rango de entradas.  

2. Simplificaciones que permiten crear el modelo a tiempo. Para ilustrarlo, considere una compañía de productos de oficina que vende y suministra una amplia variedad de fotocopiadoras, faxes y equipos similares. El ingeniero del sistema está modelando las necesidades de la organización suministradora y está trabajando para entender el flujo de información que engendra una orden de suministro. Aunque una orden de suministro puede generarse desde muchos orígenes, el ingeniero categoriza solamente dos fuentes: demanda interna o petición externa. Esto permite una partición simplificada de entradas necesaria para generar una orden de trabajo. 

3. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se está modelando un sistema de aviónica para un avión de próxima generación. Como el avión tendrá un diseño de dos motores, todos los dominios de supervisión de la propulsión se modelarán para albergar un máximo de dos motores y sus sistemas redundantes asociados. 

4. Restricciones que guían la manera de crear el modelo y el enfoque que se toma al implementar el modelo. Por ejemplo, la infraestructura tecnológica para el sistema de representación en tres dimensiones descrita anteriormente es un solo procesador basado en un Power-PC. La complejidad de cálculo de los problemas debe restringirse para encajar en los límites de proceso impuestos por el procesador. 

5. Preferencias que indican la arquitectura preferida para todos los datos, funciones y tecnología. La solución preferida entra a veces en conflicto con otros factores restrictivos. Aunque la satisfacción del cliente es a menudo tomada en cuenta hasta el punto de realizar su enfoque preferido. 

Simulación del sistema

Los sistemas de tiempo real y sistemas empotrados pertenecen a menudo a la categoría de sistemas reactivos. 

Desgraciadamente, los desarrolladores de sistemas reactivos luchan a veces para hacerlos funcionar correctamente. Hasta hace poco, ha sido difícil predecir el rendimiento, la eficacia y el comportamiento de estos sistemas antes de construirlos. 

Realmente, la construcción de muchos sistemas de tiempo real era una aventura. Las sorpresas (la mayoría desagradables) no se descubrían hasta que el sistema era construido y «arrojado colina abajo». Si el sistema se estrellaba debido a un funcionamiento incorrecto, comportamiento inapropiado o escaso rendimiento, cogíamos las piezas y empezábamos de nuevo.  

 

Muchos sistemas de la categoría de los reactivos controlan máquinas y/o procesos (por ejemplo, aerolíneas comerciales o refinerías de petróleo) que deben operar con extrema fiabilidad. Si el sistema falla, podrían ocurrir pérdidas económicas o humanas significativas. Hoy en día se utilizan herramientas software para el modelado y simulación de sistemas para ayudar a eliminar sorpresas cuando se construyen sistemas reactivos basados en computadora. 

Estas herramientas se aplican durante el proceso de ingeniería de sistemas, mientras se están especificando las necesidades del hardware, software, bases de datos y de personas. Las herramientas de modelado y simulación capacitan al ingeniero de sistemas para probar una especificación del sistema. Se estudia brevemente los detalles técnicos y técnicas especiales de modelado que se emplean para llevar a cabo estas pruebas.

Ingeniería de Proceso de Negocio

Es un conjunto de tareas relacionadas lógicamente llevadas a cabo para lograr un resultado de negocio definido. Su objetivo es definir arquitecturas que permitan a las empresas emplear la información eficazmente. 

1.      La arquitectura de datos proporciona una estructura para las necesidades de información de un negocio o de una función de negocio. Los ladrillos de la arquitectura son los objetos de datos que emplea la empresa. Un objeto de datos contiene un conjunto de atributos que definen aspectos, cualidades, características de los datos que han sido descritos.

2.      La arquitectura de aplicación comprende aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algún propósito del negocio. Se considera  normalmente que la arquitectura de aplicación es el sistema de programas (software) que realiza esta transformación.

             

Sin embargo, en un contexto más amplio, la arquitectura de aplicación podría incorporar el papel de las personas (por ejemplo, cliente/servidor) que ha sido diseñado para implementar estas tecnologías.

3.       La infraestructura tecnológica proporciona el fundamento de las arquitecturas de datos y de aplicaciones.

La infraestructura comprende el hardware y el software empleados para dar soporte a las aplicaciones y datos. Esto incluye computadoras y redes de computadora, enlaces de telecomunicaciones, tecnologías de almacenamiento y la arquitectura (por ejemplo, cliente/servidor) diseñada para implementar estas tecnologías.

Jerarquía de la ingeniería  de Procesos

La visión global se consigue a través de la planificación de la estrategia de información (PEI). La PEI ve todo el negocio como una entidad y aísla los dominios del negocio (por ejemplo, ingeniería, fabricación, marketing, finanzas, ventas) importantes para la totalidad de la empresa. La PEI define los objetos de datos visibles a nivel empresa, sus relaciones y cómo fluyen entre los dominios del negocio.

 La vista del dominio se trata con una actividad IPN denominada análisis del área de negocio (AAN).A medida que el ingeniero de información comienza el AAN, el enfoque se estrecha hacia un dominio del negocio específico. El AAN ve el área del negocio como una entidad y aísla las funciones de negocio y procedimientos que permiten al área del negocio lograr sus objetivos y metas. El AAN, al igual que la planificación de la estrategia de información, define objetos de datos, sus relaciones y cómo fluye la información. Pero a este nivel, estas características están delimitadas por el área de negocio que se está analizando. El resultado de AAN es aislar las áreas de oportunidad en las que los sistemas de información pueden prestar soporte al área de negocio.

Ingeniería de Producto

La meta de la ingeniería de producto es traducir el deseo de un cliente, de un conjunto de capacidades definidas, a un producto operativo. Para conseguir esta meta, la ingeniería de producto (como la ingeniería de proceso de negocio) debe crear una arquitectura y una infraestructura.La arquitectura comprende cuatro componentes de sistema distintos:

Se establece una infraestructura de soporte e incluye la tecnología requerida para unir los  componentes y la información (por ejemplo, documentos, CD-ROM, vídeo) que se emplea para dar soporte a los componentes.

 

Jerarquía de la ingeniería del producto

 Los requisitos generales del producto se obtienen del cliente. Estos requisitos comprenden necesidades de información y control, funcionalidad del producto y comportamiento, rendimiento general del producto, diseño, restricciones de la interfaz y otras necesidades especiales. Una vez que se conocen estos requisitos, la misión del análisis del sistema es asignar funcionalidad y comportamiento a cada uno de los cuatro componentes mencionados anteriormente.

Una vez que se ha hecho la asignación, comienza la ingeniería de componentes del sistema que consiste  un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de los componentes del sistema:

•       Ingeniería del software

•       Ingeniería hardware

•       Ingeniería humana

•       Ingeniería de bases de datos. 

Identificación de requisitos

En principio, parece bastante simple -preguntar al cliente, a los usuarios y a los que están involucrados en los objetivos del sistema o producto y sean expertos, investigar cómo los sistemas o productos se ajustan a las necesidades del negocio, y finalmente, cómo el sistema o producto va a ser utilizado en el día a día.

Hay una serie de problemas que nos ayudan a comprender por qué la obtención de requisitos es costosa.

•      problemas de alcance. El límite del sistema está mal definido o los detalles técnicos innecesarios, que han sido aportados por los clientes/usuarios, pueden confundir más que clarificar los objetivos del sistema.

•      problemas de comprensión. Los clientes/usuarios no están completamente seguros de lo que necesitan, tienen una pobre compresión de las capacidades y limitaciones de su entorno de computación, no existe un total entendimiento del dominio del problema, existen dificultades para comunicar las necesidades al ingeniero del sistema, la omisión de información por considerar que es «obvia», especificación de requisitos que están en conflicto con las necesidades de otros clientes/usuarios, o especificar requisitos ambiguos o poco estables.

•      Problemas de volatilidad. Los requisitos cambian con el tiempo.

Análisis y negociación de requisitos

Una vez recopilados los requisitos, el producto obtenido configura la base del análisis de requisitos. Los requisitos se agrupan por categorías y se organizan en subconjuntos, se estudia cada requisito en relación con el resto, se examinan los requisitos en su consistencia, completitud y ambigüedad, y se clasifican en base a las necesidades de los clientes/usuarios. Al iniciarse la actividad del análisis de requisitos se plantean las siguientes cuestiones:

• ü  ¿Cada requisito es consistente con los objetivos generales del sistema/producto?
• ü  ¿Tienen todos los requisitos especificados el nivel adecuado de abstracción? Es decir, ¿algunos requisitos tienen un nivel de detalle técnico inapropiado en esta etapa?
• ü  ¿El requisito es necesario o representa una característica añadida que puede no ser esencial a la finalidad del sistema?
• ü  ¿Cada requisito está delimitado y sin ambigüedad?
• ü  Cada requisito tiene procedencia. Es decir, ¿existe un origen (general o específico) conocido para cada requisito?
• ü  ¿Existen requisitos incompatibles con otros requisitos?
• ü  ¿Es posible lograr cada requisito en el entorno técnico donde se integrará el sistema o producto?
• ü  ¿Se puede probar el requisito una vez implementado?

Especificación de requisitos

En el contexto de un sistema basado en computadoras (y software), el término especificación significa distintas cosas para diferentes personas. Una especificación puede ser un documento escrito, un modelo gráfico, un modelo matemático formal, una colección de escenarios de uso, un prototipo o una combinación de lo anteriormente citado. Algunos sugieren que debe desarrollarse una «plantilla estándar» y usarse en la especificación del sistema, argumentando que así se conseguirían requisitos que sean presentados de una forma más consistente y más comprensible

.

No obstante, en muchas ocasiones es necesario buscar la flexibilidad cuando una especificación va a ser desarrollada. Para grandes sistemas, un documento escrito, combinado con descripciones en lenguajes natural y modelos gráficos puede ser la mejor alternativa. En cualquier caso, los escenarios a utilizar pueden ser tanto los requeridos para productos de tamaño pequeño o los de sistemas que residan en entornos técnicos bien conocidos.

La Especificación del Sistema es el producto final sobre los requisitos del sistema obtenido por el ingeniero. Sirve como fundamento para la ingeniería del hardware, ingeniería del software, la ingeniería de bases de datos y la ingeniería humana.

Modelado del sistema

La respuesta es obvia. Para especificar completamente lo que vamos a desarrollar, necesitamos un modelo de la cocina con toda su información, esto es, un anteproyecto o una representación en tres dimensiones que muestre las posiciones de los armarios y electrodomésticos, y sus relaciones. Con el modelo será relativamente fácil asegurar la eficiencia del trabajo (un requisito de todas las cocinas), la estética «visual» de la sala (es un requisito personal, aunque muy importante). Se construyen modelos del sistema por la misma razón que desarrollamos para una cocina un anteproyecto o una representación en 3D. Es importante evaluar los componentes del sistema y sus relaciones entre sí; determinar cómo están reflejados los requisitos, y valorar como se ha concebido la «estética» en el sistema. 

Validación de requisitos

El resultado del trabajo realizado es una consecuencia de la ingeniería de requisitos (especificación del sistema e información relacionada) y es evaluada su calidad en la fase de validación. La validación de requisitos examina las especificaciones para asegurar que todos los requisitos del sistema han sido establecidos sin ambigüedad, sin inconsistencias, sin omisiones, que los errores detectados hayan sido corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el proceso, el proyecto y el producto.

El primer mecanismo para la validación de los requisitos es la revisión técnica formal. El equipo de revisión incluye ingenieros del sistema, clientes, usuarios, y otros intervinientes que examinan la especificación del sistema5 buscando errores en el contenido o en la interpretación, áreas donde se necesitan aclaraciones, información incompleta, inconsistencias (es un problema importante), requisitos contradictorios, o requisitos imposibles o inalcanzables.

Gestión de requisitos

La gestión de requisitos es un conjunto de actividades que ayudan al equipo de trabajo a identificar, controlar y seguir los requisitos y los cambios en cualquier momento. Como en la Gestión de Configuración del Software (GCS), la gestión de requisitos comienza con la actividad de identificación. A cada requisito se le asigna un Único identificador, que puede tomar la forma: <tipo de requisito><requisito n.⁰ >

El tipo de requisito toma alguno de los siguientes valores: F = requisito funcional, D = requisito de datos, C =requisito de comportamiento, Z = requisito de interfaz, y S = requisito de salida. De esta forma, un requisito identificado como F09 indica que se trata de un requisito funcional y que tiene asignado el número 9 dentro de los citados requisitos.

Una vez los requisitos han sido identificados, se desarrollarán un conjunto de matrices para su seguimiento. Cada matriz de seguimiento identifica los requisitos relacionados con uno o más aspectos del sistema o su entorno. Entre las posibles matrices de seguimiento citamos las siguientes:

• Matriz de seguimiento de características. Muestra los requisitos identificados en relación a las características definidas por el cliente del sistema/producto.

• Matriz de seguimiento de orígenes. Identifica el origen de cada requisito.

• Matriz de seguimiento de dependencias. Indica cómo se relacionan los requisitos entre sí.

• Matriz de Seguimiento de subsistemas. Vincula los requisitos a los subsistemas que los manejan.

• Matriz de seguimiento de interfaces. Muestra como los requisitos están vinculados a las interfaces externas o internas del sistema.

Para desarrollar el modelo de sistema, se emplea un esquema del modelado del sistema. El ingeniero de sistemas asigna elementos a cada una de las cinco regiones de tratamiento del esquema: (1) interfaz de usuario, (2) entrada, (3) tratamiento y control del sistema, (4) salida y (5) mantenimiento y autocomprobación. En la Figura 10.5 se muestra el formato del esquema de arquitectura.

Como casi todas las técnicas de modelado usadas en la ingeniería del software y de sistemas, el esquema del modelado del sistema permite al analista crear una jerarquía en detalle. En la parte alta de la jerarquía reside  

el diagrama de contexto del sistema (DCS). 

El diagrama de contexto «establece el límite de información entre el sistema que se está implementando y el entorno en que va a operar». Es decir, el DCS define todos los suministradores externos de información que emplea el sistema, todos los consumidores externos de información creados por el sistema y todas las entidades que se comunican a través de la interfaz o realizan mantenimiento y auto comprobación .