Herramienta de Estudio de Viabilidad para Proyectos Que Utilizan La Metodología P TQ

HERRAMIENTA DE ESTUDIO DE
VIABILIDAD PARA PROYECTOS QUE

UTILIZAN LA METODOLOGA P3TQ
TRABAJO PROFESIONAL EN INGENIERA EN

INFORMTICA
Laboratorio de Sistemas Inteligentes

Facultad de Ingeniera
Universidad de Buenos Aires
Alumnos:
Pablo Damin MENDEZ

Alejandro Daniel RODRIGUEZ
Directores:
Prof. Dr. Ramn GARCIA-MARTINEZ

Prof. Dra. Paola BRITOS
Mayo 2009
FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodologa P3TQ
Directores
Alumnos
Prof. Dr. Ramn GARCA-MARTNEZ
Pablo Damin MNDEZ
Alejandro Daniel RODRGUEZ
ndice
Memoria del Trabajo Profesional.................................................................... 1
1.
2.
Resumen ........................................................................................................................... 2
Introduccin ..................................................................................................................... 2
2.1.
2.2.
2.3.
2.4.
3.
La metodologa SEMMA ................................................................................................................ 3

La metodologa CRISP-DM ............................................................................................................ 4
La metodologa P3TQ...................................................................................................................... 5
Comparacin de las metodologas P3TQ, SEMMA y Crisp-DM................................................... 7
Estudio de viabilidad....................................................................................................... 9
3.1.
El mtodo ........................................................................................................................................ 9
3.2.
Viabilidad en P3TQ ....................................................................................................................... 11
Modelo para predecir:............................................................................................................................... 17
4.
5.
6.
Conclusiones .................................................................................................................. 22
Futuras mejoras.............................................................................................................. 23
Bibliografa ..................................................................................................................... 23
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE ............. 24

1.
2.
Objetivo .......................................................................................................................... 25
Funcionalidad del Sistema ............................................................................................ 26
2.1.
2.2.
3.
Cambios en la versin ................................................................................................... 27

3.1.
3.2.
3.3.
3.4.
4.
La arquitectura Appengine .......................................................................................................... 58
Diseo de la aplicacin.................................................................................................. 60
7.1.
7.2.
7.3.
7.4.
7.5.
7.6.
7.7.
8.
Diagrama de Casos de Uso........................................................................................................... 44

Matriz de trazabilidad Casos de Uso Requerimientos Funcionales ........................................ 45
Realizacin de los Casos de Uso .................................................................................................. 46
Arquitectura del Sistema............................................................................................... 58

6.1.
7.
Formato ......................................................................................................................................... 27
Requerimientos funcionales ......................................................................................................... 28
Requerimientos no funcionales .................................................................................................... 36
Restricciones ................................................................................................................................. 43
Modelo de anlisis ......................................................................................................... 44

5.1.
5.2.
5.3.
6.
Versin 4 ....................................................................................................................................... 27
Versin 3 ....................................................................................................................................... 27
Versin 2 ....................................................................................................................................... 27
Versin 1 ....................................................................................................................................... 27
Especificacin de Requerimientos ................................................................................ 27

4.1.
4.2.
4.3.
4.4.
5.
Evaluacin de proyectos............................................................................................................... 26
Gestin de usuarios ...................................................................................................................... 26
Diagrama de Paquetes de clases .................................................................................................. 60

dbmodel. La capa De dominio ..................................................................................................... 62
View. Paquete de soporte para vista............................................................................................ 67
Paquetes de Controladores.......................................................................................................... 68
Diagramas de Secuencia ............................................................................................................... 74
Secuencia entre Pantallas ............................................................................................................. 77
Diagrama de Despliegue .............................................................................................................. 82
Casos de Prueba ............................................................................................................. 84

8.1.
8.2.
Validar Usuario............................................................................................................................. 84
Asignar evaluador ........................................................................................................................ 85

Directores
Alumnos
Pablo Damin MNDEZ
8.3.
8.4.
8.5.
8.6.
8.7.
8.8.
8.9.
8.10.
9.
10.
Actualizar planilla de evaluacin ................................................................................................ 87

Evaluar viabilidad ........................................................................................................................ 88
Crear evaluacin ......................................................................................................................... 100
Consultar proyecto ..................................................................................................................... 101
Consultar Evaluacin ................................................................................................................. 102
Crear Proyecto ............................................................................................................................ 103
Asignar colaborador ................................................................................................................... 104
Inicializar cuestionario ............................................................................................................... 106
Conclusin.................................................................................................................... 108
Posibles mejoras........................................................................................................... 109
Anexo 2. Manual de usuario la Herramienta DAMVE............................. 110

1.
2.
3.
4.
5.
Introduccin ................................................................................................................. 111

Requisitos ..................................................................................................................... 111
Acceso al sistema ......................................................................................................... 111
Presentacin de la interfaz .......................................................................................... 112
Creacin y Seleccin de Proyectos.............................................................................. 113
5.1.
5.2.
6.
7.
Roles de los usuarios ................................................................................................... 114

Gestin de un Proyecto ............................................................................................... 115
7.1.
7.2.
7.3.
7.4.
7.5.
8.
Abandonar y Retomar evaluaciones .......................................................................................... 119
Resultado de las evaluaciones .................................................................................... 119

9.1.
9.2.
9.3.
10.
Agregar colaborador al proyecto ............................................................................................... 116

Eliminar un colaborador............................................................................................................. 117
Crear una nueva evaluacin....................................................................................................... 117
Imprimir la gestin del proyecto ............................................................................................... 117
Exportar la gestin del proyecto ................................................................................................ 118
Ejecucin de evaluaciones........................................................................................... 118

8.1.
9.
Creacin de un proyecto nuevo ................................................................................................. 113

Seleccin de un proyecto existente ............................................................................................ 114
Imprimir los resultados .............................................................................................................. 120

Exportar los resultados............................................................................................................... 121
Consultar resultados de evaluaciones realizadas...................................................................... 121
Opciones Avanzadas ................................................................................................... 121

10.1.
10.2.
10.3.
10.4.
Designar evaluadores ................................................................................................................. 121

Eliminar un evaluador................................................................................................................ 122
Editar la plantilla de evaluacin ................................................................................................ 122
Inicializar la Base de Datos ........................................................................................................ 123

Directores
Alumnos
Pablo Damin MNDEZ
Memoria del Trabajo Profesional
Pg. 1

Directores
Alumnos
Pablo Damin MNDEZ
1.
Resumen
Los actuales proyectos de explotacin requieren el anlisis y
ejecucin de etapas para ser llevados a cabo con xito. Cada una de
estas etapas insume tiempo y recursos, lo que hace sumamente
importante estudiar la viabilidad del proyecto para evaluar si
resulta posible y conveniente llevarlo a cabo y, adems, controlar
cada etapa de ejecucin para detectar y corregir desvos y, de esta
manera, asegurar su xito.
El proyecto en cuestin se enfoca en una metodologa para la
realizacin de proyectos de explotacin de la informacin (Data
mining)
y propone un test de viabilidad acorde a dicha
metodologa.
2.
Introduccin
La Explotacin de Informacin se centra en la bsqueda de patrones interesantes

en grandes bases de datos.
Utiliza tanto tcnicas estadsticas (Anlisis de varianza, Regresin, Prueba chicuadrado, Anlisis de agrupamiento o clustering, Anlisis discriminante, Series
de tiempo, etc.) como informticas (Algoritmos genticos, Inteligencia Artificial,
Sistemas Expertos, Redes neuronales, etc.)
Entre muchos otros ejemplos, la Explotacin de Informacin ha contribuido
significativamente en:
Las aplicaciones de administracin empresarial basada en la relacin con el
cliente.
Detectar patrones de fuga y fraudes.
Analizar el comportamiento de las personas que interactan en un sistema

(por ejemplo Internet)
Existen en el mercado actual tres importantes metodologas para llevar a cabo

proyectos de explotacin de la informacin, a saber:
SEMMA
CRISP-DM
Pg. 2

Directores
Alumnos
Pablo Damin MNDEZ
P3TQ
Sin importar la metodologa usada, no existe hasta el da de hoy, ningn mtodo

de clculo de viabilidad para proyectos de explotacin de la informacin. En este
trabajo, se estudia la metodologa P3TQ en particular para especificar un mtodo
plausible para el clculo de viabilidad de proyectos de las caractersticas
mencionadas.
2.1. La metodologa SEMMA

La primer metodologa fue propuesta por el SAS Institute, su nombre hace
referencia a las cinco fases que se consideran al utilizarla (Sample, Explore,
Modif., Model, Assess esto es Muestrear, Explorar, modificar, Modelar y Valorar
respectivamente) [SAS Institute 1998].
La figura 2.1.1 muestra la dinmica del mtodo SEMMA.
Figura 2.1.1. Metodologa SEMMA
Pg. 3

Directores
Alumnos
Pablo Damin MNDEZ
2.2. La metodologa CRISP-DM

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

Directores
Alumnos
Pablo Damin MNDEZ
2.3. La metodologa P3TQ

La metodologa de D. Pyle se divide en dos etapas, la primera denominada
Modelado de Negocio o MII, y la segunda llamada Minera de datos o MIII
[Pyle, D. 2003].
Inicio
MII
Modelado del Negocio
Metodologa de
Modelado (MII)
MIII
Preparacin de los Datos
(Boxes 9.x)
MIII
Minera sobre el modelo
(Boxes 11.x)
Metodologa de
Minera (MIII)
MIII
Refinamiento
(Boxes 12.x)
MIII
Despliegue
(Boxes 13.x)
Fin
Figura 2.3.1. Metodologa de D.Pyle, Etapas del proyecto de explotacin de informacin
Para comenzar la primera etapa Pyle propone cinco posibles puntos de partida en
funcin del propsito del proyecto de explotacin de la informacin que se quiere
evaluar. De esta manera Pyle considera:
1.
Explorar los datos en bsqueda de relaciones tiles.
2.
Dada una oportunidad o problema ver cmo puede la explotacin de la

informacin encausar a la organizacin hacia una decisin correcta.
3.
Simplemente ver qu puede lograr la explotacin de la informacin.
Pg. 5

Directores
Alumnos
Pablo Damin MNDEZ
4.
Utilizar la minera de datos para construir un modelo sobre una situacin

particular
5.
Dada una situacin estratgica, analizar si la minera de datos puede ser til
para explicar la situacin y cules son las opciones de la organizacin para
resolverla.
Figura 2.3.2. Metodologa de P 3 TQ, Puntos de partida de un proyecto y objetos a considerar
En la Figura 2.3.2 (parte central) se enumeran los parmetros concernientes a la

organizacin y la situacin del proyecto que la metodologa de P3TQ considera,
sin embargo estos son tratados de distinta manera segn el punto de partida, para
obtener finalmente los datos requeridos para el proyecto de explotacin y los
requerimientos reales de las partes interesadas.
Pg. 6

Directores
Alumnos
Pablo Damin MNDEZ
Finalizado el modelo de negocio el siguiente paso es la explotacin de datos, para

ello D. Pyle propone los pasos mostrados en la Figura 2.3.3.
Cada parte de la metodologa (tanto en MII como en MIII)
est desagregada en pasos, estos pasos son denominados
Preparacin de los
datos
boxes, existiendo 3 tipos de ellos:
Action Boxes, en donde se decide cul es el
Seleccin de la
herramienta
prximo paso a realizar.

Discovery Boxes, en donde se analizan los

posibles resultados y problemas luego de ejecutar
un Action Box.
Minera
Technique Boxes, que describen minuciosamente

cmo debe emplearse una tcnica.
Refinamiento
Los boxes no se recorren secuencialmente, los saltos entre

ellos dependen de las situaciones que se van dando a
medida que se avanza en el proyecto.
Despliegue
Figura 2.3.3. Pasos distinguidos en la metodologa P 3 TQ
Los boxes explican detalladamente los conceptos y/o acciones que se realizan. El
grfico mostrado anteriormente permite identificar cules son los Boxes que
corresponden a cada etapa de la metodologa. Por ejemplo puede verse en la
figura 2.3.1 que los Boxes 9.x corresponden a la etapa de preparacin de los datos
en la metodologa de minera MIII.
2.4. Comparacin de las metodologas P3TQ, SEMMA y

Crisp-DM
Luego de las investigaciones iniciales, hemos concluido que SEMMA se centra en
los aspectos tcnicos de los proyectos de explotacin de datos. Adems est
acotada ya que ha sido diseada para ser implementada con los productos SAS.
Crisp-DM es ms completa y abierta que SEMMA, pero no llega al detalle de la
metodologa P3TQ, ya que nombra etapas del proceso de la explotacin de la
informacin, pero no se analizan los pasos, resultados y situaciones que se pueden
dar dentro de cada etapa.
Pg. 7

Directores
Alumnos
Pablo Damin MNDEZ
Concluimos que la metodologa P3TQ es la ms completa entre las tres

mencionadas (Ver cuadro 2.4.1), y, por lo tanto en la que se centrar el presente
trabajo. Dicha metodologa analiza muchas ms variables y ms profundamente
que las dems. Para citar un simple y claro ejemplo (considerando que nos
encontramos slo en la introduccin de la presentacin de un proyecto y no en su
desarrollo) la metodologa considera quines son los interesados en el proyecto en
la organizacin, considerando hasta la causa de su inters (Pyle, D. Business
Modeling and Data Mining, Technique Box 1: Identify Stakeholders).
Permite eleccin totalmente libre de

herramientas
Cantidad de fases
Todas las fases pueden relacionarse
Considera motivo del proyecto
Considera naturaleza del inters de las partes
Considera otros aspectos no tcnicos
Identifica claramente las variables sobre las que el
proyecto tiene impacto
Est detallada paso a paso cada etapa del mtodo
SEMMA
CRISPDM
NO
5
NO
NO
NO
NO
SI
6
SI
NO
NO
SI
NO
NO
NO
NO
PYLE
SI
5 (1 MII y 4 MIII)
SI
SI
SI
SI
SI (Product, Place, Price,
Time, Quantity)
SI
Cuadro 2.4.1. Cuadro comparativo de metodologas
Pg. 8

Directores
Alumnos
Pablo Damin MNDEZ
3. Estudio de viabilidad
Todo proyecto en el mbito de cualquier rama de la ingeniera debe satisfacer la
ecuacin fundamental de costo y beneficio.
Antes de comenzar con un proyecto, por lo tanto, tres puntos deben tenerse en
cuenta:
El esfuerzo necesario para el desarrollo (Costo)
La utilidad que se obtendr por realizar dicho desarrollo.
Tambin a veces, por razones inherentes a la naturaleza de un proyecto

surge una tercera cuestin que es si es realizable en funcin de las variables
que lo definen.
Estas tres cuestiones no slo pueden indicar si se debe comenzar o no una

inversin econmica para obtener un resultado, sino que adems, puede variar a
medida que se va avanzando en la empresa y nuevos problemas van surgiendo.
El estudio de viabilidad, considerando los puntos que D. Pyle menciona en la
bibliografa, aproxima a un valor que nos da la respuesta sobre si es conveniente
que un proyecto se ejecute, o siga ejecutndose. Estas caractersticas corresponden
en mayor medida al segundo y tercer punto.
En comparacin a cualquier otro tipo de proyecto de naturaleza informtica, toma
mayor importancia realizar estudios de viabilidad cuando se trata de actividades
de explotacin de la informacin. La razn de esta afirmacin, radica en que es
comn notar en el cliente un inters incierto, o ms bien, mucho inters, pero sin
conocer exactamente qu espera de un proyecto de explotacin de la informacin.
3.1. El mtodo
La metodologa mencionada en [Garca-Martnez, R. y Britos, P. (2004).

Sistemas Expertos. Nueva Librera] clasifica tres tipos distintos de
caractersticas que definen la viabilidad de un problema, a saber:
Booleanos
Numricos en un intervalo finito
Lingsticos (Conjunto que posee los valores nada, poco, regular,

mucho, todo).
Pg. 9

Directores
Alumnos
Pablo Damin MNDEZ
Segn los valores de cada caracterstica del problema se estima si el proyecto es

viable o no. Adems cada caracterstica estar ponderada por un peso, que har
que incida en mayor o menor medida en la dimensin de un problema.
En casos de valores lingsticos son convertidos en valores difusos
correspondiente en el intervalo [0,10] como se muestra en la tabla 3.1.1.
Nada
1,2 2,2
Poco
1,2 2,2 3,4 4,4
Regular 3,4 4,4 5,6 6,6

Mucho
5,6 6,6 7,8 8,8
Todo
7,8 8,8 10
10
Tabla 3.1.1 Conversin entre valores lingsticos y valores difusos
Para homogeneizar el problema, los valores booleanos tambin se tratan como

lingsticos considerando los valores de la tabla 3.1.2.
No
10
10
10
10
Tabla 3.1.2 Conversin entre valores booleanos y valores difusos
Las caractersticas se agruparn segn su naturaleza y llamaremos a cada grupo

Dimensin, existiendo cuatro dimensiones a saber: Plausibilidad, xito,
Adecuacin y Justificacin.
La dimensin Plausibilidad agrupar todas aquellas caractersticas que indican
si el desarrollo del proyecto es posible, por ejemplo si existen expertos y estn
disponibles, si existen los casos de prueba adecuados, etc. El xito es
determinado por caractersticas del problema que generalmente se dan a
posteriori del desarrollo, de todas maneras debemos identificar y evaluar estas
caractersticas a priori, para ejemplificar podemos mencionar el inters o
desinters de un departamento clave de la organizacin, que no sea el sponsor
pero si el usuario final (el proyecto sera desarrollado pero nunca utilizado o los
usuarios seran reacios, esto sera un fracaso).
La dimensin de Justificacin contendr cada caracterstica que determine si
vale la pena realizar el proyecto. Supongamos el caso que se dispone de
suficientes expertos en la materia y no representan costo significativo para la
empresa, en este caso seguramente no ser justificado el desarrollo.
Pg. 10

Directores
Alumnos
Pablo Damin MNDEZ
La dimensin de adecuacin, evala si es apropiado resolver el problema

mediante el sistema propuesto en este trabajo.
Finalmente el clculo del valor de cada dimensin se realiza de la siguiente
manera. Dado L el vector de valor lingstico de dimensin 4 (de acuerdo a las
tablas 3.1.1 y 3.1.2), Li y Pi el valor difuso y el peso de la caracterstica i
respectivamente; la viabilidad de una dimensin j determinada del problema ser
determinada por la ecuacin 3.1.1.
Ecuacin 3.1.1. Clculo de viabilidad de una dimensin.
Esta frmula representa la viabilidad para una dimensin j dada. Luego de

calcular para las 4 dimensiones (Adecuacin, xito, justificacin y plausibilidad),
se calcula la viabilidad total de un problema segn la frmula 3.1.2.
Ecuacin 3.1.2 Viabilidad total
Pj es el peso de cada dimensin, siguiendo la bibliografa propuesta se define que

ser:
Plausibilidad y adecuacin 8
Justificacin 3
xito 5
3.2. Viabilidad en P3TQ

Todo proyecto de Explotacin de la informacin, tiene como propsito el uso de
herramientas sobre datos existentes para obtener relaciones interesantes a la hora
de tomar decisiones o crear soluciones.
Una caracterstica de los trabajos de explotacin de datos actuales, es que el punto
de partida, o ms bien el motivo de su realizacin, no sea un problema en
particular a solucionar. Muchos interesados en aplicar explotacin de la
Pg. 11

Directores
Alumnos
Pablo Damin MNDEZ
informacin tienen como objetivo descubrir qu problemas se pueden solucionar

con la informacin existente, pero no la solucin de un problema en s.
Esta caracterstica, incrementa la necesidad del estudio de viabilidad; ya que al
comenzar con un rumbo incierto, es probable terminar en una solucin no
deseada luego de haber invertido tiempo de personal calificado y recursos
econmicos.
Naturalmente no es apropiado este tipo de perspectiva para ningn tipo de
proyectos, a pesar que la realidad en la prctica indique que muchos comienzan
de esta manera porque el sponsor lo requiere.
Como se describi en la seccin 2.3, la metodologa propuesta por D. Pyle,
establece dos partes de un proyecto de minera de datos, el Modelado de Negocio
y la Metodologa de Minera. Por esta razn analizaremos la viabilidad tomando
caractersticas de estas dos partes por separado.
3.2.1. Estudio de viabilidad en el modelado de negocio

Tomando como punto de partida que nada puede ofrecer un proyecto de
explotacin de datos hasta que el problema a resolver sea identificado, esto debe
lograrse de alguna manera, aunque el cliente no lo haya especificado.
Pyle reconoce, por lo tanto, los siguientes puntos de partida de un proyecto segn
su objetivo:

Explorar los datos y descubrir relaciones interesantes que

