Usuario:Santolaria/curso proyecto
Contenido
El Proyecto
El proyecto engloba dos partes bien diferenciadas, la documentación o memoria , y el producto. Deben estar unidas en todo momento; no puede haber producto sin la correspondiente documentación. Pero, ¿qué son?
La documentación
La documentación, también llamada memoria, es un documento que refleja el día a día en cuanto a trabajo se refiere, así como la planificación prevista de las tareas. También se recoge los acuerdos pactados con el cliente, ya sea real o ficticio.
Se trata de un documento que va dirigido a cualquiera que quiera saber qué producto se ha hecho, por eso el documento debe escribirse con un estilo formal y claro para que incluso la gente más ignorante sepa de qué estamos hablando.
Introducción
Su contenido puede variar según el producto que debemos hacer, pero todas deben tener al menos una portada y un índice, que normalmente se suele poner a continuación de la portada. Este índice contendrá los temas o puntos a tratar.
Luego empezaremos a redactar la memoria. Comenzaremos con una descripción sintetizada de lo que va a ser la aplicación final, objetivos y metas, y para quién va dirigido. Deberemos decidir si es una aplicación que se ajusta a unas necesidades específicas, o una que se lanza a todo el público en general. Tendremos también que analizar el mercado, buscaremos aplicaciones similares a la nuestra y crearemos un análisis DAFO de nuestra aplicación para ver qué cosas podemos hacer para que nuestro producto destaque entre otros.
Diseño y planificación
Continuaremos con la planificación de tareas. Vamos a dar forma a esa idea que teníamos en mente. Tenemos que calcular qué vamos a necesitar para llevar a cabo la construcción. Si ya te han dado el esquema de la memoria con los apartados que debe tener, tienes que tener en cuenta que cada apartado nos va a llevar su tiempo hacerlo y/o redactarlo. Primero tendremos que elegir qué método usaremos para organizar y distribuir nuestras tareas. ¿Usaremos la metodología ágil? ¿Le mostraremos al cliente cómo va creciendo la aplicación, o se la mostraremos únicamente cuando hayamos finalizado todo? ¿Qué esquemas o diagramas nos darán una idea de cómo desarrollar la aplicación? Estos interrogantes nos harán saber las tareas que realizaremos y diseñaremos la tabla o lista de tareas. Asignaremos a cada tarea un número aproximado de horas para llevarlas a cabo. Si optamos por mostrar al cliente nuestro trabajo antes de haberlo completado debemos posicionarlo en la lista. Si este es tu caso, decir que normalmente al cliente se le cobra un porcentaje en este punto, para al final cobrar el resto. Pero tú siéntete libre de qué quieres hacer. No olvides que esto es una 'predicción', y que luego pueden surgir imprevistos que también tendrás que anotar cuando llegue el momento.
También habrá que deducir el precio que costará montar todo el proyecto. Ten en cuenta tanto los costes fijos como los costes variables, y súmalos después. La cantidad que resulte es lo que tenemos que pagar. Por tanto, crearemos alguna comisión para obtener ganancias. Lo sumaremos también al total de costes y ese será el precio a pagar por nuestro cliente en caso de que tengamos uno.
Después de elaborar el presupuesto, comenzaremos lo que es el diseño en sí, empezando por bocetos provisionales de las interfaces de nuestra aplicación, los llamados mockups. Cada pantalla distinta será un mockup, aunque, si el tutor te deja, puedes decir, si es el caso, que algunos mockups pueden ser parecidos o iguales, esto es para no tener que repetirlos.
Una vez vistos los dibujos, los botones y enlaces debes decidir qué diagramas se ajustan más a tu aplicación. El diagrama de Grantt es obligatorio. Otros diagramas pueden no ser necesarios. Estaría bien hacer el de flujo, para ver qué quieres que pase cuando se realice una acción, o el de clases, para ver la estructura interna que tendrá tu aplicación al programar. No tiene por qué hacerse todos, haz los que creas conveniente hacer. Esto principalmente conlleva muchas horas, así que ten en cuenta eso al hacer la planificación.
Vale, pero ¿y la parte de almacenar datos? También hay que reflejar como va a ser. Necesitamos pues, el diagrama E/R y el modelo relacional (hasta la 3F por lo menos) para saber cómo crearemos nuestra BD.
Ahora vamos a pararnos un momento. Dejemos la memoria de momento, porque para seguir escribiendo la documentación necesitaremos conocimientos de nuestro programa que es mejor que los tengamos frescos. Es decir, a partir de ahora vamos a combinar escribir la memoria con programar nuestra aplicación. Además, el siguiente apartado se trata precisamente de la programación.
Empezar a programar y documentar la programación
Si escoges "a pelo" |
---|
Pros
Contras
|
Si escoges algún framework y/o plantilla |
---|
Pros Contras |