Figura 12: OpenLayers

2.1.14. OpenLayers

OpenLayers es una biblioteca de JavaScript la cual es utilizada para mostrar mapas interactivos en los navegadores web como se muestra en la Figura 12, por medio de herramientas que forman la API con la cual se puede acceder a diferentes fuentes de información cartográfica que se encuentren en un Web Map Services, tales como Mapas comerciales tipo Google Maps donde con distintos formatos vectoriales se pueden ver ubicaciones en los mapas (García, 2011).

Figura 12: OpenLayers Fuente: OpenLayers Org. (OpenLayers, 2020).

2.2. MARCO METODOLÓGICO

2.2.1. Principales metodologías de desarrollo

2.2.1.1. Metodología Scrum

Se desarrolló en 1986, como base de un estudio sobre nuevos procesos de desarrollo usados en Japón y Estados Unidos. Fue presentada de manera oficial en 1995 por Jeff Sutherland y Ken Schwaber. La última versión tuvo su origen en febrero de 2010 (ESIUS, s.f.).

Para la aplicación de esta metodología es necesario que el proyecto tenga algunas características como:

• Desarrollo incremental: esta característica nos indica que el proyecto puede ir avanzando en su desarrollo sin importar desde donde se parta en su desarrollo.

• Calidad de las personas: se basa en tener un equipo de trabajo especializado con el nivel de conocimiento adecuado para el desarrollo del proyecto. Este equipo se conoce como scrum team y básicamente el corazón de la metodología scrum, pues son los integrantes del equipo de desarrollo, encargados de la codificación del software y de cumplir los objetivos propuestos.

• Adiós al secuencial y cascada: el proyecto se desarrolló en procesos, los mismos que a pesar de haberse finalizado, en cualquier etapa de desarrollo se pueden volver a modificar o rehacer.

• La comunicación es fundamental: se basa fundamentalmente en el trabajo en equipo para alcanzar los objetivos de forma rápida.

Procesos en los que se basa esta metodología (OH, s.f.):

• Product backlog: Es una lista de lo que hay que hacer de forma ordenada de acuerdo a las prioridades y la redacta product owner, quien es el líder del proyecto y velara por llegar a la satisfacción del cliente.

• Sprint backlog: Consiste en determinar el tiempo en el que se realizará cada punto de la lista descrita en el product backlog. Cada uno de los sprint se componer de Features que son subprocesos o tareas más pequeñas que componen el desarrollo del Sprint.

• Sprint planning meeting: Es una reunión en la que se determina plazos y procesos que se desarrollaran en el product backlog.

• Daily scrum o stand-up meeting: son reuniones diarias que tienen lugar durante el desarrollo de cada sprint, en las que es necesario responder las siguientes preguntas: ¿qué hice ayer?, ¿qué voy a hacer hoy, ¿qué ayuda necesito?. Es necesario que las intervenga el scrum master, quien es la persona especialista y con los conocimientos necesarios para brindar la ayuda requerida al equipo de desarrollo en la solución de los problemas y complicaciones que sucedan a lo largo del desarrollo de cada sprint.

• Sprint review: Consiste en la revisión del sprint terminado y el entregable tangible que se mostrará al cliente.

• Sprint retrospective: Permite visualizar los objetivos cumplidos al equipo, determinar los errores ocurridos y fijar acciones para no cometerlos. Y de ser el caso las posibles mejoras que se puedan implementar en el futuro.

• Cliente: En scrum el cliente puede influir en el proceso de desarrollo, ya que tiene el conocimiento de los procesos y puede proponer nuevas ideas y emitir comentarios

Caso de estudio

Se empleó en el desarrollo de software de productos como cámaras de fotos de Canon, fotocopiadoras de Xerox, automóviles de Honda, ordenadores de HP (ES, 2018).

2.2.1.2. Metodología Kanban

Es una metodología Japonesa, consiste en ir etiquetando con tarjetas cada uno de los procesos. Es de fácil implementación e integración del equipo de trabajo, ya que pueden trabajar a la par en varios hitos del desarrollo.

Principios básicos de Kanban (Gilibets, 2020):

• Garantía de calidad: Este principio indica que se debe realizar desde el inicio cada proceso con el debido detalle y sin cometer errores tomándose el tiempo adecuado.

• Desperdicios: El sistema realizado debe hacer únicamente lo solicitado, no se debe realizar tareas extras, de valor agregado o innecesario, ahorrando así costos y optimizando el tiempo.

• Mejora continua: Indica que se puede mejorar constantemente los procesos.

• Es flexible: Permite el desarrollo de procesos sin importar la prioridad establecida, lo que permite avanzar en las tareas o retomar procesos ya concluidos.

Como iniciar:

1. Definir el flujo de trabajo: Se realiza un tablero de las tareas a realizar que este visible para todos los integrantes del equipo de trabajo y se va actualizando según el avance del mismo, se puede tener en el solo las tareas de un solo proyecto o de todos en los que se esté trabajando.

2. Fases del ciclo de producción: Es necesario definir tareas más pequeñas y colocar el tiempo en el que se plantea su elaboración, al final se indica si se concluyó y de no ser así las razones por las que no se pudo finalizar.

3. Stop starting, start finishing: No se empieza una nueva tarea sin concluir la anterior, ya que se busca tener la mayor parte de tareas concluidas.

4. Tener un control: Lleva el control por medio de notas que se va colocando, lo que permite la realización de varios proyectos de forma simultanea para evitar interrupciones innecesarias (Gilibets, 2020).

