Mendez Rodriguez Trabajoprofesional

HERRAMIENTA DE ESTUDIO DE VIABILIDAD PARA PROYECTOS QUE UTILIZAN LA METODOLOGA P3TQ
TRABAJO PROFESIONAL EN INGENIERA EN INFORMTICA
Laboratorio de Sistemas Inteligentes Facultad de Ingeniera Universidad de Buenos Aires
Alumnos:
Pablo Damin MENDEZ Alejandro Daniel RODRIGUEZ Prof. Dr. Ramn GARCIA-MARTINEZ Prof. Dra. Paola BRITOS
Directores:
Mayo 2009
FIUBA LSI Trabajo Profesional en Ingeniera en Informtica Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodologa P3TQ Directores Alumnos Prof. Dr. Ramn GARCA-MARTNEZ Pablo Damin MNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRGUEZ
ndice
Memoria del Trabajo Profesional.................................................................... 1
1. 2. Resumen ........................................................................................................................... 2 Introduccin ..................................................................................................................... 2
2.1. 2.2. 2.3. 2.4. La metodologa SEMMA ................................................................................................................ 3 La metodologa CRISP-DM ............................................................................................................ 4 La metodologa P3TQ...................................................................................................................... 5 Comparacin de las metodologas P3TQ, SEMMA y Crisp-DM................................................... 7
3.
Estudio de viabilidad....................................................................................................... 9
3.1. El mtodo ........................................................................................................................................ 9 3.2. Viabilidad en P3TQ ....................................................................................................................... 11 Modelo para predecir:............................................................................................................................... 17
4. 5. 6.
Conclusiones .................................................................................................................. 22 Futuras mejoras.............................................................................................................. 23 Bibliografa ..................................................................................................................... 23
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE ............. 24

1. 2. Objetivo .......................................................................................................................... 25 Funcionalidad del Sistema ............................................................................................ 26
2.1. 2.2. Evaluacin de proyectos............................................................................................................... 26 Gestin de usuarios ...................................................................................................................... 26 Versin 4 ....................................................................................................................................... 27 Versin 3 ....................................................................................................................................... 27 Versin 2 ....................................................................................................................................... 27 Versin 1 ....................................................................................................................................... 27 Formato ......................................................................................................................................... 27 Requerimientos funcionales ......................................................................................................... 28 Requerimientos no funcionales .................................................................................................... 36 Restricciones ................................................................................................................................. 43 Diagrama de Casos de Uso........................................................................................................... 44 Matriz de trazabilidad Casos de Uso Requerimientos Funcionales ........................................ 45 Realizacin de los Casos de Uso .................................................................................................. 46 La arquitectura Appengine .......................................................................................................... 58 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 Validar Usuario............................................................................................................................. 84 Asignar evaluador ........................................................................................................................ 85
3.
Cambios en la versin ................................................................................................... 27

3.1. 3.2. 3.3. 3.4.
4.
Especificacin de Requerimientos ................................................................................ 27

4.1. 4.2. 4.3. 4.4.
5.
Modelo de anlisis ......................................................................................................... 44

5.1. 5.2. 5.3.
6. 7.
Arquitectura del Sistema............................................................................................... 58

6.1. 7.1. 7.2. 7.3. 7.4. 7.5. 7.6. 7.7.
Diseo de la aplicacin.................................................................................................. 60
8.
Casos de Prueba ............................................................................................................. 84

8.1. 8.2.
8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10.
Actualizar planilla de evaluacin ................................................................................................ 87 Evaluar viabilidad ........................................................................................................................ 88 Crear evaluacin ......................................................................................................................... 100 Consultar proyecto ..................................................................................................................... 101 Consultar Evaluacin ................................................................................................................. 102 Crear Proyecto ............................................................................................................................ 103 Asignar colaborador ................................................................................................................... 104 Inicializar cuestionario ............................................................................................................... 106
9. 10.
Conclusin.................................................................................................................... 108 Posibles mejoras........................................................................................................... 109
Anexo 2. Manual de usuario la Herramienta DAMVE............................. 110

1. 2. 3. 4. 5. Introduccin ................................................................................................................. 111 Requisitos ..................................................................................................................... 111 Acceso al sistema ......................................................................................................... 111 Presentacin de la interfaz .......................................................................................... 112 Creacin y Seleccin de Proyectos.............................................................................. 113
5.1. 5.2. Creacin de un proyecto nuevo ................................................................................................. 113 Seleccin de un proyecto existente ............................................................................................ 114
6. 7.
Roles de los usuarios ................................................................................................... 114 Gestin de un Proyecto ............................................................................................... 115

7.1. 7.2. 7.3. 7.4. 7.5. Agregar colaborador al proyecto ............................................................................................... 116 Eliminar un colaborador............................................................................................................. 117 Crear una nueva evaluacin....................................................................................................... 117 Imprimir la gestin del proyecto ............................................................................................... 117 Exportar la gestin del proyecto ................................................................................................ 118 Abandonar y Retomar evaluaciones .......................................................................................... 119 Imprimir los resultados .............................................................................................................. 120 Exportar los resultados............................................................................................................... 121 Consultar resultados de evaluaciones realizadas...................................................................... 121 Designar evaluadores ................................................................................................................. 121 Eliminar un evaluador................................................................................................................ 122 Editar la plantilla de evaluacin ................................................................................................ 122 Inicializar la Base de Datos ........................................................................................................ 123
8. 9.
Ejecucin de evaluaciones........................................................................................... 118

8.1. 9.1. 9.2. 9.3.
Resultado de las evaluaciones .................................................................................... 119
10.
Opciones Avanzadas ................................................................................................... 121

10.1. 10.2. 10.3. 10.4.
Memoria del Trabajo Profesional
Pg. 1
1.
Resumen
Los actuales proyectos de explotacin requieren el anlisis y ejecucin 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, adems, controlar cada etapa de ejecucin para detectar y corregir desvos y, de esta manera, asegurar su xito. El proyecto en cuestin se enfoca en una metodologa para la realizacin de proyectos de explotacin de la informacin (Data mining) y propone un test de viabilidad acorde a dicha metodologa.
2.
Introduccin
La Explotacin de Informacin se centra en la bsqueda de patrones interesantes en grandes bases de datos. Utiliza tanto tcnicas estadsticas (Anlisis de varianza, Regresin, Prueba chicuadrado, Anlisis de agrupamiento o clustering, Anlisis discriminante, Series de tiempo, etc.) como informticas (Algoritmos genticos, Inteligencia Artificial, Sistemas Expertos, Redes neuronales, etc.) Entre muchos otros ejemplos, la Explotacin de Informacin ha contribuido significativamente en: Las aplicaciones de administracin empresarial basada en la relacin con el cliente. Detectar patrones de fuga y fraudes. Analizar el comportamiento de las personas que interactan en un sistema (por ejemplo Internet) Existen en el mercado actual tres importantes metodologas para llevar a cabo proyectos de explotacin de la informacin, a saber: SEMMA CRISP-DM
Pg. 2
P3TQ Sin importar la metodologa usada, no existe hasta el da de hoy, ningn mtodo de clculo de viabilidad para proyectos de explotacin de la informacin. En este trabajo, se estudia la metodologa P3TQ en particular para especificar un mtodo plausible para el clculo de viabilidad de proyectos de las caractersticas mencionadas.
2.1. La metodologa SEMMA

La primer metodologa 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 dinmica del mtodo SEMMA.
Figura 2.1.1. Metodologa SEMMA
Pg. 3
2.2. La metodologa CRISP-DM

La metodologa CRISP-DM analiza el proceso de explotacin de la informacin en seis fases diferentes (Figura 2.2.1). Aunque en la ilustracin se muestran las interacciones ms comunes entre las fases se pueden establecer relaciones entre cualquiera de ellas [CRISP-DM 2000].
Figura 2.2.1. Fases de la Metodologa CRISP-DM
Pg. 4
2.3. La metodologa P3TQ

La metodologa de D. Pyle se divide en dos etapas, la primera denominada Modelado de Negocio o MII, y la segunda llamada Minera de datos o MIII [Pyle, D. 2003].
Inicio
MII Modelado del Negocio
Metodologa de Modelado (MII)
MIII Preparacin de los Datos (Boxes 9.x)
MIII Minera sobre el modelo (Boxes 11.x)
Metodologa de Minera (MIII)

MIII Refinamiento (Boxes 12.x)
MIII Despliegue (Boxes 13.x)
Fin
Figura 2.3.1. Metodologa de D.Pyle, Etapas del proyecto de explotacin de informacin
Para comenzar la primera etapa Pyle propone cinco posibles puntos de partida en funcin del propsito del proyecto de explotacin de la informacin que se quiere evaluar. De esta manera Pyle considera: 1. Explorar los datos en bsqueda de relaciones tiles. 2. 3. Dada una oportunidad o problema ver cmo puede la explotacin de la informacin encausar a la organizacin hacia una decisin correcta. Simplemente ver qu puede lograr la explotacin de la informacin.
Pg. 5
4. 5.
Utilizar la minera de datos para construir un modelo sobre una situacin particular Dada una situacin estratgica, analizar si la minera de datos puede ser til para explicar la situacin y cules son las opciones de la organizacin para resolverla.
Figura 2.3.2. Metodologa 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 parmetros concernientes a la organizacin y la situacin del proyecto que la metodologa de P3TQ considera, sin embargo estos son tratados de distinta manera segn el punto de partida, para obtener finalmente los datos requeridos para el proyecto de explotacin y los requerimientos reales de las partes interesadas.
Pg. 6
Finalizado el modelo de negocio el siguiente paso es la explotacin de datos, para ello D. Pyle propone los pasos mostrados en la Figura 2.3.3. Cada parte de la metodologa (tanto en MII como en MIII) est desagregada en pasos, estos pasos son denominados Preparacin de los datos boxes, existiendo 3 tipos de ellos: Action Boxes, en donde se decide cul es el
Seleccin de la herramienta
prximo paso a realizar. Discovery Boxes, en donde se analizan los posibles resultados y problemas luego de ejecutar un Action Box. Technique Boxes, que describen minuciosamente cmo debe emplearse una tcnica. 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.
Minera
Refinamiento
Despliegue
Figura 2.3.3. Pasos distinguidos en la metodologa P 3 TQ
Los boxes explican detalladamente los conceptos y/o acciones que se realizan. El grfico mostrado anteriormente permite identificar cules son los Boxes que corresponden a cada etapa de la metodologa. Por ejemplo puede verse en la figura 2.3.1 que los Boxes 9.x corresponden a la etapa de preparacin de los datos en la metodologa de minera MIII.
2.4. Comparacin de las metodologas P3TQ, SEMMA y Crisp-DM

Luego de las investigaciones iniciales, hemos concluido que SEMMA se centra en los aspectos tcnicos de los proyectos de explotacin de datos. Adems est acotada ya que ha sido diseada para ser implementada con los productos SAS. Crisp-DM es ms completa y abierta que SEMMA, pero no llega al detalle de la metodologa P3TQ, ya que nombra etapas del proceso de la explotacin de la informacin, pero no se analizan los pasos, resultados y situaciones que se pueden dar dentro de cada etapa.
Pg. 7
Concluimos que la metodologa P3TQ es la ms completa entre las tres mencionadas (Ver cuadro 2.4.1), y, por lo tanto en la que se centrar el presente trabajo. Dicha metodologa analiza muchas ms variables y ms profundamente que las dems. Para citar un simple y claro ejemplo (considerando que nos encontramos slo en la introduccin de la presentacin de un proyecto y no en su desarrollo) la metodologa considera quines son los interesados en el proyecto en la organizacin, considerando hasta la causa de su inters (Pyle, D. Business Modeling and Data Mining, Technique Box 1: Identify Stakeholders).
CRISPDM SI 6 SI NO NO SI NO NO
SEMMA Permite eleccin totalmente libre de herramientas Cantidad de fases Todas las fases pueden relacionarse Considera motivo del proyecto Considera naturaleza del inters de las partes Considera otros aspectos no tcnicos Identifica claramente las variables sobre las que el proyecto tiene impacto Est detallada paso a paso cada etapa del mtodo NO 5 NO NO 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 metodologas
Pg. 8
3. Estudio de viabilidad
Todo proyecto en el mbito de cualquier rama de la ingeniera debe satisfacer la ecuacin 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. Tambin a veces, por razones inherentes a la naturaleza de un proyecto surge una tercera cuestin que es si es realizable en funcin de las variables que lo definen. Estas tres cuestiones no slo pueden indicar si se debe comenzar o no una inversin econmica para obtener un resultado, sino que adems, 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 bibliografa, aproxima a un valor que nos da la respuesta sobre si es conveniente que un proyecto se ejecute, o siga ejecutndose. Estas caractersticas corresponden en mayor medida al segundo y tercer punto. En comparacin a cualquier otro tipo de proyecto de naturaleza informtica, toma mayor importancia realizar estudios de viabilidad cuando se trata de actividades de explotacin de la informacin. La razn de esta afirmacin, radica en que es comn notar en el cliente un inters incierto, o ms bien, mucho inters, pero sin conocer exactamente qu espera de un proyecto de explotacin de la informacin.
3.1. El mtodo
La metodologa mencionada en [Garca-Martnez, R. y Britos, P. (2004). Sistemas Expertos. Nueva Librera] clasifica tres tipos distintos de caractersticas que definen la viabilidad de un problema, a saber: Booleanos Numricos en un intervalo finito Lingsticos (Conjunto que posee los valores nada, poco, regular, mucho, todo).
Pg. 9
Segn los valores de cada caracterstica del problema se estima si el proyecto es viable o no. Adems cada caracterstica estar ponderada por un peso, que har que incida en mayor o menor medida en la dimensin de un problema. En casos de valores lingsticos son convertidos en valores difusos correspondiente en el intervalo [0,10] como se muestra en la tabla 3.1.1.
Nada Poco Mucho Todo
1,2 2,2
1,2 2,2 3,4 4,4 5,6 6,6 7,8 8,8 7,8 8,8 10 10
Regular 3,4 4,4 5,6 6,6
Tabla 3.1.1 Conversin entre valores lingsticos y valores difusos
Para homogeneizar el problema, los valores booleanos tambin se tratan como lingsticos considerando los valores de la tabla 3.1.2. No S 0 10 0 10 0 10 0 10
Tabla 3.1.2 Conversin entre valores booleanos y valores difusos
Las caractersticas se agruparn segn su naturaleza y llamaremos a cada grupo Dimensin, existiendo cuatro dimensiones a saber: Plausibilidad, xito, Adecuacin y Justificacin. La dimensin Plausibilidad agrupar todas aquellas caractersticas que indican si el desarrollo del proyecto es posible, por ejemplo si existen expertos y estn disponibles, si existen los casos de prueba adecuados, etc. El xito es determinado por caractersticas del problema que generalmente se dan a posteriori del desarrollo, de todas maneras debemos identificar y evaluar estas caractersticas a priori, para ejemplificar podemos mencionar el inters o desinters de un departamento clave de la organizacin, que no sea el sponsor pero si el usuario final (el proyecto sera desarrollado pero nunca utilizado o los usuarios seran reacios, esto sera un fracaso). La dimensin de Justificacin contendr cada caracterstica 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.
Pg. 10
La dimensin de adecuacin, evala si es apropiado resolver el problema mediante el sistema propuesto en este trabajo. Finalmente el clculo del valor de cada dimensin se realiza de la siguiente manera. Dado L el vector de valor lingstico de dimensin 4 (de acuerdo a las tablas 3.1.1 y 3.1.2), Li y Pi el valor difuso y el peso de la caracterstica i respectivamente; la viabilidad de una dimensin j determinada del problema ser determinada por la ecuacin 3.1.1.
Ecuacin 3.1.1. Clculo de viabilidad de una dimensin.
Esta frmula representa la viabilidad para una dimensin j dada. Luego de calcular para las 4 dimensiones (Adecuacin, xito, justificacin y plausibilidad), se calcula la viabilidad total de un problema segn la frmula 3.1.2.
Ecuacin 3.1.2 Viabilidad total
Pj es el peso de cada dimensin, siguiendo la bibliografa propuesta se define que ser: Plausibilidad y adecuacin 8 Justificacin 3 xito 5
3.2. Viabilidad en P3TQ

