soft enlatado

Pablo.

Hay algunas variables que debes tomar en cuenta a la hora de hacer un
software enlatado o que cubra las necesidades de muchas otras empresas a
parte de la que usa el programa actualmente.

Siempre se debe tomar en cuenta los procedimientos específicos y
generalizados para poder crear rutinas flexibles y de amplio espectro.

Una de las particularidades es que estas aplicaciones deben ser un poco mas
adaptables a las necesidades propias de cada empresa y eso tambien tiene que
ver con la apariencia, los niveles jerárquicos de acceso a los datos, la
presentación y un sin número de cosas.

Pero como tu eres el programador, pues rediseña para que puedes adaptar de
cada empresa su apariencia, nombre y dar posibilidad de adaptar la
personalidad de la aplicación a las necesidades de los usuarios finales
promedio.

Tambien tendrías que ver que posibilidades tienes que tu aplicación pueda
pasar o no las fronteras de tu país y alli debes tener cuidiado inclusive
entre los diferentes idiomas

En todo caso tu mensaje no ha sido muy específico en clarificar que tipo de
aplicación es, porque evidentemente habrán aplicaciones mucho mas genéricas
que otras.

No es lo mismo que te refieras a una aplicación de
Inventario-Facturación-Ventas a que estes hablando de un sistema para Medir
Cortes de Tuberia de Gas. ¿Notas la diferencia?

Si eres mas específico seguro se te puede ayudar mejor.

Saludos.


'//RadioMan
Asdrubal Velasquez
RadioMan(ARROBA)cantv.net
Puerto Ordaz - Venezuela

Estoy de acuerdo con lo que dice Asdrubal. Sin embargo yo añadiría que no
seria muy bueno apra tu desarrollo querer "adaptar" una aplicación
personalizada a una general, corres el riezgo de perderte en el camino y que
al final obtengas un producto malo.

Personalmente te recomendaria que en base a la experiencia que se tiene con
esa aplicacion, re-hagas el análisis y empezaras la programación de cero,
para que entonces puedas tomar en cuenta todo lo que el programa original no
tomo.

Pero bueno, es solo una opinion.

Saludos.
Edgar Contreras


(Guía de netiquette del foro)
http://perso.wanadoo.es/rubenvigon/foro

"La informacion es presentada como es y sin garantia alguna"



"Pablo" wrote in message
news:087901c355c6$7e262320$

Hola: Tengo una aplicacion multiusuario que trabaja con
VB6 y access2000. Funciona todo bien, pero esta hecha muy
personalizada, o sea esta adaptada a las necesidades de
una empresa. Como puedo hacer para ir modificandola y
llegar a atebner una aplicacion enlatada, que se pueda
utilizar en cualquier empresa. Donde puedo obtener
informacion de como hacer un soft enlatado?. Gracias

Impresionante. Una vez más, vuelvo a quitarme el sombrero, maestro Azpurua

Un saludo!

Rubén Vigón
Microsoft MVP Visual Basic

(Guía de buen uso del foro)
http://perso.wanadoo.es/rubenvigon/foro

Hola Leonardo:

¿Chamo que vaina es esa que escribiste?

[...]
A veces me aterro pensando que tal vez en algun lugar hay un muchachito
escribiendo "la aplicación definitiva" que me va a condenar definitivamente
a mi anhelado futuro de taxista. Podrías ser tu (con las debidas excusas por
lo de "muchachito"), y mírame, tratando de darte consejos
[...]

¿Que pasó?, ¿te volviste loco???!!!!

;-)

Saludos


'//RadioMan
Asdrubal Velasquez
Puerto Ordaz - Venezuela

Esto está tan bueno como el OT de los viernes JIJIJI
Saludos
Pablo Muñoz
Quito-Ecuador



"Leonardo Azpurua" <l a z p u r u a g (arroba) c a n t v (punto) n e t>
escribió en el mensaje news:

"Pablo" escribió en el mensaje
news:087901c355c6$7e262320$
> Hola: Tengo una aplicacion multiusuario que trabaja con
> VB6 y access2000. Funciona todo bien, pero esta hecha muy
> personalizada, o sea esta adaptada a las necesidades de
> una empresa. Como puedo hacer para ir modificandola y
> llegar a atebner una aplicacion enlatada, que se pueda
> utilizar en cualquier empresa. Donde puedo obtener
> informacion de como hacer un soft enlatado?. Gracias


Hola, Pablo.

No eres tu el mismo de la aplicación casera desarrollada con una copia
pirata? Al final como que no era ni tan casera, no?

He dedicado mis últimos 17 años (cuando comencé tenía el pelo castaño y
abundante, y aun me bañaba a diario) a intentar eso de escribir una
"aplicación enlatada que se pueda usar en cualquier empresa".

Afortunadamente, no existe semejante cosa (si existiera, ya alguien en el
Norte la habría enlatado, habría hecho algun negocio con nuestros

políticos

y la tendríamos como estándar obligatorio con fuerza de Ley. Y nosotros,

en

vez de desarrolladores seríamos, con suerte, "Authorized Resellers").

