Hola!.

Acababa de leer el ultimo mensaje de Julio sobre patrones de diseño y esto me ha hecho recordar este tema.
Cuando hacemos una aplicación podemos hacerla de distintas formas.
Cada programador lo hará a la manera que mejor le convenga.

Bien. Os propongo esta discusión. Cuando creamos una aplicación tomamos una serie de entradas, tenemos en cuenta unas operaciones y
mostramos de alguna manera un resultado ya sea por la consola o en un formulario.

En este caso hemos partido de 0, no teníamos nada concreto y hemos ido paso a paso hasta un resultado final.
Ahora viene otra forma. Diseñamos un formulario y después su código.

Podemos tener muy claro desde un comienzo como van a ser representado los datos en el formulario.
Tenemos una distribución de componentes en el, pero nuestro código sera distinto por cada programador.

¿ No os recuerda esto al curso de Python de Coursera ?. Teniendo en cuenta que aprendemos a partir de una plantilla.
O de algo que ya hemos visto en un vídeo. Que es una buena forma de organización.

Bien. Supongamos que eres un programador y te llega un cliente a tu empresa de software.
El cliente quiere una representación de los datos de una forma determinada, sabe lo que quiere, no te esta
pidiendo que le hagas una distribución distinta.

¿ Que puede ocurrir ?.
- Podemos mostrar al cliente distintas formas de como podríamos representar los datos en un formulario.
- Podemos hacerlo a nuestra manera y no contar con la opinión del cliente. Solo va importar un resultado correcto.
- Podemos hacerlo con la idea original del cliente.
- Podemos hacerlo con la idea original del cliente y mejorarlo.

¿ No creéis que el cliente puede exigirnos como quiere que sea su aplicación ?. El paga.
Quiero que pongas esto aquí, esto allí, aquí quiero una lista, aquí botones..etc. ( Oye que es eso de un listbox ?, gambas ?.
Me vas a hacer una paella ?, es que soy mas de carne.   )

Ok, lo bonito o feo que pueda quedar el formulario es la cuestión final. Pero y si es prioritario ?.
El cliente puede ser un pejigueras de muy señor mio  

Supongamos que tenemos un extraordinario proyecto. Sumar dos números.  
Pongamos ese ejemplo por su sencillez.

Diseñas el formulario y luego haces el código o puedes hacerlo al revés.

¿ Que es lo que nos puede ocurrir ?. Al repetir el tipo de proyecto podemos hacer las cosas de una forma como un robot.
A parte que podríamos pensar, la pasta es la pasta y yo solo quiero pasta!. Y que fácil lo tengo, pero si tengo aquí mismo
el proyecto de sumar dos mas dos y no tengo que reinventar la rueda. Pasta,pasta!.

Conductas,costumbres y viva la pasta!.  

A parte de bromas. Estamos trabajando con un entorno de programación visual. Por lo tanto tendremos dos formas distintas de
crear una aplicación.


Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

No sé si entiendo muy bien lo que quieres decir.

A la hora de hacer un programa desde cero no existe ese cliente pejiguero que mencionas, porque -insisto que empezamos de cero- el cliente te plantea un problema y te pide una solución. Eres tú quien plantea el qué  y el cómo, eres tú el que conoce las herramientas y las soluciones. Muchas veces, incluso, el cliente no sabe cuál es su problema, sólo que este aspecto de su empresa no funciona.
Cómo enfocar la solución (subrayando que no digo el programa, digo la solución) tiene unos pasos muy definidos que no son cuestión de "estilo" o "preferencia" del programador.

Primero viene el Análisis Funcional:

Tu primera tarea no es si el formulario tal tiene botoncitos o desplegables. Es averiguar cuál es el problema que tienes que resolver. Tienes que sumergirte en la empresa del cliente, al menos en el ámbito de ella que te piden solucionar y comprender exactamente lo que hacen y cómo lo hacen. Tienes que definir los flujos de datos -quién crea tal o cual dato y quien lo revisa, quién lo procesa y en qué resultados está involucrado, qué documentos o dispositivos o formatos de entrada utilizan y qué documentos o soportes de salida genran, etc. etc.- En esos flujos tienes que tener en cuenta qué direcciones jerárquicas y físicas sigue la información, Si tal dato se genera desde el jefe al subordinado es una cosa, si se genera del subordinado al jefe es otra, si pasa de un departamento a otro, de un local a otro,  etc. etc. etc.
Esta fase es, casi, la más importante de todas ¡y aún no te has acercado a un teclado!. En ella te juegas que tu aplicación sea un éxito o no, que tu prestigio sea generador de futuras tareas o que nunca más se te encarge un trabajo.

