Pressman, Cap 5

Pressman, Roger S.; Ingeniera de Software, un enfoque prctico Tercera edicin, 1993 Editorial McGraw-Hill Segunda Parte Anlisis de Requisitos del Sistema y del Software 5 Ingeniera De Sistemas De Computadora

Hace cuatrocientos cincuenta aos, Maquiavelo dijo: "...no hay nada ms difcil de conseguir, ms arriesgado de mantener ni ms inseguro de tener xito, que estar a la cabeza en la introduccin de un nuevo orden de cosas..." Durante el ltimo cuarto del siglo veinte, los sistemas basados en computadora estn introduciendo un nuevo orden de cosas. La ingeniera del software y la ingeniera del hardware entran dentro de la amplia categora que llamaremos ingeniera de sistemas de computadora. Cada una de estas disciplinas representa un intento de establecer un orden en el desarrollo de sistemas basados en computadora. Las tcnicas de ingeniera para el hardware de computadoras provienen del diseo electrnico y han alcanzado un estado de relativa madurez. Las tcnicas de diseo de hardware estn bien establecidas, los mtodos de fabricacin mejoran continuamente y la fiabilidad es ms una expectativa real que una modesta esperanza. Desafortunadamente, el software de las computadoras todava padece la descripcin maquiavlica anteriormente descrita. En los sistemas basados en computadora, el software ha reemplazado al hardware en el sentido de ser el elemento del sistema ms difcil de planificar, con menos posibilidad de xito (en tiempo y en dinero) y ms peligroso de manejar. Mientras los sistemas basados en computadora continan creciendo en nmero, complejidad y aplicaciones, la demanda de software contina sin disminuir.

5.1. SISTEMAS BASADOS EN COMPUTADORA La palabra "sistema" es posiblemente el trmino ms sobreutilizado y del que ms se ha abusado en el lxico tcnico. Hablamos de sistemas polticos y educativos, de sistemas avinicos y de fabricacin, de sistemas bancarios y de ferrocarril. La palabra nos dice poco. Usamos el adjetivo que la describe para comprender el contexto en el que se usa. El diccionario Webster la describe as:
pg.: 1 de 43

Pressman, Cap 5

1. un conjunto u ordenacin de cosas relacionadas de tal manera que forman una unidad o un todo orgnico; 2. un conjunto de hechos, principios, reglas, etc... clasificados y ordenados de tal manera que muestran un plan lgico uniendo las diferentes partes; 3. un mtodo o plan de clasificacin u ordenacin; 4. una forma establecida de hacer algo; un mtodo; un procedimiento...

El diccionario contiene cinco definiciones pero no cita ningn sinnimo. "Sistema" es una palabra especial. Tomando prestada la definicin anterior del diccionario Webster, definimos un sistema basado en computadora como:
Un conjunto u ordenacin de elementos organizados para llevar a cabo algn mtodo, procedimiento o control mediante el procesamiento de informacin.

En la Figura 5.1 se muestran los elementos de un sistema basado en computadora, incluyendo los siguientes: Software. Los programas de computadora, las estructuras de datos y la documentacin asociada, que sirven para realizar el mtodo lgico, procedimiento o control requerido.

Figura 5.1. Elementos del sistema.

Hardware. Los dispositivos electrnicos (p. ej.: UCP, memoria) que proporcionan la capacidad de computacin y los dispositivos electromecnicos (p. ej.: sensores, motores, bombas) que proporcionan las funciones del mundo exterior. Gente. Los individuos que son usuarios y operadores del software y del hardware. Bases de datos. Una coleccin grande y organizada de informacin a la que se accede mediante el software y que es una parte integral del funcionamiento del sistema.
pg.: 2 de 43

Pressman, Cap 5

Documentacin. Los manuales, los impresos y otra informacin descriptiva que explica el uso y/o la operacin del sistema. Procedimientos. Los pasos que definen el uso especfico de cada elemento del sistema o el contexto procedimiento en que reside el sistema. Los elementos se combinan de muchas formas para transformar la informacin. Por ejemplo, un robot transforma un archivo de rdenes, que contiene instrucciones concretas, en un conjunto de seales de control que producen alguna accin fsica concreta. Una caracterstica compleja de los sistemas basados en computadoras es que los elementos que componen un sistema pueden tambin representar un macroelemento de un sistema todava mayor. Un macroelemento es un sistema basado en computadora que forma parte de un sistema basado en una computadora mayor. Como ejemplo, consideremos un sistema de automatizacin de una fbrica, que es, esencialmente, la jerarqua de sistemas que se muestra en la Figura 5.2. En el nivel ms bajo de la jerarqua tenemos mquinas de control numrico (CN), robots y dispositivos de entrada de datos. Cada uno es por s mismo un sistema basado en computadora. Los elementos de las mquinas de CN incluyen hardware electrnico y electromecnico (p. ej.: procesador y memoria, motores, sensores); software (comunicaciones, control de las mquinas, interpolacin); gente (operadores de las mquinas); una base de datos (el programa de CN almacenado); documentacin y procedimientos. Se podra aplicar una descomposicin similar a los robots y a los dispositivos de entrada de datos. Cada uno es un sistema basado en computadora. En el siguiente nivel de la jerarqua (Figura 5.2) se define una clula de fabricacin. La clula de fabricacin es un sistema basado en computadora que integra elementos propios (p. ej.: computadoras, fijaciones) y los macroelementos de mquinas de control numrico, robots y dispositivos de entrada de datos. Resumiendo, la clula de fabricacin y sus macroelementos estn compuestos por elementos del sistema con las siguientes etiquetas genricas: software, hardware, gente, base de datos, procedimientos y documentacin. En algunos casos, los macroelementos pueden compartir un elemento genrico. Por ejemplo, el robot y la mquina de CN pueden ser manejados por un slo operador (el elemento gente). En otros casos los elementos genricos son exclusivos de un sistema. El papel del ingeniero de sistemas (o analista de sistemas) es el de definir los elementos de un sistema basado en computadora especfico dentro del contexto de toda la jerarqua de sistemas (macroelementos). En las siguientes secciones examinamos las tareas que constituyen la ingeniera de sistemas de computadora.

pg.: 3 de 43

Pressman, Cap 5

Figura 5.2. Un sistema de sistemas.

5.2 INGENIERIA DE SISTEMAS DE COMPUTADORA La ingeniera de sistemas de computadora 1 es una actividad de resolucin de problemas. Las funciones que se desean para el sistema son descubiertas, analizadas y asignadas a elementos individuales del sistema. El ingeniero de sistemas de computadora (tambin llamado analista de sistemas en algunos mbitos de informacin) parte de los objetivos y de las restricciones definidas por el usuario y desarrolla una representacin de la funcin, del rendimiento, de las interfaces, de las restricciones de diseo y de la estructura de la informacin, todo ello pudiendo ser asociado a cada uno de los elementos genricos del sistema descritos en la seccin anterior. La gnesis de la mayora de los nuevos sistemas comienza con un concepto ms bien borroso de la funcin deseada. De esa manera, el ingeniero de sistemas debe delimitar el sistema, identificando el mbito del funcionamiento y el rendimiento deseados. Por ejemplo, no es suficiente decir que el software de control para el robot del sistema de automatizacin de fabricacin "ha de responder rpidamente si un compartimento de piezas est vaco". El ingeniero de sistemas debe definir:
1

No se deben confundir los trminos ingeniera de sistemas de computadora e ingeniera de computadoras. La ingeniera de computadoras se centra exclusivamente en el diseo y la implementacin del hardware de computadora y su software de sistema asociado, mientras que la ingeniera de sistemas de computadora se aplica a todos los productos y sistemas que contienen computadoras.
pg.: 4 de 43

Pressman, Cap 5

(1) lo que supone un compartimento vaco para el robot; (2) los lmites precisos de tiempo (en segundos) en los que se espera la respuesta del software; (3) qu formato debe tener la respuesta.

Una vez que la funcin, el rendimiento, las restricciones y las interfaces estn delimitadas, el ingeniero de sistemas procede a realizar la tarea denominada asignacin. Durante la asignacin, las funciones son asignadas a uno o ms elementos genricos del sistema (esto es, software, hardware, gente, etc.). A menudo se proponen y evalan varias asignaciones.
Para ilustrar el proceso de asignacin, consideremos otro macro elemento del sistema de automatizacin de fabricacin el sistema de clasificacin en cinta transportadora (SCCT) que se present en el Captulo 3. Al ingeniero de sistemas se le presenta el siguiente conjunto (un poco borroso) de objetivos para el SCCT:
El SCCT debe ser desarrollado de tal manera que las cajas que se mueven a lo largo de la cinta sean identificadas y clasificadas en uno de los seis compartimentos al final de la cinta. Las cajas pasarn por una estacin de clasificacin donde sern identificadas. Basndose en un nmero de identificacin, impreso en un lado de la caja (incluyendo un cdigo de barras equivalente), las cajas sern dirigidas a los compartimentos correspondientes. Las cajas pasan en un orden aleatorio y espaciadas uniformemente. La cinta se mueve despacio.

En la Figura 3.2 se muestra esquemticamente el sistema SCCT. Antes de continuar, hagamos una lista de preguntas que haramos si fusemos el ingeniero de sistemas. Entre las muchas preguntas que se deberan plantear y responder estn las siguientes: 1. Cuntos nmeros de identificacin diferentes van a ser procesados y cul es su forma? 2. Cul es la velocidad de la lnea de transporte en metros/segundo y cul es la distancia entre cajas en metros? 3. A qu distancia est la estacin de clasificacin de los compartimentos? 4. A qu distancia estn los compartimentos entre s? 5. Qu debe ocurrir si una caja no tiene el nmero de identificacin o tiene un nmero incorrecto? 6. Qu ocurre cuando se llena un compartimento? 7. Hay que mandar informacin sobre el destino de la caja y el contenido de los compartimentos a algn otro lugar del sistema de automatizacin de la fbrica? Se requiere adquisicin de datos en tiempo real? 8. Qu frecuencia de error/fallo es aceptable? 9. Qu partes del sistema de cinta transportadora existen actualmente y son operativas? 10. Qu restricciones de tiempo y presupuesto nos vienen impuestas?

pg.: 5 de 43

Pressman, Cap 5

Se puede observar que las cuestiones anteriores se centran en el funcionamiento, rendimiento, flujo de informacin y contenido. El ingeniero de sistemas no pregunta al cliente cmo se va a realizar la tarea; en vez de eso, lo que pregunta es qu se necesita. Asumiendo que las respuestas son razonables, el ingeniero de sistemas desarrolla un nmero de asignaciones alternativas. Se puede observar que el funcionamiento y rendimiento estn asociados a diferentes elementos genricos del sistema en cada asignacin. Asignacin 1 Se ensea a un operador a clasificar y se le sita en la estacin de clasificacin. El o ella lee la caja y la sita en el compartimento adecuado. La asignacin 1 representa una solucin manual (a pesar de todo efectiva) al problema del SCCT. El elemento primario del sistema es la gente (el operador que clasifica). La persona realiza todas las funciones de clasificacin. Puede requerirse alguna documentacin (en forma de tabla que relacione el nmero de identificacin con el compartimento adecuado y una descripcin de procedimientos para el entrenamiento del operador). As, esta asignacin utiliza slo los elementos gente y documentacin. Asignacin 2 Se colocan un lector de cdigo de barras y un controlador en la estacin de clasificacin. La salida del lector de barras pasa a un controlador programable que controla un mecanismo de separacin. El separador dirige la caja hacia el compartimento apropiado. Para la asignacin 2, se usan el hardware (lector de cdigos de barras, control programable, mecanismo de separacin, etc.); el software (para el lector de cdigos de barras y el controlador programable) y la base de datos (una tabla donde se relaciona el identificador de las cajas con los compartimentos) para conseguir una solucin de automatizacin total. Cualquiera de estos elementos del sistema puede tener sus correspondientes manuales y otra documentacin, aadiendo otro elemento genrico del sistema. Asignacin 3 Se colocan un lector de cdigo de barras y un controlador en la estacin de clasificacin. La salida del lector de cdigos de barras pasa a un brazo de robot que coge la caja y la coloca en el compartimento apropiado. La asignacin 3 hace uso de elementos genricos del sistema y de un macroelemento, el robot. Al igual que la asignacin 2, esta asignacin utiliza hardware, software, una base de datos y documentacin como elementos genricos. El robot es un macro elemento del SCCT y por s mismo contiene un conjunto de elementos genricos de sistema. Examinando las tres asignaciones alternativas para el SCCT, debera resultar obvio que la misma funcin puede ser asignada a diferentes elementos del sistema. Para elegir la asignacin ms efectiva, se debe aplicar un conjunto de criterios de evaluacin a cada alternativa.

pg.: 6 de 43

Pressman, Cap 5

Los siguientes criterios de evaluacin controlan la seleccin de una configuracin del sistema basndose en una asignacin especfica de funcionalidad y rendimiento a elementos genricos del sistema:
Consideraciones del proyecto. Puede ser construida la configuracin dentro de los lmites preestablecidos de coste y tiempo? Cul es el riesgo asociado a las estimaciones de tiempo y coste? Consideraciones comerciales. Representa la configuracin la solucin ms beneficiosa? Puede ser lanzada con xito? Compensarn los beneficios a los riesgos del desarrollo? Anlisis tcnico. Existe tecnologa para desarrollar todos los elementos del sistema? Estn aseguradas la funcionalidad y el rendimiento? Podr mantenerse correctamente la configuracin? Existen recursos tcnicos? Cul es el riesgo asociado con la tecnologa? Evaluacin de la fabricacin. Hay disponibles instalaciones y equipos de fabricacin? Hay escasez de los componentes necesarios? Puede llevarse a cabo adecuadamente una garanta de calidad? Aspectos humanos. Existe personal cualificado disponible para el desarrollo y la fabricacin? Existen problemas polticos? Comprende el cliente lo que va a hacer el sistema? Interfaces con el entorno. Funciona correctamente la interfaz de la configuracin propuesta con el entorno externo del sistema? Se manejan inteligentemente las comunicaciones mquina - mquina y hombre - mquina? Consideraciones legales. Introduce esta configuracin un riesgo de responsabilidad indebido? Pueden ser protegidos adecuadamente los aspectos de propiedad? Existe una infraccin potencial?

Examinaremos algunos de estos aspectos con ms detalle ms adelante en este captulo. Es importante hacer notar que el ingeniero de sistemas debe considerar tambin soluciones estndar al problema del cliente. Existe un sistema equivalente? Pueden ser adquiridas las partes ms importantes del producto a un tercero? la aplicacin de criterios de evaluacin supone la seleccin de la configuracin de un sistema especfico y la especificacin del funcionamiento y del rendimiento asignados al hardware, al software (y al firmware - microinstrucciones), a la gente, a las bases de datos, a la documentacin y a los procedimientos. Esencialmente, lo que se hace es asignar a cada elemento del sistema un mbito de funcionamiento y de rendimiento. La ingeniera del hardware, la ingeniera del software, la ingeniera humana y la ingeniera de bases de datos estn para refinar el mbito y producir un elemento del sistema capaz de funcionar que pueda ser integrado
pg.: 7 de 43

Pressman, Cap 5

adecuadamente con otros elementos del sistema.

5.2.1. Hardware e ingeniera del hardware El ingeniero de sistemas de computadora selecciona alguna combinacin de componentes de hardware que constituyen un elemento del sistema basado en computadora. La seleccin del hardware, aunque no es una tarea sencilla, que se facilitada por una serie de caractersticas: (1) los componentes estn empaquetados como bloques constitutivos individuales; (2) las interfaces entre componentes estn estandarizadas; (3) estn disponibles numerosas alternativas preparadas"; (4) el rendimiento, coste y disponibilidad son relativamente fciles de determinar. Una configuracin del hardware evoluciona de una jerarqua de "bloques constitutivos". Los componentes discretos (p. ej.: circuitos integrados y componentes electrnicos tales como resistencias, condensadores, etc.) se ensamblan en una tarjeta de circuito impreso (CI) que realiza un conjunto especfico de operaciones. Las tarjetas se interconectan con un bus (un camino de informacin y de control) para formar componentes del sistema (p. ej.: una tarjeta de la computadora) que a su vez se integran en un subsistema de hardware o elemento del sistema. Puesto que la integracin a muy gran escala ya es comn, funciones que antes estaban disponibles en un conjunto de tarjetas de circuito impreso con docenas de circuitos integrados, ahora estn disponibles en un chip. La ingeniera del hardware para computadoras digitales surgi de los precedentes establecidos en dcadas de diseo electrnico.

El proceso de la ingenieria del hardware puede verse en tres fases:

planificacin y especificacin; implementacin del diseo y del prototipo; fabricacin, distribucin y mantenimiento.

Las fases se ilustran en la Figura 5.3 a, b y c. Una vez que se ha definido la ingeniera del sistema (anlisis y definicin sistema), se asignan funciones al hardware. La primera fase de la ingeniera hardware (Figura 5.3 a) comprende la planificacin del desarrollo y el anlisis de los requisitos del hardware. La planificacin del desarrollo se orienta a establecer el alcance del esfuerzo en
pg.: 8 de 43

Pressman, Cap 5

hardware. Para esto nos hacemos las siguientes preguntas: Qu clase de hardware se adapta mejor a las funciones especificadas? Qu hardware se puede comprar? cules son los proveedores, la disponibilidad y el coste? Qu tipos de interfaces se requieren? Qu tenemos que disear y construir? cules son los problemas potenciales y los recursos requeridos? A partir de estas y otras cuestiones, se deben establecer los costes preliminares y los plazos de realizacin del sistema de hardware. Estas estimaciones son revisadas por los responsables y el personal tcnico apropiado para ser modificadas si fuese necesario. A continuacin debemos establecer una gua de acciones" para el diseo del hardware y su implementacin. El anlisis de los requisitos del hardware se orienta a especificar requisitos funcionales, de rendimiento y de interfaz precisos para todos los componentes del elemento de hardware. Adems, deben establecerse las restricciones del diseo (por ejemplo, tamao, entorno) y los criterios de prueba. Frecuentemente se realiza una especificacin del hardware. En esta etapa hay que tomar en consideracin muy especialmente las revisiones y las modificaciones. La popular imagen de la ingeniera en "mangas de camisa" est caracterizada en la segunda fase (Figura 5.3 b). Se analizan los requisitos y se disea una configuracin preliminar del hardware. Las revisiones tcnicas se suceden a medida que el diseo evoluciona hacia esquemas de ingeniera detallados (especificaciones de diseo). Hoy en da, el anlisis y el diseo se gestionan mediante herramientas de ingeniera asistida por computadora y diseo asistido por computadora (del ingls, CAE/CAD). Se compran componentes ya hechos, se construyen los componentes a medida y se ensambla un prototipo. Se prueba el prototipo para asegurar que cumple todos los requisitos.

