Tradicionalmente, los proyectos de desarrollo de software comienzan por obtener un entendimiento del

Transcripción

1 A process model for requirements elicitation in information mining projects Modelo de proceso para elicitación de requerimientos en proyectos de explotación de información Diego Mansilla 1, Florencia Pollo-Cattaneo 2, Paola Britos 3, Patricia Pesado 2, Ramón García- Martínez 4 1 Grupo de Estudio en Metodologías de Ingeniería de Software. Facultad Regional Buenos Aires. Universidad Tecnológica Nacional. Buenos Aires, Argentina. dmansilla@educ.ar. 2 Programa de doctorado en Ciencias informáticas. Facultad e Informática. Universidad Nacional de La Plata. La Plata. Buenos Aires. Argentina. fpollo@posgrado.frba.utn.edu.ar. 3 Grupo de Investigación en Explotación de información. Sede Andina. Universidad Nacional de Río Negro. Argentina. paobritos@gmail.com. 4 Grupo Investigación en Sistemas de Información. Departamento Desarrollo Productivo y Tecnológico. Universidad Nacional de Lanús. Lanús, Argentina. rgarcia@unla.edu.ar. INFORMACIÓN DEL ARTÍCULO Tipo de artículo: Investigación Historia del artículo: Recibido: 30/03/2012 Correcciones: 30/05/2012 Aceptado: 31/05/2012 Palabras clave Proceso, elicitación, requerimientos, proyecto explotación de información. Categories and Subject Descriptors D.2.1 [Requirements/Specifications]: Methodologies General Terms Requirements Engineering. ABSTRACT A problem addressed by an information mining project is transforming existing business information of an organization into useful knowledge for decision making. Thus, traditional software development process for requirements elicitation, by focusing on the software product and not in information, cannot be used to acquire required information for information mining process. In this context, a process for requirements gathering for information mining projects is presented, emphasizing the following phases: conceptualization, business definition and information mining process identification. RESUMEN La problemática abordada en los proyectos de explotación de información se basa en transformar la información existente de una organización en conocimiento útil para la toma de decisiones. Los modelos tradicionales de educción de requisitos, al enfocarse en el producto, no pueden ser utilizados para obtener la información requerida para los procesos de explotación de información. En este contexto, se presenta un proceso para elicitación de requerimientos en proyectos de explotación de información haciendo énfasis en las fases de: conceptualización, definición de negocio e identificación de procesos de explotación de información. Keywords Process, elicitation, information mining projects, requirements. 1. INTRODUCCIÓN La Ingeniería de Software tradicional ofrece una serie de herramientas y procesos para la elicitación de requerimientos software que son utilizadas en proyectos de creación de sistemas de información automatizados. Se entiende por requerimientos a la especificación de lo que debe ser implementado. Ellos son descripciones de cómo debe comportarse el sistema [1]. Los requerimientos suelen clasificarse de diferentes formas, siendo una de las clasificaciones más consensuada la organización de acuerdo al nivel del requerimiento, dividiéndose en requerimientos de negocio, requerimientos de usuario, requerimientos funcionales y requerimientos de sistema [2]. Las herramientas de elicitación de la Ingeniería de Software se enfocan en la descripción de los diferentes tipos de requerimientos, haciendo hincapié en las características que debe cumplir el producto final. Tradicionalmente, los proyectos de desarrollo de software comienzan por obtener un entendimiento del dominio del negocio y de las reglas que lo rigen. El entendimiento del dominio permite diferenciar requerimientos, a nivel producto o a nivel dominio del negocio [3], que delimitan el producto a construir respecto del contexto donde será utilizado. Modelos como el Diagrama de Contexto, Diagramas de flujos de datos, diagramas de secuencia, entre otros, sirven para representar gráficamente los procesos de negocio relevado y son utilizados como herramientas para la validación de los mismos. El analista funcional, que define los requerimientos del producto software a construir, utiliza estas herramientas con el objetivo de definir qué es lo que debe hacer el sistema software y no el cómo hacerlo. Además, la recopilación de la información está orientada a los datos de entradas y salidas de los productos a desarrollar y cómo esa información será transformada por el sistema. En etapas posteriores del proyecto, se trabaja en el cómo hacer para que el producto software satisfaga las necesidades planteadas por el negocio y en la construcción del mismo. El producto obtenido es, entonces, un sistema software que cumple con las características esperadas para el contexto en que será utilizado. 38

