lunes, 31 de diciembre de 2018

Un nuevo Tao para el software

cap.1 Si quieres algo que no existe , tendrás que hacerlo

Si quieres algo que no existe , tendrás que hacerlo
y si no hay nada parecido ,tendrás que investigar cual es el problema que hay que solucionar .

Cada uno elije sus batallas , las mías son los problemas de producción y la administración de sistemas de producción. Entonces el dominio esta bastante claro ... ahora que se requiere?
Investiga , descubre , reconoce , rodea lo desconocido de conceptos conocidos , haz perceptibles los diferentes requisitos!

En estas "batallas" debes salir airoso , debes poder formalizar los requisitos
Entonces estarás listo para un diseño







Conoce a fondo un lenguaje de computación para poder construir esa maquina de soft que te quita el sueño

deberás probar que hiciste algo que sirve. PERO ... debe servir para la solución que eljiste !
Luego llegara el alivio de que tu/s maquinas estén en los dedos de los usuarios , lista/s para funcionar
Grrr. ahora hay que conseguir que se use! , el usuario deberá instituirla como parte de su trabajo
y las maquinas que hiciste ... silenciosa,mente empezaran a llenar el mundo de sus esperados servicios.
Así haremos un mundo mejor

PERO ... el mundo cambia y eso hace que nuestras maquinas deban cambiar
Estarás de cabeza en el viejo garage del mantenimiento
Y finalmente , una vez muy muy lejos , tus maquinas sera sacadas de servicio.
El ciclo se habrá cumplido
Y nosotros estaremos felices de haber colaborado a mejorar la vida de los que se animaron a nuestras maquinitas de soft. Seguro aportamos un granito de arena a la evolucion.
OH y entonces .... que nos ayudara a que todo eso suceda de una forma controlada eficaz , efectiva y eficiente... ?
Dicho brutalmente (como o ya lo dijo antes un tango) : Es la INGENIERÍA  gilito embanderado ! (chan , chan!)

lunes, 12 de noviembre de 2018

Por el final de los 80 me llamo la atencion  este ensayo sobre la programacion de computadoras y su vision desdeel TAO
Hoy diria que: cuando una rama del saber humano todavia no tienen ciencia , recurre a los mitos   y leyendas. Ademas como no hay ciencia para explicar lo que sucede ... proporcionan metaforas para transmitir lo que no se entiende.
En esos años miticos de la programacion , este articulo era COOL , hacia furor... con ironias todavia irreemplazables.

El Tao de la Programación
por Geoffrey James
LIBRO PRIMERO: EL VACÍO SILENCIOSO
Así habló el maestro programador:
“Cuando hayas aprendido a extraer el código del error desde un trap frame,
será la hora de marcharte”
1.1
Algo misterioso se forma, nace en el vacío silencioso. Esperando solo e inmóvil, al mismo tiempo detenido y en movimiento constante. Es la fuente de todos los programas. Yo no sé su nombre, así que lo llamaré el Tao de la Programación.

Si el Tao es grandioso, entonces el sistema operativo es grandioso. Si el sistema operativo es grandioso, entonces el compilador es grandioso. Si el compilador es grandioso, entonces la aplicación es grandiosa. El usuario está complacido y hay armonía en el mundo.

El Tao de la Programación fluye lejos y regresa con el viento de la mañana.
1.2
El Tao engendró al lenguaje máquina. El lenguaje máquina dio vida al ensamblador. El ensamblador se la dio al compilador. Ahora hay diez mil lenguajes.

Cada lenguaje tiene su propósito, aunque sea humilde. Cada lenguaje expresa el Yin y el Yang del software. Cada lenguaje tiene su lugar dentro del Tao.

Pero no programes en COBOL si puedes evitarlo.
1.3
En el principio era el Tao. El Tao engendró el Espacio y Tiempo. Por tanto Espacio y Tiempo son el Yin y el Yang de la programación.

Los programadores que no comprenden el Tao siempre siempre se quedan sin tiempo y espacio para sus programas. Los programadores que comprenden el Tao siempre tienen tiempo y espacio suficiente para lograr sus objetivos.

¿Cómo podría ser de otra manera?
1.4
Al programador sabio le hablan del Tao y lo sigue. Al programador medio le hablan del Tao y lo busca. El programador necio se ríe cuando le hablan del Tao.

Si no fuera por la risa, no existiría el Tao.
Los sonidos más altos son los más difíciles de oír.
Avanzar es un camino para la retirada.
El gran talento se muestra tarde en la vida.
Incluso un programa perfecto todavía tiene errores.
LIBRO SEGUNDO: LOS MAESTROS ANCIANOS
Así habló el maestro programador:
“Después de tres días sin programar, la vida pierde sentido”
2.1
Los programadores de la antigüedad eran misteriosos y profundos. No podemos comprender sus pensamientos, así que todo lo que hacemos es describir su apariencia.

