Fichas de asignaturas 2013-14
![]() |
INGENIERÍA DE REQUISITOS |
![]() ![]() ![]() |
|
Asignatura |
![]() |
| |
Profesorado |
![]() |
| |
Competencias |
![]() |
| |
Resultados Aprendizaje |
![]() |
| |
Actividades Formativas |
![]() |
| |
Sistemas de Evaluación |
![]() |
| |
Contenidos |
![]() |
| |
Bibliografía |
![]() |
Código | Nombre | |||
Asignatura | 21714041 | INGENIERÍA DE REQUISITOS | Créditos Teóricos | 2,5 |
Título | 21714 | GRADO EN INGENIERÍA INFORMÁTICA | Créditos Prácticos | 5 |
Curso | 3 | Tipo | Obligatoria | |
Créd. ECTS | 6 | |||
Departamento | C137 | INGENIERÍA INFORMÁTICA |
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.
Profesorado
Nombre | Apellido 1 | Apellido 2 | C.C.E. | Coordinador | |
JOSE LUIS | ISLA | MONTES | PROFESOR COLABORADOR | S |
![]() |
Competencias
Se relacionan aquí las competencias de la materia/módulo o título al que pertenece la asignatura, entre las que el profesorado podrá indicar las relacionadas con la asignatura.
Identificador | Competencia | Tipo |
CG01 | Que los estudiantes hayan demostrado poseer y comprender conocimientos en un área de estudio que parte de la base de la educación secundaria general, y se suele encontrar a un nivel que, si bien se apoya en libros de texto avanzados, incluye también algunos aspectos que implican conocimientos procedentes de la vanguardia de su campo de estudio. | GENERAL |
CG02 | Que los estudiantes sepan aplicar sus conocimientos a su trabajo o vocación de una forma profesional y posean las competencias que suelen demostrarse por medio de la elaboración y defensa de argumentos y la resolución de problemas dentro de su área de estudio. | GENERAL |
CG03 | Que los estudiantes tengan la capacidad de reunir e interpretar datos relevantes (normalmente dentro de su área de estudio) para emitir juicios que incluyan una reflexión sobre temas relevantes de índole social, científica o ética. | GENERAL |
CG04 | Que los estudiantes puedan transmitir información, ideas, problemas y soluciones a un público tanto especializado como no especializado | GENERAL |
CG05 | Que los estudiantes hayan desarrollado aquellas habilidades de aprendizaje necesarias para emprender estudios posteriores con un alto grado de autonomía. | GENERAL |
G05 | 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. | ESPECÍFICA |
G08 | Conocimiento de las materias básicas y tecnologías, que capaciten para el aprendizaje y desarrollo de nuevos métodos y tecnologías, así como las que les doten de una gran versatilidad para adaptarse a nuevas situaciones. | ESPECÍFICA |
G09 | 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. | ESPECÍFICA |
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. | ESPECÍFICA |
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 | ESPECÍFICA |
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 | ESPECÍFICA |
Resultados Aprendizaje
Identificador | Resultado |
R1 | 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 |
R3 | Ser capaz de 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 |
R2 | 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 |
Actividades formativas
Actividad | Detalle | Horas | Grupo | Competencias a desarrollar |
01. Teoría | Explicación de los contenidos teóricos de la asignatura |
20 | CG01 CG02 CG03 CG04 CG05 G05 G08 G09 IS01 IS04 IS06 | |
02. Prácticas, seminarios y problemas | Ejercicios grupales sobre elicitación, especificación y análisis de requisitos. |
10 | CG02 CG04 G09 IS01 | |
03. Prácticas de informática | 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. |
30 | CG01 CG02 CG03 CG04 CG05 G05 G08 G09 IS01 IS04 IS06 | |
10. Actividades formativas no presenciales | 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. |
82 | Reducido | CG02 CG03 CG05 G09 IS01 |
12. Actividades de evaluación | Realización de las pruebas escritas de evaluación, así como la exposición y defensa del proyecto de Ingeniería de Requisitos (y trabajo de investigación en su caso). |
3 | CG02 CG03 CG04 CG05 G08 G09 IS01 | |
13. Otras actividades | Evaluación entre iguales y auto-evaluación a través de la herramienta informática EvalCOMIX de aquellas tareas diseñadas para tal fin. |
5 | CG02 CG03 CG04 CG05 G08 G09 IS01 |
Evaluación
Criterios Generales de Evaluación
Para entender los criterios de evaluación, antes es necesario conocer las tareas de evaluación (Tn) y productos/actuaciones de aprendizaje (Pn) sobre los que se van a aplicar: * 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. Exposición y defensa del proyecto. * T2. Investigación sobre algún tópico de interés en el campo de la Ingeniería de Requisitos. - P4. Artículo de investigación. - P5. Exposición y defensa del artículo. * T3. Contestación a preguntas relacionadas con el contenido teórico de la asignatura y resolución de problemas simples. - P6. Ejercicio de examen. CRITERIOS DE EVALUACIÓN * Producto P1 - CR1.1 (Complejidad). Nivel de complejidad del caso de estudio (bajo, medio, alto). - CR1.2 (Comprensibilidad). Los documentos deberán ser comprensibles por clientes, usuarios y desarrolladores. La existencia de un glosario puede ayudar en este sentido. - CR1.3 (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. - CR1.4 (No redundancia). Ausencia de requisitos redundantes o innecesarios. - CR1.5 (Consistencia). Sin conflictos ni contradicciones entre los requisitos o con cualquier otro elemento documentado. Se utiliza una terminología única. - CR1.6 (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. - CR1.7 (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. - CR1.8 (Trazabilidad). Deben poder rastrearse los requisitos hacia delante y hacia atrás. - CR1.9 (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). - CR1.10 (Independencia del diseño y de la implementación). Se debería especificar qué se desea y no cómo se pretende conseguir. - CR1.11 (Calidad de la presentación material). Encuadernación, maquetación, impresión y ortografía. * Producto P2 - CR2.1 (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 - CR2.2 (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. - CR2.3 (Equilibrio de la carga de trabajo). No debe haber un desequilibrio evidente entre las cargas de trabajo individuales. - CR2.4 (Distribución temporal adecuada). No debe haber periodos con una elevada intensidad de trabajo en contraposición con otros demasiado ociosos. * Producto P3 - CR3.1 (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 P4 - CR4.1 (Importancia del tema tratado). Importancia que para la Ingeniería de Requisitos tiene el tema que se aborda. - CR4.2 (Estructura y formato adecuados). El formato deberá ajustarse a una plantilla que se proporcionará previamente. El artículo deberá comprender las siguientes secciones: # Título # Autor # Resumen # Introducción # Apartado 1 … n (desarrollo del trabajo) # Reflexión # Bibliografía - CR4.3 (Extensión). La extensión deberá estar comprendida entre 15 y 25 páginas. - CR4.4 (Relevancia de las obras utilizadas como referencia). Uso de fuentes bibliográficas de reconocido valor científico, por ejemplo: revistas (ACM, IEEE,...…), libros de texto universitarios y actas de congresos estrechamente relacionados con la ingeniería de requisitos (RE, JISBD,...…) - CR4.5 (Correcta citación de fuentes bibliográficas). Utilización de alguna norma estandarizada para la cita o referencia bibliográfica. - CR4.6 (Redacción). Redacción clara, concisa y fidedigna. * Producto P5 - CR5.1 (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 P6 - CR6.1 (Corrección/adecuación de las respuestas). - CR6.2 (Capacidad para el análisis y resolución de problemas). - CR6.3 (Calidad de la expresión escrita).
Procedimiento de Evaluación
Tarea/Actividades | Medios, Técnicas e Instrumentos | Evaluador/es | Competencias 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. | 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. Exposición y defensa del proyecto. TÉCNICAS: - Análisis documental (productos P1 y P2). - Observación (producto P3). INSTRUMENTOS DE EVALUACIÓN: - Lista de control soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (productos P1 y P2). - Escala de valoración soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (producto P3). |
|
CG01 CG02 CG03 CG04 CG05 G05 G08 G09 IS01 IS04 IS06 |
T2. Investigación sobre algún tópico de interés en el campo de la Ingeniería de Requisitos. | MEDIOS (PRODUCTOS/ACTUACIONES DE APRENDIZAJE) - P4. Artículo de investigación. - P5. Exposición y defensa del artículo. TÉCNICAS - Análisis documental (producto P4). - Observación (producto P5). INSTRUMENTOS DE EVALUACIÓN - Lista de control soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (producto P4). - Escala de valoración soportada en Moodle e implementada con la herramienta EvalCOMIX para la evaluación colaborativa (producto P5). |
|
CG01 CG03 CG04 CG05 G05 G08 G09 IS01 IS04 IS06 |
T3. 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. |
|
CG01 CG02 G05 G08 G09 IS01 IS04 IS06 |
Procedimiento de calificación
SISTEMA DE CALIFICACIÓN: PONDERACIONES Y CÁLCULO DE LA NOTA FINAL Sobre un total de 100 puntos, el peso de cada uno de los productos es el siguiente: * P1 (obligatorio): 0-35 puntos, donde: Eval. entre iguales: 90%; autoevaluación: 10% * P2 (obligatorio): 0-5 puntos, donde: Eval. entre iguales: 90%; autoevaluación: 10% * P3 (obligatorio): 0-10 puntos, donde: Eval. entre iguales: 90%; autoevaluación: 10% * P4 (optativo): 0-10 puntos, donde: Eval. entre iguales: 90%; autoevaluación: 10% * P5 (optativo): 0-10 puntos, donde: Eval. entre iguales: 90%; autoevaluación: 10% * P6 (obligatorio): 0-50 puntos, donde: profesor: 100% El profesor supervisará todas la evaluaciones realizadas entre iguales, así como las autoevaluaciones, reservándose el derecho de rectificar 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. CÁLCULO DE LA NOTA FINAL si (P1+P2+P3) > 25 y P6 > 25 nota = (P1+P2+P3+[P4+P5]+P6)/10 en otro caso nota = menor (P1+P2+P3, P6)/10 La nota de la parte aprobada se guardará, en principio, para posteriores convocatorias, teniendo el estudiante que examinarse únicamente de la parte que le quede suspensa.
Descripcion de los Contenidos
Contenido | Competencias relacionadas | Resultados de aprendizaje relacionados |
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). |
CG01 CG02 CG03 CG04 CG05 G05 G08 G09 IS01 IS04 IS06 | |
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. |
CG01 CG02 CG03 CG04 CG05 G05 G08 G09 IS01 IS04 IS06 |
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.
El presente documento es propiedad de la Universidad de Cádiz y forma parte de su Sistema de Gestión de Calidad Docente. En aplicación de la Ley 3/2007, de 22 de marzo, para la igualdad efectiva de mujeres y hombres, así como la Ley 12/2007, de 26 de noviembre, para la promoción de la igualdad de género en Andalucía, toda alusión a personas o colectivos incluida en este documento estará haciendo referencia al género gramatical neutro, incluyendo por lo tanto la posibilidad de referirse tanto a mujeres como a hombres.