2 A diferencia de los proyectos de desarrollo de software, la problemática abordada en los proyectos de inteligencia de negocio se basa en transformar la información existente en una organización en conocimiento útil para la toma de decisiones, mediante el uso de herramientas analíticas [4]. Los modelos de elicitación de requerimientos y de gestión de proyectos, al enfocarse en el producto software a construir, no pueden ser utilizados para obtener la información requerida por los procesos de explotación de información. En este contexto, se hace necesario transformar la experiencia existente en el uso de las herramientas de elicitación de requerimientos en el dominio de sistemas software tradicionales en conocimiento que pueda ser utilizado para el armado de los modelos utilizados en la inteligencia de negocio y en los procesos de explotación de información [5-7]. En este trabajo se describirá el problema (sección 2), se presentará un proceso para elicitación de requerimientos en proyectos de explotación de información (sección 3), haciendo énfasis en la fase de conceptualización (sección 3.1), en la fase de definición de negocio (sección 3.2) y en la identificación de procesos de explotación de información (sección 3.3). Luego se propone el estudio de un caso (sección 4) y se proponen algunas conclusiones y futuras líneas de trabajo (sección 5). 2. DESCRIPCIÓN DEL PROBLEMA Actualmente, diversas disciplinas se han estandarizado para poder incorporar buenas prácticas provenientes de las experiencias adquiridas y de la incorporación de nuevos descubrimientos. La disciplina de gestión de proyectos, por ejemplo, generó un cuerpo de conocimiento donde definen las diferentes áreas del proceso de gestión de proyectos. La Ingeniería en software definió diferentes metodologías de desarrollo de sistemas, entre las cuales se establece el proceso de Desarrollo de requerimientos, donde definen las etapas de Elicitación, Análisis, Especificación y Validación como las actividades a realizar para obtener los requerimientos de un sistema software [1]. Por otro lado, en lo relacionado a proyectos de inteligencia de negocios, existe la metodología para el desarrollo de sistemas de explotación de información, CRISP-DM [8], P3TQ [9] y SEMMA[10]. En el campo de la explotación de información no existe un único proceso definido para gestionar los proyectos [11]. Sin embargo, existen aproximaciones que tratan de integrar el conocimiento adquirido en los diferentes proyectos tradicionales de desarrollo de software, como ser el ciclo de vida Kimball [12] y, abordajes para proyectos en el marco de las PyMes [13]. El ciclo de vida Kimball es utilizado en iniciativas de Data Warehouse/Business Intelligence (DW/BI) y se basa en el concepto que los proyectos de DW/BI se componen de diferentes piezas y, sólo si éstas se completan en forma apropiada y se integran correctamente, el sistema de DW/BI tendrá éxito. El problema encontrado es que dichas aproximaciones mencionadas hacen hincapié en metodologías de trabajo asociadas a los proyectos de explotación de información y no adaptan las técnicas de elicitación de requerimientos tradicionales de la Ingeniería en Software a las necesidades requeridas por los procesos de explotación de información. Ante esta situación, es necesario comprender qué pasos se deberían llevar a cabo y, qué técnicas de elicitación tradicionales podrían adaptarse en proyectos de explotación de información. 3. PROCESO DE ELICITACIÓN DE REQUERIMIENTOS El proceso que se presenta define un conjunto de actividades de alto nivel que se deben realizar como parte de la etapa de entendimiento del negocio, presentada en la metodología CRISP-DM, que puede ser utilizada en la definición de requerimientos de negocio del ciclo de vida de Kimball. El modelo de proceso propuesto descompone la problemática de la elicitación de requerimientos para proyectos de explotación de información en diferentes fases, que irán transformando el conocimiento adquirido en cada fase previa. Para cada fase del proceso se identifican qué técnicas de elicitación de requerimientos pueden ser utilizadas para resolver la problemática presentada para cada fase. Este modelo de proceso se contextualiza dentro del concepto de proyecto que, según el Project Management Institute, es un emprendimiento temporario para crear un producto, resultado o servicio único [14]. Para los proyectos de explotación de información, el objetivo planteado es identificar requerimientos de información y utilizar dicha información en la toma de decisiones. En [15] se plantea una propuesta operativa sobre la ejecución de proyectos de explotación de información, pero sin entrar en el detalle de qué técnicas de elicitación pueden utilizarse en el proyecto. Se debe comenzar definiendo diferentes capas dentro de un proyecto de explotación de información. Cada una de estas capas tendrá un objetivo y una serie de actividades a realizar, y a su vez, podrá seguir descomponiéndose en capas más específicas. Para cada actividad se plantea una adaptación de una técnica tradicional de elicitación de requerimientos. Comprensión del Negocio Conceptualización del dominio de negocio Entendimiento de los datos Preparación de datos Definición del Negocio Gestión de Proyecto Modelado Evaluación Implantación Identificación de Procesos de Explotación de Información Fig. 1: Fases propuestas La Figura 1 refleja las fases estratégicas de un proyecto de explotación de información, enfocándose en las actividades de elicitación de requerimientos propuestas. La capa de gestión de proyecto se encarga de la coordinación de las diferentes actividades necesarias para alcanzar los objetivos planteados, es la aplicación 39

