INGENlERfA DEL SOFTWARE.

U N ENFOQUE PRACTICO

parada con la contrasea vlida almacenada en el sistema. Si la contrasea es errnea, el panel de control emitir un sonido y se restaurar para incorporar una nueva entrada. 3. El propietario selecciona y pulsa stay o away (ver Fig. 11.2) para activar el sistema. Stay activa solamente sensores perimetrales (cuando detectan movimiento interno se desactivan). Away activa todos los sensores. 4. Cuando ocurre una activacin, una luz de alarma puede ser observada por el propietario. Cada caso de uso facilita un escenario sin ambigedad en la interaccin entre el actor y el software. Esto puede usarse para especificar requisitos de tiempo u otras restricciones del escenario. Por ejemplo, en el caso de uso referido anteriormente, los requisitos

indican que ocurrir 30 segundos despus de pulsar la tecla stay o away. Esta informacin puede aadirse al caso de uso. Los casos de uso describen escenarios que sern percibidos de distinta forma por distintos actores. Wyder [WYD96] indica que la calidad de la funcin desplegada puede ser usada para desarrollar un amplio valor de prioridades para cada caso de uso. Para acabar, los casos de uso son evaluados desde el punto de vista de todos los actores definidos para el sistema. Se asigna un valor de prioridad a cada caso de uso (por ejemplo, un valor de 1 a 10)para cada acto?. Se calcula una prioridad, indicando la importancia percibida de cada caso de uso. Cuando un modelo de proceso iterativo es usado por la ingeniera del software orientado a objetos, las prioridades pueden influir en qu funcionalidad del sistema ser entregada primero.

Durante las dos pasadas dcadas, se han desarrollado un gran nmero de mtodos de modelado. Los investigadores han identificado los problemas del anlisis y sus causas y han desarrollado varias notaciones de modelado y sus correspondientes conjuntos de heursticas para solucionarlos. Cada mtodo de anlisis tiene su punto de vista. Sin embargo, todos los mtodos de anlisis se relacionan por un conjunto de principios operativos: 1. Debe representarse y entenderse el dominio de informacin de un problema. 2. Deben definirse las funciones que debe realizar el software. 3. Debe representarse el comportamiento del software (como consecuencia de acontecimientos externos). 4. Deben dividirse los modelos que representan informacin, funcin y comportamiento de manera que se descubran los detalles por capas ( o jerrquicamente). 5. El proceso de anlisis debera ir desde la informacin esencial hasta el detalle de la implementacin.
Cules son los principios subyacentes que guan el trabajo de anlisis?

Aplicando estos principios, el analista se aproxima al problema sistemticamente. Se examina el dominio de informacin de manera que pueda entenderse completamente la funcin. Se emplean modelos para poder comunicar de forma compacta las caractersticas de la funcin y su comportamiento. Se aplica la particin para
Lo ideal es que la evaluacin sea realizada por funciones individuales de,la organizacin o negocio representadas por un actor.

reducir la complejidad. Son necesarias las visiones esenciales y de implementacin del software para acomodar las restricciones lgicas impuestas por los requisitos del procesamiento y las restricciones fsicas impuestas por otros elementos del sistema. Adems de los principios operativos de anlisis mencionados anteriormente, Davis [DAV95a] sugiere un conjunto6 de principios directrices para la ingeniera de requisitos: Entender el problema antes de empezar a crear el modelo de anlisis. Hay tendencia a precipitarse en busca de una solucin, incluso antes de entender el problema. Esto lleva a menudo a un elegante software para el problema equivocado! Desarrollar prototipos que permitan al usuario entender cmo ser la interaccin hombre-mquina. Como el concepto de calidad del software se basa a menudo en la opinin sobre la amigabilidad de la interfaz, el desarrollo de prototipos (y la iteracin que se produce) es altamente recomendable. Registrar el origen y la razn de cada requisito. Este es el primer paso para establecer un seguimiento hasta el cliente. Usar mltiples planteamientos de requisitos. La construccin de modelos de datos, funcionales y de comportamiento, le proporcionan al ingeniero del software tres puntos de vista diferentes. Esto reduce la probabilidad de que se olvide algo y aumenta la probabilidad de reconocer la falta de consistencia. Dar prioridad a los requisitos. Las fechas ajustadas de entrega pueden impedir la implementacin de
Aqu se menciona slo un pequeo subconjunto de los principios de ingeniera de requisitos de Davis. Para obtener ms informacin, vase [DAV95a].
188

