Las Herramientas de Ayuda al Desarrollo de Sistemas

de Información, surgieron para intentar dar solución a los

problemas inherentes a los proyectos de generación de
aplicaciones informáticas: plazos y presupuestos
incumplidos, insatisfacción del usuario, escasa
productividad y baja calidad de los desarrollos. Algunas de
estas herramientas se dirigen principalmente a mejorar la
calidad, como es el caso de las herramientas CASE
(Computer Aided Software Engineering-Ingeniería de
Software Asistida por Ordenador). Otras van dirigidas a
mejorar la productividad durante la fase de construcción,
como es el caso de los lenguajes de cuarta generación (4GL-
Fourth Generation Language).
En el presente se describen las principales
herramientas de ayuda al desarrollo de Sistemas de
Información, existentes en la actualidad: CASE, 4GL y otras
herramientas de carácter específico. También se describe su
funcionalidad y las características más relevantes, con la
finalidad de ayudar en la elección de la herramienta
adecuada a cada caso.
Conceptos y funcionalidades básicas
El presente describe los componentes esenciales y las
funcionalidades de las diferentes herramientas de ayuda al
desarrollo.
Los principales conceptos utilizados en las
herramientas de ayuda al desarrollo son los siguientes:
Ayuda de la herramienta. Es una ayuda incorporada al
programa, brindando información sobre el uso de los
componentes de la propia herramienta, de fácil acceso y
con utilidades de búsqueda de temas o palabras claves. Una
ayuda interactiva evita el manejo de manuales.
Diccionario de datos. Descripción lógica de los datos para
el usuario. Reúne la información sobre los datos
almacenados en una base de datos (descripción, significado,
estructura, consideraciones de seguridad y uso de
aplicaciones, etc.).
Ingeniería del software. Es el tratamiento sistemático de
todas las fases del ciclo de vida del software, abordando el
desarrollo de sistemas de información de forma similar a los
proyectos de ingeniería. Esto implica la identificación de las
tareas a realizar (establecidas según una metodología de
desarrollo), de los productos a obtener y de las técnicas y
herramientas a utilizar.
Ingeniería directa. Es el proceso de producción del código
de una aplicación a partir de sus especificaciones.
Ingeniería inversa. Conjunto de tareas destinadas a
obtener las especificaciones de un sistema de información,
partiendo del propio sistema. Es una actividad típica del
mantenimiento de aplicaciones, cuando no existen las
especificaciones de diseño de la aplicación a mantener.
Metodología de planificación y desarrollo de
aplicaciones. Es el conjunto de métodos que basados en
unos principios, se integran en el marco del ciclo de vida de
los sistemas. La metodología debe recoger las tareas a
realizar, los responsables de cada una de ellas y los
productos a obtener en el desarrollo de un sistema de
información. También puede incluir o hacer referencia a las
técnicas a emplear en cada momento.
Reingeniería de Sistemas. Es la modificación de los
componentes de una aplicación, sin cambiar sus
funcionalidades, por ejemplo: la mejora de la codificación de
un programa. A veces también se emplea este término para
referirse conjuntamente a la ingeniería directa e inversa.
Sistema de Información - SI. Conjunto de elementos
físicos, lógicos, de comunicación, datos y personal que,
interrelacionados, permiten el almacenamiento, transmisión
y proceso de la información.
Workbench. Es una interfase gráfica que permite modelar
procesos y datos. Está basada en el mismo principio de la
programación visual: no se emplea lenguajes procedurales
sino iconos, los cuales no son dibujos del tipo flow, sino
objetos que se almacenan en el repositorio.
Permiten aplicar la recursividad, es decir que los
modelos son vistos en diferentes niveles de detalle, lo cual
permite un uso eficiente de las técnicas de análisis de
procesos. Permite manejar diferentes metodologías de
análisis y diseño. Sirve de ayuda metodológica para quienes
no están habituados a usarlas.
HERRAMIENTAS
Herramientas CASE
Son un conjunto de métodos, utilidades y técnicas que
facilitan la automatización del ciclo de vida del desarrollo de
sistemas de información, completamente o en alguna de
sus fases.
El empleo de herramientas Case permiten integrar el
proceso de ciclo de vida:
 Análisis de datos y procesos integrados mediante un
repositorio.
 Generación de interfases entre el análisis y el diseño.
 Generación del código a partir del diseño.
 Control de mantenimiento.
Actualmente, la tendencia en el desarrollo de software
está enfocada hacia las microcomputadoras como
plataformas de ingeniería de software, que se interconectan
mediante redes para que puedan comunicarse de forma
efectiva. La base de datos del proyecto (también
denominada biblioteca del proyecto o depósito de software),
está disponible a través de un servidor de archivos en red
que es accesible desde todas las estaciones de trabajo. Un
sistema operativo que gestiona el hardware, la red y las
herramientas, mantiene todo el entorno unido.
La arquitectura de entorno, compuesta por la
plataforma hardware y el soporte del sistema operativo
(incluida la red y la gestión de la base de datos), constituye
la base del CASE. Pero el entorno CASE, en sí mismo,
necesita otros componentes. Un conjunto de servicios de
portabilidad constituyen un puente entre las herramientas
CASE y su marco de integración y la arquitectura de
entorno. El marco de integración es un conjunto de
programas especializados que permite a cada herramienta
CASE comunicarse con las demás, para crear una base de
datos de proyectos y mostrar una apariencia homogénea al
usuario final (el ingeniero de software). Los servicios de
portabilidad permiten que las herramientas CASE y su
marco de integración puedan migrar a través de diferentes
plataformas hardware y sistemas operativos, sin grandes
esfuerzos de adaptación.
 La mayoría de las herramientas Case no han sido
construidas utilizando todos los bloques componentes.
Muchas de éstas son soluciones puntuales, esto es, una
herramienta se utiliza como ayuda en una actividad
concreta de ingeniería de software (por ejemplo:
modelización del análisis), pero no se comunica
directamente con otras herramientas, porque no está unida
a una base de datos de proyectos. Aunque esta situación no
es la ideal, una herramienta Case puede ser utilizada
eficientemente, aún siendo una solución puntual.
En el nivel más bajo del espectro de integración está la
herramienta individual (solución puntual). Cuando las
herramientas proporcionan facilidades para el intercambio
de datos (la mayoría lo hace), el nivel de integración
aumenta ligeramente. Estas herramientas generan una
salida en un formato estándar compatible con otras
herramientas que puedan leer ese formato. En algunos
casos, los que construyen herramientas CASE
complementarias trabajan juntos para establecer un puente
entre ellas (p. ej.: una herramienta de análisis y diseño que
se une a un generador de código). Utilizando este enfoque,
la compatibilidad entre herramientas puede generar
productos finales que serían difíciles de desarrollar
utilizando cada herramienta por separado. La integración
por fuente única se da cuando un constructor de
herramientas CASE integra diferentes herramientas y las
vende como un único paquete. Aunque este enfoque es
bastante efectivo, la mayoría de los entornos provenientes
de una misma fuente tienen una arquitectura cerrada que
hace difícil añadir nuevas herramientas de otros
vendedores.
Al final del espectro de integración está el entorno de
soporte de proyectos integrado (del inglés IPSE). Se crean
estándares para cada uno de los bloques componentes. Los
vendedores de herramientas CASE utilizan estos estándares
IPSE para construir herramientas entre sí.

La principal ventaja de la utilización de una

herramienta CASE, es la mejora de la calidad de los
desarrollos realizados y, en segundo término, el aumento de
la productividad. Para conseguir estos dos objetivos es
conveniente contar con una organización y una metodología
de trabajo además de la propia herramienta.
La mejora de calidad se consigue reduciendo
sustancialmente muchos de los problemas de análisis y
diseño, inherentes a los proyectos de mediano y gran
tamaño (lógica del diseño, coherencia, consolidación, etc.).
La mejora de productividad se consigue a través de la
automatización de determinadas tareas como la generación
de código y la reutilización de objetos o módulos.
Tipos de Case
No existe una única clasificación de herramientas CASE
y, en ocasiones, es difícil incluirlas en una clase
determinada. Podrían clasificarse atendiendo a:
 Las plataformas que soportan.
 Las fases del ciclo de vida del desarrollo de sistemas
que cubren.
 La arquitectura de las aplicaciones que producen.
 Su funcionalidad.
 Las herramientas CASE, en función de las fases del
ciclo de vida abarcadas, se pueden agrupar de la forma
siguiente:
 Herramientas integradas, I-CASE (Integrated
CASE, CASE integrado): abarcan todas las fases del ciclo de
vida del desarrollo de sistemas. Son llamadas también CASE
workbench.
 Herramienta(s) que comprende(n) alguna(s)
fase(s) del ciclo de vida de desarrollo de software:
 Herramientas de alto nivel, U-CASE (Upper CASE -
CASE superior) o front-end, orientadas a la automatización y
soporte de las actividades desarrolladas durante las
primeras fases del desarrollo: análisis y diseño.
 Herramientas de bajo nivel, L-CASE (Lower CASE -
CASE inferior) o back-end, dirigidas a las últimas fases del
desarrollo: construcción e implantación.
 Juegos de herramientas o toolkits, son el tipo más
simple de herramientas CASE. Automatizan una fase dentro
del ciclo de vida. Dentro de este grupo se encontrarían las
herramientas de reingeniería, orientadas a la fase de
mantenimiento.
Las herramientas I-CASE se basan en una
metodología. Tienen un repositorio y aportan técnicas
estructuradas para todas las fases del ciclo de vida. Estas
son las características que les confieren su mayor ventaja:
una mejora de la calidad de los desarrollos. Sin embargo, no
todas ellas son modernas en el sentido de aprovechar la
potencia de las estaciones de trabajo o la utilización de
lenguajes de alto nivel o técnicas de prototipeo.
Una estrategia posible es utilizar una U-CASE para
análisis y diseño, combinada con otras herramientas más
modernas para las fases de construcción y pruebas. En este
caso, habría que vigilar cuidadosamente la integración entre
las distintas herramientas.
Requisitos de aplicación de Case:
 Conocimiento y manejo de metodologías.
 Capacidad de trabajo en equipo.
 Desarrollo conjunto con los usuarios (Prototipos).
 Equipamiento apropiado.
 Otra posible clasificación, utilizando la funcionalidad
como criterio principal, es la siguiente:
 Herramientas de planificación de sistemas de
gestión. Sirven para modelizar los requisitos de
información estratégica de una organización. Proporcionan
un "metamodelo" del cual se pueden obtener sistemas de
información específicos. Su objetivo principal es ayudar a
comprender mejor cómo se mueve la información entre las
distintas unidades organizativas. Estas herramientas
proporcionan una ayuda importante cuando se diseñan
nuevas estrategias para los sistemas de información y
cuando los métodos y sistemas actuales no satisfacen las
necesidades de la organización.
 Herramientas de análisis y diseño. Permiten al
