Pressman, Cap 5

Pressman, Roger S.; Ingeniera de Software, un enfoque prctico

Tercera edicin, 1993 Editorial McGraw-Hill

Segunda Parte
Anlisis de Requisitos del Sistema y del Software

5 Ingeniera De Sistemas De Computadora

Hace cuatrocientos cincuenta aos, Maquiavelo dijo: "...no hay nada ms difcil de
conseguir, ms arriesgado de mantener ni ms inseguro de tener xito, que estar a la
cabeza en la introduccin de un nuevo orden de cosas..."

Durante el ltimo cuarto del siglo veinte, los sistemas basados en computadora estn
introduciendo un nuevo orden de cosas. Aunque la tecnologa ha hecho grandes
avances desde Maquiavelo, sus palabras siguen siendo ciertas.

La ingeniera del software y la ingeniera del hardware entran dentro de la amplia

categora que llamaremos ingeniera de sistemas de computadora. Cada una de estas
disciplinas representa un intento de establecer un orden en el desarrollo de sistemas
basados en computadora. Las tcnicas de ingeniera para el hardware de
computadoras provienen del diseo electrnico y han alcanzado un estado de relativa
madurez. Las tcnicas de diseo de hardware estn bien establecidas, los mtodos de
fabricacin mejoran continuamente y la fiabilidad es ms una expectativa real que una
modesta esperanza. Desafortunadamente, el software de las computadoras todava
padece la descripcin maquiavlica anteriormente descrita. En los sistemas basados
en computadora, el software ha reemplazado al hardware en el sentido de ser el
elemento del sistema ms difcil de planificar, con menos posibilidad de xito (en tiempo
y en dinero) y ms peligroso de manejar. Mientras los sistemas basados en
computadora continan creciendo en nmero, complejidad y aplicaciones, la demanda
de software contina sin disminuir.

Las tcnicas de ingeniera para la produccin de software de computadora empiezan

ahora a tener una amplia aceptacin. En el primer captulo discutimos la evolucin de
una cultura del software que vio la programacin de computadoras como una forma de
arte. No exista un precedente de ingeniera ni se aplic ningn planteamiento de
ingeniera. Los tiempos estn cambiando!

5.1. SISTEMAS BASADOS EN COMPUTADORA

La palabra "sistema" es posiblemente el trmino ms sobreutilizado y del que ms se

ha abusado en el lxico tcnico. Hablamos de sistemas polticos y educativos, de
sistemas avinicos y de fabricacin, de sistemas bancarios y de ferrocarril. La palabra
nos dice poco. Usamos el adjetivo que la describe para comprender el contexto en el
que se usa. El diccionario Webster la describe as:

1. un conjunto u ordenacin de cosas relacionadas de tal manera que forman una unidad
pg.: 1 de 42
Pressman, Cap 5

o un todo orgnico; 2. un conjunto de hechos, principios, reglas, etc... clasificados y

ordenados de tal manera que muestran un plan lgico uniendo las diferentes partes; 3. un
mtodo o plan de clasificacin u ordenacin; 4. una forma establecida de hacer algo; un
mtodo; un procedimiento...

El diccionario contiene cinco definiciones pero no cita ningn sinnimo. "Sistema" es

una palabra especial.

Tomando prestada la definicin anterior del diccionario Webster, definimos un sistema

basado en computadora como:

Un conjunto u ordenacin de elementos organizados para llevar a cabo algn mtodo,

procedimiento o control mediante el procesamiento de informacin.

En la Figura 5.1 se muestran los elementos de un sistema basado en computadora,

incluyendo los siguientes:

Software. Los programas de computadora, las estructuras de datos y la

documentacin asociada, que sirven para realizar el mtodo lgico, procedimiento
o control requerido.

Figura 5.1. Elementos del sistema.

Hardware. Los dispositivos electrnicos (p. ej.: UCP, memoria) que proporcionan
la capacidad de computacin y los dispositivos electromecnicos (p. ej.: sensores,
motores, bombas) que proporcionan las funciones del mundo exterior.

Gente. Los individuos que son usuarios y operadores del software y del hardware.

Bases de datos. Una coleccin grande y organizada de informacin a la que se

accede mediante el software y que es una parte integral del funcionamiento del
sistema.

Documentacin. Los manuales, los impresos y otra informacin descriptiva que

pg.: 2 de 42
Pressman, Cap 5

explica el uso y/o la operacin del sistema.

Procedimientos. Los pasos que definen el uso especfico de cada elemento del
sistema o el contexto procedimiento en que reside el sistema.

Los elementos se combinan de muchas formas para transformar la informacin. Por

ejemplo, un robot transforma un archivo de rdenes, que contiene instrucciones
concretas, en un conjunto de seales de control que producen alguna accin fsica
concreta.

Una caracterstica compleja de los sistemas basados en computadoras es que los

elementos que componen un sistema pueden tambin representar un macroelemento
de un sistema todava mayor. Un macroelemento es un sistema basado en
computadora que forma parte de un sistema basado en una computadora mayor.
Como ejemplo, consideremos un sistema de automatizacin de una fbrica, que es,
esencialmente, la jerarqua de sistemas que se muestra en la Figura 5.2. En el nivel
ms bajo de la jerarqua tenemos mquinas de control numrico (CN), robots y
dispositivos de entrada de datos. Cada uno es por s mismo un sistema basado en
computadora. Los elementos de las mquinas de CN incluyen hardware electrnico y
electromecnico (p. ej.: procesador y memoria, motores, sensores); software
(comunicaciones, control de las mquinas, interpolacin); gente (operadores de las
mquinas); una base de datos (el programa de CN almacenado); documentacin y
procedimientos. Se podra aplicar una descomposicin similar a los robots y a los
dispositivos de entrada de datos. Cada uno es un sistema basado en computadora.

En el siguiente nivel de la jerarqua (Figura 5.2) se define una clula de fabricacin. La

clula de fabricacin es un sistema basado en computadora que integra elementos
propios (p. ej.: computadoras, fijaciones) y los macroelementos de mquinas de control
numrico, robots y dispositivos de entrada de datos.

Resumiendo, la clula de fabricacin y sus macroelementos estn compuestos por

elementos del sistema con las siguientes etiquetas genricas: software, hardware,
gente, base de datos, procedimientos y documentacin. En algunos casos, los
macroelementos pueden compartir un elemento genrico. Por ejemplo, el robot y la
mquina de CN pueden ser manejados por un slo operador (el elemento gente). En
otros casos los elementos genricos son exclusivos de un sistema.

El papel del ingeniero de sistemas (o analista de sistemas) es el de definir los

elementos de un sistema basado en computadora especfico dentro del contexto de
toda la jerarqua de sistemas (macroelementos). En las siguientes secciones
examinamos las tareas que constituyen la ingeniera de sistemas de computadora.

pg.: 3 de 42
Pressman, Cap 5

Figura 5.2. Un sistema de sistemas.

5.2 INGENIERIA DE SISTEMAS DE COMPUTADORA

La ingeniera de sistemas de computadora 1 es una actividad de resolucin de

problemas. Las funciones que se desean para el sistema son descubiertas, analizadas
y asignadas a elementos individuales del sistema. El ingeniero de sistemas de
computadora (tambin llamado analista de sistemas en algunos mbitos de
informacin) parte de los objetivos y de las restricciones definidas por el usuario y
desarrolla una representacin de la funcin, del rendimiento, de las interfaces, de las
restricciones de diseo y de la estructura de la informacin, todo ello pudiendo ser
asociado a cada uno de los elementos genricos del sistema descritos en la seccin
anterior.

La gnesis de la mayora de los nuevos sistemas comienza con un concepto ms bien

borroso de la funcin deseada. De esa manera, el ingeniero de sistemas debe delimitar
el sistema, identificando el mbito del funcionamiento y el rendimiento deseados. Por
ejemplo, no es suficiente decir que el software de control para el robot del sistema de
automatizacin de fabricacin "ha de responder rpidamente si un compartimento de
piezas est vaco". El ingeniero de sistemas debe definir: (1) lo que supone un
compartimento vaco para el robot; (2) los lmites precisos de tiempo (en segundos) en
los que se espera la respuesta del software; (3) qu formato debe tener la respuesta.

Una vez que la funcin, el rendimiento, las restricciones y las interfaces estn
1
No se deben confundir los trminos ingeniera de sistemas de computadora e ingeniera de computadoras. La
ingeniera de computadoras se centra exclusivamente en el diseo y la implementacin del hardware de
computadora y su software de sistema asociado, mientras que la ingeniera de sistemas de computadora se
aplica a todos los productos y sistemas que contienen computadoras.

pg.: 4 de 42
Pressman, Cap 5

delimitadas, el ingeniero de sistemas procede a realizar la tarea denominada

asignacin. Durante la asignacin, las funciones son asignadas a uno o ms elementos
genricos del sistema (esto es, software, hardware, gente, etc.). A menudo se
proponen y evalan varias asignaciones. Para ilustrar el proceso de asignacin,
consideremos otro macro elemento del sistema de automatizacin de fabricacin el
sistema de clasificacin en cinta transportadora (SCCT) que se present en el Captulo
3. Al ingeniero de sistemas se le presenta el siguiente conjunto (un poco borroso) de
objetivos para el SCCT:

El SCCT debe ser desarrollado de tal manera que las cajas que se mueven a lo largo de
la cinta sean identificadas y clasificadas en uno de los seis compartimentos al final de la
cinta. Las cajas pasarn por una estacin de clasificacin donde sern identificadas.
Basndose en un nmero de identificacin, impreso en un lado de la caja (incluyendo un
cdigo de barras equivalente), las cajas sern dirigidas a los compartimentos
correspondientes. Las cajas pasan en un orden aleatorio y espaciadas uniformemente.
La cinta se mueve despacio.

En la Figura 3.2 se muestra esquemticamente el sistema SCCT. Antes de continuar,

hagamos una lista de preguntas que haramos si fusemos el ingeniero de sistemas.

Entre las muchas preguntas que se deberan plantear y responder estn las siguientes:

1. Cuntos nmeros de identificacin diferentes van a ser procesados y cul es su

forma?
2. Cul es la velocidad de la lnea de transporte en metros/segundo y cul es la
distancia entre cajas en metros?
3. A qu distancia est la estacin de clasificacin de los compartimentos?
4. A qu distancia estn los compartimentos entre s?
5. Qu debe ocurrir si una caja no tiene el nmero de identificacin o tiene un
nmero incorrecto?
6. Qu ocurre cuando se llena un compartimento?
7. Hay que mandar informacin sobre el destino de la caja y el contenido de los
compartimentos a algn otro lugar del sistema de automatizacin de la fbrica?
Se requiere adquisicin de datos en tiempo real?
8. Qu frecuencia de error/fallo es aceptable?
9. Qu partes del sistema de cinta transportadora existen actualmente y son
operativas?
10. Qu restricciones de tiempo y presupuesto nos vienen impuestas?

Se puede observar que las cuestiones anteriores se centran en el funcionamiento,

rendimiento, flujo de informacin y contenido. El ingeniero de sistemas no pregunta al
cliente cmo se va a realizar la tarea; en vez de eso, lo que pregunta es qu se
necesita.

Asumiendo que las respuestas son razonables, el ingeniero de sistemas desarrolla un

nmero de asignaciones alternativas. Se puede observar que el funcionamiento y
rendimiento estn asociados a diferentes elementos genricos del sistema en cada
asignacin.

pg.: 5 de 42
Pressman, Cap 5

Asignacin 1 Se ensea a un operador a clasificar y se le sita en la estacin de

clasificacin. El o ella lee la caja y la sita en el compartimento adecuado.

La asignacin 1 representa una solucin manual (a pesar de todo efectiva) al problema

del SCCT. El elemento primario del sistema es la gente (el operador que clasifica). La
persona realiza todas las funciones de clasificacin. Puede requerirse alguna
documentacin (en forma de tabla que relacione el nmero de identificacin con el
compartimento adecuado y una descripcin de procedimientos para el entrenamiento
del operador). As, esta asignacin utiliza slo los elementos gente y documentacin.

Asignacin 2 Se colocan un lector de cdigo de barras y un controlador en la estacin

de clasificacin. La salida del lector de barras pasa a un controlador programable que
controla un mecanismo de separacin. El separador dirige la caja hacia el
compartimento apropiado.

Para la asignacin 2, se usan el hardware (lector de cdigos de barras, control

programable, mecanismo de separacin, etc.); el software (para el lector de cdigos de
barras y el controlador programable) y la base de datos (una tabla donde se relaciona el
identificador de las cajas con los compartimentos) para conseguir una solucin de
automatizacin total. Cualquiera de estos elementos del sistema puede tener sus
correspondientes manuales y otra documentacin, aadiendo otro elemento genrico
del sistema.

Asignacin 3 Se colocan un lector de cdigo de barras y un controlador en la estacin

de clasificacin. La salida del lector de cdigos de barras pasa a un brazo de robot que
coge la caja y la coloca en el compartimento apropiado.

La asignacin 3 hace uso de elementos genricos del sistema y de un macroelemento,

el robot. Al igual que la asignacin 2, esta asignacin utiliza hardware, software, una
base de datos y documentacin como elementos genricos. El robot es un macro
elemento del SCCT y por s mismo contiene un conjunto de elementos genricos de
sistema.

Examinando las tres asignaciones alternativas para el SCCT, debera resultar obvio que
la misma funcin puede ser asignada a diferentes elementos del sistema. Para elegir la
asignacin ms efectiva, se debe aplicar un conjunto de criterios de evaluacin a cada
alternativa.

Los siguientes criterios de evaluacin controlan la seleccin de una configuracin del

sistema basndose en una asignacin especfica de funcionalidad y rendimiento a
elementos genricos del sistema:

Consideraciones del proyecto. Puede ser construida la configuracin dentro de los

lmites preestablecidos de coste y tiempo? Cul es el riesgo asociado a las
estimaciones de tiempo y coste?

Consideraciones comerciales. Representa la configuracin la solucin ms beneficiosa?

Puede ser lanzada con xito? Compensarn los beneficios a los riesgos del
desarrollo?

pg.: 6 de 42
Pressman, Cap 5

Anlisis tcnico. Existe tecnologa para desarrollar todos los elementos del sistema?
Estn aseguradas la funcionalidad y el rendimiento? Podr mantenerse correctamente
la configuracin? Existen recursos tcnicos? Cul es el riesgo asociado con la
tecnologa?

Evaluacin de la fabricacin. Hay disponibles instalaciones y equipos de fabricacin?

Hay escasez de los componentes necesarios? Puede llevarse a cabo adecuadamente
una garanta de calidad?

Aspectos humanos. Existe personal cualificado disponible para el desarrollo y la

fabricacin? Existen problemas polticos? Comprende el cliente lo que va a hacer el
sistema?

Interfaces con el entorno. Funciona correctamente la interfaz de la configuracin

propuesta con el entorno externo del sistema? Se manejan inteligentemente las
comunicaciones mquina - mquina y hombre - mquina?

Consideraciones legales. Introduce esta configuracin un riesgo de responsabilidad

indebido? Pueden ser protegidos adecuadamente los aspectos de propiedad? Existe
una infraccin potencial?

Examinaremos algunos de estos aspectos con ms detalle ms adelante en este

captulo.

Es importante hacer notar que el ingeniero de sistemas debe considerar tambin

soluciones estndar al problema del cliente. Existe un sistema equivalente? Pueden
ser adquiridas las partes ms importantes del producto a un tercero?

la aplicacin de criterios de evaluacin supone la seleccin de la configuracin de un

sistema especfico y la especificacin del funcionamiento y del rendimiento asignados al
hardware, al software (y al firmware - microinstrucciones), a la gente, a las bases de
datos, a la documentacin y a los procedimientos. Esencialmente, lo que se hace es
asignar a cada elemento del sistema un mbito de funcionamiento y de rendimiento. La
ingeniera del hardware, la ingeniera del software, la ingeniera humana y la ingeniera
de bases de datos estn para refinar el mbito y producir un elemento del sistema
capaz de funcionar que pueda ser integrado adecuadamente con otros elementos del
sistema.

5.2.1. Hardware e ingeniera del hardware

El ingeniero de sistemas de computadora selecciona alguna combinacin de

componentes de hardware que constituyen un elemento del sistema basado en
computadora. La seleccin del hardware, aunque no es una tarea sencilla, que se
facilitada por una serie de caractersticas: (1) los componentes estn empaquetados
como bloques constitutivos individuales; (2) las interfaces entre componentes estn
estandarizadas; (3) estn disponibles numerosas alternativas preparadas"; (4) el
rendimiento, coste y disponibilidad son relativamente fciles de determinar.

pg.: 7 de 42
Pressman, Cap 5

Una configuracin del hardware evoluciona de una jerarqua de "bloques constitutivos".

Los componentes discretos (p. ej.: circuitos integrados y componentes electrnicos
tales como resistencias, condensadores, etc.) se ensamblan en una tarjeta de circuito
impreso (CI) que realiza un conjunto especfico de operaciones. Las tarjetas se
interconectan con un bus (un camino de informacin y de control) para formar
componentes del sistema (p. ej.: una tarjeta de la computadora) que a su vez se
integran en un subsistema de hardware o elemento del sistema. Puesto que la
integracin a muy gran escala ya es comn, funciones que antes estaban disponibles
en un conjunto de tarjetas de circuito impreso con docenas de circuitos integrados,
ahora estn disponibles en un chip.

La ingeniera del hardware para computadoras digitales surgi de los precedentes

establecidos en dcadas de diseo electrnico. El proceso de la ingenia del hardware
puede verse en tres fases: planificacin y especificacin; implementacin del diseo y
del prototipo; fabricacin, distribucin y mantenimiento. Las fases se ilustran en la
Figura 5.3 a, b y c.

Una vez que se ha definido la ingeniera del sistema (anlisis y definicin sistema), se
asignan funciones al hardware. La primera fase de la ingeniera hardware (Figura 5.3
a) comprende la planificacin del desarrollo y el anlisis de los requisitos del hardware.
La planificacin del desarrollo se orienta a establecer el alcance del esfuerzo en
hardware. Para esto nos hacemos las siguientes preguntas:

Qu clase de hardware se adapta mejor a las funciones especificadas?

Qu hardware se puede comprar? cules son los proveedores, la
disponibilidad y el coste?
Qu tipos de interfaces se requieren?
Qu tenemos que disear y construir? cules son los problemas potenciales
y los recursos requeridos?

A partir de estas y otras cuestiones, se deben establecer los costes preliminares y los
plazos de realizacin del sistema de hardware. Estas estimaciones son revisadas por
los responsables y el personal tcnico apropiado para ser modificadas si fuese
necesario.

A continuacin debemos establecer una gua de acciones" para el diseo del hardware
y su implementacin. El anlisis de los requisitos del hardware se orienta a especificar
requisitos funcionales, de rendimiento y de interfaz precisos para todos los
componentes del elemento de hardware. Adems, deben establecerse las restricciones
del diseo (por ejemplo, tamao, entorno) y los criterios de prueba. Frecuentemente se
realiza una especificacin del hardware. En esta etapa hay que tomar en consideracin
muy especialmente las revisiones y las modificaciones.

La popular imagen de la ingeniera en "mangas de camisa" est caracterizada en la

segunda fase (Figura 5.3 b). Se analizan los requisitos y se disea una configuracin
preliminar del hardware. Las revisiones tcnicas se suceden a medida que el diseo
evoluciona hacia esquemas de ingeniera detallados (especificaciones de diseo). Hoy

pg.: 8 de 42
Pressman, Cap 5

en da, el anlisis y el diseo se gestionan mediante herramientas de ingeniera asistida

por computadora y diseo asistido por computadora (del ingls, CAE/CAD). Se
compran componentes ya hechos, se construyen los componentes a medida y se
ensambla un prototipo. Se prueba el prototipo para asegurar que cumple todos los
requisitos.

Figura 5.3. Ingeniera del hardware. (a) fase I; (b) fase II; (c) fase III.

El prototipo (a veces denominado modelo de "placa de prueba" en electrnica),

pg.: 9 de 42
Pressman, Cap 5

normalmente, se parece poco al producto final. Por tanto, lo que se va derivando son
las especificaciones para la fabricacin. Las placas de prueba se convierten en placas
de PC; las (EPROM) y (PROM) se convierten en ROM; se disean las carcasas; se
definen las herramientas y el equipamiento. El enfoque cambia, de la funcionalidad y el
rendimiento, a la facilidad de fabricacin.

La tercera fase de la ingeniera del hardware requiere pocas atenciones directas por
parte del ingeniero de diseo, pero pone a prueba las habilidades del ingeniero de
fabricacin. Antes de que empiece la produccin, se deben establecer mtodos para
garantizar la calidad, as como un mecanismo de distribucin del producto. En el
inventario se registran los repuestos y se establece una organizacin de servicio in situ
que se encargue del mantenimiento y de la reparacin del producto. En la Figura 5.3c
se ilustra la fase de fabricacin de la ingeniera del hardware.

5.2.2. Software e ingeniera del software

Las caractersticas del software y de la ingeniera del software ya se han discutido en

detalle en el Captulo 1. En esta seccin vamos a resumir el estudio anterior dentro del
contexto de la ingeniera de sistemas de computadora.

Durante la ingeniera del sistema se asigna la funcin y el rendimiento al software. En

algunos casos, la funcin es simplemente la implementacin de un procedimiento
secuencial de manipulacin de datos. El rendimiento no queda explcitamente definido.
En otros casos, la funcin es la coordinacin y control internos de otros programas
concurrentes y el rendimiento est definido de forma explcita en trminos de tiempo de
espera y de respuesta.

Para conseguir la funcin y el rendimiento, el ingeniero de software debe construir

adquirir una serie de componentes de software. A diferencia del hardware, los
componentes de software estn muy poco estandarizados 2. En la mayora de los
casos, el ingeniero de software crea componentes a medida para satisfacer los
requisitos asignados al elemento de software que se va a desarrollar.

El elemento de software de un sistema basado en computadora est compuesto por

programas, datos y documentacin que constituyen el software de la aplicacin y el
software del sistema. El software de la aplicacin implementa los procedimientos
requeridos para realizar las funciones de procesamiento de la informacin. El software
del sistema implementa funciones de control que permiten al software de la aplicacin
comunicarse con otros diversos elementos de software.

Las reas genricas de aplicacin del software ya han sido descritas en la Seccin
1.2.3. En esta seccin consideramos la aplicacin del software en el contexto ms
amplio de los sistemas basados en computadora. Independientemente de su rea de
aplicacin, un sistema basado en computadora puede ser representado mediante un
modelo de entrada proceso - salida (EPS). El elemento de software juega un papel
2
El uso de las tcnicas orientadas a los objetos (captulos 8 y 12) puede llevarnos a disponer de una amplia serie
de CIs de software - bloques de construccin de software reutilizables.

pg.: 10 de 42
Pressman, Cap 5

en cada aspecto del modelo.

