Programa Docente de 21714041 - INGENIERÍA DE REQUISITOS

Asignatura:

Titulación:

Centro:

Dep./Área:

Compartidas:

Tipo estudio:

Ofertada:

Vigencia:

Créd. teoría:

Créd. práctica:

Créd. ECTS:

Tipo Asignatura:

Módulo:

Materia:

Curso:

Matric. 2024-25:

Matric. 2025-26:

Duración:

Idioma:

Mostrar asignatura

REQ. Y RECOM.
PROFESORADO
IDIOMAS
MOVILIDAD
RESULTADOS FORM./APREN.
RES. DE APRENDIZAJE
ACT. FORMATIVAS
SIST. DE EVALUACIÓN
DESC. DE CONTENIDOS
BIBLIOGRAFÍA
COMENTARIOS
MEC. DE CONTROL

Requisitos Previos

1. Haber adquirido las competencias que se trabajan en la asignatura de Ingeniería del Software.
2. Tener acceso al curso de la asignatura en el campus virtual.

Recomendaciones

1. Asistencia a clase y participación activa.
2. Estudio y trabajo continuado de la materia.
3. Realización de las actividades, ejercicios prácticos y trabajos que se propongan de acuerdo con los criterios de calidad exigidos en la asignatura.

Movilidad Nacional (SICUE)

Sí

Presencial Combinada Virtual

Movilidad Internacional

Sí

Presencial Combinada Virtual

Estudiante Visitante Nacional

Sí

Número de plazas

Presencial
Combinada
Virtual

Oferta en Lengua Extranjera

Sí

Idioma

Inglés.
Francés.
Italiano.
Alemán.
Ruso.
Árabe.
Griego.

Modo Impartición

A impartir sólo en ese idioma según memoria (exclusividad).
A impartir en grupo dedicado a ese idioma.
A impartir en grupo mixto (un mismo grupo con ambos idiomas).

Nivel Requerido

Documento	Primer Apellido	Segundo Apellido	Nombre	Categoria	Coordinador
24238611S	ISLA	MONTES	JOSE LUIS	PROFESOR CONTRATADO DOCTOR

Id. Compentencia	Orden	ID	Resultado formación y aprendizaje	Competencia
29106	2	CG05	Capacidad para concebir, desarrollar y mantener sistemas, servicios y aplicaciones informáticas empleando los métodos de la ingeniería del software como instrumento para el aseguramiento de su calidad, de acuerdo con los conocimientos adquiridos según lo establecido en el apartado 5 de este anexo.	COMPETENCIA GENERAL
29108	2	CG09	Capacidad para resolver problemas con iniciativa, toma de decisiones, autonomía y creatividad. Capacidad para saber comunicar y transmitir los conocimientos, habilidades y destrezas de la profesión de Ingeniero Técnico en Informática.	COMPETENCIA GENERAL
29109	3	IS01	Capacidad para desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teorías, principios, métodos y prácticas de la Ingeniería del Software.	COMPETENCIA ESPECÍFICA
29110	3	IS04	Capacidad de identificar y analizar problemas y diseñar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teorías, modelos y técnicas actuales	COMPETENCIA ESPECÍFICA
29111	3	IS06	Capacidad para diseñar soluciones apropiadas en uno o más dominios de aplicación utilizando métodos de la ingeniería del software que integren aspectos éticos, sociales, legales y económicos	COMPETENCIA ESPECÍFICA
33059	3	IS02	Capacidad para valorar las necesidades del cliente y especificar los requisitos software para satisfacer estas necesidades, reconciliando objetivos en conflicto mediante la búsqueda de compromisos aceptables dentro de las limitaciones derivadas dl coste, del tiempo, de la existencia de sistemas ya desarrollados y de las propias organizaciones	COMPETENCIA ESPECÍFICA
33180	4	CT1	Trabajo en equipo: capacidad de asumir las labores asignadas dentro de un equipo, así como de integrarse en él y trabajar de forma eficiente con el resto de sus integrantes	COMPETENCIA TRANSVERSAL

ID/ Orden	Resultado
1	Ser capaz de desarrollar, mantener y evaluar servicios y sistemas software que satisfagan todos los requisitos del usuario y se comporten de forma fiable y eficiente, sean asequibles de desarrollar y mantener y cumplan normas de calidad, aplicando las teorías, principios, métodos y prácticas de la Ingeniería del Software
2	Ser capaz de identificar y analizar problemas y diseñar, desarrollar, implementar, verificar y documentar soluciones software sobre la base de un conocimiento adecuado de las teorías, modelos y técnicas actuales
3	Ser capaz de elaborar una especificación de requisitos de software aplicando un entorno metodológico de Ingeniería de Requisitos.

