Metodologías ágiles aplicadas al desarrollo de sistemas embebidos
J. Jorge, J; Moretti I.; Caniglia C.; Amado, J.; Puntillo D.; INTI Córdoba
jjorge@inti.gob.ar,labdei@inti.gob.ar
OBJETIVO En sucesivas encuestas y en diálogos con personas del medio, se detectaron falencias importantes en lo que a proceso de desarrollo se refiere. Muchas empresas poseen sistemas de calidad, pero estos se encuentran levemente acoplados a los procesos de desarrollo. Además es evidente que estos últimos no son demasiado eficientes.
El objetivo de este trabajo consistió en desarrollar, adaptar e implementar un proceso de desarrollo para sistemas embebidos utilizando metodologías ágiles, realizar una implementacion de referencia y verificar los resultados.
DESCRIPCIÓN Los sistemas embebidos son particularmente complejos y diferentes de un sistema que solo incluye desarrollo de software. En la mayoría de los sistemas embebidos es necesario el desarrollo tanto del “hardware” como del “software”.
Por otro lado, ya nadie cuestiona las bondades de las metodologías ágiles y esto hace que sean cada vez más utilizadas en la mayoría de las empresas de software (1)(2)(3).
Para este trabajo se utilizó un proyecto definido anteriormente. Este proyecto plantea el desarrollo de un dispositivo que involucra la participación de un equipo multidisciplinario de desarrollo. Se contaba con personal con formación mecánica y personal con formación electrónica/software.
Luego de un relevamiento inicial se detectó la necesidad de un esquema de gestión de configuración. Se establecieron criterios de ubicación de archivos, nomenclatura de documentos, y se capacitó al equipo para que pueda utilizar herramientas de gestión de versiones. Se seleccionó una herramienta denominada “Subversion”, la misma se integró fácilmente con el entorno de trabajo del equipo y la mayoría de las aplicaciones en curso.
“Subversion” se utiliza para todos los elementos del proyecto, ya sea código fuente,
esquemáticos de “hardware”, diseño de piezas, etc.
Figura 1: “merge” de un circuito impreso modificado por dos personas de manera simultanea. Aqui se resaltan las firerencias para que puedan ser arregladas.
El siguiente paso fue establecer un proceso de desarrollo. Se realizó un taller sobre los diferentes procesos de desarrollo y luego se dejó al equipo decidir qué tipo de proceso les resultaba mejor. El equipo remarcó la importancia de realizar desarrollos iterativos e incrementales.
Luego se dividió al equipo en tres grupos, un grupo de mecánicos, un grupo de electrónicos y otro de desarrolladores de software. Esta división es necesaria porque la naturaleza de las tareas, las herramientas y las metodologías son diferentes.
Para cada uno de los equipos se analizó la metodología actual de trabajo y se discutieron nuevas propuestas. Continuamos con la explicación de conceptos de calidad de sistema, detalles específicos de los sistemas embebidos y el “Ciclo de desarrollo ágil”, (Agile Software Development Cicle o SLDC).
Si bien las metodologías ágiles surgen y son utilizadas en el desarrollo de software, gran parte de las técnicas ágiles pueden ser utilizadas para cualquier disciplina. Para este grupo de trabajo y para este proyecto se propuso una planificación general de alto nivel, al estilo del desarrollo de software ágil, y luego una división de tareas de acuerdo a la especialidad de cada integrante.
Para la gestión del proyecto se utilizó un SLDC estándar: se definió una planificación de alto nivel, se fijaron los alcances y los objetivos del proyecto. Se relevaron los requerimientos de alto nivel expresados por los usuarios finales
del dispositivo y los especialistas en el tema. Basándose en estos requerimientos los responsables de cada equipo construyen una lista de ítems a resolver (backlog), de esta lista se derivan las tareas de cada integrante.
Dada la naturaleza de las tareas de cada grupo y la ubicación física de los mismos, se fijaron reuniones diarias entre los grupos de electrónica y software, mientras que el equipo de mecánicos se reúne de manera separada. Reuniones semanales para todo el equipo y reuniones mensuales con quién conoce más del producto (usuarios finales o clientes). Las reuniones diarias del equipo tienen como objetivo realizar una revisión del trabajo realizado y asumir el compromiso de una nueva tarea a realizar. Las reuniones semanales tienen como objetivo revisar los avances de manera interna con todo el equipo de trabajo. Por último, las reuniones mensuales tienen como objetivo realizar presentaciones de avance con quién más sabe del producto, retrospectivas para ver cómo mejorar, y posible reorganización o priorización de la lista de tareas.
Para el equipo de software se adaptó un ciclo iterativo incremental utilizando desarrollo dirigido por pruebas (TDD). Dado que el sistema se ejecutará en un procesador ARM, se realiza compilación en x86 y se la verifica con un conjunto de pruebas. Luego se ejecuta la croscompilación para ARM con pruebas en el dispositivo. Además definimos por velocidad y eficacia que los desarrollos se realicen en la PC, que al final del día se croscompilen y se ejecuten las pruebas en el dispositivo. Como se
muestra en la Figura 2.
Figura 2: ciclo de desarrollo para software.
Las verificaciones son una parte esencial del proceso de desarrollo de software, y es la mejor manera de generar código que funcione.
Dado que el nuevo dispositivo utilizará un microcontrolador muy pequeño, se decidió utilizar “uCtestLib”, una librería de pruebas
unitarias y “cMock” para realizar suplantaciones de módulos. Ambas librerías están especialmente diseñadas para sistemas con recursos reducidos.
RESULTADOS Actualmente el equipo se encuentra implementando el sistema, y se espera realizar una revisión y analisis completo al finalizar el proyecto. Sin embargo, de acuerdo a las encuestas y entrevistas mantenidas con el personal, los resultados son altamente satisfactorios. Se observa una mayor concentración en el ambiente de trabajo, el equipo ha mejorado y aumentado la comunicacion entre sus integrantes y los mandos medios están recibiendo nociones concretas del avance del proyecto.
En el equipo de mecánicos es donde menor penetración tuvieron las técnicas ágiles, se acordó participar de reuniones diarias internas y de reuniones semanales.
La herramienta que les resultó de mayor utilidad es el sistema de control de versiones. El mismo fue adoptado rápidamente y su utilización se está extendiendo a otras áreas de la empresa.
CONCLUSIONES Se realizó una asistencia técnica en una empresa donde se capacitó y asistió al presonal en la implementación de metodologías ágiles en el desarrollo de nuevos productos. Primero se analizó la situación y luego junto con el equipo de trabajo se diseñaron y acordaron nuevas formas de trabajo con nuevas herramientas y técnicas de gestión. A partir de ahora, el equipo está implementando el sistema, probando y adaptando su forma de trabajo. Resta esperar el final del proyecto para analizar todos los datos que se estan recabando y compararlos con proyectos anteriores.
REFERENCIAS (1) Scott W Ambler. (2011). 2011 Is the first year where we asked about Lean - ambysoft surveys. (2) Scott W Ambler. (2008) Dr. Dobb's Journal . Agile Adoption Survey. Ambysoft surveys. (3) Scott W Ambler. (2007). Project success s u r v e y .
A m b y s o
Ver+/-
