determinacion de oportunidades de sinergia y plan de...

DETERMINACION DE OPORTUNIDADES DE SINERGIA Y PLAN DE

RECOMENDACIONES PARA METODOLOGIAS DE DESARROLLO AGIL

ENFOCADO EN PRUEBAS PARA APLICACIONES DE DISPOSITIVOS

MOVILES

Maria Paula Lesmes Saenz

Weimar Pena Hernandez

Universidad Distrital Francisco Jose de Caldas

Facultad de Ingenieria

Ingenieria de Sistemas

Bogota, Colombia

2017

DETERMINACION DE OPORTUNIDADES DE SINERGIA Y PLAN DE

RECOMENDACIONES PARA METODOLOGIAS DE DESARROLLO AGIL

ENFOCADO EN PRUEBAS PARA APLICACIONES DE DISPOSITIVOS

MOVILES



Trabajo de grado presentado como requisito parcial para optar al tıtulo de:

Ingeniero(a) de Sistemas

Directora:

Lilian Astrid Bejarano Garzon MsC

Revisor:

Sandro Bolanos Castro PhD

Universidad Distrital Francisco Jose de Caldas

Facultad de Ingenieria

Ingenieria de Sistemas

Bogota, Colombia

2017

DEDICATORIA

“A mi mama quien me dio todo y gracias a ella soy una mejor persona cada dıa, a

mi familia por ser mi fuerza para estar donde estoy y a ti amor que me apoyaste en

todo momento.”


“Somos lo que los recuerdos nos ensenan, como los recuerdos nos forman.

Somos cada aprendizaje que queda en nuestro ser.

Somos las alegrıas y amor que nuestros seres queridos compartieron y comparten.

Somos parte de todos, como lo somos de un todo.

Somos y seremos todo lo que queramos ser.”


NOTAS DE ACEPTACION

Jurado

Jurado

Jurado

Jurado

Bogota D.C., Septiembre 2017

Tabla de Contenido

INTRODUCCION 1

I. CONTEXTUALIZACION DE LA INVESTIGACION 3

1. DESCRIPCION DE LA INVESTIGACION 5

1.1. Planteamiento/Identificacion del Problema . . . . . . . . . . . . . . . . . . . 5

1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.1. Objetivo General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2.2. Objetivos Especificos . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.3. Justificacion de la Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.4. Hipotesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5. Marco de Referencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5.1. Marco Teorico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.5.2. Marco Conceptual . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.6. Metodologıa de la Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.6.1. Tipos de Estudio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.6.2. Metodos de Investigacion . . . . . . . . . . . . . . . . . . . . . . . . . 20

1.6.3. Fuentes y Tecnicas para Recoleccion de Informacion . . . . . . . . . . 21

1.7. Organizacion del Trabajo de Grado . . . . . . . . . . . . . . . . . . . . . . . 22

1.8. Estudio de Sistemas Previos . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

x Tabla de Contenido

II. DESARROLLO DE LA INVESTIGACION 25

2. IMPORTANCIA DE LAS PRUEBAS EN APLICACIONES MOVILES 27

3. IDENTIFICACION DE FALENCIAS EN METODOLOGIAS EXISTENTES 32

4. MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES 34

4.1. Complemento por Parte del Equipo de Pruebas . . . . . . . . . . . . . . . . 34

4.2. Correlacion Entre Equipos y Pruebas por Ciclos . . . . . . . . . . . . . . . . 34

4.3. Procesos de Seleccion del Equipo de Trabajo . . . . . . . . . . . . . . . . . . 40

4.4. Mejoras a Curvas de Aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . 41

5. VENTAJAS DEL USO DE LAS MEJORAS PRESENTADAS 44

6. ANALISIS MATEMATICO DE LA IMPLEMENTACION DE LAS MEJORAS 47

III. CIERRE DE LA INVESTIGACION 49

7. CONCLUSIONES 51

7.1. Verificacion, Contraste y Evaluacion de los Objetivos . . . . . . . . . . . . . 51

7.1.1. Verificacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

7.1.2. Contraste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.1.3. Evaluacion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.2. Sıntesis del Modelo Propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 52

7.3. Aportes Originales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

8. PROSPECTIVA DEL TRABAJO DE GRADO 55

8.1. Lıneas de Investigacion Futura . . . . . . . . . . . . . . . . . . . . . . . . . . 55

8.2. Trabajos de Investigacion Futuros . . . . . . . . . . . . . . . . . . . . . . . . 55

BIBLIOGRAFIA Y REFERENCIAS WEB 57

Tabla de Contenido xi

IV. ANEXOS 59

.1. Anexo: Analisis Documental . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

.2. Anexo: Analisis Para Deteccion y Reporte Errores . . . . . . . . . . . . . . . 62

.2.1. Identificacion de un Error . . . . . . . . . . . . . . . . . . . . . . . . 62

.2.2. Elementos para el reporte de errores . . . . . . . . . . . . . . . . . . 65

Tabla de Ilustraciones

1-1. Metodologıas Tradicionales Vs Metodologıas Agiles . . . . . . . . . . . . . . 10

1-2. Metodologıa Scrum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1-3. Metodologıa MOBILE-D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1-4. Metodologıa TDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1-5. Metodologıa Espiral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1-6. Tipos de prueba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2-1. Play Store 25 de Enero 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2-2. Play Store 10 de Febrero 2017 . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2-3. Crecimiento exponencial de WhatsApp . . . . . . . . . . . . . . . . . . . . . 29

2-4. Version de pruebas WhatsApp . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4-1. Trabajo en equipo y apoyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4-2. Ciclos de pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

4-3. Tablero de trabajo (Tipo Scrum) . . . . . . . . . . . . . . . . . . . . . . . . 38

4-4. Niveles de seleccion del equipo de trabajo . . . . . . . . . . . . . . . . . . . . 41

4-5. Etapas de aprendizaje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

5-1. Reporte de errores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

5-2. Asignador de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

6-1. Documentacion Vs Vacıos funcionales . . . . . . . . . . . . . . . . . . . . . . 48

INTRODUCCION

Actualmente el auge de las tecnologıas y comunicaciones han traıdo consigo un incre-

mento exponencial de los dispositivos moviles y sus desarrollos, teniendo en cuenta que se

convirtio en parte fundamental el uso de dispositivos moviles se hizo necesaria la masificacion

de las aplicaciones moviles. Con esto, el crecimiento de las aplicaciones moviles trae consigo

problematicas en el ciclo del desarrollo al hacer infinito el proceso de desarrollo de software

por ser actualizacion tras actualizacion de aplicaciones mal controladas antes de su entrega

al usuario final.

El proyecto de recomendaciones para metodologıas de desarrollo agil enfocado en prue-

bas pretende dar solucion a tanta iteracion sobre los errores que reportan los usuarios finales

al mantener un control del proyecto desde las etapas iniciales con el fin de reducir costos

e iteraciones, trayendo beneficios tanto para todos los entes implicados desde el equipo de

desarrollo hasta el usuario final. Este proyecto se basa en una investigacion del ambito de

las pruebas en el desarrollo de aplicaciones para dispositivos moviles como tambien en las

experiencias que tienen tanto usuarios finales como el equipo que saca una aplicacion al

mercado.

Las caracterısticas principales del plan se concentran en implantar un modelo de prue-

bas en cada fase del proyecto donde se vean implicados cada uno de los participantes y esten

involucrados en el proceso, siendo ası una participacion continua partiendo de los requeri-

mientos hasta la entrega final dando como resultado procesos que eviten la iteracion continua

en errores y una entrega al usuario final en optimas condiciones.

2 Tabla de Ilustraciones

Este plan requiere de una guıa continua donde durante cada ciclo los integrantes puedan

reconocer que pruebas o elementos a revisar deben tener en cuenta para que la etapa sea

exitosa y se cumpla con unas metas trazadas desde el comienzo de cada fase, como se especi-

fica en las metodologıas agiles con las cuales se desarrollan las aplicaciones para dispositivos

moviles.

El interes en este tema nace de ver como los usuarios finales reportan error tras error

en los centros de descarga, mostrando que se liberan aplicaciones sin control de errores y

generando costos elevados a quienes publican las aplicaciones con el fin de mantener su

software y reputacion en los centros de descarga.

Parte I.

CONTEXTUALIZACION DE LA

INVESTIGACION

1. DESCRIPCION DE LA

INVESTIGACION

1.1. Planteamiento/Identificacion del Problema

El desarrollo de aplicaciones para dispositivos moviles y las metodologıas de desarrollo

de dicha tipologıa de aplicaciones estan enfocadas en un modelo agil, dado que las pruebas

solo se realizan en las ultimas etapas del proceso de software, es necesario plantear una nueva

propuesta donde las pruebas sean tenidas en cuenta en las distintas etapas e iteraciones del

proceso, trayendo consigo de esta manera, reduccion tanto en costos como de iteraciones del

proyecto. [1]

Teniendo en cuenta lo planteado y sumado a que las personas desconocen las meto-

dologıas de pruebas existentes, se disenara un plan de recomendaciones para metodologıas

de desarrollo enfocadas en pruebas que faciliten el proceso, el desarrollo agil del proyecto y

reduzca los costos del producto final al evitar el exceso de iteraciones.

Debido a la carencia de una nueva metodologıa o una mejora profunda de alguna ya

existente, seguiran existiendo proyectos llenos de actualizaciones y cambios en medio de la

exposicion al usuario; actualmente en muchas plataformas presentan gran cantidad de re-

portes de errores por parte de los usuarios finales, los cuales son los mas importantes en el

proceso ya que son ellos quienes reciben el producto final y esperan que sea un producto

optimo que cumpla con lo que requieren en el momento de utilizarlo.

6 1 DESCRIPCION DE LA INVESTIGACION

Se propone desarrollar una serie de recomendaciones las cuales ayuden a atenuar la

cantidad de errores comunmente encontrados en etapas finales del ciclo de vida de software,

con base en pruebas de software disenadas para cada etapa con procesos paralelos de diseno

y documentacion de las mismas incluyendo el analisis de la documentacion e inclusion en los

procesos de diseno de la plataforma con el fin de buscar oportunidades de sinergia en todo

el proceso.

1.2. Objetivos

1.2.1. Objetivo General

Formular un plan de recomendaciones para la metodologıa de desarrollo agil enfocada

en aplicaciones moviles que mediante el uso de pruebas induzcan la optimizacion del desa-

rrollo y reduccion de costos dentro del proyecto evidenciando sinergia en todo el proceso de

creacion de una aplicacion.

1.2.2. Objetivos Especificos

Crear nuevos procesos y plantillas de validacion funcionales, generando la inclusion de

pruebas en cada una de las fases del ciclo de vida del software partiendo de las re-

comendaciones dadas por el mercado, trayendo consigo un acompanamiento continuo

con el fin de reducir los errores en la etapa de finalizacion y entrega del software.

Demostrar que el uso de cada uno de los componentes del plan de recomendaciones

evidenciara la sinergia del proyecto, tomando como punto de referencia principal el

analisis de cada uno de los stakeholders, con el fin de mostrar que el sistema actua

mejor frente al medio.

1.3 Justificacion de la Investigacion 7

Facilitar a desarrolladores de aplicaciones para dispositivos moviles el uso de meto-

dologıas agiles mas robustas, con la inclusion de las recomendaciones en las etapas

del proyecto, mejorando la calidad de sus entregables y la percepcion de los usuarios

finales, brindando un apoyo al desarrollador emprendedor el cual desea publicar su

proyecto en las tiendas de aplicaciones.

1.3. Justificacion de la Investigacion

El presente trabajo tiene como objeto de estudio investigar una serie de recomenda-

ciones y ajustes basados en los estandares dados por el mercado en una metodologıa agil

usada para el desarrollo de aplicaciones moviles. Se pretende plantear un modelo teorico

basado en la relacion Calidad-costo-tiempo en los entregables e iteraciones a que de lugar la

aplicacion de dicho plan, lo cual permitira a los usuarios obtener mejores productos y a los

proyectos mayor calidad y organizacion en sus desarrollos sin tantas iteraciones ni errores.

Este plan de recomendaciones se disena con el proposito de ser implementado en desarrollos

y metodologıas agiles enfocadas principalmente en dispositivos Android y IOS, debido a que

la mayorıa de usuarios de aplicaciones moviles en sus dispositivos cuentan con estos sistemas

operativos y acceden a sus centros de descarga.

El resultado de la investigacion es un planteamiento teorico-practico que muestra las re-

comendaciones a seguir y los pasos a tener en cuenta para que estas surjan efecto. El caso de

estudio verifica la eficacia del planteamiento realizado por lo tanto se pretenderıa que fuera

implementado con una metodologıa agil en un prototipo de desarrollo y posteriormente que

se pueda aceptar y adaptar en otras metodologıas existentes.

La finalidad de la investigacion consistira en que los usuarios finales puedan obtener

mejores productos con menor cantidad de errores e iteraciones que los solucionen, ya que


no existe en la actualidad una metodologıa agil que lo pueda lograr con gran precision, sin

aumentar costos y tiempos de manera excesiva; para ello el plan debe ser adaptable y ma-

leable a los cambios que puedan existir entre las diferentes metodologıas existentes y con eso

convertirse en un plan mas general.

Los resultados se veran reflejados al final del caso de estudio cuando se haga la diferencia

de tiempo con datos comparativos del uso de las metodologıas actuales antes y despues del

uso del plan de recomendaciones. Esta tambien sera una solucion concreta a problemas socio-

economicos que permitiran mejorar la vida del micro empresario que intenta competir en

centros de descarga abarrotados de aplicaciones, en los cuales su oportunidad es que los

usuarios finales aprueben y califiquen sus aplicaciones entre los mas altos puntajes para que

esta sea llamativa a los demas usuarios.

1.4. Hipotesis

La generacion de nuevas ideas e inclusion de mejoras en los procesos, tal como lo son

optimizar las curvas de aprendizaje con estandares y guıas claras al interior del equipo, gene-

rar herramientas que apoyaran la seleccion de nuevos recursos y ayudar al equipo en obtener

un resultado agil de cada fase del ciclo de vida del software, implican que se realizara un

trabajo sincronizado, organizado, en total sinergia y estableciendo con ello la homeostasis

en el proyecto.

1.5. Marco de Referencia

1.5.1. Marco Teorico

Ingenierıa de software

La ingenierıa del software [1] es una disciplina de la ingenierıa que comprende todos los

aspectos de la produccion del software desde las etapas iniciales de la especificacion del sis-

1.5 Marco de Referencia 9

tema, hasta el mantenimiento de este despues de que se utiliza. En esta definicion existen

dos frases claves: Disciplina de la ingenierıa y Todos los aspectos de produccion de software.

En general, los ingenieros de software adoptan un enfoque sistematico y organizado en su

trabajo, ya que es la forma mas efectiva de producir software de alta calidad. Sin embargo,

aunque la ingenierıa consiste en seleccionar el metodo mas apropiado para un conjunto de

circunstancias, un enfoque mas informal y creativo de desarrollo podrıa ser efectivo para

algunas circunstancias.

El ciclo de vida de software como sistema

Un sistema se define como un conjunto de elementos interrelacionados que cumplen un

objetivo en el cual se tiene una entrada y salida, se encuentra inmerso en un medio, tiene

lımites ademas de tener caracterısticas propias como la sinergia, homeostasis y el holismo.

Es ası como el ciclo de vida de software puede verse como un sistema dentro del cual se

pueden determinar los diferentes elementos (como lo son los participantes dentro del proce-

so, la documentacion, los disenos, Etc.), la entrada que corresponde a los requerimientos del

cliente, la aplicacion como la salida del sistema y el objetivo de crear una aplicacion en medio

de un ambiente competitivo que crece diariamente debido a la expansion de las tecnologıas

moviles y la necesidad de los usuarios por tener aplicaciones estables y nuevas.

Pero como entran aquı las caracterısticas propias de un sistema, teniendo en cuenta que

la suma de las partes es mayor que el todo, se puede mostrar que la documentacion, las

pruebas, los disenos o lo demas por sı solo no son nada, y el todo se puede ver como la

aplicacion pero por debajo la suma de las partes anteriormente nombradas demuestran que

es una aplicacion estable es decir que el sistema es sinergico. Se puede decir que el sistema

es homeostatico por regularse a sı mismo y teniendo en cuenta que la idea es identificar los

errores para corregirlos antes de salir al usuario final se mostrara como se regula el sistema

sin necesidad de entes externos ya que el plan de pruebas dara las mejoras en procesos previos.


Por ultimo se podra decir que el holismo se presenta dentro de este sistema al mostrar al

observador (el usuario) la muestra de un solo sistema mientras que para un ente dentro del

sistema sentira cada una de las partes y las etapas del mismo.

Metodologıas agiles

Las metodologıas agiles, a diferencia de las metodologıas tradicionales, se componen de ca-

racterısticas importantes como lo son la flexibilidad en cuanto a ser adaptables a los equipos

y proyectos, y por ser ordenadas en cuanto a la determinacion de las tareas, fases y tiempos.

Cuando se trata de proyectos cortos se facilita el uso de estas metodologıas las cuales

toman un periodo corto de tiempo de 2 a 6 semanas aproximadamente en las cuales la co-

municacion con el cliente es constante, mostrando que el proyecto se convierte en una suma

de conocimiento de todos los participantes en el y genera que el proyecto sea adaptable para

poder soportar el constante cambio de requerimientos.

Ilustracion 1-1.: Metodologıas Tradicionales Vs Metodologıas Agiles

Fuente: Revision de metodologıas agiles para el desarrollo de software. [2]

Metodologıa SCRUM

Scrum es un marco de trabajo de procesos que ha sido usado para gestionar el desarrollo

de productos complejos desde principios de los anos 90. Scrum no es un proceso o una tecnica


para construir productos; en lugar de eso, es un marco de trabajo dentro del cual se pueden

emplear varias tecnicas y procesos. Scrum muestra la eficacia relativa de las practicas de

gestion de producto y las practicas de desarrollo, de modo que se pueda mejorar [3]

Ilustracion 1-2.: Metodologıa Scrum

Fuente: Why scrum? Why agile development? [4]

Metodologıa Mobile-D

Mobile-D es la metodologıa de VTT, Valtion Teknillinen Tutkimuskeskus, en ingles Tech-

nical Research Centre of Finland, para el desarrollo agil de software. Ademas del desarrollo

de software para moviles, es conveniente para los varios contextos, por ejemplo, la seguridad,

logıstica y aplicaciones de simulacion de productos. [5]


Ilustracion 1-3.: Metodologıa MOBILE-D

Fuente: MOBILE-D [5]

Se compone de distintas fases: exploracion, inicializacion, fase de producto, fase de esta-

bilizacion y la fase de pruebas. Cada una tiene un dıa de planificacion y otro de entrega.

En la fase de exploracion se centra la atencion en la planificacion y a los conceptos basicos

del proyecto. En la iniciacion se configura el proyecto identificando y preparando todos los

recursos necesarios, en la fase de producto se repiten iterativamente las subfases. Se usa el

desarrollo dirigido por pruebas, en la fase de estabilizacion en la que se realizan las acciones

de integracion para enganchar los posibles modulos separados en una unica aplicacion y la

fase de pruebas donde una vez parado totalmente el desarrollo se pasa una fase de validacion

hasta llegar a una version estable segun lo especificado en las primeras fases por el cliente.

Si es necesario se reparan los errores, pero no se desarrolla nada nuevo.[6]

Metodologıa TDD, Test Driven Development, Desarrollo Basado En Pruebas

Es una tecnica de programacion que consiste en escribir primero las pruebas, despues

escribir el codigo fuente que pase la prueba satisfactoriamente y, por ultimo, rehacer el

codigo escrito. Esta tecnica trae consigo un codigo mas robusto, mas seguro, mas mantenible

y una mayor rapidez en el desarrollo.


Ilustracion 1-4.: Metodologıa TDD

Fuente: Test Driven Development and Agile [7]

Metodologıa Desarrollo en Espiral para Moviles

Esta propuesta metodologica utiliza el modelo de desarrollo en espiral como base, e in-

corpora procesos de evaluacion de la usabilidad, priorizando la participacion del usuario en

todos los procesos del ciclo de vida de diseno, con el fin de garantizar un diseno centrado

en el usuario, aun cuando se trata de un modelo de proceso orientado a proyectos grandes y

costosos, ya que esta destinado a ser un modelo de reduccion de riesgos. [8]


Ilustracion 1-5.: Metodologıa Espiral

Fuente: Tema: Ingenierıa de Software I Modelos de desarrollo: espiral. [9]

Caracterısticas del Desarrollo de Aplicaciones Moviles

El desarrollo de aplicaciones moviles a diferencia del desarrollo convencional debe satisfacer

caracterısticas especiales como lo son:

Canal radio: la disponibilidad, las conexiones, la variabilidad del ancho de banda, la

heterogeneidad de redes o los riesgos de seguridad.

Movilidad: la migracion de direcciones o la gestion de la informacion dependiente de

localizacion.

Portabilidad: aquı difiere el tipo de equipo por su interfaz fısica como lo son tamano

de pantalla, procesador, RAM, etc.


Time-to-market: corresponde a los tiempos y requisitos para el lanzamiento de aplica-

ciones al mercado. [10]

Pruebas de Software

Las pruebas de software, testing en ingles, son los procesos que permiten verificar y revelar

la calidad de un producto software antes de su puesta en marcha [11]. Dichas pruebas pueden

clasificarse segun el enfoque como pruebas de caja blanca, el codigo, y pruebas de caja negra

donde se validan segun las funcionalidades que tenga el desarrollo es decir la entrada y salida

de datos sin importar el procesamiento interno de los datos.

Ilustracion 1-6.: Tipos de prueba

Fuente: Tema: Ingenierıa de Software I Modelos de desarrollo: espiral. [9]

Tipos o Categorıas de Pruebas

Dentro del ambito de las pruebas existen diferentes categorıas en las cuales se pueden

clasificar las pruebas dentro de las cuales se pueden seleccionar dependiendo de la aplicacion

desarrollada, a continuacion, se presentan los diferentes tipos con su propia definicion:

Unitarias: Se focaliza en ejecutar cada modulo.


Integracion: Identifica errores al combinar modulos probados unitariamente

Regresion: identifica si hay cambios tras una actualizacion o cambio en el desarrollo

Smoke: corresponde a una prueba del sistema de forma constante con poco esfuerzo

asegurando las pruebas unitarias

Sistema: se enfoca en el ingreso y procesamiento de los datos

Desempeno: asociadas al tiempo de respuesta y funcionalidad especifica del negocio

teniendo en cuenta el volumen normal o el maximo posible

Carga: maneja los tiempos de respuesta de una accion especıfica.

Stress: se relaciona especıficamente con casos bajo condiciones como memoria baja, sin

conexion al servidor, maximo numero de usuarios conectados, multiplicidad de acciones

con los mismos datos.

Volumen: corresponde con el maximo numero de usuarios ejecutando una misma accion

o multiples consultas en la base de datos.

Recuperacion: valida los procesos de recuperacion del sistema a partir de un fallo hasta

un estado deseado.

Compatibilidad: busca errores en la compatibilidad entre sistemas es decir por cambio

en exploradores, sistemas operativos, etc.

Seguridad: comprende los niveles de seguridad de la aplicacion frente al usuario y los

niveles de seguridad del sistema que corresponden al acceso.

Logica de negocio: se detalla que el sistema funcione como lo especifica el modelo de

negocio estipulado.

Flujos y navegacion: corresponde con todo lo que tiene que ver con interfaz grafica de

usuario (colores, posiciones, tamanos, funcionalidad de botones, campos, listas, etc.)


Configuracion: tiene que ver con el como funciona el sistema al realizar la instalacion

y configuracion para el funcionamiento de la plataforma.

Funcionales: corresponden con la integracion de las anteriores categorıas es decir que

tiene en cuenta el funcionamiento, el flujo de los datos, la navegacion y los resultados

obtenidos

Documentacion: corresponde con la evaluacion de la documentacion a entregar al

cliente.[11]

1.5.2. Marco Conceptual

A continuacion, se definiran los terminos que se usaron en la investigacion:

Metodologıa: Una metodologıa es una coleccion de procedimientos, tecnicas, herramien-

tas y documentos auxiliares que ayudan a los desarrolladores de software en sus esfuerzos

por implementar nuevos sistemas de informacion. Una metodologıa esta formada por fases,

cada una de las cuales se puede dividir en sub-fases, que guiaran a los desarrolladores de

sistemas a elegir las tecnicas mas apropiadas en cada momento del proyecto y tambien a

planificarlo, gestionarlo, controlarlo y evaluarlo.[12].

Prueba: Es una actividad en la que un sistema o un componente es ejecutado bajo condi-

ciones especificadas, los resultados son observados o registrados, y una evaluacion es realizada

de un aspecto del sistema o componente. [13].

Sinergia: Se define como la accion de dos o mas causas que generan un efecto superior

al que se conseguirıa con la suma de ambos en forma individual. Se le considera como la

integracion de partes o sistemas que conforman un nuevo elemento u objeto, dos elementos

que se unen y forman una sinergia ofrecen un resultado que amplıa las cualidades de cada

uno, ya que suelen mostrar y resaltar las cualidades del trabajo en equipo para realizar o

conseguir un mismo objetivo. [14]


Homeostasis: Es la caracterıstica de un sistema abierto o de un sistema cerrado o una

conjugacion entre ambos, mediante la cual se regula el ambiente interno para mantener una

condicion estable y constante. [15]

Planeacion de Pruebas: Es la etapa en donde se ejecutan las primeras actividades co-

rrespondientes al proceso de pruebas y tiene como resultado el plan de pruebas el cual debe

estar conformado por el Alcance, tipo de pruebas, estrategias y otros aspectos. Se puede

dividir en la planeacion realizada por el lıder de pruebas frente a todo el proyecto con una

propuesta macro y organizacion de las pruebas contra la planeacion de un analista que con-

siste en la estimacion de cada uno de las nuevas funcionalidades.

Defecto: Imperfeccion en un componente o sistema que puede causar que el componente o

sistema falle en desempenar las funciones requeridas. Se puede interpretar como las falencias

detectadas en ambientes de calidad o pruebas.

Falla: Es la discrepancia visible que se produce al ejecutar un programa con un defecto,

el cual es incapaz de funcionar correctamente. Se puede interpretar como las falencias detec-

tadas por el usuario final.

Error de software: Accion humana que produce un resultado incorrecto. Se puede in-

terpretar como las falencias detectadas en ambientes de desarrollo.

Usuario: Es la persona que utiliza el software o hardware despues de que ha sido com-

pletamente desarrollado, comercializado, e instalado.

Aplicacion: Es un programa de software que se ejecuta en el ordenador, navegadores

web, programas de correo electronico, procesadores de texto, juegos y utilidades son todas

las aplicaciones. La palabra “aplicacion” se utiliza porque cada programa tiene una aplica-


cion especıfica para el usuario.

Tiendas de aplicaciones: Hace referencia a los mercados de aplicaciones existentes como

AppStore, PlayStore o Windows Store Marketplace.

Aprendizaje por intuicion: Comprende el analisis realizado por las experiencias del

usuario y su posterior aprendizaje de dichas experiencias, por ejemplo: tocar una tecla de un

piano y entender que genera un sonido. Gracias a dicho proceso permite al usuario interpre-

tar las diferentes circunstancias del entorno, como dice Wolfgang Kohler: “el aprendizaje se

produce debido a una captacion repentina o subita de relaciones del problema, es decir por

intuicion o discernimiento. Supone una interrelacion de conductas e informacion, es decir,

el sujeto llega subitamente a la solucion mediante una reorganizacion del campo perceptivo,

capta, internaliza o comprende, una “verdadrevelada.”

Requerimiento: Descripcion detallada del funcionamiento a desarrollar, tambien se pue-

de comprender como las caracterısticas necesarias para el funcionamiento del software.‘

Requerimientos Funcionales: Comprende la definicion del comportamiento, entradas

y salidas de uno o varios de los componentes del software.

Requerimientos No Funcionales: Corresponde a los requerimientos que no implican

actividad con la informacion a guardar o funciones del software, es decir conciernen a carac-

terısticas de funcionamiento, por eso suelen denominarse Atributos de calidad. Como lo son

Rendimiento, disponibilidad, accesibilidad, usabilidad, estabilidad, portabilidad, entre otros.


1.6. Metodologıa de la Investigacion

1.6.1. Tipos de Estudio

La investigacion ha llevado a hacer una aproximacion por primera vez al conocimiento

del problema, dado que las metodologıas agiles han sido una interesante forma de abarcar

las distintas soluciones planteadas en forma de aplicaciones moviles lo cual es relacionado

con el plan de mejoras a implementar para generar un producto estable y optimo.

Para la implementacion de un plan de recomendaciones para metodologıa de desarrollo

agil enfocado en pruebas para aplicaciones de dispositivos moviles y la sostenibilidad del

desarrollo, el tipo de estudio que mejor se ajusta a la investigacion es el correlacional; ya que

este tiene el proposito de medir el grado de relacion que existe entre 2 a mas conceptos o

variables, y en la investigacion las principales variables son: los usuarios, las aplicaciones y las

metodologıas entre otras, donde se van a interrelacionar para su respectivo funcionamiento.

Se hace una recopilacion de tipo teorica. Este trabajo puede servir como antesala a la

ampliacion conceptual del plan de recomendaciones planteado o la implementacion en otros

tipos de metodologıas de desarrollo a usar. El problema abarca comportamientos de tipo

social y empresarial de una colectividad como lo son los desarrolladores o proyectos los cuales

su nicho de negocio sean las aplicaciones moviles, debido a que la baja calidad en las primeras

iteraciones de las aplicaciones puede generar un impacto negativo en el comportamiento de

los usuarios como por ejemplo rechazos y crıticas que muestren la inconformidad de las

personas y perdida de potenciales usuarios.

1.6.2. Metodos de Investigacion

Para el proceso de investigacion de una determinacion de oportunidades de sinergia y

plan de recomendaciones para metodologıa de desarrollo agil enfocado en pruebas para apli-

caciones de dispositivos moviles se utilizara el metodo inductivo, dado que se va a aplicar

conceptos previamente analizados en el marco teorico y se va a implementar en el entorno del

1.6 Metodologıa de la Investigacion 21

problema de investigacion, utilizando para ello una muestra de desarrollo de una aplicacion

movil y verificar su acogida en las tiendas de aplicaciones.

Basados en que existen estandares y metodologıas ya aprobados se utilizara la investi-

gacion descriptiva, con proposito de analizar los procesos actuales y determinar mejoras a

los problemas comunes de los equipos de pruebas junto con los demas equipos del proceso

del software.

1.6.3. Fuentes y Tecnicas para Recoleccion de Informacion

En el proceso de investigacion como referencias primarias se usaron el libro virtual “A

timeline: the evolution of testing tolos” el cual corresponde a un resumen realizado por va-

rios expertos en pruebas de software publicado por ThoughtWorks en el ano 2014; tambien

se utilizo la tesis de grado “Estado del arte y tendencias en Test-Driven Development” de

Carlos Fontanela de la Universidad Nacional de La Plata [16]. En el cual hace un completo

analisis de TDD y del desarrollo agil.

La tecnica para el proceso investigativo comprende tanto la experiencia vivida tras tra-

bajar como analistas de calidad, tambien la colaboracion con otros companeros que manejan

la creacion de aplicaciones moviles, ademas de ello se incluye un proceso de observacion de

creacion de las mismas aplicaciones con el fin de tener el analisis completo de los errores

cometidos al utilizar metodologıas agiles sin tener en cuenta las pruebas.

Para la creacion del plan de mejoras se basan en las metodologıas agiles existentes junto

con la amplia variedad de estandares y conceptos de pruebas los cuales no se encuentran

unificados pero junto con listas de chequeo se planteara como realizar las pruebas o cuales

pueden hacer parte del proyecto.

En el proceso de aplicacion se utilizan herramientas como Testlink y Mantis en los cuales

se plantean las diferentes etapas del desarrollo, en cuanto a la generacion de las listas de


chequeo y el estado del proyecto se realizara en Bitrix24 la cual es una herramienta que esta

disenada para organizar las etapas de un proyecto agil y Trello que corresponde a un tablero

para la visualizacion de las tareas y estados de las mismas.

1.7. Organizacion del Trabajo de Grado

El trabajo se dividira en cinco capıtulos dentro de los cuales se analizaran la impor-

tancia, falencias, posibles mejoras y ventajas de las pruebas de software para dispositivos

moviles. Adicional a ellos se adiciona un analisis matematico del porque la documentacion

se convierte en parte primordial del proceso de creacion y mantenimiento del software.

1.8. Estudio de Sistemas Previos

Se realiza una revision bibliografica referente al plan de recomendaciones metodologıas

de pruebas expuestas en el presente proyecto en los marcos tanto teorico como conceptual,

ası mismo se revisa el contenido y desarrollo de la Manifiesto por el Desarrollo agil de Soft-

ware [17] donde exponen lo siguiente:

Los “Metodos agiles” surgen como alternativa a las metodologıas formales (CMMI,

SPICE) las cuales se caracterizaban por ser extensas por su caracter normativo y fuerte

dependencia de planificaciones detalladas previas al desarrollo. Se denomina Manifiesto agil

al documento compuesto por los siguientes postulados:

A los individuos y su interaccion, por encima de los procesos y las herramientas

El software que funciona, por encima de la documentacion exhaustiva.

La colaboracion con el cliente, por encima de la negociacion contractual.

La respuesta al cambio, por encima del seguimiento de un plan.

1.8 Estudio de Sistemas Previos 23

Teniendo en cuenta que aunque hay valor en los elementos de la derecha, valoramos

mas los de la izquierda. De estos postulados nacen todas las metodologıas agiles y se tienen

extensos trabajos donde se analiza una a una.

Tambien se revisa el contenido de Trabajo Final de Especializacion en Ingenierıa de

Software: Estado del arte y tendencias en Test-Driven Development de Carlos Fontanela

donde explica con claridad la importancia de las pruebas de software teniendo en cuenta que

la “TDD es una tecnica que combina pruebas, especificacion y diseno en una unica actividad

holıstica”, y que tiene como objetivo acortar los ciclos de desarrollo con caracterısticas como

una regresion completa.

En este caso en particular se presentan diferentes tipos de TDD con diferentes carac-

terısticas segun la necesidad o enfoque de quien determine la metodologıa a utilizar sin

embargo no se tiene una TDD integrada la cual aplique para todas las etapas del proyecto

e involucre a cada uno de los equipos(requerimientos, pruebas y desarrollo). El conocimien-

to e investigacion dieron resultado al analisis anterior que termina especificando de forma

practica los tipos de TDD y su forma de aplicacion mas sencilla.

Aunque se tienen extensas propuestas del uso de pruebas en las diferentes metodologıas

y por otro lado analisis y mejoras a las metodologıas agiles, se detecta que no se tienen en

cuenta la compatibilidad entre dichos analisis.

Parte II.

DESARROLLO DE LA

INVESTIGACION

2. IMPORTANCIA DE LAS PRUEBAS

EN APLICACIONES MOVILES

Desde los modelos de desarrollo en cascada hasta las ultimas metodologıas agiles, se ha

visto un crecimiento de las pruebas de software que terminan correspondiendo a un proceso

de control de cada una de las etapas del software para generar objetivos con mayor calidad

y confiabilidad frente a lo realizado. Las pruebas de software en el desarrollo de cualquier

tipo de aplicacion corresponde a un proceso fundamental en la produccion del mismo, por

ello al realizar una aplicacion movil se hacen necesarias para los resultados que requiere el

usuario final.

Para una aplicacion movil se intensifican la cantidad de pruebas por existir diferentes

dispositivos, sistemas operativos, dimensiones de pantalla, herramientas de los equipos, entre

otros; lo cual muestra que para realizar una aplicacion movil no se debe depender de una

sola tecnologıa sino debe ser adaptable. Dadas estas caracterısticas en el desarrollo de las

pruebas, puede definirse objetivos segun cada una de las etapas del proyecto donde se debe

tener en cuenta la tipologıa de pruebas.

Las pruebas garantizan el exito de la aplicacion debido a que la percepcion del usuario

final corresponde a las valoraciones positivas o negativas de la aplicacion, lo cual asegura

una respuesta asertiva del publico. Por ejemplo una aplicacion con suficientes calificaciones

positivas aseguran el aumento de descargas de la misma, resultando una bola de nieve de

descargas y calificaciones, como se puede ver en las siguientes ilustraciones se ve la relacion:

28 2 IMPORTANCIA DE LAS PRUEBAS EN APLICACIONES MOVILES

Ilustracion 2-1.: Play Store 25 de Enero 2017

Fuente: Play Store. Yu-Gi-Oh! Duel Links [18]

Ilustracion 2-2.: Play Store 10 de Febrero 2017

Fuente: Play Store. Yu-Gi-Oh! Duel Links [18]

29

Aunque no se puede afirmar que esta situacion suceda con todas las aplicaciones, otro

ejemplo claro de como las calificaciones positivas de una aplicacion puede resultar en un

aumento excesivo de descargas, como se muestra en la siguiente imagen se evidencia el au-

mento de la aplicacion WhatsApp en los ultimos anos.

Ilustracion 2-3.: Crecimiento exponencial de WhatsApp

Fuente: ¿Vale WhatsApp 14.000 millones? [19]

Es tanta la versatilidad y el uso de pruebas para esta aplicacion que se abrieron gru-

pos de pruebas Beta, es decir pruebas de limitados usuarios finales los cuales descargan la

aplicacion para validar su comportamiento antes de ser masificada a los demas usuarios.

Dichas pruebas se pueden realizar con tan solo permitir a Play Store la monitorizacion de

30 2 IMPORTANCIA DE LAS PRUEBAS EN APLICACIONES MOVILES

las acciones sobre la aplicacion y la descarga temprana de la aplicacion que estara disponible

tras la aceptacion de terminos y condiciones dictados por Play Store.

Ilustracion 2-4.: Version de pruebas WhatsApp

Fuente: WhatsApp Messenger [20]

El uso de pruebas funcionales generaran un resultado positivo en cuanto a lo que espera

el usuario de la aplicacion sin importar como se vea, dado que estas consisten en realizar el

analisis de errores susceptibles al usuario que se relacionen con la especificacion funcional y

los objetivos principales de la aplicacion.

Las pruebas de compatibilidad para dispositivos moviles corresponden al modulo de

pruebas mas largo debido a la cantidad de dispositivos con caracterısticas diferentes en las

cuales la aplicacion debe adaptarse. Los diferentes procesadores, dimensiones de pantalla,

accesos a componentes como acelerometros, camaras, memoria, entre otros, generan la ne-

cesidad de probar en al menos tres dispositivos con caracterısticas diferentes para dar la

fiabilidad de la aplicacion. Estas pruebas se vuelven tan importantes como las pruebas de

compatibilidad ya que si la aplicacion solo funciona en un tipo especıfico de dispositivo limita

el mercado para la aplicacion representando crıticas por el funcionamiento sesgado.

En cuanto a la correcta validacion entre las pruebas funcionalidad y las de compa-

tibilidad se llegan a realizar pruebas de rendimiento donde se ve una composicion de las

pruebas nombradas representando que el sistema puede soportar caracterısticas mınimas y

31

dar respuesta a las necesidades del desarrollador frente a los requerimientos mınimos y ajus-

tes posibles en la aplicacion. Con todo esto, se puede comprobar que una aplicacion con

mayor cantidad de pruebas y filtros antes de salir al publico junto con una muy buena idea,

representan el exito que se espera de la aplicacion.

3. IDENTIFICACION DE FALENCIAS

EN METODOLOGIAS EXISTENTES

Actualmente para el desarrollo de aplicaciones moviles se utilizan diferentes metodo-

logıas agiles, las cuales bajo el uso de desarrollos rapidos generan versionamientos rapidos

que incluyen mejoras de seguridad y adicion de modulos con nuevas funcionales con el fin de

tener una aplicacion activa en el mercado generando mayor expectativa en el usuario final,

el problema de ello es que aunque esten de moda y sea lo que mas se utilice contienen varias

falencias como las que se nombraran a continuacion.

Una de las mayores falencias de las metodologıas agiles es que todos los integrantes

del grupo de trabajo deben conocer de dicha metodologıa y estar dispuestos a cumplir con

los tiempos pactados para ello, desde que se disena hasta que se prueba. Este conocimiento

cooperativo genera dependencia dentro del proyecto por las curvas de aprendizaje, es decir

un nuevo integrante en un proyecto que use una metodologıa agil puede generar retrasos de

una o dos semanas segun el acople del nuevo integrante.

Los tiempos de retraso pueden representar la estabilidad de la plataforma, y si se tiene

en cuenta la metodologıa escogida se puede aumentar los riesgos en la plataforma por la

adaptacion de un nuevo integrante tanto en el equipo como con los vacıos funcionales frente

a la ejecucion de la misma. Por ejemplo en Scrum se necesita de tiempo en reuniones cortas

diarias y si existe un nuevo integrante puede que este no comprenda por completo dichas

reuniones por lo tanto la informacion estara dividida y comprendera vacıos frente al resto

33

del equipo. Un integrante del equipo sin el conocimiento de la aplicacion de la metodologıa

agil implica que se tendran demoras porque correspondera con una mala aplicacion de la

metodologıa.

Otra de las fallas detectadas corresponde a la falta de documentacion debido a que los

tiempos de documentacion y diseno son muy cortos frente a la cantidad de iteraciones y la

velocidad con la cual se genera cada una de las actualizaciones de la aplicacion. Ademas de

esto se debe tener en cuenta que el uso de una metodologıa agil implica la menor inclusion

posible de personal en el proyecto para limitar los desacuerdos, preguntas y retrasos.

Tambien se puede encontrar que en la etapa de pruebas, por las falencias descritas ante-

riormente, no se realiza una correcta identificacion de escenarios y tipos de pruebas a realizar

segun las etapas presentes dentro del proyecto, las pruebas no se encuentran estandarizadas

ya que dependen del analisis realizado por el analista.

4. MEJORAS ENFOCADAS EN

PRUEBAS PARA METODOLOGIAS

AGILES

Entre las mejoras posibles a realizar, teniendo en cuenta que no debe importar el tipo

de metodologıa agil que se escoja y que existen factores de acoplamiento mayores segun tipo

de metodologıa seleccionada, se encuentran las citadas a continuacion:

4.1. Complemento por Parte del Equipo de Pruebas

Aunque las metodologıas enfocadas en pruebas ya hacen uso de esto, se debe hacer un

enfasis en la inclusion de los analistas de calidad o pruebas dentro de todas las fases del

proyecto con el fin de dar otro punto de vista dentro de este. El acompanamiento continuo

del equipo de calidad generara una mayor cohesion dentro del proyecto por el grado de

pertenencia del equipo y el analisis colectivo durante el proceso de analisis y desarrollo. Con

esto se muestra que generacion de dudas tempranas y la contemplacion de casos de prueba

previos al desarrollo complementan el ciclo de vida de cada una de las iteraciones posibles.

4.2. Correlacion Entre Equipos y Pruebas por Ciclos

Cada uno de los stakeholders deben comprometerse dentro del proyecto debido a que

con el uso de diferentes perspectivas, la aclaracion de requerimientos y el sentido de per-

tenencia en el proyecto presentan mejoras de comunicacion en el equipo. La aplicacion de

4.2 Correlacion Entre Equipos y Pruebas por Ciclos 35

estas mejoras se puede presentar comenzando por la formacion de equipos de trabajo cola-

borativo entre ramas de especializacion, una vez conformados los equipos de requerimientos,

desarrollo y pruebas, se constituyen alianzas estrategicas entre los mismos.

El equipo de requerimientos tendra un acompanamiento constante del lıder de desarro-

llo para que este ayude a dimensionar los alcances de cada uno de las funcionalidades del

software solicitados y del lıder de pruebas para valorar la capacidad de respuesta del equipo,

debido a que no constituye lo mismo un requerimiento que corresponda un cambio de color

contra la inclusion de un nuevo modulo.

Una vez terminadas las primeras reuniones del analisis, la composicion de la docu-

mentacion debera complementarse con un analista de pruebas capacitado, el cual realizara

analisis adicionales sobre el requerimiento para la deteccion de vacıos o dudas previas a la

publicacion de la documentacion al desarrollador y la posterior entrega de la funcionalidad

desarrollada. Esto no solo traera complementos a la documentacion y desarrollo sino tambien

se complementara el proceso de pruebas al tener analisis de posibles escenarios de pruebas,

particularidades de la funcionalidad y posibles enfoques del equipo dando continuidad al

equipo en el proceso.

Con la deteccion de posibles escenarios, el desarrollador tendra un enfoque claro y un

complemento al analisis inicial dado en la documentacion como en cada una de las reuniones

de la metodologıa, podra realizar un bosquejo mas rapido a la entrega completa de la docu-

mentacion con la determinacion previa de los escenarios de prueba y con ello la realizacion de

pruebas previas para la deteccion de errores en los diferentes dispositivos por adaptabilidad

de los mismos.

El acompanamiento constante en pruebas al equipo de requerimientos complementa el

proceso documental y da cabida al analisis como usuario final, precisando y aclarando el

impacto que un cambio puede tener para dichos usuarios conllevando al analisis del mer-

36 4 MEJORAS ENFOCADAS EN PRUEBAS PARA METODOLOGIAS AGILES

cado, acaba con los tiempos muertos de pruebas mientras culmina el desarrollo dando un

nuevo punto de vista de los posibles escenarios o particularidades posibles en el desarrollo

de un futuro requerimiento completan el ciclo dando continuidad al equipo y haciendo de

este un sistema holıstico. Como complemento se pueden tener en cuenta que con analisis

adicionales de pruebas beta de la plataforma serviran encontrar incidentes previos a salidas

de produccion.

Ilustracion 4-1.: Trabajo en equipo y apoyo

Fuente: Los Autores


La ventaja de la inclusion constante de los diferentes equipos es el cambio del enfoque

individual de las metodologıas agiles dentro de las cuales y en cada una de sus reuniones

implican un particionamiento del proceso a eventos individuales, todo esto impactara parte

de los equipos en el inicio del ciclo por implicar mas tiempos de discusion pero reduciran

notablemente los tiempos de respuesta esperados en una metodologıa agil por la claridad de

las funcionalidades requeridas.

Ilustracion 4-2.: Ciclos de pruebas

Fuente: Los Autores


El posible desconocimiento de los tipos de pruebas a utilizar en el desarrollo de una

aplicacion puede evitarse con el uso de filtros para conocer el tipo de pruebas a realizar, sin

importar el tipo de aplicacion (juegos, comunicacion, otros) los filtros presentados a conti-

nuacion corresponden a las pruebas basicas a tener en cuenta en el momento de la creacion

de una aplicacion movil.

Teniendo en cuenta que al utilizar metodologıas agiles se utilizan ciclos de desarrollo en

los cuales el ciclo inicial corresponde a un prototipo, solo se realizaran pruebas funcionales

con el fin de validar las funcionalidades esperadas en la version inicial. En los ciclos siguientes

se tienen en cuenta las pruebas de funcionalidad para validar nuevos desarrollos y las pruebas

no funcionales como compatibilidad con el fin de validar que los cambios realizados no se

vean afectados en los diferentes dispositivos, esto incluye pruebas en diferentes tamanos de

dispositivos, marcas, versiones de sistema operativo, entre otros.

Ilustracion 4-3.: Tablero de trabajo (Tipo Scrum)

Fuente: Trello.com - Proyecto: Los Autores

Para las ultimas etapas se tienen en cuenta pruebas unitarias las cuales corresponden