Total de actividades de docencia presencial:

Total de otras actividades:

Total de la asignatura:

Tipo actividad formativa	Código	Descripción	Horas	Detalle
1	01	Teoría	20	Explicación de los contenidos teóricos de la asignatura
2	02	Prácticas, seminarios y problemas	10	Ejercicios grupales sobre elicitación, especificación, análisis, verificación y validación de requisitos.
3	03	Prácticas de informática	30	Soporte informático para el entorno metodológico utilizado durante la elaboración de un proyecto de Ingeniería de Requisitos para Sistemas Software en el marco de una organización real.
10	10	Actividades formativas no presenciales	82,00	Estas actividades se corresponden con las horas de trabajo personal del alumno, incluyendo las horas de estudio de los contenidos teóricos y prácticos de la asignatura, así como la realización de problemas y trabajos propuestos.
12	12	Actividades de evaluación	3,00	Realización de las pruebas escritas de evaluación, así como la exposición y defensa del proyecto de Ingeniería de Requisitos.
13	13	Otras actividades	5,00	Evaluación entre iguales y auto-evaluación de aquellas tareas diseñadas para tal fin.

Procedimientos de Evaluación

ID/ Orden	Tarea / Actividad	Medios, Técnicas e Instrumentos	Ponderación
1	T1. Proyecto colaborativo para la aplicación de un entorno metodológico de ingeniería de requisitos en el marco de una organización real.	MEDIOS (PRODUCTOS/ACTUACIONES DE APRENDIZAJE): - P1. Documento de Requisitos del Sistema (DRS), Documento de Análisis del Sistema (DAS) y Registro de Conflictos y Defectos. - P2. Informe detallado de las tareas realizadas por cada uno de los componentes del equipo, reuniones mantenidas (presenciales o virtuales) y actividades de coordinación llevadas a cabo. Representación del Diagrama de Gantt. - P3. Prototipo de la interfaz - P4. Exposición y defensa del proyecto. - P5. Grabación de entrevistas. TÉCNICAS: - Análisis documental (productos P1, P2, P3 y P5). - Observación (producto P4). INSTRUMENTOS DE EVALUACIÓN: - Lista de control soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (productos P1, P2 y P3). - Escala de valoración soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (producto P4).	50 %
2	T2. Contestación a preguntas relacionadas con el contenido teórico de la asignatura y resolución de problemas simples.	MEDIOS (PRODUCTOS/ACTUACIONES DE APRENDIZAJE) - P6. Ejercicio de examen. TÉCNICAS - Análisis documental. INSTRUMENTOS DE EVALUACIÓN - Preguntas a desarrollar y ejercicios prácticos.	50 %

ID/ Orden

Tarea / Actividad

Medios, Técnicas e Instrumentos

Ponderación

T1. Proyecto colaborativo para la aplicación de un entorno metodológico de ingeniería de requisitos en el marco de una organización real.

MEDIOS (PRODUCTOS/ACTUACIONES DE APRENDIZAJE):

- P1. Documento de Requisitos del Sistema (DRS), Documento de Análisis del Sistema (DAS) y Registro de Conflictos y Defectos.

- P2. Informe detallado de las tareas realizadas por cada uno de los componentes del equipo, reuniones mantenidas (presenciales o virtuales) y actividades de coordinación llevadas a cabo. Representación del Diagrama de Gantt.

- P3. Prototipo de la interfaz

- P4. Exposición y defensa del proyecto.

- P5. Grabación de entrevistas.

TÉCNICAS:

- Análisis documental (productos P1, P2, P3 y P5).

- Observación (producto P4).

INSTRUMENTOS DE EVALUACIÓN:

- Lista de control soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (productos P1, P2 y P3).

- Escala de valoración soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (producto P4).

50 %

T2. Contestación a preguntas relacionadas con el contenido teórico de la asignatura y resolución de problemas simples.

MEDIOS (PRODUCTOS/ACTUACIONES DE APRENDIZAJE)

- P6. Ejercicio de examen.

TÉCNICAS

- Análisis documental.

INSTRUMENTOS DE EVALUACIÓN

- Preguntas a desarrollar y ejercicios prácticos.

50 %

Criterios de Evaluación

== TAREAS (Tn) Y PRODUCTOS CONCRETOS (Pn) A EVALUAR ==

