Resumen
Abstract
En el desarrollo de un sistema de software, una de las etapas que presentan mayor dificultad es la de especificar en forma precisa qué se debe construir. Si no se detectan oportunamente errores cometidos en la etapa de definición de requisitos, el impacto sobre el producto de software resultante será mayor que si se producen en etapas posteriores. Por esta razón, esta es una de las etapas más importantes en el desarrollo de software. La Ingeniería de Requisitos la define como un proceso en el cual se debe elicitar, modelar y analizar la información referente al sistema, considerando diferentes puntos de vista, y aplicando una combinación de métodos, herramientas y personal. El producto de este proceso es un modelo, a partir del cual se produce un documento llamado "Requisitos", que puede ser utilizado como medio de comunicación con los clientes. Este documento contiene una descripción de qué hará el sistema, sin referirse a cómo lo hará el producto de software final [4].
La tarea principal del análisis de requisitos es generar especificaciones que describan el comportamiento del sistema en forma no ambigua, consistente y completa. Para que esta tarea sea llevada a cabo en forma adecuada, es necesario determinar correctamente el contexto, es decir dónde se efectuarán las tareas de ingeniería, con qué recursos se cuenta, cuáles son los límites y los objetivos del producto que se está por desarrollar. Este contexto se denomina Universo de Discurso (UD) y evoluciona a lo largo del proceso de desarrollo y mantenimiento del software. Cuanto mejor se especifique ese UD, mayores serán las posibilidades de obtener un sistema bien definido.
El UD contiene todas las fuentes de información que se van a utilizar. Por medio de la elicitación se intenta descubrir la información necesaria para conocer el sistema en estudio. En [3] [5] se propone el uso del Léxico Extendido del Lenguaje (LEL) y de escenarios como técnicas para representar esa información. Es importante destacar que durante la fase de elicitación puede ser necesario re-delinear el UD.
En este trabajo se describe el proceso de aplicación del método
propuesto en [4] [5] al caso concreto
de un Sistema de Plan de Ahorro Previo para la Adquisición de Vehículos
0Km [6], presentando los resultados obtenidos en cada
una de las etapas.
El Sistema de Plan de Ahorro Previo para la Adquisición de Vehículos 0Km se dedica a gestionar y administrar planes de ahorro para adquirir automotores 0Km. Funciona a través de grupos de una cierta cantidad de personas físicas o legales, los cuales participan mensualmente de los sorteos que la Administradora general organiza, con el objeto de entregar una unidad por grupo. Los integrantes o adherentes de cada grupo pueden tratar de anticipar la entrega de la unidad que les corresponde, presentando ofertas de licitación en sobre cerrado. En cada acto de adjudicación, además de sortear el número del adherente favorecido de cada grupo, se abren las ofertas de licitación, si las hubiera, para determinar la mejor oferta y establecer así el beneficiario. Además, la Administradora debe arbitrar en caso de renuncia o fallecimiento de participantes, o falta de pago de las cuotas mensuales; entiende en cuestiones legales tales como trámites sucesorios, seguros de vida y del automotor, intimaciones de pago, contratos con los fabricantes, etc.
Por su complejidad razonable pero no excesiva, el caso real elegido
resultó adecuado para aplicar la metodología.
En [4] [5] se ha propuesto un
método para realizar una derivación preliminar de los objetos
de un sistema, a partir de la elicitación de la información
del UD. En el mismo se propone especificar los diferentes términos,
obtenidos del UD, que integrarán un Léxico Extendido del
Lenguaje (LEL), como así también generar un conjunto de escenarios
que modelen el comportamiento del sistema. A partir de ambos documentos
y de la interacción entre ellos, se muestra la forma de derivar
una definición inicial del modelo de objetos. Estas etapas se presentan
en la Figura 1.
Recolección de datos
Dentro de la Ingeniería de Requisitos, por medio de la elicitación, se identifican los hechos que componen los requisitos del sistema con el fin de comprender correcta y completamente lo que se espera del software en desarrollo. El paso inicial para cumplir con este objetivo es determinar cuál es el UD, que será la fuente de la cual se extraerá la información en la tarea de elicitación.
Para poder obtener la información del UD existen distintas estrategias.
Una de ellas es la lectura de documentos, que permite a los ingenieros
de requisitos entrar en contacto con el vocabulario de la aplicación.
Sin embargo, el medio más usual para adquirir la información
consiste en efectuar entrevistas. Éstas pueden ser estructuradas,
cuando el entrevistador posee algún conocimiento sobre el problema
y elabora un cuestionario; o no estructuradas, en las cuales se permite
al entrevistado hablar libremente.
Generación del LEL
Uno de los aspectos fundamentales dentro de la Ingeniería de Software es el modelado. El LEL es un meta-modelo diseñado para ayudar a capturar el vocabulario de la aplicación, que utiliza el lenguaje natural para la representación de sus símbolos. El objetivo de esta técnica es entender el lenguaje del problema, sin preocuparse por comprender el problema en sí [3].
A través de una técnica de recolección de datos, como la lectura de documentos, o las entrevistas, el ingeniero de software registra las frases o palabras que parecen tener un significado especial en la aplicación. El resultado de esta fase es una lista de términos que el ingeniero de software utiliza como base para realizar una entrevista estructurada con los actores de la aplicación, procurando entender lo que cada término significa. En esta etapa, se describen las nociones e impactos de cada palabra o frase. La noción es el significado, y el impacto determina los efectos del uso u ocurrencia del elemento en la aplicación.
Para poder lograr una descripción apropiada de los términos del LEL, se debe establecer si éstos son usados como sujetos, verbos u objetos, o si describen situaciones en las frases que los actores utilizan para describirlos. Al definir de esta manera cada entrada del LEL, es posible detectar sinónimos para cada una, que se incorporan al modelo.
LEL para el Sistema de Plan de Ahorro
En el caso de estudio, se utilizó como primera técnica de recolección de datos la lectura de documentos. Un grupo, constituido por tres personas, procedió a la lectura del contrato del Plan de Ahorro [2]. Para esto, se dividió el contrato en tres partes y cada integrante se interiorizó en una de ellas. Posteriormente, el grupo se reunió para analizar la información obtenida. Este proceso fue muy productivo y permitió detectar fácilmente un número importante de términos. Esto fue posible puesto que un contrato contempla las diferentes situaciones que se pueden presentar durante su vigencia, y éste en particular, define el significado y alcance de los términos específicos del dominio del problema. Con la información obtenida, se redactó una lista con los símbolos del lenguaje de la aplicación.
A continuación, un nuevo grupo de dos personas, que no había tenido contacto con el documento, entrevistó informalmente al primero. Como en el desarrollo del caso de estudio no hubo oportunidad de entrevistar al usuario real, en esta reunión, el primer grupo asumió la función de actor del UD, y el segundo actuó como ingeniero de requisitos. En este caso, no existían diferencias culturales entre ambos grupos, y si bien el primero había leído anteriormente el contrato, ninguno de los dos era experto en el dominio de la aplicación. Por este motivo, se presupone que no se originó el problema de conocimiento tácito. Sin embargo, la falta de conocimiento previo ocasionó que en la entrevista, se presentaran cuestiones que el grupo lector no pudo responder porque no figuraban en el contrato.
A partir de los resultados de la primera entrevista, el grupo entrevistador se reunió para cotejar la información relevada por sus integrantes. Como producto de esta discusión se redactó una lista que se utilizó como guía para una segunda entrevista, en este caso estructurada. En ésta, se compararon las listas de ambos grupos y se comprobó que la mayoría de los términos coincidían. La lista del segundo grupo fue más extensa debido, principalmente, a que se habían incluido términos que eran sinónimos. De la combinación de ambas, surgió una lista de entradas candidatas del LEL, formada por 65 términos. A partir de este momento se procedió a fusionar ambos grupos y todos sus miembros asumieron el rol de ingenieros de requisitos.
Luego, con el fin de aplicar las heurísticas para la conformación de las entradas en el LEL, se procedió a clasificar cada uno de los términos de la lista. Para ello, ésta se dividió entre los distintos integrantes y cada uno definió las nociones e impactos de los términos que debía analizar, de acuerdo con su categoría. A lo largo de este proceso se realizaron reuniones de discusión con el fin de compaginar los resultados individuales, teniendo siempre al contrato como referencia. Esto permitió descartar algunos términos, detectar sinónimos, y agregar nuevas entradas que no habían sido incluidas en la lista de candidatas. Los resultados de estas etapas se detallan en la sección 3.4.
En las Figuras 2a y 2b, se
presenta un ejemplo de cada una de las categorías.
|
|
ADJUDICATARIO /
ADJUDICATARIOS
Noción:
|
BIEN TIPO / BIEN
Noción:
|
En general, no se presentaron dificultades para determinar la categoría
de los términos. Sin embargo, en algunos casos no fue sencillo distinguir
un verbo de una situación; cada vez que se presentó un conflicto
de este tipo se optó por el verbo. Por ejemplo, se eligió
LIQUIDAR
UN GRUPO, en lugar de LIQUIDACIÓN DE
UN GRUPO.
|
|
ACEPTAR LA ADJUDICACIÓN
POR SORTEO / ACEPTAR LA ADJUDICACIÓN
Noción:
|
INCUMPLIMIENTO
IMPUTABLE AL GRUPO
Noción:
La Administradora debe comunicar fehacientemente a cada adherente y adjudicatario la medida tomada. |
Construcción de escenarios
Los escenarios son un medio natural para representar y capturar conocimiento del dominio durante la elicitación y documentación de requisitos [9]. Un escenario constituye una descripción de los aspectos relevantes en cuanto al comportamiento y al ambiente de un sistema, mediante episodios concretos y específicos, usando generalmente lenguaje natural. Se pueden usar para describir el comportamiento externo del sistema permitiendo la participación e interacción del usuario durante todo el proceso de análisis de requisitos. Además, los escenarios pueden ayudar en la validación de la especificación de requisitos [1].
Para definir escenarios se requiere un conocimiento detallado que sólo
los expertos del dominio pueden proveer y validar. Los escenarios están
más cerca que otros modelos abstractos de la percepción que
los clientes y usuarios tienen del dominio del problema, ya que se escriben
usando el lenguaje específico de ese dominio. Esto facilita la asimilación
de descripciones complejas y abstractas que de otra forma se podrían
entender mal [7] y permite establecer una buena comunicación
con los expertos no técnicos del dominio.
|
Nombre del escenario |
|
Meta a ser alcanzada en el macrosistema |
|
Ubicación geográfica y estado inicial del escenario |
|
Medios necesarios para la realización del escenario |
|
Personas u organizaciones |
|
Serie de sentencias que muestran el comportamiento del escenario |
|
Situación que provoca un comportamiento diferente del escenario |
La construcción de escenarios es un proceso que consiste en entender, analizar y describir el comportamiento de un sistema en términos de las diferentes formas en las que se espera usarlo. El producto final de esta etapa es un documento que contiene un conjunto de escenarios correctos, completos, consistentes y validados. Este documento forma parte de la especificación de requisitos del sistema y se usa como guía para el diseño y el testing.
Un escenario se puede describir utilizando el esquema propuesto en [3],
que se muestra en la Figura 3.
Objetivo: Administradora Formulario de elección de Compañía de Seguros y de contratación del Seguro con una compañía de una lista provista por la Administradora Formulario de pedido del vehículo que debe estar debidamente completado y firmado El adjudicatario presenta el formulario de elección de Compañía de Seguros y Contratación del Seguro. El adjudicatario paga el complemento de cuotas de integración mínima. El adjudicatario reembolsa los gastos de flete y seguro de transporte. Restricción: La Administradora debe haber notificado al adherente el costo del flete y seguro de transporte previamente a la firma de la solicitud. El adjudicatario presenta el formulario de pedido del vehículo. SUSCRIBIR CONTRATO DE PRENDA con registro entre el adjudicatario y la Administradora. Restricción: con aplicación de la ley vigente El adjudicatario demuestra encontrarse al día con los pagos # El bien es retirado de la Concesionaria La Administradora pone el bien a disposición del Adjudicatario Restricción: Debe realizarse dentro de los 60 días desde la fecha de recepción del formulario de pedido del vehículo. Excepción: Demoras por caso fortuito o fuerza mayor en la Administradora o el Fabricante no imputables a ellos. |
Escenarios del Sistema de Plan de Ahorro
Existen distintas alternativas para elicitar escenarios [1] [5]. En este trabajo se utilizó la propuesta en [5] que consiste en construir los escenarios a partir del LEL, aplicando una serie de heurísticas [4]. Los pasos seguidos fueron los siguientes:
1. Identificación de los actores de la aplicación:
Los actores se obtuvieron a partir de las entradas del LEL clasificadas como Sujetos. Se identificaron 11 actores principales y 4 actores secundarios. Resultó así una lista constituída inicialmente constituida por 38 escenarios.
2. Elaboración de lista de escenarios candidatos:
Se elaboró una lista con 32 escenarios candidatos obtenidos analizando los impactos de los actores principales de la aplicación, y 6 escenarios candidatos definidos a partir de los impactos de los actores secundarios.
3. Descripción de los escenarios candidatos
Cada escenario se describió siguiendo el esquema de la Figura 3. Se identificaron casos alternativos para los escenarios y restricciones y excepciones en los episodios. En la Figura 4 se muestra la descripción de un escenario en el que aparecen las características mencionadas.
4. Revisión de los escenarios
En esta etapa se detectó que algunos escenarios contenían episodios que podían llegar a ser nuevos escenarios. En aquellos casos en los que ese episodio involucraba un conjunto de acciones, se lo incorporó a la lista de escenarios reemplazando el episodio por el nombre del nuevo escenario. Este análisis dio origen a 11 nuevos escenarios que se agregaron a la lista.
Además, se eliminaron 11 escenarios candidatos debido a diferentes razones. En algunos casos, se entendió que estaban fuera de los límites de la aplicación. Esto sucedió con algunos escenarios obtenidos a partir de los actores secundarios, como por ejemplo PAGAR INDEMNIZACION EN CASO DE SINIESTRO, obtenido de los impactos del actor secundario COMPAÑÍA DE SEGUROS. En otros casos, se encontró que ciertos escenarios candidatos resultaban poco significativos, y por lo tanto se descartaron. Por último, se descubrió que algunos otros eran, en realidad, episodios simples y pasaron a formar parte de la lista de episodios de otros escenarios. Por ejemplo, el escenario propuesto como ENVIAR COMUNICACIÓN FEHACIENTE resultó ser un episodio de diferentes escenarios, como en el caso de ACEPTAR LA ADJUDICACIÓN o en ADJUDICAR UN BIEN POR LICITACIÓN.
Finalmente, se obtuvo una lista de 33 escenarios. De los 38 escenarios candidatos, 19 permanecieron en esta lista, 11 surgieron porque estaban incluidos como episodios simples en otros escenarios y 3 se obtuvieron agrupando en uno varios escenarios candidatos.
En cada una de las etapas del proceso de desarrollo, el contrato de Plan de Ahorro fue una valiosa fuente de información que permitió validar el modelo producido. De esta manera, fue posible verificar que todas las alternativas previstas por el contrato fueran contempladas por el modelo, solucionar algunas de las dudas que se presentaron y detectar errores.
3.3 Tarjetas: Clases - Responsabilidad - Colaboración (CRC)
Confección de las tarjetas
Una vez que se han establecido los términos del LEL y los escenarios correspondientes al sistema en estudio, el método indica continuar con la confección de las tarjetas CRC [4]. Esta es una técnica orientada a establecer un planteo inicial de los objetos que participan en el sistema. El producto de esta etapa es un conjunto de tarjetas, asociadas a cada una de las clases, en las que se especifican las responsabilidades y sus colaboraciones con otras clases, como se plantea en [8].
Las responsabilidades son sentencias de alto nivel acerca de las acciones que realiza un objeto como también del conocimiento que él mantiene y provee. Por lo tanto, constituyen el grupo de servicios que brinda la clase correspondiente. El conjunto de las responsabilidades de cada clase representa la forma en que se distribuye lo que el sistema global debe realizar.
Los objetos no están aislados sino que colaboran unos con otros. Una colaboración es una solicitud hecha por un objeto a otro. Para identificarlas, se debe examinar cada par clase-responsabilidad con el fin de determinar si es necesario que la clase interactúe con otra/s para llevar a cabo esa responsabilidad. Para ello, puede ser apropiado realizar las siguientes preguntas, para cada responsabilidad definida en una clase: 1) ¿La clase es capaz de concretar la responsabilidad por sí misma?; 2) Si no es así, ¿de qué otra clase puede adquirir lo que necesita?; 3) ¿Qué otras clases necesitan la información que la clase conoce o el resultado que produce?. En este punto se puede verificar si se ha obtenido alguna clase que no interactúe con las demás, ya que en este caso debería eliminarse. Sin embargo, antes de hacerlo, es necesario revisar las etapas anteriores con el fin de comprobar que tales interacciones no se hayan pasado por alto.
Una tarjeta CRC contiene el nombre de la clase que representa, sus responsabilidades y las clases con las que colabora. En el ejemplo de la Figura 5 se muestra el esquema propuesto en [4] para la descripción de las tarjetas.
Tarjetas CRC para Sistema de Plan de Ahorro
Para la confección de las tarjetas, se revisaron los escenarios con el fin de listar las clases primarias y secundarias candidatas, verificando la existencia de una entrada para las mismas en el LEL. Luego, al examinar los escenarios, se refinaron los objetos completando los aspectos vinculados con las responsabilidades y colaboraciones con otras clases.
Siguiendo las heurísticas indicadas en la metodología, se identificaron 10 clases primarias y 13 clases secundarias. Luego se examinaron las listas de clases construidas, verificándose que, posiblemente por haberse discutido la situación previamente, no existían clases redundantes. Durante el análisis de la presencia de posibles clases no significativas, se encontró que una de las clases (definida inicialmente como secundaria por tratarse de un recurso de un escenario), no tenía suficiente "peso" como para conservarla como tal. Por otro lado, se detectó que faltaban dos clases consideradas fundamentales que no habían surgido al aplicar las heurísticas. Ante esta situación, se revisaron y se corrigieron los escenarios. Finalmente, se establecieron las responsabilidades y colaboraciones para las 10 clases primarias y 14 secundarias resultantes.
En la Figura 5 se presenta un ejemplo de las tarjetas
confeccionadas. Cabe mencionar que, en el caso de las responsabilidades,
se listaron aquellas que se desprendían directamente de los impactos
de los términos correspondientes en el LEL y que restaría
agregar otras relacionadas con el registro y la emisión de información
(en el ejemplo, podrían ser Registrar el nombre del adherente,
Informar el nombre del adherente). La lista de clases colaboradoras
se incluyó sin correspondencia con las responsabilidades (tomando
como guía el material de estudio). Sin embargo, sería más
conveniente que cada responsabilidad fuese acompañada por las clases
que colaboran.
ADHERENTE | |
Efectuar el pago de
la cuota mensual.
Realizar la cesión de derechos a otro adherente. Renunciar al grupo. Presentar oferta de licitación |
Administradora
Adherente (cesionario) Grupo Plan de ahorro oferta de licitación cupón de pago |
3.4 Resultados obtenidos en la aplicación del método
En la Figura 6 se muestran los resultados obtenidos
para una primera versión y una revisión de los documentos
producidos en todas las etapas de la aplicación de la metodología
al caso de estudio. En realidad, fue necesario realizar más de un
refinamiento y revisión de cada etapa; sin embargo, los números
que aparecen en la figura corresponden al momento en que se dio por finalizada
cada una y se decidió pasar a la siguiente.
|
|
|
|
||||||
Sujetos | Verbos | Objetos | Situacio-
|
|
|||||
Lectura preliminar del docum. |
|
||||||||
Entrevista no estructurada |
|
||||||||
Entrevista estructurada |
|
||||||||
1º Versión LEL |
|
|
|
|
|
||||
Revisión del LEL |
|
|
|
|
|
||||
1º Versión Escenarios |
|
||||||||
Revisión Escenarios |
|
|
|
|
|
|
|||
1º Versión CRC |
|
||||||||
Revisión CRC |
|
La construcción del LEL y los escenarios es un punto de partida muy apropiado para la derivación de los objetos de un sistema. En este artículo se describe la aplicación del método propuesto en [5] al Sistema de Plan de Ahorro Previo para la Adquisición de Vehículos 0Km. La principal contribución de este trabajo pretende ser el relato de las experiencias y resultados obtenidos en este proceso.
Durante el seguimiento de las heurísticas en cada una de las etapas, ocasionalmente surgieron puntos no tenidos en cuenta en la construcción de los documentos anteriores. Por esta razón fue necesario volver atrás, con el fin de revisarlos y eventualmente modificarlos. Por ejemplo, al construir los escenarios fue inevitable retornar al LEL para refinar el vocabulario, debiendo incorporar impactos en términos ya existentes, agregar o eliminar términos. Posteriormente, la construcción de las tarjetas CRC condujo a la inspección de los recursos definidos para algunos escenarios.
Es importante destacar que no se tuvo oportunidad de entrevistar al usuario. Si esto pudiera concretarse, es probable que los resultados que se presentan sufrieran modificaciones.
Agradecimientos
A la Lic. Carmen Leonardi por su colaboración durante el desarrollo
del caso de estudio.
Referencias
[1] Hsia Pei et. al, Formal Approach to
Scenario Analysis, IEEE Software, March 1994, pp. 33-40.
[2] Fiat Auto S.A., Solicitud de Adhesión
y Condiciones Generales de Contratación, para Plan de Ahorro Previo
para la
Adquisición de Automóviles
0 Km.
[3] Leite J.C.S.P., Rossi G.,et al, Enhancing
a Requirements Baseline with Scenarios, Proceedings of RE 97’:
International Symposium on Requeriments
Engineering, IEEE, January 1997.
[4] Leite JCSP, Ingeniería de Requisitos,
Notas de cátedra, 1997.
[5] Leonardi M., Maiorana V., Balaguer F.,
Una
Estrategia de Análisis Orientada a Objetos basada en Escenarios,
Actas II Jornadas de Ingeniería
de Software JIS97, Donostia, San Sebastián, España, Set.1997.
[6] Mauco V., Ridao M., del Fresno M., Rivero
L., Doorn J., Ingeniería de Requisitos, Proyecto: Sistema de Planes
de
Ahorro, Reporte Final, ISISTAN, UNCPBA,
Diciembre1997.
[7] Potts C., Using Schematic Scenarios
to Understand User Needs, DIS’95.
[8] Wirfs-Brock R., Designing Object-Oriented
Software, Prentice Hall, 1990.
[9] Zorman L., The Content and Composition
of Scenarios, OOPSLA Workshop, Requirements Engineering: Use cases
and more, 1995.