Consciente, cual zorro cruzando el agua. Alerta, como un general en el campo de batalla. Amable, como una anfitriona saludando a sus invitados. Simple, como bloques de madera sin tallar. Opaco, como negras piscinas en cuevas oscuras.

¿Quién puede contar los secretos de sus corazones y mentes?

La respuesta sólo existe en el Tao.
2.2
El Gran Maestro Turing una vez soñó que era una máquina. Cuando se despertó, exclamó:

”¡No sé si soy Turing soñando que soy una máquina, o una máquina soñando que soy Turing!'”
2.3
Un programador de una gran compañía fue a una conferencia de software y luego regresó para informar a su jefe, diciendo: “¿Qué clase de programadores trabajan en otras empresas? Se comportan mal y no se preocupan por las apariencias. Su cabello era largo y despeinado y sus ropas arrugadas y viejas. Destrozaron nuestra hospitalidad e hicieron ruidos groseros durante mi presentación''.

El director dijo: “Nunca debí haberte enviado a la conferencia. Esos programadores viven más allá del mundo físico. Consideran que la vida es absurda, una coincidencia accidental. Ellos van y vienen sin conocer limitaciones. Sin cuidado, ellos viven sólo para sus programas. ¿Por qué deberían preocuparse por las convenciones sociales?

Ellos viven dentro del Tao”.
2.4
El discípulo preguntó al Maestro: “Este es un programador que nunca diseña, documenta o prueba sus programas. Sin embargo, todos los que lo conocen lo consideran uno de los mejores programadores del mundo. ¿Por qué es esto?”

El Maestro responde: “Ese programador ha alcanzado la maestría del Tao. Ha ido más allá de la necesidad de un diseño; no se enoja cuando el sistema se cae, pero acepta al universo sin preocupación. Ha ido más allá de la necesidad de documentación; no le importa si alguien más ve su código. Ha ido más allá de la necesidad de pruebas; cada uno de sus programas son perfectos en sí mismos, serenos y elegantes, su propósito es auto-evidente. Realmente, él ha penetrado en el misterio del Tao''.
LIBRO TERCERO: DISEÑO
Así habló el maestro programador:
“Cuando el programa está siendo testeado,
es demasiado tarde para hacer hacer cambios de diseño”
3.1
Hubo una vez un hombre que fue a una feria de informática. Cada día, al entrar le decía al guarda de la puerta: “soy un gran ladrón reconocido por mis hazañas de robo. Estás prevenido de que esta feria no escapará sin ser saqueada”.

Estas palabras incomodaron mucho al guardia, porque dentro había millones de dólares en equipamiento informático, así que observó cuidadosamente al hombre. sin embargo, el hombre simplemente vagaba de stand en stand, murmurando para sí.

Cuando el hombre se iba, el guardia se lo llevó aparte y buscó entre sus ropas, pero nada fue encontrado.

Al siguiente día de la feria, el hombre regresó y regañó al guardia diciendo: "Ayer escapé con un gran botín, pero hoy será todavía mejor". Así que el guardia lo observó incluso más de cerca, pero sin resultados.

En el último día de la feria, el guardia no pudo resistir más su curiosidad. "Señor Ladrón", dijo, "estoy tan confuso que no puedo vivir en paz. Por favor ilumíneme. ¿Qué es lo que está robando?"

El hombre sonrió. "Estoy robando ideas", dijo.
3.2
Había una vez un maestro programador que escribía programas no estructurados. Un programador novicio, buscando imitarlo, también comenzó a escribir programas no estructurados. Cuando el novicio le pidió al maestro que evaluara su progreso, el maestro lo criticó por escribir programas no estructurados, diciendo:

“Lo que es apropiado para el maestro no es apropiado para los principiantes. Debes entender el Tao antes de trascender la estructura”.
3.3
Hubo una vez un maestro programador en la corte del señor de Wu. El señor preguntó al programador: “¿qué es más fácil de diseñar, un paquete de contabilidad o un sistema operativo?”.

“Un sistema operativo”, respondió el programador.

El señor lanzó una exclamación de incredulidad. “Sin duda, un paquete de contabilidad es trivial al lado de la complejidad de un sistema operativo”, dijo.

“No es así”, dijo el programador, “cuando se diseña un paquete de contabilidad, el programador actúa  como mediador entre personas con distintas ideas: cómo debe operar, cómo deben aparecer sus informes, y cómo se deben cumplir las leyes de impuestos". Por el contrario, un sistema operativo no está limitado por las apariencias externas. En el diseño de un sistema operativo, el programador busca la armonía más simple entre máquina e ideas. Esta es la razón por la que el sistema operativo es más fácil de diseñar”.

El señor de Wu asintió y sonrió. “Eso está bien, pero, ¿qué es más fácil de depurar?”.

El programador no respondió.
3.4
Un gerente fue al maestro programador y le mostró el documento de requisitos para una nueva aplicación. El gerente preguntó al maestro: “¿Cuánto tiempo se tarda en diseñar este sistema si le asigno cinco programadores?”.

“Tomará un año”, dijo el maestro rápidamente.

