aplicación móvil en dispositivos ios para la gestión de

APLICACIÓN MÓVIL EN DISPOSITIVOS iOS PARA LA GESTIÓN DE PROYECTOS ÁGILES CON SCRUM

Aplicación móvil en dispositivos iOS para la gestión de proyectos ágiles con Scrum

Juan Martín Jiménez Sardi, [email protected]

Trabajo de Grado presentado para optar al título de Ingeniero Multimedia

Asesor: Pablo Bejarano, Especialista (Esp) en Procesos de desarrollo de Software.

Universidad de San Buenaventura Colombia

Facultad de Ingeniería

Ingeniería Multimedia

Santiago de Cali, Colombia

2018

mailto:[email protected]?subject=Acerca%20de%20tu%20Proyecto%20de%20Grado


Citar/How to cite [1] Jimenez S. 2018

Referencia/Reference

Estilo/Style:

IEEE (2014)

[1] J. M. Jiménez Sardi, “Aplicación móvil en dispositivos iOS para la gestión de

proyectos ágiles con Scrum”, Trabajo de grado Ingeniería Multimedia,

Universidad de San Buenaventura Cali, Facultad de Ingenierías, 2018.

Bibliotecas Universidad de San Buenaventura

Biblioteca Fray Alberto Montealegre OFM - Bogotá.

Biblioteca Fray Arturo Calle Restrepo OFM - Medellín, Bello, Armenia, Ibagué.

Departamento de Biblioteca - Cali.

Biblioteca Central Fray Antonio de Marchena – Cartagena.

Universidad de San Buenaventura Colombia

Universidad de San Buenaventura Colombia - http://www.usb.edu.co/

Bogotá - http://www.usbbog.edu.co

Medellín - http://www.usbmed.edu.co

Cali - http://www.usbcali.edu.co

Cartagena - http://www.usbctg.edu.co

Editorial Bonaventuriana - http://www.editorialbonaventuriana.usb.edu.co/

Revistas - http://revistas.usb.edu.co/

Biblioteca Digital (Repositorio)

http://bibliotecadigital.usb.edu.co

https://co.creativecommons.org/?page_id=13

https://co.creativecommons.org/?page_id=13


TABLA DE CONTENIDO

Lista de tablas ................................................................................................................................... 5

Lista de figuras ................................................................................................................................. 6

Resumen ........................................................................................................................................... 8

1. Introducción .............................................................................................................................. 9

2. Planteamiento del problema .................................................................................................... 10

2.1 Estado del arte (Desk Research) ........................................................................................... 11

2.1.1 Aplicaciones de gestión de proyectos ............................................................................ 11

2.1.2 Software basado en Scrum ............................................................................................. 13

2.2 Identificación del problema .................................................................................................. 14

3. Justificación y Solución .......................................................................................................... 15

4. Objetivos ................................................................................................................................. 16

4.1 Objetivo general ................................................................................................................... 16

4.2 Objetivos específicos ............................................................................................................ 16

5. Definición de Actividades (EDT) ........................................................................................... 17

6. Cronograma ............................................................................................................................. 18

7. Marco Teórico ......................................................................................................................... 19

7.1 Metodologías de desarrollo de software ............................................................................... 19

7.1.1 Metodologías tradicionales ............................................................................................ 20

7.1.2 Metodologías ágiles ....................................................................................................... 21

7.3 Aplicaciones móviles nativas ............................................................................................... 34

7.3.1 Entorno de desarrollo integrado (IDE) .......................................................................... 36

7.3.2 Lenguajes de programación ........................................................................................... 36

8. Análisis e Ideación .................................................................................................................. 38


9. Diseño de la Solución ............................................................................................................. 42

9.1 Diseño de software ............................................................................................................... 42

9.1.1 Levantamiento de requerimientos .................................................................................. 42

9.1.2 Diagrama de casos de uso .............................................................................................. 44

9.1.3 Tarjetas CRC .................................................................................................................. 44

9.1.4 Diagrama de clases ........................................................................................................ 45

9.1.5 Prototipado ..................................................................................................................... 45

9.2 Diseño de arquitectura .......................................................................................................... 46

9.2.1 Diagrama de componentes ............................................................................................. 46

9.2.2 Diagrama de despliegue ................................................................................................. 47

10. Desarrollo e implementación ............................................................................................. 48

10.1 Implementación de interfaces gráficas ............................................................................... 48

10.1.1 Elementos utilizados .................................................................................................... 49

10.2 Implementación de controladores y lógica de negocio ...................................................... 50

10.3 Configuración e implementación de la autenticación y base de datos con Firebase .......... 51

10.3.1 Requisitos previos ........................................................................................................ 51

10.3.2 Configuración de Firebase en el proyecto ................................................................... 51

10.3.3 Adición del SDK .......................................................................................................... 52

10.3.4 Inicialización de Firebase ............................................................................................ 53

11. Validación del prototipo ..................................................................................................... 54

12. Conclusiones ...................................................................................................................... 73

13. Trabajos Futuros ................................................................................................................. 74

Bibliografía ..................................................................................................................................... 76

Glosario .......................................................................................................................................... 80


Lista de tablas

Tabla I. Resultados de casos de prueba…………………………………………………………54


Lista de figuras

Fig. 1. Árbol de problemas…………….………………………………………………...………14

Fig. 2. Definición de actividades (EDT)………………………………………………...………17

Fig. 3. Estimación de tiempos (PERT)...………………………………………………...………18

Fig. 4. Cronograma del proyecto………………………………………………………...………18

Fig. 5. Fases del modelo en cascada...…………………………………………………...………20

Fig. 6. Fases de la metodología Scrum…………………………………………………..………22

Fig. 7. Visualización de backlog……….………………………………………………...………31

Fig. 8. Equipo de trabajo scrum..………………………………………………………...………33

Fig. 9. Estudios del uso de tablets por Chitika…………………………………………...………35

Fig. 10. Aplicación de la técnica persona.………………………………………………..………38

Fig. 11. Aplicación de la técnica persona.………………………………………………..………38

Fig. 12. Aplicación de la técnica persona.....……………………………………………..………39

Fig. 13. Aplicación de la técnica mapa de empatía..……………………………………..………40

Fig. 14. Aplicación de la técnica mapa de empatía..……………………………………..………40

Fig. 15. Diagrama de casos de uso…….......……………………………………………..………44

Fig. 16. Tarjetas CRC (Class Responsibility Collaboration)……………………………..………44

Fig. 17. Diagrama de clases………………………..……………………………………..………45

Fig. 18. Prototipo a papel………...…….......……………………………………………..………46

Fig. 19. Diagrama de componentes………………………..……………………………..………47

Fig. 20. Diagrama de despliegue…………………..……………………………………..………47

Fig. 21. Implementación de interfaces gráficas…………………………………………..………48

Fig. 22. Estructura de carpetas del aplicativo móvil……………………………………..………50

Fig. 23. Detalle de la carpeta Controllers...………..……………………………………..………50

Fig. 24. Lineas de comando para la creación de un Podfile……….……………………..………52

Fig. 25. Linea de comando para agregar un pod al Podfile……..………………………..………52

Fig. 26. Linea de comando para instalar los Pods………………………………………..………52

Fig. 27. Lineas de código para inicializar los Pods…..…………………………………..………53

8


Resumen

El presente proyecto tiene como propósito diseñar e implementar una solución móvil para celulares

iOS que permita a empresas desarrolladoras de software en Colombia, gerenciar proyectos basados

en la metodología Scrum.

Como primera instancia se realiza un estudio del estado del arte de aplicaciones orientadas a la

gerencia de proyectos, con el fin de abstraer información necesaria, como segunda instancia se

hace el diseño de la solución móvil, seguido por su implementación y validación, y como última

instancia se expondrán las conclusiones generales en las que se pueden detallar los puntos de vista

de los autores con respecto al producto final logrado y aprendizajes alcanzados. También se habla

de los trabajos a futuro.

Palabras clave: metodologías ágiles, iOS, aplicación móvil, Scrum, Swift.

9


1. Introducción

A mediados de la década de los 80 Ikujiro Nonaka e Hirotaka Takeuchi identificaron y definieron

el modelo Scrum en su libro “The New New Product Development Game” [1] buscando dar orden

a las tareas: pendientes, en proceso y terminadas con el fin de gestionar regularmente las

expectativas del cliente y permitirle al producto ser flexible, adaptativo y evaluar la productividad

y calidad del mismo. Luego, en 1993, Jeff Sutherland, John Scumniotales y Jeff McKenna

concibieron, ejecutaron y documentaron el primer Scrum para desarrollo ágil de software [2]

basándose en el estudio de gestión de equipos de Takeuchi y Nonaka como base. En 2017 la

organización Scrum Alliance, liberó el tercer reporte que realiza acerca del estado de Scrum [3], el

reporte, es la consolidación de más de dos mil respuestas, en el cual apreciamos las siguientes

afirmaciones: “las organizaciones eligen Scrum principalmente para entregar más valor para el

cliente, en la encuesta de este año, 85 por ciento de los encuestados dicen que Scrum mejora la

calidad de la vida laboral y el 63 por ciento de los proyectos basados en la metodología scrum

tienen éxito”.

El desarrollo de software en Colombia ha crecido exponencialmente y en estos momentos

representa una gran parte del sector TI, por ejemplo, el “Informe de caracterización del sector de

software y tecnologías de la información en Colombia”, realizado por FEDESOFT en el 2015 [4]

indica que en Colombia existían ya para esa época 3718 empresas en el área de las TIC y el 23 por

ciento de estas están destinadas al desarrollo de software.

Un estudio de la Asociación de la Industria Móvil de Colombia (Asomóvil) [5] que busca

identificar los hábitos de uso de telecomunicaciones móviles en el país revela que los colombianos

utilizan en promedio cuatro horas al día el celular y unas 3,4 horas de su tiempo diario para navegar,

lo cual hace del celular un dispositivo mandatorio que puede llegar a facilitar los procesos de la

implementación de la metodología Scrum, ya que facilita el acceso a la información de manera

descentralizada, por esto se considera importante brindar a las empresas colombianas

desarrolladoras de software una aplicación móvil que permita gestionar y hacer seguimiento de sus

proyectos, basada en la metodología ágil Scrum, permitiendo disminuir tiempos, hacer que la

metodología sea cada vez más utilizada en nuestro país y facilitar el logro de mejores resultados.

10


2. Planteamiento del problema

Según un estudio publicado por IDC [6], el 25% de los proyectos de software fracasan desde su

concepción y hasta un 50% requieren rehacer y reprogramar cosas, una mayoría (el 54%) de las

causas documentadas de fracaso de un proyecto es atribuible a la gestión del proyecto.

Sorprendentemente para algunos, los desafíos técnicos son el factor menos citado (3%). Lo que

indica que los proyectos en su mayoría no satisfacen al cliente, fracasan o llegan a tener sobrecostos

por la mala gestión del mismo, la comunicación insuficiente entre los integrantes y el mal uso o la

falta de una metodología de desarrollo.

Considerando lo anterior, una herramienta para empresas pequeñas desarrolladoras de software de

Colombia, como una aplicación móvil basada en la metodología ágil Scrum que permita crear y

asignar tareas, reportar tareas realizadas, tiempo trabajado y consultar las mismas para así evitar

errores, poder saber cuánto tiempo se gasta en cada tarea y en qué porcentaje se encuentra el

desarrollo según lo planteado, sería un gran aliado a la hora de combatir la mala gestión de los

proyectos, la comunicación insuficiente entre los integrantes y permitiría aplicar la metodología

Scrum de manera descentralizada.

11


2.1 Estado del arte (Desk Research)

Con el fin de obtener información pertinente al proyecto, se hizo una búsqueda de software

orientado a la gestión de proyectos, a continuación, se expondrán cada uno de estos con sus

