Mesa Redonda GXOpen. GXOpen Objetivo y Esencia Lo que tenemos para lograrlo Objetivo y Esencia Lo que tenemos para lograrlo.

Presentación del tema: "Mesa Redonda GXOpen. GXOpen Objetivo y Esencia Lo que tenemos para lograrlo Objetivo y Esencia Lo que tenemos para lograrlo."— Transcripción de la presentación:

1 info@gxopen.com.uy Mesa Redonda GXOpen

2 GXOpen Objetivo y Esencia Lo que tenemos para lograrlo Objetivo y Esencia Lo que tenemos para lograrlo

3 Compartir y transmitir conocimiento Consolidar una comunidad La esencia es la actitud de compartir Compartir y transmitir conocimiento Consolidar una comunidad La esencia es la actitud de compartir Esencia y Objetivo

4 Lo que tenemos para lograrlo Creación de proyectos comunitarios Incluir subproyectos a nuestros proyectos El foro de GXOpen El aporte propio Creación de proyectos comunitarios Incluir subproyectos a nuestros proyectos El foro de GXOpen El aporte propio

5 GXOpen Compartir No reinventar la rueda Ahorro de tiempo Aprendizaje continuo Compartir No reinventar la rueda Ahorro de tiempo Aprendizaje continuo

6 GXOpen Estado actual Biblioteca de proyectos Cantidad y variedad Biblioteca de recursos Styles Themes Iconos Estado actual Biblioteca de proyectos Cantidad y variedad Biblioteca de recursos Styles Themes Iconos

7 GXOpen Cambio Cualitativo Planteo de Metas ambiciosas Proyectos de largo alcance (ej: ERP) Sistemas Integrados e Integrables Plan directriz (Donde queremos ir) Cambio Cualitativo Planteo de Metas ambiciosas Proyectos de largo alcance (ej: ERP) Sistemas Integrados e Integrables Plan directriz (Donde queremos ir)

8 GXOpen Hay Lugar para todos los roles Coordinador de proyecto Análisis Documentadores Testers Hay Lugar para todos los roles Coordinador de proyecto Análisis Documentadores Testers

9 GXOpen Sistemas que se reinventan una y otra vez: Stock Personas Liquidación de sueldos Facturación Seguimiento de Expedientes Sistemas que se reinventan una y otra vez: Stock Personas Liquidación de sueldos Facturación Seguimiento de Expedientes

10 Patrones de software y Genexus Patrones de software Concepto: Un patrón es un documento que captura “best practices”, experiencia en un formato que permite a otros reutilizarla Origen: Surge en la arquitectura, y luego se aplica a muchas disciplinas, incluyendo la Ingeniería de Software Definición: ”Cada patrón es una regla conformada por tres partes, que expresa una relación entre un cierto contexto, un problema y una solución” Christopher Alexander Patrones de software Concepto: Un patrón es un documento que captura “best practices”, experiencia en un formato que permite a otros reutilizarla Origen: Surge en la arquitectura, y luego se aplica a muchas disciplinas, incluyendo la Ingeniería de Software Definición: ”Cada patrón es una regla conformada por tres partes, que expresa una relación entre un cierto contexto, un problema y una solución” Christopher Alexander

11 Patrones de software y Genexus Clases de patrones Cada disciplina requiere un tipo distinto de patrón, de acuerdo al conocimiento que desea capturar Algunas clases de patrones de software: Patrones de Diseño de software Patrones de Análisis de software Patrones de Implementación de software Patrones de Arquitectura de software Existen patrones en la Arquitectura, en la Administración, Gestión de proyectos, etc. Clases de patrones Cada disciplina requiere un tipo distinto de patrón, de acuerdo al conocimiento que desea capturar Algunas clases de patrones de software: Patrones de Diseño de software Patrones de Análisis de software Patrones de Implementación de software Patrones de Arquitectura de software Existen patrones en la Arquitectura, en la Administración, Gestión de proyectos, etc.

12 Patrones de software y Genexus Ejemplo Genexus: “Trabajar con” Es un patrón porque cumple los 3 requisitos Soluciona un problema recurrente: el ABM de registros Tiene un nombre conocido por todos Es una solución abstracta, ya que se describen los componentes y sus relaciones que luego deben ser instanciados al aplicar el patrón Claro, es un patrón muy simple... Los patrones más útiles presentan soluciones no obvias a problemas recurrentes Ejemplo Genexus: “Trabajar con” Es un patrón porque cumple los 3 requisitos Soluciona un problema recurrente: el ABM de registros Tiene un nombre conocido por todos Es una solución abstracta, ya que se describen los componentes y sus relaciones que luego deben ser instanciados al aplicar el patrón Claro, es un patrón muy simple... Los patrones más útiles presentan soluciones no obvias a problemas recurrentes

