Meditaciones sobre metodologías de desarrollo

Nuestros amigos de JavaHispano han elaborado un documento con algunas meditaciones muy interesantes sobre metodologías de desarrollo.

Os lo recomiendo.

El enlace es http://www.javahispano.org/portada/2013/2/19/niveles-de-calidad-el-agujero-en-las-metodologias-de-softwar.html

Espero que os guste

Como generar un producto a partir de un proyecto

En muchas ocasiones, un proyecto se puede usar para dar solución a otro proyecto (es mas, es la forma ideal ya que te ahorras la parte de demostrar que la solución tiene salida comercial). Por ejemplo, una pagina web de venta de coches; el responsable de ventas puede ver la pagina y decir que las funcionalidades son fáciles de usar y son muy genéricas por lo que podría ser la solución para otro cliente (es decir, otro proyecto) con algunos cambios claro. Cuando un proyecto es “igual” que otro pero cambiando “algo” es que el primer proyecto se puede convertir en un producto y la elaboración del segundo proyecto debe enfocarse como la transformación del primer proyecto en un producto configurable.

¿Como se puede saber que se ha conseguido elaborar un producto configurable? Cuando al aplicar una configuración tienes el primer proyecto y cuando aplicas otra configuración tienes el segundo proyecto.

Ojo, esto es muy importante si el objetivo es obtener un producto porque como el segundo proyecto digas:

Bueno lo del producto con el tiempo. Ahora cojo el primer proyecto, lo rehago partiendo de códigos, configuraciones, ficheros, etc… y termino “RAPIDO” este segundo proyecto..

Es muerte para el producto.

Esto es lo que suele pasar. Merece la pena sacar un producto bueno que ir “recauchutando” proyectos y llamarlo producto.

El problema de la documentacion

Cuando se esta desarrollando un proyecto aparece la informácion mas importante de todas: como se ha afrontado un problema, detalles sobre tareas especificas (por ejemplo, este expediente es valido si es de tipo A y B y la fecha de expiracion es menor que la fecha actual + el parametro ... a que te suena?), etc.. Esta informacion es la mas importante pero no queda reflejada en ningun sitio ya que, en la inmensa mayoria de los casos, no queda reflejada en ningun sitio. Solo queda reflejado en el "conocimiento popular" de los miembros del proyecto que estan todo el dia con el desarrollo. Esto plantea una serie de problemas:

• No hay axima fijo para todos. La informacion queda recogida por cada miembro del equipo y su libre interpretacion por lo que al final tenemos varias verdades muy parecidas sobre el mismo asunto.
• Si un miembro del equipo se va entonces la informacion se pierde.
• Con el tiempo las cosas se olvidan y se degrada la informacion.

¿Entonces la solucion seria dejar reflejada la informacion en documentos? Esta seria la opción mas logica pero tambien plantea una serie de problemas de peso:

• El sistema de informacion varia de forma y de tamaño con mucha rapido por lo que mantener actualizada la documentacion resulta dificil. Y no solo el problema es mantenerlo "rapido" es que encima todos los miembros del equipo tendrian que volver a leerlo TODO "rapido" y con mucha frecuencia.
• Es una tarea dificil documentar ya que hay que expresarse de una manera que no sea demasiado tediosa (ya que si no el lector se cansara de leer) y que no sea demasiado abreviada (ya que si no el lector no se enterara).

Al final, la opcion que se toma es ¿Por que documentar si le puedo preguntar a alguien o lo puedo mirar en el codigo?

Drag and Drop en JavaFX 2.0

Hola

Os pongo un enlace donde hay un ejemplo de como implementar el drag and drop.

http://blog.ngopal.com.np/2011/06/09/draggable-node-in-javafx-2-0/

Un saludo

Sistema de log

Cuando se esta desarrollando una aplicación a menudo se comente el fallo de tomarse en serio el log cuando la aplicación esta muy avanzada. El log hay que usarlo desde el principio y siempre hay que estar seguro que se esta generando como se desea.

Hay que establecer una política de mensajes de tal manera que muestre información util para los desarrolladores. Esto es importante ya que no hay que confundir un log con un sistema de auditoria. Los sistemas de auditoria muestran las operaciones que se han realizado, con que datos y como han acabado y un log recoge información util para el equipo tecnico que indican datos sobre la implementacion, el estado de la aplicación, fallos, etc... Es decir, la auditoria esta orientado a negocio y el log al técnico.

Un error a eliminar del log es el sintoma del fallo ciclico. Estos log se corresponden a procesos automáticos (no requieren interaccion del usuario como pulsar un boton, etc..)  y que informan de un hecho (ya sea fallo o que ha podido realizar la tarea).

Por ejemplo, un proceso automatico que intenta conectar con una IP para enviarle un fichero xml y lo hace cada 5 segundos.

Si acierta el log dice :

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - Fichero 00222AC.xml enviado a 127.0.0.1


Si falla dice log dice :

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a ....

Y uno de estas dos pares lineas se escribe el log cada 5 segundos. Al final se tiene

[TareaEnviaXML] - Tarea funcionando....

[TareaEnviaXML] - Tratando de enviar el fichero 70222AC.xml
[TareaEnviaXML] - Fichero 70222AC.xml enviado a 127.0.0.1


[TareaEnviaXML] - Tratando de enviar el fichero 10222AC.xml
[TareaEnviaXML] - Fichero 10222AC.xml enviado a 127.0.0.1

[TareaEnviaXML] - Tratando de enviar el fichero 20222AC.xml

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X

[TareaEnviaXML] - Fichero 20222AC.xml enviado a 127.0.0.1
[TareaEnviaXML] - Tratando de enviar el fichero 30222AC.xml
[TareaEnviaXML] - Fichero 30222AC.xml enviado a 127.0.0.1

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X
...........
Asi el log se hará enorme y realmente no aporta tanta información,  es decir si el proceso ha cumplido con el fichero 70222AC.xml en realidad no necesito saberlo en el log. Si fallo para el fichero 00222AC.xml entonces si, pero si luego falla por lo mismo en realidad tampoco necesito ver el log para saberlo, lo que realmente se necesita es ver cuando a funcionando o si ha fallado por otra cosa. Por lo que el log quedaria:

[TareaEnviaXML] - Tarea funcionando....

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X

[TareaEnviaXML] - Tratando de enviar el fichero  00222AC .xml
[TareaEnviaXML] - Fichero  00222AC .xml enviado a 127.0.0.1

y ya esta. O:




[TareaEnviaXML] - Tarea funcionando....

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a Y

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X



[TareaEnviaXML] - Tratando de enviar el fichero  00222AC .xml
[TareaEnviaXML] - Fichero  00222AC .xml enviado a 127.0.0.1

Esto representa un log mas pequeño que muestra la misma informacion.

Software parts dependency research(I)

When the develop team is in design phase have to think a lot of thing but there are two concepts that are the most important concepts. In addition, it is a good beginning for the design approach starting think in these concepts.

These concepts are:

•          Which are the parts of software?
•           How coupled are these parts?

Think about that… step by step

Which is the correct way to split the software up into parts? The software splitting can not be a mechanical process because the main factor is the information system that have to be solved by the software and this information system is fully subjective, that is to say:

•     The costumer have to explain it.
•          The  develop team have to understand.
•           The initial approaching, based on costumer/develop team interviews, will change when the software developing have skill that can be review, analyze, etc. In that moment, the fight will begin. Sure.  It will be because the costumer will say:”I don’t want this, this have to be in this way”. The develop team will say:” You said you want this”.  The costumer say:”you didn’t get it, I wanted this”… Do you know the song???   

I show you the “Box split” method for splitting information system up into parts that can be used like parts of the software. The purpose is the split information system process can set the base for development.

1º Step. Information capture process: Like all good development, the information system have to be understood by the team members. Advice: when the developers talk about their work (the software) usually use a technical words that  must not be understood by the  customer. It happened to costumer too. They usually use the their language for telling us that they want. This is good because if they use the their language then the develop team can suppose how the software interface have to be but warning because the customer explanation can be only good for interface. The business logic have to be a deal between the develop team and the customer said in a technical words. Never let the costumer explain the business logic in their language.

El no empezar de cero

Cuando se empieza el desarrollo de una aplicación se puede diseñar la aplicación, se pueden hacer pruebas de concepto (utilizo este framework?, esta tecnología?, etc..), etc… Todo parece maravilloso. YA SE LIARA DESPUES.

Pero en el mundo empresarial lo mas normal es que o que te incorpores a un proyecto ya empezado o que se te obligue a partir de un proyecto ya existente. Esto unido al hecho de que al no conocer el negocio tan bien como la gente que ya estaba en el proyecto hace que si quieres hacer algo mejor, aplicar alguna nueva tecnología, crear un marco de trabajo, etc… Digas cosas como: “Es que no me dejan” , “Ya esta tan mal que no lo puedo cambiar”, “En el próximo proyecto…”    TE SUENA ¿verdad?

Es cierto que si el proyecto se empezara de cero se podrían hacer las cosas de otra manera pero eso no va a pasar por dos motivos principalmente:

-          No se puede asumir el coste (da igual el proyecto, imposible que exista un proyecto que asuma el coste de que lo desarrollado hasta el momento no valga)

-          ¿Quién te dice que lo nuevo que vas a introducir es mejor que lo que ya había? (ojo con esto y no te confies por muy bueno que te parezca lo que quieres poner  que demostrar la mejora de algo a nivel de diseño o explicándolo es muy complicado).

Tienes dos opciones:

-          No propones nada para el proyecto actual pero aprovechas el proyecto actual para conocer el negocio y proponer algo para el siguiente.

-          Cuando tengas claro lo que quieres proponer entonces lo haces para las nuevas tareas que vayan surgiendo. De esto se deduce que TIENE QUE SER COMPATIBLE CON LO QUE YA EXISTE (1).

(1)    El hacer compatible lo que quieres proponer para tu proyecto seguro que limitara la potencia que lo que pretendes pero es la forma de que tus superiores acepten tu propuesta.