ISW-S10-Ingeniería de Sistemas

INGENIERÍA DEL SOFTWARE

C A P Í T U L O 2 : M É T O D O S

C O N V E N C I O N A L E S P A R A L A

I N G E N I E R Í A D E L S O F T W A R E

I S T P - K H I P U

W I L B E R T D A L G U E R R E

O R D Ó Ñ E Z

2 0 1 3 - I

SESIÓN NÚMERO 10

INGENIERÍA DE

SISTEMAS Conocer el Proceso de la Ingeniería de Sistemas.

Ingeniería de Sistemas

1

Contenido

INGENIERÍA DE SISTEMAS .......................................................................... 2

LA JERARQUÍA DE LA INGENIERÍA DE SISTEMAS .................................................................. 5

Modelado del sistema .......................................................................................................... 5

Simulación del sistema ......................................................................................................... 7

INGENIERÍA DEL PROCESO DEL NEGOCIO ............................................................................ 8

INGENIERÍA DEL PRODUCTO .............................................................................................. 10

INGENIERÍA DE REQUISITOS ............................................................................................... 12

1. Identificación de requisitos ........................................................................................ 12

2. Análisis y negociación de requisitos ........................................................................... 14

3. Especificación de requisitos ....................................................................................... 15

4. Modelado del sistema ................................................................................................ 15

5. Validación de requisitos ............................................................................................. 16

MODELADO DEL SISTEMA .................................................................................................. 17

BIBLIOGRAFÍA ................................................................................................................ 21


2

INGENIERÍA DE SISTEMAS

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.

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;


3

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.

Tomando prestada la definición del diccionario Webster, definimos un

sistema basado en computadora como: Un conjunto o disposición de

elementos que están organizados para realizar un objetivo predefinido

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.


4

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 almacenado); documentación y

procedimientos.

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 podrían ser manejadas por el

mismo operador (el elemento personas). En otros casos, los elementos

genéricos son exclusivos de un sistema.

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.


5

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

LA JERARQUÍA DE LA INGENIERÍA DE SISTEMAS

La ingeniería de sistemas comprende una colección de métodos para

navegar de arriba abajo y de abajo arriba en las siguientes

características. 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:

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

en consideración;

2. representen el comportamiento de los procesos y los supuestos

en los que se basa el comportamiento;

3. definan explícitamente las entradas exógenas y endógenas de

información al modelo;

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


6

1. Supuestos que reducen el número de permutaciones y

variaciones posibles, permitiendo así al modelo reflejar el

problema de manera razonable. Por ejemplo, considere un

producto de representación en tres dimensiones usado por la

industria de entretenimiento para crear animaciones realistas. Un

dominio del producto permite la representación de formas

humanas en 3D. Las entradas a este dominio comprenden la

habilidad de introducir movimiento de un «actor» humano vivo,

desde vídeo o creando modelos gráficos. El ingeniero del sistema

hace ciertos supuestos sobre el rango de movimientos humanos

permitidos (por ejemplo, las piernas no pueden enrollarse

alrededor del tronco) de manera que puede limitarse el proceso y

el rango de entradas.

2. Simplificaciones que permiten crear el modelo a tiempo. Para

ilustrarlo, considere una compañía de productos de oficina que

vende y suministra una amplia variedad de fotocopiadoras, faxes

y equipos similares. El ingeniero del sistema está modelando las

necesidades de la organización suministradora y está trabajando

para entender el flujo de información que engendra una orden de

suministro. Aunque una orden de suministro puede generarse

desde muchos orígenes, el ingeniero categoriza solamente dos

fuentes: demanda interna o petición externa. Esto permite una

partición simplificada de entradas necesaria para generar una

orden de trabajo.

3. Limitaciones que ayudan a delimitar el sistema. Por ejemplo, se

está modelando un sistema de aviónica para un avión de próxima

generación. Como el avión tendrá un diseño de dos motores,

todos los dominios de supervisión de la propulsión se modelarán