respectivas ventajas y desventajas.

2.1.1 Aplicaciones de gestión de proyectos

2.1.1.1 Trello

Desarrollada por Fog Creeck en septiembre del 2011 se lanza un prototipo con el que se espera

solucionar algunos problemas de planificación de alto nivel, luego en 2014 Trello se separa de Fog

Creeck convirtiéndose en Trello Inc, ya en el 2017 Atlassian compra Trello y da comienzo a un

nuevo capítulo dedicado a fortalecer a equipos de todo el mundo. Este sistema optimiza la gestión

de procedimientos de comunicación y de progreso, independientemente si son tareas académicas o

laborales, dividiendo la sección de tareas como guía para brindar una mejor experiencia y

perspectiva del proyecto que se está liderando o desarrollando [7].

Ventajas:

Se puede asignar una tarea a más de una persona.

Integraciones con terceros. (GitHub)

Se pueden añadir comentarios en las tareas.

Es inclusivo y tiene una modalidad para daltónicos.

Desventajas:

Todo se organiza en tableros. Cuando el equipo y los proyectos crecen, los tableros juegan

en nuestra contra. Por ejemplo, hay que saber en qué tablero ubicaste la tarea para poder

asignarla a un colaborador.

Las etiquetas no son globales, debes elegir en cada tablero tus etiquetas, lo cual puede llegar

a ser confuso.

12


2.1.1.2 Asana

Fue desarrollada por el co-fundador de Facebook Dustin Moskovitz y el ingeniero Justin

Rosenstein, que tenían, entre otras ocupaciones, mejorar la productividad de los empleados

de Facebook. [8] Asana dice ser usada por decenas de miles de equipos [9], incluyendo empresas

como Twitter, TicToc Studio, Foursquare, LinkedIn, Disqus, Airbnb, Rdio, AdParlor, Flapps y

Entelo.

Ventajas:

Conocer en tiempo real el estado de las tareas y proyectos.

Recibir notificaciones directamente en la app.

Los comentarios en las tareas pueden ser respondidos por otros usuarios llevando casi una

conversación que a la vez queda como un registro de la tarea.

Desventajas:

No se presenta ningún gráfico de Gantt ni nada por el estilo.

La versión gratuita solo permite 15 personas trabajando en equipo.

2.1.1.3 Microsoft Project

Diseñado, desarrollado y comercializado por Microsoft para asistir a administradores de proyectos

en el desarrollo de planes, asignación de recursos a tareas, dar seguimiento al progreso, administrar

presupuesto y analizar cargas de trabajo. El software Microsoft Office Project en todas sus

versiones (la versión 2016 es la más reciente a junio de 2017) es útil para la gestión de proyectos,

aplicando procedimientos descritos en el PMBoK del Project Management Institute. [10]

Ventajas:

Aplica los procedimientos descritos en el PMBoK del Project Management Institute.

Crea calendarización de rutas críticas.

Gráfica Gantt.

https://es.wikipedia.org/wiki/Dustin_Moskovitz

https://es.wikipedia.org/w/index.php?title=Justin_Rosenstein&action=edit&redlink=1

https://es.wikipedia.org/w/index.php?title=Justin_Rosenstein&action=edit&redlink=1

https://es.wikipedia.org/wiki/Facebook

https://es.wikipedia.org/wiki/Microsoft

https://es.wikipedia.org/wiki/Gu%C3%ADa_de_los_fundamentos_de_gesti%C3%B3n_de_proyectos

https://es.wikipedia.org/wiki/Project_Management_Institute

https://es.wikipedia.org/wiki/Project_Management_Institute

13


Desventajas:

La interfaz gráfica es como ver Excel.

Alto costo.

No permite medir los esfuerzos de los colaboradores.

2.1.2 Software basado en Scrum

2.1.2.1 ScrumDo

ScrumDo es una aplicación web de gestión de historias Agile / Scrum. La simplicidad de su

software y permitir al usuario trabajar con la menor cantidad de funcionalidades es lo que para

ellos resulta ser el valor agregado de su software, permitiendo al usuario utilizar a cabalidad la

metodología Scrum, sin sobrecargar de funcionalidades su herramienta.

Ventajas:

Simple y fácil de usar.

Ideal para personas que estén aprendiendo sobre la metodología.

Cuenta con un video introductorio. (Tutorial)

Desventajas:

Solo muestra un gráfico de horas trabajadas vs. las planificadas.

No es un software para todo el ciclo de vida del proyecto.

2.1.2.2 IceScrum

IceScrum es una herramienta web basada en la metodología Scrum y Kanban, ofrece las opciones

de operación, consulta y estimación de historias de usuario. Permite añadir historias de usuario a

la pila de producto, dividir el tiempo en Sprints y mover estas historias de la pila de producto a

cada uno de los Sprint. [11]

Ventajas:

Cuenta con tres idiomas (inglés, español y francés)

14


Posee la técnica de Planning Póker para la estimación y paneles virtuales.

Integraciones con terceros. (Dropbox, GoogleDrive, GitHub entre otros).

Desventajas:

La versión gratuita es muy limitada.

Por momentos por más que elijas un idioma, se mezclan entre ellos.

2.2 Identificación del problema

Para la identificación del problema, se realizó un árbol de problemas el cual ayuda a identificar las

causas y las consecuencias del mismo, lo cual es de vital ayuda para atacar el problema

directamente desde su “raíz”.

Fig. 1. Árbol de problemas

15


3. Justificación y Solución

Se decide realizar este proyecto por dos principales razones, la primera es proporcionar a las

empresas pequeñas desarrolladoras de software en Colombia una solución móvil para la gestión de

proyectos ágiles en español fomentando el uso de metodologías ágiles y por otra parte hacer uso

de los dispositivos móviles iOS, ya que, según Citrix, iOS ha servido para añadir movilidad y

posibilidades “cloud” a las empresas en mayor medida que sus competidores, concretamente con

un 62% de uso como plataforma móvil para uso empresarial, frente al 35% de Android. [12]

La metodología Scrum es una metodología ágil y flexible que gestiona el desarrollo de software y

pretende maximizar el retorno de la inversión de la empresa. Según Alfatec, sus principios son la

inspección continua, adaptación, auto-gestión e innovación, consiste en la división del trabajo

completo en distintos apartados o bloques, que se abordan en periodos cortos de tiempo (1-4

semanas). [13]

“Favorece a una mayor flexibilidad a los cambios”.

“Las necesidades del cliente y las evoluciones del mercado se analizan e integran a las

tareas en menos tiempo”.

“Conlleva una alta predicción de tiempos puesto que se conoce la velocidad y rendimiento

del equipo”.

“Reduce los riesgos al conocer las funcionalidades de cada rol y la velocidad a la que

avanza el proyecto”.

“El método de trabajo y la revisión continua produce una mayor calidad del software”.

Se plantea realizar entonces el mínimo producto viable de una aplicación nativa para iOS en la cual

una empresa pequeña desarrolladora de software pueda llevar el control de su proyecto basado en

la metodología ágil Scrum, la aplicación permitirá al encargado del proyecto asignar tareas a los

demás integrantes del equipo y estos a su vez podrán reportar y consultar las horas que han

trabajado en cada tarea, reportar si la tarea está en progreso, terminada o sin empezar.

16


4. Objetivos

4.1 Objetivo general

Desarrollar el mínimo producto viable en idioma español de una solución móvil para facilitar la

gestión de proyectos, basado en la metodología de gestión SCRUM, para pequeñas empresas

desarrolladoras de software en Colombia.

4.2 Objetivos específicos

Indagar el estado del arte de software utilizado en la gerencia de proyectos para identificar

ventajas y desventajas susceptibles de mejora.

Diseñar la solución móvil para facilitar la gestión de proyectos en pequeñas empresas

desarrolladoras de software en Colombia.

Implementar el diseño de la solución móvil.

Validar la implementación de la solución móvil mediante casos de prueba.

17


5. Definición de Actividades (EDT)

Fig. 2. Definición de actividades (EDT)

18


6. Cronograma

Fig. 3. Estimación de tiempos (PERT)

Fig. 4. Cronograma del proyecto

19


7. Marco Teórico

La gestión de proyectos siempre ha sido un área importante a la hora de verificar los campos de

acción de una organización, pero se hace mucho más fundamental cuando de desarrollo de

productos y proyectos tecnológicos se refiere, siendo este el pilar central del mercado tecnológico

actual. “Una empresa que vive creando, planificando y desarrollando proyecto, quiere decir que

es una empresa que está en vanguardia de los cambios continuos e imparables de la globalización

actual. Es una entidad que está en constante cambio interno y crecimiento gradual y sostenible.”

[14]

“Muevan bits, no átomos” es una de las más célebres frases del fundador del MIT Media Lab y

fundador del programa ‘One Laptop per child’ Nicholas Negroponte, refiriéndose al importante

impacto que tiene el desarrollo de tecnología y además afirmando que, en el mundo actual, todo el

susceptible a ser digital. Esta premisa ha sido muy bien entendida por emprendedores y grandes

