Published 16 years ago
(updated 13 years ago)
La Universidad de Montemorelos (UM) recientemente inició la adopción de Scrum para el desarrollo de sus sistemas internos. A continuación se relatan las crónicas de su éxodo desde la tierra árida
donde no existe metodología alguna, hacia la tierra donde las metodologías dan excelentes resultados.
Nota del editor: Debido a limitaciones de espacio hemos obviado definiciones básicas
de Scrum y nos lanzamos de lleno a los aspectos prácticos de este caso de estudio. Puedes consultar la versión completa de este artículo, que incluye definiciones de Scrum en la versión en línea de este articulo en el sitio web de SG.Primeros pasos hacia Scrum
La Dirección de Sistemas de la Universidad de Montemorelos (UM) desarrolla principalmente dos sistemas para la institución: el sistema financiero y el sistema académico. En el verano de 2008, el líder de proyectos del sistema financiero asistió a una charla impartida por la división de Servicios Educacionales de Sun Microsystems donde se presentaron algunos fundamentos del desarrollo de software ágil, y Scrum. En el transcurso de los siguientes días se investigó un poco más al respecto. Sin esperar demasiado, se decidió iniciar el primer Sprint con una duración de tres semanas, utilizando el
conjunto de requerimientos en los cuales se estaba trabajando en ese momento, para alimentar el Product Backlog.
El primer cambio que provocó esta decisión fue eliminar al ”Líder de Proyectos”. Es decir, eliminar todo ese concepto de “el jefe con el látigo en la mano”, cuyo único interés es cumplir a fuego y sangre con las
fechas estipuladas en las gráficas de Gantt, sin detenerse a pensar por un momento siquiera en el bienestar del equipo. Fue un cambio radical de mentalidad: “el ogro se transformó en benefactor”. Dejó de existir el jefe que mira a sus subalternos desde su pedestal para convertirse ahora en un miembro
efectivo del equipo, que trabaja hombro con hombro con los demás integrantes para construir el proyecto, ayudando a eliminar los obstáculos que limitan el avance y promoviendo un ambiente armonioso de trabajo. Ahora, cada miembro del equipo podía expresarse de manera abierta y confiada, sin temor a reprimendas; y, a diferencia de otras ocasiones, ahora recibía ayuda del Scrum Master para buscar la mejor solución al problema.
En el daily scrum, los miembros del equipo se informaban entre sí en qué habían trabajado el día anterior, en qué trabajarían el día corriente y si tenían algún problema que les impedía avanzar en la tarea. En caso de que así fuera, el SM ayudaba a encontrar la solución.
En una temporada, se descuidó esta práctica hasta que eventualmente se dejó de realizar por completo el daily scrum, bajo pretexto de adelantar trabajo. Fue gracias a un integrante del equipo, el cual externó su sentir acerca de la necesidad de realizar el Daily Scrum, que se renovó el compromiso de apegarse a las prácticas de Scrum.
En el sprint review, al finalizar el primer Scrum, se hizo evidente que los resultados fueron positivos. Se lograron finalizar todas las tareas listadas en el sprint backlog en las tres semanas de duración del Sprint. Los miembros del equipo se sintieron motivados y expresaron
durante el sprint retrospective que deseaban continuar trabajando de este modo. En este punto, algunas de las cualidades del Scrum se hicieron evidentes. En palabras de Jeff Sutherland: “Scrum está diseñado para agregar energía, concentración, claridad y transparencia en la planeación e implementación del proyecto”. Tan solo en el primer Sprint, el equipo había empezado a experimentar las bondades de la comunicación consistente y estable, al ver su creatividad estimulada y una mejora en su calidad de vida.
Siguientes sprints
Antes de comenzar el segundo Sprint, se presentaron los principios básicos de Scrum al Director Financiero y al Director de Contabilidad de la institución. Cuando se les mencionó que bajo esta nueva forma de trabajo ellos serían parte activa del equipo, les nació un interés genuino y les renació la esperanza de ver sus requerimientos solucionados de manera más ágil. Al conocer las ventajas que promete Scrum, decidieron aventurarse a jugar bajo las nuevas reglas, siendo nombrado el Director de Contabilidad como Product Owner.
A partir de este momento, se hizo necesario crear dos documentos compartidos: el Product Backlog, donde el PO alimentaría todas las funcionalidades requeridas; y el Sprint Backlog, donde el Scrum Master y el equipo ingresarían aquellas tareas en las cuales trabajarían durante el Sprint. Estos documentos se compartieron además, con otros roles, como los Managers, haciendo
transparente el proceso de desarrollo. Gracias a Google Docs, es por demás sencillo mantener el Product Backlog al día.
Conforme se ha avanzado a través de los Sprint, se ha visto la necesidad de catalogar las tareas del Sprint Backlog en: tareas pendientes, tareas en las que se está trabajando
y tareas finalizadas; usando un código de color para cada uno. También identificamos aquellas tareas en las cuales no se pudo trabajar, como por ejemplo: por falta de documentación suficiente. Este código de colores ha facilitado el seguimiento del Sprint por parte del PO y los Managers
Cuando el proceso cíclico del Sprint llega a su fin, se organiza el Sprint Review, convocando
el SM al PO y los Managers. Esta reunión ha servido para revisar de manera rápida el avance de cada una de las funcionalidades que el equipo se comprometió a realizar durante el Sprint. El PO verifica que los requerimientos especificados han sido correctamente solucionados en las aplicaciones demostradas.
En nuestra experiencia, durante los Sprint Review, el PO y los Managers rectifican las prioridades de los elementos del Product Backlog, llegando incluso a agregar nuevos requerimientos a la lista. En ocasiones, no ha sido posible que el PO y los Managers tengan un espacio disponible en sus agendas
para poder llevar a cabo el Sprint Review en cuanto finaliza el Sprint. Para optimizar el uso del tiempo, el equipo financiero ha decidido organizar el Sprint Retrospective antes que el Sprint Review. El Sprint Retrospective, ha sido una instrumento de gran utilidad al equipo financiero. Durante estas reuniones se han identificado prácticas intrínsecas al equipo que sin un período de retrospección,no serían fáciles de reconocer. El resultado natural de los Sprint Retrospective, es la creación de estándares que por necesidad del mismo equipo se definen con el objetivo de agilizar el proceso de desarrollo de software.
A continuación se listan algunos de los estándares que el equipo ha acordado:
1. Crear prueba web sin parámetros para simular la ejecución de la funcionalidad desde el menú principal.
2. Definir de manera detallada cada una de las tareas.
3. Antes de dar por finalizada cualquier tarea, ésta debe ser cotejada de manera cuidadosa contra las pruebas por el SM y el integrante del equipo que la finalizó.
4. Incluir JavaDocs en todos los métodos, indicando propósito y cualquier situación especial a considerar para utilizar el método.
5. Incluir comentarios en aquellas líneas de código que así lo ameriten.
Una vez que se ha finalizado una iteración del proceso, éste comienza de nuevo con el Sprint Planning Meeting donde una vez más, el SM convoca al PO y Managers. De-bido a las agendas ocupadas del PO y los Managers, durante el tiempo que el equi-po financiero ha estado implementando Scrum, dicha reunión se ha ido adaptan-do de tal modo que el Sprint Review y el Sprint Planning Meeting se llevan a cabo como una sola reunión.
Resultados cuantitativos
En el camino de esta aventura hemos gene-rado algunos datos dignos de analizarse. A continuación, se analizarán y explicarán de manera detallada los resultados obtenidos.
Como se aprecia en la figura 1, durante los primeros tres Sprints el nivel de productivi-dad se fue incrementando de manera pro-gresiva. Es evidente que conforme el equi-po fue asimilando el proceso de Scrum, un mayor porcentaje de las tareas se completó. Es importante hacer notar que el éxito de cada Sprint se fundamenta en el análisis cui-dadoso de cada una de las funcionalidades seleccionadas del Product Backlog. Si se descuida este factor de éxito, sería muy fácil sobrepasar la capacidad de trabajo del equi-po, dando como resultado la incapacidad de cumplir con el compromiso de finalizar 100% de las tareas. Como en todo proceso de aprendizaje, es a través de la prueba y el error, que el equipo adquiere la maestría necesaria para lograr un equilibrio entre la capacidad del equipo y la carga de trabajo. Se puede notar que a partir del cuarto Sprint hay una caída drástica de 35.71% en el nivel de productividad. Las causas se analizarán a detalle más adelante en la figura 3.
Bajo la forma particular de trabajo de Scrum, se espera que debido a la continua interacción entre el PO y el equipo, cada funcionalidad liberada cumpla de manera fiel todos los requisitos que se solicitaron, elevando así la calidad del software. Tomando como base este punto, se considera
de relevancia el analizar de qué tipo de tareas está compuesto cada Sprint. Es decir, tareas que agregan nueva funcionalidad, tareas que corrigen funcionalidad o tareas que modifican la funcionalidad.
En la figura 2 se puede observar que durante los Sprints uno, dos, cinco y seis, el Sprint Backlog se compuso exclusivamente de tareas orientadas a generar nueva funcionalidad. Es decir, en estos ciclos no se trabajó en resolver bugs, ni en agregar o modificar funcionalidad a aplicaciones ya existentes. En el tercer Sprint, 14.29% de las tareas que se trabajaron, estuvieron orientadas a modificar funcionalidades de aplicaciones ya liberadas anteriormente.
Esto puede interpretarse de dos maneras:
a) Hizo falta un análisis más cuidadosonen compañía del PO a la hora de detallar las funcionalidades, para comprender perfectamente el requerimiento antes de iniciar alguno de los Sprints anteriores.
b) El usuario final una vez que tuvo la funcionalidad requerida, se da cuenta que ésta no satisface sus necesidades. En la figura 1 ya vimos que en el Sprint 4 hubo una caída notable de productividad en cuanto a tareas finalizadas. En la figura 3 se aprecia que a partir de este Sprint el equipo se vio en la necesidad de aceptar tareas que originalmente no habían formado parte del Sprint Backlog, lo cual provocó la baja en productividad.
¿Qué ocasionó este escenario? El sistema financierontiene una antigüedad de siete años y cuenta con ocho módulos principales, haciendo de la labor de mantenimiento de código una necesidad primaria que demanda recursos. Tal situación abre la puerta para que el PO solicite ciertas modificaciones y
correcciones con carácter de urgencia. Algunos de estos requerimientos extraordinarios, están en relación directa con determinadas fechas o acontecimientos bien identificados como parte de la vida institucional. Por ejemplo: inicio y término del ciclo escolar, inicio y fin de año contable. En la figura 3, los tres últimos Sprints se corresponden con periodos de cierre de año contable e inicio
del siguiente ciclo contable, lo cual explica la cantidad de tareas no planeadas.
Aunque se encuentra como una opción viable que el SM acepte nuevas tareas para un Sprint que ya inició, se considera una mejor práctica el finalizar el Sprint para reorganizar de nuevo las prioridades
de los requerimientos. Una táctica que el equipo financiero ha adoptado, es identificar en conjunto con el PO y los Managers, cualquier probabilidad de la existencia de solicitudes de requerimientos
inesperados durante el Sprint, disminuyendo entonces de manera inversa la cantidad de tareas aceptadas por el equipo.
Conclusiones
La implementación correcta de Scrum no sucede de la noche a la mañana. Este es un
proceso paulatino, en donde cada uno de los distintos roles debe aprender sus responsabilidades
y, a través de la práctica continua lograr jugar correctamente su papel.
Algunas partes de Scrum se han adaptado en la Dirección de Sistemas de la UM, con el objetivo de hacer la transición de una manera menos drástica, especialmente para el PO y los Managers. Afortunadamente Scrum es lo suficientemente flexible como para adaptarse y así facilitar la asimilación del proceso. Sin embargo, se debe estar atento de no degradar el Scrum, eliminando así cualquier valor que éste pudiera agregar a la organización.
En cada Sprint Planning Meeting fue necesario analizar detenidamente las funcionalidades que se aceptaron en cada Sprint. El determinar de manera real la cantidad de recursos que una funcionalidad
demandará es un punto clave para el éxito de Scrum. La comunicación constante entre el PO, el SM y el equipo garantizó que en cada Sprint se trabajara sólo en aquellas funcionalidades que realmente
le interesaban al PO, resolviendo necesidades reales y evitando así la generación de código ocioso
Acerca de los Autores
Omar Otoniel Soto Romero es líder de proyectos del Sistema Financiero en la Universidad de Montemorelos. Es graduado de Ingenieria en Sistemas Computacionales en 1997, y de la Maestria en Administracion de Empresas en 2007. Actualmente cursa la Maestria en Ciencias Computacionales con acentuacion en Ingenieria del Software.
osoto@um.edu.mx
Germán Harvey Alférez Salinas es Coordinador del Departamento de Investigación de la Facultad de Ingeniería y Tecnología en la Universidad de Montemorelos, e investigador asociado de Mission College, Tailandia. Es graduado con honores del Master of Science in Information and Communication
Technology en Assumption University, Tailandia. Sus áreas de interés incluyen software product lines, model driven development, y software architectures.
fit.um.edu.mx/harvey
donde no existe metodología alguna, hacia la tierra donde las metodologías dan excelentes resultados.
Nota del editor: Debido a limitaciones de espacio hemos obviado definiciones básicas
de Scrum y nos lanzamos de lleno a los aspectos prácticos de este caso de estudio. Puedes consultar la versión completa de este artículo, que incluye definiciones de Scrum en la versión en línea de este articulo en el sitio web de SG.Primeros pasos hacia Scrum
La Dirección de Sistemas de la Universidad de Montemorelos (UM) desarrolla principalmente dos sistemas para la institución: el sistema financiero y el sistema académico. En el verano de 2008, el líder de proyectos del sistema financiero asistió a una charla impartida por la división de Servicios Educacionales de Sun Microsystems donde se presentaron algunos fundamentos del desarrollo de software ágil, y Scrum. En el transcurso de los siguientes días se investigó un poco más al respecto. Sin esperar demasiado, se decidió iniciar el primer Sprint con una duración de tres semanas, utilizando el
conjunto de requerimientos en los cuales se estaba trabajando en ese momento, para alimentar el Product Backlog.
El primer cambio que provocó esta decisión fue eliminar al ”Líder de Proyectos”. Es decir, eliminar todo ese concepto de “el jefe con el látigo en la mano”, cuyo único interés es cumplir a fuego y sangre con las
fechas estipuladas en las gráficas de Gantt, sin detenerse a pensar por un momento siquiera en el bienestar del equipo. Fue un cambio radical de mentalidad: “el ogro se transformó en benefactor”. Dejó de existir el jefe que mira a sus subalternos desde su pedestal para convertirse ahora en un miembro
efectivo del equipo, que trabaja hombro con hombro con los demás integrantes para construir el proyecto, ayudando a eliminar los obstáculos que limitan el avance y promoviendo un ambiente armonioso de trabajo. Ahora, cada miembro del equipo podía expresarse de manera abierta y confiada, sin temor a reprimendas; y, a diferencia de otras ocasiones, ahora recibía ayuda del Scrum Master para buscar la mejor solución al problema.
En el daily scrum, los miembros del equipo se informaban entre sí en qué habían trabajado el día anterior, en qué trabajarían el día corriente y si tenían algún problema que les impedía avanzar en la tarea. En caso de que así fuera, el SM ayudaba a encontrar la solución.
En una temporada, se descuidó esta práctica hasta que eventualmente se dejó de realizar por completo el daily scrum, bajo pretexto de adelantar trabajo. Fue gracias a un integrante del equipo, el cual externó su sentir acerca de la necesidad de realizar el Daily Scrum, que se renovó el compromiso de apegarse a las prácticas de Scrum.
En el sprint review, al finalizar el primer Scrum, se hizo evidente que los resultados fueron positivos. Se lograron finalizar todas las tareas listadas en el sprint backlog en las tres semanas de duración del Sprint. Los miembros del equipo se sintieron motivados y expresaron
durante el sprint retrospective que deseaban continuar trabajando de este modo. En este punto, algunas de las cualidades del Scrum se hicieron evidentes. En palabras de Jeff Sutherland: “Scrum está diseñado para agregar energía, concentración, claridad y transparencia en la planeación e implementación del proyecto”. Tan solo en el primer Sprint, el equipo había empezado a experimentar las bondades de la comunicación consistente y estable, al ver su creatividad estimulada y una mejora en su calidad de vida.
Siguientes sprints
Antes de comenzar el segundo Sprint, se presentaron los principios básicos de Scrum al Director Financiero y al Director de Contabilidad de la institución. Cuando se les mencionó que bajo esta nueva forma de trabajo ellos serían parte activa del equipo, les nació un interés genuino y les renació la esperanza de ver sus requerimientos solucionados de manera más ágil. Al conocer las ventajas que promete Scrum, decidieron aventurarse a jugar bajo las nuevas reglas, siendo nombrado el Director de Contabilidad como Product Owner.
A partir de este momento, se hizo necesario crear dos documentos compartidos: el Product Backlog, donde el PO alimentaría todas las funcionalidades requeridas; y el Sprint Backlog, donde el Scrum Master y el equipo ingresarían aquellas tareas en las cuales trabajarían durante el Sprint. Estos documentos se compartieron además, con otros roles, como los Managers, haciendo
transparente el proceso de desarrollo. Gracias a Google Docs, es por demás sencillo mantener el Product Backlog al día.
Conforme se ha avanzado a través de los Sprint, se ha visto la necesidad de catalogar las tareas del Sprint Backlog en: tareas pendientes, tareas en las que se está trabajando
y tareas finalizadas; usando un código de color para cada uno. También identificamos aquellas tareas en las cuales no se pudo trabajar, como por ejemplo: por falta de documentación suficiente. Este código de colores ha facilitado el seguimiento del Sprint por parte del PO y los Managers
Cuando el proceso cíclico del Sprint llega a su fin, se organiza el Sprint Review, convocando
el SM al PO y los Managers. Esta reunión ha servido para revisar de manera rápida el avance de cada una de las funcionalidades que el equipo se comprometió a realizar durante el Sprint. El PO verifica que los requerimientos especificados han sido correctamente solucionados en las aplicaciones demostradas.
En nuestra experiencia, durante los Sprint Review, el PO y los Managers rectifican las prioridades de los elementos del Product Backlog, llegando incluso a agregar nuevos requerimientos a la lista. En ocasiones, no ha sido posible que el PO y los Managers tengan un espacio disponible en sus agendas
para poder llevar a cabo el Sprint Review en cuanto finaliza el Sprint. Para optimizar el uso del tiempo, el equipo financiero ha decidido organizar el Sprint Retrospective antes que el Sprint Review. El Sprint Retrospective, ha sido una instrumento de gran utilidad al equipo financiero. Durante estas reuniones se han identificado prácticas intrínsecas al equipo que sin un período de retrospección,no serían fáciles de reconocer. El resultado natural de los Sprint Retrospective, es la creación de estándares que por necesidad del mismo equipo se definen con el objetivo de agilizar el proceso de desarrollo de software.
A continuación se listan algunos de los estándares que el equipo ha acordado:
1. Crear prueba web sin parámetros para simular la ejecución de la funcionalidad desde el menú principal.
2. Definir de manera detallada cada una de las tareas.
3. Antes de dar por finalizada cualquier tarea, ésta debe ser cotejada de manera cuidadosa contra las pruebas por el SM y el integrante del equipo que la finalizó.
4. Incluir JavaDocs en todos los métodos, indicando propósito y cualquier situación especial a considerar para utilizar el método.
5. Incluir comentarios en aquellas líneas de código que así lo ameriten.
Una vez que se ha finalizado una iteración del proceso, éste comienza de nuevo con el Sprint Planning Meeting donde una vez más, el SM convoca al PO y Managers. De-bido a las agendas ocupadas del PO y los Managers, durante el tiempo que el equi-po financiero ha estado implementando Scrum, dicha reunión se ha ido adaptan-do de tal modo que el Sprint Review y el Sprint Planning Meeting se llevan a cabo como una sola reunión.
Resultados cuantitativos
En el camino de esta aventura hemos gene-rado algunos datos dignos de analizarse. A continuación, se analizarán y explicarán de manera detallada los resultados obtenidos.
Como se aprecia en la figura 1, durante los primeros tres Sprints el nivel de productivi-dad se fue incrementando de manera pro-gresiva. Es evidente que conforme el equi-po fue asimilando el proceso de Scrum, un mayor porcentaje de las tareas se completó. Es importante hacer notar que el éxito de cada Sprint se fundamenta en el análisis cui-dadoso de cada una de las funcionalidades seleccionadas del Product Backlog. Si se descuida este factor de éxito, sería muy fácil sobrepasar la capacidad de trabajo del equi-po, dando como resultado la incapacidad de cumplir con el compromiso de finalizar 100% de las tareas. Como en todo proceso de aprendizaje, es a través de la prueba y el error, que el equipo adquiere la maestría necesaria para lograr un equilibrio entre la capacidad del equipo y la carga de trabajo. Se puede notar que a partir del cuarto Sprint hay una caída drástica de 35.71% en el nivel de productividad. Las causas se analizarán a detalle más adelante en la figura 3.
Bajo la forma particular de trabajo de Scrum, se espera que debido a la continua interacción entre el PO y el equipo, cada funcionalidad liberada cumpla de manera fiel todos los requisitos que se solicitaron, elevando así la calidad del software. Tomando como base este punto, se considera
de relevancia el analizar de qué tipo de tareas está compuesto cada Sprint. Es decir, tareas que agregan nueva funcionalidad, tareas que corrigen funcionalidad o tareas que modifican la funcionalidad.
En la figura 2 se puede observar que durante los Sprints uno, dos, cinco y seis, el Sprint Backlog se compuso exclusivamente de tareas orientadas a generar nueva funcionalidad. Es decir, en estos ciclos no se trabajó en resolver bugs, ni en agregar o modificar funcionalidad a aplicaciones ya existentes. En el tercer Sprint, 14.29% de las tareas que se trabajaron, estuvieron orientadas a modificar funcionalidades de aplicaciones ya liberadas anteriormente.
Esto puede interpretarse de dos maneras:
a) Hizo falta un análisis más cuidadosonen compañía del PO a la hora de detallar las funcionalidades, para comprender perfectamente el requerimiento antes de iniciar alguno de los Sprints anteriores.
b) El usuario final una vez que tuvo la funcionalidad requerida, se da cuenta que ésta no satisface sus necesidades. En la figura 1 ya vimos que en el Sprint 4 hubo una caída notable de productividad en cuanto a tareas finalizadas. En la figura 3 se aprecia que a partir de este Sprint el equipo se vio en la necesidad de aceptar tareas que originalmente no habían formado parte del Sprint Backlog, lo cual provocó la baja en productividad.
¿Qué ocasionó este escenario? El sistema financierontiene una antigüedad de siete años y cuenta con ocho módulos principales, haciendo de la labor de mantenimiento de código una necesidad primaria que demanda recursos. Tal situación abre la puerta para que el PO solicite ciertas modificaciones y
correcciones con carácter de urgencia. Algunos de estos requerimientos extraordinarios, están en relación directa con determinadas fechas o acontecimientos bien identificados como parte de la vida institucional. Por ejemplo: inicio y término del ciclo escolar, inicio y fin de año contable. En la figura 3, los tres últimos Sprints se corresponden con periodos de cierre de año contable e inicio
del siguiente ciclo contable, lo cual explica la cantidad de tareas no planeadas.
Aunque se encuentra como una opción viable que el SM acepte nuevas tareas para un Sprint que ya inició, se considera una mejor práctica el finalizar el Sprint para reorganizar de nuevo las prioridades
de los requerimientos. Una táctica que el equipo financiero ha adoptado, es identificar en conjunto con el PO y los Managers, cualquier probabilidad de la existencia de solicitudes de requerimientos
inesperados durante el Sprint, disminuyendo entonces de manera inversa la cantidad de tareas aceptadas por el equipo.
Conclusiones
La implementación correcta de Scrum no sucede de la noche a la mañana. Este es un
proceso paulatino, en donde cada uno de los distintos roles debe aprender sus responsabilidades
y, a través de la práctica continua lograr jugar correctamente su papel.
Algunas partes de Scrum se han adaptado en la Dirección de Sistemas de la UM, con el objetivo de hacer la transición de una manera menos drástica, especialmente para el PO y los Managers. Afortunadamente Scrum es lo suficientemente flexible como para adaptarse y así facilitar la asimilación del proceso. Sin embargo, se debe estar atento de no degradar el Scrum, eliminando así cualquier valor que éste pudiera agregar a la organización.
En cada Sprint Planning Meeting fue necesario analizar detenidamente las funcionalidades que se aceptaron en cada Sprint. El determinar de manera real la cantidad de recursos que una funcionalidad
demandará es un punto clave para el éxito de Scrum. La comunicación constante entre el PO, el SM y el equipo garantizó que en cada Sprint se trabajara sólo en aquellas funcionalidades que realmente
le interesaban al PO, resolviendo necesidades reales y evitando así la generación de código ocioso
Acerca de los Autores
Omar Otoniel Soto Romero es líder de proyectos del Sistema Financiero en la Universidad de Montemorelos. Es graduado de Ingenieria en Sistemas Computacionales en 1997, y de la Maestria en Administracion de Empresas en 2007. Actualmente cursa la Maestria en Ciencias Computacionales con acentuacion en Ingenieria del Software.
osoto@um.edu.mx
Germán Harvey Alférez Salinas es Coordinador del Departamento de Investigación de la Facultad de Ingeniería y Tecnología en la Universidad de Montemorelos, e investigador asociado de Mission College, Tailandia. Es graduado con honores del Master of Science in Information and Communication
Technology en Assumption University, Tailandia. Sus áreas de interés incluyen software product lines, model driven development, y software architectures.
fit.um.edu.mx/harvey
- Log in to post comments