Luego viene el Análisis Sintáctico

Una vez que has definido exactamente cuál es el problema, hay que plantearse la solución. Tienes que definir qué tipo de herramienta es la más adecuada ¿Una base de datos clásica?¿Una base documental?¿debe correr por internet o sólo en red local?¿Debe ir encriptado? ¿Debes plantear niveles de acceso según usuarios?¿Hay distintas vistas según la ubicación local o jerárquica?¿Debe haber integración con la ofimática?¿Entrada o salida de datos en tal o cual soporte informático?, etc. etc.

Luego haces el presupuesto.
En este punto sabes más o menos lo que necesitas y el tiempo que te va a llevar. Sabes si es necesario añadir o quitar hardware de la empresa, modificar las condiciones de los locales, los horarios de los trabajaodres o, yo qué sé, proveer de portátiles a los empleados, lo que sea.
Una vez que llegues a un acuerdo con el cliente, tienes que dejar muy claro lo que vas a hacer, porque luego vienen los malentendidos. ¿Cómo que no puedo trabajar desde mi portátil windows desde mi casa? ¡Yo quiero aprovechar los fines de semana (y jugar al winmata-mata, también, claro)!

Luego viene el sentarse ante el teclado y currárselo.
Aquí es donde la discusión de si el botón a la izquierda o derecha etc. etc.
Durante la codificación, y a medida que vas finalizando los diferentes módulos, es cuando los presentas al cliente y cuando éste se puede poner pejiguero, por cuanto ahora sí está viendo de verdad por dónde van los tiros y puede manifestar su preferencia y, sí, el que paga, paga.

Finalmente vienen las versiones pre-alfa, las alfa, las beta, los "pilotos de pruebas", las llamadas en fin de semana, etc. etc....

Luego aparecerán, no lo dudes, los "ya ques". "Ya que el sistema de ventas está informatizado, vamos a coordinar con facturación", "ya que me has hecho las nóminas, vamos a gestionar los pagos con el banco", etc. etc. Si eres perro viejo, todo eso lo habrás previsto ya y lo tendrás medio masticado, con lo que pones cara de ¡Buff...! ¿No podías habérmelo dicho antes? y ¡Esto no estaba previsto! y puedes preparar la siguiente factura. Si no lo habías previsto, te puedes encontrar con que tienes que volver, casi, a empezar de cero.

Abundando en ésto, el rollo que te cuento ahí arriba, está sucintamente definido por Julio en su post de losPatrones de diseño en gambas, en concreto te cito parte de una de las respuestas:

Citar:

Si, existen una serie Metologia http://es.wikipedia.org/wiki/Ingenier%C3%ADa_del_software
.......Analisis de requisitos
.......Especificación
.......Arquitectura
.......Programacion
.......Prueba
.......Documentacio
.......Mantenimiento

Por muy pequeño que sea un programa siempre  se siguen esos pasos (aunque sea inconscientemente).

Gracias Shordi.

Esperaba una contestación muy extendida por tu parte. Que bien te has explicado.

Ahora que tengo unos días libre, te contestare con mas tiempo a tu respuesta.
Que es muy interesante.

Y también veré los tutoriales de Julio de patrones de diseño con mas tiempo.
Que lo tenia pendiente.

A todo esto. Con todo lo que cuentas, me hago la idea de la gran cantidad de tiempo que puede
llevarte la creación de una aplicación. Del estudio que eso supone. Menuda responsabilidad tienes!.  


Saudos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Shordi:

Muy bien explicado, se nota en que trabajas

Citar:

los "ya ques"...

Real como la vida misma...  

Shell:
Para programa grandes (y pequeños) , necesitas llevar un orden (como explica Shordi), sin ese orden vienen los lios. No te puedes poner a crear formularios y "codificar" con la idea que te cuenta el cliente, tienes que asegurarte que es lo que te pide, organizarlo (mediantes esquemas, diagramas, etc), y luego sentarte con el cliente y ver que lo que "has escuchado y comprendido" es lo que el desea... y asi te puedes poner a trabajar, enseñando las "alfas" y "betas", para ir teniendo el visto bueno del cliente y ir sobre seguro.

Una buena planificación inicial y como dice Shordi "ser perro viejo", te ahorra mucho tiempo y esfuerzo.

Saludos

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Increíble coincidencia,entonces los "ya que" de la construcción, también están en la informática.

Cambiando de lugar de cliente => trabajador

Normalmente usan las palabras, "pues ya que", que hablando como profesionales, cambian por "pos ya que",
quedando al final un tecnicismo que es ampliamente conocido como los "po yas!" y acortan.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"

Los "ya que" son, quizá, la mayor fuente de ingresos de un programador o empresa de software, junto con los contratos de mantenimiento. El cliente, si tu software está bien diseñado y soluciona todo o parte de su problema, empieza a ver la ventaja de tenerte como "proveedor de inteligencia" de su empresa y cada vez se apoya más en tí. Ahí viene un delicado juego de toma-daca que es la quintaesencia de la vida del informático:

Si aprietas demasiado y pones precios imposibles, pierdes el cliente. Si pones precios demasiado bajos pierdes el tiempo. Si pones precios justos, debes apretar al cliente en las condiciones y límites de los ya-ques, ganándote la fama de quisquilloso. Si pones precios justos, pero no limitas los yaques de segunda generación -los que surgen a raíz de los primeros yaques y que podríamos llamar los Yyaques- pierdes otra vez el tiempo, etc. etc. etc.

Además, norma básica, primera frase de la primera clase del primer trimestre del primer curso de la carrera de informática: NUNCA HAGAS UN PROGRAMA PARA LA EMPRESA/NEGOCIO DE UN AMIGO/PARIENTE. Estarás matando, inevitablemtne, una de éstas dos relaciones: O tu relación con ese amigo/pariente o tu relación con tu ego y tu orgullo.

Saludos.

Shordi:

¿Y como llegar al "precio justo"?
Aqui he tenido yo problemas, porque según que pais/nivel economico se puede considerar un precio justo.
Una vez un chaval me pidio un programita que me llevo varias horas, le pedi 10 dolares y me dijo que si yo estaba loco, que si creia que él era rico... Una limpiadora puede estar ganando entre 6 a 10 euros por hora en España..,¿cual es el precio justo?


Saludos

Julio

===================
Blog personal
Web: SoloGambas seleccion de articulos dedicados a Gambas
Visita el Curso de Gambas3 ¡¡¡Gratuito!!!

Encontrar ese precio justo es algo con lo que todo autónomo tiene que lidiar.
Hay dos maneras: o lo calculas según tu trabajo, o lo calculas según lo que el cliente pueda pagar.
Mi consejo: Calcula según tu trabajo y díselo claro antes de empezar a mover un dedo.
La segunda opción consiste en robar al rico y hacer caridad con el pobre, pero no en ser profesional.
La primera es la más honrada, pero ten una cosa en cuenta. No todas las horas que dediques a un proyecto las puedes cobrar.

Uno debe ser honrado: El cliente no tiene por qué pagar ni tus errores ni tu formación. Si en diseñar un formulario, por ejemplo, que tenga una lista y un formulario dependiente, etc., tardas dos horas haciéndolo "artesanal"... y a medio hacerlo se te ocurre que una función que cree los controles en tiempo de ejecución sería buena cosa y pierdes tres o cuatro horas haciendo esa maravillosa función, que luego va y no funciona del todo bien... y te toca terminar haciéndolo "artesanal", el cliente no tiene la culpa. Tú cóbrale esas dos horas iniciales y el resto lo echas al capítulo de "Formación".
Pero no minusvalores tu trabajo porque el cliente no pueda pagarlo. Ese es su problema.