El software se usa para adquirir informacin que puede ser suministrada por alguna
fuente externa o por otro elemento del sistema (incluyendo macroelementos). Cuando
un sistema basado en computadora requiere una interfaz interactiva entre hombre y
mquina, el software implementa la "conversacin" de E/S. En el software se
implementan los mecanismos de peticin y de entrada de datos; con el software se
generan las pantallas y los grficos y, mediante el software, se lleva a cabo la lgica
que conduce al usuario a travs de la secuencia de pasos interactivos. Cuando se
adquieren los datos desde un dispositivo, el software, en forma de controlador,
acomoda las caractersticas especiales del hardware. Por ltimo, el software tambin
se usa para establecer interfaces con las bases de datos, permitiendo a un programa
acceder a fuentes de datos pre-existentes.

El software implementa los algoritmos de procesamiento requeridos para realizar las

funciones del sistema. En general, un algoritmo de procesamiento transforma datos de
entrada y produce informacin o control como salida para otro elemento del sistema o
macroelementos. Hoy en da, el tipo ms comn de procesamiento es el procedimiento
numrico o no numrico en el que todos los pasos, bucles y condiciones estn
predefinidos. Sin embargo, en algunos sistemas basados en computadora se estn
introduciendo nuevas categoras de algoritmos de procesamiento, como el software de
sistemas expertos y las redes neuronales artificiales. A diferencia de los algoritmos
convencionales, los sistemas expertos [RAE9O] utilizan hechos especficos y reglas
para inferir, permitiendo al software mostrar habilidades de diagnosis parecidas a las
humanas, en un mbito de problemas limitado. A diferencia dei software de sistemas
expertos, una red neuronal artificial [WAS89] imita las funciones de las neuronas del
cerebro humano y han mostrado buenas expectativas en el reconocimiento de patrones
y el aprendizaje automtico.

Para que un sistema basado en computadora sea de uso prctico, el software debe
proporcionar informacin o control a otro elemento del sistema o a una fuente externa.
Para producir la informacin de salida, el software debe dar un formato a los datos que
resulte apropiado para el medio de salida y saber cmo comunicarse con el dispositivo
de salida (p. ej.: impresora, disco ptico, dispositivo de visualizacin de una estacin de
trabajo).

La ingeniera del software es una disciplina para el desarrollo de software de alta

calidad para sistemas basados en computadora. En el Captulo 1 tratamos la ingeniera
del software con detalle e identificamos cuatro paradigmas para la ingeniera del
software, el ciclo de vida clsico, la creacin de prototipos, el modelo en espiral y las
tcnicas de cuarta generacin. Cada uno es distinto de los otros, pero todos
contemplan tres grandes fases. Examinaremos estas fases en base al flujo de sucesos
que se producen, de forma anloga a como lo hicimos con el proceso de ingeniera del
hardware.

Las Figuras 5.4 a, b y c ilustran los pasos genricos del proceso de ingeniera del
software. Las distintas partes de la Figura ilustran los pasos que se deben llevar a cabo
y las distintas representaciones del software que se derivan segn se evoluciona del
concepto a la realizacin.
pg.: 11 de 42
Pressman, Cap 5

Fase de definicin. La fase de definicin de la ingeniera del software, representada

en la Figura 5.4a, comienza con la etapa de planificacin del software. Durante esta
etapa se desarrolla una descripcin bien delimitada del mbito del esfuerzo de software;
se lleva a cabo un anlisis del riesgo; se definen los recursos necesarios para
desarrollar el software; se establecen las estimaciones de tiempos y costes. El
propsito de la etapa de planificacin del software es proporcionar una indicacin
preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se
hayan establecido. La gestin del proyecto realiza y revisa un plan del proyecto de
software.

El siguiente paso en la fase de definicin es el anlisis y la definicin de los requisitos

del software. En este paso se define en detalle el elemento del sistema asignado al
software. Los requisitos se analizan y se definen de una de dos maneras. Se puede
hacer un anlisis formal del mbito de informacin para establecer modelos del flujo y la
estructura de la informacin. Luego, se amplan esos modelos para convertirlos en una
especificacin del software. Alternativamente, se puede construir un prototipo del
software, que ser evaluado por el cliente para intentar consolidar los requisitos. Los
requisitos de rendimiento y las limitaciones de recursos se traducen en caractersticas
para el diseo del software. El anlisis global del elemento de software define los
criterios de validacin que se utilizarn para demostrar que se han podido conseguir los
requisitos.

El anlisis y definicin de los requisitos del software es un esfuerzo conjunto llevado a

cabo por el desarrollador del software y el cliente. La especificacin de requisitos del
software es el documento distribuible que se produce como resultado de esta etapa.

La fase de definicin culmina con una revisin tcnica de la especificacin de requisitos

del software (o, en lugar de la especificacin, del prototipo del software) realizada por el
desarrollador y el cliente. Una vez que se han definido los requisitos, se vuelve a
revisar el plan del software con el fin de comprobar que sigue siendo correcto. La
informacin no cubierta durante el anlisis de requisitos puede influir en las
estimaciones hechas durante la planificacin. Los elementos distribuibles desarrollados
durante la fase de definicin constituyen la base de partida para la segunda fase del
proceso de desarrollo de software.

Fase de desarrollo. La fase de desarrollo (Figura 5.4b) traduce un conjunto de

requisitos en el elemento operativo del sistema que llamamos software. En las
primeras etapas del desarrollo, el ingeniero de hardware no utiliza un soldador. El
ingeniero de software no pasa a utilizar un compilador. Primero se debe realizar el
diseo.

El primer paso de la fase de desarrollo se centra en el diseo. El proceso de diseo del

software comienza con una descripcin del diseo arquitectnico y de datos. Es decir,
se desarrolla una estructura modular, se definen las interfaces y se establece la
estructura de los datos. Se siguen criterios de diseo que aseguren la calidad. Se
revisa el paso preliminar de diseo para garantizar la completitud y el seguimiento de
los requisitos del software. Se produce un primer borrador de la especificacin del

pg.: 12 de 42
Pressman, Cap 5

diseo3, convirtindose en una parte de la configuracin del software.

Figura 5.4. Ingeniera del software (a) Fase de definicin; (b) Fase de desarrollo; (c) Fase de
verificacin, lanzamiento y mantenimiento.

3
Actualmente se puede crear la especificacin del diseo con herramientas CASE especializadas (p. ej.:
Teamwork, de Cadre) y mantenerlo en forma legible para la mquina. En algunos casos, la documentacin del
diseo, denominada lenguaje de diseo de programa, se incluye directamente en los archivos del cdigo fuente.

pg.: 13 de 42
Pressman, Cap 5

A continuacin, se consideran los aspectos procedimentales de cada componente

modular del diseo del software. Cada descripcin procedimental detallada se aade a
la especificacin del diseo, una vez revisada.

Una vez terminado el diseo, se lleva a cabo la codificacin - la generacin de un

programa que use un lenguaje de programacin apropiado o una herramienta CASE.
La metodologa de la ingeniera del software contempla la codificacin como la
consecuencia de un buen diseo. En cuanto al cdigo, se revisa su estilo y su claridad,
y se comprueba que haya una correspondencia directa con la descripcin detallada del
diseo. El listado en lenguaje fuente de cada componente modular constituye el
documento de configuracin de la etapa de codificacin.

Fase de verificacin, lanzamiento y mantenimiento. Durante la ltima fase del

proceso de ingeniera del software (Figura 5.4c), el ingeniero de software prueba el
software para encontrar el mayor nmero posible de errores antes de que sea puesto
en circulacin, lo prepara para su lanzamiento y lo mantiene a lo largo de toda su vida
til.

Despus de haber generado el cdigo fuente, se lleva a cabo una serie de actividades
de verificacin y validacin. Las pruebas de unidad intentan verificar el rendimiento
funcional de cada componente modular individual del software. La prueba de
integracin constituye un medio de construccin de la arquitectura del software y de
prueba de su funcionamiento y de sus interfaces. La prueba de validacin comprueba
que se han conseguido todos los requisitos. Tras cada uno de estos pasos de prueba,
puede que haya de realizarse una depuracin - diagnstico y correccin de defectos.
Para los pasos de prueba, se puede desarrollar un plan y procedimiento de prueba.
Siempre se realiza una revisin de la documentacin, de los casos de prueba y de los
resultados de las pruebas.

Una vez terminada la prueba del software, ste est casi preparado para ser entregado
a los usuarios finales. Sin embargo, antes de la entrega se lleva a cabo una serie de
actividades de garanta de calidad (GC) para asegurar que se han generado y
catalogado los registros y los documentos internos adecuados, que se ha desarrollado
una documentacin de alta calidad para el usuario y que se han establecido los
mecanismos apropiados de control de configuraciones. Entonces, el software ya puede
ser distribuido a los usuarios finales.

Tan pronto como se entregue el software a los usuarios finales, el trabajo del ingeniero
del software cambia. En ese momento, el enfoque cambia de la construccin al
mantenimiento - correccin de errores, adaptacin al entorno y mejora de la funcin. El
reconocimiento de este hecho es el primer paso hacia una disminucin del impacto de
una tarea que consume entre el 50 y el 70 por 100 del presupuesto de muchas grandes
empresas de software. Las tareas asociadas con el mantenimiento del software
dependen del tipo de mantenimiento a realizar. En todos los casos, la modificacin del
software no slo afecta al cdigo, sino a la configuracin entera (es decir, todos los
documentos, datos y programas desarrollados en las fases de planificacin y
desarrollo).

pg.: 14 de 42
Pressman, Cap 5

5.2.3. Factores humanos e ingeniera humana

Un sistema basado en computadora casi siempre tiene un elemento humano. Puede

que una persona interacte directamente con el hardware y con el software,
manteniendo un dilogo que dirija el funcionamiento del sistema; en cualquier caso, la
responsable del desarrollo y del mantenimiento del sistema es la gente.

Nuestra percepcin del elemento humano de los sistemas basados en computadora ha

cambiado en los ltimos aos. Los primeros sistemas basados en computadora
forzaban al usuario a comunicarse de una forma que fuera fcil de implementar en
hardware y en software (si bien no siempre fuera fcil la comunicacin en el contexto
humano). Hoy, la expresin "amigable con el usuario" tiene un nuevo significado. La
ingeniera humana para los sistemas basados en computadora es considerada como un
paso importante del desarrollo de sistemas.

Cuando la gente interacta con otra gente, un conjunto de reglas, esperas y respuestas,
culturalmente definidas, permiten que la interaccin se realice suavemente.
Desgraciadamente, los convenios existentes para la interaccin entre personas, no
estn presentes cuando lo que se pretende es una interaccin hombre maquina (IHM).

Antes de que el ingeniero de sistemas pueda asignar una funcin al elemento humano,
se debe especificar la interaccin que es necesaria para poder realizar la funcin. Para
hacerlo, se deben entender los "componentes" del elemento humano. Entre los muchos
componentes que constituyen el elemento humano se encuentran: la memoria humana
y la representacin del conocimiento, el pensamiento y el razonamiento, la percepcin
visual y la construccin del dilogo humano.

La ingeniera humana es una actividad multidisciplinaria que aplica un conocimiento

derivado de la psicologa para especificar y disear IHM de alta calidad. El proceso de
la ingeniera humana comprende los siguientes pasos:

Anlisis de actividad. Cada actividad asignada a un elemento humano se evala

en el contexto de la interaccin requerida con otros elementos. Cada actividad se
subdivide en tareas que son analizadas en etapas posteriores.

Anlisis y diseo semntico. Se define el significado preciso de cada accin

requerida del usuario y de cada accin producida por la mquina. Se establece el
diseo de un "dilogo" que comunique adecuadamente la semntica.

Diseo lxico y sintctico. Se identifica y representa la forma especfica de las