pg.: 9 de 43

Pressman, Cap 5

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

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

Pressman, Cap 5

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

5.2.2. Software e ingeniera del software Las caractersticas del software y de la ingeniera del software ya se han discutido en detalle en el Captulo 1. En esta seccin vamos a resumir el estudio anterior dentro del contexto de la ingeniera de sistemas de computadora. Durante la ingeniera del sistema se asigna la funcin y el rendimiento al software. En algunos casos, la funcin es simplemente la implementacin de un procedimiento secuencial de manipulacin de datos. El rendimiento no queda explcitamente definido. En otros casos, la funcin es la coordinacin y control internos de otros programas concurrentes y el rendimiento est definido de forma explcita en trminos de tiempo de espera y de respuesta. Para conseguir la funcin y el rendimiento, el ingeniero de software debe construir adquirir una serie de componentes de software. A diferencia del hardware, los componentes de software estn muy poco estandarizados 2. En la mayora de los casos, el ingeniero de software crea componentes a medida para satisfacer los requisitos asignados al elemento de software que se va a desarrollar. El elemento de software de un sistema basado en computadora est compuesto por programas, datos y documentacin que constituyen el software de la aplicacin y el software del sistema. El software de la aplicacin implementa los procedimientos requeridos para realizar las funciones de procesamiento de la informacin. El software del sistema implementa funciones de control que permiten al software de la aplicacin comunicarse con otros diversos elementos de software. Las reas genricas de aplicacin del software ya han sido descritas en la Seccin 1.2.3. En esta seccin consideramos la aplicacin del software en el contexto ms amplio de los sistemas basados en computadora. Independientemente de su rea de aplicacin, un sistema basado en computadora puede ser representado mediante un modelo de entrada proceso - salida (EPS). El elemento de software juega un papel en cada aspecto del modelo. El software se usa para adquirir informacin que puede ser suministrada por alguna fuente externa o por otro elemento del sistema (incluyendo macroelementos). Cuando un sistema basado en computadora requiere una interfaz interactiva entre hombre y
2

El uso de las tcnicas orientadas a los objetos (captulos 8 y 12) puede llevarnos a disponer de una amplia serie de CIs de software - bloques de construccin de software reutilizables.
pg.: 11 de 43

Pressman, Cap 5

mquina, el software implementa la "conversacin" de E/S. En el software se implementan los mecanismos de peticin y de entrada de datos; con el software se generan las pantallas y los grficos y, mediante el software, se lleva a cabo la lgica que conduce al usuario a travs de la secuencia de pasos interactivos. Cuando se adquieren los datos desde un dispositivo, el software, en forma de controlador, acomoda las caractersticas especiales del hardware. Por ltimo, el software tambin se usa para establecer interfaces con las bases de datos, permitiendo a un programa acceder a fuentes de datos pre-existentes. El software implementa los algoritmos de procesamiento requeridos para realizar las funciones del sistema. En general, un algoritmo de procesamiento transforma datos de entrada y produce informacin o control como salida para otro elemento del sistema o macroelementos. Hoy en da, el tipo ms comn de procesamiento es el procedimiento numrico o no numrico en el que todos los pasos, bucles y condiciones estn predefinidos. Sin embargo, en algunos sistemas basados en computadora se estn introduciendo nuevas categoras de algoritmos de procesamiento, como el software de sistemas expertos y las redes neuronales artificiales. A diferencia de los algoritmos convencionales, los sistemas expertos [RAE9O] utilizan hechos especficos y reglas para inferir, permitiendo al software mostrar habilidades de diagnosis parecidas a las humanas, en un mbito de problemas limitado. A diferencia dei software de sistemas expertos, una red neuronal artificial [WAS89] imita las funciones de las neuronas del cerebro humano y han mostrado buenas expectativas en el reconocimiento de patrones y el aprendizaje automtico. Para que un sistema basado en computadora sea de uso prctico, el software debe proporcionar informacin o control a otro elemento del sistema o a una fuente externa. Para producir la informacin de salida, el software debe dar un formato a los datos que resulte apropiado para el medio de salida y saber cmo comunicarse con el dispositivo de salida (p. ej.: impresora, disco ptico, dispositivo de visualizacin de una estacin de trabajo). La ingeniera del software es una disciplina para el desarrollo de software de alta calidad para sistemas basados en computadora. En el Captulo 1 tratamos la ingeniera del software con detalle e identificamos cuatro paradigmas para la ingeniera del software, el ciclo de vida clsico, la creacin de prototipos, el modelo en espiral y las tcnicas de cuarta generacin. Cada uno es distinto de los otros, pero todos contemplan tres grandes fases. Examinaremos estas fases en base al flujo de sucesos que se producen, de forma anloga a como lo hicimos con el proceso de ingeniera del hardware. Las Figuras 5.4 a, b y c ilustran los pasos genricos del proceso de ingeniera del software. Las distintas partes de la Figura ilustran los pasos que se deben llevar a cabo y las distintas representaciones del software que se derivan segn se evoluciona del concepto a la realizacin. Fase de definicin. La fase de definicin de la ingeniera del software, representada en la Figura 5.4a, comienza con la etapa de planificacin del software. Durante esta etapa se desarrolla una descripcin bien delimitada del mbito del esfuerzo de software; se lleva a cabo un anlisis del riesgo; se definen los recursos necesarios para
pg.: 12 de 43

Pressman, Cap 5

desarrollar el software; se establecen las estimaciones de tiempos y costes. El propsito de la etapa de planificacin del software es proporcionar una indicacin preliminar de la viabilidad del proyecto de acuerdo con el coste y con la agenda que se hayan establecido. La gestin del proyecto realiza y revisa un plan del proyecto de software. El siguiente paso en la fase de definicin es el anlisis y la definicin de los requisitos del software. En este paso se define en detalle el elemento del sistema asignado al software. Los requisitos se analizan y se definen de una de dos maneras. Se puede hacer un anlisis formal del mbito de informacin para establecer modelos del flujo y la estructura de la informacin. Luego, se amplan esos modelos para convertirlos en una especificacin del software. Alternativamente, se puede construir un prototipo del software, que ser evaluado por el cliente para intentar consolidar los requisitos. Los requisitos de rendimiento y las limitaciones de recursos se traducen en caractersticas para el diseo del software. El anlisis global del elemento de software define los criterios de validacin que se utilizarn para demostrar que se han podido conseguir los requisitos. El anlisis y definicin de los requisitos del software es un esfuerzo conjunto llevado a cabo por el desarrollador del software y el cliente. La especificacin de requisitos del software es el documento distribuible que se produce como resultado de esta etapa. La fase de definicin culmina con una revisin tcnica de la especificacin de requisitos del software (o, en lugar de la especificacin, del prototipo del software) realizada por el desarrollador y el cliente. Una vez que se han definido los requisitos, se vuelve a revisar el plan del software con el fin de comprobar que sigue siendo correcto. La informacin no cubierta durante el anlisis de requisitos puede influir en las estimaciones hechas durante la planificacin. Los elementos distribuibles desarrollados durante la fase de definicin constituyen la base de partida para la segunda fase del proceso de desarrollo de software. Fase de desarrollo. La fase de desarrollo (Figura 5.4b) traduce un conjunto de requisitos en el elemento operativo del sistema que llamamos software. En las primeras etapas del desarrollo, el ingeniero de hardware no utiliza un soldador. El ingeniero de software no pasa a utilizar un compilador. Primero se debe realizar el diseo. El primer paso de la fase de desarrollo se centra en el diseo. El proceso de diseo del software comienza con una descripcin del diseo arquitectnico y de datos. Es decir, se desarrolla una estructura modular, se definen las interfaces y se establece la estructura de los datos. Se siguen criterios de diseo que aseguren la calidad. Se revisa el paso preliminar de diseo para garantizar la completitud y el seguimiento de los requisitos del software. Se produce un primer borrador de la especificacin del diseo3, convirtindose en una parte de la configuracin del software.

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

Pressman, Cap 5

Figura 5.4. Ingeniera del software (a) Fase de definicin; (b) Fase de desarrollo; (c) Fase de verificacin, lanzamiento y mantenimiento.
A continuacin, se consideran los aspectos procedimentales de cada componente modular del diseo del software. Cada descripcin procedimental detallada se aade a
pg.: 14 de 43

Pressman, Cap 5

