Cliente Servidor

ARQUITECTURA CLIENTE/SERVIDOR

INTRODUCCIÓN

En el mundo de TCP/IP las comunicaciones entre computadoras se rigen básicamente por lo que se llama modelo Cliente-Servidor, éste es un modelo que intenta proveer usabilidad, flexibilidad, interoperabilidad y escalabilidad en las comunicaciones.

 

El término Cliente/Servidor fue usado por primera vez en 1980 para referirse a PC’s en red.

Este modelo Cliente/Servidor empezó a ser aceptado a finales de los 80’s. Su funcionamiento es sencillo: se tiene una máquina cliente, que requiere un servicio de una máquina servidor, y éste realiza la función para la que está programado (nótese que no tienen que tratarse de máquinas diferentes; es decir, una computadora por sí sola puede ser ambos cliente y servidor dependiendo del software de configuración).

DEFINICIÓN:

Sistema distribuido entre múltiples procesadores donde hay clientes que solicitan servicios y servidores que los proporcionan. Separa los servicios situando cada uno en su plataforma más adecuada.

EL MODELO CLIENTE – SERVIDOR

Desde el punto de vista funcional, se puede definir la computación Cliente/Servidor como una arquitectura distribuida que permite a los usuarios finales obtener acceso a la información en forma transparente aún en entornos multiplataforma.

 

En el modelo cliente servidor, el cliente envía un mensaje solicitando un determinado servicio a un servidor (hace una petición), y este envía uno o varios mensajes con la respuesta (provee el servicio).

En un sistema distribuido cada máquina puede cumplir el rol de servidor para algunas tareas y el rol de cliente para otras.

La idea es tratar a una computadora como un instrumento, que por sí sola pueda realizar muchas tareas, pero con la consideración de que realice aquellas que son mas adecuadas a sus características.

Si esto se aplica tanto a clientes como servidores se entiende que la forma más estándar de aplicación y uso de sistemas Cliente/Servidor es mediante la explotación de las PC’s a través de interfaces gráficas de usuario; mientras que la administración de datos y su seguridad e integridad se deja a cargo de computadoras centrales tipo mainframe. Usualmente la mayoría del trabajo pesado se hace en el proceso llamado servidor y el o los procesos cliente sólo se ocupan de la interacción con el usuario (aunque esto puede variar).

En otras palabras la arquitectura Cliente/Servidor es una extensión de programación modular en la que la base fundamental es separar una gran pieza de software en módulos con el fin de hacer más fácil el desarrollo y mejorar su mantenimiento.

Esta arquitectura permite distribuir físicamente los procesos y los datos en forma más eficiente lo que en computación distribuida afecta directamente el tráfico de la red, reduciéndolo grandemente.

CLIENTE / SERVIDOR

Esta arquitectura consiste básicamente en un cliente que realiza peticiones a otro programa (el servidor) que le da respuesta. Aunque esta idea se puede aplicar a programas que se ejecutan sobre una sola computadora es más ventajosa en un sistema operativo multiusuario distribuido a través de una red de computadoras.

En esta arquitectura la capacidad de proceso está repartida entre los clientes y los servidores, aunque son más importantes las ventajas de tipo organizativo debidas a la centralización de la gestión de la información y la separación de responsabilidades, lo que facilita y clarifica el diseño del sistema.

La separación entre cliente y servidor es una separación de tipo lógico, donde el servidor no se ejecuta necesariamente sobre una sola máquina ni es necesariamente un sólo programa. Los tipos específicos de servidores incluyen los servidores web, los servidores de archivo, los servidores del correo, etc. Mientras que sus propósitos varían de unos servicios a otros, la arquitectura básica seguirá siendo la misma.

Una disposición muy común son los sistemas multicapa en los que el servidor se descompone en diferentes programas que pueden ser ejecutados por diferentes computadoras aumentando así el grado de distribución del sistema.

La arquitectura cliente-servidor sustituye a la arquitectura monolítica en la que no hay distribución, tanto a nivel físico como a nivel lógico.