desarrollador crear un modelo del sistema que se va a
construir y también la evaluación de la validez y
consistencia de este modelo. Proporcionan un grado de
confianza en la representación del análisis y ayudan a
eliminar errores con anticipación. Se tienen:
o Herramientas de análisis y diseño (Modelamiento).
o Herramientas de creación de prototipos y de
simulación.
o Herramientas para el diseño y desarrollo de interfases.
o Máquinas de análisis y diseño (Modelamiento).
 Herramientas de programación. Se engloban aquí
los compiladores, los editores y los depuradores de los
lenguajes de programación convencionales. Ejemplos de
estas herramientas son:
o Herramientas de codificación convencionales.
o Herramientas de codificación de cuarta generación.
o Herramientas de programación orientadas a los
objetos.
 Herramientas de integración y prueba: Sirven de
ayuda a la adquisición, medición, simulación y prueba de los
equipos lógicos desarrollados. Entre las más utilizadas
están:
o Herramientas de análisis estático.
o Herramientas de codificación de cuarta generación.
o Herramientas de programación orientadas a los
objetos.
 Herramientas de gestión de prototipos. Los
prototipos son utilizados ampliamente en el desarrollo de
aplicaciones, para la evaluación de especificaciones de un
sistema de información, o para un mejor entendimiento de
cómo los requisitos de un sistema de información se ajustan
a los objetivos perseguidos.
 Herramientas de mantenimiento: La categoría de
herramientas de mantenimiento se puede subdividir en:
o Herramientas de ingeniería inversa.
o Herramientas de reestructuración y análisis de código.
o Herramientas de reingeniería.
 Herramientas de gestión de proyectos. La
mayoría de las herramientas CASE de gestión de proyectos,
se centran en un elemento específico de la gestión del
proyecto, en lugar de proporcionar un soporte global para la
actividad de gestión. Utilizando un conjunto seleccionado de
las mismas se puede: realizar estimaciones de esfuerzo,
coste y duración, hacer un seguimiento continuo del
proyecto, estimar la productividad y la calidad, etc. Existen
también herramientas que permiten al comprador del
desarrollo de un sistema, hacer un seguimiento que va
desde los requisitos del pliego de prescripciones técnicas
inicial, hasta el trabajo de desarrollo que convierte estos
requisitos en un producto final. Se incluyen dentro de las
herramientas de control de proyectos las siguientes:
o Herramientas de planificación de proyectos.
o Herramientas de seguimiento de requisitos.
o Herramientas de gestión y medida.
 Herramientas de soporte. Se engloban en
esta categoría las herramientas que recogen las actividades
aplicables en todo el proceso de desarrollo, como las que se
relacionan a continuación:
o Herramientas de documentación.
o Herramientas para software de sistemas.
o Herramientas de control de calidad.
o Herramientas de bases de datos.
Otra clasificación, diferencia las funciones CASE en
cinco grupos:
Repositorio. Funcionan en torno a un repositorio central,
siendo éste el núcleo fundamental que contiene todas las
definiciones de objeto y sus relaciones. Los objetos pueden
ser especificaciones del sistema en forma de diagramas de
flujo de datos, diagramas entidad-relación, esquemas de
bases de datos, diseños de pantallas, etc. El repositorio es
un concepto más amplio que el de diccionario de datos y
soporta a los demás grupos de funciones. No es fácil
encontrar en el mercado productos Case con
funcionalidades estrictamente a las de repositorio, ya que, a
pesar de su innegable importancia, tienen un carácter
auxiliar de los demás grupos de funciones. Cualquier
sistema Case poseerá un repositorio propio o bien, trabajará
sobre un repositorio suministrado por otro fabricante o
vendedor.
Re-ingeniería. Los sistemas Case permiten establecer una
relación estrecha y fuertemente formalizable entre los
productos generados a lo largo de distintas fases del ciclo
de vida, permitiendo actuar en el sentido especificaciones-
código (ingeniería "directa") y también en el contrario
(ingeniería "inversa"). Ello facilita la realización de
modificaciones en la fase más adecuada en cada caso y su
traslado a las demás. Al conjunto de facilidades
proporcionadas por la ingeniería «directa» e "inversa" se le
denomina "re-ingeniería".
Soporte del ciclo de vida. El ciclo de vida de una
aplicación o de un sistema de información se compone de
varias etapas, que van desde la planificación de su
desarrollo hasta su implantación, mantenimiento y
actualización. Aunque el número de fases puede ser
variable en función del nivel de detalle que se adopte,
pueden de modo simplificado, identificarse las siguientes:
 Planeamiento.
 Análisis y Diseño.
 Implantación (programación y pruebas).
 Mantenimiento y actualización.
Los sistemas Case pueden cubrir la totalidad de estas
fases o bien especializarse en alguna(s) de ellas. En este
último caso se pueden distinguir sistemas de "alto nivel"
("Upper Case"), orientados a la autonomía y soporte de las
actividades correspondientes a las dos primeras fases y,
sistemas de "bajo nivel" ("Lower Case"), dirigidos hacia las
dos últimas. Los sistemas de "alto nivel" pueden soportar un
número más o menos amplio de metodologías de desarrollo.
Soporte de proyecto. Este tipo de funciones hace
referencia al soporte de actividades que se producen
durante el desarrollo, derivadas fundamentalmente del
trabajo en grupos, tales como facilidades de comunicación,
soporte a la creación, modificación e intercambio de
documentación, herramientas personales, controles de
seguridad, etc. Los sistemas Case pueden conceder a estas
cuestiones una importancia variable por lo cual el soporte
de proyecto constituye un factor de diferenciación.
Mejora continua de calidad. Aunque frecuentemente se
asocia a los sistemas Case con la mejora de la productividad
en el desarrollo de aplicaciones, debe tenerse en cuenta
que una de las principales ventajas estriba también, en la
mejora de la calidad de los desarrollos realizados.
Determinados sistemas Case enfatizan más sobre este
punto que sobre el anterior, introduciendo herramientas que
permiten ejercer un control intenso de garantía de calidad
del software desarrollado desde las primeras fases de su
ciclo de vida.
Opciones de Integración
Las herramientas Case pueden ser integradas de
muchas formas. En un extremo se utiliza una herramienta
CASE de forma aislada. Se crea un número limitado de
elementos de configuración de software (documentos,
programas o datos) que se manipulan mediante una única
herramienta y cuya salida tiene el formato de copia de
pantalla y/o documentación gráfica. En cierto sentido, el
enlace con el resto del entorno de desarrollo se realiza
mediante copias en papel que gestiona el ingeniero.
 Pocas herramientas CASE se utilizan en forma aislada.
Se suele disponer de las siguientes opciones:

Niveles de Integración CASE:

(a) intercambio de datos, (b) acceso común a
herramientas,
(c) integración de datos, (d) integración total.
a) Intercambio de datos. La mayoría de las herramientas
permiten exportar datos en forma de archivo sin estructura
con un formato conocido. Esto permite un intercambio de
datos punto a punto entre las distintas herramientas CASE,
utilizando normalmente un "filtro" de transmisión
intermedio.
La desventaja del intercambio de datos punto a punto
está en que, a menudo, sólo parte de los datos exportados
es utilizable por la herramienta receptora, ya que no fue
diseñada para ser totalmente compatible. Además, a
medida que evoluciona el software, la necesidad de
transferir archivos cada vez que se hace un cambio
pequeño puede llevar mucho tiempo. Las versiones pueden
quedar "desfasadas" fácilmente, perdiéndose la posibilidad
de transferencia, la cual suele ser en un único sentido. No
hay posibilidad de que los cambios se reflejen en ambos
sentidos y, es difícil hacer comprobaciones cruzadas de
documentos y mantener la integridad de la configuración a
través de las distintas herramientas que se estén utilizando.
b) Acceso común a herramientas. Permite al usuario
utilizar distintas herramientas de forma similar, por ejemplo
a través de un menú desplegable del gestor de ventanas del
sistema operativo. En un entorno multitarea, un usuario
podría abrir simultáneamente varias herramientas,
coordinando manualmente sus entradas y comparando las
representaciones de diseño a medida que evolucionan. Por
ejemplo, el usuario podría visualizar un diagrama de flujo de
datos, un diagrama de estructura , un diccionario de datos y
un segmento de código fuente, todos mantenidos por
diferentes herramientas. En estos entornos, el intercambio
de datos de herramienta a herramienta podría simplificarse
llamando al procedimiento de traducción a través de un
simple menú o de la selección de una macro. No es la
opción más adecuada.

c) Integración de Datos:
c1) Gestión común de datos. Los datos de distintas
herramientas se pueden mantener en una única base de
datos lógica, que puede estar físicamente centralizada o
distribuida. Hay una modalidad de fusión que permite
combinar el trabajo de varias personas trabajando en
diferentes partes de una aplicación.
Aunque los datos generados por las distintas
herramientas se gestionan de forma conjunta en el nivel de
gestión de datos comunes, las herramientas no conocen de
forma explícita las estructuras de datos y la semántica de
representación del diseño de las demás.
Consecuentemente, se requiere una etapa de traducción
(normalmente ejecutada manualmente) para permitir que
una herramienta utilice la salida generada por otra.
c2) Datos compartidos. Las herramientas del nivel de
datos compartidos tienen estructuras de datos y semántica
compatible, pudiendo intercambiar datos sin necesidad de
una etapa de traducción. Cada herramienta se diseña para
ser compatible con las demás. Por esta razón, la mayor
parte del intercambio de datos se da entre herramientas de
un único fabricante o en casos en los que se han establecido
relaciones estratégicas, entre distintos fabricantes para
generar un conjunto de datos integrado, a veces, a petición
de clientes importantes.
c3) Interoperabilidad. Las herramientas que combinan las
características de acceso común y la capacidad de
compartir datos, tienen la capacidad de interoperación. Esto
representa el mayor nivel de integración entre herramientas
diferentes. Sin embargo, hay otras propiedades del entorno
global CASE que se pueden añadir para mejorar la
efectividad del proceso de desarrollo de software.
d) Integración total. Para alcanzar la integración total del
entorno CASE se necesitan dos características más: gestión
de metadatos y capacidad de control. Los metadatos
representan información sobre los datos de ingeniería
generados por las distintas herramientas CASE. Esta
información incluye:
 Definiciones de objetos (tipos, atributos,
representaciones y relaciones válidas).
 Relaciones y dependencias entre objetos de
