Facultad de Informáticaoa.upm.es/1946/1/JOSE_ALBERTO_GALLARDO_ARANCIBIA.pdfdel proyecto, clarificar...

DEPARTAMENTO DE LENGUAJES Y SISTEMAS INFORMÁTICOS E INGENIERÍA DE SOFTWARE

Facultad de Informática

“Metodología para la Definición de Requisitos en Proyectos de Data Mining (ER-DM)”

Autor

José Alberto Gallardo Arancibia Ingeniero Civil Industrial

Director

Óscar Marbán Gallego Doctor en Informática

Año: 2009

i

"Entre los grandes placeres que nos brinda la vida, está el superar las dificultades paso a paso, escalando uno a uno los peldaños del éxito, concibiendo nuevos deseos y viéndolos realizados." Samuel Johnson

iii

Agradecimientos Las siguientes líneas; escritas de corazón, con humildad y palabras sencillas, pretenden expresar con la mayor sinceridad mis agradecimientos a todas las personas que posibilitaron con su colaboración y consejos, la conclusión de mi trabajo de Tesis Doctoral. En particular, quiero hacer especial mención de tres personas amigas que fueron muy importantes en el desarrollo del mismo. En primer lugar, mi profesor Director de Tesis, el Dr. Óscar Marbán G., con quien he tenido el honor de trabajar bajo su acertada conducción desde la ejecución de mi trabajo de investigación tutelada, hasta el largo y trabajoso desarrollo de mi Tesis Doctoral. Gracias por su confianza, por su eficiente y eficaz conducción, por sus prontas y oportunas correcciones, y principalmente por el permanente apoyo y actitud positiva hacia mi desempeño. Apoyo que fue fundamental para transitar con el mayor optimismo y entusiasmo el largo y pesado camino hacia la conclusión de mi tesis. Profesor, mi eterna gratitud por todas sus enseñanzas. En segundo lugar, quiero mencionar a mi colega y amigo, el Dr. Claudio Meneses V. Estimado Claudio: gracias por tu asesoría profesional, tu amistad y la comprometida colaboración que siempre me brindaste durante todo el proceso de mi perfeccionamiento. Y en tercer lugar, a mi estimada y querida amiga y colega M. Sc. Gloria Giacaman J. Glorita: gracias por tu constante disposición y ayuda en los muchos momentos en que tuviste que sacrificar tus horas de descanso, para brindarme una mano. No quiero seguir mencionando a muchas a otras personas que colaboraron en mi tarea dentro de sus respectivas competencias para así no omitir a ninguna. Finalmente, y en otra dimensión, a mi familia y a Dios Nuestro Señor que me da vida y salud.

v

Resumen

En años recientes, se ha dado inicio al desarrollo de una cantidad importante de proyectos de Data Mining y diversos estudios estiman que esta cantidad, se incrementará en el futuro inmediato. Las razones que estimulan este crecimiento son numerosas; fundamentalmente, la gran cantidad de datos que se generan y almacenan a diario en las bases de datos de las organizaciones; la imposibilidad de procesar y analizar estos grandes volúmenes de datos mediante métodos clásicos de análisis de datos y la necesidad de las empresas de descubrir en ellos, patrones, relaciones, reglas o asociaciones útiles, que aporten información relevante o conocimiento para el proceso de toma de decisiones. Cuando se inicia un proyecto de Data Mining, la educción, el análisis y el modelado de los requisitos del usuario (proceso de Ingeniería de Requisitos), constituyen actividades relevantes para el éxito del proyecto. Sin embargo estas actividades, normalmente son las menos exploradas debido a la inexistencia de técnicas, procedimientos o métodos ad-hoc para estos propósitos. Si bien es cierto, que en la tarea “Evaluación de la Situación”, correspondiente a la primera fase (Comprensión del Negocio) del modelo de proceso estándar CRISP-DM (Cross Industry Standard Process for Data Mining), uno de los procesos más ampliamente utilizados en los ámbitos industrial y académico, se propone como actividades iniciales, emitir un inventario de los recursos y establecer los requisitos, supuestos y restricciones del proyecto, no se menciona, cómo estas tareas deben ser desarrolladas, ni mediante qué instrumentos. En consecuencia, dada la importancia de contar con un documento eficaz de especificación de requisitos antes de dar inicio a un proyecto de Data Mining y la necesidad de disponer de un procedimiento metodológico explícito para obtener este documento, se ha desarrollado el presente trabajo de tesis doctoral, el cual propone una metodología para definir los requisitos de un proyecto de Data Mining. Esta metodología está centrada en las actividades fundamentales de la Ingeniería de Requisitos y se focaliza en la propuesta de un Framework que consiste de un proceso iterativo, compuesto por un conjunto de fases, que van desde la fase de comprensión del dominio de negocio, la de modelado del proceso decisional en la organización, hasta la fase de construcción del documento final de requisitos. Para el desarrollo de cada una de las fases del framework, se proponen un conjunto de técnicas y artefactos. La metodología, ha sido ensayada en el desarrollo de un proyecto de Data Mining; su aplicación ha permitido establecer lazos de confianza entre el cliente y desarrolladores del proyecto, clarificar las ideas acerca del problema y sus soluciones, mediante el modelado del proceso de negocios decisional, la posterior educción y validación de los requisitos, la observación por parte del cliente de resultados preliminares que permitieron la necesaria retroalimentación y finalmente la redacción conjunta del documento final de contrato, el cual fue suscrito de conformidad por el cliente y los desarrolladores del proyecto.

vii

Abstract In the last few years, the development of a significant amount of Data Mining projects has been done and the forecast is that this quantity will increase in the near future. The causes that stimulate this increase are many; mainly, the great amount of data that is daily generated and stored in the organization’s data bases, the impossibility to process and analyze big data volumes with classical analysis methods and the need in the organizations to discover patterns, relations, rules and useful associations in them, that would provide relevant information or knowledge for the decision making process. When the challenge of beginning a Data Mining Project is taken, the elicitation, analysis and modeling of the user’s requirements (Requirements Engineering process) become outstanding activities for the project success. Nevertheless, these activities are the less explored, due to the inexistence of ad-hoc techniques, procedures or methods for these purposes. Although in the Situation Assessment task, that belongs to the first phase (Business Understanding), of the CRISP-DM (Cross Industry Standard Process for Data Mining) standard process, one of the most used process in the industrial and academic environment, a resource inventory and the establishment of the project’s requirements, assumptions and restrictions as initial activities are proposed; there is no mention on how these tasks should be carried out, neither with which instruments. Consequently, due to the significance of having an efficient requirements specification document before beginning a Data Mining project, and the need of having an explicit methodological procedure to make this document, the present doctoral project thesis has been developed, in which, a methodology is proposed for defining the requirements in a Data Mining project. This methodology is centered in the requirement’s engineering essential activities and it is focused in a Framework proposal that is composed of an iterative and interactive process, that consists of a set of phases, that go from the comprehension of the business domain phase, the decisional process modeling in the organization, to the construction phase of the final requirement document. For the development of each of the framework phases, a set of techniques and devices are proposed. The methodology has been proved in the development of a Data Mining project; its application has allowed the establishment of trust ties between the client and the project developers, to clarify the ideas about the problem and its solutions by means of the decisional business process modeling, the subsequently elicit and validation requirements, the client remarks about the preliminary results that allowed the necessary feedback and finally the joint writing of the final contract document, which was subscribed in accordance with the client and the project developers.

ix

ÍNDICE DE CONTENIDOS

CAPÍTULO I ................................................................................................ 1 Introducción ................................................................................................. 1

1.1. Antecedentes. .................................................................................................. 3

1.2. Objetivos del trabajo. ..................................................................................... 6

1.3. Aportaciones. .................................................................................................. 7

1.4. Estructura general. ......................................................................................... 8

CAPÍTULO II ............................................................................................... 9 Marco Teórico .............................................................................................. 9

2.1. Data Mining. ................................................................................................. 11 2.1.1. Introducción ........................................................................................................... 11 2.1.2. Tipos de problemas resueltos por Data Mining. .................................................... 13 2.1.3. Logros y desafíos de Data Mining. ........................................................................ 14 2.1.4. Modelos de proceso para proyectos de Data Mining (DM). ................................. 15

2.1.4.1. CRISP-DM (Cross Industry Standard Process for Data Mining). ............................. 15

2.2. Ingeniería de Requisitos (IR). ...................................................................... 24 2.2.1. Introducción. .......................................................................................................... 24 2.2.2. Modelos de proceso de Ingeniería de Requisitos. ................................................. 28

2.2.2.1. Ingeniería de Requisitos en Ingeniería del Software. ................................................ 28 2.2.2.2. Ingeniería de Requisitos en Data Warehouse. ........................................................... 31 2.2.2.3. Ingeniería de Requisitos en proyectos de Business Intelligence. .............................. 35 2.2.2.4. Ingeniería de Requisitos en e-commerce. .................................................................. 36 2.2.2.5. Ingeniería de Requisitos en Automoción. ................................................................. 39 2.2.2.6. Ingeniería de Requisitos en Telecomunicaciones. ..................................................... 42 2.2.2.7. Ingeniería de Requisitos en otras áreas del conocimiento. ........................................ 43

2.2.3. Metodologías en Ingeniería de Requisitos. ............................................................ 43 2.2.3.1. DorCU. ...................................................................................................................... 44 2.2.3.2. Bibliotecas. ................................................................................................................ 46 2.2.3.3. Ancora. ...................................................................................................................... 49 2.2.3.4. IBRA. ........................................................................................................................ 49 2.2.3.5. KBSA. ....................................................................................................................... 50 2.2.3.6. VORD ....................................................................................................................... 52 2.2.3.7. VOLERE ................................................................................................................... 53

2.2.4. Técnicas de Ingeniería de Requisitos. ................................................................... 56 2.2.4.1. Brainstorming (lluvia de ideas). ................................................................................ 57 2.2.4.2. Entrevistas y Cuestionarios. ...................................................................................... 58 2.2.4.3. Observación in situ. ................................................................................................... 60 2.2.4.4. Etnografía. ................................................................................................................. 60 2.2.4.5. Demostración de tareas. ............................................................................................ 60 2.2.4.6. Técnica JAD (Desarrollo Conjunto de Aplicaciones). .............................................. 60 2.2.4.7. Prototipos. ................................................................................................................. 62 2.2.4.8. Proceso de Análisis Jerárquico (AHP). ..................................................................... 63 2.2.4.9. Puntos de Vista.......................................................................................................... 64 2.2.4.10. Casos de Uso. ............................................................................................................ 64 2.2.4.11. Sistemas Existentes. .................................................................................................. 66 2.2.4.12. Estudio de Documentos existentes. ........................................................................... 66 2.2.4.13. Maestro/Aprendiz. ..................................................................................................... 66 2.2.4.14. Análisis de Protocolos. .............................................................................................. 67

x

2.2.4.15. Repertory Grids. ........................................................................................................ 67 2.2.4.16. Laddering. ................................................................................................................. 68 2.2.4.17. Card Sorting. ............................................................................................................. 69

2.2.5. Notaciones para definición de Requisitos. ........................................................... 69 2.2.5.1. Lenguaje de descripción de programas. .................................................................... 71 2.2.5.2. SADT. ....................................................................................................................... 72 2.2.5.3. Notación UML para casos de uso. ............................................................................ 73 2.2.5.4. Z. ............................................................................................................................... 75 2.2.5.5. VDM. ........................................................................................................................ 77 2.2.5.6. B. ............................................................................................................................... 78

2.2.6. Documento de Requisitos. .................................................................................... 79

2.3. El proceso de toma de decisiones ................................................................ 80 2.3.1. Toma de decisiones en una organización. ............................................................. 81 2.3.2. Etapas del proceso de toma de decisiones. ............................................................ 82 2.3.3. Modelos de toma de decisiones. ............................................................................ 84

2.4. Modelos de Negocio. ..................................................................................... 86 2.4.1. Introducción. .......................................................................................................... 86 2.4.2. Estructura organizacional. ..................................................................................... 87

2.4.2.1. Unidades Funcionales Típicas. .................................................................................. 87 2.4.3. El modelo de negocios. .......................................................................................... 89

2.4.3.1. Dominios de aplicación del concepto de Modelo de Negocios. ................................ 90 2.4.3.2. Aportes del concepto de Modelo de Negocios, en la aplicación de la Ingeniería de Requisitos a proyectos de Data Mining. ....................................................................................... 91 2.4.3.3. Componentes Elementales de un Modelo de Negocios. ........................................... 93 2.4.3.4. Notaciones para la representación de Modelos de Negocios. ................................. 100

CAPÍTULO III ......................................................................................... 109 Planteamiento del Problema .................................................................... 109

3.1. Planteamiento ............................................................................................. 111

3.2. Hipótesis de trabajo .................................................................................... 113

3.3. Objetivos del trabajo .................................................................................. 114 3.3.1. Objetivo General. ................................................................................................ 114 3.3.2. Objetivos Específicos. ......................................................................................... 114

CAPÍTULO IV .......................................................................................... 115 Metodología para la Especificación de Requisitos en proyectos de Data Mining (ER-DM) ...................................................................................... 115

4.1. Introducción. ............................................................................................... 117

4.2. Descripción de la Metodología ER-DM. ................................................... 118 4.2.1. Fase de comprensión del dominio de negocio. .................................................... 121

4.2.1.1. Escenario actual del negocio (background) y objetivos estratégicos de la organización. .............................................................................................................................. 125 4.2.1.2. Estrategias, recursos y factores condicionantes....................................................... 129

4.2.2. Fase de definición de requisitos organizacionales preliminares. ......................... 134 4.2.3. Fase de construcción del modelo de negocios decisional. ................................... 141 4.2.4. Fase de modelado de requisitos. .......................................................................... 150

4.2.4.1. Especificación de los requisitos. ............................................................................. 150 4.2.4.2. Taxonomía para requisitos en Proyectos de Data Mining. ...................................... 151 4.2.4.3. Modelado de los requisitos. ..................................................................................... 153

4.2.5. Fase de creación de modelos de prueba. .............................................................. 155 4.2.6. Fase de redacción del documento final de contrato. ............................................ 156

xi

CAPÍTULO V ........................................................................................... 159 Aplicación de la Metodología (ER-DM) en el Desarrollo de un Caso Práctico ..................................................................................................... 159 (Ensayo de la Solución) ........................................................................... 159

5.1. Introducción. ............................................................................................... 161

5.2. La organización. ......................................................................................... 161

5.3. Aplicación de la metodología ER-DM. ..................................................... 162 5.3.1. Fase de comprensión del dominio de negocio. .................................................... 162 5.3.2. Fase de identificación de requisitos organizacionales. ........................................ 166 5.3.3. Fase de construcción del modelo de negocios decisional. ................................... 168 5.3.4. Fase de construcción del modelo de requisitos. .................................................. 179 5.3.5. Fase de construcción de modelos de prueba. ....................................................... 186 5.3.6. Redacción documento final de contrato. ............................................................. 187

5.4. Análisis de resultados. ................................................................................ 188

CAPÍTULO VI .......................................................................................... 197 Conclusiones y Trabajo Futuro. .............................................................. 197

6.1. Conclusiones. ............................................................................................... 199

6.2. Trabajo futuro. ........................................................................................... 202

BIBLIOGRAFÍA ...................................................................................... 203 ANEXO A: FASE DE COMPRENSIÓN DEL DOMINIO DE NEGOCIO. ............................................................................................... 219 ANEXO B: FASE DE IDENTIFICACIÓN DE REQUISITOS ORGANIZACIONALES. ......................................................................... 239 ANEXO C: FASE DE CONSTRUCCIÓN DE MODELOS DE PRUEBA. ................................................................................................................... 247

C1. Comprensión de los datos .......................................................................... 247 C1.1. Recopilación de los Datos: ...................................................................................... 247 C1.2. Descripción de los Datos: ....................................................................................... 250

C2. Preparación de los datos ............................................................................ 253

C3. Modelado ..................................................................................................... 257

ANEXO D: DOCUMENTO FINAL DE CONTRATO. ......................... 267 FICHA DEL DOCUMENTO ....................................................................... i ÍNDICE ......................................................................................................... v 1. INTRODUCCIÓN ................................................................................ vii

1.1. Propósito. ....................................................................................................... vii

1.2. Alcance. .......................................................................................................... vii 1.2.1. Objetivo .................................................................................................................... vii

1.3. Personal involucrado. .................................................................................. viii

xii

1.4. Definiciones, Acrónimos y Abreviaturas. ..................................................... viii

1.5. Referencias. ..................................................................................................... viii

1.6. Visión General del Documento. ....................................................................... ix

2. DESCRIPCIÓN GENERAL ................................................................. xi 2.1. Perspectiva del Producto. ................................................................................ xi

2.2. Funciones del Producto. ................................................................................... xi

2.3. Características de los Usuarios. ....................................................................... xi

2.4. Restricciones. .................................................................................................. xii

2.5. Suposiciones y Dependencias. ........................................................................ xii

3. REQUISITOS ESPECÍFICOS .......................................................... xiii 3.1 Requisitos Funcionales. ................................................................................... xiii

4. APÉNDICES ..................................................................................... xxiii APÉNDICE A ........................................................................................................ xxiii

ÁPENDICE B .......................................................................................................... xxv

APÉNDICE C ....................................................................................................... xxvii

APÉNDICE D ........................................................................................................ xxix

xiii

ÍNDICE DE FIGURAS Figura No. 1.1. Proceso de KDD ([Hernández, 2004]). .............................................................................. 3 Figura No. 1.2. Metodologías utilizadas en Data Mining ([kdnuggets, 2007]). .......................................... 5 Figura No. 1.3. Fase de comprensión del negocio ([CRISP-DM, 2000]). ................................................... 6 Figura No. 2.1. El proceso de KDD ([Cabena, 1997]). ............................................................................. 11 Figura No. 2.2. El proceso de Data Mining ([Caniupan, 2000]). .............................................................. 12 Figura No. 2.3. Metodologías utilizadas en Data Mining ([kdnuggets, 2007]). ........................................ 16 Figura No. 2.4. Esquema de los 4 niveles de CRISP-DM ([CRISP-DM, 2000]). ...................................... 16 Figura No. 2.5. Modelo de proceso CRISP–DM ([CRISP-DM, 2000]). .................................................... 17 Figura No. 2.6. Fase de comprensión del negocio ([CRISP-DM, 2000]). ................................................. 18 Figura No. 2.7. Fase de comprensión de los datos ([CRISP-DM, 2000]). ................................................ 19 Figura No. 2.8. Fase de preparación de los datos ([CRISP-DM, 2000]). ................................................. 20 Figura No. 2.9. Fase de modelado ([CRISP-DM, 2000]). ......................................................................... 21 Figura No. 2.10. Fase de evaluación ([CRISP-DM, 2000]). ..................................................................... 23 Figura No. 2.11. Fase de implementación ([CRISP-DM, 2000]). ............................................................. 24 Figura No. 2.12. Esquema general del proceso de Ingeniería de Requisitos (elaborado en base a [Davyt, 2001]) ......................................................................................................................................................... 29 Figura No. 2.13. Proceso de Ingeniería de Requisitos ([Sommerville, 2002]). ......................................... 30 Figura No. 2.14. Modelo en Espiral del proceso de IR ([Kotonya, 1998]). ............................................... 31 Figura No. 2.15. Etapas de la técnica DWARF ([Rilston, 2003]). ............................................................. 32 Figura No. 2.16. Proceso de elicitación de requisitos ([Britos, 2008]). .................................................... 35 Figura No. 2.17. Proceso de diseño de e-business ([Gordijn, 2000]). ....................................................... 36 Figura No. 2.18. Conceptos claves para representar un modelo de negocios de una manera semi-formal ([Gordijn, 2000]). ....................................................................................................................................... 38 Figura No. 2.19. Porcentaje de costes en el desarrollo de la electrónica ([Weber, 2003]). ...................... 40 Figura No. 2.20. Diseño de un servicio de telecomunicaciones utilizando RATS ([Gerhard, 1997]). ...... 42 Figura No. 2.21. Fases de la metodología DoRCU ([Báez, 2002]). .......................................................... 44 Figura No. 2.22. Tareas realizadas en la fase de Elicitación ([Báez, 2002]). ........................................... 45 Figura No. 2.23. Contexto de “biblioteca desde el punto de vista de un empleado” ([Richards, 2000]). . 48 Figura No. 2.24. Estructura cíclica del modelo (elaborado en base a [Antón, 1994]). ............................. 49 Figura No. 2.25. Proceso de ingeniería de software basado en conocimiento ([DACS, 2008]). ............... 51 Figura No. 2.26. Proceso VORD ([Medina, 2004]). .................................................................................. 53 Figura No. 2.27. Descripción gráfica del Shell de VOLERE [Robertson, 1999]. ...................................... 54 Figura No. 2.28. Mapa Simplificado del Proceso de Requisitos de VOLERE [Robertson, 1999]. ............ 55 Figura No. 2.29. Uso Lenguaje de Descripción de Programas [Sommerville, 2005]. .............................. 71 Figura No. 2.30. Representación gráfica de un elemento básico ([Ross, 1977]). ...................................... 72 Figura No. 2.31. Ejemplo de utilización de SADT [Lasserre, 2006]. ........................................................ 73 Figura No. 2.32. Representación gráfica de la notación (elaborado en base a [Larman, 2003], [Glinz, 2000]). ........................................................................................................................................................ 74 Figura No. 2.33. Ejemplo de utilización de Casos de Uso [Domínguez, 2008]. ........................................ 74 Figura No. 2.34. Ejemplo de utilización de la notación Z [Vallecillo, 2008]. ........................................... 76 Figura No. 2.35. Ejemplo de utilización de la notación VDM [Suderman, 1997]. .................................... 77 Figura No. 2.36. Ejemplo de utilización de la notación B [Martins, 2005]. .............................................. 78 Figura No. 2.37. El proceso de toma de decisiones ([Laudon, 2004]). ..................................................... 84 Figura No. 2.38. Nexo entre los Expertos de negocio y desarrolladores de Data Mining (elaborado en base a [Osterwalder, 2005]). ..................................................................................................................... 92 Figura No. 2.39. El Modelo de Negocios y los Objetivos Estratégicos (elaborado en base a [Osterwalder, 2005]). ........................................................................................................................................................ 93 Figura No. 2.40. Innovación del producto ([Lagha, 2004]). ..................................................................... 98 Figura No. 2.41. Gestión de la Infraestructura ([Lagha, 2004]). ............................................................. 98 Figura No. 2.42. Capital de relación con el cliente ([Lagha, 2004]). ....................................................... 98 Figura No. 2.43. Aspectos financieros ([Lagha, 2004]). ........................................................................... 99 Figura No. 2.44. Extensiones de UML para modelado de negocios [elaborado en base a [Johnston, 2004]). ...................................................................................................................................................... 101 Figura No. 2.45. Conjunto de elementos básicos de BPMN ([White, 2006])........................................... 103 Figura No. 2.46. Primitivas básicas del Framework i* (elaborado en base a [Yu, 2001]). .................... 106 Figura No. 4.1. Dimensiones del proceso de elicitación de requisitos ([Kotonya, 1998]). ..................... 118

xiv

Figura No. 4.2. Primera fase de la guía de desarrollo CRISP-DM ([CRISP-DM, 2000]). ..................... 119 Figura No. 4.3. Framework para la especificación de Requisitos (elaboración propia). ........................ 120 Figura No. 4.4. Modelo TWIN PEAKS ([Nuseibeh, 2001]). .................................................................... 120 Figura No. 4.5. Fase de comprensión del dominio de negocio (elaboración propia). ............................. 122 Figura No. 4.6. Información sobre el dominio del Negocio (elaboración propia). ................................. 123 Figura No. 4.7. Proceso orientado a elicitar información sobre el dominio del Negocio (elaboración propia). ..................................................................................................................................................... 124 Figura No. 4.8. Definición de requisitos organizacionales (elaboración propia). ................................. 134 Figura No. 4.9. Actividades presentes en la fase de definición de Requisitos Organizacionales (elaboración propia). ............................................................................................................................... 135 Figura No. 4.10. Modelo de Negocio Decisional (elaboración propia). ................................................. 141 Figura No. 4.11. Aportes del modelo de negocio (elaborado en base a [Osterwalder, 2005]). ............. 142 Figura No. 4.12. Fases del proceso de Modelado de Negocio Decisional (elaboración propia). .......... 143 Figura No. 4.13. Fases del proceso construcción del modelo (elaboración propia). ............................. 148 Figura No. 4.14. Modelo de requisitos (elaboración propia). ................................................................ 150 Figura No. 4.15. Actividades en el modelado de los requisitos (elaborado en base a [Santander, 2002]). .................................................................................................................................................................. 154 Figura No. 4.16. Modelos de prueba (elaboración propia). ................................................................... 155 Figura No. 4.17. Documento de contrato (elaboración propia). ............................................................ 156 Figura No. 5.1. Framework para la especificación de requisitos (elaboración propia). ......................... 162 Figura No. 5.2. Comprensión del dominio del negocio (elaboración propia). ....................................... 163 Figura No. 5.3. Secuencia de actividades involucradas en la fase de comprensión del Dominio de Negocio (elaboración propia). ................................................................................................................. 163 Figura No. 5.4. Organigrama Universidad Católica del Norte ............................................................... 165 Figura No. 5.5. Identificación de Requisitos Organizacionales (elaboración propia). .......................... 166 Figura No. 5.6. Actividades presentes en la fase de definición de Requisitos Organizacionales (elaboración propia). ............................................................................................................................... 166 Figura No. 5.7. Modelo de Negocio Decisional (elaboración propia). ................................................... 169 Figura No. 5.8. Actividades del proceso de Modelado de Negocio Decisional (elaboración propia). ... 169 Figura No. 5.9. Fases del proceso construcción del modelo (elaboración propia). ............................... 172 Figura No. 5.10. Primitivas básicas del Framework i* (elaborado en base a [Yu, 2001]). .................... 173 Figura No. 5.11. Modelo de Dependencias Estratégicas de primer nivel (elaboración propia). ........... 174 Figura No. 5.12. Modelo de Dependencias Estratégicas de segundo nivel (elaboración propia). ......... 175 Figura No. 5.13. Modelo de Dependencias Estratégicas de tercer nivel (elaboración propia). ............. 176 Figura No. 5.14. Modelo de Razones Estratégicas (elaboración propia). .............................................. 177 Figura No. 5.15. Modelo de Razones Estratégicas con actor Sistema incorporado (elaboración propia). .................................................................................................................................................................. 178 Figura No. 5.16. Modelo de requisitos (elaboración propia). ................................................................ 180 Figura No. 5.17. Actividades en el modelado de los requisitos (elaborado en base a [Santander, 2002]). .................................................................................................................................................................. 180 Figura No. 5.18. Diagrama de Casos de Uso para el Caso de Estudio .................................................. 182 Figura No. 5.19. Modelos de prueba (elaboración propia). ................................................................... 187 Figura No. 5.20. Documento de contrato (elaboración propia). ............................................................ 188 Figura C.1. Modelo entidad relacionamiento Base de Datos SIMBAD. ................................................. 248 Figura C.2. Modelo entidad relacionamiento Base de Datos JPSIAM. .................................................. 249 Figura C.3. Bases de Datos obtenidas. .................................................................................................... 255 Figura C.4. Integración de las Bases de Datos seleccionadas ................................................................. 256 Figura C.5. Distribución de EGRESADOS en Cohortes 1996 y 1997. .................................................... 258 Figura C.6. Gráfico Malla de la Cohorte 1996. ....................................................................................... 258 Figura C.7. Gráfico Malla de la Cohorte 1997. ....................................................................................... 259 Figura C.8. Gráfico de Egresados V/s NEM, Cohortes 1996 y 1997 ....................................................... 259 Figura C.9. Gráficos Egresados V/S Puntaje de Selección, Cohortes 1996 y 1997. ................................ 260 Figura C.10. Modelo de Prueba. .............................................................................................................. 261 Figura C.11. Resultado de la creación del Modelo de prueba con Redes Neuronales. ........................... 261 Figura C.12. Resultado de la creación del Modelo de prueba con Árboles C&R. .................................. 262 Figura C.13. Árbol resultante del modelo C&R. ...................................................................................... 262 Figura C.14. Resultado de la creación del Modelo de Prueba con Árboles C5.0. ................................... 263 Figura C.15. Árbol resultante del modelo C5.0. ...................................................................................... 264 Figura C.16. Resultado de la validación del Modelo de prueba con Redes Neuronales. ........................ 265 Figura C.17. Resultado de la validación del Modelo de prueba con Árboles C&R. ............................... 265

xv

Figura C.18. Resultado de la validación del Modelo de prueba con Árboles C5.0. ................................ 266

xvii

ÍNDICE DE TABLAS

Tabla 2.1. Notaciones para la especificación de requisitos ([Sommerville,2002]). ................................... 70 Tabla 2.2. Bloques elementales de un modelo de negocios [Osterwalder, 2005]. .................................... 95 Tabla 2.3. Bloques constructivos de un modelo de negocios (elaborada en base a [Lagha, 2004]. ......... 99 Tabla 2.4. Descripción elementos básicos de BPMN (adaptado de [BPMN, 2008]) .............................. 104 Tabla 2.5. Resumen de notaciones gráficas. ............................................................................................ 107 Tabla 4.1. Fuentes de Información ........................................................................................................... 126 Tabla 4.2. Técnicas de educción para obtener información respecto de la visión del escenario actual de la organización. ........................................................................................................................................ 128 Tabla 4.3. Información sobre el escenario actual y metas de la organización. ....................................... 128 Tabla 4.4. Fuentes de Información ........................................................................................................... 131 Tabla 4.5. Técnicas de educción para relevamiento de la información sobre las estrategias, recursos y factores condicionantes. ........................................................................................................................... 132 Tabla 4.6. Relevamiento de la Información sobre las estrategias, recursos y factores condicionantes. . 133 Tabla 4.7. Plantilla para definición del equipo participante en el proyecto. .......................................... 137 Tabla 4.8. Plantilla para educción de requisitos organizacionales. ....................................................... 138 Tabla 4.9. Plantilla para definición del alcance del proyecto. ............................................................... 139 Tabla 4.10. Plantilla para la definición del glosario del proyecto .......................................................... 140 Tabla 4.11. Técnicas de educción a utilizar en la fase de definición de requisitos organizacionales. .... 141 Tabla 4.12. Plantilla para educción de metas, actores, información o conocimiento y datos. ............... 145 Tabla 4.13. Simbología a utilizar. ........................................................................................................... 146 Tabla 4.14. Red de dependencias entre actores organizacionales. ......................................................... 146 Tabla 4.15. Árbol de refinamiento de metas ............................................................................................ 147 Tabla 5.1. Stakeholders involucrados en el proceso decisional .............................................................. 170 Tabla 5.2. Descripción del árbol de refinamiento de metas para el caso de estudio. ............................. 171 Tabla 5.3. Caso de Uso: Verificar Influencia del Perfil del Estudiante ................................................... 182 Tabla 5.4. Caso de Uso: Identificar Tendencia en Asignaturas ............................................................... 183 Tabla 5.5. Caso de Uso: Verificar Causas Eliminación Ciclo Básico ..................................................... 184 Tabla 5.6. Caso de Uso: Ponderar Efecto Ciclo Básico y Profesional .................................................... 184 Tabla 5.7. Caso de Uso: Estudiar Capacidades Académicas (DGD) ...................................................... 185 Tabla 5.8. Caso de Uso: Consultar Resultados (Unidad Académica)...................................................... 185 Tabla 5.9. Caso de Uso: Estudiar Impacto Propuestas DGD (Unidad de Análisis Institucional) ........... 186 Tabla 5.10. Comparación de indicadores (tiempo de desarrollo, esfuerzo, grado de cumplimiento y grado de participación) de dos proyectos desarrollados en el mismo dominio de negocio. .................... 189 Tabla 5.11. Problemas detectados en una amplia gama de proyectos de Data Mining desarrollados (elaborado en base a [Britos, 2008]). ...................................................................................................... 191 Tabla 5.12. Conceptos considerados y elicitados al aplicar la metodología ER-DM y su relación con los problemas habitualmente presentados en el desarrollo de proyectos de Data Mining (elaborado en base a [Britos, 2008]). ......................................................................................................................................... 192

1

CAPÍTULO I

Introducción “La información reduce nuestra incertidumbre sobre algún aspecto de la realidad y por tanto, nos permite tomar mejores decisiones” [Hernández, 2004]. En este primer capítulo, se describen en principio, los antecedentes preliminares que constituyen la principal motivación para el desarrollo de la presente tesis doctoral. Posteriormente en las secciones siguientes, se presentan, los principales objetivos del trabajo de tesis y las principales aportaciones que se esperan lograr una vez concluido el trabajo. Para finalizar el capítulo, se muestra la estructura del presente informe.

3

1.1. Antecedentes.

En las tres últimas décadas, la humanidad ha sido testigo de un vertiginoso avance en las tecnologías de la microelectrónica, la informática, la computación y las telecomunicaciones. Como muestra de estos avances, se puede mencionar la evolución de los dispositivos de almacenamiento. En la década de los 80, los computadores personales tenían discos con capacidad de almacenamiento del orden de algunas pocas decenas de MegaByte. En la actualidad los discos de almacenamiento, cuentan con capacidades del orden de los TeraByte. Apoyadas en estas grandes capacidades de almacenamiento y otros factores tales como, la computarización de muchos negocios, el uso del código de barras en productos comerciales, el desarrollo de sensores y sistemas de recolección automático de datos y el uso de la World Wide Web como un sistema de información global [Hernández, 2004], [Martínez, 2003], múltiples empresas y organizaciones, han incrementado sus capacidades de generar y almacenar datos. Este explosivo crecimiento en la cantidad de datos almacenados, ha estimulado la imperiosa necesidad de crear técnicas que permitan transformar las grandes cantidades de datos almacenados, en información y conocimiento útil. En este sentido, KDD (Knowledge Discovery in Data Bases) es una de las técnicas más emblemáticas que ha surgido en los últimos años. KDD (Knowledge Discovery from Databases o Descubrimiento de Conocimiento a partir de Bases de Datos), es definido como “el proceso no trivial de identificar patrones válidos, novedosos, potencialmente útiles y en última instancia comprensibles a partir de los datos” [Fayyad, 1996], válidos, por cuanto, los patrones deben seguir siendo precisos para datos nuevos, novedosos, pues deben aportar algo desconocido, potencialmente útiles, debido a que la información debe originar acciones que reporten algún beneficio y comprensibles, porque la información incomprensible no proporciona conocimiento [Hernández, 2004]. El proceso KDD (figura 1.1), consiste en la integración, preparación y transformación de los datos, el Data Mining, y la evaluación, interpretación y presentación de los resultados. Esta secuencia de acciones se realiza iterativa e interactivamente.

Figura No. 1.1. Proceso de KDD ([Hernández, 2004]).

A pesar de que Data Mining, constituye una fase de KDD como se puede observar en la figura 1.1 y existen claras diferencias entre ambas, en la práctica ambos términos han sido utilizados indistintamente [Han, 2001]. Los orígenes de Data Mining se pueden establecer a finales de los años 80; década en la que surge como línea de investigación, con el propósito de buscar una solución al

4

problema de descubrimiento de conocimiento en bases de datos [Marbán, 2003]. Existe más de una definición de Data Mining, una de ellas indica, “Data Mining, se entiende como el proceso de extracción de información oculta en bases de datos de gran tamaño” [Thearling, 1999]. Considerando al proceso de Data Mining, como un proceso independiente de extracción y exploración de información oculta, se puede afirmar que durante los últimos años, se ha producido una gran expansión de Data Mining. De hecho en [Dilauro, 2000], se menciona un informe de GartnerGroup de 1999, en el cual se predice un explosivo crecimiento en el número de proyectos de Data Mining para la presente década; concretamente se indica: “en la próxima década, el número de proyectos de Data Mining, crecerá dramáticamente por encima de un 300 %, para mejorar las relaciones con los clientes y ayudar a las empresas a oír a sus clientes”. En [Han & Kamber, 2006], [Sharma, 2009], se menciona que el interés en el campo de Data Mining se ha incrementado principalmente, debido al rápido crecimiento en la cantidad de datos generados y almacenados por las empresas. Complementando esta afirmación en [Sharma, 2009], se informa que en una encuesta realizada en junio de 2007 y publicada en http://www.kdnuggets.com/polls/, (portal internacional especializado en Data Mining) el 22 % de los encuestados reportaron minería en bases de datos de 1 Terabyte o más, casi el doble de los que habían trabajado con bases de datos de similar tamaño en el año 2006. Sin embargo, al igual que la evolución del desarrollo de sistemas de software, la evolución de proyectos de Data Mining no está exenta de problemas. Como se recordará, el desarrollo de software hacia los años 60, sufrió una grave crisis como resultado de la introducción de poderosos computadores de tercera generación; los cuales permitieron que aplicaciones hasta ese momento irrealizables, fueran una propuesta factible [Sommerville, 2002]. La experiencia en la construcción de esos nuevos sistemas de software, mostró que un enfoque informal para su desarrollo no era muy bueno. Los grandes proyectos a menudo presentaban años de retraso, tenían elevados costes, eran difíciles de mantener y presentaban un pobre desempeño. Para enfrentar esta crisis en el año 1969, se presenta en la primera conferencia “NATO Software Engineering Conference” [Randell, 1996], [Naur, 1968], una nueva disciplina de la ingeniería, denominada, Ingeniería de Software. En el caso de proyectos de Data Mining, se ha constatado que muchos de estos proyectos no terminan y que incluso habiendo terminado, éstos no lo hacen en los plazos y/o con los presupuestos previstos o no corresponden con las expectativas de los clientes, [Zornes, 2003], [Marbán, 2003]. Entre las principales causas identificadas y que explican estos hechos, están las relacionadas con la falta de procesos de desarrollo estandarizados que incorporen un enfoque ingenieril al desarrollo de proyectos de Data Mining [Marban et al., 2008], y aspectos relacionados con una inadecuada fase de especificación de requisitos, tales como los mencionados en [Kelley, 2003]: funciones y capacidades no implementadas en el proyecto, usuarios insatisfechos, desempeño del proyecto inaceptable, mala calidad de datos y reportes, uso complejo para el usuario, etc. En [Hermiz, 1999], se afirma que uno de los factores críticos de éxito de proyectos de Data Mining es la necesidad de una articulación clara del problema de negocio que requiere ser resuelto, para el cual, se estima que Data Mining es la solución tecnológica adecuada.

5

Como una manera de enfrentar los problemas ya mencionados, en 1999, un grupo de empresas pioneras en el desarrollo de proyectos de Data Mining, tales como, Teradata, SPSS (ISL), Daimler-Chrysler y OHRA, proponen una guía de referencia para el desarrollo sistemático de proyectos de Data Mining, denominada CRISP-DM [CRISP-DM, 2000], o CRoss Industry Standard Process for Data Mining, estándar industrial con más de 160 empresas y organizaciones en su grupo de interés [Marbán, 2003], [Daedaluz, 2000]. CRISP-DM, no es la única guía que ha sido propuesta, también existen otras propietarias o abiertas como por ejemplo la desarrollada por la empresa SAS, llamada SEMMA (Sample, Explore, Modify, Model, Assess) [SAS, 2003], o DMAMC (Definir, Medir, Analizar, Mejorar, Controlar) [Isixsigma, 2005]. Sin embargo, CRISP-DM es la más ampliamente utilizada, con un 42 % de las preferencias como se muestra en [kdnuggets, 2007] producto de una encuesta desarrollada por kdnuggets.com en el año 2007 (figura 1.2).

CRISP-DM, estructura el desarrollo de un proyecto de Data Mining, en una serie de seis fases. La sucesión de fases, no es necesariamente rígida. Cada fase es descompuesta en varias tareas generales de segundo nivel. Las tareas generales se proyectan a tareas específicas, donde finalmente se describen las acciones que deben ser desarrolladas para situaciones específicas, pero en ningún momento se propone como realizarlas.

Figura No. 1.2. Metodologías utilizadas en Data Mining ([kdnuggets, 2007]).

Ahora bien, a pesar de la amplia aceptación que ha tenido CRISP-DM en la comunidad de los mineros de datos, este estándar, aún no representa un proceso maduro que pueda calificarse como una metodología sólida, es decir, que si bien establece un conjunto de tareas y actividades que deben ser llevadas a cabo en el proyecto, no establece con que técnicas o modelos debe implementarse cada actividad [Marbán, 2003].

De las seis fases que componen CRISP-DM (figura 1.3), la primera, es probablemente una de las más importantes, pues del conocimiento y dominio del problema que se tenga en esta fase, dependerá el éxito o fracaso del proyecto. En [Sharma, 2009], se sostiene que la fase de comprensión de negocio es tan importante como la de modelado o

6

cualquier otra fase o quizás sea más importante que el resto de las fases, dado que las decisiones que se deberán tomar en el resto de las fases, tales como las de preparación de datos, modelado o evaluación, son realizadas, o deberían ser idealmente realizadas durante esta fase. No tomar las decisiones adecuadas durante la fase de comprensión de negocio, podría originar problemas tales como ineficiencias en decisiones a tratar en fases posteriores (pérdidas de tiempo y recursos), o peor aún, conducir el proyecto por direcciones no previstas. En consecuencia, la principal motivación para el desarrollo del presente trabajo de tesis doctoral, es dar inicio a un proceso de conversión y adaptación del estándar CRISP-DM, en una metodología de apoyo para el desarrollo de proyectos de Data Mining (DM). Este trabajo concretamente, tiene por finalidad, el definir una propuesta metodológica para la construcción del Documento de Requisitos, tarea fundamental correspondiente a la primera fase de CRISP-DM, la cual se divide en las siguientes actividades (figura 1.3):

1. Identificación de los objetivos del negocio y criterios de éxito.

2. Realización de una evaluación de la situación (recursos; requisitos, supuestos y requerimientos; riesgos y contingencias; costes y beneficios).

3. Determinación de los objetivos de Data Mining y criterios de éxito.

4. Generación de un plan de proyecto.

Figura No. 1.3. Fase de comprensión del negocio ([CRISP-DM, 2000]).

1.2. Objetivos del trabajo.

Dada la gran importancia que adquiere, una correcta especificación de los requisitos, para el desarrollo eficaz de un proyecto de Data Mining, el principal objetivo del presente trabajo de tesis doctoral, es desarrollar una metodología de apoyo, para la tarea

7

de construcción del “Documento de Requisitos”, fase inicial del proceso de desarrollo de un proyecto de Data Mining. Los objetivos parciales que se proponen, para cumplir este objetivo son:

Realizar un estudio en amplitud sobre las diferentes técnicas y métodos que se utilizan en las diferentes fases del proceso de Ingeniería de Requisitos.

Definir la, o las técnicas de Ingeniería de Requisitos a utilizar, o susceptibles de adaptación, para su uso en la fase de educción de requisitos en proyectos de Data Mining.

Realizar un estudio sobre las diferentes notaciones utilizadas para especificar un Documento de Requisitos.

Establecer un procedimiento para definir un Modelo de Negocios Decisional.

Plantear una metodología (conjunto de técnicas y notaciones) para educir y representar requisitos en proyectos de Data Mining.

Ensayar la metodología propuesta en un proyecto concreto de Data Mining.

1.3. Aportaciones. Se establecen las siguientes aportaciones que se esperan lograr, producto del cumplimiento de los objetivos señalados:

Aportaciones teóricas y de investigación base: Como consecuencia del objetivo principal del trabajo de tesis que es, “desarrollar una metodología de apoyo para la construcción del documento de requisitos en proyectos de Data Mining”, se debe realizar una investigación documental en amplitud, sobre las diferentes técnicas de Ingeniería de Requisitos que se utilizan en diversas áreas del conocimiento, tales como Ingeniería de Software, Data Warehouse, Comercio Electrónico, Automoción u otras, y sus posibilidades de aplicación directa o con adaptaciones al trabajo en estudio.

Otro aspecto de importancia a considerar, es el diseño de un “Modelo de Negocio Decisional”, el cual represente el proceso de toma de decisiones origen del problema de negocio, permita derivar un posterior modelo de requisitos, permita validar los requisitos identificados y finalmente permita construir el contrato definitivo de requisitos de Data Mining.

Aportaciones metodológicas: El cumplimiento de los objetivos, permitirá establecer una metodología (conjunto de procedimientos, métodos y técnicas) para lograr la construcción de un Documento de Requisitos, destinado a optimizar tiempos, costes y fijar criterios de éxito bien definidos para el desarrollo de un proyecto de Data Mining.

Aportaciones prácticas: Como resultado del trabajo de tesis doctoral, se podrá disponer de un procedimiento metodológico, que permitirá determinar los objetivos de negocio en un proyecto de Data Mining, y también la educción y posterior construcción del Documento de Requisitos, tareas propuestas en la fase de Comprensión del Problema de CRISP – DM.

8

1.4. Estructura general.

El informe del trabajo de tesis realizado, se ha organizado en seis capítulos. A continuación se describe en forma resumida el contenido de cada capítulo. En el capítulo 2, se presenta el marco teórico y se realiza un estudio del estado de la cuestión, sobre los diversos temas en cuya intersección se encuadra el problema planteado. Más concretamente se estudian los siguientes tópicos:

Los principales conceptos relacionados con Data Mining, tales como, fases del proceso de desarrollo de un proyecto de Data Mining, logros y desafíos, y modelos de proceso que existen en la actualidad para su desarrollo.

Aspectos relacionados con la Ingeniería de Requisitos, sus modelos, métodos, técnicas y notaciones utilizadas en las actividades propias del proceso de Ingeniería de Requisitos.

Los diversos aspectos relacionados con los modelos de negocio, estructura organizacional, proceso de toma de decisiones y modelos de negocio decisional.

El capítulo 3, corresponde a la definición del problema que debe ser resuelto con el desarrollo de la presente tesis doctoral y los principales objetivos que deben ser logrados como resultado del trabajo desarrollado. En el capítulo 4, se propone la solución al problema planteado, es decir, se propone una metodología para la construcción del Documento de Requisitos en proyectos de Data Mining (ER-DM). Esta metodología, se explicita mediante un framework dentro del cual, se manifiestan las principales actividades de un proceso de Ingeniería de Requisitos para proyectos de Data Mining. El framework incluye un procedimiento para construir el Modelo de Negocios Decisional de la organización, el cual servirá como una interface entre la organización y el equipo de desarrolladores del proyecto de Data Mining, el conjunto de técnicas a utilizar en las diversas fases del proceso de Ingeniería de Requisitos y finalmente la notación y formato del Documento de Requisitos (ER-DM). El capitulo 5, presenta las contribuciones de la metodología, mediante su aplicación en el desarrollo de un proyecto de Data Mining para la Universidad Católica del Norte, ejecutado en el marco del proyecto MECESUP UCN 0607, “DESARROLLO Y FORTALECIMIENTO DE LA CAPACIDAD Y LA CULTURA DE ANÁLISIS INSTITUCIONAL EN UNA RED UNIVERSITARIA”. Finalizada la descripción de la aplicación de la metodología propuesta en el desarrollo del proyecto, se realiza una discusión de la experiencia lograda mediante su aplicación y los resultados alcanzados. En el capítulo 6 se enuncian y discuten las principales aportaciones del trabajo de tesis en el contexto de su aplicación para desarrollar proyectos de Data Mining. Por último y a continuación, se proponen un conjunto de líneas futuras de investigación en la temática tratada.

9

CAPÍTULO II

Marco Teórico En este capítulo, se presenta el marco teórico que da sustento al desarrollo de la tesis doctoral. Inicialmente, se abordan los aspectos fundamentales relacionados con Data Mining, tales como el ciclo de vida de un proyecto de Data Mining y los modelos de proceso utilizados para su desarrollo. En secciones posteriores, se revisan las principales actividades de un proceso de Ingeniería de Requisitos, su aplicación en diversas áreas de la ingeniería y los principales métodos, técnicas y notaciones utilizadas. Finalmente se describen diversos aspectos relacionados con los modelos de negocio, tales como: la estructura organizacional, el proceso de toma de decisiones, aportes del concepto de modelo de negocios a la ingeniería de requisitos en proyectos de Data Mining, componentes fundamentales de un modelo de negocios y las principales notaciones para su representación.

11

2.1. Data Mining.

2.1.1. Introducción

En los últimos años, una gran cantidad de datos están siendo almacenados por innumerables organizaciones y/o empresas con múltiples propósitos, sin embargo, esto no necesariamente implica, el que la cantidad de conocimiento que posean dichas organizaciones aumente de igual forma. Basándose en la premisa de que los datos poseen más información de la que aparentemente se observa, nace KDD (Knowledge Discovery from Databases), que es definido como “el proceso no trivial de identificar patrones válidos, novedosos, potencialmente útiles y en última instancia comprensibles, a partir de los datos” [Fayyad, 1996]. Una de las fases de este proceso, la constituye “Data Mining” (figura 2.1), término utilizado para referirse a la extracción de conocimiento desde grandes cantidades de datos. Este término, se considera que es inadecuadamente utilizado [Han, 2001] y que se podría sustituir por “Knowledge Mining from data” o “knowledge Mining”, razón por la cual con el correr de los años “KDD” y “Data Mining”, se utilizan indistintamente para referirse al mismo proceso [Han, 2001].

Figura No. 2.1. El proceso de KDD ([Cabena, 1997]).

Los orígenes de Data Mining se pueden establecer a finales de los años 80, cuando la administración de hacienda estadounidense, desarrolló un programa de investigación para detectar fraudes en las declaraciones de impuestos. Sin embargo, la gran expansión de Data Mining no se produce hasta la década de 1990 originada principalmente por tres factores [Martínez, 2003]:

Incremento de la potencia de los computadores.

Incremento del ritmo de adquisición de datos, debido al abaratamiento del hardware y a la automatización de los procesos de recolección de datos.

Aparición de nuevas técnicas de aprendizaje y almacenamiento de datos.

Una de la múltiples definiciones para Data Mining, encontradas en la literatura, expresa lo siguiente: Por Data Mining, se entiende al proceso de extracción de información

12

oculta en bases de datos de gran tamaño [Thearling, 1999]. Básicamente, Data Mining analiza los datos y utiliza diversas técnicas para encontrar patrones y relaciones en conjuntos de datos, con la ayuda de un computador. En términos generales y observando diversas definiciones, se puede expresar que Data Mining representa el proceso de descubrimiento de patrones ocultos en grandes bases de datos, con el objetivo de permitir que los responsables de las empresas u organizaciones puedan tomar las mejores decisiones sobre la base del conocimiento obtenido. El objetivo global de Data Mining, es encontrar patrones interesantes en grandes volúmenes de datos. Algunos ejemplos clásicos de problemas enfrentados mediante Data Mining son: segmentación de clientes, detección de transacciones fraudulentas, predicción de series temporales, entre otras. La complejidad de estos problemas y el crecimiento en la cantidad de datos disponibles, requieren métodos sofisticados para revelar la información oculta. Es aquí donde entra la inteligencia computacional, la cual provee técnicas avanzadas para ser utilizadas por Data Mining, como son por ejemplo las redes neuronales, la lógica difusa y los algoritmos genéticos. Estas herramientas se utilizan profusamente en la actualidad y por tanto, existe gran experiencia en muchas aplicaciones; esta experiencia, implica también el conocimiento de sus limitaciones.

Identificación del Problema

Selección de Datos

Preparación de Datos

Construcción del Modelo

Descubrimiento de Patrones

Despliegue de Patrones

Monitorización del Modelo

Cambios en datosy medio ambiente

Meta

DatosSeleccionados

Patrones

Modelo

DatosPreparados

Patrones Presentados

Figura No. 2.2. El proceso de Data Mining ([Caniupan, 2000]).

Observando el proceso de Data Mining, como un proceso independiente de extracción y exploración de información oculta, éste posee también sus propias etapas (figura 2.2) [Edelstein, 1999], las cuales son: la identificación del problema, la selección de los datos, su preparación, la construcción del modelo, el descubrimiento de patrones, y finalmente el despliegue de patrones y monitoreo del modelo. Estas etapas del proceso se describen a continuación:

13

1) Identificación del problema. Es la primera etapa del proceso de Data Mining. En este punto se debe tener claro el problema que se desea resolver, teniendo en cuenta que no todo problema requiere ser resuelto mediante Data Mining. Un buen justificativo es la solución de un problema relevante, del cual se puedan obtener resultados mensurables y cuyo conocimiento logrado permita o facilite la toma de decisiones relevantes y de alto nivel para la organización.

2) Selección de datos. En esta fase, los datos son adquiridos desde diversas fuentes tales como por ejemplo, una base de datos transaccional, un Data Warehouse o un Data Mart. Lo más probable es que sea necesario consolidarlos en un sólo repositorio. Podría darse también, que no se cuenten con los datos necesarios para el proceso de Data Mining, en cuyo caso, estos deben ser recolectados. De acuerdo a los objetivos de Data Mining, se deben seleccionar sólo los datos relevantes para la construcción del modelo.

3) Preparación de los datos. Una vez seleccionados los datos, estos deben ser preparados mediante las transformaciones que sean necesarias, por ejemplo, corrigiendo inconsistencias, diferencias de codificación, transformando campos con diferentes nombres, etc. Consolidando finalmente los datos en una sola base de datos.

4) Construcción del Modelo. En esta fase del proceso, corresponde la construcción de un modelo a partir de los datos obtenidos en la fase anterior, el cual puede ser un modelo predictivo o un modelo descriptivo, en función de los objetivos declarados del problema. Un modelo predictivo permite inferir el valor de una variable, en función de valores conocidos de otras variables; permite hacer predicciones de clasificación y de regresión. Por otro lado, un modelo descriptivo, describe patrones en datos existentes (cómo los datos se distribuyen o agrupan en el espacio) para apoyar la toma de decisiones.

5) Descubrimiento de patrones. Esta etapa del proceso, corresponde al descubrimiento de patrones mediante el uso de las técnicas, herramientas, o algoritmos que se consideren más adecuados para el tipo de problema a ser resuelto, por ejemplo, árboles de decisión, redes neuronales, lógica difusa, etc..

6) Despliegue de patrones. Como en todo proceso, después de obtener los resultados (descubrimiento de patrones) éstos deben ser evaluados, e interpretados sus resultados. El proceso de evaluación, implica la validación del modelo, encontrando una razón de exactitud, la cual puede variar en función de los datos a los cuales se les aplica el algoritmo, es decir, estos deben ser lo suficientemente representativos del universo de datos.

7) Monitorización del modelo. Como es de esperar, los procesos de negocio no son estáticos, y por tanto la validez de los modelos obtenidos se verá afectada con el tiempo. Por tanto, es importante realizar una continua monitorización del modelo con relación a los nuevos datos que se obtienen. Cambios significativos en los patrones, apuntarán a la necesidad de descubrir nuevos patrones a partir de los nuevos datos. Finalmente, un proceso repetible, asegura el éxito de un proyecto de Data Mining.

2.1.2. Tipos de problemas resueltos por Data Mining.

Son diversos los problemas en cuya solución es posible aplicar Data Mining ([Hernández, 2007], [Pérez, 2007]). Éstos se pueden clasificar en diversas clases, entre las que se pueden citar:

14

1) Asociación. Este tipo de enfoque es utilizado comúnmente en problemas de tipo cesta de compra, en los que asociaciones son buscadas con el objeto de determinar tendencias de compras de los clientes. Una asociación entre dos atributos, ocurre cuando la frecuencia con que se den dos valores determinados de cada uno conjuntamente, es relativamente alta. Un ejemplo que se podría citar, es descubrir del 100% de las veces que se compran pañales, también se compra leche [Hernández, 2007].

2) Secuencias temporales. Esta clase de problemas, es similar a los de asociación, con la diferencia de que en las secuencias, se incluye la variable tiempo, agregando comparaciones de tiempo entre las transacciones. En este enfoque, se intenta encontrar patrones entre eventos que ocurren en un periodo de tiempo, por ejemplo incluyendo: “dentro de los seis meses”, “próxima vez” o un conjunto de rangos como: “próximo día”, “próxima semana”, “próximo mes”, “próximo año”. Este tipo de enfoque algorítmico es usado para identificar cursos de comportamiento rutinarios o excepcionales, identificando sucesiones comunes o no comunes de procedimientos múltiples a través del tiempo [Moxon, 1996].

3) Clasificación. En este tipo de problemas, se busca la pertenencia de un objeto (registro) dentro de alguna clase predefinida, para así descubrir alguna relación entre los atributos de entrada y la clase de salida. Básicamente, la clasificación utiliza un conjunto de datos de entrenamiento para desarrollar el modelo. El conocimiento adquirido, luego puede ser utilizado para predecir la clase a la que pertenece un nuevo objeto desconocido. Este enfoque, es normalmente utilizado en detección de transacciones fraudulentas, riesgo en los créditos, identificación de procedimientos médicos, etc.

4) Regresión. La regresión consiste en construir un modelo más o menos transparente en el cuál la información de salida es un valor numérico continuo o un vector de tales valores más que una clase discreta. Es decir, dado un objeto, es posible predecir el valor de uno de sus atributos por los valores de otros atributos que está usando el modelo construido. Por ejemplo, el modelo predictivo para una regresión podría generar la siguiente afirmación: El ingreso económico del empleado Luís Pérez, es de 100.000 $. La regresión es utilizada en casos donde la salida predictiva, puede tomar posibles valores ilimitados (variables continuas).

5) Clustering. Agrupamiento, “clustering” o segmentación, como también se conoce a este tipo de problemas, consiste en la agrupación de registros que tienen un gran número de atributos, en un conjunto de grupos relativamente pequeños. Dicho de otra manera, se segmenta la base de datos en subconjuntos, donde los elementos de cada uno de ellos comparten un número de características similares. Este proceso de asignación es ejecutado automáticamente por los algoritmos de clustering que identifican las características distintivas de un conjunto de datos y entonces los particionan en “n” dimensiones definidas por los atributos. Normalmente, este enfoque algorítmico se aplica en problemas de marketing, por ejemplo, encontrando grupos con afinidades en sus gustos.

2.1.3. Logros y desafíos de Data Mining.

La utilización de Data Mining en diversas organizaciones, como herramienta de ayuda al proceso de toma de decisiones, ha demostrado producto del desarrollo de muchos proyectos, el aporte de importantes beneficios en este ámbito, entre los cuales se pueden citar [Aranguren, 2003]:

15

Impulsa el desarrollo de bases de datos estratégicas ad hoc al proceso de Data Mining.

Permite la extracción de información táctica y estratégica que contribuye favorablemente a la toma de decisiones.

Proporciona apoyo, para el descubrimiento automatizado de información desde grandes volúmenes de datos, generados mediante procesos tradicionales o de e-business.

Estimula a que los usuarios, den prioridad a acciones y decisiones indicando los factores que tienen una mayor importancia, en los objetivos declarados de la organización.

Proporciona poderes de decisión, a los usuarios que mejor entienden el problema, permitiendo medir las acciones y resultados de mejor forma.

Permite la obtención de modelos descriptivos y predictivos, que facilitan la obtención de soluciones que impactarán a la organización.

Sin embargo, el éxito e incremento en el desarrollo de proyectos de Data Mining en las organizaciones, presenta también algunos desafíos orientados a revertir algunas limitaciones que no permiten la obtención de los resultados esperados. Entre los problemas que se presentan [Caniupan, 2000] se pueden citar:

Bases de datos mal definidas, o definidas para no ser analizadas (BD transaccionales).

Inexistencia de repositorios históricos.

Inexistencia de almacenes de datos (Data Warehouse o Data Marts).

Falta de visión corporativa y cultura informática.

Falta de metodologías de desarrollo.

2.1.4. Modelos de proceso para proyectos de Data Mining (DM).

Son diversos los modelos de proceso que han sido propuestos para el desarrollo de proyectos de Data Mining tales como SEMMA (Sample, Explore, Modify, Model, Assess) [SAS, 2003], DMAMC (Definir, Medir, Analizar, Mejorar, Controlar) [Isixsigma, 2005], o CRISP-DM (Cross Industry Standard Process for Data Mining) [CRISP-DM, 2000], sin embargo uno de los modelos principalmente utilizados en los ambientes académico e industrial es el modelo CRISP-DM.

2.1.4.1. CRISP-DM (Cross Industry Standard Process for Data Mining).

CRISP–DM [CRISP-DM, 2000], es la guía de referencia más ampliamente utilizada en el desarrollo de proyectos de Data Mining, como se puede constatar en la gráfica presentada en la figura 2.3. Esta gráfica, publicada el año 2007 por kdnuggets.com, representa el resultado obtenido en sucesivas encuestas efectuadas durante los últimos años, respecto del grado de utilización de las principales guías de desarrollo de proyectos de Data Mining. En ella se puede observar, que a pesar de que el uso de

16

CRISP-DM ha descendido desde un 51 % en el año 2002, a un 42% en el año 2007, es aun frente a otras, la guía de referencia más ampliamente utilizada. Los orígenes de CRISP-DM, se remontan hacia el año 1999 cuando un importante consorcio de empresas europeas tales como NCR (Dinamarca), AG(Alemania), SPSS (Inglaterra), OHRA (Holanda), Teradata, SPSS, y Daimer-Chrysler, proponen a partir de diferentes versiones de KDD (Knowledge Discovery in Databases) [Reinartz, 1995], [Adraans, 1996], [Brachman, 1996], [Fayyad, 1996], el desarrollo de una guía de referencia de libre distribución denominada CRISP-DM (Cross Industry Standard Process for Data Mining).

Figura No. 2.3. Metodologías utilizadas en Data Mining ([kdnuggets, 2007]).

CRISP-DM, está dividida en 4 niveles de abstracción organizados de forma jerárquica (figura 2.4) en tareas que van desde el nivel más general, hasta los casos más específicos y organiza el desarrollo de un proyecto de Data Mining, en una serie de seis fases (figura 2.5):

Figura No. 2.4. Esquema de los 4 niveles de CRISP-DM ([CRISP-DM, 2000]).

Fases

Tareas Generales

Tareas Especializadas

Instancias de Proceso

Modelo Genérico CRISP

Modelo Específico

Proyección

17

La sucesión de fases no es necesariamente rígida. Cada fase es estructurada en varias tareas generales de segundo nivel. Las tareas generales se proyectan a tareas específicas, donde finalmente se describen las acciones que deben ser desarrolladas para situaciones específicas, pero en ningún momento se propone como realizarlas.

Figura No. 2.5. Modelo de proceso CRISP–DM ([CRISP-DM, 2000]).

A continuación se describen cada una de las fases en que se divide CRISP-DM.

2.1.4.1.1. Fase de comprensión del negocio o problema. La primera fase de la guía de referencia CRISP-DM, denominada fase de comprensión del negocio o problema (figura 2.6), es probablemente la más importante y aglutina las tareas de comprensión de los objetivos y requisitos del proyecto desde una perspectiva empresarial o institucional, con el fin de convertirlos en objetivos técnicos y en un plan de proyecto. Sin lograr comprender dichos objetivos, ningún algoritmo por muy sofisticado que sea, permitirá obtener resultados fiables. Para obtener el mejor provecho de Data Mining, es necesario entender de la manera más completa el problema que se desea resolver, esto permitirá recolectar los datos correctos e interpretar correctamente los resultados. En esta fase, es muy importante la capacidad de poder convertir el conocimiento adquirido del negocio, en un problema de Data Mining y en un plan preliminar cuya meta sea el alcanzar los objetivos del negocio. Una descripción de cada una de las principales tareas que componen esta fase es la siguiente:

Determinar los objetivos del negocio. Esta es la primera tarea a desarrollar y tiene como metas, determinar cuál es el problema que se desea resolver, por qué la necesidad de utilizar Data Mining y definir los criterios de éxito. Los problemas pueden ser diversos como por ejemplo, detectar fraude en el uso de tarjetas de crédito, detección de intentos de ingreso indebido a un sistema, asegurar el éxito de una determinada campaña publicitaria, etc. En cuanto a los criterios de éxito, estos pueden ser de tipo cualitativo, en cuyo caso un experto en el área de dominio, califica el resultado del proceso de DM, o de tipo cuantitativo, por ejemplo, el número de detecciones de fraude o la respuesta de clientes ante una campaña publicitaria.

Implantación

Evaluación

Datos

Preparación de los Datos

Modelado

Comprensión del Negocio

Comprensión de los Datos

18

Figura No. 2.6. Fase de comprensión del negocio ([CRISP-DM, 2000]).

Evaluación de la situación. En esta tarea se debe calificar el estado de la situación antes de iniciar el proceso de DM, considerando aspectos tales como: ¿cuál es el conocimiento previo disponible acerca del problema?, ¿se cuenta con la cantidad de datos requerida para resolver el problema?, ¿cuál es la relación coste beneficio de la aplicación de DM?, etc. En esta fase se definen los requisitos del problema, tanto en términos de negocio como en términos de Data Mining.

Determinación de los objetivos de DM. Esta tarea tiene como objetivo representar los objetivos del negocio en términos de las metas del proyecto de DM, como por ejemplo, si el objetivo del negocio es el desarrollo de una campaña publicitaria para incrementar la asignación de créditos hipotecarios, la meta de DM será por ejemplo, determinar el perfil de los clientes respecto de su capacidad de endeudamiento.

Producción de un plan del proyecto. Finalmente esta última tarea de la primera fase de CRISP-DM, tiene como meta desarrollar un plan para el proyecto, que describa los pasos a seguir y las técnicas a emplear en cada paso.

2.1.4.1.2. Fase de comprensión de los datos. La segunda fase (figura 2.7), fase de comprensión de los datos, comprende la recolección inicial de datos, con el objetivo de establecer un primer contacto con el problema, familiarizándose con ellos, identificar su calidad y establecer las relaciones más evidentes que permitan definir las primeras hipótesis. Esta fase junto a las próximas dos fases, son las que demandan el mayor esfuerzo y tiempo en un proyecto de DM. Por lo general si la organización cuenta con una base de datos corporativa, es deseable crear una nueva base de datos ad-hoc al proyecto de DM, pues durante el desarrollo del proyecto, es posible que se generen frecuentes y abundantes accesos a la base de datos a objeto de realizar consultas y probablemente modificaciones, lo cual podría generar muchos problemas.

19

Figura No. 2.7. Fase de comprensión de los datos ([CRISP-DM, 2000]).

Las principales tareas a desarrollar en esta fase del proceso son:

Recolección de datos iniciales. La primera tarea en esta segunda fase del proceso de CRISP-DM, es la recolección de los datos iniciales y su adecuación para el futuro procesamiento. Esta tarea tiene como objetivo, elaborar informes con una lista de los datos adquiridos, su localización, las técnicas utilizadas en su recolección y los problemas y soluciones inherentes a este proceso.

Descripción de los datos. Después de adquiridos los datos iniciales, estos deben ser descritos. Este proceso involucra establecer volúmenes de datos (número de registros y campos por registro), su identificación, el significado de cada campo y la descripción del formato inicial.

Exploración de datos. A continuación, se procede a su exploración, cuyo fin es encontrar una estructura general para los datos. Esto involucra la aplicación de pruebas estadísticas básicas, que revelen propiedades en los datos recién adquiridos, se crean tablas de frecuencia y se construyen gráficos de distribución. La salida de esta tarea es un informe de exploración de los datos.

Verificación de la calidad de los datos. En esta tarea, se efectúan verificaciones sobre los datos, para determinar la consistencia de los valores individuales de los campos, la cantidad y distribución de los valores nulos, y para encontrar valores fuera de rango, los cuales pueden constituirse en ruido para el proceso. La idea en este punto, es asegurar la completitud y corrección de los datos.

2.1.4.1.3. Fase de preparación de los datos. En esta fase y una vez efectuada la recolección inicial de datos, se procede a su preparación para adaptarlos a las técnicas de Data Mining que se utilicen posteriormente, tales como técnicas de visualización de datos, de búsqueda de relaciones entre variables u otras medidas para exploración de los datos. La preparación de datos incluye las tareas generales de selección de datos a los que se va a aplicar una determinada técnica de modelado, limpieza de datos, generación de variables adicionales, integración de diferentes orígenes de datos y cambios de formato.

20

Esta fase se encuentra relacionada con la fase de modelado, puesto que en función de la técnica de modelado elegida, los datos requieren ser procesados de diferentes formas. Es así que las fases de preparación y modelado interactúan de forma permanente. La figura 2.8, ilustra las tareas de que se compone ésta, e identifica sus salidas. Una descripción de las tareas involucradas en esta fase es la siguiente:

Selección de datos. En esta etapa, se selecciona un subconjunto de los datos adquiridos en la fase anterior, apoyándose en criterios previamente establecidos en las fases anteriores: calidad de los datos en cuanto a completitud y corrección de los datos y limitaciones en el volumen o en los tipos de datos que están relacionadas con las técnicas de DM seleccionadas.

Limpieza de los datos. Esta tarea complementa a la anterior, y es una de las que más tiempo y esfuerzo consume, debido a la diversidad de técnicas que pueden aplicarse para optimizar la calidad de los datos a objeto de prepararlos para la fase de modelación. Algunas de las técnicas a utilizar para este propósito son: normalización de los datos, discretización de campos numéricos, tratamiento de valores ausentes, reducción del volumen de datos, etc.

Estructuración de los datos. Esta tarea incluye las operaciones de preparación de los datos tales como la generación de nuevos atributos a partir de atributos ya existentes, integración de nuevos registros o transformación de valores para atributos existentes.

Figura No. 2.8. Fase de preparación de los datos ([CRISP-DM, 2000]).

Integración de los datos. La integración de los datos, involucra la creación de nuevas estructuras, a partir de los datos seleccionados, por ejemplo, generación de nuevos campos a partir de otros existentes, creación de nuevos registros, fusión de tablas

21

que contengan atributos diferentes para un mismo objeto, agregación de nuevos campos o nuevas tablas donde se resumen características de múltiples registros o de otros campos en nuevas tablas de resumen.

Formateo de los datos. Esta tarea consiste principalmente, en la realización de transformaciones sintácticas de los datos sin modificar su significado, esto, con la idea de permitir o facilitar el empleo de alguna técnica de DM en particular, como por ejemplo la reordenación de los campos y/o registros de la tabla o el ajuste de los valores de los campos a las limitaciones de las herramientas de modelación (eliminar comas, tabuladores, caracteres especiales, máximos y mínimos para las cadenas de caracteres, etc.).

2.1.4.1.4. Fase de modelado. En esta fase de CRISP-DM, se seleccionan las técnicas de modelado más apropiadas para el proyecto de Data Mining específico. Las técnicas a utilizar en esta fase se eligen en función de los siguientes criterios:

oo Ser apropiada al problema.

oo Disponer de datos adecuados.

oo Cumplir los requisitos del problema.

oo Tiempo adecuado para obtener un modelo.

oo Conocimiento de la técnica.

Figura No. 2.9. Fase de modelado ([CRISP-DM, 2000]).

Previamente al modelado de los datos, se debe determinar un método de evaluación de los modelos que permita establecer el grado de bondad de ellos. Después de concluir estas tareas genéricas, se procede a la generación y evaluación del modelo. Los parámetros utilizados en la generación del modelo, dependen de las características de

22

los datos y de las características de precisión que se quieran lograr con el modelo. La figura 2.9 ilustra las tareas y resultados que se obtienen en esta fase.

Una descripción de las principales tareas de esta fase es la siguiente:

Selección de la técnica de modelado. Esta tarea consiste en la selección de la técnica de DM más apropiada al tipo de problema a resolver. Para esta selección, se debe considerar el objetivo principal del proyecto y la relación con las herramientas de DM existentes. Por ejemplo, si el problema es de clasificación, se podrá elegir de entre árboles de decisión, k-nearest neighbour o razonamiento basado en casos (CBR); si el problema es de predicción, análisis de regresión, redes neuronales; o si el problema es de segmentación, redes neuronales, técnicas de visualización, etc...

Generación del plan de prueba. Una vez construido un modelo, se debe generar un procedimiento destinado a probar la calidad y validez del mismo. Por ejemplo, en una tarea supervisada de DM como la clasificación, es común usar la razón de error como medida de la calidad. Entonces, típicamente se separan los datos en dos conjuntos, uno de entrenamiento y otro de prueba, para luego construir el modelo basado en el conjunto de entrenamiento y medir la calidad del modelo generado con el conjunto de prueba.

Construcción del Modelo. Después de seleccionada la técnica, se ejecuta sobre los datos previamente preparados para generar uno o más modelos. Todas las técnicas de modelado tienen un conjunto de parámetros que determinan las características del modelo a generar. La selección de los mejores parámetros es un proceso iterativo y se basa exclusivamente en los resultados generados. Estos deben ser interpretados y su rendimiento justificado.

Evaluación del modelo. En esta tarea, los ingenieros de DM interpretan los modelos de acuerdo al conocimiento preexistente del dominio y los criterios de éxito preestablecidos. Expertos en el dominio del problema juzgan los modelos dentro del contexto del dominio y expertos en Data Mining aplican sus propios criterios (seguridad del conjunto de prueba, perdida o ganancia de tablas, etc...).

2.1.4.1.5. Fase de evaluación. En esta fase se evalúa el modelo, teniendo en cuenta el cumplimiento de los criterios de éxito del problema. Debe considerarse además, que la fiabilidad calculada para el modelo se aplica solamente para los datos sobre los que se realizó el análisis. Es preciso revisar el proceso, teniendo en cuenta los resultados obtenidos, para poder repetir algún paso anterior, en el que se haya posiblemente cometido algún error. Considerar que se pueden emplear múltiples herramientas para la interpretación de los resultados. Las matrices de confusión [Edelstein, 1999] son muy empleadas en problemas de clasificación y consisten en una tabla que indica cuantas clasificaciones se han hecho para cada tipo, la diagonal de la tabla representa las clasificaciones correctas. Si el modelo generado es válido en función de los criterios de éxito establecidos en la fase anterior, se procede a la explotación del modelo. La figura 2.10 detalla las tareas que componen esta fase y los resultados que se deben obtener. Las tareas involucradas en esta fase del proceso son las siguientes:

23

Evaluación de los resultados. En los pasos de evaluación anteriores, se trataron factores tales como la exactitud y generalidad del modelo generado. Esta tarea involucra la evaluación del modelo en relación a los objetivos del negocio y busca determinar si hay alguna razón de negocio para la cual, el modelo sea deficiente, o si es aconsejable probar el modelo, en un problema real si el tiempo y restricciones lo permiten. Además de los resultados directamente relacionados con el objetivo del proyecto, ¿es aconsejable evaluar el modelo en relación a otros objetivos distintos a los originales?, esto podría revelar información adicional.

Proceso de revisión. El proceso de revisión, se refiere a calificar al proceso entero de DM, a objeto de identificar elementos que pudieran ser mejorados.

Figura No. 2.10. Fase de evaluación ([CRISP-DM, 2000]).

Determinación de futuras fases. Si se ha determinado que las fases hasta este momento han generado resultados satisfactorios, podría pasarse a la fase siguiente, en caso contrario podría decidirse por otra iteración desde la fase de preparación de datos o de modelación con otros parámetros. Podría ser incluso que en esta fase se decida partir desde cero con un nuevo proyecto de DM.

2.1.4.1.6. Fase de implementación. En esta fase (figura 2.11), y una vez que el modelo ha sido construido y validado, se transforma el conocimiento obtenido en acciones dentro del proceso de negocio, ya sea que el analista recomiende acciones basadas en la observación del modelo y sus resultados, ya sea aplicando el modelo a diferentes conjuntos de datos o como parte del proceso, como por ejemplo, en análisis de riesgo crediticio, detección de fraudes, etc... Generalmente un proyecto de Data Mining no concluye en la implantación del modelo, pues se deben documentar y presentar los resultados de manera comprensible para el usuario, con el objetivo de lograr un incremento del conocimiento. Por otra parte, en la fase de explotación se debe asegurar el mantenimiento de la aplicación y la posible difusión de los resultados. Las tareas que se ejecutan en esta fase son las siguientes:

24

Plan de implementación. Para implementar el resultado de DM en la organización, esta tarea toma los resultados de la evaluación y concluye una estrategia para su implementación. Si un procedimiento general se ha identificado para crear el modelo, este procedimiento debe ser documentado para su posterior implementación.

Monitorización y Mantenimiento. Si los modelos resultantes del proceso de Data Mining son implementados en el dominio del problema como parte de la rutina diaria, es aconsejable preparar estrategias de monitorización y mantenimiento para ser aplicadas sobre los modelos. La retroalimentación generada por la monitorización y mantenimiento pueden indicar si el modelo está siendo utilizado apropiadamente.

Comprensión del negocio

Comprensión de los datos

ModeladoPreparación de los datos

Evaluación Implantación

Plan de monitoreo y mantención

Informe final

Modelos aprobados

Plande

implantación

Revisión del proyecto

Documentación de

experiencias

Plande

implementación

Plan de monitorización y mantención

Informe final

Figura No. 2.11. Fase de implementación ([CRISP-DM, 2000]).

Informe Final. Es la conclusión del proyecto de DM realizado. Dependiendo del plan de implementación, este informe puede ser sólo un resumen de los puntos importantes del proyecto y la experiencia lograda o puede ser una presentación final que incluya y explique los resultados logrados con el proyecto.

Revisión del proyecto: En este punto se evalúa qué fue lo correcto y qué lo incorrecto, qué es lo que se hizo bien y qué es lo que se requiere mejorar.

2.2. Ingeniería de Requisitos (IR).

2.2.1. Introducción. Dada la importancia que representa la especificación de requisitos correctos, precisos y no ambiguos mediante un contrato o documento de requisitos al inicio de un proyecto, sea éste, de desarrollo de un sistema de software, de Data Mining, de un sistema de información, de aplicaciones de e-commerce, de e-bussines, de Data Warehouse, de diseño de un edificio, construcción de una máquina, etc., son numerosos los estudios que se han realizado sobre el tema, de los cuales, surgió una nueva disciplina denominada “Ingeniería de Requisitos”.

25

En la literatura se pueden encontrar múltiples definiciones de Ingeniería de Requisitos (IR) entre las cuales, se pueden enunciar las siguientes: Sawyer, P. y Sommerville, I. en [Sawyer, 1997] plantean la siguiente definición, “Ingeniería de Requisitos, es relativamente un término nuevo, que ha sido inventado para cubrir todas las actividades involucradas en el descubrimiento, documentación, y mantenimiento de un conjunto de requisitos”. Por su parte Loucopoulos & Karakostas (1995) [Loucopoulos, 1995] definen:“la Ingeniería de Requisitos, es el proceso de obtención de requisitos a través de un proceso interactivo y cooperativo de análisis del problema, documentando las observaciones en una variedad de formatos de representación y verificando la exactitud de lo comprendido”. En [Sommerville, 2002], se define, “Ingeniería de Requisitos, es un proceso que comprende todas las actividades requeridas para crear y mantener un documento de requisitos del sistema”. Otra definición que se puede citar es, “Proceso mediante el cual se intercambian diferentes puntos de vista para recopilar y modelar lo que el sistema va a realizar. Este proceso utiliza una combinación de métodos, herramientas y actores, cuyo producto es un modelo del cual se genera un documento de requisitos” [Resof, 2005]. Analizando las definiciones ya descritas, se puede establecer que el objetivo primordial de la Ingeniería de Requisitos, es permitir la obtención de una definición clara, estructurada y no ambigua de las especificaciones correctas que definen el comportamiento de un sistema, con el propósito de minimizar los problemas que se puedan presentar en el desarrollo de un determinado producto. Esta idea no está restringida únicamente al desarrollo de sistemas de software. Las variadas técnicas y herramientas que se han desarrollado, permiten incluso la definición de requisitos de los componentes de un automóvil [Weber, 2003] o los requisitos de aplicaciones de e-commerce [Gordijn, 2003]. Consecuentemente, la IR, representa hoy en día una técnica muy utilizada (en la construcción del documento de requisitos) por desarrolladores de software y otros especialistas, considerándose un buen punto de partida para el diseño e implementación de diversos productos. Armin Eberlein y Li Jiang [Armin, 2003] indican que para desarrollar sistemas de alta calidad, es necesario obtener las especificaciones correctas, lo cual transforma a la Ingeniería de Requisitos en una parte vital del desarrollo de un sistema y crítica para el éxito de un proyecto completo. Emam K. et al [Emam, 2000], revisando 56 proyectos de diferentes países del mundo, durante un periodo de dos años, observaron que un buen proceso de toma de requisitos tiene un impacto positivo en la calidad de un sistema. Se concluye así, que la Ingeniería de Requisitos constituye actualmente un enorme desafío para la industria por diferentes razones tales como [Armin, 2003]:

oo El proceso de Ingeniería de Requisitos es muy complejo [Prekas, 2000].

oo Varios modelos y metodologías coexisten con diferentes niveles de complejidad.

oo Muchas herramientas se han desarrollado para soportar diferentes modelos y metodologías, lo cual hace muy difícil al ingeniero decidir, qué herramienta elegir.

oo Diferentes terminologías e interpretaciones contradictorias de algunos conceptos, constituyen un problema difícil para definir modelos de IR.

26

Respecto de quiénes intervienen en los procesos involucrados en la Ingeniería de Requisitos, son diversos los especialistas que componen el equipo de trabajo. Cada uno de ellos, debe asumir un rol específico durante el proceso, de acuerdo a su especialidad, cargo o jerarquía dentro de la organización o equipo de desarrollo de proyectos. Los roles más importantes son los siguientes [Bahamonde, 2003] .

oo Usuario final: Son las personas que usarán el sistema desarrollado. Ellos están relacionados con la usabilidad, la disponibilidad y la fiabilidad del sistema, y están familiarizados con los procesos de su organización. Serán quienes utilicen las interfaces y los manuales de usuario.

oo Cliente: Son las personas que comprenden el ambiente del sistema o el dominio del problema en donde será empleado el sistema desarrollado. Ellos proporcionan al equipo técnico los detalles y requisitos de las interfaces del sistema.

oo Personal de Mantenimiento: Para proyectos que requieran un mantenimiento eventual, estas personas son las responsables de la administración de cambios, de la implementación y resolución de anomalías. Su trabajo consiste en revisar y mejorar los procesos del producto ya finalizado.

oo Analistas y programadores: Son los responsables del desarrollo del producto en sí. Interactúan directamente con el cliente.

oo Personal de pruebas: Se encargan de diseñar y ejecutar un conjunto de pruebas para asegurar que las condiciones presentadas por el sistema son las adecuadas.

Otras personas que pueden estar involucradas, dependiendo de la magnitud del proyecto, pueden ser: administradores de proyecto, documentadores, diseñadores de base de datos, etc...

Es importante finalmente, destacar algunos de los beneficios que representa la utilización de la Ingeniería de Requisitos en el desarrollo de un proyecto. Un listado ilustrativo pero no estricto es el siguiente [Bahamonde, 2003]:

oo Permite representar las necesidades de un proyecto de una manera estructurada. Toda actividad de IR consiste en una serie de pasos bien organizados y definidos.

oo Mejora la capacidad de predecir resultados. Provee un punto de partida para los controles subsecuentes y actividades de mantenimiento, tales como estimación de costes, tiempo y recursos necesarios.

oo Disminuye costes y retrasos en proyectos. Proporciona un buen estudio del problema al inicio del proyecto, disminuyendo de esta manera los errores encontrados durante el desarrollo, ahorrando los costes de reparación.

oo Mejora la calidad del producto. Al cumplir con los requisitos, se mejoran aspectos de calidad como funcionalidad, facilidad de uso, confiabilidad, desempeño, etc...

oo Mejora la comunicación entre equipos. Permite una especificación de requisitos que representa una forma de consenso entre clientes y desarrolladores.

oo Evita rechazos de usuarios finales. La IR incorpora a sus equipos de trabajo, a los usuarios del sistema a desarrollar, obligándolos a considerar sus requisitos cuidadosamente y revisarlos dentro del marco del problema.

27

Ahora bien, hasta el momento se ha mencionado en variadas ocasiones el término requisitos, por tanto, es conveniente tener una definición clara sobre su significado y realizar un estudio algo más detallado acerca de este concepto. IEEE define el concepto de requisito de la siguiente forma [IEEE, 1990]:

1. Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo.

2. Una condición o capacidad que debe estar presente en un sistema o en los componentes de un sistema para satisfacer un contrato, estándar, especificación u otro documento formal.

3. Una representación documentada de una condición o capacidad.

Los requisitos pueden ser clasificados en (es preciso manejar los conceptos en su concepción más amplia sin particularizar el sistema a uno de software esencialmente) [Sommerville, 2002], [Bahamonde, 2003]:

oo Funcionales: Los requisitos funcionales definen las funciones que el sistema será capaz de realizar. Estos deben definir y describir los procesos y actividades que componen el sistema completo. También describen qué funciones no realizará el sistema.

oo No funcionales: Los no funcionales son aquellos que no están relacionados directamente con los procesos que definen el sistema, sino más bien tienen que ver con características adicionales, como seguridad, mantenimiento, robustez, portabilidad, etc.

oo Dominio: Los requisitos de dominio, son los que provienen del dominio de aplicación del sistema y reflejan las características de ese dominio. Ellos pueden ser funcionales o no funcionales.

Los requisitos [Bahamonde, 2003] también deben poseer ciertas características tales como:

oo Necesario: Un requisito es necesario, sólo si su omisión provoca una deficiencia en el sistema, por lo que su reemplazo es imposible.

oo Conciso: Un requisito es conciso, si es fácil de leer y entender. Su redacción debe ser simple y clara, sin llegar a la incompletitud.

oo Completo: Un requisito es completo, si existe toda la información relacionada a él.

oo Consistente: Un requisito es consistente, si no se contradice con otro requisito.

oo No ambiguo: Un requisito es no ambiguo, cuando su especificación tiene sólo una interpretación, evitando de esa manera confusiones a los lectores.

oo Verificable: Un requisito es verificable, cuando puede ser cuantificado de manera que permita hacer uso de métodos de verificación como inspección, análisis, demostración o pruebas.

Para concluir, otro aspecto importante de tomar en cuenta, es que durante la identificación de los requisitos normalmente surgen ciertos problemas y dificultades tales como [Bahamonde, 2003]:

28

oo Los requisitos no son obvios y vienen de muchas fuentes.

oo Son difíciles de expresar en lenguaje natural.

oo Existe una variada gama de requisitos y diferentes niveles de detalle.

oo Un elevado número de requisitos puede volverse inmanejable.

oo Definir las relaciones entre requisitos y otras áreas de procesos.

oo Los requisitos pueden variar a lo largo del desarrollo del proyecto.

oo Dificultad en la cuantificación de los requisitos.

2.2.2. Modelos de proceso de Ingeniería de Requisitos. Diversos modelos de proceso han sido propuestos en Ingeniería de Requisitos, entre los cuales se pueden citar los siguientes:

2.2.2.1. Ingeniería de Requisitos en Ingeniería del Software.

En un proceso de Ingeniería de Requisitos, se pueden identificar ciertos elementos o actividades fundamentales que deben ser desarrolladas para establecer un documento de especificación de requisitos. Estas actividades fundamentales, como son la elicitación, el análisis, la especificación y la validación de los requisitos, sirven de base a la propuesta de diversos modelos. Así en [Davyt, 2001], se plantea en base a las actividades de elicitación, análisis, especificación y validación, el modelo de proceso representado en la figura 2.12. Los elementos fundamentales del diagrama planteado, se describen a continuación [Bahamonde, 2003]:

Elicitación: Es el proceso de adquirir (“eliciting”) todo el conocimiento relevante, necesario para producir un modelo de los requisitos en un dominio de problema, mediante la comunicación con clientes, usuarios del sistema y quienes estén involucrados en el proyecto. Es la etapa de mayor interacción con el usuario. Es el momento en el que se recurre a la observación, lectura de documentos y entrevistas, entre otras técnicas. Es la instancia en que equipos multidisciplinarios trabajan conjuntamente con el cliente/usuario para obtener los requisitos reales de la mejor manera.

Análisis: Después de obtener un conjunto inicial de requisitos, estos deben ser analizados y representados en un lenguaje más técnico, con el fin de evitar inconsistencias y ambigüedades para posteriormente negociar un contrato. Los conflictos deben ser resueltos y los requisitos deben priorizarse.

Especificación: El proceso del análisis proporciona la entrada para el proceso de la especificación de requisitos [Gordijn, 2003]. La salida es un modelo de la especificación, o los modelos que corresponden a diversas visiones. Estos modelos formalizan el conocimiento tácito del grupo o partes involucradas en el proyecto (stakeholders) [Sharp, 1999]. Es sabido que la forma de especificar tiene mucho que ver con la calidad de la solución, por lo que ésta es quizás la etapa de mayor cuidado.

29

Figura No. 2.12. Esquema general del proceso de Ingeniería de Requisitos (elaborado en base a [Davyt, 2001])

La especificación de requisitos además, tiene un doble propósito, por un lado, sirve como un acuerdo para el problema a ser resuelto entre el grupo involucrado en el proyecto y por otro, sirve como modelo para continuar con el siguiente paso.

Validación: Antes de proceder al proceso de validación, es importante tener en cuenta que no se debe confundir la validación con evaluación. La evaluación verifica las propiedades de cada requisito, mientras que la validación revisa el cumplimiento de las características de la especificación de requisitos, es decir, el objetivo de la validación de requisitos, es comprobar si la especificación de requisitos está de acuerdo a lo esperado por los ‘stakeholders’. Además revisa que no se haya omitido ningún requisito, que no sean ambiguos, inconsistentes o redundantes.

Para ejecutar el proceso de validación en forma eficiente, es importante plantearse una serie de preguntas en base a cada una de las características que se desean revisar. Algunos ejemplos son los siguientes [Caneo, 2008]:

oo ¿Están incluidas todas las funciones requeridas por el cliente? (completa).

oo ¿Existen conflictos en los requisitos? (consistencia).

oo ¿Tiene alguno de los requisitos más de una interpretación? (no ambigua).

oo ¿Está cada requisito claramente representado? (entendible).

oo ¿Pueden los requisitos ser implementados con la tecnología y el presupuesto disponible? (factible).

oo ¿Está el documento escrito en un lenguaje apropiado? (claro).

oo ¿Existe facilidad para hacer cambios en los requisitos? (modificable).

oo ¿Está claramente definido el origen de cada requisito? (rastreable).

oo ¿Pueden los requisitos ser sometidos a medidas cuantitativas? (verificable).

Finalmente la validación de requisitos es importante, pues de ello depende que no existan elevados costes de mantenimiento para el software desarrollado. En esta etapa se produce la integración y validación final de lo obtenido en las etapas anteriores, entregando como resultado final, el Documento de Requisitos.

30

Ian Sommerville [Sommerville, 2002] plantea otro modelo para el proceso de Ingeniería de Requisitos, tal como el representado en la figura 2.13.

Figura No. 2.13. Proceso de Ingeniería de Requisitos ([Sommerville, 2002]).

En este modelo de proceso como se puede observar, se incorpora como primera etapa del proceso, un estudio de viabilidad. El estudio de viabilidad, es un primer estudio que recibe como entrada una descripción breve del sistema a desarrollar y cómo éste será utilizado por la organización demandante. El objetivo de este estudio es responder fundamentalmente algunas preguntas tales como: ¿el sistema contribuye a los objetivos generales de la organización?, ¿el sistema puede ser implementado con la tecnología existente, tomando en cuenta las restricciones de tiempo y presupuesto?, ¿puede el nuevo sistema ser integrado con otros sistemas existentes en la organización?. Para conseguir los objetivos planteados en esta etapa del proceso de Ingeniería de Requisitos, se deben ejecutar algunas tareas, estas son: la evaluación y recolección de información y la redacción de un informe de viabilidad. La evaluación de la información, consiste en la identificación y recolección de la información necesaria para contestar las preguntas planteadas. Después de identificar esta información, se pregunta a las fuentes de información para descubrir las respuestas a dichas preguntas. Las fuentes de información normalmente provienen de entrevistas que se realizan a los administradores de los departamentos donde será utilizado el sistema, a ingenieros que estén relacionados con el sistema que se propone, a expertos en tecnología y a los usuarios finales [Sommerville, 2002]. Luego, cuando ya se cuenta con la información requerida, se procede a elaborar el estudio de factibilidad. Este debe incluir recomendaciones de cuando continuar con el desarrollo del proyecto, cambios en el alcance, presupuesto, temporización del desarrollo del sistema y requisitos adicionales de alto nivel. Un tercer modelo que se puede analizar, es el modelo denominado “modelo en espiral” [Kotonya, 1998], este modelo es representado en la figura 2.14. El uso de una espiral en este modelo, sirve para representar que las diferentes actividades que componen el modelo, es decir, la planificación/extracción, el análisis, la especificación y la validación, son actividades repetitivas hasta el momento en que se toma la decisión final de aceptación del documento de especificación de requisitos. Dicho de otra forma, si existen problemas en los diseños preliminares del documento,

31

permanentemente se recorre el ciclo extracción, análisis, especificación y validación hasta que no queden conflictos por resolver. En este sentido es importante destacar que el proceso puede ser influenciado por ciertos factores externos que pueden empujar hacia una finalización rápida del proceso.

Figura No. 2.14. Modelo en Espiral del proceso de IR ([Kotonya, 1998]).

Para concluir este punto, se puede establecer que no existe un modelo único que se pueda aplicar a todos los procesos de requisitos, puesto que la realidad de las diversas organizaciones es diferente, diferentes sus objetivos y el tipo de proyectos o sistemas a ser desarrollados (operacionales o no operacionales). Es decir, los diversos tipos de empresas u organizaciones, deberán utilizar los modelos de requisitos que más se adapten al tipo de proyecto a desarrollar, al tipo de personal con que cuenta, a su percepción de la organización o a su nivel de experiencia.

2.2.2.2. Ingeniería de Requisitos en Data Warehouse.

Una técnica utilizada para la definición de requisitos en proyectos de Data Warehouse es DWARF (Data Warehouse Requirements deFinition) [Rilston, 2003]. Esta técnica, está estructurada en una serie de cuatro etapas, como se ilustra en figura 2.15.

Una descripción de cada una de las etapas en que se divide la técnica, es la siguiente.

1) Planificación de la gestión de requisitos. En la primera etapa de la definición de requisitos, se debe generar un conjunto de pautas orientadas a la correcta aplicación de la Ingeniería de Requisitos en sistemas de Data Warehouse. La definición de estas pautas, en términos de reglas de negocio, procedimientos o procesos, permitirá la correcta aplicación de la técnica DWARF y clarificar aspectos tales como por ejemplo, cuál es el grado de granularidad de cada Data Mart o qué limitaciones restringen el análisis multidimensional de datos. Las respuestas a estas preguntas y muchas otras, serán consideradas en la definición de los objetivos del proyecto.

2) Especificación de requisitos. En el desarrollo del Data Warehouse, el proceso de especificación de requisitos, apunta hacia una aproximación cíclica de la adquisición, representación y evaluación de los requisitos. Los requisitos iniciales de los Data Mart, pasan por una secuencia de iteraciones, en la que

32

requisitos son analizados, negociados y registrados de acuerdo a una especificación más amplia del Data Warehouse.

Stakeholder

Usuario final

Proveedor de recursos

Ingenierode

requisitos

Ingenierode

Software

Gerentedel

proyecto

Control de gestión de requisitos

Necesidadesde usuarios

Requisitosdel Data Mart

Dominiode aplicaciónde negocios

Versión finalde requisitosdel Data Mart

Personal externo PersonalTécnico

Actor Artefacto

Requisitosdel Data Warehouse

Planificacióny gestión

de requisitos

Especificaciónde requisitos

Validaciónde requisitos

Requisitosiniciales

Requisitosdel Data

Warehouseactualizados

Etapa

Flujode

información

Ciclo de desarrollo

Requisitos inicialesdel Data

Warehouse

Líneas guía delproyecto

Cambiosacordados

Plan de gestiónde requisitos

Figura No. 2.15. Etapas de la técnica DWARF ([Rilston, 2003]).

A continuación, se describen los subprocesos que componen la fase de especificación de requisitos.

Elicitación de Requisitos. Esta fase, se orienta a la implementación de un proceso de descubrimiento de requisitos mediante:

a) La comunicación con stakeholders, para detectar necesidades de soporte de decisiones.

b) Descripción de la interacción del sistema con los clientes. c) Simular el comportamiento de OLAP (On-Line Analytical Processing). d) Investigar compromisos arquitectónicos.

Algunas de las técnicas de Ingeniería de Requisitos, incluso adaptadas para usarlas en el contexto de Data Warehouse son: entrevistas, workshops, prototipos y escenarios.

o Entrevistas. Esta técnica, es utilizada cuando los usuarios muestran cierta incapacidad para describir sus necesidades estratégicas. Se adopta un estilo de entrevistas, que consiste en efectuar consultas especialmente enfocadas a ciertos tópicos de Data Warehouse, como por ejemplo, granularidad y multidimensionalidad.

o Workshops. Workshops en el contexto de Data Warehouse, aseguran el consenso en aplicaciones de tipo multidimensional, estimulan un pronto acuerdo entre las partes involucradas respecto del curso de acciones en el

33

Data Mart, estimulan la cohesión al interior de los grupos de desarrollo y capturan de mejor forma, funcionalidades y restricciones operacionales.

o Prototipos. Esta técnica, consiste en generar prototipos para simular el funcionamiento OLAP y mostrar a los stakeholders, cómo el sistema les ayudará en la toma de decisiones, para consolidar sus ideas sobre cómo los requisitos conducirán a una solución multidimensional.

o Escenarios. La utilización de esta técnica, consiste en el uso de casos de uso para especificar escenarios en modo texto o gráfico, con el objeto aclarar los requisitos funcionales de un Data Warehouse, particularmente de acceso, transformación o extracción de datos.

Análisis y negociación de requisitos. Los requisitos descubiertos durante la fase previa de elicitación, sirven de entrada a la fase de análisis y negociación, en la cual, se realiza un análisis detallado para asegurar que la especificación cumple estándares de calidad, restricciones multidimensionales, premisas de integración y restricción de herramientas OLAP. Para soportar esta fase, se define una lista de verificación para requisitos de Data Warehouse.

Documentación de requisitos. Esta fase constituye el núcleo de la propuesta. El propósito, es proveer una completa documentación de los requisitos elicitados. Se ha diseñado un conjunto de plantillas para registrar todos los requisitos funcionales, no funcionales y de dominio del Data Warehouse. El modelo de documentación, se basa en el propuesto en [Kruchten, 1999], [Rilston, 2003] y su estructura refleja un enfoque para la especificación de requisitos, para una familia de productos [Leffingwell, 2000], [Rilston, 2003], los cuales se ajustan precisamente a la descripción de un Data Warehouse y sus Data Marts. Una descripción de los elementos que componen el modelo es la siguiente [Rilston, 2003].

o Plan de gestión de requisitos. En este punto, se describen los aspectos esenciales que permiten controlar el proyecto.

o Glosario. En el glosario, se organiza la terminología relacionada con el dominio del problema.

o Visión del Data Warehouse. En este acápite, se describen los requisitos del Data Warehouse, incluyendo una discusión del problema, objetivos generales, alcance del proyecto, perfil de los stakeholders y otros aspectos de importancia para el Data Warehouse.

o Visión del Data Mart. Describe los requisitos de alto nivel de los usuarios del Data Mart, así como también el soporte para tales necesidades.

o Especificación de casos de uso. Detalla los procedimientos (y sus posibles secuencias) necesarios para implementar todas las funcionalidades que se desean para cada Data Mart.

o Especificación de requisitos de Multidimensionalidad. Se reporta una visión multidimensional incluyendo, restricciones, información dimensional y consideraciones acerca de la granularidad y conformidad de requisitos multidimensionales.

o Especificación de requisitos no funcionales. Describe los requisitos no funcionales que no están cubiertos por el modelo de casos de uso.

34

o Especificación de las reglas de negocio. Es un registro de todas las reglas del negocio que regulan las funcionalidades del Data Warehouse y del Data Mart.

o Informe de revisión. Es un reporte que contiene los acuerdos después de la sesión de validación.

Conformidad de requisitos. Esta fase, es muy importante para la especificación de un Data Warehouse, pues aborda un aspecto esencial que es la conformidad. De acuerdo a [Kimball, 1998], [Rilston, 2003], si se espera construir un Data Warehouse que sea robusto y flexible, frente a requisitos en constante evolución, uno se debe ajustar a una definición de Data Warehouse en la cual los hechos y dimensiones comunes sean conformes a todos los Data Marts. Una dimensión es conformada, cuando significa lo mismo para cada tabla de hechos. Un hecho es conforme al modelo global, si la misma terminología para representar su contenido se usa a través de los Data Marts. En [Rilston, 2003] se extiende este concepto al más alto nivel de abstracción, en el cual, todos los requisitos comunes del sistema se conforman, es decir se representan idénticamente dentro del modelo de requisitos del Data Mart. Este principio, no sólo incluye los aspectos multidimensionales, sino también cada funcionalidad, característica o restricción en el desarrollo del sistema. Entre algunos beneficios que los requisitos conformes brindan a la especificación de Data Warehouse, se pueden citar: evitan redundancia y ambigüedad entre requisitos, permiten aspectos dimensionales comunes, permiten operaciones de OLAP que involucren múltiples tablas de hechos, permiten la evolución de un Data Warehouse de una forma más simple.

3) Validación de requisitos. La etapa de validación, tiene como meta corregir algunos tipos de errores y/o conceptos mal entendidos, que aún permanezcan después de varias iteraciones, respecto de ciertas características del Data Warehouse. Sesiones de revisión, junto a prototipos de prueba, pueden ser efectivos para detectar y eliminar tales defectos antes de que constituyan parte del paquete del Data Mart. Durante las sesiones de revisión, los requisitos finales del Data Mart son presentados a todas las partes involucradas y descritos en términos de sus aspectos funcionales, no funcionales y multidimensionales. Además una interface prototipo de OLAP, ayuda a los usuarios a reconocer aspectos arquitectónicos derivados de los requisitos definidos y validar la solución.

Cuando los problemas son detectados y localizados, el equipo de validación, establece de inmediato una lista de acciones correctivas para cada problema detectado. A continuación, el desarrollo del proceso, retorna a la etapa de especificación, en la que se toman las acciones correspondientes a fin de generar las correctas especificaciones.

4) Control de la gestión de requisitos. Los requisitos no pueden ser gestionados efectivamente sin un seguimiento [Toranzo, 2002], [Rilston, 2003]. En entornos de Data Warehouse, la gestión de configuración y cambios, debe ser llevada a cabo en los requisitos y en las esferas arquitectónicas. Esto involucra gestionar cambios, a requisitos acordados dentro del mismo documento o en documentos externos y posteriormente, extender el proceso a la arquitectura de la base de

35

datos, con el objetivo de eliminar el impacto que los cambios puedan tener en el esquema multidimensional. Para un análisis de referencias cruzadas entre los requisitos se utilizan las matrices de trazabilidad (TRaceability Matrices).

2.2.2.3. Ingeniería de Requisitos en proyectos de Business Intelligence.

En [Britos, 2008], se presenta una propuesta para elicitar requisitos en Data Mining para proyectos de Business Intelligence (DM-BI). En esta propuesta, se afirma que existe la necesidad de adaptar el proceso de ingeniería de requisitos tradicional, para su aplicación en proyectos de DM-BI. Esta afirmación, se basa en la premisa de que el análisis de requisitos para este tipo de proyectos, difiere sustancialmente del análisis de requisitos que se realiza en los sistemas de información convencionales. Evidencia de esta afirmación, se encuentra en la observación de los problemas más comúnmente presentados (relacionados con los requisitos) en el desarrollo de una amplia gama de proyectos de DM-BI, tales como: el cliente no comprendía las técnicas ni el léxico utilizado por el grupo que desarrolla el proyecto, el cliente no tenía claras las metas del proyecto de DM-BI o lo que se podía lograr con su desarrollo, o los modelos definidos por los desarrolladores eran diferentes a los que el cliente había previsto. Para resolver estos y otros problemas, es necesario educir información específica en cada proyecto de DM-BI. Esta información puede ser modelada por una lista de conceptos los cuales deben ser identificados. Basados en esta lista de conceptos que modelan la información relacionada con los problemas observados, se propuso un método compuesto por cinco pasos (figura 2.16). La propuesta se focaliza, en la identificación de información que permita comprender el dominio de un proyecto de Data Mining, en base a la experiencia en el desarrollo de este tipo de proyectos. Estos conceptos están relacionados con aspectos tales como: la comprensión del dominio del proyecto de DM-BI (establecimiento de los canales de comunicación necesarios, en un lenguaje común a todas las personas involucradas en el proyecto), conocimiento del dominio de los datos del proyecto (requisitos del proyecto, datos relacionados a estos requisitos, riesgos involucrados, restricciones y supuestos), la comprensión del alcance del proyecto (objetivos del proyecto, limitaciones, expectativas y riesgos), identificación de recursos humanos (lista de recursos humanos, sus restricciones, riesgos y limitaciones) y la selección de las herramientas adecuadas para el proyecto de DM-BI (herramientas adecuadas en concordancia a la información obtenida en los pasos anteriores).

Paso 1: Comprender el dominio del

proyecto

Paso 5: Seleccionar las correctas herramientas

de DM-BI

Paso 4: Identificar los recursos humanos y conocimientos

requeridos

Paso 3: Comprender el alcance del proyecto

Paso 2: Conocer el dominio de los datos del

proyecto

Figura No. 2.16. Proceso de elicitación de requisitos ([Britos, 2008]).

Posteriormente se plantea, cómo los requisitos pueden ser elicitados por un proceso de elicitación de requisitos para proyectos de Data Mining y cómo ellos pueden ser documentados por un conjunto de plantillas. Es decir existe un conjunto de plantillas

36

definidas en el proceso. Estas plantillas permiten la evolución del concepto, a través del proceso de elicitación de requisitos y están asociadas a cada concepto. En resumen, la propuesta está basada en una lista de requisitos de proyectos de DM-BI, los conceptos necesarios que deben ser educidos y un conjunto de plantillas para documentar lo elicitado y procesos asociados. El proceso propuesto y el conjunto de plantillas han sido afinadas en diversos casos y su efectividad ha sido demostrada.

2.2.2.4. Ingeniería de Requisitos en e-commerce.

E3-Value [Gordijn, 2000]. En el desarrollo de aplicaciones de comercio electrónico, el proceso de elicitación de requisitos no se realiza de la forma que muchos presuponen, esto es, un escenario en el cual los stakeholders, tienen requisitos tácitos que deben ser elicitados por los desarrolladores del sistema, es mejor verlo, como un proceso de creación de requisitos (figura 2.17). Las razones que lo justifican son, la naturaleza de las aplicaciones de comercio electrónico, el carácter innovador de los modelos de e-business y el rápido desarrollo de Internet y de las tecnologías Web.

En el diseño de un sistema de comercio electrónico, se deben abordar diferentes tipos de problemas tales como:

Figura No. 2.17. Proceso de diseño de e-business ([Gordijn, 2000]).

a) El diseño del modelo de negocios.

b) El diseño del proceso de negocios.

c) El diseño de la arquitectura de software.

37

La justificación de esta división, es la separación de intereses que diferentes stakeholders tienen, por ejemplo, un administrador general, deseará tomar decisiones respecto del modelo de negocios, pero no involucrarse fuertemente respecto de la arquitectura del software del sistema. De esta manera, la creación de requisitos en aplicaciones de comercio electrónico, se debe fundamentar en las diferentes visiones o intereses que los stakeholders tengan del sistema en construcción.

En el nivel más alto de la propuesta (figura 2.17), el interés se concentra en el modelo de negocios. Este modelo, describe la forma en que efectúan negocios los diferentes actores. Los stakeholders, son los administradores de compañías que participan en la ejecución del modelo de negocios, comerciantes y clientes. El diseño primario del modelo, es realizado por los diseñadores de negocios. Una razón importante para considerar un modelo de negocios en detalle, es que un modelo, es muy útil para resolver los conflictos de interés que se pudieran generar entre los diferentes stakeholders.

También se pueden generar conflictos entre los modelos de negocios, los procesos de negocios y la arquitectura de software, sin embargo, no existe un modelo sólido para representar el modelo de negocios. La idea de la propuesta presentada en [Gordijn, 2000], es que el análisis estructurado del valor, es una actividad crucial en el diseño de un modelo de negocios, lo cual permite canalizar adecuadamente los diferentes tipos de requisitos que existen en los tres puntos de vista o tres visiones presentadas en la figura 2.17. Para modelar el valor, se sugiere que un buen punto de partida es encontrar en la literatura de administración de negocios trabajos sobre la teoría del valor en microeconomía, el concepto de la cadena del valor o las nociones sobre la constelación del valor [Normann, 1994], [Gordijn, 2000].

La visión del proceso de negocios, en el nivel medio (figura 2.17), muestra qué actividades deberían ser ejecutadas y por quienes. También se deben representar los mensajes intercambiados entre actores que ejecutan las actividades. Los stakeholders son directores de niveles táctico y operacional, quienes son responsables de ejecutar la mayoría de los procesos y los encargados de ventas. Los ingenieros de procesos de negocios son los encargados del diseño. Para este proceso, existe un conjunto de técnicas útiles, como por ejemplo el UML [Fowler, 1997], [Gordijn, 2000], o técnicas de modelado de procesos basado en roles [Ould, 1995], [Gordijn, 2000].

Finalmente la vista de arquitectura de software, en el nivel inferior (figura 2.17), muestra el sistema de información y los componentes del software. En [Bass, 1997] una arquitectura de software se define, como una estructura o estructuras de un sistema, que incluye componentes de software, sus propiedades visibles externamente y las relaciones entre ellos. Para representar tipos diferentes de estructuras, se utilizan múltiples vistas arquitectónicas. En [Kruchten, 1995], [Gordijn, 2000] se usan cuatro vistas, la vista lógica, la vista del proceso, la vista física y la vista de desarrollo. Los stakeholder pueden ser, el encargado del departamento de Tecnologías de Información, en su rol de administrador y mantenedor de sistemas y el diseñador es el arquitecto de software.

Las técnicas de representación para arquitecturas de software están aún en una fase muy temprana de desarrollo, sin embargo el objetivo del artículo [Gordijn, 2000] es la

38

representación del modelo de negocios y cómo esta representación puede ser explorada para derivar requisitos arquitectónicos.

Conceptos fundamentales para representar el modelo de negocios. En la propuesta en estudio [Gordijn, 2000], el concepto central es que cualquier modelo de negocios resulte en una actividad de valor. Una actividad de valor, es realizada por actores y apunta a producir objetos materiales o intangibles, que sean de valor para otros. En un nivel macroeconómico, se puede utilizar este concepto para especificar un modelo de negocios, sin embargo utilizando además algunos conceptos de microeconomía, teoría de precios y la experiencia de los autores en el diseño de aplicaciones de comercio electrónico, se puede derivar un conjunto de conceptos fundamentales para una representación semi-formal de un modelo de negocios. Estos pueden ser representados en la figura 2.18 utilizando clases abstractas de UML. También se propone un enfoque de seis pasos que proporciona un camino práctico para trabajar con estos conceptos.

Figura No. 2.18. Conceptos claves para representar un modelo de negocios de una manera semi-formal ([Gordijn, 2000]).

Actor (Actor). Un actor, es una entidad independiente tal como una compañía o una persona.

Value Activity (Actividad de valor). Una actividad de valor, representa un proceso que agrega valor. Los actores ejecutan estas actividades. Un actor puede ejecutar múltiples actividades de valor, pero una actividad de valor particular, es ejecutada por un sólo actor.

Value Object and value object type (Objeto valor y tipo objeto valor). Objetos valor, son cosas que se intercambian entre actividades valor y pueden ser producidas o consumidas por una actividad de valor. Un tipo objeto valor, representa un recurso el cual es creado o utilizado por una actividad valor.

Value port (Puerto valor). Es necesario definir una manera formal, para indicar cómo actividades valor, pueden ser conectadas unas a otras de una forma reconfigurable y basada en componentes. Un puerto valor denota un punto de conexión de una actividad de valor, al mundo externo o a otras actividades de valor.

Value interface (Interface de valor). Los puertos valor, son agrupados dentro de interfaces de valor. Una interface de valor representa un servicio de comercio ofrecido o requerido desde una actividad de valor.

39

Enfoque de seis pasos para construir un modelo de e-business. Este enfoque, constituye un punto de partida genérico para desarrollar un modelo de e-business de una manera semi-formal. Los seis pasos de la propuesta, no necesariamente deben ejecutarse de una manera secuencial.

Paso 1. Identificación de los actores/stakeholders en el proceso de e-commerce.

Paso 2. Construcción de una lista de actividades de valor relevantes.

Paso 3. Definición de puertos valor, interfaces y tipos objetos valor asociados.

Paso 4. Asignación de actividades valor a los actores, incluyendo formas alternativas de asignación.

Paso 5. Análisis de compromisos que ocurran en modelos alternativos de negocio, producto de la aplicación de los cuatro primeros pasos.

Paso 6. Indagación de las implicaciones asociadas para los requisitos, en la arquitectura del sistema de información.

Finalmente se puede establecer que la creación de requisitos en una aplicación de comercio electrónico, debería empezar con un análisis basado en el valor, en el nivel de negocios. Para este fin se ha propuesto una nueva manera semi-formal, para representar un modelo de negocios, identificando un conjunto de conceptos claves limitado y genérico que debe ser considerado para construir dicho modelo.

2.2.2.5. Ingeniería de Requisitos en Automoción.

En [Weber, 2003] Matthias Weber y Joachim Weisbrod de DaimlerChrysler Research, detallan la aplicación de la Ingeniería de Requisitos (IR) en la industria del automóvil. El creciente aumento en los costes que ha experimentado, el desarrollo de los componentes eléctricos y electrónicos que cada vez son más complejos (actualmente un tercio de los costes que involucra el desarrollo de un modelo sofisticado, se consume en el diseño y desarrollo de los sistemas eléctricos y electrónicos, figura 2.19), justifican la aplicación de técnicas de Ingeniería de Requisitos en el industria del automóvil. Por otro lado, los sistemas convencionales de procesamiento de texto, ya no prestan un completo apoyo para la especificación de requisitos, debido a la complejidad de las actividades de especificación, en términos de la administración y seguimiento de la funcionalidad como ocurre en la Ingeniería del Software.

Proyectos de Ingeniería de Requisitos en Automoción.

Los sistemas automotores demandan complejas especificaciones de requisitos y DaimlerChrysler en los últimos años, ha asumido estos desafíos aplicando métodos y herramientas de IR en varios de sus proyectos desarrollados, los que cubren principalmente tres áreas:

a) Mantenimiento y telemática (Mercedes-Benz Technology Center, cuenta con cerca de 60 ingenieros para el diseño y especificación de sistemas de telemática en una sola serie de vehículos).

b) Interior de vehículos y confort de pasajeros (en esta área, en conjunto se tienen cerca de 70 características interconectadas y cada una tiene en promedio, cincuenta páginas de especificaciones).

40

c) Asistencia de conducción y seguridad de sistemas críticos.

Figura No. 2.19. Porcentaje de costes en el desarrollo de la electrónica ([Weber, 2003]).

Aunque los aspectos tratados no constituyen necesariamente el foco de la investigación en IR, los adelantos en este tema, son importantes para una adopción más generalizada de herramientas soportadas en IR en la industria del automóvil y también en otros dominios. El rango del tamaño de proyectos abordados, va desde pequeños, con dos a cinco desarrolladores trabajando en la base de datos de requisitos para generar unas pocas páginas de especificaciones, a proyectos mayores con una base de datos de aproximadamente 3 Gbytes, para generar más de 20 documentos de especificación de componentes de automoción.

Soporte de herramientas y técnicas en proyectos de IR en automoción [Meiyi, 2003].

En el desarrollo de proyectos de IR en automoción, tres herramientas de administración de requisitos fueron utilizadas: Dynamic Object Oriented Requirements (Doors), Requisite Pro y Requirements Traceability and Management (RTM). Las tres herramientas, soportan administración básica de bases de datos para requisitos individuales y sus atributos, sin embargo, difieren respecto de las interfaces de usuario, trabajo distribuido, conceptos de seguridad, mecanismos de extensibilidad e interfaces de importación y exportación. Como los requisitos textuales son insuficientes en automoción, toda la información sobre la complejidad de objetos diferentes, sus atributos y sus relaciones, se define formalmente en un modelo de metadatos. Un modelo de Administración de Requisitos de Información (ARI), es clave en la administración de requisitos. Así los ingenieros pueden utilizar ARI, para discutir sobre sus necesidades y cómo manejar especificaciones sistemáticamente. Para asegurar consistencia y reusabilidad, un ARI modular será introducido a futuro, para que nuevos proyectos puedan adaptarlo a la medida. Basándose en su experiencia, los ingenieros obtienen una vista general sobre las redundancias en un proyecto y las partes de documentos que han sido utilizadas son

41

anotadas en otra parte. De esta manera, ellos pueden evitar tener información redundante. Por otro lado considerando que los ingenieros trabajan en un entorno orientado a documentos, las herramientas de administración de requisitos deben ser capaces de mantener una vista de los documentos. A menudo los ingenieros tienen problemas en la presentación de contenidos. Un ARI bien definido e implementado por alguna herramienta de administración de requisitos, puede ayudar a mejorar la estructura y presentación de dichos contenidos. Para reutilizar documentos en futuros proyectos, éstos deben ser integrados dentro de un sistema de base de datos para la administración de requisitos. Durante la ejecución de los proyectos, los cambios son inevitables, por esta razón, diferentes ARIs uniformes se crean durante un proyecto, para limitar los cambios y reducir las adaptaciones no esenciales. Las vistas de usuario adaptables, constituyen un importante instrumento para guiar y administrar el proceso de especificaciones. Las prácticas de administración efectiva de requisitos y un apropiado soporte de herramientas, mejoran y facilitan sustancialmente el proceso de revisión. Las experiencias técnicas, incluyen desafíos relacionados al seguimiento, la integración de herramientas y la necesidad de contar con un mayor y más avanzado soporte de herramientas de administración de requisitos. Aunque las herramientas de administración de requisitos disponibles en la actualidad, son el mejor instrumento para desarrollar proyectos de IR, deberían ser mejoradas continuamente. En el futuro, se deberán incorporar conceptos de administración de requisitos en el Lenguaje de Modelamiento Unificado (UML). Experiencias en procesos relacionados, incluyen los desafíos derivados de especificaciones abstractas, requisitos no funcionales, cambio de requisitos y revisión de requisitos. Las técnicas que se usan, principalmente están enfocadas en la aplicación de casos de uso. La experiencia indica que es aconsejable convertir progresivamente los requisitos no funcionales, en un conjunto de requisitos funcionales, teniendo en cuenta que no es siempre posible. El trabajo de los autores [Weber, 2003], ha producido varios resultados importantes entre los que se pueden citar. Se ha establecido un equipo de trabajo en IR dentro de DaimlerChrysler research, que da soporte a las unidades de negocio de la compañía. Se ha definido un proceso genérico de IR para coordinar su trabajo y las discusiones de apoyo que se establecen con las unidades de negocio. Varias de estas unidades, adaptaron este proceso, a las necesidades específicas de sus clientes. Adicionalmente, se establecieron varios modelos específicos de administración de requisitos de información (ARI). Se generaron pautas para el uso de herramientas de administración de requisitos ad–hoc a sus procesos. Se evaluaron experiencias y se trabajó para acoplar estas herramientas, con otras de DaimlerChrysler. También se ha investigado en el desarrollo de prototipos y casos de estudio para mejorar las prácticas de IR. Los procesos, modelos y pautas generadas, se aplican en muchos proyectos pilotos para mejorar su desarrollo. Otros aportes importantes, son el desarrollo de diez extensiones específicas para Doors con cerca de cincuenta mil líneas de código. Una de estas extensiones, permite especificar y generar documentos de datos distribuidos, en la base de datos de Doors.

42

2.2.2.6. Ingeniería de Requisitos en Telecomunicaciones.

El área de las telecomunicaciones, es una de las tecnologías de mayor evolución y crecimiento en los últimos años, los avances han dado lugar a complejos sistemas de comunicaciones con diferentes tecnologías, constituyendo en su conjunto, un sistema globalmente distribuido. Por lo tanto el desarrollo de nuevos servicios con prestaciones de alta calidad, es un desafío permanente para los operadores de telecomunicaciones. En [Gerhard, 1997], se plantea la metodología denominada RATS (Requirements Assistant for Telecommunications Services), sustentada en que una de las mayores complicaciones que enfrenta el desarrollo de nuevos servicios, es la comprensión correcta de los requisitos, pues cada nuevo servicio, debe interactuar con servicios ya existentes. RATS es una metodología basada en un framework tridimensional para Ingeniería de Requisitos y sus directrices sugieren los pasos (figura 2.20) a realizar durante el diseño de nuevos servicios.

Cliente Ingeniero de Requisitos

El ultimo servicio

Elicitación de Requisitos

Análisis y Modelado de Requisitos

Especificación, validación y simulación de requisitos

Implementación de Requisitos, Pruebas y Mantención

Idea vaga

Idea ordenada Semi-formal Formal Formal

Herramientas RATS Herramientas SDL Service Logic Call Control Software

C-code

Figura No. 2.20. Diseño de un servicio de telecomunicaciones utilizando RATS

([Gerhard, 1997]).

Una descripción resumida de RATS ([Gerhard, 1997]) es la siguiente. El desarrollo de una nueva aplicación, se inicia con una idea vaga de lo que los clientes suponen o esperan que el nuevo servicio deba realizar. El cliente explica esta idea inicial de manera textual y se la entrega al departamento de marketing de un proveedor de servicios. Si el resultado de la evaluación del nuevo servicio solicitado, realizada por el departamento de marketing resulta positivo, se solicita a los expertos del dominio de negocio realizar un estudio de viabilidad. Si el nuevo estudio realizado resulta también positivo, se inicia el proceso de elicitación de los requisitos mediante entrevistas, cuestionarios y reuniones grupales para facilitar el proceso de recolección de la información requerida. El proceso de ingeniería de requisitos, involucra la estructuración de los requisitos y su representación de una manera semiformal con la ayuda de las herramientas propias de RATS. Esta estructuración constituye un hito importante que involucra un proceso extenso de análisis de requisitos e incluye un

43

proceso de descomposición en requisitos no funcionales y también el modelado de casos de uso para los requisitos funcionales. La salida de la aplicación de las herramientas de RATS, es la especificación de los servicios expresados mediante casos de uso, que luego se traducen a una forma más formal mediante SDL (Specification and Description Language), para posteriormente aplicar herramientas comerciales de generación de código automático. Para cada uno de los pasos descritos, se proveen diferentes alternativas de realizar comprobaciones.

Una de las principales críticas de las metodologías empleadas anteriormente, razón por la que se propuso RATS, es que los clientes no estaban realmente involucrados en el desarrollo de los servicios que les gustaría tener. El resultado era que las correcciones finales de producirse tardíamente durante el ciclo de vida de desarrollo, aumentaban drásticamente el tiempo de desarrollo y los costes. Por lo tanto, uno de los objetivos de la metodología RATS, es garantizar que el proceso de desarrollo este centrado en el cliente. Lo importante es ofrecer a los clientes, lo que realmente ellos necesitan y no lo que el diseñador piensa que los clientes podrían requerir, o lo que se puede ofrecer más fácilmente. Retroalimentación continua y acuerdo con los clientes son fundamentales para garantizar la aceptación del servicio que finalmente se entrega.

2.2.2.7. Ingeniería de Requisitos en otras áreas del conocimiento.

En muchas otras áreas de desarrollo, se proponen modelos de procesos de ingeniería de requisitos que aplican las técnicas y actividades propias del proceso de ingeniería de requisitos. Entre algunas, se pueden citar las siguientes: control de sistemas para plantas de energía nuclear, sistemas de aviónica, sistemas de control de iluminación, sistemas embebidos de tiempo real, sistemas complejos (método SCR, Software Cost Reduction), sistemas de detección de intrusos, [Heitmeyer, 2000], [Heninger, 1978], [Heninger, 1980], [Slagell, 2002]. También existen abundantes investigaciones en ingeniería de requisitos de seguridad [Knorr, 2001], [Leiwo, 1999], bajo la consideración de que a menudo se confunden los requisitos de seguridad, con la arquitectura de los mecanismos de seguridad que tradicionalmente son utilizados. En [Firesmith, 2003] se definen diferentes tipos de requisitos de seguridad y se proveen ejemplos y guías asociadas con el propósito de capacitar a los ingenieros de requisitos, en la especificación de requisitos de seguridad sin limitar innecesariamente la arquitectura y seguridad, utilizando los recursos más apropiados. 2.2.3. Metodologías en Ingeniería de Requisitos. En la sección anterior (2.2.2), se estudiaron diversas propuestas de modelos de proceso de Ingeniería de Requisitos, utilizadas en diferentes campos de aplicación (Ingeniería de Software, Data Warehouse, e-commerce, etc.), entendiéndose por modelo de proceso, como la forma en que se organizan las tareas o actividades que componen el proceso para desarrollar cierto cometido. A diferencia de un modelo de proceso, una metodología puede definirse como una instancia de un modelo proceso, en la cual se especifica además la manera de desarrollar cada una de las tareas o actividades que componen el modelo de proceso [Marbán, 2008]. En este sentido a continuación se presentan algunas metodologías de Ingeniería de Requisitos que han sido propuestas en la literatura.

44

2.2.3.1. DorCU.

Respecto de las metodologías utilizadas en IR o en gestión de requisitos, Báez G. y Barba S. [Báez, 2002], plantean basándose en la descomposición de las tres etapas del eje central del proceso de IR (elicitación, especificación y validación), la metodología denominada DoRCU (Documentación de Requisitos Centrada en el Usuario). DoRCU [Báez, 2002], [Bahamonde, 2003] “es una metodología para la Ingeniería de Requisitos, caracterizada por su flexibilidad y orientación al usuario. Esta metodología considera los mejores resultados de otros enfoques estudiados y se apoya en diversos métodos, técnicas y herramientas desarrolladas por otros autores, sin comprometerse con un paradigma particular”. Esta metodología consta de cuatro fases: elicitación de requisitos, análisis de requisitos, especificación de requisitos y validación y certificación de los requisitos. La interrelación de estas fases se ilustra en la figura 2.21. A continuación se describen estas etapas y las tareas que cada una involucra.

ELICITACIÓN ANÁLISIS ESPECIFICA-CION

VALIDACIÓN Y CERTIFICA-

CIÓN

INGENIERÍA DE REQUERIMIENTOS

DoRCU

UdI

Ingeniería de

Software

De

DE

De

DP

De

DA

De

DRu

De

DRt

Figura No. 2.21. Fases de la metodología DoRCU ([Báez, 2002]).

Elicitación de Requisitos. Está fase está destinada a la adquisición de conocimiento e información, es la instancia en que equipos multidisciplinarios trabajan en conjunto con el cliente/usuario para obtener los requisitos reales de la mejor manera, recurriendo por ejemplo a la observación, lectura de documentos y entrevistas y cuestionarios, entre otras técnicas. Esta fase se lleva a cabo, de acuerdo a un conjunto de pasos que se especifican en la figura 2.22, los que son tomados de la metodología planteada en [Christel, 1992]. Análisis de Requisitos. Esta fase tiene como objetivo, estudiar los requisitos que se obtuvieron en la etapa anterior, detectando probables ambigüedades, contradicciones u omisiones. Se debe tener presente siempre, que este proceso es iterativo, esto es, que los resultados obtenidos en esta etapa, pueden significar el retornar a la etapa anterior. En esta fase ya se efectúa una primera aproximación a un lenguaje más técnico. Al igual

45

que la fase anterior, ésta fase se divide también en una secuencia de pasos los cuales se nombran a continuación:

Figura No. 2.22. Tareas realizadas en la fase de Elicitación ([Báez, 2002]).

oo Reducir ambigüedades en los requisitos.

oo Traducir a lenguaje técnico los requisitos.

Esta traducción, tiene como meta, aproximar los términos utilizados por los usuarios, a los términos del sistema de software.

oo Plantear un modelo lógico.

A partir de los resultados de la etapa anterior, generar una estructura preliminar, es decir, construir un modelo del problema, ya sea en términos de diagramas de flujo, u otro tipo de representación que se considere conveniente para el modelado y que permita establecer un vínculo con la siguiente etapa.

oo Documentar la etapa.

Especificación de Requisitos. En función de la información recogida y procesada en las fases anteriores, en esta etapa se procede a la descripción de requisitos, recordando siempre el carácter iterativo del proceso. En esta fase es posible identificar la siguiente secuencia de tareas a desarrollar:

oo Determinar el tipo de requisito.

oo Elegir la herramienta de especificación acorde al tipo de requisito.

oo Especificar de acuerdo a la herramienta seleccionada.

46

oo Documentar la etapa.

La última tarea tiene por objetivo, el generar un documento, en base a los modelos formales o semiformales que se han elaborado al realizar la especificación de los requisitos. Este documento, más adelante y después de validado, se transformará en el documento de requisitos técnico (DRT). A partir del cual también se emitirá un documento de requisitos orientado al usuario (DRU), el cual es una traducción a un lenguaje comprensible por el usuario. Validación y Certificación de los Requisitos. Finalmente en esta fase, se procede a la generación del Documento de Requisitos, después de haber efectuado un proceso de validación de la información recogida y procesada en las etapas anteriores. Este documento, está dividido, en dos: uno destinado al cliente/usuario, para efectos de la certificación de los requisitos y el otro técnico, para alimentar al resto de las etapas de la Ingeniería de Software. Para concluir, esta fase al igual que las anteriores, se descompone en una secuencia de tareas que deben ser desarrolladas, las cuales se enumeran a continuación.

1) Seleccionar las fuentes de información entre DE (documento de elicitación) y DA (documento de análisis) a fin de validar el DP (documento de especificación).

2) Elegir o diseñar el modelo de documento, acorde al grado de detalle requerido y al lector final.

3) Elegir la herramienta de documentación que mejor se adapta al modelo seleccionado.

4) Documentar respetando los estándares del documento de requisitos.

5) Verificar que el Documento de Requisitos de usuario (DRU) sea isomórfico, con el Documento de Requisitos técnico (DRT).

6) Certificar el documento de requisitos DRU a través de la conformidad del usuario.

Para una descripción detallada de en qué consiste cada una de las tareas en que se descompone cada fase, es posible consultar el artículo de la referencia [Báez, 2002]. Esta metodología, de acuerdo a los autores de la misma, aporta las pautas para entender otras metodologías propuestas, contribuye a un mejor entendimiento de la IR, ofrece libertad para la selección e integración de diferentes herramientas a emplear en cada fase del proceso, contempla aspectos metodológicos destinados a lograr un documento de requisitos de clara interpretación, puede ser aplicada a diferentes paradigmas y cubre errores en el tipo de documentación generados al proponer documentos isomórficos (DRT, y DRU).

2.2.3.2. Bibliotecas.

Debbie Richards [Richards, 2000], también basado en algunos de los elementos ya discutidos del proceso de IR, plantea un modelo para el proceso de toma de requisitos descrito en su artículo “A Process Model for Requirements Elicitation”. Richards parte indicando que a pesar de las múltiples mejoras hechas en varias de las actividades involucradas en el proceso de desarrollo de software, la elicitación, análisis y modelado

47

de requisitos de usuario, son las actividades menos exploradas, y afirma que estas actividades son las más importantes, pues una validación y corrección temprana de los requisitos de usuario, ahorraría muchos de los problemas asociados al desarrollo de software, particularmente en la fase de manutención. Está claro, que es mucho más barato detectar y corregir errores temprano dentro del ciclo de desarrollo de software, que más tarde [Davis et. al., 1997].También aporta muchos otros comentarios y razones publicados en diversos artículos, que justifican la afirmación de que la Ingeniería de Requisitos, es un área muy interesante para desarrollar esfuerzos en su investigación. Apoyado en estas razones, Debbie Richards plantea su modelo, el cual se basa fundamentalmente en las fases de elicitación, modelado y validación, utilizando algunas técnicas de Adquisición de Conocimiento (KA), particularmente RDR (Ripple Down Rules) para la fase elicitación de requisitos y la técnica de modelado conceptual Formal Concept Analysis (FCA) para el análisis de requisitos. RDR, es un razonamiento híbrido basado en casos y una aproximación basada en reglas para KA, que permite el almacenamiento de conocimiento como reglas en una determinada estructura. Los casos son utilizados para la adquisición de conocimiento y para guiar al experto en la definición de reglas, proporcionando validación automática de conocimiento [Compton et. al. 1991]. Para el caso en estudio, los requisitos son vistos como un tipo de conocimiento y por tanto el uso de técnicas de KA puede ser de relevancia. Los requisitos, son normalmente elicitados en lenguaje natural durante sesiones iterativas entre usuarios y desarrolladores. En el trabajo descrito se experimenta con una versión comercial de “Múltiple Clasificación RDR (MCRDR) [Kang et. al., 1995]”, para la captura de requisitos desde el lenguaje natural. Las reglas adquiridas usando MCRDR, así como los requisitos, deben ser convertidos a un formato especial “Crosstable” (Crosstable, es equivalente a una tabla de decisión en formato binario) y son usados como entradas del FCA. Un concepto en FCA se comprende de un conjunto de objetos y un conjunto de atributos asociados a estos objetos. El conocimiento, visto y aplicado a un contexto restringido, puede ser representado como un Crosstable y definido como un contexto formal, es decir una tupla (G,M,I), donde G es el conjunto de objetos que forman la extensión del concepto, M es el conjunto de atributos que forman la intención del concepto e I es una relación binaria que conecta G con M. Los Crosstables son usados para capturar las relaciones entre objetos y atributos, donde las filas son los objetos, las columnas los atributos y una cruz (X) en la intersección, indica que un objeto tiene su correspondiente atributo. El modelo planteado es desarrollado en cinco pasos que se ejecutan iterativamente hasta que las partes, están conformes con la especificación realizada.

1) Adquisición y conversión de requisitos. Esta fase es actualmente la menos explorada y presenta aún algunos problemas a resolver. El diseño final de esta fase dependerá de varios casos de estudio y experimentos que serán realizados. Los autores desean utilizar requisitos en una variedad de formas tales como diagramas de flujo de datos, descripción de casos de uso o tablas de decisión. Sin embargo actualmente sólo es posible hacer uso de conocimiento que pueda ser representado como un Crosstable. Las tablas de decisión son comúnmente utilizadas para representar conocimiento y no parecen ser restrictivas.

48

La conversión de requisitos, es el proceso de asegurar que los diferentes puntos de vista elicitados, estén representados en formatos comparables. Todos los formatos son mapeados en una tabla cruzada para poder utilizar FCA en las subsecuentes fases.

Source-

borrower Input book

Input card

Action Check-

in

Action Check-

out

Output book

Output card

Output Database update

Dest. Borrower

Dest. catalogue

Dest. librarian

1-%BCKIN X X X X X 2-%BCKIN X X X X X 3-%BCOUT X X X X X X 4-%BCOUT X X X X X

Figura No. 2.23. Contexto de “biblioteca desde el punto de vista de un empleado”

([Richards, 2000]). 2) La generación de conceptos. En esta fase, un Crosstable, es interpretado como un

contexto formal y FCA es utilizado para derivar los conceptos asociados con cada punto de vista. Considerando que la fase 1 está aún bajo estudio, se toman los requisitos del dominio de una biblioteca que será usada como salida de la primera fase. Un subconjunto de los requisitos, se representa en figura 2.23 qué muestra el contexto formal “K” para el punto de vista del empleado “n”.

3) La comparación de conceptos y detección de conflictos. Los conceptos generados por cada punto de vista en la fase dos, ahora son comparados. El modelo de comparación elegido es el de cuatro cuadrantes, el cual clasifica dos modelos conceptuales en uno de cuatro estados.

a) Consenso, es la situación donde expertos describen los mismos conceptos utilizando la misma terminología.

b) Correspondencia, ocurre cuando expertos describen los mismos conceptos utilizando diferente terminología.

c) Conflicto, es cuando diferentes conceptos son descritos bajo los mismos términos.

d) Contraste, es cuando no hay similitud entre conceptos o la terminología utilizada.

4) La negociación. En esta fase los conflictos son manejados o resueltos. Existe un amplio rango de estrategias que pueden ser utilizadas en función de los tipos de conflicto detectados en la fase anterior, como por ejemplo, negociación, arbitrio, coerción o educación. En todo caso, diversos autores ofrecen diferentes estrategias que pueden ser utilizadas [Richards, 2000].

5) Evaluación. Finalmente en esta fase se determina mediante alguna técnica, el grado de conflicto para observar si los diferentes puntos de vista se están moviendo a un punto de convergencia o si se requiere incorporar otro ciclo del proceso.

Para concluir, se indica que el modelo requiere una mayor investigación, particularmente en la primera fase y se pretende generalizar el proceso y evaluarlo.

49

2.2.3.3. Ancora.

Otra de las metodologías propuestas, es la metodología Ancora (Análisis de Requisitos Conducente al Reuso de Artefactos) [Sumano, 2002]. Esta metodología al igual que las anteriores, también se basa en algunas de las actividades fundamentales del proceso de Ingeniería de Requisitos ya descritas, esto es, la educción de requisitos, el análisis y la validación. El ciclo de vida de Ancora se divide en un conjunto de cinco etapas las cuales son descritas a continuación:

1. Entendimiento del Dominio y Contexto de la Aplicación. El objetivo de ésta etapa, es definir claramente las metas de la organización, el dominio de la aplicación, las actividades que actualmente lleva a cabo el sistema, así como la justificación del nuevo sistema.

2. Recolección y clasificación de requisitos. El producto de esta etapa, es la propuesta computacional del nuevo sistema.

3. Reutilización de requisitos. Lo que se busca en esta etapa, es dar a los analistas, recursos de otros sistemas que ya están probados y cuyas especificaciones de requisitos se encuentran ya en una base de datos de reutilización.

4. Resolución de conflictos, priorización y validación de requisitos. Para ello, se realizan las reuniones de Reflexión y Diseño.

5. Cierre. En donde se dan pautas al desarrollador de software, para pasar a las siguientes etapas de desarrollo.

Los autores de la referencia, afirman que esta metodología ha sido utilizada exitosamente en más de cincuenta proyectos de software, con gran satisfacción por parte de los usuarios.

2.2.3.4. IBRA.

IBRA (Inquiry-Based Requirements Analisys o análisis de requisitos basado en preguntas), propuesta por Antón A., Potts C. y Takahashi K. [Antón, 1994] es otra metodología de análisis de requisitos. El análisis de requisitos basado en preguntas, consiste en la propuesta de una estructura cíclica denominada “Inquiry Cycle” (figura 2.24), la cual sirve de guía en la gestión de los requisitos.

Figura No. 2.24. Estructura cíclica del modelo (elaborado en base a [Antón, 1994]).

Evolución de los Requisitos

Especificación de Requisitos

Análisis de Requisitos

Propuestas

Decisión

Cambios

50

Este modelo se divide en tres etapas: la especificación de requisitos, análisis y discusión y la evolución de los mismos. Una descripción de cada una de estas etapas es la siguiente:

oo Especificación de Requisitos: En esta etapa, las partes involucradas en el proyecto (stakeholders) definen una propuesta de requisitos, en la cual los requisitos pueden ser representados mediante descripciones narrativas, casos de uso u otros artefactos o simplemente como una descripción de los objetivos del sistema en desarrollo.

oo Análisis de Requisitos: En esta etapa, cada una de las partes involucradas en el proyecto, debe revisar cada uno de los requisitos especificados en la etapa anterior y realizar las consultas o anotaciones pertinentes, es decir se debe generar una discusión en torno a las consultas, respuestas o justificaciones planteadas. Este proceso permite aclarar los conceptos y tener un detallado y mejor entendimiento sobre cada uno de los requisitos planteados y por consiguiente detectar ambigüedades, omisiones o restricciones.

oo Evolución de los Requisitos: En esta tercera etapa y en base a la discusión generada en la etapa anterior, se llega a un acuerdo entre los distintos stakeholders, permitiendo obtener una versión refinada de los requisitos del sistema. Esta versión refinada, es el resultado de la modificación, eliminación o inclusión de algún requisito.

Finalmente los autores recomiendan tomar en cuenta a la hora de aplicar el modelo, los siguientes aspectos:

oo El modelo debe ser dinámico.

oo No debe estar asociado a un lenguaje de especificación o estilo de expresión.

oo Es útil aplicarlo con el respaldo de tecnología de hipertexto, pero esta no es una condición obligatoria.

2.2.3.5. KBSA.

En el año 1983, se propone a la U. S. Air Force's Rome Laboratory (RL), iniciar la creación de KBSA (Knowledge-Based Software Assistant) [Boehm, 1998]. El programa de investigación se inicia y RL organiza una conferencia anual sobre Ingeniería de Software basada en conocimiento que tiene como meta, promover el intercambio de investigaciones sobre KBSA. Este programa de investigación, genera una primera versión de un enfoque basado en conocimiento para el desarrollo de software, con un interesante rol en el diseño. KBSA existe ahora en la forma de un prototipo de demostración, apropiado para ilustrar importantes conceptos de un enfoque basado en conocimiento para el desarrollo de software. La visión o idea fundamental que sustenta al enfoque KBSA [Boehm, 1998], [Green, 1983], es la explotación de los conceptos y representaciones de inteligencia artificial, la captura y utilización del conocimiento para alcanzar importantes mejoras en el desarrollo y la manutención de software involucrando los siguientes avances técnicos:

1. Generación automática de software a partir de especificaciones formales.

51

2. Evolución y manutención de software mediante la modificación de las especificaciones, más que la modificación del código fuente en sí.

3. Un modelo del ciclo de vida, organizado alrededor del desarrollo de especificaciones, iteración de directivas de generación automática de programas para lograr la calidad de software deseado y subsecuentemente, manipulación de especificaciones para acomodar cambios en el software.

4. “Actividades de coordinación” basadas en conocimiento, para el desarrollo de software y herramientas de administración.

Figura No. 2.25. Proceso de ingeniería de software basado en conocimiento ([DACS, 2008]).

En los diferentes tipos de productos, el conocimiento específico a elicitar, está compuesto por los requisitos del usuario, las especificaciones del sistema, el código, los escenarios de prueba y la documentación. Un modelo de Ingeniería de Software basado en conocimiento se ilustra en la figura 2.25.

KBSA, apoya a un analista en el desarrollo de especificaciones formales. KBSA, codifica las reglas como típicamente se hace en un Sistema Experto. Las reglas registran el conocimiento del experto, acerca del dominio para el cual la aplicación es desarrollada. La especificación formal es ejecutable y en consecuencia sirve como un prototipo que puede ser validado por los usuarios. Una vez que las especificaciones se completan, son transformadas automáticamente a código fuente. En esta etapa, cualquier decisión de diseño realizada por KBSA es registrada, y podría ser que se requiera alguna entrada adicional provista por los diseñadores para generar el programa fuente final. Estas entradas también son registradas. Cualquier cambio de requisitos en el sistema durante su ejecución y manutención, se realiza modificando primero la especificación y luego automáticamente se regenera el código fuente, utilizando las decisiones registradas en transformaciones previas.

Las decisiones de diseño en este proceso (diferente al tradicional modelo en cascada), se desarrollan en dos etapas. Primero, las decisiones transforman las especificaciones a código fuente y luego se procede a colocar a punto el sistema desarrollado. El KBSA intenta automatizar las decisiones, evitando en lo posible la participación humana.

52

KBSA también puede deducir automáticamente las consecuencias de muchas decisiones de diseño, además de automatizar algunas de las decisiones más obvias.

Un menor nivel de automatización, es posible para decisiones de alto nivel durante la fase de análisis de requisitos, pero KBSA apoya al experto diseñador con un conjunto de buenas herramientas.

Finalmente, las metas de optimización deben provenir del diseñador o conocedor del dominio del problema, pero la implementación detallada del diseño que satisfaga tales metas, debe incrementalmente ser automatizada.

2.2.3.6. VORD

VORD (Viewpoint-Oriented Requirements Definition, Definición de Requisitos Orientada a Puntos de Vista) [Kotonya, 1998], es un método que ha sido propuesto principalmente para la especificación de sistemas interactivos, sin embargo puede ser también utilizado para especificar otras clases de sistemas. Este método está basado en el enfoque de los puntos de vista de los usuarios involucrados en los aspectos organizacionales. El modelo adoptado para puntos de vista, está orientado a los servicios, el sistema da servicios a los puntos de vista y los puntos de vista pasan información de control y parámetros asociados al sistema. Los puntos de vista mapean las clases de usuarios finales de un sistema o de otro interconectado. Los puntos de vista que constituyen el núcleo del modelo, son conocidos como puntos de vista directos, por el hecho de que no todos los requisitos son derivados de personas o subsistemas que interactúan con el sistema. También son considerados los puntos de vista relacionados con la influencia del sistema, sobre el dominio de la aplicación, estos son llamados puntos de vista indirectos. Puntos de vista directos e indirectos son definidos de la siguiente forma [Kotonya, 1998]:

a) Puntos de vista Directos. Corresponden directamente a clientes que reciben servicios del sistema y envían información de datos y de control al sistema. Puntos de vista directos, pueden ser ya sea un sistema usuario/operador u otro subsistema que interactúa con el sistema ya analizado.

b) Puntos de vista Indirectos. Los puntos de vista indirectos tienen un interés en algunos o todos los servicios entregados por el sistema, pero no interactúan directamente con él, estos pueden generar requisitos que restringen los servicios entregados a los puntos de vista directos.

Los puntos de vista indirectos, pueden variar desde los puntos de vista de la ingeniería (éstos se relacionan con el diseño e implementación del sistema), por medio de puntos de vista organizacionales (se refieren a la influencia del sistema sobre la organización), hasta puntos de vista externos (se refieren a la influencia del sistema en el ambiente externo). El método VORD [Medina, 2004] está basado en tres pasos iterativos:

1. Identificación y estructuración de los puntos de vista. 2. Documentación de los puntos de vista.

53

3. Análisis y especificación de los requisitos de puntos de vista. En el primer paso, se trata de identificar los puntos de vista que son declaraciones abstractas de las necesidades de la organización, el segundo paso consiste en documentar los puntos de vista identificados en el primer paso, y el tercer paso se relaciona con la identificación de errores, conflictos y su solución. El resultado final es el documento de la especificación de requisitos. La figura 2.26 muestra el proceso del modelo iterativo VORD.

Figura No. 2.26. Proceso VORD ([Medina, 2004]).

2.2.3.7. VOLERE

VOLERE, es el resultado de muchos años de práctica, consultoría e investigación en el área de la Ingeniería de Requisitos, fue desarrollado por James y Suzanne Robertson [Volere, 2005], [Robertson, 1999] y su primera versión se libero en 1995. VOLERE consiste en un marco de trabajo para la adquisición y análisis de los requisitos de un sistema. Sus principales subsistemas [Volere, 2005], son el Shell y la Plantilla de especificación de requisitos.

El Shell de VOLERE, consta de diez componentes principales los cuales son [AU, 2001]:

oo Los requisitos oo La descripción oo Los fundamentos oo Las fuentes oo Criterios apropiados oo Clientes (satisfacción y descontento) oo Las dependencias oo Los conflictos oo Materiales de soporte oo La historia.

Mientras que la Plantilla de VOLERE, se compone de los siguientes componentes fundamentales:

54

oo Las restricciones del producto oo Los requisitos funcionales y no funcionales oo Conductores del proyecto oo Tópicos del proyecto

Figura No. 2.27. Descripción gráfica del Shell de VOLERE [Robertson, 1999].

La figura 2.27, describe gráficamente los componentes que constituyen el Shell. Una descripción resumida de cada uno de sus componentes es la siguiente:

oo Requisitos: Los campos que componen el ítem requisitos son:

Numeración de Requisitos. Se asigna a cada requisito un identificador único, para facilitar su seguimiento durante el desarrollo del proyecto.

Tipo de requisitos. Es el número de sección desde la plantilla, que corresponde a este tipo de requisito.

Event/Use Case #. Es el identificador del evento de negocio del producto, cuya respuesta tiene este requisito o el número de caso de uso del producto que contiene este requisito.

oo Descripción: En este ítem, se realiza una descripción resumida del requisito.

oo Fundamento: Se explica por qué se considera que el requisito es importante. Sirve como una herramienta para ayudar a que las personas descubran, la intención real del requisito real.

oo Las fuentes: Indica quien generó este requisito.

oo Criterios adecuados: Es una medida objetiva del significado del requisito; es el criterio para evaluar si una solución dada, satisface o no el requisito.

oo Clientes (satisfacción y descontento): Es una medida del grado de satisfacción del cliente.

55

oo Dependencias: En este ítem, se almacena un historial de otros requisitos que tienen un impacto sobre el descrito.

oo Conflictos: En este ítem, se guarda el registro de otros requisitos que discrepen con el requisito en cuestión.

oo Materiales de soporte: Éste es un puntero a documentos que ilustran y explican el requisito en cuestión.

oo Historia: Se guarda un historial de todos los cambios efectuados al requisito descrito.

Figura No. 2.28. Mapa Simplificado del Proceso de Requisitos de VOLERE [Robertson, 1999].

Respecto de los componentes de la Plantilla de VOLERE, estos son descritos a continuación:

oo Restricciones del proyecto: Las restricciones del proyecto, identifican cómo el eventual producto, se debe adecuar a restricciones de tipo técnico y económico.

oo Requisitos funcionales: Son los requisitos esenciales del producto y pueden ser medidos por métodos concretos.

oo Requisitos no funcionales: Son las propiedades de desempeño que funciones específicas deben tener, tales como la funcionalidad, usabilidad, restricciones temporales, etc...

oo Conductores del Proyecto: Son todas las personas relacionadas con el negocio, es decir los Stakeholders.

56

oo Tópicos del negocio: Definen las condiciones bajo las cuales el proyecto será realizado, es decir, los factores que contribuyen al éxito o fracaso del proyecto, y cómo los administradores, pueden utilizar los requisitos como entrada para la gestión de un proyecto.

El modelo de proceso de requisitos VOLERE [Robertson, 1999], se organiza como una jerarquía de procesos (figura 2.28), que parte del diagrama 1 denominado Project Blastoff. Este modelo de proceso, es un modelo genérico de los procesos necesarios para elicitar, especificar y validar los requisitos de un sistema. El modelo se focaliza en el contenido, las dependencias entre los procesos se definen en las interfaces. El modelo es una red asíncrona y cualquier combinación de procesos puede estar activa en cualquier momento.

El método VOLERE, ha sido utilizado efectivamente por diversas organizaciones en el mundo, como una herramienta fundamental para descubrir, organizar y comunicar sus requisitos en el desarrollo de un gran número de proyectos (http://www.volere.co.uk /experience.htm).

2.2.4. Técnicas de Ingeniería de Requisitos. El uso del término "ingeniería", se deriva del hecho de que en el proceso de educción de requisitos, se deben utilizar técnicas sistemáticas y repetibles, para asegurar que los requisitos del sistema sean completos, consistentes y relevantes [Kotonya, 1998]. A lo largo del tiempo, se han planteado diversas técnicas para la elicitación de requisitos, las que de acuerdo a determinadas características comunes, pueden ser clasificadas en [Rilston, 2003]:

o Técnicas tradicionales: Utilizadas normalmente en diversas áreas del conocimiento, incluyen el uso de cuestionarios, entrevistas [Goguen, 1993] y análisis de documentos existentes [Gómez, 1997].

o Técnicas de elicitación en grupo: Orientadas a comprender y descubrir el conocimiento y comportamiento grupal, como un intento de captar de manera más detallada las necesidades de los usuarios. En esta categoría se pueden citar técnicas como Brainstorming [Arango 2002], Focus Group [Medina, 2004], [Goguen, 1993], Workshop [Medina, 2004] o sesiones JAD [Raghavan, 1994], [Goguen, 1993].

o Prototipos: Utilizado en ambientes donde existe una alto grado de incertidumbre o cuando es necesario contar con retroalimentación de los usuarios [Kotonya, 1998].

o Técnicas dirigidas por el modelo: Estas técnicas, presentan un modelo específico del tipo de información a ser recolectada. Se usa este modelo, para llevar a cabo el proceso de elicitación. Estas técnicas incluyen métodos basados en metas tales como KAOS [Lamsweerde, 1991], [Rilston, 2003] e I* [Yu, 1995] y métodos basados en escenarios tales como Casos de Uso [Jacobson, 1993] y CREW [Maiden, 1998], [Rilston, 2003], las cuales tiene como objetivo representar las tareas que los usuarios ejecutan normalmente y aquellas que desean ejecutar.

57

o Técnicas cognitivas: Estas técnicas fueron originalmente desarrolladas para adquirir conocimiento en Sistemas Basados en Conocimiento, entre ellas se pueden citar: Análisis de protocolos [Gómez, 1997], Laddering [Rugg, 2003], Card Sorting y Repertory Grids [Milton, 2003].

o Técnicas contextuales: Surgen en los años 90 como una alternativa a las técnicas tradicionales y a las cognoscitivas. Incluyen el uso de técnicas etnográficas y análisis social [Sommerville, 2002], [Viller, 1999], [Rilston, 2003], para las cuales el trabajo es una actividad social que involucra a un conjunto de personas que cooperan para el desarrollo de diferentes tareas en la organización. La naturaleza de esta cooperación, es frecuentemente compleja y variable de acuerdo a las personas involucradas y el medio ambiente en que está inserta la organización.

Otra clasificación que ha sido propuesta de acuerdo a su nivel de aplicación [Tovar, 2004] es:

oo Técnicas de bajo nivel: Las cuales consisten en la aplicación de tácticas específicas, entre éstas se pueden citar a modo de ejemplo: lluvia de ideas (brainstorming) [Arango 2002] y entrevistas [Goguen, 1993].

oo Técnicas de alto nivel: Desarrolladas para amplios entornos de aplicación, entre las cuales se pueden enunciar las técnicas: JAD [Raghavan, 1994], [Goguen, 1993] y Prototipado [Kotonya, 1998]. La utilización de una u otra técnica, dependerá de la naturaleza del problema que se desee resolver sin dejar de considerar, el alcance del proyecto y su nivel de comprensión.

Independientemente de sus características o nivel de aplicación, toda técnica debe considerar al menos: las fuentes de información correctas, el diseño de consultas adecuadas, el análisis de la información, la confirmación de la correcta comprensión de las respuestas y la síntesis de la información colectada. Algunas de las técnicas mayormente utilizadas se enuncian a continuación [Rilston, 2003] [Tovar, 2004], [Arango, 2002], [Gause, 1989], [Komer, 1993], [Bahamonde, 2003], [Choque, 2003].

2.2.4.1. Brainstorming (lluvia de ideas).

Esta técnica [Arango, 2002] es ampliamente utilizada en diversas áreas y se basa en estimular la creatividad del equipo que participa en un proyecto. Todos deben aportar con ideas, las cuales no deben ser evaluadas hasta el final del proceso (cuando ya nadie más aporta nuevas ideas) [Gause, 1989]. Esta técnica permite generar diversas vistas del problema y formularlo desde diferentes puntos de vista, sobre todo al inicio de la fase de la toma de requisitos, donde las vistas del problema son aún difusas. Normalmente las reuniones cuentan con un número de entre cuatro y diez participantes, y de entre ellos se elige a un jefe de sesión, quien es el encargado de dar inicio a la reunión, más que de moderarla. Esta técnica se desarrolla normalmente en cuatro fases [Raghavan, 1994]:

1) Fase de preparación. La primera fase de esta técnica, es la de preparación para una reunión o sesión, esto implica determinar quiénes serán los que participarán en la sesión, en qué lugar se llevará a cabo y quién asumirá el

58

cargo de jefe de sesión. Para el caso particular del proceso de elicitación de requisitos, las personas que deben participar en la reunión, deben ser normalmente: los clientes, usuarios, desarrolladores, ingenieros de requisitos y si se precisa, algún experto en temas relativos al problema.

2) Fase de generación. En esta segunda fase, el jefe de sesión da inicio a la sesión de trabajo, exponiendo aspectos generales del problema a ser tratado. Sobre esta base, a continuación, todos los participantes de la reunión van aportando libremente todas las ideas que se les ocurra a cerca del tema expuesto. El jefe de sesión, normalmente cede la palabra a los participantes, de forma ordenada o aleatoria, hasta que finalmente decide detener el proceso ya sea, porque se está generando un número excesivo de ideas o bien porque ya se cumplió el tiempo asignado a la sesión.

En esta fase del proceso es conveniente observar algunas reglas, tales como: No se deben permitir críticas a las ideas aportadas por los participantes, se debe fomentar la generación de un número importante de ideas, se debe estimular a los participantes a complementar y enriquecer las ideas que se consideren más relevantes y finalmente se deben estimular las ideas que se consideren más relevantes.

3) Fase de consolidación. En la tercera fase, denominada de consolidación, se deben revisar las ideas generadas en la etapa anterior, identificando ideas equivalentes para posteriormente organizarlas. Determinadas ideas que el grupo considere, se deben descartar, priorizando las ideas que se consideren de mayor relevancia y aporte a la solución del problema. Después de ser evaluadas, éstas se deben clasificar en esenciales, no estrictamente esenciales y las apropiadas para ser tratadas a futuro.

4) Fase de documentación. Una vez concluida la sesión, el jefe debe generar un documento que contenga todos los principales aspectos tratados, ideas generadas, y comentarios finales.

Algunas ventajas de esta técnica frente a otras como JAD, son su simplicidad, el hecho de que no precisa de una compleja organización y el que pueda llevarse a efecto incluso mediante videoconferencias. Sin embargo, al ser un proceso poco estructurado puede producir resultados de baja calidad.

2.2.4.2. Entrevistas y Cuestionarios.

Esta técnica [Komer, 1993], consiste en una serie de consultas que realiza el profesional a cargo de la toma de requisitos, a determinadas personas o grupos que normalmente deben ser los potenciales usuarios del sistema. Su objetivo es recabar la mayor cantidad de información, la cual no necesariamente debe conducir a una probable solución del problema. Típicamente las consultas son más bien de alto nivel y el éxito del uso de esta técnica radica fundamentalmente, en la habilidad del entrevistador para obtener buenas respuestas e interpretarlas correctamente. En esta técnica, pueden ser identificadas tres fases [Piattini, 1996]: la de preparación de las entrevistas, la de realización y la de análisis, que se describen a continuación.

1) Fase de preparación: En esta fase, se plantea una entrevista la cual no puede improvisarse. Por tanto las tareas previas a la entrevista son:

59

a) Estudiar el dominio del problema. Es importante poder generar los lazos de confianza necesarios entre el ingeniero de requisitos y los clientes y usuarios del sistema. Por tanto la primera tarea en esta fase, es la de estudiar el dominio del problema, que puede ser mediante técnicas de estudio de documentación sobre el tema, estudio de proyectos similares realizados con anterioridad y/o la inmersión en la problemática y estudio de la organización. b) Selección del personal a entrevistar. Con el objeto de simplificar el problema, es recomendable realizar la menor cantidad de entrevistas y por tanto será importante la tarea de selección del personal a quien se entrevistará. Normalmente se inicia el proceso de entrevistas, con los directivos de la organización para tener una visión general del problema y posteriormente con los potenciales usuarios, quienes podrán aportar mayores detalles sobre aspectos operacionales de la organización. c) Determinar el objetivo y contenido de las entrevistas. Esta tarea tiene por objeto optimizar el tiempo empleado en las entrevistas, por tanto es importante determinar los objetivos que se desean alcanzar con la entrevista y de acuerdo a ello, definir y redactar los contenidos. Se puede adelantar el proceso, entregando algún documento introductorio del proyecto y cuestionarios debidamente preparados, dirigidos a quienes serán los futuros entrevistados. Éstos deberán responder y devolverlos previamente. d) Planificar las entrevistas. El momento y duración de la entrevista, deben ser fijados en función de la agenda de los futuros entrevistados.

2) Fase de realización: En la fase de realización, es posible distinguir las siguientes tres etapas.

a) Inicio. En la cual el entrevistador se presenta al entrevistado e informa el propósito de la entrevista, el procedimiento y algunos elementos que el entrevistado desconozca, como por ejemplo, la notación a utilizar. b) Desarrollo [Robertson, 1999]. La entrevista puede ser escrita o grabada y no debería durar más de dos horas. Las técnicas a emplear pueden ser diversas, como por ejemplo, preguntas abiertas o de contexto libre, estas permiten una comunicación más fluida evitando la similitud a un interrogatorio, partiendo de aspectos generales hasta llegar a preguntas más concretas o especificas. Típicamente, se utilizan también plantillas como medios para obtener y registrar la información que se precisa. Otro aspecto importante a tener en cuenta, es la utilización de los términos apropiados, evitando utilizar tecnicismos que el entrevistado desconozca y que lo puedan perturbar. Finalmente se debe destacar, que el entrevistador debe permanentemente mostrar interés, cuidando el tono de voz, movimientos, expresión facial, etc... c) Finalización. Al termino de la entrevista, se debe verificar que la información recogida es entendida de la misma forma por entrevistador y entrevistado, agradecerle la colaboración prestada y comprometerle para una posible siguiente entrevista.

3) Fase de análisis de las entrevistas. Después de concluida la entrevista, se debe estudiar la información recogida contrastándola con otras entrevistas o fuentes de información. Luego se puede redactar un informe y enviarlo al

60

entrevistado para verificar que los contenidos estén de acuerdo a la información que el entrevistado quiso aportar.

2.2.4.3. Observación in situ.

La técnica de observación in situ [Medina, 2004], consiste en que él o los desarrolladores del sistema a implementar, se sumergen en el ambiente de trabajo de los potenciales futuros usuarios para observar cómo es realizado el trabajo diario, registrando aspectos relevantes y observando factores sociales y organizacionales que afecten al sistema. Uno de los enfoques de esta técnica es la etnografía [Kotonya, 1998]:

2.2.4.4. Etnografía.

Considerando que los sistemas de software son utilizados en un contexto social y organizacional y que los requisitos de estos sistemas, nacen y se circunscriben en ese contexto, la etnografía es una técnica de observación que se puede utilizar para entender los requisitos sociales y organizacionales [Sommerville, 2002], [Viller, 1999]. Los desarrolladores o analistas, se involucran en el entorno laboral para observar y tomar notas del trabajo diario que desarrollan los participantes. Esta técnica de observación, permite descubrir los requisitos implícitos que reflejan los procesos reales, más que los formales [Sommerville, 2002] en los que la gente está involucrada, descubriendo factores sociales y organizacionales que podrían afectar al sistema.

2.2.4.5. Demostración de tareas.

Esta técnica [Soren, 2002], [Medina, 2004], es una variante de las técnicas entrevistas y observación in situ y consiste en consultar a los potenciales usuarios, cómo realizan ciertas tareas específicas que esperan que realice el futuro sistema. Esta técnica, es recomendable cuando a los usuarios no les es simple explicar cómo realizan su trabajo diario, pero sí pueden explicar cómo realizan ciertas tareas puntuales. Esta técnica es también útil para la observación de tareas críticas, pues a los usuarios les es más fácil demostrar cómo realizan determinadas tareas que explicar con palabras cómo las desarrollan.

2.2.4.6. Técnica JAD (Desarrollo Conjunto de Aplicaciones).

Esta técnica que fue desarrollada por IBM en 1977, se apoya en los siguientes principios [Raghavan, 1994], [Tovar, 2004]: la dinámica de grupos (JAD, representa una alternativa a las entrevistas individuales), el uso de ayudas audiovisuales (transparencias, herramientas multimedia, etc.), el proceso organizado y racional (se desarrollan reuniones grupales durante dos a cuatro días) y la filosofía de la documentación (en las reuniones se trabaja directamente sobre los documentos que se generarán). Esta técnica se puede dividir en dos: el JAD/Plan, el cual tiene la finalidad de elicitar y especificar requisitos y el JAD/Design, en el que se aborda el diseño de software. Su desarrollo se lleva a cabo en cinco fases:

1) Definición del proyecto. En esta fase se definen varias tareas con el objeto de obtener una “guía de definición de gestión”. Estas tareas consisten en:

61

a) El desarrollo de una serie de entrevistas a la dirección a objeto de definir, el propósito del proyecto, los alcances, objetivos, restricciones, requisitos, participantes, etc... b) La adquisición de información para la guía de definición de gestión. c) La selección del equipo participante. Entre los participantes de proyecto se pueden identificar a:

oo El patrocinador ejecutivo, quien tiene a cargo la decisión final del desarrollo del proyecto.

oo El jefe del JAD, que es el responsable de todo el proceso y asume el control durante las reuniones.

oo El analista, quien es el responsable de la producción de los documentos que se deben generar durante las sesiones JAD.

oo Los representantes de los usuarios, que durante el JAD/Plan suelen ser directivos con una visión global del sistema y durante el JAD/Design los futuros usuarios finales.

oo Los representantes de sistemas de información, personas expertas en sistemas de información que prestan asesoría a los usuarios.

oo Los especialistas, que son personas que pueden brindar información detallada sobre aspectos concretos cuando así se requiera.

d) La construcción de la guía de definición de la gestión, documento que define lo necesario para gestionar la aplicación. f) La planificación de la sesión, en la cual se debe especificar la duración de la sesión, el lugar y fecha de su celebración.

2) Investigación. Esta fase, consiste en la familiarización con el sistema mediante reuniones con los usuarios y desarrolladores, la documentación del flujo de trabajo existente y nuevo, la recolección de especificaciones preliminares (datos elementales, pantallas, informes) y la preparación de la agenda de la reunión.

3) Preparación. Esta fase, consiste en la preparación de todo lo necesario para llevar a cabo el desarrollo eficiente de la sesión. Se debe preparar, el documento de trabajo (punto de partida para trabajar la sesión), el guión de la sesión, que indicará qué hacer y cuando, las ayudas visuales, la reunión previa al desarrollo del JAD estableciendo compromisos con la empresa y el lugar de reuniones.

4) Sesión JAD. En esta fase se lleva a cabo la sesión, iniciándose con una introducción, en la que se revisan detalles administrativos, se describe lo que se espera, se aporta una visión global del sistema y se recorre la agenda de la sesión. Posteriormente se discute el documento de trabajo revisando supuestos entrelazados con cuestiones abiertas, flujo de trabajo, datos, pantallas, etc... Se concluye con el cierre de la sesión determinando quién recibirá el documento de trabajo y cómo será revisado por los participantes (formulario de aprobación).

5) Documentación final. Finalmente, se llevan a efecto las siguientes tareas:

oo Producción del documento final, con la actualización del documento de trabajo.

oo Revisión del documento de trabajo por los participantes, lo que asegura claridad y exactitud.

62

oo Reunión de revisión, en la que se decide qué hacer con los cambios. oo Reunión de aceptación final, en la que se da un visto bueno final. oo Cambio de las especificaciones después del JAD.

Algunas características de esta técnica son:

1) No suele emplearse con frecuencia, porque presenta problemas en la adaptación de horarios del personal heterogéneo que debe participar en sus sesiones.

2) Normalmente si se aplica, suele tener buenos resultados fundamentalmente en el área de los sistemas de información [Raghavan, 1994], [Choque, 2003].

3) En comparación con las entrevistas individuales, presenta muchas ventajas; como por ejemplo el ahorro de tiempo, la revisión en grupo de la documentación generada y la participación en su desarrollo de clientes y usuarios.

2.2.4.7. Prototipos.

Es una técnica comúnmente utilizada en el desarrollo de sistemas y permite al desarrollador crear un modelo del sistema que deberá ser desarrollado [Kotonya, 1998], [Robertson, 1999]. El modelo es una simulación del sistema, que es utilizado por el usuario final. Esta técnica permite obtener retroalimentación que sirve de información, en cuanto a si el sistema diseñado en base a los requisitos recolectados, permite al usuario realizar su trabajo de manera eficiente y efectiva.

El proceso se inicia con una primera aproximación de los requisitos generales definidos por usuarios y clientes, con el propósito de determinar las características fundamentales del sistema. Es así que desarrolladores, clientes y usuarios, se reúnen y definen los objetivos globales del sistema, identifican todos los requisitos que son conocidos y las áreas en las que será necesario profundizar más. Una vez concluida esta fase, se da inicio al desarrollo de un diseño rápido del sistema. Este diseño rápido, preferentemente se concentra en una representación de aquellos aspectos del sistema, que serán visibles al usuario (por ejemplo, entradas y formatos de las salidas). Por lo tanto este diseño lleva a la construcción de un prototipo. Este prototipo es evaluado por clientes y usuarios para refinar los requisitos del sistema a ser desarrollado. Un proceso de iteración tiene lugar a medida que el prototipo es refinado para satisfacer las necesidades del cliente, permitiendo al mismo tiempo, una mejor comprensión del problema por parte del desarrollador.

Los prototipos pueden ser de tres tipos: Prototipos Rápidos, Prototipos Evolutivos y Prototipos Tangibles/Usables.

Prototipo Rápido: Este tipo de prototipo, sirve para lograr una validación preliminar de los requisitos en una etapa previa al diseño específico. En este sentido, el prototipo puede ser visto como una aceptación tácita, de que los requisitos no son totalmente conocidos o entendidos antes del diseño y la implementación. El prototipo rápido puede ser usado como un medio para explorar nuevos requisitos y así ayudar a "controlar" su constante evolución.

Prototipo Evolutivo: Durante el ciclo de vida de un sistema, los prototipos sufren normalmente diferentes cambios hasta llegar a una versión final del producto. Claramente, todo ciclo de vida de desarrollo de un producto, puede ser visto como una serie incremental de un conjunto de prototipos acumulativos. Tradicionalmente, el ciclo de vida está dividido en dos fases distintas: desarrollo

63

y mantenimiento. La experiencia ha demostrado que esta distinción es arbitraria y que va en contra de la realidad, por cuanto la mayor parte del coste en el desarrollo de un sistema, se produce una vez que el producto es entregado. El punto de vista evolutivo del ciclo de vida del software considera a la primera entrega del producto, como un prototipo inicial. Modificaciones y mejoras posteriores resultan en nuevas entregas de prototipos más maduros. Este proceso continúa hasta que se haya desarrollado el producto final. Esta forma de ver el ciclo de vida de desarrollo de un sistema, elimina la distinción arbitraria entre desarrollo y mantenimiento, resultando en un importante cambio de mentalidad que afecta a las estrategias para la estimación de costes, enfoques de desarrollo y adquisición de productos.

Prototipos Tangibles/Usables: Esta clase de prototipos, implican el desarrollo de aplicaciones que el usuario pueda utilizar e interactuar como si se tratase de la aplicación final. Los aspectos que se deben considerar en el desarrollo de este tipo de prototipos son:

oo Los cambios a realizar deben demandar poco esfuerzo. oo Se debe tener amplia flexibilidad para el manejo de las interfaces de

usuario. oo Se debe consumir poco tiempo para generar un nuevo prototipo.

Se debe dejar bien en claro al usuario, que el sistema desarrollado sólo se trata de un prototipo y que no es el sistema final. Este tipo de prototipo es también muy útil para validar requisitos no funcionales como por ejemplo, los de facilidad de uso del sistema.

2.2.4.8. Proceso de Análisis Jerárquico (AHP).

AHP (Analytic Hierarchy Process) es una técnica de evaluación y decisión múlticriterio [Avila, 2000], [Thomas, 1998]. Esta técnica, consiste en la descomposición de una situación compleja, en problemas menores que permiten mediante la construcción de un modelo jerárquico, organizar la información respecto del problema, de una manera más eficiente y grafica. Una vez descompuesta y analizada por partes, AHP entrega un conjunto de alternativas de solución que van ordenadas desde la mejor a la peor. Algunos de los componentes producto de la descomposición, se refieren a aspectos cuantitativos y pueden ser fácilmente evaluados. AHP, permite adicionalmente incorporar al análisis, aspectos de tipo cualitativo, los que normalmente suelen quedarse fuera debido a su dificultad inherente para ser medidos, pero que pueden ser relevantes para el caso en estudio. El Proceso de Análisis Jerárquico, realiza sobre los elementos del modelo, comparaciones binarias (de pares) y atribuye valores numéricos a los juicios realizados por las personas, respecto a la importancia relativa de cada elemento, sintetizándolos y agregando las soluciones parciales en una sola solución. Adicionalmente permite realizar el análisis de sensibilidad para observar y estudiar otras posibles soluciones, al hacer cambios en la importancia de los elementos que conforman el modelo. En resumen, se puede estructurar el AHP, en una serie de pasos, que organizan el procedimiento a seguir para aplicar la técnica. Estos pasos son los siguientes:

64

oo Estructuración del modelo jerárquico (representación del problema mediante la identificación de metas, criterios, subcriterios y alternativas).

oo Priorización de los elementos del modelo jerárquico.

oo Comparaciones binarias entre los elementos.

oo Evaluación de los elementos mediante la asignación de “pesos”.

oo Ranking de las alternativas de solución de acuerdo con los pesos dados.

oo Síntesis.

oo Análisis de Sensibilidad.

El conjunto de problemas en los que se puede aplicar esta técnica es diverso, por ejemplo, priorización de cartera de proyectos, gestión ambiental, formulación de estrategias de mercado, análisis de requisitos, entre otros.

Algunas ventajas del AHP que se pueden identificar frente a otros métodos de decisión múlticriterio son:

oo Presenta un sustento matemático.

oo Permite desglosar y analizar un problema por partes.

oo Permite medir criterios cuantitativos y cualitativos mediante una escala común.

oo Incluye la participación de diferentes personas o grupos de interés para generar consenso.

oo Permite verificar el índice de consistencia y hacer las correcciones, si es el caso.

oo Genera una síntesis y posibilita realizar análisis de sensibilidad.

oo Permite que la solución se pueda complementar con métodos matemáticos de optimización.

2.2.4.9. Puntos de Vista.

Cuando se considera implementar un nuevo sistema, los diferentes futuros usuarios normalmente tienen diversos intereses y expectativas acerca de las funcionalidades que esperan del nuevo sistema. Los enfoques de elicitación de requisitos orientados a los puntos de vista [Medina, 2004], consideran estos diferentes intereses y los utilizan para organizar y estructurar el proceso de obtención de requisitos. Los puntos de vista [Medina, 2004] pueden ser considerados de acuerdo a:

o Una fuente o consumidor de datos. o Un marco de trabajo de la representación (modelo particular del sistema). o Un receptor de servicios del sistema.

2.2.4.10. Casos de Uso.

Esta técnica [Larman, 2002], se basa en la definición de la funcionalidad que se espera de un sistema y que le permita interactuar con algo o alguien. Un caso de uso se puede definir como: “una descripción narrativa textual de los procesos de una empresa o sistema” [Larman, 1999], “la descripción de una secuencia de interacciones entre el sistema y uno o más actores”, en la que se considera al sistema como una caja negra y

65

de la que los actores obtienen respuestas [Choque, 2003]. Como actores, se entenderán a las personas u otros sistemas que interactúen con el sistema cuyos requisitos se estan describiendo [Scheneider, 1998]. Inicialmente, la técnica fue propuesta en [Jacobson, 1993]. A partir de esta publicación, gran parte de los más reconocidos especialistas en métodos Orientados a Objetos coincidieron en considerar los casos de uso, como una excelente forma de especificar el comportamiento externo de un sistema. De esta forma, la notación de los casos de uso fue incorporada al lenguaje estándar de modelado UML (Unified Modeling Language) [Booch, 1999].

Los casos de uso, combinan el concepto de evento (un evento es algo que ocurre fuera de los límites del sistema) del análisis estructurado, con otra técnica de especificación de requisitos bastante poco difundida: aquella que dice que “una buena forma de expresar los requisitos de un sistema es escribir su manual de usuario antes de construirlo” [Herrera, 2005]. Esta última técnica, si bien ganó pocos adeptos, se basa en un concepto muy interesante:” al definir requisitos, es importante describir el sistema desde el punto de vista de aquél que lo va a usar y no desde el punto de vista del que lo va a construir”. De esta forma, es más fácil validar que los requisitos documentados son los verdaderos requisitos de los usuarios, ya que éstos comprenderán fácilmente la forma en la que están expresados.

Para una correcta definición de requisitos, la aplicación de esta técnica se efectúa en siete fases [Bahamonde, 2003] las cuales son:

1) Inicialmente se procede a la correcta identificación de los actores de los casos de uso. Los actores como ya se mencionó anteriormente, son entes externos (los usuarios) o quizás otros sistemas. El encargado del proceso, debe tener absolutamente claro, para quién o quienes se desarrollará el sistema. 2) En una segunda fase, se continúa con la identificación de los principales casos de uso para cada usuario, haciendo abstracción de las actividades que componen cada caso de uso. 3) En esta tercera fase, se identifican nuevos casos de uso a partir de los ya definidos en la fase anterior. 4) Una vez que ya se tienen definidos o identificados todos los casos de uso, se procede a documentarlos. En esta fase del proceso, se deben identificar el inicio y fin, los flujos normal y alternativo de los eventos y las excepciones que se produzcan en estos flujos. 5) En la quinta fase, se definen las prioridades de los requisitos, relacionándolos con los casos de uso ya identificados, determinando la funcionalidad principal y los puntos críticos. 6) Considerando que el sistema completo contemple gran cantidad de casos de uso, en la sexta fase, se definen los gráficos que se utilizaran con los casos de uso que se consideren, con el objeto de ordenar la información. Para estos efectos existen herramientas tales como el Visual UML [VisualUml, 2005].

66

7) Finalmente en esta última fase, se procede a la utilización de herramientas automatizadas para la captura, administración y producción de una especificación de requisitos como por ejemplo: RequisitePro [RQP, 2005], de Rational Software y DOORS, de Quality System and Software [DOORS, 2005].

Una particularidad que se puede observar, en la aplicación de casos de uso como técnica para la especificación de requisitos, es que su aplicación presenta ventajas frente a una descripción sólo textual de los requisitos funcionales [Firesmith, 1997], [Choque, 2003], porque:

oo Facilitan la elicitación. oo Son simples de comprender para los usuarios. oo Sirven de base a las pruebas del sistema. oo La mayoría de los requisitos funcionales, se pueden expresar como casos de uso.

2.2.4.11. Sistemas Existentes.

Esta es otra de las técnicas utilizadas en la gestión de requisitos. Esta técnica [Davyt, 2001] consiste, en la búsqueda y análisis de sistemas que ya se hayan desarrollado en la organización y que tengan características similares al sistema que se propone. De los documentos de requisitos de sistemas antiguos, se puede obtener mucha información respecto del dominio del problema, características, naturaleza de la organización, se puede definir el tipo de interfaces de usuario, etc. También es útil para validar la información nueva que se extrae, o la información que probablemente se haya omitido. Otra información que se puede obtener es la relacionada con el tipo de salidas que se utilizan; por ejemplo, listados, consultas, etc. Después de estos pasos preliminares y en base a la información recolectada se podrán obtener más requisitos.

2.2.4.12. Estudio de Documentos existentes.

La técnica de estudio de documentos existentes [Goguen, 1993], [Medina, 2004], consiste en la revisión de documentos de texto, archivos de datos, bitácoras, y bases de datos. La utilidad de esta técnica, es la posibilidad que brinda para verificar la veracidad de la información obtenida mediante entrevistas o cuestionarios realizados a los usuarios o clientes del futuro sistema, es decir esta técnica puede ser utilizada en forma complementaria a otras técnicas de elicitación de requisitos. En general se desea determinar el contexto y la información detallada del sistema en la que los requisitos están basados.

2.2.4.13. Maestro/Aprendiz.

Esta técnica [Beyer, 1995], consiste en que los ingenieros de requisitos o analistas asumen el rol de aprendices, en un escenario donde los clientes del futuro sistema asumen el rol de maestros. Los ingenieros analistas, en el rol de aprendices realizan las tareas de observación de las actividades desarrolladas por los clientes, cuestionando el origen y significado de las tareas realizadas. También pueden desarrollar algunas labores bajo la supervisión del maestro, a objeto de proponer algunas alternativas de solución a los problemas detectados.

67

En el ámbito de la Ingeniería de Conocimiento, se puede afirmar que la clasificación del conocimiento en función de algún principio general es una tarea muy compleja [Maté, 1988], sin embargo, es importante reconocer la existencia de diferentes tipos de conocimiento, los que requieren diversas técnicas de extracción desde el experto. Algunas de las principales técnicas de IR que se aplican en la extracción de conocimiento de un experto son:

2.2.4.14. Análisis de Protocolos.

Esta técnica [Maté, 1988], está orientada directamente a la producción de modelos de sistemas para la solución de problemas y es el proceso de traducir las verbalizaciones, ("pensar en voz alta") en representaciones más accesibles y significativas. En el método clásico, se graba el comportamiento del experto mientras él trabaja en la solución de un problema; luego este protocolo es trascrito y analizado, a objeto de posteriormente convertirlo en un conjunto de reglas de producción, que transforman un estado, en otro.

Los protocolos pueden ser concurrentes o retrospectivos.

oo Concurrentes son, "pensar en voz alta" al momento de realizar las acciones interesantes.

oo Retrospectivos son, "pensar en voz alta" revisando registros (escritos, verbales o visuales) de acciones interesantes.

Actualmente, el análisis de protocolos se realiza en dos fases, pues se constató que era mucho menos perturbador que hacerlo sólo en una. En la primera fase, se plantea al experto problemas concretos y se le solicita que manifieste todas las decisiones que tomó en la solución del problema, estas se listan y con esta lista se construyen las partes derechas de las reglas. En una segunda fase, se vuelve a examinar con el experto, la secuencia de acciones anteriormente registradas y se le consulta el por qué de las decisiones tomadas y por qué ésas y no otras que se puedan considerar plausibles. Las respuestas obtenidas en esta segunda fase conforman la parte izquierda o condiciones de las reglas. Luego de extraídas las condiciones y acciones para cada regla, se presentan en conjunto al experto con el fin de generalizarlas. La ventaja de esta técnica, es que puede ir más allá de lo que conscientemente el experto podría explícitamente relatar, acerca de la solución de un determinado problema. Esta técnica, es particularmente útil para extraer información sobre procedimientos, que un experto utiliza en la solución de un problema.

2.2.4.15. Repertory Grids.

Repertory Grids [Milton, 2003], es una técnica utilizada en diversos campos, para la elicitación y análisis de conocimiento. La técnica, se basa esencialmente en una matriz, aunque es mucho más compleja, que el simple llenado de una matriz de elementos. La técnica, se puede descomponer en cuatro fases, las que se describen a continuación:

68

oo Primera fase: En esta fase, se seleccionan los conceptos para el “grid”. Para que la técnica provea buenos resultados y no tome mucho tiempo su aplicación, se recomienda elegir un número de entre siete y a lo más quince elementos (conceptos). Un conjunto de aproximadamente la misma cantidad de atributos es también requerido. Estos deberían ser tal, que sus valores puedan ser expresados en una escala continua. Los atributos se pueden tomar del conocimiento previamente elicitado o se pueden generar durante la sesión de elicitación.

oo Segunda fase: En la segunda fase, los conceptos son calificados frente a cada atributo. A menudo se utiliza una escala numérica para este propósito. Por ejemplo si el concepto es, planetas en el sistema solar, se puede valorar su distancia respecto del sol, entre 1 si es muy cercana, a 9 si es muy lejana. Se sigue así sucesivamente con el resto de atributos, por ejemplo, tamaño, número de lunas, etc...

oo Tercera fase: En esta tercera fase, las calificaciones son aplicadas a un cálculo estadístico llamado análisis de cluster, para crear un focus grid. Esto asegura que conceptos con valoraciones similares sean agrupados juntos en el focus grid. En forma similar, los atributos que tienen similar valoración, a través de los conceptos, son agrupados juntos.

oo Cuarta fase: Finalmente, en esta última fase, el ingeniero de conocimiento explora al experto a través del focus grid realimentándose y aprontándose para el conocimiento respecto de las agrupaciones y correlaciones descubiertas. Si conceptos y atributos extras se agregan, ellos se califican para tener un grid mayor y más representativo.

Esta técnica puede ser utilizada para descubrir correlaciones ocultas, o conexiones causales.

2.2.4.16. Laddering.

Laddering, es una técnica desarrollada por Hinkle en 1965 [Rugg, 2003], como un medio para representar de una manera simple, clara, sistemática y estructurada, un modelo del conocimiento de una persona. Esta poderosa técnica, concentra actualmente una creciente atención en un amplio rango de comunidades científicas. La comunidad especializada en adquisición de conocimientos, ha desarrollado la semántica formal, la notación y los procedimientos utilizados. Aunque, el método básico es simple y rápido de aprender a utilizar, la mejor manera de aprender esta técnica, es mediante la demostración por parte de alguien experimentado en ella. Laddering [Milton, 2003] involucra en su aplicación, las tareas de creación, revisión y modificación de conocimiento jerarquizado a menudo en la forma de ladders, es decir, diagramas de árbol. El experto y el ingeniero de conocimiento, respecto del ladder presentado en un documento o en la pantalla de un computador, agregan, eliminan, renombran o reclasifican los nodos como consideren más apropiado. La técnica también involucra un conjunto de preguntas de prueba predefinidas tales como: ¿podría usted indicar algunos subtipos de X?, o ¿cómo podría indicarse que algo es X?, o ¿Por qué se podría preferir X a Y?.

69

Laddering es utilizada normalmente, para la adquisición de conocimientos y en IR, para un amplio rango de propósitos. Uno de los principales es obtener explicaciones y clarificación de condiciones técnicas, otra, entender como las personas estructuran su conocimiento sobre determinado dominio, es decir, las clases, subclases, etc., que ellas utilizan.

2.2.4.17. Card Sorting.

Card Sorting, [Milton, 2003], es una técnica muy conocida y utilizada para capturar la forma en que los expertos comparan y ordenan conceptos y puede llevar a revelar conocimiento de clases, propiedades y prioridades. Esta técnica se basa en el ordenamiento de tarjetas de papel, las que representan categorías, conceptos o contenidos específicos. El experto tiene la tarea de ordenar repetidamente las tarjetas en diferentes conjuntos de tal forma que las tarjetas de cada conjunto tengan siempre algo en común. En la práctica esto puede funcionar de dos modos, con propósitos muy diferentes:

oo Como herramienta de trabajo grupal.

oo Como herramienta de testeo con usuarios.

En el primer caso, el ejercicio se realiza en grupo y se discute la estructura que se va desarrollando para lograr un criterio común de equipo. En el segundo caso, se le pide a usuarios reales que realicen la clasificación; esto permitirá considerar diferentes visiones y podrá entregar información valiosa sobre la apreciación de los contenidos y los intereses de éstos.

Al igual que en el caso de los modelos del proceso de Ingeniería de Requisitos, respecto de la utilidad que presentan las diversas técnicas analizadas y algunas otras que se han publicado, no existe una técnica única que se pueda aplicar en las diferentes actividades en que se divide el proceso de IR, ni que sea la única herramienta para ser aplicada a los diversos tipos de proyectos, naturaleza y características de los innumerables tipos de organizaciones. Lo común es utilizar una combinación de las técnicas estudiadas, en función del tipo de organización, personal disponible, disponibilidad de tiempo, costes, tipo de proyecto o actividades en que se divide el proceso de IR.

2.2.5. Notaciones para definición de Requisitos.

Existen diferentes notaciones o lenguajes utilizados, para especificar los requisitos de un sistema. La decisión sobre qué tipo de notación utilizar, depende de diversos factores, tales como por ejemplo, el tipo de requisitos que se desea describir o especificar (requisitos de usuario o requisitos del sistema), el perfil de lectores de los requisitos (clientes, usuarios, administradores, arquitectos del sistema, desarrolladores), o la fuente de la cual provienen los requisitos (usuarios expertos en el dominio de negocio, usuarios técnicos, ingenieros clientes, etc.). Es decir, en general deben existir diferentes niveles de especificación de los requisitos a objeto de permitir y facilitar la comunicación entre los diferentes stakeholders. Considerando que normalmente los usuarios, no poseen un conocimiento técnico detallado, los requisitos de usuario no pueden definirse utilizando un lenguaje meramente técnico y poco comprensible para ellos, muy por el contrario, los requisitos deben representarse en un lenguaje simple y que les sea fácilmente legible y entendible

70

tal como el lenguaje natural, quizás complementado con diagramas o representaciones sencillas. Sin embargo, la representación de requisitos en lenguaje natural, posee algunas desventajas ([Sommerville, 2002]) que no la hacen apropiada para describir los requisitos del sistema, tales como ambigüedad, flexibilidad (se puede decir lo mismo de diferentes formas) y confusión. En general la comprensión de las especificaciones en lenguaje natural, radica en que lectores y redactores utilicen los mismos términos para expresar los mismos conceptos, es así que existen otros tipos de notaciones que han sido propuestas, las cuales son más adecuadas al nivel de detalle requerido para el diseño del sistema y están orientadas a técnicos y desarrolladores. Entre estas notaciones, se tienen los lenguajes gráficos complementados con notaciones textuales tales como las descripciones de casos de uso o también, aunque menos utilizados, los lenguajes más formales basados en conceptos matemáticos. Respecto de estos últimos, existen dos enfoques que han sido utilizados para redactar especificaciones detalladas de sistemas de software no trivial [Sommerville, 2002], estos son:

1. Un enfoque algebraico, en el cual, el sistema se describe en términos de operaciones y sus relaciones.

2. Un enfoque basado en modelos. En este enfoque se construye un modelo del sistema, utilizando diversos elementos matemáticos.

Las técnicas basadas en el primer enfoque se cree, producen especificaciones del comportamiento del sistema que son a menudo artificiales y difíciles de comprender, razón por la cual, un enfoque basado en modelos, donde la especificación del sistema se expresa como un modelo de estados del sistema, se ha utilizado ampliamente en muchos proyectos industriales [Sommerville, 2002]. Ejemplos de lenguajes desarrollados para soportar este último enfoque son: Z [Spivey, 1992], VDM [Jones, 1980] y B [Wordsworth, 1996].

Como corolario, en [Sommerville, 2002], se establece una clasificación de las diversas notaciones (tabla 2.1) considerando la existencia de diferentes niveles de especificación del sistema a desarrollar, ya sean estos, requisitos de usuario, nivel en el cual la definición de los requisitos es más abstracta y de más alto nivel, o niveles de especificación de requisitos del sistema y de diseño del sistema, niveles en los cuales, la especificación debe ser más precisa y detallada.

Tabla 2.1. Notaciones para la especificación de requisitos ([Sommerville,2002]).

NOTACION DESCRIPCION Lenguaje Natural

Estructurado Consistente en la definición de formas estándar o plantillas para expresar la especificación de los requisitos

Lenguajes de descripción de

diseño

Similares a los lenguajes de programación, pero con características más abstractas. Sirven para la representación de especificaciones más detalladas del sistema

Notaciones Graficas

Consisten en notaciones que utilizan un lenguaje grafico para describir los requisitos funcionales del sistema.

71

NOTACION DESCRIPCION Especificaciones

Matemáticas Se basan en conceptos matemáticos tales como máquinas de estado finito, o conjuntos. Describen los requisitos del sistema eliminando la ambigüedad propia del lenguaje natural.

Una muestra de los lenguajes más ampliamente conocidos y/o utilizados, y representativa de cada uno de los tipos de notación descritos en la tabla 2.1 es la siguiente:

2.2.5.1. Lenguaje de descripción de programas.

El lenguaje de descripción de programas (PDL) [Sommerville, 2002], es un lenguaje de descripción de diseño, muy similar a un lenguaje de programación y se deriva de lenguajes como Java o Ada, es por tanto, más comprensible para técnicos o desarrolladores que para usuarios comunes.

PDL es utilizado para la especificación de requisitos del sistema, pues su aplicación deriva en especificaciones detalladas y frecuentemente muy cercanas a la implementación. Su uso se recomienda en situaciones en que una operación se especifica, como una secuencia de acciones simples y el orden de ejecución de dichas acciones es importante, o cuando se tienen que especificar interfaces de hardware y software.

Este lenguaje, tiene como ventajas, el reducir la ambigüedad que presenta el lenguaje natural y el hacer los requisitos más comprensibles a quienes deben desarrollar el sistema, pero a su vez, presenta algunas desventajas tales como, no ser lo suficientemente expresivo para describir la funcionalidad de un sistema o ser comprensible sólo para personas que sean conocedoras de lenguajes de programación.

A modo de ilustrar su uso, se presenta un ejemplo (figura 2.29) [Sommerville, 2005] en el cual se describe la interfaz de un servidor de impresión utilizando PDL, basado en java.

Figura No. 2.29. Uso Lenguaje de Descripción de Programas [Sommerville, 2005].

72

2.2.5.2. SADT.

SADT (Structured Analysis and Design Technique) [Ross, 1977] es el nombre de una técnica propietaria basada en el Análisis Estructurado y representa una de las primeras notaciones gráficas propuestas [Sommerville, 2002]. Puede ser aplicada en una amplia gama de problemas de planificación, análisis y diseño, que involucren personas, máquinas, software, hardware, bases de datos, procesos de comunicaciones y finanzas [Ross, 1977].

El lenguaje utilizado se basa en un modelo consistente de cuatro elementos (entradas, controles, mecanismos y salidas) (figura 2.30). Puede ser utilizado en las etapas de análisis o diseño de un sistema, obteniéndose el modelo que se requiere construir o implementar.

Figura No. 2.30. Representación gráfica de un elemento básico ([Ross, 1977]).

La técnica de análisis estructural, identifica y organiza los detalles de un sistema (construye una imagen del sistema) según una jerarquía perfectamente referenciada. Este modelo se compone de:

o Diagramas de actividades, que representan el conjunto de las actividades más relevantes del sistema.

o Diagramas que muestran el conjunto de datos obtenidos sobre el sistema.

o Textos explicativos de los diagramas.

o Diagramas para explicaciones.

o Esquema de jerarquía del sistema analizado.

o Glosario que define los términos empleados.

o Condiciones de activación.

Cada diagrama incluye entradas, controles, mecanismos y salidas y representan una transformación en el sistema.

SADT es útil para representar estructuras estáticas como las especificaciones funcionales, pero no es adecuada cuando se requiere modelar la dinámica de un sistema. El siguiente ejemplo (figura 2.31) muestra cómo utilizar SADT para representar el proceso de selección de personal en una determinada empresa [Lasserre, 2006]. Dentro

73

de las actividades del proceso de selección se encuentra la Selección de postulantes tomando como entrada, la lista de posibles candidatos. Como salida de la actividad se tiene la lista de seleccionados. La selección está controlada por los requisitos del puesto establecidos por la jefatura que debe tomar en cuenta el Reclutador (mecanismo).

Selección postulantes

1

Realizar entrevistas

2

Integrar información de

postulantes 3

Rechazar o hacer oferta

4

Lista de posibles

candidatos

Requisitos de empleo desde

Jefatura

Lista de selección

Reclutador

Postulante

Interés de parte de la

Jefatura

Psicólogo

Referencias de postulantes

Resultado de entrevistas

Referencias confirmadas

Oferta o rechazo

Decisión: Contratar o rechazar

Condiciones del contrato

Reclutador

Jefatura

Postulante seleccionado

Figura No. 2.31. Ejemplo de utilización de SADT [Lasserre, 2006].

2.2.5.3. Notación UML para casos de uso.

La representación de requisitos mediante Casos de Uso (historias del uso de un sistema), es en la actualidad, una de las técnicas graficas más ampliamente utilizadas [Larman, 2003]. La técnica consiste en la construcción de escenarios mediante Casos de Uso, escenarios en los que los Casos de Uso [Jacobson, 1993], representan la funcionalidad esperada del sistema. Un escenario (instancia del Caso de Uso) define una secuencia específica de acciones e interacciones entre un conjunto de actores y el sistema objeto de estudio o de acuerdo a [Sommerville, 2002], “representa todas las posibles interacciones que ocurrirán en los requisitos del sistema”. Los actores que interactúan con el sistema, representan a toda entidad externa al sistema, que precisa una funcionalidad de éste.

Los Casos de Uso son documentos de texto y el modelado de Casos de Uso es fundamentalmente una acción de descripción textual, sin embargo, el lenguaje unificado de modelado (UML) [Larman, 2003], define un diagrama de Casos de Uso para ilustrar los nombres de los Casos de Uso, Actores y sus relaciones.

El Proceso Unificado [Larman, 2003], define el modelo de Casos de Uso como un modelo de la funcionalidad y entorno del sistema. La figura 2.32, muestra la notación utilizada.

Un ejemplo ilustrativo de la utilización de los Casos de Uso [Domínguez, 2008], se muestra en la figura 2.33. En esta figura se puede observar el diagrama de casos de uso que representa la funcionalidad de un sistema de gestión de una pequeña tienda de videos y los socios registrados en ella. El sistema deberá almacenar la información

74

correspondiente a las cuentas de los socios de la tienda y permitir las siguientes funciones:

• Alta de socio: Registrar un nuevo socio. • Baja de socio: Eliminar registros de un socio determinado. • Modificar datos de un socio: Actualizar la información guardada sobre una

persona. • Consulta de un socio: Consultar diferentes datos recopilados de determinada

persona. Algunas de las interacciones entre el sistema y los actores, incluyen un proceso de autenticación de estos últimos.

Figura No. 2.32. Representación gráfica de la notación (elaborado en base a [Larman, 2003], [Glinz, 2000]).

<<inc

lude>

>

Figura No. 2.33. Ejemplo de utilización de Casos de Uso [Domínguez, 2008].

75

2.2.5.4. Z.

La notación Z [Bowen, 2005], es una notación de especificación formal, basada en la teoría de conjuntos y la lógica de predicados de primer orden. Existen muchos libros publicados sobre Z, uno de los más ampliamente consultados es [Spivey, 1992], [Bowen, 2005]. La base teórica de Z, es tratada en [Spivey, 1988]. Z, esta soportada por una librería de operadores conocida como ‘Z toolkit’. Entre los operadores utilizados, están los operadores lógicos ‘ ,,, ⇒∨∧ …’ y las operaciones de conjuntos, ‘ ,,, ∩∪∈ ….’. Estos operadores tienen un gran número de reglas que ayudan en el razonamiento de la especificación Z. También se cuenta con un tipo de constructor especial, denominado esquema (‘schema’), que es una versión abstracta de un ‘registro’ en Pascal. Un esquema, define un vínculo de identificadores y sus valores en un determinado tipo. La especificación Z, es típicamente utilizada en un estilo de modelado, en el cual se incluye un “estado abstracto”, que contiene suficiente información para describir los cambios de estado, resultado de diversas operaciones en el sistema [Bowen, 2005]. Cada una de estas operaciones, define una relación entre un antes y un después de cada estado. Un estado puede contener invariantes, los cuales son predicados que relacionan diversos componentes en el estado abstracto, los que deberían aplicarse siempre, a pesar del estado actual del sistema. Un estado inicial, se define como un caso especial de un estado abstracto más general. La descripción de un sistema, es modelada por este estado inicial, seguido de un conjunto de operaciones en cualquier orden, limitadas solamente por precondiciones impuestas por operaciones individuales. A menudo ‘operaciones totales’ se diseñan de tal forma, que ellas puedan ser utilizadas en cualquier situación (con una condición previa de verdadero). Esto es especialmente útil en la manutención de operaciones implementadas (las cuales típicamente podrían ser llamadas a procedimientos), dado que las precondiciones no son explícitamente obvias en la implementación de un programa y un mantenedor que ignore tales restricciones, podría utilizar la operación en una situación inapropiada. Las operaciones totales se formulan típicamente como una disyunción entre el éxito y si es requerido, un número de casos de error. Una indicación apropiada del error, normalmente como alguna forma de salida, se incluye dependiendo de los requisitos. En Z, un buen punto para empezar la especificación, es postulando un posible estado abstracto para el modelo del sistema. A continuación, esto se deberá cambiar durante el curso del resto de la especificación, sin embargo, esto es parte del proceso de aprendizaje, mediante el cual se logra entender y conocer el sistema. Después, se deberían considerar algunas probables operaciones posteriores a ejecutarse en el sistema. Inicialmente, sólo los resultados de operaciones exitosas, que logran el resultado sin ningún problema, se deben considerar. El estado abstracto, debería ser modificado si algún aspecto importante no puede ser adecuadamente modelado, verificando siempre, posibles efectos sobre otras operaciones. Considerando que la especificación evoluciona, conjuntos y axiomas útiles o definiciones genéricas, se pueden asumir y definir formalmente agregados al inicio de la especificación. Los informes de errores, en caso de operaciones fracasadas, deben

76

considerarse y deben ser añadidos. Algunos de éstos, serán normalmente comunes en varias operaciones en una especificación de cualquier tamaño. En especificaciones prácticas, se encontrará que se repiten partes de la especificación a través de grupos de operaciones. Es importante dejar fuera estas partes, presentando y explicando su propósito y luego utilizarlas subsecuentemente. Esto reducirá considerablemente el tamaño de la mayoría de las especificaciones grandes y hará su asimilación más fácil para el lector. Durante la producción de la especificación, inevitablemente se generaran consultas. Éstas deben discutirse dentro del equipo de diseño con otros colegas, o con el cliente, para finalmente llegar al consenso. El estado inicial, se debe considerar como un caso especial del estado abstracto. A menudo, los contenidos de muchos de los estados son considerados como vacíos, o tienen algún valor fijo al inicio de la vida del sistema, pero si los contenidos exactos son poco importantes, pueden considerarse especificaciones aproximadas. Actualmente Z, experimenta un proceso de estandarización de ISO, que debería ayudar a su aceptación por parte de la industria y permitir el desarrollo de instrumentos para soportar la notación. Un ejemplo que muestra su utilización [Vallecillo, 2008] (figura 2.34), se basa en una estructura de datos (Cola), que es una secuencia de números naturales cuya longitud es menor que 10. Esta estructura de datos, tiene sólo una operación que es Ingresar, la cual verifica si la longitud de la cola permite la inserción de un nuevo elemento y si es así lo ingresa. La estructura y su operación se representan por medio de un “esquema”, que describe una operación que ingresa un elemento en la cola si es que hay espacio suficiente.

Figura No. 2.34. Ejemplo de utilización de la notación Z [Vallecillo, 2008].

Este esquema representa una operación que ingresa un elemento en la cola, si es que hay espacio suficiente.

77

2.2.5.5. VDM.

VDM (Vienna Development Method), [García, 2000], [Gil, 1999], [ISO, 1993], junto a Z, es uno de los más conocidos lenguajes especializados en la especificación del comportamiento de sistemas. VDM, tiene su origen, en trabajos desarrollados por Cliff Jones y Dines Bjorner del laboratorio Vienna de IBM a mediados de los años 70 [Gil, 1999]. Sin embargo las notaciones y herramientas utilizadas, han sido desarrolladas posteriormente y en la actualidad se aplican sobre un amplio dominio de sistemas. VDM, utiliza un lenguaje de especificación denominado VDM-SL (VDM, Specification Language), reglas para el refinamiento de datos, operaciones que permiten establecer vínculos entre requisitos abstractos y especificaciones detalladas y una teoría de pruebas, para verificar propiedades y decisiones de diseño. Es decir, VDM utiliza un lenguaje y un conjunto de técnicas formales para el modelado, descripción y el desarrollo de sistemas computacionales. VDM, se apoya en una notación matemática precisa, para determinar la funcionalidad que debe proporcionar el sistema. Las especificaciones VDM, se construyen en base a modelos de un estado subyacente del sistema. La especificación del modelo de un sistema, se describe mediante un conjunto de tipos de datos y un conjunto de operaciones sobre los mismos que se representan mediante funciones. A cada función se le asocian pre-condiciones y post-condiciones.

Figura No. 2.35. Ejemplo de utilización de la notación VDM [Suderman, 1997].

El lenguaje VDM-SL, se basa en la utilización de una lógica de funciones parciales, e igualmente a Z, en la teoría de conjuntos. Permite definir tipos complejos como conjuntos, registros, secuencias, etc., sobre los que se pueden especificar restricciones mediante invariantes. A diferencia de Z, en VDM-SL se diferencian dos tipos de componentes, estados sobre los que se pueden especificar invariantes y operaciones con pre y post-condiciones asociadas y descritas explícitamente.

78

Como ejemplo de su utilización (figura 2.35), se puede especificar un stack [Suderman, 1997] con una lista simple, en la cual se describe el tipo de dato, las funciones y las operaciones necesarias para generar el stack.

2.2.5.6. B.

El método B [Gil, 1999], [Lano, 1995], consiste en una colección de técnicas matemáticas para la especificación, diseño e implementación de componentes de software. Los sistemas son modelados como un conjunto de máquinas abstractas interdependientes, para las cuales, una aproximación basada en objetos es empleada en todos los estados de desarrollo. El método B establece guías para la estructuración de grandes diseños y la comprobación de la consistencia y corrección de éstos.

Figura No. 2.36. Ejemplo de utilización de la notación B [Martins, 2005].

Una máquina abstracta, esta descrita mediante el lenguaje AMN (Abstract Machine Notation). Una notación uniforme, se utiliza en todos los niveles de descripción, desde la especificación, hasta el diseño e implementación.

oo AMN es un lenguaje de especificación formal, basado en estados, tal como VDM y Z. Una máquina abstracta, se compone de un estado, junto con operaciones sobre el mismo estado. En la especificación y diseño de una máquina abstracta el estado es modelado utilizando conjuntos, relaciones, funciones, secuencias, etc. Las operaciones se modelan utilizando las, pre y post-condiciones que utiliza AMN.

oo En la implementación de una máquina abstracta, el estado es nuevamente modelado, usando un modelo teórico fijo y así, se tiene una implementación para el modelo. Las operaciones se describen utilizando una notación de pseudo programación, que es un subconjunto de AMN. Se ha puesto gran atención para

79

lograr un aspecto más simple de la notación. Para los ingenieros, la notación formal es vista como una sencilla notación de pseudo-lenguaje no existiendo prácticamente distinción, entre la notación de especificación y un lenguaje de programación.

oo El método B y la notación, se han diseñado juntos con el B-Toolkit que lo soporta, tal que cada aspecto del método, ha sido validado para proporcionar una significativa ayuda en el uso de herramientas basadas en computador que permitan escribir, verificar y mantener sistemas de software. La mayoría de los aspectos teóricos del método, tales como los relativos a pruebas, son hechos automáticamente por las herramientas. Se debe mencionar también, que existe una gran librería de reglas matemáticas provistas por el sistema.

El ejemplo descrito en figura 2.36 [Martins, 2005], muestra el desarrollo en B de una máquina para una agenda de cumpleaños.

2.2.6. Documento de Requisitos.

El documento de requisitos [Sommerville, 2002], es la declaración oficial de lo que requieren tanto clientes, como usuarios del sistema. Este documento, incluye todos los requisitos del cliente y el usuario para el sistema y también una especificación pormenorizada de requisitos del sistema. Normalmente los dos tipos de requisitos se integran en un sólo documento. En algunos casos, los del usuario se definen en una introducción del documento.

El documento de requisitos, tiene diferentes tipos de usuarios, quienes utilizan el documento para fines particulares, por ejemplo:

oo Los clientes del sistema, leen el documento para verificar que se cumplan todas sus necesidades.

oo Los administradores, utilizan el documento para planear el proceso de desarrollo del sistema.

oo Los ingenieros de sistemas, para comprender por qué se desarrollará el sistema.

oo Otros usuarios del sistema, son los ingenieros de pruebas y los ingenieros de mantenimiento del sistema.

Para cumplir con estos objetivos, el documento de requisitos tiene que cumplir las siguientes características [Heninger, 1980]:

oo Especificará la conducta externa del sistema.

oo Especificará los límites de la implementación.

oo Será fácil de cambiar.

oo Servirá como una herramienta de referencia para mantenimiento.

oo Recordará el ciclo de vida del sistema, esto es, permitirá cambios.

oo Proporcionará respuestas características a un evento no esperado.

El documento de requisitos debe también contar con una estructura estándar. Se han definido múltiples estándares para el documento de requisitos entre los que se pueden

80

enumerar IEEE/ANSI 830-1998 [IEEE, 1998], ESA PSS-05-0 de la Agencia Espacial Europea [ESA, 2003], o el British Standard 6719 [Pohl, 2006]. El estándar más conocido es IEEE/ANSI 830-1998. IEEE, sugiere la siguiente estructura para los Documentos de Requisitos [IEEE, 1998], [Sommerville, 2002].

1. Introducción 1.1 Propósito del documento 1.2 Alcance del producto 1.3 Definiciones, acrónimos y abreviaturas 1.4 Referencias 1.5 Resumen del resto del documento

2. Descripción general 2.1 Perspectiva del producto 2.2. Funciones del producto 2.3 Características del usuario 2.4 Restricciones generales 2.5 Suposiciones y dependencias

3. Requisitos específicos (cubren los funcionales, no funcionales y de interfaz). Dada la variabilidad en la práctica organizacional, en este punto, no se define una estructura estándar.

4. Apéndices 5. Índice.

2.3. El proceso de toma de decisiones

Indudablemente, uno de los procesos más complejos y de mayor relevancia, es el proceso de toma de decisiones en todos los aspectos de la vida, tanto en los cotidianos o contingentes, relacionados con las relaciones familiares o sociales, como en los laborales relacionados con el desempeño profesional dentro de una organización. En este proceso, es posible identificar diversos elementos que de una u otra forma intervienen en la toma de decisiones. Estos elementos se pueden definir como sigue. Decisión. De acuerdo al diccionario de la Real Academia de la lengua española [DRAE, 1995] “decisión” se define como la Determinación, o resolución que se toma o se da en una cosa dudosa. En [Hastie, 2001], [García, 2004] se definen, incertidumbre, juicio, preferencias, resultado y consecuencias.

Incertidumbre. La incertidumbre, se relaciona con los juicios de quien toma la decisión sobre las expectativas de los sucesos que puedan ocurrir. Se describe con medidas que incluyen probabilidad, confianza y posibilidad.

Juicio. Es la conducta del proceso de toma de decisiones que se refiere a valorar, estimar, o inferir qué sucesos ocurrirán y cuáles serán las reacciones evaluativas sobre los resultados que se obtengan.

Preferencias. Las preferencias, se refieren a las conductas de selección de un curso de acción sobre otro u otros.

Resultado. Son diversas situaciones que se pueden generar, cuando se llevan a cabo las conductas o cursos alternativos que se han establecido.

81

Consecuencias. Son las evaluaciones subjetivas que se establecen, medidas en diferentes términos, tales como bueno o malo, ganancias o pérdidas, etc., asociadas con cada resultado.

Hechas las consideraciones anteriores, se puede definir al proceso de toma de decisiones, como un proceso complejo, que deriva en la selección de una alternativa o curso de acción, que aparentemente involucra un menor riesgo o mejores resultados, cuando existen dos o más alternativas inciertas y de las que previamente se deberán establecer juicios evaluativos y anticipar posibles consecuencias. En los diversos escenarios que se presentan, frecuentemente se deben tomar decisiones, algunas de ellas casi de manera inconsciente y sin ningún proceso detallado de consideración frente a las posibles consecuencias que conlleve tal o cual decisión. Sin embargo existen situaciones, en las que las consecuencias de una determinada decisión, tienen una mayor trascendencia. De esta manera, es posible clasificar o dividir las decisiones en decisiones programadas y decisiones no programadas [McLeod, 2000], [Olivero, 2006].

Decisiones programadas. Las decisiones programadas o también denominadas decisiones estructuradas, corresponden al tipo de decisiones que se toman, cuando los problemas que se presentan son de tipo estructurado, en los cuales, ya existe un procedimiento definido para su tratamiento. Este tipo de decisiones son normalmente repetitivas y de rutina.

Decisiones no programadas. Las decisiones no programadas o no estructuradas, corresponden a decisiones que se deben tomar para enfrentar situaciones inesperadas o problemas mal definidos, poco estructurados o de naturaleza no repetitiva, para los cuales no existe un procedimiento definido. Este tipo de decisiones son las que normalmente deben tomarse en los niveles más altos en la estructura jerárquica de una organización, es decir en los niveles estratégicos. Los encargados de tomar este tipo de decisiones, deberán considerar un plan o proceso sistemático, que considere diversos componentes, tales como análisis, juicio, información, conocimiento, experiencia y un mayor entendimiento del problema, de manera tal, que las decisiones tomadas sean lo más acertadas posibles.

Sin embargo, no todas las decisiones son de un tipo u otro, más bien un alto porcentaje de las decisiones son de tipo semiestructuradas, es decir una combinación de ambos tipos de decisión. En estos casos, sólo parte del problema cuenta con algún procedimiento definido para su solución.

2.3.1. Toma de decisiones en una organización.

Considerando que en toda organización, una de las mayores responsabilidades es el proceso de toma de decisiones y este proceso se circunscribe a un conjunto limitado de personas, es importante identificar una clasificación del nivel de decisiones de acuerdo a diversas funciones administrativas tales como, planificación, organización, dirección y control, o de acuerdo a múltiples roles que puedan identificarse en la organización, como por ejemplo directivos o administradores de nivel superior, gerentes o administradores de nivel medio y supervisores o administradores de nivel operativo.

82

En función ya sea, de las diversas funciones administrativas o de los diferentes roles asignados para ejercer dichas funciones administrativas, es posible identificar los siguientes niveles en la toma de decisiones [Laudon, 2002], [Laudon, 2004]:

Toma de decisiones estratégicas. La toma de decisiones estratégicas, tiene como función principal determinar los objetivos, recursos y políticas de la organización, es decir, las decisiones están relacionadas fundamentalmente con las funciones de planificación de la organización. En este nivel de decisiones, la problemática es predecir el futuro de la organización en el largo plazo. La responsabilidad de la toma de decisiones, recae en un pequeño grupo de administradores del nivel superior de la organización, quienes son los que manejan los problemas más complejos. Las decisiones que deben tomar, son menos estructuradas por que prácticamente no existen situaciones repetitivas y por lo tanto no pueden aplicarse recetas únicas de solución; muy por el contrario, deben establecerse criterios de evaluación y puntos de vista para cada situación, pues muchos de los datos no son confiables debido a que provienen de fuentes externas en entornos con riesgos e incertidumbre.

Toma de decisiones de nivel gerencial. Son decisiones que se llevan a cabo en las diversas unidades de una organización en las funciones de organización, supervisión y control. Están relacionadas con la eficiencia y eficacia con que se utilizan los recursos y el desempeño de sus diversas unidades operativas. El control gerencial, tiene lugar dentro del contexto de políticas y objetivos amplios establecidos por la toma de decisiones estratégicas y requiere de un conocimiento completo de la toma de decisiones operativas y de ejecución de tareas.

Toma de decisiones en el nivel de conocimientos. En este nivel, las decisiones que se deben tomar están relacionadas fundamentalmente, con la evacuación de ideas orientadas a la elaboración de nuevos productos o prestación de nuevos servicios y con establecer o mejorar los canales de comunicación y distribución de información en la organización.

Toma de decisiones operativas. Finalmente, este nivel decisiones es responsabilidad de los administradores de nivel operativo. Consiste en determinar la forma en que se van a ejecutar las tareas específicas propuestas por los directivos y administradores de nivel medio y requieren decisiones acerca de la determinación de qué unidades de la organización, ejecutan determinadas tareas, con qué recursos y en función de qué criterios de desempeño.

Evidentemente, el proceso de toma de decisiones, no es un proceso simple; en este proceso están involucradas diversas actividades, las cuales deben efectuarse en diferentes instantes y por lo tanto se requiere de procedimientos sistemáticos y la consideración de diversos factores, orientados a tomar decisiones en función de descubrir las mejores soluciones a problemas o situaciones especificas.

2.3.2. Etapas del proceso de toma de decisiones.

Considerando la racionalidad como un elemento fundamental en la toma de decisiones, proceso en el cual deben ser incorporados ciertos ingredientes básicos tales como, la información, el conocimiento, la experiencia, el análisis y el juicio, es importante estructurar el proceso de toma de decisiones, en un conjunto de actividades, fases o etapas que deben cumplirse secuencial e iterativamente. En [Laudon, 2002], se plantean las siguientes etapas:

83

1. Obtención de Información estratégica. Este primer paso, consiste en la obtención de información que permita la identificación de situaciones que generan problemas en la organización, la información recolectada es importante pues permite a los administradores conocer cuál es el estado de la organización y qué tan bien se desempeña ésta, o en qué áreas están localizados los problemas que merman el buen desempeño que se espera en la organización.

2. Diseño. El diseño de posibles soluciones a los problemas detectados, constituye la segunda etapa del proceso de toma de decisiones. Esta actividad, precisa de una mayor información estratégica que la recolectada en la primera etapa y que le permita al administrador o encargado de tomar decisiones, diseñar la solución más adecuada al problema detectado. En esta etapa, es crucial el apoyo que brindan los sistemas de apoyo a las decisiones.

3. Selección. Como su nombre lo indica, en esta tercera etapa, se debe elegir alguna de las alternativas. El administrador debe evaluar previamente cada alternativa que se presente, en función de costes, consecuencias, oportunidades y variables que él estime necesarias. En esta etapa del proceso, es también importante contar con sistemas que le aporten información para la toma de decisiones, pues normalmente existen grandes cantidades de datos que deben ser procesados.

4. Implementación. La implementación es la última etapa del proceso de toma de decisiones y durante esta etapa, los administradores deben evaluar los resultados de la implantación de la, o las soluciones propuestas.

En la figura 2.37 se representa mediante un diagrama, el proceso de toma de decisiones, explicitando además, el carácter iterativo del proceso, pues el proceso no implica una secuencia lineal de actividades; en cada etapa podría ser necesario retornar a la etapa anterior. En la literatura es posible encontrar, además del conjunto de etapas ya definidas, muchos otros planteamientos para el proceso de toma de decisiones; es decir, diferentes propuestas para el conjunto de actividades, fases o etapas que deben seguirse en el proceso de toma de decisiones; sin embargo la mayoría de ellas, salvo diferencias en la redacción, coinciden en describir las siguientes actividades, como las que idealmente deben seguirse durante el proceso de toma de decisiones [Laudon, 2004], [Tarter, 1997], [McLeod, 2000], [Barrera, 2003], [Olivero, 2006], [García, 2004].

Identificación. En la primera etapa del proceso, debe realizarse un diagnóstico de la situación o problema generado, el cual da origen a la necesidad de una decisión. Este diagnóstico debe considerar, el desequilibrio entre cierto estado deseado y el estado actual o condición real en el momento.

Generación de posibles soluciones. En esta etapa, es conveniente realizar una lluvia de ideas, considerando no sólo las alternativas más viables a la vista, sino también formulando posibles hipótesis. Es también importante el identificar los criterios más relevantes que deberán ser evaluados para tomar la decisión.

Evaluación de cursos de acción. Esta etapa, considera la adecuación de las alternativas en estudio y/o su valoración cuantitativa o cualitativa, de tal forma que se pueda seleccionar el mejor curso de acción. Durante este proceso, deben considerarse o predecirse los probables efectos sobre las medidas financieras, administrativas o de desarrollo organizacional. Evidentemente, no será posible predecir con precisión los

84

resultados de cada decisión, por lo que habrá que formular también planes de contingencia o cursos alternativos de acción.

Selección de la mejor alternativa. Luego de realizarse la evaluación de alternativas, el administrador o encargado de tomar decisiones, está en condiciones de adoptar una decisión. En esta etapa, se deben considerar al menos tres criterios muy importantes como son: tomar la mejor decisión posible, el que la decisión sea al menos aceptable o que satisfaga una determinada meta o criterio identificado previamente y que represente el mejor equilibrio posible entre los diversos objetivos establecidos.

Figura No. 2.37. El proceso de toma de decisiones ([Laudon, 2004]).

Implementación de la decisión. Cuando se cumple la etapa anterior, es decir, cuando se asume una decisión, el proceso continúa con la implementación de la decisión. La implementación de la decisión, puede ser realizada por quien o quienes participaron en la decisión, esta responsabilidad también podría ser delegada en otras personas. De una u otra forma, quien asuma la etapa de implementación, debe tener un claro conocimiento y comprensión de la decisión adoptada, las razones que la justifican, y el compromiso en cumplir exitosamente su implementación. Por estas razones es recomendable que los encargados de la implementación de la decisión, hayan participado en todas o en la mayoría de las etapas anteriores.

Evaluación de la decisión. La última etapa del proceso de toma de decisiones, es la evaluación de la decisión. En esta etapa, se recopila toda la información necesaria que contribuya a evaluar las consecuencias de la decisión implementada, estos datos permitirán contar con la necesaria retroalimentación para continuar con el proceso o replicarlo en otras áreas de la organización, cuando los resultados de la decisión sean favorables, o si por el contrario, estos resultados son desfavorables, retornar a etapas anteriores para su revisión e incluso para la redefinición del problema.

2.3.3. Modelos de toma de decisiones.

El proceso de toma de decisiones no es simple como ya se describió, en él intervienen diversos elementos. Es por esta razón, la importancia de conocer determinados modelos que intentan representar o describir, de qué manera los seres humanos toman decisiones.

85

Existen diversos modelos que han sido propuestos [Tarter, 1997], cada uno de ellos se basa en diferentes supuestos y muestra una particular visión del proceso de toma de decisiones. A continuación se describen algunos de los principales modelos.

Modelo Racional. Este modelo, está basado en la teoría económica clásica y asume metas claras, información completa y la capacidad y conocimiento para analizar el problema [Tarter, 1997]. Es probablemente uno de los más ampliamente utilizados [FIS, 1996], se basa en que las personas u organizaciones, toman decisiones en función de cálculos o adaptaciones que optimicen una determinada función objetivo. Es decir, las personas u organizaciones, tienen determinadas metas u objetivos y una función de utilidad o recompensa sujeta a restricciones, en base a la cual, se clasifican las posibles alternativas de acción que mayor aporte signifiquen a su objetivo o meta final, para posteriormente seleccionar un curso de acción, que posea la puntuación más alta en la clasificación. Este modelo de toma de decisiones es interesante, por su sencillez y rigurosidad, sin embargo tiene la desventaja, de que no siempre es posible determinar ni clasificar todos los cursos de acción posibles y en cuanto a las metas, éstas no siempre son únicas.

Modelo de satisfacción. El modelo de satisfacción, propuesto en 1958 por March y Simon [Laudon, 2002], [Simon, 1993], [Tarter, 1997], indica que las personas en general, tratan de elegir la primera alternativa o curso de acción que los acerca a su meta, es decir, establece a diferencia del modelo racional, la aplicación de una racionalidad acotada, limitada a la búsqueda de alternativas y/o procedimientos ya conocidos y probados, evitando considerar alternativas nuevas e inseguras. Este modelo se puede utilizar cuando la información que se dispone es incompleta y los resultados son satisfactoriamente definidos.

Modelo de Selección. El modelo de Selección o de comparaciones limitadas sucesivas, propuesto por Charles Lindblon en 1959 [Tarter, 1997], indica que las personas y las organizaciones se plantean metas inciertas, conflictivas y difíciles de discernir, quieren tanto libertad como seguridad, un rápido crecimiento económico, con un mínimo de contaminación, etc... Estas razones en conflicto impulsan a seleccionar de entre alternativas de similares características. La selección consiste en considerar pequeños cambios incrementales, comparando consecuencias, hasta que alguna alternativa sea considerada una buena selección. No existe un análisis exhaustivo ni criterios predeterminados y producto de contar con información incompleta, las metas también son consideradas tentativas. Este modelo se utiliza cuando se tienen decisiones complejas, salidas inciertas y con estrategias de corto plazo, hasta que sean establecidos procedimientos estándar.

Modelo Político. Las decisiones en el modelo político [Hoy, 1991], [Heller, 1998], [Tarter, 1997], son fruto de la negociación entre los líderes y los grupos de interés de la organización. Las decisiones son el resultado de la competencia política y no siempre consideran la racionalidad, más bien se generan compromisos destinados a satisfacer las diversas demandas que se manifiestan en la organización. Este modelo es utilizado para entender decisiones irracionales.

Modelo de basurero. El modelo basurero o de bote de basura [Laudon, 2002], [Etzioni, 1989], [March, 1982], [Tarter, 1997], considera que la mayoría de las organizaciones son temporales y se extinguen en el tiempo. Las decisiones se toman casi de forma accidental y en función de las contingencias o de situaciones que se asocian aleatoriamente, es decir las soluciones están ligadas a los problemas, en función de

86

razones accidentales. Las personas actúan antes de pensar. Este modelo puede ser utilizado para entender decisiones fortuitas.

Modelo Burocrático. El modelo burocrático, indica que lo realizado por las organizaciones, es consecuencia de procedimientos operativos estandarizados y afinados a lo largo de los años [Thomas, 1984], [Etizione, 1988], [Tarter, 1997]. Los problemas que deben enfrentar las organizaciones, son muy complejos como para que toda la organización los enfrente, por lo tanto las decisiones se toman al interior de las diversas unidades o departamentos en que se estructura la organización, tales como recursos humanos, comercialización, producción, finanzas, etc. Para esto, cada unidad cuenta con procedimientos operativos estándar ya definidos, en función de los cuales, se toman las decisiones. Este modelo es utilizado cuando la información es incompleta, las decisiones complejas y existen políticas organizacionales definidas.

2.4. Modelos de Negocio.

2.4.1. Introducción.

Antes de abordar el estudio de los modelos de negocio, es importante aclarar algunos conceptos, mediante definiciones que permitan posteriormente contextualizar el proceso de modelado de negocios en proyectos de Data Mining. Una empresa, compañía u organización, puede definirse como un agente económico o unidad integrada por capital y trabajo como factores de producción, reglada por ciertas normas sociales y tecnológicas y dedicada a actividades industriales, mercantiles o de prestación de servicios con objetivos bien definidos, como el lucro, el bien común o la beneficencia [BVES, 2006]. Otra definición formal de las múltiples que se encuentran en la literatura, dice [Laudon, 2002] “una empresa u organización, es una estructura social formal estable, que toma recursos del entorno y los procesa para generar salidas”. Las organizaciones son formales, por cuanto su funcionamiento se rige por normas legales o leyes establecidas y también porque consideran un conjunto de reglas, procedimientos y políticas internas. El hecho de que una organización opere dentro del marco de normas jurídicas, permite que ésta sea más estable en el tiempo. Es importante no confundir los conceptos de empresa u organización, con el concepto de negocio. Etimológicamente el termino Negocio, proviene del vocablo latín “Negotium” que significa “toda actividad que genera algún tipo de utilidad” [Nava, 2006], dicho de otra forma, negocio, es toda actividad legal orientada hacia la producción, procesamiento y comercialización de productos y servicios en base a la cual, una compañía genera ingresos y obtiene el provecho económico que le permite permanecer y desarrollarse en el mercado. Por tanto, una organización debe considerar una estructura adecuada, que vaya en apoyo de las actividades de negocio que ésta desarrolla, en función de obtener algún beneficio, utilidad, o provecho económico o social. Un modelo en su concepción más amplia, es una abstracción simplificada, de un fenómeno, de un sistema o de un proceso, mediante una representación esquemática o conceptual, un conjunto de teorías y un conjunto de hipótesis acerca de cómo funciona tal fenómeno, sistema o proceso [Osterwalder, 2005], [Omega, 2006], [Arsham, 2006].

87

Considerando entonces, que un negocio es toda actividad que genera algún tipo de utilidad y que un modelo es una representación simplificada de un sistema o proceso, se puede definir un modelo de negocio como “una representación de la manera en que las empresas producen, distribuyen y venden un producto o servicio, muestra asimismo, la forma en que da valor a los clientes y cómo se crea riqueza” [Magretta, 2002], [Laudon, 2004].

2.4.2. Estructura organizacional.

La estructura organizacional, se puede definir como el conjunto de todas las formas en que se divide el trabajo y la coordinación de cada una de estas formas, consecuentemente toda organización deberá estar dividida en un conjunto de unidades, departamentos o funciones y en un conjunto de roles que deben desempeñar los diferentes miembros de la organización al interior de cada unidad, en pos de alcanzar los objetivos que se definen en los procesos de planificación.

Toda organización, se caracteriza por un conjunto de características comunes, como son la estructura formal, políticas y procedimientos operativos y por un conjunto de elementos particulares que las caracterizan y diferencian unas de otras (tipo de organización, metas, procesos de negocio, tecnología, entornos, etc.).

2.4.2.1. Unidades Funcionales Típicas.

Como se mencionó en el punto anterior, la estructura organizacional es el conjunto de todas las formas en que se divide el trabajo y es así como normalmente las organizaciones formales se estructuran en un conjunto de unidades funcionales o niveles y especialidades [Laudon, 2002] [McLeod, 2000] tales como:

o Administración

o Manufactura

o Ventas y marketing

o Finanzas

o Contabilidad

o Recursos humanos

Administración. En el nivel de administración, se encuentran los encargados de la dirección de la organización, son ellos quienes establecen la misión y visión del negocio. Establecen las metas y objetivos, la estrategia de la organización para responder a las demandas del entorno y tienen a cargo la asignación de los recursos, tanto humanos como financieros para ejecutar las estrategias establecidas y coordinar el trabajo de las diferentes unidades de la organización. Es misión de la administración el aclarar las diversas situaciones que enfrenta la organización, establecer planes de acción cuando se presentan situaciones que generan problemas y en función de las necesidades observadas en el entorno, el idear nuevos productos y/o servicios para responder a las necesidades del mercado.

Los diversos roles en la administración, así como también la jerarquía en la toma de decisiones, se sustenta en los diferentes niveles en que está dividida la organización. Se pueden identificar a:

88

o Directivos o administradores de nivel superior quienes tienen a cargo la toma de decisiones estratégicas de la organización.

o Gerentes o administradores de nivel medio que son los encargados de ejecutar los programas y planes surgidos en el nivel directivo.

o Supervisores o administradores de nivel operativo, quienes se encargan de controlar todas las actividades de la organización.

Para cumplir eficaz y eficientemente, con los diversos roles asignados en los diversos niveles de la jerarquía de administración, es de sustancial importancia el contar con el apoyo de sistemas de información, de generación de nuevos conocimientos y de apoyo a la toma de decisiones.

Manufactura. En esta unidad, se encuentran aglutinados todos procesos relacionados con la fabricación o la transformación de las materias primas en productos terminados o semielaborados destinados a su posterior comercialización, y también los relacionados con la producción de servicios.

Ventas y marketing. La unidad de ventas y marketing tiene como misión, la promoción y comercialización de los bienes y/o servicios producidos por la organización.

Finanzas. A la unidad de finanzas, le corresponde el estudiar, proponer, controlar y administrar de acuerdo a los lineamientos generales y de conformidad con normas legales vigentes, los activos financieros de la organización y consolidar la información financiera que precisen los diversos niveles directivos y unidades que conforman la organización.

Contabilidad. Esta unidad, es la encargada de mantener los registros financieros de la organización y de generar permanentemente los informes financieros y estadísticos que sean requeridos en el nivel de dirección para la toma de decisiones financieras.

Recursos Humanos. El departamento de recursos humanos, tiene como misión la selección y contrato de la fuerza laboral de la organización, la manutención de registros actualizados de los antecedentes del personal, la promoción, reubicación, retiro, permisos, asignaciones y tramitación de solicitudes, administrar programas de perfeccionamiento y capacitación y en general, proponer las políticas para la administración de los recursos humanos en consideración a normas legales vigentes.

Las unidades funcionales, departamentos o divisiones descritas, son algunas en las que tradicionalmente se estructura una organización. Naturalmente que cada organización es diferente en términos de, en qué niveles se divide o estructura, qué funciones se cumplen en cada unidad y quien ejerce y con qué prerrogativas el liderazgo en tales niveles. Organizaciones pequeñas pueden tener una estructura muy simple, organizaciones mayores suelen tener una estructura compleja. De la misma manera, la toma de decisiones en una organización puede estar centralizada en un pequeño grupo ejecutivo o con administración débil, o distribuida en diferentes niveles gerenciales, en función de la magnitud o complejidad de la organización.

Evidentemente el impacto que tengan los sistemas de apoyo a la toma de decisiones será diferente para cada nivel o grupo dentro de la organización.

89

2.4.3. El modelo de negocios.

En la literatura es posible encontrar un sinnúmero de usos del concepto de Modelo de Negocios, de hecho, si se ingresa en cualquier buscador de Internet la frase “Modelo de Negocios”, es posible descubrir más de nueve millones de coincidencias, sin embargo existe poca literatura [Gaarder, 2003] que contenga definiciones y una discusión formal acerca de este concepto. Algunas definiciones coinciden en establecer, como ya se mencionó, que un modelo de negocios “es una representación de la manera en que las empresas producen, distribuyen y venden un producto o servicio, muestra asimismo, la forma en que da valor a los clientes y cómo se crea riqueza” [Magretta, 2002], [Laudon, 2004]. En [Osterwalder, 2005], se registra una definición suficientemente amplia, la cual puede ser utilizada en diversas áreas tales como e-business, sistemas de información, ciencias de la computación, o administración [Pateli, 2003], ésta indica que un Modelo de Negocios, es “una herramienta conceptual, que contiene un conjunto de objetos, conceptos y sus relaciones, con el propósito de representar la lógica de negocios de una empresa específica”. Este conjunto de elementos, permite una descripción simplificada y una representación conceptual de todas las estrategias de producción en una empresa, los procesos, políticas de la organización, uso de tecnologías o tendencias tecnológicas y la estructura organizacional en todos sus niveles de jerarquía. Un modelo de negocios [Ericsson, 2000] podrá contar, con múltiples visiones en función de los aspectos de negocio que se deseen resaltar y/o de acuerdo al tipo de problemas que se quieran resolver. En todos los casos, facilita la comprensión de los procesos de negocios, de la estructura organizacional y del dominio de un determinado problema, identificando las metas de la organización, políticas, estructura organizacional, roles, funciones, etc. En este punto, es conveniente aclarar la distinción entre los conceptos “modelo de negocio” y “modelo de procesos de negocio”, términos que frecuentemente son utilizados indistintamente. Tal como ya se mencionó, un modelo de negocio es un concepto que debe ser entendido, como una vista de la lógica utilizada por la empresa para crear y comercializar valor, mientras que el concepto de modelo de proceso de negocio [Osterwalder, 2005], está relacionado a cómo un caso de negocio es implementado mediante un proceso. En otras palabras, un modelo de proceso de negocio, es la implementación de un modelo de negocio. La confusión que se produce entre ambos términos [Aguilar-Saven, 2004], [Osterwalder, 2005], tiene su origen en que generalmente la expresión “modelado de negocios”, es utilizada principalmente para describir la actividad de modelar procesos de negocio y no modelos de negocio. En resumen, un modelo de negocio, provee una vista simplificada de la estructura del negocio, mediante la abstracción de su complejidad inherente, permitiendo una mejor comunicación entre los diferentes actores del negocio (propietarios, gerentes, empleados y clientes), constituye también un documento base, que facilita el desarrollo de tareas orientadas a mejorar o innovar en los procesos, permitiendo identificar además, nuevas oportunidades de negocio. Es importante considerar sin embargo, que si bien un modelo es una abstracción de cómo funciona el negocio, los detalles del modelo son función de la visión de quien o quienes crean el modelo, los que podrían tener diferentes visiones acerca de los objetivos y otros aspectos del negocio, estas diferentes

90

percepciones son absolutamente normales y un modelo no resuelve por completo estas diferencias. Respecto de su aplicación en el área de Data Mining, un modelo de negocios debe contribuir o facilitar la fase de comprensión del negocio, permitiendo además una identificación y validación más eficiente de los requisitos del proyecto.

2.4.3.1. Dominios de aplicación del concepto de Modelo de Negocios. La investigación y aplicación del concepto de Modelo de Negocios es relativamente nueva. En [Osterwalder, 2005] se reporta, que este término fue utilizado por primera vez en un artículo académico publicado en 1957 [Bellman, 1957], sin embargo este concepto alcanzó prominencia sólo a finales de la década de los 90. De acuerdo a la definición de Modelo de Negocios, las contribuciones de este concepto, debieran centrarse principalmente en la creación de conceptos y herramientas que permitan a un administrador, entender y compartir, analizar, administrar y proyectar la lógica de negocios de su empresa [Osterwalder, 2005].

Entender y Compartir. En este dominio de aplicación, un modelo de negocios permite capturar, visualizar, entender, comunicar y compartir la lógica de negocios de una organización. En general, todo administrador u hombre de negocios, tiene claro cómo trabaja su negocio, es decir tiene un modelo mental de él, pero no siempre tiene la capacidad de comunicar este modelo mental de una manera clara y no ambigua. Los modelos mentales, difieren de una persona a otra [Linder, 2000] y las relaciones entre los diferentes elementos de un modelo de negocios y factores claves de éxito, no son siempre inmediatamente observables. Por lo tanto, es necesario contar con un lenguaje común que permita representar los diferentes conceptos de una manera clara y explícita al momento en que los stakeholders formulen el modelo de negocios de la organización. De esta manera y considerando que los seres humanos, no tienen la capacidad de procesar información compleja, una representación visual de la información permitirá manejar y entender de una manera más exitosa, la complejidad inherente de la lógica de negocios de una organización y consecuentemente comunicar y compartir esta información [Fensel, 2001].

Analizar. El concepto de Modelo de Negocios puede también contribuir a las actividades de medir, observar y comparar la lógica de negocios de una organización [Stähler, 2002]. Un modelo de negocios, facilita la identificación y medición de los parámetros o indicadores que permiten mejorar la gestión de la organización y también el monitoreo de estos parámetros, bajo la consideración, de que la lógica de negocios de una compañía no permanece estática y cambia frecuentemente en función de factores internos o externos. Disponer de un modelo de negocios, permite comprender y visualizar determinados elementos del negocio y cómo ellos evolucionan en el tiempo, pudiéndose finalmente, establecer comparaciones con modelos de negocio de competidores, bajo la premisa de que las cosas sólo son comparables si se entienden de igual forma. El establecer comparaciones puede resultar beneficioso, pues el resultado de ellas podrá originar e impulsar cambios e innovaciones que permitan una mayor competitividad.

Administrar. El concepto de modelo de negocios ayuda a mejorar la administración de la lógica de negocios de una organización, pues facilita el diseño, planificación, introducción de cambios e implementación de un modelo de negocios, permitiendo

91

además, que la organización responda más rápidamente a los cambios y presiones del entorno. Diseñar un modelo de negocios coherente, no es una tarea simple, por que los modelos de negocios son a menudo complejos, sobre todo, por que el incremento en la tecnología, amplía el rango de modelos de negocios [Lechner, 2002]. Tener una conceptualización del modelo, que describa los bloques esenciales y sus relaciones, permite diseñar modelos más sustentables. Por otro lado, cuando una organización [Osterwalder, 2005], decide cambiar o adoptar un nuevo modelo, su captura y visualización permitirán, planificar, introducir cambios e implementarlo más fácilmente.

Proyectar. El concepto de modelo de negocios puede también ayudar a impulsar la innovación, con una mirada hacia el futuro, a través de un portafolio de modelos de negocio y la simulación. Un modelo de negocios formal y modular puede promover la innovación. La especificación de un conjunto de elementos, bloques constructivos y sus relaciones, permite al diseñador del modelo de negocios, contar con herramientas con las cuales pueda crear completamente nuevos modelos de negocio y percibir los modelos como fuentes de innovación y generación de ventajas competitivas. A su vez el conjunto de nuevos modelos creados, permitirá contar con un portafolio de modelos de negocio que puedan utilizarse en el futuro. En [Allen, 2001], [Osterwalder, 2005] se sugiere, que los agentes necesitan contar con un stock de potenciales estrategias para enfrentar la incertidumbre que conllevan los cambios en el entorno. En el caso de una compañía, un stock de modelos de negocio permitiría enfrentar satisfactoriamente estos cambios. Por otro lado, contar con un modelo de negocios permite disponer de una herramienta, con la cual realizar experimentos de simulación menos riesgosos que lo que representaría un experimento real, para tener información que permita enfrentar el futuro, con mayores posibilidades de éxito. Finalmente, considerando que el concepto de modelo de negocios permite mejorar la comprensión y comunicación de la lógica de negocios de una organización, se desprende también, que los tomadores de decisiones, podrán tomar mejores decisiones y crear modelos de negocio decisionales [Hayes, 2005]. Los modelos de negocios, son una nueva unidad de análisis que puede ser observada y comparada para ayudar a medir, y consecuentemente a mejorar las decisiones [Osterwalder, 2005], [Stähler, 2002].

2.4.3.2. Aportes del concepto de Modelo de Negocios, en la aplicación de la Ingeniería de Requisitos a proyectos de Data Mining.

Como se enuncia en el punto 2.2.2.1 (Ingeniería de Requisitos en Ingeniería del Software), las actividades fundamentales que comprende el proceso de Ingeniería de Requisitos son: la elicitación o captura de los requisitos, el análisis, la especificación y finalmente la validación de éstos. El proceso de elicitación de los requisitos, no sólo involucra descubrir qué es lo que los clientes desean, sino también el análisis y entendimiento del dominio de aplicación y de negocios en el cual el sistema será utilizado [Kotonya, 1998]. Cuando se inicia el desarrollo de un proyecto de Data Mining, uno de los aspectos relevantes que deben ser considerados, es el descubrimiento de las necesidades organizacionales que puedan ser apoyadas por un proyecto de Data Mining. En consecuencia, es importante que los responsables de este proceso de descubrimiento, tengan un completo conocimiento de la organización, del dominio del problema a ser resuelto y de los objetivos organizacionales que precisan ser satisfechos. En

92

[Osterwalder, 2005], se indica que el rol de un modelo de negocios es definir las metas, flujos de trabajo y procesos de la organización. Normalmente, los administradores, los expertos de negocio, o los encargados de generar las estrategias para el futuro de la organización, debieran poder transmitir a los desarrolladores de una manera precisa, lo que ellos esperan del proyecto [Linder, 2000], sin embargo, si bien ellos entienden intuitivamente como trabaja su negocio, en muchos casos no tienen la capacidad para comunicar de una manera clara y precisa esta información. Por otro lado los expertos en DM, deberían poder vislumbrar de qué manera un sistema de DM podría contribuir al cumplimiento de las metas de la organización, pero este es un esfuerzo, que en muchas ocasiones no se logra. Un modelo de negocios por lo tanto, puede servir como un puente que permita una mejor y mutua comunicación entre ambas comunidades (figura 2.38).

Figura No. 2.38. Nexo entre los Expertos de negocio y desarrolladores de Data Mining (elaborado en base a [Osterwalder, 2005]).

Luego de construido el modelo de negocios de la organización, los expertos de negocio y desarrolladores de Data Mining, podrán contar con un instrumento común que les facilite la identificación de los objetivos estratégicos de la organización que dan origen al proyecto de DM y una mejor comprensión de la forma en que un proyecto de Data Mining, puede contribuir al logro de los objetivos señalados. Los objetivos estratégicos de la organización, son de la mayor relevancia para el proceso de Ingeniería de Requisitos [Mylopoulos, 1999], sin embargo no existen mayores recomendaciones acerca de cómo estos objetivos deben ser definidos. En la figura 2.39, se ilustra cómo el concepto de modelo de negocios, puede ser utilizado como un instrumento de ayuda para conceptualizar e ilustrar la estrategia de negocios de una organización y definir sus objetivos estratégicos, su relación con la infraestructura organizacional de la empresa y la relación de negocios con un sistema de apoyo a la toma de decisiones en general y un sistema de Data Mining en particular.

93

ESTRATEGIA ORGANIZACIONAL

MODELO DE NEGOCIOS

PROBLEMADE

NEGOCIOS

OBJETIVOS ESTRATÉGICOS

SISTEMA DE APOYO A LA TOMA

DE DECISIONES

Estructura OrganizacionalInfraestructuraProcesos de NegocioRecursosFactores Críticos de ÉxitoCompetencias, etc.

Objetivos de Negocio Problema de Data MiningFactores de ÉxitoInfraestructura RequeridaInventario de RecursosProceso de Ingeniería de Requerimientos

Figura No. 2.39. El Modelo de Negocios y los Objetivos Estratégicos (elaborado en base a [Osterwalder, 2005]).

2.4.3.3. Componentes Elementales de un Modelo de Negocios. En un estudio registrado en [Osterwalder, 2005], se definen los bloques constructivos elementales, a partir de los cuales se podría construir un modelo de negocios. El documento describe que la definición de los mencionados bloques elementales, se realizó en base a un estudio comparativo entre los modelos mayormente citados en la literatura y los componentes utilizados en estos modelos. Del estudio realizado, emergen nueve bloques elementales los cuales se soportan sobre cuatro pilares principales [Lagha, 2004]. Estos pilares son los siguientes:

a. Productos y servicios b. Interface con el cliente c. Administración de la infraestructura d. Aspectos financieros

a) Productos y servicios. Este es el primer pilar y en él se describen los productos y servicios que la compañía, firma, empresa u organización oferta y por los cuales los clientes estarían dispuestos a pagar. El principal elemento o bloque constructivo dentro de este ítem es la propuesta de valor.

1. Propuesta de valor. Este elemento se refiere al valor que una empresa ofrece a un segmento específico de clientes y se orienta en tres direcciones: primero ofertando productos personalizados e innovadores, segundo entregando productos a precios menores que los de la competencia y tercero brindando un alto nivel de servicios.

b) Interface con el cliente. En este segundo pilar, se aglutinan tres elementos cuyo común denominador es la relación que se establece entre la empresa y sus clientes, relación que se ve fuertemente influida en la actualidad por la utilización de las modernas tecnologías de información y comunicaciones (TIC). Los elementos que forman parte de este pilar son los siguientes:

94

2. Clientes objetivo. El principal propósito de una organización, es crear valor para un determinado segmento de consumidores. Este elemento describe el segmento de clientes para los cuales la empresa crea valor.

3. Canales de distribución. Este elemento se refiere a la forma en la cual la organización se relaciona con sus clientes, es decir a los medios que utiliza para comerciar sus productos y llegar a sus clientes [Hamel, 2000], [Lagha, 2004]. Toda organización debe definir los canales de distribución que utilizará, ya sea directos o provistos por la propia compañía, o indirectos o provistos por terceros. El propósito de la definición de una estrategia de distribución, es planificar el transporte de las cantidades correctas y de los productos correctos, a los clientes correctos y en el tiempo preciso.

4. Relacionamiento. Este elemento describe el tipo de nexos que una organización establece con los diferentes segmentos de clientes. Para una compañía es esencial establecer lazos de confianza y lealtad, sobre todo en negocios de tipo virtual, porque en ese caso las partes no necesariamente se conocen (modelos de negocio de e-business). La lealtad se entiende como resultado de los lazos de confianza y el grado de satisfacción con los productos o servicios que brinda la organización. Una compañía, debe establecer una relación en la cual, los aspectos emocionales y transaccionales jueguen un rol muy importante.

c) Administración de la infraestructura. El tercer pilar, aglutina tres elementos que dicen relación con los recursos y actividades necesarias para la generación de valor, las competencias que se requieren para este propósito y la red de colaboradores con que cuenta la empresa. Una descripción de cada uno de los elementos que conforman este pilar es la siguiente:

5. Configuración de valor. El principal propósito de una organización, es la creación y comercialización del valor por el cual los clientes están dispuestos a pagar. Este valor, es el resultado de la configuración de una serie de recursos tangibles (como plantas, equipos, capital, etc.), intangibles (patentes, licencias, conocimiento, etc.) y humanos, con que cuenta una organización y un conjunto de actividades y procesos, tanto internos como externos.

6. Competencias clave. Este elemento, sirve para representar el conjunto de capacidades que la organización debe poseer para la creación del valor que se propone. En [Lagha, 2004], se menciona que varios autores, describen como se relacionan el valor y las capacidades o competencias que la compañía debe poseer [Bagchi, 2000], [Wallin, 2000]. Estas capacidades son patrones de acción repetibles que la empresa debe tener a objeto de crear y comercializar valor.

7. Red de colaboradores. Este elemento, se utiliza para describir el tipo de alianzas estratégicas que configura una organización con otras empresas, para poder satisfacer en forma más eficiente las demandas de los clientes [Lagha, 2004]. Estas pueden ser [Gulati, 2000], [Lagha, 2004], alianzas estratégicas, joint-ventures, sociedades, etc.

d) Aspectos financieros. Este pilar está compuesto por los últimos dos elementos o bloques constructivos elementales definidos en [Osterwalder, 2005], que son la estructura de costes y el modelo de rentabilidad. Este pilar es transversal a los tres

95

pilares descritos anteriormente por su influencia en ellos. Una definición de los elementos constructivos de este pilar es la siguiente:

8. Estructura de costes. Este elemento, sirve para representar los costes en que incurre la empresa en la creación y comercialización de valor, es decir valoriza los recursos, actividades y coste de la red de colaboradores de la compañía. 9. Modelo de rentabilidad. Este elemento, mide la capacidad de valorizar monetariamente el valor que produce y el retorno que significa su comercialización mediante diferentes estrategias y con diferentes costes.

La tabla 2.2 muestra en forma resumida los diferentes pilares definidos y los elementos que sustenta cada uno de estos pilares.

Tabla 2.2. Bloques elementales de un modelo de negocios [Osterwalder, 2005].

PILAR BLOQUE DEL MODELO DESCRIPCIÓN Productos y

Servicios Propuesta de valor Entrega una visión acerca de los

productos y servicios que ofrece la compañía

Interface con el cliente

Clientes objetivo

Describe los segmentos de clientes que la compañía desea

capturar. Canales de distribución Describe los medios que usa la

compañía para contactarse con sus clientes

Relacionamiento Explica el tipo de relaciones que la compañía establece con los

diferentes segmentos de clientes

Administración de la

infraestructura

Configuración de valor Describe el arreglo de actividades y recursos

Competencias clave Muestra las competencias necesarias para ejecutar el modelo de negocios de la

compañía Red de colaboradores Describe la red de acuerdos de

colaboración con otras empresas necesaria para satisfacer

eficientemente a los clientes

Aspectos Financieros

Estructura de costes

Indica las consecuencias monetarias de los medios utilizados en el modelo de

negocios Modelo de rentabilidad Describe la forma en que la

empresa logra dinero mediante una variedad de flujos de

rentabilidad

96

La propuesta de estos nueve elementos o bloques elementales para definir un modelo de negocios no es la única. Otros autores hacen diferentes planteamientos. Por ejemplo, en [Gaarder, 2003], en base a la definición de modelo de negocios propuesta en [Chesbrough, 2002], se proponen y discuten seis elementos básicos principales y necesarios para el procedimiento de diseño y análisis de un modelo de negocios. Los autores mencionan que si alguno de estos elementos se omite, las posibilidades de crear un negocio exitoso, se ven seriamente afectadas. Los seis elementos que se plantean son los siguientes.

1. Propuesta de valor 2. Clientes y segmentos de mercado 3. Cadena de valor interna 4. Estructura de costes y potencial beneficio 5. Posición en la red de valor 6. Estrategia para posicionamiento y competencia

1. Propuesta de valor. Es una definición informal de la noción del valor que tiene el producto para el potencial cliente. Esta definición no siempre es sencilla y por tanto se divide en dos partes las cuales en su conjunto, constituyen la propuesta de valor.

a) La descripción del producto per se. b) Una descripción del problema resuelto para el cliente por el producto

descrito.

Para aclarar el concepto se puede proponer el siguiente ejemplo:

a) Productos: Un cajero automático. b) Problema resuelto: Acceder a los servicios bancarios las 24 horas del día.

Las razones que justifican esta división, son el hecho que cuando se desarrolla un nuevo producto, es necesario contar con una descripción de él en términos relativamente concretos y segundo, es necesario describir la necesidad del cliente por el producto, en términos de qué problema le resuelve éste al cliente.

2. Clientes y segmentos de mercado. Luego de descrito el producto, es necesario describir cuál es el mercado y los potenciales clientes para éste. Es importante conocer a quien irá dirigido el producto. Cuando no se tiene claridad sobre un potencial mercado, se debe reconsiderar su viabilidad. En una fase preliminar, no es necesario una descripción exacta del posible mercado, más bien se precisa una descripción más general, por ejemplo, gente joven o vieja, negocios privados o públicos, etc. Si el primer elemento (propuesta de valor), está bien descrito, debería ser posible el describir el por qué existe un segmento de mercado que es potencial consumidor del producto propuesto. Si no es posible describir un segmento de mercado para el producto, ¿cuál es el problema?, probablemente el producto no es visto como necesario y por lo tanto debería reconsiderarse su viabilidad.

3. Cadena de valor interna. Una vez definidos el producto y un posible mercado, la cadena de valor interna, describe cómo el producto se lleva al mercado, o sea, cómo se produce, se presenta al cliente, se distribuye y se vende y es función de si el producto a producir será un producto tangible, por ejemplo un dispositivo de hardware, o intangible como por ejemplo un servicio de comunicaciones.

4. Estructura de costes y potencial beneficio. Este cuarto elemento es utilizado para describir los ítems de coste más relevantes y la rentabilidad requerida para que se produzcan utilidades. Considerando el supuesto mercado descrito en el punto

97

anterior y habiendo establecido una estructura de costes, es posible presumir con un cierto grado de certeza la posible ganancia, dado un determinado volumen de ventas y por lo tanto, la producción necesaria para satisfacer dicha demanda.

5. Posición en la red de valor. Luego de definidos el mercado y el producto, como se describió anteriormente, es necesario considerar las relaciones necesarias con otros competidores en el mercado. La red de valor, consiste en el conjunto de clientes, socios, proveedores y competidores. Lo descrito por este elemento, es de importancia y particularmente crítico para determinados productos. Cuando el producto es independiente de la presencia de otros productos o actores, se debe verificar sólo que exista la red de proveedores, los canales de distribución y los medios de cobranza. Sin embargo, cuando el producto es dependiente de la existencia de otros productos o actores en el mercado, se hace crítico el establecimiento de la red de valor, ya que la existencia de uno, depende de la existencia del otro.

6. Estrategia para posicionamiento y competencia. Este último elemento, considera la definición de un plan efectivo de acción para el posicionamiento del producto en el mercado. Los cinco elementos del modelo de negocios descritos anteriormente, por muy bien que hayan sido descritos, no son suficientes si no se cuenta con una estrategia de posicionamiento en el mercado, saber cómo competir por esa posición y ganar con cierta ventaja a los competidores.

La definición de los seis elementos descritos, permite la estructuración del plan de negocios, en el cual se cuantificarán todos los elementos relacionados con los costes y ganancias, mediante las herramientas de análisis que se posean en una empresa. Para concluir, en un artículo [Lagha, 2004] publicado en el 2004, se realiza un riguroso estudio para definir los bloques constructivos de un modelo de e-business, mediante la propuesta de una ontología o marco de trabajo, inspirado en diferentes proyectos ontológicos de empresas descritos en la literatura académica. Una ontología provee esencialmente un entendimiento común de un dominio específico, definiendo sus elementos y las relaciones entre estos elementos. Los bloques propuestos, se estructuran en cuatro pilares principales:

a. Innovación del producto b. Gestión de la Infraestructura c. Capital de relación con el cliente d. Aspectos financieros

Estos pilares, son similares en su esencia, a los ya descritos anteriormente y aglutinan de diferente forma los doce bloques constructivos que se proponen, básicamente, similares a los nueve bloques ya descritos en [Osterwalder, 2005]. El primer pilar define los diferentes aspectos relacionados al producto y comprende los siguientes bloques constructivos:

a.1 Proposición de Valor a.2 Cliente Objetivo a.3 Capacidades

Las relaciones entre estos elementos se ilustran en la figura 2.40.

98

Figura No. 2.40. Innovación del producto ([Lagha, 2004]).

El segundo pilar, describe la configuración de valor del sistema, que es necesaria para entregar la propuesta de valor, los elementos que se definen en este segundo pilar son:

b.1 Configuración de la actividad b.2 Red de colaboradores b.3 Recursos y activos

Las relaciones entre ellos se muestran en la figura 2.41.

Recursos y activos

Actividad y configuracion del

procesos

Red de socios

Recursos para

Necesita

Necesita

Socios para

Figura No. 2.41. Gestión de la Infraestructura ([Lagha, 2004]).

En el tercer pilar y mediante las TIC (Tecnologías de Información y Comunicación), la empresa puede redefinir su relación con el cliente, explorando diversas formas de entregar valor, cubriendo nuevos y múltiples canales y asumiendo además que los lazos de confianza y lealtad, son elementos de suma importancia en el mundo de los negocios. Este tercer pilar comprende a los siguientes bloques constructivos:

c.1 Estrategia de Información c.2 Sentir y servir (canales de distribución) c.3 Confianza y lealtad

La figura 2.42, muestrea las relaciones existentes entre estos elementos.

Figura No. 2.42. Capital de relación con el cliente ([Lagha, 2004]).

Finalmente el cuarto pilar, está compuesto por el modelo de rentabilidad de la empresa y su estructura de costes. Lo cual se traduce, en el modelo de utilidades de la empresa y su capacidad para sobrevivir a la competencia. Los tres elementos que componen este pilar son:

99

d.1 Modelo de rentabilidad d.2 Estructura de costes d.3 Modelo de utilidad

Las relaciones entre estos elementos, es representada en la figura 2.43.

Estructura de costes

Estructura de utilidad

Estructura de rentabilidad

Disminuye

Minimiza

Maximiza

Aumenta

Figura No. 2.43. Aspectos financieros ([Lagha, 2004]).

En la tabla 2.3 se muestra en forma resumida los diferentes pilares ya citados, los elementos involucrados en cada pilar y una breve descripción de cada elemento.

Tabla 2.3. Bloques constructivos de un modelo de negocios (elaborada en base a [Lagha, 2004].

PILAR BLOQUE DEL MODELO DESCRIPCIÓN

Innovación del

producto

Proposición de valor

Se refiere al valor que la empresa ofrece a un segmento especifico de clientes

objetivo Cliente objetivo

El segmento especifico de clientes para los

cuales la empresa crea valor Capacidades

Rango de capacidades que la empresa posee, para crear el valor que oferta

Gestión de la

infraestructura

Configuración de la actividad

Configuración de actividades y procesos internos y externos para crear el valor

ofertado Red de colaboradores

Describe la red de socios entre los cuales

se distribuyen las diferentes actividades de la empresa

Recursos y activos

Describe los recursos tangibles, intangibles y humanos que la empresa requiere para

crear valor

Capital de

relación con el cliente

Estrategia de información

Define las estrategias de recolección, uso y explotación de la información de clientes.

Sentir y servir

Describe cómo una empresa comercializa el valor creado y realmente llega al

consumidor. Confianza y lealtad

Describe los mecanismos mediante los

cuales la empresa crea los necesarios lazos de confianza y lealtad con los clientes

Aspectos Financieros

Modelo de rentabilidad

Mide la habilidad de una empresa de valorizar en dinero, el valor que ofrece a

sus clientes Estructura de costes

Mide los costes en que incurre una

empresa para crear, comercializar y entregar valor a sus clientes.

100

PILAR BLOQUE DEL MODELO DESCRIPCIÓN Modelo de utilidad Este elemento mide el nivel de rentabilidad

logrado por la creación y comercialización del valor ofertado.

2.4.3.4. Notaciones para la representación de Modelos de Negocios.

En el ámbito de los Sistemas de Software, la Ingeniería de Software (IS) provee una variedad de herramientas CASE que facilitan el desarrollo de las diversas etapas que componen un proceso de IS. Estas herramientas pueden extenderse para el desarrollo de modelos de procesos de negocios y modelos de flujo de trabajo (WorkFlow). Sin embargo en el dominio de los Modelos de Negocio, se requiere de una mayor conceptualización antes de utilizar la asistencia computacional [Osterwalder, 2005]. Una vez que los diferentes objetos, elementos y sus relaciones sean claramente identificados, el uso de herramientas basadas en software podría ser muy útil y en este sentido se ve muy promisorio el desarrollo de la Ingeniería de Negocios Asistida por Computador (CABE). Por ahora, para el desarrollo de modelos de procesos de negocios es posible considerar la adaptación de algunos lenguajes utilizados en determinadas etapas del proceso de desarrollo de software. Las diferentes notaciones a tratar en la presente sección, corresponden a técnicas de especificación gráfica, entendiéndose por especificación, como el proceso mediante el cual, se describe un sistema y sus propiedades. Estas técnicas pueden ser utilizadas, para entregar la descripción del proceso de negocio, para describir el sistema a ser desarrollado, para guiar en la ejecución de las actividades relacionadas con su desarrollo y adicionalmente, para verificar que los requisitos del sistema sean completa y exactamente especificados. Entre las técnicas o lenguajes más ampliamente utilizados para el modelado de procesos de negocio, se pueden citar los siguientes.

2.4.3.4.1. UML (Unified Modeling Language) para modelado de negocios. UML [Larman, 2003], adoptado como estándar por el OMG (Object Management Group), es un lenguaje de modelado gráfico muy simple, que ha pasado por varios procesos de unificación y de estandarización. En sus primeros años, UML fue principalmente utilizado para modelar sistemas de software es decir, como un medio de expresión de los diferentes modelos que se crean durante el desarrollo de un sistema de software. En la versión 2.0, se incorporaron primitivas que permiten utilizarlo como un lenguaje adecuado para representar modelos de negocio y sus procesos [Russell, 2006], [Johnston, 2004], [Ericsson, 200], además, existen perfiles como el “Rational UML Profile for Business Modeling”, donde se definen primitivas especializadas en el dominio del negocio (figura 2.44) como actores, trabajadores de negocio, objetivos de negocio y reglas de negocio [Johnston, 2004], [Sánchez, 2006]. UML permite actualmente, representar los aspectos estructurales de un negocio tales como, la organización, la estructura de los recursos, aspectos del desempeño del negocio tales como sus procesos o las reglas que gobiernan la ejecución del negocio y que están involucradas en su estructura o desempeño [Ericsson, 2000]. Para hacer posible dichas representaciones, es posible utilizar mecanismos de extensión estándar

101

tales como los estereotipos, que permiten definir, nuevos elementos que sean adecuados para modelar negocios.

Figura No. 2.44. Extensiones de UML para modelado de negocios [elaborado en base a [Johnston, 2004]).

Una ventaja de modelar negocios con UML, es que permite bosquejar funciones o relaciones del negocio que usualmente son difíciles de visualizar. Sin embargo, existen investigaciones [Schewe, 2000], [Glinz, 2000], [Berenbach, 2004] que evidencian algunas desventajas, tales como: la sintaxis no es claramente presentada, ausencia de definiciones precisas, mucha sintáctica que no contribuye en nada a la semántica, deficiencias para describir correspondencias tales como la transformación entre elementos en diferentes vistas, falta de claridad respecto de los niveles de abstracción, generación de un elevado número de documentos y utilización de una parte reducida del lenguaje para modelar negocios.

UML define dos categorías básicas de diagramas: diagramas de modelado estructural y diagramas de comportamiento. Diagramas de modelado estructural: Los diagramas de modelado estructural, definen la arquitectura estática de un modelo. Incluyen las clases, componentes y objetos y son utilizados para modelar las relaciones y las dependencias entre ellos.

o Diagrama de paquetes: Son usados para dividir el modelo en contenedores lógicos, o “paquetes” y describir las interacciones entre ellos a todo nivel.

o Diagrama de clases o estructural: Definen los bloques de construcción básicos de un modelo, los tipos, clases y materiales generales usados para construir un modelo completo.

o Diagrama de objeto: Muestran cómo las instancias del elemento estructural son relacionadas y utilizadas.

o Estructura compuesta: Es un diagrama que muestra la estructura interna de un clasificador, incluyendo sus puntos de interacción con otras partes del sistema.

102

o Diagrama de componentes: Representan los componentes que tiene una aplicación, sistema o empresa. Proveen una buena definición de interfaces.

o Diagrama de desarrollo: Muestra la disposición física de los artefactos importantes dentro de la configuración del mundo real.

Diagramas de modelado del comportamiento: Los diagramas de comportamiento, capturan el comportamiento dinámico entre los objetos del sistema. Realizan un seguimiento de cómo el sistema actuará en un entorno real, observando los efectos de una operación o evento, incluyendo sus resultados.

o Diagrama de casos de uso: Son usados para modelar las interacciones entre los usuarios y el sistema. Ellos definen el comportamiento, requisitos y restricciones en la forma de escenarios.

o Diagrama de actividades: Tienen un amplio número de usos, desde definir diagramas de flujos básicos, hasta capturar los puntos de decisión y acciones dentro de cualquier proceso generalizado.

o Diagrama de máquina de estado: Son esenciales para entender el instante, la condición del instante, o el “estado de ejecución” de un modelo cuando éste es ejecutado.

o Diagrama de comunicación: Muestra las redes y secuencia, de mensajes o comunicaciones entre objetos en ejecución, durante la instancia de colaboración.

o Diagrama de secuencia: Están estrechamente relacionados con los diagramas de comunicación y muestran la secuencia de mensajes pasados entre objetos, usando una línea de tiempo vertical.

o Diagrama de tiempo: Son usados para desplegar los cambios en un estado o el valor de uno o más elementos en el tiempo. Puede también mostrar las interacciones entre el tiempo de los eventos y las restricciones de la duración que los gobiernan.

o Diagrama de descripción de interacciones: Es una forma de diagrama de actividades en la cual, los nodos representan diagramas de interacción. Los diagramas de interacción pueden incluir secuencia, comunicación, descripción de interacciones y diagramas de tiempo.

2.4.3.4.2. BPMN (Business Process Modeling Notation). El estándar BPMN (Business Process Modeling Notation), [BPMI, 2004], [White, 2004], es un sistema grafico para el modelado de procesos de negocio, fue desarrollado por BPMI (Business Process Management Initiative) y posteriormente adoptado por el OMG (Object Management Group). La meta principal de BPMN, es proveer una notación sencilla y comprensible para todos los usuarios empresariales y analistas de negocios, que permita como consecuencia, facilitar los procesos de comunicación en la organización y la gestión y supervisión de los procesos de negocio. BPMN permite crear un puente estandarizado entre los procesos de negocio y los procesos de diseño e implementación de sistemas. Define un diagrama de procesos de negocio (BPD) que está basado en la técnica de diagramas de flujo, adaptado a la creación de modelos gráficos de procesos de negocio, es decir genera una red de objetos

103

gráficos los cuales representan actividades y el control de flujo que define su orden de ejecución. BPMN, es una notación relativamente nueva, la versión 1.0, fue liberada en mayo de 2004 y actualmente se encuentra en proceso de difusión y consolidación, por cuanto la visualización de los procesos de negocio que presenta (mediante un formato de diagrama de flujo) es mucho más simple que la que presenta el diagrama de actividades de UML. BPMN, no posee gran cantidad de primitivas, lo cual permite un rápido adiestramiento de personas no ligadas a los niveles gerenciales de las organizaciones, ni expertas de negocio. Sin embargo, es importante señalar el alcance de BPMN ya que tiene restricciones para soportar sólo conceptos de modelado que son aplicables a los procesos de negocio, lo cual significa que otros tipos de modelos realizados por las organizaciones para fines de negocio están fuera del alcance de la notación. Por ejemplo, no se incluye: estructura organizacional y recursos, modelos de datos e información, estrategias y reglas de negocio. La figura 2.45 representa una ilustración de los elementos gráficos básicos de modelado de BPMN [BPMN, 2008], estos elementos permiten un fácil desarrollo de diagramas de procesos de negocio. Fueron definidos para ser distinguibles unos de otros utilizando formas familiares a la mayoría de los modeladores, tales como por ejemplo rectángulos para las actividades, o diamantes para las decisiones, es decir elementos sencillos para la creación de modelos de negocio y al mismo tiempo capaces de manejar la complejidad inherente de los procesos de negocio. La notación es organizada en categorías específicas a objeto de que el lector de un diagrama, pueda reconocer fácilmente los tipos básicos de elementos y comprender el diagrama.

Eventos

Decisiones

Actividades

Grupo

Objeto de dato

Nom

bre

Nom

bre

Flujo de secuencia

Flujo de Mensaje

Asociación

Anotación de texto

Pool

Lanes

Objetos de Flujo Conectores Artefactos Elementos de División

Figura No. 2.45. Conjunto de elementos básicos de BPMN ([White, 2006]).

Las cuatro categorías básicas de elementos son:

1. Objetos de flujo: Eventos, actividades, gateways.

2. Conectores: Secuencia de flujo, flujo de mensajes, asociación.

3. Artefactos: Objeto de datos, grupo, anotación.

4. Elementos de División: Pools, lanes.

104

En la tabla 2.4, se consigna el significado de los elementos básicos de BPMN

Tabla 2.4. Descripción elementos básicos de BPMN (adaptado de [BPMN, 2008])

ELEMENTO DESCRIPCIÓN

Evento

Un evento es algo que “ocurre” durante el curso de un proceso de negocio. Ellos afectan el flujo de los procesos y usualmente tienen una causa (de activación) o un impacto (resultado).

Actividad

Una actividad es un término genérico para el definir el trabajo que se ejecuta. Puede ser atómica o no atómica Los tipos de actividades que son parte de un modelo de proceso son: Sub-proceso y tarea.

Gateway

Un Gateway, es usado para controlar la divergencia y convergencia en la secuencia de flujo de un proceso.

Conectores

Existen tres tipos de conectores: de flujo de secuencia, flujo de mensaje o asociación. El de flujo de secuencia es usado para mostrar el orden en que las actividades serán ejecutadas en un proceso. El flujo de mensaje es usado para mostrar el flujo de mensajes entre dos participantes preparados para enviar y recibirlos. Una asociación es usada para asociar información con flujos de objetos.

Objeto de datos

Proveen información acerca de qué actividades requieren ser ejecutadas y/o que producen.

Anotación de texto

Son mecanismos para proveer información adicional al lector de un diagrama BPMN.

Grupo

Permite agrupar de actividades dentro de la misma categoría. Categorías pueden ser utilizadas para documentación y propósitos de análisis. Los grupos son una forma en la cual, las categorías de objetos pueden ser visualmente desplegadas.

Pool Un Pool representa un participante en el proceso.

Lane

Un Lane es una subpartición dentro de un Pool. Son utilizados para organizar y categorizar las actividades.

2.4.3.4.3. Framework i*. La técnica denominada “Framework i*”, fue propuesta en su tesis doctoral por Eric Yu [Alencar, 1999], [Yu, 1995] con el objeto de proveer una ontología más rica, capaz de describir no sólo, entidades, funciones, flujos de datos o estados de un sistema, sino que sea capaz de reconocer las motivaciones, intenciones o raciocinios sobre las características de un proceso, que permitan comprender el “porqué”, de los “qué” y los “cómo” (porqué tomar una decisión o realizar una determinada acción) [Yu, 1994] de la mayoría de los modelos de proceso, de manera tal de facilitar el desarrollo de las actividades propias de la Ingeniería de Requisitos. Es así que el Framework i*, presenta las siguientes características:

o Permite representar los actores organizacionales que toman parte de un proceso.

105

o Permite comprender las relaciones que se establecen entre los actores dentro de una organización, al posibilitar la representación explícita de las dependencias entre los diversos actores organizacionales.

o Permite entender las motivaciones y razones involucradas en los procesos decisionales.

o Permite ilustrar las diferentes características de modelado, que pueden ser convenientes para la Ingeniería de Requisitos, principalmente en la fase inicial de especificación de los requisitos.

o Permite construir una vista simplificada del proceso de negocio que se desea representar, mostrando a los actores, dependencias, recursos y las operaciones necesarias para lograr las metas de negocio definidas.

o Permite una representación gráfica con un reducido número de primitivas.

El Framework i*, está constituido por dos modelos: el modelo de dependencias estratégicas y el modelo de razones estratégicas, ambos modelos son complementarios y están conformados por un conjunto de actores primitivos, ligados por algún tipo de dependencia. El modelo de dependencias estratégicas ([Yu, 1996], [Yu, 1997]), modela las dependencias que existen entre los diferentes actores organizacionales que participan del proceso de negocio. Este modelo se representa a través de un grafo en el cual cada nodo identifica a un actor o agente y los arcos que los unen, indican las dependencias que existen entre ellos para alcanzar las metas definidas, ejecutar tareas y suministrar o solicitar recursos. Este conjunto de nodos y uniones forma una red de dependencias, que permite representar gráficamente las relaciones entre los actores. El modelo de razones estratégicas ([Yu, 1996], [Yu, 1997]), se utiliza para describir los intereses y motivaciones de los participantes, habilitar la valoración de posibles alternativas en la definición de procesos y especificar con un mayor nivel de detalle, las razones de la existencia de dependencias entre los diferentes actores. Este modelo extiende al modelo de dependencias estratégicas, incorporando dos tipos de constructores: means-end cuyo objetivo es representar las diversas alternativas que pueden tomarse para lograr una meta o tarea y task-descomposition que permite detallar el conjunto de actividades necesarias para lograr un objetivo. Respecto de los actores, ellos pueden ser de tres tipos [Yu, 1994], [Alencar, 2000].

(1) El actor dependiente denominado “depender”. (2) El actor del cual se depende, denominado “dependee”. (3) El objeto bajo el cual radica la relación de dependencia “dependum”.

En cuanto a las dependencias, se definen cuatro tipos de dependencias [Alencar, 1999].

(1) Dependencia de Recurso. En esta dependencia, se depende de cierta entidad física o informacional. Por recurso se entiende el producto final de alguna acción en un proceso que puede estar o no disponible.

(2) Dependencia de Tarea. En este tipo de dependencia, se depende de que un actor realice una tarea. Se prescribe la forma en cómo debe ser realizada.

(3) Dependencia de Meta. En esta relación de dependencia, un actor depende de otro para que una cierta meta definida sea realizada. No se prescribe la forma en cómo debe ser realizada.

106

(4) Dependencia de Meta Suave. Este tipo de dependencia es similar a la dependencia de meta, sin embargo en una dependencia de meta suave, la condición de aceptación no está definida previamente, es decir, las metas involucran aspectos subjetivos los cuales se van aclarando durante el desarrollo del proceso.

Las primitivas básicas que permiten construir los modelos de dependencias estratégicas y de razones estratégicas se ilustran en la figura 2.46.

Figura No. 2.46. Primitivas básicas del Framework i* (elaborado en base a [Yu, 2001]).

Finalmente, Eric Yu en su trabajo doctoral [Alencar, 1999], aplica la técnica propuesta en las siguientes cuatro áreas de desarrollo:

Ingeniería de Requisitos: Uno de los principales inconvenientes al elicitar requisitos, es la dificultad de comprender profundamente el dominio de aplicación. Con las motivaciones y razones explícitamente capturadas en un modelo de requisitos, se hace más simple entender los cambios en las necesidades de los usuarios. Reingeniería de procesos: De acuerdo a Yu, un principio central de la reingeniería, es la necesidad de preguntarse el “porque” de los hechos. Sin un claro entendimiento de las razones de prácticas y estructuras existentes, no se puede decidir fácilmente qué cambios pueden ser realizados en los procesos de negocios (los tipos predominantes de modelos son variaciones de diagramas de flujo de trabajo y actividades). Análisis de impactos organizacionales: Yu considera que los modelos convencionales utilizados para el desarrollo de sistemas, fueron primariamente proyectados para una descripción de sistemas técnicos y no para suministrar descripciones más ricas sobre las organizaciones socio-humanas. La técnica i*, fue concebida con la idea de considerar aspectos organizacionales, permitiendo que un

107

análisis organizacional, sea integrado a los procesos de desarrollo de sistemas de información. Modelado del proceso de software: Para alcanzar el éxito en el desarrollo de software de alta calidad, es importante tomar en cuenta no sólo las herramientas de soporte técnico, sino también, el ambiente organizacional. Un modelo de proceso de software que capture las motivaciones y razones involucradas en las actividades y flujos, facilitara el análisis sistemático de los procesos de software.

2.4.3.4.4. Comparación de Notaciones para la representación de Modelos de Negocio. Un resumen de las principales características de las notaciones graficas descritas se presenta en la tabla 2.5.

Tabla 2.5. Resumen de notaciones gráficas.

NOTACIÓN VENTAJAS DESVENTAJAS

UML

Es un lenguaje estándar de modelado gráfico simple. Su versión 2.0 incorpora primitivas adecuadas para la representación de modelos de negocio. Posee mecanismos de extensión estándar tales como los estereotipos, que permiten definirnuevos elementos para modelar negocios. Permite la identificación inmediata de las responsabilidades de los trabajadores del negocio.

La sintaxis no es claramente presentada. Ausencia de definiciones precisas. Generación de un elevado número de documentos. Orientado a los objetos y no a los negocios. Utilización de una reducida parte del lenguaje para el modelado de negocios.

BPMN

Riqueza semántica. Simplicidad de uso. Fácil de comprender. Mejora la comunicación entre todos los stakeholders.

Sólo es aplicable a los modelos de procesos de negocio.

Framework i*

Permite representar a los diversos actores organizacionales que participan de un proceso.Permite expresar en forma explícita las dependencias entre los actores organizacionales. Se entiende la racionalidad de las decisiones tomadas. Permite la representación de requisitos no funcionales. Permite contar con una vista simplificada del negocio, mostrando actores, dependencias, recursos, tareas, metas en una vista global del proceso de negocio.

Al existir una cantidad reducida de primitivas y en la medida que crece la cantidad de información a modelar, el entendimiento se dificulta.

Aparte de UML, BPMN y el Framework, también se han utilizado algunos otros lenguajes para modelar procesos de negocio, tal como el que se discute en

108

[Koubaraquis, 2002]. En este artículo, se presenta un modelo formal para representar el conocimiento de una empresa y sus procesos de negocio. Este modelo, se estructura sobre cuatro conceptos fundamentales de una organización: los objetivos y metas, los roles y actores, las acciones y procesos y las responsabilidades y restricciones. Estos conceptos deben permitir a un analista de negocios, capturar el conocimiento de una organización desde los objetivos definidos en los niveles más altos de la estructura jerárquica de la organización y producir especificaciones formales y detalladas de los procesos de negocio. Para estos efectos se utiliza un lenguaje formal, el cual más adelante debe permitir verificar el grado de correctitud de las especificaciones, en particular que las responsabilidades asignadas a los roles, se hayan ejecutado. El modelo propuesto consiste de cinco submodelos interconectados: (el submodelo organizacional, el de objetivos y metas, el de procesos, el de conceptos y el submodelo de restricciones), los que son utilizados para describir formalmente los diferentes aspectos de la organización. La representación de estos submodelos se apoya en el uso del lenguaje “ConGolog” que es un lenguaje de programación lógica concurrente y el uso una extensión del formalismo “Cálculo de situaciones”. Este formalismo ha sido especialmente diseñado para representar conocimiento en dominios de evolución dinámica. En un modelo formal de una organización, los conceptos están definidos en forma rigurosa y precisa, por lo tanto es posible el uso de las matemáticas para analizar el conocimiento extraído. Una ventaja de los modelos formales, es que ellos son auto-consistentes y tienen propiedades del proceso que pueden ser verificadas.

109

CAPÍTULO III

Planteamiento del Problema En este tercer capítulo, se realiza una descripción del problema que se desea resolver con el desarrollo de la presente tesis doctoral y posteriormente se definen los principales objetivos que deben ser logrados como resultado del trabajo desarrollado.

111

3.1. Planteamiento Cuando se toma la decisión de construir un edificio, un sistema de software, un vehículo o cualquier producto en general, descubrir las necesidades del cliente (requisitos) que deberá cubrir el nuevo producto antes de iniciar su construcción, es una cuestión de suma importancia. Sin embargo, esta afirmación que parece ser muy lógica y obvia, y que constituye una práctica habitual en diversas áreas, tales como la construcción (no se construye un edificio sin un plano), la industria automotriz [Weber, 2003], comercio electrónico [Gordijn, 2003], o data warehouse [Rilston, 2003] entre otras, es un aspecto que frecuentemente se soslaya en el desarrollo de software. En sistemas de Data Mining (DM) peor aún, no existe un procedimiento o metodología ad-hoc, que permita identificar, capturar, verificar y validar los correctos requisitos de una manera sistemática. A pesar de que la educción de requisitos, es una actividad necesaria y explicita, en el proceso de desarrollo de software, no necesariamente es considerada con la frecuencia y formalidad que amerita. Debbie Richards en [Richards, 2000] plantea que si bien, múltiples mejoras se han realizado en diversas actividades involucradas en el proceso de desarrollo de software, la captura, análisis y el modelado de los requisitos del usuario, son las actividades menos exploradas. Pero, ¿qué consecuencias ocasiona la omisión o una inadecuada definición de los requisitos?, según un estudio del Instituto Nacional de Estándares y Tecnología del Departamento de Comercio de los Estados Unidos [NoticiasDot, 2002], los errores y fallas imprevistas, costaban a la economía nacional (al momento del estudio), unos 59.500 millones de dólares al año. La investigación también permitió constatar, que más de la mitad de todos los errores, no se encuentran hasta que el proceso de desarrollo está en su fase final o durante el período de uso, luego de la comercialización del software. En [Robertson, 2005] se comenta que sus autores, gestionaron y participaron por más de un cuarto de siglo, en proyectos de software y también en muchos otros tipos de proyectos, incluyendo, arquitectura, investigación en misiles y organización de negocios, algunos exitosos y otros no. Un factor presente en cada proyecto exitoso y ausente en uno no exitoso, es la suficiente atención en los requisitos del proyecto. También se comenta que no importando el tipo de producto (electrónica, aviación, farmacéutica, gobierno, desarrollo de software, u otro) en todos ellos, se espera que los requisitos estén correctamente comprendidos antes de que el producto sea construido. Los requisitos constituyen el lazo de comunicación entre los clientes o mandantes y los desarrolladores del producto. ¿Qué ocurre en el área de Data Mining?, en la última década, una gran cantidad de proyectos de Data Mining han sido desarrollados. Un informe de Garntner Group en 1999 [Dilauro, 2000], [Menasalvas, 2004], pronosticaba un incremento de hasta un 300% en el número de proyectos de Data Mining para la presente década. Otro reporte más actualizado de Garntner Group [McDonald, 2006] [Marbán et al., 2008], informa un incremento entre los años 2005 y 2006 de un 4.8 % en el número de empresas en el área de Data Mining. En [Kantardzic, 2005], se menciona que en los últimos años, la tecnología de Data Mining ha migrado desde los laboratorios de investigación hacia las compañías de la lista “Fortune 500”. Sin embargo, la ejecución de este tipo de proyectos, ha debido enfrentar una serie de problemas, no todos los proyectos se concluyen con éxito; o sus resultados no son posteriormente utilizados [Marbán, 2007].

112

En [Kelley, 2003] aunque no se precisan cifras, se afirma que hay un número bastante alto de proyectos de Data Mining que fracasan. En [Gondar, 2005], [Marbán et al., 2008], se indica que la tasa de fracasos en el desarrollo de proyectos de Data Mining, es actualmente del orden del 60 %. Entre las principales causas determinadas que responden la pregunta, ¿por qué muchos de los proyectos de Data Mining, no concluyen con éxito?, están las relacionadas con la falta de procesos de desarrollo estandarizados que incorporen un enfoque ingenieril al desarrollo de proyectos de Data Mining [Marban et al., 2008] y aspectos relacionados con una inadecuada fase de especificación de requisitos. En [Kelley, 2003], se informa que la mayoría los factores que producen fracasos en proyectos de Data Warehouse, son también relevantes en proyectos de Data Mining, factores tales como: proyectos sobrepresupuestados, proyectos que no se desarrollan en los tiempos estimados, funciones y capacidades no implementadas en el proyecto, usuarios insatisfechos, desempeño del proyecto inaceptable, mala calidad de datos y reportes, uso complejo para el usuario, etc. Evidentemente, muchos de estos factores tienen directa relación con los procesos de descubrimiento y especificación de los requisitos de un proyecto. Considerando que los problemas mencionados en el desarrollo de proyectos de Data Mining no son nuevos, a lo largo de los últimos años, un conjunto de modelos de proceso de desarrollo de proyectos de Data Mining han sido propuestos o se han adaptado para el desarrollo de este tipo de proyectos, tales como CRISP-DM (Cross-Industry Standard Process for Data Mining) [CRISP-DM, 2000], SEMMA (Sample, Explore, Modify, Model, Assess) [SAS, 2003], DMAMC [Isixsigma, 2005] o las 5 A’s [Laudon, 2002]. Todos estos procesos o guías de desarrollo sin embargo, adolecen de métodos o técnicas que permitan educir adecuadamente los requisitos del proyecto. Más concretamente, aún no existe un proceso maduro que pueda calificarse como una metodología sólida, pues si bien por ejemplo, CRISP-DM, establece un conjunto de tareas y actividades que deben ser ejecutadas en el proyecto, no establece con qué técnicas o modelos se debe implementar cada actividad. Es por tanto, la primera fase del ciclo de vida de un proyecto de Data Mining, (independientemente del estándar o guía de desarrollo utilizada) una de las más importantes, pues del conocimiento y dominio del problema que se tenga en esta fase, dependerá el éxito o fracaso del proyecto. Esta fase, en el estándar CRISP-DM, corresponde a la fase de Comprensión del Negocio (o del problema) y consiste en una valoración de diferentes factores, tales como una comprensión del negocio, cuál es su misión, cuál es su visión, qué preguntas permitirá responder el proyecto y qué acciones se deben tomar sobre el negocio. Esto es, de qué manera el proyecto de Data Mining permite alcanzar los objetivos declarados del negocio o cuál es el objetivo del Data Mining. Dada por lo tanto la trascendencia para el desarrollo correcto de un proyecto de Data Mining, que esta fase representa, la finalidad del presente trabajo de tesis doctoral, es desarrollar una “metodología” para la construcción del Documento de Requisitos en proyectos de Data Mining. Un documento de requisitos, de acuerdo a Sawyer [Sawyer, 1997], es” una declaración oficial de los requisitos de un sistema, para los clientes, usuarios finales y desarrolladores del sistema”. En este punto, es importante destacar qué se entenderá por “metodología”. Su acepción, normalmente es función del campo de aplicación o área donde se emplea dicho término.

113

El Diccionario de la Real Academia de la Lengua Española [DRAE, 1995], la define como:

1. Ciencia del método.

2. Conjunto de métodos que se siguen en una investigación científica o en una exposición doctrinal.

En el campo de Ingeniería de Software, se encuentran las siguientes definiciones:

3. “Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software” [Piattini, 1996].

4. “Una metodología de ingeniería del software, es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas” [Rumbaugh et al., 1991].

Otras definiciones que se pueden citar son:

5. “El cuerpo de prácticas, procedimientos y reglas utilizadas por aquellos que trabajan en una disciplina o una investigación; Un conjunto de métodos de trabajo” [Houghton, 1992].

6. “La esencia de una metodología en forma opuesta a lo que ocurre con un método o técnica, es que ofrece un conjunto de pautas o principios que en cualquier instancia específica pueden ser ajustadas tanto a las características de la situación en la cual debe ser aplicada, como a las personas que usan el enfoque” [Checkland, 1989].

En este sentido y tomando en consideración fundamentalmente las últimas definiciones, la propuesta metodológica a desarrollar, incluirá un conjunto de modelos, métodos, técnicas y notaciones, que permitan construir eficientemente el “documento de requisitos” el que debe servir como base, para el desarrollo exitoso de un proyecto de Data Mining.

3.2. Hipótesis de trabajo

No existen estudios a nivel mundial, tendientes al establecimiento de una metodología para el desarrollo de proyectos de Data Mining.

Contar con una metodología, que sistematice y facilite el descubrimiento e

identificación de los requisitos para el desarrollo de un proyecto de Data Mining, a partir de la construcción de un modelo de negocios decisional, permitirá comprender de mejor manera el dominio de negocio y los problemas y necesidades organizacionales y como consecuencia, reducir el amplio espectro de causales de fracaso de este tipo de proyectos.

114

3.3. Objetivos del trabajo 3.3.1. Objetivo General.

Dada la gran importancia que adquiere, una correcta especificación de los requisitos, para el desarrollo eficaz de un proyecto de Data Mining, el objetivo general del presente trabajo de tesis doctoral, es desarrollar una metodología de apoyo, para la tarea de construcción del documento de requisitos, fase inicial del proceso de desarrollo de proyectos de Data Mining (DM).

3.3.2. Objetivos Específicos. El trabajo de tesis doctoral a desarrollar, se ha estructurado en un conjunto de objetivos específicos que se deben lograr. Los objetivos que se plantean, se listan a continuación:

Realizar una investigación sobre las diferentes técnicas que se aplican en las diferentes fases del proceso de Ingeniería de Requisitos.

Definir la, o las técnicas de Ingeniería de Requisitos a utilizar, o susceptibles de adaptación, para su uso en la fase de educción de requisitos en proyectos de Data Mining.

Establecer un procedimiento para definir un Modelo de Negocios Decisional.

Realizar un estudio las diferentes notaciones utilizadas para especificar un Documento de Requisitos.

Plantear una metodología (conjunto de técnicas y notaciones) para educir y representar requisitos en proyectos de Data Mining.

Ensayar la metodología propuesta en un caso de estudio real.

115

CAPÍTULO IV

Metodología para la Especificación de Requisitos en proyectos de Data Mining (ER-

DM)

En este capítulo, se propone una metodología para la especificación de requisitos en proyectos de Data Mining denominada “ER-DM” (Especificación de Requisitos en Data Mining). Aspectos importantes que se abordan inicialmente son, la descripción de la naturaleza y características propias de un proyecto de Data Mining y la identificación de los factores claves involucrados en un proceso de especificación de requisitos, los cuales sirven como marco para la definición de la metodología que se propone. A continuación se plantea la metodología ER-DM, se describen las diversas actividades y tareas que deben ser desarrolladas, los artefactos generados y las técnicas o métodos utilizados.

117

4.1. Introducción. La literatura sobre Gestión de Sistemas de Información [Maciaszek, 2005], está repleta de ejemplos de proyectos fracasados, inconclusos, excedidos en los plazos de desarrollo, o con costes superiores a los presupuestados. El caso de los sistemas de Data Mining ([Zornes, 2003], [Marbán, 2003]) no constituye la excepción, tal como se mencionó en el capítulo I del presente trabajo de tesis doctoral. Los principales factores identificados [Kelley, 2003], que pueden considerarse como factores característicos que originan fracasos en proyectos de Data Mining, son los relacionados con una inadecuada definición de los requisitos. En el actual escenario en que se desarrollan las diversas organizaciones, caracterizado por una elevada competitividad y continuos cambios, la capacidad de responder de una manera rápida y flexible al dinamismo de los mercados, constituye un desafío para el éxito o fracaso de cualquier organización. En este contexto, es de primordial importancia el desarrollo de eficientes sistemas de apoyo a la toma de decisiones, tanto estratégicas como operacionales, que garanticen el éxito y sobrevivencia del negocio. Los sistemas de Data Mining en la actualidad, se erigen como una poderosa tecnología de análisis de datos y extracción de conocimiento y juegan un rol indiscutido, como sistemas de apoyo a los procesos de toma de decisiones. Sin embargo históricamente, el principal foco de las investigaciones en Data Mining, ha estado centrado en el desarrollo de algoritmos y herramientas, sin considerar que para garantizar el éxito de un proyecto de Data Mining, complejo en su esencia, la atención no sólo debiera centrarse en el desarrollo de modelos y algoritmos, sino también en un enfoque metodológico que permita el desarrollo entre otros, de una definición y especificación sistemática y organizada de las necesidades estratégicas que deberá satisfacer el proyecto y las restricciones de confiabilidad inherente de los resultados. En este sentido, la integración de la Ingeniería de Requisitos con el proceso de desarrollo de proyectos de Data Mining, es considerada relevante para el desarrollo de la metodología denominada “ER-DM, Especificación de Requisitos en proyectos de Data Mining”, que se propone en la presente tesis doctoral. La Ingeniería de Requisitos, define y propone un conjunto de procedimientos y actividades, que permiten garantizar la elicitación y el correcto entendimiento de los requisitos tanto organizacionales, como de calidad para el desarrollo eficiente de un proyecto [Sommerville, 2005], [Kotonya, 1998], [Maciaszek, 2005]. El proceso de elicitación, no sólo involucra descubrir qué es lo que los clientes desean, sino también el análisis y entendimiento del dominio de aplicación y de negocios en el cual el sistema será utilizado [Kotonya, 1998]. Procesos de análisis y negociación, están fuertemente conectados con la elicitación de manera de establecer un acuerdo sobre un conjunto de requisitos completos y consistentes. Las principales dimensiones presentes en un proceso de especificación de requisitos (figura 4.1) [Kotonya, 1998] que se consideran en la propuesta metodológica son:

1) La comprensión del dominio de aplicación: Que establece, el conocimiento que se debe poseer sobre el área donde el sistema será aplicado.

118

2) El entendimiento del problema: Involucra la comprensión de los detalles del problema del cliente que el sistema deberá resolver.

3) La comprensión del negocio: Comprender de qué manera, el desarrollo del sistema afecta a los diversos componentes de negocio y su contribución hacia el logro de las metas organizacionales.

4) La comprensión de las necesidades de los Stakeholders: Los Stakeholders, se pueden definir como el conjunto de personas con intereses en el desarrollo del proyecto, o que son afectadas de alguna forma por el sistema y por lo tanto se deberán comprender sus necesidades especificas, particularmente los procesos que forman parte de su trabajo y que el sistema deberá apoyar.

Figura No. 4.1. Dimensiones del proceso de elicitación de requisitos ([Kotonya, 1998]).

La metodología ER-DM define un proceso iterativo e incremental, que a partir de un conjunto de requisitos organizacionales preliminares y un conjunto de elaboraciones sucesivas de desarrollo de modelos de prueba, deriva finalmente, en la versión final del documento de contrato. También la metodología considera, la definición de un conjunto de plantillas para la descripción de los requisitos organizacionales y del sistema a ser desarrollado. En las próximas secciones del presente capítulo, se presenta la metodología propuesta para la definición de los requisitos en proyectos de Data Mining, la cual está compuesta por un conjunto de etapas o fases que deben ser desarrolladas. Estas etapas, son aglutinadas en un framework, que presenta con un alto nivel de abstracción la metodología propuesta. Posteriormente se describen los procedimientos de desarrollo de cada una de las etapas y las plantillas que finalmente describen los requisitos descubiertos.

4.2. Descripción de la Metodología ER-DM. Habitualmente los proyectos de Data Mining, se desarrollan de acuerdo a una secuencia de fases, siguiendo alguna recomendación o modelo de desarrollo, como por ejemplo CRISP-DM [CRISP-DM, 2000], SEMMA [SAS, 2003], Seis Sigma [Isixsigma, 2005],

119

5 A’s [Laudon, 20022], u otro. Una de las primeras fases de CRISP-DM y común a ciertas recomendaciones, es la fase de comprensión del problema o dominio del negocio (figura 4.2), la que consta de un conjunto de actividades o tareas que deben ser realizadas para concretar la fase, entre estas tareas se encuentra, la tarea de descubrimiento de los requisitos del proyecto. Sin embargo, ni en CRISP-DM [CRISP-DM, 2000], ni en otras recomendaciones utilizadas, se especifica la forma de cómo desarrollar esta fundamental tarea.

Figura No. 4.2. Primera fase de la guía de desarrollo CRISP-DM ([CRISP-DM, 2000]).

En esta sección del trabajo de tesis desarrollado, se presenta una propuesta orientada a resolver la carencia de una metodología que permita descubrir y especificar con un alto grado de eficacia, los requisitos de un proyecto de Data Mining. El siguiente diagrama general (figura 4.3), presenta la metodología que se propone, expresada mediante un “framework”. Este framework (con un alto grado de abstracción), está compuesto por un conjunto de procesos destinados a proveer un procedimiento sistemático, organizado y plenamente integrado a las actividades propias de un proceso de Ingeniería de Requisitos, orientados al descubrimiento y especificación de los requisitos fundamentales del proyecto tales como por ejemplo: objetivos y necesidades de los usuarios, restricciones operacionales, roles involucrados, responsabilidades. El enfoque que se aborda en la metodología propuesta, está sustentado en la filosofía de desarrollo del Proceso Unificado (UP) [Kruchten, 1999], [Larman, 2003] y en el enfoque denominado TWIN PEAKS [Nuseibeh, 2001]. La idea más importante que se toma del Proceso Unificado (UP), se relaciona con el desarrollo iterativo e incremental. Bajo esta perspectiva, el proceso de descubrimiento de los requisitos, se desarrolla en una secuencia de fases que se dividen en, una fase de inicio, en la cual se define un conjunto de requisitos iniciales o aproximados del proyecto y posteriormente un conjunto iterativo de elaboraciones en las que se refinan

120

los requisitos iniciales, se identifican nuevos requisitos y se efectúan estimaciones más realistas en cuanto al alcance y riesgos presentes en el proyecto.

Funciona en el Marco de

Produce

MISIÓN

Descripción de la misión

METAS

Descripción de metas organizacionales y

objetivos asociados

REGLAS DE NEGOCIO

Especificación de políticas internas y

externas

PROPUESTA DE VALOR

Descripción de producto/servicio

MERCADO

Descripción de clientes y

características

RED DE VALOR

Descripción de la competencia , socios y

colaboradores

ESTRUCTURA ORGANIZACIONAL

Definición y descripción

Organigrama de la Organización

ORGANIZACIÓNNombre de la Organización

CAPACIDADES

Descripción de capacidades o competencias

ESTRUCTURA DE COSTOS

Descripción de costos asociados la creación y comercialización de

valor

GLOSARIO

Significado de términos en el

dominio de negocio

ESTRATEGIASDescripción de

Estrategias para cumplimiento de metas y objetivos

RECURSOS

Descripción de recursos humanos y

materiales

EVALUACION DEL NEGOCIO

Matriz FODA

RESTRICCIONES

Descripción de restricciones

RIESGOS

Descripción de Riesgos y plan de

contingencias

FCE

Descripción de Factores Críticos de

Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS

Descripción de beneficios que se

esperan lograr

Restringidaspor Generan

Figura No. 4.3. Framework para la especificación de Requisitos (elaboración propia).

En cuanto al enfoque TWIN PEAKS (figura 4.4), éste sugiere el desarrollo iterativo e incremental del conjunto de requisitos, concurrentemente con el desarrollo arquitectónico del sistema, fundamentado en tres principios identificados por Barry Boehm [Nuseibeh, 2001], [Boehm, 2000], denominados:

1) IKIWISI (I’ll Know It When I See It, lo sabré cuando lo vea): Este principio indica que los requisitos emergen, sólo después de que un desarrollo de prototipos del sistema tiene lugar y los usuarios tienen la oportunidad de proveer realimentación en base a la observación de los prototipos. Este principio es el que principalmente inspira la metodología propuesta.

Figura No. 4.4. Modelo TWIN PEAKS ([Nuseibeh, 2001]).

2) COTS (Commercial off-the-shelf, disponible comercialmente): El proceso de desarrollo de software, es actualmente conducido por un proceso de identificación y selección de sistemas de software existentes, tratando de hacer

121

calzar en lo posible los requisitos organizacionales con las funcionalidades de estos sistemas.

3) Rapid Change (rápidos cambios): Un problema en la gestión de los requisitos, dice relación con el continuo cambio de ellos. Una solución que se plantea, es la identificación de los requisitos fundamentales del sistema, los cuales representan las necesidades primordiales de los stakeholders y que probablemente sean persistentes en un largo periodo de tiempo.

De estos tres principios, se considera relevante para el desarrollo de la metodología, solamente el primero, por cuanto el objetivo de la metodología es proveer un procedimiento sistemático, para la construcción del documento de requisitos a partir del cual, se desarrolle el proyecto de Data Mining. No se considera la búsqueda de proyectos de Data Mining disponibles comercialmente, cuyos resultados se ajusten a las necesidades de conocimiento o información requerida para el logro de objetivos muy particulares de la organización, ni la fase de gestión de los requisitos posterior a la implantación del proyecto. La justificación para la adopción de estas ideas (UP y TWIN PEAKS), radica en el hecho de que en un proyecto de Data Mining, los requisitos al inicio del proyecto, son normalmente difusos e imprecisos y van mudando permanentemente a lo largo del desarrollo del proyecto. Un sistema de Data Mining en su esencia, es un sistema de apoyo al proceso de toma de decisiones y este proceso en sí, es un proceso no estructurado o a lo menos semiestructurado. A continuación se describen las fases constituyentes del framework. 4.2.1. Fase de comprensión del dominio de negocio. El dominio de negocio de una organización, es habitualmente bastante complejo y debería ser exactamente comprendido antes de iniciar el desarrollo de cualquier proyecto. De la comprensión de los objetivos y requisitos del proyecto, desde una perspectiva de negocio, empresarial o institucional, depende en gran medida el éxito de un proyecto de Data Mining. Por lo tanto el objetivo en esta fase, es definir un procedimiento para desarrollar la fase de comprensión del dominio de negocio (figura 4.5), que posibilite a los expertos de Data Mining, tener un mejor conocimiento de la organización y permita a su vez, consolidar los necesarios lazos de confianza entre los clientes y desarrolladores del proyecto, estableciendo una visión común de la organización. La guía de desarrollo CRISP-DM, propone entre otras, dos tareas fundamentales en la primera fase (comprensión del negocio) del ciclo de vida de un proyecto de Data Mining:

1) La determinación de los objetivos del negocio. Que tiene como meta, determinar desde la perspectiva de negocio, cuál o cuáles son los problemas que se desean resolver, qué es lo que el cliente espera obtener y cuáles son los factores que en primera instancia deben ser considerados para el desarrollo del proyecto.

2) La evaluación de la situación. Su objetivo, es el calificar el estado de la situación con un mayor nivel de detalle antes de iniciar el proyecto de Data

122

Mining, es decir, identificar recursos, supuestos y limitaciones, riesgos y contingencias y en general cualquier factor que sea relevante para el desarrollo del proyecto.

Contabilidad

Personal

Marketing

Inventario

Pagar a

$

Nómina

ORGANIZACIONES

Distribución

Sistemas de información

Fabricación

MODELO DE NEGOCIOS DECISIONAL

TÉCNICAS DE EDUCCIÓN DE

INFORMACIÓN Y CONOCIMIENTO TÉCNICAS DE

INGENIERÍA DEREQUISITOS

TÉCNICAS DE MODELADO

COMPRENSIÓNDOMINIO

DEL NEGOCIO


Produce

MISIÓN


METAS


objetivos asociados

REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR

Descripción de la competencia, socios y

colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


REQUISITOS ORGANIZACIONALES

Requisitos

TÉCNICAS DE EDUCCIÓN

Administración

Departamento jurídico

MODELO DE REQUISITOS

MODELOS DE PRUEBA

VERSIÓNFINAL

DOCUMENTODE

REQUISITOS

ACUERDOS

Figura No. 4.5. Fase de comprensión del dominio de negocio (elaboración propia).

Evidentemente el proceso de concreción de las tareas antes mencionadas, no es simple y CRISP-DM no sugiere ningún procedimiento metodológico orientado a la ejecución de este proceso. Al respecto en [Ochoa, 2006], se expresa que si bien las metodologías de desarrollo de sistemas de información, hacen mención a la fase de comprensión del dominio de negocio, ninguna de ellas explicita qué información debe ser elicitada para lograr dicha comprensión, ni las técnicas que deben ser adoptadas por el especialista, para abordar el problema. En [Sharma, 2009], producto de una amplia revisión de publicaciones de casos de estudio de Data Mining se afirma que, a menudo la fase de comprensión del dominio de negocio es desarrollada de una manera ad-hoc y se indica que casi ninguna publicación provee una descripción detallada, de cómo esta fase fue formalmente implementada. Reiterando la importancia que esta fase representa para el desarrollo de un proyecto de Data Mining, se presenta a continuación un procedimiento metodológico orientado a que los participantes del proyecto, tengan la mayor comprensión posible acerca de la organización para la cual se desarrollará el sistema de Data Mining. Recordemos inicialmente, qué se entiende por “organización”, de acuerdo a [Hodge, 1998] una organización puede definirse como “dos o más personas que colaboran dentro de unos límites bien definidos para alcanzar una meta común”, ampliando esta concepción inicial: “Las organizaciones son sistemas humanos de cooperación y coordinación integrados dentro de límites definidos con el fin de alcanzar metas compartidas”. En [Daft, 2005], se dice que las organizaciones son: 1) entidades sociales, 2) dirigidas a metas 3) diseñadas con una estructura deliberada y con sistemas de actividades coordinados y 4) vinculadas con el medio externo. Las organizaciones podrán ser de diferentes tipos, algunas pequeñas y locales, otras, grandes corporaciones multinacionales, algunas producirán manufacturas y otras proveerán de servicios. Sin embargo la importancia de las organizaciones [Daft, 2005]

123

radica en: las organizaciones atraen recursos para alcanzar metas específicas, producen bienes y servicios, las compañías buscan formas innovadoras de producir y distribuir bienes y servicios con mayor eficiencia (capacidades), utilizan fabricación moderna y tecnología basada en computadoras, se adaptan e influyen en un ambiente cambiante, crean valor para propietarios, clientes y empleados y acomodan los desafíos constantes de diversidad, ética, patrones de desarrollo profesional y motivación y coordinación de los empleados. En los párrafos anteriores, es posible identificar ciertas palabras claves tales como: metas, bienes y servicios, recursos, innovación, eficiencia, clientes, propietarios, empleados, términos que dan idea acerca de los componentes de una organización. Todos estos términos, es posible sintetizarlos en dos importantes conceptos que son la visión y la misión de una organización. Respondiendo a la crítica realizada al concepto de misión, entendida como un reflejo del funcionalismo estático de las organizaciones, la visión [Hellriegel, 2002] expresa las aspiraciones y el propósito fundamentales de una organización y apela por lo común, al corazón y razón de sus integrantes. Formular una visión infunde alma al planteamiento de la misión, si ésta no la tiene. En cuanto a la misión [Hellriegel, 2002], ésta es el propósito o razón de ser de una organización, su planteamiento suele responder preguntas básicas tales como 1) ¿en qué negocios participamos?, 2) ¿quiénes somos? y 3) ¿cuál es nuestra intención?. La misión puede describir a la organización en términos de las necesidades de clientes a satisfacer, los bienes o servicios que ofrece, o los mercados que atiende en la actualidad o que pretende servir en el futuro.

Figura No. 4.6. Información sobre el dominio del Negocio (elaboración propia).

El planteamiento de la misión, sólo tiene sentido como una fuerza unificadora que orienta las decisiones estratégicas y permite lograr los objetivos de largo plazo (estratégicos) de la organización. Los objetivos organizacionales (estratégicos) [Hellriegel, 2002], son los resultados (cualitativos o cuantitativos) que gerentes y otros participantes han elegido para lograr el crecimiento y supervivencia de la organización en el largo plazo, para lo cual sus integrantes deben actuar estratégicamente, entendiéndose por estrategias, los principales cursos de acción que se eligen e instrumentan para conseguir uno o más objetivos. En los niveles superiores de una organización, se definen, principios, valores, misión, visión, objetivos globales y proyectos estratégicos que en su conjunto, definen el estado actual de la organización y lo que se espera de ella en el mediano o largo plazo.

124

En resumen, para tener un mejor entendimiento de una organización (figura 4.6), es necesario responder las preguntas ¿Quiénes somos? y ¿dónde estamos hoy?, representada por la visión estática del negocio, ¿a dónde queremos llegar?, representada en las metas de largo plazo u objetivos estratégicos y ¿cómo podemos llegar?, representada por las estrategias, condicionadas por las restricciones (recursos, capacidades, etc.) que se observan en el horizonte de tiempo. De esta manera, el procedimiento de descubrimiento de la información relacionada con el dominio del negocio y que permite responder las preguntas antes planteadas, se propone descomponerlo en dos etapas:

1) En la primera, se pretende lograr recabar información que permita tener una visión del escenario actual en que se encuentra la empresa (visión estática del negocio) y lo que se espera de ella en el futuro, definida por sus objetivos estratégicos o de largo plazo. En esta primera etapa, se desarrollan actividades similares a las propuestas en la tarea “determinar los objetivos de negocio (background y objetivos de negocio)”, de la primera fase (comprensión del negocio) de CRISP-DM.

2) En la segunda etapa, se pretende educir información relativa a los factores que influyen o condicionan el logro de los objetivos planteados tales como recursos, requisitos, riesgos, restricciones, contingencias, etc., en forma análoga con algunas de las actividades establecidas en la tarea “valoración de la situación” de la primera fase (comprensión del negocio) de CRISP-DM. El logro de metas y objetivos organizacionales, define en sí el escenario futuro de la organización,

La propuesta que se presenta en consecuencia, se fundamenta en la identificación y descripción de los componentes fundamentales de una organización, expresados e identificados en los párrafos anteriores (objetivos organizacionales, estructura organizacional, productos/servicios, mercado, etc.), los propuestos en [Osterwalder, 2005], [Lagha, 2004] y los identificados en los estudios realizados en [Ochoa, 2006] producto de los cuales, es posible obtener y documentar la información relativa al dominio del negocio, con independencia del sistema de información a desarrollar, sea éste un sistema tradicional, uno basado en conocimiento o un sistema de explotación de información.

Listado elementos de información

Identificación de la información a

elicitar

Identificación de las fuentes de información

Aplicación de técnicas de educción y plantillas

Listado fuentes de información

Información requerida

PASOS

SALIDAS

Figura No. 4.7. Proceso orientado a elicitar información sobre el dominio del Negocio (elaboración propia).

El enfoque adoptado para educir la información requerida en ambas etapas, consiste de manera genérica en (figura 4.7):

125

1) La identificación de la información pertinente que debe ser elicitada.

2) La identificación de las fuentes de tal información.

3) La aplicación de técnicas de educción y uso de instrumentos (plantillas) para elicitar la información identificada.

4.2.1.1. Escenario actual del negocio (background) y objetivos estratégicos de la organización.

El escenario actual del negocio, representa una vista de la naturaleza y características de la organización que permanecerán estables a lo menos en el corto plazo y responde a las preguntas ¿Quiénes somos? y ¿Dónde estamos hoy?, a su vez, la obtención de los objetivos estratégicos de la organización, responde a la pregunta ¿A dónde deseamos llegar?. Considerando el procedimiento general representado mediante la figura 4.7, el primer paso a seguir para obtener la información que se precisa con el fin de lograr una vista del escenario actual y los objetivos de largo plazo de la organización, es definir la información que debe ser elicitada (elementos de información) y que formará parte del documento que represente tal visión. A continuación, se identifica y describe un conjunto de elementos que podrían ser considerados, en base a la identificación y descripción de los componentes fundamentales de una organización que son estables a lo menos en el corto plazo, expresados e identificados en [Daft, 2005], [Hodge, 1998], [Osterwalder, 2005], [Lagha, 2004] y [Ochoa, 2006]. Evidentemente los elementos organizacionales que se precisen elicitar, dependerán de cada tipo de organización en particular.

o Misión de la organización. La misión de una organización, es un breve enunciado que resume los principales propósitos estratégicos y los valores esenciales que deberán ser conocidos, comprendidos y compartidos por todos los integrantes de la organización.

o Estructura organizacional. La estructura organizacional, representa la forma en que una organización se organiza y el sistema de roles y funciones que cumplen los diferentes miembros de la organización con el propósito de alcanzar las metas u objetivos establecidos en los procesos de planificación. Es típicamente descrita por medio de un organigrama organizacional.

o Metas organizacionales. Las metas organizacionales están definidas en el plan estratégico de la organización y representan las situaciones deseadas que la organización pretende lograr en un periodo determinado. Cada meta u objetivo general, involucra uno o más objetivos estratégicos. Evidentemente la existencia de metas organizacionales, permite a los directivos de la organización contar con guías que les orienten la ruta por la que deben conducirse, en el proceso de toma de decisiones.

o Reglas de negocio. Es el conjunto de políticas y restricciones al amparo de las cuales funciona la organización.

o Productos y/o servicios. Se refiere a la descripción de los productos y/o servicios que oferta la compañía y por los cuales los clientes estarían dispuestos a pagar.

126

o Capacidades. Describe el rango de capacidades que posee la organización para crear el producto/servicio que oferta.

o Clientes objetivo. Esta información describe el segmento de clientes para los cuales la organización crea valor.

o Red de valor. La red de valor está constituida por la red de colaboradores, socios y competidores. Esta red puede ser particularmente crítica para determinado producto o servicio. Cuando un producto/servicio es independiente de la presencia de otros productos o actores, se debe considerar sólo la existencia de la red de proveedores, canales de distribución y medios de cobranza.

o Infraestructura. Capacidad instalada que posee la organización para crear el producto/servicio que oferta.

o Estructura de costes. La estructura de costes, define todos los gastos en que incurre la organización para la creación del producto/servicio y su comercialización.

o Glosario. El glosario, es el conjunto de términos, palabras, tecnicismos, etc., de uso cotidiano en el dominio de negocio de la organización.

El siguiente paso del proceso (figura 4.7), lo constituye la identificación de las fuentes de información, de las cuales se debe extraer la información requerida. Las fuentes de información podrán ser tanto materiales, (documentos, manuales de procedimientos, sistemas de información, etc.), como humanas (directivos, gerentes, supervisores, expertos de negocio y en general personal relacionado a los diferentes niveles de la organización tanto interno como externo si es preciso). La tabla 4.1 presenta una plantilla destinada a especificar las fuentes de información a utilizar en el proceso.

Tabla 4.1. Fuentes de Información

Fuentes de información

Tipo de Fuente

Características

Información

Describe el tipo de fuente de información,

directivos, especialistas, documentos, otros.

Descripción de las

características del tipo de fuente de información y

ubicación.

Descripción del tipo

información que contiene la fuente identificada.

Posteriormente y como tercer paso del proceso (figura 4.7), se inicia el proceso de elicitación de la información ya descrita, mediante la aplicación de técnicas de educción de información y conocimientos, e instrumentos tales como plantillas que permitan representar de manera organizada la información elicitada. Las técnicas seleccionadas para elicitar la información que se precisa, se eligen fundamentalmente de acuerdo a la naturaleza, características y fuentes de origen de los diferentes elementos organizacionales. Básicamente los elementos de información

127

identificados, podrían provenir de fuentes heterogéneas tales como, fuentes documentales, expertos de negocio y administradores, grupos de personas (funcionarios de los diversos niveles de la organización) o como resultado de la observación in situ. En fuentes documentales tales como, estatutos, manuales de procedimientos, portales web institucionales, legislación vigente, planes de desarrollo, planes estratégicos, etc., se pueden descubrir elementos de información como por ejemplo, la misión, la estructura organizacional, las reglas de negocio o la red de valor, en cuyos casos se podrá utilizar la técnica de estudio de documentación existente. Otros elementos pueden provenir de fuentes documentales, de personas (singulares) o grupos de personas, como por ejemplo, el mercado, la red de valor, productos/servicios, o capacidades, por tanto en estos casos podrán utilizarse técnicas de educción tales como, estudio de documentos existentes, entrevistas, encuestas o reuniones grupales (Focus Group, JAD, WorkShop), otros tipos de información tales como por ejemplo, infraestructura, o glosario de términos pueden obtenerse directamente mediante el estudio de documentos, observación in situ, o reuniones grupales. Considerando cada elemento de información individualmente a modo de ejemplo se propone el uso de las siguientes técnicas de elicitación:

o Misión: La misión de una organización se encuentra típicamente documentada ya sea en la página web institucional, documentos de constitución, declarativos, etc., por tanto debería ser suficiente con remitirse al estudio de documentos existentes. Si no estuviese declarada, podrá ser elicitada mediante entrevistas a los directivos de la organización.

o Estructura organizacional: La estructura organizacional generalmente se

encuentra documentada y es de conocimiento público de los integrantes de la organización, por tanto bastara con remitirse a la lectura de documentos existentes.

o Metas organizacionales: Este elemento de información normalmente se encuentra documentado en los planes estratégicos de la organización, en los planes de desarrollo o al menos es de conocimiento en los más altos niveles jerárquicos de la organización, por lo tanto es posible remitirse al estudio de documentación existente, o entrevistas y/o reuniones de trabajo con los niveles directivos.

o Reglas de negocio: Las reglas de negocio, deben estar declaradas en los documentos internos (manuales de procedimientos) y en documentos externos (legislación vigente), por tanto es posible obtener esta información mediante la lectura de documentos o en su defecto mediante entrevistas o cuestionaros (en función de la disponibilidad de tiempo) a los responsables de los diferentes niveles de la organización según corresponda.

La tabla 4.2 muestra, una propuesta resumen de las técnicas a utilizar para educir la información considerada en la visión estática del negocio y objetivos estratégicos o de largo plazo.

128

Tabla 4.2. Técnicas de educción para obtener información respecto de la visión del escenario actual de la organización.

TECNICAS

INFORMACION

Entr

evis

tas

Encu

esta

s/C

uest

iona

rios

Doc

umen

tos E

xist

ente

s

Focu

s Gro

up

JAD

Obs

erva

ción

In S

itu

Wor

kSho

p

Misión X X Estructura Organizacional X X Metas Organizacionales X X X X X Reglas de Negocio X X X Propuesta de valor X X X X X Capacidades X X X X Mercado X X X X Red de valor X X X X X Infraestructura X X X Estructura de costos X X Glosario de términos X X X X

Evidentemente la decisión sobre qué técnica debe ser utilizada y en qué fase del proceso de elicitación de conocimientos, necesidades o requisitos, es función de muchos factores, tales como el tipo de información que debe ser elicitada, su naturaleza, origen, recursos disponibles y evidentemente el tiempo del cual se dispone para este propósito. Por tanto se puede afirmar, que no existe una recomendación única sobre qué técnicas deben ser utilizadas para determinados propósitos. Normalmente el tiempo de que disponen los diversos miembros de una organización para dedicarlo a reuniones grupales o entrevistas es muy escaso, sobre todo si no existe un real compromiso de los ejecutivos de la organización con el desarrollo del proyecto, en cuyo caso las técnicas de estudio de documentación existente, observación in situ, entrevistas o cuestionarios adquieren mayor relevancia frente a otras. La tabla 4.3 representa la plantilla propuesta para documentar la información pertinente a la visión estática del negocio o visión del escenario actual de la organización.

Tabla 4.3. Información sobre el escenario actual y metas de la organización.

Escenario Actual y metas de la organización.

Nombre

Consigna el nombre de la organización

Misión

Descripción de la misión de la organización

Estructura Organizacional Especificación de la estructura organizacional de la empresa.

129

Escenario Actual y metas de la organización.

Metas Organizacionales

Metas Objetivos asociados Descripción de la meta Descripción de los objetivos asociados

Reglas de negocio

Internas Externas Especificación de las políticas internas que definen el marco de funcionamiento de la

organización.

Especificación de las políticas externas que regulan el funcionamiento de la organización.

Propuesta de Valor

Producto o Servicio Características Justificación Descripción per se del producto. Funcionalidades

y cualidades del producto.

Descripción del problema resuelto para el cliente.

Mercado

Clientes objetivo Perfil y conducta Descripción del segmento especifico de clientes

para los cuales la empresa crea valor. Descripción de los gustos, preferencias y

conductas de los clientes.

Infraestructura

Capacidad instalada que posee la organización para crear el producto/servicio que oferta.

Red de valor

Nombre de la organización

Rol

Tarea desarrollada Producto

Consigna el nombre de la organización

Define el rol desempeñado (socio,

colaborador, competencia)

Describe la tarea desarrollada

Describe el producto y sus características

Estructura de Costes

Describe los costes en que incurre la organización para crear, comercializar y entregar valor a sus

clientes. Glosario de Términos

Término Significado

Nombre del término utilizado en el ámbito del dominio de negocio

Descripción de la semántica del término

4.2.1.2. Estrategias, recursos y factores condicionantes.

Recordando que las metas organizacionales u objetivos estratégicos son ([Hodge, 1998]), formulaciones que establecen el estado futuro deseado que intenta conseguir una organización y que las organizaciones [Hodge, 1998], son grupos de individuos que se unen para alcanzar dichas metas, es necesario también establecer las acciones que son necesarias para alcanzar el mencionado estado futuro deseado (cumplimiento de las metas). Estas acciones definen en sí, la o las estrategias de la organización.

130

Cuando se definen o establecen las estrategias (cursos de acción para alcanzar las metas), es necesario considerar también que los cursos de acción definidos, estarán condicionados por un conjunto de restricciones (recursos, capacidades, etc.). En este sentido la estrategia es una relación causa efecto, es decir indica qué es lo que la organización quiere lograr y los factores que influirán en que se logre o no lo propuesto. En [Steiner, 20003] se menciona que “la esencia de la planificación estratégica, consiste en la identificación sistemática de las oportunidades y peligros que surgen, los cuales combinados con otros datos importantes, proporcionan la base para que una empresa tome las mejores decisiones….esto significa diseñar el futuro deseado e identificar las formas para lograrlo”. Por lo tanto en esta segunda etapa, se busca identificar y especificar las estrategias establecidas para alcanzar las metas y objetivos definidos por la organización y los elementos que las condicionan (recursos humanos y materiales, capacidades, factores condicionantes). El proceso de construcción de este segundo artefacto, de acuerdo al procedimiento general definido en la figura 4.7, se inicia con la definición de la información que debe elicitarse y que será parte constituyente de este documento. Esta información se define, considerando lo ya expresado en los párrafos anteriores y los conceptos y componentes identificados en [Daft, 2005], [Hodge, 1998], [Hellregiel, 2002], [Osterwalder, 2005], [Lagha, 2004] y [Ochoa, 2006].

o Estrategias. Para el logro de las metas planteadas, los directivos definen las estrategias o conjunto de actividades necesarias que deberán facilitar el cumplimiento efectivo de ellas. En [Porter, 1997], se definen por ejemplo, tres tipos de estrategias genéricas las cuales conviene tomar en cuenta, pues proporcionan un mayor grado de entendimiento acerca de la forma de alcanzar los objetivos definidos, ellas son:

1) Liderazgo en costes. Esta estrategia, consiste básicamente en mantener costes más bajos de producción respecto de los competidores para de esta forma, lograr un mayor volumen de ventas.

2) Diferenciación. La estrategia de diferenciación, tiene por finalidad crear valor agregado en el producto/servicio, mediante la utilización de tecnologías innovadoras.

3) Enfoque. Estrategia consistente en la especialización o concentración de la satisfacción de necesidades, de un segmento específico del mercado.

o Recursos humanos. Identificación de las personas cuya participación se considera necesaria para dar cumplimiento a las metas y objetivos de la organización y más concretamente, de los profesionales y especialistas que participaran directa o indirectamente en la concreción de dichas metas.

o Recursos materiales. Considera la definición de la infraestructura de apoyo para el cumplimiento de las metas y objetivos organizacionales, tanto a nivel de instalaciones, como de equipamiento hardware y software.

o Factores condicionantes. Los factores condicionantes, constituyen los elementos internos o externos que influyen favorable o desfavorablemente en la implantación de las estrategias definidas.

131

o Evaluación interna del negocio. Esta evaluación tiene por finalidad determinar la posición competitiva del negocio en relación a sus competidores, es decir persigue identificar las fortalezas y debilidades de la organización respecto de la competencia.

o Evaluación externa del negocio. La evaluación externa del negocio, tiene por meta identificar las oportunidades y amenazas que proporciona el medio en que se desarrolla la organización.

o Restricciones. Se considera el conjunto de restricciones de diversa naturaleza, de tiempo y espacio, técnicas y económicas que afectan adversamente el logro de las metas y objetivos planteados.

o Riesgos. Consiste en la identificación de los probables eventos y su frecuencia de ocurrencia, que puedan afectar adversamente al desarrollo del proyecto, vinculados tanto a factores humanos como a factores técnicos y económicos y las posibles líneas de acción a considerar en su gestión.

o Expectativas. Considera la identificación y descripción de las expectativas generadas por el desarrollo del proyecto. Un acuerdo entre clientes, usuarios y desarrolladores es de vital importancia al inicio del proyecto. El acuerdo debe considerar elementos tales como el alcance, el producto, riesgos, restricciones, costes y periodo de desarrollo.

o Factores críticos de éxito (FCE). Los factores de éxito [Ochoa, 2006], son eventos que deben producirse o no, para alcanzar un objetivo, estos factores presentan la categoría de críticos si ellos son absolutamente necesarios para conseguir o alcanzar los objetivos de la organización. Otra definición se encuentra en [Li, 2005] que indica que factores críticos de éxito son las funciones, componentes o áreas de negocio de las cuales la empresa no puede prescindir, si desea asegurar competitividad. Es por tanto imprescindible el identificar este tipo de factores con el propósito de asignarles los recursos necesarios que permitan la consecución de tales factores de éxito.

Tabla 4.4. Fuentes de Información


Tipo de Fuente

Características

Información

Describe el tipo de fuente de

información, directivos, especialistas, documentos, otros.

Descripción de las características del tipo de fuente de información y su

ubicación.

Descripción del tipo de información que

contiene la fuente identificada.

Una vez identificada la información que debe ser elicitada y continuando con el procedimiento general establecido (figura 4.7), se procede a la identificación de las fuentes de las cuales extraer la información a ser elicitada (tabla 4.4). Evidentemente dichas fuentes, la constituyen principalmente los profesionales involucrados con el desarrollo del proyecto, ya sea directa o indirectamente y también los materiales tanto

132

escritos como audiovisuales. Finalmente se procede con el tercer y último paso del procedimiento definido en la figura 4.7, es decir se procede a aplicar las técnicas de educción (tabla 4.5) e instrumentos (plantillas) (tabla 4.6) para elicitar la información correspondiente, que permita construir este segundo documento o artefacto.

Respecto de las técnicas de educción a utilizar en esta segunda etapa, se agregan a las ya propuestas en la primera etapa (escenario actual y metas de la organización), algunas otras técnicas ad-hoc que son típicamente utilizadas para extraer determinada información, por ejemplo, el análisis FODA (Fortalezas, Oportunidades, Debilidades, Amenazas) [Daft, 2005], para realizar la evaluación interna y externa del negocio, o el análisis de factores críticos de éxito, para determinar los factores críticos de éxito [Ochoa, 2006], [Li, 2005]. Sin embargo no son las únicas técnicas a utilizar para descubrir estos elementos de información. Por ejemplo, los resultados de los análisis FODA, normalmente están documentados y por tanto se puede recurrir a documentación existente o se pueden educir con técnicas grupales tales como Focus Group, o un Workshop. Respecto de los otros elementos de información, tales como estrategias, o recursos, es posible obtenerlos mediante ya sean, entrevistas, análisis de documentos existentes (normalmente las estrategias están documentadas en los planes estratégicos) o reuniones grupales. La tabla 4.5 resume la propuesta de técnicas de educción a utilizar, para el relevamiento de la información que se precisa.

Tabla 4.5. Técnicas de educción para relevamiento de la información sobre las estrategias, recursos y factores condicionantes.

TÉCNICAS

INFORMACIÓN

Anál

isis

de

FCE

Anál

isis

de

FOD

A

Anál

isis

de

Ries

gos

Entr

evis

tas

Doc

umen

tos

Exis

tent

es

Focu

s Gro

up

JAD

Wor

kSho

p

Estrategias X X X X X Recursos Humanos X X X Recursos Materiales X X X Evaluación Interna del Negocio X X X X X Evaluación Externa del Negocio X X X X X Restricciones X X X X Riesgos X X X X Factores Críticos de Éxito X X X X Expectativas X X X

En la tabla 4.6, se presenta una plantilla, que puede ser utilizada para orientar y especificar la información a educir.

133

Tabla 4.6. Relevamiento de la Información sobre las estrategias, recursos y factores condicionantes.

Estrategias, recursos y factores condicionantes.

Nombre Consigna el nombre de la organización Estrategias

Meta Objetivo asociado Estrategia

Descripción de la meta. Descripción del objetivo asociado a la meta descrita.

Descripción de la estrategia propuesta y asociada al

objetivo señalado. Recursos Humanos

Especialidad Función asignada Tiempo asignado

Descripción del nivel de especialización y rol en el

equipo de proyecto.

Descripción de las funciones que asumirá en el desarrollo del

proyecto.

Tiempo que podrá dedicar al proyecto.

Recursos Materiales

Hardware Software Descripción de los recursos de hardware

asignados para el proyecto. Descripción de los recursos de software

asignados para el proyecto. Evaluación Interna del Negocio

Fortalezas Debilidades

Descripción de fortalezas Descripción de debilidades Evaluación Externa del Negocio

Oportunidades Amenazas

Descripción oportunidades

Descripción amenazas

Restricciones

Objetivo afectado Restricción Curso de Acción Descripción de objetivo afectado por restricción.

Descripción de restricciones que afectan adversamente al desarrollo del proyecto.

Descripción de acciones tendientes a minimizar efectos

adversos producidos por la restricción descrita.

Riesgos

Objetivo afectado Riesgo Plan de contingencia Describe objetivo afectado

por riesgo. Descripción de riesgos que

afectan adversamente a objetivo descrito.

Descripción de plan de contingencia orientado a

minimizar efectos del riesgo descrito.

Factores Críticos de Éxito

Objetivo afectado Factor Crítico de Éxito Descripción de objetivo afectado.

Descripción de función, componente o área que

constituye factor crítico de éxito

Expectativas Descripción de las expectativas de la

134

Estrategias, recursos y factores condicionantes.

organización respecto del desarrollo y aportes del proyecto

4.2.2. Fase de definición de requisitos organizacionales preliminares.

La identificación de los requisitos organizacionales o de negocio (figura 4.8) que pareciera ser una tarea trivial y que en muchas ocasiones se soslaya o se omite, es probablemente una de las actividades de mayor relevancia en el desarrollo de un proyecto. Una inadecuada definición de tales requisitos, puede derivar en el desarrollo de un sistema que no resuelva los reales problemas de la organización que dan origen al proyecto. Por el contrario, un buen entendimiento y acuerdo respecto de las necesidades de la organización, conducirán al desarrollo de una solución efectiva.

En consecuencia, el objetivo de la presente fase, es la identificación y descripción con el mayor nivel de detalle posible, de los principales requisitos organizacionales que darán origen al desarrollo del proyecto de Data Mining y que permitirán establecer una visión común con los usuarios del futuro sistema, respecto de los objetivos fundamentales del proyecto.


Produce

MISIÓN


METAS


objetivos asociados

REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 4.8. Definición de requisitos organizacionales (elaboración propia).

Una adecuada comprensión de los requisitos organizacionales o necesidades del negocio, permitirá al equipo encargado del desarrollo del proyecto, establecer más adelante la especificación funcional que debe conducir al diseño del sistema de Data Mining. Otros aspectos de relevancia que se abordarán en esta fase son, el establecimiento de los acuerdos iniciales en cuanto a las expectativas generadas y el alcance del proyecto y la definición y conformación de los equipos responsables de las actividades propias del proceso de Ingeniería de Requisitos y del desarrollo del proyecto de Data Mining. Probablemente durante el desarrollo de los modelos preliminares de Data Mining, los requisitos inicialmente definidos presenten algunas modificaciones antes de llegar a un

135

acuerdo de conformidad, por lo cual es importante también establecer en esta fase, los correspondientes acuerdos para el tratamiento de cambios en los requisitos. Antes de dar inicio al desarrollo de esta fase, es conveniente aclarar, qué se entiende por requisitos organizacionales. En [Alencar, 1999], se encuentra la siguiente definición, “Los requisitos organizacionales dicen relación respecto de las metas de la empresa, sus políticas estratégicas adoptadas, los empleados de la empresa con sus respectivos objetivos y en fin toda la estructura de la organización”. En el presente trabajo de tesis, se entenderá por requisitos organizacionales, a los objetivos, requisitos o problemas que tienen su origen o se derivan como consecuencia de las metas estratégicas establecidas en toda organización y que son posibles de abordar mediante un sistema de Data Mining. Para el desarrollo de esta fase, se propone una secuencia de pasos o actividades (figura 4.9) de cuya ejecución se obtiene como documentos de salida:

a) Un listado de los diversos actores que participaran del proyecto.

b) El listado de requisitos organizacionales preliminares o de alto nivel.

c) Un acuerdo respecto del alcance del proyecto (visión del Data Mining)

d) El glosario de términos de negocio y de Data Mining.

Listado equipo de proyecto

Definición de los actores

participantes en el proyecto

Preparación para el proceso de elicitación de

requisitos

Educción de Requisitos

Organizacionales

Definición del alcance del

proyecto

Glosario de términos del

proyecto

Listado de Requisitos Organizacionales

Documento de acuerdos

Listado de términos

PASOS

SALIDAS

Figura No. 4.9. Actividades presentes en la fase de definición de Requisitos Organizacionales (elaboración propia).

Paso 1. Definición de los actores participantes en el proyecto. La primera actividad en el desarrollo de la presente fase, consiste en la identificación de todos los actores involucrados en el desarrollo del proyecto. Los proyectos de Data Mining, se caracterizan por ser multidisciplinarios y por lo tanto es posible distinguir diferentes roles y responsabilidades dentro del mismo. Tomando como base los roles definidos en [Marban, 2003], el siguiente listado, constituye una propuesta muy general de los roles que deben ser considerados para el desarrollo de un proyecto de Data Mining. Evidentemente el número de integrantes en cada rol y las tareas a ejecutar pueden variar en función del tamaño del proyecto y de los recursos con que cuenta cada organización.

o Patrocinador: Es el representante de la dirección de la organización y/o la dirección de la unidad o departamento para la cual se desarrolla el proyecto y tiene como función principal, coordinar que los recursos organizacionales requeridos por los

136

ejecutantes del proyecto, estén disponibles de acuerdo al plan de trabajo propuesto. También es misión de la dirección de la unidad o departamento, decidir sobre qué datos se pueden suministrar, sin que la información involucrada invada la privacidad o seguridad de la organización y sus componentes. Finalmente es misión de la dirección de la unidad, la implantación de los resultados derivados del proyecto.

o Tomador de decisiones: Tiene como función dentro del equipo, proveer la información necesaria para modelar los procesos de toma de decisiones relativos al proyecto, validar los modelos planteados y la interpretación y validación de los resultados del proyecto.

o Usuarios finales de Sistema: Son los usuarios del conocimiento extraído por el proyecto, típicamente directivos de la organización sin conocimiento de Data Mining, por lo tanto el equipo de Data Mining, deberá considerar la presentación de los resultados de una forma fácilmente interpretable. Tienen además como función proveer la información requerida, para establecer las necesidades a ser satisfechas por los resultados del proyecto y las restricciones y condiciones de aceptabilidad de los mismos.

o Ingeniero de Requisitos: Tiene como responsabilidades, preparar y coordinar todas las tareas involucradas con el proceso de captura de los requisitos organizacionales y la ejecución de las actividades propias del proceso de Ingeniaría de Requisitos.

o Experto(s) en el dominio del negocio: Tiene(n) a cargo, en coordinación con los clientes, usuarios, tomadores de decisión e ingenieros de requisitos, la conducción del proceso de captura de requisitos de negocios. Asesora(n) en la decisión acerca de qué datos deben ser utilizados en el proyecto, participa(n) en la ejecución de las actividades propias del proceso de Ingeniería de Requisitos, principalmente en las fases de validación de los modelos creados y en la preparación de los modelos de negocio.

o Administrador de Bases de Datos: El o los profesionales responsables de la administración, manutención, análisis y gestión de las bases de datos de acuerdo a las políticas y procedimientos definidos por la organización.

o Modelador de negocios y datos: Es el responsable del entendimiento del negocio y la validez de los modelos del mismo, conciliando los requisitos organizacionales identificados con los modelos de procesos de negocio y de datos de la organización.

o Equipo de desarrollo del proyecto: El cual debe considerar a un jefe de proyecto, responsable de todas las actividades relacionadas con la gestión del proyecto y un número determinado de Data Miners, profesionales que tienen a cargo la responsabilidad de planificar y ejecutar el proyecto. La composición de este equipo es de naturaleza multidisciplinaria y puede estar conformada por informáticos, estadísticos, expertos en datos, matemáticos y en general en lo posible, personal que ya haya participado anteriormente en otros proyectos de Data Mining.

La tabla 4.7 presenta la plantilla que se sugiere utilizar, para documentar los resultados de esta primera actividad.

Paso 2. Preparación para el proceso de elicitación de requisitos.

Considerando que en el desarrollo del proyecto participará personal con diferentes roles y formación y/o especialización heterogénea, esto es, profesionales representantes de la

137

organización, expertos de negocio y profesionales expertos en Data Mining, esta actividad tiene como meta principal, homogenizar el nivel de conocimientos en las diferentes áreas de conocimiento involucradas para el desarrollo del proyecto como por ejemplo, conceptos de Data Mining, dominio del negocio, gestión de bases de datos, técnicas de educción, etc. Un conocimiento común del equipo de trabajo en las diferentes áreas de conocimiento involucradas en el desarrollo del proyecto, garantizará un eficiente análisis de los requisitos organizacionales y el logro de acuerdos respecto del alcance del proyecto (visión de Data Mining), evolución de los requisitos y provisión de recursos. Otros aspectos que podrían considerarse en la preparación para el proceso de captura de requisitos, se relacionan con establecer un acuerdo respecto de los roles y dedicación al proceso de identificación y especificación de requisitos, la definición de los recursos necesarios y la creación de un repositorio de documentos.

Tabla 4.7. Plantilla para definición del equipo participante en el proyecto.

Equipo participante en el proyecto

Nombre de la Organización

Consigna el nombre de la organización para la cual se desarrolla el proyecto.

Nombre del Proyecto

Consigna el nombre del proyecto a desarrollar.

Fecha de elaboración del documento

Consigna la fecha de elaboración del documento.

Listado de participantes

Nombre Rol Responsabilidades Nombre del participante. Rol o Función a cumplir en el

desarrollo del proyecto. Especificación de las responsabilidades asociadas a la función desempeñada.

Paso 3. Educción de requisitos organizacionales.

Esta es una de las actividades de mayor trascendencia en el desarrollo de un proyecto de Data Mining, por cuanto los requisitos o necesidades organizacionales que dan origen a un proyecto de Data Mining, constituyen la base para los posteriores procesos de derivación de requisitos técnicos, el diseño, el desarrollo y la validación de los modelos de Data Mining, es decir son la base para posteriormente contrastar si la información descubierta a través de los modelos de Data Mining desarrollados, resuelve o permite apoyar los procesos de toma de decisiones de la organización. La calidad de los requisitos elicitados, es función de una apropiada comprensión del dominio de negocio (primera fase de la metodología propuesta en este trabajo de tesis), la correcta aplicación de técnicas de educción ad-hoc al propósito señalado y una adecuada comunicación y colaboración entre los integrantes del equipo de desarrollo del proyecto. A continuación se propone una plantilla (tabla 4.8), que tiene como objetivo, guiar en el proceso de elicitación de los objetivos organizacionales o de negocio. La educción de esta información, es ejecutada aplicando las técnicas que se resumen en la tabla 4.11.

138

Tabla 4.8. Plantilla para educción de requisitos organizacionales.

Definición de Requerimientos Organizacionales



Nombre del Proyecto


Nombre del Jefe de Proyecto

Nombre y cargo del jefe de proyecto.

Equipo participante en el proceso de educción de requisitos.

Nombre de los miembros del equipo participantes en la definición de los requisitos organizacionales y rol desempeñado por cada integrante.



Unidad(s) mandante(s) del proyecto

Unidad de Negocio Usuarios Descripción de la unidad de negocio mandante del proyecto y principales responsabilidades.

Consigna nombre y funciones que desempeñan los usuarios del proyecto.

Requisitos organizacionales asociados a la unidad mandante

Requisitos organizacionales generales Descripción de el, o los requisitos de más alto nivel que el sistema de Data Mining debe satisfacer.

Requisitos organizacionales específicos Descripción de requisitos específicos y priorizados que el sistema debe satisfacer para cada usuario o grupos de usuarios de la información provista por el sistema de Data Mining.

Información adicional Descripción detallada del escenario en el cual se lleva a efecto el proceso de educción, reuniones realizadas, entrevistas, participantes, documentos preliminares, infraestructura y herramientas utilizadas, periodos de tiempo empleados, etc.

Paso 4. Definición del alcance del proyecto. Esta actividad tiene como meta, determinar el alcance del proyecto. Para este propósito, es requisito que las necesidades y metas de la organización estén plenamente identificadas y comprendidas. La idea es definir con claridad, la visión de alto nivel que tiene el cliente, respecto de la solución del problema que el desarrollo de un sistema de Data Mining representa, este acuerdo en el futuro, debe contribuir al proceso de validación de los resultados del proyecto. Otro aspecto a considerar en esta actividad, se refiere a los acuerdos que deben ser establecidos, respecto de las probables modificaciones en los requisitos que se produzcan a lo largo del proceso de definición de requisitos y del desarrollo del

139

proyecto (número de iteraciones en el proceso de validación). La definición de criterios y reglas claras, es importante para llegar de manera eficaz y eficiente a una pronta conformidad de los requisitos. La plantilla descrita en la tabla 4.9, representa una propuesta sobre la estructura del documento sobre la definición del alcance del proyecto y la información que éste debe contener. La educción de esta información, es ejecutada aplicando las técnicas que se resumen en la tabla 4.11.

Tabla 4.9. Plantilla para definición del alcance del proyecto.

Definición del alcance del proyecto



Nombre del Proyecto




Equipo participante en el proceso de definición del alcance del proyecto.

Nombres de los miembros del equipo participantes en la definición del alcance del proyecto y rol desempeñado por cada integrante.



Descripción del proyecto Descripción resumida del propósito del proyecto de Data Mining.

Tecnología asociada Descripción del ámbito tecnológico asociado al desarrollo del proyecto.

Escenario actual Descripción del escenario actual en el cual está inserta y se desarrolla la unidad de negocio que origina el desarrollo del proyecto.

Oportunidad de negocio

Descripción de los principales beneficios que se espera lograr con el desarrollo del proyecto considerando el escenario previamente descrito.

Restricciones Descripción de restricciones que afectan adversamente al desarrollo del proyecto y las acciones tendientes a contrarrestar dichas restricciones.

Riesgos Descripción de riesgos asociados al desarrollo del proyecto y plan de contingencias considerados.

Objetivos no considerados Descripción de los requisitos organizacionales que no serán considerados en la solución proporcionada por el proyecto de Data Mining.

Reglas y procedimientos para el tratamiento de cambios en los requisitos

Definición de las reglas y procedimientos, para el tratamiento de modificaciones en los requisitos, en el proceso de definición de requisitos y a lo largo del desarrollo del proyecto.

140

Paso 5. Glosario de términos del proyecto. En toda organización existe un conjunto de palabras, tecnicismos y conceptos que son propios del dominio de negocio y más aun, propios de la cultura e identidad organizacional. Un conjunto particular de términos, conceptos y tecnicismos también es utilizado en diferentes ámbitos de la tecnología y de las ciencias, razón por la cual es importante generar un listado organizado de dichos términos y conceptos, con el objetivo de facilitar y estimular el necesario entendimiento y acuerdo que se debe lograr entre las partes involucradas en el desarrollo del proyecto. Este listado comúnmente es referenciado como el glosario de términos del proyecto. La tabla 4.10, muestra una plantilla para construir éste glosario.

Tabla 4.10. Plantilla para la definición del glosario del proyecto

Glosario de términos del proyecto


Consigna el nombre de la organización para la cual se desarrolla el proyecto

Nombre del Proyecto Consigna el nombre del proyecto a desarrollar

Nombre del Jefe de Proyecto Nombre y cargo del jefe de proyecto

Equipo participante en la definición del glosario de términos del proyecto.

Nombres de los miembros del equipo participantes en la definición del glosario de términos del proyecto.

Fecha de elaboración del documento Consigna la fecha de elaboración del documento

Terminología de Carácter general

Término Significado Nombre del término utilizado en el ámbito del dominio de negocio. Descripción de la semántica del término.

Terminología Propia de la Organización

Término Significado Nombre del término utilizado en el ámbito de la organización. Descripción de la semántica del término.

Terminología Propia de Data Mining

Término Significado Nombre del término utilizado en el ámbito técnico. Descripción de la semántica del término.

Referencias

Listado de todas fuentes, personales o documentales de los cuales provienen los términos descritos en el glosario del proyecto.

Respecto de las técnicas de educción a utilizar, para recolectar la información que se requiere en cada una de las actividades que componen la fase de definición de requisitos organizacionales, se puede expresar lo siguiente. La aplicación de cada técnica en particular, es función de la naturaleza de la información que debe ser recolectada. Por ejemplo, considerando la naturaleza multidisciplinar del equipo que debe participar en

141

un proyecto de Data Mining, es recomendable que las decisiones respecto de los posibles participantes en el proyecto, sea realizada por consenso. Es por esta razón que pueden aplicarse técnicas grupales tales como JAD o Workshop. En cuanto a la preparación para el proceso de captura de requisitos, se requiere que todos los stakeholders, posean un conocimiento común respecto de aspectos generales del dominio de negocio y propios del desarrollo de un proyecto de Data Mining, razón por la cual este proceso debe ser realizado mediante técnicas grupales. Un análisis similar es realizado en el resto de elementos de información, para realizar la propuesta que finalmente se resume en la tabla 4.11.

Tabla 4.11. Técnicas de educción a utilizar en la fase de definición de requisitos organizacionales.

TÉCNICAS

ACTIVIDADES

Anál

isis

de

Ries

gos

Entr

evis

tas

Doc

umen

tos

Exis

tent

es

Focu

s Gro

up

JAD

Wor

kSho

p

o Identificación del equipo participante en el proyecto.

X X

o Preparación para el proceso de captura de requisitos de negocio.

X X X

o Captura de los requisitos organizacionales. X X X X o Definición del alcance del proyecto. X X X X o Glosario de términos del dominio de

negocio y de Data Mining. X X X

4.2.3. Fase de construcción del modelo de negocios decisional. Antes de dar inicio al desarrollo de una propuesta de construcción y especificación del “Modelo de Negocios Decisional” de una organización (figura 4.10), fase constituyente de la metodología que se propone en el presente trabajo de tesis doctoral, es conveniente recordar la definición del concepto de “Modelo de Negocio”.


Produce

MISIÓN


METAS


objetivos asociados

REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 4.10. Modelo de Negocio Decisional (elaboración propia).

142

De las variadas definiciones que se encuentran en la literatura, una definición suficientemente general y que puede ser utilizada en áreas tales como e-business, sistemas de información o ciencias de la computación, es la que se encuentra en [Osterwalder, 2005] e indica, “un modelo de negocio, es una herramienta conceptual, que contiene un conjunto de objetos, conceptos y sus relaciones, con el propósito de representar la lógica de negocios de una empresa específica y sus procesos asociados”. Todo especialista en un negocio (administrador), tiene un mapa mental o conceptual de la lógica de negocios de su organización, sin embargo no necesariamente tiene la capacidad de comunicarla de una manera clara y no ambigua, por lo tanto, la construcción de un modelo de negocios, en general deberá facilitar la comprensión de la lógica y el dominio del negocio y sus procesos asociados a los diversos actores organizacionales permitiendo además, alinear el desarrollo de cualquier proyecto, con las metas y objetivos estratégicos de la organización; en este sentido una mejor comprensión de la lógica de negocios de la empresa, debe permitir a los administradores tomar mejores decisiones [Hayes, 2005]. Por otro lado los expertos de Data Mining, tienen que poder vislumbrar de qué manera un proyecto de Data Mining estará alineado con las metas y objetivos de una organización. Sin embargo, este hecho en muchas ocasiones no es posible de lograrlo y es por esta razón que el desarrollo de un modelo de negocios es importante. El modelo de negocios, debe servir como un puente (figura 4.11) que permita una mejor comunicación y comprensión de las metas de la organización por parte de los administradores de la organización (mandantes del proyecto) y los expertos de Data Mining quienes tienen a cargo el desarrollo del proyecto.

Figura No. 4.11. Aportes del modelo de negocio (elaborado en base a [Osterwalder, 2005]).

Sin embargo, el desarrollo de un modelo de negocios no es una tarea simple, es en sí una tarea compleja, por la complejidad inherente de las organizaciones y el actual incremento en el uso de las tecnologías [Lechner, 2002]. De esta manera y para simplificar la tarea, en [Ericsson, 2000], se indica que un modelo de negocios puede estar constituido por un conjunto de visiones, en función de los aspectos de negocio que se deseen resaltar y/o de acuerdo al tipo de problemas que se deseen resolver, es decir, que si bien un modelo es una abstracción de cómo funciona el negocio, los detalles del

143

modelo, son función de quien o quienes crean el modelo y la visión en particular que tengan acerca de las metas, objetivos y otros aspectos del negocio. Luego, considerando que un proyecto de Data Mining es desarrollado para apoyar el proceso de toma de decisiones de una organización, es necesario obtener un modelo de negocios que sea capaz de representar dicho proceso, es decir un Modelo de Negocios Decisional. Se puede definir de manera genérica al término “Modelo de Negocios Decisional”, en base a la definición de modelo de negocios de [Osterwalder, 2005] como: “una herramienta conceptual compuesta por un conjunto de objetos, conceptos y sus relaciones, con el propósito de representar los procesos de toma de decisiones de una organización”. El grado de complejidad del modelo de negocios, se ve incrementado por el hecho de que un proyecto de Data Mining, normalmente, debe servir como soporte a los procesos de toma de decisiones en la organización. Los procesos de toma de decisiones, son procesos complejos en su esencia, pues deben conducir a la selección de una alternativa entre muchas y que en lo posible sea la de menor coste, para lo cual se deberán establecer previamente, juicios evaluativos en los que intervienen un sinnúmero de factores tales como, el razonamiento, un conocimiento profundo de las materias asociadas y factores externos. Hechas las consideraciones anteriores, se propone descomponer el proceso de construcción del modelo de negocios decisional, en un conjunto de pasos o etapas, las cuales deben ser desarrolladas en un proceso iterativo que finalmente, debe conducir a un modelo de negocios decisional concordado entre los directivos de la organización, expertos de negocio y expertos de Data Mining. La figura 4.12 representa el proceso propuesto para la construcción del modelo de negocios decisional.

Figura No. 4.12. Fases del proceso de Modelado de Negocio Decisional (elaboración propia).

Para la adquisición de la información inherente requerida en cada una de las etapas del proceso, se sugiere la aplicación de técnicas de Ingeniería de Requisitos e Ingeniería de Conocimientos, en función del tipo de fuente de información consultada [Gomez, 1997]. La terminología asociada al proceso de adquisición, corresponde a “extracción”, cuando las fuentes son documentales, con técnicas tales como Análisis de Documentos, o “educción”, cuando las fuentes de información son los expertos. Así mismo, los tipos de

144

técnicas a utilizar en los procesos de educción, pueden ser denominadas “directas”, en los casos en que el experto pueda reportar la información que posee por articulación directa, para cuyo cometido se usan técnicas como entrevistas abiertas o estructuradas, o cuestionarios, o “indirectas”, en el caso, a veces muy común, en el cual los expertos no siempre tienen claros los detalles de sus procesos mentales, es decir la claridad sobre el aval de sus decisiones. En este último caso se precisa la utilización de técnicas de educción, más ligadas al ámbito de la Ingeniería de Conocimientos tales como por ejemplo, Análisis de Protocolos, Clasificación de Conceptos, o Emparrillado. A continuación se presenta una descripción de cada una de las actividades que componen el proceso propuesto y que permitirán finalmente obtener un modelo del proceso decisional dentro de la organización. Paso 1. Definir las metas que dan origen al proceso decisional. En esta primera etapa, se debe definir de entre las metas organizacionales elicitadas en la fase de educción de requisitos organizacionales (apartado 4.2.2), cuál es la meta estratégica que origina el proceso decisional que se desea modelar. Esta meta, será posteriormente el objetivo de más alto nivel que se desea conseguir a través del logro de una serie de metas de más bajo nivel, las cuales podrán dividirse en una serie de tareas ejecutadas por los actores organizacionales. Paso 2. Descubrir actores organizacionales que participan del proceso decisional. Para descubrir qué actores participan del proceso decisional, es conveniente considerar que dentro de una organización, existen diversos actores organizacionales que participan en los procesos decisionales insertos en los diferentes niveles de la pirámide organizacional [Laudon, 2004]. En los niveles operativos y del conocimiento, se toman decisiones de tipo estructuradas, es decir, decisiones que se apoyan en procedimientos establecidos dentro de la organización, no son innovadoras y tienden a repetirse, sin embargo, a medida que se avanza hacia los niveles estratégicos, el tipo de decisiones se transforma en decisiones de tipo no estructuradas, o al menos semiestructuradas, éstas tienen un alto nivel de incertidumbre y afectan a toda la organización. Hechas estas consideraciones, se debe identificar a los actores que toman las decisiones estratégicas (“actores primarios”) en el nivel que corresponda [Laudon, 2004] y adicionalmente a los actores que participan en el proceso de toma de decisiones, pero sin tomar decisión alguna (“actores secundarios”). Paso 3. Elicitar información o conocimiento requerido para la toma de decisiones.

En esta tercera etapa, se debe descubrir qué información o conocimiento, precisan adquirir o asimilar los actores organizacionales primarios para tomar decisiones. El descubrimiento de esta información o conocimiento, constituirá dentro del modelo, las potenciales metas de más bajo nivel que deben satisfacerse para el cumplimiento de la meta general que da origen al proceso decisional. En esta etapa, existe un desafío adicional para los modeladores o ingenieros del conocimiento y es lograr descubrir en lo posible, todos los factores que no se definen explícitamente y que el tomador de decisiones podría considerar inconscientemente.

145

Paso 4. Determinar los datos, que sirven de fuente de información o conocimiento. Esta etapa tiene por objetivo, el poder determinar todas las fuentes de datos necesarias a partir de las cuales, se pueda extraer la información o el conocimiento que precisan los tomadores de decisiones. En este punto es importante considerar, que no necesariamente los datos están disponibles al interior de la organización, es decir los datos podrían surgir de variadas fuentes, tanto internas como externas a la organización. Finalmente, el descubrir y considerar todos los recursos necesarios, es relevante por cuanto los datos son la materia prima para un proyecto de Data Mining. A objeto de guiar en el proceso de elicitación de la información que se precisa obtener con la ejecución de los cuatro primeros pasos de la fase de Construcción del Modelo de Negocios Decisional, se propone la plantilla que se muestra en la tabla 4.12.

Tabla 4.12. Plantilla para educción de metas, actores, información o conocimiento y datos.

Metas, actores, información o conocimiento y datos



Nombre del Proyecto




Equipo participante en el proceso de educción de la información consignada en el documento

Nombre de los miembros del equipo participantes del proceso de educción de información consignada en el documento.




Unidad de Negocio Usuarios Descripción de la unidad de negocio mandante del proyecto y principales responsabilidades.

Consigna nombre y funciones que desempeñan los usuarios del proyecto.

Meta origen del Proceso Decisional Consigna el nombre de la meta más general que es la meta que da origen al proceso decisional.

Metas de Logro Actores involucrados Información o

conocimiento requerido

Fuentes de datos

Listado de metas de logro en las cuales se puede descomponer la

meta origen del proceso decisional.

Listado de actores que participan en la

ejecución de la meta de logro.

Información o conocimiento

requerido para la concreción de la meta

de logro asociada.

Fuentes origen de los datos requeridos para

el proceso de extracción de información o conocimiento

requerido por los actores que toman las

decisiones.

146

Paso 5. Definir la red de dependencias entre actores organizacionales. Esta etapa tiene por objetivo, determinar de qué manera se establece la red de dependencias entre los diferentes actores involucrados en el proceso de toma de decisiones, es decir, se pretende definir cómo los actores se relacionan entre si y los grados de responsabilidad en el logro de las tareas necesarias que permiten el cumplimiento de las metas trazadas. La tabla 4.13, describe la nomenclatura utilizada en la definición del árbol de refinamiento de metas y la tabla 4.14, ilustra una plantilla para guiar la construcción del árbol de refinamiento de metas,

Tabla 4.13. Simbología a utilizar.

SIMBOLO DEFINICIÓN MG Metas Generales ML Metas de Logro Oper Operaciones Asociadas

Actores Agentes responsables

Tabla 4.14. Red de dependencias entre actores organizacionales.

Red de dependencias entre actores organizacionales (árbol de refinamiento de metas)



Nombre del Proyecto




Equipo participante en el proceso de educción de la información consignada en el documento

Nombres de los miembros del equipo participantes del proceso de educción de información consignada en el documento.



Meta origen del Proceso Decisional

Meta de Logro

Operaciones asociadas Actores responsables

Nombre de cada una de las metas de logro en que se

descompone la meta origen del proceso decisional.

Listado de operaciones asociadas a cada meta de logro

en particular.

Actores responsables de la ejecución de cada una de las operaciones asociadas a las

metas de logro.

A partir de la información elicitada en las etapas anteriormente descritas, se procederá posteriormente a la construcción de un árbol de refinamiento de metas (tabla 4.15), con dos (metas general y de logro) o máximo tres niveles de profundidad (metas generales,

147

de logro y operaciones) de acuerdo a lo sugerido en [Glinz, 2000] y [Martinez, 2002]. En este árbol de metas, se presenta la descomposición de la meta de más de alto nivel, en metas de logro, operaciones asociadas y actores involucrados. Finalmente la información consignada, constituirá la información base a partir de la cual, se pueda construir la representación grafica del proceso decisional.

Tabla 4.15. Árbol de refinamiento de metas

Árbol de refinamiento de metas

Nombre de la Meta Tipo Actores involucrados Nombre de la meta general, de

logro u operación. Tipo de meta: meta general (MG), meta de logro (ML),

operación (Oper.)

Rol del o los actores responsables

Paso 6. Creación del modelo de proceso decisional.

La construcción del modelo de proceso decisional, constituye la última etapa del proceso de modelado y consiste en la aplicación de la técnica denominada “framework i*” (descrita en el punto 2.4.3.4.3, sección 2.4, del presente trabajo de tesis), para representar gráficamente la información capturada en las anteriores etapas. Entre las múltiples razones que sustentan el uso del framework i* en esta etapa, se pueden citar:

(1) El framework i*, constituye una técnica de modelado, más que sólo un lenguaje de modelado (UML, BPMN), pues define un procedimiento para la obtención de un modelo organizacional.

(2) Permite la comprensión del modelo, de una manera simple e intuitiva por cuanto es posible construir una vista multinivel del proceso a modelar.

(3) Los requisitos organizacionales no sólo están circunscritos a las funcionalidades del sistema a desarrollar, sino también, como lo es en el caso de sistemas de Data Mining, sistemas de tiempo real o de control de procesos, están fuertemente relacionados a requisitos globales tales como confiabilidad, precisión, desempeño, seguridad, coste, etc., requisitos que adquieren gran connotación en este tipo de sistemas. En este sentido, UML o BPMN, no contemplan este tipo de restricciones de manera explícita, a diferencia del framework i*, que posee primitivas relacionadas con la noción de requisitos no funcionales.

(4) Permite representar de manera explícita las metas organizacionales, las tareas y recursos involucrados y la red de dependencias estratégicas que se establece entre los diferentes actores que participan para el logro de las metas identificadas y consecuentemente, comprender de mejor forma, las razones involucradas en los procesos decisionales.

(5) Permite derivar de manera simple y en forma gradual las especificaciones de requisitos más próximos a los requisitos organizacionales.

A continuación se propone una secuencia de fases para la construcción incremental del modelo de proceso decisional, aplicando el “Framework i*”.

148

El proceso de modelado del negocio aplicando el framework i*, deriva en el desarrollo de dos modelos: el modelo de dependencias estratégicas y el modelo de razones estratégicas, construidos en una secuencia de cinco fases (figura 4.13).

Figura No. 4.13. Fases del proceso construcción del modelo (elaboración propia).

El primer modelo, es el de más alto nivel y tiene como objetivo, representar a los actores que intervienen en el proceso decisional y sus ligas de dependencia, ya sean, de metas de logro, metas suaves, tareas, y/o recursos requeridos o generados, necesarios para la materialización de las metas generales identificadas en el primer paso del proceso (definición de metas que dan origen al proceso decisional).

La construcción del primer modelo (modelo de dependencias estratégicas), se propone sea realizada mediante una modalidad incremental de tres fases:

Fase 1. Se desarrolla un primer modelo (modelo de primer nivel) muy básico y con un alto nivel de abstracción, cuyo objetivo es que todos los Stakeholders puedan comprender de la manera más simple e intuitiva, lo que quiere representar el modelo a nivel de metas de logro. En este primer modelo, sólo se deben identificar a los actores que participan del proceso y la red de dependencias de metas de logro que los ligan, las cuales se encuentran definidas en el árbol de refinamiento de metas.

Fase 2. Una vez desarrollado el primer modelo, se procede a desarrollar un segundo modelo (modelo de segundo nivel) con un mayor nivel de detalle. En este segundo modelo, se representan las tareas originadas por cada meta de logro, los recursos requeridos para su concreción y los recursos que se generan producto del desarrollo de alguna tarea u operación del proceso.

149

Fase 3. Se concluye la construcción del modelo de dependencias estratégicas, con la definición de un tercer modelo (modelo de tercer nivel), en el cual se incorpora al actor “Sistema”. Las metas de logro de más alto nivel definidas inicialmente en el modelo de primer nivel, se descomponen en tareas u operaciones más granulares (modelo de segundo nivel). Posteriormente se analiza, cuál o cuáles de estas tareas pueden ser automatizadas o en qué actividades se requiere el apoyo de un sistema computacional (sistema de Data Mining). Esta información, es conveniente consignarla previamente en el árbol de refinamiento de metas. Luego de identificadas las tareas susceptibles de ser automatizadas, éstas se derivan al sistema, convirtiéndose ahora en nuevas metas de logro ligadas al actor “sistema”. Estas nuevas metas de logro, serán las candidatas potenciales para transformarse en los casos de uso del futuro modelo de requisitos del sistema.

El segundo modelo, denominado modelo de razones estratégicas, tiene como meta, representar de forma más explícita los recursos (materiales o informacionales) y la secuencia de eventos granulares (escenario) que desencadenan las actividades requeridas para el cumplimiento de las metas de logro. El desarrollo de este segundo modelo (extensión del modelo de dependencias estratégicas), puede también efectuarse de manera incremental para una mejor comprensión del proceso y se propone sea realizado en dos fases.

Fase 4. A objeto de tener una visión menos compleja, el modelado inicialmente se realiza a partir del modelo de dependencias estratégicas de segundo nivel obtenido en la fase 2, el cual no incorpora al actor sistema. En esta fase, se mapean las metas de logro (que formaban parte de la liga de dependencias) del modelo de dependencias estratégicas, en tareas de alto nivel. Estas tareas, en función de su nivel de complejidad, pueden ser descompuestas mediante el constructor “task-descomposition” en tareas menos complejas o en operaciones elementales que puedan ser desarrolladas por algún actor en particular. Si existiese más de una alternativa para lograr una meta o tarea, se utiliza para su representación el constructor “means-end”. Se debe considerar también, que cada recurso involucrado en el proceso, da origen a la especificación de las operaciones de envío y recepción del recurso, en el actor “Depende” y en el actor “Depender” respectivamente.

Fase 5. Para concluir el proceso de modelado y considerando que algunas de las tareas que deberán ejecutar determinados actores organizacionales, requieren del apoyo de sistemas de cómputo para el procesamiento de los datos e información, se incorpora al actor Sistema. Consecuentemente, la construcción de este modelo se realiza en función del modelo de dependencias estratégicas de tercer nivel (fase 3). Al actor Sistema, se asignan todas las tareas que requieren ser automatizadas y que en el modelo de dependencias estratégicas, constituían metas de logro. Luego, en el campo de acción del actor Sistema, las metas de logro del modelo de dependencias estratégicas de tercer nivel, mapeadas en tareas de alto nivel, se descomponen en tareas más específicas en función del tipo de recursos con que se cuenta y el nivel de especialización de cada problema. Esta descomposición de tareas de alto nivel (metas de logro del modelo de dependencias estratégicas) en tareas más simples y recursos asociados, debe constituir más adelante, el posterior escenario de casos de uso, en el modelo de requisitos.

150

4.2.4. Fase de modelado de requisitos. La definición de las pautas para la obtención de un modelo de negocios decisional planteadas en la fase anterior, tenía como principal propósito, el guiar en la obtención de un modelo que permita una transición lo más natural posible, a un posterior modelo de requisitos para un sistema de Data Mining (figura 4.14).


Produce

MISIÓN


METAS


objetivos asociados

REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 4.14. Modelo de requisitos (elaboración propia).

4.2.4.1. Especificación de los requisitos.

La especificación de los requisitos de un sistema computacional, puede ser realizada ya sea, mediante un documento escrito (lenguaje natural o algún lenguaje de descripción), a través de un modelo matemático formal, o mediante una notación gráfica. Cada una de las formas citadas, tiene ventajas y desventajas. Las descripciones textuales (en lenguaje natural), si bien son más sencillas y flexibles, suelen presentar habitualmente muchas ambigüedades, falta de claridad o gran cantidad de documentos difíciles de procesar, características que no presentan los lenguajes formales, sin embargo estos últimos, generalmente son complejos, menos flexibles, requieren de un esfuerzo adicional (entrenamiento) para su uso y frecuentemente los entienden sólo los especialistas. Los modelos gráficos por otra parte, presentan como característica principal, permitir a un grupo heterogéneo de stakeholders una buena y rápida comprensión de las funcionalidades que debe tener el futuro sistema, mediante la representación de escenarios, la selección de las características más relevantes de la entidad representada y la omisión de los detalles menos importantes, como contraparte, a medida que aumenta la información a representarse, la comprensión del modelo se hace más compleja. No obstante, en sistemas complejos, una combinación entre una descripción en lenguaje natural y el uso de modelos gráficos puede ser una buena alternativa.

En este sentido, los diagramas de casos de uso, han sido tradicionalmente utilizados por los ingenieros de software, para describir y representar, las funcionalidades esperadas de un sistema por parte de los usuarios (actores), que representan a cualquier elemento

151

externo que interactúa con el sistema. Es posible considerar que un caso de uso, es una descripción (escenario) de un conjunto de acciones que el sistema deberá realizar, para producir resultados observables y útiles para el actor.

Los casos de uso derivados a partir de un modelo de negocios, permiten a los ingenieros de requisitos, establecer las requeridas relaciones entre los requisitos funcionales del sistema a ser construido y las metas organizacionales previamente definidas en el modelo de negocios [Santander, 2002].

Cuando las funcionalidades esperadas del sistema, son las funcionalidades que se esperan de un sistema de Data Mining, es necesario definir claramente, qué representa una funcionalidad en el contexto de un sistema de Data Mining, por lo tanto en el siguiente apartado se propone en el contexto de la presente tesis doctoral, una taxonomía de requisitos de Data Mining.

4.2.4.2. Taxonomía para requisitos en Proyectos de Data Mining.

El análisis de requisitos previo al desarrollo de cualquier sistema, es un factor clave para su correcta construcción y aceptación por parte de los Stakeholders. El contar con una taxonomía adecuada de ellos, de acuerdo al tipo de sistema, facilita su educción, organización, validación y su posterior transformación en acciones de diseño/implementación o desarrollo de prototipos. En el caso de proyectos de desarrollo de sistemas de software, una categorización entre tipos de requisitos que ha sido casi universalmente aceptada, distingue entre requisitos funcionales, aquellos requisitos que describen qué deberá hacer el sistema y no funcionales, aquellos requisitos que imponen restricciones sobre cómo estos requisitos funcionales son implementados.

A diferencia de un proyecto de desarrollo de software, un proyecto de Data Mining, básicamente busca encontrar el conocimiento (nuevo) que potencialmente existe, inmerso entre los datos de una organización, por lo tanto, la taxonomía para proyectos de software, no es directamente aplicable hacia proyectos de Data Mining y se hace necesario redefinirla y extenderla para éste y otros tipos de proyectos. Por lo tanto, tomando en cuenta la clasificación existente para el desarrollo de proyectos de software (requisitos funcionales y requisitos no funcionales) se propone compatibilizar esta taxonomía, con los tipos de “funcionalidad” y “calidad” que podrían encontrarse producto del desarrollo de proyectos de Data Mining. La redefinición de requisitos funcionales y no funcionales para proyectos de Data Mining que se propone, es la siguiente:

• Requisitos Funcionales. Se debe entender por requisitos funcionales para sistemas

de Data Mining, aquellos requisitos cuya funcionalidad involucre el desarrollo de un proceso destinado a corroborar o desechar presunciones existentes, o bien a encontrar nuevos patrones en base a los datos de la organización o finalmente desarrollar resúmenes o agregación de datos. Por ello, dentro de los requisitos funcionales de Data Mining, se distinguirán tres sub-categorías:

1. Requisitos de Verificación, que involucra desarrollar un proceso orientado a verificar las hipótesis del usuario. Por ejemplo, confirmar o descartar la hipótesis, de que los estudiantes provenientes de colegios privados que ingresan

152

a las universidades tienen una mayor probabilidad que otros estudiantes, de concluir exitosamente sus estudios universitarios.

2. Requisitos de Descubrimiento, que involucran desarrollar un proceso destinado a encontrar nuevos patrones, para predecir el comportamiento futuro de algunas variables. Considerando que la actividad de Data Mining es eminentemente, de naturaleza exploratoria, la mayoría de los proyectos involucran requisitos de descubrimiento de patrones.

Dentro de los requisitos de descubrimiento, se definen los siguientes tipos:

o Requisitos Predictivos, los cuales requieren la generación de un modelo que permita predecir una categoría o el valor de un concepto en base a otras variables.

o Requisitos Descriptivos, los cuales requieren la identificación de segmentos o grupos distintivos de datos.

o Requisitos de Relacionamiento, los cuales requieren identificar la relación que exista entre datos individuales o grupos de datos.

o Requisitos de Desviaciones, los cuales requieren la detección de patrones potencialmente anómalos, o que impliquen una desviación significativa de los comportamientos considerados normales.

3. Requisitos de Agregación, que involucran desarrollar resúmenes o agregación de datos e información, pero que no conllevan la verificación de hipótesis o la generación de un modelo.

• Requisitos no Funcionales. En este caso, se trata de requisitos que identifican las restricciones técnicas o definen condiciones bajo las cuales los resultados obtenidos son considerados aceptables. Por lo tanto, dentro de los requisitos no funcionales de Data Mining, es posible distinguir las siguientes sub-categorías:

1. Requisitos de Rendimiento. Se refieren a requisitos que expresan una condición o restricción de tiempo en ya sea, el proceso de obtención de resultados, o bien en la aplicación de los resultados.

2. Requisitos de Calidad. Se refieren a requisitos que expresan una restricción respecto a la precisión, el soporte, u otras medidas acordes al tipo de requisito funcional, que permitan contrastar cuantitativamente los resultados con lo especificado.

3. Requisitos de Novedad. Se refieren a condiciones de sorpresa o desconocimiento previo, definidas para evaluar el grado de novedad de los resultados. Por lo general, estos se pueden estimar subjetivamente, dado que están relacionados al contenido de información de los resultados, lo cual depende del grado de conocimiento previo que tenga el receptor de la información.

4. Requisitos de Comprensibilidad. Se refiere a condiciones que reflejan la necesidad e importancia de entender los resultados desde el punto de vista de una persona experta en el dominio del problema, pero no experta en Data Mining.

5. Requisitos Técnicos. Se derivan de políticas y procedimientos existentes en la organización del cliente y en la del desarrollador del proyecto de Data Mining.

153

Algunos ejemplos son la metodología o guía a utilizar para el desarrollo del proyecto, utilización de alguna herramienta en particular, etc.

4.2.4.3. Modelado de los requisitos.

En este apartado se describe como derivar el modelo de casos de uso, a partir de un modelo de negocios decisional. Existen diversos planteamientos orientados a la obtención de requisitos de software, a partir de un modelo de negocios, como por ejemplo los presentados en [Ortín, 2000], [Alencar, 2000] o [Santander, 2002]. La guía de transición que se describe, está basada en la propuesta desarrollada en [Santander, 2002], adaptada en este trabajo de tesis doctoral, a los proyectos de Data Mining. En dicha propuesta, el proceso se estructura en una secuencia de tres pasos, en los pasos 1 y 2, se identifican actores y casos de uso respectivamente y en el paso 3, se describen los escenarios de los casos de uso. En esta propuesta, a diferencia de la desarrollada en [Santander, 2002], se restringe la derivación de los casos de uso, a exclusivamente los obtenidos a partir de las dependencias de metas de logro. Esta restricción se deriva del hecho de que en un sistema de Data Mining, deberá entenderse que un caso de uso debe representar básicamente la meta de logro que el usuario pretende cumplir con la información o conocimiento provisto por el sistema de Data Mining y no como el proceso asociado al desarrollo de una meta, tarea, o logro de un recurso material o informacional. Sin embargo, es importante destacar que los casos de uso derivados a partir del Modelo de Negocios Decisional, no corresponden a casos de uso exclusivamente de Data Mining, sino que también, se pueden identificar casos de uso que corresponden a otras funcionalidades que pueden ser satisfechas mediante típicos sistemas de software, los cuales se complementan con los de Data Mining para el logro de las metas organizacionales. Es decir, el modelo de casos de uso, podrá estar compuesto por casos de uso de Data Mining y casos de uso de sistemas de software y es el equipo de expertos de Data Mining que debe discriminar los casos de uso de Data Mining. Considerando, que se cuenta con un modelo en el cual están identificados los actores que toman parte en el proceso decisional y las principales metas de logro que forman parte de una meta estratégica más general, se procede a derivar el modelo de casos de uso, tomando como entradas principales, los modelos de dependencias estratégicas y de razones estratégicas. La propuesta se desarrolla en una secuencia de tres pasos (figura 4.15), en los pasos uno y dos se identifican a los actores de los casos de uso y los casos de uso respectivamente, tomando como entrada el modelo de dependencias estratégicas. En el tercer paso se describen los escenarios de los casos de uso, basándose en definición del modelo de razones estratégicas.

Paso 1: Identificación de los actores del sistema Existen diversos actores que participan de un Proceso de Negocio Decisional, (modelo de dependencias estratégicas i*), los cuales son identificados y consignados en el árbol de refinamiento de metas, sin embargo los actores de los casos de uso, son los actores que están ligados con el actor sistema (directa o indirectamente) mediante algún tipo de dependencia, ya sea de meta de logro, o de tareas y recursos derivados a partir de una dependencia de meta. Aquellos actores que no poseen ningún tipo de relación de dependencia con el actor sistema, no pueden ser considerados actores de un caso de uso.

154

Se debe además considerar, que en el caso de que existan dos o más actores que compartan alguna dependencia mediante una relación de tipo IS - A en el modelo i*, deben ser mapeados como actores individuales en el modelo de casos de uso, originándose una relación de generalización entre ellos.

Salida

PASO 1Identificación de

Actores del Sistema

PASO 2

Identificación de los Casos de Uso

PASO 3Descripción de los

escenarios de Casos de Uso

Actores de los Casos de Uso

Listado de Casos de Uso

Descripción textual de cada Caso de

Uso

Entrada Entrada

Modelo de Dependencias Estratégicas

Entrada

Modelo de Razones Estratégicas

Salida Salida

Figura No. 4.15. Actividades en el modelado de los requisitos (elaborado en base a [Santander, 2002]).

Paso 2. Identificación de casos de uso. Considerando nuevamente como entrada el modelo de dependencias estratégicas, deben identificarse todas las dependencias de meta (dependum) para las cuales el actor identificado en el primer paso, desempeña el rol de dependee en la relación de dependencia. Y las dependencias de meta en las cuales el cual el actor desempeña el rol de depender de la relación.

• Cuando el actor actúa como dependee de una dependencia de meta, se asume que el sistema para generar una salida, requiere que el actor suministre algún tipo de recurso informacional y el objeto de la dependencia (dependum), se transforma en un caso de uso.

• El caso en el cual, el actor actúa como depender en la liga de dependencias con el sistema, representa el uso del conocimiento o información que provee el sistema por parte del actor, para el cumplimiento de las metas relacionadas con el caso de uso identificado. En este caso, nuevamente el objeto de la dependencia (dependum) se transforma en un caso de uso.

Paso 3. Descripción de los escenarios de casos de uso.

El tercer paso que se debe abordar para la concreción del modelo de requisitos mediante casos de uso, es la descripción del escenario del caso de uso asociado a un determinado actor. Es decir, se debe describir la secuencia de eventos internos que se desencadenan durante la ejecución de las tareas y obtención de los recursos asociados al cumplimiento de una meta. Esta secuencia eventos, es la que se describe gráficamente en el modelo de razones estratégicas. Como se recordara, el modelo de razones estratégicas considera la descripción de los intereses y motivaciones, la valoración de las posibles alternativas y la especificación más detallada de las razones de la existencia de dependencias entre los diferentes actores organizacionales. La descripción de los escenarios asociados a los casos de uso, no es más que la descripción textual asociada a cada caso de uso, del

155

campo de acción de cada actor que interviene en la concreción de una meta, tarea o recurso representado en el modelo de razones estratégicas. 4.2.5. Fase de creación de modelos de prueba.

El desarrollo de esta fase (figura 4.16) se justifica y fundamenta en el principio IKIWISI (I’ll Know It When I See It, lo sabré cuando lo vea) identificado por Barry Boehm [Nuseibeh, 2001], [Boehm, 2000], que indica que los requisitos emergen después de que un desarrollo de prototipos del sistema tiene lugar y los usuarios tienen la oportunidad de proveer retroalimentación en base a la observación. En efecto, este hecho normalmente es típico en el desarrollo de sistemas de software, en los cuales, a medida que el usuario puede ver ciertas pantallas del futuro probable sistema, va aclarando cada vez más sus ideas y los requisitos iniciales. Evidentemente es importante previamente llegar a un principio de acuerdo sobre un número de iteraciones aceptable, pues en la práctica se puede observar que los requisitos de los usuarios son muy dinámicos y tienden a mutar permanentemente.

Figura No. 4.16. Modelos de prueba (elaboración propia).

En el campo del desarrollo de proyectos de Data Mining, esta fase es muy importante debido a que frecuentemente los usuarios al principio, no tienen muy claro lo que desean ni la forma cómo un proyecto de Data Mining, les suministrara información o conocimiento.

Bien, entonces luego contar con los requisitos iniciales del proyecto, se procede a recolectar los datos necesarios para poder crear modelos de prueba, con el propósito de mostrarle al usuario cuales son los resultados concretos que se obtendrán con un proyecto de Data Mining. Cabe señalar que para construir estos modelos de prueba, no es preciso seguir rigurosamente alguna de las guías propuestas para el desarrollo de proyectos de Data Mining tales como CRISP-DM o SEMMA, debido a que la idea no es obtener inmediatamente resultados finales, sino que interiorizar más aún al usuario/cliente sobre el tipo y la forma en que la información será presentada. La idea es presentar lo más pronto posible, resultados de análisis en base a los datos que se tengan disponibles en el momento de inicio del proyecto, es decir no se debe perder mucho tiempo en la construcción de los modelos de prueba.

156

Luego de construidos los modelos de prueba, los resultados deben ser expuestos y explicados a los clientes/usuarios, permitiéndoles que ellos realicen los análisis pertinentes; para posteriormente en base a los análisis realizados y refinando los requisitos, definir con una mayor precisión, los requisitos finales del sistema. Si esta fase de creación de modelos iniciales de prueba es exitosa, los usuarios presentarán muchas más interrogantes e ideas para construir nuevos modelos planteando incluso, hipótesis que querrán demostrar con los procesos de Data Mining.

4.2.6. Fase de redacción del documento final de contrato. Esta es la última fase del modelo propuesto (figura 4.17) y consiste en la redacción del documento final de contrato, el cual debe constituir el medio utilizado para especificar las características del sistema a desarrollar, las restricciones en cuanto al proceso de su implementación y en general, deberá servir de base para el desarrollo del proyecto de Data Mining. En este documento, se especifican todos los requisitos del cliente y usuario, como también el detalle de los requisitos del sistema, es decir se debe especificar lo que el sistema debe proveer a los usuarios y también el listado de los requisitos para el sistema. Ambos tipos de requisitos pueden ser integrados en un mismo documento o pueden ser redactados mediante diversos artefactos.

Figura No. 4.17. Documento de contrato (elaboración propia).

Es importante considerar antes de redactar el contrato, que este documento tendrá diferentes usuarios [Sommerville, 2005], tales como los clientes/usuarios y los desarrolladores del sistema (mineros de datos), por lo tanto debe cautelarse porque su redacción logre una efectiva comunicación entre los diferentes stakeholders. Para cumplir con este objetivo, el documento de requisitos deberá cumplir las siguientes características.

oo Definir claramente las salidas del sistema.

oo Especificar los límites de la implementación (restricciones).

oo Permitir cambios.

157

oo Servir como una herramienta base para el desarrollo del sistema.

Para la estructuración de un documento de requisitos, han sido propuestas diferentes recomendaciones o normas, entre las cuales se puede destacar la norma IEEE/ANSI 830-1998 [IEEE, 1998], que es una norma aceptada internacionalmente. Esta norma sugiere la siguiente estructura para los Documentos de Requisitos [Sommerville, 2005]:

1. Introducción 1.1 Propósito del documento 1.2 Alcance del producto 1.3 Definiciones, acrónimos y abreviaturas 1.4 Referencias 1.5 Resumen del resto del documento

2. Descripción general 2.1 Perspectiva del producto 2.2. Funciones del producto 2.3 Características del usuario 2.4 Restricciones generales 2.5 Suposiciones y dependencias 3. Requisitos específicos

Este es el núcleo del documento, en este apartado se especifican los requisitos funcionales, los no funcionales y de interfaz. Dada la variabilidad en la práctica organizacional, en este apartado, no se define una estructura estándar.

4. Apéndices 5. Índice.

Sin embargo, a pesar de ser esta norma ampliamente aceptada, es muy general para constituirse en un estándar para las diversas organizaciones, por lo cual se toma solamente como un marco general [Sommerville, 2005], el cual es adaptado a las necesidades y cultura organizacional de la organización en particular. Normalmente, el documento de contrato es redactado en lenguaje natural, por lo cual podría presentar algunas características no deseables tales como, la generalidad o la ambigüedad (propias del lenguaje natural), para compensar estas características no deseables se recomienda complementar el documento, con artefactos adicionales aclaratorios tales como por ejemplo, modelos gráficos. Es importante en este sentido, considerar que la fase de construcción del documento de requisitos, si bien es la última fase del modelo de proceso propuesto, no implica que la construcción del documento sea realizada solamente en esta fase. En la práctica, el documento de requisitos es generado a lo largo del desarrollo de las diferentes fases de las cuales se compone el framework corazón de la metodología (ER-DM), por lo tanto en esta fase final, la redacción del documento de contrato, se debe acompañar en apéndices por los siguientes artefactos emitidos en las fases anteriores:

o Listado de los participantes del proyecto, a partir de documentos generados en la fase 2: Definición de requisitos organizacionales preliminares.

o La visión de Data Mining, a partir de los documentos generados en la fase 2: Definición de requisitos organizacionales preliminares.

158

o El Glosario del proyecto, a partir de los documentos generados en las fases 1 y 2: Comprensión del dominio de negocio y Definición de requisitos organizacionales preliminares.

o La especificación de las reglas de negocio, a partir de los documentos generados en la fase 1: Comprensión del dominio de negocio

o El modelo de negocio, a partir de los documentos generados en la fase 3: Construcción del modelo de negocio decisional.

o La especificación de los casos de uso, a partir de los documentos generados en la fase 4: Modelado de requisitos.

o Un registro histórico de las revisiones del documento de requisitos a partir del desarrollo de la fase 5: Creación de modelos de prueba.

159

CAPÍTULO V

Aplicación de la Metodología (ER-DM) en el Desarrollo de un Caso Práctico

(Ensayo de la Solución)

En este capítulo, se presenta el desarrollo de un caso de estudio real, en el cual se aplica la metodología ER-DM que se propone en el capítulo anterior. El caso de estudio, corresponde al desarrollo de un proyecto de Data Mining, el cual es parte importante de una de las fases del Proyecto MECESUP UCN 0607 ”DESARROLLO Y FORTALECIMIENTO DE LA CAPACIDAD Y LA CULTURA DE ANALISIS INSTITUCIONAL EN UNA RED UNIVERSITARIA”. Inicialmente se presentan en forma resumida, los principales objetivos del proyecto dentro de cuyo marco se desarrolla el proyecto de Data Mining y se describe la organización en la que se aplica el estudio; posteriormente se detalla la utilización de la metodología propuesta y finalmente se presentan los resultados del desarrollo del proyecto de Data Mining y sus principales conclusiones.

161

5.1. Introducción.

En el presente capítulo, se presenta el desarrollo de un caso de estudio real, en el cual se aplica la metodología propuesta en el capítulo anterior. El caso de estudio corresponde al desarrollo de un proyecto de Data Mining, en el marco de un proyecto MECESUP (Programa de Mejoramiento de la Calidad y la Equidad de la Educación Superior), el cual es ejecutado por un conjunto de universidades, entre las cuales se encuentra la Universidad Católica del Norte, institución patrocinante para la cual se desarrolla el proyecto de Data Mining. Los principales objetivos del proyecto MECESUP UCN 0607 “DESARROLLO Y FORTALECIMIENTO DE LA CAPACIDAD Y LA CULTURA DE ANÁLISIS INSTITUCIONAL EN UNA RED UNIVERSITARIA”, son los siguientes: i. Objetivos generales. o Hacer del análisis institucional, un componente esencial de los procesos de

planificación estratégica, en el marco de una cultura directiva basada en información.

o Conformar un consorcio de universidades, para generar y compartir información

de gestión académica y trabajar con el Observatorio de la Educación Superior del MINEDUC (Ministerio de Educación).

ii. Objetivos específicos. o Fortalecer el proceso de análisis institucional, mediante la creación de unidades

específicas que desarrollen esta función, con el propósito de potenciar los procesos de planificación, seguimiento y la toma de decisiones en las universidades que conforman la red.

o Obtener indicadores de gestión académica, que permitan dar cuenta pública de la

eficiencia y eficacia de los procesos institucionales de la red de universidades, de una manera uniforme y sistemática.

o Desarrollar en los equipos directivos, las competencias necesarias para crear una

cultura de gestión estratégica, basada en información. o Conformar una red de universidades, destinada a compartir experiencias e

información, en forma sistemática y permanente, para el fortalecimiento y mejoramiento continuo de sus procesos de gestión académica e institucional.

El proyecto de Data Mining a desarrollar, debe apoyar en lo que corresponde a la Universidad Católica del Norte, al cumplimiento del objetivo específico que dice relación a la obtención de indicadores de gestión académica. 5.2. La organización.

La Universidad Católica del Norte, es una institución privada de derecho público, perteneciente a la Iglesia Católica. Fue fundada el 31 de Mayo de 1956 como Escuela de

162

Pedagogía e Ingeniería, dependiente de la Universidad Católica de Valparaíso. En el año 1964, por Ley 15.561, es reconocida por el Estado como universidad autónoma pasando a integrar el Consejo de Rectores de las Universidades Chilenas, siendo la octava universidad que se crea en Chile y la tercera Universidad Católica del país. Desde su fundación ha sido una institución de significativa gravitación en la vida científica y cultural del norte chileno. La Universidad Católica del Norte, ubicada en las II y IV regiones de Chile, es una Universidad Católica, Tradicional y Regional, que identifica su quehacer con el hombre y el entorno geográfico donde se sitúa, siendo protagonista de la historia del norte, de su cultura, de la formación de recursos humanos y de la producción científica-tecnológica ligada al desarrollo regional y nacional. 5.3. Aplicación de la metodología ER-DM.

La metodología propuesta en el capitulo anterior, es aplicada en la fase de obtención y especificación de los requisitos para el desarrollo del proyecto de Data Mining, el cual debe permitir suministrar información relevante acerca de determinados indicadores (no claros al momento de iniciar el proyecto) que permitan a las autoridades tomar las decisiones pertinentes, tendientes a mejorar algunos de los índices que recomienda el Ministerio de Educación. La metodología propuesta, es representada mediante el Framework que se ilustra en la figura 5.1. En las siguientes secciones se presenta el desarrollo de cada una de las fases que componen el Framework.


Produce

MISIÓN


METAS

Descripción de metas organizacionales y objetivos asociados

REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 5.1. Framework para la especificación de requisitos (elaboración propia).

5.3.1. Fase de comprensión del dominio de negocio.

Esta primera fase del framework (figura 5.2), tiene como meta el descubrir la información necesaria que permita a los stakeholders y fundamentalmente, a los desarrolladores del proyecto, tener la suficiente y necesaria comprensión del dominio de negocio de la organización para la cual se desarrolla el proyecto, a objeto de consolidar

163

los necesarios lazos de confianza entre clientes y desarrolladores, establecer una visión común de la organización y conocer de los problemas organizacionales que precisan ser resueltos.


Produce

MISIÓN


METAS


REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 5.2. Comprensión del dominio del negocio (elaboración propia).

El enfoque adoptado para la ejecución de esta primera fase, consistió en la aplicación de la secuencia de actividades que se ilustran en la figura 5.3.

Figura No. 5.3. Secuencia de actividades involucradas en la fase de comprensión del Dominio de Negocio (elaboración propia).

Algunos de los elementos de información relevantes que se pueden destacar, son los que se enuncian en los párrafos siguientes. El detalle de toda la información elicitada, fuentes de información y técnicas de elicitación aplicadas para el descubrimiento de la información colectada, se adjunta en el anexo A. NOMBRE DE LA ORGANIZACIÓN:

Universidad Católica del Norte (UCN)

MISIÓN:

Búsqueda de la verdad, para contribuir al desarrollo de la persona, de la sociedad y de la herencia cultural de la comunidad, mediante la docencia, la investigación y la extensión.

164

VISIÓN:

Ser reconocida como una Universidad Católica, de vanguardia y responsable socialmente. Para ello debe: o Estar en el grupo de Universidades de avanzada del Sistema Nacional de

Educación Superior.

o Formar personas íntegras, innovadoras y emprendedoras.

o Ser una comunidad de aprendizaje, de creación y transmisión de conocimientos, articulando vínculos entre estudiantes, académicos y funcionarios, mediante políticas y prácticas que permitan el desarrollo de las personas.

ESTRUCTURA ORGANIZACIONAL:

La Estructura Organizacional, está conformada por: el Gran Canciller (máxima autoridad eclesiástica), el Consejo Superior y el Rector, quien tiene a su cargo las Vicerrectorías Académica, de Asuntos Económicos y Administrativos, la Vicerrectoría Sede Coquimbo, la Secretaría General, Auditoría General, Dirección de Comunicaciones y Extensión, Dirección de Relaciones Institucionales y las Facultades de las distintas Carreras. Las relaciones de dependencia se ilustran en el organigrama de la Figura 5.4.

Los profesionales que se desempeñan en los diferentes cargos son:

o Gran Canciller: Monseñor Pablo Lizama Riquelme.

o Vice Gran Canciller: Padre André Marie René Hubert.

o Rector: Dr. Misael Camus Ibacache

o Vicerrector Académico: Sr. Mario Pereira.

o Vicerrector de Asuntos Económicos y Administrativos: Sr. Marcelo Leonardo Lufin Varas.

o Vicerrector de Sede: Sr. Luis Héctor Moncayo Martínez.

o Secretario General: Sra. Victoria Gonzáles Stuardo.

o Auditor General: Sr. Orlando Darío Castro Campusano.

o Director de Comunicación y Extensión: Sra. Giannina Silvana Marré Guzmán.

o Director de Relaciones Institucionales de la Universidad: Sra. Dania Tristá Pérez.

La Universidad Católica del Norte cumple las funciones académicas de docencia, investigación y extensión a través de sus Facultades y otros organismos que establece el Consejo Superior.

165

Gran Canciller Departamento de Pastoral Universitaria

Antofagasta - Coquimbo

Comité Asesor de Administración y Finanzas

Secretaría General

Dirección de Comunicación y Extensión

Dirección de Relaciones Institucionales de la Universidad

Rector

Consejo Superior

Facultades:Arquitectura, Construcción Civil e Ingeniería CivilCienciasCiencias del MarEconomía y AdministraciónHumanidadesIngeniería y Ciencias Geológicas

Auditoría General

Vicerrectoría Académica:Dirección General de DocenciaDirección General de Investigación y Post-GradoDirección General EstudiantilDirección de EstudiosBiblioteca y Documentación

Vicerrectoría de Asuntos Económicos y Administrativos:Dirección de FinanzasDirección de Recursos HumanosDirección de Servicios y ObrasDirección de InformáticaDirección de EstudiosDirección de Proyectos e InfraestructuraAdministración F.S.C.U.

Vicerrectoría Sede Coquimbo:Secretaría de SedeAdmisión y Registro CurricularAsuntos EstudiantilesBibliotecaDirección de Administración y Finanzas

Figura No. 5.4. Organigrama Universidad Católica del Norte

Las Facultades son unidades académicas que, en conformidad con el Estatuto y los Reglamentos de la Universidad, agrupan a un cuerpo de personas asociadas con el propósito de enseñar e investigar en una misma área o en áreas afines del conocimiento superior. Cada Facultad está dirigida por un Decano y tiene como organismo colegiado un Consejo de Facultad. Las actividades de los organismos académicos distintos a las Facultades, se desarrollan dentro del marco que fijan los Reglamentos y atribuciones de los Consejos respectivos cuando corresponda. Un Reglamento especial dictado por el Rector con acuerdo del Consejo Superior, establece los procedimientos para elegir los cargos de Decanos y Directores, como asimismo, la integración y atribuciones de los Consejos respectivos cuando corresponda.

OBJETIVOS ESTRATÉGICOS:

1. Desarrollar y posicionar un Proyecto Educativo distintivo de la UCN.

2. Fortalecer capacidades para la adquisición, creación y transferencia de conocimiento y tecnología.

3. Promover el sentido de pertenencia de la comunidad universitaria y la identidad de la institución.

4. Vincular a la Universidad con su entorno, como un actor influyente en el desarrollo del bienestar de las personas y de la sociedad.

166

5. Desarrollar un modelo de gestión de los recursos, capacidades y competencias de la UCN.

PROPUESTA DE VALOR:

o Formación de profesionales, investigación, extensión y asistencia técnica MERCADO:

La Universidad Católica del Norte, no tiene un segmento definido de clientes objetivo, sí se puede mencionar, que existen perfiles y preferencias, como por ejemplo, estudiantes provenientes de la Segunda Región de Antofagasta y empresas regionales fundamentalmente relacionadas con la actividad minera.

5.3.2. Fase de identificación de requisitos organizacionales. La segunda fase del Framework propuesto (figura 5.5), corresponde a la fase de identificación de los requisitos organizacionales.


Produce

MISIÓN


METAS


REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 5.5. Identificación de Requisitos Organizacionales (elaboración propia).

La figura 5.6, ilustra la secuencia de pasos que deben seguirse para el desarrollo de esta segunda fase.

Figura No. 5.6. Actividades presentes en la fase de definición de Requisitos Organizacionales (elaboración propia).

167

Como primera actividad, se identifican a los principales actores que participarán del proyecto. El conjunto inicial de participantes como es lo habitual, está conformado por un conjunto multidisciplinario de profesionales entre los que se pueden destacar:

o Patrocinador: Unidad para la cual se desarrolla el proyecto. Tiene como función principal, coordinar que los recursos requeridos por los ejecutantes del proyecto, estén disponibles de acuerdo al plan de trabajo propuesto. Esta unidad la constituye la Vicerrectoría Académica, representada por el Auditor General de la Universidad, Señor Orlando Castro.

o Experto en el dominio de negocio: Tiene a su cargo la conducción del proceso de definición de los requisitos organizacionales asesorando además sobre las fuentes de datos que deben ser utilizadas en el proyecto. Este experto es el Jefe del Departamento de Gestión Académica, Sr. Santiago Sánchez Varela, de la Dirección General de Docencia.

o Equipo de desarrollo del proyecto: Personal que tiene a cargo la responsabilidad de planificar y ejecutar el proyecto. Tal equipo está formado inicialmente por los Señores: Carlos Díaz M. y Luis Salinas D.

o Administrador de las bases de datos: Profesional de la dirección de Informática de la Universidad Católica del Norte.

Una vez conformado el equipo inicial de participantes en el desarrollo del proyecto, la siguiente actividad fue la planificación de un conjunto de reuniones a objeto de discutir las materias pertinentes relacionadas con el dominio de negocio, procesos importantes en docencia y materias relativas a Data Mining y Data Warehouse. Aspectos que son importantes de destacar y que se perciben en el conjunto inicial de reuniones son, la escasa disponibilidad de tiempo para programar reuniones conjuntas y el hecho de que no se tiene real claridad acerca del problema que se desea resolver, ni mediante que tipo de herramientas o sistemas. La tercera actividad desarrollada, fue la definición de los objetivos general y especifico, que deben ser apoyados por el desarrollo del proyecto. De entre los objetivos ya identificados en la fase inicial de comprensión del dominio de negocio y luego de diversas discusiones, se establece que el objetivo estratégico origen del problema es el siguiente: “Desarrollar un modelo de gestión de los recursos, capacidades y competencias de la Universidad Católica del Norte”, más concretamente, se requiere obtener información que permita tomar decisiones eficaces, tendientes a, “Mejorar los sistemas de evaluación de la actividad académica y de apoyo a la academia y el control de gestión de los recursos financieros y materiales de la UCN”. Materias concretas relacionadas con el problema definido, son las relacionadas con las tasas de egreso/ingreso y el tiempo de permanencia de los estudiantes en las diversas carreras que imparte la Universidad. La idea es contribuir con la generación de conocimiento e información, que permita determinar las causales de la baja tasa de egresos/ingresos y el elevado tiempo de permanencia en la universidad, para posteriormente determinar las medidas remediales más adecuadas. Los objetivos definidos, se materializan mediante la definición de los siguientes requisitos organizacionales:

168

Requisitos organizacionales generales:

“Identificar y analizar las variables que afectan la Tasa de Titulación y Tiempo de Permanencia de un estudiante en la Universidad Católica del Norte”.

Para ello se analizará el Avance Curricular que se observa en las respectivas cohortes, con el objeto de poder intervenir “oportunamente” y mejorar las Tasas y Tiempos de Titulación.

Requisitos organizacionales específicos:

1. Identificar las causas de las eliminaciones académicas y deserciones que se observan en las cohortes.

2. Confirmar si el perfil de los estudiantes influye directamente en su desempeño académico: Puntaje Prueba de Selección (PSU), Notas de Enseñanza Media (NEM), Tipo de Colegio, Quintil, entre otros.

3. Identificar patrones de comportamiento o tendencias en ciertas asignaturas.

4. Validar si la eliminación del ciclo básico se debe a las asignaturas de ciencias básicas.

5. Ponderar el efecto de la eliminación del ciclo básico y del ciclo profesional en la titulación oportuna.

Una vez definidos los requisitos organizacionales iniciales, se procede a definir el alcance del proyecto y en especial la carrera que será objeto de estudio, que corresponde a la carrera de Ingeniería Civil Industrial, fundamentalmente por el hecho de que esta carrera, a diferencia de otras, cuenta con ingreso directo de estudiantes. El ingreso de estudiantes a otras carreras es por la vía de planes comunes. Finalmente, a medida que se cumplieron las diversas actividades que conforman esta segunda fase, se constató la utilización de diversos términos propios del dominio de negocio, los cuales fueron registrados. Información relativa a la terminología registrada, así como también de toda la información tratada y recolectada en las diversas reuniones efectuadas, se adjuntan en el anexo B. 5.3.3. Fase de construcción del modelo de negocios decisional. La tercera fase del proceso de construcción del documento de requisitos del proyecto (figura 5.7), corresponde al desarrollo de un modelo de negocios decisional, que tiene como metas principales, identificar a los actores involucrados en la concreción de las metas organizacionales ya definidas, identificar la red de dependencias que existe entre estos actores y la identificación de las metas de logro que deben ser satisfechas por el proyecto de Data Mining a desarrollar. Para estos efectos, se procede a la ejecución del conjunto de actividades que componen esta fase y que se ilustran en la figura 5.8. Paso 1. Identificación de la meta origen del proceso decisional. De la información elicitada en la fase de definición de los requisitos organizacionales, se desprende que la meta origen del proceso decisional, es la materialización de uno de los objetivos estratégicos planteados por la organización: “Desarrollar un modelo de gestión de los recursos, capacidades y competencias de la UCN”. Este objetivo

169

estratégico, se traduce en el cumplimiento de un conjunto de objetivos específicos, entre los que se encuentra el directamente relacionado al desarrollo del proyecto: "Mejorar los sistemas de evaluación de la actividad académica y el control de gestión de los recursos financieros y materiales de la UCN".


Produce

MISIÓN


METAS


objetivos asociados

REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR

Descripción de la competencia , socios y

colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 5.7. Modelo de Negocio Decisional (elaboración propia).

Figura No. 5.8. Actividades del proceso de Modelado de Negocio Decisional (elaboración propia).

Por lo tanto, se acuerda que la meta origen del proceso decisional, es el materializar la evaluación de la actividad académica, con el fin de realizar las intervenciones correspondientes a la luz de los resultados de la evaluación. La información que se obtenga, se estima que es fundamental como apoyo para concretar la finalidad de: "Integrar los sistemas de control de gestión vigentes, que sirvan como herramienta de control para la planificación estratégica y como indicadores de gestión de la Institución".

Paso 2. Actores que participan del proceso decisional. En esta etapa, se procede inicialmente a identificar a los actores que intervienen directamente (actores primarios) en el proceso decisional relacionado con la adopción

170

de las medidas pertinentes, tendientes a mejorar las tasas de egreso/ingreso y disminuir el tiempo empleado por un estudiante en la obtención de un título profesional. Posteriormente se identifican a los actores secundarios, que son los actores que desempeñan roles de importancia para suministrar la información o el conocimiento requerido por los actores primarios. La tabla 5.1 describe a los actores participantes del proceso.

Tabla 5.1. Stakeholders involucrados en el proceso decisional

ROL TIPO DE ACTOR Vicerrector Académico Primario

DGD (Dirección General de Docencia) Secundario CIMET (Centro de Innovación Metodológica y Tecnológica) Secundario

Unidad de Análisis Institucional (UAI) Secundario Jefe Dpto. Gestión Académica Secundario

Unidad Académica Secundario

Paso 3. Información o conocimiento que se precisa para la toma de decisiones. En esta tercera etapa, se debe descubrir la información o conocimiento que requieren los actores primarios para poder tomar las decisiones; esta información posteriormente se considera como origen de los potenciales casos de uso del sistema a proyectarse. De acuerdo a la información elicitada, la decisión de sobre cuáles serán las medidas que se adopten para mejorar las tasas de egreso/ingreso y disminuir los tiempos de titulación, dependen de la siguiente información o conocimiento.

1. Análisis académico presentado por la Dirección General de Docencia, que describa las causas de atraso en la titulación oportuna en alumnos de pregrado.

2. Análisis de impacto, en base a la propuesta académica de la Dirección General de Docencia (DGD) por parte de la Unidad de Análisis Institucional (UAI).

Paso 4. Fuentes de datos. Luego de elicitar la información o conocimiento requerido por los actores primarios, para el proceso de toma de decisiones, se procede a identificar las fuentes origen de los datos necesarios, para soportar el proceso de obtención de la información definida en el punto anterior. Estas fuentes de datos, son las definidas en una primera instancia (al momento de iniciarse el estudio) y en principio son:

1. Las distintas cohortes de la Carrera de Ingeniería Civil Industrial (ICI).

2. Datos de los académicos involucrados en las Cohortes que se definan para la carrera de Ingeniería Civil Industrial.

Paso 5. Red de dependencias entre los diversos actores organizacionales. Esta etapa consiste en la construcción de un árbol de refinamiento de metas, en el cual se definen las principales metas, operaciones derivadas, actores que participan en el cumplimiento de metas y el nivel de dependencia entre ellos.

171

La tabla 5.2 representa el árbol de refinamiento de metas para el caso en estudio. La primera columna, muestra en forma jerárquica las metas identificadas (el orden en el que se ubican, indica la precedencia que existe entre ellas), en el primer nivel la meta más general, luego las metas de logro que existan y finalmente las operaciones derivadas. La segunda columna indica el tipo de meta, u operación o recurso disponible. La tercera columna muestra los actores involucrados en el logro de metas y ejecución de operaciones.

Tabla 5.2. Descripción del árbol de refinamiento de metas para el caso de estudio.

NOMBRE DE LA META TIPO ACTORES INVOLUCRADOS

EVALUACIÓN DE ACTIVIDAD ACADÉMICA MG

DGD - UAI - JEFE GESTIÓN ACADÉMICA - VICERRECTOR ACADÉMICO - CIMET -

UNIDAD ACADÉMICA

1. IDENTIFICAR CAUSAS DE RETRASO ML CIMET- JEFE DE GESTIÓN ACADÉMICA

1.1 Patrones de retraso Oper JEFE DE GESTIÓN ACADÉMICA 1.2 Perfil del estudiante Oper JEFE DE GESTIÓN ACADÉMICA 1.3 Responsabilidad ciclo básico Oper JEFE DE GESTIÓN ACADÉMICA 1.4 Tendencia en asignaturas Oper JEFE DE GESTIÓN ACADÉMICA 1.5 Efecto ciclo básico y profesional Oper JEFE DE GESTIÓN ACADÉMICA 1.6

Proporcionar información sobre patrones.

Oper

CIMET- JEFE DE GESTIÓN ACADÉMICA

2. ESTUDIO COMPETENCIA ML DGD-CIMET

2.1 Estudio de veracidad Oper CIMET 2.2 Generar propuesta Oper CIMET 2.3

Enviar estudio de competencia

Oper

DGD-CIMET

3. ANÁLISIS ACADÉMICO ML VICERRECTOR ACADÉMICO - DGD

3.1 Análisis docente Oper DGD 3.2 Generar propuesta Oper DGD 3.3

Enviar análisis académico

Oper

VICERRECTOR ACADÉMICO – DGD

4. ESTUDIAR IMPACTO DEL ANÁLISIS ACADÉMICO ML VICERRECTOR ACADÉMICO - UAI

4.1 Analizar impacto de análisis académico Oper UAI 4.2 Generar propuesta Oper UAI 4.3

Enviar análisis de impacto

Oper

VICERRECTOR ACADÉMICO – UAI

5. SOLICITUD DE ESTUDIO ACADÉMICO ML DGD-UAI

5.1 Solicitud estudio Oper DGD-UAI 5.2 Estudio docente Oper DGD 5.3

Enviar estudio académico

Oper

UAI-DGD

6. SOLICITUD ESTUDIO COMPETENCIA ML CIMET-UAI

6.1 Solicitud estudio Oper CIMET-UAI 6.2 Estudio veracidad Oper CIMET 6.3

Enviar estudio

Oper

UAI-CIMET

7. SOLICITUD ESTUDIO DE CAUSAS DE RETRASO ML JEFE GESTIÓN ACADÉMICA - UAI

172

NOMBRE DE LA META TIPO ACTORES INVOLUCRADOS 7.1 Solicitud estudio Oper JEFE GESTIÓN ACADÉMICA - UAI 7.2 Estudio patrones Oper JEFE DE GESTION ACADÉMICA 7.3

Enviar estudio

Oper

UAI - JEFE DE GESTION ACADÉMICA

8. ESTUDIO DE COSTES ML UAI - VRE 8.1 Proporcionar informe de impacto Oper VRE-UAI 8.2 Estudio costes asociados Oper VRE 8.3

Enviar informe de costes asociados.

Oper

UAI-VRE

9. SOLICITUD PARA EVALUAR PROPUESTA ML UNIDAD ACADÉMICA - VICERRECTOR

ACADÉMICO

9.1 Proporcionar informe de propuesta Oper UNIDAD ACADÉMICA - VICERRECTOR ACADÉMICO

9.2 Analizar medida Oper UNIDAD ACADÉMICA 9.3

Informar medida

Oper

VICERRECTOR ACADÉMICO - UNIDAD ACADÉMICA

Paso 6. Creación del modelo de proceso decisional.

A continuación se presenta la secuencia de actividades que deben ejecutarse para desarrollar el Modelo de Negocios Decisional, que representa el problema tratado en el caso de estudio ya descrito. Este modelo está compuesto por los modelos de dependencias estratégicas y de razones estratégicas. El modelo es construido siguiendo el proceso incremental propuesto en el capítulo anterior y representado por la figura 5.9. La técnica utilizada es la técnica denominada “Framework i*”.

Figura No. 5.9. Fases del proceso construcción del modelo (elaboración propia).

173

Modelo de dependencias estratégicas.

Fase 1. En esta fase y a partir del árbol de refinamiento de metas (tabla 5.2), se construye el modelo de primer nivel, en el cual sólo se identifican a los actores organizacionales que participan del proceso y la red de dependencias de meta que los ligan. La figura 5.10, ilustra la notación empleada en la construcción de este modelo y del resto de los modelos.

Figura No. 5.10. Primitivas básicas del Framework i* (elaborado en base a [Yu, 2001]).

La figura 5.11 muestra el modelo resultante de la fase 1, su interpretación es la siguiente: El Actor CIMET, depende de que el Jefe de Gestión Académica identifique las causas de retraso de los estudiantes de una carrera. Posteriormente la DGD, depende de que el CIMET realice el estudio de competencias en base a los patrones identificados por el Jefe de Gestión Académica. El Vicerrector Académico, tiene dependencia de la DGD para realizar un análisis académico en base a la propuesta realizada por el CIMET. El Vicerrector Académico, también depende de la Unidad de Análisis Institucional (UAI), concretamente, de que esta última realice un estudio de impacto sobre el análisis académico realizado. El actor Unidad de Análisis Institucional, debe realizar un estudio de costes, lo cual implica una dependencia con la Vicerrectoría Económica (VRE) para concretar dicha meta. Finalmente, en base a los dos análisis obtenidos, uno proveniente de la DGD y el otro de la Unidad de Análisis Institucional, el Vicerrector Académico puede plantear una propuesta a la Unidad Académica que corresponda, lo cual implica que este último actor, depende de que el Vicerrector Académico realice la solicitud de evaluación correspondiente para tomar alguna medida de intervención.

174

Se debe también considerar, que el actor UAI, actúa de dependee en solicitudes realizadas por los actores DGD, CIMET y Jefe Gestión Académica, esto, por cuanto la UAI puede también identificar causas de retraso que lleven a requerir de las competencias de CIMET y DGD.

Figura No. 5.11. Modelo de Dependencias Estratégicas de primer nivel (elaboración propia).

Fase 2. En esta segunda fase, se incluyen en el modelo desarrollado en la fase 1, las tareas originadas por cada meta de logro y los recursos involucrados. La figura 5.12 muestra el modelo resultante, su interpretación es la siguiente: El proceso se gatilla por la necesidad del jefe de gestión académica de identificar información (patrones) que le corroboren ciertas hipótesis respecto de las razones o causas que determinan el que los estudiantes de pregrado, no concluyan sus carreras en los plazos oficiales establecidos. Una vez identificada la información requerida, se genera un informe, el cual es posteriormente enviado al CIMET para que esta unidad, realice un estudio de competencias. Una vez realizado este estudio, CIMET genera una propuesta, la cual es remitida a la DGD para que esta última a su vez, realice un análisis académico. Terminado este análisis se envía la propuesta al vicerrector académico y a la Unidad de Análisis Institucional (UAI). La Unidad de Análisis Institucional realiza un estudio de impacto sobre la propuesta generada por la DGD, para lo cual se apoya en la Vicerrectoría Económica (VRE) para que ésta realice dicho estudio. Terminado el estudio y enviado el informe de costes desde VRE a la UAI, esta última envía el análisis de impacto al Vicerrector Académico el cuál con la propuesta de la DGD y la UAI procede a tomar una decisión, proponiendo determinadas medidas de intervención que son enviadas a la Unidad Académica que

175

corresponda. La Unidad Académica evalúa dicha propuesta y analiza si la puede ejecutar con los recursos disponibles. Cabe mencionar además, que la UAI puede solicitar en cualquier momento a la DGD, CIMET o Jefe de Gestión Académica que realicen un estudio según sus competencias.

VICERRECTOR ACADÉMICO

CIMET

UNIDAD ACADÉMICA

JEFE GESTIÓN

ACADÉMICA

D

D

D

ESTUDIO COMPETENCIA

D

IDENTIFICAR CAUSAS

SOLICITUD PARA EVALUAR

PROPUESTA

D

D

INFORME PROPUESTA

INFORME

PATRONESD

D

D

D

DD

PROPORCIONAR INFORME DE PROPUESTA

D D

PROPORCIONAR INFORMACIÓN

DD

ENVIAR ESTUDIO DE

COMPETENCIA

D

D

JUSTIFICACIÓN

D D

INFORMAR MEDIDA

D D

DGDUNIDAS DE ANÁLISIS

INSTITUCIONAL

ESTUDIO DE IMPACTO DEL

ANÁLISIS ACADÉMICO

ENVIAR ANÁLISIS DE

IMPACTOINFORME

PROPUESTA

D

DDDDD

INFORME PROPUESTA

ENVIAR ANÁLISIS

ACADÉMICO

ANÁLISIS ACADÉMICO

D

D

D

DD

D

VRE

SOLICITUD ESTUDIO

ACADÉMICOD D

SOLICITUD ESTUDIO

ENVÍA ESTUDIO

ACADÉMICO

INFORME DEESTUDIO

D D

D

D

D

D

SOLICITUD ESTUDIO

COMPETENCIA

SOLICITUD ESTUDIO

ENVÍA ESTUDIO

INFORMEDE ESTUDIO

DD

DD

D

D DD

SOLICITUD ESTUDIO DE CAUSAS DE RETRASO

INFORME DE ESTUDIO

ENVÍA ESTUDIO

SOLICITUD ESTUDIO D

D

D

D

D

D

D

D

ESTUDIO DE COSTE

PROPORCIONAR INFORME DE

IMPACTO

ENVÍA INFORME DE COSTE

DD

D

D

DD

INFORME DE COSTES

ASOCIADOS

INFORME DE ANÁLISIS DE

IMPACTO

DD

D

D

Figura No. 5.12. Modelo de Dependencias Estratégicas de segundo nivel (elaboración propia).

Fase 3. La construcción de este tercer modelo (modelo de dependencias estratégicas final), contempla la incorporación del actor sistema, al cual se asignarán todas las tareas o actividades en las cuales se requiere el apoyo de un sistema computacional. Luego en el modelo desarrollado, estas tareas se convierten en nuevas metas de logro que se ligan al actor sistema. En el modelo de Dependencias Estratégicas de segundo nivel (figura 5.12) se observa que las tareas que precisan ser automatizadas, son las relacionadas con la meta de logro definida entre los actores Jefe de Gestión Académica y CIMET y que tiene que ver con la identificación de información respecto de:

176

1. Identificación de las causas de las eliminaciones académicas y deserciones que se observan en la cohortes.

2. Confirmación de si el perfil de los estudiantes influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, Quintil, entre otros).

3. Identificación de patrones de comportamiento o tendencias en determinadas asignaturas.

4. Confirmación de si la eliminación en el ciclo básico, se debe a las asignaturas de ciencias básicas.


Hechas las consideraciones anteriores, la figura 5.13 ilustra el modelo resultante.

Figura No. 5.13. Modelo de Dependencias Estratégicas de tercer nivel (elaboración propia).

Modelo de razones estratégicas.

Para proseguir con el proceso de modelado, ahora se procede a construir el modelo de razones estratégicas, en el cual se pretende representar y especificar con mayor nivel de

177

detalle, las razones de la dependencia entre los diferentes actores organizacionales y su descomposición funcional. Fase 4. Para el caso de estudio y en una primera instancia, a objeto de contar con una visión de más alto nivel del modelo, el modelado se realiza a partir del modelo de dependencias estratégicas de segundo nivel (figura 5.12), el cual no incorpora al actor sistema.

Figura No. 5.14. Modelo de Razones Estratégicas (elaboración propia).

En este modelo (figura 5.14), se mapean las metas de logro (que formaban parte de las ligas de dependencias) del modelo de dependencias estratégicas, en tareas de alto nivel. Estas tareas en función de su nivel de complejidad, pueden ser descompuestas mediante el constructor “task-descomposition”, en tareas menos complejas o en operaciones elementales que puedan ser desarrolladas por algún actor en particular. Si existiese más

178

de una alternativa para lograr una meta o tarea, se utiliza para su representación el constructor “means-end”. Se debe considerar también, que cada recurso involucrado en el proceso, da origen a la especificación de las operaciones de envío y recepción del recurso, en el actor “Depende” y en el actor “Depender” respectivamente.

Como se recordará, en el caso de estudio tratado, la meta general es la evaluación de la actividad académica. Esta meta general, desencadena una serie de tareas, entre las cuales se encuentra el estudio de las causas de retraso en la duración de una carrera universitaria (Ingeniería Civil Industrial como caso particular). Este estudio, que en el modelo de dependencias estratégicas, es una meta de logro (dependum) que liga a los actores Unidad de Análisis Institucional (dependee de la relación) y Jefe de Gestión Académica (depender), dentro del campo de acción del actor Unidad de Análisis Institucional, involucra la tarea de alto nivel, solicitar estudio causas de retraso. Consecuentemente, el actor Jefe de Gestión Académica, es el encargado de realizar el estudio, por lo tanto en su campo de acción se origina la tarea identificar patrones (causas), la que a su vez, genera ligas de dependencia de subtareas y recursos como por ejemplo el envío de resultados (patrones) y el recurso informes.

VICERRECTOR ACADÉMICO

CIMET

UNIDAD ACADÉMICA

JEFE GESTIÓN

ACADÉMICA

PATRONES

DISCUSIÓN DE MEDIDA

ENVIARPROPUESTA O

ESTUDIO

EVALUACIÓN DE ACTIVIDAD

ACADÉMICA

TOMA DESISCION

Unk

now

n

ANALIZAR PROPUESTA

OccupiesESTUDIO

VERACIDAD

RECIBE CONFIRMACIÓN

Occupies

ENVÍA MEDIDA

Make

REDACTA MEDIDA

MakeC

over

s

RECIBE PROPUESTA

INFORME PROPUESTA

DOCENTE

D

RECIBE PATRONES

Covers

REDACTA PROPUESTA

Mak

e

REALIZA ESTUDIO VERACIDAD

(COMPETENCIAS)

Occupies

Make

INFORME PROPUESTA

Covers

INFORME PROPUESTA

D

PATRONES PARA EL ESTUDIO

ENVÍA PATRONESO ESTUDIO

IDENTIFICAR PATRONES

D

D

DATOS DE CAUSAS

DEL RETRASO

Make

INFORME PATRONES

Covers

RECIBE MEDIDA

CONSULTA FUNDAMENTOS

D

MEDIDA A TOMAR

D CoversFUNDAMENTOS

DE MEDIDA

INFORME DE MEDIDAS A TOMAR O RECOMENDACIONES

ENVÍA INFORME MEDIDA

Make

INFORME MEDIDA

D

D

DGD

INFORME PROPUESTA

ENVIARPROPUESTA O

ESTUDIO

RECIBE PROPUESTA

REDACTA PROPUESTA O

ESTUDIO

ANÁLISIS DOCENTE

INFORME PROPUESTA O

ESTUDIO

Covers

Make

Mak

e

OccupiesCovers

D

PROPUESTA 1

INFORME ANÁLISIS IMPACTO

D

Cover

s

ENVIARPROPUESTA O

INFORME

SOLICITA ESTUDIO

ACADÉMICO

REDACTA PROPUESTA

ANALISIS DE IMPACTO

INFORME PROPUESTA

UNIDAD DE ANÁLISIS

INSTITUCIONAL

Covers

Make

Make

PROPUESTA 2D

D

SOLICITA ESTUDIO DE

COMPETENCIA SOLICITA ESTUDIO CAUSAS

RETRASO

Make

Make

Make

RECIBE ESTUDIOSINFORME

ESTUDIO

D

D

INFORME ESTUDIO INFORME

ESTUDIO

D

D

D

D

VRE

ESTUDIO DE COSTES

RECIBE INFORME

Covers

INFORME DE IMPACTO

ENVÍA INFORME MEDIDA

INFORME DE ANÁLISIS IMPACTO

DD

INFORME DE COSTES

ASOCIADOSCoversINFORME DE COSTES

ASOCIADOS

RECIBE INFORME DE

COSTES

Occupies

Make

D

D

Occ

upie

s

RELACIONAMIENTO

VERIFICACIÓN

DESCUBRIMIENTOPREPARAR

DATOS

GENERAR MODELOS

DESPLEGAR RESULTADOS

Cov

ers

Or

Or

SISTEMA

TENDENCIA EN ASIGNATURAS

PERFIL DEL ESTUDIANTE

RESPONSABILIDAD CICLO BÁSICO

EFECTO CICLO BÁSICO Y

PROFESIONAL

IDENTIFICAR EFECTO CICLO

BÁSICO Y PROFESIONAL

Mak

e

DATOS ALUMNOS

PREGRADO Y ACADÉMICOS

Mak

e

Mak

e

Mak

e

Mak

e

ANÁLISIS RESPONSABILIDAD

CICLO BÁSICO

ANÁLISIS PERFIL DEL

ESTUDIANTE

IDENTIFICAR PATRÓN DE RETRASO

IDENTIFICAR TENDENCIA EN ASIGNATURAS

PATRÓN DE RETRASO

REDACTA INFORME

Make

Covers

Occ

upie

s

Mak

e

AndAnd

And

And

And

Or

Occupies

Occupies

Or

Or

Or

Occupies

Figura No. 5.15. Modelo de Razones Estratégicas con actor Sistema incorporado (elaboración propia).

179

Fase 5. El proceso de modelado concluye con la construcción del modelo de razones estratégicas en el cual se incorpora al actor Sistema (figura 5.15). En este modelo, se asignan al Sistema, todas las tareas que requieren ser automatizadas y que en el modelo de dependencias estratégicas (figura 5.13), constituían metas de logro. En forma previa a la construcción de este modelo, se debe realizar una descomposición más granular de las tareas de alto nivel que deben ser automatizadas, por lo tanto, este modelo se construye en función del modelo de dependencias estratégicas de tercer nivel.

Luego, en el campo de acción del actor Sistema, las metas de logro del Modelo de Dependencias Estratégicas de tercer nivel (influencia del perfil del estudiante, tendencias en asignaturas, identificar patrón de retraso, grado responsabilidad ciclo básico, efecto ciclo básico y profesional), se mapean en tareas de alto nivel (análisis perfil del estudiante, identificar tendencia en asignaturas, identificar patrón de retraso, análisis responsabilidad ciclo básico, identificar efecto ciclo básico y profesional). A su vez, cada una de estas tareas, puede descomponerse en tareas más específicas en función del tipo de recursos con que se cuenta y el nivel de especialización de cada problema.

Otro aspecto a considerar es, que es posible explicitar las diversas alternativas que pueden considerarse para el cumplimiento de una meta o tarea. En el caso de estudio, se ha indicado por ejemplo, que las tareas involucradas en el análisis del perfil del estudiante, pueden lograrse mediante modelos de verificación o descubrimiento.

Finalmente se debe destacar, que el proceso de modelado de negocios descrito, es un proceso de tipo incremental e iterativo, pues en función de las posteriores actividades, propias de un proceso de Ingeniería de Requisitos, es muy probable que nuevamente los modelos deban ser revisados.

5.3.4. Fase de construcción del modelo de requisitos.

La construcción del Modelo de Requisitos figura 5.16, se desarrolla en una secuencia de tres pasos como se describe en la figura 5.17. En los pasos uno y dos se identifican a los actores de los casos de uso y los casos de uso respectivamente, tomando como entrada el modelo de dependencias estratégicas. En el tercer paso se describen los escenarios de los casos de uso, considerando la información derivada del modelo de razones estratégicas.

Paso 1. Identificación de los Actores del Sistema. A partir del modelo de dependencias estratégicas de tercer nivel (figura 5.13), se identifican los siguientes actores de casos de uso: Unidad de Análisis Institucional, Jefe de Gestión Académica, Unidad Académica y Dirección General de Docencia.

• El actor Unidad de Análisis Institucional es un potencial actor, debido a que existen ligas de dependencias con el actor Sistema, mediante la meta de logro consulta de resultados.

180

• El actor Unidad Académica es un potencial actor, debido a que existen ligas de dependencias con el actor Sistema, mediante la meta de logro consulta de resultados.


Produce

MISIÓN


METAS


REGLAS DE NEGOCIO


externas

PROPUESTA DE VALOR


MERCADO


características

RED DE VALOR


colaboradores





CAPACIDADES




valor

GLOSARIO


dominio de negocio



RECURSOS


materiales


Matriz FODA

RESTRICCIONES


RIESGOS


contingencias

FCE


Éxito

Dirigido a un

Tiene asociada una

Define

Definidas por

Define

Para el logro

Precisa de

Apoyan

Adopta una

Utiliza

Precisa

Cuenta con

Restringen Logro de

LimtanPara el

Logro de

EXPECTATIVAS


esperan lograr


Figura No. 5.16. Modelo de requisitos (elaboración propia).

Salida

PASO 1Identificación de

Actores del Sistema

PASO 2

Identificación de los Casos de Uso

PASO 3Descripción de los

escenarios de Casos de Uso

Actores de los Casos de Uso

Listado de Casos de Uso

Descripción textual de cada Caso de

Uso

Entrada Entrada

Modelo de Dependencias Estratégicas

Entrada

Modelo de Razones Estratégicas

Salida Salida

Figura No. 5.17. Actividades en el modelado de los requisitos (elaborado en base a [Santander, 2002]).

• El actor Dirección General de Docencia (DGD) es un potencial actor, debido a que existen ligas de dependencias con el actor Sistema, mediante la meta de logro consulta de resultados.

• El actor Jefe de Gestión Académica es un potencial actor, debido a que existen ligas de dependencias con el actor Sistema, mediante las metas de logro: identificar patrón retraso, tendencia en asignaturas, grado de responsabilidad ciclo básico, efecto del ciclo básico y ciclo profesional, influencia del perfil del estudiante.

181

No existe ninguna liga de dependencia entre los actores, Vicerrector Académico, Vicerrector Económico y CIMET, con el sistema, por lo tanto estos no son actores para el modelo de casos de uso. Paso 2. Identificación de los Casos de Uso. Una vez identificados los actores potenciales y a partir del modelo de dependencias estratégicas de tercer nivel (figura 5.13), se identifican las relaciones de dependencia que posean los actores, separando éstas según su tipo de liga de dependencia (depender o dependee). Pueden identificarse los siguientes casos de uso:

1. Considerando la identificación de ligas de dependencias de meta, en las que los actores ya identificados, actúan como dependee en la liga de dependencia:

Actor: Unidad Análisis Institucional. Objetos de la dependencia: Análisis de impacto del análisis académico. Actor: Dirección General de Docencia. Objetos de la dependencia: Análisis académico. Actor: Jefe de Gestión Académica. Objetos de dependencia: Identificación de causas de retraso.

2. Considerando la identificación de ligas de dependencias de meta, en las cuales los actores actúan como depender en la liga de dependencia con el actor Sistema:

Actor: Unidad Análisis Institucional. Objeto de dependencia: Consulta Resultados. Actor: Unidad Académica. Objeto de dependencia: Consulta Resultados. Actor: Dirección General Docente. Objeto de dependencia: Consulta Resultados. Actor: Jefe de Gestión Académica. Objeto de dependencia: Influencia del perfil del estudiante, tendencia en asignaturas, identificar patrón de retraso, grado de responsabilidad del ciclo básico, efecto ciclo básico y profesional.

Una vez identificadas las ligas de dependencia, se procede a construir el diagrama de casos de uso (figura 5.18), con el objeto de comprender cómo se relacionan los actores con el sistema.

Paso 3. Descripción de los Escenarios de Casos de Uso. Para completar el modelado de casos de uso, se procede a redactar un modelo de descripción para cada caso de uso identificado, utilizando algún tipo de plantilla o variante de ella, de entre las múltiples que se proponen en la literatura, como por

182

ejemplo las propuestas en Volere [Robertson, 1999], o [Larman, 2002]. En la descripción a realizar, es importante destacar las intenciones de los actores, así como también las responsabilidades asociadas al sistema. De esta forma se podrá explicitar, cuándo los actores solicitan servicios o proveen recursos al sistema y cuándo el sistema entrega información al actor del sistema.

Figura No. 5.18. Diagrama de Casos de Uso para el Caso de Estudio

La información que se requiere para la descripción de los casos de uso, se puede obtener del Modelo de Razones Estratégicas (figura 5.15). Las tablas 5.3 a 5.9, muestran la descripción textual de los Casos de Uso definidos en el diagrama de la figura 5.18.

Tabla 5.3. Caso de Uso: Verificar Influencia del Perfil del Estudiante

Caso de Uso

Verificar Influencia del Perfil del Estudiante Autor: Carlos Díaz, Luis Salinas ID: RQ_003 Tipo: DM Fecha de Creación: 15/08/08 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite verificar si el perfil de los estudiantes, influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, Quintil, entre otros).

Actor Primario Jefe de Gestión Académica Actor Secundario

183

Caso de Uso

Verificar Influencia del Perfil del Estudiante Autor: Carlos Díaz, Luis Salinas ID: RQ_003 Tipo: DM Fecha de Creación: 15/08/08 Fecha de Modificación:

Supuestos Se cuentan con todos los datos necesarios para realizar al verificación

Recursos • Datos de una determinada cohorte • Datos de Académicos

Pasos 1. El actor Jefe de Gestión Académica suministra todos los datos de una cohorte y académicos.

2. Se definen cuales son los datos que se precisan para realizar la verificación del perfil.

3. Se efectúa la preparación de los datos. 4. Se determinan los modelos necesarios para realizar el estudio

(Verificación). 5. Se procede a desplegar los resultados

Requisitos no funcionales

Requisitos de Comprensibilidad, debido a que hay distintas especialidades, los resultados deben ser mostrados de la forma más homogénea posible. Requisitos de Calidad se necesita que los resultados entregados posean un grado de confianza elevado.

Aspectos pendientes

Tabla 5.4. Caso de Uso: Identificar Tendencia en Asignaturas

Caso de Uso

Identificar Tendencia en Asignaturas Autor: Carlos Díaz, Luis Salinas ID: RQ_004 Tipo: DM Fecha de Creación: 17/08/08 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite identificar patrones de comportamiento o tendencias de ciertas asignaturas.

Actor Primario Jefe de Gestión Académica Actor Secundario Supuestos Se cuentan con todos los datos necesarios para realizar el descubrimiento Recursos • Datos de una determinada cohorte

• Datos de Académicos Pasos 1. El actor Jefe de Gestión Académica suministra todos los datos de una

cohorte y académicos. 2. Se definen cuales son los datos que se precisan para realizar el

descubrimiento de tendencias. 3. Se efectúa la preparación de los datos. 4. Se determinan los modelos necesarios para realizar el estudio

(descubrimiento, relación). 5. Se procede a desplegar los resultados



Aspectos

184

Caso de Uso

Identificar Tendencia en Asignaturas Autor: Carlos Díaz, Luis Salinas ID: RQ_004 Tipo: DM Fecha de Creación: 17/08/08 Fecha de Modificación:

pendientes

Tabla 5.5. Caso de Uso: Verificar Causas Eliminación Ciclo Básico

Caso de Uso

Verificar Causas Eliminación Ciclo Básico Autor: Carlos Díaz, Luis Salinas ID: RQ_005 Tipo: DM Fecha de Creación: 17/08/08 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite verificar si la eliminación del ciclo básico se debe a las asignaturas de ciencias básicas.

Actor Primario Jefe de Gestión Académica Actor Secundario Supuestos Se cuentan con todos los datos necesarios para realizar la

Verificación. Recursos • Datos de una determinada cohorte

• Datos de Académicos Pasos 1. El actor Jefe de Gestión Académica suministra todos los datos de una

cohorte y académicos. 2. Se definen cuales son los datos que se precisan para realizar la verificación

del perfil. 3. Se efectúa la preparación de los datos. 4. Se determinan los modelos necesarios para realizar el estudio (Verificación,

Relación). 5. Se procede a desplegar los resultados



Aspectos pendientes

Tabla 5.6. Caso de Uso: Ponderar Efecto Ciclo Básico y Profesional

Caso de Uso

Ponderar Efecto Ciclo Básico y Profesional Autor: Carlos Díaz, Luis Salinas ID: RQ_006 Tipo: DM Fecha de Creación: 22/11/07 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite Ponderar el efecto de la eliminación del ciclo básico y del ciclo profesional en la titulación oportuna.

Actor Primario Consultores Externos Actor Secundario Supuestos Se cuentan con todos los datos necesarios para realizar el estudio Recursos • Datos de una determinada cohorte

185

Caso de Uso

Ponderar Efecto Ciclo Básico y Profesional Autor: Carlos Díaz, Luis Salinas ID: RQ_006 Tipo: DM Fecha de Creación: 22/11/07 Fecha de Modificación: • Datos de Académicos

Pasos 1. El actor Jefe de Gestión Académica suministra todos los datos de una cohorte y académicos.

2. Se definen cuales son los datos que se precisan para ponderar el efecto de la eliminación.

3. Se efectúa la preparación de los datos. 4. Se determinan los modelos que sean necesarios para realizar el estudio

(Verificación, Descubrimiento). 5. Se procede al despliegue de los resultados



Aspectos pendientes

Tabla 5.7. Caso de Uso: Estudiar Capacidades Académicas (DGD)

Caso de Uso

Estudiar Capacidades Académicas Autor: Carlos Díaz, Luis Salinas ID: RQ_007 Tipo: DM Fecha de Creación: 20/08/08 Fecha de Modificación:

Descripción Solicita la visualización de los patrones para verificar los datos y realizar el estudio relacionado con capacidades académicas.

Actor Primario Dirección General de Docencia Actor Secundario Supuestos Recursos Pasos 1. El actor Dirección General de Docencia procede a ingresar al sistema.

2. Consulta resultados. 3. Se procede a desplegar los resultados


Requisitos de Comprensibilidad, debido a que hay distintas especialidades, los resultados deben ser mostrados de la forma más homogénea posible.

Aspectos pendientes

Tabla 5.8. Caso de Uso: Consultar Resultados (Unidad Académica)

Caso de Uso

Consultar Resultados Autor: Carlos Díaz, Luis Salinas ID: RQ_008 Tipo: DM Fecha de Creación: 20/08/08 Fecha de Modificación:

Descripción Solicita la visualización de los patrones para verificar los datos y realizar la medida solicitada por el vicerrector académico o proponerle alguna alternativa.

186

Caso de Uso

Consultar Resultados Autor: Carlos Díaz, Luis Salinas ID: RQ_008 Tipo: DM Fecha de Creación: 20/08/08 Fecha de Modificación:

Actor Primario Unidad Académica Actor Secundario Supuestos Recursos Pasos 1. El actor Unidad de académica procede a ingresar al sistema.




Aspectos pendientes

Tabla 5.9. Caso de Uso: Estudiar Impacto Propuestas DGD (Unidad de Análisis Institucional)

Caso de Uso

Estudiar Impacto Propuestas DGD Autor: Carlos Díaz, Luis Salinas ID: RQ_002 Tipo: DM Fecha de Creación: 15/08/08 Fecha de Modificación:

Descripción Solicita la visualización de los patrones para verificar los datos y realizar el estudio de impacto de las propuestas de la DGD

Actor Primario Unidad de Análisis Institucional Actor Secundario Supuestos Recursos Pasos 1. El actor Unidad de análisis institucional procede a ingresar al sistema.




Aspectos pendientes 5.3.5. Fase de construcción de modelos de prueba. En esta fase del proceso (figura 5.19), se desarrolló un modelo de prueba con un doble propósito: primero, que el usuario tenga una mayor claridad sobre el tipo de información que obtendrá producto del desarrollo de los modelos de Data Mining y segundo, permitir que el usuario tenga la oportunidad de proveer la necesaria retroalimentación en base a la observación de los resultados preliminares obtenidos. Para el desarrollo del modelo de prueba, se selecciona el requisito “Verificar Influencia del Perfil del Estudiante” (tabla 5.3), el cual consiste en realizar el análisis de los datos

187

de una cohorte, que permita verificar si el perfil de los estudiantes, influye directamente en su desempeño académico (Puntaje PSU, NEM o Tipo de Colegio, entre otros). Para el desarrollo del modelo de prueba, se adoptó como guía la metodología CRISP-DM [CRISP-DM, 2000]. El proceso de desarrollo completo, se adjunta en el anexo C.

Figura No. 5.19. Modelos de prueba (elaboración propia).

El proceso de desarrollo del modelo de prueba, permitió clarificar varias de las ideas acerca de lo que el cliente esperaba como resultados del proyecto. Se desarrollaron un par de iteraciones y quedo claramente establecido que lo que el cliente requería en este caso, era un modelo predictivo el cual, dado el perfil del estudiante a su ingreso a la universidad, permitiera estimar sus posibilidades de éxito o fracaso. También en acuerdo con el cliente, se decidió por utilizar el modelo C&R, el cual entrega mayor información al cliente respecto de una red neuronal. 5.3.6. Redacción documento final de contrato. Esta última fase de la metodología (figura 5.20), considera la redacción del documento final de contrato, en base a toda la información recolectada y resultados obtenidos en las fases anteriores. Para la organización del documento de contrato, se utilizó como base la norma IEEE/ANSI 830-1998 [IEEE, 1998]. El documento fue redactado en conjunto con el cliente y luego de las revisiones de rigor, éste fue finalmente suscrito. El documento final de contrato con la firma del cliente y la de los desarrolladores del proyecto, se adjunta en el anexo D.

188

Figura No. 5.20. Documento de contrato (elaboración propia).

5.4. Análisis de resultados.

El análisis de los resultados producto del desarrollo del proyecto de Data Mining en el cual se ensayó la metodología propuesta, es efectuado en dos perspectivas: en una perspectiva particular, se comparan (de acuerdo a ciertos criterios) dos proyectos desarrollados en el mismo dominio, uno aplicando la metodología propuesta y otro sin la aplicación de dicha metodología; en la otra perspectiva, más general, se resumen los problemas habitualmente presentados en el desarrollo de proyectos de Data Mining (en los que no se aplica un enfoque metodológico para la fase de educción de los requisitos), mostrando de qué manera, se enfrentan estos problemas con la aplicación de la metodología. En la primera perspectiva, a objeto de establecer una base de evaluación y de estimación del grado de beneficio de la metodología propuesta, se comparan dos instancias en las cuales se desarrolló un proyecto de Data Mining. En ambos casos, el dominio del problema fue el mismo, con objetivos similares, con los mismos líderes de proyectos, pero desarrollados en distintos tiempos y por distintos usuarios y analistas de datos, lo que permite establecer una comparación entre las dos situaciones. Los resultados de la comparación se muestran en la tabla 5.10. El proyecto A (desarrollado sin la aplicación de la metodología propuesta) buscaba identificar factores relevantes, para discriminar entre estudiantes que no y estudiantes que sí, terminaban exitosamente sus programas de pre-grado; la búsqueda fue basada en información de ingreso del estudiante al programa. Con estos modelos descriptivos, se construyeron modelos predictivos para pronosticar la probabilidad de éxito de un estudiante que recién ingresa a un programa de pre-grado. El proyecto B (desarrollado aplicando la metodología propuesta) buscaba apoyar un objetivo estratégico y específico de la organización, el cual es “mejorar los sistemas de evaluación de la actividad académica y de apoyo a la academia y el control de la gestión de los recursos financieros y materiales de la organización”.

189

Tabla 5.10. Comparación de indicadores (tiempo de desarrollo, esfuerzo, grado de cumplimiento y grado de participación) de dos proyectos desarrollados en el mismo

dominio de negocio.

CRITERIO

PROYECTO A SITUACIÓN SIN

APLICACIÓN DE LA METODOLOGÍA

PROYECTO B SITUACIÓN CON


Tiempo de desarrollo

El tiempo empleado en la preparación de los datos y las numerosas iteraciones del proceso, redundaron en un tiempo de desarrollo largamente más extenso del estimado.

El desarrollo de un modelo de negocio y del documento de requisitos, redundó en una focalización en los datos estrictamente necesarios, lo que significó una adecuada preparación de ellos y pocas iteraciones para generar los modelos candidatos, logrando cumplir cabalmente con los plazos estimados en el plan de trabajo inicial revisado.

Esfuerzo de dedicación

El esfuerzo empleado, expresado como horas-hombre, fue largamente subestimado en la planificación inicial, principalmente debido a un proceso largo y complejo de preparación de datos, a la generación de modelos no relevantes y la reingeniería de datos realizada producto de la no satisfacción con los resultados.

El esfuerzo empleado en el proyecto estuvo acorde a lo estimado inicialmente, atribuible al proceso formal de entendimiento del negocio y la derivación de los requisitos mediante un enfoque metodológico. El esfuerzo de preparación de datos, reingeniería de datos y generación de datos fue notablemente menor que en la situación sin metodología.

Grado cumplimiento

objetivos

Los objetivos fueron establecidos informalmente como sentencias que describen lo que se pretende alcanzar con el proyecto, no obstante no hay una relación explícita y bien definida con los objetivos de negocio y por lo tanto, al finalizar el proyecto fue difícil establecer si se cumplieron los objetivos del negocio.

El Modelo de Negocio permitió establecer los objetivos estratégicos y organizacionales relacionados con los objetivos del proyecto. El Documento de Requisitos permitió identificar el cumplimiento de los objetivos de Data Mining del proyecto y determinar explícitamente el cumplimiento de los objetivos del negocio.

190

CRITERIO

PROYECTO A SITUACIÓN SIN


PROYECTO B SITUACIÓN CON


Grado de participación del usuario

La participación de los usuarios durante el desarrollo del proyecto fue asimétrica. En la primera etapa del proyecto, correspondiente a la fase de entendimiento del negocio y definición de objetivos, la participación del usuario fue importante, pero disminuyó drásticamente en las siguientes etapas.

El desarrollo del modelo de prueba permitió captar el interés del usuario, quién entendió claramente las tareas de Data Mining a realizar y los procesos de negocio que apoya. Con ello el usuario se involucró más activamente en el proyecto durante casi todas las etapas.

En una perspectiva general, el desarrollo del proyecto de Data Mining, en el cual se pudo aplicar la metodología propuesta en la presente tesis doctoral, ha permitido verificar que la metodología, aglutina efectivamente una serie de aspectos relevantes que deben ser considerados al inicio del desarrollo de un proyecto de Data Mining, en cuanto a los requisitos que debe satisfacer el proyecto, los recursos necesarios que deben ser considerados, los riesgos y restricciones del proyecto y en general todos los aspectos importantes que deben ser tomados en cuenta y que se desprenden de la fase de comprensión del dominio de negocio que plantea el estándar CRISP-DM. Así mismo, la metodología ha permitido constatar que muchos de los problemas que habitualmente se presentan en el desarrollo de proyectos de Data Mining [Britos, 2008], no se presentaron durante la ejecución del proyecto. En [Britos, 2008], se enuncia una serie de problemas identificados en el desarrollo de proyectos de Data Mining, producto de la revisión de un amplio rango de proyectos desarrollados en diversos dominios, como por ejemplo, telefonía móvil, agro-industria, inteligencia criminal y políticas de salud. En cada uno de ellos, las metodologías de Data Mining aplicadas en su desarrollo (carentes de un procedimiento metodológico para la educción de requisitos), presentaron dificultades para hacer frente a diversos problemas derivados de aspectos tales como [Britos, 2008]: el cliente no comprendía las técnicas ni el léxico utilizado por el grupo que desarrollaba el proyecto, el cliente no tenía claras las metas del proyecto o lo que se podía lograr con su desarrollo, o los modelos definidos por los desarrolladores eran diferentes a los que el cliente había previsto. La tabla 5.11, muestra la lista completa de los problemas detectados.

191

Tabla 5.11. Problemas detectados en una amplia gama de proyectos de Data Mining desarrollados (elaborado en base a [Britos, 2008]).

PROBLEMAS COMUNES DETECTADOS EN EL DESARROLLO DE

PROYECTOS DE DATA MINING

El cliente no comprende el lenguaje técnico utilizado por el grupo de DM.

El grupo de desarrollo del proyecto, no comprende el lenguaje utilizado por el experto de negocio.

Al grupo de desarrollo le resulta complejo entender cómo podría ayudar el cliente por que desconoce el dominio del proyecto.

El cliente no está seguro de qué hace o se puede lograr con el proyecto de DM.

Los modelos definidos por el grupo de desarrollo, difieren de los previstos por el cliente. El equipo que participa en el proyecto por parte del cliente muestra escaso interés en el proyecto.

El cliente no conoce las necesidades de información de la organización.

Los datos identificados por los requisitos no son los correctos.

Cuando el proyecto estaba en la fase de modelado y el grupo de DM detectó problemas en los datos (datos identificados por los requisitos no fueron los correctos), fue necesario redefinir los requisitos.

Una comprensión equivocada de los requisitos resulta en la selección de herramientas de modelado equivocadas.

La metodología propuesta en la presente tesis doctoral y aplicada al desarrollo de un caso práctico como se describe en el punto 5.3 (aplicación de la metodología ER-DM), en relación a los problemas enunciados en la tabla 5.11 ha puesto en evidencia que ninguno de los problemas mencionados en dicha tabla se ha presentado, pues cada concepto del cual se derivan los problemas identificados, es considerado por la metodología, como se describe en la tabla 5.12.

192

Tabla 5.12. Conceptos considerados y elicitados al aplicar la metodología ER-DM y su relación con los problemas habitualmente presentados en el desarrollo de proyectos de

Data Mining (elaborado en base a [Britos, 2008]).

PROBLEMA DETECTADO CONCEPTOS RELACIONADOS

METODOLOGÍA ER-DM

El cliente no comprende el lenguaje técnico utilizado por el grupo de DM.

Definiciones acrónimos y abreviaciones.

ER-DM, considera la educción de estos conceptos, durante el desarrollo de la fase Requisitos Organizacionales: Actividad, definición del glosario de términos del proyecto.

El grupo de desarrollo del proyecto, no comprende el lenguaje utilizado por el experto de negocio.


ER-DM, considera la educción de estos conceptos, durante el desarrollo de la fase Comprensión del Dominio del Negocio: Actividad, educción del glosario de términos de la organización.

Al grupo de desarrollo le resulta complejo entender cómo podría ayudar el cliente por que desconoce el dominio del proyecto.


ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de la fase Requisitos Organizacionales: Actividad, preparación para el proceso de elicitación de los requisitos.

El cliente no está seguro de qué hace o qué se puede lograr con el proyecto de DM.

Objetivos del proyecto, criterios de éxito, expectativas y supuestos del proyecto

ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de la fase Requisitos Organizacionales: Actividad, definición del alcance del proyecto.

193


METODOLOGÍA ER-DM

Los modelos definidos por el grupo de desarrollo, difieren de los previstos por el cliente.

Objetivos del proyecto, criterios de éxito, expectativas y supuestos del proyecto

ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de las fases Requisitos Organizacionales, Modelo de Negocios Decisional y Modelos de Prueba.

El equipo que participa en el proyecto por parte del cliente, muestra escaso interés en el proyecto.

Recursos humanos considerados

ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de las fases Requisitos Organizacionales (Actividad, definición de los actores participantes del proyecto) y Modelo de Negocios Decisional.

El cliente no conoce las necesidades de información de la organización.

Restricciones, riesgos y planes de contingencia del proyecto.

ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de las fases Comprensión del Dominio de Negocio, y Modelo de Negocios Decisional.

Los datos identificados por los requisitos no son los correctos.

Requisitos, e información o fuentes de datos

ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de las fases Modelo de Negocios Decisional, Modelo de Requisitos y Modelos de Prueba.

194


METODOLOGÍA ER-DM

Cuando el proyecto estaba en la fase de modelado, y el grupo de DM detectó problemas en los datos (datos identificados por los requisitos no fueron los correctos), fue necesario redefinir los requisitos.

Supuestos, restricciones, riesgos y planes de contingencia de los requisitos.

ER-DM, considera el tratamiento de todos los conceptos relacionados, durante el desarrollo de las fases Requisitos Organizacionales, Modelo de Negocios Decisional, Modelo de Requisitos y Modelos de Prueba.

Una comprensión equivocada de los requisitos resulta en la selección de herramientas de modelado equivocadas.

Evaluación de herramientas de Data Mining.

ER-DM, no considera la evaluación de herramientas de Data Mining.

Finalmente de acuerdo a lo expresado por el equipo de desarrollo del proyecto, se puede afirmar que el uso de la metodología ER-DM permitió:

1. Contar con una secuencia de fases que les posibilitó comprender más adecuadamente, de donde provenían los requisitos a satisfacer y de qué manera se podía complementar aún más la solución del problema a resolver. Por ejemplo, para responder a uno de los requisitos “Influencia del Perfil de los estudiantes”, la aplicación de la metodología, posibilitó identificar a las personas que realmente podían ser un aporte relevante para el desarrollo del proyecto y que poseían un mayor conocimiento respecto del tema relacionado a este requisito en particular, en este caso al Sr. Santiago Sánchez, quien finalmente fue el cliente directo de la solución Data Mining.

2. Disponer de un documento que contiene de manera gráfica y textual los requisitos que satisface la solución de Data Mining desarrollada. Como establece ER-DM, se desarrollaron: el Modelo de Negocios Decisional y el Modelo de Requisitos, considerando el desarrollo de los Casos de Uso para la solución Data Mining.

3. Al desarrollar modelos de prueba, tener una mejor comprensión de los datos y efectuar una eficiente preparación y modelado de ellos, permitiendo asimilar de forma más clara lo que realmente el cliente deseaba y sobre todo, verificar la conformidad de los usuarios.

4. Contar con un Documento de contrato final, que ratifica el acuerdo explícito entre los usuarios y los desarrolladores, conscientes de que se logró entender lo que realmente deseaban resolver (Modelo de Requisitos) y lo que obtendrían en mayor medida por la solución Data Mining (Modelo de Prueba), como ocurrió en el presente proyecto.

195

Adicionalmente el equipo de desarrollo del proyecto, expresa textualmente que:

1. La metodología ER-DM aplicada a un proyecto de Data Mining, tiene un alto grado de adaptabilidad que la hace flexible a la hora de utilizarla. Este grado de adaptabilidad se materializa en, la realización de las modificaciones que se estimen convenientes en sus artefactos (plantillas) o en la cantidad y tipo de información solicitada. Siguiendo siempre la secuencia de pasos o actividades recomendadas por la metodología.

2. La aplicación de las técnicas para la educción de requisitos, como Entrevistas o

Reuniones, predominan cuando los integrantes del proyecto por parte de la organización, tienen otras labores operacionales que realizar, participando en el proyecto más por interés propio, que por delegación. Al ser su disponibilidad de tiempo muy variada, se hace necesario obtener la mayor información por medio de estas técnicas. Esto último, especialmente en la fase de Modelado del Proceso Decisional del cual se derivan los Casos de Uso del Sistema.

3. La etapa de desarrollo de los modelos de prueba, fue la etapa que condujo a una

mayor interacción entre los desarrolladores y el cliente.

4. El Modelado del Proceso Decisional, fue importante para aclarar las ideas (con la asesoría de los expertos de negocio) entre los actores organizacionales (clientes) y los desarrolladores, permitiendo comprender los requisitos a satisfacer por la solución Data Mining, con la ayuda visual (gráfica) en la que pueden identificarse los actores, sus actividades y cómo interactúan tanto directa como indirectamente con la solución DM.

5. Los resultados generales obtenidos por los distintos modelos que conforman la

solución Data Mining, se focalizaron específicamente en los requisitos estipulados en el Documento de Requisitos, lo que permitió concentrarse principalmente en los datos de entrada requeridos, no siendo necesario explorar datos sin un objetivo claro. Además, el cliente con el cual se confeccionó el Documento de Requisitos, se sintió partícipe del desarrollo de los modelos, así como también en permanente aprendizaje sobre Data Mining, esto último se reflejó sobretodo en la etapa del desarrollo del Modelo de Prueba.

197

CAPÍTULO VI

Conclusiones y Trabajo Futuro.

En este capítulo, se muestran las principales conclusiones que se obtienen, producto de la aplicación de la solución al problema de investigación planteado; al desarrollo de un proyecto de Data Mining real, evidenciando a su vez, las principales contribuciones de la propuesta metodológica, en el proceso de definición de un documento de especificación de requisitos. Posteriormente, se plantean algunas ideas acerca de futuros trabajos que puedan ser desarrollados, en base al trabajo realizado en la presente tesis doctoral.

199

6.1. Conclusiones.

La naturaleza de los problemas que resuelve un proyecto de Data Mining, amerita la definición de un procedimiento metodológico nuevo, para el descubrimiento de los requisitos del proyecto, diferente al proceso de educción de los requisitos de sistemas tradicionales de desarrollo de software. Para el desarrollo de sistemas transaccionales, las políticas, reglas de negocio, funciones y procedimientos de la organización, normalmente están claramente definidos. En cambio, en el caso de los sistemas de Data Mining, considerando que estos sistemas deben proveer información o conocimiento nuevo y relevante, que ayude a resolver los problemas derivados de la toma de decisiones en los niveles superiores de una organización, no ocurre esto. Muy por el contrario; al ser los procesos decisionales típicamente procesos no estructurados, frecuentemente el cliente, sólo tiene vagas ideas acerca de los requisitos del sistema. Considerando lo anteriormente expuesto, como principal motivación para el desarrollo de ésta tesis doctoral, el trabajo realizado, presenta una propuesta consistente en una guía metodológica para la construcción del documento de requisitos, como fase inicial en el desarrollo de proyectos de Data Mining, que involucren la necesidad de obtener información o conocimiento relevante y que brinden apoyo eficiente a los procesos decisionales. La propuesta metodológica, sustentada en las actividades típicas de un proceso de ingeniería de requisitos, consta de un conjunto de seis fases, organizadas en un Framework. Las fases constituyentes de la metodología son:

1. Comprensión del dominio de negocio

2. Definición de requisitos preliminares

3. Modelado del proceso decisional

4. Construcción del modelo de requisitos

5. Construcción de modelos de prueba

6. Redacción del documento de contrato Para el desarrollo de cada una de las fases, se han propuesto un conjunto de plantillas y técnicas, para el descubrimiento y registro de la información pertinente. El proceso, es desarrollado iterativa e interactivamente, con la participación activa de los stakeholders identificados y definidos al inicio del proceso. La metodología, considera relevante, el desarrollo de un modelo de negocios del proceso decisional origen del problema. Este modelo, mediante el uso de heurísticas definidas, sirve como entrada para derivar los requisitos organizacionales y el modelo de casos de uso para el desarrollo del proyecto de Data Mining. La metodología propuesta se aplicó en el desarrollo de un caso de estudio real, con el propósito de ilustrar su uso y validar la propuesta. El desarrollo del caso real, permitió evidenciar la importancia de contar con un modelo del proceso decisional de la organización; como un paso previo al desarrollo del

200

proyecto de Data Mining, por cuanto a partir de este modelo, se derivaron los requisitos iníciales con los cuales, el proyecto de Data Mining debería estar alineado. Adicionalmente, el proceso de construcción del modelo decisional, desarrollado en conjunto con los expertos de negocio, posibilita descubrir con mayor claridad, a qué actividades del proceso de toma de decisiones estratégico, los proyectos de Data Mining podrían apoyar. Contar con una metodología ad-hoc, para la construcción de un documento de requisitos antes del inicio de un proyecto de Data Mining, permitió en nuestro caso, obtener un modelo de requisitos, que garantiza con un mayor grado de consenso, el que efectivamente los resultados del proyecto de Data Mining, correspondan a las necesidades y expectativas de los usuarios, sirviendo de apoyo eficaz a los procesos decisionales involucrados. Por cuanto el proceso de obtención del modelo organizacional, a partir del cual se obtiene el modelo de los requisitos, considera un proceso evolutivo e iterativo que permite, entender de mejor forma la organización y consensuar, negociar y verificar que efectivamente, el modelo, es una representación veraz del proceso decisional de la organización y que la solución al problema de negocio, realmente requiere el apoyo de un sistema de Data Mining. Con anterioridad al desarrollo del proyecto de Data Mining en el cual se ensayó la metodología propuesta, se ejecutó un proyecto similar; es decir el análisis de los datos de los sistemas curricular y de admisión de alumnos de la universidad, con el propósito de descubrir patrones de interés para el cliente (autoridades de la Vicerrectoría Académica). El desarrollo del proyecto, no consideró un procedimiento metodológico para el descubrimiento de los requisitos, no se obtuvo un modelo de negocio decisional y no fue suscrito ningún documento de contrato. Finalmente los resultados logrados, no fueron considerados hasta el momento. Es importante destacar por otro lado, que a partir del modelo de requisitos derivado del modelo de negocios de la organización, no sólo se pueden identificar casos de uso de Data Mining, sino además, otras funcionalidades que pueden ser satisfechas mediante típicos sistemas de software, los cuales se complementan con los de Data Mining para el logro de las metas organizacionales. Otro aspecto de relevancia que es necesario considerar, es el hecho de que la utilización de la técnica de modelado utilizada (Framework i*), permite representar en forma explícita en el modelo de negocios organizacional, los requisitos de tipo no funcional asociados a los requisitos de tipo funcional, mediante el uso de objetos de dependencia de meta suave (softgoals) a diferencia por ejemplo, del diagrama de actividades de UML, que es también utilizado para modelar procesos de negocio. En resumen, se puede concluir que se han alcanzado satisfactoriamente los objetivos planteados al inicio de la tesis esto es: 1. Como objetivo general, se ha logrado desarrollar una metodología (ER-DM) de

apoyo al proceso de construcción conjunta (clientes y técnicos de Data Mining) del documento de requisitos, el cual considera los principales requisitos que debe lograr satisfacer el proyecto de Data Mining a desarrollar.

201

2. Como objetivos específicos:

2.1. Se ha realizado una extensa investigación bibliográfica, sobre las diferentes técnicas, métodos y procesos de ingeniería de requisitos y cómo éstas se aplican en diversas áreas de la ingeniería y sector industrial.

2.2. Se han propuesto las técnicas de ingeniería de requisitos, susceptibles de utilizar

en las diversas actividades del proceso de Ingeniería de Requisitos aplicadas al desarrollo de proyectos de Data Mining.

2.3. Se ha establecido un proceso metodológico, para la creación de un modelo de

Negocios del Proceso Decisional de una Organización, a partir del cual, es posible derivar el modelo de requisitos del proyecto de Data Mining.

2.4. Se ha seleccionado y propuesto una notación eficaz para representar el Modelo

de Negocios del Proceso Decisional. 2.5. Se ha propuesto una notación, mediante la definición de los casos de uso de

Data Mining, para la representación del documento de contrato. 2.6. Se ha ensayado la metodología propuesta, en el desarrollo de un proyecto de

Data Mining aplicado a un caso de estudio real, lográndose resultados satisfactorios.

Adicionalmente se puede expresar que, contar con una metodología para el descubrimiento de los requisitos y posterior construcción de un documento de contrato permite:

1. Considerar efectivamente las necesidades de la organización.

2. Verificar si los problemas presentados en la organización, requieren efectivamente una solución que involucre el uso de Data Mining.

3. Utilizar eficazmente las técnicas más adecuadas, en las diferentes actividades del proceso de ingeniería de requisitos.

4. Poder establecer con mayor precisión el período de tiempo, en el cual será desarrollado el proyecto.

5. La construcción de un modelo del proceso de toma de decisiones, el cual suministra información, que no sólo es utilizada para el desarrollo del proyecto de Data Mining (la organización lo precisa para múltiples propósitos).

6. Descubrir diferentes caminos de solución para los problemas presentados.

7. Establecer lazos de confianza entre los diferentes stakeholders.

8. Lograr la motivación de clientes y desarrolladores en la ejecución del proyecto, por cuanto todos se sienten partícipes del proceso.

Algunos de los inconvenientes que se presentaron y que escapan a la consideración del proceso metodológico, son: el escaso tiempo del que disponen frecuentemente las autoridades de la organización, los problemas para la disponibilidad oportuna de los datos, la abundancia de datos corruptos, ausentes, etc., etc.

202

6.2. Trabajo futuro.

Como posibles trabajos futuros de investigación, derivados del desarrollo de la presente tesis doctoral y que sirvan como complemento de la metodología, se proponen las siguientes ideas.

i. Aplicar la metodología en el desarrollo de diversos proyectos de Data Mining: Se considera recomendable, la aplicación de la metodología, en un mayor número de proyectos de Data Mining de diversos grados de magnitud y complejidad para descubrir aspectos no considerados en la propuesta metodología o susceptibles de modificación o corrección.

ii. Gestión de los requisitos en un proyecto de Data Mining: La gestión de los requisitos, constituye una actividad importante dentro del proceso de Ingeniería de Requisitos. Los requisitos durante el ciclo de vida de un proyecto, pueden ser modificados; razón por la que se incorpora el concepto de Gestión de Requisitos, que es el tratamiento y control de las actualizaciones y cambios a los mismos. Tareas como la gestión de cambio de los requisitos, o el análisis de impacto, son parte de esta importante actividad que no han sido consideradas en el presente desarrollo. La gestión de los requisitos, debe ser introducida como una actividad transversal al resto de las actividades del proceso (educción, análisis y validación de los requisitos).

iii. Reutilización de requisitos: El documento de requisitos, constituye el elemento fundamental para el desarrollo de un sistema. La especificación de requisitos de alta calidad, es crítica para asegurar que el futuro sistema, satisfaga efectivamente las necesidades del cliente. Sin embargo, obtener un conjunto de requisitos de alta calidad, es una tarea muy compleja y demandante de tiempo. Por lo tanto, si se inicia el desarrollo de un proyecto, a partir de requisitos que ya hayan sido especificados para proyectos similares o en similares dominios de negocio, existe mayor tiempo y probabilidad de mejorar la calidad y completitud de los requisitos para el nuevo sistema [Robertson, 1999]. Una de las características de un desarrollo maduro, es la reutilización de los requisitos [Sommerville, 1997]. En un futuro, la reutilización de los requisitos, debería ser contemplada explícitamente en el modelo de procesos [Durán, 2000]. Considerando lo anteriormente expuesto, una línea de investigación que se propone, es la de “especificación de requisitos de calidad y creación de repositorios de requisitos para proyectos de Data Mining, al abrigo de alguna norma de calidad”.

iv. Creación de herramientas CASE y una extensión a la técnica de modelado i*: La utilización del lenguaje de modelado organizacional i*, no es claramente comprensible para los stakeholders que no son especialistas en el modelado y alcanza un mayor grado de complejidad, en la medida que aumenta el número de actores y la complejidad del proceso decisional o tamaño de la organización, por lo tanto se propone crear aplicaciones de software que automaticen el proceso de modelado de una organización, su posterior derivación de un modelo de casos de uso y una extensión al conjunto de primitivas que componen el lenguaje, que provea explicaciones en lenguaje natural, de modo que los diagramas i*, sean más fácilmente comprensibles.

203

BIBLIOGRAFÍA

[Adraans, 1996] Adraans P., Zantinge D., “Data Mining”, Ed. Addison Wesley. Harlow, England, 1996.

[Aguilar-Saven, 2004] Aguilar-Savén R. S., "Business Process Modelling: Review and Framework", International Journal of Production Economics, (90) 129-149. (2004).

[Alencar, 1999] Alencar Ribeiro F., “Mapeando A Modelagem Organizacional Em Especificações Precisas”, tesis de Doctorado en Cs. de la Computación, Universidad Federal de Pernanbuco, 1999.

[Alencar, 2000] Alencar F. y otros, “From Early Requirements Modeled by the i* Technique to Later Requirements Modeled in Precise UML”, III Workshop de Engenharia de Requisitos,WER’2000, 2000.

[Allen 2001] Allen P. M., “A Complex Systems Approach to Learning in Adaptive Networks”, International Journal of Innovation Management, 5(2) 149-180, 2001.

[Arango, 2002] Arango J., “Tormenta de Ideas”, Colombia, Universidad EAFIT, 2002, [en línea], disponible en: http://www.eafit.edu.co/tda/boletin/TORMENTA%20DE%20IDEAS.htm, [Consulta: 29 de abril de 2005].

[Aranguren, 2003] Aranguren S., Muzachiodi S., “Implicancias del Data Mining”, tesis de grado Licenciatura en Sistemas de Información, convenio UTN – ISIPER, Argentina, 2003, disponible en: http://www.fceco.uner.edu.ar/ extinv/publicdocent /sarangur/ [Armin, 2003] Armin Eberlein and Li Jiang, “Requirements Engineering: A Review and a Proposal”, Department of Electrical & Computer Engineering, University of Calgary, QSSE, 2003, Banff, Alberta, Canada, 2003.

[Arsham, 2006] Arsham H., “Toma de Decisiones con Periodos de Tiempo Crítico en Economía y Finanzas”, University of Baltimore, [en línea] disponible en, http://home.ubalt.edu/ntsbarsh/stat-data/Forecasts.htm, [Consulta: 12 de mayo de 2006].

[Antón, 1994] Antón A., Potts C. and Takahashi K., “Inquiry-Based Requirements Analysis”, IEEE Software, 1994.

[AU, 2001] Portal American University, “THE REVIEW OF THE LITERATURE”, disponible en http://www.american.edu/cas/health/nchf/archives/ pubsdissfinalch2.html [Consulta, 07 de noviembre de 2005].

[Ávila, 2000] Ávila R. M., “El AHP (Proceso de Análisis Jerárquico) y su aplicación, para determinar los usos de tierras”, Informe Técnico, proyecto regional, sobre tierras y aguas para un desarrollo agrícola sostenible, (Proyecto GCP/RLA/126/JPN), Santiago - Chile, 2000.

[Báez, 2002] Báez G., Barba S., “Metodología DoRCU para la Ingeniería de Requerimientos”, Instituto Superior Politécnico José Antonio Echeverría, La Habana, 2002.

204

[Bagchi, 2000] Bagchi S., Tulskie B., “e-business Models: Integrating Learning from Strategy Development Experiences and Empirical Research”, 20th Annual International Conference of the Strategic Management Society, Vancouver, October 15-18, 2000.

[Bahamonde, 2003] Bahamonde J.M., Rossel R., “Un Acercamiento a la Ingeniería de Requerimientos”, Universidad Técnica Federico Santa María, 2003.

[Barrera, 2003] Barrera M., “Toma de decisiones”, [en línea] disponible en http://www.monografias.com/trabajos12/decis/decis.shtml, [Consulta: 23 de mayo de 2006].

[Bass, 1997] Bass L., Clements, P., and Kazman, R., “Software Architectures in Practice”, Addison-Wesley, Reading, Massachusetts, 1997.

[Bellman, 1957] Bellman R., Clark C., et al., "On the Construction of a Multi-Stage, Multi-Person Business Game.", Operations Research 5(4): 469- 503, 1957.

[Beregi, 1984] Beregi W. E., “Architecture prototyping in the software engineering environment”, IBM SYSTEMS JOURNAL, vol. 23, no. 1, 1984.

[Beyer, 1995]. Beber H., Holtzblatt K., “Apprenticing whit the Customer”, Communications of the ACM, 38(5), mayo 1995.

[Bienvenido, 2004] Bienvenido J. y Martínez de Pisón F., “Apuntes asignatura Minería de Datos”, Versión:1.3, Curso:2004-2005, Universidad De La Rioja.

[Boehm, 1998] Boehm B. and Brown W., “KBSA Life Cycle Evaluation”, FINAL TECHNICAL REPORT, USC Center for Software Engineering, Prasanta Bose George Mason University, 1998.

[Boehm, 2000] Boehm B., “Requirements that Handle IKIWISI, COTS and Rapid Change”, Computer, 33(7):99-102, IEEE Computer Software Press, 2000.

[Booch, 1999] Booch, G., Rumbaugh J. and Jacobson I., “The Unified Modeling Language User Guide”, Addison–Wesley, 1999.

[Bowen, 2005] Bowen J. “The Z Notation”, [en línea], disponible en, http://vl.zuser.org/#vdm, 2005, [Consulta: 16 Agosto de 2005].

[BPMI, 2004] Business Process Management Initiative (BPMI): Business Process Modeling Notation (BPMN), Specification Version 1.0, May 3, 2004.

[BPMN, 2008] OMG Document Number: formal/2008-01-17 “Business Process Modeling Notation, V1.1”, Standard document URL: http://www.omg.org/spec/BPMN/1.1/PDF, January 2008.

[Brachman, 1996] Brachman R.J., Anand T., “The Process of Knowledge Discovery en Databases: A Human Centered Approach”, In Fayyad, U.M., Piatetsky-Shapiro, G., G., Smyth, P., & Uthurasamy, R. (eds), Advances in Knowledge Discovery and Data Mining, AAI/MIT Press, 1996.

[Britos, 2008] Britos P., Dieste O. and García-Martínez R., 2008, “Requirements Elicitation in Data Mining for Business Intelligence Projects”, in IFIP International Federation for Information Processing, Volume 274; Advances in Information Systems Research, Education and Practice; David Avison, George M. Kasper, Barbara Pernici, Isabel Ramos, Dewald Roode; (Boston: Springer), pp. 139 – 150.

205

[BVES, 2006] Portal Bolsa de Valores de el Salvador www.bves.com.sv, “Glosario”, disponible en: https://www.bves.com.sv/glosario/g_e.htm [Consulta: 20 de mayo de 2006].

[Cabena, 1997] Cabena P., Hadjinian P., Stadler R., Verhees J., and Zanasi A. “Discovery Data Mining. From Concept to Implementation”, Prentice Hall, 1997.

[Caneo, 2008] Caneo P., “Técnicas de Auditoria Aplicadas a la Ingeniería de Software”, Conferencia presentada en Latin America CACS, 2008. Disponible en internet: http://auditor2006.comunidadcoomeva.com/blog/uploads/312TecnicasAuditIngenieriaSoftware-PCaneo., fecha de consulta 15/11/2008.

[Caniupan, 2000] Caniupan M. y Toro G., “Aplicación del Proceso de Data Mining en el Área Docente”, Tesis de Grado, Ingeniería Civil en Informática, Universidad del Bio Bio Chile, 2000.

[Checkland, 1989] Checkland P., “An Application of Soft Systems Methodology Rational Analysis for a Problematic World”, Ed. John Wiley & Sons, 1989 New York.

[Chesbrough, 2002] Chesbrough H., and Rosenbloom S., “The role of the Business Model in Capturing Value from Innovation: Evidence from Xerox Corporation’s Technology Spinoff Companies”, Industrial and Corporate Change, 11 (3), 2002.

[Choque, 2003] Choque Guillermo, “Ingeniería de Requerimientos”, artículo de divulgación, Ingeniería de Software, Universidad Mayor de San Andrés, 2003.

[Christel, 1992] Christel M. G., Kang K. C., “Issues in Requirements Elicitation”, Technical Report CMU/SEI-92-TR-12., ESC-TR-92-012 Software Engineering Institute, Pittsburgh. September 1992.

[Compton et. al. 1991] Compton P., Edwards G., Kang B., Lazarus L., Malor R., Menzies T., Preston P., Srinivasan A. and Sammut C. (1991), “Ripple Down Rules: Possibilities and Limitations”, 6th Banff AAAI Knowledge Acquisition for Knowledge Based Systems Workshop, Banff, 6.1 - 6.18.

[CRISP-DM, 2000] Chapman P., (NCR), Clinton J., (SPSS) Kerber R., (NCR), Khabaza T. (SPSS), Reinartz T. (DaimlerChrysler), Shearer C. (SPSS), and Wirth R. (DaimlerChrysler), “CRISP-DM 1.0 step-by-step data mining guide”, Thechnical report, 2000.

[Daedaluz, 2000] Daedaluz- Data, decisions and language, S.A., “Minería de datos, Conceptos y objetivos”, 1012-V-DB-002-020, Septiembre de 2000.

[DACS, 2008] Portal DACS (The Data and Analysis Center for Software) https://www.thedacs.com/, “A State of the Art Report: Software Design Methods”, [en línea], disponible en https://www.dacs.dtic.mil/techs/design/overview.php, [Consulta: 01 de Agosto de 2008].

[Daft, 2205] Daft Richard, “Teoría y diseño organizacional”, Ed. Thomson, 2005.

[Davis et al, 1997] Davis A.M., Jordan, K. and Nakajima T. (1997) “Elements Underlying the Specification of Requirements”, Annals of Software Engineering, Spec. Issue on Software Requirements Engineering, 3:63-100.

206

[Davyt, 2001] Davyt N., “Ingeniería de Requerimientos, una guía para extraer, analizar, especificar y validar los requerimientos de un proyecto”, facultad de Ingeniería, Universidad Ort del Uruguay, Montevideo, 2001.

[Dilauro, 2000] Dilauro L., “What’s nest in monitoring technology? Data Mining finds a calling in centers”, mayo 2000.

[Domínguez, 2008] Domínguez D. y García R. “Ejemplo de Casos de Uso Gestión de un Vídeo-Club”, Facultad de Informática, Universidad Politécnica de Valencia, [en línea], disponible en: http://www.dsic.upv.es/asignaturas/facultad/lsi/trabajos.html, [Consulta: 25 de Noviembre de 2008].

[DOORS, 2005] Portal www.telelogic.com, “DOORS Home Page” [en línea], disponible en: http://www.telelogic.com/products/doorsers/doors/, [Consulta: 29 de junio de 2005].

[DRAE, 1995] Real Academia Española, “Diccionario de Real Academia”, Vigésimo primera edición, Espasa-Calpe, Edición electrónica, versión 21.1.0. 1995.

[Durán, 2000] Durán Amador, “Un entorno metodológico de Ingeniería de requisitos para sistemas de información”, memoria de tesis doctoral para optar al grado de Doctor en informática por la Universidad de Sevilla, 2000.

[Edelstein, 1999] Edelstein Herbert. “Introduction to Data Mining and Knowledge Discovery, Third Edition”, Two Cows Corporation. USA. 1999.

[Emam, 2000] Emam K. E. and Birk A., “Validating the ISO/IEC 15504 Measure of Software Requirements Analysis Process Capability”, IEEE Transactions on Software Engineering, VOL. 26, NO. 6, June 2000.

[Eriksson, 2000] Eriksson H. E., “Business Modeling with UML, Business Patterns at Work”, Ed. Wiley Computer Publishing, 2000.

[ESA, 2003] ESA Comité de Estandarización y Control de Software (BSSC) “Guía para la aplicación de Estándares de Ingeniería de Software ESA”, European Space Agency / Agence Spatiale Européenne (Agencia Espacial Europea) 8-10, rue Mario -Nikis, 75738 PARIS CEDEX, Francia, BSSC(96) 2 Número 1. 2003.

[Etzioni, 1988] Etzioni A., “The Moral Dimension: Toward a New Economics”, Free Press, New York, NY, 1988.

[Etzioni, 1989] Etzioni A. (1989), “Humble decision making”, Harvard Business Review, Vol. 67, pp. 122-126.

[Fayyad, 1996] Fayyad Usama; Piatesky-Shapiro G.; Smyth P., “Advances in Knowledge Discovery and Data Mining”, MIT Press, 1996.

[Fensel, 2001]. Fensel, D., “Ontologies: Silver Bullet for Knowledge Management and Electronic Commerce”, Heidelberg: Springer-Verlag, 2001.

[Firesmith, 1997] Firesmith, D. G., “Uses Cases: the Pros and Cons”, 1997, [en línea], disponible en http:/ /www.ksccary.com/usecjrnl.html, [Consulta: 29 de junio de 2005].

[Firesmith, 2003] Firesmith D. G., "Engineering Security Requirements", in Journal of Object Technology, vol. 2, no. 1, January-February 2003, pp. 53-68.

207

[FIS, 1996] Faculty of Information Studies, University of Toronto, “The Knowing Organization: How Organizations Use Information To Construct Meaning, Create Knowledge, and Make Decisions International”, Journal of Information Management, vol. 16 no. 5, October 1996, pp. 329-340 [en Línea], disponible en http://choo.fis.utoronto.ca/FIS/respub/KOart.html [Consulta: 12 de Junio de 2006.

[Fowler, 1997] Fowler M. and Scott K., “UML Distilled - Applying the Standard Object Modeling Language”, Addison-Wesley, Reading, Massachusetts, 1997.

[Gaarder, 2003] Gaarder K., “Business models ¿what are they and how do we design them?”, paper presented at Eurescom, Summit 2003.

[García, 2000] Garcia J., “Especificación, verificación, y mantenimiento de requisitos funcionales con técnicas de descripción formal”, tesis doctoral, Universidad de Vigo, 2000.

[García, 2004] García J., “El proceso de toma de decisiones y de resolución de problemas”, [en línea] disponible en http://www.cop.es/colegiados/m-00451/tomadeciones.htm, [Consulta: 22 de junio de 2006].

[Gause, 1989] Gause D. C. and G. M. Weinberg. “Exploring Requirements: Quality Before Design”, Dorset House, 1989.

[Gerhard, 1997] Gerhard P., “Requirements Acquisition and Specification for Telecommunication Services”, tesis doctoral, University of Wales, Swansea, UK, 1997.

[Gil, 1999] Gil A., “Diseño y verificación de sistemas distribuidos mediante la aplicación combinada de métodos formales”, tesis doctoral, Universidad de Vigo, 1999.

[Glinz, 2000] Glinz M., “Problems and Deficiencies of UML as a Requirements Specification Language”, Proceedings of the Tenth International Workshop on Software Specification and Design (IWSSD'00), 2000.

[Green, 1983] Green, C., Luckham, D., Balzer R., Cheatham T. and C. Rich, “Report on a Knowledge Based Software Assistant”, Kestrel Institute Report, prepared for RADC, June 15, 1983.

[Goguen, 1993] Goguen J., Linde C., “Techniques for RequirementsElicitation”, Proceedings of The First International Symposium on Requirements Engineering, 1993.

[Gomez, 1997] Gomez A. y otros, “Ingeniería de Conocimiento”, Ed. Centro de Estudios Ramon Areces, S. A. Madrid, 1997.

[Gondar, 2005] Gondar J.E., “Metodología del Data Mining”, No. 84-96272-21-4. Data Mining Institute, S.L., 2005

[Gordijn, 2000] Gordijn J., et al, “Value Based Requirements Creation for Electronic Comerce Applications”, Publisher in the Proceedings of the Hawaii Internacional Conference On System Sciences, January 4-7, 2000, Maui, Hawaii.

[Gordijn, 2003] Gordijn J., “Value-based Requirements Engineering Exploring Innovative e-Commerce Ideas”, VRIJE UNIVERSITEIT, 2003.

[Gulati, 2000] Gulati R., Nohria N., Zaheer A., “Strategic Networks”, Strategic Management Journal, 2000, 21: pp. 203-215.

208

[Hall, 1997] Hall Anthony, “What’s the use of Requirements Engineering”, 1090-705x97, 1997, IEEE.

[Hamel, 2000] Hamel G., “Leading the revolution”, Harvard Business School Press, Boston 2000.

[Han, 2001] Han J., and Kamber M., “Data Mining: Concepts and Techniques”, Academic Press, 2001.

[Han & Kamber, 2006] Han, J., & Kamber, M., “Data Mining: Concepts and Techniques”, Elsevier.

[Hastie, 2001] Hastie R., “Problems for Judgement and Decision Making”, Annual Review of Psychology. 52:653-83 2001.

[Hayes, 2005] Hayes J. and Finnegan P., “Assessing the of potential of e-business models: towards a framework for assisting decision-makers”, European Journal of Operational Research 160(2): 365-379, 2005.

[Heitmayer, 2000] Heitmeyer C. & Bharadwaj R., “Applying the SCR Requirements Method to the Light Control Case Study”, Journal of Universal Computer Science 6, 7 (2000): 650-678.

[Heller, 1988] Heller F., Drenth P., Koopman P. and Rus V., “Decisions in Organizations”, Sage, Beverly Hills, CA, 1988.

[Hellriegel, 2002] Hellriegel D., Jackson S., Slucum J., “Administración un enfoque basado en competencias”, Thomson Learning, 2002.

[Heninger, 1978] Heninger K.; Parnas D. L.; Shore J. E.; & Kallander, J. W., “Software Requirements for the A-7E Aircraft”, Technical Report 3876. Washington, D.C.: Naval Research Laboratory, 1978.

[Heninger, 1980] Heninger K.L., “Specifying software requirements for complex system. New techniques and their applications”, IEEE Trans., On Software Engineering, SE-6(1), 2-13, 1980.

[Hermiz, 1999] Hermiz K., “Critical Success Factors for Data Mining Projects”, DM Review Magazine, February 1999, disponible en línea en http://www.dmreview.com/issues/19990201/164-1.html.

[Hernández, 2004] Hernández J., et al “Introducción a la Minería de Datos”, Ed. Prenntice Hall, 2004.

[Herrera, 2005] Herrera L. “Ingeniería de Requerimientos”, [en línea], disponible en: http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php [Consulta: 23 de Junio de 2005].

[Hodge, 1998] Hodge B. j., Anthony W. P., Gales L. M., “Teoría de la organización, un enfoque estratégico”, Ed. Prentice hall, 1998.

[Houghton, 1992] Houghton Mifflin Company. “The American Heritage Dictionary of the English Language”, 3rd Edition, Houghton Mifflin Company, Electronic Version. 1992.

[Hoy, 1991] Hoy W.K., and Miskel C.G., “Educational Administration: Theory, Research, and Practice (4th edition)”, McGraw-Hill, New York, NY, 1991.

[IEEE, 1990] Glosario IEEE Estándar 610.12-1990.

209

[IEEE, 1998] IEEE/ANSI 830-1998, “Recommended Practice for Software Requirements Specifications”, IEEE, NY, 1998.

[Isixsigma, 2005] Portal www.isixsigma.com, “consulta sobre metodología 6-Sigma” [en línea], disponible en: http://www.isixsigma.com/sixsigma/six_sigma.asp [Consulta: 23 de Junio de 2005].

[ISO, 1993] ISO, “Information Technology Programming Languages –VDMSL ISO/IEC/JTC1/SC22/WG19”, n-20 edition, Noviembre, 1993.

[Jacobson, 1993] Jacobson I., Christerson M., Jonsson P., y Övergaard G., “Object–Oriented Software Engineering: A Use Case Driven Approach”. Addison–Wesley, 4ta. edición, 1993.

[Johnston, 2004] Johnston S., “Rational UML Profile for Business Modeling”, Julio, 2004, disponible en línea http://www-128.ibm.com/developerworks/rational/library/ 5167.html#author1 [Consulta: 12 Diciembre de 2007].

[Johnson, 2001] Johnson, J. H., 2001. “Micro Projects Cause Constant Change”, In: Extreme Programming Conference (XP2001), Villasimius, Cagliari, Italy (May).

[Jones, 1980] Jones, C. B. “Software, Development : A Rigorous Approach”, Ed. Prentice Hall, Londres, 1980.

[Kang, et. al., 1995] Kang B., Compton P., and Preston P., (1995) “Multiple Classification Ripple Down Rules: Evaluation and Possibilities”, Proceedings 9th Banff Knowledge Acquisition for Knowledge Based Systems Workshop Banff. Feb 26 - March 3 1995, Vol. 1: 17.1-17.20.

[Kantardzic, 2005] Kantardzic M., and Zurada J., “Trends in Data Mining Applications:From Research Labs to Fortune 500 Companies”, Next Generation of Data Mining Applications”, IEEE, Wiley Interscience, 2005.

[kdnuggets, 2007] Portal www.kdnuggets.com, “consulta sobre metodologías utilizadas en Data Mining”, [en línea], disponible en: http://www.kdnuggets.com/polls/2007/data_mining_methodology.htm [Consulta: 10 de Junio de 2008].

[Kelley, 2003] Kelley Ch., Adelman S., “¿Where can I find sources about failed data mining projects and the reason for their failure?”, DM Review Online Published in April 2003, DMReview.com.

[Kimball, 1998] Kimball R. et al, “The Data Warehouse Lifecycle Toolkit”, New Cork, John Wiley and Sons, 1998.

[Knorr, 2001] Knorr K., & Rohrig S., “Security Requirements of E-Business Processes,” 73-86. Towards the E-Society: E-Commerce, E-Business, and E-Government. Edited by B. Schmid, K. Stanoevska-Slabeva, and V. Tschammer. First IFIP Conference on E-Commerce, E-Business, E-Government, Zurich, Switzerland, Oct. 4-5, 2001. Norwell, MA: Kluwer Academic Publishers, 2001 (ISBN 0792375297).

[Komer, 1993] Komer P., “Dirección de la Mercadotecnia”, Séptima Edición, España, Prentice Hall, 1993.

[Kotonya, 1998] Kotonya G. and Sommerville I., “Requirements Engineering. Processes and techniques”, USA. J. Wiley, 1998.

210

[Koubarakis, 2002] Koubarakis M. and Plexousakis D., “A Formal Framework for Business Process Modeling and Design”, Information Systems, Vol. 27, No. 5, pages 299-319, July 2002.

[Kruchten, 1995] Kruchten P. B., “The 4+1 view model of architecture”, IEEE Software, vol. 12, Nov, 1995, pp. 42-50.

[Kruchten, 1999] Kruchten P. B., “The Racional Unified Process”, Addison-Wesley, 1999.

[Lagha, 2004] Lagha B., Osterwalder A. and Pigneur Y., “An ontology for e-business models”, In Value Creation from E-Business Models. W. Currie, Butterworth- Heinemann, 2004.

[Lano, 1995] Lano K. C. and Haughton H. P., “Formal development in B Abstract Machine Notation”, Information and Software Technology, 37(5–6):303–316, Mayo–Junio 1995.

[Larman, 1999] Larman C., “UML y Patrones, introducción al análisis y diseño orientado a objetos”, Ed. Prentice Hall, 1999.

[Larman, 2002] Larman C., “Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process”, Second Edition, Ed. PH PRT, 2002.

[Larman, 2003] Larman C., “UML y Patrones, una introducción al análisis y diseño orientado a objetos y al proceso unificado”, 2ª. Edición, Ed. Prentice Hall, 2003.

[Lasserre, 2006] Lasserre C., Apuntes de Ingeniería de Software II, Universidad de Jujuy-Argentina, [en línea], disponible en: http://www.fi.unju.edu.ar /materias/cyrax/document/document.php?cidReq=IS2&curdirpath=%2FM%C9TRICA_v3%2FT%E9cnicas_y_Pr%E1cticas, consulta 08 de enero de 2009.

[Lamsweerde, 1991] Lamsweerde Van, Dardenne, A., “The KAOS Project: Knowledge Acquisition in Automated Specification of Software”, In: Proceedings of the AAAI Spring Symposium Series, Stanford University, 1991.

[Laudon, 2002] Laudon K., and Laudon J., “Sistemas de Información Gerencial, organización y tecnología de la empresa conectada en red”, Ed. Prentice Hall, 2002.

[Laudon, 2004] Laudon K., and Laudon J., “Sistemas de Información Gerencial”, Ed. Prentice Hall, 2004.

[Lechner, 2002] Lechner U. and Hummel J., “Business models and system architectures of virtual communities: From a sociological phenomenon to peer-to-peer architectures”, International Journal of Electronic Commerce 6(3): 41-53, 2002.

[Leiwo, 1999] Leiwo J.; Gamage C.; & Zheng Y., “Organizational Modeling for Efficient Specification of Information Security Requirements”, 247-260. Advances in Databases and Information Systems: Third East European Conference, ADBIS’99. Maribor, Slovenia, Sept. 13-16, 1999. Berlin, Germany: Springer-Verlag, 1999 (Lecture Notes in Computer Science Vol. 1691).

[Leffingwell, 2000] Leffingwell D. and Widrig D., “Managing Software Requirements: A Unified Approach”, The Object Technology Series, Addison-Wesley, 2000.

211

[Li, 2005] Li Jijian, Li Liwei, “On the critical success factors for B2B e-marketplace”, Proceedings of the 7th international conference on Electronic Commerce ICEC’05, ACM Press, 2005.

[Linder, 2000] Linder J. and Cantrell S., "Changing Business Models: Surveying the Landscape", accenture Institute for Strategic Change, 2000.

[Loucopoulos, 1995] Loucopoulos P. & Karakostas V., “System Requirements Engineering”, McGraw-Hill, Berkshire, UK, 1995.

[Maciaszek, 2005] Maciaszek L., “Requirements Análisis and System Design”, 2a Edition, Ed. Addison Wesley, 2005.

[Maddison, 1983] Maddison R. N., “Information System Methodologies”, Wiley Henden, 1983.

[Magretta, 2002] Magretta J., “Why Business Models Matter”, Harvard Business Review, mayo 2002.

[Maiden, 1998] MAIDEN N., 1998, “CREWS-SAVRE: Scenarios for Acquiring and Validating Requirements”, Automated Software Engineering, 5(4): 419-446.

[Marbán, 2003] Marbán O. “Modelo matemático paramétrico de estimación para proyectos de Data Mining (DMCOMO)”, Tesis Doctoral, Facultad de Informática, Universidad Politécnica de Madrid, 2003.

[Marbán, 2007] Marbán O., et al, “An Engineering Approach to Data Mining Projects”, IDEAL 2007, LNCS 4881, pp. 578–588, Springer-Verlag, Berlin Heidelberg 2007.

[Marbán et al., 2008] Marbán O., et al, “Toward Data Mining Engineering: A software engineering approach”, Informat Systems (2008), doi: 10.1016/j.is.2008.04.003.

[March, 1982] March J.G. (1982), “Emerging developments in the study of higher education”, The Review of Higher Education, Vol. 6, pp. 1-18.

[Martínez, 2002] Martínez A., y otros, “From Early Requirements to User Interface Prototyping: A methodological approach”, 17th IEEE International Conference on Automated Software Engineering 2002, September 23-27, 2002, Edinburgh, UK.

[Martínez, 2003] Martínez de Pisón, “Optimización mediante técnicas de minería de datos del ciclo de recocido de una línea de galvanizado”, Tesis Doctoral, Universidad de La Rioja, Servicio de Publicaciones, 2003.

[Martins, 2005] Martins A., Déharbe D., “Software Engineering with the B Method”, 8th Brazilian Symposium on Formal Methods, 2005.

[Maté, 1988] Maté J.L., “Ingeniería del Conocimiento: diseño y construcción de sistemas expertos”, CETTICO, SEPA, Argentina, 1988.

[McDonald, 2006] McDonald M.P., JaffarianT., and Stevens S., “Growing its contribution: The 2006 CIO Agenda”, Gartner group, http://www.gartner.com, 2006.

[McLeod, 2000] McLeod R., “Sistemas de Información Gerencial”, Ed. Prentice Hall, 2000.

212

[Medina, 2004] Medina J.C., “Análisis comparativo de Técnicas, Metodologías y Herramientas de Ingeniería de Requerimientos”, tesis de maestría en Ingeniería Eléctrica opción Computación, Centro de Investigación y de Estudios Avanzados del IPN, México, Junio de 2004.

[Meiyi, 2003] Maiyi C., “Review Report on Requirements Engineering in Automotive Development: Experiences and Challenges”, SC207 Software Engineering. Nanyang Technological University, 2003.

[Menasalvas, 2004] Menasalvas Ernestina, “CRM y Data Mining”, Facultad de Informática-UPM, 2004.

[Milton, 2003] Milton N., Portal http://www.epistemics.co.uk, “Repertory Grid Technique” [en línea], disponible en: http://www.epistemics.co.uk, 20 de noviembre de 2003, [Consulta: 18 de julio de 2005].

[Moxon, 1996] Moxon, B., “Defining Data Mining”, DBMS, Datawarehouse Suplement, Agosto 1996.

[Mylopoulos, 1999] Mylopoulos J., Cheng L. et al., "From object-oriented to goal-oriented requirements analysis", Communications of the ACM 42(1): 31-37, 1999.

[Naur, 1968] Naur P. and Randell B., “Software Engineering”, Report on a conference sponsored by the NATO SCIENCE COMMITTEE Garmisch, Germany, 7th to 11th October 1968.

[Nava, 2006] Nava Condarco C., “Negocio y estrategia”, [en línea], disponible en: http://www.gestiopolis.com/canales/gerencial/articulos/36/negest.htm, [Consulta: 16 de abril de 2006].

[Normann, 1994] Normann, R, “Designing Interactive Strategy – From Value Chain to Value Constellation”, John Wiley & Sons,Chichester, 1994.

[NoticiasDot, 2002] Portal http://www2.noticiasdot.com, Diario del mundo digital, “Consulta sobre noticias de actualidad” [en línea], disponible en http://www2.noticiasdot.com/publicaciones/2002/0702/0307/noticias0307/noticias0307-1.htm, [consulta: 29 de Abril de 2006].

[Nuseibeh, 2001] Nuseibeh B., 2001. "Weaving the Software Development Process Between Requirements and Architecture", In: Proceedings of the ICSE2001 International Workshop: From Software Requirements to Architectures (STRAW-01), Toronto, Canada.

[Ochoa, 2006] Ochoa A., “Uso de Técnicas de Educción para el Entendimiento del Negocio”, Tesis de Magister en Ingeniería del Software. Escuela de Postgrado. Instituto Tecnológico de Buenos Aires, 2006.

[Olivero, 2006] Olivero L., “El Proceso de Toma de Decisiones”, Carlos Albizu University, Puerto Rico, [en línea], disponible en: http://sju.albizu.edu/ [Consulta: 22 de junio de 2006].

[Omega, 2006] Portal http://omega.ilce.edu.mx, Glosario [en línea], disponible en: http://omega.ilce.edu.mx:3000/sites/ciencia/ volumen2/ciencia3/070/ htm/sec_82.htm, [Consulta: 29 de junio de 2006].

[Oracle, 2005] Portal Oracle Development Tools, [en línea], disponible en http://www.oracle.com/tools/index.html, [Consulta: 12 de Septiembre de 2005].

213

[Ortin, 2000] Ortín M.J., García Molina J., Moros B., et al., “De los procesos de negocio a los casos de uso” , JISBD 2000, Valladolid, España Fecha: Noviembre 2000.

[Osterwalder, 2005] Osterwalder A., Pigneur Y., “CLARIFYING BUSINESS MODELS: ORIGINS, PRESENT, AND FUTURE OF THE CONCEPT”, Communications of AIS, Volume 15, Article, May, 2005.

[Ould, 1995] Ould M. A., “Business Processes - Modelling and Analysis for the Re-engineering and Improvement”, John Wiley & Sons Ltd., Chichester, England, 1995.

[Pateli, 2003] Pateli A. and Giaglis G., “A Framework for Understanding and Analysing e-Business Models”, Proceedings of the Bled Electronic Commerce Conference, 2003.

[Pérez, 2007] Pérez C. y Santín D., “Minería de Datos, técnicas y herramientas”, Ed. Thomson, 2007.

[Piattini, 1996] Piattini M. G., Calvo-Manzano J. A., Cervera J., Fernández L., “Análisis y Diseño Detallado de Aplicaciones Informáticas de Gestión”, Rama, 1996.

[Pohl, 2006] Pohl Klaus, “The three dimensions of requirements engineering”, Springer Berlin / Heidelberg, 2006.

[Porter, 1997] Porter M., “Ventaja Competitiva”, 10ª Edición, Ed. Continental, México, 1997.

[Prekas, 2000] Prekas N. and Loucopoulos P., “Combining Strategy and Deliberation in the RE Process”, Proceedings of the 11th International Workshop on Database and Expert Systems Applications (DEXA'00).

[Raghavan, 1994] Raghavan S., Zelesnik G. y Ford G., “Lecture Notes on Requirements Elicitation”, Educational Materials CMU/SEI–94–EM –10, Software Engineering Institute, Carnegie Mellon University, 1994. http://www.sei.cmu.edu.

[Randell, 1996] Randell B., “The 1968/69 NATO Software Engineering Reports”, Dagstuhl-Seminar 9635: "History of Software Engineering", Schloss Dagstuhl, August 26 - 30, 1996.

[Reinartz, 1995] Reinartz T. & Wirth R., “The Need for a Task Model for Knowledge Discovery in Databases”, In:Kodratoff, Y., Nakhaeizadeh, G., & Taylor, C. (eds.), Workshop Notes Satatistics, Machine Learning, and knowledge Discovery in Databases, MLNet Familiarization Workshop, April, 28-29, Heraklion, Crete, pp. 19-24. 1995.

[Resof, 2005] Portal www.monografias.com, “Ingeniería de Requisitos, Ingeniería de Software”, [en línea], disponible en: http://www.monografias.com/trabajos6/resof/resof2.shtml#teec [Consulta: 19 de Abril de 2005].

[Richards, 2000] Richards D., “A Process Model for Requirements Elicitation”, Department of Computing Division of Information and Communications Sciences Macquarie University, Sydney, Australia, 2000.

214

[Rilston, 2003] Rilston, F., Paim, S., and Castro, J., “DWARF: An Approach for Requeriments Definition and Management of Data Warehouse Systems”, 11th IEEE International Requirements Engineering Conference (RE'03), p-75, 2003.

[Robertson, 1999] Robertson S. and Robertson J., “Mastering the Requirements Process”, Addison Wesley Professional, 1999.

[Ross, 1977] Ross Douglas, “Structured Analysis (SA): A Language for - Communicating Ideas”, IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, Vol. SE-3, NO. 1, JANUARY 1977.

[RQP, 2005] Portal Rational Requisite Pro, [en línea]. Disponible en http://www-306.ibm.com/software/awdtools/reqpro/ [Consulta: 04 de Julio de 2005].

[Rugg, 2003] Rugg, G., Homepage de Gordon Rugg, [en línea], disponible en: http://mcs.open.ac.uk/gr768/elicitation/methods/laddering/ laddering.shtml, site designed by Ed. De Quincey, 2003, [Consulta: 18 de julio de 2005].

[Rumbaugh et al. 1991] Rumbaugh J., Blaha M., Premerlani W., Eddy F., Lorensen W., “Object Oriented Modeling and Design”, Prentice-Hall, 1991.

[Russell, 2006] Russell N., eta al., “On the Suitability of UML 2.0 Activity Diagrams for Business Process Modelling”, Third Asia-Pacific Conference on Conceptual Modelling (APCCM2006), Hobart, Australia. Conferences in Research and Practice in Information Technology, Vol. 53., 2006.

[SAS, 2003] Portal www.sas.com, “Descripción de la metodología SEMMA”, [en línea], disponible en: http://www.sas.com/technologies/analytics/ datamining/miner/semma.html [Consulta: 19 de Abril de 2005]. [Sawyer, 1997] Sawyer P. and Sommerville I., “Requirements, Engineering: A good practice guide”, Ed, Wiley, 1997.

[Sánchez, 2006] Sánchez M. A., “Una recomendación para el desarrollo de software en un contexto de negocio bajo demanda de acuerdo a la especificación MDA y la arquitectura SOA”, tesis doctoral, Universidad Pontificia de Salamanca, 2006.

[Santander, 2002] Santander V., Castro J., “Deriving Use Cases from Organizational Modeling”, Proceedings of the IEEE Joint International Conference on Requirements Engineering (RE’02), IEEE, 2002.

[Schewe, 2000] Schewe K.D., “UML: A modern dinosaur? – A critical analysis of the Unified Modelling Language”, 10th European – Japanese Conference on Information Modelling and Knowledge Bases, Saariselk, Finlandia, 2000.

[Scheneider, 1998] Scheneider G. y Winters J. P., “Applying Use Cases: a Practical Guide”, Addison–Wesley, 1998.

[Sharma, 2009] Sharma S., et al. “Framework for formal implementation of the business understanding phase of data mining projects”, Expert Systems with Applications 36 (2009) 4114–4124.

[Sharp, 1999] Sharp H., Finkelstein A. & Galal G., “Stakeholder Identification in the Requirements Engineering Process”, Centre for HCI Design, School of Informatics, City University, Northampton Square, London EC1V 0HB, UK; Computer Science Department, University College London, Gower Street, London WC1E 6BT, UK, 1999.

215

[Simon, 1993] Simon H.A., “Decision making: rational, nonrational, and irrational”, Educational Administration Quarterly, Vol. 29, pp. 392-411., 1993.

[Slagell, 2002] Slagell M. et al., “A Software Fault Tree Approach to Requirements Analysis of an Intrusion Detection System.” Requirements Engineering 7, 4 (December 2002): 207-220.

[Sommerville, 2002] Sommerville I., “Ingeniería de Software”, 6ta. Edición, Ed. Addison Wesley, 2002.

[Sommerville, 2005] Sommerville I., “Ingenieria de Software”, 7ma. Ed., Pearson, Addison Wesley, 2005.

[Soren, 2002] Lauesen Soren, “Software Requirements, Styles and Techniques”, Eddison Wesley, Pearson Education Book, 2002.

[Spivey, 1988] Spivey J.M, “Understanding Z: A Specification Language and its Formal Semantics”, Volume 3, Cambridge Tracts in Theoretical Computer Science, Cambridge University Press, Cambridge, 1988.

[Spivey, 1992] Spivey J.M, “The Z Notation: A Reference Manual”, 2nd edition. Prentice Hall International Series in Computer Science, London, 1992.

[SPSS, 2005] Portal www.spss.com “SPSS Home Page” [en línea] disponible en: http://www.spss.com [Consulta: 29 de junio de 2005].

[Stähler 2002] Stähler P., “Business Models as an Unit of Analysis for Strategizing”, Proceedings of the 1st International Workshop on Business Models, 2002.

[Steiner, 2003] Steiner George, “Planeación Estratégica”, Compañia Editorial Continental, 2003.

[Suderman, 1997] Suderman M. “Abstract Data Types in VDM-SL”, Trinity Western University, [en línea] disponible en: http://www.vdmportal.org /twiki/bin/view/Main/VDMSLexamples [Consulta: 29 de Diciembre de 2008].

[Sumano, 2002] Sumano M. A., “Método para el análisis de requerimientos de software con enfoque conjunto psicológico, social y lingüístico conducente al reuso”, Tesis doctoral, Universidad Veracruzana, IPN, 2002.

[Summers, 2006] Summers D., “Administración de la Calidad”, Ed. Pearson Educación, 2006.

[Tarter, 1997] Tarter J. and Hoy W., “Toward a contingency theory of decision making”, Journal of Educational Administration 36, 3, 1997.

[Teicherow, 1977] Teicherow D. and Hershey E., “PSL/PSA A computer aided technique for structured documentation and analysis of computer-based information systems,” IEEE Transactions on Software Engineering3, No. 1, 41-48 (1977).

[Thearling, 1999] Thearling K. “Increasing Customer Value by Integrating, Data Mining and Compaign Management Software”, Direct Marketing Magazine, Febrero de 1999.

[Thomas, 1984] Thomas H., “Mapping strategic management research”, Journal of General Management, Vol. 9, pp. 55-72, 1984.

216

[Thomas, 1998] Thomas S. “Método Analítico Jerárquico (AHP): Principios Básicos en: Evaluación y Decisión Múlticriterio: Reflexiones y Experiencias”, Editado por Eduardo Martínez y Mauricio Escudey, Editorial Universidad de Santiago, Pp 17-46, 1998.

[Toranzo, 2002] Toranzo M., “A Proposal for Improving Requirements Traceability” (in portuguese), PhD Thesis, Federal University of Pernambuco, December 2002.

[Tovar, 2004] Tovar E., “Ingeniería de Requisitos”, apuntes programa de doctorado conjunto UCN – UPM, Antofagasta, 2004.

[Vallecillo, 2008] Vallecillo A., “Métodos Formales para Sistemas Abiertos”, Depto. Lenguajes y Ciencias de la Computación, Universidad de Málaga, [en línea], disponible en: http://www.lcc.uma.es/~av/Docencia/Doctorado/[Consulta: 27 de noviembre de 2008].

[Viller, 1999] Viller S., Sommerville, I., “Social Analysis in the Requirements Engineering Process: From Ethnography to Method”, In: Proceedings of the 4th International Symposium on Requirements Engineering, Limerick, Ireland 1999.

[VisualUml, 2005] Portal http://www.visualuml.com/ “Visual UML” [en línea], disponible en: http://www.visualuml.com [Consulta: 29 de junio de 2005].

[Volere, 2005] Portal http://www.volere.co.uk/, “Requirements Specification Template”, disponible en http://www.volere.co.uk/rstrtf.htm [Consulta, 07 de noviembre de 2005].

[Wallin, 2000] Wallin J., “Operationalizing Competencies”, 5th Annual International Conference on Competence-Based Management, Helsinki, June 10-14, 2000.

[Weber, 2003] Weber M. and Weisbrod J., “Requirements engineering in automotive development: Experiences and challenges”. IEEE Software, pages 16 –24, Enero/Febrero 2003.

[White, 2004] White S., IBM Corporation, “Introduction to BPMN”, Stephen A. White, All Rights Reserved, www.bptrends.com, BPTrends July, 2004.

[White, 2006] White S. “Introduction to BPMN”, IBM Software Group, IBM, 2006.

[Wordsworth, 1996] Wordsworth J., “Software Engineering with B. Wokingham”, Ed. Addison-Wesley, 1996.

[Yu, 1994] Yu Eric and Mylopoulus J., “Understanding “Why” in Sotware Process Modelling, Analysis, and Design”, Proc. 16th Int. Conf. Software Engineering, May 16-21, 1994, Sorrento, Italy.

[Yu, 1995] Yu Eric, “Modelling Strategic Relationships for Process Reengineering”, Ph.D. thesis, Department of Computer Science, University of Toronto,1995.

[Yu, 1996] Yu Eric and Mylopoulos J., “AI Models for Business Process Reengineering.”, in IEEE Expert Intelligent Systems and Their Applications. IEEE Computer Society. Volume 11, Number 4. pp. 16-23, 1996.

217

[Yu, 1997] Yu Eric and Mylopoulos J., “Enterprise Modelling for Business Redesign: The i* Framework”, Special Issue: Enterprise Modelling Papers, SIGGROUP Bulletin, Vol. 18, No. 1 (April 1997).

[Yu, 2001] Yu Eric, “Strategic Actor Relationships Modelling with I*”, (presentación de PowerPoint), Trento, Italia, December 13-14, 2001.

[Zornes, 2003] The Top 5 Global 3000 Data Mining Trends for 2003/04 Enterprise Analytics Strategies, Application Delivery Strategies, META Group Research-Delta Summary, 2061, March 26, 2003.

219

ANEXO A: FASE DE COMPRENSIÓN DEL DOMINIO DE NEGOCIO.

Tabla A.1. Identificación de fuentes de información.


Tipo de fuente

Características

Información

Personal

Sr. Orlando Castro Auditor General de la

Universidad Católica del Norte (UCN).

Describe el dominio del negocio, datos sobre información a elicitar y nuevas fuentes de información.

Sitio Web http://www.ucn.cl

Sitio Web de la Universidad Católica del Norte, contiene información sobre la estructura organizacional, además de la reglamentación vigente.

Documento Plan de Desarrollo Corporativo 2004-2008

Describe el plan de trabajo quinquenal de la Universidad.

Documento Balance de Gestión Anual 2006

El Documento contiene un balance de las actividades que se realizaron entre los años 2004 y 2006. Se destacan los principales objetivos estratégicos que ya se cumplieron o que se encuentran en proceso de finalización.

Documento Proyecto Educativo 2007

El Proyecto Educativo es el marco conceptual que explicita las intencionalidades de formación de los estudiantes de la UCN. En él, la Universidad define las características del profesional que desea formar, expresando una posición educativa propia que involucra a los diversos integrantes de la institución.

220

Tabla A.2. Información Escenario Actual.

Visión: Escenario Actual

Nombre


Misión

La Universidad Católica del Norte, sustentada en los valores del Humanismo Cristiano, tiene como misión, la constante búsqueda de la verdad para contribuir al desarrollo de la persona, de la sociedad y de la herencia cultural de la comunidad, mediante la docencia, la investigación y la extensión.

Visión

Ser reconocida como una Universidad Católica, de vanguardia, responsable socialmente. Para ello debe:

o Estar en el grupo de Universidades de avanzada del Sistema Nacional de Educación Superior.

o Formar personas íntegras, innovadoras y emprendedoras.

o Constituir una comunidad de aprendizaje, de creación y transmisión de conocimientos, articulando vínculos entre estudiantes, académicos, y funcionarios, mediante políticas y prácticas que permitan el desarrollo de las personas.

Estructura Organizacional

La estructura organizacional y niveles de autoridad están constituídas por el Gran Canciller, el Consejo Superior y el Rector de la Universidad, el cual tiene a su cargo las Vicerrectoría Académica, Vicerrectoría de Asuntos Económicos y Administrativos, Vicerrectoría Sede Coquimbo, Secretaría General, Auditoría General, Dirección de Comunicaciones y Extensión, Dirección de Relaciones Institucionales de la Universidad y las Facultades de las distintas Carreras que se imparten. El organigrama de la UCN se ilustra en la figura A1. Los distintos profesionales que desempeñan los principales cargos directivos son:

o Gran Canciller: Monseñor Pablo Lizama Riquelme.

o Vice Gran Canciller: Padre André Marie René Hubert.

o Rector: Dr. Misael Camus Ibacache

o Vicerrector Académico: Sr. Mario Pereira.

o Vicerrector de Asuntos Económicos y Administrativos: Sr. Marcelo Leonardo Lufin Varas.

o Vicerrector de Sede: Sr. Luis Héctor Moncayo Martínez.

o Secretario General: Sra. Victoria Gonzáles Stuardo.

o Auditor General: Sr. Orlando Darío Castro Campusano.

o Director de Comunicación y Extensión: Sra. Giannina Silvana Marré Guzmán.

o Director de Relaciones institucionales de la Universidad: Sra. Dania Trista Pérez. La Universidad Católica del Norte cumple las funciones académicas propias de docencia, investigación, extensión y asistencia técnica a través de sus Facultades y otros organismos que establece el Consejo Superior. Las Facultades son unidades académicas que, en conformidad con el Estatuto y los Reglamentos de la Universidad, agrupan a un cuerpo de personas asociadas con el propósito de enseñar e investigar en una misma área o en áreas afines del conocimiento superior. Cada Facultad está dirigida por un Decano y tiene como organismo colegiado un Consejo de Facultad. Las actividades de los organismos académicos distintos a las Facultades, se desarrollan dentro del

221


marco que fijan sus Reglamentos y las atribuciones de los Consejos respectivos cuando corresponda. Un Reglamento especial dictado por el Rector, con acuerdo del Consejo Superior establece los procedimientos para elegir los cargos de Decanos y Directores, como asimismo, la integración y atribuciones de los Consejos respectivos cuando corresponda.

Figura A1. Organigrama Universidad Católica del Norte.

Metas Organizacionales

Objetivos estratégicos

Objetivos específicos


1.1. Reconocer, asumir e influir en el perfil de ingreso de los postulantes. 1.2. Desarrollar e implementar un perfil de egreso, en el marco del humanismo cristiano, que considere las exigencias de competencias tales como innovación, emprendimiento, creatividad, ejercicio de liderazgo, trabajo en equipo, uso de tecnologías de información, que requiere el desarrollo del país. 1.3. Fortalecer una planta académica que cumpla con las competencias que requiere el Proyecto Educativo. 1.4. Institucionalizar un proceso continuo de evaluación y aseguramiento de la calidad. 1.5. Diseñar currículos que ofrezcan la alternativa de estudio continuo, conducente al grado académico de maestría. 1.6. Diseñar un plan de educación continua que incluya la capacitación, el

222


2. Fortalecer capacidades para la adquisición, creación y transferencia de conocimiento y tecnología. 3. Promover el sentido de pertenencia de la comunidad universitaria y la identidad de la institución. 4. Vincular a la UCN con su entorno, como un actor influyente en el desarrollo del bienestar de las personas y de la sociedad. 5. Desarrollar un modelo de gestión de los recursos, capacidades y competencias de la UCN.

aprendizaje virtual (e-learning) y los nuevos perfiles de demanda por educación superior. 2.1. Incrementar y consolidar los programas de Postgrado (Maestrías y Doctorados). 2.2. Alcanzar estándares de productividad científica que posicionen a la UCN dentro de las universidades de investigación. 2.3. Fomentar mecanismos de transferencia tecnológica. 3.1. Definir un modelo de comunicación que fomente una identidad universitaria y que construya la imagen corporativa de la UCN. 3.2. Difundir e internalizar los valores corporativos en la comunidad universitaria. 3.3. Fortalecer el sentido de pertenencia del personal académico, estudiantes y personal de apoyo a la academia, hacia la institución. 3.4. Fomentar ambientes de comunicación que enriquezcan el diálogo y la relación entre los integrantes de la comunidad universitaria. 3.5. Desarrollar programas de vinculación de la universidad con sus ex alumnos. 4.1. Insertar la actividad académica en el desarrollo regional y nacional. 4.2. Promover el cultivo de las ciencias, las artes y las letras con el objeto de incrementar el acervo cultural. 4.3. Profundizar y difundir una lectura cristiana del acontecer social, político y cultural desde una perspectiva multi e interdisciplinaria. 4.4. Propiciar la reflexión sobre temas relevantes para la sociedad, aportando a la formación de una conciencia crítica y creadora, al interior de ella. 5.1. Mejorar los sistemas de evaluación de la actividad académica y de apoyo a la academia, y el control de gestión de los recursos financieros y materiales de la UCN. 5.2. Formular y aplicar políticas de desarrollo de los Recursos Humanos que favorezcan la eficiencia y eficacia del personal y organizacional. 5.3. Diseñar un plan de obtención de recursos, que incorpore en forma creciente, la diversificación de las fuentes de financiamiento. 5.4. Definir un nuevo modelo de asignación presupuestaria y reformular los presupuestos de trabajo de la Universidad, sobre la base de planes maestros trienales, acordes a metas de desempeño. 5.5. Definir e implementar, un sistema integral de gestión de inversiones, que considere las inversiones nuevas, el mantenimiento, reposición y mejoramiento de la infraestructura y equipamiento generales de la universidad. 5.6. Iniciar un proceso de revisión sistemática y participativa de las normativas

223


actuales de la Universidad, a objeto de que permitan adecuarlas a la realidad vigente en la institución y en el país.

Reglas de negocio

Normativa Legal

Normativa Eclesiástica

Normativa Interna

Constitución política del estado. Ley Orgánica Constitucional de Enseñanza (ley 18.962). Ley de creación de la Universidad del Norte (ley 15.561). Decretos con fuerza de ley nº 1,2,3 y 4 de 1981. Legislación general nacional.

Código de derecho canónico. Ley Orgánica Constitucional de Enseñanza (ley 18.962).

Estatutos Universitarios. Normativa laboral. Normativa sobre docencia. Normativa sobre Investigación y extensión. Normativa Estudiantil Otras Normativas.

Propuesta de Valor

Servicio Características Justificación Formación de profesionales. Investigación y extensión. Asistencia Técnica.

Generar personas íntegras, innovadoras y emprendedoras

Adquirir capacidades académicas para desempeñarse en el mundo laboral

Mercado

La UCN no tiene un segmento de clientes objetivos, sin embargo se puede mencionar que dentro del universo de estudiantes que ingresan a la Universidad, existen perfiles y preferencias de estudiantes. Uno de estos perfiles es el alto número de estudiantes de la región.

Evaluación Interna del Negocio

Fortalezas Debilidades

224


Calidad y prestigio. Ser una universidad tradicional con una planta académica estable y una capacidad creciente de generación y transferencia de conocimiento. Tener un compromiso institucional con la calidad de la educación superior y disciplinas con buen desarrollo académico. Poseer 80% de carreras en proceso de innovación y creciente número de postgrados. Gestión interna. Ser una Universidad ordenada en su administración y gestión financiera con un buen nivel de profesionalización. Poseer la capacidad de asegurar flujos financieros. Contar con sistemas de información automática que permiten agilizar la toma de decisiones adecuadas. Imagen corporativa. Prestigio por estar entre las Universidades Católicas más antiguas del país y por mostrar un crecimiento responsable y sólido. Identidad y liderazgo reconocidos en la macro zona norte y por instituciones de cooperación internacional, acompañados por un incremento de relaciones a nivel nacional y mundial. Proyectos. Capacidad de generar y ganar proyectos institucionales, en particular Proyectos MECESUP y de Infraestructura. Identidad católica. Vivencia de la identidad católica en un contexto de pluralidad. Relaciones internas. Capacidad de diálogo entre los distintos estamentos y tendencias al mejoramiento de las relaciones alumnos/profesores.

Universidad y entorno. Débil relación de la Universidad con el entorno y baja influencia en los distintos niveles de decisión del país. Personal académico. A la desigualdad del desarrollo académico y la falta de políticas de contratación del personal se añaden la edad promedio avanzada de los académicos y el hecho de que algunas unidades tienen un planta reducida. Se prevé un estancamiento del número de académicos con doctorado por la estructura etárea de la academia. Sentido de pertenencia. Un cierto individualismo personal y organizacional con una estructura orgánica y normativa no actualizada, acentúa el débil compromiso con la institución. La carencia de políticas de comunicaciones corporativas y la falta de explicitación de los valores de la Universidad Católica del Norte, no permiten su asimilación por la comunidad. Esto se hace más notable, en el caso de los profesores/hora, los cuáles, por otra parte, reciben rentas poco atractivas. Academia. Deficiencias en materia de incentivos; así como en un sistema y cultura de evaluación. Carencia de un estándar de carga académica y ausencia de una carrera académica. Académicos sin actualización en metodologías de enseñanza y aprendizaje. Bajo retorno de la alta inversión que se realiza en postgrados, como por ejemplo, en el número reducido de publicaciones. Tecnología. Brecha tecnológica entre la Universidad y las empresas. Ausencia de renovación y de políticas de inversión en tecnologías. Carreras. Bajo porcentaje de carreras con planes de estudios actualizados y escaso uso de la plataforma de las TI. Menos del 6% de las carreras en proceso de acreditación. Carencia de un plan general que asocie postgrado y carrera. Falta de carreras pedagógicas Recursos. Carencia de estrategias para captar nuevos recursos financieros. Alumnos. Estudiantes con un perfil académico deficitario y pobreza cultural en el uso del idioma materno. Alta relación numérica alumnos/docente. Falta de oportunidades de salidas intermedias para estudiantes que no logran concluir su carrera.

225


Evaluación Externa del Negocio

Oportunidades Amenazas

Nuevos escenarios. El desarrollo del país, la firma de Tratados de Libre Comercio y Cooperación y las reformas del Estado permiten participar en la obtención de nuevos recursos de los sectores tanto públicos como privados. El Sistema de Acreditación Universitaria Nacional, promoverá el aseguramiento de la calidad de la educación superior del país. Mercado. Dentro del proceso de descentralización nacional y el creciente desarrollo de las regiones, crece la demanda de educación superior tanto en cantidad como en calidad; así como en la formación de postítulo y postgrado. Ubicación geográfica. Emplazamiento de la Universidad Católica del Norte en una región geográfica única, caracterizada por el desierto y el mar, con la posibilidad de proyectar una imagen potente y diferenciadora. Reconocimiento institucional. Creciente percepción, por parte del entorno, de la Universidad Católica del Norte como actor relevante a nivel regional y nacional.

Mercado. Competencia creciente de las universidades privadas en la oferta de carreras de pregrado, contratación de académicos, captación de alumnos con altos puntajes y obtención de fondos públicos. Presencia de universidades extranjeras y universidades virtuales en el país. Postulantes. Disparidad de formación y déficit académico de los alumnos egresados de la enseñanza media. Aumento de postulantes que precisan de apoyo socio-económico. Marco normativo. Creciente competencia e incertidumbre sobre las reglamentaciones jurídicas que regularán los accesos a los fondos públicos.

Red de valor

Según la información obtenida de las fuentes de información, se diseña la red de valor de la UCN, que se observa en la figura A2 y que está centrada en la cadena de valor de Michael Porter1. Esta red de valor está formada por: Procesos primarios:

Incorporación de recursos: Ya sea profesorado, información, como también en tecnologías que ayuden en las tareas de servicio que entrega la Universidad. Actividades productivas: Las operaciones que realiza la Universidad, y que se dividen en las tres actividades mostradas en la figura, Docencia, investigación y extensión. Promoción institucional: Tareas que llevan al reconocimiento de la Universidad por la comunidad, así como el accionar frente al plan estratégico adoptado. Servicios relacionados: Productos que se obtienen de sus actividades productivas, tales como

226


investigaciones y asistencias técnicas, entre otras. Procesos de apoyo:

Tecnología de Información/Infraestructura: Desarrollo de tecnología para apoyar las actividades productivas de la Universidad. Recursos Humanos: Es la administración de los RRHH con actividades asociadas al desarrollo de docentes o académicos y funcionarios. Organización: Se refiere a la estructura organizacional que brinda apoyo y permite un flujo en las distintas actividades primarias de la Universidad.

Actividades Primarias

Act

ivid

ades

de

Apo

yo

Organización

Tecnología de Información / infraestructura

Administración Recursos Humanos

Incorporaciónde recursos

Actividades productivas

Promocióninstitucional

Servicios relacionados

ProfesoresInvestigadoresConocimientosTecnologíasAlumnosInformaciónEquipos

DocenciaInvestigaciónExtensión

Informar a la sociedadPosicionar la UniversidadPoner en contacto a empresas externas

PublicacionesInvestigaciónProyectosAsistencia técnica

Actividades PrimariasActividades Primarias

Act

ivid

ades

de

Apo

yoA

ctiv

idad

es d

e A

poyo

Organización

Tecnología de Información / infraestructura

Administración Recursos Humanos

Incorporaciónde recursos

Actividades productivas

Promocióninstitucional

Servicios relacionados

ProfesoresInvestigadoresConocimientosTecnologíasAlumnosInformaciónEquipos

DocenciaInvestigaciónExtensión

Informar a la sociedadPosicionar la UniversidadPoner en contacto a empresas externas

PublicacionesInvestigaciónProyectosAsistencia técnica

Figura A2. Red de valor de la UCN

1 Porter Michael E., Millar Victor E, "How Information gives you competitive advantage", Pág. 2-3, Harvard Business Review (2001)

Capacidades

Generar y ganar proyectos institucionales. Generar y transferir conocimiento. Capacidad de asegurar flujos financieros.

Estructura de Costes

Centrada en:

o Publicidad. o Capacitación docente. o Mejora de infraestructura. o Mantenimiento del Campus y seguridad. o Proyectos de investigación.

Glosario de Términos


227


Cohorte Grupo de alumnos que inician sus estudios en un programa educativo al mismo tiempo.

PDC

Plan de desarrollo corporativo. Es el plan estratégico que la Universidad adopta durante un período de tiempo.

228

Tabla A.3. Técnicas de educción utilizadas.

TÉCNICAS

INFORMACIÓN

Entre

vist

as

Encu

esta

s/C

uest

iona

rios

Doc

umen

tos E

xist

ente

s

Focu

s Gro

up

JAD

Obs

erva

ción

In S

itu

Wor

kSho

p

Misión X Visión X Estructura Organizacional X Metas Organizacionales X Reglas de Negocio X X Propuesta de valor X X Mercado X X Eval. Interna del negocio X Eval. Externa del negocio X Red de valor X X Capacidades X X Estructura de costos X X Glosario de términos X

229

Tabla A.4. Información Escenario Deseado.

Visión: Escenario Deseado

Nombre


Estrategias

Objetivo Estratégico

Objetivo Específico Línea de Acción


1.1. Reconocer, asumir e influir en el perfil de ingreso de los postulantes. 1.2. Desarrollar e implementar un perfil de egreso, en el marco del humanismo cristiano, que considere las exigencias de competencias tales como innovación, emprendimiento, creatividad, ejercicio de liderazgo, trabajo en equipo, uso de tecnologías de información, que requiere el desarrollo del país.

1- Desarrollar e implementar, un sistema de diagnóstico sobre el perfil de ingreso de los estudiantes de la UCN, que identifique su perfil académico, psicológico, social y valórico. 2- Diseñar estrategias de organización curricular y de apoyo a los estudiantes que ingresan a la universidad, para que enfrenten con éxito sus estudios superiores. 3- Diseñar estrategias de colaboración con el sistema de Educación Básica y Media, mediante la integración de profesores, estudiantes, padres y apoderados con la Universidad. 1- Definir el perfil de competencias, valores y actitudes característicos del alumno UCN. 2- Implementar reformas al sistema curricular, que potencien el perfil de competencias, valores y actitudes que caractericen al alumno de la UCN y que favorezcan la armonización de currículos a nivel nacional e internacional. 3- Diseñar e implementar modelos pedagógicos que permitan obtener el perfil esperado, potenciando el desarrollo de las competencias, habilidades y destrezas de los estudiantes, con apoyo de plataformas tecnológicas e integración con el entorno laboral. 4- Diseñar actividades que promuevan un mayor compromiso social y respondan a necesidades de la comunidad, incentivando y facilitando actividades en las áreas de deportes, artísticas, sociales, científico-tecnológicas y culturales que promuevan el desarrollo integral del alumno. 5- Confeccionar un nuevo Reglamento de Docencia de Pregrado que flexibilice el avance curricular, implementando mecanismos que lo evalúen y potencien, estandarizando criterios y metodologías para la revisión y modificación

230


2. Fortalecer

1.3. Fortalecer una planta académica, que cumpla con las competencias que requiere el Proyecto Educativo. 1.4. Institucionalizar un proceso continuo de evaluación y aseguramiento de la calidad. 1.5. Diseñar currículos, que ofrezcan la alternativa de estudio continuo, conducente al grado académico de maestría. 1.6. Diseñar un plan de educación continua, que incluya la capacitación, el aprendizaje virtual (e- learning) y los nuevos perfiles de demanda por educación superior. 2.1. Incrementar y consolidar

de los planes de estudios y currículos de las carreras, con una metodología coherente con el proyecto educativo de la UCN.

1- Poner en funcionamiento los Reglamentos del Académico y de Evaluación del Desempeño Académico. 2- Definir e implementar programas de desarrollo personal, de habilitación y/o perfeccionamiento docente y de capacitación en gestión académica, actualizando el perfil de competencias, valores y actitudes característicos del académico de la UCN, que sustente el proyecto educativo, haciéndolo exigible a todos los académicos.

1- Adoptar los sistemas de autoevaluación y de acreditación de pregrado e institucional. 2- Desarrollar un Centro de Innovación Pedagógica, Metodológica y Tecnológica, para que diseñe e implemente mecanismos de mejoramiento de la calidad de la docencia y se valide como referente de los procesos de innovación de los procesos de enseñanza aprendizaje. 3- Consolidar y difundir el Sistema de Indicadores Transversales de Docencia de la UCN e incentivar a las unidades académicas para que sobresalgan en su actividad docente.

1- Identificar áreas o disciplinas susceptibles de incorporar en sus currículos, la alternativa conducente al grado académico de maestría. 2- Implementar currículos conducentes al grado de maestría académica y/o profesional de acuerdo a las necesidades globales y de la macro zona andina.

1- Desarrollar el Centro de Educación a Distancia, para que se transforme y valide como referente y socio estratégico para el desarrollo de programas de educación continua virtual. 2- Estudiar, diseñar e implementar alternativas de programas docentes, que satisfagan los requerimientos de profesionales titulados y/o de la nueva demanda por educación superior.

1- Diseñar, planificar e implementar nuevos

231


capacidades para la adquisición, creación y transferencia de conocimiento y tecnología.

los programas de Postgrado (Maestrías y Doctorados). 2.2. Alcanzar estándares de productividad científica, que posicionen a la UCN, dentro de las universidades de investigación. 2.3. Fomentar mecanismos de transferencia tecnológica.

Programas de Postgrado, considerando estándares nacionales e internacionales, generando redes y/o alianzas estratégicas con otras instituciones de investigación. En el marco del Proyecto Educativo UCN, se considerará la enseñanza de la Ética Profesional y del Pensamiento Filosófico. 2- Actualizar los Programas de Postgrado existentes, en concordancia con el Proyecto Educativo UCN. 3- Acreditar los programas de postgrado de la UCN.

1- Diseñar e implementar el Sistema de Indicadores de la Investigación de la UCN.

2- Perfeccionar los mecanismos de subsidios e incentivos a las publicaciones y patentes de invención, para aumentar su número. 3- Incrementar la participación de académicos UCN en la adjudicación de proyectos de investigación. 4- Fortalecer las acciones de la DGIP para la búsqueda de recursos y contactos, para apoyo a la gestión y administración de proyectos, para la estructuración de grupos que permitan abordar proyectos de gran envergadura. 5- Desarrollar estrategias, para incentivar la participación de alumnos e investigadores jóvenes en proyectos de investigación. 6- Diseñar estrategias y mecanismos que faciliten la inserción internacional de los investigadores UCN.

1- Diseñar e implementar Unidades de Altos Estudios en áreas de Ciencia y Tecnología, de Humanidades y de Ciencias Sociales, con el fin de transferir los resultados de investigación e innovación tecnológica hacia el sector productivo y de servicio. 2- Establecer redes y/o alianzas estratégicas con instituciones de investigación y desarrollo tecnológico en el ámbito nacional e internacional. 3- Posicionar los centros o institutos tecnológicos existentes en la universidad, como referentes y socios estratégicos para el desarrollo regional y del país.

232


3. Promover el sentido de pertenencia de la comunidad universitaria y la identidad de la institución.

3.1. Definir un modelo de comunicación, que fomente una identidad universitaria y que construya la imagen corporativa de la UCN. 3.2. Difundir e internalizar los valores corporativos en la comunidad universitaria. 3.3. Fortalecer el sentido de pertenencia del personal académico, estudiantes y personal de apoyo a la academia, hacia la institución. 3.4. Fomentar ambientes de comunicación, que enriquezcan el diálogo y la relación entre los integrantes de la comunidad universitaria. 3.5. Desarrollar programas de vinculación de la universidad con sus ex alumnos.

1- Implementar un modelo de comunicación estratégica, externo e interno de la UCN, que responda tanto a la Misión-Visión declarada por la institución como a las necesidades internas, regionales, nacionales y globales. 2- Renovar y desarrollar una cultura activo-adaptativa que genere mística y liderazgo, que conduzca a la UCN a posiciones de vanguardia.

1- Utilizar los medios de comunicación actuales y nuevos para difundir los valores declarados. 2- Diseñar e implementar un programa de actividades, orientadas a la internalización de valores corporativos a través de procesos de inducción y capacitación.

1- Recuperar, promover y proyectar la historia institucional a través de principios, símbolos y personas. 2- Potenciar el funcionamiento de las instancias colegiadas de la Institución, que permitan la participación y compromiso con ella. 3- Destacar personajes ilustres relacionados con la institución. 50% 100%. 1- Creación de espacios físicos que favorezca la integración entre docente - estudiante; docente - docente; administrativos y personal de apoyo a la academia con docentes y estudiantes. 2- Generar espacios de reflexión docente, que permitan el intercambio de conocimientos y experiencias entre los académicos de la UCN. 3- Generar mecanismos especiales, que faciliten la vinculación de las familias de la comunidad universitaria con la institución. 1- Diseñar estrategias personalizadas de integración para que los ex alumnos de la UCN se vinculen, en forma tradicional o virtual, con su casa de estudios superiores. 2- Apoyar la creación de centros de ex alumnos de la UCN, con el fin de mantener los contactos humanos y profesionales. 3- Utilizar el sitio Web de la Universidad

233


4. Vincular a la UCN con su entorno, como un actor influyente en el desarrollo del bienestar de las personas y de la sociedad.

4.1. Insertar la actividad académica en el desarrollo regional y nacional. 4.2. Promover el cultivo de las ciencias, las artes y las letras con el objeto de incrementar el acervo cultural. 4.3. Profundizar y difundir una lectura cristiana del acontecer social, político y cultural desde una perspectiva multi e

como instrumento de trabajo y comunicación con los ex alumnos (foro de opiniones, información sobre egresados en actividades relevantes). 4- Generar mecanismos especiales que faciliten la vinculación de las familias de los ex alumnos con la universidad. 1- Definir el entorno de interés específico para la priorización de alianzas estratégicas de la UCN. 2- Fortalecer vínculos estratégicos entre la academia y el entorno de interés definido. 3- Incrementar y materializar vínculos con instituciones universitarias, de investigación y de cooperación de otros países. 4- Promover y desarrollar, una red de colaboración académica entre las universidades católicas del país. 5- Consolidar los Centros de Apoyo Social (Prevención Drogas y Alcohol, Asistencia Jurídica, Asistencia Social, Consultorio Escuela de Psicología) como referentes de apoyo al desarrollo social de la región y del país. 6- Implementar redes de cooperación con colegios de enseñanza media, para facilitar ciertos elementos o herramientas tecnológicas e infraestructura, para mejorar el proceso de enseñanza aprendizaje. 1- Consolidar los programas de difusión de las ciencias a nivel general y particularmente, en los sectores juveniles. 2- Incrementar la realización y difusión de presentaciones de los talleres artísticos culturales en eventos de la comunidad regional y nacional. 3- Investigar y difundir el acervo cultural del norte chileno. 4- Incentivar la creación de Academias para la comunidad nortina. 1- Crear espacios de discusión y debate de los acontecimientos y hechos sociales a la luz de las ciencias y la fe.

234


5. Desarrollar un modelo de gestión de los recursos, capacidades y competencias de la UCN.

interdisciplinaria. 4.4. Propiciar la reflexión sobre temas o actividades relevantes para la sociedad, aportando a la formación de una conciencia crítica y creadora, al interior de ella. 5.1. Mejorar los sistemas de evaluación de la actividad académica y de apoyo a la academia y el control de gestión de los recursos financieros y materiales de la UCN. 5.2. Formular y aplicar políticas de desarrollo de los Recursos Humanos, que favorezcan la eficiencia y eficacia del personal y organizacional.

2- Diseñar políticas para que los departamentos de Teología y Pastoral de la UCN, tengan una mayor vinculación con las distintas unidades, con la comunidad externa y con la comunidad eclesial. 1- Crear espacios de participación de la comunidad, interna y externa, en los programas y actividades que promuevan la reflexión desde el humanismo sobre los problemas sociales, las bellas artes y la cultura en general. 2- Motivar e incrementar en forma equitativa, la publicación y la difusión del trabajo intelectual y cultural, realizado por miembros de la comunidad, que reflejen la misión y visión institucional. 1- Integrar los sistemas de control de gestión vigentes, para que sirvan como herramienta de control para la planificación estratégica y como indicadores de gestión de la Institución. 2- Desarrollar actividades de difusión y capacitación para incentivar el uso de los sistemas de gestión de la Universidad. Crear un sistema de control y gestión de inventario de activo fijo. 1- Diseñar una estructura organizacional que considere los Objetivos Estratégicos de la Universidad, los resultados de la acreditación institucional y una armonización con el sistema de educación internacional. 2- Desarrollar e implementar un estudio de Dotación, que permita analizar la carga de trabajo y responsabilidades de los cargos de la organización y su dotación óptima. 3- Desarrollar estrategias de promoción de la planta académica, resguardando la mantención de una adecuada estructura de remuneraciones y beneficios. 4- Desarrollar e implementar un sistema de Retiro y Habilitación de Cuadros de Reemplazo en toda la Universidad, que fomente la capacidad y competencias en el personal de UCN, que incluya entre otros aspectos, el retiro por jubilación o la desvinculación anticipada. 5- Mejorar la eficiencia de los sistemas de información para la gestión estudiantil, que

235


5.3. Diseñar un plan de obtención de recursos, que incorpore en forma creciente la diversificación de las fuentes de financiamiento. 5.4. Definir un nuevo modelo de asignación presupuestaria y reformular los presupuestos de trabajo de la Universidad sobre la base de planes maestros trienales, acorde a metas de desempeño. 5.5. Definir e implementar un sistema integral de gestión de inversiones que considere las inversiones nuevas, el mantenimiento, reposición y mejoramiento de la infraestructura y equipamiento generales de la universidad. 5.6. Iniciar un proceso de revisión sistemática y participativa de las normativas actuales de la Universidad, a

permita optimizar la distribución y asignación de los beneficios estudiantiles, asegurando la calidad y equidad de los mismos. 6- Explicitar y difundir las políticas generales que orientan el desarrollo de los Recursos Humanos de la Institución. 7- Consolidar el desarrollo, implementación y mejoramiento contínuo de los sistemas de Vinculación del Personal de Apoyo a la Academia y de los Académicos con la UCN. 8- Diseño e implementación de un sistema de capacitación en dirección y gestión. 1- Consolidar la política de fijación de aranceles considerando la competencia, los costes y el mercado, en el contexto del Sistema de Educación Superior y de la responsabilidad social asumida por la UCN. 2- Mejorar la estrategia de cobranza a los ex alumnos deudores de la UCN. 3- Establecer métodos de licitación para las adquisiciones institucionales, con distintos proveedores de bienes y servicios que signifiquen disminución de costos. 4- Incrementar las donaciones, aportes y fondos provenientes de instituciones y concursos nacionales e internacionales. 1- Diseñar e implementar un nuevo modelo de asignación presupuestaria, que considere metas de desempeños concordados. 1- Redefinir destinos y utilidades de la infraestructura y equipamiento. 2- Actualizar los planos reguladores de acuerdo a los objetivos estratégicos de la UCN. 3- Estudiar alternativas de financiamiento de inversiones mayores asociadas al Plan de Desarrollo Corporativo. 1- Actualizar la normativa institucional que reglamenta el quehacer académico, estudiantil y administrativo. 2- Programar actividades de difusión y

236


objeto de que permitan adecuarlas a la realidad vigente en la institución y en el país.

socialización de los instrumentos resultantes.

Descripción

Para llevar a cabo las distintas líneas de acción que permitirán lograr los objetivos específicos y posteriormente los objetivos generales, cada Unidad o Departamento de la Universidad, dentro de sus funciones asignadas, tiene la posibilidad de realizar proyectos los cuáles se integran al “Tablero integral de proyectos”. Cada proyecto dentro de este tablero, busca el materializar algún objetivo estratégico dependiendo de la Unidad a cargo.

Riesgos

Objetivo afectado

Riesgo Plan de contingencia

1.-Desarrollar y posicionar un Proyecto Educativo distintivo de la UCN.

Proyectos que buscan nuevas maneras de enseñanza basadas en competencias, muestran un rechazo por parte de los académicos, al tener que modificar su metodología tradicional de enseñanza.

No es una obligación, la adopción de una nueva manera de enseñanza, dependiendo de la estructura de la asignatura.

237

Tabla A.5. Técnicas de educción utilizadas.

TÉCNICAS

INFORMACIÓN

Aná

lisis

de

FCE

Aná

lisis

de

Rie

sgos

Entre

vist

as

Doc

umen

tos

Exis

tent

es

Focu

s Gro

up

JAD

Wor

kSho

p

Estrategias X Descripción X X Riesgos X

239

ANEXO B: FASE DE IDENTIFICACIÓN DE REQUISITOS ORGANIZACIONALES.

Tabla B.1. Definición del equipo inicial del proyecto

Participantes en el proyecto



Nombre del Proyecto

Identificación y análisis de las causales de atraso en la titulación oportuna de alumnos de Pre-grado de la UCN, mediante el uso de Business Intelligence.


23/07/08


Nombre Rol Responsabilidades

Sr. Orlando Castro Auditor General Patrocinador del proyecto.

Coordinar que los recursos organizacionales requeridos por los ejecutantes del proyecto, estén disponibles de acuerdo al plan de trabajo propuesto

Sr. Santiago Sánchez Jefe Dpto. Gestión Académica

Experto en el dominio de negocio

Tiene a su cargo la conducción del proceso de captura y validación de los requisitos de negocios, asesorando la decisión sobre qué datos deben ser utilizados en el proyecto

Sres. Carlos Díaz Luis Salinas

Ejecutantes del proyecto.

A cargo de la responsabilidad de planificar y ejecutar el proyecto.

240

Tabla B.2. Definición de Requisitos Organizacionales.

Definición de Requisitos Organizacionales



Nombre del Proyecto

Identificación y análisis de las causas de atraso en la titulación oportuna de alumnos de Pre-grado de la UCN, mediante el uso de Business Intelligence.


Orlando Castro C. Auditor General


Luis Salinas Díaz Carlos Díaz Mondaca

Fecha de elaboración del documento 23/07/08


Unidad de Negocio Usuarios

Vicerrectoria Académica de la UCN

Dirección General de Docencia de la UCN

Dpto. de Ingeniería de Sistemas y Computación.

Orlando Castro C.

Patrocinador

Santiago Sánchez Experto en el dominio de negocio

Carlos Díaz Luis Salinas

Desarrolladores

José Gallardo Claudio Meneses Profesores guías


Requisitos organizacionales generales

Identificar y analizar las variables que afectan la Tasa de Titulación y Tiempo de Duración de la Carrera de Ingeniería Civil Industrial. Para ello se analizará el Avance Curricular que se observa en las respectivas cohortes, con el fin de poder intervenir “oportunamente” y mejorar las Tasas y Tiempos de Titulación.

241

Definición de Requisitos Organizacionales

Requisitos organizacionales específicos

1. Identificar las causas de las eliminaciones

académicas y deserciones que se observan en la cohortes.

2. Confirmar si el perfil de los estudiantes influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, Quintil, entre otros).

3. Identificar patrones de comportamiento o tendencias de ciertas asignaturas.

4. Validar si la eliminación del ciclo básico, se debe a las asignaturas de ciencias básicas.


Información adicional

02 de julio del 2008 Reunión. Participantes: Orlando Castro, Carlos Díaz, Luis Salinas. Objetivo: Explicación de la segunda fase de la metodología ER-DM. 04 de julio del 2008 Reunión. Participantes: Orlando Castro, Santiago Sánchez, Carlos Díaz, Luis Salinas, José Gallardo y Claudio Meneses. Objetivo: Definición de requisitos organizacionales, objetivo estratégico al que apoya, definición de participantes en el proyecto. 15 de julio del 2008 Reunión. Participantes: José Gallardo, Claudio Meneses, Carlos Díaz, Luis Salinas. Objetivo: Discusión sobre la problemática del proyecto y como abordar esta misma, mediante tormenta de ideas y posibles soluciones a los requisitos.

242

Tabla B.3. Definición del alcance del proyecto.




Nombre del Proyecto

Identificación y análisis de las causas de atraso en la titulación oportuna de alumnos de Pre-grado en la UCN, mediante el uso de Business Intelligence.



Equipo participante en el proceso de definición del alcance del proyecto.

Santiago Sánchez Luis Salinas Díaz

Carlos Díaz Mondaca

Fecha de elaboración del documento 23/07/08 Descripción

La no continuidad de un alumno en la Universidad Católica del Norte, puede ser originada por:

Eliminado por la aplicación del Reglamento de Docencia. En la que un alumno incurre en causal de pérdida de la calidad de alumno y consecuentemente quedará eliminado de la Universidad, si se encuentra en una o más de las situaciones académicas estipuladas en el Reglamento de Docencia. Eliminación por causales. Cuando los hechos realizados por el estudiante constituyen una falta para la UCN. Deserción. El alumno se retira voluntariamente de la UCN, ya sea por razones económicas, o no agrado de la Universidad o Carrera, entre otras varias causas.

Los temas anteriormente descritos son, los que se tomarán como base para el desarrollo del proyecto y de los que se tomarán los datos relevantes, que muestren la manifestación de las distintas causales de eliminación.

Tecnología asociada

Está en el marco de Business Intelligence, con herramientas tales como Data Mining con la la guía de desarrollo CRISP-DM y adicionalmente la metodología ER-DM que se está validando. Para el modelado de los datos se utilizara la aplicación Weka.

243


Escenario actual

Se manejan un conjunto de hipótesis de porqué hay un bajo rendimiento académico; pero hasta el momento no han sido comprobadas, por ello la importancia de corroborar estas hipótesis o descubrir nuevos patrones con un alto nivel de confianza, que permita la toma de medidas para solucionar y mejorar el rendimiento académico de alumnos de Pre-grado.


Posicionar a la Universidad Católica del Norte, en un nivel superior en comparación con otras universidades, incrementando el fondo entregado por el Ministerio de Educación con respecto al arancel de referencia.

Restricciones

Se realizará la identificación y análisis de las variables que afectan la tasa de titulación y el tiempo de duración de una sola carrera; esta carrera, es Ingeniería Civil Industrial. La razón es simplemente porque su ingreso es directo a la carrera. No se analizarán variables que afecten a los alumnos eliminados por razones económicas.

Riesgos

La selección de los datos, si se eligen erróneamente puede influir en la calidad de los resultados obtenidos. La no disponibilidad de los datos. No disponibilidad de personal que haya estado involucrado en proyectos de Data Mining.

Objetivos no considerados

Crear un DataWarehouse o una Base de Datos centralizada con la información integrada de docencia (Pre-grado, Post-grado, Educación Continua y Educación a distancia).


Se analizará la propuesta de cambio para ver si es válida, utilizando análisis del cambio y el coste de éste, si es viable, se implementará el cambio. [Somerville, 2005].

244

Tabla B.4. Glosario de términos del proyecto.


Nombre de la Organización Universidad Católica del Norte

Nombre del Proyecto




Equipo participante definición del Glosario de términos.


Carlos Díaz Mondaca

Fecha de elaboración del documento 23/07/08 Terminología de Carácter general


Cohorte Grupo de alumnos que inician sus estudios en un programa educativo al mismo tiempo. 1



Estructura curricular

Conjunto de normas y actividades cuyo objetivo es la formación integral del estudiante. La estructura incluye: Plan básico, Profesional, Formación General y de Titulación. 3

Actividades curriculares Aquellas que el alumno realiza dentro de un Plan de estudios. 3



Requisitos organizacionales

Objetivos, requisitos o problemas que tienen su origen o se derivan, como consecuencia de las metas estratégicas establecidas en toda la organización y que son posibles de abordar mediante un sistema de Data Mining. 2

Referencias

1Universidad Católica del Norte, “Plan de Desarrollo Corporativo de la UCN, años 2004-2008”, Antofagasta, Chile, (2003). 2Gallardo A. José, “Metodología ER-DM”, Tesis de Doctorado en Informática, Universidad Politécnica de Madrid, Antofagasta, Chile, (2008). 3Reglamento de Docencia de Pre-Grado.

245

Tabla B.5. Técnicas de educción utilizadas.

TÉCNICAS

ACTIVIDADES

Aná

lisis

de

Rie

sgos

Entre

vist

as

Doc

umen

tos

Exis

tent

es

Focu

s Gro

up

JAD

Wor

kSho

p

Identificación del equipo participante en el proyecto.

X

Preparación para el proceso de captura de requisitos de negocio

X

Captura de los requisitos organizacionales X X Definición del alcance del proyecto X Glosario de términos del dominio de negocio y de Data Mining

X

247

ANEXO C: FASE DE CONSTRUCCIÓN DE MODELOS DE PRUEBA.

C1. Comprensión de los datos El modelo de prueba, busca explorar los datos de los alumnos de la carrera de Ingeniería Civil Industrial de la Universidad Católica del Norte, para llegar a conocer, de qué manera el perfil del estudiante a su ingreso a la universidad, influye en la culminación de su carrera.

C1.1. Recopilación de los Datos: Para el desarrollo del prototipo, fue necesario disponer de los datos que se recolectan en el proceso de admisión, además de las bases de datos con información de alumnos eliminados y titulados. Todos estos datos, están localizados en dos Bases de datos Oracle: SIMBAD que contiene datos del Sistema Curricular y JPSIAM, que contiene los datos de Admisión. El acceso a estas Bases de Datos, fue autorizado por la Dirección de Informática de la Universidad Católica del Norte. Se utilizó el software PowerDesigner V.12, para obtener los modelos entidad-relacionamiento (ER) mediante ingeniería reversa (figura C.1 de la base de datos SIMBAD y figura C.2 de la base de datos JPSIAM).

248

Figura C.1. Modelo entidad relacionamiento Base de Datos SIMBAD.

RA

MO

_SE

R_D

ICTA

DO

_PO

R

CA

RR

ER

A_D

EP

EN

DE

R_D

EC

AR

R_S

INI_D

EC

OD

_CO

N

CA

RR

_SFIN

_DE

CO

D_C

ON

A_C

UR

_ES

TAR

_AS

OC

IAD

A_C

N_A

A_TE

NE

R

FK_R

AM

O_C

ALC

E_C

UR

SO

RA

HO

_DE

CO

DIFIC

AR

SE

_CO

FK_N

OTA

_PA

RC

IAL_C

UR

SO

_ALU

MN

O

FK_N

OTA

_FINA

LFK

_NO

TA_E

XA

ME

N_C

UR

SO

_ALU

MN

O

H_C

_CO

RR

ES

PO

ND

ER

_A

HO

RA

_P_TE

NE

R_A

SO

CIA

DA

PR

OF_C

_ES

TAR

_AS

OC

IAD

O_C

CO

N_H

OR

AS

_PR

OFS

_RU

T

CO

N_P

C_P

ER

S_R

UT

FK_S

EM

ES

TRE

_IND

ICA

DO

R

FK_P

LAN

_ALU

M_S

EM

E_IN

D

SE

ME

STR

E_P

LAN

_ALU

M_FK

RI_P

LAN

_PE

RTE

NE

CE

_A

RI_C

UR

S_P

ER

TEN

EC

E_A

CA

RR

_PLA

N_D

EP

_PE

RTE

NE

CE

R_A

P_A

L_ES

TAR

_AS

OC

IAD

O

P_A

L_TER

MIN

AR

P_A

L_CO

ME

NZA

R

FK_S

EM

E_IN

I_PLA

N

FK_S

EM

E_FIN

_PLA

N FK_S

EM

E_IN

G_U

CN

P_A

L_ES

TAR

_AS

OC

IAD

O2

CO

N_A

NTE

_PE

RS

_RU

T

S_A

L_ES

TAR

_AS

OC

IAD

O_A

C_IN

S_S

ER

_INS

TAN

CIA

_DE

CU

RS

O_E

STA

R_A

SO

CIA

DO

_A

RA

HO

_TEN

ER

_AS

OC

IAD

O

RA

HO

_DE

CO

D_S

EM

_FK

P_C

_R_TE

NE

R

P_C

_R_TE

NE

R2

CU

RS

O_S

ER

_INS

TAN

CIA

PLA

N_C

_DE

P_P

ER

TEN

EC

ER

_A

PLA

N_C

_ES

TAR

_AS

OC

IAD

O_A

CA

RR

_CA

MP

US

_DE

CO

D_C

ON

SE

IN_E

STA

R_A

SO

CIA

DO

SE

ME

STR

E

SE

ME

_AG

NO

SE

ME

_C_P

ER

IOD

O_A

GN

OS

EM

E_C

_SE

MS

EM

E_F_FIN

_ES

TIMA

DO

SE

ME

_F_FIN_R

EA

LS

EM

E_F_IN

I_ES

TIMA

DO

SE

ME

_F_INI_R

EA

L

NU

MB

ER

NU

MB

ER

NU

MB

ER

DA

TED

ATE

DA

TED

ATE

<ak><ak><pk>

PLA

NE

S_C

AR

R

PLA

N_C

OD

IGO

PLA

N_C

_CA

RR

ER

AP

LAN

_DE

SC

RIP

CIO

NP

LAN

_E_P

LAN

_CA

RR

PLA

N_F_A

CTU

ALIZA

CIO

NP

LAN

_F_CR

EA

CIO

NP

LAN

_F_VIG

EN

CIA

PLA

N_U

D_E

LEC

TIVA

SP

LAN

_UD

_LIBR

ES

PLA

N_U

D_E

FGP

LAN

_DE

CR

ETO

PLA

N_TA

SA

_AV

AN

PLA

N_M

AX

_SE

MP

LAN

_C_D

EP

PLA

N_S

INI

PLA

N_S

FINP

LAN

_CO

DIG

O_D

EP

NU

MB

ER

(4)N

UM

BE

R(4)

VA

RC

HA

R2(100)

NU

MB

ER

DA

TED

ATE

DA

TEN

UM

BE

R(3)

NU

MB

ER

(2)N

UM

BE

R(3)

VA

RC

HA

R2(100)

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

<pk><pk,fk1>

<fk4>

<fk2,fk3>

<fk2>

PE

RS

ON

AS

PE

RS

_ALIA

SP

ER

S_A

P_M

ATE

RN

OP

ER

S_A

P_P

ATE

RN

OP

ER

S_C

OM

EN

TAR

IOP

ER

S_D

V_R

UT

PE

RS

_E_M

AIL

PE

RS

_F_NA

CIM

IEN

TOP

ER

S_N

AC

ION

LDP

ER

S_N

OM

1P

ER

S_N

OM

2P

ER

S_P

AS

SW

OR

DP

ER

S_R

UT

PE

RS

_SE

XO

PE

RS

_SU

B_TIP

OU

SE

RN

AM

E

VA

RC

HA

R2(50)

VA

RC

HA

R2(20)

VA

RC

HA

R2(30)

VA

RC

HA

R2(100)

VA

RC

HA

R2(1)

VA

RC

HA

R2(30)

DA

TEN

UM

BE

RV

AR

CH

AR

2(20)V

AR

CH

AR

2(40)V

AR

CH

AR

2(15)N

UM

BE

RV

AR

CH

AR

2(1)V

AR

CH

AR

2(4)V

AR

CH

AR

2(15)

<fk>

<pk>

PLA

NE

S_A

LUM

S

P_A

L_CO

ME

NTA

RIO

P_A

L_C_C

AR

RE

RA

P_A

L_C_P

LAN

P_A

L_DE

CR

ETO

P_A

L_E_P

LAN

_ALU

MP

_AL_F_A

CTU

ALIZA

CIO

NP

_AL_N

_MA

TRIC

ULA

P_A

L_RU

T_ALU

MP

_AL_S

EM

E_FIN

P_A

L_SE

ME

_INI

P_A

L_T_ING

RE

SO

P_A

L_AG

NO

_ICP

_AL_S

EM

E_IN

I_CA

RP

_AL_S

EM

E_FIN

_CA

RP

_AL_E

_CA

RR

_ALU

MP

_AL_V

_PLA

N_A

LUM

P_A

L_SE

ME

_ING

_UC

NP

_AL_S

EM

E_IN

I_PLA

NP

_AL_S

EM

E_FIN

_PLA

N

VA

RC

HA

R2(50)

NU

MB

ER

(4)N

UM

BE

R(4)

VA

RC

HA

R2(30)

NU

MB

ER

DA

TEN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

R

<pk,fk7><pk,fk7>

<fk11>

<pk,fk2><fk1><pk,fk3><fk9>

<fk10><fk8><fk6><fk4><fk5>

AN

TEC

ED

_ALU

MS

AN

TE_A

GN

O_E

GR

_ED

_ME

DA

NTE

_AG

NO

_ING

R_FA

CA

NTE

_AG

NO

_ING

R_U

CH

AN

TE_A

GN

O_IN

GR

_UN

IA

NTE

_AG

NO

_RE

ING

R_FA

CA

NTE

_ALU

M_R

UT

AN

TE_C

_CIU

DA

DA

NTE

_ES

TAB

_ED

_ME

DA

NTE

_E_A

LUM

AN

TE_N

UM

_MA

TR_M

ILIA

NTE

_PR

EF_P

OS

TA

NTE

_PR

OM

_NO

TAS

AN

TE_P

TJE_E

SP

_FISA

NTE

_PTJE

_ES

P_M

AT

AN

TE_P

TJE_H

IST

AN

TE_P

TJE_IN

GR

_FAC

AN

TE_P

TJE_M

AT

AN

TE_P

TJE_N

OTA

SE

MA

NTE

_PTJE

_VE

RB

AL

AN

TE_T_IN

GR

AN

TE_U

BIC

_ING

R_FA

CA

NTE

_PTJE

_ES

P_C

SA

NTE

_PTJE

_ES

P_B

IOA

NTE

_PTJE

_ES

P_Q

UI

NU

MB

ER

(4)N

UM

BE

R(4)

NU

MB

ER

(4)N

UM

BE

R(4)

NU

MB

ER

(4)N

UM

BE

R(9)

NU

MB

ER

NU

MB

ER

NU

MB

ER

VA

RC

HA

R2(20)

NU

MB

ER

(2)N

UM

BE

R(2,1)

NU

MB

ER

(5,2)N

UM

BE

R(5,2)

NU

MB

ER

(5,2)N

UM

BE

R(5,2)

NU

MB

ER

(5,2)N

UM

BE

R(5,2)

NU

MB

ER

(5,2)N

UM

BE

RN

UM

BE

R(3)

NU

MB

ER

(5,2)N

UM

BE

R(5,2)

NU

MB

ER

(5,2)

<pk,fk2><fk4>

<fk1>

<fk3>

SE

ME

_ALU

M

S_A

L_CO

ME

NTA

RIO

S_A

L_E_B

IAS

_AL_E

_CA

RN

E_E

SC

S_A

L_E_C

AR

NE

_UN

IVS

_AL_E

_SE

M_A

LUM

S_A

L_F_AC

TUA

LIZAC

ION

S_A

L_RU

T_ALU

MS

_AL_S

EM

ES

TRE

S_A

L_RIE

SG

OS

OS

_AL_C

_CA

RR

ER

AS

_AL_C

_PLA

NS

_AL_S

EM

E_IN

IS

_AL_N

_MA

TRIC

ULA

S_A

L_PO

STU

LAC

ION

VA

RC

HA

R2(50)

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

DA

TEN

UM

BE

R(9)

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

(1)

<fk5><fk6><fk4><fk3>

<fk2><fk1>

<fk2><fk2><fk2>

CU

RS

OS

_INS

CR

ITOS

C_IN

_CU

RS

O_C

OD

IGO

C_IN

_E_C

UR

SO

_INS

CC

_IN_E

_FIN_C

UR

SO

C_IN

_F_AC

TUA

LIZAC

ION

C_IN

_NO

TA_FIN

AL

C_IN

_SE

ME

_ALU

M_C

_SE

MC

_IN_S

EM

E_A

LUM

_RU

T_ALU

MC

_IN_F_V

EN

C_N

OTA

C_IN

_CU

RS

O_C

C_IN

_FLAG

_EX

AM

EN

C_IN

_NO

TA_FIN

AL_P

AR

CIA

LC

_IN_N

OTA

_EX

AM

EN

_RE

CU

PE

RA

TIVO

C_IN

_SO

LICITU

DC

_IN_N

OTA

_CA

TED

RA

C_IN

_CA

LCU

LOC

_IN_M

AR

CA

_INA

SIS

TEN

CIA

C_IN

_CA

LCU

LO_N

OTA

_FINA

L_FINA

LE

RR

OR

_MA

RC

AC

_IN_C

OR

RE

LATIV

O_R

EC

TIFC

_IN_C

_CA

RR

ER

AC

_IN_C

_PLA

NC

_IN_S

EM

E_IN

IC

_IN_N

_MA

TRIC

ULA

C_IN

_OP

OR

TUN

IDA

D

NU

MB

ER

NU

MB

ER

NU

MB

ER

DA

TEN

UM

BE

R(2,1)

NU

MB

ER

NU

MB

ER

(9)D

ATE

NU

MB

ER

NU

MB

ER

NU

MB

ER

(2,1)N

UM

BE

R(2,1)

NU

MB

ER

NU

MB

ER

(2,1)N

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

R

<fk3><fk1><fk2>

<fk6>


CU

RS

OS

CU

RS

_CO

DIG

OC

UR

S_C

OM

EN

TAR

IOC

UR

S_C

UP

O_C

AR

RC

UR

S_C

UP

O_B

AC

HC

UR

S_C

UP

O_O

TRA

S_C

AR

RC

UR

S_C

_RA

MO

CU

RS

_C_S

EM

CU

RS

_F_AC

TUA

LIZAC

ION

CU

RS

_SE

CC

ION

CU

RS

_C_R

AM

O_C

ON

TC

UR

S_S

EC

CIO

N_C

ON

TC

UR

S_TIP

OC

UR

S_C

ON

TRO

L_CU

PO

NU

MB

ER

LON

GN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RD

ATE

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

<pk>

<ak,fk1><ak,fk2>

<ak>

<fk3>

RA

MO

_HO

MO

RA

HO

_CO

N_C

_PE

RIO

DR

AH

O_C

_NO

TAR

AH

O_C

_RA

MO

RA

HO

_E_R

AM

O_H

OM

OR

AH

O_F_A

CTU

ALIZA

CIO

NR

AH

O_N

OM

BR

E_A

SIG

NA

TUR

AR

AH

O_N

UM

ER

O_ITE

MR

AH

O_O

BS

ER

VA

CIO

NE

SR

AH

O_S

OLI_H

OM

OR

AH

O_C

_INS

TR

AH

O_O

PO

RTU

NID

AD

RA

HO

_C_S

EM

RA

HO

_T_RA

MO

_HO

MO

RA

HO

_CA

LCE

RA

HO

_E_A

PR

OB

AC

ION

RA

HO

_C_R

AM

O_O

RIG

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

DA

TEV

AR

CH

AR

2(40)N

UM

BE

RV

AR

CH

AR

2(100)N

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

R


<fk1>

<fk4><fk5>

PLA

NE

S_C

AR

R_R

AM

O

P_C

_CA

RR

ER

AP

_C_C

_PLA

N_C

AR

RP

_C_C

_RA

MO

P_C

_E_P

LAN

_CA

RR

_RA

MO

P_C

_F_AC

TUA

LIZAC

ION

P_C

_T_RA

MO

P_C

_NIV

EL

P_C

_PO

SIC

ION

P_C

_CIC

LOP

_C_E

XA

ME

NP

_C_T_C

UR

RIC

NU

MB

ER

(4)N

UM

BE

R(4)

NU

MB

ER

NU

MB

ER

DA

TEN

UM

BE

RN

UM

BE

R(2)

NU

MB

ER

(2)N

UM

BE

RN

UM

BE

RN

UM

BE

R

<pk,fk1><pk,fk1><pk,fk2><fk7>

<fk3>

<fk4><fk6><fk5>

CA

RR

ER

AS

CA

RR

_CO

DIG

OC

AR

R_D

EP

_CO

DIG

OC

AR

R_D

ES

CR

IPC

ION

CA

RR

_E_C

AR

RC

AR

R_F_A

CTU

ALIZA

CIO

NC

AR

R_F_C

RE

AC

ION

CA

RR

_F_VIG

EN

CIA

CA

RR

_T_GR

_CO

DIG

OC

AR

R_D

EC

RE

TOC

AR

R_FIN

I_VIG

EN

CIA

CA

RR

_CA

MP

US

CA

RR

_T_CU

RR

ICC

AR

R_T_E

STU

DIO

CA

RR

_SIN

IC

AR

R_S

FIN

NU

MB

ER

(4)N

UM

BE

R(4)

VA

RC

HA

R2(100)

NU

MB

ER

(4)D

ATE

DA

TED

ATE

NU

MB

ER

VA

RC

HA

R2(100)

DA

TEN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

R

<pk><fk1>

<fk6>

<fk5>

<fk4><fk2><fk3>

SE

DE

CO

DIG

OTE

XTO

NU

MB

ER

VA

RC

HA

R2(100)

<pk>

SE

ME

_INS

C

SE

IN_A

NU

AL

SE

IN_C

_SE

MS

EIN

_F_AC

TUA

LIZAC

ION

SE

IN_D

ER

_AD

MS

EIN

_SE

ME

_PO

ST

SE

IN_S

EM

E_E

NC

SE

IN_S

EM

E_A

CTA

SE

IN_R

UT_R

EP

RE

SE

IN_L_N

EM

O

NU

MB

ER

NU

MB

ER

DA

TEN

UM

BE

RN

UM

BE

RN

UM

BE

R(22)

NU

MB

ER

NU

MB

ER

NU

MB

ER

<pk,fk>

RA

MO

S

RA

MO

_CO

ME

NTA

RIO

RA

MO

_C_D

UR

A_R

AM

OR

AM

O_C

_RA

MO

RA

MO

_C_R

AM

O_E

SC

UE

LAR

AM

O_E

_RA

MO

RA

MO

_F_AC

TUA

LIZAC

ION

RA

MO

_F_CR

EA

CIO

NR

AM

O_IN

ST_C

OD

IGO

RA

MO

_NIV

EL

RA

MO

_NO

MB

RE

RA

MO

_PR

OG

RA

MA

RA

MO

_UD

_VIG

EN

TER

AM

O_S

ES

ION

RA

MO

_PO

SIC

ION

RA

MO

_C_R

AM

O_C

ON

TR

AM

O_E

VA

LUA

RA

MO

_AS

ISTE

NC

IA

VA

RC

HA

R2(500)

NU

MB

ER

NU

MB

ER

VA

RC

HA

R2(7)

NU

MB

ER

DA

TED

ATE

NU

MB

ER

NU

MB

ER

(1)V

AR

CH

AR

2(80)LO

NG

NU

MB

ER

(3)N

UM

BE

R(2)

NU

MB

ER

(2)N

UM

BE

RV

AR

CH

AR

2(1)N

UM

BE

R

<fk3><pk><ak><fk2>

<fk1>

INS

TITUC

ION

ES

INS

T_CA

SILLA

INS

T_CO

DIG

OIN

ST_C

OM

EN

TAR

IOIN

ST_D

IRE

CC

ION

INS

T_E_M

AIL

INS

T_FAX

INS

T_FON

OS

INS

T_NO

MB

RE

INS

T_SIG

LAIN

ST_R

UT

INS

T_CA

MP

US

VA

RC

HA

R2(20)

NU

MB

ER

VA

RC

HA

R2(2000)

VA

RC

HA

R2(50)

VA

RC

HA

R2(30)

VA

RC

HA

R2(35)

VA

RC

HA

R2(30)

VA

RC

HA

R2(100)

VA

RC

HA

R2(15)

NU

MB

ER

NU

MB

ER

<pk>

<ak>

AC

TIV_C

UR

SO

S

A_C

U_C

UR

SO

_CO

DIG

OA

_CU

_F_AC

TIVA

_CU

_F_AC

TUA

LIZAC

ION

A_C

U_N

_AC

TIVA

_CU

_PO

ND

ER

AC

ION

A_C

U_T_A

CTIV

A_C

U_D

IGITA

A_C

U_C

OD

IGO

A_C

U_P

AD

RE

A_C

U_C

OM

EN

TAR

IOA

_CU

_OR

DE

NA

_CU

_SA

LAA

_CU

_VIS

IBA

_CU

_RE

PO

RTE

A_C

U_F_R

EC

LAM

OA

_CU

_PO

RC

EN

T_IGU

AL

A_C

U_FE

CH

A_IN

ICIA

LA

_CU

_CO

NTA

DO

R_C

AM

BIO

S

NU

MB

ER

DA

TED

ATE

NU

MB

ER

(2)N

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RV

AR

CH

AR

2(200)N

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RD

ATE

NU

MB

ER

DA

TEN

UM

BE

R

<fk2>

<fk1>

<pk><fk3>

NO

TAS

_AC

TI_ALU

MN

OS

N_A

A_A

LUM

_RU

TN

_AA

_C_C

UR

SO

N_A

A_C

_SE

MN

_AA

_F_AC

TUA

LIZAC

ION

N_A

A_N

OTA

N_A

A_N

_AC

TIVN

_AA

_PR

OF_R

UT

N_A

A_T_A

CTIV

N_A

A_E

_FINA

LN

_AA

_CO

DIG

ON

_AA

_CA

LCU

LON

_AA

_SO

LICITU

D

NU

MB

ER

(9)N

UM

BE

RN

UM

BE

RD

ATE

NU

MB

ER

(2,1)N

UM

BE

R(2)

NU

MB

ER

(9)N

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

R

<fk2><fk1>

C_N

OTA

C_N

O_C

OD

IGO

C_N

O_TE

XTO

NU

MB

ER

VA

RC

HA

R2(50)

<pk><ak>

CU

RS

OS

CU

RS

_CO

DIG

OC

UR

S_C

OM

EN

TAR

IOC

UR

S_C

UP

O_C

AR

RC

UR

S_C

UP

O_B

AC

HC

UR

S_C

UP

O_O

TRA

S_C

AR

RC

UR

S_C

_RA

MO

CU

RS

_C_S

EM

CU

RS

_F_AC

TUA

LIZAC

ION

CU

RS

_SE

CC

ION

CU

RS

_C_R

AM

O_C

ON

TC

UR

S_S

EC

CIO

N_C

ON

TC

UR

S_TIP

OC

UR

S_C

ON

TRO

L_CU

PO

NU

MB

ER

LON

GN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RN

UM

BE

RD

ATE

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

<pk>

<ak,fk1><ak,fk2>

<ak>

<fk3>

PR

OFE

SO

RE

S_C

UR

SO

P_C

_C_C

UR

SO

P_C

_F_AC

TUA

LIZAC

ION

P_C

_PR

OF_R

UT

P_C

_T_PR

OF

P_C

_SE

SIO

NP

_C_F_IN

IP

_C_F_FIN

P_C

_JER

P_C

_ES

TAD

O

NU

MB

ER

DA

TEN

UM

BE

R(9)

NU

MB

ER

NU

MB

ER

DA

TED

ATE

NU

MB

ER

NU

MB

ER

(2)

<pk,fk4>

<pk,fk1><pk,fk3>

<fk2>

HO

RA

S_P

RO

FS

HO

RA

_H_C

_CU

R_C

OD

HO

RA

_H_C

_HO

R_C

OD

HO

RA

_RU

T_PR

OF

NU

MB

ER

NU

MB

ER

(2)N

UM

BE

R(9)

<pk,fk1><pk,fk1><pk,fk2>

HO

RA

S_C

UR

SO

S

H_C

_CO

MP

AR

TIBILID

AD

H_C

_CU

RS

O_C

OD

IGO

H_C

_F_AC

TUA

LIZAC

ION

H_C

_HO

R_C

OD

IGO

H_C

_N_S

ALA

S_R

EQ

H_C

_P_H

OR

A_C

UR

SO

H_C

_T_CLA

SE

H_C

_CO

ME

NTA

RIO

NU

MB

ER

NU

MB

ER

DA

TEN

UM

BE

R(2)

NU

MB

ER

(2)N

UM

BE

RN

UM

BE

RV

AR

CH

AR

2(100)

<fk4><pk,fk1>

<pk,fk3>

<fk2><fk5>

SE

ME

_IND

_AU

X

S_I_R

UT

S_I_C

_CA

RR

ER

AS

_I_C_P

LAN

S_I_S

EM

E_IN

IS

_I_C_S

EM

S_I_P

PA

S_I_P

SA

CA

S_I_N

IVE

LS

_I_CIC

LOS

_I_C_S

IT_CU

RR

IS

_I_PO

SIC

ION

AM

IEN

TOS

_I_PP

GS

_I_CR

ED

_AC

UM

S_I_C

RE

D_IN

SC

S_I_FE

CH

A_S

ITS

_I_FEC

HA

_PO

SS

_I_FEC

HA

_PP

GS

_I_FEC

HA

_AC

TS

_I_OB

SS

_I_MA

TRIC

ULA

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

NU

MB

ER

DA

TED

ATE

DA

TED

ATE

VA

RC

HA

R2(500)

NU

MB

ER

<fk2><fk2><fk2><fk2><fk1>

RE

STR

IC_IN

SC

RI_C

UR

S_C

OD

IGO

RI_C

_CA

RR

ER

AR

I_C_P

LAN

_CA

RR

RI_F_A

CTU

ALIZA

CIO

NR

I_F_CO

ME

NTA

RIO

NU

MB

ER

NU

MB

ER

NU

MB

ER

DA

TEV

AR

CH

AR

2(200)


249

Figura C.2. Modelo entidad relacionamiento Base de Datos JPSIAM.

SIS_IN

G_SE_AS

OCIA

_A_FK

POST

ULACION_DE

TALLE_FK

REQ

UISITO

S_D

ETALLE

_POST

_FK

NIVEL_DETALLE_FK

PRO

VINCIA

_CO

LEGIO

_FK

TIPO

_EDUC

_MO

DALIDAD_F

KTIP

O_F

INANC_M

ODA

LID_FKT

PO_INS

TITUCIO

N_MO

D_FK

CARR

ERA_PRE

FRENC

IA_FK

AD_PT

_PRG

_RA_C

A_PRG

_FK

ESTADO

_RESO

LUCIO

N_FK

TI_POS

_SE_AS

OCIA

_FK

REQ

UISIT

OS_PO

STULAC

ION_FK

ESTAD

OS_RE

SOLUCIO

N_FKRES

OLU

CION

_PO

STULACIO

N_FK

SE_A

SOCIA_A_SIS

TEM

A_ING

RESO

_FK

SE_AS

OCIA

_SIST

EMA_IN

GRES

O_FK

SIS_IN

G_T

IENE_PO

S_F

K

SIS_ING_TIENE

_FK

PRO

VINCIA_C

OM

UNA_F

K

COM

UNA_DO

MIC

ILIO_FK

TIPO

_DOM

ICILIO

_FK

NACIO

NALIDAD

_PER

SONA

_FK

SEXO

_PERSO

NA_FK

REG

ION_P

ROVINCIA

_FK

FK_AD_RE

QUI_R

EFEREN

CE_AD_SIS

TE

FK_AD_DE

TAL_R

EFEREN

CE_AD_RE

QU

I

FK_AD_M

ODAL_RE

FERENC

E_AD_INST

IF

K_AD_M

OD

AL_REFERE

NCE_AD_M

ODA

LFK_AD

_INSTI_RE

FERENC

E_AD_M

OD

AL

FK_AD

_INSTI_REF

ERENC

E_AD_IN

STI

FK_AD_PO

STU_RE

FEREN

CE_AD_ADM

IS

FK_AD_DIR

EC_REFE

RENCE_A

D_INSTI

FK_AD

_DET

AL_REFERE

NCE_AD_IN

STI

FK_AD

_DET

AL_REFERE

NCE_AD_D

ETAL

FK_AD_D

ETAL_R

EFEREN

CE_A

D_DURAC

FK_A

D_POS

TU_REFE

RENCE_UC

N_PERS

FK_AD_D

ETAL_R

EFEREN

CE_A

D_ADM

IS

FK_AD_AN

TEC_REF

ERENC

E_AD_A

DMIS

FK_AD

_CARR

E_REFER

ENCE_AD

_INSTI

FK_UC

N_NACI_RE

FEREN

CE_UCN_PE

RS

AD_ADM

ISION

ES

AD_IN

SCRIPC

ION

RUT

AD_AN

HO_AD

MISIO

NS

A_COD

IGO

TI_CO

DIG0

AD_O

BSERV

ACIO

NA

D_SEM

_ADM

ISIO

NA

D_FOLIO

_TIA

D_FOLIO

_TPIE_CO

DIGO

_UCN

AD_PR

EFERE

NCIAA

D_ORD

EN_LISTA

MO

_MO

DALIDA

D

NUM

BER(10)

NUM

BER(10)

NUM

BER(4)

NUM

BER(4)

NUM

BER(4)

VARC

HAR2(240)

NUM

BER(4)

NUM

BER(10)

NUM

BER(10)

NUM

BER(10)

NUM

BER(2)

NUM

BER(4)

NUM

BER(10)

<pk>

<fk>

<fk>

AD_ANT

ECEDE

NTES_PA

A

AD_INS

CRIPC

ION

AD__AD_IN

SCRIPC

ION

ANH

O_R

ENDIR_PA

AP

TJE_EMP

TJE_PAA_M

ATP

TJE_PAA_VE

RP

TJE_PAA_ST

ADRP

ROM

_PAA

PTJE_SE

LEC_SBP

TAJE

_SELEC

_CB

PTJE_PC

E_HYG

PTJE_PC

E_BIOP

TJE_PCE_CS

PTJE_PC

E_FISP

TJE_PCE_Q

UIP

TJE_PCE_M

ATP

TJE_PSU_M

ATP

TJE_PSU_LENG

_CO

MP

TJE_PSU_HIST_CS

PTJE_PS

U_CIENCIAS

PTJE_PS

U_PRO

M_LM

NUM

BER

NUM

BER(10)

NUM

BER

NUM

BER

NUM

BER(7,3)

NUM

BER(7,3)

NUM

BER(7,3)

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

NUM

BER

<pk><fk>

AD_C

ARRER

AS_PAA

CC_C

LAVECC

_DES

CRIPCIO

NIE_C

ODIG

O_UC

NAD

__IE_CO

DIGO

_UCN

IE_CAM

PUS

CC_R

EGIO

N

NUM

BER(4)

VARCH

AR2(50)NU

MBER

(10)NU

MBER

(10)VA

RCHAR2(50)

NUM

BER(4)

<pk>

<fk1><fk2>

AD_DETA

LLE_ADM

ISION

AD_INSC

RIPCIO

NRS

I_CORR

ELATIVO

RA_V

ALOR

NUM

BER(10)

NUM

BER(10)

VARCH

AR2(50)

<pk,ak,fk2><fk1>

AD_DETA

LLE_P

OSTU

LACION

RP_CO

RRELA

TIVO

PO_NU

M_S

OLICIT

UDDP_V

ALOR

NUM

BER(10)

NUM

BER(10)

VARC

HAR2(50)

<pk,fk2><pk,fk1>

AD_D

ETALLES_CO

LEG

IOS

IE_CODIG

O_U

CNA

NHO_A

DMISIO

ND

E_COD

IGO

DEC_T

OTAL_M

ATRICU

LASD

EC_DIRE

CTOR

DEC_T

ELEFON

O_DIRE

CTO

R

NUMB

ER(10)NUM

BER(4)

NUMB

ER(4)NUM

BER(10)

VARCH

AR2(50)VAR

CHAR2(50)

<pk,fk1><pk><fk2>

AD_DET

ALLES_NIVELES

IE_CODIG

O_U

CNA

NHO_A

DMISIO

NN

C_COD

IGO

DN_NU

M_H

OM

BRES

DN_NU

M_M

UJE

RES

DN_NU

M_T

OTAL

NUM

BER(10)

NUM

BER(4)

NUM

BER(4)

NUM

BER(10)

NUM

BER(10)

VARCH

AR2(50)


AD_DIRE

CCIO

NES_INS

TITUCIO

NES

IE_C

ODIG

O_UC

NA

NHO_AD

MISIO

ND

C_DIRECC

ION

DC_TELE

FONO

DC_CIU

DADP

V_CODIG

OC

O_C

OM

UNA

NUM

BER(10)

NUM

BER(4)

VAR

CHAR2(60)

NUM

BER(9)

VAR

CHAR2(50)

NUM

BER(4)

NUM

BER(6)

<pk,fk2><pk>

<fk1>

AD_DURA

CION_E

STUDIO

S

DE_C

ODIG

ODE

_DES

CRIPCION

DE_E

Q_PAA

NUMB

ER(4)VAR

CHAR2(50)

VARCHA

R2(50)

<pk>

AD_INST

ITUCIO

NES_AD

MISIO

N

AD_INS

CRIPCION

IE_CO

DIGO

_UCN

MO

_MO

DALIDAD

MI_M

ODA

LIDAD

NUMB

ER(10)NUM

BER(10)

NUMB

ER(10)NUM

BER(10)

<pk><pk,fk1,fk2><fk1>

AD_INST

ITUCIO

NES_ED

UCACIO

N

IE_COD

IGO

_UCNIE_NO

MB

REIE_CO

DIG

O_PAA

IE_LOCA

L_EDUC

ACIONAL

IE_UNIDA

D_EDUCA

TIVA

NUMB

ER(10)

VARCH

AR2(50)NUM

BER

(10)VAR

CHAR2(10)

VARCH

AR2(10)

<pk>

AD_MO

DALIDAD

ES

IE_CO

DIGO

_UCNTE

_CO

DIGO

TRE_CO

DIGO

TDE_CO

DIGO

TJ_CODIG

OTF

_CO

DIGO

MO

_MO

DALID

AD

NUMB

ER(10)NUM

BER(4)

NUMB

ER(4)NUM

BER(4)

NUMB

ER(4)NUM

BER(4)

NUMB

ER(10)

<pk,fk4><pk,fk1><pk,fk6><pk,fk3><pk,fk5><pk,fk2><fk4>

AD_M

OD

ALIDADES

_INSTITU

CION

ES

IE_COD

IGO

_UCN

MO

_MO

DALIDA

DN

UMBE

R(10)N

UMBE

R(10)<pk,fk><pk>

AD_N

IVELE

S_COLEG

IOS

NC_CO

DIG

ON

C_DESCR

IPCIO

NN

C_EQ_PA

A

NUM

BER(4)

VARCH

AR2(50)

VARCH

AR2(50)

<pk>

AD_PO

STULA

CION

ES_PAA

AD_INS

CRIPCION

PP_PRE

FEREN

CIAC

C_CLAVE

EP_CO

DIGO

PP_PTJE

_SELEC

_CB

PP_UBICAC

ION_LIST

A

NUM

BER(10)

NUM

BER(4)

NUM

BER(4)

NUM

BER(4)

NUM

BER(6,2)

NUM

BER(10)

<pk,fk3>

<pk>

<fk1>

<fk2>

AD_PO

STULAC

ION_PR

G

PO_NU

M_S

OLICIT

UDRU

TPO

_ANHO

_POST

ULACIO

NPO

_ESTAD

OPO

_FECHA

_POST

ULACION

TP_C

ODIG

OCA

_CO

DIGO

NUMB

ER(10)

NUMB

ER(9)

NUMB

ER(4)

NUMB

ER(4)

DATE

NUMB

ER(4)

NUMB

ER(5)

<pk>

<fk4>

<fk2>

<fk3>

<fk1>

AD_R

EQUISIT

OS_PO

STULAC

ION

RP_CO

RRELAT

IVOTP

_CODIG

ORP

_OBLIG

ATO

RIORP

_VIGEN

CIARP

_FECHA_IN

ICIO_V

IGRP

_FECHA_T

ERMIN

O_VIG

NUM

BER(10)

NUM

BER(4)

VARCH

AR2(1)VA

RCHAR2(1)

DATE

DATE

<pk><fk>

AD_R

ESOLU

CION

NUM

_SO

LICITUD

RE_C

ODIG

ORE

_ESTA

DORE

_OB

SERVA

CION

RE_F

ECHA_RE

SOLUC

ION

PRS_RUT

NUM

BER(10)

NUM

BER(4)

NUM

BER(4)

VARCH

AR2(100)DA

TENU

MBER

(9)

< pk,fk2><pk><fk1>

AD_S

ISTEM

AS_ADM

ISIO

N

SA_CO

DIGO

SA_DES

CRPCIO

NSA

_VIGEN

CIASA

_INICIO

_VIGSA

_TERM

INO_VIG

NUM

BER(4)

VARC

HAR2(50)

VARC

HAR2(1)

DATE

DATE

<pk> A

D_SISTE

MAS_IN

GRES

O_U

CN

SA_C

ODIG

OTI_C

ODIG

OSI_V

IGENC

IASI_IN

ICIO_V

IGSI_T

ERMIN

O_VIG

SI_EXIG

ENCIA

_PAASI_E

XIGEN

CIA_PO

STULAC

ION

SI_OB

SERVAC

ION

SI_MO

DALIDA

D_COBR

O

NUM

BER

(4)NU

MB

ER(4)

VARCH

AR2(1)DA

TEDA

TEVA

RCHAR2(1)

VARCH

AR2(1)VA

RCHAR2(240)

NUM

BER

(2)

<pk,fk1><pk,fk2>

AD_TIPO

_FINANC

IAMIENT

O

TF_CO

DIGO

TF_DES

CRIPC

ION

TF_EQ

_PAA

NUM

BER

(4)VA

RCHAR2(50)

VARCH

AR2(50)

<pk>A

D_TIPOS_DE

PENDE

NCIA_ECON

OM

ICA

TDE_CO

DIG

OTD

E_DESCR

IPCIO

NTD

E_EQ_PA

A

NUM

BER(4)

VARCH

AR2(50)VA

RCHAR2(50)

<pk>

AD_T

IPOS

_EDUC

ACIO

N

TE_CO

DIGO

TE_DES

CRIPC

ION

TE_EQ

_PAA

NUMB

ER(4)

VARCH

AR2(50)VAR

CHAR2(50)

<pk>

AD_TIPO

S_ESTA

DOS_R

ESOLUC

IONE

S

TER_CO

DIGO

TER_DE

SCRIPC

ION

NUM

BER(4)

VARCH

AR2(50)<pk>

AD_TIPO

S_ING

RESO

TI_CO

DIGO

TI_DES

CRIPCIO

NT

I_VIGE

NCIAT

I_INICIO

_VIGT

I_TERM

INO_VIG

NUM

BER(4)

VARC

HAR2(50)

VARC

HAR2(1)

DATE

DATE

<pk>

AD_TIPO

S_POS

TULACIO

N

TP_C

ODIG

OTP

_NO

MBR

ETI_C

ODIG

OSA

_CO

DIGO

NUMB

ER(4)VAR

CHAR2(50)

NUMB

ER(4)NUM

BER(4)

<pk>

<fk><fk>

AD_V

ACANT

ES_CARR

ERAS

CA_COD

IGO

PL_CO

DIGO

SA_COD

IGO

TI_COD

IGO

VC_ANHO

VC_OFR

ECIDASVC_PO

STULA

DASVC_SE

LECCIO

NADAS

VC_EFEC

TIVAS

VC_FECH

A_ACTUA

LIZAC

ION

VC_RENU

NCIADA

S

NUM

BER(5)

VARCH

AR2(2)NU

MBER

(4)NU

MBER

(4)NU

MBER

(4)NU

MBER

(4)NU

MBER

(4)NU

MBER

(4)NU

MBER

(4)DA

TENU

MBER

(4)

<pk><pk><pk,fk><pk,fk><pk>

RA_CAR

RERAS

_PRG

CA_COD

IGO

CA_NOM

BRE

CA_DURA

CION

CA_COD

IGO

_MINE

DUCCA_CLA

VE_POS

TULA

CION

CA_CLAVE_PR

OJECT

CA_PLAN_ADM

ISION

CA_E_CARR

NUM

BER(5)

VARC

HAR2(50)

NUM

BER(4)

NUM

BER(10)

NUM

BER(10)

NUM

BER(10)

VARC

HAR2(2)

NUM

BER(1)

<pk>

UCN_CO

MUN

AS

CO_CO

DIG

OCO

_NOM

BRE

PV_CO

DIGO

NUM

BER(5)

VARCH

AR2(50)

NUM

BER(4)

<pk>

<fk>

UCN_DIR

ECCIO

NES

DO

M_C

ORRE

LATIVO

RUT

DO

M_V

IGEN

CIAD

OM

_DIRE

CCION

DO

M_T

ELEFO

NOD

OM

_CIUD

ADT

IPO_DO

MIC

ILIOC

O_C

ODIG

OD

OM

_PAIS

DO

M_C

ODIG

O_PO

STAL

NUM

BER(7)

NUM

BER(9)

VARCH

AR2(1)VA

RCHAR2(120)

NUM

BER(10)

VARCH

AR2(50)NU

MBER

(4)NU

MBER

(5)VA

RCHAR2(50)

VARCH

AR2(20)

<fk1><fk2>

UCN_NA

CION

ALIDADES

NA_CO

DIG

ON

A_DESCR

IPCIO

NNU

MBER

(4)VA

RCHAR

2(50)<pk>

UCN_NA

CION

ALIDADES

_PERSO

NA

RUT

NA_C

ODIG

ONA

_FEC

HA_NACIO

NALIDA

DNA

_VIG

ENCIA

NUM

BER(9)

NUM

BER(4)

DATE

VARCH

AR2(2)

<pk,fk2><pk,fk1>

UCN_P

ERSO

NAS

RUT

DV_R

UTAP

ELLIDO_PA

TERNO

APELLIDO

_MATE

RNO

NOM

BRE1

NOM

BRE2

FECHA

_NAC

IMIEN

TOSE

XOEM

AIL

PRO

MEDIO

_NEM

ANHO

_EGRE

SOFE

CHA_D

EF

NUM

BER(9)

VARC

HAR2(1)

VARC

HAR2(50)

VARC

HAR2(50)

VARC

HAR2(50)

VARC

HAR2(50)

DATE

NUM

BER(4)

VARC

HAR2(70)

NUM

BER(3,2)

NUM

BER(4)

DATE

<pk>

<fk>

UCN_PR

OVINC

IAS

PV_CO

DIG

OP

V_NOM

BRE

RG

_CO

DIGO

PV_EQ

_PAA

NUM

BER(4)

VARC

HAR2(50)

NUM

BER(4)

VARC

HAR2(50)

<pk>

<fk>

UCN_RE

GIO

NES

RG_CO

DIG

ORG

_NOM

BRE

NUM

BER(4)

VARCH

AR2(50)

<pk>

UCN_S

EXO

S

SX_CO

DIGO

SX_DES

CRIPCION

SX_EQ

_PAA

NUMB

ER(4)VAR

CHAR2(50)

VARCHA

R2(50)

<pk>

UCN_TIP

OS_DO

MIC

ILIO

TD_CO

DIGO

TD_DES

CRIPC

ION

NUM

BER

(4)VA

RCHAR2(50)

<pk>

AD_RE

QUIS

ITOS_S

ISTEM

A_ING

RSI_CO

RRELAT

IVOT

R_CODIG

OS

A_CODIG

OT

I_CO

DIGO

RSI_EX

IGENC

IA_REQ

RSI_INICIO

_VIGR

SI_TERM

INO_V

IGR

SI_VIGE

NCIA

NUMB

ER(10)NUM

BER(4)

NUMB

ER(4)NUM

BER(4)

VARCHA

R2(1)DAT

EDAT

EVAR

CHAR2(1)

<pk>

<fk><fk>

250

• Datos de Admisión Del modelo ER de la figura C.2 se seleccionaron las siguientes tablas para desarrollar el modelo de prueba:

UCN_PERSONAS, UCN_DIRECCIONES, AD_ADMISIONES, AD_ANTECEDENTES_PAA, AD_MODALIDADES, AD_MODALIDADES_INSTITUCION, AD_TIPOS_EDUCACION, AD_TIPOS_DEPENDENCIA _ECONOMICA, AD_INSTITUCIONES_EDUCACION, AD_INSTITUCIONES_ADMISION, AD_DIRECCIONES_INSTITUCIONES.

En estas tablas se encuentran datos tales como: o Nombre del Alumno. o Colegio de Procedencia. o Región Comuna de Procedencia. o Puntajes obtenidos en las pruebas de selección universitaria. o Tipo de dependencia del colegio. o Carrera de postulación. o Promedio de notas de la enseñanza media.

• Datos de Sistema Curricular Del modelo ER de la figura C.1 se seleccionaron las siguientes tablas:

PERSONAS, PLANES_ALUMS, PLANES_CARR, CARRERAS_RAMOS, SEMESTRE.

En estas tablas se encuentran datos tales como:

o Carrera del alumno. o Estado del alumno en la carrera. o Semestre de inicio del alumno en el plan de una carrera. o Tipo de ingreso a la carrera. o Año de ingreso a la carrera.

C1.2. Descripción de los Datos: Teniendo las fuentes de datos, se hace necesario realizar una descripción de ellos para un mejor entendimiento:

251

Descripción de los datos seleccionados de admisión (tabla C.1).

Tabla C.1. Descripción de los datos de Admisión.

Descripción de los datos de los alumnos antes de ingresar a la Universidad RUT_ALUM Número Rut del Alumno SEME_FIN Número Semestre de fin de la carrera SEME_INI Número Semestre de inicio en la carrera AGNO_IC Número Año de ingreso del alumno a la Carrera ANHO_RENDIR_PAA

Número Año en el cual rindió la Prueba de Aptitud Académica (PAA)

PTJE_EM Número Puntaje otorgado por notas de enseñanza media PTJE_PAA_MAT Número Puntaje obtenido en la PAA de Matemáticas PTJE_SELEC_SB Número Puntaje entregado por selección DOM_VIGENCIA Texto Vigencia del domicilio (S/N) DOM_DIRECCION Texto Dirección donde habita el alumno DOM_CIUDAD Texto Ciudad a la cuál corresponde la dirección del alumno SEXO Texto Sexo que corresponde al alumno APELLIDO_PATERNO

Texto Apellido Paterno del alumno

APELLIDO_MATERNO

Texto Apellido Materno del alumno

NOMBRE1 Texto Nombre del alumno PROMEDIO_NEM Número Promedio de las Notas de Enseñanza Media (NEM) ANHO_EGRESO Número Año en el cuál egresa de Enseñanza Media TE_DESCRIPCION Texto Descripción del tipo de enseñanza en el colegio. TDE_DESCRIPCION Texto Descripción de la dependencia del Estado del Colegio.

252

Descripción de los datos seleccionados de SIMBAD (tabla C.2).

Tabla C.2. Descripción de los datos del Sistema Curricular.

Descripción de los datos del Sistema Curricular CARRERA Número Código Carrera PLAN Número Código del plan de la carrera F_ACTUALIZACION Fecha/Hora Fecha de actualización del registro MATRICULA Número Número de matrícula del alumno en la carrera RUT_ALUM Número Rut del alumno V_PLAN_ALUM Número Vigencia del alumno en la carrera-plan EST_ALUM Texto Estado del alumno en la carrera SEME_FIN_CARR Número Semestre de fin de la carrera FEC_SEME_FIN_CARR Fecha/Hora Fecha de inicio del semestre el cuál finaliza la carrera SEME_INI_PLAN Número Semestre de inicio del alumno en el plan de la carrera FEC_SEME_INI_PLAN Fecha/Hora Fecha de inicio del semestre el cuál inicia el plan de la carrera SEME_FIN_PLAN Número Semestre de término del alumno en el plan de la carrera FEC_SEME_FIN_PLAN Fecha/Hora Fecha de inicio del semestre el cual finaliza el plan de la carrera

253

C2. Preparación de los datos En esta etapa, se concentraron los mayores esfuerzos por cuanto la limpieza de la información exige en algunos casos, realizar determinadas tareas manualmente. Selección de los datos: Para trabajar con los datos seleccionados, se creó una consulta que uniera toda la información del universo de datos relevante, en una sola tabla. La consulta realizada en la Base de Datos de JPSIAM es la siguiente: SELECT * INTO Datos_Admisión FROM UCN_PERSONAS, UCN_DIRECCIONES, AD_ADMISIONES, AD_ANTECEDENTES_PAA, AD_MODALIDADES, AD_MODALIDADES_INSTITUCION, AD_TIPOS_EDUCACION, AD_TIPOS_DEPENDENCIA _ECONOMICA, AD_INSTITUCIONES_EDUCACION, AD_INSTITUCIONES_ADMISION WHERE UCN_PERSONAS.RUT = UCN_DIRECCIONES.RUT AND UCN_PERSONAS.RUT = AD_ADMISIONES.RUT AND AD_ADMISIONES.AD_INSCRIPCION = AD_INSTITUCIONES_ADMISION.AD_INSCRIPCION AND AD_INSTITUCIONES_ADMISION.IE_CODIGO_UCN = AD_MODALIDADES_INSTITTUCION.IE_CODIGO_UCN AND AD_MODALIDADES_INSTITUCION.IE_CODIGO_UCN = AD_INSTITUCIONES_EDUCACION.IE_CODIGO_UCN AND AD_INSTITUCIONES_EDUCACION.IE_CODIGO_UCN = AD_DIRECCIONES_INSTITUCIONES.IE_CODIGO_UCN AND AD_MODALIDADES.MO_MODALIDAD = AD_MODALIDADES_INSTITUCION.MO_MODALIDAD AND AD_TIPOS_DEPENDENCIA_ECONOMICA.TDE_CODIGO = AD_MODALIDADES.TDE_CODIGO AND AD_MODALIDADES.TE_CODIGO = AD_TIPOS_EDUCACION.TE_CODIGO En la Base de Datos del Sistema Curricular (SIMBAD) se realizaron las siguientes consultas de preparación: Selección de Alumnos: C_CARRERA = 8613: Ingeniería Civil Industrial AGNO_IC = 1996: Año de ingreso a la carrera (en este ejemplo es el 1996) T_INGRESO = 1: Ingreso regular SELECT * INTO Planes_Alum FROM CURRI_PLANES_ALUMS WHERE CURRI_PLANES_ALUMS.P_AL_C_CARRERA = 8613 and CURRI_PLANES_ALUMS.P_AL_AGNO_IC = 1996 and CURRI_PLANES_ALUMS.P_AL_T_INGRESO = 1 Reemplazar código del estado del alumno a su descripción original: SELECT Planes_Alum.*, CURRI_E_CARR_ALUM.E_CA_CODIGO, CURRI_E_CARR_ALUM.E_CA_TEXTO FROM Planes_Alum, CURRI_E_CARR_ALUM WHERE Planes_Alum.P_AL_E_CARR_ALUM = CURRI_E_CARR_ALUM.E_CA_CODIGO Columna E_CA_TEXTO renombrada para mayor legibilidad a EST_ALUM

254

Reemplazar los códigos semestre con los años y fechas correspondientes: Renombrar SEME_FIN SELECT Planes_Alum.*, CURRI_SEMESTRE.SEME_AGNO, CURRI_SEMESTRE.SEME_F_INI_ESTIMADO FROM Planes_Alum LEFT JOIN CURRI_SEMESTRE ON Planes_Alum.P_AL_SEME_FIN = CURRI_SEMESTRE.SEME_C_SEM Columna SEME_AGNO renombrada para mayor legibilidad a SEME_FIN_CARR. Columna F_INI_ESTIMADO renombrada a FEC_SEME_FIN_CARR (el semestre en el cuál el alumno termina su carrera, es el semestre cuya fecha de inicio es F_INI_ESTIMADO, de esta forma se puede discriminar si es el 1er Semestre o 2do semestre), esto se realizó para los casos que quedan a continuación. Renombrar P_AL_SEME_INI_PLAN SELECT Planes_Alum.*, CURRI_SEMESTRE.SEME_AGNO, CURRI_SEMESTRE.SEME_F_INI_ESTIMADO FROM Planes_Alum, CURRI_SEMESTRE WHERE Planes_Alum.P_AL_SEME_INI_PLAN = CURRI_SEMESTRE.SEME_C_SEM Columna SEME_AGNO renombrada para mayor legibilidad a SEME_INI_PLAN. Columna F_INI_ESTIMADO renombrada a FEC_SEME_INI_PLAN. Renombrar P_AL_SEME_FIN_PLAN SELECT Planes_Alum.*, CURRI_SEMESTRE.SEME_AGNO, CURRI_SEMESTRE.SEME_F_INI_ESTIMADO FROM Planes_Alum LEFT JOIN CURRI_SEMESTRE ON Planes_Alum.P_AL_SEME_FIN_PLAN = CURRI_SEMESTRE.SEME_C_SEM Columna SEME_AGNO renombrada para mayor legibilidad a SEME_FIN_PLAN. Columna F_INI_ESTIMADO renombrada a FEC_SEME_FIN_PLAN. Al tener estas consultas realizadas y sus instancias guardadas, se traspasó la información obtenida desde el software TOAD a Microsoft Access, por la comodidad que entrega este último, para realizar filtrados de forma manual y la posibilidad de transportar de manera más cómoda los datos (ver figura C.3). Se realizó un filtrado de información, en base a la carrera (CA_CODIGO) y al año de admisión (AD_ANHO_ADMISION) en el cual se definieron distintas cohortes, que se almacenaron de forma independiente (tablas) en la base de datos utilizada para el modelo de prueba:

• Año admisión 1996; carrera 8613(Ingeniería Civil Industrial) cohorte de 1996 • Año admisión 1997; carrera 8613(Ingeniería Civil Industrial) cohorte de 1997 • Año admisión 1998; carrera 8613(Ingeniería Civil Industrial) cohorte de 1998 • Año admisión 1999; carrera 8613(Ingeniería Civil Industrial) cohorte de 1999

255

Figura C.3. Bases de Datos obtenidas.

Limpieza de los datos: Limpieza de datos de admisión En las distintas Cohortes obtenidas, al enlazar las tablas aparecieron duplicidad de datos, el problema fue resuelto de la siguiente forma: Duplicidad de domicilio: Para el modelo de prueba desarrollado, no interesa el lugar donde aloja el alumno, lo que interesa es la localidad de la que proviene. Lo realizado, se describe a modo de ejemplo: Un alumno que posee en el campo DOM_CIUDAD (ciudad en la que vive el alumno) un registro de la ciudad de Antofagasta y uno de la ciudad de Calama, se deja el de Calama, ya que si posee un registro de una ciudad externa a Antofagasta (donde se encuentra la Universidad Católica del Norte) quiere decir que el alumno proviene de esa ciudad y por tanto se elimina el resto de registros, siempre y cuando el campo DOM_VIGENCIA (si domicilio está vigente) sea “NO”. La procedencia del alumno es importante; ya que es utilizada para poder identificar el nombre del colegio del cual proviene y seleccionar el tipo de dependencia que posee (municipal, subvencionado, etc.). Duplicidad de tipo de dependencia de los colegios: Se genera duplicidad en los tipos de dependencias de los colegios, ya que con la unión de las Bases de Datos de la figura C.3 se seleccionan las cuatro posibilidades (particular pagado, particular subvencionado, desconocido y municipal). Para solucionar este problema de información no consistente, se optó por acudir al sitio web del MINEDUC (Ministerio de Educación de Chile), http://www.mineduc.cl/DirectorioMineduc/DirectorioMineduc.html, en el cual, al saber la procedencia (DOM_CIUDAD) del alumno, se buscaba el colegio indicado en el campo IE_NOMBRE (nombre del colegio) para obtener la dependencia del colegio de una fuente fidedigna y confiable.

JPSIAM SIMBAD

Datos_Admisión.mdb Planes_Alum.mdb

256

Al limpiar estos dos campos, se eliminó la duplicidad y se obtuvieron registros no ambiguos y únicos. Cabe mencionar que no existían campos nulos en los atributos de interés para el desarrollo del modelo de prueba. Preparación de los datos: En la base de datos del SIMBAD los campos de interés son: SEME_FIN_CARR (contiene el año en que el alumno terminó su carrera) y EST_ALUM que contiene el estado del alumno el cual pueden ser:

• Alumno regular • Egresado • Egresado Eliminado • Alumno Eliminado • Titulado • Renunciado • Fallecido • Renuncia Admisión • No Continuidad • Afecto • Licenciado (S) • De Intercambio

Posteriormente se enlazaron las Bases de Datos para ver la correspondencia de los datos según las Cohortes, en donde la Base de Datos SIMBAD entrega más registros de alumnos que JPSIAM. Al verificar estos alumnos, en JPSIAM aparecían en otra carrera, por tanto se llega a la conclusión de que estos alumnos realizaron un cambio de carrera, razón por la que no ingresan al modelo de prueba. Una vez limpia la base de datos SIMBAD, se integra con la generada desde JPSIAM (figura C.4), creando una Base de Datos Access Dato_Admisión_Estado.mdb la cual será utilizada en el modelo de prueba.

Figura C.4. Integración de las Bases de Datos seleccionadas

Datos_Admisión.mdb Planes_Alum.mdb

Dato_Admision_Estado.mdb

Limpieza y Selección

257

C3. Modelado El objetivo del modelo de prueba, es reconocer un perfil de ingreso de los alumnos de la carrera Ingeniería Civil Industrial, que permita estimar si un alumno egresará de su carrera o no. Como se quiere trabajar con modelos predictivos o clasificadores, se optó por trabajar con árboles de decisión y redes neuronales. Para este tipo de modelos se debe contar con una variable a predecir y un conjunto de entradas al modelo. La herramienta para modelar es CLEMENTINE v11.1. Una vez que se tiene el archivo con los atributos y registros correctos (figura C.4), se crean dos nuevos atributos:

• EGRESADO

• PROCEDENCIA El primero, EGRESADO se deriva del atributo EST_ALUM, este atributo toma los siguientes valores:

• “SI” cuando EST_ALUM es “EGRESADO”, “TITULADO”, “EGRESADO ELIMINADO”.

• “NO” cuando EST_ALUM es “ELIMINADO”, “AFECTO”, “NO CONTINUIDAD”.

El segundo, PROCEDENCIA, se deriva del atributo DOM_CIUDAD, este atributo toma los siguientes valores:

• “LOCAL” cuando el DOM_CIUDAD es “ANTOFAGASTA”.

• “EXTERNO” cuando el DOM_CIUDAD es distinto a “ANTOFAGASTA”.

Entonces para el modelo de prueba se tiene:

• Variable a predecir: EGRESADO, la cual arroja como resultado SI/NO.

• Variables de entrada: o Tipo de dependencia del Colegio (Particular, Subvencionado,

Municipal).

o Tipo de educación del Colegio (Científico Humanista, Técnico Profesional, Alumnos Libres).

o Procedencia del alumno (Local/Externo).

o Promedio NEM del alumno.

o Promedio PAA/PSU sin bonificación.

258

Figura C.5. Distribución de EGRESADOS en Cohortes 1996 y 1997.

Creados estos campos y los modelos a utilizar para desarrollar el modelo de prueba, se elige como datos de entrenamiento las Cohortes de 1996 y 1997, mientras que se considera datos para validación las Cohortes de 1998 y 1999. Antes de generar el modelo, se buscaron variables que indicaran algún patrón de comportamiento de manera de crear un mejor modelo. El resultado del análisis a las dos cohortes de entrenamiento (cohortes 1996 y 1997) que se utilizaron para crear el modelo, se muestran en la figura C.5. El porcentaje de egresados en ambas cohortes es cercano al 24,42%, esto indica que pueden tener un comportamiento similar las cohortes. Para las cohortes del 1996 y 1997 se puede distinguir que las variables (no numéricas) que más incidirán en el modelo de prueba, (enlaces más gruesos) son la procedencia local/externo, tipo de dependencia del colegio (particular subvencionado) y tipo de enseñanza del colegio (científico-humanista) como muestran las figuras C.6 y C.7.

Figura C.6. Gráfico Malla de la Cohorte 1996.

259

Figura C.7. Gráfico Malla de la Cohorte 1997.

Para ver la importancia del NEM en ambas cohortes, se realiza el gráfico correspondiente con los EGRESADOS (figura C.8), donde se observa la tendencia de que los egresados tienen notas mayores a 5.5, aunque en una de estas cohortes, hay una excepción de dos alumnos con nota menor (Cohorte 1996).

Figura C.8. Gráfico de Egresados V/s NEM, Cohortes 1996 y 1997

Al verificar si existe alguna tendencia respecto del puntaje de selección de los alumnos en ambas cohortes de entrenamiento (1996 y 1997), según la figura C.9, no es muy clara la relación entre estos dos campos, se verá si con el modelo, se logra identificar algún patrón para el puntaje.

260

Figura C.9. Gráficos Egresados V/S Puntaje de Selección, Cohortes 1996 y 1997. Una vez identificada la importancia que tienen las variables de entrada, se procede a la construcción del modelo, para lo cual se utilizaron tres tipos de modelado: Red Neuronal, Árbol C&R y Árbol C5.0. Según CLEMENTINE v11.1, estos algoritmos se definen como:

• Red Neuronal: Las redes neuronales, son modelos simples que emulan el funcionamiento del sistema nervioso. Las unidades básicas, son las neuronas, que generalmente se organizan en capas.

• Árbol C&R: El nodo Árbol de clasificación y regresión (C&R) es un método de pronóstico y clasificación basado en árboles. Similar a C5.0, este método utiliza la partición reiterada para dividir los registros de entrenamiento en segmentos con valores de campo de salida similares. El árbol C&R comienza por realizar un examen de los campos de entrada, para buscar la mejor división que se ha medido mediante la reducción del índice de impureza resultado de la división. La división define dos subgrupos, que se siguen dividiendo en otros dos subgrupos sucesivamente hasta que se activa un criterio de parada. Todas las divisiones son binarias (sólo se crean dos subgrupos).

• Árbol C5.0: Este nodo utiliza el algoritmo C5.0 para generar un árbol de decisión o un conjunto de reglas. Los modelos C5.0 dividen la muestra en función del campo que ofrece la máxima ganancia de información. Las distintas submuestras definidas por la primera división se vuelven a dividir, por lo general basándose en otro campo, y el proceso se repite hasta que resulta imposible dividir las submuestras de nuevo. Por último se vuelven a examinar las divisiones del nivel inferior, y se eliminan o podan las que no contribuyen significativamente con el valor del modelo.

261

Figura C.10. Modelo de Prueba.

Creación (entrenamiento) del Modelo: El Modelo de prueba resultante, con los tres algoritmos mencionados anteriormente se muestra en la figura C.10, donde se observa en la parte inferior el entrenamiento o desarrollo del(los) modelo(s) de prueba, mientras que en la parte superior la validación de los modelos creados, con las cohortes del 1998 y 1999. Se utilizó la herramienta seleccionar, para dejar fuera del análisis a los alumnos que aun no egresaban y que tenían su EST_ALUM igual a REGULAR, luego se generaron los siguientes tres modelos con los siguientes resultados. Red Neuronal: La red clasifica correctamente al 80,24% de los registros (figura C.11). El problema es que ésta, junto con la matriz de coincidencias, es la única información que aporta. No es posible saber cómo realizó la clasificación ni que atributos tomó como importantes.

Figura C.11. Resultado de la creación del Modelo de prueba con Redes Neuronales.

262

Esto cambia al utilizar el algoritmo de árboles de decisión. Los resultados de la clasificación son los siguientes: Árbol C&R: De acuerdo a los resultados consignados en la figura C.12, éste modelo clasifica correctamente el 88,02% de los registros, dando un error sólo a 20 de estos registros, equivalente al 11,98%.

Figura C.12. Resultado de la creación del Modelo de prueba con Árboles C&R.

Además se concluye que la variable que más incide en el egreso es el NEM (menor a 5.9 y mayor a 5.9), ya que es la hoja de mayor nivel en el árbol (ver figura C.13).

Figura C.13. Árbol resultante del modelo C&R.

263

Árbol C5.0: De acuerdo a los resultados consignados en la figura C.14, éste modelo clasifica correctamente el 81,44% de los registros, dando un error sólo a 31 de estos registros (11 registros más que el árbol C&R), equivalente al 18,56%.

Figura C.14. Resultado de la creación del Modelo de Prueba con Árboles C5.0.

Este modelo encontró que la variable que más incide en el egreso, es el NEM (menor a 5.6 y mayor a 5.6) dentro de éste, hay excepciones las cuales se pueden visualizar en el árbol de la figura C.15.

264

Figura C.15. Árbol resultante del modelo C5.0.

265

Validación del Modelo de Prueba: Una vez concluido el proceso de entrenamiento del modelo, es necesario validarlo, para esto como datos de prueba se utilizaran las cohortes, de 1998 y 1999. Al ingresar estas cohortes como entrada a los modelos mencionados anteriormente, se obtuvieron los siguientes resultados: Red Neuronal: Este modelo al validarlo arroja un 75% de Certeza en los datos de estas Cohortes (ver figura C.16), pero como se dijo con anterioridad, el problema es la explicación (justificación) de los resultados obtenidos.

Figura C.16. Resultado de la validación del Modelo de prueba con Redes Neuronales.

Árbol C&R: Este modelo predice con el mismo porcentaje de certeza que la red neuronal (figura C17), pero con la diferencia que éste muestra de forma gráfica, cómo cataloga a los distintos alumnos.

Figura C.17. Resultado de la validación del Modelo de prueba con Árboles C&R.

266

Árbol C5.0: Este modelo entrega un porcentaje de certeza más bajo que los dos modelos anteriores (figura C.18), lo cual podría explicarse porque éste fija el NEM, más bajo que el Árbol C&R.

Figura C.18. Resultado de la validación del Modelo de prueba con Árboles C5.0.

267

ANEXO D: DOCUMENTO FINAL DE CONTRATO.

i

Universidad Católica del Norte Facultad de Ingeniería y Ciencias Geológicas

Departamento de Ingeniería de Sistemas y Computación

DOCUMENTO DE REQUISITOS SOLUCIÓN DATA MINING

Antofagasta, Enero 2009

FICHA DEL DOCUMENTO

iii

FECHA 23/01/09

AUTORES Carlos Díaz Mondaca

Luis Salinas Díaz Documento validado por las partes:

v

ÍNDICE ÍNDICE .............................................................................................................. v 1. INTRODUCCIÓN ..................................................................................... vii

1.1 Propósito .................................................................................................................. vii

1.2 Alcance ..................................................................................................................... vii

1.3 Personal involucrado ............................................................................................. viii

1.4 Definiciones, Acrónimos y Abreviaturas ............................................................. viii

1.5 Referencias ............................................................................................................. viii

1.6 Visión General del Documento ............................................................................... ix

2. DESCRIPCIÓN GENERAL ...................................................................... xi 2.1 Perspectiva del Producto ........................................................................................ xi

2.2 Funciones del Producto ........................................................................................... xi

2.3 Características de los Usuarios ............................................................................... xi

2.4 Restricciones .......................................................................................................... xii

2.5 Suposiciones y Dependencias ................................................................................ xii

3. REQUISITOS ESPECÍFICOS .............................................................. xiii 3.1 Requisitos funcionales ........................................................................................... xiii

4. APÉNDICES ......................................................................................... xxiii APÉNDICE A .............................................................................................................. xxiii

ÁPENDICE B ................................................................................................................ xxv

APÉNDICE C ............................................................................................................. xxvii

APÉNDICE D .............................................................................................................. xxix

vii

1. INTRODUCCIÓN El siguiente documento, tiene como objetivo especificar las necesidades funcionales que deberá soportar la solución Data Mining a desarrollar. Esta solución pretende identificar y analizar las causas de atraso en la titulación oportuna de alumnos de Pre-grado de la carrera de Ingeniería Civil Industrial, mediante el uso de Business Intelligence. Se identifican los requisitos que ha de satisfacer la solución Data Mining, recopilados mediante técnicas de ingeniería de requisitos, además de restricciones para validar la solución y que se ajustan a las necesidades del usuario.

1.1. Propósito.

El presente documento tiene un doble propósito. Primero, tener un documento que especifique los requisitos de los Stakeholders y de los diseñadores de la solución Data Mining y segundo, tener una referencia tangible del acuerdo entre los diseñadores de la solución Data Mining y los usuarios, de manera de enfocar el desarrollo y los objetivos descritos en el presente documento y lograr los resultados esperados. El presente documento de requisitos, va dirigido tanto a los usuarios o personas involucradas en los resultados de la solución Data Mining, como a las personas involucradas en el desarrollo.

1.2. Alcance. El alcance considerado para la solución Data Mining, involucra el análisis de los datos de estudiantes de la Carrera de Ingeniería Civil Industrial de la Universidad Católica del Norte, por la simple razón de que su ingreso es directo, lo cual disminuye la complejidad de la solución. Para tener más detalle del alcance de la solución revisar APÉNDICE A.

1.2.1. Objetivo Identificar y analizar las variables que afectan la tasa de titulación y tiempo de duración de la Carrera (número de años) de Ingeniería Civil Industrial. Para ello, se analizará el Avance Curricular que se observa en las respectivas cohortes, con el fin de poder intervenir “oportunamente” y mejorar las tasas y tiempo de titulación. Para mayor detalle revisar APÉNDICE B.

viii

1.3. Personal involucrado. El desarrollo de la solución Data Mining, así como los requisitos a satisfacer, se obtienen de personas internas a la Universidad Católica del Norte, en donde se identifican los siguientes roles (revisar APÉNDICE C):

• Patrocinador: La unidad para la cual se desarrolla el proyecto y que tiene como función principal, coordinar que los recursos organizacionales requeridos por los ejecutantes del proyecto, estén disponibles de acuerdo al plan de trabajo propuesto. Esta unidad es la de Vicerrectoría Académica y como representante, el Auditor General Señor Orlando Castro.

• Experto en el dominio de Negocio: Tiene a su cargo la conducción del proceso de definición de los requisitos organizacionales, asesorando además sobre las fuentes de datos que deben ser utilizados en el proyecto y la validación de los resultados de éste. Este experto, es el Jefe del Departamento de Gestión Académica, Sr. Santiago Sánchez Varela, de la Dirección General de Docencia.

• Equipo de desarrollo del proyecto: Personas que tienen a cargo la responsabilidad de planificar y ejecutar el proyecto. Tal equipo está formado inicialmente por los memoristas Señores: Carlos Díaz M. y Luis Salinas D.

1.4. Definiciones, Acrónimos y Abreviaturas. Para la interpretación apropiada del documento así como de los requisitos de los usuarios, se describen en el APÉNDICE D las definiciones recopiladas.

1.5. Referencias. Documentos relacionados en la especificación de los requisitos de la solución Data Mining:

Referencia Título Fecha Autor [Gallardo, 2008] “Metodología ER-DM” 1998 Gallardo A. José

[PDC, 2003] “Plan de Desarrollo Corporativo de la UCN, años 2004-2008” 2003 Universidad Católica

del Norte

[Yu, 1995] "Strategic Modelling for Enterprise Integration" 1995 Eric Yu

ix

1.6. Visión General del Documento. El documento de requisitos para la solución Data Mining, se estructura inicialmente de la siguiente forma: una breve descripción general del producto a desarrollar, en este caso utilizando Business Intelligence (Data Mining). Luego en forma más detallada, se describen los requisitos que se desean satisfacer mediante una solución de análisis de datos con Data Mining, considerando las correspondientes restricciones para la validez de la solución encontrada.

xi

2. DESCRIPCIÓN GENERAL

2.1. Perspectiva del Producto. El presente documento es parte de un proyecto, contexto en el cual, se encuentra el desarrollo de una Memoria de titulación en la carrera de Ingeniería Civil en Computación e Informática, del Departamento de Ingeniería de Sistemas y Computación, de la Universidad Católica del Norte. Dicho proyecto consiste en la identificación y análisis de las causas de atraso en la titulación oportuna de alumnos de Pre-grado de la UCN, mediante el uso de Business Intelligence (BI), específicamente una solución Data Mining.

2.2. Funciones del Producto. Dentro de las funciones que debe tener la solución Data Mining a desarrollar se consideran, como se consigna en el APÉNDICE B, los siguientes requisitos organizacionales específicos:

1. Confirmar si el perfil de los estudiantes influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, Quintil, entre otros).

2. Identificar patrones de comportamiento o tendencias en ciertas asignaturas.

3. Validar si la eliminación corresponde al ciclo básico, es decir, si se debe a las asignaturas de ciencias básicas.


2.3. Características de los Usuarios. El usuario potencial del producto, es el Cliente de la solución a desarrollar, Don Santiago Sánchez Varela, Jefe Dpto. Gestión Académica, el cual tiene a su cargo la conducción del proceso de captura y validación de los requisitos de negocio, asesorando sobre la decisión sobre qué datos deben ser utilizados en el proyecto (APÉNDICE D).

xii

2.4. Restricciones.

• Como se indica en el APÉNDICE A, una de las restricciones de los modelos a desarrollar en la solución Data Mining y los cuáles responden a las funciones descritas anteriormente, es la consideración de una sola carrera, esta carrera es la de Ingeniería Civil Industrial.

• Se especifica que no se analizarán variables que afecten a los alumnos eliminados por razones económicas.

• Los modelos a desarrollar deben estar basados, en la mayoría y si corresponde, en árboles de decisión para una mejor interpretación.

• Si al obtener información de las cohortes en determinada tabla, algún registro no se encuentra en otra tabla a utilizar, dicho registro procede ser eliminado según el requisito a satisfacer. Por ejemplo, si se tienen las notas de las asignaturas para un determinado alumno de una determinada cohorte, pero en la Base de Datos no se encuentran sus datos anteriores al ingreso a la Universidad, dicho registro será eliminado para satisfacer el requisito: Confirmar si el perfil de los estudiantes influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, entre otros).

2.5. Suposiciones y Dependencias. La captura de los requisitos para el desarrollo de la solución Data Mining se estableció según la Metodología ER-DM [Gallardo, 2008] y en base al framework i* [Yu, 1995], por tanto, los requisitos establecidos en el presente documento, dependen de la aplicación de la metodología ER-DM y el framework i*. Se considera como supuesto, que los datos obtenidos desde las Bases de Datos a las cuales se permitió el acceso, corresponden a las cohortes de los distintos años para la carrera de Ingeniería Civil Industrial.

xiii

3. REQUISITOS ESPECÍFICOS En el presente capítulo, se detallan todos los requisitos de la solución Data Mining, a un nivel de detalle suficiente para permitir a los desarrolladores diseñar una solución que satisfaga estos requisitos y al cliente probar que el sistema satisface esos requisitos.

3.1 Requisitos Funcionales. En base a la metodología ER-DM [Gallardo, 2008] y los artefactos resultantes de ésta, se encuentran los casos de uso que Data Mining debe satisfacer, estos casos de uso se describen en la siguiente figura:

Sistema

Jefe de Gestión Académica

Dirección General

de Docencia

Unidad Académica

Unidad de Análisis

Institucional

Identificar Causas

Verificar Influencia Perfildel Estudiante

IdentificarTendencia en Asignaturas

Verificar Causas EliminaciónCiclo Básico

Ponderar Efecto Ciclo Básico y

Profesional

Consultar Resultados

Estudiar Capacidades Académicas

Estudiar Impacto propuestas DGD

<<include>>

<<include>><<include>>

<<include>>

<<include>> <<include>>

Data Mine Use Case

Data Mine Use Case

Data Mine Use Case

Data Mine Use Case

Casos de Uso de la solución Data Mining

En base a los Data Mine Use Case o Casos de uso de Data Mining, se describen los siguientes requisitos funcionales:

xiv

REQ. 01 Verificar Influencia del Perfil de los Estudiantes Objetivo: Confirmar si el perfil de los estudiantes influye directamente en el

desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, entre otros). Descripción: Se describe en la siguiente tabla el Requisito N°01 (Caso de uso

identificado):

Caso de Uso

Verificar Influencia del Perfil de los Estudiantes Autor: Carlos Díaz, Luis Salinas ID: RQ 01 Tipo: DM Fecha de Creación: 15/08/08 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite verificar si el perfil de los estudiantes influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, Quintil, entre otros).

Actor Primario Jefe de Gestión Académica Actor Secundario

Supuestos Se cuentan con todos los datos necesarios para realizar la verificación Recursos • Datos de una determinada cohorte

• Datos de Académicos Pasos 6. El actor Jefe de Gestión Académica suministra todos los datos de una cohorte y

académicos. 7. Se definen cuales son los datos que se precisan para realizar la verificación del

perfil. 8. Se efectúa la preparación de los datos. 9. Se determinan los modelos necesarios para realizar el estudio (Verificación). 10. Se procede a desplegar los resultados


Requisitos de Calidad, se necesita que los resultados entregados posean un grado de confianza razonable.

Aspectos pendientes

Entrada: Como entradas al diseño de los Modelos en Data Mining, se consideran

las siguientes Tablas: Cohortes y Datos_Alumnos. Descripción de los datos de las Cohortes CARRERA Número Código Carrera PLAN Número Código del plan de la carrera F_ACTUALIZACION Fecha/Hora Fecha de actualización del registro MATRICULA Número Número de matrícula del alumno en la carrera RUT_ALUM Número Rut del alumno V_PLAN_ALUM Número Vigencia del alumno en la carrera-plan EST_ALUM Texto Estado del alumno en la carrera SEME_FIN_CARR Número Semestre de fin de la carrera FEC_SEME_FIN_CARR Fecha/Hora Fecha de inicio del semestre con que finaliza la carrera

xv

Descripción de los datos de las Cohortes SEME_INI_PLAN Número Semestre de inicio del alumno en el plan de la carrera FEC_SEME_INI_PLAN Fecha/Hora Fecha de inicio del semestre con que inicia el plan de la carrera SEME_FIN_PLAN Número Semestre de término del alumno en el plan de la carrera FEC_SEME_FIN_PLAN Fecha/Hora Fecha de inicio del semestre con que finaliza el plan de la carrera

Descripción de los datos de los alumnos antes de ingresar a la Universidad RUT_ALUM Número Rut del Alumno SEME_FIN Número Semestre de fin de la carrera SEME_INI Número Semestre de inicio en la carrera AGNO_IC Número Año de ingreso del alumno a la Carrera ANHO_RENDIR_PAA Número Año en el que rindió la Prueba de Aptitud Académica (PAA) PTJE_EM Número Puntaje otorgado por notas de enseñanza media PTJE_PAA_MAT Número Puntaje obtenido en la PAA de Matemáticas PTJE_SELEC_SB Número Puntaje entregado por selección DOM_VIGENCIA Texto Vigencia del domicilio (S/N) DOM_DIRECCION Texto Dirección donde habita el alumno DOM_CIUDAD Texto Ciudad a la cuál corresponde la dirección del alumno SEXO Texto Sexo que corresponde al alumno APELLIDO_PATERNO Texto Apellido Paterno del alumno APELLIDO_MATERNO Texto Apellido Materno del alumno NOMBRE1 Texto Nombre del alumno PROMEDIO_NEM Número Promedio de las Notas de Enseñanza Media (NEM) ANHO_EGRESO Número Año en el que egresa de Enseñanza Media TE_DESCRIPCION Texto Descripción del tipo de enseñanza en el colegio. TDE_DESCRIPCION Texto Descripción de la dependencia del Estado del Colegio.

Salida: La salida o respuesta entregada por la solución Data Mining, es un árbol de decisión con sus distintas ramas y porcentajes asociados. Opcionalmente: No se descarta otra posible entrega tales como, gráficos que describan el requisito.

xvi

REQ. 02 Identificar Tendencias en Asignaturas Objetivo: Identificar patrones de comportamiento o tendencias de ciertas asignaturas. Descripción: Se describe en la siguiente tabla el Requisito N°02 (Caso de uso

identificado):

Caso de Uso

Identificar Tendencias en Asignaturas Autor: Carlos Díaz, Luis Salinas ID: RQ 02 Tipo: DM Fecha de Creación: 17/08/08 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite Identificar patrones de comportamiento o tendencias de ciertas asignaturas.

Actor Primario Jefe de Gestión Académica Actor Secundario Supuestos Se cuentan con todos los datos necesarios para realizar el descubrimiento Recursos • Datos de una determinada cohorte

• Datos de Académicos Pasos 6. El actor Jefe de Gestión Académica suministra todos los datos de una cohorte

y académicos. 7. Se definen cuales son los datos que se precisan para realizar el

descubrimiento de tendencias. 8. Se efectúa la preparación de los datos. 9. Se determinan los modelos necesarios para realizar el estudio

(descubrimiento, Relación). 10. Se procede a desplegar los resultados



Aspectos pendientes Entrada: Como entradas al diseño de los Modelos en Data Mining se consideran

las siguientes Tablas: Cohortes y Cursos_Inscritos. Descripción de los datos de las Cohortes CARRERA Número Código Carrera PLAN Número Código del plan de la carrera F_ACTUALIZACION Fecha/Hora Fecha de actualización del registro MATRICULA Número Número de matrícula del alumno en la carrera RUT_ALUM Número Rut del alumno V_PLAN_ALUM Número Vigencia del alumno en la carrera-plan EST_ALUM Texto Estado del alumno en la carrera SEME_FIN_CARR Número Semestre de fin de la carrera FEC_SEME_FIN_CARR Fecha/Hora Fecha de inicio del semestre con que finaliza la carrera SEME_INI_PLAN Número Semestre de inicio del alumno en el plan de la carrera FEC_SEME_INI_PLAN Fecha/Hora Fecha de inicio del semestre con que inicia el plan de la carrera SEME_FIN_PLAN Número Semestre de término del alumno en el plan de la carrera

xvii

Descripción de los datos de las Cohortes FEC_SEME_FIN_PLAN Fecha/Hora Fecha de inicio del semestre con que finaliza el plan de la carrera

Descripción de los Cursos Inscritos por los alumnos RUT_ALUM Número Rut del Alumno CURSO_CODIGO Número Código del curso que inscribió el alumno RAMO_NOMBRE Texto Nombre del ramo (asignatura) OPORTUNIDAD Número Oportunidad de la asignatura al momento de inscribirla NOTA_FINAL Número Nota final del alumno en el curso EST_INSCR Texto Estado del alumno al inscribir el curso EST_FIN Texto Estado del alumno al terminar el curso RAMO_ESCUELA Texto Sigla descriptiva única del ramo COD_RAMO Número Código de la asignatura o ramo SEME_INSCR Número Semestre en que se inscribe el alumno en el curso PLAN Número Código del Plan de la carrera SEME_INI Número Semestre de inicio de la carrera del alumno MATRICULA Número Número de matrícula del alumno

Salida: La salida o respuesta entregada por la solución Data Mining, es un árbol de decisión con sus distintas ramas y porcentajes asociados. Opcionalmente: No se descarta otra posible entrega tales como, gráficos que describan el requisito; esto dependerá de los distintos modelos con los que se interactúe.

xviii

REQ. 03 Verificar Causas Eliminación Ciclo Básico Objetivo: Validar si la eliminación del ciclo básico, se debe a las asignaturas de

ciencias básicas. Descripción: Se describe en la siguiente tabla el Requisito N° 03 (Caso de uso

identificado):

Caso de Uso

Verificar Causas Eliminación Ciclo Básico Autor: Carlos Díaz, Luis Salinas ID: RQ 03 Tipo: DM Fecha de Creación: 17/08/08 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite verificar si tardanza en la titulación se debe a las asignaturas de ciencias básicas.

Actor Primario Jefe de Gestión Académica Actor Secundario Supuestos Se cuentan con todos los datos necesarios para realizar la Verificación. Recursos • Datos de una determinada cohorte

• Datos de Académicos Pasos 6. El actor Jefe de Gestión Académica suministra todos los datos de una cohorte

y académicos. 7. Se definen cuales son los datos que se precisan para realizar la verificación

del perfil. 8. Se efectúa la preparación de los datos. 9. Se determinan los modelos necesarios para realizar el estudio (Verificación,

Relación). 10. Se procede a desplegar los resultados



Aspectos pendientes

Entrada: Como entradas al diseño de los Modelos en Data Mining se consideran

las siguientes Tablas: Cohortes y Cursos_Inscritos. Descripción de los datos de las Cohortes CARRERA Número Código Carrera PLAN Número Código del plan de la carrera F_ACTUALIZACION Fecha/Hora Fecha de actualización del registro MATRICULA Número Número de matrícula del alumno en la carrera RUT_ALUM Número Rut del alumno V_PLAN_ALUM Número Vigencia del alumno en la carrera-plan EST_ALUM Texto Estado del alumno en la carrera SEME_FIN_CARR Número Semestre de fin de la carrera FEC_SEME_FIN_CARR Fecha/Hora Fecha de inicio del semestre con que finaliza la carrera

xix

Descripción de los datos de las Cohortes SEME_INI_PLAN Número Semestre de inicio del alumno en el plan de la carrera FEC_SEME_INI_PLAN Fecha/Hora Fecha de inicio del semestre con que inicia el plan de la carrera SEME_FIN_PLAN Número Semestre de término del alumno en el plan de la carrera FEC_SEME_FIN_PLAN Fecha/Hora Fecha de inicio del semestre con que finaliza el plan de la carrera

Descripción de los Cursos Inscritos por los alumnos RUT_ALUM Número Rut del Alumno CURSO_CODIGO Número Código del curso que inscribió el alumno RAMO_NOMBRE Texto Nombre del ramo (asignatura) OPORTUNIDAD Número Oportunidad de la asignatura al momento de inscribirla NOTA_FINAL Número Nota final del alumno en el curso EST_INSCR Texto Estado del alumno al inscribir el curso EST_FIN Texto Estado del alumno al terminar el curso RAMO_ESCUELA Texto Sigla descriptiva única del ramo COD_RAMO Número Código de la asignatura o ramo SEME_INSCR Número Semestre en que se inscribe el alumno en el curso PLAN Número Código del Plan de la carrera SEME_INI Número Semestre de inicio de la carrera del alumno MATRICULA Número Número de matrícula del alumno


xx

REQ. 04 Ponderar Efecto Ciclo Básico y Ciclo Profesional Objetivo: Ponderar el efecto de la eliminación del ciclo básico y del ciclo profesional

en la titulación oportuna. Descripción: Se describe en la siguiente tabla, el Requisito N° 04 (Caso de uso

identificado):

Caso de Uso

Ponderar Efecto Ciclo Básico y Ciclo Profesional Autor: Carlos Díaz, Luis Salinas ID: RQ 04 Tipo: DM Fecha de Creación: 22/11/07 Fecha de Modificación:

Descripción Análisis de datos de una cohorte que permite Ponderar el efecto de la eliminación del ciclo básico y del ciclo profesional en la titulación oportuna.

Actor Primario Consultores Externos Actor Secundario Supuestos Se cuentan con todos los datos necesarios para realizar el estudio Recursos • Datos de una determinada cohorte

• Datos de Académicos Pasos 6. El actor Jefe de Gestión Académica suministra todos los datos de una cohorte y

académicos. 7. Se definen cuales son los datos que se precisan para ponderar el efecto de la

eliminación. 8. Se efectúa la preparación de los datos. 9. Se determinan los modelos que necesarios para realizar el estudio

(Verificación, Descubrimiento). 10. Se procede al despliegue de los resultados



Aspectos pendientes

Entrada: Como entradas al diseño de los Modelos en Data Mining se consideran

las siguientes Tablas: Cohortes y Cursos_Inscritos. Descripción de los datos de las Cohortes CARRERA Número Código Carrera PLAN Número Código del plan de la carrera F_ACTUALIZACION Fecha/Hora Fecha de actualización del registro MATRICULA Número Número de matrícula del alumno en la carrera RUT_ALUM Número Rut del alumno V_PLAN_ALUM Número Vigencia del alumno en la carrera-plan EST_ALUM Texto Estado del alumno en la carrera SEME_FIN_CARR Número Semestre de fin de la carrera FEC_SEME_FIN_CARR Fecha/Hora Fecha de inicio del semestre con que finaliza la carrera

xxi

Descripción de los datos de las Cohortes SEME_INI_PLAN Número Semestre de inicio del alumno en el plan de la carrera FEC_SEME_INI_PLAN Fecha/Hora Fecha de inicio del semestre con que inicia el plan de la carrera SEME_FIN_PLAN Número Semestre de término del alumno en el plan de la carrera FEC_SEME_FIN_PLAN Fecha/Hora Fecha de inicio del semestre con que finaliza el plan de la

carrera Descripción de los Cursos Inscritos por los alumnos RUT_ALUM Número Rut del Alumno CURSO_CODIGO Número Código del curso que inscribió el alumno RAMO_NOMBRE Texto Nombre del ramo (asignatura) OPORTUNIDAD Número Oportunidad de la asignatura al momento de inscribirla NOTA_FINAL Número Nota final del alumno en el curso EST_INSCR Texto Estado del alumno al inscribir el curso EST_FIN Texto Estado del alumno al terminar el curso RAMO_ESCUELA Texto Sigla descriptiva única del ramo COD_RAMO Número Código de la asignatura o ramo SEME_INSCR Número Semestre en que se inscribe el alumno en el curso PLAN Número Código del Plan de la carrera SEME_INI Número Semestre de inicio de la carrera del alumno MATRICULA Número Número de matrícula del alumno


xxiii

4. APÉNDICES

APÉNDICE A



Universidad Católica del Norte

Nombre del Proyecto




Equipo participante en la definición del alcance del proyecto


Carlos Díaz Mondaca Memoristas

Fecha de elaboración del documento 23/07/08 Descripción del proyecto La no continuidad de un alumno en la Universidad

Católica del Norte, puede ser por:

• Eliminación por la aplicación del Reglamento de Docencia. En la que un alumno incurre en causal de pérdida de la calidad de alumno y consecuentemente quedará eliminado de la Universidad si se encuentra en una o más de las situaciones académicas estipuladas en el Reglamento de Docencia. • Eliminación por causales. Cuando los

hechos realizados por el estudiante constituyen una falta para la UCN.

• Deserción. El alumno se retira voluntariamente de la UCN, ya sea por razones económicas, o no agrado a la Universidad o Carrera, entre otras varias causas.

Los temas anteriormente descritos, son los que se tomarán como base para el desarrollo del proyecto y del cual se tomarán los datos relevantes que muestren la manifestación de las distintas causales de eliminación.

Tecnología asociada Está en el marco de Business Intelligence, con herramientas tales como Data Mining con la metodología CRISP-DM y adicional una metodología que se está validando con este proyecto ER-DM. Para el modelado de los datos se utilizará la aplicación Clementine.

xxiv


Escenario actual Se conocen muchas hipótesis de porqué hay un bajo rendimiento académico, pero hasta el momento no se ha comprobado; por esto el hecho de corroborar estas hipótesis o descubrir nuevos patrones con un alto nivel de confianza, que permita la toma de medidas para solucionar y mejorar el rendimiento académico de alumnos de Pre-grado.


Posicionar a la Universidad Católica del Norte en un nivel superior en comparación con otras universidades, mejorando el fondo entregado por el Ministerio de Educación con respecto al arancel de referencia.

Restricciones Como alcance del proyecto se realizará la identificación y análisis de las variables que afectan la tasa de titulación y el tiempo de duración de una sola carrera: esta carrera es Ingeniería Civil Industrial. La razón de esta carrera, es simplemente por su ingreso directo que tiene en la institución. No se analizarán variables que afecten a los alumnos eliminados por razones económicas.

Riesgos La selección de los datos, si se escogen de mala manera, los resultados obtenidos no pueden ser los deseados. La no disponibilidad de los datos. No disponibilidad de personal que haya estado involucrado en proyectos de Data Mining.

Objetivos no considerados Crear un DataWarehouse o una Base de Datos centralizada con la información integrada de docencia (Pre-grado, Post-grado, Educación Continua y Educación a distancia).


Se analizará la propuesta de cambio para ver si es válida, utilizando análisis del cambio y el costo de éste; si es viable se implementará el cambio. [Somerville, 2005].

xxv

ÁPENDICE B




Nombre del Proyecto







Fecha de elaboración del documento 23/07/08


Unidad de Negocio Usuarios

Vicerrectoria Académica de la UCN

Dirección General de Docencia de la UCN

Memorista del Dpto. de Ingeniería de Sistemas y Computación.

Dpto. de Ingeniería de Sistemas y Computación.

Orlando Castro C.

Patrocinador

Santiago Sánchez Experto en el dominio de negocio

Carlos Diaz Luis Salinas

Desarrolladores

José Gallardo Claudio Meneses Profesores guías


Requisitos organizacionales generales

Identificar y analizar las variables que afectan la Tasa de Titulación y Tiempo de Duración de la Carrera de Ingeniería Civil Industrial. Para ello se analizará el Avance Curricular que se observa en las respectivas cohortes, con el fin de poder intervenir “oportunamente” y mejorar las Tasas y Tiempos de Titulación.

xxvi


Requisitos organizacionales específicos

1. Confirmar si el perfil de los estudiantes

influye directamente en el desempeño académico (Puntaje PSU, NEM, Tipo de Colegio, Quintil, entre otros).

2. Identificar patrones de comportamiento o

tendencias de ciertas asignaturas. 3. Validar si la eliminación del ciclo básico

se debe a las asignaturas de ciencias básicas.

4. Ponderar el efecto de la eliminación del

ciclo básico y del ciclo profesional en la titulación oportuna.

Información adicional

02 de julio del 2008 Reunión. Participantes: Orlando Castro, Carlos Díaz, Luis Salinas. Objetivo: Explicación de la segunda fase de la metodología ER-DM. 04 de julio del 2008 Reunión. Participantes: Orlando Castro, Santiago Sánchez, Carlos Díaz, Luis Salinas, José Gallardo y Claudio Meneses. Objetivo: Definición de requisitos organizacionales, objetivo estratégico al que apoya, definición de participantes en el proyecto. 15 de julio del 2008 Reunión. Participantes: José gallardo, Claudio Meneses, Carlos Díaz, Luis Salinas Objetivo: Discusión sobre la problemática del proyecto y cómo abordar esta misma, mediante aporte de ideas y posibles soluciones a los requisitos.

xxvii

APÉNDICE C


Nombre de la Organización Universidad Católica del Norte

Nombre del Proyecto




Equipo participante definición Glosario de Términos del proyecto



Fecha de elaboración del documento 23/07/08 Terminología de Carácter general


Cohorte Grupo de alumnos que inician sus estudios en un programa educativo al mismo tiempo. 1



Estructura curricular

Conjunto de normas y actividades cuyo objetivo es la formación integral del estudiante. La estructura incluye: Plan básico, Profesional, Formación General y de Titulación. 2

Actividades curriculares Aquellas que el alumno realiza dentro de un Plan de estudios. 2



Business Intelligence (BI) Inteligencia de Negocios. Término que ha surgido para definir el análisis de datos y la toma de decisiones dentro de las empresas. 3

Data Mining (DM)

Proceso de descubrir conocimiento interesante de grandes cantidades de datos almacenados en Bases de Datos, Almacenes de datos u otros repositorios de información. 4

Requisitos organizacionales

Objetivos, requisitos o problemas que tienen su origen o se derivan como consecuencia de las metas estratégicas establecidas en toda la organización y que son posibles de abordar mediante un sistema de Data Mining. 5

Referencias

1Universidad Católica del Norte, “Plan de Desarrollo Corporativo de la UCN, años 2004-2008”, Antofagasta, Chile, (2003). 2Reglamento de Docencia de Pre-Grado. 3Sivanandam S. N., Sumathi S, "Introduction to Data Mining and its Applications", Pág. 01-21, 185-195 Springer: Studies in Computational Intelligence, Volume 29 (2006). 4 Han Jiawei, Kamber Micheline, "Data Mining: Concepts and Techniques", 2ª Edición, Pág. 01-47, The Morgan Kaufmann Series in Data Management Systems (2006).4Reglamento de Docencia de Pre-

xxviii


Grado. 5Gallardo A. José, “Metodología ER-DM”, Tesis de Doctorado en Informática, Universidad Politécnica de Madrid, Antofagasta, Chile, (2008).

xxix

APÉNDICE D

Equipo participante en el proyecto



Nombre del Proyecto



23/07/08


Nombre Rol Responsabilidades

Orlando Castro Auditor General Patrocinador del proyecto.

Coordinar que los recursos organizacionales requeridos por los ejecutantes del proyecto, estén disponibles de acuerdo al plan de trabajo propuesto

Santiago Sánchez Jefe Dpto. Gestión Académica

Experto en el dominio de negocio

Tiene a su cargo la conducción del proceso de captura y validación de los requisitos de negocios, asesorando la decisión sobre qué datos deben ser utilizados en el proyecto

Carlos Díaz Luis Salinas Memoristas

Ejecutantes del proyecto. A cargo la responsabilidad de planificar y ejecutar el proyecto.

Facultad de Informáticaoa.upm.es/1946/1/JOSE_ALBERTO_GALLARDO_ARANCIBIA.pdfdel proyecto, clarificar...

Documents

Transcript of Facultad de Informáticaoa.upm.es/1946/1/JOSE_ALBERTO_GALLARDO_ARANCIBIA.pdfdel proyecto, clarificar...