La red Cliente/Servidor es aquella red de comunicaciones en la que todos los clientes están conectados a un servidor, en el que se centralizan los diversos recursos y aplicaciones con que se cuenta; y que los pone a disposición de los clientes cada vez que estos son solicitados. Esto significa que todas las gestiones que se realizan se concentran en el servidor, de manera que en él se disponen los requerimientos provenientes de los clientes que tienen prioridad, los archivos que son de uso público y los que son de uso restringido, los archivos que son de sólo lectura y los que, por el contrario, pueden ser modificados, etc. Este tipo de red puede utilizarse conjuntamente en caso de que se esté utilizando en una red mixta.

¿CUÁNDO IMPLANTAR CLIENTE/SERVIDOR?

1. Cambios estructurales y organizativos.

2. Cambios en organigramas.

3. Respuesta dinámica de mercado.

4. Cambio en procesos de negocio.

¿QUÉ AYUDA A LA IMPLEMENTACIÓN?

1. La demanda de sistemas fáciles.

2. Precio/rendimiento de estaciones y servidores.

3. Creciente acceso a la información para decisiones:

1. Separación datos-programas.
2. Programas flexibles.

4. Nuevas tecnologías de alta productividad.

FUNCIONAMIENTO DEL SISTEMA CLIENTE / SERVIDOR

Un sistema cliente/servidor funciona tal como se detalla en el siguiente diagrama:

ü  El cliente envía una solicitud al servidor mediante su dirección IP y el puerto, que está reservado para un servicio en particular que se ejecuta en el servidor.

ü  El servidor recibe la solicitud y responde con la dirección IP del equipo cliente y su puerto.

CLIENTE

Es el que inicia un requerimiento de servicio. El requerimiento inicial puede convertirse en múltiples requerimientos de trabajo a través de redes LAN o WAN. La ubicación de los datos o de las aplicaciones es totalmente transparente para el cliente. En la arquitectura C/S el remitente de una solicitud es conocido como cliente.

CARACTERÍSTICAS DEL CLIENTE:

1. Es quien inicia solicitudes o peticiones, tienen por tanto un papel activo en la comunicación (dispositivo maestro o amo).
2. Espera y recibe las respuestas del servidor.
3. Por lo general, puede conectarse a varios servidores a la vez.
4. Normalmente interactúa directamente con los usuarios finales mediante una interfaz gráfica de usuario.
5. 5. Al contratar un servicio de redes , se tiene que tener en la velocidad de conexión que le otorga al cliente y el tipo de cable que utiliza , por ejemplo : cable de cobre ronda entre 1 ms y 50 ms.

SERVIDOR

Es cualquier recurso de cómputo dedicado a responder a los requerimientos del cliente. Los servidores pueden estar conectados a los clientes a través de redes, para proveer de múltiples servicios a los clientes y ciudadanos tales como impresión, acceso a bases de datos, fax, procesamiento de imágenes, etc. Al receptor de la solicitud enviada por cliente se conoce como servidor.

CARACTERÍSTICAS DEL SERVIDOR:

1. Al iniciarse esperan a que lleguen las solicitudes de los clientes, desempeñan entonces un papel pasivo en la comunicación (dispositivo esclavo).

2. Tras la recepción de una solicitud, la procesan y luego envían la respuesta al cliente.

3. Por lo general, aceptan conexiones desde un gran número de clientes (en ciertos casos el número máximo de peticiones puede estar limitado).

4. No es frecuente que interactúen directamente con los usuarios finales.

FUNCIONES

CLIENTE:

El cliente es el proceso que permite al usuario formular los requerimientos y pasarlos al servidor, se le conoce con el término front-end.

El Cliente normalmente maneja todas las funciones relacionadas con la manipulación y despliegue de datos, por lo que están desarrollados sobre plataformas que permiten construir interfaces gráficas de usuario (GUI), además de acceder a los servicios distribuidos en cualquier parte de una red.

Las funciones que lleva a cabo el proceso cliente se resumen en los siguientes puntos:

• Administrar la interfaz de usuario.

• Interactuar con el usuario.

• Procesar la lógica de la aplicación y hacer validaciones locales.

• Generar requerimientos de bases de datos.

• Recibir resultados del servidor.

• Formatear resultados.