“¡Pero necesitamos este sistema inmediatamente o incluso antes! ¿Cuánto se tarda si le asigno diez programadores?”.

El maestro programador frunció el ceño. “En este caso, se tardará dos años”.

“¿Y si le asigno cien programadores?”

El maestro programador se encogió de hombros. “Entonces el diseño no se completará jamás”, dijo.
LIBRO CUARTO: CODIFICACIÓN
Así habló el maestro programador:
“Un programa bien escrito es su propio cielo;
un programa mal escrito, su propio infierno”
4.1
Un programa debe ser ligero y ágil, sus subrutinas conectadas como las perlas de un collar. El espíritu e intencionalidad del programa debe mantenerse en todo momento. No debe ser ni mucho ni poco, ni bucles innecesarios ni variables sin utilidad, ni ausencia de estructura ni rigidez excesiva.

Un programa debe seguir la “Ley de la menor sorpresa”. ¿Qué es esta Ley? Simplemente que el programa debe responder siempre de la forma que menos sorprenda al usuario.

Un programa, no importa cuán complejo sea, debería actuar como una sola unidad. El programa debe ser dirigido por la lógica interna en lugar de por las apariencias externas.

Si el programa falla en estos requisitos, se llegará a un estado de desorden y confusión. La única manera de corregir esto es reescribiendo el programa.
4.2
Un discípulo preguntó al maestro: “Tengo un programa que a veces funciona y veces aborta. He seguido las reglas de la programación, y estoy totalmente desconcertado. ¿Cuál es la razón?”.

El maestro respondió: “Estás confuso porque no entiendes el Tao. Sólo un necio espera un comportamiento racional de sus semejantes humanos. ¿Por qué ibas a esperarlo de una máquina que los humanos han construido? Los ordenadores simulan determinismo; sólo el Tao es perfecto.
Las reglas de la programación son transitorias; sólo el Tao es eterno. Por tanto, debes contemplar el Tao antes de ser iluminado.”

“Pero, ¿cómo sabré que he sido iluminado?”, preguntó el discípulo.

“Tu programa funcionará correctamente”, respondió el maestro.
4.3
Un maestro estaba explicando la naturaleza del Tao a uno de sus discípulos. “El Tao está presente en todo el software, independientemente de su insignificancia”, dijo el maestro.

“¿Está el Tao en una calculadora de bolsillo?”, preguntó el novicio.

“Está”, fue la respuesta.

“¿Está el Tao en un videojuego?”, continuó el discípulo.

“Incluso en un videojuego”, dijo el maestro.

“¿Y está en el sistema operativo de un ordenador personal?”

El maestro tosió y cambió levemente de posición. “La lección ha acabado por hoy”, dijo.
4.4
El programador del Príncipe Wang estaba codificando software. Sus dedos bailaban sobre el teclado. El programa compiló sin errores y se ejecutó cual ligera brisa.

“¡Excelente!”, exclamó el Príncipe, “¡Tu técnica es infalible!”.

“¿Técnica?”, dijo el programador girándose desde su terminal, “¡Lo que yo sigo es el Tao más allá de toda técnica! Cuando empecé a programar, veía ante mí el problema completo como un todo.

Después de tres años ya no veía ese bloque: empecé a usar subrutinas. Pero ahora no veo nada. Mi ser existe en un vacío sin forma. Mis sentidos están ociosos. Mi espíritu, libre para trabajar sin un plan, sigue su propio instinto. En resumen, mi programa se escribe a sí mismo. Es cierto que a veces hay problemas complejos. Los veo acercarse, me detengo, observo en silencio. Entonces cambio una única línea de código y las dificultades se desvanecen como una voluta de humo. Compilo mi programa. Me quedo quieto y dejo que el gozo del trabajo llene mi ser. Cierro los ojos un momento, y entonces cierro mi sesión”.

El Príncipe Wang dijo “Ojalá todos mis programadores fueran tan sabios”.
LIBRO QUINTO: MANTENIMIENTO
Así habló el maestro programador:
“Incluso un programa de tres líneas algún día tendrá que se mantenido”
5.1
Una puerta bien usada no necesita aceite en sus bisagras.
Un río que fluye veloz no se estanca.
Ni el sonido ni los pensamientos pueden viajar a través del vacío.
El software se pudre si no se utiliza.
Son grandes misterios.
5.2
Un gerente preguntó a un programador que cuánto tiempo le llevaría terminar el programa en el que trabajaba. “Se acabará mañana”, respondió rápidamente el programador.

“Creo que no estás siendo realista”, dijo el gerente, “De verdad, ¿cuánto tiempo tardará?”.

El programador pensó un instante. “Tengo algunas características que me gustaría añadirle. Me llevará al menos dos semanas”, dijo finalmente.

“Incluso eso es demasiado esperar”, insistió el gerente, “me basta si simplemente me avisas cuando el programa esté completo”.

El programador asintió.

