¿Qué es una especificación de requerimientos? Pues, en esencia, el conjunto de descriptores (usualmente documentados) que recoge de forma expresa las necesidades de un cliente, entendido éste en su sentido más amplio, para resolver problemas concretos insertos en un ámbito bien definido. Equivale, de hecho, en nuestro ámbito, al conjunto de requerimientos que originan la necesidad de una solución software, y estos no debieran ser distintos de los que conducen, por ejemplo, a la compra de un determinado electrodo­méstico. Pero examinemos este ejemplo más de cerca.

“Necesito un televisor color stereo de 26" con sistema dual PAL-SECAM, euroconector, mando a distancia, teletexto y controles de monitorización gráfica”

Esto suena bien, pero, ¿es una especificación de requerimientos? ¡NO, no, no! Más bien se trata de la solución a los posibles requerimientos personales del comprador, que podrían ser expresados de esta otra forma (y perdone el lector lo ridículo de esta situación, pero los ejemplos suelen ser como los consejos: de mala catadura):

“Necesito un sistema televisivo que me permita recibir las emisiones audiovisuales de todas las cadenas españolas, así como de algunas norteamericanas, con posibilidades de recibir información textual como el teletexto, de interconectabilidad con otros equipos como videos, y de fácil manejo a distancia”

Naturalmente aquí cabría añadir condicionantes temporales de todo tipo: "Para cumplir estos requerimientos dispongo de un presupuesto de 200.000,-pta. y además quiero que la marca del televisor empiece por SA, y quiero que las instrucciones vengan en sánscrito, y quiero...", pero que en absoluto cambian la naturaleza de los requerimientos expresados. Se aprecia también, en este estúpido ejemplo, que requerimiento no equivale a necesidad, pues ésta es anterior a aquél. O sea, se aplica el siguiente y elemental esquema secuencial (a veces no tan secuencial):

• Evaluación de necesidades.
• Establecimiento de requerimientos para satisfacer tales necesi­dades.
• Determinación del rango de soluciones que cumplen las especificacio­nes dadas.
• Aplicación de condicionantes al conjunto de posibles solucio­nes y elección de solución.

Oh, bueno, esto parece esencialmente correcto, pero ¿no se están obviando importantes circunstancias de entorno? Esto es, siguiendo el ejemplo, ¿no habría que inquirir sobre el contexto en que se insertará el aparato y las condiciones de interacción de éste en el mismo?

“Deseo un televisor para la habitación de mi padre, que está medio ciego y casi sordo y necesita dosis audiovisuales a altos niveles. Además debe resultar duro y barato, porque las piernas le fallan a menudo y golpea todos los muebles con la cabeza (ahora que lo pienso, quizás esté sordo y ciego precisamente por esto)”

Parece que de esta manera, al describir los “roles” del sistema (en este caso una simple interacción hombre-máquina), los condicionantes se muestran claros, formando un todo con los requerimientos. De hecho suele ser así como deberían abordarse las compras de electrodomésticos. Pero, vaya, esto plantea nuevas y difusas fronteras, incluso para los grandes almacenes.

INCOMPLETITUD DE LAS ESPECIFICACIONES

Hay que notar que, en principio, no importa si los requerimientos constituyen una realidad objetiva exterior al cliente o si más bien forman parte, por la propia capacidad de éste relacionada con el problema a analizar, de su propia estructura mental, pues lo que en definitiva transmite el cliente al analista es una imagen, frecuen­temente deformada por condicionamientos propios, de tal realidad, siendo lo que percibe efectivamente el analista otra imagen, matizada y quizás afortunada­mente distinta, de tales requerimientos. Bien, esta larguísima frase viene a querer expresar, en definitiva, lo que Nietzsche en su aforismo "El filósofo preso de las redes del lenguaje". Por naturaleza, la comuni­cación viene determinada por la intersección semántica de sistemas simbólicos formales entre los comunicantes, así que ... bueno, quizás me esté apartando de ese enfoque pragmático con que se pretendía dotar al presente texto. Bien: bajemos al planeta Tierra. La cuestión es que cuando una entidad multiconceptual se comunica a otros, ésta se convierte en una entidad distinta (y recuerden aquello de "traduttore tradittore", luego denostado por Jacobson). Todo esto, aplicado a la comunica­ción entre cliente y analista, nos lleva a la siguiente trivial conclu­sión: ¡Este asunto no es nada fácil, diantre!

