Viabilidad y validación de una herramienta de inteligencia ...
Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la ...
Transcript of Herramienta de Estudio de Viabilidad para Proyectos que Utilizan la ...
HERRAMIENTA DE ESTUDIO DE VIABILIDAD PARA PROYECTOS QUE
UTILIZAN LA METODOLOGÍA P3TQ
TRABAJO PROFESIONAL EN INGENIERÍA EN INFORMÁTICA
Laboratorio de Sistemas Inteligentes Facultad de Ingeniería
Universidad de Buenos Aires
Alumnos: Pablo Damián MENDEZ Alejandro Daniel RODRIGUEZ
Directores: Prof. Dr. Ramón GARCIA-MARTINEZ Prof. Dra. Paola BRITOS
Mayo 2009
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Índice
Memoria del Trabajo Profesional.................................................................... 1 1. Resumen ........................................................................................................................... 2
2. Introducción ..................................................................................................................... 2 2.1. La metodología SEMMA ................................................................................................................ 3 2.2. La metodología CRISP-DM ............................................................................................................ 4 2.3. La metodología P3TQ...................................................................................................................... 5 2.4. Comparación de las metodologías P3TQ, SEMMA y Crisp-DM................................................... 7
3. Estudio de viabilidad....................................................................................................... 9 3.1. El método ........................................................................................................................................ 9 3.2. Viabilidad en P3TQ ....................................................................................................................... 11 Modelo para predecir:............................................................................................................................... 17
4. Conclusiones .................................................................................................................. 22
5. Futuras mejoras.............................................................................................................. 23
6. Bibliografía ..................................................................................................................... 23
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE ............. 24 1. Objetivo .......................................................................................................................... 25
2. Funcionalidad del Sistema ............................................................................................ 26 2.1. Evaluación de proyectos............................................................................................................... 26 2.2. Gestión de usuarios ...................................................................................................................... 26
3. Cambios en la versión ................................................................................................... 27 3.1. Versión 4 ....................................................................................................................................... 27 3.2. Versión 3 ....................................................................................................................................... 27 3.3. Versión 2 ....................................................................................................................................... 27 3.4. Versión 1 ....................................................................................................................................... 27
4. Especificación de Requerimientos ................................................................................ 27 4.1. Formato ......................................................................................................................................... 27 4.2. Requerimientos funcionales ......................................................................................................... 28 4.3. Requerimientos no funcionales .................................................................................................... 36 4.4. Restricciones ................................................................................................................................. 43
5. Modelo de análisis ......................................................................................................... 44 5.1. Diagrama de Casos de Uso........................................................................................................... 44 5.2. Matriz de trazabilidad Casos de Uso – Requerimientos Funcionales ........................................ 45 5.3. Realización de los Casos de Uso .................................................................................................. 46
6. Arquitectura del Sistema............................................................................................... 58 6.1. La arquitectura Appengine .......................................................................................................... 58
7. Diseño de la aplicación.................................................................................................. 60 7.1. Diagrama de Paquetes de clases .................................................................................................. 60 7.2. dbmodel. La capa De dominio ..................................................................................................... 62 7.3. View. Paquete de soporte para vista............................................................................................ 67 7.4. Paquetes de Controladores.......................................................................................................... 68 7.5. Diagramas de Secuencia ............................................................................................................... 74 7.6. Secuencia entre Pantallas ............................................................................................................. 77 7.7. Diagrama de Despliegue .............................................................................................................. 82
8. Casos de Prueba............................................................................................................. 84 8.1. Validar Usuario............................................................................................................................. 84 8.2. Asignar evaluador ........................................................................................................................ 85
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
8.3. Actualizar planilla de evaluación ................................................................................................ 87 8.4. Evaluar viabilidad ........................................................................................................................ 88 8.5. Crear evaluación ......................................................................................................................... 100 8.6. Consultar proyecto ..................................................................................................................... 101 8.7. Consultar Evaluación ................................................................................................................. 102 8.8. Crear Proyecto ............................................................................................................................ 103 8.9. Asignar colaborador ................................................................................................................... 104 8.10. Inicializar cuestionario ............................................................................................................... 106
9. Conclusión.................................................................................................................... 108 10. Posibles mejoras........................................................................................................... 109
Anexo 2. Manual de usuario la Herramienta DAMVE............................. 110 1. Introducción ................................................................................................................. 111
2. Requisitos ..................................................................................................................... 111 3. Acceso al sistema ......................................................................................................... 111
4. Presentación de la interfaz .......................................................................................... 112
5. Creación y Selección de Proyectos.............................................................................. 113 5.1. Creación de un proyecto nuevo ................................................................................................. 113 5.2. Selección de un proyecto existente ............................................................................................ 114
6. Roles de los usuarios ................................................................................................... 114 7. Gestión de un Proyecto ............................................................................................... 115
7.1. Agregar colaborador al proyecto ............................................................................................... 116 7.2. Eliminar un colaborador............................................................................................................. 117 7.3. Crear una nueva evaluación....................................................................................................... 117 7.4. Imprimir la gestión del proyecto ............................................................................................... 117 7.5. Exportar la gestión del proyecto ................................................................................................ 118
8. Ejecución de evaluaciones........................................................................................... 118 8.1. Abandonar y Retomar evaluaciones .......................................................................................... 119
9. Resultado de las evaluaciones .................................................................................... 119 9.1. Imprimir los resultados .............................................................................................................. 120 9.2. Exportar los resultados............................................................................................................... 121 9.3. Consultar resultados de evaluaciones realizadas...................................................................... 121
10. Opciones Avanzadas ................................................................................................... 121 10.1. Designar evaluadores ................................................................................................................. 121 10.2. Eliminar un evaluador................................................................................................................ 122 10.3. Editar la plantilla de evaluación ................................................................................................ 122 10.4. Inicializar la Base de Datos ........................................................................................................ 123
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 1
Memoria del Trabajo Profesional
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 2
1. Resumen
Los actuales proyectos de explotación requieren el análisis y
ejecución de etapas para ser llevados a cabo con éxito. Cada una de
estas etapas insume tiempo y recursos, lo que hace sumamente
importante estudiar la viabilidad del proyecto para evaluar si
resulta posible y conveniente llevarlo a cabo y, además, controlar
cada etapa de ejecución para detectar y corregir desvíos y, de esta
manera, asegurar su éxito.
El proyecto en cuestión se enfoca en una metodología para la
realización de proyectos de explotación de la información (Data
mining) y propone un test de viabilidad acorde a dicha
metodología.
2. Introducción
La Explotación de Información se centra en la búsqueda de patrones interesantes
en grandes bases de datos.
Utiliza tanto técnicas estadísticas (Análisis de varianza, Regresión, Prueba chi-
cuadrado, Análisis de agrupamiento o clustering, Análisis discriminante, Series
de tiempo, etc.) como informáticas (Algoritmos genéticos, Inteligencia Artificial,
Sistemas Expertos, Redes neuronales, etc.)
Entre muchos otros ejemplos, la Explotación de Información ha contribuido
significativamente en:
� Las aplicaciones de administración empresarial basada en la relación con el
cliente.
� Detectar patrones de fuga y fraudes.
� Analizar el comportamiento de las personas que interactúan en un sistema
(por ejemplo Internet)
Existen en el mercado actual tres importantes metodologías para llevar a cabo
proyectos de explotación de la información, a saber:
� SEMMA
� CRISP-DM
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 3
� 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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 4
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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 5
2.3. La metodología P3TQ
La metodología de D. Pyle se divide en dos etapas, la primera denominada
Modelado de Negocio o MII, y la segunda llamada Minería de datos o MIII
[Pyle, D. 2003].
MII
Modelado del Negocio
Inicio
MIII
Preparación de los Datos
(Boxes 9.x)
MIII
Minería sobre el modelo
(Boxes 11.x)
MIII
Refinamiento
(Boxes 12.x)
Fin
MIII
Despliegue
(Boxes 13.x)
Figura 2.3.1. Metodología de D.Pyle, Etapas del proyecto de explotación de información
Para comenzar la primera etapa Pyle propone cinco posibles puntos de partida en
función del propósito del proyecto de explotación de la información que se quiere
evaluar. De esta manera Pyle considera:
1. Explorar los datos en búsqueda de relaciones útiles.
2. Dada una oportunidad o problema ver cómo puede la explotación de la
información encausar a la organización hacia una decisión correcta.
3. Simplemente ver qué puede lograr la explotación de la información.
Metodología de Modelado (MII)
Metodología de Minería (MIII)
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 6
4. Utilizar la minería de datos para construir un modelo sobre una situación
particular
5. Dada una situación estratégica, analizar si la minería de datos puede ser útil
para explicar la situación y cuáles son las opciones de la organización para
resolverla.
Figura 2.3.2. Metodología de P3TQ, Puntos de partida de un proyecto y objetos a considerar
En la Figura 2.3.2 (parte central) se enumeran los parámetros concernientes a la
organización y la situación del proyecto que la metodología de P3TQ considera,
sin embargo estos son tratados de distinta manera según el punto de partida, para
obtener finalmente los datos requeridos para el proyecto de explotación y los
requerimientos reales de las partes interesadas.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 7
Finalizado el modelo de negocio el siguiente paso es la explotación de datos, para
ello D. Pyle propone los pasos mostrados en la Figura 2.3.3.
Preparación de los datos
Selección de la herramienta
Minería
Refinamiento
Despliegue
Cada parte de la metodología (tanto en MII como en MIII)
está desagregada en pasos, estos pasos son denominados
boxes, existiendo 3 tipos de ellos:
� Action Boxes, en donde se decide cuál es el
próximo paso a realizar.
� Discovery Boxes, en donde se analizan los
posibles resultados y problemas luego de ejecutar
un Action Box.
� Technique Boxes, que describen minuciosamente
cómo debe emplearse una técnica.
Los boxes no se recorren secuencialmente, los saltos entre
ellos dependen de las situaciones que se van dando a
medida que se avanza en el proyecto.
Figura 2.3.3. Pasos distinguidos en la metodología P3TQ
Los boxes explican detalladamente los conceptos y/o acciones que se realizan. El
gráfico mostrado anteriormente permite identificar cuáles son los Boxes que
corresponden a cada etapa de la metodología. Por ejemplo puede verse en la
figura 2.3.1 que los Boxes 9.x corresponden a la etapa de preparación de los datos
en la metodología de minería MIII.
2.4. Comparación de las metodologías P3TQ, SEMMA y
Crisp-DM
Luego de las investigaciones iniciales, hemos concluido que SEMMA se centra en
los aspectos técnicos de los proyectos de explotación de datos. Además está
acotada ya que ha sido diseñada para ser implementada con los productos SAS.
Crisp-DM es más completa y abierta que SEMMA, pero no llega al detalle de la
metodología P3TQ, ya que nombra etapas del proceso de la explotación de la
información, pero no se analizan los pasos, resultados y situaciones que se pueden
dar dentro de cada etapa.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 8
Concluimos que la metodología P3TQ es la más completa entre las tres
mencionadas (Ver cuadro 2.4.1), y, por lo tanto en la que se centrará el presente
trabajo. Dicha metodología analiza muchas más variables y más profundamente
que las demás. Para citar un simple y claro ejemplo (considerando que nos
encontramos sólo en la introducción de la presentación de un proyecto y no en su
desarrollo) la metodología considera quiénes son los interesados en el proyecto en
la organización, considerando hasta la causa de su interés (Pyle, D. Business
Modeling and Data Mining, Technique Box 1: Identify Stakeholders).
SEMMA
CRISP-
DM PYLE
Permite elección totalmente libre de
herramientas NO SI SI
Cantidad de fases 5 6 5 (1 MII y 4 MIII)
Todas las fases pueden relacionarse NO SI SI
Considera motivo del proyecto NO NO SI
Considera naturaleza del interés de las partes NO NO SI
Considera otros aspectos no técnicos NO SI SI
Identifica claramente las variables sobre las que el
proyecto tiene impacto NO NO
SI (Product, Place, Price,
Time, Quantity)
Está detallada paso a paso cada etapa del método NO NO SI
Cuadro 2.4.1. Cuadro comparativo de metodologías
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 9
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”).
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 10
Según los valores de cada característica del problema se estima si el proyecto es
viable o no. Además cada característica estará ponderada por un “peso”, que hará
que incida en mayor o menor medida en la dimensión de un problema.
En casos de valores lingüísticos son convertidos en valores difusos
correspondiente en el intervalo [0,10] como se muestra en la tabla 3.1.1.
Tabla 3.1.1 Conversión entre valores lingüísticos y valores difusos
Para homogeneizar el problema, los valores booleanos también se tratan como
lingüísticos considerando los valores de la tabla 3.1.2.
Tabla 3.1.2 Conversión entre valores booleanos y valores difusos
Las características se agruparán según su naturaleza y llamaremos a cada grupo
“Dimensión”, existiendo cuatro dimensiones a saber: Plausibilidad, Éxito,
Adecuación y Justificación.
La dimensión “Plausibilidad” agrupará todas aquellas características que indican
si el desarrollo del proyecto es posible, por ejemplo si existen expertos y están
disponibles, si existen los casos de prueba adecuados, etc. El “éxito” es
determinado por características del problema que generalmente se dan a
posteriori del desarrollo, de todas maneras debemos identificar y evaluar estas
características a priori, para ejemplificar podemos mencionar el interés o
desinterés de un departamento clave de la organización, que no sea el sponsor
pero si el usuario final (el proyecto sería desarrollado pero nunca utilizado o los
usuarios serían reacios, esto sería un fracaso).
La dimensión de “Justificación” contendrá cada característica que determine si
vale la pena realizar el proyecto. Supongamos el caso que se dispone de
suficientes expertos en la materia y no representan costo significativo para la
empresa, en este caso seguramente no será justificado el desarrollo.
Nada 0 0 1,2 2,2
Poco 1,2 2,2 3,4 4,4
Regular 3,4 4,4 5,6 6,6
Mucho 5,6 6,6 7,8 8,8
Todo 7,8 8,8 10 10
No 0 0 0 0
Sí 10 10 10 10
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 11
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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 12
información tienen como objetivo descubrir qué problemas se pueden solucionar
con la información existente, pero no la solución de un problema en sí.
Esta característica, incrementa la necesidad del estudio de viabilidad; ya que al
comenzar con un rumbo incierto, es probable terminar en una solución no
deseada luego de haber invertido tiempo de personal calificado y recursos
económicos.
Naturalmente no es apropiado este tipo de perspectiva para ningún tipo de
proyectos, a pesar que la realidad en la práctica indique que muchos comienzan
de esta manera porque el sponsor lo requiere.
Como se describió en la sección 2.3, la metodología propuesta por D. Pyle,
establece dos partes de un proyecto de minería de datos, el “Modelado de Negocio”
y la “Metodología de Minería”. Por esta razón analizaremos la viabilidad tomando
características de estas dos partes por separado.
3.2.1. Estudio de viabilidad en el modelado de negocio
Tomando como punto de partida que nada puede ofrecer un proyecto de
explotación de datos hasta que el problema a resolver sea identificado, esto debe
lograrse de alguna manera, aunque el cliente no lo haya especificado.
Pyle reconoce, por lo tanto, los siguientes puntos de partida de un proyecto según
su objetivo:
Según el punto de partida inicial, D. Pyle establece cuáles son los siguientes pasos
a seguir.
Por ejemplo el caso más general, con escasa información sobre el negocio, sólo
llega el conjunto de datos sobre el cual se debe aplicar minería para descubrir
relaciones que puedan llegar a ser de interés. En este punto, Pyle, establece
� Explorar los datos y descubrir relaciones interesantes que
ofrezcan valor agregado al negocio.
� Un problema u oportunidad de negocio en particular a ser
explorado.
� Descubrir en qué partes de la organización puede ser
interesante aplicar métodos de explotación de la
información.
� Crear un modelo para un propósito especificado. � Planificar escenarios corporativos.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 13
específicamente el aso más lógico a seguir: reconocer a los interesados según cinco
categorías:
1. Los que necesitan la realización del proyecto.
2. Los que poseen los recursos económicos.
3. Los que poseen poder de decisión para que el proyecto avance.
4. Los que se benefician con el resultado.
Luego se procedería con una entrevista a los interesados, en donde se debe
entender cuál es la parte relevante de negocio que, justamente, les interesa y
discutir con ellos para identificar cuál es el proyecto original que alimenta la
necesidad de un proyecto de minería.
Siguiendo este ejemplo, es nuestro estudio de viabilidad, analiza si:
� Las partes interesadas están identificadas.
� Las partes interesadas tienen disponibilidad de tiempo para avocarse al
proyecto.
� Existen partes interesadas con recursos suficientes.
� Las características importantes para las partes interesadas están identificadas.
La parte clave de estos pasos es descubrir y caracterizar cuál, cómo y cuánto de
los componentes P3TQ (Product, Price, Place, Time, Quantity) son afectados por
el proyecto, qué hay que cambiar para ver la oportunidad o resolver el problema
de trasfondo.
Las cinco variables de negocio que dan nombre a esta metodología, interactúan
mutuamente (figura 3.2.1.1). Por ejemplo, el éxito del lanzamiento de un producto
depende, obviamente del cliente, pero las características de ellos, dependen del
tiempo y el lugar.
Figura 3.2.1.1 Variables P3TQ
Estas relaciones deben ser reveladas en los datos con las herramientas usadas para
la minería de datos.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 14
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 15
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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 16
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á
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 17
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 18
Presentado ya el método de cálculo de viabilidad, la metodología sobre la cual se
apoyan los proyectos de explotación de la información que consideramos,
analizaremos a continuación cómo se presenta la metodología propuesta al
usuario final.
El interesado en determinar el riesgo de un proyecto deberá ir contestando un
cuestionario donde se presentan los posibles escenarios de riesgo para cada paso
de la metodología P3TQ.
Como P3TQ no es secuencial, no serán tampoco las preguntas presentadas.
Según lo que el usuario responda se le mostrarán un conjunto de preguntas u
otro.
Las preguntas de la tabla 3.2.3.1 están divididas en aquellas que corresponden a la
etapa de modelado (Id de la 1 a la 27), las que corresponden a la etapa de minería
(27 a 49) y las que manejan la secuencia de la metodología P3TQ (50 a 57). Notar
que todas excepto las del tercer grupo tienen un peso asignado y su dimensión
correspondiente en la tabla (P: plausibilidad, A: adaptabilidad, J: justificación y E:
éxito). El peso es la ponderación que tendrán en su dimensión en el cálculo de
viabilidad.
Las preguntas 50 a 57 tienen peso cero, ya que no evalúan el proyecto, sino que
identifican una situación particular y en función de sus respuestas se mostrará
una secuencia de preguntas o no. Id
pregunta Descripción Peso Dimensión
1
Las partes interesadas están identificadas? Las partes interesadas son aquellas personas o grupos de
personas que afectan o pueden ser afectadas por el proyecto.Boxes de referencia de la metodología P3TQ:
DB1, AB2, AB3
8 P
2 Todas las partes interesadas cuentan con la disponibilidad de tiempo para avocarse al proyecto? Boxes de
referencia de la metodología P3TQ: DB1, AB2, AB3
8 P
3 Existen partes interesadas con autoridad suficiente dentro de la organización para liderar el proyecto de
explotación? Boxes de referencia de la metodología P3TQ: DB1, AB2, AB3
6 E
4 Existen partes interesadas con recursos económicos suficientes para encarar el proyecto? Boxes de
referencia de la metodología P3TQ: DB1, AB2, AB3
6 P
50 El proyecto de explotación tiene como propósito buscar relaciones de interés? 0 M
5 El proyecto original cuenta con el apoyo de la organización? Boxes de referencia de la metodología P
3TQ:
DB1, AB2, AB3 10 E
6 El proyecto original cuenta con el apoyo de las partes interesadas? Boxes de referencia de la metodología
P3TQ: DB1, AB2, AB3
8 P
7
Existe comunicación con las partes interesadas del proyecto original? El proyecto original es aquel que
origina el proyecto de explotación que se está evaluando.Boxes de referencia de la metodología P3TQ:
DB1, AB2, AB3
6 P
8 Se cumplieron los objetivos del proyecto original? 8 P
51 El proyecto de explotación tiene como propósito la evaluación de una situación de negocio? (análisis de
problema u oportunidad)? 0 M
9
Con respecto a la problemática del negocio del proyecto original: Se han encontrado datos de utilidad para
llevar a cabo la minería? El proyecto original es aquel que origina el proyecto de explotación que se está
evaluando.Boxes de referencia de la metodología P3TQ: AB6
5 P
10
Las partes interesadas han identificado o pueden identificar aquellas características del negocio
importantes, que enmarcan sus expectativas del proyecto de explotación? Boxes de referencia de la
metodología P3TQ: TB7
5 A
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 19
Id
pregunta Descripción Peso Dimensión
11 La situación del negocio está enmarcada o puede enmarcarse en un modelo a partir de los datos
conocidos? Boxes de referencia de la metodología P3TQ: AB6
6 J
12 Los Objetivos y Metas del negocio están definidos o pueden definirse? Boxes de referencia de la
metodología P3TQ: AB6, TB5
8 J
52 El proyecto de explotación tiene como propósito descubrir en que partes de la organización se puede
agregar valor? 0 M
13
Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del
negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB11,
TB3
10 E
14 Es conocida la relación entre las cinco temáticas claves del negocio (producto, lugar, precio, tiempo y
cantidad) y el proceso principal de la organización? Boxes de referencia de la metodología P3TQ: AB11
5 A
15
Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII
de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P3TQ:
AB11, MII Tabla 7.1
5 A
16 Existen datos disponibles para explotación? Boxes de referencia de la metodología P3TQ: AB11 10 E
17 Esta desarrollado, o es posible desarrollar un esquema de caso de negocio para cada oportunidad
significativa? Boxes de referencia de la metodología P3TQ: AB11
10 P
53 Hay otro propósito especifico? 0 M
18 Los requerimientos fueron consensuados con las partes interesadas? Boxes de referencia de la
metodología P3TQ: AB9
10 E
19 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: AB9
6 J
20 Existe información disponible para la explotación? Boxes de referencia de la metodología P3TQ: AB9 10 E
54 Se requiere inicialmente un análisis estratégico para planificar escenarios corporativos? 0 M
21 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: AB9
2 A
22 Existe un mapa del escenario estratégico, consensuado con las partes interesadas. .Boxes de referencia de
la metodología P3TQ: AB12
6 A
23 Están identificadas por las partes interesadas las relaciones entre las cinco temáticas clave del
negocio(producto, lugar, precio, tiempo y cantidad)? Boxes de referencia de la metodología P3TQ: AB12 8 A
24 Puede establecerse correspondencia entre el mapa y las relaciones P3TQ? Boxes de referencia de la
metodología P3TQ: AB12
8 A
25 Existen o pueden realizarse simulaciones que permitan identificar ambigüedades, incertezas,
discordancias? Boxes de referencia de la metodología P3TQ: AB12 8 A
26 Están caracterizadas o pueden caracterizarse las relaciones clave del sistema? Boxes de referencia de la
metodología P3TQ: AB12
8 E
27
Esta determinado o puede determinarse cuales de los 26 recursos de gestión (Consultar la tabla 7.2 de MII
de P3TQ) son adecuados a cada potencial parte interesada? Boxes de referencia de la metodología P
3TQ:
AB12, MII Tabla 7.1
4 A
28 Existe o puede obtenerse un set de datos sin errores? Boxes de referencia de la metodología P3TQ: DB9.1 8 P
29 El set de datos obtenidos esta referenciado al caso de negocio a estudiar? Boxes de referencia de la
metodología P3TQ: DB9.1
8 P
30 Existen variables con único valor, o valores vacios en sus instancias? Boxes de referencia de la metodología
P3TQ: DB9.2
-4 P
31 Las variables categóricas están documentadas? Boxes de referencia de la metodología P3TQ: DB9.2 3 A
32 Los nombres de los atributos son acorde a los conceptos del negocio? Boxes de referencia de la
metodología P3TQ: DB9.3
4 A
33 Son reconocidas y es posible adecuar variables anacrónicas? Boxes de referencia de la metodología P
3TQ:
DB9.4 4 A
34
Existen datos suficientes como para crear diez modelos predictivos con once atributos cada uno (siempre
distintos) y generar un set de entrenamiento y otro de testeo? Boxes de referencia de la metodología
P3TQ: DB9.5, TB9.4
8 E
35 Se dispone de un experto para analizar y asegurar que el set de datos representa los escenarios más
importantes que pueden ocurrir en el negocio? Boxes de referencia de la metodología P3TQ: DB9.6
10 E
36 Es necesario realizar recodificación de variables para mejor comprensión del modelo? Boxes de referencia
de la metodología P3TQ: DB9.7
-4 A
37 Los conjuntos de variables de entrada y salida están caracterizadas? Boxes de referencia de la metodología
P3TQ: AB11.1
6 A
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 20
Id
pregunta Descripción Peso Dimensión
38 Los datos están estructurados o pueden estructurarse para aplicarlos en la herramienta de minería
elegida? Boxes de referencia de la metodología P3TQ: AB11.1
6 A
39 Están seleccionados los algoritmos de minería adecuados al modelo? Boxes de referencia de la
metodología P3TQ: AB11.3
8 A
40 Existe una herramienta de minería adecuada al modelo y esta disponible? Boxes de referencia de la
metodología P3TQ: AB11.6
8 A
41 De necesitarse comprar herramientas, existen proveedores disponibles. .Boxes de referencia de la
metodología P3TQ: AB11.5
8 P
42 Esta construido o puede construirse el MVCM (Missing Value Check Model)? Boxes de referencia de la
metodología P3TQ: AB11.1
5 P
55 El objetivo de la explotación es entender una situación? 0 M
43 Las variables utilizadas en el modelo están relacionadas con conceptos que son conocidos por las partes
interesadas? Boxes de referencia de la metodología P3TQ: AB11.1, DB11.5
8 E
44 Los objetos del negocio que representan las variables pueden ser utilizados por las partes interesadas, o
gerentes para realizar mejoras en el negocio. .Boxes de referencia de la metodología P3TQ: AB11.1, DB11,5
8 E
45 Los datos son suficientes para definir las relaciones explicativas? Boxes de referencia de la metodología
P3TQ: AB11.1 DB11.5
6 E
56 El objetivo de la explotación es aplicar una clasificación? 0 M
46 Esta determinado o puede determinarse en la herramienta el tipo de modelo de clasificación inicial (B:
Binario; M : Clases Múltiples o C : Continuo)? Boxes de referencia de la metodología P3TQ: DB11.6
6 E
47 La herramienta elegida soporta el tipo de entrada y el tipo de salida del modelo inicial de clasificación?
Boxes de referencia de la metodología P3TQ: DB11.6
8 E
57 El objetivo de la explotación es buscar una predicción? 0 M
48 Las herramientas de modelado del sistema están seleccionadas? Boxes de referencia de la metodología
P3TQ: TB11.7
5 E
49 Es posible caracterizar las relaciones esenciales entre los conceptos del negocio en las herramientas de
predicción? Boxes de referencia de la metodología P3TQ: DB11.7
6 E
Tabla 3.2.3.1 Cuestionario de viabilidad
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 21
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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 22
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Memoria del Trabajo Profesional Pág. 23
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/
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 24
Anexo 1. Documento de
Desarrollo de la Herramienta
DAMVE
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 25
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 26
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 27
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 28
� 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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 29
4.2.1. Crear y Actualizar Proyectos
La Figura A1.2 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-001 Alta Funcional CREAR Y ACTUALIZAR PROYECTOS
Descripción
El sistema debe permitirle a un usuario registrado crear un nuevo proyecto y
convertirse en su líder.
La información que debe ingresarse y guardarse cuando se crea un proyecto es:
� Descripción del proyecto
� Fecha de creación
� Líder del proyecto (usuario que lo crea)
Deben respetarse las siguientes reglas:
� Cualquier usuario registrado en el sistema se convierte en el líder de un
proyecto que crea.
Control de Cambios
Fecha Solicitado
por
Descripción del cambio
Figura A1.2. Requerimiento Funcional Crear y Actualizar Proyectos
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 30
4.2.2. Creación de Evaluaciones
La Figura A1.3 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-002 Alta Funcional CREACIÓN DE EVALUACIONES
Descripción
El sistema debe permitirle al líder del proyecto o a un usuario asignado 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
Descripción del cambio
Figura A1.3. Requerimiento Funcional Creación de evaluaciones
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 31
4.2.3. Continuar con una evaluación en Ejecución
La Figura A1.4 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-003 Media Funcional CONTINUAR CON UNA
EVALUACIÓN EN EJECUCIÓN
Descripción
El sistema debe permitirle al usuario creador de una evaluación que se encuentra
en el estado de "en ejecución " continuar con la misma, presentándole la interfaz
correspondiente.
Control de Cambios
Fecha Solicitado
por
Descripción del cambio
Figura A1.4. Requerimiento Funcional continuar con una evaluación en ejecución
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 32
4.2.4. Mostrar resultados del proyecto
La Figura A1.5 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-004 Alta Funcional MOSTRAR RESULTADOS DEL
PROYECTO
Descripción
El sistema debe presentar una interfaz que le permita a los usuarios que iniciaron
sesión navegar un proyecto cualquiera.
� Si el usuario pertenece a dicho proyecto (siendo su líder o colaborador)
podrá ver los datos generales del proyecto (descripción, fecha de
creación, usuario creador, sus colaboradores) y la información
actualizada y resumida de todas las evaluaciones realizadas, incluyendo
el resultado final de cada evaluación completada, ordenado de manera
cronológica descendente, de manera de poder analizar la evolución del
proyecto en el tiempo. Si existen evaluaciones “en ejecución” el sistema
debe comunicarlo y proveer una opción para poder retomar dicha
evaluación.
� Si el usuario no pertenece al proyecto podrá ver solamente los datos
generales del proyecto especificados anteriormente y la información de
las evaluaciones, pero no su resultado final.
Control de Cambios
Fecha Solicitado por
Descripción del cambio
Figura A1.5. Requerimiento Funcional Mostrar resultados del proyecto
4.2.5. Actualización de la Plantilla de Evaluación
La Figura A1.6 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-005 Media Funcional ACTUALIZACIÓN DE LA PLANTILLA
DE EVALUACIÓN
Descripción
El sistema debe proporcionar una plantilla estándar pre-cargada que permita de
avisar evaluaciones de proyectos por los usuarios del sistema.
Además debe proporcionar una interfaz para que el usuario con rol de Evaluador,
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 33
pueda actualizar esta plantilla de evaluación, ajustando los siguientes parámetros
en cada pregunta de la plantilla:
� Texto de la pregunta
� Dimensión a la que pertenece
� Peso
Deben respetarse las siguientes reglas:
� Cuando se actualiza la plantilla estándar las evaluaciones posteriores a
dicha actualización se realizarán con los cambios.
� Las evaluaciones que se han completado antes de la actualización no
reflejarán los cambios realizados.
� Las evaluaciones que se encuentran "en ejecución" no reflejarán los
cambios en aquellas preguntas ya contestadas; sin embargo sí lo harán en
las preguntas aún no contestadas.
Control de Cambios
Fecha Solicitado por Descripción del cambio
05/03/2009 Alejandro
Rodríguez
� El administrador debe poder
inicializar el cuestionario con valores
por defecto al desplegarse el sistema
por primera vez.
� El administrador debe poder
restablecer el cuestionario por
defecto. Figura A1.6. Requerimiento Funcional Actualización de la Plantilla de Evaluación
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 34
4.2.6. Asignación de Colaboradores al Proyecto
La Figura A1.7 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-006 Alta Funcional ASIGNACIÓN DE COLABORADORES
AL PROYECTO
Descripción
El sistema debe permitirle al líder de un proyecto designar colaboradores para
que puedan realizar evaluaciones en dicho proyecto. La información que debe
ingresarse para poder asignar un colaborador es su nombre de usuario,
coincidente con su dirección de correo electrónico.
Una vez que esta información ha sido provista, los usuarios designados pueden
colaborar en un proyecto creando evaluaciones. Deben respetarse las siguientes
reglas:
� Un usuario puede ser colaborador de distintos proyectos.
� Un usuario no puede ser colaborador y líder de proyecto al mismo
tiempo. El rol de líder de proyecto incluye la funcionalidad de
colaborador.
Control de Cambios
Fecha Solicitado
por
Descripción del cambio
Figura A1.7. Requerimiento Funcional Asignación de Colaboradores al Proyecto
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 35
4.2.7. Designación de evaluadores
La Figura A1.8 presenta el requerimiento funcional con el formato establecido.
Código Relevancia Clasificación Nombre
RF-007 Alta Funcional DESIGNACIÓN DE EVALUADORES
Descripción
El sistema debe permitirle al administrador de sistema designar a aquellos
usuarios con el rol de evaluadores.
La información que debe ingresarse para poder designar a un usuario como
evaluador es su nombre de usuario, coincidente con su dirección de correo
electrónico.
Una vez que esta información ha sido provista, los usuarios designados pueden
actualizar la plantilla estándar de evaluación de proyecto.
Deben respetarse las siguientes reglas:
� Todos usuarios evaluadores pueden realizan cambios sobre la única
plantilla estándar.
Control de Cambios
Fecha Solicitado
por
Descripción del cambio
Figura A1.8. Requerimiento Funcional Designación de evaluadores
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 36
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 Relevancia Clasificación Nombre
RNF-
001
Alta Rendimiento PROPORCIONAR TIEMPOS DE
RESPUESTA ACEPTABLES
Descripción
El sistema debe poseer la capacidad de prestar el servicio con los siguientes
niveles aceptables de desempeño, teniendo cuenta la concurrencia de usuarios
� Tiempo máximo de actualización de pantalla durante la ejecución de una
evaluación a cada usuario: 5 seg.
� Cantidad máxima de usuarios concurrentes: 20 usuarios
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.9. Requerimiento no Funcional Designación de evaluadores
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 37
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 Relevancia Clasificación Nombre
RNF-
002
Alta Rendimiento PREVEER CONTINGENCIAS POR
CAIDA DEL SISTEMA
Descripción
El sistema deberá prever contingencias que pueden afectar la prestación estable y
permanente del servicio.
La siguiente es la lista de las contingencias que se deben tener en cuenta y se
pueden considerar críticas:
� Caída del sistema por volumen de datos excedido en la base.
� Sobrecarga del sistema por volumen de transferencia de datos a los
usuarios.
� Caída del sistema por sobrecarga de recursos (procesos, memoria).
Estas consideraciones implicarán que la infraestructura técnica sobre la que se
implantará el sistema garantice una alta disponibilidad del mismo.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.10. Requerimiento no Funcional Preveer Contingencias Por Caída Del Sistema
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 38
4.3.3. Considerar El Crecimiento Esperado En El Volumen De Datos
La Figura A1.11 presenta el requerimiento no funcional con el formato
establecido.
Código Relevancia Clasificación Nombre
RNF-
003
Media Capacidad CONSIDERAR EL CRECIMIENTO
ESPERADO EN EL VOLUMEN DE
DATOS
Descripción
El sistema deberá garantizar el soporte en el crecimiento del volumen de la
información almacenada que se gestionará en la base de datos.
Deben realizarse estimaciones, mediciones y comparaciones para proyectar un
estimado de dicho crecimiento, y se presentarse las características de tecnología
requeridas para afrontar el crecimiento proyectado en el volumen.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.11. Requerimiento no Funcional Considerar El Crecimiento Esperado En El Volumen De Datos
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 39
4.3.4. Parametrizar Las Variables Del Sistema
La Figura A1.12 presenta el requerimiento no funcional con el formato
establecido.
Código Relevancia Clasificación Nombre
RNF-
004
Media Portabilidad PARAMETRIZAR LAS VARIABLES DEL
SISTEMA
Descripción
El sistema debe permitir que sus variables y eventos de conFigura A1.ción sean
parametrizables e independientes del código fuente.
La modificación de los parámetros configurables será planteada para que el
sistema tome sus cambios una vez reiniciado el servidor de aplicaciones y no en
tiempo de ejecución de tal manera que se disminuya el riesgo de perdida de
funcionalidad por configuraciones en el vuelo.
Se deberá emplear la tecnología estándar propuesta por Appengine de Google.
Las variables que se configurarán, o se presentarán en el archivo de configuración,
determinarán fuentes de datos y ubicación de recursos.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.12. Requerimiento no Funcional Parametrizar Las Variables Del Sistema
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 40
4.3.5. Diseñar interfaces con el usuario amigables
La Figura A1.13 presenta el requerimiento no funcional con el formato
establecido.
Código Relevancia Clasificación Nombre
RNF-
005
Media Amigabilidad DISEÑAR INTERFACES CON EL
USUARIO AMIGABLES
Descripción
El sistema debe poseer una interfaz gráfica uniforme a través del mismo
incluyendo pantallas, menús y opciones, tamaño de las pantallas, color, tipo de
letra y configuración de los campos de entrada.
El diseño debe realizarse guiado por las características generales, en cuanto a
colores institucionales y disposición de contenidos, encontradas en el sitio web de
la organización.
Las interfaces deben realizarse en idioma castellano; sin perjuicio de lo cual debe
evitar traducirse la terminología técnica específica que no posee una traducción
precisa al castellano.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.13. Requerimiento no Funcional Diseñar interfaces con el usuario amigables
4.3.6. Desarrollar manual de usuario
La Figura A1.14 presenta el requerimiento no funcional con el formato
establecido.
Código Relevancia Clasificación Nombre
RNF-
006
Alta Amigabilidad DESARROLLAR MANUAL DE
USUARIO
Descripción
Debe desarrollarse el Manual de Usuario del Sistema que especifique la totalidad
de la funcionalidad que éste provee.
Los contenidos del Manual deben estar ofrecidos 100% en línea, en formato
HTML.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.14. Requerimiento no Funcional Desarrollar manual de usuario
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 41
4.3.7. Codificar con estándares
La Figura A1.15 presenta el requerimiento no funcional con el formato
establecido.
Código Relevancia Clasificación Nombre
RNF-
007
Alta Portabilidad CODIFICAR CON ESTANDARES
Descripción
El código fuente del sistema debe cumplir con un estándar de codificación.
El estándar especificado debe considerar puntos como:
� Estándares de nombres utilizados en todos sus objetos: programas,
formas, tablas, campos, índices, procedimientos, paquetes.
� Empleo de las características del IDE Eclipse para el formato del código.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.15. Requerimiento no Funcional codificar con estándares
4.3.8. Permitir niveles de seguridad
La Figura A1.16 presenta el requerimiento no funcional con el formato
establecido.
Código Relevancia Clasificación Nombre
RNF-
008
Alta Seguridad PERMITIR NIVELES DE SEGURIDAD
Descripción
El sistema deberá permitir que toda su información junto con los procesos
desarrollados por el mismo tenga controles de acceso acordes con el nivel de
privacidad requerido.
Los niveles de seguridad estarán determinados por la distribución jerárquica de
los usuarios, a saber:
� Usuarios Administradores: Acceso total.
� Usuarios registrados : Podrán tener acceso al información, que
corresponda con su rol (líder de proyecto, colaborador o evaluador)
Control de Cambios
Fecha Solicitado por Descripción del cambio
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 42
Figura A1.16. Requerimiento no Funcional permitir niveles de seguridad
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 43
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.
Código Relevancia Clasificación Nombre
RST-001 Alta Restricciones ARQUITECTURA DEL SISTEMA
Descripción
El Sistema debe desarrollarse sobre la Arquitectura Web Appengine de Google
debiendo utilizarse exclusivamente recursos de software compatibles con ella.
Los requerimientos mínimos de la aplicación, corriendo en un servidor local se
presentan a continuación. Los requisitos de hardware del servidor pueden variar
según los requerimientos de rendimiento:
� Procesador 1.0 GHz
� 512 MB de RAM
Los requerimientos mínimos de software y hardware en el equipo cliente son:
� Navegador web compatible con Javascript (Recomendado IE7 o
posterior/Firefox 2.0 o posterior)
� Conexión a Internet, si la aplicación se ejecuta en Appspot de Google o
Interfaz de Red que soporte el protocolo TCP/IP para una conexión local.
Control de Cambios
Fecha Solicitado por Descripción del cambio
Figura A1.17. Restricción Arquitectura del Sistema
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 44
5. Modelo de análisis
5.1. Diagrama de Casos de Uso
La Figura A1.18 presenta el diagrama de Casos de Uso del sistema, basado en los
requerimientos funcionales desarrollados previamente: ud Casos de Uso
Administrador
Ev aluador
Lider de Proyecto
Colaborador de Proyecto
Crear Proyecto
Ev aluar Viabilidad
Crear Ev aluación
Validar usuario
Actualizar plantilla de evaluación
Asignar evaluador
Asignar Colaborador
Consultar Proyecto
Visitante
Consultar Evaluación
Inicializar ev aluación
«include»
«include»«include»
«include»
«include»
«include»
«include»
«include»
«include»
«include»
Figura A1.18. Restricción Arquitectura del Sistema
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 45
5.2. Matriz de trazabilidad Casos de Uso – Requerimientos
Funcionales
La Figura A1.19 muestra la matriz de trazabilidad que permite relacionar los
casos de uso del sistema con los requerimientos funcionales, permitiendo conocer
que requerimientos funcionales resuelve cada caso de uso.
Caso de Uso Requerimiento
Funcional
Id Nombre Id
CU-001 Validar usuario --
CU-002 Asignar evaluador RF–007
CU-003 Actualizar planilla de evaluación RF–005
CU-004 Evaluar viabilidad RF–003
CU-005 Crear evaluación RF–002
CU-006 Consultar proyecto RF–004
CU-007 Consultar evaluación RF–004
CU-008 Crear proyecto RF–001
CU-009 Asignar colaborador RF–006
CU-010 Inicializar Evaluación RF–005 Figura A1.19. Matriz de trazabilidad Casos de Uso – Requerimientos funcionales
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 46
5.3. Realización de los Casos de Uso
A continuación se presenta la realización de cada uno de los casos de uso del
sistema.
5.3.1. Validar Usuario
La Figura A1.20 presenta el caso de uso con el formato establecido.
ID CU-001
Nombre VALIDAR USUARIO
Fecha Creación 16/11/2008 Fecha última modificación
16/11/2008
Actores -
Descripción El sistema verifica que el usuario posea el rol correcto para
realizar una tarea.
Trigger El usuario intenta realizar una acción en el sistema.
Precondiciones
Postcondiciones El operador se encuentra validado en el sistema.
Flujo principal CU-001.0
1. El sistema presenta una pantalla que invita al
usuario a ingresar su nombre y contraseña para
autenticarse.
2. El usuario ingresa su nombre y contraseña y
presiona el botón “ingresar”.
3. El sistema verifica los roles que posee el usuario en
el sistema (visitante, líder de proyecto, colaborador
o evaluador).
4. El sistema notifica al usuario que está autenticado.
Flujos
alternativos
CU-001.1
1. Si el usuario ingresa su nombre y contraseña de
manera incorrecta el sistema lo notifica y le solicita
ingresar los datos nuevamente, volviendo a CU-
001.0
Excepciones
Extensiones -
Incluye -
Heredado por -
Prioridad Alta
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 47
Reglas de
Negocio -
Requerimientos
especiales
Hipótesis
Notas Figura A1.20. Caso de uso validar Usuario
5.3.2. Asignar evaluador
La Figura A1.21 presenta el caso de uso con el formato establecido.
ID CU-002
Nombre ASIGNAR EVALUADOR
Fecha Creación 16/11/2008 Fecha última modificación
16/11/2008
Actores � Administrador
Descripción El administrador del sistema designa a un usuario con el rol
de evaluador para que pueda modificar la plantilla estándar
de evaluación.
Trigger El administrador accede a la opción agregar evaluador
Precondiciones � El administrador ha iniciado sesión en el sistema.
Postcondiciones � Un nuevo usuario cuenta con el rol de evaluador.
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 e-
mail del usuario a registrar como evaluador.
3. El administrador ingresa el e-mail del usuario.
4. El sistema agrega al usuario como evaluador y
notifica al administrador
Flujos
alternativos
CU-002.1
El sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
Excepciones -
Extensiones -
Incluye � CU-001. Validar Usuario
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 48
Heredado de -
Prioridad � Alta
Reglas de
Negocio RF-007
Requerimientos
especiales -
Hipótesis -
Notas - Figura A1.21. Caso de uso asignar evaluador
5.3.3. Actualizar planilla de evaluación
La Figura A1.22 presenta el caso de uso con el formato establecido.
ID CU-003
Nombre ACTUALIZAR PLANILLA DE EVALUACIÓN
Fecha Creación 16/11/2008 Fecha última
modificación 16/11/2008
Actores � Evaluador
Descripción El usuario evaluador actualiza las preguntas de la planilla
estándar de evaluación, es la fuente de las futuras
evaluaciones de viabilidad de todos los proyectos.
Trigger El evaluador accede a la opción actualizar planilla
Precondiciones � El usuario debe contar con el rol de evaluador
Postcondiciones � La planilla de evaluación estándar queda
actualizada
Flujo principal CU-003.0
1. El sistema verifica que el usuario sea evaluador. De
no cumplirse se ejecuta el flujo alternativo CU-
003.1.
2. El sistema presenta un formulario que muestra la
información de todas las preguntas de la plantilla
estándar con la posibilidad de modificar la
descripción, el peso y la dimensión.
3. El evaluador actualiza todos los parámetros de
todas las preguntas que consideren necesario y
enviar formulario.
4. El sistema actualiza la plantilla estándar y notifica
al evaluador
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 49
Flujos
alternativos
CU-003.1
� el sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
Excepciones -
Extensiones -
Incluye � CU-001. Validar Usuario
Heredado de -
Prioridad � Alta
Reglas de
Negocio RF-005
Requerimientos
especiales -
Hipótesis -
Notas - Figura A1.22. Caso de uso actualizar planilla de evaluación
5.3.4. Evaluar viabilidad
La Figura A1.23 presenta el caso de uso con el formato establecido.
ID CU-004
Nombre EVALUAR VIABILIDAD
Fecha Creación 16/11/2008 Fecha última
modificación 16/11/2008
Actores � Líder de proyecto
� colaborador
Descripción El sistema le permite al usuario creador de una evaluación
que se encuentra en el estado de "en ejecución" continuar
con la misma, presentándole la interfaz correspondiente.
Trigger El líder de proyecto o colaborador accede a la opción
continuar evaluación.
Precondiciones � El usuario debe contar con el rol de colaborador en
el proyecto en el cual desea continuar la
evaluación.
Postcondiciones � La evaluación queda actualizada con los pasos del
cuestionario cargados
Flujo principal CU-004.0
1. El sistema verifica que el usuario sea colaborador
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 50
del proyecto al cual pertenece la evaluación. De no
cumplirse se ejecuta el flujo alternativo CU-004.1.
2. Se repite el siguiente ciclo hasta que el colaborador
completa la última pregunta del cuestionario o
abandona el cuestionario dejándolo incompleto.
a. El sistema presenta todas las preguntas y
respuestas contestadas hasta el momento.
b. El sistema presenta un formulario que
muestra la próxima pregunta del
cuestionario.
c. El colaborador contesta la pregunta.
3. Si el usuario completo todo el cuestionario el
sistema muestra el resultado de la evaluación,
ejecutando el caso de uso CU-007.
Flujos
alternativos
CU-004.1
� El sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
Excepciones -
Extensiones -
Incluye CU-001. Validar Usuario
CU-007. Consultar evaluación
Heredado por -
Prioridad Alta
Reglas de Negocio
RF-003
Notas - Figura A1.23. Caso de uso evaluar viabilidad
5.3.5. Crear evaluación
La Figura A1.24 presenta el caso de uso con el formato establecido.
ID CU-005
Nombre CREAR EVALUACIÓN
Fecha Creación 16/11/2008 Fecha última
modificación 16/11/2008
Actores � Colaborador
Descripción El sistema le permite al usuario colaborador crear una
evaluación en un proyecto al cual pertenece.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 51
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
� 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
CU-004. Evaluar viabilidad
Heredado por -
Prioridad Alta
Reglas de
Negocio RF-002
Requerimientos especiales
-
Hipótesis -
Notas - Figura A1.24. Caso de uso Crear evaluación
5.3.6. Consultar proyecto
La Figura A1.25 presenta el caso de uso con el formato establecido.
ID CU-006
Nombre CONSULTAR PROYECTO
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 52
Fecha Creación 16/11/2008 Fecha última
modificación 16/11/2008
Actores � 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
El sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
Excepciones -
Extensiones -
Incluye � CU-001 : Validar Usuario
Heredado de -
Prioridad Alta
Reglas de
Negocio RF-004
Requerimientos
especiales -
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 53
Hipótesis -
Notas - Figura A1.25. Caso de uso consultar proyecto
5.3.7. Consultar Evaluación
La Figura A1.26 presenta el caso de uso con el formato establecido.
ID CU-007
Nombre COSULTAR EVALUACIÓN
Fecha Creación 16/11/2008 Fecha última modificación
16/11/2008
Actores � 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
El sistema notifica al usuario que no cuenta con los
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 54
permisos suficientes para llevar a cabo la tarea.
Excepciones -
Extensiones -
Incluye � CU-001 : Validar Usuario
Heredado de -
Prioridad Alta
Reglas de
Negocio RF-004
Requerimientos especiales
-
Hipótesis -
Notas - Figura A1.26. Caso de uso consultar evaluación
5.3.8. Crear proyecto
La Figura A1.27 presenta el caso de uso con el formato establecido.
ID CU-008
Nombre CREAR PROYECTO
Fecha Creación 16/11/2008 Fecha última
modificación 16/11/2008
Actores � Visitante
Descripción El sistema le permite a un usuario registrado crear un nuevo
proyecto y convertirse en su líder.
Trigger El usuario accede a la opción crear nuevo proyecto.
Precondiciones -
Postcondiciones � El proyecto queda creado.
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 -
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 55
Incluye CU-001. Validar Usuario
Heredado por -
Prioridad Alta
Reglas de
Negocio RF-001
Requerimientos especiales
Hipótesis
Notas Figura A1.27. Caso de uso Crear proyecto
5.3.9. Asignar colaborador
La Figura A1.28 presenta el caso de uso con el formato establecido.
ID CU-009
Nombre ASIGNAR COLABORADOR
Fecha Creación 16/11/2008 Fecha última
modificación 16/11/2008
Actores � 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
alternativo CU-009.1.
2. El sistema presenta un formulario que solicita el e-
mail del usuario a registrar como colaborador.
3. El líder del proyecto ingresa el e-mail del usuario.
4. El sistema agrega al usuario como colaborador y
notifica al líder del proyecto
Flujos
alternativos
CU-009.1
El sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 56
Excepciones -
Extensiones -
Incluye � CU-001. Validar Usuario
Heredado por -
Prioridad � Alta
Reglas de Negocio
RF-006
Requerimientos
especiales
Hipótesis
Notas Figura A1.28. Caso de uso asignar colaborador
5.3.10. Inicializar cuestionario
La Figura A1.29 presenta el caso de uso con el formato establecido.
ID CU-010
Nombre INICIALIZAR CUESTIONARIO
Fecha Creación 05/03/2009 Fecha última
modificación 05/03/2009
Actores � Administrador
Descripción El administrador del sistema inicializa la Plantilla estándar
de evaluación de proyectos con los valores
predeterminados.
Trigger El administrador accede a la opción de inicializar Plantilla
devaluación.
Precondiciones � El administrador ha iniciado sesión en el sistema.
Postcondiciones � La Plantilla estándar de evaluación de proyectos se
encuentra inicializada con los valores por defecto.
Flujo principal CU-009.0
1. El sistema verifica que el usuario sea
administrador. De no cumplirse se ejecuta el flujo
alternativo CU-010.1.
2. El sistema presenta un formulario que solicita al
administrador del sistema su confirmación para
inicializar la Plantilla de evaluación con los valores
por defecto.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 57
3. Si el administrador contesta “sí” entonces se
ejecuta el flujo alternativo CU-009.2. Si el
administrador contesta “no” se ejecuta el flujo
alternativo CU-009.3
Flujos
alternativos
CU-009.1
El sistema notifica al usuario que no cuenta con los
permisos suficientes para llevar a cabo la tarea.
CU-009.2
El sistema inicializa la Plantilla de 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 � CU-001. Validar Usuario
Heredado por -
Prioridad � Alta
Reglas de
Negocio RF-005
Requerimientos
especiales
Hipótesis
Notas Figura A1.29. Caso de uso inicializar cuestionario
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 58
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 59
� 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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 60
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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 61
permitan desarrollar una aplicación dentro de la arquitectura. Algunos de los
servicios dentro de la categoría son:
� Persistencia de entidades.
� Acceso a archivos del sistema operativo.
� Motor de plantillas para representación de página web dinámicas.
� Autenticación de usuarios.
Estos servicios son parte de la infraestructura de la aplicación y, generalmente,
son consumidos por una o más de las tres categorías de MVC.
pd Paquetes
dbmodel
+ Answer
+ Evaluation
+ EvaluationInstance
+ Evaluator
+ NextQuestion
+ Project
+ ProjectMember
+ Question
+ Result
google.appengine.ext
+ db
+ webapp
+ webapp.template
google.appengine.api
+ users
v iew
+ CustomView
+ EvaluationDraw
menu
+ menu
evaluatorform
+ AddMemberPage
+ Evaluate
+ MainPage
Figura A1.32. Diagrama de paquetes de la aplicación categorizados por color
Por simplicidad para el entendimiento se ha omitido la representación en el
diagrama todos los paquetes de la categoría controlador del sistema, incluyendo
solamente el paquete controlador evaluatorform. Para una descripción detallada
de cada uno de los paquetes controladores debe leerse la sección 7.4 de este
documento.
Infraestructura
Modelo
Vista
Controlador
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 62
La Figura A1.33 describe brevemente todos los paquetes que se han desarrollado
en el sistema y qué casos de uso implementa cada uno. No se describen los
paquetes de infraestructura ya que han sido muy bien documentados por
Appengine.
Nuevamente la columna tipo permite identificar la categoría a través de su color
asociado.
Nombre Tipo CU que
implementa
Descripción
dbmodel Modelo Todos Contiene las clases que
implementan el modelo de la
aplicación, incluyendo su
persistencia.
view Vista - Implementa funciones
genéricas de representación
de los datos en formato
HTML.
evaluatorform Controlador CU-004
CU-005
CU-007
Creación, ejecución y cálculo
de una evaluación de
viabilidad para un proyecto.
choose_project Controlador CU-008 Selección de un proyecto.
view_project Controlador CU-006
CU-009
Creación y consulta en
proyecto.
add_evaluator Controlador CU-002 Agregar evaluadores.
help Controlador CU-001 Inicio y cierre de sesión el
sistema. Manual de Usuario.
data Controlador CU-003 dos
CU-010
Inicialización de datos.
Figura A1.33. Trazabilidad entre paquetes y casos de uso
7.2. dbmodel. La capa De dominio
La capa de dominio, se encarga de modelar la lógica del estudio de viabilidad,
incluyendo aquellas clases que son consideradas entidades y, por ende, deben ser
persistentes.
Esta capa se desarrolla dentro del componente de Modelo y Persistencia de
Appengine. Dentro de la misma existen dos niveles de los cuales uno de ellos está
acoplado al otro y usa sus servicios para resolver el estudio:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 63
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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 64
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:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 65
cd Modelo
db.Model
Question
+ category: db.TextProperty+ description: db.TextProperty+ dimension: db.TextProperty+ idquestion: db.IntegerProperty+ thresholdvalue: db.TextProperty+ type: db.TextProperty+ weight: db.IntegerProperty
+ dimensionText()+ nextQuestions() : q:Question[]+ validAnswers() : a: Answer[]
db.Model
NextQuestion
+ idanswer: db.IntegerProperty+ idnextquestion: db.IntegerProperty+ idquestion: db.IntegerProperty
+ answer() : Answer+ nextQuestion() : Question+ question() : Question
db.Model
Answer
+ description: db.TextProperty+ idanswer: db.IntegerProperty
db.Model
Project
+ createdate: db.DateTimeProperty+ description: db.TextProperty+ owner: db.UserProperty+ releasedate: db.DateTimeProperty+ testdate: db.DateTimeProperty
+ addEvaluation(string, Evaluation)+ addMember(string, string)+ currentUserIsMember()+ getEvaluations() : Evaluation[]+ removeMember(string, string)+ userIsMember(string)
db.Model
Ev aluation
+ actualresult: db.IntegerProperty+ createdate: db.DateTimeProperty+ description: db.TextProperty+ idproject: db.ReferenceProperty(Project)+ owner: db.UserProperty
+ calculate() : Result+ isComplete() : bool+ lastQuestion() : Question+ nextQuestion() : Question+ questions() : Question[]
Result
+ adaptabilidad: array[4]+ completo: bool+ exito: array[4]+ justificacion: array[4]+ plausibidad: array[4]+ resultado: array[4]
+ A() : float+ E() : float+ J() : float+ P() : float+ viability(var)
db.Model
Ev aluationInstance
+ description: db.TextProperty+ dimension: db.TextProperty+ idanswer: db.IntegerProperty+ idevaluation: db.ReferenceProperty(Evaluation)+ idinstance: db.IntegerProperty+ idquestion: db.IntegerProperty+ thresholdvalue: db.TextProperty+ type: db.TextProperty+ weight: db.IntegerProperty
+ answerText(var)+ dimensionText(var)
Nivel 2. Estudio de Viabi lidad
Nivel 1. Questionario
db.Model
ProjectMember
+ idproject: db.ReferenceProperty(Project)+ member: db.UserProperty+ role: db.TextProperty()
db.Model
Ev aluator
+ evaluator: db.UserProperty
+ all (Evaluator[])+ remove(string)+ userIsEvaluator(var)
User
+ email: Text+ nickname: Text
Provisto por el User API de Appengine
1
1
1
1
1
1
1
1
*
1
111 1
1Evaluation Result
1
1
1
*
questions
1
*
evaluations
1
Figura A1.35. Diagrama de clases del paquete dbmodel
El Nivel 1 del modelo está implementado por las siguientes clases:
� Question: implementa la pregunta con todos sus atributos (identificador de
pregunta, categoría de la metodología P3TQ, texto de la pregunta, dimensión
de la viabilidad, umbral, tipo y peso). El tipo de pregunta permite conocer
cuáles son las posibles respuestas admitidas. Por ejemplo el tipo booleano
solamente admitir a valores “si” y “no”. Mientras que el tipo “ difuso”
admitirá los valores "ninguno", "muy poco", "medio", "alto", "muy alto". Esta
clase representa, entonces, los vértices del grafo.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 66
� 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,
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 67
dada una dirección de correo electrónico, si un usuario posee el rol de
evaluador o no.
7.3. View. Paquete de soporte para vista.
Las clases pertenecientes a este paquete, que se muestran en la Figura A1.36,
tienen la responsabilidad de generar contenidos para la interfaz de usuario. cd v iew
object
Ev aluationDraw
+ accepted: bool = 60+ draw: bool+ evaluation: Evaluation+ maxsize: int = 100
+ createArray(Evaluation[]) : EvaluationDraw[]+ drawA() : string+ drawBar(int) : string+ drawE() : string+ drawJ() : string+ drawP() : string+ drawViabili ty() : string+ getEvaluation() : Evaluation+ setEvaluation(Evaluation)
object
CustomMenu
+ getCustomMenu() : string
Logical Model::User
+ email: Text+ nickname: Text
db.Model
Logical Model::Ev aluator
+ evaluator: db.UserProperty
+ all(Evaluator[])+ remove(string)+ userIsEvaluator(var)
1 1
Figura A1.36. Diagrama de clases del paquete view
� EvaluationDraw: Esta clase tienen la responsabilidad de generar un gráfico
de barras en código HTML de cada una de las dimensiones de una evaluación,
desacoplando la responsabilidad de dibujo en la clase de dominio. Almacena
un objeto de la clase Evaluation (atributo evaluation), el tamaño máximo de
escala (atributo maxsize). Existe una operación de clase que funciona como
factory para crear una colección de objetos EvaluationDraw a partir de una
colección de objetos Evaluation. El motor de renderización de la vista (django),
entonces, utiliza objetos EvaluationDraw, con los cuales puede acceder a toda
la información de una evaluación y, además, podrá dibujar gráfico de barras
con dicho información. Las operaciones de dibujo son DrawBar, que permite
dibujar un gráfico de barras genérico, a partir de un valor resultado entre cero
y 10. Las operaciones drawP, drawA, drawJ, drawE y drawViability permiten
dibujar gráfico de barras para las dimensiones de plausibilidad a,
adaptabilidad, justificación, éxito y el resultado final de viabilidad
respectivamente.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 68
� 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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 69
pd ev aluatorform
MainPage
+ get() : void+ put() : void+ redirect(string) : void
AddMemberPage
+ get() : void+ put() : void+ redirect(string) : void
Ev aluate
+ get() : void+ put() : void+ redirect(string) : void
Logical Model::webapp.
RequestHandler
+ request: + response:
+ get() : void+ put() : void+ redirect(string) : void
ev aluatorform.htmlerror.html evaluate.htmlv iew_project.html
Figura A1.37. Diagrama de clases del paquete evaluatorform
Las clases de este paquete son:
� AddMemberPage: esta clase tiene la responsabilidad de agregar o eliminar a
un colaborador del proyecto.
� MainPage: esta clase tiene la responsabilidad de recibir las respuestas de cada
pregunta del cuestionario de evaluación, a guardar las y presentarle al usuario
la próxima pregunta a responder.
� Evaluate: esta clase tiene la responsabilidad de presentarle al usuario el
resultado de un estudio de viabilidad para una evaluación finalizada.
7.4.2. Add Evaluator
La Figura A1.38 muestra las clases que componen este paquete.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 70
cd add_ev aluator
webapp.RequestHandler
MainPage
+ get() : void+ put() : void+ redirect(string) : void
webapp.RequestHandler
+ request: + response:
+ get() : void+ put() : void+ redirect(string) : void
add_ev aluator.html
error.html
Figura A1.38. Diagrama de clases del paquete add_evaluator
Las clases de este paquete son:
� MainPage: esta clase tiene la responsabilidad de agregar o eliminar un
evaluador del sistema, que puede modificar la plantilla de evaluación de
proyectos.
7.4.3. Choose_project
La Figura A1.39 muestra las clases que componen este paquete.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 71
cd choose_project
webapp.RequestHandlerwebapp.RequestHandler
MainPage
+ get() : void+ put() : void+ redirect(string) : void
webapp.RequestHandler
+ request: + response:
+ get() : void+ put() : void+ redirect(string) : void
choose_project.html
Figura A1.39. Diagrama de clases del paquete choose_project
Las clases de este paquete son:
� MainPage: esta clase tiene la responsabilidad de seleccionar todos 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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 72
7.4.4. Help
La Figura A1.40 muestra las clases que componen este paquete. cd help
webapp.RequestHandler
AboutPage
+ get() : void+ put() : void+ redirect(string) : void
webapp.RequestHandler
LogoutPage
+ get() : void+ put() : void+ redirect(string) : void
webapp.RequestHandler
LoginPage
+ get() : void+ put() : void+ redirect(string) : void
webapp.RequestHandler
+ request: + response:
+ get() : void+ put() : void+ redirect(string) : void
about.html login.htmllogout.html
Figura A1.40. Diagrama de clases del paquete help
Las clases de este paquete son:
� AboutPage: esta clase tiene la responsabilidad de presentarle al usuario el
manual de ayuda.
� LoginPage: esta clase tiene la responsabilidad de autenticar al usuario,
abriendo la sesión en caso de que los datos de ingreso se han correctos.
� LogoutPage: esta clase tiene la responsabilidad de cerrar la sesión de un
usuario.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 73
7.4.5. View_project
La Figura A1.41 muestra las clases que componen este paquete. cd v iew_project
webapp.RequestHandlerwebapp.RequestHandlerwebapp.RequestHandler
MainPage
+ get() : void+ put() : void+ redirect(string) : void
webapp.RequestHandler
+ request: + response:
+ get() : void+ put() : void+ redirect(string) : void
v iew_project.htmlv iew_project.csv
Figura A1.41. Diagrama de clases del paquete view_project
Las clases de este paquete son:
� MaintPage: esta clase tiene la responsabilidad de recuperar y mostrar al
usuario toda la información de un proyecto y de crear nuevas evaluaciones.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 74
7.5. Diagramas de Secuencia
A continuación se presentan los diagramas de secuencia que permiten
comprender cómo colaboran las clases de las distintas categorías (modelo, pista,
controlador e infraestructura) para resolver la funcionalidad requerida.
Se han incluido aquellas secuencias que se consideran fundamentales para el
sistema. Las restantes se resuelven de manera análoga a las presentadas o son
muy simples de implementar por lo cual su representación gráfica no agrega
valor.
Además del diagrama se describirán brevemente los escenarios dentro de los
cuales transcurre cada secuencia.
7.5.1. Crear Proyecto
� Escenario: El usuario ha iniciado sesión en el sistema. Se encuentra frente a la
pantalla de selección de proyectos y desea crear un nuevo proyecto,
completando una descripción para el mismo y enviando el formulario. Se
considera que no ocurren errores o excepciones. A continuación se presenta en
la Figura A1.42 el diagrama de secuencia. sd Crear Proyecto
Usuario choose_project view_project::MainPage
LogicalModel::Project
users
view_project
POST(description)
post(description)
user:= get_current_user
project:= <<new>> description, user
put()
render(project)
render
Figura A1.42. Diagrama de secuencia Crear proyecto.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 75
7.5.2. Crear Evaluación
� Escenario: El usuario ha iniciado sesión en el sistema y ha seleccionado un
proyecto. Se encuentra frente a la pantalla de consulta de dicho proyecto y
desea agregar una nueva evaluación, ingresando, para ello, una descripción
para la nueva evaluación y enviando el formulario. Se considera que no
ocurren errores o excepciones. A continuación se presenta en la Figura A1.43
el diagrama de secuencia. sd Crear Ev aluacion
Miembro view_project evaluatorform::evaluate
users
LogicalModel::Evaluation
run
POST(create,idproject,description)
post(create,idproject,description)
user:= get_current_user
eval:= <<new>>(idproject,user,description)
put()
q:= questions()
nq:= nextQuestion()
render(idproject,eval,q,nq)
render
Figura A1.43. Diagrama de secuencia Crear evaluación.
7.5.3. Contestar Pregunta
� Escenario: El usuario ha iniciado sesión en el sistema, ha seleccionado un
proyecto y ha creado una nueva evaluación para el mismo, o retomado una
evaluación previamente creada y aún no completada. Se encuentra frente a la
pantalla de ejecución de la evaluación y desea completar la siguiente pregunta
del cuestionario. Selecciona entonces la respuesta que considera correcta y
envía el formulario. Se considera que no ocurren errores o excepciones. A
continuación se presenta en la Figura A1.44 el diagrama de secuencia.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 76
sd Contestar Pregunta
Miembro run evaluatorform::evaluate
db eval :Evaluation
ev :EvaluationInstance
Si la evaluación está completa.
POST(idevaluation,idanswer)
post(idevaluation,idanswer)
eval:= get(idevaluation)
nq:= nextQuestion()
ev:= <<new>> (idanswer, eval, nq.weight, nq.dimension)
put()
q:= questions()
nq2:= nextQuestion()
idproject:= idproject
[eval.isComplete==false]: render(idproject,eval,nq2,q)
render
Figura A1.44. Diagrama de secuencia contestar pregunta.
7.5.4. Calcular Evaluación
� Escenario: El usuario ha iniciado sesión en el sistema, ha seleccionado un
proyecto y ha seleccionado una evaluación completa, o retomado una
evaluación previamente creada y aún no completada. Se encuentra frente a la
pantalla de ejecución de la evaluación y desea completar la siguiente pregunta
del cuestionario. Selecciona entonces la respuesta que considera correcta y
envía el formulario. Se considera que no ocurren errores o excepciones. A
continuación se presenta en la Figura A1.45 el diagrama de secuencia. sd Calcular Ev aluación
Miembro evaluate evaluatorform::evaluate
eval :Evaluation
Si la evaluación está completa.
[eval.isComplete]: result:= calculate()
render(eval,q,result)
render
Figura A1.45. Diagrama de secuencia Calcular Evaluación.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 77
7.6. Secuencia entre Pantallas
Las pantallas del sistema han sido presentadas separadamente en cada uno de los
diagramas de clase del controlador.
El diagrama que se muestra a continuación la Figura A1.46 permite ver, a través
de un diagrama de estados UML, como se relacionan entre sí a partir de la
interacción del usuario con el sistema. sm Statecharts
choose_project
v iew_project
add_ev aluator
ev aluate
Logout
run
about
login
edit
clear
ayuda
nueva evaluación carga de pregunta del cuestionario
agregar evaluador (usuario administrador)
evaluación completa
ejecución de evaluaciónagregado de nuevo colaborador
creación de un proyecto
selección de evaluación finalizada
selección de un proyecto
abrir sesión
cerrar sesión
editar plantil la de evaluación
Inicial izar planti lla de evaluación
Figura A1.46. Diagrama de estados para la transición entre las pantallas del sistema.
A continuación se presentan cada una de las pantallas que componen el sistema, y
las interfaces con el usuario.
7.6.1. Logout
Esta pantalla, mostrada en la Figura A1.47, se presenta cuando el usuario desea
ingresar al sistema y aún no sea autenticado, o cuando decide salir, cerrando la
sesión.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 78
Figura A1.47. Pantalla Logout.
7.6.2. Login
Esta pantalla, mostrada en la Figura A1.48, es provista por el API user del
appengine, para que el usuario pueda autenticar se en el tenga a través de su e-
mail y contraseña.
Figura A1.48. Pantalla Login.
7.6.3. Choose Project
Esta pantalla, mostrada en la Figura A1.49, presenta al usuario una tabla con los
proyectos existentes en el sistema, mostrando la fecha de creación, la descripción,
el e-mail del líder del proyecto, la cantidad de evaluaciones realizadas y el rol que
tiene el usuario en dicho proyecto. El usuario puede elegir cualquiera de los
proyectos para consultar la información existente. También presenta una interfaz
para que el usuario pueda crear un nuevo proyecto ingresando un nombre para el
mismo.
Figura A1.49. Pantalla Choose Project.
7.6.4. View Project
Esta pantalla, mostrada en la Figura A1.50 presenta al usuario toda la
información referente a un proyecto que él ha seleccionado. Muestra la
información de fecha de creación, líder de proyecto, colaboradores y evaluaciones
realizadas. Para estas últimas muestra la fecha de creación, descripción, autor y, si
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 79
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 80
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 81
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 82
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 83
El cliente se comunica con el servidor a través de un navegador web, utilizando el
protocolo http. dd Despliegue
appengine Serv er
choose_project
datadbmodel
ev aluatorform
help
v iew
v iew_project
menu
cliente (webbrowser)
http
Figura A1.58. Diagrama de Despliegue.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 84
8. Casos de Prueba
En esta sección se desarrollan los casos de prueba planificados y ejecutados
satisfactoriamente que surgen de los escenarios más importantes de cada caso de
uso.
8.1. Validar Usuario
A continuación se presentan los casos de prueba correspondientes a los diferentes
escenarios del caso de uso CU-001 : Validar usuario.
8.1.1. Inicio de sesión exitoso
La Figura A1.59 nuestra el caso de prueba inicio de sesión exitoso.
Identificación CP-001 : Inicio de sesión exitoso
Caso de Uso
que lo origina CU-001
Escenario El usuario intenta iniciar sesión en el sistema.
Datos de
Entrada El usuario ingresa un e-mail y contraseña válidos (cuentas
activas en google)
Resultado Esperado
El usuario inicia sesión el sistema.
Estado Ejecutado correctamente. Figura A1.59. Caso de prueba inicio de sesión exitoso
8.1.2. Inicio de sesión fallido
La Figura A1.60 nuestra el caso de prueba inicio de sesión fallido.
Identificación CP-002: Inicio de sesión fallido
Caso de Uso
que lo origina CU-001
Escenario El usuario intenta iniciar sesión en el sistema.
Datos de
Entrada El usuario ingresa las siguientes combinaciones de e-mail y
contraseña:
� E-mail válido y contraseña inválida.
� E-mail y contraseña inválidas.
� E-mail inválido y contraseña de algún usuario
válido.
� E-mail y contraseña nulos.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 85
� E-mail nulo y contraseña correcta.
� E-mail válido y contraseña nula.
Resultado
Esperado El sistema notifica error en el inicio de sesión.
Estado Ejecutado correctamente. Figura A1.60. Caso de prueba inicio de sesión fallido
8.2. Asignar evaluador
A continuación se presentan los casos de prueba correspondientes a los diferentes
escenarios del caso de uso CU-002 : Asignar Evaluador.
8.2.1. Administrador agrega nuevo evaluador
La Figura A1.61 nuestra el caso de prueba Administrador agrega nuevo
evaluador.
Identificación CP-003 : Administrador agrega nuevo evaluador
Caso de Uso que lo origina
CU-002
Escenario El administrador accede a la pantalla para agregar un nuevo
usuario evaluador.
Datos de Entrada
El administrador ingresa un e-mail válido (cuenta activa en
google)
Resultado
Esperado El usuario evaluador queda registrado en el sistema.
Estado Ejecutado correctamente. Figura A1.61. Caso de prueba Administrador agrega nuevo evaluador
8.2.2. Administrador intenta agregar evaluador registrado
La Figura A1.62 nuestra el caso de prueba Administrador intenta agregar
evaluador registrado.
Identificación CP-004 : Administrador intenta agregar evaluador registrado
Caso de Uso que lo origina
CU-002
Escenario El administrador accede a la pantalla para agregar un
usuario evaluador, que ya fue registrado previamente en el
sistema.
Datos de El administrador ingresa un e-mail válido, que ya fue
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 86
Entrada registrado previamente (cuenta activa en google)
Resultado Esperado
El sistema notifica que el e-mail ya ha sido registrado.
Estado Ejecutado correctamente. Figura A1.62. Caso de prueba Administrador intenta agregar evaluador registrado
8.2.3. Administrador intenta agregar evaluador con e-mail nulo
La Figura A1.63 nuestra el caso de prueba Administrador intenta agregar
evaluador con e-mail nulo.
Identificación CP-005 : Administrador intenta agregar evaluador con e-mail
nulo
Caso de Uso
que lo origina CU-002
Escenario El administrador accede a la pantalla para agregar un nuevo
usuario evaluador.
Datos de
Entrada El administrador envía el formulario sin ingresar un e-mail
Resultado
Esperado El sistema notifica que el e-mail no es válido, debido a que es
nulo.
Estado Ejecutado correctamente. Figura A1.63. Caso de prueba Administrador intenta agregar evaluador con e-mail nulo
8.2.4. Usuario intenta agregar evaluador
La Figura A1.64 nuestra el caso de prueba Usuario intenta agregar evaluador.
Identificación CP-006 : Usuario intenta agregar evaluador
Caso de Uso
que lo origina CU-002
Escenario Un usuario, que no cuenta con el rol de administrador,
accede a la pantalla para agregar un nuevo usuario
evaluador.
Datos de
Entrada Ninguno
Resultado
Esperado El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la acción.
Estado Ejecutado correctamente. Figura A1.64. Caso de prueba Usuario intenta agregar evaluador
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 87
8.3. Actualizar planilla de evaluación
A continuación se presentan los casos de prueba correspondientes a los diferentes
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
que lo origina CU-003
Escenario Un usuario evaluador accede a la pantalla modificar las
preguntas del cuestionario de la plantilla de evaluación.
Datos de
Entrada El usuario evaluador modifica los siguientes datos de las
preguntas:
� modifica el texto de la Descripción
� modifica el peso (valor entero entre 0 y 10)
� modifica la dimensión
Resultado Esperado
El sistema actualiza los datos de la pregunta y notifica al
usuario.
Estado Ejecutado correctamente. Figura A1.65. Caso de prueba Evaluador actualiza pregunta
8.3.2. Evaluador intenta actualizar pregunta con datos incorrectos
La Figura A1.66 nuestra el caso de prueba Evaluador intenta actualizar pregunta
con datos incorrectos.
Identificación CP-008 : Evaluador intenta actualizar pregunta con datos
incorrectos
Caso de Uso
que lo origina CU-003
Escenario Un usuario evaluador accede a la pantalla modificar las
preguntas del cuestionario de la plantilla de evaluación.
Datos de
Entrada El usuario evaluador modifica los datos de las preguntas,
con cada uno de los valores enunciados a continuación :
� descripción nula
� peso incorrecto (mayor a 10 y/o alfanumérico)
Resultado
Esperado El sistema y notifica al usuario que los datos ingresados son
incorrectos.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 88
Estado Ejecutado correctamente. Figura A1.66. Caso de prueba Evaluador intenta actualizar pregunta con datos incorrectos
8.3.3. Usuario intenta actualizar pregunta
La Figura A1.67 nuestra el caso de prueba Usuario intenta actualizar pregunta.
Identificación CP-009 : Usuario intenta actualizar pregunta
Caso de Uso
que lo origina CU-003
Escenario Un usuario, que no cuenta con el rol de evaluador, accede a
la pantalla para modificar las preguntas del cuestionario de
la plantilla de evaluación.
Datos de
Entrada Ninguno
Resultado
Esperado El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la acción.
Estado Ejecutado correctamente. Figura A1.67. Caso de prueba Usuario intenta actualizar pregunta
8.4. Evaluar viabilidad
A continuación se presentan los casos de prueba correspondientes a los diferentes
escenarios del caso de uso CU-004: Evaluar viabilidad.
8.4.1. Proyecto altamente viable
La Figura A1.68 nuestra el caso de prueba Proyecto altamente viable.
Identificación CP-010 : Proyecto altamente viable
Caso de Uso que lo origina
CU-004
Escenario Un miembro del proyecto accede a la pantalla que permite
continuar la ejecución de una evaluación creada por él.
Datos de Entrada
� El miembro del proyecto contesta Si o Todo (Si) en
cada una de las preguntas.
Resultado
Esperado El sistema muestra como resultado de viabilidad:
� Vector Justificación = (10;10;10;10)
� Resultado Justificación = 10
� Vector éxito = (10;10;10;10)
� Resultado éxito = 10
� Vector adaptabilidad = (10;10;10;10)
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 89
� Resultado adaptabilidad = 10
� Vector plausibilidad = (10;10;10;10)
� Resultado plausibilidad = 10
� Vector Viabilidad = (10;10;10;10)
� Resultado viabilidad = 10
Estado Ejecutado correctamente. Figura A1.68. Caso de prueba Proyecto altamente viable
8.4.2. Proyecto no viable rotundamente
La Figura A1.69 nuestra el caso de prueba Proyecto no viable rotundamente.
Identificación CP-011 : Proyecto no viable rotundamente
Caso de Uso
que lo origina CU-004
Escenario Un miembro del proyecto accede a la pantalla que permite
continuar la ejecución de una evaluación creada por él.
Datos de
Entrada El miembro del proyecto contesta las preguntas con los
valores indicados a continuación:
� Las partes interesadas están identificadas? Las
partes interesadas son aquellas personas o grupos
de personas que afectan o pueden ser afectadas por
el proyecto. Boxes de referencia de la metodología
P3TQ: DB1, AB2, AB3 Mucho
� Todas las partes interesadas cuentan con la
disponibilidad de tiempo para avocarse al proyecto?
Boxes de referencia de la metodología P3TQ: DB1,
AB2, AB3: Mucho
� Existen partes interesadas con autoridad suficiente
dentro de la organización para liderar el proyecto
de explotación? Boxes de referencia de la
metodología P3TQ: DB1, AB2, AB3 Poco
� Existen partes interesadas con recursos económicos
suficientes para encarar el proyecto? Boxes de
referencia de la metodología P3TQ: DB1, AB2, AB3 Poco
� El proyecto de explotación tiene como propósito
buscar relaciones de interés? No
� El proyecto de explotación tiene como propósito la
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 90
evaluación de una situación de negocio? (análisis de
problema u oportunidad)? Si
� Con respecto a la problemática del negocio del
proyecto original: Se han encontrado datos de
utilidad para llevar a cabo la minería? El proyecto
original es aquel que origina el proyecto de
explotación que se está evaluando. Boxes de
referencia de la metodología P P3TQ: AB6 Poco
� Las partes interesadas han identificado o pueden
identificar aquellas características del negocio
importantes, que enmarcan sus expectativas del
proyecto de explotación? Boxes de referencia de la
metodología P3TQ: TB7 No
� La situación del negocio está enmarcada o puede
enmarcarse en un modelo a partir de los datos
conocidos? Boxes de referencia de la metodología
P3TQ: AB6 Poco
� Los Objetivos y Metas del negocio están definidos o
pueden definirse? Boxes de referencia de la
metodología P3TQ: AB6, TB5 Poco
� Se requiere inicialmente un análisis estratégico para
planificar escenarios corporativos? Si
� 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: AB9 Poco
� Existe un mapa del escenario estratégico,
consensuado con las partes interesadas. .Boxes de
referencia de la metodología P3TQ: AB12 No
� Están identificadas por las partes interesadas las
relaciones entre las cinco temáticas clave del
negocio(producto, lugar, precio, tiempo y
cantidad)? Boxes de referencia de la metodología
P3TQ: AB12 No
� Puede establecerse correspondencia entre el mapa y
las relaciones P3TQ? Boxes de referencia de la
metodología P3TQ: AB12 No
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 91
� Existen o pueden realizarse simulaciones que
permitan identificar ambigüedades, incertezas,
discordancias? Boxes de referencia de la
metodología P3TQ: AB12 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
metodología P3TQ: DB9.1 No
� Existen variables con único valor, o valores vacios
en sus instancias? Boxes de referencia de la
metodología P3TQ: DB9.2 Mucho
� Las variables categóricas están documentadas?
Boxes de referencia de la metodología P3TQ: DB9.2
Poco
� Los nombres de los atributos son acorde a los
conceptos del negocio? Boxes de referencia de la
metodología P3TQ: DB9.3 Poco
� Son reconocidas y es posible adecuar variables
anacrónicas? Boxes de referencia de la metodologí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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 92
importantes que pueden ocurrir en el negocio?
Boxes de referencia de la metodología P3TQ: DB9.6 No
� Es necesario realizar recodificación de variables
para mejor comprensión del modelo? Boxes de
referencia de la metodología P3TQ: DB9.7 Si
� Los conjuntos de variables de entrada y salida están
caracterizadas? Boxes de referencia de la
metodología P3TQ: AB11.1 Si
� Los datos están estructurados o pueden
estructurarse para aplicarlos en la herramienta de
minería elegida? Boxes de referencia de la
metodología P3TQ: AB11.1 Poco
� Están seleccionados los algoritmos de minería
adecuados al modelo? Boxes de referencia de la
metodología P3TQ: AB11.3 No
� Existe una herramienta de minería adecuada al
modelo y está disponible? Boxes de referencia de la
metodología P3TQ: AB11.6 No
� De necesitarse comprar herramientas, existen
proveedores disponibles. .Boxes de referencia de la
metodología P3TQ: AB11.5 Poco
� Esta construido o puede construirse el MVCM
(Missing Value Check Model)? Boxes de referencia
de la metodología P3TQ: AB11.1 No
� El objetivo de la explotación es entender una
situación? No
� El objetivo de la explotación es aplicar una
clasificación? No
� El objetivo de la explotación es buscar una
predicción? No
Resultado Esperado
El sistema muestra como resultado de viabilidad:
� Vector Justificación = (1.20 ; 2.20 ; 3.40 ;2.80)
� Resultado justificación =2.80
� Vector éxito = (0.22 ; 0.33 ; 0.42 ; 0.27)
� Resultado éxito = 0.27
� Vector adaptabilidad = (0.42 ; 0.57 ; 0.69 ; 0.49)
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 93
� Resultado adaptabilidad = 0.49
� Vector plausibilidad = (1.18 ; 1.54 ; 1.83 ; 1.36)
� Resultado plausibilidad = 1.36
� Vector Viabilidad = (0.85 ; 1.19 ; 1.48 ; 1.02)
� Resultado viabilidad = 1.02
Estado Ejecutado correctamente. Figura A1.69. Caso de prueba Proyecto no viable rotundamente
8.4.3. Proyecto no viable
La Figura A1.70 nuestra el caso de prueba Proyecto no.
Identificación CP-012 : Proyecto no viable
Caso de Uso
que lo origina CU-004
Escenario Un miembro del proyecto accede a la pantalla que permite
continuar la ejecución de una evaluación creada por él.
Datos de
Entrada El miembro del proyecto contesta 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 Regular
� 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 Mucho
� Existen partes interesadas con recursos económicos
suficientes para encarar el proyecto? Boxes de
referencia de la metodología P3TQ: DB1, AB2, AB3 Regular
� 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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 94
evaluación de una situación de negocio? (análisis de
problema u oportunidad)? Si
� Con respecto a la problemática del negocio del
proyecto original: Se han encontrado datos de
utilidad para llevar a cabo la minería? El proyecto
original es aquel que origina el proyecto de
explotación que se está evaluando..Boxes de
referencia de la metodología P3TQ: AB6 Regular
� Las partes interesadas han identificado o pueden
identificar aquellas características del negocio
importantes, que enmarcan sus expectativas del
proyecto de explotación? Boxes de referencia de la
metodología P3TQ: TB7 Si
� 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 Regular
� Los Objetivos y Metas del negocio están definidos o
pueden definirse? Boxes de referencia de la
metodología P3TQ: AB6, TB5 Regular
� Se requiere inicialmente un análisis estratégico para
planificar escenarios corporativos? Si
� 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: AB9 Regular
� Existe un mapa del escenario estratégico,
consensuado con las partes interesadas. .Boxes de
referencia de la metodología P3TQ: AB12 Si
� Están identificadas por las partes interesadas las
relaciones entre las cinco temáticas clave del
negocio(producto, lugar, precio, tiempo y
cantidad)? Boxes de referencia de la metodología
P3TQ: AB12 Si
� Puede establecerse correspondencia entre el mapa y
las relaciones P3TQ? Boxes de referencia de la
metodología P3TQ: AB12 Si
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 95
� Existen o pueden realizarse simulaciones que
permitan identificar ambigüedades, incertezas,
discordancias? Boxes de referencia de la
metodología P3TQ: AB12 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
� Existe o puede obtenerse un set de datos sin
errores? Boxes de referencia de la metodología
P3TQ: DB9.1 Si
� El set de datos obtenidos esta referenciado al caso
de negocio a estudiar? Boxes de referencia de la
metodología P3TQ: DB9.1 Si
� Existen variables con único valor, o valores vacios
en sus instancias? Boxes de referencia de la
metodología P3TQ: DB9.2 Regular
� Las variables categóricas están documentadas?
Boxes de referencia de la metodología P3TQ: DB9.2
Regular
� Los nombres de los atributos son acorde a los
conceptos del negocio? Boxes de referencia de la
metodología P3TQ: DB9.3 Mucho
� Son reconocidas y es posible adecuar variables
anacrónicas? Boxes de referencia de la metodología
P3TQ: DB9.4 Si
� Existen datos suficientes como para crear diez
modelos predictivos con once atributos cada uno
(siempre distintos) y generar un set de
entrenamiento y otro de testeo? Boxes de referencia
de la metodología P3TQ: DB9.5, TB9.4 Si
� Se dispone de un experto para analizar y asegurar
que el set de datos representa los escenarios más
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 96
importantes que pueden ocurrir en el negocio?
Boxes de referencia de la metodología P3TQ: DB9.6 Si
� Es necesario realizar recodificación de variables
para mejor comprensión del modelo? Boxes de
referencia de la metodología P3TQ: DB9.7 No
� Los conjuntos de variables de entrada y salida están
caracterizadas? Boxes de referencia de la
metodología P3TQ: AB11.1 Si
� Los datos están estructurados o pueden
estructurarse para aplicarlos en la herramienta de
minería elegida? Boxes de referencia de la
metodología P3TQ: AB11.1 Regular
� Están seleccionados los algoritmos de minería
adecuados al modelo? Boxes de referencia de la
metodología P3TQ: AB11.3 No
� Existe una herramienta de minería adecuada al
modelo y está disponible? Boxes de referencia de la
metodología P3TQ: AB11.6 Si
� De necesitarse comprar herramientas, existen
proveedores disponibles. .Boxes de referencia de la
metodología P3TQ: AB11.5 Regular
� Esta construido o puede construirse el MVCM
(Missing Value Check Model)? Boxes de referencia
de la metodología P3TQ: AB11.1 No
� El objetivo de la explotación es entender una
situación? No
� El objetivo de la explotación es aplicar una
clasificación? No
� El objetivo de la explotación es buscar una
predicción? No
Resultado Esperado
El sistema muestra como resultado de viabilidad:
� Vector Justificación = (3.40 ; 4.40 ; 5.60 ;6.60)
� Resultado Justificación = 5
� Vector éxito = (8.95 ; 9.24 ; 9.54 ; 9.76)
� Resultado éxito = 9.37
� Vector adaptabilidad = (3.48 ; 3.60 ; 3.75 ; 3.88)
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 97
� Resultado adaptabilidad = 3.68
� Vector plausibilidad = (2.77 ; 3.07 ; 3.43 ; 3.73)
� Resultado plausibilidad = 3.25
� Vector Viabilidad = (4.37 ; 4.70 ; 5.08 ; 5.39)
� Resultado viabilidad = 4.89
Estado Ejecutado correctamente. Figura A1.70. Caso de prueba Proyecto no viable
8.4.4. Proyecto no viable por incumplimiento de situaciones esenciales
La Figura A1.71 nuestra el caso de prueba Proyecto no.
Identificación CP-013 : Proyecto no viable por incumplimiento de
situaciones esenciales
Caso de Uso
que lo origina CU-004
Escenario Un miembro del proyecto accede a la pantalla que permite
continuar la ejecución de una evaluación creada por él.
Datos de
Entrada El miembro del proyecto contesta 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 Poco
� 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 Mucho
� Existen partes interesadas con recursos económicos
suficientes para encarar el proyecto? Boxes de
referencia de la metodología P3TQ: DB1, AB2, AB3 Mucho
� El proyecto de explotación tiene como propósito
buscar relaciones de interés? Si
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 98
� El proyecto original cuenta con el apoyo de la
organización? Boxes de referencia de la metodología
P3TQ: DB1, AB2, AB3 Mucho
� 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
� Se requiere inicialmente un análisis estratégico para
planificar escenarios corporativos? No
� Existe o puede obtenerse un set de datos sin
errores? Boxes de referencia de la metodología
P3TQ: DB9.1 Si
� El set de datos obtenidos esta referenciado al caso
de negocio a estudiar? Boxes de referencia de la
metodología P3TQ: DB9.1 Si
� Existen variables con único valor, o valores vacios
en sus instancias? Boxes de referencia de la
metodología P3TQ: DB9.2 Muy poco o nada
(No) � Las variables categóricas están documentadas?
Boxes de referencia de la metodología P3TQ: DB9.2
Mucho
� Los nombres de los atributos son acorde a los
conceptos del negocio? Boxes de referencia de la
metodología P3TQ: DB9.3 Mucho
� Son reconocidas y es posible adecuar variables
anacrónicas? Boxes de referencia de la metodología
P3TQ: DB9.4 Si
� Existen datos suficientes como para crear diez
modelos predictivos con once atributos cada uno
(siempre distintos) y generar un set de
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 99
entrenamiento y otro de testeo? Boxes de referencia
de la metodología P3TQ: DB9.5, TB9.4 Si
� 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 Si
� Es necesario realizar recodificación de variables
para mejor comprensión del modelo? Boxes de
referencia de la metodología P3TQ: DB9.7 No
� Los conjuntos de variables de entrada y salida están
caracterizadas? Boxes de referencia de la
metodología P3TQ: AB11.1 Si
� Los datos están estructurados o pueden
estructurarse para aplicarlos en la herramienta de
minería elegida? Boxes de referencia de la
metodología P3TQ: AB11.1 Mucho
� Están seleccionados los algoritmos de minería
adecuados al modelo? Boxes de referencia de la
metodología P3TQ: AB11.3 Si
� Existe una herramienta de minería adecuada al
modelo y está disponible? Boxes de referencia de la
metodología P3TQ: AB11.6 Si
� De necesitarse comprar herramientas, existen
proveedores disponibles. .Boxes de referencia de la
metodología P3TQ: AB11.5 Mucho
� 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? 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
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 100
interesadas, o gerentes para realizar mejoras en el
negocio. .Boxes de referencia de la metodología
P3TQ: AB11.1, DB11,5 Mucho
� Los datos son suficientes para definir las relaciones
explicativas? Boxes de referencia de la metodología
P3TQ: AB11.1 DB11.5 Si
Resultado
Esperado El sistema muestra como resultado de viabilidad:
� Vector Justificación = (10 ; 10 ; 10 ; 10)
� Resultado Justificación = 10
� Vector éxito = (7.80 ; 8.37 ; 8.99 ; 9.47 )
� Resultado éxito = 8.66
� Vector adaptabilidad = (0 ; 0; 0 ; 0)
� Resultado adaptabilidad = 0
� Vector plausibilidad = (0 ; 0; 0 ; 0)
� Resultado plausibilidad = 0
� Vector Viabilidad = (5.62 ; 5.93 ; 6.20 ; 6.44)
� Resultado viabilidad = 6.05
Estado Ejecutado correctamente. Figura A1.71. Caso de prueba Proyecto no viable por incumplimiento de situaciones esenciales
8.5. Crear evaluación
A continuación se presentan los casos de prueba correspondientes a los diferentes
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
que lo origina CU-005
Escenario Un miembro del proyecto intenta crear una nueva
evaluación.
Datos de
Entrada El miembro del proyecto ingresa cualquiera de los siguientes
nombres:
� Texto Alfanumérico
� Texto nulo
Resultado Esperado
El sistema crea una nueva evaluación y redirige al usuario a
la pantalla de ejecución de la evaluación.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 101
Estado Ejecutado correctamente. Figura A1.72. Caso de prueba Miembro del proyecto crea evaluación
8.5.2. Líder del proyecto crea evaluación
La Figura A1.73 nuestra el caso de prueba Líder del proyecto crea evaluación.
Identificación CP-012 : Líder del proyecto crea evaluación
Caso de Uso
que lo origina CU-005
Escenario El líder del proyecto intenta crear una nueva evaluación.
Datos de
Entrada El líder del proyecto ingresa cualquiera de los siguientes
nombres:
� Texto 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 Ejecutado correctamente. Figura A1.73. Caso de prueba Líder del proyecto crea evaluación
8.5.3. Usuario intenta crear evaluación
La Figura A1.74 nuestra el caso de prueba Usuario intenta crear evaluación.
Identificación CP-013 : Usuario intenta crear evaluación
Caso de Uso
que lo origina CU-005
Escenario Un usuario que no posee roles en un proyecto intenta crear
una evaluación en él.
Datos de
Entrada Ninguno
Resultado
Esperado El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la acción.
Estado Ejecutado correctamente. Figura A1.74. Caso de prueba Usuario intenta crear evaluación
8.6. Consultar proyecto
A continuación se presentan los casos de prueba correspondientes a los diferentes
escenarios del caso de uso CU-006 : Consultar proyecto.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 102
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 que lo origina
CU-006
Escenario Un miembro del proyecto (colaborador o líder) selecciona un
proyecto para consultarlo.
Datos de Entrada
El usuario selecciona de la lista de proyectos uno al cual
pertenece.
Resultado
Esperado El sistema le presenta al usuario la pantalla de información
del proyecto, que incluye los resultados de todas las
evaluaciones realizadas.
Estado Ejecutado correctamente. Figura A1.75. Caso de prueba Miembro consulta proyecto
8.6.2. Usuario intenta consultar proyecto
La Figura A1.76nuestra el caso de prueba Usuario intenta consultar proyecto.
Identificación CP-015 : Usuario intenta consultar proyecto
Caso de Uso que lo origina
CU-006
Escenario Un usuario que no es miembro de un proyecto (ni
colaborador ni líder) selecciona ese proyecto para
consultarlo.
Datos de Entrada
El usuario selecciona de la lista de proyectos uno al cual no
pertenece.
Resultado
Esperado El sistema le presenta al usuario la pantalla de información
del proyecto, sin mostrar los resultados de las evaluaciones
realizadas.
Estado Ejecutado correctamente. Figura A1.76. Caso de prueba Usuario intenta consultar proyecto
8.7. Consultar Evaluación
A continuación se presentan los casos de prueba correspondientes a los diferentes
escenarios del caso de uso CU-007 : Consultar evaluación.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 103
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 que lo origina
CU-007
Escenario Un miembro del proyecto (colaborador o líder) selecciona
una evaluación de ese proyecto para consultarla.
Datos de Entrada
El usuario selecciona una evaluación de la lista de
evaluaciones del proyecto.
Resultado
Esperado El sistema le presenta al usuario la pantalla de información
de la evaluación.
Estado Ejecutado correctamente. Figura A1.77. Caso de prueba Miembro consulta evaluación
8.7.2. Usuario intenta consultar evaluación
La Figura A1.78 nuestra el caso de prueba Usuario intenta consultar evaluación.
Identificación CP-017 : Usuario intenta consultar evaluación
Caso de Uso que lo origina
CU-007
Escenario Un usuario que no es miembro de un proyecto (ni
colaborador ni líder) intenta consultar una evaluación de ese
proyecto.
Datos de Entrada
El usuario selecciona una evaluación de la lista de
evaluaciones del proyecto al cual no pertenece.
Resultado
Esperado El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la acción.
Estado Ejecutado correctamente. Figura A1.78. Caso de prueba Usuario intenta consultar evaluación
8.8. Crear Proyecto
A continuación se presentan los casos de prueba correspondientes a los diferentes
escenarios del caso de uso CU-008 : Crear proyecto.
8.8.1. Usuario crea Proyecto
La Figura A1.79 nuestra el caso de prueba Usuario crea proyecto.
Identificación CP-018 : Usuario crea proyecto
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 104
Caso de Uso
que lo origina CU-008
Escenario Un Usuario que ha iniciado sesión del sistema intenta crear
un nuevo proyecto.
Datos de
Entrada El usuario ingresa cualquiera de los siguientes nombres para
el proyecto:
� Texto 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 Ejecutado correctamente. Figura A1.79. Caso de prueba Usuario crea proyecto
8.9. Asignar colaborador
A continuación se presentan los casos de prueba correspondientes a los diferentes
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 que lo origina
CU-009
Escenario El líder del proyecto accede a la pantalla para agregar un
nuevo colaborador al proyecto.
Datos de Entrada
El líder del proyecto ingresa un e-mail válido
Resultado
Esperado El usuario colaborador del proyecto queda registrado en el
sistema.
Estado Ejecutado correctamente. Figura A1.80. Caso de prueba líder de proyecto agrega nuevo colaborador
8.9.2. Líder del proyecto intenta agregar colaborador registrado
La Figura A1.81 nuestra el caso de prueba Líder del proyecto intenta agregar
colaborador registrado.
Identificación CP-020 : Líder del proyecto intenta agregar colaborador
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 105
registrado
Caso de Uso
que lo origina CU-009
Escenario El líder de proyecto accede a la pantalla para agregar un
colaborador, que ya ha sido registrado previamente en el
sistema, en el mismo proyecto.
Datos de
Entrada El líder del proyecto ingresa un e-mail válido, que ya fue
registrado previamente en ese proyecto (cuenta activa en
google)
Resultado Esperado
El sistema notifica que el e-mail ya ha sido registrado
para ese proyecto.
Estado Ejecutado correctamente. Figura A1.81. Caso de prueba Líder del proyecto intenta agregar colaborador registrado
8.9.3. Líder de proyecto intenta agregar colaborador con e-mail nulo
La Figura A1.82 nuestra el caso de prueba Líder de proyecto intenta agregar
colaborador con e-mail nulo.
Identificación CP-021 : Líder de proyecto intenta agregar colaborador con
e-mail nulo
Caso de Uso
que lo origina CU-009
Escenario El líder de proyecto accede a la pantalla para agregar un
nuevo colaborador al proyecto.
Datos de
Entrada El administrador envía el formulario sin ingresar un e-mail
Resultado Esperado
El sistema notifica que el e-mail no es válido, debido a que es
nulo.
Estado Ejecutado correctamente. Figura A1.82. Caso de prueba Líder de proyecto intenta agregar colaborador con e-mail nulo
8.9.4. Usuario intenta agregar colaborador al proyecto
La Figura A1.83 nuestra el caso de prueba Usuario intenta agregar colaborador al
proyecto.
Identificación CP-022 : Usuario intenta agregar colaborador al proyecto
Caso de Uso
que lo origina CU-009
Escenario Un usuario, que no cuenta con el rol de líder de proyecto
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 106
(puede o no ser colaborador del proyecto), accede a la
pantalla para agregar un nuevo usuario evaluador.
Datos de Entrada
Ninguno
Resultado
Esperado El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la acción.
Estado Ejecutado correctamente. Figura A1.83. Caso de prueba Usuario intenta agregar colaborador al proyecto
8.10. Inicializar cuestionario
A continuación se presentan los casos de prueba correspondientes a los diferentes
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
que lo origina CU-010
Escenario El Administrador accede a la pantalla para inicializar la
plantilla de evaluación.
Datos de Entrada
El administrador contesta ”Si“
Resultado
Esperado El sistema inicializa la plantilla de evaluación y elimina
todos los registros de la base de datos.
Estado Ejecutado correctamente. Figura A1.84. Caso de prueba Administrador inicializa cuestionario
8.10.2. Administrador intenta inicializar cuestionario
La Figura A1.85 nuestra el caso de prueba Administrador intenta inicializar
cuestionario.
Identificación CP-023 : Administrador intenta inicializar cuestionario
Caso de Uso
que lo origina CU-010
Escenario El Administrador accede a la pantalla para inicializar la
plantilla de evaluación.
Datos de
Entrada El administrador contesta ”No“
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 107
Resultado
Esperado El Sistema aborda la operación y notifica al administrador y
notifica al administrador.
Estado Ejecutado correctamente. Figura A1.85. Caso de prueba Administrador intenta inicializar cuestionario
8.10.3. Usuario intenta inicializar cuestionario
La Figura A1.86 nuestra el caso de prueba Usuario intenta intenta inicializar
cuestionario.
Identificación CP-024 : Usuario intenta inicializar cuestionario
Caso de Uso
que lo origina CU-010
Escenario Un usuario, que no cuenta con el rol de administrador,
accede a la pantalla para inicializar la plantilla de
evaluación.
Datos de
Entrada Ninguno
Resultado Esperado
El sistema notifica al usuario que no cuenta con los permisos
suficientes para realizar la acción.
Estado Ejecutado correctamente. Figura A1.86. Caso de prueba Usuario intenta inicializar cuestionario
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 108
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 1. Documento de Desarrollo de la Herramienta DAMVE. Pág. 109
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.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 110
Anexo 2. Manual de usuario la
Herramienta DAMVE
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 111
1. Introducción
El Sistema DAMVE tiene por finalidad, ayudar a los miembros de un proyecto de
explotación de información que utilizan la metodología P3TQ a evaluar su
viabilidad.
2. Requisitos
Para poder ejecutar el sistema DAMVE se requiere de un navegador web con
soporte para AJAX. Los siguientes navegadores funcionan correctamente con el
sistema DAMVE :
� Microsoft Internet Explorer 6.0 o superior
� Mozilla Firefox 2.0 o superior
En cualquiera de los dos casos deben habilitarse las opciones de cookies y
ejecución de comandos javascript.
3. Acceso al sistema
Cuando un usuario ingresa el enlace del sistema DAMVE en el navegador web se
presenta la siguiente pantalla, mostrada en la Figura A2.1.:
Figura A2.1. Pantalla de ingreso al sistema
Siguiendo el enlace el usuario accede a un formulario que le solicita identificarse
para poder ingresar al sistema. Los datos de acceso son:
� e-mai l : corresponde a la dirección de e-mail del usuario.
� Contraseña : se debe ingresar la clave de acceso que debe ser conocida por
el usuario.
Éstos datos son los pertenecientes a una cuenta de Google habilitada, si el sistema
se está ejecutando online.
Si los datos ingresados son correctos el usuario accede a la pantalla de selección
de proyectos, que se muestra en la Figura A2.2:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 112
Figura A2.2. Pantalla de selección de proyectos
Por el contrario, si los datos ingresados son incorrectos, el sistema mostrará la
siguiente pantalla de error, que pedirá que se vuelvan a ingresar los datos
nuevamente.
4. Presentación de la interfaz
Se presenta a continuación, en la Figura A2.3, la pantalla de selección de
proyectos del sistema y se describen las distintas opciones de la barra de menús.
Figura A2.3. Panta l la de presentación de la inter faz
Los números asociados con cada elemento de la pantalla se describen a
continuación:
1. Nombre de usuario : en el encabezado de la pantalla puede verse el
nombre del usuario que está utilizando el sistema.
2. Proyectos : esta opción lleva a la pantalla de selección de proyectos que le
permite al usuario dar de alta un nuevo proyecto, seleccionar un existente
1
2 3 4 5 6 7
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 113
y, a partir de allí, realizar evaluaciones de viabilidad para el mismo. Esta
opción explica en detalle en el ítem 5 de este manual.
3. Cuestionario : esta opción lleva a la pantalla de edición de la plantilla de
evaluación para los estudios de viabilidad. Solamente los usuarios de
cuentan con el rol de evaluadores pueden acceder, y les permite modificar
los parámetros del cuestionario con el cual se realizan todos los estudios
de viabilidad. Esta opción se explica en detalle en el ítem 10.3 de este
manual.
4. Evaluadores : esta opción lleva a la pantalla que le permite al
administrador del sistema agregar nuevos usuarios evaluadores para que
puedan modificar la plantilla de evaluación, explicada anteriormente. Esta
opción se explica en detalle en el ítem 10.1 de este manual.
5. Inicializar : esta opción lleva a la pantalla que le permite al administrador
del sistema inicializar la base de datos, eliminando, de existir, toda la
información que exista y reiniciando la plantilla de evaluación. Esta
opción se explica en detalle en el ítem 10.4 de este manual.
6. Ayuda : esta opción permite consultar este manual en línea o descargarlo el
formato electrónico.
7. Salir : esta opción permite que el usuario cierra su sesión y salga del
sistema.
5. Creación y Selección de Proyectos
En este ítem explicara cómo crear o seleccionar proyectos existentes en la sistema.
5.1. Creación de un proyecto nuevo
Cualquier usuario registrado en el sistema es capaz de crear un nuevo proyecto y,
de esa manera, convertirse en el líder (o propietario) del mismo.
La creación de nuevo proyecto se lleva a cabo haciendo clic en la opción
“Proyectos” . Luego de hacer esto el usuario puede ver el siguiente formulario,
presentado en la Figura A2.4:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 114
Figura A2.4. Formulario de creación de un nuevo proyecto
Para crear un nuevo proyecto, en la sección "crear proyecto" el usuario debe:
� Escribir un nombre para el proyecto.
� Hacer clic en el botón “Crear”.
Una vez realizada esta tarea el sistema DAMVE crea el proyecto y le presenta al
usuario la pantalla de gestión del proyecto.
5.2. Selección de un proyecto existente
Para seleccionar un proyecto existente en el sistema debe hacerse clic en la opción
“Proyectos” . Luego de hacer esto el usuario puede ver una lista con los proyectos
existentes en el sistema. La Figura A2.5 muestra esta lista:
Figura A2.5. Pantalla de selección de un proyecto
La información que se presenta es la siguiente:
� Fecha: fecha en la cual se creó el proyecto.
� Descripción: nombre del proyecto.
� Creador: e-mail del usuario creador del proyecto
� evaluaciones: cantidad de evaluaciones que se han realizado en dicho
proyecto.
� Rol: corresponde al rol del usuario con respecto a dicho proyecto,
representado por iconos. El icono significa que el usuario es el líder del
proyecto, el icono significa que el usuario de colaborador en el proyecto
y el icono significa que el usuario es visitante en dicho proyecto.
Haciendo clic en la fecha, descripción o rol de un proyecto el usuario
puede acceder a la pantalla de gestión del proyecto.
6. Roles de los usuarios
Antes de continuar explicando los pasos a seguir para poder crear evaluaciones
de viabilidad en la proyectos es necesario presentar los distintos roles que los
usuarios pueden tener dentro del sistema DAMVE. La Tabla 1 presenta los roles
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 115
de los usuarios en el sistema ordenados por jerarquía, comenzando por el rol de
menor jerarquía (visitante) y llegando hasta el rol con mayor jerarquía
(Administrador):
Nombre del rol Acciones dentro del sistema
Visitante Cualquier usuario que haya ingresado el sistema es
considerado visitante. Puede consultar los proyectos
existentes, los miembros pertenecientes a los
proyectos y la cantidad de evaluaciones de viabilidad
realizadas. No puede conocer los resultados de las
evaluaciones de viabilidad.
Colaborador del Proyecto Cualquier usuario que haya sido designado como
colaborador de un proyecto por el líder del mismo.
Como tal puede crear evaluaciones de viabilidad. Un
colaborador de un proyecto no puede continuar la
ejecución de evaluaciones creadas por otro colaborador
del mismo proyecto.
Líder del Proyecto Cualquier usuario visitante que dé de alta un proyecto
se convierte en el líder del mismo. Como tal puede
crear evaluaciones de viabilidad y designar a otros
usuarios como colaboradores.
Evaluador Cualquier usuario que haya sido designado como
evaluador por el administrador. Tiene la capacidad de
modificar la plantilla de evaluación del estudio de
viabilidad.
Administrador Es el usuario responsable de la administración del
sistema. Puede designar a los usuarios evaluadores.
Tabla 1. Roles de los usuarios
Un mismo usuario puede tener dentro del sistema uno o varios roles. Por ejemplo,
un usuario puede ser líder del proyecto 1 por haberlo creado, colaborador del
proyecto 2 porque su líder lo ha designado, visitante en el resto de los proyectos y
evaluador porque el administrador lo ha designado.
7. Gestión de un Proyecto
Una vez creado un nuevo proyecto o seleccionado de la pantalla de selección de
proyecto, el usuario accede a la pantalla de gestión del proyecto. La Figura A2.6
presenta dicha pantalla:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 116
Figura A2.6. Pantalla de gestión del proyecto
En esta pantalla puede observarse toda la información relativa al estudio de
viabilidad del proyecto, organizada por secciones.
� Sección general : se presenta el Nombre del proyecto, la fecha de creación
y el usuario propietario, o líder.
� Colaboradores : se presentan los e-mails de todos los usuarios designados
por el líder del proyecto para crear evaluaciones de viabilidad.
� Evaluaciones : se presenta una tabla que muestra la información resumida
de cada uno de los estudios de viabilidad realizados para este proyecto,
ordenados en forma cronológica descendente, lo que permite visualizar la
evolución de la viabilidad del proyecto. La tabla presenta la fecha de
creación, la descripción, el usuario creador y el resultado de cada una de
las evaluaciones. Si la evaluación ha sido completada se muestra en la
tabla el resultado final en forma gráfica y numérica. Sin evaluación no ha
sido completada todavía se muestran la tabla el texto “Incompleto”. En el
caso de que un usuario visitante acceda a un proyecto del cual no es
miembro (ni líder ni colaborador) el sistema no mostrara el resultado de
ninguna evaluación.
7.1. Agregar colaborador al proyecto
El líder del proyecto puede agregar un colaborador al mismo, completando el
formulario “Agregar colaborador al proyecto” que se presenta en la pantalla de
gestión del proyecto. La Figura A2.7 muestra dicha pantalla:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 117
Figura A2.7. Formulario agregar colaborador al proyecto
Para agregar un colaborador al proyecto, el líder debe:
� Escribir el e-mail del usuario colaborador.
� Hacer clic en el botón “Agregar colaborador”.
Una vez realizada esta tarea el sistema DAMVE agrega al usuario como
colaborador del proyecto.
7.2. Eliminar un colaborador
El líder de un proyecto puede eliminar a cualquier colaborador que haya
agregado previamente. Para esto debe hacer clic en el icono que se encuentra al
lado del e-mail de cada colaborador. El sistema le pedirá una confirmación y, si el
líder del proyecto contesta afirmativamente, el colaborador será eliminado de ese
proyecto, convirtiéndose en visitante.
7.3. Crear una nueva evaluación
El líder del proyecto y los usuarios colaboradores pueden crear una nueva
evaluación de viabilidad para el proyecto, completando el formulario “crear
nueva evaluación” que se presenta en la pantalla de gestión del proyecto.
Figura A2.7. Formulario crear nueva evaluación
Para crear una nueva evaluación, el usuario miembro del proyecto debe:
� Escribir una descripción para la evaluación.
� Hacer clic en el botón “crear nueva evaluación”.
Una vez realizada esta tarea el sistema DAMVE crea una nueva evaluación para el
proyecto y le muestra al usuario la pantalla de ejecución de la evaluación.
7.4. Imprimir la gestión del proyecto
Para imprimir la información de gestión del proyecto el usuario debe hacer clic en
el botón “Imprimir” que se encuentra en el borde superior derecho de la pantalla.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 118
El sistema preparará una versión adaptada para impresión de la pantalla que
facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo de
impresión del navegador web.
7.5. Exportar la gestión del proyecto
Para exportar la información de gestión del proyecto a un archivo separado por
comas (.csv) el usuario debe hacer clic en el botón “Exportar” que se encuentra en
el borde superior derecho de la pantalla.
El sistema generará un archivo .csv que el usuario podrá descargar y visualizar en
cualquier planilla de cálculo o editor de texto.
8. Ejecución de evaluaciones
Hasta el momento se ha presentado la forma de crear proyectos, agregar
colaboradores al mismo y crear evaluaciones. En este ítem se mostrará la forma de
ejecutar las evaluaciones a través de un cuestionario guiado.
Una vez que un miembro del proyecto cree una nueva evaluación, el sistema
DAMVE presenta la pantalla de ejecución de la evaluación. La Figura A2.8
presenta dicha pantalla:
Figura A2.8. Pantalla de ejecución de la evaluación
La ejecución de una evaluación de viabilidad es simple:
1. El sistema le presenta al usuario una pregunta relacionada a un aspecto
particular de la metodología P3TQ.
2. El usuario debe responderla en relación a la información con la que cuenta
del proyecto que está evaluando. Para esto puede utilizar el mouse para
elegir la opción que considere correcta y hacer clic en el botón siguiente.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 119
Alternativamente, para hacer más dinámica la interacción, el usuario
puede seleccionar la opción correcta con las flechas del cursor y presionar
la tecla ENTER.
3. El sistema procesará la respuesta del usuario y le presentará la próxima
pregunta. Además, en la sección "preguntas respondidas" el sistema
muestra todas las preguntas que el usuario ha respondido.
4. A llegar a la última pregunta el sistema siendo capaz de calcular la
viabilidad del proyecto en base a las respuestas del usuario, le presenta la
pantalla de resultado de la evaluación.
8.1. Abandonar y Retomar evaluaciones
No es necesario que el usuario complete una evaluación en una única sesión,
pudiendo abandonar la ejecución de una evaluación en cualquier momento.
Para retomar una evaluación incompleta, el usuario miembro del proyecto debe
seleccionar el proyecto en la pantalla de selección de proyectos y, en la pantalla de
gestión del proyecto buscar en la tabla de evaluaciones, que se presenta en la
Figura A2.9, la evaluación que ha dejado incompleta.
Figura A2.9. Retomar una evaluación incompleta
Una vez hecho esto debe hacer clic en el icono , que le permitirá volver a la
pantalla de ejecución de la evaluación, retomando el cuestionario desde dónde lo
abandonó.
9. Resultado de las evaluaciones
Una vez que se ha completado el cuestionario de evaluación el sistema le presenta
al usuario de resultado obtenido. La Figura A2.10 muestra un ejemplo de
resultado de evaluación:
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 120
Figura A2.10. Pantalla de resultado de una evaluación
El sistema muestra los siguientes resultados:
� Dimensión just if icación : presenta el vector justificación y, en forma
gráfica, el módulo del vector que sintetiza el resultado de esa dimensión.
� Dimensión Adaptabi lidad : presenta el vector adaptabilidad y, en forma
gráfica, el módulo del vector que sintetiza el resultado de esa dimensión.
� Dimensión Plausibi lidad : presenta el vector plausibilidad y, en forma
gráfica, el módulo del vector que sintetiza el resultado de esa dimensión.
� Dimensión Éxito : presenta el vector éxito y, en forma gráfica, el módulo
del vector que sintetiza el resultado de esa dimensión.
� Viabi lidad : presenta el vector viabilidad, que es un promedio de las cuatro
dimensiones anteriores y, en forma gráfica, el módulo de este vector que
sintetiza el resultado final de la evaluación.
� Si el resultado del cálculo del módulo de un vector es menor a seis, se
considera insuficiente y se presenta el resultado gráfico en color rojo. Por
el contrario si el módulo es mayor a seis se lo considera aceptable y se
presenta el resultado gráfico en color verde.
� Al igual que la pantalla de ejecución de una evaluación del sistema
presenta en la sección "preguntas respondidas" todas las preguntas que el
usuario ha respondido, permitiendo contar con trazabilidad de la
evaluación.
9.1. Imprimir los resultados
Para imprimir los resultados de la evaluación de un proyecto el usuario debe
hacer clic en el botón “Imprimir” es encuentra en el borde superior derecho de la
pantalla.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 121
El sistema preparará una versión adaptada para impresión del resultado que
facilita su lectura en papel y ejecutará automáticamente el cuadro de diálogo de
impresión del navegador web.
9.2. Exportar los resultados
Para exportar los resultados de la evaluación a un archivo separado por comas
(.csv) el usuario debe hacer clic en el botón “Exportar” que se encuentra en el
borde superior derecho de la pantalla.
El sistema generará un archivo .csv que el usuario podrá descargar y visualizar en
cualquier planilla de cálculo o editor de texto.
9.3. Consultar resultados de evaluaciones realizadas
Para poder consultar los resultados de una evaluación realizada cualquier
miembro del proyecto (líder o colaborador) debe hacer clic en el resultado final de
la evaluación que se encuentra en la sección "Evaluaciones" de la pantalla de
gestión del proyecto. La Figura A2.11 muestra un ejemplo de dicha pantalla:
Figura A2.11. Consultar resultados de evaluaciones realizadas
10. Opciones Avanzadas
Las opciones presentadas a continuación pueden ser llevadas a cabo por usuarios
con mayor jerarquía en el sistema, debido a los roles que poseen.
10.1. Designar evaluadores
El administrador del sistema puede designar usuarios evaluadores, que son
capaces de modificar la plantilla de evaluación.
Para realizar esta tarea el administrador debe hacer clic en la opción
“Evaluadores” del menú y completar el formulario “Agregar evaluador” que se
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 122
presenta en la pantalla evaluadores. La Figura A2.12 muestra un ejemplo de dicho
formulario:
Figura A2.12. Formulario para agregar un evaluador
Para agregar un nuevo evaluador, el usuario administrador debe:
� Escribir el e-mail del nuevo valor.
� Hacer clic en el botón “Agregar evaluador”.
Una vez realizada esta tarea el sistema DAMVE agrega al usuario como
evaluador.
10.2. Eliminar un evaluador
El administrador puede eliminar a cualquier evaluador que haya sido designado
previamente. Para esto debe hacer clic en el icono que se encuentra al lado del
e-mail de cada evaluador, en la pantalla evaluadores. El sistema le pedirá una
confirmación y, si el administrador contesta afirmativamente, el evaluador será
eliminado del sistema.
10.3. Editar la plantilla de evaluación
Los usuarios con el rol de evaluadores pueden editar la plantilla de evaluación.
Para realizar esta tarea deben hacer clic en la opción "Cuestionario" del menú. A
continuación se presenta en la Figura A2.13 la pantalla de edición de la plantilla
de evaluación.
Figura A2.13. Formulario para editar la plantilla de evaluación
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 123
El sistema presenta un formulario por cada pregunta del cuestionario de
evaluación. Los parámetros que pueden modificarse en cada formulario es:
� Descripción : contiene el texto de la pregunta a contestar.
� Peso : el peso de la pregunta, en un rango de -10 a 10.
� Dimensión : correspondiente a que dimensión de viabilidad corresponde la
pregunta (justificación, éxito, adaptabilidad, plausibilidad)
� Próximas preguntas : muestra para cada valor posible de respuesta cual es
la próxima pregunta del cuestionario. Esta opción permite que el usuario
evaluador pueda navegar el cuestionario. Para esto el usuario evaluador
debe hacer clic en el número de la próxima pregunta y el sistema lo
llevara hasta el formulario de dicha pregunta.
El usar evaluador puede, entonces, modificar cualesquiera de los parámetros del
formulario y, haciendo clic en el botón “Actualizar” el sistema guardará los
cambios en la plantilla de evaluación.
10.3.1. Preservación de los resultados
Cuando una pregunta de la plantilla de evaluación es modificada, todas las
evaluaciones de viabilidad de cualquier proyecto utilizarán los nuevos
parámetros de dicha pregunta. Las evaluaciones que ya hayan respondido
previamente la pregunta conservarán el valor anterior en el resultado. De esta
manera se preservan los resultados de viabilidad anteriores a la modificación de
la plantilla de evaluación.
10.3.2. Preservación de la secuencia
El sistema DAMVE, no permite que se altere la secuencia de las preguntas, debido
a que siguen, de manera estricta la metodología P3TQ. Sin embargo, resulta muy
útil para un líder de proyecto de explotación de información con experiencia la
posibilidad de modificar los parámetros de la pregunta para adecuar la
evaluación de debilidad a su entorno de trabajo.
10.4. Inicializar la Base de Datos
El administrador del sistema puede reiniciar la base de datos, haciendo clic en la
opción “Inicializar” del menú.
Luego de hacer esto el sistema mostrará una pantalla similar a la Figura A2.14,
que solicita la confirmación del administrador, dado que esta acción destruye
todos los datos que existan en la base de datos y lleva al Sistema DAMVE a su
estado original.
FIUBA – LSI – Trabajo Profesional en Ingeniería en Informática Herramienta de Estudio de Viabilidad para proyectos que utilizan la metodología P3TQ
Directores Alumnos Prof. Dr. Ramón GARCÍA-MARTÍNEZ Pablo Damián MÉNDEZ Prof. Dra. Paola BRITOS Alejandro Daniel RODRÍGUEZ
Anexo 2. Manual de Usuario de la Herramienta DAMVE. Pág. 124
Figura A2.14. Confirmación de Inicialización de la Base de Datos
Si el usuario hace clic en el botón “Aceptar” toda la información existente es
eliminada y el sistema queda reinicializado.