ofrezcan valor agregado al negocio.
Un problema u oportunidad de negocio en particular a ser
explorado.
Descubrir en qu partes de la organizacin puede ser
interesante aplicar mtodos de explotacin de la
informacin.
Crear un modelo para un propsito especificado.
Planificar escenarios corporativos.
Segn el punto de partida inicial, D. Pyle establece cules son los siguientes pasos
a seguir.
Por ejemplo el caso ms general, con escasa informacin sobre el negocio, slo
llega el conjunto de datos sobre el cual se debe aplicar minera para descubrir
relaciones que puedan llegar a ser de inters. En este punto, Pyle, establece
Pg. 12

Directores
Alumnos
Pablo Damin MNDEZ
especficamente el aso ms lgico a seguir: reconocer a los interesados segn cinco

categoras:
1. Los que necesitan la realizacin del proyecto.
2. Los que poseen los recursos econmicos.
3. Los que poseen poder de decisin para que el proyecto avance.
4. Los que se benefician con el resultado.
Luego se procedera con una entrevista a los interesados, en donde se debe
entender cul es la parte relevante de negocio que, justamente, les interesa y
discutir con ellos para identificar cul es el proyecto original que alimenta la
necesidad de un proyecto de minera.
Siguiendo este ejemplo, es nuestro estudio de viabilidad, analiza si:
Las partes interesadas estn identificadas.
Las partes interesadas tienen disponibilidad de tiempo para avocarse al
proyecto.
Existen partes interesadas con recursos suficientes.
Las caractersticas importantes para las partes interesadas estn identificadas.
La parte clave de estos pasos es descubrir y caracterizar cul, cmo y cunto de
los componentes P3TQ (Product, Price, Place, Time, Quantity) son afectados por
el proyecto, qu hay que cambiar para ver la oportunidad o resolver el problema
de trasfondo.
Las cinco variables de negocio que dan nombre a esta metodologa, interactan
mutuamente (figura 3.2.1.1). Por ejemplo, el xito del lanzamiento de un producto
depende, obviamente del cliente, pero las caractersticas de ellos, dependen del
tiempo y el lugar.
Figura 3.2.1.1 Variables P 3 TQ
Estas relaciones deben ser reveladas en los datos con las herramientas usadas para
la minera de datos.
Pg. 13

Directores
Alumnos
Pablo Damin MNDEZ
El siguiente paso tiene que ver con los interesados, es notar quin o qu
departamento origin el proyecto original y qu esperan a cambio.
Hasta aqu, se ha analizado slo un punto de partida de modelado de negocio
identificado por D. Pyle, notemos cules son las situaciones que se tienen luego de
analizar esta pequea fraccin de la metodologa:

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

El proyecto original perdi el apoyo de uno o algunos de los interesados.
EL proyecto original fall en entregar los resultados esperados.
Los datos fueron recolectados para dirigir una situacin especfica, pero el
objetivo de la minera sera descubrir si hay algn valor corporativo que se
pueda obtener de ellos.
Segn la situacin, el nivel de riesgo es distinto. Adems, Pyle especifica una

accin para resolver el problema en cada una de estos escenarios. Es objetivo de
este trabajo tambin, analizar estas acciones, descubrir acciones implcitas, y
determinar el riesgo de realizarlas.
El software de Anlisis de viabilidad, ubica al usuario en la situacin de la
metodologa de explotacin de datos propuesta por D. Pyle realizando ciertas
preguntas.
Adaptando la metodologa de D. Pyle al mtodo de clculo de viabilidad (seccin
3.1), se identifica primero a qu dimensin pertenece cada una y se le asigna un
peso, determinando en conjunto la viabilidad del proyecto.
En la tabla 3.2.1.1, se muestran los tems que establecen los puntos de riesgo para
el modelado de negocio. El software de clculo de viabilidad es extendible en este
sentido, los puntos mostrados en la tabla son los correspondientes a la versin 1.0
del software. La primer columna indica la dimensin de viabilidad a la cul
apunta la pregunta (P: Plausibilidad; A: Adecuacin; E: xito; J: justificacin). La
segunda columna indica el Pyle Box (ver seccin 2.3) fuente de la pregunta, que
es la caja que enumera de alguna manera el factor de riesgo que se identific
para generar la pregunta en cuestin.
3.2.2. Estudio de viabilidad en la metodologa de minera de datos

El desarrollo de modelos aptos para la minera requiere anlisis, interpretacin y
cambios sobre los datos de manera cclica. Las acciones a tomar dependen
enteramente del problema de negocio y de lo que el experto en minera descubre
en ellos.
Pg. 14

Directores
Alumnos
Pablo Damin MNDEZ
Por esta razn debe ser posible realizar tests de viabilidad no slo antes de
comenzar la minera, sino tambin a lo largo del desarrollo del proyecto.
La metodologa P3TQ, comienza el proceso de minera con la preparacin de los
datos.
Se debe tener en cuenta que el esfuerzo del experto es enfocado en mayor medida
a esta tarea. Es de esperar que la relacin sea entre el 60 y 90% del esfuerzo total
avocado a la minera.
Esto, apunta a que el test de viabilidad para la minera de datos est enfocado en
gran parte hacia el estado de los conjuntos de variables y, por ejemplo, si no
existen errores, si dichas variables y sus valores son congruentes con el modelo de
negocio o si son suficientes, adems si poseen muchos valores indefinidos, etc.
Las cuestiones mencionadas se reflejan en las preguntas que el sistema de clculo
de viabilidad muestra al usuario (tabla 3.2.2.1).
Pyle establece los pasos a seguir para la preparacin de los datos en los boxes 9.x.
El siguiente punto ms relevante, luego de la preparacin de los datos, es la
minera en s, refirindonos a los algoritmos utilizados, los conjuntos de variables
de entrada y salida, etc. Estos casos son apuntados por los boxes 11.x.
El test de viabilidad en la minera propuesto en este trabajo tiene una bifurcacin
segn los tres tipos de proyectos de explotacin que Pyle identifica:
Minera para entender.
Minera para clasificar.
Minera para predecir.
Minera para entender:
Cuando la cuestin que motiva el proyecto es entender el por qu de una
situacin del negocio en particular, el set de datos limita la respuesta que el
encargado de la explotacin de la informacin puede otorgar.
Si es posible, la transformacin de variables es normalmente de gran ayuda para
la comprensin de los resultados y puede hacer ms rico un modelo. Tomemos
como ejemplo de transformacin, establecimientos de una empresa dedicada a la
logstica georeferenciados, o sea, puntos en particular con latitud y longitud
establecida. Es probable que dada la situacin a entender, no sea de relevancia
conocer estos parmetros, pero s la distancia a un punto en particular de cada
establecimiento. Naturalmente el minero debera encargarse de transformar las
variables de latitud y longitud a una variable con el valor de la distancia.
Con este sencillo ejemplo, se intenta demostrar algunos de los puntos que
determinan el riesgo previamente a comenzar a realizar la tarea de minera. Ya
Pg. 15

Directores
Alumnos
Pablo Damin MNDEZ
que, conociendo la cuestin que se debe explicar, el encargado de la explotacin

de la informacin debe analizar previamente: Pueden transformarse los datos de
manera que sean importantes para entender la situacin, y tiles para explicar el
resultado?, pueden las herramientas elegidas, transformar los datos de manera
conveniente?.
Adems de los puntos relativos a las variables en s, la explicacin de la situacin
(el resultado final del proyecto), contendr tanto implcita o explcitamente las
relaciones entre variables que conforman la parte del modelo concerniente a la
situacin particular analizada. Estas relaciones son coherentes?, existen
variables, donde comnmente se espera un par relacionado, sin estar
relacionadas?, estas cuestiones tambin hacen que el riesgo del proyecto aumente
o disminuya, son consideradas por este trabajo.
Otras cuestiones que influyen directamente en el riesgo de la minera son mucho
ms triviales, por ejemplo, si estn elegidas las herramientas y algoritmos para la
minera, si se cuenta con un proveedor de dichas herramientas, la capacidad de
respuesta en caso necesitar modificaciones.
Minera para clasificar:
Segn D. Pyle, la clasificacin es un caso especial de lo que comnmente se
denomina prediccin, debido a que se intenta predecir a qu clase una instancia
de dato pertenece en funcin a ciertos atributos. Se discute el trmino
prediccin en el siguiente punto (Minera para predecir).
Por ejemplo, un modelo para clasificar muy comn y utilizado muy a menudo
pedaggicamente es aquel que en funcin de ciertos atributos de una persona,
sta accedera a un crdito otorgado por un banco o no. Estos atributos pueden ser
sexo, edad, nivel de estudio, estado civil, regin donde vive, etc. El modelo de
clasificacin producir algn tipo de puntuacin en funcin de esos atributos que
determine si la persona accede o no al crdito.
Sin embargo, ocurre en ciertos casos que la puntuacin producida por la
herramienta de minera no es fcil de interpretar. Supongamos que para el caso en
cuestin el modelo establezca un resultado booleano de tipo 0= No accede al
crdito, 1 = Accede al crdito. Es probable que luego de la minera, la herramienta
utilizada calcule un valor entre 1 y 0. Estos casos requieren que el responsable de
la explotacin haga una interpretacin y que tenga los medios necesarios para
ello.
Otra cuestin, es que se necesitan varios conjuntos de datos para aplicar la
herramienta. Esto se debe a que si se usa un solo conjunto, el modelo interpretar
Pg. 16

Directores
Alumnos
Pablo Damin MNDEZ
que las proporciones de cada clase son universales. Siguiendo el ejemplo, si se

otorga un conjunto donde un 30% acceden al crdito y un 70% no, el modelo
interpretar que un 30% de los casos acceden al crdito universalmente.
Las cuestiones de los prrafos anteriores, influyen directamente en la viabilidad
de un proyecto de minera para clasificar ya que, deben ser elegidas
cuidadosamente las herramientas, saber si se podrn interpretar los datos, o
estarn disponibles aquellas personas que puedan interpretarlos. Obviamente, con
respecto a las proporciones de las clases, la viabilidad estar influida por la
cantidad de conjuntos de datos que se puedan generar. P3TQ especifica
minuciosamente los pasos a seguir para la minera de clasificacin, en cada uno de
ellos se pueden reconocer factores de riesgo que hemos incluido en el desarrollo
de este trabajo y se reflejan en la herramienta final.
Modelo para predecir:

Quizs el ms difcil de los tres objetivos que puede tener un proyecto de minera
es la prediccin.
Un modelo para predecir debe ser capaz de arrojar informacin que no est
presente en el set de datos que toma como entrada. Estos resultados salen de la
elaboracin de los datos junto con el conocimiento del negocio, por lo tanto, el
modelo debe ser lo suficientemente rico, y se debe poseer expertos en el caso de
negocio que puedan interpretar causas y efectos, con la dinmica de relaciones
que interconectan los objetos representados en los datos.
Los datos disponibles no contienen un patrn que describa cmo se comportar el
sistema de las circunstancias de inters ya que la combinacin nica de estas
circunstancias no ha sucedido an. Y en esta incertidumbre de comportamiento
subyace el trabajo que se le encomend al encargado de la explotacin de la
informacin.
Ya que no existen herramientas de minera para este propsito, el xito depender
en gran parte en la habilidad del experto para seleccionar herramientas existentes
y su habilidad para relacionar los resultados que vaya encontrando entre las
distintas situaciones del negocio, para lo cual necesitar la ayuda y disponibilidad
de expertos interesados en el proyecto.
3.2.3. El cuestionario de evaluacin

Cada paso de la metodologa posee acciones u objetos plausibles de riesgo. Un
experto puede generar riesgo por su ausencia, un conjunto de datos puede
generar riesgo por poseer demasiados valores nulos, etc.
Pg. 17

Directores
Alumnos
Pablo Damin MNDEZ
Presentado ya el mtodo de clculo de viabilidad, la metodologa sobre la cual se

apoyan los proyectos de explotacin de la informacin que consideramos,
analizaremos a continuacin cmo se presenta la metodologa propuesta al
usuario final.
El interesado en determinar el riesgo de un proyecto deber ir contestando un
cuestionario donde se presentan los posibles escenarios de riesgo para cada paso
de la metodologa P3TQ.
Como P3TQ no es secuencial, no sern tampoco las preguntas presentadas.
Segn lo que el usuario responda se le mostrarn un conjunto de preguntas u
otro.
Las preguntas de la tabla 3.2.3.1 estn divididas en aquellas que corresponden a la
etapa de modelado (Id de la 1 a la 27), las que corresponden a la etapa de minera
(27 a 49) y las que manejan la secuencia de la metodologa P3TQ (50 a 57). Notar
que todas excepto las del tercer grupo tienen un peso asignado y su dimensin
correspondiente en la tabla (P: plausibilidad, A: adaptabilidad, J: justificacin y E:
xito). El peso es la ponderacin que tendrn en su dimensin en el clculo de
viabilidad.
Las preguntas 50 a 57 tienen peso cero, ya que no evalan el proyecto, sino que
identifican una situacin particular y en funcin de sus respuestas se mostrar
una secuencia de preguntas o no.
Id
pregunta
Descripcin
Las partes interesadas estn identificadas? Las partes interesadas son aquellas personas o grupos de
1 personas que afectan o pueden ser afectadas por el proyecto.Boxes de referencia de la metodologa P3TQ:
DB1, AB2, AB3
Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de
2
referencia de la metodologa P3TQ: DB1, AB2, AB3
Peso Dimensin
8 P
8 P
Existen partes interesadas con autoridad suficiente dentro de la organizacin para liderar el proyecto de
explotacin? Boxes de referencia de la metodologa P3TQ: DB1, AB2, AB3
6 E
Existen partes interesadas con recursos econmicos suficientes para encarar el proyecto? Boxes de
6 P
50 El proyecto de explotacin tiene como propsito buscar relaciones de inters?

El proyecto original cuenta con el apoyo de la organizacin? Boxes de referencia de la metodologa P3TQ:
5
DB1, AB2, AB3
El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodologa
6 3
P TQ: DB1, AB2, AB3
Existe comunicacin con las partes interesadas del proyecto original? El proyecto original es aquel que
7 origina el proyecto de explotacin que se est evaluando.Boxes de referencia de la metodologa P3TQ:
DB1, AB2, AB3
8 Se cumplieron los objetivos del proyecto original?
El proyecto de explotacin tiene como propsito la evaluacin de una situacin de negocio? (anlisis de
51
problema u oportunidad)?
Con respecto a la problemtica del negocio del proyecto original: Se han encontrado datos de utilidad para
9 llevar a cabo la minera? El proyecto original es aquel que origina el proyecto de explotacin que se est
evaluando.Boxes de referencia de la metodologa P3TQ: AB6
Las partes interesadas han identificado o pueden identificar aquellas caractersticas del negocio
10 importantes, que enmarcan sus expectativas del proyecto de explotacin? Boxes de referencia de la
metodologa P3TQ: TB7
0 M
10 E
8 P
6 P
8 P
0 M
5 P
5 A
Pg. 18

Directores
Alumnos
Pablo Damin MNDEZ
Id
pregunta
11
12
52
13
14
15
Descripcin
Peso Dimensin
La situacin del negocio est enmarcada o puede enmarcarse en un modelo a partir de los datos
conocidos? Boxes de referencia de la metodologa P3TQ: AB6
Los Objetivos y Metas del negocio estn definidos o pueden definirse? Boxes de referencia de la
metodologa P3TQ: AB6, TB5
El proyecto de explotacin tiene como propsito descubrir en que partes de la organizacin se puede
agregar valor?
Estn identificadas por las partes interesadas las relaciones entre las cinco temticas clave del
negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodologa P3TQ: AB11,
TB3
Es conocida la relacin entre las cinco temticas claves del negocio (producto, lugar, precio, tiempo y
cantidad) y el proceso principal de la organizacin? Boxes de referencia de la metodologa P3TQ: AB11
Esta determinado o puede determinarse cuales de los 26 recursos de gestin (Consultar la tabla 7.2 de MII
de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodologa P3TQ:
AB11, MII Tabla 7.1
16 Existen datos disponibles para explotacin? Boxes de referencia de la metodologa P3TQ: AB11
17
Esta desarrollado, o es posible desarrollar un esquema de caso de negocio para cada oportunidad
significativa? Boxes de referencia de la metodologa P3TQ: AB11
53 Hay otro propsito especifico?
6 J
8 J
0 M
10 E
5 A
5 A
10 E
10 P
0 M
Los requerimientos fueron consensuados con las partes interesadas? Boxes de referencia de la
metodologa P3TQ: AB9
19
18
20 Existe informacin disponible para la explotacin? Boxes de referencia de la metodologa P3TQ: AB9
54 Se requiere inicialmente un anlisis estratgico para planificar escenarios corporativos?
10 E
6 J
10 E
0 M
21
2 A
22
Existe un mapa del escenario estratgico, consensuado con las partes interesadas. .Boxes de referencia de
la metodologa P3TQ: AB12
6 A
23
24
25
26
27
Estn identificadas por las partes interesadas las relaciones entre las cinco temticas clave del
negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodologa P3TQ: AB12
Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la
Existen o pueden realizarse simulaciones que permitan identificar ambigedades, incertezas,
discordancias? Boxes de referencia de la metodologa P3TQ: AB12
Estn caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la
Esta determinado o puede determinarse cuales de los 26 recursos de gestin (Consultar la tabla 7.2 de MII
de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodologa P3TQ:
AB12, MII Tabla 7.1
28 Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodologa P3TQ: DB9.1
El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la
29
metodologa P3TQ: DB9.1
Existen variables con nico valor, o valores vacios en sus instancias? Boxes de referencia de la metodologa
30 3
P TQ: DB9.2
3
31 Las variables categricas estn documentadas? Boxes de referencia de la metodologa P TQ: DB9.2
32
33
34
35
Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la
Son reconocidas y es posible adecuar variables anacrnicas? Boxes de referencia de la metodologa P3TQ:
DB9.4
Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre
distintos) y generar un set de entrenamiento y otro de testeo? Boxes de referencia de la metodologa
P3TQ: DB9.5, TB9.4
Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios ms
importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodologa P3TQ: DB9.6
Es necesario realizar recodificacin de variables para mejor comprensin del modelo? Boxes de referencia
de la metodologa P3TQ: DB9.7
Los conjuntos de variables de entrada y salida estn caracterizadas? Boxes de referencia de la metodologa
37 3
P TQ: AB11.1
36
8 A
8 A
8 A
8 E
4 A
8 P
8 P
-4 P
3 A
4 A
4 A
8 E
10 E
-4 A
6 A
Pg. 19

Directores
Alumnos
Pablo Damin MNDEZ
Id
pregunta
38
39
40
41
42
Descripcin
Los datos estn estructurados o pueden estructurarse para aplicarlos en la herramienta de minera
elegida? Boxes de referencia de la metodologa P3TQ: AB11.1
Estn seleccionados los algoritmos de minera adecuados al modelo? Boxes de referencia de la
metodologa P3TQ: AB11.3
Existe una herramienta de minera adecuada al modelo y esta disponible? Boxes de referencia de la
De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la
Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la
Peso Dimensin
6 A
8 A
8 A
8 P
5 P
55 El objetivo de la explotacin es entender una situacin?
0 M
Las variables utilizadas en el modelo estn relacionadas con conceptos que son conocidos por las partes
43
interesadas? Boxes de referencia de la metodologa P3TQ: AB11.1, DB11.5
8 E
Los objetos del negocio que representan las variables pueden ser utilizados por las partes interesadas, o
gerentes para realizar mejoras en el negocio. .Boxes de referencia de la metodologa P3TQ: AB11.1, DB11,5
Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodologa
45 3
P TQ: AB11.1 DB11.5
44
8 E
6 E
56 El objetivo de la explotacin es aplicar una clasificacin?
0 M
Esta determinado o puede determinarse en la herramienta el tipo de modelo de clasificacin inicial (B:
46
Binario; M : Clases Mltiples o C : Continuo)? Boxes de referencia de la metodologa P3TQ: DB11.6
6 E
La herramienta elegida soporta el tipo de entrada y el tipo de salida del modelo inicial de clasificacin?
Boxes de referencia de la metodologa P3TQ: DB11.6
8 E
47
57 El objetivo de la explotacin es buscar una prediccin?

Las herramientas de modelado del sistema estn seleccionadas? Boxes de referencia de la metodologa
48 3
P TQ: TB11.7
Es posible caracterizar las relaciones esenciales entre los conceptos del negocio en las herramientas de
49
prediccin? Boxes de referencia de la metodologa P3TQ: DB11.7
0 M
5 E
6 E
Tabla 3.2.3.1 Cuestionario de viabilidad
Pg. 20

Directores
Alumnos
Pablo Damin MNDEZ
La figura 3.2.3.1 muestra un grafo que muestra los posibles caminos a seguir en el
cuestionario.
Figura 3.2.3.1 Secuencia del cuestionario de viabilidad
Pg. 21

Directores
Alumnos
Pablo Damin MNDEZ
4.
Conclusiones
La metodologa P3TQ es muy rica y tiene como principal ventaja detallar cada
paso en funcin de los objetivos del proyecto y el estado de cada atributo que lo
define.
Esto nos ha permitido, reconocer en cada paso aquellas cuestiones que hace
riesgoso o fcilmente viable a un proyecto de explotacin de la informacin.
Al mismo tiempo reconocemos los distintos tipos dificultades que pueden
acarrear un proyecto de explotacin de la informacin. Estas dificultades pueden
ser de distinta naturaleza. Se pueden mencionar dificultades de origen tcnico,
como la disponibilidad de datos suficientes, la existencia de herramientas
adecuadas para el tipo de proyecto que se quiere llevar a cabo, etc. Pero tambin
hay dificultades de otra naturaleza, que no son tan triviales e influyen con gran
impacto en el xito de un proyecto; identificar los interesados, sus expectativas,
detectar si conocen con precisin las variables del negocio y la relacin entre ellas,
su impacto en los resultados.
Todas estas cuestiones deben ser convenientemente analizadas antes de comenzar
a utilizar recursos en explotacin de informacin; para conocer la situacin de
partida del proyecto y qu se pretende como resultado, la importancia de las
personas en la organizacin que quieren ese resultado, cmo se va a presentar
dicha informacin, etc.
Como agregado, no existe hasta el momento un metodologa para calcular la
viabilidad de proyectos de este tipo, creamos en este trabajo una metodologa con
dicho propsito basndonos en el clculo de viabilidad propuesto por [Liebowitz
1986; Laufman et al, 1990; Adelman, 1989; 1992; De Antonio y Samper, 1990;
Beckam, 1991; Lpez et al 1991].
Adems se desarrollamos una herramienta de arquitectura web que permite
estudiar la viabilidad de proyectos de explotacin de informacin desarrollados
bajo la metodologa P3TQ a lo largo de todo su ciclo.
Dicha herramienta est desarrollada con Goolgle App Engine, un nuevo concepto
de programacin web basado en el lenguaje python, y funcionando enteramente
(cdigo y persistencia) en los servidores de Google.
Se adjunta el manual de usuario y documentacin de desarrollo de la herramienta
junto a este documento.
Pg. 22

Directores
Alumnos
Pablo Damin MNDEZ
5.
Futuras mejoras
Si bien la herramienta desarrollada es muy completa, incluyendo seguimiento de

proyectos, generacin de distintas evaluaciones para cada trabajo y manejo de
usuarios, adems de la funcionalidad bsica; el mtodo propuesto es extensible,
pueden reconocerse nuevos puntos de riesgo siguiendo minuciosamente los pasos
que D. Pyle describe en la metodologa P3TQ y agregarse a la metodologa.
El agregado de nuevos puntos de riesgo no requiere de recodificacin de la
herramienta, pero s un agregado cuidadoso en su base de datos, ya que la
metodologa P3TQ cumple una secuencia que es respetada en este trabajo.
6. Bibliografa

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

Publishers.
Garca-Martnez, R. ; Britos, P. (2004). Sistemas Expertos. Nueva Librera.
Chapman, P. ; Clinton, J. (2000). CRISP-DM 1.0: Step by Step Data mining Guide.
The CRISP-DM consortium; 2000
Martelli, A. (2008). Python, Gua de referencia. Anaya Multimedia.
Martelli, A. (2006). Python in a Nutshell. O'Reilly.
Prez Lpez, C.; Santin Gonzlez, D. (2006). Data Mining, Soluciones con
Enterprise Miner. Alfaomega Grupo Editor.
Colomes Fornos, X. (2009); Css Dhtml y Ajax Gua Prctica. Anaya
Multimedia.
Ochoa, A (2006). Uso de Tcnicas de educcin para el entendimiento del negocio;
Tesis de Magster en Ingeniera de Software. Instituto Tecnolgico de Buenos
Aires.
Google (2008). Gua de Introduccin de Google AppEngine. Disponible en:
http://code.google.com/intl/es-ES/appengine/docs/python/gettingstarted/
Pg. 23

Directores
Alumnos
Pablo Damin MNDEZ
Anexo 1. Documento de
Desarrollo de la Herramienta
DAMVE
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE.
Pg. 24

Directores
Alumnos
Pablo Damin MNDEZ
1. Objetivo
El presente documento tiene como objetivo documentar la herramienta software
DAMVE, que permite ingresar las caractersticas de un proyecto que utiliza la
metodologa P3TQ, con el objetivo de analizar y evaluar su viabilidad.
El documento presenta informacin detallada de cada una de las etapas en el
desarrollo de la herramienta, utilizando siempre que sea posible, el estndar UML
de modelado de software:
Requerimientos funcionales, requerimientos no funcionales y restricciones
Modelo de anlisis (casos de uso)
Arquitectura
Modelo de diseo
Casos de Prueba
El modelo de negocio que debe implementar la herramienta se encuentra
documentado en la Memoria Del Trabajo Profesional, donde se describe la
tcnica de estudio de viabilidad aplicada a la metodologa P3TQ.
Pg. 25

Directores
Alumnos
Pablo Damin MNDEZ
2. Funcionalidad del Sistema

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

Creacin de proyectos que utilizarn o utilizan la metodologa P3TQ.

Creacin de evaluaciones asociadas a un proyecto, que permitan evaluar su
viabilidad a lo largo del tiempo (desde la etapa de concepcin y durante
su ejecucin).
Todas las evaluaciones estarn basadas en una plantilla comn de estudio de
viabilidad.
Las evaluaciones pueden ser completadas por un usuario en una o varias
sesiones. En el primer caso debe presentarse el resultado de la evaluacin. En
el segundo caso la evaluacin debe presentarse como "en ejecucin".
Las evaluaciones de un proyecto deben presentarse de manera que se pueda
analizar la evolucin del proyecto a travs de la comparacin de dichas
evaluaciones.
2.2. Gestin de usuarios

Deben existir al menos los siguientes roles en el sistema:
Lderes de proyecto: son los responsables de la administracin del proyecto
pudiendo crear evaluaciones y/o participar en todas las evaluaciones en
ejecucin de ese proyecto.
Colaboradores de proyecto: son usuarios asignados por el lder del proyecto
y su funcin es realizar evaluaciones del proyecto. Un colaborador puede,
entonces, crear una evaluacin y completarla hasta obtener el resultado de
viabilidad. Un colaborador no puede continuar una evaluacin en ejecucin
creada por otro colaborador del mismo proyecto.
Evaluador: Es un usuario con mucha experiencia que tiene conocimiento
suficiente en proyectos que utilizan la metodologa P3TQ y puede actualizar la
plantilla de evaluacin de estudio de viabilidad de proyectos.
Administrador: Es responsable de la administracin de la infraestructura y de
la base de datos que consume sistema, como as tambin de asignar a los
usuarios evaluadores.
Pg. 26

Directores
Alumnos
Pablo Damin MNDEZ
3. Cambios en la versin
A continuacin se presentan las modificaciones realizadas en las distintas
versiones del documento, para facilitar la trazabilidad de los cambios.
3.1. Versin 4
Actualizacin del objetivo del documento.
3.2. Versin 3

Actualizacin del objetivo del documento.

Se incorporan los casos de prueba, conclusiones y mejoras.
3.3. Versin 2

Se corrigen las referencias en los grficos.

Se incorpora la documentacin de paquetes, clases, secuencia, pantallas y
despliegue.
3.4. Versin 1
Versin inicial
4. Especificacin de Requerimientos
4.1. Formato
La Figura A1.1 contiene el formato con el cual se registran cada uno de los
requerimientos. A partir de la seccin 4.2 se desarrolln todos los requerimientos
utilizando dicho formato.
Los campos a completar en dicho registro son los siguientes:
Cdigo: comienza con el identificador de tipo: RF si se trata de un requisito
funcional o con RNF si se trata de un requisito no funcional. A continuacin se
enumeran correlativamente segn el tipo (funcional o no funcional). Ej) RF-001
(requisito funcional 1)
Relevancia:
Se clasifica en Alta, Media o Baja segn la regla de negocio /
requerimiento no funcional que describa.
Pg. 27

Directores
Alumnos
Pablo Damin MNDEZ

Clasificacin: Funcional si se trata de un requerimiento funcional o o el tipo

de requerimiento no funcional (ej: Reusabilidad, Portabilidad, Confiabilidad,
etc.)
Nombre: identificador textual (breve) del requerimiento.
Descripcin: descripcin textual del requerimiento.
Control de cambios: debe ingresarse por cada cambio la fecha, persona que
lo solicita y descripcin del cambio. Todos los cambios son registrados de
manera cronolgica ascendente (el primer cambio al comienzo y el ltimo
cambio al final).
Cdigo Relevancia Clasificacin
Nombre
Descripcin
Control de Cambios
Fecha
Solicitado
por
Descripcin del cambio
Figura A1.1. Formato de registro de los requerimientos del sistema
4.2. Requerimientos funcionales

Los requerimientos funcionales definen las funciones que el sistema ser capaz de
realizar y describen las transformaciones que el sistema realiza sobre las entradas
para producir salidas.
Se presentan a continuacin los requerimientos funcionales del sistema.
Pg. 28

Directores
Alumnos
Pablo Damin MNDEZ
4.2.1. Crear y Actualizar Proyectos

La Figura A1.2 presenta el requerimiento funcional con el formato establecido.
RF-001 Alta
Funcional
Nombre
CREAR Y ACTUALIZAR PROYECTOS
Descripcin
El sistema debe permitirle a un usuario registrado crear un nuevo proyecto y
convertirse en su lder.
La informacin que debe ingresarse y guardarse cuando se crea un proyecto es:
Descripcin del proyecto

Fecha de creacin

Lder del proyecto (usuario que lo crea)
Deben respetarse las siguientes reglas:
Cualquier usuario registrado en el sistema se convierte en el lder de un
proyecto que crea.
Control de Cambios
Fecha
Solicitado
por
Figura A1.2. Requerimiento Funcional Crear y Actualizar Proyectos
Pg. 29

Directores
Alumnos
Pablo Damin MNDEZ
4.2.2. Creacin de Evaluaciones

RF-002 Alta
Funcional
Nombre
CREACIN DE EVALUACIONES
Descripcin
El sistema debe permitirle al lder del proyecto o a un usuario asignado como
colaborador de del mismo crear una nueva evaluacin a partir de la plantilla
estndar.
La informacin que debe ingresarse y almacenarse cuando se crea una evaluacin
es:

Proyecto al cual pertenece
Descripcin de la evaluacin

Fecha de creacin

Usuario que la crea (colaborador o lder del proyecto)
Una vez que la evaluacin ha sido creada el sistema debe, automticamente,
presentar la interfaz para que el usuario pueda comenzar a completar el estudio
de debilidad.
Una evaluacin puede ser suspendida, quedando en el estado de "en ejecucin".
Control de Cambios
Fecha
Solicitado
por
Figura A1.3. Requerimiento Funcional Creacin de evaluaciones
Pg. 30

Directores
Alumnos
Pablo Damin MNDEZ
4.2.3. Continuar con una evaluacin en Ejecucin

RF-003 Media
Funcional
Nombre
CONTINUAR
CON
EVALUACIN EN EJECUCIN
UNA
Descripcin
El sistema debe permitirle al usuario creador de una evaluacin que se encuentra
en el estado de "en ejecucin " continuar con la misma, presentndole la interfaz
correspondiente.
Control de Cambios
Fecha
Solicitado
por
Figura A1.4. Requerimiento Funcional continuar con una evaluacin en ejecucin
Pg. 31

Directores
Alumnos
Pablo Damin MNDEZ
4.2.4. Mostrar resultados del proyecto

RF-004 Alta
Funcional
Nombre
MOSTRAR
PROYECTO
RESULTADOS
DEL
Descripcin
El sistema debe presentar una interfaz que le permita a los usuarios que iniciaron
sesin navegar un proyecto cualquiera.
Si el usuario pertenece a dicho proyecto (siendo su lder o colaborador)

podr ver los datos generales del proyecto (descripcin, fecha de
creacin, usuario creador, sus colaboradores) y la informacin
actualizada y resumida de todas las evaluaciones realizadas, incluyendo
el resultado final de cada evaluacin completada, ordenado de manera
cronolgica descendente, de manera de poder analizar la evolucin del
proyecto en el tiempo. Si existen evaluaciones en ejecucin el sistema
debe comunicarlo y proveer una opcin para poder retomar dicha
evaluacin.
Si el usuario no pertenece al proyecto podr ver solamente los datos
generales del proyecto especificados anteriormente y la informacin de
las evaluaciones, pero no su resultado final.
Control de Cambios
Fecha
Solicitado
por
Figura A1.5. Requerimiento Funcional Mostrar resultados del proyecto
4.2.5. Actualizacin de la Plantilla de Evaluacin

Cdigo
RF-005
Relevancia
Media
Clasificacin
Funcional
Nombre
ACTUALIZACIN DE LA PLANTILLA
DE EVALUACIN
Descripcin
El sistema debe proporcionar una plantilla estndar pre-cargada que permita de
avisar evaluaciones de proyectos por los usuarios del sistema.
Adems debe proporcionar una interfaz para que el usuario con rol de Evaluador,
Pg. 32

Directores
Alumnos
Pablo Damin MNDEZ
pueda actualizar esta plantilla de evaluacin, ajustando los siguientes parmetros

en cada pregunta de la plantilla:
Texto de la pregunta
Dimensin a la que pertenece
Peso
Cuando se actualiza la plantilla estndar las evaluaciones posteriores a
dicha actualizacin se realizarn con los cambios.
Las evaluaciones que se han completado antes de la actualizacin no
reflejarn los cambios realizados.
Las evaluaciones que se encuentran "en ejecucin" no reflejarn los

cambios en aquellas preguntas ya contestadas; sin embargo s lo harn en
las preguntas an no contestadas.
Control de Cambios
Fecha
Solicitado por
05/03/2009 Alejandro
Rodrguez
El
administrador
debe
poder
inicializar el cuestionario con valores
por defecto al desplegarse el sistema
por primera vez.
El
administrador
debe
poder
restablecer
el
cuestionario
por
defecto.
Figura A1.6. Requerimiento Funcional Actualizacin de la Plantilla de Evaluacin
Pg. 33

Directores
Alumnos
Pablo Damin MNDEZ
4.2.6. Asignacin de Colaboradores al Proyecto

RF-006 Alta
Funcional
Nombre
ASIGNACIN DE COLABORADORES
AL PROYECTO
Descripcin
El sistema debe permitirle al lder de un proyecto designar colaboradores para
que puedan realizar evaluaciones en dicho proyecto. La informacin que debe
ingresarse para poder asignar un colaborador es su nombre de usuario,
coincidente con su direccin de correo electrnico.
Una vez que esta informacin ha sido provista, los usuarios designados pueden
colaborar en un proyecto creando evaluaciones. Deben respetarse las siguientes
reglas:
Un usuario puede ser colaborador de distintos proyectos.
Un usuario no puede ser colaborador y lder de proyecto al mismo

tiempo. El rol de lder de proyecto incluye la funcionalidad de
colaborador.
Control de Cambios
Fecha
Solicitado
por
Figura A1.7. Requerimiento Funcional Asignacin de Colaboradores al Proyecto
Pg. 34

Directores
Alumnos
Pablo Damin MNDEZ
4.2.7. Designacin de evaluadores

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

Directores
Alumnos
Pablo Damin MNDEZ
4.3. Requerimientos no funcionales

Los requerimientos no funcionales tienen que ver con caractersticas que de una
u otra forma puedan limitar el sistema, como por ejemplo, el rendimiento (en
tiempo y espacio), interfaces de usuario, fiabilidad (robustez del sistema,
disponibilidad de equipo), mantenimiento, seguridad, portabilidad, estndares,
etc.
Se presentan a continuacin los requerimientos no funcionales del sistema.
4.3.1. Proporcionar tiempos de respuesta aceptables

La Figura A1.9 presenta el requerimiento no funcional con el formato establecido.
Cdigo
RNF001
Relevancia Clasificacin
Alta
Rendimiento
Nombre
PROPORCIONAR
TIEMPOS
RESPUESTA ACEPTABLES
DE
Descripcin
El sistema debe poseer la capacidad de prestar el servicio con los siguientes
niveles aceptables de desempeo, teniendo cuenta la concurrencia de usuarios
Tiempo mximo de actualizacin de pantalla durante la ejecucin de una
evaluacin a cada usuario: 5 seg.
Cantidad mxima de usuarios concurrentes: 20 usuarios
Control de Cambios
Fecha
Solicitado por
Figura A1.9. Requerimiento no Funcional Designacin de evaluadores
Pg. 36

Directores
Alumnos
Pablo Damin MNDEZ
4.3.2. Preveer Contingencias Por Cada Del Sistema

La Figura A1.10 presenta el requerimiento no funcional con el formato
establecido.
Cdigo
RNF002
Alta
Rendimiento
Nombre
PREVEER
CONTINGENCIAS
CAIDA DEL SISTEMA
POR
Descripcin
El sistema deber prever contingencias que pueden afectar la prestacin estable y
permanente del servicio.
La siguiente es la lista de las contingencias que se deben tener en cuenta y se
pueden considerar crticas:
Cada del sistema por volumen de datos excedido en la base.
Sobrecarga del sistema por volumen de transferencia de datos a los
usuarios.
Cada del sistema por sobrecarga de recursos (procesos, memoria).
Estas consideraciones implicarn que la infraestructura tcnica sobre la que se
implantar el sistema garantice una alta disponibilidad del mismo.
Control de Cambios
Fecha
Solicitado por
Figura A1.10. Requerimiento no Funcional Preveer Contingencias Por Cada Del Sistema
Pg. 37

Directores
Alumnos
Pablo Damin MNDEZ
4.3.3. Considerar El Crecimiento Esperado En El Volumen De Datos

establecido.
Cdigo
Nombre
RNF003
Media
CONSIDERAR
EL
CRECIMIENTO
ESPERADO EN EL VOLUMEN DE
DATOS
Capacidad
Descripcin
El sistema deber garantizar el soporte en el crecimiento del volumen de la
informacin almacenada que se gestionar en la base de datos.
Deben realizarse estimaciones, mediciones y comparaciones para proyectar un
estimado de dicho crecimiento, y se presentarse las caractersticas de tecnologa
requeridas para afrontar el crecimiento proyectado en el volumen.
Control de Cambios
Fecha
Solicitado por
Figura A1.11. Requerimiento no Funcional Considerar El Crecimiento Esperado En El Volumen De Datos
Pg. 38

Directores
Alumnos
Pablo Damin MNDEZ
4.3.4. Parametrizar Las Variables Del Sistema

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

Directores
Alumnos
Pablo Damin MNDEZ
4.3.5. Disear interfaces con el usuario amigables

establecido.
Cdigo
Nombre
RNF005
Media
DISEAR INTERFACES
USUARIO AMIGABLES
Amigabilidad
CON
EL
Descripcin
El sistema debe poseer una interfaz grfica uniforme a travs del mismo
incluyendo pantallas, mens y opciones, tamao de las pantallas, color, tipo de
letra y configuracin de los campos de entrada.
El diseo debe realizarse guiado por las caractersticas generales, en cuanto a
colores institucionales y disposicin de contenidos, encontradas en el sitio web de
la organizacin.
Las interfaces deben realizarse en idioma castellano; sin perjuicio de lo cual debe
evitar traducirse la terminologa tcnica especfica que no posee una traduccin
precisa al castellano.
Control de Cambios
Fecha
Solicitado por
Figura A1.13. Requerimiento no Funcional Disear interfaces con el usuario amigables
4.3.6. Desarrollar manual de usuario

establecido.
Cdigo
Nombre
RNF006
Alta
DESARROLLAR
USUARIO
Amigabilidad
MANUAL
DE
Descripcin
Debe desarrollarse el Manual de Usuario del Sistema que especifique la totalidad
de la funcionalidad que ste provee.
Los contenidos del Manual deben estar ofrecidos 100% en lnea, en formato
HTML.
Control de Cambios
Fecha
Solicitado por
Figura A1.14. Requerimiento no Funcional Desarrollar manual de usuario

Pg. 40

Directores
Alumnos
Pablo Damin MNDEZ
4.3.7. Codificar con estndares

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

establecido.
Cdigo
RNF008
Alta
Seguridad
Nombre
PERMITIR NIVELES DE SEGURIDAD
Descripcin
El sistema deber permitir que toda su informacin junto con los procesos
desarrollados por el mismo tenga controles de acceso acordes con el nivel de
privacidad requerido.
Los niveles de seguridad estarn determinados por la distribucin jerrquica de
los usuarios, a saber:
Usuarios Administradores: Acceso total.
Usuarios registrados : Podrn tener acceso al informacin, que
corresponda con su rol (lder de proyecto, colaborador o evaluador)
Control de Cambios
Fecha
Solicitado por
Pg. 41

Directores
Alumnos
Pablo Damin MNDEZ
Figura A1.16. Requerimiento no Funcional permitir niveles de seguridad
Pg. 42

Directores
Alumnos
Pablo Damin MNDEZ
4.4. Restricciones
Se presentan a continuacin las restricciones del sistema.
4.4.1. Arquitectura del Sistema

