crbelaus / pfg-doc Goto Github PK

Incluir un diagrama que muestre la arquitectura del nuevo LandPortal al completo. En este diagrama se puede explicar (de forma muy resumida) la función de cada uno de los componentes que lo conforman.

Revisar el capítulo de "Implementación del sistema"

Introducir las entidades que utilizaremos en la sección de datos: observaciones, indicadores, regiones, organizaciones, etc. Introducir también las entidades de la sección social (los nodos del debate).

Incluir manual de configuración del sistema. Al igual que el manual de instalación se incluirá como un anexo al que se realizará una referencia desde el apartado correspondiente de al documentación.

Incluir un diagrama que muestre el funcionamiento del punto de entrada de datos ante la llegada de un fichero XML procedente de los importadores.

Importante destacar la comprobación de seguridad que se realiza antes de procesar la petición, el funcionamiento del parser como un único backend para procesar el XML, y el funcionamiento de los distintos frontends para exportar los datos.

Incluir las herramientas utilizadas: editores, IDEs, librerías (hablar de virtualenv y pip), etc.

Añadir el análisis de interfaces de usuario, mostrando los mockups del debate y explicandolos en detalle. Las vistas finales serán parecidas pero no 100% iguales.

Revisar el capítulo de "Diseño del sistema"

Incluir una sección en la que se expongan los reportes obtenidos tras las pruebas por parte del cliente. A falta de un nombre mejor éstas pruebas podrían ser llamadas pruebas beta.

Sería interesante también añadir comentarios a cerca de los reportes que se han aceptado, los que se han podido reproducir y los que no.

Al principio de cada capítulo incluir un par de líneas explicando lo que se va a tratar. Un ejemplo de ésto se puede ver en el capítulo de pruebas.

El PMBOK define los stakeholders como personas u organizaciones que tienen un interés en la buena marcha del proyecto o en el sistema en construcción. Puesto que tengo que incluir dos componentes que no son ni personas ni organizaciones (importadores y visualizaciones) será mejor cambiarlo por actores para evitar posibles problemas.

Incluir un diagrama que muestre de qué forma se comunica el módulo "landportal_uris" con las vistas de mustache, y de que forma interviene la detección de idioma para obtener los datos y las labels a renderizar.

Hacer la identificación de subsistemas y la definición de interfaces entre los subsistemas. Será interesante hacer un "mapeo" entre componentes (CMS, SOLR, etc) y subsistemas.

Realizar la portada conforme al diseño de la plantilla oficial.

Revisar el capítulo de "Conceptos teóricos"

Incluir un requisito por el que los usuarios puedan pedir una nueva contraseña si han olvidado la suya.

Establecer los diseños de los encabezados y pies de página conforme a la plantilla oficial.

Habrá que añadir un nuevo subsistema de gestión de organizaciones y unos requisitos para tratar con las organizaciones.

De todas formas es mejor esperar, porque es posible que después del feedback de los usuarios esta vista se sustituya por la de los usuarios.

Durante la entrega adjuntar el fichero Excel con los resultados y los gráficos obtenidos de las mediciones.

Durante la entrega incluir el fichero Excel que contiene el presupuesto de costes y del cliente.

Incluir el presupuesto de costes en el que se detallan todos los costes reales en los que incurre el proyecto.

Hablar de los problemas encontrados durante el desarrollo y las soluciones que se han tomado al respecto.

Realizar la identificación de casos de uso y escenarios. Los casos de uso pueden ir divididos según los distintos subsistemas que hemos identificado anteriormente.

Actualmente algunos diagramas están hechos con Microsoft Visio y otros con Enterprise Architect. Portar todos los diagramas a draw.io hará que el documento sea más consistente.

Sería conveniente portar todos los diagramas a Microsoft Visio para así poder exportarlos en formato PDF y que no pierdan calidad al insertarlos en el documento final.

Será necesario actualizar las capturas de pantalla con los cambios que hagamos en el CSS.

Quizás sería conveniente cambiar el nombre de las pruebas del sistema que se detallaron en la sección Especificación del plan de pruebas del capítulo 4. Un nombre más adecuado podría ser: "pruebas beta".

Incluir el manual de instalación del sistema. Puesto que el manual de instalación también será entregado al cliente se incluirá como un anexo, y desde la sección correspondiente de la documentación simplemente se realizará una referencia al mismo.