* T1. Proyecto colaborativo para la aplicación de un entorno metodológico de ingeniería de requisitos en el marco de una organización real.

- P1. Documento de Requisitos del Sistema (DRS), Documento de Análisis del Sistema (DAS) y Registro de Conflictos y Defectos.
- P2. Informe detallado de las tareas realizadas por cada uno de los componentes del equipo, reuniones mantenidas (presenciales o virtuales) y actividades de coordinación llevadas a cabo. Representación del Diagrama de Gantt.
- P3. Prototipo de la interfaz.
- P4. Exposición y defensa del proyecto.
- P5. Grabación de entrevistas realizadas (optativo)

* T2. Contestación a preguntas relacionadas con el contenido teórico de la asignatura y resolución de problemas simples.

- P6. Ejercicio de examen.

== CRITERIOS GENERALES DE EVALUACIÓN ==

* Producto P1

- (Complejidad) Nivel de complejidad del caso de estudio (bajo, medio, alto).
- (Comprensibilidad) Los documentos deberán ser comprensibles por clientes, usuarios y desarrolladores. La existencia de un glosario puede ayudar en este sentido.
- (Corrección) Se puede considerar que la especificación es totalmente correcta cuando:
   # Se ha utilizado la metodología y la herramienta de gestión de requisitos adecuadamente.
   # No hay errores en la descripción de los requisitos.
   # No hay errores en la representación de los modelos de análisis y la descripción de sus elementos (tipos, roles, atributos, asociaciones, operaciones).
   # Las dependencias entre los requisitos, así como entre éstos y los elementos utilizados en el análisis, son correctas. No hay errores en las matrices de rastreabilidad generadas.
- (No redundancia) Ausencia de requisitos redundantes o innecesarios.
- (Consistencia) Sin conflictos ni contradicciones entre los requisitos o con cualquier otro elemento documentado. Se utiliza una terminología única.
- (Completitud) Se puede considerar que la especificación es completa cuando:
   # Están especificados todos los requisitos elicitados.
   # Están todas las respuestas del sistema a entradas tanto válidas como inválidas.
   # No falta ninguna sección por documentar.
   # Están documentadas todas las sesiones realizadas para la elicitación/validación de requisitos.
   # Están especificados todos los artefactos de análisis.
- (Verificabilidad) Los requisitos deben estar especificados de manera que pueda comprobarse que el sistema final cumple con ellos mediante un proceso finito y de coste razonable.
- (Trazabilidad) Deben poder rastrearse los requisitos hacia delante y hacia atrás.
- (Prioridad y estabilidad) Los requisitos deben estar anotados con prioridades (indicando la importancia y urgencia para el cliente) y estabilidad (probabilidad de que un requisito cambie).
- (Independencia del diseño y de la implementación) Se debería especificar qué se desea y no cómo se pretende conseguir.
- (Calidad de la presentación material) Encuadernación, maquetación, impresión y ortografía.

* Producto P2

- (Estructuración, precisión y claridad) Descripción precisa y clara de las actividades realizadas y de las reuniones de equipo planificadas indicando: momento, lugar, personas participantes y responsables, resultados obtenidos, problemas surgidos y soluciones adoptadas, etc. Diagrama de Gantt donde se pueda ver con claridad la secuencia temporal de actividades/reuniones y sus participantes
- (Capacidad de coordinación) Valorar la capacidad para estructurar el trabajo, asignar responsabilidades y establecer dependencias entre tareas, indicando cuándo empieza y termina cada una de ellas.
- (Equilibrio de la carga de trabajo) No debe haber un desequilibrio evidente entre las cargas de trabajo individuales.
- (Distribución temporal adecuada) No debe haber periodos con una elevada intensidad de trabajo en contraposición con otros demasiado ociosos.

* Producto P3

- (Adecuación a los requisitos) El prototipo refleja adecuadamente los requisitos especificados y permite la validación de la interfaz.
- (Usabilidad) El prototipo posee un alto grado de usabilidad

* Producto P4

- (Calidad de la exposición y defensa pública) Para su valoración se tendrá en cuenta:
   # Exposición organizada de manera clara y lógica.
   # Adecuación del lenguaje, tono y volumen de voz.
   # Expresión corporal, gestual y mirada.
   # Corrección ortográfica y gramatical.
   # Capacidad de argumentación.
   # Adaptación al tiempo de exposición.
   # Énfasis en los puntos más importantes.

* Producto P5

- Lenguaje, forma y contenido adecuado.
- Objetivo y contexto bien determinado.
- Selección idónea de las personas a entrevistar.
- Correcta apertura, desarrollo y terminación.

