Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la ...

HERRAMIENTA DE ESTUDIO DE VIABILIDAD PARA PROYECTOS QUE

UTILIZAN LA METODOLOGÍA P3TQ

TRABAJO PROFESIONAL EN INGENIERÍA EN INFORMÁTICA

Laboratorio de Sistemas Inteligentes Facultad de Ingeniería

Universidad de Buenos Aires

Alumnos: Pablo Damián MENDEZ Alejandro Daniel RODRIGUEZ

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

Mayo 2009

FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ

Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ

Índice

Memoria del Trabajo Profesional.................................................................... 1 1. 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 interesantes

en 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, Series

de tiempo, etc.) como informáticas (Algoritmos genéticos, Inteligencia Artificial,

Sistemas Expertos, Redes neuronales, etc.)

Entre muchos otros ejemplos, la Explotación de Información ha contribuido

significativamente en:

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

cliente.

� Detectar patrones de fuga y fraudes.

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

(por ejemplo Internet)

Existen en el mercado actual tres importantes metodologías para llevar a cabo

proyectos de explotación de la información, a saber:

� SEMMA

� CRISP-DM




� P3TQ

Sin importar la metodología usada, no existe hasta el día de hoy, ningún método

de cálculo de viabilidad para proyectos de explotación de la información. En este

trabajo, se estudia la metodología P3TQ en particular para especificar un método

plausible para el cálculo de viabilidad de proyectos de las características

mencionadas.

2.1. La metodología SEMMA

La primer metodología fue propuesta por el SAS Institute, su nombre hace

referencia a las cinco fases que se consideran al utilizarla (Sample, Explore,

Modif., Model, Assess esto es Muestrear, Explorar, modificar, Modelar y Valorar

respectivamente) [SAS Institute 1998].

La figura 2.1.1 muestra la dinámica del método SEMMA.

Figura 2.1.1. Metodología SEMMA




2.2. La metodología CRISP-DM

La metodología CRISP-DM analiza el proceso de explotación de la información en

seis fases diferentes (Figura 2.2.1). Aunque en la ilustración se muestran las

interacciones más comunes entre las fases se pueden establecer relaciones entre

cualquiera de ellas [CRISP-DM 2000].

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




2.3. La metodología P3TQ

La metodología de D. Pyle se divide en dos etapas, la primera denominada

Modelado de Negocio o MII, y la segunda llamada Minería de datos o MIII

[Pyle, D. 2003].

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 en

función del propósito del proyecto de explotación de la información que se quiere

evaluar. De esta manera Pyle considera:

1. Explorar los datos en búsqueda de relaciones útiles.

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

información encausar a la organización hacia una decisión correcta.

3. Simplemente ver qué puede lograr la explotación de la información.

Metodología de Modelado (MII)

Metodología de Minería (MIII)




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

particular

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

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

resolverla.

Figura 2.3.2. Metodología de P3TQ, Puntos de partida de un proyecto y objetos a considerar

En la Figura 2.3.2 (parte central) se enumeran los parámetros concernientes a la

organización y la situación del proyecto que la metodología de P3TQ considera,

sin embargo estos son tratados de distinta manera según el punto de partida, para

obtener finalmente los datos requeridos para el proyecto de explotación y los

requerimientos reales de las partes interesadas.




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 los datos

Selección de la herramienta

Minería

Refinamiento

Despliegue

Cada parte de la metodología (tanto en MII como en MIII)

está desagregada en pasos, estos pasos son denominados

boxes, 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 entre

ellos dependen de las situaciones que se van dando a

medida que se avanza en el proyecto.

Figura 2.3.3. Pasos distinguidos en la metodología P3TQ

Los boxes explican detalladamente los conceptos y/o acciones que se realizan. El

gráfico mostrado anteriormente permite identificar cuáles son los Boxes que

corresponden a cada etapa de la metodología. Por ejemplo puede verse en la

figura 2.3.1 que los Boxes 9.x corresponden a la etapa de preparación de los datos

en la metodología de minería MIII.

2.4. Comparación de las metodologías P3TQ, SEMMA y

Crisp-DM

Luego de las investigaciones iniciales, hemos concluido que SEMMA se centra en

los aspectos técnicos de los proyectos de explotación de datos. Además está

acotada ya que ha sido diseñada para ser implementada con los productos SAS.

Crisp-DM es más completa y abierta que SEMMA, pero no llega al detalle de la

metodología P3TQ, ya que nombra etapas del proceso de la explotación de la

información, pero no se analizan los pasos, resultados y situaciones que se pueden

dar dentro de cada etapa.




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

mencionadas (Ver cuadro 2.4.1), y, por lo tanto en la que se centrará el presente

trabajo. Dicha metodología analiza muchas más variables y más profundamente

que las demás. Para citar un simple y claro ejemplo (considerando que nos

encontramos sólo en la introducción de la presentación de un proyecto y no en su

desarrollo) la metodología considera quiénes son los interesados en el proyecto en

la organización, considerando hasta la causa de su interés (Pyle, D. Business

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

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 viabilidad

Todo proyecto en el ámbito de cualquier rama de la ingeniería debe satisfacer la

ecuación fundamental de costo y beneficio.

Antes de comenzar con un proyecto, por lo tanto, tres puntos deben tenerse en

cuenta:

• El esfuerzo necesario para el desarrollo (Costo)

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

• También a veces, por razones inherentes a la naturaleza de un proyecto

surge una tercera cuestión que es si es realizable en función de las variables

que lo definen.

Estas tres cuestiones no sólo pueden indicar si se debe comenzar o no una

inversión económica para obtener un resultado, sino que además, puede variar a

medida que se va avanzando en la empresa y nuevos problemas van surgiendo.

El estudio de viabilidad, considerando los puntos que D. Pyle menciona en la

bibliografía, aproxima a un valor que nos da la respuesta sobre si es conveniente

que un proyecto se ejecute, o siga ejecutándose. Estas características corresponden

en mayor medida al segundo y tercer punto.

En comparación a cualquier otro tipo de proyecto de naturaleza informática, toma

mayor importancia realizar estudios de viabilidad cuando se trata de actividades

de explotación de la información. La razón de esta afirmación, radica en que es

común notar en el cliente un interés incierto, o más bien, mucho interés, pero sin

conocer exactamente qué espera de un proyecto de explotación de la información.

3.1. El método

� La metodología mencionada en [García-Martínez, R. y Britos, P. (2004).

Sistemas Expertos. Nueva Librería] clasifica tres tipos distintos de

características que definen la viabilidad de un problema, a saber:

• Booleanos

• Numéricos en un intervalo finito

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

“mucho”, “todo”).




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

viable o no. Además cada característica estará ponderada por un “peso”, que hará

que incida en mayor o menor medida en la dimensión de un problema.

En casos de valores lingüísticos son convertidos en valores difusos

correspondiente en el intervalo [0,10] como se muestra en la tabla 3.1.1.

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

Para homogeneizar el problema, los valores booleanos también se tratan como

lingüísticos considerando los valores de la tabla 3.1.2.

Tabla 3.1.2 Conversión entre valores booleanos y valores difusos

Las características se agruparán según su naturaleza y llamaremos a cada grupo

“Dimensión”, existiendo cuatro dimensiones a saber: Plausibilidad, Éxito,

Adecuación y Justificación.

La dimensión “Plausibilidad” agrupará todas aquellas características que indican

si el desarrollo del proyecto es posible, por ejemplo si existen expertos y están

disponibles, si existen los casos de prueba adecuados, etc. El “éxito” es

determinado por características del problema que generalmente se dan a

posteriori del desarrollo, de todas maneras debemos identificar y evaluar estas

características a priori, para ejemplificar podemos mencionar el interés o

desinterés de un departamento clave de la organización, que no sea el sponsor

pero si el usuario final (el proyecto sería desarrollado pero nunca utilizado o los

usuarios serían reacios, esto sería un fracaso).

La dimensión de “Justificación” contendrá cada característica que determine si

vale la pena realizar el proyecto. Supongamos el caso que se dispone de

suficientes expertos en la materia y no representan costo significativo para la

empresa, en este caso seguramente no será justificado el desarrollo.

Nada 0 0 1,2 2,2

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

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

Mucho 5,6 6,6 7,8 8,8

Todo 7,8 8,8 10 10

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 siguiente

manera. Dado L el vector de valor lingüístico de dimensión 4 (de acuerdo a las

tablas 3.1.1 y 3.1.2), Li y Pi el valor difuso y el peso de la característica i

respectivamente; la viabilidad de una dimensión j determinada del problema será

determinada por la ecuación 3.1.1.

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

Esta fórmula representa la viabilidad para una dimensión j dada. Luego de

calcular para las 4 dimensiones (Adecuación, éxito, justificación y plausibilidad),

se calcula la viabilidad total de un problema según la fórmula 3.1.2.

Ecuación 3.1.2 Viabilidad total

Pj es el peso de cada dimensión, siguiendo la bibliografía propuesta se define que

será:

� Plausibilidad y adecuación 8

� Justificación 3

� Éxito 5

3.2. Viabilidad en P3TQ

Todo proyecto de Explotación de la información, tiene como propósito el uso de

herramientas sobre datos existentes para obtener relaciones interesantes a la hora

de tomar decisiones o crear soluciones.

Una característica de los trabajos de explotación de datos actuales, es que el punto

de partida, o más bien el motivo de su realización, no sea un problema en

particular a solucionar. Muchos interesados en aplicar explotación de la




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

con la información existente, pero no la solución de un problema en sí.

Esta característica, incrementa la necesidad del estudio de viabilidad; ya que al

comenzar con un rumbo incierto, es probable terminar en una solución no

deseada luego de haber invertido tiempo de personal calificado y recursos

económicos.

Naturalmente no es apropiado este tipo de perspectiva para ningún tipo de

proyectos, a pesar que la realidad en la práctica indique que muchos comienzan

de esta manera porque el sponsor lo requiere.

Como se describió en la sección 2.3, la metodología propuesta por D. Pyle,

establece dos partes de un proyecto de minería de datos, el “Modelado de Negocio”

y la “Metodología de Minería”. Por esta razón analizaremos la viabilidad tomando

características de estas dos partes por separado.

3.2.1. Estudio de viabilidad en el modelado de negocio

Tomando como punto de partida que nada puede ofrecer un proyecto de

explotación de datos hasta que el problema a resolver sea identificado, esto debe

lograrse de alguna manera, aunque el cliente no lo haya especificado.

Pyle reconoce, por lo tanto, los siguientes puntos de partida de un proyecto según

su objetivo:

Según el punto de partida inicial, D. Pyle establece cuáles son los siguientes pasos

a seguir.

Por ejemplo el caso más general, con escasa información sobre el negocio, sólo

llega el conjunto de datos sobre el cual se debe aplicar minería para descubrir

relaciones que puedan llegar a ser de interés. En este punto, Pyle, establece

� Explorar los datos y descubrir relaciones interesantes que

ofrezcan valor agregado al negocio.

� Un problema u oportunidad de negocio en particular a ser

explorado.

� Descubrir en qué partes de la organización puede ser

interesante aplicar métodos de explotación de la

información.

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




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

categorías:

1. Los que necesitan la realización del proyecto.

2. Los que poseen los recursos económicos.

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

4. Los que se benefician con el resultado.

Luego se procedería con una entrevista a los interesados, en donde se debe

entender cuál es la parte relevante de negocio que, justamente, les interesa y

discutir con ellos para identificar cuál es el proyecto original que alimenta la

necesidad de un proyecto de minería.

Siguiendo este ejemplo, es nuestro estudio de viabilidad, analiza si:

� Las partes interesadas están identificadas.

� Las partes interesadas tienen disponibilidad de tiempo para avocarse al

proyecto.

� Existen partes interesadas con recursos suficientes.

� Las características importantes para las partes interesadas están identificadas.

La parte clave de estos pasos es descubrir y caracterizar cuál, cómo y cuánto de

los componentes P3TQ (Product, Price, Place, Time, Quantity) son afectados por

el proyecto, qué hay que cambiar para ver la oportunidad o resolver el problema

de trasfondo.

Las cinco variables de negocio que dan nombre a esta metodología, interactúan

mutuamente (figura 3.2.1.1). Por ejemplo, el éxito del lanzamiento de un producto

depende, obviamente del cliente, pero las características de ellos, dependen del

tiempo y el lugar.

Figura 3.2.1.1 Variables P3TQ

Estas relaciones deben ser reveladas en los datos con las herramientas usadas para

la 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 negocio

identificado por D. Pyle, notemos cuáles son las situaciones que se tienen luego de

analizar esta pequeña fracción de la metodología:

� El problema de negocio de trasfondo descubierto no está totalmente dirigido.

� El proyecto original perdió el apoyo de uno o algunos de los interesados.

� EL proyecto original falló en entregar los resultados esperados.

� Los datos fueron recolectados para dirigir una situación específica, pero el

objetivo de la minería sería descubrir si hay algún valor corporativo que se

pueda obtener de ellos.

Según la situación, el nivel de riesgo es distinto. Además, Pyle especifica una

acción para resolver el problema en cada una de estos escenarios. Es objetivo de

este trabajo también, analizar estas acciones, descubrir acciones implícitas, y

determinar el riesgo de realizarlas.

El software de Análisis de viabilidad, ubica al usuario en la situación de la

metodología de explotación de datos propuesta por D. Pyle realizando ciertas

preguntas.

Adaptando la metodología de D. Pyle al método de cálculo de viabilidad (sección

3.1), se identifica primero a qué dimensión pertenece cada una y se le asigna un

peso, determinando en conjunto la viabilidad del proyecto.

En la tabla 3.2.1.1, se muestran los ítems que establecen los puntos de riesgo para

el modelado de negocio. El software de cálculo de viabilidad es extendible en este

sentido, los puntos mostrados en la tabla son los correspondientes a la versión 1.0

del software. La primer columna indica la dimensión de viabilidad a la cuál

apunta la pregunta (P: Plausibilidad; A: Adecuación; E: Éxito; J: justificación). La

segunda columna indica el “Pyle Box” (ver sección 2.3) fuente de la pregunta, que

es la “caja” que enumera de alguna manera el factor de riesgo que se identificó

para generar la pregunta en cuestión.

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