De alguna manera tenemos que extraer del cliente la mayor cantidad posible de información relevante al problema a resolver. Y fíjese bien el lector que, según lo declarado, las sesiones de análisis tendrán dos cometidos básicos: extraer mucha información y que ésta sea esencial al problema. El abuso, por separado, de esta funcionalidad puede llevar bien al inútil sobreexceso de descriptores, bien a una interpretación conceptual demasiado alejada de la realidad del problema. Pero aun suponiendo la exacta aplicación de las técnicas apropiadas a lo que en Tecnología de Objetos se ha dado en llamar OORA (Object-Oriented Requirements Analysis), el resultado a documentar por el analista -esto es, las especificaciones- será matizadamente distinto del conjunto de requeri­mientos previsto por el cliente, de manera que las especificaciones observarán, en todos los casos, una característica básica de incompleti­tud, que nos llevará, como veremos, a un ciclo de refinamiento involutivo posterior similar al representado por los conocidos modelos de fuente, espiral o piscina en las fases de Análisis y Diseño Orienta­dos­-a-Objetos. Lo más fascinante de todo es que el cliente en absoluto busca la comunalidad, la abstracción o la reutilización: simplemente la satisfacción de una necesidad inserta en un contexto concreto, y que observará, por tanto, un comportamiento mayormente arbitrario. Es propio de la condición humana, por otro lado, el cambio inopinado y la carencia de previsión, por lo que es prácticamente imposible satisfacer a la vez todos los posibles roles que la solución provista pueda adoptar. He aquí la llaga. El dedo correspondiente señala que la circunstancia de rol es precisamente la que define la incompletitud generalista del requerimiento y satisface, a la vez, su adecuación para con la necesidad que lo genera.

¿DÓNDE COMIENZA EL CÍRCULO?

¿Cuál es la tarea primera del analista? Secuencialmente hablando, debiera ser, como base de su posterior trabajo, el establecimiento tangible de las especificaciones que conforman los requerimientos del cliente. Esto es, el analista, mediante una interrogación adecuada al cliente, deberá establecer el material conceptual sobre el que operar des­pués. El resultado final de este proceso marcará, de forma ineludible, el desarrollo ulterior de software. Naturalmente aquí, como ya habrá supuesto el inteligente lector, la orientación-a­-objetos tiene mucho que decir. Pero antes examinemos la típica orientación estructurada, con un enfoque que podríamos denominar de "descomposición en tablas", o de "análisis tabular", y que normal­mente se basa, de una forma tendenciosa, en reconocer y definir las estructuras de datos (?!) que se esconden tras los requerimien­tos del cliente. Vayamos, pues, por partes.

TABULA RASA

Resultaría interesante -y aconsejable, si no estuviera perseguido policialmente- diseccionar la mente de un analista estructurado. Pero, bueno, actualmente nos habremos de conformar con observar a uno de ellos en una típica sesión de análisis de requerimientos. Se trata de someter las consideraciones del cliente a un especial filtrado que las tamiza segmentándolas, básicamente, en cuatro áreas bien definidas: pantallas de acceso y modificación de datos, listados de impresora, procesos secuenciales y estructura de las tablas para bases de datos relacionales sobre las que habría de bascular el sistema entero. De esta manera, y con cierta lógica perversa, tal tipo de analista no intenta compren­der la esencia del problema que se le plantea sino, más bien, resulta en actuar como una especie de curioso traductor mecánico: cada requerimiento del cliente se transforma, así, bien en una indicación directa de la composición de una o más tablas susceptibles de ser manejadas por un gestor de bases de datos relacionales, bien en una o más funciones de aplicación secuencial que habrán de manejar los datos encerrados en las tablas anteriores.