Todo proyecto de Explotacin de la informacin, tiene como propsito el uso de herramientas sobre datos existentes para obtener relaciones interesantes a la hora de tomar decisiones o crear soluciones. Una caracterstica de los trabajos de explotacin de datos actuales, es que el punto de partida, o ms bien el motivo de su realizacin, no sea un problema en particular a solucionar. Muchos interesados en aplicar explotacin de la
Pg. 11
informacin tienen como objetivo descubrir qu problemas se pueden solucionar con la informacin existente, pero no la solucin de un problema en s. Esta caracterstica, incrementa la necesidad del estudio de viabilidad; ya que al comenzar con un rumbo incierto, es probable terminar en una solucin no deseada luego de haber invertido tiempo de personal calificado y recursos econmicos. Naturalmente no es apropiado este tipo de perspectiva para ningn tipo de proyectos, a pesar que la realidad en la prctica indique que muchos comienzan de esta manera porque el sponsor lo requiere. Como se describi en la seccin 2.3, la metodologa propuesta por D. Pyle, establece dos partes de un proyecto de minera de datos, el Modelado de Negocio y la Metodologa de Minera. Por esta razn analizaremos la viabilidad tomando caractersticas 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 explotacin 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 segn 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 organizacin puede ser interesante aplicar mtodos de explotacin de la informacin. Crear un modelo para un propsito especificado. Planificar escenarios corporativos.
Segn el punto de partida inicial, D. Pyle establece cules son los siguientes pasos a seguir. Por ejemplo el caso ms general, con escasa informacin sobre el negocio, slo llega el conjunto de datos sobre el cual se debe aplicar minera para descubrir relaciones que puedan llegar a ser de inters. En este punto, Pyle, establece
Pg. 12
especficamente el aso ms lgico a seguir: reconocer a los interesados segn cinco categoras: 1. Los que necesitan la realizacin del proyecto. 2. Los que poseen los recursos econmicos. 3. Los que poseen poder de decisin para que el proyecto avance. 4. Los que se benefician con el resultado. Luego se procedera con una entrevista a los interesados, en donde se debe entender cul es la parte relevante de negocio que, justamente, les interesa y discutir con ellos para identificar cul es el proyecto original que alimenta la necesidad de un proyecto de minera. Siguiendo este ejemplo, es nuestro estudio de viabilidad, analiza si: Las partes interesadas estn identificadas. Las partes interesadas tienen disponibilidad de tiempo para avocarse al proyecto. Existen partes interesadas con recursos suficientes. Las caractersticas importantes para las partes interesadas estn identificadas. La parte clave de estos pasos es descubrir y caracterizar cul, cmo y cunto 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 metodologa, interactan mutuamente (figura 3.2.1.1). Por ejemplo, el xito del lanzamiento de un producto depende, obviamente del cliente, pero las caractersticas 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 minera de datos.
Pg. 13
El siguiente paso tiene que ver con los interesados, es notar quin o qu departamento origin el proyecto original y qu esperan a cambio. Hasta aqu, se ha analizado slo un punto de partida de modelado de negocio identificado por D. Pyle, notemos cules son las situaciones que se tienen luego de analizar esta pequea fraccin de la metodologa: 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 situacin especfica, pero el objetivo de la minera sera descubrir si hay algn valor corporativo que se pueda obtener de ellos. Segn la situacin, el nivel de riesgo es distinto. Adems, Pyle especifica una accin para resolver el problema en cada una de estos escenarios. Es objetivo de este trabajo tambin, analizar estas acciones, descubrir acciones implcitas, y determinar el riesgo de realizarlas. El software de Anlisis de viabilidad, ubica al usuario en la situacin de la metodologa de explotacin de datos propuesta por D. Pyle realizando ciertas preguntas. Adaptando la metodologa de D. Pyle al mtodo de clculo de viabilidad (seccin 3.1), se identifica primero a qu dimensin 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 clculo de viabilidad es extendible en este sentido, los puntos mostrados en la tabla son los correspondientes a la versin 1.0 del software. La primer columna indica la dimensin de viabilidad a la cul apunta la pregunta (P: Plausibilidad; A: Adecuacin; E: xito; J: justificacin). La segunda columna indica el Pyle Box (ver seccin 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 cuestin.
3.2.2. Estudio de viabilidad en la metodologa de minera de datos

El desarrollo de modelos aptos para la minera requiere anlisis, interpretacin y cambios sobre los datos de manera cclica. Las acciones a tomar dependen enteramente del problema de negocio y de lo que el experto en minera descubre en ellos.
Pg. 14
Por esta razn debe ser posible realizar tests de viabilidad no slo antes de comenzar la minera, sino tambin a lo largo del desarrollo del proyecto. La metodologa P3TQ, comienza el proceso de minera con la preparacin 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 relacin sea entre el 60 y 90% del esfuerzo total avocado a la minera. Esto, apunta a que el test de viabilidad para la minera 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, adems si poseen muchos valores indefinidos, etc. Las cuestiones mencionadas se reflejan en las preguntas que el sistema de clculo de viabilidad muestra al usuario (tabla 3.2.2.1). Pyle establece los pasos a seguir para la preparacin de los datos en los boxes 9.x. El siguiente punto ms relevante, luego de la preparacin de los datos, es la minera en s, refirindonos 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 minera propuesto en este trabajo tiene una bifurcacin segn los tres tipos de proyectos de explotacin que Pyle identifica: Minera para entender. Minera para clasificar. Minera para predecir. Minera para entender: Cuando la cuestin que motiva el proyecto es entender el por qu de una situacin del negocio en particular, el set de datos limita la respuesta que el encargado de la explotacin de la informacin puede otorgar. Si es posible, la transformacin de variables es normalmente de gran ayuda para la comprensin de los resultados y puede hacer ms rico un modelo. Tomemos como ejemplo de transformacin, establecimientos de una empresa dedicada a la logstica georeferenciados, o sea, puntos en particular con latitud y longitud establecida. Es probable que dada la situacin a entender, no sea de relevancia conocer estos parmetros, pero s la distancia a un punto en particular de cada establecimiento. Naturalmente el minero debera 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 minera. Ya
Pg. 15
que, conociendo la cuestin que se debe explicar, el encargado de la explotacin de la informacin debe analizar previamente: Pueden transformarse los datos de manera que sean importantes para entender la situacin, y tiles para explicar el resultado?, pueden las herramientas elegidas, transformar los datos de manera conveniente?. Adems de los puntos relativos a las variables en s, la explicacin de la situacin (el resultado final del proyecto), contendr tanto implcita o explcitamente las relaciones entre variables que conforman la parte del modelo concerniente a la situacin particular analizada. Estas relaciones son coherentes?, existen variables, donde comnmente se espera un par relacionado, sin estar relacionadas?, estas cuestiones tambin hacen que el riesgo del proyecto aumente o disminuya, son consideradas por este trabajo. Otras cuestiones que influyen directamente en el riesgo de la minera son mucho ms triviales, por ejemplo, si estn elegidas las herramientas y algoritmos para la minera, si se cuenta con un proveedor de dichas herramientas, la capacidad de respuesta en caso necesitar modificaciones. Minera para clasificar: Segn D. Pyle, la clasificacin es un caso especial de lo que comnmente se denomina prediccin, debido a que se intenta predecir a qu clase una instancia de dato pertenece en funcin a ciertos atributos. Se discute el trmino prediccin en el siguiente punto (Minera para predecir). Por ejemplo, un modelo para clasificar muy comn y utilizado muy a menudo pedaggicamente es aquel que en funcin de ciertos atributos de una persona, sta accedera a un crdito otorgado por un banco o no. Estos atributos pueden ser sexo, edad, nivel de estudio, estado civil, regin donde vive, etc. El modelo de clasificacin producir algn tipo de puntuacin en funcin de esos atributos que determine si la persona accede o no al crdito. Sin embargo, ocurre en ciertos casos que la puntuacin producida por la herramienta de minera no es fcil de interpretar. Supongamos que para el caso en cuestin el modelo establezca un resultado booleano de tipo 0= No accede al crdito, 1 = Accede al crdito. Es probable que luego de la minera, la herramienta utilizada calcule un valor entre 1 y 0. Estos casos requieren que el responsable de la explotacin haga una interpretacin y que tenga los medios necesarios para ello. Otra cuestin, 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
Pg. 16
que las proporciones de cada clase son universales. Siguiendo el ejemplo, si se otorga un conjunto donde un 30% acceden al crdito y un 70% no, el modelo interpretar que un 30% de los casos acceden al crdito universalmente. Las cuestiones de los prrafos anteriores, influyen directamente en la viabilidad de un proyecto de minera para clasificar ya que, deben ser elegidas cuidadosamente las herramientas, saber si se podrn interpretar los datos, o estarn 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 minera de clasificacin, 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: Quizs el ms difcil de los tres objetivos que puede tener un proyecto de minera es la prediccin. Un modelo para predecir debe ser capaz de arrojar informacin que no est presente en el set de datos que toma como entrada. Estos resultados salen de la elaboracin 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 dinmica de relaciones que interconectan los objetos representados en los datos. Los datos disponibles no contienen un patrn que describa cmo se comportar el sistema de las circunstancias de inters ya que la combinacin nica de estas circunstancias no ha sucedido an. Y en esta incertidumbre de comportamiento subyace el trabajo que se le encomend al encargado de la explotacin de la informacin. Ya que no existen herramientas de minera para este propsito, 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 evaluacin

Cada paso de la metodologa 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.
Pg. 17
Presentado ya el mtodo de clculo de viabilidad, la metodologa sobre la cual se apoyan los proyectos de explotacin de la informacin que consideramos, analizaremos a continuacin cmo se presenta la metodologa 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 metodologa P3TQ. Como P3TQ no es secuencial, no sern tampoco las preguntas presentadas. Segn lo que el usuario responda se le mostrarn un conjunto de preguntas u otro. Las preguntas de la tabla 3.2.3.1 estn divididas en aquellas que corresponden a la etapa de modelado (Id de la 1 a la 27), las que corresponden a la etapa de minera (27 a 49) y las que manejan la secuencia de la metodologa P3TQ (50 a 57). Notar que todas excepto las del tercer grupo tienen un peso asignado y su dimensin correspondiente en la tabla (P: plausibilidad, A: adaptabilidad, J: justificacin y E: xito). El peso es la ponderacin que tendrn en su dimensin en el clculo de viabilidad. Las preguntas 50 a 57 tienen peso cero, ya que no evalan el proyecto, sino que identifican una situacin particular y en funcin de sus respuestas se mostrar una secuencia de preguntas o no.
Id pregunta Descripcin Peso Dimensin 8 P 8 P 6 E 6 P 0 M 10 E 8 P 6 P 8 P 0 M 5 P Las partes interesadas estn 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 metodologa P3TQ: DB1, AB2, AB3 Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de 2 referencia de la metodologa P3TQ: DB1, AB2, AB3 3 4 Existen partes interesadas con autoridad suficiente dentro de la organizacin para liderar el proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Existen partes interesadas con recursos econmicos suficientes para encarar el proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3
50 El proyecto de explotacin tiene como propsito buscar relaciones de inters? El proyecto original cuenta con el apoyo de la organizacin? Boxes de referencia de la metodologa P3TQ: 5 DB1, AB2, AB3 El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodologa 6 3 P TQ: DB1, AB2, AB3 Existe comunicacin con las partes interesadas del proyecto original? El proyecto original es aquel que 7 origina el proyecto de explotacin que se est evaluando.Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 8 Se cumplieron los objetivos del proyecto original? El proyecto de explotacin tiene como propsito la evaluacin de una situacin de negocio? (anlisis de 51 problema u oportunidad)? Con respecto a la problemtica del negocio del proyecto original: Se han encontrado datos de utilidad para 9 llevar a cabo la minera? El proyecto original es aquel que origina el proyecto de explotacin que se est evaluando.Boxes de referencia de la metodologa P3TQ: AB6 Las partes interesadas han identificado o pueden identificar aquellas caractersticas del negocio 10 importantes, que enmarcan sus expectativas del proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: TB7
5 A
Pg. 18
Id pregunta 11 12 52 13 14 15
Descripcin La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodologa P3TQ: AB6 Los Objetivos y Metas del negocio estn definidos o pueden definirse? Boxes de referencia de la metodologa P3TQ: AB6, TB5 El proyecto de explotacin tiene como propsito descubrir en que partes de la organizacin se puede agregar valor? Estn identificadas por las partes interesadas las relaciones entre las cinco temticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodologa P3TQ: AB11, TB3 Es conocida la relacin entre las cinco temticas claves del negocio (producto, lugar, precio, tiempo y cantidad) y el proceso principal de la organizacin? Boxes de referencia de la metodologa P3TQ: AB11 Esta determinado o puede determinarse cuales de los 26 recursos de gestin (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodologa P3TQ: AB11, MII Tabla 7.1 Esta desarrollado, o es posible desarrollar un esquema de caso de negocio para cada oportunidad significativa? Boxes de referencia de la metodologa P3TQ: AB11
Peso Dimensin 6 J 8 J 0 M 10 E 5 A 5 A 10 E 10 P 0 M 10 E 6 J 10 E 0 M 2 A 6 A 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
16 Existen datos disponibles para explotacin? Boxes de referencia de la metodologa P3TQ: AB11 17
53 Hay otro propsito especifico? Los requerimientos fueron consensuados con las partes interesadas? Boxes de referencia de la metodologa P3TQ: AB9 La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos 19 conocidos? Boxes de referencia de la metodologa P3TQ: AB9 18 20 Existe informacin disponible para la explotacin? Boxes de referencia de la metodologa P3TQ: AB9 54 Se requiere inicialmente un anlisis estratgico para planificar escenarios corporativos? 21 22 23 24 25 26 27 La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodologa P3TQ: AB9 Existe un mapa del escenario estratgico, consensuado con las partes interesadas. .Boxes de referencia de la metodologa P3TQ: AB12 Estn identificadas por las partes interesadas las relaciones entre las cinco temticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodologa P3TQ: AB12 Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la metodologa P3TQ: AB12 Existen o pueden realizarse simulaciones que permitan identificar ambigedades, incertezas, discordancias? Boxes de referencia de la metodologa P3TQ: AB12 Estn caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la metodologa P3TQ: AB12 Esta determinado o puede determinarse cuales de los 26 recursos de gestin (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodologa P3TQ: AB12, MII Tabla 7.1
28 Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodologa P3TQ: DB9.1 El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la 29 metodologa P3TQ: DB9.1 Existen variables con nico valor, o valores vacios en sus instancias? Boxes de referencia de la metodologa 30 3 P TQ: DB9.2 31 Las variables categricas estn documentadas? Boxes de referencia de la metodologa P TQ: DB9.2 32 33 34 35 36 Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodologa P3TQ: DB9.3 Son reconocidas y es posible adecuar variables anacrnicas? Boxes de referencia de la metodologa 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 metodologa P3TQ: DB9.5, TB9.4 Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios ms importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodologa P3TQ: DB9.6
3
Es necesario realizar recodificacin de variables para mejor comprensin del modelo? Boxes de referencia de la metodologa P3TQ: DB9.7 Los conjuntos de variables de entrada y salida estn caracterizadas? Boxes de referencia de la metodologa 37 3 P TQ: AB11.1
Pg. 19
Id pregunta 38 39 40 41 42
Descripcin Los datos estn estructurados o pueden estructurarse para aplicarlos en la herramienta de minera elegida? Boxes de referencia de la metodologa P3TQ: AB11.1 Estn seleccionados los algoritmos de minera adecuados al modelo? Boxes de referencia de la metodologa P3TQ: AB11.3 Existe una herramienta de minera adecuada al modelo y esta disponible? Boxes de referencia de la metodologa P3TQ: AB11.6 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodologa P3TQ: AB11.5 Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodologa P3TQ: AB11.1
Peso Dimensin 6 A 8 A 8 A 8 P 5 P 0 M 8 E 8 E 6 E 0 M 6 E 8 E 0 M 5 E 6 E
55 El objetivo de la explotacin es entender una situacin? Las variables utilizadas en el modelo estn relacionadas con conceptos que son conocidos por las partes 43 interesadas? Boxes de referencia de la metodologa P3TQ: AB11.1, DB11.5 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 metodologa P3TQ: AB11.1, DB11,5 Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodologa 45 3 P TQ: AB11.1 DB11.5 44 56 El objetivo de la explotacin es aplicar una clasificacin? Esta determinado o puede determinarse en la herramienta el tipo de modelo de clasificacin inicial (B: 46 Binario; M : Clases Mltiples o C : Continuo)? Boxes de referencia de la metodologa P3TQ: DB11.6 47 La herramienta elegida soporta el tipo de entrada y el tipo de salida del modelo inicial de clasificacin? Boxes de referencia de la metodologa P3TQ: DB11.6
57 El objetivo de la explotacin es buscar una prediccin? Las herramientas de modelado del sistema estn seleccionadas? Boxes de referencia de la metodologa 48 3 P TQ: TB11.7 Es posible caracterizar las relaciones esenciales entre los conceptos del negocio en las herramientas de 49 prediccin? Boxes de referencia de la metodologa P3TQ: DB11.7 Tabla 3.2.3.1 Cuestionario de viabilidad
Pg. 20
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
Pg. 21
4.
Conclusiones
La metodologa P3TQ es muy rica y tiene como principal ventaja detallar cada paso en funcin 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 fcilmente viable a un proyecto de explotacin de la informacin. Al mismo tiempo reconocemos los distintos tipos dificultades que pueden acarrear un proyecto de explotacin de la informacin. Estas dificultades pueden ser de distinta naturaleza. Se pueden mencionar dificultades de origen tcnico, como la disponibilidad de datos suficientes, la existencia de herramientas adecuadas para el tipo de proyecto que se quiere llevar a cabo, etc. Pero tambin 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 precisin las variables del negocio y la relacin entre ellas, su impacto en los resultados. Todas estas cuestiones deben ser convenientemente analizadas antes de comenzar a utilizar recursos en explotacin de informacin; para conocer la situacin de partida del proyecto y qu se pretende como resultado, la importancia de las personas en la organizacin que quieren ese resultado, cmo se va a presentar dicha informacin, etc. Como agregado, no existe hasta el momento un metodologa para calcular la viabilidad de proyectos de este tipo, creamos en este trabajo una metodologa con dicho propsito basndonos en el clculo de viabilidad propuesto por [Liebowitz 1986; Laufman et al, 1990; Adelman, 1989; 1992; De Antonio y Samper, 1990; Beckam, 1991; Lpez et al 1991]. Adems se desarrollamos una herramienta de arquitectura web que permite estudiar la viabilidad de proyectos de explotacin de informacin desarrollados bajo la metodologa P3TQ a lo largo de todo su ciclo. Dicha herramienta est desarrollada con Goolgle App Engine, un nuevo concepto de programacin web basado en el lenguaje python, y funcionando enteramente (cdigo y persistencia) en los servidores de Google. Se adjunta el manual de usuario y documentacin de desarrollo de la herramienta junto a este documento.
Pg. 22
5.
Futuras mejoras
Si bien la herramienta desarrollada es muy completa, incluyendo seguimiento de proyectos, generacin de distintas evaluaciones para cada trabajo y manejo de usuarios, adems de la funcionalidad bsica; el mtodo propuesto es extensible, pueden reconocerse nuevos puntos de riesgo siguiendo minuciosamente los pasos que D. Pyle describe en la metodologa P3TQ y agregarse a la metodologa. El agregado de nuevos puntos de riesgo no requiere de recodificacin de la herramienta, pero s un agregado cuidadoso en su base de datos, ya que la metodologa P3TQ cumple una secuencia que es respetada en este trabajo.
6. Bibliografa
Pyle, D. (2003). Business Modeling and Data Mining. Morgan Kaufmann Publishers. Garca-Martnez, R. ; Britos, P. (2004). Sistemas Expertos. Nueva Librera. Chapman, P. ; Clinton, J. (2000). CRISP-DM 1.0: Step by Step Data mining Guide. The CRISP-DM consortium; 2000 Martelli, A. (2008). Python, Gua de referencia. Anaya Multimedia. Martelli, A. (2006). Python in a Nutshell. O'Reilly. Prez Lpez, C.; Santin Gonzlez, D. (2006). Data Mining, Soluciones con Enterprise Miner. Alfaomega Grupo Editor. Colomes Fornos, X. (2009); Css Dhtml y Ajax Gua Prctica. Anaya Multimedia. Ochoa, A (2006). Uso de Tcnicas de educcin para el entendimiento del negocio; Tesis de Magster en Ingeniera de Software. Instituto Tecnolgico de Buenos Aires. Google (2008). Gua de Introduccin de Google AppEngine. Disponible en: http://code.google.com/intl/es-ES/appengine/docs/python/gettingstarted/
Pg. 23
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE.
Pg. 24
1. Objetivo
El presente documento tiene como objetivo documentar la herramienta software DAMVE, que permite ingresar las caractersticas de un proyecto que utiliza la metodologa P3TQ, con el objetivo de analizar y evaluar su viabilidad. El documento presenta informacin detallada de cada una de las etapas en el desarrollo de la herramienta, utilizando siempre que sea posible, el estndar UML de modelado de software: Requerimientos funcionales, requerimientos no funcionales y restricciones Modelo de anlisis (casos de uso) Arquitectura Modelo de diseo 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 tcnica de estudio de viabilidad aplicada a la metodologa P3TQ.
Pg. 25
2. Funcionalidad del Sistema

El sistema debe proveer la siguiente funcionalidad:
2.1. Evaluacin de proyectos

Creacin de proyectos que utilizarn o utilizan la metodologa P3TQ. Creacin de evaluaciones asociadas a un proyecto, que permitan evaluar su viabilidad a lo largo del tiempo (desde la etapa de concepcin y durante su ejecucin). Todas las evaluaciones estarn basadas en una plantilla comn 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 evaluacin. En el segundo caso la evaluacin debe presentarse como "en ejecucin". Las evaluaciones de un proyecto deben presentarse de manera que se pueda analizar la evolucin del proyecto a travs de la comparacin de dichas evaluaciones.
2.2. Gestin de usuarios

Deben existir al menos los siguientes roles en el sistema: Lderes de proyecto: son los responsables de la administracin del proyecto pudiendo crear evaluaciones y/o participar en todas las evaluaciones en ejecucin de ese proyecto. Colaboradores de proyecto: son usuarios asignados por el lder del proyecto y su funcin es realizar evaluaciones del proyecto. Un colaborador puede, entonces, crear una evaluacin y completarla hasta obtener el resultado de viabilidad. Un colaborador no puede continuar una evaluacin en ejecucin creada por otro colaborador del mismo proyecto. Evaluador: Es un usuario con mucha experiencia que tiene conocimiento suficiente en proyectos que utilizan la metodologa P3TQ y puede actualizar la plantilla de evaluacin de estudio de viabilidad de proyectos. Administrador: Es responsable de la administracin de la infraestructura y de la base de datos que consume sistema, como as tambin de asignar a los usuarios evaluadores.
Pg. 26
3. Cambios en la versin
A continuacin se presentan las modificaciones realizadas en las distintas versiones del documento, para facilitar la trazabilidad de los cambios.
3.1. Versin 4
Actualizacin del objetivo del documento.
3.2. Versin 3
Actualizacin del objetivo del documento. Se incorporan los casos de prueba, conclusiones y mejoras.
3.3. Versin 2
Se corrigen las referencias en los grficos. Se incorpora la documentacin de paquetes, clases, secuencia, pantallas y despliegue.
3.4. Versin 1
Versin inicial
4. Especificacin 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 seccin 4.2 se desarrolln todos los requerimientos utilizando dicho formato. Los campos a completar en dicho registro son los siguientes: Cdigo: 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 continuacin se enumeran correlativamente segn el tipo (funcional o no funcional). Ej) RF-001 (requisito funcional 1) Relevancia: Se clasifica en Alta, Media o Baja segn la regla de negocio / requerimiento no funcional que describa.
Pg. 27
Clasificacin: 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. Descripcin: descripcin textual del requerimiento. Control de cambios: debe ingresarse por cada cambio la fecha, persona que lo solicita y descripcin del cambio. Todos los cambios son registrados de manera cronolgica ascendente (el primer cambio al comienzo y el ltimo cambio al final). Cdigo Relevancia Clasificacin Descripcin Control de Cambios Fecha Solicitado por Nombre
Descripcin 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 continuacin los requerimientos funcionales del sistema.
Pg. 28
4.2.1. Crear y Actualizar Proyectos

La Figura A1.2 presenta el requerimiento funcional con el formato establecido. Cdigo Relevancia Clasificacin RF-001 Alta Funcional Nombre CREAR Y ACTUALIZAR PROYECTOS
Descripcin El sistema debe permitirle a un usuario registrado crear un nuevo proyecto y convertirse en su lder. La informacin que debe ingresarse y guardarse cuando se crea un proyecto es: Descripcin del proyecto Fecha de creacin Lder del proyecto (usuario que lo crea) Deben respetarse las siguientes reglas: Cualquier usuario registrado en el sistema se convierte en el lder de un proyecto que crea. Control de Cambios Fecha Solicitado por
Figura A1.2. Requerimiento Funcional Crear y Actualizar Proyectos
Pg. 29
4.2.2. Creacin de Evaluaciones

La Figura A1.3 presenta el requerimiento funcional con el formato establecido. Cdigo Relevancia Clasificacin RF-002 Alta Funcional Nombre CREACIN DE EVALUACIONES
Descripcin El sistema debe permitirle al lder del proyecto o a un usuario asignado como colaborador de del mismo crear una nueva evaluacin a partir de la plantilla estndar. La informacin que debe ingresarse y almacenarse cuando se crea una evaluacin es: Proyecto al cual pertenece Descripcin de la evaluacin Fecha de creacin Usuario que la crea (colaborador o lder del proyecto) Una vez que la evaluacin ha sido creada el sistema debe, automticamente, presentar la interfaz para que el usuario pueda comenzar a completar el estudio de debilidad. Una evaluacin puede ser suspendida, quedando en el estado de "en ejecucin". Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.3. Requerimiento Funcional Creacin de evaluaciones
Pg. 30
4.2.3. Continuar con una evaluacin en Ejecucin

La Figura A1.4 presenta el requerimiento funcional con el formato establecido. Cdigo Relevancia Clasificacin RF-003 Media Funcional Descripcin El sistema debe permitirle al usuario creador de una evaluacin que se encuentra en el estado de "en ejecucin " continuar con la misma, presentndole la interfaz correspondiente. Control de Cambios Fecha Solicitado por Descripcin del cambio Nombre CONTINUAR CON EVALUACIN EN EJECUCIN UNA
Figura A1.4. Requerimiento Funcional continuar con una evaluacin en ejecucin
Pg. 31
4.2.4. Mostrar resultados del proyecto

La Figura A1.5 presenta el requerimiento funcional con el formato establecido. Cdigo Relevancia Clasificacin RF-004 Alta Funcional Descripcin El sistema debe presentar una interfaz que le permita a los usuarios que iniciaron sesin navegar un proyecto cualquiera. Si el usuario pertenece a dicho proyecto (siendo su lder o colaborador) podr ver los datos generales del proyecto (descripcin, fecha de creacin, usuario creador, sus colaboradores) y la informacin actualizada y resumida de todas las evaluaciones realizadas, incluyendo el resultado final de cada evaluacin completada, ordenado de manera cronolgica descendente, de manera de poder analizar la evolucin del proyecto en el tiempo. Si existen evaluaciones en ejecucin el sistema debe comunicarlo y proveer una opcin para poder retomar dicha evaluacin. Si el usuario no pertenece al proyecto podr ver solamente los datos generales del proyecto especificados anteriormente y la informacin de las evaluaciones, pero no su resultado final. Control de Cambios Fecha Solicitado por Descripcin del cambio Nombre MOSTRAR PROYECTO RESULTADOS DEL
Figura A1.5. Requerimiento Funcional Mostrar resultados del proyecto
4.2.5. Actualizacin de la Plantilla de Evaluacin

La Figura A1.6 presenta el requerimiento funcional con el formato establecido. Cdigo RF-005 Relevancia Media Clasificacin Funcional Nombre ACTUALIZACIN DE LA PLANTILLA DE EVALUACIN
Descripcin El sistema debe proporcionar una plantilla estndar pre-cargada que permita de avisar evaluaciones de proyectos por los usuarios del sistema. Adems debe proporcionar una interfaz para que el usuario con rol de Evaluador,
Pg. 32
pueda actualizar esta plantilla de evaluacin, ajustando los siguientes parmetros en cada pregunta de la plantilla: Texto de la pregunta Dimensin a la que pertenece Peso Deben respetarse las siguientes reglas: Cuando se actualiza la plantilla estndar las evaluaciones posteriores a dicha actualizacin se realizarn con los cambios. Las evaluaciones que se han completado antes de la actualizacin no reflejarn los cambios realizados. Las evaluaciones que se encuentran "en ejecucin" no reflejarn los cambios en aquellas preguntas ya contestadas; sin embargo s lo harn en las preguntas an no contestadas. Control de Cambios Fecha Solicitado por 05/03/2009 Alejandro Rodrguez Descripcin del cambio 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 Actualizacin de la Plantilla de Evaluacin
Pg. 33
4.2.6. Asignacin de Colaboradores al Proyecto

La Figura A1.7 presenta el requerimiento funcional con el formato establecido. Cdigo Relevancia Clasificacin RF-006 Alta Funcional Descripcin El sistema debe permitirle al lder de un proyecto designar colaboradores para que puedan realizar evaluaciones en dicho proyecto. La informacin que debe ingresarse para poder asignar un colaborador es su nombre de usuario, coincidente con su direccin de correo electrnico. Una vez que esta informacin 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 lder de proyecto al mismo tiempo. El rol de lder de proyecto incluye la funcionalidad de colaborador. Control de Cambios Fecha Solicitado por Descripcin del cambio Nombre ASIGNACIN DE COLABORADORES AL PROYECTO
Figura A1.7. Requerimiento Funcional Asignacin de Colaboradores al Proyecto
Pg. 34
4.2.7. Designacin de evaluadores

La Figura A1.8 presenta el requerimiento funcional con el formato establecido. Cdigo Relevancia Clasificacin RF-007 Alta Funcional Nombre DESIGNACIN DE EVALUADORES
Descripcin El sistema debe permitirle al administrador de sistema designar a aquellos usuarios con el rol de evaluadores. La informacin que debe ingresarse para poder designar a un usuario como evaluador es su nombre de usuario, coincidente con su direccin de correo electrnico. Una vez que esta informacin ha sido provista, los usuarios designados pueden actualizar la plantilla estndar de evaluacin de proyecto. Deben respetarse las siguientes reglas: Todos usuarios evaluadores pueden realizan cambios sobre la nica plantilla estndar. Control de Cambios Fecha Solicitado por
Figura A1.8. Requerimiento Funcional Designacin de evaluadores
Pg. 35
4.3. Requerimientos no funcionales

Los requerimientos no funcionales tienen que ver con caractersticas 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, estndares, etc. Se presentan a continuacin 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. Cdigo RNF001 Relevancia Clasificacin Alta Rendimiento Nombre PROPORCIONAR TIEMPOS RESPUESTA ACEPTABLES DE
Descripcin El sistema debe poseer la capacidad de prestar el servicio con los siguientes niveles aceptables de desempeo, teniendo cuenta la concurrencia de usuarios Tiempo mximo de actualizacin de pantalla durante la ejecucin de una evaluacin a cada usuario: 5 seg. Cantidad mxima de usuarios concurrentes: 20 usuarios Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.9. Requerimiento no Funcional Designacin de evaluadores
Pg. 36
4.3.2. Preveer Contingencias Por Cada Del Sistema

La Figura A1.10 presenta el requerimiento no funcional con el formato establecido. Cdigo RNF002 Relevancia Clasificacin Alta Rendimiento Nombre PREVEER CONTINGENCIAS CAIDA DEL SISTEMA POR
Descripcin El sistema deber prever contingencias que pueden afectar la prestacin estable y permanente del servicio. La siguiente es la lista de las contingencias que se deben tener en cuenta y se pueden considerar crticas: Cada del sistema por volumen de datos excedido en la base. Sobrecarga del sistema por volumen de transferencia de datos a los usuarios. Cada del sistema por sobrecarga de recursos (procesos, memoria). Estas consideraciones implicarn que la infraestructura tcnica sobre la que se implantar el sistema garantice una alta disponibilidad del mismo. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.10. Requerimiento no Funcional Preveer Contingencias Por Cada Del Sistema
Pg. 37
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. Cdigo RNF003 Relevancia Clasificacin Media Capacidad Nombre CONSIDERAR EL CRECIMIENTO ESPERADO EN EL VOLUMEN DE DATOS
Descripcin El sistema deber garantizar el soporte en el crecimiento del volumen de la informacin 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 caractersticas de tecnologa requeridas para afrontar el crecimiento proyectado en el volumen. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.11. Requerimiento no Funcional Considerar El Crecimiento Esperado En El Volumen De Datos
Pg. 38
4.3.4. Parametrizar Las Variables Del Sistema

La Figura A1.12 presenta el requerimiento no funcional con el formato establecido. Cdigo RNF004 Relevancia Clasificacin Media Portabilidad Nombre PARAMETRIZAR LAS VARIABLES DEL SISTEMA
Descripcin El sistema debe permitir que sus variables y eventos de conFigura A1.cin sean parametrizables e independientes del cdigo fuente. La modificacin de los parmetros configurables ser planteada para que el sistema tome sus cambios una vez reiniciado el servidor de aplicaciones y no en tiempo de ejecucin de tal manera que se disminuya el riesgo de perdida de funcionalidad por configuraciones en el vuelo. Se deber emplear la tecnologa estndar propuesta por Appengine de Google. Las variables que se configurarn, o se presentarn en el archivo de configuracin, determinarn fuentes de datos y ubicacin de recursos. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.12. Requerimiento no Funcional Parametrizar Las Variables Del Sistema
Pg. 39
4.3.5. Disear interfaces con el usuario amigables

La Figura A1.13 presenta el requerimiento no funcional con el formato establecido. Cdigo RNF005 Relevancia Clasificacin Media Amigabilidad Nombre DISEAR INTERFACES USUARIO AMIGABLES CON EL
Descripcin El sistema debe poseer una interfaz grfica uniforme a travs del mismo incluyendo pantallas, mens y opciones, tamao de las pantallas, color, tipo de letra y configuracin de los campos de entrada. El diseo debe realizarse guiado por las caractersticas generales, en cuanto a colores institucionales y disposicin de contenidos, encontradas en el sitio web de la organizacin. Las interfaces deben realizarse en idioma castellano; sin perjuicio de lo cual debe evitar traducirse la terminologa tcnica especfica que no posee una traduccin precisa al castellano. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.13. Requerimiento no Funcional Disear 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. Cdigo RNF006 Relevancia Clasificacin Alta Amigabilidad Nombre DESARROLLAR USUARIO MANUAL DE
Descripcin 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 lnea, en formato HTML. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.14. Requerimiento no Funcional Desarrollar manual de usuario

Pg. 40
4.3.7. Codificar con estndares

La Figura A1.15 presenta el requerimiento no funcional con el formato establecido. Cdigo RNF007 Relevancia Clasificacin Alta Portabilidad Nombre CODIFICAR CON ESTANDARES
Descripcin El cdigo fuente del sistema debe cumplir con un estndar de codificacin. El estndar especificado debe considerar puntos como: Estndares de nombres utilizados en todos sus objetos: programas, formas, tablas, campos, ndices, procedimientos, paquetes. Empleo de las caractersticas del IDE Eclipse para el formato del cdigo. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.15. Requerimiento no Funcional codificar con estndares
4.3.8. Permitir niveles de seguridad

La Figura A1.16 presenta el requerimiento no funcional con el formato establecido. Cdigo RNF008 Relevancia Clasificacin Alta Seguridad Nombre PERMITIR NIVELES DE SEGURIDAD
Descripcin El sistema deber permitir que toda su informacin junto con los procesos desarrollados por el mismo tenga controles de acceso acordes con el nivel de privacidad requerido. Los niveles de seguridad estarn determinados por la distribucin jerrquica de los usuarios, a saber: Usuarios Administradores: Acceso total. Usuarios registrados : Podrn tener acceso al informacin, que corresponda con su rol (lder de proyecto, colaborador o evaluador) Control de Cambios Fecha Solicitado por
Pg. 41
Figura A1.16. Requerimiento no Funcional permitir niveles de seguridad
Pg. 42
4.4. Restricciones
Se presentan a continuacin las restricciones del sistema.
4.4.1. Arquitectura del Sistema

La Figura A1.17 presenta la restriccin con el formato establecido. Cdigo Relevancia Clasificacin RST-001 Alta Restricciones Nombre ARQUITECTURA DEL SISTEMA
Descripcin El Sistema debe desarrollarse sobre la Arquitectura Web Appengine de Google debiendo utilizarse exclusivamente recursos de software compatibles con ella. Los requerimientos mnimos de la aplicacin, corriendo en un servidor local se presentan a continuacin. Los requisitos de hardware del servidor pueden variar segn los requerimientos de rendimiento: Procesador 1.0 GHz 512 MB de RAM Los requerimientos mnimos de software y hardware en el equipo cliente son: Navegador web compatible con Javascript (Recomendado IE7 o posterior/Firefox 2.0 o posterior) Conexin a Internet, si la aplicacin se ejecuta en Appspot de Google o Interfaz de Red que soporte el protocolo TCP/IP para una conexin local. Control de Cambios Fecha Solicitado por Descripcin del cambio
Figura A1.17. Restriccin Arquitectura del Sistema
Pg. 43
5. Modelo de anlisis
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 aluacin Asignar Colaborador
Administrador
Asignar ev aluador Lider de Proyecto include include Crear Proyecto
include Validar usuario include Consultar Ev aluacin
include include include
include
Visitante
Consultar Proyecto include Actualizar plantilla de ev aluacin include Ev aluador Colaborador de Proyecto Ev aluar Viabilidad
Crear Ev aluacin
Figura A1.18. Restriccin Arquitectura del Sistema
Pg. 44
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 CU-001 CU-002 CU-003 CU-004 CU-005 CU-006 CU-007 CU-008 CU-009 CU-010 Nombre Validar usuario Asignar evaluador Actualizar planilla de evaluacin Evaluar viabilidad Crear evaluacin Consultar proyecto Consultar evaluacin Crear proyecto Asignar colaborador Inicializar Evaluacin Requerimiento Funcional Id -RF007 RF005 RF003 RF002 RF004 RF004 RF001 RF006 RF005
Figura A1.19. Matriz de trazabilidad Casos de Uso Requerimientos funcionales
Pg. 45
5.3. Realizacin de los Casos de Uso

A continuacin se presenta la realizacin 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 Nombre Fecha Creacin Actores Descripcin Trigger 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 contrasea para autenticarse. 2. El usuario ingresa su nombre y contrasea y presiona el botn ingresar. 3. El sistema verifica los roles que posee el usuario en el sistema (visitante, lder de proyecto, colaborador o evaluador). 4. El sistema notifica al usuario que est autenticado. CU-001.1 1. Si el usuario ingresa su nombre y contrasea de manera incorrecta el sistema lo notifica y le solicita ingresar los datos nuevamente, volviendo a CU001.0 Alta
Pg. 46
CU-001 VALIDAR USUARIO 16/11/2008 El sistema verifica que el usuario posea el rol correcto para realizar una tarea. El usuario intenta realizar una accin en el sistema. Fecha ltima 16/11/2008 modificacin
Flujos alternativos
Excepciones Extensiones Incluye Heredado por Prioridad
Reglas de Negocio Requerimientos especiales Hiptesis 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 Nombre Fecha Creacin Actores Descripcin CU-002 ASIGNAR EVALUADOR 16/11/2008 Fecha ltima 16/11/2008 modificacin
Administrador El administrador del sistema designa a un usuario con el rol de evaluador para que pueda modificar la plantilla estndar de evaluacin. El administrador accede a la opcin agregar evaluador El administrador ha iniciado sesin en el sistema. Un nuevo usuario cuenta con el rol de evaluador. 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
Trigger Precondiciones Postcondiciones Flujo principal
Flujos alternativos Excepciones Extensiones Incluye
CU-002.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. CU-001. Validar Usuario
Pg. 47
Heredado de Prioridad Reglas de Negocio Requerimientos especiales Hiptesis Notas
Alta RF-007 Figura A1.21. Caso de uso asignar evaluador
5.3.3. Actualizar planilla de evaluacin

La Figura A1.22 presenta el caso de uso con el formato establecido. ID Nombre Fecha Creacin Actores Descripcin CU-003 ACTUALIZAR PLANILLA DE EVALUACIN 16/11/2008 Fecha ltima 16/11/2008 modificacin
Evaluador El usuario evaluador actualiza las preguntas de la planilla estndar de evaluacin, es la fuente de las futuras evaluaciones de viabilidad de todos los proyectos. El evaluador accede a la opcin actualizar planilla El usuario debe contar con el rol de evaluador La planilla actualizada de evaluacin estndar 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 informacin de todas las preguntas de la plantilla estndar con la posibilidad de modificar la descripcin, el peso y la dimensin. 3. El evaluador actualiza todos los parmetros de todas las preguntas que consideren necesario y enviar formulario. 4. El sistema actualiza la plantilla estndar y notifica al evaluador
Pg. 48
Flujos alternativos Excepciones Extensiones Incluye Heredado de Prioridad Reglas de Negocio Requerimientos especiales Hiptesis Notas
CU-003.1 el sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. CU-001. Validar Usuario Alta RF-005 Figura A1.22. Caso de uso actualizar planilla de evaluacin
5.3.4. Evaluar viabilidad

La Figura A1.23 presenta el caso de uso con el formato establecido. ID Nombre Fecha Creacin Actores Descripcin CU-004 EVALUAR VIABILIDAD 16/11/2008 Fecha ltima 16/11/2008 modificacin
Lder de proyecto colaborador El sistema le permite al usuario creador de una evaluacin que se encuentra en el estado de "en ejecucin" continuar con la misma, presentndole la interfaz correspondiente. El lder de proyecto o colaborador accede a la opcin continuar evaluacin. El usuario debe contar con el rol de colaborador en el proyecto en el cual desea continuar la evaluacin. La evaluacin queda actualizada con los pasos del cuestionario cargados CU-004.0 1. El sistema verifica que el usuario sea colaborador
Trigger Precondiciones
Postcondiciones Flujo principal
Pg. 49
del proyecto al cual pertenece la evaluacin. 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 dejndolo incompleto. a. El sistema presenta todas las preguntas y respuestas contestadas hasta el momento. b. El sistema presenta un formulario que muestra la prxima pregunta del cuestionario. El colaborador contesta la pregunta. c. 3. Si el usuario completo todo el cuestionario el sistema muestra el resultado de la evaluacin, ejecutando el caso de uso CU-007. Flujos alternativos Excepciones Extensiones Incluye Heredado por Prioridad Reglas Negocio Notas CU-004.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. CU-001. Validar Usuario CU-007. Consultar evaluacin Alta de RF-003 Figura A1.23. Caso de uso evaluar viabilidad
5.3.5. Crear evaluacin

La Figura A1.24 presenta el caso de uso con el formato establecido. ID Nombre Fecha Creacin Actores Descripcin CU-005 CREAR EVALUACIN 16/11/2008 Fecha ltima 16/11/2008 modificacin
Colaborador El sistema le permite al usuario colaborador crear una evaluacin en un proyecto al cual pertenece.
Pg. 50
El colaborador accede a la opcin crear nueva evaluacin. El usuario debe contar con el rol de colaborador en el proyecto en el cual desea crear la evaluacin. La evaluacin queda creada. CU-005.0 1. El sistema verifica que el usuario sea colaborador del proyecto al cual pertenece la evaluacin. De no cumplirse se ejecuta el flujo alternativo CU-005.1. 2. El sistema presenta un formulario para que el colaborador ingrese la descripcin de la evaluacin. 3. El colaborador completa de informacin y enva el formulario. 4. El sistema crea la nueva evaluacin, y ejecuta el caso de uso CU-004, que inicia la evaluacin de viabilidad. CU-005.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. CU-001. Validar Usuario CU-004. Evaluar viabilidad Alta
Flujos alternativos Excepciones Extensiones Incluye Heredado por Prioridad
Reglas de RF-002 Negocio Requerimientos especiales Hiptesis Notas Figura A1.24. Caso de uso Crear evaluacin
5.3.6. Consultar proyecto

La Figura A1.25 presenta el caso de uso con el formato establecido. ID Nombre CU-006 CONSULTAR PROYECTO
Pg. 51
Fecha Creacin Actores Descripcin Trigger Precondiciones Flujo principal
16/11/2008
Fecha ltima 16/11/2008 modificacin
Lder de proyecto Colaborador El sistema le presenta a los miembros del proyecto toda la informacin existente. Un usuario del proyecto ingresa a la opcin consultar proyecto. El usuario debe pertenecer al proyecto(lder o colaborador) CU-006.0 1. El sistema verifica que el usuario sea lder o colaborador del proyecto. De no cumplirse se ejecuta el flujo alternativo CU-006.1. 2. El sistema presenta la siguiente informacin del proyecto al usuario, dando la opcin de que la informacin pueda ser impresa en papel. Fecha de creacin Descripcin Lder Colaboradores Lista de evaluaciones realizadas ordenadas en forma cronolgica descendente (incluye fecha de creacin, colaborador de la creo, descripcin, estado: s est finalizada el resultado de la evaluacin; sino el mensaje en ejecucin). CU-006.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea. CU-001 : Validar Usuario Alta
Postcondiciones Ninguna
Flujos alternativos Excepciones Extensiones Incluye Heredado de Prioridad
Reglas de RF-004 Negocio Requerimientos especiales

Pg. 52
Hiptesis Notas
Figura A1.25. Caso de uso consultar proyecto
5.3.7. Consultar Evaluacin

La Figura A1.26 presenta el caso de uso con el formato establecido. ID Nombre Fecha Creacin Actores Descripcin Trigger Precondiciones CU-007 COSULTAR EVALUACIN 16/11/2008 Fecha ltima 16/11/2008 modificacin
Lder de proyecto Colaborador El sistema le presenta a los miembros del proyecto la informacin de una evaluacin. Un usuario del proyecto ingresa a la opcin consultar Evaluacin. El usuario debe pertenecer al proyecto (lder o colaborador) la evaluacin debe estar finalizada. CU-007.0 1. El sistema verifica que el usuario sea lder o colaborador del proyecto. De no cumplirse se ejecuta el flujo alternativo CU-007.1. 2. El sistema presenta la siguiente informacin de la evaluacin al usuario proveyendo la opcin de imprimir en papel. Fecha de creacin Proyecto al cual pertenece Colaborador de la creo Descripcin Resultado final expresado numrica y grficamente. Todas las preguntas y respuestas de la evaluacin que fueron respondidas y que justifican el resultado. CU-007.1 El sistema notifica al usuario que no cuenta con los
Pg. 53
Postcondiciones Ninguna Flujo principal
Flujos alternativos
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 Hiptesis Notas Figura A1.26. Caso de uso consultar evaluacin
5.3.8. Crear proyecto

La Figura A1.27 presenta el caso de uso con el formato establecido. ID Nombre Fecha Creacin Actores Descripcin Trigger Precondiciones Postcondiciones Flujo principal CU-008 CREAR PROYECTO 16/11/2008 Fecha ltima 16/11/2008 modificacin
Visitante El sistema le permite a un usuario registrado crear un nuevo proyecto y convertirse en su lder. El usuario accede a la opcin crear nuevo proyecto. El proyecto queda creado. CU-008.0 1. El sistema presenta un formulario para que el usuario ingrese la descripcin del nuevo proyecto. 2. El usuario completa de informacin y enva el formulario. 3. El sistema crea el nuevo proyecto. Pg. 54
Flujos alternativos Excepciones Extensiones
Incluye Heredado por Prioridad
CU-001. Validar Usuario Alta
Reglas de RF-001 Negocio Requerimientos especiales Hiptesis 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 Nombre Fecha Creacin Actores Descripcin CU-009 ASIGNAR COLABORADOR 16/11/2008 Fecha ltima 16/11/2008 modificacin
Lder de proyecto El lder de un proyecto designa a un usuario con el rol de colaborador para que pueda crear nuevas evaluaciones en dicho proyecto. El lder del proyecto accede a la opcin agregar colaborador El lder de proyecto ha iniciado sesin en el sistema. Un nuevo usuario cuenta con el rol de colaborador. CU-009.0 1. El sistema verifica que el usuario sea lder 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 lder del proyecto ingresa el e-mail del usuario. 4. El sistema agrega al usuario como colaborador y notifica al lder del proyecto CU-009.1 El sistema notifica al usuario que no cuenta con los permisos suficientes para llevar a cabo la tarea.
Pg. 55
Flujos alternativos
Excepciones Extensiones Incluye Heredado por Prioridad Reglas de Negocio Requerimientos especiales Hiptesis Notas
CU-001. Validar Usuario Alta RF-006
Figura A1.28. Caso de uso asignar colaborador
5.3.10.
ID Nombre
Inicializar cuestionario
CU-010 INICIALIZAR CUESTIONARIO 05/03/2009 Fecha ltima 05/03/2009 modificacin
La Figura A1.29 presenta el caso de uso con el formato establecido.
Fecha Creacin Actores Descripcin
Administrador El administrador del sistema inicializa la Plantilla estndar de evaluacin de proyectos con los valores predeterminados. El administrador accede a la opcin de inicializar Plantilla devaluacin. El administrador ha iniciado sesin en el sistema. La Plantilla estndar de evaluacin de proyectos se encuentra inicializada con los valores por defecto. 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 confirmacin para inicializar la Plantilla de evaluacin con los valores por defecto.
Pg. 56
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 evaluacin con los valores por defecto y notifica al administrador sobre la accin. CU-009.3 El sistema notifica al usuario que no se realiz la inicializacin del cuestionario. CU-001. Validar Usuario Alta RF-005
Excepciones Extensiones Incluye Heredado por Prioridad Reglas de Negocio Requerimientos especiales Hiptesis Notas
Figura A1.29. Caso de uso inicializar cuestionario
Pg. 57
6. Arquitectura del Sistema

6.1. La arquitectura Appengine
La Figura A1.30 presenta un grfico que resume las principales componentes de la arquitectura propuesta por Appengine y que, en lneas generales, respeta el clsico patrn 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 estn completamente acoplados en esta capa (Patrn 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 interaccin del usuario a travs de comandos GET o POST, que se traducen en Requests o pedidos. El controlador se programa segn se requiera y se presentarn los resultados utilizando plantillas (ver a continuacin) a travs de Responses o respuestas.
Pg. 58
Plantillas de Vista: Appengine provee un framework basado en Django para desarrollar las vistas HTML utilizando plantillas (Patrn Template View) y fomentando la reutilizacin y desacople con el modelo de negocio.
Pg. 59
7. Diseo de la aplicacin
En esta seccin se detallar el diseo elegido para implementar el sistema. La tcnica 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 aplicacin y su relacin. 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 describirn las responsabilidades de las clases ms relevantes del paquete. Una vez presentados en detalle cada uno de los paquetes y las clases del sistema se utilizarn diagramas de secuencia que permitan comprender la dinmica del sistema a travs de la interaccin 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 patrn MVC, se disearon los paquetes que interrelacionados implementan la funcionalidad del sistema. La categorizacin por colores que se presenta en la Figura A1.31 ser utilizada de aqu en adelante en este documento, para facilitar la comprensin del mismo. Modelo Vista Controlador Infraestructura
Figura A1.31. Cdigo de color para cada una de las categoras de paquetes de la aplicacin
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 categora pertenecen. Las categoras existentes son las tres definidas en el modelo MVC (modelo, vista y controlador) ms una cuarta denominada infraestructura. Esta cuarta categora en provista por el entorno Appengine e implementa los servicios de base que
Pg. 60
permitan desarrollar una aplicacin dentro de la arquitectura. Algunos de los servicios dentro de la categora son: Persistencia de entidades. Acceso a archivos del sistema operativo. Motor de plantillas para representacin de pgina web dinmicas. Autenticacin de usuarios. Estos servicios son parte de la infraestructura de la aplicacin y, generalmente, son consumidos por una o ms de las tres categoras de MVC.
pd Paquetes dbmodel ev aluatorform + AddMemberPage + Evaluate + MainPage + Answer + Evaluation + EvaluationInstance + Evaluator + NextQuestion + Project + ProjectMember + Question + Result
v iew + CustomView + EvaluationDraw
google.appengine.ext + db + webapp menu + menu + webapp.template
google.appengine.api + users
Infraestructura Modelo
Vista Controlador
Figura A1.32. Diagrama de paquetes de la aplicacin categorizados por color
Por simplicidad para el entendimiento se ha omitido la representacin en el diagrama todos los paquetes de la categora controlador del sistema, incluyendo solamente el paquete controlador evaluatorform. Para una descripcin detallada de cada uno de los paquetes controladores debe leerse la seccin 7.4 de este documento.
Pg. 61
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 categora a travs de su color asociado. Nombre dbmodel Tipo Modelo CU que Descripcin implementa Todos Contiene las clases que implementan el modelo de la aplicacin, incluyendo su persistencia. Implementa funciones genricas de representacin de los datos en formato HTML. Creacin, ejecucin y clculo de una evaluacin de viabilidad para un proyecto. Seleccin de un proyecto. Creacin proyecto. y consulta en
view
Vista
evaluatorform
Controlador CU-004 CU-005 CU-007 Controlador CU-008 Controlador CU-006 CU-009 Controlador CU-002 Controlador CU-001 Controlador CU-003 dos CU-010
choose_project view_project add_evaluator help data
Agregar evaluadores. Inicio y cierre de sesin el sistema. Manual de Usuario. Inicializacin de datos.
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 lgica 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:
Pg. 62
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 dinmica que permite conocer la prxima 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 dinmico. El trmino dinmico se refiere a que el cuestionario cambia segn 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 evaluacin es una instancia de una plantilla de cuestionario, cuyas preguntas son respondidas con algn valor de respuesta admitido y cuya secuencia est determinada por dichos valores. A continuacin se presenta en la Figura A1.34 un grfico esquemtico 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
Pg. 63
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 (vrtices). 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 tambin finaliza ya que no existe arista con ese valor que conduzca a una prxima pregunta. Si llegando a la pregunta cuatro se contestara "s" entonces el cuestionario si continuara 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 slo 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 tcnica de grafos permite una gran flexibilidad al momento de disear los cuestionarios.
7.2.3. Diagrama de Clases

Se ha presentado anteriormente una explicacin coloquial del diseo del modelo en dos niveles. En esta seccin se presentar el modelo de software elegido para implementarlo, a travs de un diagrama de clases UML que se muestra en la Figura A1.35:
Pg. 64
cd Modelo
Provisto por el User API de Appengine
User + 1 + email: Text 1 nickname: Text 1 1 1 db.Model Proj ectMember + + * + idproject: db.ReferenceProperty(Project) member: db.UserProperty role: db.TextProperty() + + + + + + + * + + + Ev aluation 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[] 1 db.Model
1 db.Model Ev aluator + + + + evaluator: db.UserProperty all(Evaluator[]) remove(string) userIsEvaluator(var) 1 db.Model 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
evaluations questions
1 Evaluation Result * db.Model Ev aluationInstance + + + + + + + + + + + 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) 1 1 + + + + + + + + + + + 1 Result 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)
Nivel 2. Estudio de Viabilidad
db.Model Answ er + + description: db.TextProperty idanswer: db.IntegerProperty 1 + + 1 + + + + Nivel 1. Questionario NextQuestion
db.Model Question + + + 1 + + + + + + +
db.Model
idanswer: db.IntegerProperty idnextquestion: db.IntegerProperty idquestion: db.IntegerProperty answer() : Answer nextQuestion() : Question question() : Question
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, categora de la metodologa P3TQ, texto de la pregunta, dimensin de la viabilidad, umbral, tipo y peso). El tipo de pregunta permite conocer cules 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 vrtices del grafo.
Pg. 65
NextQuestion: implementa la relacin 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 prxima pregunta en el cuestionario. Con estos tres atributos puede conocerse cul es la prxima 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 descripcin). El Nivel 2 del modelo est implementado por las siguientes clases: EvaluationInstance: Implementa una pregunta del cuestionario respondida para una evaluacin determinada. Esta clase se encarga de copiar toda informacin de la pregunta que instancia y el valor de respuesta que el usuario haya ingresado. Evaluation: implementa una evaluacin completa realizada por un usuario. Sus atributos son el creador de la evaluacin, la fecha de creacin, su descripcin y su estado actual. La evaluacin permanece abierta mientras no se haya alcanzado una ltima pregunta de cuestionario; y se encuentra cerrada en caso contrario, pudindose conocer el resultado del evaluacin. Esta clase se encarga de obtener la secuencia de preguntas del cuestionario consumiendo las clases del nivel 1. Cuando el cuestionario finaliza posee una operacin calculate() que permite conocer el resultado del evaluacin de viabilidad. Result: Esta clase encapsula el resultado de un estudio de viabilidad, obtenido a partir de una evaluacin completa. Posee cinco atributos correspondientes a los cuatro sectores de las dimensiones del estudio de viabilidad, ms el vector resultado final. Project: esta clase implementa un proyecto en el cual su creador y colaboradores crearn evaluaciones para estimar su viabilidad. Sus atributos son su identificador, su usuario propietario (lder de proyecto), sus miembros colaboradores (implementado a travs de la clase ProjectMember), su descripcin y su fecha de creacin. Evaluator: implementa los usuarios que tienen la capacidad de modificar los atributos del cuestionario de evaluacin. Posee una operacin de clase llamada all(), que permite obtener una coleccin de todos los usuarios con rol de evaluador y una operacin llamada userIsEvaluator() que permite conocer,
Pg. 66
dada una direccin de correo electrnico, 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 + + + + evaluator: db.UserProperty all(Evaluator[]) remove(string) userIsEvaluator(var) 1 1 + + Logical Model:: User email: Text nickname: Text
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)
object CustomMenu + getCustomMenu() : string
Figura A1.36. Diagrama de clases del paquete view
EvaluationDraw: Esta clase tienen la responsabilidad de generar un grfico de barras en cdigo HTML de cada una de las dimensiones de una evaluacin, desacoplando la responsabilidad de dibujo en la clase de dominio. Almacena un objeto de la clase Evaluation (atributo evaluation), el tamao mximo de escala (atributo maxsize). Existe una operacin de clase que funciona como factory para crear una coleccin de objetos EvaluationDraw a partir de una coleccin de objetos Evaluation. El motor de renderizacin de la vista (django), entonces, utiliza objetos EvaluationDraw, con los cuales puede acceder a toda la informacin de una evaluacin y, adems, podr dibujar grfico de barras con dicho informacin. Las operaciones de dibujo son DrawBar, que permite dibujar un grfico de barras genrico, a partir de un valor resultado entre cero y 10. Las operaciones drawP, drawA, drawJ, drawE y drawViability permiten dibujar grfico de barras para las dimensiones de plausibilidad a, adaptabilidad, justificacin, xito y el resultado final de viabilidad respectivamente.
Pg. 67
CustomMenu: esta clase tiene la responsabilidad de generar una coleccin de opciones del men de usuario segn el rol que posea el usuario est ejecutando la aplicacin. Para esto, verifica si el usuario es administrador y/o evaluador y devuelve en la coleccin opciones especficas para estos roles. El motor de renderizacin de la vista recibe siempre una coleccin de opciones que le permite mostrar la funcionalidad especfica 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 informacin 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 continuacin se presentan los diagramas de clase de cada uno de los paquetes que conforman los controladores de la aplicacin.
7.4.1. evaluatorform
La Figura A1.37 muestra las clases que componen este paquete.
Pg. 68
pd ev aluatorform Logical Model:: w ebapp. RequestHandler + + + + + request: response: get() : void put() : void redirect(string) : void
AddMemberPage + + + get() : void put() : void redirect(string) : void + + +
MainPage get() : void put() : void redirect(string) : void + + +
Ev aluate get() : void put() : void redirect(string) : void
v iew _proj ect.html
error.html
ev aluatorform.html
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 evaluacin, a guardar las y presentarle al usuario la prxima pregunta a responder. Evaluate: esta clase tiene la responsabilidad de presentarle al usuario el resultado de un estudio de viabilidad para una evaluacin finalizada.
7.4.2. Add Evaluator

