Metodología¶
Primeramente observaremos que el estilo de desarrollo de software se basa en el modelo V que divide el proceso en 3 partes: diseño, implementación y pruebas. Las razones por las que se escogió este estilo de desarrollo van desde el énfasis que necesitamos en el testeo de los módulos hasta la detección y validación de errores en etapas tempranas del desarrollo.
Requerimientos¶
Una vez que se tiene el concepto claro de la nueva característica o módulo del proyecto se da paso a plasmarlo en un issue de Gitlab o la herramienta de versionado que se esté utilizando. Aquí se comentará y preguntará todo lo relacionado a la nueva característica, pasando desde detalles globales a los más especificos, donde las dos partes (ingeniería y el área que pide el módulo), moldearán el concepto previo hasta llegar a la funcionalidad de la característica.
Las herramientas disponibles para esta etapa:
Issue de gitlab para tener un seguimiento de todo lo que se ha propuesto.
Se debe hacer la prueba del caso de uso para el final de desarrollo, teniendo así un panorama general de como se visualiza al terminar este.
Diseño¶
Ya conociendo los requerimientos, pasariamos a la etapa del diseño, donde determinaremos cual parte del proyecto se va a modificar. Esto podría ser desde un archivo hasta una gran parte del árbol de directorios, dependiendo de los requerimientos. Al final de esta etapa se debe tener claro los pasos que se realizarán para llevar a cabo la modificación.
Se seguirá plasmando las ideas obtenidas en el issue para tener así el seguimiento completo.
Se comenzará a escribir los test de integración necesarios para probar la funcionalidad.
Diseño del software¶
En está etapa se empieza a decidir que parte del software se modificará. Desde que líneas se tienen que eliminar o aumentar hasta que clases o funciones se necesitan. Esto para no modificar otras partes del código original y solo tener líneas concisas que se verán reflejadas en el merge request o en cada uno de los commits.
Se creará un merge request desde el issue (o agregar que issue se debe de cerrar), empezando así el seguimiento pero ahora del código.
Se debe de empezar a escribir las pruebas funcionales para las modificaciones del código.
¡Ahora sí, a escribir código!¶
Empezaremos a escribir el código necesario en la rama del feature pero tomando en cuenta que cada uno de los proyectos tiene su guía de estilos. NO SE DEBE de romper la guía de estilos ya preestablecida. En esta parte del desarrollo, la decisión de cuándo está listo el código, es del maintainer de cada repositorio.
Se debe de escribir las pruebas unitarias de cada funcionalidad escrita, a menos que ya estén escritas, estas deben de pasar junto con las modificaciones que hemos hecho.
Para este punto es muy importante la herramienta de gitlab y conocer su funcionamiento para poder reportar tus cambios adecuadamente, para ello, sigue estos pasos:
Previamente deberás crear una rama para tus funciones o correcciones de errores con nombres breves y descriptivos de la función o el error a corregir (en inglés) agregando una descripción del problema o función a cambiar o arreglar (en español). El fork debe realizarse desde la rama de desarrollo, a menos que la función o corrección de errores sea especial. Si alguien crea un issue, puedes crear la rama desde allí, incluso un merge request.
Clona el repositorio de manera local o sincroniza los cambios y trabaja en la rama creada para el issue.
Cada commit debe intentar resolver un cambio lógico simple. No hagas varios cambios en un solo commit. Si ya escribiste mucho código, herramientas como «git add -p» te ayudarán a elegir qué cambios incluir en un commit.
Debes describir tu trabajo en cada commit. Usa “git commit -m «Message…» para detallar los cambios realizados en dicho commit.
Una vez que creas que la característica (o el error) está solucionado, debes realizar un “git push” para enviar tus cambios al repositorio y posteriormente crear un merge request en el que se debe asignar un mantainer. El mantainer evaluará tu código y, si hay algo que debas cambiar en el código, lo harás. Esta última tarea se puede repetir muchas veces. Si tu código es correcto, el mantainer fusionará tu rama con la rama de desarrollo y pasarás a la siguiente edición.
¡Pruebas!¶
Todas las pruebas: unitarias, funcionales y de integración; deben de ejecutarse automáticamente (idealmente). Se ejecutarán TODAS (las escritas en este ciclo y las del propio proyecto), así podremos observar en que nivel del desarrolllo podría estar fallando el código.
Algunas pruebas de integración y las pruebas del sistema se deben realizar con ayuda de ciertas herramientas:
SIL (Software in the loop)
HIL (Hardware in the loop)
Manejadores de Use Case Testing (TestLink)
Dependiendo de donde se encuentren los errores de las pruebas (como se muestra en la imagen del modelo), volveremos a ese punto para verificar lo que se ha hecho.