Cada empresa tiene sus particularidades. Y casi ninguna empresa, en cuanto
usuarios, tiene la capacidad o el interés de adaptar las aplicaciones a

sus

necesidades individuales. Gracias a eso se come en mi casa.

Como principio general, debes diseñar tu aplicación en capas. Las capas no
son necesariamente aquella tontería dogmática de presentación-políticas de
negocio-acceso a datos que causaron furor en las mentes simples hace diez
años (aunque ese modelito no es una mala simplificación). Un enfoque más
efectivo de las "capas" es concebir los objetos como un núcleo inmutable
sobre el cual se pueden agregar componentes accesorios, en niveles que
pueden clasificarse como "de dominio" (comunes a todo un tipo de

empresas),

de "aplicación" (comunes de un tipo de aplicación, dentro del tipo de
empresa) y "de usuario", específicos de un usuario en particular. Luego

hay

que respetar ciertas normas, como no tomar decisiones sobre el negocio en
las formas, por ejemplo (las formas son muy reciclables, tambien). El
principio de oro es mantener cada componente al tanto de lo mínimo

necesario

para que pueda funcionar sin parecer imbécil.

Considera, por ejemplo, un mercado y una clínica. El mercado vende
productos. La clínica vende servicios. El mercado estará interesado en
controlar su inventario de mercancías (sin perjuicio de que quiera

controlar

tambien otros tipos de inventario, como pudieran ser los de materiales de
oficina o limpieza para consumo interno, activos fijos, etcétera). La
clínica, probalemente, tambien tenga inventarios de alta movilidad

(insumos

quirúrgicos, medicinas, materiales de laboratorio). Pero el inventario de

la

clínica no se mueve a consecuencia de las ventas en una relación simple

(si

vendo una lata de quinchonchos, sale del inventario una lata de
quinchonchos; si, por el contrario, realizo una operación de vesícula, y
gasto tantos mililitros de porquería para dormir al cerdo, tantas cajas de
gasa, tantas jeringas desechables, sedantes, analgésicos, etcétera, en una
relación que puede variar en función del tamaño del cerdo, del grado de
podredumbre de la vesícula y de sus organos vecinos y de la torpeza o
habilidad del carnicero encargado de procesar el fiambre). Tanto la
operación de vesícula (de la cual me voy librando por la Gracia de Dios)
como la lata de quinchonchos son cosas que se venden: tienen un precio,

una

categoría fiscal, un régimen de promociones (por ejemplo, compre dos y

lleve

tres, u opérese la vesícula y deje de paso el apéndice, todo por el mismo
precio, o aproveche la anestesia: sáquese la vesícula y colóquese un par

de

tetas capaces de hacer morir de la envidia a Yuyito).

Total, que tienes una clase genérica: Producto (quinchonchos, operaciones,
tetas), y tienes otra clase genérica: ArticuloInventario (quinchonchos,
gasas, anestesicos, tetas de silicona). Si tus artículos de inventario se
conciben para ser vendidos, tendrás problemas al adaptar tu aplicación

para

una clínica.

En el dominio del mercado (Empresas Comerciales) tienes una clase:
Mercancia, que se compone de la agregación de un artículo de inventario y

de

una definición de producto. La manera de mover y de controlar el

inventario

en un mercado es diferente de la que se utilizaría en una clínica

(Empresas

de Servicios). Pero la esencia es la misma. Si en vez de un mercado, la
empresa se dedicara al corretaje de repuestos de aviación de segunda mano,
los artículos de inventario se complicarían tremendamente, pero se
resolvería añadiendo funcionalidad al núcleo (herencia).

Entonces, lo primero que hay que hacer es analizar lo que ya tienes, y
separar lo esencial de lo accesorio. Crear un núcleo de aplicación

esencial,

teniendo en mente que lo que estás construyendo no es una aplicación, sino
un esqueleto de aplicación, una especie de marco de desarrollo para las
aplicaciones reales.

Ray Bradbury decía que el trabajo del escritor consiste en vomitar por la
mañana y limpiar por las tardes, refiriéndose a su rutina, que consistía

en

darle rienda suelta a las ideas y las palabras en las primeras horas del
día, cuando su imaginación estaba más activa, y luego dedicar las horas de
la tarde a pulir las parrafadas de la mañana, a criticarlas y organizarlas
en aquellos extraordinarios cuentos y novelas. Con nosotros pasa algo
parecido, sólo que tardamos demasiado en vomitar y luego le tenemos un

poco

de asco a la limpieza.

A veces me aterro pensando que tal vez en algun lugar hay un muchachito
escribiendo "la aplicación definitiva" que me va a condenar

definitivamente

a mi anhelado futuro de taxista. Podrías ser tu (con las debidas excusas

por

lo de "muchachito"), y mírame, tratando de darte consejos

Salud!

Leonardo
[MS MVP - VB]