Pg. 69
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 evaluacin de proyectos.
7.4.3. Choose_project
Pg. 70
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 presentrselos 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.
Pg. 71
7.4.4. Help
cd help w ebapp. RequestHandler + + + + + request: response: get() : void put() : void redirect(string) : void
webapp.RequestHandler LogoutPage + + + get() : void put() : void redirect(string) : void
webapp.RequestHandler AboutPage + + + get() : void put() : void redirect(string) : void
webapp.RequestHandler LoginPage + + + get() : void put() : void redirect(string) : void
about.html logout.html
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 sesin en caso de que los datos de ingreso se han correctos. LogoutPage: esta clase tiene la responsabilidad de cerrar la sesin de un usuario.
Pg. 72
7.4.5. View_project
cd v iew _proj ect w ebapp. RequestHandler + + + + + request: response: get() : void put() : void redirect(string) : void
webapp.RequestHandler webapp.RequestHandler webapp.RequestHandler MainPage + + + get() : void put() : void redirect(string) : void
v iew _proj ect.csv
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 informacin de un proyecto y de crear nuevas evaluaciones.
Pg. 73
7.5. Diagramas de Secuencia

A continuacin se presentan los diagramas de secuencia que permiten comprender cmo colaboran las clases de las distintas categoras (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 anloga a las presentadas o son muy simples de implementar por lo cual su representacin grfica no agrega valor. Adems del diagrama se describirn brevemente los escenarios dentro de los cuales transcurre cada secuencia.
7.5.1. Crear Proyecto

Escenario: El usuario ha iniciado sesin en el sistema. Se encuentra frente a la pantalla de seleccin de proyectos y desea crear un nuevo proyecto, completando una descripcin para el mismo y enviando el formulario. Se considera que no ocurren errores o excepciones. A continuacin 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.
Pg. 74
7.5.2. Crear Evaluacin

Escenario: El usuario ha iniciado sesin en el sistema y ha seleccionado un proyecto. Se encuentra frente a la pantalla de consulta de dicho proyecto y desea agregar una nueva evaluacin, ingresando, para ello, una descripcin para la nueva evaluacin y enviando el formulario. Se considera que no ocurren errores o excepciones. A continuacin 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 Logical Model::Evaluation
eval:= <<new>>(idproject,user,description)
put()
q:= questions()
nq:= nextQuestion()
render(idproject,eval,q,nq)
render
Figura A1.43. Diagrama de secuencia Crear evaluacin.
7.5.3. Contestar Pregunta

Escenario: El usuario ha iniciado sesin en el sistema, ha seleccionado un proyecto y ha creado una nueva evaluacin para el mismo, o retomado una evaluacin previamente creada y an no completada. Se encuentra frente a la pantalla de ejecucin de la evaluacin y desea completar la siguiente pregunta del cuestionario. Selecciona entonces la respuesta que considera correcta y enva el formulario. Se considera que no ocurren errores o excepciones. A continuacin se presenta en la Figura A1.44 el diagrama de secuencia.
Pg. 75
sd Contestar Pregunta
db Miembro run evaluatorform:: evaluate
eval :Evaluation
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 evaluacin 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 Evaluacin

Escenario: El usuario ha iniciado sesin en el sistema, ha seleccionado un proyecto y ha seleccionado una evaluacin completa, o retomado una evaluacin previamente creada y an no completada. Se encuentra frente a la pantalla de ejecucin de la evaluacin y desea completar la siguiente pregunta del cuestionario. Selecciona entonces la respuesta que considera correcta y enva el formulario. Se considera que no ocurren errores o excepciones. A continuacin se presenta en la Figura A1.45 el diagrama de secuencia.
sd Calcular Ev aluacin
eval :Evaluation Miembro evaluate evaluatorform:: evaluate [eval.isComplete]: result:= calculate()
render(eval,q,result) Si la evaluacin est completa.
render
Figura A1.45. Diagrama de secuencia Calcular Evaluacin.
Pg. 76
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 continuacin la Figura A1.46 permite ver, a travs de un diagrama de estados UML, como se relacionan entre s a partir de la interaccin del usuario con el sistema.
sm Statecharts
abrir sesin clear login
Logout
edit cerrar sesin
Inicializar plantilla de evaluacin editar plantilla de evaluacin choose_proj ect creacin de un proyecto
agregar evaluador (usuario administrador) ayuda seleccin de un proyecto about add_ev aluator
v iew _proj ect
nueva evaluacin ejecucin de evaluacin
run
carga de pregunta del cuestionario
agregado de nuevo colaborador
seleccin de evaluacin finalizada
evaluacin completa
ev aluate
Figura A1.46. Diagrama de estados para la transicin entre las pantallas del sistema.
A continuacin 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 an no sea autenticado, o cuando decide salir, cerrando la sesin.
Pg. 77
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 travs de su email y contrasea.
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 creacin, la descripcin, el e-mail del lder 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 informacin existente. Tambin 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 informacin referente a un proyecto que l ha seleccionado. Muestra la informacin de fecha de creacin, lder de proyecto, colaboradores y evaluaciones realizadas. Para estas ltimas muestra la fecha de creacin, descripcin, autor y, si
Pg. 78
han sido finalizadas, el resultado. Tambin provee interfaces para crear una nueva evaluacin en dicho proyecto, agregar colaboradores al proyecto en caso de que el usuario sea el lder y opciones para exportar la informacin 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 evaluacin. Muestra el nombre proyecto, el nombre de la evaluacin, la dimensin, peso y descripcin de la pregunta y las opciones de respuesta.
Figura A1.51. Pantalla run.
Pg. 79
7.6.6. Evaluate
Esta pantalla, presentada en la Figura A1.52, se muestra cuando el usuario miembro del proyecto selecciona una evaluacin finalizada, o cuando contesta la ltima pregunta del cuestionario. Presenta el resultado del estudio de viabilidad mostrando los valores de los vectores justificacin, adaptabilidad, plausibilidad, xito y viabilidad y tambin el mdulo de cada uno de ellos numrica y grficamente. 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 informacin.
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 informacin.
Figura A1.53. Pantalla add evaluator.

Pg. 80
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 evaluacin de proyectos. Muestra la informacin de cada preguntas del cuestionario, que puede ser modificada y enlaces que dirigen a la prxima pregunta segn 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 informacin sobre la versin en ejecucin 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 informacin del sistema de inicializar la plantilla de evaluacin de proyectos.
Pg. 81
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 sesin 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 sesin en el sistema a la pantalla about. Salir: conduce a cualquier usuario que inici sesin en el sistema a la pantalla logout.
7.7. Diagrama de Despliegue

El despliegue de la aplicacin 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.
Pg. 82
El cliente se comunica con el servidor a travs 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.
Pg. 83
8. Casos de Prueba
En esta seccin se desarrollan los casos de prueba planificados y ejecutados satisfactoriamente que surgen de los escenarios ms importantes de cada caso de uso.
8.1. Validar Usuario

A continuacin se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-001 : Validar usuario.
8.1.1. Inicio de sesin exitoso

La Figura A1.59 nuestra el caso de prueba inicio de sesin exitoso. Identificacin CP-001 : Inicio de sesin exitoso Caso de Uso CU-001 que lo origina Escenario El usuario intenta iniciar sesin en el sistema. Datos Entrada Resultado Esperado Estado de El usuario ingresa un e-mail y contrasea vlidos (cuentas activas en google) El usuario inicia sesin el sistema. Ejecutado correctamente.
Figura A1.59. Caso de prueba inicio de sesin exitoso
8.1.2. Inicio de sesin fallido

La Figura A1.60 nuestra el caso de prueba inicio de sesin fallido. Identificacin CP-002: Inicio de sesin fallido Caso de Uso CU-001 que lo origina Escenario El usuario intenta iniciar sesin en el sistema. Datos Entrada de El usuario ingresa las siguientes combinaciones de e-mail y contrasea: E-mail vlido y contrasea invlida. E-mail y contrasea invlidas. E-mail invlido y contrasea de algn usuario vlido. E-mail y contrasea nulos.
Pg. 84
E-mail nulo y contrasea correcta. E-mail vlido y contrasea nula. Resultado Esperado Estado El sistema notifica error en el inicio de sesin. Ejecutado correctamente.
Figura A1.60. Caso de prueba inicio de sesin fallido
8.2. Asignar evaluador

A continuacin 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. Identificacin 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 Resultado Esperado Estado de El administrador ingresa un e-mail vlido (cuenta activa en google) 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. Identificacin 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 vlido, que ya fue
Pg. 85
Entrada Resultado Esperado Estado
registrado previamente (cuenta activa en google) 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. Identificacin 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 Estado de El administrador enva el formulario sin ingresar un e-mail El sistema notifica que el e-mail no es vlido, debido a que es nulo. 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. Identificacin 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 accin. Ejecutado correctamente.
Figura A1.64. Caso de prueba Usuario intenta agregar evaluador
Pg. 86
8.3. Actualizar planilla de evaluacin

A continuacin se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-003 : Actualizar planilla de evaluacin.
8.3.1. Evaluador actualiza pregunta

La Figura A1.65 nuestra el caso de prueba Evaluador actualiza pregunta. Identificacin 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 evaluacin. Datos Entrada de El usuario evaluador modifica los siguientes datos de las preguntas: modifica el texto de la Descripcin modifica el peso (valor entero entre 0 y 10) modifica la dimensin El sistema actualiza los datos de la pregunta y notifica al usuario. Ejecutado correctamente.
Figura A1.65. Caso de prueba Evaluador actualiza pregunta
Resultado Esperado Estado
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. Identificacin 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 evaluacin. Datos Entrada de El usuario evaluador modifica los datos de las preguntas, con cada uno de los valores enunciados a continuacin : descripcin nula peso incorrecto (mayor a 10 y/o alfanumrico) El sistema y notifica al usuario que los datos ingresados son incorrectos.
Pg. 87
Resultado Esperado
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. Identificacin 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 evaluacin. Datos Entrada Resultado Esperado Estado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la accin. Ejecutado correctamente.
Figura A1.67. Caso de prueba Usuario intenta actualizar pregunta
8.4. Evaluar viabilidad

A continuacin 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. Identificacin 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 ejecucin de una evaluacin 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 Justificacin = (10;10;10;10) Resultado Justificacin = 10 Vector xito = (10;10;10;10) Resultado xito = 10 Vector adaptabilidad = (10;10;10;10)
Pg. 88
Resultado adaptabilidad = 10 Vector plausibilidad = (10;10;10;10) Resultado plausibilidad = 10 Vector Viabilidad = (10;10;10;10) Resultado viabilidad = 10 Estado 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. Identificacin 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 ejecucin de una evaluacin creada por l. Datos Entrada de El miembro del proyecto contesta las preguntas con los valores indicados a continuacin: Las partes interesadas estn 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 metodologa P3TQ: DB1, AB2, AB3 Mucho Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3: Mucho Existen partes interesadas con autoridad suficiente dentro de la organizacin para liderar el proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Poco Existen partes interesadas con recursos econmicos suficientes para encarar el proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Poco El proyecto de explotacin tiene como propsito buscar relaciones de inters? No El proyecto de explotacin tiene como propsito la
Pg. 89
evaluacin de una situacin de negocio? (anlisis de problema u oportunidad)? Si Con respecto a la problemtica del negocio del proyecto original: Se han encontrado datos de utilidad para llevar a cabo la minera? El proyecto original es aquel que origina el proyecto de explotacin que se est evaluando. Boxes de referencia de la metodologa P P3TQ: AB6 Poco Las partes interesadas han identificado o pueden identificar aquellas caractersticas del negocio importantes, que enmarcan sus expectativas del proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: TB7 No La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodologa P3TQ: AB6 Poco Los Objetivos y Metas del negocio estn definidos o pueden definirse? Boxes de referencia de la metodologa P3TQ: AB6, TB5 Poco Se requiere inicialmente un anlisis estratgico para planificar escenarios corporativos? Si La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodologa P3TQ: AB9 Poco Existe un mapa del escenario estratgico, consensuado con las partes interesadas. .Boxes de referencia de la metodologa P3TQ: AB12 No Estn identificadas por las partes interesadas las relaciones entre las cinco temticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodologa P3TQ: AB12 No Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la No metodologa P3TQ: AB12
Pg. 90
Existen o pueden realizarse simulaciones que permitan identificar ambigedades, incertezas, discordancias? Boxes de referencia de la metodologa P3TQ: AB12 No Estn caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la metodologa P3TQ: AB12 No Esta determinado o puede determinarse cuales de los 26 recursos de gestin (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodologa P3TQ: AB12, MII Tabla 7.1 Poco Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodologa P3TQ: DB9.1 No El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la metodologa P3TQ: DB9.1 No Existen variables con nico valor, o valores vacios en sus instancias? Boxes de referencia de la metodologa P3TQ: DB9.2 Mucho Las variables categricas estn documentadas? Boxes de referencia de la metodologa P3TQ: DB9.2 Poco Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodologa P3TQ: DB9.3 Poco Son reconocidas y es posible adecuar variables anacrnicas? Boxes de referencia de la metodologa 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 metodologa P3TQ: DB9.5, TB9.4 No Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios ms
Pg. 91
importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodologa P3TQ: DB9.6 No Es necesario realizar recodificacin de variables para mejor comprensin del modelo? Boxes de referencia de la metodologa P3TQ: DB9.7 Si Los conjuntos de variables de entrada y salida estn caracterizadas? Boxes de referencia de la metodologa P3TQ: AB11.1 Si Los datos estn estructurados o pueden estructurarse para aplicarlos en la herramienta de minera elegida? Boxes de referencia de la metodologa P3TQ: AB11.1 Poco Estn seleccionados los algoritmos de minera adecuados al modelo? Boxes de referencia de la metodologa P3TQ: AB11.3 No Existe una herramienta de minera adecuada al modelo y est disponible? Boxes de referencia de la No metodologa P3TQ: AB11.6 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodologa P3TQ: AB11.5 Poco Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodologa P3TQ: AB11.1 No El objetivo de la explotacin es entender una situacin? No El objetivo de la explotacin es aplicar una clasificacin? No El objetivo de la explotacin es buscar una prediccin? No Resultado Esperado El sistema muestra como resultado de viabilidad: Vector Justificacin = (1.20 ; 2.20 ; 3.40 ;2.80) Resultado justificacin =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)
Pg. 92
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 Estado 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. Identificacin 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 ejecucin de una evaluacin creada por l. Datos Entrada de El miembro del proyecto contesta las preguntas con los valores indicados a continuacin: Las partes interesadas estn 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 metodologa P3TQ: DB1, AB2, AB3 Regular Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Mucho Existen partes interesadas con autoridad suficiente dentro de la organizacin para liderar el proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Mucho Existen partes interesadas con recursos econmicos suficientes para encarar el proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Regular El proyecto de explotacin tiene como propsito buscar relaciones de inters? No El proyecto de explotacin tiene como propsito la
Pg. 93
evaluacin de una situacin de negocio? (anlisis de problema u oportunidad)? Si Con respecto a la problemtica del negocio del proyecto original: Se han encontrado datos de utilidad para llevar a cabo la minera? El proyecto original es aquel que origina el proyecto de explotacin que se est evaluando..Boxes de referencia de la metodologa P3TQ: AB6 Regular Las partes interesadas han identificado o pueden identificar aquellas caractersticas del negocio importantes, que enmarcan sus expectativas del proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: TB7 Si La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodologa P3TQ: AB6 Regular Los Objetivos y Metas del negocio estn definidos o pueden definirse? Boxes de referencia de la metodologa P3TQ: AB6, TB5 Regular Se requiere inicialmente un anlisis estratgico para planificar escenarios corporativos? Si La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos conocidos? Boxes de referencia de la metodologa P3TQ: AB9 Regular Existe un mapa del escenario estratgico, consensuado con las partes interesadas. .Boxes de referencia de la metodologa P3TQ: AB12 Si Estn identificadas por las partes interesadas las relaciones entre las cinco temticas clave del negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodologa P3TQ: AB12 Si Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la Si metodologa P3TQ: AB12
Pg. 94
Existen o pueden realizarse simulaciones que permitan identificar ambigedades, incertezas, discordancias? Boxes de referencia de la metodologa P3TQ: AB12 No Estn caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la metodologa P3TQ: AB12 Si Esta determinado o puede determinarse cuales de los 26 recursos de gestin (Consultar la tabla 7.2 de MII de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodologa P3TQ: AB12, MII Tabla 7.1 Regular Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodologa P3TQ: DB9.1 Si El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la metodologa P3TQ: DB9.1 Si Existen variables con nico valor, o valores vacios en sus instancias? Boxes de referencia de la metodologa P3TQ: DB9.2 Regular Las variables categricas estn documentadas? Boxes de referencia de la metodologa P3TQ: DB9.2 Regular Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodologa P3TQ: DB9.3 Mucho Son reconocidas y es posible adecuar variables anacrnicas? Boxes de referencia de la metodologa 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 metodologa P3TQ: DB9.5, TB9.4 Si Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios ms
Pg. 95
importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodologa P3TQ: DB9.6 Si Es necesario realizar recodificacin de variables para mejor comprensin del modelo? Boxes de referencia de la metodologa P3TQ: DB9.7 No Los conjuntos de variables de entrada y salida estn caracterizadas? Boxes de referencia de la metodologa P3TQ: AB11.1 Si Los datos estn estructurados o pueden estructurarse para aplicarlos en la herramienta de minera elegida? Boxes de referencia de la metodologa P3TQ: AB11.1 Regular Estn seleccionados los algoritmos de minera adecuados al modelo? Boxes de referencia de la metodologa P3TQ: AB11.3 No Existe una herramienta de minera adecuada al modelo y est disponible? Boxes de referencia de la Si metodologa P3TQ: AB11.6 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodologa P3TQ: AB11.5 Regular Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodologa P3TQ: AB11.1 No El objetivo de la explotacin es entender una situacin? No El objetivo de la explotacin es aplicar una clasificacin? No El objetivo de la explotacin es buscar una prediccin? No Resultado Esperado El sistema muestra como resultado de viabilidad: Vector Justificacin = (3.40 ; 4.40 ; 5.60 ;6.60) Resultado Justificacin = 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)
Pg. 96
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 Estado 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. Identificacin 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 ejecucin de una evaluacin creada por l. Datos Entrada de El miembro del proyecto contesta las preguntas con los valores indicados a continuacin: Las partes interesadas estn 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 metodologa P3TQ: DB1, AB2, AB3 Mucho Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Poco Existen partes interesadas con autoridad suficiente dentro de la organizacin para liderar el proyecto de explotacin? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Mucho Existen partes interesadas con recursos econmicos suficientes para encarar el proyecto? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Mucho El proyecto de explotacin tiene como propsito buscar relaciones de inters? Si
Pg. 97
El proyecto original cuenta con el apoyo de la organizacin? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Mucho El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Todo (Si) Existe comunicacin con las partes interesadas del proyecto original? El proyecto original es aquel que origina el proyecto de explotacin que se est evaluando..Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3 Todo (Si) Se cumplieron los objetivos del proyecto original? Mucho Se requiere inicialmente un anlisis estratgico para planificar escenarios corporativos? No Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodologa P3TQ: DB9.1 Si El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la metodologa P3TQ: DB9.1 Si Existen variables con nico valor, o valores vacios en sus instancias? Boxes de referencia de la metodologa P3TQ: DB9.2 Muy poco o nada (No) Las variables categricas estn documentadas? Boxes de referencia de la metodologa P3TQ: DB9.2 Mucho Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la metodologa P3TQ: DB9.3 Mucho Son reconocidas y es posible adecuar variables anacrnicas? Boxes de referencia de la metodologa 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
Pg. 98
entrenamiento y otro de testeo? Boxes de referencia de la metodologa P3TQ: DB9.5, TB9.4 Si Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios ms importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodologa P3TQ: DB9.6 Si Es necesario realizar recodificacin de variables para mejor comprensin del modelo? Boxes de referencia de la metodologa P3TQ: DB9.7 No Los conjuntos de variables de entrada y salida estn caracterizadas? Boxes de referencia de la Si metodologa P3TQ: AB11.1 Los datos estn estructurados o pueden estructurarse para aplicarlos en la herramienta de minera elegida? Boxes de referencia de la metodologa P3TQ: AB11.1 Mucho Estn seleccionados los algoritmos de minera adecuados al modelo? Boxes de referencia de la metodologa P3TQ: AB11.3 Si Existe una herramienta de minera adecuada al modelo y est disponible? Boxes de referencia de la metodologa P3TQ: AB11.6 Si De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la metodologa P3TQ: AB11.5 Mucho Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la metodologa P3TQ: AB11.1 No El objetivo de la explotacin es entender una situacin? Si Las variables utilizadas en el modelo estn relacionadas con conceptos que son conocidos por las partes interesadas? Boxes de referencia de la metodologa P3TQ: AB11.1, DB11.5 Si Los objetos del negocio que representan las variables pueden ser utilizados por las partes
Pg. 99
interesadas, o gerentes para realizar mejoras en el negocio. .Boxes de referencia de la metodologa P3TQ: AB11.1, DB11,5 Mucho Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodologa P3TQ: AB11.1 DB11.5 Si Resultado Esperado El sistema muestra como resultado de viabilidad: Vector Justificacin = (10 ; 10 ; 10 ; 10) Resultado Justificacin = 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 Ejecutado correctamente.
Estado
Figura A1.71. Caso de prueba Proyecto no viable por incumplimiento de situaciones esenciales
8.5. Crear evaluacin

A continuacin se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-005 : Crear evaluacin.
8.5.1. Miembro del proyecto crea evaluacin

La Figura A1.72 nuestra el caso de prueba Miembro del proyecto crea evaluacin. Identificacin CP-011 : Miembro del proyecto crea evaluacin Caso de Uso CU-005 que lo origina Escenario Un miembro evaluacin. Datos Entrada
del
proyecto
intenta
crear
una
nueva
de El miembro del proyecto ingresa cualquiera de los siguientes nombres: Texto Alfanumrico Texto nulo El sistema crea una nueva evaluacin y redirige al usuario a la pantalla de ejecucin de la evaluacin.
Pg. 100
Resultado Esperado
Estado
Ejecutado correctamente.
Figura A1.72. Caso de prueba Miembro del proyecto crea evaluacin
8.5.2. Lder del proyecto crea evaluacin

La Figura A1.73 nuestra el caso de prueba Lder del proyecto crea evaluacin. Identificacin CP-012 : Lder del proyecto crea evaluacin Caso de Uso CU-005 que lo origina Escenario El lder del proyecto intenta crear una nueva evaluacin. Datos Entrada de El lder del proyecto ingresa cualquiera de los siguientes nombres: Texto Alfanumrico Texto nulo Resultado Esperado Estado El sistema crea una nueva evaluacin y redirige al lder del proyecto a la pantalla de ejecucin de la evaluacin. Ejecutado correctamente.
Figura A1.73. Caso de prueba Lder del proyecto crea evaluacin
8.5.3. Usuario intenta crear evaluacin

La Figura A1.74 nuestra el caso de prueba Usuario intenta crear evaluacin. Identificacin CP-013 : Usuario intenta crear evaluacin Caso de Uso CU-005 que lo origina Escenario Un usuario que no posee roles en un proyecto intenta crear una evaluacin en l. Datos Entrada Resultado Esperado Estado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la accin. Ejecutado correctamente.
Figura A1.74. Caso de prueba Usuario intenta crear evaluacin
8.6. Consultar proyecto

A continuacin se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-006 : Consultar proyecto.
Pg. 101
8.6.1. Miembro consulta proyecto

La Figura A1.75 nuestra el caso de prueba Miembro consulta proyecto. Identificacin CP-014 : Miembro consulta proyecto Caso de Uso CU-006 que lo origina Escenario Un miembro del proyecto (colaborador o lder) selecciona un proyecto para consultarlo. Datos Entrada Resultado Esperado Estado de El usuario selecciona de la lista de proyectos uno al cual pertenece. El sistema le presenta al usuario la pantalla de informacin del proyecto, que incluye los resultados de todas las evaluaciones realizadas. 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. Identificacin 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 lder) selecciona ese proyecto para consultarlo. Datos Entrada Resultado Esperado Estado de El usuario selecciona de la lista de proyectos uno al cual no pertenece. El sistema le presenta al usuario la pantalla de informacin del proyecto, sin mostrar los resultados de las evaluaciones realizadas. Ejecutado correctamente.
Figura A1.76. Caso de prueba Usuario intenta consultar proyecto
8.7. Consultar Evaluacin

A continuacin se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-007 : Consultar evaluacin.
Pg. 102
8.7.1. Miembro consulta evaluacin

La Figura A1.77 nuestra el caso de prueba Miembro consulta evaluacin. Identificacin CP-016 : Miembro consulta evaluacin Caso de Uso CU-007 que lo origina Escenario Un miembro del proyecto (colaborador o lder) selecciona una evaluacin de ese proyecto para consultarla. Datos Entrada Resultado Esperado Estado de El usuario selecciona una evaluacin de la lista de evaluaciones del proyecto. El sistema le presenta al usuario la pantalla de informacin de la evaluacin. Ejecutado correctamente.
Figura A1.77. Caso de prueba Miembro consulta evaluacin
8.7.2. Usuario intenta consultar evaluacin

La Figura A1.78 nuestra el caso de prueba Usuario intenta consultar evaluacin. Identificacin CP-017 : Usuario intenta consultar evaluacin Caso de Uso CU-007 que lo origina Escenario Un usuario que no es miembro de un proyecto (ni colaborador ni lder) intenta consultar una evaluacin de ese proyecto. Datos Entrada Resultado Esperado Estado de El usuario selecciona una evaluacin de la lista de evaluaciones del proyecto al cual no pertenece. El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la accin. Ejecutado correctamente.
Figura A1.78. Caso de prueba Usuario intenta consultar evaluacin
8.8. Crear Proyecto

