pressman-cap5

Pressman, Cap 5
Pressman, Roger S.; Ingeniería de Software, un enfoque práctico
Tercera edición, 1993 Editorial McGraw-Hill
Segunda Parte
Análisis de Requisitos del Sistema y del Software
5
Ingeniería De Sistemas De Computadora
Hace cuatrocientos cincuenta años, Maquiavelo dijo: "...no hay nada más difícil de
conseguir, más arriesgado de mantener ni más inseguro de tener éxito, que estar a la
cabeza en la introducción de un nuevo orden de cosas..."
Durante el último cuarto del siglo veinte, los sistemas basados en computadora están
introduciendo un nuevo orden de cosas. Aunque la tecnología ha hecho grandes
avances desde Maquiavelo, sus palabras siguen siendo ciertas.
La ingeniería del software y la ingeniería del hardware entran dentro de la amplia
categoría que llamaremos ingeniería 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 técnicas de ingeniería para el hardware de
computadoras provienen del diseño electrónico y han alcanzado un estado de relativa
madurez. Las técnicas de diseño de hardware están bien establecidas, los métodos de
fabricación mejoran continuamente y la fiabilidad es más una expectativa real que una
modesta esperanza. Desafortunadamente, el software de las computadoras todavía
padece la descripción maquiavélica anteriormente descrita. En los sistemas basados
en computadora, el software ha reemplazado al hardware en el sentido de ser el
elemento del sistema más difícil de planificar, con menos posibilidad de éxito (en tiempo
y en dinero) y más peligroso de manejar. Mientras los sistemas basados en
computadora continúan creciendo en número, complejidad y aplicaciones, la demanda
de software continúa sin disminuir.
Las técnicas de ingeniería para la producción de software de computadora empiezan
ahora a tener una amplia aceptación. En el primer capítulo discutimos la evolución de
una cultura del software que vio la programación de computadoras como una forma de
arte. No existía un precedente de ingeniería ni se aplicó ningún planteamiento de
ingeniería. ¡Los tiempos están cambiando!
5.1. SISTEMAS BASADOS EN COMPUTADORA
La palabra "sistema" es posiblemente el término más sobreutilizado y del que más se
ha abusado en el léxico técnico. Hablamos de sistemas políticos y educativos, de
sistemas aviónicos y de fabricación, 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 ordenación de cosas relacionadas de tal manera que forman una unidad
pág.: 1 de 41
Pressman, Cap 5
o un todo orgánico; 2. un conjunto de hechos, principios, reglas, etc... clasificados y
ordenados de tal manera que muestran un plan lógico uniendo las diferentes partes; 3. un
método o plan de clasificación u ordenación; 4. una forma establecida de hacer algo; un
método; un procedimiento...
El diccionario contiene cinco definiciones pero no cita ningún sinónimo. "Sistema" es
una palabra especial.
Tomando prestada la definición anterior del diccionario Webster, definimos un sistema
basado en computadora como:
Un conjunto u ordenación de elementos organizados para llevar a cabo algún método,
procedimiento o control mediante el procesamiento de información.
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
documentación asociada, que sirven para realizar el método lógico, procedimiento
o control requerido.
Figura 5.1. Elementos del sistema.
Hardware. Los dispositivos electrónicos (p. ej.: UCP, memoria) que proporcionan
la capacidad de computación y los dispositivos electromecánicos (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 colección grande y organizada de información a la que se
accede mediante el software y que es una parte integral del funcionamiento del
sistema.
Documentación. Los manuales, los impresos y otra información descriptiva que
pág.: 2 de 41
Pressman, Cap 5
explica el uso y/o la operación del sistema.
Procedimientos. Los pasos que definen el uso específico de cada elemento del
sistema o el contexto procedimiento en que reside el sistema.
Los elementos se combinan de muchas formas para transformar la información. Por
ejemplo, un robot transforma un archivo de órdenes, que contiene instrucciones
concretas, en un conjunto de señales de control que producen alguna acción física
concreta.
Una característica compleja de los sistemas basados en computadoras es que los
elementos que componen un sistema pueden también representar un macroelemento
de un sistema todavía 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 automatización de una fábrica, que es,
esencialmente, la jerarquía de sistemas que se muestra en la Figura 5.2. En el nivel
más bajo de la jerarquía tenemos máquinas de control numérico (CN), robots y
dispositivos de entrada de datos. Cada uno es por sí mismo un sistema basado en
computadora. Los elementos de las máquinas de CN incluyen hardware electrónico y
electromecánico (p. ej.: procesador y memoria, motores, sensores); software
(comunicaciones, control de las máquinas, interpolación); gente (operadores de las
máquinas); una base de datos (el programa de CN almacenado); documentación y
procedimientos. Se podría aplicar una descomposición 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 jerarquía (Figura 5.2) se define una célula de fabricación. La
célula de fabricación es un sistema basado en computadora que integra elementos
propios (p. ej.: computadoras, fijaciones) y los macroelementos de máquinas de control
numérico, robots y dispositivos de entrada de datos.
Resumiendo, la célula de fabricación y sus macroelementos están compuestos por
elementos del sistema con las siguientes etiquetas genéricas: software, hardware,
gente, base de datos, procedimientos y documentación. En algunos casos, los
macroelementos pueden compartir un elemento genérico. Por ejemplo, el robot y la
máquina de CN pueden ser manejados por un sólo operador (el elemento gente). En
otros casos los elementos genéricos 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 específico dentro del contexto de
toda la jerarquía de sistemas (macroelementos).
En las siguientes secciones
examinamos las tareas que constituyen la ingeniería de sistemas de computadora.
pág.: 3 de 41
Pressman, Cap 5
Figura 5.2. Un sistema de sistemas.
5.2 INGENIERIA DE SISTEMAS DE COMPUTADORA
La ingeniería de sistemas de computadora1 es una actividad de resolución 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 (también llamado analista de sistemas en algunos ámbitos de
información) parte de los objetivos y de las restricciones definidas por el usuario y
desarrolla una representación de la función, del rendimiento, de las interfaces, de las
restricciones de diseño y de la estructura de la información, todo ello pudiendo ser
asociado a cada uno de los elementos genéricos del sistema descritos en la sección
anterior.
La génesis de la mayoría de los nuevos sistemas comienza con un concepto más bien
borroso de la función 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
automatización de fabricación "ha de responder rápidamente si un compartimento de
piezas está vacío". El ingeniero de sistemas debe definir: (1) lo que supone un
compartimento vacío para el robot; (2) los límites precisos de tiempo (en segundos) en
los que se espera la respuesta del software; (3) qué formato debe tener la respuesta.
1
No se deben confundir los términos “ingeniería de sistemas de computadora” e “ingeniería de computadoras”. La
ingeniería de computadoras se centra exclusivamente en el diseño y la implementación del hardware de
computadora y su software de sistema asociado, mientras que la ingeniería de sistemas de computadora se
aplica a todos los productos y sistemas que contienen computadoras.
pág.: 4 de 41
Pressman, Cap 5
Una vez que la función, el rendimiento, las restricciones y las interfaces están
delimitadas, el ingeniero de sistemas procede a realizar la tarea denominada
asignación. Durante la asignación, las funciones son asignadas a uno o más elementos
genéricos del sistema (esto es, software, hardware, gente, etc.). A menudo se
proponen y evalúan varias asignaciones. Para ilustrar el proceso de asignación,
consideremos otro macro elemento del sistema de automatización de fabricación el
sistema de clasificación en cinta transportadora (SCCT) que se presentó en el Capítulo
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 pasarán por una estación de clasificación donde serán identificadas.
Basándose en un número de identificación, impreso en un lado de la caja (incluyendo un
código de barras equivalente), las cajas serán 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 esquemáticamente el sistema SCCT. Antes de continuar,
hagamos una lista de preguntas que haríamos si fuésemos el ingeniero de sistemas.
Entre las muchas preguntas que se deberían plantear y responder están las siguientes:
1. ¿Cuántos números de identificación diferentes van a ser procesados y cuál es su
forma?
2. ¿Cuál es la velocidad de la línea de transporte en metros/segundo y cuál es la
distancia entre cajas en metros?
3. ¿A qué distancia está la estación de clasificación de los compartimentos?
4. ¿A qué distancia están los compartimentos entre sí?
5. ¿Qué debe ocurrir si una caja no tiene el número de identificación o tiene un
número incorrecto?
6. ¿Qué ocurre cuando se llena un compartimento?
7. ¿Hay que mandar información sobre el destino de la caja y el contenido de los
compartimentos a algún otro lugar del sistema de automatización de la fábrica?
¿Se requiere adquisición 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 información y contenido. El ingeniero de sistemas no pregunta al
cliente cómo 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
número de asignaciones alternativas. Se puede observar que el funcionamiento y
rendimiento están asociados a diferentes elementos genéricos del sistema en cada
asignación.
pág.: 5 de 41
Pressman, Cap 5
Asignación 1 Se enseña a un operador a clasificar y se le sitúa en la estación de
clasificación. El o ella lee la caja y la sitúa en el compartimento adecuado.
La asignación 1 representa una solución 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 clasificación. Puede requerirse alguna
documentación (en forma de tabla que relacione el número de identificación con el
compartimento adecuado y una descripción de procedimientos para el entrenamiento
del operador). Así, esta asignación utiliza sólo los elementos gente y documentación.
Asignación 2 Se colocan un lector de código de barras y un controlador en la estación
de clasificación. La salida del lector de barras pasa a un controlador programable que
controla un mecanismo de separación.
El separador dirige la caja hacia el
compartimento apropiado.
Para la asignación 2, se usan el hardware (lector de códigos de barras, control
programable, mecanismo de separación, etc.); el software (para el lector de códigos 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 solución de
automatización total. Cualquiera de estos elementos del sistema puede tener sus
correspondientes manuales y otra documentación, añadiendo otro elemento genérico
del sistema.
Asignación 3 Se colocan un lector de código de barras y un controlador en la estación
de clasificación. La salida del lector de códigos de barras pasa a un brazo de robot que
coge la caja y la coloca en el compartimento apropiado.
La asignación 3 hace uso de elementos genéricos del sistema y de un macroelemento,
el robot. Al igual que la asignación 2, esta asignación utiliza hardware, software, una
base de datos y documentación como elementos genéricos. El robot es un macro
elemento del SCCT y por sí mismo contiene un conjunto de elementos genéricos de
sistema.
Examinando las tres asignaciones alternativas para el SCCT, debería resultar obvio que
la misma función puede ser asignada a diferentes elementos del sistema. Para elegir la
asignación más efectiva, se debe aplicar un conjunto de criterios de evaluación a cada
alternativa.
Los siguientes criterios de evaluación controlan la selección de una configuración del
sistema basándose en una asignación específica de funcionalidad y rendimiento a
elementos genéricos del sistema:
Consideraciones del proyecto. ¿Puede ser construida la configuración dentro de los
límites preestablecidos de coste y tiempo? ¿Cuál es el riesgo asociado a las
estimaciones de tiempo y coste?
Consideraciones comerciales. ¿Representa la configuración la solución más beneficiosa?
¿Puede ser lanzada con éxito? ¿Compensarán los beneficios a los riesgos del
pág.: 6 de 41
Pressman, Cap 5
desarrollo?
Análisis técnico. ¿Existe tecnología para desarrollar todos los elementos del sistema?
¿Están aseguradas la funcionalidad y el rendimiento? ¿Podrá mantenerse correctamente
la configuración? ¿Existen recursos técnicos? ¿Cuál es el riesgo asociado con la
tecnología?
Evaluación de la fabricación. ¿Hay disponibles instalaciones y equipos de fabricación?
¿Hay escasez de los componentes necesarios? ¿Puede llevarse a cabo adecuadamente
una garantía de calidad?
Aspectos humanos. ¿Existe personal cualificado disponible para el desarrollo y la
fabricación? ¿Existen problemas políticos? ¿Comprende el cliente lo que va a hacer el
sistema?
Interfaces con el entorno. ¿Funciona correctamente la interfaz de la configuración
propuesta con el entorno externo del sistema? ¿Se manejan inteligentemente las
comunicaciones máquina - máquina y hombre - máquina?
Consideraciones legales. ¿Introduce esta configuración un riesgo de responsabilidad
indebido? ¿Pueden ser protegidos adecuadamente los aspectos de propiedad? ¿Existe
una infracción potencial?
Examinaremos algunos de estos aspectos con más detalle más adelante en este
capítulo.
Es importante hacer notar que el ingeniero de sistemas debe considerar también
soluciones estándar al problema del cliente. ¿Existe un sistema equivalente? ¿Pueden
ser adquiridas las partes más importantes del producto a un tercero?
la aplicación de criterios de evaluación supone la selección de la configuración de un
sistema específico y la especificación del funcionamiento y del rendimiento asignados al
hardware, al software (y al firmware - microinstrucciones), a la gente, a las bases de
datos, a la documentación y a los procedimientos. Esencialmente, lo que se hace es
asignar a cada elemento del sistema un ámbito de funcionamiento y de rendimiento. La
ingeniería del hardware, la ingeniería del software, la ingeniería humana y la ingeniería
de bases de datos están 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 ingeniería del hardware
El ingeniero de sistemas de computadora selecciona alguna combinación de
componentes de hardware que constituyen un elemento del sistema basado en
computadora. La selección del hardware, aunque no es una tarea sencilla, que se
facilitada por una serie de características: (1) los componentes están empaquetados
como bloques constitutivos individuales; (2) las interfaces entre componentes están
estandarizadas; (3) están disponibles numerosas alternativas “preparadas"; (4) el
pág.: 7 de 41
Pressman, Cap 5
rendimiento, coste y disponibilidad son relativamente fáciles de determinar.
Una configuración del hardware evoluciona de una jerarquía de "bloques constitutivos".
Los componentes discretos (p. ej.: circuitos integrados y componentes electrónicos
tales como resistencias, condensadores, etc.) se ensamblan en una tarjeta de circuito
impreso (CI) que realiza un conjunto específico de operaciones. Las tarjetas se
interconectan con un bus (un camino de información 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
integración a muy gran escala ya es común, funciones que antes estaban disponibles
en un conjunto de tarjetas de circuito impreso con docenas de circuitos integrados,
ahora están disponibles en un chip.
La ingeniería del hardware para computadoras digitales surgió de los precedentes
establecidos en décadas de diseño electrónico. El proceso de la ingenia del hardware
puede verse en tres fases: planificación y especificación; implementación del diseño y
del prototipo; fabricación, distribución y mantenimiento. Las fases se ilustran en la
Figura 5.3 a, b y c.
Una vez que se ha definido la ingeniería del sistema (análisis y definición sistema), se
asignan funciones al hardware. La primera fase de la ingeniería hardware (Figura 5.3 a)
comprende la planificación del desarrollo y el análisis de los requisitos del hardware. La
planificación 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? ¿cuáles son los proveedores, la
disponibilidad y el coste?
 ¿Qué tipos de interfaces se requieren?
 ¿Qué tenemos que diseñar y construir? ¿cuáles 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 realización del sistema de hardware. Estas estimaciones son revisadas por
los responsables y el personal técnico apropiado para ser modificadas si fuese
necesario.
A continuación debemos establecer una guía de acciones" para el diseño del hardware
y su implementación. El análisis 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. Además, deben establecerse las restricciones
del diseño (por ejemplo, tamaño, entorno) y los criterios de prueba. Frecuentemente se
realiza una especificación del hardware. En esta etapa hay que tomar en consideración
muy especialmente las revisiones y las modificaciones.
La popular imagen de la ingeniería en "mangas de camisa" está caracterizada en la
segunda fase (Figura 5.3 b). Se analizan los requisitos y se diseña una configuración
preliminar del hardware. Las revisiones técnicas se suceden a medida que el diseño
pág.: 8 de 41
Pressman, Cap 5
evoluciona hacia esquemas de ingeniería detallados (especificaciones de diseño). Hoy
en día, el análisis y el diseño se gestionan mediante herramientas de ingeniería asistida
por computadora y diseño asistido por computadora (del inglés, 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. Ingeniería del hardware. (a) fase I; (b) fase II; (c) fase III.
pág.: 9 de 41
Pressman, Cap 5
El prototipo (a veces denominado modelo de "placa de prueba" en electrónica),
normalmente, se parece poco al producto final. Por tanto, lo que se va derivando son
las especificaciones para la fabricación. Las placas de prueba se convierten en placas
de PC; las (EPROM) y (PROM) se convierten en ROM; se diseñan las carcasas; se
definen las herramientas y el equipamiento. El enfoque cambia, de la funcionalidad y el
rendimiento, a la facilidad de fabricación.
La tercera fase de la ingeniería del hardware requiere pocas atenciones directas por
parte del ingeniero de diseño, pero pone a prueba las habilidades del ingeniero de
fabricación. Antes de que empiece la producción, se deben establecer métodos para
garantizar la calidad, así como un mecanismo de distribución del producto. En el
inventario se registran los repuestos y se establece una organización de servicio in situ
que se encargue del mantenimiento y de la reparación del producto. En la Figura 5.3c
se ilustra la fase de fabricación de la ingeniería del hardware.
5.2.2.
Software e ingeniería del software
Las características del software y de la ingeniería del software ya se han discutido en
detalle en el Capítulo 1. En esta sección vamos a resumir el estudio anterior dentro del
contexto de la ingeniería de sistemas de computadora.
Durante la ingeniería del sistema se asigna la función y el rendimiento al software. En
algunos casos, la función es simplemente la implementación de un procedimiento
secuencial de manipulación de datos. El rendimiento no queda explícitamente definido.
En otros casos, la función es la coordinación y control internos de otros programas
concurrentes y el rendimiento está definido de forma explícita en términos de tiempo de
espera y de respuesta.
Para conseguir la función y el rendimiento, el ingeniero de software debe construir
adquirir una serie de componentes de software. A diferencia del hardware, los
componentes de software están muy poco estandarizados2. En la mayoría 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 documentación que constituyen el software de la aplicación y el
software del sistema. El software de la aplicación implementa los procedimientos
requeridos para realizar las funciones de procesamiento de la información. El software
del sistema implementa funciones de control que permiten al software de la aplicación
comunicarse con otros diversos elementos de software.
Las áreas genéricas de aplicación del software ya han sido descritas en la Sección
1.2.3. En esta sección consideramos la aplicación del software en el contexto más
amplio de los sistemas basados en computadora. Independientemente de su área de
2
El uso de las técnicas orientadas a los objetos (capítulos 8 y 12) puede llevarnos a disponer de una amplia serie
de “CIs de software” - bloques de construcción de software reutilizables.
pág.: 10 de 41
Pressman, Cap 5
aplicación, un sistema basado en computadora puede ser representado mediante un
modelo de entrada – proceso - salida (EPS). El elemento de software juega un papel
en cada aspecto del modelo.
El software se usa para adquirir información 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
máquina, el software implementa la "conversación" de E/S. En el software se
implementan los mecanismos de petición y de entrada de datos; con el software se
generan las pantallas y los gráficos y, mediante el software, se lleva a cabo la lógica
que conduce al usuario a través de la secuencia de pasos interactivos. Cuando se
adquieren los datos desde un dispositivo, el software, en forma de controlador,
acomoda las características especiales del hardware. Por último, el software también
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 información o control como salida para otro elemento del sistema o
macroelementos. Hoy en día, el tipo más común de procesamiento es el procedimiento
numérico o no numérico en el que todos los pasos, bucles y condiciones están
predefinidos. Sin embargo, en algunos sistemas basados en computadora se están
introduciendo nuevas categorías 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 específicos 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 automático.
Para que un sistema basado en computadora sea de uso práctico, el software debe
proporcionar información o control a otro elemento del sistema o a una fuente externa.
Para producir la información de salida, el software debe dar un formato a los datos que
resulte apropiado para el medio de salida y saber cómo comunicarse con el dispositivo
de salida (p. ej.: impresora, disco óptico, dispositivo de visualización de una estación de
trabajo).
La ingeniería del software es una disciplina para el desarrollo de software de alta
calidad para sistemas basados en computadora. En el Capítulo 1 tratamos la ingeniería
del software con detalle e identificamos cuatro paradigmas para la ingeniería del
software, el ciclo de vida clásico, la creación de prototipos, el modelo en espiral y las
técnicas de cuarta generación. 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 análoga a como lo hicimos con el proceso de ingeniería del
hardware.
Las Figuras 5.4 a, b y c ilustran los pasos genéricos del proceso de ingeniería del
software. Las distintas partes de la Figura ilustran los pasos que se deben llevar a cabo
pág.: 11 de 41
Pressman, Cap 5
y las distintas representaciones del software que se derivan según se evoluciona del
concepto a la realización.
Fase de definición. La fase de definición de la ingeniería del software, representada
en la Figura 5.4a, comienza con la etapa de planificación del software. Durante esta
etapa se desarrolla una descripción bien delimitada del ámbito del esfuerzo de software;
se lleva a cabo un análisis del riesgo; se definen los recursos necesarios para
desarrollar el software; se establecen las estimaciones de tiempos y costes. El
propósito de la etapa de planificación del software es proporcionar una indicación
preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se
hayan establecido. La gestión del proyecto realiza y revisa un plan del proyecto de
software.
El siguiente paso en la fase de definición es el análisis y la definición 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 análisis formal del ámbito de información para establecer modelos del flujo y la
estructura de la información. Luego, se amplían esos modelos para convertirlos en una
especificación 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 características
para el diseño del software. El análisis global del elemento de software define los
criterios de validación que se utilizarán para demostrar que se han podido conseguir los
requisitos.
El análisis y definición de los requisitos del software es un esfuerzo conjunto llevado a
cabo por el desarrollador del software y el cliente. La especificación de requisitos del
software es el documento distribuible que se produce como resultado de esta etapa.
La fase de definición culmina con una revisión técnica de la especificación de requisitos
del software (o, en lugar de la especificación, 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
información no cubierta durante el análisis de requisitos puede influir en las
estimaciones hechas durante la planificación. Los elementos distribuibles desarrollados
durante la fase de definición 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 diseño.
El primer paso de la fase de desarrollo se centra en el diseño. El proceso de diseño del
software comienza con una descripción del diseño arquitectónico 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 diseño que aseguren la calidad. Se
revisa el paso preliminar de diseño para garantizar la completitud y el seguimiento de
los requisitos del software. Se produce un primer borrador de la especificación del
pág.: 12 de 41
Pressman, Cap 5
diseño3, convirtiéndose en una parte de la configuración del software.
Figura 5.4. Ingeniería del software – (a) Fase de definición; (b) Fase de desarrollo; (c) Fase de
verificación, lanzamiento y mantenimiento.
3
Actualmente se puede crear la especificación del diseño con herramientas CASE especializadas (p. ej.:
Teamwork, de Cadre) y mantenerlo en forma legible para la máquina. En algunos casos, la documentación del
diseño, denominada lenguaje de diseño de programa, se incluye directamente en los archivos del código fuente.
pág.: 13 de 41
Pressman, Cap 5
A continuación, se consideran los aspectos procedimentales de cada componente
modular del diseño del software. Cada descripción procedimental detallada se añade a
la especificación del diseño, una vez revisada.
Una vez terminado el diseño, se lleva a cabo la codificación - la generación de un
programa que use un lenguaje de programación apropiado o una herramienta CASE.
La metodología de la ingeniería del software contempla la codificación como la
consecuencia de un buen diseño. En cuanto al código, se revisa su estilo y su claridad,
y se comprueba que haya una correspondencia directa con la descripción detallada del
diseño. El listado en lenguaje fuente de cada componente modular constituye el
documento de configuración de la etapa de codificación.
Fase de verificación, lanzamiento y mantenimiento. Durante la última fase del
proceso de ingeniería del software (Figura 5.4c), el ingeniero de software prueba el
software para encontrar el mayor número posible de errores antes de que sea puesto
en circulación, lo prepara para su lanzamiento y lo mantiene a lo largo de toda su vida
útil.
Después de haber generado el código fuente, se lleva a cabo una serie de actividades
de verificación y validación. Las pruebas de unidad intentan verificar el rendimiento
funcional de cada componente modular individual del software. La prueba de
integración constituye un medio de construcción de la arquitectura del software y de
prueba de su funcionamiento y de sus interfaces. La prueba de validación comprueba
que se han conseguido todos los requisitos. Tras cada uno de estos pasos de prueba,
puede que haya de realizarse una depuración - diagnóstico y corrección de defectos.
Para los pasos de prueba, se puede desarrollar un plan y procedimiento de prueba.
Siempre se realiza una revisión de la documentación, 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 garantía de calidad (GC) para asegurar que se han generado y
catalogado los registros y los documentos internos adecuados, que se ha desarrollado
una documentación 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 construcción al
mantenimiento - corrección de errores, adaptación al entorno y mejora de la función. El
reconocimiento de este hecho es el primer paso hacia una disminución 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 modificación del
software no sólo afecta al código, sino a la configuración entera (es decir, todos los
documentos, datos y programas desarrollados en las fases de planificación y
desarrollo).
pág.: 14 de 41
Pressman, Cap 5
5.2.3.
Factores humanos e ingeniería humana
Un sistema basado en computadora casi siempre tiene un elemento humano. Puede
que una persona interactúe directamente con el hardware y con el software,
manteniendo un diálogo que dirija el funcionamiento del sistema; en cualquier caso, la
responsable del desarrollo y del mantenimiento del sistema es la gente.
Nuestra percepción del elemento humano de los sistemas basados en computadora ha
cambiado en los últimos años. Los primeros sistemas basados en computadora
forzaban al usuario a comunicarse de una forma que fuera fácil de implementar en
hardware y en software (si bien no siempre fuera fácil la comunicación en el contexto
humano). Hoy, la expresión "amigable con el usuario" tiene un nuevo significado. La
ingeniería humana para los sistemas basados en computadora es considerada como un
paso importante del desarrollo de sistemas.
Cuando la gente interactúa con otra gente, un conjunto de reglas, esperas y respuestas,
culturalmente definidas, permiten que la interacción se realice suavemente.
Desgraciadamente, los convenios existentes para la interacción entre personas, no
están presentes cuando lo que se pretende es una interacción hombre maquina (IHM).
Antes de que el ingeniero de sistemas pueda asignar una función al elemento humano,
se debe especificar la interacción que es necesaria para poder realizar la función. 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 representación del conocimiento, el pensamiento y el razonamiento, la percepción
visual y la construcción del diálogo humano.
La ingeniería humana es una actividad multidisciplinaria que aplica un conocimiento
derivado de la psicología para especificar y diseñar IHM de alta calidad. El proceso de
la ingeniería humana comprende los siguientes pasos:
Análisis de actividad. Cada actividad asignada a un elemento humano se evalúa
en el contexto de la interacción requerida con otros elementos. Cada actividad se
subdivide en tareas que son analizadas en etapas posteriores.
Análisis y diseño semántico. Se define el significado preciso de cada acción
requerida del usuario y de cada acción producida por la máquina. Se establece el
diseño de un "diálogo" que comunique adecuadamente la semántica.
Diseño léxico y sintáctico. Se identifica y representa la forma específica de las
acciones y las órdenes. Después, se diseña la implementación en software y en
hardware de cada acción u orden.
Diseño 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 físicas (brillo, utilización del espacio, etc.), además de la propia IHM.
Creación de prototipos. Es difícil, si no imposible, especificar formalmente una
pág.: 15 de 41
Pressman, Cap 5
IHM sin usar un prototipo. La creación de prototipos permite evaluar la IHM desde
una perspectiva humana, con una participación activa en lugar de una evaluación
pasiva. La creación de prototipos supone una evaluación y una aplicación iterativa
de todos los pasos de ingeniería humana anteriores.
En el Capítulo 14 se incluye un tratamiento más detallado de los factores humanos y de
la ingeniería humana (aplicada al diseño de interfaces de usuario).
5.2.4.
Bases de datos e ingeniería 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 almacén de información a menudo es crucial para el
funcionamiento general del sistema. La ingeniería de bases de datos (término
relativamente nuevo que comprende análisis, diseño e implementación de bases de
datos) es una disciplina técnica que se aplica una vez que se ha definido el ámbito de la
información. Por ello, el papel del ingeniero de sistemas es el de definir la información
que va a contener la base de datos, los tipos de peticiones que se podrán procesar, la
manera en que se accederá a los datos y la capacidad de la base de datos. Aunque la
ingeniería de bases de datos es un tema que requiere un estudio en profundidad (véase
[DAT86], IEEE89]), el análisis y el diseño de los datos son actividades fundamentales
de la ingeniería del software, independientemente de la presencia o no de una base de
datos formal. Estos temas de la ingeniería de bases de datos, llamados colectivamente
diseño de datos, se estudian en los Capítulos 8, 9 y 10.
5.3. ANALISIS DEL SISTEMA
El análisis del sistema es una actividad que engloba la mayoría de las tareas que
hemos llamado colectivamente ingeniería de sistemas basados en computadora.
Algunas veces se incurre en confusión porque el término se usa a menudo en un
contexto que alude sólo a las actividades de análisis de los requisitos del software
(véanse los Capítulos 6 al 9). Para el propósito de este estudio, el análisis del sistema
se centra en todos los elementos del sistema - no sólo en el software.
El análisis del sistema se realiza teniendo presentes los siguientes objetivos: (1)
identificar las necesidades del cliente; (2) evaluar la viabilidad del sistema; (3) realizar
un análisis técnico y económico; (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 definición del sistema que sea la base para todo el
trabajo posterior de ingeniería. Para alcanzar con éxito esos objetivos, se requiere
experiencia, tanto en hardware como en software (así como en ingeniería humana y en
bases de datos). Aunque la mayoría de los profesionales de la industria reconocen que
el tiempo y el esfuerzo gastado en el análisis de sistemas producen dividendos
importantes más adelante en el proceso de desarrollo del sistema, todavía surgen tres
preguntas:
pág.: 16 de 41
Pressman, Cap 5
 ¿Cuánto esfuerzo se debe emplear en el análisis y en la definición de sistemas y
de software? Es difícil establecer unas directrices definitivas para determinar el
esfuerzo de análisis. El tamaño del sistema y su complejidad, el área de
aplicación, el uso final y las obligaciones del contrato son sólo unas pocas de las
muchas variables que afectan al esfuerzo total dedicado al análisis. 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 análisis del sistema y aplicar otro 10 o 20
por 100 del esfuerzo de la ingeniería del software del análisis de los requisitos del
software.
 ¿Quién 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 técnico
y administrativo, tanto del cliente como del que desarrolla el sistema. Para
muchos proyectos grandes, debe crearse un equipo para cada tarea de análisis.
 ¿Por qué es tan difícil? Se trata de una transformación de un concepto dudoso en
un conjunto concreto de elementos tangibles. Debido a que durante el análisis la
comunicación es excepcionalmente densa, abundan las oportunidades de mal
entendimiento, omisiones, inconsistencias y errores. Finalmente, la percepción del
sistema puede cambiar a medida que avanza la actividad, invalidando, de esta
manera, el trabajo anterior.
5.3.1 Identificación de las necesidades
El primer paso del proceso de análisis del sistema implica la identificación de las
necesidades. El analista (ingeniero de sistemas) se entrevista con el cliente o su
representante. El cliente puede ser un representante de una compañía externa, del
departamento de marketing de la compañía del analista (cuando se está definiendo un
producto) o de otro departamento técnico (cuando se va a desarrollar un sistema
interno).
La identificación de las necesidades es el punto de partida en la evolución 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 información que
se va a obtener, la información que se va a suministrar, las funciones y el rendimiento
requerido. El analista se asegura de distinguir entre lo que "necesita" el cliente
(elementos críticos para la realización) 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 evaluación
de la información suplementaria: ¿existe la tecnología necesaria para construir el
sistema? ¿qué recursos de fabricación y de desarrollo especiales se requerirán? ¿qué
límites 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, también se hacen las
siguientes preguntas: ¿cuál es el mercado potencial para el producto? ¿cómo se
compara este producto con los de la competencia? ¿qué lugar ocupa este producto
dentro de la línea global de la compañía?
pág.: 17 de 41
Pressman, Cap 5
La información recogida durante la etapa de identificación 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 comunicación 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 años de esfuerzo, miles de millones de
pesetas y una inversión profesional incalculable, si un sistema mal concebido es
reconocido como tal al principio de la etapa de definición.
Figura 5.5. Información requerida por el analista.
El análisis de viabilidad y el análisis del riesgo (Capítulo 4) están relacionados de varias
maneras. Si el riesgo del proyecto es grande (por cualquiera de las razones vistas en el
Capítulo 4), se reduce la posibilidad de producir software de calidad. Sin embargo,
durante la ingeniería del sistema centramos nuestra atención en cuatro áreas de interés
básico:
Viabilidad económica. Una evaluación del coste de desarrollo frente al beneficio
final producido por el sistema desarrollado.
Viabilidad técnica.
Un estudio de la funcionalidad, el rendimiento y las
restricciones que pueden afectar a la posibilidad de realización de un sistema
aceptable.
Viabilidad legal. Una determinación de cualquier infracción, violación o ilegalidad
que pudiera resultar del desarrollo del sistema.
pág.: 18 de 41
Pressman, Cap 5
Alternativas. Una evaluación de los enfoques alternativos para el desarrollo del
sistema
No será necesario llevar a cabo un estudio de viabilidad para sistemas en los que la
justificación económica es obvia, el riesgo técnico 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 justificación económica es normalmente la principal consideración para la mayoría
de los sistemas (excepciones notables son los sistemas de defensa nacional, los
sistemas impuestos por la ley y las aplicaciones de alta tecnología, como el programa
espacial). La justificación económica comprende un amplio rango de aspectos, entre
los que se encuentran el análisis de coste - beneficio (tratado en la siguiente sección),
las estrategias de ingresos a largo plazo, el impacto en otros productos o en centros de
explotación, el coste de los recursos que se necesitan para el desarrollo y el crecimiento
potencial del mercado.
La viabilidad técnica es frecuentemente el área más difícil 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 análisis y de
definición se realice en paralelo con el análisis de viabilidad técnica. De esta forma, se
pueden juzgar las especificaciones concretas según se van determinando.
Las consideraciones que van asociadas normalmente a la viabilidad técnica son:
Riesgo del desarrollo. ¿Puede el elemento del sistema ser diseñado de tal forma
que las funciones y el rendimiento necesarios se consigan dentro de las
restricciones determinadas en el análisis?
Disponibilidad de recursos. ¿Hay personal cualificado para desarrollar el elemento
del sistema en cuestión? ¿Están disponibles para el sistema otros recursos
necesarios (de hardware y de software)?
Tecnología. ¿Ha progresado la tecnología relevante lo suficiente como para poder
soportar el sistema?
Los desarrolladores de los sistemas basados en computadora son optimistas por
naturaleza. (¿Quién más tiene el suficiente coraje para intentar hacer aquello a lo que
nosotros frecuentemente nos comprometemos sin pensarlo mucho?) Sin embargo,
durante una evaluación de viabilidad técnica debería prevalecer una actitud cínica, 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 técnico. Un estudio de los aspectos legales del software
va más allá del alcance de este libro. El lector interesado puede acudir a Gemignani
[GEM81], Harris [HAR85] o Scott [SC089].
pág.: 19 de 41
Pressman, Cap 5
El grado en el que se consideran las alternativas muchas veces está limitado por
restricciones de tiempo y de dinero; sin embargo, no se debería descartar cualquier
alternativa legítima, aunque no tenga quien "la financie".
El estudio de viabilidad puede documentarse en un informe separado de los otros
documentos importantes de gestión e incluirse como apéndice en la especificación del
sistema. Aunque el formato del informe de viabilidad puede variar, el esquema de la
tabla 5.1 cubre la mayoría de los aspectos importantes.
Tabla 5.1. Esquema del estudio de viabilidad
I. Introducción
A. Declaración del problema
B. Entorno de implementación
C. Restricciones
II. Resumen y recomendaciones de gestión
A. Hallazgos importantes
B. Comentarios
C. Recomendaciones
D. Impacto
III. Alternativas
A. Configuraciones del sistema alternativas
B. Criterio utilizado en la selección del enfoque definitivo
IV. Descripción del sistema
A. Declaración resumida del ámbito
B. Viabilidad de los elementos asignados
V. Análisis de coste beneficio
VI. Evaluación del riesgo técnico
VII. Consideraciones legales
VIII. Otros asuntos específicos del proyecto
La revisión 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 decisión de "seguir/no
seguir". Debe tenerse en cuenta que durante las etapas de planificación, especificación
y desarrollo de la ingeniería del hardware y del software, se tomarán otras decisiones
del tipo seguir/no seguir.
pág.: 20 de 41
Pressman, Cap 5
5.3.3. Análisis económico
Entre la información más relevante que contiene el estudio de viabilidad se encuentra el
análisis de coste - beneficio una evaluación de la justificación económica para un
proyecto de sistema basado en computadora. El análisis de coste beneficio señala los
costes del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es,
medibles directamente en pesetas) e intangibles del sistema.
El análisis de coste beneficio es complicado porque los criterios varían según las
características del sistema a desarrollar, el tamaño relativo del proyecto y la
recuperación esperada de la inversión como parte del plan estratégico de la compañía.
Además, muchos beneficios obtenidos de los sistemas basados en computadora son
intangibles (p. ej.: una mejor calidad del diseño mediante una optimización iterativa, una
mayor satisfacción del cliente debida a un control programable y unas mejores
decisiones comerciales a partir de datos de ventas con formato previamente
analizados). Puede ser difícil lograr comparaciones directas cuantitativas.
Como hemos visto anteriormente, el análisis de los beneficios diferirá dependiendo de
las características del sistema. Para ilustrar este hecho, consideremos los beneficios
de los sistemas de información de gestión [KIN78] mostrados en la Tabla 5.2. La
mayoría de los sistemas de proceso de datos se desarrollan teniendo como principal
objetivo una mejor cantidad, calidad, rapidez y organización de la información. Así, los
beneficios de la Tabla 5.2 se centran en el acceso a la información y su impacto en el
entorno del usuario. Los beneficios que se pueden asociar a programas de análisis
científico y de ingeniería 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 diseño asistido por
computadora (CAD) que vaya a reemplazar a elementos del proceso manual de diseño
en ingeniería. El analista de sistemas debe definir características ponderables del
sistema existente (diseño manual) y del sistema propuesto (CAD). Seleccionando el
tiempo de producción de un dibujo completo y detallado (t-dibujo) entre las muchas
cantidades medibles, el analista llega a la conclusión de que el sistema CAD supondrá
una reducción de 4 a 1 en ese t-dibujo. Para cuantificar con más 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, número de dibujos por año = 8.000
p, porcentaje de dibujo que se va a realizar en el sistema CAD = 60 por 100
pág.: 21 de 41
Pressman, Cap 5
Tabla 5.2. Posibles beneficios del sistema de información*
Beneficios de las contribuciones a las tareas de cálculo e impresión
Reducción del coste en cálculos e impresiones (RC)
Mejora en la exactitud de las tareas de cálculo (RE)
Posibilidad de cambiar rápidamente las variables y los valores en los programas de
cálculo (AF)
Gran incremento en la velocidad de los cálculos y las impresiones (AV)
Beneficios de las contribuciones a las tareas de mantenimiento de registros
Posibilidad de recoger y guardar "automáticamente" datos de los registros (RC, AV, RE)
Mantenimiento de registros más completo y más sistemático (RC, RE)
Aumento de la capacidad para el mantenimiento de registros en términos de espacio y
coste (RC)
Estandarización 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 búsqueda de registros
Obtención de registros más rápida (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 búsquedas a través de
telecomunicaciones (AF, AV)
Mejores posibilidades de mantener un registro sobre los accesos a los registros y por
quién (RE, MG)
Posibilidad de auditar y analizar la actividad de búsqueda de registros (MG, RE)
Beneficios de las contribuciones a la posibilidad de reestructuración del sistema
Posibilidad de cambiar simultáneamente 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 análisis y de simulación
Posibilidad de llevar a cabo rápidamente complejos cálculos simultáneos (AV, AF, RE)
Posibilidad de crear simulaciones de fenómenos 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 planificación y la toma de decisiones (MG, AF)
Beneficios de las contribuciones al control de procesos y de recursos
Reducción de la necesidad de trabajo forzado en el control de procesos y de recursos
(RC)
Mejores posibilidades de "afinar" procesos tales como la línea de ensamblaje (RC, MG,
AV, RE)
Mejores posibilidades de mantener una continua monitorización de los procesos y los
recursos disponibles (MG, RE, AF)
*
Abreviaturas: RC= reducción o eliminación de costes; RE= reducción de errores; AF= aumento en
fiabilidad; AV= aumento en la velocidad de la actividad; MG = mejoras en el control o en la
planificación de la gestión.
Fuente: King y Schrems [KIN78], pág. 23. Reimpreso con permiso.
pág.: 22 de 41
Pressman, Cap 5
Conocidos los datos anteriores, puede establecer una estimación del ahorro anual - el
beneficio:
Ahorro en el coste del tiempo de dibujo = reducción x t-dibujo x n x c x p
= 9.600.000 ptas. por año
Otros beneficios tangibles del sistema CAD serían tratados de una manera similar. A
los beneficios intangibles (p. ej.: mejor calidad de diseño y mayor estímulo para los
empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una
recomendación 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 recuperación de la
inversión, el punto de igualdad y el período de amortización. El gráfico que muestra la
Figura 5.6 ilustra estas características para el ejemplo del sistema CAD expuesto
anteriormente. Asumimos que el ahorro total por año 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 gráfico de la Figura 5.6 determinamos que el período de amortización es de 3,1
años. En realidad, la recuperación de la inversión se determina con un análisis más
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 inversión.
Contabilizando los beneficios intangibles, el director administrativo decide silos
resultados económicos justifican el sistema.
Figura 5.6. Análisis de coste beneficio
pág.: 23 de 41
Pressman, Cap 5
Tabla 5.3. Posibles costes del sistema de información
___________________________________________________________________
Costes de avituallamiento
Coste de consultoría
Coste de la compra o alquiler del equipo actual
Coste de la instalación 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 instalación del equipo de comunicaciones (líneas telefónicas, líneas de datos,
etc.)
Coste del personal dedicado a la puesta a punto
Coste de las actividades de búsqueda y contratación de personal
Coste de los trastornos al resto de la organización
Coste de la gestión requerida para dirigir la actividad de puesta a punto
Costes relativos al proyecto
Coste de la compra de software de aplicación
Coste de modificaciones del software para ajustarse a los sistemas locales
Coste de personal, generales, etc., del desarrollo interno de aplicaciones
Coste de la formación del personal en el uso de las aplicaciones
Coste de los procedimientos de recolección de datos y de recolección de datos de
instalación
Coste de la preparación de documentación
Coste de la gestión del desarrollo
Costes continuos
Coste del mantenimiento del sistema (hardware, software y utilidades)
Coste de los alquileres (electricidad, teléfono, etc.)
Coste de la depreciación del hardware
Coste de la plantilla involucrada en las actividades de gestión, operación y planificación
del sistema de información.
___________________________________________________
Fuente: King y Schrems [KIN78], pág. 24. Reimpreso con permiso.
Otro aspecto del análisis de coste beneficio es la consideración de los costes
incrementales asociados con los beneficios añadidos (mayor o mejor funcionalidad y
rendimiento). Para los sistemas basados en computadora, la relación 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. Después de ese punto, cada beneficio
adicional es demasiado caro. Por ejemplo, consideremos una función de sondeo en
tiempo real que tiene 500 milisegundos de tiempo muerto. Se pueden añadir nuevas
tareas a un coste relativamente bajo; sin embargo, si la ejecución total de la tarea se
pág.: 24 de 41
Pressman, Cap 5
aproxima a los 500 milisegundos, el coste de implementación aumenta drásticamente,
ya que se debe mejorar el rendimiento global.
Figura 5.7. Incremento de la relación coste beneficio.
En otros casos (curva ABCC'), los costes aumentan proporcionalmente hasta A y
después se nivelan a favor de los beneficios añadidos (hasta B), antes de aumentar
drásticamente (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 añadir funciones multiusuario puede bajar un poco. Sin embargo, una vez que
se alcance la capacidad máxima del procesador, las nuevas funciones requerirán un
procesador más potente, con el consiguiente gran incremento en el coste.
La siguiente cita [FRI77] caracteriza mejor el análisis de coste beneficio:
Al igual que se olvida la retórica política después de las elecciones, puede que se olvide el
análisis de coste beneficio una vez que comienza la implementación del proyecto. Sin
embargo, es extremadamente importante, ya que ha sido el vehículo con el que se ha
conseguido la aprobación por parte de la gestión.
Sólo gastando el tiempo necesario para evaluar la viabilidad, reducimos las
oportunidades de situaciones extremadamente embarazosas (o más que embarazosas)
en etapas posteriores de un proyecto de un sistema. El esfuerzo gastado en el análisis
de viabilidad que resulta en la cancelación de un proyecto propuesto no es un esfuerzo
desaprovechado.
5.3.4. Análisis técnico
Durante el análisis técnico, el analista evalúa los méritos técnicos del concepto de
sistema, mientras que al mismo tiempo recoge información adicional sobre el
rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de producción. En
algunos casos la etapa de análisis del sistema también incluye una cantidad limitada de
investigación y de diseño.
pág.: 25 de 41
Pressman, Cap 5
El análisis técnico empieza con una definición de la viabilidad técnica del sistema
propuesto. ¿Qué tecnologías se requieren para conseguir la funcionalidad y el
rendimiento del sistema? ¿Qué nuevos materiales, métodos, algoritmos o procesos se
requieren y cuál es el riesgo de su desarrollo? ¿Cómo afectarán al coste estos
elementos de tecnología?
Las herramientas de que se puede disponer para el análisis técnico se encuentran en
las técnicas matemáticas de modelización y optimización, en la probabilidad y la
estadística, en la teoría de colas y en la teoría de control - por nombrar unas cuantas4.
Sin embargo, es importante tener en cuenta que la evaluación analítica no es siempre
posible. La modelización (bien matemática o física) es un mecanismo efectivo para el
análisis técnico de sistemas basados en computadora. La Figura 5.8 ilustra el flujo
global de información del proceso de modelización. El modelo se crea a partir de la
observación del mundo real o de una aproximación 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 información de viabilidad técnica para el
sistema propuesto.
Figura 5.8. Modelización del sistema.
Blanchard y Fabrycky [BLA81, pág. 270] definen un conjunto de criterios para el uso de
modelos durante el análisis técnico de sistemas:
1. El modelo debe representar la dinámica de la configuración del sistema que está
siendo evaluado, de una forma que sea suficientemente simple de comprender y
manipular, y también que esté lo suficientemente cerca de la realidad operativa como
para obtener resultados satisfactorios.
2. El modelo debe realzar aquellos factores que sean más relevantes para el problema en
4
Hay un tipo de herramientas CASE, denominadas herramientas de simulación y creación de prototipos, que
pueden ayudar bastante en el análisis técnico. Estas herramientas se tratan en los capítulos 15 y 22.
pág.: 26 de 41
Pressman, Cap 5
cuestión y suprimir (con discreción) aquellos que no sean importantes.
3. El modelo debe ser amplio, incluyendo todos los factores relevantes, y fiable en cuanto
a repetición de resultados.
4. El diseño del modelo debe ser lo suficientemente simple como para permitir una rápida
implementación de la resolución del problema. A no ser que la herramienta pueda ser
utilizada de una manera rápida 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.
También puede ser deseable evaluar un elemento específico de un sistema
independientemente del resto de los elementos.
5. El diseño del modelo debe incorporar previsiones para poder modificarlo y/o expandirlo
fácilmente y permitir la evaluación 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 información que no se hayan detectado a primera vista y, consecuentemente,
sugerir cambios beneficiosos.
Los resultados del análisis técnico son la base de otra decisión del tipo "seguir / no
seguir" con el sistema. Si el riesgo técnico 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
Asignación y compromisos
Una vez que se ha respondido a las cuestiones relativas a la tarea de análisis, hay que
considerar soluciones alternativas. Cada función del sistema, con su rendimiento
requerido y sus características de interfaz, es asignada a uno o más elementos del
sistema.
Por ejemplo, el análisis de un nuevo sistema de gráficos de computadora indica que
una función importante es la transformación espacial de las imágenes gráficas
tridimensionales. Una investigación de soluciones alternativas para la función de
transformación revela las siguientes opciones:
1. Todas las transformaciones tridimensionales realizadas por el software.
2. Las transformaciones "simples" (p. ej.: cambio de escala, translación y rotación)
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 gráfico implementado con
hardware.
El proceso general de evaluación 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
evalúa cada alternativa de configuración para el sistema de acuerdo con un conjunto de
"parámetros de evaluación" (criterios de compromiso) que han sido ordenados de
acuerdo con su importancia (Figura 5.10). En general, los parámetros de evaluación
están relacionados con los factores económicos (p. ej.: el coste del ciclo de vida).
Cuando dos o más parámetros de evaluación del sistema de bajo orden (p. ej.: el
pág.: 27 de 41
Pressman, Cap 5
tiempo de respuesta o la resolución de la pantalla) pueden variar (en diferentes
asignaciones), permitiendo que se siga alcanzando un parámetro deseable de alto
orden (p. ej.: el coste o la fiabilidad), se aísla un área de compromiso (Figura 5.11).
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 análisis de
requisitos y de diseño. Ya hemos visto que cada sistema basado en computadora se
puede modelar como una transformación de información mediante una arquitectura de
entrada - proceso - salida. Hatley y Pirbhai [HAT87] han ampliado este enfoque,
incluyendo dos características adicionales del sistema - el procesamiento de la interfaz
de usuario y el procesamiento de mantenimiento y de autocomprobación. Aunque estas
características adicionales no están presentes para todos los sistemas basados en
computadora, son muy comunes y su especificación hace que cada modelo de sistema
sea más 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)
función y control del sistema, (4) salida y (5) mantenimiento y autocomprobación. El
formato de la plantilla de arquitectura aparece en la Figura 5.12.
Como casi todas las técnicas de modelización utilizadas en la ingeniería del software y
de sistemas, la plantilla de arquitectura permite al analista crear una jerarquía de
detalles. En el nivel superior de la jerarquía está el diagrama de contexto de la
arquitectura (DCA).
pág.: 28 de 41
Pressman, Cap 5
Figura 5.9. Evaluación de alternativas. (Reimpreso con permiso de
Prentice Hall, EngleWood Cliffs, NJ)
El diagrama de contexto establece los límites de información 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 información externos utilizados por el
sistema, todos los consumidores de información externos creados por el sistema y
todas las entidades que se comunican a través de la interfaz o realizan mantenimiento o
autocomprobación.
pág.: 29 de 41
Pressman, Cap 5
Figura 5.10. Orden de los parámetros de evaluación. (Reimpreso con
permiso de Prentice Hall, Englewood Cliffs, NJ)
Figura 5.11. Area de compromiso.
pág.: 30 de 41
Pressman, Cap 5
Para ilustrar el uso del DCA, consideremos una versión ampliada del sistema de
clasificación de cinta transportadora visto anteriormente en este capítulo. La versión
ampliada utiliza una computadora personal (PC) como esta de clasificación. El PC
ejecuta todo el software del SCCT; está conectado al lector de códigos de barras para
leer los números de serie de cada caja; está conectado al equipo de supervisión de la
cinta transportadora para obtener la velocidad; guarda todos los números de serie
clasificados; interactúa con un operador de la estación de clasificación produciendo una
serie de informes y diagnósticos; manda señales de control al hardware encargado de
la maniobra para clasificar las cajas y se comunica con la computadora central de la
fábrica de automatización. En la Figura 5.13 se muestra el DCA para la versión
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 información del sistema. Por ejemplo, el lector de códigos de
barras produce información que entra en el sistema SCCT. El símbolo que representa
el sistema completo (o, a niveles más bajos, los subsistemas principales) es un
rectángulo con esquinas redondeadas. Aquí, el SCCT está representado en la región
de proceso y control, en el centro del DCA. Las flechas etiquetadas del DCA
representan la información (de datos y de control) que se fluye entre el entorno externo
y el sistema SCCT. La entidad externa lector de códigos de barras produce
información de entrada que está etiquetada como código 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 más detalle el rectángulo sombreado de la Figura 5.13. Identifica los subsistemas
principales que permiten el funcionamiento del sistema de clasificación 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 guía para el desarrollo del DFA un "esquema"
más detallado del SCCT, el ingeniero de software utiliza la información que fluye a
través de las regiones de DCA. El diagrama de flujo de la arquitectura muestra los
5
Hatley y Pirbhai [HAT87] los denominan módulos del sistema.
pág.: 31 de 41
Pressman, Cap 5
subsistemas principales y las líneas importantes de flujo de información (control y
datos). Además, 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 más elementos del
sistema (p. ej.: hardware, software, gente) según 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).
pág.: 32 de 41
Pressman, Cap 5
El diagrama inicial de flujo de la arquitectura se constituye en el nodo raíz de la
jerarquía de DFAs. Se puede ampliar cada rectángulo redondeado del DFA inicial en
otra plantilla de arquitectura dedicada exclusivamente a él. Este proceso se ilustra
esquemáticamente en la Figura 5.15. Cada uno de los DFAs del sistema se puede
utilizar como punto de partida para los posteriores pasos de ingeniería del subsistema
que describe.
Figura 5.15. Construcción de una jerarquía de DFAs.
5.4.2.
Especificación de la arquitectura del sistema
Se pueden especificar (limitar) los subsistemas y la información que fluye entre ellos
para que esté disponible en los posteriores trabajos de ingeniería. La especificación del
diagrama de arquitectura6 (EDA) presenta la información sobre cada subsistema y el
flujo de información entre los subsistemas. La EDA contiene una descripción denominada narrativa de módulo del sistema - de cada subsistema. La narrativa de
módulo del sistema describe qué hace el subsistema, qué información procesa y cómo
está relacionado con otros subsistemas. Además de las narrativas, la EDA puede
contener un diccionario de arquitectura - una lista con los elementos de información que
aparecen en el DFA y sus descripciones. Por ejemplo el elemento de información
número de serie de la Figura 5.14 podría describirse tal como muestra la Figura 5.16.
Como se puede ver en la figura, se utiliza una notación especial para representar la
descripción del elemento de información. La notación (que se describe en el Capítulo 7)
6
La EDA es una adaptación de varias especificaciones diferentes sugeridas por Hartley y Pirbhai [HAT87]. Para
Simplificar, lo hemos combinado en un único documento
pág.: 33 de 41
Pressman, Cap 5
indica qué número de serie es un elemento de datos compuesto - es decir, un
elemento de datos que está compuesto por otros tres elementos de datos: prefijo de
tipo de producto, identificador numérico y categoría de coste. En realidad, en el
diccionario también 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 comunicación indica la manera en que se transfiere físicamente la información desde
el origen y el destino. En otras circunstancias, el camino de comunicación puede estar
definido como un bus o un canal que tendrá que ser implementado como parte del
diseño del sistema. El diccionario de la arquitectura es una versión a nivel de sistema
del diccionario de requisitos - una importante notación de análisis del software que se
trata en detalle en el Capítulo 7.
El último elemento de la especificación del diagrama de arquitectura es el diagrama de
interconexión de la arquitectura (DIA) y la correspondiente descripción de la
interconexión. Las flechas del DFA indican el flujo del control y de los datos, sin
describir cómo se efectúa ese flujo de información. El DIA y la especificación
correspondiente, describen cómo se transfiere la información - electrónicamente (p. ej.:
por un bus), ópticamente (p. ej.: por un enlace óptico de tal ancho de banda) o
mecánicamente (p. ej.: mediante un actuador o una articulación mecánica). Para
desarrollar el DIA, el ingeniero de sistemas tiene que tomar decisiones de
implementación que es mejor dejarlas para la etapa de diseño. Por esta razón,
posponemos el estudio de los aspectos de interconexión hasta el Capítulo 15.
Figura 5.16. Una entrada del diccionario de la arquitectura.
5.5. SIMULACION Y MODELIZACION DEL SISTEMA
Hace dos décadas, 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,
soltándolo desde un acantilado, dejando que se estrelle y comenzando de nuevo". De
hecho, actualmente seguimos haciéndolo así con al menos un tipo de sistema - el
sistema reactivo.
Muchos sistemas basados en computadora interactúan 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, basándose en esos sucesos, el sistema
impone un control sobre las máquinas, los procesos e incluso la gente que hace que se
pág.: 34 de 41
Pressman, Cap 5
produzcan los sucesos. Los sistemas de tiempo real y los sistemas empotrados
muchas veces se encuentran en la categoría de los temas reactivos.
Desgraciadamente, los desarrolladores de sistemas reactivos a veces tienen que luchar
para conseguir que funcionen correctamente. Hasta hace poco, era difícil predecir el
rendimiento, la eficiencia y el comportamiento de dichos sistemas antes de construirlos.
En cierto sentido, la construcción de sistemas de tiempo real era muchas veces como
una aventura "de vuelo". No se encontraban sorpresas (la mayoría desagradables)
hasta que no se construía el sistema y se "soltaba desde un acantilado". Si el sistema
fallaba debido a una función incorrecta, a un comportamiento inapropiado o a un
rendimiento pobre, se recogían las piezas y se empezaba de nuevo.
Muchos sistemas de la categoría de los reactivos controlan máquinas y/o procesos (p.
ej.: refinerías de petróleo o líneas aéreas comerciales) que han de funcionar con un
grado de fiabilidad extremadamente alto. Si el sistema falla, pueden producirse
pérdidas humanas o económicas importantes. Por esta razón, el panorama descrito por
Graham es lamentable y peligroso.
Hoy en día, se usan herramientas CASE para la modelización y la simulación, con el fin
de eliminar sorpresas en la construcción de sistemas reactivos basados en
computadora. Estas herramientas se aplican durante el proceso de ingeniería del
software, durante la especificación de los papeles del hardware, del software, de las
bases de datos y de la gente. El papel de la herramienta de modelización y de
simulación de sistemas ha sido resumido por i-Logix, Inc., un vendedor de herramientas
de ingeniería del sistema [ILO90]:
En un proyecto, cuando más frecuentemente nos centramos en el entendimiento del
comportamiento de un sistema en su entorno, es durante las fases de diseño, de
implementación y de prueba, mediante un proceso iterativo de prueba y error. El método
Statemate [una herramienta de modelización y simulación] 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 también los aspectos de la
dinámica y del comportamiento del sistema. Luego, se puede probar el modelo con...
herramientas que proporcionan varios mecanismos para inspeccionar y depurar la
especificación y para recuperar la información que contiene. Mediante la prueba del
modelo de especificación, el ingeniero de sistemas puede ver cómo se comportará el
sistema especificado una vez que se implemente. Se pueden plantear preguntas del tipo
"¿qué pasa si...?" seguir guiones específicos, comprobar que se van a producir
determinadas situaciones deseables... y que otras no deseables no se encontrarán. 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 modelización y simulación permiten al ingeniero de sistemas
"conducir la prueba" de una especificación del sistema. Los detalles técnicos y las
técnicas especializadas de modelización que se utilizan para conducir la prueba se
presentan en el Capítulo 15.
pág.: 35 de 41
Pressman, Cap 5
5.6. LA ESPECIFICACION DEL SISTEMA
La especificación del sistema es un documento que sirve como base para la ingeniería
del hardware, la ingeniería del software, la ingeniería de bases de datos y la ingeniería
humana. Describe la función y el rendimiento de un sistema balado en computadora y
las restricciones que gobernarán su desarrollo. La especificación limita cada uno de los
elementos del sistema asignados. Por ejemplo, proporciona al ingeniero de software
una indicación 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
especificación del sistema también describe la información (control y datos) que sirve de
entrada y de salida al sistema.
La tabla 5.4 muestra un esquema recomendado para la especificación del sistema. Sin
embargo, téngase en cuenta que se trata sólo de uno de los muchos esquemas que se
pueden seguir para definir un documento de descripción del sistema. El contenido o el
formato actual puede venir impuesto por algún estándar de la ingeniería del software o
de la ingeniería de sistemas (p. ej.: DoD/STD 2167A) o por las preferencias y gustos
particulares.
5.7. REVISION DE LA ESPECIFICACION DEL SISTEMA
Durante la ingeniería del sistema hay una tendencia natural a pasar por alto la revisión
e ir rápidamente al desarrollo. Los gestores tienden a ponerse cada vez más nerviosos
cuando lo que se hace no es soldar componentes ni escribir código. El personal técnico
quiere pasar a las "tareas creativas de la ingeniería" tan pronto como sea posible. ¡No
se debe ceder ante estas actitudes!
La revisión de la especificación del sistema evalúa la corrección de la definición
contenida en la especificación del sistema. La revisión ha de ser realizada por el
técnico 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 análisis del entorno y del riesgo del desarrollo justifican el sistema y (4)
el desarrollador y el cliente tienen la misma percepción de los objetivos del sistema. La
revisión de la especificación del sistema se realiza en dos partes. Inicialmente se aplica
un punto de vista de gestión. Después se realiza una evaluación técnica de los
elementos y funciones del sistema.
pág.: 36 de 41
Pressman, Cap 5
Tabla 5.4. Esquema de la especificación del sistema
I.
II.
III.
IV.
V.
VI.
Introducción
A. Ambito y propósito del documento
B. Visión general
1. Objetivos
2. Restricciones
Descripción funcional y de datos
A. Arquitectura del sistema
1. Diagrama de contexto de la arquitectura
2. Descripción del DCA
Descripción de los subsistemas
A. Especificación del diagrama de arquitectura para el subsistema n
1. Diagrama de flujo de la arquitectura
2. Narrativa de módulo del sistema
3. Aspecto de rendimiento
4. Restricciones de diseño
5. Asignación de componentes del sistema
B. Diccionario de la arquitectura
C. Diagramas y descripción de la interconexión de la arquitectura
Resultados de la modelización y la simulación del sistema
A. Modelo del sistema utilizado para la simulación
B. Resultados de la simulación
C. Aspectos especiales del rendimiento
Aspectos del proyecto
A. Costes de desarrollo proyectados
B. Agenda proyectada
Apéndices
Las consideraciones claves de la gestión generan las siguientes cuestiones:
 ¿Se ha establecido una necesidad comercial en firme? ¿Tiene sentido la
justificación del sistema?
 ¿Necesita el entorno especificado (o el mercado) el sistema descrito?
 ¿Qué alternativas has se han considerado?
 ¿Cuál es el riesgo de desarrollo de cada elemento del sistema?
 ¿Están 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 análisis. En este momento, lo que hacemos es volver a
examinarlas.
El nivel de detalle considerado durante la etapa técnica de la revisión del sistema varía
de acuerdo con el nivel de detalle considerado durante la tarea de asignación. La
revisión debe cubrir los siguientes aspectos:
pág.: 37 de 41
Pressman, Cap 5
 ¿Se corresponde la complejidad funcional del sistema con el riesgo
desarrollo, el coste y la agenda?
 ¿Está definida la asignación de funciones con suficiente detalle?
 ¿Se han definido con suficiente detalle las interfaces entre los elementos
sistema y el entorno?
 ¿Se han planteado los aspectos de rendimiento, fiabilidad y facilidad
mantenimiento en la especificación?
 ¿Proporciona la especificación del sistema una base suficiente para
siguientes pasos de ingeniería del software y del hardware?
de
del
de
los
Una vez que ha terminado la revisión del sistema, comienzan los caminos paralelos de
ingeniería. Los elementos de hardware, humanos y de base de datos de un sistema se
consideran dentro de sus correspondientes procesos de ingeniería. En el resto de este
libro, seguiremos el camino de la ingeniería del software.
5.8. RESUMEN
La ingeniería de sistemas de computadora es el primer paso en la evolución de un
producto o sistema basado en computadora nuevo. Mediante los pasos que hemos
denominado colectivamente análisis del sistema, el ingeniero de sistemas identifica las
necesidades del usuario, determina la viabilidad técnica y económica, 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 arquitectónico del sistema y se
desarrolla una representación de cada uno de los principales subsistemas. Por último,
la ingeniería de sistemas puede utilizar herramientas CASE para crear un modelo
reactivo del sistema que se pueda utilizar como base para la simulación del
funcionamiento y del comportamiento. La tarea de ingeniería de sistemas culmina con
la creación de la especificación del sistema un documento que es la base de todo el
trabajo de ingeniería que viene a continuación.
La ingeniería de sistemas requiere una comunicación 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é investigación realizar. Si la comunicación se rompe en esta fase, el éxito del
proyecto entero estará en peligro.
REFERENCIAS
[ALL89]
[BLA81]
[DAT86]
[FRI77]
Allman, W. F., Apprentices of Wonder, Bantam, 1989.
Blanchard, B. S., and W. J. Fabrycky, Systems Engineering and Analysis,
Prentice Hall, 1981.
Date, C. J., An Introduction to Data Base Systems, 4th ed., Addison Wesley,
1986.
Fried, L., "Performing Cost Benefit Analysis", Systems Development
pág.: 38 de 41
Pressman, Cap 5
[GEM81]
[GRA69]
[HAR85]
[HAT87]
[IEE89]
[ILO90]
[KIN78]
[RAE9O]
[SC089]
[WAS89]
Management, Auerbarch Publishers, 1977
Gemignani, M., Law and the Computer, CBI Publishing Co., 1981.
Graham, R. M., in Proceedings 1969 NATO Conference on Software
Engineering, 1969.
Harris, T. D., Computer Software Protection, Prentice Halí, 1985.
Hatley, D. J., and I. A. Pirbhai, Strategies for Real Time Systems
Specification, Dorset House, 1987.
Database Engineering, Vol. 7, IEEE Computer Society Press, 1989.
The Statemate Approach to Complex Systems, i-Logix, Inc., 1990.
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.
Raeth, P. G., Expert Systems: A Software Methodology for Modern
Applications, IEEE Computer Society Press, 1990.
Scott, M. D., Computer Law, Wiley, 1989.
Wasserman, P. D., Neural Computing: Theory and Practice, Van Nostrand
Reinhold, 1989.
PROBLEMAS Y PUNTOS A CONSIDERAR
5.1. Encuentre tantos sinónimos 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 jerarquía debe llegar hasta los elementos
más 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 organización 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. Añada al menos cinco cuestiones más a la lista desarrollada para el sistema SCCT
en la Sección 5.2. Aborde el problema con dos asignaciones adicionales para el
SCCT.
5.7. Su profesor le proporcionará una descripción 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 compañeros.
5.8. Intente desarrollar una clasificación jerárquica para el hardware de computadoras.
Identifique cada clase de hardware; proporcione ejemplos de dispositivos reales de
cada clase.
pág.: 39 de 41
Pressman, Cap 5
5.9
Intente desarrollar una clasificación jerárquica 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 ingeniería del hardware y
del software. ¿En qué difieren las fases de estos procesos?
5.11.La ingeniería 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 comprobación de atributos que haya que considerar
cuando se vaya a evaluar la "viabilidad" de un sistema. Discuta la interrelación
entre los atributos e intente aportar un método para clasificarlos de tal forma que
se pueda obtener un “número de viabilidad” cuantitativo.
5.13.
Investigue sobre las técnicas de contabilidad que se usan para el análisis
detallado de coste beneficio de un sistema basado en computadora que requiera
fabricación de hardware y ensamblaje. Intente escribir un conjunto de directrices
tipo de “receta" que pudiese seguir un gestor técnico.
5.14.Desarrolle un análisis de coste beneficio equivalente al que se muestra en las
Tablas 5.2 y 5.3, para sistemas científicos/de ingeniería. Amplíe 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 elección (o
uno asignado por su profesor).
5.16.Escriba una narrativa de módulo de sistema que pudiera encontrarse en la
especificación del diagrama de arquitectura de uno o más de los subsistemas
definidos en los DFAs del Problema 5.15.
5.17.Investigue en la literatura sobre herramientas CASE y escriba un breve artículo
describiendo cómo funcionan las herramientas de modelización y simulación.
Alternativa: recopile información de dos o más vendedores de herramientas
CASE que suministren herramientas de modelización y simulación, y evalúe las
similitudes y las diferencias.
5.18.Basándose en los documentos suministrados por su profesor, desarrolle una
especificación 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 electrónico.
(d) Un sistema de matrícula para la universidad.
(e) Un sistema de análisis de ingeniería.
(f) Un sistema interactivo de reservas.
g) Un sistema de interés local.
Asegúrese de crear los modelos de arquitectura descritos en la Sección 5.4.
5.19. ¿Existen características de un sistema que no se puedan establecer en el
momento de la definición? Describa esas características, si las hay, y explique
por qué su consideración debe ser postergada para más adelante en el proceso
de ingeniería.
5.20. ¿Existen situaciones en las que la especificación formal del sistema pueda ser
abreviada o eliminada por completo? Explique su respuesta.
pág.: 40 de 41
Pressman, Cap 5
OTRAS LECTURAS
Debido a que se trata de un tema interdisciplinario, la ingeniería de sistemas basados
en computadora es una materia difícil 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
ingeniería de sistemas (con un enfoque de ingeniería distinto) y constituyen una valiosa
guía. IEEE Computer Society ha puesto empeño en desarrollar una estructura
educativa para la ingeniería 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 análisis 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 estándares y las directrices para el trabajo de
análisis.
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 análisis
de sistemas tal y como se aplica en el mundo de los sistemas de información. Los
libros contienen casos de estudio suplementarios que ilustran los problemas, los
métodos y las soluciones que se pueden aplicar durante el análisis de sistemas. Se
han publicado muchos otros libros de texto en el área general del análisis y la definición
de sistemas. Entre las incorporaciones más 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 clásicos y
proporcionan un tratamiento excelente de la "concepción de sistemas generales" que
conduce implícitamente a un enfoque general del análisis y del diseño de sistemas. Los
libros más recientes de Weinberg (General Principies of System Design, Dorset House,
1988 y Rethinking Systems Analysis and Design, Dorset House, 1988) continúan en la
tradición de sus anteriores trabajos.
Las series de Auerbach, System Development Management (Auerbach Publishers,
actualizadas cada año), proporcionan un tratamiento excelente de la planificación y la
definición de sistemas de información a gran escala. El enfoque pragmático de
Auerbach será especialmente útil a los profesionales de la industria.
pág.: 41 de 41