Mendez Rodriguez Trabajoprofesional

5/12/2018 Mendez Rodriguez Trabajoprofesional - slidepdf.com

http://slidepdf.com/reader/full/mendez-rodriguez-trabajoprofesional 1/127

HERRAMIENTA DE ESTUDIO DEVIABILIDAD PARA PROYECTOS QUE

UTILIZAN LA METODOLOGÍA P3TQ

TRABAJO PROFESIONAL EN INGENIERÍA ENINFORMÁTICA

Laboratorio de Sistemas InteligentesFacultad de Ingeniería

Universidad de Buenos Aires

Alumnos: Pablo Damián MENDEZAlejandro Daniel RODRIGUEZ

Directores: Prof. Dr. Ramón GARCIA-MARTINEZProf. Dra. Paola BRITOS

Mayo 2009



FIUBA – LSI – Trabajo Profesional en Ingeniería en InformáticaHerramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P 3TQDirectores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZProf. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ

Índice

Memoria del Trabajo Profesional.................................................................... 1 1. Resumen ........................................................................................................................... 2 2. Introducción ..................................................................................................................... 2

2.1. La metodología SEMMA ............................................................ .................................................... 3 2.2. La metodología CRISP-DM ........................................................ .................................................... 4 2.3. La metodología P3TQ........................................................ ........................................................... ... 5 2.4. Comparación de las metodologías P3TQ, SEMMA y Crisp-DM...................................... ............. 7

3. Estudio de viabilidad....................................................................................................... 9 3.1. El método ...................................................... ........................................................... ....................... 9 3.2. Viabilidad en P3TQ ........................................................... ........................................................... . 11 Modelo para predecir:....................................................................................... ........................................ 17

4. Conclusiones .................................................................................................................. 22 5. Futuras mejoras.............................................................................................................. 23 6. Bibliografía.....................................................................................................................23 Anexo 1. Documento de Desarrollo de la Herramienta DAMVE ............. 24 1. Objetivo .......................................................................................................................... 25 2. Funcionalidad del Sistema............................................................................................ 26

2.1. Evaluación de proyectos................................................... ........................................................... . 26 2.2. Gestión de usuarios .......................................................... ........................................................... . 26

3. Cambios en la versión ................................................................................................... 27 3.1. Versión 4 ....................................................... ........................................................... ..................... 27 3.2. Versión 3 ....................................................... ........................................................... ..................... 27 3.3. Versión 2 ....................................................... ........................................................... ..................... 27 3.4. Versión 1 ....................................................... ........................................................... ..................... 27

4. Especificación de Requerimientos ................................................................................ 27 4.1. Formato ......................................................... ........................................................... ..................... 27 4.2. Requerimientos funcionales ....................................................... .................................................. 28 4.3. Requerimientos no funcionales.................... ........................................................... ..................... 36 4.4. Restricciones ........................................................... ........................................................... ........... 43

5. Modelo de análisis ......................................................................................................... 44 5.1. Diagrama de Casos de Uso............................................................................ ............................... 44 5.2. Matriz de trazabilidad Casos de Uso – Requerimientos Funcionales ........................................ 45 5.3. Realización de los Casos de Uso .......................................................... ........................................ 46

6. Arquitectura del Sistema............................................................................................... 58 6.1. La arquitectura Appengine ........................................................ .................................................. 58

7. Diseño de la aplicación.................................................................................................. 60 7.1. Diagrama de Paquetes de clases .......................................................... ........................................ 60 7.2. dbmodel. La capa De dominio ............................................................. ........................................ 62 7.3. View. Paquete de soporte para vista................................................................................. ........... 67 7.4. Paquetes de Controladores.............................................. ........................................................... . 68 7.5. Diagramas de Secuencia. ............................................................ .................................................. 74 7.6. Secuencia entre Pantallas ........................................................... .................................................. 77 7.7. Diagrama de Despliegue ............................................................ .................................................. 82

8. Casos de Prueba............................................................................................................. 84 8.1. Validar Usuario........................................................................................................ ..................... 84 8.2. Asignar evaluador ............................................................ ........................................................... . 85




8.3. Actualizar planilla de evaluación ........................................................ ........................................ 87 8.4. Evaluar viabilidad ............................................................ ........................................................... . 88 8.5. Crear evaluación..................................................... ........................................................... ......... 100 8.6. Consultar proyecto ........................................................... .......................................................... 101 8.7. Consultar Evaluación ....................................................... .......................................................... 102 8.8. Crear Proyecto ........................................................ ........................................................... ......... 103 8.9. Asignar colaborador ......................................................... .......................................................... 104 8.10. Inicializar cuestionario ..................................................... .......................................................... 106

9. Conclusión.................................................................................................................... 108 10. Posibles mejoras........................................................................................................... 109 Anexo 2. Manual de usuario la Herramienta DAMVE............................. 110 1. Introducción ................................................................................................................. 111 2. Requisitos ..................................................................................................................... 111 3.

Acceso al sistema ......................................................................................................... 111

4. Presentación de la interfaz .......................................................................................... 112 5. Creación y Selección de Proyectos.............................................................................. 113

5.1. Creación de un proyecto nuevo ........................................................... ...................................... 113 5.2. Selección de un proyecto existente ...................................................... ...................................... 114

6. Roles de los usuarios ................................................................................................... 114 7. Gestión de un Proyecto ............................................................................................... 115

7.1. Agregar colaborador al proyecto ......................................................... ...................................... 116 7.2. Eliminar un colaborador.......................................................................................... ................... 117 7.3. Crear una nueva evaluación....................................................... ................................................ 117 7.4. Imprimir la gestión del proyecto ......................................................... ...................................... 117 7.5. Exportar la gestión del proyecto............................ ........................................................... ......... 118

8. Ejecución de evaluaciones........................................................................................... 118 8.1. Abandonar y Retomar evaluaciones .................................................... ...................................... 119

9. Resultado de las evaluaciones .................................................................................... 119 9.1. Imprimir los resultados .................................................... .......................................................... 120 9.2. Exportar los resultados................................. ........................................................... ................... 121 9.3. Consultar resultados de evaluaciones realizadas...................................................................... 121

10. Opciones Avanzadas ................................................................................................... 121 10.1. Designar evaluadores ....................................................... .......................................................... 121 10.2. Eliminar un evaluador........................ ........................................................... ............................. 122 10.3. Editar la plantilla de evaluación ......................................................... ....................................... 122 10.4. Inicializar la Base de Datos ........................................................ ................................................ 123




Memoria del Trabajo Profesional Pág. 1

Memoria del Trabajo Profesional





1. Resumen

Los actuales proyectos de explotación requieren el análisis y

ejecución de etapas para ser llevados a cabo con éxito. Cada una de

estas etapas insume tiempo y recursos, lo que hace sumamente

importante estudiar la viabilidad del proyecto para evaluar si

resulta posible y conveniente llevarlo a cabo y, además, controlar

cada etapa de ejecución para detectar y corregir desvíos y, de esta

manera, asegurar su éxito.El proyecto en cuestión se enfoca en una metodología para la

realización de proyectos de explotación de la información (Data

mining) y propone un test de viabilidad acorde a dicha

metodología.

2. Introducción

La Explotación de Información se centra en la búsqueda de patrones interesantesen grandes bases de datos.Utiliza tanto técnicas estadísticas (Análisis de varianza, Regresión, Prueba chi-cuadrado, Análisis de agrupamiento o clustering, Análisis discriminante, Seriesde tiempo, etc.) como informáticas (Algoritmos genéticos, Inteligencia Artificial,Sistemas Expertos, Redes neuronales, etc.)Entre muchos otros ejemplos, la Explotación de Información ha contribuido

significativamente en: Las aplicaciones de administración empresarial basada en la relación con el

cliente.

Detectar patrones de fuga y fraudes.

Analizar el comportamiento de las personas que interactúan en un sistema

(por ejemplo Internet)

Existen en el mercado actual tres importantes metodologías para llevar a caboproyectos de explotación de la información, a saber:

SEMMA CRISP-DM





P3TQ

Sin importar la metodología usada, no existe hasta el día de hoy, ningún métodode cálculo de viabilidad para proyectos de explotación de la información. En este

trabajo, se estudia la metodología P3TQ en particular para especificar un métodoplausible para el cálculo de viabilidad de proyectos de las característicasmencionadas.

2.1. La metodología SEMMA

La primer metodología fue propuesta por el SAS Institute, su nombre hacereferencia a las cinco fases que se consideran al utilizarla (Sample, Explore,Modif., Model, Assess esto es Muestrear, Explorar, modificar, Modelar y Valorarrespectivamente) [SAS Institute 1998].La figura 2.1.1 muestra la dinámica del método SEMMA.

Figura 2.1.1. Metodología SEMMA





2.2. La metodología CRISP-DM

La metodología CRISP-DM analiza el proceso de explotación de la información enseis fases diferentes (Figura 2.2.1). Aunque en la ilustración se muestran lasinteracciones más comunes entre las fases se pueden establecer relaciones entrecualquiera de ellas [CRISP-DM 2000].

Figura 2.2.1. Fases de la Metodología CRISP-DM





2.3. La metodología P3TQ

La metodología de D. Pyle se divide en dos etapas, la primera denominadaModelado de Negocio o MII , y la segunda llamada Minería de datos o MIII

[Pyle, D. 2003].

MII

Modelado del Negocio

Inicio

MIII

Preparación de los Datos

(Boxes 9.x)

MIII

Minería sobre el modelo(Boxes 11.x)

MIII

Refinamiento(Boxes 12.x)

Fin

MIII

Despliegue

(Boxes 13.x)

Figura 2.3.1. Metodología de D.Pyle, Etapas del proyecto de explotación de información

Para comenzar la primera etapa Pyle propone cinco posibles puntos de partida enfunción del propósito del proyecto de explotación de la información que se quiereevaluar. De esta manera Pyle considera:1. Explorar los datos en búsqueda de relaciones útiles.

2. Dada una oportunidad o problema ver cómo puede la explotación de la

información encausar a la organización hacia una decisión correcta.3. Simplemente ver qué puede lograr la explotación de la información.

Metodología deModelado (MII)

Metodología deMinería (MIII)





4. Utilizar la minería de datos para construir un modelo sobre una situación

particular5. Dada una situación estratégica, analizar si la minería de datos puede ser útil

para explicar la situación y cuáles son las opciones de la organización para

resolverla.

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

En la Figura 2.3.2 (parte central) se enumeran los parámetros concernientes a laorganización y la situación del proyecto que la metodología de P 3TQ considera,sin embargo estos son tratados de distinta manera según el punto de partida, para

obtener finalmente los datos requeridos para el proyecto de explotación y losrequerimientos reales de las partes interesadas.





Finalizado el modelo de negocio el siguiente paso es la explotación de datos, para

ello D. Pyle propone los pasos mostrados en la Figura 2.3.3.

Preparación de losdatos

Selección de laherramienta

Minería

Refinamiento

Despliegue

Cada parte de la metodología (tanto en MII como en MIII)está desagregada en pasos, estos pasos son denominadosboxes, existiendo 3 tipos de ellos:

Action Boxes, en donde se decide cuál es el

próximo 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

cómo debe emplearse una técnica.

Los boxes no se recorren secuencialmente, los saltos entreellos dependen de las situaciones que se van dando amedida que se avanza en el proyecto.

Figura 2.3.3. Pasos distinguidos en la metodología P3

TQ

Los boxes explican detalladamente los conceptos y/o acciones que se realizan. Elgráfico mostrado anteriormente permite identificar cuáles son los Boxes quecorresponden a cada etapa de la metodología. Por ejemplo puede verse en lafigura 2.3.1 que los Boxes 9.x corresponden a la etapa de preparación de los datosen la metodología de minería MIII.

2.4. Comparación de las metodologías P3TQ, SEMMA yCrisp-DM

Luego de las investigaciones iniciales, hemos concluido que SEMMA se centra enlos aspectos técnicos de los proyectos de explotación de datos. Además estáacotada ya que ha sido diseñada para ser implementada con los productos SAS.Crisp-DM es más completa y abierta que SEMMA, pero no llega al detalle de lametodología P3TQ, ya que nombra etapas del proceso de la explotación de lainformación, pero no se analizan los pasos, resultados y situaciones que se pueden

dar dentro de cada etapa.





Concluimos que la metodología P3TQ es la más completa entre las tres

mencionadas (Ver cuadro 2.4.1), y, por lo tanto en la que se centrará el presentetrabajo. Dicha metodología analiza muchas más variables y más profundamenteque las demás. Para citar un simple y claro ejemplo (considerando que nosencontramos sólo en la introducción de la presentación de un proyecto y no en sudesarrollo) la metodología considera quiénes son los interesados en el proyecto enla organización, considerando hasta la causa de su interés (Pyle, D. Business

Modeling and Data Mining, Technique Box 1: Identify Stakeholders).

SEMMA

CRISP-

DM PYLE

Permite elección totalmente libre de

herramientas NO SI SI

Cantidad de fases 5 6 5 (1 MII y 4 MIII)

Todas las fases pueden relacionarse NO SI SI

Considera motivo del proyecto NO NO SI

Considera naturaleza del interés de las partes NO NO SI

Considera otros aspectos no técnicos NO SI SI

Identifica claramente las variables sobre las que el

proyecto tiene impacto NO NO

SI (Product, Place, Price,

Time, Quantity)

Está detallada paso a paso cada etapa del método NO NO SI

Cuadro 2.4.1. Cuadro comparativo de metodologías





3. Estudio de viabilidadTodo proyecto en el ámbito de cualquier rama de la ingeniería debe satisfacer laecuación fundamental de costo y beneficio.Antes de comenzar con un proyecto, por lo tanto, tres puntos deben tenerse encuenta:

• El esfuerzo necesario para el desarrollo (Costo)

• La utilidad que se obtendrá por realizar dicho desarrollo.

• También a veces, por razones inherentes a la naturaleza de un proyectosurge una tercera cuestión que es si es realizable en función de las variables

que lo definen.

Estas tres cuestiones no sólo pueden indicar si se debe comenzar o no unainversión económica para obtener un resultado, sino que además, puede variar amedida que se va avanzando en la empresa y nuevos problemas van surgiendo.El estudio de viabilidad, considerando los puntos que D. Pyle menciona en labibliografía, aproxima a un valor que nos da la respuesta sobre si es conveniente

que un proyecto se ejecute, o siga ejecutándose. Estas características correspondenen mayor medida al segundo y tercer punto.En comparación a cualquier otro tipo de proyecto de naturaleza informática, tomamayor importancia realizar estudios de viabilidad cuando se trata de actividadesde explotación de la información. La razón de esta afirmación, radica en que escomún notar en el cliente un interés incierto, o más bien, mucho interés, pero sinconocer exactamente qué espera de un proyecto de explotación de la información.

3.1. El método

La metodología mencionada en [García-Martínez, R. y Britos, P. (2004).Sistemas Expertos. Nueva Librería] clasifica tres tipos distintos decaracterísticas que definen la viabilidad de un problema, a saber:

• Booleanos

• Numéricos en un intervalo finito

• Lingüísticos (Conjunto que posee los valores “nada”, “poco”, “regular”,

“mucho”, “todo”).





Según los valores de cada característica del problema se estima si el proyecto es

viable o no. Además cada característica estará ponderada por un “peso”, que haráque incida en mayor o menor medida en la dimensión de un problema.En casos de valores lingüísticos son convertidos en valores difusoscorrespondiente en el intervalo [0,10] como se muestra en la tabla 3.1.1.

Tabla 3.1.1 Conversión entre valores lingüísticos y valores difusos

Para homogeneizar el problema, los valores booleanos también se tratan comolingüísticos considerando los valores de la tabla 3.1.2.

Tabla 3.1.2 Conversión entre valores booleanos y valores d ifusos

Las características se agruparán según su naturaleza y llamaremos a cada grupo“Dimensión”, existiendo cuatro dimensiones a saber: Plausibilidad, Éxito,Adecuación y Justificación.La dimensión “Plausibilidad” agrupará todas aquellas características que indicansi el desarrollo del proyecto es posible, por ejemplo si existen expertos y están

disponibles, si existen los casos de prueba adecuados, etc. El “éxito” esdeterminado por características del problema que generalmente se dan aposteriori del desarrollo, de todas maneras debemos identificar y evaluar estascaracterísticas a priori, para ejemplificar podemos mencionar el interés odesinterés de un departamento clave de la organización, que no sea el sponsorpero si el usuario final (el proyecto sería desarrollado pero nunca utilizado o losusuarios serían reacios, esto sería un fracaso).La dimensión de “Justificación” contendrá cada característica que determine si

vale la pena realizar el proyecto. Supongamos el caso que se dispone desuficientes expertos en la materia y no representan costo significativo para laempresa, en este caso seguramente no será justificado el desarrollo.

Nada 0 0 1,2 2,2

Poco 1,2 2,2 3,4 4,4

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

Mucho 5,6 6,6 7,8 8,8Todo 7,8 8,8 10 10

No 0 0 0 0

Sí 10 10 10 10





La dimensión de “adecuación”, evalúa si es apropiado resolver el problema

mediante el sistema propuesto en este trabajo.Finalmente el cálculo del valor de cada dimensión se realiza de la siguientemanera. Dado L el vector de valor lingüístico de dimensión 4 (de acuerdo a lastablas 3.1.1 y 3.1.2), Li y Pi el valor difuso y el peso de la característica irespectivamente; la viabilidad de una dimensión j determinada del problema serádeterminada por la ecuación 3.1.1.

Ecuación 3.1.1. Cálculo de viabilidad de una dimensión.

Esta fórmula representa la viabilidad para una dimensión j dada. Luego decalcular para las 4 dimensiones (Adecuación, éxito, justificación y plausibilidad),se calcula la viabilidad total de un problema según la fórmula 3.1.2.

Ecuación 3.1.2 Viabilidad total

P j es el peso de cada dimensión, siguiendo la bibliografía propuesta se define queserá: Plausibilidad y adecuación 8 Justificación 3

Éxito 5

3.2. Viabilidad en P3TQ

Todo proyecto de Explotación de la información, tiene como propósito el uso deherramientas sobre datos existentes para obtener relaciones interesantes a la horade tomar decisiones o crear soluciones.Una característica de los trabajos de explotación de datos actuales, es que el punto

de partida, o más bien el motivo de su realización, no sea un problema enparticular a solucionar. Muchos interesados en aplicar explotación de la





información tienen como objetivo descubrir qué problemas se pueden solucionar

con la información existente, pero no la solución de un problema en sí.Esta característica, incrementa la necesidad del estudio de viabilidad; ya que alcomenzar con un rumbo incierto, es probable terminar en una solución nodeseada luego de haber invertido tiempo de personal calificado y recursoseconómicos.Naturalmente no es apropiado este tipo de perspectiva para ningún tipo deproyectos, a pesar que la realidad en la práctica indique que muchos comienzande esta manera porque el sponsor lo requiere.Como se describió en la sección 2.3, la metodología propuesta por D. Pyle,establece dos partes de un proyecto de minería de datos, el “Modelado de Negocio” y la “Metodología de Minería”. Por esta razón analizaremos la viabilidad tomandocaracterísticas de estas dos partes por separado.

3.2.1. Estudio de viabilidad en el modelado de negocio

Tomando como punto de partida que nada puede ofrecer un proyecto deexplotación de datos hasta que el problema a resolver sea identificado, esto debelograrse de alguna manera, aunque el cliente no lo haya especificado.

Pyle reconoce, por lo tanto, los siguientes puntos de partida de un proyecto segúnsu objetivo:

Según el punto de partida inicial, D. Pyle establece cuáles son los siguientes pasosa seguir.Por ejemplo el caso más general, con escasa información sobre el negocio, sólollega el conjunto de datos sobre el cual se debe aplicar minería para descubrirrelaciones que puedan llegar a ser de interés. En este punto, Pyle, establece