El desarrollo de modelos aptos para la minería requiere análisis, interpretación y

cambios sobre los datos de manera cíclica. Las acciones a tomar dependen

enteramente del problema de negocio y de lo que el experto en minería descubre

en ellos.




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

comenzar la minería, sino también a lo largo del desarrollo del proyecto.

La metodología P3TQ, comienza el proceso de minería con la preparación de los

datos.

Se debe tener en cuenta que el esfuerzo del experto es enfocado en mayor medida

a esta tarea. Es de esperar que la relación sea entre el 60 y 90% del esfuerzo total

avocado a la minería.

Esto, apunta a que el test de viabilidad para la minería de datos esté enfocado en

gran parte hacia el estado de los conjuntos de variables y, por ejemplo, si no

existen errores, si dichas variables y sus valores son congruentes con el modelo de

negocio o si son suficientes, además si poseen muchos valores indefinidos, etc.

Las cuestiones mencionadas se reflejan en las preguntas que el sistema de cálculo

de viabilidad muestra al usuario (tabla 3.2.2.1).

Pyle establece los pasos a seguir para la preparación de los datos en los boxes 9.x.

El siguiente punto más relevante, luego de la preparación de los datos, es la

minería en sí, refiriéndonos a los algoritmos utilizados, los conjuntos de variables

de entrada y salida, etc. Estos casos son apuntados por los boxes 11.x.

El test de viabilidad en la minería propuesto en este trabajo tiene una bifurcación

según los tres tipos de proyectos de explotación que Pyle identifica:

� Minería para entender.

� Minería para clasificar.

� Minería para predecir.

Minería para entender:

Cuando la cuestión que motiva el proyecto es entender el por qué de una

situación del negocio en particular, el set de datos limita la respuesta que el

encargado de la explotación de la información puede otorgar.

Si es posible, la transformación de variables es normalmente de gran ayuda para

la comprensión de los resultados y puede hacer más rico un modelo. Tomemos

como ejemplo de transformación, establecimientos de una empresa dedicada a la

logística georeferenciados, o sea, puntos en particular con latitud y longitud

establecida. Es probable que dada la situación a entender, no sea de relevancia

conocer estos parámetros, pero sí la distancia a un punto en particular de cada

establecimiento. Naturalmente el minero debería encargarse de transformar las

variables de latitud y longitud a una variable con el valor de la distancia.

Con este sencillo ejemplo, se intenta demostrar algunos de los puntos que

determinan el riesgo previamente a comenzar a realizar la tarea de minería. Ya




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

de la información debe analizar previamente: ¿Pueden transformarse los datos de

manera que sean importantes para entender la situación, y útiles para explicar el

resultado?, ¿pueden las herramientas elegidas, transformar los datos de manera

conveniente?.

Además de los puntos relativos a las variables en sí, la explicación de la situación

(el resultado final del proyecto), contendrá tanto implícita o explícitamente las

relaciones entre variables que conforman la parte del modelo concerniente a la

situación particular analizada. ¿Estas relaciones son coherentes?, ¿existen

variables, donde comúnmente se espera un par relacionado, sin estar

relacionadas?, estas cuestiones también hacen que el riesgo del proyecto aumente

o disminuya, son consideradas por este trabajo.

Otras cuestiones que influyen directamente en el riesgo de la minería son mucho

más triviales, por ejemplo, si están elegidas las herramientas y algoritmos para la

minería, si se cuenta con un proveedor de dichas herramientas, la capacidad de

respuesta en caso necesitar modificaciones.

Minería para clasificar:

Según D. Pyle, la clasificación es un caso especial de lo que comúnmente se

denomina predicción, debido a que se intenta predecir a qué clase una instancia

de dato pertenece en función a ciertos atributos. Se discute el término

“predicción” en el siguiente punto (“Minería para predecir”).

Por ejemplo, un modelo para clasificar muy común y utilizado muy a menudo

pedagógicamente es aquel que en función de ciertos atributos de una persona,

ésta accedería a un crédito otorgado por un banco o no. Estos atributos pueden ser

sexo, edad, nivel de estudio, estado civil, región donde vive, etc. El modelo de

clasificación producirá algún tipo de puntuación en función de esos atributos que

determine si la persona accede o no al crédito.

Sin embargo, ocurre en ciertos casos que la puntuación producida por la

herramienta de minería no es fácil de interpretar. Supongamos que para el caso en

cuestión el modelo establezca un resultado booleano de tipo 0= No accede al

crédito, 1 = Accede al crédito. Es probable que luego de la minería, la herramienta

utilizada calcule un valor entre 1 y 0. Estos casos requieren que el responsable de

la explotación haga una interpretación y que tenga los medios necesarios para

ello.

Otra cuestión, es que se necesitan varios conjuntos de datos para aplicar la

herramienta. Esto se debe a que si se usa un solo conjunto, el modelo interpretará




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

otorga un conjunto donde un 30% acceden al crédito y un 70% no, el modelo

interpretará que un 30% de los casos acceden al crédito universalmente.

Las cuestiones de los párrafos anteriores, influyen directamente en la viabilidad

de un proyecto de minería para clasificar ya que, deben ser elegidas

cuidadosamente las herramientas, saber si se podrán interpretar los datos, o

estarán disponibles aquellas personas que puedan interpretarlos. Obviamente, con

respecto a las proporciones de las clases, la viabilidad estará influida por la

cantidad de conjuntos de datos que se puedan generar. P3TQ especifica

minuciosamente los pasos a seguir para la minería de clasificación, en cada uno de

ellos se pueden reconocer factores de riesgo que hemos incluido en el desarrollo

de este trabajo y se reflejan en la herramienta final.

Modelo para predecir:

Quizás el más difícil de los tres objetivos que puede tener un proyecto de minería

es la predicción.

Un modelo para predecir debe ser capaz de arrojar información que no está

presente en el set de datos que toma como entrada. Estos resultados salen de la

elaboración de los datos junto con el conocimiento del negocio, por lo tanto, el

modelo debe ser lo suficientemente rico, y se debe poseer expertos en el caso de

negocio que puedan interpretar causas y efectos, con la dinámica de relaciones

que interconectan los objetos representados en los datos.

Los datos disponibles no contienen un patrón que describa cómo se comportará el

sistema de las circunstancias de interés ya que la combinación única de estas

circunstancias no ha sucedido aún. Y en esta incertidumbre de comportamiento

subyace el trabajo que se le encomendó al encargado de la explotación de la

información.

Ya que no existen herramientas de minería para este propósito, el éxito dependerá

en gran parte en la habilidad del experto para seleccionar herramientas existentes

y su habilidad para relacionar los resultados que vaya encontrando entre las

distintas situaciones del negocio, para lo cual necesitará la ayuda y disponibilidad

de expertos interesados en el proyecto.

3.2.3. El cuestionario de evaluación

Cada paso de la metodología posee acciones u objetos plausibles de riesgo. Un

experto puede generar riesgo por su ausencia, un conjunto de datos puede

generar riesgo por poseer demasiados valores nulos, etc.




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

apoyan los proyectos de explotación de la información que consideramos,

analizaremos a continuación cómo se presenta la metodología propuesta al

usuario final.

El interesado en determinar el riesgo de un proyecto deberá ir contestando un

cuestionario donde se presentan los posibles escenarios de riesgo para cada paso

de la metodología P3TQ.

Como P3TQ no es secuencial, no serán tampoco las preguntas presentadas.

Según lo que el usuario responda se le mostrarán un conjunto de preguntas u

otro.

Las preguntas de la tabla 3.2.3.1 están divididas en aquellas que corresponden a la

etapa de modelado (Id de la 1 a la 27), las que corresponden a la etapa de minería

(27 a 49) y las que manejan la secuencia de la metodología P3TQ (50 a 57). Notar

que todas excepto las del tercer grupo tienen un peso asignado y su dimensión

correspondiente en la tabla (P: plausibilidad, A: adaptabilidad, J: justificación y E:

éxito). El peso es la ponderación que tendrán en su dimensión en el cálculo de

viabilidad.

Las preguntas 50 a 57 tienen peso cero, ya que no evalúan el proyecto, sino que

identifican una situación particular y en función de sus respuestas se mostrará

una secuencia de preguntas o no. Id

pregunta Descripción 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

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

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

8 P

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

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

6 E

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

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

6 P

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

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

3TQ:

DB1, AB2, AB3 10 E

6 El 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

51 El 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 P3TQ: 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


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

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

6 J

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

metodología P3TQ: AB6, TB5

8 J

52 El 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

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

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

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

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

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

10 P

53 Hay otro propósito especifico? 0 M

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

metodología P3TQ: AB9

10 E



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



2 A

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

la metodología P3TQ: AB12

6 A

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

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

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


8 A

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

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

26 Está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

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

metodología P3TQ: DB9.1

8 P

30 Existen 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

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

metodología P3TQ: DB9.3

4 A

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

3TQ:

DB9.4 4 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

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

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

10 E

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

de la metodología P3TQ: DB9.7

-4 A

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

P3TQ: AB11.1

6 A




Id


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

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

6 A

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

metodología P3TQ: AB11.3

8 A

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


8 A

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


8 P

42 Esta 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

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

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

8 E

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

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

8 E

45 Los 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

46 Esta 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

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

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

8 E

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

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

P3TQ: TB11.7

5 E

49 Es 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 cada

paso en función de los objetivos del proyecto y el estado de cada atributo que lo

define.

Esto nos ha permitido, reconocer en cada paso aquellas cuestiones que hace

riesgoso o fácilmente viable a un proyecto de explotación de la información.

Al mismo tiempo reconocemos los distintos tipos dificultades que pueden

acarrear un proyecto de explotación de la información. Estas dificultades pueden

ser de distinta naturaleza. Se pueden mencionar dificultades de origen técnico,

como la disponibilidad de datos suficientes, la existencia de herramientas

adecuadas para el tipo de proyecto que se quiere llevar a cabo, etc. Pero también

hay dificultades de otra naturaleza, que no son tan triviales e influyen con gran

impacto en el éxito de un proyecto; identificar los interesados, sus expectativas,

detectar si conocen con precisión las variables del negocio y la relación entre ellas,

su impacto en los resultados.

Todas estas cuestiones deben ser convenientemente analizadas antes de comenzar

a utilizar recursos en explotación de información; para conocer la situación de

partida del proyecto y qué se pretende como resultado, la importancia de las

personas en la organización que quieren ese resultado, cómo se va a presentar

dicha información, etc.

Como agregado, no existe hasta el momento un metodología para calcular la

viabilidad de proyectos de este tipo, creamos en este trabajo una metodología con

dicho propósito basándonos en el cálculo de viabilidad propuesto por [Liebowitz

1986; Laufman et al, 1990; Adelman, 1989; 1992; De Antonio y Samper, 1990;

Beckam, 1991; López et al 1991].

Además se desarrollamos una herramienta de arquitectura web que permite

estudiar la viabilidad de proyectos de explotación de información desarrollados

bajo la metodología P3TQ a lo largo de todo su ciclo.

Dicha herramienta está desarrollada con Goolgle App Engine, un nuevo concepto

de programación web basado en el lenguaje python, y funcionando enteramente

(código y persistencia) en los servidores de Google.

Se adjunta el manual de usuario y documentación de desarrollo de la herramienta

junto a este documento.




5. Futuras mejoras

Si bien la herramienta desarrollada es muy completa, incluyendo seguimiento de

proyectos, generación de distintas evaluaciones para cada trabajo y manejo de

usuarios, además de la funcionalidad básica; el método propuesto es extensible,

pueden reconocerse nuevos puntos de riesgo siguiendo minuciosamente los pasos

que D. Pyle describe en la metodología P3TQ y agregarse a la metodología.

El agregado de nuevos puntos de riesgo no requiere de recodificación de la

herramienta, pero sí un agregado cuidadoso en su base de datos, ya que la

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

6. Bibliografía

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

Publishers.

� García-Martínez, R. ; Britos, P. (2004). Sistemas Expertos. Nueva Librería.

� Chapman, P. ; Clinton, J. (2000). CRISP-DM 1.0: Step by Step Data mining Guide.

The CRISP-DM consortium; 2000

� Martelli, A. (2008). Python, Guía de referencia. Anaya Multimedia.

� Martelli, A. (2006). Python in a Nutshell. O'Reilly.

� Pérez López, C.; Santin González, D. (2006). Data Mining, Soluciones con

Enterprise Miner. Alfaomega Grupo Editor.

� Colomes Fornos, X. (2009); Css Dhtml y Ajax Guía Práctica. Anaya

Multimedia.

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

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

Aires.

� Google (2008). Guía de Introducción de Google AppEngine. Disponible en:

http://code.google.com/intl/es-ES/appengine/docs/python/gettingstarted/



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 software

DAMVE, que permite ingresar las características de un proyecto que utiliza la

metodología P3TQ, con el objetivo de analizar y evaluar su viabilidad.

El documento presenta información detallada de cada una de las etapas en el

desarrollo de la herramienta, utilizando siempre que sea posible, el estándar UML

de modelado de software:

� Requerimientos funcionales, requerimientos no funcionales y restricciones

� Modelo de análisis (casos de uso)

� Arquitectura

� Modelo de diseño

� Casos de Prueba

El modelo de negocio que debe implementar la herramienta se encuentra

documentado en la Memoria Del Trabajo Profesional, donde se describe la

técnica de estudio de viabilidad aplicada a la metodología P3TQ.




2. Funcionalidad del Sistema

El sistema debe proveer la siguiente funcionalidad:

2.1. Evaluación de proyectos

� Creación de proyectos que utilizarán o utilizan la metodología P3TQ.

� Creación de evaluaciones asociadas a un proyecto, que permitan evaluar su

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

su ejecución).

� Todas las evaluaciones estarán basadas en una plantilla común de estudio de

viabilidad.

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

sesiones. En el primer caso debe presentarse el resultado de la evaluación. En

el segundo caso la evaluación debe presentarse como "en ejecución".

� Las evaluaciones de un proyecto deben presentarse de manera que se pueda

analizar la evolución del proyecto a través de la comparación de dichas

evaluaciones.

2.2. Gestión de usuarios

Deben existir al menos los siguientes roles en el sistema:

� Líderes de proyecto: son los responsables de la administración del proyecto

pudiendo crear evaluaciones y/o participar en todas las evaluaciones “en

ejecución” de ese proyecto.

� Colaboradores de proyecto: son usuarios asignados por el líder del proyecto

y su función es realizar evaluaciones del proyecto. Un colaborador puede,

entonces, crear una evaluación y completarla hasta obtener el resultado de

viabilidad. Un colaborador no puede continuar una evaluación “en ejecución”

creada por otro colaborador del mismo proyecto.

� Evaluador: Es un usuario con mucha experiencia que tiene conocimiento

suficiente en proyectos que utilizan la metodología P3TQ y puede actualizar la

plantilla de evaluación de estudio de viabilidad de proyectos.

� Administrador: Es responsable de la administración de la infraestructura y de

la base de datos que consume sistema, como así también de asignar a los

usuarios evaluadores.




3. Cambios en la versión

A continuación se presentan las modificaciones realizadas en las distintas

versiones del documento, para facilitar la trazabilidad de los cambios.

3.1. Versión 4

� Actualización del objetivo del documento.

3.2. Versión 3

� Actualización del objetivo del documento.

� Se incorporan los casos de prueba, conclusiones y mejoras.

3.3. Versión 2

� Se corrigen las referencias en los gráficos.

� Se incorpora la documentación de paquetes, clases, secuencia, pantallas y

despliegue.

3.4. Versión 1

� Versión inicial

4. Especificación de Requerimientos

4.1. Formato

La Figura A1.1 contiene el formato con el cual se registran cada uno de los

requerimientos. A partir de la sección 4.2 se desarrollán todos los requerimientos

utilizando dicho formato.

Los campos a completar en dicho registro son los siguientes:

� Código: comienza con el identificador de tipo: RF si se trata de un requisito

funcional o con RNF si se trata de un requisito no funcional. A continuación se

enumeran correlativamente según el tipo (funcional o no funcional). Ej) RF-001

(requisito funcional 1)

� Relevancia: Se clasifica en Alta, Media o Baja según la regla de negocio /

requerimiento no funcional que describa.




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

de requerimiento no funcional (ej: Reusabilidad, Portabilidad, Confiabilidad,

etc.)

� Nombre: identificador textual (breve) del requerimiento.

� Descripción: descripción textual del requerimiento.

� Control de cambios: debe ingresarse por cada cambio la fecha, persona que

lo solicita y descripción del cambio. Todos los cambios son registrados de

manera cronológica ascendente (el primer cambio al comienzo y el último

cambio al final).

Código Relevancia Clasificación Nombre

Descripción

Control de Cambios

Fecha Solicitado

por

Descripción del cambio

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

4.2. Requerimientos funcionales

Los requerimientos funcionales definen las funciones que el sistema será capaz de

realizar y describen las transformaciones que el sistema realiza sobre las entradas

para producir salidas.

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




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 y

convertirse en su líder.

La información que debe ingresarse y guardarse cuando se crea un proyecto es:

� Descripción del proyecto

� Fecha de creación

� Líder del proyecto (usuario que lo crea)

Deben respetarse las siguientes reglas:

� Cualquier usuario registrado en el sistema se convierte en el líder de un

proyecto que crea.

Control de Cambios

Fecha Solicitado

por


Figura A1.2. Requerimiento Funcional Crear y Actualizar Proyectos




4.2.2. Creación de Evaluaciones



RF-002 Alta Funcional CREACIÓN DE EVALUACIONES

Descripción

El sistema debe permitirle al líder del proyecto o a un usuario asignado como

colaborador de del mismo crear una nueva evaluación a partir de la plantilla

estándar.

La información que debe ingresarse y almacenarse cuando se crea una evaluación

es:

� Proyecto al cual pertenece

� Descripción de la evaluación


� Usuario que la crea (colaborador o líder del proyecto)

Una vez que la evaluación ha sido creada el sistema debe, automáticamente,

presentar la interfaz para que el usuario pueda comenzar a completar el estudio

de debilidad.

Una evaluación puede ser suspendida, quedando en el estado de "en ejecución".

Control de Cambios

Fecha Solicitado

por


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 UNA

EVALUACIÓN EN EJECUCIÓN

Descripción

El sistema debe permitirle al usuario creador de una evaluación que se encuentra

en el estado de "en ejecución " continuar con la misma, presentándole la interfaz

correspondiente.

Control de Cambios

Fecha Solicitado

por


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 DEL

PROYECTO

Descripción

El sistema debe presentar una interfaz que le permita a los usuarios que iniciaron

sesión navegar un proyecto cualquiera.

� Si el usuario pertenece a dicho proyecto (siendo su líder o colaborador)

podrá ver los datos generales del proyecto (descripción, fecha de

creación, usuario creador, sus colaboradores) y la información

actualizada y resumida de todas las evaluaciones realizadas, incluyendo

el resultado final de cada evaluación completada, ordenado de manera

cronológica descendente, de manera de poder analizar la evolución del

proyecto en el tiempo. Si existen evaluaciones “en ejecución” el sistema

debe comunicarlo y proveer una opción para poder retomar dicha

evaluación.

� Si el usuario no pertenece al proyecto podrá ver solamente los datos

generales del proyecto especificados anteriormente y la información de

las evaluaciones, pero no su resultado final.

Control de Cambios

Fecha Solicitado por


Figura A1.5. Requerimiento Funcional Mostrar resultados del proyecto

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



RF-005 Media Funcional ACTUALIZACIÓN DE LA PLANTILLA

DE EVALUACIÓN

Descripción

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

avisar evaluaciones de proyectos por los usuarios del sistema.

Además debe proporcionar una interfaz para que el usuario con rol de Evaluador,




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


� Cuando se actualiza la plantilla estándar las evaluaciones posteriores a

dicha actualización se realizarán con los cambios.

� Las evaluaciones que se han completado antes de la actualización no

reflejarán los cambios realizados.

� Las evaluaciones que se encuentran "en ejecución" no reflejarán los

cambios en aquellas preguntas ya contestadas; sin embargo sí lo harán en

las preguntas aún no contestadas.

Control de Cambios

Fecha Solicitado por Descripción del cambio

05/03/2009 Alejandro

Rodríguez

� El administrador debe poder

inicializar el cuestionario con valores

por defecto al desplegarse el sistema

por primera vez.

� El administrador debe poder

restablecer el cuestionario por

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




4.2.6. Asignación de Colaboradores al Proyecto



RF-006 Alta Funcional ASIGNACIÓN DE COLABORADORES

AL PROYECTO

Descripción

El sistema debe permitirle al líder de un proyecto designar colaboradores para

que puedan realizar evaluaciones en dicho proyecto. La información que debe

ingresarse para poder asignar un colaborador es su nombre de usuario,

coincidente con su dirección de correo electrónico.

Una vez que esta información ha sido provista, los usuarios designados pueden

colaborar en un proyecto creando evaluaciones. Deben respetarse las siguientes

reglas:

� Un usuario puede ser colaborador de distintos proyectos.

� Un usuario no puede ser colaborador y líder de proyecto al mismo

tiempo. El rol de líder de proyecto incluye la funcionalidad de

colaborador.

Control de Cambios

Fecha Solicitado

por


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 aquellos

usuarios con el rol de evaluadores.

La información que debe ingresarse para poder designar a un usuario como

evaluador es su nombre de usuario, coincidente con su dirección de correo

electrónico.

Una vez que esta información ha sido provista, los usuarios designados pueden

actualizar la plantilla estándar de evaluación de proyecto.


� Todos usuarios evaluadores pueden realizan cambios sobre la única

plantilla estándar.

Control de Cambios

Fecha Solicitado

por


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




4.3. Requerimientos no funcionales

Los requerimientos no funcionales tienen que ver con características que de una

u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en

tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,

disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estándares,

etc.

Se presentan a continuación los requerimientos no funcionales del sistema.

4.3.1. Proporcionar tiempos de respuesta aceptables

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


RNF-

001

Alta Rendimiento PROPORCIONAR TIEMPOS DE

RESPUESTA ACEPTABLES

Descripción

El sistema debe poseer la capacidad de prestar el servicio con los siguientes

niveles aceptables de desempeño, teniendo cuenta la concurrencia de usuarios

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

evaluación a cada usuario: 5 seg.

� Cantidad máxima de usuarios concurrentes: 20 usuarios

Control de Cambios


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 formato

establecido.


RNF-

002

Alta Rendimiento PREVEER CONTINGENCIAS POR

CAIDA DEL SISTEMA

Descripción

El sistema deberá prever contingencias que pueden afectar la prestación estable y

permanente del servicio.

La siguiente es la lista de las contingencias que se deben tener en cuenta y se

pueden considerar críticas:

� Caída del sistema por volumen de datos excedido en la base.

� Sobrecarga del sistema por volumen de transferencia de datos a los

usuarios.

� Caída del sistema por sobrecarga de recursos (procesos, memoria).

Estas consideraciones implicarán que la infraestructura técnica sobre la que se

implantará el sistema garantice una alta disponibilidad del mismo.

Control de Cambios


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


establecido.


RNF-

003

Media Capacidad CONSIDERAR EL CRECIMIENTO

ESPERADO EN EL VOLUMEN DE

DATOS

Descripción

El sistema deberá garantizar el soporte en el crecimiento del volumen de la

información almacenada que se gestionará en la base de datos.

Deben realizarse estimaciones, mediciones y comparaciones para proyectar un

estimado de dicho crecimiento, y se presentarse las características de tecnología

requeridas para afrontar el crecimiento proyectado en el volumen.

Control de Cambios


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




4.3.4. Parametrizar Las Variables Del Sistema


establecido.


RNF-

004

Media Portabilidad PARAMETRIZAR LAS VARIABLES DEL

SISTEMA

Descripción

El sistema debe permitir que sus variables y eventos de conFigura A1.ción sean

parametrizables e independientes del código fuente.

La modificación de los parámetros configurables será planteada para que el

sistema tome sus cambios una vez reiniciado el servidor de aplicaciones y no en

tiempo de ejecución de tal manera que se disminuya el riesgo de perdida de

funcionalidad por configuraciones en el vuelo.

Se deberá emplear la tecnología estándar propuesta por Appengine de Google.

Las variables que se configurarán, o se presentarán en el archivo de configuración,

determinarán fuentes de datos y ubicación de recursos.

Control de Cambios


Figura A1.12. Requerimiento no Funcional Parametrizar Las Variables Del Sistema




4.3.5. Diseñar interfaces con el usuario amigables


establecido.


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 mismo

incluyendo pantallas, menús y opciones, tamaño de las pantallas, color, tipo de

letra y configuración de los campos de entrada.

El diseño debe realizarse guiado por las características generales, en cuanto a

colores institucionales y disposición de contenidos, encontradas en el sitio web de

la organización.

Las interfaces deben realizarse en idioma castellano; sin perjuicio de lo cual debe

evitar traducirse la terminología técnica específica que no posee una traducción

precisa al castellano.

Control de Cambios


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

4.3.6. Desarrollar manual de usuario


establecido.


RNF-

006

Alta Amigabilidad DESARROLLAR MANUAL DE

USUARIO

Descripción

Debe desarrollarse el Manual de Usuario del Sistema que especifique la totalidad

de la funcionalidad que éste provee.

Los contenidos del Manual deben estar ofrecidos 100% en línea, en formato

HTML.

Control de Cambios


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




4.3.7. Codificar con estándares


establecido.


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


establecido.


RNF-

008

Alta Seguridad PERMITIR NIVELES DE SEGURIDAD

Descripción

El sistema deberá permitir que toda su información junto con los procesos

desarrollados por el mismo tenga controles de acceso acordes con el nivel de

privacidad requerido.

Los niveles de seguridad estarán determinados por la distribución jerárquica de

los usuarios, a saber:

� Usuarios Administradores: Acceso total.

� Usuarios registrados : Podrán tener acceso al información, que

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

Control de Cambios





Figura A1.16. Requerimiento no Funcional permitir niveles 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 se

presentan a continuación. Los requisitos de hardware del servidor pueden variar

según los requerimientos de rendimiento:

� Procesador 1.0 GHz

� 512 MB de RAM

Los requerimientos mínimos de software y hardware en el equipo cliente son:

� Navegador web compatible con Javascript (Recomendado IE7 o

posterior/Firefox 2.0 o posterior)

� Conexión a Internet, si la aplicación se ejecuta en Appspot de Google o

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

Control de Cambios


Figura A1.17. Restricción Arquitectura del Sistema




5. Modelo de análisis

5.1. Diagrama de Casos de Uso

La Figura A1.18 presenta el diagrama de Casos de Uso del sistema, basado en los

requerimientos funcionales desarrollados previamente: ud Casos de Uso

Administrador

Ev aluador

Lider de Proyecto

Colaborador de Proyecto

Crear Proyecto

Ev aluar Viabilidad

Crear Ev aluación

Validar usuario

Actualizar plantilla de evaluación

Asignar evaluador

Asignar Colaborador

Consultar Proyecto

Visitante

Consultar Evaluación

Inicializar ev aluació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

Funcionales

La Figura A1.19 muestra la matriz de trazabilidad que permite relacionar los

casos de uso del sistema con los requerimientos funcionales, permitiendo conocer

que requerimientos funcionales resuelve cada caso de uso.

Caso de Uso Requerimiento

Funcional

Id Nombre Id

CU-001 Validar usuario --

CU-002 Asignar evaluador RF–007

CU-003 Actualizar planilla de evaluación RF–005

CU-004 Evaluar viabilidad RF–003

CU-005 Crear evaluación RF–002

CU-006 Consultar proyecto RF–004

CU-007 Consultar evaluación RF–004

CU-008 Crear proyecto RF–001

CU-009 Asignar colaborador RF–006

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




5.3. Realización de los Casos de Uso

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

sistema.

5.3.1. Validar Usuario

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

ID CU-001

Nombre VALIDAR USUARIO

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

16/11/2008

Actores -

Descripción El sistema verifica que el usuario posea el rol correcto para

realizar una tarea.

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

Precondiciones

Postcondiciones El operador se encuentra validado en el sistema.

Flujo principal CU-001.0

1. El sistema presenta una pantalla que invita al