13 Patrones de software y Genexus ¿Por qué patrones? Los patrones recogen soluciones probadas a problemas recurrentes en cierto contexto Los beneficios de su uso por una comunidad son múltiples: Se comparte la experiencia o conocimiento de la comunidad Generan un lenguaje común dando nombres a distintas soluciones de problemas comunes Homogenizan las aplicaciones construidas Mejoran la productividad quien los usa En suma, compartir experiencia y no solo código ¿Por qué patrones? Los patrones recogen soluciones probadas a problemas recurrentes en cierto contexto Los beneficios de su uso por una comunidad son múltiples: Se comparte la experiencia o conocimiento de la comunidad Generan un lenguaje común dando nombres a distintas soluciones de problemas comunes Homogenizan las aplicaciones construidas Mejoran la productividad quien los usa En suma, compartir experiencia y no solo código

14 Patrones de software y Genexus OK, los patrones son beneficiosos... ¿Y ahora? En cada comunidad, existen diferentes mecanismos de definición y validación de patrones, desde GxOpen podemos establecer los nuestros ¿Qué hay para hacer? Elegir que clase o clases de patrones necesitamos, o sea, que experiencia nos interesa compartir Escribir una plantilla para patrones Crear grupos que trabajen sobre cada patrón que se detecte Motivar al resto de la industria a aportar su conocimiento y experiencia OK, los patrones son beneficiosos... ¿Y ahora? En cada comunidad, existen diferentes mecanismos de definición y validación de patrones, desde GxOpen podemos establecer los nuestros ¿Qué hay para hacer? Elegir que clase o clases de patrones necesitamos, o sea, que experiencia nos interesa compartir Escribir una plantilla para patrones Crear grupos que trabajen sobre cada patrón que se detecte Motivar al resto de la industria a aportar su conocimiento y experiencia

15 Organización en la Publicación de Proyectos Objetivos de esta Presentación: Establecer una serie de pasos a seguir a la hora de públicar un proyecto. Se pretende que esta presentación sirva de guía a los integrantes de esta comunidad para que puedan brindar mas información del proyecto que se pública. Con esto se intenta incentivar a la reutilización de código y poder tener una idea clara del proyecto que se esta bajando sin tener que probarlo. Objetivos de esta Presentación: Establecer una serie de pasos a seguir a la hora de públicar un proyecto. Se pretende que esta presentación sirva de guía a los integrantes de esta comunidad para que puedan brindar mas información del proyecto que se pública. Con esto se intenta incentivar a la reutilización de código y poder tener una idea clara del proyecto que se esta bajando sin tener que probarlo.

16 Organización en la Publicación de Proyectos Con qué nos encontramos a la hora de descargar un Proyecto? No es clara la idea del Proyecto La descripción de las versiones no es buena o no existe No existe buena documentación No se indica la versión de GX en la que fue desarrollado No hay guía de desarrollo ni de implementación Con qué nos encontramos a la hora de descargar un Proyecto? No es clara la idea del Proyecto La descripción de las versiones no es buena o no existe No existe buena documentación No se indica la versión de GX en la que fue desarrollado No hay guía de desarrollo ni de implementación

17 Organización en la Publicación de Proyectos No se documentan las mejoras en las versiones En ocasiones no se entienden los criterios a la hora de publicar distintas versiones de un mismo proyecto Se utiliza mucho código externo a la hora de desarrollar No se siguen estandares de desarrollo para nombrar atributos y variables No se documentan las mejoras en las versiones En ocasiones no se entienden los criterios a la hora de publicar distintas versiones de un mismo proyecto Se utiliza mucho código externo a la hora de desarrollar No se siguen estandares de desarrollo para nombrar atributos y variables

18 Organización en la Publicación de Proyectos Que proponemos para organizar y mejorar la publicación de Proyectos Dejar clara la idea del proyecto por medio de documentación o en la descripción del mismo. Mejorar las descripciones de las versiones que se públican. No poner descripciones que son iguales al título de la versión. Acompañar los proyectos de documentación descriptiva que puede ser técnica o simplemente de usuario. Que proponemos para organizar y mejorar la publicación de Proyectos Dejar clara la idea del proyecto por medio de documentación o en la descripción del mismo. Mejorar las descripciones de las versiones que se públican. No poner descripciones que son iguales al título de la versión. Acompañar los proyectos de documentación descriptiva que puede ser técnica o simplemente de usuario.

19 Organización en la Publicación de Proyectos Indicar la versión de GX en la que se desarrollo el Proyecto e indicar Generador Hacer una pequeña guía de implementación e indicar si es necesario hacer referencia a alguna DLL o OCX si fuese necesario Crear una breve documentación de las mejoras cuando se públican nuevas versiones de un Proyecto Indicar la versión de GX en la que se desarrollo el Proyecto e indicar Generador Hacer una pequeña guía de implementación e indicar si es necesario hacer referencia a alguna DLL o OCX si fuese necesario Crear una breve documentación de las mejoras cuando se públican nuevas versiones de un Proyecto

