-
Notifications
You must be signed in to change notification settings - Fork 0
Documento del proyecto
| Miembro | Horas | Commits | LoC | Test | Issues | Incremento |
|---|---|---|---|---|---|---|
| Álvarez Caro, Pablo | 60 | 19 | 431+ 194- | 6 | 5 | Login con redes sociales |
| Marín Gómez, Pablo | 60 | 37 | 1313+ 149- | 6 | 7 | Traducción español |
| Migueles Domínguez, Francisco Javier | 60 | 24 | 864+ 172- | 6 | 9 | Traducción inglés, interfaz traducible |
| Ruiz Gil, Diego | 60 | 14 | 593+ 193- | 6 | 5 | Exportación Census |
| Zamora Fernández, David | 60 | 20 | 476+ 175- | 6 | 5 | Visualizado de gráficas |
- decide-part-villanueva-de-trabuco-2: Los dos grupos tienen sus repositorios correspondientes villanueva del trabuco 1 y 2 donde desarrollaran las funcionalidades dentro de sus repositorios por ramas y luego subirán dichos cambios a los repositorios ya comentados y al repositorio general villanueva del trabuco. Los miembros del equipo trabajaremos en ramas individuales donde desarrollarán las tareas que se han asignado.
Decide está compuesto por diferentes subsistemas que son más o menos independientes entre sí y que se interconectan implementando una API concreta.
Cada subsistema se encarga de una tarea concreta en el sistema de voto. Puede haber tareas que impliquen modificaciones en más de un subsistema, por lo que habrá que coordinar el desarrollo para que puedan comunicarse entre sí.
Autenticación de votantes. En una votación debemos autenticar a los votantes y asegurarnos de que no se vota más de una vez o de que el votatne puede votar en esa votación. Para ello debemos autenticar a la persona y esta autenticación ha de ser segura, de tal forma que se reduzca la posibilidad de fraude, suplantación de identidad, etc.
Posibles formas de autenticación: * Usuario / Contraseña * Enlace único por correo electrónico * Enlace único por SMS o sistema de mensajería (whatsapp, telegram, etc) * Certificado FNMT * Redes sociales (twitter, facebook, google)
Una parte impmortante de una votación es el censo, que es el grupo de personas que pueden votar en una votación. Gestoniar el censo es una tarea importante a la hora de definir una votación y de controlar quién ha votado y quién no.
El censo está relacionado con la autenticación, pero no es lo mismo, el censo es la autorización para votar en una votación en concreto, es decir, puede estar autorizado a entrar en el sistema a través de la autenticación, pero puede que no tengas autorización para votar en una determinada votación.
Una votación puede definir una o varias preguntas, con diferente número de opciones y diferentes configuraciones. Puede ser voto simple, ordenación de una lista de opciones, elección múltiple, etc.
Interfaz para votar. Este subsistema se encarga de mostrar la interfaz de voto de una votación en concreto, perimtiendo al votante votar de la forma más sencilla posible.
Los votos se almacenan cifrados en una base de datos, donde tenemos la relación directa de votante y voto. No se puede saber la intención de voto porque el voto estará cifrado en la base de datos, pero sí tendremos la información de quién ha votado y quién no.
Susbsistema que se encarga de la parte criptográfica de una votación. La mixnet es una red de ordenadores que generarán una clave compartida para cifrar los votos. De esta manera sólo se podrá descifrar un voto cuando todas las autoridades se pongan de acuerdo, a la hora de hacer el recuento.
En el proceso de recuento se desliga el votante del voto, cada autoridad aplicará un paso de barajado de votos, antes de descifrar su parte, de tal forma que cuando se obtenga el listado de votos en claro, no habrá forma de saber qué ha votado cada usuario.
Una vez realizado el recuento, tenemos una lista de números, este subsistema de encarga de traducir esa lista de números a un resultado coherente con el tipo de votación.
Por ejemplo, si es una votación de tipo simple, simplemente habrá que contar el número de veces que aparece cada opción y se dará como ganadora la opción con más opciones.
Este subsistema también es el encargado de aplicar diferentes reglas a los resultados, por ejemplo, aplicar reglas de paridad, ley d'Hondt, etc.
Este subsistema es el encargado de coger los datos obtenidos tras el post procesado y pintarlos de una manera gráfica y entendible, generando gráficas y tablas.
También se encargará de generar los diferentes informes necesarios de estos resultados, ya sea en formato web, pdf, texto planto, etc.
- Registro con redes sociales
- Interfaz traducible
- Traducción al español y al inglés
- Exportación del censo de una votación
- Representación gráfica de los resultados obtenidos de una votación
A continuación, reflejamos todo el proceso de desarrollo descrito anteriormente mediante un ejemplo práctico de propuesta de cambio al sistema:
En primer lugar, al encontrar una propuesta de cambio al sistema, en principio por alguien perteneciente a alguno de los dos equipos de desarrollo, esta se debate entre ambas parts mediante la celebración de una reunión acordada previamente entre todos los miembros. Durante el debate se presenta el cambio, se discute su impacto en el proyecto y las ventajas/desventajas de su aplicación.
Una vez se apruebe mediante votación con mayoría simple, el cambio en sí deberá ser documentado y añadido a la primera de las herramientas que vamos a mencionar, GitHub Projects:
En GitHub Projects tenemos un tablero con las tareas a realizar con 4 secciones; “TO DO”, “IN PROGRESS”, “IN REVIEW”, “DONE”, en la que se asocia cada tarea a su responsable y se va actualizando el estado de esta según avanza. Esto ha facilitado al grupo tener una visión más amplia sobre el estado general del proyecto, tanto de su part como la del otro grupo. La nueva tarea se añade a la columna “TO DO” y se asocia a un desarrollador, que será el encargado de realizar la tarea en sí.
A continuación se crea la rama específica para la tarea, dentro del repositorio del part al que pertenezca el encargado de la tarea. Esta rama tendrá el nombre siguiente: tarea-nueva/uvus, cambiando ”tarea-nueva” por un nombre que represente bien el cambio y “uvus” por el uvus del encargado. En dicha rama solo debería trabajar dicho encargado, aunque en casos excepcionales, podrán hacerlo otros miembros del equipo.
A partir de entonces, el encargado debe desarrollar los cambios pertinentes en el sistema para satisfacer el cambio propuesto, subiendo sus cambios periódicamente a su rama e integrándose con la rama master del repositorio.
Para poder desarrollar una característica, el miembro del grupo descargará la rama correspondiente a su versión local del repositorio git. A continuación, abrirá el directorio de trabajo de la rama o bien mediante comandos git “git checkout” o bien, mediante la propia interfaz del VSCode.
Una vez se termine la funcionalidad, se procederá a hacer un commit “atómico”, donde se incluirá únicamente los cambios pertinentes para realizar el cambio que quiere realizar.
Alternativamente, si el cambio no es de código sino de archivos de configuración, se puede realizar el cambio sobre la rama desde VSCode en la web. para abrir VSCode en la web, simplemente se siguen los siguientes pasos:
- Diríjase a la rama apropiada del repo
- En la página principal de la rama del repo, pulse sobre el botón “.” de su teclado.
- A continuación, espere a que se cargue completamente la interfaz web
- Si se necesita de algún plugin de VSCode, puede buscar en la tienda de extensiones de code por si es compatible la que necesita.
Una vez finalizados los cambios necesarios en local, el encargado debe terminar de subir los últimos cambios a su rama y seguidamente crear una pull request hacia master, donde se integran sus cambios con las demás funcionalidades del sistema.
Desde master se van creando periódicamente pull requests para ir integrando los cambios con los del otro part. Los cambios desarrollados para satisfacer la nueva tarea deben pasar los workflows definidos en el repositorio.
Se han utilizado las GitHub Actions para poder realizar diversas tareas. En concreto, hemos definido dos archivos de workflow en el repositorio que realizan diversos jobs:
-
El primer archivo ejecuta con varias versiones de Python y PostgreSQL los tests definidos en el proyecto DJango.
-
Este archivo además analiza el código de forma estática con una herramienta web llamada Codacy. Este análisis en principio está configurado en la acción para que se ejecute en todas las ramas, pero en Codacy también podemos configurar las ramas en las cuales nos interesa conocer los tests.
-
Finalmente el último está diseñado para que compile una imagen Docker siguiendo las instrucciones del Dockerfile incluido y que una vez lo compile satisfactoriamente lo suba a DockerHub, un repositorio oficial de imagenes Docker donde los usuarios podrán descargar cualquier imagen (incluida la subida anteriormente) ejecutando docker pull o docker run, por ejemplo.
Además, el encargado de la tarea debe generar tests que comprueben el correcto funcionamiento de la funcionalidad añadida. En función de la tarea que estemos tratando, el diseño de los tests debe seguir uno de los siguientes patrones:
-
Particiones equivalentes (equivalent partitioning)
- Se divide el espacio de prueba en clases equivalentes
- Las particiones deben ser disjuntas
- Inconveniente: rápida explosión
-
Valores límite (boundary analysis)
- Según esta técnica los errores en los programas suelen estar en los valores límites de las entradas de un programa
- Se prueban los valores límite de las particiones equivalentes en caso de haberlas
-
Combinaciones: par-wise, n-wise
- Pairwise testing (también 2-wise testing). Es un método dentro de los llamados “combinatorios” que propone hacer pruebas sobre todas las posibles combinaciones de 2 parámetros de entrada.
- La hipótesis que maneja es que la mayoría de los errores son debidos a errores en un parámetro de entrada, la siguiente es la combinación de pares de
- parámetros de entrada, etc.
-
Errores conocidos (error guessing)
- Errores comunes según nuestra experiencia
- Ejemplo: cuándo se almacena un voto se puede almacenar con el mismo ID
-
Cobertura CRUD
- Para cada elemento persistente, se prueban todas sus operaciones CRUD
- Cada caso de prueba comienza por una C, seguida por todas las U y se termina por una D
- Tras cada C, U o D, se ejecuta una R que nos sirve de oráculo
Estos tests podrán ser tests unitarios, tests de carga, tests de vistas o tests de modelos.
El equipo usará las siguientes herramientas para desarrollar el proyecto:
Microsoft Visual Studio Code (v1.73 o superior)
- Python 3.8
- Firefox 105
- Chrome 107
- Django 2.0.12
- Bootstrap 4
En conjunto a estas herramientas, se hará uso de las siguientes extensiones del IDE utilizado: Soporte de Python en VSCode (Pylance)
- Live Share
- Spanish Language Pack for Visual Studio Code
El framework Django, al cual desde ahora nos referiremos como Framework, será utilizado como la base del proyecto, administrando los modelos, las vistas y los controladores del proyecto. A este le asistirá Bootstrap, otro framework orientado a facilitar un desarrollo más ágil de las vistas, proporcionando un modelo básico de vista con características iniciales como la adaptación de la vista en función del dispositivo.
La aplicación Visual Studio Code, a la cual nos referiremos como IDE, nos permitirá escribir el código de la aplicación, asistiendo en la tarea con sus extensiones mencionadas anteriormente. Para poder programar, será necesario un intérprete o compilador. En este proyecto se hará uso de Python.
Tanto Firefox como Chrome se utilizarán para comprobar que la plataforma web funciona de la forma que se espera, haciendo uso si fuera necesario de sus relativas herramientas de desarrollo, incluidas por defecto.
Intalación del entorno:
Linux:
Para instalar VSCode en Ubuntu Linux se deben seguir los siguientes pasos:
-
Dirijase a https://code.visualstudio.com/download
-
Descarge el archivo .deb para la arquitectura de su sistema (normalmente suele ser x64, x86_64 o amd64)
-
Abra una terminal en la carpeta donde haya descargado el fichero y ejecute:
sudo apt install ./.deb
Donde se sustituye por el nombre del archivo
Para instalar las extensiones de VSCode, simplemente se dirige dentro de VSCode a la tienda de extensiones y se busca por su nombre
Instalación de decide
-
Clone el repositorio
-
Instale python3.8 con: sudo apt update && sudo apt upgrade -y sudo add-apt-repository ppa:deadsnakes/ppa -y sudo apt update sudo apt install python3.8 python3.8-dev python3.8-venv python3-pip postgresql libpq-dev -y
-
Instale chromium con su driver para los tests sudo apt install chromium-browser chromium-chromedriver
-
Cree un entorno virtual e instale las dependencias de decide python3.8 -m venv pyEnv source pyEnv/bin/activate cd decide python3.8 -m pip install -r requirements.txt
-
Cree la DB y configurela sudo su - postgres -c /etc/init.d/postgresql restart sudo su - postgres -c psql -c "create user decide with password 'decide'" sudo su - postgres psql -c "create database decide owner decide"
cd decide cp local_settings.gactions.py local_settings.py
python3.8 ./manage.py migrate
Finalmente cree un superusuario en decide python3.8 ./manage.py createsuperuser
Presentamos el siguiente cambio a realizar en el sistema:
- Actualizar a Django4
En primer lugar, al encontrar una propuesta de cambio al sistema, en principio por alguien perteneciente a alguno de los dos equipos de desarrollo, esta se debate entre ambas parts mediante la celebración de una reunión acordada previamente entre todos los miembros. Durante el debate se presenta el cambio, se discute su impacto en el proyecto y las ventajas/desventajas de su aplicación.
Una vez se apruebe mediante votación con mayoría simple, el cambio en sí deberá ser documentado y añadido al tablero de GitHub Actions. La nueva tarea se añade a la columna “TO DO” y se asocia a un desarrollador, que será el encargado de realizar la tarea en sí.
A continuación se crea la rama específica para la tarea, dentro del repositorio del part al que pertenezca el encargado de la tarea. Esta rama tendrá el nombre siguiente:
- actualizar-Django4/miembro
A partir de entonces, el encargado debe desarrollar los cambios pertinentes en el sistema para satisfacer el cambio propuesto, subiendo sus cambios periódicamente a su rama e integrándose con la rama master del repositorio. Para hacer esos cambios clona el repositorio con git clone y luego se irá a la rama correspondiente git checkout actualizar-Django4/miembro y cuando estén listos mergerara con git add ., git commit -m “[Label] Titulo \n\n Descripción”. Justo después de esto , se subirá y se hará desde el navegador una pull hacia master y un miembro de tu part será revisor de ella. Tras realizar la pull request mover la tarea del tablero hacia In Review, una vez que el revisor de el visto bueno, se moverá a Done.
Si hay problemas en la funcionalidad , se creará una issue como se ha explicado en la sección de “Visión general de proceso”.
En conclusión, este cuatrimestre hemos aprendido la gestión y evaluación de proyectos grandes a pesar de este cambio de horario en comparación al año pasado el cual el cuatrimestre acaba en enero y se podría tener un baremos más de tiempo.
A continuación, se mencionan los cambios a mejorar y sus respectiva soluciones presentadas:
DJango 4
Como cambios futuros, se puede proponer una adaptación por completo del sistema a una versión de Django más reciente, como la versión 4 (a fecha de hoy, diciembre 2022), ya que en versiones futuras de Ubuntu y Python pueden haber más incompatibilidades.
Despliegue
También se podría añadir una instancia donde los estudiantes pudieran desplegar decide sin problema, ya que durante este curso (2022/23) no ha habido una alternativa oficial a heroku propuesta por el LSI. Se dijo que los profesores se reunirían para discutirlo, para no tener que hacer uso de alternativas de pago como CleverCloud, pero nunca se transmitió nada a los estudiantes.
Para solucionar esa situación, la ETSII podría alojar servidores de despliegue tal y como se realizó en el curso 2020/21 con los servidores avantasia y warzone en la asignatura Sistemas Operativos, del departamento de Lenguajes y Sistemas Informáticos.
Problemas con la wiki
También puede proponerse como cambio, aunque no sea funcional, dejar de usar la wiki para evitar malentendidos y pasarse al servicio de Enseñanza Virtual, el cual, además, ofrece un servicio de notificaciones muy eficiente que avisa a los estudiantes de cada cambio y actualización en la asignatura, en lugar de tener que usar Telegram para estas, ya que obliga a los estudiantes a tener que registrarse en esta para poder tener algunas notificaciones.
Si fuera imposible dejar de usar la wiki, al menos, mantener actualizada la ev con los datos de la wiki.
Si en cambio fuera un problema de software privativo, podría usarse la plataforma de Moodle tal y como ha usado la asignatura de Inteligencia Artificial, del Dpto. Ciencias de la Computación e Inteligencia Artificial.
Este software, al igual que Enseñanza Virtual y a diferencia de la Wiki, si ofrece un servicio de notificaciones por varias vías.