para albergar un máximo de dos motores y sus sistemas

redundantes asociados.

4. Restricciones que guían la manera de crear el modelo y el

enfoque que se toma al implementar el modelo. Por ejemplo, la

infraestructura tecnológica para el sistema de representación en

tres dimensiones descrita anteriormente es un solo procesador

basado en un Power-PC. La complejidad de cálculo de los

problemas debe restringirse para encajar en los límites de

proceso impuestos por el procesador.


7

5. Preferencias que indican la arquitectura preferida para todos los

datos, funciones y tecnología. La solución preferida entra a veces

en conflicto con otros factores restrictivos. Aunque la satisfacción

del cliente es a menudo tomada en cuenta hasta el punto de

realizar su enfoque preferido. El modelo de sistema resultante

(desde cualquier visión) puede reclamar una solución

completamente automática, semiautomática o un enfoque manual.

De hecho, es posible a menudo caracterizar modelos de cada tipo

que sirven de soluciones alternativas para el problema que

tenemos entre manos. En esencia, el ingeniero del sistema

modifica simplemente la influencia relativa de los diferentes

elementos del sistema (personas, hardware, software) para crear

modelos de cada tipo.

Simulación del sistema

En los años 60, R.M. Graham hizo un comentario crítico sobre la

manera en que se construían los sistemas basados en computadora:

«Construimos sistemas igual que los hermanos Wright construían

aviones: construimos todo el sistema, lo empujamos barranco abajo,

le dejamos que se estrelle y empezamos de nuevo.» De hecho, para

al menos un tipo de sistema (el sistema reactivo) lo continuamos

haciendo hoy en día. Muchos sistemas basados en computadora

interaccionan con el mundo real de forma reactiva. Es decir, los

acontecimientos del mundo real son vigilados por el hardware y el

software que componen el sistema, y basándose en esos sucesos, el

sistema aplica su control sobre las máquinas, procesos e incluso las

personas que motivan los acontecimientos. Los sistemas de tiempo

real y sistemas empotrados pertenecen a menudo a la categoría de

sistemas reactivos. Desgraciadamente, los desarrolladores de

sistemas reactivos luchan a veces para hacerlos funcionar

correctamente. Hasta hace poco, ha sido difícil predecir el

rendimiento, la eficacia y el comportamiento de estos sistemas antes

de construirlos. Realmente, la construcción de muchos sistemas de

tiempo real era una aventura. Las sorpresas (la mayoría

desagradables) no se descubrían hasta que el sistema era construido

y «arrojado colina abajo». Si el sistema se estrellaba debido a un

funcionamiento incorrecto, comportamiento inapropiado o escaso

rendimiento, cogíamos las piezas y empezábamos de nuevo. Muchos

sistemas de la categoría de los reactivos controlan máquinas y/o

procesos (por ejemplo, aerolíneas comerciales o refinerías de


8

petróleo) que deben operar con extrema fiabilidad. Si el sistema falla,

podrían ocurrir pérdidas económicas o humanas significativas. Por

este motivo, el enfoque descrito por Graham es penoso y peligroso.

Hoy en día se utilizan herramientas software para el modelado y

simulación de sistemas para ayudar a eliminar sorpresas cuando se

construyen sistemas reactivos basados en computadora. Estas

herramientas se aplican durante el proceso de ingeniería de sistemas,

mientras se están especificando las necesidades del hardware,

software, bases de datos y de personas. Las herramientas de

modelado y simulación capacitan al ingeniero de sistemas para probar

una especificación del sistema.

INGENIERÍA DEL PROCESO DEL NEGOCIO

El objetivo de la ingeniería de

proceso de

negocio (IPN) es

definir arquitecturas

que permitan a las

empresas emplear la

información

eficazmente. Michael

Guttman describe el desafío cuando dice: El

actual entorno computacional consiste en un poder de

computación distribuido en toda la empresa con múltiples unidades

diferentes de procesamiento, dividido y configurado por una amplia

variedad de tareas, Nuevos planteamientos como la computación

cliente-servidor, procesamiento distribuido, el trabajo en red (por

nombrar algunos de los términos más sobreusados) permiten

gestionar las demandas aportando mayor funcionalidad y flexibilidad.

Sin embargo, el coste de estos cambios es ampliamente discutido por

las organizaciones de TI (Tecnologías de la Información) que deben

soportar esta políglota configuración. Hoy, cada organización de TI

debe favorecer la integración de sus sistemas. Debe diseñar,

implementar y soportar su propia configuración de recursos de

computación heterogénea, distribuidos lógica y geográficamente por

toda la empresa, conectándola a través de un esquema apropiado

para el trabajo en red. Por otra parte, esta configuración debe ser

diseñada para cambios continuos, desigualmente localizados en la


9

empresa, debido a cambios en requisitos del negocio y en las propias

tecnologías. Estos diversos e incrementales cambios deben ser

coordinados a través del entorno distribuido, consistente en hardware

y software suministrado por decenas, cuando no cientos, de

vendedores. Por supuesto, esperamos que estos cambios los

incorporemos sin ruptura con la operativa habitual permitiendo

además ampliar la operativa. Cuando hablamos de una visión general

de las necesidades de tecnología de información de una compañía,

existen pequeñas incertidumbres que son planteadas a ingeniería de

sistemas. La ingeniería de proceso de negocio es un acercamiento

para crear un plan general para implementar la arquitectura de

computación se deben analizar y diseñar tres arquitecturas diferentes

dentro del contexto de objetivos y metas de negocio: arquitectura de

datos arquitectura de aplicaciones infraestructura de la tecnología

La arquitectura de datos proporciona una estructura para las

necesidades de información de un negocio o de una función de

negocio. Los ladrillos de la arquitectura son los objetos de datos que

emplea la empresa. Un objeto de datos contiene un conjunto de

atributos que definen aspectos, cualidades, características o

descriptor de los datos que han sido descritos. Por ejemplo, un

ingeniero de la información puede definir el objeto de datos: cliente.

Para describir más en detalle al cliente, se definen los siguientes

atributos:

Objeto: Cliente

Atributos: nombre

nombre de la compañía

clasificación del trabajo y autoridad en compra

dirección comercial e información de contacto

producto(s) de interés

compra(s) anteriores

fecha de último contacto

situación del contacto

Una vez definido el conjunto de datos, se identifican sus relaciones.

Una relación indica como los objetos están conectados. Como

ejemplo, considerar los objetos: cliente y producto A. Los dos objetos


10

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 las funciones de

negocio, están organizados dentro de una base de datos y se

transforman para proveer información que sirva a las necesidades del

negocio.

La arquitectura de aplicación comprende aquellos elementos de un

sistema que transforman objetos dentro de la arquitectura de datos

por algún propósito del negocio. En el contexto de este libro,

consideramos normalmente que la arquitectura de aplicación es el

sistema de programas (software) que realiza esta transformación. Sin

embargo, en un contexto más amplio, la arquitectura de aplicación

podría incorporar el papel de las personas (por ejemplo, cliente

servidor) que ha sido diseñado para implementar estas tecnologías.

La infraestructura tecnológica proporciona el fundamento de las

arquitecturas de datos y de aplicaciones. La infraestructura

comprende el hardware y el software empleados para dar soporte a

las aplicaciones y datos. Esto incluye computadoras y redes de

computadora, enlaces de telecomunicaciones, tecnologías de

almacenamiento y la arquitectura (por ejemplo, cliente servidor)

diseñada para implementar estas tecnologías.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.

INGENIERÍA DEL PRODUCTO

La meta de la ingeniería de producto es traducir el deseo de un

cliente, de un conjunto de capacidades definidas, a un producto

operativo. Para conseguir esta meta, la ingeniería de producto (como

la ingeniería de proceso de negocio) debe crear una arquitectura y

una infraestructura. La arquitectura comprende cuatro componentes

de sistema distintos: software, hardware, datos (bases de datos) y

