2. Marco Teorico
3.7. Ingenier´ıa Industrial
3.7.1. Perfil Del Egresado
El Ingeniero Industrial de la UDFJC, est´a en capacidad de gestionar orga- nizaciones, soportado en estructuras de pensamiento sist´emico, mediante el modelado de procesos en los sistemas productivos, para la toma de decisiones enfocadas al Desarrollo Sostenible y al mejoramiento de la productividad y la competitividad.
Gestionar Organizaciones:Liderar e integrar las dimensiones de una organizaci´on (talento humano, producci´on, mercadeo, finanzas, inves- tigaci´on y desarrollo) generando valor agregado.
Estructuras de pensamiento sist´emico: Abstraer y analizar los componentes de los sistemas productivos y sus relaciones causales de manera hol´ıstica.
Modelizar y Modelar sistemas productivos: Representar formal- mente la realidad en los componentes funcionales de la cadena de abas- tecimiento de manera confiable, viable y verificable.
Toma de decisiones:Pensar conceptual, anal´ıtica y cr´ıticamente, pa- ra analizar la informaci´on, proponer y evaluar alternativas a situaciones probl´emicas.
Desarrollo Sostenible Propender por el crecimiento econ´omico y el bienestar social, manteniendo y fortaleciendo la fuente de los recursos, para la satisfacci´on de las necesidades de la comunidad y el entorno, a trav´es del tiempo.
Competitividad y productividad:Combinar eficaz y eficientemen- te los recursos para alcanzar el ´optimo desempe˜no individual y orga- nizacional, que responda a las necesidades y exigencias de la sociedad, generando rentabilidad de manera sostenible.
3.7. INGENIER´IA INDUSTRIAL 35
Investigaci´on, innovaci´on y desarrollo tecnol´ogico. Identificar oportunidades de investigaci´on a partir de situaciones de contexto, teor´ıas y/o t´ecnicas que generen desarrollo tecnol´ogico.
Cap´ıtulo 4
Metodolog´ıa
4.1.
Introducci´on
Scrum es un proceso en el que se aplican de manera regular un conjunto de buenas pr´acticas para trabajar colaborativamente, en equipo, y obtener el mejor resultado posible de un proyecto. Estas pr´acticas se apoyan unas a otras y su selecci´on tiene origen en un estudio de la manera de trabajar de equipos altamente productivos.
En Scrum se realizan entregas parciales y regulares del producto final, prio- rizadas por el beneficio que aportan al receptor del proyecto. Por ello, Scrum est´a especialmente indicado para proyectos en entornos complejos, donde se necesita obtener resultados pronto, donde los requisitos son cambiantes o poco definidos, donde la innovaci´on, la competitividad, la flexibilidad y la productividad son fundamentales.
Scrum tambi´en se utiliza para resolver situaciones en que no se est´a entre- gando al cliente lo que necesita, cuando las entregas se alargan demasiado, los costes se disparan o la calidad no es aceptable, cuando se necesita capaci- dad de reacci´on ante la competencia, cuando la moral de los equipos es baja y la rotaci´on alta, cuando es necesario identificar y solucionar ineficiencias sistem´aticamente o cuando se quiere trabajar utilizando un proceso especia- lizado en el desarrollo de producto.[Agi]
4.1. INTRODUCCI ´ON 37
4.1.1.
Proceso
El desarrollo se realiza de forma iterativa e incremental. Cada iteraci´on, denominadaSprint, tiene una duraci´on preestablecida de entre 2 y 4 sema- nas, obteniendo como resultado una versi´on del software con nuevas pres- taciones listas para ser usadas. En cada nuevo Sprint, se va ajustando la funcionalidad ya construida y se a˜naden nuevas prestaciones prioriz´andose siempre aquellas que aporten mayor valor de negocio.
Figura 4.1: Proceso de SCRUM
Product Backlog:Conjunto de requisitos denominados historias des- critos en un lenguaje no t´ecnico y priorizados por valor de negocio, o lo que es lo mismo, por retorno de inversi´on considerando su beneficio y coste. Los requisitos y prioridades se revisan y ajustan durante el curso del proyecto a intervalos regulares.
Sprint Planning:Reuni´on durante la cual el Product Owner presenta las historias del backlog por orden de prioridad. El equipo determina la cantidad de historias que puede comprometerse a completar en ese sprint, para en una segunda parte de la reuni´on, decidir y organizar c´omo lo va a conseguir.
Sprint: Iteraci´on de duraci´on prefijada durante la cual el equipo tra- baja para convertir las historias del Product Backlog a las que se ha comprometido, en una nueva versi´on del software totalmente operativo.
Sprint Backlog:Lista de las tareas necesarias para llevar a cabo las historias del sprint.
Daily sprint meeting: Reuni´on diaria de c´omo m´aximo 15 min. en la que el equipo se sincroniza para trabajar de forma coordinada. Ca- da miembro comenta que hizo el d´ıa anterior, que har´a hoy y si hay impedimentos.
Demo y retrospectiva: Reuni´on que se celebra al final del sprint y en la que el equipo presenta las historias conseguidas mediante una de- monstraci´on del producto. Posteriormente, en la retrospectiva, el equi- po analiza qu´e se hizo bien, qu´e procesos ser´ıan mejorables y discute acerca de c´omo perfeccionarlos.
4.1.2.
Roles en SCRUM
En Scrum, el equipo se focaliza en construir software de calidad. La ges- ti´on de un proyecto Scrum se centra en definir cu´ales son las caracter´ısticas que debe tener el producto a construir (qu´e construir, qu´e no y en qu´e orden) y en vencer cualquier obst´aculo que pudiera entorpecer la tarea del equipo de desarrollo.
A modo diferenciador de la mayor´ıa de metodolog´ıas, en SCRUM no existe un gerente del proyecto. El equipo Scrum est´a formado por los siguientes roles:
Scrum master:Persona que lidera al equipo gui´andolo para que cum- pla las reglas y procesos de la metodolog´ıa. Gestiona la reducci´on de impedimentos del proyecto y trabaja con el Product Owner para ma- ximizar el ROI.
Product owner (PO):Representante de los accionistas y clientes que usan el software. Se focaliza en la parte de negocio y el es responsable del ROI del proyecto (entregar un valor superior al dinero invertido). Traslada la visi´on del proyecto al equipo, formaliza las prestaciones en historias a incorporar en el Product Backlog y las reprioriza de forma regular.
Team: Grupo de profesionales con los conocimientos t´ecnicos necesa- rios y que desarrollan el proyecto de manera conjunta llevando a cabo las historias a las que se comprometen al inicio de cada sprint.
4.1. INTRODUCCI ´ON 39
Parte III
Desarrollo
4.2. MODELO DE AFINIDAD VOCACIONAL CARRERAS DE PREGRADO DE LA UNIVERSIDAD DISTRITAL SEDE INGENIER´IA (MAVPUDI)41
4.2.
Modelo de Afinidad vocacional Carreras
de Pregrado de la Universidad Distrital
sede Ingenier´ıa (MAVPUDI)
Uno de los principales problemas que tienen los j´ovenes al momento estar en proceso de elegir una carrera, o incluso ya teni´endola casi definida, el pa- norama al momento de finalizar la universidad no es muy claro, en muchos casos los aspirantes o incluso los estudiantes no tienen claro los campos de acci´on al momento de dejar la universidad, ¿En qu´e puedo trabajar? ¿Sobre qu´e rama de la carrera me podre especializar? O incluso muchas veces no se tienen ning´un conocimiento sobre las diferentes ´areas de la carrera que ha decidido estudiar.
Por estas razones el MAVPUDI se plantea como un modelo de apoyo donde la orientaci´on vocacional se presenta de tal manera que los aspirantes tengan mejores herramientas y mayor conocimiento sobre la carrera y las ´areas sobre las que se pude desempe˜nar un profesional en las ´areas de la ingenier´ıa. El MAVPUDI pretende mostrar un porcentaje de afinidad de los aspirantes con las carreras profesionales, en este marco se presenta un modelo basado en cuestionarios con diferentes preguntas y respuestas, las cuales al final se analizar´an y presentaran un resultado de compatibilidad del aspirante con la carrera que ha seleccionado.
Dentro de las preguntas planteadas por el modelo se debe tener en cuen- ta que las preguntas pueden obedecer a diferentes tipos de habilidades y concordancias con la carrera, En este caso se puede contar con habilidades blandas como las comunicativas o habilidades duras como temas m´as t´ecni- cos y acad´emicos de cada carrera. Por esto se plantea el modelo basado en preguntas con una respectiva tipolog´ıa sobre la cual se aplicara un peso es- pec´ıfico, a mayor peso mayor valor tendr´a la pregunta, al final se promediara para definir el porcentaje de afinidad .
Para el desarrollo del MAVPUDI se evaluaron diferentes modelos de orienta- ci´on vocacional existentes y de ellos se han obtenido las bases para el dise˜no del modelo de orientaci´on vocacional a implementar en el presente proyecto. Los modelos de orientaci´on vocacional que se estudiaron son presentados en el cuadro (n´umero del cuadro), en varios casos para estos modelos se tiene en cuenta factores como la crianza y la infancia, En otros se abarcan dife- rentes ´areas de la educaci´on, pero en el caso del proyecto actual muchos de
estos modelos no son aplicables debido a que el proyecto comprende solo las ramas de la ingenier´ıa impartidas por la Universidad distrital sede ingenier´ıa. Por esto de los modelos evaluados se han seleccionado dos como los m´as indicados como base y apoyo al modelo que se pretende implementar en la facultad de ingenier´ıa, en este caso se cuenta con:
Modelos de asesoramiento vocacional de f. Rivas Este modelo basado en la autoayuda se puede presentar como una base fundamental para el dise˜no del modelo actual, esto se debe a que para la implementaci´on del modelo de orientaci´on vocacional, se pretende que los j´ovenes que har´an uso de la plataforma ya tengan un ´area vocacional predefinida, como principio del modelo se cuenta con que ellos para iniciar con la orientaci´on vocacional, deben seleccionar una de las carreras que son:
Ingenier´ıa catastral y geodesia
Ingenier´ıa de sistemas
Ingenier´ıa electr´onica
Ingenier´ıa el´ectrica
Ingenier´ıa industrial
En este caso el aspirante ira navegando por la diferente informaci´on que se le brindara respecto a cada una de la diferentes carreras, en este caso podr´a indagar sobre informaci´on espec´ıfica de la carrera o incluso sobre datos espec´ıficos sobre la Universidad Distrital.
Modelo de enfoques de toma de decisiones y aprendizaje social Krum- bolt
Este modelo de orientaci´on vocacional basado en la toma de decisiones se presenta como una gu´ıa que puede ser adaptable al MAVPUDI ya que al realizar la implementaci´on por medio de un chat de interacci´on entre el aspirante y el sistema, el basado en sus respuestas el sistema lo va guiando en el camino de la carrera seleccionada.
Modelo Integral de orientaci´on vocacional – profesional (MIOVP) y Test de orientaci´on de Malca de Goldenberg y Magali Merch´an (TOV) Este modelo tiene como principal eje la implementaci´on de diferentes encuestas a estudiantes y a padres de familia, tiene en cuenta temas socio-demograficos, Pruebas saber 11, entre otros cuestionarios, tam- bi´en se incluye la implementaci´on del test de Malca de Goldenberg
4.2. MODELO DE AFINIDAD VOCACIONAL CARRERAS DE PREGRADO DE LA UNIVERSIDAD DISTRITAL SEDE INGENIER´IA (MAVPUDI)43 y Magali Merch´an, el test se presenta como una encuesta que contie-
ne una serie de preguntas en las cuales se deben marcar si se siente afinidad, cada pregunta realizada se encuentra dentro de un ´area de conocimiento espec´ıfico, de acuerdo a los resultados obtenidos se mues- tra unos valores de afinidad con las diferentes ´areas del conocimiento. El TOV se aplica al proyecto como una parte de la base de la encuesta de afinidad que ser´a implementada, y sobre la cual al funcionar sobre diferentes ´areas de estudio, es una base a aplicar sobre el MAVPUDI ya que una parte de la orientaci´on que realice el proyecto estar´a basada en un cuestionario que ser´a evaluado para presentar el porcentaje de afinidad del estudiante con la carrera previamente seleccionada. El MOVPUDI tendr´a como fundamento la siguiente estructura que es sobre la cual se basara el modelo de orientaci´on:
El aspirante tendr´a preseleccionada una de las carreras ofrecidas por la Universidad Distrital Sede Ingenier´ıa
El aspirante podr´a obtener informaci´on espec´ıfica sobre la carrera im- partida en la universidad distrital
El aspirante podr´a obtener informaci´on sobre las diferentes ramas de la carrera seleccionada
El sistema le guiara y mostrara el campo de acci´on profesional de la carrera
4.3.
Desarrollo
4.3.1.
Diagrama general del proyecto
Figura 4.3: Diagrama General del proyecto
La imagen 4.1 representa el modelo de negocio planteado en el proyecto contando con una serie de entidades y relaciones que permiten definir los procesos generales se presentan a continuaci´on:
1. Un estudiante al finalizar sus estudios de colegio tiene la posibilidad de ingresar a realizar sus estudios profesionales, esto hace que el estudiante pasa a ser un aspirante de ingreso a la universidad
2. El estudiante toma la decisi´on sobre la carrera que desea estudiar (En este caso la carrera elegida ser´a una de las carreras de pregrado de la Facultad de Ingenier´ıa de la Universidad Distrital FJC), para es- to debe buscar informaci´on referente a la carrera, buscar orientaci´on profesional.
3. El sistema de ofrecer´a un ChatBot que le permitir´a realizar un test que le permitir´a obtener un nivel de afinidad con la carrera elegida. El chat- bot se encargar´a de realizarle diferentes preguntas con los cuales podr´a realizar los c´alculos y presentar algunas recomendaciones al aspirante.
4.3. DESARROLLO 45
4.3.2.
Selecci´on del BOT
Para el desarrollo del proyecto se realiz´o la evaluaci´on de diferentes plata- formas sobre las cuales se pueden desarrollar el BOT (Ver Anexo 2). Dentro de los Bots se encuentran wit.AI, IBM Watson, BOT Framework, entre otros. Al final se ha seleccionado BOT Framework de Microsoft como plataforma de desarrollo debido a la facilidad de despliegue para los diferentes canales y las facilidades con la integraci´on con diferentes servicios web, adem´as de contar con una plataforma administrativa y un API para realizar las pruebas del BOT sin necesidad de desplegar en alg´un canal en particular.
Microsoft BOT Framework
BOT Framework es la apuesta de Microsoft en el desarrollo de bots, cons- truyendo una plataforma completa que permite la construcci´on de Chatbots basados en lenguaje C# o Node.JS. Cuenta con un conjunto de herramientas de cognitive services de Microsoft. Bot Framework ofrece la posibilidad de desarrollar bots basados en el desarrollo de servicios REST con WebApi. Por su facilidad en el desarrollo y dado que permite la integraci´on y el consu- mo de servicios REST o WCF, BOT Framework ha sido seleccionado como plataforma para el desarrollo del proyecto, adem´as de contar con un portal donde se puede establecer toda la configuraci´on del BOT, as´ı como el desplie- gue sobre los diferentes canales como Facebook Messenger, Telegram, Skype, entre otros, incluso se puede agregar dentro de cualquier portal web.
4.3.3.
Ciclo de Vida del Bot
ChatBot magazine que es una de las fuentes de informaci´on sobre bots mas importantes, define el ciclo de vida de un chatbot en 11 pasos que co- rresponden al ciclo de vida de un BOT.
Figura 4.4: Ciclo de vida de un BOT [Gala]
Requerimientos:Los requerimientos son el punto inicial de todo pro- yecto de desarrollo de software, para este caso todos los requerimientos dan como resultado las historias de usuario, que son la interpretaci´on del contenido del proyecto a nivel del desarrollo.
Spec y Script: Es necesario generar la estructura espec´ıfica del bot, adicionalmente se debe realizar un Script donde se determinen los com-
4.3. DESARROLLO 47 portamientos y como reaccionara a cada uno de ellos. El script del Bot tendr´a los siguientes comportamientos
Saludo: Se presenta un saludo al aspirante con una peque˜na introducci´on al Bot
Figura 4.5: Ventana Saludo
Datos: Se le solicitar´ıan algunos datos al usuario, (No ser´a ne- cesario responderlos todos)
Figura 4.6: Ventana Datos B´asicos
Selecci´on de Carrera: Se mostraran las carreras disponibles, el usuario podr´a elegir entre una de las que se muestran en la lista
Figura 4.7: Ventana Selecci´on de Carrera
Ejecuci´on del test: Se realizara una serie de preguntas a las cuales el usuario responder´a seg´un corresponda
Figura 4.8: Ventana Preguntas Especificas
Resultados: El sistema presentara los resultados del test
Arquitectura: La arquitectura del sistema esta soportada sobre la propia arquitectura de Bot Framework, lo que permite centrarse en que los dem´as elementos de la arquitectura est´en centrados en la l´ogica de negocios, en este caso se aplica basado en los servicios WebApi de acceso a datos.
Desarrollo: hace referencia a todo el desarrollo y codificaci´on de la aplicaci´on
4.3. DESARROLLO 49
Test: hace referencia a todas las pruebas correspondientes al sistema, en este caso se aplicar´ıan los test locales y los test despu´es de desplegada la aplicaci´on sobre uno de los canales.
Implementaci´on y publicaci´on: Hace referencia al despliegue de la aplicaci´on sobre alguno de los canales disponibles (Facebook Messenger, Skype, entre otros)
Monitoreo: Validaci´on de estado del bot y monitoreo general.
Promoci´on: Hace referencia a la publicidad y alcance del bot para que sea conocido por m´as personas, en este punto adem´as se incluyen los servicios de publicaci´on en las diferentes tiendas de bots.
An´alisis: Como en todas las metodolog´ıas de desarrollo de software, es necesario realizar siempre un an´alisis y verificar se debe ajustar, tambi´en validar que mejoras se tienen para el bot
4.3.4.
Modelo de datos
Para el modelado de datos se implement´o el sistema de gesti´on de bases de datos SQL Server 2016, que es un motor de base de datos muy popular para el desarrollo de sistemas de informaci´on, se utiliz´o la versi´on standar para no incurrir en gastos de licenciamiento
Para establecer la conexi´on con la base de datos se utiliz´o Entity Frame- work [Cor], el cual ademas de agilizar el proceso de desarollo de acceso a datos permite que la aplicaci´on se pueda actualizar en cualqueir momento de una manera rapida y eficiente, adem´as de optimizar las consultas y el tiempo de respuesta de la base de datos
4.3. DESARROLLO 51
4.3.5.
Diagrama de Componentes
4.3.6.
Diagrama de clases Acceso a datos
4.3. DESARROLLO 53
4.3.7.
Diagrama de clases Negocio
4.3.8.
Diagrama de clases Servicio
4.3. DESARROLLO 55