granularidad arbritaria (p. ej.: un proceso en un diagrama
DFD, una entidad única o un fragmento de código de una
subrutina).
 Reglas de diseño del software (p. ej.: las distintas
formas válidas de dibujar y equilibrar un diagrama de flujo
de datos).
 Procedimientos (fases estándar, hitos, informes, etc.)
y sucesos (revisiones, finalizaciones, informes de problemas,
peticiones de cambios, etc.) del flujo de trabajo (proceso).
Normalmente, la parte de reglas y procedimientos de
los metadatos se definen en forma de base de reglas, para
facilitar su modificación según evoluciona el proceso de
desarrollo del software. Por ejemplo, un nuevo método de
diseño podría alterar las reglas de representación y cambiar
los estándares del proceso de trabajo seguido hasta el
momento.
La capacidad de control permite que cada herramienta
pueda notificar al resto del entorno (a otras herramientas, al
gestor de metadatos, al gestor de datos, etc.) la ocurrencia
de sucesos significativos, así como enviar peticiones para la
realización de acciones a otras herramientas y servicios por
medio de un activador. Por ejemplo, una herramienta de
gestión de configuración que haga una comprobación
cruzada de la consistencia de documentos. La capacidad de
control ayudará a mantener la integridad del entorno y
proporcionará, también, un medio para automatizar
procesos y procedimientos estándar. El activador puede
estar incorporado en un entorno cerrado o puede estar
visible para las distintas herramientas, a través de una
interfase de programación y un mecanismo de paso de
mensajes.
Estrategias de Implantación
de Herramientas Case
 Identificar la magnitud de problemas a resolver en la
Institución.
 Identificar el nivel estratégico que deben tener los
sistemas.
 Evaluar los recursos de hardware y software
disponibles en la Institución y el medio.
 Evaluar el nivel del personal.
 Efectuar un estudio de costo-beneficio definiendo
metas a lograr.
 Elegir las herramientas apropiadas para la Institución.
 Establecer un programa de capacitación de personal
de sistemas y usuarios
 Elegir una aplicación que reúna la mayor parte de los
siguientes requisitos:
o Gran impacto de resultados.
o Disponibilidad de recursos.
o Mínimo nivel de riesgos.
o Máxima colaboración de usuarios.
o Tamaño reducido de solución.
Se establecerá interfases de compatibilidad de los
nuevos sistemas que deben convivir con los sistemas
anteriores.
Integración a otras tecnologías
La tecnología Case tendrá el mayor impacto si se
integra a proyectos de innovación tecnológica que hoy en
día contemple:
 Interfases de programación visual.
 Soluciones cliente-servidor.
 Manejo de múltiples Bases de Datos.
 Independencia de la plataforma de hardware y
software.
 Reingeniería de proceso de negocios.
Componentes y funcionalidades
de una herramienta CASE
A continuación se describen los principales
componentes de una herramienta CASE y sus
funcionalidades.
Repositorio
Base de datos central de una herramienta CASE. El
repositorio amplia el concepto de diccionario de datos para
incluir toda la información que se va generando a lo largo
del ciclo de vida del sistema, como por ejemplo:
componentes de análisis y diseño (diagramas de flujo de
datos, diagramas entidad-relación, esquemas de bases de
datos, diseños de pantallas), estructuras de programas,
algoritmos, etc. En algunas referencias se le
denomina Diccionario de Recursos de Información.
La mayoría de herramientas CASE poseen un
repositorio propio o bien trabajan sobre un repositorio
suministrado por otro fabricante o vendedor.
Apoyándose en la existencia del repositorio se efectúan
comprobaciones de integridad y consistencia:
 Que no existan datos no definidos.
 Que no existan datos autodefinidos (datos que se
emplean en una definición pero que no han sido definidos
previamente).
 Que todos los alias (referencias a un mismo dato
empleando nombres distintos) sean correctos y estén
actualizados.
 Las características más importantes de un repositorio
son:
o Tipo de información. Que contiene alguna
metodología concreta, datos, gráficos, procesos, informes,
modelos o reglas.
o Tipo de controles. Si incorpora algún módulo
de gestión de cambios, de mantenimiento de versiones, de
acceso por clave, de redundancia de la información. La
gestión de cambios y el mantenimiento de versiones,
ayudarán en el caso de que convivan diferentes versiones
de la misma aplicación o se tengan que realizar cambios en
la versión en producción y en la de desarrollo,
simultáneamente.
o Tipo de actualización. Si los cambios en los
elementos de análisis o diseño se ven reflejados en el
repositorio en tiempo real o mediante un proceso por lotes
(batch). Esto será importante en función a la necesidad de
que los cambios sean visibles por todos los usuarios, en el
acto.
o Reutilización de módulos para otros
diseños. El repositorio es la clave para identificar, localizar
y extraer código para su reutilización.
o Posibilidad de exportación e
importación para extraer información del repositorio y
tratarla con otra herramienta (formateo de documentos,
mejora de presentación) o incorporar al repositorio,
información generada por otros medios.
o Interfases automáticas con otros
repositorios o bases de datos externos.
Módulos de diagramación y modelización
Algunos de los diagramas y modelos utilizados con
mayor frecuencia son:
 Diagrama de flujo de datos.
 Modelo entidad - interrelación.
 Historia de la vida de las entidades.
 Diagrama Estructura de datos.
 Diagrama Estructura de cuadros.
 Técnicas matriciales.
Algunas características referentes a los diagramas son:
 Número máximo de niveles para poder soportar
diseños complejos.
 Número máximo de objetos que se pueden incluir
para no encontrarse limitado en el diseño de grandes
aplicaciones.
 Número de diagramas distintos en pantalla o al
mismo tiempo en diferentes ventanas.
 Dibujos en formato libre con la finalidad de añadir
comentarios, dibujos, información adicional para aclarar
algún punto concreto del diseño.
 Actualización del repositorio por cambios en los
diagramas.Siempre resulta más fácil modificar de forma
gráfica un diseño y que los cambios queden reflejados en el
repositorio.
 Control sobre el tamaño, fuente y
emplazamiento de los textosen el diagrama.
 Comparaciones entre gráficos de distintas
versiones. De esta forma será más fácil identificar qué
diferencias existen entre las versiones.
 Inclusión de pseudocódigo que servirá de base a
los programadores para completar el desarrollo de la
aplicación.
 Posibilidad de deshacer el último
cambio facilitando que un error no conlleve perder el
trabajo realizado.
Herramienta de prototipado
El objetivo principal de esta herramienta es poder
mostrar al usuario, desde los momentos iniciales del diseño,
el aspecto que tendrá la aplicación una vez desarrollada.
Ello facilitará la aplicación de los cambios que se consideren
necesarios, todavía en la fase de diseño.
La herramienta será tanto más útil, cuanto más
rápidamente permita la construcción del prototipo y por
tanto antes, se consiga la implicación del usuario final en el
diseño de la aplicación. Asimismo, es importante poder
aprovechar como base el prototipo para la construcción del
resto de la aplicación. Actualmente, es imprescindible
utilizar productos que incorporen esta funcionalidad por la
cambiante tecnología y necesidades de los usuarios.
Los prototipos han sido utilizados ampliamente en el
desarrollo de sistemas tradicionales ya que proporcionan
una realimentación inmediata, que ayudan a determinar los
requisitos del sistema. Las herramientas CASE están bien
dotadas, en general, para crear prototipos con rapidez y
seguridad.
Generador de código
Normalmente, se suele utilizar sobre ordenadores
personales o estaciones de trabajo, por lo que el paso
posterior del código al host puede traer problemas, al tener
que compilar en ambos entornos.
Las características más importantes de los generadores de
código son:
 Lenguaje generado. Si se trata de un lenguaje
estándar o un lenguaje propietario.
 Portabilidad del código generado. Capacidad para
poder ejecutarlo en diferentes plataformas físicas y/o
lógicas.
 Generación del esqueleto del programa o del
programa completo. Si únicamente genera el esqueleto
será necesario completar el resto mediante programación.
 Posibilidad de modificación del código
generado. Suele ser necesario acceder directamente al
código generado para optimizarlo o completarlo.
 Generación del código asociado a las pantallas e
informes de la aplicación. Mediante esta característica se
obtendrá la interfase de usuario de la aplicación.
Módulo generador de documentación
El módulo generador de la documentación se alimenta
del repositorio para transcribir las especificaciones allí
contenidas.
Algunas características de los generadores de
documentación son:
 Generación automática a partir de los datos del
repositorio, sin necesidad de un esfuerzo adicional.
 Combinación de información textual y gráfica, lo
que hace más fácil su comprensión.
 Generación de referencias cruzadas. Con ello se
podrá localizar fácilmente en qué partes de la aplicación se
encuentra un determinado objeto o elemento, con el fin de
analizar el impacto de un cambio o identificar los módulos
afectados por un determinado error.
 Ayuda de tratamiento de textos. Facilidad para la
introducción de textos complementarios a la documentación
que se genera de forma automática.
 Interfase con otras herramientas: procesadores
de textos, editores gráficos, etc.
Módulo de gestión de proyectos
Algunos productos CASE incorporan un módulo para la
gestión del proyecto de desarrollo de sistemas. Sus
características más importantes serán analizadas en el
apartado de otras herramientas.
Tendencias Tecnológicas y del

Mercado de las Herramientas CASE

Las principales líneas de evolución hacia las que

parecen encaminarse las herramientas CASE son:
 CASE para sistemas bajo arquitectura cliente/servidor.
No hay que confundir el hecho de que una herramienta
CASE funcione en un entorno de arquitectura
cliente/servidor, con que el sistema desarrollado mediante
una herramienta CASE vaya a funcionar bajo dicha
arquitectura.
En la actualidad ya hay ejemplos de los dos casos,
herramientas CASE que funcionan bajo un entorno
cliente/servidor, en red y con un repositorio centralizado en
un servidor y herramientas CASE que generan aplicaciones
que funcionan en un entorno cliente/servidor, en las cuales
se puede indicar dónde deben residir los componentes de la
aplicación en tiempo de ejecución, liberando al programador
de aspectos referidos a los protocolos de comunicaciones,
seguridad, interfases gráficas de usuario, etc.
La línea de evolución, en este caso, vendrá marcada
por versiones mejoradas de la herramienta, que faciliten
cada vez más la distribución de los elementos de una
aplicación entre los diferentes clientes y servidores y una
mayor liberalización del programador, de todos los aspectos
que no sean propios de la aplicación (protocolos de red,
seguridad, etc.).
 CASE multiplataforma. Estas herramientas soportan
las combinaciones dominantes de diferentes plataformas
físicas, sistemas operativos, interfases gráficas de usuario,
sistemas de gestión de bases de datos, lenguajes de
programación y protocolos de red. En este sentido el futuro
podrá ser de apertura creciente a nuevas plataformas y
portabilidad más generalizada.
 CASE para ingeniería inversa y directa. Ya existen
