10. Estimación Visión General del Proceso Experiencia Recuento de GXPoints Ponderación por productividad promedio Requerimientos / Funciones Esfuerzo Total Estimación de Objetos GX Ponderación por esfuerzo promedio Recuento de Puntos de Función Ponderación por productividad promedio
11. GX Consulting Development Framework: Metodología para la estimación de tiempos de un proyecto Ing. Marcela Corbo, MBA GenexusConsulting Ing. Alejandra Lemos, PMP GenexusConsulting
16. GX ConsultingDevelopment Framework: Análisis y desarrollo, buenas prácticas para la convivencia Juan van de Kerchove GenexusConsulting Alfonso Falconi GenexusConsulting
18. ¿Cómo diseñamos una aplicación GX? Requerimientos Requerimientos Modelo GeneXus (Objetos GX) Modelo GeneXus (Objetos GX) Modelo de Base de Datos y Programas Modelo de Base de Datos y Programas Aplicación (ejecutable) Aplicación (ejecutable)
19. Modelo de Procesos y Actividades Modelo de Módulos Modelo de Entidades Modelo de Explotación El Modelo Funcional Proceso Datos Explotación
20.
21. ¿Cómo diseñamos una aplicación? Requerimientos Mas Semántica GX-PatternsK2btools - Patterns UI Diseño Patrones Navegación Modelo GeneXus (Objetos GX) Modelo de Base de Datos y Programas Aplicación (ejecutable)
24. Arquitectura del Software Fuentes de DatosExternas Integración de ComponentesExternos Web Services .Net Assembly Base de Datos ArchivosPlanos y XML Clase Java XML Schema Archivos Excel User Control Especifico SISTEMA
38. GX ConsultingDevelopment Framework: Usabilidad de sus aplicaciones utilizando GeneXus X y K2B Tools Carolina Torrado GenexusConsulting Hernán Hiriart Crudo Media
40. ¿Quién no escuchó…? “¿Y eso cuánto te puede llevar probarlo…?” “Pero eso, con una “pasadita” por arriba alcanza…” “No lo pruebes porque modifiqué solo esta cosita...”
41. TEST Especialización de la Tarea de Test Herramientas de Test GXTEST Gestión de Errores e Incidentes Experiencia de un cliente
42. Y PENSAR QUE ME HABÍAN DICHO… Ing. Natalia Dimu, PMP ndimu@genexusconsulting.com
44. Preparando el terrenoPreproducción y Producción Infraestructura SistemaOperativo: Win/Linux; 32/64 bits Herramientasparaayudar al “deploy” , Java y .Net Servidores (BD,Aplicaciones, Web, etc.) Stack Tecnológico Genexus Etc. Ambientes de Test y Producción lo másparecidosposibles
45. Deployment de Aplicaciones GeneXus Ing. Pablo Alzuri, Ing. Guillermo González GeneXusConsulting palzuri@genexusconsulting.com ggonzalez@genexusconsulting.com
48. Oportunidad Compartiendo: Buenas Prácticas, Metodologías y Herramientas Genexus X es una plataforma que habilita la colaboración y desarrollo de extensiones. GXC Develop. Framework en FOROS de: www.genexusconsulting.com
GX ConsultingDevelopment Framework: Lecciones aprendidas en disciplinas de Desarrollo de Sistemas.Las lecciones aprendidas en gestión de proyectos, dimensionamiento y estimación, desarrollo y test, se sintetizan en un marco compuesto por metodologías y herramientas denominado “GeneXusDevelopment Framework".Orador: Daniel Dávila
Otra forma de verlo, un proyecto 8.000 PF, requeriría equipos y tiempos muy diferentes usando GX o una herramienta o lenguaje de 3GL Creemos que el concepto esta claro a esta altura, y los números son impactantes.
El desarrollo de proyectos con alta productividad no solo tiene que ver con el espacio de construcción sino con un conjunto de actividades y herramietnas que operan en todas las fases del ciclo de vida del software en construcción.GenexusConsultingDevelopment FrameworkVolviendo a nuestra idea hoy, y de los próximos días del encuentro, de presentarles lo que hemos dado en llamar Genexus C. Development Framework.Decíamos que allí recogemos un conjunto de buenas prácticas y herramientas ha aplicar a lo largo de las diferentes fases del ciclo de vida de los productos de software. El lograr productividad y realizar buenos proyectos (calidad en sentido amplio) requiere realizar correctamente una serie de actividades…que aquí plantearemos para diferentes fases del proyecto tipos, herramientas para de cada uno de sus ciclos o versiones. Estamos trabajando en la sistematización de prácticas y herramientas, para todo el ciclo de vida, desde la gestión de requerimientos, desde que nace la idea o la necesidad del sistema,… hasta que se entrega software ejecutando.Buscando de alguna manera la visión de Artech y de BGV en particular, de elevar el nivel de abstracción de forma que el desarrollo, esté cada vez más cerca del usuario. La “programación” este cada vez más cercano a la especificación para cubrir todo el ciclo de obtener software que funcione. Vamos a ver por ejemplo, en la etapa de diseño una propuesta de metodología y las líneas de investigación de forma establecer un nuevo puente digamos entre la especificación de CU hacia Diseño y Construcción en GX, conceptos que se está trabajando y que hemos visto llamar ModelDriven.Extenderemos la consideración hacia las puntas, saliendo del escenario central de construcción, y buscando herramientas para extender Genexus en este aspecto.Estamos de alguna manera saliendo del núcleo central de diseño-construcción-prueba (muy cercano a la construcción) que podemos visualizar propiamente en los cursos Genexus, y de alguna forma “extendiendonos” hacia las puntas (en algunos casos son hoy prácticas, lineamiento y métodos) pero serán herramientas en un futuro próximo… un ciclo natural la extension a herramientas (en particular Genexus hoy propone las Extensions que posibilitan técnicamente la integración de herramientas).* Framework y herramientasFrameWork es un concepto sumamente genérico, se refiere a “ambiente de trabajo, y ejecución”, por ejemplo “.Net” es considerado un “framework” para desarrollar aplicaciones.En general los framework contemplan herramientas de apoyo a la construcción (ambiente de trabajo o desarrollo) y motores de ejecución (ambiente de ejecución). Siguiendo con el ejemplo: “.Net” ofrece el “Visual Studio .net” (ambiente construcción o desarrollo) que le permite a lo desarrolladores construir aplicaciones, y su motor es el “.Netframework” que permite ejecutar dichas aplicaciones. Análogamente ocurre en entornos JAVA.Estamos usando aquí el concepto de FRAMEWORK en referencia a proyectos Genexusy expresando la orientación, además de definir prácticas útiles, al de contar con herramientas de apoyo. Por ejemplo, K2BTOOLS, para proceso de diseño y construcción basado en patrones, GXTEST de Abstrata para las (incorporado ahora a la cartera de productos Genexus), a GXSERVER ahora en X Ev1, y GXTEND de Accendo y SVT AdminG de Intergsoft , en la 9.0 para administración y control de versiones (SCM).
¿Como diseñamos esta aplicación con GeneXus?:Diseñamos un modelo GeneXus que satisfaga los requerimientos de los usuarios, y luego GX , a partir de ese modelo , generará la aplicación en alguna plataforma y algún lenguaje de programación. GeneXus nos da una gran ventaja en todo esto: La especificación de la aplicación se hace a un nivel de abstracción mucho más alto que si tuviéramos que especificarla a nivel de tablas y programas. De esta forma no nos preocupamos por detalles técnicos de bajo nivel, el modelo que construimos es independiente de la plataforma, y ambas cosas nos dan nos da grandes ventajas : el proceso es más simple y mucho más productivo.Pero.. ¿hacemos algo más entre los requerimientos y la especificación de ese modelo en GeneXus? Muchas veces no . Y está bien.En muchas aplicaciones donde las características de la misma hacen que mappear los requerimientos a un modelo GeneXus es claro y simple, no es necesario. Dicho de otra manera, el nivel de abstracción que nos da GeneXus es suficiente. Personalmente he construido muchas aplicaciones de esta manera. Sin embargo, existen otros escenarios, de aplicaciones más grandes, más complejas, con más actores, donde necesitamos construir modelos más abstractos antes de ir al modelo GeneXus. De esos modelos, es lo que estaremos charlando hoy. En GeneXus Consulting hemos recogido las experiencias en las diferentes consultorías a lo largo de los años, y hemos llegado a definir un modelo (con una metodología asociada) que nos ha resultado muy útil para describir funcionalmente una aplicación . En este modelo formalizamos prácticas que muchos ya aplicamos desde hace tiempo. Como pasa habitualmente, pero la conceptualización y formalización de las ideas, contribuye definitivamente en aclararlas.Queremos compartir este modelo con ustedes. El primer objetivo es ayudar en el proceso de análisis:La idea es entonces proponer un modelo para describir y diseñar funcionalmente una aplicación (modeldrivendesign), que: sea más abstracto (que nos oculte detalles de implementación) y se centre en lo funciona que nos guíe y apoye en el análisis que nos permita entenderla que nos permita comunicarlay discutirla Esto ya de por sí, solamente con metodología nos da un valor interesante, pero además queremos que ese modelo sea la base para la implementación de la aplicación: queremos especificar ese modelo en una base de conocimiento GX sin necesidad de hacer un mappingy poder generar la aplicación en forma automática en base a él. Elobjetivo central es construir aplicaciones con menos esfuerzo de análisis y de especificación (industrialización del software) con las ventajas que esto tiene en: productividad (tanto en la creación como en el mantenimiento), más calidad de las aplicaciones (libre de errores), más usables, y con más cobertura funcional.Este es una propuesta en la linea del objetivo que planteaba BGV en una de sus presentaciones anteriores en este encuentro *** hacia la 4ta dimension ***, subir el nivel de abstracción de Genexus.
Una clasificación semántica que aplica a casi todas las aplicaciones de negocio, es la siguiente. Actores: Son personas u organizaciones que interactúan con la aplicación, que tienen la iniciativa en la misma. (usuarios, clientes, proveedores, La empresa) Objetos: Son objetos que no tienen iniciativa en el sistema. Pueden especificar objetos tangibles de la realidad (Productos, Monedas) o ser objetos que se crean para clasificar y definir comportamiento más sofisticado a los sistemas (Categorías, Formas de Pago, etc.) Eventos: Son las entidades que materializan las cosas "que ocurren" en la empresa. (Órden de Compra, Factura, etc). Solamente con esta clasificación puedo inferir una cantidad de cosas, datos y comportamiento:- Que los actores : Son o bien personas físicas o jurídicas, deben tener información de contacto (direcciones y teléfonos), al participar en los eventos lo hacen con algún rol, por lo tanto deben tener roles asociados. Que los eventos deben ocurrir en algún lugar (físico o virtual) que ocurren en algún momento en el tiempo (tiene información sobre fechas), que en general intercambian algún objeto o recurso, etc. Y que seguramente quiera información agregada por el valor del evento, el valor del intercambio según ciertas dimensiones. Con esta semántica entonces y patrones, podemos inferir entonces para las entidades datos que deben tenerreglas que deben cumplirservicios que deben proveer. + SemánticaPodemos agregar aun más semántica a esta clasificación, y podemos separar los Eventos en:Eventos Económicos. Son aquellos intercambios de recursos, que representan un incremento o decremento de valor en los recursos económicos, y conocerlos nos puede permitir inferir muchas de sus reglas. (por ejemplo que deben tener algún tipo de registración contable, que participan 2 actores en el intercambio, etc.) En General: DominiosEn general en las aplicaciones que construimos ya manejamos cierta semántica y si tenemos patrones para modelar esas entidades semánticas, aplicaremos esos patrones para diseñarlos, una vez que los identificamos semánticamente. Esto es independiente si este proceso de aplicar el patrón está automatizado o no. Esto vale incluso aunque lo hagamos por metodología, en forma manual. De esta forma logramos diseños muy buenos, con menos esfuerzo y además logramos una coherencia conceptual y homogeneidad en el diseño de la aplicación. En K2B por ejemplo, usamos varios patrones que ya forman parte de nuestro vocabulario. Al diseñar no hablamos ya de transacciones, ni siquiera de entidades. Hablamos de: Eventos, Distribución de costos Posting Contable InventariosEntonces si tenemos que diseñar algo nuevo, lo primero que hacemos es en ubicarlo semánticamente: O sea, decimos esto es un evento que no necesita distribución de costos, que tendrá posting contable y que debe actualizar su inventario. Esto ya define como se debe diseñar, no hay que pensar demasiado para eso. (y guardamos la mente para nuevos problemas)Si bien esto tiene un gran valor ya de por si, solo como metodologia del equipo, si podemos automatizar esto en GeneXus, ademas de lograr mejor productividad, el conocimiento de esos patrones queda dentro del modelo.
Tareas que debe hacer un administrador del consolidado de una KB GX y como se deben manejar los desarrolladores del proyecto para obtener un producto exitoso.Puede llegar a ser un verdadero dolor de cabeza… felizmente hay herramientas que los ultimos años han aparecido para ayudar…
Aparece también la posibilidad de administrar diferentes versiones del software desde GXSERVER. Versiones de Test, de Produccción, versiones de desarrollo de una Version 2 del software, en cuanto continua el mantenimiento correctivo de la Version 1. De ahora en más, así se administraran las versiones, con GXSERVER.Hay numerosas charlas al respecto.En GX 9.0 hemos utilizado GXTend y SVT, que aportan tecnología complementaria para administración de estos temas. Actualmente están en evolución y propondrán extensiones a GXSERVER o alternativas de valor. SVT por ejemplo con importantes aportes aprovechando características de ambientes como AS400.