SERVIDOR:

Es el proceso encargado de atender a múltiples clientes que hacen peticiones de algún recurso administrado por él. Al proceso servidor se le conoce con el término back-end.

El servidor normalmente maneja todas las funciones relacionadas con la mayoría de las reglas del negocio y los recursos de datos.

 Las funciones que lleva a cabo el proceso servidor se resumen en los siguientes puntos:

• Aceptar los requerimientos de bases de datos que hacen los clientes.

• Procesar requerimientos de bases de datos.

• Formatear datos para trasmitirlos a los clientes.

• Procesar la lógica de la aplicación y realizar validaciones a nivel de bases de datos.

ARQUITECTURA CLIENTE/SERVIDOR

CONCEPTOS:

Cualquier combinación de sistemas que pueden colaborar entre sí para dar a los usuarios toda la información que ellos necesiten sin que tengan que saber donde está ubicada.

Es una arquitectura de procesamientos cooperativo donde uno de los componentes pide servicios a otro.

Es un procesamiento de datos de índole colaborativo entre dos o más computadoras conectadas a una red.

El término cliente/servidor es originalmente aplicado a la arquitectura de software que describe el procesamiento entre dos o más programas: una aplicación y un servicio soportante.

IBM define al modelo Cliente/Servidor. "Es la tecnología que proporciona al usuario final el acceso transparente a las aplicaciones, datos, servicios de cómputo o cualquier otro recurso del grupo de trabajo y/o, a través de la organización, en múltiples plataformas. El modelo soporta un medio ambiente distribuido en el cual los requerimientos de servicio hechos por estaciones de trabajo inteligentes o "clientes'', resultan en un trabajo realizado por otros computadores llamados servidores".

"Es un modelo para construir sistemas de información, que se sustenta en la idea de repartir el tratamiento de la información y los datos por todo el sistema informático, permitiendo mejorar el rendimiento del sistema global de información"

CARACTERÍSTICAS DE LA ARQUITECTURA CLIENTE/SERVIDOR:

Ø  Combinación de un cliente que interactúa con el usuario, y un servidor que interactúa con los recursos compartidos. El proceso del cliente proporciona la interfaz entre el usuario y el resto del sistema. El proceso del servidor actúa como un motor de software que maneja recursos compartidos tales como bases de datos, impresoras, módems, etc.

Ø  Las tareas del cliente y del servidor tienen diferentes requerimientos en cuanto a recursos de cómputo como velocidad del procesador, memoria, velocidad y capacidades del disco y input-output devices.

Ø  Se establece una relación entre procesos distintos, los cuales pueden ser ejecutados en la misma máquina o en máquinas diferentes distribuidas a lo largo de la red.

Ø  Existe una clara distinción de funciones basada en el concepto de "servicio", que se establece entre clientes y servidores.

 

Ø  La relación establecida puede ser de muchos a uno, en la que un servidor puede dar servicio a muchos clientes, regulando su acceso a recursos compartidos.

 

Ø  Los clientes corresponden a procesos activos en cuanto a que son éstos los que hacen peticiones de servicios a los servidores. Estos últimos tienen un carácter pasivo ya que esperan las peticiones de los clientes.

Ø  No existe otra relación entre clientes y servidores que no sea la que se establece a través del intercambio de mensajes entre ambos. El mensaje es el mecanismo para la petición y entrega de solicitudes de servicio.

Ø  El ambiente es heterogéneo. La plataforma de hardware y el sistema operativo del cliente y del servidor no son siempre la misma. Precisamente una de las principales ventajas de esta arquitectura es la posibilidad de conectar clientes y servidores independientemente de sus plataformas.

 

Ø  El concepto de escalabilidad tanto horizontal como vertical es aplicable a cualquier sistema Cliente/Servidor. La escalabilidad horizontal permite agregar más estaciones de trabajo activas sin afectar significativamente el rendimiento. La escalabilidad vertical permite mejorar las características del servidor o agregar múltiples servidores.

MODELO DE ARQUITECTURA CLIENTE/SERVIDOR