A continuacin 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. Identificacin CP-018 : Usuario crea proyecto
Pg. 103
Caso de Uso CU-008 que lo origina Escenario Un Usuario que ha iniciado sesin del sistema intenta crear un nuevo proyecto. Datos Entrada de El usuario ingresa cualquiera de los siguientes nombres para el proyecto: Texto Alfanumrico Texto nulo El sistema crea una nueva proyecto, designando como lder al usuario creador, y redirigiendo al usuario a la pantalla de informacin del proyecto. Ejecutado correctamente.
Figura A1.79. Caso de prueba Usuario crea proyecto
8.9. Asignar colaborador

A continuacin se presentan los casos de prueba correspondientes a los diferentes escenarios del caso de uso CU-009 : Asignar colaborador.
8.9.1. Lder del proyecto agrega nuevo colaborador

La Figura A1.80 nuestra el caso de prueba Administrador agrega nuevo evaluador. Identificacin CP-019 : Lder del proyecto agrega nuevo colaborador Caso de Uso CU-009 que lo origina Escenario El lder del proyecto accede a la pantalla para agregar un nuevo colaborador al proyecto. Datos Entrada Resultado Esperado Estado de El lder del proyecto ingresa un e-mail vlido El usuario colaborador del proyecto queda registrado en el sistema. Ejecutado correctamente.
Figura A1.80. Caso de prueba lder de proyecto agrega nuevo colaborador
8.9.2. Lder del proyecto intenta agregar colaborador registrado

