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 2

Formato de Terminación de Residencia


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.


Í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


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


Í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


CAPÍTULO I CONTEXTO

DEL PROYECTO


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.


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.


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


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.


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.


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


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.


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


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.


CAPÍTULO II

FUNDAMENTO TEÓRICO


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).


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)


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.


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.


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.


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).


CAPÍTULO III

PROCEDIMIENTO Y

DESCRIPCIÓN DE LAS

ACTIVIDADES


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.


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.


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.


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.


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


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


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.


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.


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.


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.3.- Pre-condición: Los usuarios deben tener asignaciones registradas en la base de

datos.



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.


Verificar la demostración del chart por día, semana o mes.


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.3.- Pre-condición: Los usuarios deben tener asignaciones registradas en la base de

datos.


1. El caso de uso inicia cuando el usuario selecciona a un usuario.

2. El sistema le muestra cuáles son sus asignaciones.


Editar la asignación.


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


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.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.



Identificar si el usuario tiene correo de Magma Labs:


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.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.


Ninguno


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.


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.


Ilustración 9 Diagrama Entidad-Relación

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.


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.


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.


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.


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


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


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.


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.


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.


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


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.


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.


CAPÍTULO IV

CONCLUSIONES


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.


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


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


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


Anexos

Formato de Presentación de Residencia


Formato de Aceptación de Residencia


Formato de Evaluación de Residencia

Villa de Álvarez, Col., junio de 2013 - ITColima

Documents

Transcript of Villa de Álvarez, Col., junio de 2013 - ITColima