Home

Rúbrica para la Evaluación de Trabajos Fin de Grado en Ingeniería Informática relativos al Desarrollo de Sistemas Software de Gestión.

Esta rúbrica descompone el proceso de desarrollo software en diferentes etapas, para cada una de las cuales existe una rúbrica independiente. Cada subrúbrica tiene una ponderación concreta sobre el total del proceso de desarrollo. En función de las características de cada proyecto, se deberá escoger las rúbricas de las etapas que se apliquen a dicho proyecto, calculándose la calificación final como la media ponderada de las calificaciones de las subrúbricas seleccionadas.

	Suspenso	Aprobado	Notable	Sobresaliente
Ingeniería de Requisitos	más de 24 fallos leves, 3 o más graves, o alguno muy grave	entre de 12 y 24 fallos leves y no más de 2 graves	entre 4 y 12 fallos leves y no más de 1 grave	4 o menos fallos leves
Arquitectura y Diseño software	más de 3 graves	más de 4 fallos leves, más de 2 graves	4 o más fallos leves, más de 1 grave	nivel ideal con menos de 4 fallos leves
Implementación	más de 3 graves	más de 4 fallos leves, más de 2 graves	4 o más fallos leves, más de 1 grave	nivel ideal con menos de 4 fallos leves
Pruebas	más de 3 graves	más de 4 fallos leves, más de 2 graves	4 o más fallos leves, más de 1 grave	nivel ideal con menos de 4 fallos leves
Gestión de la Calidad	más de un fallo grave	como mucho 1 fallo grave	como mucho 4 fallos leves	nivel ideal
Gestión de la Configuración Ideal
Metodología de Desarrollo Ideal

Ingeniería de Requisitos

Condiciones Ideales

• Los requisitos funcionales son completos y están correctamente especificados como plantillas de casos de uso, historias de usuario o una técnica propia y adecuada utilizada en la empresa donde se haya desarrollado el Trabajo Fin de Grado, para el caso de Trabajos Fin de Grado desarrollados en empresas.

• Para los requisitos no funcionales, se ha analizado la ISO 25010 y se han especificado de manera correcta y adecuada aquellos que sean de especial interés para la aplicación en desarrollo.

Opcionalmente, en aquellos casos donde sea factible y corresponda, el alumno ha diseñado y ejecutado correctamente un proceso de captura de requisitos y ha derivado los requisitos funcionales de modelos de objetivos.

Fallos Muy Graves

• Los requisitos no están recogidos como historias de usuario, plantillas de casos de uso o mecanismo alternativo utilizado por la empresa o institución donde el alumno haya realizado su Trabajo de Fin de Grado. Los diagramas de casos de uso, sin plantillas que los acompañen, no se consideran suficientes para una adecuada especificación de requisitos.

• No existen evidencias suficientes que permitan constatar el punto anterior.

Fallos Graves

Requisitos Funcionales

• Falta un requisito funcional clave para la aplicación bajo desarrollo. Por ejemplo, un requisito funcional clave sería, para una aplicación tipo Spotify, que se puedan buscar canciones o que se puedan buscar artistas.

• Las especificaciones de los casos de uso o de las historias de usuario no son conformes a las plantillas utilizadas en clase.

• Faltan pasos importantes dentro de los escenarios, como avisar al usuario de un error antes de abortarlo o insertar datos en la base de datos cuando se da de alta un nuevo elemento.

Requisitos No Funcionales

• No se ha revisado ningún catálogo de requisitos no funcionales, como la ISO 25010.

Fallos Leves

Requisitos Funcionales

• Falta un requisito funcional deducible. Por ejemplo, un requisito funcional deducible sería que, si introducimos un dato, es de esperar que tengamos la necesidad de editarlo y, posiblemente, de borrarlo.