La Figura A1.81 nuestra el caso de prueba Lder del proyecto intenta agregar colaborador registrado. Identificacin CP-020 : Lder del proyecto intenta agregar colaborador
Pg. 104
registrado Caso de Uso CU-009 que lo origina Escenario El lder 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 Resultado Esperado Estado de El lder del proyecto ingresa un e-mail vlido, que ya fue registrado previamente en ese proyecto (cuenta activa en google) El sistema notifica que el e-mail ya ha sido registrado para ese proyecto. Ejecutado correctamente.
Figura A1.81. Caso de prueba Lder del proyecto intenta agregar colaborador registrado
8.9.3. Lder de proyecto intenta agregar colaborador con e-mail nulo

La Figura A1.82 nuestra el caso de prueba Lder de proyecto intenta agregar colaborador con e-mail nulo. Identificacin CP-021 : Lder de proyecto intenta agregar colaborador con e-mail nulo
Caso de Uso CU-009 que lo origina Escenario El lder de proyecto accede a la pantalla para agregar un nuevo colaborador al proyecto. Datos Entrada Resultado Esperado Estado de El administrador enva el formulario sin ingresar un e-mail El sistema notifica que el e-mail no es vlido, debido a que es nulo. Ejecutado correctamente.
Figura A1.82. Caso de prueba Lder 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. Identificacin 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 lder de proyecto
Pg. 105
(puede o no ser colaborador del proyecto), 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 accin. Ejecutado correctamente.
Figura A1.83. Caso de prueba Usuario intenta agregar colaborador al proyecto
8.10. Inicializar cuestionario

