Gestión de Tareas de Software

UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA
FACULTAD DE INGENIERÍA EN INFORMÁTICA Y SISTEMAS
INFORME DE PRÁCTICAS PRE PROFESIONALES
GESTIÓN DE TAREAS DE SOFTWARE EN LEAD WORKING

PARTNER SAC
Presentado por: Luis Alberto, Reyes Viera
Asesor: ING. Brian Cesar, Pando Soto
Periodo de Prácticas Pre Profesionales: 16/03/2017 – 16/09/2017
Lugar de las Prácticas Pre Profesionales: LEAD WORKING PARTNER SAC
TINGO MARIA - OCTUBRE 2017

DEDICATORIA
A Dios que me ha dado la vida y

fortaleza para terminar este
proyecto de investigación.
A mis padres, por su comprensión,

confianza y sus consejos para hacer
de mí una mejor persona.
A mis maestros y la Universidad

por los conocimientos que me
otorgaron.
AGRADECIMIENTOS
Mi más sincero agradecimiento:

A la UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA, quien me dio la oportunidad de
formarme profesionalmente.
A la FACULTAD DE INGENIERÍA INFORMÁTICA Y SISTEMAS (FIIS), que a través de sus

docentes contribuyeron en mi formación personal y profesional.
A la EMPRESA LEAD WORKING PARTNER (LWP) y al gerente Brian Cesar Pando Soto por
darme la oportunidad de poder desarrollar mis prácticas pre profesionales y de esa adquirir
nuevos conocimientos.
A mi asesor el Ing. Brian Cesar Pando Soto por brindarme todo el conocimiento necesario
para el desarrollo de la Practicas Pre Profesionales.
A mis compañeros de la Promoción 2010 y a otras promociones de la FIIS, por brindarme

su ayuda en momentos difíciles y sobre todo por haber compartido una gran amistad con
muchos de ellos.
RESUMEN
LWP S.A.C. es una empresa dedicada al desarrollo de software a nivel

nacional e internacional. Esta práctica pre profesional tiene por objetivo gestionar las
tareas de desarrollo y mantenimiento de los productos de software que está a cargo la
empresa. Las actividades desarrolladas se realizan tomando referencia el método Scrum
como marco de trabajo en donde se definen los Sprints, Daily Meeting, Sprint Retrospective,
Sprint Review.
En esta experiencia se logró monitorear 7 proyectos de software, de las

cuales 2 eran para mantenimiento y 5 eran para desarrollo, del que inicialmente no existía
un medio definido para la gestión de estas tareas. Además, se identifica la necesidad de
mejorar este proceso de gestión de tareas, por ello se desarrolla un complemento para
verificar los avances de cada proyecto, pero en tiempo real o en las fechas de Sprints sin
realizar informes manuales.
Se concluye que la gestión de tareas es importante en una empresa de

desarrollo de software, ya que permite verificar la productividad y la eficiencia de trabajo
del equipo para medir y mejorar en siguientes proyectos.
ÍNDICE GENERAL
RESUMEN ..........................................................................................................................6
INTRODUCCIÓN ............................................................................................................... 13
I. INFORMACIÓN GENERAL DE LA ORGANIZACIÓN ...................................................... 14
1.1. DESCRIPCIÓN DE LA ORGANIZACIÓN ..................................................................... 14
1.1.1. Nombre .......................................................................................................... 14
1.1.2. Reseña Histórica ............................................................................................. 14
1.1.3. Ubicación Geográfica...................................................................................... 14
1.1.4. Misión y Visión ............................................................................................... 15
1.1.4.1. Misión ......................................................................................................... 15
1.1.4.2. Visión .......................................................................................................... 15
1.1.5. ORGANIGRAMA ESTRUCTURAL ...................................................................... 15
II. MARCO TEÓRICO Y CONCEPTUAL............................................................................. 16
2.1. CONCEPTOS METODOLÓGICOS ............................................................................. 16
2.1.1. SCRUM ........................................................................................................... 16
2.1.1.1. Características del Scrum ............................................................................. 16
2.1.1.2. Roles Scrum ................................................................................................. 17
2.1.2. GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE .............................. 19
2.1.2.1. Proyecto Software ....................................................................................... 19
2.1.2.2. Necesidad de la Gestión del Proyecto Software ........................................... 20
2.1.2.3. Gestión del Proyecto Software .................................................................... 19
2.1.2.4. Actividades de la Gestión de Software ......................................................... 21
2.2. CONCEPTOS BÁSICOS ............................................................................................ 21
2.2.1. SOFTWARE ..................................................................................................... 21
2.2.2. KANBAN ......................................................................................................... 22
2.2.3. PLUGIN ........................................................................................................... 22
2.2.4. PROCESO ........................................................................................................ 23
2.2.5. TAREA ............................................................................................................ 23
2.2.6. REQUISITO...................................................................................................... 23
2.2.7. SPRINT (Iteración).......................................................................................... 24
2.2.8. PROCESO DE DESARROLLO ..................................Error! Bookmark not defined.
2.2.9. MILESTONE.................................................................................................... 24
III. ACTIVIDADES REALIZADAS ................................................................................. 25
3.1. PLANTEAMIENTO DEL PROBLEMA ......................................................................... 25
3.1.1. IDENTIFICACIÓN DEL PROBLEMA .................................................................... 25
3.2. JUSTIFICACIÓN ...................................................................................................... 25
3.3. CRONOGRAMA...................................................................................................... 25
3.4. OBJETIVOS ............................................................................................................ 26
3.4.1. OBJETIVO GENERAL ........................................................................................ 26
3.4.2. OBJETIVOS ESPECÍFICOS ................................................................................. 26
3.5. ESCENARIO DE TRABAJO ....................................................................................... 26
3.5.1. EQUIPO DE TRABAJO ...................................................................................... 26
3.6. PROCESOS DE SOFTWARE EN LEAD WORKING PARTNER SAC ................................ 27
3.6.1. EXPLORACIÓN DE PROYECTOS ACTUALES ....................................................... 27
3.6.2. EXPLORACIÓN Y CONOCIMIENTO DE PROCESOS ACTUALES ........................... 28
3.7. ACTUALIZACIÓN, MONITOREO Y EVALUACIÓN DE TAREAS EN LOS
PROYECTOS .................................................................................................................. 32
3.7.1. Creación y Asignación Tareas.......................................................................... 32
3.7.2. Actualización y monitoreo Tareas ................................................................... 34
3.7.3. Desempeño y avance de proyecto .................................................................. 36
3.8. MEJORA DEL SISTEMA DE REPORTES DE AVANCES DE PROYECTOS ................ 37
3.8.1. Alternativas de solución ................................................................................. 37
3.8.2. Análisis del Desarrollo de un Complemento ................................................... 38
3.8.3. Diseño del Plugin ............................................................................................ 40
3.8.4. Construcción del Plugin. ................................................................................. 41
3.8.5. Pruebas del Plugin .......................................................................................... 43
3.8.6. Informe de Desempeño usando el Plugin ....................................................... 44
3.9. Otras actividades ............................................................................................ 45
3.9.1. Pruebas funcionales del Camotracker ............................................................. 45
3.9.2. Cambio de idioma al sitio web de Camotracker .............................................. 49
3.9.3. Creación de video tutoriales de Camotracker ................................................. 50
CONCLUSIONES ............................................................................................................... 53
RECOMENDACIONES........................................................................................................ 54
BIBLIOGRAFIA .................................................................................................................. 55
ANEXOS ........................................................................................................................... 56
INDICE DE FIGURAS
Figura 1. Mapa de ubicación geográfica de LWP……………………………………………………………………………………….. 15
Figura 2. Organigrama estructural de LWP ………………………………………………………………………………………………. 15

Figura 3. Marco de trabajo Scrum …………………………………………………………………………………………………………... 16
Figura 4. Equipo Scrum e interacciones ………………………………………………………………………………………………… 17
Figura 5. Necesidad de la Gestión de Proyecto ……………………………………………………………………………………... 19
Figura 6. Cronograma de Actividades ........................................................................................................ 24
Figura 7. Hoja de cálculo Excel - Requisitos …………………………………………………………………………………………… 27
Figura 8. Plataforma Bitbucket – Tareas, asignación, sprint …………………………………………………………………... 28
Figura 9. Prototipo Balsamiq ………………………………………………………………………………………………………………… 29
Figura 10. Proceso de desarrollo de software en LWP ....……………………………………………………………………….. 30
Figura 11. Creación y asignación de Tarea ……………………………………………………………………………………………. 31
Figura 12. Proceso de creación de tareas en LWP…………………………………………………………………………………. 32
Figura 13. Plataforma Bitbucket – Tablero Kanban ………………………………………………………………………………. 32
Figura 14. Revisión de tareas en LWP……………………………………………………………………………………………………. 33
Figura 15. Revisión detallada de tareas con el cliente……………………………………………………………………………. 34
Figura 16. Proceso de revisión de tareas con el Cliente en LWP…………………………………………………………….. 34
Figura 17. Reunión mensual del proyecto - Simba…………………………………………………………………………………. 36
Figura 18. Arquitectura del Plugin……………………………….............................................................................. 39
Figura 19. Grafico por Sprint ...........................................................................................................………... 41
Figura 20. Pruebas del plugin .........................................................................................…………………………