Incluir un diagrama que muestre la arquitectura del módulo "landportal_uris". Explicar que su función dentro del sistema es proveer la información con la que se renderizarán tanto las vistas como las visualizaciones de datos.

Incluir la definicion de RDF Data Cube en la sección de conceptos teóricos. Explicar que el modelo de datos intentará cumplir con ésta especificación.

Hablar de los diversos lenguajes de programación utilizados:

• PHP
• Python
• SQL

También convendría hablar de otros lenguajes utilizados que no son lenguajes de programación:

• XML
• HTML
• CSS
• JSON

Incluir un diagrama que muestre los módulos de drupal que se han desarrollado así como los hooks a través de los que cada uno de ellos se integra con Drupal.
Explicar también que no se entrará en el detalle de los módulos porque todos ellos son muy simples, salvo el módulo "landportal_uris" que tendrá un diagrama para sí mismo.

Incluir el capítulo de conclusiones y ampliaciones. En las conclusiones se podría hablar de conclusiones técnicas y personales obtenidas del proyecto. En ampliaciones se podrían incluir todos aquellos futuros proyectos que habría con este cliente: LandLibrary o Hackaton.

Incluir un breve resumen de lo que se ha hecho en el proyecto, sus objetivos, la utilidad que se quiere dar, si está destinado a un cliente real, aspectos sobre la tecnología usada y cosas similares que permitan hacerse una rápida idea del trabajo realizado.

Revisar el capítulo de "Evaluación de alternativas"

Revisar el capítulo de "Análisis"

Incluir las pruebas del debate. Será necesario crear casos de prueba y pensar las salidas esperadas para cada uno de ellos. Luego construir una tabla explicando cada caso de prueba, su salida esperada y si se ha cumplido adecuadamente o no.

A diferencia de la zona de datos, éstas pruebas tendremos que realizarlas manualmente. Indicar que tampoco hay ningún problema en hacerlas a mano porque los fallos que se espera detectar aquí son fallos de configuración.

Incluir un diagrama que muestre en detalle la arquitectura del punto de entrada de datos. Se puede dar especial énfasis a la existencia de un backend común (el parser) y a la posibilidad de incorporar nuevos frontends además de los ya existentes (SQL, RDF, CKAN) sin necesidad de modificar la estructura existente.

Incluir las pruebas de integración del Receiver. Será necesario crear una tabla que explique las pruebas que tenemos realizadas en el fichero de tests, su resultado esperado y su resultado obtenido.

Añadir la especificación del plan de pruebas explicando los distintos tipos de pruebas que se realizarán:

• Pruebas unitarias para la funcionalidad implementada desde 0 (sección de datos).
• Integración continua para ejecutar automáticamente las pruebas unitarias en busca de regresiones y bugs.
• Iteraciones rápidas y actualización en el servidor de integración para conseguir feedback del cliente.

Incluir un diagrama que muestre la estructura final de la base de datos. Importante destacar que la estructura intenta cumplir con lo especificado en el RDF Data Cube Vobaculary y que cuenta con soporte multiidoma para los propios datos.

Los scripts de instalación deberán incluirse en un directorio llamado "installation_scripts" junto con los ficheros que se entreguen.

Incluir pruebas de rendimiento del punto de entrada de datos. Para realizar éstas pruebas se puede incluir el memory_profiler de Python y ejecutar desde 0 el proceso de importación de datos.
Los resultados de éstas mediciones pueden exponerse en un gráfico que compare:

• memoria - tamaño de la entrada
• velocidad - tamaño de la entrada

Posteriormente podríamos hacer unas regresiones para ver cómo se comportaría el sistema con otros tamaños de entrada.

Incluir una explicación de las interfaces del LandDebate, acompañadas de las capturas de pantalla correspondientes. La estructura y organización puede ser similar a la sección donde se mostaron los mockups.

Cambiar el puerto getData por una petición HTTP POST para que quede claro el único verbo que recibe. Indicar también que se utiliza ese verbo por su semántica.

Incluir un diagrama que muestre el funcionamiento del framework de acceso a datos que provee los datos para crear las visualizaciones.

Es importante destacar el funcionamiento del caché para mejorar el rendimiento.

Incluir un requisito en la zona de búsqueda que indique que el administrador podrá ejecutar la indexación de datos cuando el crea de forma conveniente (además de la importación periódica).