Collaborative Projects: Experiencias y Testimonios.

  • Published on
    28-Jan-2016

  • View
    218

  • Download
    0

Embed Size (px)

Transcript

  • Collaborative Projects: Experiencias y Testimonios

  • AgendaExperiencias Personales - Armin

    GXUNIT - Alejandro y Uruguay

    Summarized By Pattern Enrique y Marcos

  • ForumSRCollaborative Projects

  • Documentacin y ejemplos de Web ServicesLder: Ivn Padilla(Ecuador)Armin Bachmann(Uy)

  • La HistoriaCmo se dioMotivaciones/beneficiosComunicaciones

  • Testimonio de Ivn Que todas las personas que deseen compartir su conocimiento y experiencias lo hagan ya, as tendremos un crecimiento y unidad mas acelerado, rompamos las barreras de la distancia y unmonos ms. COLABORANDO DECIDIDAMENTE, CRECEMOS TODOS !! Ivn Padilla, Quito-Ecuador.

  • Proyecto Colaborativo GxUnitEnrique Almeida - ealmeida@concepto.com.uyAlejandro Arajo alar@bipbip.com.uyUruguay Larre Borges ularre@genexusconsulting.com

  • GxUnit: Agenda

    Qu es? Por qu? Cmo? Algunas reflexiones

  • Antecedentes: Hubo una vez una propuesta GxUnit Propuesta de Enrique Almeida (XIV Encuentro de Usuarios GeneXus)Integrar las pruebas unitarias a GeneXusEscribir las pruebas en GenexusGenexus facilitando la escritura de las pruebasMarco para ejecutarlasRegistro y publicacin de resultados Conseguir adeptos para el desarrollo

    Qu es?

  • GxUnit: Nace como CP

    Inicio: Agosto 2006Objetivo: Concepcin de un marco de trabajo para pruebas unitarias automatizadas.Inicializacin y borradoEjecucin individual y agrupadaResultados comparados con los esperados Escritura de las pruebas en GenexusGxUnitGeneracin de procedimientos de pruebaQu es?

  • GxUnit

    Qu es? Por qu? Cmo? Algunas reflexiones

  • La importancia del testing en la calidadVerificacin: Se est construyendo el producto correctamente?Validacin: Se est construyendo el producto correcto? El testing es una actividad desarrollada para evaluar la calidad de un producto, por la va de identificar defectos (IEEE-Swebok)GxUnit: MotivacionesPor qu?

  • GxUnit: MotivacionesLa participacin del testing en el tiempo y costo total

    TiempoCosto (Beizer)Por qu?(G. Tassey NIST 2002)

    Chart5

    0.5

    0.5

    Testing

    Sheet1

    50%Testing

    50%

    Sheet1

    0

    0

    Testing

    Sheet2

    Sheet3

  • GxUnit: MotivacionesLa integracin temprana del testing al ciclo de vidaEl esfuerzo de corregir errores crece a medida que avanzamos en el ciclo de vida

    Por qu?(G. Tassey NIST 2002)

  • GxUnit: MotivacionesLa automatizacin de las pruebasAutomatizar implicar probar v validar automticamente los resultados (Hunt & Thomas)

    (Nunit)Por qu?

  • GxUnit: MotivacionesAspectos metodolgicosAplicacin de buenas prcticasAutomatizar pruebas + integracin continua + regresinMtricasTest First Programming

    Por qu?

  • GxUnit

    Qu es? Porqu? Cmo? Algunas reflexiones

  • GxUnit: Investigacin

    Bsqueda de proyectos complementarios

    Desarrollo del motor y marco de trabajo

    Integracin al IDE de Genexus (Rocha?)

    Estado de la base de datos

    Cmo?

  • GxUnit: Investigacin

    Patrones

    Nuevos tipos de objetos (Rocha?)

    Cmo escribir las pruebas? Sentencias Try/Catch AssertOtras posibilidades?

    Cmo?

  • GxUnit

    Qu es? Porqu? Cmo? Algunas Reflexiones

  • GxUnit: Algunas reflexiones

    Integracin con otros Proyectos FullGx FIT(W.Cunningham) para GenexusTiempo Sub proyectosGxUnit proceduresConcepcinConstruccinRecursos (Humanos!)

    La experiencia

  • GxUnit: Sitios de inters

    La experienciahttp://www.gxopen.com/forumsr/servlet/hsrmain

  • Collaborative ProjectsSummarizedBy PatternMarcos Crispino mcrispino@concepto.com.uy Enrique Almeida ealmeida@concepto.com.uy

  • ParticipantesEnrique Almeida (Concepto, Uruguay)Marcos Crispino (Concepto, Uruguay)Nicolas Jodal (Artech, Uruguay)Federico Dominioni (GX Consulting, Uruguay)Daniel Coellar (Etapa Telecom, Ecuador)Gabriel Medina (GXSoft, Argentina)

  • MotivacinPantalla de resumen en aplicaciones web

    Siempre son similares

    Se identifica claramente un patrn

  • Ejemplo (1)

  • Ejemplo (2)

  • EtapasMarzo/2005 Surge la idea y se registra en el WikiJunio/2006 Se decide implementar como Collaborative ProjectJulio/2006 Ejemplo cannicoAgosto/2006 DesarrolloSetiembre/2006 Liberacin versin 1.0

  • Collaborative ProjectsExperiencia nuevaExperiencia multi-diciplinariaProyecto DifusoComunicacin humanaPlan inicial

  • Consejos para prximos CPDefinir claramenteObjetivo y Grupo de TrabajoIntereses de los participantesEtapas (y un lder para cada etapa)RolesRecursos

  • Mejoras para los CPTO-DO Lists compartidasGXOpen con pedazos de proyectosForos de ProyectosRepositorio con versionadoHerramientas para facilitar pruebasCambio de logo

  • Charlas relacionadas

  • ConclusionesLos Collaborative Projects sirvenSe implement el PatternDesarrollo rpido (3 meses)Implementar ideas dormidasCompartir conocimientos y aprenderConocer gente y otras realidadesSatisfacen necesidades de la comunidad

  • Experiencias en el desarrollo de Collaborative Projects

    Preguntas?

    Adems 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 documentacin de una gua rpida de web services con GeneXus.

    Espero que esto los motive tambin 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 bsicamente 2 cosas:-Trabajar en equipo con personas agenas a la empresa en la que trabajo.- Trabajar remoto es fcil, 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 documentacin trabajamos 2, el lder fue Ivn Padilla de Ecuador.Al principio quera participar una persona ms, pero que luego no pudo seguir por temas urgentes en su trabajo que lo requeran 100%.Aqu unas imgenes de la documentacin en el wiki.Cmo se dio? Bueno, Ivn cuando hizo web services se encontr con dificultades para encontrar la documentacin. Haba, pero no estaba ordenada y no haba un ejemplo paso a paso para hacerlo.De ah entonces que me escribi con la motivacin de arrancar un CP juntos y acced.

    A mi me serva porque quera participar en CPs para ganar experiencia y verlo del lado del participante y adems por un tema institucional, de que quedara claro para todos cmo usar web services.

    Entonces Ivn 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 quera tambin mostrar para que uds puedan pensar tambin en proyectos as, cortos, e incluso de proyectos de documentacin. No precisan ser todos de desarrollar algn producto, etc. Realmente se puede colaborar y trabajar juntos en todos los tipos de proyectos, de desarrollo, de documentacin o de testing.Ivn Padilla fue lder del proyecto actualmente esta liderando otro ms.3 preguntas acerca de GxUnitQu es o ser GxUni?Cul es la motivacin?Cmo 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 caractersticas de Genexus.Este marco debera permitir escribir las pruebas, almacenarlas, ejecutarlas, guardar y publicar los resultados.Habilitara la aplicacin de la prctica de Test First Programming. Surgan 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 participacin voluntaria en el proyecto.Pasaron 2 aos

    Finalmente en Agosto de este ao comienza GxUnit como proyecto colaborativo.Se defini que la primera etapa ser de investigacin y diseo preliminar de la solucin, decidindose 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 propondrn de ser necesario en el diseo de la solucin. Se considera en la primera etapa la elaboracin automtica 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 notificacin visual (semforo).(Caractersticas bsicas del ambiente de testing segn Hunt Y Thomas)El testing consiste en tareas de verificacin y validacin, que responden a las preguntas:Verificacin: Se est construyendo el producto correctamente?Validacin: Se est construyendo el producto correcto? (CMMi)Un producto construido correctamente y que sea el producto correcto podra ser calificado como de buena calidad.

    El propsito del testing es identificar errores, segn la clsica definicin de G. Myers.Esto es una forma de evaluar la calidad de un producto identificando defectos. (IEEE-Swebok).Estimamos importante hacer la precisin que muchos factores contribuyen a la calidad, entre ellos una mejor y ms 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 dinmica (testing de software) correspondiente a las tareas de validacin para el testing unitario.

    Contar con una herramienta como GxUnit podra contribuir a la calidad del software que desarrollamos?

    Esfuerzo y costo total:

    En la bibliografa se encuentran reiteradas citas considerando que aproximadamente la mitad del tiempo que se tarda en desarrollar un programa es tpicamente invertida en actividades de testing. F. Brook en sus ensayos sobre ingeniera de software (Mithycal Man Month) ya sugera 1/3 diseo, 1/6 codificacin, 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 presin por finalizar, cuando se agotan los plazos? Recortamos el testing. Entonces comenzamos a transitar el circulo vicioso: ms presin, menos testing, ms errores.

    Y que hay acerca del costo? En general el costo de obtener certeza de ejecucin 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 prdidas debido a estructura de testing inadecuada es de 22.1 a 55 billones de dlares.Probablemente ninguna herramienta resuelva tamao problema, obviamente menos Gxunit, pero con este tipo de herramientas se puede ir construyendo una estructura ms factible.Est considerado una buena prctica integrar en forma temprana las diversas actividades de testing al ciclo de vida. Tanto los procesos de verificacin como de validacin 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 correccin. Es importante detectarlos en la cercanas 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 automticamente, sino tambin verificar los resultados. Nos motiva saber que podemos generar procedimientos en forma automtica y aprovechar en muchos sentidos las ventajas de Genexus.La automatizacin requiere actividades de programacin, el testware implica que debemos encargarnos del cdigo de los test, que tambin puede tener errores (quin vigila a los vigilantes? Virgilio-). Genexus creo que puede ayudar en tal sentido, tal como nos ayuda con la programacin. GxUnit puede ser un comienzo.

    Se han identificado varios aspectos que se estn investigando:-Otros proyectos: Qu se est haciendo y en que forma podemos unificar esfuerzos?--Motor para implementar la generacin de procedimientos. Framework para ejecutarlos, guardar resultados, publicarlos, mtricas y estadsticas, etc. -Posibilidad de integrar el motor y el marco al IDE de Genexus: Se espera a la versin Rocha?-Estado de la base de datos: Mtodos para la estabilidad de la base de datos e inicializacin; resultados de las pruebas.

    Se han identificado varios aspectos que se estn investigando:-Patrones de testing: Se buscar alinearse con patrones de testing para el diseo de la solucin a implementar, comenzando con single test patterns.-Propiedades o tipo de objeto: Objeto para pruebas. Propiedades: Resultado (semforo) de ltima ejecucin, probado-no probado. -Cmo escribir las pruebas?: Sentencias Try Catch Assert. Inclusin 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 integrara con el proyecto FIT para Genexus, as como FullGx del cual les hablarn en la prxima 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 concepcin de la herramienta.

    Finalmente, todo depende de la cantidad de colaboradores, la cantidad de horas que puedan dedicar, la debida gestin del proyecto, etc. Pero fundamentalmente depende, como todo proyecto, de las personas, de la capacidad de comunicacin, y de la sinergia que el trabajo en grupo provoque.

    Explicar qu es la aplicacin 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 superiorvarias categoras 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 filtrosvarias categoras de datos, pero en este caso se muestran dos indicadores: cantidad de solicitudes y promedio de dastambin 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 patrn.

Recommended

View more >