Ingeniería de Sistemas

  

Ingeniería de Sistema

¿Qué es Ingeniería de Sistemas?

Antes de que el software se pueda construir, el sistema en el que residirá se debe comprender. Para lograrlo, se deben definir los objetivos generales del sistema; se debe identificar el papel del hardware, software, personas, bases de datos, procedimientos y otros elementos del sistema; y los requerimientos operacionales deben ser identificados; analizados, especificados, modelizados, validados y gestionados. Estas actividades son la base de la ingeniería de sistemas.

¿Quién lo hace?

Un ingeniero de sistema que trabaja para comprender los requisitos del sistema en colaboración con el cliente, los futuros usuarios y otras partes interesadas.

¿Por qué es importante?

        Son importante porque generan elementos tecnológicos que para realizar este sistema en el que ayuda enormemente a la generación del software.

¿Cuáles son los pasos?

Los objetivos y los requisitos operacionales de mayor detalle son identificados gracias a la información facilitada por el cliente. Los requisitos son analizados para valorar su claridad, completitud y consistencia. Una especificación incorporada a un modelo de sistema, se crea y valida posteriormente por los clientes y las partes interesadas. Finalmente, los requisitos del sistema son gestionados para asegurar que los cambios se controlan adecuadamente.

   ¿Cuál es producto obtenido?

Se debe obtener una correcta representación del sistema como consecuencia de la ingeniería de sistema. Se puede realizar a través de un prototipo, una especificación o incluso un modelo simbólico, debiendo comunicar la operativa, la funcionalidad y las características de comportamiento del sistema que se va construir e incorporarlo dentro de la arquitectura del sistema.

¿Cómo puedo estar seguro de que lo he hecho correctamente?

El producto obtenido, a través de la aplicación de la ingeniería de sistemas, debe ser revisado para determinar su claridad, completitud y consistencia. Es importante que los cambios en los requisitos de un sistema sean gestionados utilizando métodos sólidos.

Sistemas Basados 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.

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.

  

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 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.

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 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.

En algunos casos, los macro elementos 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 (macro elementos).

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. 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 de Proceso

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.

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.

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 de Sistema

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. 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

El objetivo de la ingeniería de proceso de negocio (ZPN) es definir arquitecturas que permitan a las empresas emplear la información eficazmente.

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 la 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:

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. 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.

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.

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)

·        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.

Jerarquía de la ingeniería del producto

        Como se muestra en la Figura (jerarquía de la ingeniería del producto), 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 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.

        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.

        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. 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, Modelizado 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.

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

                                                

¿Por qué es tan difícil obtener un planteamiento claro de lo que

necesita el cliente?

·        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.

·        crear escenarios de uso para ayudara 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. los métodos de obtención de 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 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.

¿Qué cuestiones deben ser preguntadas y contestadas durante el análisis de requisitos?

·        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?

·        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.

Especificaciones 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 de Sistema

Considérese por un momento que se le ha requerido 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

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.

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.

Todos los sistemas basados en computadora pueden modelarse como una transformación de la información empleando una arquitectura del tipo entrada-proceso salida.

La 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.