Mariana del FRESNO, Virginia MAUCO, Marcela RIDAO, Jorge DOORN* , Laura RIVERO
Universidad Nacional del Centro de la Provincia de Buenos Aires.
Facultad de Ciencias Exactas - Instituto de Sistemas de Tandil - ISISTAN
 * También en Universidad de Belgrano,B.A., Argentina

 
mdelfres@exa.unicen.edu.ar
vmauco@exa.unicen.edu.ar
mridao@exa.unicen.edu.ar
jdoorn@exa.unicen.edu.ar
lrivero@exa.unicen.edu.ar

 


 Resumen

El área de Ingeniería de Requisitos se encuentra en permanente evolución, y muchos de sus métodos y herramientas han tenido poca ejercitación en casos reales, por lo que algunas de las opiniones y conclusiones que se pueden recoger en la bibliografía especializada se han generado a partir de consideraciones teóricas o expresiones de deseo de sus autores. En [5] se ha propuesto un método para realizar una derivación preliminar de los objetos de un sistema, mediante el uso del Léxico Extendido del Lenguaje y Escenarios. Existen reportes acerca de algunas aplicaciones de este método, pero pocas de ellas han sido realizadas en situaciones controladas, prestando atención a la importancia relativa de cada uno de los pasos de las heurísticas empleadas. En el presente artículo se relata el proceso de aplicación de la metodología a un caso concreto y se detallan los resultados de las principales métricas utilizadas. Palabras clave: LEL, Escenarios, Tarjetas CRC, Análisis Orientado a Objetos

Abstract

The Requirements Engineering area is in constant evolution, and many of its methods and tools had hardly been put into practice in real cases. Therefore, some of the opinions and conclusions that can be found in the specialised bibliography have been generated from theoretical considerations or from their authors’ wishes. In [5] a method to obtain a preliminary derivation of the objects of a system, through the use of the Lexical Extended Language and Scenarios, has been proposed. There are reports about some applications of this method, but few of them have been accomplished in controlled situations, paying attention to the relative importance of each step of the heuristics used. This paper presents the application of the methodology to a concrete case and it details the results of the main metrics used. Key Words: LEL, Scenarios, CRC Cards, Object Oriented Analysis

 



1. Introducción
2. Caso de estudio
3. El método
     3.1   LEL
     3.2   Escenarios
     3.3   Tarjetas: Clases - Responsabilidad - Colaboración (CRC)
     3.4   Resultados obtenidos en la aplicación del método
4. Conclusiones



 

1. Introducción

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.
 
 

2. Caso de estudio

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.
 
 

3. El método

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.
 
 

3.1 LEL

    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.
 

Fig. 1 - Método de derivación de objetos


  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.
 

Sujeto
Objeto
ADJUDICATARIO / ADJUDICATARIOS 

Noción:  

    Adherente sin deuda pendiente que ha resultado favorecido en un acto de adjudicación
Impacto: 
  • Puede aceptar la adjudicación por sorteo o rechazar la adjudicación por sorteo mediante comunicación fehaciente
  • Puede solicitar el cambio del bien una vez que le fue adjudicado. 
  • Debe continuar pagando las cuotas mensuales del Plan de ahorro
  • Puede realizar una cancelación anticipada de su deuda con la Administradora
  • Debe contratar un seguro para el bien.
BIEN TIPO / BIEN 

Noción: 

    Es la unidad 0Km producida por un Fabricante nacional o extranjero, elegida por un solicitante
Impacto: 
  • Puede ser adjudicado por sorteo 
  • Puede ser adjudicado por licitación 
  • Puede producirse la discontinuación del bien 
  • Puede ser reemplazado por el Fabricante 
  • Puede producirse el cambio del bien por el adjudicatario, antes de la entrega del bien 
  • Si queda sin adjudicar en una licitación, por incumplimiento del o los adherentes, se agrega en el acto de adjudicación siguiente.
Fig 2a -Ejemplos de términos del LEL

 


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.
 
 

Verbo
Situación
ACEPTAR LA ADJUDICACIÓN POR SORTEO / ACEPTAR LA ADJUDICACIÓN 

Noción: 

    Se produce cuando el adjudicatario manifiesta su acuerdo por comunicación fehaciente a la Administradora. El plazo para hacerlo es de cinco días a partir del día en que se efectúa la publicación en diario de circulación nacional, o a falta de ésta, de la comunicación fehaciente al adjudicatario
Impacto: 
  • Ocasiona que el adjudicatario deba efectuar el pago del derecho de adjudicación y realizar la contratación de un seguro en una Compañía de Seguros para el bien, previo a la entrega del bien. 
  • Si no se produce en el plazo y en la forma establecida, el adjudicatario pierde el derecho a la adjudicación, pasando a tenerlo el siguiente en el orden de sorteo.
  • Debe contratar un seguro para el bien.
INCUMPLIMIENTO IMPUTABLE AL GRUPO  

Noción: 

Se produce cuando en un grupo se encuentran vencidas e impagas un número de cuotas mensuales igual o superior al 60% de las cuotas de un mes dado. Impacto:  
  • La Administradora puede continuar con el trámite normal de adjudicación en la medida que el fluir de fondos lo permita. 
  • La Administradora puede reagrupar o fusionar al grupo con otro u otros grupos
  • La Administradora puede proceder a la liquidación del grupo

  • La Administradora debe comunicar fehacientemente a cada adherente y adjudicatario la medida tomada.
Fig 2b -Ejemplos de términos del LEL


3.2 Escenarios

    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.
 

Título
Nombre del escenario
Objetivo
Meta a ser alcanzada en el macrosistema
Contexto
Ubicación geográfica y estado inicial del escenario
Recursos
Medios necesarios para la realización del escenario
Actores
Personas u organizaciones 
Episodios
Serie de sentencias que muestran el comportamiento del escenario
Excepción
Situación que provoca un comportamiento diferente del escenario
Fig.3 - Descripción de un 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.
 

Título: ENTREGAR EL BIEN 
Objetivo:  Otorgar el bien adjudicado al adjudicatario Contexto:  El bien ha sido adjudicado por sorteo y el adjudicatario ha aceptado la adjudicación o ha sido adjudicado por licitación Actores:  Adjudicatario 
Administradora
Recursos:  Disponibilidad del bien 
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
Episodios:           # El adjudicatario paga el derecho de adjudicación  El adjudicatario paga impuestos, tasas, patentes y otros gastos 
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 
Si los bienes del adjudicatario no resultan suficientes para la cobertura y respaldo del grupo, entonces el adjudicatario presenta un codeudor solidario como garantía adicional 
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.
Excepción:  Si la Administradora no cumple con la entrega entonces el adjudicatario puede RECLAMAR PENALIDAD 
Fig 4 - Descripción del escenario ENTREGAR EL BIEN

    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
Fig 5 - Tarjeta CRC de la clase ADHERENTE


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.
 

#Términos en listas preliminares
# Entradas del LEL
#Escenarios
# CRC
Sujetos Verbos Objetos Situacio-
nes
Total
Lectura preliminar del docum.
73
             
Entrevista no estructurada
90
             
Entrevista estructurada
65
             
1º Versión LEL  
19
12
25
9
65
   
Revisión del LEL  
13
10
19
10
52
   
1º Versión Escenarios            
38
 
Revisión Escenarios  
15
11
20
9
55
33
 
1º Versión CRC              
23
Revisión CRC              
24
Fig. 6 - Resumen de los resultados obtenidos

 

4. Conclusiones

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.