* Producto P6

- (Teoría) Corrección y adecuación de las respuestas a las preguntas teóricas planteadas.
- (Problemas) Capacidad para el análisis y resolución de los problemas planteados

== PROCEDIMIENTO DE CALIFICACIÓN ==

En aquellos productos de aprendizaje que sean evaluados colaborativamente se atenderá al siguiente reparto de porcentajes:

   - Autoevaluación: 10%
   - Evaluación entre iguales: 90%

La evaluación entre iguales será obligatoria. El profesor supervisará todas la evaluaciones realizadas, reservándose el derecho de aplicar un factor de corrección [0.8-1.2] para modificar aquellas valoraciones que no estén convenientemente justificadas, penalizar a aquellos/as evaluadores/as que no actúen con honestidad e incentivar a aquellos/as que mejor argumenten sus evaluaciones. También podrá aplicar dicho factor de corrección si el resultado obtenido no se ajusta a la realidad del trabajo realizado, bien sea como consecuencia de la valoración de algún aspecto no contemplado inicialmente en la lista de chequeo o de la valoración incorrecta de ítems existentes. 

// CÁLCULO DE LA NOTA FINAL

P1: DRS y DAS proyecto
P2: Informe actividades proyecto
P3: Prototipo
P4: Presentación proyecto
P5: Grabación entrevistas //optativo
P6: Examen
FC: Factor de corrección a criterio del profesor para ajustar el resultado del proyecto y la evaluación entre iguales realizada [0,80 -1,20]

T1 = FC*(40%*P1 + 10%*P2 + 30%*P3 + 20%*P4 + [10%*P5])
T2 = P6

if T1 >= 50 & T2 >= 50
      Nota_Final = media(T1,T2)
else
      if media(T1,T2) >= 50
            Nota_Final = 40
      else
            Nota_Final = media(T1,T2)
      endif
endif

La nota de la parte aprobada se guardará para cualquier convocatoria posterior, teniendo el estudiante que examinarse únicamente de la parte suspensa.

// EVALUACIÓN GLOBAL

Siguiendo la normativa de la Universidad de Cádiz, el alumnado podrá solicitar la evaluación global. Este mecanismo proporcionará al alumnado la posibilidad de alcanzar la máxima calificación posible mediante un examen y/o ejercicios de carácter práctico acordados en el momento de la solicitud. El tipo de tareas, pruebas y criterios de evaluación serán los mismos que para el resto del alumnado, con la salvedad de que, en este caso, la valoración entre iguales no procederá y todos los productos entregados serán íntegramente valorados por el profesorado. Debido a la complejidad y el esfuerzo necesario que puede conllevar para el estudiante la entrega de los productos a evaluar, es muy importante que se ponga en contacto con el equipo docente con la máxima antelación posible.

ID/ Orden	Temario	Descripción
1	PROGRAMA DE TEORÍA: UNIDAD 1. VISIÓN GENERAL - Introducción. - Definición de Ingeniería de Requisitos (IR). - Motivación de la IR. - Concepto y tipos de requisitos. - La IR en el ciclo de vida del software. - Modelos de proceso de la IR. - Modelo de madurez de proceso de la IR. - Gestión de requisitos. UNIDAD 2. OBTENCIÓN DE REQUISITOS - Introducción. - Objetivos de la elicitación de requisitos. - Obstáculos. - Técnicas de elicitación. - Metodología para la elicitación de requisitos. UNIDAD 3. ESPECIFICACIÓN DE REQUISITOS - El estándar IEEE 830-1998. - Otros estándares y guías relacionadas con la IR. - Especificación formal de requisitos. UNIDAD 4. ANÁLISIS DE REQUISITOS. MODELADO DE SISTEMAS SOFTWARE CON UML - Introducción. - Metodología para el análisis de requisitos. - Modelado conceptual de datos. - El lenguaje OCL (Object Constraint Language). - Modelado del comportamiento.
2	PROGRAMA DE PRÁCTICAS: UNIDAD 1. INTRODUCCIÓN A LA GESTIÓN DE REQUISITOS CON LA HERRAMIENTA REM. UNIDAD 2. PROYECTO PARA LA ESPECIFICACIÓN DE REQUISITOS DE UN SISTEMA. - Realización de tareas básicas para la elicitación y especificación de requisitos en el marco de una metodología concreta. - Construcción del Documento de Requisitos del Sistema (DRS). UNIDAD 3. PROYECTO PARA EL ANÁLISIS DE REQUISITOS DE UN SISTEMA. - Realización de tareas básicas para el análisis de requisitos en el marco de una metodología concreta. - Construcción del Documento de Análisis del Sistema (DAS).
3	SEMINARIOS - La IR y el Diseño Centrado en el Usuario. - Prototipado - Problemas sobre modelado estático/dinámico y OCL

