Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la
Transcripción
Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la
HERRAMIENTA DE ESTUDIO DE VIABILIDAD PARA PROYECTOS QUE UTILIZAN LA METODOLOGÍA P3TQ TRABAJO PROFESIONAL EN INGENIERÍA EN INFORMÁTICA Laboratorio de Sistemas Inteligentes Facultad de Ingeniería Universidad de Buenos Aires Alumnos: Pablo Damián MENDEZ Alejandro Daniel RODRIGUEZ Directores: Prof. Dr. Ramón GARCIA-MARTINEZ Prof. Dra. Paola BRITOS Mayo 2009 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Índice Memoria del Trabajo Profesional.................................................................... 1 1. 2. Resumen ........................................................................................................................... 2 Introducción ..................................................................................................................... 2 2.1. 2.2. 2.3. 2.4. 3. La metodología SEMMA ................................................................................................................ 3 La metodología CRISP-DM ............................................................................................................ 4 La metodología P3TQ...................................................................................................................... 5 Comparación de las metodologías P3TQ, SEMMA y Crisp-DM................................................... 7 Estudio de viabilidad....................................................................................................... 9 3.1. El método ........................................................................................................................................ 9 3.2. Viabilidad en P3TQ ....................................................................................................................... 11 Modelo para predecir:............................................................................................................................... 17 4. 5. 6. Conclusiones .................................................................................................................. 22 Futuras mejoras.............................................................................................................. 23 Bibliografía ..................................................................................................................... 23 Anexo 1. Documento de Desarrollo de la Herramienta DAMVE ............. 24 1. 2. Objetivo .......................................................................................................................... 25 Funcionalidad del Sistema ............................................................................................ 26 2.1. 2.2. 3. Cambios en la versión ................................................................................................... 27 3.1. 3.2. 3.3. 3.4. 4. La arquitectura Appengine .......................................................................................................... 58 Diseño de la aplicación.................................................................................................. 60 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7. 8. Diagrama de Casos de Uso........................................................................................................... 44 Matriz de trazabilidad Casos de Uso – Requerimientos Funcionales ........................................ 45 Realización de los Casos de Uso .................................................................................................. 46 Arquitectura del Sistema............................................................................................... 58 6.1. 7. Formato ......................................................................................................................................... 27 Requerimientos funcionales ......................................................................................................... 28 Requerimientos no funcionales .................................................................................................... 36 Restricciones ................................................................................................................................. 43 Modelo de análisis ......................................................................................................... 44 5.1. 5.2. 5.3. 6. Versión 4 ....................................................................................................................................... 27 Versión 3 ....................................................................................................................................... 27 Versión 2 ....................................................................................................................................... 27 Versión 1 ....................................................................................................................................... 27 Especificación de Requerimientos ................................................................................ 27 4.1. 4.2. 4.3. 4.4. 5. Evaluación de proyectos............................................................................................................... 26 Gestión de usuarios ...................................................................................................................... 26 Diagrama de Paquetes de clases .................................................................................................. 60 dbmodel. La capa De dominio ..................................................................................................... 62 View. Paquete de soporte para vista............................................................................................ 67 Paquetes de Controladores.......................................................................................................... 68 Diagramas de Secuencia ............................................................................................................... 74 Secuencia entre Pantallas ............................................................................................................. 77 Diagrama de Despliegue .............................................................................................................. 82 Casos de Prueba ............................................................................................................. 84 8.1. 8.2. Validar Usuario............................................................................................................................. 84 Asignar evaluador ........................................................................................................................ 85 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10. 9. 10. Actualizar planilla de evaluación ................................................................................................ 87 Evaluar viabilidad ........................................................................................................................ 88 Crear evaluación ......................................................................................................................... 100 Consultar proyecto ..................................................................................................................... 101 Consultar Evaluación ................................................................................................................. 102 Crear Proyecto ............................................................................................................................ 103 Asignar colaborador ................................................................................................................... 104 Inicializar cuestionario ............................................................................................................... 106 Conclusión.................................................................................................................... 108 Posibles mejoras........................................................................................................... 109 Anexo 2. Manual de usuario la Herramienta DAMVE............................. 110 1. 2. 3. 4. 5. Introducción ................................................................................................................. 111 Requisitos ..................................................................................................................... 111 Acceso al sistema ......................................................................................................... 111 Presentación de la interfaz .......................................................................................... 112 Creación y Selección de Proyectos.............................................................................. 113 5.1. 5.2. 6. 7. Roles de los usuarios ................................................................................................... 114 Gestión de un Proyecto ............................................................................................... 115 7.1. 7.2. 7.3. 7.4. 7.5. 8. Abandonar y Retomar evaluaciones .......................................................................................... 119 Resultado de las evaluaciones .................................................................................... 119 9.1. 9.2. 9.3. 10. Agregar colaborador al proyecto ............................................................................................... 116 Eliminar un colaborador............................................................................................................. 117 Crear una nueva evaluación....................................................................................................... 117 Imprimir la gestión del proyecto ............................................................................................... 117 Exportar la gestión del proyecto ................................................................................................ 118 Ejecución de evaluaciones........................................................................................... 118 8.1. 9. Creación de un proyecto nuevo ................................................................................................. 113 Selección de un proyecto existente ............................................................................................ 114 Imprimir los resultados .............................................................................................................. 120 Exportar los resultados............................................................................................................... 121 Consultar resultados de evaluaciones realizadas...................................................................... 121 Opciones Avanzadas ................................................................................................... 121 10.1. 10.2. 10.3. 10.4. Designar evaluadores ................................................................................................................. 121 Eliminar un evaluador................................................................................................................ 122 Editar la plantilla de evaluación ................................................................................................ 122 Inicializar la Base de Datos ........................................................................................................ 123 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Memoria del Trabajo Profesional Memoria del Trabajo Profesional Pág. 1 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 1. Resumen Los actuales proyectos de explotación requieren el análisis y ejecución de etapas para ser llevados a cabo con éxito. Cada una de estas etapas insume tiempo y recursos, lo que hace sumamente importante estudiar la viabilidad del proyecto para evaluar si resulta posible y conveniente llevarlo a cabo y, además, controlar cada etapa de ejecución para detectar y corregir desvíos y, de esta manera, asegurar su éxito. El proyecto en cuestión se enfoca en una metodología para la realización de proyectos de explotación de la información (Data mining) y propone un test de viabilidad acorde a dicha metodología. 2. Introducción La Explotación de Información se centra en la búsqueda de patrones interesantes en grandes bases de datos. Utiliza tanto técnicas estadísticas (Análisis de varianza, Regresión, Prueba chicuadrado, Análisis de agrupamiento o clustering, Análisis discriminante, Series de tiempo, etc.) como informáticas (Algoritmos genéticos, Inteligencia Artificial, Sistemas Expertos, Redes neuronales, etc.) Entre muchos otros ejemplos, la Explotación de Información ha contribuido significativamente en: Las aplicaciones de administración empresarial basada en la relación con el cliente. Detectar patrones de fuga y fraudes. Analizar el comportamiento de las personas que interactúan en un sistema (por ejemplo Internet) Existen en el mercado actual tres importantes metodologías para llevar a cabo proyectos de explotación de la información, a saber: SEMMA CRISP-DM Memoria del Trabajo Profesional Pág. 2 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ P3TQ Sin importar la metodología usada, no existe hasta el día de hoy, ningún método de cálculo de viabilidad para proyectos de explotación de la información. En este trabajo, se estudia la metodología P3TQ en particular para especificar un método plausible para el cálculo de viabilidad de proyectos de las características mencionadas. 2.1. La metodología SEMMA La primer metodología fue propuesta por el SAS Institute, su nombre hace referencia a las cinco fases que se consideran al utilizarla (Sample, Explore, Modif., Model, Assess esto es Muestrear, Explorar, modificar, Modelar y Valorar respectivamente) [SAS Institute 1998]. La figura 2.1.1 muestra la dinámica del método SEMMA. Figura 2.1.1. Metodología SEMMA Memoria del Trabajo Profesional Pág. 3 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 2.2. La metodología CRISP-DM La metodología CRISP-DM analiza el proceso de explotación de la información en seis fases diferentes (Figura 2.2.1). Aunque en la ilustración se muestran las interacciones más comunes entre las fases se pueden establecer relaciones entre cualquiera de ellas [CRISP-DM 2000]. Figura 2.2.1. Fases de la Metodología CRISP-DM Memoria del Trabajo Profesional Pág. 4 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 2.3. La metodología P3TQ La metodología de D. Pyle se divide en dos etapas, la primera denominada Modelado de Negocio o MII, y la segunda llamada Minería de datos o MIII [Pyle, D. 2003]. Inicio MII Modelado del Negocio Metodología de Modelado (MII) MIII Preparación de los Datos (Boxes 9.x) MIII Minería sobre el modelo (Boxes 11.x) Metodología de Minería (MIII) MIII Refinamiento (Boxes 12.x) MIII Despliegue (Boxes 13.x) Fin Figura 2.3.1. Metodología de D.Pyle, Etapas del proyecto de explotación de información Para comenzar la primera etapa Pyle propone cinco posibles puntos de partida en función del propósito del proyecto de explotación de la información que se quiere evaluar. De esta manera Pyle considera: 1. Explorar los datos en búsqueda de relaciones útiles. 2. Dada una oportunidad o problema ver cómo puede la explotación de la información encausar a la organización hacia una decisión correcta. 3. Simplemente ver qué puede lograr la explotación de la información. Memoria del Trabajo Profesional Pág. 5 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4. Utilizar la minería de datos para construir un modelo sobre una situación particular 5. Dada una situación estratégica, analizar si la minería de datos puede ser útil para explicar la situación y cuáles son las opciones de la organización para resolverla. Figura 2.3.2. Metodología de P 3 TQ, Puntos de partida de un proyecto y objetos a considerar En la Figura 2.3.2 (parte central) se enumeran los parámetros concernientes a la organización y la situación del proyecto que la metodología de P3TQ considera, sin embargo estos son tratados de distinta manera según el punto de partida, para obtener finalmente los datos requeridos para el proyecto de explotación y los requerimientos reales de las partes interesadas. Memoria del Trabajo Profesional Pág. 6 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Finalizado el modelo de negocio el siguiente paso es la explotación de datos, para ello D. Pyle propone los pasos mostrados en la Figura 2.3.3. Cada parte de la metodología (tanto en MII como en MIII) está desagregada en pasos, estos pasos son denominados Preparación de los datos boxes, existiendo 3 tipos de ellos: Action Boxes, en donde se decide cuál es el Selección de la herramienta próximo paso a realizar. Discovery Boxes, en donde se analizan los posibles resultados y problemas luego de ejecutar un Action Box. Minería Technique Boxes, que describen minuciosamente cómo debe emplearse una técnica. Refinamiento Los boxes no se recorren secuencialmente, los saltos entre ellos dependen de las situaciones que se van dando a medida que se avanza en el proyecto. Despliegue Figura 2.3.3. Pasos distinguidos en la metodología P 3 TQ Los boxes explican detalladamente los conceptos y/o acciones que se realizan. El gráfico mostrado anteriormente permite identificar cuáles son los Boxes que corresponden a cada etapa de la metodología. Por ejemplo puede verse en la figura 2.3.1 que los Boxes 9.x corresponden a la etapa de preparación de los datos en la metodología de minería MIII. 2.4. Comparación de las metodologías P3TQ, SEMMA y Crisp-DM Luego de las investigaciones iniciales, hemos concluido que SEMMA se centra en los aspectos técnicos de los proyectos de explotación de datos. Además está acotada ya que ha sido diseñada para ser implementada con los productos SAS. Crisp-DM es más completa y abierta que SEMMA, pero no llega al detalle de la metodología P3TQ, ya que nombra etapas del proceso de la explotación de la información, pero no se analizan los pasos, resultados y situaciones que se pueden dar dentro de cada etapa. Memoria del Trabajo Profesional Pág. 7 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Concluimos que la metodología P3TQ es la más completa entre las tres mencionadas (Ver cuadro 2.4.1), y, por lo tanto en la que se centrará el presente trabajo. Dicha metodología analiza muchas más variables y más profundamente que las demás. Para citar un simple y claro ejemplo (considerando que nos encontramos sólo en la introducción de la presentación de un proyecto y no en su desarrollo) la metodología considera quiénes son los interesados en el proyecto en la organización, considerando hasta la causa de su interés (Pyle, D. Business Modeling and Data Mining, Technique Box 1: Identify Stakeholders). Permite elección totalmente libre de herramientas Cantidad de fases Todas las fases pueden relacionarse Considera motivo del proyecto Considera naturaleza del interés de las partes Considera otros aspectos no técnicos Identifica claramente las variables sobre las que el proyecto tiene impacto Está detallada paso a paso cada etapa del método SEMMA CRISPDM NO 5 NO NO NO NO SI 6 SI NO NO SI NO NO NO NO PYLE SI 5 (1 MII y 4 MIII) SI SI SI SI SI (Product, Place, Price, Time, Quantity) SI Cuadro 2.4.1. Cuadro comparativo de metodologías Memoria del Trabajo Profesional Pág. 8 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 3. Estudio de viabilidad Todo proyecto en el ámbito de cualquier rama de la ingeniería debe satisfacer la ecuación fundamental de costo y beneficio. Antes de comenzar con un proyecto, por lo tanto, tres puntos deben tenerse en cuenta: • El esfuerzo necesario para el desarrollo (Costo) • La utilidad que se obtendrá por realizar dicho desarrollo. • También a veces, por razones inherentes a la naturaleza de un proyecto surge una tercera cuestión que es si es realizable en función de las variables que lo definen. Estas tres cuestiones no sólo pueden indicar si se debe comenzar o no una inversión económica para obtener un resultado, sino que además, puede variar a medida que se va avanzando en la empresa y nuevos problemas van surgiendo. El estudio de viabilidad, considerando los puntos que D. Pyle menciona en la bibliografía, aproxima a un valor que nos da la respuesta sobre si es conveniente que un proyecto se ejecute, o siga ejecutándose. Estas características corresponden en mayor medida al segundo y tercer punto. En comparación a cualquier otro tipo de proyecto de naturaleza informática, toma mayor importancia realizar estudios de viabilidad cuando se trata de actividades de explotación de la información. La razón de esta afirmación, radica en que es común notar en el cliente un interés incierto, o más bien, mucho interés, pero sin conocer exactamente qué espera de un proyecto de explotación de la información. 3.1. El método La metodología mencionada en [García-Martínez, R. y Britos, P. (2004). Sistemas Expertos. Nueva Librería] clasifica tres tipos distintos de características que definen la viabilidad de un problema, a saber: • Booleanos • Numéricos en un intervalo finito • Lingüísticos (Conjunto que posee los valores “nada”, “poco”, “regular”, “mucho”, “todo”). Memoria del Trabajo Profesional Pág. 9 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Según los valores de cada característica del problema se estima si el proyecto es viable o no. Además cada característica estará ponderada por un “peso”, que hará que incida en mayor o menor medida en la dimensión de un problema. En casos de valores lingüísticos son convertidos en valores difusos correspondiente en el intervalo [0,10] como se muestra en la tabla 3.1.1. Nada 0 0 1,2 2,2 Poco 1,2 2,2 3,4 4,4 Regular 3,4 4,4 5,6 6,6 Mucho 5,6 6,6 7,8 8,8 Todo 7,8 8,8 10 10 Tabla 3.1.1 Conversión entre valores lingüísticos y valores difusos Para homogeneizar el problema, los valores booleanos también se tratan como lingüísticos considerando los valores de la tabla 3.1.2. No 0 0 0 0 Sí 10 10 10 10 Tabla 3.1.2 Conversión entre valores booleanos y valores difusos Las características se agruparán según su naturaleza y llamaremos a cada grupo “Dimensión”, existiendo cuatro dimensiones a saber: Plausibilidad, Éxito, Adecuación y Justificación. La dimensión “Plausibilidad” agrupará todas aquellas características que indican si el desarrollo del proyecto es posible, por ejemplo si existen expertos y están disponibles, si existen los casos de prueba adecuados, etc. El “éxito” es determinado por características del problema que generalmente se dan a posteriori del desarrollo, de todas maneras debemos identificar y evaluar estas características a priori, para ejemplificar podemos mencionar el interés o desinterés de un departamento clave de la organización, que no sea el sponsor pero si el usuario final (el proyecto sería desarrollado pero nunca utilizado o los usuarios serían reacios, esto sería un fracaso). La dimensión de “Justificación” contendrá cada característica que determine si vale la pena realizar el proyecto. Supongamos el caso que se dispone de suficientes expertos en la materia y no representan costo significativo para la empresa, en este caso seguramente no será justificado el desarrollo. Memoria del Trabajo Profesional Pág. 10 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ La dimensión de “adecuación”, evalúa si es apropiado resolver el problema mediante el sistema propuesto en este trabajo. Finalmente el cálculo del valor de cada dimensión se realiza de la siguiente manera. Dado L el vector de valor lingüístico de dimensión 4 (de acuerdo a las tablas 3.1.1 y 3.1.2), Li y Pi el valor difuso y el peso de la característica i respectivamente; la viabilidad de una dimensión j determinada del problema será determinada por la ecuación 3.1.1. Ecuación 3.1.1. Cálculo de viabilidad de una dimensión. Esta fórmula representa la viabilidad para una dimensión j dada. Luego de calcular para las 4 dimensiones (Adecuación, éxito, justificación y plausibilidad), se calcula la viabilidad total de un problema según la fórmula 3.1.2. Ecuación 3.1.2 Viabilidad total Pj es el peso de cada dimensión, siguiendo la bibliografía propuesta se define que será: Plausibilidad y adecuación 8 Justificación 3 Éxito 5 3.2. Viabilidad en P3TQ Todo proyecto de Explotación de la información, tiene como propósito el uso de herramientas sobre datos existentes para obtener relaciones interesantes a la hora de tomar decisiones o crear soluciones. Una característica de los trabajos de explotación de datos actuales, es que el punto de partida, o más bien el motivo de su realización, no sea un problema en particular a solucionar. Muchos interesados en aplicar explotación de la Memoria del Trabajo Profesional Pág. 11 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ información tienen como objetivo descubrir qué problemas se pueden solucionar con la información existente, pero no la solución de un problema en sí. Esta característica, incrementa la necesidad del estudio de viabilidad; ya que al comenzar con un rumbo incierto, es probable terminar en una solución no deseada luego de haber invertido tiempo de personal calificado y recursos económicos. Naturalmente no es apropiado este tipo de perspectiva para ningún tipo de proyectos, a pesar que la realidad en la práctica indique que muchos comienzan de esta manera porque el sponsor lo requiere. Como se describió en la sección 2.3, la metodología propuesta por D. Pyle, establece dos partes de un proyecto de minería de datos, el “Modelado de Negocio” y la “Metodología de Minería”. Por esta razón analizaremos la viabilidad tomando características de estas dos partes por separado. 3.2.1. Estudio de viabilidad en el modelado de negocio Tomando como punto de partida que nada puede ofrecer un proyecto de explotación de datos hasta que el problema a resolver sea identificado, esto debe lograrse de alguna manera, aunque el cliente no lo haya especificado. Pyle reconoce, por lo tanto, los siguientes puntos de partida de un proyecto según su objetivo: Explorar los datos y descubrir relaciones interesantes que ofrezcan valor agregado al negocio. Un problema u oportunidad de negocio en particular a ser explorado. Descubrir en qué partes de la organización puede ser interesante aplicar métodos de explotación de la información. Crear un modelo para un propósito especificado. Planificar escenarios corporativos. Según el punto de partida inicial, D. Pyle establece cuáles son los siguientes pasos a seguir. Por ejemplo el caso más general, con escasa información sobre el negocio, sólo llega el conjunto de datos sobre el cual se debe aplicar minería para descubrir relaciones que puedan llegar a ser de interés. En este punto, Pyle, establece Memoria del Trabajo Profesional Pág. 12 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ específicamente el aso más lógico a seguir: reconocer a los interesados según cinco categorías: 1. Los que necesitan la realización del proyecto. 2. Los que poseen los recursos económicos. 3. Los que poseen poder de decisión para que el proyecto avance. 4. Los que se benefician con el resultado. Luego se procedería con una entrevista a los interesados, en donde se debe entender cuál es la parte relevante de negocio que, justamente, les interesa y discutir con ellos para identificar cuál es el proyecto original que alimenta la necesidad de un proyecto de minería. Siguiendo este ejemplo, es nuestro estudio de viabilidad, analiza si: Las partes interesadas están identificadas. Las partes interesadas tienen disponibilidad de tiempo para avocarse al proyecto. Existen partes interesadas con recursos suficientes. Las características importantes para las partes interesadas están identificadas. La parte clave de estos pasos es descubrir y caracterizar cuál, cómo y cuánto de los componentes P3TQ (Product, Price, Place, Time, Quantity) son afectados por el proyecto, qué hay que cambiar para ver la oportunidad o resolver el problema de trasfondo. Las cinco variables de negocio que dan nombre a esta metodología, interactúan mutuamente (figura 3.2.1.1). Por ejemplo, el éxito del lanzamiento de un producto depende, obviamente del cliente, pero las características de ellos, dependen del tiempo y el lugar. Figura 3.2.1.1 Variables P 3 TQ Estas relaciones deben ser reveladas en los datos con las herramientas usadas para la minería de datos. Memoria del Trabajo Profesional Pág. 13 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ El siguiente paso tiene que ver con los interesados, es notar quién o qué departamento originó el proyecto original y qué esperan a cambio. Hasta aquí, se ha analizado sólo un punto de partida de modelado de negocio identificado por D. Pyle, notemos cuáles son las situaciones que se tienen luego de analizar esta pequeña fracción de la metodología: El problema de negocio de trasfondo descubierto no está totalmente dirigido. El proyecto original perdió el apoyo de uno o algunos de los interesados. EL proyecto original falló en entregar los resultados esperados. Los datos fueron recolectados para dirigir una situación específica, pero el objetivo de la minería sería descubrir si hay algún valor corporativo que se pueda obtener de ellos. Según la situación, el nivel de riesgo es distinto. Además, Pyle especifica una acción para resolver el problema en cada una de estos escenarios. Es objetivo de este trabajo también, analizar estas acciones, descubrir acciones implícitas, y determinar el riesgo de realizarlas. El software de Análisis de viabilidad, ubica al usuario en la situación de la metodología de explotación de datos propuesta por D. Pyle realizando ciertas preguntas. Adaptando la metodología de D. Pyle al método de cálculo de viabilidad (sección 3.1), se identifica primero a qué dimensión pertenece cada una y se le asigna un peso, determinando en conjunto la viabilidad del proyecto. En la tabla 3.2.1.1, se muestran los ítems que establecen los puntos de riesgo para el modelado de negocio. El software de cálculo de viabilidad es extendible en este sentido, los puntos mostrados en la tabla son los correspondientes a la versión 1.0 del software. La primer columna indica la dimensión de viabilidad a la cuál apunta la pregunta (P: Plausibilidad; A: Adecuación; E: Éxito; J: justificación). La segunda columna indica el “Pyle Box” (ver sección 2.3) fuente de la pregunta, que es la “caja” que enumera de alguna manera el factor de riesgo que se identificó para generar la pregunta en cuestión. 3.2.2. Estudio de viabilidad en la metodología de minería de datos El desarrollo de modelos aptos para la minería requiere análisis, interpretación y cambios sobre los datos de manera cíclica. Las acciones a tomar dependen enteramente del problema de negocio y de lo que el experto en minería descubre en ellos. Memoria del Trabajo Profesional Pág. 14 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Por esta razón debe ser posible realizar tests de viabilidad no sólo antes de comenzar la minería, sino también a lo largo del desarrollo del proyecto. La metodología P3TQ, comienza el proceso de minería con la preparación de los datos. Se debe tener en cuenta que el esfuerzo del experto es enfocado en mayor medida a esta tarea. Es de esperar que la relación sea entre el 60 y 90% del esfuerzo total avocado a la minería. Esto, apunta a que el test de viabilidad para la minería de datos esté enfocado en gran parte hacia el estado de los conjuntos de variables y, por ejemplo, si no existen errores, si dichas variables y sus valores son congruentes con el modelo de negocio o si son suficientes, además si poseen muchos valores indefinidos, etc. Las cuestiones mencionadas se reflejan en las preguntas que el sistema de cálculo de viabilidad muestra al usuario (tabla 3.2.2.1). Pyle establece los pasos a seguir para la preparación de los datos en los boxes 9.x. El siguiente punto más relevante, luego de la preparación de los datos, es la minería en sí, refiriéndonos a los algoritmos utilizados, los conjuntos de variables de entrada y salida, etc. Estos casos son apuntados por los boxes 11.x. El test de viabilidad en la minería propuesto en este trabajo tiene una bifurcación según los tres tipos de proyectos de explotación que Pyle identifica: Minería para entender. Minería para clasificar. Minería para predecir. Minería para entender: Cuando la cuestión que motiva el proyecto es entender el por qué de una situación del negocio en particular, el set de datos limita la respuesta que el encargado de la explotación de la información puede otorgar. Si es posible, la transformación de variables es normalmente de gran ayuda para la comprensión de los resultados y puede hacer más rico un modelo. Tomemos como ejemplo de transformación, establecimientos de una empresa dedicada a la logística georeferenciados, o sea, puntos en particular con latitud y longitud establecida. Es probable que dada la situación a entender, no sea de relevancia conocer estos parámetros, pero sí la distancia a un punto en particular de cada establecimiento. Naturalmente el minero debería encargarse de transformar las variables de latitud y longitud a una variable con el valor de la distancia. Con este sencillo ejemplo, se intenta demostrar algunos de los puntos que determinan el riesgo previamente a comenzar a realizar la tarea de minería. Ya Memoria del Trabajo Profesional Pág. 15 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ que, conociendo la cuestión que se debe explicar, el encargado de la explotación de la información debe analizar previamente: ¿Pueden transformarse los datos de manera que sean importantes para entender la situación, y útiles para explicar el resultado?, ¿pueden las herramientas elegidas, transformar los datos de manera conveniente?. Además de los puntos relativos a las variables en sí, la explicación de la situación (el resultado final del proyecto), contendrá tanto implícita o explícitamente las relaciones entre variables que conforman la parte del modelo concerniente a la situación particular analizada. ¿Estas relaciones son coherentes?, ¿existen variables, donde comúnmente se espera un par relacionado, sin estar relacionadas?, estas cuestiones también hacen que el riesgo del proyecto aumente o disminuya, son consideradas por este trabajo. Otras cuestiones que influyen directamente en el riesgo de la minería son mucho más triviales, por ejemplo, si están elegidas las herramientas y algoritmos para la minería, si se cuenta con un proveedor de dichas herramientas, la capacidad de respuesta en caso necesitar modificaciones. Minería para clasificar: Según D. Pyle, la clasificación es un caso especial de lo que comúnmente se denomina predicción, debido a que se intenta predecir a qué clase una instancia de dato pertenece en función a ciertos atributos. Se discute el término “predicción” en el siguiente punto (“Minería para predecir”). Por ejemplo, un modelo para clasificar muy común y utilizado muy a menudo pedagógicamente es aquel que en función de ciertos atributos de una persona, ésta accedería a un crédito otorgado por un banco o no. Estos atributos pueden ser sexo, edad, nivel de estudio, estado civil, región donde vive, etc. El modelo de clasificación producirá algún tipo de puntuación en función de esos atributos que determine si la persona accede o no al crédito. Sin embargo, ocurre en ciertos casos que la puntuación producida por la herramienta de minería no es fácil de interpretar. Supongamos que para el caso en cuestión el modelo establezca un resultado booleano de tipo 0= No accede al crédito, 1 = Accede al crédito. Es probable que luego de la minería, la herramienta utilizada calcule un valor entre 1 y 0. Estos casos requieren que el responsable de la explotación haga una interpretación y que tenga los medios necesarios para ello. Otra cuestión, es que se necesitan varios conjuntos de datos para aplicar la herramienta. Esto se debe a que si se usa un solo conjunto, el modelo interpretará Memoria del Trabajo Profesional Pág. 16 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ que las proporciones de cada clase son universales. Siguiendo el ejemplo, si se otorga un conjunto donde un 30% acceden al crédito y un 70% no, el modelo interpretará que un 30% de los casos acceden al crédito universalmente. Las cuestiones de los párrafos anteriores, influyen directamente en la viabilidad de un proyecto de minería para clasificar ya que, deben ser elegidas cuidadosamente las herramientas, saber si se podrán interpretar los datos, o estarán disponibles aquellas personas que puedan interpretarlos. Obviamente, con respecto a las proporciones de las clases, la viabilidad estará influida por la cantidad de conjuntos de datos que se puedan generar. P3TQ especifica minuciosamente los pasos a seguir para la minería de clasificación, en cada uno de ellos se pueden reconocer factores de riesgo que hemos incluido en el desarrollo de este trabajo y se reflejan en la herramienta final. Modelo para predecir: Quizás el más difícil de los tres objetivos que puede tener un proyecto de minería es la predicción. Un modelo para predecir debe ser capaz de arrojar información que no está presente en el set de datos que toma como entrada. Estos resultados salen de la elaboración de los datos junto con el conocimiento del negocio, por lo tanto, el modelo debe ser lo suficientemente rico, y se debe poseer expertos en el caso de negocio que puedan interpretar causas y efectos, con la dinámica de relaciones que interconectan los objetos representados en los datos. Los datos disponibles no contienen un patrón que describa cómo se comportará el sistema de las circunstancias de interés ya que la combinación única de estas circunstancias no ha sucedido aún. Y en esta incertidumbre de comportamiento subyace el trabajo que se le encomendó al encargado de la explotación de la información. Ya que no existen herramientas de minería para este propósito, el éxito dependerá en gran parte en la habilidad del experto para seleccionar herramientas existentes y su habilidad para relacionar los resultados que vaya encontrando entre las distintas situaciones del negocio, para lo cual necesitará la ayuda y disponibilidad de expertos interesados en el proyecto. 3.2.3. El cuestionario de evaluación Cada paso de la metodología posee acciones u objetos plausibles de riesgo. Un experto puede generar riesgo por su ausencia, un conjunto de datos puede generar riesgo por poseer demasiados valores nulos, etc. Memoria del Trabajo Profesional Pág. 17 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Presentado ya el método de cálculo de viabilidad, la metodología sobre la cual se apoyan los proyectos de explotación de la información que consideramos, analizaremos a continuación cómo se presenta la metodología propuesta al usuario final. El interesado en determinar el riesgo de un proyecto deberá ir contestando un cuestionario donde se presentan los posibles escenarios de riesgo para cada paso de la metodología P3TQ. Como P3TQ no es secuencial, no serán tampoco las preguntas presentadas. Según lo que el usuario responda se le mostrarán un conjunto de preguntas u otro. Las preguntas de la tabla 3.2.3.1 están divididas en aquellas que corresponden a la etapa de modelado (Id de la 1 a la 27), las que corresponden a la etapa de minería (27 a 49) y las que manejan la secuencia de la metodología P3TQ (50 a 57). Notar que todas excepto las del tercer grupo tienen un peso asignado y su dimensión correspondiente en la tabla (P: plausibilidad, A: adaptabilidad, J: justificación y E: éxito). El peso es la ponderación que tendrán en su dimensión en el cálculo de viabilidad. Las preguntas 50 a 57 tienen peso cero, ya que no evalúan el proyecto, sino que identifican una situación particular y en función de sus respuestas se mostrará una secuencia de preguntas o no. Id pregunta Descripción Las partes interesadas están identificadas? Las partes interesadas son aquellas personas o grupos de 1 personas que afectan o pueden ser afectadas por el proyecto.Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de 2 referencia de la metodología P3TQ: DB1, AB2, AB3 Peso Dimensión 8 P 8 P 3 Existen partes interesadas con autoridad suficiente dentro de la organización para liderar el proyecto de explotación? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 6 E 4 Existen partes interesadas con recursos económicos suficientes para encarar el proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 6 P 50 El proyecto de explotación tiene como propósito buscar relaciones de interés? El proyecto original cuenta con el apoyo de la organización? Boxes de referencia de la metodología P3TQ: 5 DB1, AB2, AB3 El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodología 6 3 P TQ: DB1, AB2, AB3 Existe comunicación con las partes interesadas del proyecto original? El proyecto original es aquel que 7 origina el proyecto de explotación que se está evaluando.Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 8 Se cumplieron los objetivos del proyecto original? El proyecto de explotación tiene como propósito la evaluación de una situación de negocio? (análisis de 51 problema u oportunidad)? Con respecto a la problemática del negocio del proyecto original: Se han encontrado datos de utilidad para 9 llevar a cabo la minería? El proyecto original es aquel que origina el proyecto de explotación que se está evaluando.Boxes de referencia de la metodología P3TQ: AB6 Las partes interesadas han identificado o pueden identificar aquellas características del negocio 10 importantes, que enmarcan sus expectativas del proyecto de explotación? Boxes de referencia de la metodología P3TQ: TB7 Memoria del Trabajo Profesional 0 M 10 E 8 P 6 P 8 P 0 M 5 P 5 A Pág. 18 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Id pregunta 11 12 52 13 14 15 Descripción Peso Dimensión La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodología P3TQ: AB6 Los Objetivos y Metas del negocio están definidos o pueden definirse? Boxes de referencia de la metodología P3TQ: AB6, TB5 El proyecto de explotación tiene como propósito descubrir en que partes de la organización se puede agregar valor? Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB11, TB3 Es conocida la relación entre las cinco temáticas claves del negocio (producto, lugar, precio, tiempo y cantidad) y el proceso principal de la organización? Boxes de referencia de la metodología P3TQ: AB11 Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P3TQ: AB11, MII Tabla 7.1 16 Existen datos disponibles para explotación? Boxes de referencia de la metodología P3TQ: AB11 17 Esta desarrollado, o es posible desarrollar un esquema de caso de negocio para cada oportunidad significativa? Boxes de referencia de la metodología P3TQ: AB11 53 Hay otro propósito especifico? 6 J 8 J 0 M 10 E 5 A 5 A 10 E 10 P 0 M Los requerimientos fueron consensuados con las partes interesadas? Boxes de referencia de la metodología P3TQ: AB9 La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos 19 conocidos? Boxes de referencia de la metodología P3TQ: AB9 18 20 Existe información disponible para la explotación? Boxes de referencia de la metodología P3TQ: AB9 54 Se requiere inicialmente un análisis estratégico para planificar escenarios corporativos? 10 E 6 J 10 E 0 M 21 La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodología P3TQ: AB9 2 A 22 Existe un mapa del escenario estratégico, consensuado con las partes interesadas. .Boxes de referencia de la metodología P3TQ: AB12 6 A 23 24 25 26 27 Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB12 Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la metodología P3TQ: AB12 Existen o pueden realizarse simulaciones que permitan identificar ambigüedades, incertezas, discordancias? Boxes de referencia de la metodología P3TQ: AB12 Están caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la metodología P3TQ: AB12 Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P3TQ: AB12, MII Tabla 7.1 28 Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodología P3TQ: DB9.1 El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la 29 metodología P3TQ: DB9.1 Existen variables con único valor, o valores vacios en sus instancias? Boxes de referencia de la metodología 30 3 P TQ: DB9.2 3 31 Las variables categóricas están documentadas? Boxes de referencia de la metodología P TQ: DB9.2 32 33 34 35 Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodología P3TQ: DB9.3 Son reconocidas y es posible adecuar variables anacrónicas? Boxes de referencia de la metodología P3TQ: DB9.4 Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre distintos) y generar un set de entrenamiento y otro de testeo? Boxes de referencia de la metodología P3TQ: DB9.5, TB9.4 Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios más importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodología P3TQ: DB9.6 Es necesario realizar recodificación de variables para mejor comprensión del modelo? Boxes de referencia de la metodología P3TQ: DB9.7 Los conjuntos de variables de entrada y salida están caracterizadas? Boxes de referencia de la metodología 37 3 P TQ: AB11.1 36 Memoria del Trabajo Profesional 8 A 8 A 8 A 8 E 4 A 8 P 8 P -4 P 3 A 4 A 4 A 8 E 10 E -4 A 6 A Pág. 19 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Id pregunta 38 39 40 41 42 Descripción Los datos están estructurados o pueden estructurarse para aplicarlos en la herramienta de minería elegida? Boxes de referencia de la metodología P3TQ: AB11.1 Están seleccionados los algoritmos de minería adecuados al modelo? Boxes de referencia de la metodología P3TQ: AB11.3 Existe una herramienta de minería adecuada al modelo y esta disponible? Boxes de referencia de la metodología P3TQ: AB11.6 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodología P3TQ: AB11.5 Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodología P3TQ: AB11.1 Peso Dimensión 6 A 8 A 8 A 8 P 5 P 55 El objetivo de la explotación es entender una situación? 0 M Las variables utilizadas en el modelo están relacionadas con conceptos que son conocidos por las partes 43 interesadas? Boxes de referencia de la metodología P3TQ: AB11.1, DB11.5 8 E Los objetos del negocio que representan las variables pueden ser utilizados por las partes interesadas, o gerentes para realizar mejoras en el negocio. .Boxes de referencia de la metodología P3TQ: AB11.1, DB11,5 Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodología 45 3 P TQ: AB11.1 DB11.5 44 8 E 6 E 56 El objetivo de la explotación es aplicar una clasificación? 0 M Esta determinado o puede determinarse en la herramienta el tipo de modelo de clasificación inicial (B: 46 Binario; M : Clases Múltiples o C : Continuo)? Boxes de referencia de la metodología P3TQ: DB11.6 6 E La herramienta elegida soporta el tipo de entrada y el tipo de salida del modelo inicial de clasificación? Boxes de referencia de la metodología P3TQ: DB11.6 8 E 47 57 El objetivo de la explotación es buscar una predicción? Las herramientas de modelado del sistema están seleccionadas? Boxes de referencia de la metodología 48 3 P TQ: TB11.7 Es posible caracterizar las relaciones esenciales entre los conceptos del negocio en las herramientas de 49 predicción? Boxes de referencia de la metodología P3TQ: DB11.7 0 M 5 E 6 E Tabla 3.2.3.1 Cuestionario de viabilidad Memoria del Trabajo Profesional Pág. 20 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ La figura 3.2.3.1 muestra un grafo que muestra los posibles caminos a seguir en el cuestionario. Figura 3.2.3.1 Secuencia del cuestionario de viabilidad Memoria del Trabajo Profesional Pág. 21 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4. Conclusiones La metodología P3TQ es muy rica y tiene como principal ventaja detallar cada paso en función de los objetivos del proyecto y el estado de cada atributo que lo define. Esto nos ha permitido, reconocer en cada paso aquellas cuestiones que hace riesgoso o fácilmente viable a un proyecto de explotación de la información. Al mismo tiempo reconocemos los distintos tipos dificultades que pueden acarrear un proyecto de explotación de la información. Estas dificultades pueden ser de distinta naturaleza. Se pueden mencionar dificultades de origen técnico, como la disponibilidad de datos suficientes, la existencia de herramientas adecuadas para el tipo de proyecto que se quiere llevar a cabo, etc. Pero también hay dificultades de otra naturaleza, que no son tan triviales e influyen con gran impacto en el éxito de un proyecto; identificar los interesados, sus expectativas, detectar si conocen con precisión las variables del negocio y la relación entre ellas, su impacto en los resultados. Todas estas cuestiones deben ser convenientemente analizadas antes de comenzar a utilizar recursos en explotación de información; para conocer la situación de partida del proyecto y qué se pretende como resultado, la importancia de las personas en la organización que quieren ese resultado, cómo se va a presentar dicha información, etc. Como agregado, no existe hasta el momento un metodología para calcular la viabilidad de proyectos de este tipo, creamos en este trabajo una metodología con dicho propósito basándonos en el cálculo de viabilidad propuesto por [Liebowitz 1986; Laufman et al, 1990; Adelman, 1989; 1992; De Antonio y Samper, 1990; Beckam, 1991; López et al 1991]. Además se desarrollamos una herramienta de arquitectura web que permite estudiar la viabilidad de proyectos de explotación de información desarrollados bajo la metodología P3TQ a lo largo de todo su ciclo. Dicha herramienta está desarrollada con Goolgle App Engine, un nuevo concepto de programación web basado en el lenguaje python, y funcionando enteramente (código y persistencia) en los servidores de Google. Se adjunta el manual de usuario y documentación de desarrollo de la herramienta junto a este documento. Memoria del Trabajo Profesional Pág. 22 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 5. Futuras mejoras Si bien la herramienta desarrollada es muy completa, incluyendo seguimiento de proyectos, generación de distintas evaluaciones para cada trabajo y manejo de usuarios, además de la funcionalidad básica; el método propuesto es extensible, pueden reconocerse nuevos puntos de riesgo siguiendo minuciosamente los pasos que D. Pyle describe en la metodología P3TQ y agregarse a la metodología. El agregado de nuevos puntos de riesgo no requiere de recodificación de la herramienta, pero sí un agregado cuidadoso en su base de datos, ya que la metodología P3TQ cumple una secuencia que es respetada en este trabajo. 6. Bibliografía Pyle, D. (2003). Business Modeling and Data Mining. Morgan Kaufmann Publishers. García-Martínez, R. ; Britos, P. (2004). Sistemas Expertos. Nueva Librería. Chapman, P. ; Clinton, J. (2000). CRISP-DM 1.0: Step by Step Data mining Guide. The CRISP-DM consortium; 2000 Martelli, A. (2008). Python, Guía de referencia. Anaya Multimedia. Martelli, A. (2006). Python in a Nutshell. O'Reilly. Pérez López, C.; Santin González, D. (2006). Data Mining, Soluciones con Enterprise Miner. Alfaomega Grupo Editor. Colomes Fornos, X. (2009); Css Dhtml y Ajax Guía Práctica. Anaya Multimedia. Ochoa, A (2006). Uso de Técnicas de educción para el entendimiento del negocio; Tesis de Magíster en Ingeniería de Software. Instituto Tecnológico de Buenos Aires. Google (2008). Guía de Introducción de Google AppEngine. Disponible en: http://code.google.com/intl/es-ES/appengine/docs/python/gettingstarted/ Memoria del Trabajo Profesional Pág. 23 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Anexo 1. Documento de Desarrollo de la Herramienta DAMVE Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 24 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 1. Objetivo El presente documento tiene como objetivo documentar la herramienta software DAMVE, que permite ingresar las características de un proyecto que utiliza la metodología P3TQ, con el objetivo de analizar y evaluar su viabilidad. El documento presenta información detallada de cada una de las etapas en el desarrollo de la herramienta, utilizando siempre que sea posible, el estándar UML de modelado de software: Requerimientos funcionales, requerimientos no funcionales y restricciones Modelo de análisis (casos de uso) Arquitectura Modelo de diseño Casos de Prueba El modelo de negocio que debe implementar la herramienta se encuentra documentado en la Memoria Del Trabajo Profesional, donde se describe la técnica de estudio de viabilidad aplicada a la metodología P3TQ. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 25 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 2. Funcionalidad del Sistema El sistema debe proveer la siguiente funcionalidad: 2.1. Evaluación de proyectos Creación de proyectos que utilizarán o utilizan la metodología P3TQ. Creación de evaluaciones asociadas a un proyecto, que permitan evaluar su viabilidad a lo largo del tiempo (desde la etapa de concepción y durante su ejecución). Todas las evaluaciones estarán basadas en una plantilla común de estudio de viabilidad. Las evaluaciones pueden ser completadas por un usuario en una o varias sesiones. En el primer caso debe presentarse el resultado de la evaluación. En el segundo caso la evaluación debe presentarse como "en ejecución". Las evaluaciones de un proyecto deben presentarse de manera que se pueda analizar la evolución del proyecto a través de la comparación de dichas evaluaciones. 2.2. Gestión de usuarios Deben existir al menos los siguientes roles en el sistema: Líderes de proyecto: son los responsables de la administración del proyecto pudiendo crear evaluaciones y/o participar en todas las evaluaciones “en ejecución” de ese proyecto. Colaboradores de proyecto: son usuarios asignados por el líder del proyecto y su función es realizar evaluaciones del proyecto. Un colaborador puede, entonces, crear una evaluación y completarla hasta obtener el resultado de viabilidad. Un colaborador no puede continuar una evaluación “en ejecución” creada por otro colaborador del mismo proyecto. Evaluador: Es un usuario con mucha experiencia que tiene conocimiento suficiente en proyectos que utilizan la metodología P3TQ y puede actualizar la plantilla de evaluación de estudio de viabilidad de proyectos. Administrador: Es responsable de la administración de la infraestructura y de la base de datos que consume sistema, como así también de asignar a los usuarios evaluadores. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 26 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 3. Cambios en la versión A continuación se presentan las modificaciones realizadas en las distintas versiones del documento, para facilitar la trazabilidad de los cambios. 3.1. Versión 4 Actualización del objetivo del documento. 3.2. Versión 3 Actualización del objetivo del documento. Se incorporan los casos de prueba, conclusiones y mejoras. 3.3. Versión 2 Se corrigen las referencias en los gráficos. Se incorpora la documentación de paquetes, clases, secuencia, pantallas y despliegue. 3.4. Versión 1 Versión inicial 4. Especificación de Requerimientos 4.1. Formato La Figura A1.1 contiene el formato con el cual se registran cada uno de los requerimientos. A partir de la sección 4.2 se desarrollán todos los requerimientos utilizando dicho formato. Los campos a completar en dicho registro son los siguientes: Código: comienza con el identificador de tipo: RF si se trata de un requisito funcional o con RNF si se trata de un requisito no funcional. A continuación se enumeran correlativamente según el tipo (funcional o no funcional). Ej) RF-001 (requisito funcional 1) Relevancia: Se clasifica en Alta, Media o Baja según la regla de negocio / requerimiento no funcional que describa. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 27 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Clasificación: Funcional si se trata de un requerimiento funcional o o el tipo de requerimiento no funcional (ej: Reusabilidad, Portabilidad, Confiabilidad, etc.) Nombre: identificador textual (breve) del requerimiento. Descripción: descripción textual del requerimiento. Control de cambios: debe ingresarse por cada cambio la fecha, persona que lo solicita y descripción del cambio. Todos los cambios son registrados de manera cronológica ascendente (el primer cambio al comienzo y el último cambio al final). Código Relevancia Clasificación Nombre Descripción Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.1. Formato de registro de los requerimientos del sistema 4.2. Requerimientos funcionales Los requerimientos funcionales definen las funciones que el sistema será capaz de realizar y describen las transformaciones que el sistema realiza sobre las entradas para producir salidas. Se presentan a continuación los requerimientos funcionales del sistema. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 28 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.2.1. Crear y Actualizar Proyectos La Figura A1.2 presenta el requerimiento funcional con el formato establecido. Código Relevancia Clasificación RF-001 Alta Funcional Nombre CREAR Y ACTUALIZAR PROYECTOS Descripción El sistema debe permitirle a un usuario registrado crear un nuevo proyecto y convertirse en su líder. La información que debe ingresarse y guardarse cuando se crea un proyecto es: Descripción del proyecto Fecha de creación Líder del proyecto (usuario que lo crea) Deben respetarse las siguientes reglas: Cualquier usuario registrado en el sistema se convierte en el líder de un proyecto que crea. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.2. Requerimiento Funcional Crear y Actualizar Proyectos Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 29 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.2.2. Creación de Evaluaciones La Figura A1.3 presenta el requerimiento funcional con el formato establecido. Código Relevancia Clasificación RF-002 Alta Funcional Nombre CREACIÓN DE EVALUACIONES Descripción El sistema debe permitirle al líder del proyecto o a un usuario asignado como colaborador de del mismo crear una nueva evaluación a partir de la plantilla estándar. La información que debe ingresarse y almacenarse cuando se crea una evaluación es: Proyecto al cual pertenece Descripción de la evaluación Fecha de creación Usuario que la crea (colaborador o líder del proyecto) Una vez que la evaluación ha sido creada el sistema debe, automáticamente, presentar la interfaz para que el usuario pueda comenzar a completar el estudio de debilidad. Una evaluación puede ser suspendida, quedando en el estado de "en ejecución". Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.3. Requerimiento Funcional Creación de evaluaciones Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 30 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.2.3. Continuar con una evaluación en Ejecución La Figura A1.4 presenta el requerimiento funcional con el formato establecido. Código Relevancia Clasificación RF-003 Media Funcional Nombre CONTINUAR CON EVALUACIÓN EN EJECUCIÓN UNA Descripción El sistema debe permitirle al usuario creador de una evaluación que se encuentra en el estado de "en ejecución " continuar con la misma, presentándole la interfaz correspondiente. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.4. Requerimiento Funcional continuar con una evaluación en ejecución Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 31 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.2.4. Mostrar resultados del proyecto La Figura A1.5 presenta el requerimiento funcional con el formato establecido. Código Relevancia Clasificación RF-004 Alta Funcional Nombre MOSTRAR PROYECTO RESULTADOS DEL Descripción El sistema debe presentar una interfaz que le permita a los usuarios que iniciaron sesión navegar un proyecto cualquiera. Si el usuario pertenece a dicho proyecto (siendo su líder o colaborador) podrá ver los datos generales del proyecto (descripción, fecha de creación, usuario creador, sus colaboradores) y la información actualizada y resumida de todas las evaluaciones realizadas, incluyendo el resultado final de cada evaluación completada, ordenado de manera cronológica descendente, de manera de poder analizar la evolución del proyecto en el tiempo. Si existen evaluaciones “en ejecución” el sistema debe comunicarlo y proveer una opción para poder retomar dicha evaluación. Si el usuario no pertenece al proyecto podrá ver solamente los datos generales del proyecto especificados anteriormente y la información de las evaluaciones, pero no su resultado final. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.5. Requerimiento Funcional Mostrar resultados del proyecto 4.2.5. Actualización de la Plantilla de Evaluación La Figura A1.6 presenta el requerimiento funcional con el formato establecido. Código RF-005 Relevancia Media Clasificación Funcional Nombre ACTUALIZACIÓN DE LA PLANTILLA DE EVALUACIÓN Descripción El sistema debe proporcionar una plantilla estándar pre-cargada que permita de avisar evaluaciones de proyectos por los usuarios del sistema. Además debe proporcionar una interfaz para que el usuario con rol de Evaluador, Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 32 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ pueda actualizar esta plantilla de evaluación, ajustando los siguientes parámetros en cada pregunta de la plantilla: Texto de la pregunta Dimensión a la que pertenece Peso Deben respetarse las siguientes reglas: Cuando se actualiza la plantilla estándar las evaluaciones posteriores a dicha actualización se realizarán con los cambios. Las evaluaciones que se han completado antes de la actualización no reflejarán los cambios realizados. Las evaluaciones que se encuentran "en ejecución" no reflejarán los cambios en aquellas preguntas ya contestadas; sin embargo sí lo harán en las preguntas aún no contestadas. Control de Cambios Fecha Solicitado por Descripción del cambio 05/03/2009 Alejandro Rodríguez El administrador debe poder inicializar el cuestionario con valores por defecto al desplegarse el sistema por primera vez. El administrador debe poder restablecer el cuestionario por defecto. Figura A1.6. Requerimiento Funcional Actualización de la Plantilla de Evaluación Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 33 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.2.6. Asignación de Colaboradores al Proyecto La Figura A1.7 presenta el requerimiento funcional con el formato establecido. Código Relevancia Clasificación RF-006 Alta Funcional Nombre ASIGNACIÓN DE COLABORADORES AL PROYECTO Descripción El sistema debe permitirle al líder de un proyecto designar colaboradores para que puedan realizar evaluaciones en dicho proyecto. La información que debe ingresarse para poder asignar un colaborador es su nombre de usuario, coincidente con su dirección de correo electrónico. Una vez que esta información ha sido provista, los usuarios designados pueden colaborar en un proyecto creando evaluaciones. Deben respetarse las siguientes reglas: Un usuario puede ser colaborador de distintos proyectos. Un usuario no puede ser colaborador y líder de proyecto al mismo tiempo. El rol de líder de proyecto incluye la funcionalidad de colaborador. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.7. Requerimiento Funcional Asignación de Colaboradores al Proyecto Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 34 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.2.7. Designación de evaluadores La Figura A1.8 presenta el requerimiento funcional con el formato establecido. Código Relevancia Clasificación RF-007 Alta Funcional Nombre DESIGNACIÓN DE EVALUADORES Descripción El sistema debe permitirle al administrador de sistema designar a aquellos usuarios con el rol de evaluadores. La información que debe ingresarse para poder designar a un usuario como evaluador es su nombre de usuario, coincidente con su dirección de correo electrónico. Una vez que esta información ha sido provista, los usuarios designados pueden actualizar la plantilla estándar de evaluación de proyecto. Deben respetarse las siguientes reglas: Todos usuarios evaluadores pueden realizan cambios sobre la única plantilla estándar. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.8. Requerimiento Funcional Designación de evaluadores Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 35 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.3. Requerimientos no funcionales Los requerimientos no funcionales tienen que ver con características que de una u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema, disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares, etc. Se presentan a continuación los requerimientos no funcionales del sistema. 4.3.1. Proporcionar tiempos de respuesta aceptables La Figura A1.9 presenta el requerimiento no funcional con el formato establecido. Código RNF001 Relevancia Clasificación Alta Rendimiento Nombre PROPORCIONAR TIEMPOS RESPUESTA ACEPTABLES DE Descripción El sistema debe poseer la capacidad de prestar el servicio con los siguientes niveles aceptables de desempeño, teniendo cuenta la concurrencia de usuarios Tiempo máximo de actualización de pantalla durante la ejecución de una evaluación a cada usuario: 5 seg. Cantidad máxima de usuarios concurrentes: 20 usuarios Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.9. Requerimiento no Funcional Designación de evaluadores Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 36 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.3.2. Preveer Contingencias Por Caída Del Sistema La Figura A1.10 presenta el requerimiento no funcional con el formato establecido. Código RNF002 Relevancia Clasificación Alta Rendimiento Nombre PREVEER CONTINGENCIAS CAIDA DEL SISTEMA POR Descripción El sistema deberá prever contingencias que pueden afectar la prestación estable y permanente del servicio. La siguiente es la lista de las contingencias que se deben tener en cuenta y se pueden considerar críticas: Caída del sistema por volumen de datos excedido en la base. Sobrecarga del sistema por volumen de transferencia de datos a los usuarios. Caída del sistema por sobrecarga de recursos (procesos, memoria). Estas consideraciones implicarán que la infraestructura técnica sobre la que se implantará el sistema garantice una alta disponibilidad del mismo. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.10. Requerimiento no Funcional Preveer Contingencias Por Caída Del Sistema Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 37 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.3.3. Considerar El Crecimiento Esperado En El Volumen De Datos La Figura A1.11 presenta el requerimiento no funcional con el formato establecido. Código Relevancia Clasificación Nombre RNF003 Media CONSIDERAR EL CRECIMIENTO ESPERADO EN EL VOLUMEN DE DATOS Capacidad Descripción El sistema deberá garantizar el soporte en el crecimiento del volumen de la información almacenada que se gestionará en la base de datos. Deben realizarse estimaciones, mediciones y comparaciones para proyectar un estimado de dicho crecimiento, y se presentarse las características de tecnología requeridas para afrontar el crecimiento proyectado en el volumen. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.11. Requerimiento no Funcional Considerar El Crecimiento Esperado En El Volumen De Datos Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 38 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.3.4. Parametrizar Las Variables Del Sistema La Figura A1.12 presenta el requerimiento no funcional con el formato establecido. Código RNF004 Relevancia Clasificación Media Portabilidad Nombre PARAMETRIZAR LAS VARIABLES DEL SISTEMA Descripción El sistema debe permitir que sus variables y eventos de conFigura A1.ción sean parametrizables e independientes del código fuente. La modificación de los parámetros configurables será planteada para que el sistema tome sus cambios una vez reiniciado el servidor de aplicaciones y no en tiempo de ejecución de tal manera que se disminuya el riesgo de perdida de funcionalidad por configuraciones en el vuelo. Se deberá emplear la tecnología estándar propuesta por Appengine de Google. Las variables que se configurarán, o se presentarán en el archivo de configuración, determinarán fuentes de datos y ubicación de recursos. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.12. Requerimiento no Funcional Parametrizar Las Variables Del Sistema Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 39 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.3.5. Diseñar interfaces con el usuario amigables La Figura A1.13 presenta el requerimiento no funcional con el formato establecido. Código Relevancia Clasificación Nombre RNF005 Media DISEÑAR INTERFACES USUARIO AMIGABLES Amigabilidad CON EL Descripción El sistema debe poseer una interfaz gráfica uniforme a través del mismo incluyendo pantallas, menús y opciones, tamaño de las pantallas, color, tipo de letra y configuración de los campos de entrada. El diseño debe realizarse guiado por las características generales, en cuanto a colores institucionales y disposición de contenidos, encontradas en el sitio web de la organización. Las interfaces deben realizarse en idioma castellano; sin perjuicio de lo cual debe evitar traducirse la terminología técnica específica que no posee una traducción precisa al castellano. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.13. Requerimiento no Funcional Diseñar interfaces con el usuario amigables 4.3.6. Desarrollar manual de usuario La Figura A1.14 presenta el requerimiento no funcional con el formato establecido. Código Relevancia Clasificación Nombre RNF006 Alta DESARROLLAR USUARIO Amigabilidad MANUAL DE Descripción Debe desarrollarse el Manual de Usuario del Sistema que especifique la totalidad de la funcionalidad que éste provee. Los contenidos del Manual deben estar ofrecidos 100% en línea, en formato HTML. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.14. Requerimiento no Funcional Desarrollar manual de usuario Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 40 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.3.7. Codificar con estándares La Figura A1.15 presenta el requerimiento no funcional con el formato establecido. Código RNF007 Relevancia Clasificación Alta Portabilidad Nombre CODIFICAR CON ESTANDARES Descripción El código fuente del sistema debe cumplir con un estándar de codificación. El estándar especificado debe considerar puntos como: Estándares de nombres utilizados en todos sus objetos: programas, formas, tablas, campos, índices, procedimientos, paquetes. Empleo de las características del IDE Eclipse para el formato del código. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.15. Requerimiento no Funcional codificar con estándares 4.3.8. Permitir niveles de seguridad La Figura A1.16 presenta el requerimiento no funcional con el formato establecido. Código RNF008 Relevancia Clasificación Alta Seguridad Nombre PERMITIR NIVELES DE SEGURIDAD Descripción El sistema deberá permitir que toda su información junto con los procesos desarrollados por el mismo tenga controles de acceso acordes con el nivel de privacidad requerido. Los niveles de seguridad estarán determinados por la distribución jerárquica de los usuarios, a saber: Usuarios Administradores: Acceso total. Usuarios registrados : Podrán tener acceso al información, que corresponda con su rol (líder de proyecto, colaborador o evaluador) Control de Cambios Fecha Solicitado por Descripción del cambio Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 41 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A1.16. Requerimiento no Funcional permitir niveles de seguridad Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 42 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 4.4. Restricciones Se presentan a continuación las restricciones del sistema. 4.4.1. Arquitectura del Sistema La Figura A1.17 presenta la restricción con el formato establecido. Código Relevancia Clasificación RST-001 Alta Restricciones Nombre ARQUITECTURA DEL SISTEMA Descripción El Sistema debe desarrollarse sobre la Arquitectura Web Appengine de Google debiendo utilizarse exclusivamente recursos de software compatibles con ella. Los requerimientos mínimos de la aplicación, corriendo en un servidor local se presentan a continuación. Los requisitos de hardware del servidor pueden variar según los requerimientos de rendimiento: Procesador 1.0 GHz 512 MB de RAM Los requerimientos mínimos de software y hardware en el equipo cliente son: Navegador web compatible con Javascript (Recomendado IE7 o posterior/Firefox 2.0 o posterior) Conexión a Internet, si la aplicación se ejecuta en Appspot de Google o Interfaz de Red que soporte el protocolo TCP/IP para una conexión local. Control de Cambios Fecha Solicitado por Descripción del cambio Figura A1.17. Restricción Arquitectura del Sistema Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 43 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 5. Modelo de análisis 5.1. Diagrama de Casos de Uso La Figura A1.18 presenta el diagrama de Casos de Uso del sistema, basado en los requerimientos funcionales desarrollados previamente: ud Casos de Uso Inicializar ev aluación Asignar Colaborador Administrador Asignar ev aluador Lider de Proyecto «include» «include» Crear Proyecto «include» Validar usuario Consultar Ev aluación «include» «include» «include» Visitante «include» «include» Consultar Proyecto «include» Ev aluar Viabilidad Actualizar plantilla de ev aluación «include» Ev aluador Colaborador de Proyecto Crear Ev aluación Figura A1.18. Restricción Arquitectura del Sistema Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 44 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 5.2. Matriz de trazabilidad Casos de Uso – Requerimientos Funcionales La Figura A1.19 muestra la matriz de trazabilidad que permite relacionar los casos de uso del sistema con los requerimientos funcionales, permitiendo conocer que requerimientos funcionales resuelve cada caso de uso. Caso de Uso Id Nombre Requerimiento Funcional Id CU-001 Validar usuario -- CU-002 Asignar evaluador RF–007 CU-003 Actualizar planilla de evaluación RF–005 CU-004 Evaluar viabilidad RF–003 CU-005 Crear evaluación RF–002 CU-006 Consultar proyecto RF–004 CU-007 Consultar evaluación RF–004 CU-008 Crear proyecto RF–001 CU-009 Asignar colaborador RF–006 CU-010 Inicializar Evaluación RF–005 Figura A1.19. Matriz de trazabilidad Casos de Uso – Requerimientos funcionales Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 45 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 5.3. Realización de los Casos de Uso A continuación se presenta la realización de cada uno de los casos de uso del sistema. 5.3.1. Validar Usuario La Figura A1.20 presenta el caso de uso con el formato establecido. ID CU-001 Nombre VALIDAR USUARIO Fecha Creación 16/11/2008 Actores - Descripción El sistema verifica que el usuario posea el rol correcto para realizar una tarea. Trigger El usuario intenta realizar una acción en el sistema. Fecha última 16/11/2008 modificación Precondiciones Postcondiciones El operador se encuentra validado en el sistema. Flujo principal CU-001.0 1. El sistema presenta una pantalla que invita al usuario a ingresar su nombre y contraseña para autenticarse. 2. El usuario ingresa su nombre y contraseña y presiona el botón “ingresar”. 3. El sistema verifica los roles que posee el usuario en el sistema (visitante, líder de proyecto, colaborador o evaluador). 4. El sistema notifica al usuario que está autenticado. Flujos alternativos CU-001.1 1. Si el usuario ingresa su nombre y contraseña de manera incorrecta el sistema lo notifica y le solicita ingresar los datos nuevamente, volviendo a CU001.0 Excepciones Extensiones - Incluye - Heredado por - Prioridad Alta Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 46 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Reglas de Negocio Requerimientos especiales Hipótesis Notas Figura A1.20. Caso de uso validar Usuario 5.3.2. Asignar evaluador La Figura A1.21 presenta el caso de uso con el formato establecido. ID CU-002 Nombre ASIGNAR EVALUADOR Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Administrador Descripción El administrador del sistema designa a un usuario con el rol de evaluador para que pueda modificar la plantilla estándar de evaluación. Trigger El administrador accede a la opción agregar evaluador Precondiciones El administrador ha iniciado sesión en el sistema. Postcondiciones Un nuevo usuario cuenta con el rol de evaluador. Flujo principal CU-002.0 1. El sistema verifica que el usuario sea administrador. De no cumplirse se ejecuta el flujo alternativo CU-002.1. 2. El sistema presenta un formulario que solicita el email del usuario a registrar como evaluador. 3. El administrador ingresa el e-mail del usuario. 4. El sistema agrega al usuario como evaluador y notifica al administrador Flujos alternativos CU-002.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. Excepciones - Extensiones - Incluye CU-001. Validar Usuario Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 47 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Heredado de - Prioridad Reglas de Negocio Requerimientos especiales Hipótesis RF-007 Notas - Alta Figura A1.21. Caso de uso asignar evaluador 5.3.3. Actualizar planilla de evaluación La Figura A1.22 presenta el caso de uso con el formato establecido. ID Nombre CU-003 ACTUALIZAR PLANILLA DE EVALUACIÓN Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Evaluador Descripción El usuario evaluador actualiza las preguntas de la planilla estándar de evaluación, es la fuente de las futuras evaluaciones de viabilidad de todos los proyectos. Trigger El evaluador accede a la opción actualizar planilla Precondiciones El usuario debe contar con el rol de evaluador Postcondiciones La planilla actualizada Flujo principal de evaluación estándar queda CU-003.0 1. El sistema verifica que el usuario sea evaluador. De no cumplirse se ejecuta el flujo alternativo CU003.1. 2. El sistema presenta un formulario que muestra la información de todas las preguntas de la plantilla estándar con la posibilidad de modificar la descripción, el peso y la dimensión. 3. El evaluador actualiza todos los parámetros de todas las preguntas que consideren necesario y enviar formulario. 4. El sistema actualiza la plantilla estándar y notifica al evaluador Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 48 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Flujos alternativos CU-003.1 el sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. Excepciones - Extensiones - Incluye Heredado de - Prioridad Reglas de Negocio Requerimientos especiales Hipótesis RF-005 Notas - CU-001. Validar Usuario Alta Figura A1.22. Caso de uso actualizar planilla de evaluación 5.3.4. Evaluar viabilidad La Figura A1.23 presenta el caso de uso con el formato establecido. ID Nombre CU-004 EVALUAR VIABILIDAD Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Líder de proyecto colaborador Descripción El sistema le permite al usuario creador de una evaluación que se encuentra en el estado de "en ejecución" continuar con la misma, presentándole la interfaz correspondiente. Trigger El líder de proyecto o colaborador accede a la opción continuar evaluación. Precondiciones El usuario debe contar con el rol de colaborador en el proyecto en el cual desea continuar la evaluación. Postcondiciones La evaluación queda actualizada con los pasos del cuestionario cargados Flujo principal CU-004.0 1. El sistema verifica que el usuario sea colaborador Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 49 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ del proyecto al cual pertenece la evaluación. De no cumplirse se ejecuta el flujo alternativo CU-004.1. 2. Se repite el siguiente ciclo hasta que el colaborador completa la última pregunta del cuestionario o abandona el cuestionario dejándolo incompleto. a. El sistema presenta todas las preguntas y respuestas contestadas hasta el momento. b. El sistema presenta un formulario que muestra la próxima pregunta del cuestionario. El colaborador contesta la pregunta. c. 3. Si el usuario completo todo el cuestionario el sistema muestra el resultado de la evaluación, ejecutando el caso de uso CU-007. Flujos alternativos CU-004.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. Excepciones - Extensiones - Incluye CU-001. Validar Usuario CU-007. Consultar evaluación Heredado por - Prioridad Alta Reglas Negocio Notas de RF-003 Figura A1.23. Caso de uso evaluar viabilidad 5.3.5. Crear evaluación La Figura A1.24 presenta el caso de uso con el formato establecido. ID CU-005 Nombre CREAR EVALUACIÓN Fecha Creación 16/11/2008 Actores Descripción Fecha última 16/11/2008 modificación Colaborador El sistema le permite al usuario colaborador crear una evaluación en un proyecto al cual pertenece. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 50 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Trigger El colaborador accede a la opción crear nueva evaluación. Precondiciones El usuario debe contar con el rol de colaborador en el proyecto en el cual desea crear la evaluación. Postcondiciones La evaluación queda creada. Flujo principal CU-005.0 1. El sistema verifica que el usuario sea colaborador del proyecto al cual pertenece la evaluación. De no cumplirse se ejecuta el flujo alternativo CU-005.1. 2. El sistema presenta un formulario para que el colaborador ingrese la descripción de la evaluación. 3. El colaborador completa de información y envía el formulario. 4. El sistema crea la nueva evaluación, y ejecuta el caso de uso CU-004, que inicia la evaluación de viabilidad. Flujos alternativos CU-005.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. Excepciones - Extensiones - Incluye CU-001. Validar Usuario CU-004. Evaluar viabilidad Heredado por - Prioridad Alta Reglas de RF-002 Negocio Requerimientos especiales Hipótesis Notas Figura A1.24. Caso de uso Crear evaluación 5.3.6. Consultar proyecto La Figura A1.25 presenta el caso de uso con el formato establecido. ID CU-006 Nombre CONSULTAR PROYECTO Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 51 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Líder de proyecto Colaborador Descripción El sistema le presenta a los miembros del proyecto toda la información existente. Trigger Un usuario del proyecto ingresa a la opción consultar proyecto. Precondiciones El usuario debe pertenecer al proyecto(líder o colaborador) Postcondiciones Ninguna Flujo principal CU-006.0 1. El sistema verifica que el usuario sea líder o colaborador del proyecto. De no cumplirse se ejecuta el flujo alternativo CU-006.1. 2. El sistema presenta la siguiente información del proyecto al usuario, dando la opción de que la información pueda ser impresa en papel. Fecha de creación Descripción Líder Colaboradores Lista de evaluaciones realizadas ordenadas en forma cronológica descendente (incluye fecha de creación, colaborador de la creo, descripción, estado: sí está finalizada el resultado de la evaluación; sino el mensaje en ejecución). Flujos alternativos CU-006.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. Excepciones - Extensiones - Incluye Heredado de - Prioridad Alta CU-001 : Validar Usuario Reglas de RF-004 Negocio Requerimientos especiales Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 52 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Hipótesis - Notas Figura A1.25. Caso de uso consultar proyecto 5.3.7. Consultar Evaluación La Figura A1.26 presenta el caso de uso con el formato establecido. ID CU-007 Nombre COSULTAR EVALUACIÓN Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Líder de proyecto Colaborador Descripción El sistema le presenta a los miembros del proyecto la información de una evaluación. Trigger Un usuario del proyecto ingresa a la opción consultar Evaluación. Precondiciones El usuario debe pertenecer al proyecto (líder o colaborador) la evaluación debe estar finalizada. Postcondiciones Ninguna Flujo principal CU-007.0 1. El sistema verifica que el usuario sea líder o colaborador del proyecto. De no cumplirse se ejecuta el flujo alternativo CU-007.1. 2. El sistema presenta la siguiente información de la evaluación al usuario proveyendo la opción de imprimir en papel. Fecha de creación Proyecto al cual pertenece Colaborador de la creo Descripción Resultado final expresado numérica y gráficamente. Todas las preguntas y respuestas de la evaluación que fueron respondidas y que justifican el resultado. Flujos alternativos CU-007.1 El sistema notifica al usuario que no cuenta con los Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 53 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ permisos suficientes para llevar a cabo la tarea. Excepciones - Extensiones - Incluye Heredado de - Prioridad Alta CU-001 : Validar Usuario Reglas de RF-004 Negocio Requerimientos especiales Hipótesis Notas Figura A1.26. Caso de uso consultar evaluación 5.3.8. Crear proyecto La Figura A1.27 presenta el caso de uso con el formato establecido. ID Nombre CU-008 CREAR PROYECTO Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Visitante Descripción El sistema le permite a un usuario registrado crear un nuevo proyecto y convertirse en su líder. Trigger El usuario accede a la opción crear nuevo proyecto. Precondiciones - Postcondiciones El proyecto queda creado. Flujo principal CU-008.0 1. El sistema presenta un formulario para que el usuario ingrese la descripción del nuevo proyecto. 2. El usuario completa de información y envía el formulario. 3. El sistema crea el nuevo proyecto. Flujos alternativos Excepciones - Extensiones - - Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 54 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Incluye CU-001. Validar Usuario Heredado por - Prioridad Alta Reglas de RF-001 Negocio Requerimientos especiales Hipótesis Notas Figura A1.27. Caso de uso Crear proyecto 5.3.9. Asignar colaborador La Figura A1.28 presenta el caso de uso con el formato establecido. ID CU-009 Nombre ASIGNAR COLABORADOR Fecha Creación 16/11/2008 Actores Fecha última 16/11/2008 modificación Líder de proyecto Descripción El líder de un proyecto designa a un usuario con el rol de colaborador para que pueda crear nuevas evaluaciones en dicho proyecto. Trigger El líder del proyecto accede a la opción agregar colaborador Precondiciones El líder de proyecto ha iniciado sesión en el sistema. Postcondiciones Un nuevo usuario cuenta con el rol de colaborador. Flujo principal CU-009.0 1. El sistema verifica que el usuario sea líder del proyecto. De no cumplirse se ejecuta el flujo alternativo CU-009.1. 2. El sistema presenta un formulario que solicita el email del usuario a registrar como colaborador. 3. El líder del proyecto ingresa el e-mail del usuario. 4. El sistema agrega al usuario como colaborador y notifica al líder del proyecto Flujos alternativos CU-009.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 55 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Excepciones - Extensiones - Incluye Heredado por - Prioridad Reglas de Negocio Requerimientos especiales Hipótesis RF-006 CU-001. Validar Usuario Alta Notas Figura A1.28. Caso de uso asignar colaborador 5.3.10. Inicializar cuestionario La Figura A1.29 presenta el caso de uso con el formato establecido. ID Nombre CU-010 INICIALIZAR CUESTIONARIO Fecha Creación 05/03/2009 Actores Fecha última 05/03/2009 modificación Administrador Descripción El administrador del sistema inicializa la Plantilla estándar de evaluación de proyectos con los valores predeterminados. Trigger El administrador accede a la opción de inicializar Plantilla devaluación. Precondiciones El administrador ha iniciado sesión en el sistema. Postcondiciones La Plantilla estándar de evaluación de proyectos se encuentra inicializada con los valores por defecto. Flujo principal CU-009.0 1. El sistema verifica que el usuario sea administrador. De no cumplirse se ejecuta el flujo alternativo CU-010.1. 2. El sistema presenta un formulario que solicita al administrador del sistema su confirmación para inicializar la Plantilla de evaluación con los valores por defecto. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 56 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 3. Si el administrador contesta “sí” entonces se ejecuta el flujo alternativo CU-009.2. Si el administrador contesta “no” se ejecuta el flujo alternativo CU-009.3 Flujos alternativos CU-009.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. CU-009.2 El sistema inicializa la Plantilla de evaluación con los valores por defecto y notifica al administrador sobre la acción. CU-009.3 El sistema notifica al usuario que no se realizó la inicialización del cuestionario. Excepciones - Extensiones - Incluye Heredado por - Prioridad Reglas de Negocio Requerimientos especiales Hipótesis RF-005 CU-001. Validar Usuario Alta Notas Figura A1.29. Caso de uso inicializar cuestionario Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 57 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 6. Arquitectura del Sistema 6.1. La arquitectura Appengine La Figura A1.30 presenta un gráfico que resume las principales componentes de la arquitectura propuesta por Appengine y que, en líneas generales, respeta el clásico patrón MVC y que será la base del desarrollo del Sistema. Figura A1.30. Arquitectura de Appengine Entidades persistentes: Appengine provee una capa destinada al modelado de entidades persistentes. Si bien la persistencia y el modelo de negocio están completamente acoplados en esta capa (Patrón Active Record) Appengine provee un framework de persistencia que permite abstraerse del modelo relacional y trabajar con entidades, utilizando operadores en las entidades y el lenguaje GQL para realizar consultas de objetos. Controlador RequestHandler. Appengine provee un controlador que encapsula el protocolo http y permite capturar la interacción del usuario a través de comandos GET o POST, que se traducen en Requests o pedidos. El controlador se programa según se requiera y se presentarán los resultados utilizando plantillas (ver a continuación) a través de Responses o respuestas. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 58 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Plantillas de Vista: Appengine provee un framework basado en Django para desarrollar las vistas HTML utilizando plantillas (Patrón Template View) y fomentando la reutilización y desacople con el modelo de negocio. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 59 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7. Diseño de la aplicación En esta sección se detallará el diseño elegido para implementar el sistema. La técnica elegida para llevar a cabo la tarea consiste en presentar los modelos de lo general a lo particular. Se comenzara por presentar los paquetes que componen la aplicación y su relación. Posteriormente se describirá cada paquete como un conjunto de clases que colaboran para resolver alguna parte del sistema, utilizando diagramas de clase UML. Finalmente se describirán las responsabilidades de las clases más relevantes del paquete. Una vez presentados en detalle cada uno de los paquetes y las clases del sistema se utilizarán diagramas de secuencia que permitan comprender la dinámica del sistema a través de la interacción de las clases de distintos paquetes. 7.1. Diagrama de Paquetes de clases A partir de la arquitectura presentada, que está basada fundamentalmente en el patrón MVC, se diseñaron los paquetes que interrelacionados implementan la funcionalidad del sistema. La categorización por colores que se presenta en la Figura A1.31 será utilizada de aquí en adelante en este documento, para facilitar la comprensión del mismo. Modelo Vista Controlador Infraestructura Figura A1.31. Código de color para cada una de las categorías de paquetes de la aplicación El diagrama presentado en la Figura A1.32 muestra los paquetes de las clases del sistema y sus dependencias, categorizando cada uno de ellos por medio de colores que permiten identificar a qué categoría pertenecen. Las categorías existentes son las tres definidas en el modelo MVC (modelo, vista y controlador) más una cuarta denominada infraestructura. Esta cuarta categoría en provista por el entorno Appengine e implementa los servicios de base que Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 60 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ permitan desarrollar una aplicación dentro de la arquitectura. Algunos de los servicios dentro de la categoría son: Persistencia de entidades. Acceso a archivos del sistema operativo. Motor de plantillas para representación de página web dinámicas. Autenticación de usuarios. Estos servicios son parte de la infraestructura de la aplicación y, generalmente, son consumidos por una o más de las tres categorías de MVC. pd Paquetes dbmodel + Answer ev aluatorform + AddMemberPage + Evaluation + Evaluate + EvaluationInstance + MainPage + Evaluator + NextQuestion + Project + ProjectMember + Question + Result v iew + CustomView + EvaluationDraw google.appengine.ext + db + webapp google.appengine.api + users + webapp.template menu + menu Infraestructura Vista Modelo Controlador Figura A1.32. Diagrama de paquetes de la aplicación categorizados por color Por simplicidad para el entendimiento se ha omitido la representación en el diagrama todos los paquetes de la categoría controlador del sistema, incluyendo solamente el paquete controlador evaluatorform. Para una descripción detallada de cada uno de los paquetes controladores debe leerse la sección 7.4 de este documento. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 61 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ La Figura A1.33 describe brevemente todos los paquetes que se han desarrollado en el sistema y qué casos de uso implementa cada uno. No se describen los paquetes de infraestructura ya que han sido muy bien documentados por Appengine. Nuevamente la columna tipo permite identificar la categoría a través de su color asociado. Nombre Tipo CU que Descripción implementa Todos Contiene las clases que implementan el modelo de la aplicación, incluyendo su persistencia. dbmodel Modelo view Vista evaluatorform Controlador CU-004 CU-005 CU-007 Creación, ejecución y cálculo de una evaluación de viabilidad para un proyecto. choose_project Controlador CU-008 Selección de un proyecto. view_project Controlador CU-006 CU-009 Creación proyecto. add_evaluator Controlador CU-002 Agregar evaluadores. help Controlador CU-001 Inicio y cierre de sesión el sistema. Manual de Usuario. data Controlador CU-003 dos CU-010 Inicialización de datos. - Implementa funciones genéricas de representación de los datos en formato HTML. y consulta en Figura A1.33. Trazabilidad entre paquetes y casos de uso 7.2. dbmodel. La capa De dominio La capa de dominio, se encarga de modelar la lógica del estudio de viabilidad, incluyendo aquellas clases que son consideradas entidades y, por ende, deben ser persistentes. Esta capa se desarrolla dentro del componente de Modelo y Persistencia de Appengine. Dentro de la misma existen dos niveles de los cuales uno de ellos está acoplado al otro y usa sus servicios para resolver el estudio: Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 62 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.2.1. Nivel1. Cuestionario En este nivel se encuentran las entidades que modelan el cuestionario: las preguntas, las respuestas admitidas para cada pregunta, y la secuencia dinámica que permite conocer la próxima pregunta a partir de una pregunta respondida con una respuesta determinada. Este nivel implementa un grafo dirigido no cerrado, que representa todas las posibles secuencias del cuestionario. Este nivel, en resumen, representa una plantilla de un cuestionario dinámico. El término dinámico se refiere a que el cuestionario cambia según las preguntas respondidas anteriormente. 7.2.2. Nivel 2. Estudio de Viabilidad En este nivel se encuentran las entidades que modelan el estudio de viabilidad propiamente dicho: los proyectos, las evaluaciones realizadas para dichos proyectos. Debido a que las evaluaciones se realizan por medio de un cuestionario, este nivel es dependiente del anterior. Cada evaluación es una instancia de una plantilla de cuestionario, cuyas preguntas son respondidas con algún valor de respuesta admitido y cuya secuencia está determinada por dichos valores. A continuación se presenta en la Figura A1.34 un gráfico esquemático que permite relacionar los dos niveles de la capa de dominio: Figura A1.34. Ejemplo de los dos niveles existentes en la capa de dominio Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 63 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ En el ejemplo presentado en la Figura A1.34 puede verse que el Nivel 1 implementa un Grafo dirigido no cerrado que permite recorrer todas las opciones del cuestionario comenzando desde la pregunta uno y finalizando en la pregunta 6 o en la pregunta 4. No es necesario que el cuestionario finalice siempre en la misma pregunta, ya que una pregunta del cuestionario es la última cuando posee menos del total de opciones de aristas dirigidas hacia otras preguntas (vértices). En el ejemplo si se llega a la pregunta 6, el cuestionario finaliza porque no existe arista que conduzca hacia otra pregunta. Por otra parte, si se llega a la pregunta 4 y se contesta “no“, el cuestionario también finaliza ya que no existe arista con ese valor que conduzca a una próxima pregunta. Si llegando a la pregunta cuatro se contestara "sí" entonces el cuestionario si continuaría porque existe un arista con dicho valor que conduce de la pregunta 4 a la pregunta 5. Observando ahora el nivel 1 se observa una instancia del cuestionario que ha sido respondida y, por ende posee sólo un camino lineal. Al comenzar el cuestionario el usuario contestó con el valor "no" la pregunta 1, con lo cual el grafo lo llevó a la pregunta 2. En este caso contexto con el valor "sí", pasando entonces a la pregunta 3. Siguiendo la secuencia el cuestionario finaliza cuando el usuario llega a la pregunta 6 y la responde. Como puede verse esta técnica de grafos permite una gran flexibilidad al momento de diseñar los cuestionarios. 7.2.3. Diagrama de Clases Se ha presentado anteriormente una explicación coloquial del diseño del modelo en dos niveles. En esta sección se presentará el modelo de software elegido para implementarlo, a través de un diagrama de clases UML que se muestra en la Figura A1.35: Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 64 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ cd Modelo User Provisto por el User API de Appengine + 1 + email: Text 1 nickname: Text 1 1 + + + all(Evaluator[]) remove(string) userIsEvaluator(var) Ev aluation Proj ectMember Ev aluator evaluator: db.UserProperty db.Model db.Model db.Model + 1 1 1 + + * + + + + + + idproject: db.ReferenceProperty(Project) member: db.UserProperty role: db.TextProperty() 1 db.Model 1 evaluations Proj ect + + + + + createdate: db.DateTimeProperty description: db.TextProperty owner: db.UserProperty releasedate: db.DateTimeProperty testdate: db.DateT imeProperty + + + + + + addEvaluation(string, Evaluation) addMember(string, string) currentUserIsMember() getEvaluations() : Evaluation[] removeMember(string, string) userIsMember(string) 1 1 + + * + + + actualresult: db.IntegerProperty createdate: db.DateTimeProperty description: db.T extProperty idproject: db.ReferenceProperty(Project) owner: db.UserProperty calculate() : Result isComplete() : bool lastQuestion() : Question nextQuestion() : Question questions() : Question[] questions 1 Evaluation Result * 1 db.Model Ev aluationInstance Nivel 2. Estudio de Viabilidad Result + + + + + + + + + description: db.T extProperty dimension: db.TextProperty idanswer: db.IntegerProperty idevaluation: db.ReferenceProperty(Evaluation) idinstance: db.IntegerProperty idquestion: db.IntegerProperty thresholdvalue: db.TextProperty type: db.TextProperty weight: db.IntegerProperty + + answerText(var) dimensionT ext(var) + + + + + + adaptabilidad: array[4] completo: bool exito: array[4] justificacion: array[4] plausibidad: array[4] resultado: array[4] + + + + + A() : float E() : float J() : float P() : float viability(var) 1 1 db.Model db.Model + + db.Model NextQuestion Answ er description: db.TextProperty idanswer: db.IntegerProperty 1 + + 1 + + + + idanswer: db.IntegerProperty idnextquestion: db.IntegerProperty idquestion: db.IntegerProperty answer() : Answer nextQuestion() : Question question() : Question Question 1 + + + 1 + + + + + + + Nivel 1. Questionario category: db.T extProperty description: db.T extProperty dimension: db.TextProperty idquestion: db.IntegerProperty thresholdvalue: db.TextProperty type: db.TextProperty weight: db.IntegerProperty dimensionT ext() nextQuestions() : q:Question[] validAnswers() : a: Answer[] Figura A1.35. Diagrama de clases del paquete dbmodel El Nivel 1 del modelo está implementado por las siguientes clases: Question: implementa la pregunta con todos sus atributos (identificador de pregunta, categoría de la metodología P3TQ, texto de la pregunta, dimensión de la viabilidad, umbral, tipo y peso). El tipo de pregunta permite conocer cuáles son las posibles respuestas admitidas. Por ejemplo el tipo booleano solamente admitir a valores “si” y “no”. Mientras que el tipo “ difuso” admitirá los valores "ninguno", "muy poco", "medio", "alto", "muy alto". Esta clase representa, entonces, los vértices del grafo. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 65 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ NextQuestion: implementa la relación existente entre una pregunta del cuestionario y la siguiente. La clase posee tres atributos que son el identificador de la pregunta respondida, el valor de respuesta de dicha pregunta y el identificador de la próxima pregunta en el cuestionario. Con estos tres atributos puede conocerse cuál es la próxima pregunta del cuestionario a partir de la pregunta actual y la respuesta. Esta clase representa, entonces, las aristas del grafo. Answer: implementa los tipos de respuesta que se admiten en las preguntas del cuestionario. Posee solamente dos atributos (identificador la respuesta y descripción). El Nivel 2 del modelo está implementado por las siguientes clases: EvaluationInstance: Implementa una pregunta del cuestionario respondida para una evaluación determinada. Esta clase se encarga de copiar toda información de la pregunta que instancia y el valor de respuesta que el usuario haya ingresado. Evaluation: implementa una evaluación completa realizada por un usuario. Sus atributos son el creador de la evaluación, la fecha de creación, su descripción y su estado actual. La evaluación permanece abierta mientras no se haya alcanzado una última pregunta de cuestionario; y se encuentra cerrada en caso contrario, pudiéndose conocer el resultado del evaluación. Esta clase se encarga de obtener la secuencia de preguntas del cuestionario consumiendo las clases del nivel 1. Cuando el cuestionario finaliza posee una operación calculate() que permite conocer el resultado del evaluación de viabilidad. Result: Esta clase encapsula el resultado de un estudio de viabilidad, obtenido a partir de una evaluación completa. Posee cinco atributos correspondientes a los cuatro sectores de las dimensiones del estudio de viabilidad, más el vector resultado final. Project: esta clase implementa un proyecto en el cual su creador y colaboradores crearán evaluaciones para estimar su viabilidad. Sus atributos son su identificador, su usuario propietario (líder de proyecto), sus miembros colaboradores (implementado a través de la clase ProjectMember), su descripción y su fecha de creación. Evaluator: implementa los usuarios que tienen la capacidad de modificar los atributos del cuestionario de evaluación. Posee una operación de clase llamada all(), que permite obtener una colección de todos los usuarios con rol de evaluador y una operación llamada userIsEvaluator() que permite conocer, Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 66 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ dada una dirección de correo electrónico, si un usuario posee el rol de evaluador o no. 7.3. View. Paquete de soporte para vista. Las clases pertenecientes a este paquete, que se muestran en la Figura A1.36, tienen la responsabilidad de generar contenidos para la interfaz de usuario. cd v iew db.Model Logical Model::Ev aluator object Ev aluationDraw + + + + accepted: bool = 60 draw: bool evaluation: Evaluation maxsize: int = 100 + + + + + + + + + createArray(Evaluation[]) : EvaluationDraw[] drawA() : string drawBar(int) : string drawE() : string drawJ() : string drawP() : string drawViability() : string getEvaluation() : Evaluation setEvaluation(Evaluation) + evaluator: db.UserProperty + + + all(Evaluator[]) remove(string) userIsEvaluator(var) Logical Model:: User 1 + + 1 email: Text nickname: Text object CustomMenu + getCustomMenu() : string Figura A1.36. Diagrama de clases del paquete view EvaluationDraw: Esta clase tienen la responsabilidad de generar un gráfico de barras en código HTML de cada una de las dimensiones de una evaluación, desacoplando la responsabilidad de dibujo en la clase de dominio. Almacena un objeto de la clase Evaluation (atributo evaluation), el tamaño máximo de escala (atributo maxsize). Existe una operación de clase que funciona como factory para crear una colección de objetos EvaluationDraw a partir de una colección de objetos Evaluation. El motor de renderización de la vista (django), entonces, utiliza objetos EvaluationDraw, con los cuales puede acceder a toda la información de una evaluación y, además, podrá dibujar gráfico de barras con dicho información. Las operaciones de dibujo son DrawBar, que permite dibujar un gráfico de barras genérico, a partir de un valor resultado entre cero y 10. Las operaciones drawP, drawA, drawJ, drawE y drawViability permiten dibujar gráfico de barras para las dimensiones de plausibilidad a, adaptabilidad, justificación, éxito y el resultado final de viabilidad respectivamente. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 67 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ CustomMenu: esta clase tiene la responsabilidad de generar una colección de opciones del menú de usuario según el rol que posea el usuario está ejecutando la aplicación. Para esto, verifica si el usuario es administrador y/o evaluador y devuelve en la colección opciones específicas para estos roles. El motor de renderización de la vista recibe siempre una colección de opciones que le permite mostrar la funcionalidad específica por rol. 7.4. Paquetes de Controladores Como se explicó anteriormente, todos los controladores implementan la interfaz de webapp.RequestHandler, la cual posee las siguientes operaciones: get(): permite procesar un pedido GET del protocolo http. put(): permite procesar un pedido PUT del protocolo http. redirect(): permite redireccionar a un nuevo enlace el cliente http. Para poder procesar los predios de un cliente cuenta con los siguientes atributos: request: este objeto encapsula la información de solicitud de un cliente, fundamentalmente toda las variables y sus valores enviados. response: este objeto permite que el controlador escriba los resultados del proceso, generalmente en formato HTML. A continuación se presentan los diagramas de clase de cada uno de los paquetes que conforman los controladores de la aplicación. 7.4.1. evaluatorform La Figura A1.37 muestra las clases que componen este paquete. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 68 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ pd ev aluatorform Logical Model:: w ebapp. RequestHandler + + request: response: + + + get() : void put() : void redirect(string) : void AddMemberPage + + + v iew _proj ect.html get() : void put() : void redirect(string) : void MainPage + + + get() : void put() : void redirect(string) : void error.html ev aluatorform.html Ev aluate + + + get() : void put() : void redirect(string) : void ev aluate.html Figura A1.37. Diagrama de clases del paquete evaluatorform Las clases de este paquete son: AddMemberPage: esta clase tiene la responsabilidad de agregar o eliminar a un colaborador del proyecto. MainPage: esta clase tiene la responsabilidad de recibir las respuestas de cada pregunta del cuestionario de evaluación, a guardar las y presentarle al usuario la próxima pregunta a responder. Evaluate: esta clase tiene la responsabilidad de presentarle al usuario el resultado de un estudio de viabilidad para una evaluación finalizada. 7.4.2. Add Evaluator La Figura A1.38 muestra las clases que componen este paquete. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 69 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ cd add_ev aluator w ebapp. RequestHandler + + request: response: + + + get() : void put() : void redirect(string) : void webapp.RequestHandler MainPage + + + get() : void put() : void redirect(string) : void error.html add_ev aluator.html Figura A1.38. Diagrama de clases del paquete add_evaluator Las clases de este paquete son: MainPage: esta clase tiene la responsabilidad de agregar o eliminar un evaluador del sistema, que puede modificar la plantilla de evaluación de proyectos. 7.4.3. Choose_project La Figura A1.39 muestra las clases que componen este paquete. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 70 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ cd choose_proj ect w ebapp. RequestHandler + + request: response: + + + get() : void put() : void redirect(string) : void webapp.RequestHandler webapp.RequestHandler MainPage + + + get() : void put() : void redirect(string) : void choose_proj ect.html Figura A1.39. Diagrama de clases del paquete choose_project Las clases de este paquete son: MainPage: esta clase tiene la responsabilidad de seleccionar todos los proyectos de sistema y presentárselos al usuario para que este seleccione uno. En caso de que el usuario de es crear un nuevo proyecto esta clase se encarga de hacer persistente este nuevo proyecto en el sistema. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 71 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.4.4. Help La Figura A1.40 muestra las clases que componen este paquete. cd help w ebapp. RequestHandler + + request: response: + + + get() : void put() : void redirect(string) : void webapp.RequestHandler webapp.RequestHandler webapp.RequestHandler LogoutPage AboutPage LoginPage + + + get() : void put() : void redirect(string) : void + + + get() : void put() : void redirect(string) : void about.html logout.html + + + get() : void put() : void redirect(string) : void login.html Figura A1.40. Diagrama de clases del paquete help Las clases de este paquete son: AboutPage: esta clase tiene la responsabilidad de presentarle al usuario el manual de ayuda. LoginPage: esta clase tiene la responsabilidad de autenticar al usuario, abriendo la sesión en caso de que los datos de ingreso se han correctos. LogoutPage: esta clase tiene la responsabilidad de cerrar la sesión de un usuario. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 72 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.4.5. View_project La Figura A1.41 muestra las clases que componen este paquete. cd v iew _proj ect w ebapp. RequestHandler + + request: response: + + + get() : void put() : void redirect(string) : void webapp.RequestHandler webapp.RequestHandler webapp.RequestHandler MainPage + + + v iew _proj ect.csv get() : void put() : void redirect(string) : void v iew _proj ect.html Figura A1.41. Diagrama de clases del paquete view_project Las clases de este paquete son: MaintPage: esta clase tiene la responsabilidad de recuperar y mostrar al usuario toda la información de un proyecto y de crear nuevas evaluaciones. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 73 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.5. Diagramas de Secuencia A continuación se presentan los diagramas de secuencia que permiten comprender cómo colaboran las clases de las distintas categorías (modelo, pista, controlador e infraestructura) para resolver la funcionalidad requerida. Se han incluido aquellas secuencias que se consideran fundamentales para el sistema. Las restantes se resuelven de manera análoga a las presentadas o son muy simples de implementar por lo cual su representación gráfica no agrega valor. Además del diagrama se describirán brevemente los escenarios dentro de los cuales transcurre cada secuencia. 7.5.1. Crear Proyecto Escenario: El usuario ha iniciado sesión en el sistema. Se encuentra frente a la pantalla de selección de proyectos y desea crear un nuevo proyecto, completando una descripción para el mismo y enviando el formulario. Se considera que no ocurren errores o excepciones. A continuación se presenta en la Figura A1.42 el diagrama de secuencia. sd Crear Proyecto users Usuario choose_project view_project:: MainPage view_project POST(description) post(description) user:= get_current_user project:= <<new>> description, user Logical Model::Project put() render(project) render Figura A1.42. Diagrama de secuencia Crear proyecto. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 74 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.5.2. Crear Evaluación Escenario: El usuario ha iniciado sesión en el sistema y ha seleccionado un proyecto. Se encuentra frente a la pantalla de consulta de dicho proyecto y desea agregar una nueva evaluación, ingresando, para ello, una descripción para la nueva evaluación y enviando el formulario. Se considera que no ocurren errores o excepciones. A continuación se presenta en la Figura A1.43 el diagrama de secuencia. sd Crear Ev aluacion users Miembro view_project evaluatorform::evaluate run POST(create,idproject,description) post(create,idproject,description) user:= get_current_user eval:= <<new>>(idproject,user,description) Logical Model::Evaluation put() q:= questions() nq:= nextQuestion() render(idproject,eval,q,nq) render Figura A1.43. Diagrama de secuencia Crear evaluación. 7.5.3. Contestar Pregunta Escenario: El usuario ha iniciado sesión en el sistema, ha seleccionado un proyecto y ha creado una nueva evaluación para el mismo, o retomado una evaluación previamente creada y aún no completada. Se encuentra frente a la pantalla de ejecución de la evaluación y desea completar la siguiente pregunta del cuestionario. Selecciona entonces la respuesta que considera correcta y envía el formulario. Se considera que no ocurren errores o excepciones. A continuación se presenta en la Figura A1.44 el diagrama de secuencia. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 75 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ sd Contestar Pregunta db Miembro run eval :Evaluation evaluatorform:: evaluate POST(idevaluation,idanswer) post(idevaluation,idanswer) eval:= get(idevaluation) nq:= nextQuestion() ev :EvaluationInstance ev:= <<new>> (idanswer, eval, nq.weight, nq.dimension) put() q:= questions() Si la evaluación está completa. nq2:= nextQuestion() idproject:= idproject [eval.isComplete==false]: render(idproject,eval,nq2,q) render Figura A1.44. Diagrama de secuencia contestar pregunta. 7.5.4. Calcular Evaluación Escenario: El usuario ha iniciado sesión en el sistema, ha seleccionado un proyecto y ha seleccionado una evaluación completa, o retomado una evaluación previamente creada y aún no completada. Se encuentra frente a la pantalla de ejecución de la evaluación y desea completar la siguiente pregunta del cuestionario. Selecciona entonces la respuesta que considera correcta y envía el formulario. Se considera que no ocurren errores o excepciones. A continuación se presenta en la Figura A1.45 el diagrama de secuencia. sd Calcular Ev aluación eval :Evaluation Miembro evaluate evaluatorform:: evaluate [eval.isComplete]: result:= calculate() render(eval,q,result) Si la evaluación está completa. render Figura A1.45. Diagrama de secuencia Calcular Evaluación. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 76 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.6. Secuencia entre Pantallas Las pantallas del sistema han sido presentadas separadamente en cada uno de los diagramas de clase del controlador. El diagrama que se muestra a continuación la Figura A1.46 permite ver, a través de un diagrama de estados UML, como se relacionan entre sí a partir de la interacción del usuario con el sistema. sm Statecharts abrir sesión clear Logout login edit cerrar sesión Inicializar plantilla de evaluación editar plantilla de evaluación choose_proj ect creación de un proyecto agregar evaluador (usuario administrador) ayuda add_ev aluator selección de un proyecto about v iew _proj ect nueva evaluación run carga de pregunta del cuestionario ejecución de evaluación agregado de nuevo colaborador selección de evaluación finalizada evaluación completa ev aluate Figura A1.46. Diagrama de estados para la transición entre las pantallas del sistema. A continuación se presentan cada una de las pantallas que componen el sistema, y las interfaces con el usuario. 7.6.1. Logout Esta pantalla, mostrada en la Figura A1.47, se presenta cuando el usuario desea ingresar al sistema y aún no sea autenticado, o cuando decide salir, cerrando la sesión. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 77 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A1.47. Pantalla Logout. 7.6.2. Login Esta pantalla, mostrada en la Figura A1.48, es provista por el API user del appengine, para que el usuario pueda autenticar se en el tenga a través de su email y contraseña. Figura A1.48. Pantalla Login. 7.6.3. Choose Project Esta pantalla, mostrada en la Figura A1.49, presenta al usuario una tabla con los proyectos existentes en el sistema, mostrando la fecha de creación, la descripción, el e-mail del líder del proyecto, la cantidad de evaluaciones realizadas y el rol que tiene el usuario en dicho proyecto. El usuario puede elegir cualquiera de los proyectos para consultar la información existente. También presenta una interfaz para que el usuario pueda crear un nuevo proyecto ingresando un nombre para el mismo. Figura A1.49. Pantalla Choose Project. 7.6.4. View Project Esta pantalla, mostrada en la Figura A1.50 presenta al usuario toda la información referente a un proyecto que él ha seleccionado. Muestra la información de fecha de creación, líder de proyecto, colaboradores y evaluaciones realizadas. Para estas últimas muestra la fecha de creación, descripción, autor y, si Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 78 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ han sido finalizadas, el resultado. También provee interfaces para crear una nueva evaluación en dicho proyecto, agregar colaboradores al proyecto en caso de que el usuario sea el líder y opciones para exportar la información o imprimir. Figura A1.50. Pantalla View Project. 7.6.5. Run Esta pantalla, mostrada en la Figura A1.51, le presenta al usuario una interfaz para que pueda completar el cuestionario de evaluación. Muestra el nombre proyecto, el nombre de la evaluación, la dimensión, peso y descripción de la pregunta y las opciones de respuesta. Figura A1.51. Pantalla run. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 79 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.6.6. Evaluate Esta pantalla, presentada en la Figura A1.52, se muestra cuando el usuario miembro del proyecto selecciona una evaluación finalizada, o cuando contesta la última pregunta del cuestionario. Presenta el resultado del estudio de viabilidad mostrando los valores de los vectores justificación, adaptabilidad, plausibilidad, éxito y viabilidad y también el módulo de cada uno de ellos numérica y gráficamente. Para permitir trazabilidad presenta cada una de las preguntas respondidas y las respuestas ingresadas. Provee interfaces para que el usuario pueda exportar o imprimir la información. Figura A1.52. Pantalla evaluate. 7.6.7. Add Evaluator Esta pantalla, mostrada en la Figura A1.53, le presenta al usuario administrador del sistema una lista con los e-mail de todos los usuarios evaluadores del sistema. Provee interfaces que permiten agregar nuevos usuarios evaluadores, eliminar de la lista usuarios existentes e imprimir la información. Figura A1.53. Pantalla add evaluator. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 80 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 7.6.8. edit Esta pantalla, mostrada en la Figura A1.54, le presenta al usuario evaluador una interfaz que le permite modificar la plantilla de evaluación de proyectos. Muestra la información de cada preguntas del cuestionario, que puede ser modificada y enlaces que dirigen a la próxima pregunta según el valor de respuesta. Figura A1.54. Pantalla edit. 7.6.9. About Esta pantalla, mostrada la Figura A1.55, le presenta al usuario en manual de ayuda, y la información sobre la versión en ejecución del sistema. Figura A1.55. Pantalla About. 7.6.10. Data Esta pantalla, mostrada en la Figura A1.56, le presenta al usuario administrador una interfaz para confirmar si desea eliminar toda la información del sistema de inicializar la plantilla de evaluación de proyectos. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 81 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A1.56. Pantalla data. 7.6.11. Barra de Menú La barra de menú, mostrada en la Figura A1.57, le permite al usuario seleccionar las opciones del sistema. Se encuentra ubicada en la zona superior de cada una de las pantallas presentadas anteriormente. Figuras 57. Menú del Sistema. Las acciones que pueden realizarse con el menú son: Proyectos: conduce a cualquier usuario que inició sesión en el sistema a la pantalla choose project. Cuestionario: solamente visible por los usuarios con el rol de evaluadores. Conduce al usuario a la pantalla edit. Evaluadores: solamente visible por el administrador de sistema. Conduce a la pantalla add evaluator. Inicializar: solamente visible por el administrador de sistema. Conduce a la pantalla clear. Ayuda: conduce a cualquier usuario que inició sesión en el sistema a la pantalla about. Salir: conduce a cualquier usuario que inició sesión en el sistema a la pantalla logout. 7.7. Diagrama de Despliegue El despliegue de la aplicación es muy simple, como puede verse en la Figura A1.58, ya que consiste en un servidor appengine (de google o local) conteniendo todo los componentes. En el modelo de appengine existe una correspondencia uno a uno entre componente y paquete. Por lo cual, el nodo servidor contendrá todos los paquetes (componentes) presentados anteriormente en este documento. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 82 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ El cliente se comunica con el servidor a través de un navegador web, utilizando el protocolo http. dd Despliegue dbmodel data v iew _proj ect choose_proj ect appengine Serv er help ev aluatorform v iew http menu cliente (w ebbrow ser) Figura A1.58. Diagrama de Despliegue. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 83 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 8. Casos de Prueba En esta sección se desarrollan los casos de prueba planificados y ejecutados satisfactoriamente que surgen de los escenarios más importantes de cada caso de uso. 8.1. Validar Usuario A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-001 : Validar usuario. 8.1.1. Inicio de sesión exitoso La Figura A1.59 nuestra el caso de prueba inicio de sesión exitoso. Identificación CP-001 : Inicio de sesión exitoso Caso de Uso CU-001 que lo origina Escenario El usuario intenta iniciar sesión en el sistema. Datos Entrada de El usuario ingresa un e-mail y contraseña válidos (cuentas activas en google) Resultado Esperado Estado El usuario inicia sesión el sistema. Ejecutado correctamente. Figura A1.59. Caso de prueba inicio de sesión exitoso 8.1.2. Inicio de sesión fallido La Figura A1.60 nuestra el caso de prueba inicio de sesión fallido. Identificación CP-002: Inicio de sesión fallido Caso de Uso CU-001 que lo origina Escenario El usuario intenta iniciar sesión en el sistema. Datos Entrada de El usuario ingresa las siguientes combinaciones de e-mail y contraseña: E-mail válido y contraseña inválida. E-mail y contraseña inválidas. E-mail inválido y contraseña de algún usuario válido. E-mail y contraseña nulos. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 84 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Resultado Esperado Estado E-mail nulo y contraseña correcta. E-mail válido y contraseña nula. El sistema notifica error en el inicio de sesión. Ejecutado correctamente. Figura A1.60. Caso de prueba inicio de sesión fallido 8.2. Asignar evaluador A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-002 : Asignar Evaluador. 8.2.1. Administrador agrega nuevo evaluador La Figura A1.61 nuestra el caso de prueba Administrador agrega nuevo evaluador. Identificación CP-003 : Administrador agrega nuevo evaluador Caso de Uso CU-002 que lo origina Escenario El administrador accede a la pantalla para agregar un nuevo usuario evaluador. Datos Entrada de El administrador ingresa un e-mail válido (cuenta activa en google) Resultado Esperado Estado El usuario evaluador queda registrado en el sistema. Ejecutado correctamente. Figura A1.61. Caso de prueba Administrador agrega nuevo evaluador 8.2.2. Administrador intenta agregar evaluador registrado La Figura A1.62 nuestra el caso de prueba Administrador intenta agregar evaluador registrado. Identificación CP-004 : Administrador intenta agregar evaluador registrado Caso de Uso CU-002 que lo origina Escenario El administrador accede a la pantalla para agregar un usuario evaluador, que ya fue registrado previamente en el sistema. Datos de El administrador ingresa un e-mail válido, que ya fue Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 85 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Entrada registrado previamente (cuenta activa en google) Resultado Esperado Estado El sistema notifica que el e-mail ya ha sido registrado. Ejecutado correctamente. Figura A1.62. Caso de prueba Administrador intenta agregar evaluador registrado 8.2.3. Administrador intenta agregar evaluador con e-mail nulo La Figura A1.63 nuestra el caso de prueba Administrador intenta agregar evaluador con e-mail nulo. Identificación CP-005 : Administrador intenta agregar evaluador con e-mail nulo Caso de Uso CU-002 que lo origina Escenario El administrador accede a la pantalla para agregar un nuevo usuario evaluador. Datos Entrada Resultado Esperado de El administrador envía el formulario sin ingresar un e-mail El sistema notifica que el e-mail no es válido, debido a que es nulo. Estado Ejecutado correctamente. Figura A1.63. Caso de prueba Administrador intenta agregar evaluador con e-mail nulo 8.2.4. Usuario intenta agregar evaluador La Figura A1.64 nuestra el caso de prueba Usuario intenta agregar evaluador. Identificación CP-006 : Usuario intenta agregar evaluador Caso de Uso CU-002 que lo origina Escenario Un usuario, que no cuenta con el rol de administrador, accede a la pantalla para agregar un nuevo usuario evaluador. Datos Entrada Resultado Esperado Estado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la acción. Ejecutado correctamente. Figura A1.64. Caso de prueba Usuario intenta agregar evaluador Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 86 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 8.3. Actualizar planilla de evaluación A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-003 : Actualizar planilla de evaluación. 8.3.1. Evaluador actualiza pregunta La Figura A1.65 nuestra el caso de prueba Evaluador actualiza pregunta. Identificación CP-007 : Evaluador actualiza pregunta Caso de Uso CU-003 que lo origina Escenario Un usuario evaluador accede a la pantalla modificar las preguntas del cuestionario de la plantilla de evaluación. Datos Entrada de El usuario evaluador modifica los siguientes datos de las preguntas: modifica el texto de la Descripción modifica el peso (valor entero entre 0 y 10) modifica la dimensión Resultado Esperado El sistema actualiza los datos de la pregunta y notifica al usuario. Estado Ejecutado correctamente. Figura A1.65. Caso de prueba Evaluador actualiza pregunta 8.3.2. Evaluador intenta actualizar pregunta con datos incorrectos La Figura A1.66 nuestra el caso de prueba Evaluador intenta actualizar pregunta con datos incorrectos. Identificación CP-008 : Evaluador intenta actualizar pregunta con datos incorrectos Caso de Uso CU-003 que lo origina Escenario Un usuario evaluador accede a la pantalla modificar las preguntas del cuestionario de la plantilla de evaluación. Datos Entrada Resultado Esperado de El usuario evaluador modifica los datos de las preguntas, con cada uno de los valores enunciados a continuación : descripción nula peso incorrecto (mayor a 10 y/o alfanumérico) El sistema y notifica al usuario que los datos ingresados son incorrectos. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 87 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Estado Ejecutado correctamente. Figura A1.66. Caso de prueba Evaluador intenta actualizar pregunta con datos incorrectos 8.3.3. Usuario intenta actualizar pregunta La Figura A1.67 nuestra el caso de prueba Usuario intenta actualizar pregunta. Identificación CP-009 : Usuario intenta actualizar pregunta Caso de Uso CU-003 que lo origina Escenario Un usuario, que no cuenta con el rol de evaluador, accede a la pantalla para modificar las preguntas del cuestionario de la plantilla de evaluación. Datos Entrada Resultado Esperado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la acción. Estado Ejecutado correctamente. Figura A1.67. Caso de prueba Usuario intenta actualizar pregunta 8.4. Evaluar viabilidad A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-004: Evaluar viabilidad. 8.4.1. Proyecto altamente viable La Figura A1.68 nuestra el caso de prueba Proyecto altamente viable. Identificación CP-010 : Proyecto altamente viable Caso de Uso CU-004 que lo origina Escenario Un miembro del proyecto accede a la pantalla que permite continuar la ejecución de una evaluación creada por él. Datos Entrada Resultado Esperado de El miembro del proyecto contesta Si o Todo (Si) en cada una de las preguntas. El sistema muestra como resultado de viabilidad: Vector Justificación = (10;10;10;10) Resultado Justificación = 10 Vector éxito = (10;10;10;10) Resultado éxito = 10 Vector adaptabilidad = (10;10;10;10) Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 88 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Estado Resultado adaptabilidad = 10 Vector plausibilidad = (10;10;10;10) Resultado plausibilidad = 10 Vector Viabilidad = (10;10;10;10) Resultado viabilidad = 10 Ejecutado correctamente. Figura A1.68. Caso de prueba Proyecto altamente viable 8.4.2. Proyecto no viable rotundamente La Figura A1.69 nuestra el caso de prueba Proyecto no viable rotundamente. Identificación CP-011 : Proyecto no viable rotundamente Caso de Uso CU-004 que lo origina Escenario Un miembro del proyecto accede a la pantalla que permite continuar la ejecución de una evaluación creada por él. Datos Entrada de El miembro del proyecto contesta las preguntas con los valores indicados a continuación: Las partes interesadas están identificadas? Las partes interesadas son aquellas personas o grupos de personas que afectan o pueden ser afectadas por el proyecto. Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3: Mucho Existen partes interesadas con autoridad suficiente dentro de la organización para liderar el proyecto de explotación? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Poco Existen partes interesadas con recursos económicos suficientes para encarar el proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Poco El proyecto de explotación tiene como propósito buscar relaciones de interés? No El proyecto de explotación tiene como propósito la Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 89 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ evaluación de una situación de negocio? (análisis de problema u oportunidad)? Si Con respecto a la problemática del negocio del proyecto original: Se han encontrado datos de utilidad para llevar a cabo la minería? El proyecto original es aquel que origina el proyecto de explotación que se está evaluando. Boxes de referencia de la metodología P P3TQ: AB6 Poco Las partes interesadas han identificado o pueden identificar aquellas características del negocio importantes, que enmarcan sus expectativas del proyecto de explotación? Boxes de referencia de la metodología P3TQ: TB7 No La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodología P3TQ: AB6 Poco Los Objetivos y Metas del negocio están definidos o pueden definirse? Boxes de referencia de la metodología P3TQ: AB6, TB5 Poco Se requiere inicialmente un análisis estratégico para planificar escenarios corporativos? Si La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodología P3TQ: AB9 Poco Existe un mapa del escenario estratégico, consensuado con las partes interesadas. .Boxes de referencia de la metodología P3TQ: AB12 No Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB12 No Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la No metodología P3TQ: AB12 Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 90 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Existen o pueden realizarse simulaciones que permitan identificar ambigüedades, incertezas, discordancias? Boxes de referencia de la metodología P3TQ: AB12 No Están caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la metodología P3TQ: AB12 No Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P3TQ: AB12, MII Tabla 7.1 Poco Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodología P3TQ: DB9.1 No El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la metodología P3TQ: DB9.1 No Existen variables con único valor, o valores vacios en sus instancias? Boxes de referencia de la metodología P3TQ: DB9.2 Mucho Las variables categóricas están documentadas? Boxes de referencia de la metodología P3TQ: DB9.2 Poco Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodología P3TQ: DB9.3 Poco Son reconocidas y es posible adecuar variables anacrónicas? Boxes de referencia de la metodología P3TQ: DB9.4 No Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre distintos) y generar un set de entrenamiento y otro de testeo? Boxes de referencia de la metodología P3TQ: DB9.5, TB9.4 No Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios más Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 91 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Resultado Esperado importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodología P3TQ: DB9.6 No Es necesario realizar recodificación de variables para mejor comprensión del modelo? Boxes de referencia de la metodología P3TQ: DB9.7 Si Los conjuntos de variables de entrada y salida están caracterizadas? Boxes de referencia de la metodología P3TQ: AB11.1 Si Los datos están estructurados o pueden estructurarse para aplicarlos en la herramienta de minería elegida? Boxes de referencia de la metodología P3TQ: AB11.1 Poco Están seleccionados los algoritmos de minería adecuados al modelo? Boxes de referencia de la metodología P3TQ: AB11.3 No Existe una herramienta de minería adecuada al modelo y está disponible? Boxes de referencia de la No metodología P3TQ: AB11.6 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodología P3TQ: AB11.5 Poco Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodología P3TQ: AB11.1 No El objetivo de la explotación es entender una situación? No El objetivo de la explotación es aplicar una clasificación? No El objetivo de la explotación es buscar una predicción? No El sistema muestra como resultado de viabilidad: Vector Justificación = (1.20 ; 2.20 ; 3.40 ;2.80) Resultado justificación =2.80 Vector éxito = (0.22 ; 0.33 ; 0.42 ; 0.27) Resultado éxito = 0.27 Vector adaptabilidad = (0.42 ; 0.57 ; 0.69 ; 0.49) Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 92 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Estado Resultado adaptabilidad = 0.49 Vector plausibilidad = (1.18 ; 1.54 ; 1.83 ; 1.36) Resultado plausibilidad = 1.36 Vector Viabilidad = (0.85 ; 1.19 ; 1.48 ; 1.02) Resultado viabilidad = 1.02 Ejecutado correctamente. Figura A1.69. Caso de prueba Proyecto no viable rotundamente 8.4.3. Proyecto no viable La Figura A1.70 nuestra el caso de prueba Proyecto no. Identificación CP-012 : Proyecto no viable Caso de Uso CU-004 que lo origina Escenario Un miembro del proyecto accede a la pantalla que permite continuar la ejecución de una evaluación creada por él. Datos Entrada de El miembro del proyecto contesta las preguntas con los valores indicados a continuación: Las partes interesadas están identificadas? Las partes interesadas son aquellas personas o grupos de personas que afectan o pueden ser afectadas por el proyecto..Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Regular Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho Existen partes interesadas con autoridad suficiente dentro de la organización para liderar el proyecto de explotación? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho Existen partes interesadas con recursos económicos suficientes para encarar el proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Regular El proyecto de explotación tiene como propósito buscar relaciones de interés? No El proyecto de explotación tiene como propósito la Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 93 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ evaluación de una situación de negocio? (análisis de problema u oportunidad)? Si Con respecto a la problemática del negocio del proyecto original: Se han encontrado datos de utilidad para llevar a cabo la minería? El proyecto original es aquel que origina el proyecto de explotación que se está evaluando..Boxes de referencia de la metodología P3TQ: AB6 Regular Las partes interesadas han identificado o pueden identificar aquellas características del negocio importantes, que enmarcan sus expectativas del proyecto de explotación? Boxes de referencia de la metodología P3TQ: TB7 Si La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodología P3TQ: AB6 Regular Los Objetivos y Metas del negocio están definidos o pueden definirse? Boxes de referencia de la metodología P3TQ: AB6, TB5 Regular Se requiere inicialmente un análisis estratégico para planificar escenarios corporativos? Si La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodología P3TQ: AB9 Regular Existe un mapa del escenario estratégico, consensuado con las partes interesadas. .Boxes de referencia de la metodología P3TQ: AB12 Si Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB12 Si Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la Si metodología P3TQ: AB12 Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 94 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Existen o pueden realizarse simulaciones que permitan identificar ambigüedades, incertezas, discordancias? Boxes de referencia de la metodología P3TQ: AB12 No Están caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la metodología P3TQ: AB12 Si Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P3TQ: AB12, MII Tabla 7.1 Regular Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodología P3TQ: DB9.1 Si El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la metodología P3TQ: DB9.1 Si Existen variables con único valor, o valores vacios en sus instancias? Boxes de referencia de la metodología P3TQ: DB9.2 Regular Las variables categóricas están documentadas? Boxes de referencia de la metodología P3TQ: DB9.2 Regular Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodología P3TQ: DB9.3 Mucho Son reconocidas y es posible adecuar variables anacrónicas? Boxes de referencia de la metodología P3TQ: DB9.4 Si Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre distintos) y generar un set de entrenamiento y otro de testeo? Boxes de referencia de la metodología P3TQ: DB9.5, TB9.4 Si Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios más Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 95 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Resultado Esperado importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodología P3TQ: DB9.6 Si Es necesario realizar recodificación de variables para mejor comprensión del modelo? Boxes de referencia de la metodología P3TQ: DB9.7 No Los conjuntos de variables de entrada y salida están caracterizadas? Boxes de referencia de la metodología P3TQ: AB11.1 Si Los datos están estructurados o pueden estructurarse para aplicarlos en la herramienta de minería elegida? Boxes de referencia de la metodología P3TQ: AB11.1 Regular Están seleccionados los algoritmos de minería adecuados al modelo? Boxes de referencia de la metodología P3TQ: AB11.3 No Existe una herramienta de minería adecuada al modelo y está disponible? Boxes de referencia de la Si metodología P3TQ: AB11.6 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodología P3TQ: AB11.5 Regular Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodología P3TQ: AB11.1 No El objetivo de la explotación es entender una situación? No El objetivo de la explotación es aplicar una clasificación? No El objetivo de la explotación es buscar una predicción? No El sistema muestra como resultado de viabilidad: Vector Justificación = (3.40 ; 4.40 ; 5.60 ;6.60) Resultado Justificación = 5 Vector éxito = (8.95 ; 9.24 ; 9.54 ; 9.76) Resultado éxito = 9.37 Vector adaptabilidad = (3.48 ; 3.60 ; 3.75 ; 3.88) Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 96 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Estado Resultado adaptabilidad = 3.68 Vector plausibilidad = (2.77 ; 3.07 ; 3.43 ; 3.73) Resultado plausibilidad = 3.25 Vector Viabilidad = (4.37 ; 4.70 ; 5.08 ; 5.39) Resultado viabilidad = 4.89 Ejecutado correctamente. Figura A1.70. Caso de prueba Proyecto no viable 8.4.4. Proyecto no viable por incumplimiento de situaciones esenciales La Figura A1.71 nuestra el caso de prueba Proyecto no. Identificación CP-013 : Proyecto no viable por incumplimiento de situaciones esenciales Caso de Uso CU-004 que lo origina Escenario Un miembro del proyecto accede a la pantalla que permite continuar la ejecución de una evaluación creada por él. Datos Entrada de El miembro del proyecto contesta las preguntas con los valores indicados a continuación: Las partes interesadas están identificadas? Las partes interesadas son aquellas personas o grupos de personas que afectan o pueden ser afectadas por el proyecto..Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Poco Existen partes interesadas con autoridad suficiente dentro de la organización para liderar el proyecto de explotación? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho Existen partes interesadas con recursos económicos suficientes para encarar el proyecto? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho El proyecto de explotación tiene como propósito buscar relaciones de interés? Si Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 97 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ El proyecto original cuenta con el apoyo de la organización? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Todo (Si) Existe comunicación con las partes interesadas del proyecto original? El proyecto original es aquel que origina el proyecto de explotación que se está evaluando..Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3 Todo (Si) Se cumplieron los objetivos del proyecto original? Mucho Se requiere inicialmente un análisis estratégico para planificar escenarios corporativos? No Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodología P3TQ: DB9.1 Si El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la metodología P3TQ: DB9.1 Si Existen variables con único valor, o valores vacios en sus instancias? Boxes de referencia de la metodología P3TQ: DB9.2 Muy poco o nada (No) Las variables categóricas están documentadas? Boxes de referencia de la metodología P3TQ: DB9.2 Mucho Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodología P3TQ: DB9.3 Mucho Son reconocidas y es posible adecuar variables anacrónicas? Boxes de referencia de la metodología P3TQ: DB9.4 Si Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre distintos) y generar un set de Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 98 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ entrenamiento y otro de testeo? Boxes de referencia de la metodología P3TQ: DB9.5, TB9.4 Si Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios más importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodología P3TQ: DB9.6 Si Es necesario realizar recodificación de variables para mejor comprensión del modelo? Boxes de referencia de la metodología P3TQ: DB9.7 No Los conjuntos de variables de entrada y salida están caracterizadas? Boxes de referencia de la Si metodología P3TQ: AB11.1 Los datos están estructurados o pueden estructurarse para aplicarlos en la herramienta de minería elegida? Boxes de referencia de la metodología P3TQ: AB11.1 Mucho Están seleccionados los algoritmos de minería adecuados al modelo? Boxes de referencia de la metodología P3TQ: AB11.3 Si Existe una herramienta de minería adecuada al modelo y está disponible? Boxes de referencia de la metodología P3TQ: AB11.6 Si De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodología P3TQ: AB11.5 Mucho Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodología P3TQ: AB11.1 No El objetivo de la explotación es entender una situación? Si Las variables utilizadas en el modelo están relacionadas con conceptos que son conocidos por las partes interesadas? Boxes de referencia de la metodología P3TQ: AB11.1, DB11.5 Si Los objetos del negocio que representan las variables pueden ser utilizados por las partes Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 99 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ interesadas, o gerentes para realizar mejoras en el negocio. .Boxes de referencia de la metodología P3TQ: AB11.1, DB11,5 Mucho Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodología P3TQ: AB11.1 DB11.5 Si Resultado Esperado El sistema muestra como resultado de viabilidad: Vector Justificación = (10 ; 10 ; 10 ; 10) Resultado Justificación = 10 Vector éxito = (7.80 ; 8.37 ; 8.99 ; 9.47 ) Resultado éxito = 8.66 Vector adaptabilidad = (0 ; 0; 0 ; 0) Resultado adaptabilidad = 0 Vector plausibilidad = (0 ; 0; 0 ; 0) Resultado plausibilidad = 0 Vector Viabilidad = (5.62 ; 5.93 ; 6.20 ; 6.44) Resultado viabilidad = 6.05 Estado Ejecutado correctamente. Figura A1.71. Caso de prueba Proyecto no viable por incumplimiento de situaciones esenciales 8.5. Crear evaluación A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-005 : Crear evaluación. 8.5.1. Miembro del proyecto crea evaluación La Figura A1.72 nuestra el caso de prueba Miembro del proyecto crea evaluación. Identificación CP-011 : Miembro del proyecto crea evaluación Caso de Uso CU-005 que lo origina Escenario Un miembro evaluación. Datos Entrada Resultado Esperado del proyecto intenta crear una nueva de El miembro del proyecto ingresa cualquiera de los siguientes nombres: Texto Alfanumérico Texto nulo El sistema crea una nueva evaluación y redirige al usuario a la pantalla de ejecución de la evaluación. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 100 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Estado Ejecutado correctamente. Figura A1.72. Caso de prueba Miembro del proyecto crea evaluación 8.5.2. Líder del proyecto crea evaluación La Figura A1.73 nuestra el caso de prueba Líder del proyecto crea evaluación. Identificación CP-012 : Líder del proyecto crea evaluación Caso de Uso CU-005 que lo origina Escenario El líder del proyecto intenta crear una nueva evaluación. Datos Entrada de El líder del proyecto ingresa cualquiera de los siguientes nombres: Texto Alfanumérico Texto nulo Resultado Esperado El sistema crea una nueva evaluación y redirige al líder del proyecto a la pantalla de ejecución de la evaluación. Estado Ejecutado correctamente. Figura A1.73. Caso de prueba Líder del proyecto crea evaluación 8.5.3. Usuario intenta crear evaluación La Figura A1.74 nuestra el caso de prueba Usuario intenta crear evaluación. Identificación CP-013 : Usuario intenta crear evaluación Caso de Uso CU-005 que lo origina Escenario Un usuario que no posee roles en un proyecto intenta crear una evaluación en él. Datos Entrada Resultado Esperado Estado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la acción. Ejecutado correctamente. Figura A1.74. Caso de prueba Usuario intenta crear evaluación 8.6. Consultar proyecto A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-006 : Consultar proyecto. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 101 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 8.6.1. Miembro consulta proyecto La Figura A1.75 nuestra el caso de prueba Miembro consulta proyecto. Identificación CP-014 : Miembro consulta proyecto Caso de Uso CU-006 que lo origina Escenario Un miembro del proyecto (colaborador o líder) selecciona un proyecto para consultarlo. Datos Entrada de El usuario selecciona de la lista de proyectos uno al cual pertenece. Resultado Esperado El sistema le presenta al usuario la pantalla de información del proyecto, que incluye los resultados de todas las evaluaciones realizadas. Estado Ejecutado correctamente. Figura A1.75. Caso de prueba Miembro consulta proyecto 8.6.2. Usuario intenta consultar proyecto La Figura A1.76nuestra el caso de prueba Usuario intenta consultar proyecto. Identificación CP-015 : Usuario intenta consultar proyecto Caso de Uso CU-006 que lo origina Escenario Un usuario que no es miembro de un proyecto (ni colaborador ni líder) selecciona ese proyecto para consultarlo. Datos Entrada de El usuario selecciona de la lista de proyectos uno al cual no pertenece. Resultado Esperado El sistema le presenta al usuario la pantalla de información del proyecto, sin mostrar los resultados de las evaluaciones realizadas. Estado Ejecutado correctamente. Figura A1.76. Caso de prueba Usuario intenta consultar proyecto 8.7. Consultar Evaluación A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-007 : Consultar evaluación. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 102 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 8.7.1. Miembro consulta evaluación La Figura A1.77 nuestra el caso de prueba Miembro consulta evaluación. Identificación CP-016 : Miembro consulta evaluación Caso de Uso CU-007 que lo origina Escenario Un miembro del proyecto (colaborador o líder) selecciona una evaluación de ese proyecto para consultarla. Datos Entrada de El usuario selecciona una evaluación de la lista de evaluaciones del proyecto. Resultado Esperado El sistema le presenta al usuario la pantalla de información de la evaluación. Estado Ejecutado correctamente. Figura A1.77. Caso de prueba Miembro consulta evaluación 8.7.2. Usuario intenta consultar evaluación La Figura A1.78 nuestra el caso de prueba Usuario intenta consultar evaluación. Identificación CP-017 : Usuario intenta consultar evaluación Caso de Uso CU-007 que lo origina Escenario Un usuario que no es miembro de un proyecto (ni colaborador ni líder) intenta consultar una evaluación de ese proyecto. Datos Entrada de El usuario selecciona una evaluación de la lista de evaluaciones del proyecto al cual no pertenece. Resultado Esperado El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la acción. Estado Ejecutado correctamente. Figura A1.78. Caso de prueba Usuario intenta consultar evaluación 8.8. Crear Proyecto A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-008 : Crear proyecto. 8.8.1. Usuario crea Proyecto La Figura A1.79 nuestra el caso de prueba Usuario crea proyecto. Identificación CP-018 : Usuario crea proyecto Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 103 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Caso de Uso CU-008 que lo origina Escenario Un Usuario que ha iniciado sesión del sistema intenta crear un nuevo proyecto. Datos Entrada de El usuario ingresa cualquiera de los siguientes nombres para el proyecto: Texto Alfanumérico Texto nulo Resultado Esperado El sistema crea una nueva proyecto, designando como líder al usuario creador, y redirigiendo al usuario a la pantalla de información del proyecto. Estado Ejecutado correctamente. Figura A1.79. Caso de prueba Usuario crea proyecto 8.9. Asignar colaborador A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-009 : Asignar colaborador. 8.9.1. Líder del proyecto agrega nuevo colaborador La Figura A1.80 nuestra el caso de prueba Administrador agrega nuevo evaluador. Identificación CP-019 : Líder del proyecto agrega nuevo colaborador Caso de Uso CU-009 que lo origina Escenario El líder del proyecto accede a la pantalla para agregar un nuevo colaborador al proyecto. Datos Entrada Resultado Esperado de El líder del proyecto ingresa un e-mail válido El usuario colaborador del proyecto queda registrado en el sistema. Estado Ejecutado correctamente. Figura A1.80. Caso de prueba líder de proyecto agrega nuevo colaborador 8.9.2. Líder del proyecto intenta agregar colaborador registrado La Figura A1.81 nuestra el caso de prueba Líder del proyecto intenta agregar colaborador registrado. Identificación CP-020 : Líder del proyecto intenta agregar colaborador Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 104 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ registrado Caso de Uso CU-009 que lo origina Escenario El líder de proyecto accede a la pantalla para agregar un colaborador, que ya ha sido registrado previamente en el sistema, en el mismo proyecto. Datos Entrada de El líder del proyecto ingresa un e-mail válido, que ya fue registrado previamente en ese proyecto (cuenta activa en google) Resultado Esperado El sistema notifica que el e-mail ya ha sido registrado para ese proyecto. Estado Ejecutado correctamente. Figura A1.81. Caso de prueba Líder del proyecto intenta agregar colaborador registrado 8.9.3. Líder de proyecto intenta agregar colaborador con e-mail nulo La Figura A1.82 nuestra el caso de prueba Líder de proyecto intenta agregar colaborador con e-mail nulo. Identificación CP-021 : Líder de proyecto intenta agregar colaborador con e-mail nulo Caso de Uso CU-009 que lo origina Escenario El líder de proyecto accede a la pantalla para agregar un nuevo colaborador al proyecto. Datos Entrada Resultado Esperado de El administrador envía el formulario sin ingresar un e-mail Estado El sistema notifica que el e-mail no es válido, debido a que es nulo. Ejecutado correctamente. Figura A1.82. Caso de prueba Líder de proyecto intenta agregar colaborador con e-mail nulo 8.9.4. Usuario intenta agregar colaborador al proyecto La Figura A1.83 nuestra el caso de prueba Usuario intenta agregar colaborador al proyecto. Identificación CP-022 : Usuario intenta agregar colaborador al proyecto Caso de Uso CU-009 que lo origina Escenario Un usuario, que no cuenta con el rol de líder de proyecto Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 105 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ (puede o no ser colaborador del proyecto), accede a la pantalla para agregar un nuevo usuario evaluador. Datos Entrada Resultado Esperado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la acción. Estado Ejecutado correctamente. Figura A1.83. Caso de prueba Usuario intenta agregar colaborador al proyecto 8.10. Inicializar cuestionario A continuación se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-010 : Inicializar cuestionario. 8.10.1. Administrador inicializa cuestionario La Figura A1.84 nuestra el caso de prueba Administrador inicializa cuestionario. Identificación CP-023 : Administrador inicializa cuestionario Caso de Uso CU-010 que lo origina Escenario El Administrador accede a la pantalla para inicializar la plantilla de evaluación. Datos Entrada Resultado Esperado de El administrador contesta ”Si“ El sistema inicializa la plantilla de evaluación y elimina todos los registros de la base de datos. Estado Ejecutado correctamente. Figura A1.84. Caso de prueba Administrador inicializa cuestionario 8.10.2. Administrador intenta inicializar cuestionario La Figura A1.85 nuestra el caso de prueba Administrador intenta inicializar cuestionario. Identificación CP-023 : Administrador intenta inicializar cuestionario Caso de Uso CU-010 que lo origina Escenario El Administrador accede a la pantalla para inicializar la plantilla de evaluación. Datos Entrada de El administrador contesta ”No“ Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 106 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Resultado Esperado El Sistema aborda la operación y notifica al administrador y notifica al administrador. Estado Ejecutado correctamente. Figura A1.85. Caso de prueba Administrador intenta inicializar cuestionario 8.10.3. Usuario intenta inicializar cuestionario La Figura A1.86 nuestra el caso de prueba Usuario intenta intenta inicializar cuestionario. Identificación CP-024 : Usuario intenta inicializar cuestionario Caso de Uso CU-010 que lo origina Escenario Un usuario, que no cuenta con el rol de administrador, accede a la pantalla para inicializar la plantilla de evaluación. Datos Entrada Resultado Esperado Estado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la acción. Ejecutado correctamente. Figura A1.86. Caso de prueba Usuario intenta inicializar cuestionario Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 107 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 9. Conclusión A lo largo de este documento se desarrollaron de manera detallada todas las etapas involucradas en el desarrollo de la herramienta DAMVE, desde los requerimientos hasta el modelo de diseño para ser implementado en lenguaje Python sobre la arquitectura Appengine de Google. A continuación se resumen los aspectos más relevantes durante el desarrollo de la herramienta DAMVE Si bien el documento presenta las etapas de manera consecutiva, suponiendo un modelo de desarrollo en cascada, el proceso de desarrollo y por consiguiente los contenidos del documento se fueron generando de manera iterativa, siguiendo un proceso conducido por el dominio del problema. Durante la etapa de diseño se buscó siempre que la lógica del dominio del problema fuese independiente del resto de la lógica de la aplicación (vista y controlador). Este aspecto es fundamental en el desarrollo de software ya que hace posible reutilizar completamente dominio para adaptarlo a otro escenario. Además, dado que Appengine está basado en el patrón MVC, que separa el dominio de la interfaz con el usuario (vista y controlador), se consiguió una concordancia entre la arquitectura del sistema y el proceso de desarrollo. Al estar la herramienta basada en un entorno web, se buscó optimizar la interacción con el usuario. Para ello se implementaron interfaces en AJAX/JSON, que minimizan la transferencia http entre el servidor y el cliente, en los casos de uso que requieren mayor interacción usuario/sistema. Como ejemplo se pueden citar los casos de uso CU-003 Actualizar planilla de evaluación y CU-004 Evaluar viabilidad. A lo largo del documento se buscó registrar la trazabilidad que existe entre las distintas etapas de desarrollo. La Figura A1.19 relaciona los requierimientos funcionales con los casos de uso, permitiendo registrar la trazabilidad entre Requerimientos y Casos de Uso. La Figura A1.33 relaciona los casos de uso, con los paquetes de clases que los implementan permitiendo registrar la trazabilidad entre Casos de Uso y Clases. Finalmente en la sección 8 se desarrollan los casos de prueba como escenarios posibles para cada caso de uso, permitiendo registrar la trazabilidad entre Casos de Uso y Casos de Prueba. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 108 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 10. Posibles mejoras Este documento podría mejorarse tomando en cuenta algunos de estos elementos: Incorporando fragmentos de código en lenguaje Python sobre aquella funcionalidad del dominio que permita clarificar la implementación. El Sistema DAMVE podría mejorarse tomando en cuenta algunos de estos elementos: Desarrollar una capa de servicios web. Esto permitiría, por ejemplo, utilizar la aplicación desde una interfaz de usuario de ventanas mejorando la interacción usuario/herramienta, o permitir que la herramienta se integre con otros sistemas proveyendo el servicio de evaluación de viabilidad. En el último caso sería interesante integrar la herramienta DAMVE con un Sistema de administración de proyectos. Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 109 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Anexo 2. Manual de usuario la Herramienta DAMVE Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 110 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 1. Introducción El Sistema DAMVE tiene por finalidad, ayudar a los miembros de un proyecto de explotación de información que utilizan la metodología P3TQ a evaluar su viabilidad. 2. Requisitos Para poder ejecutar el sistema DAMVE se requiere de un navegador web con soporte para AJAX. Los siguientes navegadores funcionan correctamente con el sistema DAMVE : Microsoft Internet Explorer 6.0 o superior Mozilla Firefox 2.0 o superior En cualquiera de los dos casos deben habilitarse las opciones de cookies y ejecución de comandos javascript. 3. Acceso al sistema Cuando un usuario ingresa el enlace del sistema DAMVE en el navegador web se presenta la siguiente pantalla, mostrada en la Figura A2.1.: Figura A2.1. Pantalla de ingreso al sistema Siguiendo el enlace el usuario accede a un formulario que le solicita identificarse para poder ingresar al sistema. Los datos de acceso son: e - m ai l : corresponde a la dirección de e-mail del usuario. Con t ra se ñ a : se debe ingresar la clave de acceso que debe ser conocida por el usuario. Éstos datos son los pertenecientes a una cuenta de Google habilitada, si el sistema se está ejecutando online. Si los datos ingresados son correctos el usuario accede a la pantalla de selección de proyectos, que se muestra en la Figura A2.2: Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 111 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A2.2. Pantalla de selección de proyectos Por el contrario, si los datos ingresados son incorrectos, el sistema mostrará la siguiente pantalla de error, que pedirá que se vuelvan a ingresar los datos nuevamente. 4. Presentación de la interfaz Se presenta a continuación, en la Figura A2.3, la pantalla de selección de proyectos del sistema y se describen las distintas opciones de la barra de menús. 1 2 3 4 5 6 7 Figura A2.3. Pantalla de presentación de la interfaz Los números asociados con cada elemento de la pantalla se describen a continuación: 1. 2. No m b re de u su a ri o : en el encabezado de la pantalla puede verse el nombre del usuario que está utilizando el sistema. P r oy e ct os : esta opción lleva a la pantalla de selección de proyectos que le permite al usuario dar de alta un nuevo proyecto, seleccionar un existente Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 112 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ y, a partir de allí, realizar evaluaciones de viabilidad para el mismo. Esta opción explica en detalle en el ítem 5 de este manual. 3. 4. 5. 6. 7. Cue s tio n a rio : esta opción lleva a la pantalla de edición de la plantilla de evaluación para los estudios de viabilidad. Solamente los usuarios de cuentan con el rol de evaluadores pueden acceder, y les permite modificar los parámetros del cuestionario con el cual se realizan todos los estudios de viabilidad. Esta opción se explica en detalle en el ítem 10.3 de este manual. Ev a lu a do re s : esta opción lleva a la pantalla que le permite al administrador del sistema agregar nuevos usuarios evaluadores para que puedan modificar la plantilla de evaluación, explicada anteriormente. Esta opción se explica en detalle en el ítem 10.1 de este manual. Ini ci a li za r : esta opción lleva a la pantalla que le permite al administrador del sistema inicializar la base de datos, eliminando, de existir, toda la información que exista y reiniciando la plantilla de evaluación. Esta opción se explica en detalle en el ítem 10.4 de este manual. A yu d a : esta opción permite consultar este manual en línea o descargarlo el formato electrónico. S a li r : esta opción permite que el usuario cierra su sesión y salga del sistema. 5. Creación y Selección de Proyectos En este ítem explicara cómo crear o seleccionar proyectos existentes en la sistema. 5.1. Creación de un proyecto nuevo Cualquier usuario registrado en el sistema es capaz de crear un nuevo proyecto y, de esa manera, convertirse en el líder (o propietario) del mismo. La creación de nuevo proyecto se lleva a cabo haciendo clic en la opción “P ro ye c tos ” . Luego de hacer esto el usuario puede ver el siguiente formulario, presentado en la Figura A2.4: Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 113 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A2.4. Formulario de creación de un nuevo proyecto Para crear un nuevo proyecto, en la sección "c re a r p ro ye c to " el usuario debe: Escribir un nombre para el proyecto. Hacer clic en el botón “Cre a r ”. Una vez realizada esta tarea el sistema DAMVE crea el proyecto y le presenta al usuario la pantalla de gestión del proyecto. 5.2. Selección de un proyecto existente Para seleccionar un proyecto existente en el sistema debe hacerse clic en la opción “P ro ye c tos ” . Luego de hacer esto el usuario puede ver una lista con los proyectos existentes en el sistema. La Figura A2.5 muestra esta lista: Figura A2.5. Pantalla de selección de un proyecto La información que se presenta es la siguiente: Fecha: fecha en la cual se creó el proyecto. Descripción: nombre del proyecto. Creador: e-mail del usuario creador del proyecto evaluaciones: cantidad de evaluaciones que se han realizado en dicho proyecto. Rol: corresponde al rol del usuario con respecto a dicho proyecto, representado por iconos. El icono significa que el usuario es el líder del proyecto, el icono significa que el usuario de colaborador en el proyecto y el icono significa que el usuario es visitante en dicho proyecto. Haciendo clic en la fecha, descripción o rol de un proyecto el usuario puede acceder a la pantalla de gestión del proyecto. 6. Roles de los usuarios Antes de continuar explicando los pasos a seguir para poder crear evaluaciones de viabilidad en la proyectos es necesario presentar los distintos roles que los usuarios pueden tener dentro del sistema DAMVE. La Tabla 1 presenta los roles Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 114 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ de los usuarios en el sistema ordenados por jerarquía, comenzando por el rol de menor jerarquía (visitante) y llegando hasta el rol con mayor jerarquía (Administrador): Nombre del rol Acciones dentro del sistema Visitante Cualquier usuario que haya ingresado el sistema es considerado visitante. Puede consultar los proyectos existentes, los miembros pertenecientes a los proyectos y la cantidad de evaluaciones de viabilidad realizadas. No puede conocer los resultados de las evaluaciones de viabilidad. Cualquier usuario que haya sido designado como colaborador de un proyecto por el líder del mismo. Como tal puede crear evaluaciones de viabilidad. Un colaborador de un proyecto no puede continuar la ejecución de evaluaciones creadas por otro colaborador del mismo proyecto. Cualquier usuario visitante que dé de alta un proyecto se convierte en el líder del mismo. Como tal puede crear evaluaciones de viabilidad y designar a otros usuarios como colaboradores. Cualquier usuario que haya sido designado como evaluador por el administrador. Tiene la capacidad de modificar la plantilla de evaluación del estudio de viabilidad. Es el usuario responsable de la administración del sistema. Puede designar a los usuarios evaluadores. Colaborador del Proyecto Líder del Proyecto Evaluador Administrador Tabla 1. Roles de los usuarios Un mismo usuario puede tener dentro del sistema uno o varios roles. Por ejemplo, un usuario puede ser líder del proyecto 1 por haberlo creado, colaborador del proyecto 2 porque su líder lo ha designado, visitante en el resto de los proyectos y evaluador porque el administrador lo ha designado. 7. Gestión de un Proyecto Una vez creado un nuevo proyecto o seleccionado de la pantalla de selección de proyecto, el usuario accede a la pantalla de gestión del proyecto. La Figura A2.6 presenta dicha pantalla: Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 115 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A2.6. Pantalla de gestión del proyecto En esta pantalla puede observarse toda la información relativa al estudio de viabilidad del proyecto, organizada por secciones. Se c ci ón g e ne r a l : se presenta el Nombre del proyecto, la fecha de creación y el usuario propietario, o líder. Co la b o ra d o re s : se presentan los e-mails de todos los usuarios designados por el líder del proyecto para crear evaluaciones de viabilidad. Ev a lu a ci one s : se presenta una tabla que muestra la información resumida de cada uno de los estudios de viabilidad realizados para este proyecto, ordenados en forma cronológica descendente, lo que permite visualizar la evolución de la viabilidad del proyecto. La tabla presenta la fecha de creación, la descripción, el usuario creador y el resultado de cada una de las evaluaciones. Si la evaluación ha sido completada se muestra en la tabla el resultado final en forma gráfica y numérica. Sin evaluación no ha sido completada todavía se muestran la tabla el texto “Incompleto”. En el caso de que un usuario visitante acceda a un proyecto del cual no es miembro (ni líder ni colaborador) el sistema no mostrara el resultado de ninguna evaluación. 7.1. Agregar colaborador al proyecto El líder del proyecto puede agregar un colaborador al mismo, completando el formulario “A g re g a r co l a bo r a do r al p ro ye ct o ” que se presenta en la pantalla de gestión del proyecto. La Figura A2.7 muestra dicha pantalla: Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 116 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A2.7. Formulario agregar colaborador al proyecto Para agregar un colaborador al proyecto, el líder debe: Escribir el e-mail del usuario colaborador. Hacer clic en el botón “Ag re g a r co l a bo r a do r ”. Una vez realizada esta tarea el sistema DAMVE agrega al usuario como colaborador del proyecto. 7.2. Eliminar un colaborador El líder de un proyecto puede eliminar a cualquier colaborador que haya agregado previamente. Para esto debe hacer clic en el icono que se encuentra al lado del e-mail de cada colaborador. El sistema le pedirá una confirmación y, si el líder del proyecto contesta afirmativamente, el colaborador será eliminado de ese proyecto, convirtiéndose en visitante. 7.3. Crear una nueva evaluación El líder del proyecto y los usuarios colaboradores pueden crear una nueva evaluación de viabilidad para el proyecto, completando el formulario “cre a r nue va e v a l ua ci ón ” que se presenta en la pantalla de gestión del proyecto. Figura A2.7. Formulario crear nueva evaluación Para crear una nueva evaluación, el usuario miembro del proyecto debe: Escribir una descripción para la evaluación. Hacer clic en el botón “c re ar n ue va e v a lu a c ión ”. Una vez realizada esta tarea el sistema DAMVE crea una nueva evaluación para el proyecto y le muestra al usuario la pantalla de ejecución de la evaluación. 7.4. Imprimir la gestión del proyecto Para imprimir la información de gestión del proyecto el usuario debe hacer clic en el botón “Imp r im i r ” que se encuentra en el borde superior derecho de la pantalla. Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 117 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ El sistema preparará una versión adaptada para impresión de la pantalla que facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo de impresión del navegador web. 7.5. Exportar la gestión del proyecto Para exportar la información de gestión del proyecto a un archivo separado por comas (.csv) el usuario debe hacer clic en el botón “Expo r ta r ” que se encuentra en el borde superior derecho de la pantalla. El sistema generará un archivo .csv que el usuario podrá descargar y visualizar en cualquier planilla de cálculo o editor de texto. 8. Ejecución de evaluaciones Hasta el momento se ha presentado la forma de crear proyectos, agregar colaboradores al mismo y crear evaluaciones. En este ítem se mostrará la forma de ejecutar las evaluaciones a través de un cuestionario guiado. Una vez que un miembro del proyecto cree una nueva evaluación, el sistema DAMVE presenta la pantalla de ejecución de la evaluación. La Figura A2.8 presenta dicha pantalla: Figura A2.8. Pantalla de ejecución de la evaluación La ejecución de una evaluación de viabilidad es simple: 1. El sistema le presenta al usuario una pregunta relacionada a un aspecto particular de la metodología P3TQ. 2. El usuario debe responderla en relación a la información con la que cuenta del proyecto que está evaluando. Para esto puede utilizar el mouse para elegir la opción que considere correcta y hacer clic en el botón siguiente. Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 118 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ 3. 4. Alternativamente, para hacer más dinámica la interacción, el usuario puede seleccionar la opción correcta con las flechas del cursor y presionar la tecla ENTER. El sistema procesará la respuesta del usuario y le presentará la próxima pregunta. Además, en la sección "pr e g u nt as re s p on di d as " el sistema muestra todas las preguntas que el usuario ha respondido. A llegar a la última pregunta el sistema siendo capaz de calcular la viabilidad del proyecto en base a las respuestas del usuario, le presenta la pantalla de resultado de la evaluación. 8.1. Abandonar y Retomar evaluaciones No es necesario que el usuario complete una evaluación en una única sesión, pudiendo abandonar la ejecución de una evaluación en cualquier momento. Para retomar una evaluación incompleta, el usuario miembro del proyecto debe seleccionar el proyecto en la pantalla de selección de proyectos y, en la pantalla de gestión del proyecto buscar en la tabla de evaluaciones, que se presenta en la Figura A2.9, la evaluación que ha dejado incompleta. Figura A2.9. Retomar una evaluación incompleta Una vez hecho esto debe hacer clic en el icono , que le permitirá volver a la pantalla de ejecución de la evaluación, retomando el cuestionario desde dónde lo abandonó. 9. Resultado de las evaluaciones Una vez que se ha completado el cuestionario de evaluación el sistema le presenta al usuario de resultado obtenido. La Figura A2.10 muestra un ejemplo de resultado de evaluación: Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 119 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A2.10. Pantalla de resultado de una evaluación El sistema muestra los siguientes resultados: Di me nsi ón j ust if i c a c ión : presenta el vector justificación y, en forma gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. Di me nsi ón A d a pt a bi li da d : presenta el vector adaptabilidad y, en forma gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. Di me nsi ón P l au si bi li da d : presenta el vector plausibilidad y, en forma gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. Di me nsi ón É xit o : presenta el vector éxito y, en forma gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. V ia bi li d ad : presenta el vector viabilidad, que es un promedio de las cuatro dimensiones anteriores y, en forma gráfica, el módulo de este vector que sintetiza el resultado final de la evaluación. Si el resultado del cálculo del módulo de un vector es menor a seis, se considera insuficiente y se presenta el resultado gráfico en color rojo. Por el contrario si el módulo es mayor a seis se lo considera aceptable y se presenta el resultado gráfico en color verde. Al igual que la pantalla de ejecución de una evaluación del sistema presenta en la sección "p re g u nt as re sp on di da s " todas las preguntas que el usuario ha respondido, permitiendo contar con trazabilidad de la evaluación. 9.1. Imprimir los resultados Para imprimir los resultados de la evaluación de un proyecto el usuario debe hacer clic en el botón “Im p ri mi r ” es encuentra en el borde superior derecho de la pantalla. Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 120 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ El sistema preparará una versión adaptada para impresión del resultado que facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo de impresión del navegador web. 9.2. Exportar los resultados Para exportar los resultados de la evaluación a un archivo separado por comas (.csv) el usuario debe hacer clic en el botón “Expo r ta r ” que se encuentra en el borde superior derecho de la pantalla. El sistema generará un archivo .csv que el usuario podrá descargar y visualizar en cualquier planilla de cálculo o editor de texto. 9.3. Consultar resultados de evaluaciones realizadas Para poder consultar los resultados de una evaluación realizada cualquier miembro del proyecto (líder o colaborador) debe hacer clic en el resultado final de la evaluación que se encuentra en la sección "Eval u a cio ne s " de la pantalla de gestión del proyecto. La Figura A2.11 muestra un ejemplo de dicha pantalla: Figura A2.11. Consultar resultados de evaluaciones realizadas 10. Opciones Avanzadas Las opciones presentadas a continuación pueden ser llevadas a cabo por usuarios con mayor jerarquía en el sistema, debido a los roles que poseen. 10.1. Designar evaluadores El administrador del sistema puede designar usuarios evaluadores, que son capaces de modificar la plantilla de evaluación. Para realizar esta tarea el administrador debe hacer clic en la opción “Eva l u ad o re s ” del menú y completar el formulario “A g re g a r e va lu a do r ” que se Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 121 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ presenta en la pantalla evaluadores. La Figura A2.12 muestra un ejemplo de dicho formulario: Figura A2.12. Formulario para agregar un evaluador Para agregar un nuevo evaluador, el usuario administrador debe: Escribir el e-mail del nuevo valor. Hacer clic en el botón “A g re g a r e v a lu a do r ”. Una vez realizada esta tarea el sistema DAMVE agrega al usuario como evaluador. 10.2. Eliminar un evaluador El administrador puede eliminar a cualquier evaluador que haya sido designado previamente. Para esto debe hacer clic en el icono que se encuentra al lado del e-mail de cada evaluador, en la pantalla evaluadores. El sistema le pedirá una confirmación y, si el administrador contesta afirmativamente, el evaluador será eliminado del sistema. 10.3. Editar la plantilla de evaluación Los usuarios con el rol de evaluadores pueden editar la plantilla de evaluación. Para realizar esta tarea deben hacer clic en la opción "Cue sti on a r io " del menú. A continuación se presenta en la Figura A2.13 la pantalla de edición de la plantilla de evaluación. Figura A2.13. Formulario para editar la plantilla de evaluación Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 122 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ El sistema presenta un formulario por cada pregunta del cuestionario de evaluación. Los parámetros que pueden modificarse en cada formulario es: De s c ri p c ió n : contiene el texto de la pregunta a contestar. P e so : el peso de la pregunta, en un rango de -10 a 10. Di me nsi ón : correspondiente a que dimensión de viabilidad corresponde la pregunta (justificación, éxito, adaptabilidad, plausibilidad) P r óxi m as p r e g u nt as : muestra para cada valor posible de respuesta cual es la próxima pregunta del cuestionario. Esta opción permite que el usuario evaluador pueda navegar el cuestionario. Para esto el usuario evaluador debe hacer clic en el número de la próxima pregunta y el sistema lo llevara hasta el formulario de dicha pregunta. El usar evaluador puede, entonces, modificar cualesquiera de los parámetros del formulario y, haciendo clic en el botón “A ct ua l iz a r ” el sistema guardará los cambios en la plantilla de evaluación. 10.3.1. Preservación de los resultados Cuando una pregunta de la plantilla de evaluación es modificada, todas las evaluaciones de viabilidad de cualquier proyecto utilizarán los nuevos parámetros de dicha pregunta. Las evaluaciones que ya hayan respondido previamente la pregunta conservarán el valor anterior en el resultado. De esta manera se preservan los resultados de viabilidad anteriores a la modificación de la plantilla de evaluación. 10.3.2. Preservación de la secuencia El sistema DAMVE, no permite que se altere la secuencia de las preguntas, debido a que siguen, de manera estricta la metodología P3TQ. Sin embargo, resulta muy útil para un líder de proyecto de explotación de información con experiencia la posibilidad de modificar los parámetros de la pregunta para adecuar la evaluación de debilidad a su entorno de trabajo. 10.4. Inicializar la Base de Datos El administrador del sistema puede reiniciar la base de datos, haciendo clic en la opción “Inicia li z ar ” del menú. Luego de hacer esto el sistema mostrará una pantalla similar a la Figura A2.14, que solicita la confirmación del administrador, dado que esta acción destruye todos los datos que existan en la base de datos y lleva al Sistema DAMVE a su estado original. Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 123 FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ Figura A2.14. Confirmación de Inicialización de la Base de Datos Si el usuario hace clic en el botón “A ce p ta r ” toda la información existente es eliminada y el sistema queda reinicializado. Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 124