algunas herramientas de este tipo. Su evolución marcará
notables mejoras en la obtención de los diseños a partir del
código ya existente (ingeniería inversa) y la regeneración
del mismo, una vez optimizado el diseño (ingeniería
directa).
 CASE para trabajo en grupo (groupware). Estas
herramientas se centran en el proceso de desarrollo más
que en el producto a desarrollar, facilitando la integración
de diferentes grupos humanos, pertenecientes incluso a
empresas diferentes, trabajando conjuntamente en un gran
proyecto. Deberían incorporar las facilidades clásicas de
ofimática: correo electrónico, calendarios en línea,
planificación de actividades, preparación de documentos,
actas de reuniones, etc.
 CASE para desarrollo de sistemas orientados a
objetos. En la actualidad existen algunas herramientas que
cubren alguna de las fases del ciclo de vida de desarrollo de
aplicaciones orientadas a objetos (interfase de usuario,
análisis, diseño, programación, etc.). El objetivo futuro
podría ser cubrir el ciclo de vida completo. Aunque hoy en
día, la mayor efectividad se consigue con las herramientas
CASE para métodos estructurados, en un futuro no muy
lejano esta situación se invertirá a favor de las que soportan
objetos.
La proliferación de este tipo de herramientas podrá
verse retrasada debido al gran número de notaciones y
metodologías de orientación a objetos distintas que existen
en la actualidad.
En general, puede afirmarse que aquellas herramientas
que soportan muchas notaciones, no consiguen realmente
ayudar en la aplicación de una metodología con todo su
proceso y validaciones correspondientes, sino que suelen
quedarse, más bien, en un nivel exclusivamente gráfico. Por
el contrario, las que cuentan con una sola metodología
consiguen recoger prácticamente toda su semántica y
ayudar al diseñador en la validación de los sistemas,
además de generar un código de mayor calidad.
Es importante resaltar que las herramientas actuales
permiten generar objetos: modelo "estático" y modelo
"funcional", mas no el modelo "dinámico".
Todas estas herramientas CASE suelen generar código
C++. Algunas simplemente la definición esquemática de las
clases mientras que otras, pueden llegar a generar más de
la mitad del código del sistema.
La programación orientada a objetos puede cambiar la
forma que tienen las empresas de hacer negocio y como tal,
necesita ser tratada cuidadosamente, tanto por las
empresas u organismos, como por los fabricantes de
tecnologías que proporcionan las soluciones. Los fabricantes
tienen que ofrecer herramientas eficaces para ayudar a las
empresas a explotar todas las potentes prestaciones de la
tecnología de objetos (código reutilizable, programación
modular y capacidad de modelización), para construir
aplicaciones críticas y eficaces. Dentro de estas
herramientas, tendrán un papel fundamental las
herramientas CASE.
Una atención especial merecen las herramientas CASE
adaptables, algunas de las cuales permiten que sea el
propio usuario quien defina su metodología y los símbolos
de las notaciones a utilizar. Estas herramientas se
denominan "meta-CASE".
A mediano y largo plazo otras posibles líneas de evolución
serán:
 La utilización de la tecnología multimedia.
 La incorporación de técnicas de inteligencia artificial.
 Sistemas de realidad virtual.
Consideraciones
La elección del Case va a depender de sus estrategias de
desarrollo:
 Si tiene un gran volumen de aplicativos desarrollados,
es conveniente contrastar lo realizado versus las técnicas de
Análisis y Diseño.
 Si tiene presión por resultados a corto plazo, el empleo
de un Lower Case le será de utilidad, si se basa en modelos
de datos y procesos claros y definidos.
 Si desea realizar proyectos de gran envergadura es
recomendable aplicar Upper y Lower Case.
 Si trabaja con archivos de grandes dimensiones, es
recomendable que el Case soporte el Diseño de Bases de
Datos.
 Si no tiene formación y experiencia en el manejo de
metodologías es recomendable contar con asesoría
especializada, que capacite al personal y supervise los
avances de Análisis y Diseño.
 Evalúe la eficiencia del producto, en las pruebas
unitarias y de integración, y fundamentalmente en las
pruebas de sistemas.
 Considere los recursos apropiados para usar el Case,
de HW (memoria, disco, concurrencia), de SW (versión de
Sistema Operativo).
Lenguajes de Cuarta Generación (4GL)

Los lenguajes de cuarta generación son entornos de

desarrollo de aplicaciones constituidos por un conjunto de
herramientas integradas, entre las que se encuentran
editores, compiladores, sistemas para el acceso a bases de
datos, generadores de informes, generadores de pantallas
(modo carácter, interfases gráficas), etc.
Son herramientas que por lo general funcionan sobre
determinados tipos de SGBD y permiten construir a su
alrededor potentes y productivos entornos de desarrollo de
aplicaciones y sistemas de información. Las capacidades de
los 4GL exceden ampliamente de las tradicionales
facilidades de los SGBD, soportadas por los lenguajes de
definición y manipulación de datos (DDL/DML) y de
interrogación (SQL, QUEL y similares).
A diferencia de las herramientas CASE, los 4GL se
centran fundamentalmente en las fases de construcción e
implantación. En este aspecto, una herramienta CASE del
tipo L-CASE tendría muchas semejanzas con un 4GL. De
hecho, muchas herramientas U-CASE tienen interfases con
un 4GL para completar el ciclo de vida del desarrollo de
sistemas.
Los lenguajes que incorporan los 4GL suelen ser
mezcla de lenguajes procedurales y no procedurales. La
parte procedural se manifiesta en la definición de tipos de
constantes, tipos de datos elementales, visibilidad de las
variables (locales o globales), sentencias de control de flujo,
definición de funciones y procedimientos, etc., mientras que
la parte no procedural suele estar basada en el lenguaje
SQL (Structured Query Language) o, como mínimo, en
lenguajes de consulta de bases de datos relacionales.
Con los 4GL se consigue un aumento de productividad
gracias a:
 La utilización de funciones preprogramadas.
El entorno de desarrollo que facilita la realización de
determinadas tareas como diseño de pantallas o informes.
Tipos de 4GL
Los 4GL, en función de su relación con un
determinado gestor de base de datos, se pueden
agrupar de la forma siguiente:
 Lenguajes que están ligados a una base de datos. La mayoría de los gestores
de bases de datos cuentan con un lenguaje de cuarta generación. Son lenguajes
propietarios, lo que quiere decir que sirven únicamente para acceder a esa base de datos
en particular. El aprovechamiento de los recursos del gestor es muy alto.
 Lenguajes que son independientes del gestor de base de datos. Tienen la
capacidad de acceder a diferentes bases de datos, generalmente aquellas que soportan
un estándar común. No son lenguajes propietarios y por tanto no ligan al comprador a
ninguna base de datos en particular. La necesidad de utilizar el 4GL, siguiendo
estrictamente el estándar para asegurar la accesibilidad a diferentes bases de datos,
impide sacar el máximo provecho de cada una de ellas.

Componentes y funcionalidades de un 4GL

Los principales componentes de un lenguaje de cuarta
generación son:
Editor
Donde se escriben las sentencias del lenguaje de
programación. Puede contar con:
 Ayuda de tratamiento de textos.
 Facilidades para incorporar el nombre de variables,
objetos o funciones.
 Chequeo preliminar de errores de sintaxis.
 Utilidades de selección, copia o movimiento de
bloques.
 Posibilidad de deshacer el último cambio.
Compilador
Traduce las sentencias del lenguaje fuente a código
binario o a un lenguaje intermedio. Las características más
importantes de un compilador son:
 Posibilidad de separar la interpretación del código
fuente, de la generación del código. Esto permite la
ejecución inmediata de una parte del código sin haber
generado el fichero ejecutable.
 Gestión avanzada de errores. Recuperación desde un
estado erróneo del código, para poder continuar con el
proceso de interpretación y así detectar el mayor número
posible de errores en una única compilación.
 Optimización del código. La traducción del código
fuente va acompañada por una optimización del código (en
tamaño y/o en rendimiento), a la hora de ejecutar la
aplicación.
Módulo de acceso a base de datos
Incorpora la interfase con el gestor de base de datos.
Facilita toda la comunicación con la base de datos, desde el
diseño de las tablas hasta la construcción de sentencias
para recuperar información. La mayoría de los 4GL soportan
el lenguaje SQL estándar como lenguaje de acceso a base
de datos relacionales, lo que garantiza la portabilidad.
Módulo de ayuda a las pruebas
Hay 4GL que permiten una ejecución controlada del
código para poder aislar un error, con técnicas de ejecución
paso a paso, localizando los puntos de parada y permitiendo
la modificación del contenido de las variables durante la
ejecución.
Generador de informes y pantallas
Los 4GL incorporan módulos para la construcción
rápida de pantallas, ya sea en modo caracter o en modo
gráfico. Asimismo, algunos cuentan con un módulo de
generación de informes a través de consultas a la base de
datos.
Diccionario
Algunos 4GL cuentan con un diccionario en el que
almacenan la información referente a los objetos de la
aplicación. Esto facilita la gestión de los objetos generados
especialmente para trabajos en grupo.
Gestor de librerías
El gestor de librerías permite:
 La distribución de los objetos por las librerías
siguiendo los criterios que se establezcan.
  La localización rápida de los objetos con el fin de
analizar el impacto de una modificación o corregir un
error.
 La coordinación de los trabajos en equipo.
Módulo de control de versiones
Algunos lenguajes de cuarta generación incorporan
facilidades para el control de versiones o tienen interfase
con alguna herramienta del mercado para el control de
versiones.
Biblioteca con funciones u objetos reutilizables en la
aplicación.
La funcionalidad de este tipo de bibliotecas se describe
en detalle en el apartado de otras herramientas, al hablar
de bibliotecas de clases de objetos.
Tendencias Tecnológicas y del Mercado de Lenguajes de cuarta generación

La evolución de los 4GL se está dirigiendo hacia:

 Independencia de plataformas hardware y
software.
 Independencia de estructuras de datos y acceso
a información distribuida.
 Interoperabilidad con herramientas ofimáticas.
 Soporte para diferentes interfases gráficas de
usuario.
 Soporte para diferentes entornos de red.
 La aplicación de forma más extendida del
modelo cliente/servidor, tanto en el
funcionamiento del propio 4GL como en las
aplicaciones generadas.
 Mayor apertura para la interfase con
herramientas CASE.
 Incorporación de la tecnología de orientación a
objetos.
 Aplicación de capacidades multimedia.