• En la descripción del requisito funcional, falta un escenario alternativo. En general, deben considerarse como escenarios alternativos el tratamiento de errores debido a problemas de red, de acceso a la base de datos o la introducción de datos en formato incorrecto. (NOTA: Aquí me surge la duda de cuántos leves se consideran un grave)

• La descripción de los escenarios contiene pequeños errores, pero no son errores de calado ni son abundantes. Por ejemplo, en la descripción del escenario se pide un dato al usuario que se podría obtener de otro sitio, o no se pide una confirmación antes de realizar una determinada acción que sea crítica.

• La descripción de un escenario contiene ambigüedades obvias. Un ejemplo de ambigüedad obvia sería "el sistema muestra un formulario", sin indicar en ningún momento qué campos tiene ese formulario o dónde se puede encontrar el mismo.

Requisitos No Funcionales

• No se ha considerado algún requisito de segundo nivel de la ISO 25010 que es de relevancia para el sistema.

• Un requisito no funcional está especificado de forma vaga o difusa, dificultando su correcta verificación una vez implementado el sistema.

• Un requisito no funcional identificado es un requisito obvio que se puede aplicar a cualquier sistema (e.g., el sistema ha de ser usable, el sistema debe consumir poca memoria).

• Un requisito no funcional no está suficientemente refinado de manera que se materialice en acciones concretas que se puedan ejecutar durante el desarrollo del producto. Por ejemplo, un requisito no funcional que establezca *debe mantenerse la confidencialidad de los expedientes de los usuarios* deberá descomponerse en una serie de acciones concretas que permitan mantener dicha confidencialidad.

• Una decisión sobre los requisitos no funcionales que no está adecuadamente justificada. Por ejemplo, si se establece que la aplicación deberá tener un tamaño menor a 139.49Mb, se tendrá que poder justificar el porqué de ese valor concreto.

• Un requisito no funcional no es verificable mediante un procedimiento claro.

Elementos extra que pueden mejorar la calificación

• Se ha diseñado un proceso de captura de requisitos, considerando potenciales fuentes de requisitos, seleccionando las que se consideren más adecuadas y realizando actividades de captura, tales como entrevistas o cuestionarios, sobre varias de ellas.

• Se ha creado un modelo de objetivos que detalla cómo se descomponen los objetivos principales de la aplicación en subobjetivos, hasta acabar materializándose en requisitos funcionales y, opcionalmente, no funcionales.

Niveles

Sobresaliente (9-10): 4 o menos fallos leves

Notable (7-9): entre 4 y 12 fallos leves y no más de 1 grave

Aprobado (5-6): entre de 12 y 24 fallos leves y no más de 2 graves

Suspenso (0-4): más de 24 fallos leves, 3 o más graves, o alguno muy grave

Arquitectura y Diseño software

Condiciones Ideales

• El diseño del sistema, tanto a nivel arquitectónico como de dominio, está completa, correcta y claramente especificado, utilizando para ello diagramas UML, o cualquier otro lenguaje o mecanismo para la representación de arquitecturas o estructuras software.

• En cuanto al diseño arquitectónico:

  • Se indica el patrón (o patrones) arquitectónicos que se han aplicado en el diseño del sistema y/o subsistemas y se explica como este patrón se aplica de manera concreta al sistema y/o subsistemas.

  • El patrón o patrones arquitectónicos elegidos son adecuados al tipo de sistema.

  • La arquitectura definida da soporte a todos los requisitos especificados.

  • Todos los componentes de la arquitectura definen de manera correcta y completa su contrato (funcionalidad proporcionada y/o requerida):

    • Aquellos que describen su funcionalidad en base a métodos, definen todos los necesarios para implementar su funcionalidad.

    • Aquellos que describen su funcionalidad en base a recursos (como los servicios REST) incluyen su lista de recursos, identificadores, métodos soportados y códigos de error.

• En cuanto al diseño del dominio:

  • Se describen de manera completa y correcta todas las clases que forman el modelo de dominio del sistema.