A continuacin 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

CP-023 : Administrador inicializa cuestionario
La Figura A1.84 nuestra el caso de prueba Administrador inicializa cuestionario. Identificacin Caso de Uso CU-010 que lo origina Escenario El Administrador accede a la pantalla para inicializar la plantilla de evaluacin. Datos Entrada Resultado Esperado Estado de El administrador contesta Si El sistema inicializa la plantilla de evaluacin y elimina todos los registros de la base de datos. 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. Identificacin 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 evaluacin. Datos Entrada de El administrador contesta No
Pg. 106
El Sistema aborda la operacin y notifica al administrador y notifica al administrador. 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. Identificacin 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 evaluacin. Datos Entrada Resultado Esperado Estado de Ninguno El sistema notifica al usuario que no cuenta con los permisos suficientes para realizar la accin. Ejecutado correctamente.
Figura A1.86. Caso de prueba Usuario intenta inicializar cuestionario
Pg. 107
9. Conclusin
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 diseo para ser implementado en lenguaje Python sobre la arquitectura Appengine de Google. A continuacin se resumen los aspectos ms 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 diseo se busc siempre que la lgica del dominio del problema fuese independiente del resto de la lgica de la aplicacin (vista y controlador). Este aspecto es fundamental en el desarrollo de software ya que hace posible reutilizar completamente dominio para adaptarlo a otro escenario. Adems, dado que Appengine est basado en el patrn 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 interaccin 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 interaccin usuario/sistema. Como ejemplo se pueden citar los casos de uso CU-003 Actualizar planilla de evaluacin 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 seccin 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.
Pg. 108
10. Posibles mejoras

Este documento podra mejorarse tomando en cuenta algunos de estos elementos: Incorporando fragmentos de cdigo en lenguaje Python sobre aquella funcionalidad del dominio que permita clarificar la implementacin. El Sistema DAMVE podra mejorarse tomando en cuenta algunos de estos elementos: Desarrollar una capa de servicios web. Esto permitira, por ejemplo, utilizar la aplicacin desde una interfaz de usuario de ventanas mejorando la interaccin usuario/herramienta, o permitir que la herramienta se integre con otros sistemas proveyendo el servicio de evaluacin de viabilidad. En el ltimo caso sera interesante integrar la herramienta DAMVE con un Sistema de administracin de proyectos.
Pg. 109
Anexo 2. Manual de usuario la Herramienta DAMVE
Anexo 2. Manual de Usuario de la Herramienta DAMVE.
Pg. 110
1. Introduccin
El Sistema DAMVE tiene por finalidad, ayudar a los miembros de un proyecto de explotacin de informacin que utilizan la metodologa 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 ejecucin 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 direccin 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 seleccin de proyectos, que se muestra en la Figura A2.2:
Pg. 111
Figura A2.2. Pantalla de seleccin 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. Presentacin de la interfaz
Se presenta a continuacin, en la Figura A2.3, la pantalla de seleccin de proyectos del sistema y se describen las distintas opciones de la barra de mens.
1
Figura A2.3. Pantalla de presentacin de la interfaz
Los nmeros asociados con cada elemento de la pantalla se describen a continuacin:

1.
2.
en el encabezado de la pantalla puede verse el nombre del usuario que est utilizando el sistema. P r oy e ct os : esta opcin lleva a la pantalla de seleccin de proyectos que le permite al usuario dar de alta un nuevo proyecto, seleccionar un existente
Pg. 112
No m b re de u su a ri o :
y, a partir de all, realizar evaluaciones de viabilidad para el mismo. Esta opcin explica en detalle en el tem 5 de este manual.
3.
4.
5.
6.
7.
esta opcin lleva a la pantalla de edicin de la plantilla de evaluacin para los estudios de viabilidad. Solamente los usuarios de cuentan con el rol de evaluadores pueden acceder, y les permite modificar los parmetros del cuestionario con el cual se realizan todos los estudios de viabilidad. Esta opcin se explica en detalle en el tem 10.3 de este manual. Ev a lu a do re s : esta opcin lleva a la pantalla que le permite al administrador del sistema agregar nuevos usuarios evaluadores para que puedan modificar la plantilla de evaluacin, explicada anteriormente. Esta opcin se explica en detalle en el tem 10.1 de este manual. Ini ci a li za r : esta opcin lleva a la pantalla que le permite al administrador del sistema inicializar la base de datos, eliminando, de existir, toda la informacin que exista y reiniciando la plantilla de evaluacin. Esta opcin se explica en detalle en el tem 10.4 de este manual. A yu d a : esta opcin permite consultar este manual en lnea o descargarlo el formato electrnico. S a li r : esta opcin permite que el usuario cierra su sesin y salga del sistema.
Cue s tio n a rio :
5. Creacin y Seleccin de Proyectos