Otras Herramientas
Existen otras herramientas de ayuda al
desarrollo, alguna de las cuales se pueden
encontrar en el mercado bajo la denominación
de CASE de propósito específico (toolkits), que
se integran de forma sencilla en cualquier
sistema de desarrollo.
Tipos de herramientas
En este apartado tienen cabida un amplio abanico de
herramientas dentro de las cuáles se pueden citar las
siguientes:
 Herramientas de gestión de proyectos. Facilitan
la labor de planificación y seguimiento de tareas y recursos,
para conseguir que el proyecto logre sus objetivos en plazo
y presupuesto.
 Herramientas de gestión de la configuración.
Identifican y definen los elementos de un sistema, controlan
los cambios y las versiones de dichos elementos.
 Herramientas de ayuda en las pruebas. Facilitan
la tarea de probar el equipo lógico desarrollado, para
asegurar que cumple las especificaciones del diseño.
 Herramientas de control de calidad. Dentro de
este apartado podrían englobarse la gran mayoría de las
herramientas citadas aquí, ya que de una u otra forma todas
van dirigidas a una mejora de la calidad de las aplicaciones.
No obstante, se hace referencia bajo esta denominación a
las herramientas que se centran en la fase de análisis,
diseño y construcción.
 Herramientas de revamping. Sirven para
"maquillar" una aplicación existente en modo carácter,
mediante una interfase gráfica de usuario sobre PC.
Componentes y funcionalidades
de otras herramientas
Se describen en este capítulo las funcionalidades más
importantes de otras herramientas de ayuda al desarrollo.
Gestión de proyectos
Las principales funcionalidades de un gestor de proyectos
son:
 Posibilidad de parametrización o personalización de
las opciones de utilización del programa (opciones de
cálculo, selección de datos a visualizar, etc.).
 Presentación de diferentes vistas del proyecto (por
tareas, por recursos, por fechas...).
 Definición de calendario a nivel de proyecto y de
recurso.
 Establecimiento de diferentes relaciones entre tareas
(final- inicio, final-final, inicio-inicio).
  Facilidades gráficas para la planificación (diagrama
de GANTT, diagrama de PERT).
 Resolución de conflictos de los recursos.
 Facilidades para la impresión de programas de
trabajo.
 Posibilidad de desarrollar macros.
 Conexión entre varios proyectos.
 Facilidades de importación / exportación.
 Facilidad de comunicación con otras herramientas
(hojas de cálculo, aplicaciones gráficas, correo
electrónico, etc.).
Gestión de la Configuración
Las principales funcionalidades de una herramienta de
gestión de la configuración son:
 Identificación de cada uno de los elementos de la
aplicación: número de versión e información de
carácter general.
 Soporte para jerarquías de elementos.
 Control de versiones. Utilización de técnicas de
bloqueo de objetos o código para evitar
actualizaciones simultáneas por varios
desarrolladores.
 Definición de las configuraciones. Criterio que se
sigue para seleccionar elementos de una versión.
 Posibilidad de recuperación de versiones anteriores
de determinados objetos o partes del código.
Herramientas de ayuda en las pruebas
Los principales componentes de una herramienta de ayuda
a las pruebas y sus funcionalidades son:
 Utilidades de datos. Describen las características
de los datos implicados en la prueba del software.
 Simuladores. Permiten representar partes del
sistema no desarrollado todavía o simular la
interacción del mismo con otros sistemas o con el
usuario final.
 Trazadores. Permiten seguir paso a paso el
funcionamiento de un determinado proceso e
introducir paradas dentro de la ejecución para
analizar el contenido de variables.
 Sistemas de captura y repetición. Permiten
capturar datos para utilizarlos como entrada de un
proceso, interceptar el flujo de ejecución de un
 programa, retener una secuencia de acciones desde
el teclado o ratón y repetirlos posteriormente.
 Comparadores de datos. Sirven para comparar los
resultados esperados de la prueba con los obtenidos.
Estos componentes o módulos pueden formar parte de una
misma herramienta de ayuda, las pruebas, o pueden ser
herramientas independientes entre sí.
Herramientas de control de calidad
Los componentes de una herramienta de control de
calidad y sus funcionalidades son las siguientes:
 Comprobadores de requisitos. Chequean las
sentencias de los requisitos para verificar que no existe
ambigüedad, inconsistencia o falta de integridad. Estas
herramientas sólo comprueban sobre los requisitos incluidos
en la documentación, lo que no hacen es informar que falta
algún requisito importante.
 Generadores de condiciones de prueba basados
en las especifica-ciones del diseño. Generan las
condiciones por métodos aleatorios, algorítmicos y/o
heurísticos. El método aleatorio utiliza procedimientos de
muestreo estadístico para elegir las condiciones. El método
algorítmico se basa en técnicas de análisis de causa-efecto
y análisis de enlaces. El método heurístico se construye
sobre experiencias previas con errores de aplicaciones.
 Trazadores de requisitos a probar. Desarrollan una
traza (log) para un requisito en particular.
 Generadores de resultados esperados. Ejecutan
las condiciones de prueba por primera vez. Las salidas
obtenidas son juzgadas por la herramienta como correctas o
erróneas y según ésto, son utilizadas como resultados
esperados.
 Generadores de métricas. Analizan el código
existente y obtienen métricas sobre el flujo de datos, el
control del flujo, la estructura de datos, la estructura del
proceso, el número de líneas de código, etc.
 Verificadores de código. Son analizadores de
código a la búsqueda de variables no inicializadas, índices
fuera de rango, seguimiento de estándares, etc.
Estos módulos pueden formar parte de una misma
herramienta de control de calidad o pueden ser
herramientas independientes entre sí.
Bibliotecas de clases de objetos
 La función de estas bibliotecas es obtener de ellas
objetos, módulos o partes del código que se puedan
implantar directamente, o con leves modificaciones, en la
aplicación en desarrollo.
Las bibliotecas de clases suelen ser específicas de un
determinado lenguaje, sin embargo, se tiende a eliminar
esta limitación, mediante la creación de bibliotecas
siguiendo unas determinadas especificaciones (Ejemplo:
System Object Model - SOM).
Hay bibliotecas de clases que se han diseñado para:
 La creación de interfases gráficas de usuario (IGU).
 El acceso a bases de datos.
 La integración de funcionalidades multimedia.
 El tratamiento de documentos.
 El intercambio electrónico de datos.
 El desarrollo de aplicaciones científicas, matemáticas
o de ingeniería.
Herramientas de revamping
Las principales características de estas herramientas son:
 Soporte de un determinado estándar de
comunicaciones con el ordenador central (host) a
través de terminales.
 Creación, más o menos automática, de las interfases
gráficas de usuario correspondientes a las pantallas
host, así como la navegación entre las mismas.
 Validación de la entrada de datos en la ventana
gráfica.
Tendencias tecnológicas y del mercado de otras herramientas de ayuda al desarrollo

De forma general se puede observar que todas las

herramientas englobadas en este apartado están
evolucionando en las siguientes líneas:
 Herramientas más abiertas para poder conectarse con
mayor facilidad unas con otras.
 Soporte para diferentes plataformas físicas y lógicas.
 Mejor aprovechamiento de los recursos físicos y los
servicios de red e interconexión.
 Decidida aplicación de lo que parece ser la tecnología
con mayor futuro: la orientación a objetos.
 Interfase de usuario más amigable apoyándose en
tecnologías multimedia.
Aspectos técnicos en el proceso de Herramientas de ayuda al desarrollo
 En este capítulo se pretende dar la orientación
suficiente al comprador, para la preparación del conjunto de
especificaciones que definirán los requisitos que han de
cumplir las herramientas de ayuda al desarrollo, objeto de la
adquisición.
Se realiza en primer lugar un análisis de las
necesidades del comprador, a continuación se recogen los
factores relevantes a tener en cuenta en el proceso de
adquisición y, finalmente, se describe cómo deben ser
planteadas las especificaciones técnico - funcionales para la
elaboración del Pliego de Prescripciones Técnicas, qué
normas, estándares y cláusulas tipo pueden ser de
aplicación y cuál es el cuestionario técnico diseñado para
normalizar las ofertas y facilitar su evaluación.
Análisis de las necesidades del
comprador
La decisión de adquirir e implantar una herramienta de
ayuda al desarrollo, surge para poder satisfacer las
necesidades y requisitos impuestos por el usuario final de
los sistemas de información, requisitos tanto de calidad
como de coste (mejora de la productividad).
La primera etapa que debe abordarse de modo
sistemático, dentro del proceso de adquisición, es el análisis
de las necesidades existentes, que deberán ser satisfechas
a través de la implantación de la herramienta que se va a
adquirir. El comprador debe identificar:
 Los principales requisitos funcionales que debe
cumplir la herramienta.
 El tipo de facilidades de uso que deben prestar.
 Las limitaciones y restricciones que se derivan del
entorno de operación previsto.
En función de los requisitos funcionales se podrá deducir
qué tipo de herramienta es la más adecuada.
Algunos factores a tener en cuenta y que son comunes a
todas estas herramientas son:
 Tipo(s) de plataforma(s) sobre las que deberá
funcionar la herramienta, tanto desde el punto de vista del
equipamiento lógico como del equipamiento físico.
 Requisitos físicos (espacio en disco, memoria RAM,
UCP, etc.).
 Necesidad de integración con otras herramientas de
ayuda al desarrollo ya existentes.
 Necesidad de acceso simultáneo para diferentes
usuarios. Esto puede enfocar la elección hacia una
herramienta que permita accesos compartidos a los datos y
que cuente con una definición de perfiles de usuario para la
protección de información.
 Necesidad de compartir datos con aplicaciones
externas. Se valorará más a aquella aplicación que permita
exportar sus datos o que almacene la información en un
formato de fácil acceso para otra aplicación.
Herramientas CASE
Para una herramienta CASE, el comprador deberá tener
en cuenta todas las necesidades, limitaciones y
restricciones que afecten a los siguientes puntos:
 Funcionalidad requerida
Es importante definir con el mayor grado de
aproximación, cuáles son las funciones que se le van a pedir
a la herramienta. Para ello, es necesario analizar si las
necesidades son cubiertas con un CASE integrado o con un
CASE orientado a alguna de las fases del ciclo de vida del
desarrollo.

 Metodología soportada
Si en la organización ya existe una metodología y
técnicas, la herramienta deberá soportar dicha metodología,
así como las técnicas empleadas en cada fase. Si la
herramienta CASE va a servir precisamente para introducir
un nuevo método de trabajo, habrá que asegurarse de que
dicho método es el adecuado. En ocasiones, para adaptarse
a una metodología, es preciso realizar desarrollos
adicionales en la herramienta.
 Generación automática de código