a las pruebas especıficas sobre los elementos afectados, pruebas no funcionales para validar


que los cambios no representen cambios visuales o de rendimiento en diferente hardware y

adicionalmente pruebas de regresion para validar que los cambios realizados no afecten las

funcionalidades existentes.

Para conocer el estado de cada una de las funcionalidades o requerimientos se pueden

tener en cuenta herramientas como Trello en las cuales mediante la creacion de tarjetas se

pueden validar las tareas pendientes y adicionar comentarios por parte de todos los partici-

pantes del proceso.

Si no se tiene claridad de las pruebas a realizar, se pueden tener en cuenta las listas de

chequeo del anexo 1 con las cuales se puede determinar las pruebas a realizar incluyendo los

analisis a realizar cuando se apoya el proceso documental. Al encontrar un NO en cualquiera

de las listas de chequeo se debera entrar a analizar la correccion por el equipo correspondiente.

Dependiendo del tipo de aplicacion (Juegos, comunicacion, navegacion, productividad,

entre otros) se podran realizar mas tipos de pruebas como las listadas a continuacion con

las cuales se realizaran analisis mas profundos sobre el funcionamiento de la aplicacion.

Pruebas de acciones del usuario: comportamiento de la aplicacion ante distintas

acciones como tocar, arrastrar, rotar, extender los dedos, cerrar los dedos, etc.

Pruebas de usabilidad y accesibilidad: corresponden a la validacion de la Presen-

tacion de la informacion en el diseno de pagina para moviles, Facilidad para completar

tareas, Eficiencia y exactitud, y Integracion de aplicaciones nativas, aplicaciones web

movil e hıbridas.

Pruebas de localizacion: prueban el desempeno de la aplicacion cuando el dispositivo

movil esta en movimiento.

Pruebas de compatibilidad: Sirven para probar el desempeno de la aplicacion al

conectarse a las redes en distintos protocolos y distintas condiciones, por ejemplo:

Wi-Fi, Bluetooth, Red analogica (3G o 4G).


Pruebas de seguridad: Su finalidad busca validar la resistencia de la aplicacion a

ataques maliciosos, como por ejemplo: ataques vıa la red, ataques al servidor, ataques

al dispositivo, entre otros.

4.3. Procesos de Seleccion del Equipo de Trabajo

Dado que la aplicacion de una metodologıa agil implica que cada uno de los participantes

tenga el conocimiento de la misma, se recomienda que antes de comenzar un proyecto bajo

alguna metodologıa agil se realice un adecuado proceso de seleccion de los participantes para

ello deben tener en cuenta los siguientes parametros:

Conocimiento de la metodologıa agil a utilizar.

Conocimiento tecnico en el area a ejercer (requerimientos, desarrollo y pruebas).

Experiencia en el area a ejercer (requerimientos, desarrollo y pruebas).

Experiencia en trabajo en equipo.

Al ser un proceso de seleccion se deben realizar examenes para validar los conocimientos,

los cuales contribuiran a la categorizacion de los participantes. Los parametros correspon-

dientes a conocimiento nombrados se deben medir mediante porcentajes segun la siguiente

categorizacion.

4.4 Mejoras a Curvas de Aprendizaje 41

Ilustracion 4-4.: Niveles de seleccion del equipo de trabajo

Fuente: Los Autores

En cuanto a la experiencia sera cuantificable entre la cantidad de tiempo, tareas desem-

penadas y referencias entregadas por las personas referenciadas en la hoja de vida, ademas

de un analisis completo realizado en entrevistas.

Bajo las premisas anteriores, es ideal que los lıderes de las areas comprometidas tengan

un nivel alto cercano al 99 %, teniendo en cuenta que nunca se llega a un 100 % de conoci-

miento por las actualizaciones del mercado, con el fin de lograr una alta cohesion entre los

lıderes. Con respecto a los demas participantes del proyecto, se necesita como mınimo un

nivel medio de conocimiento debido a que es uno de los requerimientos mınimos para el uso

de las metodologıas agiles, ademas de una alta capacidad para el trabajo en equipo.

4.4. Mejoras a Curvas de Aprendizaje

Como cualquier proyecto no se pueden asegurar la continuidad del equipo, por lo tanto

se deben manejar protocolos de aseguramiento del conocimiento incluidos en cada uno de

los ciclos o semanas de desarrollo siendo por cada iteracion una nueva inclusion a una par-

ticularidad del proceso. A continuacion se presenta la propuesta de inclusion al equipo de

trabajo para integrantes nuevos en etapas avanzadas del proyecto.


Ilustracion 4-5.: Etapas de aprendizaje

Fuente: Los Autores

Ciclo uno: En la primera semana se espera que por interaccion de la aplicacion se com-

prendan comportamientos basicos y con el equipo comience la correcta relacion tanto laboral

como de relacion con el equipo, con esta relacion establecida se fortalecera el equipo y hara

mas sencilla la generacion de dudas.

Ciclo dos: Tras intentar realizar un acercamiento intuitivo a la aplicacion, se podra com-

pletar el conocimiento junto con la lectura del funcionamiento de la aplicacion. Con el fin de

no malgastar el tiempo de los participantes del proyecto se espera que las dudas presentadas

en el ciclo se resuelvan inmediatamente.

Ciclo tres: Tras tener el conocimiento basico de la aplicacion, podra ingresar a las reunio-

nes de seguimiento para conocer el futuro de la aplicacion, ademas de esto se asignaran tareas

