ingenieria de Sistema

A.   Sistema basado en computadoras

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.

Se proporcionan cinco definiciones más en el diccionario, pero no se sugiere un sinónimo preciso. Sistema es una palabra especial. Tomando prestada la definición del diccionario Webster, definimos un sistema basado en computadora como:

Un conjunto o disposición de elementos que están organizados para realizar un objetivo predeterminado 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.

Los elementos se combinan de varias maneras para transformar la información. Por ejemplo, un departamento de marketing transforma la información bruta de ventas en un perfil del típico comprador del producto; un robot transforma un archivo de órdenes, que contiene instrucciones específicas, en un conjunto de señales de control que provocan alguna acción física específica. Tanto la creación de un sistema de información para asesorar a un departamento de marketing, como el software de control para el robot, requieren de la ingeniería de sistemas. Una característica complicada de los sistemas basados en computadora es que los elementos que componen un sistema pueden también representar un macroelemento de un sistema aún más grande.

El macroelemento es un sistema basado en computadora que es parte de un sistema más grande basado en computadora. Por ejemplo, consideremos un «sistema de automatización de una fábrica» que es esencialmente una jerarquía de sistemas. En el nivel inferior de la jerarquía tenemos una máquina de control numérico, robots y dispositivos de entrada de información. Cada uno es un sistema basado en computadora por derecho propio.

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 macroelementos 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 macroelementos están compuestos de elementos del sistema con las etiquetas genéricas: software, hardware, personas, 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 CN podrían ser manejadas por el mismo operador (el elemento personas). En otros casos, los elementos genéricos son exclusivos de un sistema. El papel del ingeniero de sistemas es definir los elementos de un sistema específico basado en computadora en el contexto de la jerarquía global de sistemas (macroelementos). En las siguientes secciones, examinamos las tareas que constituyen la ingeniería de sistemas de computadoras.

La jerarquía de la ingeniería en sistemas

Independientemente del dominio de enfoque, la ingeniería de sistemas comprende una colección de métodos para navegar de arriba abajo y de abajo arriba en la jerarquía ilustrada en la Figura 10.1. El proceso de la ingeniería de sistemas empieza normalmente con una «visión global». Es decir, se examina el dominio entero del negocio o del producto para asegurarse de que se puede establecer el contexto de negocio o tecnológico apropiado. La visión global se refina para enfocarse totalmente en un dominio de interés específico. Dentro de un dominio específico, se analiza la necesidad de elementos del sistema (por ejemplo, información, software, hardware, personas). Finalmente, se inicia el análisis, diseño y construcción del elemento del sistema deseado. En la parte alta de la jerarquía se establece un contexto muy amplio y en la parte baja se llevan a cabo actividades técnicas detalladas, realizadas por la disciplina de ingeniería correspondiente (por ejemplo, ingeniería hardware o software).

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.

Para construir un modelo del sistema, el ingeniero debería considerar algunas restricciones:

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  (por ejemplo, las piernas no pueden enrollarse alrededor del tronco) 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 deben 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. El modelo de sistema resultante (desde cualquier visión) puede reclamar una solución completamente automática, semiautomática o un enfoque manual. De hecho, es posible a menudo caracterizar modelos de cada tipo que sirven de soluciones alternativas para el problema que tenemos entre manos. En esencia, el ingeniero del sistema modifica simplemente la influencia relativa de los diferentes elementos del sistema (personas, hardware, software) para crear modelos de cada tipo.

Simulación del sistema

En los años 60, R.M. Graham hizo un comentario crítico sobre la manera en que se construían los sistemas basados en computadora: «Construimos sistemas igual que los hermanos Wright construían aviones: construimos todo el sistema, lo empujamos barranco abajo, le dejamos que se estrelle y empezamos de nuevo.» De hecho, para al menos un tipo de sistema  el sistema reactivo lo continuamos haciendo hoy en día. Muchos sistemas basados en computadora interaccionan con el mundo real de forma reactiva. Es decir, los acontecimientos del mundo real son vigilados por el hardware y el software que componen el sistema, y basándose en esos sucesos, el sistema aplica su control sobre las máquinas, procesos e incluso las personas que motivan los acontecimientos. 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. Por este motivo, el enfoque descrito por Graham es penoso y peligroso. 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.