En algunos casos la necesidad predominante del
usuario puede consistir en la generación automática de
código fuente (programas), a partir de productos del diseño
fuertemente formalizados (scripts, formatos, etc.). En tal
caso, deberán conocerse los pormenores de tal necesidad,
como lenguajes de programación admisibles como salida,
generación en tiempo real o en un proceso por lotes, etc.
 Capacidad de integración en la arquitectura
existente
Habrá que tener en cuenta la plataforma o
plataformas diferentes (ordenadores) que deberán soportar
la herramienta CASE, su tipología (fabricante, modelo y
sistema operativo cuando menos) y las características de la
red de interconexión cuando exista. Ello tendrá importancia
a la hora de garantizar la compatibilidad del equipamiento
existente con los nuevos productos que se van a adquirir.
Lo mismo debe hacerse en relación con las
herramientas lógicas previamente existentes en esas
plataformas, siempre que deban integrarse en mayor o
menor medida con los nuevos productos.
Se deberá considerar cuáles son los recursos
disponibles en el equipamiento existente para la
implantación de la herramienta CASE en cuestión. Deberán
conocerse con el mayor detalle, posibles cuestiones como
memoria RAM y espacio en disco necesarios, grado de
utilización de la(s) UCP(s) en condiciones normales de
operación y de picos de demanda de la nueva herramienta.
Este punto es importante de cara a un posible
redimensionamiento del equipamiento disponible.
Estas mismas consideraciones también deben ser
tenidas en cuenta no ya para la propia herramienta CASE,
sino para las aplicaciones desarrolladas con ayuda de dicha
herramienta.

 Modo de funcionamiento
Será bueno conocer el modo de funcionamiento
(monousuario / multiusuario), así como el grado deseable de
centralización de los recursos y funciones asociadas con la
administración y operación de la herramienta CASE que se
va a implantar.
 Personalización del entorno
Finalmente, deberán considerarse las necesidades o
conveniencias de la personalización del sistema, en función
de los diferentes perfiles de usuario de la herramienta.
Lenguajes de cuarta generación
Para un lenguaje de cuarta generación, el comprador
deberá tener en cuenta todas aquellas necesidades,
limitaciones y restricciones que afecten, entre otros, a los
puntos siguientes:
 Tipo de aplicaciones que van a ser desarrolladas
La naturaleza de las aplicaciones que se van a
construir es importante porque de ella se derivarán
requisitos diferentes. Existen dos grandes grupos de
aplicaciones: sistemas de soporte a la toma de decisiones y
aplicaciones transaccionales. Las del primer tipo son, por lo
general, poco intensivas en actualizaciones de la base de
datos y sí en el uso de generadores de informes y
herramientas de análisis de usuario final, por lo que
requieren un sistema de recuperación de la información
flexible, rápido y potente. En cambio, las aplicaciones
transaccionales exigen la realización de frecuentes
consultas y actualizaciones de la base de datos compartida
por los distintos usuarios.
 Capacidad de integración en la arquitectura
existente
Se debe conocer el número de plataformas diferentes
(ordenadores) que deberá soportar el 4GL, su tipología
(fabricante, modelo y sistema operativo cuando menos) y
las características de la red de interconexión cuando exista.
Ello tendrá importancia a la hora de garantizar la
compatibilidad del equipamiento existente con los nuevos
productos que se van a adquirir.
Lo mismo debe hacerse en relación con las
herramientas lógicas previamente existentes en esas
plataformas, siempre que deban integrarse en mayor o
menor medida con los nuevos productos. Dentro de este
apartado tiene una especial importancia el gestor de base
de datos que exista en la organización y al cual deba
acceder el 4GL.
Habrá que tener en cuenta cuáles son los recursos
disponibles en el equipamiento existente para la
implantación del 4GL. Deberán conocerse con el mayor
detalle posible cuestiones como memoria RAM y espacio en
disco necesarios, grado de utilización de la(s) UCP(s) en
condiciones normales de operación, en condiciones de picos
altos de demanda, etc. Este punto es importante de cara a
un posible redimensionamiento del equipamiento
disponible, necesario para la correcta implantación y
funcionamiento de los nuevos productos.
Estas mismas consideraciones se deben tener en
cuenta para las aplicaciones generadas mediante el 4GL.
 Grado deseable de
centralización/descentralización de las funciones
relativas a la utilización del 4GL
 Se debe conocer el grado deseable de centralización
de los recursos y funciones asociadas con el desarrollo, la
administración y la operación del entorno 4GL a implantar.
El análisis de estos factores incidirá en la arquitectura que
se juzgue más adecuada al entorno de operación.
Como es lógico, en la práctica podrán existir otros tipos
de necesidades de usuario que deberán igualmente ser
identificadas por el comprador, con el fin de que todos los
factores relevantes sean tenidos explícitamente en cuenta
durante la fase del proceso de adquisición.
Otras herramientas
Para seleccionar una herramienta específica de ayuda
al desarrollo, el comprador deberá tener en cuenta todas las
necesidades, limitaciones y restricciones que se han
expuesto en los apartados anteriores, especialmente el
correspondiente a herramientas CASE.
Factores relevantes en el proceso de
adquisición
En la definición del objeto del contrato y los requisitos
inherentes al mismo, así como en la valoración y
comparación de ofertas de los proveedores, pueden
intervenir muchos factores y de muy diversa índole, los
cuales deberán estar recogidos dentro del conjunto de
cuestionarios disponibles a tal efecto:
 De empresa o Institución.
 Económicos.
 Técnicos particulares.
No obstante, y a título orientativo en este apartado se
hace mención de aquellos factores que, entre los anteriores,
pueden intervenir en el proceso de adquisición de
herramientas de ayuda al desarrollo y cuyo seguimiento
debe efectuarse exhaustivamente.
 Consideraciones en el Contrato de Adquisición.
Aparte de las cláusulas que son comunes a todos los
contratos, se considerarán las siguientes:

 Requerimientos para el funcionamiento del Case.

 Incumplimiento de los requerimientos.
 Entrega e instalación de la herramienta.
 Instalación del Case.
 Certificación de la Instalación.
 Prueba de funcionamiento.
  Informe de fallas durante la prueba de aceptación.
 Responsabilidad de fallas.
 Penalidad en caso de no alcanzar el nivel de
funcionamiento mínimo.
 Constancia de aceptación del equipo.
 Garantía de la herramienta.
 Asesoría técnica..
 Capacitación.
 Información técnica.

 Estrategia de implantación. Se debe comenzar

aplicando la herramienta al desarrollo de un proyecto piloto,
que no afecte a ningún área crítica y que sea de poca
envergadura. Con la experiencia adquirida en este proyecto
piloto, se podrá acometer el desarrollo de otros más
complejos. Es importante asegurarse de poder utilizar la
nueva herramienta sin tener que volver a escribir las
aplicaciones existentes. En el caso particular de implantar
por primera vez una herramienta CASE, es un factor crítico
el apoyo del suministrador o de consultores con experiencia
en las etapas iniciales.
 Requisitos físicos. Expresado en el Modelo de
Tecnología de Arquitectura y características del puesto de
desarrollo (procesador, memoria RAM, espacio en disco) y
características del puesto de producción para las
aplicaciones desarrolladas. Con ello se asegura que se
dispone de los equipos necesarios o se prevé la necesidad
de compra. Es posible que este factor obligue a la
remodelación de todos los equipos y que su coste no sea
asumible.
 Requisitos lógicos. Expresado en el Modelo de
Tecnología, se debe analizar con especial atención la
necesidad de otros módulos, no incluidos en el producto
ofertado por el vendedor, para el correcto y completo
funcionamiento de la herramienta (compiladores, módulos
para trabajo en grupo, etc.).
Es fundamental comprobar si la herramienta tiene los
módulos que incorporan las funcionalidades ofrecidas. Hay
que tener cierta precaución cuando se analice un módulo
ofertado, ya que hay casos en que para el funcionamiento
de dicho módulo, es necesario adquirir otros módulos que, a
veces, no se incluyen en la oferta.
 Prueba en condiciones reales. Si se va a instalar
una herramienta CASE, se debe exigir al suministrador una
prueba anterior a la adquisición de la herramienta CASE.
Esta prueba debe realizarse en la propia instalación de
destino.
La prueba se debe realizar en las condiciones más
parecidas a las reales que se puedan conseguir e intentando
simular el acceso de un número de usuarios, parecido al
esperado. Durante la prueba se deberán evaluar conceptos
objetivos fácilmente medibles.
No todas las herramientas cumplen con las
prestaciones indicadas en los manuales, por lo que es
aconsejable establecer un período de prueba para explorar
la herramienta que se pretende adquirir. Una vez que en las
especificaciones técnicas se hayan definido la plataforma
física y lógica y las necesidades funcionales, mediante este
período de prueba se podrá probar que la herramienta
puede ser instalada en esa plataforma y soporta dichas
funcionalidades.
 Dependencia del proveedor. Hay que evitar esta
dependencia. A veces las herramientas llevan integradas
partes de la plataforma operativa, lo cual las hace cerradas
y propietarias. En el contrato de adquisición se debe
contemplar la asesoría técnica, la capacitación y la
información técnica.
Se debe encontrar el equilibrio entre la productividad de la
herramienta y su carácter abierto, por ejemplo:
independencia del proveedor.
 Coste límite de adquisición. En este apartado hay
que analizar las posibilidades que ofrece el suministrador en
cuanto a disponer de licencias individuales, grupos de
licencia o licencias corporativas. Los costes varían
considerablemente en función del tipo de licencia.
 Coste de instalación de las aplicaciones
generadas. Hay que averiguar si una vez generada la
aplicación y a la hora de distribuirla entre los usuarios, es
necesaria la instalación de un módulo propiedad del
suministrador (runtime). Este módulo en ocasiones no es de
libre distribución y es preciso comprarlo. Hay que dejar claro
este punto desde un principio.
 Capacidad de integración. Hay que tener en cuenta
la plataforma o plataformas diferentes en que va a ser
instalada la herramienta en cuestión, su tipología
(fabricante, modelo y sistema operativo) y las
características de la red de interconexión, cuando exista.
Igualmente habrá que asegurar la integración con el
software ya instalado. La necesidad de la integración con
una herramienta CASE determinada, condiciona de forma
decisiva la elección de un 4GL.
 Portabilidad de la aplicación generada. Cuando
se pretende ejecutar la aplicación generada en diferentes
plataformas, es un factor muy importante la portabilidad,
tanto del código generado como de las especificaciones del
diseño. En el caso particular de 4GL, este factor puede
convertirse en decisivo si se tiene la intención de instalar la
aplicación generada en entornos técnicos diferentes:
sistemas operativos, plataformas físicas, interfases gráficas
y protocolos de red. Un 4GL será realmente portable si el
código generado se ejecuta en diferentes plataformas sin
necesidad de adaptar los programas.
 Capacidad técnica de la empresa y de la