usuario a ingresar su nombre y contraseña para

autenticarse.

2. El usuario ingresa su nombre y contraseña y

presiona el botón “ingresar”.

3. El sistema verifica los roles que posee el usuario en

el sistema (visitante, líder de proyecto, colaborador

o evaluador).

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

Flujos

alternativos

CU-001.1

1. Si el usuario ingresa su nombre y contraseña de

manera incorrecta el sistema lo notifica y le solicita

ingresar los datos nuevamente, volviendo a CU-

001.0

Excepciones

Extensiones -

Incluye -

Heredado por -

Prioridad Alta




Reglas de

Negocio -

Requerimientos

especiales

Hipótesis

Notas Figura A1.20. Caso de uso validar Usuario

5.3.2. Asignar evaluador


ID CU-002

Nombre ASIGNAR EVALUADOR


16/11/2008

Actores � Administrador

Descripción El administrador del sistema designa a un usuario con el rol

de evaluador para que pueda modificar la plantilla estándar

de evaluación.

Trigger El administrador accede a la opción agregar evaluador

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

Postcondiciones � Un nuevo usuario cuenta con el rol de evaluador.


1. El sistema verifica que el usuario sea

administrador. De no cumplirse se ejecuta el flujo

alternativo CU-002.1.

2. El sistema presenta un formulario que solicita el 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

Flujos

alternativos

CU-002.1

El sistema notifica al usuario que no cuenta con los

permisos suficientes para llevar a cabo la tarea.

Excepciones -

Extensiones -

Incluye � CU-001. Validar Usuario




Heredado de -

Prioridad � Alta

Reglas de

Negocio RF-007

Requerimientos

especiales -

Hipótesis -

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

5.3.3. Actualizar planilla de evaluación


ID CU-003

Nombre ACTUALIZAR PLANILLA DE EVALUACIÓN

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

modificació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 futuras

evaluaciones de viabilidad de todos los proyectos.

Trigger El evaluador accede a la opción actualizar planilla

Precondiciones � El usuario debe contar con el rol de evaluador

Postcondiciones � La planilla de evaluación estándar queda

actualizada


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 la

información de todas las preguntas de la plantilla

estándar con la posibilidad de modificar la

descripción, el peso y la dimensión.

3. El evaluador actualiza todos los parámetros de

todas las preguntas que consideren necesario y

enviar formulario.

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

al evaluador




Flujos

alternativos

CU-003.1

� el sistema notifica al usuario que no cuenta con los


Excepciones -

Extensiones -


Heredado de -

Prioridad � Alta

Reglas de

Negocio RF-005

Requerimientos

especiales -

Hipótesis -

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

5.3.4. Evaluar viabilidad


ID CU-004

Nombre EVALUAR VIABILIDAD



Actores � Líder de proyecto

� colaborador

Descripción El sistema le permite al usuario creador de una evaluación

que se encuentra en el estado de "en ejecución" continuar

con la misma, presentándole la interfaz correspondiente.

Trigger El líder de proyecto o colaborador accede a la opción

continuar evaluación.

Precondiciones � El usuario debe contar con el rol de colaborador en

el proyecto en el cual desea continuar la

evaluación.

Postcondiciones � La evaluación queda actualizada con los pasos del

cuestionario cargados


1. El sistema verifica que el usuario sea colaborador




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

cumplirse se ejecuta el flujo alternativo CU-004.1.

2. Se repite el siguiente ciclo hasta que el colaborador

completa la última pregunta del cuestionario o

abandona el cuestionario dejándolo incompleto.

a. El sistema presenta todas las preguntas y

respuestas contestadas hasta el momento.

b. El sistema presenta un formulario que

muestra la próxima pregunta del

cuestionario.

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.

Flujos

alternativos

CU-004.1

� El sistema notifica al usuario que no cuenta con los


Excepciones -

Extensiones -

Incluye CU-001. Validar Usuario

CU-007. Consultar evaluación

Heredado por -

Prioridad Alta

Reglas de Negocio

RF-003

Notas - Figura A1.23. Caso de uso evaluar viabilidad

5.3.5. Crear evaluación


ID CU-005

Nombre CREAR EVALUACIÓN



Actores � Colaborador

Descripció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 en

el proyecto en el cual desea crear la evaluación.

Postcondiciones � La evaluación queda creada.


1. El sistema verifica que el usuario sea colaborador

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

cumplirse se ejecuta el flujo alternativo CU-005.1.

2. El sistema presenta un formulario para que el

colaborador ingrese la descripción de la

evaluación.

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

formulario.

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

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

viabilidad.

Flujos

alternativos

CU-005.1

� El sistema notifica al usuario que no cuenta con los


Excepciones -

Extensiones -


CU-004. Evaluar viabilidad

Heredado por -

Prioridad Alta

Reglas de

Negocio RF-002

Requerimientos especiales

-

Hipótesis -

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

5.3.6. Consultar proyecto


ID CU-006

Nombre CONSULTAR PROYECTO







� Colaborador

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

información existente.

Trigger Un usuario del proyecto ingresa a la opción consultar

proyecto.

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

Postcondiciones Ninguna


1. El sistema verifica que el usuario sea líder o

colaborador del proyecto. De no cumplirse se

ejecuta el flujo alternativo CU-006.1.

2. El sistema presenta la siguiente información del

proyecto al usuario, dando la opción de que la

información pueda ser impresa en papel.


� Descripción

� Líder

� Colaboradores

Lista de evaluaciones realizadas ordenadas en forma