acciones y las rdenes. Despus, se disea la implementacin en software y en
hardware de cada accin u orden.

Diseo del entorno de usuario. El hardware, software y otros elementos del

sistema se combinan para formar un entorno de usuario. El entorno puede incluir
facilidades fsicas (brillo, utilizacin del espacio, etc.), adems de la propia IHM.

Creacin de prototipos. Es difcil, si no imposible, especificar formalmente una

pg.: 15 de 42
Pressman, Cap 5

IHM sin usar un prototipo. La creacin de prototipos permite evaluar la IHM desde
una perspectiva humana, con una participacin activa en lugar de una evaluacin
pasiva. La creacin de prototipos supone una evaluacin y una aplicacin iterativa
de todos los pasos de ingeniera humana anteriores.

En el Captulo 14 se incluye un tratamiento ms detallado de los factores humanos y de

la ingeniera humana (aplicada al diseo de interfaces de usuario).

5.2.4. Bases de datos e ingeniera de bases de datos

No todos los sistemas basados en computadora hacen uso de una base de datos, pero
para aquellos que s lo hacen, ese almacn de informacin a menudo es crucial para el
funcionamiento general del sistema. La ingeniera de bases de datos (trmino
relativamente nuevo que comprende anlisis, diseo e implementacin de bases de
datos) es una disciplina tcnica que se aplica una vez que se ha definido el mbito de la
informacin. Por ello, el papel del ingeniero de sistemas es el de definir la informacin
que va a contener la base de datos, los tipos de peticiones que se podrn procesar, la
manera en que se acceder a los datos y la capacidad de la base de datos. Aunque la
ingeniera de bases de datos es un tema que requiere un estudio en profundidad (vase
[DAT86], IEEE89]), el anlisis y el diseo de los datos son actividades fundamentales
de la ingeniera del software, independientemente de la presencia o no de una base de
datos formal. Estos temas de la ingeniera de bases de datos, llamados colectivamente
diseo de datos, se estudian en los Captulos 8, 9 y 10.

5.3. ANALISIS DEL SISTEMA

El anlisis del sistema es una actividad que engloba la mayora de las tareas que
hemos llamado colectivamente ingeniera de sistemas basados en computadora.
Algunas veces se incurre en confusin porque el trmino se usa a menudo en un
contexto que alude slo a las actividades de anlisis de los requisitos del software
(vanse los Captulos 6 al 9). Para el propsito de este estudio, el anlisis del sistema
se centra en todos los elementos del sistema - no slo en el software.

El anlisis del sistema se realiza teniendo presentes los siguientes objetivos: (1)
identificar las necesidades del cliente; (2) evaluar la viabilidad del sistema; (3) realizar
un anlisis tcnico y econmico; (4) asignar funciones al software, al hardware, a la
gente, a la base de datos y a otros elementos del sistema; (5) establecer restricciones
de coste y tiempo; (6) crear una definicin del sistema que sea la base para todo el
trabajo posterior de ingeniera. Para alcanzar con xito esos objetivos, se requiere
experiencia, tanto en hardware como en software (as como en ingeniera humana y en
bases de datos). Aunque la mayora de los profesionales de la industria reconocen que
el tiempo y el esfuerzo gastado en el anlisis de sistemas producen dividendos
importantes ms adelante en el proceso de desarrollo del sistema, todava surgen tres
preguntas:

pg.: 16 de 42
Pressman, Cap 5

Cunto esfuerzo se debe emplear en el anlisis y en la definicin de sistemas y

de software? Es difcil establecer unas directrices definitivas para determinar el
esfuerzo de anlisis. El tamao del sistema y su complejidad, el rea de
aplicacin, el uso final y las obligaciones del contrato son slo unas pocas de las
muchas variables que afectan al esfuerzo total dedicado al anlisis. Una regla de
"andar por casa" usada a menudo es que se debe dedicar entre el 10 y el 20 por
100 de todo el esfuerzo de desarrollo al anlisis del sistema y aplicar otro 10 o 20
por 100 del esfuerzo de la ingeniera del software del anlisis de los requisitos del
software.
Quin lo hace? Todas las tareas han de ser dirigidas por un analista bien formado
y con experiencia. El analista trabaja en contacto con el personal tcnico y
administrativo, tanto del cliente como del que desarrolla el sistema. Para muchos
proyectos grandes, debe crearse un equipo para cada tarea de anlisis.
Por qu es tan difcil? Se trata de una transformacin de un concepto dudoso en
un conjunto concreto de elementos tangibles. Debido a que durante el anlisis la
comunicacin es excepcionalmente densa, abundan las oportunidades de mal
entendimiento, omisiones, inconsistencias y errores. Finalmente, la percepcin del
sistema puede cambiar a medida que avanza la actividad, invalidando, de esta
manera, el trabajo anterior.

5.3.1 Identificacin de las necesidades

El primer paso del proceso de anlisis del sistema implica la identificacin de las
necesidades. El analista (ingeniero de sistemas) se entrevista con el cliente o su
representante. El cliente puede ser un representante de una compaa externa, del
departamento de marketing de la compaa del analista (cuando se est definiendo un
producto) o de otro departamento tcnico (cuando se va a desarrollar un sistema
interno).

La identificacin de las necesidades es el punto de partida en la evolucin de un

sistema basado en computadora. La Figura 5.5 muestra las entradas que se le
suministran al analista como parte de este paso. Para empezar, el analista da
asistencia al cliente definiendo los objetivos del sistema (producto): la informacin que
se va a obtener, la informacin que se va a suministrar, las funciones y el rendimiento
requerido. El analista se asegura de distinguir entre lo que "necesita" el cliente
(elementos crticos para la realizacin) y lo que el cliente "quiere" (elementos deseables
pero no esenciales).

Una vez que se han identificado todos los objetivos, el analista pasa a una evaluacin
de la informacin suplementaria: existe la tecnologa necesaria para construir el
sistema? qu recursos de fabricacin y de desarrollo especiales se requerirn? qu
lmites se han impuesto a los costes y a la agenda? Si el nuevo sistema es un producto
que va a ser desarrollado para venderlo a muchos clientes, tambin se hacen las
siguientes preguntas: cul es el mercado potencial para el producto? cmo se
compara este producto con los de la competencia? qu lugar ocupa este producto
dentro de la lnea global de la compaa?

pg.: 17 de 42
Pressman, Cap 5

La informacin recogida durante la etapa de identificacin de las necesidades se

especifica en un documento de conceptos del sistema. A veces, es el cliente el que
prepara un documento de conceptos inicial antes de reunirse con el analista.
Invariablemente, los resultados de la comunicacin analista - cliente producen
modificaciones en el documento.

5.3.2. Estudio de viabilidad

Todos los proyectos son realizables con recursos ilimitados y un tiempo infinito!
Desafortunadamente, el desarrollo de un sistema basado en computadora se
caracteriza por la escasez de recursos y la dificultad (si no imposibilidad) de cumplir los
plazos de entrega. Es necesario y prudente evaluar la viabilidad de un proyecto lo
antes posible. Se pueden evitar meses o aos de esfuerzo, miles de millones de
pesetas y una inversin profesional incalculable, si un sistema mal concebido es
reconocido como tal al principio de la etapa de definicin.

Figura 5.5. Informacin requerida por el analista.

El anlisis de viabilidad y el anlisis del riesgo (Captulo 4) estn relacionados de varias

maneras. Si el riesgo del proyecto es grande (por cualquiera de las razones vistas en el
Captulo 4), se reduce la posibilidad de producir software de calidad. Sin embargo,
durante la ingeniera del sistema centramos nuestra atencin en cuatro reas de inters
bsico:

Viabilidad econmica. Una evaluacin del coste de desarrollo frente al beneficio

final producido por el sistema desarrollado.

Viabilidad tcnica. Un estudio de la funcionalidad, el rendimiento y las

restricciones que pueden afectar a la posibilidad de realizacin de un sistema
aceptable.

Viabilidad legal. Una determinacin de cualquier infraccin, violacin o ilegalidad

que pudiera resultar del desarrollo del sistema.

Alternativas. Una evaluacin de los enfoques alternativos para el desarrollo del

pg.: 18 de 42
Pressman, Cap 5

sistema

No ser necesario llevar a cabo un estudio de viabilidad para sistemas en los que la
justificacin econmica es obvia, el riesgo tcnico es bajo, se esperan pocos problemas
legales y no existe una alternativa razonable. Sin embargo, cuando no se da alguna de
las anteriores condiciones, debe realizarse el estudio.

La justificacin econmica es normalmente la principal consideracin para la mayora

de los sistemas (excepciones notables son los sistemas de defensa nacional, los
sistemas impuestos por la ley y las aplicaciones de alta tecnologa, como el programa
espacial). La justificacin econmica comprende un amplio rango de aspectos, entre
los que se encuentran el anlisis de coste - beneficio (tratado en la siguiente seccin),
las estrategias de ingresos a largo plazo, el impacto en otros productos o en centros de
explotacin, el coste de los recursos que se necesitan para el desarrollo y el
crecimiento potencial del mercado.

La viabilidad tcnica es frecuentemente el rea ms difcil de evaluar en esta etapa del

proceso de desarrollo del sistema. Debido a que los objetivos, las funciones y el
rendimiento son de alguna manera confusos, cualquier cosa puede parecer posible si
se hacen las consideraciones adecuadas. Es esencial que el proceso de anlisis y de
definicin se realice en paralelo con el anlisis de viabilidad tcnica. De esta forma, se
pueden juzgar las especificaciones concretas segn se van determinando.

Las consideraciones que van asociadas normalmente a la viabilidad tcnica son:

Riesgo del desarrollo. Puede el elemento del sistema ser diseado de tal forma
que las funciones y el rendimiento necesarios se consigan dentro de las
restricciones determinadas en el anlisis?

Disponibilidad de recursos. Hay personal cualificado para desarrollar el elemento

del sistema en cuestin? Estn disponibles para el sistema otros recursos
necesarios (de hardware y de software)?

Tecnologa. Ha progresado la tecnologa relevante lo suficiente como para poder

soportar el sistema?

Los desarrolladores de los sistemas basados en computadora son optimistas por

naturaleza. (Quin ms tiene el suficiente coraje para intentar hacer aquello a lo que
nosotros frecuentemente nos comprometemos sin pensarlo mucho?) Sin embargo,
durante una evaluacin de viabilidad tcnica debera prevalecer una actitud cnica, si no
pesimista. Las equivocaciones en esta etapa pueden ser desastrosas.

La viabilidad legal comprende un amplio rango de aspectos que incluyen los contratos,
la responsabilidad, las infracciones y un millar de otros detalles frecuentemente
desconocidos para el personal tcnico. Un estudio de los aspectos legales del software
va ms all del alcance de este libro. El lector interesado puede acudir a Gemignani
[GEM81], Harris [HAR85] o Scott [SC089].

El grado en el que se consideran las alternativas muchas veces est limitado por
pg.: 19 de 42
Pressman, Cap 5

restricciones de tiempo y de dinero; sin embargo, no se debera descartar cualquier

alternativa legtima, aunque no tenga quien "la financie".

El estudio de viabilidad puede documentarse en un informe separado de los otros

documentos importantes de gestin e incluirse como apndice en la especificacin del
sistema. Aunque el formato del informe de viabilidad puede variar, el esquema de la
tabla 5.1 cubre la mayora de los aspectos importantes.

Tabla 5.1. Esquema del estudio de viabilidad

I. Introduccin
A. Declaracin del problema
B. Entorno de implementacin
C. Restricciones

II. Resumen y recomendaciones de gestin

A. Hallazgos importantes
B. Comentarios
C. Recomendaciones
D. Impacto

III. Alternativas
A. Configuraciones del sistema alternativas
B. Criterio utilizado en la seleccin del enfoque definitivo

IV. Descripcin del sistema

A. Declaracin resumida del mbito
B. Viabilidad de los elementos asignados

V. Anlisis de coste beneficio

VI. Evaluacin del riesgo tcnico

VII. Consideraciones legales

VIII. Otros asuntos especficos del proyecto

La revisin del estudio de viabilidad ha de llevarla a cabo primero el gestor del proyecto
(para asegurar la fiabilidad de su contenido) y luego por el director administrativo (para
determinar el estado del proyecto). El estudio debe provocar una decisin de "seguir/no
seguir". Debe tenerse en cuenta que durante las etapas de planificacin, especificacin
y desarrollo de la ingeniera del hardware y del software, se tomarn otras decisiones
del tipo seguir/no seguir.

pg.: 20 de 42
Pressman, Cap 5

5.3.3. Anlisis econmico

Entre la informacin ms relevante que contiene el estudio de viabilidad se encuentra el

anlisis de coste - beneficio una evaluacin de la justificacin econmica para un
proyecto de sistema basado en computadora. El anlisis de coste beneficio seala los
costes del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es,
medibles directamente en pesetas) e intangibles del sistema.

El anlisis de coste beneficio es complicado porque los criterios varan segn las
caractersticas del sistema a desarrollar, el tamao relativo del proyecto y la
recuperacin esperada de la inversin como parte del plan estratgico de la compaa.
Adems, muchos beneficios obtenidos de los sistemas basados en computadora son
intangibles (p. ej.: una mejor calidad del diseo mediante una optimizacin iterativa, una
mayor satisfaccin del cliente debida a un control programable y unas mejores
decisiones comerciales a partir de datos de ventas con formato previamente
analizados). Puede ser difcil lograr comparaciones directas cuantitativas.

Como hemos visto anteriormente, el anlisis de los beneficios diferir dependiendo de

las caractersticas del sistema. Para ilustrar este hecho, consideremos los beneficios
de los sistemas de informacin de gestin [KIN78] mostrados en la Tabla 5.2. La
mayora de los sistemas de proceso de datos se desarrollan teniendo como principal
objetivo una mejor cantidad, calidad, rapidez y organizacin de la informacin. As, los
beneficios de la Tabla 5.2 se centran en el acceso a la informacin y su impacto en el
entorno del usuario. Los beneficios que se pueden asociar a programas de anlisis
cientfico y de ingeniera o a un producto basado en microprocesador pueden diferir
substancialmente.

Los beneficios de un sistema nuevo siempre se determinan de acuerdo con el modo de

trabajo ya existente. Por ejemplo, consideremos un sistema de diseo asistido por
computadora (CAD) que vaya a reemplazar a elementos del proceso manual de diseo
en ingeniera. El analista de sistemas debe definir caractersticas ponderables del
sistema existente (diseo manual) y del sistema propuesto (CAD). Seleccionando el
tiempo de produccin de un dibujo completo y detallado (t-dibujo) entre las muchas
cantidades medibles, el analista llega a la conclusin de que el sistema CAD supondr
una reduccin de 4 a 1 en ese t-dibujo. Para cuantificar con ms detalle este beneficio,
determina los siguientes datos:

t-dibujo, tiempo medio de dibujo = 4 horas

d, coste por hora de dibujo = 2.000 ptas.

n, nmero de dibujos por ao = 8.000

p, porcentaje de dibujo que se va a realizar en el sistema CAD = 60 por 100

pg.: 21 de 42
Pressman, Cap 5

Tabla 5.2. Posibles beneficios del sistema de informacin*

Beneficios de las contribuciones a las tareas de clculo e impresin

Reduccin del coste en clculos e impresiones (RC)
Mejora en la exactitud de las tareas de clculo (RE)
Posibilidad de cambiar rpidamente las variables y los valores en los programas de
clculo (AF)
Gran incremento en la velocidad de los clculos y las impresiones (AV)

Beneficios de las contribuciones a las tareas de mantenimiento de registros

Posibilidad de recoger y guardar "automticamente" datos de los registros (RC, AV, RE)
Mantenimiento de registros ms completo y ms sistemtico (RC, RE)
Aumento de la capacidad para el mantenimiento de registros en trminos de espacio y
coste (RC)
Estandarizacin del mantenimiento de registros (RC, AV)
Aumento de la cantidad de datos que se pueden guardar por registro (RC, AV)
Mejora en la seguridad en el almacenamiento de registros (RE, RC, MG)
Mejora en la portabilidad de los registros (AF, RC, AV)

Beneficios de las contribuciones a las tareas de bsqueda de registros

Obtencin de registros ms rpida (AV)
Mejores posibilidades de acceso a registros de grandes bases de datos (AF)
Mejores posibilidades de cambio de registros en bases de datos (AF, RC)
Posibilidad de enlazar lugares que precisan poder efectuar bsquedas a travs de
telecomunicaciones (AF, AV)
Mejores posibilidades de mantener un registro sobre los accesos a los registros y por
quin (RE, MG)
Posibilidad de auditar y analizar la actividad de bsqueda de registros (MG, RE)

Beneficios de las contribuciones a la posibilidad de reestructuracin del sistema

Posibilidad de cambiar simultneamente clases enteras de registros (AV, AF, RC)
Posibilidad de mover de lugar grandes archivos de datos (AV, Al)
Posibilidad de crear nuevos archivos, mezclando partes de otros archivos (AV, AF)

Beneficios de las contribuciones a las posibilidades de anlisis y de simulacin

Posibilidad de llevar a cabo rpidamente complejos clculos simultneos (AV, AF, RE)
Posibilidad de crear simulaciones de fenmenos complejos con el fin de responder a
preguntas del tipo "qu pasa si...?" (MG, AF)
Posibilidad de agregar grandes cantidades de datos de distintas formas que sean tiles
para la planificacin y la toma de decisiones (MG, AF)

Beneficios de las contribuciones al control de procesos y de recursos

Reduccin de la necesidad de trabajo forzado en el control de procesos y de recursos
(RC)
Mejores posibilidades de "afinar" procesos tales como la lnea de ensamblaje (RC, MG,
AV, RE)
Mejores posibilidades de mantener una continua monitorizacin de los procesos y los
recursos disponibles (MG, RE, AF)
* Abreviaturas: RC= reduccin o eliminacin de costes; RE= reduccin de errores; AF= aumento en
fiabilidad; AV= aumento en la velocidad de la actividad; MG = mejoras en el control o en la
planificacin de la gestin.
Fuente: King y Schrems [KIN78], pg. 23. Reimpreso con permiso.

pg.: 22 de 42
Pressman, Cap 5

Conocidos los datos anteriores, puede establecer una estimacin del ahorro anual - el
beneficio:

Ahorro en el coste del tiempo de dibujo = reduccin x t-dibujo x n x c x p

= 9.600.000 ptas. por ao

