CP: Experiencias y testimonios sobre proyectos colaborativos
•Download as PPT, PDF•
0 likes•361 views
![Agenda ,[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
Viewers also liked
Viewers also liked (20)
Similar to CP: Experiencias y testimonios sobre proyectos colaborativos
Similar to CP: Experiencias y testimonios sobre proyectos colaborativos (20)
More from Enrique Almeida
More from Enrique Almeida (14)
Recently uploaded
Recently uploaded (16)
CP: Experiencias y testimonios sobre proyectos colaborativos
- 1. Collaborative Projects: Experiencias y Testimonios
- 9. Proyecto Colaborativo GxUnit Enrique Almeida - e [email_address] Alejandro Araújo – alar@bipbip.com.uy Uruguay Larre Borges – ularre@genexusconsulting.com
- 24. GxUnit: Sitios de interés La experiencia http://www.gxopen.com/forumsr/servlet/hsrmain
- 25. Collaborative Projects SummarizedBy Pattern Marcos Crispino – mcrispino@concepto.com.uy Enrique Almeida – ealmeida@concepto.com.uy
- 28. Ejemplo (1)
- 29. Ejemplo (2)
- 39. Experiencias en el desarrollo de Collaborative Projects ¿Preguntas?
Editor's Notes
- Además de organizar los CP, estuve participando en 2 proyectos y de eso es lo que les quiero hablar, de lo que me dejaron los CP por haber participado en los proyectos. Son 2 proyectos totalmente distintos, uno de desarrollo, de mayor envergadura y el otro de documentación de una guía rápida de web services con GeneXus. Espero que esto los motive también a uds a participar en otros proyectos.
- En este proyecto de desarrollo de un web view de foros participé y aquí lo que aprendí fueron básicamente 2 cosas: -Trabajar en equipo con personas agenas a la empresa en la que trabajo. - Trabajar remoto es fácil, es factible. Gabriel Gramajo, uno de los integrantes reside en USA, pero realmente la distancia no nos difucultó en nada. Realmente todo se resuelve con mail, skype y messenger. El hablar (no solo escribir) es importante y por eso el skype.
- En el proyecto de documentación trabajamos 2, el líder fue Iván Padilla de Ecuador. Al principio quería participar una persona más, pero que luego no pudo seguir por temas urgentes en su trabajo que lo requerían 100%.
- Aquí unas imágenes de la documentación en el wiki.
- Cómo se dio? Bueno, Iván cuando hizo web services se encontró con dificultades para encontrar la documentación. Había, pero no estaba ordenada y no había un ejemplo paso a paso para hacerlo. De ahí entonces que me escribió con la motivación de arrancar un CP juntos y accedí. A mi me servía porque quería participar en CPs para ganar experiencia y verlo del lado del participante y además por un tema institucional, de que quedara claro para todos cómo usar web services. Entonces Iván comenzó a organizar, nos repartimos tareas y comenzamos cada uno con su parte. Nos comunicamos por mail simplemente en este proyecto. Intuyo que este CP es el mas chico realizado hasta el momento, pero lo quería también mostrar para que uds puedan pensar también en proyectos así, cortos, e incluso de proyectos de documentación. No precisan ser todos de desarrollar algún producto, etc. Realmente se puede colaborar y trabajar juntos en todos los tipos de proyectos, de desarrollo, de documentación o de testing.
- Iván Padilla fue líder del proyecto actualmente esta liderando otro más.
- 3 preguntas acerca de GxUnit ¿Qué es o será GxUni? ¿Cuál es la motivación? ¿Cómo se construirá, en base a que, en que etapas?
- En el XIV encuentro de usuarios Genexus Enrique Almeida lanzó la propuesta de GxUnit; un marco de pruebas del tipo Xunit, para pruebas unitarias, adaptado a las características de Genexus. Este marco debería permitir escribir las pruebas, almacenarlas, ejecutarlas, guardar y publicar los resultados. Habilitaría la aplicación de la práctica de Test First Programming. Surgían como probablemente necesarias modificaciones a Genexus para permitir sentencias del tipo Try Catch Assert así como diferenciar los objetos de prueba. La idea fue lanzada a la comunidad llamando a la participación voluntaria en el proyecto. Pasaron 2 años…
- Finalmente en Agosto de este año comienza GxUnit como proyecto colaborativo. Se definió que la primera etapa será de investigación y diseño preliminar de la solución, decidiéndose limitar el alcance a pruebas para procedures que pudiera evolucionar en el mediano plazo hacia Business Components. No se considera en la primera etapa la escritura de las pruebas en Genexus , es necesario contar probablemente con sentencias que Genexus no soporta actualmente, pero que se propondrán de ser necesario en el diseño de la solución. Se considera en la primera etapa la elaboración automática de procedimientos para ejecutar las pruebas. El marco de trabajo que se utilice deberá: -Permitir ejecutar pruebas aisladas de un procedimiento o agrupadas en conjuntos (suites) de pruebas. -Registrar los resultados esperados y producidos -Publicar los resultados producidos y esperados, con notificación visual (semáforo). (Características básicas del ambiente de testing según Hunt Y Thomas)
- El testing consiste en tareas de verificación y validación, que responden a las preguntas: Verificación: ¿Se está construyendo el producto correctamente? Validación: ¿Se está construyendo el producto correcto? (CMMi) Un producto construido correctamente y que sea el producto “correcto” podría ser calificado como de buena calidad. El propósito del testing es identificar errores, según la clásica definición de G. Myers. Esto es una forma de evaluar la calidad de un producto identificando defectos. (IEEE-Swebok). Estimamos importante hacer la precisión que muchos factores contribuyen a la calidad, entre ellos una mejor y más completa actividad de testing. Sin embargo no queremos con esto decir que simplemente aumentando la cantidad de esfuerzo de testing se mejora la calidad. GxUnit se orienta a apoyar la prueba dinámica (“testing” de software) correspondiente a las tareas de validación para el testing unitario. ¿Contar con una herramienta como GxUnit podría contribuir a la calidad del software que desarrollamos?
- Esfuerzo y costo total: En la bibliografía se encuentran reiteradas citas considerando que aproximadamente la mitad del tiempo que se tarda en desarrollar un programa es típicamente invertida en actividades de testing. F. Brook en sus ensayos sobre ingeniería de software (Mithycal Man Month) ya sugería 1/3 diseño, 1/6 codificación, 1/2 “testing”. En 1990 Beizer ---reportaba (Software testing techniques) que la mitad del tiempo se invierte en “testing”. Kent Beck nos sugiere emplear solo para pruebas unitarias entre un 25% y 50% del tiempo. ¿Qué ocurre cuando llega la presión por finalizar, cuando se agotan los plazos? Recortamos el “testing”. Entonces comenzamos a transitar el circulo vicioso: más presión, menos testing, más errores. ¿Y que hay acerca del costo? En general el costo de obtener certeza de ejecución satisfactoria insume entre el 50% y el 75% del costo total. ¿Y qué ocurre cuando no se invierte en tiempo y costo lo necesario, o se invierte mal? En el informe NIST (National Institute of Standards and Technologies) 2002, impacto del costo de una inadecuada infraestructura de testing, se cita que el costo anual de las pérdidas debido a estructura de testing inadecuada es de 22.1 a 55 billones de dólares. Probablemente ninguna herramienta resuelva tamaño problema, obviamente menos Gxunit, pero con este tipo de herramientas se puede ir construyendo una estructura más factible.
- Está considerado una buena práctica integrar en forma temprana las diversas actividades de “testing” al ciclo de vida. Tanto los procesos de verificación como de validación deben comenzarse alineados con el comienzo del proyecto de desarrollo. Los casos de prueba pueden escribirse desde un comienzo. Cuanto antes se descubren los errores, menos cuesta su corrección. Es importante detectarlos en la cercanías de la fase del ciclo donde se producen. En las pruebas unitarias se descubre en promedio el 33 % del total de errores y el costo es muy inferior a descubrirlo en etapas posteriores, por lo que tener una adecuada infraestructura para dichas pruebas redundará en beneficios.
- Automatizar no es solo probar automáticamente, sino también verificar los resultados. Nos motiva saber que podemos generar procedimientos en forma automática y aprovechar en muchos sentidos las ventajas de Genexus. La automatización requiere actividades de programación, el “testware” implica que debemos encargarnos del código de los test, que también puede tener errores (¿quièn vigila a los vigilantes? –Virgilio-). Genexus creo que puede ayudar en tal sentido, tal como nos ayuda con la programación. GxUnit puede ser un comienzo.
- Se han identificado varios aspectos que se están investigando: -Otros proyectos: ¿Qué se está haciendo y en que forma podemos unificar esfuerzos? --Motor para implementar la generación de procedimientos. Framework para ejecutarlos, guardar resultados, publicarlos, métricas y estadísticas, etc. -Posibilidad de integrar el motor y el marco al IDE de Genexus: ¿Se espera a la versión Rocha? -Estado de la base de datos: Métodos para la estabilidad de la base de datos e inicialización; resultados de las pruebas.
- Se han identificado varios aspectos que se están investigando: -Patrones de testing: Se buscará alinearse con patrones de testing para el diseño de la solución a implementar, comenzando con “single test patterns”. -Propiedades o tipo de objeto: Objeto para pruebas. Propiedades: Resultado (semáforo) de última ejecución, probado-no probado. -¿Cómo escribir las pruebas?: Sentencias Try Catch Assert. Inclusión de plugin para captura de datos para las pruebas.
- Queremos compartir algunas reflexiones acerca de la experiencia.
- Es muy importante buscar integrarse con otros proyectos, para darse valor mutuamente y no reinventar la rueda. En particular se integraría con el proyecto FIT para Genexus, así como FullGx del cual les hablarán en la próxima charla. El tiempo de 3 meses no es suficiente para un proyecto que se proponga objetivos muy ambiciosos. Entendemos que GxUnit en su totalidad contiene objetivos ambiciosos, por lo cual hemos decido que el objetivo principal inicial sea la concepción de la herramienta. Finalmente, todo depende de la cantidad de colaboradores, la cantidad de horas que puedan dedicar, la debida gestión del proyecto, etc. Pero fundamentalmente depende, como todo proyecto, de las personas, de la capacidad de comunicación, y de la sinergia que el trabajo en grupo provoque.
- Explicar qué es la aplicación de Procesamiento de Logs: logs de errores Java que se clasifican por tipo, fecha, cliente, programa, etc. La pantalla de resumen tiene: un conjunto de filtros en la parte superior varias categorías de datos, donde se tiene la cantidad de errores clasificada por cliente, tipo de error, fecha, etc. haciendo click en las cantidades, muestra una pantalla con los logs que componen ese total.
- Sistema de problemas y solicitudes: se ingresan solicitudes de trabajo para un cliente, con un encargado de corregir y una persona que realiza el seguimiento, y la solicitud pasa por varios estados. Igual que en la pantalla anterior se tiene: un conjunto de filtros varias categorías de datos, pero en este caso se muestran dos indicadores: cantidad de solicitudes y promedio de días también se puede ir a una pantalla con el detalle al hacer click en los links. Hay otras aplicaciones que presentan el mismo esquema. => identificamos claramente un patrón.