Explorar los datos y descubrir relaciones interesantes queofrezcan valor agregado al negocio.

Un problema u oportunidad de negocio en particular a serexplorado.

Descubrir en qué partes de la organización puede serinteresante aplicar métodos de explotación de la

información. Crear un modelo para un propósito especificado. Planificar escenarios corporativos.





específicamente el aso más lógico a seguir: reconocer a los interesados según cinco

categorías:1. Los que necesitan la realización del proyecto.

2. Los que poseen los recursos económicos.

3. Los que poseen poder de decisión para que el proyecto avance.

4. Los que se benefician con el resultado.

Luego se procedería con una entrevista a los interesados, en donde se debeentender cuál es la parte relevante de negocio que, justamente, les interesa ydiscutir con ellos para identificar cuál es el proyecto original que alimenta la

necesidad de un proyecto de minería.Siguiendo este ejemplo, es nuestro estudio de viabilidad, analiza si: Las partes interesadas están identificadas. Las partes interesadas tienen disponibilidad de tiempo para avocarse al

proyecto. Existen partes interesadas con recursos suficientes. Las características importantes para las partes interesadas están identificadas.La parte clave de estos pasos es descubrir y caracterizar cuál, cómo y cuánto de

los componentes P3TQ (Product, Price, Place, Time, Quantity) son afectados porel proyecto, qué hay que cambiar para ver la oportunidad o resolver el problemade trasfondo.Las cinco variables de negocio que dan nombre a esta metodología, interactúanmutuamente (figura 3.2.1.1). Por ejemplo, el éxito del lanzamiento de un productodepende, obviamente del cliente, pero las características de ellos, dependen deltiempo y el lugar.

Figura 3.2.1.1 Variables P3TQ

Estas relaciones deben ser reveladas en los datos con las herramientas usadas parala minería de datos.





El siguiente paso tiene que ver con los interesados, es notar quién o qué

departamento originó el proyecto original y qué esperan a cambio.Hasta aquí, se ha analizado sólo un punto de partida de modelado de negocioidentificado por D. Pyle, notemos cuáles son las situaciones que se tienen luego deanalizar esta pequeña fracción de la metodología:

El problema de negocio de trasfondo descubierto no está totalmente dirigido. El proyecto original perdió el apoyo de uno o algunos de los interesados. EL proyecto original falló en entregar los resultados esperados. Los datos fueron recolectados para dirigir una situación específica, pero el

objetivo de la minería sería descubrir si hay algún valor corporativo que sepueda obtener de ellos.

Según la situación, el nivel de riesgo es distinto. Además, Pyle especifica unaacción para resolver el problema en cada una de estos escenarios. Es objetivo deeste trabajo también, analizar estas acciones, descubrir acciones implícitas, ydeterminar el riesgo de realizarlas.El software de Análisis de viabilidad, ubica al usuario en la situación de la

metodología de explotación de datos propuesta por D. Pyle realizando ciertaspreguntas.Adaptando la metodología de D. Pyle al método de cálculo de viabilidad (sección3.1), se identifica primero a qué dimensión pertenece cada una y se le asigna unpeso, determinando en conjunto la viabilidad del proyecto.En la tabla 3.2.1.1, se muestran los ítems que establecen los puntos de riesgo parael modelado de negocio. El software de cálculo de viabilidad es extendible en estesentido, los puntos mostrados en la tabla son los correspondientes a la versión 1.0

del software. La primer columna indica la dimensión de viabilidad a la cuálapunta la pregunta (P: Plausibilidad; A: Adecuación; E: Éxito; J: justificación). Lasegunda columna indica el “Pyle Box” (ver sección 2.3) fuente de la pregunta, quees la “caja” que enumera de alguna manera el factor de riesgo que se identificópara generar la pregunta en cuestión.

3.2.2. Estudio de viabilidad en la metodología de minería de datos

El desarrollo de modelos aptos para la minería requiere análisis, interpretación ycambios sobre los datos de manera cíclica. Las acciones a tomar dependenenteramente del problema de negocio y de lo que el experto en minería descubreen ellos.





Por esta razón debe ser posible realizar tests de viabilidad no sólo antes de

comenzar la minería, sino también a lo largo del desarrollo del proyecto.La metodología P3TQ, comienza el proceso de minería con la preparación de losdatos.Se debe tener en cuenta que el esfuerzo del experto es enfocado en mayor medidaa esta tarea. Es de esperar que la relación sea entre el 60 y 90% del esfuerzo totalavocado a la minería.Esto, apunta a que el test de viabilidad para la minería de datos esté enfocado engran parte hacia el estado de los conjuntos de variables y, por ejemplo, si noexisten errores, si dichas variables y sus valores son congruentes con el modelo denegocio o si son suficientes, además si poseen muchos valores indefinidos, etc.Las cuestiones mencionadas se reflejan en las preguntas que el sistema de cálculode viabilidad muestra al usuario (tabla 3.2.2.1).Pyle establece los pasos a seguir para la preparación de los datos en los boxes 9.x.El siguiente punto más relevante, luego de la preparación de los datos, es laminería en sí, refiriéndonos a los algoritmos utilizados, los conjuntos de variablesde entrada y salida, etc. Estos casos son apuntados por los boxes 11.x.El test de viabilidad en la minería propuesto en este trabajo tiene una bifurcación

según los tres tipos de proyectos de explotación que Pyle identifica: Minería para entender. Minería para clasificar. Minería para predecir.

Minería para entender:

Cuando la cuestión que motiva el proyecto es entender el por qué de unasituación del negocio en particular, el set de datos limita la respuesta que el

encargado de la explotación de la información puede otorgar.Si es posible, la transformación de variables es normalmente de gran ayuda parala comprensión de los resultados y puede hacer más rico un modelo. Tomemoscomo ejemplo de transformación, establecimientos de una empresa dedicada a lalogística georeferenciados, o sea, puntos en particular con latitud y longitudestablecida. Es probable que dada la situación a entender, no sea de relevanciaconocer estos parámetros, pero sí la distancia a un punto en particular de cadaestablecimiento. Naturalmente el minero debería encargarse de transformar lasvariables de latitud y longitud a una variable con el valor de la distancia.

Con este sencillo ejemplo, se intenta demostrar algunos de los puntos quedeterminan el riesgo previamente a comenzar a realizar la tarea de minería. Ya





que, conociendo la cuestión que se debe explicar, el encargado de la explotación

de la información debe analizar previamente: ¿Pueden transformarse los datos demanera que sean importantes para entender la situación, y útiles para explicar elresultado?, ¿pueden las herramientas elegidas, transformar los datos de maneraconveniente?.Además de los puntos relativos a las variables en sí, la explicación de la situación(el resultado final del proyecto), contendrá tanto implícita o explícitamente lasrelaciones entre variables que conforman la parte del modelo concerniente a lasituación particular analizada. ¿Estas relaciones son coherentes?, ¿existenvariables, donde comúnmente se espera un par relacionado, sin estarrelacionadas?, estas cuestiones también hacen que el riesgo del proyecto aumenteo disminuya, son consideradas por este trabajo.Otras cuestiones que influyen directamente en el riesgo de la minería son muchomás triviales, por ejemplo, si están elegidas las herramientas y algoritmos para laminería, si se cuenta con un proveedor de dichas herramientas, la capacidad derespuesta en caso necesitar modificaciones.

Minería para clasificar:

Según D. Pyle, la clasificación es un caso especial de lo que comúnmente sedenomina predicción, debido a que se intenta predecir a qué clase una instanciade dato pertenece en función a ciertos atributos. Se discute el término“predicción” en el siguiente punto (“Minería para predecir”).Por ejemplo, un modelo para clasificar muy común y utilizado muy a menudopedagógicamente es aquel que en función de ciertos atributos de una persona,ésta accedería a un crédito otorgado por un banco o no. Estos atributos pueden sersexo, edad, nivel de estudio, estado civil, región donde vive, etc. El modelo de

clasificación producirá algún tipo de puntuación en función de esos atributos quedetermine si la persona accede o no al crédito.Sin embargo, ocurre en ciertos casos que la puntuación producida por laherramienta de minería no es fácil de interpretar. Supongamos que para el caso encuestión el modelo establezca un resultado booleano de tipo 0= No accede alcrédito, 1 = Accede al crédito. Es probable que luego de la minería, la herramientautilizada calcule un valor entre 1 y 0. Estos casos requieren que el responsable dela explotación haga una interpretación y que tenga los medios necesarios paraello.

Otra cuestión, es que se necesitan varios conjuntos de datos para aplicar laherramienta. Esto se debe a que si se usa un solo conjunto, el modelo interpretará





que las proporciones de cada clase son universales. Siguiendo el ejemplo, si se

otorga un conjunto donde un 30% acceden al crédito y un 70% no, el modelointerpretará que un 30% de los casos acceden al crédito universalmente.Las cuestiones de los párrafos anteriores, influyen directamente en la viabilidadde un proyecto de minería para clasificar ya que, deben ser elegidascuidadosamente las herramientas, saber si se podrán interpretar los datos, oestarán disponibles aquellas personas que puedan interpretarlos. Obviamente, conrespecto a las proporciones de las clases, la viabilidad estará influida por lacantidad de conjuntos de datos que se puedan generar. P3TQ especificaminuciosamente los pasos a seguir para la minería de clasificación, en cada uno deellos se pueden reconocer factores de riesgo que hemos incluido en el desarrollode este trabajo y se reflejan en la herramienta final.

Modelo para predecir:

Quizás el más difícil de los tres objetivos que puede tener un proyecto de mineríaes la predicción.Un modelo para predecir debe ser capaz de arrojar información que no está

presente en el set de datos que toma como entrada. Estos resultados salen de laelaboración de los datos junto con el conocimiento del negocio, por lo tanto, elmodelo debe ser lo suficientemente rico, y se debe poseer expertos en el caso de

negocio que puedan interpretar causas y efectos, con la dinámica de relacionesque interconectan los objetos representados en los datos.Los datos disponibles no contienen un patrón que describa cómo se comportará elsistema de las circunstancias de interés ya que la combinación única de estascircunstancias no ha sucedido aún. Y en esta incertidumbre de comportamientosubyace el trabajo que se le encomendó al encargado de la explotación de lainformación.Ya que no existen herramientas de minería para este propósito, el éxito dependeráen gran parte en la habilidad del experto para seleccionar herramientas existentesy su habilidad para relacionar los resultados que vaya encontrando entre lasdistintas situaciones del negocio, para lo cual necesitará la ayuda y disponibilidadde expertos interesados en el proyecto.

3.2.3. El cuestionario de evaluación

Cada paso de la metodología posee acciones u objetos plausibles de riesgo. Unexperto puede generar riesgo por su ausencia, un conjunto de datos puedegenerar riesgo por poseer demasiados valores nulos, etc.





Presentado ya el método de cálculo de viabilidad, la metodología sobre la cual se

apoyan los proyectos de explotación de la información que consideramos,analizaremos a continuación cómo se presenta la metodología propuesta alusuario final.El interesado en determinar el riesgo de un proyecto deberá ir contestando uncuestionario donde se presentan los posibles escenarios de riesgo para cada pasode la metodología P3TQ.Como P3TQ no es secuencial, no serán tampoco las preguntas presentadas.Según lo que el usuario responda se le mostrarán un conjunto de preguntas uotro.Las preguntas de la tabla 3.2.3.1 están divididas en aquellas que corresponden a laetapa de modelado (Id de la 1 a la 27), las que corresponden a la etapa de minería(27 a 49) y las que manejan la secuencia de la metodología P3TQ (50 a 57). Notarque todas excepto las del tercer grupo tienen un peso asignado y su dimensióncorrespondiente en la tabla (P: plausibilidad, A: adaptabilidad, J: justificación y E:éxito). El peso es la ponderación que tendrán en su dimensión en el cálculo deviabilidad.Las preguntas 50 a 57 tienen peso cero, ya que no evalúan el proyecto, sino que

identifican una situación particular y en función de sus respuestas se mostraráuna secuencia de preguntas o no.

Id

preguntaDescripción Peso Dimensión

1

Las partes interesadas están identificadas? Las partes interesadas son aquellas personas o grupos de

personas que afectan o pueden ser afectadas por el proyecto.Boxes de referencia de la metodología P3TQ:

DB1, AB2, AB3

8 P

2Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de

referencia de la metodología P3TQ: DB1, AB2, AB3

8 P

3Existen partes interesadas con autoridad suficiente dentro de la organización para liderar el proyecto de

explotación? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3

6 E

4Existen partes interesadas con recursos económicos suficientes para encarar el proyecto? Boxes de

referencia de la metodología P3TQ: DB1, AB2, AB3

6 P

50 El proyecto de explotación tiene como propósito buscar relaciones de interés? 0 M

5El proyecto original cuenta con el apoyo de la organización? Boxes de referencia de la metodología P

3TQ:

DB1, AB2, AB310 E

6El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodología

P3TQ: DB1, AB2, AB3

8 P

7

Existe comunicación con las partes interesadas del proyecto original? El proyecto original es aquel que

origina el proyecto de explotación que se está evaluando.Boxes de referencia de la metodología P3TQ:

DB1, AB2, AB3

6 P

8 Se cumplieron los objetivos del proyecto original? 8 P

51El proyecto de explotación tiene como propósito la evaluación de una situación de negocio? (análisis de

problema u oportunidad)?0 M

9

Con respecto a la problemática del negocio del proyecto original: Se han encontrado datos de utilidad para

llevar a cabo la minería? El proyecto original es aquel que origina el proyecto de explotación que se está

evaluando.Boxes de referencia de la metodología P

3

TQ: AB6

5 P

10

Las partes interesadas han identificado o pueden identificar aquellas características del negocio

importantes, que enmarcan sus expectativas del proyecto de explotación? Boxes de referencia de la

metodología P3TQ: TB7

5 A





Id


11La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos

conocidos? Boxes de referencia de la metodología P3TQ: AB6 6 J

12Los Objetivos y Metas del negocio están definidos o pueden definirse? Boxes de referencia de la

metodología P3TQ: AB6, TB5

8 J

52El proyecto de explotación tiene como propósito descubrir en que partes de la organización se puede

agregar valor?0 M

13

Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del

negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB11,

TB3

10 E

14Es conocida la relación entre las cinco temáticas claves del negocio (producto, lugar, precio, tiempo y

cantidad) y el proceso principal de la organización? Boxes de referencia de la metodología P3TQ: AB11

5 A

15

Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII

de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P3TQ:

AB11, MII Tabla 7.1

5 A

16 Existen datos disponibles para explotación? Boxes de referencia de la metodología P3TQ: AB11 10 E

17Esta desarrollado, o es posible desarrollar un esquema de caso de negocio para cada oportunidad

significativa? Boxes de referencia de la metodología P3TQ: AB11

10 P

53 Hay otro propósito especifico? 0 M

18Los requerimientos fueron consensuados con las partes interesadas? Boxes de referencia de la

metodología P3TQ: AB9

10 E


conocidos? Boxes de referencia de la metodología P3TQ: AB9

6 J

20 Existe información disponible para la explotación? Boxes de referencia de la metodología P3TQ: AB9 10 E

54 Se requiere inicialmente un análisis estratégico para planificar escenarios corporativos? 0 M


conocidos? Boxes de referencia de la metodología P3TQ: AB9

2 A

22Existe un mapa del escenario estratégico, consensuado con las partes interesadas. .Boxes de referencia de

la metodología P

3

TQ: AB12

6 A

23Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del

negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB128 A

24Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la


8 A

25Existen o pueden realizarse simulaciones que permitan identificar ambigüedades, incertezas,

discordancias? Boxes de referencia de la metodología P3TQ: AB128 A

26Están caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la


8 E

27

Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII

de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P

3TQ:

AB12, MII Tabla 7.1

4 A

28 Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodología P3TQ: DB9.1 8 P

29El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la

metodología P3

TQ: DB9.18 P

30Existen variables con único valor, o valores vacios en sus instancias? Boxes de referencia de la metodología

P3TQ: DB9.2

-4 P

31 Las variables categóricas están documentadas? Boxes de referencia de la metodología P3TQ: DB9.2 3 A

32Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la

metodología P3TQ: DB9.3

4 A

33Son reconocidas y es posible adecuar variables anacrónicas? Boxes de referencia de la metodología P

3TQ:

DB9.44 A

34

Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre

distintos) y generar un set de entrenamiento y otro de testeo? Boxes de referencia de la metodología

P3TQ: DB9.5, TB9.4

8 E

35Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios más

importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodología P3TQ: DB9.6

10 E

36Es necesario realizar recodificación de variables para mejor comprensión del modelo? Boxes de referencia

de la metodología P3

TQ: DB9.7-4 A

37Los conjuntos de variables de entrada y salida están caracterizadas? Boxes de referencia de la metodología

P3TQ: AB11.1

6 A





Id


38Los datos están estructurados o pueden estructurarse para aplicarlos en la herramienta de minería

elegida? Boxes de referencia de la metodología P3TQ: AB11.1 6 A

39Están seleccionados los algoritmos de minería adecuados al modelo? Boxes de referencia de la

metodología P3TQ: AB11.3

8 A

40Existe una herramienta de minería adecuada al modelo y esta disponible? Boxes de referencia de la


8 A

41De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la


8 P

42Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la


5 P

55 El objetivo de la explotación es entender una situación? 0 M

43Las variables utilizadas en el modelo están relacionadas con conceptos que son conocidos por las partes

interesadas? Boxes de referencia de la metodología P3TQ: AB11.1, DB11.5

8 E

44Los objetos del negocio que representan las variables pueden ser utilizados por las partes interesadas, o

gerentes para realizar mejoras en el negocio. .Boxes de referencia de la metodología P3TQ: AB11.1, DB11,5

8 E

45Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodología

P3TQ: AB11.1 DB11.5

6 E

56 El objetivo de la explotación es aplicar una clasificación? 0 M

46Esta determinado o puede determinarse en la herramienta el tipo de modelo de clasificación inicial (B:

Binario; M : Clases Múltiples o C : Continuo)? Boxes de referencia de la metodología P3TQ: DB11.6

6 E

47La herramienta elegida soporta el tipo de entrada y el tipo de salida del modelo inicial de clasificación?

Boxes de referencia de la metodología P3TQ: DB11.6

8 E

57 El objetivo de la explotación es buscar una predicción? 0 M

48Las herramientas de modelado del sistema están seleccionadas? Boxes de referencia de la metodología

P3TQ: TB11.7

5 E

49Es posible caracterizar las relaciones esenciales entre los conceptos del negocio en las herramientas de

predicción? Boxes de referencia de la metodología P3TQ: DB11.7

6 E

Tabla 3.2.3.1 Cuestionario de viabilidad





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





4. Conclusiones

La metodología P3TQ es muy rica y tiene como principal ventaja detallar cadapaso en función de los objetivos del proyecto y el estado de cada atributo que lodefine.Esto nos ha permitido, reconocer en cada paso aquellas cuestiones que haceriesgoso o fácilmente viable a un proyecto de explotación de la información.Al mismo tiempo reconocemos los distintos tipos dificultades que puedenacarrear un proyecto de explotación de la información. Estas dificultades pueden

ser de distinta naturaleza. Se pueden mencionar dificultades de origen técnico,como la disponibilidad de datos suficientes, la existencia de herramientasadecuadas para el tipo de proyecto que se quiere llevar a cabo, etc. Pero tambiénhay dificultades de otra naturaleza, que no son tan triviales e influyen con granimpacto en el éxito de un proyecto; identificar los interesados, sus expectativas,detectar si conocen con precisión las variables del negocio y la relación entre ellas,

su impacto en los resultados.Todas estas cuestiones deben ser convenientemente analizadas antes de comenzar