La Figura A1.17 presenta la restriccin con el formato establecido.
RST-001 Alta
Restricciones
Nombre
ARQUITECTURA DEL SISTEMA
Descripcin
El Sistema debe desarrollarse sobre la Arquitectura Web Appengine de Google
debiendo utilizarse exclusivamente recursos de software compatibles con ella.
Los requerimientos mnimos de la aplicacin, corriendo en un servidor local se
presentan a continuacin. Los requisitos de hardware del servidor pueden variar
segn los requerimientos de rendimiento:
Procesador 1.0 GHz
512 MB de RAM
Los requerimientos mnimos de software y hardware en el equipo cliente son:
Navegador web compatible con Javascript (Recomendado IE7 o
posterior/Firefox 2.0 o posterior)

Conexin a Internet, si la aplicacin se ejecuta en Appspot de Google o
Interfaz de Red que soporte el protocolo TCP/IP para una conexin local.
Control de Cambios
Fecha
Solicitado por
Figura A1.17. Restriccin Arquitectura del Sistema
Pg. 43

Directores
Alumnos
Pablo Damin MNDEZ
5. Modelo de anlisis
5.1. Diagrama de Casos de Uso
La Figura A1.18 presenta el diagrama de Casos de Uso del sistema, basado en los
requerimientos funcionales desarrollados previamente:
ud Casos de Uso
Inicializar
ev aluacin
Asignar
Colaborador
Administrador
Asignar ev aluador
Lider de Proyecto
include
include
Crear Proyecto
include
Validar usuario
Consultar
Ev aluacin
include
include
include
Visitante
include
include
Consultar Proyecto
include
Ev aluar Viabilidad
Actualizar plantilla
de ev aluacin
include
Ev aluador
Colaborador de
Proyecto
Crear Ev aluacin
Figura A1.18. Restriccin Arquitectura del Sistema
Pg. 44

Directores
Alumnos
Pablo Damin MNDEZ
5.2. Matriz de trazabilidad Casos de Uso Requerimientos

Funcionales
La Figura A1.19 muestra la matriz de trazabilidad que permite relacionar los
casos de uso del sistema con los requerimientos funcionales, permitiendo conocer
que requerimientos funcionales resuelve cada caso de uso.
Caso de Uso
Id
Nombre
Requerimiento
Funcional
Id
CU-001
Validar usuario
--
CU-002
Asignar evaluador
RF007
CU-003
Actualizar planilla de evaluacin
RF005
CU-004
Evaluar viabilidad
RF003
CU-005
Crear evaluacin
RF002
CU-006
Consultar proyecto
RF004
CU-007
Consultar evaluacin
RF004
CU-008
Crear proyecto
RF001
CU-009
Asignar colaborador
RF006
CU-010
Inicializar Evaluacin
RF005
Figura A1.19. Matriz de trazabilidad Casos de Uso Requerimientos funcionales
Pg. 45

Directores
Alumnos
Pablo Damin MNDEZ
5.3. Realizacin de los Casos de Uso

A continuacin se presenta la realizacin de cada uno de los casos de uso del
sistema.
5.3.1. Validar Usuario

La Figura A1.20 presenta el caso de uso con el formato establecido.
ID
CU-001
Nombre
VALIDAR USUARIO
Fecha Creacin
16/11/2008
Actores
Descripcin
El sistema verifica que el usuario posea el rol correcto para

realizar una tarea.
Trigger
El usuario intenta realizar una accin en el sistema.
Fecha
ltima 16/11/2008
modificacin
Precondiciones
Postcondiciones El operador se encuentra validado en el sistema.
Flujo principal
CU-001.0
1. El sistema presenta una pantalla que invita al
usuario a ingresar su nombre y contrasea para
autenticarse.
2. El usuario ingresa su nombre y contrasea y
presiona el botn ingresar.
3. El sistema verifica los roles que posee el usuario en
el sistema (visitante, lder de proyecto, colaborador
o evaluador).
4. El sistema notifica al usuario que est autenticado.
Flujos
alternativos
CU-001.1
1. Si el usuario ingresa su nombre y contrasea de
manera incorrecta el sistema lo notifica y le solicita
ingresar los datos nuevamente, volviendo a CU001.0
Excepciones
Extensiones
Incluye
Heredado por
Prioridad
Alta
Pg. 46

Directores
Alumnos
Pablo Damin MNDEZ
Reglas
de Negocio
Requerimientos
especiales
Hiptesis
Notas
Figura A1.20. Caso de uso validar Usuario
5.3.2. Asignar evaluador

ID
CU-002
Nombre
ASIGNAR EVALUADOR
Fecha Creacin
16/11/2008
Actores
Fecha
ltima 16/11/2008
modificacin
Administrador
Descripcin
El administrador del sistema designa a un usuario con el rol

de evaluador para que pueda modificar la plantilla estndar
de evaluacin.
Trigger
El administrador accede a la opcin agregar evaluador
Precondiciones
El administrador ha iniciado sesin en el sistema.
Postcondiciones
Un nuevo usuario cuenta con el rol de evaluador.
Flujo principal
CU-002.0
1. El sistema verifica que el usuario sea
administrador. De no cumplirse se ejecuta el flujo
alternativo CU-002.1.
2. El sistema presenta un formulario que solicita el email del usuario a registrar como evaluador.
3. El administrador ingresa el e-mail del usuario.
4. El sistema agrega al usuario como evaluador y
notifica al administrador
Flujos
alternativos
CU-002.1
El sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
Excepciones
Extensiones
Incluye
CU-001. Validar Usuario
Pg. 47

Directores
Alumnos
Pablo Damin MNDEZ
Heredado de
Prioridad
Reglas
de
Negocio
Requerimientos
especiales
Hiptesis
RF-007
Notas
Alta
Figura A1.21. Caso de uso asignar evaluador
5.3.3. Actualizar planilla de evaluacin

ID
Nombre
CU-003
ACTUALIZAR PLANILLA DE EVALUACIN
Fecha Creacin
16/11/2008
Actores
Fecha
ltima 16/11/2008
modificacin
Evaluador
Descripcin
El usuario evaluador actualiza las preguntas de la planilla

estndar de evaluacin, es la fuente de las futuras
evaluaciones de viabilidad de todos los proyectos.
Trigger
El evaluador accede a la opcin actualizar planilla
Precondiciones
El usuario debe contar con el rol de evaluador
Postcondiciones
La planilla
actualizada
Flujo principal
de
evaluacin
estndar
queda
CU-003.0
1. El sistema verifica que el usuario sea evaluador. De
no cumplirse se ejecuta el flujo alternativo CU003.1.
2. El sistema presenta un formulario que muestra la
informacin de todas las preguntas de la plantilla
estndar con la posibilidad de modificar la
descripcin, el peso y la dimensin.
3. El evaluador actualiza todos los parmetros de
todas las preguntas que consideren necesario y
enviar formulario.
4. El sistema actualiza la plantilla estndar y notifica
al evaluador
Pg. 48

Directores
Alumnos
Pablo Damin MNDEZ
Flujos
alternativos
CU-003.1
el sistema notifica al usuario que no cuenta con los
Excepciones
Extensiones
Incluye
Heredado de
Prioridad
Reglas
de
Negocio
Requerimientos
especiales
Hiptesis
RF-005
Notas

Alta
Figura A1.22. Caso de uso actualizar planilla de evaluacin
5.3.4. Evaluar viabilidad

ID
Nombre
CU-004
EVALUAR VIABILIDAD
Fecha Creacin
16/11/2008
Actores

Fecha
ltima 16/11/2008
modificacin
Lder de proyecto
colaborador
Descripcin
El sistema le permite al usuario creador de una evaluacin

que se encuentra en el estado de "en ejecucin" continuar
con la misma, presentndole la interfaz correspondiente.
Trigger
El lder de proyecto o colaborador accede a la opcin

continuar evaluacin.
Precondiciones
El usuario debe contar con el rol de colaborador en

el proyecto en el cual desea continuar la
evaluacin.
Postcondiciones
La evaluacin queda actualizada con los pasos del

cuestionario cargados
Flujo principal
CU-004.0
1. El sistema verifica que el usuario sea colaborador
Pg. 49

Directores
Alumnos
Pablo Damin MNDEZ
del proyecto al cual pertenece la evaluacin. De no

cumplirse se ejecuta el flujo alternativo CU-004.1.
2. Se repite el siguiente ciclo hasta que el colaborador
completa la ltima pregunta del cuestionario o
abandona el cuestionario dejndolo incompleto.
a. El sistema presenta todas las preguntas y
respuestas contestadas hasta el momento.
b. El sistema presenta un formulario que
muestra
la
prxima
pregunta
del
cuestionario.
El colaborador contesta la pregunta.
c.
3. Si el usuario completo todo el cuestionario el
sistema muestra el resultado de la evaluacin,
ejecutando el caso de uso CU-007.
Flujos
alternativos
CU-004.1
Excepciones
Extensiones
Incluye

CU-007. Consultar evaluacin
Heredado por
Prioridad
Alta
Reglas
Negocio
Notas
de RF-003
Figura A1.23. Caso de uso evaluar viabilidad
5.3.5. Crear evaluacin

ID
CU-005
Nombre
CREAR EVALUACIN
Fecha Creacin
16/11/2008
Actores
Descripcin
Fecha
ltima 16/11/2008
modificacin
Colaborador
El sistema le permite al usuario colaborador crear una

evaluacin en un proyecto al cual pertenece.
Pg. 50

Directores
Alumnos
Pablo Damin MNDEZ
Trigger
El colaborador accede a la opcin crear nueva evaluacin.
Precondiciones
El usuario debe contar con el rol de colaborador en

el proyecto en el cual desea crear la evaluacin.
Postcondiciones
La evaluacin queda creada.
Flujo principal
CU-005.0
1. El sistema verifica que el usuario sea colaborador
del proyecto al cual pertenece la evaluacin. De no
cumplirse se ejecuta el flujo alternativo CU-005.1.
2. El sistema presenta un formulario para que el
colaborador ingrese la descripcin de la
evaluacin.
3. El colaborador completa de informacin y enva el
formulario.
4. El sistema crea la nueva evaluacin, y ejecuta el
caso de uso CU-004, que inicia la evaluacin de
viabilidad.
Flujos
alternativos
CU-005.1
Excepciones
Extensiones
Incluye

CU-004. Evaluar viabilidad
Heredado por
Prioridad
Alta
Reglas
de RF-002
Negocio
Requerimientos especiales
Hiptesis
Notas
Figura A1.24. Caso de uso Crear evaluacin
5.3.6. Consultar proyecto

ID
CU-006
Nombre
CONSULTAR PROYECTO
Pg. 51

Directores
Alumnos
Pablo Damin MNDEZ
Fecha Creacin
16/11/2008
Actores

Fecha
ltima 16/11/2008
modificacin
Lder de proyecto
Colaborador
Descripcin
El sistema le presenta a los miembros del proyecto toda la

informacin existente.
Trigger
Un usuario del proyecto ingresa a la opcin consultar

proyecto.
Precondiciones
El usuario debe pertenecer al proyecto(lder o colaborador)
Postcondiciones Ninguna
Flujo principal
CU-006.0
1. El sistema verifica que el usuario sea lder o
colaborador del proyecto. De no cumplirse se
ejecuta el flujo alternativo CU-006.1.
2. El sistema presenta la siguiente informacin del
proyecto al usuario, dando la opcin de que la
informacin pueda ser impresa en papel.
Fecha de creacin
Descripcin
Lder
Colaboradores
Lista de evaluaciones realizadas ordenadas en forma
cronolgica descendente (incluye fecha de creacin,
colaborador de la creo, descripcin, estado: s est finalizada
el resultado de la evaluacin; sino el mensaje en ejecucin).
Flujos
alternativos
CU-006.1
Excepciones
Extensiones
Incluye
Heredado de
Prioridad
Alta
CU-001 : Validar Usuario
Reglas
de RF-004
Negocio
Pg. 52

Directores
Alumnos
Pablo Damin MNDEZ
Hiptesis
Notas
Figura A1.25. Caso de uso consultar proyecto
5.3.7. Consultar Evaluacin

ID
CU-007
Nombre
COSULTAR EVALUACIN
Fecha Creacin
16/11/2008
Actores
Fecha
ltima 16/11/2008
modificacin
Lder de proyecto
Colaborador
Descripcin
El sistema le presenta a los miembros del proyecto la

informacin de una evaluacin.
Trigger
Un usuario del proyecto ingresa a la opcin consultar

Evaluacin.
Precondiciones
El usuario debe pertenecer al proyecto (lder o colaborador)

la evaluacin debe estar finalizada.
Postcondiciones Ninguna
Flujo principal
CU-007.0
1. El sistema verifica que el usuario sea lder o
colaborador del proyecto. De no cumplirse se
ejecuta el flujo alternativo CU-007.1.
2. El sistema presenta la siguiente informacin de la
evaluacin al usuario proveyendo la opcin de
imprimir en papel.
Fecha de creacin
Proyecto al cual pertenece
Colaborador de la creo
Descripcin
Resultado final expresado numrica y
grficamente.
Todas las preguntas y respuestas de la
evaluacin que fueron respondidas y que
justifican el resultado.
Flujos
alternativos
CU-007.1
Pg. 53

Directores
Alumnos
Pablo Damin MNDEZ

Excepciones
Extensiones
Incluye
Heredado de
Prioridad
Alta
CU-001 : Validar Usuario
Reglas
de RF-004
Negocio
Hiptesis
Notas
Figura A1.26. Caso de uso consultar evaluacin
5.3.8. Crear proyecto

ID
Nombre
CU-008
CREAR PROYECTO
Fecha Creacin
16/11/2008
Actores
Fecha
ltima 16/11/2008
modificacin
Visitante
Descripcin
El sistema le permite a un usuario registrado crear un nuevo

proyecto y convertirse en su lder.
Trigger
El usuario accede a la opcin crear nuevo proyecto.
Precondiciones
Postcondiciones
El proyecto queda creado.
Flujo principal
CU-008.0
1. El sistema presenta un formulario para que el
usuario ingrese la descripcin del nuevo proyecto.
2. El usuario completa de informacin y enva el
formulario.
3. El sistema crea el nuevo proyecto.
Flujos
alternativos
Excepciones
Extensiones
Pg. 54

Directores
Alumnos
Pablo Damin MNDEZ
Incluye
Heredado por
Prioridad
Alta
Reglas
de RF-001
Negocio
Requerimientos
especiales
Hiptesis
Notas
Figura A1.27. Caso de uso Crear proyecto
5.3.9. Asignar colaborador

ID
CU-009
Nombre
ASIGNAR COLABORADOR
Fecha Creacin
16/11/2008
Actores
Fecha
ltima 16/11/2008
modificacin
Lder de proyecto
Descripcin
El lder de un proyecto designa a un usuario con el rol de

colaborador para que pueda crear nuevas evaluaciones en
dicho proyecto.
Trigger
El lder del proyecto accede a la opcin agregar colaborador
Precondiciones
El lder de proyecto ha iniciado sesin en el

sistema.
Postcondiciones
Un nuevo usuario cuenta con el rol de colaborador.
Flujo principal
CU-009.0
1. El sistema verifica que el usuario sea lder del
proyecto. De no cumplirse se ejecuta el flujo
2. El sistema presenta un formulario que solicita el email del usuario a registrar como colaborador.
3. El lder del proyecto ingresa el e-mail del usuario.
4. El sistema agrega al usuario como colaborador y
notifica al lder del proyecto
Flujos
alternativos
CU-009.1
Pg. 55

Directores
Alumnos
Pablo Damin MNDEZ
Excepciones
Extensiones
Incluye
Heredado por
Prioridad
Reglas
de
Negocio
Requerimientos
especiales
Hiptesis
RF-006

Alta
Notas
Figura A1.28. Caso de uso asignar colaborador
5.3.10.
Inicializar cuestionario

ID
Nombre
CU-010
INICIALIZAR CUESTIONARIO
Fecha Creacin
05/03/2009
Actores
Fecha
ltima 05/03/2009
modificacin
Administrador
Descripcin
El administrador del sistema inicializa la Plantilla estndar

de
evaluacin
de
proyectos
con
los
valores
predeterminados.
Trigger
El administrador accede a la opcin de inicializar Plantilla

devaluacin.
Precondiciones
El administrador ha iniciado sesin en el sistema.
Postcondiciones
La Plantilla estndar de evaluacin de proyectos se

encuentra inicializada con los valores por defecto.
Flujo principal
CU-009.0
1. El sistema verifica que el usuario sea
administrador. De no cumplirse se ejecuta el flujo
2. El sistema presenta un formulario que solicita al
administrador del sistema su confirmacin para
inicializar la Plantilla de evaluacin con los valores
por defecto.
Pg. 56

Directores
Alumnos
Pablo Damin MNDEZ
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 evaluacin con los
valores por defecto y notifica al administrador sobre la
accin.
CU-009.3
El sistema notifica al usuario que no se realiz la
inicializacin del cuestionario.
Excepciones
Extensiones
Incluye
Heredado por
Prioridad
Reglas
de
Negocio
Requerimientos
especiales
Hiptesis
RF-005

Alta
Notas
Figura A1.29. Caso de uso inicializar cuestionario
Pg. 57

Directores
Alumnos
Pablo Damin MNDEZ
6. Arquitectura del Sistema

6.1. La arquitectura Appengine
La Figura A1.30 presenta un grfico que resume las principales componentes de
la arquitectura propuesta por Appengine y que, en lneas generales, respeta el
clsico patrn MVC y que ser la base del desarrollo del Sistema.
Figura A1.30. Arquitectura de Appengine
Entidades persistentes: Appengine provee una capa destinada al modelado

de entidades persistentes. Si bien la persistencia y el modelo de negocio estn
completamente acoplados en esta capa (Patrn Active Record) Appengine
provee un framework de persistencia que permite abstraerse del modelo
relacional y trabajar con entidades, utilizando operadores en las entidades y el
lenguaje GQL para realizar consultas de objetos.
Controlador RequestHandler. Appengine provee un controlador que

encapsula el protocolo http y permite capturar la interaccin del usuario a
travs de comandos GET o POST, que se traducen en Requests o pedidos. El
controlador se programa segn se requiera y se presentarn los resultados
utilizando plantillas (ver a continuacin) a travs de Responses o respuestas.
Pg. 58

Directores
Alumnos
Pablo Damin MNDEZ
Plantillas de Vista: Appengine provee un framework basado en Django para

desarrollar las vistas HTML utilizando plantillas (Patrn Template View) y
fomentando la reutilizacin y desacople con el modelo de negocio.
Pg. 59

Directores
Alumnos
Pablo Damin MNDEZ
7. Diseo de la aplicacin
En esta seccin se detallar el diseo elegido para implementar el sistema. La
tcnica elegida para llevar a cabo la tarea consiste en presentar los modelos de lo
general a lo particular.
Se comenzara por presentar los paquetes que componen la aplicacin y su
relacin.
Posteriormente se describir cada paquete como un conjunto de clases que
colaboran para resolver alguna parte del sistema, utilizando diagramas de
clase UML.
Finalmente se describirn las responsabilidades de las clases ms relevantes
del paquete.
Una vez presentados en detalle cada uno de los paquetes y las clases del sistema
se utilizarn diagramas de secuencia que permitan comprender la dinmica del
sistema a travs de la interaccin de las clases de distintos paquetes.
7.1. Diagrama de Paquetes de clases

A partir de la arquitectura presentada, que est basada fundamentalmente en el
patrn MVC, se disearon los paquetes que interrelacionados implementan la
funcionalidad del sistema.
La categorizacin por colores que se presenta en la Figura A1.31 ser utilizada
de aqu en adelante en este documento, para facilitar la comprensin del
mismo.
Modelo
Vista
Controlador
Infraestructura
Figura A1.31. Cdigo de color para cada una de las categoras de paquetes de la aplicacin
El diagrama presentado en la Figura A1.32 muestra los paquetes de las clases del
sistema y sus dependencias, categorizando cada uno de ellos por medio de colores
que permiten identificar a qu categora pertenecen.
Las categoras existentes son las tres definidas en el modelo MVC (modelo, vista y
controlador) ms una cuarta denominada infraestructura. Esta cuarta categora en
provista por el entorno Appengine e implementa los servicios de base que
Pg. 60

Directores
Alumnos
Pablo Damin MNDEZ
permitan desarrollar una aplicacin dentro de la arquitectura. Algunos de los

servicios dentro de la categora son:
Persistencia de entidades.
Acceso a archivos del sistema operativo.
Motor de plantillas para representacin de pgina web dinmicas.
Autenticacin de usuarios.
Estos servicios son parte de la infraestructura de la aplicacin y, generalmente,
son consumidos por una o ms de las tres categoras de MVC.
pd Paquetes
dbmodel
+ Answer
ev aluatorform
+ AddMemberPage
+ Evaluation
+ Evaluate
+ EvaluationInstance
+ MainPage
+ Evaluator
+ NextQuestion
+ Project
+ ProjectMember
+ Question
+ Result
v iew
+ CustomView
+ EvaluationDraw
google.appengine.ext
+ db
+ webapp
google.appengine.api
+ users
+ webapp.template
menu
+ menu
Infraestructura
Vista
Modelo
Controlador
Figura A1.32. Diagrama de paquetes de la aplicacin categorizados por color
Por simplicidad para el entendimiento se ha omitido la representacin en el

