Herramientas para El Desarrollo de Sistemas de Información
Herramientas para El Desarrollo de Sistemas de Información
Herramientas para El Desarrollo de Sistemas de Información
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).
Los principales conceptos utilizados en las herramientas de ayuda al desarrollo son los siguientes:
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.
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.
• Control de mantenimiento.
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, aun 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í.
1.2. Herramientas para el desarrollo de sistemas.
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 fases del ciclo de vida del desarrollo de sistemas que cubren.
• 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.
• 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.
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.
• Equipamiento apropiado.
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.
o Herramientas de reingeniería.
o Herramientas de documentación.
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.
Reingenierí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 "reingenierí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:
1.2. Herramientas para el desarrollo de sistemas.
• Planeamiento.
• Análisis y Diseño.
• 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:
1.2. Herramientas para el desarrollo de sistemas.
1.2. Herramientas para el desarrollo de sistemas.
(a) intercambio de datos, (b) acceso común a herramientas, (c) integración de datos, (d)
integración total.
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.
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
1.2. Herramientas para el desarrollo de sistemas.
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:
• Reglas de diseño del software (p. ej.: las distintas formas válidas de dibujar y
equilibrar un diagrama de flujo de datos).
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.
• Elegir una aplicación que reúna la mayor parte de los siguientes requisitos:
o Disponibilidad de recursos.
Se establecerá interfases de compatibilidad de los nuevos sistemas que deben convivir con los
sistemas anteriores.
• Soluciones cliente-servidor.
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.
• 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.
• Técnicas matriciales.
• 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.
• Comparaciones entre gráficos de distintas versiones. De esta forma será más fácil
identificar qué diferencias existen entre las versiones.
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.
1.2. Herramientas para el desarrollo de sistemas.
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.
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.
Las principales líneas de evolución hacia las que parecen encaminarse las herramientas CASE son:
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 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).
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".
1.2. Herramientas para el desarrollo de sistemas.
Consideraciones
v 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.
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.
1.2. Herramientas para el 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.
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:
v 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.
v 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.
Editor
Donde se escriben las sentencias del lenguaje de programación. Puede contar con:
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:
1.2. Herramientas para el desarrollo de sistemas.
• 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.
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.
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.
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
v La distribución de los objetos por las librerías siguiendo los criterios que se establezcan.
v La localización rápida de los objetos con el fin de analizar el impacto de una modificación o
corregir un error.
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:
Se describen en este capítulo las funcionalidades más importantes de otras herramientas de ayuda
al desarrollo.
Gestión de proyectos
v Presentación de diferentes vistas del proyecto (por tareas, por recursos, por fechas...).
Gestión de la Configuración
v Definición de las configuraciones. Criterio que se sigue para seleccionar elementos de una
versión.
Los principales componentes de una herramienta de ayuda a las pruebas y sus funcionalidades
son:
v Utilidades de datos. Describen las características de los datos implicados en la prueba del
software.
v 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.
v 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í.
Los componentes de una herramienta de control de calidad y sus funcionalidades son las
siguientes:
Estos módulos pueden formar parte de una misma herramienta de control de calidad o pueden ser
herramientas independientes entre sí.
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).
v El tratamiento de documentos.
Herramientas de revamping
v 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.
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.
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.
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:
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.
Herramientas CASE
Para una herramienta CASE, el comprador deberá tener en cuenta todas las necesidades,
limitaciones y restricciones que afecten a los siguientes puntos:
1.2. Herramientas para el desarrollo de sistemas.
• 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
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.
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:
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.
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.
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.
1.2. Herramientas para el desarrollo de sistemas.
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.
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:
v De empresa o Institución.
v Económicos.
v 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.
v Certificación de la Instalación.
v Prueba de funcionamiento.
v Responsabilidad de fallas.
v Garantía de la herramienta.
v Asesoría técnica.
1.2. Herramientas para el desarrollo de sistemas.
v Capacitación.
v Información técnica.
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.
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.
• 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.
Además de los factores relevantes anteriores, en las herramientas CASE hay que prestar especial
atención a:
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.
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 prerrequisito para poder utilizarlo.
1.2. Herramientas para el desarrollo de sistemas.
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.
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:
1.2. Herramientas para el desarrollo de sistemas.
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:
v 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:
v Repositorio
v Reingeniería
v Soporte de proyecto
v Control de calidad
v Modelo de Balzer
o Planificación:
� Análisis de viabilidad
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
1.2. Herramientas para el desarrollo de sistemas.
• Soporte a la documentación:
o Edición automática
o Mantenimiento
o Archivo y gestión
o Referencias cruzadas
o Desde:
� "scripts"
� formatos
� diagramas
o Hasta:
� COBOL
� FORTRAN
� PASCAL
� C
� SQL
o Tipo y complejidad
1.2. Herramientas para el desarrollo de sistemas.
o Naturaleza:
� técnico-científica
� gráfica
� transaccional
� proceso de datos
o Lenguajes de programación
o Fabricante y modelo
o Sistema operativo
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
• Coste límite:
o Adquisición
o Operación y mantenimiento
o Costes indirectos
• Generador de aplicaciones.
• Portabilidad.
• Facilidades de depuración.
Algunos de los estándares más importantes son los que se refieren al repositorio. Sobre este tema
se pueden citar:
• 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.
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.
• Funcionalidades requeridas.
• Generación de la aplicación.
• 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.
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
• 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)
1.2. Herramientas para el desarrollo de sistemas.
• 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:
Para realizar este proceso de forma ordenada se deberán seguir los siguientes pasos:
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)
(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)
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 wj, lo cual es extensible, en algunos casos, a las valoraciones parciales relativas xij. 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.
1.2. Herramientas para el desarrollo de sistemas.
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.
• verificación de componentes
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, tendientes 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.
1.2. Herramientas para el desarrollo de sistemas.
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.
• Generador de aplicaciones.
• Portabilidad.
• Facilidades de depuración.