cronológica descendente (incluye fecha de creación,

colaborador de la creo, descripción, estado: sí está finalizada

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

Flujos

alternativos

CU-006.1



Excepciones -

Extensiones -

Incluye � CU-001 : Validar Usuario

Heredado de -

Prioridad Alta

Reglas de

Negocio RF-004

Requerimientos

especiales -




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


� Colaborador

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

información de una evaluación.

Trigger Un usuario del proyecto ingresa a la opción consultar

Evaluación.

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

la evaluación debe estar finalizada.

Postcondiciones Ninguna


1. El sistema verifica que el usuario sea líder o

colaborador del proyecto. De no cumplirse se

ejecuta el flujo alternativo CU-007.1.

2. El sistema presenta la siguiente información de la

evaluación al usuario proveyendo la opción de

imprimir en papel.


� Proyecto al cual pertenece

� Colaborador de la creo

� Descripción

� Resultado final expresado numérica y

gráficamente.

� Todas las preguntas y respuestas de la

evaluación que fueron respondidas y que

justifican el resultado.

Flujos

alternativos

CU-007.1






Excepciones -

Extensiones -

Incluye � CU-001 : Validar Usuario

Heredado de -

Prioridad Alta

Reglas de

Negocio RF-004


-

Hipótesis -

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

5.3.8. Crear proyecto


ID CU-008

Nombre CREAR PROYECTO



Actores � Visitante

Descripción El sistema le permite a un usuario registrado crear un nuevo

proyecto y convertirse en su líder.

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

Precondiciones -

Postcondiciones � El proyecto queda creado.


1. El sistema presenta un formulario para que el

usuario ingrese la descripción del nuevo proyecto.

2. El usuario completa de información y envía el

formulario.

3. El sistema crea el nuevo proyecto.

Flujos

alternativos -

Excepciones -

Extensiones -





Heredado por -

Prioridad Alta

Reglas de

Negocio RF-001


Hipótesis

Notas Figura A1.27. Caso de uso Crear proyecto

5.3.9. Asignar colaborador


ID CU-009

Nombre ASIGNAR COLABORADOR




Descripción El líder de un proyecto designa a un usuario con el rol de

colaborador para que pueda crear nuevas evaluaciones en

dicho proyecto.

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

Precondiciones � El líder de proyecto ha iniciado sesión en el

sistema.

Postcondiciones � Un nuevo usuario cuenta con el rol de colaborador.


1. El sistema verifica que el usuario sea líder del

proyecto. De no cumplirse se ejecuta el flujo


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

Flujos

alternativos

CU-009.1






Excepciones -

Extensiones -


Heredado por -

Prioridad � Alta

Reglas de Negocio

RF-006

Requerimientos

especiales

Hipótesis

Notas Figura A1.28. Caso de uso asignar colaborador

5.3.10. Inicializar cuestionario


ID CU-010

Nombre INICIALIZAR CUESTIONARIO



Actores � Administrador

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

de evaluación de proyectos con los valores

predeterminados.

Trigger El administrador accede a la opción de inicializar Plantilla

devaluación.

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

Postcondiciones � La Plantilla estándar de evaluación de proyectos se

encuentra inicializada con los valores por defecto.


1. El sistema verifica que el usuario sea

administrador. De no cumplirse se ejecuta el flujo


2. El sistema presenta un formulario que solicita al

administrador del sistema su confirmación para

inicializar la Plantilla de evaluación con los valores

por defecto.




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

ejecuta el flujo alternativo CU-009.2. Si el

administrador contesta “no” se ejecuta el flujo

alternativo CU-009.3

Flujos

alternativos

CU-009.1



CU-009.2

El sistema inicializa la Plantilla de evaluación con los

valores por defecto y notifica al administrador sobre la

acción.

CU-009.3

El sistema notifica al usuario que no se realizó la

inicialización del cuestionario.

Excepciones -

Extensiones -


Heredado por -

Prioridad � Alta

Reglas de

Negocio RF-005

Requerimientos

especiales

Hipótesis

Notas Figura A1.29. Caso de uso inicializar cuestionario




6. Arquitectura del Sistema

6.1. La arquitectura Appengine

La Figura A1.30 presenta un gráfico que resume las principales componentes de

la arquitectura propuesta por Appengine y que, en líneas generales, respeta el

clásico patrón MVC y que será la base del desarrollo del Sistema.

Figura A1.30. Arquitectura de Appengine

� Entidades persistentes: Appengine provee una capa destinada al modelado

de entidades persistentes. Si bien la persistencia y el modelo de negocio están

completamente acoplados en esta capa (Patrón Active Record) Appengine

provee un framework de persistencia que permite abstraerse del modelo

relacional y trabajar con entidades, utilizando operadores en las entidades y el

lenguaje GQL para realizar consultas de objetos.

� Controlador RequestHandler. Appengine provee un controlador que

encapsula el protocolo http y permite capturar la interacción del usuario a

través de comandos GET o POST, que se traducen en Requests o pedidos. El

controlador se programa según se requiera y se presentarán los resultados

utilizando plantillas (ver a continuación) a través de Responses o respuestas.




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

desarrollar las vistas HTML utilizando plantillas (Patrón Template View) y

fomentando la reutilización y desacople con el modelo de negocio.




7. Diseño de la aplicación

En esta sección se detallará el diseño elegido para implementar el sistema. La

técnica elegida para llevar a cabo la tarea consiste en presentar los modelos de lo

general a lo particular.

� Se comenzara por presentar los paquetes que componen la aplicación y su

relación.

� Posteriormente se describirá cada paquete como un conjunto de clases que

colaboran para resolver alguna parte del sistema, utilizando diagramas de

clase UML.

� Finalmente se describirán las responsabilidades de las clases más relevantes

del paquete.

Una vez presentados en detalle cada uno de los paquetes y las clases del sistema

se utilizarán diagramas de secuencia que permitan comprender la dinámica del

sistema a través de la interacción de las clases de distintos paquetes.

7.1. Diagrama de Paquetes de clases

A partir de la arquitectura presentada, que está basada fundamentalmente en el

patrón MVC, se diseñaron los paquetes que interrelacionados implementan la

funcionalidad del sistema.

La categorización por colores que se presenta en la Figura A1.31 será utilizada

de aquí en adelante en este documento, para facilitar la comprensión del

mismo.

Modelo

Vista

Controlador

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

El diagrama presentado en la Figura A1.32 muestra los paquetes de las clases del

sistema y sus dependencias, categorizando cada uno de ellos por medio de colores

que permiten identificar a qué categoría pertenecen.

Las categorías existentes son las tres definidas en el modelo MVC (modelo, vista y

controlador) más una cuarta denominada infraestructura. Esta cuarta categoría en

provista por el entorno Appengine e implementa los servicios de base que




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

v iew

+ 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 el

diagrama todos los paquetes de la categoría controlador del sistema, incluyendo

solamente el paquete controlador evaluatorform. Para una descripción detallada

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

documento.

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 los

paquetes de infraestructura ya que han sido muy bien documentados por

Appengine.

Nuevamente la columna tipo permite identificar la categoría a través de su color

asociado.

Nombre Tipo CU que

implementa

Descripción

dbmodel Modelo Todos Contiene las clases que

implementan el modelo de la

aplicación, incluyendo su

persistencia.

view Vista - Implementa funciones

genéricas de representación

de los datos en formato

HTML.

evaluatorform Controlador CU-004

CU-005

CU-007

Creación, ejecución y cálculo

de una evaluación de

viabilidad para un proyecto.

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

view_project Controlador CU-006

CU-009

Creación y consulta en

proyecto.

add_evaluator Controlador CU-002 Agregar evaluadores.

help Controlador CU-001 Inicio y cierre de sesión el

sistema. Manual de Usuario.

data Controlador CU-003 dos

CU-010

Inicialización de datos.

Figura A1.33. Trazabilidad entre paquetes y casos de uso

7.2. dbmodel. La capa De dominio

La capa de dominio, se encarga de modelar la lógica del estudio de viabilidad,

incluyendo aquellas clases que son consideradas entidades y, por ende, deben ser

persistentes.

Esta capa se desarrolla dentro del componente de Modelo y Persistencia de

Appengine. Dentro de la misma existen dos niveles de los cuales uno de ellos está

acoplado al otro y usa sus servicios para resolver el estudio:




7.2.1. Nivel1. Cuestionario

En este nivel se encuentran las entidades que modelan el cuestionario: las

preguntas, las respuestas admitidas para cada pregunta, y la secuencia dinámica

que permite conocer la próxima pregunta a partir de una pregunta respondida

con una respuesta determinada. Este nivel implementa un grafo dirigido no

cerrado, que representa todas las posibles secuencias del cuestionario.

Este nivel, en resumen, representa una plantilla de un cuestionario dinámico. El

término dinámico se refiere a que el cuestionario cambia según las preguntas

respondidas anteriormente.

7.2.2. Nivel 2. Estudio de Viabilidad

En este nivel se encuentran las entidades que modelan el estudio de viabilidad

propiamente dicho: los proyectos, las evaluaciones realizadas para dichos

proyectos. Debido a que las evaluaciones se realizan por medio de un

cuestionario, este nivel es dependiente del anterior. Cada evaluación es una

instancia de una plantilla de cuestionario, cuyas preguntas son respondidas con

algún valor de respuesta admitido y cuya secuencia está determinada por dichos

valores.

A continuación se presenta en la Figura A1.34 un gráfico esquemático que

permite relacionar los dos niveles de la capa de dominio:

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




En el ejemplo presentado en la Figura A1.34 puede verse que el Nivel 1

implementa un Grafo dirigido no cerrado que permite recorrer todas las opciones

del cuestionario comenzando desde la pregunta uno y finalizando en la pregunta

6 o en la pregunta 4. No es necesario que el cuestionario finalice siempre en la

misma pregunta, ya que una pregunta del cuestionario es la última cuando posee

menos del total de opciones de aristas dirigidas hacia otras preguntas (vértices).

En el ejemplo si se llega a la pregunta 6, el cuestionario finaliza porque no existe

arista que conduzca hacia otra pregunta. Por otra parte, si se llega a la pregunta 4

y se contesta “no“, el cuestionario también finaliza ya que no existe arista con ese

valor que conduzca a una próxima pregunta. Si llegando a la pregunta cuatro se

contestara "sí" entonces el cuestionario si continuaría porque existe un arista con

dicho valor que conduce de la pregunta 4 a la pregunta 5.

Observando ahora el nivel 1 se observa una instancia del cuestionario que ha sido

respondida y, por ende posee sólo un camino lineal.

Al comenzar el cuestionario el usuario contestó con el valor "no" la pregunta 1,

con lo cual el grafo lo llevó a la pregunta 2. En este caso contexto con el valor "sí",

pasando entonces a la pregunta 3. Siguiendo la secuencia el cuestionario finaliza

cuando el usuario llega a la pregunta 6 y la responde.

Como puede verse esta técnica de grafos permite una gran flexibilidad al

momento de diseñar los cuestionarios.

7.2.3. Diagrama de Clases

Se ha presentado anteriormente una explicación coloquial del diseño del modelo

en dos niveles. En esta sección se presentará el modelo de software elegido para

implementarlo, a través de un diagrama de clases UML que se muestra en la

Figura A1.35:




cd Modelo

db.Model

Question

+ category: db.TextProperty+ description: db.TextProperty+ dimension: db.TextProperty+ idquestion: db.IntegerProperty+ thresholdvalue: db.TextProperty+ type: db.TextProperty+ weight: db.IntegerProperty

+ dimensionText()+ nextQuestions() : q:Question[]+ validAnswers() : a: Answer[]

db.Model

NextQuestion

+ idanswer: db.IntegerProperty+ idnextquestion: db.IntegerProperty+ idquestion: db.IntegerProperty

+ answer() : Answer+ nextQuestion() : Question+ question() : Question

db.Model

Answer

+ description: db.TextProperty+ idanswer: db.IntegerProperty

db.Model

Project

+ createdate: db.DateTimeProperty+ description: db.TextProperty+ owner: db.UserProperty+ releasedate: db.DateTimeProperty+ testdate: db.DateTimeProperty

+ addEvaluation(string, Evaluation)+ addMember(string, string)+ currentUserIsMember()+ getEvaluations() : Evaluation[]+ removeMember(string, string)+ userIsMember(string)

db.Model

Ev aluation

+ actualresult: db.IntegerProperty+ createdate: db.DateTimeProperty+ description: db.TextProperty+ idproject: db.ReferenceProperty(Project)+ owner: db.UserProperty

+ calculate() : Result+ isComplete() : bool+ lastQuestion() : Question+ nextQuestion() : Question+ questions() : Question[]

Result

+ adaptabilidad: array[4]+ completo: bool+ exito: array[4]+ justificacion: array[4]+ plausibidad: array[4]+ resultado: array[4]

+ A() : float+ E() : float+ J() : float+ P() : float+ viability(var)

db.Model

Ev aluationInstance

+ description: db.TextProperty+ dimension: db.TextProperty+ idanswer: db.IntegerProperty+ idevaluation: db.ReferenceProperty(Evaluation)+ idinstance: db.IntegerProperty+ idquestion: db.IntegerProperty+ thresholdvalue: db.TextProperty+ type: db.TextProperty+ weight: db.IntegerProperty

+ answerText(var)+ dimensionText(var)

Nivel 2. Estudio de Viabi lidad

Nivel 1. Questionario

db.Model

ProjectMember

+ idproject: db.ReferenceProperty(Project)+ member: db.UserProperty+ role: db.TextProperty()

db.Model

Ev aluator

+ evaluator: db.UserProperty

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

User

+ email: Text+ nickname: Text

Provisto por el User API 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 dbmodel

El Nivel 1 del modelo está implementado por las siguientes clases:

� Question: implementa la pregunta con todos sus atributos (identificador de

pregunta, categoría de la metodología P3TQ, texto de la pregunta, dimensión

de la viabilidad, umbral, tipo y peso). El tipo de pregunta permite conocer

cuáles son las posibles respuestas admitidas. Por ejemplo el tipo booleano

solamente admitir a valores “si” y “no”. Mientras que el tipo “ difuso”

admitirá los valores "ninguno", "muy poco", "medio", "alto", "muy alto". Esta

clase representa, entonces, los vértices del grafo.




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

cuestionario y la siguiente. La clase posee tres atributos que son el

identificador de la pregunta respondida, el valor de respuesta de dicha

pregunta y el identificador de la próxima pregunta en el cuestionario. Con

estos tres atributos puede conocerse cuál es la próxima pregunta del

cuestionario a partir de la pregunta actual y la respuesta. Esta clase representa,

entonces, las aristas del grafo.

� Answer: implementa los tipos de respuesta que se admiten en las preguntas

del cuestionario. Posee solamente dos atributos (identificador la respuesta y

descripción).

El Nivel 2 del modelo está implementado por las siguientes clases:

� EvaluationInstance: Implementa una pregunta del cuestionario respondida

para una evaluación determinada. Esta clase se encarga de copiar toda

información de la pregunta que instancia y el valor de respuesta que el

usuario haya ingresado.

� Evaluation: implementa una evaluación completa realizada por un usuario.

Sus atributos son el creador de la evaluación, la fecha de creación, su

descripción y su estado actual. La evaluación permanece abierta mientras no

se haya alcanzado una última pregunta de cuestionario; y se encuentra cerrada

en caso contrario, pudiéndose conocer el resultado del evaluación. Esta clase

se encarga de obtener la secuencia de preguntas del cuestionario consumiendo

las clases del nivel 1. Cuando el cuestionario finaliza posee una operación

calculate() que permite conocer el resultado del evaluación de viabilidad.

� Result: Esta clase encapsula el resultado de un estudio de viabilidad, obtenido

a partir de una evaluación completa. Posee cinco atributos correspondientes a

los cuatro sectores de las dimensiones del estudio de viabilidad, más el vector

resultado final.

� Project: esta clase implementa un proyecto en el cual su creador y

colaboradores crearán evaluaciones para estimar su viabilidad. Sus atributos

son su identificador, su usuario propietario (líder de proyecto), sus miembros

colaboradores (implementado a través de la clase ProjectMember), su

descripción y su fecha de creación.

� Evaluator: implementa los usuarios que tienen la capacidad de modificar los

atributos del cuestionario de evaluación. Posee una operación de clase llamada

all(), que permite obtener una colección de todos los usuarios con rol de

evaluador y una operación llamada userIsEvaluator() que permite conocer,




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

evaluador o no.

7.3. View. Paquete de soporte para vista.

Las clases pertenecientes a este paquete, que se muestran en la Figura A1.36,

tienen la responsabilidad de generar contenidos para la interfaz de usuario. cd v iew

object

Ev aluationDraw

+ accepted: bool = 60+ draw: bool+ evaluation: Evaluation+ maxsize: int = 100

+ createArray(Evaluation[]) : EvaluationDraw[]+ drawA() : string+ drawBar(int) : string+ drawE() : string+ drawJ() : string+ drawP() : string+ drawViabili ty() : string+ getEvaluation() : Evaluation+ setEvaluation(Evaluation)

object

CustomMenu

+ getCustomMenu() : string

Logical Model::User

+ email: Text+ nickname: Text

db.Model

Logical Model::Ev aluator

+ evaluator: 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áfico

de barras en código HTML de cada una de las dimensiones de una evaluación,

desacoplando la responsabilidad de dibujo en la clase de dominio. Almacena

un objeto de la clase Evaluation (atributo evaluation), el tamaño máximo de

escala (atributo maxsize). Existe una operación de clase que funciona como

factory para crear una colección de objetos EvaluationDraw a partir de una

colección de objetos Evaluation. El motor de renderización de la vista (django),

entonces, utiliza objetos EvaluationDraw, con los cuales puede acceder a toda

la información de una evaluación y, además, podrá dibujar gráfico de barras

con dicho información. Las operaciones de dibujo son DrawBar, que permite

dibujar un gráfico de barras genérico, a partir de un valor resultado entre cero

y 10. Las operaciones drawP, drawA, drawJ, drawE y drawViability permiten

dibujar gráfico de barras para las dimensiones de plausibilidad a,

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

respectivamente.




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

opciones del menú de usuario según el rol que posea el usuario está

ejecutando la aplicación. Para esto, verifica si el usuario es administrador y/o

evaluador y devuelve en la colección opciones específicas para estos roles. El

motor de renderización de la vista recibe siempre una colección de opciones

que le permite mostrar la funcionalidad específica por rol.

7.4. Paquetes de Controladores

Como se explicó anteriormente, todos los controladores implementan la interfaz

de webapp.RequestHandler, la cual posee las siguientes operaciones:

� get(): permite procesar un pedido GET del protocolo http.

� put(): permite procesar un pedido PUT del protocolo http.

� redirect(): permite redireccionar a un nuevo enlace el cliente http.

Para poder procesar los predios de un cliente cuenta con los siguientes atributos:

� request: este objeto encapsula la información de solicitud de un cliente,

fundamentalmente toda las variables y sus valores enviados.

� response: este objeto permite que el controlador escriba los resultados del

proceso, generalmente en formato HTML.

A continuación se presentan los diagramas de clase de cada uno de los paquetes

que conforman los controladores de la aplicación.

7.4.1. evaluatorform

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




pd ev aluatorform

MainPage

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

AddMemberPage


Ev aluate


Logical Model::webapp.

RequestHandler

+ request: + response:


ev aluatorform.htmlerror.html evaluate.htmlv iew_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 usuario

la próxima pregunta a responder.

� Evaluate: esta clase tiene la responsabilidad de presentarle al usuario el

resultado de un estudio de viabilidad para una evaluación finalizada.

7.4.2. Add Evaluator





cd add_ev aluator

webapp.RequestHandler

MainPage





add_ev aluator.html

error.html

Figura A1.38. Diagrama de clases del paquete add_evaluator


� MainPage: esta clase tiene la responsabilidad de agregar o eliminar un

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

proyectos.

7.4.3. Choose_project





cd choose_project

webapp.RequestHandlerwebapp.RequestHandler

MainPage





choose_project.html

Figura A1.39. Diagrama de clases del paquete choose_project


� MainPage: esta clase tiene la responsabilidad de seleccionar todos los

proyectos de sistema y presentárselos al usuario para que este seleccione uno.

En caso de que el usuario de es crear un nuevo proyecto esta clase se encarga

de hacer persistente este nuevo proyecto en el sistema.




7.4.4. Help

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


AboutPage



LogoutPage



LoginPage





about.html login.htmllogout.html

Figura A1.40. Diagrama de clases del paquete help


� 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 v iew_project

webapp.RequestHandlerwebapp.RequestHandlerwebapp.RequestHandler

MainPage





v iew_project.htmlv iew_project.csv

Figura A1.41. Diagrama de clases del paquete view_project


� 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 Secuencia

A continuación se presentan los diagramas de secuencia que permiten

comprender cómo colaboran las clases de las distintas categorías (modelo, pista,

controlador e infraestructura) para resolver la funcionalidad requerida.

Se han incluido aquellas secuencias que se consideran fundamentales para el

sistema. Las restantes se resuelven de manera análoga a las presentadas o son

muy simples de implementar por lo cual su representación gráfica no agrega

valor.

Además del diagrama se describirán brevemente los escenarios dentro de los

cuales transcurre cada secuencia.

7.5.1. Crear Proyecto

� Escenario: El usuario ha iniciado sesión en el sistema. Se encuentra frente a la

pantalla de selección de proyectos y desea crear un nuevo proyecto,

completando una descripción para el mismo y enviando el formulario. Se

considera que no ocurren errores o excepciones. A continuación se presenta en

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

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 un

proyecto. Se encuentra frente a la pantalla de consulta de dicho proyecto y

desea agregar una nueva evaluación, ingresando, para ello, una descripción

para la nueva evaluación y enviando el formulario. Se considera que no

ocurren errores o excepciones. A continuación se presenta en la Figura A1.43

el diagrama de secuencia. sd Crear Ev aluacion

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 una

evaluación previamente creada y aún no completada. Se encuentra frente a la

pantalla de ejecución de la evaluación y desea completar la siguiente pregunta

del cuestionario. Selecciona entonces la respuesta que considera correcta y

envía el formulario. Se considera que no ocurren errores o excepciones. A

continuación se presenta en la Figura A1.44 el diagrama de secuencia.




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 una

evaluación previamente creada y aún no completada. Se encuentra frente a la

pantalla de ejecución de la evaluación y desea completar la siguiente pregunta

del cuestionario. Selecciona entonces la respuesta que considera correcta y

envía el formulario. Se considera que no ocurren errores o excepciones. A

continuación se presenta en la Figura A1.45 el diagrama de secuencia. sd Calcular Ev aluación

Miembro evaluate evaluatorform::evaluate

eval :Evaluation

Si la evaluación está completa.

[eval.isComplete]: result:= calculate()

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 los

diagramas de clase del controlador.

El diagrama que se muestra a continuación la Figura A1.46 permite ver, a través

de un diagrama de estados UML, como se relacionan entre sí a partir de la

interacción del usuario con el sistema. sm Statecharts

choose_project

v iew_project

add_ev aluator

ev aluate

Logout

run

about

login

edit

clear

ayuda

nueva evaluación carga de pregunta del cuestionario

agregar evaluador (usuario administrador)

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 plantil la de evaluación

Inicial izar planti lla 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, y

las interfaces con el usuario.

7.6.1. Logout

Esta pantalla, mostrada en la Figura A1.47, se presenta cuando el usuario desea

ingresar al sistema y aún no sea autenticado, o cuando decide salir, cerrando la

sesión.




Figura A1.47. Pantalla Logout.

7.6.2. Login

Esta pantalla, mostrada en la Figura A1.48, es provista por el API user del

appengine, para que el usuario pueda autenticar se en el tenga a través de su 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 los

proyectos existentes en el sistema, mostrando la fecha de creación, la descripción,

el e-mail del líder del proyecto, la cantidad de evaluaciones realizadas y el rol que

tiene el usuario en dicho proyecto. El usuario puede elegir cualquiera de los

proyectos para consultar la información existente. También presenta una interfaz

para que el usuario pueda crear un nuevo proyecto ingresando un nombre para el

mismo.

Figura A1.49. Pantalla Choose Project.

7.6.4. View Project

Esta pantalla, mostrada en la Figura A1.50 presenta al usuario toda la

información referente a un proyecto que él ha seleccionado. Muestra la

información de fecha de creación, líder de proyecto, colaboradores y evaluaciones

realizadas. Para estas últimas muestra la fecha de creación, descripción, autor y, si




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

evaluación en dicho proyecto, agregar colaboradores al proyecto en caso de que el

usuario sea el líder y opciones para exportar la información o imprimir.

Figura A1.50. Pantalla View Project.

7.6.5. Run

Esta pantalla, mostrada en la Figura A1.51, le presenta al usuario una interfaz

para que pueda completar el cuestionario de evaluación. Muestra el nombre

proyecto, el nombre de la evaluación, la dimensión, peso y descripción de la

pregunta y las opciones de respuesta.

Figura A1.51. Pantalla run.




7.6.6. Evaluate

Esta pantalla, presentada en la Figura A1.52, se muestra cuando el usuario

miembro del proyecto selecciona una evaluación finalizada, o cuando contesta la

última pregunta del cuestionario. Presenta el resultado del estudio de viabilidad

mostrando los valores de los vectores justificación, adaptabilidad, plausibilidad,

éxito y viabilidad y también el módulo de cada uno de ellos numérica y

gráficamente. Para permitir trazabilidad presenta cada una de las preguntas

respondidas y las respuestas ingresadas. Provee interfaces para que el usuario

pueda exportar o imprimir la información.

Figura A1.52. Pantalla evaluate.

7.6.7. Add Evaluator

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

del sistema una lista con los e-mail de todos los usuarios evaluadores del sistema.

Provee interfaces que permiten agregar nuevos usuarios evaluadores, eliminar de

la lista usuarios existentes e imprimir la información.

Figura A1.53. Pantalla add evaluator.




7.6.8. edit

Esta pantalla, mostrada en la Figura A1.54, le presenta al usuario evaluador una

interfaz que le permite modificar la plantilla de evaluación de proyectos. Muestra

la información de cada preguntas del cuestionario, que puede ser modificada y

enlaces que dirigen a la próxima pregunta según el valor de respuesta.

Figura A1.54. Pantalla edit.

7.6.9. About

Esta pantalla, mostrada la Figura A1.55, le presenta al usuario en manual de

ayuda, y la información sobre la versión en ejecución del sistema.

Figura A1.55. Pantalla About.

7.6.10. Data

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

una interfaz para confirmar si desea eliminar toda la información del sistema de

inicializar la plantilla de evaluación de proyectos.




Figura A1.56. Pantalla data.

7.6.11. Barra de Menú

La barra de menú, mostrada en la Figura A1.57, le permite al usuario seleccionar

las opciones del sistema. Se encuentra ubicada en la zona superior de cada una de

las pantallas presentadas anteriormente.

Figuras 57. Menú del Sistema.

Las acciones que pueden realizarse con el menú son:

� Proyectos: conduce a cualquier usuario que inició sesión en el sistema a la

pantalla choose project.

� Cuestionario: solamente visible por los usuarios con el rol de evaluadores.

Conduce al usuario a la pantalla edit.

� Evaluadores: solamente visible por el administrador de sistema. Conduce a la

pantalla add evaluator.

� Inicializar: solamente visible por el administrador de sistema. Conduce a la

pantalla clear.

� Ayuda: conduce a cualquier usuario que inició sesión en el sistema a la

pantalla about.

� Salir: conduce a cualquier usuario que inició sesión en el sistema a la pantalla

logout.

7.7. Diagrama de Despliegue

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

A1.58, ya que consiste en un servidor appengine (de google o local) conteniendo

todo los componentes.

En el modelo de appengine existe una correspondencia uno a uno entre

componente y paquete. Por lo cual, el nodo servidor contendrá todos los paquetes

(componentes) presentados anteriormente en este documento.




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

protocolo http. dd Despliegue

appengine Serv er

choose_project

datadbmodel

ev aluatorform

help

v iew

v iew_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 ejecutados

satisfactoriamente que surgen de los escenarios más importantes de cada caso de

uso.

8.1. Validar Usuario

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

escenarios del caso de uso CU-001 : Validar usuario.

8.1.1. Inicio de sesión exitoso

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

Identificación CP-001 : Inicio de sesión exitoso

Caso de Uso

que 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)