3 del conocimiento, habilidades y herramientas para alcanzar los requerimientos planteados [14]. La disciplina de gestión de proyectos está definida por el Project Management Institute [14] pero dichas actividades están fuera del alcance de este proceso. Este trabajo identifica las actividades relacionadas con el proceso expuesto en [12], las que pueden utilizarse como guía de las actividades a realizar dentro de un proyecto de Explotación de Información. El primer paso de dicho proceso es la fase de Conceptualización del Negocio. Su objetivo es identificar el vocabulario de negocio y los procesos del mismo, con el fin de poder establecer un lenguaje común entre el equipo de proyecto y el interlocutor del negocio. La necesidad de establecer este vocabulario radica en que las metodologías de DM-BI han tenido dificultades con el grupo de usuarios respecto del léxico utilizado por los equipos de DM-BI [15]. Esta fase generará los casos de uso del negocio en estudio. Una vez concluida la Conceptualización del Negocio, comenzará la fase de Definición del Negocio cuyo objetivo es definir los, datos y repositorios de información afectados en los diferentes procesos de negocio, utilizando los identificados en la fase anterior y sus relaciones. Se definirá entonces, el vocabulario de que será utilizado como lenguaje de comunicación entre los interlocutores del negocio y los analistas de DM-BI y el modelo conceptual del mismo. También se identificarán los diferentes repositorios de información que posee la organización, los que almacenan datos relacionados con los identificados. La fase de Identificación de Procesos comienza una vez formalizadas las definiciones asociadas al negocio e identificados los repositorios de información. Su objetivo es definir la lista de problemas de información a resolver y los procesos de explotación de información que deberán ser utilizados para cada problema de inteligencia de información encontrado. 3.1 Fase de Conceptualización La Conceptualización es la fase del proceso de elicitación que será utilizada por el analista para comprender el lenguaje de la organización y los vocabularios específicos del negocio. Esta fase es crucial en el proyecto, ya que la información recopilada y las decisiones que se establezcan como resultado de esta fase afectarán al alcance del proyecto y a las soluciones que serán construidas por el mismo [12]. Los proyectos se inician con la identificación de los interesados en el mismo. De acuerdo a [14], deben identificarse los patrocinadores del proyecto, que son las personas que proveen de apoyo financiero o recursos y los usuarios, que serán los beneficiados por el proyecto. La Figura 2 refleja las diferentes actividades y productos de la fase de conceptualización y la Tabla 1 resume las principales entradas y salidas de la misma. Comprensión del Negocio Fig. 2: Fase de Conceptualización Tabla 1. Entradas y salidas de Fase de Conceptualización Fase Conceptualización usuarios a relevar Tarea Comprensión del Negocio de procesos Elaboración de modelos Productos Entrada Técnica de Productos de salida Transformación a Entrada Representación utilizar Salida Representación Formalización de proyecto usuarios a relevar Informe de relevamiento de Procesos Documento de Inicio de Proyecto lista de usuarios Informe de Documentación de Análisis de sponsors de proyecto Entrevistas Workshops Otros. Análisis de relevamiento Elaboración de Modelos usuarios a relevar Informe de relevamiento Documento de Casos de Uso Modelo de Casos de Uso lista de usuarios Informe de Modelo de Casos de Uso Los patrocinadores de proyectos pueden seleccionarse de acuerdo al conocimiento que tienen sobre la información que administra el negocio, las visiones estratégicas de la organización, los problemas de operatoria en los procesos de negocio, entre otros. Dependerá principalmente quién es el patrocinador del proyecto y qué problemáticas de información se tratarán de resolver. Inicialmente, se comenzará con un grupo reducido de personas que tengan una visión estratégica del negocio y luego en diferentes iteraciones se podrá ir profundizando en niveles más operativos. La actividad debe generar un listado de usuarios que serán relevados durante la actividad de de procesos de Negocio. Una vez identificados los usuarios principales, se procederá al relevamiento de los procesos de negocio y su modelado en casos de uso. Un proceso de negocio se puede definir como el proceso de utilización del negocio por parte de un cliente y cómo va realizando los diferentes flujos de eventos en el sistema, los cuales le permiten al cliente iniciar, llevar a cabo y completar el proceso de negocio [16]. Es una serie de tareas relacionadas que permiten producir un producto o servicio que le es útil a un cliente del negocio. Diferentes técnicas de elicitación de requerimientos software tradicionales pueden ser de utilidad para la recopilación de datos relacionados con el funcionamiento del negocio. Si bien estas técnicas son necesarias para el desarrollo del software a construir, no satisfacen las necesidades de los proyectos de Explotación de Información, ya que éstos requieren definir problemáticas del negocio en cuanto a información existente y disponible en la organización, y no las características que deben tener los sistemas software que almacenan dicha información. Las técnicas de elicitación de proyectos de desarrollo software enfocan su atención en los requerimientos de usuario, los cuales tienden a representar las necesidades de los mismos en cuanto a expectativas de funcionalidad, performance, usabilidad y otros atributos relacionados con el software a construir, tienden a definir qué es lo que el usuario espera del sistema. Dentro de las técnicas tradicionales para recopilación de información podemos mencionar: las entrevistas, la observación y los talleres de dominio [3]. La información obtenida se suele modelar mediante Casos 40

4 de Uso o lista de eventos [2], siendo estos modelos la base de los procesos de desarrollo de Software. Las técnicas enfocadas a obtener información de negocio y no de producto, pueden utilizarse en los proyectos de explotación de información. En la Elicitación de Requerimientos de Software se establece el concepto de Usuario de Producto campeón. Es la persona que sirve de interlocutor entre los diferentes usuarios y el analista de requerimientos. Es quien tiene una visión clara de lo que el nuevo sistema software hará [2]. En proyectos de Explotación de Información se deben identificar estos usuarios campeones, pero en vez de ser interlocutores, serán aquellos usuarios que conozcan el funcionamiento completo del proceso de negocio, independientemente de los sistemas software que soporten al proceso de negocio. Durante la actividad de Elicitación, el analista de negocio deberá enfocarse en la descripción de las distintas funciones que el negocio realiza. Debe dejar que el interlocutor del negocio exprese sus necesidades en el vocabulario que utiliza habitualmente. El analista deberá recopilar también las palabras específicas utilizadas en el negocio con el fin de obtener tanto una descripción de las diferentes tareas que se realizan en cada función, como así también la terminología utilizada en cada caso. Esta actividad podrá ser documentada mediante la descripción de los casos de uso, donde el caso corresponderá a la definición de la estructura de pasos que los usuarios del negocio realizan para completar su actividad. Este enfoque difiere del utilizado en el desarrollo de software en el cual el objetivo es describir el negocio y sus flujos de trabajo y no la interacción del usuario con el sistema software, como se utiliza tradicionalmente al modelo. Por lo tanto, el caso de uso es la secuencia de transacciones en un sistema [17] cuya tarea es producir un resultado de valor medible para un actor individual del sistema, que en el caso de estudio sería el cliente del negocio. La tarea del modelado de casos de uso utiliza la información obtenida de los relevamientos de negocio y genera en la última actividad de la fase, la elaboración de modelos. 3.2 Fase de Definición de Negocio Concluida la actividad de identificación de los asociados al negocio en estudio, se comienza a definirlo en términos de relación de, vocabulario y fuentes de información que dan soporte a los procesos de negocio. La fase de Definición de Negocio requiere como entrada los casos de uso definidos en la fase de Conceptualización. La Figura 3 refleja las actividades y productos de la fase y la Tabla 2 resume las principales entradas y salidas. Modelo de Casos de Uso Elaborar Diccionario Relacionar Fig. 3: Fase de Definición de Negocio Elaborar Repositorios Repositorios Tabla 2. Entradas y salidas de la Definición de Negocio Fase Definición de Negocio Tarea Elaborar Diccionario Relacionar Elaborar Mapa de Repositorios Productos Entrada Técnica de Productos de salida Transformación a Entrada Representación utilizar Salida Representación Documento de Casos de Uso Modelo de Casos de Uso Estructura de Concepto Plantillas de Mapas de Análisis del Caso de La primera tarea del analista será elaborar el diccionario de de los procesos de negocio. El concepto de diccionario es utilizado en metodologías estructuradas para la definición de las estructuras de los flujos de datos existentes entre los procesos, y que no necesariamente representan los utilizados en el negocio. La propuesta de trabajo es utilizar los definidos por la herramienta de Diccionario de Datos y expandir su uso hacia los procesos de Negocio. El objetivo es documentar los relevados en la fase de Conceptualización. La estructura de un concepto podrá ser definida de acuerdo con la Tabla 3. Tabla 3. Estructura de un concepto Elemento de la estructura Descripción Concepto Término que se desea definir. Definición Descripción del significado del concepto. Estructura de datos Definición de la estructura de los datos existentes en el concepto definido Relaciones relaciones con otros Procesos los procesos de negocio que hacen uso del concepto En este diccionario de se podrán identificar las diferentes entidades que forman parte del proceso de negocio. Otras representaciones han sido propuestas para poder documentar la información relevada [10]. Como objetivo secundario de esta actividad se encuentra el descubrimiento de sinónimos de. Los procesos de negocio hacen uso de un mismo concepto pero cada uno de ellos puede considerar características y condiciones diferentes para dicho concepto. Por ejemplo, un cliente para un área de preventa puede diferir del concepto de cliente para un área de soporte, siendo que en el primer caso el cliente puede ser una persona que aún no tenga servicios y, en el segundo caso sea cliente sólo aquella persona que ya ha adquirido un servicio. Estas diferencias en condiciones y características de los deben ser disipadas en esta fase. Con los definidos, el analista deberá realizar el modelo de dominio de negocio, mediante un modelo conceptual del mismo. Las técnicas de modelado de clases y de Entidad/Relación pueden ser utilizadas como base del modelo. El objetivo es abstraerse de la implementación en software de dichos y focalizarse en su relación a nivel negocio. El analista trabajará sobre la vinculación que existe entre los diferentes definidos en el diccionario, con los Uso Modelo de clases Análisis de relevamiento Repositorios Estructura de Concepto Plantillas de Mapas de repositorios 41

