Villa de Álvarez, Col., junio de 2013 - ITColima
Transcript of Villa de Álvarez, Col., junio de 2013 - ITColima
Villa de Álvarez, Col., junio de 2013
SISTEMA WEB PARA ADMINISTRAR LA PRODUCTIVIDAD DEL RECURSO
HUMANO EN LA EMPRESA MAGMA LABS
DEMETER
Ana Karen Ventura Juárez
Nombre del Asesor
Ana Claudia Ruiz Tadeo
Nombre de la Carrera
Ing. Sistemas Computacionales
Villa de Álvarez, Col., a 05 de Junio del 2016
INFORME TÉCNICO DE RESIDENCIA PROFESIONAL QUE PRESENTA:
TECNOLOGICO DE COLIMA 3
Agradecimientos
Primeramente quiero agradecer a mis padres Natividad Juárez Sánchez y Lic. Guillermo
Velasco Gutiérrez por el apoyo y la confianza absoluta, gracias a ustedes por ser el soporte
que necesité durante la carrera y que hoy en día culmino, gracias también al ahora mi esposo
Mario Andrés Pacheco Méndez por su apoyo incondicional y por siempre creer en mí, así
mismo doy las gracias a cada uno de los maestros que me guiaron a lo largo de esta formación
académica, a base de sus enseñanzas y exigencias fueron participe de nuestros conocimientos
y desarrollo como profesionistas.
Gracias a M.C. Ana Claudia Ruíz Tadeo por ser mi asesora, por darme la confianza y apoyo
para el desarrollo de este proyecto.
Por último agradezco a mis compañeros y amigos quienes me brindaron su apoyo durante
todo el curso, sobre todo por su amistad y confianza, que me dieron la oportunidad de vivir
momentos inolvidables en una misma meta de vida.
Resumen
Actualmente el ámbito del desarrollo web se ha ido situando en una de las mejores
herramientas para el acceso a la información de manera fácil y sencilla; en este artículo se
presenta una aplicación web para llevar a cabo la administración de los recursos de una
empresa dedicada al desarrollo de proyectos de software, ya que te permite saber cuál es la
productividad de cada empleado en el proyecto asignado, además de saber de manera fácil
cual es la salud de la empresa y cuál es la productividad de esta, esto gracias a estadísticas y
cálculos aplicados mediante el sistema.
TECNOLOGICO DE COLIMA 4
Índice Agradecimientos ................................................................................................................. 3
Resumen .............................................................................................................................. 3
CAPÍTULO I CONTEXTO DEL PROYECTO ..................................................................... 7
1.1 Planteamiento del problema .......................................................................................... 8
1.2 Propuesta de Solución ................................................................................................... 8
1.3 Justificación .................................................................................................................. 9
1.4 Objetivos ....................................................................................................................... 9
1.4.1 Objetivo General .................................................................................................... 9
1.4.2 Objetivo Específico ................................................................................................ 9
1.5 Análisis de Requerimientos ........................................................................................ 10
1.5.1 Requerimientos de Software: ............................................................................... 10
1.5.2 Requerimientos de Hardware: ............................................................................. 10
1.5.3 Requerimientos Funcionales: ............................................................................... 10
1.5.4 Requerimientos no Funcionales: .......................................................................... 11
1.5.5 Requerimientos de Calidad .................................................................................. 11
1.6 Estudio de Factibilidad ............................................................................................... 11
1.6.1 Factibilidad Económica ....................................................................................... 11
1.6.2 Factibilidad Técnica ............................................................................................. 12
1.6.3 Factibilidad Operativa .......................................................................................... 13
1.6.4 Factibilidad Legal ................................................................................................ 13
1.7 Análisis Costo-Beneficio ............................................................................................ 14
1.8 Análisis de Alternativas .............................................................................................. 15
1.9 Alcances y Limitaciones del Proyecto ........................................................................ 15
1.9.1 Alcance ................................................................................................................ 15
1.9.2 Limitaciones ......................................................................................................... 15
1.10 Ventajas Competitivas .............................................................................................. 16
CAPÍTULO II ....................................................................................................................... 17
FUNDAMENTO TEÓRICO ................................................................................................ 17
2.1 Ciclo de vida del desarrollo de sistemas .................................................................... 18
2.1.1 identificación de problemas, oportunidades y objetivos: ..................................... 18
2.1.2 Determinación de los requerimientos de información: ........................................ 19
2.1.3 Análisis de las necesidades del sistema: .............................................................. 19
2.1.4 Diseño del sistema recomendado: ........................................................................ 19
2.1.5 Desarrollo y documentación del software: .......................................................... 19
2.1.6 Pruebas y mantenimiento del sistema: ................................................................. 20
2.1.7 Implementación y evaluación del sistema: .......................................................... 20
2.2 Lenguaje de programación .......................................................................................... 20
2.3 Lenguaje de programación web .................................................................................. 21
2.4 PostgresSQL ............................................................................................................... 22
2.5 Ruby on Rails .............................................................................................................. 22
2.6 HTML ......................................................................................................................... 22
TECNOLOGICO DE COLIMA 5
2.7 CSS ............................................................................................................................. 23
2.8 JavaScript .................................................................................................................... 23
CAPÍTULO III PROCEDIMIENTO Y DESCRIPCIÓN DE LAS ACTIVIDADES .......... 24
3.1 Antecedentes de la Metodología Utilizada: SCRUM ................................................. 25
3.1.1 Historia ................................................................................................................. 25
3.1.2 Fases de SCRUM ................................................................................................. 26
3.1.4 Cierre ................................................................................................................... 28
3.1.5 Controles de SCRUM .......................................................................................... 29
3.2 Planificación ............................................................................................................... 29
3.2.1 Requerimientos del usuario ................................................................................. 30
3.3 Diseño ......................................................................................................................... 30
3.3.1 Diagramas de casos de usos ................................................................................. 30
3.3.2. Modelo conceptual .............................................................................................. 36
3.3.3. Diagrama Entidad-Relación ................................................................................ 37
3.4 Desarrollo .................................................................................................................... 39
3.4.1. Módulo del Asignación vs Utilización ............................................................... 39
3.5 Implementación .......................................................................................................... 49
3.6 Pruebas ........................................................................................................................ 50
CAPÍTULO IV CONCLUSIONES ...................................................................................... 51
4.1 Cumplimiento de los Objetivos .................................................................................. 52
4.2 Trabajos Futuros ......................................................................................................... 52
4.3 Conclusión .................................................................................................................. 53
Referencias ............................................................................................................................ 54
Anexos .............................................................................................................................. 56
TECNOLOGICO DE COLIMA 6
Índice de Ilustraciones
Ilustración 1 Costo del Sistema ............................................................................................ 12
Ilustración 2. Fases del ciclo de vida del desarrollo de sistemas. ......................................... 18
Ilustración 3. Lenguajes de Programación ............................................................................ 21
Ilustración 4. Arquitectura de los lenguajes de programación web. ..................................... 21
Ilustración 5. Contenido HTML detrás de una página web. ................................................. 23
Ilustración 6. Modelo de casos de uso del módulo de asignación vs utilización. ................. 31
Ilustración 7 Modelo de casos de uso del módulo de administradores ................................. 35
Ilustración 8 Modelo conceptual ........................................................................................... 37
Ilustración 9 Diagrama Entidad-Relación ............................................................................. 38
Ilustración 10 Inicio de sesión .............................................................................................. 39
Ilustración 11 Omniauth ....................................................................................................... 40
Ilustración 12 Empleados a los que se les puede asignar a un proyecto ............................... 40
Ilustración 13 Filtro de información ..................................................................................... 41
Ilustración 14 Opciones principales ...................................................................................... 41
Ilustración 15 Asignación por color, gama de colores .......................................................... 42
Ilustración 16 Botón de asignación ....................................................................................... 42
Ilustración 17 Búsqueda ........................................................................................................ 42
Ilustración 18 Vista de asignación de proyectos ................................................................... 43
Ilustración 19 Edición de asignación de proyecto ................................................................ 44
Ilustración 20 Eliminación de asignación de proyecto ......................................................... 44
Ilustración 21 Vista para una nueva asignación .................................................................... 44
Ilustración 22 Selección del proyecto ................................................................................... 45
Ilustración 23 Vista del Chart ............................................................................................... 46
Ilustración 24 Funcionalidades y filtraciones del Chart ....................................................... 46
Ilustración 25 Vista de la utilización vs asignación .............................................................. 47
Ilustración 26 Vista del forecast ........................................................................................... 47
Ilustración 27 Vista para los reportes ................................................................................... 48
Ilustración 28 Reporte por empleado .................................................................................... 48
Ilustración 29 Reporte por proyecto ..................................................................................... 49
Ilustración 30 Botón de salida de sesión ............................................................................... 49
TECNOLOGICO DE COLIMA 8
1.1 Planteamiento del problema
Magma Labs necesita estar informada del desempeño laboral de sus empleados, para tener
una apreciación sistemática, periódica, estandarizada y cualificada del valor demostrado por
cada uno de los integrantes de su equipo. Su giro es el desarrollo de software, el cual
involucra diversos roles tales como Programador, Analista, Tester, Diseñador y Product
Manager. La labor realizada por cada rol se diferencia una de otra, por lo que es necesario
que su trabajo pueda ser medido y evaluado de forma efectiva, dependiendo de la asignación
de cada trabajador y la utilización de cada uno, que en realidad son las horas trabajadas con
respecto a la asignación.
1.2 Propuesta de Solución Crear un sistema para la administración de recursos humanos, en la cual se pueda visualizar
la asignación que tiene el recurso en un proyecto, saber cuál es la utilización de este, de igual
manera saber cuáles son los proyectos en los que se está trabajando y la rentabilidad de este.
Mediante un dashboard (interfaz donde el usuario puede administrar el equipo y/o software)
se sabrá que tanto se ha avanzado en un proyecto. En esta aplicación se registrará las horas
de trabajo que se dedica a cada proyecto. Se podrá diferenciar las horas facturables de las que
no lo son, y de esta manera se sabrá qué porcentaje de la jornada laboral dedicas a tareas
realmente productivas, a continuación se desglosa la propuesta de solución:
Obtener y filtrar datos de los de programadores y diseñadores que se encuentran en la
plataforma Bamboo (plataforma que administra la información de empleados de
diferentes empresas).
Interfaz de empleado (Búsquedas, filtros de información, asignar tiempo para cada
proyectos, Indicación de colores por tiempo de asignación).
Reporte de trabajos asignados por empleado y por fechas.
Graficar de tiempos por horas de trabajo, por programador (Opción Chart). Indicas lo
respecto a la utilización con respecto a la asignación. Si, cumpliendo lo planeado con lo
real trabajado. Por día, por proyecto, por mes.
Estimaciones del tiempo que se invertirá para desarrollar un proyecto de acuerdo al
avance con la metodología SCRUM.
TECNOLOGICO DE COLIMA 9
1.3 Justificación Contando con un sistema formal y sistemático de evaluación de desempeño de los empleados,
se obtendrá la retroalimentación necesaria para que el departamento de recursos humanos
puede identificar a los empleados que cumplen con las tareas establecidas dentro de un
proyecto, las cuales son: la asignación y productividad que se ha tenido en este, también se
notará a aquellos empleados que presenten deficiencias en las siguientes tareas: no trabajar
con respecto a la asignación que se le ha dado, cumplir con la puntación de las tareas
semanales y tener una buena productividad en el proyecto en el que se encuentra. Asimismo,
ayuda a evaluar los procedimientos de reclutamiento, selección y orientación, incluso las
decisiones sobre promociones internas, compensaciones y otras más.
Las personas que se desempeñan de manera insuficiente pueden poner en evidencia procesos
equivocados de selección, orientación y capacitación, o puede indicar que el diseño del
puesto o los desafíos externos no han sido considerados en todas sus facetas.
1.4 Objetivos
1.4.1 Objetivo General
Desarrollar una aplicación web que mida la productividad de los empleados de Magma Labs,
basado en las asignaciones y utilización de cada usuario.
1.4.2 Objetivo Específico
Analizar los requerimientos del sistema.
Diseñar un sistema atractivo, llamativo e interesante para el usuario en cuanto a su
contenido y calidad.
Codificar el código necesario para obtener un software de calidad
Probar el sistema a través de pruebas unitarias
Obtener satisfactoriamente la app para ser ejecutada y presentada ante al personal con
una previa verificación y evaluación de su funcionamiento.
TECNOLOGICO DE COLIMA 10
1.5 Análisis de Requerimientos
1.5.1 Requerimientos de Software:
Ruby on Rails framework
Ruby
Bamboo API
omniauth api authentication
Javascript
Postgres
Formulas
Fully Loaded Bill Rate (costo/precio)
FlBR: horas cobradas / horas meta
personas billable = diseñadores + developers + PM
Costo Directo = costo de nómina de diseñadores + developers
Costo Operativo = costo de operación + costo directo + staff + directores
Costo Overhead = costo operativo / # de personas billable
Fully loaded cost rate (FLCR)
Fully loaded cost rate (adjusted)
1.5.2 Requerimientos de Hardware:
Computadora
Teclado
Mouse
1.5.3 Requerimientos Funcionales:
manejo del tiempo, billable(facturable) y no billable
Depurar el performance de Harvest
Permitir asignaciones
Asignaciones en cortes semanales
Asignaciones variables
Modificaciones en las asignaciones
Asignaciones hacia el futuro
TECNOLOGICO DE COLIMA 11
Dashboard(tablero) de empleados y proyectos
1.5.4 Requerimientos no Funcionales:
El sistema deberá:
Visualizarse y funcionar en cualquier navegador
Visualizarse y funcionar correctamente en cualquier Sistema Operativo
Ser programa en Ruby on Rails
Tener una respuesta rápida cuando se emita una solicitud al servidor
1.5.5 Requerimientos de Calidad
El sistema deberá:
Tener un buen rendimiento
Contar con una buena experiencia de usuario UX, así como ser atractivo.
1.6 Estudio de Factibilidad
1.6.1 Factibilidad Económica
Dentro de la “factibilidad económica se muestra que la inversión que se está realizando se
encuentra justificada por la ganancia que se generará” (Hernández, 2013). Para lo cual se
implementa el uso de esquemas en los que se aprecien todos los costos ya sean fijos y/o
variables, a su vez cada uno de los beneficios a obtener.
Este tipo de estudio incluye análisis de costo/beneficio asociados con cada una de las
alternativas del proyecto; analizando todos los costos y beneficios de adquisición y operación
de cada sistema alternativo identificando y realizando comparaciones entre ellos.
TECNOLOGICO DE COLIMA 12
Ilustración 1 Costo del Sistema
En la ilustración 1 se muestra el costo del sistema en base a la estimación previa, el monto
total es en dólares.
1.6.2 Factibilidad Técnica
Para llevar a cabo el desarrollo de la aplicación se utilizará lenguaje de fácil uso y con un
costo aceptable, para el equipo de trabajo se necesitará:
Computadora
Software(Ruby on Rails)
Este software fue el elegido porque es un lenguaje fácil de manejar, y es el que se utiliza en
la empresa, además que hoy en día se encuentra infinidad de información en la red acerca de
cómo programar aplicaciones con este lenguaje.
La tecnología y los componentes son aprobados por el cliente, ya que ellos tienen amplios
conocimientos técnicos del área por ser del Departamento de Sistemas y quedaron
convencidos de los requerimientos técnicos para el desarrollo de la app.
TECNOLOGICO DE COLIMA 13
1.6.3 Factibilidad Operativa
Esta factibilidad comprende una determinación de la probabilidad de que el sistema se use
como se supone que debe ser implementado donde el modo de operación y uso se encuentra
garantizado (Lacayo, 2013).
Es por ello que se puede decir que existe un 70% de probabilidad, ya implementado la
aplicación, de que se utilice correctamente con las especificaciones de programación y
utilización que se marcarán en la guía de usuario y un 30% de probabilidad de que esta app
sea utilizada de manera inadecuada poniendo en riesgo las funciones operativas del mismo.
No es necesario tener conocimientos relacionados con la programación por parte del usuario,
ya que hoy en día cualquiera sabe cómo interactuar con una aplicación móvil. Por lo general
los usuarios poseen conocimientos básicos de lógica que permiten que el desarrollo del
funcionamiento de la app sea sencillo de asimilar, además que se integra una guía de usuario
que facilitará el desarrollo del mismo.
Con respecto a la factibilidad operativa el cliente aprueba lo especificado anteriormente,
además de que los usuarios tienen más conocimiento de estas tecnologías ya que están en el
área de Sistemas, garantizando el buen funcionamiento de la aplicación.
1.6.4 Factibilidad Legal
Permitiendo el desarrollo del proyecto Demeter se hace referencia al estudio legal que
conlleva el análisis de las leyes que respaldaran el proyecto ya mencionado, aplicándonos
al margen de la ley para hacer un buen uso de las normas reglamentarías que nos respaldaran
ante cualquier acto o ente jurídico.
En la actualidad hay una familia de normas ISO/IEC 25000, que proporciona una guía para
el uso de la nueva serie de estándares internacionales llamada Requisitos de Evaluación de
Calidad de Productos de Software.
Existen normas como ISO/IEC 25000 que constituye una serie de normas basadas en
ISO/IEC 9126 y en ISO/IEC 14598 cuyo objetivo principal es guiar el desarrollo de los
productos de software mediante la especificación de requisitos y evaluación de características
TECNOLOGICO DE COLIMA 14
de calidad, tales como: funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibilidad,
portabilidad y calidad de uso (ISO 25000, 2015).
El lenguaje de programación a implementar es libre, por lo cual no se entra en ningún
problema legal ya que todo es de código abierto, por lo cual quedan descartados cualquier
tipo de anomalía en el software
Software a utilizar:
Ruby on Rails.
Con respecto a esta factibilidad, el cliente está convencido del marco legal donde recae el
software libre y sabe de antemano que no habrá problemas al utilizar este framework.
1.7 Análisis Costo-Beneficio
El análisis costo-beneficio, nos permitirá definir la factibilidad del proyecto a ser
desarrollado.
Beneficios Intangibles
Al implementar esta nueva aplicación “Demeter” se podrá saber fácilmente cual es el estado
de la empresa y si sus recursos están asignados a un proyecto, esto claramente significa que
la empresa tiene proyectos en desarrollo por lo cual los ingenieros están asignados, así
mismo se podrá observar cual es la utilización de cada empleado, y se sabrá cuanto es lo
que ha trabajado en el proyecto asignado.
Beneficios Tangibles
Estos serán apreciados en las facturas generadas a los clientes, ya que se podrá comprobar
que es lo que ha trabajado cada ingeniero en el proyecto asignado, así mismo se ahorrará
tiempo ya que la aplicación a simple vista mostrará con los rangos de colores la asignación
de cada empleado.
TECNOLOGICO DE COLIMA 15
1.8 Análisis de Alternativas
Actualmente solo surgió una alternativa para dar solución al problema mencionado
anteriormente.
En este caso una aplicación que maneje información proveniente de las apis de Bambooh y
Harvest, así mismo maneje las asignaciones para un proyecto, la utilización con respecto a la
asignación dada, asignaciones hacia el futuro y tendencias de estos datos.
1.9 Alcances y Limitaciones del Proyecto
Existen características que se tienen que tomar en cuenta para llevar a cabo el desarrollo de
la aplicación, donde todas las habilidades y espacios pueden limitarse; a continuación se
muestran los alcances y limitaciones del Sistema:
1.9.1 Alcance
La programación de la aplicación será con el framework Ruby on Rails.
Desarrollar la aplicación Demeter.
Hacer llegar este sistema a Gabriel Gonzales, el cual es el encargado de llevar a cabo
la administración de los proyectos.
El Administrador podrá asignar proyectos, analizar la información, crear reportes y
agregar o eliminar a otros administradores.
1.9.2 Limitaciones
Una limitación podría ser en el desarrollo de la aplicación, ya que no se cuenta con suficiente
tiempo para desarrollar y terminar en tiempo y forma.
El proceso laboral, solo será por 16 semanas con 8 horas de desarrollo al día, el
tiempo es una gran limitación, ya que no contamos con lo necesario para
desarrollar el proyecto, esto puede afectar directamente a la aplicación ya que
puede concluir de una manera inesperada
TECNOLOGICO DE COLIMA 16
1.10 Ventajas Competitivas
En el mundo de la tecnología existe un sinfín de aplicaciones para el tracking de proyectos,
pero Demeter es una aplicación personalizada, ya que estamos utilizando diferentes
alimentadores de datos, tales como Harvest y Bambooh, actualmente ninguna aplicación en
el mercado cuenta con estas características específicas, es por ello que ventaja competitiva
como tal no la hay, pero existen alguna aplicaciones parecidas, a continuación mencionaré
dos de las más conocidas:
Clockodo
En esta aplicación se puede realizar un seguimiento de los tiempos de trabajo de forma rápida,
sencilla y fiable en línea. Informes claros y detalles, versatilidad en el análisis de los tiempos.
Paymo
Es una aplicación para el seguimiento de tiempo, es ahora parte de una plataforma de gestión
de proyectos para equipos.
TECNOLOGICO DE COLIMA 18
2.1 Ciclo de vida del desarrollo de sistemas
Es importante destacar el ciclo de vida del desarrollo de sistemas puesto que es la guía que
nos servirá para concluir de manera organizada un proyecto, para esto se describen a
continuación las siguientes 7 fases que lo conforman.
Ilustración 2. Fases del ciclo de vida del desarrollo de sistemas.
En la ilustración 2 se muestra cómo se lleva a cabo las fases del ciclo de vida del desarrollo
de sistemas.
2.1.1 identificación de problemas, oportunidades y objetivos:
La primera fase requiere que el analista observe honestamente lo que está sucediendo en un
negocio. Luego, junto con los demás miembros de la organización, el analista hace resaltar
los problemas. Frecuentemente estos ya han sido vistos por los demás, y son la razón por la
cual el analista fue llamado inicialmente. Las personas involucradas en la primera fase son
los usuarios, analistas y administradores de sistemas que coordinan el proyecto.
Las actividades de esta fase consisten en entrevistas a los administradores de los usuarios,
sumarización del conocimiento obtenido, estimación del alcance del proyecto y
documentación de los resultados. La salida de esta fase es un estudio de factibilidad que
contiene una definición del problema y la sumarización de los objetivos (Hernández, 1998).
TECNOLOGICO DE COLIMA 19
2.1.2 Determinación de los requerimientos de información:
El aspecto del análisis es comprender todas las facetas de la empresa que están bajo estudio
y estas tienen como prioridad responder a las siguientes preguntas, ¿Qué es lo que hace?,
¿Cómo se hace?, ¿Con qué frecuencia se presenta?, ¿Qué tan grande es l volumen de
transacciones o decisiones?, ¿Cuál es el grado de eficiencia con el que se efectúan las tareas?,
¿Existe algún problema?, ¿Qué tan serio es? Y ¿cuál es la causa que lo origina? (Senn, 1992)
Esta etapa está enfocada a que el analista comprenda la información y para ello participan
los usuarios, los administradores de las operaciones y los trabajadores de la operación.
2.1.3 Análisis de las necesidades del sistema:
En esta etapa el analista de sistemas se auxilia de herramientas ya creadas para determinar
los requerimientos, por ejemplo diagramar la entrada, proceso y salida de las funciones del
negocio en forma gráfica y estructurada, desarrollar diccionarios de datos, y dar una
estructura a las bases de datos como el diagrama entidad relación, ya que este nos ayudará a
trabajar con objetos de manera independiente.
2.1.4 Diseño del sistema recomendado:
El diseño de un sistema de información produce los detalles que establecen la forma en la
que el sistema cumplirá con los requerimientos identificados durante la fase de análisis. Los
especialistas en sistemas se refieren, con frecuencia, a esta etapa como diseño lógico en
contraste con la del desarrollo del software, a la que denominan diseño físico. (Senn,1992)
2.1.5 Desarrollo y documentación del software:
En la quinta fase del ciclo de vida del desarrollo de sistemas el analista trabaja con los
programadores para desarrollar cualquier software original que se necesite. Durante esta fase,
el analista también trabaja con los usuarios para desarrollar documentación efectiva para el
software, incluyendo manuales de procedimientos. La documentación le dice al usuario la
manera de usar el software y también qué hacer si se suceden problemas con el software.
(Hernández, 1998)
TECNOLOGICO DE COLIMA 20
2.1.6 Pruebas y mantenimiento del sistema:
Durante la prueba de sistemas, el sistema se emplea de manera experimental para asegurarse
de que el software no tenga fallas, es decir, que funciona de acuerdo con las especificaciones
y en la forma en que los usuarios esperan que lo haga.
2.1.7 Implementación y evaluación del sistema:
En esta fase del desarrollo del sistema el analista ayuda a implementar el sistema de
información. Esto incluye el entrenamiento de los usuarios para que manejen el sistema.
Algún entrenamiento es hecho por los proveedores, pero la supervisión del entrenamiento es
responsabilidad del analista de sistemas. Adicionalmente, el analista necesita un plan para
una conversión suave del sistema antiguo al nuevo. (Hernández, 1998)
Una vez concluidos los 7 pasos del desarrollo de sistemas, se procede al continuo
mejoramiento ya que conforme avanza el tiempo pueden requerirse nuevos componentes al
sistema y esto lo hace cada vez más completo.
2.2 Lenguaje de programación
Según Wilson la definición de lenguaje de programación se la siguiente:
“Un lenguaje de programación es un idioma artificial diseñado para expresar computaciones
que pueden ser llevadas a cabo por máquinas como las computadoras. Pueden usarse para
crear programas que controlen el comportamiento físico y lógico de una máquina, para
expresar algoritmos con precisión, o como modo de comunicación humana”.
En la actualidad existe una diversidad de lenguajes de programación, el cual, cada uno de
ellos tienen características, aplicación y propósito distinto.
TECNOLOGICO DE COLIMA 21
Ilustración 3. Lenguajes de Programación
Como se observó en la ilustración 3 los lenguajes de programación más utilizados en la actualidad.
2.3 Lenguaje de programación web
Actualmente existen diferentes lenguajes de programación para desarrollar en la web, estos
han ido surgiendo debido a las necesidades que han surgido en la programación.
Los lenguajes de programación web generalmente siguen un proceso.
Ilustración 4. Arquitectura de los lenguajes de programación web.
En la ilustración 4 se muestra la arquitectura general de los lenguajes de programación web.
TECNOLOGICO DE COLIMA 22
2.4 PostgresSQL
Es un Sistema de gestión de bases de datos relacional orientado a objetos y libre, publicado
bajo la licencia PosgreSQL, similar a la BSD o la MIT.
Como muchos otros proyectos de código abierto, el desarrollo de PostgreSQL no es
manejado por una empresa y/o persona, sino que es dirigido por una comunidad de
desarrolladores que trabajan de forma desinteresada, altruista, libre y/o apoyada por
organizaciones comerciales. Dicha comunidad es denominada el PostgresSQL Global
Development Group.
2.5 Ruby on Rails
Conocido como RoR o Rails, es un framework de aplicaciones web de código abierto escrito
en el lenguaje de programación Ruby, siguiendo el paradigma de la arquitectura Modelo
Vista Controlador (MVC). Trata de combinar la simplicidad con la posibilidad de desarrollar
aplicaciones del mundo real escribiendo menos código que con otros frameworks y con un
mínimo de configuración. El lenguaje de programación Ruby permite la metaprogramación,
de la cual Rails hace uso, lo que resulta en una sintaxis que muchos de sus usuarios
encuentran muy legible. Rails se distribuye a través de RubyGems, que es el formato oficial
de paquete y canal de distribución de bibliotecas y aplicaciones Ruby.
2.6 HTML
El HTML es el lenguaje de la Web, tras cada página visitada al azar durante una exploración
por la web se oculta su código fuente, En efecto, el navegador, Microsoft Internet Explorer
o Firefox no hace más que mostrar en pantalla la página diseñada por su autor mediante un
lenguaje, a priori bastante hermético, como es el lenguaje HTML.
TECNOLOGICO DE COLIMA 23
Ilustración 5. Contenido HTML detrás de una página web.
En la ilustración 5 se presentó un ejemplo de una muestra de las etiquetas que conforman
una página Web.
2.7 CSS Hojas de Estilo en <Cascada (Cascading Style Sheets), es un mecanismo simple que describe
cómo se va a mostrar un documento en la pantalla, o cómo se va a imprimir, o incluso cómo
va a ser pronunciada la información presente en ese documento a través de un dispositivo de
lectura. Esta forma de descripción de estilos ofrece a los desarrolladores el control total sobre
estilo y formato de sus documentos.
2.8 JavaScript Es un lenguaje de programación interpretado dialecto del estándar ECMAScript. Se utiliza
principalmente en su forma del lado del cliente (client-side), implementado como parte de
un navegador Web permitiendo mejoras en la interfaz de usuario y páginas Web dinámicas,
aunque existe una forma de Javascript del lado del servidor (Server-side Javascript o SSJS).
TECNOLOGICO DE COLIMA 25
3.1 Antecedentes de la Metodología Utilizada: SCRUM
3.1.1 Historia
Scrum es el término dado por Nonaka y Takeuchi al método de desarrollo de nuevos
productos realizado con equipos reducidos, multidisciplinares, que trabajan con
comunicación directa y empleando ingeniería concurrente, en lugar de ciclos o fases
secuenciales.
Esta forma de trabajo logra niveles de eficiencia y valor en el producto superiores a los
obtenidos con ingeniería secuencial y producción basada en procesos. En los 80, Nonaka y
Takeuchi (Takeuchi & Nonaka 1986) analizaron esta forma de producción, observando cómo
trabajaban los equipos de las empresas tecnológicas que lograban mayores niveles de
eficiencia y valor en sus productos ("New New Product Development Game"): Fuji-Xerox,
Canon, Honda, NEC, Epson, Brother, 3M, Xerox y Hewlett-Packard.
Diez años más tarde Ken Schwaber presentó en OOPSLA (1995) la descripción de la
implementación de Scrum para software que él empleaba en el desarrollo de Delphi.
Las implementaciones de Scrum para desarrollo de software se vienen enriquecendo desde
entonces, y poco tienen que ver las implementaciones actuales con la original de Ken. Ahora
es muy raro que alguien configure un campo de Scrum con los controles originales (paquetes,
cambios, riesgos, soluciones...) el Backlog único ha evolucionado a Backlog de producto y
Backlog de Sprint. También es habitual usar un backlog estratégico o "Epics" de producto.
La evolución añadió a la reunión de revisión de sprint, otra de inicio; y más tarde otra de
retrospectiva. Tampoco se suele usar la fase de cierre, etc.
También las prácticas se han enriquecido. En 2001 apareció el gráfico burndown(diagrama
de quemado), más tarde empezó a ser habitual el uso de estimación de póquer, luego tableros
de control visual kanban.
Para tener una visión de retrospectiva, este es el "paper" de Ken Schwber presentado en 1995
su implementación de Scrum en OOPSLA: "SCRUM Development Process " y este otro su
artículo del mismo año "Living on the Edge" en el que describía su implementación de Scrum
para Software.
TECNOLOGICO DE COLIMA 26
3.1.2 Fases de SCRUM
3.1.2.1 Pre-juego
Planificación: Definición de una nueva versión basada en la pila actual, junto con una
estimación de coste y agenda. Si se trata de un nuevo sistema, esta fase abarca tanto la visión
como el análisis. Si se trata de la mejora de un sistema existente comprende un análisis de
alcance más limitado. Arquitectura: Diseño de la implementación de las funcionalidades de
la pila. Esta fase incluye la modificación de la arquitectura y diseño generales.
3.1.2.2 Juego
Desarrollo de sprints(periodos de tiempo): Desarrollo de la funcionalidad de la nueva versión
con respeto continúo a las variables de tiempo, requisitos, costo y competencia. La
interacción con estas variables define el final de esta fase. El sistema va evolucionando a
través de múltiples iteraciones de desarrollo o sprints.
3.1.2.3 Post-juego
Preparación para el lanzamiento de la versión, incluyendo la documentación final y pruebas
antes del lanzamiento de la versión.
3.1.3 Pasos de cada fase
3.1.3.1 Pasos de la planificación
Desarrollo de un backlog completo.
Determinación de la fecha de entrega y la funcionalidad de una o más versiones.
Selección de la versión más adecuada para desarrollo inmediato.
TECNOLOGICO DE COLIMA 27
Trazado de los “paquetes del producto” (objetos) sobre los elementos del backlog de
la versión elegida.
Selección del equipo o equipos para desarrollar la nueva versión.
Evaluación y control adecuado de los riesgos.
Estimación del coste de la versión, incluyendo desarrollo, material, marketing,
formación y despliegue.
Conformidad de la dirección y financiación del proyecto.
3.1.3.2 Pasos de diseño y arquitectura
Revisión de los elementos del Backlog (libro de registros) incluidos en la versión.
Identificación de los cambios necesarios para implementar el backlog.
Análisis del dominio para incluir los requisitos que incluye el desarrollo mejora o
actualización.
Acotar la arquitectura del sistema para apoyar el nuevo contexto y necesidades.
Identificar problemas del desarrollo o modificaciones.
Reunión de revisión de diseño. Cada equipo presenta los cambios para implementar
los elementos del backlog, e identificar posibles reasignaciones.
3.1.3.3 Pasos del desarrollo (Sprint)
La fase de desarrollo es un ciclo de trabajo repetitivo. La gestión determina el cumplimiento
de los tiempos, funcionalidad y calidad. Este enfoque es conocido también como ingeniería
concurrente.
3.1.3.3.1 El desarrollo consiste en los siguientes macro-procesos:
Reunión con los equipos para revisar los planes de lanzamiento de versión.
Distribución, revisión y ajuste de los estándares de conformidad para el producto.
Sprints iterativos hasta que el producto se considera listo para su distribución.
Un sprint es un conjunto de actividades de desarrollo llevado a cabo durante un periodo
predefinido, por lo general entre una y cuatro semanas. Duración basada en la complejidad
del producto, evaluación de riesgos y grado de supervisión deseado. El tiempo determinado
para el sprint establece su velocidad e intensidad. El riesgo se evalúa de forma continua a
través de las respuestas a los controles adecuados establecidos.
TECNOLOGICO DE COLIMA 28
3.1.3.3.2 Cada sprint consiste en uno o varios equipos realizando:
Desarrollo: Definición de los cambios necesarios para la implementación de los
requisitos del backlog en módulos, la apertura de los módulos, análisis del dominio,
diseño, desarrollo, implementación, pruebas y documentación de los cambios. El
Desarrollo consiste en el micro proceso de descubrimiento, invención e
implementación.
Envoltura: Cierre de los módulos, creación de una versión ejecutable con los
cambios que implementas los requisitos del backlog.
Revisión: Reunión de todos los equipos para presentar el trabajo y revisar el progreso,
identificando y resolviendo posibles cuestiones y añadiendo nuevos elementos al
backlog. Se revisan los riesgos y las respuestas apropiadas.
Ajuste: Consolidación de la información de la revisión de los módulos afectados.
3.1.3.3.3.- Cada sprint es seguido de una revisión cuyas características son:
Está presente y participa el equipo al completo.
La revisión puede incluir a clientes, personal de ventas y otros.
La revisión cubre los sistemas funcionales y ejecutables abarcados por el equipo e
incluye los cambios que se han realizado para implementar los elementos del backlog.
En la revisión se pueden evidenciar cambios en la forma en la que se han
implementado los elementos del backlog.
La revisión también puede introducir elementos nuevos en el backlog, cambiando de
esta forma los contenidos y dirección de las versiones previstas.
Se determina la fecha de la siguiente revisión en base al progreso y complejidad. La
duración normal de los sprints es de 1 a 4 semanas.
3.1.4 Cierre
Cuando el equipo de gestión siente que las variables de tiempo, parte completada, requisitos,
coste y calidad están alineadas para producir una nueva versión, declaran cerrada la versión,
dando paso a esta fase. En esta fase se prepara el producto generado para producir una nueva
versión. Entre las tareas de cierre se encuentran: integración, pruebas del sistema,
documentación de usuario, preparación del material de formación y marketing.
TECNOLOGICO DE COLIMA 29
3.1.5 Controles de SCRUM
Al trabajar bordeando el caos (complejidad e imprevisibilidad) se requiere la gestión de
controles que eviten la caída en el caos.
La metodología SCRUM incorpora estos controles generales para evitar la pérdida de
control, utilizando las técnicas de Orientación a Objetos para la construcción de las entregas.
El principal control es el del riesgo. La gestión de riesgos da lugar a cambios en los controles
y respuestas del equipo.
3.1.5.1 Los controles de la metodología SCRUM Son:
Backlog: Requisitos que el producto en su versión actual no gestiona de forma
adecuada. Errores, defectos, peticiones del cliente, incorporación de mejoras
competitivas o tecnológicas son elementos del backlog. Los elementos del backlog
que comprenden una nueva versión comprenden variables de fechas, calidad y
funcionalidad viables.
Paquetes: componentes del producto que deben cambiarse para implementar la
nueva versión.
Cambios: cambios que deben producirse en un paquete para implementar una nueva
versión.
Problemas: problemas técnicos presentes que deben resolverse para implementar un
cambio.
Riesgos: Para lograr el éxito del proyecto se revisan de forma continua los riesgos y
las respuestas previstas. La gestión de riesgos afecta a otros controles.
Soluciones: respuestas a problemas y riesgos, que suelen ser cambios.
Temas: Cuestiones generales del proyecto que no se definen en términos de paquetes.
Estos controles se emplean en diversas fases de SCRUM. La dirección los emplea para
gestionar el backlog. Los equipos los usan para gestionar cambios y problemas. Ambos,
dirección y equipos, gestionan los temas, riesgos y soluciones. Estos controles son revisados,
modificados y consolidados en la revisión de cada Sprint. (Scrum Manager, 2013)
3.2 Planificación
TECNOLOGICO DE COLIMA 30
En Este apartado se realizan los pasos necesarios para la elaboración correcta del sistema, en
primer punto se muestra el análisis ya que este es uno de los más importantes para el
desarrollo del proyecto informático. Se recopila los datos necesarios que el cliente y los
usuarios finales requieren para el sistema, en el siguiente punto se muestra el diseño técnico,
tal como la programación, en esta parte se detalla la parte técnica del sistema, y el resultado
final. Por último se realiza las pruebas necesarias para el buen funcionamiento del sistema.
3.2.1 Requerimientos del usuario
3.2.1.1 Funcionales
El sistema debe:
Obtener y filtrar datos de los de programadores y diseñadores que se encuentran en la
plataforma Bamboo (plataforma que administra la información de empleados de
diferentes empresas).
Interfaz de empleado (Búsquedas, asignar tiempo para cada proyectos, Indicación de
colores por tiempo de asignación).
Reporte de trabajos asignados por empleado y por fechas.
Graficar tiempos por horas de trabajo, por programador (Opción Chart). Indicas lo
respecto a la utilización con respecto a la asignación. Si, cumpliendo lo planeado con lo
real trabajado. Por día, por proyecto, por mes.
Estimaciones del tiempo que se invertirá para desarrollar un proyecto de acuerdo al
avance con la metodología SCRUM.
3.2.1.2 No funcionales
El sistema debe:
De visualizarse y funcionar correctamente en cualquier navegador.
De visualizarse y funcionar correctamente en cualquier sistema operativo.
Ser programado en Ruby on Rails.
3.3 Diseño
3.3.1 Diagramas de casos de usos
TECNOLOGICO DE COLIMA 31
Los diagramas de uso muestran el comportamiento del sistema, el alcance d y las
interacciones con entidades externas. A continuación se muestra primero el diagrama para el
módulo del almacén y después del módulo del centro de cómputo.
3.3.1.1 Modulo de Asignación vs Utilización de Proyectos
Ilustración 6. Modelo de casos de uso del módulo de asignación vs utilización.
En la ilustración 6 se muestra el modelo de casos de asignación de proyectos.
A continuación se describen cada uno de los casos de uso:
3.3.1.1.1 Caso de uso Asignar proyectos (ilustración 6, caso de uso 1)
3.3.1.1.1.1 Funcionalidad: El propósito de este caso de uso es asignar a los desarrolladores,
diseñadores o el tester a un proyecto.
3.3.1.1.1.2 Actores: Administrador
3.3.1.1.1.3 Pre-condición: El desarrollador, diseñador o tester debe de tener tiempo libre
para ser asignado.
TECNOLOGICO DE COLIMA 32
3.3.1.1.1.4 Flujo principal:
1. El caso de uso inicia cuando el administrador se loguea al sistema.
2. El administrador visualiza a través de los colores quien está libre para ser asignado.
3. El administrador le indica al sistema a quien va a asignar.
4. El administrador ingresa el nombre del proyecto al que se va a asignar.
5. El administrador indica las horas que será asignado y en que fechas.
3.3.1.1.1.5 Flujos alternos:
Identificar si el programador, diseñador o tester no está asignado:
1. El sistema consulta e identifica si el programador, diseñador o tester ya
fue asignado.
2. El flujo de eventos continúa en el paso 2 del flujo principal.
3.3.1.1.1.6 Flujos excepcionales:
Cancelar registro de la asignación:
1. En cualquier momento, el administrador le puede indicar al sistema que desea
cancelar la asignación en curso.
2. El caso de uso termina con la cancelación del proceso de asignación.
3.3.1.1.1.7 Post-condición: La asignación queda guardada en la base de datos.
3.3.1.1.2 Caso de uso Consultar Asignación (ilustración 6, caso de uso 2)
3.3.1.1.2.1.- Funcionalidad: Su funcionalidad es consultar todos los desarrolladores,
diseñadores y tester que se encuentran asignados a un proyecto.
3.3.1.1.2.2.- Actores: Administrador
3.3.1.1.2.3.- Pre-condición: Las asignaciones deben de estar registradas en la base de datos
3.3.1.1.2.4.- Flujo principal:
1. El caso de uso inicia cuando el administrador entra al sistema y visualiza a través de
los colores la asignación del personal.
2. El caso de uso termina cuando el administrador consulta otra sección.
TECNOLOGICO DE COLIMA 33
3.3.1.1.2.5.- Post-condición: Se muestran todos los usuarios que se han registrado en la base
de datos.
3.3.1.1.3 Caso de uso Editar Asignación (ilustración 6, caso de uso 3)
3.3.1.1.3.1.- Funcionalidad: Tiene como propósito editar las asignaciones existentes por
cada usuario.
3.3.1.1.3.2.- Actores: Administrador.
3.3.1.1.3.3.- Pre-condición: El usuario debe de tener dado de alta al menos una asignación.
3.3.1.1.3.4.- Flujo principal:
1. El administrador debe seleccionar que asignación va a editar.
2. El administrador cambia los datos que desee.
3. El administrador guarda las actualizaciones.
3.3.1.1.3.5.- Post-condición: Queda registrado en la base de datos la actualización de la
asignación.
3.3.1.1.3.6.- Flujos alternos:
1. El administrador borra la asignación
3.3.1.1.3.7.- Flujos excepcionales:
Cancelar edición de la asignación:
1. En cualquier momento, el administrador le puede indicar al sistema que desea
cancelar el proceso.
2. El caso de uso termina con su cancelación.
3.3.1.1.4 Caso de uso Visualizar la Utilización vs Asignación (ilustración 6, caso de uso
5)
3.3.1.1.4.1.- Funcionalidad: Tiene como propósito visualizar las asignaciones vs
asignaciones existentes por cada usuario.
3.3.1.1.4.2.- Actores: Administrador.
3.3.1.1.4.3.- Pre-condición: Los usuarios deben tener asignaciones registradas en la base de
datos.
TECNOLOGICO DE COLIMA 34
3.3.1.1.4.4.- Flujo principal:
1. El caso de uso inicia cuando el usuario observa a través del chart la asignación de los
desarrolladores, diseñadores y tester.
2. El sistema le muestra cual es la utilización por día, semana y mes.
3.3.1.1.4.5.- Flujos alternos:
Verificar la demostración del chart por día, semana o mes.
3.3.1.1.4.6.- Flujos excepcionales:
Salir del chart.
3.3.1.1.4.7.- Post-condición: La asignación se muestra a través de javascript del usuario.
3.3.1.1.5 Caso de uso Eliminar Asignación (ilustración 6, caso de uso 4)
3.3.1.1.5.1.- Funcionalidad: Tiene como propósito eliminar las asignaciones existentes por
cada usuario.
3.3.1.1.5.2.- Actores: Administrador.
3.3.1.1.5.3.- Pre-condición: Los usuarios deben tener asignaciones registradas en la base de
datos.
3.3.1.1.5.4.- Flujo principal:
1. El caso de uso inicia cuando el usuario selecciona a un usuario.
2. El sistema le muestra cuáles son sus asignaciones.
3.3.1.1.5.5.- Flujos alternos:
Editar la asignación.
3.3.1.1.5.6.- Flujos excepcionales:
Salir del proceso de eliminación de la asignación.
3.3.1.1.5.7.- Post-condición: La asignación eliminada se muestra a través de javascript del
usuario en el apartado de asignaciones eliminadas.
3.3.1.2 Modulo para la Administración de Súper Usuarios del Sistema
TECNOLOGICO DE COLIMA 35
Ilustración 7 Modelo de casos de uso del módulo de administradores
En la ilustración 7 se muestra el modelo de casos para la administración de súper usuarios
A continuación se describen cada uno de los casos de uso:
3.3.1.2.1 Caso de uso Agregar un Nuevo Administrador (ilustración 1, caso de uso 1)
3.3.1.2.1.1 Funcionalidad: El propósito de este caso de uso es agregar un nuevo
administrador al sistema.
3.3.1.2.1.2 Actores: Administrador
3.3.1.2.1.3 Pre-condición: El administrador debe dar de alta a usuarios que tengan correo de
Magma Labs.
3.3.1.2.1.4 Flujo principal:
1. El caso de uso inicia cuando el administrador ingresa al módulo de administradores
del sistema.
2. El administrador agrega al usuario deseado.
TECNOLOGICO DE COLIMA 36
3.3.1.2.1.5 Flujos alternos:
Identificar si el usuario tiene correo de Magma Labs:
3.3.1.2.1.6 Flujos excepcionales:
Cancelar registro de un nuevo administrador:
1.- El caso de uso termina con la cancelación del proceso de agregación de un nuevo
administrador.
3.3.1.2.1.7 Post-condición: El registro queda guardado en la base de datos.
3.3.1.2.2 Caso de uso Revocar un Administrador (ilustración 7, caso de uso 3)
3.3.1.2.2.1 Funcionalidad: El propósito de este caso de uso es eliminar un administrador del
sistema.
3.3.1.2.2.2 Actores: Administrador
3.3.1.2.2.3 Pre-condición: El administrador debe elegir al administrador que va a eliminar.
Flujo principal:
1 El caso de uso inicia cuando el usuario ingresa al módulo de administradores del
sistema.
2 El usuario selecciona al administrador deseado.
3.3.1.2.2.5 Flujos alternos:
Ninguno
3.3.1.2.2.6 Flujos excepcionales:
Cancelar la revocación de un administrador:
1.- El caso de uso termina con la cancelación del proceso de eliminación de un
administrador registrado.
3.3.1.2.2.7 Post-condición: El registro se remueve de la base de datos.
3.3.2. Modelo conceptual
El modelo conceptual, como se muestra en la ilustración 8, nos permite mostrar los conceptos
más relevantes del problema, el cual nos va a servir de base para poder desarrollar el modelo
entidad-relación.
TECNOLOGICO DE COLIMA 37
Ilustración 8 Modelo conceptual
En la ilustración 8 Se muestra el modelo conceptual del sistema Demeter.
3.3.3. Diagrama Entidad-Relación
Para la creación del sistema se necesita una Base de Datos para la inserción de información,
por lo que se generó un diagrama de Entidad –Relación como se muestra en la ilustración 9.
En la ilustración 9 se muestra el diagrama entidad-relación del sistema Demeter.
3.4 Desarrollo
El diseño de la interfaz se hizo en base a los mockups (plantilla) proporcionados por los
diseñadores, para lograr la parte del front-end se utilizó el lenguaje de marcado ligero HAML
y para la parte del backend el framework Ruby on Rails del lenguaje Ruby.
3.4.1. Módulo del Asignación vs Utilización
3.4.1.1 Vista de inicio de sesión
Ilustración 10 Inicio de sesión
En la ilustración 10 se muestra el inicio de sesión a la aplicación Demeter, la cual tiene un
botón para (loguearte) a través de omniauth el cual es un multi-provedor de autenticación a
través de aplicaciones web, para poder utilizarlo se instaló la gema de omniauth.
TECNOLOGICO DE COLIMA 40
Ilustración 11 Omniauth
En esta ilustración 11 se muestra cuando omniauth pide acceso para conectarse a través de
la cuenta de Gmail con dominio de Magma Labs.
3.4.1.2 Vista principal de los empleados a los cuales se les puede asignar proyectos
Ilustración 12 Empleados a los que se les puede asignar a un proyecto
En la ilustración 12 se muestra la vista de todos los programadores, tester y diseñadores que
pueden ser asignados a un proyecto.
TECNOLOGICO DE COLIMA 41
La lista de los empleados que se muestran en la ilustración, fue extraída del api de bambooh,
la cual es una aplicación para llevar la administración del personal de empresas, en este caso
Magma Labs cuenta con el servicio.
Ilustración 13 Filtro de información
En la vista principal, también se puede observar un recuadro que te permite filtrar los datos
de los empleados que desee el administrador, se puede observar las siguientes opciones en la
ilustración 13:
Foto
Nombre
Apellido
Carga actual
Asignación
Ilustración 14 Opciones principales
La aplicación muestra un menú con las opciones principales las cuales se muestran en la parte
superior de la vista principal, a continuación la ilustración 14 muestra aquellas opciones con
las que cuenta el administrador.
TECNOLOGICO DE COLIMA 42
Ilustración 15 Asignación por color, gama de colores
La ilustración 15 muestra la gama de colores para cuando se le asigne horas en un proyecto
a un ingeniero, este se tornará de un color especifico dependiendo de la carga de trabajo.
Ilustración 16 Botón de asignación
La ilustración 16 se muestra cual es el botón que dispara el proceso para la asignación del
ingeniero a un determinado proyecto.
Ilustración 17 Búsqueda
En la siguiente ilustración 17 se muestra el texbox que funciona como un buscador de
empleados, esto para agilizar la búsqueda.
TECNOLOGICO DE COLIMA 43
3.4.1.3 Asignación de Proyectos
Ilustración 18 Vista de asignación de proyectos
En la vista de asignación ilustración 18 de proyectos para un empleado específico se puede
observar las siguientes funcionalidades y campos:
Asignaciones eliminadas
Nueva asignación
Edición de una asignación
Fecha inicial de la asignación
Fecha de terminación de la asignación
Cliente
Proyecto
Horas diarias designadas
TECNOLOGICO DE COLIMA 44
Ilustración 19 Edición de asignación de proyecto
En la ilustración 19 se muestra la vista para la edición de una asignación
Ilustración 20 Eliminación de asignación de proyecto
En la ilustración 20 se muestra la vista para ver el historial de las asignaciones eliminadas,
esto para que el administrador lleve el seguimiento de lo que ha pasado con ese determinado
ingeniero.
Ilustración 21 Vista para una nueva asignación
TECNOLOGICO DE COLIMA 45
En la ilustración 21 se muestra la vista para dar de alta una asignación, los campos que se
requieren llenar son las fechas que durará la asignación, el cliente, el proyecto y las horas
diarias que se trabajará en ello.
Ilustración 22 Selección del proyecto
En la ilustración 22 se muestra los datos de los clientes que se encuentran dados de alta en
la plataforma de harvest, los cuales se obtienen de su api.
TECNOLOGICO DE COLIMA 46
3.4.1.4 Vista Principal del Chart
Ilustración 23 Vista del Chart
En esta vista de la ilustración 23 se muestra el chart, el cual gráfica con triángulos las
asignaciones de cada ingeniero, los triángulos verdes representa la asignación diaria y los
rojos la utilización diaria.
Ilustración 24 Funcionalidades y filtraciones del Chart
En la ilustración 24 se muestra la funcionalidad del chart, y se puede observar que cuenta con
filtros para mostrar la gráfica por día, semana y mes, así como mostrar ya sea por empleado
o por proyecto.
TECNOLOGICO DE COLIMA 47
Ilustración 25 Vista de la utilización vs asignación
En esta vista 25 se muestra la utilización como funcionalidad seleccionada, en la cual se
muestra la utilización vs asignación, los datos mostrados se extrajeron de la api de harvest.
Ilustración 26 Vista del forecast
En ilustración anterior núm. 26 se muestra el pronóstico de la asignación vs utilización y se
muestra que el triángulo está hacia arriba, lo cual indica que va en picada, ya que no se ha
laborado nada de lo asignado.
TECNOLOGICO DE COLIMA 48
3.4.1.5 Vista Para los Reportes
Ilustración 27 Vista para los reportes
En la ilustración 27 se muestra la vista para generar los reportes, existe la posibilidad de
indicar si el reporte se desea por empleado o por proyecto, al igual las fechas de las cuales se
quiere obtener información.
3.4.1.6 Formato de los Reportes
Ilustración 28 Reporte por empleado
TECNOLOGICO DE COLIMA 49
Ilustración 29 Reporte por proyecto
En la ilustración 28 se muestra el reporte generado por empleado, el reporte muestra
información como el nombre del cliente, el nombre del proyecto, departamento, ya sea QA
o desarrollo, las fechas de inicio y terminación de asignación en el proyecto, las horas
asignadas y las trabajadas, en el caso de la ilustración 29 se muestra la información agrupada
por proyecto y con los mismos datos que en la ilustración 28.
3.4.1.7 Sign Out
. Ilustración 30 Botón de salida de sesión
En la ilustración 30 se muestra el botón de salida de la aplicación.
3.5 Implementación El sistema Demeter se instalará en un servidor de paga el cual se llama Heroku, se escogió
este porque la empresa tiene una cuenta con este proveedor de hosting para las aplicaciones
que se desarrollan en Magma Labs.
TECNOLOGICO DE COLIMA 50
3.6 Pruebas Las pruebas realizadas en el sistema fueron pruebas unitarias, las cuales se implementan en
el desarrollo de la aplicación y al igual son programadas para probar pequeñas partes de
código, así mismo la aplicación pasó por el área de QA, donde se hicieron todas las
revisiones pertinentes por el tester de esa área.
Ilustración 31 Pruebas Unitarias
En la ilustración 31 se muestra un ejemplo de las pruebas unitarias que contiene el sistema
Demeter.
TECNOLOGICO DE COLIMA 52
4.1 Cumplimiento de los Objetivos
Se ha desarrollado el sistema Demeter, está aplicación web es para llevar el control de las
asignaciones de los proyectos de Magma Labs, en el cual se puede medir la utilización con
respecto a la asignación. El objetivo principal se logró satisfactoriamente.
Los objetivos específicos al igual que el principal se concretaron satisfactoriamente teniendo
un diseño llamativo e interesante para el usuario en cuanto a contenido y calidad, así mismo
tener una app de calidad para ser ejecutada y presentada al personal indicado; a continuación
se mencionan los objetivos específicos logrados:
Se analizaron los requerimientos del sistema.
Se diseñó un sistema atractivo, llamativo e interesante para el usuario en cuanto a su
contenido y calidad.
Se codificó el código necesario para obtener un software de calidad
Se realizaron pruebas unitarias para probar la funcionalidad del sistema
La app fue satisfactoriamente ejecutada y presentada ante al personal de la empresa
Magma Labs con una previa verificación y evaluación de su funcionamiento.
4.2 Trabajos Futuros Dado a que este sistema web desarrollado en Ruby on Rails, Java script, HTML y Postgres,
tiene un amplio entorno de desarrollo y portabilidad aceptable en el mercado.
La creación de este sistema ayuda a esta empresa a llevar el control de las asignaciones de
los proyectos puestos en marcha en la compañía, la cual puede ser aplicada en otras empresas
que se dediquen al desarrollo de aplicaciones web o aquellas que manejen proyectos con sus
respectivos clientes.
TECNOLOGICO DE COLIMA 53
4.3 Conclusión El haber concluido satisfactoriamente está aplicación me permitió adquirir un amplio
aprendizaje en las tecnologías ya antes mencionadas, además de que la aplicación tendrá un
impacto satisfactorio en la empresa, ya que con esta aplicación será más fácil saber cuál es
la productividad de la empresa.
En detalle me permito obtener conocimientos en:
Desarrollo de aplicaciones web con el framework Ruby on Rails
Manejo de Apis
o Harvest
o Bambooh
Manejo de herramientas para el desarrollo del front-end
o Html
o Css
o Javascript
o Ajax
o Jquery
Manejo de tecnologías para el desarrollo del back-end
o Ruby
o Active Record
o Jobs, tareas programadas en background
o Manejo de gemas
Pruebas Unitarias
Desarrollo orientado a objetos
TECNOLOGICO DE COLIMA 54
Referencias
Abad, J. (Abril de 2005). Tipos de prueba de software. Obtenido de http://ing-sw.blogspot.mx/2005/04/tipos-de-pruebas-de-software.html
Amaya, Y. (2013). Metodologías ágiles en el desarrollo de aplicaciones. Amaya, Y. (23 de Julio de 2013). Metodologías ágiles en el desarrollo de aplicaciones para
el desarrollo móvil. Obtenido de http://www.uelbosque.edu.co/sites/default/files/publicaciones/revistas/revista_tecnologia/volumen12_numero2/12Articulo_Rev-Tec-Num-2.pdf
AstrovicApp. (31 de Marzo de 2015). Play Store. Obtenido de https://play.google.com/store/apps/details?id=com.astrovicapp.bigdays
Blanco, P., Camarero, J., Fumero, A., Werterski, A., & Rodríguez, P. (2009). Metodología de desarrollo ágil para sistemas móviles. Universidad Politécnica de Madrid.
Estrategias de Prueba del Software. (s.f.). Obtenido de https://www.google.com.mx/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0ahUKEwjXhpbWmsPJAhVEOSYKHQcDAVEQFgghMAE&url=https%3A%2F%2Fkesquivel.files.wordpress.com%2F2009%2F08%2Ftema15_estrategiaspruebasw.ppt&usg=AFQjCNFIb9JjwNYWOh95RyhaVpJ_AmYgvQ&sig2=PCKWCf
freshbooks.com. (2016). Small Business Accounting Software Designed for You. Obtenido de https://www.freshbooks.com/
Fuentes, V. (Diciembre de 2012). Aseguramiento de la Calidad del Software. Obtenido de http://dankocs2012.blogspot.mx/2012/12/aseguramiento-de-la-calidad-de-software.html
Google Inc. (2015 de Septiembre de 2015). Play Store. Obtenido de https://play.google.com/store/apps/details?id=com.google.android.talk
google play. (2016). Timesheet- Time Tracker. Obtenido de https://play.google.com/store/apps/details?id=com.rauscha.apps.timesheet
Guía Digital beta. (s.f.). Pruebas de Carga. Obtenido de http://www.guiadigital.gob.cl/articulo/pruebas-de-carga
Harvest. (2016). Harvest. Obtenido de https://www.getharvest.com/ IBM. (22 de November de 2010). SCRUM como metodologís. Obtenido de
https://www.ibm.com/developerworks/community/wikis/home?lang=en#!/wiki/Rational+Team+Concert+for+Scrum+Projects/page/SCRUM+como+metodolog%C3%ADa
ISO. (2014). Iso.org. Obtenido de ISO 13482:2014 - Robots and robotic devices -- Safety requirements for personal care robots: http://www.iso.org/iso/catalogue_detail?csnumber=53820
ISO 25000. (2015). ISO 25000 Calidad del Producto de Software. Obtenido de http://iso25000.com/
Itunes. (2016). Time Master + Billing. Obtenido de https://itunes.apple.com/ca/app/time-master-billing/id310289408?mt=8
Jesus, C. (27 de Agosto de 2015). Play Store. Obtenido de https://play.google.com/store/apps/details?id=com.cea.eventos
TECNOLOGICO DE COLIMA 55
Maltez, C. (Octubre de 2013). Historia y Evolución del SmartPhone. Obtenido de http://smartphoneavancetecnologico.blogspot.mx/p/historia-y-evolucion-del-smartphone.html
Marco Teórico. (Marzo de 2011). Obtenido de http://findme1.blogspot.mx/2011/03/marco-teorico.html
Martínez, J. (11 de Junio de 2007). Curso de Microsoft Project 2003. Obtenido de https://www.uv.mx/universo/270/infgral/infgral11.htm
Mountaingoat Software. (2016). Scrum. Obtenido de https://www.mountaingoatsoftware.com/agile/scrum
Peña, R. (s.f.). Gestión de Proyecto. Obtenido de http://www.monografias.com/trabajos11/gepro/gepro.shtml
PlayerApps. (12 de Septiembre de 2015). Play Store. Obtenido de https://play.google.com/store/apps/details?id=com.playerapps.eventcalendar
proyectosagiles.org. (s.f.). Que es SCRUM. Obtenido de http://proyectosagiles.org/que-es-scrum/
Scrum Manager. (05 de Marzo de 2013). Obtenido de http://www.scrummanager.net/bok/index.php?title=Modelo_original_de_Scrum_para_desarrollo_de_software
Valerio, W. (11 de Junio de 2013). Trabajar en Equipo. Obtenido de http://www.eoi.es/blogs/mintecon/2013/06/11/trabajar-en-equipo/
WIKIMEDIA. (9 de Septiembre de 2015). Gestión de Proyectos. Obtenido de https://es.wikibooks.org/wiki/Gesti%C3%B3n_de_proyectos
WIKIPEDIA La enciclopedia libre. (09 de Noviembre de 2015). Análisis del Sistema. Obtenido de https://es.wikipedia.org/wiki/An%C3%A1lisis_de_sistemas
WIKIPEDIA la enciclopedia libre. (27 de Septiembre de 2015). Control de Versiones. Obtenido de https://es.wikipedia.org/wiki/Control_de_versiones
WIKIPEDIA la enciclopedia libre. (28 de Noviembre de 2015). Gestión de Proyectos. Obtenido de https://es.wikipedia.org/wiki/Gesti%C3%B3n_de_proyectos
WIKIPEDIA La enciclopedía libre. (Septiembre de 2015). Historia del Teléfono Móvil. Obtenido de https://es.wikipedia.org/wiki/Historia_del_tel%C3%A9fono_m%C3%B3vil
WIKIPEDIA La enciclopedia libre. (21 de Noviembre de 2015). Pruebas de Software. Obtenido de https://es.wikipedia.org/wiki/Pruebas_de_software
WIKIPEDIA la enciclopedia libre. (23 de Octubre de 2015). Pruebas Funcionales. Obtenido de https://es.wikipedia.org/wiki/Pruebas_funcionales
WIKIPEDIA La enciclopedia libre. (24 de Noviembre de 2015). Requisito (sistemas). Obtenido de https://es.wikipedia.org/wiki/Requisito_%28sistemas%29
Wikipedia la enciclopedia libre. (26 de Febrero de 2016). Scrum. Obtenido de https://es.wikipedia.org/wiki/Scrum