asistencia técnica que presta. Es recomendable pedir
referencias a otros usuarios de la Administración de este
tipo de productos.
Más Herramientas CASE
Además de los factores relevantes anteriores, en las
herramientas CASE hay que prestar especial atención a:
 Metodología y técnicas soportadas. Para obtener
éxito en la utilización de una herramienta CASE, es
necesaria la existencia en la organización de una
metodología. Si todavía no se cuenta con ninguna, la
instalación de una herramienta CASE es un buen momento
para implantarla.
Si ya se está utilizando una metodología, la
herramienta CASE deberá ser capaz de adaptarse con el
menor esfuerzo posible por parte del usuario, a dicha
metodología y a las técnicas empleadas en cada una de sus
fases.
 Módulos que componen la herramienta CASE.
Las herramientas CASE suelen necesitar varios módulos,
que se venden como productos independientes, para
alcanzar su plena funcionalidad. Por lo tanto, en las
especificaciones técnicas se deben señalar las
funcionalidades a cubrir por la herramienta CASE, las cuales
deben estar totalmente cubiertas por los módulos ofertados.
Igualmente se debe exigir que se detallen cuáles son
las funcionalidades que cubre cada módulo y, para cada uno
de ellos, cuáles de los otros son un pre-requisito para poder
utilizarlo.
 Licencias de Explotación y Desarrollo. Es posible
que para algunos o todos los módulos ofertados, existan dos
versiones distintas. Una versión completa conocida
normalmente como versión de "Desarrollo" y otra, con
alguna de las funcionalidades restringidas o inexistentes,
usualmente llamada versión de "Explotación" o "Producción"
(a veces se utiliza runtime).
Es necesario que el suministrador detalle cuál de las
dos versiones está ofreciendo para cada una de las licencias
que se compren y, si alguna de ellas fuese una versión
limitada, que especifique claramente cuáles de las
funcionalidades ofertadas no se encuentran presentes en la
versión restringida. Se debe especificar en el contrato de
adquisición.
 Funcionalidad del repositorio. Los cambios que se
hagan en el repositorio se deben realizar automáticamente
en los programas. Por ejemplo: tenemos definido en nuestro
repositorio el campo sueldo de longitud 5 y es cambiado a
9, luego en nuestro programa este campo ya tendrá
longitud 9.
 Costes indirectos. Es muy importante tener en
cuenta:

o La formación del personal y el efecto de la curva de

aprendizaje. Para minimizar el coste de la curva de
aprendizaje son importantes factores como la calidad de la
formación inicial, la calidad de la documentación de la
herramienta, la existencia de ayuda interactiva y la
disponibilidad de la herramienta en castellano.
o La definición de estándares de uso y mantenimiento
de la herramienta.
o La adaptación de la herramienta a las necesidades o
peculiaridades de la organización, tanto desde el punto de
vista metodológico como tecnológico.
o La adaptación de las aplicaciones ya existentes al
nuevo entorno.
Lenguajes de Cuarta Generación
En los lenguajes de cuarta generación se consideran,
específicamente, factores relevantes los siguientes:
 Integración con el/los gestor/es de base/s de
datos. Si ya se cuenta con un/unos determinado/s
gestor/es de base/s de datos puede ser un factor
relevante que el 4GL se integre con él/ellos.
 Rendimiento adecuado de la aplicación
generada. Las aplicaciones desarrolladas con un 4GL
pueden presentar problemas de rendimiento, ya que se
lleva a cabo un proceso más laborioso de interpretación
del código hasta hacerlo inteligible para la máquina en el
momento de la ejecución. Es uno de los factores críticos
de estos lenguajes.
Otras Herramientas
El factor más importante a la hora de decidirse por una
herramienta de ayuda al desarrollo de carácter específico,
es su perfecta integración con el entorno ya establecido en
la organización, tanto lógico como físico:
 Integración con otras herramientas de ayuda al
desarrollo. La necesidad de la integración con una
herramienta determinada, como una herramienta CASE,
condiciona de forma decisiva la elección de otra
herramienta de apoyo.
Además, es importante tener en cuenta los costes indirectos
derivados de:
 La adaptación de las aplicaciones ya existentes a la
nueva herramienta.
 La formación del personal y el efecto de la curva de
aprendizaje en la nueva herramienta.
 La adaptación de la herramienta a las necesidades o
peculiaridades de la organización, tanto desde el punto de
vista metodológico como tecnológico.
Diseño de las Bases de especificaciones
técnicas particulares
En las Bases de especificaciones técnicas se deben
indicar aquellas consideraciones que, extraídas del proceso
de análisis de necesidades efectuado previamente, van a
determinar las características y requisitos del objeto de
nuestro contrato y en el caso particular de herramientas
CASE, deberán contemplar aspectos tales como:
  Fases del ciclo de vida soportadas.
 Metodologías de diseño soportadas.
 Generación automática de código fuente.
 Aplicaciones a desarrollar con el soporte de la
herramienta.
 Plataforma(s) de implantación de la herramienta.
 Herramientas lógicas que deben integrarse en/con la
herramienta.
 Modo de funcionamiento (monousuario /
multiusuario).
 Perfiles de usuarios y factores humanos en el entorno
de operación.
 Módulos (cuáles son los módulos que se deben
adquirir para lograr las funcionalidades deseadas y si
dichos módulos están incluidos en la oferta).
Lista para la especificación de las características
técnico -funcionales de las Herramientas Case
En las bases de las especificaciones técnicas se
incluirán las características técnicas y funcionales que se
refieren a los factores críticos que hayan sido identificados.
A continuación se incluye una lista referencial:
 Funciones CASE requeridas:

 Repositorio
 Re-ingeniería
 Soporte al ciclo de vida
 Soporte de proyecto
 Control de calidad
 Otras (se indicará cuáles)

 Paradigmas de desarrollo soportados:

 Ciclo de vida en cascada
 Creación y refinamiento de prototipos
 Desarrollo por especificaciones fuertemente
formalizadas
 Modelo de Balzer
 Otros (se indicará cuáles)

 Fases de ciclo de vida soportadas:

o Planificación:
 Análisis de viabilidad
 Organización y planificación del proyecto
o Diseño:
 Modelo de datos
 Modelo de procesos
 Diseño general
 Diseño detallado
o Implantación:
 Programación de módulos
 Pruebas de módulos
 Integración
 Pruebas de integración
 Pruebas de aceptación
o Mantenimiento y actualización:
 Mantenimiento ligero
 Mantenimiento pesado
 Actualización
 Gestión de la configuración

 Metodologías de diseño soportadas:

o Diseño por flujo de datos (Yourdon-Constantine)
o Diseño por estructuras de datos (Warnier-Orr,
Jackson)
o Diseño de sistemas de información (SSADM,
Merise)
o Diseño en tiempo real (Ward-Mellor)
o Diseño "orientado a objetos" (Buhr)
o Otras (se indicará cuáles)

 Soporte a la documentación:
o Edición automática
o Generación automática de diagramas
o Mantenimiento
o Archivo y gestión
o Referencias cruzadas

 Generación automática de código (programas)

fuente:
o Desde:
 "scripts"
 formatos
 diagramas
 lenguajes de especificación formal
 otros (se indicará cuáles)
o Hasta:
 COBOL
 FORTRAN
 PASCAL
 C
 SQL
 otros (se indicará cuáles) o combinación
de los anteriores

 Aplicaciones a desarrollar a través del sistemas

CASE:
o Tipo y complejidad
o Modalidad de desarrollo (interno/externo)
o Plataforma(s) de desarrollo de las aplicaciones
o Plataforma(s) de implantación de las
aplicaciones
o Naturaleza:
 técnico-científica
 gráfica
 soporte a la toma de decisiones
 transaccional
 proceso de datos
 otras (se indicará cuáles)
o Lenguajes de programación

 Plataforma(s) de implantación del sistema

CASE:
o Fabricante y modelo
o Sistema operativo
o Recursos libres utilizables
o Red de interconexión si son varias

 Herramientas lógicas que deben integrarse

en/con el entorno CASE:
o Compiladores e intérpretes
o "Debuggers"
o Librerías
o SGBD/4GL
o Diccionario de datos
o Editores
o Entornos gráficos
o Entornos multiventana
o Otras (se indicará cuáles)

 Factores humanos en el entorno de operación:

o Perfil de los grupos técnicos de desarrollo
o Perfil del grupo técnico de administración y
operación
o Posibles discapacidades a considerar
o Otros factores relevantes

 Coste límite:
o Adquisición
o Operación y mantenimiento
o Costes indirectos

En el caso de lenguajes de cuarta generación serán

aspectos tales como:
 Soporte de técnicas de programación.
 Generador de aplicaciones.
 Modelos de datos soportados.
 Portabilidad.
 Facilidades de depuración.
 Integración con entornos CASE.
 Interfase y documentación de usuario en español.
 Perfiles de usuarios y factores humanos en el entorno
de operación.
Además de lo expuesto anteriormente, habrá que tener
en cuenta en el proceso de adquisición, lo expuesto en el
punto de Análisis de las necesidades del comprador y
en el de Factores relevantes en el proceso de
adquisición.
Normas y estándares aplicables
Existen pocas normas y estándares, entre ellas se
encuentran las siguientes:
 ISO 9075-1987. Norma internacional que contiene el
estándar del lenguaje de consulta y manejo de datos SQL
(Structured Query Language).
 ISO/TR 10623. Technical product documentation -
Requirements for computer-aided design and draughting -
Vocabulary (ISO/TR 10623:1991).
 ISO 11442-1993. Technical product documentation -
Handling of computer- based technical information.
o Part 1: Security requirements.
o Part 2: Original documentation.
o Part 3: Phases in the product design process.
o Part 4: Document management and retrieval systems.
Algunos de los estándares más importantes son los que
se refieren al repositorio. Sobre este tema se pueden citar:
 CDIF (CASE Data Interchange Format) CASE Formato
de Intercambio de Datos.
 IRDS (Information Resource Dictionary System)
aprobado por el ANSI, es un estándar para diccionarios de
datos. Define los tipos de objetos, relaciones y atributos que
van a ser incluidos en el diccionario.
 PCTE (Portable Common Tool Environment) es una
