CAPÍTULO

10 INGENIERÍA DE SISTEMAS

H
ACE casi 500 años, Maquiavelo dijo: no hay nada más difícil de llevar a cabo, más
peligroso de realizar o de éxito más incierto que tomar el liderazgo en la introducción
de un nuevo orden de Durante los Últimos 50 años, los sistemas basados en
han introducido un nuevo orden. Aunque la tecnología ha conseguido grandes avan-
ces desde que habló Maquiavelo, sus palabras siguen sonando a verdad.
La ingeniería del software aparece como consecuencia de un proceso denominado ingenie-
rí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 sis-
tema que pueden ser un producto, un servicio o una tecnología para la transformación de infor-
mació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 pro-
ducto, el proceso se denomina ingeniería de producto.
Tanto la ingeniería de proceso de negocio como la de producto intentan poner orden al desa-
rrollo de sistemas basados en computadoras. Aunque cada una se aplica en un dominio de apli-
cación diferente, ambas intentan poner al software en su contexto.

obtenido? Se debe
a correcta representación
secuencia de la

generales del sistema;se debe

el papel del hardware, so

y los requerimientos operacionales

deben ser identificados; analizados,
especificados,modelizados,validados de la arquitectura del
y gestionados. Estas actividades son
la base de la ingeniería de sistemas.
lo hace? Un ingeniero de sistemas
ja comprender los requisitos
istema en colabora