Caso de estudio

Se empleó en el desarrollo del software del cerebro de los vehículos Toyota (OH, 2021).

2.2.1.3. Metodología XP (Programación Extrema)

Esta metodología fue desarrollada por Kent Beck en 1999. Tiene capacidad de adaptabilidad ante cualquier eventualidad durante el proceso, permite modificar procesos en caso de que se suscite hacerlo.

Se dice que es de programación extrema ya que permite combinar varias metodologías, es recomendable su aplicación en proyectos a corto plazo.

Valores de la Metodología XP (Bello, 2021):

• Comunicación: Esta característica depende de la estandarización del código fuente y de la documentación técnica de los procesos y código, diccionario de datos

y manuales. El grupo de trabajo se divide en parejas y su comunicación con el cliente es directa y constante.

• Simplicidad: Consiste en realizar únicamente lo solicitado y de la manera más simple y básica en aspectos de codificación técnica y de diseño. Internamente el código fuente debe estar realizado con los debidos estándares para creación y documentación de variables, métodos y clases y que los mismos tengan nombres adecuados a la tarea que realicen, lo que permitirá que todo el equipo de trabajo pueda involucrarse o si existe algún nuevo integrante puedan entender de forma fácil a que se refiere cada proceso.

• Retroalimentación: La presencia del cliente en el desarrollo permitirá que se puede llegar de manera más rápida a lo que requiere ya que está en una constante revisión y participación.

• Valentía: Esta característica se refiere a los valores de los programadores quienes después de largas jornadas de programación a veces deben volver a iniciar o cambiar o arreglar porciones de su código fuente.

• Respeto: Se refiere a la relación entre los integrantes del equipo, que debe ser cordial y honesta, sin denigrar a nadie, esto es básico para que exista un buen ambiente laboral y un buen y eficiente equipo de trabajo donde todos sus integrantes estén a gusto.

Características que componen la metodología XP

• Tipo de desarrollo iterativo e incremental: Se basa en retomar procesos y mejorarlos de ser el caso.

• Pruebas unitarias: se usa para desglosar y validar cada proceso, pudiendo con esas pruebas evidenciar si el código fuente realiza o no lo que debe realizar y poder realizar los procesos de mejora de ser el caso.

• Trabajo en equipo: Trabajo en parejas donde ambos forman un equipo, enriquecen mutuamente el proyecto y aprenden y complementan conocimientos.

Este equipo puede estar formado de hasta 12 personas.

• Alguien del equipo trabaja con el cliente: Es necesario que exista una persona intermediaria entre el equipo de trabajo y el cliente. El cliente participa del proyecto pero es este intermediario en que comunica a ambas partes del avance del proyecto y los requerimientos del mismo.

• Corrección de errores: En primera instancia se corrigen los errores en el código fuente y luego se continúa con el desarrollo.

• Reestructuración del código: Consisten en desarrollar código fuente lo más simple posible y que realice lo solicitado, sin agregar porciones de código o tareas innecesarias, lo que permitirá a la vez su compresión y adaptación a nuevos cambios.

• El código es de todos: Todos pueden acceder al código fuente por lo que sería importante tener algún software de control de versiones, ya que esto facilitará las mejoras de los procesos y el control de los cambios.

 Test del cliente: Se elaboran pruebas a las diferentes versiones del desarrollo por parte del cliente en conjunto con los desarrolladores.

 Versiones pequeñas: Estas mini-versiones deben presentar entregables de la funcionalidad esperada por el cliente, el mismo que podrá realizar sobre ellas sus pruebas.

 Ritmo sostenible: Permite realizar los desarrollos a un ritmo estable es decir que no haya días muertos en los que no se puede avanzar con los desarrollos (SP, 2018).

Equipo de trabajo dentro de una metodología XP

• Programador: Es el encargado de generar, crear o desarrollar el código fuente.

• Tester: Realiza todas las pruebas necesarias del software y comunica al cliente y al equipo los resultados de las mismas.

• Tracker: Es el encargado de verificar que los tiempos se cumplan para el desarrollo de cada proceso.

• Entrenador: Se encarga de guiar al equipo en el desarrollo.

• Consultor: Es un elemento externo, no forma parte del equipo de trabajo pero tiene como función ayudar en la solución de problemas del desarrollo.

• Gestor: Es el líder, une a los clientes y a los programadores (OH, 2021)

Caso de estudio

Se utilizó en IBM (Corporación internacional de máquinas comerciales) en el desarrollo de diferentes aplicaciones de software para plataformas de sus servidores (PMOI, 2013).

2.2.1.4. Metodología OMT

“La OMT fue desarrollada y creada por James Rumbaugh y Michael Blaha, por esa época James dirigía a un grupo de investigadores de los laboratorios General Electric, en 1991” (Ruíz, 2010, pág. 30).

Los ingenieros y diseñadores han estado creando modelos a lo largo de los años y los probaban antes de ejecutarlos (Beliblog, 2015). Lo mismo ha pasado con el desarrollo de hardware y software, se realiza bosquejos, plantillas y modelos que permiten plasmar las ideas de manera clara y ordenada para poder realizar un proceso automatizado y llegar así a satisfacer los requerimientos planteados para luego realizar una implementación (CH, s.f.).

Caso de estudio

Se utilizó en el desarrollo de software de telefónicos inteligentes de General Electric (UNWTO, 2015)