Información general


Tipo de asignatura: obligatoria

Coordinador: Adso Fernández Baena

trimestre:1

Créditos: 6

Profesorado: David Ródenas Picó

Descripción


La asignatura de Laboratorio de Software 2 del primer trimestre de cuarto curso, es la última de las dos asignaturas llamadas Laboratorio de Software. Su impartición está pensada en dedicar 1 ECTS en la parte de teoría y 5 ECTS a practicar los conceptos expuestos en teoría y los adquiridos en el resto de asignaturas.

Esta asignatura consistirá en la creación de una aplicación cliente servidor mediante en grupo respetando la metodología SCRUM y de continuos delivery.

El alumno, además de implementar la aplicación y crear las pruebas de software, captará requisitos para nuevas funcionalidades, los especificará, y hará los roles de Scrum Master y Release Manager.

Todo el dessenvolupament se hará a GitHub, y las contribuciones del equipo se regularán mediante pull requests.

El código se desarrollará con Java Spring + JPA junto servidor, Javascript React + Redux al cliente, y se comunicará con protocolo REST.

Esta asignatura dispone de recursos metodológicos y digitales para hacer posible su continuidad en modalidad no presencial en el caso de ser necesario por motivos relacionados con la Covidien-19. De esta forma se asegurará la consecución de los mismos conocimientos y competencias que se especifican en este plan docente.

Resultados de aprendizaje


A nivel general, esta asignatura contribuye a siguientes resultados de aprendizaje especificados para la materia a la que pertenece (Ingeniería del Software):

- Utilizar de forma apropiada teorías, procedimientos y herramientas en el desarrollo profesional de la ingeniería informática en todos sus ámbitos (especificación, diseño, implementación, despliegue -implantación- y evaluación de productos) de forma que se demuestre la comprensión de los compromisos adoptados en las decisiones de diseño.
- Utilizar las herramientas de un entorno de desarrollo de software para crear y desarrollar aplicaciones.
- Asumir los roles y las funciones del jefe del proyecto y aplicar, en el ámbito de las organizaciones las técnicas de gestión y programación del tiempo, de los costes y de los aspectos financieros, los recursos humanos y del riesgo.
- Demostrar conocimiento y saber aplicar las técnicas apropiadas para modelar y analizar los diferentes tipos de decisiones.
- Gestionar y resolver los problemas y conflictos gracias a la capacidad de generar alternativas o escenarios de futuro convenientemente analizados, integrando los aspectos de incertidumbre y los múltiples objetivos a considerar.
- Controlar versiones y configuraciones del proyecto.
- Tomar iniciativas que generen oportunidades, nuevos objetos o soluciones nuevas, con una visión de implementación de proceso y de mercado, y que implique y haga partícipes a los demás en proyectos a desarrollar (capacidad de actuar de manera autónoma) .
- Especificar, diseñar, implementar, gestionar y mantener sistemas y servicios software complejos y / o críticos.
- Controlar la calidad y diseñar pruebas en la producción de software.
- Definir y gestionar los requisitos de un sistema software.
- Comprender y utilizar eficazmente manuales, especificaciones de productos y otra información de carácter técnico escrita en inglés.
- Planificar y utilizar la información necesaria para un trabajo académico (por ejemplo, para el trabajo final de grado) a partir de una reflexión crítica sobre los recursos de información utilizados. Gestionar la información de manera competente, independiente y autónoma. Evaluar la información encontrada e identificar las lagunas presentes.
- Garantizar que los sistemas TIC de una organización funcionan de forma adecuada, son seguros, y están adecuadamente instalados, documentados, personalizados, mantenidos y sustituidos, y que las personas de la organización reciben un apoyo TIC correcto.
- Dirigir, planificar y coordinar la gestión de la infraestructura informática: hardware, software, redes y comunicaciones.

 

A un nivel más concreto, al finalizar la asignatura el estudiante debe ser capaz de:

- RA1: Crear aplicaciones multiusuario cliente / servidores con interfaz web / mobile.
- RA2: Gestionar el desarrollo de un producto informático en equipo, así como dirigir el equipo para asegurar el correcto desarrollo.
- RA3: Crear y gestionar las pruebas de calidad de un producto informático.
- RA4: Captar y crear los requisitos de un producto informático, analizarlos, definirlos, y presentarlos a miembros externos al desarrollo.
- RA5: Capacidad de mantener un código existente, y añadir nuevas funcionalidades, como parte de un equipo.
- RA6: Presentar y negociar nuevas funcionalidades con miembros internos y externos al desarrollo.
- RA7: Capacidad de coordinar un equipo hasta de un entorno y velar por el correcto desarrollo del software.
- RA8: Vigilar y gestionar nuevas funcionalidades todo interaccionando con otros miembros del equipo y asegurando la correcta correcta calidad. 
- RA9: Aplicar nuevas funcionalidades a la versión de producción así como hacer su despliegue.

 