En este tem explicara cmo crear o seleccionar proyectos existentes en la sistema.
5.1. Creacin de un proyecto nuevo

Cualquier usuario registrado en el sistema es capaz de crear un nuevo proyecto y, de esa manera, convertirse en el lder (o propietario) del mismo. La creacin de nuevo proyecto se lleva a cabo haciendo clic en la opcin P ro ye c tos . Luego de hacer esto el usuario puede ver el siguiente formulario, presentado en la Figura A2.4:
Pg. 113
Figura A2.4. Formulario de creacin de un nuevo proyecto
Para crear un nuevo proyecto, en la seccin "c re a r p ro ye c to " el usuario debe: Escribir un nombre para el proyecto. Hacer clic en el botn Cre a r . Una vez realizada esta tarea el sistema DAMVE crea el proyecto y le presenta al usuario la pantalla de gestin del proyecto.
5.2. Seleccin de un proyecto existente

Para seleccionar un proyecto existente en el sistema debe hacerse clic en la opcin 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 seleccin de un proyecto
La informacin que se presenta es la siguiente: Fecha: fecha en la cual se cre el proyecto. Descripcin: 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 lder 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, descripcin o rol de un proyecto el usuario puede acceder a la pantalla de gestin 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
Pg. 114
de los usuarios en el sistema ordenados por jerarqua, comenzando por el rol de menor jerarqua (visitante) y llegando hasta el rol con mayor jerarqua (Administrador):
Nombre del rol Visitante Acciones dentro del sistema 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 lder del mismo. Como tal puede crear evaluaciones de viabilidad. Un colaborador de un proyecto no puede continuar la ejecucin de evaluaciones creadas por otro colaborador del mismo proyecto. Cualquier usuario visitante que d de alta un proyecto se convierte en el lder 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 evaluacin del estudio de viabilidad. Es el usuario responsable de la administracin del sistema. Puede designar a los usuarios evaluadores.
Tabla 1. Roles de los usuarios
Colaborador del Proyecto
Lder del Proyecto
Evaluador
Administrador
Un mismo usuario puede tener dentro del sistema uno o varios roles. Por ejemplo, un usuario puede ser lder del proyecto 1 por haberlo creado, colaborador del proyecto 2 porque su lder lo ha designado, visitante en el resto de los proyectos y evaluador porque el administrador lo ha designado.
7. Gestin de un Proyecto
Una vez creado un nuevo proyecto o seleccionado de la pantalla de seleccin de proyecto, el usuario accede a la pantalla de gestin del proyecto. La Figura A2.6 presenta dicha pantalla:
Pg. 115
Figura A2.6. Pantalla de gestin del proyecto
En esta pantalla puede observarse toda la informacin 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 creacin y el usuario propietario, o lder. Co la b o ra d o re s : se presentan los e-mails de todos los usuarios designados por el lder del proyecto para crear evaluaciones de viabilidad. Ev a lu a ci one s : se presenta una tabla que muestra la informacin resumida de cada uno de los estudios de viabilidad realizados para este proyecto, ordenados en forma cronolgica descendente, lo que permite visualizar la evolucin de la viabilidad del proyecto. La tabla presenta la fecha de creacin, la descripcin, el usuario creador y el resultado de cada una de las evaluaciones. Si la evaluacin ha sido completada se muestra en la tabla el resultado final en forma grfica y numrica. Sin evaluacin no ha sido completada todava 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 lder ni colaborador) el sistema no mostrara el resultado de ninguna evaluacin.
7.1. Agregar colaborador al proyecto

El lder 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 gestin del proyecto. La Figura A2.7 muestra dicha pantalla:
Pg. 116
Figura A2.7. Formulario agregar colaborador al proyecto
Para agregar un colaborador al proyecto, el lder debe: Escribir el e-mail del usuario colaborador. Hacer clic en el botn 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 lder 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 confirmacin y, si el lder del proyecto contesta afirmativamente, el colaborador ser eliminado de ese proyecto, convirtindose en visitante.
7.3. Crear una nueva evaluacin

El lder del proyecto y los usuarios colaboradores pueden crear una nueva evaluacin 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 gestin del proyecto.
Figura A2.7. Formulario crear nueva evaluacin
Para crear una nueva evaluacin, el usuario miembro del proyecto debe: Escribir una descripcin para la evaluacin. Hacer clic en el botn c re ar n ue va e v a lu a c in . Una vez realizada esta tarea el sistema DAMVE crea una nueva evaluacin para el proyecto y le muestra al usuario la pantalla de ejecucin de la evaluacin.
7.4. Imprimir la gestin del proyecto

Para imprimir la informacin de gestin del proyecto el usuario debe hacer clic en el botn Imp r im i r que se encuentra en el borde superior derecho de la pantalla.
Pg. 117
El sistema preparar una versin adaptada para impresin de la pantalla que facilita su lectura en papel y ejecutar automticamente el cuadro de dilogo de impresin del navegador web.
7.5. Exportar la gestin del proyecto

Para exportar la informacin de gestin del proyecto a un archivo separado por comas (.csv) el usuario debe hacer clic en el botn 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 clculo o editor de texto.
8. Ejecucin 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 travs de un cuestionario guiado. Una vez que un miembro del proyecto cree una nueva evaluacin, el sistema DAMVE presenta la pantalla de ejecucin de la evaluacin. La Figura A2.8 presenta dicha pantalla:
Figura A2.8. Pantalla de ejecucin de la evaluacin
La ejecucin de una evaluacin de viabilidad es simple: 1. El sistema le presenta al usuario una pregunta relacionada a un aspecto particular de la metodologa P3TQ. 2. El usuario debe responderla en relacin a la informacin con la que cuenta del proyecto que est evaluando. Para esto puede utilizar el mouse para elegir la opcin que considere correcta y hacer clic en el botn siguiente.
Pg. 118
3.
4.
Alternativamente, para hacer ms dinmica la interaccin, el usuario puede seleccionar la opcin correcta con las flechas del cursor y presionar la tecla ENTER. El sistema procesar la respuesta del usuario y le presentar la prxima pregunta. Adems, en la seccin "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 evaluacin.
8.1. Abandonar y Retomar evaluaciones

No es necesario que el usuario complete una evaluacin en una nica sesin, pudiendo abandonar la ejecucin de una evaluacin en cualquier momento. Para retomar una evaluacin incompleta, el usuario miembro del proyecto debe seleccionar el proyecto en la pantalla de seleccin de proyectos y, en la pantalla de gestin del proyecto buscar en la tabla de evaluaciones, que se presenta en la Figura A2.9, la evaluacin que ha dejado incompleta.
Figura A2.9. Retomar una evaluacin incompleta
Una vez hecho esto debe hacer clic en el icono , que le permitir volver a la pantalla de ejecucin de la evaluacin, retomando el cuestionario desde dnde lo abandon.
9. Resultado de las evaluaciones

Una vez que se ha completado el cuestionario de evaluacin el sistema le presenta al usuario de resultado obtenido. La Figura A2.10 muestra un ejemplo de resultado de evaluacin:
Pg. 119
Figura A2.10. Pantalla de resultado de una evaluacin
El sistema muestra los siguientes resultados: Di me nsi n j ust if i c a c in : presenta el vector justificacin y, en forma grfica, el mdulo del vector que sintetiza el resultado de esa dimensin. Di me nsi n A d a pt a bi li da d : presenta el vector adaptabilidad y, en forma grfica, el mdulo del vector que sintetiza el resultado de esa dimensin. Di me nsi n P l au si bi li da d : presenta el vector plausibilidad y, en forma grfica, el mdulo del vector que sintetiza el resultado de esa dimensin. Di me nsi n xit o : presenta el vector xito y, en forma grfica, el mdulo del vector que sintetiza el resultado de esa dimensin. V ia bi li d ad : presenta el vector viabilidad, que es un promedio de las cuatro dimensiones anteriores y, en forma grfica, el mdulo de este vector que sintetiza el resultado final de la evaluacin. Si el resultado del clculo del mdulo de un vector es menor a seis, se considera insuficiente y se presenta el resultado grfico en color rojo. Por el contrario si el mdulo es mayor a seis se lo considera aceptable y se presenta el resultado grfico en color verde. Al igual que la pantalla de ejecucin de una evaluacin del sistema presenta en la seccin "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 evaluacin.
9.1. Imprimir los resultados

Para imprimir los resultados de la evaluacin de un proyecto el usuario debe hacer clic en el botn Im p ri mi r es encuentra en el borde superior derecho de la pantalla.
Pg. 120
El sistema preparar una versin adaptada para impresin del resultado que facilita su lectura en papel y ejecutar automticamente el cuadro de dilogo de impresin del navegador web.
9.2. Exportar los resultados

Para exportar los resultados de la evaluacin a un archivo separado por comas (.csv) el usuario debe hacer clic en el botn 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 clculo o editor de texto.
9.3. Consultar resultados de evaluaciones realizadas

Para poder consultar los resultados de una evaluacin realizada cualquier miembro del proyecto (lder o colaborador) debe hacer clic en el resultado final de la evaluacin que se encuentra en la seccin "Eval u a cio ne s " de la pantalla de gestin 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 continuacin pueden ser llevadas a cabo por usuarios con mayor jerarqua 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 evaluacin. Para realizar esta tarea el administrador debe hacer clic en la opcin 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
Pg. 121
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 botn 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 confirmacin y, si el administrador contesta afirmativamente, el evaluador ser eliminado del sistema.
10.3. Editar la plantilla de evaluacin

Los usuarios con el rol de evaluadores pueden editar la plantilla de evaluacin. Para realizar esta tarea deben hacer clic en la opcin "Cue sti on a r io " del men. A continuacin se presenta en la Figura A2.13 la pantalla de edicin de la plantilla de evaluacin.
Figura A2.13. Formulario para editar la plantilla de evaluacin
Pg. 122
El sistema presenta un formulario por cada pregunta del cuestionario de evaluacin. Los parmetros que pueden modificarse en cada formulario es: 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 dimensin de viabilidad corresponde la pregunta (justificacin, 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 prxima pregunta del cuestionario. Esta opcin permite que el usuario evaluador pueda navegar el cuestionario. Para esto el usuario evaluador debe hacer clic en el nmero de la prxima pregunta y el sistema lo llevara hasta el formulario de dicha pregunta. El usar evaluador puede, entonces, modificar cualesquiera de los parmetros del formulario y, haciendo clic en el botn A ct ua l iz a r el sistema guardar los cambios en la plantilla de evaluacin.
De s c ri p c i n :
10.3.1.
Preservacin de los resultados
Cuando una pregunta de la plantilla de evaluacin es modificada, todas las evaluaciones de viabilidad de cualquier proyecto utilizarn los nuevos parmetros de dicha pregunta. Las evaluaciones que ya hayan respondido previamente la pregunta conservarn el valor anterior en el resultado. De esta manera se preservan los resultados de viabilidad anteriores a la modificacin de la plantilla de evaluacin.
10.3.2.
Preservacin de la secuencia
El sistema DAMVE, no permite que se altere la secuencia de las preguntas, debido a que siguen, de manera estricta la metodologa P3TQ. Sin embargo, resulta muy til para un lder de proyecto de explotacin de informacin con experiencia la posibilidad de modificar los parmetros de la pregunta para adecuar la evaluacin 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 opcin Inicia li z ar del men. Luego de hacer esto el sistema mostrar una pantalla similar a la Figura A2.14, que solicita la confirmacin del administrador, dado que esta accin destruye todos los datos que existan en la base de datos y lleva al Sistema DAMVE a su estado original.
Pg. 123
Figura A2.14. Confirmacin de Inicializacin de la Base de Datos
Si el usuario hace clic en el botn A ce p ta r toda la informacin existente es eliminada y el sistema queda reinicializado.
Pg. 124

Mendez Rodriguez Trabajoprofesional

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Mendez Rodriguez Trabajoprofesional

Uploaded by

Copyright:

Available Formats

HERRAMIENTA DE ESTUDIO DE VIABILIDAD PARA PROYECTOS QUE UTILIZAN LA METODOLOGA P3TQ

TRABAJO PROFESIONAL EN INGENIERA EN INFORMTICA

Laboratorio de Sistemas Inteligentes Facultad de Ingeniera Universidad de Buenos Aires

Anexo 1. Documento de Desarrollo de la Herramienta DAMVE ............. 24

Cambios en la versin ................................................................................................... 27

Especificacin de Requerimientos ................................................................................ 27

Modelo de anlisis ......................................................................................................... 44

Arquitectura del Sistema............................................................................................... 58

Casos de Prueba ............................................................................................................. 84

8.3. 8.4. 8.5. 8.6. 8.7. 8.8. 8.9. 8.10.

Conclusin.................................................................................................................... 108 Posibles mejoras........................................................................................................... 109

Anexo 2. Manual de usuario la Herramienta DAMVE............................. 110

Roles de los usuarios ................................................................................................... 114 Gestin de un Proyecto ............................................................................................... 115

Ejecucin de evaluaciones........................................................................................... 118

Resultado de las evaluaciones .................................................................................... 119

Opciones Avanzadas ................................................................................................... 121

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

2.1. La metodologa SEMMA

Figura 2.1.1. Metodologa SEMMA

Memoria del Trabajo Profesional

2.2. La metodologa CRISP-DM

Figura 2.2.1. Fases de la Metodologa CRISP-DM

Memoria del Trabajo Profesional

2.3. La metodologa P3TQ

MII Modelado del Negocio

Metodologa de Modelado (MII)

MIII Preparacin de los Datos (Boxes 9.x)

MIII Minera sobre el modelo (Boxes 11.x)

Metodologa de Minera (MIII)

MIII Despliegue (Boxes 13.x)

Figura 2.3.1. Metodologa de D.Pyle, Etapas del proyecto de explotacin de informacin

Memoria del Trabajo Profesional

Figura 2.3.2. Metodologa de P 3 TQ, Puntos de partida de un proyecto y objetos a considerar

Figura 2.3.3. Pasos distinguidos en la metodologa P 3 TQ

2.4. Comparacin de las metodologas P3TQ, SEMMA y Crisp-DM

Memoria del Trabajo Profesional

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 metodologas

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

Nada Poco Mucho Todo

Regular 3,4 4,4 5,6 6,6

Tabla 3.1.1 Conversin entre valores lingsticos y valores difusos

Tabla 3.1.2 Conversin entre valores booleanos y valores difusos

Ecuacin 3.1.1. Clculo de viabilidad de una dimensin.

Ecuacin 3.1.2 Viabilidad total

3.2. Viabilidad en P3TQ

Memoria del Trabajo Profesional

3.2.1. Estudio de viabilidad en el modelado de negocio

Memoria del Trabajo Profesional

Figura 3.2.1.1 Variables P 3 TQ

3.2.2. Estudio de viabilidad en la metodologa de minera de datos

3.2.3. El cuestionario de evaluacin

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

Figura 3.2.3.1 Secuencia del cuestionario de viabilidad

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

Anexo 1. Documento de Desarrollo de la Herramienta DAMVE

Anexo 1. Documento de Desarrollo de la Herramienta DAMVE.

Anexo 1. Documento de Desarrollo de la Herramienta DAMVE.