a utilizar recursos en explotación de información; para conocer la situación departida del proyecto y qué se pretende como resultado, la importancia de laspersonas en la organización que quieren ese resultado, cómo se va a presentardicha información, etc.Como agregado, no existe hasta el momento un metodología para calcular laviabilidad de proyectos de este tipo, creamos en este trabajo una metodología condicho propósito basándonos en el cálculo de viabilidad propuesto por [Liebowitz1986; Laufman et al, 1990; Adelman, 1989; 1992; De Antonio y Samper, 1990;

Beckam, 1991; López et al 1991].Además se desarrollamos una herramienta de arquitectura web que permiteestudiar la viabilidad de proyectos de explotación de información desarrolladosbajo la metodología P3TQ a lo largo de todo su ciclo.Dicha herramienta está desarrollada con Goolgle App Engine, un nuevo conceptode programación web basado en el lenguaje python, y funcionando enteramente(código y persistencia) en los servidores de Google.Se adjunta el manual de usuario y documentación de desarrollo de la herramienta

junto a este documento.





5. Futuras mejoras

Si bien la herramienta desarrollada es muy completa, incluyendo seguimiento deproyectos, generación de distintas evaluaciones para cada trabajo y manejo deusuarios, además de la funcionalidad básica; el método propuesto es extensible,pueden reconocerse nuevos puntos de riesgo siguiendo minuciosamente los pasosque D. Pyle describe en la metodología P3TQ y agregarse a la metodología.El agregado de nuevos puntos de riesgo no requiere de recodificación de laherramienta, pero sí un agregado cuidadoso en su base de datos, ya que la

metodología P3TQ cumple una secuencia que es respetada en este trabajo.

6. Bibliografía

Pyle, D. (2003). Business Modeling and Data Mining. Morgan KaufmannPublishers.

García-Martínez, R. ; Britos, P. (2004). Sistemas Expertos. Nueva Librería. Chapman, P. ; Clinton, J. (2000). CRISP-DM 1.0: Step by Step Data mining Guide.

The CRISP-DM consortium; 2000 Martelli, A. (2008). Python, Guía de referencia. Anaya Multimedia. Martelli, A. (2006). Python in a Nutshell. O'Reilly. Pérez López, C.; Santin González, D. (2006). Data Mining, Soluciones con

Enterprise Miner. Alfaomega Grupo Editor. Colomes Fornos, X. (2009); Css Dhtml y Ajax Guía Práctica. Anaya

Multimedia. Ochoa, A (2006). Uso de Técnicas de educción para el entendimiento del negocio;

Tesis de Magíster en Ingeniería de Software. Instituto Tecnológico de BuenosAires.

Google (2008). Guía de Introducción de Google AppEngine. Disponible en:http://code.google.com/intl/es-ES/appengine/docs/python/gettingstarted/




Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 24

Anexo 1. Documento de

Desarrollo de la Herramienta

DAMVE





1. Objetivo

El presente documento tiene como objetivo documentar la herramienta softwareDAMVE, que permite ingresar las características de un proyecto que utiliza lametodología P3TQ, con el objetivo de analizar y evaluar su viabilidad.El documento presenta información detallada de cada una de las etapas en eldesarrollo de la herramienta, utilizando siempre que sea posible, el estándar UMLde modelado de software: Requerimientos funcionales, requerimientos no funcionales y restricciones Modelo de análisis (casos de uso) Arquitectura Modelo de diseño Casos de PruebaEl modelo de negocio que debe implementar la herramienta se encuentradocumentado en la Memoria Del Trabajo Profesional, donde se describe latécnica de estudio de viabilidad aplicada a la metodología P3TQ.





2. Funcionalidad del SistemaEl sistema debe proveer la siguiente funcionalidad:

2.1. Evaluación de proyectos

Creación de proyectos que utilizarán o utilizan la metodología P3TQ. Creación de evaluaciones asociadas a un proyecto, que permitan evaluar su

viabilidad a lo largo del tiempo (desde la etapa de concepción y durante

su ejecución). Todas las evaluaciones estarán basadas en una plantilla común de estudio de

viabilidad. Las evaluaciones pueden ser completadas por un usuario en una o varias

sesiones. En el primer caso debe presentarse el resultado de la evaluación. Enel segundo caso la evaluación debe presentarse como "en ejecución".

Las evaluaciones de un proyecto deben presentarse de manera que se puedaanalizar la evolución del proyecto a través de la comparación de dichas

evaluaciones.

2.2. Gestión de usuarios

Deben existir al menos los siguientes roles en el sistema: Líderes de proyecto: son los responsables de la administración del proyecto

pudiendo crear evaluaciones y/o participar en todas las evaluaciones “enejecución” de ese proyecto.

Colaboradores de proyecto: son usuarios asignados por el líder del proyectoy su función es realizar evaluaciones del proyecto. Un colaborador puede,

entonces, crear una evaluación y completarla hasta obtener el resultado deviabilidad. Un colaborador no puede continuar una evaluación “en ejecución”creada por otro colaborador del mismo proyecto.

Evaluador: Es un usuario con mucha experiencia que tiene conocimientosuficiente en proyectos que utilizan la metodología P3TQ y puede actualizar laplantilla de evaluación de estudio de viabilidad de proyectos.

Administrador: Es responsable de la administración de la infraestructura y dela base de datos que consume sistema, como así también de asignar a los

usuarios evaluadores.





3. Cambios en la versiónA continuación se presentan las modificaciones realizadas en las distintasversiones del documento, para facilitar la trazabilidad de los cambios.

3.1. Versión 4

Actualización del objetivo del documento.

3.2. Versión 3 Actualización del objetivo del documento. Se incorporan los casos de prueba, conclusiones y mejoras.

3.3. Versión 2

Se corrigen las referencias en los gráficos. Se incorpora la documentación de paquetes, clases, secuencia, pantallas y

despliegue.

3.4. Versión 1

Versión inicial

4. Especificación de Requerimientos

4.1. Formato

La Figura A1.1 contiene el formato con el cual se registran cada uno de losrequerimientos. A partir de la sección 4.2 se desarrollán todos los requerimientosutilizando dicho formato.

Los campos a completar en dicho registro son los siguientes: Código: comienza con el identificador de tipo: RF si se trata de un requisito

funcional o con RNF si se trata de un requisito no funcional. A continuación seenumeran correlativamente según el tipo (funcional o no funcional). Ej) RF-001(requisito funcional 1)

Relevancia: Se clasifica en Alta, Media o Baja según la regla de negocio /requerimiento no funcional que describa.





Clasificación: Funcional si se trata de un requerimiento funcional o o el tipo

de requerimiento no funcional (ej: Reusabilidad, Portabilidad, Confiabilidad,etc.) Nombre: identificador textual (breve) del requerimiento. Descripción: descripción textual del requerimiento. Control de cambios: debe ingresarse por cada cambio la fecha, persona que

lo solicita y descripción del cambio. Todos los cambios son registrados demanera cronológica ascendente (el primer cambio al comienzo y el últimocambio al final).

Código Relevancia Clasificación Nombre

Descripción

Control de Cambios

Fecha Solicitadopor

Descripción del cambio

Figura A1.1. Formato de registro de los requerimientos del sistema

4.2. Requerimientos funcionales

Los requerimientos funcionales definen las funciones que el sistema será capaz derealizar y describen las transformaciones que el sistema realiza sobre las entradas

para producir salidas.Se presentan a continuación los requerimientos funcionales del sistema.





4.2.1. Crear y Actualizar Proyectos

La Figura A1.2 presenta el requerimiento funcional con el formato establecido.


RF-001 Alta Funcional CREAR Y ACTUALIZAR PROYECTOS

Descripción

El sistema debe permitirle a un usuario registrado crear un nuevo proyecto yconvertirse en su líder.La información que debe ingresarse y guardarse cuando se crea un proyecto es:

Descripción del proyecto Fecha de creación Líder del proyecto (usuario que lo crea)

Deben respetarse las siguientes reglas: Cualquier usuario registrado en el sistema se convierte en el líder de un

proyecto que crea.

Control de Cambios

Fecha Solicitado

por


Figura A1.2. Requerimiento Funcional Crear y Actualizar Proyectos





4.2.2. Creación de Evaluaciones

La Figura A1.3 presenta el requerimiento funcional con el formato establecido.Código Relevancia Clasificación Nombre

RF-002 Alta Funcional CREACIÓN DE EVALUACIONES

Descripción

El sistema debe permitirle al líder del proyecto o a un usuario asignado comocolaborador de del mismo crear una nueva evaluación a partir de la plantillaestándar.La información que debe ingresarse y almacenarse cuando se crea una evaluación

es: Proyecto al cual pertenece Descripción de la evaluación Fecha de creación Usuario que la crea (colaborador o líder del proyecto)

Una vez que la evaluación ha sido creada el sistema debe, automáticamente,presentar la interfaz para que el usuario pueda comenzar a completar el estudiode debilidad.Una evaluación puede ser suspendida, quedando en el estado de "en ejecución".

Control de Cambios

Fecha Solicitadopor


Figura A1.3. Requerimiento Funcional Creación de evaluaciones





4.2.3. Continuar con una evaluación en Ejecución


RF-003 Media Funcional CONTINUAR CON UNAEVALUACIÓN EN EJECUCIÓN

Descripción

El sistema debe permitirle al usuario creador de una evaluación que se encuentraen el estado de "en ejecución " continuar con la misma, presentándole la interfazcorrespondiente.

Control de CambiosFecha Solicitado

porDescripción del cambio

Figura A1.4. Requerimiento Funcional continuar con una evaluación en ejecución





4.2.4. Mostrar resultados del proyecto


RF-004 Alta Funcional MOSTRAR RESULTADOS DELPROYECTO

Descripción

El sistema debe presentar una interfaz que le permita a los usuarios que iniciaronsesión navegar un proyecto cualquiera.

Si el usuario pertenece a dicho proyecto (siendo su líder o colaborador)podrá ver los datos generales del proyecto (descripción, fecha decreación, usuario creador, sus colaboradores) y la informaciónactualizada y resumida de todas las evaluaciones realizadas, incluyendoel resultado final de cada evaluación completada, ordenado de maneracronológica descendente, de manera de poder analizar la evolución delproyecto en el tiempo. Si existen evaluaciones “en ejecución” el sistemadebe comunicarlo y proveer una opción para poder retomar dichaevaluación.

Si el usuario no pertenece al proyecto podrá ver solamente los datosgenerales del proyecto especificados anteriormente y la información delas evaluaciones, pero no su resultado final.

Control de Cambios

Fecha Solicitadopor


Figura A1.5. Requerimiento Funcional Mostrar resultados del proyecto

4.2.5. Actualización de la Plantilla de Evaluación

La Figura A1.6 presenta el requerimiento funcional con el formato establecido.


RF-005 Media Funcional ACTUALIZACIÓN DE LA PLANTILLADE EVALUACIÓN

Descripción

El sistema debe proporcionar una plantilla estándar pre-cargada que permita de

avisar evaluaciones de proyectos por los usuarios del sistema.Además debe proporcionar una interfaz para que el usuario con rol de Evaluador,





pueda actualizar esta plantilla de evaluación, ajustando los siguientes parámetros

en cada pregunta de la plantilla: Texto de la pregunta Dimensión a la que pertenece Peso

Deben respetarse las siguientes reglas: Cuando se actualiza la plantilla estándar las evaluaciones posteriores a

dicha actualización se realizarán con los cambios. Las evaluaciones que se han completado antes de la actualización no

reflejarán los cambios realizados.

Las evaluaciones que se encuentran "en ejecución" no reflejarán loscambios en aquellas preguntas ya contestadas; sin embargo sí lo harán enlas preguntas aún no contestadas.

Control de Cambios

Fecha Solicitado por Descripción del cambio

05/03/2009 AlejandroRodríguez

El administrador debe poderinicializar el cuestionario con valorespor defecto al desplegarse el sistemapor primera vez.

El administrador debe poderrestablecer el cuestionario pordefecto.

Figura A1.6. Requerimiento Funcional Actualización de la Plantilla de Evaluación





4.2.6. Asignación de Colaboradores al Proyecto


RF-006 Alta Funcional ASIGNACIÓN DE COLABORADORESAL PROYECTO

Descripción

El sistema debe permitirle al líder de un proyecto designar colaboradores paraque puedan realizar evaluaciones en dicho proyecto. La información que debeingresarse para poder asignar un colaborador es su nombre de usuario,

coincidente con su dirección de correo electrónico.Una vez que esta información ha sido provista, los usuarios designados puedencolaborar en un proyecto creando evaluaciones. Deben respetarse las siguientesreglas:

Un usuario puede ser colaborador de distintos proyectos.

Un usuario no puede ser colaborador y líder de proyecto al mismotiempo. El rol de líder de proyecto incluye la funcionalidad decolaborador.

Control de CambiosFecha Solicitadopor


Figura A1.7. Requerimiento Funcional Asignación de Colaboradores al Proyecto





4.2.7. Designación de evaluadores


RF-007 Alta Funcional DESIGNACIÓN DE EVALUADORES

Descripción

El sistema debe permitirle al administrador de sistema designar a aquellosusuarios con el rol de evaluadores.La información que debe ingresarse para poder designar a un usuario comoevaluador es su nombre de usuario, coincidente con su dirección de correo

electrónico.Una vez que esta información ha sido provista, los usuarios designados puedenactualizar la plantilla estándar de evaluación de proyecto.Deben respetarse las siguientes reglas:

Todos usuarios evaluadores pueden realizan cambios sobre la únicaplantilla estándar.

Control de Cambios

Fecha Solicitadopor Descripción del cambio

Figura A1.8. Requerimiento Funcional Designación de evaluadores





4.3. Requerimientos no funcionalesLos requerimientos no funcionales tienen que ver con características que de una

