Re: How we start a project
Posted: Mon Mar 29, 2010 12:12 am
Hi Sudip,
Rathi is right about some applications that arise in your mind and you have made part of the solution before on paper and then translate it into code.
The development is generally automating manual tasks, see, speak of accounting, billing, inventory, and all that was carried by hand and still does in many companies.
When a customer calls you because he wants a program, ultimately wants to automate the work to be done manually within your company, therefore, when you're taking requests, converse with the client, it tells you what you want and is the ability for us to define the limit as far as possible from the application, because otherwise, you automate you want to open the lock of the door.
Well, once you defined the problem, we ask that copies of documents used to perform the task. Of these, you can get all the information you require to assemble the database.
Then comes the analysis of the data, apply the techniques of cleaning the tables and create building blocks according to documents obtained by adding new requirements or formalities required.
With this, you will do an initial design (prototype) which present the client, how it works, as entering data, etc ... in general terms.
Once approved the prototype, you will get you from head to encode and painted screens.
Some kinds of applications that you do more than once, such as inventory control, this kind of applications is a world apart as each client has its control as it wants, has created a code at will, sometimes not well done and over ... what you do have to know is that you should never bring administrative services to your applications because you'll get in trouble, for example, allow change records when proof is closed, go to the tables and make changes, and etc. .. very long.
Well, this is more or less my experience as to how to deal with new developments, I hope you find it useful.
Best Regards,
Luis Vasquez
Hola Sudip,
Rathi tiene razón respecto a que algunas aplicaciones nacen en tu mente y ya tienes parte de la solución hecha antes de plasmarla en papel y luego en código.
El desarrollo por lo general es la automatización de tareas manuales, ya ves, hablamos de contabilidad, facturación, inventarios, y todo eso se llevaba a mano y aún se hace en muchas empresas.
Cuando un cliente te llama porque quiere un programa, en definitiva quiere automatizar el trabajo que se hace manualmente dentro de su empresa, por lo tanto, cuando tú vas a tomar requerimientos, conversas con el cliente, el te indica que es lo que quiere y está en la habilidad de nosotros poder definirle el límite dentro de lo posible de la aplicación, porque sino, querrá que le automatices hasta abrir el candado de la puerta.
Bueno, una vez que definiste el problema, le pides copias de los documentos que utilizan para realizar la tarea. De éstos, podrás sacar todos los datos que requieres para armar la base de datos.
Luego, viene el analisis de los datos, aplicar las técnicas de depuración de las tablas y crear los módulos en base a los documentos obtenidos agregando los nuevos requerimientos o formalidades que se requieran.
Con esto, podrás hacer un diseño inicial (prototipo) el cual presentarle al cliente, mostrarle como funcionará, como ingresarán los datos, etc... en términos generales.
Una vez aprobado el prototipo, podrás meterte de cabeza a codificar y pintar pantallas.
Hay algunos tipos de aplicaciones que las vas a hacer más de una vez, como por ejemplo el control de inventario, este tipo de aplicaciones es todo un mundo aparte ya que cada cliente lleva su control como quiere, tiene una codificación creada a su antojo, algunas veces bien hecha y otra no... lo que sí tienes que saber es que nunca debes llevar los vicios administrativos a tus aplicaciones porque te vas a meter en problemas , por ejemplo, permitirles cambiar registros cuando un comprobante está cerrado, entrar a las tablas y hacer cambios, y un etc.. muy largo.
Bueno, esto es más o menos mi experiencia en cuanto a como enfrento los nuevos desarrollos; espero te sea de utilidad.
Saludos cordiales,
Luis Vasquez
Rathi is right about some applications that arise in your mind and you have made part of the solution before on paper and then translate it into code.
The development is generally automating manual tasks, see, speak of accounting, billing, inventory, and all that was carried by hand and still does in many companies.
When a customer calls you because he wants a program, ultimately wants to automate the work to be done manually within your company, therefore, when you're taking requests, converse with the client, it tells you what you want and is the ability for us to define the limit as far as possible from the application, because otherwise, you automate you want to open the lock of the door.
Well, once you defined the problem, we ask that copies of documents used to perform the task. Of these, you can get all the information you require to assemble the database.
Then comes the analysis of the data, apply the techniques of cleaning the tables and create building blocks according to documents obtained by adding new requirements or formalities required.
With this, you will do an initial design (prototype) which present the client, how it works, as entering data, etc ... in general terms.
Once approved the prototype, you will get you from head to encode and painted screens.
Some kinds of applications that you do more than once, such as inventory control, this kind of applications is a world apart as each client has its control as it wants, has created a code at will, sometimes not well done and over ... what you do have to know is that you should never bring administrative services to your applications because you'll get in trouble, for example, allow change records when proof is closed, go to the tables and make changes, and etc. .. very long.
Well, this is more or less my experience as to how to deal with new developments, I hope you find it useful.
Best Regards,
Luis Vasquez
Hola Sudip,
Rathi tiene razón respecto a que algunas aplicaciones nacen en tu mente y ya tienes parte de la solución hecha antes de plasmarla en papel y luego en código.
El desarrollo por lo general es la automatización de tareas manuales, ya ves, hablamos de contabilidad, facturación, inventarios, y todo eso se llevaba a mano y aún se hace en muchas empresas.
Cuando un cliente te llama porque quiere un programa, en definitiva quiere automatizar el trabajo que se hace manualmente dentro de su empresa, por lo tanto, cuando tú vas a tomar requerimientos, conversas con el cliente, el te indica que es lo que quiere y está en la habilidad de nosotros poder definirle el límite dentro de lo posible de la aplicación, porque sino, querrá que le automatices hasta abrir el candado de la puerta.
Bueno, una vez que definiste el problema, le pides copias de los documentos que utilizan para realizar la tarea. De éstos, podrás sacar todos los datos que requieres para armar la base de datos.
Luego, viene el analisis de los datos, aplicar las técnicas de depuración de las tablas y crear los módulos en base a los documentos obtenidos agregando los nuevos requerimientos o formalidades que se requieran.
Con esto, podrás hacer un diseño inicial (prototipo) el cual presentarle al cliente, mostrarle como funcionará, como ingresarán los datos, etc... en términos generales.
Una vez aprobado el prototipo, podrás meterte de cabeza a codificar y pintar pantallas.
Hay algunos tipos de aplicaciones que las vas a hacer más de una vez, como por ejemplo el control de inventario, este tipo de aplicaciones es todo un mundo aparte ya que cada cliente lleva su control como quiere, tiene una codificación creada a su antojo, algunas veces bien hecha y otra no... lo que sí tienes que saber es que nunca debes llevar los vicios administrativos a tus aplicaciones porque te vas a meter en problemas , por ejemplo, permitirles cambiar registros cuando un comprobante está cerrado, entrar a las tablas y hacer cambios, y un etc.. muy largo.
Bueno, esto es más o menos mi experiencia en cuanto a como enfrento los nuevos desarrollos; espero te sea de utilidad.
Saludos cordiales,
Luis Vasquez