Varios años más tarde, el gerente se retiró. De camino hacia su almuerzo de jubilación descubrió al programador dormido sobre su terminal. Había estado programando toda la noche.
5.3
Un programador novicio fue una vez asignado a la codificación de un sencillo paquete financiero.

El novicio trabajó furiosamente muchos días, pero cuando su maestro revisó su programa descubrió que contenía un editor de pantallas, un conjunto de rutinas gráficas generales, y una interfaz de inteligencia artificial, pero ni la más mínima mención de nada financiero.

Cuando el maestro le preguntó acerca de ello, el novicio se indignó. “No seas tan impaciente”, dijo, “Incluiré los temas financieros al final”.
5.4
¿Acaso un buen agricultor descuidaría un cultivo que ha plantado?
¿Acaso descuidaría un buen profesor incluso al estudiante más humilde?
¿Acaso un buen padre permitiría que uno de sus hijos murieran de hambre?
¿Acaso un buen programador rechazaría mantener su propio código?
LIBRO SEXTO: GESTIÓN
Así habló el maestro programador:
“Sean los programadores muchos y gestores pocos;
todos ellos serán entonces productivos”
6.1
Cuando los gestores tienen reuniones infinitas, los programadores escriben juegos. Cuando los financieros hablan de beneficios cuatrimestrales, el presupuesto de desarrollo está a punto de ser recortado. Cuando los científicos hablan de cielo azul, las nubes están a punto de aparecer.

Ciertamente, esto no es el Tao de la Programación.

Cuando los gestores de comprometen, los juegos son ignorados. Cuando los financieros hacen planes a largo plazo, la armonía y el orden son restaurados. Cuando los científicos se centran en los problemas cercanos, los problemas estarán a punto de resolverse.

Ciertamente, esto es el Tao de la Programación.
6.2
¿Por qué los programadores son improductivos?
Porque pierden su tiempo en reuniones.

¿Por qué los programadores son rebeldes?
Porque la gestión interfiere mucho.

¿Por qué los programadores reniegan unos de otros?
Porque están quemados.

Después de haber trabajado para un mal gestor, ya no valoran sus empleos.
6.3
Un gerente estaba a punto de ser despedido, pero un programador que trabajaba para él inventó un nuevo programa que se hizo popular y se vendió bien. Como consecuencia, el gerente conservó su empleo.

El gerente intentó darle al programador una bonificación, pero éste se negó diciendo “yo escribí el programa porque pensé que era un concepto interesante, por lo que no espero ninguna recompensa”.

Al oír esto, el gerente comentó: “Este programador, a pesar de su baja autoestima, entiende bien los deberes de un empleado. ¡Vamos a promocionarlo hacia la posición de consultor de gestión!”.

Pero cuando se le dijo esto, el programador lo rechazó una vez más diciendo: “Vivo para la programación. Si fuera ascendido no haría más que desperdiciar el tiempo de todos. ¿Me puedo ir? Tengo un programa en el que trabajar”.
6.4
Un gerente se dirigió a sus programadores: “En cuanto a sus horas de trabajo, van a tener que venir desde las nueve de la mañana hasta las cinco de la tarde”. En ese momento todos se enfadaron y muchos de ellos renunciaron en el acto.

Así que el gerente dijo: “Bien, pues en ese caso podéis establecer vuestros propios horarios de trabajo, siempre que terminéis los proyectos a tiempo”. Los programadores, ahora satisfechos, comenzaron a llegar a mediodía y trabajar hasta altas horas de la madrugada.
LIBRO SÉPTIMO: CONOCIMIENTO CORPORATIVO
Así habló el maestro programador:
“Puedes mostrar un programa a un ejecutivo de la empresa,
pero no puedes hacerlo experto en informática”
7.1
Un discípulo preguntó al maestro: “En el Este hay una gran estructura con forma de árbol que los hombres llaman sede corporativa. Está excesivamente inflada con vicepresidentes y contables. Generan una gran cantidad de notas diciendo ‘ve aquí’ o ‘ve allá’ y nadie sabe lo que significa. Cada año se colocan nuevos nombres en las ramas, todo en vano. ¿Cómo puede existir una entidad tan innatural?”.

El maestro respondió: “Percibes esta inmensa estructura y te perturba que no tenga un propósito racional. ¿No puedes encontrar entretenimiento con sus giros sin fin? ¿No disfrutas de la facilidad de programar sin problemas refugiado bajo sus ramas? ¿Por qué te molesta su inutilidad?”.
7.2
En el Este hay un tiburón que es mayor que todos los otros peces. Se transforma en ave cuyas alas son como nubes llenando el cielo. Cuando es ave, se mueve por toda la tierra y trae un mensaje desde la sede corporativa. Este mensaje cae entre los programadores como una gaviota dejando su huella en la playa. Entonces el pájaro remonta el vuelo y, con el cielo azul a sus espaldas, vuelve a casa.