ID/ Orden

Temario

Descripción

PROGRAMA DE TEORÍA:

UNIDAD 1. VISIÓN GENERAL

- Introducción.
- Definición de Ingeniería de Requisitos (IR).
- Motivación de la IR.
- Concepto y tipos de requisitos.
- La IR en el ciclo de vida del software.
- Modelos de proceso de la IR.
- Modelo de madurez de proceso de la IR.
- Gestión de requisitos.

UNIDAD 2. OBTENCIÓN DE REQUISITOS

- Introducción.
- Objetivos de la elicitación de requisitos.
- Obstáculos.
- Técnicas de elicitación.
- Metodología para la elicitación de requisitos.

UNIDAD 3. ESPECIFICACIÓN DE REQUISITOS

- El estándar IEEE 830-1998.
- Otros estándares y guías relacionadas con la IR.
- Especificación formal de requisitos.

UNIDAD 4. ANÁLISIS DE REQUISITOS. MODELADO DE SISTEMAS SOFTWARE CON UML

- Introducción.
- Metodología para el análisis de requisitos.
- Modelado conceptual de datos.
- El lenguaje OCL (Object Constraint Language).
- Modelado del comportamiento.

PROGRAMA DE PRÁCTICAS:

UNIDAD 1. INTRODUCCIÓN A LA GESTIÓN DE REQUISITOS CON LA HERRAMIENTA REM.

UNIDAD 2. PROYECTO PARA LA ESPECIFICACIÓN DE REQUISITOS DE UN SISTEMA.

- Realización de tareas básicas para la elicitación y especificación de requisitos en el marco de una metodología concreta.
- Construcción del Documento de Requisitos del Sistema (DRS).

UNIDAD 3. PROYECTO PARA EL ANÁLISIS DE REQUISITOS DE UN SISTEMA.

- Realización de tareas básicas para el análisis de requisitos en el marco de una metodología concreta.
- Construcción del Documento de Análisis del Sistema (DAS).

SEMINARIOS

- La IR y el Diseño Centrado en el Usuario.
- Prototipado
- Problemas sobre modelado estático/dinámico y OCL

Bibliografía

Bibliografía Básica

Sommerville, I. Ingeniería del Software, 6ª ed. Addison Wesley, 2002.
Sommerville, I., Sawyer, P. Requirements Engineering. A good practice guide. Wiley, 1997
Kotonya, G., Sommerville, I. Requirements Engineering: Processes and Techniques. John Wiley & Sons, 1998
Durán, A. Un Entorno Metodológico de Ingeniería de Requisitos para Sistemas de Información. Tesis Doctoral, Universidad de Sevilla, 2000
 
Bibliografía Específica

Booch, G., Rumbaugh, J., Jacobson, I. El Lenguaje Unificado de Modelado. Addison-Wesley, 1999.
Booch, G., Rumbaugh, J., Jacobson, I. El Lenguaje Unificado de Modelado: Manual de Referencia. Addison-Wesley, 1999.
OMG. Unified Modeling Language (UML).  http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML
 
Bibliografía Ampliación

Robertson, S., Robertson, J. Mastering the Requirements Process. Addison-Wesley, 1999
Sutcliffe, A. User-Centred Requirements Engineering. Theory and Practice. Springer, 2002
Wieringa, R. J. Requirements Engineering. Frameworks for Understanding. John Wiley, 1996
Wiegers, K. Software Requirements. Microsoft Press, 1999.
Toval, A., Nicolás, J. Ingeniería del Software. Gestión de Requisitos. DM, ICE-Universidad de Murcia, 1999
Booch, G., Rumbaugh, J., Jacobson, I. El Proceso Unificado de Desarrollo de Software. Addison-Wesley, 1999.
Larman, C., UML y Patrones. Una Introducción al Análisis y Diseño Orientado a Objetos y al Proceso Unificado, 2ª ed., Prentice Hall, 2003.
Maciaszek, L.A., Requeriments Analysis and Systems Design. Developing Information Systems with UML. Addison-Wesley, 2001.

Comentarios / Observaciones Adicionales

Buscar otra Asignatura

UniversidaddeCádiz

Programa Docente de 21714041 - INGENIERÍA DE REQUISITOS