infraestructura que ofrece los servicios que necesitan las
herramientas CASE, de forma similar a cómo un sistema
operativo ofrece los servicios que necesita cualquier
producto instalado sobre él.
Pruebas de verificación y control
Las herramientas de ayuda al desarrollo tratadas
aquí pertenecen a la categoría del equipo lógico
empaquetado. Su fabricación se realiza no para satisfacer
las necesidades particulares de un usuario u organización
concreta, sino para ser vendidos en el mercado a un
número de usuarios tan amplio como sea posible. Por esta
razón, durante su desarrollo, estos productos se ven
sometidos a una serie de rigurosos controles de calidad,
tendentes a garantizar que su funcionamiento se ajusta a
lo indicado en la documentación técnica correspondiente y
que por otra parte no existan errores que afecten al
correcto comportamiento del sistema en cuestión.
En tal sentido, este tipo de productos se diferencia
notablemente del equipo lógico desarrollado a medida, ya
que éste debe ser sometido a unas pruebas de aceptación
rigurosas por parte del comprador, con el fin de garantizar
el nivel de calidad demandado. El comprador debe
comprobar, por un lado, que han sido instalados todos los
dispositivos, elementos y componentes que se incluyen en
la oferta, tomando nota de los correspondientes modelos y
números de serie a efectos de inventario y, por otra parte,
que su funcionamiento se ajusta perfectamente a las
especificaciones indicadas en el Pliego de Bases. Para ello
se realizarán las pruebas de aceptación del mismo, sobre
todo en lo relativo a sus funcionalidades y capacidad de
integración en el entorno previamente existente. La
mayoría de los suministradores de estos productos suelen
admitir su examen y prueba, bien libremente o mediante
el pago de una pequeña tarifa. Esta es una ventaja que
debe ser aprovechada por el comprador.
Una prueba completa y fiable en el desarrollo,
consistiría en un pequeño sistema o un módulo de éste, a
modo de experiencia piloto. De esta forma se validaría,
punto por punto, todo lo que se había exigido a la
herramienta, como por ejemplo:
 Requisitos físicos y lógicos.
 Funcionalidades requeridas.
 Integración en el entorno existente.
 Metodología y/o técnicas soportadas.
 Generación de la aplicación.
 Portabilidad a diferentes plataformas.
 Etc.
Evaluación de Productos
La evaluación de los equipos o productos ofertados por
los proveedores, consiste en la realización de una serie de
actividades. Dentro de los factores a evaluar se distinguen
dos tipos de importancia diferente:
 Factores críticos
 Factores secundarios
Factores críticos son aquellos que tienen una relación
directa con la funcionalidad, el rendimiento o la adecuación
del equipamiento que se va a adquirir.
Factores secundarios son aquellos que correspondiendo
a características hasta cierto punto relevantes, no tienen
una importancia crucial ni influyen de modo estrictamente
determinante en la funcionalidad, el rendimiento o la
adecuación de los equipos a su entorno de operación.
La importancia de cada uno de los factores
considerados, sean de naturaleza crítica o bien de carácter
secundario, quedará reflejada en el proceso de decisión a
través de la asignación de los correspondientes pesos
relativos.
Existen múltiples técnicas de evaluación, cuantitativas
y cualitativas, directas e indirectas, cuya aplicación depende
en gran medida de las particularidades del proceso de
adquisición y de las características de los equipos a evaluar.
 En determinados casos, los procedimientos
tradicionales de evaluación son insuficientes para garantizar
a priori el correcto funcionamiento y la adecuación del
sistema que se va a adquirir. Para estos casos se
recomienda que en la fase de evaluación se contemple la
realización de pruebas de adecuación o de rendimiento
("benchmarks") sobre los sistemas ofertados.
Metodología tradicional de evaluación
Las técnicas numéricas utilizadas con mayor
frecuencia se basan en la comparación, entre las
características de los equipos ofertados y las
especificaciones técnicas y requisitos funcionales
especificados en las bases de las especificaciones
técnicas. Se describirá una sencilla técnica de
valorización de uso bastante extendido, basada en
los métodos de análisis de decisión multidiscreta.

 Terminología
Se utilizará la siguiente terminología :
 Alternativas a valorar : A1, A2, ...., Ai, ...., Am (Cada una corresponderá a un equipo u
oferta diferente).
 Criterios de valoración : C1, C2, ...., Cj, ...., Cn (Cada uno corresponderá a un factor o
característica de los equipos a valorar)
 Valoraciones parciales relativas : X11,, X12, ...., Xij, ...., Xmn (Representan la valoración
relativa otorgada a la alternativa Ai en relación con el criterio Cj)
 v Pesos relativos de los criterios de valoración : w1, ..., wj, ..., wn (Cada uno refleja la
importancia relativa de cada factor Cj en el conjunto de las características valoradas)
 Aplicación
La aplicación de este método se basa en obtener
para cada alternativa Ai, las valorizaciones parciales
relativas correspondientes Xij y reducir finalmente la
valoración de cada equipo ofertado mediante la
aplicación de la siguiente expresión:
Valoración de Ai = j (Xij * wj)
Para realizar este proceso de forma ordenada se
deberán seguir los siguientes pasos:
1) Enumeración e identificación de las posibles
alternativas Ai
2) Identificación de los factores susceptibles de
valoración Cj
3) Obtención de los pesos relativos de los criterios wj
Para ello se recomienda asignar los pesos como
porcentajes, reflejando de este modo su importancia
relativa de cada factor en el proceso de decisión)
4) Obtención de las valoraciones parciales relativas
Xij y formación de la matriz (Xij).
(Una forma bastante directa de realizar las
valoraciones parciales, consiste en comparar las
características de cada equipo ofertado con las
exigidas en las bases técnicas, asignando un valor
unidad, si la característica en cuestión es idéntica a
lo establecido en las bases y valores
proporcionalmente más elevados, en la medida que
sea más favorable que el valor mínimo exigido. Si
alguna alternativa incumple de forma manifiesta los
mínimos exigidos en las bases técnicas, deberá ser
desechada)
5) Formación de la matriz (Xij * wj)
6) Obtención de la valoración de cada alternativa
Limitaciones del método
A pesar de que el método es sencillo y rápido de
aplicar, en la mayoría de los procesos de adquisición de
productos y servicios informáticos existen factores cuya
apreciación es difícilmente expresable en términos
numéricos, ya que su naturaleza no es en modo alguno
cuantitativa. No existen técnicas de valoración de validez
universal, por lo que la evaluación de estos factores de
orden cualitativo se suele llevar a cabo por métodos
heurísticos de difícil formalización.
Otro de los puntos que puede considerarse como una
debilidad potencial de los métodos numéricos, es la
existencia de un notable grado de subjetividad a la hora de
asignar los valores de los pesos w j, lo cual es extensible, en
algunos casos, a las valoraciones parciales relativas x ij. En
cualquier caso, los métodos numéricos constituyen una
base interesante para la evaluación de productos sobre la
cual se pueden (y en muchos casos se deben) llevar a cabo
análisis más refinados de orden esencialmente cualitativo.
Evaluación a través de pruebas de
adecuación o de rendimiento
 Existen casos en que es extraordinariamente
importante garantizar a priori, que el funcionamiento de los
sistemas o productos que se van a adquirir es
suficientemente satisfactorio, una vez implantados en su
entorno real de operación y sin embargo, la aplicación de
técnicas tradicionales de evaluación no aporta el grado
necesario de seguridad y certidumbre.
En tales supuestos, es prudente proceder a la
realización de pruebas de adecuación o de rendimiento
("benchmarks") antes de decidir la adquisición de un
determinado producto o sistema. La complejidad de estas
pruebas depende de la naturaleza del producto y de su
entorno de operación. Para su realización puede ser
aconsejable contar con la asistencia técnica de una empresa
especializada
Pruebas de aceptación
Suponen la última fase técnica del proceso de
adquisición a la cual sucede el acto administrativo de la
recepción formal del suministro.
Las pruebas de aceptación se componen de dos grupos de
actividades diferentes:
 verificación de componentes
 verificación del cumplimiento de las especificaciones
Verificación de componentes. Una vez realizada la selección
de ofertas y la correspondiente propuesta de adjudicación,
el suministrador procederá a la entrega e instalación del
sistema contratado. El Organismo comprador deberá
comprobar que han sido instalados todos los dispositivos,
elementos y componentes que se incluyen en la oferta,
tomando nota de los correspondientes modelos y números
de serie a efectos de inventario.
Verificación del cumplimiento de las especificaciones. Está
dirigido a la comprobación de que el equipamiento instalado
cumple las especificaciones técnicas incluidas en las bases
técnicas o presentación de ofertas.
Para ello se podrán utilizar las listas de comprobación
sobre factores críticos u otras que se hayan elaborado a
partir de las anteriores, las que deberán ser coherentes con
las bases técnicas y llevar a cabo las correspondientes
pruebas de aceptación.
Los sistemas CASE son tipos de productos que
pertenecen a la categoría de software empaquetado. Su
fabricación se realiza no para satisfacer las necesidades
particulares de un usuario u organización concreta, sino
para ser vendidos en el mercado a un número de usuarios
tan amplio como sea posible. Por esta razón durante su
desarrollo, estos productos se ven sometidos a una serie de
rigurosos controles de calidad, tendentes a garantizar que
su funcionamiento se ajusta a lo indicado en la
documentación técnica correspondiente y, por otra parte, a
que no existan errores que afecten al correcto
comportamiento del sistema en cuestión.
Este tipo de productos se diferencian del software
desarrollado a medida, ya que éste debe ser sometido a
unas pruebas de aceptación rigurosas por parte del
comprador, con el fin de garantizar el nivel de calidad
demandado.
Sin embargo, hay una serie de puntos sobre los que se
debe comprobar que el entorno CASE se comporta de
acuerdo con las especificaciones, sobre todo en lo relativo a
las funcionalidades y capacidad de integración en el entorno
previamente existente.
Para ello, es conveniente que las pruebas necesarias
para comprobar los puntos anteriores se realicen con
anterioridad a la adquisición. La mayoría de los vendedores
de estos productos suelen admitir el examen y prueba de
sus productos, bien libremente o mediante el pago de una
pequeña tarifa.
En los casos en que no sea posible llevar a cabo
pruebas previas de adecuación y funcionamiento, se
realizarán las correspondientes pruebas de aceptación que
estarán dirigidas a comprobar el adecuado comportamiento
del sistema CASE, en relación con los factores críticos
identificados en el documento de especificaciones.
En el caso de lenguajes de cuarta generación serán
aspectos tales como:
 Soporte de técnicas de programación.
 Generador de aplicaciones.
 Modelos de datos soportados.
 Portabilidad.
 Facilidades de depuración.
 Integración con entornos CASE.
 Interfase y documentación de usuario en español.
 Perfiles de usuarios y factores humanos en el entorno
de operación.
Además de lo expuesto anteriormente, habrá que tener
en cuenta en el proceso de adquisición, lo expuesto en el
punto de Análisis de las necesidades del comprador y
en el de Factores relevantes en el proceso de
adquisición.