El programador novicio mira sorprendido el ave porque no lo entiende. El programador intermedio teme la llegada del ave porque teme su mensaje. El maestro programador continúa trabajando en su terminal, no sabe que el ave ha llegado y se ha marchado.
7.3
El Mago de la Torre de Marfil llevó su último invento para que lo examinara el maestro programador. El Mago acarreó una gran caja negra a la oficina del maestro, mientras éste esperaba en silencio.

“Esto es una estación de trabajo de propósito general integrada y distribuida”, comenzó el Mago, “diseñada ergonómicamente con un sistema operativo propietario, lenguajes de sexta generación y múltiples interfaces de usuario de tecnología punta. Construirlo costó a mis asistentes varios cientos de años/hombre . ¿No es sorprendente?”.

El maestro alzó sus cejas ligeramente. “Sin duda es increíble”, dijo.

“La sede corporativa ha ordenado”, continuó el Mago, “que todos usen esta estación de trabajo como plataforma para los nuevos programas. ¿Está de acuerdo con esto?” .

“Ciertamente”, respondió el maestro, “Lo transportaré al centro de datos inmediatamente”. Y el Mago retornó complacido a su torre.

Varios días después, un novicio vagaba por la oficina del maestro programador y le dijo: “No puedo encontrar el listado de mi nuevo programa. ¿Sabes dónde puede estar?”.

“Sí”, respondió el maestro, “los listados están apilados sobre la plataforma del centro de datos”.
7.4
El maestro programador se mueve de un programa a otro sin miedo. Ningún cambio en los gestores puede dañarle. No será despedido, ni siquiera aunque el proyecto en el que trabaja sea cancelado. ¿Por qué es esto?

El Tao está en él.
LIBRO OCTAVO: HARDWARE Y SOFTWARE
Así habló el maestro programador:
“Sin el viento, el pasto no se mueve. 
Sin software, el hardware es inútil”
8.1
Un discípulo preguntó al maestro: “Percibo que una compañía de ordenadores es mucho mayor que todas las demás. Se eleva por encima de su competencia como un gigante entre enanos. Cualquiera de sus divisiones podría abarcar todo el negocio. ¿Por qué es esto así?”.

El maestro respondió: “¿Por qué haces preguntas tan necias? Esa compañía es así de grande porque es grande. Si sólo fabricara hardware nadie lo compraría. Si sólo hiciera software, nadie lo usaría. Si sólo mantuviera sistemas, la gente los trataría como a sirvientes. Pero al combinar todas esas cosas, la gente piensa que son dioses. Al no buscar la confrontación conquista sin esfuerzo”.
8.2
Un maestro programador pasó un día junto a un novicio. El maestro notó la preocupación del novicio con un juego en un dispositivo portátil. “Disculpe”, dijo, “¿me permite examinarlo?”.

El novicio atendió y pasó el dispositivo al maestro. “Veo que el aparato afirma tener tres niveles de juego: fácil, intermedio y difícil”, dijo el maestro. “Pero aún cada dispositivo tiene otro nivel de juego, donde el apartado no busca conquistar al humano, ni ser conquistado por el humano”.

“Ruego, gran maestro”, imploró el novicio, “¿cómo hace uno para encontrar esa misteriosa configuración?”.

El maestro arrojó el dispositivo al suelo y lo aplastó bajo su pie. Y de pronto, el novicio fue iluminado.
8.3
Había una vez un programador que trabajaba con microordenadores. “Mira lo bien que estoy aquí”, dijo a un programador de mainframes que lo fue a visitar. “Tengo mi propio sistema operativo y dispositivo de almacenamiento de archivos. No tengo que compartir mis recursos con nadie. El software es consistente y fácil de usar. ¿Por qué no dejas tu trabajo actual y te vienes conmigo?”

Entonces, el programador de mainframes comenzó a describir su sistema a su amigo, diciendo: “El mainframe está sentado como un antiguo sabio meditando en el centro de datos. Sus discos se encuentran de extremo a extremo como un gran océano de maquinaria. El software es tan polifacético como un diamante, y enrevesado como una selva virgen. Los programas, cada uno único, se mueven a través del sistema como un río de corriente rápida. Por eso estoy feliz donde estoy”.

El programador de microordenadores, al oír esto, se quedó en silencio. Pero los dos programadores siguieron siendo amigos hasta el final de sus días.
8.4
Hardware y Software se encontraron en el camino hacia Changtse. Software dijo: “Tú eres Yin y yo soy Yang. Si viajamos juntos nos haremos famosos y ganaremos vastas sumas de dinero”. Y así, el equipo se unió, pensando que conquistarían el mundo.

Actualmente se encontraron con Firmware, que estaba vestido con harapos y cojeaba apoyado en un palo espinoso. Firmware les dijo: “El Tao está más allá del Yin y Yang. Es silencioso y quieto como un estanque de agua. No busca la fama, por tanto, nadie sabe de su presencia. No busca fortuna, porque es completo en sí mismo. Existe más allá del espacio y del tiempo”.

Software y hardware, avergonzados, regresaron a sus hogares.
LIBRO NOVENO: EPÍLOGO
Así habló el maestro programador:
“Es hora de que partas”