20 Organización en la Publicación de Proyectos Ser ordenados a la hora de incrementar las versiones de un Proyecto. Seguir todos el mismo críterio Evitar la utilización de código externo a GeneXus. Si es pósible no utilizar código que no sea GeneXus. Esto para poder probar las versiones en cualquier generador sin tener que saber un lenguaje en especial. Para poder facilitar la reutilización de código proponemos que se utilize la nomenclatura GIK para nombrar atributos Ser ordenados a la hora de incrementar las versiones de un Proyecto. Seguir todos el mismo críterio Evitar la utilización de código externo a GeneXus. Si es pósible no utilizar código que no sea GeneXus. Esto para poder probar las versiones en cualquier generador sin tener que saber un lenguaje en especial. Para poder facilitar la reutilización de código proponemos que se utilize la nomenclatura GIK para nombrar atributos

21 Organización en la Publicación de Proyectos Nomenclatura GIK ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilización de conocimiento entre ellos. Nombre de atributo> Objeto + Categoría + Calificador Objeto: Es el nombre del Objeto al que pertenece el atributo Categoría: Es la categoría semántica del atributo Calificador: Puede existir uno o dos calificadores. Nomenclatura GIK ARTech ha definido un Standard para la nomenclatura de atributos, el GIK (GeneXus Incremental Knowledge Base). Puede gustarnos más o menos que otros. Lo importante es que es el utilizado por la comunidad de usuarios GeneXus. Esto viabiliza reutilización de conocimiento entre ellos. Nombre de atributo> Objeto + Categoría + Calificador Objeto: Es el nombre del Objeto al que pertenece el atributo Categoría: Es la categoría semántica del atributo Calificador: Puede existir uno o dos calificadores.

22 Organización en la Publicación de Proyectos Ejemplo de Nomenclatura GIK Transacción Clientes ObjetoCategoría Calificador Atributo Cli Cod CliCod Cli NomCliNom Cli Fch Nac CliFchNac Cli Fch Ing CliFchIng Ejemplo de Nomenclatura GIK Transacción Clientes ObjetoCategoría Calificador Atributo Cli Cod CliCod Cli NomCliNom Cli Fch Nac CliFchNac Cli Fch Ing CliFchIng

23 Organización en la Publicación de Proyectos Conclusiones: Acompañar el XPW o XPZ de los siguientes archivos: Readme.txt que contenga: Idea y descripción general del Proyecto Versión y Generador de GeneXus en el que fue desarrollado Versión.txt que contenga: Versión del Proyecto Descripción de la Versión Mejoras incorporadas con la versión Cambios realizados con respecto a la versión anterior Conclusiones: Acompañar el XPW o XPZ de los siguientes archivos: Readme.txt que contenga: Idea y descripción general del Proyecto Versión y Generador de GeneXus en el que fue desarrollado Versión.txt que contenga: Versión del Proyecto Descripción de la Versión Mejoras incorporadas con la versión Cambios realizados con respecto a la versión anterior

24 Organización en la Publicación de Proyectos Desarrollo.txt que contenga: Notas sobre el desarrollo Documentar si se necesitan hacer referencias a dll o OCX Indicar si se tienen que registrar DLL Si se necesitan utilizar procedimientos externos hacer comentarios de cómo hacerlos y si es posible utilizar archivos IGX Otros: Según la magnitud del proyecto se pueden incluir manuales de usuario, de administración y de desarrollo Comentar los programas realizados en GeneXus Para saltar de versión tener en cuenta lo propuesto anteriormente Desarrollo.txt que contenga: Notas sobre el desarrollo Documentar si se necesitan hacer referencias a dll o OCX Indicar si se tienen que registrar DLL Si se necesitan utilizar procedimientos externos hacer comentarios de cómo hacerlos y si es posible utilizar archivos IGX Otros: Según la magnitud del proyecto se pueden incluir manuales de usuario, de administración y de desarrollo Comentar los programas realizados en GeneXus Para saltar de versión tener en cuenta lo propuesto anteriormente

25 La tabla de "Most Active Members" es actualizada con el siguiente criterio: Reviews Very Aceptable 20 Aceptable 10 Medium 0 Not Aceptable-10 Rejected-20 La tabla de "Most Active Members" es actualizada con el siguiente criterio: Reviews Very Aceptable 20 Aceptable 10 Medium 0 Not Aceptable-10 Rejected-20 Most Active Members

26 La tabla de "Most Active Members" es actualizada con el siguiente criterio: Proyectos: Cada proyecto el usuario a creado 100 Cada download de su proyecto 10 Cada versión el usuario ha creado 50 La tabla de "Most Active Members" es actualizada con el siguiente criterio: Proyectos: Cada proyecto el usuario a creado 100 Cada download de su proyecto 10 Cada versión el usuario ha creado 50

27 Usuarios

28 Proyectos

29