INGENIERÍA DE SISTEMAS

El proceso de ingeniería de sistemas es denominada ingeniería de procesos de negocios cuando el contexto del trabajo de ingeniería se enroca a una empresa.

Que es ingeniería en sistemas?

Antes de que el software se puede construir,se deben definir los objetivos generales del sistema; 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.  

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

La meta de la  ingeniería de procesos de negocios (IPN) es definir arquitecturas que permitan que un negocio utilice información de manera efectiva. Cuando las necesidades de tecnología de información de una compañía se observan de manera global, casi no hay duda de que se requiera la ingeniería de sistemas. No sólo se requiere la especificación de la arquitectura de cómputo apropiada, sino también se debe desarrollar la arquitectura de software que puebla la configuración única de fuentes de cómputo de la organización. La ingeniería de procesos de negocios es un enfoque que crea un plan general para implementar la arquitectura de cómputo.

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

Arquitectura de datos

Arquitectura de aplicaciones

Infraestructura de la tecnología

La  arquitectura de datos  proporciona un marco de trabajo para las necesidades de información de un negocio o de una función de negocios. Los ladrillos de la arquitectura son los objetos de datos que utiliza el negocio. Un objeto  de los datos contiene un conjunto de atributos que define algún aspecto, cualidad, característica o descriptor de los datos que se describen.

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

La  arquitectura de aplicación  abarca aquellos elementos de un sistema que transforman objetos dentro de la arquitectura de datos por algún propósito del negocio. En el contexto de este libro se considera que la arquitectura de aplicación es el sis tema de programas (software) que realiza esta transformación. Sin embargo, en un contexto más amplio, la arquitectura de aplicación puede incorporar el papel de las personas quienes son transformadores y usuarios de información) y procedimientos de negocios que no han sido automatizados.

En la figura  se define e ilustra una jerarquía de proceso de negocios para 

modelar estas arquitecturas de sistema:

La  infraestructura tecnológica  proporciona el fundamento para las estructuras de datos y de aplicación. La infraestructura comprende el hardware y el software con que se apoyan las aplicaciones y los datos. Esto incluye computadoras, sistemas de operación, redes de computadora, enlaces de telecomunicaciones, tecnologías de almacenamiento y la arquitectura (por ejemplo, cliente, servidor) diseñada para implementar estas tecnologías.

INGENIERÍA DE PRODUCTO: UNA VISIÓN GENERAL

La meta de la  ingeniería de producto  es traducir el deseo del cliente, de una serie de capacidades definidas, a un producto del trabajo. Para conseguir esta meta la ingeniería de producto  —como la ingeniería de procesos de negocios debe crear una arquitectura y una estructura. La arquitectura abarca cuatro componentes de sistema distintos: software, hardware, datos (y bases de datos) y personas. Se establece una infraestructura de soporte e incluye la tecnología requerida para unir los componentes y la información (como documentos,CD-ROM, video) que se emplea para dar soporte a los componentes.

 La visión global se consigue mediante 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, desempeño general del producto, diseño, restricciones de la interfaz y otras necesidades especiales. Una vez que se conocen estos requisitos, el trabajo de la ingeniería de requisitos es asignar función y comportamiento a cada uno de los cuatro componentes antes descritos.Una vez hecha la asignación comienza la ingeniería de componentes del sistema. 

La ingeniería de componentes del sistema es en realidad un conjunto de actividades concurrentes que dirige por separado cada uno de los componentes del sistema: ingeniería de software, ingeniería de hardware, ingeniería humana e ingeniería de bases de datos. Cada una de estas disciplinas de ingeniería toma una visión de dominio específica, pero es importante señalar que las disciplinas de ingeniería deben establecer y mantener una comunicación activa entre ellas. Parte del papel de la ingeniería de requisitos es establecer los mecanismos de interfaz que permitan que esto suceda.

