BiomaSoft: sistema informático para el monitoreo y evaluación de la producción de alimentos y energía. Parte II

Julio Ramiro Quevedo-Benkí y Jesús Suárez-Hernández ]]> Estación Experimental de Pastos y Forrajes Indio Hatuey, Universidad de Matanzas, Ministerio de Educación Superior Central EspañaRepublicana, CP 44280, Matanzas, Cuba
Correo electrónico: julio.quevedo@ihatuey.cu

RESUMEN

Con el propósito de apoyar y facilitar el monitoreo y evaluación (M&E) de la producción integrada de alimentos y energía en Cuba, se diseñó BiomaSoft, un sistema informático para el M&E de la producción integrada de alimentos y energía en municipios cubanos. El objetivo del presente artículo es brindar una descripción de los principales aspectos en la implementación y el desarrollo de dicho sistema, para lo cual se describen textualmente sus casos de uso y se brindan los diagramas de clases del diseño específicos para cada uno. En su conjunto, los aspectos detallados evidencian la forma en que los diferentes actores deben interactuar con el sistema BiomaSoft, diseñado a medida para el apoyo del M&E. Asimismo, toda la información recopilada permitió diseñar y construir una robusta base de datos, capaz de dar sostén a la gran cantidad de información que el sistema debe manipular; y también alcanzar una comprensión profunda del funcionamiento y las capacidades del sistema, para su posterior despliegue.

Palabras clave: base de datos, modelos, proyecto de desarrollo.

ABSTRACT

In order to support and facilitate the monitoring and evaluation (M&E) of the integrated food and energy production in Cuba, BiomaSoft was designed, a computer system for the M&E of integrated food and energy production in Cuban municipalities. The objective of this paper is to provide a description of the main aspects in the implementation and development of such system, for which its use cases are textually described and the specific design class diagrams for each one are provided. As a whole, the detailed aspects show the way in which the different actors should interact with the BiomaSoft system, tailor-designed for the support of M&E. Likewise, all the compiled information allowed to design and construct a robust database, capable of supporting the large quantity of information the system should manipulate; and also to reach a deep understanding of the functioning and capacities of the system, for their later display. ]]> Keywords: database, models, development project.

La utilización de las fuentes renovables de energía, con énfasis en los biocombustibles tanto líquidos y gaseosos como sólidos ha alcanzado un elevado desarrollo en la actualidad a escala internacional (FAO, 2008a; 2008b; IEA, 2013; IRENA, 2014). En Cuba, en los últimos cinco años, también se han logrado avances en el desarrollo de estos biocombustibles (Suárez y Martin, 2012; Cubadebate, 2014; MINEM, 2014; Suárez et al., 2014), con el propósito de contribuir a la seguridad alimentaria, la sostenibilidad energética y la sustentabilidad ambiental a escala local.

A este propósito contribuye el proyecto internacional «La biomasa como fuente renovable de energía para el medio rural cubano (BIOMAS-CUBA)», financiado por la Agencia Suiza para el Desarrollo y la Cooperación (COSUDE) y liderado por la Estación Experimental Indio Hatuey, en seis provincias cubanas. Este proyecto desarrolla experiencias para la producción integrada y sostenible de alimentos y energía que necesitan ser monitoreadas y evaluadas, lo cual puede ser favorecido por un software que facilite y automatice todo el complejo proceso de gestión de la información.

Con tal objetivo se estudiaron diversos sistemas informáticos para el monitoreo, control y/o evaluación de proyectos, como los desarrollados por Allué et al. (2013), Pellerin et al. (2013), Acebes et al. (2014) y Hazir (2015), entre otros, pero estos están enfocados a proyectos de informatización y diseñados para países desarrollados. Por ello, se decidió diseñar a medida, desarrollar e implementar BiomaSoft, un sistema informático para apoyar el M&E de la producción integrada de alimentos y energía, lo cual no tiene antecedentes en Cuba.

El objetivo de este artículo es brindar una descripción del proceso de desarrollo del software que se llevó a cabo en la implementación del sistema¹.

