Por colaboradores de Mundo Ingenio
Actualmente, en el campo de la tecnología se siguen fundamentos de desarrollo de sistemas/”software” con el fin de cumplir con los parámetros óptimos para un diseño eficiente que cumpla las mejores propiedades del desarrollo y diseño de programas o aplicaciones. Ciertamente, existe mucha documentación dedicada a cumplir con los objetivos específicos mencionados antes, sin embargo, en la presente indagación de información referente a estrategias y módulos creados con el fin de conseguir “software” óptimos y que aprovechen en su mejor forma la arquitectura de diferentes dispositivos, además, de cumplir con los requerimientos solicitados, y contar con un sistema que sea abierto a cambios posteriores, seguro, que provea estabilidad en la red, entre otras múltiples características con las que debe ser elaborado un sistema informático; en fin, con un diseño adaptable y eficiente.
La siguiente investigación tiene como objetivo general reunir información alusiva a pautas con fundamentos en el planteamiento, diseño y desarrollo de sistemas informáticos, parte de la compilación de estos datos se ponen en práctica, con base en el ejercicio planteado con nombre “Oc2021” propuesto en el curso “Análisis y Diseño de Sistemas”.
De manera específica, se manifiesta la conceptualización y propósitos de patrones arquitectónicos, por otra parte, se describe la aplicación de guías de arquitectura de sistemas en el ejemplo sugerido mencionado antes. También, se modela mediante el ejercicio práctico de algunas técnicas de diseño y desarrollo de “software”, tales como, historias de usuario o más conocido como “story mapping”; igualmente, se detalla la implementación del marco de desarrollo con nombre “SCRUM”, a través del ejercicio práctico. Además, mediante codificación planteada, se recomienda el mejoramiento y optimización del mismo con el fin de cumplir con los fundamentos necesarios de desarrollo y diseño de calidad.
La estructura de la indagación programada, consiste en primer lugar, describir algunos conceptos básicos del desarrollo de software, donde se muestran sus objetivos, diagramas de visualización, procedimientos y modelado.
En segundo lugar, se especifica a través de la puesta en práctica, algunas de las técnicas de diseño y codificación optimizadas con el principio de cumplir con un producto de “software” de calidad.
Desarrollo
1. Patrones arquitectónicos “Arquitectura en capas”, “Arquitectura de repositorio”, “Arquitectura cliente-servidor”.
a. En que consisten y qué aspectos o problemas pueden resolver
Con el fin de comprender mejor como funcionan los distintos patrones arquitectónicos en el diseño y desarrollo de sistemas, es significativo mencionar que, según el autor Summerville (2011), expone que estos estilos de arquitectura consiste en presentar, reutiliza y compartir competencias e instrucciones sobre los sistemas.
Ahora, tomando en cuenta la conceptualización, aunque de forma general, se van a describir los patrones de arquitectura de tres de ellos. Referente al patrón arquitectónico en capas, el autor Instituto Politécnico Nacional (s.f.), menciona que fundamentalmente este patrón tiene la característica de dividir la solución del problema en varias capas, con el fin de segmentar e identificar de mejor manera sus componentes. El patrón de capas modelado como MVC (Modelo-Vista-Controlador), donde el Modelo contiene en su módulo diferentes objetos que modelan, dependiendo de los requerimientos del sistema, elementos que componen el sistema. Por otro lado, la Vista, que cumple con la función de mostrar la interfaz gráfica del aplicativo, mismo que puede almacenar datos y activar eventos. También, el Controlador, que se encarga en esencia de controlar el flujo de datos y eventos recuperado de la Vista y actualiza el Modelo y viceversa.
Este tipo de patrón, escribe el mismo autor mencionado antes, da soporte a sistemas incrementales donde el aplicativo tiene características cambiantes; también cada pretende quedar a disposición del usuario final.
Alusivo al patrón de arquitectura con nombre Arquitectura de repositorio, el mismo autor mencionado con anterioridad, dice que este tipo de diseño consiste en especificar como se comparten datos en conjunto de componentes en interacción, en palabras del mismo autor “se interesa por la estructura estática de un sistema sin mostrar su organización en tiempo de operación” (pág. 8). Más adelante, Instituto Politécnico Nacional (s.f.) manifiesta que uno de los principales problemas que resuelve este tipo de arquitectura, es en “aplicaciones en las que un componente genere datos y otro los use.” (pág. 8). Por otra parte, el mismo autor hace mención sobre algunos sistemas de comando y control de esta clase, tales como, información administrativa, sistemas CAD, y entornos de desarrollo interactivo para “software”.
Concerniente al patrón arquitectónico con nombre Arquitectura cliente-servidor, Instituto Politécnico Nacional (s.f.), explica que este tipo de arquitectura se fundamenta en disponer de un conjunto de servicios y servidores asociados, y de clientes que acceden y hacen uso de los mismos. Por otro lado, el mismo autor describe algunos de sus principales componentes, a continuación se listan:
- Un conjunto de servidores que ofrecen servicios a otros componentes.
- Un conjunto de servidores que ofrecen servicios a otros componentes.
- Una red que permite a los clientes acceder a dichos servicios.
La ventaja más significativa de esta clase de patrón arquitectónico que destaca el mismo autor, es que se apoya en una arquitectura distribuida. Este tipo de diseño arquitectónico se puede implementar en sistemas en red con diferentes procesadores distribuidos.
b. Cómo aplicaría este patrón arquitectura en el contexto del proyecto
Seguidamente, se describe la implementación más cercana de cada patrón arquitectónico (capas, repositorio y cliente-servidor). En el primer caso, con base en el proyecto propuesto con nombre “Oc2021”; se sabe que el modelado MVC permite separar de forma eficiente los diferentes componentes del sistema, en este caso se habla de varios aplicativos, todos con características propias y especificas, sin embargo, mantienen una comunicación entre ellos; lo que requiere un modelado de entidades con atributos que son dependientes unos de otros, en el caso de las interfaces que controlan un CRUD de roles como los de Guardianes, Jueces y Oficiales, lo cual favorece al modelado MVC que permitiría la comunicación entre entidades y vistas mediante su controlador correspondiente, es decir su actualización.
En cuanto al patrón arquitectónico de repositorio, es cierto que esta clase de arquitectura funciona para desarrollos donde exista un sistema de información administrativa, el cual se puede identificar en el proyecto, donde se detalla que debe crearse un sistema de administración para manejar la aplicación móvil y la de “Live Map”, entonces, podría aplicarse en este caso para cumplir con el requerimiento respectivo. Para ambos casos, los componentes trabajarían con un modelado de repositorio ya establecido, sin la posibilidad de integrar nuevos componentes.
Por último, referente al patrón arquitectónico cliente-servidor. Tomando como base el aplicativo de “Live Map”, es necesario consumir recursos de un servicio externo, tal es el caso de la API de Google Maps y algunos paquetes en específico; entonces, el patrón de esta clase es aplicable en esta ocasión, donde se transmitirían datos mediante el protocolo “Http” por ejemplo, entre algunos paquetes más, que son necesarios para el buen funcionamiento, calidad y seguridad de los datos.
2. Diagrama de despliegue UML
A continuación, se muestra un diagrama de despliegue, con base en el caso de ejemplo del proyecto con nombre “Oc2021”; con base en la lectura de los autores Campderrich Falgueras (2013) y Summerville (2011), donde menciona algunas propiedades alusivas a la información de diagramas de despliegue, tales como su conceptualización, componentes, entre otros. Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”. El diagrama se presenta en forma de imagen (Imagen 1).
Imagen 1:
Diagrama de despliegue: “Oc2021”
Autor: propio
En cuanto a la importancia de este tipo de ejercicio puesto en práctica, radica fundamentalmente en las diferentes capas y patrones de arquitectura que son necesarios para un producto final de alta calidad, sin perder la posibilidad de extensiones del servicio o aplicativo, es decir que un programa, como se plantea en el proyecto, debe cumplir los requisitos de las métricas de calidad de “software”. Entonces, un diagrama amplía la extensión y recursos con los que se debe contar, aunque sean de un tercero.
3. Historias de usuarios
Seguidamente, se describen en forma de tabla (Tabla 1: Historias de Usuario) historias de usuario basados en el caso “Oc2021”. Basados en la descripción de historias de usuarios de los autores Sobczak (2020), Betancur (2018), y Menzinsky , López y Palacio (2018).
Tabla 1:
| ID de la Historia | Como un – Actor | Quiero – Función | Con el fin de – Valor | Prioridad1(+alta) a (+10 baja) | Justificación Prioridad | Estimación 1(+baja) a 10(+alta) |
| 1 | Usuario final (Guardián, Juez) | Consultar denuncias | Consultar las denuncias del sistema. | 1 | Beneficio de la función, es la temática principal de la aplicación. | 4 |
| 2 | Usuario final (Oficial) | Proponer solución a denuncia | Visualizar una lista de denuncias confirmadas y proponer una solución para una denuncia y enviar una notificación a los Jueces. | 1 | Beneficio de la función, pues se genera una posible solución a un problema inmediato. | 4 |
| 3 | Usuario final(Juez) | Aprobar denuncia | Solicitar al sistema desplegar una lista de denuncias con su respectiva solución para luego aprobar esta propuesta. | 2 | Beneficio de la función, se ejecuta la respuesta positiva a la propuesta que debe ser atendida. | 4 |
| 4 | Usuario final(Juez) | Rechazar propuesta de solución | Solicitar al sistema desplegar una lista de denuncias con su respectiva solución para luego rechazar esta propuesta. | 2 | Beneficio de la función, se ejecuta la respuesta negativa a la propuesta que debe ser atendida. | 4 |
| 5 | Usuario final (Guardián) | Registrar aporte a la carbono-neutralidad | Hacer aportes referentes a actividades relacionadas con el carbono neutral y generar un reporte en el sistema. | 3 | Coherencia con los intereses del negocio. Aquí se los guardianes aportan al propósito de la aplicación | 5 |
Historias de Usuario
Referencia: Propia.
4. Mapeo de Historias
A continuación, se muestra un mapa de historias, con base en el caso de ejemplo del proyecto con nombre “Oc2021”; con base en la lectura del autor Vila (2017) y Sanders (2018), donde menciona algunas características referentes a la información de mapeo de historias, tales como su conceptualización, “Backlog”, entre otros. Se utiliza el sistema en línea “lucidchart” para diseñar el mapa de historias, con sitio web oficial “lucidchart.com”. El mapa se muestra en formato de imagen (Imagen 2).
Imagen 2:
Mapa de Historias: “Proyecto Oc2021”
Autor: propio
5. Reflexión Historias de Usuario y Contraste con Casos de Uso
A continuación, se describe una comparativa entre la definición de historias de usuario contrastado con los casos de usos. En primer lugar, según el autor Sobczak (2019), aclara que una historia de usuario funciona para describir brevemente una funcionalidad requerida por el usuario. Igualmente, el autor Rehkopf (2021), afirma nuevamente que las historias de usuario describen funcionalidades del sistema, y que son requisitos que explica el usuario, pero, también coloca al usuario en el centro de la conversación, y se utiliza lenguaje no técnico para este fin. Por otra parte, los casos de uso, según el autor Junta de Andalucía (s.f.), son “es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización de software” (párr. 1). Entonces, teniendo en cuenta este acercamiento a las concepciones correspondientes de ambos términos, podrían confundirse, sin embargo, los caso de uso tienen una perspectiva de la interacción entre el usuario y el sistema, sin embargo, hasta cierto punto del desarrollo del sistema, se diagrama en un lenguaje UML, que resulta en un lenguaje amigable con la máquina y no tanto con el ser humano; por su parte, las historias de usuario están escritos en un lenguaje coloquial.
En cuanto a algunas de los beneficios que ofrecen las historias de usuario y casos de usos. Es cierto que, las historias de usuario acercan mucho al usuario a la temática central del sistema, lo que permite el intercambio de requerimientos más fáciles de entender para estos, lo que al final va a resultar en un aplicativo mucho mejor para su usabilidad, en este caso en particular (caso hipotético-proyecto “Oc2021”), es conveniente, ya que los usuarios finales van a colaborar activamente con el proceso en cuestión, pero con múltiples perfiles de escolaridad. También, las historias de usos ofrecen una comunicación clara para el perfil del usuario final y el programador, independiente de quien está en medio de ambos, un dueño de producto por ejemplo, en alguna metodología de desarrollo en específico. Es claro que, los casos de uso también brindan beneficios varios, no obstante uno destacable es que permite al perfil del analista se centre en las necesidades del usuario (Junta de Andalucía, s.f.).
6. Marco de Trabajo SCRUM
a. Documentación
Manual de usuario de la aplicación
A continuación, se muestra un manual de usuario de la aplicación con base en el caso propuesto con nombre “Oc2021”, igualmente se toma como base una plantilla de manual de usuario propuesta por el autor Junta de Andalucía (s.f.), por otra parte, se toma en cuenta la guía SCRUM propuesta por los autores Schwaber y Sutherland (2020), donde se adquieren varios elementos y conceptualización que suman al desarrollo del manual en cuestión.
Formato:
DESCRIPCIÓN Y TÍTULO
“Oc2021”
Manual de Usuario
Versión: 01
Fecha: 25/11/2021
Caso Práctico “Oc2021” V. 1
HOJA DE CONTROL
| Organismo | “MINAE” | ||
| Proyecto | Oc2021 | ||
| Entregable | Manual de Usuario | ||
| Autor | “Bob” | ||
| Versión/Edición | 01 | Fecha Versión | 26/10/2021 |
| Aprobado por | Fecha Aprobación | 26/11/2021 | |
| Nº Total de Páginas | 10 |
REGISTRO DE CAMBIOS
| Versión | Causa del Cambio | Responsable del Cambio | Fecha del Cambio |
| 01 | Versión inicial | “Bob” | 26/10/2021 |
CONTROL DE DISTRIBUCIÓN
| Nombre y Apellidos |
| “Bob” |
ÍNDICE
El índice correspondiente.
1 DESCRIPCIÓN DEL SISTEMA
1.1 Objeto
La siguiente documentación tiene como objetivo principal, contener una guía explicativa sobre el aplicativo “Oc2021”, con algunos detalles de los parámetros del sistema.
1.2 Alcance
En cuanto el alcance del documento es accesible por la sociedad civil costarricense en primera instancia, ya que el aplicativo esta dirigido para la soberanía costarricense, sin embargo, cualquier persona natural con acceso a internet que desee utilizar el aplicativo, por lo tanto, el manual de usuario será accesible para aquel. También, el documento cuenta con la guía y preguntas frecuentes para orientar al usuario final.
1.3 Funcionalidad
A continuación, se muestra la principal funcionalidad del sistema “Oc2021”. En primer lugar, se pretende llevar un control de carbononeutralidad a nivel nacional, todo mediante reportes de referentes a irregularidades en el ámbito de la biodiversidad, cuidado del medio ambiente y explotación de recursos naturales. En segundo sitio, el sistema cuenta con varios perfiles de usuario, una vez elegido este, debe ingresar sus datos personales para la creación de una cuenta con funciones y/o tareas específicas. Todos los perfiles tienen como fin funcionar en conjunto para el objetivo principal de la aplicación, de esta manera se facilita la gestión de carbononeutralidad a través de la cantidad de personas necesarias.
2 MAPA DEL SISTEMA
Seguidamente, se muestra documentación correspondiente para el manual de usuario, pero solo para la aplicación móvil.
2.1 Modelo Lógico
A continuación, un modelo lógico (libre formato), donde se describe la función principal de la aplicación. En primera instancia, nace un problema que se debe denunciar, este a su vez debe ser generado y revisado. Una vez que se consultan las denuncias se notifica a un perfil para generar una propuesta de la posible solución, luego, se procede a confirmarla o rechazarla, para al final encontrar la solución más óptima. Así, suma al propósito de cumplir con un país en los primeros lugares de protección al medio ambiente y uso de recursos naturales, reduciendo la huella de carbono. Se muestra el modelo en formato de imagen (Imagen Modelo Lógico). Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”.
Imagen Modelo lógico
Modelo Lógico: “Oc2021”
Autor: propio
2.2 Navegación
A continuación, se muestra la navegación de la aplicación a través de ventanas, se exponen los caminos más significativos. Se muestra el modelo en formato de imagen (Imagen Pantallas). Se utiliza el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”.
Imagen Pantallas
Navegación: “Oc2021”
Autor: propio
3 DESCRIPCIÓN DEL SISTEMA
En esta sección se describirá la interfaz gráfica con las principales características de la aplicación. Se exponen las pantallas anteriormente expuestas, así como las dependientes. Hay que ir explicando las distintas pantallas de la aplicación siguiendo los caminos lógicos que el usuario realizaría. También se explican los mensajes de error que pueden aparecer dependiendo de la ventana.
3.1 Aplicación Móvil
Esta aplicación, de esta manera como se describe en el objetivo principal, reúne un conjunto de perfiles con funciones específicas que trabajan para solucionar problemas referentes al medio ambiente y uso de recursos naturales para alcanzar carbono neutral a nivel Costa Rica.
3.1.1 Pantalla Login/Register
En esta pantalla el usuario final tiene las opciones de ingresar al sistema, o si no tiene una cuenta abierta tiene la posibilidad de registrarse.
3.1.2 Mensajes de error
Varios errores pueden pasar aquí, si el usuario intenta ingresar al sistema y no digita bien su usuario o email o contraseña o tipo perfil (guardián, oficial, juez) correctamente, no va a ingresar y el error va a aparecer en pantalla, puede recuperar el usuario/email o contraseña si definitivamente no puede ingresar. En el caso de que el usuario no tenga cuenta y desea registrarse, podría digitar mal el formato de usuario o email o repetirlo, y puede no digitar contraseña lo que es un requisito del formulario, entonces debe colocar correctamente en el formato correcto la información solicitada.
3.1.3 Pantalla CuentaPerfilX
En esta pantalla el usuario final tiene acceso a una cuenta, donde puede navegar por diferentes opciones de menú dependiendo de su perfil.
3.1.4 Mensajes de error
Aquí se pueden dar varios errores. Por ejemplo, si la conexión se pierde con el servicio web o base de datos de las cuales consume sus recursos, el sistema genera un mensaje de error informando el inconveniente.
3.1.5 Pantalla Gestión CarbonoNeutralidad
En esta pantalla el usuario final tiene acceso a diferentes opciones para administrar generación de aportes de neutralidad.
3.1.6 Mensajes de error
Aquí se pueden dar varios errores:
1. Perdida de conexión de la aplicación.
2. Digitalización errónea de información en los formularios.
3.1.7 Pantalla Notificación
En esta pantalla el sistema está automatizado para gestionar diferentes notificaciones a varios perfiles de usuario.
3.1.8 Mensajes de error
Aquí se pueden dar varios errores:
1. Perdida de conexión de la aplicación.
3.1.9 Pantalla CRUDDenuncia
En esta pantalla el usuario final con el perfil correspondiente tiene la opción de gestionar las denuncias (consultar, crear, modificar).
3.1.10 Mensajes de error
Aquí se pueden dar varios errores:
1. Perdida de conexión de la aplicación.
2. Digitalización errónea de información en los formularios.
3.1.11 Pantalla CRUDPropuesta
En esta pantalla el usuario final con el perfil correspondiente tiene la opción de gestionar las propuestas de solución (consultar, generar, modificar).
3.1.12 Mensajes de error
Aquí se pueden dar varios errores:
1. Perdida de conexión de la aplicación.
2. Digitalización errónea de información en los formularios.
3.1.13 Pantalla CRUD RevisionDenuncia
En esta pantalla el usuario final con el perfil correspondiente tiene la opción de gestionar las propuestas de solución (consultar, cambiar estado, modificar).
3.1.14 Mensajes de error
Aquí se pueden dar varios errores:
1. Perdida de conexión de la aplicación.
2. Digitalización errónea de información en los formularios.
3.1.15 Pantalla CRUD RevisionPropuesta
En esta pantalla el usuario final con el perfil correspondiente tiene la opción de gestionar las propuestas de solución (consultar, cambiar estado, modificar).
3.1.16 Mensajes de error
Aquí se pueden dar varios errores:
1. Perdida de conexión de la aplicación.
2. Digitalización errónea de información en los formularios.
4 FAQ
A continuación, se incluyen una lista de las preguntas o dudas más frecuentes (Frequently Asked Questions) que pueden surgirle a un usuario del sistema junto a una explicación para cada una de ellas.
1. ¿Qué es tipo de perfil?
Un tipo de perfil da características propias con las que puede gestionar los problemas referentes al medio ambiente y neutralidad del carbono.
2. ¿Qué es carbono neutral?
Esto significa la reducción de la huella de carbono, es decir que se reducen los gases de efecto invernadero que se generan mediante varias actividades como: quemar basura, botar basura en ríos, tirar baterías y vidrio en el basurero sin dividir y reciclar, etc.
3. ¿Puedo registrarme gratis y ayudar?
Si, la plataforma es un medio de colaboración activa de la población en general sin involucrar no más que regenerar la naturaleza.
5 ANEXOS
Anexar cuantas referencias sean de interés para la comprensión del sistema.
6 GLOSARIO
A continuación, encuentre la definición de algunos de los términos utilizados, y se considere de interés para la comprensión del sistema.
| Término | Descripción |
| Carbono Neutralidad | Reducción de la huella de carbono, es decir que se reducen los gases de efecto invernadero que se generan mediante varias actividades como: quemar basura, botar basura en ríos, tirar baterías y vidrio en el basurero sin dividir y reciclar, etc. |
| MINAE | Ministerio de Ambiente y Energía de Costa Rica. |
6 BIBLIOGRAFÍA Y REFERENCIAS
| Referencia | Título |
| ……… | …….. |
| ………. | …….. |
Documento de arquitectura
Alusivo al documento de arquitectura. Antes es necesario mencionar que la base de la arquitectura de la metodología de desarrollo SCRUM, es el Sprint, (Mago y Alférez, s.f.). El Sprint menciona el mismo autor, es un una iteración de 1 a 4 semanas. También, existe un arquitecto que se involucra durante el desarrollo de sistemas, mismo que se encarga de gestionar los distintos Sprints. En este caso en particular, el ejercicio propone describir la documentación de la semana antes de empezar el proyecto. Entonces, se podría documentar 1 “Sprint 0” o inicial para comenzar, no tan extenso pero si necesario para tener una buena planificación. La documentación se muestra en forma de imagen (Imagen Sprint), mismo que se recupera de la lectura del mismo autor, posteriormente se describen los puntos que en ella se observan.
Imagen Sprint
Sprint 0: “Oc2021”
Autor: Mago y Alférez (s.f.).
Como se observa en la imagen Sprint, se encuentra el “concepto del software”, donde se identifica que el sistema va a resolver problemas relacionados con el carbono neutral, se va a utilizar diferentes artefactos y roles de usuarios, entre otros componentes para solventar adecuadamente cada situación, cada uno con sus características correspondientes. Luego, está el análisis de requisitos preliminares, aquí se debe proceder a encontrar e identificar las funcionalidades que forman parte de la aplicación, descartando aquellos que no son fundamentales o necesarios realmente. También, el diseño de la arquitectura y núcleo, en esta etapa se debe concretar la arquitectura óptima para el aplicativo al igual que solventar la identificación y documentación respectiva del núcleo del mismo sistema para tener una calidad idónea al momento de correr el “software”. Más adelante, los documentos de la arquitectura, se basa en un proceso de descomposición basado en los atributos de calidad de software. Igualmente, se encuentra el sistema de evaluación de calidad de sistemas ATAM, el cual se debe elaborar para definir el éxito de un aproximado de interacción de la calidad del sistema. Además, se debe reevaluar para definir la arquitectura del sistema, produciendo en resultado final. Por último se obtiene un esqueleto del sistema, y con este borrador se tiene una documentación preliminar sólida para continuar con la siguiente iteración (Mago y Alférez, (s.f.).
Documento de soporte del sistema para su mantenimiento
En esta documentación se deben colocar los parámetros necesarios para que el usuario final tenga las soluciones más eficientes y sencillas de entender.
En el caso de la estructura de este documento, se procede a tener en cuenta los puntos principales del proyecto; entre las cuales se destacan: tres módulos diferentes principales interconectados con funcionalidades propias, en el primer caso está la aplicación móvil, en segundo lugar la aplicación Back Office y tercero la aplicación Live Map.
Se debe establecer los diferentes componentes de los tres subsistemas, referente a las interfaces, modelos y el control de estos se deben contarse con la documentación interna de la codificación y la documentación externa, modelado de diagramas de bases da datos, documentación de los API’s distintos web services que se consumen, la documentación del gestor de correos para notificaciones, documentación de la arquitectura y el núcleo del sistema. Contar con la planificación escrita disponible del aplicativo. Una página con la información de contacto para errores emergentes con especificaciones muy detalladas del sistema, dificultades técnicas que pueden ser resueltas solo por un especialista en sistemas.
b. Componentes
A continuación, se documentan algunos de los principales componentes de la metodología de desarrollo SCRUM que se deben tener en cuenta para el proyecto “Oc2021”. Ahora, se describen los eventos más significativos, cada uno con su respectivo objetivo y actividades o características. En primer lugar, está el Sprint. Este evento es el corazón de SCRUM, este es a su vez un contenedor de otros eventos, estos eventos son la planificación del Sprint, el objetivo de Sprint, las reuniones SCRUM diarias, las reuniones de retrospectiva, la revisión del Sprint. Un Sprint es un periodo de tiempo determinado y cuando se especifica no se puede acortar ni alargar, por ende durante el Sprint no se puede cambiar el objetivo de Sprint. Por otra parte, si es necesario cancelar un Sprint se deben tomar varios aspectos en cuenta, por ejemplo, si es que el objetivo del Sprint pierde su valor real, es decir que se torna obsoleto, entonces el Product Owner toma la decisión de cancelar el Sprint. Algo muy importante que se debe mencionar es que si se llega a cancelar un Sprint, si es que algunos elementos de la lista del Sprint son relevantes o sumamente importantes para el proyecto, entonces se aceptan para su respectiva entrega, Schwaber y Sutherland (2017).
Por otra parte, los mismos autores mencionan sobre otro evento llamado Planificación de Sprint, los siguientes datos. En este evento todos los miembros del equipo de SCRUM se reúnen para elaborar un plan para cumplir el objetivo del siguiente o primer Sprint. Aquí el Scrum Máster gestiona el tiempo, mismo que para un Sprint tarda 8 horas para una iteración de 1 mes. Existen dos cuestiones muy importantes para llevar a cabo una planificación, estas son que se va a hacer para cumplir con la funcionalidad de esta iteración contenida en la lista de del Sprint, y la otra como lo van a conseguir desde la concepción del diseño de la o las funcionalidades hasta la entrega de elementos de lista terminados. Es durante esta planificación donde nace el objetivo del Sprint.
Más adelante, Schwaber y Sutherland (2017) mencionan otro evento significativo del modelo desarrollo SCRUM, este evento se conoce como Objetivo del Sprint. El objetivo se constituye a partir de los elementos que se desean concretar de la lista del sprint; una vez establecido esta meta se trabaja en equipo para conseguirla. En ocasiones si no se cumplen algunos elementos de la lista del sprint como parte del objetivo, se puede negociar con el dueño del producto para convenir su alcance.
Otro evento que forma parte de este modelo de desarrollo son las reuniones diarias. Las reuniones diarias consisten en determinar que se está haciendo cada día durante un Sprint, esta reunión la conforman el equipo de trabajo (el scrum máster y el equipo de desarrolladores), tarda aproximadamente 15 minutos o menos, el scrum máster controla el tiempo, uno de los miembros del equipo de desarrollo toma el rol de orquestador de la reunión y da las pautas para preguntar y responder a las siguientes cuestiones: que se hizo ayer y que se va a hacer hoy para cumplir el objetivo de la iteración, y también, describir cuál o cuáles serían algunos impedimentos para cumplir con el objetivo del Sprint Schwaber y Sutherland (2017).
Seguidamente, según los autores mencionados antes, el evento conocido como revisión de un Sprint. Este evento es una reunión de aproximadamente 4 horas para una iteración de 1 mes, y menos para un Sprint más corto. Los miembros del equipo y los interesados del Sprint se reúnen para una exposición de los elementos de la lista del producto que se tenían para terminar o desarrollar como objetivo de Sprint, mismos que se modifican o ajustan; el Scrum máster igualmente maneja el tiempo de la reunión y explica el objetivo de la reunión a los demás miembros de la reunión. Este evento incluye una serie de elementos significativos que a continuación se enumeran:
- Los asistentes son el Equipo Scrum y los interesados clave invitados por el Dueño de Producto.
- El Dueño de Producto explica qué elementos de la Lista de Producto se han “Terminado” y cuáles no se han“Terminado”.
- El Equipo de Desarrollo habla acerca de qué estuvo bien durante el Sprint, qué problemas aparecen y cómo fueron resueltos esos problemas.
- El Equipo de Desarrollo hace una demostración del trabajo que ha “Terminado” y responde preguntas acerca del Incremento.
- El Dueño de Producto habla acerca de la Lista de Producto en su estado actual. Proyecta objetivos probables y fechas de entrega en el tiempo basándose en el progreso obtenido hasta la fecha(si fuera necesario).
- El grupo completo colabora acerca de qué hacer a continuación, de modo que la Revisión del Sprint proporcione información de entrada valiosa para Reuniones de Planificación de Sprints subsiguientes.
- Revisión de cómo el mercado o el uso potencial del producto podría haber cambiado lo que es de más valor para hacer a continuación; y.
- Verificación de la línea de tiempo, presupuesto, capacidades potenciales y mercado para las próximas entregas de funcionalidad o capacidad prevista del producto.
Por último, como parte importante de los eventos se encuentra la reunión de retrospectiva. Esta reunión básicamente se trata de una retroalimentación de lo que se hizo durante el Sprint recién terminado, esta reunión se da en medio de la finalización de un Sprint y el comienzo de otro. Es una reunión donde el scrum máster tiene mucha más participación que solo controlar los tiempos de la reunión, si no que forma parte importante, ya que debe rendir cuentas al product owner igual que el resto del equipo scrum. La reunión retrospectiva consta de 3 horas para una iteración de 1 mes, igualmente durante el tiempo de esta reunión se plantean varias preguntas relevantes para la retroalimentación y cumplimiento del objetivo de la misma, como por ejemplo, “Inspeccionar cómo fue el último Sprint en cuanto a personas, relaciones, procesos y herramientas. Identificar y ordenar los elementos más fundamentales que salieron bien y las posibles mejoras. Crear un plan para implementar las mejoras a la forma en la que el Equipo Scrum desempeña su trabajo”. Schwaber y Sutherland (pág. 14, 2017).
Referente a los roles del modelo de desarrollo de SCRUM, seguidamente se detallan sus tareas más considerables. En primer lugar, se encuentra el product owner, es el encargado de elaborar la lista del producto, es decir que está en contacto directo con el cliente que desea desarrollar el sistema; esto lo hace el responsable directo de manejar la lista del producto, que en teoría para que se desempeñe con eficiencia el resto del equipo Scrum deben respetar sus decisiones. Ahora, una tarea sumamente significativa es la de generar y gestionar la lista de producto, otra es desarrollar una lista de producto clara ordenada y optimizada para el resto del equipo de trabajo; y por último la responsabilidad de permanecer el contacto directo con el cliente dueño del proyecto y hacer cumplir los requerimientos o elementos de la lista Palacio (2015, pág. 33).
En segundo lugar, según el autor mencionado antes se encuentra el scrum máster. Este es el encargado de gestionar los tiempos de las reuniones dentro de cada Sprint, también, se encarga de dirigir y hacer entender las reglas de la organización, es decir que es el líder del equipo; el scrum máster es el enlace entre el equipo de trabajo y el producto owner o dueño del producto. Algunas de las tareas más significativas que realiza un scrum master son: asesorar y formar el equipo de trabajo de desarrollo, funciona como moderador de las reuniones y también da solución a los impedimentos que puedan bloquear el trabajo de cada Sprint (dinamiza las reuniones).
Por último, el otro rol es de Equipo de trabajo o desarrollo. El mismo autor describe que este lo conforman miembros profesionales en uno o varios campos que trabajan en conjunto para cumplir con los objetivos de cada Sprint. Cada miembro puede ser o no especialista en un campo o varios, pero al final todos trabajan en conjunto con un fin específico. Las tareas más importantes del equipo de desarrollo son las siguientes: todos los miembros participan en las decisiones de cada reunión; igual cada miembro del equipo conoce a cabalidad la visión del dueño del producto; y también colaboran y ayudan al dueño del producto con la realización de la pila del producto.
A continuación se describen los artefactos del modelo SCRUM al igual que sus respectivas funciones dentro de la metodología. Para empezar según Schwaber y Sutherland ( 2017), el artefacto conocido como la lista del producto, este artefacto consiste en una serie de requisitos que puede alargarse o no dependiendo del valor dentro del mercado; por otra parte, es cambiante, es decir que al inicio del proyecto se conocen los elementos que se consideran más relevantes para realizar el mismo, sin embargo, puede evolucionar según lo que se requiera adaptar para mejorar su funcionalidad. La lista del producto es manejada por el product owner desde el principio. La lista del producto consta de una serie de elementos que representan las funcionalidades, requisitos y mejoras del sistema. Una lista tiene según el mismo autor mencionado con anterioridad “como atributos la descripción, el orden, la estimación y el valor” (pág. 15, 2017). Cada atributo va más o menos detallado dependiendo de su prioridad dentro de la lista. Por otra parte, cada elemento de la lista tienen un estado dentro de la lista, esta son conocidas como terminado (final), en proceso (en acción) y preparado (listado).
Otro artefacto que mencionan los mismos autores es la lista de Sprint. Esta lista está presente durante cada Sprint, que significa que son una serie de tareas dirigida para el equipo de trabajo o desarrollo, que en conjunto con un plan de entrega cumplen con el fin de cumplir con el objetivo del Sprint. Esta lista varía su prioridad dependiendo de varios factores, por ejemplo, de la retrospectiva que se da al finalizar cada Sprint; esta lista evoluciona respecto al avance del Sprint, puede modificarse según especificaciones determinadas por el equipo al avanzar en el proyecto.
Por último, otro artefacto es el incremento. El incremento es el conjunto de la lista de sprint culminados en cada Sprint o iteración. Según Schwaber y Sutherland describen que “Al final de un Sprint el nuevo Incremento debe estar “Terminado”, lo cual significa que está en condiciones de ser utilizado y que cumple la Definición de “Terminado” del Equipo Scrum” (pág. 17, 2017). Entonces, se puede inferir que su propósito principal es documentar todos los elementos finalizados de la lista del producto que funcionan como una guía durante el proyecto y que al final provee un respaldo para verificar el objetivo principal del proyecto.
c. Base de Datos
Seguidamente, se expone el diseño de la base de datos del aplicativo móvil, back office y live map, es decir total del proyecto. La base datos se muestra en un modelado de diagrama. Se muestra el diagrama de la base de datos en formato de imagen (Imagen Base de Datos). Se usa el sistema en línea “lucidchart” para diseñar el diagrama, con sitio web oficial “lucidchart.com”.
Imagen Base de Datos
Diagrama Base de Datos: Proyecto “Oc2021”
Autor: propio
7. Rediseño de algoritmo siguiendo el principio de responsabilidad única
Seguidamente, se detalla el funcionamiento de un algoritmo o método o funcionalidad o módulo u objeto, la cual debe cumplir con los principios fundamentales de la programación con el fin de alcanzar una codificación eficiente u óptima, capaz de satisfacer los fundamentos SOLID, donde la S significa “Single responsibility principle” o Principio de responsabilidad única por su traducción al español; la O significa “Open/closed principle” o Principio de abierto/cerrado traducido al español; la letra L quiere decir “Liskov substitution principle” o Principio de sustitución de Liskov por su traducción al castellano; la I significa “Interface segregation principle” o Principio de segregación de la interfaz traducido al español; y por último la D que significa “Dependency inversion principle” o Principio de inversión de dependencia en español (Macias, 2019).
Los parámetros que diferencias un método con el principio de responsabilidad única, el autor (Leiva, 2016), menciona algunos de ellos, entre los cuales se destacan la reducción de líneas, adaptable y es sencilla de testear. En resumen, según el autor mencionado antes, el principio fundamental de la responsabilidad única se basa en que el módulo u objeto realice un solo objetivo, sin mezclar alguna otra funcionalidad.
Algunas de las consecuencias de mantener la codificación propuesta son varias. El mismo autor describe algunas de ellas; una es, eventualmente la codificación puede adaptarse a cambios, si se mantiene un módulo con muchas funciones dentro de él, podría presentar problemas de comunicación y tener que utilizar paquetes necesarios, API’s, entre otros recursos, por ejemplo, dentro de un objeto o clase que al final se va a desperdiciar recursos. Otra consecuencia se basa en el control de la clase o clases, podría presentar problemas al momento de hacer pruebas y detectar errores mediante el “debugging”. Otro desenlace negativo es cuando se necesita de un código limpio y eficiente, donde si no se emplean los principios mencionados antes, se puede caer en código redundante y mucho más complejo de manejar.
Algunos de los cambios que se sugieren para usar codificación SOLID correctamente, es separar los métodos expuestos por el compañero, y hacer varios cambios. A continuación, se muestra la codificación modificada, siguiendo las base de calidad de un código optimizado y eficiente.
////////////////////////////////////////////////////////////////////codigo/////////////////////////////////////////////////////////////////////
class DenunciaController {
public DenunciaController(){}//fin constructor
public Denuncia CrearNuevaDenuncia(string param1, string param2, string param3, string param4, string param5)
{
var denuncia = new Denuncia();
denuncia.Titulo = param1;
denuncia.Descripcion = param2;
denuncia.Latitud = double.Parse(param3);
denuncia.Longitud = double.Parse(param4);
denuncia.Estado = (EstadoDenuncia) int.Parse(param5);
return denuncia;
}//fin metodo CrearNuevaDenuncia
//otros metodos
}//fin clase DenunciaController
class DenunciaBBDD{
public DenunciaBBDD(){}
public void GuardarEnBaseDatos(Denuncia denuncia)
{
BaseDeDatos.Guarde(denuncia);
}//fin metodo GuardarEnBaseDatos
//otros metodos
}//fin clase DenunciaBBDD
////////////////////////////////////////////////////////////////////codigo/////////////////////////////////////////////////////////////////////
En cuento a las validaciones de los atributos de la clase “Denuncia” se pueden controlar desde el modelo con un paquete para tal fin, por ejemplo, DataAnnotations en el código de programación c#; de este modo en la clase DenunciaController el método “CrearNuevaDenuncia” solo va a cumplir con un solo propósito, cargar un objeto de tipo Denuncia.
8. Rediseño de algoritmo siguiendo el principio de abierto/cerrado
En el punto anterior, se menciona la conceptualización del principio en cuestión. Tomando en cuenta la descripción que detalla el autor Leiva (2016), se propone el rediseño de la codificación propuesta en el ejercicio para cumplir con los fundamentos SOLID. A continuación, se agrega el código necesario para cuando se detectan problemas de ambiente en el océano.
////////////////////////////////////////////////////////////////////codigo/////////////////////////////////////////////////////////////////////
public class DenunciaOceano : Denuncia
{
//constructor
public DenunciaOceano()
{
Tipo = “Oceano”;
}//fin constructor
//metodos
protected override NivelDeImpacto CalculeImpacto()
{
var mes = Fecha.Month;
if(Calendario.EsDeLaTemporadaCritica(mes))
return NivelDeImpacto.Critica;
return NivelDeImpacto.Moderado;
}//fin metodo NivelDeImpacto
//otros metodos
}//fin clase DenunciaOceano
////////////////////////////////////////////////////////////////////codigo/////////////////////////////////////////////////////////////////////
En esta ocasión, se observa en el código anterior las siguientes características. Se crea una clase “DenunciaOceano” que hereda de la clase Denuncia; también se sobreescribe el método “CalculeImpacto”, con la intención de devolver un objeto “NivelDeImpacto”, colocando la condición respectiva (“Moderado” o “Critica”), dependiendo del mes; en esta condición se implementa un método que verifica el mes que entra como parámetros y definir si entra en el nivel de impacto correspondiente y se devuelve el objeto verificado. Esta codificación se presenta de esta manera siguiendo la condición de apego del diseño ya planteado, es decir que se sigue la misma lógica.
En esta ocasión se cumple con el principio Open/Closed por varias razones; una es que a medida que se necesite extender el funcionamiento de requisitos no es necesario modificar las clases existentes, simplemente se genera una clase que herede los atributos y características de otra que ya existe y está diseñada para extenderse. Otra es que algunas clases, la que se utiliza a menudo “Denuncia”, no es modificable desde afuera, es decir que esta cerrada a posibles modificaciones (Leiva, 2016).
9. Despliegue de datos de la denuncia en pantalla
En primer lugar, la codificación propuesta cumple con el principio de responsabilidad única hasta cierto punto, donde los métodos cumplen un solo propósito, pero dentro de una sola clase, ya que ambos métodos son privados y estáticos, lo cual evita que puedan ser instanciados fuera de esta clase o módulo. Por otra parte, en cuanto al principio de open/close no lo cumple, ya que los métodos estáticos no se podrían modificar, sin embargo, tampoco está abierta a ser extendida de ser requerido.
Cuando se habla del principio de sustitución de Liscov dice el autor Leiva (2016), que este propósito se base en:
“Si en alguna parte de nuestro código estamos usando una clase, y esta clase es extendida, tenemos que poder utilizar cualquiera de las clases hijas y que el programa siga siendo válido” (pág. 10).
El código propuesto no hace extensiones de ninguna clase, por lo tanto, se puede afirmar que no cumple con el principio.
Referente a la solución propuesta en el punto anterior, donde se habla sobre el principio open/close, en este caso en particular el principio de sustitución de Liscov, no lo cumple, porque la herencia que se maneja esta funcionando correctamente, pero no óptimamente según el principio de sustitución de Liscov, por ejemplo, de la clase “Denuncia” hereda todos los métodos a las clases hijas, y en palabras sencillas no quedan métodos que no se empleen cuando se instancia, pero, si necesita reconocer el tipo de clase (dependiendo del problema, sea denuncia tipo incendio forestal, urbana o de océano) para poder imprimir su información en consola.
10. Denuncia positiva para el ambiente
El código planteado no cumple alguno de los principios SOLID. A continuación, se describen los fundamentos para sostener esta afirmación. En primer lugar, el principio de sustitución de Liscov, ya que maneja un método sobreescrito que no se utiliza y lanza una excepción en este caso en particular. Por otro lado, en cuanto al principio de segregación de interfaces, donde el autor Leiva (2016), este principio se basa en que ninguna clase debe depender de métodos que no usa, lo cual es precisamente lo que hace la clase “DenunciaOceano” cuando hereda el método abstracto “NivelDeImpacto”, aunque no lo necesita.
Una de las soluciones que se propone es la siguiente. Para cumplir con los principios SOLID, se puede rediseñar el código de la siguiente manera. Modificar la clase “Denuncia” de ser abstracta a una interface, donde se cambien los métodos protegidos por metodos publicos, de esta manera cuando las clases “DenunciaDeIncendioForestal”, “DenunciaUrbana” y “DenunciaOceano” podran implementar la clase “Denuncia” y poder reescribir sus métodos con los parámetros y características que necesita, todas con los mismos nombres, para cuando vayamos a instanciarlas en otra clase se pueda reutilizar código, donde el sistema va a reconocer cuál clase implementa, por ejemplo en un método que despliegue la información en pantalla (ventana, consola).
Entre las consecuencias negativas que podría presentarse como resultado de la implementación de la codificación planteada están, el uso de recursos innecesarios en el sistema, si por ejemplo, se maneja un método abstracto innecesario, como el sugerido, donde se lanza una excepción, si se emplea de forma incorrecta el programa podría fallar. Otra consecuencia se basa en el modelado de objetos de la vida real, donde muchas veces es recomendable no modelarlo exactamente como se percibe en la vida real, sino, que para optimizar el código y evitar errores se pueden hacer “tests” y comprobar la optimización de objetos, módulos, métodos y otros.
Conclusiones
A continuación, se describen algunas conclusiones luego de terminada la compilación de información del tema en cuestión.
En primer lugar, se logra alcanzar con éxito la generalización de la captura de información referente a principios de diseño y desarrollo de sistemas.
Como segunda posición, se consigue específicamente modificar y optimizar el código planteado como práctica; también, se modelan las historias de usuario propuestas; por otra parte, se precisa el uso de una de las metodologías empleadas para la creación de sistemas de información; además, se explica la concepción de algunos términos al igual algunos de sus propósitos que se utilizan en patrones de arquitectura de sistemas.
En tercer lugar, es igualmente significativo destacar el proceso de desarrollo y diseño de programas tecnológicos, en esta investigación, se alcanzaron varios fundamentos del mismo, con el fin de concretar un producto y servicio de alta calidad, donde siempre se debe contar con una guía y pautas claras y eficientes.
En el cuarto sitio, es destacable manifestar que el conocimiento adquirido es vital para la práctica del curso y la temática en cuestión dentro de la carrera, ya que el diseño, y un buen y claro planteamiento dan un cimiento y entendimiento fuerte para desempeñarse en cualquier campo de sistemas y tecnología.
Por último, es preciso distinguir referente a la codificación, que un algoritmo cualquiera que sea es igual de importante para que todo el sistema funcione de forma óptima; entonces, al igual cualquier detalle en programación, en las distintas áreas que la componen, diseño, “front-end”, “back-end”, bases de datos, arquitectura, y otros elementos, va a inferir en los resultados finales de la aplicación o programa; en fin, un buen sistema alcanza el éxito desde su planificación hasta la última línea de código puesto en producción.
Referencias Bibliográficas
Betancur, J. (2018). HISTORIAS DE USUARIO: EN BÚSQUEDA DEL ENTENDIMIENTO COMPARTIDO. Recuperado de https://julibetancur.blog/category/historias-de-usuario/
Campderrich Falgueras, B. (2013). Ingeniería del software. Editorial UOC. Recuperado de
Instituto Politécnico Nacional. (s.f.). Diseño Arquitectónico. [archivo PDF]. Recuperado de http://upiicsa.tecnologia-educativa.com.mx/docs/u2/s3/DISENO%20ARQUITECTONICO.pdf
Junta de Andalucía. (s.f.). Marco de Desarrollo de la Junta de Andalucía – Guía para la redacción de casos de uso. Recuperado de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/416
Junta de Andalucía. (s.f.). Plantilla Manual de Usuario. Recuperado de
http://www.juntadeandalucia.es/servicios/madeja/contenido/recurso/465
Leiva, A. (2016). Principios SOLID. Recuperado de https://architectcoders.com/wp-content/uploads/2019/08/principios-solid-devexperto.pdf
Macias, C. (2019). Principios SOLID. Recuperado de https://enmilocalfunciona.io/principios-solid/
Mago, E., y Alférez, G. (s.f.). El Papel de la Arquitectura de Software en Scrum. Recuperado de https://sg.com.mx/revista/30/el-papel-la-arquitectura-software-scrum
Menzinsky, A., López G., y Palacio, J. (2018). Historias de Usuario. [archivo PDF]. Recuperado de https://scrummanager.net/files/historias_usuario_scrum_manager.pdf
Palacio, J. (2015). Scrum Manager I Las reglas de scrum. [archivo PDF]. Recuperado de https://www.scrummanager.net/files/scrum_I.pdf
Rehkopf, M. (2021). Historias de usuarios con ejemplo y plantilla. Recuperado de https://www.atlassian.com/es/agile/project-management/user-stories
Sanders, M. (2018). Top 5 takeaways from User Story Mapping. Recuperado de https://medium.com/@mal.sanders/top-5-takeaways-from-user-story-mapping-by-jeff-patton-f8c80cf73750
Schwaber, K., y Sutherland, J. (2017). La Guía de ScrumTM. [archivo PDF]. Recuperado de https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Spanish-SouthAmerican.pdf
Schwaber, K., y Sutherland, J. (2020). La Guía Scrum. [archivo PDF]. Recuperado de https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Spanish-European.pdf
Sobczak, K. (2020). Historias de Usuarios. Recuperado de https://henryksobczak.medium.com/historias-de-usuarios-fcbd6dba29e8
Summerville, I. (2011). Ingeniería de Software. Recuperado de https://elibro-net.cidreb.uned.ac.cr/es/ereader/uned/37857?page=1
Vila-Grau, J. (2017). Cómo generar un Backlog de Producto: el mapa de historias de usuario. Recuperado de https://proagilist.es/blog/agilidad-y-gestion-agil/generar-backlog-producto-mapa-historias-usuario/