CAPTULO 11

CONCEPTOS Y PRINCIPIOS DEL ANALISIS

todos los requisitos del software. Si se aplica un modelo de proceso incremental (Captulo 2), se deben identificar los requisitos que se van a entregar en la primera entrega. Trabajar- para eliminar la ambigedad. Como la mayora de los requisitos estn descritos en un lenguaje natural, abunda la oportunidad de ambigedades. El empleo de revisiones tcnicas formales es una manera de descubrir y eliminar la ambigedad.

un modelo de datos. Este dominio contiene tres visiones diferentes de los datos y del control a medida que se procesa cada uno en un programa de computadora: (1) contenido de la informacin y relaciones, (2) flujo de la informacin y (3) estructura de la informacin. Para entender completamente el dominio de la informacin, debera estudiarse cada una de estas visiones.

Para comenzar a comprender el dominio de informacin, la primera pregunto que debe ser realizada es: ((2Qu informacin de salida generadel sistema?))

Un ingeniero del software que se aprenda estos principios de memoria es muy probable que desarrolle una especificacin del software que proporcione un excelente fundamento para el diseo.

11.3.1. El dominio de la informacin Todas las aplicaciones software pueden denominarse colectivamenteprocesamiento de dutos. Es interesante que este trmino contenga una clave para nuestro entendimiento de los requisitos del software. El software se construye para procesar datos, para transformar datos de una forma a otra, es decir, para aceptar una entrada de informacin, manipularla de alguna manera y producir una salida de informacin. Esta declaracin fundamental de objetivos es cierta, tanto si construimos software por lotes para un sistema de nminas, como si construimos software dedicado de tiempo real para controlar el flujo de combustible de un motor de automvil.

El dominio de informacin de un problema agrupan elementos de datos u objetos que contienen nmeros, texto, imgenes audio, video o cualquier combinacin de ellos.

Es importante recalcar, sin embargo, que el softwa-

re tambin procesa sucesos. Un suceso representa algn

aspecto de control del sistema.y no es ms que un dato binario (es encendido o apagado, verdadero o falso, est all o no). Por ejemplo, un sensor de presin detecta la presin que excede de un valor seguro y enva una seal de alarma al software de vigilancia. La seal de alarma es un suceso que controla el comportamiento del sistema. Por tanto, los datos (nmeros, caracteres, imgenes, sonidos, etc.) y el control (acontecimientos)residen dentro del dominio de la informacin de un problema. El primer principio operativo de anlisis requiere el examen del dominio de la informacin y la creacin de
189

El contenido de la informacin representa los objetos individuales de datos y de control que componen alguna coleccin mayor de informacin a la que transforma el software. Por ejemplo, el objeto datos cheque es una composicin de varios componentes de informacin importantes: el nombre del beneficiario, la cantidad neta a pagar, el importe bruto, deducciones, etc. Por tanto, el contenido de cheque es definido por los atributos necesarios para crearlo. De forma similar, el contenido de un objeto de control denominado estado del sistema podra definirse mediante una cadena de bits. Cada bit representa un elemento diferente de informacin que indica si un dispositivo en particular est en lnea o fuera de lnea. Los objetos de datos y de control pueden relacionarse con otros objetos de datos o de control. Por ejemplo, el objeto de datos cheque tiene una o ms relaciones con los objetos empleado, banco y otros. Durante el anlisis del dominio de la informacin, se deberan definir estas relaciones. Elflujo de la informacin representa cmo cambian los datos y el control a medida que se mueven dentro de un sistema. Como se muestra en la Figura 11.3, los objetos de entrada se transforman para intercambiar informacin (datos y/o control), hasta que se transforman en informacin de salida. A lo largo de este camino de transformacin (o caminos), se puede introducir informacin adicional de un almacn de datos (por ejemplo, un archivo en disco o memoria intermedia). Las transformaciones que se aplican a los datos son funciones o subfunciones que debe realizar un programa. Los datos y control que se mueven entre dos transformaciones (funciones) definen la interfaz de cada funcin. La estructura de la informacin representa la organizacin interna de los elementos de datos o de control. Hay que organizar los elementos de datos o de control como una tabla de dimensin n o como una estructura jerrquica en rbol? Dentro del contexto de la estructura, qu informacin est relacionada con otra informacin? Est contenida toda la informacin en una sola estructura o se van a utilizar varias? Cmo se relaciona la informacin de una estructura con la de otra? Estas y otras preguntas se responden mediante una valoracin de la estructura de la informacin.

INGENiERfA DEL SOFTWARE. UN ENFOQUE PRCTICO

Debera resaltase que la estructura de datos, un concepto afn que se estudiar ms adelante en este libro, se refiere al diseo e implementacin de la estructura de la informacin. 11.3.2. Modelado Los modelos se crean para entender mejor la entidad que se va a construir. Cuando la entidad es algo fsico (un edificio, un avin, una mquina), podemos construir un modelo idntico en forma, pero ms pequeo. Sin embargo, cuando la entidad que se va a construir es software, nuestro modelo debe tomar una forma diferente. Debe ser capaz de modelar la informacin que transforma el software, las funciones (y subfunciones) que permiten que ocurran las transformaciones y el comportamiento del sistema cuando ocurren estas transformaciones. El segundo y tercer principios operativos del anlisis requieren la construccin de modelos de funcin y comportamiento.

na manera. Un modelo de comportamiento crea una representacin de los estados del software y los sucesos que causan que cambie de estado.

Los modelos creados durante el anlisis de requisitos desempean unos papeles muy importantes: El modelo ayuda al analista a entender la informacin, la funcin y el comportamiento del sistema, haciendo por tanto ms fcil y sistemtica la tarea de anlisis de requisitos. El modelo se convierte en el punto de mira para la revisin y por tanto la clave para determinar si se ha completado, su consistencia y la precisin de la especificacin. El modelo se convierte en el fundamento para el diseo, proporcionando al diseador una representacin esencial del software que pueda trasladarse al contexto de la implementacin.

L Qu tipos de modelos debemos crear durante el anlisis de requisitos?

Modelos funcionales. El software transforma la informacin y, para hacerlo, debe realizar al menos tres funciones genricas: entrada, procevamiento y salida. Cuando se crean modelos funcionales de una aplicacin, el ingeniero del software se concentra en funciones especficas del problema. El modelo funcional empieza con un sencillo modelo a nivel de contexto (por ejemplo, el nombre del software que se va a construir). Despus de una serie de iteraciones, se consiguen ms y ms detalles funcionales, hasta que se consigue representar una minuciosa definicin de toda la funcionalidad del sistema.
Objetc de enti

i Cmo usar los modelos creados durante el trabajo de anlisis de requisitos?

Los mtodos de anlisis estudiados en los Captulos 12 y 2 1 son de hecho mtodos de modelado. Aunque el mtodo de modelado empleado es a menudo cuestin de preferencias personales (o de la organizacin),la actividad de modelado es fundamental para un buen trabajo de anlisis.

!salida

11.3.3. Particin A menudo los problemas son demasiado grandes o complejos para entenderlos globalmente. Por este motivo, tendemos a hacer una particin (dividir) de estos problemas en partes que puedan entenderse fcilmente y establecer las interacciones entre las partes de manera que se pueda conseguir la funcin global. El cuarto principio operativo del anlisis sugiere que se pueden partir los dominios de la informacin, funcional y de comportamiento.

Almacn

".% c

VE

FIGURA 11.3. Flujo y transformacin de la informacin.

l a descomposicin es un proceso que resulta de la elaboracin de datos, funciones o comportamientos. Puede ser realizada horizontal o verticalmente,

Modelos de comportamiento. La mayora del software responde a los acontecimientos del mundo exterior. Esta caracterstica estmulo-respuesta forma la base del modelo
del comportamiento. Un programa de computadora siempre est en un estado, un modo de comportamiento observable exteriormente (por ejemplo, esperando, calculando, imprimiendo, haciendo cola) que cambia slo cuando ocurre algn suceso. Por ejemplo, el software permanecer en el estado de espera hasta que (1) un reloj interno le indique que ha pasado cierto intervalo de tiempo, (2) un suceso externo (por ejemplo, un movimiento del ratn) provoca una interrupcin, o (3) un sistema externo seala al software que acte de algu190