Metodología

A partir de los requerimientos funcionales y no funcionales, el diagrama de casos de uso del sistema, los actores y su descripción general, y siguiendo el flujo de trabajo de la metodología RUP (RationalUnifiedProcess), brindados y descritos en la parte I (Quevedo y Suárez, 2015), se desglosa toda la funcionalidad de BiomaSoft en tres principales casos de uso: «Gestionar datos del sistema», «Gestionar estrategias de dirección», y «Gestionar fichas de seguimiento». A continuación se brinda, mediante un esquema que responde a la metodología empleada, una descripción detallada de cada uno de ellos, así como su específico diagrama de clases del diseño, derivado del genérico Diagrama de Clases del Diseño de BiomaSoft (Quevedo y Suárez, 2015). Esta delineación será útil para una mejor comprensión del funcionamiento del sistema, y para establecer claramente quiénes interactúan con él y cómo lo hacen.

a) Caso de uso Gestionar datos del sistema

1. Descripción textual del caso de uso

En la tabla 1 se brindan los aspectos básicos de la descripción textual del caso de uso Gestionar datos del sistema. Quedan así agrupados el identificador del caso de uso, los actores que interactúan con él, un breve resumen de su funcionamiento, la prioridad que recibirá por parte del sistema, y las condicionesque deberán cumplirse después de que el caso de uso haya sido necesitado y satisfactoriamente utilizado.

El Flujo normal de eventos, o sea, el comportamiento del sistema en respuesta a una solicitud del actor o usuario, se muestra en la tabla 2. De esta forma se lista cada acción del actor, en orden sucesivo, y la respectiva respuesta del sistema a cada una de ellas. Se presenta además un prototipo de interfaz gráfica que permite visualizar el aspecto que tendrá el sistema y las acciones que podrá realizar el actor, en el apartado específico del caso de uso Gestionar datos del sistema.

En la tabla 3 se muestra la sección que permite eliminar un dato del sistema. Asociada al Flujo normal de eventos, es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que el actor accediese previamente a la opción Eliminar dato (véase tabla 2).

La sección que permite editar un dato del sistema se describe en la tabla 4. Es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que el actor accediese previamente a la opción editar dato,según describe el flujo normal de eventos (véase tabla 2).

En la tabla 5 se muestra la sección que permite adicionar un dato nuevo al sistema. Asociada al Flujo normal de eventos, es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que el actor accediese previamente a la opción Nuevo dato (véase tabla 2). ]]> En caso de que durante el Flujo normal de eventos de estas secciones descritas el sistema verificase algún error en los datos introducidos, se procede a un flujo alterno para evitar daños en los datos manipulados e informar al usuario. En la tabla 6 se describe un flujo alterno para la edición o la adición, ante un suceso no esperado.

2. Diagrama de clases del diseño

El diagrama de clases del diseño (fig. 1) se basa en el propuesto por Quevedo y Suárez (2015), peroenfocado al caso de usoGestionardatos del sistema un diagrama similar se presenta para losrestantes dos casos de uso. Este diagramapermiteorganizar, según propone el patrónarquitectónicoModelo Vista Controlador (MVC), las clases y componentesutilizadosendichocaso de uso. Elloposibilitaestructurarloscomponentes, segúnReenskaug et al. (1995), Jacobson et al. (1999) y la ISO/IEC (2014), como se muestra a continuación:

Modelo: compuesto por el ORM (ObjectRelationalMapping) Doctrine, utilizado por el framework (Symfony) para la gestión y procesamiento de los datos.

Controlador: compuesto por un controlador frontal GestionarProyecto.php, encargado de recibir peticiones (generalmente URL) y, utilizando los componentes de Symfony (paquete que encapsula el funcionamiento del framework), determinar el módulo Acciones y la acción que debe invocar, a fin de responder a la petición recibida.

Vista: compuesta por archivos con sufijo success(ListarDatosSuccess, NuevoDatoSuccess, y EditarDatoSuccess), encargados, en conjunto con el Layout, de adherir los resultados de las acciones, utilizados luego por el controlador frontal para construir las páginas cliente GestionarDatosIndex, que son las que finalmente serán mostradas al usuario.