personas.


11

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. La visión global se consigue a través de la ingeniería

de requisitos. Los requisitos generales del producto se obtienen del

cliente. Estos requisitos comprenden necesidades de información y

control, funcionalidad del producto y comportamiento, rendimiento

general del producto, diseño, restricciones de la interfaz y otras

necesidades especiales. Una vez que se conocen estos requisitos, la

misión del análisis del sistema es asignar funcionalidad y

comportamiento a cada uno de los cuatro componentes mencionados

anteriormente.

Una vez que se ha hecho la asignación, comienza la ingeniería de

componentes del sistema. La ingeniería de componentes del sistema

es, de hecho, un conjunto de actividades

concurrentes que se dirigen separadamente a

cada uno de los componentes del sistema: la

ingeniería del software, ingeniería hardware,

ingeniería humana e ingeniería de bases de datos.

Cada una de estas disciplinas de ingeniería toma

una vista de dominio específica, pero es

importante resaltar que las disciplinas de ingeniería

deben establecer y mantener una comunicación

activa entre ellas. Parte del papel del análisis de

sistemas es establecer los mecanismos de interfaz

que permitirán que esto suceda.

La visión de elemento para la ingeniería de

producto es la disciplina de ingeniería aplicada a la

asignación de componentes. Para la ingeniería del

software, esto significa actividades de modelado

del análisis y diseño 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.


12

INGENIERÍA DE REQUISITOS

La consecuencia del

proceso de

ingeniería de

sistemas es la

especificación de un

sistema o producto

basado en

computadora que se

describe genéricamente,

en diferentes niveles. 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:

1. Identificación de Requisitos,

2. Análisis de Requisitos y Negociación,

3. Especificación de Requisitos,

4. Modelado del Sistema,

5. Validación de Requisitos y Gestión de Requisitos.

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


13

sistema o producto va a ser utilizado en el día a día. Esto que parece

simple, es muy complicado. Christel y Kang identifican una serie de

problemas que nos ayudan a comprender por qué la obtención de

requisitos es costosa. Problemas de alcance. El límite del sistema

está mal definido o los detalles técnicos innecesarios, que han sido

aportados por los clientes/usuarios, pueden confundir más que

clarificar los objetivos del sistema. Problemas de comprensión. Los

clientes/usuarios no están completamente seguros de lo que

necesitan, tienen una pobre compresión de las capacidades y

limitaciones de su entorno de computación, no existe un total

entendimiento del dominio del problema, existen dificultades para

comunicar las necesidades al ingeniero del sistema, la omisión de

información por considerar que es «obvia», especificación de

requisitos que están en conflicto con las necesidades de otros

clientes/usuarios, o especificar requisitos ambiguos o poco estables.

Problemas de volatilidad. Los requisitos cambian con el tiempo.

Para ayudar a solucionar estos problemas, los ingenieros de sistemas

deben aproximarse de una manera organizada a través de reuniones

para definir requisitos. Sommerville y Sawyer sugieren un conjunto de

actuaciones para la obtención de

requisitos, que están descritos en las

tareas siguientes: valorar el impacto en el

negocio y la viabilidad técnica del sistema

propuesto; identificar las personas que

ayudarán a especificar requisitos y

contrastar su papel en la organización;

definir el entorno técnico (arquitectura de

computación, sistema operativo,

necesidades de telecomunicaciones) en el

sistema o producto a desarrollar e integrar;

identificar «restricciones de dominio»

(características específicas del entorno de

negocio en el dominio de la aplicación) que

limiten la funcionalidad y rendimientos del

sistema o producto a construir; definir uno

o más métodos de obtención de requisitos

(entrevistas, grupos de trabajo, equipos de

discusión); solicitar la participación de

muchas personas para que los requisitos

se definan desde diferentes puntos de vista, asegurarse de identificar

lo fundamental de cada requisito registrado; identificar requisitos

Cada uno de los

productos

obtenidos debe ser

revisado por las

personas que