lunes, 26 de febrero de 2018


TIPS para un sistemas de stocks y ventas


El éxito de un sistema de stocks requiere una clasificación útil y eficiente de la mercadería que fluye desde los proveedores hacia los depósitos y hacia los clientes. Cuanto mayor es la variedad de la mercadería (ítems) mayor es el impacto de una organización inicial

Debe preverse los puntos de stock, que pueden ser depósitos fijos o por ejemplo consignatarios, o simple mercadería reservada
De mínimo un sistema de stock registra los ingresos y egresos a esos “puntos de stock” y es capaz de mostrar los flujos y calcular el “saldo” en cualquier momento de la historia registrada.

Los eventos que generan ingresos o egresos pueden ser creados por el mismo sistema ej.: evento de egreso= facturación en mostrador. O registrarse una factura de venta
Los eventos de ingresos en gral consisten en la registración de una factura de compra o remito de compra
Si se trata de más de un deposito debe considerarse el evento “traslado” que egresa mercadería de un depósito y lo ingresa en otro 3
Quienes son los actores? Clientes codificados? , proveedores codificados? , muchos vendedores?, revendedores?
Como se valorizara el stock? . Para esto deberá considerarse almacenar datos de valor (costo, precio de venta, márgenes de recargo etc.)
El conocimiento razonable  de estos temas que no son %100 informático fundamentan el éxito de un sistema
Tenemos mucha experiencia en el manejo de estos temas . Creemos firmemente en la utilidad de nuestro apoyo en la configuración de un sistema adecuado
Describiendo únicamente características del soft. Podemos decir que la mercadería puede identificarse en base a códigos propios ;pero guardando también el código que le asigne el proveedor (alfanumérico) . Para su localización rápida pueden generarse códigos de barra o utilizar (si los hay) del proveedor. La descripción también sirve de criterio de localización de un ítem
Para el valor de la mercadería se guarda el costo y/o el precio de venta.
El precio de venta se puede fijar en base a formula o por grabación directa.
La variación del precios y su control se hace mediante procesos automáticos o grabación directa.
Los movimientos de ingreso/egreso son todos en base a comprobantes .(facturas , remitos , notas , planilla etc). Esos comprobantes pueden ser copiados o generados (ej:factura de venta o remito) en puestos de ventas cumpliendo con los requisitos fiscales (impresora fiscal , facturación electrónica etc) La actividad de ventas puede ser controlada de forma específica.
Puestos de ventas puede haber muchos funcionando simultáneamente (en red local preferentemente ) o accediendo remotamente a un server dedicado en la nube de internet



Los movimientos de stock pueden referirse a un único deposito o hasta 5
Se puede registrar todo desde un único puesto o tener una pc en cada deposito que este aislada (se actualiza vía pendrive), que esté conectado vía cable (red local) o  que se acceda a un servidor dedicado en la nube de internet
Los movimientos de ingreso pueden estar referidos a la actividad de compras, es decir asociados a un proveedor o en el caso más simple: registrar solo la cantidad de mercadería ingresada
El stock (existencias o saldos) se pueden calcular a cualquier fecha para la que existan movimientos registrados. No hay cierres ni restricciones en eso.
Se genera información entre fechas , por artículo , la clásica ficha “cardex”  para control. Se han hecho informes analíticos de mercadería sin movimiento , precios desactualizados , ranking de ventas , análisis de márgenes de venta, movimiento mensual agrupado etc., etc.
El sistema de “stock” es la base para el de “ventas” que a su vez puede estar  estar relacionado con “caja” y “cuentas de clientes” .
El sistema de ventas , puede registrar distintas formas de pago , entonces puede haber pagos con tarjeta , con efectivo a cuenta corriente a crédito etc existiendo un nuevo sistema para cada tema

Según la forma de pago

Tambien en caso especial de pago con “mutuales” , donde se deja todo listo pàra “importar” cupones desde el sistema de “Ordenes de Mutuales”
Por el lado de la compras se relaciona con  “cuentas de proveedores”


lunes, 12 de febrero de 2018


TRATAMIENTO DE PROBLEMAS


Hay 4 maneras distintas y de distinta efectividad de tratar un problema
1- ABSOLUCIÓN
consiste en ignorar el problema y esperar que se resuelva solo
2- RESOLUCION
consiste en hacer algo que produce un resultado que se considera suficientemente  bueno , que "satisface" (los médicos tienden a resolver problemas)
3- SOLUCIÓN
Consiste en hacer algo que produce lo que corrientemente se considera el mejor resultado posible
4- DISOLUCIÓN
consiste en  en rediseñar la entidad que tiene el problema , o su entorno a fin de idealizar: eliminar el problema y permitir que esa entidad se desempeñe mejor en el futuro de lo que puede hacerlo actualmente
 Rusell Ackoff "Las fabulas antiburocraticas de Ackoff"

miércoles, 7 de febrero de 2018

Pronósticos en Stocks y ventas
Series de Tiempo