Front/end : Es la parte de la aplicación que interactúa con el usuario. Basados en una interfaz gráfica con el usuario (GUI). El Cliente corre la aplicación que ofrece la interfaz con el usuario.

Back/end: Es la parte no-interactiva de la aplicación. La mayor parte reside en las Bases de Datos (relacionales o no).

APLICACIONES SIMPLES

No requieren una gran Base de Datos compartida, pueden ser elaboradas solamente en el Cliente.

APLICACIONES COMPLEJAS

Exigen dos capas, una para la aplicación del usuario (Cliente) y otra para la base de datos (Servidor).

VENTAJAS DEL MODELO CLIENTE SERVIDOR

1. Uno de los aspectos que más ha promovido el uso de sistemas Cliente/Servidor, es la existencia de plataformas de hardware cada vez más baratas.

 

2. El esquema Cliente/Servidor facilita la integración entre sistemas diferentes y comparte información permitiendo, por ejemplo que las máquinas ya existentes puedan ser utilizadas pero utilizando interfaces mas amigables al usuario.

 

3. Al favorecer el uso de interfaces gráficas interactivas, los sistemas construidos bajo este esquema tienen mayor interacción más intuitiva

con el usuario.

4. Es más rápido el mantenimiento y el desarrollo de aplicaciones, pues se pueden emplear las herramientas existentes (por ejemplo los servidores de SQL o las herramientas de más bajo nivel como los sockets o el RPC ).

La estructura inherentemente modular facilita además la integración de nuevas tecnologías y el crecimiento de la infraestructura computacional, favoreciendo así la escalabilidad de las soluciones.

 

El esquema Cliente/Servidor contribuye además, a proporcionar, a los diferentes departamentos de una organización, soluciones locales, pero permitiendo la integración de la información relevante a nivel global.

BIBLIOGRAFÍA

es.wikipedia.org/wiki/Cliente-servidor

www.monografias.com/trabajos24/arquitectura-cliente-servidor/arquitectura-cliente-servidor.shtml

www.desarrolloweb.com/articulos/arquitectura-cliente-servidor.html

www.csae.map.es/csi/silice/Global71.html

temariotic.wikidot.com/la-arquitectura-cliente-servidor

Caso de Estudio C/S:

La Empresa “Autónica” es una empresa Nicaragüense que se dedica a vender repuestos automotrices, esta tiene su sede principal en Managua con sucursales en Estelí, Chinandega y en Rivas, dicha empresa desea implementar un sistema de ventas en línea y quiere conservar su información automatizada y bien organizada entre todas sus sucursales, mediante la implementación de un modelo C/S para esto se requiere:

1)    Modelo de Negocio

Entradas

Datos del Cliente: Los datos del cliente serán ingresados por el sistema, con el objetivo de mantener un control de los clientes. En el momento en que un cliente realiza un pedido sus datos personales son solicitados y almacenados, dichos datos son los siguientes: Nombre, Apellido, Departamento, Dirección y Correo electrónico. Y un Id_cliente que es asignado por el sistema.

Datos del Vehículo: Cuando el cliente decide realizar una compra debe seleccionar los datos del vehículo si dichos datos coinciden con los vehículos disponibles se realiza la solicitud de repuesto entre los datos del vehículo solicitados son: año del vehículo, marca, modelo y se solicita el número de chasis.

Datos del Repuesto: El cliente debe seleccionar el o los repuestos que necesita, seleccionando de una lista presentada por el sistema, dichos datos son: nombre del repuesto, cantidad y color (si es necesario). Solamente se solicitaran estos datos ya que la marca y modelo quedan almacenados anteriormente.  

Procesos

Registrar Cliente: En cada venta se solicitan los datos generales del cliente esto para hacer más sencillo el proceso de facturación en próximas ventas. Los datos solicitados a cada cliente son: nombre, apellido, departamento, dirección, correo electrónico y un código que es proporcionado por el sistema. En el caso de ser un cliente cuyos datos ya fueron  almacenados en la BD estos solo serán verificados y actualizados.

Registrar Datos de Vehículo: El registro de vehículo lo realiza únicamente el administrador del sistema, si se trata de un dato de vehículo nuevo se solicita la ubicación del dato ya sea: año del vehículo, marca, modelo, etc. y se almacenan los datos.