organizaciones encontrando, desde hace ya varias décadas atrás, las TIC`s como un importante

mecanismo de automatización de procesos organizacionales, pero el impacto de la era digital se ha

ampliado a tal punto de llevar procesos humanos básicos como relacionarse, conversar y debatir,

por medio de la tecnología, esto ha hecho que diferentes campos de la sociología y hasta el mismo

marketing se hayan interesado en estudiar y verificar el alcance que tienen sus campos de acción

en la tecnología y cómo ésta puede ser el vehículo que llevaría directamente al público o al contacto

humano, ya aclarando este proceso de la interacción del humano con la tecnología y la importancia

actual de la misma y el impacto en la vida de todos (Tanto a nivel organizacional como a nivel

personal) y haciendo una convergencia entre los conceptos aplicados anteriormente, nace la

necesidad fundamental de cómo gestionar y llevar control de estos procesos de desarrollo

tecnológico y es aquí donde el mercado comienza a preocuparse en el “¿Cómo puedo

optimizar mis recursos y poder llevar un correcto seguimiento a la ejecución de un proyecto?”.

7.1 Metodologías de desarrollo de software

Las metodologías de desarrollo de software, son un marco de trabajo usado para estructurar,

planificar y controlar el proceso de desarrollo en sistemas de información [15].

20


7.1.1 Metodologías tradicionales

Son aquellas con mayor énfasis en la planificación y control del proyecto, en especificación precisa

de requisitos y modelado. Las metodologías tradicionales no se adaptan adecuadamente a los

cambios, por lo que no son adecuadas cuando se trabaja en un entorno donde los requisitos no

pueden predecirse o bien pueden variar. [16]

7.1.1.1 Metodología de desarrollo en cascada

En el área del desarrollo de software el primer concepto de desarrollo ‘Cascada’ data de 1970

cuando Winston W. Royce propone una primera versión de lo que llamó ‘Metodología cascada’ en

el cual afirmaba que un proceso debe llevarse una vez haya finalizado en inmediatamente anterior,

es así como el proceso fundamental de desarrollo nace y senta un importante prospecto, no sólo en

el desarrollo de software sino en el desarrollo de productos en general.

Fig. 5. Fases del modelo en cascada

Imagen tomada de: http://www.eoi.es/blogs/demostenesdelossantos/2011/12/06/gerencia-de-proyectos/

Esta metodología no sólo creó un pilar fundamental en el desarrollo de software sino que creó un

importante problema, un estudio del año 2013 realizado por el Standish Group afirma que el 61%

de los proyectos que inician no cumplen completamente con los objetivos propuestos y el 17% de

http://www.eoi.es/blogs/demostenesdelossantos/2011/12/06/gerencia-de-proyectos/

21


los mismos terminan en un completo fracaso. Además, esa misma estadística revela que el 72% de

los proyectos sufren un retraso en su entrega.

7.1.2 Metodologías ágiles

El desarrollo ágil de software envuelve un enfoque para la toma de decisiones en los proyectos de

software, que se refiere a métodos de ingeniería del software basados en el desarrollo iterativo e

incremental, donde los requisitos y soluciones evolucionan con el tiempo según la necesidad del

proyecto. Así el trabajo es realizado mediante la colaboración de equipos auto-organizados y

multidisciplinarios, inmersos en un proceso compartido de toma de decisiones a corto plazo. [17]

7.1.2.1 Scrum.

En 1986 Nonaka y Takeuchi diseñaron un modelo de desarrollo de producto basado en cómo

trabajan importantes compañías niponas y americanas. En dicho estudio compararon la forma de

organización del trabajo de las empresas estudiadas con la forma de la organización del melé

(scrum) de los equipos de rugby, acuñando así el concepto.

En 1995, Ken Schwaber presentó “Scrum Development Process” en el “Object-Oriented

Programming Systems and Applications Conference” del 1995. En ella presentó un marco de

normas y reglas para el desarrollo de software, basado en Scrum que él implementó en el desarrollo

de Delphi.

Lo anteriormente nombrado sembraría los inicios de uno de los pilares del agilismo en la actualidad

como lo es Scrum. Tomando como base el problema del alto nivel de probabilidad de insatisfacción

en proyectos (72% de los proyectos resultan insatisfactorios) esto se debe a la alta volatilidad en la

gestión de requisitos de los proyectos de tecnología actuales, los cuales siempre tienen una altísima

probabilidad de cambio en el tiempo, lo que, en metodologías tradicionales (Cascada) representa

un reinicio del ciclo a pequeña escala, lo que termina en fuertes retrasos en el mejor de los casos y

hasta la no finalización de proyecto en el peor de ellos.

La metodología Scrum trata de solventar la posibilidad de fracaso en los proyectos (Más

específicamente de software) teniendo al cliente o usuario del producto en el centro del proceso,

https://es.wikipedia.org/wiki/Desarrollo_iterativo_e_incremental

https://es.wikipedia.org/wiki/Desarrollo_iterativo_e_incremental

22


realizando un proceso iterativo con una altísima adaptabilidad al cambio y aumentando el

dinamismo en los equipos de trabajo.

Desde la definición de los requisitos iniciales (Stories/Historias) se toma como punto de partida la

necesidad inicial del cliente y se elabora un banco de requerimientos (Product Backlog), pero sin

olvidar que estos pueden ser cambiantes en el tiempo, el Product Owner se reúne con el stakeholder

de negocio y define por cada Sprint (Que se definirá a continuación) qué elementos de valor le son

prioridad para añadir valor a su negocio y que progresivamente se vaya viendo, en entregas

completamente funcionales, como cada entrega va añadiendo valor al producto. La anterior

definición de Sprint se socializa con el scrum team y con el Scrum Master quien mediará entre el

Product Owner y las historias que se han definido de alta prioridad, y el scrum team para que, según

las habilidades principales del equipo se pueda priorizar al interior del mismo (Sprint Planning).

Definiendo el peso de cada historia por “Story points” según el peso que el mismo tenga en el

entregable del sprint, generalmente el miembro del equipo puede desarrollar (por estándar) entre 8

y 10 story points por sprint Al final de cada Sprint se hace una reunión retrospectiva (Sprint

Retrospective Meeting) en el cuál se sacan conclusiones sobre los aciertos, desaciertos y las

acciones que se tomarán para mejorar esos desaciertos y que no terminen afectando la entrega final

del producto.

Fig. 6. Fases de la metodología Scrum

Imágen tomada de: https://www.scrum.org/resources/what-is-scrum

https://www.scrum.org/resources/what-is-scrum

23


A continuación, se definirán conceptos claves para el entendimiento de la metodología.

7.1.2.1.1 Sprint (Iteración)

El Sprint es una ventana de tiempo definida desde la concepción del proyecto (Generalmente no

más de dos semanas) en donde el scrum team se compromete a entregar un subproducto

completamente funcional y de valor al producto final, este producto debe mostrarse en un “Demo”

en el cual el Product Owner o un representante de stakeholder principal verifica la funcionalidad y

hasta puede tener la posibilidad de interactuar con el mismo. Es de recordar que el producto que se

entregue en la demo, debe ser incremental al producto entregado inmediatamente anterior.

“Cada Sprint puede considerarse un proyecto con un horizonte de un mes como máximo. Al igual

que los proyectos, Sprints se utilizan para lograr algo. Cada Sprint tiene una definición de lo que

se va a construir, un diseño y un plan flexible que guiará la construcción del mismo, el trabajo y

el producto resultante. [18]

7.1.2.1.2 User Story (Historia de usuario)

Es la definición de requisitos o componentes del proyecto el cual debe ser definida entre el

stakeholder principal y el Product Owner. Las historias deben resultar en un pequeño componente

que debe ser verificable, trazable y pueda medirse en su fase de desarrollo, debe ser estimado tanto

en tiempo como en esfuerzos (story points) para saber la carga de trabajo que puede asumir el

equipo de desarrollo y esta capacidad de esfuerzo será medido por el Scrum Master. “Las historias

de usuarios a menudo se escriben en fichas o notas adhesivas, se guardan en una caja de zapatos

y se colocan en las paredes o en las mesas para facilitar la planificación y la discusión. Como tal,

cambian fuertemente el foco de la escritura sobre características a discutirlas. De hecho, estas

discusiones son más importantes que cualquier texto escrito. [19]

7.1.2.1.3 Product Backlog (Banco de historias)

Es la definición inicial de requisitos de producto definidos desde la concepción del proyecto y que

es susceptible a cambios durante la ejecución de proyecto. Este proceso se ejecuta entre el

stakeholder principal y el Product Owner, con el fin de definir los pasos y requisitos fundamentales

del desarrollo.”Trabajar con un backlog de producto Scrum no significa que el equipo Scrum no

está autorizado a crear y utilizar otros artefactos. Ejemplos de artefactos adicionales podrían ser

24


un resumen de las diversas funciones de usuario, descripciones de flujo de trabajo, directrices de

interfaz de usuario, guiones gráficos o prototipos de interfaz de usuario. Sin embargo, estos

artefactos no reemplazan el Backpack de productos Scrum, sino que complementan y detallan su

contenido.” [20]

Además, un Product Backlog debe tener unas consideraciones importantes “Cada registro de

productos de Scrum tiene ciertas propiedades que lo diferencian de una simple lista de tareas

pendientes:

una entrada en el Scrum Product Backlog siempre agrega valor al cliente

las entradas en el Backlog de productos Scrum se priorizan y se ordenan en consecuencia el nivel

de detalle depende de la posición de la entrada dentro de la cartera de productos Scrum

todas las entradas son estimadas el backlog de productos Scrum es un documento vivo no hay

acción-elementos o tareas de bajo nivel en el Scrum Product Backlog“ [20]

7.1.2.1.4 Sprint Backlog (Banco de historias por iteración)

Cómo su nombre lo indica, se trata del Backlog saliente de la reunión de planeación por iteración

(Sprint Planning). Este concepto surge ya que las tareas de cada sprint no son arbitrariamente

escogidos, sino que cada miembro del equipo de desarrollo escogerá cuales puede desarrollar según

sus habilidades. ”El backlog de sprint es comúnmente mantenido como una hoja de cálculo, pero

también es posible utilizar su sistema de seguimiento de defectos o cualquiera de una serie de

productos de software diseñados específicamente para Scrum o ágil (Texto original citado, en

Inglés)”. [21]

Este sistema de Backlog por Sprint puede ser mantenido y actualizado durante la ejecución del

sprint, aunque no se recomienda hacerlo muy frecuentemente. “Durante el Sprint Scrum, se espera

que los miembros del equipo actualicen el backlog de sprint a medida que se dispone de nueva

información, pero mínimamente una vez al día. Muchos equipos lo harán durante el scrum diario.

Una vez cada día, el trabajo estimado que queda en el sprint es calculado y graficado por el

ScrumMaster, lo que resulta en un gráfico de burndown de sprint como éste (Texto original citado,

en Inglés)”. [21]

25


7.1.2.1.5 Sprint Planning (Planeación de la iteración)

Es una reunión que se realiza al iniciar el ciclo del sprint en el cual el Scrum Team, Scrum Master

y Product Owner, definen qué tareas (Stories) se desarrollarán en la presente iteración y se realiza

la puesta en discusión de las mismas para la respectiva estimación de las mismas, cabe resaltar que

para la estimación de las tareas, quien escogió la historia debe socializar su estimación con el resto

del equipo y el mismo dará aval para dicha estimación. La idea de esta reunión es distribuir las

asignaciones según el conjunto de habilidades de cada miembro del equipo con el fin de que se

pueda aprovechar el tiempo de la mejor forma y así reducir la probabilidad de caer en sobrecostos

que se pueden solventar.

“La planificación de sprint es una reunión de un día de duración, dividida en dos sesiones de 4

horas, que también es timeboxed.

1. Durante la primera sesión, el Propietario del Producto presenta las prioridades más elevadas

del Backlog de Producto al equipo. El equipo y el propietario del producto colaboran para ayudar

al equipo a determinar qué funcionalidad se puede ofrecer en el próximo Sprint. El equipo se

compromete a este Backlog de productos al final de la sesión - Backlog de productos

seleccionados.

2.Durante la segunda sesión de la reunión, el equipo planea cómo cumplirá este compromiso al

detallar su trabajo como un plan en el Backlog de Sprint.(Texto original citado, en Inglés)”. [22]

7.1.2.1.6 Scrum Daily Stand up (Reunión diaria de seguimiento)

Es una pequeña reunión (De no más de 15 minutos) en la cual todos los miembros del equipo

comentan el progreso de sus historias, si han encontrado algún bloqueante que no deje proseguir

con el desarrollo y si es así comentarlo con el Scrum Team para que se le pueda dar solución con

el objetivo que ese traspiés no afecte el desarrollo de Sprint en progreso. En esta fase s requiere de

la completa sinceridad del equipo de trabajo para que se puedan tomar acciones rápidas y eficaces.

“Scrum otorga un estatus especial a aquellos que están comprometidos, y muchos equipos hacen

cumplir una regla en la que sólo se permite a los que están comprometidos a hablar durante la

reunión diaria del scrum (Texto original citado, en Inglés)”. [23]

26


7.1.2.1.7 Sprint Retrospective Meeting (Reunión retrospectiva de la iteración)

Es una de las reuniones más importantes del flujo de trabajo del Sprint, en esta se requiere la

presencia de todo el equipo con el fin de verificar fortalezas, falencias y diseñar planes de acción

para que esas falencias no terminen afectando el desarrollo del proyecto ni, en mayor medida, la

entrega final del producto. La idea de la reunión recae en la identificación temprana de acciones

que pueden resultar a largo plazo una dificultad mayor en el desarrollo de producto, además de

resaltar las fortalezas del equipo para trabajar sobre la motivación del mismo.

“Elementos clave de la retrospectiva del sprint:

Las mejoras de proceso se hacen al final de cada sprint. Esto asegura que el equipo del proyecto

está siempre mejorando la forma en que funciona.

La retrospectiva es un proceso de colaboración entre todos los miembros, incluido el equipo, el

propietario del producto y el ScrumMaster.

Todos los miembros del equipo identifican lo que salió bien y lo que podría mejorarse.

Los miembros del equipo discutir el proceso que están siguiendo y dar cualquier sugerencia para

la mejora.

Los miembros del equipo discutir cualquier otra idea que podría mejorar su productividad.

El ScrumMaster prioriza las acciones y lecciones aprendidas basadas en la dirección del equipo.

La retrospectiva apoya la formación del equipo y la vinculación, sobre todo porque cualquier área

de conflicto puede ser identificada y tratada.

La retrospectiva ayuda a construir el sentido del equipo de la propiedad y su autogestión. (Texto

original citado, en inglés)” [24].

27


7.1.2.1.8 Sprint Review and Increment (Demo, revision del sprint incremental)

En esta fase se cierra completamente el Sprint, en el cual se hace la demostración funcional del

entregable que se definió en la planeación de la iteración que finaliza. En esta presentación pueden

participar diversos equipos de trabajo y personal de negocio (Definidas por el stakeholder

principal) y presentada por el equipo de trabajo en el cual los asistentes pueden ser solo

observadores e incluso pueden interactuar con el entregable si así está definido en el acta de

reunión. Esta entrega debe ser incremental, es decir, debe añadir valor a los productos entregados

en sprints inmediatamente inferiores.

7.1.2.1.9 Roles de Trabajo

A continuación, se detallarán los roles que hacen parte del desarrollo al manejar la metodología

ágil Scrum.

7.1.2.1.9.1 Scrum Developer

Se trata del desarrollador perteneciente al equipo de trabajo Scrum, sobre él recae la

responsabilidad de participar en el desarrollo del producto.

7.1.2.1.9.2 Scrum Master

Se trata del ‘líder del proyecto’. El scrum master tiene la responsabilidad de mediar la carga de

trabajo y asignación de historias de cada integrante del equipo de trabajo, además es el responsable

de llevar los bloqueantes de cada miembro del equipo a una solución, ya sea por mano propia o

haciendo el respectivo escalamiento a la persona indicada.

7.1.2.1.9.3 Product Owner

A veces llamado “Product Manager” se trata del gestor del proyecto por lado del cliente, en sus

manos recae la responsabilidad de gestionar requisitos y priorizar los mismos, teniendo un total

entendimiento de los aspectos de negocio más importantes del mismo y teniendo como punto de

partida el valor que pueda brindar las mismas al cliente.

28


7.1.2.1.10 El Manifiesto Ágil

“En marzo de 2001, 17 profesionales del software, críticos de los modelos de producción basados

en procesos, fueron convocados por Kent Beck, que había publicado un par de años antes el libro

en el que explicaba la nueva metodología Extreme Programming (Beck, 2000). Se reunieron en

Salt Lake City para discutir sobre los procesos empleados por los equipos de programación. En

la reunión se acuñó el término “Métodos Ágiles” para definir a aquellos que estaban surgiendo

como alternativa a las metodologías formales: CMM-SW, (precursor de CMMI) PMI, SPICE

(proyecto inicial de ISO 15504), a los que consideraban excesivamente “pesados” y rígidos por

su carácter normativo y fuerte dependencia de planificaciones detalladas, previas al desarrollo.

Los integrantes de la reunión resumieron en cuatro postulados lo que ha quedado denominado

como “Manifiesto Ágil”, que son los valores sobre los que se asientan estos métodos. Hasta 2005,

entre los defensores de los modelos de procesos y los de modelos ágiles, fueron frecuentes las

posturas radicales, más ocupadas en descalificar al otro, que en conocer sus métodos”. [25]

El manifiesto ágil es entonces la definición entre profesionales innovadores de la industria del

software sobre las buenas prácticas que se deberían tener en el momento de mejorar el

cumplimiento de un proyecto de software. El manifiesto ágil se definen doce principios que se

expondrán a continuación.

“1. Nuestra principal prioridad es satisfacer al cliente a través de la entrega temprana y continua

de software de valor.

2. Son bienvenidos los requisitos cambiantes, incluso si llegan tarde al desarrollo. Los procesos

ágiles se doblegan al cambio como ventaja competitiva para el cliente.

3. Entregar con frecuencia software que funcione, en periodos de un par de semanas hasta un par

de meses, con preferencia en los períodos breves.

4. Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a

través del proyecto.

5. Construcción de proyectos en torno a individuos motivados, dándoles la oportunidad y el

respaldo que necesitan y procurándoles confianza para que realicen la tarea.

6. La forma más eficiente y efectiva de comunicar información de ida y vuelta dentro de un equipo

de desarrollo es mediante la conversación cara a cara.

29


7. El software que funciona es la principal medida del progreso.

8. Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y

usuarios deben mantener un ritmo constante de forma indefinida.

9. La atención continua a la excelencia técnica enaltece la agilidad.

10. La simplicidad como arte de maximizar la cantidad de trabajo que no se hace, es esencial.

11. Las mejores arquitecturas, requisitos y diseños emergen de equipos que se autoorganizan.

12. En intervalos regulares, el equipo reflexiona sobre la forma de ser más efectivo y ajusta su

conducta en consecuencia” [25]

7.1.2.1.11 Consideraciones de Scrum

“Se comienza con la visión general del resultado que se desea, y a partir de ella se especifica y da

detalle a las funcionalidades que se desean obtener en primer lugar.

Cada ciclo de desarrollo o iteración (sprint) finaliza con la entrega de una parte operativa del

producto (incremento). La duración de cada sprint puede ser desde una, hasta seis semanas,

aunque se recomienda que no exceda de un mes”. [26]

Con lo que se explica la realización de la iteración no como un lapso de tiempo propiamente

expresado sino como un proceso en el cual se requiere una salida funcional (haciendo referencia

de producto), demostrable e incremental, es decir, que agregue valor a la implementación

inmediatamente anterior.

“Al finalizar cada sprint se revisa funcionalmente el resultado, con todos los implicados en el

proyecto. Es por tanto la duración del sprint, el período de tiempo máximo para descubrir

planteamientos erróneos, mejorables o malinterpretaciones en las funcionalidades del producto.”

[27] Esto anterior implicando que la duración del sprint no es netamente desarrollo como equipo

scrum como se dice en la pura teoría sino que la implicación del Product Owner debe ser total, es

decir, debe tener la capacidad total para identificar problemas de definición o definir el valor de

negocio que tendrá la realización de dicho componente. Es de aclarar que si una funcionalidad no

es perceptible por el usuario o por parte de producto, ese sprint no será satisfactorio y la

metodología no sería realmente aprovechada.

30


“Son muchos los factores impredecibles en un proyecto. La gestión predictiva asigna al rol de

gestor del proyecto la responsabilidad de su gestión y resolución. En scrum los equipos son auto

organizados, con un ámbito de decisión suficiente para adoptarlas resoluciones que consideren

oportunas.”. [27] La auto organización y autogestión dentro de los equipos scrum es la razón de

ser de la metodología, la capacidad de los equipos scrum para reconocer sus fortalezas y debilidades

como equipo hace que esta metodología sea diferenciadora, en donde un ‘Scrum master’ como

líder de equipo únicamente entra a mediar en situaciones discordantes dentro del equipo.

Respecto a los “Backlogs” de producto y de Sprint, a continuación, se revisará unas comparaciones

fundamentales entre los ‘Scrum Backlogs’ y los requerimientos de sistema de las metodologías

tradicionales de desarrollo.

“En los proyectos predictivos, los requisitos del sistema suelen especificarse en documentos

formales; mientras que en los proyectos ágiles toman la forma de pila del producto o lista de

historias de usuario.

Los requisitos del sistema formales se especifican de forma completa y cerrada al inicio del

proyecto; sin embargo, una pila del producto es un documento vivo, que evoluciona durante el

desarrollo.

Los requisitos del sistema los desarrolla una persona o equipo especializado en ingeniería de

requisitos a través del proceso de obtención (licitación) con el cliente. En scrum el cliente

(propietario del producto) comparte su visión con todo el equipo, y la pila del producto se realiza

y evoluciona de forma continua con los aportes de todos”. [28]

Esto anterior refiere un hilo-conductor sobre los ‘backlogs’ (o pilas) en donde se refieren como

documentos con alta volatilidad y altamente adaptables al cambio.

31


Fig. 7. Visualización de backlog

Además, en el día a día de un equipo Scrum se pueden evidenciar varios aspectos, en los cuales

hay que tener especial atención, ya que de ellos depende la correcta ejecución de proyectos ágiles.

Son procesos que pueden parecer extremadamente simples pero que suponen grandes problemas

cuando su aplicación no es tenida en cuenta dentro del marco de trabajo.

Inspección: “Mediante inspección, significa que los usuarios de scrum inspeccionan los artefactos

de scrum para reducir el coste y el tiempo no deseados y alcanzar el objetivo de Sprint en menos

tiempo estipulado. Idealmente, la inspección debe ser realizada con frecuencia y preferiblemente

por inspectores expertos, ya que es un proceso diligente que se llevará a cabo a intervalos

regulares, tanto como parte del trabajo (Texto original en inglés)” [29]. Esto último supone que

hay un constante trabajo de verificación de alcances y producto (En algunos ámbitos estos procesos

son llamados Grooming Backlog en los cuales el equipo Scrum se reúne con su Product Owner para

verificar el Backlog y hacer actualizaciones al mismo si así se considera.

Grooming Backlog. “Backlog Grooming es cuando el Product Owner y parte o todo el resto del

equipo revisan los elementos del backlog para asegurarse de que el backlog contiene los elementos

apropiados, que se les da prioridad y que los elementos en la parte superior del backlog están

listos Para entrega. Esta actividad ocurre de manera regular y puede ser una reunión oficialmente

programada o una actividad en curso. Algunas de las actividades que ocurren durante este

32


refinamiento del retraso incluyen eliminar historias de usuarios que ya no parecen relevantes

crear nuevas historias de usuarios en respuesta a las necesidades recién descubiertas reevaluación

de la prioridad relativa de las historias asignar estimaciones a historias que aún no han recibido

una corrección de estimaciones a la luz de información recién descubierta dividiendo las historias

de usuarios que son de alta prioridad pero demasiado gruesas para encajar en una próxima

iteración (Texto citado original en Inglés)” [30]

Otro de los aspectos que se deben tener en cuenta en la gestión y ejecución de un proyecto scrum

siendo esta la adaptación un aspecto fundamental en la ejecución de Scrum como metodología de

trabajo que se adapta a la alta volatilidad de proyectos. “El principio de adaptación sugiere que se

hacen ajustes en los procesos o en los materiales mismos, cuando ocurre una desviación más allá

de los límites aceptables. Este factor se suma a una de las mejores ventajas de la metodología

scrum, ya que influye directamente en la calidad y la cantidad de desarrollo del producto (Texto

original citado en inglés)”. [29]

Factores de riesgo. Dentro de un equipo de trabajo scrum, y en general en el ámbito de la

metodología es importante tener en cuenta los factores de riesgo dentro del desarrollo de un

producto, diferente a lo que se puede pensar debido a su ‘informalismo’ los factores de riesgos son

unos de los principales factores que trata de cubrir Scrum como metodología (Adaptándose a la

volatilidad e incertidumbre de un proyecto de software).”Como los equipos de Scrum suelen ser

interfuncionales, los miembros de varios grupos de disciplina se reúnen en una sala de equipo

común para mantener conversaciones sobre los factores de riesgo que deben considerarse en un

proyecto de desarrollo de productos específico o Sprints.(Texto original citado, en Inglés)” [31]

33


Fig. 8. Equipo de trabajo Scrum

La organización de un equipo Scrum no es propiamente dividida entre Scrum Developers, Scrum

Master, Product Owner sino que dentro de la organización del equipo se toman varios roles de los

cuales deben ser repartidos para poder lograr una excelente convergencia entre los implicados (Es

de recordar que un equipo scrum debe ser auto organizado y autogestionado) “Para ello, es

importante que el tipo correcto de comunicación se utilice en todos los puntos del proyecto. Por

ejemplo, al tratar los riesgos de alta calificación, involucrar a demasiadas personas en la

comunicación empeorará las cosas.

Por lo tanto, para abordar de forma efectiva el problema en cuestión, los "equipos de

características" se utilizan para interactuar en diferentes niveles de las capas y entre componentes.

Y varios equipos interactúan entre sí eligiendo un delegado representativo de un equipo para

participar en todas las reuniones.(Texto original citado, en Inglés)” [31]

34


7.3 Aplicaciones móviles nativas

“Las aplicaciones nativas tienen archivos ejecutables binarios que se descargan directamente al

dispositivo y se almacenan localmente. El proceso de instalación lo puede iniciar el usuario o, en

algunos casos, el departamento de TI de la empresa. La manera más común de descargar una

aplicación nativa es visitando una tienda de aplicaciones, como App Store de Apple, Marketplace

de Android o App World de BlackBerry, pero existen otros métodos que a veces ofrece el proveedor

móvil.”. [32]

Las aplicaciones móviles tienen diferentes beneficios respecto al otro tipo de aplicaciones

orientadas a dispositivos móviles que, aunque carece de la versatilidad que pueden tener otras

basadas en web. Tienen otras ventajas como mejora de performance (rendimiento con respecto al

procesamiento) y el uso de todos los dispositivos anidados de alta tecnología que contiene un

dispositivo de este estilo.

“El desarrollo de aplicaciones en para dispositivos iOS contienen unas ventajas respecto a otras

plataformas. Según dos estudios bastante recientes parece que mientras que a todos nos encanta

descargar y utilizar aplicaciones nuevas, los usuarios de iPhone pasamos mucho más tiempo al

día enredados con nuestros teléfonos (26 minutos más de media que el usuario típico de Android)

y no contentos con ello, lo hacemos en menor proporción utilizando el teléfono para llamar y más

como Smartphone para todo lo demás.”. [33]

A continuación, se mostrarán dos gráficas del estudio realizado por Chitika en el año 2013:

http://www.experian.com/blogs/marketing-forward/2013/05/28/americans-spend-58-minutes-a-day-on-their-smartphones/?WT.srch=PR_EMS_smartphones_052813_press

http://www.experian.com/blogs/marketing-forward/2013/05/28/americans-spend-58-minutes-a-day-on-their-smartphones/?WT.srch=PR_EMS_smartphones_052813_press

35


Fig. 9. Estudios del uso de tablets por Chitika Tomada de: www.applesfera.com

Otro de los beneficios del desarrollo para iOS es la alta tasa de start ups que son consumidoras de

productos de Apple, uno de ellos es Ash Rust quien es fundador de compañías como VoIP y

SendHub, el cual afirma que en Silicon Valley, la mayor parte de compañías jóvenes son

consumidoras de productos de apple.

http://www.applesfera.com/

36


“Hasta hace poco apenas se veían otra cosa que no fueran iPhones en las manos de la gente. Eso

incluye a nuestro propio equipo, otras compañías con las que tenemos amistad, y nuestros amigos

y familiares. iOS fue la mejor elección dado que nos permitió conseguir rápidamente el feedback

de la gente que conocíamos.”. [33]

7.3.1 Entorno de desarrollo integrado (IDE)

Es una aplicación informática que proporciona servicios integrales para facilitarle

al desarrollador o programador el desarrollo de software. Normalmente, un IDE consiste de

un editor de código fuente, herramientas de construcción automáticas y un depurador. La mayoría

de los IDE tienen auto-completado inteligente de código (IntelliSense). Algunos IDE contienen

un compilador, un intérprete, o ambos. [34]

7.3.1.1 Xcode

Actualmente en su versión 9.2, es un software, es un entorno de desarrollo integrado (IDE, en sus

siglas en inglés) para macOS que contiene un conjunto de herramientas creadas

por Apple destinadas al desarrollo de software para macOS, iOS, watchOS y tvOS. Su primera

versión tiene origen en el año 2003, se encuentra disponible de manera gratuita en el Mac App

Store o mediante descarga directa desde la página para desarrolladores de Apple. Xcode trabaja

conjuntamente con Interface Builder, una herencia de NeXT, una herramienta gráfica para la

creación de interfaces de usuario. [35]

Xcode incluye la colección de compiladores del proyecto GNU (GCC), y puede compilar

código C, C++, Swift, Objective-C, Objective-C++, Java y AppleScript mediante una amplia

gama de modelos de programación, incluyendo, pero no limitado a Cocoa, Carbón y Java. [35]

7.3.2 Lenguajes de programación

Un lenguaje de programación es un lenguaje formal que especifica una serie de instrucciones para

que una computadora produzca diversas clases de datos. Los lenguajes de programación pueden

usarse para crear programas que pongan en práctica algoritmos específicos que controlen el

comportamiento físico y lógico de una computadora o celular. [35]

https://es.wikipedia.org/wiki/Desarrollador_de_software

https://es.wikipedia.org/wiki/Programador

https://es.wikipedia.org/wiki/Desarrollo_de_software

https://es.wikipedia.org/wiki/Editor_de_c%C3%B3digo_fuente

https://es.wikipedia.org/wiki/Depurador

https://es.wikipedia.org/wiki/IntelliSense

https://es.wikipedia.org/wiki/Compilador

https://es.wikipedia.org/wiki/Int%C3%A9rprete_(inform%C3%A1tica)

https://es.wikipedia.org/wiki/Entorno_de_desarrollo_integrado

https://es.wikipedia.org/wiki/MacOS

https://es.wikipedia.org/wiki/Apple_Inc.

https://es.wikipedia.org/wiki/MacOS

https://es.wikipedia.org/wiki/IOS

https://es.wikipedia.org/wiki/WatchOS

https://es.wikipedia.org/wiki/TvOS

https://es.wikipedia.org/wiki/Mac_App_Store

https://es.wikipedia.org/wiki/Mac_App_Store

https://es.wikipedia.org/w/index.php?title=Interface_Builder&action=edit&redlink=1

https://es.wikipedia.org/wiki/NeXT

https://es.wikipedia.org/wiki/GNU

https://es.wikipedia.org/wiki/GCC

https://es.wikipedia.org/wiki/C_(lenguaje_de_programaci%C3%B3n)

https://es.wikipedia.org/wiki/C%2B%2B

https://es.wikipedia.org/wiki/Swift_(lenguaje_de_programaci%C3%B3n)

https://es.wikipedia.org/wiki/Objective_C

https://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Java

https://es.wikipedia.org/wiki/AppleScript

https://es.wikipedia.org/wiki/Cocoa_(inform%C3%A1tica)

https://es.wikipedia.org/wiki/Carbon_(API)

https://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n_Java

https://es.wikipedia.org/wiki/Software

https://es.wikipedia.org/wiki/Algoritmo

37


7.3.2.1 Swift

Swift es un lenguaje de programación multiparadigma creado por Apple enfocado en el desarrollo

de aplicaciones para iOS y macOS. Fue presentado en WWDC 2014 [36] y está diseñado para

integrarse con los Frameworks Cocoa y Cocoa Touch, puede usar cualquier biblioteca programada

en Objective-C y llamar a funciones de C. También es posible desarrollar código en Swift

compatible con Objective-C bajo ciertas condiciones. Swift tiene la intención de ser un lenguaje

seguro, de desarrollo rápido y conciso. [37]

7.3.2.2 C++

C++ es un lenguaje de programación diseñado a mediados de los años 1979 por Bjarne Stroustrup.

La intención de su creación fue el extender al lenguaje de programación C mecanismos que

permiten la manipulación de objetos. En ese sentido, desde el punto de vista de los lenguajes

orientados a objetos, el C++ es un lenguaje híbrido. [38]

Posteriormente se añadieron facilidades de programación genérica, que se sumaron a los

paradigmas de programación estructurada y programación orientada a objetos. Por esto se suele

decir que el C++ es un lenguaje de programación multiparadigma. [38]

https://es.wikipedia.org/wiki/Apple

https://es.wikipedia.org/wiki/WWDC

https://es.wikipedia.org/wiki/Cocoa_(inform%C3%A1tica)

https://es.wikipedia.org/wiki/Cocoa_Touch

https://es.wikipedia.org/wiki/Objective-C

38


8. Análisis e Ideación

Haciendo uso de la técnica Persona, se detallarán a continuación 3 perfiles de tipos de usuario que

se contemplaron en el desarrollo.

Fig. 10. Aplicación de la técnica persona


39



La técnica persona trata de crear usuarios objetivo del sistema, con el fin de conocer el modus

operandi de los mismos y obtener información pertinente a la hora de pensar en la interfaz de

usuario y en la experiencia del usuario. De estos usuarios entonces sabemos que el rango de edades

es entre los 24 y los 35 años de edad, todos cuentan con un celular iPhone, trabajan en empresas

desarrolladoras de software, no tienen discapacidades físicas ni mentales y viven en Colombia.

Una técnica complementaria a la anterior es el mapa de empatía el cual tiene como objetivo

conocer, con el mayor grado de detalle posible, cuál es el segmento de clientes y/o clientas al que

vamos a dirigir esa nueva propuesta, basándose en como esa persona se siente y percibe su entorno

con aspectos clave como: ¿qué piensa y siente?, ¿qué ve?, ¿qué oye?, ¿qué dice y hace?, sus

esfuerzos y sus resultados.

El concepto no implica tomar la visión del cliente como único punto de partida para una iniciativa

de innovación, sino tener en cuenta su perspectiva a la hora de evaluar el modelo de negocio. El

éxito de la innovación se basa en una profunda comprensión de los clientes, su entorno, sus rutinas

diarias, sus preocupaciones y sus aspiraciones. [39]

40


Fig. 13. Aplicación de la técnica Mapa de Empatía

Fig. 14. Aplicación de la técnica Mapa de Empatía

41


Al analizar los mapas de empatía se define la necesidad de dos tipos de roles, el primero con la

opción de gerenciar proyectos y asignar tareas y el segundo sería a quien se le asignan las tareas y

reporta el tiempo trabajado en cada una de las tareas, también se analiza que los usuarios utilizan

y quieren seguir utilizando celulares iOS, esto define que se deben llevar a cabo los estándares de

diseño iOS y la mejor forma de hacerlo es valiéndose de los elementos propios provistos por Xcode.

42


9. Diseño de la Solución

9.1 Diseño de software

Diseño de software es el proceso de diseño para la planificación de una solución de software. Este

proceso es, por regla general, necesario para que los programadores puedan manejar la

complejidad que la mayoría de los programas informáticos poseen y para disminuir el riesgo de

desarrollos erróneos y reprocesos.

9.1.1 Levantamiento de requerimientos

Es una descripción completa del comportamiento del sistema que se va a desarrollar. Incluye un

conjunto de casos de uso que describe todas las interacciones que tendrán los usuarios con el

software [40].

9.1.1.1 Requerimientos funcionales

Un requisito funcional define una función del sistema de software o sus componentes. Una función

es descrita como un conjunto de entradas, comportamientos y salidas. Los requisitos funcionales

pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas

que se supone, un sistema debe cumplir [41].

RF-1 El aplicativo permitirá al usuario registrarse como “organización” o como

“colaborador”; para cada uno hay un formulario distinto.

RF-2 Una vez registrado, el aplicativo permitirá al usuario ingresar con su correo

electrónico y contraseña.

RF-3 El aplicativo permitirá al rol “organización” crear un número ilimitado de

proyectos.

RF-4 Una vez creado el proyecto, el rol “organización” puede crear equipos para

esos proyectos.

RF-5 Una vez creado un equipo, el rol “organización” puede asignar colaboradores

al equipo.

RF-6 Una vez creado un proyecto, el rol “organización” puede crear tareas

43


pertenecientes al proyecto y podrá asignarlas a los equipos creados para el proyecto y a los

usuarios colaboradores.

RF-7 Una vez creado un proyecto, el rol “organización” puede crear Sprints para el

proyecto.

RF-8 Una vez creado un Sprint, el rol “organización” puede asignar tareas al sprint.

RF-9 La aplicación permite al rol “colaborador” ver todas las tareas que le han sido

asignadas.

RF-10 EL aplicativo permite al usuario “colaborador” reportar tiempos de trabajo para

cada tarea que le ha sido asignada y cambiar el estado de las mismas.

9.1.1.2 Requerimientos no funcionales

Un requisito no funcional o atributo de calidad es, en la ingeniería de sistemas y la ingeniería de

software, un requisito que sabe bien y especifica criterios que pueden usarse para juzgar la

operación de un sistema en lugar de sus comportamientos específicos. Por tanto, se refieren a todos

los requisitos que no describen información a guardar, ni funciones a realizar, sino características

de funcionamiento. [42]

RNF-1 La aplicación debe informar al usuario si hay problemas de conexión al iniciar

sesión.

RNF-2 La base de datos debe soportar 100 usuarios concurrentes.

RNF-3 El aplicativo móvil garantizar un margen de 90% de disponibilidad.

RNF-4 El aplicativo móvil debe contar con un diseño responsivo, es decir que se verá igual

en cualquier iPhone.

RNF-5 El aplicativo móvil debe permitir nuevas versiones o actualizaciones para mejorar

su funcionamiento y usabilidad.

44


9.1.2 Diagrama de casos de uso

Fig. 15. Diagrama de casos de uso

9.1.3 Tarjetas CRC

Fig. 16. Tarjetas CRC

45


9.1.4 Diagrama de clases

Fig. 17. Diagrama de clases

9.1.5 Prototipado

El prototipado en papel en productos digitales consiste en dibujar sobre ese papel las pantallas de

interfaz. La interfaz puede ser un programa de ordenador, una web o una app para móvil [43]. Para

este caso se tuvo en cuenta los elemente que Xcode provee para el desarrollo de aplicaciones

móviles y que el prototipo fuera lo más orientado a estos elementos, los cuales resultan siendo el

factor diferenciador de las aplicaciones para iOS.

46


Fig. 18. Prototipo a papel

9.2 Diseño de arquitectura

Se le ha denominado arquitectura de software, porque, a semejanza de los planos de un edificio o

construcción, estas indican la estructura, funcionamiento e interacción entre las partes del software

[44].

9.2.1 Diagrama de componentes

Un diagrama de componentes representa cómo un sistema de software es dividido

en componentes y muestra las dependencias entre estos componentes. Debido a que los diagramas

de componentes son más parecidos a los diagramas de casos de usos, éstos son utilizados para

modelar la vista estática y dinámica de un sistema. Muestra la organización y las dependencias

entre un conjunto de componentes [45].

47


Fig. 19. Diagrama de componentes

9.2.2 Diagrama de despliegue

Un Diagrama de Despliegue modela la arquitectura en tiempo de ejecución de un sistema. Esto

muestra la configuración de los elementos de hardware (nodos) y muestra cómo los elementos y

artefactos del software se trazan en esos nodos. Un Nodo es un elemento de hardware o software

[46].

Fig. 20. Diagrama de despliegue

48


10. Desarrollo e implementación

La implementación fue realizada en Xcode 9.2, bajo las licencias de la Universidad San

Buenaventura con el identificador de paquete “co.edu.usbcali.ProjectManagement”, el equipo

“university san buenaventura (Ingeniería multimedia – Multimedia Engineering)”, el certificado

de firma “iPhone Developer: Martiolo Jimenez (“GTZV74QGA)” y el requisito mínimo para la

versión de iOS es 9.

10.1 Implementación de interfaces gráficas

Basada en el prototipo a papel, la implementación de las interfaces gráficas con los respectivos

elementos provistos por Xcode 9.2, se llevó a cabo haciendo uso del Interface Builder, la herencia

de NeXT.

Fig. 21. Implementación de interfaces gráficas

49


10.1.1 Elementos utilizados

View Controller: es la representación gráfica de una vista vacía.

Navigation Controller: es el encargado de gestionar la navegación entre View Controllers.

Table View Controller: es un View Controller que automáticamente crea consigo una tabla

dentro, con las correctas dimensiones.

Tab Bar Controller: al igual que el Navigation controller se encarga de gestionar grupos

de View Controllers, con la diferencia que a cada uno lo referencia visualmente en la parte

de abajo.

Page View Controller: representa una secuencia de View Controllers que deben verse en

secuencia.

Label: los labels son los encargados de contener texto corto.

Button: es el encargado de gestionar los eventos de toque del usuario.

Text Field: es un campo de texto designado para que el usuario ingrese datos necesarios.

Text View: a diferencia del Label el Text View es un campo de texto mucho más grande.

Image View: es el campo designado para mostrar imágenes dentro de él.

Table View: una tabla en la cual mostrar información.

Date Picker: elemento para seleccionar una fecha.

Picker View: elemento para seleccionar datos alojados dentro del él.

Bar Button Item: íconos alojados en la barra de la parte inferior que representas a los View

controllers que se encuentran dentro del Tab bar controller.

Tab Bar Item: el Tab Bar es el elemento contenedor de los Bar Button Items.

Todos los anteriores elementos son provistos por Xcode sin ninguna necesidad de plugins externos

o add-ons. Los elementos se arrastran directamente a las vistas y desde la vista se referencia al

controlador, permitiendo así manejar todas las funcionalidades de cada elemento.

50


10.2 Implementación de controladores y lógica de negocio

Los controladores se desarrollaron en el lenguaje de programación Swift 3.0, heredando de Cocoa

Touch Class “View Controllers”. El proyecto en total cuenta con 27 controladores que se encargan

de recibir, procesar y enviar datos a las vistas, y están organizados en el proyecto de la siguiente

manera:

Fig. 22. Estructura de carpetas del aplicativo móvil

Fig. 23. Detalle de la carpeta Controllers

51


10.3 Configuración e implementación de la autenticación y base de datos con Firebase

Se llevó a cabo la base de datos y la autenticación con correo electrónico provista por Firebase la

cual se encarga de verificar el formato correcto del correo electrónico, la no repetición de usuarios

con el mismo correo electrónico y que la contraseña sea mayor a 6 caracteres.

10.3.1 Requisitos previos

Xcode 8.0 o una versión posterior.

Un proyecto de Xcode orientado a iOS 8 o una versión más reciente.

Los proyectos Swift deben usar la versión 3.0 o una más reciente.

El identificador del paquete de la app.

CocoaPods 1.2.0 o una versión más reciente.

10.3.2 Configuración de Firebase en el proyecto

Crea un proyecto en Firebase console si no lo hiciste anteriormente. Si ya tienes un

proyecto de Google asociado con tu app para dispositivos móviles, haz clic en Importar

proyecto de Google. De lo contrario, haz clic en “Agregar proyecto”.

Haz clic en “Agrega Firebase a tu app para iOS” y sigue los pasos de configuración. Si estás

importando un proyecto de Google existente, es posible que esto ocurra de forma

automática y solo tengas que descargar el archivo de configuración.

Ingresa el ID de paquete de la app cuando se te solicite. Es importante que ingreses el ID

de paquete que tu app está usando. Esto solo se puede configurar cuando agregas una app

a tu proyecto de Firebase.

Para finalizar el proceso, descargarás un archivo GoogleService-Info.plist. Puedes volver

a descargarlo en cualquier momento.

Si aún no lo haces, agrega este archivo a la raíz de tu proyecto de Xcode con la

función Agregar archivos de Xcode (en el menú Archivo, haz clic en Agregar archivos).

Asegúrate de que el archivo esté incluido en el destino de la compilación de tu app.

52


10.3.3 Adición del SDK

Haciendo uso de la terminal, se crea un Podfile de la siguiente forma:

Fig. 24. Líneas de comandos para la creación de un Podfile

Una vez creado el Podfile se deben agregar los Pods que quieras instalar. Puedes incluir un Pod en

tu Podfile, de la siguiente forma:

Fig. 25. Línea de comando para agregar un pod al Podfile

Estas líneas de comando deben ser incluidas dentro del Podfile y no se recomienda usar TextEdit

para hacerlo, en el caso puntual de este proyecto los pod agregados fueron: ‘Firebase/Auth’ y

‘Firebase/Database’.

Una vez agregados los Pods necesarios al PodFile se deben instalar los pods, una vez más haciendo

uso de la terminal.

Fig. 26. Línea de comando para instalar los Pods.

Una vez la terminal indique que los pods han sido instalados correctamente, se debe abrir el archivo

.xcworkspace el cual es creado automáticamente después de la instalación de los Pods en el

proyecto para ver el proyecto en Xcode. (No se debe abrir el archivo creado por vosotros ya que

no contiene los Pods y no podrás hacer uso de Firebase).

53


10.3.4 Inicialización de Firebase

Para importar las librerías y poder utilizarlas en los controladores son necesarias las siguientes

líneas de código:

Fig. 27. Línea de código para inicializar los Pods.

Las líneas de código deben ser incluidas dentro del controlador por fuera de la estructura de la

clase. Una vez inicializados los Pods, se puede hacer uso de los métodos de registro de usuario,

inicio de sesión, escritura y lectura de datos, los cuales se pueden consultar respectivamente en la

documentación de desarrollador de Firebase [43].

54


11. Validación del prototipo

Para realizar la validación del prototipo se implementó el uso de casos de prueba con el fin de

analizar si los requisitos funcionales del software son parcial o completamente satisfactorios.

TABLA I. RESULTADOS DE CASOS DE PRUEBA

Id Prueba: CPRF-2 Prueba diseñada por: Juan Martín Jiménez

Título: Caso de prueba inicio de sesión. Prueba ejecutada por: Juan Martín Jiménez

Objetivo: el objetivo de este caso de prueba es

verificar que un usuario con correo electrónico y

contraseña válidos, pueda ingresas a la aplicación

móvil.

Fecha de la prueba: 30/05/2018

Prioridad: 0.8

Pre-condiciones: el usuario tiene un correo

electrónico y una contraseña válidos.

Dependencias:

Paso

#

Descripción Info. Necesaria Resultado

Esperado

Resultado Pasa/Pierde

1 Ingresar correo

electrónico.

Usuario:

[email protected]

No aplica. No aplica.

2 Ingresar

contraseña.

Contraseña:

password


3 Pulsar el botón

“Iniciar sesión”

Se espera que la

aplicación

muestre al

usuario la tareas

que le han sido

asignadas.

Pasa

55


Id Prueba: CPRF-1A Prueba diseñada por: Juan Martín Jiménez

Título: Registro de usuario organización. Prueba ejecutada por: Juan Martín Jiménez

Objetivo: el objetivo de este caso de prueba es

verificar que un usuario pueda registrarse

como usuario organización.


Prioridad: 0.8

Pre-condiciones: Dependencias:

Paso

#


Esperado


1 Ingresar nuevo

nombre de

usuario


2 Ingresar nuevo

correo

electrónico


3 Ingresar NIT de

la organización


4 Ingresar nueva

contraseña


5 Pulsar el botón

“Registrarme”

Se espera que la

aplicación

muestre al

usuario la

ventana de

proyectos vacía,

ya que es un

usuario nuevo.

Pasa

56


Id Prueba: CPRF-1B Prueba diseñada por: Juan Martín Jiménez

Título: Registro de usuario colaborador. Prueba ejecutada por: Juan Martín Jiménez

Objetivo: el objetivo de este caso de

prueba es verificar que un usuario pueda

registrarse como usuario colaborador.


Prioridad: 0.8

Pre-condiciones: debe existir al menos

un usuario de rol Organización.

Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado

Esperado


1 Ingresar nuevo

nombre de usuario


2 Ingresar nuevo

correo electrónico


3 Seleccionar un

usuario

Organización de la

lista de

organizaciones


4 Ingresar nueva

contraseña


5 Pulsar el botón

“Registrarme”

Se espera que la

aplicación muestre

al usuario la

ventana de tareas

vacía, ya que es un

usuario nuevo.

Pasa

57



Título: Caso de prueba creación de

proyecto.

Prueba ejecutada por: Juan Martín Jiménez


prueba es verificar que un usuario de rol

organización pueda crear un proyecto.


Prioridad: 0.9

Pre-condiciones: Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado

Esperado


1 Pulsar el botón

“Nuevo” en la

parte superior

derecha de la

ventana de

proyectos.

La aplicación debe

mostrar al usuario

un formulario para

la creación del

proyecto.

Pasa

2 Ingresar el

nombre del

nuevo proyecto


58


3 Seleccionar una

fecha de entrega

del proyecto.

La aplicación debe

permitir al usuario

pre visualizar la

fecha de entrega

que será asignada

para el proyecto

Pasa

4 Pulsar el botón

“Ok”

La aplicación debe

llevar al usuario a

la ventana de

proyectos, en el

cual se verá

reflejado el

proyecto recién

creado.

Pasa

59



Título: Caso de prueba creación de equipo. Prueba ejecutada por: Juan Martín Jiménez

Objetivo: el objetivo de este caso de prueba

es verificar que un usuario de rol

organización pueda crear un equipo de

trabajo


Prioridad: 0.7

Pre-condiciones: Existe un proyecto en el

cual crear el equipo.

Dependencias:

Paso

#


Esperado


1 Pulsar el

nombre del

proyecto en el

cual deseamos

crear el equipo,

en la ventana

de proyectos.

Se espera que la

aplicación lleve

al usuario a ver

el detalle del

proyecto

La aplicación mostró el detalle del

proyecto.

Pasa

2 Pulsar el botón

“Equipos” en la

parte inferior

derecha.

La aplicación

debe mostrar al

usuario la

ventana de

equipos del

proyecto.

Pasa

60


3 Pulsar el botón

“Nuevo”

ubicado en la

parte superior

derecha de la

ventana de

equipos.

La aplicación

debe mostrar al

usuario una

alerta con

opción de

respuesta para

ingresar el

nombre del

nuevo equipo

Pasa

4 Pulsar el botón

“Aceptar” de la

alerta.

Debe verse

reflejado en la

lista de equipos

del proyecto el

nuevo equipo

creado.

Pasa

61



Título: Caso de prueba asignar colaborador a

equipo.


Objetivo: el objetivo de este caso de prueba

es verificar que un usuario de rol

organización pueda asignar usuario de rol

colaborador a los equipos.


Prioridad: 0.8

Pre-condiciones: existe un equipo creado

para el proyecto y la organización cuenta con

usuarios colaboradores.

Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado

Esperado


1 Pulsar el nombre del

equipo en el cual

deseamos agregar el

colaborador, en la

ventana de equipos

del proyecto

La aplicación

debe mostrar el

detalle del

equipos es decir,

su nombre y sus

respectivos

integrantes.

Pasa

2 Seleccionar un

colaborador de la lista

de colaboradores

ubicada en el detalle

del equipo.


62


3 Pulsar el botón

“Agregar a equipo”

El usuario

agregado debe

verse reflejado

en la lista de

integrantes del

equipo.

Pasa

63




tareas.



prueba es verificar que un usuario de

rol organización pueda crear tareas

para los proyectos.


Prioridad: 0.9

Pre-condiciones: existe un proyecto en

el cual crear tareas.

Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado Esperado Resultado Pasa/Pierde

1 Pulsar el nombre

del proyecto en el

cual deseamos

crear la tarea, en

la ventana de

proyectos.

Se espera que la

aplicación lleve al

usuario a ver el

detalle del proyecto


proyecto.

Pasa

2 Pulsar el botón

“Backlog”

ubicado en la

parte inferior

central.

La aplicación debe

mostrar el detalle

del backlog,

número de tareas,

numero de tareas

terminadas, en

progreso y

pendientes, y una

lista con todas la

anteriores.

Pasa

64


3 Pulsar el botón

“Nuevo” ubicado

en la parte

superior derecha

de la ventana del

Backlog

Se espera que la

aplicación muestre

un formulario para

la creación de la

nueva tarea.

Pasa

4 Ingresar el

nombre de la

nueva tarea

No aplica No aplica

5 Ingresar la

descripción de la

nueva tarea

No aplica No aplica

6 Seleccionar un

encargado de la

lista de

colaboradores.

No aplica No aplica

7 Ingresar el

número estimado

de horas para

completar la tarea

No aplica No aplica

65


8 Pulsar el botón

“OK”

Se espera que la

aplicación muestre

una alerta diciendo

si la creación de la

tarea fue exitosa y

limpie los campos

para poder crear

otra tarea.

Pasa

9 Verificar que la

tarea esté ahora

reflejada en la

tabla de tareas del

“Backlog”

La aplicación debe

reflejar la nueva

tarea en la tabla de

tareas del

“Backlog”

Pasa

66




Sprint.



prueba es verificar que un usuario

de rol organización pueda crear un

sprint.


Prioridad: 0.7

Pre-condiciones: existe un proyecto

en el cual crear el sprint.

Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado Esperado Resultado Pasa/Pierde

1 Pulsar el

nombre del

proyecto en el

cual deseamos

crear el sprint,

en la ventana

de proyectos.

Se espera que la

aplicación lleve al

usuario a ver el

detalle del proyecto


proyecto.

Pasa

2 Pulsar el botón

“Sprints”

ubicado en la

parte inferior

central de la

ventana del

detalle del

proyecto.

La aplicación debe

mostrar al usuario el

detalle de los

Sprints, cuantos

creados y cuantos

cerrados y una lista

con todos.

Pasa

67


3 Pulsar el botón

“Nuevo”

ubicado en la

parte superior

derecha.

La aplicación debe

mostrar al usuario

un formulario para

la creación del

nuevo Sprint

Pasa

4 Ingresar el

nombre del

nuevo Sprint

No aplica No aplica

5 Elegir una

fecha en la

cual se cerrará

el Sprint

No aplica No aplica

6 Pulsar el botón

“Ok”

La aplicación debe

mostrar una alerta

que indique que el

Sprint fue creado

con éxito y el Sprint

debe verse reflejado

ahora en la lista de

Sprints del proyecto

en la ventana

“Sprints”

68



Título: Caso de prueba asignar tarea a

Sprint.




organización pueda asignar una tarea a

un Sprint.


Prioridad: 0.8

Pre-condiciones: debe existir una tarea

y un sprint.

Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado

Esperado


1 Pulsar el

nombre de la

tarea que

vayamos a

asignar al

Sprint en la

ventana del

“Backlog”

La aplicación

debe mostrar al

usuario el detalle

de la tarea.

Pasa

69


2 Pulsar el botón

“Asignar a

Sprint”

La aplicación

debe llevar a una

ventana en la

cual debemos

seleccionar el

Sprint al cual

vayamos a

agregar la tarea.

Pasa

3 Pulsar el botón

“Ok”

Se espera que la

aplicación

muestre al

usuario una

alerta

confirmando la

asignación

exitosa de la

tarea al Sprint y

debe verse

reflejada en la

lista de tareas

del Sprint

seleccionado.

Pasa

70


Id Prueba: CPRF-9 y CPRF-10 Prueba diseñada por: Juan Martín Jiménez

Título: Caso de prueba ver tareas,

reportar horas y cambiar de estado.




colaborador, pueda ver todas las tareas

que le han sido asignadas y a su vez

pueda reportar tiempo trabajado y

cambiar el estado de la tarea.


Prioridad: 0.9

Pre-condiciones: el usuario debe tener

tareas asignadas.

Dependencias:

Paso

#

Descripción Info.

Necesaria

Resultado

Esperado


1 Iniciar sesión

con los pasos

descritos en el

CPRF-2

Se espera que

la aplicación

muestre al

usuario la

tareas que le

han sido

asignadas.

71


2 Pulsar el

nombre de una

de las tareas

que le han

sido

asignadas.

La aplicación

debe mostrar

al usuario el

detalle de la

tarea.

Pasa

3 Seleccionar el

nuevo estado

de la tarea

No aplica No aplica

4 Pulsar el

botón

“Cambiar

estado”

La aplicación

debe mostrar

al usuario una

alerta que

confirme el

cambio

exitoso del

estado y debe

verse

reflejado el

cambio en el

detalle de la

tarea.

Pasa

72


5 Ingresar el

número de

horas que

desea reportar

como

trabajadas

La aplicación

debe mostrar

al usuario una

alerta que

confirme el

reporte

exitoso de las

horas

trabajadas y

debe verse

reflejado el

cambio en el

detalle de la

tarea.

Pasa

73


12. Conclusiones

La planeación y el gerenciamiento de proyectos de manera ágil es una tarea en conjunto,

donde todos los participantes deben tener claridad de las tareas pendientes y realizadas, esto

permite que cada vez más la tarea de trabajar en equipo sea agradable y con un mejor

rendimiento, crear equipos interdisciplinarios favorece la creatividad y el aprendizaje, ya

que las ideas de otros generan nuevas ideas en nosotros mismos y como consecuencia

obtendremos un producto innovador, el trabajo en equipos interdisciplinarios mezcla

fortalezas complementarias permitiendo así que cada individuo aporte sus talentos.

La metodología Scrum individualmente permite a las personas evaluar su productividad y

mejorar cada día, ya que en las tareas siempre existirá el versus entre las horas estimadas y

las horas de trabajo, lo que pensé que me demoraría versus lo que me demoré en el

cumplimiento de una tarea, algunas veces seré más rápido de lo que pensé y otras veces lo

contrario, pero siempre habrá un aprendizaje de por medio.

Gerenciar proyectos Scrum proporciona al proyecto flexibilidad y adaptación según las

necesidades del cliente y los cambios en el mercado, ya que en el Sprint Planning se puede

llegar a replantear una meta obedeciendo a los tipos de cambios mencionados

anteriormente. Ya que en cada iteración el equipo y el cliente trabajan juntos en la creación

de los requisitos del proyecto.

La implementación de Firebase dejó amplios horizontes para siguientes desarrollos de la

aplicación, ya que solo consumimos 2 de sus 10 recursos de desarrollo.

El desarrollo de aplicaciones en la IDE Xcode es agradable y su documentación es clara,

los errores en la consola son claros y específicos y el lenguaje de programación Swift ahora

es uno de mis favoritos.

74


13. Trabajos Futuros

Primera propuesta de trabajo

Enviar notificaciones al Scrum Master o cliente cuando uno de sus colaboradores reporte

horas trabajadas o cambie el estado en una tarea.

Implementar en las tablas, una forma de identificar el estado de las tareas, sin tener que

entrar al detalle de las mismas.

Implementar el Storage de Firebase para disminuir aún más el consumo de almacenamiento.

Implementar la utilidad Performance de Firebase para recibir información útil sobre el

rendimiento de la aplicación y sobre las latencias que experimentan los usuarios.

Verificación del correo electrónico.

Crear reportes gráficos para los avances de los proyectos, la productividad de los equipos

y la efectividad en los Sprints.

Implementar las notificaciones de Firebase para hacer notificaciones masivas, contando a

los usuarios las nuevas actualizaciones de la app.

Segunda propuesta de trabajo

Gamificación de la app, para esta propuesta se requiere investigar cómo se puede volver la app un

juego, brindar a los usuarios puntuaciones por buen cumplimiento de sus tareas y brindar algún

tipo de recompensa es algo que se nos ocurre en primera intención, pero como ya aclaramos es

algo que tiene que ser investigado para así no afectar la dinámica de la metodología.

75


Tercera propuesta de trabajo

Creación de “Agile Cards” siendo estas tarjetas en las que se describe una historia de usuario y se

va actualizando su estatus de forma física en un tablero con las columnas “Hecho, En progreso,

Por hacer”, dicho desarrollo constará de tarjetas con códigos QR que al tomar una foto actualizará

el status en la plataforma.

Cuarta propuesta de trabajo

Se propone hacer la versión para Android para generar un alcance mucho mayor a la solución

móvil.

76


Bibliografía

[1] I. Nonaka y H. Takeuchi, The New New Product Development Game, Cambridge,

Massachusetts, 1986.

[2] j. Sutherland, j. Scumniotales y . J. Mckenna, Scrum methodology of agile software

development, 1993.

[3] S. Alliance, «www.scrumalliance.org,» 2017. [En línea]. Available:

https://www.scrumalliance.org/ScrumRedesignDEVSite/media/ScrumAllianceMedia/Files

%20and%20PDFs/State%20of%20Scrum/2017-SoSR-Final-Version-(Pages).pdf. [Último

acceso: 15 Mayo 2018].

[4] FEDESOFT, «Informe de Caracterizacióndel Sector del Software de Colombia,» 2015.

[5] E. T. Noticias, «eltiempo.com,» 8 Noviembre 2017. [En línea]. Available:

http://www.eltiempo.com/tecnosfera/novedades-tecnologia/uso-del-celular-y-el-internet-

en-colombia-149384. [Último acceso: 2018 Abril 4].

[6] Velneo, «www.velneo.es,» 22 Julio 2015. [En línea]. Available: https://velneo.es/7-

motivos-de-fracaso-de-un-proyecto-de-software/. [Último acceso: 15 Mayo 2018].

[7] Trello, «trello.com,» 2017. [En línea]. Available: https://trello.com/about. [Último acceso:

12 Mayo 2018].

[8] J. Guynn, «latimesblogs.com,» Los Angeles Times, 2 Noviembre 2011. [En línea].

Available: http://latimesblogs.latimes.com/technology/2011/11/facebook-co-founder-

dustin-moskovitz-unveils-new-company-.html. [Último acceso: 13 Mayo 2018].

[9] Asana, «asana.com,» 27 Junio 2012. [En línea]. Available:

https://blog.asana.com/2012/06/asana-launches-inbox/. [Último acceso: 12 Mayo 2018].

[10] Wikipedia, «es.wikipedia.org,» 13 Noviembre 2017. [En línea]. Available:

https://es.wikipedia.org/wiki/Microsoft_Project. [Último acceso: 14 Mayo 2018].

[11] J. Garzás, «javiergarzas.com,» 2 Abril 2012. [En línea]. Available:

http://www.javiergarzas.com/2012/04/herramientas-scrum.html. [Último acceso: 16 Mayo

2018].

77


[12] Clipset, «www.clipset20minutos.es,» [En línea]. Available: https://clipset.20minutos.es/ios-

contra-android-quien-gana-la-batalla/. [Último acceso: 15 Mayo 2018].

[13] Alfatec, «www.alfatecsistemas.es,» 2017. [En línea]. Available:

https://alfatecsistemas.es/los-10-beneficios-la-metodologia-scrum/. [Último acceso: 12

Mayo 2018].

[14] D. L. S. Ciprian, «La Importancia de la gestión de proyectos,» 19 Junio 2012. [En línea].

Available: http://www.eoi.es/blogs/demostenesdelossantos/. [Último acceso: 2 Abril 2018].

[15] D. d. s. y. s. h. -. Usa, «www.cms.gov,» 27 MArzo 2008. [En línea]. Available:

https://www.cms.gov/Research-Statistics-Data-and-Systems/CMS-Information-

Technology/XLC/Downloads/SelectingDevelopmentApproach.pdf. [Último acceso: 15

Mayo 2018].

[16] K. Brito Acuña, «Eumed,» [En línea]. Available: http://www.eumed.net/libros-

gratis/2009c/584/Metodologias%20tradicionales%20y%20metodologias%20agiles.htm.

[Último acceso: 23 Mayo 2018].

[17] Wikipedia, «es.wikipedia.org,» 18 Agosto 2017. [En línea]. Available:

https://es.wikipedia.org/wiki/Desarrollo_%C3%A1gil_de_software. [Último acceso: 12

Mayo 2018].

[18] V. D. H. Jasper, «scrum.org,» [En línea]. Available: https://www.scrum.org/resources/what-

is-a-sprint-in-scrum. [Último acceso: 2 Abril 2018].

[19] M. G. Software Developers, «mountaingoatsoftware.com,» [En línea]. Available:

https://www.mountaingoatsoftware.com/agile/user-stories. [Último acceso: 2 Abril 2018].

[20] S. I. T:M, «scruminstitute.org,» [En línea]. Available: http://www.scrum-

institute.org/The_Scrum_Product_Backlog.php. [Último acceso: 2 Abril 2018].


https://www.mountaingoatsoftware.com/agile/scrum/scrum-tools/sprint-backlog. [Último

acceso: 2 Abril 2018].

[22] «dailyscrum.com,» [En línea]. Available: http://daily-scrum.com/scrum/sprint/planning-

meeting. [Último acceso: 3 Abril 2018].

78



https://www.mountaingoatsoftware.com/agile/scrum/meetings/daily-scrum. [Último


[24] S. A. Organization, «https://www.scrumalliance.org,» [En línea]. Available:

https://www.scrumalliance.org/community/articles/2014/april/key-elements-of-sprint-

retrospective. [Último acceso: 3 Abril 2018].

[25] A. Mezinsky, G. López y J. Palacio, «El manifesto ágil,» de Scrum Manager, 2016, pp. 9-

11.

[26] A. Mezinsky, G. López y J. Palacio, «Primera parte: Scrum Técnico,» de Scrum Manager,

2016, p. 16.

[27] A. Mezinsky, G. López y J. Palacio, «Primera Parte: Scrum Técnico,» de Scrum Manager,

2016, p. 17.

[28] A. Mezinsky, G. López y J. Palacio, «Primera Parte: Scrum Técnico,» de Scum Manager,

2016, p. 22.

[29] S. L. Group, «Scrum Roles,» de Guide to the Scrum Methodology, Simpli Learn, 2015, p. 5.

[30] O. A. Alliance, «agilealliance.org,» [En línea]. Available: https://goo.gl/aCsA7o. [Último


[31] S. L. Group, «Adressing the risk,» de Guide to the Scrum Methodology, Simpli Learn, 2015,

p. 19.

[32] C. IBM, de El desarrollo de aplicaciones móviles, web o híbridas, WildSphere, 2012, p. 2.

[33] M. Michán , «applesfera.com,» [En línea]. Available:

https://www.applesfera.com/aplicaciones-ios-1/cinco-razones-por-las-que-los-

desarrolladores-siguen-prefiriendo-ios-frente-a-android. [Último acceso: 3 Abril 2018].

[34] Wikipedia, «es.wikipedia.org,» 2016 Noviembre 13. [En línea]. Available:

https://es.wikipedia.org/wiki/Entorno_de_desarrollo_integrado. [Último acceso: 16 Mayo

2018].

[35] Wikipedia, «es.wikipedia.org,» 29 Marzo 2018. [En línea]. Available:

https://es.wikipedia.org/wiki/Xcode. [Último acceso: 12 Abril 2018].

79


[36] O. Williams, «thenextweb.com,» 2 Junio 2014. [En línea]. Available:

https://thenextweb.com/apple/2014/06/02/apple-announces-swift-new-programming-

language-ios/. [Último acceso: 19 Mayo 2018].

[37] Wikipedia, «wikipedia.com,» 21 Mayo 2018. [En línea]. Available:

https://es.wikipedia.org/wiki/Swift_(lenguaje_de_programaci%C3%B3n). [Último acceso:

23 Mayo 2018].

[38] Wikipedia, «es.wikipedia.org,» 11 Mayo 2018. [En línea]. Available:

https://es.wikipedia.org/wiki/Lenguaje_de_programaci%C3%B3n. [Último acceso: 30

Mayo 2018].

[39] A. Strategy an Business Design, «http://advenio.es,» [En línea]. Available:

http://advenio.es/modelo-de-negocio-y-el-cliente-mapa-de-empatia/. [Último acceso: 8

Abril 2018].

[40] Wikipedia, «es.wikipedia.org,» 26 Abril 2018. [En línea]. Available:

https://es.wikipedia.org/wiki/Especificaci%C3%B3n_de_requisitos_de_software. [Último

acceso: 29 Mayo 2018].

[41] Wikipedia, «es.wikipedia.org,» 24 Marzo 2018. [En línea]. Available:

https://es.wikipedia.org/wiki/Requisito_funcional. [Último acceso: 29 Mayo 2018].

[42] Wikipedia, «ws.wikipedia.org,» 13 Mayo 2018. [En línea]. Available:

https://es.wikipedia.org/wiki/Requisito_no_funcional. [Último acceso: 29 Mayo 2018].

[43] Firebase, «firebase.google.com,» [En línea]. Available: https://firebase.google.com/docs/.


[44] A. Dominguez, «projectmanagement.com,» 2017. [En línea]. Available:

https://www.projectmanagement.com/blog-post/31273/El-Estado-de-Scrum-2017-de-

Scrum-Alliance-. [Último acceso: 15 Mayo 2018].

[45] Wikipedia, 18 Mayo 2018. [En línea]. Available: https://es.wikipedia.org/wiki/C%2B%2B.


80


Glosario

Metodología ágil: metodologías utilizadas principalmente en el desarrollo de software con

estructuras distintas a las metodologías convencionales, con métodos de ingeniería del software

basados en el desarrollo iterativo e incremental, las cuales permiten flexibilidad al proyecto.

Software: conjunto de programas, instrucciones y reglas informáticas que permiten ejecutar

distintas tareas en una computadora.

Smartphone: teléfono celular con pantalla táctil, que permite al usuario conectarse a internet,

gestionar cuentas de correo electrónico e instalar otras aplicaciones y recursos a modo de pequeño

computador.

IDE: Un entorno de desarrollo integrado o entorno de desarrollo interactivo, en inglés Integrated

Development Environment (IDE), es una aplicación informática que proporciona servicios

integrales para facilitarle al desarrollador o programador el desarrollo de software.

Automatizar: aplicar procedimientos automáticos en la realización de un proceso.

Smart watch: Un smart watch es un reloj inteligente. La palabra, como tal, es un vocablo inglés

compuesto con las palabras smart, que significa 'inteligente', y watch, que traduce 'reloj',

comportándose de cierta forma a un celular inteligente, con algunas otras limitaciones.

Desarrollador: es aquella persona que escribe, depura y mantiene el código fuente de un programa

informático, es decir, el conjunto de instrucciones que ejecuta el hardware de una computadora,

para realizar una tarea determinada.

Usabilidad: Cualidad de la página web o del programa informático que son sencillos de usar

porque facilitan la lectura de los textos, descargan rápidamente la información y presentan

funciones y menús sencillos, por lo que el usuario encuentra satisfechas sus consultas y cómodo su

uso.

81


iOS: es un sistema operativo móvil de la multinacional Apple Inc. Originalmente desarrollado para

el iPhone (iPhone OS), después se ha usado en dispositivos como el iPod touch y el iPad.

App Store: es el marketplace de aplicaciones para usuarios de Apple, a través del cual miles de

desarrolladores de apps del mundo entero ofrecen sus productos y millones de usuarios pueden

descargar aplicaciones gratuitas o de pago.

Marketplace: es el lugar en la red donde se llevan a cabo acciones comerciales, igual que en la

plaza del mercado, pero a nivel virtual y online.

Aplicación Híbrida: las aplicaciones híbridas se desarrollan en lenguajes de programación para

web como HTML, CSS y JavaScript y por medio de algunos servicios como el de Adobe Phonegap

se compila para aplicativos móviles.

Compilar: en el caso del software hace referencia a pasar un programa escrito en lenguajes de

programación a lenguaje de máquina.

aplicación móvil en dispositivos ios para la gestión de

Documents