Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la

Transcripción

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

Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la

Transcripción

Documentos relacionados

Modulo XII - Proyectos de Inversión

El listado de Trabajos Fin de Master UE 2015/2016

María Pía Lara Zavala - Facultad de Filosofía

Peter Gabriel Stein - ertic - Universidad Nacional de Asunción