diagrama todos los paquetes de la categora controlador del sistema, incluyendo
solamente el paquete controlador evaluatorform. Para una descripcin detallada
de cada uno de los paquetes controladores debe leerse la seccin 7.4 de este
documento.
Pg. 61

Directores
Alumnos
Pablo Damin MNDEZ
La Figura A1.33 describe brevemente todos los paquetes que se han desarrollado
en el sistema y qu casos de uso implementa cada uno. No se describen los
paquetes de infraestructura ya que han sido muy bien documentados por
Appengine.
Nuevamente la columna tipo permite identificar la categora a travs de su color
asociado.
Nombre
Tipo
CU
que Descripcin
implementa
Todos
Contiene las clases que
implementan el modelo de la
aplicacin, incluyendo su
persistencia.
dbmodel
Modelo
view
Vista
evaluatorform
Controlador CU-004
CU-005
CU-007
Creacin, ejecucin y clculo

de
una
evaluacin
de
viabilidad para un proyecto.
choose_project
Controlador CU-008
Seleccin de un proyecto.
view_project
Controlador CU-006
CU-009
Creacin
proyecto.
add_evaluator
Controlador CU-002
Agregar evaluadores.
help
Controlador CU-001
Inicio y cierre de sesin el

sistema. Manual de Usuario.
data
Controlador CU-003 dos

CU-010
Inicializacin de datos.
Implementa
funciones
genricas de representacin
de los datos en formato
HTML.
consulta
en
Figura A1.33. Trazabilidad entre paquetes y casos de uso
7.2. dbmodel. La capa De dominio

La capa de dominio, se encarga de modelar la lgica del estudio de viabilidad,
incluyendo aquellas clases que son consideradas entidades y, por ende, deben ser
persistentes.
Esta capa se desarrolla dentro del componente de Modelo y Persistencia de
Appengine. Dentro de la misma existen dos niveles de los cuales uno de ellos est
acoplado al otro y usa sus servicios para resolver el estudio:
Pg. 62

Directores
Alumnos
Pablo Damin MNDEZ
7.2.1. Nivel1. Cuestionario

En este nivel se encuentran las entidades que modelan el cuestionario: las
preguntas, las respuestas admitidas para cada pregunta, y la secuencia dinmica
que permite conocer la prxima pregunta a partir de una pregunta respondida
con una respuesta determinada. Este nivel implementa un grafo dirigido no
cerrado, que representa todas las posibles secuencias del cuestionario.
Este nivel, en resumen, representa una plantilla de un cuestionario dinmico. El
trmino dinmico se refiere a que el cuestionario cambia segn las preguntas
respondidas anteriormente.
7.2.2. Nivel 2. Estudio de Viabilidad

En este nivel se encuentran las entidades que modelan el estudio de viabilidad
propiamente dicho: los proyectos, las evaluaciones realizadas para dichos
proyectos. Debido a que las evaluaciones se realizan por medio de un
cuestionario, este nivel es dependiente del anterior. Cada evaluacin es una
instancia de una plantilla de cuestionario, cuyas preguntas son respondidas con
algn valor de respuesta admitido y cuya secuencia est determinada por dichos
valores.
A continuacin se presenta en la Figura A1.34 un grfico esquemtico que
permite relacionar los dos niveles de la capa de dominio:
Figura A1.34. Ejemplo de los dos niveles existentes en la capa de dominio
Pg. 63

Directores
Alumnos
Pablo Damin MNDEZ
En el ejemplo presentado en la Figura A1.34 puede verse que el Nivel 1

implementa un Grafo dirigido no cerrado que permite recorrer todas las opciones
del cuestionario comenzando desde la pregunta uno y finalizando en la pregunta
6 o en la pregunta 4. No es necesario que el cuestionario finalice siempre en la
misma pregunta, ya que una pregunta del cuestionario es la ltima cuando posee
menos del total de opciones de aristas dirigidas hacia otras preguntas (vrtices).
En el ejemplo si se llega a la pregunta 6, el cuestionario finaliza porque no existe
arista que conduzca hacia otra pregunta. Por otra parte, si se llega a la pregunta 4
y se contesta no, el cuestionario tambin finaliza ya que no existe arista con ese
valor que conduzca a una prxima pregunta. Si llegando a la pregunta cuatro se
contestara "s" entonces el cuestionario si continuara porque existe un arista con
dicho valor que conduce de la pregunta 4 a la pregunta 5.
Observando ahora el nivel 1 se observa una instancia del cuestionario que ha sido
respondida y, por ende posee slo un camino lineal.
Al comenzar el cuestionario el usuario contest con el valor "no" la pregunta 1,
con lo cual el grafo lo llev a la pregunta 2. En este caso contexto con el valor "s",
pasando entonces a la pregunta 3. Siguiendo la secuencia el cuestionario finaliza
cuando el usuario llega a la pregunta 6 y la responde.
Como puede verse esta tcnica de grafos permite una gran flexibilidad al
momento de disear los cuestionarios.
7.2.3. Diagrama de Clases

Se ha presentado anteriormente una explicacin coloquial del diseo del modelo
en dos niveles. En esta seccin se presentar el modelo de software elegido para
implementarlo, a travs de un diagrama de clases UML que se muestra en la
Figura A1.35:
Pg. 64

Directores
Alumnos
Pablo Damin MNDEZ
cd Modelo
User
Provisto por el User

API de Appengine
+
1 +
email: Text
1
nickname: Text
1
+
+
+
all(Evaluator[])
remove(string)
userIsEvaluator(var)
Ev aluation
Proj ectMember
Ev aluator
evaluator: db.UserProperty
db.Model
db.Model
db.Model
+
+
* +
+
+
+
+
+
idproject: db.ReferenceProperty(Project)
member: db.UserProperty
role: db.TextProperty()
1
db.Model
1
evaluations
Proj ect
+
+
+
+
+
createdate: db.DateTimeProperty
description: db.TextProperty
owner: db.UserProperty
releasedate: db.DateTimeProperty
testdate: db.DateT imeProperty
+
+
+
+
+
+
addEvaluation(string, Evaluation)
addMember(string, string)
currentUserIsMember()
getEvaluations() : Evaluation[]
removeMember(string, string)
userIsMember(string)
+
+
* +
+
+
actualresult: db.IntegerProperty
createdate: db.DateTimeProperty
description: db.T extProperty
idproject: db.ReferenceProperty(Project)
owner: db.UserProperty
calculate() : Result
isComplete() : bool
lastQuestion() : Question
nextQuestion() : Question
questions() : Question[]
questions
1
Evaluation Result
*
1
db.Model
Ev aluationInstance
Nivel 2. Estudio de
Viabilidad
Result
+
+
+
+
+
+
+
+
+

dimension: db.TextProperty
idanswer: db.IntegerProperty
idevaluation: db.ReferenceProperty(Evaluation)
idinstance: db.IntegerProperty
idquestion: db.IntegerProperty
thresholdvalue: db.TextProperty
type: db.TextProperty
weight: db.IntegerProperty
+
+
answerText(var)
dimensionT ext(var)
+
+
+
+
+
+
adaptabilidad: array[4]
completo: bool
exito: array[4]
justificacion: array[4]
plausibidad: array[4]
resultado: array[4]
+
+
+
+
+
A() : float
E() : float
J() : float
P() : float
viability(var)
1
1
db.Model
db.Model
+
+
db.Model
NextQuestion
Answ er
description: db.TextProperty
1
+
+
1 +
+
+
+
idnextquestion: db.IntegerProperty
answer() : Answer
nextQuestion() : Question
question() : Question
Question
+
+
+
1
+
+
+
+
+
+
+
Nivel 1. Questionario
category: db.T extProperty

dimension: db.TextProperty
thresholdvalue: db.TextProperty
type: db.TextProperty
weight: db.IntegerProperty
dimensionT ext()
nextQuestions() : q:Question[]
validAnswers() : a: Answer[]
Figura A1.35. Diagrama de clases del paquete dbmodel
El Nivel 1 del modelo est implementado por las siguientes clases:

Question: implementa la pregunta con todos sus atributos (identificador de
pregunta, categora de la metodologa P3TQ, texto de la pregunta, dimensin
de la viabilidad, umbral, tipo y peso). El tipo de pregunta permite conocer
cules son las posibles respuestas admitidas. Por ejemplo el tipo booleano
solamente admitir a valores si y no. Mientras que el tipo difuso
admitir los valores "ninguno", "muy poco", "medio", "alto", "muy alto". Esta
clase representa, entonces, los vrtices del grafo.
Pg. 65

Directores
Alumnos
Pablo Damin MNDEZ
NextQuestion: implementa la relacin existente entre una pregunta del

cuestionario y la siguiente. La clase posee tres atributos que son el
identificador de la pregunta respondida, el valor de respuesta de dicha
pregunta y el identificador de la prxima pregunta en el cuestionario. Con
estos tres atributos puede conocerse cul es la prxima pregunta del
cuestionario a partir de la pregunta actual y la respuesta. Esta clase representa,
entonces, las aristas del grafo.
Answer: implementa los tipos de respuesta que se admiten en las preguntas
del cuestionario. Posee solamente dos atributos (identificador la respuesta y
descripcin).
El Nivel 2 del modelo est implementado por las siguientes clases:

EvaluationInstance: Implementa una pregunta del cuestionario respondida
para una evaluacin determinada. Esta clase se encarga de copiar toda
informacin de la pregunta que instancia y el valor de respuesta que el
usuario haya ingresado.
Evaluation: implementa una evaluacin completa realizada por un usuario.
Sus atributos son el creador de la evaluacin, la fecha de creacin, su
descripcin y su estado actual. La evaluacin permanece abierta mientras no
se haya alcanzado una ltima pregunta de cuestionario; y se encuentra cerrada
en caso contrario, pudindose conocer el resultado del evaluacin. Esta clase
se encarga de obtener la secuencia de preguntas del cuestionario consumiendo
las clases del nivel 1. Cuando el cuestionario finaliza posee una operacin
calculate() que permite conocer el resultado del evaluacin de viabilidad.
Result: Esta clase encapsula el resultado de un estudio de viabilidad, obtenido
a partir de una evaluacin completa. Posee cinco atributos correspondientes a
los cuatro sectores de las dimensiones del estudio de viabilidad, ms el vector
resultado final.
Project: esta clase implementa un proyecto en el cual su creador y
colaboradores crearn evaluaciones para estimar su viabilidad. Sus atributos
son su identificador, su usuario propietario (lder de proyecto), sus miembros
colaboradores (implementado a travs de la clase ProjectMember), su
descripcin y su fecha de creacin.
Evaluator: implementa los usuarios que tienen la capacidad de modificar los
atributos del cuestionario de evaluacin. Posee una operacin de clase llamada
all(), que permite obtener una coleccin de todos los usuarios con rol de
evaluador y una operacin llamada userIsEvaluator() que permite conocer,
Pg. 66

Directores
Alumnos
Pablo Damin MNDEZ
dada una direccin de correo electrnico, si un usuario posee el rol de

evaluador o no.
7.3. View. Paquete de soporte para vista.

Las clases pertenecientes a este paquete, que se muestran en la Figura A1.36,
tienen la responsabilidad de generar contenidos para la interfaz de usuario.
cd v iew
db.Model
Logical Model::Ev aluator
object
Ev aluationDraw
+
+
+
+
accepted: bool = 60
draw: bool
evaluation: Evaluation
maxsize: int = 100
+
+
+
+
+
+
+
+
+
createArray(Evaluation[]) : EvaluationDraw[]
drawA() : string
drawBar(int) : string
drawE() : string
drawJ() : string
drawP() : string
drawViability() : string
getEvaluation() : Evaluation
setEvaluation(Evaluation)
evaluator: db.UserProperty
+
+
+
all(Evaluator[])
remove(string)
userIsEvaluator(var)
Logical Model::
User
1 +
+
email: Text
nickname: Text
object
CustomMenu
+
getCustomMenu() : string
Figura A1.36. Diagrama de clases del paquete view
EvaluationDraw: Esta clase tienen la responsabilidad de generar un grfico

de barras en cdigo HTML de cada una de las dimensiones de una evaluacin,
desacoplando la responsabilidad de dibujo en la clase de dominio. Almacena
un objeto de la clase Evaluation (atributo evaluation), el tamao mximo de
escala (atributo maxsize). Existe una operacin de clase que funciona como
factory para crear una coleccin de objetos EvaluationDraw a partir de una
coleccin de objetos Evaluation. El motor de renderizacin de la vista (django),
entonces, utiliza objetos EvaluationDraw, con los cuales puede acceder a toda
la informacin de una evaluacin y, adems, podr dibujar grfico de barras
con dicho informacin. Las operaciones de dibujo son DrawBar, que permite
dibujar un grfico de barras genrico, a partir de un valor resultado entre cero
y 10. Las operaciones drawP, drawA, drawJ, drawE y drawViability permiten
dibujar grfico de barras para las dimensiones de plausibilidad a,
adaptabilidad, justificacin, xito y el resultado final de viabilidad
respectivamente.
Pg. 67

Directores
Alumnos
Pablo Damin MNDEZ
CustomMenu: esta clase tiene la responsabilidad de generar una coleccin de

opciones del men de usuario segn el rol que posea el usuario est
ejecutando la aplicacin. Para esto, verifica si el usuario es administrador y/o
evaluador y devuelve en la coleccin opciones especficas para estos roles. El
motor de renderizacin de la vista recibe siempre una coleccin de opciones
que le permite mostrar la funcionalidad especfica por rol.
7.4. Paquetes de Controladores

Como se explic anteriormente, todos los controladores implementan la interfaz
de webapp.RequestHandler, la cual posee las siguientes operaciones:
get(): permite procesar un pedido GET del protocolo http.
put(): permite procesar un pedido PUT del protocolo http.
redirect(): permite redireccionar a un nuevo enlace el cliente http.
Para poder procesar los predios de un cliente cuenta con los siguientes atributos:
request: este objeto encapsula la informacin de solicitud de un cliente,
fundamentalmente toda las variables y sus valores enviados.
response: este objeto permite que el controlador escriba los resultados del
proceso, generalmente en formato HTML.
A continuacin se presentan los diagramas de clase de cada uno de los paquetes
que conforman los controladores de la aplicacin.
7.4.1. evaluatorform
La Figura A1.37 muestra las clases que componen este paquete.
Pg. 68

Directores
Alumnos
Pablo Damin MNDEZ
pd ev aluatorform
Logical Model::
w ebapp.
RequestHandler
+
+
request:
response:
+
+
+
get() : void
put() : void
redirect(string) : void
AddMemberPage
+
+
+
v iew _proj ect.html
get() : void
put() : void
MainPage
+
+
+
get() : void
put() : void
error.html
ev aluatorform.html
Ev aluate
+
+
+
get() : void
put() : void
ev aluate.html
Figura A1.37. Diagrama de clases del paquete evaluatorform
Las clases de este paquete son:

AddMemberPage: esta clase tiene la responsabilidad de agregar o eliminar a
un colaborador del proyecto.
MainPage: esta clase tiene la responsabilidad de recibir las respuestas de cada
pregunta del cuestionario de evaluacin, a guardar las y presentarle al usuario
la prxima pregunta a responder.
Evaluate: esta clase tiene la responsabilidad de presentarle al usuario el
resultado de un estudio de viabilidad para una evaluacin finalizada.
7.4.2. Add Evaluator

Pg. 69

Directores
Alumnos
Pablo Damin MNDEZ
cd add_ev aluator
w ebapp.
RequestHandler
+
+
request:
response:
+
+
+
get() : void
put() : void
webapp.RequestHandler
MainPage
+
+
+
get() : void
put() : void
error.html
add_ev aluator.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 evaluacin de
proyectos.
7.4.3. Choose_project
Pg. 70

Directores
Alumnos
Pablo Damin MNDEZ
cd choose_proj ect
w ebapp.
RequestHandler
+
+
request:
response:
+
+
+
get() : void
put() : void
MainPage
+
+
+
get() : void
put() : void
choose_proj ect.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 presentrselos al usuario para que este seleccione uno.
En caso de que el usuario de es crear un nuevo proyecto esta clase se encarga
de hacer persistente este nuevo proyecto en el sistema.
Pg. 71

Directores
Alumnos
Pablo Damin MNDEZ
7.4.4. Help
cd help
w ebapp.
RequestHandler
+
+
request:
response:
+
+
+
get() : void
put() : void
LogoutPage
AboutPage
LoginPage
+
+
+
get() : void
put() : void
+
+
+
get() : void
put() : void
about.html
logout.html
+
+
+
get() : void
put() : void
login.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 sesin en caso de que los datos de ingreso se han correctos.
LogoutPage: esta clase tiene la responsabilidad de cerrar la sesin de un
usuario.
Pg. 72

Directores
Alumnos
Pablo Damin MNDEZ
7.4.5. View_project
cd v iew _proj ect
w ebapp.
RequestHandler
+
+
request:
response:
+
+
+
get() : void
put() : void
MainPage
+
+
+
v iew _proj ect.csv
get() : void
put() : void
v iew _proj ect.html
Figura A1.41. Diagrama de clases del paquete view_project

MaintPage: esta clase tiene la responsabilidad de recuperar y mostrar al
usuario toda la informacin de un proyecto y de crear nuevas evaluaciones.
Pg. 73

Directores
Alumnos
Pablo Damin MNDEZ
7.5. Diagramas de Secuencia

A continuacin se presentan los diagramas de secuencia que permiten
comprender cmo colaboran las clases de las distintas categoras (modelo, pista,
controlador e infraestructura) para resolver la funcionalidad requerida.
Se han incluido aquellas secuencias que se consideran fundamentales para el
sistema. Las restantes se resuelven de manera anloga a las presentadas o son
muy simples de implementar por lo cual su representacin grfica no agrega
valor.
Adems del diagrama se describirn brevemente los escenarios dentro de los
cuales transcurre cada secuencia.
7.5.1. Crear Proyecto

Escenario: El usuario ha iniciado sesin en el sistema. Se encuentra frente a la

pantalla de seleccin de proyectos y desea crear un nuevo proyecto,
completando una descripcin para el mismo y enviando el formulario. Se
considera que no ocurren errores o excepciones. A continuacin se presenta en
la Figura A1.42 el diagrama de secuencia.
sd Crear Proyecto
users
Usuario
choose_project
view_project::
MainPage
view_project
POST(description)
post(description)
user:= get_current_user
project:= <<new>> description, user
Logical
Model::Project
put()
render(project)
render
Figura A1.42. Diagrama de secuencia Crear proyecto.
Pg. 74

Directores
Alumnos
Pablo Damin MNDEZ
7.5.2. Crear Evaluacin

Escenario: El usuario ha iniciado sesin en el sistema y ha seleccionado un

proyecto. Se encuentra frente a la pantalla de consulta de dicho proyecto y
desea agregar una nueva evaluacin, ingresando, para ello, una descripcin
para la nueva evaluacin y enviando el formulario. Se considera que no
ocurren errores o excepciones. A continuacin se presenta en la Figura A1.43
el diagrama de secuencia.
sd Crear Ev aluacion
users
Miembro
view_project
evaluatorform::evaluate
run
POST(create,idproject,description)
post(create,idproject,description)
user:= get_current_user
eval:= <<new>>(idproject,user,description)
Logical
Model::Evaluation
put()
q:= questions()
nq:= nextQuestion()
render(idproject,eval,q,nq)
render
Figura A1.43. Diagrama de secuencia Crear evaluacin.
7.5.3. Contestar Pregunta

Escenario: El usuario ha iniciado sesin en el sistema, ha seleccionado un

proyecto y ha creado una nueva evaluacin para el mismo, o retomado una
evaluacin previamente creada y an no completada. Se encuentra frente a la
pantalla de ejecucin de la evaluacin y desea completar la siguiente pregunta
del cuestionario. Selecciona entonces la respuesta que considera correcta y
enva el formulario. Se considera que no ocurren errores o excepciones. A
continuacin se presenta en la Figura A1.44 el diagrama de secuencia.
Pg. 75

Directores
Alumnos
Pablo Damin MNDEZ
sd Contestar Pregunta
db
Miembro
run
eval :Evaluation
evaluatorform::
evaluate
POST(idevaluation,idanswer)
post(idevaluation,idanswer)
eval:= get(idevaluation)
nq:= nextQuestion()
ev :EvaluationInstance
ev:= <<new>> (idanswer, eval, nq.weight, nq.dimension)
put()
q:= questions()
Si la evaluacin
est completa.
nq2:= nextQuestion()
idproject:= idproject
[eval.isComplete==false]: render(idproject,eval,nq2,q)
render
Figura A1.44. Diagrama de secuencia contestar pregunta.
7.5.4. Calcular Evaluacin