5 casos de uso identificados y podrá obtener así el modelo conceptual de dominio para los procesos de negocio. Una vez que completado el mapa, se comienzan a relevar los diferentes repositorios de información de la organización. Aquí se requiere de la participación de diferentes personas (roles) de la organización. Podemos mencionar a: los analistas de software, los administradores de base de datos y los responsables de las metodologías y procesos de negocio. Para obtener los datos requeridos por los procesos de Explotación de Información, en caso de existir modelos estructurados de análisis de los sistemas de información existentes en la organización, la identificación de donde se encuentran las implementaciones físicas del concepto de demora puede ser base del descubrimiento. Otra opción puede ser la identificación de sistemas de información (tanto software como manuales) que den soporte de información a los procesos de negocio. Es importante obtener el volumen de información de dichos repositorios, ya que son necesarios para poder definir qué procesos de Explotación de Información pueden ser aplicados en el proyecto. Con la información obtenida, se arma un mapa que relaciona los casos de uso del negocio, con los que el negocio define y en el repositorio en que son almacenados. Esta triple relación puede ser utilizada como base por cualquiera de las técnicas de procesos de Explotación de Información. 3.3 Fase de Identificación de procesos de Explotación de Información La fase de Identificación de Procesos de explotación de Información tiene como objetivo definir qué procesos de explotación de información resolverán los problemas identificados en los procesos de negocio. Existen diversos procesos que pueden ser utilizados [18-19], entre los que se encuentran: Descubrimiento de reglas de comportamiento (DRC) Descubrimiento de grupos (DDG) Ponderación de interdependencia de atributos (PIA) Descubrimiento de reglas de pertenencia al Grupo (DRPG) Ponderación de reglas de comportamiento o de Pertenencia a Grupos (PRC) Esta fase no requiere entradas previas, puede realizarse en paralelo junto con la fase de Conceptualización del dominio. Incluso, durante la actividad de relevamiento de procesos, se podrá realizar la actividad de identificación de problemas de negocio. La Figura 4 refleja las actividades y productos de la fase y la Tabla 4 identifica las entradas y salidas de las tareas. Identificar Problemas de Negocio Problemas Seleccionar proceso de explotación Proceso de Explotación Fase Identificación de Procesos de Explotación de Información Tabla 4. Entradas y salidas de la fase de Definición Tarea Identificar problemas de negocio Seleccionar proceso de explotación de información Productos Entrada Técnica de Productos de salida Transformación a Entrada Representación Salida Representación utilizar Formalización de proyecto Problemas Documento de Inicio de Proyecto problemas diccionario Análisis de documentación Léxico Extendido del lenguaje Problemas de negocio Proceso de explotación problemas de negocio Para poder definir qué técnica utilizar, se comienza con el relevamiento de los problemas que el usuario detecta en su negocio y se utiliza la información generada en las fases previas como fuente de información para la aplicación de las técnicas mencionadas. Al igual que en la fase de Conceptualización, pueden utilizarse las técnicas tradicionales de recopilación de información, enfocando la problemática en las necesidades de información de los diferentes usuarios de negocio. La lista de problemas debe ser priorizada y estar en lenguaje natural, expresado con el vocabulario de usuario, identificando los problemas más importantes según su criterio. Ejemplos de problemas que deben ser reflejados en esta lista: Contexto de negocio: Inmobiliaria Recibe una nueva casa para la venta y desea conocer qué clientes podrían estar interesados en ella. Contexto de negocio: Banco Tiene usuarios categorizados en grupos y se desea saber cuando llega un nuevo cliente, a qué grupo se debe asignarlo. Una vez definida la lista de problemas, se procede al análisis de los mismos. Este análisis se realiza mediante la utilización del modelo de Léxico Extendido del Lenguaje (LEL) [20]. El modelo LEL se obtiene del dominio del negocio, aplicando un conjunto de reglas para su construcción. Se han realizado trabajos sobre el enfoque LEL en el análisis de situaciones de negocio [21], y que puede ser utilizado como base del trabajo que se debe realizar en esta fase: descomponer el problema en los diferentes símbolos presentados en el modelo LEL. El modelo presenta 4 tipos generales de símbolos, símbolo sujeto, símbolo objeto, símbolo verbo y símbolo estado. Para poder definir qué técnica puede ser utilizada, se propone una tabla de decisión que analice las estructuras LEL, los identificados en la fase de Conceptualización, los repositorios de información existentes y las acciones que se desean resolver y en función de esa información, ofrecer qué técnica de explotación sería la más adecuada para el proyecto en cuestión. La Tabla 5 muestra qué condiciones se evalúan y las reglas que fueron identificadas como base para este trabajo. Como observaciones, se entiende como descubrimiento de sujeto a la búsqueda de sujetos o que no hayan sido identificados como parte del dominio relevado. de información a utilizar Fig. 4: Fase de Definición de Negocio 42