Cuando se trabaja sobre stocks y ventas , debemos prepararnos para el momento en que el cliente pida información de análisis histórico , o nos sugiera que estaría buenisimo que el programa de venta compare el stock existente vs la venta esperada y genere un aviso de faltante o próximo faltante.
Parece muy fácil ... ! todo se hace con una planilla excel
Pero hacer responsablemente algo para satisfacer esto necesita algún conocimiento previo.
Las series cronológicas de datos (o series de tiempo) requieren de un análisis descriptivo que se hará comprensible y útil si hemos estudiado la estadística descriptiva habitual .
Habrá que tener algún background en ajuste de curvas.
Así podremos analiza la tendencia , los ciclos , la estacionalidad , Seleccionar un modelo adecuado de ajuste y finalmente hacer un pronostico con un criterio de aceptacion mensurable (defendible)
La administración de stocks es un tema fundamental en las actividades productivas del hombre. Toda administración necesita de planes , los planes necesitan de pronósticos. Los pronósticos necesitan de la estadística , la estadística es una disciplina de la matemática.
O sea ... basta de la ingenuidad decepcionante de muchas herramientas para la administración de inventarios. la mas simple de las herramientas debe  tener una justificacion aceptable
En ingeniería industrial , los temas citados son parte habitual de la curricula académica. En otras profesiones involucradas es conocimiento que se debe adquirir por motus propio.
En gral todo plan formal requiere de la emisión de pronósticos para diferentes indicadores
La plantificación es una actividad que se expresa numericamente

lunes, 29 de enero de 2018

CONSULTORIA














Consultoria es el proceso por el cual ayudamos a nuestros clientes a resolver problemas o alcanzar objetivos
Nuestras metas durante el proceso son:
  • Establecer un vinculo de colaboracion
  • Solucionar los problemas de forma permanente
  • Brindar atencion a los aspectos tecnicos y a las personas
Nuestra experiencia se ha desarrollado en empresas comerciales , industriales y de servicios donde nuestros consultores hicieron su aporte en el area de direccion , administracion, operaciones administrativas , produccion ,infromación para desiciones e información para operación , tecnologia informática , análisis de sistemas , diseño de sistemas , reingenieria
Las componentes basicas de un trabajo de consultoria en su empresa seran:
  • Exploracion
  • Fijacion de objetivos
  • Programa de trabajo
  • Controles
  • Planificar transferencia , instalacion,institucion,puesta en marcha


Para trabajar como consultor o independiente, uno necesita ser un 
verdadero experto en el campo en el que se ha especializado.
Trabajamos sobre datos y reglas para modelar sistemas informaticos útiles, estables , robustos , capaces de interactuar eficazmente con las computadoras y comodamente con los seres humanos que los manejan
En nuestra tarea de consultoria siempre tenemos presente que :un sistema informático instituido debe ser revisado periódicamente para cersiorarse de que se estén empleando los procedimientos y datos apropiados. Este seguimiento es esencial para obtener los beneficios esperados y recuperar los gastos causados por los cambios. Un grupo de trabajo debe ver en el seguimiento una oportunidad para introducir cambios de mejoramiento . ....Deberá cerciorarse que el trabajador individual por lo menos no tendrá que enfrentar mas contingencias que las que son normales en la organización (G. Nadler: Diseño de sistemas de producción)
1- Lo escucharemos
2- Reuniremos informacion y evaluaremos
3- Propondremos una solucion factible (Aseguramiento de datos y estructuras , reingenieria de procesos de informacion y  de sistemas esenciales)
4- Si es necesario iniciaremos un proceso de consultoria




viernes, 26 de enero de 2018



➤Cualquier oferta de soft hace exhibicion de sus CARACTERISTICAS

que esta escrito en n+/- ,
 que los datos se guardan en la base de datos estacional orateplus ,
 que es bajo en contenido de sodio ,
 que es cero azucar ,
 que es un diseño transaction holatv! ,
 que es multiusuario
que cuenta y acumula los flujos
que controla los saldos
que el diseño de informacion y procesos esta basado en componentes zzz
 que esta integrado a la red regional y se hace delivery de cafe incluido
que la empresa esta aprobada por la jtp 666
 que se cumple con la normativa gral y especial del area
 etc
 etc
 etc
Debemos considerar que para una aplicacion que resuelve problemas integrados , muchas de esas caracteristicas no tienen ningun significado especial , quizas si no  las tuviera simplemente no estaria en concurso.
➤ Las caracteristicas sumamnete apropiadas o diferenciadas en alguna aplicacion las llamamos VENTAJAS
➤Cuando la disposicion de un soft permite que la empresa haga algo que antes no podia , o que lo hace a menos cosoto , o mejor ... eso implica un BENEFICIO

✱✱✱ Lo IMPORTANTE es que algunas de esas caracteristicas signifiquen una VENTAJA para la empresa
✱✱✱ El trabajo del consultor es la intervencion para localizar caracteristias ventajosas que  se conviertan en un BENEFICIO