u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (entiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,etc.Se presentan a continuación los requerimientos no funcionales del sistema.

4.3.1. Proporcionar tiempos de respuesta aceptables

La Figura A1.9 presenta el requerimiento no funcional con el formato establecido.


RNF-001

Alta Rendimiento PROPORCIONAR TIEMPOS DERESPUESTA ACEPTABLES

Descripción

El sistema debe poseer la capacidad de prestar el servicio con los siguientesniveles aceptables de desempeño, teniendo cuenta la concurrencia de usuarios

Tiempo máximo de actualización de pantalla durante la ejecución de una

evaluación a cada usuario: 5 seg . Cantidad máxima de usuarios concurrentes: 20 usuarios

Control de Cambios


Figura A1.9. Requerimiento no Funcional Designación de evaluadores





4.3.2. Preveer Contingencias Por Caída Del Sistema

La Figura A1.10 presenta el requerimiento no funcional con el formatoestablecido.


RNF-002

Alta Rendimiento PREVEER CONTINGENCIAS PORCAIDA DEL SISTEMA

Descripción

El sistema deberá prever contingencias que pueden afectar la prestación estable ypermanente del servicio.

La siguiente es la lista de las contingencias que se deben tener en cuenta y sepueden considerar críticas: Caída del sistema por volumen de datos excedido en la base. Sobrecarga del sistema por volumen de transferencia de datos a los

usuarios.

Caída del sistema por sobrecarga de recursos (procesos, memoria).Estas consideraciones implicarán que la infraestructura técnica sobre la que seimplantará el sistema garantice una alta disponibilidad del mismo.

Control de CambiosFecha Solicitado por Descripción del cambio

Figura A1.10. Requerimiento no Funcional Preveer Contingencias Por Caída Del Sistema





4.3.3. Considerar El Crecimiento Esperado En El Volumen De Datos



RNF-003

Media Capacidad CONSIDERAR EL CRECIMIENTOESPERADO EN EL VOLUMEN DEDATOS

Descripción

El sistema deberá garantizar el soporte en el crecimiento del volumen de lainformación almacenada que se gestionará en la base de datos.Deben realizarse estimaciones, mediciones y comparaciones para proyectar unestimado de dicho crecimiento, y se presentarse las características de tecnologíarequeridas para afrontar el crecimiento proyectado en el volumen.

Control de Cambios


Figura A1.11. Requerimiento no Funcional Considerar El Crecimiento Esperado En El Volumen De Datos





4.3.4. Parametrizar Las Variables Del Sistema



RNF-004

Media Portabilidad PARAMETRIZAR LAS VARIABLES DELSISTEMA

Descripción

El sistema debe permitir que sus variables y eventos de conFigura A1.ción seanparametrizables e independientes del código fuente.

La modificación de los parámetros configurables será planteada para que elsistema tome sus cambios una vez reiniciado el servidor de aplicaciones y no entiempo de ejecución de tal manera que se disminuya el riesgo de perdida defuncionalidad por configuraciones en el vuelo.Se deberá emplear la tecnología estándar propuesta por Appengine de Google.Las variables que se configurarán, o se presentarán en el archivo de configuración,determinarán fuentes de datos y ubicación de recursos.

Control de Cambios


Figura A1.12. Requerimiento no Funcional Parametrizar Las Variables Del Sis tema





4.3.5. Diseñar interfaces con el usuario amigables



RNF-

005

Media Amigabilidad DISEÑAR INTERFACES CON EL

USUARIO AMIGABLES

Descripción

El sistema debe poseer una interfaz gráfica uniforme a través del mismoincluyendo pantallas, menús y opciones, tamaño de las pantallas, color, tipo deletra y configuración de los campos de entrada.El diseño debe realizarse guiado por las características generales, en cuanto acolores institucionales y disposición de contenidos, encontradas en el sitio web dela organización.Las interfaces deben realizarse en idioma castellano; sin perjuicio de lo cual debeevitar traducirse la terminología técnica específica que no posee una traducciónprecisa al castellano.

Control de Cambios


Figura A1.13. Requerimiento no Funcional Diseñar interfaces con el usuario amigables

4.3.6. Desarrollar manual de usuario



RNF-006

Alta Amigabilidad DESARROLLAR MANUAL DEUSUARIO

Descripción

Debe desarrollarse el Manual de Usuario del Sistema que especifique la totalidadde la funcionalidad que éste provee.Los contenidos del Manual deben estar ofrecidos 100% en línea, en formatoHTML.

Control de Cambios


Figura A1.14. Requerimiento no Funcional Desarrollar manual de usuario





4.3.7. Codificar con estándares



RNF-007

Alta Portabilidad CODIFICAR CON ESTANDARES

Descripción

El código fuente del sistema debe cumplir con un estándar de codificación.El estándar especificado debe considerar puntos como:

Estándares de nombres utilizados en todos sus objetos: programas,formas, tablas, campos, índices, procedimientos, paquetes. Empleo de las características del IDE Eclipse para el formato del código.

Control de Cambios


Figura A1.15. Requerimiento no Funcional codificar con estándares

4.3.8. Permitir niveles de seguridad



RNF-008

Alta Seguridad PERMITIR NIVELES DE SEGURIDAD

Descripción

El sistema deberá permitir que toda su información junto con los procesosdesarrollados por el mismo tenga controles de acceso acordes con el nivel deprivacidad requerido.Los niveles de seguridad estarán determinados por la distribución jerárquica delos usuarios, a saber:

Usuarios Administradores: Acceso total. Usuarios registrados : Podrán tener acceso al información, que

corresponda con su rol (líder de proyecto, colaborador o evaluador)

Control de Cambios






Figura A1.16. Requerimiento no Funcional permitir ni veles de seguridad





4.4. Restricciones

Se presentan a continuación las restricciones del sistema.

4.4.1. Arquitectura del Sistema

La Figura A1.17 presenta la restricción con el formato establecido.


RST-001 Alta Restricciones ARQUITECTURA DEL SISTEMA

Descripción

El Sistema debe desarrollarse sobre la Arquitectura Web Appengine de Google

debiendo utilizarse exclusivamente recursos de software compatibles con ella.Los requerimientos mínimos de la aplicación, corriendo en un servidor local sepresentan a continuación. Los requisitos de hardware del servidor pueden variarsegún los requerimientos de rendimiento:

Procesador 1.0 GHz 512 MB de RAM

Los requerimientos mínimos de software y hardware en el equipo cliente son: Navegador web compatible con Javascript (Recomendado IE7 o

posterior/Firefox 2.0 o posterior) Conexión a Internet, si la aplicación se ejecuta en Appspot de Google o

Interfaz de Red que soporte el protocolo TCP/IP para una conexión local.

Control de Cambios


Figura A1.17. Restricción Arquitectura del Sistema





5. Modelo de análisis5.1. Diagrama de Casos de Uso

La Figura A1.18 presenta el diagrama de Casos de Uso del sistema, basado en losrequerimientos funcionales desarrollados previamente:

ud Casos de Uso

Administrador

Evaluador

Lider de Proyecto

Colaborador de

Proyecto

Crear Proyecto

Evaluar Viabilidad

Crear Evaluación

Validar usuario

Actualizar plantilla

de evaluación

Asignar evaluador

Asignar

Colaborador

Consultar Proyecto

Visitante

Consultar

Evaluación

Inicializar

evaluación

«include»

«include»«include»

«include»

«include»

«include»

«include»

«include»

«include»

«include»

Figura A1.18. Restricción Arquitectura del Sistema





5.2. Matriz de trazabilidad Casos de Uso – Requerimientos

FuncionalesLa Figura A1.19 muestra la matriz de trazabilidad que permite relacionar loscasos de uso del sistema con los requerimientos funcionales, permitiendo conocerque requerimientos funcionales resuelve cada caso de uso.

Caso de Uso RequerimientoFuncional

Id Nombre Id

CU-001 Validar usuario --

CU-002 Asignar evaluador RF–007CU-003 Actualizar planilla de evaluación RF–005

CU-004 Evaluar viabilidad RF–003

CU-005 Crear evaluación RF–002

CU-006 Consultar proyecto RF–004

CU-007 Consultar evaluación RF–004

CU-008 Crear proyecto RF–001

CU-009 Asignar colaborador RF–006

CU-010 Inicializar Evaluación RF–005Figura A1.19. Matriz de trazabilidad Casos de Uso – Requerimientos funcionales





5.3. Realización de los Casos de Uso

A continuación se presenta la realización de cada uno de los casos de uso delsistema.

5.3.1. Validar Usuario

La Figura A1.20 presenta el caso de uso con el formato establecido.

ID CU-001

Nombre VALIDAR USUARIO

Fecha Creación 16/11/2008 Fecha última

modificación

16/11/2008

Actores -

Descripción El sistema verifica que el usuario posea el rol correcto pararealizar una tarea.

Trigger El usuario intenta realizar una acción en el sistema.

Precondiciones

Postcondiciones El operador se encuentra validado en el sistema.

Flujo principal CU-001.0

1. El sistema presenta una pantalla que invita alusuario a ingresar su nombre y contraseña paraautenticarse.

2. El usuario ingresa su nombre y contraseña ypresiona el botón “ingresar”.

3. El sistema verifica los roles que posee el usuario enel sistema (visitante, líder de proyecto, colaboradoro evaluador).

4. El sistema notifica al usuario que está autenticado.

Flujosalternativos

CU-001.1

1. Si el usuario ingresa su nombre y contraseña demanera incorrecta el sistema lo notifica y le solicitaingresar los datos nuevamente, volviendo a CU-001.0

Excepciones

Extensiones -

Incluye -

Heredado por -Prioridad Alta





Reglas de

Negocio

-

Requerimientosespeciales

Hipótesis

NotasFigura A1.20. Caso de uso validar Usuario

5.3.2. Asignar evaluador


ID CU-002

Nombre ASIGNAR EVALUADOR

Fecha Creación 16/11/2008 Fecha últimamodificación

16/11/2008

Actores Administrador

Descripción El administrador del sistema designa a un usuario con el rolde evaluador para que pueda modificar la plantilla estándarde evaluación.

Trigger El administrador accede a la opción agregar evaluadorPrecondiciones El administrador ha iniciado sesión en el sistema.

Postcondiciones Un nuevo usuario cuenta con el rol de evaluador.


1. El sistema verifica que el usuario seaadministrador. De no cumplirse se ejecuta el flujoalternativo CU-002.1.

2. El sistema presenta un formulario que solicita el e-

mail 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

Flujosalternativos

CU-002.1

El sistema notifica al usuario que no cuenta con lospermisos suficientes para llevar a cabo la tarea.

Excepciones -

Extensiones -Incluye CU-001. Validar Usuario





Heredado de -

Prioridad

AltaReglas deNegocio

RF-007


-

Hipótesis -

Notas -Figura A1.21. Caso de uso asignar evaluador

5.3.3. Actualizar planilla de evaluación


ID CU-003Nombre ACTUALIZAR PLANILLA DE EVALUACIÓN


16/11/2008

Actores Evaluador

Descripción El usuario evaluador actualiza las preguntas de la planilla

estándar de evaluación, es la fuente de las futurasevaluaciones de viabilidad de todos los proyectos.

Trigger El evaluador accede a la opción actualizar planilla

Precondiciones El usuario debe contar con el rol de evaluador

Postcondiciones La planilla de evaluación estándar quedaactualizada


1. El sistema verifica que el usuario sea evaluador. De

no cumplirse se ejecuta el flujo alternativo CU-003.1.

2. El sistema presenta un formulario que muestra lainformación de todas las preguntas de la plantillaestándar con la posibilidad de modificar la

descripción, el peso y la dimensión.3. El evaluador actualiza todos los parámetros de

todas las preguntas que consideren necesario y

enviar formulario.4. El sistema actualiza la plantilla estándar y notifica

al evaluador





Flujos

alternativos

CU-003.1

el sistema notifica al usuario que no cuenta con lospermisos suficientes para llevar a cabo la tarea.

Excepciones -

Extensiones -

Incluye CU-001. Validar Usuario

Heredado de -

Prioridad Alta

Reglas deNegocio

RF-005


-

Hipótesis -

Notas -Figura A1.22. Caso de uso actualizar planilla de evaluación

5.3.4. Evaluar viabilidad


ID CU-004Nombre EVALUAR VIABILIDAD


16/11/2008

Actores Líder de proyecto colaborador

Descripción El sistema le permite al usuario creador de una evaluaciónque se encuentra en el estado de "en ejecución" continuar

con la misma, presentándole la interfaz correspondiente.Trigger El líder de proyecto o colaborador accede a la opción

continuar evaluación.

Precondiciones El usuario debe contar con el rol de colaborador enel proyecto en el cual desea continuar laevaluación.

Postcondiciones La evaluación queda actualizada con los pasos delcuestionario cargados

Flujo principal CU-004.01. El sistema verifica que el usuario sea colaborador





del proyecto al cual pertenece la evaluación. De no

cumplirse se ejecuta el flujo alternativo CU-004.1.2. Se repite el siguiente ciclo hasta que el colaboradorcompleta la última pregunta del cuestionario oabandona el cuestionario dejándolo incompleto.a. El sistema presenta todas las preguntas y

respuestas contestadas hasta el momento.b. El sistema presenta un formulario que

muestra la próxima pregunta delcuestionario.

c. El colaborador contesta la pregunta.3. Si el usuario completo todo el cuestionario el

sistema muestra el resultado de la evaluación,ejecutando el caso de uso CU-007.

Flujosalternativos

CU-004.1


Excepciones -


CU-007. Consultar evaluación

Heredado por -

Prioridad Alta

Reglas deNegocio

RF-003

Notas -

Figura A1.23. Caso de uso evaluar viabilidad

5.3.5. Crear evaluación


ID CU-005Nombre CREAR EVALUACIÓN


16/11/2008

Actores

ColaboradorDescripción El sistema le permite al usuario colaborador crear una

evaluación en un proyecto al cual pertenece.





Trigger El colaborador accede a la opción crear nueva evaluación.

Precondiciones

El usuario debe contar con el rol de colaborador enel proyecto en el cual desea crear la evaluación.

Postcondiciones La evaluación queda creada.


1. El sistema verifica que el usuario sea colaboradordel proyecto al cual pertenece la evaluación. De nocumplirse se ejecuta el flujo alternativo CU-005.1.

2. El sistema presenta un formulario para que elcolaborador ingrese la descripción de la

evaluación.3. El colaborador completa de información y envía el

formulario.4. El sistema crea la nueva evaluación, y ejecuta el

caso de uso CU-004, que inicia la evaluación deviabilidad.

Flujosalternativos

CU-005.1

El sistema notifica al usuario que no cuenta con los

permisos suficientes para llevar a cabo la tarea.Excepciones -

Extensiones -

Incluye CU-001. Validar UsuarioCU-004. Evaluar viabilidad

Heredado por -

Prioridad Alta

Reglas de

Negocio

RF-002


-

Hipótesis -

Notas -Figura A1.24. Caso de uso Crear evaluación

5.3.6. Consultar proyecto

La Figura A1.25 presenta el caso de uso con el formato establecido.ID CU-006

Nombre CONSULTAR PROYECTO






modificación

16/11/2008

Actores Líder de proyecto Colaborador

Descripción El sistema le presenta a los miembros del proyecto toda lainformación existente.

Trigger Un usuario del proyecto ingresa a la opción consultarproyecto.

Precondiciones El usuario debe pertenecer al proyecto(líder o colaborador)

Postcondiciones NingunaFlujo principal CU-006.0

1. El sistema verifica que el usuario sea líder ocolaborador del proyecto. De no cumplirse seejecuta el flujo alternativo CU-006.1.

2. El sistema presenta la siguiente información delproyecto al usuario, dando la opción de que la

información pueda ser impresa en papel. Fecha de creación Descripción Líder Colaboradores

Lista de evaluaciones realizadas ordenadas en formacronológica descendente (incluye fecha de creación,colaborador de la creo, descripción, estado: sí está finalizada

el resultado de la evaluación; sino el mensaje en ejecución).

Flujos

alternativos

CU-006.1


Excepciones -

Extensiones -

Incluye CU-001 : Validar Usuario

Heredado de -

Prioridad Alta

Reglas de

Negocio

RF-004


-





Hipótesis -

Notas -Figura A1.25. Caso de uso consultar proyecto

5.3.7. Consultar Evaluación


ID CU-007

Nombre COSULTAR EVALUACIÓN


16/11/2008

Actores Líder de proyecto

ColaboradorDescripción El sistema le presenta a los miembros del proyecto la

información de una evaluación.

Trigger Un usuario del proyecto ingresa a la opción consultarEvaluación.

Precondiciones El usuario debe pertenecer al proyecto (líder o colaborador)la evaluación debe estar finalizada.

Postcondiciones Ninguna


1. El sistema verifica que el usuario sea líder ocolaborador del proyecto. De no cumplirse seejecuta el flujo alternativo CU-007.1.

2. El sistema presenta la siguiente información de laevaluación al usuario proveyendo la opción deimprimir en papel. Fecha de creación Proyecto al cual pertenece Colaborador de la creo Descripción Resultado final expresado numérica y

gráficamente. Todas las preguntas y respuestas de la

evaluación que fueron respondidas y que

justifican el resultado.Flujosalternativos

CU-007.1

El sistema notifica al usuario que no cuenta con los





permisos suficientes para llevar a cabo la tarea.

Excepciones -Extensiones -

Incluye CU-001 : Validar Usuario

Heredado de -

Prioridad Alta

Reglas deNegocio

RF-004


-

Hipótesis -

Notas -Figura A1.26. Caso de uso con sultar evaluación

5.3.8. Crear proyecto


ID CU-008

Nombre CREAR PROYECTO


16/11/2008

Actores Visitante

Descripción El sistema le permite a un usuario registrado crear un nuevoproyecto y convertirse en su líder.

Trigger El usuario accede a la opción crear nuevo proyecto.

Precondiciones -

Postcondiciones El proyecto queda creado.

Flujo principal CU-008.01. El sistema presenta un formulario para que el

usuario ingrese la descripción del nuevo proyecto.2. El usuario completa de información y envía el

formulario.3. El sistema crea el nuevo proyecto.

Flujosalternativos

-

Excepciones -Extensiones -






Heredado por -Prioridad Alta

Reglas deNegocio

RF-001


Hipótesis

NotasFigura A1.27. Caso de uso Crear proyecto

5.3.9. Asignar colaborador


ID CU-009

Nombre ASIGNAR COLABORADOR


16/11/2008

Actores Líder de proyecto

Descripción El líder de un proyecto designa a un usuario con el rol decolaborador para que pueda crear nuevas evaluaciones endicho proyecto.

Trigger El líder del proyecto accede a la opción agregar colaborador

Precondiciones El líder de proyecto ha iniciado sesión en elsistema.

Postcondiciones Un nuevo usuario cuenta con el rol de colaborador.


1. El sistema verifica que el usuario sea líder delproyecto. De no cumplirse se ejecuta el flujoalternativo CU-009.1.

2. El sistema presenta un formulario que solicita el e-

mail del usuario a registrar como colaborador.3. El líder del proyecto ingresa el e-mail del usuario.4. El sistema agrega al usuario como colaborador y

notifica al líder del proyecto

Flujosalternativos

CU-009.1El sistema notifica al usuario que no cuenta con lospermisos suficientes para llevar a cabo la tarea.





Excepciones -


Heredado por -

Prioridad Alta

Reglas deNegocio

RF-006


Hipótesis

NotasFigura A1.28. Caso de uso asignar colaborador

5.3.10. Inicializar cuestionario


ID CU-010

Nombre INICIALIZAR CUESTIONARIO


modificación

05/03/2009

Actores AdministradorDescripción El administrador del sistema inicializa la Plantilla estándar

de evaluación de proyectos con los valorespredeterminados.

Trigger El administrador accede a la opción de inicializar Plantilladevaluación.

Precondiciones El administrador ha iniciado sesión en el sistema.

Postcondiciones La Plantilla estándar de evaluación de proyectos seencuentra inicializada con los valores por defecto.


1. El sistema verifica que el usuario seaadministrador. De no cumplirse se ejecuta el flujoalternativo CU-010.1.

2. El sistema presenta un formulario que solicita aladministrador del sistema su confirmación para

inicializar la Plantilla de evaluación con los valorespor defecto.





3. Si el administrador contesta “sí” entonces se

ejecuta el flujo alternativo CU-009.2. Si eladministrador contesta “no” se ejecuta el flujoalternativo CU-009.3

Flujosalternativos

CU-009.1


CU-009.2El sistema inicializa la Plantilla de evaluación con losvalores por defecto y notifica al administrador sobre laacción.

CU-009.3El sistema notifica al usuario que no se realizó la

inicialización del cuestionario.

Excepciones -

Extensiones -


Heredado por -

Prioridad AltaReglas deNegocio

RF-005


Hipótesis

NotasFigura A1.29. Caso de uso inicializar cuestionario





6. Arquitectura del Sistema6.1. La arquitectura Appengine

La Figura A1.30 presenta un gráfico que resume las principales componentes dela arquitectura propuesta por Appengine y que, en líneas generales, respeta elclásico patrón MVC y que será la base del desarrollo del Sistema.

Figura A1.30. Arquitectura de Appengine

Entidades persistentes: Appengine provee una capa destinada al modeladode entidades persistentes. Si bien la persistencia y el modelo de negocio estáncompletamente acoplados en esta capa (Patrón Active Record) Appengineprovee un framework de persistencia que permite abstraerse del modelo

relacional y trabajar con entidades, utilizando operadores en las entidades y ellenguaje GQL para realizar consultas de objetos.

Controlador RequestHandler. Appengine provee un controlador queencapsula el protocolo http y permite capturar la interacción del usuario através de comandos GET o POST, que se traducen en Requests o pedidos. Elcontrolador se programa según se requiera y se presentarán los resultadosutilizando plantillas (ver a continuación) a través de Responses o respuestas.





Plantillas de Vista: Appengine provee un framework basado en Django para

desarrollar las vistas HTML utilizando plantillas (Patrón Template View) yfomentando la reutilización y desacople con el modelo de negocio.





7. Diseño de la aplicaciónEn esta sección se detallará el diseño elegido para implementar el sistema. Latécnica elegida para llevar a cabo la tarea consiste en presentar los modelos de logeneral a lo particular. Se comenzara por presentar los paquetes que componen la aplicación y su

relación. Posteriormente se describirá cada paquete como un conjunto de clases que

colaboran para resolver alguna parte del sistema, utilizando diagramas declase UML.

Finalmente se describirán las responsabilidades de las clases más relevantesdel paquete.

Una vez presentados en detalle cada uno de los paquetes y las clases del sistemase utilizarán diagramas de secuencia que permitan comprender la dinámica delsistema a través de la interacción de las clases de distintos paquetes.

7.1. Diagrama de Paquetes de clases

A partir de la arquitectura presentada, que está basada fundamentalmente en elpatrón MVC, se diseñaron los paquetes que interrelacionados implementan lafuncionalidad del sistema.

La categorización por colores que se presenta en la Figura A1.31 será utilizadade aquí en adelante en este documento, para facilitar la comprensión delmismo.

Modelo

Vista

Controlador

InfraestructuraFigura A1.31. Código de color para cada una de las categorías de paquetes de la aplicación

El diagrama presentado en la Figura A1.32 muestra los paquetes de las clases delsistema y sus dependencias, categorizando cada uno de ellos por medio de coloresque permiten identificar a qué categoría pertenecen.

Las categorías existentes son las tres definidas en el modelo MVC (modelo, vista ycontrolador) más una cuarta denominada infraestructura. Esta cuarta categoría enprovista por el entorno Appengine e implementa los servicios de base que





permitan desarrollar una aplicación dentro de la arquitectura. Algunos de los

servicios dentro de la categoría son: Persistencia de entidades. Acceso a archivos del sistema operativo. Motor de plantillas para representación de página web dinámicas. Autenticación de usuarios.Estos servicios son parte de la infraestructura de la aplicación y, generalmente,son consumidos por una o más de las tres categorías de MVC.

pd Paquetes

dbmodel

+ Answer

+ Evaluation

+ EvaluationInstance

+ Evaluator

+ NextQuestion

+ Project

+ ProjectMember

+ Question

+ Result

google.appengine.ext

+ db

+ webapp

+ webapp.template

google.appengine.api

+ users

view

+ CustomView

+ EvaluationDraw

menu

+ menu

evaluatorform

+ AddMemberPage

+ Evaluate

+ MainPage

Figura A1.32. Diagrama de paquetes de la aplicación categorizados por color

Por simplicidad para el entendimiento se ha omitido la representación en eldiagrama todos los paquetes de la categoría controlador del sistema, incluyendosolamente el paquete controlador evaluatorform . Para una descripción detallada

de cada uno de los paquetes controladores debe leerse la sección 7.4 de este

documento.

Infraestructura

Modelo

Vista

Controlador





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 lospaquetes de infraestructura ya que han sido muy bien documentados porAppengine.Nuevamente la columna tipo permite identificar la categoría a través de su colorasociado.

Nombre Tipo CU queimplementa

Descripción

dbmodel Modelo Todos Contiene las clases queimplementan el modelo de laaplicación, incluyendo supersistencia.

view Vista - Implementa funcionesgenéricas de representaciónde los datos en formatoHTML.

evaluatorform Controlador CU-004

CU-005CU-007

Creación, ejecución y cálculo

de una evaluación deviabilidad para un proyecto.

choose_project Controlador CU-008 Selección de un proyecto.

view_project Controlador CU-006CU-009

Creación y consulta enproyecto.

add_evaluator Controlador CU-002 Agregar evaluadores.

help Controlador CU-001 Inicio y cierre de sesión elsistema. Manual de Usuario.

data Controlador CU-003 dosCU-010

Inicialización 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 lógica del estudio de viabilidad,incluyendo aquellas clases que son consideradas entidades y, por ende, deben serpersistentes.

Esta capa se desarrolla dentro del componente de Modelo y Persistencia deAppengine. 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:





7.2.1. Nivel1. Cuestionario

En este nivel se encuentran las entidades que modelan el cuestionario: laspreguntas, las respuestas admitidas para cada pregunta, y la secuencia dinámicaque permite conocer la próxima pregunta a partir de una pregunta respondidacon una respuesta determinada. Este nivel implementa un grafo dirigido nocerrado, que representa todas las posibles secuencias del cuestionario.Este nivel, en resumen, representa una plantilla de un cuestionario dinámico. Eltérmino dinámico se refiere a que el cuestionario cambia según las preguntasrespondidas anteriormente.

7.2.2. Nivel 2. Estudio de Viabilidad

En este nivel se encuentran las entidades que modelan el estudio de viabilidadpropiamente dicho: los proyectos, las evaluaciones realizadas para dichosproyectos. Debido a que las evaluaciones se realizan por medio de uncuestionario, este nivel es dependiente del anterior. Cada evaluación es unainstancia de una plantilla de cuestionario, cuyas preguntas son respondidas conalgún valor de respuesta admitido y cuya secuencia está determinada por dichosvalores.

A continuación se presenta en la Figura A1.34 un gráfico esquemático quepermite relacionar los dos niveles de la capa de dominio:

Figura A1.34. Ejemplo de los dos niveles existentes en la capa de dominio





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 opcionesdel cuestionario comenzando desde la pregunta uno y finalizando en la pregunta6 o en la pregunta 4. No es necesario que el cuestionario finalice siempre en lamisma pregunta, ya que una pregunta del cuestionario es la última cuando poseemenos del total de opciones de aristas dirigidas hacia otras preguntas (vértices).En el ejemplo si se llega a la pregunta 6, el cuestionario finaliza porque no existearista que conduzca hacia otra pregunta. Por otra parte, si se llega a la pregunta 4y se contesta “no“, el cuestionario también finaliza ya que no existe arista con esevalor que conduzca a una próxima pregunta. Si llegando a la pregunta cuatro se

contestara "sí" entonces el cuestionario si continuaría porque existe un arista condicho valor que conduce de la pregunta 4 a la pregunta 5.Observando ahora el nivel 1 se observa una instancia del cuestionario que ha sidorespondida y, por ende posee sólo un camino lineal.Al comenzar el cuestionario el usuario contestó con el valor "no" la pregunta 1,con lo cual el grafo lo llevó a la pregunta 2. En este caso contexto con el valor "sí",pasando entonces a la pregunta 3. Siguiendo la secuencia el cuestionario finalizacuando el usuario llega a la pregunta 6 y la responde.

Como puede verse esta técnica de grafos permite una gran flexibilidad almomento de diseñar los cuestionarios.

7.2.3. Diagrama de Clases

Se ha presentado anteriormente una explicación coloquial del diseño del modeloen dos niveles. En esta sección se presentará el modelo de software elegido paraimplementarlo, a través de un diagrama de clases UML que se muestra en la

Figura A1.35:





cd Modelo

db.Model

Question

+ category: db.TextProperty

+ description: db.TextProperty

+ dimen sion: db.TextProperty

+ idquestion: db.IntegerProperty

+ thresholdvalu e: db.TextProperty

+ type: db.TextProperty

+ weight: db.IntegerProperty

+ dimensionText()

+ nextQuestions() : q:Question[]

+ vali dAnswers() : a: Answer[]

db.Model

NextQuestion

+ idanswer: db.IntegerProperty

+ idnextquestion: db.IntegerProperty

+ idque stion: db.IntegerProperty

+ answer() : Answer

+ nextQuestion() : Question

+ question() : Question

db.Model

Answer

+ description : db.TextProperty


db.Model

Project

+ createdate: db.DateTim eProperty


+ owner: db.UserProperty

+ releasedate: db.DateTime Property

+ testdate: db.DateTim eProperty

+ addEvaluati on(string, Evaluati on)

+ addMem ber(string, string)

+ currentUserIsMember()

+ getEvaluatio ns() : Evaluatio n[]

+ removeMember(string, string)

+ userIsMember(string)

db.Model

Evaluation

+ actualresult: db.IntegerProperty

+ createdate: db.DateTim eProperty


+ idproject: db.ReferenceProperty(Project)

+ owner: db.UserProperty

+ calcu late() : Result

+ isComple te() : bool

+ lastQuestion() : Question

+ nextQuestion() : Question

+ questions() : Question []

Result

+ adaptabi lidad: array[4]

+ completo: bool

+ exito: array[4]

+ justificacion: array[4]

+ plausibidad: array[4]

+ resultado : array[4]

+ A() : float

+ E() : float

+ J() : floa t

+ P() : float

+ viability(var)

db.Model

Ev aluationInstance


+ dimen sion: db.TextProperty


+ idevalua tion: db.ReferenceProperty(Evaluation)

+ idinstance: db.IntegerProperty

+ idquestion: db.IntegerProperty

+ thresholdvalu e: db.TextProperty

+ type: db.TextProperty

+ weight: db.IntegerProperty

+ answerText(var)

+ dimensionText(var)

Nivel 2. Estudio de

Viabilidad

Nivel 1. Questionario

db.Model

ProjectMember

+ idproject: db.ReferenceProperty(Project)

+ membe r: db.UserProperty

+ role: db.TextProperty()

db.Model

Evaluator

+ evaluator: db.UserProperty

+ all(Evaluator[])

+ remove(string)

+ userIsEvaluator(var)

User

+ email: Text

+ nickname: Text

Provisto por el UserAPI de Appengine

1

1

1

1

1

1

1

1

*

1

111 1

1Evaluation Result

1

1

1

*

questions

1

*

evaluations

1

Figura A1.35. Diagrama de clases del paquete dbm odel

El Nivel 1 del modelo está implementado por las siguientes clases: Question: implementa la pregunta con todos sus atributos (identificador de

pregunta, categoría de la metodología P3TQ, texto de la pregunta, dimensiónde la viabilidad, umbral, tipo y peso). El tipo de pregunta permite conocercuáles son las posibles respuestas admitidas. Por ejemplo el tipo booleanosolamente admitir a valores “si” y “no”. Mientras que el tipo “ difuso”

admitirá los valores "ninguno", "muy poco", "medio", "alto", "muy alto". Estaclase representa, entonces, los vértices del grafo.





NextQuestion: implementa la relación existente entre una pregunta del

cuestionario y la siguiente. La clase posee tres atributos que son elidentificador de la pregunta respondida, el valor de respuesta de dichapregunta y el identificador de la próxima pregunta en el cuestionario. Conestos tres atributos puede conocerse cuál es la próxima pregunta delcuestionario 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 preguntasdel cuestionario. Posee solamente dos atributos (identificador la respuesta ydescripción).

El Nivel 2 del modelo está implementado por las siguientes clases: EvaluationInstance: Implementa una pregunta del cuestionario respondida

para una evaluación determinada. Esta clase se encarga de copiar todainformación de la pregunta que instancia y el valor de respuesta que elusuario haya ingresado.

Evaluation: implementa una evaluación completa realizada por un usuario.Sus atributos son el creador de la evaluación, la fecha de creación, su

descripción y su estado actual. La evaluación permanece abierta mientras nose haya alcanzado una última pregunta de cuestionario; y se encuentra cerradaen caso contrario, pudiéndose conocer el resultado del evaluación. Esta clasese encarga de obtener la secuencia de preguntas del cuestionario consumiendolas clases del nivel 1. Cuando el cuestionario finaliza posee una operacióncalculate() que permite conocer el resultado del evaluación de viabilidad.

Result: Esta clase encapsula el resultado de un estudio de viabilidad, obtenidoa partir de una evaluación completa. Posee cinco atributos correspondientes a

los cuatro sectores de las dimensiones del estudio de viabilidad, más el vectorresultado final.

Project: esta clase implementa un proyecto en el cual su creador ycolaboradores crearán evaluaciones para estimar su viabilidad. Sus atributosson su identificador, su usuario propietario (líder de proyecto), sus miembroscolaboradores (implementado a través de la clase ProjectMember), sudescripción y su fecha de creación.

Evaluator: implementa los usuarios que tienen la capacidad de modificar losatributos del cuestionario de evaluación. Posee una operación de clase llamada

all(), que permite obtener una colección de todos los usuarios con rol deevaluador y una operación llamada userIsEvaluator() que permite conocer,





dada una dirección de correo electrónico, si un usuario posee el rol de

evaluador o no.

7.3. View. Paquete de soporte para vista.

Las clases pertenecientes a este paquete, que se muestran en la Figura A1.36,tienen la responsabilidad de generar contenidos para la interfaz de usuario.

cd view

object

Ev aluationDraw

+ accepted: bool = 60

+ draw: bool

+ evaluation: Evaluation

+ maxsize: int = 100

+ createArray(Evaluati on[]) : Evaluat ionDraw[]

+ drawA() : string

+ drawBar(int) : string

+ drawE() : string

+ drawJ() : string

+ drawP() : string

+ drawViabil ity() : string

+ getEvaluation() : Evaluation

+ setEvaluation(Evaluation)

object

CustomMenu

+ getCustomMenu () : string

Logical Model::

User

+ email: Text

+ nickname: Text

db.Model

Logical Model::Evaluator

+ evalua tor: db.UserProperty

+ all(Evaluator[])+ remove(string)

+ userIsEvaluator(var)

1 1

Figura A1.36. Diagrama de clases del paquete view

EvaluationDraw : Esta clase tienen la responsabilidad de generar un gráficode barras en código HTML de cada una de las dimensiones de una evaluación,desacoplando la responsabilidad de dibujo en la clase de dominio. Almacenaun objeto de la clase Evaluation (atributo evaluation), el tamaño máximo deescala (atributo maxsize). Existe una operación de clase que funciona como

factory para crear una colección de objetos EvaluationDraw a partir de unacolección de objetos Evaluation. El motor de renderización de la vista (django),entonces, utiliza objetos EvaluationDraw, con los cuales puede acceder a todala información de una evaluación y, además, podrá dibujar gráfico de barras

con dicho información. Las operaciones de dibujo son DrawBar , que permitedibujar un gráfico de barras genérico, a partir de un valor resultado entre ceroy 10. Las operaciones drawP, drawA, drawJ, drawE y drawViability permitendibujar gráfico de barras para las dimensiones de plausibilidad a,

adaptabilidad, justificación, éxito y el resultado final de viabilidadrespectivamente.





CustomMenu: esta clase tiene la responsabilidad de generar una colección de

opciones del menú de usuario según el rol que posea el usuario estáejecutando la aplicación. Para esto, verifica si el usuario es administrador y/oevaluador y devuelve en la colección opciones específicas para estos roles. Elmotor de renderización de la vista recibe siempre una colección de opcionesque le permite mostrar la funcionalidad específica por rol.

7.4. Paquetes de Controladores

Como se explicó anteriormente, todos los controladores implementan la interfazde webapp.RequestHandler, la cual posee las siguientes operaciones: get(): permite procesar un pedido GET del protocolo http. put(): permite procesar un pedido PUT del protocolo http. redirect(): permite redireccionar a un nuevo enlace el cliente http.Para poder procesar los predios de un cliente cuenta con los siguientes atributos: request: este objeto encapsula la información de solicitud de un cliente,

fundamentalmente toda las variables y sus valores enviados. response: este objeto permite que el controlador escriba los resultados del

proceso, generalmente en formato HTML.

A continuación se presentan los diagramas de clase de cada uno de los paquetesque conforman los controladores de la aplicación.

7.4.1. evaluatorform

La Figura A1.37 muestra las clases que componen este paquete.





pd ev aluatorform

MainPage

+ get() : void+ put() : void+ redirect(string) : void

AddMemberPage


Ev aluate


Logical Model::webapp.

RequestHandler

+ request:+ response:


ev aluatorform.htmlerror.html ev aluate.htmlview_project.html

Figura A1.37. Diagrama de clases del paquete evaluatorform

Las clases de este paquete son: AddMemberPage : esta clase tiene la responsabilidad de agregar o eliminar a

un colaborador del proyecto. MainPage: esta clase tiene la responsabilidad de recibir las respuestas de cada

pregunta del cuestionario de evaluación, a guardar las y presentarle al usuariola próxima pregunta a responder.

Evaluate: esta clase tiene la responsabilidad de presentarle al usuario elresultado de un estudio de viabilidad para una evaluación finalizada.

7.4.2. Add Evaluator La Figura A1.38 muestra las clases que componen este paquete.





cd add_eva luator

webapp.RequestHandler

MainPage

+ get() : void

+ put() : void

+ redirect(string) : void

webapp.

RequestHandler

+ request:

+ response:

+ get() : void

+ put() : void


add_evaluator.html

error.html

Figura A1.38. Diagrama de clases del paquete add_evaluator

Las clases de este paquete son: MainPage: esta clase tiene la responsabilidad de agregar o eliminar un

evaluador del sistema, que puede modificar la plantilla de evaluación deproyectos.

7.4.3. Choose_project

La Figura A1.39 muestra las clases que componen este paquete.





cd choose_projec t



MainPage

+ get() : void+ put() : void+ redi rect(string ) : void

webapp.

RequestHandler


+ get() : void+ put() : void+ redi rect(string ) : void

choose_project.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 losproyectos de sistema y presentárselos al usuario para que este seleccione uno.En caso de que el usuario de es crear un nuevo proyecto esta clase se encargade hacer persistente este nuevo proyecto en el sistema.





7.4.4. Help

La Figura A1.40 muestra las clases que componen este paquete.cd help


AboutPage

+ get() : void

+ put() : void



LogoutPage

+ get() : void

+ put() : void



LoginPage

+ get() : void

+ put() : void


webapp.

RequestHandler

+ request:

+ response:

+ get() : void

+ put() : void


about.html login.htmllogout.html

Figura A1.40. Diagrama de clases del paquete help

Las clases de este paquete son: AboutPage: esta clase tiene la responsabilidad de presentarle al usuario el

manual de ayuda. LoginPage: esta clase tiene la responsabilidad de autenticar al usuario,

abriendo la sesión en caso de que los datos de ingreso se han correctos. LogoutPage : esta clase tiene la responsabilidad de cerrar la sesión de un

usuario.





7.4.5. View_project

La Figura A1.41 muestra las clases que componen este paquete.cd view_project




MainPage


webapp.

RequestHandler


+ get() : void+ put() : void+ redirect (string ) : void

view_project.htmlview_project.csv

Figura A1.41. Diagrama de clases del paquete view_project

Las clases de este paquete son: MaintPage: esta clase tiene la responsabilidad de recuperar y mostrar al

usuario toda la información de un proyecto y de crear nuevas evaluaciones.





7.5. Diagramas de SecuenciaA continuación se presentan los diagramas de secuencia que permiten

comprender cómo colaboran las clases de las distintas categorías (modelo, pista,controlador e infraestructura) para resolver la funcionalidad requerida.Se han incluido aquellas secuencias que se consideran fundamentales para elsistema. Las restantes se resuelven de manera análoga a las presentadas o sonmuy simples de implementar por lo cual su representación gráfica no agregavalor.Además del diagrama se describirán brevemente los escenarios dentro de loscuales transcurre cada secuencia.

7.5.1. Crear Proyecto

Escenario: El usuario ha iniciado sesión en el sistema. Se encuentra frente a lapantalla de selección de proyectos y desea crear un nuevo proyecto,completando una descripción para el mismo y enviando el formulario. Seconsidera que no ocurren errores o excepciones. A continuación se presenta en

la Figura A1.42 el diagrama de secuencia.sd Crear Proyecto

Usuario choose_project view_project::MainPage

LogicalModel::Project

users

view_project

POST(description)

post(description)

user:= get_current_user

project:= <<new>> description, user

put()

render(project)

render

Figura A1.42. Diagrama de secuencia Crear proyecto.





7.5.2. Crear Evaluación

Escenario: El usuario ha iniciado sesión en el sistema y ha seleccionado unproyecto. Se encuentra frente a la pantalla de consulta de dicho proyecto ydesea agregar una nueva evaluación, ingresando, para ello, una descripciónpara la nueva evaluación y enviando el formulario. Se considera que noocurren errores o excepciones. A continuación se presenta en la Figura A1.43 el diagrama de secuencia.

sd Crear Evaluacion

Miembro view_project evaluatorform::evaluate

users

LogicalModel::Evaluation

run

POST(create,idproject,description)

post(create,idproject,description)

user:= get_current_user

eval:= <<new>>(idproject,user,description)

put()

q:= questions()

nq:= nextQuestion()

render(idproject,eval,q,nq)

render

Figura A1.43. Diagrama de secuencia Crear evaluación.

7.5.3. Contestar Pregunta

Escenario: El usuario ha iniciado sesión en el sistema, ha seleccionado un

proyecto y ha creado una nueva evaluación para el mismo, o retomado unaevaluación previamente creada y aún no completada. Se encuentra frente a lapantalla de ejecución de la evaluación y desea completar la siguiente preguntadel cuestionario. Selecciona entonces la respuesta que considera correcta yenvía el formulario. Se considera que no ocurren errores o excepciones. Acontinuación se presenta en la Figura A1.44 el diagrama de secuencia.





sd Contestar Pregunta

Miembro run evaluatorform::

evaluate

db eval :Evaluation

ev :EvaluationInstance

Si la evaluación

está completa.

POST(idevaluation,idanswer)

post(idevaluation,idanswer)

eval:= get(idevaluation)

nq:= nextQuestion()

ev:= <<new>> (idanswer, eval, nq.weight, nq.dimension)

put()

q:= questions()

nq2:= nextQuestion()

idproject:= idproject

[eval.isComplete==false]: render(idproject,eval,nq2,q)

render

Figura A1.44. Diagrama de secuencia contestar pregunta.

7.5.4. Calcular Evaluación

Escenario: El usuario ha iniciado sesión en el sistema, ha seleccionado un

proyecto y ha seleccionado una evaluación completa, o retomado unaevaluación previamente creada y aún no completada. Se encuentra frente a lapantalla de ejecución de la evaluación y desea completar la siguiente preguntadel cuestionario. Selecciona entonces la respuesta que considera correcta yenvía el formulario. Se considera que no ocurren errores o excepciones. Acontinuación se presenta en la Figura A1.45 el diagrama de secuencia.

sd Calcular Evaluación

Miembro evaluate evaluatorform::

evaluate

eval :Evaluation

Si la evaluación

está completa.

[eval.i sCompl ete]: result:= calcul ate()

render(eval,q,result)

render

Figura A1.45. Diagrama de secuencia Calcular Evaluación.





7.6. Secuencia entre Pantallas

Las pantallas del sistema han sido presentadas separadamente en cada uno de losdiagramas de clase del controlador.El diagrama que se muestra a continuación la Figura A1.46 permite ver, a travésde un diagrama de estados UML, como se relacionan entre sí a partir de lainteracción del usuario con el sistema.

sm Statecharts

choose_project

view_project

add_evaluator

evaluate

Logout

run

about

login

edit

clear

ayuda

nueva evaluación carga de pregunta del cuestionario

agregar evaluador (usuario admi nistrador)

evaluación completa

ejecución de evaluaciónagregado de nuevo colaborador

creación de un proyecto

selección de evaluación finalizada

selección de un proyecto

abrir sesión

cerrar sesión

editar plantilla de evaluación

Inicializar plantilla de evaluación

Figura A1.46. Diagrama de estados para la transición entre las pantallas del sistema.

A continuación se presentan cada una de las pantallas que componen el sistema, ylas interfaces con el usuario.

7.6.1. Logout

Esta pantalla, mostrada en la Figura A1.47, se presenta cuando el usuario deseaingresar al sistema y aún no sea autenticado, o cuando decide salir, cerrando lasesión.





Figura A1.47. Pantalla Logout.

7.6.2. Login

Esta pantalla, mostrada en la Figura A1.48, es provista por el API user delappengine, para que el usuario pueda autenticar se en el tenga a través de su e-mail y contraseña.

Figura A1.48. Pantalla Login.

7.6.3. Choose Project

Esta pantalla, mostrada en la Figura A1.49, presenta al usuario una tabla con losproyectos existentes en el sistema, mostrando la fecha de creación, la descripción,el e-mail del líder del proyecto, la cantidad de evaluaciones realizadas y el rol quetiene el usuario en dicho proyecto. El usuario puede elegir cualquiera de losproyectos para consultar la información existente. También presenta una interfazpara que el usuario pueda crear un nuevo proyecto ingresando un nombre para elmismo.

Figura A1.49. Pantalla Choose Project.

7.6.4. View Project

Esta pantalla, mostrada en la Figura A1.50 presenta al usuario toda lainformación referente a un proyecto que él ha seleccionado. Muestra lainformación de fecha de creación, líder de proyecto, colaboradores y evaluacionesrealizadas. Para estas últimas muestra la fecha de creación, descripción, autor y, si





han sido finalizadas, el resultado. También provee interfaces para crear una nueva

evaluación en dicho proyecto, agregar colaboradores al proyecto en caso de que elusuario sea el líder y opciones para exportar la información o imprimir.

Figura A1.50. Pantalla View Project.

7.6.5. Run

Esta pantalla, mostrada en la Figura A1.51, le presenta al usuario una interfazpara que pueda completar el cuestionario de evaluación. Muestra el nombreproyecto, el nombre de la evaluación, la dimensión, peso y descripción de lapregunta y las opciones de respuesta.

Figura A1.51. Pantalla run.





7.6.6. Evaluate

Esta pantalla, presentada en la Figura A1.52, se muestra cuando el usuariomiembro del proyecto selecciona una evaluación finalizada, o cuando contesta laúltima pregunta del cuestionario. Presenta el resultado del estudio de viabilidadmostrando los valores de los vectores justificación, adaptabilidad, plausibilidad,éxito y viabilidad y también el módulo de cada uno de ellos numérica ygráficamente. Para permitir trazabilidad presenta cada una de las preguntasrespondidas y las respuestas ingresadas. Provee interfaces para que el usuariopueda exportar o imprimir la información.

Figura A1.52. Pantalla evaluate.

7.6.7. Add Evaluator

Esta pantalla, mostrada en la Figura A1.53, le presenta al usuario administrador

del sistema una lista con los e-mail de todos los usuarios evaluadores del sistema.Provee interfaces que permiten agregar nuevos usuarios evaluadores, eliminar dela lista usuarios existentes e imprimir la información.

Figura A1.53. Pantalla add evaluator.





7.6.8. edit

Esta pantalla, mostrada en la Figura A1.54, le presenta al usuario evaluador unainterfaz que le permite modificar la plantilla de evaluación de proyectos. Muestrala información de cada preguntas del cuestionario, que puede ser modificada yenlaces que dirigen a la próxima pregunta según el valor de respuesta.

Figura A1.54. Pantalla edit.

7.6.9. About

Esta pantalla, mostrada la Figura A1.55, le presenta al usuario en manual deayuda, y la información sobre la versión en ejecución del sistema.

Figura A1.55. Pantalla About.

7.6.10. Data

Esta pantalla, mostrada en la Figura A1.56, le presenta al usuario administradoruna interfaz para confirmar si desea eliminar toda la información del sistema deinicializar la plantilla de evaluación de proyectos.





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 seleccionarlas opciones del sistema. Se encuentra ubicada en la zona superior de cada una delas pantallas presentadas anteriormente.

Figuras 57. Menú del Sistema.

Las acciones que pueden realizarse con el menú son: Proyectos: conduce a cualquier usuario que inició sesión en el sistema a la

pantalla choose project.

Cuestionario: solamente visible por los usuarios con el rol de evaluadores.Conduce al usuario a la pantalla edit.

Evaluadores : solamente visible por el administrador de sistema. Conduce a lapantalla add evaluator.

Inicializar: solamente visible por el administrador de sistema. Conduce a lapantalla clear.

Ayuda: conduce a cualquier usuario que inició sesión en el sistema a lapantalla about.

Salir: conduce a cualquier usuario que inició sesión en el sistema a la pantallalogout.

7.7. Diagrama de Despliegue

El despliegue de la aplicación es muy simple, como puede verse en la Figura

A1.58, ya que consiste en un servidor appengine (de google o local) conteniendotodo 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.





El cliente se comunica con el servidor a través de un navegador web, utilizando el

protocolo http.dd Despliegue

appengine

Server

choose_project

datadbmodel

ev aluatorform

help

view

view_project

menu

cliente

(webbrowser)

http

Figura A1.58. Diagrama de Despliegue.





8. Casos de Prueba

En esta sección se desarrollan los casos de prueba planificados y ejecutadossatisfactoriamente que surgen de los escenarios más importantes de cada caso deuso.

8.1. Validar Usuario

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-001 : Validar usuario.

8.1.1. Inicio de sesión exitoso

La Figura A1.59 nuestra el caso de prueba inicio de sesión exitoso.

Identificación CP-001 : Inicio de sesión exitosoCaso de Usoque lo origina

CU-001

Escenario El usuario intenta iniciar sesión en el sistema.

Datos de

Entrada

El usuario ingresa un e-mail y contraseña válidos (cuentas

activas en google)ResultadoEsperado

El usuario inicia sesión el sistema.

Estado Ejecutado correctamente.Figura A1.59. Caso de prueba inicio de sesión exitoso

8.1.2. Inicio de sesión fallido

La Figura A1.60 nuestra el caso de prueba inicio de sesión fallido.

Identificación CP-002: Inicio de sesión fallidoCaso de Usoque lo origina

CU-001

Escenario El usuario intenta iniciar sesión en el sistema.

Datos deEntrada

El usuario ingresa las siguientes combinaciones de e-mail ycontraseña:

E-mail válido y contraseña inválida. E-mail y contraseña inválidas. E-mail inválido y contraseña de algún usuario

válido. E-mail y contraseña nulos.





E-mail nulo y contraseña correcta.

E-mail válido y contraseña nula.

ResultadoEsperado

El sistema notifica error en el inicio de sesión.

Estado Ejecutado correctamente.Figura A1.60. Caso de prueba inicio de sesión fallido

8.2. Asignar evaluador

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios 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 nuevoevaluador.

Identificación CP-003 : Administrador agrega nuevo evaluador

Caso de Usoque lo origina

CU-002

Escenario El administrador accede a la pantalla para agregar un nuevousuario evaluador.

Datos deEntrada

El administrador ingresa un e-mail válido (cuenta activa engoogle)

ResultadoEsperado

El usuario evaluador queda registrado en el sistema.

Estado Ejecutado correctamente.Figura A1.61. Caso de prueba Administrador agrega nuevo e valuador

8.2.2. Administrador intenta agregar evaluador registrado

La Figura A1.62 nuestra el caso de prueba Administrador intenta agregarevaluador registrado.

Identificación CP-004 : Administrador intenta agregar evaluador registrado


CU-002

Escenario El administrador accede a la pantalla para agregar un

usuario evaluador, que ya fue registrado previamente en elsistema.

Datos de El administrador ingresa un e-mail válido, que ya fue





Entrada registrado previamente (cuenta activa en google)

ResultadoEsperado El sistema notifica que el e-mail ya ha sido registrado.

Estado Ejecutado correctamente.Figura A1.62. Caso de prueba Administrador inten ta 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 agregarevaluador con e-mail nulo.

Identificación CP-005 : Administrador intenta agregar evaluador con e-mailnulo


CU-002

Escenario El administrador accede a la pantalla para agregar un nuevousuario evaluador.

Datos deEntrada

El administrador envía el formulario sin ingresar un e-mail

Resultado

Esperado

El sistema notifica que el e-mail no es válido, debido a que es

nulo.Estado Ejecutado correctamente.

Figura A1.63. Caso de prueba Administrador intenta agregar evaluador con e-mail nulo

8.2.4. Usuario intenta agregar evaluador

La Figura A1.64 nuestra el caso de prueba Usuario intenta agregar evaluador.

Identificación CP-006 : Usuario intenta agregar evaluadorCaso de Uso

que lo origina

CU-002

Escenario Un usuario, que no cuenta con el rol de administrador,accede a la pantalla para agregar un nuevo usuarioevaluador.

Datos deEntrada

Ninguno

ResultadoEsperado

El sistema notifica al usuario que no cuenta con los permisossuficientes para realizar la acción.

Estado Ejecutado correctamente.Figura A1.64. Caso de prueba Usuario intenta agregar evaluador





8.3. Actualizar planilla de evaluación

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-003 : Actualizar planilla de evaluación.

8.3.1. Evaluador actualiza pregunta

La Figura A1.65 nuestra el caso de prueba Evaluador actualiza pregunta.

Identificación CP-007 : Evaluador actualiza pregunta


CU-003

Escenario Un usuario evaluador accede a la pantalla modificar laspreguntas del cuestionario de la plantilla de evaluación.

Datos deEntrada

El usuario evaluador modifica los siguientes datos de laspreguntas:

modifica el texto de la Descripción modifica el peso (valor entero entre 0 y 10) modifica la dimensión

ResultadoEsperado

El sistema actualiza los datos de la pregunta y notifica al

usuario.Estado Ejecutado correctamente.Figura A1.65. Caso de prueba Evaluador actualiza pregunta

8.3.2. Evaluador intenta actualizar pregunta con datos incorrectos

La Figura A1.66 nuestra el caso de prueba Evaluador intenta actualizar preguntacon datos incorrectos.

Identificación CP-008 : Evaluador intenta actualizar pregunta con datosincorrectos


CU-003

Escenario Un usuario evaluador accede a la pantalla modificar laspreguntas del cuestionario de la plantilla de evaluación.

Datos deEntrada

El usuario evaluador modifica los datos de las preguntas,con cada uno de los valores enunciados a continuación :

descripción nula peso incorrecto (mayor a 10 y/o alfanumérico)

ResultadoEsperado

El sistema y notifica al usuario que los datos ingresados sonincorrectos.





Estado Ejecutado correctamente.Figura A1.66. Caso de prueba Evaluador intenta actualizar pregunta con datos incorrectos

8.3.3. Usuario intenta actualizar pregunta

La Figura A1.67 nuestra el caso de prueba Usuario intenta actualizar pregunta.

Identificación CP-009 : Usuario intenta actualizar pregunta


CU-003

Escenario Un usuario, que no cuenta con el rol de evaluador, accede ala pantalla para modificar las preguntas del cuestionario dela plantilla de evaluación.

Datos deEntrada

Ninguno

ResultadoEsperado


Estado Ejecutado correctamente.Figura A1.67. Caso de prueba Usuario intenta actualizar pregunta

8.4. Evaluar viabilidad A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-004: Evaluar viabilidad.

8.4.1. Proyecto altamente viable

La Figura A1.68 nuestra el caso de prueba Proyecto altamente viable.

Identificación CP-010 : Proyecto altamente viable

Caso de Uso

que lo origina

CU-004

Escenario Un miembro del proyecto accede a la pantalla que permitecontinuar la ejecución de una evaluación creada por él.

Datos deEntrada

El miembro del proyecto contesta Si o Todo (Si) encada una de las preguntas.

ResultadoEsperado

El sistema muestra como resultado de viabilidad: Vector Justificación = (10;10;10;10) Resultado Justificación = 10

Vector éxito = (10;10;10;10) Resultado éxito = 10

Vector adaptabilidad = (10;10;10;10)





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.

Identificación CP-011 : Proyecto no viable rotundamenteCaso de Usoque lo origina

CU-004


Datos deEntrada

El miembro del proyecto contesta las preguntas con losvalores indicados a continuación:

Las partes interesadas están identificadas? Las

partes interesadas son aquellas personas o gruposde personas que afectan o pueden ser afectadas porel proyecto. Boxes de referencia de la metodologíaP3TQ: DB1, AB2, AB3 Mucho

Todas las partes interesadas cuentan con ladisponibilidad de tiempo para avocarse al proyecto?Boxes de referencia de la metodología P3TQ: DB1,AB2, AB3: Mucho

Existen partes interesadas con autoridad suficientedentro de la organización para liderar el proyectode explotación? Boxes de referencia de lametodología P3TQ: DB1, AB2, AB3 Poco

Existen partes interesadas con recursos económicossuficientes para encarar el proyecto? Boxes dereferencia de la metodología P3TQ: DB1, AB2, AB3 Poco

El proyecto de explotación tiene como propósitobuscar relaciones de interés? No

El proyecto de explotación tiene como propósito la





evaluación de una situación de negocio? (análisis de

problema u oportunidad)? Si Con respecto a la problemática del negocio del

proyecto original: Se han encontrado datos deutilidad para llevar a cabo la minería? El proyectooriginal es aquel que origina el proyecto deexplotación que se está evaluando. Boxes dereferencia de la metodología P P3TQ: AB6 Poco

Las partes interesadas han identificado o puedenidentificar aquellas características del negocioimportantes, que enmarcan sus expectativas delproyecto de explotación? Boxes de referencia de lametodología P3TQ: TB7No

La situación del negocio está enmarcada o puedeenmarcarse en un modelo a partir de los datosconocidos? Boxes de referencia de la metodologíaP3TQ: AB6 Poco

Los Objetivos y Metas del negocio están definidos o

pueden definirse? Boxes de referencia de lametodología P3TQ: AB6, TB5 Poco

Se requiere inicialmente un análisis estratégico paraplanificar escenarios corporativos? Si

La situación del negocio está enmarcada o puedeenmarcarse en un modelo a partir de los datosconocidos? Boxes de referencia de la metodologíaP3TQ: AB9 Poco

Existe un mapa del escenario estratégico,consensuado con las partes interesadas. .Boxes dereferencia de la metodología P3TQ: AB12 No

Están identificadas por las partes interesadas lasrelaciones entre las cinco temáticas clave delnegocio(producto, lugar, precio, tiempo ycantidad)? Boxes de referencia de la metodologíaP3TQ: AB12 No

Puede establecerse correspondencia entre el mapa ylas relaciones P3TQ? Boxes de referencia de lametodología P3TQ: AB12 No





Existen o pueden realizarse simulaciones que

permitan identificar ambigüedades, incertezas,discordancias? Boxes de referencia de lametodología P3TQ: AB12 No

Están caracterizadas o pueden caracterizarse lasrelaciones clave del sistema? Boxes de referencia dela metodología P3TQ: AB12 No

Esta determinado o puede determinarse cuales delos 26 recursos de gestión (Consultar la tabla 7.2 deMII de P3TQ) son adecuados a cada potencial parteinteresada? Boxes de referencia de la metodologíaP3TQ: AB12, MII Tabla 7.1 Poco

Existe o puede obtenerse un set de datos sinerrores? Boxes de referencia de la metodologíaP3TQ: DB9.1 No

El set de datos obtenidos esta referenciado al casode negocio a estudiar? Boxes de referencia de lametodología P3TQ: DB9.1 No

Existen variables con único valor, o valores vaciosen sus instancias? Boxes de referencia de lametodología P3TQ: DB9.2 Mucho

Las variables categóricas están documentadas?Boxes de referencia de la metodología P3TQ: DB9.2

Poco Los nombres de los atributos son acorde a los

conceptos del negocio? Boxes de referencia de la

metodología P3TQ: DB9.3 Poco Son reconocidas y es posible adecuar variables

anacrónicas? Boxes de referencia de la metodologíaP3TQ: DB9.4 No

Existen datos suficientes como para crear diezmodelos predictivos con once atributos cada uno(siempre distintos) y generar un set deentrenamiento y otro de testeo? Boxes de referencia


TQ: DB9.5, TB9.4No

Se dispone de un experto para analizar y asegurar

que el set de datos representa los escenarios más





importantes que pueden ocurrir en el negocio?

Boxes de referencia de la metodología P3

TQ: DB9.6 No

Es necesario realizar recodificación de variablespara mejor comprensión del modelo? Boxes dereferencia de la metodología P3TQ: DB9.7 Si

Los conjuntos de variables de entrada y salida estáncaracterizadas? Boxes de referencia de lametodología P3TQ: AB11.1 Si

Los datos están estructurados o puedenestructurarse para aplicarlos en la herramienta deminería elegida? Boxes de referencia de lametodología P3TQ: AB11.1 Poco

Están seleccionados los algoritmos de minería

adecuados al modelo? Boxes de referencia de lametodología P3TQ: AB11.3 No

Existe una herramienta de minería adecuada almodelo y está disponible? Boxes de referencia de la

metodología P3TQ: AB11.6 No De necesitarse comprar herramientas, existen

proveedores disponibles. .Boxes de referencia de lametodología P3TQ: AB11.5 Poco

Esta construido o puede construirse el MVCM(Missing Value Check Model)? Boxes de referenciade la metodología P3TQ: AB11.1 No

El objetivo de la explotación es entender una

situación? No El objetivo de la explotación es aplicar una

clasificación? No El objetivo de la explotación es buscar una

predicción? No

ResultadoEsperado

El sistema muestra como resultado de viabilidad: Vector Justificación = (1.20 ; 2.20 ; 3.40 ;2.80) Resultado justificación =2.80

Vector éxito = (0.22 ; 0.33 ; 0.42 ; 0.27) Resultado éxito = 0.27 Vector adaptabilidad = (0.42 ; 0.57 ; 0.69 ; 0.49)





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.

Identificación CP-012 : Proyecto no viableCaso de Usoque lo origina

CU-004


Datos deEntrada


Las partes interesadas están identificadas? Las

partes interesadas son aquellas personas o gruposde personas que afectan o pueden ser afectadas porel proyecto..Boxes de referencia de la metodologíaP3TQ: DB1, AB2, AB3 Regular

Todas las partes interesadas cuentan con ladisponibilidad de tiempo para avocarse al proyecto?Boxes de referencia de la metodología P3TQ: DB1,AB2, AB3 Mucho

Existen partes interesadas con autoridad suficientedentro de la organización para liderar el proyectode explotación? Boxes de referencia de lametodología P3TQ: DB1, AB2, AB3 Mucho

Existen partes interesadas con recursos económicossuficientes para encarar el proyecto? Boxes dereferencia de la metodología P3TQ: DB1, AB2, AB3 Regular

El proyecto de explotación tiene como propósitobuscar relaciones de interés? No

El proyecto de explotación tiene como propósito la





evaluación de una situación de negocio? (análisis de

problema u oportunidad)? Si Con respecto a la problemática del negocio del

proyecto original: Se han encontrado datos deutilidad para llevar a cabo la minería? El proyectooriginal es aquel que origina el proyecto deexplotación que se está evaluando..Boxes dereferencia de la metodología P3TQ: AB6 Regular

Las partes interesadas han identificado o puedenidentificar aquellas características del negocioimportantes, que enmarcan sus expectativas delproyecto de explotación? Boxes de referencia de lametodología P3TQ: TB7Si

La situación del negocio está enmarcada o puedeenmarcarse en un modelo a partir de los datosconocidos? Boxes de referencia de la metodologíaP3TQ: AB6 Regular

Los Objetivos y Metas del negocio están definidos o

pueden definirse? Boxes de referencia de lametodología P3TQ: AB6, TB5 Regular

Se requiere inicialmente un análisis estratégico paraplanificar escenarios corporativos? Si

La situación del negocio está enmarcada o puedeenmarcarse en un modelo a partir de los datosconocidos? Boxes de referencia de la metodologíaP3TQ: AB9 Regular

Existe un mapa del escenario estratégico,consensuado con las partes interesadas. .Boxes dereferencia de la metodología P3TQ: AB12 Si

Están identificadas por las partes interesadas lasrelaciones entre las cinco temáticas clave delnegocio(producto, lugar, precio, tiempo ycantidad)? Boxes de referencia de la metodologíaP3TQ: AB12 Si

Puede establecerse correspondencia entre el mapa ylas relaciones P3TQ? Boxes de referencia de lametodología P3TQ: AB12 Si





Existen o pueden realizarse simulaciones que

permitan identificar ambigüedades, incertezas,discordancias? Boxes de referencia de lametodología P3TQ: AB12 No

Están caracterizadas o pueden caracterizarse lasrelaciones clave del sistema? Boxes de referencia dela metodología P3TQ: AB12 Si

Esta determinado o puede determinarse cuales delos 26 recursos de gestión (Consultar la tabla 7.2 deMII de P3TQ) son adecuados a cada potencial parteinteresada? Boxes de referencia de la metodologíaP3TQ: AB12, MII Tabla 7.1 Regular

Existe o puede obtenerse un set de datos sinerrores? Boxes de referencia de la metodologíaP3TQ: DB9.1 Si

El set de datos obtenidos esta referenciado al casode negocio a estudiar? Boxes de referencia de lametodología P3TQ: DB9.1 Si

Existen variables con único valor, o valores vaciosen sus instancias? Boxes de referencia de lametodología P3TQ: DB9.2 Regular

Las variables categóricas están documentadas?Boxes de referencia de la metodología P3TQ: DB9.2

Regular Los nombres de los atributos son acorde a los

conceptos del negocio? Boxes de referencia de la

metodología P3TQ: DB9.3 Mucho Son reconocidas y es posible adecuar variables

anacrónicas? Boxes de referencia de la metodologíaP3TQ: DB9.4 Si

Existen datos suficientes como para crear diezmodelos predictivos con once atributos cada uno(siempre distintos) y generar un set deentrenamiento y otro de testeo? Boxes de referencia


TQ: DB9.5, TB9.4Si

Se dispone de un experto para analizar y asegurar

que el set de datos representa los escenarios más





importantes que pueden ocurrir en el negocio?

Boxes de referencia de la metodología P3

TQ: DB9.6 Si Es necesario realizar recodificación de variables

para mejor comprensión del modelo? Boxes dereferencia de la metodología P3TQ: DB9.7 No


Los datos están estructurados o puedenestructurarse para aplicarlos en la herramienta deminería elegida? Boxes de referencia de lametodología P3TQ: AB11.1 Regular


adecuados al modelo? Boxes de referencia de lametodología P3TQ: AB11.3 No


metodología P3TQ: AB11.6 Si De necesitarse comprar herramientas, existen

proveedores disponibles. .Boxes de referencia de lametodología P3TQ: AB11.5 Regular


El objetivo de la explotación es entender una

situación? No El objetivo de la explotación es aplicar una

clasificación? No El objetivo de la explotación es buscar una

predicción? No

ResultadoEsperado

El sistema muestra como resultado de viabilidad: Vector Justificación = (3.40 ; 4.40 ; 5.60 ;6.60) Resultado Justificación = 5

Vector éxito = (8.95 ; 9.24 ; 9.54 ; 9.76) Resultado éxito = 9.37 Vector adaptabilidad = (3.48 ; 3.60 ; 3.75 ; 3.88)





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.

Identificación CP-013 : Proyecto no viable por incumplimiento desituaciones esenciales


CU-004


Datos deEntrada


Las partes interesadas están identificadas? Laspartes interesadas son aquellas personas o gruposde personas que afectan o pueden ser afectadas porel proyecto..Boxes de referencia de la metodologíaP3TQ: DB1, AB2, AB3 Mucho

Todas las partes interesadas cuentan con ladisponibilidad de tiempo para avocarse al proyecto?Boxes de referencia de la metodología P3TQ: DB1,

AB2, AB3 Poco Existen partes interesadas con autoridad suficiente

dentro de la organización para liderar el proyectode explotación? Boxes de referencia de lametodología P3TQ: DB1, AB2, AB3 Mucho

Existen partes interesadas con recursos económicossuficientes para encarar el proyecto? Boxes dereferencia de la metodología P3TQ: DB1, AB2, AB3

Mucho El proyecto de explotación tiene como propósito

buscar relaciones de interés? Si





El proyecto original cuenta con el apoyo de la

organización? Boxes de referencia de la metodologíaP3TQ: DB1, AB2, AB3 Mucho El proyecto original cuenta con el apoyo de las

partes interesadas? Boxes de referencia de lametodología P3TQ: DB1, AB2, AB3 Todo (Si)

Existe comunicación con las partes interesadas delproyecto original? El proyecto original es aquel queorigina el proyecto de explotación que se estáevaluando..Boxes de referencia de la metodologíaP3TQ: DB1, AB2, AB3 Todo (Si)

Se cumplieron los objetivos del proyecto original?Mucho

Se requiere inicialmente un análisis estratégico paraplanificar escenarios corporativos? No

Existe o puede obtenerse un set de datos sinerrores? Boxes de referencia de la metodologíaP3TQ: DB9.1 Si

El set de datos obtenidos esta referenciado al casode negocio a estudiar? Boxes de referencia de lametodología P3TQ: DB9.1 Si

Existen variables con único valor, o valores vaciosen sus instancias? Boxes de referencia de lametodología P3TQ: DB9.2 Muy poco o nada

(No) Las variables categóricas están documentadas?

Boxes de referencia de la metodología P3TQ: DB9.2Mucho

Los nombres de los atributos son acorde a losconceptos del negocio? Boxes de referencia de lametodología P3TQ: DB9.3 Mucho

Son reconocidas y es posible adecuar variablesanacrónicas? Boxes de referencia de la metodologíaP3TQ: DB9.4 Si

Existen datos suficientes como para crear diezmodelos predictivos con once atributos cada uno(siempre distintos) y generar un set de





entrenamiento y otro de testeo? Boxes de referencia


TQ: DB9.5, TB9.4 Si Se dispone de un experto para analizar y asegurar

que el set de datos representa los escenarios másimportantes que pueden ocurrir en el negocio?Boxes de referencia de la metodología P3TQ: DB9.6 Si

Es necesario realizar recodificación de variablespara mejor comprensión del modelo? Boxes dereferencia de la metodología P3TQ: DB9.7 No


Los datos están estructurados o pueden

estructurarse para aplicarlos en la herramienta deminería elegida? Boxes de referencia de lametodología P3TQ: AB11.1 Mucho


adecuados al modelo? Boxes de referencia de lametodología P3TQ: AB11.3 Si


metodología P3TQ: AB11.6 Si De necesitarse comprar herramientas, existen

proveedores disponibles. .Boxes de referencia de lametodología P3TQ: AB11.5 Mucho


El objetivo de la explotación es entender unasituación? Si

Las variables utilizadas en el modelo estánrelacionadas con conceptos que son conocidos porlas partes interesadas? Boxes de referencia de lametodología P3TQ: AB11.1, DB11.5 Si

Los objetos del negocio que representan lasvariables pueden ser utilizados por las partes





interesadas, o gerentes para realizar mejoras en el

negocio. .Boxes de referencia de la metodologíaP3TQ: AB11.1, DB11,5 Mucho Los datos son suficientes para definir las relaciones

explicativas? Boxes de referencia de la metodologíaP3TQ: AB11.1 DB11.5 Si

ResultadoEsperado

El sistema muestra como resultado de viabilidad: Vector Justificación = (10 ; 10 ; 10 ; 10) Resultado Justificación = 10

Vector éxito = (7.80 ; 8.37 ; 8.99 ; 9.47 ) Resultado éxito = 8.66 Vector adaptabilidad = (0 ; 0; 0 ; 0) Resultado adaptabilidad = 0 Vector plausibilidad = (0 ; 0; 0 ; 0) Resultado plausibilidad = 0 Vector Viabilidad = (5.62 ; 5.93 ; 6.20 ; 6.44) Resultado viabilidad = 6.05

Estado Ejecutado correctamente.Figura A1.71. Caso de prueba Proyecto no viable por incumplimiento de situaciones esenciales

8.5. Crear evaluación

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-005 : Crear evaluación.

8.5.1. Miembro del proyecto crea evaluación

La Figura A1.72 nuestra el caso de prueba Miembro del proyecto crea evaluación.

Identificación CP-011 : Miembro del proyecto crea evaluaciónCaso de Usoque lo origina

CU-005

Escenario Un miembro del proyecto intenta crear una nueva

evaluación.

Datos deEntrada

El miembro del proyecto ingresa cualquiera de los siguientesnombres:

Texto Alfanumérico

Texto nuloResultadoEsperado

El sistema crea una nueva evaluación y redirige al usuario ala pantalla de ejecución de la evaluación.





Estado Ejecutado correctamente.Figura A1.72. Caso de prueba Miembro del proyecto crea evaluación

8.5.2. Líder del proyecto crea evaluación

La Figura A1.73 nuestra el caso de prueba Líder del proyecto crea evaluación.

Identificación CP-012 : Líder del proyecto crea evaluación


CU-005

Escenario El líder del proyecto intenta crear una nueva evaluación.

Datos deEntrada

El líder del proyecto ingresa cualquiera de los siguientesnombres:

Texto Alfanumérico

Texto nulo

ResultadoEsperado

El sistema crea una nueva evaluación y redirige al líder delproyecto a la pantalla de ejecución de la evaluación.

Estado Ejecutado correctamente.Figura A1.73. Caso de prueba Líder del proyecto crea evaluación

8.5.3. Usuario intenta crear evaluaciónLa Figura A1.74 nuestra el caso de prueba Usuario intenta crear evaluación.

Identificación CP-013 : Usuario intenta crear evaluaciónCaso de Usoque lo origina

CU-005

Escenario Un usuario que no posee roles en un proyecto intenta crearuna evaluación en él.

Datos de

Entrada

Ninguno

ResultadoEsperado


Estado Ejecutado correctamente.Figura A1.74. Caso de prueba Usuario intenta crear evaluación

8.6. Consultar proyecto

A continuación se presentan los casos de prueba correspondientes a los diferentes

escenarios del caso de uso CU-006 : Consultar proyecto.





8.6.1. Miembro consulta proyecto

La Figura A1.75 nuestra el caso de prueba Miembro consulta proyecto.Identificación CP-014 : Miembro consulta proyecto


CU-006

Escenario Un miembro del proyecto (colaborador o líder) selecciona unproyecto para consultarlo.

Datos deEntrada

El usuario selecciona de la lista de proyectos uno al cualpertenece.

ResultadoEsperado El sistema le presenta al usuario la pantalla de informacióndel proyecto, que incluye los resultados de todas lasevaluaciones realizadas.

Estado Ejecutado correctamente.Figura A1.75. Caso de prueba Miembro consulta proyecto

8.6.2. Usuario intenta consultar proyecto

La Figura A1.76nuestra el caso de prueba Usuario intenta consultar proyecto.

Identificación CP-015 : Usuario intenta consultar proyecto


CU-006

Escenario Un usuario que no es miembro de un proyecto (nicolaborador ni líder) selecciona ese proyecto paraconsultarlo.

Datos deEntrada

El usuario selecciona de la lista de proyectos uno al cual nopertenece.

Resultado

Esperado

El sistema le presenta al usuario la pantalla de información

del proyecto, sin mostrar los resultados de las evaluacionesrealizadas.

Estado Ejecutado correctamente.Figura A1.76. Caso de prueba Usuario intenta consultar proyecto

8.7. Consultar Evaluación

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-007 : Consultar evaluación.





8.7.1. Miembro consulta evaluación

La Figura A1.77 nuestra el caso de prueba Miembro consulta evaluación.Identificación CP-016 : Miembro consulta evaluación


CU-007

Escenario Un miembro del proyecto (colaborador o líder) seleccionauna evaluación de ese proyecto para consultarla.

Datos deEntrada

El usuario selecciona una evaluación de la lista deevaluaciones del proyecto.

ResultadoEsperado El sistema le presenta al usuario la pantalla de informaciónde la evaluación.

Estado Ejecutado correctamente.Figura A1.77. Caso de prueba Miembro consulta evaluación

8.7.2. Usuario intenta consultar evaluación

La Figura A1.78 nuestra el caso de prueba Usuario intenta consultar evaluación.

Identificación CP-017 : Usuario intenta consultar evaluación


CU-007

Escenario Un usuario que no es miembro de un proyecto (nicolaborador ni líder) intenta consultar una evaluación de eseproyecto.

Datos deEntrada

El usuario selecciona una evaluación de la lista deevaluaciones del proyecto al cual no pertenece.

ResultadoEsperado


Estado Ejecutado correctamente.Figura A1.78. Caso de prueba Usuario intenta co nsultar evaluación

8.8. Crear Proyecto

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-008 : Crear proyecto.

8.8.1. Usuario crea Proyecto

La Figura A1.79 nuestra el caso de prueba Usuario crea proyecto.Identificación CP-018 : Usuario crea proyecto





Caso de Uso

que lo origina

CU-008

Escenario Un Usuario que ha iniciado sesión del sistema intenta crearun nuevo proyecto.

Datos deEntrada

El usuario ingresa cualquiera de los siguientes nombres parael proyecto:

Texto Alfanumérico

Texto nulo

ResultadoEsperado

El sistema crea una nueva proyecto, designando como líderal usuario creador, y redirigiendo al usuario a la pantalla deinformación del proyecto.

Estado Ejecutado correctamente.Figura A1.79. Caso de prueba Usuario crea proyecto

8.9. Asignar colaborador

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-009 : Asignar colaborador.

8.9.1. Líder del proyecto agrega nuevo colaborador

La Figura A1.80 nuestra el caso de prueba Administrador agrega nuevoevaluador.

Identificación CP-019 : Líder del proyecto agrega nuevo colaborador


CU-009

Escenario El líder del proyecto accede a la pantalla para agregar unnuevo colaborador al proyecto.

Datos deEntrada

El líder del proyecto ingresa un e-mail válido

ResultadoEsperado

El usuario colaborador del proyecto queda registrado en elsistema.

Estado Ejecutado correctamente.Figura A1.80. Caso de prueba líder de proyecto agrega nuevo colaborador

8.9.2. Líder del proyecto intenta agregar colaborador registrado

La Figura A1.81 nuestra el caso de prueba Líder del proyecto intenta agregarcolaborador registrado.

Identificación CP-020 : Líder del proyecto intenta agregar colaborador





registrado

Caso de Usoque lo origina CU-009

Escenario El líder de proyecto accede a la pantalla para agregar uncolaborador, que ya ha sido registrado previamente en elsistema, en el mismo proyecto.

Datos deEntrada

El líder del proyecto ingresa un e-mail válido, que ya fueregistrado previamente en ese proyecto (cuenta activa engoogle)

ResultadoEsperado

El sistema notifica que el e-mail ya ha sido registradopara ese proyecto.

Estado Ejecutado correctamente.Figura A1.81. Caso de prueba Líder del proyecto intenta agregar colaborador registrado

8.9.3. Líder de proyecto intenta agregar colaborador con e-mail nulo

La Figura A1.82 nuestra el caso de prueba Líder de proyecto intenta agregarcolaborador con e-mail nulo.

Identificación CP-021 : Líder de proyecto intenta agregar colaborador con

e-mail nuloCaso de Usoque lo origina

CU-009

Escenario El líder de proyecto accede a la pantalla para agregar unnuevo colaborador al proyecto.

Datos deEntrada

El administrador envía el formulario sin ingresar un e-mail

Resultado

Esperado

El sistema notifica que el e-mail no es válido, debido a que es

nulo.Estado Ejecutado correctamente.

Figura A1.82. Caso de prueba Líder de proyecto intenta agregar colaborador con e-mail nu lo

8.9.4. Usuario intenta agregar colaborador al proyecto

La Figura A1.83 nuestra el caso de prueba Usuario intenta agregar colaborador alproyecto.

Identificación CP-022 : Usuario intenta agregar colaborador al proyecto

Caso de Usoque lo origina CU-009

Escenario Un usuario, que no cuenta con el rol de líder de proyecto





(puede o no ser colaborador del proyecto), accede a la

pantalla para agregar un nuevo usuario evaluador.Datos deEntrada

Ninguno

ResultadoEsperado


Estado Ejecutado correctamente.Figura A1.83. Caso de prueba Usuario intenta agregar colaborador al proyecto

8.10. Inicializar cuestionario

A continuación se presentan los casos de prueba correspondientes a los diferentesescenarios del caso de uso CU-010 : Inicializar cuestionario.

8.10.1. Administrador inicializa cuestionario

La Figura A1.84 nuestra el caso de prueba Administrador inicializa cuestionario.

Identificación CP-023 : Administrador inicializa cuestionario


CU-010

Escenario El Administrador accede a la pantalla para inicializar laplantilla de evaluación.

Datos deEntrada

El administrador contesta ”Si“

ResultadoEsperado

El sistema inicializa la plantilla de evaluación y eliminatodos los registros de la base de datos.

Estado Ejecutado correctamente.Figura A1.84. Caso de prueba Administrador inicializa cuestionario

8.10.2. Administrador intenta inicializar cuestionario

La Figura A1.85 nuestra el caso de prueba Administrador intenta inicializarcuestionario.

Identificación CP-023 : Administrador intenta inicializar cuestionario


CU-010

Escenario El Administrador accede a la pantalla para inicializar la

plantilla de evaluación.Datos deEntrada

El administrador contesta ”No“





Resultado

Esperado

El Sistema aborda la operación y notifica al administrador y

notifica al administrador.Estado Ejecutado correctamente.Figura A1.85. Caso de prueba Administrador intenta inicializar cuestionario

8.10.3. Usuario intenta inicializar cuestionario

La Figura A1.86 nuestra el caso de prueba Usuario intenta intenta inicializarcuestionario.

Identificación CP-024 : Usuario intenta inicializar cuestionario


CU-010

Escenario Un usuario, que no cuenta con el rol de administrador,

accede a la pantalla para inicializar la plantilla deevaluación.

Datos deEntrada

Ninguno

ResultadoEsperado


Estado Ejecutado correctamente.Figura A1.86. Caso de prueba Usuario intenta inicializar cuestionario





9. ConclusiónA lo largo de este documento se desarrollaron de manera detallada todas lasetapas involucradas en el desarrollo de la herramienta DAMVE, desde losrequerimientos hasta el modelo de diseño para ser implementado en lenguajePython sobre la arquitectura Appengine de Google.A continuación se resumen los aspectos más relevantes durante el desarrollo de laherramienta DAMVE

Si bien el documento presenta las etapas de manera consecutiva, suponiendoun modelo de desarrollo en cascada, el proceso de desarrollo y porconsiguiente los contenidos del documento se fueron generando de maneraiterativa, siguiendo un proceso conducido por el dominio del problema.

Durante la etapa de diseño se buscó siempre que la lógica del dominio delproblema fuese independiente del resto de la lógica de la aplicación (vista ycontrolador). Este aspecto es fundamental en el desarrollo de software ya quehace posible reutilizar completamente dominio para adaptarlo a otroescenario. Además, dado que Appengine está basado en el patrón MVC, quesepara el dominio de la interfaz con el usuario (vista y controlador), seconsiguió una concordancia entre la arquitectura del sistema y el proceso dedesarrollo.

Al estar la herramienta basada en un entorno web, se buscó optimizar lainteracción con el usuario. Para ello se implementaron interfaces enAJAX/JSON, que minimizan la transferencia http entre el servidor y el cliente,en los casos de uso que requieren mayor interacción usuario/sistema. Comoejemplo se pueden citar los casos de uso CU-003 Actualizar planilla de

evaluación y CU-004 Evaluar viabilidad. A lo largo del documento se buscó registrar la trazabilidad que existe entre las

distintas etapas de desarrollo. La Figura A1.19 relaciona los requierimientosfuncionales con los casos de uso, permitiendo registrar la trazabilidad entreRequerimientos y Casos de Uso. La Figura A1.33 relaciona los casos de uso,con los paquetes de clases que los implementan permitiendo registrar latrazabilidad entre Casos de Uso y Clases. Finalmente en la sección 8 sedesarrollan los casos de prueba como escenarios posibles para cada caso de

uso, permitiendo registrar la trazabilidad entre Casos de Uso y Casos dePrueba.





10. Posibles mejoras

Este documento podría mejorarse tomando en cuenta algunos de estos elementos: Incorporando fragmentos de código en lenguaje Python sobre aquella

funcionalidad del dominio que permita clarificar la implementación.

El Sistema DAMVE podría mejorarse tomando en cuenta algunos de estoselementos: Desarrollar una capa de servicios web. Esto permitiría, por ejemplo, utilizar la

aplicación desde una interfaz de usuario de ventanas mejorando la interacciónusuario/herramienta, o permitir que la herramienta se integre con otrossistemas proveyendo el servicio de evaluación de viabilidad. En el último casosería interesante integrar la herramienta DAMVE con un Sistema deadministración de proyectos.




Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 110

Anexo 2. Manual de usuario la

Herramienta DAMVE





1. IntroducciónEl Sistema DAMVE tiene por finalidad, ayudar a los miembros de un proyecto deexplotación de información que utilizan la metodología P3TQ a evaluar suviabilidad.

2. Requisitos

Para poder ejecutar el sistema DAMVE se requiere de un navegador web consoporte para AJAX. Los siguientes navegadores funcionan correctamente con elsistema 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 yejecución de comandos javascript.

3. Acceso al sistema

Cuando un usuario ingresa el enlace del sistema DAMVE en el navegador web sepresenta 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 identificarsepara poder ingresar al sistema. Los datos de acceso son:

e-mail: corresponde a la dirección de e-mail del usuario.

Contraseña: se debe ingresar la clave de acceso que debe ser conocida porel usuario.

Éstos datos son los pertenecientes a una cuenta de Google habilitada, si el sistema

se está ejecutando online.Si los datos ingresados son correctos el usuario accede a la pantalla de selecciónde proyectos, que se muestra en la Figura A2.2:





Figura A2.2. Pantalla de selección de proyectos

Por el contrario, si los datos ingresados son incorrectos, el sistema mostrará lasiguiente pantalla de error, que pedirá que se vuelvan a ingresar los datosnuevamente.

4. Presentación de la interfaz

Se presenta a continuación, en la Figura A2.3, la pantalla de selección de

proyectos del sistema y se describen las distintas opciones de la barra de menús.

Figura A2.3. Pantal la de presentación de la interfaz

Los números asociados con cada elemento de la pantalla se describen acontinuación:

1. Nombre de usuario: en el encabezado de la pantalla puede verse elnombre del usuario que está utilizando el sistema.

2. Proyectos: esta opción lleva a la pantalla de selección de proyectos que lepermite al usuario dar de alta un nuevo proyecto, seleccionar un existente

1

2 3 4 5 6 7





y, a partir de allí, realizar evaluaciones de viabilidad para el mismo. Esta

opción explica en detalle en el ítem 5 de este manual.3. Cuestionario : esta opción lleva a la pantalla de edición de la plantilla de

evaluación para los estudios de viabilidad. Solamente los usuarios decuentan con el rol de evaluadores pueden acceder, y les permite modificarlos parámetros del cuestionario con el cual se realizan todos los estudiosde viabilidad. Esta opción se explica en detalle en el ítem 10.3 de estemanual.

4. Evaluadores: esta opción lleva a la pantalla que le permite aladministrador del sistema agregar nuevos usuarios evaluadores para que

puedan modificar la plantilla de evaluación, explicada anteriormente. Estaopción se explica en detalle en el ítem 10.1 de este manual.

5. In icial izar: esta opción lleva a la pantalla que le permite al administradordel sistema inicializar la base de datos, eliminando, de existir, toda lainformación que exista y reiniciando la plantilla de evaluación. Estaopción se explica en detalle en el ítem 10.4 de este manual.

6. Ayuda: esta opción permite consultar este manual en línea o descargarlo elformato electrónico.

7. Salir: esta opción permite que el usuario cierra su sesión y salga delsistema.

5. Creación y Selección de Proyectos

En este ítem explicara cómo crear o seleccionar proyectos existentes en la sistema.

5.1. Creación de un proyecto nuevo

Cualquier usuario registrado en el sistema es capaz de crear un nuevo proyecto y,de esa manera, convertirse en el líder (o propietario) del mismo.La creación de nuevo proyecto se lleva a cabo haciendo clic en la opción“Proyectos”. Luego de hacer esto el usuario puede ver el siguiente formulario,presentado en la Figura A2.4:





Figura A2.4. Formulario de creación de un nuevo proyecto

Para crear un nuevo proyecto, en la sección "crear proyecto" el usuario debe: Escribir un nombre para el proyecto. Hacer clic en el botón “Crear”.

Una vez realizada esta tarea el sistema DAMVE crea el proyecto y le presenta alusuario la pantalla de gestión del proyecto.

5.2. Selección de un proyecto existente

Para seleccionar un proyecto existente en el sistema debe hacerse clic en la opción

“Proyectos”. Luego de hacer esto el usuario puede ver una lista con los proyectosexistentes en el sistema. La Figura A2.5 muestra esta lista:

Figura A2.5. Pantalla de selección de un proyecto

La información que se presenta es la siguiente: Fecha: fecha en la cual se creó el proyecto. Descripción: nombre del proyecto. Creador: e-mail del usuario creador del proyecto evaluaciones: cantidad de evaluaciones que se han realizado en dicho

proyecto.

Rol: corresponde al rol del usuario con respecto a dicho proyecto,representado por iconos. El icono significa que el usuario es el líder del

proyecto, el icono significa que el usuario de colaborador en el proyectoy el icono significa que el usuario es visitante en dicho proyecto.

Haciendo clic en la fecha, descripción o rol de un proyecto el usuariopuede acceder a la pantalla de gestión del proyecto.

6. Roles de los usuarios

Antes de continuar explicando los pasos a seguir para poder crear evaluacionesde viabilidad en la proyectos es necesario presentar los distintos roles que losusuarios pueden tener dentro del sistema DAMVE. La Tabla 1 presenta los roles





de los usuarios en el sistema ordenados por jerarquía, comenzando por el rol de

menor jerarquía (visitante) y llegando hasta el rol con mayor jerarquía(Administrador):

Nombre del rol Acciones dentro del sistema

Visitante Cualquier usuario que haya ingresado el sistema es

considerado visitante. Puede consultar los proyectos

existentes, los miembros pertenecientes a los

proyectos y la cantidad de evaluaciones de viabilidad

realizadas. No puede conocer los resultados de las

evaluaciones de viabilidad.

Colaborador del Proyecto Cualquier usuario que haya sido designado comocolaborador de un proyecto por el líder del mismo.

Como tal puede crear evaluaciones de viabilidad. Un

colaborador de un proyecto no puede continuar la

ejecución de evaluaciones creadas por otro colaborador

del mismo proyecto.

Líder del Proyecto Cualquier usuario visitante que dé de alta un proyecto

se convierte en el líder del mismo. Como tal puede

crear evaluaciones de viabilidad y designar a otros

usuarios como colaboradores.

Evaluador Cualquier usuario que haya sido designado como

evaluador por el administrador. Tiene la capacidad de

modificar la plantilla de evaluación del estudio de

viabilidad.

Administrador Es el usuario responsable de la administración del

sistema. Puede designar a los usuarios evaluadores.

Tabla 1. Roles de los usuarios

Un mismo usuario puede tener dentro del sistema uno o varios roles. Por ejemplo,un usuario puede ser líder del proyecto 1 por haberlo creado, colaborador del

proyecto 2 porque su líder lo ha designado, visitante en el resto de los proyectos yevaluador porque el administrador lo ha designado.

7. Gestión de un Proyecto

Una vez creado un nuevo proyecto o seleccionado de la pantalla de selección deproyecto, el usuario accede a la pantalla de gestión del proyecto. La Figura A2.6

presenta dicha pantalla:





Figura A2.6. Pantalla de gestión del proyecto

En esta pantalla puede observarse toda la información relativa al estudio deviabilidad del proyecto, organizada por secciones.

Sección general: se presenta el Nombre del proyecto, la fecha de creacióny el usuario propietario, o líder.

Colaboradores

: se presentan los e-mails de todos los usuarios designadospor el líder del proyecto para crear evaluaciones de viabilidad. Evaluaciones: se presenta una tabla que muestra la información resumida

de cada uno de los estudios de viabilidad realizados para este proyecto,ordenados en forma cronológica descendente, lo que permite visualizar laevolución de la viabilidad del proyecto. La tabla presenta la fecha decreación, la descripción, el usuario creador y el resultado de cada una delas evaluaciones. Si la evaluación ha sido completada se muestra en latabla el resultado final en forma gráfica y numérica. Sin evaluación no ha

sido completada todavía se muestran la tabla el texto “Incompleto”. En elcaso de que un usuario visitante acceda a un proyecto del cual no es

miembro (ni líder ni colaborador) el sistema no mostrara el resultado deninguna evaluación.

7.1. Agregar colaborador al proyecto

El líder del proyecto puede agregar un colaborador al mismo, completando elformulario “Agregar colaborador al proyecto” que se presenta en la pantalla de

gestión del proyecto. La Figura A2.7 muestra dicha pantalla:





Figura A2.7. Formulario agregar colaborador al proyecto

Para agregar un colaborador al proyecto, el líder debe: Escribir el e-mail del usuario colaborador. Hacer clic en el botón “Agregar colaborador”.

Una vez realizada esta tarea el sistema DAMVE agrega al usuario comocolaborador del proyecto.

7.2. Eliminar un colaborador

El líder de un proyecto puede eliminar a cualquier colaborador que haya

agregado previamente. Para esto debe hacer clic en el icono que se encuentra al

lado del e-mail de cada colaborador. El sistema le pedirá una confirmación y, si ellíder del proyecto contesta afirmativamente, el colaborador será eliminado de eseproyecto, convirtiéndose en visitante.

7.3. Crear una nueva evaluaciónEl líder del proyecto y los usuarios colaboradores pueden crear una nuevaevaluación de viabilidad para el proyecto, completando el formulario “crear

nueva evaluación” que se presenta en la pantalla de gestión del proyecto.

Figura A2.7. Formulario crear nueva evaluación

Para crear una nueva evaluación, el usuario miembro del proyecto debe: Escribir una descripción para la evaluación. Hacer clic en el botón “crear nueva evaluación”.

Una vez realizada esta tarea el sistema DAMVE crea una nueva evaluación para elproyecto y le muestra al usuario la pantalla de ejecución de la evaluación.

7.4. Imprimir la gestión del proyecto

Para imprimir la información de gestión del proyecto el usuario debe hacer clic enel botón “Imprimir” que se encuentra en el borde superior derecho de la pantalla.





El sistema preparará una versión adaptada para impresión de la pantalla que

facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo deimpresión del navegador web.

7.5. Exportar la gestión del proyecto

Para exportar la información de gestión del proyecto a un archivo separado porcomas (.csv) el usuario debe hacer clic en el botón “Exportar” que se encuentra enel borde superior derecho de la pantalla.El sistema generará un archivo .csv que el usuario podrá descargar y visualizar encualquier planilla de cálculo o editor de texto.

8. Ejecución de evaluaciones

Hasta el momento se ha presentado la forma de crear proyectos, agregarcolaboradores al mismo y crear evaluaciones. En este ítem se mostrará la forma de

ejecutar las evaluaciones a través de un cuestionario guiado.Una vez que un miembro del proyecto cree una nueva evaluación, el sistema

DAMVE presenta la pantalla de ejecución de la evaluación. La Figura A2.8presenta dicha pantalla:

Figura A2.8. Pantalla de ejecución de la evaluación

La ejecución de una evaluación de viabilidad es simple:1. El sistema le presenta al usuario una pregunta relacionada a un aspecto

particular de la metodología P3TQ.2.

El usuario debe responderla en relación a la información con la que cuentadel proyecto que está evaluando. Para esto puede utilizar el mouse paraelegir la opción que considere correcta y hacer clic en el botón siguiente.





Alternativamente, para hacer más dinámica la interacción, el usuario

puede seleccionar la opción correcta con las flechas del cursor y presionarla tecla ENTER.3. El sistema procesará la respuesta del usuario y le presentará la próxima

pregunta. Además, en la sección "preguntas respondidas" el sistemamuestra todas las preguntas que el usuario ha respondido.

4. A llegar a la última pregunta el sistema siendo capaz de calcular laviabilidad del proyecto en base a las respuestas del usuario, le presenta lapantalla de resultado de la evaluación.

8.1. Abandonar y Retomar evaluacionesNo es necesario que el usuario complete una evaluación en una única sesión,pudiendo abandonar la ejecución de una evaluación en cualquier momento.Para retomar una evaluación incompleta, el usuario miembro del proyecto debeseleccionar el proyecto en la pantalla de selección de proyectos y, en la pantalla degestión del proyecto buscar en la tabla de evaluaciones, que se presenta en laFigura A2.9, la evaluación que ha dejado incompleta.

Figura A2.9. Retomar una evaluación incompleta

Una vez hecho esto debe hacer clic en el icono , que le permitirá volver a lapantalla de ejecución de la evaluación, retomando el cuestionario desde dónde lo

abandonó.

9. Resultado de las evaluacionesUna vez que se ha completado el cuestionario de evaluación el sistema le presentaal usuario de resultado obtenido. La Figura A2.10 muestra un ejemplo deresultado de evaluación:





Figura A2.10. Pantalla de resultado de una evaluación

El sistema muestra los siguientes resultados: Dimensión justificación: presenta el vector justificación y, en forma

gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. Dimensión Adaptabi l idad: presenta el vector adaptabilidad y, en forma

gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. Dimensión Plausibi l idad: presenta el vector plausibilidad y, en forma

gráfica, el módulo del vector que sintetiza el resultado de esa dimensión. Dimensión Éxito: presenta el vector éxito y, en forma gráfica, el módulo

del vector que sintetiza el resultado de esa dimensión. Viabi l idad: presenta el vector viabilidad, que es un promedio de las cuatro

dimensiones anteriores y, en forma gráfica, el módulo de este vector quesintetiza el resultado final de la evaluación.

Si el resultado del cálculo del módulo de un vector es menor a seis, seconsidera insuficiente y se presenta el resultado gráfico en color rojo. Porel contrario si el módulo es mayor a seis se lo considera aceptable y se

presenta el resultado gráfico en color verde. Al igual que la pantalla de ejecución de una evaluación del sistema

presenta en la sección "preguntas respondidas" todas las preguntas que elusuario ha respondido, permitiendo contar con trazabilidad de laevaluación.

9.1. Imprimir los resultados

Para imprimir los resultados de la evaluación de un proyecto el usuario debe

hacer clic en el botón “Imprimir” es encuentra en el borde superior derecho de lapantalla.





El sistema preparará una versión adaptada para impresión del resultado que

facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo deimpresión del navegador web.

9.2. Exportar los resultados

Para exportar los resultados de la evaluación a un archivo separado por comas(.csv) el usuario debe hacer clic en el botón “Exportar” que se encuentra en elborde superior derecho de la pantalla.El sistema generará un archivo .csv que el usuario podrá descargar y visualizar encualquier planilla de cálculo o editor de texto.

9.3. Consultar resultados de evaluaciones realizadas

Para poder consultar los resultados de una evaluación realizada cualquiermiembro del proyecto (líder o colaborador) debe hacer clic en el resultado final dela evaluación que se encuentra en la sección "Evaluaciones " de la pantalla degestión del proyecto. La Figura A2.11 muestra un ejemplo de dicha pantalla:

Figura A2.11. Consultar resultados de evaluaciones realizadas

10. Opciones Avanzadas

Las opciones presentadas a continuación pueden ser llevadas a cabo por usuarioscon mayor jerarquía en el sistema, debido a los roles que poseen.

10.1. Designar evaluadores

El administrador del sistema puede designar usuarios evaluadores, que soncapaces de modificar la plantilla de evaluación.Para realizar esta tarea el administrador debe hacer clic en la opción

“Evaluadores” del menú y completar el formulario “Agregar evaluador” que se





presenta en la pantalla evaluadores. La Figura A2.12 muestra un ejemplo de dicho

formulario:

Figura A2.12. Formulario para agregar un evaluador

Para agregar un nuevo evaluador, el usuario administrador debe: Escribir el e-mail del nuevo valor. Hacer clic en el botón “Agregar evaluador”.

Una vez realizada esta tarea el sistema DAMVE agrega al usuario comoevaluador.

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 dele-mail de cada evaluador, en la pantalla evaluadores. El sistema le pedirá unaconfirmación y, si el administrador contesta afirmativamente, el evaluador será

eliminado del sistema.

10.3. Editar la plantilla de evaluación

Los usuarios con el rol de evaluadores pueden editar la plantilla de evaluación.Para realizar esta tarea deben hacer clic en la opción "Cuestionario" del menú. Acontinuación se presenta en la Figura A2.13 la pantalla de edición de la plantillade evaluación.

Figura A2.13. Formulario para editar la plantilla de evaluación





El sistema presenta un formulario por cada pregunta del cuestionario de

evaluación. Los parámetros que pueden modificarse en cada formulario es: Descripción: contiene el texto de la pregunta a contestar. Peso: el peso de la pregunta, en un rango de -10 a 10. Dimensión : correspondiente a que dimensión de viabilidad corresponde la

pregunta (justificación, éxito, adaptabilidad, plausibilidad) Próximas preguntas: muestra para cada valor posible de respuesta cual es

la próxima pregunta del cuestionario. Esta opción permite que el usuarioevaluador pueda navegar el cuestionario. Para esto el usuario evaluadordebe hacer clic en el número de la próxima pregunta y el sistema lo

llevara hasta el formulario de dicha pregunta.El usar evaluador puede, entonces, modificar cualesquiera de los parámetros delformulario y, haciendo clic en el botón “Actualizar” el sistema guardará loscambios en la plantilla de evaluación.

10.3.1. Preservación de los resultados

Cuando una pregunta de la plantilla de evaluación es modificada, todas lasevaluaciones de viabilidad de cualquier proyecto utilizarán los nuevos

parámetros de dicha pregunta. Las evaluaciones que ya hayan respondidopreviamente la pregunta conservarán el valor anterior en el resultado. De estamanera se preservan los resultados de viabilidad anteriores a la modificación dela plantilla de evaluación.

10.3.2. Preservación de la secuencia

El sistema DAMVE, no permite que se altere la secuencia de las preguntas, debidoa que siguen, de manera estricta la metodología P3TQ. Sin embargo, resulta muy

útil para un líder de proyecto de explotación de información con experiencia laposibilidad de modificar los parámetros de la pregunta para adecuar laevaluación de debilidad a su entorno de trabajo.

10.4. Inicializar la Base de Datos

El administrador del sistema puede reiniciar la base de datos, haciendo clic en laopción “Inicializar” del menú.Luego de hacer esto el sistema mostrará una pantalla similar a la Figura A2.14,que solicita la confirmación del administrador, dado que esta acción destruyetodos los datos que existan en la base de datos y lleva al Sistema DAMVE a suestado original.




Figura A2.14. Confirmación de Inicialización de la Base de Datos

Si el usuario hace clic en el botón “Aceptar” toda la información existente eseliminada y el sistema queda reinicializado.

Documents

Mendez Rodriguez Trabajoprofesional