6 Tabla 5. Selección de proceso de Explotación Condiciones R01 R02 R03 R04 R05 Existen los identificados como objeto en algún repositorio de Información del negocio? Existen identificados como Objeto que no se encuentren en ningún repositorio? La acción representada por el verbo, Denota descubrimiento de Sujeto? Existen objetos asociables a Factores? Los factores requeridos, Se encuentran identificados? Los factores identificados, Pueden deducirse de la información existente en los repositorios? La acción representada por el verbo, Asocia Sujetos con Objetos? Se requiere analizar la incidencia de los factores para obtener un grupo de sujetos u objetos? Acciones NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO NO Se recomienda aplicar DRC DDG PIA DRP PRC Esta tabla tiene como objetivo poder decidir, mediante el análisis de la información obtenida acerca del negocio en estudio, qué proceso de Explotación de Información puede aplicarse en el proyecto. Es importante destacar que esta tabla de decisión incorporará nuevos conocimientos y nuevas reglas, con el fin de mejorar el criterio de selección de la técnica. Con la incorporación de más proyectos y más experiencia, se pueden refinar las reglas de las tablas y así lograr una mejor selección del proceso. Con la fase de Identificación del Proceso de Explotación de Información, se concluye la fase y el proceso. Las tareas posteriores dependerán del proceso definido y de las actividades establecidas en el proyecto. 4. PRUEBA DE CONCEPTO 4.1 Descripción del negocio Inmobiliaria del distrito federal Buenos Aires que trabaja en zonas residenciales de la ciudad. Dirigida por dos socios, dueños en partes iguales de la misma que publica las casas ofrecidas en su cartera en diferentes medios, principalmente en revistas locales de inmobiliarias. Las casas publicadas son de rango de clase media y media alta. Esta inmobiliaria no se dedica a la construcción de emprendimientos inmobiliarios aunque se asocia con otras inmobiliarias que sí lo hacen y ofrecen dichos emprendimientos como productos para vender. Tiene una única sucursal, donde trabajan todos sus empleados. Se cubren los roles de martillero, vendedores, administrativos, gestores de trámites y asesores de compra/venta. 4.2 Implementación del proceso Fase de Conceptualización: El primer paso del proceso es identificar interesados del proyecto y armar la lista de interesados que serán relevados. De este paso, con el breve conocimiento que tenemos de la empresa, podemos definir 3 interesados: los dueños y el vendedor. El segundo paso es establecer una serie de entrevistas con los roles seleccionados y relevar el funcionamiento del negocio. Ese funcionamiento puede ser documentado en informes de relevamiento. La inmobiliaria se focaliza principalmente en el alquiler y venta de inmuebles. Si una persona se acerca a ofrecer su inmueble para la venta, el martillero realiza una tasación del inmueble ofrecido. Se presenta dicha tasación al cliente y si está de acuerdo con la misma, se establecen las condiciones en las que se realizará la venta. Cuando una persona presenta interés en comprar una casa, los vendedores completan una planilla con los datos de la persona y las características que debe cumplir el inmueble. Si existen inmuebles que cumplan con el criterio solicitado, se presentan los mismos a la persona. La inmobiliaria considera como clientes aquellas personas que tienen ofrecida una casa para vender y a las personas que ya iniciaron un proceso de compra de una casa ofrecida, y considera interesados a aquellas personas que están consultando por los inmuebles ofertados o están buscando inmuebles para comprar. Si los interesados acuerdan la compra de un inmueble, serán clientes de la inmobiliaria y se da comienzo al proceso de compra de inmuebles. La información de los clientes e inmuebles se almacena en un archivo Excel. El tercer paso implica el análisis de la información relevada y su modelado en casos de uso. Con la información relevada podríamos identificar los siguientes casos de uso de negocio: Vender Inmuebles, que refleja la acción de venta del inmueble por parte de una persona y gestionada por la inmobiliaria Comprar Inmuebles, que refleja la acción de compra por parte de una persona de un inmueble ofrecido por la inmobiliaria Ofrecer Inmuebles, que refleja la acción de mostrar los inmuebles que dispone para venta la inmobiliaria a los interesados. Este es un breve análisis de los casos de uso identificados. Un trabajo más exhaustivo detallaría más la información de cada caso de uso. Fase de Definición de Negocio: El cuarto paso consiste en la elaboración del diccionario de del negocio. Del relevamiento, podemos identificar los indicados en la Tabla 6. Tabla 6. identificados en la definición Cliente Vendedor Persona que ofrece un inmueble para la venta Estructura: Nombre y Apellido Documento Identidad Información de Contacto Relaciones: Inmueble Tasación Procesos : Vender Inmueble Tasación Valuación del inmueble para su venta Estructura: Valor Tasación (Numérico) Identificador de Inmueble Moneda Tasación 43