La visión de elemento para la ingeniería de producto es la disciplina de ingeni ería aplicada a un componente asignado. Para la ingeniería de software esto significa actividades de modelado del análisis y diseño (cubierto en detalle en capítulos posteriores) y actividades de construcción  y  despliegue que abarcan: generación de código, pruebas y tareas de soporte. Los modelos de análisis de tareas asignan requisitos a las representaciones de datos, función y comportamiento. El diseño convierte el modelo de análisis en diseños de datos, arquitectónicos, de interfaz y en el nivel  de componentes del software.

La jerarquía de la ingeniería de productos.

MODELADO DEL SISTEMA

Debido a que un sistema puede representarse con diferentes grados de abstracción (por ejemplo, la visión global, la visión de dominio, la visión de elemento), los modelos de sistema  tienden a ser jerárquicos o estratificados por naturaleza. En la parte más alta de la jerarquía se presenta un modelo del sistema completo (la visión global). 

Los objetos principales de datos, las funciones de procesamiento y los comportamientos se representan sin incluir el componente del sistema que implementará  los elementos del modelo de visión global. A medida que la jerarquía se refina o estratifica se modela el detal le al nivel de componentes (en este caso, representaciones de hardware, software, etcétera). Al final, los modelos de sistemas evolucionan a modelos de ingeniería (los cuales se refinan después) que son específicos para  la disciplina de ingeniería apropiada.

Modelado  del  sistema  con UML

El UML proporciona una cantidad impresionante de diagramas que pueden utilizarse para el análisis y diseño al nivel de software y del sistema.Para el SCCT se modelan cuatro elementos importantes del sistema: 1) el hardware que permit e el SCCT; 

2) el software que implementa el acceso a la base de datos y la clasificación; 3) el 

operador que acata varias peticiones del sistema; y 4) la base de datos que contiene información relevante del código de barras y el destino.

El hardware del SCCT se puede modelar en el nivel del sistema mediante un diagrama de despliegue  de UML, como se ilustra en la figura 6.6. Cada caja tridimensional muestra un elemento del hardware que es parte de la arquitectura física del sistema. En algunos casos, los elementos del hardware tendrán que diseñarse y construirse como parte del proyecto. Sin embargo, en muchos casos los elementos del hardware se pueden adquirir ya construidos. El reto para el equipo de ingeniería es realizar la interfaz de los elementos del hardware de manera apropiada.

Los elementos del software para el SCCT se pueden modelar en una variedad de formas mediante el uso de UML. Los aspectos de procedimiento del software del SCCT se pueden representar mediante un  diagrama de  actividad. Esta notación del UML es similar al diagrama de flujo y se utiliza para representar lo que sucede mientras el sistema realiza sus funciones. Los rectángulos redondeados implican una función específica del sistema; las flechas representan el flujo a través del sistema; el rombo de decisión representa una decisión ramificada (cada flecha que sale del rombo está etiquetada); las líneas sólidas horizontales implican la realización de actividades en paralelo.

Otra notación de UML que se puede usar para modelar software es el diagrama de clase  (junto con muchos diagramas relacionados con las clases que se examinan en apartados posteriores de este libro). En el nivel de la ingeniería del sistema las clasespodrían ser de: caja, línea de conducción, lector de código de barras, controlador de maniobras, solicitud del operador, reporte, producto  y otras. Cada clase encapsula un conjunto de atributos que representa toda la información necesaria acerca de la clase. Una descripción de clase también contiene un conjunto de operaciones que se aplican a la clase en el contexto del sistema SCCT. En la figura 6.8 se muestra un diagrama de clase de UML la clase caja.

El operador del SCCT se puede modelar con un diagrama de UML de tipo casos de uso como se muestra en la figura 6.9. El diagrama de caso de uso ilustra la forma en la que un actor (en este caso el operador que se representa con una figura adherida) interactúa con el sistema. Cada óvalo etiquetado dentro de la caja (la cual representa la frontera del sistema SCCT) implica un caso de uso —un escenario escrito que describe una interacción con el sistema.