A.     Ingeniería de proceso de negocio: Una visón general

El objetivo de la ingeniería de proceso de negocio (ZPN) es definir arquitecturas que permitan a las empresas emplear la información eficazmente. Michael Guttman describe el desafío cuando dice:

El actual entorno computacional consiste en un poder de computación distribuido en toda la empresa con múltiples unidades diferentes de procesamiento, dividido y configurado por una amplia variedad de tareas, Nuevos planteamientos como la computación cliente-servidor, procesamiento distribuido, el trabajo en red (por nombrar algunos de los términos más sobre usados) permiten gestionar las demandas aportando mayor funcionalidad y flexibilidad.

Sin embargo, el coste de estos cambios es ampliamente discutido por las organizaciones de TI (Tecnologías de la Información) que deben soportar esta políglota configuración. Hoy, cada organización de TI debe favorecer la integración de sus sistemas. Debe diseñar, implementar y soportar su propia configuración de recursos de computación heterogénea, distribuidos lógica y geográficamente por toda la empresa, conectándola a través de un esquema apropiado para el trabajo en red. Por otra parte, esta configuración debe ser diseñada para cambios continuos, desigualmente localizados en la empresa, debido a cambios en requisitos del negocio y en las propias tecnologías. Estos diversos e incrementales cambios deben ser coordinados a través del entorno distribuido, consistente en hardware y software suministrado por decenas, cuando no cientos, de vendedores. Por supuesto, esperamos que estos cambios los incorporemos sin ruptura con la operativa habitual permitiendo además ampliar la operativa.

Cuando hablamos de una visión general de las necesidades de tecnología de información de una compañía, existen pequeñas incertidumbres que son planteadas a ingeniería de sistemas. La ingeniería de proceso de Negocio es un acercamiento para crear un plan general para implementar la arquitectura de computación.

Se deben analizar y diseñar tres arquitecturas diferentes dentro del contexto de objetivos y metas de negocio:

·         arquitectura de datos

·         arquitectura de aplicaciones

·         infraestructura de la tecnología

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 o descriptor de los datos que han sido descritos. Por ejemplo, un ingeniero de la información puede definir el objeto de datos: cliente. Para describir más en detalle al cliente, se definen los siguientes atributos:

Objeto: Cliente

Atributos:

Nombre

Nombre de la compañía

Clasificación del trabajo y autoridad en compra

Dirección comercial e información de contacto

Producto(s) de interés

Compra(s) anteriores

Fecha de último contacto

Situación del contacto

Una vez definido el conjunto de datos, se identifican sus relaciones. Una relación indica como los objetos están conectados. Como ejemplo, considerar los objetos: cliente y producto A. Los dos objetos pueden conectarse por la relación compra; es decir, un cliente compra el producto A o el producto A es comprado por un cliente. Los objetos de datos (pueden existir cientos o miles para una actividad de negocio importante) fluyen entre las funciones de negocio, están organizados dentro de una base de datos y se transforman para proveer información que sirva a las necesidades del negocio.

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. En el contexto de este libro, consideramos 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.

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

Para modelar las arquitecturas de sistema descritas anteriormente, se define una jerarquía de actividades de ingeniería de la información. Como muestra la Figura 10.2, 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.

Una vez que se ha aislado un sistema de información para un desarrollo posterior, la IPN hace una transición a la ingeniería del software. Invocando la fase del diseño de sistema de negocio (DSN), se modelan los requisitos básicos de un sistema de información específico y estos requisitos se traducen en arquitectura de datos, arquitectura de aplicación e infraestructura tecnológica. El paso final de la IPN (construcción e integración, C&Z) se centra en los detalles de la implementación. La arquitectura e infraestructura se implementan construyendo una base de datos apropiados y estructuras internas de datos, mediante la construcción de aplicaciones que están constituidas por programas, y seleccionando los elementos apropiados de una infraestructura tecnológica para dar soporte al diseño creado durante el DSN. Cada uno de estos componentes del sistema debe integrarse para formar una aplicación o sistema de información completo. La actividad de integración también coloca al nuevo sistema de información en el contexto del área de negocio, realizando todo el entrenamiento de usuario y soporte logístico para conseguir una suave transición.