En esencia, la particin descompone un problema en sus partes constitutivas. Conceptualmente,establecemos una representacin jerrquica de la informacin o de la funcin y despus partimos el elemento de orden superior (1) exponiendo ms detalles cada vez al movernos verticalmente en la jerarqua o (2) descomponiendo el problema si nos movemos horizontalmente en la jerarqua. Para ilustrar estos enfoques de particin, reconsideremos el sistema de seguridad Hogarseguro descrito en la Seccin 11.2.2. La asignacin de software para Hogarseguro (obtenido como consecuencia de las acti-

CAPTULO 11

CONCEPTOS Y PRINCIPIOS DEL

ANALISIS

vidades de ingeniera del sistema y de las reuniones TFEA) puede establecerse en los prrafos siguientes:
El software de HogarSeguro permite al propietario configurar el sistema de seguridad cuando se instala, vigila todos los sensores conectados al sistema de seguridad e interacta con el propietario a travs de un teclado y teclas funcionales del panel de control de HogarSeguro mostrado en la Figura 11.2.
Durante la instalacin, el panel de control de HogarSeguro se emplea para programar y configurar el sistema. A cada sensor se le asigna un nmero y un tipo, se programa una contrasea para activar y desactivar el sistema y se introducen el (los) nmero(s) de telfono que se marcar(n) cuando un sensor detecte un suceso que haga saltar la alarma. Cuando un sensor detecta un acontecimiento, el software invoca una alarma sonora asociada al sistema. Despus de un retardo especificado por el propietario durante la configuracin del sistema, el software marca un nmero de telfono de una empresa de seguridad y proporciona informacin sobre la direccin, informando de la naturaleza del acontecimiento detectado. El nmero se volver a marcar cada 20 segundos hasta que se obtenga la conexin telefnica.

en el Capitulo 12) proporcionar una visin ms profunda de los requisitos del sistema. A medida que se parte el sistema, se obtienen las interfaces entre las funciones. Los datos y elementos de control que se mueven a travs de una interfaz deberan restringirse a las entradas necesarias para realizar la funcin en cuestin y a las salidas requeridas por otras funciones o elementos del sistema.
Sotfware de Hogarseguro

Configurar sistema

Monitorizar sensores Particin horizontal

lnteractuar con el usuario

FIGURA 11.4. Particin horizontal de una funcin de Hogar Seguro.

Toda la interaccin con Hogarseguro es manejada por un subsistema de interaccin con el usuario que lee la entrada de informacin proporcionada a travs del teclado y las teclas funcionales, las pantallas que presentan mensajes y el estado del sistema en la pantalla LCD. La interaccin con el teclado toma la siguiente forma...

Los requisitos del software de HogarSeguro pueden analizarse partiendo los dominios de informacin, funcional y de comportamiento del producto. Para ilustrarlo, partiremos el dominio funcional del problema. La Figura 11.4 ilustra una descomposicin horizontal del software HogarSeguro. El problema se parte mediante la representacin de las funciones constitutivas del softwareHogarSeguro, movindose horizontalmente en la jerarqua funcional. En el primer nivel de la jerarqua aparecen tres funciones principales.

1 1.3.4. Visiones esenciales y de implementa~in~ Una visin esencial de los requisitos del software presenta las funciones a conseguir y la informacin a procesar sin tener en cuenta los detalles de la implementacin. Por ejemplo, la visin esencial de la funcin de HogarScguro leer el estado del sensor no tiene nada que ver con la forma fsica de los datos o el tipo de sensor que se emplea. De hecho, se podra argumentar que leer estado sera un nombre ms apropiado para esta funcin, ya que ignora totalmente los detalles del mecanismo de entrada. Igualmente, un modelo de datos esencial del elemento datos nmero de telfono (implicado en la funcin marcar nmero de telfono) puede representarse en esta fase independientemente de la estructura de los datos (si es que hay alguna) usada para implementar el elemento datos. Enfocando nuestra atencin en la esencia del problema en las primeras fases del anlisis de requisitos, dejamos abiertas nuestras opciones para especificar los detalles de implementacin durante fases posteriores de especificacin de requisitos y diseo del software.

Las subfunciones asociadas con una funcin principal de HogarSeguro pueden examinarse mediante la exposicin vertical detallada en la jerarqua, tal y como se ilustra en la Figura 11.5. Movindose hacia abajo a lo largo de un camino, por ejemplo la funcin sensores de vigilancia, la particin se hace vertical para mostrar mayores niveles de detalle funcional. El enfoque de particin que hemos aplicado a las funciones de HogarSeguro puede aplicarse tambin al dominio de la informacin y al de comportamiento. De hecho, la particin del flujo de la informacin y del comportamiento del sistema (tratados

Evita la tentacin de trasladarfe directamente al punta de vista de implementacin, entendiendo que lo esencia del problema es obvia. El especificar demasiado rpido la implementacin en detalle reduce tus olternativas e incremento el riesgo.

La visin de implementacin de los requisitos del software introduce la manifestacin en el mundo real de las funciones de procesamiento y las estructuras de la informacin. En algunos casos, se desarrolla una representacin fsica en la primera fase del diseo del software. Sin embargo, la mayora de los sistemas basados en computadora se especifican de manera que

' Mucha gente utiliza trminos visin dgicab)y dsica~) referirse para
al mismo concepto.
191

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

se acomode a ciertos detalles de implementacin. Un dispositivo de entrada de informacin a HogarSeguro podra ser un sensor de permetro (no un perro guardin, un guardia de seguridad o una trampa). El sensor detecta una entrada no autorizada al detectar una ruptura en un circuito electrnico. Las caractersticas generales del sensor deberan tenerse en cuenta como parte de la especificacin de los requisitos del software. El analista debe reconocer las restricciones impuestas por elementos predefinidos del sistema (el sensor) y considerar la visin de implementacin de la funcin y de la informacin cuando tal visin es apropiada. Ya hemos comentado anteriormente que el anlisis de los requisitos del software debera concentrarse en qu es lo que debe hacer el software, en vez de cmo se implementar el procesamiento. Sin embargo, la visin de implementacin no debera interpretarse necesariamente como una representacin del cmo. Ms bien, un modelo de implementacin representa el modo actual de operacin, es decir, la asignacin existente o

propuesta de todos los elementos del sistema. El modelo esencial (de funcin o datos) es genrico en el sentido de que la realizacin de la funcin no se indica explcitamente.
Sotfware de HogarSeguro

Configurar sistema

Monitorizar sensores

lnteractuar con el usuario

Rastreo de sucesos del sensor

Act var las funciones de la alarma

Leer el estado del sensor

Identificar el tipo de suceso

Activar/ desactivar el sensor

Activar la alarma sonora

Marcar el nmero de telfono

FIGURA 11.5. Particin vertical de la funcin de Hogarseguro.

El anlisis hay que hacerlo independientemente del paradigma de ingeniera del software que se aplique. Sin embargo, la forma que toma este anlisis vara. En algunos casos es posible aplicar los principios operativos del anlisis y obtener un modelo de software del que se pueda desarrollar un diseo. En otras situaciones, se realizan recopilaciones de requisitos (por TFEA, DFC u otras tcnicas de tormenta de ideas [JOR89]), se aplican los principios del anlisis y se construye un modelo del software a fabricar denominado prototipo para que lo valore el cliente y el desarrollador. Finalmente, hay circunstancias que requieren la construccin de un prototipo al comienzo del anlisis, ya que el modelo es el nico medio a travs del cual se pueden obtener eficazmente los requisitos. El modelo evoluciona despus hacia la produccin del software.

do prototipo desechable. Este prototipo sirve nicamente como una basta demostracin de los requisitos. Despus se desecha y se hace una ingeniera del software con un paradigma diferente. Un enfoque abierto, denominado prototipo evalutivo, emplea el prototipo como primera parte de una actividad de anlisis a la que seguir el diseo y la construccin. El prototipo del software es la primera evolucin del sistema terminado.

i Qu debemos mirar para determinar si un prototipo es o no una alternativa viable?

Antes de poder elegir un enfoque abierto o cerrado, es necesario determinar si se puede crear un prototipo del sistema a construir. Se pueden definir varios factores candidatos a la creacin de prototipos [BOA84]: rea de aplicacin, complejidad, caractersticas del cliente y del proyecto'. En general, cualquier aplicacin que cree pantallas visuales dinmicas, interacte intensamente con el ser humano, o demande algoritmos o procesamiento de combinaciones que deban crearse de manera progresiva, es un buen candidato para la creacin de un prototipo. Sin embargo, estas reas de aplicacin deben ponderarse con la complejidad de la aplicacin. Si una aplicacin candidata (una con las caractersticas reseadas anteriormente) va a requerir el desarrollo de decenas de miles de lneas de cdigo

11.4.1. Seleccin del enfoque de creacin de prototipos El paradigma de creacin de prototipos puede ser cerrado o abierto. El enfoque cerrado se denomina a menu-

Se puede encontrar otro til estudio sobre los factores candidatos e de ((cuandohacer un prototipo>> n [DAV95bj.

192

CAPfTULO 11

CONCEPTOS Y PRINCIPIOS DEL

ANALISIS

antes de poder realizar cualquier funcin demostrable, es muy probable ue sea demasiado compleja para crear un prototipc?. Si se puede hacer una particin a su complejidad, puede ser posible crear prototipos de porciones del software. Como el cliente debe interactuar con el prototipo en fases posteriores, es esencial que ( 1 ) se destinen recursos del cliente a la evaluacin y refinamiento del prototipo, y (2) el cliente sea capaz de tomar decisiones inmediatas sobre los requisitos. Finalmente, la naturaleza del proyecto de desarrollo tendr una gran influencia en la capacidad de crear un prototipo. Desea y es capaz la gestin del proyecto de trabajar con el mtodo del prototipo? ,Tenemos disponibles herramientas para la creacin de prototipos? Tienen experiencia los desarrolladores con los mtodos de creacin de prototipos? Andriole [AND92] sugiere un conjunto de seis preguntas (Fig. 11.6) e indica unos conjuntos bsicos de respuestas con su correspondiente tipo de prototipo sugerido.

ware existentes. La combinacin de prototipos con la reutilizacin de componentes de programa slo funcionar si se desarrolla un sistema bibliotecario de manera que los componentes existentes estn catalogados y puedan recogerse. Debera resaltarse que se puede usar un prodiicto software existente como prototipo de un nuevo y mejorado producto competitivo. En cierta manera, sta es una forma de reutilizacin en la creacin de prototipos software. Especificaciones formales y entornos para prototipos. Durante las pasadas dos dcadas, se han desarrollado varios lenguajes formales de especificacin y herramientas como sustitutos de las tcnicas de especificacin con lenguaje natural. Hoy en da, los desarrolladores de estos lenguajes formales estn desarrollando entornos interactivos que (1) permitan al analista crear interactivamente una especificacin basada en lenguaje de un sistema o software, (2) invoquen herramientas automticas que traducen la especificacin basada en el lenguaje en cdigo ejecutable, y (3) permitan al cliente usar el cdigo ejecutable del prototipo para refinar los requisitos formales.
Trabajo preliminar adicional requerido

11.4.2. Mtodos y herramientaspara el desarrollo de prototipos Para que la creacin del prototipo de software sea efectivo, debe desarrollarse rpidamente para que el cliente pueda valorar los resultados y recomendar los cambios
oportunos. Para poder crear prototipos rpidos, hay disponibles tres clases genricas de mtodos y herramientas (por ejemplo, [AND92], [TAN89]):
Tcnicas de Cuarta Generacin. Las tcnicas de cuarta generacin (T4G) comprenden una amplia gama de lenguajes de consulta e informes de bases de datos, generadores de programas y aplicaciones y de otros lenguajes no procedimentales de muy alto nivel. Como las tcnicas T4G permiten al ingeniero del software generar cdigo ejecutable rpidamente, son ideales para la creacin rpida de prototipos. Componentes de software reutilizables. Otro enfoque para crear prototipos rpidos es ensamblar, ms que construir, el prototipo mediante un conjunto de componentes soft-

Pregunta

Prototipo desechable

Prototipo evolutivo

Se entiende el dominio de la aplicacin? Se puede modelar el problema? Est el cliente suficientemente seguro de los requisitos bsicos del sistema? Estn establecidos los requisitos y son estables?
Hay requisitos ambiguos?
Hay contradicciones en los requisitos?

s s

No No

s
SINo

SINo

No

No

s
No No

s s s

FIGURA 11.6. Seleccin del enfoque apropiado de creacin de prototipo.

No hay duda de que el modo de especificacintiene mucho que ver con la calidad de la solucin. Los ingenieros del sohare que se han visto forzados a trabajar con especiBcaciones incompletas, inconsistentes o engaosas han aperimentado la frustracin y confusin que invariablemente provocan. La calidad, la fecha de entrega y el alcana del software son las que sufren las consecuencias.

En muchos casos, no es rozonable plonteorse que la especificacin deber controstorse con todo Debemos copivror lo esencio de lo que el cliente solicito.

:En algunos casos, se pueden construir rapidamente prototipos extremadamente complejos usando tcnicas de cuarta generacion o componentes software reutilizables
193