• Existen evidencias suficientes de que todo el diseño ha sido documentado conforme a la técnica elegida.

• En cuanto al diseño de la persistencia, si la hubiera:

  • Cuando no venga impuesto por las características del proyecto, se justifica el paradigma(s) de almacenamiento de datos seleccionado (ejemplos: relacional, no relacional/NoSQL, ficheros, etc), la justificación es razonable y correcta y se describen de manera adecuada las ventajas e inconvenientes del paradigma seleccionado.

  • En caso de haber tenido que diseñar una base de datos, o sistema de almacenamiento similar, existe un diseño de la base de datos, conforme al paradigma de almacenamiento seleccionado (e.g., relacional, documental), debidamente explicado y justificado de acuerdo con las buenas prácticas del paradigma de almacenamiento empleado. En caso de que este diseño se haya derivado de un modelo conceptual de datos, se valorará que los patrones o técnicas de transformación aplicados sean correctos y estén debidamente justificados.

• Existe un diseño de la organización general de la interfaz gráfica de la aplicación, identificando sus principales componentes y describiendo de manera genérica la navegación por la interfaz.

• Existe un diseño correcto de alto nivel para los algoritmos no triviales (i.e. diferentes a las operaciones CRUD comunes) que sean fundamentales para la aplicación.

Fallos Muy Graves

• La arquitectura no está recogida en forma de diagramas UML o representación similar, sino que se limita a una explicación del patrón arquitectónico genérico aplicado.

• Componentes de la arquitectura sin contrato especificado.

• El modelo de dominio no está recogido como un diagrama UML o representación similar.

• No existe una justificación respecto a la selección del paradigma de almacenamiento de datos aplicado.

• No se incluye un diseño de la base de datos. Se considera la presencia de un diseño sin explicaciones de las partes y decisiones más relevantes del mismo como la no existencia de dicho diseño.

Fallos Graves

• Fallos graves de sintaxis UML: Confundir realización de interfaz con uso de interfaz (interfaz proporcionada vs interfaz requerida), confundir herencia con dependencia, falta repetida de tipos o de calificación de asociaciones, etc.

• Faltan componentes de la arquitectura (para dar soporte a los requisitos).

• Faltan clases en el modelo de dominio (para dar soporte a los requisitos).

• Falta de funcionalidades necesarias en los componentes (métodos o recursos).

• La justificación detrás de la seleccion del paradigma de datos aplicado presenta errores de concepto. Por ejemplo, seleccionar Cassandra para evitar particionar los datos, o una base de datos relacional para aplicar denormalización.

• El diseño de base de datos presenta errores graves en base a las buenas prácticas del paradigma de almacenamiento de datos utilizado.

• No existe un diseño de la organización gráfico.

Fallos Leves

• Fallos leves de sintaxis UML: falta esporádica del tipo de algún atributo o parámetro de un método, etc.

• Falta de algún parámetro en un método.

• Fallos leves en URI o métodos de servicios REST.

• El diseño de base de datos presenta carencias leves en base a las buenas prácticas del paradigma de almacenamiento de datos utilizado.

Puntos Extra

NOTA: Estos elementos pueden servir para mejora la calificación siempre y cuando se alcancen los requisitos mínimos para alcanzar el nivel de aprobado.

• Se ha utilizado algún patrón arquitectónico innovador y no abordado en el grado.

Niveles

Sobresaliente (9-10): nivel ideal con menos de 4 fallos leves

Notable (7-9): 4 o más fallos leves, más de 1 grave

Aprobado (5-6): más de 4 fallos leves, más de 2 graves

Suspenso (0-4): más de 3 graves

Implementación

Se entiende como implementación al conjunto de artefactos creados para construir una aplicación software funcional. Tipos de artefactos típicos incluyen, pero no están limitados a, código fuente, documentación y ficheros de configuración.