la especificacin del diseo, una vez revisada. Una vez terminado el diseo, se lleva a cabo la codificacin - la generacin de un programa que use un lenguaje de programacin apropiado o una herramienta CASE. La metodologa de la ingeniera del software contempla la codificacin como la consecuencia de un buen diseo. En cuanto al cdigo, se revisa su estilo y su claridad, y se comprueba que haya una correspondencia directa con la descripcin detallada del diseo. El listado en lenguaje fuente de cada componente modular constituye el documento de configuracin de la etapa de codificacin. Fase de verificacin, lanzamiento y mantenimiento. Durante la ltima fase del proceso de ingeniera del software (Figura 5.4c), el ingeniero de software prueba el software para encontrar el mayor nmero posible de errores antes de que sea puesto en circulacin, lo prepara para su lanzamiento y lo mantiene a lo largo de toda su vida til. Despus de haber generado el cdigo fuente, se lleva a cabo una serie de actividades de verificacin y validacin. Las pruebas de unidad intentan verificar el rendimiento funcional de cada componente modular individual del software. La prueba de integracin constituye un medio de construccin de la arquitectura del software y de prueba de su funcionamiento y de sus interfaces. La prueba de validacin comprueba que se han conseguido todos los requisitos. Tras cada uno de estos pasos de prueba, puede que haya de realizarse una depuracin - diagnstico y correccin de defectos. Para los pasos de prueba, se puede desarrollar un plan y procedimiento de prueba. Siempre se realiza una revisin de la documentacin, de los casos de prueba y de los resultados de las pruebas. Una vez terminada la prueba del software, ste est casi preparado para ser entregado a los usuarios finales. Sin embargo, antes de la entrega se lleva a cabo una serie de actividades de garanta de calidad (GC) para asegurar que se han generado y catalogado los registros y los documentos internos adecuados, que se ha desarrollado una documentacin de alta calidad para el usuario y que se han establecido los mecanismos apropiados de control de configuraciones. Entonces, el software ya puede ser distribuido a los usuarios finales. Tan pronto como se entregue el software a los usuarios finales, el trabajo del ingeniero del software cambia. En ese momento, el enfoque cambia de la construccin al mantenimiento - correccin de errores, adaptacin al entorno y mejora de la funcin. El reconocimiento de este hecho es el primer paso hacia una disminucin del impacto de una tarea que consume entre el 50 y el 70 por 100 del presupuesto de muchas grandes empresas de software. Las tareas asociadas con el mantenimiento del software dependen del tipo de mantenimiento a realizar. En todos los casos, la modificacin del software no slo afecta al cdigo, sino a la configuracin entera (es decir, todos los documentos, datos y programas desarrollados en las fases de planificacin y desarrollo).

pg.: 15 de 43

Pressman, Cap 5

5.2.3. Factores humanos e ingeniera humana Un sistema basado en computadora casi siempre tiene un elemento humano. Puede que una persona interacte directamente con el hardware y con el software, manteniendo un dilogo que dirija el funcionamiento del sistema; en cualquier caso, la responsable del desarrollo y del mantenimiento del sistema es la gente. Nuestra percepcin del elemento humano de los sistemas basados en computadora ha cambiado en los ltimos aos. Los primeros sistemas basados en computadora forzaban al usuario a comunicarse de una forma que fuera fcil de implementar en hardware y en software (si bien no siempre fuera fcil la comunicacin en el contexto humano). Hoy, la expresin "amigable con el usuario" tiene un nuevo significado. La ingeniera humana para los sistemas basados en computadora es considerada como un paso importante del desarrollo de sistemas. Cuando la gente interacta con otra gente, un conjunto de reglas, esperas y respuestas, culturalmente definidas, permiten que la interaccin se realice suavemente. Desgraciadamente, los convenios existentes para la interaccin entre personas, no estn presentes cuando lo que se pretende es una interaccin hombre maquina (IHM). Antes de que el ingeniero de sistemas pueda asignar una funcin al elemento humano, se debe especificar la interaccin que es necesaria para poder realizar la funcin. Para hacerlo, se deben entender los "componentes" del elemento humano. Entre los muchos componentes que constituyen el elemento humano se encuentran: la memoria humana y la representacin del conocimiento, el pensamiento y el razonamiento, la percepcin visual y la construccin del dilogo humano. La ingeniera humana es una actividad multidisciplinaria que aplica un conocimiento derivado de la psicologa para especificar y disear IHM de alta calidad. El proceso de la ingeniera humana comprende los siguientes pasos: Anlisis de actividad. Cada actividad asignada a un elemento humano se evala en el contexto de la interaccin requerida con otros elementos. Cada actividad se subdivide en tareas que son analizadas en etapas posteriores. Anlisis y diseo semntico. Se define el significado preciso de cada accin requerida del usuario y de cada accin producida por la mquina. Se establece el diseo de un "dilogo" que comunique adecuadamente la semntica. Diseo lxico y sintctico. Se identifica y representa la forma especfica de las acciones y las rdenes. Despus, se disea la implementacin en software y en hardware de cada accin u orden. Diseo del entorno de usuario. El hardware, software y otros elementos del sistema se combinan para formar un entorno de usuario. El entorno puede incluir facilidades fsicas (brillo, utilizacin del espacio, etc.), adems de la propia IHM. Creacin de prototipos. Es difcil, si no imposible, especificar formalmente una
pg.: 16 de 43

Pressman, Cap 5

IHM sin usar un prototipo. La creacin de prototipos permite evaluar la IHM desde una perspectiva humana, con una participacin activa en lugar de una evaluacin pasiva. La creacin de prototipos supone una evaluacin y una aplicacin iterativa de todos los pasos de ingeniera humana anteriores. En el Captulo 14 se incluye un tratamiento ms detallado de los factores humanos y de la ingeniera humana (aplicada al diseo de interfaces de usuario). 5.2.4. Bases de datos e ingeniera de bases de datos No todos los sistemas basados en computadora hacen uso de una base de datos, pero para aquellos que s lo hacen, ese almacn de informacin a menudo es crucial para el funcionamiento general del sistema. La ingeniera de bases de datos (trmino relativamente nuevo que comprende anlisis, diseo e implementacin de bases de datos) es una disciplina tcnica que se aplica una vez que se ha definido el mbito de la informacin. Por ello, el papel del ingeniero de sistemas es el de definir la informacin que va a contener la base de datos, los tipos de peticiones que se podrn procesar, la manera en que se acceder a los datos y la capacidad de la base de datos. Aunque la ingeniera de bases de datos es un tema que requiere un estudio en profundidad (vase [DAT86], IEEE89]), el anlisis y el diseo de los datos son actividades fundamentales de la ingeniera del software, independientemente de la presencia o no de una base de datos formal. Estos temas de la ingeniera de bases de datos, llamados colectivamente diseo de datos, se estudian en los Captulos 8, 9 y 10.

5.3. ANALISIS DEL SISTEMA El anlisis del sistema es una actividad que engloba la mayora de las tareas que hemos llamado colectivamente ingeniera de sistemas basados en computadora. Algunas veces se incurre en confusin porque el trmino se usa a menudo en un contexto que alude slo a las actividades de anlisis de los requisitos del software (vanse los Captulos 6 al 9). Para el propsito de este estudio, el anlisis del sistema se centra en todos los elementos del sistema - no slo en el software. El anlisis del sistema se realiza teniendo presentes los siguientes objetivos: (1) identificar las necesidades del cliente; (2) evaluar la viabilidad del sistema; (3) realizar un anlisis tcnico y econmico; (4) asignar funciones al software, al hardware, a la gente, a la base de datos y a otros elementos del sistema; (5) establecer restricciones de coste y tiempo; (6) crear una definicin del sistema que sea la base para todo el trabajo posterior de ingeniera. Para alcanzar con xito esos objetivos, se requiere experiencia, tanto en hardware como en software (as como en ingeniera humana y en bases de datos). Aunque la mayora de los profesionales de la industria reconocen que el tiempo y el esfuerzo
pg.: 17 de 43

Pressman, Cap 5

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

5.3.1 Identificacin de las necesidades El primer paso del proceso de anlisis del sistema implica la identificacin de las necesidades. El analista (ingeniero de sistemas) se entrevista con el cliente o su representante. El cliente puede ser un representante de una compaa externa, del departamento de marketing de la compaa del analista (cuando se est definiendo un producto) o de otro departamento tcnico (cuando se va a desarrollar un sistema interno). La identificacin de las necesidades es el punto de partida en la evolucin de un sistema basado en computadora. La Figura 5.5 muestra las entradas que se le suministran al analista como parte de este paso. Para empezar, el analista da asistencia al cliente definiendo los objetivos del sistema (producto): la informacin que se va a obtener, la informacin que se va a suministrar, las funciones y el rendimiento requerido. El analista se asegura de distinguir entre lo que "necesita" el cliente (elementos crticos para la realizacin) y lo que el cliente "quiere" (elementos deseables pero no esenciales). Una vez que se han identificado todos los objetivos, el analista pasa a una evaluacin de la informacin suplementaria: existe la tecnologa necesaria para construir el sistema? qu recursos de fabricacin y de desarrollo especiales se requerirn? qu lmites se han impuesto a los costes y a la agenda? Si el nuevo sistema es un producto que va a ser desarrollado para venderlo a muchos clientes, tambin se hacen las
pg.: 18 de 43

Pressman, Cap 5

siguientes preguntas: cul es el mercado potencial para el producto? cmo se compara este producto con los de la competencia? qu lugar ocupa este producto dentro de la lnea global de la compaa? La informacin recogida durante la etapa de identificacin de las necesidades se especifica en un documento de conceptos del sistema. A veces, es el cliente el que prepara un documento de conceptos inicial antes de reunirse con el analista. Invariablemente, los resultados de la comunicacin analista - cliente producen modificaciones en el documento.

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

Figura 5.5. Informacin requerida por el analista.

El anlisis de viabilidad y el anlisis del riesgo (Captulo 4) estn relacionados de varias maneras. Si el riesgo del proyecto es grande (por cualquiera de las razones vistas en el Captulo 4), se reduce la posibilidad de producir software de calidad. Sin embargo, durante la ingeniera del sistema centramos nuestra atencin en cuatro reas de inters bsico: Viabilidad econmica. Una evaluacin del coste de desarrollo frente al beneficio final producido por el sistema desarrollado. Viabilidad tcnica. Un estudio de la funcionalidad, el rendimiento y las restricciones que pueden afectar a la posibilidad de realizacin de un sistema aceptable.

pg.: 19 de 43

Pressman, Cap 5

Viabilidad legal. Una determinacin de cualquier infraccin, violacin o ilegalidad que pudiera resultar del desarrollo del sistema. Alternativas. Una evaluacin de los enfoques alternativos para el desarrollo del sistema No ser necesario llevar a cabo un estudio de viabilidad para sistemas en los que la justificacin econmica es obvia, el riesgo tcnico es bajo, se esperan pocos problemas legales y no existe una alternativa razonable. Sin embargo, cuando no se da alguna de las anteriores condiciones, debe realizarse el estudio. La justificacin econmica es normalmente la principal consideracin para la mayora de los sistemas (excepciones notables son los sistemas de defensa nacional, los sistemas impuestos por la ley y las aplicaciones de alta tecnologa, como el programa espacial). La justificacin econmica comprende un amplio rango de aspectos, entre los que se encuentran el anlisis de coste - beneficio (tratado en la siguiente seccin), las estrategias de ingresos a largo plazo, el impacto en otros productos o en centros de explotacin, el coste de los recursos que se necesitan para el desarrollo y el crecimiento potencial del mercado. La viabilidad tcnica es frecuentemente el rea ms difcil de evaluar en esta etapa del proceso de desarrollo del sistema. Debido a que los objetivos, las funciones y el rendimiento son de alguna manera confusos, cualquier cosa puede parecer posible si se hacen las consideraciones adecuadas. Es esencial que el proceso de anlisis y de definicin se realice en paralelo con el anlisis de viabilidad tcnica. De esta forma, se pueden juzgar las especificaciones concretas segn se van determinando. Las consideraciones que van asociadas normalmente a la viabilidad tcnica son: Riesgo del desarrollo. Puede el elemento del sistema ser diseado de tal forma que las funciones y el rendimiento necesarios se consigan dentro de las restricciones determinadas en el anlisis? Disponibilidad de recursos. Hay personal cualificado para desarrollar el elemento del sistema en cuestin? Estn disponibles para el sistema otros recursos necesarios (de hardware y de software)? Tecnologa. Ha progresado la tecnologa relevante lo suficiente como para poder soportar el sistema? Los desarrolladores de los sistemas basados en computadora son optimistas por naturaleza. (Quin ms tiene el suficiente coraje para intentar hacer aquello a lo que nosotros frecuentemente nos comprometemos sin pensarlo mucho?) Sin embargo, durante una evaluacin de viabilidad tcnica debera prevalecer una actitud cnica, si no pesimista. Las equivocaciones en esta etapa pueden ser desastrosas. La viabilidad legal comprende un amplio rango de aspectos que incluyen los contratos, la responsabilidad, las infracciones y un millar de otros detalles frecuentemente desconocidos para el personal tcnico. Un estudio de los aspectos legales del software
pg.: 20 de 43

Pressman, Cap 5

va ms all del alcance de este libro. El lector interesado puede acudir a Gemignani [GEM81], Harris [HAR85] o Scott [SC089]. El grado en el que se consideran las alternativas muchas veces est limitado por restricciones de tiempo y de dinero; sin embargo, no se debera descartar cualquier alternativa legtima, aunque no tenga quien "la financie". El estudio de viabilidad puede documentarse en un informe separado de los otros documentos importantes de gestin e incluirse como apndice en la especificacin del sistema. Aunque el formato del informe de viabilidad puede variar, el esquema de la tabla 5.1 cubre la mayora de los aspectos importantes. Tabla 5.1. Esquema del estudio de viabilidad I. Introduccin A. Declaracin del problema B. Entorno de implementacin C. Restricciones II. Resumen y recomendaciones de gestin A. Hallazgos importantes B. Comentarios C. Recomendaciones D. Impacto III. Alternativas A. Configuraciones del sistema alternativas B. Criterio utilizado en la seleccin del enfoque definitivo IV. Descripcin del sistema A. Declaracin resumida del mbito B. Viabilidad de los elementos asignados V. Anlisis de coste beneficio VI. Evaluacin del riesgo tcnico VII. Consideraciones legales VIII. Otros asuntos especficos del proyecto

REVISION DE LA ESPECIFICACION DEL SISTEMA

La revisin del estudio de viabilidad ha de llevarla a cabo primero el gestor del proyecto (para asegurar la fiabilidad de su contenido) y luego por el director administrativo (para determinar el estado del proyecto). El estudio debe provocar una decisin de "seguir/no
pg.: 21 de 43

Pressman, Cap 5

seguir". Debe tenerse en cuenta que durante las etapas de planificacin, especificacin y desarrollo de la ingeniera del hardware y del software, se tomarn otras decisiones del tipo seguir/no seguir. 5.3.3. Anlisis econmico Entre la informacin ms relevante que contiene el estudio de viabilidad se encuentra el anlisis de coste - beneficio una evaluacin de la justificacin econmica para un proyecto de sistema basado en computadora. El anlisis de coste beneficio seala los costes del desarrollo del proyecto y los contrasta con los beneficios tangibles (esto es, medibles directamente en pesetas) e intangibles del sistema. El anlisis de coste beneficio es complicado porque los criterios varan segn las caractersticas del sistema a desarrollar, el tamao relativo del proyecto y la recuperacin esperada de la inversin como parte del plan estratgico de la compaa. Adems, muchos beneficios obtenidos de los sistemas basados en computadora son intangibles (p. ej.: una mejor calidad del diseo mediante una optimizacin iterativa, una mayor satisfaccin del cliente debida a un control programable y unas mejores decisiones comerciales a partir de datos de ventas con formato previamente analizados). Puede ser difcil lograr comparaciones directas cuantitativas. Como hemos visto anteriormente, el anlisis de los beneficios diferir dependiendo de las caractersticas del sistema. Para ilustrar este hecho, consideremos los beneficios de los sistemas de informacin de gestin [KIN78] mostrados en la Tabla 5.2. La mayora de los sistemas de proceso de datos se desarrollan teniendo como principal objetivo una mejor cantidad, calidad, rapidez y organizacin de la informacin. As, los beneficios de la Tabla 5.2 se centran en el acceso a la informacin y su impacto en el entorno del usuario. Los beneficios que se pueden asociar a programas de anlisis cientfico y de ingeniera o a un producto basado en microprocesador pueden diferir substancialmente. Los beneficios de un sistema nuevo siempre se determinan de acuerdo con el modo de trabajo ya existente. Por ejemplo, consideremos un sistema de diseo asistido por computadora (CAD) que vaya a reemplazar a elementos del proceso manual de diseo en ingeniera. El analista de sistemas debe definir caractersticas ponderables del sistema existente (diseo manual) y del sistema propuesto (CAD). Seleccionando el tiempo de produccin de un dibujo completo y detallado (t-dibujo) entre las muchas cantidades medibles, el analista llega a la conclusin de que el sistema CAD supondr una reduccin de 4 a 1 en ese t-dibujo. Para cuantificar con ms detalle este beneficio, determina los siguientes datos: t-dibujo, tiempo medio de dibujo = 4 horas d, coste por hora de dibujo = 2.000 ptas. n, nmero de dibujos por ao = 8.000 p, porcentaje de dibujo que se va a realizar en el sistema CAD = 60 por 100
pg.: 22 de 43

Pressman, Cap 5

Tabla 5.2. Posibles beneficios del sistema de informacin*

Beneficios de las contribuciones a las tareas de clculo e impresin

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

Beneficios de las contribuciones a las tareas de mantenimiento de registros

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

Beneficios de las contribuciones a las tareas de bsqueda de registros

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

Beneficios de las contribuciones a la posibilidad de reestructuracin del sistema

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

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

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

Beneficios de las contribuciones al control de procesos y de recursos

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

Pressman, Cap 5

Fuente: King y Schrems [KIN78], pg. 23. Reimpreso con permiso.

Conocidos los datos anteriores, puede establecer una estimacin del ahorro anual - el beneficio: Ahorro en el coste del tiempo de dibujo = reduccin x t-dibujo x n x c x p = 9.600.000 ptas. por ao Otros beneficios tangibles del sistema CAD seran tratados de una manera similar. A los beneficios intangibles (p. ej.: mejor calidad de diseo y mayor estmulo para los empleados) se les puede asignar valores en pesetas o usarlos como apoyo de una recomendacin de "seguir", si fuese oportuna. En la Tabla 5.3 se exponen los costes asociados con el desarrollo de un sistema basado en computadora [KlN8]. El analista estima cada coste y luego utiliza los costes del desarrollo y los que surjan sobre la marcha para determinar la recuperacin de la inversin, el punto de igualdad y el perodo de amortizacin. El grfico que muestra la Figura 5.6 ilustra estas caractersticas para el ejemplo del sistema CAD expuesto anteriormente. Asumimos que el ahorro total por ao ha sido estimado en 9.600.000 ptas., que el coste total del desarrollo se ha estimado en 20.400.000 ptas. y que los costes anuales se han estimado en 3.200.000 ptas. Por el grfico de la Figura 5.6 determinamos que el perodo de amortizacin es de 3,1 aos. En realidad, la recuperacin de la inversin se determina con un anlisis ms detallado que considera el cambio del valor del dinero a lo largo del tiempo, las consecuencias de los impuestos y otros usos potenciales de la inversin. Contabilizando los beneficios intangibles, el director administrativo decide silos resultados econmicos justifican el sistema.

Figura 5.6. Anlisis de coste beneficio

pg.: 24 de 43

Pressman, Cap 5

Tabla 5.3. Posibles costes del sistema de informacin

___________________________________________________________________ Costes de avituallamiento

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

Costes de puesta a punto

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