Metodología de trabajo


El trabajo en esta asignatura, a pesar organizarse en grupos, será de carácter unipersonal.

Cada alumno participará en el desarrollo de una aplicación cliente / servidor con interfaz web / mobile, pero no sólo desde el punto de vista del código, sino también desde el punto de vista de captación de requisitos, y nuevas funcionalidades.

Durante el trimestre se simulará un entorno de trabajo basado en Scrum donde el profesor hará el rol de cabeza / PO (Product Owner).

El curso se organizará en Sprints que definirán un periodo durante el cual el alumno contribuirá al proyecto.

 


Normas de realización de las actividades

Para cada actividad, los docentes informarán de las normas y condiciones particulares que las rijan.

Las actividades unipersonales presuponen el compromiso del estudiante de realizarlas de manera individual. Se considerarán suspendidas todas aquellas actividades en que el estudiante no se ajuste a este compromiso, independientemente de su papel (origen o destino).

Igualmente, las actividades que se deban realizar en grupos presuponen el compromiso por parte de los estudiantes que lo integran de realizarlas en el seno del grupo. Se considerarán suspendidas todas aquellas actividades en las que el grupo no haya respetado este compromiso con independencia de su papel (origen o destino).

Todas las actividades realizadas en esta asignatura se consideran que se realizan de forma unipersonal; el resultado de cada contribución al grupo deberá negociar con el resto del grupo, con preferencia primero al profesor, y luego al Scrum Master si se trata de funcionalidades o al Release Manager si son de calidad y detalles de implementación.

En las actividades realizadas en grupo el docente personalizará la calificación para cada integrante del grupo.

Cualquier actividad no entregada se considerará puntuada con cero puntos.

Es potestativo de los docentes aceptar o no entregas fuera de los plazos que se indiquen. En caso de que estas entregas fuera de plazo se acepten, es potestativo del docente decidir si aplica alguna penalización y la cuantía de la misma.

contenidos


1. Diseño de arquitecturas Cliente / Servidor

Uso de arquitecturas distribuidas en arquitectura cliente / servidor. El servidor establece una interfaz que el cliente usará para comunicarse con el usuario. El servidor y el cliente se comunicaron principalmente con REST.

2. Arquitectura de Inyección de dependencias automática + JPA

Uso de tecnologías de inyección de dependencias automática Spring.
Uso de la API JPA el back-end que automáticamente conecta con una fuente de datos y estructura las tablas y relaciones de forma automática.

3. Arquitectura cliente MVC

Uso de una arquitectura MVC al cliente capaz de gestionar correctamente los datos y la comunicación con el servidor.

4. Project Management

Uso del sistema SCRUM en equipos donde los alumnos deberán presentar los resultados frecuentemente al PO. El profesor hará el rol de PO. Dentro de cada grupo y en rotación uno de los alumnos hará de Scrumm Master.
Los alumnos también harán la captura de requisitos, presentación de funcionalidades y diseño de implementación.

5. Continuous Delivery

Uso de un sistema de continuous delivery. Se usan pruebas de software para trazar y asegurar que se implementa la especificación correctamente. En cada iteración, con un sistema de rotación, cada uno de los alumnos hará de Release Manager, creando y validando la versión a desplegar, y haciendo el despliegue en un entorno real de producción.

6. Calidad y Seguridad

El sistema implantado debe pasar altos estándares de calidad y seguridad. Todo el código pasará por varias code reviews y deberá aplicar los patrones aprendidos en asignaturas anteriores. También todo el código deberá disponer de macetas con una cobertura de casi el 100%, y éstos deberán contemplar todas las excepciones que puedan comprometer el servidor.

Actividades de aprendizaje


PROYECTO EN GRUPO (RA1 - RA9)

El hilo conductor de todo el trimestre es la creación / mantenimiento de una aplicación en grupo aunque la contribución de cada alumno del grupo al proyecto será individual.

Las tareas del alumno durante el trimestre serán:

