[an error occurred while processing this directive]

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).

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 textos en 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:

v               Si tiene un gran volumen de aplicativos desarrollados, es conveniente contrastar lo realizado versus las técnicas de Análisis y Diseño.

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.

v               Si desea realizar proyectos de gran envergadura es recomendable aplicar Upper y Lower Case.

v               Si trabaja con archivos de grandes dimensiones, es recomendable que el Case soporte el Diseño de Bases de Datos.

v               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.

v                Evalúe la eficiencia del producto, en las pruebas unitarias y de integración, y fundamentalmente en las pruebas de sistemas.

v                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:

v    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:

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.

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:

v    Ayuda de tratamiento de textos.

v    Facilidades para incorporar el nombre de variables, objetos o funciones.

v    Chequeo preliminar de errores de sintaxis.

v    Utilidades de selección, copia o movimiento de bloques.

v    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:

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.

v    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:

v    Independencia de plataformas hardware y software.

v    Independencia de estructuras de datos y acceso a información distribuida.

v    Interoperabilidad con herramientas ofimáticas.

v    Soporte para diferentes interfases gráficas de usuario.

v    Soporte para diferentes entornos de red.

v    La aplicación de forma más extendida del modelo cliente/servidor, tanto en el funcionamiento del propio 4GL como en las aplicaciones generadas.

v    Mayor apertura para la interfase con herramientas CASE.

v    Incorporación de la tecnología de orientación a objetos.

v    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:

v    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.).

v    Presentación de diferentes vistas del proyecto (por tareas, por recursos, por fechas...).

v    Definición de calendario a nivel de proyecto y de recurso.

v    Establecimiento de diferentes relaciones entre tareas (final- inicio, final-final, inicio-inicio).

v    Facilidades gráficas para la planificación (diagrama de GANTT, diagrama de PERT).

v    Resolución de conflictos de los recursos.

v    Facilidades para la impresión de programas de trabajo.

v    Posibilidad de desarrollar macros.

v    Conexión entre varios proyectos.

v    Facilidades de importación / exportación.

v    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:

v    Identificación de cada uno de los elementos de la aplicación: número de versión e información de carácter general.

v    Soporte para jerarquías de elementos.

v    Control de versiones. Utilización de técnicas de bloqueo de objetos o código para evitar actualizaciones simultáneas por varios desarrolladores.

v    Definición de las configuraciones. Criterio que se sigue para seleccionar elementos de una versión.

v    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:

v    Utilidades de datos. Describen las características de los datos implicados en la prueba del software.

v    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.

v    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.

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í.

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:

v    La creación de interfases gráficas de usuario (IGU).

v    El acceso a bases de datos.

v    La integración de funcionalidades multimedia.

v    El tratamiento de documentos.

v    El intercambio electrónico de datos.

v    El desarrollo de aplicaciones científicas, matemáticas o de ingeniería.

Herramientas de revamping

Las principales características de estas herramientas son:

v    Soporte de un determinado estándar de comunicaciones con el ordenador central (host) a través de terminales.

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.

v    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:

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.

·                     Consideraciones en el Contrato de Adquisición. Aparte de las cláusulas que son comunes a todos los contratos, se considerarán las siguientes:

 

v    Requerimientos para el funcionamiento del Case.

v    Incumplimiento de los requerimientos.

v    Entrega e instalación de la herramienta.

v    Instalación del Case.

v    Certificación de la Instalación.

v    Prueba de funcionamiento.

v    Informe de fallas durante la prueba de aceptación.

v    Responsabilidad de fallas.

v    Penalidad en caso de no alcanzar el nivel de funcionamiento mínimo.

v    Constancia de aceptación del equipo.

v    Garantía de la herramienta.

v    Asesoría técnica..

v    Capacitación.

v    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:

v    Fases del ciclo de vida soportadas.

v    Metodologías de diseño soportadas.

v    Generación automática de código fuente.

v    Aplicaciones a desarrollar con el soporte de la herramienta.

v    Plataforma(s) de implantación de la herramienta.

v    Herramientas lógicas que deben integrarse en/con la herramienta.

v    Modo de funcionamiento (monousuario / multiusuario).

v    Perfiles de usuarios y factores humanos en el entorno de operación.

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:

·                     Funciones CASE requeridas:

 

v    Repositorio

v    Re-ingeniería

v    Soporte al ciclo de vida

v    Soporte de proyecto

v    Control de calidad

v    Otras (se indicará cuáles)

 

v    Paradigmas de desarrollo soportados:

v    Ciclo de vida en cascada

v    Creación y refinamiento de prototipos

v    Desarrollo por especificaciones fuertemente formalizadas

v    Modelo de Balzer

v    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 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.

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.

 

 

 

 

 

 

 

CUESTIONARIO DE EMPRESA

 

 

 

 


CUESTIONARIO ECONOMICO

 



[an error occurred while processing this directive]