7 Cliente Vendedor Persona que ofrece un inmueble para la venta Relaciones: Inmueble Cliente Procesos Vender Inmueble Ofrecer Inmueble El siguiente paso consiste en el armado de un modelo de relación de los definidos. La Figura 5 muestra brevemente las relaciones existentes entre los identificados. Fig. 5: Modelo de identificados en el caso El sexto paso del proceso implica identificar los repositorios donde la información asociada a los se encuentra almacenada. Del relevamiento obtenido, podemos identificar dos repositorios: la planilla de interesados y la planilla Excel de clientes e inmuebles. El séptimo paso es la identificación de problemas de negocio. Esta identificación se puede realizar junto con el segundo paso, durante el relevamiento del negocio. La lista debe identificar los problemas en el lenguaje del usuario. De un segundo relevamiento surge que uno de los problemas de la inmobiliaria es: cuando se recibe una nueva casa para la venta deseamos conocer qué clientes podrían estar interesados en ella. La lista puede tener varios problemas. Cada problema debe ser priorizado y estar identificado unívocamente. Con los problemas identificados, se continúa con el octavo paso, el análisis LEL de los problemas. En este caso, el análisis identifica (entre otros) los símbolos expresados en la Tabla 7. Tabla 7. Símbolos asociados al problema de la inmobiliaria Inmueble [Objeto] Noción - Es el objeto que vende la inmobiliaria Impacto - Lo vende un cliente de la inmobiliaria Ofrecer una casa [Verbo] Noción - Es la acción de presentarle una casa en venta a un cliente Impacto - La casa debe satisfacer los criterios de los interesados Cliente [Sujeto] Noción - Persona que está interesada en comprar casa - Persona que vende la casa Impacto - Completa un formulario de criterios de compra - Establece lineamientos de la zona donde trabaja Interesado [Estado] Noción - Es un estado que tiene un cliente cuando una casa ofrecida cumple con sus expectativas Impacto - La casa ofrecida se muestra al interesado Con el análisis LEL obtenido y la información de los repositorios y, determinamos qué proceso de Explotación de Información se puede aplicar. Para ello, se utiliza como guía la Tabla 5 y se analiza la regla obtenida. El resultado del análisis se ve en la Tabla 8. Tabla 8. Resultado del análisis LEL Condiciones Existen los identificados como objeto en algún repositorio de Información del negocio? Existen identificados como Objeto que no se encuentren en ningún repositorio? La acción representada por el verbo, Denota descubrimiento de Sujeto? Existen objeto asociables a Factores? Los factores requeridos, Se encuentran identificados? Los factores identificados, Pueden deducirse de la información existente en los repositorios? La acción representada por el verbo, Asocia Sujetos con Objetos? Se requiere analizar la incidencia de los factores para obtener un grupo de sujetos u objetos? Acciones Aplicar: Regla NO NO DRC 5. CONCLUONES Este trabajo presenta una propuesta de proceso para la elicitación de requerimientos en proyectos de Explotación de Información y cómo utilizar técnicas existentes de elicitación de requerimientos, pero adaptándolas dichos proyectos. El proceso se descompone en 3 fases, donde se analiza el negocio en estudio (Fase de Conceptualización), se trata de armar un modelo del negocio y definirlo para poder comprender el alcance del mismo y la información que administra (Fase de Definición de Negocio) y por último, los problemas que los usuarios del negocio identifican y conociendo los y repositorios de información que administran, se presenta una herramienta para poder establecer qué técnica de explotación de información puede ser aplicada para un proyecto de explotación de información (Fase de Identificación de Procesos de Explotación de Información). Como futuras líneas de trabajo se están identificando diferentes casos para la contrastación empírica del proceso propuesto con énfasis en la validación de la tabla de decisión referida en la sección REFERENCIAS [1] Sommerville, I. & Sawyer, P Requirements Engineering: A Good Practice Guide. Wiley & Sons. [2] Wiegers, K Software Requirements. Microsoft Press. [3] Lauesen, S Software Requirements. Styles and Techniques. Pearson Education. [4] Pollo-Cattaneo, F. et al Proceso de Educción de Requisitos en Proyectos de Explotación de Información. En Aguilar R. et al (Eds.), Ingeniería de Software e 44