- Blog: Captación, definición, especificación y presentación de requisitos,
- Como: Interacción con el profesor PO ordenando las historias a implementar,
- QLT: Velar por la calidad y corrección del código propio,
- Test: Crear y mantener tests cuidados que validen con la máxima cobertura posible el código y funcionalidades,
- crevan: proactivamente revisar los pull request otros alumnos del mismo grupo y aprobarlos o hacer recomendaciones de cambios,
- SM: Cuando le corresponda, hacer el rol de scrum master, velar por el correcto dessenvolupament del producto y hacer el informe de progreso resultante de su gestión,
- RM: Cuando le corresponda, hacer el rol de release manager, validar los pull requests, velar por la calidad del producto, y garantizar el correcto uso del repositorio, hacer el informe de progreso resultante de su gestión y despliegue en producción,
- BE: Implementación de back-end,
- FE: Implementación de front-end

Para el desarrollo del proyecto se definirán historias que representarán una funcionalidad a añadir al producto. El alumno deberá ser capaz de hacer todas las etapas de una sola historia.
Nota: todos los alumnos deberán contribuir en todos los roles y todas las tareas. Sin hacerse en grupo, no se podrán dividir las tareas de forma que una historia se implemente entre varios alumnos. Todos los alumnos implementarán front-end, todos back-end, y todos harán captación y definición de historias. Exceptuando el main de la aplicación, la cobertura debe ser del 100%, y todos los tiestos deben estar justificados con la especificación de las funcionalidades.

El grupo se reunirá con el profesor regularmente en períodos de tiempo identificados como Sprints. En cada Sprint se reorganizará las tareas a desarrollar, se evaluará el trabajo realizado, y los roles de scrum master y release manager podrán cambiar de alumno dentro del grupo.

 

EXAMEN INDIVIDUAL (RA1 - RA5)

Prueba individual eminentemente práctica.

Se deberá entregar la resolución de la prueba.

Esta prueba representa el 50% de la calificación final de la asignatura.

Objetivos específicos: El objetivo de esta actividad es evaluar si el estudiante sabe:

- Captar, definir, y especificar requisitos

- Aplicar los principios del diseño orientado a objetos.

- Implementar programas con interfaz gráfica para el usuario y web.

- Persistir objetos a bases de datos relacionales mediante el uso del JPA.

- Implementar pruebas de calidad automatizada.

 

Esta asignatura es de carácter completamente práctico. Reproduce el desarrollo de un software cliente / servidor web de forma iterativa en grupos. Se exige al alumno participar en todas las fases de desarrollo, desde la captación de nuevas ideas y requerimientos hasta el despliegue en un entorno real en internet. El profesor hace el rol de stakeholder de la empresa con la que el alumno ha de negociar las nuevas funcionalidades, los posibles costes, y el resultado. La calidad juega un papel esencial, junto con la trazabilidad. Todas las nuevas funcionalidades se documentan en el blog de la aplicación, de carácter comercial, que se usan de entrada a algoritmos de test automáticos que verifican el correcto funcionamiento de la aplicación. El alumno también será responsable de la calidad del código, tan suya como la de sus compañeros mediante la revisión de código. Se exige al alumno en todos los niveles de aplicación, tanto cliente como servidor, y participar en todos los roles. La evaluación se hará mediante entregas continuas individuales firmadas con llave de hash a un repositorio de código indicado por el profesor, herramientas automáticas de trazado de ciclos de vida de features y code reviews, interacción con el profesor a su rol de stakeholder, y entrevistas / cuestionarios sobre su eficacia en cada rol. Esto hace que a pesar de ser una práctica en grupo, cada evaluación sea individual.

El examen tiene un alcance mucho más reducido, no hay interacción con otras personas, pero tiene por objetivo contrastar que el alumno ha sido capaz de alcanzar los aspectos más técnicos. En este se pide la captación de requisitos, especificación, diseño, implementación, creación de test e integración completa de una propuesta hecha por el profesor sobre una base de código igual o de similares características a la usada en la práctica. Opcionalmente el profesor podrá complementar esta prueba con una prueba teórica sobre partes de la arquitectura básica de la práctica.

