1.1 CLASIFICACIÓN DE LAS HERRAMIENTAS CASE Tradicionalmente las herramientas CASE han sido categorizadas dependiendo de la fase del ciclo de vida donde se emplean. No obstante, resulta igualmente interesante su clasificación de acuerdo con el nivel de integración, una preocupación creciente en la Ingeniería del Software asistida por computadora. Las siguientes secciones estudian con detalle ambas clasificaciones basada en el ciclo de vida, por permitir una clasificación más detallada de las herramientas. 1.1.1
Herramientas CASE según el ciclo de vida
La clasificación más habitual divide las herramientas CASE según la fase del ciclo de vida para el cual han sido concebidas – concebidas – de de hecho, esta es una clasificación que propone la guía SWEBOK-. No es infrecuente tampoco, ver como se distingue entre herramientas Upper-CASE y herramientas Lower-CASE, dependiendo de las fases del ciclo de vida al que proporcionen soporte. Las herramientas Upper-CASE dan soporte, según esta clasificación, a tareas del desarrollo mas cercanas a la definición conceptual (obtención de requisitos, análisis, etc.), mientras que las Lower-CASE dan soporte a tareas de programación, diseño, pruebas, mantenimiento o gestión de la configuración. Como lo muestra la siguiente figura:
Empleo de herramientas a lo largo del ciclo de vida del software Gestión
Upper CASE: Herramientas de gestión de proyectos
Análisis
Upper CASE: Herramientas de requisitos
Diseño
Upper CASE: Herramientas de diagramación y modelado
Construcción
Lower CASE: Herramientas de generación de código y BBDD BB DD Lower CASE: Herramientas de gestión de la configuración
Pruebas
Lower CASE: Herramientas de pruebas
Mantenimiento
Lower CASE: Herramientas de generación de documentación Lower CASE: Herramientas de requisitos y gestión de cambios
A continuación se muestra una clasificación detallada de las herramientas CASE según la fase del ciclo de vida del desarrollo del software en la que se aplican. Herramientas Herramientas de requisitos
Dentro de esta categoría de herramientas podemos encontrarnos con dos tipos:
Herramientas para el modelado de requisitos. Se utilizan para la obtención, análisis, especificación y validación de los requisitos. Herramientas para el seguimiento de los requisitos (trazabilidad). Permiten hacer un seguimiento de los requisitos a lo largo de todo el ciclo de vida del desarrollo, identificando, por ejemplo, que artefactos implementan un determinado requisito, o que elementos de diseño dan cumplimiento a un cierto conjunto de requisitos.
Las herramientas para el modelado de requisitos son muy variadas, ya que dentro de esta categoría se engloban tareas relacionadas, pero heterogéneas. Así, las herramientas para la obtención de requisitos proporcionan facilidades para los diferentes actores implicados en la recogida de los requisitos para introducirlos y centralizarlos, permitiendo y facilitando, en ocasiones, la conexión con plataformas de trabajo en grupo. Las herramientas para el análisis de requisitos , a menudo, proporcionan plantillas para documentos y hoja de cálculo que facilitan la creación de documentos simples que permiten reflejar el análisis a realizar dentro de los distintos tipos de requisitos. Un ejemplo de este tipo de herramientas son aquellas que permiten hacer análisis de escenarios y que incorporan facilidades para comprobar la consistencia entre escenarios o su compleción y consistencia con ciertos modelos de requisitos. Las herramientas para la especificación de requisitos suelen incluir un lenguaje de especificación (más o menos formal) que permite modelar los requisitos de acuerdo a dicho lenguaje o notación. A menudo, se trata de herramientas que permiten modelar requisitos visualmente basándose en notaciones conocidas, tales como los casos de uso. Finalmente, las herramientas para la evaluación de requisitos permiten comprobar la corrección de los mismos, proporcionando habitualmente al desarrollador alguna facilidad para comprobar la consistencia de los requisitos con un modelo dado, tales como comprobadores automáticos de sintaxis o semántica. Las Herramientas para el seguimiento de requisitos son cada vez más importantes en el proceso de requisitos, ya que la complejidad del software construido hace muy difícil determinar qué requisito determinó un cierto artefacto o una cierta parte del diseño, si no se dispone de herramientas software específicas. Estas herramientas, por tanto, almacenan toda la información sobre los requisitos, como por ejemplo, los documentos de especificación que los originaron, los documentos de análisis y diseño donde se implementaron o las pruebas de aceptación que permiten comprobar su cumplimiento. Gracias a estas herramientas es posible, no solo seguir la traza de un requisito, sino también elaborar informes sobre el cumplimiento de los mismos o el estado de desarrollo del producto de acuerdo con una necesidad concreta. Herramientas para diseño
Cuando se desea diseñar un sistema software es necesario utilizar herramientas que soporten la creación de gráficos, que sean conformes con las diferentes notaciones de diseño que pudieran ser empleadas (tales como UML) y que, en general, ayuden a automatizar las tareas de análisis y diseño del software a partir de los requisitos del sistema. En esta área, el espectro de actividades
es tan amplio que las herramientas de diseño podrían subdividirse atendiendo, como criterio de la clasificación, a cada una de las actividades específicas del diseño. Algunas de las subcategorías podrían ser (entre otras): Herramientas para el diseño de interfaces. Herramientas para la elaboración de prototipos. Herramientas para la creación de diagramas de análisis y diseño. Herramientas para presentación e implementación de arquitecturas de software. Herramientas para la descripción y comprobación de restricciones. Diccionarios de datos, que permiten almacenar información sobre las entidades del diseño y sus relaciones. Herramientas para construcción
En los albores de las ciencias de la computación, la programación era la única preocupación de los desarrolladores. Hoy en día existen muchos otros aspectos –igual de importantes- a tomar en cuenta en un proyecto de desarrollo de software. Sin embargo, al ser la programación la actividad (tradicionalmente) central del proceso, existen para esta etapa más herramientas que para cualquier otra. El número y tipo de herramientas para construcción disponibles es muy elevado. Entran dentro de esta categoría los editores, los compiladores e intérpretes, los enlazadores, los depuradores, las herramientas para el diseño y construcción de interfaces, las herramientas para creación y ejecución de ejecutables o las herramientas para construcción de prototipos y simulaciones, entre otras. Muchas de ellas son dependientes del lenguaje, tales como los compiladores o los intérpretes, mientras que otras, como los editores de texto, son herramientas de propósito general que se adaptan a la construcción de software. Si bien muchas de las herramientas de construcción son de sobra conocidas, como los compiladores o los editores de texto, es interesante dedicar algunas líneas a las herramientas de construcción automática de ejecutables a partir del código fuente. Se tratan de herramientas que simplifican el proceso de compilación del software utilizando ficheros de configuración (a menudo denominados ficheros make) y que permiten, entre otras funcionalidades obvias como la generación del código objeto, un mayor control del proceso de construcción, realizar configuraciones específicas para diferentes sistemas, generar preprocesadores o utilizar plantillas de configuración. Algunas de ellas son, incluso, independientes del compilador utilizado y de la plataforma destino, lo que les confiere una gran flexibilidad. Herramientas para pruebas
Muchas de las actividades relacionadas con las pruebas son repetitivas y hasta cierto modo monótonas, por lo que ésta es una de las áreas donde la utilización de herramientas de apoyo cobra mayor sentido. Es posiblemente por ello por lo que la automatización de las pruebas es una de las áreas para las que existe un mayor número de herramientas disponibles. Teniendo en cuenta sólo aquellas herramientas de código fuente abierto, podemos listar más de 300 herramientas orientadas a facilitar las pruebas de los más diversos tipos: pruebas funcionales, de rendimiento, de gestión de pruebas, pruebas de unidad, de detección y seguimiento de fallos,
pruebas de regresión, etc. Las herramientas CASE para las pruebas se enmarcan dentro de las siguientes categorías: Generadores de pruebas. Marcos de trabajo (frameworks) para la ejecución de pruebas. Herramientas de evaluación de pruebas. Herramientas de gestión de las actividades de pruebas. Analizadores de rendimiento. La implementación es una colección de pruebas, por ejemplo, se lleva a cabo un plan de pruebas y de acuerdo con las directrices de una especificación de pruebas, por lo que todos los actores implicados en este proceso deben trabajar estrechamente. Por ello, junto con aquellas herramientas específicamente diseñadas para un tipo concreto de pruebas, existen a disposición de los desarrolladores conjuntos de herramientas (cajas de herramientas y bancos de trabajo) que integran varias herramientas relacionadas. SE trata de software que, además de proporcionar apoyo técnico para la realización de los distintos tipos de prueba que cubren y facilitan el trabajo en grupo, incluyen, además, capacidades para realizar tareas de gestión del propio proceso, tales como monitorizar las pruebas realizadas, controlar los equipos que las llevan a cabo, realizar informes y estadísticas, etc. Herramientas para mantenimiento
El mantenimiento del software es una actividad compleja a la que se dedica mucho tiempo y esfuerzo. Se trata de una tarea de tal importancia que se hace difícil pensar en llevarla a cabo sin ayuda de herramientas. Dentro de la categoría de las herramientas CASE para el mantenimiento, es posible señalar fundamentalmente dos: las herramientas de análisis de código y las herramientas para la ingeniería inversa. No obstante, también se utilizan durante esta fase herramientas de pruebas (fundamentalmente simuladores de pruebas), de generación de documentación y de gestión de la configuración, entre otras. Las herramientas de análisis de código permiten comprender otros programas, por lo que son especialmente importantes en una fase como la de mantenimiento, donde una gran parte del esfuerzo se invierte en comprender el software que se ha de mantener. Dentro de este tipo de herramientas se encuentran las siguientes: Analizadores estáticos, que permiten marcar aquellas secciones de un programa que pueden tener influencia en otro punto que quiere analizarse, facilitando a menudo esta tarea mediante el uso de gráficos. Los encargados del mantenimiento pueden así concentrarse en aquello que podría cambiar cuando, por ejemplo, se modifica el valor de una variable, lo que permite prever los efectos de la introducción de los cambios. Analizadores dinámicos o inspectores, que permiten analizar un programa durante su ejecución. Algunos, como los analizadores del flujo de datos, permiten observar la lógica del programa y las relaciones entre diferentes elementos. Gestores de referencias cruzadas, que facilitan información sobre el uso de un programa, pues permiten hacer búsquedas en la base de datos de dependencias del mismo para, por ejemplo, comprender mejores las interrelaciones y dependencias entre los módulos. A menudo, permiten mostrar dicha dependencia mediante gráficos.
Dentro de las herramientas de ingeniería inversa se pueden citar multitud de ellas, si bien las más conocidas sean quizá las siguientes: Compiladores inversos (o descompiladores), que permiten obtener código fuente a partir de un código objeto. Si el código obtenido es ensamblador entonces se denominan desensambladores. Herramientas de análisis de código de bajo nivel, tales como los editores de código hexadecimal y los analizadores de código objeto. Generadores de diagramas de diseño a partir del código fuente, como los generadores de diagramas de clases o de paquetes. Generadores de diagramas de bases de datos, que permiten generar modelos de alto nivel (por ejemplo, diagramas de entidad-relación) a partir de la información existente en la base de datos Cualquier modificación que deba abordarse como parte de una tarea de mantenimiento debe ser probada adecuadamente antes de darla por válida. Las herramientas CASE que se emplean durante las pruebas en tareas de mantenimiento son las mismas que se han descrito en la sección anterior, si bien resulta interesante mencionar los simuladores de pruebas, ya que se utilizan más frecuentemente en tareas de mantenimiento que en nuevos desarrollos. Se trata de herramientas que permiten comprobar los efectos que tendría un cambio en el sistema actual, lo cual ayuda a valorar la oportunidad de llevarlos a cabo. Herramientas para la gestión de la configuración
Las herramientas para la gestión de la configuración pueden clasificarse en tres categorías: Herramientas para detección y seguimiento, herramientas para el control de versiones y herramientas de construcción y distribución de entregas del software. Las herramientas para detección y seguimiento permiten monitorizar y seguir los defectos, problemas, mejoras y otras cuestiones dentro de un desarrollo de software. Las herramientas de gestión de flujos de trabajo facilitan la colaboración de las diferentes personas que intervienen en un proceso de este tipo. Igualmente, la utilización de una base de datos de cambio, problemas, defectos y otros asuntos pendientes permite una mayor facilidad ala hora de administrar todas las tareas relacionadas con los cambios. Las herramientas de control de versiones permiten controlar los cambios producidos en un software entre las distintas versiones del mismo. Las herramientas de construcción y generación de entregas automatizan las tareas de elaboración de una nueva entrega del software a partir de un conjunto de archivos de configuración creados a tal efecto. Estas herramientas parten de una especificación que dicta que es lo que se quiere construir, cuales son las dependencias de construcción y cuáles son las reglas para llevar dicha tarea a cabo y, a partir de los archivos fuente creados por los programadores, realiza las siguientes tareas:
Construye los elementos a instalar en la máquina destino. Detecta la configuración del sistema destino. Busca e instala los archivos de cabecera, bibliotecas y otros archivos de configuración necesarios para la correcta ejecución del software. Instala los archivos de ayuda y otros elementos auxiliares. Realiza las tareas finales necesarias para que el nuevo software pueda ejecutarse (por ejemplo, si es necesario un reinicio del sistema, lo fuerza). Herramientas para gestión
Los gestores de proyectos tratan con actividades que demandan la participación de personas con un perfil de especialización determinado y cuyo número es limitado. En el desarrollo de proyectos de cierta envergadura, la asignación de recursos a tareas resulta de gran complejidad. Posiblemente por ello, la gestión del desarrollo es una de las tareas más cubiertas por la oferta comercial de herramientas CASE. Las herramientas disponibles son muchas y muy variadas, aunque es posible agruparlas en las siguientes categorías: Herramientas de planificación y seguimiento de proyectos. Estas herramientas están orientadas a proporcionar una planificación más eficiente, realizar estimaciones del esfuerzo y los costes, y en definitiva, a proporcionar una mejor gestión y desarrollo del proceso de construcción, en general. Facilitan la tarea de los gestores del proyecto, pues permiten controlar la asignación de recursos a tareas, ajustar dichas asignaciones para evitar conflictos, gestionar los plazos de las diferentes actividades, controlar los gastos asignando presupuestos tanto a las tareas como al proyecto en su conjunto, etc., y generar gráficos e informes sobre cualquiera de estos aspectos. Herramientas de gestión de riesgos, que como su propio nombre indica, permiten identificar, priorizar y gestionar los riesgos del desarrollo. Se entiende por gestión de riesgos el control y verificación constante de aquello que podría ir mal, las actividades para determinar qué riesgos son importantes y la implementación de estrategias para gestionar dichos riesgos. Algunas de estas herramientas han sido desarrolladas para procesos específicos, si bien los principios básicos de la mayoría de ellas permiten aplicarlas a cualquier proceso de desarrollo donde se realice gestión de riesgos. Herramientas para medición. Debido al aumento de la medición como parte de las labores de ingeniería del software, han aparecido en el mercado numerosas herramientas que dan soporte a los diferentes métodos de medición, y en particular, a la recogida y análisis de datos para la posterior elaboración de informes. No obstante, existe mucha confusión todavía, debida, en buena medida, a la inmadurez de la Ingeniería del Software en esta área, por lo que no es infrecuente ver cómo casi cada fabricante proporciona su propio conjunto diferente de medidas, a menudo incompatibles con las que proporcionan otros fabricantes. Herramientas para procesos
Dentro de esta categoría se clasifican las herramientas de modelado, las herramientas de gestión de procesos y los entornos integrados. Los modelos de procesos son complejas estructuras que permiten describir formalmente los pasos y actividades de un desarrollo. La creación de estos modelos por parte de los ingenieros del
software permite crear un modelo específico para un desarrollo concreto (lo que denomina instanciar un modelo de procesos). Las herramientas de modelado permiten cuestionar e investigar los procesos de Ingeniería del Software, así como diseñar, realizar y probar modelos de dichos procesos. Las herramientas de gestión de procesos permiten gestionar la ejecución de los procesos software una vez que han sido modelados e instanciados, incluir aspectos críticos para el rendimiento del proceso (por ejemplo, características específicas y experiencias anteriores de los recursos humanos que participarán en el mismo), y administrar la naturaleza dinámica de los procesos, lo que a menudo obliga a remodelar un proceso debido a modificaciones o a eventos imprevistos. Este tipo de herramientas suelen clasificarse como entornos CASE centrados en el proceso (IPSEE) , pues incorporan información sobre los procesos y guían a los gestores de acuerdo con un proceso definido. Al tratarse de las herramientas que gestionan múltiples funciones, tienen mucha interacción con el proceso en ejecución. Herramientas para garantizar la calidad
La calidad es una preocupación creciente en los desarrollos, por lo que cada vez resulta más necesario utilizar herramientas que den soporte a las actividades relacionadas con su gestión. Las herramientas para calidad de software pueden dividirse, fundamentalmente, en dos categorías: Herramientas de auditorías e inspección: facilitan la realización y revisiones de los diferentes artefactos generados durante el desarrollo. Permiten identificar qué artefactos no se ajustan a ciertos estándares de calidad., hacer un seguimiento de los mismos, inventariar los problemas de calidad detectados y realizar informes. Herramientas de análisis estático: permiten comprobar la conformidad, tanto del software como de los artefactos generados durante el desarrollo con los estándares o especificaciones de calidad empleados, o simplemente, comprobar que verifican ciertas propiedades. Se emplean analizadores sintácticos y semánticos que permiten comprobar que los datos y relaciones entre ellos son correctas. 1.1.2
Herramientas CASE según su nivel de integración
A medida que la industria del software se ha desarrollado, han ido apareciendo herramientas cada vez mas potentes y complejas que dan soporte, bien a actividades puntuales o bien a conjunto de actividades relacionadas. Según este criterio, es posible clasificar las herramientas CASE en cuatro tipos con muy distinto nivel de integración. Con frecuencia se hace uso de mas de una herramienta CASE durante las distintas actividades del ciclo de vida de un software. De hecho, para cubrir todas las actividades a realizar suelen emplearse combinaciones de herramientas que soportan conjunto de tareas (conocidas como bancos de trabajo) y herramientas específicas para una tarea (denominadas herramientas independientes).
Debe tenerse en cuenta que la utilización de diversas herramientas no es inmediata, sino que se deriva de ella un conjunto de problemas cuya descripción exhaustiva sería demasiado prolija. No obstante, es posible enumerar los más relevantes:
Las herramientas consideradas idóneas para las diferentes actividades del desarrollo no serán, casi con seguridad, del mismo fabricante. Algunas herramientas han sido diseñadas para trabajar sobre una cierta plataforma, y lamentablemente no lo hacen correctamente sobre otras. Ciertas herramientas pueden importar datos de otras, pero no te todas aquellas con las que podrían llegar a interconectarse. A veces, tampoco son capaces de exportar datos en formatos que permitan a otras herramientas importarlos correctamente. La falta de flexibilidad de algunas herramientas no permite adaptarlas para configurar características específicas de ciertos elementos, tales como la apariencia de la interfaz o sus conexiones con otras herramientas.
Dado que en los desarrollos actuales se utilizarán, casi con seguridad, herramientas en muchos puntos diferentes del ciclo de vida, y dado que será deseable que dichas herramientas puedan cooperar, es importante estudiar diferentes técnicas o categorías de integración entre herramientas. Así, es posible identificar cinco niveles de integración: 1. La integración a nivel de plataforma se refiere a la capacidad de diferentes herramientas para interoperar en un entorno de red heterogéneo. 2. La integración a nivel interfaz tiene que ver con la uniformidad en la representación de la información al usuario. 3. La integración a nivel de proceso se da cuando existe una relación entre las herramientas y el propio proceso de desarrollo que permite enlazarlos. 4. La integración a nivel de datos se da cuando existe la posibilidad de que distintas herramientas intercambien y compartan datos. 5. La integración de control tiene que ver con la capacidad de una herramienta para desencadenar comportamientos en otra (iniciar acciones, notificar eventos, etc.). La discusión subsiguiente analiza los diferentes conjuntos o entornos de herramientas según su nivel de integración. Este criterio nos permitirá clasificarlos en cuatro grupos distintos: herramientas independientes, cajas de herramientas (a menudo conocidos como toolkits), bancos de trabajo y entornos CASE, los cuales a su vez se clasifican en entornos CASE integrados y entornos CASE centrados en el proceso. En los puntos siguientes se estudiarán con mayor profundidad cada una de estas categorías. Herramientas CASE independientes
Son aquellas que realizan únicamente una tarea específica y definida dentro del desarrollo. Si bien es cierto que en la mayoría de los casos pueden trabajar conjuntamente con otras herramientas, son independientes y pueden por tanto, instalarse y utilizarse por separado. Algunos ejemplos de este tipo de herramientas sería un depurador de código, un software para diseño de diagramas entidad-relación para bases de datos, o un generador de informes, por citar solo algunos de los más conocidos. No obstante, debe tenerse en cuenta que pocas herramientas son completamente independientes, pues la mayoría se adhiere a estándares o especificaciones de funcionamiento que les permiten proporcionar salidas en un comprensible para otras herramientas CASE. Esto es así, incluso en muchas herramientas que no fueron inicialmente concebidas para trabajar con ninguna otra herramienta en particular. Las herramientas CASE independientes conforman el nivel mayor de independencia, lo que conlleva un mínimo o nulo nivel de integración. Incluso así, es posible integrarlas con otras herramientas para que cooperen (y a menudo se desea hacerlo); sin embargo, este esfuerzo corre por parte del equipo de desarrollo. Cajas de herramientas (toolkits)
En el siguiente nivel de integración se encuentran las cajas de herramientas. Pensar en el carpintero que tiene centralizado en un determinado lugar todas las posibles herramientas de las que habitualmente hace uso durante su trabajo, es una metáfora que define muy bien lo que son las cajas de herramientas en la Ingeniería del Software. Una cajas de herramientas contiene un conjunto de herramientas simples, cada una de las cuales tiene un fin específico. Entre ellas no se han implementado mecanismos de integración, por lo que el funcionamiento conjunto suele requerir un esfuerzo extra para su integración, lo cual no siempre es posible. Las herramientas en este tipo de entorno están débilmente acopladas, pues no dependen de otras para su correcto funcionamiento ni tampoco están diseñadas para tener en cuenta que los datos o informes que generan puedan ser utilizados por otras herramientas. La principal ventaja de las cajas de herramientas es que resulta posible utilizar solo algunas de ellas. Así, muchos entornos permiten personalizar la instalación, indicando que herramientas quieren instalarse y cuales no. Pueden ser útiles gracias a su flexibilidad como colecciones de base cuando, por ejemplo, en un punto concreto del desarrollo se considera más interesante utilizar una herramienta independiente y no la herramienta proporcionada por el toolkit . En cuanto a los inconvenientes, nos encontramos con todos los derivados de los problemas de integración ya señalados. Bancos de trabajo (workbenchs)
La creciente necesidad de utilizar herramientas en diferentes fases del desarrollo ha llevado a la aparición de conjuntos de herramientas integradas. El concepto de banco de trabajo (workbench en inglés) define un entorno práctico formado por un conjunto uniforme de herramientas que facilitan las tareas de desarrollo en algún punto del mismo; estas herramientas están orientadas a las tareas y no al tipo de proyecto, por lo que dan soporte a una o varias fases del desarrollo, pero no a todas. Así, un banco de trabajo para programación incluirá un conjunto de herramientas para
la programación (editor, compilador, depurador, enlazador, etc.), no específicamente dirigidas a un modelo específico de ciclo de vida, mientras que uno para diseño incluirá un conjunto de herramientas específicamente dirigidas a facilitar la tarea del diseñador del software. Una de las características a resaltar en esta definición de banco de trabajo es el hecho de que las herramientas que la conforman son capaces de cooperar entre si, es decir, están integradas. Así, debe tenerse en cuenta que los bancos de trabajo incluyen herramientas completamente independientes (tales como un editor de texto), si bien algunas de ellas son fuertemente dependientes del banco de trabajo y no pueden utilizarse fuera del mismo. Es importante tener en cuenta que la utilización combinada de uno o más bancos de trabajo y/o herramientas CASE independientes para cubrir todas las actividades del ciclo de vida del desarrollo obliga a la organización a un esfuerzo de integración muy importante. Además dicho esfuerzo puede toparse con diversos problemas, no siempre solucionables.
Dificultad para combinar fácilmente herramientas o bancos de trabajo que cubran todo el ciclo de vida del desarrollo del software. Esto ocurre cuando, por ejemplo, las herramientas de requisitos y las de diseño tienen diferentes arquitecturas de implementación o dan soporte a métodos distintos. Desalineamientos o solapamientos de herramientas que llevan a cabo tareas similares. Por ejemplo, cuando varias herramientas llevan a cabo formas de control de versiones incompatibles entre sí. Inexistencia de procedimientos para el intercambio de datos entre aplicaciones. Problemas para realizar la integración en el control de las herramientas, por ejemplo, cuando los problemas en la comunicación impiden realizar tareas donde una herramienta necesita invocar un comportamiento en otra. Problemas derivados de la dificultad para monitorizar el progreso de las tareas desde el punto de vista de su gestión.
Los entornos CASE, que constituyen el nivel más alto de integración, aspiran a resolver todos estos problemas. Entornos CASE
En la mayoría de desarrollos es imprescindible la integración de las herramientas CASE utilizadas. Así, los artefactos de diseño deben estar relacionados con el código generado y con los requisitos que dieron origen a ambos, diseño y código, detallando todas estas relaciones en la documentación correspondiente. Todo ellos debe, además, estar sujeto a un riguroso control de versiones. De este modo, surge la necesidad de conectar las diferentes herramientas y/o bancos de trabajo utilizados a lo largo de las diferentes fases del desarrollo, evitando lo que algunos autores han denominado isla de desarrollo.
Para conformar un entorno global, pueden organizarse diferentes herramientas CASE y bancos de trabajo, pero deben integrarse si aspiran a operar uniformemente sobre distintas plataformas software y hardware y proporcionar soporte a múltiples tipos de usuarios. Algunos de ellos, como los gestores de desarrollo y los desarrolladores propiamente dichos, se sirven simplemente de algunas de las herramientas proporcionadas para hacer más fácil su tarea. Otros, como los integradores de herramientas, garantizan que las herramientas cooperen correctamente y funcionan sin problema sobre la plataforma hardware o software utilizada y que es mantenida por los administradores del sistema. En suma, los entornos integrados surgen de la necesidad de que diferentes personas realicen tareas interdependientes. Así por ejemplo, los programadores generan código que será probado por otras personas, pero que debe estar centralizado para que todos tengan acceso a dicho código: los ingenieros de pruebas para consultarlos y probarlos y los propios programadores para introducir modificaciones en el mismo, derivadas del propio progreso del desarrollo o de los errores detectados durante las pruebas. El objetivo es que las herramientas que utilicen las diferentes personas involucradas en el desarrollo sean tan interoperables como sea posible, por lo que su esfuerzo en la integración es previo al inicio del desarrollo. Es, en realidad, la propia organización que distribuye el entorno que debe hacer dicho esfuerzo y quien, en buena medida, es responsable de los errores de integración que pudieran aparecer. Los entornos CASE constituyen el nivel más alto de integración dentro de las herramientas CASE, y surgen para superar los problemas que plantea la integración de uno o más bancos de trabajo y herramientas CASE independientes. Es importante destacar que un conjunto de herramientas heterogéneas para el desarrollo no constituye por sí solo un entorno CASE. Debe existir, por el contrario, algún tipo de mecanismo que facilite la interacción entre las herramientas que lo conforman, lo cual puede ser un mecanismo físico como una base de datos centralizada donde se almacenan todos los datos del desarrollo (repositorio CASE o bus de software), o una concepción común sobre cuál debe ser la filosofía que guíe el desarrollo, o una combinación de ambas cosas. Según el enfoque de integración, podemos identificar dos tipos:
Entornos de soporte integrados al proyecto (IPSE, del acrónimo inglés integrates Project support environment). Entorno case que da soporte a todas las fases del desarrollo, y que incluye un repositorio central con el que las herramientas se comunican para obtener y almacenar datos. Puede incluir componentes de diferentes fabricantes, los cuales, eso si, comparten el mismo repositorio. Estos componentes podrían tener una concepción distinta al proceso de desarrollo, pero están diseñados para escribir y leer el repositorio de manera estandarizada, lo que les permite cooperar con otras herramientas o componentes. Entornos CASE centrados en el proceso (PSEE, de process centered engineering environment). SE trata de entornos formados por herramientas que poseen idéntica concepción del proceso de desarrollo. Al haber sido específicamente diseñadas para utilizarse en un determinado proceso de desarrollo, las herramientas que la conforman suelen mantener unos mayores niveles de acoplamiento, si bien, también es posible la
utilización de herramientas externas en tareas concretas, pues suelen permitir la conexión con compiladores o gestores de configuración independientes.1