Los artefactos típicamente deben ser construidos en base a un diseño, creado y documentado durante una actividad previa. De igual manera, la implementación sirve como entrada para la actividad de pruebas.

Condiciones Ideales

• Se proporcionan evidencias de que se ha completado la implementación. Idealmente esto significa acceso al código fuente de la aplicación completa.

• Se ha respetado el diseño previamente establecido. Si no se ha realizado la implementación de todo el diseño, deberá justificarse el por qué. Por ejemplo, se puede justificar porque implementar la aplicación al completo superaría claramente la complejidad esperada en un TFG.

• El código está completamente documentado de una manera clara y concisa.

• Se proporcionan evidencias de que la aplicación es plenamente funcional y cumple con los requisitos. Por ejemplo, se pueden proporcionar ejecutables, contenedores, máquinas virtuales, páginas web desplegadas, etc.

• Se han enumerado y justificado el conjunto de herramientas o tecnologías utilizadas. Herramientas o tecnologías típicas que se pueden considerar son lenguajes de programación, librerías, sistemas de bases de datos, editores de código, compiladores, gestor de versiones de código, herramientas de diseño, etc.

• Se proporcionan evidencias de cómo se han utilizado las diferentes tecnologías empleadas en la implementación, de manera que se pueda comprobar su correcta utilización. Por ejemplo, en caso de utilizar Spring REST para la implementación de un controlador REST, se describe, con ayuda de un ejemplo extraído del proyecto, como se han utilizado sus anotaciones.

• No se aprecian defectos obvios en la codificación que afecten al rendimiento del sistema.

• No se aprecian defectos obvios (e.g, redundancias claras de código, métodos con nombres poco representativos) en la codificación que afecten a la mantenibilidad del sistema.

• No se aprecian errores obvios en la codificación que afecten a su fiabilidad, esto es que puedan generar comportamientos erróneos o inesperados.

Fallos Muy Graves

• No se ha proporcionado ninguna evidencia de que se ha realizado una implementación de la aplicación.

• Existe una completa desconexión entre la implementación y el diseño previamente realizado.

Fallos Graves

• La implementación no abarca por completo el diseño, y no se justifica debidamente.

• La documentación en el código es inexistente.

• No se proporciona un ejemplo de uso de alguna de las tecnologías utilizadas en la implementación. El ejemplo tiene que ser extraído de la codificación realizada.

• Un algoritmo no trivial no ha sido debidamente descrito.

Fallos Leves

• En general el código está documentado, pero existe alguna laguna.

• En la memoria se menciona el uso de alguna tecnología o herramienta que no ha sido debidamente justificada.

• Deficiencia en el código que afecta al rendimiento, mantenibilidad o fiabilidad

Puntos Extra

• Se ha seguido algún estándar de codificación. Además, se han utilizado herramientas para controlar la aplicación de dicho estándar.

• Se proporcionan evidencias de que ha habido esfuerzos para optimizar el rendimiento del código.

• En aplicaciones con despliegues complejos, se ha proporcionado al tribunal algún mecanismo automatizado de despliegue para poder probar la aplicación. Por ejemplo, un script que realice automáticamente el despliegue de los componentes de una aplicación de varias capas. Otro ejemplo sería una máquina virtual con el entorno ya desplegado.

Niveles

Sobresaliente (9-10): nivel ideal con menos de 4 fallos leves

Notable (7-9): 4 o más fallos leves, más de 1 grave

Aprobado (5-6): más de 4 fallos leves, más de 2 graves

Suspenso (0-4): más de 3 graves

Pruebas

Condiciones Ideales

• Se ha llevado a cabo un proceso de pruebas de la aplicación bien planificado y acorde a las características del sistema. Por bien planificado se entiende que se hayan definido y justificado los niveles de prueba a aplicar y se hayan definido las técnicas y tecnologías a utilizar en cada nivel. A través de este proceso se ha validado el cumplimiento de todos los requisitos especificados para la aplicación.

• La nomenclatura y organización de las clases de prueba sigue los estándares adecuados (por ejemplo, guardarlos en la carpeta src/test/java cuando se usa Maven, etc.)

• Las tecnologías aplicadas para cada nivel de pruebas son adecuadas.

• Existen evidencias suficientes acerca del proceso de pruebas aplicado, incluyendo tanto la existencia de pruebas como de haberlas superado correctamente.

• Pruebas unitarias

  • Se diseñan y aplican correctamente pruebas unitarias a aquellas partes del software que se considere necesario. Por ejemplo, métodos que implementen algoritmos no triviales.

• Pruebas de integración

  • Cada requisito funcional (caso de uso o historia de usuario) está probado en todos sus escenarios posibles.

  • En caso de haber diseñado un back-end, sus métodos públicos han sido correctamente probados.

• Pruebas de sistema

  • Si existen requisitos no funcionales, se han diseñado y aplicado pruebas para su validación.

• Pruebas de aceptación

  • Se explica la estrategia utilizada para llevar a cabo este tipo de pruebas.

  • Las pruebas de aceptación cubren la total funcionalidad de la aplicación.

• Se ha controlado el porcentaje de cobertura de las pruebas utilizando herramientas adecuadas.

Fallos Muy Graves

• No se realizan pruebas de alguno de los niveles o no se justifica debidamente su ausencia.

• Existen casos de prueba fallidos.

• La implementación de los propios casos de prueba es errónea, esto es, no se realizan las comprobaciones adecuadas. Por ejemplo, al eliminar un elemento de una lista, no se comprueba que la lista ha reducido su tamaño.

Fallos Graves

• Falta algún caso de prueba obvio. Por ejemplo, en pruebas que requieran la introducción de datos, dejar algún campo sin valor.

• Ubicación errónea de las clases de prueba dentro del proyecto de desarrollo.

Fallos Leves

• Falta algún caso de prueba no obvio.

• Nombre erróneo de clase de prueba o de paquete de clases de prueba.

Elementos extra que pueden mejorar la calificación

NOTA: Estos elementos pueden servir para mejora la calificación siempre y cuando se alcancen los requisitos mínimos para alcanzar el nivel de aprobado.

Utilización de frameworks de prueba cuya base tecnológica no haya sido vista durante el grado (usar PHPUnit, teniendo en cuenta que sí se ha utilizado previamente JUnit, no se considera un framework innovador en este sentido).

Niveles

Sobresaliente (9-10): nivel ideal con menos de 4 fallos leves

Notable (7-9): 4 o más fallos leves, más de 1 grave

Aprobado (5-6): más de 4 fallos leves, más de 2 graves

Suspenso (0-4): más de 3 graves

Gestión de la Calidad

Se entiende como Gestión de la Calidad a las actividades que se realizan durante el transcurso del proyecto para asegurar que el producto final cumple con los requisitos establecidos.

La Gestión de la Calidad tiene especial relevancia en entornos profesionales y empresariales, pero su aplicación en TFGs queda limitada porque generalmente son trabajos realizados por una persona. Por lo tanto, la evaluación de la Gestión de la Calidad se centrará en las labores que típicamente podrá realizar un alumno trabajando en solitario.

Condiciones Ideales

• El alumno ha establecido requisitos de calidad, utilizando por ejemplo el estándar ISO 25010.

• El alumno ha establecido algún mecanismo de gestión de la calidad para el aseguramiento del cumplimiento de los requisitos de calidad establecidos. Un ejemplo puede ser establecer un objetivo de calidad (e.g. Quality Gate), y utilizar alguna herramienta de análisis estático de código que verifique si dicho objetivo se está cumpliendo.

Fallos Muy Graves

• No se ha proporcionado ninguna evidencia de que se ha realizado algún tipo de gestión o control de la calidad.

Fallos Graves

• Se han establecido objetivos de calidad arbitrarios o no debidamente justificados.