Personalmente, cuando un amigo o familiar me pide algo, un programa, una web, lo que sea, siempre, siempre se la hago gratis. Me cueste lo que me cueste de tiempo y esfuerzo. Lo pongo en el capítulo de "Donaciones". La mitad de mi familia me lo echa en cara... y tienen razón. Pero es que es un problema sin solución:

Si le cobras lo que vale malo, que eres un cabrón que te aprovechas de la familia y, además, por haber confianza, no te libras de llamadas a media noche, fines de semana, etc. etc.

Si le haces "precio de amigo", peor, que entonces se sienten con derecho "porque lo han pagado" a esas mismas llamadas y demás mientras tú te sientes imbécil porque esa mierda que te dieron no cubre el follón.

Cuando lo haces gratis, te sitúas en posición de fuerza, por cuanto te deben un favor. Entonces como que se cortan de llamarte y darte demasiado la lata. El problema es que a nadie le gusta sentirse en deuda y, o bien dejan de usar el programa porque "no funcionaba y por no molestar prefiero hacerlo a mano", con lo que tu trabajo se desperdicia del todo, o bien van cortando la relación poco a poco y al final has perdido el amigo y te enteras por terceras personas que han "contratado una empresa" que le da un producto igual o inferior al tuyo, pero que aprecian porque lo pagan.

En todos los casos sales perdiendo o amigos o dinero. Por eso, repito: NUNCA HAGAS NADA PARA LA FAMILIA O AMIGOS.

Si no es amigo o familiar, haz como cualquier profesional: "Esto vale tanto, lo tomas o lo dejas" y las horas que he dedicado a analizarlo, a tanto la hora, por supuesto.

Dejando esto dicho, quede claro que hay más de una forma de cobrar que no es por horas de trabajo. Puedes cobrar por tabla maestra, por formulario, por módulo funcional, etc. etc. Ahí cada cual que estime su manera.

Personalmente hago el cálculo por horas y le resto mi propio interés. Con esto quiero decir que cuando hay una solución que a mí, como programador, me interesa profundizar, eso no se lo cobro, aunque él salga beneficiado. No śe si hago bien con ello, pero es que me remuerde la conciencia si hago otra cosa.
Un ejemplo: Hace poco hice un proyecto para un Gabinete de abogados. Parte fundamental era subir todos los documentos a un servidor FTP y enlazarlos con la base de datos. Bien. Aquí yo podría haber hecho una serie de scripts que utilizasen FTP vía shell  o, como al final hice "inventar" un cliente ftp al estilo Filezilla hecho con gambas e imbricado en la aplicación.
Esta segunda opción me interesaba a mí, que era lo único novedoso en toda la aplicación, y me costó bastantes horas de investigación y demás. No se lo cobré. No me pareció justo. Hoy día están encantados con la aplicación y yo encantados con mi cliente ftp (lo subí a este foro, pero luego lo he modificado y a ver si tengo un ratito y lo actualizo).

Finalmente tienes el tema del caché personal, que no es lo mismo tener nombre en el mercado que no, etc. etc.

Sea como sea no hay una fórmula fija para el precio justo, me temo.

Saludos.

Julio:

Uff, pero en cuestión de precios os vais a encontrar de toda clase de clientes.

¿ Como se puede valorar mas o menos las horas que has hecho en un trabajo determinado ?.  ( Convenios,leyes ?.. )

¿ Como se puede tener un baremo para decir puedo poner un precio determinado por una aplicación ?.
¿ Viendo el precio de la competencia ?. ¿ Entonces las empresas bajan el precio por que el cliente sea de otro lugar ?..pregunten a M$.

¿ A ti te parece justo el precio ?, ¿ Entonces ?.
¿ Quieres tener un beneficio determinado o piensas hasta donde puedes bajar para poder vivir de esto ?.
¿ Quieres vivir de esto ?.

Pongamos un caso. ¿ Como una aplicación puede valer millones ? ¿ Cuantas copias piensan vender ?.
Sin conocer el trabajo, personal, material que conlleva no podemos apreciarlo. Luego esta el soporte al cliente.

Saludos

===================
Gambas Básico
"No es un bug, es una característica no documentada"