En el ámbito competencial la práctica, que en su mayoría se deberá desarrollar en tiempo no presencial, cubre todas las competencias comunes y específicas de la asignatura:
EFB4: interacción con múltiples herramientas y IDEs, tanto editores o navegadores como bases de datos
CIN1: cumple en todos los ciclos de vida con la máxima fiabilidad, seguridad, calidad y conformidad con principios éticos y legales
CIN2: participa en todo el proceso de desarrollo hasta el despliegue, aprendiendo las consecuencias de sus acciones
CIN3: negocia nuevas funcionalidades con profesor y compañeros
CIN4: deben ser capaces de determinar y desplegar la aplicación de acuerdo con los estándares y leyes actuales
CIN5: mantiene y evoluciona la solución en un entorno real
CIN8: aplica altos estándares de pruebas de software, revisa calidad de código, y arquitectura cada funcionalidad
CIN12: despliega la práctica en un entorno web real
CIN13: la aplicación sigue el esquema cliente / servidor mediante protocolos web con base de datos
CIN16: participa en todas las etapas, incluyendo múltiples mejoras de la aplicación
CIN17: diseña e implementa nuevas interfaces de usuario teniendo en cuenta estándares de accesibilidad
CIN18: hay que consideren la normativa nacional, europea e internacional en las condiciones de desarrollo
EIS1: aplica altos estándares de pruebas de software y las liga con los requisitos,
EIS2: hace propuestas de nuevas funcionalidades dado un entorno ya existente y analizando costes
EIS3: soluciona los problemas basados ​​en estándares y tecnologías disponibles
EIS4: busca alternativas de uso adelantándose a problemas de funcionamiento o seguridad con pruebas de software
EIS5: cuando se le asigna el rol, vela por la corrección del método, los riesgos y propone soluciones
EIS6: aplica altos estándares de pruebas de software y se revisa que el código tenga buena calidad y los patrones bien aplicados,
ESI2: atiende a los principios de seguridad y cumplimiento legal en la captación de requisitos y especificación
ESI3: integra propuestas con seguridad completa gracias a un entorno de testing

En el ámbito básico y transversal:
CB.2, CB.4, CT.2: pese a ser evaluación personal, necesitan comunicarse, convencer a otros miembros del equipo y profesor y coordinar el trabajo con un objetivo común
CB.5: ellos mismos establecen los retos y aprenden sus limitaciones
CT.1: toda la documentación, código, y documentos de trabajo deben ser en inglés.

Para superar (aprobar) las actividades evaluativas, los estudiantes deberán demostrar

  • Que han adquirido los conocimientos teóricos relativos a los contenidos de la asignatura y que su comprensión les permite llevarlos a la práctica [MECES-2 punto a, punto c]
  • Que pueden desarrollar soluciones a problemas que, si bien son similares a otros vistos anteriormente, presentan aspectos que son nuevos [MECES-2 punto f]

Sistema de evaluación


La nota final se calculará con las calificaciones de las actividades ponderadas de la forma siguiente:

- EXAMEN INDIVIDUAL: 50%

- PRÁCTICA: PROYECTO EN GRUPO: 50%


El proyecto en grupo, aunque hacerse en grupo, la participación y la nota será individual. Esta será la ponderación de las diversas notas de las diversas tareas llevadas a cabo por el alumno. La nota de cada tarea debe ser 3 o superior, de lo contrario la nota de todo el proyecto en grupo será el mínimo de las notas de cada tarea.

Si la nota del examen es inferior a 3, o la nota de la práctica es inferior a 3, la nota final de la asignatura será la mínima de ellas.

Sólo podrá recuperarse la del examen individual (el proyecto en grupo no se podrá recuperar). El 50% de la nota final de la asignatura será la mayor entre la prueba de recuperación y la obtenida en el examen.
 

Para poder realizar la prueba de recuperación del estudiante deberá cumplir las tres condiciones siguientes:

- La nota de la asignatura es inferior a cinco.

- La nota de la prueba 1 es superior a 3.

- La nota que ha obtenido en cada una de las tareas de la práctica ser 3 o más.

 

Sobre la evaluación de la práctica:

Durante el trimestre, se irá registrando la actividad evaluable de cada alumno que as usuarios para calcular la nota del proyecto en grupo.

En cada sprint se evaluará la participación individual de cada alumno al proyecto así como el dessenvolupament los posibles roles que haya llevado a cabo.

Es imprescindible que el alumno contribuya de forma uniforme en todos los sprints y en todas las tareas. Se valora más la constancia en la contribución en todas las tareas que el resultado final del proyecto en grupo de la asignatura.

Dada la regularidad de los sprint, a discreción del profesor, se da la opción de obviar los resultados de uno o dos sprints de cada alumno.

El número exacto de sprints, y el cambio de rol dentro de cada sprint se dejan a discreción del profesor, que haya todos los alumnos cumplir con todos los roles.

 

Requisitos hardware:

Es necesario que el alumno disponga de un equipo propio con el software y versiones requeridas por el profesor. Deberá disponer del equipo durante las sesiones de teoría y práctica y también durante el examen.

Bibliografía


básico

Spring Documentation - https://spring.io

Agile Software Development: Principles, Patterns, and Practices - Robert C. Martin,

Guía: escritura de código comprobable http://misko.hevery.com/code-reviewers-guide/ -Miško Hevery

Complementario

UML for Java Programmers - Robert C. Martin