basicas para comenzar la alineacion dentro del equipo(Analista de requerimientos: analisis

funcional inicial complementado por el analista lıder, Analista de pruebas: analisis de crea-

cion de casos de prueba y ejecucion de casos de prueba sencillos, Analista de desarrollo:

inclusion en desarrollos pequenos y adaptacion de otros desarrollos, documentacion de codi-

go por la comprension (lectura) del mismo.

Ciclo cuatro: Corresponde a la ultima semana de acople al equipo dentro de esta ya

se realizara la asignacion normal como a cualquier miembro del equipo, podra participar

activamente de las reuniones y dar puntos de vista.

Lo anterior se considera con el fin de tener en cuenta que al ingresar un nuevo inte-

4.4 Mejoras a Curvas de Aprendizaje 43

grante al equipo, sin importar la tarea a realizar, hay curvas de aprendizaje las cuales en

los proyectos avanzados implican desgaste del tiempo de los demas integrantes por tiempos

en capacitaciones, resolucion de preguntas, acoplamiento al equipo, entre otros. La solucion

a esto se plantea bajo el uso de etapas de inclusion de las personas al equipo en el menor

tiempo posible y sincronizadamente con los ciclos de desarrollo de la aplicacion, teniendo

en cuenta que dicha inclusion aplica cuando ya se tienen equipos consolidados que traba-

jan sobre la aplicacion y el nuevo integrante cumple con los requisitos del perfil bajo las

calificaciones dadas en el anterior numeral. Bajo esto se considera que el nuevo integrante

tendra la capacidad de asumir responsablemente el aprendizaje por intuicion y asociacion

dando oportunidad a explorar requerimientos funcionales, identificando pequenos errores que

al ser persistentes los analistas con mas tiempo en el proyecto se omiten, y no funcionales

del software, como la usabilidad o eficiencia, demostrando como un posible usuario final se

entenderıa con la aplicacion.

5. VENTAJAS DEL USO DE LAS

MEJORAS PRESENTADAS

Las ventajas actuales del uso de una metodologıa agil implican la satisfaccion del clien-

te al verse involucrado a lo largo del proyecto, el conocimiento del estado del proyecto por

todos los miembros del equipo y evidencias de la eficiencia por implicar un menor intervalo

de tiempo en una version funcional del producto. Con el uso de las mejoras descritas ante-

riormente se lograran cambios aun mas significativos en el momento de la creacion de una

aplicacion movil.

La eficiencia inherente en el uso de una metodologıa agil se ve mejorada con el uso

del plan descrito, evidenciando un alto nivel de cohesion en el equipo con el cual las tareas

se veran mejor equilibradas, para lo cual se realizara una distribucion de las tareas en una

mayor cantidad de personas en el equipo con diferentes enfoques, limitando ası la aparicion

de espacios sin productividad y eventuales problemas en el desarrollo los cuales incluyen

tiempos muertos y contradicciones por vacıos funcionales.

Al evitar tiempos muertos la aplicacion se tendra lista en menor tiempo por lo cual el

cliente se encontrara mas satisfecho y este al estar incluido en cada uno de los ciclos encon-

trara a satisfaccion el producto final entregado.

El uso de las listas de chequeo del anexo “Analisis documental” simplificara las tareas

de analisis del equipo de pruebas en cuanto al proceso de apoyo documental y junto con el

45

anexo “analisis para deteccion y reporte de errores” el cual apoyara tanto la deteccion de

errores como permitira a los integrantes del equipo de pruebas generar la mayor cantidad

de insumos para el equipo de desarrollo y simplificar las tareas del mismo. Adicionalmente

intenta ayudar el equipo de desarrollo al entregar la mayor cantidad de informacion posible

de los errores. Con el uso de herramientas de reporte de errores como Bugzilla o Mantis

(Open Source) se puede visualizar la aplicacion de las mejoras planteadas como por ejemplo

la ilustracion 5-1 la cual corresponde a un formulario de reporte de errores.

Ilustracion 5-1.: Reporte de errores

Fuente: MantisHub - Proyecto: Los Autores

46 5 VENTAJAS DEL USO DE LAS MEJORAS PRESENTADAS

Con el uso de estas herramientas se pueden simplificar el reporte de errores y con ello

hacer mas simple para el desarrollador la solucion de este, adicionalmente se tiene la traza-

bilidad del error al tener asignada la persona la cual se encuentra solucionando el error o el

vacıo funcional.

En cuanto a la mejora de la comunicacion entre todos los equipos se tienen herramien-

tas de trabajo como Bitrix24 dentro de las cuales se puede llevar el control del estado del

proyecto, la asignacion de tareas, el reporte de las tareas realizadas por persona, creacion de

canales de comunicacion, entre otras, y con el uso de estas tener un mayor control y enfoque

de las tareas.

Ilustracion 5-2.: Asignador de tareas

Fuente: Bitrix24 - Proyecto: Los Autores

Con la asignacion de tareas tambien se puede llevar el control de la curva de aprendizaje

de los nuevos integrantes ası como el registro de los indicadores del estado del proyecto.

6. ANALISIS MATEMATICO DE LA

IMPLEMENTACION DE LAS

MEJORAS

Si se tiene en cuenta esto las pruebas realizadas a una funcionalidad pueden verse

desenfocadas porque al no existir informacion concreta y documentada las pruebas seran

dependientes de la interpretacion del analista mas no dependientes de la verdadera funcio-

nalidad del modulo, en pocas palabras se plantea la siguiente ecuacion:

E ≈ D∗VR

Donde R corresponde a la cantidad de requerimientos o funcionalidades que se entrega-

ran en la version de la aplicacion, D corresponde al porcentaje de documentacion entregado,

V corresponde a la cantidad de vacıos o preguntas documentales y la E son los posibles

defectos encontrados en la ejecucion por el analista. Esto quiere decir que existe mayor po-

sibilidad de defectos si se entrega menor cantidad de documentacion porque existiran mayor

cantidad de preguntas para una menor cantidad de requerimientos.

48 6 ANALISIS MATEMATICO DE LA IMPLEMENTACION DE LAS MEJORAS

Ilustracion 6-1.: Documentacion Vs Vacıos funcionales

Fuente: Los Autores

Teniendo en cuenta que como nombra la ISQTB “un error introduce un defecto y un

defecto causa un fallo” la ecuacion anterior solo es la prueba de la importancia en la calidad

con la que se realizan los analisis tanto en el proceso documental como en los demas procesos

del ciclo de vida del software.

Parte III.

CIERRE DE LA INVESTIGACION

7. CONCLUSIONES

7.1. Verificacion, Contraste y Evaluacion de los Objetivos

7.1.1. Verificacion

La aplicacion de los objetivos planteados demuestra que el uso de listas de chequeo com-

plementa el proceso de identificacion de error y simplifican la tarea del equipo de pruebas en

especial de los nuevos integrantes del equipo agrupando y clasificando los hallazgos segun su

tipologıa, que junto con el proceso de curva de aprendizaje conlleva a plantear nuevas ideas

para lograr una mejor transicion de ingreso al equipo en un corto plazo de tiempo.

Es posible verificar que la constante interaccion entre los equipos de requerimientos

y pruebas genera una notable disminucion de reporte de vacıos o inquietudes funcionales,

ademas del acompanamiento en el proceso de afinamiento de los insumos del desarrollo,

entregando la documentacion completa de la plataforma, por lo cual se evidencia una re-

duccion en costos de los recursos del proyecto, disminuye la cantidad de desarrollos erroneos

inherentes a fallas en la especificacion de soluciones y de manera paralela la revalidacion de

los errores. Tambien impacta de manera positiva al proyecto la interrelacion constante del

equipo de pruebas con el equipo de desarrollo debido a que ayuda a la resolucion oportuna

de los errores o ajustes no planeados.

52 7 CONCLUSIONES

7.1.2. Contraste

Dado el manejo que se le otorga a la documentacion dentro de las metodologıas agiles y

aunque va en contra de sus principales postulados, es posible denotar que la documentacion

se convirtio en punto focal para identificar los errores, definir claramente el funcionamiento

correcto de la aplicacion y su dedicacion. La documentacion clara y tipificada de los errores

genera organizacion y sinergia dentro de los procesos del proyecto y evidencia dentro del

balance final del proceso el impacto positivo en el costo de cada etapa.

7.1.3. Evaluacion

Los objetivos propuestos se cumplieron gracias a la creacion de los nuevos procesos y

plantillas, con los cuales fue posible facilitar dentro del equipo de trabajo la socializacion de

errores, brindando el apoyo constante por parte del equipo de pruebas a todos los stakehol-

ders. Con esto poder demostrar que el desarrollo agil de aplicaciones moviles que posean

un proceso mas claro, que en lo posible genere la mınima cantidad de iteraciones gracias a

los ajustes en documentacion, genera un equipo de trabajo acoplado que interactua en un

estado dinamico, es decir, como un sistema, a su vez lograr una robusta clasificacion de las

tareas, se evidenciara la sinergia del equipo.

7.2. Sıntesis del Modelo Propuesto

El objetivo principal de este trabajo de grado es la propuesta de un plan de recomen-

daciones para la optimizacion y mejora continua de una metodologıa agil con enfasis en

pruebas, esta basado principalmente en el uso de listas de chequeo y se apoya en su meto-

dologıa practica que genera cohesion con el analista de pruebas, lo cual aprovecha aun mas

sus capacidades beneficiando el proceso completo. Los proyectos hoy en dıa estan limitados

en el enfoque del set de pruebas a ejecutar, generando con esto deficiencias notables en los

entregables de cada fase del ciclo de vida del software y evidenciando retrasos y extra costos

muy comunes en la industria del desarrollo de aplicaciones moviles, tambien provocan re-

procesos, dependencias y perdidas de conocimiento dentro de los recursos del personal del

7.2 Sıntesis del Modelo Propuesto 53

proyecto dada la baja documentacion y fallas en los procesos ejecutados sobre cada equipo

de trabajo que interviene en la construccion del software final.

Los interrogantes para la investigacion que surgen para proponer el Plan de recomenda-

ciones, se refieren al analisis del ciclo de vida del software, y posterior estudio de la eficiencia

del proceso y la rentabilidad/esfuerzo, a efectos de identificar los factores crıticos de exito,

como tambien la experiencia que entrega la industrias. De la percepcion del analista de prue-

bas y en general los demas stakeholders del proyecto que trabajan con ellos, se definiran las

condiciones a considerar para la implementacion o mejora del Plan propuesto.

Este trabajo de grado se ha desarrollado de acuerdo a las pautas de la investigacion

exploratoria, y, por tanto, es de tipo cualitativa. La principal fuente de informacion primaria

son la experiencia recogida dentro del mercado y las entrevistas a analistas de pruebas con

trayectoria en el mercado de desarrollo de aplicaciones moviles, ingenieros de sistemas con

roles funcionales y de lıderes tecnicos, gerentes, y los conocimientos adquiridos por observa-

cion, principalmente de la manera de pensar del analista de pruebas, quien conoce el trabajo

diario, su impacto y los reprocesos comunes que la metodologıa tradicional obliga y no es

flexible. Ası mismo, se realizaron validaciones del modelo sobre productos del mercado de

aplicaciones moviles y en general sobre el comportamiento del ciclo de vida del software,

respetando las caracterısticas intrınsecas del sistema actual y los beneficios atractivos para

las necesidades de un nicho de mercado creciente e importante en la actualidad. Su verifica-

cion estuvo respaldada por la ejecucion de pruebas de forma escalonada teniendo en cuenta

la estabilidad de la aplicacion, mediante la prueba de concepto del producto, sostenida en

base al conocimiento de expertos de mercado y demanda del proyecto. El proyecto debe

estar pendiente de validar los conocimientos de los integrantes del equipo, nuevos o antiguos,

con el objetivo de generar equipos de trabajo solidos, directamente impactando de manera

positiva al proyecto y asegurando el proceso de aprendizaje para nuevos integrantes con los

procesos establecidos.

54 7 CONCLUSIONES

Finalmente, el presente proyecto sugiere considerar la implementacion del Plan de reco-

mendaciones, como base para que se planteen futuras investigaciones respecto de los factores

crıticos de exito: forma de asociatividad y cohesion entre los stakeholders del proyecto, de-

bera dirigirse a metodologıas de cualquier tipo y con inclusion de nuevos equipos dentro de

las etapas de desarrollo del software.

7.3. Aportes Originales

Dentro de los aportes que se plantean y ejecutan, se aporta las listas de chequeo enfo-

cadas e influenciando directamente el mejoramiento de las curvas de aprendizaje, debido a

que normalmente las empresas no tienen en cuenta estos procesos los cuales pueden incurrir

en disminucion del trabajo para los integrantes del equipo que entran a apoyar el proceso

de capacitacion y socializacion del conocimiento, disminuyendo las tareas en la asignacion

de los antiguos integrantes del equipo ya que se deben nivelar las actividades y entre ellas

adicionar los apoyos prestados para las explicaciones. Por ello se convierte en un aporte ori-

ginal e importante para el proyecto teniendo en cuenta que la curva de aprendizaje como se

plantea en lo expuesto contempla un aprendizaje por intuicion, asociacion y profundizacion,

en ese orden generando un impacto positivo en todo el equipo de trabajo.

8. PROSPECTIVA DEL TRABAJO DE

GRADO

8.1. Lıneas de Investigacion Futura

Las mejoras propuestas estan dirigidas a metodologıas agiles enfocadas en ciclos, para

futuras investigaciones puede dirigirse a metodologıas de cualquier tipo y con inclusion de

nuevos equipos dentro de las etapas de desarrollo del software.

8.2. Trabajos de Investigacion Futuros

Como trabajos futuros de investigacion se proponen los siguientes:

Aplicacion de las mejoras a otros tipos de metodologıas

Inclusion de nuevos equipos colaboradores en el desarrollo con determinacion de listas

de chequeo para su comportamiento holıstico.

Replanteamiento de las metodologıas agiles basados en el manifiesto agil pero contem-

plando los tiempos y necesidades de los clientes actuales.

Crear una herramienta tecnologica para la deteccion de errores basado en listas de

chequeo

Crear una herramienta tecnologica para soporte a las curvas de aprendizaje en el

desarrollo agil.

BIBLIOGRAFIA Y REFERENCIAS WEB

[1] I. Sommerville. Ingenierıa del software, 2010.

[2] A. Navarro, J. Fernandez, and J. Morales. Revision de metodologıas agiles para el

desarrollo de software., 2013.

[3] S. Ghosh. Systemic comparison of the application of evm in traditional and agile softwa-

re project. urlhttp://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-ES.pdf.

[4] Why scrum? why agile development? urlhttp://calvinx.com/2014/05/22/why-scrum-

why-agile-development.

[5] Mobile-d. urlhttp://agile.vtt.fi/mobiled.html.

[6] Metodos aplicables para el desarrollo de aplicaciones moviles.

urlhttp://www.genbetadev.com/desarrollo-aplicaciones-moviles/metodos-aplicables-

para-el-desarrollo-de-aplicaciones-moviles.

[7] Kristine. Test driven development and agile. urlhttp://www.boost.co.nz/blog/2012/05/test-

driven-development-and-agile/, 2012.

[8] A. Nosseir, D. Flood, R. Harrison, and O. Ibrahim. Mobile development process spiral,

2012.

[9] Tema: Ingenierıa de software i modelos de desarrollo: espiral.

urlhttp://www.aprenderaprogramar.com/foros/index.php?topic=2144.0/.

58 BIBLIOGRAFIA Y REFERENCIAS WEB

[10] J. Blanco, J. Camarero, A. Fumero, A. Werterski, and P. Rodriguez. Me-

todologıa de desarrollo agil para sistemas moviles introduccion al desa-

rrollo con android y el iphone. urlhttp://www.adamwesterski.com/wp-

content/files/docsCursosAgile doc TemasAnv.pdf.

[11] Tipos de pruebas de software. urlhttp://ing-sw.blogspot.com.co/2005/04/tipos-de-

pruebas-de-software.html.

[12] D. Avison and G. Fitzgerald. Information system development., 2006.

[13] Instituto de Ingenieros Electricos y Electronicos. (IEEE Computer Dictionary. Soft-

ware Engineering Terms. 1990). Ieee 610-1990. urlhttp://web.fi.uba.ar/˜cfonte-

la/Fontela EstadoDelArteTDD UNLP EIS.pdf, 1990.

[14] Introduccion a la teorıa general de sistemas, 2004.

[15] O. Johansen Bertoglio. Capıtulo 3. iagp 2005/06. metodologıas usadas en ingenierıa del

software. urlhttp://www.um.es/docencia/barzana/IAGP/Iagp3.html, 2005.

[16] C. Fontanela. Trabajo final de especializacion en ingenierıa de software estado

del arte y tendencias en test-driven development. urlhttp://web.fi.uba.ar/˜cfonte-

la/Fontela EstadoDelArteTDD UNLP EIS.pdf, 2011.

[17] K. Beck, M. Beedle, A. Bennekum, A. Cockburn, W. Cunningham, M. Fowler,

J. Grenning, J. Highsmith, A. Hunt, R. Jeffries, J. Kern, B. Marick, R. Mar-

tin, S. Mellor, K. Schwaber, J. Sutherland, and D. Thomas. Manifiesto agil.

urlhttp://www.agilemanifesto.org.

[18] Play store. yu-gi-oh! duel links. urlhttps://play.google.com/store/apps/details?id=jp.konami

.duellinks&hl=es.

[19] ¿vale whatsapp 14.000 millones? urlhttp://economia.elpais.com/economia/2014/02/20/

actualidad/1392907095 894321.html.

[20] Whatsapp messenger. urlhttps://play.google.com/apps/testing/com.whatsapp.

BIBLIOGRAFIA Y REFERENCIAS WEB 59

[21] Metodologıasagiles en el desarrollo de aplicaciones para dispositivos movi-

les. Estado actual. urlhttp://www.uelbosque.edu.co/sites/default/files /publicacio-

nes/revistas/revista tecnologia/volumen12 numero2 /12Articulo Rev-Tec-Num-2.pdf

[22] Garrido Cordoba, J. TFC Desarrollo de aplicaciones moviles.

urlhttp://openaccess.uoc.edu/webapps/o2/bitstream/ 10609/18528/6/ jugarrido-

coTFC0113memoria.pdf, 2013

[23] Gasca, M. AND Camargo, L AND Medina, B. Metodologıa para el desarrollo de apli-

caciones moviles. urlhttp://www.scielo.org.co/pdf/tecn/v18n40/v18n40a03.pdf, 2013

[24] ISO/IEC/IEEE 29119 Software Testing Standard. urlhttp://in2test.lsi.uniovi.es/gt26

/#presentacion, 2015

[25] Pruebas Unitarias para Haskell. urlhttp://osl2.uca.es/wikihaskell/index.php/ Prue-

bas Unitarias para Haskell, 2015

[26] End user Definition. urlhttp://techterms.com/definition/enduser

[27] La importancia de las pruebas en dispositivos moviles.

urlhttps://www.globetesting.com/2012/08/pruebas-en- dispositivos-mviles/, 2012

[28] Que son las metodologıasagiles y su aplicacion en el mercado actual.

urlhttp://www.uv.es/capgeminiuv/documents/Capgemini Charla Agile UV.pdf,

2016

Parte IV.

ANEXOS

.1 Anexo: Analisis Documental 63

.1. Anexo: Analisis Documental

La tabla a continuacion presenta los elementos basicos para la validacion de la docu-

mentacion

SI NO Observaciones

1. Se encuentra clara la funcionalidad descrita

2. Se describen los elementos afectados con los

cambios

3. Describe el alcance de la funcionalidad

4. Contiene el objetivo de la funcionalidad

5. Se presentan los mockups de la interfaz

6. Encontro inconsistencias en el documento

64

.2. Anexo: Analisis Para Deteccion y Reporte Errores

Teniendo en cuenta que para la identificacion de los errores se debe realizar segun la

categorıa del error acontinuacion se exponen las tablas de principal uso para el equipo de

pruebas.

.2.1. Identificacion de un Error

La siguiente tabla tiene como objetivo entregar la mayor cantidad de informacion posible

al equipo de desarrollo

SI NO Observaciones

1. El error bloquea el flujo

de la funcionalidad

2. El error cambia la interfaz

grafica definida inicialmente

Si la respuesta es Si se debe a un cambio

en los componentes o frente a la compati-

bilidad de los equipos

3. El error depende del dis-

positivo en el cual se realiza

la prueba

Si la respuesta es Si se debe a un error de

compatibilidad del equipo, por la pantalla

o por temas de rendimiento del equipo

4. El error corresponde a

un comportamiento no re-

producible facilmente

Si la respuesta es Si puede analizarse co-

mo cache, respuesta de memoria, rendi-

miento, o funcionalidades compuestas no

contempladas

5. El error corresponde a

un comportamiento no do-

cumentado

De ser ası debe reportarse el vacıo docu-

mental al equipo de requerimientos con el

fin de evitar esfuerzos al equipo de desa-

rrollo

Las siguientes tablas tienen como objetivo entregar la mayor cantidad de informacion

posible al equipo de desarrollo segun el tipo o categorıa del error.

.2 Anexo: Analisis Para Deteccion y Reporte Errores 65

Categorıa: Funcional

SI NO Observaciones

1. El comportamiento corresponde con lo defi-

nido documentalmente

2. Permite realizar el flujo completo de la fun-

cionalidad

3. Se puede realizar configuraciones de la fun-

cionalidad desde otra funcionalidad

Si la respuesta es Si con-

testar los numerales deri-

vados

3.1 Permite realizar la configuracion previa

3.2 La configuracion realizada se encuentra apli-

cada correctamente sobre la funcionalidad prin-

cipal

3.3 Al eliminar la configuracion previa se per-

mite el flujo normal de la funcionalidad

Categorıa: Compatibilidad

SI NO Observaciones

1. La aplicacion se adapta al tamano de la pan-

talla

2. La aplicacion se adapta a la orientacion de la

aplicacion

3. La aplicacion permite el despliegue del tecla-

do sin danar la distribucion de los componentes

de la interfaz

4. Se permite el acceso a la aplicacion y su na-

vegacion en diferentes versiones de sistema ope-

rativo

66

Categorıa: Rendimiento

SI NO Observaciones

1. Se puede realizar la navegacion correctamente

sobre un dispositivo de gama baja


sobre un dispositivo de gama media


sobre un dispositivo de gama alta

4. Permite el ingreso de llamadas, visualizacion

de notificaciones sin afectar la navegacion

5. Permite realizar la navegacion sobre la apli-

cacion mientras se encuentren en uso otras apli-

caciones

6. Permite la navegacion en la aplicacion con

baja capacidad de memoria

7. Permite la navegacion en la aplicacion para

versiones de sistema operativo antiguas

.2 Anexo: Analisis Para Deteccion y Reporte Errores 67

.2.2. Elementos para el reporte de errores

Corresponde a los elementos mınimos a entregar al equipo de desarrollo.

SI NO Observaciones

1. Contiene el resumen completo del error

2. Se describen los pasos completos para la re-

produccion del error

3. Se adjuntan los registros generados por la

aplicacion(trazabilidad de los mensajes servidor

aplicacion, bitacora de acciones, etc.)

Registros no visibles de

cara al usuario

4. Se ajuntan las pantallas correspondientes al

error y son congruentes con los pasos del error

determinacion de oportunidades de sinergia y plan de...

Documents