De lo que se trata en estas reuniones, que podríamos nominar como "relacionales", es de ajustar las especificaciones del problema a la especial estructuración -y a veces deformación profesional- del analista. Claro que esto normalmente funciona, pero imagino que si uno se entrenara durante años para encender cerillas con los dedos de los pies la cosa funcionaría igualmente. Esto es, que la persona es un animal acomodaticio y se acostumbra a todo. Lo cierto es que el desarrollo y estabilización del modelo relacional ha influido de forma esencial en la construcción de sistemas software durante los últimos quince años, pero ¿estamos en el buen camino? Bien, examinemos una típica reunión de este tipo de análisis (un poco deformada -y así me anticipo a la razonable queja del lector-, pero es que es así como mejor se aprecian sus peculiaridades). Les pongo en antecedentes: se trata de una primera reunión para la especifica­ción de requerimientos de una aplicación de gestión de muestras para un laboratorio de aguas:

Analista: De acuerdo, especifíqueme ahora qué proceso sigue para la confección de un análisis de aguas.

Cliente: Bueno, un análisis ...

Analista: Un momento, ¿qué campos tiene un análisis?

Cliente: ¿Cómo?

Analista: Quiero decir, ¿qué información aparece en un análisis de aguas?

Cliente: ¡Ah, ya! Bien, un análisis tiene una estructura, y ...

Analista: ¿Una estructura? ¿Qué es? ¿Un nombre?

Cliente: No, en realidad se trata del conjunto de medicio­nes que deben ser realizadas a ciertos analitos y ...

Analista: Un momento, un momento. O sea que tenemos una tabla de análisis y otra de estructuras. Y una clave principal podría ser el número de análisis, porque los análisis deberán llevar numeración, ¿no?

Cliente: Er ... sí. A cada muestra que se recibe se le asigna un número secuencial y ...

Analista: Bien, ya veo. Y este número, ¿de qué se compo­ne? ¿Es muy largo? ¿Sólo es un número o puede contener también caracteres alfanuméricos?

Cliente: Nosotros actualmente utilizamos el número del año en curso seguido por un numerador secuen­cial que ...

Analista: Ya, ya. Así que tenemos un campo para el núme­ro secuencial y el año ... bueno, el año lo podría­mos tomar de la fecha de realización del análisis, porque imagino que los análisis deberán contener la fecha de realización. Así que el campo "núme­ro" será la clave de tipo, digamos, entero, porque ¿pasan de 30.000 análisis al año?

Cliente: ¿Qué? ¡Ah, no! El año pasado realizamos unos 6.000 análisis, aunque ...

Analista: Bien, perfecto. Esto marcha.

.....................

Analista: Queda claro, entonces, que la secuencia es: primero la previsión de análisis, después el análi­sis pendiente y, por último, el análisis terminado, así que ...

Cliente: Bueno, no es realmente así, porque casi todos los días tenemos que realizar análisis que no estaban previstos y que nos traen los clientes de forma discreccional, de manera que ...

Analista: (sonriendo paternalmente) ¿Quiere decir que algún análisis puede terminarse sin haber estado previa­men­te pendiente de realizar? ¡Naturalmente que no! Los análisis sobrevenidos se introducirán como una previsión más, pero para la misma fecha, y luego se transformarán en análisis pen­dientes, y luego ...

Cliente: Pero es que hay veces ...

Analista: Nada, nada. El proceso secuencial está claro, lo que ocurre es que ustedes a veces, deformados por su propio trabajo, no reparan en estas cosas.

Cliente: ??? ...

Analista: Pero no perdamos el tiempo y sigamos con el proce­so de flujo de datos.

.....................

Analista: Ya tenemos definidas casi todas las tablas, así que, si le parece, podemos ver las pantallas.

Cliente: ¿Las pantallas? Bien, si usted ...

Analista: Claro, porque lo que se pretende es que la aplica­ción sea fácil de usar para los operadores. Veamos la de introducción de parámetros.

Cliente: ¿Parámetros?

Analista: Sí, ya sabe, es el nombre que le hemos dado a lo que ustedes llaman ...

Cliente: ¿Analitos?

Analista: Eso es. Aquí hay que introducir los campos de nombre (25 caracteres), abreviatura (5 caracteres) y unidades de medida (15 caracteres). Aunque, de todas maneras, las máscaras de entrada gestiona­rán la longitud de cada campo. Pongamos el nombre aquí y un campo de edición al lado, y debajo ...

.....................

Analista: Bien, repasemos las impresiones.

Cliente: ¿Quiere que le traiga ...

