Diferencia entre revisiones de «Usuario:Santolaria/curso proyecto»

De WikiEducator
Saltar a: navegación, buscar
(Diseño y planificación)
Línea 36: Línea 36:
  
 
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?
 
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.
+
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.
 
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.

Revisión de 04:16 29 oct 2022

El Proyecto

Icon review.gif
Definición

El proyecto es un trabajo que demuestra un amplio conocimiento de los conceptos y técnicas necesarias para desarrollar un producto final, que en este caso se trata de un programa, aplicación web o página web.



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.

Icon activity.jpg
Ejercicio para la memoria

Una vez vistos los primeros puntos de la documentación o memoria del proyecto, vamos a ponernos manos a la obra.

  • Elabora una idea que refleje una necesidad real del día a día bien de una empresa o a una sola persona. Después, descríbela. Empieza con un resumen de esa idea, después ya la iremos detallando.
  • Tanto la portada como el índice del documento puedes ir haciéndolos, pero se recomienda que se haga cuando hayas finalizado para asegurarte de qué páginas se corresponden con cada apartado.
  • No hagas el DAFO aún aunque lo hayas pensado.

No olvides registrar las tareas y fecha en el que has hecho este ejercicio. ¡Lo necesitarás más tarde!
Para ejercicios de la memoria, puedes registrarlo en un documento aparte o a mano.
Para ejercicios de programación de la aplicación, guarda los cambios que hayas hecho hasta ahora en Github con los comandos correspondientes.



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.