Technical note

Ficha del Artículo [=]

Compartir (Ô_Ô)

Desarrollo Móvil:
prototipo para la gestión de socios basado en la metodología D3A

 

Chalub, Maximiliano
Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura,
Universidad Nacional del Nordeste. Corrientes, Argentina
maximilianochalub@gmail.com


Mariño, Sonia I.
Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura,
Universidad Nacional del Nordeste. Corrientes, Argentina
simarinio@yahoo.com


Alfonzo, Pedro L.
Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura,
Universidad Nacional del Nordeste. Corrientes, Argentina.
plalfonzo@hotmail


Godoy, Maria V.
Departamento de Informática. Facultad de Ciencias Exactas y Naturales y Agrimensura,
Universidad Nacional del Nordeste. Corrientes, Argentina.
mvgodoy@exa.unne.edu.ar

 

Resumen

La Industria del Software promueve el uso de métodos, herramientas y estándares. El desarrollo aplicaciones móviles difiere del ciclo de vida tradicional del software por lo que se requiere del estudio y elección de metodologías específicas para construir Apps. En este trabajo se ilustra la aplicación de la metodología D3A para la construcción de una App para la gestión de socios, y se exhiben los resultados derivados del primer incremento.


Palabras Clave: tecnologías móviles, métodos, Apps

 

Mobile development:
prototype for partner management based on D3A methodology

Abstract

Software Industry promotes the use of methods, tools and standards. Mobile application development differs from the life cycle of traditional software, so it requires the study and selection of specific methodologies in order to build Apps. In this paper the application of the D3A methodology for building an App for managing partners is illustrated, also the results from the first increase are shown.


Key-words: mobile technologies, methods, Apps

Introducción

La Informática se compone de nueve disciplinas, siendo una de ellas la Ingeniería del Software (IS). Menciona como elementos clave los métodos, las herramientas, y los procedimientos que facilitan el control del proceso de desarrollo del software y brinda a los desarrolladores las bases de calidad de una forma productiva ([18], [22]).

Asociaciones profesionales como la IEEE Computer Society [13] y la Association for Computing Machinery [3] han aunado sus trabajos y desarrollaron una guía del Cuerpo de Conocimientos de la Ingeniería de Software (SWEBOK) [23].

La guía SWEBOK V3.0 [5] presenta actualizaciones en todas las áreas de conocimiento (KAS-por sus siglas en inglés-) a fin dereflejar los cambios en la Ingeniería de Software, previamente publicados en la guía SWEBOK 2004.

SWEBOK, 2015 expone 15 áreas del conocimiento: Requisitos de Software, Diseño de software, Construcción de software, Pruebas de software, Mantenimiento del software, Gestión de la Configuración de Software, Gestión de Ingeniería de Software, Proceso de Ingeniería de Software, Modelos de Ingeniería de Software y Métodos, Calidad del software, Ingeniería de Software Práctica Profesional, Economía Ingeniería de Software, Fundamentos de computación, Fundamentos matemáticos, Fundamentos de ingeniería.

El área Ingeniería de Procesos de Software, aborda la definición de procesos, de ciclo de vida del software, la evaluación y mejora de procesos de software, la medición del software, y herramientas de la ingeniería de proceso de software.

En la propuesta que se expone se abordan las tecnologías móviles comprendidas enel área de conocimiento identificada como Ingeniería de Procesos de Software, específicamente en los ciclos de vida del software. La propuesta además se fundamenta en que  una de las  principales áreas de estudio de I+D de la IS es la calidad del software, para lo cual se deben emplear los métodos y las herramientas, así como los estándares apropiados. Producir software sin un método y las herramientas adecuadas afecta a la calidad del producto.

El desarrollo de Apps difiere del ciclo de vida tradicional ([16], [18], [22]), por ello se han estudiado metodologías para desarrollos móviles ([6], [8], [9], [10], [11], [19]).

Por otra parte, se menciona que desde ámbitos de la Educación Superior, existen redes de Universidades como la RedUNCI [20]) quienes  trabajan en la definición de estándares curriculares, que son evaluados y adoptados según diversos trayectos de formación determinantes de perfiles de graduados en la disciplina. Uno de los temas incorporados entre los estándares de la RedUNCI son las tecnologías móviles, que evolucionan en el mercado internacional.

En el estudio y experimentación con una metodología para desarrollos móviles y, para su tratamiento en abstracciones de problemas reales se expone la aplicación de D3A en la definición de una App para la gestión de socios, y se exhiben los resultados derivados del primer incremento.

Metodología

De las metodologías relevadas, se optó por D3A [17], deriva de un proceso incremental que implementa características de Scrum ([7], [21]) y Kanban [15], desarrollo basado en  prototipos y el Modelo Vista-Controlador [22].

La metodología D3A se compone de 7 (siete) etapas. En la Fig. 1 se muestra el ciclo de la metodología D3A adaptada a la presente propuesta.

En la siguiente sección se muestran los resultados  de su aplicación, incorporándose la especificación de requerimientos según lo establece la IEEE [14].

 

Fig. 1. Metodología D3A aplicada para el desarrollo de la App.
Fuente: elaboración propia adaptado de [17].

 

Resultados

Se ilustra la aplicación de la metodología D3A, se exponen los resultados derivados del primer incremento en el diseño y desarrollo de una App para gestionar la información de socios. Es decir, las acciones correspondientes al ingreso, eliminación y modificaciones de datos personales. A efectos prácticos se ejemplificará con el ingreso de un usuario.

    Verificación existencia de usuario (socio o administrador).
  • Mínimo diseño de interfaz para las pantallas de inicio de sesión y registro.

Primera etapa: Recolección de requerimientos

En esta etapa se definen los requerimientos funcionales y no funcionales del primer incremento (Tabla 1).

Segunda etapa: Diseño rápido

El asesor del proyecto define un primer prototipo en modo gráfico destinado  al equipo de desarrolladores.

En la Figura. 2 se muestra el Esquema correspondiente al primer incremento. Se dispone de dos pantallas, una de inicio de la sesión el usuario y otra de registro. En esta última, si se presiona el botón “Registrarse”, el usuario de perfil “socio” es dado de alta y enviado a la pantalla de iniciar sesión. Al inicio de sesión se debe verificar su perfil administrador o socio y mostrar un mensaje luego de la verificación. Además, se dispone de una opción alternativa de ingreso al usuario no registrado, enviándose un mensaje que indica el acceso en modo “no socio o visitante”.

 

Tabla 1 – Requerimientos funcionales y no funcionales definidos en el primer incremento

Requerimiento

Descripción

RF-01

El sistema debe permitir a los usuarios “no socios” ingresar sin registro alguno.

RF-02

El sistema debe permitir a los usuarios “socios” ingresar con su respectivo usuario y contraseña

RF-03

El sistema debe permitir al usuario “administrador” ingresar con su usuario y contraseña

RNF-01

El sistema debe tener un tiempo de respuesta aceptable (menor a 5 segundos)

 

 

Fig. 2. Diseño rápido correspondiente al primer incremento.
Fuente: elaboración propia

 

Tercera etapa: Definición de Tareas

En esta etapa se aplica la metodología Kan-ban para organizar las tareas en un tablero y visualizar sus estados. El tablero que maneja esta metodología representa de forma visual tarjetas, en donde puede apreciarse de forma clara y definida  las actividades a realizar en el proyecto Cada tarea es escrita en una tarjeta y se pega en el tablero, en la fase que corresponda. Estas tarjetas deberán contener la información básica para que el desarrollador o equipo de desarrolladores sepa la carga total de trabajo que supone, es decir, se especifica la descripción de la tarea y la estimación en horas.

  • Para implementar el tablero Kan-ban, el esquema metodológico original propone usar la herramienta Trello [24] con la siguiente configuración:
  • Estado “Pendientes”: Corresponde a la lista de tareas que se deben ejecutar, donde se deberán asignar etiquetas de colores representativas de prioridad y si con la posibilidad de añadir recursos para el mayor entendimiento de cada tarea.
  • Estado “Development”: Se encuentran las tareas en ejecución, es decir,  en la fase de desarrollo.
  • Estado “Testing”: Corresponde a la lista de tareas que se prueban. Si se encuentra algún error se debería mover la tarea en el estado de “Development” y corregir ese error en el desarrollo para poder luego volver a avanzar en el estado de testeo.
  • Estado “Finalizadas”: Se encuentran las tareas probadas y consideradas finalizadas o realizadas para el incremento actual. Cuando todas las tarjetas se encuentren en este estado significa que el incremento en desarrollo está listo para ser finalizado.

Las actividades propuestas para este primer incremento son las siguientes:

  • Crear las actividades (pantallas) propuestas para el primer incremento.
  • Establecer los controles (botones, cuadros de texto, labels, etc.) en la actividad “IniciarSesion”.
  • Establecer los controles (botones, cuadros de texto, labels, etc.) en la actividad “Registrate”.
  • Crear la base de datos en un servidor de hosting.
  • Desarrollar código destinado a verificación de campos y caracteres ingresados.
  • Realizar la conexión de la App con la base de datos.
  • Dar de alta a un usuario.
  • Configurar la App para su conexión  a internet.
  • Iniciar sesión con usuario y contraseña, mostrando el mensaje que corresponda.
  • Añadir un fondo al diseño de las actividades (pantallas).

En la Fig. 3 se puede observar el desarrollo de tareas en una etapa media del primer incremento:

 

Fig. 3. Disposición de las tareas en el tablero Kan-ban con Trello. Fuente [24]

 

Cuarta etapa: Desarrollo del Prototipo (Interfaz y código)

Se procedió al desarrollo del prototipo y a la codificación, en base a los estándares establecidos, con la notación lowerCamelCase. Se utilizó la plataforma Android ([1], [2], [4], [12], [19])

Quinta etapa: Pruebas funcionales

En esta etapa se realizó una serie de pruebas para los incrementos. Estas pruebas consistieron en realizar un plan de prueba por cada caso de uso, es decir, por cada incremento se tendrán la cantidad de planes de pruebas correspondientes a los casos de uso que intervengan en cada uno.

Para el primer incremento, se tiene el siguiente diagrama de casos de uso parcial:

Plan de Prueba (PP) Nro. 1: C.U. “Iniciar sesión” (ver Tabla 2).

a) Generación y ejecución:

 

Tabla 2.Plan de Pruebas Nro. 1. C.U. “Iniciar Sesión”.Fuente: elaboración propia

ID nombre sistema: Sistema <nombre del sistema>

Autor del caso de prueba: autor1

ID C.U.: Iniciar sesión

Nombre del probador: autor2

Versión Caso de Prueba: v.1

Fecha de creación: 16/10/15

Fecha de ejecución: 16/10/15

N° CP

Objetivo

Datos  entrada

Resultados esperados

Resultados obtenidos

1

Verificar campos.

No se ingresa ningún valor.

El sistema verifica los campos y al estar incompletos emite un mensaje de error.

Mensaje de error:

“Complete todos los campos antes de continuar!”.

2

Verificar campos.

usuario=“maria”.
No se ingresa contraseña.

El sistema verifica los campos y al estar incompletos emite un mensaje de error.

Mensaje de error:

“Complete todos los campos antes de continuar!”.

3

Verificar existencia usuario.

Usuario inexistente.
usuario=“marta”
contraseña= “marta”

El sistema verifica los datos ingresados y al no ser usuario del sistema emite un mensaje de error.

Mensaje de error: “Usuario y contraseña ingresados no coinciden”.

4

 

Identificar tipo usuario.

Usuario socio.
usuario = “juanperez”
contraseña = “juanperez”

El sistema verifica los datos ingresados y al ser usuario socio emite un mensaje.

Mensaje: “usuario socio”.

5

Identificar tipo usuario.

Usuario administrador.
usuario = “admin”
contraseña = “ad2_2015p”

El sistema verifica los datos ingresados y al ser usuario administrador emite un mensaje.

Mensaje: “usuario administrador”.

Decisión de aprobación del caso de prueba (X): Aprobó: X; Falló:

Fecha de aprobación del caso de prueba: 16/10/15.

 

b) Registro de ejecución: la Fig. 4 visualiza la ejecución de plan de pruebas 1.

 

Fig. 4. Registro de ejecución. Plan de Pruebas Nro. 1.

Plan de Prueba Nro. 2: C.U. “Registrarse”   (ver Tabla 3).

a) Generación y ejecución:

Tabla 3.Plan de Pruebas Nro. 2. C.U. “Registrarse”. Fuente: elaboración propia

ID nombre sistema: Sistema <nombre del sistema>

Autor del caso de prueba: autor1

ID C.U.: Registrarse

Nombre del probador: autor2

Versión Caso de Prueba: v.1

Fecha de creación: 16/10/15

 

Fecha de ejecución: 16/10/15

N° CP

Objetivo

Datos  entrada

Resultados esperados

Resultados obtenidos

1

Verificar campos.

No se ingresa ningún valor.

El sistema verifica los campos y al estar incompletos emite un mensaje de error.

Mensaje de error: “Complete todos los campos antes de continuar!”.

2

Verificar campos.

nombre = “agustin”
email = “agustin12@gmail.com”
usuario = “agustin12”.
No se ingresa contraseña.

El sistema verifica los campos y al estar incompletos emite un mensaje de error.

Mensaje de error: “Complete todos los campos antes de continuar!”.

3

Controlar caracteres ingresados.

Nombre = “pedro”
email = “pedro@gmail.com”
usuario = “!!pedro”
contraseña = “pedro”

El sistema controla caracteres ingresados y emite un mensaje de error.

Mensaje de error: “Utilice solo letras, números, o guión bajo para su usuario y contraseña”.

4

Controlar caracteres ingresados.

Nombre = “fabiana”
Email = fabiana@gmail.com
Usuario = fab
Contraseña = fabiana2015

El sistema controla caracteres ingresados y emite un mensaje de error.

Mensaje de error: “Su nombre, usuario y contraseña deben tener 5 o más caracteres”

5

Controlar caracteres ingresados.

Nombre = “fabian232”
Email = fabiana@gmail.com
Usuario = Fabiana
Contraseña = Fabiana

El sistema controla caracteres ingresados y emite un mensaje de error.

Mensaje de error: “Utilice solo letras para su nombre”

4

Registrar usuario.

nombre = “agustin”
email = “agustin12@gmail.com”
usuario = “agustin12”.
contraseña = “agustin12”.

El sistema verifica los campos, toma los datos y registra al usuario, enviando un mensaje de información de registro al nuevo usuario y llevándolo a la página de iniciar sesión.

OK.

Decisión de aprobación del caso de prueba (X): Aprobó: X; Falló:

Fecha de aprobación del caso de prueba: 16/10/15.

 

b) Registro de ejecución: Las Figs. 5 y 6 representan el plan de pruebas del caso de uso “Registrarse”

 

Fig. 5. Registro de ejecución. Plan de Pruebas Nro. 2.
Fuente: elaboración propia

 

 

Fig. 6. Registro de ejecución. Plan de Pruebas Nro. 2.
Fuente: elaboración propia

 

Consideraciones finales

El Sector de Servicios Informáticos crece considerablemente, desde los ámbitos de Educación Superior, se debe asegurar la formación de recursos humanos que respondan a las demandas del mercado, por ello, constantemente las cuestiones curriculares intentan reflejar los nuevos requerimientos a fin de aportar al crecimiento de la Industria del Software. Uno de los temas planteados en la formación en el desarrollo de aplicaciones para tecnologías móviles, que emergen como un nuevo paradigma de desarrollo tecnológico.

Con el fin de explorar el uso de metodologías apropiadas según las tecnologías involucradas en la construcción de softwrae, se han estudiado y seleccionado una pertinente al desarrollo móvil. Se han expuesto los resultados derivados de aplicar el primer incremento para modelar una abstracción de la gestión de socios, desarrollo transferible y adaptable a diversos contextos de la industria y de la academia.

Bibliografía

[1] Android, Android Developers, “Dashboards”. [En línea]. Disponible en:
https://developer.android.com/about/dashboards/index.html?utm_source=suzunsuz

[2] Android Developers, “Tools: Android Studio”. [En línea]. Disponible en
http://developer.android.com/sdk/index.html

[3] Association for Computing Machinery. [En línea]. Disponible en: https://www.acm.org/

[4] M. Báez, A. Borrego, J. Cordero, L. Cruz, M. González, F. Hernández, D. Palomero, J. Rodríguez de Llera, D. Sanz, M. Saucedo, P. Torralbo, A. Zapata., Introducción a Android. Madrid: Editorial E.M.E. 2010.

[5] P. Bourque; R. E. Fairley, “Guide to the Software Engineering Body ofKnowledge”, Version 3.0, IEEE Computer Society, 2014. [En línea]. Disponible en: http://www.swebok.org

[6] P. Thomas, N. Galdámez, L. Delía, F. Cristina, S. Dapoto y P. Pesado, “Dispositivos Móviles: desarrollo de aplicaciones y conectividad,” en 14to Workshop de Investigadores en Ciencias de la Computación, 2014.

[7] P. Deemer, G. Benefield, C. Larman, B. Vodde, Scrum Training Institute, “Información Básica de Scrum,” Versión 1.1., 2009. [En línea]. Disponible en:

http://www.goodagile.com/scrumprimer/scrumprimer_es.pdf

[8] D. G. De la Riva, C. Di Cicco, C., F. Montero, S. Sottile, “Proyecto UniMóvil: una aplicación móvil para Universidades,” en 18vo Congreso Argentino de Ciencias de la Computación, Buenos Aires, Argentina, 2012.

[9] A. J. Durán Sanjuán, J. L. Peinado Rodríguez, A. A. Rosado, “Comparación de dos tecnologías de desarrollo de aplicaciones móviles desde la perspectiva de los atributos de calidad,” Scientia et Technica Año XX, vol. 20, no. 1, pp. 81-87, 2015.

[10] M. Fennema, R.Palavecino, S. Herrera, S., P. Najar Ruíz,“Métodos, técnicas y herramientas para optimizar la calidad de los sistemas móviles,” en XVII Workshop de Investigadores en Ciencias de la Computación, 2015.

[11] M. Gasca Mantilla, L. Camargo Ariza, B. Medina Delgado, “Metodología para el desarrollo de aplicaciones móviles,” Tecnura, vol.18, no. 40, pp. 20-35, 2014.

[12] G. Hecht, N. Moha, R. Rouvoy, “An Empirical Study of the Performance Impacts of Android Code Smells,” in IEEE/ACM International Conference on Mobile Software Engineering and Systems, Austin, Texas, United States, May 2016.

[13] IEEE ComputerSociety. [En línea]. Disponible en: https://www.acm.org/

[14] IEEE Recommended Practice for Software Requirements Specifications, IEEE Std. 830- 1998.
[15] KanbanTool. [En línea]. Disponible en: http://kanbantool.com

[16] M. Ochoa,  P. Britos, E. Fernández, R. García Martinez,Metodologías de la Ingeniería Informática. Nueva Librería, 2008

[17] U. Ponce Mendoza, V. Yañez Moreno, R. Soto Bernal, “Propuesta Metodológica para el desarrollo de Aplicaciones Móviles para Dispositivos Android,” en Congreso Internacional de Investigación, Tabasco, México, pp. 1-6, Mayo de 2014.

[18] R. Pressman, Ingeniería del Software. Un enfoque práctico. México: Mc Graw-Hill Interamericana, 2010. 

[19] Thomas, P., Galdámez, N., Delía, L., Cristina, F., Dapoto, S., Tinetti, F., Pesado, P., De Giusti “Ingeniería de Software en el desarrollo de Aplicaciones para Dispositivos Móviles,” en 15to Workshop de Investigadores en Ciencias de la Computación, 2013.

[20] Propuesta de Currícula RedUNCI, “RedUNCI, Red de Universidades Nacionales con Carreras en Informática,” 2006. [En línea]. Disponible en: http://redunci.info.unlp.edu.ar/docs/Core-basico-23-6-2006-Agosto.pdf

[21] K. Schwaber, “Scrum Development Process”. [En línea]. Disponible en:

http://www.jeffsutherland.org/oopsla/schwapub.pdf

[22] I. Sommerville, Ingeniería del Software, 9na ed. Madrid, España: Pearson Educación.

[23] SWEBOK. “AboutSwebok,” 2014. [En línea]. Disponible en:

https://www.computer.org/portal/web/swebok

[24] Trello. [En línea]. Disponible en: http://trello.com

URL: www.cyta.com.ar/ta1504/v15n4a2.htm

Técnica Administrativa
ISSN 1666-1680
http://www.cyta.com.ar -

Recibido el: 01-03-2016; Aprobado el:14-03-2016

Volúmen:15

Número:4

Artículo:2

Buenos Aires, 15-10-2016

	  

Ver Ficha:[Artículo]


Ver Ficha Autor/a:

[Chalub, Maximiliano ]
[Mariño, Sonia I. ]
[Alfonzo, Pedro L. ]
[Godoy, Maria V.]

Traducir el artículo:[Translate]

(Ô_Ô) Recomendar el artículo por: Correo / facebook / Twitter / Google+ / WhatsApp /