hayan participado

en la obtención de

sus requisitos.


14

ambiguos como candidatos para el prototipo, y crear escenarios de

uso para ayudar a los clientes/usuarios a identificar mejor los

requisitos fundamentales.

El resultado alcanzado como consecuencia de la identificación de

requisitos variará dependiendo del tamaño del sistema o producto a

construir. Para grandes sistemas, el producto obtenido debe incluir:

una relación de necesidades y características; un informe conciso del

alcance del sistema o producto; una lista de clientes, usuarios y otros

intervinientes que deben participar en la actividad de obtención de

requisitos; una descripción del entorno técnico del sistema; una

relación de requisitos (perfectamente agrupados por funcionalidad) y

las restricciones del dominio aplicables a cada uno; un conjunto de

escenarios que permiten profundizar en el uso del sistema o producto

bajo diferentes condiciones operativas, y cualquier prototipo

desarrollado para definir mejor los requisitos.

2. Análisis y negociación de requisitos

Una vez recopilados los requisitos, el producto obtenido configura la

base del análisis de requisitos. Los requisitos se agrupan por

categorías y se organizan en subconjuntos, se estudia cada requisito

en relación con el resto, se examinan los requisitos en su

consistencia, completitud y ambigüedad, y se clasifican en base a las

necesidades de los clientes/usuarios. Al iniciarse la actividad del

análisis de requisitos se plantean las siguientes cuestiones: ¿Cada

requisito es consistente con los objetivos generales del

sistema/producto? ¿Tienen todos los requisitos especificados el nivel

adecuado de abstracción? Es decir, ¿algunos requisitos tienen un

nivel de detalle técnico inapropiado en esta etapa? ¿El requisito es

necesario o representa una característica añadida que puede no ser

esencial a la finalidad del sistema? ¿Cada requisito está delimitado y

sin ambigüedad? Cada requisito tiene procedencia. Es decir, ¿existe

un origen (general o específico) conocido para cada requisito?

¿Existen requisitos incompatibles con otros requisitos? ¿Es posible

lograr cada requisito en el entorno técnico donde se integrará el

sistema o producto? ¿Se puede probar el requisito una vez

implementado?

El ingeniero del sistema debe resolver estos conflictos a través de un

proceso de negociación. Los clientes, usuarios y el resto de


15

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.

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

4. Modelado del sistema

Considere por un momento que a usted se le ha requerido para

especificar los requisitos para la construcción de una cocina. Se

conocen las dimensiones del lugar, la localización de las puertas y

ventanas y el espacio de pared disponible. Debes especificar todos

los armarios y electrodomésticos e indicar dónde colocarlos. ¿Será

una especificación válida? La respuesta es obvia. Para especificar

completamente lo que vamos a desarrollar, necesitamos un modelo


16

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.

5. 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 sistema 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,


17

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?

MODELADO DEL SISTEMA

Todos los sistemas basados

en computadora

pueden

modelarse como

una

transformación de

la información

empleando una

arquitectura del tipo

entrada-proceso-salida.

Hatley y Pirbhai han

extendido esta visión para

incluir dos características adicionales

del sistema: tratamiento de la interfaz de usuario y

tratamiento del mantenimiento y autocomprobación. Aunque estas

características adicionales no están presentes en todos los sistemas

basados en computadora, son muy comunes y su especificación hace

más robusto cualquier modelo del sistema. Mediante la

representación de entrada, proceso, salida, tratamiento de la interfaz

de usuario y de Auto comprobació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.


18

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.

Para ilustrar el empleo del DCS, considere una versión ampliada del

sistema de clasificación de cinta transportadora (SCCT). Al ingeniero

del sistema se le presenta la siguiente declaración (algo confusa) de

objetivos para el SCCT:

El sistema SCCT debe desarrollarse de manera que las cajas que se

mueven a lo largo de la cinta transportadora sean identificadas y

ordenadas en uno de los seis contenedores al final de la cinta. Las

cajas pasarán a través de una estación clasificadora donde se

identificarán. Basándose en un número de identificación impreso en

un lateral de la caja (se proporciona un código de barras equivalente),

las cajas se mandarán a los contenedores apropiados. Las cajas

pasan aleatoriamente y están igualmente espaciadas. La línea se

mueve lentamente.

Para este ejemplo, la versión ampliada utiliza un PC en la estación

clasificadora. El PC ejecuta todo el software del SCCT; interacciona

con el lector de código de barras para leer parte de los números de

cada caja; interacciona con la cinta transportadora vigilando los

equipos que controlan velocidad en dicha cinta; almacena todos los

números de pieza clasificados; interacciona con el operador de la

estación clasificadora para producir una variedad de informes y

diagnósticos; envía señales de control al hardware separador para


19

clasificar las cajas; y se comunica con la estructura central de la

automatización de la fábrica.

En la Figura se muestra el DCS para SCCT (ampliado).

Cada caja de la Figura representa una entidad externa, es decir, un

suministrador o consumidor de información del sistema. Por ejemplo,

el lector del código de barras produce información que es introducida

en el sistema SCCT. El símbolo para representar todo el sistema (o a

niveles más bajos, subsistemas principales) es un rectángulo con las

esquinas redondeadas. De ahí que SCCT se represente en la región

de proceso y control en el centro del DCS. Las flechas etiquetadas

mostradas en el DCS representan información (datos y control) que

va desde el entorno exterior al sistema SCCT. La entidad externa

lector del código de barras produce una entrada de información

etiquetada como código de barras. En esencia, el DCS sitúa a

cualquier sistema en el contexto de su entorno exterior.


20

El ingeniero de sistemas refina el diagrama de contexto de

arquitectura estudiando con más detalle el rectángulo sombreado de

la Figura. Se identifican los subsistemas principales que permiten

funcionar al sistema clasificador de cinta transportadora dentro del

contexto definido por el DCS.

En este punto, cada uno de los subsistemas puede contener uno o

más elementos del sistema (por ejemplo, hardware, software,

personas) tal y como los ha asignado el ingeniero de sistemas. El

diagrama inicial de flujo del sistema (DFS) se convierte en el nudo

superior de una jerarquía de DFS. Cada rectángulo redondeado del

DFS original puede expandirse en otra plantilla de arquitectura

dedicada exclusivamente a ella. Se pueden especificar (delimitar) los

subsistemas y la información que fluyen entre ellos para los

subsiguientes trabajos de ingeniería. Una descripción narrativa de

cada subsistema y una definición de todos los datos que fluyen entre

los subsistemas son elementos importantes de la Especificación del

Sistema.


21

BIBLIOGRAFÍA

Ingeniería del software – un enfoque práctico. Roger S. Pressman

http://www.google.com.pe/search?num=10&hl=es&site=imghp&tb

m=isch&source=hp&biw=1366&bih=677&q=EL+PRODUCTO&oq=

EL+PRODUCTO&gs_l=img.3..0l10.1430.3454.0.4143.11.9.0.2.2.0

.186.986.4j5.9.0...0.0...1ac.1.Fl7oAV4lIQw#hl=es&tbo=d&site=img

hp&tbm=isch&sa=1&q=software+de+inteligencia+artificial&oq=soft

ware+de+inteligencia+artificial&gs_l=img.3..0j0i24l5.134002.1409

50.6.141169.26.11.0.15.15.1.196.1908.0j11.11.0...0.0...1c.1.9iim2

AMAFfQ&pbx=1&bav=on.2,or.r_gc.r_pw.r_qf.&fp=ba1326681ff2cb

8&bpcl=38897761&biw=1366&bih=634

http://es.wikipedia.org/wiki/Ingenier%C3%ADa_de_software

http://www.ctic.uni.edu.pe/files/insoft01.pdf

Todos son links o enlaces a diferentes páginas web que se

consultaron para el desarrollo de esta sesión de clases.

Documents

ISW-S10-Ingeniería de Sistemas