Escenario: El usuario ha iniciado sesin en el sistema, ha seleccionado un

proyecto y ha seleccionado una evaluacin completa, o retomado una
evaluacin previamente creada y an no completada. Se encuentra frente a la
pantalla de ejecucin de la evaluacin y desea completar la siguiente pregunta
del cuestionario. Selecciona entonces la respuesta que considera correcta y
enva el formulario. Se considera que no ocurren errores o excepciones. A
continuacin se presenta en la Figura A1.45 el diagrama de secuencia.
sd Calcular Ev aluacin
eval :Evaluation
Miembro
evaluate
evaluatorform::
evaluate
[eval.isComplete]: result:= calculate()
render(eval,q,result)
Si la evaluacin
est completa.
render
Figura A1.45. Diagrama de secuencia Calcular Evaluacin.
Pg. 76

Directores
Alumnos
Pablo Damin MNDEZ
7.6. Secuencia entre Pantallas

Las pantallas del sistema han sido presentadas separadamente en cada uno de los
diagramas de clase del controlador.
El diagrama que se muestra a continuacin la Figura A1.46 permite ver, a travs
de un diagrama de estados UML, como se relacionan entre s a partir de la
interaccin del usuario con el sistema.
sm Statecharts
abrir sesin
clear
Logout
login
edit
cerrar sesin
Inicializar plantilla de evaluacin

editar plantilla de evaluacin
choose_proj ect
creacin de un proyecto
agregar evaluador (usuario administrador)

ayuda
add_ev aluator
seleccin de un proyecto
about
v iew _proj ect
nueva evaluacin
run
carga de pregunta del cuestionario
ejecucin de evaluacin
agregado de nuevo colaborador
seleccin de evaluacin finalizada
evaluacin completa
ev aluate
Figura A1.46. Diagrama de estados para la transicin entre las pantallas del sistema.
A continuacin se presentan cada una de las pantallas que componen el sistema, y

las interfaces con el usuario.
7.6.1. Logout
Esta pantalla, mostrada en la Figura A1.47, se presenta cuando el usuario desea
ingresar al sistema y an no sea autenticado, o cuando decide salir, cerrando la
sesin.
Pg. 77

Directores
Alumnos
Pablo Damin MNDEZ
Figura A1.47. Pantalla Logout.
7.6.2. Login
Esta pantalla, mostrada en la Figura A1.48, es provista por el API user del
appengine, para que el usuario pueda autenticar se en el tenga a travs de su email y contrasea.
Figura A1.48. Pantalla Login.
7.6.3. Choose Project

Esta pantalla, mostrada en la Figura A1.49, presenta al usuario una tabla con los
proyectos existentes en el sistema, mostrando la fecha de creacin, la descripcin,
el e-mail del lder del proyecto, la cantidad de evaluaciones realizadas y el rol que
tiene el usuario en dicho proyecto. El usuario puede elegir cualquiera de los
proyectos para consultar la informacin existente. Tambin presenta una interfaz
para que el usuario pueda crear un nuevo proyecto ingresando un nombre para el
mismo.
Figura A1.49. Pantalla Choose Project.
7.6.4. View Project

Esta pantalla, mostrada en la Figura A1.50 presenta al usuario toda la
informacin referente a un proyecto que l ha seleccionado. Muestra la
informacin de fecha de creacin, lder de proyecto, colaboradores y evaluaciones
realizadas. Para estas ltimas muestra la fecha de creacin, descripcin, autor y, si
Pg. 78

Directores
Alumnos
Pablo Damin MNDEZ
han sido finalizadas, el resultado. Tambin provee interfaces para crear una nueva
evaluacin en dicho proyecto, agregar colaboradores al proyecto en caso de que el
usuario sea el lder y opciones para exportar la informacin o imprimir.
Figura A1.50. Pantalla View Project.
7.6.5. Run
Esta pantalla, mostrada en la Figura A1.51, le presenta al usuario una interfaz
para que pueda completar el cuestionario de evaluacin. Muestra el nombre
proyecto, el nombre de la evaluacin, la dimensin, peso y descripcin de la
pregunta y las opciones de respuesta.
Figura A1.51. Pantalla run.
Pg. 79

Directores
Alumnos
Pablo Damin MNDEZ
7.6.6. Evaluate
Esta pantalla, presentada en la Figura A1.52, se muestra cuando el usuario
miembro del proyecto selecciona una evaluacin finalizada, o cuando contesta la
ltima pregunta del cuestionario. Presenta el resultado del estudio de viabilidad
mostrando los valores de los vectores justificacin, adaptabilidad, plausibilidad,
xito y viabilidad y tambin el mdulo de cada uno de ellos numrica y
grficamente. Para permitir trazabilidad presenta cada una de las preguntas
respondidas y las respuestas ingresadas. Provee interfaces para que el usuario
pueda exportar o imprimir la informacin.
Figura A1.52. Pantalla evaluate.
7.6.7. Add Evaluator

Esta pantalla, mostrada en la Figura A1.53, le presenta al usuario administrador
del sistema una lista con los e-mail de todos los usuarios evaluadores del sistema.
Provee interfaces que permiten agregar nuevos usuarios evaluadores, eliminar de
la lista usuarios existentes e imprimir la informacin.
Figura A1.53. Pantalla add evaluator.

Pg. 80

Directores
Alumnos
Pablo Damin MNDEZ
7.6.8. edit
Esta pantalla, mostrada en la Figura A1.54, le presenta al usuario evaluador una
interfaz que le permite modificar la plantilla de evaluacin de proyectos. Muestra
la informacin de cada preguntas del cuestionario, que puede ser modificada y
enlaces que dirigen a la prxima pregunta segn el valor de respuesta.
Figura A1.54. Pantalla edit.
7.6.9. About
Esta pantalla, mostrada la Figura A1.55, le presenta al usuario en manual de
ayuda, y la informacin sobre la versin en ejecucin del sistema.
Figura A1.55. Pantalla About.
7.6.10.
Data
Esta pantalla, mostrada en la Figura A1.56, le presenta al usuario administrador

una interfaz para confirmar si desea eliminar toda la informacin del sistema de
inicializar la plantilla de evaluacin de proyectos.
Pg. 81

Directores
Alumnos
Pablo Damin MNDEZ
Figura A1.56. Pantalla data.
7.6.11.
Barra de Men
La barra de men, mostrada en la Figura A1.57, le permite al usuario seleccionar

las opciones del sistema. Se encuentra ubicada en la zona superior de cada una de
las pantallas presentadas anteriormente.
Figuras 57. Men del Sistema.
Las acciones que pueden realizarse con el men son:

Proyectos: conduce a cualquier usuario que inici sesin en el sistema a la
pantalla choose project.
Cuestionario: solamente visible por los usuarios con el rol de evaluadores.
Conduce al usuario a la pantalla edit.
Evaluadores: solamente visible por el administrador de sistema. Conduce a la
pantalla add evaluator.
Inicializar: solamente visible por el administrador de sistema. Conduce a la
pantalla clear.
Ayuda: conduce a cualquier usuario que inici sesin en el sistema a la
pantalla about.
Salir: conduce a cualquier usuario que inici sesin en el sistema a la pantalla
logout.
7.7. Diagrama de Despliegue

El despliegue de la aplicacin es muy simple, como puede verse en la Figura
A1.58, ya que consiste en un servidor appengine (de google o local) conteniendo
todo los componentes.
En el modelo de appengine existe una correspondencia uno a uno entre
componente y paquete. Por lo cual, el nodo servidor contendr todos los paquetes
(componentes) presentados anteriormente en este documento.
Pg. 82

Directores
Alumnos
Pablo Damin MNDEZ
El cliente se comunica con el servidor a travs de un navegador web, utilizando el

protocolo http.
dd Despliegue
dbmodel
data
v iew _proj ect
choose_proj ect
appengine
Serv er
help
ev aluatorform
v iew
http
menu
cliente
(w ebbrow ser)
Figura A1.58. Diagrama de Despliegue.
Pg. 83

Directores
Alumnos
Pablo Damin MNDEZ
8. Casos de Prueba
En esta seccin se desarrollan los casos de prueba planificados y ejecutados
satisfactoriamente que surgen de los escenarios ms importantes de cada caso de
uso.
8.1. Validar Usuario

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

La Figura A1.59 nuestra el caso de prueba inicio de sesin exitoso.
Identificacin
CP-001 : Inicio de sesin exitoso
Caso de Uso CU-001

que lo origina
Escenario
El usuario intenta iniciar sesin en el sistema.
Datos
Entrada
de El usuario ingresa un e-mail y contrasea vlidos (cuentas

activas en google)
Resultado
Esperado
Estado
El usuario inicia sesin el sistema.

Ejecutado correctamente.
Figura A1.59. Caso de prueba inicio de sesin exitoso
8.1.2. Inicio de sesin fallido

La Figura A1.60 nuestra el caso de prueba inicio de sesin fallido.
Identificacin
CP-002: Inicio de sesin fallido
Caso de Uso CU-001

que lo origina
Escenario
El usuario intenta iniciar sesin en el sistema.
Datos
Entrada
de El usuario ingresa las siguientes combinaciones de e-mail y

contrasea:
E-mail vlido y contrasea invlida.
E-mail y contrasea invlidas.
E-mail invlido y contrasea de algn usuario
vlido.
E-mail y contrasea nulos.
Pg. 84

Directores
Alumnos
Pablo Damin MNDEZ

Resultado
Esperado
Estado
E-mail nulo y contrasea correcta.

E-mail vlido y contrasea nula.
El sistema notifica error en el inicio de sesin.

Figura A1.60. Caso de prueba inicio de sesin 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.
Identificacin
CP-003 : Administrador agrega nuevo evaluador
Caso de Uso CU-002

que lo origina
Escenario
El administrador accede a la pantalla para agregar un nuevo
usuario evaluador.
Datos
Entrada
de El administrador ingresa un e-mail vlido (cuenta activa en

google)
Resultado
Esperado
Estado
El usuario evaluador queda registrado en el sistema.

Figura A1.61. Caso de prueba Administrador agrega nuevo evaluador
8.2.2. Administrador intenta agregar evaluador registrado

La Figura A1.62 nuestra el caso de prueba Administrador intenta agregar
evaluador registrado.
Identificacin
CP-004 : Administrador intenta agregar evaluador registrado
Caso de Uso CU-002

que lo origina
Escenario
El administrador accede a la pantalla para agregar un
usuario evaluador, que ya fue registrado previamente en el
sistema.
Datos
de El administrador ingresa un e-mail vlido, que ya fue
Pg. 85

Directores
Alumnos
Pablo Damin MNDEZ
Entrada
registrado previamente (cuenta activa en google)
Resultado
Esperado
Estado
El sistema notifica que el e-mail ya ha sido registrado.

Figura A1.62. Caso de prueba Administrador intenta agregar evaluador registrado
8.2.3. Administrador intenta agregar evaluador con e-mail nulo

La Figura A1.63 nuestra el caso de prueba Administrador intenta agregar
evaluador con e-mail nulo.
Identificacin
CP-005 : Administrador intenta agregar evaluador con e-mail

nulo
Caso de Uso CU-002

que lo origina
Escenario
El administrador accede a la pantalla para agregar un nuevo
usuario evaluador.
Datos
Entrada
Resultado
Esperado
de El administrador enva el formulario sin ingresar un e-mail

El sistema notifica que el e-mail no es vlido, debido a que es
nulo.
Estado
Figura A1.63. Caso de prueba Administrador intenta agregar evaluador con e-mail nulo
8.2.4. Usuario intenta agregar evaluador

La Figura A1.64 nuestra el caso de prueba Usuario intenta agregar evaluador.
Identificacin
CP-006 : Usuario intenta agregar evaluador
Caso de Uso CU-002

que lo origina
Escenario
Un usuario, que no cuenta con el rol de administrador,
accede a la pantalla para agregar un nuevo usuario
evaluador.
Datos
Entrada
Resultado
Esperado
Estado
de Ninguno
El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la accin.
Figura A1.64. Caso de prueba Usuario intenta agregar evaluador
Pg. 86

Directores
Alumnos
Pablo Damin MNDEZ
8.3. Actualizar planilla de evaluacin

escenarios del caso de uso CU-003 : Actualizar planilla de evaluacin.
8.3.1. Evaluador actualiza pregunta

La Figura A1.65 nuestra el caso de prueba Evaluador actualiza pregunta.
Identificacin
CP-007 : Evaluador actualiza pregunta
Caso de Uso CU-003

que lo origina
Escenario
Un usuario evaluador accede a la pantalla modificar las
preguntas del cuestionario de la plantilla de evaluacin.
Datos
Entrada
de El usuario evaluador modifica los siguientes datos de las

preguntas:
modifica el texto de la Descripcin
modifica el peso (valor entero entre 0 y 10)
modifica la dimensin
Resultado
Esperado
El sistema actualiza los datos de la pregunta y notifica al

usuario.
Estado
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.
Identificacin
CP-008 : Evaluador intenta actualizar pregunta con datos

incorrectos
Caso de Uso CU-003

que lo origina
Escenario
Un usuario evaluador accede a la pantalla modificar las
preguntas del cuestionario de la plantilla de evaluacin.
Datos
Entrada
Resultado
Esperado
de El usuario evaluador modifica los datos de las preguntas,

con cada uno de los valores enunciados a continuacin :
descripcin nula
peso incorrecto (mayor a 10 y/o alfanumrico)
El sistema y notifica al usuario que los datos ingresados son
incorrectos.
Pg. 87

Directores
Alumnos
Pablo Damin MNDEZ
Estado
Figura A1.66. Caso de prueba Evaluador intenta actualizar pregunta con datos incorrectos
8.3.3. Usuario intenta actualizar pregunta

La Figura A1.67 nuestra el caso de prueba Usuario intenta actualizar pregunta.
Identificacin
CP-009 : Usuario intenta actualizar pregunta
Caso de Uso CU-003

que lo origina
Escenario
Un usuario, que no cuenta con el rol de evaluador, accede a
la pantalla para modificar las preguntas del cuestionario de
la plantilla de evaluacin.
Datos
Entrada
Resultado
Esperado
de Ninguno
Estado
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.
Identificacin
CP-010 : Proyecto altamente viable
Caso de Uso CU-004

que lo origina
Escenario
Un miembro del proyecto accede a la pantalla que permite
continuar la ejecucin de una evaluacin creada por l.
Datos
Entrada
Resultado
Esperado
de
El miembro del proyecto contesta Si o Todo (Si) en

cada una de las preguntas.
El sistema muestra como resultado de viabilidad:

Vector Justificacin = (10;10;10;10)
Resultado Justificacin = 10
Vector xito = (10;10;10;10)
Resultado xito = 10
Vector adaptabilidad = (10;10;10;10)
Pg. 88

Directores
Alumnos
Pablo Damin MNDEZ

Estado
Resultado adaptabilidad = 10
Vector plausibilidad = (10;10;10;10)
Resultado plausibilidad = 10
Vector Viabilidad = (10;10;10;10)
Resultado viabilidad = 10
Figura A1.68. Caso de prueba Proyecto altamente viable
8.4.2. Proyecto no viable rotundamente

La Figura A1.69 nuestra el caso de prueba Proyecto no viable rotundamente.
Identificacin
CP-011 : Proyecto no viable rotundamente
Caso de Uso CU-004

que lo origina
Escenario
Datos
Entrada
de El miembro del proyecto contesta las preguntas con los

valores indicados a continuacin:
Las partes interesadas estn identificadas? Las
partes interesadas son aquellas personas o grupos
de personas que afectan o pueden ser afectadas por
el proyecto. Boxes de referencia de la metodologa
P3TQ: DB1, AB2, AB3 Mucho
Todas las partes interesadas cuentan con la
disponibilidad de tiempo para avocarse al proyecto?
Boxes de referencia de la metodologa P3TQ: DB1,
AB2, AB3: Mucho
Existen partes interesadas con autoridad suficiente

dentro de la organizacin para liderar el proyecto

de explotacin? Boxes de referencia de la
metodologa P3TQ: DB1, AB2, AB3 Poco
Existen partes interesadas con recursos econmicos
suficientes para encarar el proyecto? Boxes de
Poco
El proyecto de explotacin tiene como propsito
buscar relaciones de inters? No
El proyecto de explotacin tiene como propsito la
Pg. 89

