CHAPTER 3 CONSUMER DECISION MAKING: PRODUCT ATTRIBUTES, PRODUCT
3.3 PROCESS (INTERNAL VARIABLES)
3.3.2 Internal psychological variables
Procesos de usuario
El proceso de usuario se mostrará al mismo como una aplicación híbrida a la que se podrá acceder tanto en dispositivos fijos (PC estándar con acceso a internet) compatible para los navegadores más comunes: Internet Explorer, Mozila Firefox, Google Chrome, Safar, etc; y como una aplicación descargable para dispositivos móviles: Android, Ios, Windows Phone, Blackberry, etc. Y la pretensión es que se actualice a los diferentes sistemas operativos en un futuro.
Test de clasificación
El test está concebido como elemento fundamental en la clasificación del usuario y nos determinará el perfil del usuario. El cuestionario contendrá preguntas acerca de los gustos y preferencias. Las preguntas irán apoyadas por imágenes y sonidos, para aproximar en lo máximo posible las preferencias principales del usuario.
Destino singular
Tanto en la planificación de un viaje, en el desarrollo del mismo, como en cualquier momento durante un viaje, el usuario podrá acceder a las sugerencias de destino singular.
Se solicitará al usuario que indique cual es la necesidad que se desea satisfacer: comer, visita turística, concierto, etc. Se contará con un amplio abanico de posibilidades de acuerdo con las experiencias tanto propias como de otros usuarios de la aplicación.
Una vez determinada la necesidad, el sistema preguntará por los sentimientos actuales del usuario: cansancio, preferencias, etc.
La combinación del perfil con los sentimientos nos puede hacer que el usuario se ajuste a un perfil distinto al suyo (perfil actual) y que los destinos que se sugieren sean distintos a los que se ajustaría el perfil.
Procesos de análisis y clasificación Perfil de usuarios
Las respuestas del usuario asignarán a éste en uno de los perfiles, que no será fijo sino que puede ir variando en función de las experiencias del usuario y de su historia.
Combinación perfil-sentimiento
Aunque a cada usuario se le asigna un perfil, no es éste el que nos determina nuestra sugerencia de destino ya que consideramos que existen otras variables que pueden modificar las preferencias de destino. A estos aspectos les hemos llamado sentimientos, que nos van a ayudar en conjunción con la necesidad del usuario a determinar qué recursos se pueden ajustar más a las preferencias del cliente.
A estos dos conceptos: necesidad y sentimiento, los hemos denominado así ya que en los estudios preliminares del problema nos encontrábamos con que nuestro objetivo era definir un recurso no sólo atendiendo a un perfil sino a la respuesta a dos preguntas: ¿Qué necesitas ahora? Y ¿Cómo te sientes?.
Con los datos de los perfiles y los sentimientos se definirá el perfil final con el que junto a la necesidad que exprese el usuario nos proporcionará qué recursos son los que más se ajustan, en ese momento.
Clasificación de recursos
Una vez definida la necesidad, nos podremos encontrar que un recurso puede cubrir una o varias necesidades o una necesidad combinada, con lo que para cada tipo de recurso que nos encontremos tendremos que analizar qué necesidades puede cubrir y posteriormente determinar los porcentajes de ajuste del recurso a los perfiles.
Asignación recurso-usuario
En esta fase de análisis se asignarán las propensiones de uso de cada perfil de usuario en cada recurso.
Planificador de viajes
El usuario puede tener definidos qué destinos son los que le gustaría visitar, pero si no se da el caso, deberemos ser capaces de sugerir una serie de destinos que se ajusten a su perfil de usuario.
Una vez determinados los destinos y los días de estancia en cada uno de ellos, se sugerirán las actividades más adecuadas a cada tramo horario, atendiendo a los perfiles del los usuarios.
Procesos de carga de datos
Como se ha indicado nuestra previsión es la de llegar a acuerdos con proveedores de servicios en internet que ya dispongan de la geolocalización de los recursos.
Para ello vamos a necesitar:
1. Recursos Naturales y sitios de interés 2. Comercios y comerciantes
3. Edificios y Monumentos 4. Otros recursos
Para la carga de datos en nuestro sistema trataremos de usar los siguientes métodos de captación de información:
1. Cesión de bases de datos
2. Uso de API proporcionados por los sites. 3. Técnicas de scraping
Como cada base de datos que se obtenga, va a tener su propio formato, las cargas de datos de modo tradicional no iban a ser tarea sencilla y además hemos de contar con que de muchos recursos tendremos datos no estructurados. Por ello, hemos concluido que el mejor modo de cargar las bases de datos sería mediante procesos en Hadoop. Con unos datos mínimos para la carga de cada recurso en nuestro sistema y en función de otros procesos de carga ir enriqueciendo las bases de datos con otros datos, tanto estructurados como no estructurados.
ARQUITECTURA IT PARA TRIPMATE HARDWARE
Haciendo un estudio de mercado de las grandes marcas que suministran hardware, nos hemos decantado por servidores de IBM por su relación calidad/precio y porque también tendremos software de esta compañía y nos podría abaratar la transacción por volumen de compra. Al ser nuestros servicios de usuarios, una app y una página web, nuestros servidores tendrán que ir creciendo conforme nuestros usuarios lo hagan, ya que hay que soportar un mayor número de accesos a nuestra aplicación y esto será el parámetro nos indique cuanto tenemos que crecer.
La arquitectura IT consta de:
1. Bastidor IBM 42U 1200mm Deep Dynamic Expansion Rack, modelo 93604EX. El bastidor será el que aloje nuestros servidores Blade.
2. Chasis para servidores Blade, que irá integrado en el bastidor. El modelo escogido es IBM BladeCenter H 88525TU.
3. Dentro del chasis, colocaremos 10 servidores BladeCenter HS23 modelo 7875AC1 Elite. A pesar de no ser servidores de alto almacenamiento si son servidores muy potentes con mayor memoria de caché que mejoran la productividad a un mayor rendimiento de procesamiento. Entre otras cosas, lo utilizaremos para dar respuesta al servicio de mapas GIS.
4. Para alojar y procesar los datos, tendremos un servidor específico, modelo IBM System X3950 X6. recomendado por IBM para el análisis de datos y el uso de herramientas big data.
Bastidor IBM 42U 1200mm Deep Dynamic Expansion Rack, modelo 93604EX
BladeCenter HS23 modelo 7875AC1
IBM BladeCenter Chassis H 88525TU
SOFTWARE
Arquitectura Hadoop.
La primera fase del proyecto sería hacer una extracción, scrapping/crawler, de los recursos de la web. La idea sería, nutrir nuestro operacional de recursos/servicios (nuestra entidad de base de datos).
Tendríamos que montar una arquitectura software, con software del ecosistema Hadoop, HDFS, MapReduce, Hadoop Streaming, Hive and Hue, Pig, Sqoop, Oozie, HBase, Flume, Whirr, Mahout, Fuse, Zookeeper, entre otros.
Este ecosistema se utilizará para montar un crawler que nos extraiga, analice y categorice los recursos encontrados en la web. También será la encargada de analizar toda la información que podamos encontrar como datos de las diferentes oficinas de turismo, ayuntamientos, cabildos, compra de diferentes bases de datos a empresas o cámaras de comercios.
Crawler, buscadores WEB y su funcionamiento
Un clasificador es una técnica capaz de diferenciar elementos de acuerdo con sus características y agruparlos en órdenes o clases. Estos algoritmos se pueden dividir en dos grandes grupos. Usaremos los algoritmos de aprendizaje supervisado, en los que se dispone de un conjunto de datos con ejemplos de entrenamiento etiquetados previamente.
SVM (Support Vector Machine o Máquinas de Vectores de Soporte) son los que usaremos para categorizar los recursos.
Esquema de crawler
Utilizaremos este ecosistema para la búsqueda de productos, para minería de datos, procesos de ETL y análisis de datos.
Software App Mobile/Web Mobile. IBM Worklight 6.X. Dentro de las posibilidades que nos ofrece esta herramienta, nos hemos decantado por desarrollar una App mixta, por un lado será híbrida y otras partes del desarrollo serán en código nativo específico para cada dispositivo (Objective-C para IOS, Java para Android).
Worklight consta de los componentes: · Studio:
· Worklight Server
· Componentes de tiempo de ejecución (SDK de Worklight)
· Consola Worklight
Base de Datos. IBM DB2 with BLUE Aceleration, ya que DB2 10.5 nace de la necesidad de administrar y manipular grandesvolúmenes de información.
DB2 BLU está diseñado bajo las siguientes ideas: a. Simple y fácil de usar
b. Compresión extrema
c. Almacenamiento de la información por columnas d. Salto de datos (Data Skipping)
e. Paralelismo multiprocesamiento f. Explotación del CPU
g. Datos en memoria
Por todas estas características hemos escogido DB2 como nuestro gestor de base de datos. Nuestro modelo de base de datos, gestiona localizaciones/ubicaciones y para ello nos hemos basado en las directiva Inspire y en el marco de referencia de TMFORUM.
Cartografía GIS. Cuando un usuario planifica un viaje con nuestra aplicación, se le presenta en un mapa la planificación de su viaje/ruta. El usuario la puede ir modificando a su gusto directamente en el mapa e ir añadiendo nuevos destinos directamente desde el mapa.
Los mapas tendrán bastante uso dentro de la aplicación, ya que añade la funcionalidad de GPS, es decir, le indicará al usuario el recorrido hasta llegar a su próximo destino. Fundamentales en la funcionalidad “On the Go”.
Usaremos ArcGIS es una completa plataforma de información que permite crear, analizar, almacenar y difundir datos, modelos, mapas y globos en 3D, poniéndolos a disposición de todos los usuarios según las necesidades de la organización.
ArcGIS es accesible desde clientes desktop, navegadores web, y terminales móviles que se conectan a servidores de departamento, corporativos.
También disponen de Location Analytics, que facilita el análisis geográfico de tus datos con mapas intuitivos y herramientas analíticas.