Technical note
Desarrollo Móvil: prototipo para la gestión de socios basado en la metodología D3A
Mobile development: prototype for partner management based on D3A methodology
Departamento de Informática.
Facultad de Ciencias Exactas y Naturales y Agrimensura,
Universidad Nacional del Nordeste. Corrientes, Argentina
Departamento de Informática.
Facultad de Ciencias Exactas y Naturales y Agrimensura,
Universidad Nacional del Nordeste. Corrientes, Argentina
Departamento de Informática.
Facultad de Ciencias Exactas y Naturales y Agrimensura.
Universidad Nacional del Nordeste. Corrientes, Argentina.
Departamento de Informática.
Facultad de Ciencias Exactas y Naturales y Agrimensura.
Universidad Nacional del Nordeste. Corrientes, Argentina.
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.
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.
Palabras Clave:
tecnologías móviles, métodos, Apps ⓘ
Keyword:
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. |
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. |
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”. |
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. |
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. |
El sistema verifica los datos ingresados y al ser usuario socio emite un mensaje. |
Mensaje: “usuario socio”. |
5 |
Identificar tipo usuario. |
Usuario administrador. |
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” |
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” |
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” |
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” |
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” |
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. |
Fig. 6. Registro de ejecución. Plan de Pruebas Nro. 2. |
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 - Bibliography
[1] Android, Android Developers, Dashboards .
[2] Android Developers, Tools: Android Studio .
[3] Association for Computing Machinery.
[14] IEEE Recommended Practice for Software Requirements Specifications, IEEE Std. 830- 1998.
[21] K. Schwaber, Scrum Development Process .
[22] I. Sommerville, Ingeniería del Software, 9na ed. Madrid, España: Pearson Educación.
[23] SWEBOK. AboutSwebok, 2014.
Google Scholar Index
Article
Desarrollo Móvil: prototipo para la gestión de socios basado en la metodología D3A
Publisher: