jun 25

Uno para todos y todos para uno

Posted in analisis, aplicaciones, foro

Al hilo de los ultimos comentarios realizados por nuestro amigo del foro, Luis Palomo “Overall” y basandome en mi corta experiencia con V7, he decidido volver a la carga con una nueva critica, y alla cada cual con las conclusiones que quiera sacar de ella, pero creo que la unica conclusión valida a lo que voy a exponer es: “mejorar lo que tenemos para evitar los problemas que aqui se plantean”.

El hilo al que me refiero en concreto es este:

Copiar una solucion de Overall

Y como yo mismo comente en este hilo, hay existe un problema al copiar proyectos de una solucion a otra, y que se detalla en este articulo que escribi hace varios meses, Las malas costumbres del 7 de abril de 2010, apenas un mes y 1/2 despues de publicarse la version 7.3

Para ir concretando, el problema no surge en el instanciamiento de datos, el problema no lo tiene el cliente final que desarrolla una aplicacion personalizada para su PYME, el problema real, lo tenemos los desarrolladores que nos dedicamos exclusivamente a la programación y vamos a tener multiples aplicaciones, todas muy similares pero personalizadas para cada uno de los clientes, y ante tal planteamiento se me ocurren varias formas de afrontarlos para obtener el mejor resultado posible.

Y cual es ese resultado:

  1. Que el cliente este satisfecho con su aplicación, y el resultado tenga una relación calidad/precio optima.
  2. Que los desarrolladores trabajemos en una aplicación común y solo tengamos que realizar las personalizaciones para cada uno de ellos, abaratando asi los costes para ser competitivos.

Un ejemplo practico “y real” de todo esto, hemos desarrollado un pequeño E.R.P. basico pero lo suficientemente completo como para servir de plantilla para futuros desarrollos y este es es esquema de la solución:

ERP basico

Fijaos en el circulo rojo, que hemos marcado claramente el proyecto de contabilidad que es el único que nos interesa para este ejemplo, mas adelante veremos porque.

Paralelamente, en otro departamento, estamos desarrollando otra aplicación para corredurias de seguros,

Corredurias de seguros

Y aunque no será el último, para este ejemplo lo vamos a dejar aqui, tambien hemos desarrollado una gestión para cristalerías, y algunos modulos adicionales como Flota, etc.

Gestion de cristalerias y flota

Con todo esto, ya tenemos los ingredientes para nuestro guiso, y hasta ahora lo que eran 3 soluciones independientes, se convierte en un problema que debemos solucionar, ¿cual?

Nuesto cliente, “corredor de seguros” quiere tener instalada la contabilidad, y por supuesto nuestro cliente “cristalero” tambien, ya que una vez desarrollada, el coste no es elevado y deciden que es una buena opción.

Hasta ahora, no se ha planteado nada raro, creo yo, es mas, es nuestro caso real y es nuestro problema actual.

Segun lo que se plantea en el foro, y el articulo escrito por mi mismo anteriormente al que se hacia referencia tenemos varias soluciones posibles:

  1. Si seguimos el articulo Las malas costumbres al pie de la letra, bastaria con copiar los poyectos de Contabilidad y sus heredados a la nueva solución, y tendriamos la contabilidad en los 3 proyectos, repetida, pero seguirian siendo pequeños proyectos, con un problema añadido, si realizamos modificaciones en Contabilidad, hay que copiar nuevamente los proyectos y por tanto surgen posibilidad de errores, o realizar las modificaciones 3 veces. ¡Hemos decidido que esta no es la solucion al problema que se plantea!
  2. Si seguimos el consejo de FGutierrez en el hilo de Overall, en el que nos aconseja no copiar los proyectos para no tener ducplicados, solo nos queda una solución, heredar la conta desde los proyectos de Corredurias de seguros, y desde Cristalerias. ¡Esta es una buena solución! y este seria el resultado:

Multiples aplicaciones

Y aqui vemos como el resultado de heredar la contabilidad por las nuevas aplicaciones, convierte nuestros 3 pequeños proyectos en un macro proyecto que seguira creciendo a medida que vayamos incorporando mas funcionalidad.

Como he dicho anteriormente, no me preocupa el resultado de la instalacion en el cliente, no es el tema que nos ocupa en este momento, ya que el instalador se encargara de usar los proyectos que sean necesarios para la instalación.

La intencion de este articulo, vuelvo a repetir, es plantear los problemas que tendremos los desarrolladores ante esta situación, y es que, aunque la solucion de FGutierrez es totalmente validad y la mas correcta, ahora nos surge otro problema añadido, del que tambien he publicado otro articulo hacetan solo un par de semanas, el 6 de junio de 2010, llamado Mejoras en el rendimiento, que nos plantea el problema de redimiento de vDevelop y los refrescos cuando la solución empieza a crecer con multiples proyectos.

Este ejemplo es muy relativo, si tenemos en cuenta que solo he utilizado 3 de los desarrollos que actualmente estamos preparando para nuestros clientes, pero no quiero olvidar y espero que asi se repita, con Velazquez Visual, realizamos más de 80 instalaciones personalizadas en tan solo 4 años, y si con 3 aplicaciones ya tenemos un pequeño problema de rendimiento, como será cuando lleguemos a 15 o 20 aplicaciones…

y ahora, ¿Cual es la solución?

Create PDF    Enviar artculo en formato PDF   
comments: Comentarios desactivados en Uno para todos y todos para uno