Analista: No, bueno. Examinemos la composición de la salida a impresora de los análisis. Tenemos en primer lugar la cabecera, que será común a todos los listados, y que se com­pon­drá del nombre de la empresa y la fecha y del tipo de listado. Los datos de la empresa los sacare­mos de la tabla de empre­sas y el resto, bueno, está claro. Realicemos un boceto y, ¡demo­nios! ¡no nos caben bien todos los campos! Podría­mos recortar algún campo, si le parece, aunque ... bueno, la verdad es que un análisis es como una factura y ...

Cliente: Un momento, un análisis no es una factura, porque de eso se encarga otro ...

Analista: Sí, sí, ya sé. Ustedes lo llaman análisis pero en realidad es un tipo de factura, y estas mediciones de las que usted me hablaba son, en el fondo, líneas de factura. Así que la impresión ...

Como se ve, el diálogo no tiene desperdicio. ¿Qué ha ocurrido aquí? El lector por fuerza habrá de reconocer cierta similitud entre esta situación y la que se generaría con un vendedor de coches usados. El analista (que aquí podría muy bien ser nominado "analistra", y que me perdone Alfred Jarry) maneja perfectamente la situación, de forma que las explicaciones del cliente sólo son asumidas cuando reflejan algún retazo del pequeño universo de éste. Naturalmente que el diálogo anterior no expresa literalmente la realidad, pero puedo asegurar que la refleja fielmente.

COMPRENSIÓN DE LA NATURALEZA DEL PROBLEMA

Pudiera parecer, desde un enfoque alarmantemente simplista, que cliente y analista pertenecen a dos mundos distintos, posiblemente en colisión, y que el entendimiento entre ambos depende de la elección de un adecuado y seguro territorio común, potenciando así un ánimo parecido al que originó en su día el esperanto. Semblaría, entonces, que los comunicantes habrían de perder parte de su acervo personal para que la comunicación alcanzara mayor densidad formal. Bien, esto resulta verdaderamente interesante, pero ... ¡vaya!, es exactamente contrario a nuestro enfoque expositivo, que establece un área común para los comunicantes: el dominio del problema. De esta manera, cliente y analista han de trabajar conjuntamente en las descripciones de los requeri­mientos que compondrán la especificación buscada, y es por esto que ambos hablarán el mismo lenguaje. Atención: ¡el mismo lenguaje!. Esto quiere decir que en las reuniones de OORA no deben normalmente aparecer vocablos como bases de datos relacionales, campos, registros, índices, etc., aun suponiendo que el mismo cliente sea un experto en ingeniería de software. Lo que se pretende, al fin, básicamente, es traspasar al analista una porción del conocimiento del cliente referido a un ámbito concreto, y fíjense que se trataría así de un flujo de informa­ción direccional con un único sentido: del cliente al analista. No nos interesa, pues, el bagaje informático que el analista pudiera aportar al cliente.

Si necesitáramos expresar sincréticamente (¡Maldición! ¡Un neologis­mo!) lo anterior, podríamos decir que el objeto cliente, en respuesta a mensajes excitadores o catalizadores del analista, le envía a éste mensajes volcando su conteni­do. Pero, ¿quiere esto decir que en ningún momento se va a hablar de componen­tes informáticos concretos? -podría preguntar el ya inquieto lector. No, no, no: la informática ha de hacerse notar, pero cuanto más tarde mejor [1].

¿TIENE ALGUNA VEZ EL CLIENTE LA RAZÓN?

Como en el diálogo de ejemplo, es frecuente encontrarnos en la vida real con situaciones en que el analista, arrastrado por una cierta mecanización profesional, interprete directamente y corrija de forma automática requerimientos del cliente, ajustándolos a sus propios esquemas. Pero es que así lo que se consigue es cambiar el sentido de flujo de la informa­ción, y esto es esencialmente erróneo, según vimos en el parágrafo anterior. De esta manera, por ejemplo, en el análisis de requerimientos de una estación de servicio de carburante, el cliente podría decir que ellos utilizan vales de servicio de carburante, y entonces el analist(r)a le corregiría diciendo: "Ya, ya. Vales. O sea, albaranes de servicio", presuntuosamente suponiendo que el conocimiento desarrollado en el análisis de innumerables aplicaciones le coloca en un plano más general que el cliente. Pero, ¿no es esto una verdad práctica? No tan deprisa. Veámoslo desarro­llando un poco el sencillo ejemplo expuesto.

