Cambio de enfoque en la segunda parte

[jalcaldea]

He estado releyendo el enunciado y pone claramente que se trata de realizar una plataforma que siga una arquitectura de pizarra ( un framework). No dice nada de que haya que explicar la arquitectura de pizarra, que aunque esta bien lo considero en parte innecesario, os propongo cambiar el enfoque que le habéis dado, siguiendo esta estructura:

-1. Introducción: Se explica brevemente que se se nos pide y cómo vamos a trabajar.

-1.1 Arquitectura de Pizarra: Se explica que es la arquitectura de pizarra, pero sin detalles (como mi ejemplo del HDD), después se detallan las partes y dónde se suele utilizar ( se pude poner esquema).

-1.2 ¿Qué implica la arquitectura de pizarra? Describir que significa tener que usar esta arquitectura (cliente-servidor, distribuido, etc.)

-1.3 ¿Cómo va a ser la plataforma? Explicar brevemente las cosas que debe y no debe tener (requisitos) y por ello acabará con un párrafo introduciendo el siguiente capítulo.

-2. Documentación Se realiza la documentación de los requisitos, cual modelo en cascada, y se especifican en un documento ( a introducir en el capítulo o como anexo)

-3. Diseño Se realizan los diseños UML y se explican detalladamente

HASTA AQUÍ SE PIDE EN LA PRÁCTICA

-4. Implementación Se implementa y se explica brevemente el código.

Esto implica varias cosas:

1. Necesitamos concretar cómo va a ser la plataforma (para que lenguaje: android, c, c# )y que funcionalidades va a tener.
2. Hay que realizar una captura de los requisitos.
3. A partir de esos requisitos se pude empezar el diseño.

Y todas estas cosas se pueden hacer sin necesidad de escribir nada en la memoria, por lo que voy a crear un nuevo Issue para poder concretar estas cosas.

PD: También es necesario realizar un manual de la plataforma, ya lo veremos más adelante, no ? =P

[baos99]

Me parece correcto tu enfoque, ya que es claro y conciso, a la par que óptimo. De esa manera, nos evitamos meter cosas sin sentido.

[AdrianGJ]

La estructura que propones me parece bien, pero yo creo que donde explicamos la arquitectura de pizarra tiene que tener algo de detalle. Lo que tenemos es 1 pagina y media o algo así, no es mucho, si lo reducimos se va a quedar en un breve comentario. También yo aprovecharía el hecho de que disponemos de espacio ilimitado y poner el máximo de detalles, así como imágenes y esquemas aclaratorios, por ejemplo, en vez de explicar brevemente los requisitos, hacerle una recolección de requisitos completa diferenciando tipos de requisitos y explicándolos.

[jiep]

Estoy con @AdrianGJ, la arquitectura de pizarra hay que explicarla al máximo ya que es la base del framework y conocer al máximo el funcionamiento de ésta servirá para conseguir un mejor diseño.

[jalcaldea]

Creo 2 cosas, que tanto @AdrianGJ como @jiep no han entendido bien la practica, y que no habeis entendido para nada lo que he puesto un poco mas arriba xD

No he dicho que no haya que explicarla, he dicho que explicada así esta mal, tal como esta ahora sobran cosas.

Un primer apartado contendría: un pequeño párrafo para introducir la idea de "pizarra"( para que alguien que no tenga ni idea se entere), en otro párrafo irían las partes y como interaccionan con su correspondiente esquema, y mas tarde los usos que se le suele dar y demás (de momento todo lo que he dicho es lo ya esta puesto, sólo que ahora iría en un único apartado)

Luego faltan 2 apartados más, el primero en que se explica que significa o que implica el uso de esta arquitectura a la hora de crear un framework ( de esto no se ha puesto nada y es muchísimo más importante, sobretodo que poner metáforas inútiles) y en el segundo y último se daría pié a los requisitos del framework.

No se si os habéis liado antes o que yo no me he expresado bien, pero obviamente lo que os intentaba decir es que lo que hay ahora mismo no va a ningún lado y que hace falta organizarlo mejor para, precisamente, poder profundizar más.

Otra cosa, explicar cosas porque sí no tiene ningún sentido, si se explica algo es recomendable y prácticamente necesario, relacionarlo con lo que se quería dar a entender. Esto último lo digo porque tal y como esta ahora simplemente se dan unas "pinceladas" de arquitectura de pizarra pero que no van a ninguna parte.

EDITO: Los pros y contras que hay puestos en la memoria actualmente no tienen ningún sentido para nostros, eso es una de esas cosas que esta bien saber para nosotros poder utilizar pero que ponerlo de manera explicita no sirve para nada.

[jalcaldea]

Ya que prácticamente he recuperado lo que perdí sobre la primera parte (https://github.com/KekoAlk/Practica_DAS/issues/2#issuecomment-31318316) voy a invertir parte de tiempo en crear un nuevo branch para realizar, con los contenidos que ya hay, la introducción de la segunda parte. A ver si al verlo se entiende mejor y ya luego vemos si hacemos merge (combinamos las dos ramas, supondría quedarse con mi versión) o no.

[jalcaldea]

Como lo prometido es deuda, he creado un nuevo branch (https://github.com/KekoAlk/Practica_DAS/tree/memoria2) y he reorganizado el contenido del apartado introducción de la parte II (https://github.com/KekoAlk/Practica_DAS/commit/077dcb74bbca918d7290ad241e866bfcc307373e) para que se introduzcan los términos de una manera más amena e intentando que el avance en la memoria sea progresivo, que al acabar una parte se de lugar a la siguiente.

[jalcaldea]

No habéis contestado, pero he visto que @AdrianGJ y @jiep habéis mejorado a partir de aquí, así que, entiendo que os gusta la idea, voy a hacer un merge!