Resultado Esperado

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 fallido

Caso de Uso


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

Datos de

Entrada El usuario ingresa las siguientes combinaciones de e-mail y

contraseña:

� E-mail válido y contraseña inválida.

� E-mail y contraseña inválidas.

� E-mail inválido y contraseña de algún usuario

válido.

� E-mail y contraseña nulos.




� E-mail nulo y contraseña correcta.

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

Resultado

Esperado 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


escenarios del caso de uso CU-002 : Asignar Evaluador.

8.2.1. Administrador agrega nuevo evaluador

La Figura A1.61 nuestra el caso de prueba Administrador agrega nuevo

evaluador.

Identificación CP-003 : Administrador agrega nuevo evaluador

Caso de Uso que lo origina

CU-002

Escenario El administrador accede a la pantalla para agregar un nuevo

usuario evaluador.

Datos de Entrada

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

google)

Resultado

Esperado El usuario evaluador queda registrado en el sistema.

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

8.2.2. Administrador intenta agregar evaluador registrado

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

evaluador registrado.

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


CU-002

Escenario El administrador accede a la pantalla para agregar un

usuario evaluador, que ya fue registrado previamente en el

sistema.

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




Entrada registrado previamente (cuenta activa en google)

Resultado Esperado

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

Estado Ejecutado correctamente. Figura A1.62. Caso de prueba Administrador intenta agregar evaluador registrado

8.2.3. Administrador intenta agregar evaluador con e-mail nulo

La Figura A1.63 nuestra el caso de prueba Administrador intenta agregar

evaluador con e-mail nulo.

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

nulo

Caso de Uso


Escenario El administrador accede a la pantalla para agregar un nuevo

usuario evaluador.

Datos de

Entrada 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 evaluador

Caso de Uso


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

accede a la pantalla para agregar un nuevo usuario

evaluador.

Datos de

Entrada Ninguno

Resultado

Esperado El sistema notifica al usuario que no cuenta con los permisos

suficientes 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


escenarios del caso de uso CU-003 : Actualizar planilla de evaluación.

8.3.1. Evaluador actualiza pregunta

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

Identificación CP-007 : Evaluador actualiza pregunta

Caso de Uso


Escenario Un usuario evaluador accede a la pantalla modificar las

preguntas del cuestionario de la plantilla de evaluación.

Datos de

Entrada El usuario evaluador modifica los siguientes datos de las

preguntas:

� modifica el texto de la Descripción

� modifica el peso (valor entero entre 0 y 10)

� modifica la dimensión

Resultado Esperado

El sistema actualiza los datos de la pregunta y notifica al

usuario.

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

8.3.2. Evaluador intenta actualizar pregunta con datos incorrectos

La Figura A1.66 nuestra el caso de prueba Evaluador intenta actualizar pregunta

con datos incorrectos.

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

incorrectos

Caso de Uso


Escenario Un usuario evaluador accede a la pantalla modificar las

preguntas del cuestionario de la plantilla de evaluación.

Datos de

Entrada 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)

Resultado

Esperado El sistema y notifica al usuario que los datos ingresados son

incorrectos.




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

8.3.3. Usuario intenta actualizar pregunta

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

Identificación CP-009 : Usuario intenta actualizar pregunta

Caso de Uso


Escenario Un usuario, que no cuenta con el rol de evaluador, accede a

la pantalla para modificar las preguntas del cuestionario de

la plantilla de evaluación.

Datos de

Entrada Ninguno

Resultado



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

8.4. Evaluar viabilidad


escenarios del caso de uso CU-004: Evaluar viabilidad.

8.4.1. Proyecto altamente viable

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

Identificación CP-010 : Proyecto altamente viable


CU-004

Escenario Un miembro del proyecto accede a la pantalla que permite

continuar la ejecución de una evaluación creada por él.

Datos de Entrada

� El miembro del proyecto contesta Si o Todo (Si) en

cada una de las preguntas.

Resultado

Esperado 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 rotundamente

Caso de Uso




Datos de

Entrada El miembro del proyecto contesta las preguntas con los

valores indicados a continuación:

� Las partes interesadas están identificadas? Las

partes interesadas son aquellas personas o grupos

de personas que afectan o pueden ser afectadas por

el proyecto. Boxes de referencia de la metodología

P3TQ: DB1, AB2, AB3 Mucho

� Todas las partes interesadas cuentan con la

disponibilidad de tiempo para avocarse al proyecto?

Boxes de referencia de la metodología P3TQ: DB1,

AB2, AB3: Mucho

� Existen partes interesadas con autoridad suficiente

dentro de la organización para liderar el proyecto

de explotación? Boxes de referencia de la

metodología P3TQ: DB1, AB2, AB3 Poco

� Existen partes interesadas con recursos económicos

suficientes para encarar el proyecto? Boxes de

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

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

buscar relaciones de interés? No

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




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

problema u oportunidad)? Si

� Con respecto a la problemática del negocio del

proyecto original: Se han encontrado datos de

utilidad para llevar a cabo la minería? El proyecto

original es aquel que origina el proyecto de

explotación que se está evaluando. Boxes de

referencia de la metodología P P3TQ: AB6 Poco

� Las partes interesadas han identificado o pueden

identificar aquellas características del negocio

importantes, que enmarcan sus expectativas del

proyecto de explotación? Boxes de referencia de la

metodología P3TQ: TB7 No

� La situación del negocio está enmarcada o puede

enmarcarse en un modelo a partir de los datos

conocidos? Boxes de referencia de la metodología

P3TQ: AB6 Poco

� Los Objetivos y Metas del negocio están definidos o

pueden definirse? Boxes de referencia de la

metodología P3TQ: AB6, TB5 Poco

� Se requiere inicialmente un análisis estratégico para

planificar escenarios corporativos? Si




P3TQ: AB9 Poco

� Existe un mapa del escenario estratégico,

consensuado con las partes interesadas. .Boxes de

referencia de la metodología P3TQ: AB12 No

� Están identificadas por las partes interesadas las

relaciones entre las cinco temáticas clave del

negocio(producto, lugar, precio, tiempo y

cantidad)? Boxes de referencia de la metodología

P3TQ: AB12 No

� Puede establecerse correspondencia entre el mapa y

las relaciones P3TQ? Boxes de referencia de la

metodología P3TQ: AB12 No




� Existen o pueden realizarse simulaciones que

permitan identificar ambigüedades, incertezas,

discordancias? Boxes de referencia de la


� Están caracterizadas o pueden caracterizarse las

relaciones clave del sistema? Boxes de referencia de

la metodología P3TQ: AB12 No

� Esta determinado o puede determinarse cuales de

los 26 recursos de gestión (Consultar la tabla 7.2 de

MII de P3TQ) son adecuados a cada potencial parte

interesada? Boxes de referencia de la metodología

P3TQ: AB12, MII Tabla 7.1 Poco

� Existe o puede obtenerse un set de datos sin

errores? Boxes de referencia de la metodología

P3TQ: DB9.1 No

� El set de datos obtenidos esta referenciado al caso

de negocio a estudiar? Boxes de referencia de la

metodología P3TQ: DB9.1 No

� Existen variables con único valor, o valores vacios

en sus instancias? Boxes de referencia de la

metodología P3TQ: DB9.2 Mucho

� Las variables categóricas están documentadas?


Poco

� Los nombres de los atributos son acorde a los

conceptos del negocio? Boxes de referencia de la

metodología P3TQ: DB9.3 Poco

� Son reconocidas y es posible adecuar variables

anacrónicas? Boxes de referencia de la metodología

P3TQ: DB9.4 No

� Existen datos suficientes como para crear diez

modelos predictivos con once atributos cada uno

(siempre distintos) y generar un set de

entrenamiento y otro de testeo? Boxes de referencia

de la metodología P3TQ: DB9.5, TB9.4 No

� Se dispone de un experto para analizar y asegurar

que el set de datos representa los escenarios más




importantes que pueden ocurrir en el negocio?

Boxes de referencia de la metodología P3TQ: DB9.6 No

� Es necesario realizar recodificación de variables

para mejor comprensión del modelo? Boxes de

referencia de la metodología P3TQ: DB9.7 Si

� Los conjuntos de variables de entrada y salida están

caracterizadas? Boxes de referencia de la

metodología P3TQ: AB11.1 Si

� Los datos están estructurados o pueden

estructurarse para aplicarlos en la herramienta de

minería elegida? Boxes de referencia de la

metodología P3TQ: AB11.1 Poco

� Están seleccionados los algoritmos de minería

adecuados al modelo? Boxes de referencia de la

metodología P3TQ: AB11.3 No

� Existe una herramienta de minería adecuada al

modelo y está disponible? Boxes de referencia de la