Si asimilamos directamente que un "Vale" es conceptualmente igual a un albarán, según nuestra propia experiencia de análisis, es posible que tengamos que ampliar de una forma no natural el comportamiento habitual de los albaranes tal y como los entendía­mos. Así, verbigracia, a un "Vale" podría seguirle o no una factura, mientras que los albaranes necesitarían, acaso, ser siempre factura­dos. Esta situación nos llevaría a modificar la estructura de los albaranes (¿añadiendo quizás un nuevo campo del tipo "Facturar s/n"?), creando al final una macro-composición de difícil cualifica­ción. Pero, bueno -exclamará el lector-, ¿no es este tipo de reutiliza­ción el que se pretende imbuir con la Orientación-a-Objetos? No exactamente, pues un OOSS sostiene según Meyer [2], entre otros, el principio abierto-cerra­do­, que establece, prácticamente, que la modificación de los módulos (objetos) será realizada en otros nuevos provenientes de aquellos mediante herencia. ¡Ya está, pues! -repetirá el inteligente lector-: derivamos nuestra clase "Vale" de la anterior clase "Albarán" y ... ¡todo arreglado! Bravo, amigo lector: esta podría ser la solución, pero la cuestión es que nuestro analist(r)a la ha tomado a destiempo. Me explico: es posible, efectiva­mente, que "Vale" derive de "Albarán" mediante herencia (significando que un "Vale" es-un "Alba­rán"), o también que, sin que se dé tal relación de herencia, pueda ser aprovecha­do el módulo "Albarán" para la construcción del "Vale" usando, por ejemplo, de layering, pero esto no lo podemos determinar hasta que las especificaciones de requerimien­tos para tal módulo "Vale" estén completas. O sea, primero hay que determinar cuáles son las necesidades y luego, en las etapas de OOA y OOD buscar si disponemos de módulos (objetos) que puedan reutilizarse para satisfacer éstas.

De acuerdo con lo expuesto, un analista procurará no reutilizar módulos ni conceptos en la fase de OORA. Incluso si "Vale", según la descrip­ción del cliente, es exactamente idéntico a un módulo ya disponible pero con otro nombre, pues tal temprana asunción constreñiría de forma no despreciable las posteriores etapas de OOA y OOD, y aun la implemen­tación final. Bueno, esto puede parecer trivial, pero el corolario es que el analista de OORA debe "simple­mente" analizar el problema, y no procurar al cliente una suerte de servicio de consultoría de organiza­ción de empresas. Al menos, no debiera proporcionar ambos servicios de forma indivisible: es posible asesorar al cliente, como analistas del dominio del problema en que éste se ve inmerso, en la generaliza­ción de aspectos concretos del mismo, pero la asunción de estas indicaciones por parte del cliente conllevará, ineludiblemente, el cambio de las especifica­ciones de requerimientos, por lo que tendríamos entonces que volver a empezar.

LA FALACIA DE LA SECUENCIA MAESTRA

A fuerza de reparar siempre en el mismo error, uno puede llegar a convencerse que está en lo cierto. Es práctica común, así, inquirir al cliente, como en nuestro ejemplo, por una cierta secuencia de procesos y, de aqui, intentar reconocer o inferir una línea maestra, con una secuencia principal y varias bifurcaciones, sobre la que apoyar el análisis completo. Pero lo cierto es que la situación real suele ser más grave: al analist(r)a no le suele importar el carácter dinámico del sistema a estudiar, sino que desaforadamente intenta establecer una estructura secuencial rígida sobre la que "colgar" pantallas, listados y cambios estructurales. Por supuesto que, una vez establecida tal secuencia maestra, nuestro analist(r)a se agarra a ella como a una viuda rica, y cada vez que el cliente lo llama para introducir alguna modificación es como si le clavaran un puñal en el occipital. El invariable desarrollo de estas pequeñas historias de cambio en la secuencia maestra pasa por las siguientes fases, directamente relacionadas con el estado mental del analist(r)a:

• Optimismo : "De acuerdo, sin problemas: añadiremos un campo nuevo a la tabla, que nos dirá si va a ser procesada de la antigua forma o de la nueva, y cambiaremos una pantalla para que se pueda modificar este campo, porque en impresión no hace falta ¿ver­dad?"
• Aviso : "Bien, añadiremos un menú para que puedan elegir en cada caso el tipo de tarea a realizar, pero tengan en cuenta que, al proceder ustedes de esa forma no-ortodoxa, esto exige un esfuerzo de programación adicional que ... así que es posible que los costes ... pero, en fin, ustedes mandan."
• Reticencia : "Bueno, lo cierto es que para hacer lo que ustedes quieren prácticamente debemos desarrollar una aplicación paralela, que naturalmente les resolvería el problema, pero debemos indicarles que desaconsejamos esta mixtificación, pues ..."
• Resignación : "No, no, es imposible. Claro, esto debían haberlo planteado en el análisis, porque ahora ... así que les sugeriría que empecemos un subproyecto separado, con un nuevo análisis parcial, natural­mente a su cargo, porque ... ¿cómo que no quieren pagar más? ..."
• Rabia : "Por supuesto que no funciona como estaba previsto, debido, como saben, a los absurdos cambios que nos han hecho implemen­tar y ... ¿que somos qué? Sepan que nunca, como profesionales, ..."
• Caos : "¿Así que los items en estado pendiente que no van a ser facturados se mezclan con los de la aplicación de facturaciones pendientes, mientras que los pendientes a facturar pero que no generarán albarán desaparecen misteriosamente? ... ¿Y cómo quiere que lo sepamos? ... ¡Eso no me lo dice en la calle!"

En el mejor de los casos, se produce la siguiente última fase, de fuerte compo­nente negocial:

• Reconducción : "Hemos estudiado con detenimiento las modifica­ciones realizadas al análisis inicial, habiendo determinado que todas ellas se podrían engarzar en un único diseño, con una línea de proceso más flexible que les permitiría introducir cambios con más facilidad, y eliminando, a la vez, todos los parches. Ahora sí tenemos una línea secuencial precisa que ... así que, si les parece, podemos concertar una cita para estudiar ..."

Y vuelta a empezar. ¿O es que creían que el analist(r)a es un animal autoevolutivo? ¿O acaso pensaban que las quejas del cliente influyen "realmente" sobre las técnicas de este tipo de análisis? Por supuesto que la pregunta del millón de dólares del cliente es: ¿por qué diablos no plantearon al principio esta generalización y unificación conceptual?

Bien, vayamos al principio. El analist(r)a intenta secuenciar con exactitud porque es su única forma de abordar un problema. Así, con el práctico lema "Divide y vencerás", se aplica al problema un enfoque top-down, más o menos matizado, y ... bueno, ya saben ustedes: se busca el cometido principal o función top del sistema y, en sucesivos pasos, se descompone en subobjetivos, hasta llegar a subproblemas indescomponi­bles o perfectamente identificables como componentes básicos en ciertos repositorios. El verdadero problema es que, como señala Meyer, la mayoría de los sistemas complejos de información no poseen función top, de manera que el analist(r)a debe normalmente moldear uno "a medida", pero que, por su misma extrema concreción, malamente admite modificaciones.

CICLO DE VIDA DE LAS ESPECIFICACIONES

La observación -por no decir análisis- de multitud de proyectos software basados, informal o formalmente, en el "enfoque estructura­do" puede llevar al lector a la errónea conclusión de que el análisis de requerimien­tos es una suerte de composición estática, gráfica o textual, que sostendrá el proyecto como un todo, del mismo modo que lo harían los requerimien­tos del cliente de un arquitecto con respecto a la construcción de una cierta edificación. Bien, esto es parcialmente cierto, pero, a la vez, lamentablemente difuso. O sea, es en efecto acertado suponer que un proyecto dado no podrá llevarse a cabo sin saber de qué demonios de proyecto se trata, pero también lo es que pensar que el desarrollo del proyecto puede, de alguna manera, imponer restricciones o facilitar ampliaciones de los requerimientos iniciales del mismo. Así que volvemos a lo de siempre -pensará el inquieto y avisado lector-: "Arriba y abajo, siempre atrás y adelante. Pero, ¿es que no hay nada fijo, estable, en que apoyarse firmemente?". Bueno, amable lector, quizás la muerte, o aun la tontería, pero no las frágiles estructuras que se desprenden de la interpretación del conocimiento humano.