Costes relativos al proyecto

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

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

Otro aspecto del anlisis de coste beneficio es la consideracin de los costes incrementales asociados con los beneficios aadidos (mayor o mejor funcionalidad y rendimiento). Para los sistemas basados en computadora, la relacin incremental de coste - beneficio se puede representar como en la Figura 5.7. En algunos casos (curva AA) los costes se incrementan proporcionalmente a los beneficios hasta un determinado punto. Despus de ese punto, cada beneficio adicional es demasiado caro. Por ejemplo, consideremos una funcin de sondeo en tiempo real que tiene 500 milisegundos de tiempo muerto. Se pueden aadir nuevas tareas a un coste relativamente bajo; sin embargo, si la ejecucin total de la tarea se
pg.: 25 de 43

Pressman, Cap 5

aproxima a los 500 milisegundos, el coste de implementacin aumenta drsticamente, ya que se debe mejorar el rendimiento global.

Figura 5.7. Incremento de la relacin coste beneficio.

En otros casos (curva ABCC'), los costes aumentan proporcionalmente hasta A y despus se nivelan a favor de los beneficios aadidos (hasta B), antes de aumentar drsticamente (en C) para los posteriores beneficios. Como ejemplo, consideremos un sistema operativo monousuario que se va mejorando hasta soportar finalmente varios usuarios. Una vez que se dispone del soporte multiusuario, la tasa de aumento del coste al aadir funciones multiusuario puede bajar un poco. Sin embargo, una vez que se alcance la capacidad mxima del procesador, las nuevas funciones requerirn un procesador ms potente, con el consiguiente gran incremento en el coste. La siguiente cita [FRI77] caracteriza mejor el anlisis de coste beneficio:
Al igual que se olvida la retrica poltica despus de las elecciones, puede que se olvide el anlisis de coste beneficio una vez que comienza la implementacin del proyecto. Sin embargo, es extremadamente importante, ya que ha sido el vehculo con el que se ha conseguido la aprobacin por parte de la gestin.

Slo gastando el tiempo necesario para evaluar la viabilidad, reducimos las oportunidades de situaciones extremadamente embarazosas (o ms que embarazosas) en etapas posteriores de un proyecto de un sistema. El esfuerzo gastado en el anlisis de viabilidad que resulta en la cancelacin de un proyecto propuesto no es un esfuerzo desaprovechado. 5.3.4. Anlisis tcnico Durante el anlisis tcnico, el analista evala los mritos tcnicos del concepto de sistema, mientras que al mismo tiempo recoge informacin adicional sobre el rendimiento, fiabilidad, facilidad de mantenimiento y posibilidad de produccin. En algunos casos la etapa de anlisis del sistema tambin incluye una cantidad limitada de investigacin y de diseo.
pg.: 26 de 43

Pressman, Cap 5

El anlisis tcnico empieza con una definicin de la viabilidad tcnica del sistema propuesto. Qu tecnologas se requieren para conseguir la funcionalidad y el rendimiento del sistema? Qu nuevos materiales, mtodos, algoritmos o procesos se requieren y cul es el riesgo de su desarrollo? Cmo afectarn al coste estos elementos de tecnologa? Las herramientas de que se puede disponer para el anlisis tcnico se encuentran en las tcnicas matemticas de modelizacin y optimizacin, en la probabilidad y la estadstica, en la teora de colas y en la teora de control - por nombrar unas cuantas 4. Sin embargo, es importante tener en cuenta que la evaluacin analtica no es siempre posible. La modelizacin (bien matemtica o fsica) es un mecanismo efectivo para el anlisis tcnico de sistemas basados en computadora. La Figura 5.8 ilustra el flujo global de informacin del proceso de modelizacin. El modelo se crea a partir de la observacin del mundo real o de una aproximacin basada en los objetivos del sistema. El analista comprueba el comportamiento del modelo y lo compara con el del mundo real o con el del sistema esperado, obteniendo informacin de viabilidad tcnica para el sistema propuesto.

Figura 5.8. Modelizacin del sistema.

Blanchard y Fabrycky [BLA81, pg. 270] definen un conjunto de criterios para el uso de modelos durante el anlisis tcnico de sistemas:
1. El modelo debe representar la dinmica de la configuracin del sistema que est siendo evaluado, de una forma que sea suficientemente simple de comprender y manipular, y tambin que est lo suficientemente cerca de la realidad operativa como para obtener resultados satisfactorios. 2. El modelo debe realzar aquellos factores que sean ms relevantes para el problema en cuestin y suprimir (con discrecin) aquellos que no sean importantes.
4

Hay un tipo de herramientas CASE, denominadas herramientas de simulacin y creacin de prototipos, que pueden ayudar bastante en el anlisis tcnico. Estas herramientas se tratan en los captulos 15 y 22.
pg.: 27 de 43

Pressman, Cap 5

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

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

5.3.5 Asignacin y compromisos Una vez que se ha respondido a las cuestiones relativas a la tarea de anlisis, hay que considerar soluciones alternativas. Cada funcin del sistema, con su rendimiento requerido y sus caractersticas de interfaz, es asignada a uno o ms elementos del sistema. Por ejemplo, el anlisis de un nuevo sistema de grficos de computadora indica que una funcin importante es la transformacin espacial de las imgenes grficas tridimensionales. Una investigacin de soluciones alternativas para la funcin de transformacin revela las siguientes opciones: 1. Todas las transformaciones tridimensionales realizadas por el software. 2. Las transformaciones "simples" (p. ej.: cambio de escala, translacin y rotacin) realizadas por el hardware y las transformaciones "complejas" (p. ej.: perspectiva y sombreado) realizadas por el software. 3. Todas las transformaciones realizadas por un procesador grfico implementado con hardware. El proceso general de evaluacin de las configuraciones alternativas para el sistema est ilustrado en las Figuras 5.9 y 5.10 [BLA81]. De acuerdo con la Figura 5.9, se evala cada alternativa de configuracin para el sistema de acuerdo con un conjunto de "parmetros de evaluacin" (criterios de compromiso) que han sido ordenados de acuerdo con su importancia (Figura 5.10). En general, los parmetros de evaluacin estn relacionados con los factores econmicos (p. ej.: el coste del ciclo de vida). Cuando dos o ms parmetros de evaluacin del sistema de bajo orden (p. ej.: el tiempo de respuesta o la resolucin de la pantalla) pueden variar (en diferentes
pg.: 28 de 43

Pressman, Cap 5

asignaciones), permitiendo que se siga alcanzando un parmetro deseable de alto orden (p. ej.: el coste o la fiabilidad), se asla un rea de compromiso (Figura 5.11).

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

5.4.1. Diagramas de arquitectura Para desarrollar el modelo del sistema se utiliza una plantilla de arquitectura [HAT87]. El ingeniero de sistemas asigna elementos del sistema a cada una de las cinco regiones de procesamiento dentro de la plantilla: (1) interfaz de usuario, (2) entrada, (3) funcin y control del sistema, (4) salida y (5) mantenimiento y autocomprobacin. El formato de la plantilla de arquitectura aparece en la Figura 5.12. Como casi todas las tcnicas de modelizacin utilizadas en la ingeniera del software y de sistemas, la plantilla de arquitectura permite al analista crear una jerarqua de detalles. En el nivel superior de la jerarqua est el diagrama de contexto de la arquitectura (DCA).

pg.: 29 de 43

Pressman, Cap 5

Figura 5.9. Evaluacin de alternativas. (Reimpreso con permiso de Prentice Hall, EngleWood Cliffs, NJ)

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

pg.: 30 de 43

Pressman, Cap 5

Figura 5.10. Orden de los parmetros de evaluacin. (Reimpreso con permiso de Prentice Hall, Englewood Cliffs, NJ)

Figura 5.11. Area de compromiso.

pg.: 31 de 43

Pressman, Cap 5

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

Figura 5.12. Plantilla de arquitectura.

Cada cuadro de la Figura 5.13 representa una entidad externa - es decir, un productor o un consumidor de informacin del sistema. Por ejemplo, el lector de cdigos de barras produce informacin que entra en el sistema SCCT. El smbolo que representa el sistema completo (o, a niveles ms bajos, los subsistemas principales) es un rectngulo con esquinas redondeadas. Aqu, el SCCT est representado en la regin de proceso y control, en el centro del DCA. Las flechas etiquetadas del DCA representan la informacin (de datos y de control) que se fluye entre el entorno externo y el sistema SCCT. La entidad externa lector de cdigos de barras produce informacin de entrada que est etiquetada como cdigo de barras. En esencia, el DCA ubica el sistema en el contexto de su entorno externo. El ingeniero de sistemas refina el diagrama de contexto de la arquitectura considerando con ms detalle el rectngulo sombreado de la Figura 5.13. Identifica los subsistemas principales que permiten el funcionamiento del sistema de clasificacin de cinta transportadora en el contexto definido por el DCA. De acuerdo con la Figura 5.14, se definen los subsistemas principales 5 en un diagrama de flujo de la arquitectura (DFA), que se obtiene a partir del DCA. Como gua para el desarrollo del DFA un "esquema" ms detallado del SCCT, el ingeniero de software utiliza la informacin que fluye a travs de las regiones de DCA. El diagrama de flujo de la arquitectura muestra los subsistemas principales y las lneas importantes de flujo de informacin (control y
5

Hatley y Pirbhai [HAT87] los denominan mdulos del sistema.

pg.: 32 de 43

Pressman, Cap 5

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

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

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

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

pg.: 33 de 43

Pressman, Cap 5

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

Figura 5.15. Construccin de una jerarqua de DFAs.

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

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

Pressman, Cap 5

elemento de datos que est compuesto por otros tres elementos de datos: prefijo de tipo de producto, identificador numrico y categora de coste . En realidad, en el diccionario tambin estar definido cada uno de esos tres elementos. Los datos sobre el tipo, el origen y el destino se obtienen directamente del DFA (Figura 5.14) y el camino de comunicacin indica la manera en que se transfiere fsicamente la informacin desde el origen y el destino. En otras circunstancias, el camino de comunicacin puede estar definido como un bus o un canal que tendr que ser implementado como parte del diseo del sistema. El diccionario de la arquitectura es una versin a nivel de sistema del diccionario de requisitos - una importante notacin de anlisis del software que se trata en detalle en el Captulo 7. El ltimo elemento de la especificacin del diagrama de arquitectura es el diagrama de interconexin de la arquitectura (DIA) y la correspondiente descripcin de la interconexin. Las flechas del DFA indican el flujo del control y de los datos, sin describir cmo se efecta ese flujo de informacin. El DIA y la especificacin correspondiente, describen cmo se transfiere la informacin - electrnicamente (p. ej.: por un bus), pticamente (p. ej.: por un enlace ptico de tal ancho de banda) o mecnicamente (p. ej.: mediante un actuador o una articulacin mecnica). Para desarrollar el DIA, el ingeniero de sistemas tiene que tomar decisiones de implementacin que es mejor dejarlas para la etapa de diseo. Por esta razn, posponemos el estudio de los aspectos de interconexin hasta el Captulo 15.

Figura 5.16. Una entrada del diccionario de la arquitectura.

5.5. SIMULACION Y MODELIZACION DEL SISTEMA Hace dos dcadas, R. M. Graham [GRA69] hizo un comentario angustioso sobre la forma de construir sistemas basados en computadora: "Construimos los sistemas igual que los hermanos Wright construyeron sus aviones - construyendo todo de una vez, soltndolo desde un acantilado, dejando que se estrelle y comenzando de nuevo". De hecho, actualmente seguimos hacindolo as con al menos un tipo de sistema - el sistema reactivo. Muchos sistemas basados en computadora interactan con el mundo real de una forma reactiva. Es decir, el sistema basado en computadora supervisa los sucesos del mundo real mediante el hardware y el software y, basndose en esos sucesos, el sistema impone un control sobre las mquinas, los procesos e incluso la gente que hace que se produzcan los sucesos. Los sistemas de tiempo real y los sistemas empotrados
pg.: 35 de 43

Pressman, Cap 5

muchas veces se encuentran en la categora de los temas reactivos. Desgraciadamente, los desarrolladores de sistemas reactivos a veces tienen que luchar para conseguir que funcionen correctamente. Hasta hace poco, era difcil predecir el rendimiento, la eficiencia y el comportamiento de dichos sistemas antes de construirlos. En cierto sentido, la construccin de sistemas de tiempo real era muchas veces como una aventura "de vuelo". No se encontraban sorpresas (la mayora desagradables) hasta que no se construa el sistema y se "soltaba desde un acantilado". Si el sistema fallaba debido a una funcin incorrecta, a un comportamiento inapropiado o a un rendimiento pobre, se recogan las piezas y se empezaba de nuevo. Muchos sistemas de la categora de los reactivos controlan mquinas y/o procesos (p. ej.: refineras de petrleo o lneas areas comerciales) que han de funcionar con un grado de fiabilidad extremadamente alto. Si el sistema falla, pueden producirse prdidas humanas o econmicas importantes. Por esta razn, el panorama descrito por Graham es lamentable y peligroso. Hoy en da, se usan herramientas CASE para la modelizacin y la simulacin, con el fin de eliminar sorpresas en la construccin de sistemas reactivos basados en computadora. Estas herramientas se aplican durante el proceso de ingeniera del software, durante la especificacin de los papeles del hardware, del software, de las bases de datos y de la gente. El papel de la herramienta de modelizacin y de simulacin de sistemas ha sido resumido por i-Logix, Inc., un vendedor de herramientas de ingeniera del sistema [ILO90]:
En un proyecto, cuando ms frecuentemente nos centramos en el entendimiento del comportamiento de un sistema en su entorno, es durante las fases de diseo, de implementacin y de prueba, mediante un proceso iterativo de prueba y error. El mtodo Statemate [una herramienta de modelizacin y simulacin] es una alternativa para este costoso proceso. Permite construir un modelo completo que... se centra en los aspectos funcionales y de flujo de datos usuales, pero cubriendo tambin los aspectos de la dinmica y del comportamiento del sistema. Luego, se puede probar el modelo con... herramientas que proporcionan varios mecanismos para inspeccionar y depurar la especificacin y para recuperar la informacin que contiene. Mediante la prueba del modelo de especificacin, el ingeniero de sistemas puede ver cmo se comportar el sistema especificado una vez que se implemente. Se pueden plantear preguntas del tipo "qu pasa si...?" seguir guiones especficos, comprobar que se van a producir determinadas situaciones deseables... y que otras no deseables no se encontrarn. En este sentido, se puede decir que el ingeniero de sistemas juega el papel de usuario eventual del sistema y de su entorno...

Las herramientas de modelizacin y simulacin permiten al ingeniero de sistemas "conducir la prueba" de una especificacin del sistema. Los detalles tcnicos y las tcnicas especializadas de modelizacin que se utilizan para conducir la prueba se presentan en el Captulo 15.

pg.: 36 de 43

Pressman, Cap 5

5.6. LA ESPECIFICACION DEL SISTEMA La especificacin del sistema es un documento que sirve como base para la ingeniera del hardware, la ingeniera del software, la ingeniera de bases de datos y la ingeniera humana. Describe la funcin y el rendimiento de un sistema balado en computadora y las restricciones que gobernarn su desarrollo. La especificacin limita cada uno de los elementos del sistema asignados. Por ejemplo, proporciona al ingeniero de software una indicacin del papel del software dentro del contexto del sistema como un todo y dentro de los subsistemas descritos en los diagramas de flujo de la arquitectura. La especificacin del sistema tambin describe la informacin (control y datos) que sirve de entrada y de salida al sistema. La tabla 5.4 muestra un esquema recomendado para la especificacin del sistema. Sin embargo, tngase en cuenta que se trata slo de uno de los muchos esquemas que se pueden seguir para definir un documento de descripcin del sistema. El contenido o el formato actual puede venir impuesto por algn estndar de la ingeniera del software o de la ingeniera de sistemas (p. ej.: DoD/STD 2167A) o por las preferencias y gustos particulares.

5.7. REVISION DE LA ESPECIFICACION DEL SISTEMA Durante la ingeniera del sistema hay una tendencia natural a pasar por alto la revisin e ir rpidamente al desarrollo. Los gestores tienden a ponerse cada vez ms nerviosos cuando lo que se hace no es soldar componentes ni escribir cdigo. El personal tcnico quiere pasar a las "tareas creativas de la ingeniera" tan pronto como sea posible. No se debe ceder ante estas actitudes! La revisin de la especificacin del sistema evala la correccin de la definicin contenida en la especificacin del sistema. La revisin ha de ser realizada por el tcnico y por el cliente, para asegurar que (1) se ha perfilado adecuadamente el mbito del proyecto; (2) se ha definido correctamente la funcionalidad, el rendimiento y las interfaces; (3) el anlisis del entorno y del riesgo del desarrollo justifican el sistema y (4) el desarrollador y el cliente tienen la misma percepcin de los objetivos del sistema. La revisin de la especificacin del sistema se realiza en dos partes. Inicialmente se aplica un punto de vista de gestin. Despus se realiza una evaluacin tcnica de los elementos y funciones del sistema.

pg.: 37 de 43

Pressman, Cap 5

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

II.

III.

IV.

V. VI.

Las consideraciones claves de la gestin generan las siguientes cuestiones: Se ha establecido una necesidad comercial en firme? Tiene sentido la justificacin del sistema? Necesita el entorno especificado (o el mercado) el sistema descrito? Qu alternativas has se han considerado? Cul es el riesgo de desarrollo de cada elemento del sistema? Estn disponible los recursos necesarios para el desarrollo? Tienen sentido las restricciones de coste y de agenda? Realmente, se debe haber planteado y respondido a estas cuestiones regularmente durante la tarea de anlisis. En este momento, lo que hacemos es volver a examinarlas. El nivel de detalle considerado durante la etapa tcnica de la revisin del sistema vara de acuerdo con el nivel de detalle considerado durante la tarea de asignacin. La revisin debe cubrir los siguientes aspectos:
pg.: 38 de 43

Pressman, Cap 5

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

de

del de los

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

5.8. RESUMEN La ingeniera de sistemas de computadora es el primer paso en la evolucin de un producto o sistema basado en computadora nuevo. Mediante los pasos que hemos denominado colectivamente anlisis del sistema, el ingeniero de sistemas identifica las necesidades del usuario, determina la viabilidad tcnica y econmica, y asigna las funciones y el rendimiento al software, al hardware, a la gente y a las bases de datos los elementos clave del sistema. Se crea un modelo arquitectnico del sistema y se desarrolla una representacin de cada uno de los principales subsistemas. Por ltimo, la ingeniera de sistemas puede utilizar herramientas CASE para crear un modelo reactivo del sistema que se pueda utilizar como base para la simulacin del funcionamiento y del comportamiento. La tarea de ingeniera de sistemas culmina con la creacin de la especificacin del sistema un documento que es la base de todo el trabajo de ingeniera que viene a continuacin. La ingeniera de sistemas requiere una comunicacin intensa entre el cliente y el analista. El cliente debe comprender los objetivos del sistema y ser capaz de exponerlos claramente. El analista debe saber qu preguntas hacer, qu consejos dar y qu investigacin realizar. Si la comunicacin se rompe en esta fase, el xito del proyecto entero estar en peligro. REFERENCIAS [ALL89] [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
pg.: 39 de 43

Pressman, Cap 5

Management, Auerbarch Publishers, 1977 [GEM81] Gemignani, M., Law and the Computer, CBI Publishing Co., 1981. [GRA69] Graham, R. M., in Proceedings 1969 NATO Conference on Software Engineering, 1969. [HAR85] Harris, T. D., Computer Software Protection, Prentice Hal, 1985. [HAT87] Hatley, D. J., and I. A. Pirbhai, Strategies for Real Time Systems Specification, Dorset House, 1987. [IEE89] Database Engineering, Vol. 7, IEEE Computer Society Press, 1989. [ILO90] The Statemate Approach to Complex Systems, i-Logix, Inc., 1990. [KIN78] King, J., and E. Schrems, "Cost Benefit analysis in Information Systems Development and Operation", ACM Computing Surveys, vol. 10, no. 1, March 1978, pp. 19-34. [RAE9O] Raeth, P. G., Expert Systems: A Software Methodology for Modern Applications, IEEE Computer Society Press, 1990. [SC089] Scott, M. D., Computer Law, Wiley, 1989. [WAS89] Wasserman, P. D., Neural Computing: Theory and Practice, Van Nostrand Reinhold, 1989. PROBLEMAS Y PUNTOS A CONSIDERAR 5.1. Encuentre tantos sinnimos como pueda de la palabra sistema. Suerte! 5.2. Construya un "sistema de sistemas" similar al de la Figura 5.2, para un sistema grande (diferente al del ejemplo). La jerarqua debe llegar hasta los elementos ms sencillos del sistema (hardware, software, etc.), al menos por una rama del "rbol". 5.3. Intente dibujar el equivalente de la Figura 5.1 para un sistema (preferiblemente basado en computadora) con el que est familiarizado. Muestre las entradas y las salidas principales, cada elemento del sistema y la interconectividad entre los elementos. 5.4. Un analista de sistemas puede ser: el que desarrolla el sistema, el cliente o alguien de una organizacin externa. Discuta los pros y los contras de cada uno. Describa al analista "ideal". 5.5. Los elementos comunes a todos los sistemas son el hardware, el software y la gente. Qu otros elementos se encuentran frecuentemente en los sistemas basados en computadora? 5.6. Aada al menos cinco cuestiones ms a la lista desarrollada para el sistema SCCT en la Seccin 5.2. Aborde el problema con dos asignaciones adicionales para el SCCT. 5.7. Su profesor le proporcionar una descripcin de alto nivel de un sistema basado en computadora. (a) Desarrolle un conjunto de preguntas que pudiera proponer un analista. (b) Proponga por lo menos dos conjuntos diferentes de asignaciones para el sistema, de acuerdo con las respuestas del profesor a las preguntas planteadas. (c) En clase, compare sus asignaciones con las realizadas por otros compaeros. 5.8. Intente desarrollar una clasificacin jerrquica para el hardware de computadoras. Identifique cada clase de hardware; proporcione ejemplos de dispositivos reales de cada clase.
pg.: 40 de 43

Pressman, Cap 5

5.9

Intente desarrollar una clasificacin jerrquica para el software de computadoras. Identifique cada clase de software; proporcione ejemplos de programas reales de cada clase. 5.10. Hemos observado similitudes entre los procesos de ingeniera del hardware y del software. En qu difieren las fases de estos procesos? 5.11. La ingeniera humana intenta construir sistemas "amigables con el usuario". Defina el concepto amigable con el usuario con sus propias palabras. 5.12 Desarrolle una lista de comprobacin de atributos que haya que considerar cuando se vaya a evaluar la "viabilidad" de un sistema. Discuta la interrelacin entre los atributos e intente aportar un mtodo para clasificarlos de tal forma que se pueda obtener un nmero de viabilidad cuantitativo. 5.13. Investigue sobre las tcnicas de contabilidad que se usan para el anlisis detallado de coste beneficio de un sistema basado en computadora que requiera fabricacin de hardware y ensamblaje. Intente escribir un conjunto de directrices tipo de receta" que pudiese seguir un gestor tcnico. 5.14. Desarrolle un anlisis de coste beneficio equivalente al que se muestra en las Tablas 5.2 y 5.3, para sistemas cientficos/de ingeniera. Ample las tablas para incluir aplicaciones de tiempo real y empotradas. 5.15. Desarrolle un diagrama de contexto de la arquitectura y los diagramas de flujo de la arquitectura para un sistema basado en computadoras de su eleccin (o uno asignado por su profesor). 5.16. Escriba una narrativa de mdulo de sistema que pudiera encontrarse en la especificacin del diagrama de arquitectura de uno o ms de los subsistemas definidos en los DFAs del Problema 5.15. 5.17. Investigue en la literatura sobre herramientas CASE y escriba un breve artculo describiendo cmo funcionan las herramientas de modelizacin y simulacin. Alternativa: recopile informacin de dos o ms vendedores de herramientas CASE que suministren herramientas de modelizacin y simulacin, y evale las similitudes y las diferencias. 5.18. Basndose en los documentos suministrados por su profesor, desarrolle una especificacin del sistema abreviada, para uno de los siguientes sistemas basados en computadora: (a) Un sistema de procesamiento de textos de bajo coste. (b) Un digitalizador ptico para una computadora personal. (c) Un sistema de correo electrnico. (d) Un sistema de matrcula para la universidad. (e) Un sistema de anlisis de ingeniera. (f) Un sistema interactivo de reservas. g) Un sistema de inters local. Asegrese de crear los modelos de arquitectura descritos en la Seccin 5.4.
pg.: 41 de 43

Pressman, Cap 5

5.19. Existen caractersticas de un sistema que no se puedan establecer en el momento de la definicin? Describa esas caractersticas, si las hay, y explique por qu su consideracin debe ser postergada para ms adelante en el proceso de ingeniera. 5.20. Existen situaciones en las que la especificacin formal del sistema pueda ser abreviada o eliminada por completo? Explique su respuesta. OTRAS LECTURAS Debido a que se trata de un tema interdisciplinario, la ingeniera de sistemas basados en computadora es una materia difcil y, por ello, se han publicado pocos libros verdaderamente buenos. Los libros de Blanchard y Fabrycky [BLA81] y de Athey (Systematic Systems Approach, Prentice Hall, 1982) presentan el proceso de la ingeniera de sistemas (con un enfoque de ingeniera distinto) y constituyen una valiosa gua. IEEE Computer Society ha puesto empeo en desarrollar una estructura educativa para la ingeniera de sistemas basados en computadora. Sus primeros descubrimientos se han publicado en los Proceedings of Computer Based System Engineering Workshop (IEEE, 1990). Un excelente tutorial del IEEE por Thayer y Dorfman (System and Software Requirements Engineering, IEEE Computer Society Press, 1990) trata las interrelaciones entre los aspectos del anlisis de requisitos a nivel de software y a nivel de sistema. Un manual de los mismos autores (Standars. Guidelines and Examples: System and Software Requirements Engineering, IEEE Computer Society Press, 1990) presenta un estudio detallado de los estndares y las directrices para el trabajo de anlisis. Los libros de Lesson (Systems Analysis and Design, SRA, 1981), McMenamin y Palmer (Essential Systems Analysis, Yourdon Press, 1984) y Silver (Systems Analysis and Design, Addison Wesley, 1989), proporcionan tiles tratamientos de la tarea de anlisis de sistemas tal y como se aplica en el mundo de los sistemas de informacin. Los libros contienen casos de estudio suplementarios que ilustran los problemas, los mtodos y las soluciones que se pueden aplicar durante el anlisis de sistemas. Se han publicado muchos otros libros de texto en el rea general del anlisis y la definicin de sistemas. Entre las incorporaciones ms recientes a la literatura se encuentran: Dickinson, B., Developing Quality Systems, McGraw Hill, 1988. Gause, D.A, y G.M Weinberg, Exploring Requirements, Dorset House, 1989. ModeIl, M.E., A Professional's Guide to System Analysis, McGraw Hill, 1988. Para aquellos lectores involucrados activamente en el trabajo con sistemas o interesados en un tratamiento sofisticado del tema, los libros de Gerald Weinberg (An Introduction to General System Thinking, Wiley Interscience, 1976 y On the design of Stable Systems, Wiley Interscience, 1979) se han convertido ya en clsicos y proporcionan un tratamiento excelente de la "concepcin de sistemas generales" que conduce implcitamente a un enfoque general del anlisis y del diseo de sistemas. Los libros ms recientes de Weinberg (General Principies of System Design, Dorset House, 1988 y Rethinking Systems Analysis and Design, Dorset House, 1988) continan en la
pg.: 42 de 43

Pressman, Cap 5

tradicin de sus anteriores trabajos. Las series de Auerbach, System Development Management (Auerbach Publishers, actualizadas cada ao), proporcionan un tratamiento excelente de la planificacin y la definicin de sistemas de informacin a gran escala. El enfoque pragmtico de Auerbach ser especialmente til a los profesionales de la industria.

pg.: 43 de 43