A.   Ingeniería de producto: Una visión general 

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: software, hardware, datos (bases de datos) y personas. 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.

Como se muestra en la Figura 10.3, la visión global se consigue a través de la ingeniería de requisitos. 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. La ingeniería de componentes del sistema es, de hecho, un conjunto de actividades concurrentes que se dirigen separadamente a cada uno de los componentes del sistema: la ingeniería del software, ingeniería hardware, ingeniería humana e ingeniería de bases de datos. Cada una de estas disciplinas de ingeniería toma una vista de dominio específica, pero es importante resaltar que las disciplinas de ingeniería deben establecer y mantener una comunicación activa entre ellas

Parte del papel del análisis de sistemas es establecer los mecanismos de interfaz que permitirán que esto suceda. La visión de elemento para la ingeniería de producto es la disciplina de ingeniería aplicada a la asignación de componentes. Para la ingeniería del software, esto significa actividades de modelado del análisis y diseño (cubierto en detalle en posteriores capítulos) y actividades de construcción e integración que comprenden generación de código, pruebas y actividades de soporte. El modelado de la fase de análisis asigna requisitos a las representaciones de datos, funciones y comportamiento. El diseño convierte el modelo de análisis en diseños de datos, arquitectónicos, de interfaz y a nivel de componentes del software.

A.   Ingeniería de requisitos

La consecuencia del proceso de ingeniería de sistemas es la especificación de un sistema o producto basado en computadora que se describe genéricamente, en diferentes niveles en la Figura 10.1. Pero el desafío de la ingeniería del sistema (y de los ingenieros del software) es importante: ¿Cómo podemos asegurar que hemos especificado un sistema que recoge las necesidades del cliente y satisface sus expectativas? No hay una respuesta segura a esta difícil pregunta, pero un sólido proceso de ingeniería de requisitos es la mejor solución de que disponemos actualmente.

La ingeniería de requisitos facilita el mecanismo apropiado para comprender lo que quiere el cliente, analizando necesidades, confirmando su viabilidad, negociando una solución razonable, especificando la solución sin ambigüedad, validando la especificación y gestionando los requisitos para que se transformen en un sistema operacional. El proceso de ingeniería de requisitos puede ser descrito en 5 pasos distintos: Identificación de Requisitos, Análisis de Requisitos y Negociación, Especificación de Requisitos, Modernizado del Sistema, Validación de Requisitos y Gestión de Requisitos.

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-. Esto que parece simple, es muy complicado.

Christel y Kang identifican 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.

Para ayudar a solucionar estos problemas, los ingenieros de sistemas deben aproximarse de una manera organizada a través de reuniones para definir requisitos. Sommerville y Sawyer sugieren un conjunto de actuaciones para la obtención de requisitos, que están descritos en las tareas siguientes:

·         Valorar el impacto en el negocio y la viabilidad técnica del sistema propuesto.

·         Identificar las personas que ayudarán a especificar requisitos y contrastar su papel en la organización.

·         Definir el entorno técnico (arquitectura de computación, sistema operativo, necesidades de telecomunicaciones) en el sistema o producto a desarrollar e integrar.

·         Identificar «restricciones de dominio» (características específicas del entorno de negocio en el dominio de la aplicación) que limiten la funcionalidad y rendimientos del sistema o producto a construir.

·         Definir uno o más métodos de obtención de requisitos (entrevistas, grupos de trabajo, equipos de discusión).

·         Solicitar la participación de muchas personas para que los requisitos se definan desde diferentes puntos de vista, asegurarse de identificar lo fundamental de cada requisito registrado.

·         Identificar requisitos ambiguos como candidatos para el prototipado, y crear escenarios de uso para ayudar a los clientes/usuarios a identificar mejor los requisitos fundamentales.

El resultado alcanzado como consecuencia de la identificación de requisitos variará dependiendo del tamaño del sistema o producto a construir. Para grandes sistemas, el producto obtenido debe incluir:

·         Una relación de necesidades y características.

·         Un informe conciso del alcance del sistema o producto.

·         Una lista de clientes, usuarios y otros intervinientes que deben participar en la actividad de obtención de requisitos.

·         Una descripción del entorno técnico del sistema.