� De necesitarse comprar herramientas, existen

proveedores disponibles. .Boxes de referencia de la

metodología P3TQ: AB11.5 Poco

� Esta construido o puede construirse el MVCM

(Missing Value Check Model)? Boxes de referencia

de la metodología P3TQ: AB11.1 No

� El objetivo de la explotación es entender una

situación? No

� El objetivo de la explotación es aplicar una

clasificación? No

� El objetivo de la explotación es buscar una

predicción? No

Resultado Esperado

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 viable

Caso de Uso




Datos de






el proyecto..Boxes de referencia de la metodología

P3TQ: DB1, AB2, AB3 Regular




AB2, AB3 Mucho




metodología P3TQ: DB1, AB2, AB3 Mucho



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


buscar 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 de

utilidad para llevar a cabo la minería? El proyecto

original es aquel que origina el proyecto de

explotación que se está evaluando..Boxes de

referencia de la metodología P3TQ: AB6 Regular

� Las partes interesadas han identificado o pueden

identificar aquellas características del negocio

importantes, que enmarcan sus expectativas del

proyecto de explotación? Boxes de referencia de la

metodología P3TQ: TB7 Si




P3TQ: AB6 Regular

� Los Objetivos y Metas del negocio están definidos o

pueden definirse? Boxes de referencia de la

metodología P3TQ: AB6, TB5 Regular


planificar escenarios corporativos? Si




P3TQ: AB9 Regular

� Existe un mapa del escenario estratégico,

consensuado con las partes interesadas. .Boxes de

referencia de la metodología P3TQ: AB12 Si

� Están identificadas por las partes interesadas las

relaciones entre las cinco temáticas clave del

negocio(producto, lugar, precio, tiempo y

cantidad)? Boxes de referencia de la metodología

P3TQ: AB12 Si

� Puede establecerse correspondencia entre el mapa y

las relaciones P3TQ? Boxes de referencia de la

metodología P3TQ: AB12 Si




� Existen o pueden realizarse simulaciones que

permitan identificar ambigüedades, incertezas,

discordancias? Boxes de referencia de la


� Están caracterizadas o pueden caracterizarse las

relaciones clave del sistema? Boxes de referencia de

la metodología P3TQ: AB12 Si

� Esta determinado o puede determinarse cuales de

los 26 recursos de gestión (Consultar la tabla 7.2 de

MII de P3TQ) son adecuados a cada potencial parte

interesada? Boxes de referencia de la metodología

P3TQ: AB12, MII Tabla 7.1 Regular



P3TQ: DB9.1 Si



metodología P3TQ: DB9.1 Si



metodología P3TQ: DB9.2 Regular

� Las variables categóricas están documentadas?


Regular






P3TQ: DB9.4 Si





de la metodología P3TQ: DB9.5, TB9.4 Si







Boxes de referencia de la metodología P3TQ: DB9.6 Si



referencia de la metodología P3TQ: DB9.7 No







metodología P3TQ: AB11.1 Regular









metodología P3TQ: AB11.5 Regular





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

Resultado Esperado

El sistema muestra como resultado de viabilidad:

� Vector Justificación = (3.40 ; 4.40 ; 5.60 ;6.60)


� Vector éxito = (8.95 ; 9.24 ; 9.54 ; 9.76)


� 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



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 de

situaciones esenciales

Caso de Uso




Datos de






el proyecto..Boxes de referencia de la metodología





AB2, AB3 Poco




metodología P3TQ: DB1, AB2, AB3 Mucho



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


buscar relaciones de interés? Si




� El proyecto original cuenta con el apoyo de la

organización? Boxes de referencia de la metodología


� El proyecto original cuenta con el apoyo de las

partes interesadas? Boxes de referencia de la

metodología P3TQ: DB1, AB2, AB3 Todo (Si)

� Existe comunicación con las partes interesadas del

proyecto original? El proyecto original es aquel que

origina el proyecto de explotación que se está

evaluando..Boxes de referencia de la metodología

P3TQ: DB1, AB2, AB3 Todo (Si)

� Se cumplieron los objetivos del proyecto original?

Mucho


planificar escenarios corporativos? No



P3TQ: DB9.1 Si



metodología P3TQ: DB9.1 Si



metodología P3TQ: DB9.2 Muy poco o nada

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


Mucho






P3TQ: DB9.4 Si








de la metodología P3TQ: DB9.5, TB9.4 Si




Boxes de referencia de la metodología P3TQ: DB9.6 Si



referencia de la metodología P3TQ: DB9.7 No







metodología P3TQ: AB11.1 Mucho









metodología P3TQ: AB11.5 Mucho





situación? Si

� Las variables utilizadas en el modelo están

relacionadas con conceptos que son conocidos por

las partes interesadas? Boxes de referencia de la

metodología P3TQ: AB11.1, DB11.5 Si

� Los objetos del negocio que representan las

variables pueden ser utilizados por las partes




interesadas, o gerentes para realizar mejoras en el

negocio. .Boxes de referencia de la metodología

P3TQ: AB11.1, DB11,5 Mucho

� Los datos son suficientes para definir las relaciones

explicativas? Boxes de referencia de la metodología

P3TQ: AB11.1 DB11.5 Si

Resultado

Esperado El sistema muestra como resultado de viabilidad:

� Vector Justificación = (10 ; 10 ; 10 ; 10)


� Vector éxito = (7.80 ; 8.37 ; 8.99 ; 9.47 )


� Vector adaptabilidad = (0 ; 0; 0 ; 0)

� Resultado adaptabilidad = 0

� Vector plausibilidad = (0 ; 0; 0 ; 0)

� Resultado plausibilidad = 0



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

8.5. Crear evaluación


escenarios del caso de uso CU-005 : Crear evaluación.

8.5.1. Miembro del proyecto crea evaluación

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

Identificación CP-011 : Miembro del proyecto crea evaluación

Caso de Uso


Escenario Un miembro del proyecto intenta crear una nueva

evaluación.

Datos de

Entrada El miembro del proyecto ingresa cualquiera de los siguientes

nombres:

� Texto Alfanumérico

� Texto nulo

Resultado Esperado

El sistema crea una nueva evaluación y redirige al usuario a

la 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

Caso de Uso


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

Datos de

Entrada El líder del proyecto ingresa cualquiera de los siguientes

nombres:


� Texto nulo

Resultado

Esperado El sistema crea una nueva evaluación y redirige al líder del

proyecto a la pantalla de ejecución de la evaluación.

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

8.5.3. Usuario intenta crear evaluación

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

Identificación CP-013 : Usuario intenta crear evaluación

Caso de Uso


Escenario Un usuario que no posee roles en un proyecto intenta crear

una evaluación en él.

Datos de

Entrada Ninguno

Resultado



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

8.6. Consultar proyecto


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 un

proyecto para consultarlo.

Datos de Entrada

El usuario selecciona de la lista de proyectos uno al cual

pertenece.

Resultado

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

del proyecto, que incluye los resultados de todas las

evaluaciones realizadas.

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

8.6.2. Usuario intenta consultar proyecto

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

Identificación CP-015 : Usuario intenta consultar proyecto


CU-006

Escenario Un usuario que no es miembro de un proyecto (ni

colaborador ni líder) selecciona ese proyecto para

consultarlo.

Datos de Entrada

El usuario selecciona de la lista de proyectos uno al cual no

pertenece.

Resultado


del proyecto, sin mostrar los resultados de las evaluaciones

realizadas.

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

8.7. Consultar Evaluación


escenarios 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) selecciona

una evaluación de ese proyecto para consultarla.

Datos de Entrada

El usuario selecciona una evaluación de la lista de

evaluaciones del proyecto.

Resultado


de la evaluación.

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

8.7.2. Usuario intenta consultar evaluación

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

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


CU-007

Escenario Un usuario que no es miembro de un proyecto (ni

colaborador ni líder) intenta consultar una evaluación de ese

proyecto.

Datos de Entrada

El usuario selecciona una evaluación de la lista de

evaluaciones del proyecto al cual no pertenece.

Resultado



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

8.8. Crear Proyecto


escenarios del caso de uso CU-008 : Crear proyecto.

8.8.1. Usuario crea Proyecto

La Figura A1.79 nuestra el caso de prueba Usuario crea proyecto.

Identificación CP-018 : Usuario crea proyecto




Caso de Uso


Escenario Un Usuario que ha iniciado sesión del sistema intenta crear

un nuevo proyecto.

Datos de

Entrada El usuario ingresa cualquiera de los siguientes nombres para

el proyecto:


� Texto nulo

Resultado

Esperado El sistema crea una nueva proyecto, designando como líder

al usuario creador, y redirigiendo al usuario a la pantalla de

información del proyecto.

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

8.9. Asignar colaborador


escenarios del caso de uso CU-009 : Asignar colaborador.

8.9.1. Líder del proyecto agrega nuevo colaborador

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

evaluador.

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


CU-009

Escenario El líder del proyecto accede a la pantalla para agregar un

nuevo colaborador al proyecto.

Datos de Entrada

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

Resultado

Esperado El usuario colaborador del proyecto queda registrado en el

sistema.

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

8.9.2. Líder del proyecto intenta agregar colaborador registrado

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

colaborador registrado.

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




registrado

Caso de Uso


Escenario El líder de proyecto accede a la pantalla para agregar un

colaborador, que ya ha sido registrado previamente en el

sistema, en el mismo proyecto.

Datos de

Entrada El líder del proyecto ingresa un e-mail válido, que ya fue

registrado previamente en ese proyecto (cuenta activa en

google)

Resultado Esperado

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

para ese proyecto.

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

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

La Figura A1.82 nuestra el caso de prueba Líder de proyecto intenta agregar

colaborador con e-mail nulo.

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

e-mail nulo

Caso de Uso


Escenario El líder de proyecto accede a la pantalla para agregar un

nuevo colaborador al proyecto.

Datos de

Entrada 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 nulo

8.9.4. Usuario intenta agregar colaborador al proyecto

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

proyecto.

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

Caso de Uso


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 de Entrada

Ninguno

Resultado



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

8.10. Inicializar cuestionario


escenarios del caso de uso CU-010 : Inicializar cuestionario.

8.10.1. Administrador inicializa cuestionario

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

Identificación CP-023 : Administrador inicializa cuestionario

Caso de Uso


Escenario El Administrador accede a la pantalla para inicializar la

plantilla de evaluación.

Datos de Entrada

El administrador contesta ”Si“

Resultado

Esperado El sistema inicializa la plantilla de evaluación y elimina

todos los registros de la base de datos.

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

8.10.2. Administrador intenta inicializar cuestionario

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

cuestionario.

Identificación CP-023 : Administrador intenta inicializar cuestionario

Caso de Uso


Escenario El Administrador accede a la pantalla para inicializar la

plantilla de evaluación.

Datos de

Entrada 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 inicializar

cuestionario.

Identificación CP-024 : Usuario intenta inicializar cuestionario

Caso de Uso


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

accede a la pantalla para inicializar la plantilla de

evaluación.

Datos de

Entrada Ninguno

Resultado Esperado

El sistema notifica al usuario que no cuenta con los permisos


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




9. Conclusión

A lo largo de este documento se desarrollaron de manera detallada todas las

etapas involucradas en el desarrollo de la herramienta DAMVE, desde los

requerimientos hasta el modelo de diseño para ser implementado en lenguaje

Python sobre la arquitectura Appengine de Google.

A continuación se resumen los aspectos más relevantes durante el desarrollo de la

herramienta DAMVE

� Si bien el documento presenta las etapas de manera consecutiva, suponiendo

un modelo de desarrollo en cascada, el proceso de desarrollo y por

consiguiente los contenidos del documento se fueron generando de manera

iterativa, siguiendo un proceso conducido por el dominio del problema.

� Durante la etapa de diseño se buscó siempre que la lógica del dominio del

problema fuese independiente del resto de la lógica de la aplicación (vista y

controlador). Este aspecto es fundamental en el desarrollo de software ya que

hace posible reutilizar completamente dominio para adaptarlo a otro

escenario. Además, dado que Appengine está basado en el patrón MVC, que

separa el dominio de la interfaz con el usuario (vista y controlador), se

consiguió una concordancia entre la arquitectura del sistema y el proceso de

desarrollo.

� Al estar la herramienta basada en un entorno web, se buscó optimizar la

interacción con el usuario. Para ello se implementaron interfaces en

AJAX/JSON, que minimizan la transferencia http entre el servidor y el cliente,

en los casos de uso que requieren mayor interacción usuario/sistema. Como

ejemplo se pueden citar los casos de uso CU-003 Actualizar planilla de

evaluación y CU-004 Evaluar viabilidad.

� A lo largo del documento se buscó registrar la trazabilidad que existe entre las

distintas etapas de desarrollo. La Figura A1.19 relaciona los requierimientos

funcionales con los casos de uso, permitiendo registrar la trazabilidad entre

Requerimientos y Casos de Uso. La Figura A1.33 relaciona los casos de uso,

con los paquetes de clases que los implementan permitiendo registrar la

trazabilidad entre Casos de Uso y Clases. Finalmente en la sección 8 se

desarrollan los casos de prueba como escenarios posibles para cada caso de

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

Prueba.




10. Posibles mejoras

Este documento podría mejorarse tomando en cuenta algunos de estos elementos:

� Incorporando fragmentos de código en lenguaje Python sobre aquella

funcionalidad del dominio que permita clarificar la implementación.

El Sistema DAMVE podría mejorarse tomando en cuenta algunos de estos

elementos:

� Desarrollar una capa de servicios web. Esto permitiría, por ejemplo, utilizar la

aplicación desde una interfaz de usuario de ventanas mejorando la interacción

usuario/herramienta, o permitir que la herramienta se integre con otros

sistemas proveyendo el servicio de evaluación de viabilidad. En el último caso

sería interesante integrar la herramienta DAMVE con un Sistema de

administración de proyectos.



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

Anexo 2. Manual de usuario la

Herramienta DAMVE




1. Introducción

El Sistema DAMVE tiene por finalidad, ayudar a los miembros de un proyecto de

explotación de información que utilizan la metodología P3TQ a evaluar su

viabilidad.

2. Requisitos

Para poder ejecutar el sistema DAMVE se requiere de un navegador web con