42
Figura 21. Informe – Usando el plugin ...................................................................................................... 43
Figura 22. Ingreso con Documento Nacional de Identidad…………………………………………………………………….. 44
Figura 23. Ingreso con Clave para marcar entrada……………………………....................................................... 44
Figura 24. Ingreso con Wifi para marcar entrada…………………………………………………………………………………… 45
Figura 25. Ingreso mediante lectura de código de barra del Dni…………………………………………………………….. 45
Figura 26. Reporte mediante ingreso por Dni……………………………………….................................................... 46
Figura 27. Reporte mediante ingreso por clave……………………………………………………………………………………… 46
Figura 28. Reporte mediante ingreso por lectura de código de barra del Dni………………………………………... 47
Figura 29. Subir recibo de pago por horas trabajadas…………………………………………………………………………… 47
Figura 30. Pagina Camotracker – Idioma Castellano…………………………………………………………………………….... 48
Figura 31. Pagina Camotracker – Idioma Ingles……………………………………………………………………………………… 48
Figura 32. Creación de video – Documento Web…………………………………………………………………………………… 49
Figura 33. creación de video – Usuario / Clave ……………………………………………………………………………………… 49
Figura 34: creación de video – Wifi Android………………………………………………………………………………………….. 50
Figura 35: creación de video – Web Facial. …………………………………………………………………………………………… 50
Figura 36. creación de video – Código de barra……………………………………………………………………………………… 51
INDICE DE CUADROS
Cuadro 1. Equipo de trabajo ..............................…………………………………………………………………………………....... 25
Cuadro 2. Proyectos en LWP ……….......................…………………………………………………………………………………….. 27

Cuadro 3. Comparación de alternativas de solución …………………………………………………………………………….. 37
Cuadro 4. Requisito – Resumir tareas por sprint …....……………………………………………………………………….…… 37
Cuadro 5. Requisito – Generar grafico de BurnDown .................…………………………………………………………... 38

Cuadro 6. Requisito – Generar grafico de tareas resueltas ........................................................................ 38
Cuadro 7. Requisito no funcional – Acceso libre al plugin ................……………………………………………………… 38
Cuadro 8. Requisito no funcional – Usar JavaScript y JQuery ........………………………………………………………... 39
Cuadro 9. Requisito no funcional – Usar JqPlot …………………..................…………………………………………………39
Cuadro 10. Comparación entre Google Charts con JqPlot ....…………………………………………………………………..
40
INTRODUCCIÓN
El informe da a conocer el proceso de desarrollo de las actividades realizadas

de acuerdo con el plan general de Prácticas Pre Profesionales.
El Capítulo I: “Descripción de la Organización”, describe el contexto general

de la organización en la que se realizaron las Prácticas Pre Profesionales, en este caso de
LEAD WORKING PARTNER S.A.C. en el cual se mencionan su reseña histórica, ubicación
geográfica, visión, misión.
El Capítulo II: “Marco Teórico y Conceptual”, nos da a conocer el marco

teórico de los conceptos que se utilizaron y aplicaron para el desarrollo de las Prácticas Pre
Profesionales. También un marco metodológico basado en la metodología Scrum, gestión
de proyectos de desarrollo de Software.
El Capítulo III: “Actividades Desarrolladas”, en este capítulo se explicará de

manera detallada el desarrollo de las Prácticas Pre Profesionales. Para el desarrollo se
explicará de forma detallada los proyectos con los que cuenta la empresa LEAD WORKING
PARTNER S.A.C., así como la evaluación de las tareas de cada proyecto que cuenta la
empresa y finalizando con reportes de avance de cada proyecto, todos apoyado con el
marco de trabajo de la metodología Scrum.
Finalizando, se mencionan las conclusiones obtenidas al finalizar las

Prácticas pre profesionales y las recomendaciones necesarias a tener en cuenta para
mejorar la gestión de tareas.
13
I. INFORMACIÓN GENERAL DE LA ORGANIZACIÓN
1.1. DESCRIPCIÓN DE LA ORGANIZACIÓN
1.1.1. Nombre
LEAD WORKIN PARTNER SAC.

1.1.2. Reseña Histórica1
Se constituye como una agencia de desarrollo de sistemas web y

