Recuperación de un sistema agropecuario con Crystal Clear

Transcripción

1 Recuperación de un sistema agropecuario con Crystal Clear Resumen. En el presente trabajo se describe un caso de estudio sobre el desarrollo de un sistema agropecuario. Este sistema surge de un proyecto de investigación, que originalmente consistía en una aplicación de escritorio (etapa 1). Posteriormente, fue convertido en un simulador Web utilizando un ciclo de vida en cascada (etapa 2), donde surgieron varios problemas que pusieron en riesgo la continuidad del desarrollo. El proyecto debió ser sometido a un análisis de relevamiento que permitiera definir el método de desarrollo adecuado para continuar su avance (etapa 3), que fue finalmente aplicado en la etapa 4. El método ágil Crystal Clear fue la opción elegida. La mejora en la comunicación del equipo y la entrega frecuente de código de software usable contribuyeron a la satisfacción del Sponsor. Se concluye positivamente sobre la eficiencia de Crystal Clear para superar, en un corto tiempo (4 meses), las dificultades detectadas en el proyecto. Palabras-claves: Métodos Ágiles, sistema agrícola, experiencia. 1. Introducción Las metodologías tradicionales aplicadas para el desarrollo de software se centran en el control del proceso, estableciendo rigurosamente las actividades, roles, herramientas y notaciones [12]. Las mismas se caracterizan por ser rígidas y dirigidas por la documentación que se genera en cada una de las actividades desarrolladas. Sin embargo, este enfoque no resulta adecuado en los proyectos de entorno cambiante, donde se debe reducir drásticamente los tiempos de desarrollo pero manteniendo una alta calidad [1]. Los denominados Métodos Ágiles (MA) [16] dan respuesta a este tipo de proyectos. El software constituye una herramienta de uso creciente en diferentes dominios y los sistemas agropecuarios no son la excepción. Los sistemas de engorde de ganado basados en pastura son tradicionales en las empresas argentinas [30]. Estos sistemas son complejos debido a que sus componentes (clima, suelo, pastura, consumo del animal, crecimiento del animal, mercado, manejo, etc.) interactúan en el tiempo [26]. Debido a esta complejidad y al alto costo de la experimentación a campo, los modelos de simulación se recomiendan para el estudio de éste tipo de sistemas [20] y para la construcción de sistemas de soporte en la toma de decisiones [8] [21]. Basado en modelos locales de investigación [3], se llevó a cabo un proyecto [28] para desarrollar un sistema de soporte en la toma de decisiones agropecuarias. Durante la ejecución inicial de este proyecto se siguió un ciclo de vida en cascada, pero los problemas

2 crecientes en el proceso de desarrollo pusieron en riesgo concreto al proyecto. Se optó por aplicar un MA particular, Crystal Clear (CC) [6]. Este reporte tiene como objetivo presentar esta experiencia de desarrollo, la cual esta estructurada de la siguiente manera: En la sección 2 se describen las consideraciones del dominio que motivan la construcción del simulador. En la sección 3 se cuentan las etapas de desarrollo del proyecto. La sección 4 justifica la selección de CC y explica su adaptación. En la sección 5 se detalla la auditoria del sistema y la ejecución de cuatro iteraciones del desarrollo. Finalmente, en la sección 6 muestra las observaciones finales y conclusiones. 2. Consideraciones del dominio agropecuario En la actualidad los sistemas económicos en general y el sector agropecuario en particular enfrentan la necesidad y el desafío de gestionar más y mejor información. La planificación y el planteo de estrategias, el incremento de la complejidad y dinamismo de los diferentes sistemas (tecnológicos, productivos, comerciales, financieros, económicos) exigen más del insumo información para el gerenciamiento y la toma de decisión empresaria [25]. Ejemplos de cambios y procesos demandantes de información son, entre otros, el desarrollo de la agricultura de precisión y el manejo diferenciado de sitios específicos dentro del potrero, la intensificación de los sistemas ganaderos, las exigencias de trazabilidad productiva, la difusión de la inseminación artificial, la selección genética, la aparición de nuevos mercados (biocombustibles) entre otras múltiples condiciones. En la ganadería, se incorporan la suplementación estratégica [29] con distintos recursos y planteos de alimentación a corral según circunstancias de mercado y de empresas [9] [30]. Sin embargo, la aplicación de dichas tecnologías de procesos a planteos ganaderos particulares presenta cierta incertidumbre para la toma de decisión, ya que es difícil poder efectuar anticipadamente una valoración adecuada de sus impactos directos e indirectos sobre los animales y el sistema. Esto aún es válido para la transferencia de información desarrollada y demostrada en un contexto de sistema [11], cuando es desafiada con preguntas del tipo que pasa si la relación de precios grano/carne es otra..., a diferente carga animal o si se pretende suplementar una mayor o una menor cantidad, o con otras escalas productivas o si las condiciones climáticas son otras, etc.. Es importante recordar que la actividad ganadera frecuentemente se desarrolla dentro del ámbito de una organización más amplia, la empresa agropecuaria, que constituye la unidad básica para la asignación de los recursos y de la toma de las decisiones. La ganadería y el sector agropecuario en general, están constituidos fundamentalmente por componentes biológicos que son manejados o controlados para lograr un fin económico. Por otro lado, el control y manejo es incompleto, debido a la naturaleza variable del clima y de los mercados. El manejo de sistemas agropecuarios es clave, ya que en virtud del mismo se pueden obtener resultados muy dispares partiendo de situaciones originales similares [26]. Esto último destaca la importancia de las habilidades de manejo físico y comercial, incorporando racionalmente las tecnologías disponibles. La experiencia en el sector, se adquiere al evaluar ciclos de acciones-consecuencias del pasado, en ese mismo o en otros que los decidores entienden como comparables. Para analizar las distintas 2

3 situaciones que surgen, normalmente se suele analizar sus componentes esperando impactos inmediatos. Sin embargo, muchas de las respuestas a acciones de los sistemas se observan con demora (Fig 1). Relacionado a esto, y a modo de ejemplo, se podría mencionar lo dificultoso que suele resultar valorar de forma cuantitativa las consecuencias de algunas relaciones, aún aquellas que son cualitativamente beneficiosas (agricultura-ganadería, cría-invernada, cuando integran un corral a un sistema pastoril, etc.). En el ámbito internacional se han desarrollado y utilizado exitosamente modelos de simulación como herramientas de síntesis de la información disponible [20] [8]. El uso de modelos en nuestro país es creciente, pero mayormente se basan en planteos biológicos definidos, a los que se les calculan y sensibilizan resultados económicos. Acciones Impacto/s Consecuencia/s Impacto/s no detectados o no asociados con las acciones Aprendizaje Habilidad de analizar y plantear alternativas Zona de aprendizaje tradicional Consecuencias/s no detectadas o no asociadas con las acciones Fig. 1. Asociación de impactos y consecuencias para el aprendizaje durante la operación de las empresas agropecuarias. Por los motivos antes mencionados resulta evidente la importancia de disponer de un sistema agropecuario (en adelante simulador) en el que se integre un modelo económico, uno financiero y otro impositivo, donde se pueda observar integralmente el funcionamiento de una empresa agropecuaria y que permita evaluar cuantitativamente distintos cursos de acción a distintos plazos, facilitando el aprendizaje y la toma de decisión. 3. Etapas de construcción del simulador Durante el desarrollo de este simulador se identifican 4 etapas. La primera de ellas ( ) consistió en el desarrollo de una aplicación de escritorio, que implementaba modelos matemáticos (MM) obtenidos a partir de investigaciones de campo realizadas en Argentina. Este primer desarrollo fue realizado por un investigador experto en el dominio para su tesis doctoral [17]. Sin tener conocimientos informáticos previos de programación (y menos aún, de procesos y metodologías para el desarrollo), el investigador supo utilizar de forma correcta el lenguaje Extend [10] (lenguaje de 4ta generación utilizado para realizar simulaciones simples) para implementar sus MM y satisfacer los objetivos originalmente planteados en su tesis. Posteriormente, se definieron nuevos objetivos para el simulador vinculados a su aplicación en docencia y el agregado de varias funcionalidades puso de manifiesto que la plataforma resultó poco flexible e inadecuada. 3

4 Por lo expuesto previamente, se da comienzo a la etapa 2 del proyecto en febrero del 2005, y se decide trasladar el sistema a uno con tecnologías que ofrezcan mayor flexibilidad y oportunidad de concretar los nuevos objetivos. Conciente de sus limitaciones (con respecto al desarrollo de software), el experto del dominio organiza un equipo para llevar a cabo esta actividad y toma la posición de un cliente en el proyecto. El equipo estaba formado por cuatro miembros: un manager y tres desarrolladores; que trabajaban aproximadamente 30 horas semanales en el proyecto. Los requerimientos principales definidos para el simulador incluían: acceso vía Web, inclusión de diferentes perfiles de usuarios y entorno de escenarios, control por reglas de manejo 1 afectadas por diferentes subsistemas (Fig. 2). Fig. 2. Sistema a modelar. La exportación a las nuevas tecnologías no se enmarco dentro de un correcto proceso de desarrollo de software que atendiera las características de este proyecto. Se intentó seguir un ciclo de vida en cascada [4] que a través del tiempo fue manifestando incompatibilidades con la llegada continua de nuevos requerimientos en componentes que se habían considerado estables. A pesar de haber logrado con éxito el traslado del desarrollo inicial del simulador a tecnologías más flexibles, la incorporación de nuevas funcionalidades dejaron en evidencia muchas deficiencias en el desarrollo: Falta de comunicación: El experto de dominio (el cliente) estaba disponible solo una vez (6 horas) por semana. Los desarrolladores se encontraban con dudas que no podían evacuar en las reuniones semanales y muchas veces quedaban aspectos pendientes de explicación que resultaban complejos de ser entendidos por teléfono o correo electrónico. Falta de conocimiento en el dominio de desarrollo: no se tenía en claro la complejidad del dominio del sistema. Las tareas realizadas aportaban información de forma aislada y en consecuencia se cometían errores de implementación que podrían haber sido evitados con un conocimiento más integral y amplio del sistema. Demoras en el tiempo de las tareas: Las reuniones semanales donde el experto de dominio explicaba las características de la tarea a realizar, no agotaban aspectos importantes que modificaban el diseño de la herramienta. Estas fallas eran detectadas cuando se revisaba la tarea y muchas veces debían ser re-implementadas. 1 Una regla es la especificación de una acción que se debe tomar cuando se cumple una condición dada. La condición puede usar uno o más valores del modelo, o constantes. La acción indica que valores se deben modificar en el modelo. 4

5 La Interrupción de actividades dificultaban el desarrollo: En reiteradas ocasiones el cliente realizaba nuevas solicitudes a los desarrolladores y estos debían abandonar las actividades que se estaban llevando a cabo. Los desarrollos terminaban combinando tareas poco relacionadas, haciendo difícil la comprensión de los objetivos perseguidos. Falta de documentación del proceso de software. La documentación de la funcionalidad implementada era escasa: Para saber que era lo que ya se había implementado y la forma en que se hizo, había que referirse al código de la aplicación. En su conjunto, estas deficiencias ocasionaban cierta desmotivación en el equipo de desarrollo. La falta de un proceso de desarrollo acorde a los requerimientos del proyecto conducía al fracaso del mismo. Por esta razón el equipo y el cliente analizaron en una reunión específica las razones posibles de falta de avance en el desarrollo. Esto permitió intercambiar diferentes puntos de vista, así como también imaginar que recaudos deberían considerarse especialmente para una siguiente etapa. Esta instancia de discusión resultó muy efectiva para el cliente, quien decidió continuar con el proyecto, primero realizando una auditoría del mismo (etapa 3) y a continuación se avanzó con las funcionalidades restantes (etapa 4). Dentro de la etapa 3, que comenzó en enero de 2007, se identificó un proceso de desarrollo adecuado para el proyecto. Se realizó una renovación parcial del equipo (dos desarrolladores fueron contratados en otro proyecto y uno nuevo fue incorporado) y se elaboró una lista de requerimientos que debería cumplir el nuevo proceso de desarrollo acorde con las necesidades del proyecto: Adaptarse a la variabilidad de los requerimientos. Contemplar una cantidad reducida de integrantes en el grupo de desarrollo. Ponderar la comunicación entre los desarrolladores y el experto de dominio. Ajustar la comunicación entre los desarrolladores del proyecto. Efectuar muestras frecuentes de los avances. Regenerar la documentación de las funcionalidades ya implementadas. Varias razones indicaban no volver a utilizar un ciclo de vida en cascada. Primero, por no contar con fundamentos explícitos que den soporte a la variabilidad de los requerimientos. Segundo, porque los resultados son observados hacia la finalización del proyecto. Y por último, porque las fallas surgidas en la etapa de testeo de aceptación pueden llevar a un rediseño de la arquitectura del sistema. En consecuencia, se decide optar por un ciclo de vida iterativo e incremental que caracteriza a los métodos ágiles [16], los cuales tienen como principal aspecto la simplicidad y la velocidad. El grupo de desarrollo se concentra solo en las funcionalidades a implementar durante la iteración actual, libera el software rápidamente a los usuarios con el fin de obtener feedback y reaccionar ante éste. Otra característica es que no se invierte demasiado tiempo en la documentación, el cliente es parte del equipo, la comunicación es instantánea y eficiente (grupos pequeños en un mismo sitio). 4. Selección y aplicación de Crystal Clear 5

6 La problemática planteada en el proyecto necesitaba objetivos cortos que permitieran solucionar rápidamente las deficiencias funcionales, a partir de allí, proyectar a futuro objetivos más ambiciosos. El carácter de periodicidad establecida por las iteraciones fijas, que propone Crystal Clear (CC) [6][7] resulta acorde para lograr ese fin. Crystal Clear esta caracterizado por un grupo de trabajo formado por un líder y varios desarrolladores (de 2 a 7) ubicados dentro de un espacio de trabajo común, continuamente radiado de artefactos visuales (como diagramas y mapas varios), de manera que el acceso a la información sea rápido y la comunicación entre desarrolladores sea fluida, libre de distracciones. Los testeos y las entregas periódicas de software son vitales para el ajuste constante de la metodología de trabajo. En CC, cada iteración es independiente y construye una porción de código estable, integrado y testeado. Una iteración agrupa un conjunto de actividades que deben realizarse en un período de tiempo establecido (de una semana a tres meses) dependiendo de la funcionalidad requerida y las estimaciones que los desarrolladores hayan realizado para su implementación. La finalización de una iteración requiere de un análisis completo de los resultados alcanzados a través de Reflection Workshop, reuniones de carácter formal o informal que involucran a todo el equipo. En ellas, se toman las medidas necesarias para continuar mejorando el método a medida que se avanza en las iteraciones siguientes, fortaleciéndolo y perfeccionándolo (ver propiedad Mejora Continua). Finalizar una iteración no significa que se realice una entrega del software, en general ellas representan un release interno para el equipo. Sin embargo, en cada iteración que el equipo planifica, se avalúa la posibilidad de hacer una entrega concreta del software corriendo. A través de ellas el Sponsor puede observar la maduración del equipo y su avance a través del producto materializado; y adicionalmente brindar al equipo de desarrolladores un feedback preciso de las deficiencias detectadas. Planificar una entrega dependerá de las necesidades del Sponsor, de la visibilidad de los requerimientos que deban ser resueltos y de la longitud de la iteración misma. En general, las entregas de software involucran actividades de varias iteraciones, de modo que su frecuencia es menor (Fig. 3). Las entregas de software constituyen el ciclo de entregas y tampoco deben superar los tres meses. Fig.3. Ciclo de entregas. El carácter repetitivo organizado en ciclos de iteraciones y entregas de software, permite la maduración incremental de la arquitectura (Incremental Rearchitecture) y la mejora continua del proceso utilizado en el desarrollo del proyecto (Reflective Improvement) a través de las prácticas que CC enuncia. 4.1 Roles y ambiente de trabajo A continuación, se describen los roles definidos por CC (Fig. 4), y como estos son adaptados de acuerdo a los recursos del proyecto. 6

7 Desarrollador (developer). El grupo de desarrolladores es el motor de producción de software. CC hace una categorización y desagrega este rol en otros más específicos. En este proyecto se adaptó para que los desarrolladores asumieran los siguientes roles: Líder de Diseño (Lead Designer): persona experimentada en el desarrollo de software, capaz de coordinar el diseño y realización del sistema con el equipo de trabajo. Diseñador-Programador (Designer-Programmer): Si bien existe un líder de diseño separado. En CC es deseable que los programadores realicen sus propios diseños. Coordinador (Coordinator): Comunica al Sponsor el estado del proyecto, dándole una visión interna del mismo. Es una ocupación parcial, y puede ser llevada a cabo como un rol adicional por cualquier miembro del equipo con capacidades mediadoras, que facilite discusiones y soluciones a los conflictos. Testeador (Tester): Evalúa el sistema y crea los correspondientes reportes de errores. Documentador (Writer): Documenta el sistema (manual de usuarios, el manual de entrenamiento y otros textos de ayuda). Para llevar adelante el desarrollo de este proyecto se dispuso de dos desarrolladores, que ejecutaron alternativamente los roles especificados con anterioridad, según las necesidades del proyecto en cada una de las iteraciones. Sponsor. Administra los recursos que han sido asignados al proyecto. Esta persona toma las decisiones adecuadas para satisfacer las necesidades que el proyecto demande en función de las disponibilidades y prioridades impuestas desde los niveles superiores. Debe tener una visión a corto y a largo plazo para evaluar el status del proyecto en cada etapa y determinar cómo se dispondrán de los recursos. La visión y las prioridades que motivan al Sponsor no necesariamente son coincidentes con las de la comunidad de usuarios, por lo que se deben adoptar mecanismos de reaseguro para que coincidan. Usuario Experto (Expert User). Lo ejecuta una persona que esta muy familiarizada con el modo de operación del sistema. Tiene conocimiento de las respuestas esperables del sistema ante un evento en particular. Sabe con precisión cuándo, cómo y qué tipo de información debe ser mostrada a los usuarios del sistema, según el perfil de cada uno. El rol del Sponsor y Expert User fue llevado a cabo por una única persona, quien tuvo a cargo de la etapa 1 del proyecto. El equipo de desarrollo solicitó un mayor acceso a la persona que desempeñaba estos roles, por lo que a partir de la etapa 4, este compartió diariamente el ambiente de trabajo. De manera de facilitar la comprensión de CC al Expert User/Sponsor, se realizó un breve entrenamiento del mismo para facilitar la comunicación y el monitoreo de las iteraciones. Usuario Cercano (Friendly User). Se hace referencia a este rol cuando un usuario potencial del sistema se encuentra disponible para asistir a los desarrolladores, mientras trabajan en el proyecto. Para la metodología es un usuario del que se tiene plena disponibilidad durante el desarrollo. Durante el desarrollo del proyecto, se dispuso de diferentes personas que desempeñaron este rol, permitiendo el tratamiento y detección de puntos débiles surgidos desde una perspectiva diferente a la de los demás miembros del equipo. 7

8 Asesor Tecnológico (Software Technology Expert). Este rol le corresponde a una persona que tiene un amplio conocimiento de las tecnologías disponibles en el mercado, que pueden ser útiles para desempeñar alguna actividad del proyecto. Cuando los desarrolladores lo solicitan, El mismo aconsejará en función de los beneficios y de los costos, la tecnología más conveniente a utilizar. Fig. 4. Roles del proyecto. El área de trabajo era una amplia oficina, utilizada durante la etapa 1, 2 y 3 del proyecto (Fig. 5.a). Al inicio de la aplicación de CC, se efectuó un rediseño del uso del espacio disponible. En la nueva oficina se observan dos sectores bien definidos (Fig. 5.b): un área de reunión, cercana al acceso a la oficina, y otra con dos escritorios ubicados de forma paralela donde los desarrolladores desempeñan sus actividades, que incluye radiadores de información (Information Radiators) fácilmente visibles desde distintas distancias. Fig. 5. Área de trabajo. a) Antes de aplicar CC. b) Después de aplicar CC. 8

9 4.2 Propiedades básicas Crystal Clear se basa en un conjunto de propiedades básicas: la entrega frecuente de software, la comunicación cercana y la mejora continua de la forma de trabajo. El cumplimiento de estas propiedades genera una zona segura que indica una buena probabilidad de éxito para un proyecto Adicionalmente CC describe otras propiedades complementarias que disminuyen el riesgo de un desarrollo (Fig. 6). Fig. 6. Zona segura de CC. Lo primordial es el cumplimiento de las propiedades, el procedimiento o método aplicado es secundario. CC es flexible en este sentido y ofrece una librería de prácticas puntuales (técnicas y estrategias), sugiriendo su aplicación. En el desarrollo de este reporte, se destacan aquellas prácticas que el equipo consideró útiles y aplicables al desarrollo del simulador (por ej: Time Boxing, Frequent Integration, Early Victory, Side by Side Programing, Coding Standard, Burn Chart, Information Radiators, Reflection Workshop, Exploratory 360, Incremental Rearchitecture, Methodology Shaping, Blitz Planning, Daily Stand-Up Meetings). Adicionalmente algunas prácticas propuestas en otros métodos ágiles fueron exitosamente adaptadas e integradas al proceso, tales como Self-Directed && Self-Organized, Don t Add Iteration, Block gone in one Day de Scrum [32], Story Cards de XP [16] y las plantillas de RUP [31] para la redacción de artefactos. A continuación se describen las propiedades de CC: Entrega frecuente de software Esta propiedad compromete al equipo de desarrollo a hacer entregas específicas y continuas de software que reflejen el trabajo realizado en cada iteración. Los tiempos de cada iteración son fijados durante su planificación (Time-Boxing) y no pueden extenderse. Relegar la completitud de alguna funcionalidad requerida, suele ser la única solución para llegar al fin de una iteración en la fecha planificada. De la misma forma que se fija la duración de una iteración, las tareas planificadas en ellas son estables (Don t Add Iteration) y la llegada de nuevos requerimientos solo serán atendidos al final del ciclo en la próxima iteración. En este proyecto las integraciones se realizaron al menos una vez por semana, de acuerdo con la práctica denominada Frequent Integration Comunicación cercana Optimiza el flujo de información continua entre los desarrolladores al compartir un ambiente de desarrollo común, como un recurso práctico y económico y de alta eficiencia. La disponibilidad en este proyecto de un ambiente de trabajo común especialmente acondicionado (Fig. 5.b) facilitó la transmisión del conocimiento y 9

10 consenso antes de tomar una decisión frente a un problema. Es importante considerar que esta propiedad requiere definir algunas pautas que eviten interrupciones frecuentes (Ej. Cono de silencio) y disminuya la eficiencia del desarrollo. Adicionalmente, para lograr que el Sponsor tuviera conocimiento de las actividades realizadas se graficaron algunos resultados (Burn Chart) realizados con diagramas de Gantt [19] que mostraban el progreso del equipo Mejora continua Esta propiedad puede sintetizarse como Reflexionar y Mejorar, y permite al equipo ajustar los aspectos del proceso que no lo favorecen durante el transcurso del desarrollo. Esta propiedad abarca desde el cambio de la ubicación de un escritorio hasta el reemplazo de prácticas sugeridas por la metodología. Cambios en las tecnologías de soporte, definiciones de estándares para la programación (Coding Standards), etc., son muchos de los cambios que pueden ocurrir como resultado de una simple reunión formal o informal (Reflection Workshop). 4.3 Otras propiedades Crystal Clear identifica otras propiedades que fortalecen adicionalmente las posibilidades de un desarrollo exitoso (Fig. 6): Respeto mutuo: el hecho de compartir un mismo ambiente de trabajo de forma continua, donde se fomenta la comunicación rescatando diferentes puntos de vistas, requiere especialmente que se mantenga la cordialidad y el respeto dentro del grupo. Esto funcionó muy bien en este proyecto. Los dos desarrolladores han compartido de manera estrecha su formación como profesionales en el área de Ingeniería de Software y conocen las habilidades y las limitaciones de cada uno. El grado de confianza que se ha generado junto al sponsor, permite a los desarrolladores trabajar libremente y les da autonomía para tomar decisiones (Self-Organized and Self- Directed). Foco: esta propiedad destaca la importancia de mantener la concentración en las actividades que realmente son importantes para el proyecto y fueron planificadas para una etapa determinada. Fácil acceso a usuarios expertos: esta necesidad fue planteada por los desarrolladores (durante la etapa 3) y su cumplimiento se hizo efectivo cuando la persona que cumplía con el rol de usuario experto, se estableció de forma permanente en la oficina de trabajo en la etapa 4(Fig. 5 b). Herramientas de test automático, de administración y de integración: el uso de herramientas como SmartCVS Foundation [34] permitieron controlar el versionado y el uso concurrente de código: los desarrolladores trabajaban de forma aislada en sus actividades y luego compartían sus resoluciones con el resto del equipo. Sin embargo, no se dispuso del tiempo para implementar pruebas integrales del sistema mediante test automatizados. Los test fueron realizados manualmente por cada desarrollador y las respuestas del sistema se analizaban con la colaboración del Expert User. 5. Auditoría del sistema e iteraciones de trabajo Una vez seleccionada la metodología, analizado el ciclo de vida y las prácticas a utilizar se dio comienzo a la etapa 4. Siguiendo la práctica Exploratory 360 se 10

11 realizó una auditoria del sistema para hacer un relevamiento de la funcionalidad implementada y evaluar el estado general del simulador. Las actividades de audición se centraron fundamentalmente a la revisión de código, debido a que la documentación existente era escasa y/o desactualizada. Los requerimientos resueltos en etapas anteriores no habían sido testeados, y en otros casos, el estado de su desarrollo era parcial. Esta situación era agravada por la ausencia de documentación válida de soporte, que permitiera a los desarrolladores decidir qué requerimientos estaban resuelto y cuáles no. Por este motivo, el equipo de desarrolladores realizó varias reuniones con el Sponsor con el objetivo de definir claramente los requerimientos más relevantes del sistema y las respuestas que los usuarios debían recibir. Los resultados materializados de estas reuniones dieron lugar a los primeros workproducts: Use Case & Requeriments File. En este se plantearon los casos de uso más relevantes y las respectivas respuestas por parte del sistema. Su contenido puede ser resumido como: El sistema efectuará simulaciones integrales ( whole-farm ) de empresas agroganaderas de la Provincia de Buenos Aires Argentina, permitiendo la evaluación de diferentes estrategias en diferentes escalas de tiempo. Como parte de la auditoria se elaboró una descripción general de la arquitectura del simulador dando origen al workproduct Architecture Description. Donde se expone que la arquitectura utilizada para el sistema era Tres Capas (o Three Tier) (Fig. 7) [2] [33], Capa de Presentación, Capa de Aplicación y Capa de Datos. Fig. 7. Arquitectura Tres Capas. La Capa de Presentación se utilizó OpenLaszlo [22]. El bajo rendimiento, sumado a la insatisfacción del cliente por las interfaces, llevaron a que nunca se integren la capa de presentación y la de aplicación. Durante la auditoria quedó en evidencia que esta capa debería ser mejorada a la brevedad para alcanzar niveles aceptables de rendimiento y la satisfacción del cliente. En la Capa de Aplicación se utilizó el Framework Spring [35] para el manejo de los objetos del negocio y de interfaz hacia la capa de datos. Los dos principales objetos del negocio son Simulator y Simulation, integrantes del paquete simulator (Fig. 8). Simulator administra todas las simulaciones en ejecución y el segundo, representa una simulación particular y sus respectivas características de la empresa integral en un momento dado. 11

12 Fig.8. Diagrama de paquetes (diferentes líneas representan las tareas por iteración). La representación del campo se encuentra en el paquete structure de la Figura 8 y se muestra más detallado en la Figura 9. La clase Farm contiene una o más instancias de las clases Mob y Paddock. La clase Mob representa a un grupo de animales que pastorea en un mismo potrero y puede contener una o más instancias de la clase SubMob. Esta última representa animales de características similares dentro de un lote y contiene una o más instancias de la clase Animal. La clase Animal esta asociada a varias clases que contienen las características particulares de un animal y datos adicionales para el manejo de sistema. La clase Paddock representa el potrero donde las pasturas crecerán y donde los animales (agrupados en Mob) se alimentarán. Esta clase contiene una única instancia de la clase PastureType y una o más instancias de la clase Strip. PastureType representa el tipo de pastura contenida en un potrero. Esta clase contiene la información y comportamiento propio de una pastura en un campo real. Adicionalmente, PastureType tiene una instancia de PastureParams que mantiene y administra información referida al crecimiento de la pastura. Por otro lado, la clase Strip (franja de pastoreo) representa la superficie del potrero sobre la cual los animales pueden comer y moverse en un periodo de tiempo determinado en un paso de simulación (un día por defecto). 12

13 Finalmente, Farm, Mob, SubMob, Animal, Paddock y Strip implementan la interfaz SimulationEntity, utilizada para indicar que sus atributos pueden persistir en la base de datos y formar parte de las salidas. Fig. 9. Diagrama de clases del paquete structure. Como lo muestra la Figura 10, la simulación, atraviesa distintos estados a lo largo de su vida. Inicialmente pasa por el estado Starting, donde se inicializan todos los trabajadores de la simulación. Se denominan trabajadores a las clases destinadas a modificar los componentes del campo durante la ejecución de una simulación. Luego se pasa el estado Running, donde se corren los pasos de simulación definidos en el escenario por el usuario. Cada paso representa un día de simulación y en cada uno de ellos se ejecutan los trabajadores (previamente inicializados). Una vez transcurridos todos los días de simulación que fueron planificados por el usuario, se llega al final de la simulación (fecha de fin en la definición del escenario) y se pasa al estado Finishing. Allí los trabajadores realizan sus acciones de finalización y luego se pasa al estado Finished. Alternativamente, si ocurre una anomalía durante los días de simulación, no se podrá llegar a la fecha definida en el escenario y la simulación pasará al estado Aborting ; los trabajadores abortarán su ejecución y se pasará al estado Aborted. Fig. 10. Diagrama de estado de una simulación. En los diferentes estados de una simulación se ejecutan distintos trabajadores. En la Figura 11 se muestra un diagrama de secuencia de la ejecución de un trabajador durante el estado Running. En este ejemplo, el objeto simulator:simulator manda el mensaje step con simulation como parámetro al objeto growpasture:growpasture, el cual solicita el objeto farm:farm que el parámetro simulation lleva en su interior. A ese objeto farm:farm, growpasture:growpasture hace crecer las pasturas de todos los potreros (paddocks) del campo simulado. 13

14 Posteriormente se envía el mismo mensaje: step(simulation),al objeto sellanimals: SellAnimals(), el cual tratará de vender animales. De esta manera, se ejecutan todos los trabajadores y se avanzará un paso (día), en el cual se volverán a ejecutar todos los trabajadores, de acuerdo al estado de la simulación, hasta llegar al estado Finished o Aborted. Fig. 11. Diagrama de secuencia de los trabajadores. Por otro lado, los trabajadores están divididos en reglas (SimulatorRule) y bloques (SimulatorBlock). La participación de los primeros en una simulación particular depende del escenario que configuró el usuario, mientras que los bloques siempre son parte de la simulación. Alguna acción particular en un trabajador puede activar a otro trabajador, y la comunicación de estas acciones se realiza con una arquitectura de eventos. Por ejemplo, el objeto sellanimals:sellanimals de la Figura 11 al realizar una venta de animales emite un evento, el cual puede ser captado por cualquiera de los demás trabajadores, y actuar en consecuencia. La Capa de Datos utiliza la base de datos Hsqldb [14], configurada para ser utilizada en memoria sin necesidad de almacenar los datos en disco. La base de datos esta preparada para registrar cada paso (o día) de una simulación que este corriendo en el simulador. El simulador toma una simulación y ejecuta un paso, guarda los datos en la base y la devuelve a la cola de simulaciones (al ser un sistema Web, puede haber varios usuarios al mismo tiempo). A partir de esta, el simulador seleccionará otra simulación, ejecutará un paso, guardará la información pertinente a ese paso y la devolverá a la cola. Este proceso se repetirá hasta terminar todas las simulaciones, quedando toda la información en la base esperando para ser mostrada. 5.2 Iteraciones Una vez comprendida la metodología y los roles que cada uno de los miembros debería tomar durante el desarrollo, se realizó el workproduck Mission Statement, donde se delinearon las características y objetivos principales del proyecto. En un fragmento del mismo se menciona: Deseamos conformar un grupo de docenciainvestigación de sistemas ganaderos de una Universidad pública, que dentro de otras actividades, propende a la transferencia tecnológica a otros docentes-investigadores, profesionales y alumnos mediante la aplicación de herramientas informáticas de propio diseño para el apoyo a la toma de decisión. Objetivos estratégicos: Diseñar distintas herramientas informáticas (HI) para el apoyo a la toma de decisión en sistemas ganaderos de la región de influencia de la 14

15 UNCPBA (Universidad Nacional del Centro de la Provincia de Buenos Aires). Estimular el uso de HI por parte de docentes-investigadores, profesionales y alumnos para aumentar la eficacia y la eficiencia de la transmisión del conocimiento referido a la toma de decisión en los sistemas reales de nuestra región. Se desarrollaron luego los workproducts Team Structure and Conventions y Risk List. En el primero se describieron los roles asignados para cada uno de los miembros del equipo. En el segundo, se definieron los riesgos más importantes para proyecto, el que resultó fundamental a la hora de la planificación de las iteraciones, y fue también actualizado durante la ejecución de las mismas. Algunos puntos de la lista de riesgo: Interfaz no amigable. Mantener la coherencia en el ingreso de datos de acuerdo a los distintos perfiles de usuarios. Incorrecta división de perfiles de usuarios, que puede general salidas no pertinentes y un uso inadecuado de la herramienta. La selección de tareas a llevar a cabo en las iteraciones era realizada entre el Sponsor y los desarrolladores, considerando las estimaciones ya establecidas por los últimos (siguiendo la práctica Blitz Planning). En las primeras iteraciones los desarrolladores se orientaron a lograr una pronta satisfacción del Sponsor (Early Victory) mediante la inclusión de tareas que reunieran dos características simultáneas: que fueran de alta prioridad para el Sponsor, y que sus resultados fueran rápidamente visualizados. Adicionalmente, antes de comenzar con las iteraciones, se decide tercerizar la mejora de la capa de presentación a un grupo externo con experiencia previa con la tecnología OpenLaszlo [22]. Esta mejora, de acuerdo a lo detectado en la auditoria, consistía en optimizar el rendimiento de las interfaces y desarrollar algunas pantallas de carga complementarias. En la planificación se utilizaron Story Card`s para identificar las actividades y asentar sus estimaciones. Luego, se convenía una distribución equitativa de ellas (favorecido por el Side-by-Side Programming) considerando las experiencias previas de cada desarrollador, o bien, cada uno seleccionaba a gusto las tareas que prefería desarrollar (Self-Organized && Self- Directed). En algunos casos, la distribución de actividades vinculaba a un desarrollador en particular, para entrenarlo en algún aspecto del dominio o en el uso de tecnologías. Para señalar el progreso de las iteraciones se utilizaron los diagramas de Gantt [15] (ver propiedad Comunicación Cercana) Iteración 1 De acuerdo a la estrategia Early Victory, se decidió realizar una iteración corta de 19 días (22/01/2007 a 09/02/2007) que da inicio a la etapa 4. Se planificaron dos tareas, una fue agregarle al sistema la capacidad de incorporar agricultura a la actividad ganadera existente. La segunda estuvo orientada a integrar la capa de presentación y la capa de aplicación por primera vez; planificado como una entrega de software. Para el caso de la Agricultura, se agregaron al paquete structure las clases correspondientes al manejo de cultivos y un nuevo trabajador (RotationPaddocks) para simular la rotación de actividades (Pasturas y cultivos) en los potreros (Fig. 8). Durante la reunión de reflexión (Reflection Workshop) realizada al finalizar esta iteración, se especificaron diferentes convenciones de codificación (Code Conventions) para facilitar la actividad de mantenimiento y la legibilidad de código. 15

16 La integración de capas fue exitosa, pudiendo visualizar y operar el sistema vía Web. Sin embargo, las pantallas desarrollados por el equipo externo no resultaron de la calidad visual pretendida por el Sponsor. En consecuencia, se decidió que el ajuste final de las interfaces existentes y el desarrollo de adicionales se efectuarían dentro del mismo equipo Iteración 2 La segunda iteración comenzó el 12/02/2007 y terminó el 23/03/2007. Se incorporó un modelo económico para permitir la estimación del margen bruto de los cultivos y la invernada, rentabilidad del activo, utilidad neta y capacidad de crecimiento de la empresa. También se planificó aquí el entrenamiento en la herramienta OpenLaszlo utilizada en la capa de presentación. En esta iteración el Expert User y Friendly User probaron exhaustivamente las interfaces con el objetivo de identificar mejoras. Como el equipo incrementaba su conocimiento sobre el sistema, se realizo el workproduct mapa de proyecto (Project Map) en el que se incluyen actividades priorizadas a ser realizadas en futuras iteraciones. La realización del modelo económico se basó en un documento elaborado por un experto de ese dominio particular. Adicionalmente este profesional pudo ser consultado durante el proceso. Al finalizar la iteración el paquete structure quedó incluido dentro del paquete whole-farm, que ahora además incluía al paquete economic para la administración de datos económicos y financieros. Adicionalmente, se agregó el paquete models dentro de workers, para el manejo de modelos adicionales al biofísico (Fig. 8). Durante la reunión de reflexión de esta iteración, se mencionó que a menudo los tiempos en la integración de código se extendían más de lo pensado. La misma se venía realizando una vez a la semana, y a partir de esta se realizó cada dos días. La documentación diseño y la implementación del modelo económico resultó laboriosa, llevando más tiempo que el planificado por lo que se adicionó a la lista de convenciones que: la redacción de la documentación del proyecto no podía superar la hora diaria Iteración 3 Esta iteración fue llevada a cabo desde el 26/03/2007 hasta 27/04/2007. Sus dos principales objetivos estaban referidos a la capa de presentación. Por un lado desarrollar las interfaces para la carga del modelo económico realizado en la iteración anterior y por otro lado mejorar las deficiencias encontradas en las interfaces por parte del Expert User y Friendly User en la iteración anterior. Las tareas fueron realizadas en su mayoría, pero se subestimó la asignación de tiempos de las interfaces, así que algunos componentes tuvieron que ser simplificados para alcanzar la fecha de finalización de la iteración. El simulador representa un dominio complejo, y la amigabilidad de sus interfaces (presente en la lista de riesgos) resultan fundamentales para su comprensión y como consecuencia su uso creciente. La presencia diaria del Expert User para evacuar dudas en la visualización e interpretación de las pantallas fue muy relevante para estas tareas. Durante la reunión de reflexión se destacó que a futuro se debe considerar particularmente la asignación de tiempo cuando dentro de las tareas previstas hubiese desarrollos de pantallas Iteración 4 La cuarta iteración comenzó el 30/04/2007 y finalizó el 15/06/2007. En la Figura 12, se muestran las correspondientes Story Cards y diagrama de Gantt [19] de la misma. El entendimiento y aplicación continúa de las convenciones, la comunicación fluida 16

17 entre los desarrolladores y con el Expert User eran reflejados en la motivación y productividad del equipo. Como consecuencia, se decide incorporar en esta iteración actividades de mayor extensión y complejidad. Esta iteración finalizó con una entrega de software al cliente del simulador accedido vía Web por distintos perfiles de usuario. Por ello, se migró la base de datos de Hsqldb [14] a Oracle XE [23], se desarrolló un modulo para el manejo de distintos perfiles de usuario, que restringe a cada uno las actividades permitidas: las entradas de datos y las salidas. Adicionalmente, se incorporó la funcionalidad de envió automático de las salidas directamente a la cuenta de correo electrónico facilitada por el usuario. Con ese sentido se agregó el paquete output, para el envío de la planilla de cálculo, y el paquete users para el manejo de distintos perfiles de usuario (Fig. 8). El archivo de salida (hoja de cálculo) presenta la información en texto plano, así como también en gráficos pre-diseñados con la asistencia de Expert User. Debido a que se necesitó utilizar nuevas herramientas para el desarrollo de las actividades, dentro de la iteración se asignó un tiempo al entrenamiento en las mismas. Durante la reunión de reflexión de esta iteración no surgieron modificaciones o sugerencias a la forma de desarrollo. La metodología alcanzó la estabilidad deseada desde el comienzo y fue muy apreciada por el Sponsor y los desarrolladores. Fig. 12. Diagrama de Gantt y Story Cards de la iteración 4. 17

18 6. Observaciones finales y conclusiones Las deficiencias en la captura de requerimientos del sistema al inicio de la etapa 2 del proyecto tuvieron como consecuencia, por un lado una mala definición de las características necesarias del sistema y por otro a la aplicación de un inadecuado proceso de desarrollo. Con relación al primer punto, en la industria del software se reporta frecuentemente que más de la mitad de los proyectos de software no coinciden con la funcionalidad requerida [36]. Dentro de ese contexto, el presente documento tiene como objetivo contribuir a la comprensión de porqué se fracasó, identificando las lecciones aprendidas de manera tal que puedan contribuir al desarrollo futuro de otros sistemas agropecuarios u otros dominios complejos. Con respecto al ciclo de vida seleccionado para la etapa 2, se utilizó de forma errónea un ciclo en cascada al no percibirse adecuadamente la necesidad de cambios constantes en los requerimientos como se evidenció durante la ejecución de tareas. Los cambios constantes también se originan en que los sistemas agropecuarios porque son un dominio complejo donde interactúan en el tiempo componentes como el clima, el mercado y los manejos involucrando múltiples disciplinas [27]. Este simulador agropecuario integral es la primera experiencia en Argentina según el conocimiento de los autores, por lo que no se disponía de una referencia cercana que se pudiera considerar. Recientemente, se informó que los métodos ágiles se aplicaron a un gran simulador agrícola de Australia [13]. Los costos adicionales son un importante efecto secundario de deficiencias como las mencionadas [18], y en este proyecto tanto este factor como la disconformidad de Sponsor al final de la etapa 2, casi provocan la cancelación definitiva del desarrollo. Además de los problemas anteriormente mencionados, potencialmente vinculados a la captura de requerimientos, hubo dificultades adicionales durante el desarrollo del software. Algunos autores [15] mencionan el inconveniente de distinguir si los problemas provienen de la ingeniería de requerimientos o de alguna parte del ciclo de vida. Al comienzo de la etapa 2, el equipo de trabajo tenía poca experiencia en la utilización de la tecnología a utilizar en la capa de presentación (OpenLaszlo [22]). El empleo de tecnologías nuevas constituye un riesgo adicional para el proyecto si no se las maneja adecuadamente [24]. En este proyecto se efectuó un período de entrenamiento en la tecnología OpenLaszlo, pero resultó insuficiente a la luz que al finalizar la etapa 2 la capa de presentación presentaba una baja calidad. Después de la auditoria se tercerizó la mejora de las interfaces a un grupo externo con experiencia en la tecnología. Este desarrollo se integró eficientemente a la capa de aplicación, pero algunos detalles visuales no terminaron de conformar al Sponsor. Por tal motivo, a posteriori de la iteración 1 (etapa 4) se efectuaron la totalidad de los desarrollados requeridos del sistema (incluyendo la capa de presentación) dentro del equipo. El uso del método ágil CC fue decidido en la etapa 3, y adicionalmente se agregaron prácticas de Scrum y UP para asegurar que el proyecto se mantenga en la zona segura (Fig. 6). Se tuvo especial cuidado en la compresión de la metodología por parte de cada uno de los integrantes del equipo. La aplicación de la práctica Side-by-Side Programming de CC fue muy importante, tanto como para la compresión y ejecución de la metodología, como para la transferencia de conocimiento entre los desarrolladores. Los beneficios de los testeos automáticos son bien conocidos, pero eran de difícil aplicación de acuerdo a los recursos que se disponía para el proyecto. 18

19 En este desarrollo se aplicaron testeos manuales, los que resultaron igualmente eficientes. La comunicación es una de las claves de los métodos ágiles [1] [6]. Durante el desarrollo se aplicaron simultáneamente diferentes prácticas de CC que facilitó el trabajo cooperativo y eficiente (Side-by-Side Programming, Information Radiators y Story Cards, el equipo estuvo ubicado en la misma oficina y se modificó la organización mobiliaria de la misma como lo muestra la Fig. 5.b). Este contexto de trabajo contribuyó a que se comparta el estado de avance de todo el proyecto y a que se formara un verdadero espíritu de equipo y camaradería, los cuales, definitivamente, fueron la clave para mantener el foco y el compromiso. La entrega frecuente de software testeado proveía visibilidad del progreso. A modo de ejemplo de progreso, se destaca un comentario del Sponsor durante la tercera iteración Ahora estamos en el camino correcto. Los nuevos requerimientos que van surgiendo son siempre bien recibidos e incorporados rápidamente por los desarrolladores dentro de las posibilidades tecnológicas y metodológicas. Considerando que el proyecto estuvo cerca de cancelarse definitivamente al fin de la etapa 2 (120 días atrás), este comentario no resulta un logro menor para el equipo de desarrollo. Las principales conclusiones de esta experiencia son que la no detección de cambios constantes en los requerimientos en la fase de iniciación en la etapa 2 del proyecto causó una mala selección en el ciclo de vida a utilizar. Por lo tanto, las dificultades durante el desarrollo produjeron insatisfacción en el Sponsor y en los desarrolladores poniendo en riesgo el proyecto. La aplicación del método ágil CC (en combinación con prácticas seleccionadas de Scrum y XP) fue altamente efectiva para recuperar este proyecto, alcanzando las expectativas del Sponsor en menos de 4 meses. En el presente, 4 iteraciones adicionales fueron terminadas exitosamente y otras ya están planeadas para seguir agregando funcionalidad al simulador. Dentro de las mejoras futuras a modo de ejemplo se encuentra: la incorporación de un modelo más avanzado para el crecimiento de las pasturas clima dependiente, un modelo impositivo, engorde de animales a corral (Feedlot) y la actividad de cría vacuna. 7. Referencias 1. Abrahamsson P., Salo O., Ronkainen J., Warsta J.: Agile software development Methods. Review and Analysis. In: Espoo VTT Publications p (2002). 2. Bass, L., Clements, P., Kazman, R.: Software Architecture in Practice. Addison Wesley (1998). 3. Berger, H., Machado, C., Copes, M., Ponssa, E., Auza, N.: Revista Argentina de Producción Animal. XXV25 Congreso Argentino de Producción Animal 22, 346 (2002). 4. Boehm, B. W.: A spiral model of software development and enhancement. IEEE 5. Computer Society, volume 21, Issue: 5 pp (1988). 6. Cockburn, A.: Crystal Clear: A human-powered methodology for small teams. Addison Wesley (2004). 7. Cockburn, A.: Crystal methodologies main foyer, 8. Doyle, C. J., Baars, J. A., Bywater, A. C.: Agricultural Systems 31, p (1989). 9. Elizalde, J. C.: Integración del feedlot a los sistemas pastoriles. In: Rearte, D.H. Ed. El Feedlot en Argentina. Programa de Producción animal, INTA. 112 p (1994). 10. Extend, Simulation Tool, Garcia, S. C., Santini, F., Castańo, G.: Producción de carne bajo pastoreo: Alternativas de intensificación. Material didáctico Nro 14. INTA, Cerbas.:52 p (1998). 19

20 12. Highsmith, J., Highsmith J. A.: Agile Software Development Ecosystems. Addison- Wesley (2002). 13. Holzworth, D., Meinke, H., DeVoil, P., Wegener, M., Huth, N., Hammer, G., Howden, M., Robertson, M., Carberry, P., Freebairn, D., Murphy, C.: The development of a farming systems model (APSIM) a disciplined approach (2006). 14. Hsqldb, Lightweight Java SQL Database Engine, Johnson, C. W., Holloway, C. M.: Questioning the Role of Requirements Engineering in the Causes of Safety-Critical Software Failures. The 1st Institution of Engineering and Technology International Conference on System Safety p (2006). 16. Larman C.: Agile and Iterative Development: A Manager's Guide. Addison Wesley (2004). 17. Machado, C.: Field and modelling studies of the effects of herbage allowance and maize grain feeding on animal performance in beef cattle finishing systems in: unpublished PhD Thesis, directed by S.T. Morris. Massey University, New Zealand, pp. 271 (2004). 18. Masticola, S. P.: A Simple Estimate of the Cost of Software Project Failures and the Breakeven Effectiveness of Project Risk Management. First International Workshop on the Economics of Software and Computation p (2007). 19. Maylor, H.: Beyond the Gantt chart: Project management moving. In: European Management Journal, 19 (1), pp (2001). 20. McCall, D., Townsley, R., Bircham, J., Sheath, G. W.: Proceedings of the New Zealand Grassland Association 47, p (1986). 21. McCown, R.: Changing systems for supporting farmers decisions: problems, paradigms and prospects. Agricultural Systems 74, 179 (2002). 22. OpenLaszlo, Oracle XE Express Edition, Ould, M.: Managing Software Quality and Business Risk, John Wiley & Sons, San Francisco (1998). 25. Palmieri, V., Rivas, L.: Gestión de la Información para la innovación tecnólogica agropecuaria: Comuniica, Mayo-Agosto, (2007). 26. Pannell, D. J.: On the estimation of on-farm benefits of agricultural research. Agricultural Systems 61, p (1999). 27. Pearson, C. J., Ison, R. L.: Agronomy of grassland systems. Cambridge University Press, Cambridge (1987). 28. PICTO 22926: Desarrollo y evaluación de un simulador dinámico clima-dependiente de empresas ganaderas predominantemente pastoriles. Dir: Claudio F. Machado, aprobado por la Resolución Directorio de la Agencia Nº 029/2006. ANPCyT- FONCYT, Argentina (2006). 29. Rearte, D., Pieroni, G. A.: Supplementation of temperate pastures. Proceedings of the XV International Grassland Congress : (2001). 30. Rearte, D.: Revista Argentina de Producción Animal 18, p (1998). 31. Rumbaugh, J.,Jacobson, I., Booch, G.: The Unified Modeling Language. Reference Manual. Addison-Wesley (1999). 32. Schwaber, K.,Beedle, M.: Agile software development with Scrum. Prentice-Hall (2002). 33. Shaw, M., Garlan, D.: Software Architecture, Perspectives on an Emerging Discipline. Prentice-Hall (1996). 34. SmartCVS Foundation Copyright(C) By SyntEvo GmbH, Spring Framework, Standish Group s: Standish Group s The Chaos Report 2004, Extreme Chaos (2004). 20