·         Una relación de requisitos (perfectamente agrupados por funcionalidad) y las restricciones del dominio aplicables a cada uno.

·         Un conjunto de escenarios que permiten profundizar en el uso del sistema o producto bajo diferentes condiciones operativas,

·         Cualquier prototipo desarrollado para definir mejor los requisitos.

Cada uno de los productos obtenidos debe ser revisado por las personas que hayan participado en la obtención de sus requisitos.

Análisis de 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?

Es corriente en clientes y usuarios solicitar más de lo que puede realizarse, consumiendo recursos de negocios limitados. También es relativamente común en clientes y usuarios el proponer requisitos contradictorios, argumentando q su visión es “esencial por necesidades especiales”.

El ingeniero del sistema debe resolver estos conflictos a través de un proceso de negociación. Los clientes, usuarios y el resto de intervinientes deberán clasificar sus requisitos y discutir los posibles conflictos según su prioridad. Los riesgos asociados con cada requisito serán identificados y analizados. Se efectúan «estimaciones» del esfuerzo de desarrollo que se utilizan para valorar el impacto de cada requisito en el coste del proyecto y en el plazo de entrega. Utilizando un procedimiento iterativo, se irán eliminando requisitos, se irán combinando y/o modificando para conseguir satisfacer los objetivos planteados.

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. Describe la función y características de un sistema de computación y las restricciones que gobiernan su desarrollo. La especificación delimita cada elemento del sistema. La especificación del sistema describe la información (datos y control) que entra y sale del sistema.

Modelado del sistema

Considere por un momento que a usted se le ha requerido para especificar los requisitos para la construcción de una cocina. Se conocen las dimensiones del lugar, la localización de las puertas y ventanas y el espacio de pared disponible. Debes especificar todos los armarios y electrodomésticos e indicar dónde colocarlos. ¿Será una especificación válida?

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.

Aunque la validación de requisitos puede guiarse de manera que se descubran errores, es útil chequear cada requisito con un cuestionario. Las siguientes cuestiones representan un pequeño subconjunto de las preguntas que pueden plantearse:

• ¿Está el requisito claramente definido? ¿Puede interpretarse mal?

• ¿Está identificado el origen del requisito (por ejemplo: persona, norma, documento)? ¿El planteamiento final del requisito ha sido contrastado con la fuente original?

• ¿El requisito está delimitado en términos cuantitativos?

• ¿Qué otros requisitos hacen referencia al requisito estudiado? ¿Están claramente identificados por medio de una matriz de referencias cruzadas o por cualquier otro mecanismo?

• ¿El requisito incumple alguna restricción definida?

• ¿El requisito es verificable? Si es así, ¿podemos efectuar pruebas (algunas veces llamadas criterios de validación) para verificar el requisito?

• ¿Se puede seguir el requisito en el modelo del sistema que hemos desarrollado?

• ¿Se puede localizar el requisito en el conjunto de objetivos del sistema/producto?

• ¿Está el requisito asociado con los rendimientos del sistema o con su comportamiento y han sido establecidas claramente sus características operacionales? ¿El requisito está implícitamente definido?

Las preguntas planteadas en la lista de comprobación ayudan a asegurar que el equipo de validación dispone de lo necesario para realizar una revisión completa de cada requisito.

Gestión de requisitos

En el capítulo anterior se advertía que los requisitos del sistema cambian y que el deseo de cambiar los requisitos persiste a lo largo de la vida del sistema. 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. En la Figura 10.4 se muestra de forma esquemática este planteamiento. 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ística: 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.

En muchos casos, las matrices de seguimiento se incorporan como parte de un requisito de base de datos y se utiliza para buscar rápidamente los diferentes aspectos del sistema a construir afectados por el cambio de requisito.

Modelado del sistema

Todos los sistemas basados en computadora pueden modelarse como una transformación de la información empleando una arquitectura del tipo entrada-proceso salida. Hatley y Pirbhai han extendido esta visión para incluir dos características adicionales del sistema: tratamiento de la interfaz de usuario y tratamiento del mantenimiento y autocomprobación. Aunque estas características adicionales no están presentes en todos los sistemas basados en computadora, son muy comunes y su especificación hace más robusto cualquier modelo del sistema. Mediante la representación de entrada, proceso, salida, tratamiento de la interfaz de usuario y de autocomprobación, un ingeniero de sistemas puede crear un modelo de componentes de sistema que establezca el fundamento para análisis de requisitos posteriores y etapas de diseño en cada una de las disciplinas de ingeniería.

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.
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 autocomprobación.

Para ilustrar el empleo del DCS, considere una versión ampliada del sistema de clasificación de cinta transportadora (SCCT). Al ingeniero del sistema se le presenta la siguiente declaración (algo confusa) de objetivos para el SCCT:

El sistema SCCT debe desarrollarse de manera que las cajas que se mueven a lo largo de la cinta transportadora sean identificadas y ordenadas en uno de los seis contenedores al final de la cinta. Las cajas pasarán a través de una estación clasificadora donde se identificarán. Basándose en un número de identificación impreso en un lateral de la caja (se proporciona un código de barras equivalente), las cajas se mandarán a los contenedores apropiados. Las cajas pasan aleatoriamente y están igualmente espaciadas. La línea se mueve lentamente.

Para este ejemplo, la versión ampliada utiliza un PC en la estación clasificadora. El PC ejecuta todo el software del SCCT; interacciona con el lector de código de barras para leer parte de los números de cada caja; interacciona con la cinta transportadora vigilando los equipos que controlan velocidad en dicha cinta; almacena todos los números de pieza clasificados; interacciona con el operador de la estación clasificadora para producir una variedad de informes y diagnósticos; envía señales de control al hardware separador para clasificar las cajas; y se comunica con la estructura central de la automatización de la fábrica. En la Figura 10.6 se muestra el DCS para SCCT (ampliado).

Cada caja de la Figura 10.6 representa una entidad externa, es decir, un suministrador o consumidor de información del sistema. Por ejemplo, el lector del código de barras produce información que es introducida en el sistema SCCT. El símbolo para representar todo el sistema (o a niveles más bajos, subsistemas principales) es un rectángulo con las esquinas redondeadas. De ahí que SCCT se represente en la región de proceso y control en el centro del DCS. Las flechas etiquetadas mostradas en el DCS representan información (datos y control) que va desde el entorno exterior al sistema SCCT. La entidad externa lector del código de barras produce una entrada de información etiquetada como código de barras. En esencia, el DCS sitúa a cualquier sistema en el contexto de su entorno exterior.

El ingeniero de sistemas refina el diagrama de contexto de arquitectura estudiando con más detalle el rectángulo sombreado de la Figura 10.6. Se identifican los subsistemas principales que permiten funcionar al sistema clasificador de cinta transportadora dentro del contexto definido por el DCS. En la Figura 10.7 los subsistemas principales se definen en un diagrama de flujo del sistema (DFS) que se obtiene del DCS. El flujo de información a través de las regiones del DCS se traza para guiar al ingeniero de sistemas en el desarrollo de DFS (un «esquema» más detallado del SCCT). El diagrama de flujo de la arquitectura muestra los subsistemas principales y el flujo de las líneas de información &portantes (datos y control). Además, el esquema del sistema divide el proceso del subsistema en cada una de las cinco regiones de proceso estudiadas anteriormente. En este punto, cada uno de los subsistemas puede contener uno o más elementos del sistema (por ejemplo, hardware, software, personas) tal y como los ha asignado el ingeniero de sistemas.

El diagrama inicial de flujo del sistema (DFS) se convierte en el nudo superior de una jerarquía de DFS. Cada rectángulo redondeado del DFS original puede expandirse en otra plantilla de arquitectura dedicada exclusivamente a ella. Este proceso se ilustra esquemáticamente en la Figura 10.8. Cada uno de los DFS del sistema puede usarse como punto de partida de subsiguientes fases de ingeniería para el subsistema que se describe.

Se pueden especificar (delimitar) los subsistemas y la información que fluyen entre ellos para los subsiguientes trabajos de ingeniería. Una descripción narrativa de cada subsistema y una definición de todos los datos que fluyen entre los subsistemas son elementos importantes de la Especificación del Sistema.

Bibliografía:

Pressman .S. Roger. Ingeniería de Software. Un enfoque practico. Editorial McGraw-Hill V Edición. Pág. 165-178