• No se proporciona ninguna justificación o evidencia sobre el cumplimiento de los criterios de calidad.

Fallos Leves

• Algún criterio de calidad establecido no se cumple.

Puntos Extra

Si el TFG se ha realizado dentro de un contexto empresarial con actividades sobre gestión de la calidad ya establecidas, se valorará positivamente si el alumno se ha integrado dentro de éstas. Por ejemplo, el alumno ha podido participar en inspecciones internas de código, auditorías, etc.

Niveles

Sobresaliente (9-10): nivel ideal

Notable (7-9): como mucho 4 fallos leves

Aprobado (5-6): como mucho 1 fallo grave

Suspenso (0-4): más de un fallo grave

Gestión de la Configuración

Condiciones Ideales

1. El alumno ha utilizado correctamente un software de control de versiones.

2. El alumno ha seguido una política clara de gestión de la configuración.

3. El alumno ha utilizado de manera adecuada alguna herramienta para la gestión de dependencias.

4. El alumno proporciona evidencias suficientes que permitan evaluar los elementos anteriores.

Opcionalmente, se valorará que el alumno haya utilizado un entorno de integración y despliegue continuo.

Fallos Muy Graves

• No se ha utilizado ningún software de control de versiones.

• El alumno no ha utilizado ninguna herramienta para la gestión de dependencias, habiendo necesidad de ello.

• El alumno no proporciona ninguna evidencia que permita evaluar los elementos pertinentes.

Fallos Graves

• El alumno no ha seguido ninguna regla de gestión de la configuración, creándose las versiones y los elementos de gestión de la configuración, como las ramas, de manera desordenada y no sistematizada.

Fallos Leves

• Un elemento del sistema de control de versiones no es conforme a las reglas de gestión de la configuración establecidas. Por ejemplo, hay una rama mal nombrada, o una determinada historia de usuario carece de una rama asociada.

Metodología de Desarrollo

Condiciones Ideales

1. El alumno ha seguido una metodología software adecuada al tipo de proyecto que estaba desarrollando.

2. La metodología estaba bien definida y establecía unas pautas de trabajo claras.

3. El alumno describe de manera concreta cómo se ha aplicado la metodología escogida al proyecto desarrollado. Por ejemplo, en el caso de un desarrollo iterativo, especifica cuántas iteraciones ha habido y qué se ha hecho en ellas.

4. La metodología cubre adecuadamente todas las fases del ciclo de vida software que sean exigibles a un proyecto en cuestión. Por ejemplo, ciertos proyectos desarrollados en empresa podrían carecer de una fase de ingeniería de requisitos, mientras que ciertos proyectos personales podrían carecer de una fase de despliegue, al carecer de acceso a servidores.

5. El alumno proporciona evidencias suficientes que permitan evaluar el seguimiento de la metodología.

Fallos Muy Graves

• El alumno no proporciona ninguna evidencia que permita evaluar este apartado.

• No se ha utilizado ninguna metodología para el desarrollo del producto software.

• No existe ningún indicio de cómo se ha particularizado la metodología escogida al desarrollo del producto.

Fallos Graves

• La metodología utilizada es claramente inadecuada para el proyecto desarrollado.

• La metodología es muy básica y apenas establece pautas para el desarrollo del producto.

• Una fase del ciclo de vida software, por ejemplo, la fase de pruebas, no está cubierta por la metodología.

Fallos Leves

• La elección de la metodología es discutible, pero no claramente inadecuada.

• Algún elemento de la metodología no está correctamente aplicado. Por ejemplo, en el caso de Scrum, los sprints no son de duración fija.

• Para un determinado elemento de la metodología, no está claro cómo se ha aplicado concretamente durante el desarrollo del producto software. Por ejemplo, en el caso de Scrum, no queda claro quién ejercía de Product Owner.

• Las evidencias proporcionadas generan alguna duda sobre la correcta aplicación de la metodología.