Registrar Repuestos: El registro de repuestos lo realiza únicamente el administrador del sistema, si se tratase de un repuesto nuevo se almacena el nombre del repuesto, color si lo amerita y un código que solo será visible para el administrador.

Registro de Factura de Venta: En los registros de la factura de venta se almacenan los datos del cliente, vehículo, y los datos del repuesto, además de la cantidad de repuestos comprados para realizar el cálculo y agregar el pago realizado.

Salidas

Factura de Ventas: Esta factura debe reflejar la fecha en que se realizó la venta, a su vez la cantidad del repuestos vendidos y la descripción de estos (nombre y color), también deben los datos del cliente (Código, nombre y apellido), los datos del vehículo (año del vehículo, marca, modelo y numero de chasis), se debe indicar si se realizó algún tipo de descuento y el porcentaje de este, además se deben realizar los cálculos del pago y el pago total. Dicha factura de ventas es emitida por el sistema en el departamento en que se realizará la entrega y ser entregada al cliente por el sistema de envío.     

Sala Limpia del Software

Es un enfoque que hace hincapié en la necesidad de incluir la corrección en el software a medida que éste se desarrolla.

Consiste en la edición de dependencias de costosos procesos de eliminación de defectos, mediante la escritura de incrementos de código desde su primer momento.

Su modelo de proceso incluye la certificación estadística de calidad de los incrementos de código, a medida que estos se van acumulando en el sistema.

Demanda la disciplina necesaria para eliminar errores en las especificaciones y diseño, fabricando el producto de forma limpia. Propuesta por Mills y sus colegas. Henderson sugiere tres razones:

•1. La creencia consistente en que la metodología de sala limpia es excesivamente teórica, matemática y radical para utilizarla en el desarrollo de software real.

•2. No propone una comprobación unitaria por parte de los desarrolladores, sino  que la sustituye por un control estadístico de la calidad.

•3. El uso de los procesos de sala limpia requiere procesos definidos  en las fases del ciclo vital.

•Hace uso del modelo incremental del software

•Asignada la funcionalidad el tubo de sala limpia comienza sus incrementos

•Los requisitos globales del sistema se desarrollan empleando los métodos de software

•Desarrolla un tubo de incremento de software

 

 

Tareas:

 

•Planificación de incrementos: Se desarrolla un plan de proyecto que adopta la estrategia incremental. Se establecen las funcionalidades de los incrementos, tamaño estimado y un plan de desarrollo de sala limpia de cada uno.

•Recolección de requisitos: Mediante el uso de técnicas  se desarrolla una descripción de los requisitos a nivel de usuario.

•Especificación de la estructura de cajas: Se utiliza un método de especificación que hace uso de la estructura de caja para describir la especificación funcional, donde se aísla y separa  la definición de los datos  para cada nivel de refinamiento.

•Diseño formal: El diseño de sala limpia es una extensión natural y sin discontinuidades de la especificación. Las especificaciones (cajas negras) se refinan iterativamente para transformarse en diseños análogos  a la arquitectura  y a los procedimientos (cajas  de estado y cajas transparentes) respectivamente.

 

•Verificación de corrección: El equipo de sala limpia lleva a cabo actividades de verificación de corrección aplicadas al diseño y al código. La verificación comienza con la estructuras de cajas de alto nivel y avanza hacia el diseño y el código.

•Generación de código, inspección y verificación: La especificaciones de estructura de caja, que se representan mediante un lenguaje especializado, se traduce al lenguaje de programación adecuado.

•Planificación de la comprobación estadística: La utilización del software se analiza , se planifica y se diseña un conjunto de casos de pruebas que ejerciten la distribución de probabilidad de la utilización.

•Comprobación estadística de utilización: Las técnicas estadísticas de utilización ejecutan un conjunto finito de casos de prueba.

 

Qué hace diferente la sala limpia?

1. Hace uso explícito del control estadístico de calidad.

2. Verifica la especificación del diseño empleando una demostración de corrección basada en las matemáticas 

 

 

3. Hace uso de la comprobación estadística de utilización para descubrir errores de especial incidencia.

 

 