Directores
Alumnos
Pablo Damin MNDEZ
evaluacin de una situacin de negocio? (anlisis de

Si

Con respecto a la problemtica del negocio del

proyecto original: Se han encontrado datos de
utilidad para llevar a cabo la minera? El proyecto
original es aquel que origina el proyecto de
explotacin que se est evaluando. Boxes de
referencia de la metodologa P P3TQ: AB6 Poco
Las partes interesadas han identificado o pueden
identificar aquellas caractersticas del negocio
importantes, que enmarcan sus expectativas del
proyecto de explotacin? Boxes de referencia de la
metodologa P3TQ: TB7 No
La situacin del negocio est enmarcada o puede
enmarcarse en un modelo a partir de los datos
conocidos? Boxes de referencia de la metodologa
P3TQ: AB6
Poco
Los Objetivos y Metas del negocio estn definidos o
pueden definirse? Boxes de referencia de la
metodologa P3TQ: AB6, TB5 Poco
Se requiere inicialmente un anlisis estratgico para
planificar escenarios corporativos? Si
P3TQ: AB9
Poco
Existe un mapa del escenario estratgico,
consensuado con las partes interesadas. .Boxes de
referencia de la metodologa P3TQ: AB12 No
Estn identificadas por las partes interesadas las
relaciones entre las cinco temticas clave del
negocio(producto,
lugar,
precio,
tiempo
y
cantidad)? Boxes de referencia de la metodologa
P3TQ: AB12
No
Puede establecerse correspondencia entre el mapa y
las relaciones P3TQ? Boxes de referencia de la
No
Pg. 90

Directores
Alumnos
Pablo Damin MNDEZ
Existen o pueden realizarse simulaciones que

permitan identificar ambigedades, incertezas,
discordancias? Boxes de referencia de la
No
Estn caracterizadas o pueden caracterizarse las
relaciones clave del sistema? Boxes de referencia de
la metodologa P3TQ: AB12 No
Esta determinado o puede determinarse cuales de
los 26 recursos de gestin (Consultar la tabla 7.2 de
MII de P3TQ) son adecuados a cada potencial parte
interesada? Boxes de referencia de la metodologa
P3TQ: AB12, MII Tabla 7.1
Poco
Existe o puede obtenerse un set de datos sin
errores? Boxes de referencia de la metodologa
P3TQ: DB9.1
No
El set de datos obtenidos esta referenciado al caso
de negocio a estudiar? Boxes de referencia de la
No
Existen variables con nico valor, o valores vacios
en sus instancias? Boxes de referencia de la
Mucho
Las variables categricas estn documentadas?
Poco
Los nombres de los atributos son acorde a los
conceptos del negocio? Boxes de referencia de la
Poco
Son reconocidas y es posible adecuar variables
anacrnicas? Boxes de referencia de la metodologa
P3TQ: DB9.4
No
Existen datos suficientes como para crear diez
modelos predictivos con once atributos cada uno
(siempre distintos) y generar un set de
entrenamiento y otro de testeo? Boxes de referencia
de la metodologa P3TQ: DB9.5, TB9.4
No
Se dispone de un experto para analizar y asegurar
que el set de datos representa los escenarios ms
Pg. 91

Directores
Alumnos
Pablo Damin MNDEZ

Resultado
Esperado
importantes que pueden ocurrir en el negocio?

No
Es necesario realizar recodificacin de variables
para mejor comprensin del modelo? Boxes de
referencia de la metodologa P3TQ: DB9.7 Si
Los conjuntos de variables de entrada y salida estn
caracterizadas? Boxes de referencia de la
Si
Los datos estn estructurados o pueden
estructurarse para aplicarlos en la herramienta de
minera elegida? Boxes de referencia de la
Poco
Estn seleccionados los algoritmos de minera
adecuados al modelo? Boxes de referencia de la
No
Existe una herramienta de minera adecuada al
modelo y est disponible? Boxes de referencia de la
No
De necesitarse comprar herramientas, existen
proveedores disponibles. .Boxes de referencia de la
Poco
Esta construido o puede construirse el MVCM
(Missing Value Check Model)? Boxes de referencia
de la metodologa P3TQ: AB11.1
No
El objetivo de la explotacin es entender una
situacin? No
El objetivo de la explotacin es aplicar una
clasificacin?
No
El objetivo de la explotacin es buscar una
prediccin?
No

Vector Justificacin = (1.20 ; 2.20 ; 3.40 ;2.80)
Resultado justificacin =2.80
Vector xito = (0.22 ; 0.33 ; 0.42 ; 0.27)
Resultado xito = 0.27
Vector adaptabilidad = (0.42 ; 0.57 ; 0.69 ; 0.49)
Pg. 92

Directores
Alumnos
Pablo Damin MNDEZ

Estado
Resultado adaptabilidad = 0.49

Vector plausibilidad = (1.18 ; 1.54 ; 1.83 ; 1.36)
Resultado plausibilidad = 1.36
Vector Viabilidad = (0.85 ; 1.19 ; 1.48 ; 1.02)
Resultado viabilidad = 1.02
Figura A1.69. Caso de prueba Proyecto no viable rotundamente
8.4.3. Proyecto no viable

La Figura A1.70 nuestra el caso de prueba Proyecto no.
Identificacin
CP-012 : Proyecto no viable
Caso de Uso CU-004

que lo origina
Escenario
Datos
Entrada

el proyecto..Boxes de referencia de la metodologa
P3TQ: DB1, AB2, AB3 Regular
AB2, AB3 Mucho


metodologa P3TQ: DB1, AB2, AB3 Mucho
Regular
buscar relaciones de inters? No
El proyecto de explotacin tiene como propsito la
Pg. 93

Directores
Alumnos
Pablo Damin MNDEZ
evaluacin de una situacin de negocio? (anlisis de

Si

Con respecto a la problemtica del negocio del

proyecto original: Se han encontrado datos de
utilidad para llevar a cabo la minera? El proyecto
original es aquel que origina el proyecto de
explotacin que se est evaluando..Boxes de
referencia de la metodologa P3TQ: AB6 Regular
Las partes interesadas han identificado o pueden
identificar aquellas caractersticas del negocio
importantes, que enmarcan sus expectativas del
proyecto de explotacin? Boxes de referencia de la
metodologa P3TQ: TB7 Si
P3TQ: AB6
Regular
Los Objetivos y Metas del negocio estn definidos o
pueden definirse? Boxes de referencia de la
metodologa P3TQ: AB6, TB5 Regular
planificar escenarios corporativos? Si
P3TQ: AB9
Regular
Existe un mapa del escenario estratgico,
consensuado con las partes interesadas. .Boxes de
referencia de la metodologa P3TQ: AB12 Si
Estn identificadas por las partes interesadas las
relaciones entre las cinco temticas clave del
negocio(producto,
lugar,
precio,
tiempo
y
cantidad)? Boxes de referencia de la metodologa
P3TQ: AB12
Si
Puede establecerse correspondencia entre el mapa y
las relaciones P3TQ? Boxes de referencia de la
Si
Pg. 94

Directores
Alumnos
Pablo Damin MNDEZ
Existen o pueden realizarse simulaciones que

permitan identificar ambigedades, incertezas,
discordancias? Boxes de referencia de la
No
Estn caracterizadas o pueden caracterizarse las
relaciones clave del sistema? Boxes de referencia de
la metodologa P3TQ: AB12 Si
Esta determinado o puede determinarse cuales de
los 26 recursos de gestin (Consultar la tabla 7.2 de
MII de P3TQ) son adecuados a cada potencial parte
interesada? Boxes de referencia de la metodologa
P3TQ: AB12, MII Tabla 7.1
Regular
P3TQ: DB9.1
Si
Si
Regular
Regular
Mucho
P3TQ: DB9.4
Si
Si
Pg. 95

Directores
Alumnos
Pablo Damin MNDEZ

Resultado
Esperado

Si
referencia de la metodologa P3TQ: DB9.7 No
Si
Regular
No
Si
Regular
No
situacin? No
El objetivo de la explotacin es aplicar una
clasificacin?
No
El objetivo de la explotacin es buscar una
prediccin?
No

Vector Justificacin = (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)
Pg. 96

Directores
Alumnos
Pablo Damin MNDEZ

Estado
Resultado adaptabilidad = 3.68

Vector plausibilidad = (2.77 ; 3.07 ; 3.43 ; 3.73)
Resultado plausibilidad = 3.25
Figura A1.70. Caso de prueba Proyecto no viable
8.4.4. Proyecto no viable por incumplimiento de situaciones esenciales

La Figura A1.71 nuestra el caso de prueba Proyecto no.
Identificacin
CP-013 : Proyecto no viable por incumplimiento de

situaciones esenciales
Caso de Uso CU-004

que lo origina
Escenario
Datos
Entrada

el proyecto..Boxes de referencia de la metodologa
AB2, AB3 Poco

metodologa P3TQ: DB1, AB2, AB3 Mucho
Mucho
buscar relaciones de inters? Si
Pg. 97

Directores
Alumnos
Pablo Damin MNDEZ

El proyecto original cuenta con el apoyo de la

organizacin? Boxes de referencia de la metodologa
El proyecto original cuenta con el apoyo de las
partes interesadas? Boxes de referencia de la
metodologa P3TQ: DB1, AB2, AB3 Todo (Si)
Existe comunicacin con las partes interesadas del
proyecto original? El proyecto original es aquel que
origina el proyecto de explotacin que se est
evaluando..Boxes de referencia de la metodologa
P3TQ: DB1, AB2, AB3 Todo (Si)
Se cumplieron los objetivos del proyecto original?
Mucho
planificar escenarios corporativos? No
P3TQ: DB9.1
Si
Si
Muy poco o nada
(No)
Mucho
Mucho
P3TQ: DB9.4
Si
Pg. 98

Directores
Alumnos
Pablo Damin MNDEZ


Si
Si
referencia de la metodologa P3TQ: DB9.7 No
Si
Mucho
Si
Si
Mucho
No
situacin? Si
Las variables utilizadas en el modelo estn
relacionadas con conceptos que son conocidos por
las partes interesadas? Boxes de referencia de la
metodologa P3TQ: AB11.1, DB11.5 Si
Los objetos del negocio que representan las
variables pueden ser utilizados por las partes
Pg. 99

Directores
Alumnos
Pablo Damin MNDEZ
interesadas, o gerentes para realizar mejoras en el

negocio. .Boxes de referencia de la metodologa
P3TQ: AB11.1, DB11,5 Mucho
Los datos son suficientes para definir las relaciones
explicativas? Boxes de referencia de la metodologa
P3TQ: AB11.1 DB11.5 Si
Resultado
Esperado

Vector Justificacin = (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
Figura A1.71. Caso de prueba Proyecto no viable por incumplimiento de situaciones esenciales
8.5. Crear evaluacin

escenarios del caso de uso CU-005 : Crear evaluacin.
8.5.1. Miembro del proyecto crea evaluacin

La Figura A1.72 nuestra el caso de prueba Miembro del proyecto crea evaluacin.
Identificacin
CP-011 : Miembro del proyecto crea evaluacin
Caso de Uso CU-005

que lo origina
Escenario
Un miembro
evaluacin.
Datos
Entrada
Resultado
Esperado
del
proyecto
intenta
crear
una
nueva
de El miembro del proyecto ingresa cualquiera de los siguientes

nombres:
Texto Alfanumrico
Texto nulo
El sistema crea una nueva evaluacin y redirige al usuario a
la pantalla de ejecucin de la evaluacin.
Pg. 100

Directores
Alumnos
Pablo Damin MNDEZ
Estado
Figura A1.72. Caso de prueba Miembro del proyecto crea evaluacin
8.5.2. Lder del proyecto crea evaluacin

La Figura A1.73 nuestra el caso de prueba Lder del proyecto crea evaluacin.
Identificacin
CP-012 : Lder del proyecto crea evaluacin
Caso de Uso CU-005

que lo origina
Escenario
El lder del proyecto intenta crear una nueva evaluacin.
Datos
Entrada
de El lder del proyecto ingresa cualquiera de los siguientes

nombres:
Texto Alfanumrico
Texto nulo
Resultado
Esperado
El sistema crea una nueva evaluacin y redirige al lder del

proyecto a la pantalla de ejecucin de la evaluacin.
Estado
Figura A1.73. Caso de prueba Lder del proyecto crea evaluacin
8.5.3. Usuario intenta crear evaluacin

La Figura A1.74 nuestra el caso de prueba Usuario intenta crear evaluacin.
Identificacin
CP-013 : Usuario intenta crear evaluacin
Caso de Uso CU-005

que lo origina
Escenario
Un usuario que no posee roles en un proyecto intenta crear
una evaluacin en l.
Datos
Entrada
Resultado
Esperado
Estado
de Ninguno
Figura A1.74. Caso de prueba Usuario intenta crear evaluacin
8.6. Consultar proyecto

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

Directores
Alumnos
Pablo Damin MNDEZ
8.6.1. Miembro consulta proyecto

La Figura A1.75 nuestra el caso de prueba Miembro consulta proyecto.
Identificacin
CP-014 : Miembro consulta proyecto
Caso de Uso CU-006

que lo origina
Escenario
Un miembro del proyecto (colaborador o lder) selecciona un
proyecto para consultarlo.
Datos
Entrada
de El usuario selecciona de la lista de proyectos uno al cual

pertenece.
Resultado
Esperado
El sistema le presenta al usuario la pantalla de informacin

del proyecto, que incluye los resultados de todas las
evaluaciones realizadas.
Estado
Figura A1.75. Caso de prueba Miembro consulta proyecto
8.6.2. Usuario intenta consultar proyecto

La Figura A1.76nuestra el caso de prueba Usuario intenta consultar proyecto.
Identificacin
CP-015 : Usuario intenta consultar proyecto
Caso de Uso CU-006

que lo origina
Escenario
Un usuario que no es miembro de un proyecto (ni
colaborador ni lder) selecciona ese proyecto para
consultarlo.
Datos
Entrada
de El usuario selecciona de la lista de proyectos uno al cual no

pertenece.
Resultado
Esperado

del proyecto, sin mostrar los resultados de las evaluaciones
realizadas.
Estado
Figura A1.76. Caso de prueba Usuario intenta consultar proyecto
8.7. Consultar Evaluacin

escenarios del caso de uso CU-007 : Consultar evaluacin.
Pg. 102

Directores
Alumnos
Pablo Damin MNDEZ
8.7.1. Miembro consulta evaluacin

La Figura A1.77 nuestra el caso de prueba Miembro consulta evaluacin.
Identificacin
CP-016 : Miembro consulta evaluacin
Caso de Uso CU-007

que lo origina
Escenario
Un miembro del proyecto (colaborador o lder) selecciona
una evaluacin de ese proyecto para consultarla.
Datos
Entrada
de El usuario selecciona una evaluacin de la lista de

evaluaciones del proyecto.
Resultado
Esperado

de la evaluacin.
Estado
Figura A1.77. Caso de prueba Miembro consulta evaluacin
8.7.2. Usuario intenta consultar evaluacin

La Figura A1.78 nuestra el caso de prueba Usuario intenta consultar evaluacin.
Identificacin
CP-017 : Usuario intenta consultar evaluacin
Caso de Uso CU-007

que lo origina
Escenario
Un usuario que no es miembro de un proyecto (ni
colaborador ni lder) intenta consultar una evaluacin de ese
proyecto.
Datos
Entrada
de El usuario selecciona una evaluacin de la lista de

evaluaciones del proyecto al cual no pertenece.
Resultado
Esperado

Estado
Figura A1.78. Caso de prueba Usuario intenta consultar evaluacin
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.
Identificacin
CP-018 : Usuario crea proyecto
Pg. 103

Directores
Alumnos
Pablo Damin MNDEZ
Caso de Uso CU-008

que lo origina
Escenario
Un Usuario que ha iniciado sesin del sistema intenta crear
un nuevo proyecto.
Datos
Entrada
de El usuario ingresa cualquiera de los siguientes nombres para

el proyecto:
Texto Alfanumrico
Texto nulo
Resultado
Esperado
El sistema crea una nueva proyecto, designando como lder

al usuario creador, y redirigiendo al usuario a la pantalla de
informacin del proyecto.
Estado
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. Lder del proyecto agrega nuevo colaborador

La Figura A1.80 nuestra el caso de prueba Administrador agrega nuevo
evaluador.
Identificacin
CP-019 : Lder del proyecto agrega nuevo colaborador
Caso de Uso CU-009

que lo origina
Escenario
El lder del proyecto accede a la pantalla para agregar un
nuevo colaborador al proyecto.
Datos
Entrada
Resultado
Esperado
de El lder del proyecto ingresa un e-mail vlido

El usuario colaborador del proyecto queda registrado en el
sistema.
Estado
Figura A1.80. Caso de prueba lder de proyecto agrega nuevo colaborador
8.9.2. Lder del proyecto intenta agregar colaborador registrado

La Figura A1.81 nuestra el caso de prueba Lder del proyecto intenta agregar
colaborador registrado.
Identificacin
CP-020 : Lder del proyecto intenta agregar colaborador
Pg. 104

Directores
Alumnos
Pablo Damin MNDEZ
registrado
Caso de Uso CU-009
que lo origina
Escenario
El lder de proyecto accede a la pantalla para agregar un
colaborador, que ya ha sido registrado previamente en el
sistema, en el mismo proyecto.
Datos
Entrada
de El lder del proyecto ingresa un e-mail vlido, 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
Figura A1.81. Caso de prueba Lder del proyecto intenta agregar colaborador registrado
8.9.3. Lder de proyecto intenta agregar colaborador con e-mail nulo

La Figura A1.82 nuestra el caso de prueba Lder de proyecto intenta agregar
colaborador con e-mail nulo.
Identificacin
CP-021 : Lder de proyecto intenta agregar colaborador con

e-mail nulo
Caso de Uso CU-009

que lo origina
Escenario
El lder de proyecto accede a la pantalla para agregar un
nuevo colaborador al proyecto.
Datos
Entrada
Resultado
Esperado
de El administrador enva el formulario sin ingresar un e-mail
Estado
El sistema notifica que el e-mail no es vlido, debido a que es

nulo.
Figura A1.82. Caso de prueba Lder de proyecto intenta agregar colaborador con e-mail nulo
8.9.4. Usuario intenta agregar colaborador al proyecto

La Figura A1.83 nuestra el caso de prueba Usuario intenta agregar colaborador al
proyecto.
Identificacin
CP-022 : Usuario intenta agregar colaborador al proyecto
Caso de Uso CU-009

que lo origina
Escenario
Un usuario, que no cuenta con el rol de lder de proyecto
Pg. 105

Directores
Alumnos
Pablo Damin MNDEZ
(puede o no ser colaborador del proyecto), accede a la

pantalla para agregar un nuevo usuario evaluador.
Datos
Entrada
Resultado
Esperado
de Ninguno
Estado
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.

Identificacin
CP-023 : Administrador inicializa cuestionario
Caso de Uso CU-010

que lo origina
Escenario
El Administrador accede a la pantalla para inicializar la
plantilla de evaluacin.
Datos
Entrada
Resultado
Esperado
de El administrador contesta Si
El sistema inicializa la plantilla de evaluacin y elimina
todos los registros de la base de datos.
Estado
Figura A1.84. Caso de prueba Administrador inicializa cuestionario
8.10.2.
Administrador intenta inicializar cuestionario
La Figura A1.85 nuestra el caso de prueba Administrador intenta inicializar

cuestionario.
Identificacin
CP-023 : Administrador intenta inicializar cuestionario
Caso de Uso CU-010

que lo origina
Escenario
El Administrador accede a la pantalla para inicializar la
plantilla de evaluacin.
Datos
Entrada
de El administrador contesta No
Pg. 106

Directores
Alumnos
Pablo Damin MNDEZ
Resultado
Esperado
El Sistema aborda la operacin y notifica al administrador y

notifica al administrador.
Estado
Figura A1.85. Caso de prueba Administrador intenta inicializar cuestionario
8.10.3.
Usuario intenta inicializar cuestionario
La Figura A1.86 nuestra el caso de prueba Usuario intenta intenta inicializar

cuestionario.
Identificacin
CP-024 : Usuario intenta inicializar cuestionario
Caso de Uso CU-010

que lo origina
Escenario
Un usuario, que no cuenta con el rol de administrador,
accede a la pantalla para inicializar la plantilla de
evaluacin.
Datos
Entrada
Resultado
Esperado
Estado
de Ninguno
Figura A1.86. Caso de prueba Usuario intenta inicializar cuestionario
Pg. 107

Directores
Alumnos
Pablo Damin MNDEZ
9. Conclusin
A lo largo de este documento se desarrollaron de manera detallada todas las
etapas involucradas en el desarrollo de la herramienta DAMVE, desde los
requerimientos hasta el modelo de diseo para ser implementado en lenguaje
Python sobre la arquitectura Appengine de Google.
A continuacin se resumen los aspectos ms relevantes durante el desarrollo de la
herramienta DAMVE
Si bien el documento presenta las etapas de manera consecutiva, suponiendo
un modelo de desarrollo en cascada, el proceso de desarrollo y por
consiguiente los contenidos del documento se fueron generando de manera
iterativa, siguiendo un proceso conducido por el dominio del problema.
Durante la etapa de diseo se busc siempre que la lgica del dominio del
problema fuese independiente del resto de la lgica de la aplicacin (vista y
controlador). Este aspecto es fundamental en el desarrollo de software ya que
hace posible reutilizar completamente dominio para adaptarlo a otro
escenario. Adems, dado que Appengine est basado en el patrn MVC, que
separa el dominio de la interfaz con el usuario (vista y controlador), se
consigui una concordancia entre la arquitectura del sistema y el proceso de
desarrollo.
Al estar la herramienta basada en un entorno web, se busc optimizar la
interaccin con el usuario. Para ello se implementaron interfaces en
AJAX/JSON, que minimizan la transferencia http entre el servidor y el cliente,
en los casos de uso que requieren mayor interaccin usuario/sistema. Como
ejemplo se pueden citar los casos de uso CU-003 Actualizar planilla de
evaluacin y CU-004 Evaluar viabilidad.
A lo largo del documento se busc registrar la trazabilidad que existe entre las
distintas etapas de desarrollo. La Figura A1.19 relaciona los requierimientos
funcionales con los casos de uso, permitiendo registrar la trazabilidad entre
Requerimientos y Casos de Uso. La Figura A1.33 relaciona los casos de uso,
con los paquetes de clases que los implementan permitiendo registrar la
trazabilidad entre Casos de Uso y Clases. Finalmente en la seccin 8 se
desarrollan los casos de prueba como escenarios posibles para cada caso de
uso, permitiendo registrar la trazabilidad entre Casos de Uso y Casos de
Prueba.
Pg. 108

Directores
Alumnos
Pablo Damin MNDEZ
10. Posibles mejoras

Este documento podra mejorarse tomando en cuenta algunos de estos elementos:
Incorporando fragmentos de cdigo en lenguaje Python sobre aquella
funcionalidad del dominio que permita clarificar la implementacin.
El Sistema DAMVE podra mejorarse tomando en cuenta algunos de estos
elementos:
Desarrollar una capa de servicios web. Esto permitira, por ejemplo, utilizar la
aplicacin desde una interfaz de usuario de ventanas mejorando la interaccin
usuario/herramienta, o permitir que la herramienta se integre con otros
sistemas proveyendo el servicio de evaluacin de viabilidad. En el ltimo caso
sera interesante integrar la herramienta DAMVE con un Sistema de
administracin de proyectos.
Pg. 109

Directores
Alumnos
Pablo Damin MNDEZ
Anexo 2. Manual de usuario la

Herramienta DAMVE
Anexo 2. Manual de Usuario de la Herramienta DAMVE.
Pg. 110

Directores
Alumnos
Pablo Damin MNDEZ
1. Introduccin
El Sistema DAMVE tiene por finalidad, ayudar a los miembros de un proyecto de
explotacin de informacin que utilizan la metodologa P3TQ a evaluar su
viabilidad.
2. Requisitos
Para poder ejecutar el sistema DAMVE se requiere de un navegador web con
soporte para AJAX. Los siguientes navegadores funcionan correctamente con el
sistema DAMVE :
Microsoft Internet Explorer 6.0 o superior
Mozilla Firefox 2.0 o superior
En cualquiera de los dos casos deben habilitarse las opciones de cookies y
ejecucin de comandos javascript.
3. Acceso al sistema
Cuando un usuario ingresa el enlace del sistema DAMVE en el navegador web se
presenta la siguiente pantalla, mostrada en la Figura A2.1.:
Figura A2.1. Pantalla de ingreso al sistema
Siguiendo el enlace el usuario accede a un formulario que le solicita identificarse

para poder ingresar al sistema. Los datos de acceso son:
e - m ai l : corresponde a la direccin de e-mail del usuario.
Con t ra se a : se debe ingresar la clave de acceso que debe ser conocida por
el usuario.
stos datos son los pertenecientes a una cuenta de Google habilitada, si el sistema
se est ejecutando online.
Si los datos ingresados son correctos el usuario accede a la pantalla de seleccin
de proyectos, que se muestra en la Figura A2.2:
Pg. 111

Directores
Alumnos
Pablo Damin MNDEZ
Figura A2.2. Pantalla de seleccin de proyectos
Por el contrario, si los datos ingresados son incorrectos, el sistema mostrar la

siguiente pantalla de error, que pedir que se vuelvan a ingresar los datos
nuevamente.
4. Presentacin de la interfaz
Se presenta a continuacin, en la Figura A2.3, la pantalla de seleccin de
proyectos del sistema y se describen las distintas opciones de la barra de mens.
1
Figura A2.3. Pantalla de presentacin de la interfaz
Los nmeros asociados con cada elemento de la pantalla se describen a

continuacin:
1.
2.
No m b re de u su a ri o :
en el encabezado de la pantalla puede verse el

nombre del usuario que est utilizando el sistema.
P r oy e ct os : esta opcin lleva a la pantalla de seleccin de proyectos que le
permite al usuario dar de alta un nuevo proyecto, seleccionar un existente
Pg. 112

Directores
Alumnos
Pablo Damin MNDEZ
y, a partir de all, realizar evaluaciones de viabilidad para el mismo. Esta

opcin explica en detalle en el tem 5 de este manual.
3.
4.
5.
6.
7.
Cue s tio n a rio :
esta opcin lleva a la pantalla de edicin de la plantilla de

evaluacin para los estudios de viabilidad. Solamente los usuarios de
cuentan con el rol de evaluadores pueden acceder, y les permite modificar
los parmetros del cuestionario con el cual se realizan todos los estudios
de viabilidad. Esta opcin se explica en detalle en el tem 10.3 de este
manual.
Ev a lu a do re s : esta opcin lleva a la pantalla que le permite al
administrador del sistema agregar nuevos usuarios evaluadores para que
puedan modificar la plantilla de evaluacin, explicada anteriormente. Esta
opcin se explica en detalle en el tem 10.1 de este manual.
Ini ci a li za r : esta opcin lleva a la pantalla que le permite al administrador
del sistema inicializar la base de datos, eliminando, de existir, toda la
informacin que exista y reiniciando la plantilla de evaluacin. Esta
opcin se explica en detalle en el tem 10.4 de este manual.
A yu d a : esta opcin permite consultar este manual en lnea o descargarlo el
formato electrnico.
S a li r : esta opcin permite que el usuario cierra su sesin y salga del
sistema.
5. Creacin y Seleccin de Proyectos

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

Cualquier usuario registrado en el sistema es capaz de crear un nuevo proyecto y,
de esa manera, convertirse en el lder (o propietario) del mismo.
La creacin de nuevo proyecto se lleva a cabo haciendo clic en la opcin
P ro ye c tos . Luego de hacer esto el usuario puede ver el siguiente formulario,
presentado en la Figura A2.4:
Pg. 113

Directores
Alumnos
Pablo Damin MNDEZ
Figura A2.4. Formulario de creacin de un nuevo proyecto
Para crear un nuevo proyecto, en la seccin "c re a r p ro ye c to " el usuario debe:

Escribir un nombre para el proyecto.
Hacer clic en el botn Cre a r .
Una vez realizada esta tarea el sistema DAMVE crea el proyecto y le presenta al
usuario la pantalla de gestin del proyecto.
5.2. Seleccin de un proyecto existente

Para seleccionar un proyecto existente en el sistema debe hacerse clic en la opcin
P ro ye c tos . Luego de hacer esto el usuario puede ver una lista con los proyectos
existentes en el sistema. La Figura A2.5 muestra esta lista:
Figura A2.5. Pantalla de seleccin de un proyecto
La informacin que se presenta es la siguiente:

Fecha: fecha en la cual se cre el proyecto.
Descripcin: nombre del proyecto.
Creador: e-mail del usuario creador del proyecto
evaluaciones: cantidad de evaluaciones que se han realizado en dicho
proyecto.
Rol: corresponde al rol del usuario con respecto a dicho proyecto,
representado por iconos. El icono
significa que el usuario es el lder del
proyecto, el icono significa que el usuario de colaborador en el proyecto
y el icono significa que el usuario es visitante en dicho proyecto.
Haciendo clic en la fecha, descripcin o rol de un proyecto el usuario
puede acceder a la pantalla de gestin del proyecto.
6. Roles de los usuarios

Antes de continuar explicando los pasos a seguir para poder crear evaluaciones
de viabilidad en la proyectos es necesario presentar los distintos roles que los
usuarios pueden tener dentro del sistema DAMVE. La Tabla 1 presenta los roles
Pg. 114

Directores
Alumnos
Pablo Damin MNDEZ
de los usuarios en el sistema ordenados por jerarqua, comenzando por el rol de

menor jerarqua (visitante)
y llegando hasta el rol con mayor jerarqua
(Administrador):
Nombre del rol
Acciones dentro del sistema
Visitante
Cualquier usuario que haya ingresado el sistema es

considerado visitante. Puede consultar los proyectos
existentes, los miembros pertenecientes a los
proyectos y la cantidad de evaluaciones de viabilidad
realizadas. No puede conocer los resultados de las
evaluaciones de viabilidad.
Cualquier usuario que haya sido designado como
colaborador de un proyecto por el lder del mismo.
Como tal puede crear evaluaciones de viabilidad. Un
colaborador de un proyecto no puede continuar la
ejecucin de evaluaciones creadas por otro colaborador
del mismo proyecto.
Cualquier usuario visitante que d de alta un proyecto
se convierte en el lder del mismo. Como tal puede
crear evaluaciones de viabilidad y designar a otros
usuarios como colaboradores.
Cualquier usuario que haya sido designado como
evaluador por el administrador. Tiene la capacidad de
modificar la plantilla de evaluacin del estudio de
viabilidad.
Es el usuario responsable de la administracin del
sistema. Puede designar a los usuarios evaluadores.
Colaborador del Proyecto
Lder del Proyecto
Evaluador
Administrador
Tabla 1. Roles de los usuarios
Un mismo usuario puede tener dentro del sistema uno o varios roles. Por ejemplo,
un usuario puede ser lder del proyecto 1 por haberlo creado, colaborador del
proyecto 2 porque su lder lo ha designado, visitante en el resto de los proyectos y
evaluador porque el administrador lo ha designado.
7. Gestin de un Proyecto
Una vez creado un nuevo proyecto o seleccionado de la pantalla de seleccin de
proyecto, el usuario accede a la pantalla de gestin del proyecto. La Figura A2.6
presenta dicha pantalla:
Pg. 115

Directores
Alumnos
Pablo Damin MNDEZ
Figura A2.6. Pantalla de gestin del proyecto
En esta pantalla puede observarse toda la informacin relativa al estudio de

viabilidad del proyecto, organizada por secciones.
Se c ci n g e ne r a l : se presenta el Nombre del proyecto, la fecha de creacin
y el usuario propietario, o lder.
Co la b o ra d o re s : se presentan los e-mails de todos los usuarios designados
por el lder del proyecto para crear evaluaciones de viabilidad.
Ev a lu a ci one s : se presenta una tabla que muestra la informacin resumida
de cada uno de los estudios de viabilidad realizados para este proyecto,
ordenados en forma cronolgica descendente, lo que permite visualizar la
evolucin de la viabilidad del proyecto. La tabla presenta la fecha de
creacin, la descripcin, el usuario creador y el resultado de cada una de
las evaluaciones. Si la evaluacin ha sido completada se muestra en la
tabla el resultado final en forma grfica y numrica. Sin evaluacin no ha
sido completada todava se muestran la tabla el texto Incompleto. En el
caso de que un usuario visitante acceda a un proyecto del cual no es
miembro (ni lder ni colaborador) el sistema no mostrara el resultado de
ninguna evaluacin.
7.1. Agregar colaborador al proyecto

El lder del proyecto puede agregar un colaborador al mismo, completando el
formulario A g re g a r co l a bo r a do r al p ro ye ct o que se presenta en la pantalla de
gestin del proyecto. La Figura A2.7 muestra dicha pantalla:
Pg. 116

Directores
Alumnos
Pablo Damin MNDEZ
Figura A2.7. Formulario agregar colaborador al proyecto
Para agregar un colaborador al proyecto, el lder debe:

Escribir el e-mail del usuario colaborador.
Hacer clic en el botn Ag re g a r co l a bo r a do r .
Una vez realizada esta tarea el sistema DAMVE agrega al usuario como
colaborador del proyecto.
7.2. Eliminar un colaborador

El lder de un proyecto puede eliminar a cualquier colaborador que haya
agregado previamente. Para esto debe hacer clic en el icono
que se encuentra al
lado del e-mail de cada colaborador. El sistema le pedir una confirmacin y, si el
lder del proyecto contesta afirmativamente, el colaborador ser eliminado de ese
proyecto, convirtindose en visitante.
7.3. Crear una nueva evaluacin

El lder del proyecto y los usuarios colaboradores pueden crear una nueva
evaluacin de viabilidad para el proyecto, completando el formulario cre a r
nue va e v a l ua ci n que se presenta en la pantalla de gestin del proyecto.
Figura A2.7. Formulario crear nueva evaluacin
Para crear una nueva evaluacin, el usuario miembro del proyecto debe:
Escribir una descripcin para la evaluacin.
Hacer clic en el botn c re ar n ue va e v a lu a c in .
Una vez realizada esta tarea el sistema DAMVE crea una nueva evaluacin para el
proyecto y le muestra al usuario la pantalla de ejecucin de la evaluacin.
7.4. Imprimir la gestin del proyecto

Para imprimir la informacin de gestin del proyecto el usuario debe hacer clic en
el botn Imp r im i r que se encuentra en el borde superior derecho de la pantalla.
Pg. 117

Directores
Alumnos
Pablo Damin MNDEZ
El sistema preparar una versin adaptada para impresin de la pantalla que

facilita su lectura en papel y ejecutar automticamente el cuadro de dilogo de
impresin del navegador web.
7.5. Exportar la gestin del proyecto

Para exportar la informacin de gestin del proyecto a un archivo separado por
comas (.csv) el usuario debe hacer clic en el botn Expo r ta r que se encuentra en
el borde superior derecho de la pantalla.
El sistema generar un archivo .csv que el usuario podr descargar y visualizar en
cualquier planilla de clculo o editor de texto.
8. Ejecucin de evaluaciones
Hasta el momento se ha presentado la forma de crear proyectos, agregar
colaboradores al mismo y crear evaluaciones. En este tem se mostrar la forma de
ejecutar las evaluaciones a travs de un cuestionario guiado.
Una vez que un miembro del proyecto cree una nueva evaluacin, el sistema
DAMVE presenta la pantalla de ejecucin de la evaluacin. La Figura A2.8
presenta dicha pantalla:
Figura A2.8. Pantalla de ejecucin de la evaluacin
La ejecucin de una evaluacin de viabilidad es simple:

1. El sistema le presenta al usuario una pregunta relacionada a un aspecto
particular de la metodologa P3TQ.
2. El usuario debe responderla en relacin a la informacin con la que cuenta
del proyecto que est evaluando. Para esto puede utilizar el mouse para
elegir la opcin que considere correcta y hacer clic en el botn siguiente.
Pg. 118

Directores
Alumnos
Pablo Damin MNDEZ
3.
4.
Alternativamente, para hacer ms dinmica la interaccin, el usuario

puede seleccionar la opcin correcta con las flechas del cursor y presionar
la tecla ENTER.
El sistema procesar la respuesta del usuario y le presentar la prxima
pregunta. Adems, en la seccin "pr e g u nt as re s p on di d as " el sistema
muestra todas las preguntas que el usuario ha respondido.
A llegar a la ltima pregunta el sistema siendo capaz de calcular la
viabilidad del proyecto en base a las respuestas del usuario, le presenta la
pantalla de resultado de la evaluacin.
8.1. Abandonar y Retomar evaluaciones

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

, que le permitir volver a la
pantalla de ejecucin de la evaluacin, retomando el cuestionario desde dnde lo
abandon.
9. Resultado de las evaluaciones

Una vez que se ha completado el cuestionario de evaluacin el sistema le presenta
al usuario de resultado obtenido. La Figura A2.10 muestra un ejemplo de
resultado de evaluacin:
Pg. 119

Directores
Alumnos
Pablo Damin MNDEZ
Figura A2.10. Pantalla de resultado de una evaluacin
El sistema muestra los siguientes resultados:

Di me nsi n j ust if i c a c in : presenta el vector justificacin y, en forma
grfica, el mdulo del vector que sintetiza el resultado de esa dimensin.
Di me nsi n A d a pt a bi li da d : presenta el vector adaptabilidad y, en forma
Di me nsi n P l au si bi li da d : presenta el vector plausibilidad y, en forma
Di me nsi n xit o : presenta el vector xito y, en forma grfica, el mdulo
del vector que sintetiza el resultado de esa dimensin.
V ia bi li d ad : presenta el vector viabilidad, que es un promedio de las cuatro
dimensiones anteriores y, en forma grfica, el mdulo de este vector que
sintetiza el resultado final de la evaluacin.
Si el resultado del clculo del mdulo de un vector es menor a seis, se
considera insuficiente y se presenta el resultado grfico en color rojo. Por
el contrario si el mdulo es mayor a seis se lo considera aceptable y se
presenta el resultado grfico en color verde.
Al igual que la pantalla de ejecucin de una evaluacin del sistema
presenta en la seccin "p re g u nt as re sp on di da s " todas las preguntas que el
usuario ha respondido, permitiendo contar con trazabilidad de la
evaluacin.
9.1. Imprimir los resultados

Para imprimir los resultados de la evaluacin de un proyecto el usuario debe
hacer clic en el botn Im p ri mi r es encuentra en el borde superior derecho de la
pantalla.
Pg. 120

Directores
Alumnos
Pablo Damin MNDEZ
El sistema preparar una versin adaptada para impresin del resultado que
facilita su lectura en papel y ejecutar automticamente el cuadro de dilogo de
impresin del navegador web.
9.2. Exportar los resultados

Para exportar los resultados de la evaluacin a un archivo separado por comas
(.csv) el usuario debe hacer clic en el botn Expo r ta r que se encuentra en el
borde superior derecho de la pantalla.
El sistema generar un archivo .csv que el usuario podr descargar y visualizar en
cualquier planilla de clculo o editor de texto.
9.3. Consultar resultados de evaluaciones realizadas

Para poder consultar los resultados de una evaluacin realizada cualquier
miembro del proyecto (lder o colaborador) debe hacer clic en el resultado final de
la evaluacin que se encuentra en la seccin "Eval u a cio ne s " de la pantalla de
gestin del proyecto. La Figura A2.11 muestra un ejemplo de dicha pantalla:
Figura A2.11. Consultar resultados de evaluaciones realizadas
10. Opciones Avanzadas

Las opciones presentadas a continuacin pueden ser llevadas a cabo por usuarios
con mayor jerarqua en el sistema, debido a los roles que poseen.
10.1. Designar evaluadores

El administrador del sistema puede designar usuarios evaluadores, que son
capaces de modificar la plantilla de evaluacin.
Para realizar esta tarea el administrador debe hacer clic en la opcin
Eva l u ad o re s del men y completar el formulario A g re g a r e va lu a do r que se
Pg. 121

Directores
Alumnos
Pablo Damin MNDEZ
presenta en la pantalla evaluadores. La Figura A2.12 muestra un ejemplo de dicho

formulario:
Figura A2.12. Formulario para agregar un evaluador
Para agregar un nuevo evaluador, el usuario administrador debe:

Escribir el e-mail del nuevo valor.
Hacer clic en el botn A g re g a r e v a lu a do r .
Una vez realizada esta tarea el sistema DAMVE agrega al usuario como
evaluador.
10.2. Eliminar un evaluador

El administrador puede eliminar a cualquier evaluador que haya sido designado
previamente. Para esto debe hacer clic en el icono
que se encuentra al lado del
e-mail de cada evaluador, en la pantalla evaluadores. El sistema le pedir una
confirmacin y, si el administrador contesta afirmativamente, el evaluador ser
eliminado del sistema.
10.3. Editar la plantilla de evaluacin

Los usuarios con el rol de evaluadores pueden editar la plantilla de evaluacin.
Para realizar esta tarea deben hacer clic en la opcin "Cue sti on a r io " del men. A
continuacin se presenta en la Figura A2.13 la pantalla de edicin de la plantilla
de evaluacin.
Figura A2.13. Formulario para editar la plantilla de evaluacin
Pg. 122

Directores
Alumnos
Pablo Damin MNDEZ
El sistema presenta un formulario por cada pregunta del cuestionario de

evaluacin. Los parmetros que pueden modificarse en cada formulario es:
De s c ri p c i n : contiene el texto de la pregunta a contestar.
P e so : el peso de la pregunta, en un rango de -10 a 10.
Di me nsi n : correspondiente a que dimensin de viabilidad corresponde la
pregunta (justificacin, xito, adaptabilidad, plausibilidad)
P r xi m as p r e g u nt as : muestra para cada valor posible de respuesta cual es
la prxima pregunta del cuestionario. Esta opcin permite que el usuario
evaluador pueda navegar el cuestionario. Para esto el usuario evaluador
debe hacer clic en el nmero de la prxima pregunta y el sistema lo
llevara hasta el formulario de dicha pregunta.
El usar evaluador puede, entonces, modificar cualesquiera de los parmetros del
formulario y, haciendo clic en el botn A ct ua l iz a r el sistema guardar los
cambios en la plantilla de evaluacin.
10.3.1.
Preservacin de los resultados
Cuando una pregunta de la plantilla de evaluacin es modificada, todas las

evaluaciones de viabilidad de cualquier proyecto utilizarn los nuevos
parmetros de dicha pregunta. Las evaluaciones que ya hayan respondido
previamente la pregunta conservarn el valor anterior en el resultado. De esta
manera se preservan los resultados de viabilidad anteriores a la modificacin de
la plantilla de evaluacin.
10.3.2.
Preservacin de la secuencia
El sistema DAMVE, no permite que se altere la secuencia de las preguntas, debido

a que siguen, de manera estricta la metodologa P3TQ. Sin embargo, resulta muy
til para un lder de proyecto de explotacin de informacin con experiencia la
posibilidad de modificar los parmetros de la pregunta para adecuar la
evaluacin de debilidad a su entorno de trabajo.
10.4. Inicializar la Base de Datos

El administrador del sistema puede reiniciar la base de datos, haciendo clic en la
opcin Inicia li z ar del men.
Luego de hacer esto el sistema mostrar una pantalla similar a la Figura A2.14,
que solicita la confirmacin del administrador, dado que esta accin destruye
todos los datos que existan en la base de datos y lleva al Sistema DAMVE a su
estado original.
Pg. 123

Directores
Alumnos
Pablo Damin MNDEZ
Figura A2.14. Confirmacin de Inicializacin de la Base de Datos
Si el usuario hace clic en el botn A ce p ta r toda la informacin existente es

eliminada y el sistema queda reinicializado.
Pg. 124

Herramienta de Estudio de Viabilidad para Proyectos Que Utilizan La Metodología P TQ

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Herramienta de Estudio de Viabilidad para Proyectos Que Utilizan La Metodología P TQ

Uploaded by

Copyright:

Available Formats

HERRAMIENTA DE ESTUDIO DE

VIABILIDAD PARA PROYECTOS QUE

TRABAJO PROFESIONAL EN INGENIERA EN

Laboratorio de Sistemas Inteligentes

Pablo Damin MENDEZ

Prof. Dr. Ramn GARCIA-MARTINEZ

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

La metodologa SEMMA ................................................................................................................ 3

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

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

La arquitectura Appengine .......................................................................................................... 58

Diagrama de Casos de Uso........................................................................................................... 44

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

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

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

Diagrama de Paquetes de clases .................................................................................................. 60

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

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

Actualizar planilla de evaluacin ................................................................................................ 87

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

Introduccin ................................................................................................................. 111

Roles de los usuarios ................................................................................................... 114

Abandonar y Retomar evaluaciones .......................................................................................... 119

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

Agregar colaborador al proyecto ............................................................................................... 116

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

Creacin de un proyecto nuevo ................................................................................................. 113

Imprimir los resultados .............................................................................................................. 120

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

Designar evaluadores ................................................................................................................. 121

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

Memoria del Trabajo Profesional

Memoria del Trabajo Profesional

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

y propone un test de viabilidad acorde a dicha

La Explotacin de Informacin se centra en la bsqueda de patrones interesantes

Detectar patrones de fuga y fraudes.

Analizar el comportamiento de las personas que interactan en un sistema

Existen en el mercado actual tres importantes metodologas para llevar a cabo

Memoria del Trabajo Profesional

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

Sin importar la metodologa usada, no existe hasta el da de hoy, ningn mtodo

2.1. La metodologa SEMMA

Figura 2.1.1. Metodologa SEMMA

Memoria del Trabajo Profesional

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

2.2. La metodologa CRISP-DM

Figura 2.2.1. Fases de la Metodologa CRISP-DM

Memoria del Trabajo Profesional

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

2.3. La metodologa P3TQ

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

Dada una oportunidad o problema ver cmo puede la explotacin de la

Simplemente ver qu puede lograr la explotacin de la informacin.

Memoria del Trabajo Profesional

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

Utilizar la minera de datos para construir un modelo sobre una situacin

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

En la Figura 2.3.2 (parte central) se enumeran los parmetros concernientes a la

FIUBA LSI Trabajo Profesional en Ingeniera en Informtica

Finalizado el modelo de negocio el siguiente paso es la explotacin de datos, para

prximo paso a realizar.

Discovery Boxes, en donde se analizan los