b) Caso de uso Gestionar estrategias de dirección

1. Descripción textual del caso de uso

En la tabla 7 se brinda una descripción textual del caso de uso Gestionar estrategias de dirección. Se agrupan el identificador del caso de uso, los actores que interactúan con él, un breve resumen de su funcionalidad, la prioridad que recibirá por parte del sistema, y las condiciones que deberán cumplirse cuando el caso de uso haya finalizado.

El flujo normal de eventos se presenta en la tabla 8; de esta forma se enumera consecutivamente cada acción del actor, y la respectiva respuesta del sistema a cada una de ellas. Se brinda además un prototipo de interfaz gráfica que visualiza el aspecto que tendrá el sistema y las acciones que podrá realizar el actor, específicamente en el caso de uso Gestionar estrategias de dirección. ]]> La sección que permite eliminar una estrategia de dirección se describe en la tabla 9. Es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que el actor accediese previamente a la opción eliminar estrategia,según describe el flujo normal de eventos (tabla 8).

En la tabla 10 se brinda la sección que permite editar una estrategia de dirección. Asociada al flujo normal de eventos, es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, posterior a que el actor accediese a la opción Editar estrategia (véase tabla 8).

La sección que permite adicionar una nueva estrategia de dirección se describe en la tabla 11. Es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que el actor accedió a la opción nueva estrategia, según describe el flujo normal de eventos (tabla 8).

La tabla 12 describe el flujo alterno para la edición o la adición, ante un suceso no esperado, en caso de que durante el flujo normal de eventos de las secciones antes descritas el sistema verificase algún error, para evitar daños en los datos manipulados e informar al usuario.

2. Diagrama de clases del diseño

La figura 2 muestra el diagrama de clases del diseño, que se basa en el propuesto por Quevedo y Suárez (2015) y estáenfocado al caso de usoGestionarestrategias de dirección.

1. Descripción textual del caso de uso

En la tabla 13 se presentan los aspectos básicos de la descripción textual del caso de uso Gestionar fichas de seguimiento. Se agrupan el identificador del caso de uso, los actores que interactúan con él, un breve resumen de este, la prioridad que recibirá, y las condiciones que deberán cumplirse después de que el caso de uso haya sido utilizado.

El flujo normal de eventos describe el comportamiento del sistema en respuesta a una solicitud del usuario (tabla 14). De esta manera, se lista cada acción del actor y la respectiva respuesta del sistema a cada una de ellas; se muestra también un prototipo de interfaz gráfica que visualiza el aspecto que tendrá el sistema y las acciones que podrá realizar el actor en el caso de uso Gestionar fichas de seguimiento. ]]> En la tabla 15 se brinda la sección que permite eliminar una ficha de seguimiento. Vinculada al flujo normal de eventos, es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que el actor accedió a la opción Eliminar ficha (tabla 14).

La sección que permite editar una ficha de seguimiento se presenta en la tabla 16. Es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, después de que se accedió a la opción Editar ficha descrita en el flujo normal de eventos (tabla 14).

La sección que permite adicionar una nueva ficha de seguimiento (tabla 17) está asociada al flujo normal de eventos y es una continuación de la lista de cada acción del actor y la respectiva respuesta del sistema, posterior a que el actor accediese a la opción Nueva ficha (véase tabla 14).

En caso de que durante el flujo normal de eventos de estas secciones el sistema verificase algún error, se procede a un flujo alterno (tabla 6), para evitar daños en los datos manipulados e informar al usuario.

2. Diagrama de clases del diseño

El diagrama de clases del diseño del sistema (fig. 3) se basa en el propuesto por Quevedo y Suárez (2015), peroenfocado al caso de usoGestionarficha de seguimiento.

Con las diferentes definiciones, conceptos, entidades y sus relaciones, se evidenció quiénes interactúan con BiomaSoft (gestores del proyecto y especialistas de monitoreo y evaluación a nivel nacional y local) y cómo lo hacen.