tes interesadas.
qué es importante? estionados para as que los cambios en los requisitos de un
ambios se controla sistema sean gestionados utilizando
cuadamente. métodos sólidos de GCS (Capítulo

Es decir, tanto la ingeniería de procesos de negocio' como la de producto trabajan para asignar un
papel al software de computadora y para establecer los enlaces que unen al software con otros ele-
mentos de un sistema basado en computadora.
En este capítulo, profundizamos en las necesidades de gestión y en las actividades específicas del
proceso que permitan asegurar una organización del software que consiga resultados satisfactoriosen
el tiempo fijado y por el método definido.

En realidad, el término ingeniería de sistemas se emplea a menudo en este contexto. Sin embargo, en este libro, el
término de es genérico y se usa para abarcar a la ingeniería de proceso de negocio y a la inge-
niería de producto.
 DEL SOFTWARE. UN ENFOQUE PR A C TI C O

La palabra sistema es posiblemente el término más usa- ciones específicas, en un conjunto de señales de control
do y abusado del léxico técnico. Hablamos de sistemas que provocan alguna acción física específica. Tanto la
políticos y de sistemas educativos, de sistemas de avia- creación de un sistema de información para asesorar a un
ción y de sistemas de fabricación, de sistemas banca- departamento de marketing, como el software de control
rios y de sistemas de locomoción. La palabra no nos para el robot, requieren de la ingeniería de sistemas.
dice gran cosa. Usamos el adjetivo para describir el sis- Una característica complicada de los sistemas basa-
tema y para entender el contexto en que se emplea. El dos en computadora es que los elementos que compo-
diccionario Webster define sistema como: nen un sistema pueden también representar un
un conjunto o disposición de cosas relacionadas de mane- macroelemento de un sistema aún más grande. El macro-
ra que forman una unidad o un todo orgánico; 2. un conjunto elemento es un sistema basado en computadora que es
de hechos, principios, reglas, etc., clasificadas y dispuestas de parte de un sistema más grande basado en computado-
manera ordenada mostrando un plan de unión de las par- ra. Por ejemplo, consideremos un de
tes; 3. un método o plan de clasificación o disposición; 4.una tización de una fábrica» que es esencialmente una
manera establecida de hacer algo; método; procedimiento...
jerarquía de sistemas. En el nivel inferior de la jerar-
Se proporcionan cinco definiciones más en el dic- quía tenemos una máquina de control numérico, robots
cionario, pero no se sugiere un sinónimo preciso. Sis- y dispositivos de entrada de información. Cada uno es
tema es una palabra especial. un sistema basado en computadora por derecho propio.
Tomando prestada la definición del diccionario Los elementos de la máquina de control numérico inclu-
ter, definimos un sistema basado en computadora como: yen hardware electrónico y electromecánico (por ejem-
Un conjunto o disposición de elementos que están organi- plo, procesador y memoria, motores, sensores); software
zados para realizar un objetivo predeñnido procesando infor- (para comunicaciones, control de la máquina e
mación. lación); personas (el operador de la máquina); una base
El objetivo puede ser soportar alguna función de de datos (el programa CN almacenado); documentación
negocio o desarrollar un producto que pueda venderse y procedimientos. Se podría aplicar una descomposi-
para generar beneficios. Para conseguir el objetivo, un ción similar a los dispositivos de entrada de informa-
sistema basado en computadora hace uso de varios ele- ción y al robot. Todos son sistemas basados en
mentos del sistema: computadora.
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.
CLAVE
Hardware. Dispositivos electrónicos que proporcionan
los complejos son actualmente uno jerarquía
capacidad de cálculo, dispositivos de interconexión (por
ejemplo, conmutadores de red, dispositivos de telecomuni- de macro elementos que son sistemas en sí mismos.
cación) y dispositivos electromecánicos (por ejemplo,
motores, bombas) que proporcionan una función En el siguiente nivel de la jerarquía, se define una
externa, del mundo real. célula de fabricación. La célula de fabricación es un sis-
Personas. Usuarios y operadores del hardware y software. tema basado en computadora que puede tener elemen-
tos propios (por ejemplo, computadoras, fijaciones
Documentación. Manuales, formularios y otra informa- mecánicas) y también integra los macroelementos que
ción descriptiva que plasma el empleo funcionamiento
del sistema. hemos denominado máquina de control numérico, robot
y dispositivo de entrada de información.
Procedimientos. Los pasos que definen el empleo especí-
fico de cada elemento del sistema o el contexto procedimental Para resumir, la célula de fabricación y sus
en que reside el sistema. lementos están compuestos de elementos del sistema
con las etiquetas genéricas: software, hardware, perso-
nas, base de datos, procedimientos y documentación.
En algunos casos, los macroelementos pueden compartir
No esté por de un un elemento genérico. Por ejemplo, el robot y la máqui-
en el por considerar na CN podrían ser manejadas por el mismo operador
todos los elementos de un de concentrarse (el elemento personas). En otros casos, los elementos
en el genéricos son exclusivos de un sistema.
El papel del ingeniero de sistemas es definir los ele-
Los elementos se combinan de varias maneras para mentos de un sistema específico basado en computa-
transformar la información. Por ejemplo, un departamento dora en el contexto de la jerarquía global de sistemas
de marketing transforma la información bruta de ventas (macroelementos).
en un perfil del típico comprador del producto; un robot En las siguientes secciones, examinamos las tareas que
transforma un archivo de órdenes, que contiene instruc- constituyen la ingeniería de sistemas de computadoras.
166
 10 DE S I S T E M A S

Dominio
de negocio Vista global
o de producto

Dominio d e interés

Elemento
del sistema
Vista
del elemento

Vista
detallada

FIGURA 10.1. La jerarquía de la ingeniería de sistemas de computadora.

Independientemente del dominio de enfoque, la ingenie- definan los procesos que satisfagan las necesidades
ría de sistemas comprende una colección de métodos para de la visión en consideración;
navegar de arriba abajo y de abajo arriba en la jerarquía representen el comportamiento de los procesos y los
ilustrada en la Figura 1O. El proceso de la ingeniería de supuestos en los que se basa el comportamiento;
sistemas empieza normalmente con una definan explícitamente las entradas y
Es decir, se examina el dominio entero del negocio o del de información al modelo;
producto para asegurarse de que se puede establecer el representen todos las uniones (incluyendo las sali-
contexto de negocio o tecnológico apropiado. La visión das) que permitan al ingeniero entender mejor la
global se refina para enfocarse totalmente en un dominio visión.
de interés específico. Dentro de un dominio específico, se
analiza la necesidad de elementos del sistema (por ejem-
plo, información, software, hardware, personas). Final-
mente, se inicia el análisis, diseño y construcción del
elemento del sistema deseado. En la parte alta de c VE
se establece un contexto muy amplio y en la parte tos buenos sistemas de ingeniería comienzan por
baja se llevan a cabo actividades técnicas detalladas, rea- clarificar el comportamiento de contexto visión
lizadas por la disciplina de ingeniería correspondiente(por global-y progresivamente se van estrechando hasta
ejemplo, ingeniería hardware o el nivel de detalle necesario.

10.2.1. Modelado del sistema Para construir un modelo del sistema, el ingeniero
La ingeniería de sistemas de computadora es un proce- debería considerar algunas restricciones:
so de modelado. Tanto si el punto de mira está en la Supuestos que reducen el número de permutaciones
visión global o en la visión detallada, el ingeniero crea y variaciones posibles, permitiendo así al modelo
modelos que : reflejar el problema de manera razonable. Por

En algunas situaciones, sin embargo, los ingenieros del sistema Las entradas unen un elemento de una visión dada con
deben considerar primero los elementos individuales del sistema otros elementos al mismo o a otros niveles; las entradas
los requisitos detallados. Empleando este enfoque, los subsistemas unen componentes individuales de un elemento en una visión par-
se escriben de abajo a arriba considerando primero los componen- ticular.
tes de detalle del subsistema.
167
 DEL SOFTWARE. UN ENFOQUE PRÁCTICO

plo, considere un producto de representación en tres cliente es a menudo tomada en cuenta hasta el punto
dimensiones usado por la industria de entretenimiento de realizar su enfoque preferido.
para crear animaciones realistas. Un dominio del pro- El modelo de sistema resultante (desde cualquier
ducto permite la representación de formas humanas visión) puede reclamar una solución completamente
en 3D. Las entradas a este dominio comprenden la automática, semiautomática o un enfoque manual. De
habilidad de introducir movimiento de un hecho, es posible a menudo caracterizar modelos de
humano vivo, desde vídeo o creando modelos gráfi- cada tipo que sirven de soluciones alternativas para el
cos. El ingeniero del sistema hace ciertos supuestos problema que tenemos entre manos. En esencia, el
sobre el rango de movimientos humanos permitidos ingeniero del sistema modifica simplemente la influen-
(por ejemplo, las piernas no pueden enrollarse alre- cia relativa de los diferentes elementos del sistema
dedor del tronco) de manera que puede limitarse el (personas, hardware, software) para crear modelos de
proceso y el rango de entradas. cada tipo.
2. Simplificaciones que permiten crear el modelo a
tiempo. Para ilustrarlo, considere una compañía de 10.2.2. Simulación del sistema
productos de oficina que vende y suministra una
amplia variedad de fotocopiadoras, faxes y equipos En los años 60, R.M. Graham hizo un comen-
similares. El ingeniero del sistema está modelando tario crítico sobre la manera en que se construían los sis-
las necesidades de la organización suministradora y temas basados en computadora: «Construimos sistemas
está trabajando para entender el flujo de información igual que los hermanos Wright construían aviones: cons-
que engendra una orden de suministro. Aunque una truimos todo el sistema, lo empujamos barranco abajo,
orden de suministro puede generarse desde muchos le dejamos que se estrelle y empezamos de nuevo.» De
orígenes, el ingeniero categoriza solamente dos fuen- hecho, para al menos un tipo de sistema sistema
tes: demanda interna o petición externa. Esto per- reactivo- lo continuamos haciendo hoy en día.
mite una partición simplificada de entradas necesaria Muchos sistemas basados en computadora
para generar una orden de trabajo. cionan con el mundo real de forma reactiva. Es decir,
los acontecimientos del mundo real son vigilados por
3. Limitaciones que ayudan a delimitar el sistema. Por el hardware y el software que componen el sistema, y
ejemplo, se está modelando un sistema de aviónica
basándose en esos sucesos, el sistema aplica su control
para un avión de próxima generación. Como el avión
sobre las máquinas, procesos e incluso las personas que
tendrá un diseño de dos motores, todos los dominios
motivan los acontecimientos. Los sistemas de tiempo
de supervisión de la propulsión se modelarán para
real y sistemas empotrados pertenecen a menudo a la
albergar un máximo de dos motores y sus sistemas
categoría de sistemas reactivos.
redundantes asociados.

acaba el modelo
de ingeniería del sistema? Si lo de no está disponible
poro un el riesgo del proyecto
4 . Restricciones que guían la manera de crear el modelo se incremento. poro un modelo
y el enfoque que se toma al implementar el modelo. de proceso que te permito obtener un resultado
Por ejemplo, la infraestructura tecnológica para el en uno primero y poro
sistema de representación en tres dimensiones des-
crita anteriormente es un solo procesador basado en
un Power-PC. La complejidad de cálculo de los pro- Desgraciadamente, los desarrolladores de sistemas
blemas deben restringirse para encajar en los reactivos luchan a veces para hacerlos funcionar correc-
tes de proceso impuestos por el procesador. tamente. Hasta hace poco, ha sido difícil predecir el ren-
dimiento, la eficacia y el comportamiento de estos
sistemas antes de construirlos. Realmente, la construc-
ción de muchos sistemas de tiempo real era una aven-
CLAVE tura. Las sorpresas (la mayoría desagradables) no se
Un ingeniero del sistema considera los siguientes factores descubrían hasta que el sistema era construido y
cuando desarrolla soluciones alternativas: planteamientos, jado colina abajo». Si el sistema se estrellaba debido a
simplificaciones, limitaciones, restricciones y preferencias un funcionamiento incorrecto, comportamiento inapro-
de los clientes. piado o escaso rendimiento, cogíamos las piezas y empe-
zábamos de nuevo.
5. Preferencias que indican la arquitectura preferida Muchos sistemas de la categoría de los reactivos con-
para todos los datos, funciones y tecnología. La solu- trolan máquinas procesos (por ejemplo, aerolíneas
ción preferida entra a veces en conflicto con otros comerciales o refinerías de petróleo) que deben operar
factores restrictivos. Aunque la satisfacción del con extrema fiabilidad.
168
 10 DE SISTEMAS

Si el sistema falla, podrían ocurrir pérdidas econó- ficación del sistema. En el Capítulo 31 se estudian
micas o humanas significativas. Por este motivo, el enfo- brevemente los detalles técnicos y técnicas especia-
que descrito por Graham es penoso y peligroso. les de modelado que se emplean para llevar a cabo
Hoy en día se utilizan herramientas software para estas pruebas.
el modelado y simulación de sistemas para ayudar a
eliminar sorpresas cuando se construyen sistemas
reactivos basados en computadora. Estas herramien-
tas se aplican durante el proceso de ingeniería de sis-
temas, mientras se están especificando las necesidades
del hardware, software, bases de datos y de personas.
Las herramientas de modelado y simulación capaci- CASE
tan al ingeniero de sistemas para probar una especi- Modelado y Simulación

El objetivo de la ingeniería de proceso de negocio Se deben analizar y diseñar tres arquitecturas dife-
es definir arquitecturas que permitan a las empresas rentes dentro del contexto de objetivos y metas de
emplear la información eficazmente. Michael Guttman negocio:
describe el desafio cuando dice: arquitectura de datos
El actual entorno computacional consiste en un poder de arquitectura de aplicaciones
computación distribuido en toda la empresa con múltiples
unidades diferentes de procesamiento, dividido y configura- infraestructura de la tecnología
do por una amplía variedad de tareas, Nuevos planteamien-
tos como la computación cliente-servidor, procesamiento
distribuido, el trabajo en red (por nombrar algunos de los tér- los de detalle
minos más sobreusados) permiten gestionar las demandas en el Capítulo 12.
aportando mayor funcionalidad y flexibilidad.
Sin embargo, el coste de estos cambios es ampliamente La arquitectura de datos proporciona una estructu-
discutido por la organizaciones de TI (Tecnologías de la Infor-
mación) que deben soportar esta configuración. ra para las necesidades de información de un negocio o
Hoy, cada organización de TI debe favorecer la integración de una función de negocio. Los ladrillos de la arquitec-
de sus sistemas. Debe diseñar, implementar y soportar su tura son los objetos de datos que emplea la empresa. Un
propia configuración de recursos de computación objeto de datos contiene un conjunto de atributos que
nea, distribuidos lógica y geográficamente por toda la empre- definen aspectos, cualidades, características o
sa, conectándola a través de un esquema apropiado para el tor de los datos que han sido descritos. Por ejemplo, un
trabajo en red.
ingeniero de la información puede definir el objeto de
Por otra parte, esta configuración debe ser diseñada para datos: cliente. Para describir más en detalle al cliente,
cambios continuos, desigualmente localizadosen la empre-
sa, debido a cambios en requisitos del negocio y en las pro- se definen los siguientes atributos:
pias tecnologías. Estos diversos e incrementales cambios Objeto: Cliente
deben ser coordinados a través del entorno distribuido, con- Atributos:
sistente en hardware y software suministrado por decenas,
cuando no cientos, de vendedores. Por supuesto, esperamos nombre
que estos cambios los incorporemos sin ruptura con la nombre de la compañía
rativa habitual permitiendo además ampliar la operativa.
clasificación del trabajo y autoridad en compra
Cuando hablamos de una visión general de las dirección comercial e información de contacto
de tecnología de información de una compañía, de interés
pequeñas incertidumbres que son planteadas a anteriores
ingeniería de sistemas. La ingeniería de proceso de
fecha de último contacto
es un acercamiento para crear un plan gene-
@ para implementar la arquitectura de computación 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 obje-
tos: cliente y producto A. Los dos objetos pueden conec-
Tres arquitecturas diferentes son desorrollodos durante tarse por la relación compra; es decir, un cliente compra
IPN: arquitectura de datos, arquitectura el producto A o el producto A es comprado por un clien-
de aplicación y infraestructura tecnológica. te. Los objetos de datos (pueden existir cientos o miles
169
 DEL SOFTWARE. UN ENFOQUE PRÁCTICO

para una actividad de negocio importante) fluyen entre dad de la empresa. La PEI define los objetos de datos
las funciones de negocio, están organizados dentro de visibles a nivel empresa, sus relaciones y cómo fluyen
una base de datos y se transforman para proveer infor- entre los dominios del negocio
mación que sirva a las necesidades del negocio.
La arquitectura de aplicación comprende aquellos
elementos de un sistema que transforman objetos den-
lomo ingeniero del no debes profundizar en
tro de la arquitectura de datos por algún propósito del
ni en el No obstante, si no está cloro que estas
negocio. En el contexto de este libro, consideramos sido informe a su superior
normalmente que la arquitectura de aplicación es el sis- que el riesgo es muy alto.
tema de programas (software) que realiza esta trans-
formación. Sin embargo, en un contexto más amplio, La vista del dominio se trata con una actividad IPN
la arquitectura de aplicación podría incorporar el papel denominada análisis del área de negocio (AAN).
de las personas (por ejemplo, que ha describe AAN de la siguiente manera:
sido diseñado para implementar estas tecnologías. El se ocupa de identificar en detalle la información (en
la forma de tipos de entidad [objeto datos]) y los requisitos de
las funciones (en la forma de procesos) de áreas de negocio
El sobre la del seleccionadas [dominios] identificadas durante el PEI,
es en Capítulo 14. guando sus (en forma de matrices). Se ocupa sola-
mente de especificar qué se requiere en un área de negocio.
La infraestructura tecnológica proporciona el fun- A medida que el ingeniero de información comienza el
damento de las arquitecturas de datos y de aplicaciones. AAN, el enfoque se estrecha hacia un dominio del nego-
La infraestructura comprende el hardware y el software cio específico. El AAN ve el área del negocio como una
empleados para dar soporte a las aplicaciones y datos. entidad y aísla las funciones de negocio y procedimientos
Esto incluye computadoras y redes de computadora, enla- que permiten al área del negocio lograr sus objetivos y
ces de telecomunicaciones, tecnologías de almacena- metas. El AAN, al igual que el PEI, define objetos de datos,
miento y la arquitectura (por ejemplo, sus relaciones y cómo fluye la información. Pero a este
diseñada para implementar estas tecnologías. 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
Planificacion información pueden prestar soporte al área de negocio.
estratégica
de la informacion
(vista global)

Área

Ingeniería de Procesos de

Una vez que se ha aislado un sistema de información

Requisito para un desarrollo posterior, la IPN hace una transición
a la ingeniería del software. Invocando la fase del dise-
del sistema ño de sistema de negocio (DSN), se modelan los requi-
de negocio
(vista del elemento)
sitos 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
se centra en los detalles de la implementación. La
arquitectura e infraestructura se implementan constru-
yendo una base de datos apropiada y estructuras
FIGURA 10.2. La jerarquía de la ingeniería de procesos. de datos, mediante la construcción de aplicaciones que
están constituidas por programas, y seleccionando los
Para modelar las arquitecturas de sistema descritas elementos apropiados de una infraestructura tecnológica
anteriormente, se define una jerarquía de actividades de para dar soporte al diseño creado durante el DSN. Cada
ingeniería de la información. Como muestra la Figura uno de estos componentes del sistema debe integrarse
10.2, la visión global se consigue a través de la para formar una aplicación o sistema de información com-
cación de la estrategia de información (PEI). La PEI pleto. La actividad de integración también coloca al nue-
ve todo el negocio como una entidad y aisla los domi- vo sistema de información en el contexto del área de
nios del negocio (por ejemplo, ingeniería, fabricación, negocio, realizando todo el entrenamiento de usuario y
marketing, finanzas, ventas) importantes para la totali- soporte para conseguir una suave transición.
170
 10 DE SISTEMAS

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

deseo de un cliente, de un conjunto de capacidades Análisis
definidas, a un producto operativo4. Para conseguir del sistema
esta meta, la ingeniería de producto (como la inge- (vista global)
niería de proceso de negocio) debe crear una arqui-
Capa
tectura y una infraestructura. La arquitectura
comprende cuatro componentes de sistema distintos: lngenieria
de componente
software, hardware, datos (bases de datos) y perso-
nas. Se establece una infraestructura de soporte e de dominio)
incluye la tecnología requerida para unir los compo- ,
Requisito
nentes y la información (por ejemplo, documentos,
CD-ROM, vídeo) que se emplea para dar soporte a
los componentes.
Como se muestra en la Figura 10.3, la visión glo-
bal se consigue a través de la ingeniería de requisi- Componentes Ingeniería
de programa del software
tos. Los requisitos generales del producto se obtienen
del cliente. Estos requisitos comprenden necesidades Construcción
e integración
de información y control, funcionalidad del produc- (vista detallada)
to y comportamiento, rendimiento general del pro-
ducto, diseño, restricciones de la interfaz y otras FIGURA 10.3. La jerarquía de la ingeniería de productos.
necesidades especiales. Una vez que se conocen estos
requisitos, la misión del análisis del sistema es asig- Parte del papel del análisis de sistemas es establecer los
nar funcionalidad y comportamiento a cada uno de mecanismos de interfaz que permitirán que esto suceda.
los cuatro componentes mencionados anteriormente. La visión de elemento para la ingeniería de produc-
Una vez que se ha hecho la asignación, comienza to es la disciplina de ingeniería aplicada a la asignación
la ingeniería de componentes del sistema. La inge- de componentes. Para la ingeniería del software, esto
niería de componentes del sistema es, de hecho, un significa actividades de modelado del análisis y diseño
conjunto de actividades concurrentes que se dirigen (cubierto en detalle en posteriores capítulos) y activi-
separadamente a cada uno de los componentes del sis- dades de construcción e integración que comprenden
tema: la ingeniería del software, ingeniería hardware, generación de código, pruebas y actividades de sopor-
ingeniería humana e ingeniería de bases de datos. Cada te. El modelado de la fase de análisis asigna requisitos
una de estas disciplinas de ingeniería toma una vista a las representaciones de datos, funciones y comporta-
de dominio específica, pero es importante resaltar que miento. El diseño convierte el modelo de análisis en
las disciplinas de ingeniería deben establecer y man- diseños de datos, arquitectónicos, de interfaz y a nivel
tener una comunicación activa entre ellas. 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 dife-
rentes niveles en la Figura 10.1. Pero el desafío de la
ingeniería del sistema (y de los ingenieros del softwa-
re) es importante: podemos asegurar que hemos
especificado un sistema que recoge las necesidades del
cliente y satisface sus expectativas? No hay una res-
puesta segura a esta difícil pregunta, pero un sólido
ceso de ingeniería de requisitos es la mejor solución de La ingeniería de requisitos facilita el mecanismo
que disponemos actualmente. apropiado para comprender lo que quiere el cliente,

‘Debemos hacer notar que la terminología (adaptada por

utilizada en la Figura 10.2 está asociada con la ingeniería de la infor-
mación, la predecesora del moderno IPN. Sin embargo, el área cen-
tral implicada en cada actividad señalada es dirigida por todos
aquellos que consideran el tema.

171
 DEL SOFTWARE. UN ENFOQUE PRÁCTICO

lizando necesidades, confirmando su viabilidad, nego- qué es tan difícil

ciando una solución razonable, especificando la solu- obtener un planteamiento
ción sin ambigüedad, validando la especificación y claro de lo que necesita
gestionando los requisitos para que se transformen en el cliente?
un sistema operacional El proceso de inge-
niería de requisitos puede ser descrito en 5 pasos dis- identificar las personas que ayudarán a especificar
tintos Identificación de Requisitos, Análisis requisitos y contrastar su papel en la organización;
de Requisitos y Negociación, Especificación de Requi- definir el entorno técnico (arquitectura de computa-
sitos, Modelizado del Sistema, Validación de Requisi- ción, sistema operativo, necesidades de telecomuni-
tos y Gestión de Requisitos. caciones) en el sistema o producto a desarrollar e
integrar;
10.5.1. Identificación de requisitos identificar «restricciones de dominio» (característi-
En principio, parece bastante simple -preguntar al cas específicas del entorno de negocio en el domi-
cliente, a los usuarios y a los que están involucrados en nio de la aplicación) que limiten la funcionalidad y
los objetivos del sistema o producto y sean expertos, rendimientos del sistema o producto a construir;
investigar cómo los sistemas o productos se ajustan a definir uno o más métodos de obtención de requisi-
las necesidades del negocio, y finalmente, cómo el sis- tos (entrevistas, grupos de trabajo, equipos de dis-
tema o producto va a ser utilizado en el día a día-. Esto cusión);
que parece simple, es muy complicado. solicitar la participación de muchas personas para
Christel y Kang identifican una serie de pro- que los requisitos se definan desde diferentes puntos
blemas que nos ayudan a comprender por qué la obten- de vista, asegurarse de identificar lo fundamental de
ción de requisitos es costosa. cada requisito registrado;
problemas de alcance. El límite del sistema está mal identificar requisitos ambiguos como candidatos para
definido o los detalles técnicos innecesarios, que han el prototipado, y
sido aportados por los pueden con- crear escenarios de uso (ver Capítulo 11) para ayu-
fundir más que clarificar los objetivos del sistema. dar a los a identificar mejor los
problemas de comprensión. Los no requisitos fundamentales.
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, Asegúrate de haber los características generales
existen dificultades para comunicar las necesidades antes de especificar el esfuerzo y plazo para obtener
al ingeniero del sistema, la omisión de información los requisitos de
por considerar que es «obvia», especificación de
El resultado alcanzado como consecuencia de la iden-
requisitos que están en conflicto con las necesidades
tificación de requisitos variará dependiendo del tama-
de otros o especificar requisitos
ño del sistema o producto a construir. Para grandes
ambiguos o poco estables.
sistemas, el producto obtenido debe incluir:
Problemas de volatilidad. Los requisitos cambian una relación de necesidades y características;
con el tiempo.
.- un informe conciso del alcance del sistema o producto;

Referencia
a&
’-
una lista de clientes, usuarios y otros intervinientes
que deben participar en la actividad de obtención de
requisitos;
Un informe detallado el titulo ((Necesidades una descripción del entorno técnico del sistema;
en Obtención de Requisitos)) puede ser descargado de una relación de requisitos (perfectamente agrupados
por funcionalidad) y las restricciones del dominio
aplicables a cada uno;
Para ayudar a solucionar estos problemas, los inge- un conjunto de escenarios que permiten profundizar
nieros de sistemas deben aproximarse de una mane- en el uso del sistema o producto bajo diferentes con-
ra organizada a través de reuniones para definir diciones operativas, y
requisitos. cualquier prototipo desarrollado para definir mejor
Sommerville y Sawyer sugieren un con- los requisitos.
junto 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éc- los métodos de de requisitos
nica del sistema propuesto; son presentados en el Capítulo 1

172
 10 DE S I S T E M A S

Cada uno de los productos obtenidos debe ser revi- El ingeniero del sistema debe resolver estos conflic-
sado por las personas que hayan participado en la obten- tos a través de un proceso de negociación. Los clientes,
ción de sus requisitos. usuarios y el resto de intervinientes deberán clasificar
sus requisitos y discutir los posibles conflictos según su
10.5.2. Análisis y negociación de requisitos prioridad. Los riesgos asociados con cada requisito serán
identificados y analizados (ver Capítulo 6). Se efectúan
Una vez recopilados los requisitos, el producto obteni- del esfuerzo de desarrollo que se utili-
do configura la base del análisis de requisitos. Los requi- zan para valorar el impacto de cada requisito en el cos-
sitos se agrupan por categorías y se organizan en te del proyecto y en el plazo de entrega. Utilizando un
subconjuntos, se estudia cada requisito en relación con procedimiento iterativo, se irán eliminando requisitos,
el resto, se examinan los requisitos en su consistencia, se irán combinando modificando para conseguir
completitud y ambigüedad, y se clasifican en base a las satisfacer los objetivos planteados.
necesidades de los

cuestiones deben ser 10.5.3. Especificación de requisitos

preguntadas y contestadas En el contexto de un sistema basado en computadoras
. durante el análisis de requisitos? (y software), el término especificación significa distin-
tas cosas para diferentes personas. Una especificación
Al iniciarse la actividad del análisis de requisitos se puede ser un documento escrito, un modelo gráfico, un
plantean las siguientes cuestiones: modelo matemático formal, una colección de escena-
requisito es consistente con los objetivos gene- rios de uso, un prototipo o una combinación de lo ante-
rales del riormente citado.
todos los requisitos especificados el nivel Algunos sugieren que debe desarrollarse una «plan-
adecuado de abstracción? Es decir, requi- tilla y usarse en la especificación
sitos tienen un nivel de detalle técnico inapropiado del sistema, argumentando que así se conseguirían requi-
en esta etapa? sitos que sean presentados de una forma más consis-
tente y más comprensible. No obstante, en muchas
requisito es necesario o representa una caracte- ocasiones es necesario buscar la flexibilidad cuando una
rística añadida que puede no ser esencial a la finali- especificación va a ser desarrollada. Para grandes sis-
dad del sistema? temas, un documento escrito, combinado con descrip-
requisito está delimitado y sin ambigüedad? ciones en lenguajes natural y modelos gráficos puede
Cada requisito tiene procedencia. Es decir, ser la mejor alternativa. En cualquier caso, los escena-
un origen (general o específico) conocido para cada rios a utilizar pueden ser tanto los requeridos para pro-
requisito? ductos de tamaño pequeño o los de sistemas que residan
requisitos incompatibles con otros requi- en técnicos bien conocidos.
sitos?
posible lograr cada requisito en el entorno téc-
nico donde se integrará el sistema o producto?
puede probar el requisito una vez implementado?
Técnicas de Negociación

La Especificacióndel Sistema es el producto final sobre

los requisitos del sistema obtenido por el ingeniero. Sir-
ve como fundamento para la ingeniería del hardware,
ingeniería del software, la ingeniería de bases de datos y
Análisis de Requisitos la ingeniería humana. Describe la función y característi-
Es corriente en clientes usuarios solicitar más de cas de un sistema de computación y las restricciones que

especiales».

Si los diferentes no pueden

los requisitos, el de errar es Proceda
con precaución. Especificacióndel sistema
173
 DEL SOFTWARE. UN ENFOQUE PRÁCTICO

10.5.4. Modelado del sistema (es un problema importante), requisitos contradictorios,

Considere por un momento que a usted se le ha reque- o requisitos imposibles o inalcanzables.
rido para especificar los requisitos para la construcción Aunque la validación de requisitos puede guiarse de
de una cocina. Se conocen las dimensiones del lugar, la manera que se descubran errores, es útil chequear cada
localización de las puertas y ventanas y el espacio de requisito con un cuestionario. Las siguientes cuestiones
pared disponible. Debes especificar todos los armarios representan un pequeño subconjunto de las preguntas
y electrodomésticos e indicar dónde colocarlos. que pueden plantearse:
una especificación válida? el requisito claramente definido?
La respuesta es obvia. Para especificar completamente pretarse mal?
lo que vamos a desarrollar, necesitamos un modelo de identificado el origen del requisito (por ejem-
la cocina con toda su información, esto es, un antepro- plo: persona, norma, documento)? planteamiento
yecto o una representación en tres dimensiones que mues- final del requisito ha sido con la fuente
tre las posiciones de los armarios y electrodomésticos, original?
y sus relaciones. Con el modelo será relativamente fácil requisito está delimitado en términos cuantita-
asegurar la eficiencia del trabajo (un requisito de todas tivos?
las cocinas), la estética «visual» de la sala (es un requi-
otros requisitos hacen referencia al requisito
sito personal, aunque muy importante).
estudiado? claramente identificados por medio
Se construyen modelos del sistema por la misma
de una matriz de referencias cruzadas o por cualquier
razón que desarrollamos para una cocina un antepro-
otro mecanismo?
yecto o una representación en 3D. Es importante eva-
luar los componentes del sistema y sus relaciones entre requisito incumple alguna restricción definida?
sí; determinar cómo están reflejados los requisitos, y requisito es verificable? Si es así, efec-
valorar como se ha concebido la «estética» en el siste- tuar pruebas (algunas veces llamadas criterios de
ma. Se profundiza en el modelado del sistema en la validación) para verificar el requisito?
Sección 10.6. puede seguir el requisito en el modelo del sis-
tema que hemos desarrollado?
Validación de requisitos puede localizar el requisito en el conjunto de
El resultado del trabajo realizado es una consecuencia objetivos del
de la ingeniería de requisitos (especificación del siste- el requisito asociado con los rendimientos del
ma e información relacionada) y es evaluada su calidad sistema o con su comportamiento y han sido esta-
en la fase de validación. La validación de requisitos exa- blecidas claramente sus características
mina las especificaciones para asegurar que todos los les? requisito está implícitamente definido?
requisitos del sistema han sido establecidos sin ambi-
güedad, sin inconsistencias, sin omisiones, que los erro-
res 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.

Requisitos

Un punto Las preguntas planteadas en la lista de comproba-

de requisitos es Utilice el modelo ción ayudan a asegurar que el equipo de validación dis-
del que los requisitos pone de lo necesario para realizar una revisión completa
sido consistentemente de cada requisito.
El primer mecanismo para la validación de los requi-
sitos es la revisión técnica formal (Capítulo 8). El equi- 10.5.6. Gestión d e requisitos
po de revisión incluye ingenieros del sistema, clientes, En el capítulo anterior se advertía que los requisitos del
usuarios, y otros intervinientes que examinan la espe- sistema cambian y que el deseo de cambiar los requisi-
cificación del sistema5 buscando errores en el conteni- tos persiste a lo largo de la vida del sistema. La gestión
do o en la interpretación, áreas donde se necesitan de requisitos es un conjunto de actividades que ayudan
aclaraciones, información incompleta, inconsistencias al equipo de trabajo a identificar, controlar y seguir los

En realidad, muchas Revisiones Técnicas son dirigidas a

medida que se desarrolla la especificación del sistema. Es mejor para
el equipo de revisión examinar pequeñas partes de la especificación,
de forma que se pueda centrar la atención en un aspecto específico
de los requisitos.

174
 10 DE S I S T E M A S

requisitos y los cambios en cualquier momento. Muchas miento. En la Figura 10.4 se muestra de forma
de estas actividades son idénticas a las técnicas de ges- esquemática este planteamiento. Cada matriz de
tión de configuración del software que se referencian seguimiento identifica los requisitos relacionados
en el Capítulo 9. con uno o más aspectos del sistema o su entorno.
Entre las posibles matrices de seguimiento citamos
las siguientes:
Referencia Matriz de seguimiento de Muestra
Un artículo titulado ((Configurando el trabajo de gestión los requisitos identificados en relación a las caracte-
de requisitos para contiene una guía pragmático: rísticas definidas por el cliente del
Matriz de seguimiento de orígenes. Identifica el
origen de cada requisito.
Como en la Gestión de Configuración del Software
(GCS), la gestión de requisitos comienza con la activi- Matriz de seguimiento de dependencias. Indica
dad de identificación. A cada requisito se le asigna un cómo se relacionan los requisitos entre sí.
Único que puede tomar la forma: Matriz de Seguimiento de subsistemas. Vincula
de los requisitos a los subsistemas que los manejan.
El tipo de requisito toma alguno de los siguientes Matriz de seguimiento de interfaces. Muestra
valores: F = requisito funcional, = requisito de datos, como los requisitos están vinculados a las interfaces
=requisitode comportamiento, = requisito de externas o internas del sistema.
faz, y = requisito de salida. De esta forma, un requi-
sito identificado como F09 indica que se trata de un
requisito funcional y que tiene asignado el número 9
dentro de los citados requisitos. Cuando un sistema es grande y determinar
las entre las puede ser una tarea
desalentadora. Utilice las de seguimiento
para hacer el trabajo un poco
CLAVE
Muchas actividades de gestión de requisitos En muchos casos, las matrices de seguimiento se
son tomadas de GCS. incorporan como parte de un requisito de base de datos
y se utiliza para buscar rápidamente los diferentes aspec-
Una vez los requisitos han sido identificados, se tos del sistema a construir afectados por el cambio de
desarrollarán un conjunto de matrices para su segui- requisito.

Todos los sistemas basados en computadora pueden

modelarse como una transformación de la información
empleando una arquitectura del tipo
salida. Hatley y Pirbhai han extendido esta
visión para incluir dos características adicionales del
sistema: tratamiento de la interfaz de usuario y trata-
miento del mantenimiento y autocomprobación. Aun-
que 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, sali-
da, tratamiento de la interfaz de usuario y de
probación, un ingeniero de sistemas puede crear un
modelo de componentes de sistema que establezca el fun- Rnn
damento para análisis de requisitos posteriores y etapas
de diseño en cada una de las disciplinas de ingeniería. FIGURA 10.4. Matriz de seguimiento genérica.

175
 DEL SOFTWARE. UN ENFOQUE PR A C T I C O

código de barras equivalente), las cajas se mandarán a los con-

tenedores apropiados. Las cajas pasan aleatoriamente y están
Proceso de interfaz de usuario igualmente espaciadas. La línea se mueve lentamente.

Proceso Funciones de proceso Proceso

de entrada y control de salida

Mantenimiento
y autocomprobación

FIGURA 10.5. Plantilla del modelo del sistema

Para desarrollar el modelo de sistema, se emplea un

FIGURA 10.6. Diagrama de contexto de Arquitectura
esquema del modelado del sistema El inge-
del SCCT (ampliado).
niero 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 sis- Para este ejemplo, la versión ampliada utiliza un PC
tema, (4) salida y ( 5 ) mantenimiento y en la estación clasificadora. El PC ejecuta todo el software
ción. En la Figura 10.5 se muestra el formato del del SCCT; interacciona con el lector de código de barras
esquema de arquitectura. para leer parte de los números de cada caja; interacciona
con la cinta transportadora vigilando los equipos que con-
trolan velocidad en dicha cinta; almacena todos los núme-
ros de pieza clasificados; interacciona con el operador
Otros métodos de sistema toman
de la estación clasificadora para producir una variedad
una a enfoque puede
ser aplicada o estos sistemas, de informes y diagnósticos; envía señales de control al
en los 21 y 22. hardware separador para clasificar las cajas; y se comu-
nica con la estructura central de la automatización de la
fábrica. En la Figura 10.6 se muestra el DCS para SCCT
Como casi todas las técnicas de modelado usadas en (ampliado).
la ingeniería del software y de sistemas, el esquema del
modelado del sistema permite al analista crear una jerar-
quía en detalle. En la parte alta de la jerarquía reside el
diagrama de contexto del sistema (DCS). El diagrama El permite una visión del sistema
de contexto «establece el límite de información entre el que debes los que necesites
sistema que se está implementando y el entorno en que no deben en este nivel. Refina
va a operar» Es decir, el DCS define todos los el para elaborar el sistema.
suministradores externos de información que emplea el
sistema, todos los consumidores externos de informa- Cada caja de la Figura 10.6 representa una entidad
ción creados por el sistema y todas las entidades que se externa, es decir, un suministrador o consumidor de
comunican a través de la interfaz o realizan manteni- información del sistema. Por ejemplo, el lector del códi-
miento y autocomprobación. go de barras produce información que es introducida en
Para ilustrar el empleo del DCS, considere una ver- el sistema SCCT. El símbolo para representar todo el
sión ampliada del sistema de clasificación de cinta trans- sistema (o a niveles más bajos, subsistemas principa-
portadora (SCCT) estudiado anteriormente en el les) es un rectángulo con las esquinas redondeadas. De
Capítulo 5. Al ingeniero del sistema se le presenta la ahí que SCCT se represente en la región de proceso y
siguiente declaración (algo confusa) de objetivos para control en el centro del DCS. Las flechas etiquetadas
el SCCT: mostradas en el DCS representan información (datos y
El sistema SCCT debe desarrollarse de manera que las cajas control) que va desde el entorno exterior al sistema
que se mueven a lo largo de la cinta transportadora sean iden-
tificadas y ordenadas en uno de los seis contenedores al final
SCCT. La entidad externa lector del código de barras
de la cinta. Las cajas pasarán a través de una estación clasifi- produce una entrada de información etiquetada como
cadora donde se identificarán.Basándose en un número de iden- código de barras. En esencia, el DCS sitúa a cualquier
tificación impreso en un lateral de la caja (se proporciona un sistema en el contexto de su entorno exterior.
176
 10 DE SISTEMAS

lnterfaz
Peticiones de operador Respuestas, informes y visualizaciones del SCCT
de
con el
operador

Proceso y control Petición Datos temporal

del SCCT de informe
Subsistema
lector
de código Controlador
de maniobras
de barras

Datos Posición
del código del contenedoi Órdenes de maniobra
Código de barras
de barras
Subsistema
de acceso Informes de SCCT
a la base de datos Subsistema
de configuración
Subsistema Velocidad de informes
del sensor de la cinta
de adquisición Clasificación Controlador
de datos de registros de las
Estado BCR comunicaciones
con la computadora
Estado de maniobra central
Estado del sensor

de tacómetro Estado de comunicaciones Configuración

de impulsos de los datos
Estado del lector del informe
de código de barras
de adquisición
de datos lnterfaz de diagnóstico de salida

10.7. Diagrama de flujo de arquitectura para el SCCT (ampliado).

ejemplo, hardware, software, personas) tal y como los

ha asignado el ingeniero de sistemas.
ElDCS es un del diagrama de de datos, El diagrama inicial de flujo del sistema (DFS) se con-
que se estudia en el Capítulo 12. vierte en el nudo superior de una jerarquía de DFS. Cada
rectángulo redondeado del DFS original puede expan-
El ingeniero de sistemas refina el diagrama de con- dirse en otra plantilla de arquitectura dedicada exclusi-
texto de arquitectura estudiando con más detalle el rec- vamente a ella. Este proceso se ilustra esquemáticamente
tángulo sombreado de la Figura 10.6. Se identifican los en la Figura 10.8. Cada uno de los DFS del sistema pue-
subsistemas principales que permiten funcionar al sis- de usarse como punto de partida de subsiguientes fases
tema clasificador de cinta transportadora dentro del con- de ingeniería para el subsistema que se describe.
texto definido por el DCS. En la Figura 10.7 los
subsistemas principales se definen en un diagrama de
del sistema (DFS) que se obtiene del DCS. El
de información a través de las regiones del DCS se Referencia
para guiar al ingeniero de sistemas en el desarrollo Para concretar el método de se puede acudir a
de DFS (un más detallado del SCCT). El
de flujo de la arquitectura muestra los
temas principales y el flujo de las líneas de información Se pueden especificar (delimitar) los subsistemas y
(datos y control). Además, el esquema del la información que fluyen entre ellos para los subsi-
sistema divide el proceso del subsistema en cada una guientes trabajos de ingeniería. Una descripción narra-
de las cinco regiones de proceso estudiadas anterior- tiva de cada subsistema y una definición de todos los
mente. En este punto, cada uno de los subsistemas pue- datos que fluyen entre los subsistemas son elementos
de contener uno o más elementos del sistema (por importantes de la Especificación del Sistema.
177
 DEL SOFTWARE. U N ENFOQUE

Diafragma de flujo de más alto nivel de la arquitectura

FIGURA 10.8. Construcción de una jerarquía DFA.

Un sistema de alta tecnología comprende varios com- prende una planificación de la estrategia de la infor-
ponentes: hardware, software, personas, bases de datos, mación (PEI),un análisis del área de negocio (AAN) y
documentación y procedimientos. La ingeniería de sis- un análisis específico de aplicación que de hecho for-
temas ayuda a traducir las necesidades del cliente en un man parte de la ingeniería del software.
modelo.de sistema que utiliza uno o más de estos com- La ingeniería de productos es un enfoque de la inge-
ponentes. niería de sistemas que empieza con el análisis del sis-
La ingeniería de sistemas comienza tomando una tema. El ingeniero de sistemas identifica las necesidades
Se analiza el dominio de negocio o del cliente, determina la viabilidad económica y técni-
producto para establecer todos los requisitos básicos. ca, y asigna funciones y rendimientos al software,
El enfoque se estrecha entonces a una de ware, personas y bases de datos; los componente claves
dominio», donde cada uno de los elementos del sis- de la ingeniería.
tema se analiza individualmente. Cada elemento es La ingeniería del sistema demanda una intensa
asignado a uno o más componentes de ingeniería que comunicación entre el cliente y el ingeniero siste-
son estudiados por la disciplina de ingeniería corres- ma. Esto se realiza a través de un conjunto de activi-
pondiente. dades bajo la denominación de ingeniería de requisitos
La ingeniería de procesos de negocio es un enfoque -identificación, análisis y negociación, especificación,
de la ingeniería de sistemas que se usa para definir arqui- modelización, validación y gestión-.
tecturas que permitan a un negocio utlizar la informa- Una vez que los requisitos hayan sido aislados, el
ción eficazmente. La intención de la ingeniería de modelado del sistema puede ser realizado, y las repre-
procesos de negocio es crear minuciosas arquitecturas sentaciones de los subsistemas principales pueden ser
de datos, una arquitectura de aplicación y una infraes- desarrolladas. La tarea de la ingeniería del sistema fina-
tructura tecnológica que satisfaga las necesidades de la liza con la elaboración de una Especificación del Siste-
estrategía de negocio y los objetivos de cada área de ma -un documento que sirve de base para las tareas de
negocio. La ingeniería de procesos de negocio com- ingeniería que se realizarán posteriormente-.

Chnstel, M.G., y K.C. Kang, Requirements Martin, Information Engineering: Book -

Software Engineering Institute, Planning and Prentice Hall, 1990.
92-TR-12 7, September 1992.
Motamarri, Modelling and
Graham, R.M., en Proceedings 1969 NATO Software Engineering Notes, vol. 17, 2,
ference on S o f i a r e Engineering, 1969. 1992, 57-63.
Guttman, M., Requirements for a I., y Sawyer, Requirements
Changing Business Research Briefs from Cutter Wiley, 1997
Consortium online service), June 1999.
Spewak, Architecture QED
Information Engineering for the Publishing, 1993.
Practitioner, Wiley, 1993, pp. 12-13.
Thayer, R.H., y M. Dorfman,
Hatley, D.J., e Pirbhai, Strategies for Real-Time Engineering, ed., IEEE Computer Society
Dorset House, 1987. 1997.
178