ASPECTOS CONTRACTUALES

Una queja que se deja oír muchas veces en las empresas serias de desarrollo de software suena de forma parecida a: "resulta turbadora­men­te difícil establecer un documento con carácter contractual sobre el que se pueda dirimir, en caso de conflicto, el ajuste, o no, del trabajo realizado a los requerimien­tos del cliente". Recapacitemos ligeramente: de todas las posibles fases (en cascada o no) del proceso de desarrollo de software, la única que posibilita tal entroncamiento contractual, por ser la única susceptible de ser expresada en un lenguaje común a ambos, cliente y analista, es la de OORA. En el resto de las fases se produce una transcripción de tales especificaciones a lenguajes y simbologías que no tienen directamente que ver con el dominio del problema a estudiar, y que, por ende, requerirían, para ser dotadas de fuerza legal, de una interpretación léxica objetiva y exacta. Por supuesto que no existe tal esfera objetiva exterior, y dudo que ningún cliente se aviniera a basar sus cuitas judiciales en la previa aceptación de un diagrama no proveniente de su propia casa, por mucho Yourdon, de Marco, Jackson, Rumbaugh, etc. que en tal se detallara. Aparentemente se imponen, así, las especificaciones textuales: necesarias, pero no exclusivas.

¿ESPECIFICACIONES GRÁFICAS O TEXTUALES?

Regresemos al principio: ¿por qué las especificaciones en OOA/OOD son mayoritariamente textuales? Esto es, ¿qué pasa con aquéllos habituales -y prácticos- diagramas estructurados de flujo de datos? ¿o con las conocidas burbujas? Y sobre todo, ¿por qué no usar los tan extendidos modelos gráficos Entidad-Relación de Chen? Bien: Lo cierto es que la mayoría de las técnicas actuales -calificadas ya como "tradicionales" por Firesmith [3] hace uso intensivo de las directrices de Abbott [4], desarrolladas sobre una plataforma textual conseguida de alguna innominada manera, pues normalmente se obvia el proceso por el que se obtienen tales especificaciones textuales, así como su tratamiento, si acaso existe.

TÉCNICAS DE OORA

Tras lo expuesto en anteriores parágrafos, el lector puede pensar que la tarea de arrancar al cliente las especificaciones no es nada fácil. De hecho, como ya ha sido dicho, la práctica totalidad de los métodos actuales de OOA/OOD no establecen ningun método formal de procurar las especificaciones de requerimientos que proporcionen la base sobre la que edificar el posterior análisis y diseño del sistema. Precisamente por eso podría sorprenderse al constatar que Graham [5] sostiene precisamente lo contrario. Oh, pero no hay nada sustantivo tras estas cuitas, que vienen a sostener que el bagaje técnico del analista finalmente inclinará la balanza. La verdad es que, mención aparte del texto de Jackson [6](que comenté en el artículo “Objetos: Hitos, Mitos y Ritos”, RPP, enero, 1996), pocas técnicas de especificaciones encontrará editadas el ávido lector (cosa que no puede decirse de los lenguajes de especificación que, sin abrumar, abundan).

UNA SOLUCIÓN INTEGRAL

Tras todo lo anterior, ¿qué hacer? ¿Realmente no existe una solución integral que cubra el proceso entero de desarrollo de software? Oh, sí. Se denomina OOram, y será protagonista del próximo artículo.

[1] No cuento aquí, claro, con los supuestos de estimación cuantitativa, solidez, efectividad y eficacia de los sistemas software.

[2] Meyer, Bertrand, Object-Oriented Sofware Construction, 1988, Prentice Hall.

[3] Firesmith, Donald G., Object-Oriented Requirements Analysis and Logical Design, 1993.

[4] Abbott, R.J. (1983), Program Design by Informal English Descriptions, Communications of the ACM, 26(11), 882-94

[5] Graham, Ian M., Object-Oriented Methods, 1991, Addison-Wesley.

[6] Jackson, Michael, Software Requirements & Specifications, 1995, Addison-Wesley, 0-201-87712-0.