miércoles, 24 de enero de 2018


Donde invertir en test y correccion antes de liberar un programa?

La severidad de los defectos tienden a seguir la regla 80/20. Con el %80 de los defectos no criticos  y un %20  criticos.
Adicionalmente , generalmente solo el %20 de las caracteristica de un programa , son  criticas  en el sentido que:un error en esas  caracteristicas haga inservible al programa.
La probabilidad de que un bug critico ocurra en un area funcional critica  es apenas del %4 (%20 de %20). O sea , las chances de que un bug sea de menor importancia es del %96
Podemos interpretar que para que esos % sean factibles se debe incurrir en una desproporcionada cantidad de testeo y correcccion a las areas funcionales criticas
James Walsh . "detrmining software quality" .Computer languaje , abril 1993

lunes, 22 de enero de 2018


-Un programa terminado contiene todos los defectos posiblesY los que no sean los que pusimos nosotros , es probable que se generen por el ambiente pero ...Que se manifiesten como fallas ...mmmm. sigue siendo una cuestión de probabilidades.-

Hace mas de 20 años cuando llego la ola de los formalismos , se hizo notable un tema: la fiabilidad del software . con mucho fundamento estadístico se proclamaba aspectos ingenierles en esta profesión. Me pareció fantástico que al fin los términos modelo , distribución , esperanza , muestra ... etc etc etc iban a ser parte del normal arsenal de conceptos del programador
Tema no apto para los programadores iluminados , menos para los que provenian de áreas no formales o sin nivel matemático.
Fue una oprotuna inspiracion , hoy en los centros de desarrollo de la ingenieria continua el debate

"El tamaño, la complejidad y la dependencia humana de los productos basados en software han crecido dramáticamente durante las últimas décadas. Los desarrolladores de software están luchando para entregar software confiable con un nivel aceptable de calidad, dentro del presupuesto y el cronograma dados.
Una medida de la calidad y confiabilidad del software es la cantidad de fallas residuales . Por lo tanto, los investigadores se están centrando en la identificación del número de
fallas presentes en el software o la identificación de los módulos del programa que son más
 probable que contenga fallas.
 Se han desarrollado muchos modelos usando varias técnicas. Se sigue un enfoque común para la predicción de fiabilidad del software utilizando datos de falla.
 La confiabilidad del software y la predicción de la calidad es altamente deseada por los promotores , desarrolladores, gerentes y usuarios finales. Detectando software las fallas al principio del desarrollo definitivamente mejorarán la confiabilidad y calidad de manera rentable."  A. K. Pandey and N. K. Goyal, Early Software Reliability Prediction, Studies in Fuzziness and Soft Computing" ...
...
"Los modelos de confiabilidad del software generalmente se refieren a estimar el número de
errores en un software parcialmente depurado. Las pruebas realizadas en el software resultan
 como : aceptado, condicionalmente aceptado o rechazado. La aceptación puede ser
basado en la cantidad de errores encontrados durante un período de tiempo seleccionado, en el número de caminos ejecutados del número total de caminos disponibles para ser ejecutados, o algun  otro criterio preestablecido. Una variedad de modelos de confiabilidad ahora compiten por
la atención del analista
Los modelos de confiabilidad de software se pueden categorizar ampliamente
como lo sugirió Pham (2006):
Determinístico: utilizado para estudiar la cantidad de operadores y operandos distintos
así como las instrucciones de la máquina en el programa. Los dos  más comunes  son:
- La métrica de software de Halstead, basada en el no exclusivo. de operadores y operandos.
- Métrica de complejidad ciclomática de McCabe, basada en el número ciclomático V (G).
Probabilistico: describe la ocurrencia de falla y / o el fenómeno de eliminación de fallas
del proceso de prueba como eventos probabilísticos con respecto al tiempo y / o prueba
esfuerzo. Algunos modelos probabilísticos comunes incluyen los siguientes (Pham 2006):
- Modelo de tasa de fallas (tiempos entre modelos de falla).
- Modelo de falla o conteo de fallas (modelos NHPP).
- Error o modelo de siembra de fallas.
- Modelo de crecimiento de confiabilidad, etc."
 Ajeet Kumar Pandey 2013
Aunque ninguna técnica puede determinar el número de errores restantes con precisión absoluta, la medición sistemática de la tasa a la que se están descubriendo nuevos errores proporciona una pista valiosa sobre la calidad del software. El principio básico de esta técnica es intuitivamente atractivo:
Cuanto mas defefctos hay en un programa , mas fácil es descubrirlos.

el numero de nuevos bugs por unida de tiempo de testeo , tiende a disminuir con el tiempo en la medida que los defectos de un programa son descubertos y solucionados.
Midiendo la tasa de decaimiento en el descubrimiento de defectos a travez del tiempo en un proyecto,el numero de bugs no detectados que quedan en un programa, puede ser inferidos con un alto grado de confianza
James Walsh Determining software quality .Computer languaje abril 1993