Conceptos

Una petición (que a menudo se convierte en exigencia) muy común que hacen los clientes, es una garantía de desempeño, cosas como:

1. Quiero que todas las pantallas/paginas tengan un tiempo de respuesta máximo de 3 segundos.
2. Quiero que todas las consultas tengan un tiempo de respuesta máximo de 3 segundos
3. Quiero que el sistema corra en mi servidor (cuando bien nos va, nos dicen las características del servidor)

Que hacer en un caso así? Cuando yo acababa de salir de la carrera (hace ya más de una década) mi respuesta solía ser: "Necesito más datos", "Con la información que tengo no puedo garantizar ese desempeño", "No sé ni en que consiste el algoritmo para el proceso de cálculo de comisiones por ventas indirectas ¿cómo voy a garantizar que la pantalla donde veo el resultado de eso responda en 3 segundos???"

Casi sobra decir mi actitud era la actitud equivocada...

Encontré este codigo y La verdad empiezo a programar ocupo hace un punto de venta y que todo se guarde en un inventario.. crees que me funcione esto https://code.google.com/p/punto-venta/source/browse/?r=48#svn%2Ftrunk%2F...

Estoy Trabajando en eclipse MySql..

Ocupo un diseñ y la verdad el diseño de la base de datos lo tengo pesimo.. es de la preparatoria.. pero. me gustaría si me pudieran apoyar..
Es que me quebre la cabeza haciendolo todo.. y pss. un novato como yo no puede hacer mucho de diseño con el Puro Eclipse.. aparte queno soy muy bueno ..

lo que pasa lo trate de hacer en eclipse ese mismo proyecto pero.. tube algunas complicaciones.. con respecto al WebService.. En realidad nunca lo habia visto.. aparecio de repente.. y la verdad no lo entendi.. estoi acotumbrado a hacer proyectos. sencillos dde la escuela.. y genero el .war para el servidor local..
Gracias :)

Saludos :) espero su ayuda :)

En ingles hay un dicho: There is a difference betwee doing the right thing and doing the thing right.
La traduccion directa seria algo asi como hay una diferencia entre hacer lo correcto y hacerlo correctamente.

En la estimacion de software, y el proceso de negociacion que es necesario para que una consultora le
construya software a un cliente la diferencia entre una cosa y la otra es tremendamente importante.

Para "Hacer lo correcto" debemos entender claramente que es lo que el cliente realmente necesita (independietemente de lo que pida), en cambio, para "Hacerlo correctamente", no es relevante si lo que hagamos realmente le va a servir al cliente o no,lo que es importante es si lo que hicimos esta bien construido.

Un ejemplo extremo:

Un cliente viene y te describe un vehiculo monoplaza de transporte, que le permita viajar a donde quiera. Tu le de construyes una bicicleta, el pensaba usar el vehiculo en alaska, en la nieve, buscaba: una motonieve.

Finalmente, no importa que te tan bien hayas construido la bicicleta (hecha correctamente) al cliente no le sirve, por que lo que el necesitaba (hacer lo correcto) era que le construyeras una motonieve.

Antes de continuar con mas ejemplos concretos de supuestos, considero importante relatarles que cuando iniciaba con desarrollo de software me tope muchas veces con esta situación:

Lider del proyecto: El cliente dijo que la caracteristica XXX no le parece util. Que no entiende por que la hicimos asi si el necesitaba otra cosa
Programador: Es que yo supuse que...
Lider del proyecto: Pues, para la proxima vez no supongas: pregunta!
Programador: Lo siento, no vuelve a pasar

Y unos dias despues:

Programador: ¿Como debemos hacer la caracteristica YYY?
Cliente: Pues, de modo tal que maximisemos la eficiencia y demos valor al negocio...
Programador: Si, pero, la multiplicidad entre productos y pedidos es uno a muchos? o muchos a muchos?
Cliente: (de que habla este compadre?) Lo siento, tengo otra junta, luego lo vemos
Programador: Pero pero...

Y finalmente:

Hace poco lei, un tweet que decia:

Felicidades a "Asumir" por ser la MADRE DE TODOS LOS ERRORES DE ESTIMACIÓN en los desarrollos de software!!!!

— SoftwareEvangelist (@vanessa_amaya) May 10, 2013

¿se dara cuenta la autora... que esta asumiendo que asumir es el problema?

Hay quienes consideran que estimar es imposible y una perdida de tiempo, una inutilidad, hay quienes consideran que si puede hacerse, pero solo bajo ciertas condiciones y hay quienes piensan que el secreto en seguir un cierto método... Sin embargo yo quisiera antes de platicar al respecto de dichos puntos de vista, centrarme en una pregunta a menudo omitida en los artículos y libros de estimación:

Por que estimamos? Y no hablo de por que en el sentido teórico que típicamente se utiliza en los libros del tema, si no de, afuera, en el mundo real. No quisiera generalizar, asi que lo que diré a continuación lo digo acotado únicamente a mi experiencia.

No estimamos para saber cuanto tardara el proyecto, el cliente generalmente ya estableció un deadline que difícilmente moverá.

Por que estimamos entonces? Estimamos para ver si podemos hacer algo que quepa dentro del tiempo y presupuesto que ya están establecidos y que le suene al cliente a lo que pidió (por que si algo es cierto es que la mayoría de los clientes no sabe realmente lo que quiere hasta que no se le han hecho un par de demostraciones de avance )

Hola,
Comparto la segunda parte de un tutorial que cree del API de concurrencia en Java, para quien le interese.

http://jrlq.blogspot.mx/2013/05/concurrencia-en-java-parte-2.html