Proyecto final – Ingeniería del Software/ POSIX

A continuación se explicita la letra, reglamento y metodología de evaluación del proyecto final de las asignaturas de Ingeniería de Software y POSIX.

Letra

En función de la siguiente letra, se debe realizar un script en una distribución de GNU/Linux a elección; con permisos para varios usuarios (al menos: de lectura y ejecución para el grupo al que pertenezca el creador) y generar un registro de las veces que el programa es puesto en funcionamiento:

• La Escuela Técnica Superior “Pedro Blanes Viale” necesita de una forma de transmitir a los posibles estudiantes la oferta de cursos terciarios del local. Mediante una pantalla y un teclado al ingreso de la Institución, cada persona debe

1. Ver un listado de los cursos habilitados para el año con un identificador o número (1- Recreación; 2- Redes; 3- Logística …).

2. El usuario puede ingresar el número del curso deseado para que se le muestre información relevante del mismo (Por ejemplo, si ingresa el “1” el script desplegará datos sobre “Recreación”). Es importante, los datos que se muestren -como cantidad de años de duración o especialidad- no deben ser menores a 5 para todos los cursos.

3. Una vez mostrada la información, el programa debe preguntar si desea ingresar al menú con todos los cursos listados y retornar en caso afirmativo.

4. Se recomienda utilizar símbolos para “adornar” el script. Por ejemplo:

echo "===================================="

echo "                                                                                 "

echo "   Escuela Técnica Superior 'Pedro Blanes Viale'    "

echo "                         Mercedes – Soriano                       "

echo "      Oferta de Cursos Terciarios - Año 2025 -        "

echo "                                                                                 "

echo "===================================="

Asimismo, se solicita:

1. Diagrama de Gantt, Kanban o similar para organizar las tareas.

2. ERS con los requerimientos funcionales y no funcionales.

3. Diagrama de Casos de Uso (UML).

4. Plan de testing (al menos, una técnica del mismo).

REGLAS

1. El trabajo debe ser entregado (script, diagramas, etc.) en papel o en digital mediante un mensaje en la plataforma CREA.

2. La fecha límite para la entrega será el 7 de noviembre a las 11:59 PM.

3. Puede ser por alumno o en equipos de hasta 4 integrantes cada uno, siempre que se indique con claridad a los integrantes.

EVALUACIÓN

A los efectos de colocar una calificación, se seguirá la siguiente rúbrica:

Aspecto	Logrado (2 puntos)	Logrado con detalles (1 punto)	No completado o equivocado (0 punto)
1. Funcionalidad del script	El script permite ver la lista de cursos, ingresar un número, mostrar al menos 5 datos por curso y regresar al menú de forma correcta.	El script funciona parcialmente (falla al mostrar información completa o al retornar al menú).	El script no cumple con la funcionalidad básica solicitada.
2. Programación del script	El script está programado de acuerdo con lo estudiado en clase.	El script contiene elementos que no fueron tratados en clase.	Existe evidencia de que el script no fue redactado por los estudiantes.
3. Manejo de permisos y registro	El script se entrega con permisos correctos (grupo con lectura y ejecución) y genera un registro de las ejecuciones.	Se cumple solo uno de los dos aspectos (permisos o registro).	No se cumplen los requisitos de permisos ni de registro.
4. Planificación (Diagrama de Gantt/Kanban o similar)	Se presenta un plan de tareas completo, claro y coherente con el desarrollo del proyecto.	Se presenta un plan incompleto o poco claro.	No se presenta un plan de organización de tareas.
5. Documentación técnica (ERS y Casos de Uso UML)	Se entrega un ERS con requerimientos funcionales y no funcionales bien definidos y un diagrama de casos de uso UML correcto.	Se entrega solo uno de los dos (ERS o UML) o ambos de forma incompleta.	No se entrega documentación técnica.
6. Plan de Testing	Se presenta un plan de pruebas con al menos una técnica clara y aplicada al proyecto.	Se presenta un plan de pruebas poco detallado o no aplicado al proyecto.	No se presenta un plan de testing.