8 Ingeniería del Conocimiento: Tendencias de Investigación e Innovación Tecnológica en Iberoamérica, Alfaomega. [5] Pollo-Cattaneo, F. et al Ingeniería de Proyectos de Explotación de Información. Proceedings XII Workshop de Investigadores en Ciencias de la Computación, [6] Pytel, P. et al Ingeniería de Requisitos Basada en Técnicas de Ingeniería del Conocimiento. Proceedings XIII WICC, [7] Chapman P. et al CRISP-DM 1.0 Step-by-step data mining guide. The CRISP-DM consortium. [8] García-Martínez, R. et al Information Mining Processes Based on Intelligent Systems. Proceedings of II International Congress on Computer Science and Informatics, [9] Pyle, D Business Modeling and Business Intelligence. Morgan Kauffmann Publishers. [10] SAS SAS Enterprise Miner: SEMMA. Online: alytics/datamining/miner/semma.html. [Jun. 2011]. [11] Pollo-Cattaneo, F. et al Metodología para Especificación de Requisitos en Proyectos de Explotación de Información. Proceedings XI WICC, [12] Kimball, R. et al The Data Warehouse Lifecycle Toolkit. Wiley & Sons. [13] Vanrell, J.; Bertone, R. & García-Martínez, R Modelo de Proceso de Operación para Proyectos de Explotación de Información. Proceedings XVI Congreso argentino de ciencias de la computación, [14] William, R A Guide to the Project Management Body of Knowledge. PMI Publishing. [15] Britos, P.; Dieste, O. & García-Martínez, R Requirements Elicitation in Data Mining for Business Intelligence Projects. En Avison, D. et al (Eds.), Advances in Information Systems Research, Education and Practice, [16] Jacobson, I.; Ericsson, M. & Jacobson, A The Object Advantage. Business Process Reengineering with Object Technology, 98. Addison Wesley Publishing Company. [17] Jacobson, I.; Ericsson, M. & Jacobson, A The Object Advantage. Business Process Reengineering with Object Technology, 101. Addison Wesley Publishing Company. [18] García-Martínez, R. et al Towards an Information Mining Engineering. In Zapata, J. C. M. et al. (Eds.), Software Engineering, Methods, Modeling and Teaching, Editorial Universidad de Medellín. [19] Pollo-Cattaneo, F. et al Ingeniería de Procesos de Explotación de Información. En Aguilar, R.; Díaz, J. & Gómez, G. (Eds.), Ingeniería de Software e Ingeniería del Conocimiento: Tendencias de Investigación e Innovación Tecnológica en Iberoamérica, Alfaomega. [20] Leite, J. C. S. P Notas de Aula. Material del curso de Ingeniería de Requisitos. [21] Fresno, M. et al Derivación de objetos utilizando LEL y Escenarios en un caso real. Online: [Nov. 2011]. 45