Otros beneficios tangibles del sistema CAD seran tratados de una manera similar. A
los beneficios intangibles (p. ej.: mejor calidad de diseo y mayor estmulo para los
empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una
recomendacin de "seguir", si fuese oportuna.

En la Tabla 5.3 se exponen los costes asociados con el desarrollo de un sistema

basado en computadora [KlN8]. El analista estima cada coste y luego utiliza los costes
del desarrollo y los que surjan sobre la marcha para determinar la recuperacin de la
inversin, el punto de igualdad y el perodo de amortizacin. El grfico que muestra la
Figura 5.6 ilustra estas caractersticas para el ejemplo del sistema CAD expuesto
anteriormente. Asumimos que el ahorro total por ao ha sido estimado en 9.600.000
ptas., que el coste total del desarrollo se ha estimado en 20.400.000 ptas. y que los
costes anuales se han estimado en 3.200.000 ptas.

Por el grfico de la Figura 5.6 determinamos que el perodo de amortizacin es de 3,1

aos. En realidad, la recuperacin de la inversin se determina con un anlisis ms
detallado que considera el cambio del valor del dinero a lo largo del tiempo, las
consecuencias de los impuestos y otros usos potenciales de la inversin.
Contabilizando los beneficios intangibles, el director administrativo decide silos
resultados econmicos justifican el sistema.

Figura 5.6. Anlisis de coste beneficio

pg.: 23 de 42
Pressman, Cap 5

Tabla 5.3. Posibles costes del sistema de informacin

___________________________________________________________________

Costes de avituallamiento
Coste de consultora
Coste de la compra o alquiler del equipo actual
Coste de la instalacin del equipo
Coste del acondicionamiento del lugar destinado al equipo (aire acondicionado, seguridad,
etc.)
Coste del capital
Coste de los gestores y el personal encargados del avituallamiento

Costes de puesta a punto

Coste del software del sistema operativo
Coste de la instalacin del equipo de comunicaciones (lneas telefnicas, lneas de datos,
etc.)
Coste del personal dedicado a la puesta a punto
Coste de las actividades de bsqueda y contratacin de personal
Coste de los trastornos al resto de la organizacin
Coste de la gestin requerida para dirigir la actividad de puesta a punto

Costes relativos al proyecto

Coste de la compra de software de aplicacin
Coste de modificaciones del software para ajustarse a los sistemas locales
Coste de personal, generales, etc., del desarrollo interno de aplicaciones
Coste de la formacin del personal en el uso de las aplicaciones
Coste de los procedimientos de recoleccin de datos y de recoleccin de datos de
instalacin
Coste de la preparacin de documentacin
Coste de la gestin del desarrollo

Costes continuos
Coste del mantenimiento del sistema (hardware, software y utilidades)
Coste de los alquileres (electricidad, telfono, etc.)
Coste de la depreciacin del hardware
Coste de la plantilla involucrada en las actividades de gestin, operacin y planificacin
del sistema de informacin.
___________________________________________________
Fuente: King y Schrems [KIN78], pg. 24. Reimpreso con permiso.

Otro aspecto del anlisis de coste beneficio es la consideracin de los costes

incrementales asociados con los beneficios aadidos (mayor o mejor funcionalidad y
rendimiento). Para los sistemas basados en computadora, la relacin incremental de
coste - beneficio se puede representar como en la Figura 5.7.

En algunos casos (curva AA) los costes se incrementan proporcionalmente a los

beneficios hasta un determinado punto. Despus de ese punto, cada beneficio
adicional es demasiado caro. Por ejemplo, consideremos una funcin de sondeo en
tiempo real que tiene 500 milisegundos de tiempo muerto. Se pueden aadir nuevas
tareas a un coste relativamente bajo; sin embargo, si la ejecucin total de la tarea se
aproxima a los 500 milisegundos, el coste de implementacin aumenta drsticamente,
pg.: 24 de 42
Pressman, Cap 5

ya que se debe mejorar el rendimiento global.

Figura 5.7. Incremento de la relacin coste beneficio.

En otros casos (curva ABCC'), los costes aumentan proporcionalmente hasta A y

despus se nivelan a favor de los beneficios aadidos (hasta B), antes de aumentar
drsticamente (en C) para los posteriores beneficios. Como ejemplo, consideremos un
sistema operativo monousuario que se va mejorando hasta soportar finalmente varios
usuarios. Una vez que se dispone del soporte multiusuario, la tasa de aumento del
coste al aadir funciones multiusuario puede bajar un poco. Sin embargo, una vez que
se alcance la capacidad mxima del procesador, las nuevas funciones requerirn un
procesador ms potente, con el consiguiente gran incremento en el coste.

La siguiente cita [FRI77] caracteriza mejor el anlisis de coste beneficio:

Al igual que se olvida la retrica poltica despus de las elecciones, puede que se olvide el
anlisis de coste beneficio una vez que comienza la implementacin del proyecto. Sin
embargo, es extremadamente importante, ya que ha sido el vehculo con el que se ha
conseguido la aprobacin por parte de la gestin.

Slo gastando el tiempo necesario para evaluar la viabilidad, reducimos las

oportunidades de situaciones extremadamente embarazosas (o ms que embarazosas)
en etapas posteriores de un proyecto de un sistema. El esfuerzo gastado en el anlisis
de viabilidad que resulta en la cancelacin de un proyecto propuesto no es un esfuerzo
desaprovechado.

5.3.4. Anlisis tcnico

Durante el anlisis tcnico, el analista evala los mritos tcnicos del concepto de
sistema, mientras que al mismo tiempo recoge informacin adicional sobre el
rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de produccin. En
algunos casos la etapa de anlisis del sistema tambin incluye una cantidad limitada de
investigacin y de diseo.

El anlisis tcnico empieza con una definicin de la viabilidad tcnica del sistema
pg.: 25 de 42
Pressman, Cap 5

propuesto. Qu tecnologas se requieren para conseguir la funcionalidad y el

rendimiento del sistema? Qu nuevos materiales, mtodos, algoritmos o procesos se
requieren y cul es el riesgo de su desarrollo? Cmo afectarn al coste estos
elementos de tecnologa?

Las herramientas de que se puede disponer para el anlisis tcnico se encuentran en

las tcnicas matemticas de modelizacin y optimizacin, en la probabilidad y la
estadstica, en la teora de colas y en la teora de control - por nombrar unas cuantas 4.
Sin embargo, es importante tener en cuenta que la evaluacin analtica no es siempre
posible. La modelizacin (bien matemtica o fsica) es un mecanismo efectivo para el
anlisis tcnico de sistemas basados en computadora. La Figura 5.8 ilustra el flujo
global de informacin del proceso de modelizacin. El modelo se crea a partir de la
observacin del mundo real o de una aproximacin basada en los objetivos del sistema.
El analista comprueba el comportamiento del modelo y lo compara con el del mundo
real o con el del sistema esperado, obteniendo informacin de viabilidad tcnica para el
sistema propuesto.

Figura 5.8. Modelizacin del sistema.

Blanchard y Fabrycky [BLA81, pg. 270] definen un conjunto de criterios para el uso de
modelos durante el anlisis tcnico de sistemas:

1. El modelo debe representar la dinmica de la configuracin del sistema que est

siendo evaluado, de una forma que sea suficientemente simple de comprender y
manipular, y tambin que est lo suficientemente cerca de la realidad operativa como
para obtener resultados satisfactorios.
2. El modelo debe realzar aquellos factores que sean ms relevantes para el problema en
cuestin y suprimir (con discrecin) aquellos que no sean importantes.
3. El modelo debe ser amplio, incluyendo todos los factores relevantes, y fiable en cuanto
a repeticin de resultados.
4
Hay un tipo de herramientas CASE, denominadas herramientas de simulacin y creacin de prototipos, que
pueden ayudar bastante en el anlisis tcnico. Estas herramientas se tratan en los captulos 15 y 22.

pg.: 26 de 42
Pressman, Cap 5

4. El diseo del modelo debe ser lo suficientemente simple como para permitir una rpida
implementacin de la resolucin del problema. A no ser que la herramienta pueda ser
utilizada de una manera rpida y eficiente por el analista o por el gestor, ser de poca
utilidad. Si el modelo es grande y muy complejo, puede ser apropiado desarrollar una
serie de modelos en los que la salida de uno pueda ser conectada a la entrada de otro.
Tambin puede ser deseable evaluar un elemento especfico de un sistema
independientemente del resto de los elementos.
5. El diseo del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo
fcilmente y permitir la evaluacin de factores adicionales si se requieren. En un
desarrollo satisfactorio del modelo, a menudo se hace una serie de intentos antes de
alcanzar el objetivo final. Los intentos iniciales pueden hacer evidentes ciertas lagunas
en la informacin que no se hayan detectado a primera vista y, consecuentemente,
sugerir cambios beneficiosos.

Los resultados del anlisis tcnico son la base de otra decisin del tipo "seguir / no
seguir" con el sistema. Si el riesgo tcnico es alto, silos modelos indican que la
funcionalidad o el rendimiento deseados no pueden ser alcanzados, o si las piezas no
encajan bien - hay que volver a la mesa de trabajo!

5.3.5 Asignacin y compromisos

Una vez que se ha respondido a las cuestiones relativas a la tarea de anlisis, hay que
considerar soluciones alternativas. Cada funcin del sistema, con su rendimiento
requerido y sus caractersticas de interfaz, es asignada a uno o ms elementos del
sistema.

Por ejemplo, el anlisis de un nuevo sistema de grficos de computadora indica que

una funcin importante es la transformacin espacial de las imgenes grficas
tridimensionales. Una investigacin de soluciones alternativas para la funcin de
transformacin revela las siguientes opciones:

1. Todas las transformaciones tridimensionales realizadas por el software.

2. Las transformaciones "simples" (p. ej.: cambio de escala, translacin y rotacin)
realizadas por el hardware y las transformaciones "complejas" (p. ej.: perspectiva y
sombreado) realizadas por el software.
3. Todas las transformaciones realizadas por un procesador grfico implementado con
hardware.

El proceso general de evaluacin de las configuraciones alternativas para el sistema

est ilustrado en las Figuras 5.9 y 5.10 [BLA81]. De acuerdo con la Figura 5.9, se
evala cada alternativa de configuracin para el sistema de acuerdo con un conjunto de
"parmetros de evaluacin" (criterios de compromiso) que han sido ordenados de
acuerdo con su importancia (Figura 5.10). En general, los parmetros de evaluacin
estn relacionados con los factores econmicos (p. ej.: el coste del ciclo de vida).
Cuando dos o ms parmetros de evaluacin del sistema de bajo orden (p. ej.: el
tiempo de respuesta o la resolucin de la pantalla) pueden variar (en diferentes
asignaciones), permitiendo que se siga alcanzando un parmetro deseable de alto
orden (p. ej.: el coste o la fiabilidad), se asla un rea de compromiso (Figura 5.11).

pg.: 27 de 42
Pressman, Cap 5

5.4. MODELIZACION DE LA ARQUITECTURA DEL SISTEMA

Una vez asignadas las funciones del sistema basado en computadora, el ingeniero de
sistemas puede crear un modelo que represente las interrelaciones entre los distintos
elementos del sistema y establezca una base para los posteriores pasos de anlisis de
requisitos y de diseo. Ya hemos visto que cada sistema basado en computadora se
puede modelar como una transformacin de informacin mediante una arquitectura de
entrada - proceso - salida. Hatley y Pirbhai [HAT87] han ampliado este enfoque,
incluyendo dos caractersticas adicionales del sistema - el procesamiento de la interfaz
de usuario y el procesamiento de mantenimiento y de autocomprobacin. Aunque estas
caractersticas adicionales no estn presentes para todos los sistemas basados en
computadora, son muy comunes y su especificacin hace que cada modelo de sistema
sea ms robusto.

5.4.1. Diagramas de arquitectura

Para desarrollar el modelo del sistema se utiliza una plantilla de arquitectura [HAT87].
El ingeniero de sistemas asigna elementos del sistema a cada una de las cinco
regiones de procesamiento dentro de la plantilla: (1) interfaz de usuario, (2) entrada, (3)
funcin y control del sistema, (4) salida y (5) mantenimiento y autocomprobacin. El
formato de la plantilla de arquitectura aparece en la Figura 5.12.

Como casi todas las tcnicas de modelizacin utilizadas en la ingeniera del software y
de sistemas, la plantilla de arquitectura permite al analista crear una jerarqua de
detalles. En el nivel superior de la jerarqua est el diagrama de contexto de la
arquitectura (DCA).

pg.: 28 de 42
Pressman, Cap 5

Figura 5.9. Evaluacin de alternativas. (Reimpreso con permiso de

Prentice Hall, EngleWood Cliffs, NJ)

El diagrama de contexto establece los lmites de informacin entre los que se est
implementando el sistema y el entorno en el que va a funcionar el sistema [HAT87]. Es
decir, el DCA define todos los productores de informacin externos utilizados por el
sistema, todos los consumidores de informacin externos creados por el sistema y
todas las entidades que se comunican a travs de la interfaz o realizan mantenimiento o
autocomprobacin.

pg.: 29 de 42
Pressman, Cap 5

Figura 5.10. Orden de los parmetros de evaluacin. (Reimpreso con

permiso de Prentice Hall, Englewood Cliffs, NJ)

Figura 5.11. Area de compromiso.

pg.: 30 de 42
Pressman, Cap 5

Para ilustrar el uso del DCA, consideremos una versin ampliada del sistema de
clasificacin de cinta transportadora visto anteriormente en este captulo. La versin
ampliada utiliza una computadora personal (PC) como esta de clasificacin. El PC
ejecuta todo el software del SCCT; est conectado al lector de cdigos de barras para
leer los nmeros de serie de cada caja; est conectado al equipo de supervisin de la
cinta transportadora para obtener la velocidad; guarda todos los nmeros de serie
clasificados; interacta con un operador de la estacin de clasificacin produciendo una
serie de informes y diagnsticos; manda seales de control al hardware encargado de
la maniobra para clasificar las cajas y se comunica con la computadora central de la
fbrica de automatizacin. En la Figura 5.13 se muestra el DCA para la versin
ampliada del SCCT.

Figura 5.12. Plantilla de arquitectura.

Cada cuadro de la Figura 5.13 representa una entidad externa - es decir, un productor o
un consumidor de informacin del sistema. Por ejemplo, el lector de cdigos de
barras produce informacin que entra en el sistema SCCT. El smbolo que representa
el sistema completo (o, a niveles ms bajos, los subsistemas principales) es un
rectngulo con esquinas redondeadas. Aqu, el SCCT est representado en la regin
de proceso y control, en el centro del DCA. Las flechas etiquetadas del DCA
representan la informacin (de datos y de control) que se fluye entre el entorno externo
y el sistema SCCT. La entidad externa lector de cdigos de barras produce
informacin de entrada que est etiquetada como cdigo de barras. En esencia, el
DCA ubica el sistema en el contexto de su entorno externo.

El ingeniero de sistemas refina el diagrama de contexto de la arquitectura considerando

con ms detalle el rectngulo sombreado de la Figura 5.13. Identifica los subsistemas
principales que permiten el funcionamiento del sistema de clasificacin de cinta
transportadora en el contexto definido por el DCA. De acuerdo con la Figura 5.14, se
definen los subsistemas principales5 en un diagrama de flujo de la arquitectura (DFA),
que se obtiene a partir del DCA. Como gua para el desarrollo del DFA un "esquema"
ms detallado del SCCT, el ingeniero de software utiliza la informacin que fluye a
travs de las regiones de DCA. El diagrama de flujo de la arquitectura muestra los
subsistemas principales y las lneas importantes de flujo de informacin (control y
5
Hatley y Pirbhai [HAT87] los denominan mdulos del sistema.

pg.: 31 de 42
Pressman, Cap 5

datos). Adems, la plantilla de la arquitectura clasifica el procesamiento de los

subsistemas en una de las cinco regiones de procesamiento vistas anteriormente. En
esta etapa, cada uno de los subsistemas pueden contener uno o ms elementos del
sistema (p. ej.: hardware, software, gente) segn hayan sido asignados por el ingeniero
de sistemas.

Figura 5.13. Diagrama de contexto de la arquitectura del sistema SCCT (ampliado).

Figura 5.14. Diagrama de flujo de la arquitectura para el SCCT (ampliado).

El diagrama inicial de flujo de la arquitectura se constituye en el nodo raz de la

pg.: 32 de 42
Pressman, Cap 5

jerarqua de DFAs. Se puede ampliar cada rectngulo redondeado del DFA inicial en
otra plantilla de arquitectura dedicada exclusivamente a l. Este proceso se ilustra
esquemticamente en la Figura 5.15. Cada uno de los DFAs del sistema se puede
utilizar como punto de partida para los posteriores pasos de ingeniera del subsistema
que describe.

Figura 5.15. Construccin de una jerarqua de DFAs.

5.4.2. Especificacin de la arquitectura del sistema

Se pueden especificar (limitar) los subsistemas y la informacin que fluye entre ellos
para que est disponible en los posteriores trabajos de ingeniera. La especificacin del
diagrama de arquitectura6 (EDA) presenta la informacin sobre cada subsistema y el
flujo de informacin entre los subsistemas. La EDA contiene una descripcin -
denominada narrativa de mdulo del sistema - de cada subsistema. La narrativa de
mdulo del sistema describe qu hace el subsistema, qu informacin procesa y cmo
est relacionado con otros subsistemas. Adems de las narrativas, la EDA puede
contener un diccionario de arquitectura - una lista con los elementos de informacin que
aparecen en el DFA y sus descripciones. Por ejemplo el elemento de informacin
nmero de serie de la Figura 5.14 podra describirse tal como muestra la Figura 5.16.

Como se puede ver en la figura, se utiliza una notacin especial para representar la
descripcin del elemento de informacin. La notacin (que se describe en el Captulo
7) indica qu nmero de serie es un elemento de datos compuesto - es decir, un

6
La EDA es una adaptacin de varias especificaciones diferentes sugeridas por Hartley y Pirbhai [HAT87].
Para Simplificar, lo hemos combinado en un nico documento

pg.: 33 de 42
Pressman, Cap 5

elemento de datos que est compuesto por otros tres elementos de datos: prefijo de
tipo de producto, identificador numrico y categora de coste. En realidad, en el
diccionario tambin estar definido cada uno de esos tres elementos. Los datos sobre
el tipo, el origen y el destino se obtienen directamente del DFA (Figura 5.14) y el camino
de comunicacin indica la manera en que se transfiere fsicamente la informacin desde
el origen y el destino. En otras circunstancias, el camino de comunicacin puede estar
definido como un bus o un canal que tendr que ser implementado como parte del
diseo del sistema. El diccionario de la arquitectura es una versin a nivel de sistema
del diccionario de requisitos - una importante notacin de anlisis del software que se
trata en detalle en el Captulo 7.

El ltimo elemento de la especificacin del diagrama de arquitectura es el diagrama de

interconexin de la arquitectura (DIA) y la correspondiente descripcin de la
interconexin. Las flechas del DFA indican el flujo del control y de los datos, sin
describir cmo se efecta ese flujo de informacin. El DIA y la especificacin
correspondiente, describen cmo se transfiere la informacin - electrnicamente (p. ej.:
por un bus), pticamente (p. ej.: por un enlace ptico de tal ancho de banda) o
mecnicamente (p. ej.: mediante un actuador o una articulacin mecnica). Para
desarrollar el DIA, el ingeniero de sistemas tiene que tomar decisiones de
implementacin que es mejor dejarlas para la etapa de diseo. Por esta razn,
posponemos el estudio de los aspectos de interconexin hasta el Captulo 15.

Figura 5.16. Una entrada del diccionario de la arquitectura.

5.5. SIMULACION Y MODELIZACION DEL SISTEMA

Hace dos dcadas, R. M. Graham [GRA69] hizo un comentario angustioso sobre la

forma de construir sistemas basados en computadora: "Construimos los sistemas igual
que los hermanos Wright construyeron sus aviones - construyendo todo de una vez,
soltndolo desde un acantilado, dejando que se estrelle y comenzando de nuevo". De
hecho, actualmente seguimos hacindolo as con al menos un tipo de sistema - el
sistema reactivo.

Muchos sistemas basados en computadora interactan con el mundo real de una forma
reactiva. Es decir, el sistema basado en computadora supervisa los sucesos del mundo
real mediante el hardware y el software y, basndose en esos sucesos, el sistema
impone un control sobre las mquinas, los procesos e incluso la gente que hace que se
produzcan los sucesos. Los sistemas de tiempo real y los sistemas empotrados
pg.: 34 de 42
Pressman, Cap 5

muchas veces se encuentran en la categora de los temas reactivos.

Desgraciadamente, los desarrolladores de sistemas reactivos a veces tienen que luchar

para conseguir que funcionen correctamente. Hasta hace poco, era difcil predecir el
rendimiento, la eficiencia y el comportamiento de dichos sistemas antes de construirlos.
En cierto sentido, la construccin de sistemas de tiempo real era muchas veces como
una aventura "de vuelo". No se encontraban sorpresas (la mayora desagradables)
hasta que no se construa el sistema y se "soltaba desde un acantilado". Si el sistema
fallaba debido a una funcin incorrecta, a un comportamiento inapropiado o a un
rendimiento pobre, se recogan las piezas y se empezaba de nuevo.

Muchos sistemas de la categora de los reactivos controlan mquinas y/o procesos (p.
ej.: refineras de petrleo o lneas areas comerciales) que han de funcionar con un
grado de fiabilidad extremadamente alto. Si el sistema falla, pueden producirse
prdidas humanas o econmicas importantes. Por esta razn, el panorama descrito por
Graham es lamentable y peligroso.

Hoy en da, se usan herramientas CASE para la modelizacin y la simulacin, con el fin
de eliminar sorpresas en la construccin de sistemas reactivos basados en
computadora. Estas herramientas se aplican durante el proceso de ingeniera del
software, durante la especificacin de los papeles del hardware, del software, de las
bases de datos y de la gente. El papel de la herramienta de modelizacin y de
simulacin de sistemas ha sido resumido por i-Logix, Inc., un vendedor de herramientas
de ingeniera del sistema [ILO90]:

En un proyecto, cuando ms frecuentemente nos centramos en el entendimiento del

comportamiento de un sistema en su entorno, es durante las fases de diseo, de
implementacin y de prueba, mediante un proceso iterativo de prueba y error. El mtodo
Statemate [una herramienta de modelizacin y simulacin] es una alternativa para este
costoso proceso. Permite construir un modelo completo que... se centra en los aspectos
funcionales y de flujo de datos usuales, pero cubriendo tambin los aspectos de la
dinmica y del comportamiento del sistema. Luego, se puede probar el modelo con...
herramientas que proporcionan varios mecanismos para inspeccionar y depurar la
especificacin y para recuperar la informacin que contiene. Mediante la prueba del
modelo de especificacin, el ingeniero de sistemas puede ver cmo se comportar el
sistema especificado una vez que se implemente. Se pueden plantear preguntas del tipo
"qu pasa si...?" seguir guiones especficos, comprobar que se van a producir
determinadas situaciones deseables... y que otras no deseables no se encontrarn. En
este sentido, se puede decir que el ingeniero de sistemas juega el papel de usuario
eventual del sistema y de su entorno...

Las herramientas de modelizacin y simulacin permiten al ingeniero de sistemas

"conducir la prueba" de una especificacin del sistema. Los detalles tcnicos y las
tcnicas especializadas de modelizacin que se utilizan para conducir la prueba se
presentan en el Captulo 15.

pg.: 35 de 42
Pressman, Cap 5

5.6. LA ESPECIFICACION DEL SISTEMA

La especificacin del sistema es un documento que sirve como base para la ingeniera
del hardware, la ingeniera del software, la ingeniera de bases de datos y la ingeniera
humana. Describe la funcin y el rendimiento de un sistema balado en computadora y
las restricciones que gobernarn su desarrollo. La especificacin limita cada uno de los
elementos del sistema asignados. Por ejemplo, proporciona al ingeniero de software
una indicacin del papel del software dentro del contexto del sistema como un todo y
dentro de los subsistemas descritos en los diagramas de flujo de la arquitectura. La
especificacin del sistema tambin describe la informacin (control y datos) que sirve
de entrada y de salida al sistema.

La tabla 5.4 muestra un esquema recomendado para la especificacin del sistema. Sin
embargo, tngase en cuenta que se trata slo de uno de los muchos esquemas que se
pueden seguir para definir un documento de descripcin del sistema. El contenido o el
formato actual puede venir impuesto por algn estndar de la ingeniera del software o
de la ingeniera de sistemas (p. ej.: DoD/STD 2167A) o por las preferencias y gustos
particulares.

5.7. REVISION DE LA ESPECIFICACION DEL SISTEMA

Durante la ingeniera del sistema hay una tendencia natural a pasar por alto la revisin
e ir rpidamente al desarrollo. Los gestores tienden a ponerse cada vez ms nerviosos
cuando lo que se hace no es soldar componentes ni escribir cdigo. El personal tcnico
quiere pasar a las "tareas creativas de la ingeniera" tan pronto como sea posible. No
se debe ceder ante estas actitudes!

La revisin de la especificacin del sistema evala la correccin de la definicin

contenida en la especificacin del sistema. La revisin ha de ser realizada por el
tcnico y por el cliente, para asegurar que (1) se ha perfilado adecuadamente el mbito
del proyecto; (2) se ha definido correctamente la funcionalidad, el rendimiento y las
interfaces; (3) el anlisis del entorno y del riesgo del desarrollo justifican el sistema y (4)
el desarrollador y el cliente tienen la misma percepcin de los objetivos del sistema. La
revisin de la especificacin del sistema se realiza en dos partes. Inicialmente se aplica
un punto de vista de gestin. Despus se realiza una evaluacin tcnica de los
elementos y funciones del sistema.

pg.: 36 de 42
Pressman, Cap 5

Tabla 5.4. Esquema de la especificacin del sistema

I. Introduccin
A. Ambito y propsito del documento
B. Visin general
1. Objetivos
2. Restricciones
II. Descripcin funcional y de datos
A. Arquitectura del sistema
1. Diagrama de contexto de la arquitectura
2. Descripcin del DCA
III. Descripcin de los subsistemas
A. Especificacin del diagrama de arquitectura para el subsistema n
1. Diagrama de flujo de la arquitectura
2. Narrativa de mdulo del sistema
3. Aspecto de rendimiento
4. Restricciones de diseo
5. Asignacin de componentes del sistema
B. Diccionario de la arquitectura
C. Diagramas y descripcin de la interconexin de la arquitectura
IV. Resultados de la modelizacin y la simulacin del sistema
A. Modelo del sistema utilizado para la simulacin
B. Resultados de la simulacin
C. Aspectos especiales del rendimiento
V. Aspectos del proyecto
A. Costes de desarrollo proyectados
B. Agenda proyectada
VI. Apndices

Las consideraciones claves de la gestin generan las siguientes cuestiones:

Se ha establecido una necesidad comercial en firme? Tiene sentido la

justificacin del sistema?
Necesita el entorno especificado (o el mercado) el sistema descrito?
Qu alternativas has se han considerado?
Cul es el riesgo de desarrollo de cada elemento del sistema?
Estn disponible los recursos necesarios para el desarrollo?
Tienen sentido las restricciones de coste y de agenda?

Realmente, se debe haber planteado y respondido a estas cuestiones regularmente

durante la tarea de anlisis. En este momento, lo que hacemos es volver a
examinarlas.

El nivel de detalle considerado durante la etapa tcnica de la revisin del sistema vara
de acuerdo con el nivel de detalle considerado durante la tarea de asignacin. La
revisin debe cubrir los siguientes aspectos:

pg.: 37 de 42
Pressman, Cap 5

Se corresponde la complejidad funcional del sistema con el riesgo de

desarrollo, el coste y la agenda?
Est definida la asignacin de funciones con suficiente detalle?
Se han definido con suficiente detalle las interfaces entre los elementos del
sistema y el entorno?
Se han planteado los aspectos de rendimiento, fiabilidad y facilidad de
mantenimiento en la especificacin?
Proporciona la especificacin del sistema una base suficiente para los
siguientes pasos de ingeniera del software y del hardware?

Una vez que ha terminado la revisin del sistema, comienzan los caminos paralelos de
ingeniera. Los elementos de hardware, humanos y de base de datos de un sistema se
consideran dentro de sus correspondientes procesos de ingeniera. En el resto de este
libro, seguiremos el camino de la ingeniera del software.

5.8. RESUMEN

La ingeniera de sistemas de computadora es el primer paso en la evolucin de un

producto o sistema basado en computadora nuevo. Mediante los pasos que hemos
denominado colectivamente anlisis del sistema, el ingeniero de sistemas identifica las
necesidades del usuario, determina la viabilidad tcnica y econmica, y asigna las
funciones y el rendimiento al software, al hardware, a la gente y a las bases de datos
los elementos clave del sistema. Se crea un modelo arquitectnico del sistema y se
desarrolla una representacin de cada uno de los principales subsistemas. Por ltimo,
la ingeniera de sistemas puede utilizar herramientas CASE para crear un modelo
reactivo del sistema que se pueda utilizar como base para la simulacin del
funcionamiento y del comportamiento. La tarea de ingeniera de sistemas culmina con
la creacin de la especificacin del sistema un documento que es la base de todo el
trabajo de ingeniera que viene a continuacin.

La ingeniera de sistemas requiere una comunicacin intensa entre el cliente y el

analista. El cliente debe comprender los objetivos del sistema y ser capaz de
exponerlos claramente. El analista debe saber qu preguntas hacer, qu consejos dar
y qu investigacin realizar. Si la comunicacin se rompe en esta fase, el xito del
proyecto entero estar en peligro.

REFERENCIAS

[ALL89] Allman, W. F., Apprentices of Wonder, Bantam, 1989.

[BLA81] Blanchard, B. S., and W. J. Fabrycky, Systems Engineering and Analysis,
Prentice Hall, 1981.
[DAT86] Date, C. J., An Introduction to Data Base Systems, 4th ed., Addison Wesley,
1986.
[FRI77] Fried, L., "Performing Cost Benefit Analysis", Systems Development

pg.: 38 de 42
Pressman, Cap 5

Management, Auerbarch Publishers, 1977

[GEM81] Gemignani, M., Law and the Computer, CBI Publishing Co., 1981.
[GRA69] Graham, R. M., in Proceedings 1969 NATO Conference on Software
Engineering, 1969.
[HAR85] Harris, T. D., Computer Software Protection, Prentice Hal, 1985.
[HAT87] Hatley, D. J., and I. A. Pirbhai, Strategies for Real Time Systems
Specification, Dorset House, 1987.
[IEE89] Database Engineering, Vol. 7, IEEE Computer Society Press, 1989.
[ILO90] The Statemate Approach to Complex Systems, i-Logix, Inc., 1990.
[KIN78] King, J., and E. Schrems, "Cost Benefit analysis in Information Systems
Development and Operation", ACM Computing Surveys, vol. 10, no. 1, March
1978, pp. 19-34.
[RAE9O] Raeth, P. G., Expert Systems: A Software Methodology for Modern
Applications, IEEE Computer Society Press, 1990.
[SC089] Scott, M. D., Computer Law, Wiley, 1989.
[WAS89] Wasserman, P. D., Neural Computing: Theory and Practice, Van Nostrand
Reinhold, 1989.

PROBLEMAS Y PUNTOS A CONSIDERAR

5.1. Encuentre tantos sinnimos como pueda de la palabra sistema. Suerte!

5.2. Construya un "sistema de sistemas" similar al de la Figura 5.2, para un sistema
grande (diferente al del ejemplo). La jerarqua debe llegar hasta los elementos
ms sencillos del sistema (hardware, software, etc.), al menos por una rama del
"rbol".
5.3. Intente dibujar el equivalente de la Figura 5.1 para un sistema (preferiblemente
basado en computadora) con el que est familiarizado. Muestre las entradas y las
salidas principales, cada elemento del sistema y la interconectividad entre los
elementos.
5.4. Un analista de sistemas puede ser: el que desarrolla el sistema, el cliente o alguien
de una organizacin externa. Discuta los pros y los contras de cada uno.
Describa al analista "ideal".
5.5. Los elementos comunes a todos los sistemas son el hardware, el software y la
gente. Qu otros elementos se encuentran frecuentemente en los sistemas
basados en computadora?
5.6. Aada al menos cinco cuestiones ms a la lista desarrollada para el sistema SCCT
en la Seccin 5.2. Aborde el problema con dos asignaciones adicionales para el
SCCT.
5.7. Su profesor le proporcionar una descripcin de alto nivel de un sistema basado
en computadora.
(a) Desarrolle un conjunto de preguntas que pudiera proponer un analista.
(b) Proponga por lo menos dos conjuntos diferentes de asignaciones para el
sistema, de acuerdo con las respuestas del profesor a las preguntas
planteadas.
(c) En clase, compare sus asignaciones con las realizadas por otros compaeros.
5.8. Intente desarrollar una clasificacin jerrquica para el hardware de computadoras.
Identifique cada clase de hardware; proporcione ejemplos de dispositivos reales de
cada clase.
pg.: 39 de 42
Pressman, Cap 5

5.9 Intente desarrollar una clasificacin jerrquica para el software de computadoras.

Identifique cada clase de software; proporcione ejemplos de programas reales de
cada clase.
5.10.
Hemos observado similitudes entre los procesos de ingeniera del hardware y del
software. En qu difieren las fases de estos procesos?
5.11.
La ingeniera humana intenta construir sistemas "amigables con el usuario".
Defina el concepto amigable con el usuario con sus propias palabras.
5.12 Desarrolle una lista de comprobacin de atributos que haya que considerar
cuando se vaya a evaluar la "viabilidad" de un sistema. Discuta la interrelacin
entre los atributos e intente aportar un mtodo para clasificarlos de tal forma que
se pueda obtener un nmero de viabilidad cuantitativo.
5.13.

Investigue sobre las tcnicas de contabilidad que se usan para el anlisis

detallado de coste beneficio de un sistema basado en computadora que requiera
fabricacin de hardware y ensamblaje. Intente escribir un conjunto de directrices
tipo de receta" que pudiese seguir un gestor tcnico.
5.14.
Desarrolle un anlisis de coste beneficio equivalente al que se muestra en las
Tablas 5.2 y 5.3, para sistemas cientficos/de ingeniera. Ample las tablas para
incluir aplicaciones de tiempo real y empotradas.
5.15.
Desarrolle un diagrama de contexto de la arquitectura y los diagramas de flujo de
la arquitectura para un sistema basado en computadoras de su eleccin (o uno
asignado por su profesor).
5.16.
Escriba una narrativa de mdulo de sistema que pudiera encontrarse en la
especificacin del diagrama de arquitectura de uno o ms de los subsistemas
definidos en los DFAs del Problema 5.15.
5.17.
Investigue en la literatura sobre herramientas CASE y escriba un breve artculo
describiendo cmo funcionan las herramientas de modelizacin y simulacin.
Alternativa: recopile informacin de dos o ms vendedores de herramientas
CASE que suministren herramientas de modelizacin y simulacin, y evale las
similitudes y las diferencias.
5.18.
Basndose en los documentos suministrados por su profesor, desarrolle una
especificacin del sistema abreviada, para uno de los siguientes sistemas
basados en computadora:
(a) Un sistema de procesamiento de textos de bajo coste.
(b) Un digitalizador ptico para una computadora personal.
(c) Un sistema de correo electrnico.
(d) Un sistema de matrcula para la universidad.
(e) Un sistema de anlisis de ingeniera.
(f) Un sistema interactivo de reservas.
g) Un sistema de inters local.
Asegrese de crear los modelos de arquitectura descritos en la Seccin 5.4.
pg.: 40 de 42
Pressman, Cap 5

5.19. Existen caractersticas de un sistema que no se puedan establecer en el

momento de la definicin? Describa esas caractersticas, si las hay, y explique
por qu su consideracin debe ser postergada para ms adelante en el proceso
de ingeniera.
5.20. Existen situaciones en las que la especificacin formal del sistema pueda ser
abreviada o eliminada por completo? Explique su respuesta.

OTRAS LECTURAS

Debido a que se trata de un tema interdisciplinario, la ingeniera de sistemas basados

en computadora es una materia difcil y, por ello, se han publicado pocos libros
verdaderamente buenos. Los libros de Blanchard y Fabrycky [BLA81] y de Athey
(Systematic Systems Approach, Prentice Hall, 1982) presentan el proceso de la
ingeniera de sistemas (con un enfoque de ingeniera distinto) y constituyen una valiosa
gua. IEEE Computer Society ha puesto empeo en desarrollar una estructura
educativa para la ingeniera de sistemas basados en computadora. Sus primeros
descubrimientos se han publicado en los Proceedings of Computer Based System
Engineering Workshop (IEEE, 1990).

Un excelente tutorial del IEEE por Thayer y Dorfman (System and Software
Requirements Engineering, IEEE Computer Society Press, 1990) trata las
interrelaciones entre los aspectos del anlisis de requisitos a nivel de software y a nivel
de sistema. Un manual de los mismos autores (Standars. Guidelines and Examples:
System and Software Requirements Engineering, IEEE Computer Society Press, 1990)
presenta un estudio detallado de los estndares y las directrices para el trabajo de
anlisis.

Los libros de Lesson (Systems Analysis and Design, SRA, 1981), McMenamin y Palmer
(Essential Systems Analysis, Yourdon Press, 1984) y Silver (Systems Analysis and
Design, Addison Wesley, 1989), proporcionan tiles tratamientos de la tarea de anlisis
de sistemas tal y como se aplica en el mundo de los sistemas de informacin. Los
libros contienen casos de estudio suplementarios que ilustran los problemas, los
mtodos y las soluciones que se pueden aplicar durante el anlisis de sistemas. Se
han publicado muchos otros libros de texto en el rea general del anlisis y la definicin
de sistemas. Entre las incorporaciones ms recientes a la literatura se encuentran:

Dickinson, B., Developing Quality Systems, McGraw Hill, 1988.

Gause, D.A, y G.M Weinberg, Exploring Requirements, Dorset House, 1989.
ModeIl, M.E., A Professional's Guide to System Analysis, McGraw Hill, 1988.

Para aquellos lectores involucrados activamente en el trabajo con sistemas o

interesados en un tratamiento sofisticado del tema, los libros de Gerald Weinberg (An
Introduction to General System Thinking, Wiley Interscience, 1976 y On the design of
Stable Systems, Wiley Interscience, 1979) se han convertido ya en clsicos y
proporcionan un tratamiento excelente de la "concepcin de sistemas generales" que
conduce implcitamente a un enfoque general del anlisis y del diseo de sistemas. Los
libros ms recientes de Weinberg (General Principies of System Design, Dorset House,
1988 y Rethinking Systems Analysis and Design, Dorset House, 1988) continan en la
pg.: 41 de 42
Pressman, Cap 5

tradicin de sus anteriores trabajos.

Las series de Auerbach, System Development Management (Auerbach Publishers,

actualizadas cada ao), proporcionan un tratamiento excelente de la planificacin y la
definicin de sistemas de informacin a gran escala. El enfoque pragmtico de
Auerbach ser especialmente til a los profesionales de la industria.

pg.: 42 de 42