La construcción, presentación y análisis de los diagramas, modelos y descripciones mostrados posibilitó diseñar y construir una robusta base de datos, capaz de dar sostén a la gran cantidad de información que el sistema debe manipular.

Asimismo, se obtuvo una herramienta para apoyar el monitoreo y evaluación de la producción integrada de alimentos y energía; y se logró un mejor entendimiento de la distribución física y lógica de dicha producción, lo que permitió alcanzar una comprensión profunda de su funcionamiento y capacidades, para su posterior despliegue. ]]>  

1. Acebes, F.; Pajares, J.; Galán, J. M. & Lopez-Paredes, A. A new approach for project control under uncertainty. Going back to the basics. Int. J. Project Manage. 32 (4):423-434, 2014.

2. Allué, A.; Domínguez, E.; López, A. & Zapata, María A. QRP: a CMMI appraisal tool for project quality management. ProcediaTechnol. 9:664-669, 2013.

3. Cubadebate. Cuba apuesta por una energía más limpia, diversa y eficiente. La Habana. http://www.cubadebate.cu/especiales/2014/08/14/cuba-apuesta-por-una-energia-mas-limpia-diversa-y-eficiente/#.Wc5bGXop7IU , 2014.

4. FAO. Cambio climático, bioenergía y seguridad alimentaria: opciones para las instancias decisorias de políticas identificadas por las reuniones de expertos. Conferencia de alto nivel sobre la seguridad alimentaria mundial: Los desafíos del cambio climático y la bioenergía. Roma: FAO. p. 42, 2008b.

5. FAO. Política bioenergética, mercados y comercio, y seguridad alimentaria y perspectivas mundiales de la seguridad alimentaria y de los combustibles. Roma: FAO. http://www.fao.org/foodclimate, 2008a.

6. Hazir, O. A review of analytical models, approaches and decision support tools in project monitoring and control. Int. J. Project Manage. 33 (4):808-815, 2015.

7. IEA. Renewable energy. Market trends and projections to 2018. Paris: International Energy Agency, 2013.

8. IRENA. Global bioenergysupply and demand projections for the year 2030. Abu Dhabi, United Arab Emirates: International Renewable Energy Agency, 2014.

9. ISO/IEC. Software engineering. Software product quality. Requirements and evaluation (SQuaRE). Guide. ISO/IEC 25000:2014. Genève, Switzerland: International Standards Organization, 2014.

10. Jacobson, I.; Booch, G. & Rumbaugh, J. The unified software development process. Reading, Mass, USA: Addison-Wesley Professional, 1999.

11. MINEM. Política para el desarrollo perspectivo de las fuentes renovables y el uso eficiente de la energía. XII Seminario Nacional de Energía en apoyo a la toma de decisiones. La Habana: Dirección de Energía Renovable, Ministerio de Energía y Minas. p. 36, 2014. ]]>

12. Pellerin, R.; Perrier, Nathalie; Guillot, X. & Léger, P. M. Project management software utilization and project performance. Procedia Technol. 9:857-866, 2013.

13. Quevedo, J. R. & Suárez, J. BiomaSoft: Sistema informático para el monitoreo y evaluación de la producción de alimentos y energía. Parte I. Pastos y Forrajes. 38 (3):209-215, 2015.

14. Reenskaug, T.; Wold, P. &Lehne, O. A. Working with objects: the Ooram software engineeering method. Upper Saddle River, USA: Prentice Hall, 1995.

15. Suárez, J.; Cabeza, Evelyn & Quevedo, J. R. Formulación de estrategias locales para la producción integrada de alimentos y energía en seis municipios cubanos. Documento interno del proyecto BIOMAS-Cuba. Matanzas, Cuba: EEPF IndioHatuey, 2014.

16. Suárez, J. & Martin, G. J., Eds. La biomasa como fuente renovable de energía en el medio rural: La experiencia de BIOMAS-CUBA. Matanzas, Cuba: EEPF IndioHatuey, 2012.