aplicaciones móviles, hace ya varios años venimos trabajando en consultoría web
construyendo y desarrollando aplicaciones web con tecnologías competentes en el
mercado informático tanto en software libre como licenciado, tales como .Net, Java, Php,
basados en marcos de referencia MVC (Modelo vista controlador), que hace que el
software sea un producto más liviano y productivo. Nuestra experiencia nos ha llevado a
desarrollar aplicaciones transaccionales y de inteligencia de negocios.
1.1.3. Ubicación Geográfica
La Empresa LEAD WORKING PARTNER SAC. se encuentra ubicada en:
• Departamento : Huánuco.
• Provincia : Leoncio Prado.
• Distrito : Rupa Rupa.
• Entidad : LEAD WORKING PARTNER SAC.
• Dirección : Jr. Arequipa 1085.
• Altitud : 109 m.s.n.m.
• Temperatura : Máx. 31°C – Mín. 13 °C.
1 [En línea]: Sitio Oficial de Lead Working Partner , (http://bidsoft.net/ , 2013).
14
Figura 1: Ubicación geográfica de LEAD WORKING PARTNER SAC.
Fuente: LEAD WORKING PARTNERT [En linea]: https://maps.google.com/
1.1.4. Misión y Visión2
1.1.4.1. Misión
Ser una empresa líder en desarrollo y mantenimiento de software con la

vanguardia de las últimas tecnologías, brindando al cliente productos más livianos.
1.1.4.2. Visión
Ser reconocidos por nuestro mercado, contar con productos maduros

(software) para ofertar en el mercado mundial.
1.1.5. ORGANIGRAMA ESTRUCTURAL
Figura 2: Organigrama estructural de LEAD WORKING PARTNER SAC.
Gerente General
Líder de Proyecto
Equipo de Proyecto 1 Equipo de Proyecto 2 Equipo de Proyecto ...
Fuente: Elaboración propia
2 [En línea]: Sitio Oficial de Lead Working Partner , (http://bidsoft.net/ , 2013).
15
II. MARCO TEÓRICO Y CONCEPTUAL
2.1. CONCEPTOS METODOLÓGICOS
2.1.1. SCRUM
Según (Schwaber y Sutherland, 2016) menciona que, Scrum es un marco

de trabajo que ha sido usado para gestionar el desarrollo de productos complejos desde
principios de los años 90. Scrum no es un proceso o una técnica para construir productos,
en lugar de eso, es un marco de trabajo dentro del cual se pueden emplear varios procesos
y técnicas
Figura 3: Marco de trabajo Scrum
Fuente: Marco de trabajo Scrum (Schwaber y Sutherland, 2016).
2.1.1.1. Características del Scrum
Según (Oliver Andrés, 2011) menciona que, Scrum da prioridad a los

individuos y las interacciones sobre los procesos y las tareas, lo cual significa que gran parte
del éxito del proyecto radica en la forma cómo el equipo se organice para trabajar. Se debe
tener una cohesión fuerte de equipo ya que el triunfo de un hito no es de un solo miembro
sino de todo el equipo Scrum, todos colaboran entre sí y ayudan a los integrantes que no
están a la par con el equipo
16
2.1.1.2. Roles Scrum
Según (Fernández & Cadelli, 2014) menciona que un equipo Scrum se espera
que intervengan tres roles: Product owner, Equipo de desarrollo y ScrumMaster
Figura 4: Equipo Scrum e interacciones.
Fuente: Proyectos agiles con Scrum (Alaimo, 2013)
• Product Owner
El Product owner se focaliza en maximizar la rentabilidad del producto. La

principal herramienta con la que cuenta para poder realizar esta tarea es
la priorización. El Product owner es la persona responsable del éxito del
producto desde el punto de vista de los stakeholders. Sus principales
responsabilidades son:
• Determinar la visión del producto, hacia dónde va el equipo de

desarrollo.
• Gestionar las expectativas de los stakeholders.
• Recolectar los requerimientos y determinar las características
funcionales de alto nivel y de bajo nivel, así como determinar
prioridades.
• Generar y mantener el plan de entregas (reléase plan).
• Cambiar las prioridades de las características según avanza el
proyecto, acompañando así los cambios en el negocio.
• Aceptar/rechazar el producto construido durante el Sprint y
proveer feedback valioso para su evolución.
17
• Participar de la revisión del Sprint junto a los miembros del
Equipo de Desarrollo para obtener feedback de los
stakeholders.
• Equipo de Desarrollo
Según (Alaimo, 2013) menciona que el equipo de desarrollo es auto-

organizado. Esto significa que no existe un líder externo que asigne las
tareas ni que determine la forma en la que serán resueltos los problemas.
Es el mismo equipo quien determina la forma en que realizará el trabajo y
como resolverá cada problemática que se presente. Es recomendable que
un equipo de desarrollo se componga de hasta 9 personas en lo cual tienen
que ser multi funcionalidad, en la que puedan colaborar con el equipo. El
equipo de desarrollo cuenta con 3 responsabilidades, la primera es proveer
las estimaciones en cuanto al esfuerzo requerido para el producto,
segundo es comprometerse a cumplir con el sprint y finalmente es
responsable por la entrega del producto terminado al finalizar cada sprint.
• ScrumMaster
Tomando algunas referencias de (Leonardo Wolk, 2003), podemos decir

que el ScrumMaster, en tanto que coach, es un líder, facilitador. Líder por
ser un ejemplo que seguir, facilitador por fomentar contextos de apertura
y discusión donde todos pueden expresar sus opiniones y lograr consensos
comunes.
Las responsabilidades principales del ScrumMaster son:
• Velar por el correcto empleo y evolución de Scrum.

• Facilitar el uso de Scrum a medida que avanza el tiempo. Esto
incluye la responsabilidad de que todos asistan a tiempo a las
daily meeting, review y retrospectivas.
• Asegurar que el equipo de desarrollo sea multi – funcional y
eficiente.
• Proteger al equipo de desarrollo de distracciones y trabas
externas al proyecto.
• Detectar, monitorear y facilitar la remoción de los
impedimentos que puedan surgir con respecto al proyecto y a
la metodología.
• Asegurar la cooperación y comunicación dentro del equipo.
18
2.1.2. GESTIÓN DE PROYECTOS DE DESARROLLO DE SOFTWARE
2.1.2.1. Proyecto Software
Según (Sommerville, 2011) menciona que, Un proyecto de Software es todo

el procedimiento del desarrollo de software, desde el recojo de requisitos, pasando por las
pruebas y el mantenimiento, y llevado a cabo en acorde a las metodologías de ejecución,
en un momento concreto en el tiempo para lograr el producto software deseado.
2.1.2.2. Gestión del Proyecto Software
Según (Sommerville, 2011) menciona que, La gestión de proyectos de

software es una parte esencial de la ingeniería de software. Los proyectos necesitan
administrarse porque la ingeniería de software profesional está sujeta siempre a
restricciones organizacionales de presupuesto y fecha. El trabajo del administrador del
proyecto es asegurarse de que el proyecto de software cumpla y supere las restricciones,
además de que entregue software de alta calidad. La buena gestión no puede garantizar el
éxito del proyecto. Sin embargo, la mala gestión, por lo general, da como resultado una
falla del proyecto: el software puede entregarse tarde, costar más de lo estimado original-
mente o no cumplir las expectativas de los clientes. La gestión de proyectos es un proceso
continuo. Este proceso requiere de una estrategia global, apoyada por herramientas de
trabajo que incrementen la productividad.
El director del proyecto sigue de cerca el proceso de desarrollo, prepara y

ejecuta planes, organiza los recursos adecuados y necesarios, se mantiene comunicado con
todos los miembros del equipo con tal de dirigir asuntos de costes, presupuesto, recursos,
tiempo, calidad y satisfacción del cliente.
Algunas responsabilidades que el director de un proyecto asume:
• Gestión de Personas
• Actuar como líder de proyecto.
• Intermediar con accionistas.
• Gestionar los recursos humanos.
• Armar informes de jerarquía.
• Gestión del Proyecto

• Definir y armar el alcance del proyecto.
• Gestionar las actividades de gestión del proyecto.
19
• Seguimiento de la actuación y del progreso.
• Análisis de riesgos en cada fase.
• Tomar la iniciativa para evitar o salir de problemas.
• Actuar como representante del proyecto.
2.1.2.3. Necesidad de la Gestión del Proyecto Software
Según (Sommerville, 2011) indica que, el software es un producto no

tangible. El desarrollo de software contiene aspectos de todas las corrientes del mundo de
los negocios, pero tiene poca experiencia en construir productos software. La mayor parte
de los productos software se diseñan para satisfacer las necesidades de los clientes.
Figura 5: Necesidad de la Gestión de Proyecto .
Fuente: ((Sommerville,
- 2011)
La Figura 5 muestra las limitaciones triples para los proyectos de software.

Es una parte esencial de la organización del software entregar un producto de calidad,
manteniendo el coste de las limitaciones del presupuesto del cliente y entregar el proyecto
a tiempo. Cada uno de los 3 factores puede causar un impacto en los otros dos de forma
grave. Por tanto, la gestión del proyecto software debe incorporar los requisitos del usuario
junto con el presupuesto y las limitaciones de temporales.
20
2.1.2.4. Actividades de la Gestión de Software
Según (Sommerville, 2011) indica que, La gestión del proyecto software

comprende un gran número de actividades, que contienen la planificación del proyecto,
decir el alcance del producto software, estimar el costo.
• Planificación del Proyecto
La planificación del proyecto de software es una tarea que se realiza antes

que la producción del software empiece. Está ahí para la producción de
software, pero no implica una actividad concreta que tenga una conexión
directa con la producción de software; más bien es un conjunto de
procesos, que facilitan la producción de software.
• Gestión del alcance
Definir el alcance de un proyecto incluye todas las actividades y procesos

que se requieren para crear un producto software distribuible. La gestión
del alcance es esencial porque crea condiciones del proyecto por medio de
la definición de lo que se debe realizar en el proyecto y lo que no. Esto hace
que el proyecto contenga tareas limitadas y cuantificables.
• Estimación del Proyecto
Para una gestión efectiva, es necesario que se realice una estimación

acurada de varias medidas. Los directores pueden gestionar y controlar el
proyecto de forma más eficiente y efectiva haciendo estimaciones
correctas, las estimaciones del proyecto pueden incluir los siguientes
aspectos (estimación del tamaño del software, estimación del esfuerzo,
estimación del tiempo y estimación del coste).
2.2. CONCEPTOS BÁSICOS
2.2.1. SOFTWARE
Según la Real Academia Española, Software es un conjunto de programas,

instrucciones y reglas informáticas para ejecutar ciertas tareas en una computadora.
Según (Sommerville, 2011) menciona que, Software es un programas de
cómputo y documentación asociada. Los productos de software se desarrollan para un
cliente en particular o para un mercado en general.
21
Asimismo (Sommerville, 2011) indica que; muchos suponen que el software
es tan sólo otra palabra para los programas de cómputo. No obstante, cuando se habla de
software, esto no sólo se refiere a los programas en sí, sino también a toda la
documentación asociada y los datos de configuración requeridos para hacer que estos
programas operen de manera correcta. Un sistema de software desarrollado
profesionalmente es usualmente más que un solo programa. El sistema por lo regular
consta de un número de programas separados y archivos de configuración que se usan para
instalar dichos programas. Puede incluir documentación del sistema, que describe la
estructura del sistema; documentación del usuario, que explica cómo usar el sistema, y los
sitios web para que los usuarios descarguen información reciente del producto.
Tomando en cuenta de los párrafos anteriores, se puede concluir que un

software no solo es un programa informático, sino que para su desarrollo incluye una serie
de actividades, tecnologías a configurar, metodologías a usar, personas que desarrollan,
documentación y entre otros, siendo esto una Ingeniería en la cual es denominada
Ingeniería de Software.
2.2.2. KANBAN
Según los conceptos en la página web oficial de Kanban Tool (Kanban Tool,
2009), donde textualmente menciona:
“Kanban es un sistema de visualización empleado en los procesos de
producción que coordinan en una cadena de montaje, la entrega a tiempo de cada parte
en el momento que se necesita, evitando sobreproducción y almacenamiento innecesario
de producto. El termino Kanban aplicado a la gestión ágil de proyectos se refiere a técnicas
de representación visual de información para mejorar la eficiencia en la ejecución de las
tareas”.
Podemos concluir en que Kanban es una solución para la gestión visual de
procesos que ayuda a los equipos a trabajar más eficientemente, visualizar el flujo de
trabajo, analizar y mejorar los procesos de trabajo en los proyectos de software.
2.2.3. PLUGIN
Podemos apreciar en los conceptos de la página web Enciclopedia Culturalia

(Enciclopedia Culturalia, 2013) , donde textualmente menciona:
“Plugin, que también puede mencionarse como plug-in, es una noción que Commented [L1]:
no forma parte del diccionario de la Real Academia Española (RAE). Se trata de un concepto
de la lengua inglesa que puede entenderse como “inserción” y que se emplea en el campo
de la informática. Un plugin es aquella aplicación que, en un programa informático, añade
una funcionalidad adicional o una nueva característica al software. En nuestro idioma, por
lo tanto, puede nombrarse al plugin como un complemento”.
22
Entonces podemos decir que es un complemento, lo habitual que es el
plugin sea ejecutado mediante el software principal, con el que interactúa a través de una
cierta interfaz.
2.2.4. PROCESO DE SOFTWARE
Existe una amplia información bibliográfica sobre la definición de ¿Qué es

un proceso? , pero hay una definición interesante que según (Bravo Carrasco, 2011) se
menciona:
“Proceso es un conjunto de actividades, interacciones y recursos con una
finalidad común: transformar las entradas en salidas que agreguen valor a los clientes. El
proceso realizado por personas organizadas según ciertas estructuras, tienen tecnología de
apoyo y manejan información; las entradas y salidas incluyen tránsito de información y
producto”
Por lo tanto teniendo en cuenta la definición anterior, un proceso de
software es una serie de actividades relacionadas que tienen por finalidad la fabricación o
elaboración de un producto de software. Reforzando el concepto de Proceso de Software,
según (Sommerville, 2011) menciona que, Los procesos de software real son secuencias
entrelazadas de actividades técnicas, colaborativas y administrativas con la meta general
de especificar, diseñar, implementar y probar un sistema de software.
2.2.5. TAREA
Según el diccionario de la Real Academia Española (RAE), una tarea es una

labor u ocupación; el término puede hacer referencia a aquello que una persona debe
realizar, lo que se realiza en un tiempo específico recibe la denominación de tarea.
Además (Sommerville, 2011) menciona que; en la Gestión de proyectos de

software, la labor del administrador de proyecto varia el enormemente en función a la
organización y el producto de software a desarrollar, siendo una de sus actividades
principales la planeación de proyecto, que consiste en la estimación y calendarización del
desarrollo de proyecto, así como la asignación de tareas a las personas. Supervisan el
trabajo para verificar que se realice de acuerdo con los estándares requeridos y
monitorizan el avance para comprobar que el desarrollo este a tiempo y dentro del
presupuesto.
Se puede concluir que la Gestión de tareas en los proyectos de desarrollo de
software es importante para asegurar el éxito del producto de software en el tiempo y
presupuesto asignado.
2.2.6. REQUERIMIENTOS
23
Según (Sommerville, 2011) menciona que; los Requerimientos para un
sistema son descripciones de lo que el sistema debe hacer: el servicio que ofrece y las
restricciones en su operación. Tales requerimientos reflejan las necesidades de los clientes
por un sistema que atienda cierto propósito, como sería controlar un dispositivo, colocar
un pedido o buscar información. Al proceso de descubrir, analizar, documentar y verificar
estos servicios y restricciones se le llama ingeniería de requerimientos (IR).
Tomando en cuenta el párrafo anterior, se puede concluir que es importante

comprender y gestionar la especificación y los requerimientos del software (lo que el
software debe hacer). Debe conocerse qué esperan de él los diferentes clientes y usuarios
del sistema, y gestionar sus expectativas, para entregar un sistema útil dentro de la fecha
y presupuesto.
2.2.7. SPRINT (Iteración)
Según (Rouse, 2015) menciona que; el Sprint es un período de tiempo

determinado durante el cual el trabajo específico debe completarse y prepararse para su
revisión. Cada Sprint comienza con una reunión de planificación. Durante la reunión, el
propietario del producto (la persona que solicita el trabajo) y el equipo de desarrollo
acuerdan exactamente qué trabajo se realizará durante el sprint. El equipo de desarrollo
tiene la última palabra cuando se trata de determinar cuánto trabajo se puede lograr de
manera realista durante el sprint, y el propietario del producto tiene la última palabra sobre
qué criterios deben cumplirse para que el trabajo sea aprobado y aceptado.
2.2.9. MILESTONE
Milestone es un término en ingles que traducido al español es “hito”.

Podemos apreciar en los conceptos de la página web del software SINNAPS (Sinnaps, 2015),
donde textualmente menciona:
“Los hitos son una serie de etapas dentro de un mismo proyecto. Se
determinan desde la planificación previa del mismo, se van revisando a medida que avanza
nuestro trabajo y se pueden ir modificando según las necesidades del proyecto o cliente.
Por eso decimos, que normalmente son partes indispensables en los proyectos que siguen
una metodología ágil, cuyo requisito principal es la flexibilidad de la herramienta, como es
el caso del desarrollo software”.
24
III. ACTIVIDADES REALIZADAS
3.1. PLANTEAMIENTO DEL PROBLEMA
3.1.1. IDENTIFICACIÓN DEL PROBLEMA
La empresa Lead Working Partner en la actualidad, es una empresa dedicada

al desarrollo y mantenimiento de software, la empresa cuenta con un equipo de desarrollo
para cada proyecto, donde cada integrante se hace cargo de sus tareas por sprint que les
son asignados al comienzo de cada proyecto, donde su forma de desarrollar optan por el
marco de trabajo que sugiere Scrum, ahí es donde encontramos el problema, el equipo de
desarrollo no cuenta con el tiempo para estar pendientes de las actualizaciones de sus
tareas, revisar su funcionalidad de estas tareas o los problemas que puedan estar pasando
en el equipo para un mejor desempeño.
3.2. JUSTIFICACIÓN
Gestionar las tareas de cada proyecto que cuenta la empresa Lead Working
Partner, en lo cual nos permita mejorar la entrega del producto el cliente, cumplir con el
cliente con el sprint dado al comienzo de cada proyecto, mejorar el desempeño del equipo
de desarrollo.
3.3. CRONOGRAMA
Figura 6: Cronograma de Actividades
Fuente: Elaboración Propia
25
3.4. OBJETIVOS
3.4.1. OBJETIVO GENERAL
¿Gestionar las tareas de desarrollo y mantenimiento de los proyectos de

Software de LWP SAC usando Bitbucket?
3.4.2. OBJETIVOS ESPECÍFICOS
1. Conocer los procesos actuales de la empresa Lead Working Partner.
2. Monitorear las tareas de los proyectos de software de la empresa Lead Working

Partner.
3. Mejorar los procesos actuales de la empresa desarrollando un plugin.
3.5. ESCENARIO DE TRABAJO
3.5.1. EQUIPO DE TRABAJO
Cuadro 1: Equipo de trabajo
NOMBRE CARGO EN EQUIPO

Ing. Brian Cesar, Pando Soto Gerente Analista-Programador
Samuel Ricardo, Pardo Desarrollador Analista-Programador
Mesias
Yelsin, Ramírez Lujan Desarrollador Analista-Programador
Carlos Clemente, Vásquez Practicante Analista-Programador
Cisneros
Paulo Adrián, Tijero Texeira Practicante Analista-Programador
Luis Alberto, Reyes Viera Practicante Administrador del Proyecto y Téster
26
3.6. PROCESOS DE SOFTWARE EN LEAD WORKING PARTNER SAC
3.6.1. EXPLORACIÓN DE PROYECTOS ACTUALES
Lead Working Partner es una empresa que se encarga de desarrollar

software, actualmente cuenta con 5 proyectos en construcción y 2 proyectos en
mantenimiento.
Cuadro 2: Proyectos en LWP
PROYECTO DESCRIPCION TECNOLOGIAS
Optimus Consiste en elaborar un CMS con Laravel • IDE: Eclipse Luna.
personalizado según las necesidades de la • Lenguaje: Php5.
empresa.
• Base de Datos: MySQL5.
• Framework: Laravel 5.4.
Silum Consiste en elaborar un CMS personalizado en • IDE: Visual Studio 2015.
.net conectado a Oracle. • Lenguaje: C# integrado con
angular.
• Base de Datos: Oracle.
• Framework: Modelo Vista
Controlador 5 (MVC)
Globalnet Consiste en el mantenimiento del sistema • IDE: Eclipse luna.
comercial de la empresa. • Lenguaje: Java.
• Base de Datos: MySQL.
• Framework: Symfony.
Qubank Consiste en una red social para la formulación y • IDE: Php Storn.
gestión de exámenes. • Lenguaje: Php
• Base de Datos: Sql
• Framework: Symfony
Simba Consiste en el mantenimiento de un sistema • IDE: Eclipse Luna.
comercial para pequeñas empresas. • Lenguaje: Java.
• Base de Datos: PostgreSQL.
• Framework: AngularJS.
Sisaplab Consiste en el mantenimiento de un sistema • IDE: Eclipse Luna.
para la gestión de resultado de un laboratorio • Lenguaje: Java EE.
clínico.
• Framework: Spring MVC.
Camotracker Consiste en el desarrollo de un proyecto para la • IDE: Eclipse Luna.
gestión de tiempo de los colaboradores de una • Lenguaje: Php.
organización.
Framework: Symfony 3.
27
3.6.2. EXPLORACIÓN Y CONOCIMIENTO DE PROCESOS ACTUALES
Para conocer los procesos actuales y como actúa internamente la empresa

Lead Working Partner al desarrollar sus servicios se llegó a realizar diálogos y entrevistas.
Mediante estos diálogos y entrevistas se conoció el patrón de desarrollo que realiza la
empresa en la construcción o desarrollo de un software, en lo cual inician listando los
requisitos por parte del cliente y escribirlo en una hoja de cálculo Excel.
El equipo del proyecto se encarga de realizar las actividades para su

desarrollo, en lo cual el equipo se enfoca a cumplir con las tareas que se les asignaban en
el plazo indicado, pero de una forma informal como en un Excel (ver figura 7) o el uso del
correo gmail, el problema es que no disponían de mucho tiempo para subir las tareas
constantemente.
Figura 7: Hoja de cálculo Excel – Requisitos
Fuente: Proyecto Simba
Una vez terminada la reunión y de haber listado los requisitos, se planifica

una reunión con el equipo del proyecto y se dan a conocer estos requisitos con sus
funcionalidades, se les asigna prioridades, fechas entregables o los sprints, en lo cual es
designado al desarrollador (ver figura 8) , en esta reunión también se absuelven todo tipo
de inquietudes o problemas que puedan existir en torno a los requisitos dados, una vez
asignado estos requisitos son pasados a un tablero Kanban sugerido por Scrum, utilizando
Team Foundation Service o el gestor de tareas de la plataforma Bitbucket, en algunos casos
estos requisitos pueden ser para nuevos proyectos o para mantenimiento.
28
Figura 8: Plataforma b itbucket – Tareas, asignación, sprint
“El gestor de tareas de la plataforma Bitbucket (denominada Issue Tracker),

permite crear y monitorear las tareas de un proyecto, en la figura 8 se observan las tareas
del proyecto Simba, cada tarea representa un requisito del cliente, en esta vista se ven las
tareas como una lista y se puede diferenciar a quien está asignada y la fecha de entrega”.
En algunos casos se construye los prototipos de los proyectos con

herramientas como Balsamiq (ver figura 9) u otras, dependiendo del tipo de proyecto, todo
esto se realiza con la finalidad de reducir el número de cambios durante la codificación.
29
Figura 9: Prototipo Balsamiq
Fuente: Proyecto Qubank
Después de haber desarrollado el prototipo, se realiza la configuración de la

infraestructura de desarrollo, es decir se evalúa con qué tipo de tecnología se realizará,
como el IDE, Base de datos, Framework o lo que se necesitará para el proyecto. Después se
realiza las actividades de codificación, pruebas, refactorización, entregas continuas de
avances.
Actualmente la empresa Lead Working Partner cuenta con un estilo propio

de construcción de aplicaciones con el cual trabaja el equipo de desarrolladores.
30
Figura 10: Proceso de desarrollo de software en LWP
30
3.7. ACTUALIZACIÓN, MONITOREO Y EVALUACIÓN DE TAREAS EN LOS PROYECTOS
El foco principal de estas prácticas es precisamente de esta actividad, ya que

actualmente la empresa Lead Working Partner no cuenta con alguien disponible para el
monitoreo de las actividades.
3.7.1. Creación y Asignación Tareas
Cuando los requisitos han sido definidos se pasa a la creación de estos

requisitos como tareas en la plataforma de Bitbucket o del Team Foundation Service, en el
que se asigna el responsable, el hito (milestone), la prioridad, el módulo, etc.
Figura 11: Creación y asignación de Tarea
Fuente: Proyecto SIMBA
Como se puede observar en la Figura 11, la creación de una tarea en el

proyecto Simba, donde se puede visualizar a quién se le debe asignar, la prioridad de la
tarea, el componente, el hito (milestone). Para la creación de nuevas tareas se reunía con
el cliente y se definían todos los requisitos que debía considerarse en el sprint nuevo o
agregar nuevas al sprint actual, para el que se seguía el siguiente proceso:
32
Figura 12: Proceso de Creación de tareas en LWP.
Tareas Definir los

cumplidas del requisitos para
Sprint actual el nuevo Sprint
Reunión con el Revisar las tareas Agregar las

cliente del Sprint actual
tareas al nuevo
Sprint
Agregar nuevas
Agregar las tareas
tareas al sprint
a la plataforma
actual
Bitbucket
El Issue Tracker es una buena herramienta para gestionar esta tarea, sin
embargo, se han desarrollado otros complementos afines, en este caso un tablero Kanban
(ver figura 13) a partir del Issue Tracker, de manera que se pueda gestionar según la
recomendación de Scrum, visualizando las tareas nuevas, abiertas o resueltas como en la
figura anterior, además de que el uso es más fácil porque solo se debe arrastrar tareas por
el tablero.
Figura 13: Plataforma Bitbucket – Tablero Kanban.
33
3.7.2. Actualización y monitoreo Tareas
El desarrollador iba moviendo sus tareas en la plataforma de abierto (en

desarrollo) ha resuelto, o en algunas ocasiones se revisaba la plataforma y no se veía
cambios, se le consultaba sobre cuales tareas ya había realizado para actualizar el estado
estas tareas.
Cuando el desarrollador culminaba el sprint, este debía ser verificado por

tanto se hacía una primera verificación interna como control de calidad antes de enviar al
cliente, en algunas ocasiones se encontraban errores o defectos, y este pasaba a crearse
como una nueva tarea en el sprint actual, cuando todas las observaciones se solucionaban
recién se podía entregar al cliente para su revisión. Entonces este proceso se guiaba del
siguiente diagrama:
Figura 14: Revisión de Tareas en LWP
Verificación de Verificar el
Entregar avance al
tareas resueltas y funcionamiento
cliente
pendientes de las tareas
Problemas en
tareas, pasar a
tareas pendientes
A pesar de la revisión interna, el cliente detectaba fallas (ver figura15) en los

requisitos solicitados, y esto hacía que crearan nuevas tareas en la plataforma y se
informaba al equipo para que empiece a trabajar en la solución de estas observaciones.
34
Figura 15: Revisión detallada de tareas con el cliente .
Como se puede observar en la figura 15, el cliente las pintaba de color verde
que significa cuando las tareas cumplían con el requerimiento solicitado, el color naranja
significa que no hacía lo que decía como en este caso dice no funciona, los de color amarillo
significa que se realiza las tareas pero con fallas, de ese modo también se gestionaba las
tareas por parte cliente, cuando no se entendían los de color amarillo se solicitaba una
reunión con el cliente, donde participaba el desarrollador y mi persona. Así resolviendo
todo tipo de dudas, una vez resueltas, mi trabajo era volver a subir estas tareas a la
plataforma de Bitbucket.
Una vez resueltas todas las observaciones del cliente, se realizaba una
verificación interna de estas nuevas tareas y otra vez pasaba a cliente para su verificación,
y este era un ciclo hasta que el cliente de conformidad del Sprint.
Figura 16: Proceso de revisión de Tareas con el c liente en LWP
Verificar el
funcionamiento
de las tareas
Verificación de Entregar avance Tareas

tareas resueltas y al cliente cumplidas
pendientes
Incidencia en
tareas, pasar a
tareas
pendientes
35
3.7.3. Desempeño y avance de proyecto
Existen diversas formas de evaluar el desempeño de un equipo de trabajo,

sin embargo, en esta empresa se decidió medir el desempeño por el número de tareas
resueltas y el tiempo en el que lo resuelve. Inicialmente como con la ayuda del practicante
se podía mantener la lista de tareas actualizado, permitía 2 cosas; la primera, poder hacer
una reunión diaria de 5 minutos, segundo un informe mensual del avance de todos los
proyectos.
• La reunión diaria, consistía en juntarse con cada equipo y preguntar lo

siguiente:
o ¿Qué tareas desarrollo el día anterior? o ¿Qué problemas tuvo
con la codificación?
o ¿Qué tareas piensa resolver hoy?
• El informe mensual, consistía en elaborar un informe de cada proyecto en

el que se muestre:
o El número de tareas resueltas por Sprint, o El número de tareas
pendientes, o La productividad basada en el número de tareas
resultas por día, o Porcentaje de cumplimiento de Sprint, o El
estado del proyecto (A tiempo o atrasado).
Cabe aclarar que como inicialmente este proceso de gestión de las tareas no
estaba llevándose adecuadamente, en los informes mensuales se podía ver que solo un
proyecto se encontraba a tiempo, los demás siempre permanecían atrasados por diversos
motivos, sin embargo, la finalidad de este monitoreo no era la de desmotivar a los equipos
sino de encontrar solucionar que permitan ayudar y mejorar el proceso de desarrollo.
36
Figura 17: Reunión - Informe mensual del proyecto Simba
3.8. MEJORA DEL SISTEMA DE REPORTES DE AVANCES DE PROYECTOS
La empresa se basa en algunos principios de Scrum, para conocer la

capacidad de producción de parte del equipo de desarrolladores, apoyándose en un gráfico
de tareas resueltas en la plataforma de Bitbucket, en un inicio se integró el plugin con el
que contaba la empresa, pero este plugin solo te mostraba en forma general y el problema
principal es que si se pasaba de 50 tareas no los contaba, entonces el gráfico salía con datos
incorrectos.
Entonces como se realizaba la retroalimentación o el informe mensual de

cada proyecto por entregable, se realizó la sugerencia por parte del equipo de proyecto
que se tenía que mejorar en los procesos de monitorear los reportes por fechas, así de
poder visualizarlo en el momento indicado y no esperar cada 30 días para saber cómo
estaba el rendimiento del equipo, en lo cual se integró en 2 gráficos (un gráfico especificado
de las tareas resuelta en las fechas realizadas) y el otro gráfico de las tareas pendientes.
3.8.1. Alternativas de solución
Existen varias opciones, el primero, desarrollar un software que se conecte

a Bitbucket y grafique los reportes en un sistema propio, el segundo, adquirir la licencia de
Atlassian Jira para contar con este tipo de reportes, el tercero desarrollar un complemento
integrado en la misma plataforma de Bitbucket para graficar estos reportes.
37
Cuadro 3: Comparación de alternativas de solución
Alternativa Pros Contras
Desarrollar un software que se Tener las fuentes y la posibilidad Tener una aplicación más por
conecte a Bitbucket y grafique los de modificar la aplicación. mantener.
reportes en un sistema propio
Adquirir la licencia de Atlassian Contar con lo que se necesita y Costo de licencia inaccesible e
Jira para contar con este tipo de muchas opciones más para la innecesaria actualmente para la
reportes gestión. empresa.
Desarrollar un complemento • Una primera versión existente Alojamiento parcial del
integrado en la misma plataforma de integración. complemento.
de Bitbucket para graficar estos
• La plataforma se encarga del
reportes.
alojamiento parcial y la
seguridad.
• Libertad de que otros usuarios
fuera de la empresa lo usen.
• Posibilidad de madurez del
complemento con las
sugerencias de otros usuarios.
Se analizó y decidió por la tercera alternativa, es decir desarrollar un

complemento que funcione sobre la misma plataforma Bitbucket.
3.8.2. Análisis del Desarrollo de un Complemento
Las funcionalidades del plugin son:
Cuadro 4: Requisito – Resumir tareas por sprint
RF1: Usuario: Equipo de Proyecto

Nombre Historia: Resumir tareas por sprint Prioridad: 3
Tiempo Estimado: 3 días Responsable: L. Reyes
Descripción: Traer las tareas del sprint del Issue Tracker y calcular la tareas resueltas,
pendientes, tareas resueltas por día y el responsable del sprint.
Criterios de Aceptación:
El número de tareas resueltas coincide con el número de tareas resueltas en el Issue
Tracker.
El número de tareas pendientes coincide con el número de tareas pendientes en el Issue
Tracker.
38
Cuadro 5: Requisito – Generar grafico de BurnDown
RF2 Usuario: Equipo de Proyecto

Nombre Historia: Generar Grafico de BurnDown Prioridad: 3
Descripción: Mediante la lista de tareas debe generar el gráfico de área expresando las
tareas pendientes por cada fecha, conocido como BurnDown, si se cambia el sprint, debe
actualizarse el gráfico.
El número de tareas pendientes de una fecha coincide con las tareas resueltas del Issue
Tracker.
Cuando se cambia de Sprint se actualiza el gráfico con los nuevos datos.
Cuadro 6: Requisito – Generar grafico de tareas resueltas
RF3 Usuario: Equipo de Proyecto

Nombre Historia: Generar Gráfico de tareas resueltas Prioridad: 2

Descripción: Mediante la lista de tareas debe generar el grafico de área expresando las
tareas resueltas por cada fecha, si se cambia el sprint, debe actualizarse el gráfico.
El número de tareas resueltas de una fecha coincide con las tareas resueltas del Issue
Tracker. Cuando se cambia de Sprint se actualiza el gráfico con los nuevos datos.
Cuadro 7: Requisito no funcional – Acceso libre al plugin
RNF1 Usuario: Equipo de Proyecto

Nombre Historia: Acceso Libre al plugin Prioridad: 3
Tiempo Estimado: 1 día Responsable: L. Reyes
Descripción: El plugin debe ser libre para cualquier usuario de Bitbucket, por tanto, debe
alojarse en un servidor con acceso libre.
Instalar complementos para otros usuarios de Bitbucket.
39
Cuadro 8: Requisito no funcional – Usar JavaScript y JQuery

Nombre Historia: Usar JavaScript y JQuery Prioridad: 3
Descripción: El plugin debe usar JavaScript o JQuery como lenguaje de programación.
El desarrollo del código debe contener la estructura de JavaScript.
El desarrollo del código debe contener la estructura de JQuery.
Cuadro 9: Requisito no funcional – Usar JqPlot

Nombre Historia: Usar JqPlot Prioridad: 3
Descripción: El plugin debe usar JqPlot como herramienta graficadora, y como alternativa
2, Google Chart si fuera necesario.
El tipo de grafico JqPlot.
3.8.3. Diseño del Plugin
La arquitectura del plugin debería ser así:
Figura 18: Arquitectura del Plugin
Plataforma
Bitbucket
Servidor LWP
Plugin
40
El funcionamiento del plugin sigue el siguiente proceso:
• Extraer los datos de la plataforma de Bitbucket como los Issues

(Tareas), Milestones (Fechas de entregables), Display_name (nombre
del encargado del proyecto).
• Agregar los datos obtenidos al plugin.
• Seleccionar los Issues por Milestones, y agregarlos en arreglo.
• El plugin agrega 2 gráficos, el primero donde nos representará las

tareas resueltas y la segunda las tareas pendientes.
3.8.4. Construcción del Plugin.
El plugin pasó por dos versiones, la primera con gráfica JqPlot y la otra con
Google Chart.
Cuadro 10: Comparación entre Google Charts con JqPlot
Alternativa Pros Contras
Google Charts • Todos los navegadores web y • No se puede realizar
móviles modernos. desgloses.
• No genera línea de
tendencias.
• Solo cuenta con 6 tipos de
gráficos.
• No se puede integrar
JQuery nativa.
JqPlot • Proporciona facilidad de • No es compatible con todos
que cuando cambie el los navegadores.
tamaño de su ventana del
navegador cambie de
tamaño del gráfico.
• Dibuja un gráfico en
lienzo.
• Cuenta con más de
gráficos.
Fuente: (FusionCharts, 2017)
Conociendo las características de cada una de las gráficas se determinó que
JqPlot como el más adecuado para su implementación.
41
Figura 19: Grafico por Sprint
Fuente: Proyecto Qubank
En el gráfico se puede observar el número de tareas que cuenta el Sprint,

número de tareas resueltas, número de tareas pendientes, número promedio de tareas
resueltas por día, número estimado de días para resolver tareas pendientes y el nombre
del encargado del Sprint.
Para la obtención del número de tareas que cuenta el Sprint se conecta a

través del API, donde el límite es de 50 tareas por Sprints, una vez obtenido las tareas y sus
atributos que contiene como la fecha en que se resolvió dicha tarea, se realizó una
búsqueda por estado “resolved” para contabilizar las tareas resueltas. Para la obtención de
tareas pendientes se realizó una resta de tareas totales con el número de tareas resueltas.
En el primer gráfico de Issues By Day (tareas resueltas), se puede observar

las tareas resueltas por fechas, el número de cantidad.
En el segundo gráfico de BurnDown (tareas pendientes), se observa el

número de tarea por resolver con las respectivas fechas.
42
3.8.5. Pruebas del Plugin
Para la realización de pruebas del plugin se consideraron casos con un

proyecto que contenía más información como es el caso del software Simba, en las cuales
se probaron los siguientes casos:
• Probar, agregando tarea, asignar responsable, milestones y generar

reporte.
• Probar cambiar de estado de la tarea de pendiente a resueltas y
verificar reporte.
• Probar, cambiar la tarea de milestones y verificar el número de tareas
por Sprint.
Entonces la forma de probar este plugin que se realizó fue basada en criterios de aceptación
por el equipo de proyecto, mas no en casos de prueba redactados como podrían sugerir
otras metodologías.
Figura 20: Pruebas del plugin
43
3.8.6. Informe de Desempeño usando el Plugin
En el último informe, ya se contaba con el plugin, por lo que se expuso

utilizando el plugin, mostrando los siguientes datos:
Figura 21: Informe – Usando el plugin
Como se observa en la figura del proyecto Simba, según el plugin integrado

en la plataforma bitbutcket resulta, que el sprint lleva por fecha “09/06 Almacén”, número
total de tareas es de 32, numero de tareas resueltas es de 14, numero de tareas pendientes
es de 18, numero de tareas resueltas por día aproximado, número de días pendientes para
finalizar es de 6 días y así mismo el nombre del responsable “Carlos Vásquez”.
En el primer grafico de título “Issues By Day” se puede observar que el día

12 de agosto desarrollo 5 tareas, el día 14 de agosto desarrollo 4 tareas, el día 15 de agosto
desarrollo 3 tareas y el día 21 de agosto desarrollo 2 tareas.
En el segundo grafico de título “BurnDown” se puede observar que el

número de tareas pendientes va disminuyendo hasta encontrar que quedan 18 tareas por
resolver como se muestra en el resumen.
Se pudo concluir entonces, que usando el plugin se puede ver el desempeño

del equipo en cualquier momento, permitiendo al equipo ver en tiempo real la estadística
de su productividad y tareas pendientes.
44
3.9. Otras actividades
3.9.1. Pruebas funcionales del Camotracker
Se realizó las siguientes pruebas para el funcionamiento de Camotracker

(Software para la gestión de colaboradores).
• Ingresar con número de Documento Nacional de Identidad (Dni): Mediante

el número del DNI se puede ingresar al sistema Camotracker, para realizar el
ingreso al trabajo, así como también para marcar la salida.
Figura 22: Ingreso con Documento Nacional de Identidad
• Ingresar con clave proporcionada por el sistema: Mediante una clave, que se
almacena en la base de datos, que es proporcionada por el sistema
Camotracker, se permite registrar su ingreso, así como su salida del sistema.
Figura 23: Ingreso con clave para marcar entrada.
45
• Ingresar conectándose mediante la red o el wifi: Mediante la instalación de
una aplicación en el celular, cuando reconoce la red, te envía un mensaje
para confirmar tu ingreso al trabajo, de la misma forma para marca la salida,
te desconectas de la red y de esta manera habrás marcado tu salida.
Figura 24: Ingreso con Wifi para marcar entrada.
• Ingresar con la lectura de código de barra del DNI: Mediante un lector de

código de barra que se cuenta en la empresa, se pasa sobre el DNI, de esta
manera te permite marca tu ingreso a tu trabajo, para marcar la salida es el
mismo proceso.
Figura 25: Ingreso mediante lectura de código de barra del Dni
46
• Generar reporte por ingreso de DNI: El colaborador puede revisar su reporte
mediante el ingreso de su número de DNI, donde se presentan 2 opciones,
el primero para el reporte que es visualizar las horas trabajadas durante las
fechas que el considere, segundo ingresar para marca su registro de entrada.
Figura 26: Reporte mediante ingreso por DNI
• Generar reporte por ingreso de clave proporcionada por el sistema: El

colaborador puede revisar su reporte mediante el ingreso de su número de
clave, donde se presentan 2 opciones, el primero para el reporte que es
visualizar las horas trabajadas durante las fechas que el considere, segundo
ingresar para marca su registro de entrada.
Figura 27: Reporte medi ante ingreso por clave
47
• Generar reporte por ingreso de lectura de código de barra de DNI: Después
de haber ingresado por la lectura del código de barra, usted puede visualizar
sus horas trabajadas por fechas.
Figura 28: Reporte mediante ingreso por lectura de código de barra del DNI
• Subir recibo de pago a la hora de generar reporte: Después de generar su

reporte por las distintas formas explicadas anterior, usted puede subir su
recibo de pago, que al mismo tiempo se estará mandando un mensaje de
confirmación a su correo.
Figura 29: Subir recibo de pago por horas trabajadas
48
3.9.2. Cambio de idioma al sitio web de Camotracker
Camotracker es un software para la gestión de colaboradores, permite el

registro de entrada y salida también se encarga de crear reportes de cada trabajador.
En un primer momento contó con el idioma castellano (ver figura 29), pero
para llegar a nuevos clientes se agregó el idioma Inglés para abarcar más el mercado (ver
figura 30).
Figura 30: Pagina Camotracker – Idioma castellano
Fuente: [En línea]: http://camotracker.net/
Figura 31: Pagina Camotracker – Idioma inglés
Fuente: [En línea]: http://camotracker.net/en
49
3.9.3. Creación de video tutoriales de Camotracker
Camotracker es un software para la gestión de colaboradores y cuenta con

diferente forma de registrar tu asistencia, se realizó un video por las distintas formas de
marcar:
• Camotracker – Documento web: Documento Web, donde el colaborador

puede ingresar mediante su DNI para marcar su entrada o salida dentro de
la empresa.
Figura 32: Creación de video – Documento Web
• Camotracker – Usuario / Clave: El colaborador marca entrada o salida con su

clave de usuario asignado, estando dentro del empresa.
Figura 33: Creación de video – Usuario /Clave
50
• Camotracker – Wifi Android: El colaborador conecta su móvil al Wifi de la
empresa y se le permite marcar entrada o salida.
Figura 34: Creación de video – Wifi Android
• Camotracker – Web Facial: El colaborador marca entrada o salida usando su

rostro como mecanismos de autenticación.
Figura 35: Creación de video – Web Facial
51
• Camotracker – Código de Barra: El colaborador puede marcar su entrada o
salida con cualquier tarjeta que lo identifica y contenga código de barras.
Figura 36: Creación de video – Código de Barra
52
CONCLUSIONES
1. Se logró conocer los procesos actuales de desarrollo de software de la empresa

LWP consiguiendo expresarlo mediante un modelo BPM que cuenta con 11
procesos, verificado por el líder de la empresa.
2. Se realizó satisfactoriamente el monitoreo de tareas de los proyectos que cuenta

la empresa LWP, en la cual 5 para producción y 2 para mantenimiento con un
promedio de 200 tareas.
3. Se logró mejorar los procesos actuales, mediante el desarrollo e implementación

de un plugin con un porcentaje de aceptación superior al 50%, logrando
complementar en la plataforma de bitbutcket, que también podría ser usado por
cualquier empresa.
Se logró gestionar las actividades de desarrollo y mantenimiento, además de

aportar en la mejora del proceso actual, consiguiendo tener reportes de avance en
cualquier momento.
53
RECOMENDACIONES
Luego de esta experiencia, se recomienda que el desarrollo de software también se centre

la gestión de tareas desde los proyectos pequeños, ya que así se puede determinar el
desempeño de los miembros del proyecto de manera más certera, además, la búsqueda
de mecanismos que automaticen este proceso de gestión hace que esta tarea sea casi al
instante, por eso debe buscarse más herramientas y maneras de poder automatizar estos
procesos.
Se recomienda la plataforma de Bitbucket para la gestión de tareas de proyectos, te

permite contar con un tablero Kanban, donde se pueden visualizar las tareas pendientes,
tareas resueltas y las tareas en desarrollo.
54
BIBLIOGRAFIA
Alaimo, D. M. (2013). Proyectos agiles con Scrum: flexibilidad, aprendizaje, innovacion y

colaboracion en contextos complejos. Buenos Aires: Kleer.
Alexander Menzinsky, Gertrudis López & Juan Palacio. (2016). Scrum Manager Guia de formacion
(Vol. 2.6).
Fernández, J. M., & Cadelli, S. (2014). Convivencia de metodologías: Scrum y Rup en un proyecto de
gran escala. Recuperado el 24 de 10 de 2017, de
http://sedici.unlp.edu.ar/handle/10915/47082
FusionCharts. (2017). JavaScript (HTML5) Charting Library Comparisons. Obtenido de

https://www.fusioncharts.com/javascript-charting-comparison/
Julián Pérez ,P. & María Merino. (2013). Obtenido de https://definicion.de/plugin/.
Julián Pérez Porto & Ana Gardey. (2012). Real Academica Española. Obtenido de
https://definicion.de/proceso/
Julián Perez,P. & María Merino. (2012). Real Academica Española. Obtenido de
https://definicion.de/tarea/
Leonardo Wolk, C. (2003). El arte de soplar brazas.
Oliver Andrés, P. A. (2011). Cuatro enfoques metodológicos para el desarrollo de Software RUP -
MSF - XP - SCRUM. Recuperado el 10 de Junio de 2011
Porto, J. P. (2008). Real Academica Española. Obtenido de https://definicion.de/software/
Revista-Digital. (Abril de 2016). Que son los hitos o milestones de un proyecto. Obtenido de Revista
Digital. Tu lugar de información tecnológica y humana:
http://bibliotecaprofesional.com/que-son-los-hitos-o-milestones-de-un-proyecto/
Rouse, M. (Junio de 2015). SearchSoftwareQuality. Obtenido de

http://searchsoftwarequality.techtarget.com/definition/Scrum-sprint
Schwaber y Sutherland. (2016). La Guia Definitiva de Scrum: Las Reglas del Juego.
Tutorials-Point. (2016). Ingeniería de Software Tutorial. Obtenido de Tutorials Point:Ingeniería de

Software Tutorial: https://www.tutorialspoint.com/es/software_engineering/index.htm
55
ANEXOS
56
ANEXO I
TAREAS DE USUARIOS EN BITBUCKET – PROYECTO SIMBA
57
58
59
ANEXO II
TAREAS POR SPRINT – PROYECTO SIMBA
60
ITEM DESCRIPCIÓN RESPONSABLE
RQ1_1 Revisar y corregir la creación Cotización (versión JSF) Carlos Clemente,
de Vásquez Cisneros
RQ1_2 Reporte Balance Diario: Sale error (versión JSF) Carlos Clemente,
Vásquez Cisneros
RQ1_3 Reporte de Venta: Sale error (versión JSF) Carlos Clemente,
Vásquez Cisneros
RQ1_4 Reporte Ventas por Fechas: Sale error (versión JSF) Carlos Clemente,
Vásquez Cisneros
RQ1_5 Facturación: Al dar nuevo no abre el modal de registro Carlos Clemente,
(versión JSF) Vásquez Cisneros
RQ1_6 Cobre de Facturación: Tendrá la opción de cobrar, bajo 2 Carlos Clemente,

métodos (Contado y Crédito). Vásquez Cisneros
RQ1_7 Organización de configuración IGV: La configuración de si Carlos Clemente,

el producto trabajaría con IGV integrado o no, esto debería Vásquez Cisneros
estar en la vista de configuración de IGV. actualmente creo
que está en la configuración de procesos.
RQ1_8 Ventas: El tipo de comprobante está mal, no es la misma. Carlos Clemente,

Vásquez Cisneros
RQ1_9 Ventas: Cuando es Facturación Directa restringir el Carlos Clemente,
monto pagado. Vásquez Cisneros
RQ1_10 Facturación Directa: No carga las fotos de los productos en Carlos Clemente,
el listado. Vásquez Cisneros
RQ1_11 Compras: Las compras no funcionan. Carlos Clemente,

Vásquez Cisneros
RQ1_12 Servicio: No se puede crear Servicio. Carlos Clemente,
Vásquez Cisneros
RQ1_13 Cuentas por cobrar: Esta duplicando datos. Carlos Clemente,
Vásquez Cisneros
RQ1_14 Cuentas por cobrar detalle: El costo se está duplicando de Carlos Clemente,
los clientes. Vásquez Cisneros
61
RQ1_15 Entrega Directa: Carlos Clemente,
- No funciona el botón editar. Vásquez Cisneros
- Cuando generas una entrega se genera la fecha 1 día
antes.
- No funciona el botón eliminar
RQ1_16 Egresos: No guarda, y no sale la opción de subir imagen Carlos Clemente,

(versión JSF) Vásquez Cisneros
RQ1_17 Productos: En la lista de productos en un inicio no se Carlos Clemente,

visualiza, después de realizar la búsqueda recién se Vásquez Cisneros
visualiza.
RQ1_18 Reporte Venta por Producto: No está trayendo la cantidad Carlos Clemente,
total vendido. Vásquez Cisneros
RQ1_19 Pedidos: Cuando se agrega un nuevo cliente, del tipo de Carlos

persona jurídica no debe contener Apellido, ni Dni, debe Clemente,
pedirte el Numero de ruc. Vásquez Cisneros

RQ1_20 Cambiar la vista de Reporte Diario de Ventas a Angular y Carlos Clemente,
Spring Refactorizando. Vásquez Cisneros
RQ1_21 Cambiar la vista de Ventas por Producto a Angular y Carlos Clemente,

Spring Refactorizando. Vásquez Cisneros
RQ1_22 Cambiar la vista de ventas por Dia a Angular y Spring Carlos Clemente,
Refactorizando. Vásquez Cisneros
RQ1_23 Cambiar la vista de Balance Diario a Angular y Spring Carlos Clemente,

Refactorizando. Vásquez Cisneros
RQ1_24 Cambiar la vista de Reporte de Ventas por Trabajador a Carlos Clemente,

Angular y Spring. Vásquez Cisneros
RQ1_25 Cambiar la vista de Empresa a Angular y Spring Carlos Clemente,

Refactorizando Vásquez Cisneros
62
RQ1_26 Calculo de IGV: las lógicas de IGV debe calcularse en entre Carlos Clemente,
el neto y totales, ya no en los productos - Refactorizando. Vásquez Cisneros
RQ1_27 Producto: Hay que diferenciar los productos que son para Carlos Clemente,
venta con un check, si no está para venta no debe salir en Vásquez Cisneros
las listas de productos a vender.
RQ1_28 Listado de Egresos: Debe haber una opción ver y también Carlos Clemente,
ver el documento adjunto. Vásquez Cisneros
RQ1_29 Reporte: Crear Reporte Nuevo de Balance Anual. Carlos Clemente,

Vásquez Cisneros
RQ1_30 Listado y Reportes: Todos los reportes deben tener una Carlos Clemente,
exportar Excel. Vásquez Cisneros
RQ1_31 Cliente: Agregar Campo Email y verificar si tiene teléfono. Carlos Clemente,
Vásquez Cisneros
RQ1_32 Compras: Solo debe listarse los productos y no servicios, el Carlos Clemente,
IGV aquí se trata distinto. Vásquez Cisneros
RQ1_33 Productos: Crear Ventas vinculadas a una persona y estas Carlos Clemente,
tener comisiones. Vásquez Cisneros
RQ1_34 Crear vista Comisiones: Comisiones orientada a Servicios Carlos Clemente,

en Angular y Spring Refactorizando. Vásquez Cisneros
RQ1_35 Terminar Nota de salida y Refactorizar en la nueva Carlos Clemente,

tecnología Angular y Spring. Vásquez Cisneros
RQ1_36 Crear vista Orden de Servicio: guardar, editar, listar y Carlos Clemente,
eliminar. Refactorizando en la nueva tecnología Angular y Vásquez Cisneros
spring.
63
RQ2_1 Producto: Debe registrar Producto y Servicio, solo Carlos Clemente, Vásquez
registra producto. Cisneros
RQ2_2 Deudas de cliente: Se debe poder anular un Carlos Clemente, Vásquez
pago. Cisneros
RQ2_3 Cambiar la vista Facturación Directa a Angular y Carlos Clemente, Vásquez
spring Refactorizando. Cisneros
RQ2_4 Compras: Los productos no se están mostrando. Carlos Clemente, Vásquez
Cisneros
RQ2_5 Producto: No actualiza cuando se edita y no Carlos Clemente, Vásquez
realiza el guardado de imagen. Cisneros
RQ2_6 Facturación: Cuando se elimina un producto del Carlos Clemente, Vásquez
listado ya no deja agregar otro. Cisneros
RQ2_7 Procesos: Sin IGV, no funciona en Cotización, Carlos Clemente, Vásquez
Pedidos y Facturación. Cisneros
RQ2_8 Entrega directa: cuando se anula una entrega, se Carlos Clemente, Vásquez
desaparece el pedido del producto. Cisneros
RQ2_9 Guía de Remisión: cuando se anula la entrega, Carlos Clemente, Vásquez
debe mostrarse. Cisneros
RQ2_14 General: Crear una clase en css que permita Carlos Clemente, Vásquez
mostrar los montos hacia la derecha. Cisneros
RQ2_15 Compras: Elimino la compra y se sigue Carlos Clemente, Vásquez

mostrando, hago una venta y desaparece la Cisneros
compra eliminada. La compra debe seguir
mostrándose con estado anulado
RQ2_16 Balance Diario: Se está mostrando la venta desde Carlos Clemente, Vásquez
pagadas, deben aparecer desde facturada. Cisneros
RQ2_17 Ventas por Producto: Se está mostrando la venta Carlos Clemente, Vásquez
desde pagadas, deben aparecer desde facturadas Cisneros
RQ2_18 Diario de Ventas: Se está mostrando la venta Carlos Clemente, Vásquez

desde pagadas, deben aparecer desde facturadas Cisneros
64
RQ2_19 Clientes: No Registra nuevo cliente Carlos Clemente, Vásquez
Cisneros
RQ2_20 Proveedores: Habilitar vista de proveedores, no Carlos Clemente, Vásquez
está guardando. Cisneros
RQ2_21 Nueva Orden de servicio: La OS debe cambiar a Carlos Clemente, Vásquez

estado facturado cuando se realizó el proceso de Cisneros
venta
RQ2_22 Facturación: No busca por fechas Carlos Clemente, Vásquez

Cisneros
RQ2_23 Producto Base: Cuando se llena un nombre con Carlos Clemente, Vásquez
más caracteres del límite se cuelga la pantalla, Cisneros
debe salir un mensaje que diga el límite.
RQ2_24 Comisiones: Se verán en un listado de servicios, Carlos Clemente, Vásquez

donde se podrá editar los valores de las Cisneros
comisiones, serán comisiones generales para
todos.
RQ2_25 Reporte de comisiones: Falta exportar, el filtro Carlos Clemente, Vásquez

trabajador tiene error, quitar columna total, Cisneros
orden de los campos del listado (Doc, Trabajador,
Descripción, Fecha, Monto,
Comisión y Porcentaje)
RQ2_26 Cotización: Carlos Clemente, Vásquez
- En el formulario de cotización solo debe Cisneros
mostrarse el stock disponible. siempre y cuando
el sistema este configurado para trabajar con
Stock.
- Si en la cotización excedes del stock disponible

debe salir una notificación de cantidad no
disponible. siempre y cuando el sistema este
configurado para trabajar con Stock.
65
RQ2_27 Pedidos: Carlos Clemente, Vásquez
Cisneros
- En el formulario de pedido solo debe mostrarse
el stock disponible, siempre y cuando el sistema
este configurado para trabajar con Stock.
- Cuando se crea un pedido, los productos

elegidos pasan a un estado de separado y ya no
están disponibles en el stock.
- Al editar los productos de un pedido se debe

actualizar los productos en estado separado.
- Al eliminar un pedido los productos que estaban

en estado separado deben regresar a
disponibles como si nunca lo hubieran separado.
- Al eliminar un pedido los productos que estaban

en estado separado deben regresar a
disponibles como si nunca lo hubieran separado.
RQ2_28 Facturación: Carlos Clemente, Vásquez

- Cuando se crea una factura los productos, si los Cisneros
productos vinieron de un pedido ahora pasan a
dejar de estar en un estado de separado y pasan
a un estado de facturado. Por tanto, ya no están
disponible en stock
RQ2_29 Facturación: Cuando guarda y no haz elegido un Carlos Clemente, Vásquez

tipo de comprobante, no lo registra y la pantalla Cisneros
se cuelga, cuando le das guardar debe salir un
mensaje avisando que debe elegir el tipo de
comprobante para así poder registrarlo.
66
RQ2_30 Facturación: Agregar el campo orden para Carlos Clemente, Vásquez
vincular con las OS. Cisneros
RQ2_31 Facturación: Filtros de fechas, no hacen la Carlos Clemente, Vásquez

búsqueda Cisneros
RQ2_32 Marca: Cuando se edita una marca y se le quitan Carlos Clemente, Vásquez
productos base, se cuelga. Cisneros
RQ2_33 Egreso: no guarda imagen Carlos Clemente, Vásquez

Cisneros
RQ2_34 Transferencia: Crear el módulo de Transferencia. Carlos Clemente, Vásquez
Cisneros
RQ2_35 Conversión: Crear el módulo de Conversión de Carlos Clemente, Vásquez
productos. Cisneros
RQ2_36 Reporte de Caja: Todo ítem debe ser por registro Carlos Clemente, Vásquez
de pago, si se paga por deuda de clientes cada Cisneros
recibo es un ítem en el reporte.
67
ANEXO III
68
ENCUESTA DE ACEPTACIÓN DEL PLUGIN
1: ¿Cuan útil considera que es el resumen de sprint que muestra el plugin?
1. Malo.
2. Regular.
3. Bueno.
4. Muy bueno.
5. Excelente.
2: ¿Cuan útil considera los gráficos que muestra el plugin?
1. Malo.
2. Regular.
3. Bueno.
4. Muy bueno.
5. Excelente.
3: ¿Considera que el plugin fortalece el proceso de desarrollo de su

proyecto?
1. Malo.
2. Regular.
3. Bueno.
4. Muy bueno.
5. Excelente.
69

Gestión de Tareas de Software

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Gestión de Tareas de Software

Hochgeladen von

Copyright:

Verfügbare Formate

UNIVERSIDAD NACIONAL AGRARIA DE LA SELVA

FACULTAD DE INGENIERÍA EN INFORMÁTICA Y SISTEMAS

INFORME DE PRÁCTICAS PRE PROFESIONALES

GESTIÓN DE TAREAS DE SOFTWARE EN LEAD WORKING

Presentado por: Luis Alberto, Reyes Viera

Asesor: ING. Brian Cesar, Pando Soto

Periodo de Prácticas Pre Profesionales: 16/03/2017 – 16/09/2017

Lugar de las Prácticas Pre Profesionales: LEAD WORKING PARTNER SAC

TINGO MARIA - OCTUBRE 2017

A Dios que me ha dado la vida y

A mis padres, por su comprensión,

A mis maestros y la Universidad

Mi más sincero agradecimiento:

A la FACULTAD DE INGENIERÍA INFORMÁTICA Y SISTEMAS (FIIS), que a través de sus

A mis compañeros de la Promoción 2010 y a otras promociones de la FIIS, por brindarme

LWP S.A.C. es una empresa dedicada al desarrollo de software a nivel

En esta experiencia se logró monitorear 7 proyectos de software, de las

Se concluye que la gestión de tareas es importante en una empresa de

Figura 1. Mapa de ubicación geográfica de LWP……………………………………………………………………………………….. 15

Figura 2. Organigrama estructural de LWP ………………………………………………………………………………………………. 15

Figura 20. Pruebas del plugin .........................................................................................…………………………

Cuadro 1. Equipo de trabajo ..............................…………………………………………………………………………………....... 25

Cuadro 2. Proyectos en LWP ……….......................…………………………………………………………………………………….. 27

Cuadro 5. Requisito – Generar grafico de BurnDown .................…………………………………………………………... 38

El informe da a conocer el proceso de desarrollo de las actividades realizadas

El Capítulo I: “Descripción de la Organización”, describe el contexto general

El Capítulo II: “Marco Teórico y Conceptual”, nos da a conocer el marco

El Capítulo III: “Actividades Desarrolladas”, en este capítulo se explicará de

Finalizando, se mencionan las conclusiones obtenidas al finalizar las

1.1. DESCRIPCIÓN DE LA ORGANIZACIÓN

LEAD WORKIN PARTNER SAC.

Se constituye como una agencia de desarrollo de sistemas web y

1.1.3. Ubicación Geográfica

La Empresa LEAD WORKING PARTNER SAC. se encuentra ubicada en:

• Provincia : Leoncio Prado.

• Distrito : Rupa Rupa.

• Entidad : LEAD WORKING PARTNER SAC.

• Dirección : Jr. Arequipa 1085.

• Altitud : 109 m.s.n.m.

• Temperatura : Máx. 31°C – Mín. 13 °C.

1 [En línea]: Sitio Oficial de Lead Working Partner , (http://bidsoft.net/ , 2013).

Fuente: LEAD WORKING PARTNERT [En linea]: https://maps.google.com/

1.1.4. Misión y Visión2

Ser una empresa líder en desarrollo y mantenimiento de software con la

Ser reconocidos por nuestro mercado, contar con productos maduros

1.1.5. ORGANIGRAMA ESTRUCTURAL

Figura 2: Organigrama estructural de LEAD WORKING PARTNER SAC.

Equipo de Proyecto 1 Equipo de Proyecto 2 Equipo de Proyecto ...

Fuente: Elaboración propia

2 [En línea]: Sitio Oficial de Lead Working Partner , (http://bidsoft.net/ , 2013).

2.1. CONCEPTOS METODOLÓGICOS

Según (Schwaber y Sutherland, 2016) menciona que, Scrum es un marco

Figura 3: Marco de trabajo Scrum

Fuente: Marco de trabajo Scrum (Schwaber y Sutherland, 2016).

2.1.1.1. Características del Scrum

Según (Oliver Andrés, 2011) menciona que, Scrum da prioridad a los

Figura 4: Equipo Scrum e interacciones.

Fuente: Proyectos agiles con Scrum (Alaimo, 2013)

El Product owner se focaliza en maximizar la rentabilidad del producto. La

• Determinar la visión del producto, hacia dónde va el equipo de

Según (Alaimo, 2013) menciona que el equipo de desarrollo es auto-

Tomando algunas referencias de (Leonardo Wolk, 2003), podemos decir

Las responsabilidades principales del ScrumMaster son: