The words you are searching are inside this book. To get more targeted content, please make full-text search by clicking here.

Ingeniería del Software - 5ta Edición - Roger S. Pressman

Discover the best professional documents and content resources in AnyFlip Document Base.
Search
Published by Marvin's Underground Latino USA, 2018-09-02 15:06:47

Ingeniería del Software - 5ta Edición - Roger S. Pressman

Ingeniería del Software - 5ta Edición - Roger S. Pressman

hwttpw:/w/lib.erelsrioa-luunciivoenrsaitraiori.an.belot gspot.com
.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

cación dinámica para (1) obtener la información perti- dentes del cliente, y lleva a cabo otras muchas tareas
nente acerca del objeto deseado a partir del depósito de de gestión de objetos [ORF99]. En el servidor unos
interfaz; (2) crear una estructura de datos con paráme- stubs LDI, similares a los definidosen la máquina clien-
tros que habrá que pasar al objeto; (3) crear una solici- te, se emplean como interfaz con la implementación
tud para el objeto; y (4)invocar la solicitud. A del objeto real que reside en la ubicación del servidor.
continuación, se pasa la solicitud al núcleo ORB -una
parte dependiente de implementación del sistema ope- El desarrollo del software para sistemas C/S moder-
rativo en red que gestione las solicitudes-y, a conti- nos está orientado a objetos. Empleando la arquitectu-
nuación, se satisface la solicitud. ra CORBA descrita brevemente en esta sección, los
desarrolladores de software pueden crear un entorno en
La solicitud se pasa a través del núcleo y es proce- el cual se pueden reutilizar los objetos a lo largo y ancho
sada por el servidor. En la ubicación del servidor, un de una red muy amplia. Para más información acerca
adaptador de objetos almacena la información de cla- de CORBA y de su impacto general sobre la ingeniería
ses y de objetos en un depósito de interfaz residente en del software para sistemas C/S, el lector interesadopue-
el servidor, admite y gestiona las solicitudes proce- de consultar [HOQ99] y [SIE991.

CIS

En el Capítulo 2 se presentó un cierto número de (-pj JJdinámica decliente www.elsolucionario.net
modelos de proceso de software distintos. Aun cuan-
do muchos de ellos se podrían adaptar para su utili- Repositorio
zación en el desarrollo de software para sistemas C/S, de lnterfaz
hay dos enfoques que son los que se utilizan más
comúnmente: (1) un paradigma evolutivo que hace FIGURA 28.6.La arquitectura básica CORBA.
uso de la ingeniería del software basada en sucesos
y/o orientada a objetos; y (2) una ingeniería del soft-
ware basada en componentes (Capítulo 27) que se basa
en una biblioteca de componentes de software CYD
y de desarrollo propio.

Los sistemas cliente servidor se desarrollan emplean-
do las actividades de ingeniería del software clásicas
-el análisis, diseño, construcción y depuración- a
medida que evoluciona el sistema a partir de un con-
junto de requisitos de negocios generales para llegar a
ser una colección de componentes de software ya vali-
dados que han sido implementados en máquinas clien-
te y servidor.

RP

La actividad de modelado de requisitos para los sistemas Dado que el modelado de análisis evita la especi-
C/S difiere poco de los métodos de modelado de análisis ficación de detalles de implementación, sólo cuando
que se aplicaban para la arquitectura de computadoras más se haga la transición al diseño se considerarán los
convencionales. Consiguientemente, los principios bási- problemas asociados a la asignación de software al
cos de análisis descritos en el Capítulo 11 y los métodos cliente y al servidor3. Sin embargo, dado que se apli-
de modelado de análisis presentados en los Capítulos 12 ca un enfoque evolutivo de la ingeniería del softwa-
y 21 son igualmente aplicables al softwareC/S. Se debe- re para los sistemas C/S, las decisiones de imple-
ría destacar, sin embargo, que dado que muchos sistemas mentación acerca del enfoque C/S global (por ejem-
C/S modernos hacen uso de componentes reutilizables, plo, cliente pesado frente a servidor pesado) se podrán
también se aplican las actividades de cualificación aso- hacer durante las primeras iteraciones de análisis y
ciadas a la ISBC (Capítulo 27). diseño.

Por ejemplo, una arquitectura C/S conforme a CORBA (Sección
28.1.5) tendrá un profundo impacto en la decisiones sobre el diseño
y la implementación.

512

www.elsolucionario.net
.

CAPfTULO 28 INGENIERfA DEL SOFTWARE DEL COMERCIO ELECTR6NtCO CLIENTE/SERVIDOR

Cuando se está desarrollandoun softwarepara su imple- rísticas. Sin embargo, también se pueden adoptar méto-
mentación empleando una arquitectura de computado- dos convencionales (Capítulos 12 y 16).
ras concreta, el enfoque de diseño debe de considerar
el entorno específico de construcción. En esencia, el 28.12.1. Diseño arquitectónico para sistemas
diseño debería de personalizarse para adecuarlo a la cliente/servidor
arquitectura del hardware.
El diseño arquitectónico de un sistema cliente servidor
Cuando se diseña software para su implementación se suele caracterizar como un estilo de comunicación
empleando una arquitectura clientehervidor, el enfoque de procesos. Bass y sus colegas [BAS98] describe esta
de diseño debe de ser «personalizado» para adecuarlo arquitecturá de la siguiente manera:
a los problemas sig-uientes:
El objetivo es lograr la calidad de la escalabilidad. Un ser-
' diseño de datos domina proceso ,,idor existe para proporcionar datos para uno o más clientes,
de diseño. Para utilizar efectivamente las capacida- que suelen dishbuidos en una red. El cliente originauna
llamada al servidor, el cual trabaja síncronamente o asíncro-
des de un sistema de gestión de bases de datos rela- namente, para servir a la solicitud del cliente. Si el servidor
funciona síncronamente, devuelve el control al cliente al mis-
cional (SGBDR) o un sistema de gestión de bases de mo tiempo que devuelve los datos. Si el servidor trabaja asín-
cronamente, devuelve solo los datos al cliente (el que tiene su
datos orientado a objetos (SGBDOO) el diseño de propio hilo de control). www.elsolucionario.net

los datos pasa a ser todavía más significativo que en

las aplicaciones convencionales.

Aun cuandoel sohore C/S es diferente, se pueden Enel CoprturO 14 sa presenta un estudiodetallado de
utilizar métodos convencionoleso de diseño O0 con muy arquitecíuros.

pocos modificaciones. Dado que los sistemas modernos C/S están basados
en componentes, se utiliza una arquitectura de agente
Cuando se selecciona el paradigma controlado por de solicitud de objetos (ORB) para implementar esta
sucesos, debería realizarse el modelado del com- comunicación síncrona y asíncrona.
portamiento (una actividad del análisis, Capítulo 12
y 21) y será preciso traducir los aspectos orientados A un nivel arquitectónico, el lenguaje de descrip-
al control implícitos en el modelo de comportamiento ción de la interfaz CORBA4 se utiliza para especifi-
al modelo de diseño. car los detalles de la interfaz. La utilización de LDI
El componente de interacciórdpresentacióndel usua- permite que los componentes de software de la apli-
rio de un sistema C/S implementatodas aquellas fun- cación accedan a los servicios ORB (componentes)
ciones que se asocian típicamente con una interfaz sin un conocimiento de su funcionamiento interno.
gráfica de usuario (IGU). Consiguientemente,se verá El ORB también tiene la responsabilidad de coordi-
incrementada la importancia del diseño de interfa- nar la comunicación entre los componentes del clien-
ces (Capítulo 15).El componente de interacción/pre- te y del servidor. Para lograr esto, el diseñador
sentación del usuario implementatodas las funciones especifica un adaptador de objetos (también llamado
que se asocian típicamente con una interfaz gráfica encubridor) que proporciona los servicios siguientes
de usuario (IGU). [BAS98]:
0 Suele seleccionarse un punto de vista orientado a
objetos para el diseño (Capítulo 22). En lugar de la Se registran las implementaciones de componentes
estructura secuencia1 que proporciona un lenguaje (objetos).
de procedimientos se proporciona una estructura de Se interpretan y se reconcilian todas las referencias
objetos mediante la vinculación entre los sucesos de componentes (objetos).
iniciados en la IGU y una función de gestión de Se hacen coincidir las referencias de componentes
sucesos que reside en el software basado en el (objetos) con la implementación de los componen-
cliente. tes correspondiente.
Se activan y desactivan objetos.
Aun cuando prosigue todavía el debate acerca del
mejor enfoque de análisis y diseño para los sistemas Se invocan métodos cuando se transmiten mensa-
C/S, los métodos orientados a objetos (Capítulos 21 y jes.
22) parecen ofrecer la mejor combinación de caracte- Se implementan servicios de seguridad.

En COM y JavaBeans se utiliza un método análogo.
513

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

Para admitirlos componentesCYDproporcionadospor tos de negocios se lleva a cabo empleando los méto- www.elsolucionario.net
dos de ingeniería de la información descritos en el
proveedores diferentes y componentes de desarrollo pro- Capítulo 10. La notación de modelado del análisis
pio que pueden haber sido implementadosutilizandodife- convencional (Capítulo 12), tal como DER, se podrá
rentes tecnologías, se debe diseñar la arquitectura ORB utilizar para definir objetos de negocios, pero es pre-
para lograr interoperabilidad entres componentes. Para ciso establecer un depósito de base de datos para cap-
poderlo llevar a cabo CORBAutiliza un concepto puente. turar la información adicional que no se puede
documentar por completo empleando una notación
Supongamos que un cliente se haya implementado gráfica tal como un DER.
utilizando un protocolo ORBX y que el servidor se haya
implementado utilizando el protocolo ORB Y. Ambos En este depósito,se define un objeto de negocio como
protocolos son conforme CORBA, pero debido a las una información que es visible para los compradores y
diferencias de implementacióninternas, se deben comu- usuarios del sistema, pero no para quienes lo imple-
nicar con un «puente» que proporcione un mecanismo mentan, por ejemplo, un libro en el caso de estudio de
para la traducción entre protocolos internos [BAS98]. ventas de libros. Esta información que se implementa
El puente traduce mensajes de manera que el cliente y utilizando una base de datos relacional, se puede man-
el servidor se puedan comunicar suavemente. tener en un depósito de diseño. La siguiente informa-
ción de diseño se recoge para la base de datos
28.12.2. Enfoques de diseño convencionales para clientehervidor [POR941:

software de aplicaciones Entidades: se identifican en el DER del nuevo sis-
tema.
En los sistemas cliente/servidor, los diagramas de flujo
(Capítulos 12 y 14) se pueden utilizar para establecer Archivos: que implementan las entidades identifica-
el ámbito del sistema, para identificar las funciones de das en el DER.
nivel superior y las áreas de datos temáticas (almace-
nes de datos), y para permitir la descomposición de fun- Relación entre campo y archivo: establece la dispo-
ciones de nivel superior. Apartándose del enfoque DFD sición de los archivos al identificar los campos que
tradicional, sin embargo, la descomposición se detiene están incluidos en cada archivo.
en el nivel de un proceso de negocio elemental, en lugar
de proseguir hasta el nivel de procesos atómicos. Campos: define los campos del diseño (el dicciona-
rio de datos).
En el contexto C/S, se puede definir un proceso ele-
mental de negocios (PEN) como un cierto conjunto de Relaciones entre archivos: identifican los archivos
tareas que se llevan a cabo sin interrupción por parte relacionados que se pueden unir para crear vistas
de un usuario en los centros cliente. Estas tareas o bien lógicas o consultas.
se realizan en su totalidad, o bien no se realizan en
absoluto. Validación de relaciones: identifica el tipo de rela-
ciones entre archivos o entre archivos y campos que
El diagrama entidad relación adopta también un se utilicen par la validación.
papel más importante. Sigue utilizándose para des-
componer las áreas de datos temáticas (de almacenes Tipos de campo: se utiliza para permitir la herencia
de datos) de los DFD con objeto de establecer una de característicasde campos procedentes de superen-
visión de alto nivel de la base de datos que haya que laces del campo (por ejemplo, fecha, texto, número,
implementar empleando un SGBDR. Su nuevo papel valor, precio).
consiste en proporcionar la estructura para definir obje-
tos de negocios de alto nivel (Sección 28.4.3). Tipo de datos: las características de los datos conte-
nidos en el campo.
En lugar de servir como herramientas para una des-
composición funcional, el diagrama de estructuras se Tipo de archivo: se utiliza para identificarcualquiera
utiliza ahora como diagrama de ensamblaje, con obje- de las ubicaciones del archivo.
to de mostrar los componentes implicados en la solu-
ción de algún procedimiento de negocios elemental. Función del campo: clave, clave externa, atributo,
Estos componentes, que constan de objetos de inter- campo virtual, campo derivado, etc.
faz, objetos de aplicación y objetos de bases de datos,
establecen la forma en la que se van a procesar los Valorespermitidos: identifica los valores permitidos
datos. para los campos de tipo de estado.

Reglas de negocios: reglas para editar, calcular cam-
pos derivados, etc.

28.12.3. Diseño de bases de datos
El diseño de bases de datos se utiliza para definir y
después para especificar la estructura de los objetos
de negocios que se emplean en el sistema cliente/ser-
vidor. El análisis necesario para identificar los obje-

514

www.elsolucionario.net
.

CAPfTULO 28 INGENIERfA DEL SOFTWARE DEL COMERCIO ELECTRÓNICO CLIENTElSERVIDOR

A medida que las arquitecturas C/S se han ido hacien- que van más allá del alcance de este libro. El lector inte-
do más frecuentes, la tendencia hacia una gestión de resado puede consultar [BR091], [BER92], [VAS931y
datos distribuida se ha visto acelerada. En los sistemas [ORF99] para una descripción más extensa.
C/S que implementan este enfoque, el componente de
gestión de datos reside tanto en el cliente como en el ser- Objetos de
vidor. En el contexto del diseño de bases de datos, un interfaz
problema fundamental es la distribución de datos. Esto
es, jcómo se distribuyen los datos entre el cliente y el (Componentes)
servidor y cómo se dispersan entre los nudos de la red?
Asociación
Un sistema de gestión de bases de datos relaciona1
(SGBDR)hace fácil el acceso a datos distribuidos median- Objetos de Objetos
te el uso del lenguaje de consulta estructurado(SQL). La base de datos de aplicación
ventaja de SQL en una estructuraC/S es que «no requie- (Componentes) (Componentes)
re navegar» [BER92]. En un SGBDR, los tipos de datos
se especificanempleando SQL,pero no se requiere infor- FIGURA 28.7. Notación de diagrama de estructura www.elsolucionario.net
mación de navegación. Por supuesto, la implicación de
esto es que SGBDR debe ser suficientemente sofisticado para componentes C/S.
para mantener la ubicación de todos los datos y tiene que
ser capaz de definir la mejor ruta hasta ella. En sistemas 28.12.4. Visión general de un enfoque de diseño
de bases de datos menos sofisticados, una solicitud de
datos debe indicar a qué hay que acceder y dónde se Porter [POR951sugiere un conjunto de pasos para dise-
encuentra. Si el software de aplicación debe mantener la ñar un proceso elemental de negocio que combine ele-
información de navegación, entonces la gestión de datos mentos de diseño convencional con elementos de
se vuelve mucho más complicada por los sistemas C/S. diseño orientado a objetos. Se supone que se ha desa-
rrollado un modelo de requisitos que defina los obje-
¿Qué opciones existen para * tos de negocio, y que se ha refinado ya antes de
distribuir datos dentro de un comenzar el diseño de los procesos elementales de
sistema C/S? negocio. Entonces, se utilizan los pasos siguientes para
derivar el diseño:
Es preciso tener en cuenta que también están dispo-
nibles para el diseñador [BER92] otras técnicas para la 1. Para cada proceso elemental de negocio, se identifi-
distribución y gestión de datos: can los archivos creados, actualizados, borrados o
referenciados
Extracción manual. Se permite al usuario copiar
manualmente los datos adecuados de un servidor a un 2. Se utilizan los archivos identificados en el paso 1
cliente. Este enfoque resulta útil cuando el usuario como base para definir componentes u objetos.
requiere unos datos estáticos y cuando se puede dejar
el control de la estación en manos del usuario. 3 . Para cada componente, se recuperan las reglas de
negocio y otra información de objetos de negocio
Instantánea. Esta técnica automatiza la extracción que se haya determinado para el archivo relevante.
manual al especificar una «instantánea»de los datos que
deberán de transferirse desde un cliente hasta un servi- 4. Se determinan las reglas que son relevantes para el
dor a intervalos predefinidos. Este enfoque es Útil para proceso y se descomponen las reglas hasta llegar al
distribuir unos datos relativamente estáticos que sola- nivel de métodos.
mente requieran actualizaciones infrecuentes.
5. Según sea necesario, se definen los componentes
Duplicación. Se puede utilizar esta técnica cuando adicionales que se requieren para implementar los
es preciso mantener múltiples copias de los datos en dis- métodos.
tintos lugares (por ejemplo, servidores distintos o clien-
tes y servidores). En este caso, el nivel de complejidad Porter [POR951 sugiere una notación especializada
se incrementa porque la consistencia de los datos, las de diagramas de estructura (Fig. 28.7) para representar
actualizaciones,la seguridad y el procesamiento deben la estructura de componentes de un proceso elemental
de coordinarse entre los múltiples lugares. de negocio. Sin embargo, se utiliza una simbología dife-
rente para que el diagrama se ajuste a la naturaleza orien-
Fragmentación. En este enfoque, la base de datos tada a objetos del software C/S. En la figura, se
del sistema se fragmenta entre múltiples máquinas.Aun- encuentran cinco símbolos distintos:
que resulta intrigante en teoría, la fragmentación es
excepcionalmente difícil de implementar y hasta el Objeto de interfaz. Este tipo de componente, que
momento no es frecuente encontrarla. también se denomina componente de interacciónlpre-
sentación con el usuario, se construye típicamente en
El diseño de bases de datos, y más específicamente, un único archivo o bien otros archivos relacionados que
el diseño de bases de datos para sistemas C/S son temas se hayan unido mediante una consulta. Incluye méto-

515

www.elsolucionario.net

INGENiERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

dos para dar formato a la interfaz IGU y también la Asociación de datos. Cuando un objeto invoca a otro www.elsolucionario.net
lógica de aplicación residente en el cliente, junto con objeto independiente,se pasa un mensaje entre dos obje-
los controles de la interfaz. También incluye sentencias tos. El símbolo de asociación de datos se utiliza para
incrustadas de SQL, que especifican el procesamiento denotar este hecho.
de la base de datos efectuado en el archivo primario con
respecto al cual se haya construido la interfaz. Si la Asociación de control. Cuando un objeto invoca a
lógica de aplicación asociada normalmente a un objeto otro objeto independiente y no se pasan entre los dos
de interfaz se implementa en un servidor, típicamente objetos, se utiliza un símbolo de asociación de control.
mediante el uso de herramientas de software interme-
dio, entonces la lógica de aplicación que funcione en el 28.12.5. Iteración del diseño de procesos
servidor deberá de identificarsecomo un objeto de apli-
cación por separado. El repositorio de diseño (Sección 28.4.3), que se utili-
za para representar objetos de negocio, se emplea tam-
Objeto de base de datos. Este tipo de componentes bién para representar objetos de interfaz, de aplicación
se utiliza para identificar el procesamiento de bases de y de base de datos. Obsérvese que se han identificado
datos tal como la creación o selección de registros que las entidades siguientes:
esté basada en un archivo distinto del archivo primario
en el cual se haya construido el objeto de interfaz. Es Métodos: describen cómo hay que implementar una
preciso tener en cuenta que si el archivo primario con regla de negocio.
respecto al cual se construyeel objeto de interfaz se pro- Procesos elementales:definen los procesos elementa-
cesa de manera distinta, entonces se puede utilizar un les de negocio identificadosen el modelo de análisis.
segundo conjunto de sentencias SQL para recuperar un Enlace procesolcomponente: identifica a los com-
archivo en una secuencia alternativa. La técnica de pro- ponentes que forman la solución de un proceso ele-
cesamiento del segundo archivo debería identificarse mental de negocio.
por separado en el diagrama de estructura, en forma de Componentes: describe los componentes mostrados
un objeto de base de datos por separado. en el diagrama de estructura.
Enlace regla de negocioslcornponente: identifican a
Objeto de aplicación.Es utilizado por un objeto de los componentesque son significativos para la imple-
interfaz,bien por un objeto de base de datos, y este com- mentación de una determinada regla de negocio.
ponente será invocado bien por un activadorde una base
de datos, o por una llamada a procedimientos remotos. Si se implementa un repositorio utilizando un
También se puede emplear para identificar la lógica de SGBDR, el diseñador tendrá acceso a una herramienta
negocios que normalmente se asocia al procesamiento de diseño muy Útil que proporciona informes que sir-
de interfaz que ha sido trasladado al servidor para su ven de ayuda tanto para la construcción como para el
funcionamiento. futuro mantenimiento del sistema C/S.

203

La naturaleza distribuida de los sistemas clienteher- Se presentan recursos e información útil
vidor plantea un conjunto de problemas específicospara sobre comprobaciones C/S en la dirección
los probadores de software. Binder [BIN92] sugiere las wwwkon-stl.net/-djmosleyl
siguientes zonas de interés:
La estrategia y las tácticas asociadas a la comproba-
Consideraciones del IGU de cliente. acbióonrdca/rstoddeobsevn
diseñarse de tal modo que asneteriores.
Consideraciones del entorno destino y de la diversi- cada uno de los Droblemas
dad de plataformas.
28.13.1. Estrategia general de pruebas C/S
Consideracionesde bases de datos distribuidas (inclu-
yendo datos duplicados). En general, las pruebas de software cliente/servidor se
produce en tres niveles diferentes: (1) las aplicaciones
Consideraciones de procesamiento distribuido(inclu-
yendo procesos duplicados).

Entornos destino que no son robustos.

Relaciones de rendimiento no lineales.

Esta sección e s una versión muy abreviada y adaptada de un ar-
tículo escrito por Daniel Mosley [MOS96] (utilizado con permiso del
autor). En [MOS99] se puede encontrar una versión actualizada y
ampliada.

516

hwttpw:/w/lib.erelsrioa-luunciivoenrsaitraiori.an.belot gspot.com
.

CAPfTULO 28 INGENIERfA DEL SOFTWARE DEL COMERCIO ELECTR6NlCO CLIENTE/SERVIDOR

de cliente individuales se prueban de modo edesconec- Para desarrollar el perfil operativo, es preciso deri- www.elsolucionario.net
tado» (el funcionamiento del servidor y de la red sub- var un conjunto de escenarios de usuario [BIN95], que
yacente no se consideran); (2) las aplicaciones de sea similar a los casos prácticos de estudio tratados en
software de cliente y del servidor asociado se prueban este libro. Cada escenario abarca quién, dónde, qué y
al unísono, pero no se ejercitan específicamentelas ope- por qué. Esto es, quién es el usuario, dónde (en la arqui-
raciones de red; ( 3 )se prueba la arquitectura completa tectura física) se produce la interacción con el sistema,
de C/S, incluyendo el rendimiento y funcionamiento de cuál es la transacción, y por qué ha sucedido. Se pue-
la red. den derivar los escenarios durante las técnicas de obten-
ción de requisitos o a través de discusiones menos
Aun cuando se efectúen muchas clases distintas de formales con los usuarios finales. Sin embargo, el resul-
pruebas en cada uno de los niveles de detalle anterio- tado debería ser el mismo. Cada escenario debe pro-
res, es frecuente encontrar los siguientes enfoques de porcionar una indicación de las funciones del sistema
pruebas para aplicaciones C/S: que se necesitarán para dar servicio a un usuario con-
creto; el orden en que serán necesarias esas funciones,
Pruebas defunción de aplicación. Se prueba la fun- los tiempos y respuestas que se esperan, y la frecuen-
cionalidad de las aplicaciones cliente utilizando los cia con la que se utilizará cada una de estas funciones.
métodos descritos en el Capítulo 17.En esencia, la apli- Entonces se combinan estos datos (para todos los usua-
cación se prueba en solitario en un intento de descubrir rios) para crear el perfil operativo.
errores de su funcionamiento.
La estrategia para probar arquitecturas C/S es aná-
¿Qué tipos de loga a la estrategia de pruebas para sistemas basados en
software que se describían en el Capítulo 18. La com-
comprobaciones se realizan probación comienza por comprobar al por menor. Esto
para los sistemas C/S? es, se comprueba una única aplicación de cliente. La
integración de los clientes, del servidor y de la red se
Pruebas de servidor. Se prueban la coordinación y irá probando progresivamente. Finalmente, se prueba
las funciones de gestión de datos del servidor. También todo el sistema como entidad operativa. La prueba tra-
se considera el rendimiento del servidor (tiempo de res- dicional visualiza la integración de módulos para sub-
puesta y trasvase de datos en general). sistemas/sistemas y su prueba (Capítulo 18) como un
proceso descendente, ascendente o alguna variación de
Pruebas de bases de datos. Se prueba la precisión e los dos anteriores. La integración de módulos en el desa-
integridad de los datos almacenados en el servidor. Se rrollo C/S puede tener algunos aspectos ascendentes o
examinan las transacciones enviadas por las aplicacio- descendentes,pero la integraciónen proyectos C/S tien-
nes cliente para asegurar que los datos se almacenen, de más hacia el desarrollo paralelo y hacia la integra-
actualicen y recuperen adecuadamente. También se ción de módulos en todos los niveles de diseño. Por
prueba el archivado. tanto, la prueba de integraciónen proyectos C/S se efec-
túa a veces del mejor modo posible empleandouna apro-
Pruebas de transacciones. Se crea una serie de prue- ximación no incremental o del tipo «big bang».
bas adecuada para comprobarque todas las clases de tran-
sacciones se procesen de acuerdo con los requisitos. Las un área
transacciones hacen especial hincapié en la corrección e encuenhan
de procesamiento y también en los temas de rendimiento
(por ejemplo,tiempo de procesamientode transacciones y los sistemas
y comprobación de volúmenes de transacciones).
El hecho de que el sistema no se esté construyendo
Pruebas de comunicaciones a través de la red. Estas para utilizar un hardware y un software especificado
pruebas verifican que la comunicación entre los nudos con anterioridad tiene su impacto sobre la comproba-
de la red se produzca correctamente, y que el paso de ción del sistema. La naturaleza multiplataforma en red
mensaje, las transacciones y el tráfico de red relacio- de los sistemas C/S requiere que se preste bastante más
nado tenga lugar sin errores. También se pueden efec- atención a la prueba de configuraciones y a la prueba
tuar pruebas de seguridad de la red como parte de esta de compatibilidades.
actividad de prueba.

Para llevar a cabo estos enfoques de pruebas, Musa
[MUS93] recomienda el desarrollo de perfiles operati-
vos derivados de escenarios cliente/servidor. Un p e r - l
operativo indica la forma en que los distintos tipos de
usuarios interactúancon el sistema C/S. Esto es, los per-
files proporcionan un «patrón de USO» que se puede apli-
car cuando se diseñan y ejecutan las pruebas. Por
ejemplo, para un determinado tipo de usuarios, ¿qué
porcentaje de las transacciones serán consultas? ¿Actua-
lizaciones? ¿Pedidos?

517

www.elsolucionario.net

.

INGENlERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

La doctrina de prueba de configuraciones impone la formas. Además, la comprobación debe explorar un www.elsolucionario.net
prueba del sistema en todos los entornos conocidos de elevado número de rutas lógicas, porque la IGU crea,
hardware y software en los cuales vaya a funcionar. La manipula y modifica una amplia gama de objetos grá-
prueba de compatibilidad asegura una interfaz funcio- ficos. La comprobación se ve complicada aun más por-
nalmente consistente entre plataformas de software y que los objetos pueden estar presentes o ausentes,
hardware. Por ejemplo, la interfaz de ventanas puede ser pueden existir durante un cierto período de tiempo, y
visualmente distinta dependiendo del entorno de imple- pueden aparecer en cualquier lugar del escritorio.
mentación, pero los mismos comportamientos básicos
del usuario deberían dar lugar a los mismos resultados Esto significa que el enfoque tradicional de captu-
independientementedel estándar de interfaz de cliente. ra/reproducción para comprobar interfaces convencio-
nales basadas en caracteres debe ser modificado para
Especificación de pruebas C/S que pueda manejar las complejidades de un entorno
IGU. Ha aparecido una variación funcional del para-
28.13.2. Táctica de pruebas C/S digma de captura/reproducción denominado captura1
Aun cuando el sistema C/S no se haya implementado reproducción estructurada [FAR93] para efectuar la
empleando tecnología orientada a objetos, las técni- prueba de la IGU.
cas de pruebas orientadas a objetos (Capítulo 23) tie-
nen sentido porque los datos y procesos duplicados se La captura/reproducción tradicional registra las
pueden organizar en clases de objetos que compartan entradas tales como las teclas pulsadas y las salidas
un mismo conjunto de propiedades. Una vez que se tales como imágenes de pantalla que se almacenan
hayan derivado los casos prácticos para una clase de para comprobaciones posteriores. La captura/repro-
objetos (o su equivalente en un sistema desarrollado ducción estructurada está basada en una visión in-
convencionalmente), estos casos de prueba deberían terna (lógica) de las actividades externas. Las
resultar aplicables en general a todas las instancias de interacciones del programa de aplicación con la IGU
esa clase. se registran como sucesos internos, que se p u d m
almacenar en forma de «guiones» escritos en Visual
El punto de vista O 0 es especialmente valioso cuan- Basic de Microsoft, en una de las variantes de C, o
do se considera la interfaz gráfica de usuario de los en el lenguaje patentado del fabricante. Las herra-
sistemas C/S modernos. La IGU es inherentemente mientas que ejercitan las IGUs no abarcan las vali-
orientada a objetos, y se aparta de las interfaces tradi- daciones de datos tradicionales ni tampoco las
cionales porque tiene que funcionar en muchas plata- necesidades de comprobación de rutas. Los métodos
de comprobación de caja blancay caja negra descri-
tos en el Capítulo 17 son aplicables en muchos casos,
y las estrategias orientadas a objetos especiales que
se presentaban en el Capítulo 23 son adecuadas tan-
to para el software de cliente como para el software
de servidor.

Aun cuando los sistemas cliente/servidor pueden adop- Las arquitecturas de agente de solicitud de objetos
tar uno o más de los modelos de procesos de software sirven de apoyo para los diseños C/S en los cuales los
y muchos de los métodos de análisis, diseño y com- objetos cliente envían mensajes a los objetos servidor.
probación descritos anteriormente en este libro, las El estándar CORBA hace uso de un lenguaje de defini-
característicasde arquitecturas especialesde C/S requie- ción de interfaz, y los repositorios de interfaz gestionan
ren una personalización del software de ingeniería del las solicitudes de objetos independientementede su ubi-
software. En general,el modelo de proceso del software cación dentro de la red.
que se aplica a los sistemasC/S tiene una naturalezaevo-
lutiva, y los métodos técnicos suelen tender a enfoques El análisis y el diseño de sistemas clientehervidor
orientadosa objetos.El desarrolladordebe describiraque- hacen uso de diagramas de flujo de datos y de enti-
llos objetos que se produzcan en la implementaciónde los dades y relaciones, diagramas de estructura modifi-
componentesde interacción hepresentación con el usua- cados, y otras notaciones que se encuentran en el
rio, de base de datos y de aplicación. Los objetos defi- desarrollo de aplicaciones convencionales. Es preci-
nidos para estos componentes deberían asignarse bien so modificar las estrategias de comprobación para ade-
a la máquina, o bien a la máquina servidor, y se pue- cuarlas a las comprobaciones que examinan la
den vincular a través de un distribuidor de solicitudes comunicación a través de la red y el juego entre el
de objetos. software que reside en el cliente y aquel que reside en
el servidor.

518

www.elsolucionario.net
.

CAPfTULO 28 INGENIERfA DEL SOFTWARE DEL C O M E R C I O ELECTRÓNICO CLIENTE/SERVIDOR

[BAS98] Bass, L., P. Clemens y R. Kazman, Software Archi- [MOS99] Mosley, D., Client Server Software Testing on the www.elsolucionario.net
tecture in Practice, Addison-Wesley, 1998. Desk Top and the Web,Prentice-Hall, 1999.

[BER92] Berson, A., ClientlServer Architecture, McGraw- [MUS93] Musa, J., «Operational Profiles in Software Relia-
Hill, 1992. bility Engineering», IEEE Software, Marzo de 1993, pp.
14-32.
[BIN92] Binder, R., «A CASE-based Systems Engineering
Approach to Client-Server Development», CASE Trends, [ORF99] Orfali, R., D. Harkey y J. Edwards, Essential
1992. ClientlServer Survival Guide, 3.* ed., Wiley, 1999.

[BIN95] Binder, R., «Scenario-Based Testing for Client Ser- [PAU95] L. G. Paul, «Client/Server Deployment», Compu-
ver systemsn, Software Development, vol. 3, n.” 8, Agos- tenuorld, 18 de Diciembre, 1995.
to de 1995, pp. 43-49.
[POR941 Porter, J., O-DES Design Manual, Fairfield Uni-
[BR091] Brown, A.W., Object-Oriented Databases, versity, 1994.
McGraw-Hill, 1991.
[POR951 Porter, J., Synon Developer’s Guide,McGraw-Hill,
[FAR93] Farley, K.J., «SoftwareTesting For Windows Deve-
lopers», Data BasedAdvisor, Noviembre de 1993,pp. 45- 1995.
46,50-52.
[REE97] Reece, G., JBDC and Java, O’Reilly, 1997.
[HOQ99] Hoque, R., CORBAfor Real Programmers, Aca-
demic Pressmorgan Kaufmann, 1999. [SE991 Siegel, J., CORBA 3 Fundamentals and Program-
ming, Wiley, 1999.

[VAS931 Vaskevitch, D., ClientlServer Strategies, IDG
Books. 1993.

28.1. Empleandopublicaciones comerciales o recursos e Inter- Wide Web, y se pueden hacer pedidos a través de correo elec-
net de información de fondo, defina un conjunto de criterios trónico, mediante el sitio Web y también por teléfono o fax.
para evaluar herramientas para la ingeniena del software C/S. Se construirá un sistema clientehervidor para prestar su apo-
yo al procesamiento de pedidos en el sitio de la compañía.
28.2. Sugieracinco aplicacionesen las cuales un servidorpesa- Defina un conjunto de objetos de alto nivel que fueran nece-
do parezca una estrategia de diseño adecuada. sarios para el sistema de procesamiento de pedidos, y organi-
ce estos objetos en tres categorías de componentes: la
28.3. Sugieracinco aplicacionesen las cuales un cliente pesa- presentación con el usuario, la base de datos y la aplicación.
do parezca ser una estrategia de diseño adecuada.
28.8. Formulereglas de negociopara establecercuándose pue-
28.4. Efectúe una investigaciónsobre los Últimos delitos come- de efectuar un envío si el pago se efectúa mediante tarjeta de
tidos en Intemet y describa cómo la tecnología de seguridad crédito, con respecto al sistema descrito en el Problema 28.7.
apuntada en este capítulo podría haberla evitado. Añada reglas adicionales si el pago se efectúamediante cheque.

28.5. Describa cómo se podría estructurarun sistemade reser- 28.9. Desarrolle un diagrama de transición de estados (Capí-
vas en unas líneas aéreas como un sistema cliente/servidor. tulo 12) que defina los sucesos y estados que resultm’an visi-
bles para un dependiente de entrada de pedidos que trabajase
28.6. Investigue los últimos avances en software para traba- en un PC cliente en la división de ventas por catálogo (Pro-
jo en grupo y desarrolle una breve presentación para la clase. blema 28.7).
El profesor puede asignar una función específica a los distin-
tos participantes. 28.10.0frezca ejemplos de tres o cuatro mensajes que pudie-
ran dar lugar a una solicitud de un método de cliente mante-
28.7. Una compañía va a establecer una nueva división de nido en el servidor.
ventas por catálogo para vender mercancías de uso frecuente
y en exteriores.El catálogoelectrónico se publicará en la World

Aun cuando los métodos básicos de análisis y diseño para nahan (Developing Client-Server Applications, IDG Books
sistemas cliente/servidor son bastante parecidos a los siste- Worldwide, 1999) abarca un amplio abanico de temas C/S.
mas O 0 convencionales, se requieren técnicas y conoci- A un nivel más sofisticado, Orfali y sus colaboradores
mientos especializados. Lowe y Helda han escrito unas [ORF99], y Linthicum (Guide to ClientlServer and Intranet
introduccionesvaliosas a los conceptos básicos (ClientlSer- Development, Wiley, 1997) proporcionan las líneas genera-
ver Computingfor Dummies, 3.sed., IDG Books Worldwide, les detalladas para aplicaciones C/S. Berson (ClientlServer
1999),al igual que Zantinge y Adriaans (ManagingClientlSer- Architecture, 2.s ed., McGraw-Hill, 1996)trata temas de arqui-
ver,AddisoniWesley, 1997).En un nivel intermedio, McCla- tectura y componentes.

519

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRdCTICO .

En los últimos años las computadorasde redes se han con- dimiento del software y los aplican a la arquitectura y al dise- www.elsolucionario.net
vertidoen un tema tecnológicocandente (y una estrategiaanies- ño de los sistemas distribuidos. Heinckiens y Loomies (Buil-
gada de negocios). Sinclair y Merkow (Thin Clients Clearly ding Scalable Database Applications: Object-Oriented
Explained, Morgan Kaufmann Publishers, 1999),Friedrichs y Design, Architectures, and Ihzplementations, Addison-Wes-
Jubin (Java Thin-Client Programrningfor a Network Cornpu- ley, 1998) dan importancia al diseño de bases de datos en su
ting Environment,Prentice-Hall, 1999),Dewire (ThinClients, guía para construir aplicaciones cliente/servidor. Ligon
McGraw-Hiil, 1998)y Kanter (UnderstandingThin-ClientlSer- (ClientlServer Comrnunicutions Services: A Guidefor the
ver Cornputing,Microsoft Press, 1998)proporcionan una guía Applications Developer, McGraw-Hill, 1997) tiene en cuen-
valiosa de cómo diseñar, construir, hacer uso y apoyar siste- ta una gran variedad de temas de comunicación relacionados
mas cliente ligeros (delgados). entre los que se incluyen TCP/IP, ATM, EDI, CORBA, men-
sajes y encriptación. Schneberger (ClientlServer Software
Empezando con el modelado de sucesos de negocios, Maintenance, McGraw-Hill, 1997) presenta un marco de tra-
Ruble (Practica1Analysis and Design for ClientlServer and bajo para controlar los costes de mantenimiento de software
GUI Systems, 1997) proporciona un estudio en profundidad C/S y para optimizar el apoyo al usuario.
de las técnicas para el análisis y diseño de sistemas C/S. Los
libros de Goldman, Rawles y Mariga (ClientlServer Infor- Literalmente cientos de libros abarcan el desarrollo de sis-
mation Systems: A Business-Oriented Approuch,Wiley, 1999), temas C/S específicos del vendedor. La siguiente relación
Shan, Earle y Lenzi (Enterprise Computing With Objects: representa un pequeño muestreo:
From ClientlServer Environments to the Internet, Addison-
Wesky, 1997) y Gold-Berstein y Marca (Designing Enter- Anderson, G.W., Client/Server Database Design With
prise ClientlServer Systems, Prentice-Hall, 1997) tienen en Sybase: A High-Performance and Fine-Tuning Guide,
consideración los sistemas C/S en un contexto más amplio McGraw-Hill, 1997.
de empresa.
Barlotta, M. J., Distributed Application Development With
Existe un grupo de libros que estudian la seguridad en Powerbuilder 6 , Manning Publications Company, 1998.
redes; a continuación se proporciona una muestra:
Bates, R.J., Hands-On .Client/Server Internetworking,
Stallings, W., Cryptology and Network Security, Prenti- McGraw-Hill, 1997.
ce-Hall, 1998.
Mahmoud, Q.H., Distributed Programming with java,
Gralla, P., The Complete Idiots Guide to Protecting Your- Manning Publications Company, 1998.
self Online, Que, 1999.
Orfali, R., y Harkey, Client/Server Programming with
Ghosh, A. K., E-cornrnerce Security: Weak Links, Best JavaBeans, Wiley, 1999.
Defenses, John Wiley, 1998.
Sankar, K., Building Internet Client/Server Systems,
Atkins, D. T., Shelden y T. Petru, Internet Security: Pro- McGraw-Hill, 1999.
fessional Reference, New Riders Publishing, 1997.
Mosley [MOS99] y Boume (Testing ClientlServer Sys-
Bernstein, T., A.B. Bhimani, E. Schultz y C. Siegel, Inter- terns, McGraw-Hill, 1997) han escrito libros de guía detalla-
net Securityfor Business, John Wiley, 1998. dos para pruebas C/S. Ambos autoresproporcionan un estudio
en profundidad de las estrategias de comprobación, tácticas
Garfinkel, S., y G. Spafford, Web Securio and Commer- y herramientas.
ce, O. Reilly, 1997.
Una gran variedad de fuentes de información sobre inge-
Tiwana, A., Web Security, Digital Press, 1999. niería del software cliente/servidor está disponible en Inter-
net. Una lista actualizada de referencias a sitios (páginas) web
Loosely y Douglas (High-Performance ClientlServer, que son relevantes para sistemas C/S se pueden encontrar en
Wiley, 1997) explican los principios de la ingeniería de ren- http://www.pressman5.com.

520

CAPÍTULO www.elsolucionario.net
.
29
INGENIERÍA WEB

LA World Wide Web e Internet han introducido a la población en general en el mundo de www.elsolucionario.net
la informática. Compramos fondos de inversión colectivos y acciones, descargamos
música, vemos películas, obtenemos asesoramiento médico, hacemos reservas de habi-
taciones en hoteles, vendemos artículos personales, planificamos vuelos en líneas aéreas, cono-
cemos gente, hacemos gestiones bancarias, recibimos cursos universitarios, hacemos la compra
-es decir, en el mundo virtual se puede hacer todo lo que se necesite-. Se puede decir que
Internet y la Web son los avances más importantes en la historia de la informática. Estas tec-
nologías informáticas nos han llevado a todos nosotros a la era de la informática (con otros
millones de personas quienes finalmente entrarán también). Durante los primeros años del siglo
veintiuno estas tecnologías han llegado casi a formar parte de nuestra vida diaria.

Para todos nosotros que recordamos un mundo sin Web, el crecimiento caótico de la tecno-
logía tiene su origen en otra era -los primeros días del software-. Eran tiempos de poca dis-
ciplina, pero de enorme entusiasmo y creatividad. Eran tiempos en que los programadores a
menudo entraban en otros sistemas, algunas veces con buena intención y otras con mala inten-
ción. La actitud que prevalecía parecía ser la de «Hazlo rápidamente, y entra en el campo, que
nosotros lo limpiaremos (y mejor sería que entendieras lo que realmente queremos construir)
cuando actuemos». ¿Le suena familiar?

En una mesa redonda virtual publicada en IEEE Software [PRE98], mantuve en firme mi
postura en relación con la ingeniería de Web:

Me parece que cualquier producto o sistema importante es merecedor de recibir una ingeniería. Antes
de comenzar a construirlas, lo mejor es entender el problema, diseñar una solución viable, implementarla
de una manera sólida y comprobarla en profundidad. Probablemente también se deberían controlar los
cambios a medida que el trabajo vaya avanzando, y disponer de mecanismos para asegurar la calidad del
resultado final. Muchos de los que desarrollan Webs no dicen lo mismo; ellos piensan que su mundo es
realmente diferente, y que simplemente no se van a aplicar los enfoques de ingeniería del software con-
vencionales.

&Quées? Los sistemas y aplicaciones ñías (por ejemplo, comercio electróni- s.Dado que lasWebApps están e n
(WebApps)basados en Web hacen posi- co), y cada vez es más importante la nte evolución, deben de esta-
ble que una población extensa de usua- necesidad de construir sistemas fia- e los mecanismos para el con-
rios finales dispongan de una gran bles, utilizables y adaptables. Esta es
variedad de contenido y funcionalidad la razón por la que es necesario un trol de configuraciones, garantía de
La ingeniería Web no esun clónicoper- enfoque disciplinado para el desarro- calidad y soporte continuado.
fectode la ingeniería del software,pero llo de WebApps.
toma prestado muchos de los concep- 4 Cuál es el producto obtddo? La
tos y principios básicos de la ingenie- &Cuálesson los pasos a seguir ? Al elaboración de una gran variedad de
ría del software, dando importancia a igual que cualquier disciplina de inge- productos de trabajo de ingenierfa Web
las mismas actividades técnicas y de niería, la ingeniería Web aplica. un (por ejemplo, modelos de análisis.
gestión. Existen diferencias sutiles en enfoque genérico que se suaviza con modelos de diseño, procedimientos de
la forma en que se llevan a cabo estas estrategias, tácticas y métodos espe- pruebas). Y como producto final la
actividades,pero la filosofía primordial cializados. El proceso de ingeniería WebApp operativa.
es idéntica dado que dicta un enfoque Webcomienza con una formulacióndel
disciplinado para el desarrollo de un problema que pasa a resolverse con 1 Cómo puedo estar seguro de que
sistema basado en computadora. las WebApps. Se planifica el proyecto lo he hecho correctamente?Apli-
y se analizan los requisitos d e l a cando las mismas prácticas SQAque se
&Quiénlo hace? Los ingenieros Web y WebApp, entonces se lleva a cabo el aplican en todos los procesos de inge-
los desarrolladores de contenido no diseño de interfaces arquitectónico y niería del software -las revisiones téc-
técnicos crean las WebApps. del navegador. El sistema se imple- nicas formales valoran los modelos de
menta utilizando lenguajes y herra- análisis y diseiío-; las revisiones espe-
&Porqué es importante? A medida mientas especializados asociados con cializadas tienen en consideración la
que las WebApps se integran cada vez la Web,y entonces comienzan las prue- usabilidad y la comprobación se apli-
más en grandes y pequeñas compa- ca para descubrir errores en el conteni-
do, funcionalidad y compatibilidad.

521

hwttpw:/w/li.berelsrioal-uucniivoenrasirtaiori.an.beltogspot.com www.elsolucionario.net
.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRdCTICO

Esto nos lleva a formular una pregunta clave: ¿Pue-
den aplicarse principios, conceptos y métodos de inge-
niería en el desarrollo de la Web? Creo que muchos de
ellos sí se pueden aplicar, pero su aplicación quizás
requiera un giro algo diferente.

Pero, ¿qué ocurriría si estuviera equivocado?, y ¿si
persiste el enfoque actual y específico para ese desa-
rrollo de la Web? Con la ausencia de un proceso disci-
plinado para sistemas basados en Web, cada vez nos
preocupa más la manera en que nos podemos enfrentar con problemas serios para obtener éxito en el desarrollo,
empleo y «mantenimiento» de estos sistemas. En esencia, a medida que entramos en el nuevo siglo, la infraes-
tructura de las aplicaciones que se están creando hoy en día puede llevamos a algo que se podría llamar «Web
enmarañada». Esta frase connota un cúmulo de aplicaciones basadas en Web pobremente desarrolladas y con una
probabilidad de fallo bastante alta. Y lo que es peor, a medida que los sistemas basados en Web se van compli-
cando, un fallo en uno de ellos puede propagar y propagará problemas muy extensos en todos. Cuando ocurra esto,
la confianza en Internet se puede romper provocando resultados irremediables. Y lo que es aún peor, puede con-
ducir a una regulación gubernamental innecesaria y mal concebida, provocando daños irreparables en estas tec-
nologías singulares.
Con objeto de evitar una Web enmarañada y lograr un mayor éxito en el desarrollo y aplicación de sistemas
basados en Web complejos y a gran escala, existe una necesidad apremiante de enfoques de ingeniería Web disci-
plinada y de métodos y herramientas nuevos para el desarrollo, empleo y evaluación de sistemas y aplicaciones
basados en Web. Tales enfoques y técnicas deberán tener en cuenta las características especiales en el medio nue-
vo, en los entornas y escenarios operativos, y en la multiplicidad de perfiles de usuario implicando todo ello un
reto adicional para el desarrollo de aplicaciones basadas en Web.

La Ingeniería Web (IWeb) está relacionada con el establecimiento y utilización de principios científicos, de
ingeniería y de gestión, y con enfoques sistemáticos y disciplinados del éxito del desarrollo, empleo y manteni-
miento de sistemas y aplicaciones basados en Web de alta calidad [MUR99].

B '. .,.-., ,
,.

No hay mucho que decir con respecto al hecho de que el mundo). De forma alternativa, una aplicación se pue-
los sistemas y las aplicaciones' basados en Web (nos de ubicar en una Intranet (implementando la comuni-
referiremos a estas como WebApps)son muy diferentes cación a través de redes de una organización) o una
de las otras categorías de software informático que se Extranet (comunicación entre redes).
tratan en el Capítulo 1. Powell resume las diferencias
básicas cuando afirma que los sistemas basados en Web las WebApps son intensivasde red, controladas
«implican una mezcla de publicación impresa y desa- por el contenidoy en continua evolución. Estos atributos
rrollo de software,de marketing e informática,de comu- tienen un profundo impacto dentro de la forma
nicaciones internas y relaciones externas, y de arte y en que se lleva a coba lo IWeb.
tecnología» [POW98]. Los atributos siguientes se van
a encontrar en la gran mayoría de las WebApps2: Controlada por el contenido. En muchos casos, la
función primaria de una WebApp es utilizar hiperme-
Intensivas de Red. Por su propia naturaleza, una dia para presentar al usuario el contenido de textos, grá-
WebApp es intensiva de red. Reside en una red y debe ficos, sonido y vídeo.

dar servicio a las necesidades de una comunidad diver-

sa de clientes. Una WebApp puede residir en Internet
(haciendoposible así una comunicación abiertapar todo

I En esta categoria se incluyen unos sitios Web completos, funcio En el contexto de este capitulo el termino «aplicacion Webn abar-

nalidad especializada dentro de los sitios Web y aplicaciones de pro- cara todo, desde una pagina Web simple que podria ayudar a un con-
ceso de informacion que residen en Internet, en una Intranet o en sumidor a calcular el pago de un alquiler de un coche hasta un sitio
una Extranet Web completo que proporcione los servicios completos para viales
de negocios y de vacaciones

522

www.elsolucionario.net CAPfTULO 29 INGENIERfA WEB
.

Evolución continua. A diferencia del software de apli- medidas de seguridaden toda la infraestructuraque apo- www.elsolucionario.net
caciones convencional, que evoluciona con una serie de ya una WebApp y dentro de la misma aplicación.
versiones planificadas y cronológicamente espaciadas,
las aplicaciones Web están en constante evolución. No Estética. Una parte innegable del atractivo de una
es inusual que algunas WebApps (específicamente, su WebApp es su apariencia e interacción. Cuando se ha
contenido) se actualicen cada hora. diseñado una aplicación con el fin de comercializarse o
vender productos o ideas, la estética puede tener mucho
Algunos argumentan que la evolución continua de que ver con el éxito del diseño técnico.
las WebApps hace que el trabajo realizado en ellas sea
similar a la jardinería. Lowe [LOW99] trata este tema Las características generales destacadas anterior-
con el siguiente escrito: mente se aplican a todas las WebApps, pero con un gra-
do diferentede influencia. Las categoríasde aplicaciones
La ingeniena está a punto de adoptar un enfoque cientí- que se enumeran a continuación son las más frecuentes
fico y consecuente, suavizado por un contexto específico y en el trabajo de la Web [DAR99]:
práctico, para el desarrollo y el comisionado de sistemas y
aplicaciones. El desarrollo de los sitios Web suele estar des- informativa: se proporciona un contenido solo de lec-
tinado a crear una infraestructura (sembrarel jardín) y enton- tura con navegación y enlaces simples;
ces «ocuparse» de la información que crece y brota dentro
del jardín. Después de un tiempo, el jardín (es decir, el sitio descarga: un usuario descarga la información desde
Web) continuará evolucionando, cambiando y creciendo. el servidor apropiado;
Una buena arquitecturainicial deberá permitir que este cre-
cimiento ocurra de forma controladay consecuente...podn- ¿Cómo se pueden
amos hacer que «tres cirujanos» podaran los «árboles» (es tategorizar las WebApps?
decir, las secciones del sitio Web) dentro del jardín (el sitio
en sí) a la vez se asegurala integridadde las referencias cru- personalizable: el usuario personaliza el contenido
zadas. Podríamos disfrutar de «guarderíasde jardín» donde a sus necesidades específicas;
«se cultiven))las plantasjóvenes (es decir, las configuracio-
nes de diseño para sitios Web). Acabemos con esta analogía, interacción: la comunicación entre una comunidad
no vaya a ser que vayamos demasiado lejos. de usuarios ocurre mediante un espacio chat (charla),
tablones de anuncios o mensajería instantánea;
Un cuidado y una alimentacióncontinua permite que
un sitio Web crezca (en robustez y en importancia). Pero entrada del usuario: la entrada basada en formula-
a diferencia de un jardín, las aplicaciones Web deben rios es el mecanismo primario de la necesidad de
de servir (y adaptarse a) las necesidades de más de un comunicación;
jardinero, Las siguientes características de WebApps
son las que conducen el proceso: orientada a transacciones: el usuario hace una soli-
citud (por ejemplo, la realización un pedido) que es
Inmediatez. Las aplicaciones basadas en Web tienen cumplimentado por la WebApp;
una inmediatez [NOR99] que no se encuentra en otros
tipos de software. Es decir, el tiempo que se tarda en orientado a servicios: la aplicación proporciona un
comercializar un sitio Web completo puede ser cuestión servicio al usuario, por ejemplo, ayuda al usuario a
de días o semanas3. Los desarrolladores deberán utili- determinar un pago de hipoteca;
zar los métodos de planificación, análisis,diseño, imple-
mentación y comprobación que se hayan adaptado a portal: la aplicación canaliza al usuario llevándolo
planificaciones apretadas en tiempo para el desarrollo a otros contenidos o servicios Web fuera del domi-
de WebApps. nio de la aplicación del portal;

No hay duda de que la inmediotez o menudo prevalece acceso a bases de datos: el usuario consulta en una
en el desorrollade las WebApps, pero hay que tener base de datos grande y extrae información;
cuidodo, porque el hecho de hocer olga rápidomente aZmacenesde datos: el usuario hace una consulta en
no significo tener el privilegio de hacer un irobajo una colección de bases de datos grande y extrae infor-
de ingenieríopobre. lo rápido y erróneo roros veces mación.
tiene un resultado acepiable. Las características y las categorías destacadas ante-
riormente en esta sección, y las categorías de aplica-
Seguridad. Dado que las WebApps están disponibles ciones representan los hechos reales para los ingenieros
a través de1 acceso por red, es difícil, si no imposible, de la Web. La clave es vivir dentro de las restricciones
limitarla población de usuarios finales que pueden acce- impuestas por las características anteriores y aun así
der a la aplicación. Con objeto de proteger el conteni- tener éxito en la elaboración de la WebApp.
do confidencial y de proporcionar formas seguras de
transmisión de datos, deberán implementarse fuertes 29.1.1. Atributos de calidad

Todas las personas que hayan navegado alguna vez por la
Web o hayan utilizado una intranet de una compañía pue-

Páginas Web sofisticadaspueden elaborarse en pocas horas

523

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

den opinar sobre lo que hace una «buena»WebApp. Los Desarrollo basado en componentes
puntos de vista individuales vm’an enormemente. Algu- Las tecnologías de componentes estudiadas en los Capí-
nos usuarios disfrutan con gráficosllamativos,en cambio tulos 27 y 28 han evolucionado en gran parte gracias al
otros soloquieren un texto sencillo.Algunos exigen infor- crecimiento explosivo de los sistemas y aplicaciones
mación copiosa, otros desean una presentaciónabreviada. basados en Web. Retomandoel estudio del capítulo ante-
En efecto, la percepción de «lo bueno» por parte del usua- rior, los ingenieros Web disponen de tres estándares
rio (y como consecuencia, la aceptación o no aceptación importantes para la infraestructura: CORBA,
resultante de la WebApp) podría ser más importante que COMDCOM y JavaBeans. Estos estándares (acompa-
cualquierdiscusión técnica sobre la calidad de la WebApp. ñados por los componentespreconstmidos,herramientas
y técnicas) proporcionan una infraestructuraque permite
Pero ¿cómo se percibe la calidad de la WebApp? a los que diseñan empleary personalizar componentesde
¿qué atributos deben de exhibirse ante los ojos de los terceras partes permitiéndoles así comunicarse unos con
usuarios para lograr lo bueno y al mismo tiempo exhi- otros y con servicios a nivel de sistemas.
bir las características técnicas de calidad que permitan
a un ingeniero corregir, adaptar, mejorar y soportar la
aplicación a largo plazo?

Arbol detallado de los requisitos www.elsolucionario.net
de calidad para WebApps

En realidad, todas las características generales de la Seguridad
calidad del software estudiadas en los Capítulos 8, 19 Si en una red reside una WebApp, ésta está abierta a un
y 24 se aplican también a las WebApps. Sin embargo, acceso sin autorización. En algunos casos, ha sido el per-
las características más relevantes -usabilidad, fiabili- sonal interno el que ha intentado acceder sin autorización.
dad, eficiencia y capacidad de mantenimiento- pro- En otros casos, intrusos (hackers)pueden intentar acce-
porcionan una base Útil para evaluar la calidad de los der por deporte,por sacar provecho o con intencionesmás
sistemas basados en Web. maliciosas. Mediante la infraestructurade red se propor-
ciona una variedad de medidas de seguridad,tales como
Olsina y sus colaboradores [OSL99] han preparado encriptación, cortafuegos y otras. Un estudio amplio de
un «árbol de requisitos de calidad» que identifica un este tema queda fuera del ámbito de este libro. Para más
conjunto de atributos que conduce a WebApps de alta información,el lector interesado puede consultar en esta
calidad. La Figura 29.1 resume su trabajo. bibliografía: [ATK97], [KAE991y [BRE991.

Facilidadde corrección Estándares de Internet
Durante la última década el estándar dominante en la
FIGURA 29.1. Árbol de requisitos de calidad (OSL 99). creación del contenido y la estructura de la WebApp ha
sido HTML, un lenguaje de marcas que posibilita al desa-
29.1.2. Las tecnologías rrollador proporcionar una serie de etiquetas que des-
El diseño y la implementación de sistemas basados en criben una gran variedad de objetos de datos (texto,
Web incorporan tres tecnologías importantes: el desarro- gráficos, audio/vídeo, formularios, etc.). Sin embargo,a
llo basado en componentes, la seguridad y los estándares medida que las aplicaciones crecen en tamaño y com-
de Internet. Un ingeniero Web deberá estar familiarizado plejidad, se ha adoptado un nuevo estándar -XML-
con las tres para construir WebApps de alta calidad. para la próxima generación de WebApps. XML
(Extensible Markup Language) el Lenguaje de marcas
extensible es un subconjunto estrictamente definido del
metalenguaje SGML [BRA97],permitiendo que los dise-
ñadores definan etiquetas personalizadas en las descrip-
ciones de una página Web. Mediante una descripción del
metalenguaje XML, el significado de las etiquetas per-
sonalizadas se define en la información transmitida al
sitio del cliente. Para más información sobre XML, el
lector interesado deberá consultar [PAR991 y [STL99].

524

CZC

www.elsolucionario.net

. .. ..... .. ,.: .. . , , .~ . 1. “

8 3 M VJü3IN33NI 62 O?il.LldV3 www.elsolucionario.net
.

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

cliente. Es en este punto en donde se solicitan cambios se integran en la siguiente ruta mediante el flujo incre-
(tienen lugar ampliaciones del ámbito). Estos cambios mental del proceso.

La formulación y el análisis de sistemas y aplicaciones en zonas geográficas en donde actualmente no tenemos dma- www.elsolucionario.net
basados en Web representan una sucesión de activida- cenes de ventas.
des de ingeniería Web que comienza con la identifica-
ción de metas globales para la WebApp, y termina con Finalmente, la compañía define la demografía para
el desarrollo de un modelo de análisis o especificación la WebApp: «Los usuarios potenciales de HogarSegu-
de los requisitos para el sistema. La formulación per- roInc.com son propietarios de casas y de negocios
mite que el cliente o diseñador establezca un conjunto pequeños.»
común de metas y objetivos para la construcción de la
WebApp. También identifica el ámbito de esfuerzo en Las respuestas que se han establecido anteriormen-
el desarrollo y proporciona un medio para determinar te implican metas específicas para el sitio Web Hogar-
un resultado satisfactorio. El análisis es una actividad SeguroInc.com. En general, se identifican dos categorías
técnica que identifica los datos y requisitos funcionales [GNA99]:
y de comportamiento para la WebApp.
Metas informativas:indican la intención de propor-
29.4.1. Formulación cionar el contenido y/o información específicospara
el usuario final.
Powell [POW98] sugiere una serie de preguntas que
deberán formularsey responderse al comienzo de la eta- Metas aplicables: indican la habilidad de realizar
pa de formulación: algunas tareas dentro de la WebApp.

¿Cuál es la motivación principal para la WebApp? "*c%V E

¿Por qué es necesaria la WebApp? Poro toda WebApp deberán definirse metas
informativosy aplicables.
¿Quién va a utilizar la WebApp?

¿Qué preguntas En el contenido de la Web HogarSeguroInc.com,una
se deberían hacer meta informativa podría ser la siguiente:
para formular el problema?
El sitio proporcionará a los usuarios especificacionesde un
La respuesta a estas preguntas deberá ser de lo más producto detallado,como descripcióntécnica, instruccionesde
sucinto posible. Por ejemplo, supongamos que el fabri- instalación e información de precios.
cante de sistemas de seguridad en el hogar ha decidido
establecer un sitio Web de comercio electrónico para El examen de las respuestas anteriores llevará a
vender sus productos directamente a los consumidores. poderse aplicar la afirmación de meta siguiente:
Una frase que describiera la motivación de la WebApp
podría ser la siguiente: HogarSeguroInc.com consultará al cliente sobre la ins-
talación (es decir, sobre la casa, oficina/almacén rninoris-
HogarSeguroInc.com5permitirá a los consumidores confi- ta) que se va a proteger, y dará recomendaciones per-
gurar y comprar todos los componentes necesarios para insta- sonalizadas sobre el producto y la configuración que se va
lar un sistema de seguridad en casa o en su comercio. utilizar.

Es importantedestacar que en esta frase no se ha pro- Una vez que han identificado todas las metas apli-
porcionado ningún detalle. El objetivo es delimitar la cables e informativas se desarrolla el perfil del cliente.
intención global del sitio Web. El perfil del usuario recoge «las características rele-
vantes de los usuarios potenciales incluyendo antece-
Después de discutir con otros propietarios de Hogar- dentes, conocimiento, preferencias e incluso más»
Seguro Inc., la segunda pregunta se podría contestar de [GNA99]. En el caso de HogarSeguroInc.com, el per-
la siguiente manera: fil de usuario identificará las características de un com-
prador típico de sistemas de seguridad (esta información
HogarSeguroInc.com nos permitirá vender directamente a sería proporcionada por el departamento de marketing
los consumidores, eliminando por tanto los costes de interme- de HogarSeguroInc.com).
diarios, y mejorando de esta manera los márgenes de benefi-
cios. También nos permitirá aumentar las ventas en un 25 por Una vez que se han desarrollado las metas y los per-
100por encima de las ventas anuales y nos permitirá penetrar files de usuarios,la actividad de formulación se centraen

HogurSeguro ya se ha utilizado anteriormente como ejemplo en el
libro.

526

hwttwp:w//l.iberlesroialu-ucniiovenrasritiaor.ian.ebtlogspot.com CAPfTULO 29 INGENIERfA WEB
.

la afirmación del ámbito para la WebApp (Capítulo 5).
En muchos casos, las metas ya desarrolladas se integran
en la afirmación del ámbito. Además es Útil, no obstan-
te, indicar el grado de integración que se espera para la
WebApp. Es decir, a menudo es necesario integrar los
sistemas de informaciónexistentes (por ejemplo, la apli-
cación de base de datos existente) en un planteamiento
basado en Web. En este punto se tienen en consideración
también los temas de conectividad.

29.4.2. Análisis de procesamiento. Aquí se realiza una descripción deta- www.elsolucionario.net
llada de todas las funciones y operaciones.
Los conceptos y principios que se trataron para el aná-
lisis de los requisitos del software (Capítulo 11) se apli- Análisis de la configuración.Se efectúa una des-
can sin revisión en la actividad de análisis de ingeniería cripción detallada del entorno y de la infraestructura en
Web. Para crear un modelo de análisis completo para la donde reside la WebApp. La WebApp puede residir en
WebApp se elabora el ámbito definido durante la acti- Internet, en una intranet o en una Extranet. Además, se
vidad de formulación. Durante la IWeb se realizan cua- deberá identificar la infraestructura (es decir, la infra-
tro tipos de análisis diferentes: estructura de los componentes y el grado de utilización
de la base de datos para generar el contenido) de la
Análisis del contenido. Se trata de la identificación WebApp.
del espectro completo de contenido que se va a pro-
porcionar. En el contenido se incluyen datos de texto, Aun cuando se recomienda una especificación
gráficos, imágenes, vídeo y sonido. Para identificar y detallada de los requisitos para WebApps grandes y
describir cada uno de los objetos de datos que se van a complejas, tales documentos no son los usuales. Se
utilizar dentro de la WebApp se puede utilizar el mode- puede decir que la continua evolución de los requisi-
lado de datos (Capítulo 12). tos de la WebApp puede hacer que cualquier docu-
mento se quede obsoleto antes de finalizarse. Aunque
Análisis de la interacción. Se trata de la descrip- se puede decir que esto sucede de verdad, es necesa-
ción detallada de la interacción del usuario y la rio definir un modelo de análisis que pueda funcio-
WebApp. Para proporcionar descripciones detalladas nar como fundamento de la siguiente actividad de
de esta interacción se pueden desarrollar casos prácti- diseño. Como mínimo, la información recogida duran-
cos (Capítulo 11). te las cuatro tareas de análisis anteriores deberá ser
revisada, modificada a petición, y organizada para
Análisis funcional. Los escenarios de utilización formar un documento que pueda pasarse a los dise-
(casos de uso) creados como parte del análisis de inte- ñadores de WebApps
racción definen las operaciones que se aplicarán en el
contenido de la WebApp e implicarán otras funciones

La naturaleza de inmediatez de las aplicaciones basadas en Con objeto de realizar un diseño eficaz basado en
Web unida a la presión de evolucionar continuamente obli- Web, el ingeniero deberá trabajar reutilizando cuatro
ga a que un ingenieroestablezcaun diseño que resuelva el elementos técnicos [NAN98]:
problema comercial inmediato,mientras que al mismo tiem-
po obliga a definif una arquitectura de aplicaciónque ten- Principios y métodos de diseño.Es importante des-
ga la habilidad de evolucionarrápidamentecon el tiempo. tacar que los conceptos y principios del diseño estu-
El problema, desde luego, es que resolver (rápidamente) el diados en el Capítulo 13 se aplican a todas las WebApps.
problema inmediato puede dar comoresultadocompromi- La modularidad eficaz (exhibida con una cohesión alta
sos que afectana la habilidad quetiene la aplicaciónde evo- y con un acoplamientobajo), la elaboración paso a paso,
lucionar con el paso del tiempo. y cualquier otra heurística de diseño del software con-
ducirá a sistemas y aplicaciones basados en Web más
3Referencia Web fáciles de adaptar, mejorar, probar y utilizar.

Uno fuente volioso de líneasgeneralesprácticos Cuando se crean aplicaciones Web se pueden reutili-
poro el diseño de sitios Web se puede enconbar en zar los métodos de diseño que se utilizan para los siste-
www.ibm.tom/ibm/eas y/design/lower/ mas orientados a objetos estudiados anteriormente en
1060100.html este libro. La hipermedia define «objetos» que interac-
túan mediante un protocolo de comunicación algo simi-
lar a la mensajería. De hecho, la notación de diagramas

527

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

propuesta por UML (Capítulos 21 y 22) puede adaptar- Una vez que se ha especificadouna plantilla,cualquierpar-
se y utilizarse durante las actividades de diseño de las te de una estructura hipermedia que se acopla a esta plantilla
WebApps.Además, se han propuesto otros hipermedios se podrá generar o actualizar automáticamente llamandosola-
de métodos de diseño (por ejemplo, [ISA95], [SCH96]). mente a la plantilla con datos relevantes [para dar cuerpo al
esquema]. La utilización de plantillas constructivas depende
implícitamentedel contenido separadode los documentoshiper-
media, de la especificación y de su presentación: los datos fuen-
te se organizan en la estructura del hipertexto tal y como se
especifica en la plantilla

Reglas de oro. Las aplicaciones hipermedia inte- 29.5.1. Diseño arquitectónico www.elsolucionario.net
ractivas (WebApps) llevan construyéndose ya hace una El diseño arquitectónico para los sistemas y aplicacio-
década. Durante ese tiempo, los diseñadores han desa- nes basados en Web se centra en la definición de la
rrollado un conjunto de heurísticas de diseño (reglasde estructura global hipermedia para la WebApp, y en la
oro)que se podrán volver a aplicar durante el diseño de aplicación de las configuraciones de diseño y plantillas
aplicaciones nuevas. constructivas para popularizar la estructura (y lograr la
reutilización). Una actividad paralela, llamada diseño
Configuracionesde diseño. Como se ha destacado del contenido6,deriva la estructura y el formato deta-
anteriormente en este libro, las configuracionesde dise- llados del contenido de la información que se presenta-
ño son un enfoque genérico para resolver pequeños pro- rá como parte de la WebApp.
blemas que se pueden adaptar a una variedad más amplia
de problemas específicos. En el contexto de las la mopria de las estructuras de las WebApps
WebApps, las configuraciones de diseño se pueden apli-
car no solo a los elementos funcionales de una aplica- simplemente aparecen. Evite esto trampa. Estoblezco
ción, sino también a los documentos, gráficos y estética el diseña estructuralde la WebApp explicitamente
general de un sitio Web.
antes de empezar a desarrollar los detalles de la pógina
Plantillas.Las plantillas se pueden utilizar para pro- y de la navegación.
porcionar un marco de trabajo esquemático de cualquier
configuración de diseño o documento a utilizar dentro Estructuras de las WebApps
de una WebApp. Nanard y Kahn [NAN98] describen La estructura arquitectónica global va unida a las metas
este elemento de diseño reutilizable de la siguiente establecidas para una WebApp, al contenido que se va
manera: a presentar, a los usuarios que la visitarán y a la filoso-
fía de navegación (Sección 29.5.3) establecidos. Cuan-
do el encargado de la arquitectura va a realizar el diseño
de una WebApp típica puede elegir entre cuatro fuen-
tes diferentes [POW98].

¿Cuáles son las opciones
disponibles para el diseño de
una WebApp?

Lineal Lineal con flujo Lineal Las estructuras lineales (Fig. 29.3) aparecen cuan-
opciona I con desviaciones do es común la sucesión predecible de interacciones
(con alguna variación o diversificación). Un ejemplo
FIGURA 29.3.Estructuras lineales. clásico podría ser la presentación de un manual de usua-
rio en la que las páginas de información se presentan
con gráficos relacionados, vídeos cortos o sonido solo
después de haber presentado un prerrequisito. La suce-
sión de presentación del contenido queda predefinida y
se puede decir que, generalmente, es lineal. Otro ejem-
plo podría ser la sucesión de una entrada de pedido de
un producto donde se tenga que especificar la informa-
ción específica en un orden específico. En tales casos,

El diseño del contenido es una actividad no técnica que llevan a
cabo redactores publicitarios, artistas, diseñadores gráficos y otros
que generan el contenido de las WebApps. Para más información,

véase IDlN98) y \LYN99].

www.elsolucionario.net
.

CAPÍTULO 29 INGENIERfA WEB

las estructuras que se muestran en la Figura 29.3 son las del extremo izquierdode lajerarquía puede tener enlaces
adecuadas. A medida que el contenido y el procesa- de hipertexto que lleven al contenido que existe en medio
miento crecen en complicación, el flujo puramente line-
al que se muestra a la derecha da como resultado de la rama derecha de la estructura. Sin embargo, debería
estructuras lineales más sofisticadas en las que se pue-
de invocar el contenido alternativo, o en donde tiene de destacarse que aunque dicha rama permita una nave-
lugar una desviación para adquirir un contenido com- gación rápida por el contenidode la WebApp, puede ori-
plementario (la estructura se muestra a la derecha en la ginar también confusiónpor parte del usuario.
Fig. 29.3).
El ocoplomiento es un temo engoñoso poro

lo orquiteciurode los WebApps. Por un lodo, focilita
lo novegoción. Pero, por otro, tambiénpuede hocer
que el usuorio use pierdo». No rehogo conexiones

horizontales dentro de uno jerorquío.

FIGURA 29.4. Estructura reticular. FIGURA 29.5. Estructuras jerárquicas. www.elsolucionario.net

Las estructuras reticdares (Fig. 29.4) son una opción Una estructura en red o de «web pura» (Fig. 29.6)
arquitectónica que puede aplicarse cuando el contenido se asemeja en muchos aspectos a la arquitectura en evo-
de la WebApp puede ser organizado categóricamenteen lución para los sistemas orientados a objetos. Los com-
dos dimensiones (o más). Por ejemplo,consideremosuna ponentes arquitectónicos (en este caso las páginas Web)
situación en la que un sitio de comercio electrónicoven- se diseñan de forma que pueden pasar el control
de palos de golf. La dimensión horizontal de la retícula (mediante enlaces de hipertexto) a otros componentes
representa el tipo de palo en venta (por ejemplo, made- del sistema. Este enfoque permite una flexibilidad de
ras, hierros,wedges, putters). La dimensión vertical repre- navegación considerable, aun cuando puede resultar
senta la oferta proporcionada por los fabricantesde palos confuso para el usuario.
de golf. De aquí que un usuario pueda navegar por la retí-
cula horizontalmente para encontrar la columna de los
putters, y recorrer la columna para examinar las ofertas
proporcionadas por los vendedores de putters. Esta arqui-
tectura WebApp es de utilidad solo cuando se encuentra
un contenido muy regular [POW98].

"*C%V E

Las estructuras reticulares funcionan bien cuando
el contenido puede organizarse categóricamente
en dos dimensiones o más.

Las estructurasjerúrquicas (Fig. 29.5) son sin duda la FIGURA 29.6. Estructura en red o (cweb pura)).
arquitectura WebApp más común.A diferencia de la divi-
sión de jerarquías de software estudiadas en el Capítulo Las estructuras arquitectónicas estudiadas en los
14, que fomentan el flujo de control solo a lo largo de las párrafos anteriores se pueden combinar para formar estruc-
ramas verticales de la jerarquía, se podrá diseñar una
estructurajerárquica de la WebApp para posibilitar (por
medio de la ramificación de hipertexto) el flujo de con-
trol en horizontal atravesando las ramas verticales de la
estructura. Por tanto, el contenido presentado en la rama

529

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

turas compuestas. La arquitectura global de una WebApp Tamiz: una configuración que va guiando al usuario www.elsolucionario.net
puede ser jerárquica, pero parte de la estructura puede a través de una serie de opciones (decisiones) con el
exhibir características lineales, mientras que otra parte de fin de llevar al usuario a un contenido específico e
la arquitectura puede confeccionarse en red. La meta del indicado por la sucesión de opciones elegidas o deci-
diseñador arquitectónico es hacer corresponderla estruc- siones tomadas.
tura de la WebApp con el contenido que se va a presen-
tar y con el procesamiento que se va a llevar a cabo. Vecindario: una configuración que abarca un marco
de navegación uniforme por todas la páginas Web
Patrones de diseño para permitir que un usuario tenga una guía de nave-
Como se ha destacado anteriormente en este mismo gación consecuente independientemente de la loca-
libro, los patrones de diseño son un buen método para lización de la WebApp.
resolver pequeños problemas que pueden adaptarse a
una variedad mucho más amplia de problemas especí- Las configuraciones de diseño de hipertexto aue se
ficos. En el contexto de los sistemas y aplicacionesbasa- han descrito anteriormente se pueden rekilizar a medi-
dos en Web, los patrones de diseño pueden aplicarse en da que el contenido va adquiriendo el formato que per-
el nivel jerárquico, nivel de componentes y nivel de mitirá la navegación a través de una WebApp.
hipertexto (de navegación).
29.5.2. Diseño de navegación
Enlos Copitulos 14 y 22 se puede sncontror mbs
Una vez establecida una arquitectura de WebApp, una
informa¿& sobre las configuracionesde diseh. vez identificados los componentes (páginas, guiones,
applets y otras funciones de proceso) de la arquitectu-
Cuando dentro de una WebApp se requiere la fun- ra, el diseñador deberá definir las rutas de navegación
cionalidad del proceso de datos, pueden aplicarse los que permitan al usuario acceder al contenido y a los ser-
patrones de diseño arquitectónicas a nivel de compo- vicios de la WebApp. Para que el diseñador pueda lle-
nentes propuestas por [BUS96], [GAM95] y otros. Los varlo a cabo, debe (1) identificar la semántica de la
patrones de diseño a nivel de hipertexto se centran en navegación para diferentes usuarios del sitio; y (2) defi-
el diseño de las características de navegación que per- nir la mecánica (sintaxis) para lograr la navegación.
miten al usuario moverse por el contenido de la WebApp
fácilmente. Entre muchos de los patrones de diseño de Generalmente una WebApp grande tendrá una varie-
hipertexto propuestos en literatura sobre este tema se dad de roles de usuarios diferentes. Por ejemplo, los
encuentran los siguientes [BER98]: roles podrían ser el de visitante, cliente registrado o
cliente privilegiado. Cada uno de estos roles se pueden
Ciclo: una configuración que devuelve al usuario al asociar a diferentes niveles de acceso al contenido y de
nodo de contenido visitado anteriormente. servicios diferentes. Un visitante puede tener acceso
sólo a un contenido limitado, mientras que un cliente
regla registrado puede tener acceso a una variedad mucho
más amplia de información y de servicios. La semán-
Anillo de Web: una configuración que implementa tica de la navegación de cada uno de estos roles sería
un «gran ciclo que enlaza hipertextos enteros via- diferente.
jando por un tema» [BER98].
Contorno:un patrón que aparece cuando varios ciclos El diseñador de WebApps crea una unidad semánti-
inciden en otro, permitiendo navegar por rutas defi- ca de navegación (USN) para cada una de las metas aso-
nidas por los ciclos. ciadas a cada uno de los roles de usuario [GNA99]. Por
Contrapunto: un patrón que añade comentarios de ejemplo, un cliente registrado puede tener seis metas
hipertexto interrumpiendo la narrativa del contenido diferentes, todas ellas con un acceso a información y
para proporcionarmás información o más indagación. servicios diferentes. Para cada meta se crea una USN.
Mundo de espejo: el contenido se presenta utilizando Gnaho y Larcher [GNA99] describen la USN de la
diferentes hilos narrativos, cada uno con un punto de siguiente manera:
vista o perspectiva diferente. Por ejemplo, el conte-
nido que describe una computadora personal podría La estructura de una USN se compone de un conjunto de
permitir al usuario seleccionar una narrativa «téc- subestructuras de navegación que llamarnosformas de nave-
nica» o «no técnica» que describa la máquina. gación [WoN (Ways of navigating)]. Una WoN representa
la mejor forma de navegación o ruta para que usuarios con
ciertos perfiles logren su meta o submeta deseada. Por tan-
to, el concepto de WoN se asocia al concepto de Perfil de
Usuario.

La estructura de una WoN se compone de un conjuntode
nodos de navegación (NN) relevantes conectados a enlaces
de navegación, entre los que algunas veces se incluyen las
USNs. Eso significa que las USNs pueden agregarse para
formar una USN de nivel superior, o anidarse en cualquier
nivel de profundidad.

530

www.elsolucionario.net CAPfTULO 29 INGENIERfA WEB
.

@& do, la sofisticación de las capacidades, los servicios de www.elsolucionario.net
procesamiento y el beneficio global de la WebApp en
CLAVE sí, una interfaz con un diseño pobre decepcionará al
usuario potencial y podrá de hecho hacer que el usua-
Una USN se compone de un coniunto de subestructuras rio se vaya a cualquier otro sitio. Dado el gran volumen
de navegación llamadas ((formas de navegación)) (WoN). de WebApps que compiten virtualmente en todas las
Una USN representa una meta de navegación específica áreas temáticas, la interfaz debe «arrastrar» inmediata-
para un tipo específico de usuario. mente al usuario potencial. Nielsen y Wagner [NIE96]
sugieren unas cuantas líneas generales y sencillas en el
Durante las etapas iniciales del diseño de navega- rediseño de una WebApp:
ción, para determinar una o más WoNs para cada meta
de usuario, se evaluará la estructura de la WebApp Probabilidad de que los errores del servidor, incluso
(arquitectura y componentes). Como se ha destacado los más pequeños, hagan que el usuario abandone el
anteriormente, una WoN identifica los nodos de nave- sitio Web y busque información y servicios en algún
gación (por ejemplo, páginas Web), y entonces los enla- otro sitio.
ces que hacen posible la navegación entre ellos. La WoN
entonces se organiza en USNs. ¿Cuáles son algunas
de las líneas generales
A medida que avanza el diseño, se va identificando la básicas para el diseño
mecánica de cada enlace de navegación. Entre otras de la interfaz de un sitio Web?
muchas opciones se encuentran los enlaces basados en
texto, iconos, botones, interruptores y metáforas gráficas. La velocidad de lectura del monitor de una compu-
El diseñadordeberá elegir los enlaces de navegación ade- tadora es aproximadamente un 25 por 100más lento
cuados para el contenido y consecuentescon la heurísti- que leer una copia impresa. Por tanto, no hay que obli-
ca que conduce al diseño de una interfaz de alta calidad. gar al usuario a leer cantidades voluminosas de texto,
particularmente cuando el texto explica la operación
Además de elegir la mecánica de navegación,el dise- de la WebApp o ayuda a navegar por la red.
ñador también deberá establecer las convencionesy ayu-
das adecuadas. Por ejemplo, los iconos y los enlaces Evite los símbolos «bajo construcción» -levantan
gráficos deberán tener un aspecto «clickable (capacidad expectación y provocan un enlace innecesario que
de accederse)» con los bordes biselados, y dar así una seguramente sea decepcionante-.
imagen en tres dimensiones. La realimentación visual
o de sonido se deberá diseñar para proporcionar al usua- Los usuarios prefieren no tener que recorrer la pan-
rio una indicación de que se ha elegido una opción de talla. Dentro de las dimensiones normales de una
navegación. Para la navegación basada en texto, se debe- ventana del navegador se deberá incluir información
rá utilizar el color que indica los enlaces de navegación importante.
y proporcionar una indicaciónde los enlaces por los que
se ha navegado. Estas son solo unas pocas convencio- Los menús de navegación y las barras de cabecera se
nes de las docenas que hacen que la navegación por la deberán diseñar consecuentemente y deberán estar
red sea agradable. Además de las convenciones, en este disponibles en todas las páginas a las que el usuario
punto también se deberán diseñar ayudas de navegación tenga acceso. El diseño no deberá depender de las fun-
tales como mapas de sitios, tablas de contenidos, meca- ciones del navegador para ayudar en la navegación.
nismos de búsqueda y servicios dinámicos de ayuda
La estética nunca deberá sustituir la funcionalidad.
29.5.3. D i s e ñ o de la interfaz Por ejemplo, un botón sencillo podría ser una opción
de navegación mejor que una imagen o icono esté-
Los conceptos, principios y métodos de diseños de inter- ticamente agradables, pero vagos cuya intención no
faz que se presentaron en el Capítulo 15 son todos apli- es muy clara.
cables al diseño de interfaces de usuario para WebApps.
Sin embargo, las características especiales de los siste- 3Referencia We6
mas y aplicaciones Web requieren otras consideracio-
nes adicionales. Uno de los mejores grupos de recursos de usabilidad
de la Web ha sido recogido por el Grupo de Usabiiidad,
con los sitios y se puede encontrar en la dirección
www.usability.com/umi-links.htm

La interfaz de usuario de una WebApp es la «primera Las opciones de navegación deberán ser obvias,
impresión».Independientemente del valor del conteni- incluso para el usuario casual. El usuario deberá bus-
car la pantalla para determinar cómo enlazar con otro
contenido o servicio.

531

hwttwp:w//li.berlesroial-uucniiovenrasirtiaor.ian.ebltogspot.com

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

Una interfaz bien diseñada mejora la percepción de las interfaces WebApp de usuario está fuera
del contenido o de los servicios del usuario que pro- del ámbito de este libro. Los lectores interesados
porciona el sitio Web. No tiene que ser necesaria- pueden consultar [SAN96], [FLE98], [ROS98], o
mente deslumbrante, pero deberá estar siempre bien [LYN99] entre los cientos de ofertas que existen
estructurada y ergonómica. Un estudio completo como guía.

En el Capítulo 17,se destacó que las pruebas son el pro- ces de navegación (Sección 29.5.2) son revisados www.elsolucionario.net
ceso de ejercitar el software con la intención de encon- para asegurar su correspondencia con los especifi-
trar (y por último corregir) los errores. Esta filosofía cados en cada USN del rol de usuario.
fundamentalno se cambiará para el caso de las WebApps.
De hecho, dado que los sistemas y aplicaciones basados 3. Se aplican pruebas de unidad a los componentes de
en Web residen en una red e interoperan con muchos sis- proceso seleccionados y las páginas Web. Cuando
temas operativos diferentes, navegadores, plataformas de lo que se tiene en consideración es el tema de las
hardware, y protocolos de comunicación,la búsqueda de WebApps el concepto de unidad cambia. Cada una
errores representa un reto significativopara los ingenie- de las páginas Web encapsulará el contenido,los enla-
ros Web. ces de navegación y los elementos de procesamiento
(formularios, guiones, applets). No siempre es posi-
¿Qué pasos hay que seguir ble o práctico comprobar cada una de las caractens-
para la comprobación de una ticas individualmente. En muchos casos, la unidad
WebApp? comprobable más pequeña es la página Web. A dife-
rencia de la comprobación de unidades de software
El enfoque de las pruebas de las WebApps adopta los convencional, que tiende a centrarse en el detalle
principios básicos de todas las pruebas del software (Capí- algorítmico de un módulo y los datos que fluyen por
tulo 17) y aplica estrategias y tácticas que ya han sido la interfaz del módulo, la comprobación por páginas
recomendadas para los sistemasorientadosa objetos (Capí- se controla mediante el contenido, proceso y enla-
tulo 23). Este enfoque se resume en los pasos siguientes: ces encapsulados por la página Web.
1. El modelo de contenidode la WebAppes revisadopara
tos esírategios de integmcii se abarcan
descubrir errores.Esta actividad de <<prueba»se ase- en los Capítulos 18 y 23.
meja en muchos aspectos a la de un corrector orto-
gráfico de un documento escrito. De hecho, un sitio 4. Se construye la arquitectura, se realizan las pruebas
Web grande tendrá la capacidad de construir un lis- de integración. La estrategia para la prueba de inte-
tado de los servicios de correctores profesionales para gración depende de la arquitecturaque se haya elegido
descubrir errores tipográficos, errores gramaticales, para la WebApp. Si la WebApp se ha diseñadocon una
errores en la consistencia del contenido, errores en estructurajerárquica lineal,reticular o sencilla,es posi-
representaciones gráficas y de referencias cruzadas. ble integrar páginas Web de una manera muy similar
a como se integran los módulos del software conven-
para los que cional. Sin embargo, si se utiliza una jerarquía mez-
se sabe qué clada o una arquitectura de red (Web), la prueba de
particular, integración es similar al enfoqueutilizado para los sis-
PPS),Y se temas OO. La comprobación basada en hilos (Capí-
tulo 23) se puede utilizar para integrar un conjunto de
2. El modelo de diseño para la WebApp es revisado páginas Web (se puede utilizar una USN para definir
para descubrir errores de navegación. Los casos el conjunto adecuado) que se requiere para responder
prácticos derivados como parte de la actividad de a un sucesode usuario. Cada hilo se integra y seprueba
análisis permite que un ingeniero Web ejercite cada individualmente.La prueba de regresión se aplicapara
escenario de utilización frente al diseño arquitectó- asegurar que no haya efectos secundarios. La com-
nico y de navegación. En esencia, estas pruebas no probación de agrupamientos integra un conjunto de
ejecutables ayudan a descubrir errores en la nave- páginas colaborativas (determinadasexaminando los
gación (por ejemplo, un caso en donde el usuario no casos prácticos y la USN). Los casos de prueba se deri-
pueda leer un nodo de navegación).Además, los enla- van para descubrirerrores en las colaboraciones.

5. La WebApp ensamblada se prueba para conseguir
una funcionalidad global y un contenido. Al igual
que la validación convencional, la validación de los

532

www.elsolucionario.net
.

CAPfTULO 29 INGENIERfA WEB

sistemas y aplicaciones basados en Web se centra en cubrir los errores asociados con todas y cada una de
acciones visibles del usuario y en salidas reconoci- las configuraciones posibles.
bles para el usuario que procedan del sistema. Para
ayudar en la derivación de las pruebas de validación, 7. La WebAppse comprueba con una población de usua-
las pruebas deberán basarse en casos prácticos. El riosfinales controlada y monitorizada. Se selecciona
caso práctico proporciona un escenario con una pro- un grupo de usuarios que abarque todos los roles posi-
babilidad alta de descubrir errores en los requisitos bles de usuarios. La WebApp se pone en práctica con
de interacción del usuario. estos usuarios y se evalúan los resultados de su inte-
racción con el sistema para ver los errores de conte-
6. La WebApp se implementa en una variedad de con- nido y de navegación, los intereses en usabilidad,
figuraciones diferentes de entornos y comprobar así compatibilidad,fiabilidady rendimiento de la WebApp.
la compatibilidad con cada configuración. Se crea
una matriz de referencias cruzadas que define todos Dado que muchas WebApps están en constante evo-
los sistemas operativos probables, plataformas de lución, el proceso de comprobación es una actividad
hardware para navegadores7y protocolos de comu- continua, dirigida por un personal de apoyo a la Web
nicación. Entonces se llevan a cabo pruebas para des- que utiliza pruebas de regresión derivadas de pruebas
desarrolladas cuando se creó la WebApp.

29.7 P R C ) B L E M A S T I h N ciplinas.. .»Aun cuando los autores están absolutamente www.elsolucionario.net
en lo cierto, los «renacentistas»no disponen de muchas
Dada la inmediatez de las WebApps, sería razonable provisiones, y dado las exigencias asociadas a los pro-
preguntarse: ¿necesito realmente invertir tiempo esfor- yectos importantes de desarrollo de WebApps,el conjun-
zándome con la WebApp? ¿no debería dejarse que la to de conocimientos diversos necesario podrá distribuirse
WebApp evolucionarade forma natural, con poca o nin- incluso mejor dentro del equipo de IWeb.
guna gestión explícita? Muchos diseñadores de Webs
optarían por gestionar poco o nada, pero eso no hace Los equipos de IWeb pueden organizarse de forma
que estén en lo cierto. muy similar a como se organizan los equipos de softwa-
re del Capítulo 3. Sin embargo, pueden existir diferen-
La ingeniería Web es una actividad técnica com- cias entre los participantes y sus roles. Entre los muchos
plicada. Hay muchas personas implicadas, y a menu- conocimientos que deben distribuirse por los miembros
do trabajando en paralelo. La combinación de tareas del equipo IWeb se encuentran los siguientes: ingeniería
técnicas y no técnicas que deben de tener lugar (a tiem- del software basada en componentes,realización de redes,
po y dentro del presupuesto) para producir una diseño arquitectónicoy de navegación,lenguajes y están-
WebApp de alta calidad representa un reto para cual- dares de Intemet, diseño de interfacespara personas, dise-
quier grupo detprofesionales. Con el fin de evitar cual- ño gráfico, disposición del contenido y pruebas de las
quier confusión, frustración y fallo, se deberá poner WebApps. Los roles' siguientes deberán ser distribuidos
en acción una planificación, tener en cuenta los ries- entre los miembros del equipo IWeb:
gos, establecer y rastrear una planificación temporal
y definir los controles. Estas son las actividades clave ¿Qué papeles juegan
que constituyen lo que se conoce como gestión de pro- las personas que forman
yectos. parte del equipo de IWeb?

los actividodes asociadoscon lo gestión de proyectos Desarrolladoresy proveedoresde contenido.Dado
de soíiwarese esíudion en lo Porte Segunda que las WebApps son controladas inherentemente por
de este libro. el contenido, el papel de los miembros del equipo IWeb
se centra en la generación y/o recolección del conteni-
29.7.1. El equipo de IWEB

La creación de una buena aplicación Web exige un amplio
abanico de conocimientos. Tilley y Huang [TIL99] se
enfrentan a este tema cuando afirman: «Hay muchos
aspectos diferentes en relación con el softwarede aplica-
ciones [Web] debido al resurgimiento del renacentista,
aquel que se encuentracómodo trabajando en varias dis-

7 Los navegadores son excelentes para implementar sus propias inter- Estos roles se han adaptado de Harsen y sus colaboradores [HAN99].
pretaciones ((estándar. ligeramente diferentes de HTML y Javascript.
Para un estudio de temas de compatibilidad, véase www.browser-
caps.com.

533

www.elsolucionario.net

INGENiERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO .

do. Retomando la idea de que el contenido abarca un el desarrollo e implementación de normas para el www.elsolucionario.net
amplio abanico de objetos de datos, los diseñadores y funcionamiento de la WebApp;
proveedores del contenido pueden proceder de diver-
sos planos de fondo (no de software). Por ejemplo, el el establecimiento de los procedimientos de soporte
personal de ventas o de marketing puede proporcionar y realimentación;
información de productos e imágenes gráficas: los pro-
ductores de medios pueden proporcionar imagen y soni- los derechos de acceso y seguridad de la implemen-
do; los diseñadores gráficospueden proporcionar diseños tación;
para composiciones gráficas y contenidos estéticos; los
redactores publicitarios pueden proporcionar conteni- la medición y análisis del tráfico del sitio Web;
do basado en texto. Además, existe la posibilidad de
necesitar personal de investigación que encuentre y dé la coordinación de los procedimientos de control de
formato al contenido externo y lo ubique y referencie cambios (Sección 29.7.3);
dentro de la WebApp.
la coordinación con especialistas de soporte.
Editores de Web. El contenido tan diverso generado
por los desarrolladores y proveedores de contenido debe- El administrador también puede estar involucrado
rá organizarse e incluirse dentro de la WebApp. Además, en las actividades técnicas realizadas por los ingenie-
alguien deberá actuar como conexión entre el personal ros de Web y por los especialistas de soporte.
técnico que diseña la WebApp y los diseñadores y pro-
veedores del contenido. Esta función la lleva a cabo el 29.7.2. Gestión del proyecto
editor de Web, quien deberá entender la tecnología tan-
to del contenido como de la WebApp en donde se inclu- En la Parte Segunda de este libro se tuvieron en consi-
ye el lenguaje HTML (o ampliaciones de generaciones deración todas y cada una de las actividades global-
posteriores, tal como XML), la funcionalidad de bases mente llamadas gestión de proyectos'. Las métricas de
de datos y guiones, y la navegación global del sitio Web. procesos y proyectos, la planificación de proyectos (y
estimación), el análisis y gestión de riesgos, la planifi-
Ingeniero de Web. Un ingeniero Web cada vez se cación temporal y el rastreo, SQA y CGS, se estudia-
involucra más con la gran cantidad de actividades del ron en detalle. En teoría, la mayoría de las actividades
desarrollo de una WebApp entre las que se incluyen la de gestión de proyectos, si no todas, estudiadas en capí-
obtención de requisitos, modelado de análisis, diseño tulos anteriores,se aplican a los proyectos de IWeb. Pero
arquitectónico, de navegación y de interfaces, imple- en la práctica, el enfoque de IWeb para la gestión de
mentación de la WebApp y pruebas. El ingeniero de Web proyectos es considerablemente diferente.
también deberá conocer a fondo las tecnologías de com-
ponentes, las arquitecturas cliente/servidor, HTML/XML, En primer lugar, se subcontrata un porcentaje sus-
y las tecnologíasde bases de datos; y deberá tener cono- tancial" de WebApps a proveedores que (supuesta-
cimiento del trabajo con conceptos de multimedia, pla- mente) son especialistas en el desarrollo de sistemas y
taformas de hardware/software, seguridad de redes y aplicaciones basados en Web. En tales casos, un nego-
temas de soporte a los sitios Web. cio (el cliente) solicita un precio fijo para el desarrollo
de una WebApp a uno o más proveedees, evalúa los
Especialistasde soporte.Este papel se asigna a la per- precios de los candidatosy selecciona un proveedor para
sona (personas) que tiene la responsabilidad de continuar hacer el trabajo. Pero, ¿qué es lo que busca la organi-
dando soportea la WebApp. Dado que las WebApps están zación contratista?, ¿cómo se determina la competen-
en constanteevolución,el especialistade soportees el res- cia de un proveedor de WebApps?, ¿cómo se puede
ponsable de las correcciones, adaptaciones y mejoras del saber si un precio es razonable?, ¿qué grado de planifi-
sitio Web, donde se incluyen actualizaciones del conteni- cación, programación temporal, y valoración de riesgos
do, implementación de productos y formularios nuevos, se puede esperar a medida que una organización (y su
y cambios del patrón de navegación. subconstratista) se va embarcando en un desarrollo
importante de WebApps?
Administrador. Se suele llamar Wehmaster, y es el
responsable del funcionamiento diario de la WebApp, En segundo lugar, el desarrollo de WebApps es una
en donde se incluye: área de aplicación relativamente nueva por tanto se pue-
den utilizar pocos datos para la estimación. Hasta la
fecha, no se ha publicado virtualmente ninguna métri-
ca de IWeb. De hecho, tampoco han surgido muchos
estudios sobre lo que esas métricas podrían ser. Por tan-
to, la estimación es puramente cualitativa -basada en

9 Se recomienda que lectores no familiarizados con los conceptos l o Aun cuando los datos de industria fiables son dificiles de encon-
básicos de gestión de proyectos revisen en este momento el Capí- trar, es seguro decir que este porcentaje es considerablemente mayor
tul0 3 . que el que se encuentra en el trabajo del software convencional.

534

www.elsolucionario.net CAPfTUI.0 29 INGENIERfA WEB
.

experiencias anteriores con proyectos similares-. Pero una WebApp con éxito. Esta información deberá de www.elsolucionario.net
casi todas las WebApps tienen que ser innovadoras documentarseen una especificacióndel producto.
-ofreciendo algo nuevo y diferente a aquellos que la 2. Se deberá desarrollar internamente un diseño apro-
utilizan-. De aquí que la estimación experimental,aun- ximado de la WebApp. Obviamente una persona
que sea Útil, está abierta a errores considerables. Por experta en el desarrollo de WebApps creará un diseño
consiguiente, ¿cómo se derivan estimaciones fiables?, completo, pero puede ahorrar tiempo y dinero iden-
¿con qué grado de seguridad pueden cumplirse los pro- tificando el aspecto e interacción general de la
gramas temporales definidos? WebApp para el proveedor de subcontratación (esto
siempre puede modificarse durante las etapas preli-
En tercer lugar, el análisis de riesgos y la programa- minares del proyecto). El diseño deberá incluir la indi-
ción temporal se predican bajo un entendimiento claro cación del proceso interactivo que se va a llevar a
del ámbito del proyecto. Y sin embargo, la característi- cabo (por ejemplo, formularios,entrada de pedidos).
ca de «evolución continua» tratada en la Sección 29.1 3. Se deberá desarrollar unaplanijicacióntemporal apro-
sugiere que el ámbito de la WebApp sea fluido. ¿Cómo ximada del proyecto, incluyendo no solo lasfechas
pueden controlar los costes la organización contratista finales de entrega,sino tambiénlasfechas hito (signi-
y el proveedor subcontratado?, y ¿cómo pueden plani- ficativas). Los hitos deberán adjuntarse a las versiones
ficar el momento en que es probable que los requisitos de entrega posibles a medida que avanza el proyecto.
cambien drásticamente a lo largo del proyecto?, ¿cómo 4 . Se deberá identificar el grado de supervisión e inte-
se puede controlar el cambio del ámbito?, y lo que es racción del contratista con el proveedor. Deberá
más importante, dado su naturaleza ¿deberán contro- incluirse el nombre del contacto del proveedor y la
larse los sistemas y aplicaciones basados en Web ? identificación de la responsabilidad y autoridad del
contacto, la definición de los puntos de revisión de
Llegado a este punto de gestión de proyectos para calidad a medida que el desarrollo va avanzando, y
WebApps, las preguntas que se han formulado por las la responsabilidad de los proveedores en relación con
diferencias destacadas anteriormente no son fáciles de la comunicación entre organizaciones.
responder. Sin embargo, merece la pena tener en con-
sideración una serie de líneas generales. Toda la información desarrollada en los pasos ante-
riores deberá de organizarse en una solicitud de opcio-
Inicio de un proyecto. Aun cuando la subcontrata- nes que se transmite a los proveedores candidatos".
ción sea la estrategia elegida para el desarrollo de
WebApps, una organización deberá realizar una serie Selección entre los proveedores de subcontrata-
de tareas antes de buscar el proveedor de subcontrata- ción candidatos. En los últimos años han surgido miles
ción para hacer el trabajo. de compañías de «diseñoWeb» para ayudar a las empre-
sas a establecer una presencia y/o implicación Web en
1. Muchas de las actividades de análisis tratadas en la el comercio electrónico. Muchas han llegado a tener
Sección 29.3 se deberán realizar internamente. Se adicción por el proceso IWeb, mientras que otras muchas
identifica el público de la WebApp; se confecciona un se asemejan a los intrusos informáticos (hackers).Con
listado de aquellos con intereses internos en la objeto de seleccionar el desarrollador de Web candida-
WebApp; y se definen y revisan las metas globales de to, el contratistadeberá llevar a cabo una diligencia obli-
la WebApp; se especifica tanto la información como gada: (1) entrevistar a los clientes antiguos para
los servicios que se van a proporcionaren la WebApp; determinar la profesionalidad del proveedor de Web, la
se destacan los sitios Web rivales, y se definen las habilidad de cumplir los compromisosde horarios y cos-
«medidas» cuantitativas y cualitativas para obtener tes, y la habilidad de comunicarseeficazmente; (2) deter-
minar el nombre del ingenierojefe de Web del proveedor
de proyectos anterior con éxito (y después cerciorarse
de que esta persona se vea obligada mediante contrato
a su implicación en el proyecto), y (3) examinar cuida-
dosamente las muestras de trabajo del proveedor simi-

I I Si el trabajo de desarrollo de la WebApp e s dirigida por un grupo
interno, nada cambia. El proyecto se inicia de la misma manera.

535

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

lares en aspecto e interacción (y en área de negocios) a «temporalmente».Este enfoque hace posible que el equi- www.elsolucionario.net
la WebApp que se va a contratar. Antes incluso de que po de la WebApp trabaje sin tener que aceptaruna conien-
se vaya a establecer la oferta, una reunión cara a cara te continua de cambios,pero reconociendo la característica
puede proporcionar una buena impresión para que el de evolución continua de la mayoría de las WebApps.
contratista y el proveedor conecten bien.
Las líneas generales sugeridas anteriormente no pre-
Evaluación de la validez de las ofertas de precios tenden ser un recetario a prueba de tontos para WebApps
y de la fiabilidad de las estimaciones.Dado que exis- puntuales y con una producción a un coste bajo. Sin
ten muy pocos datos históricos y el ámbito de las embargo, ayudarán tanto al contratista como al provee-
WebApps es notoriamente fluido, la estimación es inhe- dor a iniciar el trabajo suavemente con unos conoci-
rentemente arriesgada. Por esta razón algunos provee- mientos mínimos.
dores incorporarán márgenes sustanciales de seguridad
en las ofertas de precios de un proyecto. Evidentemen- 29.7.3. Problemas GCS para la IWEb
te esto es comprensible y adecuado. La pregunta no es Durante la última década, las WebApps han evolucio-
si tenemos la mejor solución para nuestra inversión,sino nado y han pasado de utilizar dispositivos informales
la serie de preguntas que se muestran a continuación: para la difusión de información a utilizar sitios sofisti-
cados para el comercio electrónico. A medida que las
¿Es el coste acordado una buena oferta para propor- WebApps van creciendo en importancia para la super-
vivencia y el crecimiento de los negocios, también cre-
cionar un beneficio directo o indirecto sobre la inver- ce el control de la configuración. ¿Por qué? Porque sin
sión y justificar así el proyecto? controles eficaces cualquier cambio inadecuado en una
WebApp (recordemos que la inmediatez y la evolución
¿Es el proveedor de la oferta una muestra clara de la continua son los atributos dominantes de muchas
WebApps) puede conducir a: (1) una ubicación no auto-
profesionalidad y experiencia requeridos? rizada de la información del producto nuevo; (2) una
funcionalidad errónea y pobremente comprobada que
Si la respuesta es «sí», el precio ofertado es justo. frustra a los visitantes del sitio Web; (3) agujeros de
seguridad que ponen en peligro a los sistemas internos
El grado de gestión del proyecto que se puede espe- de las compañías, y otras consecuencias económica-
rar o realizar. La formalidad asociada con las tareas de mente desagradables e incluso desastrosas.
gestión del proyecto (llevadas a cabo tanto por el provee-
dor como por el contratista) es directamenteproporcional Se pueden aplicar las estrategias generales para la
al tamaño, coste y complejidad de la WebApp. Para pro- gestión de la configuración del software (GCS) descri-
yectos complejos y grandesdeberá desarrollarse una pla- tas en el Capítulo 9, pero las tácticas y herramientas
nificación que defina las tareas del trabajo, los puntos de deberán adaptarse y ajustarse a la naturaleza única de
comprobación, los productos de trabajo de ingeniería, los las WebApps. Cuando se desarrollan tácticas para la
puntos de revisión del cliente y los hitos importantes. El gestión de configuración de las WebApps,deberán tener-
proveedor y el contratista deberán evaluar el riesgo en se en consideración cuatro temas [DAR99]: el conteni-
conjunto,y desarrollar los planes de mitigar, monitorizar do, las personas, la escalabilidad y la política.
y gestionar esos riesgos considerados como importantes.
Los mecanismos para la seguridad de calidad y el control Contenido. Una WebApp normal contiene una gran
de cambios se deberán definir explícitamente al escribir- cantidad de contenido-texto, gráficos, applets, guiones,
se. Y tendrán que establecerse métodos de comunicación archivos de sonido y vídeo, elementos activos de pági-
entre el contratista y el proveedor. nas, tablas, corrientes de datos y muchos más-. El reto
es organizar este mar de contenido en un conjunto razo-
Evaluación de la planificación temporal del desa- nable de objetos de configuración (Capítulo 9). y enton-
rrollo. Dado que las planificacionesde desarrollo de las ces establecerlos mecanismos de controlde configuración
WebApps abarcan un período de tiempo relativamente adecuados para estos objetos. Un enfoque será modelar
corto (normalmente menos de un mes o dos), la plani- el contenido de la WebApp mediante la utilización de téc-
ficación de desarrollo deberá tener un alto grado de gra- nicas convencionales de modelado de datos (Capítulo
nularidad. Es decir, las tareas del trabajo y los hitos 11),adjuntando un conjunto de propiedades especializa-
menores se tendrán que planificar día a día. Esta gra- das a cada objeto. La naturaleza estática y dinámica de
nularidad permite que el contratista y el proveedor reco-
nozcan la reducción del tiempo de planificación antes
de que amenace la fecha de finalización.

Gestión del ámbito. Dado que es muy probable que
el ámbito cambie a medida que avanza el proyecto de la
WebApp, el modelo de proceso deberá ser incremental
(Capítulo 2). Esto permite que el equipo de desarrollo
«congele» el ámbito para poder crear una nueva versión
operativa de la WebApp. El incremento siguientepuede
afrontar los cambios de ámbito sugeridos por una revi-
sión del incrementoprecedente, pero una vez que comien-
za el incremento, el ámbito se congela de nuevo

536

hwttwp:w//l.iberlesroialu-ucniiovenrasritiaor.ian.ebtlogspot.com CAPfTULO 29 INGENIERfA WEB
.

cada objeto y la longevidad proyectada (por ejemplo, en las actividades de gestión y control asociadas con la www.elsolucionario.net
existencia temporal y fija, o un objeto permanente) son IWeb. En algunos casos los diseñadores de WebApps
ejemplos de las propiedades necesarias para establecer se encuentran fuera de la organización TI, dificultando
un enfoque GCS eficaz. Por ejemplo, si se cambia un posiblemente la comunicación. Para ayudar a entender
objeto de contenidocada hora, se dice que tiene una lon-
gevidad temporal. Los mecanismos de control de este la política asociada a IWeb, Dart [DAR991 sugiere las
objeto serán diferentes (menos formales) de los que se
aplicanyaun componente de formularios (objeto perma- siguientes preguntas: ¿quién asume la responsabilidad
nente). de la información en el sitio Web? ¿quién asegura que
los procesos de control de calidad se han llevado a cabo
Es esencialconirolor el cambiodurante los proyectos antes de publicar la información en el sitio Web? ¿quién
Web, aun cuando puede hocene de formo exagerado. es el responsable de hacer los cambios? ¿quién asume
Empiecepor los procedimientosde control de cambio el coste del cambio? Las respuestas ayudarán a deter-
de relativo informalidad Kopihlo 91. lo meto inicialserá minar qué personas dentro de la organización deberán
evitar los efectos de trinquete en cambios incontrolodos. adoptar un proceso de gestión de configuración para las
WebApps.
Personas. Dado que un porcentaje significativo del
desarrollo de las WebApps continúarealizándose depen- La gestión de configuración para la IWeb está toda-
diendo del caso, cualquier persona que esté implicada vía en su infancia. Un proceso convencional de GCS
en la WebApp puede (y a menudo lo hace) crear el con- puede resultar demasiadopesado y torpe. La gran mayo-
tenido. Muchos creadores de contenido no tienen ante- ría de las herramientas GCS no tienen las característi-
cedentes en ingeniería del software y no tienen ningún cas que permiten adaptarse fácilmente a la IWeb. Entre
conocimiento de la necesidad de una gestión de confi- los temas que quedan por tratar se encuentran los
guración. La aplicación crece y cambia de forma incon- siguientes [DAR99]:
trolada.
creación de un proceso de gestión de configuración
Escalabilidad. Las técnicas y controles aplicados a que sea lo suficientemente hábil como para aceptar la
una WebApp pequeña no tienen buena escalabilidad. inmediatez y la evolución continua de las WebApps;
No es muy común que una WebApp sencilla crezca sig-
nificativamente cuando se implementan las intercone- aplicación de mejores conceptos y herramientas de
xiones que existen dentro de los sistemas de gestión de configuración para aquellos que desarro-
información, bases de datos, almacenes de datos y pasa- llan y no están familiarizados con la tecnología;
relas de portales. A medida que crece el tamaño y la
complejidad, los pequeños cambios pueden tener efec- suministro del soporte a los equipos de desarrollo de
tos inalcanzables y no intencionados que pueden ser WebApps distribuidos;
problemáticos. Por tanto, el rigor de los mecanismos de
control de la configuración deberán ser directamente suministro de control en un entorno de cuasipubli-
proporcionales a la escalabilidad de la aplicación. cación, donde el contenido cambia de forma casi con-
tinua;
Política. ¿Quién es el propietario de una WebApp?
Esta pregunta se argumenta en compañías grandes y consecución de la granularidad necesaria para con-
pequeñas, y la respuesta tiene un impacto significativo trolar una gran cantidad de objetos de configuración;

incorporación de la funcionalidad de gestión de con-
figuración en las herramientas IWeb existentes;

gestión de cambios en objetos que contienen enla-
ces con otros objetos.

Estos y otros temas deberán afrontarse antes de que se
disponga-magestión de configuracióneficaz para la k e b .

Se puede argumentar que el impacto de los sistemas y nadas por el contenido y están en continua evolución. La
aplicacionesbasados en Web es el acontecimiento más inmediatez que conduce a su desarrollo,la necesidad pri-
significativo en la historia de la informática. A medida mordial de seguridad al funcionar,y la demanda de esté-
que las WebApps crecen en importancia, el enfoque de tica y la entrega del contenido funcional son otros factores
ingeniería de Web disciplinado ha empezado a evolu- diferenciadores.Durante el desarrollode la WebApp hay
cionar -basado en principios, conceptos, procesos y tres tecnologías que se integran con otras de ingeniería
métodos que se han desarrollado para la ingeniería del del software convencional;desarrollobasado en compo-
software-. nentes, seguridad y lenguajes de notas estándar.

Las WebApps son diferentes de otras categorías de El proceso de ingenieríade Web comienza con la for-
software informático. Son intensivas de red, están gober- mulación -una actividad que identifica las metas y los

537

www.elsolucionario.net

INGENlERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

objetivos de la WebApp-. La planificación estima el probación ejercita la navegación de la WebApp, inten-
coste global del proyecto, evalúa los riesgos asociados tando descubrir errores en la función y el contenido, y
con el esfuerzodel desarrolloy define una programación asegurando mientras tanto que la WebApp funcione
temporal del desarrollo. El análisis establece requisitos correctamente en diferentes entomos. La ingeniería de
técnicos e identificalos objetos del contenidoque se incor- Web hace uso de un modelo de proceso iterativo e incre-
porarán en la WebApp. La actividad de ingeniería incor- mental porque la línea temporal del desarrollo para la
pora dos tareas paralelas: diseño del contenido y diseño WebApp es muy corta. Las actividades protectoras apli-
técnico. La generación de páginas es una actividad de cadas durante el trabajo de la ingeniería del software
construcción que hace un uso extenso de herramientas -SQA, GCS, gestión de proyectos-se aplican a todos
automatizadas para la creación de WebApps, y la com- los proyectos de ingeniería de Web.

[ATK97] Atkins, D., et al., Internet Security: Professional [MUR991 Murugesan, S., WebE Home Page, http://fist- www.elsolucionario.net
Reference, New Riders Publishing, 2.&ed., 1997. serv.macarthur.uws.edu.au./san/WebHome,Julio de 1999.

[BER98] Bemstein, M., «Pattems in Hypertext», Proc. gth [NAN98] Nanard, M., y P. Kahn, «Pushing Reuse in Hyper-
ACM Conf. Hypertext, ACM Press, 1998, pp. 21-29. media Design: Golden Rules, Design pattems and cons-
tructive Templates», Proc. gth ACM conf. On Hypertext
[BRA97] Bradley, N., The Concise SGML Companion,Addi- and Hypermedia, ACM Press, 1998, pp. 11-20.
son-Wesley, 1997.
[NIE96] Nielsen, J., y A. Wagner, «User Interface Design for
[BRE99] Brenton, C., Mastering Network Security, Sybex, the WWWD,Proc. CHI' 96 conference on Human Factors
Inc., 1999. in Computing systems, ACM, Press, 1996, pp. 330-331.

[BUS961 Buschmann, E et al., Pattern-Oriented Software [NOR99] Norton, K., «Applying Cross Functional Metho-
Architecture, Wiley, 1996. dologies to Web Development», Proc. I s t ICSE Works-
hop on Web Engineering, ACM, Los Ángeles, Mayo de
[DAR991 Dart, S., «Containing the Web Crisis Configura- 1995.

tion Managemenb, Proc. Is' ICSE Workshopon Webengi- [OSL99] Olsina, L. et al., «Specifying Quality Characteris-

neering, ACM, Los Ángeles, Mayo de 1999". tics and Attributes for Web Sitesm,Proc. Is' Workshopon

[DIN98] Dinucci, D., M. Giudice y L. Stiles, Elements of Web Engineering, ACM, Los Angeles, Mayo de 1995.
WebDesign: The DesignerS Guide to a New Medium, 2.3
ed., Peachpit Press, 1998. [PAR991 Pardi, W.J., XML in Action, Microsoft Press, 1999.

[GAM95] Gamma, E. et al., DesignPatterns, Addison-Wes- [POW98] Powell, T.A., WebSite engineering, Prentice-Hall,
ley, 1998. 1998.

[GNA99] Gnaho, C., y E Larcher, «A User Centered Me- [PRE98] Pressman, R.S. (moderador), «Can Intemet-Based
thodology for Complex and Customimizable Web Appli- Applications be Engineered?», IEEE Sofmare, Septiem-
cations engineerinp, Proc. 1st ICSE Workshop on Web bre de 1998, pp. 104-110.
engineering, ACM, Los Ángeles, Mayo de 1999.
[ROS981 Rosenfeld, L., y P. Morville, Information Architec-
[HAN991 Hansen, S., Y. Deshpande y S. Murgusan, «A Skills turefor the World Wide Web,O'Reilly & Associates, 1998.
Hierarchy for Web Information system Development»,
Proc. 1"' ICSE Workshop on WebEngineering, ACM, Los [SAN961 Sano, D., Designing Large-Scale Web Sites: A
Ángeles, Mayo de 1999. Visual Design Methodology, Wiley 1996.

[ISA95] Isakowitz, T. et al., «RMM: A Methodology for [SCH96] Schwabe, D., G. Rossi y S. Barbosa, «Systematic
Structured Hypermedia Design», CACM, vol. 38, n." 8, Hypermedia Application Design with OOHDMD,Proc.
Agosto de 1995, pp. 43-44. Hypertext ' 96, pp. 116-128.

[KAE99] Kaeo, M., Designing Network Security, Cisco [SPO98] Spool, J.M., et al., Web Site Usability:A Desig-
Press, 1999. ner's Guide, Morgan Kaufmann Publishers, 1998.

[LOW99] Lowe, D., «Web Engineering or Web Gardening?», [STL99] St. Laurent, S., y E. Cerami, Building XML Appli-
WebNet Journal, vol. 1, n." 2, Enero-Marzo de 1999. cations, McGraw-Hill, 1999.

[LYN99] Lynch, P.J., y S. Horton, Web Style Guide: Basic [TIL99] Tilley, S., y S. Huang, «On the emergence of the
Design Principlesfor Creating WebSites, Yale University Renaissance Software engineer», Proc. 1"' ICSE Workshop
Press. 1999. on the WebEngineering, ACM, Los Angeles, Mayo de 1999.

I2 Los procedimientos del Primer Taller ICSE sobre Ingeniena del %IR-
ware se publican en la red en http://ñstserv.marcarthur.
uws.edu.au/san/icse99-WebE/ICSE99-Web-E-~/default.htm

538

www.elsolucionario.net CAPfTULO 29 INGENIERfA WEB
.

29.1. ¿Existen otros atributos genéricos que diferencien a las 29.10. Realice un análisis del contenido para HogarSegu- www.elsolucionario.net
WebApps de otras aplicaciones de software? Enumere 2 Ó 3. roInc.com o para un sitio Web asignado por su profesor.

29.2. ¿Cómo se juzga la calidad de un sitio Web? Confeccio- 29.11. Sugiera tres «reglas de oro» que servirán como guía en
ne una lista de 10 atributos de calidad prioritarios que consi- el diseño de WebApps.
dere más importantes.
29.12. ¿En qué difiere una configuración de diseño WebApp
29.3. Realice una pequeña investigación y realice un trabajo de una plantilla?
de 2 ó 3 páginas que resuma una de las tres tecnologías que
se destacaron en la Sección 29.1.2. 29.13. Seleccione un sitio Web con el que esté familiarizado
y desarrolle un diseño arquitectónico razonablemente com-
29.4. Utilizando un sitio Web real como ejemplo, ilustre las pleto para el sitio. ¿Qué estructura arquitectónica seleccionó
diferentes manifestaciones del «contenido» de la WebApp. el diseñador del sitio?

29.5. Responda a las tres preguntas de formulación para un 29.14. Haga una investigación breve y escriba 2 ó 3 páginas
sitio Web con el que esté familiarizado. Desarrolle una afir- que resuman el trabajo actual en las configuraciones de dise-
mación de ámbito para el sitio Web. ño de las WebApps.

29.6. Desarrolle un conjunto de perfiles para HogarSegu- 29.15. Desarrolle un diseño arquitectónico para HogarSegu-
roInc.com o un sitio Web asignado por su profesor. roInc.com o para un sitio Web asignado por su instructor.

29.7. Desarrolle una lista completa de metas informativas y 29.16. Utilizando un sitio Web real como ejemplo, desarrolle
aplicables para HogarSeguroInc.com o un sitio Web asigna- una crítica de su interfaz de usuario y haga una recomenda-
do por su profesor. ción que lo mejore.

29.8. Elabore un conjunto de casos de uso para HogarSegu- 29.17. Describa la manera en que una gestión de proyecto para
roInc.com o un sitio Web asignado por su profesor. sistemas y aplicaciones basados en Web difieren de la gestión
de proyecto para el software convencional. ¿En qué se ase-
29.9. ¿En qué difiere el análisis del contenido del análisis fun- meja?
cional y de interacción?

Durante los últimos años se han publicado cientos de libros Menasce y Almeida (CapacisPlanning for WebPerfor-
que tratan uno o más temas de ingeniería de Web, aunque mance: Metrics, Models, and Methods, Prentice-Hall, 1998)
relativamente pocos tratan todos los aspectos. Lowe y Hall tratan la valoración cuantitativa del rendimiento de las
(Hypertext and the Web:An Engineering Approach, Wiley, WepApps. Amoroso (Intrusion Detection: An Introduction to
1999), y Powell [POW98] abarcan razonablemente estos Internet Surveillance, Correlation, Trace Back, Traps, and
temas. Norris, West y Warson (MediaEngineering: A Quide Response, 1ntrusion.Net Books, 1999) proporciona una guía
to Developing Information Products, Wiley, 1997), Navarro detallada para los ingenieros de Web que están especializa-
y Khan (Effective WebDesign: Master the Essentials, Sybex, dos en temas de seguridad. Umar (Application(Re)Enginee-
1998), Fleming y Koman (WebNavigation: Designing the ring: Building Web-Based Applications and Dealing With
User Experience, O'Reilly & Associates, 1998), y Sano Legacies, Rentice-Hall, 1997)estudia estrategias para la trans-
[SAN961 también abarcan aspectos importantes del proceso formación (reingeniería) de sistemas anteriores en aplicacio-
de ingeniería. nes basadas en Web. Mosley (Client Sewer S o f i a r e Testing
on the Desk Top and the Web, Prentice-Hall, 1999) ha escri-
Además de [LYN99], [DIN98] y [SPO98], los siguientes to uno de los mejores libros que estudian los temas de com-
libros proporcionan una guía útil para los aspectos del dise- probación asociados con WebApps.
ño de WebApps tanto técnicos como no:
Haggard (Survival Guide to Web Site Developrnent,
Baumgardt, M., Creative Web Design: Tips and Tricks Microsoft Press, 1998) y Siegel (Secrets of Successful Web
Step by Step, Springer Verlag, 1998. Sites: Project Management on the World Wide Web, Hay-
den Books, 1997) proporcionan una guía para el gestor que
Donnelly, D. et al., Cutting Edge Design: The Next Gene- debe de controlar y hacer un seguimiento del desarrollo de
ration, Rockport Publishing, 1998. WebApps.

Holzschlag, M.E., Web by Design: The Complete Guide, Una amplia variedad de fuentes de información sobre inge-
Sybex, 1998. niería de Web está disponible en Internet. Una lista amplia y
actualizada de referencias en sitios (páginas) web se puede
Niederst, J., y R. Koman, Web Design in a Nutshell: A obtener en http:/www.pressman5.com.
Desktop Quick Reference, O'Reilly & Associates, 1998.

Weinman, L., y R. Prirouz, Click Here: Web Communi-
cation Design, New Riders Publishing, 1997.

539

www.elsolucionario.net
.

www.elsolucionario.net

CAPÍTULO www.elsolucionario.net
.
30
REINGENIERÍA

EN un artículo de gran importancia escrito para la Hurvard Business Review, Michael www.elsolucionario.net
Hammer [HAM90] sentaba las bases para una revolución del pensamiento administrati-
vo acerca de los procesos y computación de los negocios:

Ha llegado el momento de dejar de pavimentar los senderos para vacas. En lugar de incrustar unos pro-
cesos anticuados en silicio y en software, deberíamos eliminarlos y volver a empezar. Tenemos que reha-
cer la ingenieria de nuestros negocios: hay que utilizar la potencia de la tecnología de'la información moderna
para rediseñar de forma radical nuestros procesos de negocios, y lograr así unas mejoras drásticas de su ren-
dimiento.

Todas las compañías funcionan de acuerdo con una gran cantidad de reglas no escritas... La reingenie-
ría intenta apartarse de las viejas reglas acerca de la forma en que se organizan y desarrollan nuestros ne-
gocios.

Al igual que todas las revoluciones, la llamada a las armas de Hammer ha dado lugar a cam-
bios tanto positivos como negativos. Algunas compañías han hecho un esfuerzo legítimo en
rehacer su ingeniería, y los resultados han mejorado su competitividad. Otras se han basado
únicamente en reducir las dimensiones y hacer subcontratas (en lugar de rehacer su reingenie-
ría) para mejorar sus beneficios. Y como resultado se obtuvieron organizaciones reducidas con
pocas probabilidades de crecer en un futuro [DEM95].

Durante la primera década del siglo veintiuno, el bombo publicitario asociado a la reinge-
niería ha decaído, pero el proceso en sí continúa en compañías grandes y pequeñas. La unión
de la reingeniería con la ingeniería del software se encuentra en una «revisión del sistema».

¿Qué es? Tenga en consideración cual- ¿Por qué es importante?Vivimos en un los programas existentes que exhiben
quier producto de tecnología que haya mundoen constantecambio.Lasdeman- una mantenibilidad de mayor calidad.
adquirido. Lo ve con regularidad, pero das de funciones de negocios y de tec-
está envejeciendo. Se rompe con fre- nología de informaciónque las soportan ¿Cuál es el producto obtenido? Son
cuencia, tarda en repararse y y a no están cambiando a un ritmo que impo- varios los productos que se elaboran
representa la última tecnología. ¿Qué ne mucha presión competitiva en todas (porejemplo,modelos análisis, modelos
se puede hacer? Si el producto es de las organizaciones comerciales. Tanto de diseño, procedimientos de pruebas).
hardware, probablemente lo tirará y se los negocios comoel softwareque sopor- El resultado final es un proceso de rein-
comprará uno nuevo. Pero si es un soft- tan (oes)el negocio deberán diseñarse geniería de negocios yío el software de
ware personalizado, no dispondrá la una vez más para mantener el ritmo. reingeniería que lo soporta.
opción de tirarlo. Necesitará recons-
truirlo. Creará un productocon una fun- ¿Cuáles son los pasos? La reingenieria ¿Cómo puedo esta seguro de que lo
cionalidad nueva, un mejor rendimiento de procesosde negocios WN)define las he hecho correctamente?Utilizun-
y fiabilidad, y un mantenimiento mejo- metas comerciales, identifica y evalúa do las mismas prácticas que se aplican
rado. Eso es lo que llamamos reinge- los procesos de negocios existentes, y en todos los procesos de ingeniería del
niería. crea procesos comercialesrevisados que software -las revisiones técnicas for-
mejoran las metas actuales. El proceso males evalúan los modelos de análisis
¿Quiénlo hace? A nivel de negocio, la de reingeniería del software acompaña y de diseños, las revisiones especializa-
reingeniería es ejercida por especia- el análisis de inventarios, la estructura- das tienen en consideración la capaci-
listas de negocio (frecuentemente ción de documentoc. la ingenieríainver- dad de aplicación comercial y la
empresas de consultoría).A nivel de sa, la reestructuración de datos y.la compatibilidad, y la comprobación se
software, la reingeniería es ejecutada ingeniería avanzada. El objetivode estas aplica para descubrir los errores en el
por ingenieros del software. actividades escrearversionesnuevas de contenido, en la funcionalidad y e n la
interoperabilidad.

El software suele ser la realización de las reglas de negocio que describe Hammer. A medida que
las reglas cambian, el softwaretambién tiene que cambiar. En la actualidad,existen compañías impor-
tantes que poseen decenas de miles de programas de computadora que prestan apoyo a las «viejas
reglas del negocio». Cuando los administradorestrabajan para modificar estas reglas y lograr así una
mayor efectividady competitividad,el software seguirá el mismo ritmo. En algunos casos, esto impli-
ca la creación de sistemasnuevos e importantes basados en computadora'. Pero en muchos otros, esto
implica la modificación ylo reconstrucción de las aplicaciones existentes.

' Los sistemas y aplicaciones basados en Web estudiados en el Capítulo 29 son ejemplos contemporáneos.

541

hwttwp:w//l.iberlesroialu-ucniiovenrasritiaor.ian.ebtlogspot.com
.

INGENiERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

En este capítulo se examina la reingeniería de forma descendente, comenzando por una visión general de la reingenie-
ría de procesos de negocio y pasando entonces a una discusión más detallada de las actividades técnicas que se producen
cuando se efectúa una reingeniería del software.

La Reingeniería de procesos de negocio, RPN (Busi- @O"SEJO@ www.elsolucionario.net
ness Process Reingineering,BPR2)va más allá del ámbi-
to de las tecnologías de la informacióny de la ingeniería Como ingeniero del sohare, el trabajo de reingenierío
del software. Entre las muchas definiciones (la mayo-
ría de ellas, algo abstractas) que se han sugerido para la tiene lugar en lo porte inferior de la jerorrpia.
RPN, se cuenta con una publicada en la revista Fortu- Sin embargo, osegúrese de que alguien hoyo pensado
seriamente en el nivel anterior. Si no lo han hecho,
ne [STE93]: «...la búsqueda e implementación de cam-
su trabojocorre olgún riesgo.
bios radicales en el proceso de negocios para lograr un
avance significativo». Ahora bien ¿cómo se efectúa la Cada uno de los sistemas de negocios (también lla-
búsqueda, y cómo se lleva a cabo la implementación? madosfunción de negocios) están compuestos por uno
O lo que es más importante,¿cómo podemos estar segu- o más procesos de negocio, y cada proceso de negocio
ros de que el «cambio radical» que se sugiere va a dar está definido por un conjunto de subprocesos.
lugar realmente a un «avance significativo» en lugar de
conducimos a un caos organizativo? La RPN se puede aplicar a cualquier nivel de la jerar-
quía, pero a medida que se amplía el ámbito de la RPN
(esto es, a medida que se asciende dentro de la jerarquía)
los riesgos asociados a la RPN crecen de forma dramáti-
ca. Por esta razón, la mayor parte de los esfuerzos de la
RPN se centran en procesos o subprocesosindividuales.

30.1.1. Procesos de negocios 30.1.2. Principios de reingeniería de procesos

Un proceso de negocio es «un conjunto de tareas lógi- de negocios
camente relacionadas que se llevan a cabo para obtener
un determinado resultado de negocio» [DAV90]. Den- En muchos aspectos, la RPN tiene un objetivo y un ámbi-
tro del proceso de negocio, se combinan las personas, to idéntico al proceso de la ingeniería de la información
los equipos, los recursos materiales y los procedimien- (Capítulo 10).Lo ideal sería que la RPN se produjera de
tos de negocio con objeto de producir un resultado con- forma descendente,comenzando por la identificación de
creto. Entre los ejemplos de negocio se incluyen el los objetivos principales del negocio, y culminando con
diseño de un nuevo producto, la adquisición de servi- una especificación mucho más detallada de las tareas que
cios y suministros, la contratación de nuevos emplea- definen un proceso específico de negocios.
dos o el pago a proveedores. Cada una requiere un
conjunto de tareas y se basa en diversos recursos den- Hammer [HAM90] sugiere una serie de principios
tro del negocio. que nos guiarán por las actividades de la RPN cuando
se comienza en el nivel superior (de negocios):
Cada proceso de negocio posee un cliente bien defi-
nido -una persona o grupo que recibe el resultado (por Organizaciónen torno a los resultados, no en torno a las
ejemplo: una idea, un informe, un diseño, un produc- tareas. Hay muchascompañíasque poseen actividadesde nego-
t o t . Además, los procesos de negocio cruzan los lími- cio compartimentadas,de tal modo que no existe una Única
tes organizativos. Requieren que distintos grupos de la persona (u organización)que tenga la responsabilidad(oel con-
organizaciónparticipen en las «tareas lógicamente rela- trol) de un cierto resultado de negocio. En tales casos, resulta
cionadas» que definen el proceso. difícil determinar el estado del trabajo e incluso más difícil

En el Capítulo 10se indicaba que todo sistema es en depurarlos problemas de procesocuandoesto sucede.La RPN
realidad una jerarquía de subsistemas. El negocio glo-
bal se puede segmentar de la siguiente manera: deberá diseñar procesos que eviten este problema.

El negocio Hay que hacer que quienes utilicen la salida del proceso
llevena cabo elproceso. El objetivo de esta recomendación es
sistemas de negocio permitir que quienes necesiten las salidas del negocio contre
len todas las variables que les permitan obtener esa salida de
proceso de negocio forma temporalmenteadecuada. Cuantomenor sea el número
de personas distintas implicadas en el proceso, más fácil será
subprocesos de negocio el camino hacia un resultado rápido.

BPR, en castellanoRPN 3Referencia Web

Poro encontrar uno extensa información

sobre lo reingenierío de procesosde negocios
visite lo dirección www.brint.tom/BPR.htm

542

www.elsolucionario.net CAPfTULO 30 REINGENIERfA
.

Hay que incorporarel trabajo de procesamiento de infor- Identificaciónde procesos.En esta actividad se iden-
mación al trabajo real que produce la información pura. A tifican los procesos críticos para alcanzar los objetivos
medida que la TI se distribuye, es posible localizar la mayor definidos en la definición del negocio, A continuación,
parte del procesamiento de información en el seno de la orga- pueden recibir prioridades en función de su importan-
nización que produce los datos. Esto localiza el control, redu- cia, necesidad de cambio, o cualquier otra forma que
ce el tiempo de comunicación y la potencia de computación se resulte adecuada para la actividad de reingeniería.
pone en manos de quienes tienen fuertes intereses en la infor-
mación producida. Definición
del negocio
Hay que manipular recursos geográficamente dispersos
como si estuviesen centralizados. Las comunicaciones basa-
das en computadoras se han sofisticado tanto que es posible
situar grupos geográficamentedispersos en una misma «ofici-
na virtual». Por ejemplo, en lugar de emplear tres turnos de
ingeniería en una única localización, toda la compañía podrá
tener un turno en Europa, un segundo turno en Norteaménca
y un tercer turno en Asia. En todos los casos, los ingenierostra-
bajarán durante el día y se comunicarán empleando redes de
un elevado ancho de banda.

Hay que enlazar las actividadesparalelas en lugar de inte- FIGURA 30.1. Un modelo de BPR. www.elsolucionario.net
grar sus resultados. Cuando se utilizan diferentes grupos de
empleados para realizar tareas en paralelo, es esencial diseñar Evaluación de procesos. Los procesos existentes
un proceso que exija una continuación en la comunicación y deberán analizarse y medirse exhaustivamente. Las
coordinación. En caso contrario, es seguro que se producirán tareas de procesos se identificarán;los costes y los tiem-
problemas de integración. pos consumidos por las tareas de proceso se anotarán
cuidadosamente, y se aislarán los problemas de calidad
Hay que poner e1punto de decisión en el lugar donde se y rendimiento.
efectúa el trabajo, e incorporar el control al proceso. Dentro
de lajerga del diseño del software, esto sugiere una estructura Especificación y diseño de procesos. Basándose en la
organizativamás uniforme y con menos factorización. informaciónobtenidadurante las tres primeras actividades
de la RPN, se prepararán casos prácticos (Capítulo 11)para
Hay que capturar los datos una sola vez, en el lugar don- cada uno de los procesos que se tengan querediseñar. Den-
de se producen. Los datos se deberán almacenar en computa- tro del contexto de la RPN, los casos prácticos identifican
doras, de tal modo que una vez recopilados no sea necesario un escenario que proporcionaresultados a un cliente. Con
volver a introducirlos nunca. el uso de casos prácticos como especificacióndel proceso,
se diseña un nuevo conjunto de tareas (que se ajustan a los
Todos y cada uno de los principios anteriores repre- principios indicadosen la Sección 30.2.1) para el proceso.
sentan una visión dotalmente general» de la RPN. Una
vez informados por estos principios, los planificadoresde Creación de prototipos. Es preciso construir un pro-
negocios y los diseñadores de procesos deberán empezar totipo del proceso de negocios rediseñado antes de inte-
a procesar el nuevo diseño. En la sección siguiente, se grarlo por completo en el negocio. Esta actividad
examinará el proceso de RPN más detalladamente. «comprueba»el proceso para que sea posible efectuarrefi-
namientos.
30.1.3. Un modelo de RPN
Refinamientoe instanciación. Basándose en la rea-
Al igual que la mayoría de las actividades de ingenie- limentación procedente del prototipo, se refina el pro-
na, la reingeniería de procesos de negocio es iterativa. ceso de negocio y después se instancia en el seno de un
Los objetivos de negocio, y los procesos que los logran, sistema de negocio.
deberán adaptarse a un entorno de negocio cambiante.
Por esta razón, no existe ni principio ni fin en la RPN En algunas ocasiones las actividades de RPN descritas
-se trata de un proceso evolutivo-. En la Figura 30.1 anteriormente se utilizanjunto con herramientas de análi-
se representa un modelo de reingeniería de procesos de sis del flujo de trabajo. El objetivo de estas herramientas
negocio. Este modelo define seis actividades: es construirun modelo del flujo de trabajoexistente,en un
esfuerzo por analizar mejor los procesos existentes. Ade-
Definición del negocio. Los objetivos de negocios más, para implementar las cuatroprimeras actividades des-
se identifican en un contexto de cuatro controladores critas en el modelo de procesos se pueden utilizar las
principales: reducción de costes, reducción de tiempos,
mejora de calidad y desarrollo y potenciación del per-
sonal. Los objetivos se pueden definir en el nivel de
negocios o para un componente específico del negocio.

543

www.elsolucionario.net

INGENlERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO .

técnicas de modelado que se asocian normalmente a las dos por la evidencia empírica. Para muchas compañías parece www.elsolucionario.net
actividades de ingeniería de la información tales como la que la bala de plata no da en el blanco.
planificación de estrategias de información y el análi-
sis de áreas de negocios (Capítulo 10). Para otras, sin embargo, el nuevo esfuerzo de la reingenie-

30.1.4. Advertencias ría ha tenido evidentemente su fruto...

Es muy frecuente que se exagere la importancia de un La RPN puede funcionar, si es aplicada por personas
nuevo enfoque de negocio - e n este caso, la RPN- motivadas y formadas,que reconozcan que el proceso de
como si fuese la panacea, para después criticarla con reingeniería es una actividad continua. Si la RPN se Ile-
tanta severidad que pase a ser un desecho. A lo largo de va a cabo de forma efectiva, los sistemas de información
los Últimos años, se ha debatido de forma exagerada se integran mejor con los procesos de negocios. Dentro
acerca de la eficacia de la RPN (por ejemplo: [BLE93] del contexto de una estrategiamás amplia de negocios se
y [DIC95]). En un resumen excelente del caso a favor puede examinar la reingeniería de aplicacionesmás anti-
y en contra de la RPN, Weisz (WEI95) expone su argu- guas, y también se pueden establecer de forma inteligente
mento de la manera siguiente: las prioridades de reingeniería del software.

Resulta tentador atacar a la RPN como si se tratase de otra Aunque la reingeniería de negocio sea una estrate-
reencarnación de la famosa bala de plata. Desde varios puntos gia rechazada por una compañía, la reingeniería del soft-
de vista -pensamientode sistemas, tratamiento de personal, ware es algo que dehe hacerse. Existen decenas de
simple historia-habría que predecir unos índices de fallos millares de sistemas heredados -aplicaciones crucia-
elevados para el concepto, índices que parecen ser confirma- les para el éxito de negocios grandes y pequeños-que
se ven afectados por una enorme necesidad de ser
reconstruidos o rehechos en su totalidad.

Este escenario resulta sumamente conocido: Una apli- debajo de la superficie. A principios de los años 70, el
cación ha dado servicio y ha cubierto las necesidades iceberg de mantenimiento era lo suficientemente gran-
del negocio de una compañía durante diez o quince años. de como para hundir un portaaviones. En la actualidad
A lo largo de este tiempo, ha sido corregida, adaptada podría hundir toda la Armada.
y me-joradamuchas veces. Las personas se dedicaban a
esta tarea con la mejor de sus intenciones, pero las prác- El mantenimiento del software existente puede dar
ticas de ingeniería del software buenas siempre se echa- cuenta de más del 60 por 100 de las inversiones efec-
ban a un lado (por la urgencia de otros problemas). tuadas por una organización de desarrollo, y ese por-
Ahora la aplicación se ha vuelto inestable. Sigue fun- centaje sigue ascendiendo a medida que se produce más
cionando, pero cada vez que intenta efectuar un cam- software [HAN93]. Los lectores que tengan menos
bio se producen efectos colaterales graves e inesperados. conocimientos en estos temas podrían preguntarse por
¿Qué se puede hacer? qué se necesita tanto mantenimiento,y por qué se invier-
te tanto esfuerzo. Osborne y Chifosky [OSB90] ofre-
La imposibilidad de mantener el software no es un cen una respuesta parcial:
problema nuevo. De hecho, el gran interés por la rein-
geniería del software ha sido generado por un «iceberg» Gran parte del software del que dependemos en la actua-
de mantenimiento de software que lleva creciendo des- lidad tiene por término medio entre diez y quince años de
de hace más de treinta años. antigüedad. Aun cuando estos programas se crearon emple-
ando las mejores técnicas de diseño y codificación conoci-
3Referencia Web das en su época (y la mayoría no lo fueron), se crearon
cuando el tamaño de los programas y el espacio de alma-
SE1 ofrece una variedad de recursos cenamiento eran las preocupaciones principales. A conti-
nuación, se trasladaron a las nuevas plataformas, se ajustaron
de reingeniería del software en la para adecuarlos a cambios de máquina y de sistemas ope-
rativos y se mejoraron para satisfacer nuevas necesidades
dirección: www.sei.tmu.edu/reengineering/ del usuario; y todo esto se hizo sin tener en cuenta la arqui-
tectura global.
30.2.1. Mantenimiento del software
El resultado son unas estructuras muy mal diseñadas, una
Hace casi treinta años, el mantenimiento del software mala codificación, una lógica inadecuada, y una escasa docu-
se caracterizaba [CAN721 por ser como un «iceberg». mentación de los sistemas de software que ahora nos piden
Esperábamos que lo que era inmediatamente visible fue- que mantengamos en marcha ...
ra de verdad lo que había, pero sabíamos que una enor-
me masa de posibles problemas y costes yacía por La naturaleza ubicua del cambio subyace en todos
los tipos de trabajo del software. El cambio es algo ine-
vitable cuando se construyen sistemas basados en com-
putadoras; por tanto debemos desarrollar mecanismos
para evaluar, controlar y realizar modificaciones.

544

www.elsolucionario.net
.

CAPÍTULO 30 REINGENIERfA

Al leer los párrafos anteriores, un lector podría argu- Antes de derribar y de construir toda la casa, asegú- www.elsolucionario.net
rese de que la estructura está en mal estado. Si la casa
mentar: <<...pero yo no invierto el 60 por 100 de mi tiem- tiene una buena estructura, quizá sea posible remo-
delarla sin reconstruirla (con un coste muy inferior
po corrigiendo errores de los programas que desarrollo». y en mucho menos tiempo).
Por supuesto, el mantenimiento del software es algo que Antes de empezar a reconstruir, asegúrese de que
va mucho más allá de morregir errores>>E.l mantenimiento entiende la forma en que se construyó el original.
se puede definir describiendo las cuatro actividades Eche una ojeada por detrás de las paredes. Com-
[SWA76]que se emprendencuando se publica un progra- prenda el cableado, la fontanería y los detalles inter-
ma para su utilización. En el Capítulo 2 se definieron cua- nos de la estructura.Aunque vaya a eliminarlostodos,
tro actividades diferentes de mantenimiento: mantenimiento la idea que haya adquirido de ellos le servirán de
correctivo, mantenimientoadaptativo, mejoras o mante- mucho cuando empiece a construirla.
nimientodeperj4eccionamientoy mantenimientopreventi- Si empieza a reconstruir, utilice tan solo los materia-
vo o reingeniería. Tan sólo el 20 por 100 de nuestros les más modernos y de mayor duración. Quizá ahora
esfuerzos de mantenimiento se invertirán «comgiendoerre le cuesten un poquito más, pero le ayudarán a evitar
res». El 80por 100se dedicará a adaptarlos sistemasexis- un mantenimientocostoso y lento en fecha posterior.
tentes a los cambios de su entorno externo, a efectuar las Si ha decidido reconstruir, tenga una actitud disci-
mejoras solicitadaspor los usuarios y a rehacer la ingenie- plinada. Utilice prácticas que den como resultado
ría de las aplicacionespara su posterior utilización. Cuan- una gran calidad -tanto hoy como en el futuro-.
do se considera que el mantenimiento abarca todas estas
actividades, es fácil ver por qué absorbe tanto esfuerzo. las pasas para una casa indicudos aquíson obvios.
Asegúrese de que su consideraciónsobre el sahare
anticuada aplica pasos que sean ton obvios. píenselo.
Hay mucha dinero en juego.

30.2.2. Un modelo de procesos de reingeniería Aunque los principios anteriores se centran en la
reconstrucción de una casa, son aplicables igualmente
del software a la reingeniería de sistemas y aplicaciones basados en
computadoras.
La reingeniería requiere tiempo; conlleva un coste de
dinero enorme y absorbe recursos que de otro modo Para implementar estos principios, se aplica un modelo
podrían emplearse en preocupaciones más inmediatas. de proceso de reingeniería del software que define las seis
Por todas estas razones, la reingeniería no se lleva a actividades mostradas en la Figura 30.2. En algunas oca-
cabo en unos pocos meses, ni siquiera en unos pocos siones, estas actividades se producen de forma secuencial
años. La reingeniería de sistemas de información es una y lineal, pero estono siemprees así.Por ejemplo, puede ser
actividad que absorberá recursos de las tecnologías de que la ingenieríainversa(la comprensióndel funcionamiento
la información durante muchos años. Esta es la razón internode un programa) tenga que producirse antes de que
por la cual toda organización necesita una estrategia pueda comenzar la reestructuración de documentos.
pragmática para la reingeniería del software.
El paradigma de la reingeniería mostrado en la figu-
Una estrategia de trabajo también acompaña al mode- ra es un modelo cíclico. Esto significa que cada una de
lo de procesos de reingeniería. Más adelante, en esta las actividades presentadas como parte del paradigma
misma sección, se describirá este modelo, pero veamos pueden repetirse en otras ocasiones. Para un ciclo en
en primer lugar algunos de los principios básicos. particular, el proceso puede terminar después de cual-
quiera de estas actividades.
La reingeniería es una tarea de reconstrucción, y se
podrá comprender mejor la reingeniería de sistemas de Análisis de inventario. Todas las organizaciones de
información si tomamos en consideración una activi- software deberán disponer de un inventario de todas sus
dad análoga: la reconstrucción de una casa. Considere- aplicaciones. El inventario puede que no sea más que una
mos la situación siguiente: hoja de cálculo con la información que proporciona una
descripción detallada (por ejemplo: tamaño, edad, impor-
Suponga que ha adquirido una casa en otro lugar. tancia para el negocio) de todas las aplicaciones activas.
Nunca ha llegado a ver la finca realmente, pero la con-
siguió por un precio sorprendentementereducido, advir- Análisis de inventario
tiéndosele que quizá fuera preciso reconstruirla en su
totalidad. ¿Cómo se las arreglaría?

Antes de empezar a construir, sería razonable inspec-

cionar la casa. Para determinar si necesita una recons-
trucción, usted (o un inspector profesional) creará una
lista de criteriospara que la inspección sea sistemática.

545

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO

Los candidatos a la reingeniería aparecen cuando se Ingenieríainversa.El término «ingeniería inversa» tie-
ordena esta información en función de su importancia ne sus orígenes en el mundo del hardware. Una cierta com-
para el negocio, longevidad, mantenibilidad actual y pañía desensambla un producto de hardware competitivo
otros criterios localmente importantes. Es entonces cuan- en un esfuerzo por comprender los-«secretos»del diseño
do es posible asignar recursos a las aplicaciones candi- y fabricación de su competidor. Estos secretos se podrán
datas para el trabajo de reingeniería. comprender más fácilmente si se obtuvieran las especifi-
caciones de diseño y fabricación del mismo. Pero estos
Es importante destacar que el inventario deberá revi- documentos son privados, y no están disponibles para la
sarse con regularidad. El estado de las aplicaciones (por compañía que efectúa la ingeniería inversa. En esencia,
ejemplo, la importancia con respecto al negocio) pue- una ingeniería inversacon éxito precede de una o más espe-
de cambiar en función del tiempo y, como resultado, cificaciones de diseño y fabricación para el producto,
cambiarán también las prioridades para la reingeniería. mediante el examen de ejemplos reales de ese producto.

Reectructuracion Reestructuracion La ingeniería inversa del software es algo bastante www.elsolucionario.net
similar. Sin embargo, en la mayoría de los casos, el pro-
FIGURA 30.2.Un modelo de proceso de reingeniería grama del cual hay que hacer una ingeniería inversa no
es el de un rival, sino, más bien, el propio trabajo de la
de software. compañía (con frecuenciaefectuado hace muchos años).
Los «secretos»que hay que comprender resultan incom-
Reestructuración de documentos. Una documen- prensibles porque nunca se llegó a desarrollar una espe-
tación escasa es la marca de muchos sistemas hereda- cificación. Consiguientemente, la ingeniería inversa del
dos. ¿Qué se puede hacer al respecto? software es el proceso de análisis de un programa con
el fin de crear una representación de programa con un
Opción n.g 1: La creación de documentación consume nivel de abstracción más elevado que el código fuente.
muchísimo tiempo. El sistema funciona, y ya nos apañaremos La ingeniería inversa es un proceso de recuperación de
con lo que tengamos. En algunos casos, éste es el enfoque diseño. Con las herramientas de la ingeniería inversa se
correcto. No es posible volver a crear la documentación para extraerá del programa existente información del diseño
cientos de programas de computadoras. Si un programaes rela- arquitectónico y de proceso, e información de los datos.
tivamente estático está llegando al final de vida útil, y no es
probable que experimente muchos cambios: idejémoslo así! Reestructuracióndel código. El tipo más común de
reingeniería (en realidad, la aplicación del término rein-
Opción n.O 2: Es preciso actualizar la documentación, pero geniería sería discutible en este caso) es la reestructu-
se dispone de recursos limitados. Se utilizará un enfoque «del ración del código. Algunos sistemas heredados tienen
tipo documentar si se modifica». Quizá no se necesario volver una arquitectura de programa relativamente sólida,pero
a documentar por completo la aplicación. Más bien se docu- los módulos individuales han sido codificados de una
mentarán por completo aquellas partes del sistema que estén forma que hace difícil comprenderlos, comprobarlos y
experimentando cambios en ese momento. La colección de mantenerlos. En estos casos, se puede reestructurar el
documentos Útil y relevante irá evolucionando con el tiempo. código ubicado dentro de los módulos sospechosos.

Opción n.O 3:El sistema es fundamental para el negocio, y Para llevar a cabo esta actividad, se analiza el códi-
es preciso volver a documentarlo por completo. En este caso, go fuente mediante una herramienta de reestructuración,
un enfoque inteligenteconsiste en reducir la documentación al se indican las violaciones de las estructuras de progra-
mínimo necesario. mación estructurada, y entonces se reestructura el códi-
go (esto se puede hacer automáticamente). El código
Creesólo la documentación que necesite reestructurado resultante se revisa y se comprueba para
para mejorar su comprensiónsobre el sohare asegurar que no se hayan introducido anomalías. Se
No para avanzar una pógina más. actualiza la documentación interna del código.

Todas y cada una de estas opciones son viables. Las Reestructuraciónde datos. Un programa que posea
organizaciones del software deberán seleccionar aque- una estructura de datos débil será difícil de adaptar y de
lla que resulte más adecuada para cada caso. mejorar. De hecho, para muchas aplicaciones, la arqui-
tectura de datos tiene más que ver con la viabilidad a
largo plazo del programa que el propio código fuente.

A diferencia de la reestructuración de código, que se
produce en un nivel relativamente bajo de abstracción,
la estructuración de datos es una actividad de reinge-
niería a gran escala. En la mayoría de los casos, la rees-
tructuración de datos comienza por una actividad de
ingeniería inversa. La arquitectura de datos actual se
analiza minuciosamente y se definen los modelos de

546

httpw://lwibwre.reial-suonliuvecrisointaarirai.ob.lnogestpot.com CAPfTULO 30 REINGENIERfA
.

datos necesarios (Capítulo 12). Se identifican los obje- do un «motor de reingeniería» automatizado. En el www.elsolucionario.net
tos de datos y atributos y, a continuación, se revisan las motor se insertm’a el programa viejo, que lo analizaría,
estructuras de datos a efectos de calidad. reestructurm’a y después regeneraría la forma de exhi-
bir los mejores aspectosde la calidad del software. Des-
3Referencia Web pués de un espacio de tiempo corto, es probable que
llegue a aparecer este «motor», pero los fabricantes de
Para poder obtener una gran cantidadde recursos CASE han presentado herramientas que proporcionan
para la comunidad de reingeniería visite esto dirección: un subconjunto limitado de estas capacidades y que se
www.comp.lancs.acuk/prqect s/RenaissanceWeb/ enfrentan con dominiosde aplicacionesespecíficos (por
ejemplo, aplicaciones que han sido implementadas
Cuando la estructura de datos es débil (por ejemplo, empleando un sistema de bases de datos específico). Lo
actualmente se implementan archivos planos, cuando que es más importante, estas herramientas de reinge-
un enfoque relaciona1 simplificaría muchísimo el pro- niería cada vez son más sofisticadas.
cesamiento), se aplica una reingeniería a los datos.
La ingeniería directa, que se denomina también reno-
Dado que la arquitectura de datos tiene una gran vación o reclamación [CHI90], no solamente recupera la
influencia sobre la arquitectura del programa, y también información de diseño de un softwareya existente, sino
sobre los algoritmos que lo pueblan, los cambios en que, además, utiliza esta informaciónpara alteraro recons-
datos darán lugar invariablemente a cambios o bien de truir el sistema existente en un esfuerzo por mejorar su
arquitectura o bien de código. calidad global. En la mayoría de los casos, el software
procedente de una reingeniería vuelve a implementar la
Ingeniería directa (forward engineering). En un funcionalidaddel sistema existente,y añade además nue-
mundo ideal, las aplicaciones se reconstruyen utilizan- vas funciones y/o mejora el rendimiento global.

La ingeniería inversa invoca una imagen de «ranura La completitud de un proceso de ingeniería inversa
mágica». Se inserta un listado de código no estructura- alude al nivel de detalle que se proporciona en un deter-
do‘yno documentado por la ranura, y por el otro lado minado nivel de abstracción. En la mayoría de los casos,
sale la documentación completa del programa de com- la completitud decrece a medida que aumenta el nivel
putadora. Lamentablemente, la ranura mágica no exis- de abstracción. Por ejemplo, dado un listado del códi-
te. La ingeniería inversa puede extraer información de go fuente, es relativamente sencillo desarrolla una repre-
diseño del código fuente, pero el nivel de abstracción, sentación de diseño de procedimientos completa.
la completitudde la documentación,el grado con el cual También se pueden derivar representaciones sencillas
trabajan al mismo tiempo las herramientas y el analis- del flujo de datos, pero es mucho más difícil desarrollar
ta humano, y la direccionalidad del proceso son suma- un conjunto completo de diagramas de flujo de datos o
mente variables [CASSS]. un diagrama de transición de estados.

El nivel de abstracción de un proceso de ingeniería “.c%V E
inversa y las herramientas que se utilizan para realizarlo
aluden a la sofisticación de la información de diseño que Se deben ofrontar tres enfoques de ingeniería inversa:
sepuede extraerdel código fuente. El nivel de abstracción nivel de obstracción, completitud y direccionolidad.
ideal deberá ser lo más alto posible. Esto es, el proceso de
ingeniería inversa deberá ser capaz de derivar sus repre- La completitud mejora en proporción directa a la can-
sentacionesde diseño de procedimientos(con un bajo nivel tidad de análisis efectuado por la persona que está efec-
de abstracción);y la informaciónde las estructurasde datos tuando la ingeniería inversa. La interactividud alude al
y de programas (un nivel de abstracción ligeramente más grado con el cual el ser humano se «integra» con las
elevado); modelos de flujo de datos y de control (un nivel herramientas automatizadas para crear un proceso de
de abstracción relativamente alto); y modelos de entida- ingeniería inversa efectivo. En la mayoría de los casos,
des y de relaciones (un elevado nivel de abstracción). A a medida que crece el nivel de abstracción, la interacti-
medida que crece el nivel de abstracción se proporciona vidad deberá incrementarse, o sino la completitud se
al ingenierodel software información que le permitirá com- verá reducida.
prender más fácilmente estos programas.
Si la direccionalidad del proceso de ingeniería inver-
Lo notacibnindicadoaquí se explica con detalle sa es monodireccional, toda la información extraída del
código fuente se proporcionará a la ingeniería del soft-
en el Copítuio 12. ware que podrá entonces utilizarla durante la actividad

547

www.elsolucionario.net
.

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRÁCTICO

de mantenimiento. Si la direccionabilidad es bidirec- miento que se realiza, la interfaz de usuario que se apli-
cional, entonces la información se suministrará a una ca, y las estructuras de datos de programa o de base de
herramienta de reingeniería que intentará reestructurar datos que se utiliza.
o regenerar el viejo programa.

I 30.3.1. Ingeniería inversa para comprender
el procesamiento
Código fuente sucio
La primera actividad real de la ingeniería inversa

comienza con un intento de comprender y extraer des-

Reestructuración pués abstracciones de procedimientos representadas por
del código el código fuente. Para comprender las abstraccionesde
procedimientos, se analiza el código en distintos nive-
Código fuente limpio les de abstracción: sistema,programa, componente,con-
figuración y sentencia.
/4I
Procesamiento La funcionalidad general de todo el sistema de apli-

Extraer Ulnterfaz caciones deberá ser algo perfectamente comprendido
abstracciones antes de que tenga lugar un trabajo de ingeniería inversa
más detallado. Esto es lo que establece un contexto para

un análisis posterior, y se proporcionan ideas generales www.elsolucionario.net

Especificación inicial acerca de los problemas de interoperabilidadentre apli-
caciones dentro del sistema. Cada uno de los programas
I de que consta el sistema de aplicacionesrepresentaráuna

Refinar abstracción funcional con un elevado nivel de detalle.
y simplificar También se creará un diagrama de bloques como repre-
sentación de la iteración entre estas abstracciones fun-

cionales. Cada uno de los componentes efectúa una

Especificación final subfunción, y representa una abstracción definida de pro-

t cedimientos. En cada componente se crea una narrativa
de procesamiento. En algunas situacionesya existen espe-
cificacionesde sistema, programa y componente. Cuan-
FIGURA 30.3.El proceso de ingeniería inversa. do ocurre tal cosa, se revisan las especificaciones para
El proceso de la ingeniena se representa en la Figu- preciar si se ajustan al código existente4.

ra 30.3. Antes de que puedan comenzar las actividades

de ingeniería inversa, el código fuente no estructurado

(«sucio»)se reestructura (Sección 30.4.1)para que sola-

mentecontengaconstnxcionesdeproglamación estnic-

turada3.Esto hace que el código fuente sea más fácil de

leer, y es lo que proporciona la base para todas las acti-

vidades subsiguientes de ingeniería inversa.

l a página de Recuperaciónde diseños y entendimiento Todo se complica cuando se considera el código que
de programasproporcionalos recursos útiles para un trabajo reside en el interior del componente. El ingeniero bus-
de reingeniería: www.sel.it.nrc.ca/projects/dr/dr.html ca las secciones de código que representan las configu-
raciones genéricas de procedimientos. En casi todos los
El núcleo de la ingeniería inversa es una actividad componentes, existe una sección de código que prepa-
denominada extracción de abstracciones. El ingeniero ra los datos para su procesamiento (dentro del compo-
tiene que evaluar el viejo programa y a partir del códi- nente), una sección diferente de código que efectúa el
go fuente (que no suele estar documentado) tiene que procesamiento y otra sección de código que prepara los
extraer una especificación significativa del procesa- resultados del procesamiento para exportarlos de ese
componente. En el interior de cada una de estas sec-
ciones, se encuentran configuraciones más pequeñas.

El código se puede reestructurar automáticamente empleando un Con frecuencia, las especificaciones escritas en fases centradas de
((motorde reestructuración), -una herramienta CASE que reestruc- la historia del programa no llegan a actualizarse nunca. A medida
tura el código fuente-. que se hacen cambios, el código deja de satisfacer esas especifica-
ciones.

548

www.elsolucionario.net CAPfIULO 30 REINGENIERIA
.

Por ejemplo, suele producirse una verificación de los 3 . Para toda variable (dentro de un programa) que repre- www.elsolucionario.net
datos y una comprobación de los límites dentro de la sente una matriz o archivo, la construcción de un lis-
sección de código que prepara los datos para su proce- tado de todas las variables que tengan una relación
samiento. lógica con ella.

Para los sistemas grandes, la ingeniería inversa sue- En lospróximos años los compromisosre/aiivamente
le efectuarse mediante el uso de un enfoque semiauto- rignificotivosen /asestructuras de datos pueden conduci/
matizado. Las herramientas CASE se utilizan para o tener problemas potencialmentecatostr6ficos. Fijese
«analizar» la semántica del código existente. La salida por ejemploen elefecto del ajo 2000.
de este proceso se pasa entonces a unas herramientas
de reestructuración y de ingeniería directa que comple- Estos pasos hacen posible que el ingeniero del soft-
tarán el proceso de reingeniería. ware identifique las clases del programa que interactú-
an con las estructuras de datos globales.
30.3.2. Ingeniería inversa para comprender
Estructuras de bases de datos. Independientemen-
los datos te de su organización lógica y de su estructura física,
las bases de datos permiten definir objetos de datos, y
La ingeniería inversa de datos suele producirse a dife- apoyan los métodos de establecerrelaciones entre obje-
rentes niveles de abstracción. En el nivel de programa, tos. Por tanto, la reingeniería de un esquema de bases
es frecuente que sea preciso realizar una ingeniería inver- de datos para formar otro exige comprenderlos objetos
sa de las estructuras de datos internas del programa, ya existentes y sus relaciones.
como parte del esfuerzo general de la reingeniería. En
el nivel del sistema,es frecuente que se efectúe una rein- ¿Cuáles son los pasos que
geniería de las estructuras globales de datos (por ejem-
plo: archivos, bases de datos) para ajustarlas a los se pueden ophtar para apkar
paradigmas nuevos de gestión de bases de datos (por la ingeniería inversa en una estructura
ejemplo, la transferencia de archivos planos a unos sis- de bases de datos existente?
temas de bases de datos relacionales u orientadosa obje-
tos). La ingeniería inversa de las estructuras de datos Para definir el modelo de datos existente como pre-
globales actuales establecen el escenario para la intro- cursor para una reingeniería que producirá un nuevo
ducción de una nueva base de datos que abarque todo modelo de base de datos se pueden emplear los pasos
el sistema. siguientes [PRE94] :
1. Construcción de un modelo de objetos inicial. Las
Estructuras de datos internas. Las técnicas de inge-
niería inversa para datos de programa internos se cen- claves definidas como parte del modelo se podrán
tran en la definición de clases de objetos5. Esto se logra conseguir mediante la revisión de registros de una
examinando el código del programa en un intento de base de datos de archivos planos o de tablas de un
agrupar variables de programa que estén relacionadas. esquema relacional. Los elementos de esos registros
En muchos casos, la organización de datos en el seno o tablas pasarán a ser atributos de una clase.
del código identifica los tipos abstractos de datos. Por 2. Determinaciónde los candidatosa claves. Los atribu-
ejemplo, las estructuras de registros, los archivos, las tos se examinan para determinar si se van a utilizar o
listas y otras estructuras de datos que suelen propor- no para señalara otro registro o tabla.Aquellos que sir-
cionar una indicación inicial de las clases. van como punteros pasarán a ser candidatos a claves.
3 . Refinamiento de las clases provisionales. Se deter-
Para la ingeniería inversa de clases, Breuer y Lano mina si ciertas clases similares pueden o no combi-
[BRE91] sugieren el enfoque siguiente: narse dentro de una Única clase.
4. Definición de las generalizaciones. Para determinar
Identificación de los indicadores y estructuras de si se debe o no construir una jerarquía de clases con
datos locales dentro del programa que registran infor- una clase de generalización como precursor de todos
mación importante acerca de las estructuras de datos sus descendentes se examinan las clases que pueden
globales (por ejemplo, archivos o bases de datos). tener muchos atributos similares.
5. Descubrimiento de las asociaciones. Mediante el uso
Definición de la relación entre indicadores y estruc- de técnicas análogas al enfoque de CRC (Capí-
turas de datos locales y las estructuras de datos glo- tulo 21) se establecen las asociaciones entre clases.
bales. Por ejemplo, se podrá activar un indicador
cuando un archivo esté vacío; una estructura de
datos local podrá servir como memoria intermedia
de los cieh últimos registros recogidos para una
base de datos central.

Para una descripción completa d e estos conceptos orientados a
objetos, véase la Parte Cuarta de este libro.

549

www.elsolucionario.net

1NGENIERfA DEL SOFTWARE. UN ENFOQUE PRdCTICO .

Una vez que se conoce la información definida en los ¿Cuáles son las acciones básicas que deberá proce- www.elsolucionario.net
pasos anteriores, se pueden aplicar una serie de trans- sar la interfaz, por ejemplo, acciones de teclado y
formaciones [PRE94]para hacer corresponder la estruc- clics de ratón?
tura de la vieja base de datos con una nueva estructura
de base de datos. ¿Cuál es la descripción compacta de la respuesta de

30.3.3. Ingeniería inversa de interfaces comportamiento del sistema a estas acciones?
de usuario
¿Qué queremos decir con «sustitución», o más exac-
Las IGUs sofisticadas se van volviendo de rigor para
los productos basados en computadoras y para los sis- tamente, qué concepto de equivalencia de interfaces
temas de todo tipo. Por tanto el nuevo desarrollo de es relevante en este caso?
interfaces de usuario ha pasado a ser uno de los tipos
más comunes de las actividades de reingeniería. Aho- La notación de modelado de comportamiento (Capí-
ra bien, antes de que se pueda reconstruir una interfaz tulo 12)puede proporcionar una forma de desarrollar las
de usuario, deberá tener lugar una actividad de inge- respuestas de las dos primeras preguntas indicadasante-
niería inuersa. riormente. Gran parte de la información necesaria para
crear un modelo de comportamiento se puede obtener
O¿Cómo puedo entender mediante la observación de la manifestación extema de
el funcionamiento de la la interfaz existente. Ahora bien, es preciso extraer del
código la información adicional necesaria para crear el
interfaz de usuario existente? modelo de comportamiento.

Para comprender totalmente una interfaz de usuario Es importante indicar que una IGU de sustitución
ya existente (IU), es preciso especificar la estructura y puede que no refleje la interfaz antigua de forma exac-
comportamiento de la interfaz. Merlo y sus colabora- ta (de hecho, puede ser totalmente diferente). Con fre-
dores [MER93] sugieren tres preguntas básicas a las cuencia, merece la pena desarrollar metáforas de
cuales hay que responder cuando comienza la ingenie- interacción nuevas. Por ejemplo, una solicitud de IU
ría inversa de la IU: antigua en la que un usuario proporcione un
superior (del 1 a 10)para encoger o agrandar una inia-
gen gráfica. Es posible que una IGU diseñada utilice
una barra de imágenes y un ratón para realizar la mis-
ma función.

La reestructuración del software modifica el código Reduce la frustración entre ingenieros del software
fuente y/o los datos en un intento de adecuar10 a futu- que deban trabajar con el programa, mejorando por
ros cambios. En general, la reestructuración no modifi- tanto la productividad y haciendo más sencillo el
ca la arquitecturaglobal del programa. Tiende a centrarse aprendizaje.
en los detalles de diseño de módulos individuales y en Reduce el esfuerzo requerido para llevar a cabo las
estructuras de datos locales definidas dentro de los actividades de mantenimiento.
módulos. Si el esfuerzo de la reestructuración se extien- Hace que el software sea más sencillo de comprobar
de más allá de los límites de los módulos y abarca la y de depurar.
arquitectura del software, la reestructuración pasa a ser
ingeniería directa (Sección 30.5). La reestructuración se produce cuando la arquitectura
básica de la aplicaciónes sólida, aun cuando sus interio-
¿Qué beneficios se derivan ridades técnicas necesiten un retoque. Comienzacuando
existen partes considerables del software que son Útiles
de la reestructuración? todavía, y solamente existe un subconjunto de todos los
módulos y datos que requieren una extensa modificacid.
Amold [ARN89] define un cierto número de bene-
ficios que se pueden lograr cuando se reestructura el 30.4.1. Reestructuración del código
software:
La reestructuración del código se lleva a cabo para con-
Programas de mayor calidad -con mejor docu- seguir un diseño que produzca la misma funciónpero con
mentación y menos complejidad, y ajustados a las mayor calidad que el programa original. En general, las
prácticas y estándares de la ingeniería del software técnicas de reestructuracióndel código (por ejemplo, las
moderna-. técnicas de simplificaciónlógica de Warnier [WAR74])

En algunas ocasiones,resulta dificil distinguir entre una reestructura-
ción extensa y un nuevo desarrollo. Ambos con casos de reingeniería.

550

www.elsolucionario.net CAPfTULO SO REINGENlERfA
.

modelan la lógica del programa empleandoálgebra Boo- sa, llamada análisis del código fuente. En primer www.elsolucionario.net
leana, y a continuación aplican una serie de reglas de lugar se evaluarán todas las sentencias del lenguaje
transformación que dan lugar a una lógica reestructura- de programación con definiciones de datos, des-
da. El objetivo es tomar el código de forma de «plato de cripciones de archivos, de E/S, y descripciones de
espaguetis» y derivar un diseño de procedimientos que interfaz. El objetivo es extraer elementos y objetos
se ajuste a la filosofía de la programación estructurada de datos, para obtener información acerca del flujo
(Capítulo 16). de datos, así como comprender las estructuras de
datos ya existentes que se hayan implementado. Esta
Aun cuando la reesthiuración puede aliviar actividad a veces se denomina análisis de datos
los problemas inmediatas asociadas a la depuración [RIC89].
y los pequeños cambios, eso no es reingenierío.
Una vez finalizado el análisis de datos, comien-
El beneficia realse logra salo cuando se za el rediseño de datos. En su forma más sencilla se
emplea un paso de estandarización de rediseño de
reestruciuran los datas y la arquiteciura. datos que clarifica las definiciones de datos para
lograr una consistencia entre nombres de objetos de
Se han propuesto también otras técnicas de reestructu- datos, o entre formatos de registros físicos en el seno
ración que puedan utilizarse con herramientas de reinge- de la estructura de datos o formato de archivos exis-
niería. Por ejemplo, Chot y Acacchi [CH090] sugieren la tentes. Otra forma de rediseño, denominada racio-
creación de un diagrama de intercambio de recursos que nalización de nombres de datos, garantiza que todas
diseña cada uno de los módulos de programa y los recur- las convenciones de denominación de datos se ajus-
sos (tipos de datos, procedimientos y variables) que se ten a los estándares locales, y que se eliminen las
intercambian en este y otros módulos. Mediante la crea- irregularidades a medida que los datos fluyen por el
ción de representaciones del flujo de recursos, la arqui- sistema.
tectura del programa se puede reestructurar para lograr
el acoplamientomínimo entre los módulos. Cuando la reestructuración sobrepasa la estandari-
zación y la racionalización, se efectúan modificaciones
30.4.2. Reestructuraciónde los datos físicas en las estructurasde datos ya existentes con obje-
to de hacer que el diseño de datos sea más efectivo. Esto
Antes de que pueda comenzar la reestructuración de puede significaruna conversión de un formato de archi-
datos, es preciso llevar a cabo una ingeniería inver- vo a otro, o, en algunos casos, una conversión de un tipo
de base de datos a otra.

Un programa que posea flujo de control es el equivalente caciones, aplicando un enfoque de ingeniería del soft-
gráfico de un plato de espaguetis con «módulos»,es decir ware a todos los segmentos revisados.
con 2.000 sentencias de longitud; con pocas líneas de
comentarioútiles en 290.000 sentenciasde códigofuente, 4.La posibilidad de rediseñar, recodificar y comprobar
y sin ninguna otra documentación que se deba modificar el programa en su totalidad, utilizando herramientas
para ajustarle a los requisitos de cambios del usuario. Se CASE (herramientas de reingeniería) que servirán
puede decir que disponemos de las opciones siguientes: para comprender el diseño actual.
1. La posibilidad de esforzarse por efectuar una modi-
No existe una Única opción «correcta».Las circuns-
ficación tras otra, luchando con el diseño implícito tancias pueden imponer la primera opción, aun cuando
y con el código fuente para implementar los cambios las otras sean las preferidas.
necesarios.
2. La posibilidad de intentar comprender el funciona- En lugar de esperar a que se reciba una solicitud
miento interno más ampliodel programq en un esfuerzo de mantenimiento, la organización de desarrollo o
por hacer que las modificaciones sean más efectivas. de soporte utilizará los resultados del análisis de
inventario para seleccionar el programa (1) que con-
¿Qué opciones existen tinúe utilizándose durante un número determinado
cuando nos enfrentamos de años, (2) que se esté utilizando con éxito en la
con un programa de diseño actualidad, y (3) que tenga probabilidades de sufrir
e implementeciónpobres? grandes modificaciones o mejoras en un futuro pró-
ximo. Entonces, se aplicarán las opciones 2, 3 ó 4
3. La posibilidad de rediseñar, recodificar y comprobar anteriores.
aquellas partes del software que requieran modifi-
Este enfoque de mantenimientopreventivo fue intro-
ducido por Miller [MIL811 con el nombre de «reajuste
estructurado». Definía este concepto como «la aplica-

551

hwttpw:/w/li.berelsrioal-uucniivoenrasirtaiori.an.beltogspot.com
.

INGENIERfA DEL SOFTWARE. U N ENFOQUE PRftCTICO

ción de las metodologías de hoy a los sistemas de ayer 30.5.1. Ingeniería directa para arquitecturas www.elsolucionario.net
para prestar apoyo a los requisitos del mañana». cliente/servidor

A primera vista, la sugerencia de volver a desarro- A lo largo de la última década, muchas aplicaciones de
llar un gran programa cuando ya existe una versión ope- grandes computadoras han sufrido un proceso de rein-
rativa puede parecer más bien extravagante. Sin geniería para adaptarlas a arquitecturas clientehervidor
embargo, antes de pasar a emitir un juicio, considéren- (C/S). En esencia, los recursos de computación centra-
se los puntos siguientes: lizados (incluyendo el software) se distribuyen entre
muchas plataformas cliente. Aunque se puede diseñar
1. El coste de mantener una línea de código fuente toda una gama de entornos distribuidosdistintos,la apli-
puede estar entre veinte y cuarenta veces por encima cación típica de computadora central que sufre un pro-
del coste del desarrollo inicial de esa línea. ceso de reingeniería para adoptar una arquitectura
cliente/servidor posee las características siguientes:
2. El rediseño de la arquitectura del software (del pro-
grama y/o de las estructuras de datos) empleando la funcionalidad de la aplicación migra hacia todas
conceptos de diseño modernos puede facilitar mucho las computadoras cliente;
el mantenimiento futuro. se implementan nuevas interfaces IGU en los cen-
tros clientes;
3. Dado que ya existe un prototipo del software, la pro-
ductividad de desarrollo deberá ser mucho más ele- las funciones de bases de datos se le asignan al ser-
vada que la media. vidor;
la funcionalidad especializada (por ejemplo, los aná-
4. En la actualidad, el usuario ya tiene experiencia con lisis de computación intensiva) pueden permanecer
el software. Por tanto, los nuevos requisitos y la direc- en el centro del servidor; y
ción del cambio se podrán estimarse con mucha más los nuevos requisitos de comunicaciones, seguridad,
facilidad. archivado y control deberán establecerse tanto en el
centro cliente, como en el centro servidor.
5. Las herramientas CASE para la reingeniería auto-
matizarán algunas partes del trabajo. dor

6. Cuando finalice el mantenimientopreventivo, se dis-
pondrá de una configuración completa del software
(documentos, programas y datos).

l a reingenieríaes muy similar al hecho de lavarse Es importante tener en cuenta que la migración des-
las dientes. Se puede pensor en mil razanes de computadoras centrales a un proceso C/S requiere
y tardar en lavárselas, dejándoloparo más tarde. tanto una reingeniería del negocio como una reinge-
Pera, al final, estas tácticas de retrasar los cosos niería del software. Además, es preciso establecer una
siempre volverán a randornos. «infraestructura de red de empresa». [JAY94]

Cuando una organización de desarrollo de software En algunos casas, los sistemas C/S o los sistemas O0
vende el software como un producto, el mantenimien-
to preventivo se ve como «nuevas versiones» del pro- diseñadosporo reemplazar una aplicación ontiguo deberán
grama. Un gran desarrollador de software local (por enfocarse como un proyecto nuevo de desarrollo.
ejemplo, un grupo de desarrollo de software de siste- La reingenieríaentra en juega solo cuando los elementos
mas para una compañía de productos de un consumidor de un sistema ontiguo se von a integrar con la nueva
de gran volumen) puede tener entre 500 y 2.000 pro- orquitecfvra. En algunos casos, quizós es mejor no aceptar
gramas de producción dentro de su dominio de respon- la viejay crear una funcionolidodnueva e idéntico.
sabilidad. Se podrán asignar prioridades a estos
programas según su importancia, y a continuación se La reingeniería de aplicaciones C/S comienza con
revisarán esos programas como los candidatos para el un análisis exhaustivo del entorno de negocios que abar-
mantenimiento preventivo. ca la computadora central existente. Se pueden identi-
ficar tres capas de abstracción- (Fig. 30.4).La base de
El proceso de ingeniería del software aplica prin- datos se encuentra en los cimientos de la arquitectura
cipios, conceptos y métodos de ingeniería del softwa- cliente/servidor, y gestiona las transacciones y consul-
re para volver a crear las aplicaciones existentes. En tas que proceden de las aplicaciones de servidor. Sin
la mayoría de los casos, la ingeniería directa no se limi- embargo, estas transacciones y consultas tienen que ser
ta a crear un equivalente moderno de un programa ante- controladas en el contexto de un conjunto de reglas de
rior, sino que más bien se integran los nuevos requisitos negocio (definidas por un proceso de negocio ya exis-
y las nuevas tecnologías 'en ese esfuerzo de volver a tente o que ha experimentado una reingeniería). Las
aplicar reingeniería. El programa que se ha vuelto a aplicaciones de cliente proporcionan la funcionalidad
desarrollar amplía las capacidades de la aplicación deseada para la comunidad de usuarios.
anterior.

552 ,

www.elsolucionario.net CAPfTULO 30 REINGENIERfA
.

Las funciones del sistema de gestión de bases de Un estudio completo sobre el diseño y reingeniería
datos ya existente y la arquitectura de datos de la base de software cliente/servidor es más adecuadopara otros
de datos existente deberán sufrir un proceso de inge- libros especializados en este materia. El lector intere-
niería inversa como precedente para el rediseño de la sado deberá consultar [VAS93], [INM93[ y [BER92].
capa de fundamento de la base de datos. En algunos
casos, se crea un nuevo modelo de datos (Capítulo 12). 30.5.2. Ingeniería directa para arquitecturas
En todos los casos, la base de datos C/S sufre un pro-
ceso de reingeniería para asegurar que las transaccio- orientadasa objetos
nes se ejecutan consistentemente; para asegurar que
todas las actualizaciones se efectúen únicamente por La ingeniería del software orientada a objetos se ha trans-
usuarios autorizados; para asegurar que se impongan formado en el paradigma opcional de desarrollo para
las reglas de negocios fundamentales (por ejemplo, antes muchas organizacionesde software. Sin embargo, ¿qué
de borrar el registro de un proveedor, el servidor se ase- sucede con las aplicaciones existentes que se desano-
gura de que no exista ningún registro pendiente, con- . llaron empleando métodos convencionales? En algunos
trato o comunicaciónpara ese proveedor);para asegurar casos, la respuesta consiste en dejar estas aplicaciones
que se puedan admitir las consultas de forma eficaz; y tal y como eran. Pero en otros casos, es preciso aplicar
para asegurar que se ha establecido una capacidad com- una reingeniería a las viejas aplicaciones para que se
pleta de archivado. puedan integrar fácilmente en grandes sistemas orienta-
dos a objetos.
Interfaz: IGU I www.elsolucionario.net
Aplicaciones cliente La reingeniería del software convencional para pro-
ducir una implementación orientada a objetos hace uso
Interfaz: solicitudes de proceso de muchas de las mismas técnicas descritas en la Cuar-
ta Parte de este libro. En primer lugar, se hace una inge-
T c niería inversa del software existentepara que sea posible
crear los modelos adecuados de datos, funcional y de
Interfaz: transacciones y consultas comportamiento. Si el sistema que se aplica a la reinge-
niería extiende la funcionalidad o comportamientode la
FIGURA 30.4. Proceso de reingeniería de apiicaciones aplicación original, se crean casos prácticos (Capítulos
de computadores centrales a cliente/servidor. 11y 21). Los modelos de datos creados durante la inge-
niería inversa se utilizan entonces junto con un modela-
La capa de reglas de negocios representa el software do CRC (Capítulo 21) para establecer la base para la
residente tanto en el cliente como en el servidor. Este definición de clases. Las jerarquías de clases, los mode-
software lleva a cabo las tareas de control y coordina- los de relaciones entre objetos, los modelos de compor-
ción para asegurar que las transacciones y consultas tamiento de objetos, y los subsistemas se definen a
entre la aplicación cliente y la base de datos se ajusten continuación, y comienza el diseño orientado a objetos.
a los procesos de negocios establecidos.
A medida que la ingenieríadirecta orientada a objetos
La capa de aplicación del cliente implementa las fun- pasa del análisishasta el diseño, se podrá invocar el mode-
ciones de negocios requeridas por grupos específicosde lo de proceso de ISBC (Capítulo27). Si la aplicación exis-
usuarios finales.En muchos casos, se segmenta una apli- tente se encuentracon un dominioya ha sidopopularizada
cación de computadora central en un cierto número de por muchas aplicaciones orientadas a objetos, es proba-
aplicaciones más pequeñas, sometidas a reingeniería, y ble que exista una biblioteca robusta de componentes y
adecuadas para su funcionamiento de sobremesa. La que se pueda utilizar durante la ingeniería directa.
comunicaciónentre aplicaciones de sobremesa (cuando
es necesaria) será controlada por la capa de reglas de Para aquellasclases que sea preciso construirpartiendo
negocios. de cero, quizá sea posible reutilizar algoritmos y estruc-
turas de datos procedentes de la aplicaciónconvencional
ya existente. Si embargo, es preciso volver a diseñarlos
para ajustarse a la arquitectura orientada a objetos.

30.5.3. Ingeniería directa para interfaces

de usuario

Cuando las aplicacionesmigrandesde la computadora cen-
tral a la computadora de sobremesa, los usuarios ya no
están dlspuestosa admitir unas interfaces de usuarios arca-
nas basadas en caracteres. De hecho, una parte significa-
tiva de todos los esfuerzos invertidos en la transición desde
la computación de computadora central hasta la arquitec-
tura cliente/servidor se pueden reinvertir en la reingenie-
ría de las interfaces de usuario de la aplicación cliente.

553

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

¿Cuáles son los pasos a seguir siendo los mismos. La interfaz diseñada deberá seguir www.elsolucionario.net
para una ingeniería de interfaz permitiendo que el usuario muestre el comportamiento
de usuario? de negocios adecuado. Por ejemplo, cuando se efec-
túa una consulta en una base de datos, es posible que,
Merlo y colaboradores [MER95] sugieren el modelo para especificar la consulta, la interfaz vieja necesite
siguiente para la reingeniería de interfaces de usuario: una serie larga de órdenes basadas en textos. La IGU
sometida a reingeniería puede hacer que la consulta
1. Comprender la interfaz original y los datos que se sea más eficiente,reduciéndola a una pequeña secuen-
trasladan entre ella y el resto de la aplicación. El cia de seleccionescon el ratón, pero la intención y el
objetivo es comprender la forma en que los demás contenidode la consultadeberán permanecer intactas.
elementos del programa interactúan con el código
existente que implementa la interfaz. Si se ha de desa- 3 . Introducir mejoras que hagan que el modo de inter-
rrollar una nueva IGU, entonces el flujo de datos acción sea más eficiente. Los fallos ergonómicos de
entre la IGU y el resto del programa deberá ser con- la interfaz existente se estudian y se corrigen en el
secuente con los datos que en la actualidad fluyen diseño de la IGU nueva.
entre la interfaz basada en caracteres y el programa.
4. Construir e integrar la IGU nueva. La existencia de
2. Remodelar el comportamiento implícito en intedaz bibliotecas de clases y de herramientas de cuarta
existente paraformar una serie de abstracciones que generación puede reducir el esfuerzo requerido para
tengan sentido en el contexto de una IGU. Aunque el construir la IGU de forma significativa.Sin embargo,
modelo de interacciónpueda ser radicalmentedistinto, la integración con el software de aplicación ya exis-
el comportamientode negociosmostradopor los usua- tente puede llevar más tiempo. Para asegurarse de
rios de la interfaz nueva y vieja (cuando se consideran que la IGU no propague unos efectos adversos al
en función del escenario de utilización) deberán seguir resto de la aplicación es preciso tener cuidado.

En un mundo perfecto, todo programa que no se pudie- El coste asociado al mantenimiento continuado de
ra mantener se retiraría inmediatamente, para ser susti- una aplicacióncandidata (esto es, si no se realiza la rein-
tuido por unas aplicaciones de alta calidad, fabricadas geniería) se puede definir como:
mediante reingeniería y desarrolladas empleando las
prácticas de la ingeniería del software modernas. Sin Crnafl=t [P, - ( P i + 4 1 x L (30.1)
embargo, vivimos en un mundo de recursos limitados.
La reingeniería consume recursos que se pueden utili- Los costes asociados con la reingeniería se definen
zar para otros propósitos de negocio. Consiguiente- empleando la relación siguiente:
mente, antes de que una organización intente efectuar
una reingeniería de la aplicación existente, deberá lle- Creifl=g [p6- (p4+4 1 x (L- p s )- ( p , x p,)I (30.2)
var a cabo un análisis de costes y beneficios.
Empleando los costes presentados en la ecuaciones
Sneed [SNE95]ha propuesto un modelo de análisis (30.1) y (30.2), los beneficios globales de la reingenie-
de costes y beneficios para la reingeniería. Se definen ría se pueden calcular en la forma siguiente:
nueve parámetros:
Beneficio y coste = Creing- Cmant (30.3)
P , = coste de mantenimiento anual actual para una
aplicación; El análisis de costes y beneficios presentados en
las ecuaciones anteriores se puede llevar a cabo para
P , = coste de operación anual de una aplicación; todas aquellas aplicaciones de alta prioridad que se
hayan identificado durante un análisis de inventario
P , = valor de negocios anual actual de una aplicación; (Sección 30.2.2). Aquellas aplicaciones que muestren
el mayor beneficio en relación con los costes podrán
P, = coste de mantenimientoanual predicho después destinarse a la reingeniería, mientras que las demás
de la reingeniería; podrán ser propuestas hasta que se disponga de más
recursos.
P, = coste de operacionesanual predicho después de
la reingeniería;

P, = valor de negocio actual predicho después de la
reingeniería;

P , = costes de reingeniería estimados;

P , = fecha estimada de reingeniería;

P , = factor de riesgo de la reingeniería (P, = 1,O es
el valor nominal);

L = vida esperada del sistema.

554

www.elsolucionario.net CAPITULO 30 R E I N G E N I E R ~ A
.

La ingeniería se produce en dos niveles distintos de dad -se trata de programas que sean viables hasta bien www.elsolucionario.net
abstracción. En el nivel de negocios, la reingeniería entrado el siglo veintiuno-.
se concentra en el proceso de negocios con la inten-
ción de efectuar cambios que mejoren la competitivi- El análisis de inventarios permite que una organiza-
dad en algún aspecto de los negocios. En el nivel del ción estime todas y cada una de las aplicaciones siste-
software, la reingeniería examina los sistemas y apli- máticamente, con el fin de determinar cuáles son las
caciones de información con la intención de rees- candidatas para una reingeniería. La reestructuración
tructurarlos o reconstruirlos de tal modo que muestren de documentos crea un marco de trabajo de documen-
una mayor calidad. tos necesario para el apoyo de una cierta aplicación a
largo plazo. La ingeniería inversa es el proceso de ana-
La reingeniería de procesos de negocio (RPN) defi- lizar un programa en un esfuerzo por extraer informa-
ne los objetivos de negocios, identifica y evalúa los ción acerca de los datos, de su arquitectura y del diseño
procesos de negocios ya existentes (en el contexto de de procedimientos. Por Último, la ingeniería directa
los objetivos definidos), especifica y diseña los pro- reconstruye el programa empleando prácticas de inge-
cesos revisados, y construye prototipos, refina e ins- niería moderna del software y la información obtenida
tancia esos procesos en el seno de un negocio. La RPN durante la ingeniería inversa.
tiene un objetivo que va más allá del software. Su resul-
tado suele ser la definición de formas en que las tec- Los costes y beneficios de la reingeniería se pue-
nologías de la información puedan prestar un mejor den determinar de forma cuantitativa. El coste del sta-
apoyo a los negocios. tus quo, esto es, los costes asociados al mantenimiento
y soporte que conlleva una aplicación existente se pue-
La reingeniería del software abarca una serie de acti- de comparar con los costes estimados de la reingenie-
vidades entre las que se incluye el análisis de inventa- ría, y con la reducción resultante de los costes de
rio, la reestructuración de documentos, la ingeniería mantenimiento. En casi todos los casos en que un pro-
inversa, la reestructuración de programas y datos, y la grama tiene una vida larga y muestra en la actualidad
ingeniería directa. El objetivo de esas actividades con- un mantenimiento dificultoso, la reingeniería repre-
siste en crear versiones de los programas existentes que senta una estrategia de negocios eficiente en relación
muestren una mayor calidad, y una mejor mantenibili- con los costes.

[ARN89] Arnold, R. S., «Software Restructuring», Proc. [DEM95] DeMarco, T., «Lean and Meann, IEEE Software,
IEEE, vol. 77, n.’ 4, Abril de 1989, pp. 607-617. Noviembre de 1995, pp. 101-102.

[BER92] Berson, A., ClientlSewer Architecture, McGraw- [DIC95] Dickinson, B., Strategic Business Reengineering,
Hill, 1992. LCI Press, 1995.

[BLE93] Bleakley, F.R., «The Best Plans: Many Companies [HAM90] Hammer, M., «ReengineerWork: Don’t Automa-
Try ManagementFads, Only to See Them Flop», The Wall te, Obliterate», Harvard Business Review, Julio-Agosto
Street Journal, 6 de Julio de 1993, p. 1. de 1990, pp. 104-112.

[BRE91] Breuer, P.T., y K. Lano, «Creating Specification [HAN931 Hanna, M., «Maintenance Burden Begging for a
From Code: Reverse-Engineering Techniquew, Journal Remedy», Datamation, Abril de 1993, pp. 53-63.
of Sofmare Muintenance: Research and Practice, vol. 3,
Wiley, 1991, pp. 145-162. [INM93] Inmon, W.H., Developing Client Server Applica-
tions, QED Publishing, 1993.
[CAN721 Canning, R., «The Maintenance “Iceberg”», EDP
Analyzer, vol. 10, n.O 10, Octubre de 1972. [JAY94] Jaychandra, Y., Re-engineering the Networked Enter-
prise», McGraw-Hill, 1994.
[CASSS] «Case Tools for Reverse Engineering», CASE Out-
look, CASE Consulting Group, Lake Oswego, OR, vol. 2, [MAR941 Markosian, L. et al., «Using an Enabling Techno-
n.’ 2, 1988, pp. 1-15. logy to Reengineer Legacy Systems, CACM, vol. 37, n.O 5,
Mayo de 1994, pp. 58-70.
[CHI90] Chifofsky, E.J., y J.H. Cross, 11, «Reverse Enginee-
ring and Design Recovery: A Taxonomy», IEEE Sofmare, [MER93] Merlo, E. et al., «Reverse Engineering of User
Enero de 1990, pp. 13-17. Interfacew, Proc. Working Conference on Reverse Engi-
neering, IEEE, Baltimore, MD, Mayo de 1993, pp. 171-
[DAV90] Davenport, T.H., y J.E. Young, «The New Indus- 178.
trial Engineering: Information Technology and Business
F’rocess Redesigm, Sloan Munugement Review, Summer [MER95] Merlo, E. et al., «Reengineering User Interfacew,
1990, pp. 11-27. IEEE Software, Enero de 1995, pp. 64-73.

555

www.elsolucionario.net

INGENIERfA DEL SOFTWARE. UN ENFOQUE PRACTICO .

[MIL811Miller, J., Techniques of Prograrn and Systern Main- [STE93] Steward, T.A., «Reengineering:The Hot New Mana-
tenance (G. Parikh, ed.), Winthrop Publishers, 1981. ging Tool», Fortune, 23 de Agosto de 1993, pp. 41-48.

[OSB90] Osbome, W.M., y E.J. Chifofsky, «Fitting Pieces to [SWA76] Swanson, E.B., «The Dimensions of Maintenan-
the Maintenance Puzzle», IEEE Soflware, Enero de 1990, ce», Proc. 2nd Intl. Conf. Software Engineering, IEEE,
pp. 10-11. Octubre de 1976, pp. 492-497.

[PRE94] Premerlani, W.J., y M.R. Blaha, «An Approach for [VAS931Vaskevitch, D., ClientlServer Strategies, IDG Books,
Reverse Engineering of Relational Databasew, CACM, San Mateo, CA, 1993.
vol. 37, n.' 5, Mayo de 1994, pp. 42-49.
[WAR74] Wamier, J.D., Logical Construction of Prograrns,
[RIC89]Ricketts,J.A., J.C. DelMonaco y M.W. Weeks, «Data VanNostrand Reinhold, 1974.
Reengineering for Application Systemw, Proc. Conf. Soft-
ware Maintenance-1989, IEEE, 1989, pp. 174-179. [WEI95] Weisz, M., «BPR is Like Teenage Sex», Arnerican
Prograrnrner,vol. 8, n.' 6, Junio de 1995, pp. 9-15.

P m Y-P CON- 30.5. Sugiera alternativas para el papel y el lápiz o para la www.elsolucionario.net
documentación electrónica convencional que puedan servir
30.1. Considere cualquier trabajo que haya desempeñado en como base para la reestructuración de documentos. [Pista:
los últimos cinco años. Describa el proceso de negocios en Piense en las nuevas tecnologías descriptivas que se podrían
que haya desempeñado su función. Utilice el modelo RPN utilizar para comunicar el objetivo del software.]
descrito en la Sección 30.1.3 para recomendar cambios en el
proceso con la intención de hacerlo más eficiente. 30.6. Algunas personas creen que las técnicas de inteligencia
artificial incrementarán el nivel de abstracción de los proce-
30.2. Realice una investigación acerca de la eficacia de la rein- sos de ingeniería inversa. Efectúe una investigación sobre este
geniería de procesos de negocios. Presente argumentosa favor tema (esto es, el uso de la IA para ingeniería inversa) y escri-
y en contra de este enfoque. ba un artículo breve que se decante por este tema.

30.3. Su profesor seleccionará uno de los programas que haya 30.7. ¿Por qué es más difícil lograr la completitud a medida
desarrollado alguien de la clase durante el curso. Intercambie que el nivel de abstracción crece?
su programa aleatoriamente con cualquier otra persona de la
clase. No le explique ni revise el programa. A continuación, 30.8. ¿Por qué tiene que incrementarse la interactividad si es
implemente una mejora (especificada por el instructor) en el preciso incrementarse la completitud?
programa que haya recibido.
30.9. Obtenga literatura de productos correspondientes a tres
a. Lleve a cabo todas las tareas de ingeniería del software herramientas de ingeniería inversa y presente sus caracterís-
incluyendo una breve revisión (pero no con el autor del ticas en clase.
programa).
30.10. Existe una diferencia sutil entre la reestructuración y
b. Lleve la cuenta cuidadosamentede todos los errores encon- la ingeniería directa. ¿En qué consiste?
trados durante la comprobación.
30.11. Investigue en la literatura para hallar uno o dos artícu-
c. Describa su experiencia en clase. los que describan casos prácticos de reingeniería de grandes
computadoras para producir una arquitectura cliente/servidor.
30.4. Explore la lista de comprobación del análisis de inventa- Presente un resumen.
rio presentada en el sitioWeb SEPAe intente desarrollarun sis-
tema de evaluación cuantitativodel softwareque se pueda aplicar 30.12. ¿Cómo se determinarían los valores de P, a P, en el
a los programasexistentes en un esfuerzo de seleccionarlos pro- modelo de costes y beneficios presentado en la Sección 30.6?
gramas candidatos para su reingeniería. Su sistema deberá ir
más allá del análisis económicopresentado en la Sección 30.6.

Al igual que muchos tópicos candentes dentro de la comuni- 1997),Hunt (ProcessMapping: How to Reengineer YourBusi-
dad de negocios, el bombo publicitario de la reingeniería de ness Processes, Wiley 1996), y Carr y Johanson (Best Prac-
procesos de negocios ha dado pie a una visión más pragmáti- tices in Reengineering: What Works and WhatDoesn't in the
ca del tema. Hammer y Champy (Reengineering the Corpo- Reengineering Process, McGraw-Hill, 1995) presentan casos
ration, HarperCollins, 1993) anticiparon gran interés por el prácticos y líneas generales detalladas para RPN.
tema con su best seller. Posteriormente, Hammer (Beyond
Reengineering: How the Processed-Centered Organization is Feldmann (ThePractica1Guide to Business Process Reen-
Changing Our Work and Our Lives, Harper-Collins, 1997)refi- gineering Using IDEFO, Dorset House, 1998) estudia una
nó su visión centrándose en temas «centrados en procesos». notación modelada que ayuda en la RPN. Berztiss (Sofiare
Methodsfor Business Reengineering, Spnnger, 1996)y Spurr
Los libros de Andersen (Business Process Irnprovernent y colaboradores (SoftwareAssistance for Business Reengi-
Toolhox,American Society for Quality, 1999), Harrington et neering, Wiley, 1994) estudian las herramientas y técnicas
al. (Business Process Improvement Workhook,McGraw-Hill, que facilitan la RPN.

556

httpw://lwibwre.reial-suonliuvecrisointaarirai.ob.lnogestpot.com CAPfTULO 30 REINGENIERÍA
.

Relativamente pocos libros se han dedicado a la reingenie- mation Architectures: Reengineering Information Systems,
ría del software. Rada (Reengineering Software: How to Reu- Prentice Hall, 1996) estudia el puente que existe entre RPN
se Programming to Build New, State-Of-The-Art Sofbvare, y la tecnología de información. Aiken (Data Reverse Engi-
Fitzroy Dearborn Publishers, 1999) se centra en la reinge- neering, McGraw-Hill, 1996) estudia cómo reclamar, reor-
niería a p n nivel técnico. Miller (Reengineering Legacy Sofr- ganizar y reutilizar los datos de la organización. Arnold
ware Systems, Digital Press, 1998) «proporciona un marco (Software Reengineering, IEEE Computer Society Press,
de trabajo para mantener los sistemas de aplicaciones sin- 1993) ha publicado una antología excelente de los primeros
cronizados con las estrategias de negocios y con los cambios trabajos sobre las tecnologías de reingeniería del software.
tecnológicos». Umar (Application(Re)Engineering:Building
Web-BasedApplications and Dealing WithLegacies, Prentice En Intemet se disponen de gran variedad fuentes de infor-
Hall, 1997)proporciona una guía valiosa para aquellas orga- mación sobre la reingeniería de procesos de negocios y la
nizaciones que quieren transformar los sistemas antiguos en reingeniería del software. Una lista actualizada de referen-
un entorno basado en Web. Cook (Building Enterprise Infor- cias a sitios (páginas) web se puede encontrar en la dirección
http:/www.pressrnanS.com.

www.elsolucionario.net

557

www.elsolucionario.net
.

www.elsolucionario.net

CAPÍTULO www.elsolucionario.net
.
31
INGENIERÍA DEL SOFTWARE
ASISTIDA POR COMPUTADORA

TODO el mundo ha oído ese proverbio que habla de los hijos del zapatero: el zapatero www.elsolucionario.net
está tan ocupado haciendo zapatos para los demás que sus hijos no tienen sus propios
zapatos. Antes de los años 90, muchos de los ingenieros de software fueron los hijos del
zapatero. Aunque estos profesionales técnicos construyeron sistemas complejos y productos
que automatizan los trabajos de otros, no utilizaron mucha automatización para ellos mismos.

En la actualidad, los ingenieros de software han recibido por fin su primer par de zapatos
nuevos -la ingeniería del software asistida por computadora (CASE)-. Los zapatos no vie-
nen con tanta variedad como querrían, a veces son un poco duros y en algunos casos resultan
incómodos, no proporcionan una sofisticación suficiente para los que los gustan de vestir bien,
y no siempre coinciden con la ropa que utilizan los que desarrollan el software. Ahora bien,
suponen una prenda absolutamente esencial en el guardarropa del que desarrolla el software y,
con el tiempo, serán más cómodos, se utilizarán con más facilidad y se adaptarán mejor a las
necesidades de cada uno de los desarrolladores.

En los capítulos anteriores de este libro se ha intentado proporcionar una explicación razo-
nable para comprender lo que sucede entre bastidores dentro de la tecnología de la ingeniería
del software. En este capítulo, nuestro centro de interés se desplaza hacia las herramientas y
entornos que ayudarán a automatizar el proceso del software.

559

www.elsolucionario.net

.

INGENIERfA DEL SOFTWARE. U N ENFOQUE PRÁCTICO

31.1 J Q ~ ?

El mejor taller de un artesano -sea mecánico, carpin- El taller de ingeniería del software se denomina un
tero o ingeniero del software-tiene tres característi- entorno de apoyo integrado a proyectos (que se des-
cas fundamentales: (1) una colección de herramientas cribirá posteriormente en este capítulo), y el conjunto
útiles que le ayudarán en todos los pasos de la cons- de herramientas que llena ese taller se denomina inge-
trucción de un producto; (2) una disposición organiza- niería del software asistida por computadora (CASE).
da que permitirá hallar rápidamente las herramientas y
utilizarlas con eficacia; y (3) un artesano cualificado que CASE proporciona al ingeniero la posibilidad de
entienda la forma de utilizar las herramientas de mane- automatizar actividadesmanuales y de mejorar su visión
ra eficaz. Ahora es cuando los ingenieros del software general de la ingeniería. Al igual que las herramientas
reconocen que necesitan más herramientas y más varia- de ingeniería y de diseño asistidos por computadoraque
das junto con un taller eficiente y organizado en el que utilizan los ingenieros de otras disciplinas, las herra-
puedan ubicarlas. mientas CASE ayudan a garantizar que la calidad se
diseñe antes de llegar a construir el producto.

La ingeniería del software asistida por computadora permiten a cada una de las herramientas comunicarse www.elsolucionario.net
puede ser tan sencilla como una única herramienta que entre sí, para crear una base de datos del proyecto, y
preste su apoyo para una única actividad de ingeniería para mostrar el mismo aspecto al usuario final (el inge-
del software, o tan compleja como todo un entorno que niero del software). Los servicios de portabilidad per-
abarque «herramientas», una base de datos, personas, miten que las herramientas CASE y su marco de
hardware, una red, sistemas operativos, estándares, y integración migren entre distintas plataformas del hard-
otros mil componentes más. Los bloques de construc- ware y sistemas operativos sin un mantenimiento adap-
ción de CASE se ilustran en la Figura 31.1. Cada blo- tativo significativo.
que de construcción forma el fundamento del siguiente,
estando las herramientas situadas en la parte superior Herramientas CASE
del montón. Es interesante tener en cuenta que el fun-
damento de los entornos CASE efectivos tiene relati- 21 cMarco de integración
vamente poco que ver con las herramientas de ingeniería
del software en sí. Más bien, los entomos para la inge-
niería del software se construyen con éxito sobre una
arquitectura de entornos que abarca un hardware y un
software de sistemas adecuados. Además, la arquitec-
tura del entorno deberá tener en cuenta los patrones de
trabajo humano que se aplicarán durante el proceso de
ingeniería del software.

FIGURA 31.1. Bloques de construcción CASE.

Las arquitecturas del entorno,que constan de una pla- Los bloques de construcción representados en la
taforma hardware y de un soporte de sistema operativo Figura 3 1.1 representan un fundamento completo para
(incluyendo software de red, gestión de la base de datos la integración de herramientas CASE. Sin embargo, la
y servicios de gestión de objetos), establece los cimien- mayor parte de las herramientas CASE que se utilizan
tos para un entorno CASE. Pero el entorno CASE en sí en la actualidad no han sido construidas empleando
requiere otros bloques de construcción. Existe un con- todos los bloques de construcción anteriormente des-
junto de servicios de portabilidad que proporciona un critos. De hecho, algunas herramientas siguen siendo
puente entre las herramientas CASE, su marco de inte- las «soluciones puntuales». Esto es, una herramientase
gración y la arquitectura del entorno. El marco de inte- utiliza para prestar apoyo en una actividad de ingenie-
gración es un grupo de programas especializados que ría del software concreta (por ejemplo, modelado de
análisis), pero esta herramienta no se comunica direc-
tamente con otras, no está unida a una base de datos del
proyecto, y no forma parte de un entorno integrado

560

www.elsolucionario.net
.

CAPfTULO 31 INGENIERfA DEL SOFTWARE ASISTIDA POR C O M P U T A D O R A

CASE (1-CASE). Aunque esta situación no es la ideal, puente entre herramientas (por ejemplo,una herramienta
se puede utilizar una herramienta CASE bastante efi- de análisis y diseño que se enlaza con un generador de
ciente, aunque se trate de una solicitud puntual. código). Mediante la utilización de este enfoque, la siner-
gia entre herramientas puede producir unos resultados
Fuente única finales que serían difíciles de crear empleando cada una
de las herramientas por separado. La integración de
Intercambio de datos fuente única se produce cuando un único vendedor de
herramientas CASE integra una cierta cantidad de herra-
Puentes y asociaciones mientas distintas y las vende en forma de paquete. Aun-
que este enfoque es bastante eficiente, la arquitectura
? ? ? ?entre herramientas cerrada de la mayoría de los entornos de fuente Única
evita añadir fácilmente herramientas procedentes de
otros fabricantes.

EAIP las herramientas CASE de soluciónpuntual pueden
praparcionar un beneficio sustancia/, pero un equipa de
FIGURA 31.2. Opciones integradas. software necesitaherramientas que se comuniquenentre www.elsolucionario.net
sí. las herramientas integradas ayudan a que el equipa
Los niveles relativos de integración CASE se mues- desarrolle, organice y controlelos productos del trabaja.
tran en la Figura 3 1.2. En el extremo inferior del espec- Utilicelas.
tro de integración se encuentra la herramienta individual
(solución puntual). Cuando las herramientas individuales En el extremo superior del espectro de integración
proporcionan servicios para el intercambio de datos se encuentra el entorno de apoyo integrado a proyec-
(como lo hacen la mayoría), el nivel de integración mejo- tos integrado (EAIP). Se han creado estándares en cada
ra ligeramente. Estas herramientas producen su salida uno de los bloques de construcción descritos anterior-
en un formato estándar que deberá ser compatible con mente. Los fabricantes de herramientas CASE utilizan
otras herramientas que sean capaces de leer ese forma- los estándares EAIP para construir herramientas que
to. En algunos casos, los constructores de herramientas sean compatibles con el EAIP, y que por tanto sean com-
CASE complementarias trabajan juntos para formar un patibles entre sí.

Existe un cierto número de riesgos que son inherentes nistradores o personal técnico, por su utilización en los
siempre que se intenta efectuar una categorización de distintos pasos del proceso de ingeniería del software,
las herramientas CASE. Existe una sutil implicación que por la arquitectura del entorno (hardware y software)
consiste en que para crear un entorno CASE efectivo se que les presta su apoyo, o incluso por su origen o cos-
deberán implementartodas las categoríasde herramientas te [QED89]. La taxonomía que se presenta a continua-
4 s t o no es ni sencillo, ni cierto-. Cuando hay perso- ción utiliza como criterio principal la función.
nas que creen que una herramienta pertenece a una cate-
goría, se puede crear cierta confusión (o contradicción) Herramientas CASE
al ubicar una herramienta específicadentro de otra cate-
goría. Es posible que algunos lectores piensen que se ha Herramientas de ingeniería de procesos de nego-
omitido una categoría completa -1iminando por tan- cio. Al modelar los requisitos de información estraté-
to un conjunto de herramientas completo e incluirlo así gica de una organización, las herramientasde ingeniería
en el entorno CASE global-. Además, una categoriza- de procesos de negocios proporcionan un «metamo-
ción sencilla tiende a ser plana - e s t o es, no se muestra delo» del cual se derivan sistemas de información espe-
la interacciónjerárquica de las herramientas o las rela- cíficos. En lugar de centrarse en los requisitos de una
ciones que existen entre ellas-. A pesar de estos ries- aplicación específica, estas herramientas CASE mode-
gos, es necesario crear una taxonomía de herramientas lan la información de negocio cuando ésta se transfiere
CASE -para comprender mejor la amplitud de CASE entre distintas entidades organizativasen el seno de una
y para apreciar mejor en donde se pueden aplicar estas
herramientas dentro del proceso del software-.

Las herramientas CASE se pueden clasificar por su
función, por su papel como instrumentos para admi-

561


Click to View FlipBook Version