soporte para AJAX. Los siguientes navegadores funcionan correctamente con el

sistema DAMVE :

� Microsoft Internet Explorer 6.0 o superior

� Mozilla Firefox 2.0 o superior

En cualquiera de los dos casos deben habilitarse las opciones de cookies y

ejecución de comandos javascript.

3. Acceso al sistema

Cuando un usuario ingresa el enlace del sistema DAMVE en el navegador web se

presenta la siguiente pantalla, mostrada en la Figura A2.1.:

Figura A2.1. Pantalla de ingreso al sistema

Siguiendo el enlace el usuario accede a un formulario que le solicita identificarse

para poder ingresar al sistema. Los datos de acceso son:

� e-mai l : corresponde a la dirección de e-mail del usuario.

� Contraseña : se debe ingresar la clave de acceso que debe ser conocida por

el usuario.

Éstos datos son los pertenecientes a una cuenta de Google habilitada, si el sistema

se está ejecutando online.

Si los datos ingresados son correctos el usuario accede a la pantalla de selección

de proyectos, que se muestra en la Figura A2.2:




Figura A2.2. Pantalla de selección de proyectos

Por el contrario, si los datos ingresados son incorrectos, el sistema mostrará la

siguiente pantalla de error, que pedirá que se vuelvan a ingresar los datos

nuevamente.

4. Presentación de la interfaz

Se presenta a continuación, en la Figura A2.3, la pantalla de selección de

proyectos del sistema y se describen las distintas opciones de la barra de menús.

Figura A2.3. Panta l la de presentación de la inter faz

Los números asociados con cada elemento de la pantalla se describen a

continuación:

1. Nombre de usuario : en el encabezado de la pantalla puede verse el

nombre del usuario que está utilizando el sistema.

2. Proyectos : esta opción lleva a la pantalla de selección de proyectos que le

permite al usuario dar de alta un nuevo proyecto, seleccionar un existente

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 de

cuentan con el rol de evaluadores pueden acceder, y les permite modificar

los parámetros del cuestionario con el cual se realizan todos los estudios

de viabilidad. Esta opción se explica en detalle en el ítem 10.3 de este

manual.

4. Evaluadores : esta opción lleva a la pantalla que le permite al

administrador del sistema agregar nuevos usuarios evaluadores para que

puedan modificar la plantilla de evaluación, explicada anteriormente. Esta

opción se explica en detalle en el ítem 10.1 de este manual.

5. Inicializar : esta opción lleva a la pantalla que le permite al administrador

del sistema inicializar la base de datos, eliminando, de existir, toda la

información que exista y reiniciando la plantilla de evaluación. Esta

opción se explica en detalle en el ítem 10.4 de este manual.

6. Ayuda : esta opción permite consultar este manual en línea o descargarlo el

formato electrónico.

7. Salir : esta opción permite que el usuario cierra su sesión y salga del

sistema.

5. Creación y Selección de Proyectos

En este ítem explicara cómo crear o seleccionar proyectos existentes en la sistema.

5.1. Creación de un proyecto nuevo

Cualquier usuario registrado en el sistema es capaz de crear un nuevo proyecto y,

de esa manera, convertirse en el líder (o propietario) del mismo.

La creación de nuevo proyecto se lleva a cabo haciendo clic en la opción

“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 al

usuario la pantalla de gestión del proyecto.

5.2. Selección de un proyecto existente

Para seleccionar un proyecto existente en el sistema debe hacerse clic en la opción

“Proyectos” . Luego de hacer esto el usuario puede ver una lista con los proyectos

existentes en el sistema. La Figura A2.5 muestra esta lista:

Figura A2.5. Pantalla de selección de un proyecto

La información que se presenta es la siguiente:

� Fecha: fecha en la cual se creó el proyecto.

� Descripción: nombre del proyecto.

� Creador: e-mail del usuario creador del proyecto

� evaluaciones: cantidad de evaluaciones que se han realizado en dicho

proyecto.

� Rol: corresponde al rol del usuario con respecto a dicho proyecto,

representado por iconos. El icono significa que el usuario es el líder del

proyecto, el icono significa que el usuario de colaborador en el proyecto

y el icono significa que el usuario es visitante en dicho proyecto.

Haciendo clic en la fecha, descripción o rol de un proyecto el usuario

puede acceder a la pantalla de gestión del proyecto.

6. Roles de los usuarios

Antes de continuar explicando los pasos a seguir para poder crear evaluaciones

de viabilidad en la proyectos es necesario presentar los distintos roles que los

usuarios pueden tener dentro del sistema DAMVE. La Tabla 1 presenta los roles




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 como

colaborador de un proyecto por el líder del mismo.

Como tal puede crear evaluaciones de viabilidad. Un

colaborador de un proyecto no puede continuar la

ejecución de evaluaciones creadas por otro colaborador

del mismo proyecto.

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 y

evaluador porque el administrador lo ha designado.

7. Gestión de un Proyecto

Una vez creado un nuevo proyecto o seleccionado de la pantalla de selección de

proyecto, el usuario accede a la pantalla de gestión del proyecto. La Figura A2.6

presenta dicha pantalla:




Figura A2.6. Pantalla de gestión del proyecto

En esta pantalla puede observarse toda la información relativa al estudio de

viabilidad del proyecto, organizada por secciones.

� Sección general : se presenta el Nombre del proyecto, la fecha de creación

y el usuario propietario, o líder.

� Colaboradores : se presentan los e-mails de todos los usuarios designados

por 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 la

evolución de la viabilidad del proyecto. La tabla presenta la fecha de

creación, la descripción, el usuario creador y el resultado de cada una de

las evaluaciones. Si la evaluación ha sido completada se muestra en la

tabla el resultado final en forma gráfica y numérica. Sin evaluación no ha

sido completada todavía se muestran la tabla el texto “Incompleto”. En el

caso de que un usuario visitante acceda a un proyecto del cual no es

miembro (ni líder ni colaborador) el sistema no mostrara el resultado de

ninguna evaluación.

7.1. Agregar colaborador al proyecto

El líder del proyecto puede agregar un colaborador al mismo, completando el

formulario “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 como

colaborador del proyecto.

7.2. Eliminar un colaborador

El líder de un proyecto puede eliminar a cualquier colaborador que haya

agregado previamente. Para esto debe hacer clic en el icono que se encuentra al

lado del e-mail de cada colaborador. El sistema le pedirá una confirmación y, si el

líder del proyecto contesta afirmativamente, el colaborador será eliminado de ese

proyecto, convirtiéndose en visitante.

7.3. Crear una nueva evaluación

El líder del proyecto y los usuarios colaboradores pueden crear una nueva

evaluación de viabilidad para el proyecto, completando el formulario “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 el

proyecto y le muestra al usuario la pantalla de ejecución de la evaluación.

7.4. Imprimir la gestión del proyecto

Para imprimir la información de gestión del proyecto el usuario debe hacer clic en

el botón “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 de

impresión del navegador web.

7.5. Exportar la gestión del proyecto

Para exportar la información de gestión del proyecto a un archivo separado por

comas (.csv) el usuario debe hacer clic en el botón “Exportar” que se encuentra en

el borde superior derecho de la pantalla.

El sistema generará un archivo .csv que el usuario podrá descargar y visualizar en

cualquier planilla de cálculo o editor de texto.

8. Ejecución de evaluaciones

Hasta el momento se ha presentado la forma de crear proyectos, agregar

colaboradores al mismo y crear evaluaciones. En este ítem se mostrará la forma de

ejecutar las evaluaciones a través de un cuestionario guiado.

Una vez que un miembro del proyecto cree una nueva evaluación, el sistema

DAMVE presenta la pantalla de ejecución de la evaluación. La Figura A2.8

presenta dicha pantalla:

Figura A2.8. Pantalla de ejecución de la evaluación

La ejecución de una evaluación de viabilidad es simple:

1. El sistema le presenta al usuario una pregunta relacionada a un aspecto

particular de la metodología P3TQ.

2. El usuario debe responderla en relación a la información con la que cuenta

del proyecto que está evaluando. Para esto puede utilizar el mouse para

elegir la opción que considere correcta y hacer clic en el botón siguiente.




Alternativamente, para hacer más dinámica la interacción, el usuario

puede seleccionar la opción correcta con las flechas del cursor y presionar

la tecla ENTER.

3. El sistema procesará la respuesta del usuario y le presentará la próxima

pregunta. Además, en la sección "preguntas respondidas" el sistema

muestra todas las preguntas que el usuario ha respondido.

4. A llegar a la última pregunta el sistema siendo capaz de calcular la

viabilidad del proyecto en base a las respuestas del usuario, le presenta la

pantalla de resultado de la evaluación.

8.1. Abandonar y Retomar evaluaciones

No es necesario que el usuario complete una evaluación en una única sesión,

pudiendo abandonar la ejecución de una evaluación en cualquier momento.

Para retomar una evaluación incompleta, el usuario miembro del proyecto debe

seleccionar el proyecto en la pantalla de selección de proyectos y, en la pantalla de

gestión del proyecto buscar en la tabla de evaluaciones, que se presenta en la

Figura A2.9, la evaluación que ha dejado incompleta.

Figura A2.9. Retomar una evaluación incompleta

Una vez hecho esto debe hacer clic en el icono , que le permitirá volver a la

pantalla de ejecución de la evaluación, retomando el cuestionario desde dónde lo

abandonó.

9. Resultado de las evaluaciones

Una vez que se ha completado el cuestionario de evaluación el sistema le presenta

al usuario de resultado obtenido. La Figura A2.10 muestra un ejemplo de

resultado de evaluación:




Figura A2.10. Pantalla de resultado de una evaluación

El sistema muestra los siguientes resultados:

� Dimensión just if icació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 lidad : presenta el vector adaptabilidad y, en forma


� Dimensión Plausibi lidad : presenta el vector plausibilidad y, en forma


� 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 lidad : presenta el vector viabilidad, que es un promedio de las cuatro

dimensiones anteriores y, en forma gráfica, el módulo de este vector que

sintetiza el resultado final de la evaluación.

� Si el resultado del cálculo del módulo de un vector es menor a seis, se

considera insuficiente y se presenta el resultado gráfico en color rojo. Por

el contrario si el módulo es mayor a seis se lo considera aceptable y se

presenta el resultado gráfico en color verde.

� Al igual que la pantalla de ejecución de una evaluación del sistema

presenta en la sección "preguntas respondidas" todas las preguntas que el

usuario ha respondido, permitiendo contar con trazabilidad de la

evaluación.

9.1. Imprimir los resultados

Para imprimir los resultados de la evaluación de un proyecto el usuario debe

hacer clic en el botón “Imprimir” es encuentra en el borde superior derecho de la

pantalla.




El sistema preparará una versión adaptada para impresión del resultado que

facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo de

impresión del navegador web.

9.2. Exportar los resultados

Para exportar los resultados de la evaluación a un archivo separado por comas

(.csv) el usuario debe hacer clic en el botón “Exportar” que se encuentra en el

borde superior derecho de la pantalla.

El sistema generará un archivo .csv que el usuario podrá descargar y visualizar en

cualquier planilla de cálculo o editor de texto.

9.3. Consultar resultados de evaluaciones realizadas

Para poder consultar los resultados de una evaluación realizada cualquier

miembro del proyecto (líder o colaborador) debe hacer clic en el resultado final de

la evaluación que se encuentra en la sección "Evaluaciones" de la pantalla de

gestión del proyecto. La Figura A2.11 muestra un ejemplo de dicha pantalla:

Figura A2.11. Consultar resultados de evaluaciones realizadas

10. Opciones Avanzadas

Las opciones presentadas a continuación pueden ser llevadas a cabo por usuarios

con mayor jerarquía en el sistema, debido a los roles que poseen.

10.1. Designar evaluadores

El administrador del sistema puede designar usuarios evaluadores, que son

capaces de modificar la plantilla de evaluación.

Para realizar esta tarea el administrador debe hacer clic en la opción

“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 como

evaluador.

10.2. Eliminar un evaluador

El administrador puede eliminar a cualquier evaluador que haya sido designado

previamente. Para esto debe hacer clic en el icono que se encuentra al lado del

e-mail de cada evaluador, en la pantalla evaluadores. El sistema le pedirá una

confirmación y, si el administrador contesta afirmativamente, el evaluador será

eliminado del sistema.

10.3. Editar la plantilla de evaluación

Los usuarios con el rol de evaluadores pueden editar la plantilla de evaluación.

Para realizar esta tarea deben hacer clic en la opción "Cuestionario" del menú. A

continuación se presenta en la Figura A2.13 la pantalla de edición de la plantilla

de evaluación.

Figura A2.13. Formulario para editar la plantilla de evaluación




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 usuario

evaluador pueda navegar el cuestionario. Para esto el usuario evaluador

debe hacer clic en el número de la próxima pregunta y el sistema lo

llevara hasta el formulario de dicha pregunta.

El usar evaluador puede, entonces, modificar cualesquiera de los parámetros del

formulario y, haciendo clic en el botón “Actualizar” el sistema guardará los

cambios en la plantilla de evaluación.

10.3.1. Preservación de los resultados

Cuando una pregunta de la plantilla de evaluación es modificada, todas las

evaluaciones de viabilidad de cualquier proyecto utilizarán los nuevos

parámetros de dicha pregunta. Las evaluaciones que ya hayan respondido

previamente la pregunta conservarán el valor anterior en el resultado. De esta

manera se preservan los resultados de viabilidad anteriores a la modificación de

la plantilla de evaluación.

10.3.2. Preservación de la secuencia

El sistema DAMVE, no permite que se altere la secuencia de las preguntas, debido

a que siguen, de manera estricta la metodología P3TQ. Sin embargo, resulta muy

útil para un líder de proyecto de explotación de información con experiencia la

posibilidad de modificar los parámetros de la pregunta para adecuar la

evaluación de debilidad a su entorno de trabajo.

10.4. Inicializar la Base de Datos

El administrador del sistema puede reiniciar la base de datos, haciendo clic en la

opción “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 destruye

todos los datos que existan en la base de datos y lleva al Sistema DAMVE a su

estado 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 es

eliminada y el sistema queda reinicializado.

Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la ...

Documents

Transcript of Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la ...