HERRAMIENTAS CASE, 2COMO INCORPORARLAS CON EXITO EN NUESTRA ORGANIZACION? Pascual Gonzalez Lopez Ana Amelia Gonzélez Lépez José Antonio Gallud Lézaro Pascual Gonailes Liper, Ana Amelia Gonz Lipes y José Antonio Gallud Learo extn en ef Departamento de In- Formiticn Exe, Uni. Poiténiea de Albacete. Universidad de CastlacLa Manche. RESUMEN Enestc articulo se analiza un nuevo modo de desarrollo del software basadoen su aulomatizacién, las herramientas CASE, Este tipo de herramientas tienen como grinci- pal objetivo fecilitar Ia obvenciGn de software de mayor ealidad, a un menor cost, Jun- toa una breve exposicién sobre To que entendemos por CASE, nos centraremos en el estudio de las tareas asociadas al proceso de seleccién o implantacién de una yerra- ‘mienta de este tipo, Proceso que, por otra parte, es Fundamental para asegurar el éxito en a incorporacién de estas herramientas dentro de una organi2acin. 1. ,QUE ES EL CASE? 1000 el mundo conoce el famoso dicho popular de «en casa del he- rrero cuchara de palo», o Ia historia del zapatero que estaba tan ocupado que no se petcaté que sus hijos iban descalzos. Algo parecido a lo que describen ambos dichos populares es lo que les ha sucedido a los ingenieros del software en el pasado, los cuales, aunque han desarrollado sistemas complejos para automatizar el traba~ jo de otros, no han Tlegado a aplicar esas mismas técnicas para intentar automatizar su propio trabajo, el desarrollo de sistemas. Hoy en dfa podemos decir que el ingeniero de software ha elabora- do su primera cuchara metélica 0 st primer par de zapatos, en la forma de Ia «ingenieria de software asistida por ordenador» o mas popalar- mente conocida como «CASE». En la actualidad, y siguiendo con el sfmil del zapatero, no hay tanta variedad de zapatos como nos gustarfa; 195,a veces son muy rigidos y otros ineémodos; no son suficientemente so- fisticados para los mas exigentes y no siempre van con las prendas que tenemos en nuestros armarios; sin embargo podemos decir que ya constituyen una pieza indispensable del guardarropa del ingeniero y, con el tiempo, se harin mas confortables, més adaptables al usuario’y tal vez con una apariencia totalmente distinta pero al final seguiran re- alizando la misma funcién: ayudar a la concepeién y construccién de sistemas software. Es importante tener en cuenta que al igual que en otras ingenierias, la introduccién de herramientas cada vez més potentes no sélo cambia los métodos de diseiio 0 construccién, sino que también amplia el hori- zonte sobre qué puede ser construido. No es posible desarrollar siste- mas software altamente complejos utilizando métodos manuales, cuan- do estos sistemas, al igual que el entorno en el que estan inmersos, de- berdin evolucionar y cambiar rpidamente, Por tanto en el futuro, para seguir siendo competitivas, las corpora- ciones dependerén de potentes herramientas que les permitan desarro- Iar y mantener sus sistemas de informacién, algo que cada vez es més importante y estratégico para mejorar la gestiGn, calidad, productivi- dad y en definitiva la competitividad de las organizaciones modernas. El término CASE. se estableci6 durante los afios 80 en los Esta- dos Unidos como abreviatura de «Computer Aided Software Enginee~ ring». Este término se hizo popular, al asociarse con potentes herra- mientas para el desarrollo de sistemas, con las cuales se abria en un principio una puerta de esperanza a multitud de organizaciones donde el desarrollo y mantenimiento del software se haba convertido, como decfa Brooks [BRO75}, en un «hombre lobo», y se vefa a estas herra- ientas como la «bala de plata» que terminase con él. Las herramientas CASE proponen una nueva filosoffa del concepto de ciclo de vida basado en la automatizacién, para lo cual proporcio- nan un conjunto de herramientas bien integradas, que, enmarcadas dentro de una determinada metodologfa, permiten automatizar las fa ses del ciclo de vida de un sistema software. Con esta automatizacién total, se intenta conseguir una mejora en la productividad y en Ia calidad del producto final. Para alcanzar estas ventajas se define un conjunto de objetivos: ‘© Automatizar e integrar las tareas de Tas distintas etapas del ciclo de vida, junto con la gestién de proyectos software, ‘© Mejorar la calidad mediante la automatizacién de la comproba- cin de errores. ‘Automatizar la generacién de la documentacién, ‘+ Facilitar que se pueda compartir Ia informacién entre varios pro- yectos y la reutilizacién del software. ‘© Aportar un entomo de desarrollo interactive.© Acercar el desarrollo al usuario facilitandy la creacién de proto- tipos. © Simplificar la labor de mantenimiento, Esta automatizacién del proceso de desarrollo leva consige algu- nas variaciones en el ciclo de vida, al permitir la verdadera aplicacion de ciclos de vida de desarrollo répido de sistemas y enfatizar las fases de anilisis y disefio, a la vez que se reduce notablemente el tiempo uti- lizado en ei resto de fases (ver figura 1). Los prototipos rapidos ¢ itera- tivos reemplazan a los métodos manuales de definicién de requer ‘mieentos facilitando la determinacién de las necesidades de los usuarios y sirviendo como especificacién «viva» del sistema, siempre actualiza- a, lo que elimina la necesidad de largos documentos de especificacio- nes basados en Ia narrativa. A continuacién vamos a aportar tna clasificacién de las herramiet tas CASE que permita caracterizar a las distintas herramientas existen- tes en el mercado, Ciclo devia rate Cie de vida a PEP, citode vit Seeediede - socndo rence iit de & amines Cask ee ee ee FIGURA1 Distribucién del esfuerzo en las distintas fases segtin el ciclo de vida 2. CLASIFICACION Y COMPONENTES DE LAS HERRAMIENTAS CASE Las herramientas CASE se enfocan hacia el soporte de diferentes fases del ciclo de vida del software o al desarrollo de diferentes tipos de sistemas. La disparidad de herramientas que se engloban dentro del concepto CASE hace necesaria una clasificacién que nos permita po- der realizar una comparacién de las distintas herramientas existentes en el mercado, Atendiendo a la clasificacién propuesta por Carma McClure [MCC89a] se pueden determinar tres categorias de herra- mientas 197,198 © Juego de herramientas (Toolkit): conjunto de herramientas izan un tipo de tarea del ciclo de vida del software. Constituyen el tipo mas simple de herramientas. ‘© Banco de trabajo (Workbench): entorno de propésito general {que soporta la fofalidad de las tareas del ciclo de vida del software. En este tipo las herramientas se integran de forma que In salida de una fase del ciclo de vida pasa directa y automética- mente a la siguiente. © Compafiero de metodologfa (Methodology Companion): es un tipo de herramientas CASE toolkit o CASE workbench, que estructura el proceso de desarrollo del software de acuerdo con los pasos y reglas de una determinada metodologia. Fstc tipo de herramientas, por ejemplo, informan al desarrollador, me~ diante mens o pantallas de ayuda del préximo paso a realizar, segtin la metodologfa soportada, y no le permiten pasar a él hias- ta que se compruebe que la tarea actual se ha completado total- mente, TABLA 1. Caracteristicas bésicas de una herramienta CASE. Permiten a tos usuarios dibujar diagramas para la planiieacién isco en i pantalla de un ordenador + | Soticitan intormacién acerea de cada uno de los abjetos de un diageama y de las itertclaciones entre dichos objtos. ‘= [Atmaconan el signticado det diagrama, en ver del diagrama en sf mismo, dentro de un depesito de informacién (repository). ‘+ |Comprueban a exacttu, integridad y completitud de ead diagrama. Los diggramas que se ofrezcan deben ser elegidos con el chjeto de faciitar esta labor. Como hemos dicho los juegos de herramientas CASE de tipo tool- kits se caracterizan por la realizacién de algunas tareas espectficas dentro del desarrollo det software. Sin embargo, aunque se obtienen beneficios utilizando herramientas aisladas (toolkits) que realicen de~ terminadas labores dentro del desarrollo de sistemas software, la po- tencia real del CASE sélo puede conseguirse a través de la utilizacién de las herramientas dentro de un entomo integrado y enmarcado dentro de una metodologia de desarrollo, es decir, mediante una herramienta CASE Workbench de tipo Methodology Companion, a lo que més uusualmente se le llama Integrated-CASE (I-CASF). Por tanto Ja caracteristica esencial de las I-CASE no es otra que la integracién, a través de una enciclopedia comin, de las distintas herra-mientas, facilitando, de este modo, que el generador de cédigo se nutra de la informacién obtenida por las herramientas de disefio, 0 que se pueda compartir la informacién de la enciclopedia por diferentes pro- yectos realizados en paralelo. Entre otras cosas estas caracteristicas permiten que se consiga una alta productividad, mayor que en aquellas herramientas que no estan acopladas. Una I-CASE, como ya hemos dicho anteriormente, no es una mera reunién de las mejores herramientas disponibles, sino que éstas deben abarcar todas las fases del ciclo de vida. Deben integrarse bajo la co- bertura de una interfaz de usuario homogénea y la informaci6n debe ser compartida en una enciclopedia comtin gestionada de forma orde- nada, segura y automatizada, La enciclopedia es el corazén del I-CASE, siendo la que facilita la integridad y consistencia. En ella se almacena, de una manera estructu- rada, toda la informacién conforme se va obteniendo en las distintas fases del ciclo de vida. Almacena el significado de los diagramas y comprueba Ia consistencia de cada representacién, eliminando infor- macién redundante y permitiendo la reutilizacién no solo del eédigo sino del andlisis 0 del disefio. Es una utilidad «viva» en la que el cono- cimiento que se almacena es vital para comprender y modificar los sis- temas de una organizacién, ya que cualquier modificacién hace que ésta se actualice automidticamente y que el cédigo sea generado a partir de dichas modificaciones. La etapa de generacién de cédigo tampoco se encuentra aislada en tun entomo I-CASE, Los aspectos de mantenimiento del cédigo gene- rado (gestién de versiones y modificaciones realizadas), librerias de componentes y criterios de reutilizacién, ingenieria inversa y reinge- nierfa de aplicaciones preexistentes, son aspectos de vital importancia cen este tipo de entomos, Pero las capacidades de las herramientas CASE van mis alld de una cenciclopedia o un generador de c6digo. Las verdaderas potencialidades de estas herramientas pueden verse claramente al estudiar los compo- nentes, 0 capacidades que pueden ofrecer a los desarrolladores y que, como veremos a continuacién, van desde las capacidades gréficas has- ta.el soporte del mantenimiento de los sistemas actualmente en explo- tacién Estas capacidades que proporcionan un soporte total al desarrollo del software pueden resumirse en las siguientes + Capacidades grificas para representar los modelos y diagramas. © Comprobacién de ertores integrado dentro de las herramientas, * Depésito de informacién 0 enciclopedia para almacenar y ges- tionar toda Ia informacidn del sistema de forma global200 © Conjunto altamente integrado de herramientas para asistir a to- das y cada una de las fases del ciclo de vida, dentro de un inter- faz. comin de cara al usuario, © Soporte de una metodologta. ‘© Generacin automética de cédigo desde las especificaciones de! disefio y soporte en la obtencién de prototipos. © Soporte de herramientas para el mantenimiento de sistemas anti- guos: reestrueturacién (restructuring), ingenierfa inversa (rever- se engineering), reingenieria (reengineering). ‘Aunque serfa aconsejable que la herramienta seleccionada contenga los componentes anteriores, la base y por tanto el corazén de la herra~ mienta serd Ia enciclopedia. Las caracteristicas de ésta serdn las que condicionardn las posibilidades de Ia herramienta y, por tanto, es el componente que con mayor cuidado se debe estudiar en la seleccién de tuna herramienta dada, 3. CONSIDERACIONES SOBRE LA ELECCION E, IMPLANTACION DE UNA HERRAMIENTA. CASE Antes de abordar de manera detallada el andlisis de la eleccién e implantacién de una herramienta CASE cabe preguntarse por la madu- rez de esta nueva tecnologia y repasar algunos de los posicionamientos ‘mas comunes ante cualquier nueva tecnologia. El problema de las nuevas tecnologias ex que la gente esté o muy entusiasmada, y por tanto puede esperar beneficios inalcanzables, 0 de- masiado pesimista y por tanto obstruccionista en su adopcién. Hay que tener en cuenta que ambas posturas son ciertamente peligrosas y deben tenerse presentes a la hora de pensar en introducir dentro de una orga~ nizacién una nueva tecnologia, en este caso una herramienta CASE. ‘A la hora de introducir una nueva tecnologia en una organiza- cién se suelen dar tres modos e instantes de adoptarla ((MAR89J, pp. 170-171) © Los pioneros asumen el gran coste inicial de Ia investigacién con el objetivo de obtener una ventaja significativa sobre la competencia. Este coste inicial y sobre todo la incertidumbre de Jos resultados a obtener hace que sean pocos los que se sumen al tren de la tecnologia en sus primeras etapas. En cualquier caso, aunque cl riesgo es alto hay que tener en cuenta que si el resulta- do es satisfactorio los beneficios pueden ser igualmente altos. © La segunda ola sc refiere a las corporaciones que introducen cesta nueva tecnologia cuando los pioneros empiezan a obtener resultados satisfactorios. En ese momento ya hay alguna basemas 0 menos sélida que aprender y sobre la que trabajar. En este caso los costes y los riesgos se han reducido y sin embargo los bengficios siguen siendo altos, ya que el numero de compaiiias que*se incorporan en esta situacién es escaso (alrededor de! 20%) y por tanto se pueden conseguir considerables ventajas so- bre aquellas empresas de la competencia més rezagadas. © Por tiltimo, los rezagados piensan en términos de la tecnologia actual y no ven claro los beneficios que podrfan obtener al aban- donarla por una nueva que para ellos, aunque sea por desconoci- miento, todavia no es muy segura. En este caso este grupo de or- ganizaciones corren el riesgo de quedarse obsoletas en un mundo tan cambiante. Su incorporacién a ta nueva tecnologia, se realiza generalmente de forma precipitada y desordenada, obligadas por la propia competencia, obteniendo beneficios sen- siblemente menores, al haberse quedado rezagadas respecto a las que se incorporaron con anterioridad, Existen muchos estudios sobre la oportunidad y beneficios obteni- dos con la implantacién de una herramienta CASE dentro del proceso de desarrollo de sistemas, pero estos estudios no son todos halagtiefios y la experiencia nos demuestra que las herramientas CASE no son por Si solas las «balas de plata» que desesperadamente buscan algunos di- rectivos, Por tanto, podrfamos preguntarnos zqué ha sucedido a la hora de adoptar una determinada herramienta CASE dentro de una organi- zaci6n? Tal vez como propone Patrick Loy [LOY93}, la principal ceusa de algunos fracasos ha sido que las expectativas eran poco realistas, ya que se buscaba la barita magica que sin ningtin esfuerzo ni compromi- so solucionara todos los problemas, y ademas los productos no estaban preparados para ofrecer lo que los vendedores decfan que hacian, Esta idea general puede resumirse en tres aspectos criticos del pro- bblema de las herramientas CASE [LOY93] = Hay un sentimiento generatizado de que las méiquinas son més fiables que el ser humano y que pueden sustituirlo en ciertas funciones. Este sentimiento puede hacer que los directores de Jas empresas sean presa fécil de algunos vendedores que prome- ten la luna, Pero hay que ser conscientes de que tanto los métodos como las herramientas son de gran ayuda para los ingenieros del software, pero no dejan de ser una ayuda, no pudiendo considerarse como sustitutos de la mente de Ios desarrolladores. = Hay una tendencia a pensar que las herramientas reemplazan a los métodos, en vez de, que les sirven a ellos. Esto leva a mu- chas organizaciones a pensar que el entrenamiento y soporte 201202 aportado por el vendedor es lo tinico necesario, lo cual general- ‘mente sucle ser un desastre, ya que deberfa pensarse que el mé- todo debe «dirigir» a la herramienta y no a la inversa. — Las herramientas no soportan todavia de forma adecuada los métodos para los que dicen estar creadas. ‘A estos tres problemas sc puede afiadir que muchas organizaciones han adoptado, o al menos comprado, una herramienta CASE motiva- dos por una mada y no han tenido en cuenta Ja complejidad de los pro- blemas del desarrollo del software, lo cual era casi asegurarse el fraca- $0. ‘Aun existiendo estos problemas, algunos de los cuales son debidos una mala comprension de lo que suponen realmente las herramientas CASE, éstas son una importante ayuda, pero no la solucién total y por tanto Ta panacea, en el proceso de desarrollo, Por tanto, podemos con- siderar que en Ia actualidad nos encontramos ante Ia «ventana de la oportunidad. Esto significa que el que sea capaz de ineorporarse de forma ordenada y meditada a esta nueva tecnologta podré sacar ventaja a la competencia y evitari los riesgos de incorporarse motivado por tuna imposicién del mercado que le obligue a hacerlo de forma ripida y tal vez incontrolada, con el riesgo adicional que esto implica. Al igual que sucede con la adopeién de una metodologia de desa- rrollo, hace falta un estudio muy serio antes de decidirse por una herra- mienta CASE en conereto, Hay que ser consciente de qué es lo que esti fallando y de cules son las necesidades reales y las caracteristicas particulares de cada organizacién, algo que en la mayorfa de los casos no se plantea nunca de forma seria, Pero esta decisiGn no resulta sim- ple, pues lleva consigo un importante compromiso, y no debe dejarse llevar por posibles modas o tendencias, que mal asimiladas no son sino tun estorbo mas a la hora de solucionar los problemas del desarrollo de sistemas software, 0 por desconfianzas a ultranza de aquellos que se han sentido engafiados anteriormente con otra supuesta panacea. Entonces cabe preguntarse {qué hacer para tomar una decisién 10 mis acertada posible? En este sentido, una estrategia que puede ayu- darnos a tomar una decisién sensata acerca del empleo de la tecnologia CASE en un tiempo razonable es: © Estudiar y determinar cudles son los problemas reales, las nece~ sidades y las caracterfsticas peculiares de la organizacién. ‘© Buscar y seleccionar un conjunto de soluciones que satisfagan, aunque s6lo sea en parte, dichos problemas, necesidades y ca- racteristicas. ‘© Establecer y aplicar un plan de implantacin que controle y ase~ gure la correcta adopcién de dichas soluciones tecnol6gicas.En los siguientes apartados vamos a desarrollar brevemente las ca racteristicas principales de cada una de estas etapas. 3.1, Estudio y determinacién de necesidades La mayorfa de tas organizaciones se encuentran ante una situacién de escepticismo sobre Ia existencia de soluciones migicas, pero a la ‘vez esperanzadas en encontrar una realmente magica, La causa de esta situacién de escepticismo es la gran inversidn rea- lizada por algunas de ellas y los escasos rendimientos, respecto alo es- perado, de dichas inversions. A la vez tienen necesidad de soluciones ‘magicas ya que la répida evolucién de Ia sociedad, y por tanto de los negocios, les esté enterrando entre tun montén de solicitudes de nuevos y mas complejos sistemas, de mayor calidad, y més baratos. Mientras tanto los centros de desarrollo tienen que hacer frente a las tarsas de ‘mantenimiento de los sistemas existentes, tareas que consumen la ma- yor parte de los recursos. Ante esta situacién seguir esperando la solucién magica puede ser tun grave error que s6lo puede conducir a que los problemas y los gas- tos aumenten. Por tanto, aunque es dificil de conseguir, pues el tiempo es un recurso escaso y muy valioso, toda organizacién que se encuen- tre en esta situacién deberia emplear algiin tiempo en recapacitar y de- ferminar qué va bien y qué va mal dentro del desarrollo de sistemas software. Este no es un tiempo perdido, sino que deberfa ser una pric~ tica comin para conseguir mejorar y actualizar el proceso de desarro- Mo de sistemas software dentro de una organizaci6n, AAI igual que en otras éreas de una organizaci6n, dentro del desarro- Io del software cada corporacisn sure su propia y personal forma de crisis del software (no hay una soluci6n universal). Podemos asimilar el problema a lo que sucede en el drea de perso- nal 0 contabilidad de una empresa a ta hora de introducir una nueva tecnologfa, en este caso la mecanizacién de los distintos proceses aso- cciados a cada una de dichas reas. Nos encontramos, por tanto, ante la necesidad de mecanizar un conjunto de tareas y para dar soluzién a esta mecanizacién existen en el mercado un conjunto de soluciones que en distinta medida podrén cubrir las necesidades de cada area, cla- ro esti que antes debemos saber cules son estas necesidades. ,Qué es Jo que un conceptor de sistemas software harfa? Pues esti claro que el responsable de este estudio intentarfa, junto con los responsables del ‘rea a estudiar, determinar cudles son’ ios grandes objetivos de ‘a em- presa y dentro de éstos cules son las necesidades y peculiaridades de su nomina, contabilidad, etc, para, en funcién de dichas earacteristicas, poder seleccionar, dentro de la oferta del mercado, una herramienta que cumpla dichas necesidades con un costo razonable. 203AL igual que pedirfamos a los responsables del érea de personal, que describieran con la mayor precisién posible sus necesidades, del ‘mismo modo debemos pedir a los responsables del drea de desarrollo de sistemas software que detallen sus necesidades, ya que decir sim- plemente que se necesita aumentar la calidad y Ja productividad no es tuna forma adecuada para determinar cual puede ser Ia solucién ideal ero aqui tal vez. nos encontramos con un problema afiadido, ya que puede no existir dentro de la organizacién un modo esténdar de atacar las tareas de desarrollo de sistemas. Eso es lo mismo que pensar que dentro de una empresa cada empleado del area de personal tuviera una forma propia de obtener Ia némina de los empleados. En este punto {icémo determinar las necesidades? Si nos encontramos ante una situa- ccién tan caética como la descrita anteriormente, situacién més frecuen- te de lo que puede parecer, cabria pensar que antes de embarcarse en la adopcién de una herramienta CASE habria que pensar en normalizar y estandarizar el proceso de desarrollo, bien implantando una metodolo- gia estandar, o bien creando nuestra propia metodologia. Por tanto en este caso estarfamos ante una pregunta previa que debemos resolver antes de seguir adelante {qué metodologia, 0 tal vez metodologtas, de desarrollo se debe utilizar de forma estandar en nuestra organizaciGn? Suponiendo que hemos superado esa primera cuestién, es decir, existe una forma estindar de entender el desarrollo de sistemas, nos encontramos en el mismo punto que estén los responsables del drea de personal que pretenden introducir dentrs de su entorno de trabajo una nueva tecnologia. ‘Se deben estudiar tanto las necesidades de tipo organizativo como técnico, para de este modo tener una comprensién mayor del problema y poder adoptar una solucién mas coherente y adecuada, Para determi- nar dichas necesidades podemos efectuar un conjunto de preguntas fucrtemente interrelacionadas, entre las que podemos destacar: © {Cudl es el método estandar de trabajo?, zeste método se utiliza siempre en todos los desarrollos de sistemas software?, gexisten controles que aseguren la correcta tilizacién de dicho método? ‘© {Qué problemas encuentran los desarrolladores en la aplicacién del método? © {Cuiles son las quejas mas frecuentes de los usuarios respecto a fos sistemas desarrollados? ‘© {Qué sistemas funcionan correctamente y cuales son las caracte- risticas (en cuanto a desarrollo, organizacién, mantenimiento, etc) que pueden diferenciarlos de aquellos que no funcionan como se desea? © jExisten formas de medir la productividad de los sistemas desa- rrollados?, si es asf ,eusll es su productividad?© {Qué estindares y procedimientos técnicos existen para garanti zar la calidad del software? ‘* ,Cudl es la formacién y predisposicién del personal de desarro- Tio ante la inclusién de nuevas tecnologias (cambios)? * {Qué herramientas de desarrollo y mantenimicnto del software, incluyendo los lenguajes de programacién, se estan utilizando?, {oul es la satisfaccién en cuanto a su funcionamiento?, {se pre~ tende que continiien siendo utilizadas 0 pueden ser sustituidas? * Cudl es la estructura organizacional de los desarrollos softwa- re?, ces centralizada, descentralizada 0 mixta (centraliza los de~ sarrollos corporativos y descentraliza desarrollo puntuates de un rea o departamento)? ‘© {Cudl es Ia predisposicién de la organizacién a in tanto a invertir en nuevas tecnologias? roducir y por Estas y otras preguntas deberfan hacerse los responsables de los de- partamentos de desarrollo de sistemas software antes de decidir si adoptar 0 no una herramienta CASE y en su caso cuales son sus reque- rimientos. 3.2. Basqueda y seleccién de una herramienta CASE Una vez que se conocen las necesidades y caracteristicas propias del departamento de desarrollo y se ha decidido adoptar una herra- micnta CASE, el siguiente paso es buscar dentro del mercado cudles son las candidatas que mejor se ajustan a nuestras necesidades, En este punto es necesario resaltar que la caracteristica que mis nos va a condicionar a la hora de seleccionar una herramienta y que por tanto va a restringir el dmbito de baisqueda, es la metodologia que se haya adoptado como esténdar dentro del desarrollo de sistemas. Esto ces esencial pues generalmente una herramienta CASE est4 pensada para dar soporte a un conjunto de técnicas propias de una metodologia € incluso puede incluir dentro de sus caracteristicas la de servir de ayu- da en la aplicacién de una determinada metodologfa (methodology companion), Otra caracteristica casi general es ta dificultad de encontrar una he- rramienta que se adapte completamente a nuestras necesidades, atin en el caso de que la metodologfa de desarrollo aplicada dentro de la orga- nizacién sea una estdndar. En este sentido hay que tener en cuenta cud- les son las restricciones que el uso de Ia herramienta supondri en Ja aplicacién completa de la metodologta. A Ia vez que consideramos los puntos anteriores deben tenerse en cuenta otras caracteristicas comunes a Ia seleccién de cualquier herra- ‘mienta mecanizada en cualquier entorno, como por ejemplo: si es facil 205206 de usar y aprender, cual es el soporte técnico y de aprendizaje que se ofiece, e6mo se adapta a las necesidades planteadas, si contempla al ‘menos las consideradas minimas, cual es el ratio coste/beneficio, etc. Una vez que se han tenido en cuenta estas u otras cuestiones los responsables pueden determinar cul es la herramienta que més se adapta a su organizacién. 3.3. Establecimiento y aplicacién de un plan de implantacién Una vez elegida una determinada herramienta no esti todo hecho, sino que es ahora cuando debe tenerse mas cuidado para asegurar el correcto funcionamiento e integracidn de la herramienta dentro de la organizacién. Para ello hay que establecer un plan que controle y ga- rantice una correcta implantacién. Este plan debe establecer un conjun- to de fases que faciliten la incorporacién paulatina de este elemento ex- traito dentro de la organizacién. Como una implantacién global, a todo el personal, es algo muy di- ficil de conseguir, lo primero que deberemos hacer es seleccionar un grupo de personas que constituird el embrién desde donde se extenderé esta nueva tecnologfa al resto de la organizacién, La correcta seleccién del personal que constituir4 este grupo es algo importante pues de ellos. dependerd en gran medida el éxito de la implantacién de la herramien- ta, Debemos seleccionar a personas que conozcan bastante bien la me- todologfa de trabajo y tengan una predisposicién favorable a Ia incor- poracién de este tipo de herramientas de ayuda, Una vez seleccionado el grupo de personas que constituiran la avanzadilla de la implantaci6n lo siguiente a tener en cuenta es su for- macién, para lo cual seri necesario planificar un conjunto de cursos de aprendizaje que les permitan familiarizarse con la herramienta, ‘Tras esta primera toma de contacto con la herramienta es interesan- te que este grupo de personas Ileven a cabo el desarrollo de un proyec- to piloto, liste debe ser un proyecto real, no critico, clegido con el ob- jetivo de probar la herramienta, o las herramientas si se han seleccio- nado mas de una, y por tanto de un tamaiio apropiado para conseguir en un tiempo minimo una opinién sobre cémo se puede adaptar una herramienta a las necesidades de la organizacién. Una vez. terminado el o los proyectos pilotos los resultados de estos servirén para: © Sugerir cuél es la herramienta, en el caso de haber seleccionado ‘més de una, que mas se adapta y c6mo a nuestras necesidades. © Convencer a la direccién y al personal de desarrollo mas reacio a su implantacién, de las bondades y beneficios que pueden de- rivarse de su adopeién,Si tras la presentacién de los resultados obtenidos, la decisién de la direccién es continuar con su implantacién deberfan realizarse un con- junto de acciones que asegurasen su correcta expansiGn e integracio © Definir un conjunto de procedimientos estindar que puedan uti- lizarse para la aplicacién de esta nueva tecnologia. ‘© Proponer un plan de formacién y de nuevos proyectos a abordar que garantice la implantacién general de la herramienta selec~ cionada dentro de la organizaciGn. Dentro de esta etapa de expansiGn y consolidacién de la hercamien- ta sigue jugando un papel esencial el grupo inicial de implantacién, ya que éste deberd integrarse en los nuevos proyectos y ser el soporte ba~ sico a las consultas y posibles problemas que surjan en el desarrollo de estos nuevos proyectos, AAI mismo tiempo este plan debera incorporar un conjunto de con- troles y revisiones que garanticen la correcta utilizacién de las herra- mientas y metodologfas dentro del entorno de desarrollo y que detec~ ten posibles deficiencias que surjan durante su aplicacién y, pcr tanto, puedan servir para la continua y necesaria actualizacién y mejora del proceso de desarrollo, 4, CONCLUSIONES Como hemos visto, las herramientas CASE como toda nueva tecno- logia crea ciertas actitudes que pueden dificultar su correcta difusién. En cualquier caso, aunque la madurez de esta tecnologia es suficiente para pensar en su introduccién dentro del proceso de desarrollo, no de- bemos olvidar que para garantizar su éxito no podemos introducirla de tun modo desordenado, sino que su incorporacién debe ir acompaiiada de una estrategia de seleccién ¢ implantacién correcta, Este proceso de seleccién ¢ implantacién de una herramient CASE no difiere en gran medida del proceso seguido para elegir y poner en funcionamiento otro paquete software cualquiera. Tal vez. Ia diferencia estriba en la naturaleza y complejidad de la herramienta y en las difi- ccultades derivadas de la homogeneizacién del trabajo en el érea de de~ sarrollo de software. En todo caso, esa dificultad no debe ser un obsti- culo, ya que Ia introduccién de este tipo de herramientas no solo ofre- cen la posibiliad de automatizar el proceso de desarrollo, sino que también nos ofrecen la posibilidad de estudiar detenidamente dicho pproceso dentro de nuestra organizacién. Este estudio profundo del pro- cceso de desarrollo sirve realmente para conseguir una estandarizacién del mismo y la climinacién de algunos de los problemas que més fre- ‘cuentemente aparecen en la mayoria de los desarrollos. De este modo a las ventajas asociadas a la automatizacién se pueden incorporar las de- 207la rivadas de la realizacién de un estudio profundo del propio método de desarrollo, BIBLIOGRAFIA [BRO7S] BROOKS, Fs The Mythical Man-Month. Addison-Wesley, 1975. [GAN90] Gave, C.: Computer-Aided Software Engineering. The methodologies, the pproducs, and the fare. Prentice-Hall Internationa, 1990. [G1B89] GwsoN, M. L.: «La filosofia CASE». Binary, n° 10, pp. 82-88 [LOY93) Loy, P. «The Methos Won't Save You (but it can help)». ACM SIGSOFT, ‘ol, 18, n° 1, Jan 1993, pp. 30-34 IMARS9] Martin, 52 Information Engineering. Book I Iuroduction. Englewood ‘Cliffs, Prentice-Hall, 1989, [MARSO] Marin, J: Information Engineering. Book Ill Design & Consiraction. Englewood Cliffs, Prentice-Hall, 1990. IMCC8Da] Mectune, C.: CASE is Software Automation. Englewood Cliffs, Prentice Hall, 1989, [MCC89b] Mectune, C.: La experiencia CASE, Binary, 1" 10, pp. 103-111 [PRE93] PRESSMAN, R.:Ingenier(a del Software, Un enfoque préctico, McGraw-Hill, Madkid, 1993 ISAL88} SALINAS, AssComo legit e implantar herramientas CASE de automatiza ‘cin del softwareo, Computerworld, 26, Febrero, 1988, pp. 21-23, [SLA93] StavKovA, O,, GRaNE, J: «To CASE, or not 0 CASE?», Novation, x" 108, Sept/Oct, 1993, pp. 3-9. [SULD1] SuttivaN-TRamon, MLL: «Buyers’ Scorecard, TT's IEP scores high for in tegration, benefits delivery». Computerward, April 22,1991, pp. 72-74