Desde hace poco mas de un mes, estamos haciendo builds nocturnos con GeneXus.
Para realizarlos hemos desarrollado un herramienta (KBFullCycle) que permite la realizacion de
- Impacto en la Base de datos
- Especificacion de los objetos con FULLSpecification
- Compilacion de todos los objetos.
- Envio mail de errores y registro de todos los pasos en una base de datos.
Esto nos ha permitido ahorrarnos varias horas de especificacion/generacion en el dia. Ademas se pueden detectar rapidamente los errores que se van cometiendo.
Nos falta
- Generacion del Help.
- Generacion del jar y war en forma automatica para dejar el build en un lugar testeable.
- Incorporar alguna herramienta de testeo automatizado, para que chequee los casos de prueba.
Por ahora, la experiencia ha sido muy positiva.
Auditoria ISO-9000 - Software
En el dia de hoy hemos pasado con exito, la auditoría anual de la norma ISO-9001:2000, en Concepto, para todas sus áreas y procesos.
Ya es el tercer año que estamos certificados, y realmente se notan las ventajas de tener procesos bien definidos, escritos y controlados.
La obligación de definir indicadores para los procesos críticos de la empresa, si bien es una tarea dificil y que insume mucho trabajo, una vez establecida y puesta en funcionamiento, da sus frutos.
Papá, cuando a vos en la escuela te mandaban buscar información, ¿cómo la buscabas con la maquina de escribir?
Anoche estabamos cumpliendo el ritual de lectura nocturna con mis tres hijos (todos en edad escolar) y hablamos de los tiempos en que yo iba a la escuela.
Les contaba que no habia computadoras y que si habia que escribir algo prolijo habia que hacerlo con maquina de escribir.
En eso, Emilia me preguntó:
"Papá, cuando a vos en la escuela te mandaban buscar información, ¿cómo la buscabas con la maquina de escribir?"
Esto me hizo pensar en cuanto ha influido Internet y Google en nuestros niños que ven como natural que cuando se necesita información LA fuente de información es Internet. Cuando la veo buscar en Google y cortar el texto a su programa que le lee en voz alta lo que esta escrito, pienso que nuevas cosas podran realizar con las nuevas herramientas, cuando las han adoptado con tanta naturalidad.
¿Vale la Pena el BetaTesting? - Charla en XV Encuentro Internacional GeneXus -
http://petroglifo.blogspot.com/2005/09/vale-la-pena-el-betatesting-charla-en.html
Como migrar de Visual FoxPro a Java y no morir en el intento - Charla en XV Encuentro Internacional Genexus
http://petroglifo.blogspot.com/2005/09/como-migrar-de-visual-foxpro-java-y-no.h
Diferencias y Similitudes entre el armado de Aplicaciones Empresariales con GeneXus y Puzzle
En las últimas dos semanas, estuvimos armando en familia un puzzle de 1000 piezas, de una foto del puerto de Portofino, Italia. Fue una tarea, que llevó unas cuantas horas de trabajo, de toda la familia.
Las horas de la confección del puzzle, me hicieron pensar en las similutudes entre un Puzzle y ek armado de las aplicaciones empresariales desarrolladas con GeneXus.
Las correspondencia que se pueden encontrar
Piezas del Puzzle = Objetos GeneXus
Una pieza limita con otra = Referencia entre objetos (call, referencia de atributos, etc)
Puzzle terminado = Aplicación que compila y está pronta a ser probada.
Ahi terminan las similitudes y empiezan a verse las dificultades.
Una pieza del Puzzle, tiene únicamente como máximo contacto con 4 otras piezas
Un objeto Genexus, puede tener relacion con cientos (o miles) de otros objetos.
Un puzzle se arma en 2 dimensiones.
La aplicaciones tiene varias dimensiones (varias base de datos, varia plataformas win/web/pda)
Las aplicaciones GeneXus (y las de soluciones orientadas a empresas) son un puzzle mucho mas complicado de armar que los puzzles tradicionales.
Para esto es importante, perfeccionar las herramientas del armado de la aplicacion, para lograr mejorar nuestra productividad y hacernos mas predecibles.
En ese aspecto, tenemos mucho para mejorar, donde los builds nocturnos son un paso importante pero no pueden ser el ultimo.
Deberiamos contar con herramientas para
* Medir impacto de cambios de atributos (que objetos se veran afectados)
* Medir impacto de cambios de propiedades
* Saber que debemos testear luego de un cambio
Check List a realizar antes de desarrollar una nueva aplicacion Genexus
Esto pretende ser una guía de ayuda para los momentos en que debemos desarrollar un nuevo modulo o hacerle un cambio importante a un sistema.
No es algo completo, y debería ser adaptable y cambiable para las diferentes realidades. Simplemente pretende ser un refresca-memoria de tal forma de no olvidarnos de cosas obvias.
Cual es el objetivos de este desarrollo?
Explicar en un parrafo, que es lo que se quiere hacer y que beneficio se quiere lograr con el cambio.
Quienes son los usuarios de la aplicación?.
Usuarios directos
Personas que Controlan
Usuarios que manejan Errores y Excepciones
Areas
- Operativa
- Data Warehouse
- Consultas Gerenciales
- Consultas de Control
- Consultas Operativas
- Datos Básicos
- Instalación
- Auditoria/Seguimiento/Log
- Seguridad
En que plataformas va a funcionar? - WIN
- WEB
- WEBServices
- Mensajeria
- WAP
- Pocket PC
- Telefonos
- Word
- Excel
- Report Viewer
- Archivos
- Mensajes
- SMS
- XML
- TXT
- OpenOffice
Preguntas a hacerse
Que pasa si falla?
A quien se avisa?
Como se avisa? Como se notifica a alguien?.
Hay plan de contingencia?
Tiene restricciones especiales de performance?
Tiene restricciones especiales de escalabilidad?
Se prevén problemas de lockeos?.
En que generador lo haremos?
Tiene algún proceso/tecnología nueva que pueda causarnos problemas?.
No hay algún otro desarrollo parecido? En GxOpen?
Revisar diseño de la base de datos con los DBA
Subtipos
Índices
Nuevas tablas
Nuevos atributos
Revisar tablas a Cachear
Revisar arquitectura de la solución con el encargado del sistema.
Como se instala?
Reorganización / Base de Datos
Documentación
Capacitacion
Requisitos adicionales.
Se necesita algun otro software?
Se necesita hardware especial?
Datos Basicos? Metadatos?
Prueba de la aplicación
Como se prueba la funcionalidad basica? Escribir un documento donde diga como se prueba lo que se esta programando. Este documento, debe ser un documento WORD donde diga que es lo que la aplicación debe hacer y como lo hace de forma que alguien que no conozca la aplicación pueda testearla.
Como se prueba los requisitos funcionales?
Hay pruebas automatizables?
No comments:
Post a Comment