Como empezar un proyecto

Empezar la elaboración de una aplicación puede ser lo suficientemente complicado como para quedarse en ese punto, pero si tenemos una guía, el asunto puede verse facilitado un poco. Y de eso se trata este artículo.
Pero por ahora sólo voy a analizar el caso de un proyecto que realizamos a iniciativa propia, es decir, que no hay un cliente que nos va a decir que tenemos que hacer (y a vecescómo). Puede ser un programa que nosotros necesitemos para nuestra actividad laboral, o un proyecto de fin de semestre que podemos escoger, o una aplicación que luego pensamos comercializar.
Lo que pasa es que si hay un cliente, muchas cosas cambian y, en general, será más difícil. Seguramente luego escribiré al respecto.
Es muy importante tener un idea clara de lo que vamos a realizar y mientras másprofundo sea el análisis, mejor será el resultado, además de ser más rápida la construcción del software, sin embargo, se debe evitar la llamada “parálisis por análisis” que ocurre cuando queremos tenerabsolutamente todo resuelto antes de empezar, y, eso es sólo un ideal, no ocurre en la realidad. Así que usemos el sentido común y hasta la intuición para saber cuándo es suficiente análisis.Nunca podremos realizar el análisis completo y perfecto. Siempre existirá más datos, más posibilidades, más funciones necesarias, pero debemos empezar pronto para evitar la parálisis por análisis.
Entonces, sin más demora, estas son mis recomendaciones:
1)     Apagar la PC y tomar un lápiz y papel. Antes cuando tenía una idea, la analizaba lo mejor que podía mentalmente y empezaba a escribir código.En ese entonces vi que cuando el programa se hacía muy complicado era mejor empezar de nuevo. Y como eso era muy frecuente, aprendí que debes tener una idea muy clara del programa a realizar antes de empezar a codificar.
El papel nos deja anotar, tachar, dibujar, escribir ideas importantes al margen y, muy importante, arrugarlo y botarlo, cosa que es más difícil con la computadora.2)     Escribir el propósito del programa. Aunque tengamos muy claro en nuestra mente el objetivo de la aplicación, al escribirlo, ingresa en una categoría diferente, más formal, más objetiva. Debemos escribir todo lo que esperamos del programa pero sin caer en la tentación de convertirlo en un súper-sistema que hace todo. Es mejor colocar las metas mínimas, pues cuando ya esté funcionando se podrá aumentarfunciones mucho más fácilmente.
Se debe tomar en cuenta que a más funciones, más riesgo de no terminarlo.
3)     Analizar y mejorar el documento. Después de leer el texto escrito antes con el detalle de las principales funciones del programa, debemos hacer mejoras y aclarar cualquier detalle confuso. Aunque nosotros seamos los autores de la idea, es casi seguro que no tendremos todo claro. Y esto seevidencia al leer el documento completo de nuestras especificaciones. Vamos a ver relaciones entre distintos módulos, necesidades pasadas por alto la primera vez, tal vez contradicciones, etc.
Alguna vez me ha pasado que después de leer el documento recién elaborado, me he dado cuenta que el programa era una tontería que no valía la pena desarrollar.
También hubo otras ocasiones en que vi que elprograma era mucho más grande de lo que pensaba y que no podía hacerlo por cualquier razón.
Que quede claro: Si te saltas esta parte, perderás mucho tiempo después.
4)     Diseñar la base de datos. Esta es la parte más técnica y complicada. Pero también es fundamental. Tiene que estar bien hecha.
Debemos leer las especificaciones anteriormente escritas buscando las entidades (buscar entre lossustantivos)  y luego anotando sus atributos. Un diagrama Entidad-Relación será de mucha ayuda.
La importancia de esta fase es tal que vale la pena considerar el encargo a algún amigo experto la revisión  del diseño resultante.
Puedes leer un tutorial acerca del diseño de bases de datos en el blog no usaras coból.com.
5)     Diseñar las clases necesarias. Con el diseño de la base de...