Se utilizan tres tipos de cajas:

 

Caja negra: Especifica el comportamiento del sistema.

  Caja de estado: Encapsula los datos de estados  y de servicios de forma análoga a los objetos.

Caja transparente: Contiene el diseño de procedimientos correspondiente a la caja de estados.

  

Certificacion:

 

•3. Se generan casos de prueba a partir del perfil

•1. Es preciso crear escenarios de utilización

•4. Se ejecutan pruebas y los datos de los fallos se registran

•5. Se calcula y se certifica la fiabilidad

•2. Se especifica un perfil de utilización

 

Requeire de 3 Modelos:

•Modelo de muestreo : Ejecuta m casos de pruebas aleatorias y especifica si produce ó no un fallo.

•Modelo de componentes: Certifica un sistema de n componentes  y determina la probabilidad de fallo del componente i.

•Modelo de certificación: Estima y certifica la fiabilidad global del sistema. 

 

La ingeniería del software de sala limpia  es un enfoque formal para el desarrollo de software de calidad alta.

El resultado final son unas tasas de fallos bajas difíciles de conseguir empleando métodos menos formales.

 

 

 

 

 

 

 

 

Reingenieria

Caso de Estudio

La fábrica de accesorios militares el jaguar  http://www.accesoriosmilitareseljaguar.com desea hacer una modificación en sus procesos. Para ello ha contratado los servicios de usted como Ingeniero(a) del software, y se considera que como usted es una persona actualizada, aplicará el método de Reingeniería del software (análisis, reestructuración, ingeniería inversa, ingeniería directa) iniciando desde su sitio web hasta obtener los novedosos requerimientos.

 

Análisis:

En el sitio web de la fábrica de accesorios militares el jaguar, se encontró que solo cuenta con tipos de información: primero una bienvenida a la pagina, su misión, algunos productos (específicamente solo 12) y  un enlace a un documento con la descripción de los productos sin su precio, un formulario que se llena con datos personales y la consulta a realizar, el cual se abre en una página en blanco.

Reestructuración:

En esta página hay dos enlaces que muestran  una misma información (home, quienes somos), lo cual representa un mal diseño ya que solo debería de establecer uno solo.

También  el enlace donde deberían de aparecer los precios solo muestra la descripción de los productos y no lo que indican.

A las imágenes se les podría agregar una descripción de producto  con  su respectivo  precio, y así hacer que la pagina sea más atractivo y más rápido de navegar para el usuario.

Contáctenos

Quienes Somos:

  Productos: 

Ingeniería Directa

En este tipo de ingeniería se necesita modificar detalladamente mas la información que los clientes desean y lo que les  interesa visualizar, así como una lista de productos con sus respectivos precios, este sistema de información también tiene muchas debilidades conforme al diseño y de cómo está estructurado la pagina web, osea no tiene un orden cronológico, no tiene mucha variedad de productos, no sale una buena descripción sobre su empresa…

Ingenieria de Sistemas

Introducción

En este parte de ingeniería de software consideramos los conceptos técnicos, métodos y mediciones que son aplicables al análisis, diseño y pruebas del software.
La ingeniería del software aparece como consecuencia de un proceso denominado ingeniería de sistemas. En lugar de centrarse únicamente en el software, la ingeniería de sistemas se centra en diversos elementos, analizando, diseñando y organizando esos elementos en un sistema que pueden ser un producto, un servicio o una tecnología para la transformación de información o control de información.
El proceso de ingeniería de sistemas es denominado ingeniería de procesos de negocio cuando el contexto del trabajo de ingeniería se enfoca a una empresa. Cuando hay que construir un producto, el proceso se denomina ingeniería de producto. Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desarrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de aplicación diferente, ambas intentan poner al software en su contexto.
¿Qué es ingeniería de Sistema?
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 por que 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
Sistema Basado en Computadora
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 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 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 del 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: Una visió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.
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.

Jerarquía de la ingeniería  de Procesos

Como muestra la Figura, 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 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.

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 apropiada 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 diseño del sistema del negocio. 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.

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)

ž  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

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

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

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

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.

 

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. 

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