Facultad de Ingeniería y Ciencias Aplicadas

Ingeniería en Sistemas de Computación e Informática

ACI480 – Análisis de Requerimientos
Período 2019-1

A. Identificación
Número de sesiones: 48
Número total de hora de aprendizaje: 48 h presenciales + 96 h de
aplicación del aprendizaje y
aprendizaje autónomo = 144 h
total.
Profesor: Paulo Guerra Terán
Correo electrónico del docente: paulo.guerra.teran@udla.edu.ec
Director: Marco Galarza
Campus: Queri
Pre-requisito: ACI320 Co-requisito:
Paralelo: 1

B. Descripción del curso

La asignatura es de carácter teórico – práctico y proporciona una visión general de los
conceptos de la Ingeniería de requerimientos, el proceso de requerimientos y su elicitación, la
clasificación de requerimientos funcionales y no funcionales, técnicas de recolección,
especificación y validación de requerimientos de usuario y elaboración de la documentación
correspondiente a la fase de análisis del proceso de desarrollo de software

C. Resultados de aprendizaje (RdA) del curso

1. Identifica los componentes de ingeniería de requerimientos en el proceso de desarrollo de

software.

2. Aplica el proceso y las técnicas de la ingeniería de requerimientos para la especificación de

requerimientos de software.

D. Sistema y mecanismos de evaluación

La evaluación del aprendizaje de la materia será un proceso continuo, integral y participativo.

De acuerdo con el Modelo Educativo de la UDLA la evaluación busca evidenciar el logro de los
resultados de aprendizaje institucionales, de cada carrera y de cada asignatura, a través de
mecanismos de evaluación (MdE). Por lo tanto, la evaluación debe ser continua, formativa y
sumativa. La UDLA estipula la siguiente distribución porcentual para los reportes de evaluaciones
previstas en cada semestre de acuerdo al calendario académico:

Reporte de progreso 1: (5 semanas) 25%

A. Resúmenes e informes: Documento escrito que refleja argumentación, ideas y propuestas
principales del estudiante de forma profunda, analítica y objetiva del tema propuesto por
el docente (3%).

pág. 1
 B. Portafolio de Ejercicios: El estudiante resuelve ejercicios propuestos como parte del
trabajo autónomo. Además, se incluye una actividad para definir el problema a solucionar
como caso de estudio (5%).
C. Talleres en Clase de todos los temas estudiados durante el progreso (5%).
D. Evaluación continua (12%):
a. Cuestionarios aula virtual. En ciertos temas estudiados tanto en clase como de
trabajo autónomo se tendrá una evaluación a través de un cuestionario en el aula
virtual. Esto incluye la parte teórica de la evaluación del primer parcial y se
realizará máximo en 30 minutos (6%).
b. Evaluación parcial: Se evaluará la comprensión de los contenidos tanto de temas
estudiados en clase como de trabajo autónomo (6%).

Reporte de progreso 2: (5 semanas) 35%

A. Portafolio de Ejercicios: El estudiante resuelve ejercicios propuestos como parte del
trabajo autónomo (7%).
B. Talleres en Clase de todos los temas estudiados durante el progreso (8%).
C. Avance del Proyecto Final: El estudiante en equipo de trabajo realiza un informe en el cual
se evidencie que define el problema a ser abordado, realiza una primera recopilación de
requerimientos utilizando una técnica de levantamiento de requerimientos, propone
alternativas de solución y elabora el análisis de factibilidad del proyecto (10%).
D. Evaluación continua: evaluaciones y evaluación parcial práctico en el cual se propondrá
un problema a solucionar, el cual el estudiante debe realizar el análisis de factibilidad y
dar su interpretación y conclusiones con base en los datos obtenidos (10%).

Evaluación final: (6 semanas) 40%

A. Talleres en Clase grupales en los que los estudiantes durante la clase elaboran
especificaciones sobre los requisitos funcionales y no funcionales. (5%).
B. Evaluación continua (15%)
a. Cuestionarios aula virtual. En ciertos temas estudiados tanto en clase como de
trabajo autónomo se tendrá una evaluación a través de un cuestionario en el aula
virtual. Esto incluye la parte teórica de la evaluación del progreso y se realizará
máximo en 30 minutos. (7%).
b. Evaluación parcial práctico en el cual se propondrá un problema a solucionar, el
cual el estudiante debe diseñar el diagrama de casos de uso y especificar al
menos 2 casos de uso. (8%).
C. Proyecto Final: El estudiante en equipo de trabajo realiza el análisis de requerimientos de
un caso de estudio en el cual se evidencie la aplicación de todo lo aprendido en la
asignatura, desde las etapas de recopilación de información hasta llegar a la especificar los
requerimientos del software utilizando los eventos y artefactos definidos en metodologías
de desarrollo ágil de software. (20%)

E. Asistencia

Al finalizar el curso habrá un examen de recuperación para los estudiantes que, habiendo cumplido
con más del 80% de asistencia presencial a clases, deseen reemplazar la nota de un examen anterior
(ningún otro tipo de evaluación). Este examen debe integrar todos los conocimientos estudiados
durante el periodo académico, por lo que será de alta exigencia y el estudiante necesitará
pág. 2
prepararse con rigurosidad. La nota de este examen reemplazará a la del examen que sustituye.
Recordar que, para rendir el EXAMEN DE RECUPERACIÓN, es requisito que el estudiante haya
asistido por lo menos al 80% del total de las sesiones programadas de la materia. No se podrá
sustituir la nota de un examen previo en el que el estudiante haya sido sancionado por una falta
grave, como copia o deshonestidad académica.

F. Metodología del curso

En el proceso de enseñanza – aprendizaje de la materia hay dos aristas; la primera es el estudiante,

cuya participación en todas las actividades planificadas es parte integral de su formación
académica, la segunda arista es la planificación sistemática del semestre. En las clases se usarán
materiales didácticos que motiven a los estudiantes al aprendizaje como: Proyectos, foros
participativos, talleres prácticos, trabajos colaborativos y autónomos, todo esto conlleva a los
estudiantes a que se motiven y les guste la carrera de Ingeniería de Software.

F.1. Escenario de aprendizaje presencial.

Para el aprendizaje presencial en el curso se realizará:

1. Presentación del tema por parte del docente: Los estudiantes recibirán explicación
directa de los temas de la clase.
2. Trabajo grupal: Los estudiantes realizarán trabajos en grupo dentro del aula de clases.
Todos los trabajos deben presentar su bibliografía académica que sustente su contenido,
la evaluación será de manera individual de acuerdo a la rúbrica respectiva. Todos los
trabajos formarán parte del portafolio de ejercicios.
3. Trabajo individual: Los estudiantes realizarán trabajos en el laboratorio de PC, los cuales
van a ser dirigidos por el docente, su entrega va a ser al final de la clase y su evaluación
de acuerdo a la rúbrica respectiva. Todos los trabajos formarán parte del portafolio de
ejercicios.
4. Evaluaciones: Los estudiantes deberán rendir una evaluación por cada temática de
aprendizaje, algunas de estas evaluaciones serán realizadas en el aula virtual. Todos los
trabajos formarán parte del portafolio de evaluaciones. Finalmente, al culminar cada
progreso existe una evaluación que sintetiza todo lo aprendido.

F.2. Escenario de aprendizaje virtual.

Para el aprendizaje virtual en el curso se realizará:

1. Portafolio de ejercicios. Recopilación de Trabajos individuales de los estudiantes subidos al
apoyo virtual.
2. Foros. El estudiante debe aportar con ideas a foros virtuales en el apoyo virtual. Todos los
foros formarán parte del portafolio de ejercicios.

F.3. Escenario de aprendizaje autónomo.

Para el aprendizaje autónomo en el curso se realizará:

1. Portafolio de ejercicios: El estudiante practica los conocimientos y destrezas adquiridos
realizando de manera autónoma ejercicios sobre temas específicos.
2. Auto-evaluaciones y evaluaciones: Se utilizará la herramienta del aula virtual, la cual
permite evidenciar el nivel de aprendizaje de los estudiantes, desarrollando en ellos
responsabilidad y autonomía en las tareas enviadas.

pág. 3
 G. Planificación alineada a los RdA

RdA RdA
Planificación Fechas
1 2
Unidad o Tema
1. Introducción a la Ingeniería de Software
2. Ingeniería del Software y la Web
3. Fundamentos de los requerimientos del software Semanas 1-5
4. Proceso de requerimientos
X
(5 semanas)
5. Análisis de Factibilidad
6.
7. 1.
Lecturas
Sánchez, S. (2012). Introducción a la ingeniería de software. En M. Silicia., D.
Rodríguez & S. Sánchez. Ingeniería del Software, un enfoque desde la
guía SWEBOK (pp. 5-15). México: Alfa Omega.
Sánchez, S. (2012). Conceptos básicos de la ingeniería de software. En M.
Silicia., D. Rodríguez & S. Sánchez. Ingeniería del Software, un enfoque X
desde la guía SWEBOK (pp. 19-30). México: Alfa Omega.
Sommerville, I. (2011). Ingeniería del Software y la Web. Ingeniería del
Software. (pp. 13-14). Pearson Educación.

Actividades
1. (P) Presentación por parte del docente del tema: “Introducción a la
ingeniería de software”
2. (P) Demostración de ejercicios en clase.
3. (P) Dinámica grupal Metodología Scrum con Legos.
4. (P) Presentación por parte del docente del tema: “Análisis de X
Factibilidad”
5. (A) Resolución de ejercicios y actividades.
6. (A)Resumen de las lecturas ACM/IEEE

Evaluaciones
1. Resolución de cuestionario aula virtual.
2. Informe de la dinámica sobre metodología Scrum.
3. Ensayo sobre Modelos de procesos de requerimientos.
X
4. Resolución de ejercicios.
5. Evaluación teórica y práctica del primer progreso.

Segundo Parcial
Unidad o Tema
1. Elicitación de requerimientos
2. Técnicas de recolección de requerimientos.
Semanas 6-10
3. Análisis de requerimientos X X
(5 semanas)
4. Diagramas de casos de uso-UML
5. Trazabilidad y medición de requerimientos

pág. 4
Lecturas

(Bourque,2014). Guide to the software engineering body of knowledge

(SWEBOK (R). (pp. 36-46). IEEE Computer Society Press.
(Sommerville I, 2011). Adquisición y análisis de requerimientos.
Ingeniería del Software. (pp. 100-110). Pearson Educación.
(Sánchez S, 2012). Procesos Fundamentales de la Ingeniería de
Software. Ingeniería del Software, un enfoque desde la guía SWEBOK. X X
(pp. 111-126). Alfa Omega.
(Sánchez S, 2012). Obtención de requisitos. Ingeniería del Software, un
enfoque desde la guía SWEBOK. (pp. 128-131). Alfa Omega.

Actividades
1. (P) Presentación por parte de los estudiantes el tema: “Elicitación de
Requerimientos”
2. (P) Demostración de ejercicios en clase.
3. (A) Elaboración de diagramas de casos de uso.
4. (P) Estudio de caso en clase sobre requerimientos.
5. (A) Indagación y trabajo de campo para plantear el tema del
X X
proyecto.
6. (A)Resumen de las lecturas ACM/IEEE

Evaluaciones
1. Resolución de cuestionario aula virtual.
2. Estudio de casos realizados en clase.
3. Resolución de ejercicios del portafolio. X X
4. Evaluación teórica y práctica del segundo progreso.
5. Informe del proyecto

Evaluación final
Unidad o Tema
1. Documento de especificación de requerimientos
2. Especificación de requerimientos
Semanas 11-16
3. Validación de requerimientos X
(6 semanas)
4. Herramientas para gestión de requerimientos

Lecturas
Sommerville, I. (2011). Documento de especificación de requerimientos.
Ingeniería del Software. (pp. 91-95). Pearson Educación.
Sánchez S. (2012). Procesos Fundamentales de la Ingeniería de Software. En
X
M. Silicia., D. Rodríguez & S. Sánchez. Ingeniería del Software, un
enfoque desde la guía SWEBOK (pp. 127-162). México: Alfa Omega.

Actividades

pág. 5
 1. (P) Demostración de ejercicios en clase.
2. (P) Especificación de casos de uso
3. (P) Presentación por parte del docente del tema: “Trazabilidad y
X
medición de requerimientos”
4. (A) Especificación de requerimientos.
5. (P) Presentación del proyecto final por parte de los estudiantes.
Evaluaciones
1. Resolución de cuestionario aula virtual.
2. Evaluación práctica de especificación de requerimientos. X
3. Documento de Especificación de requerimientos del software.

H. Normas y procedimientos para el aula

1. Solo se recibirán trabajos en el aula virtual y dentro del plazo establecido.

2. Se tomará lista en los primeros 10 minutos iniciada la clase si el estudiante llega después, podrá
ingresar de forma silenciosa, pero no se registrará la asistencia sin excepción.
3. Se tomará lista en los últimos 10 minutos de la clase si el estudiante sale antes de tomar lista
no se registrará la asistencia sin excepción.
4. Los estudiantes deberán practicar la “honestidad académica” para todas las actividades de
esta asignatura. La copia de ejercicios, exámenes, proyectos, y todas las actividades de
aprendizaje solicitadas por el docente, y se reportará a la dirección.
5. Se acepta el uso de cualquier dispositivo electrónico (iPad, tablets, celulares, audífonos)
únicamente con fines académicos.
6. No se podrán ingresar alimentos al aula.
7. El estudiante tiene derechos a recibir tutoría en los horarios establecidos por el docente.
8. En el caso de inasistencia es responsabilidad del estudiante igualarse en los contenidos de la
materia dictada en dicha clase.
9. En el caso de que un estudiante falte a una sesión en la que se realicen pruebas o prácticas de
laboratorio, no se podrán recuperar las calificaciones. Las fechas de las evaluaciones serán
publicadas en el apoyo virtual de la materia.

I. Referencias
Principales.
Silicia, M., Rodríguez, D., & Sánchez, S. (2012). Ingeniería del Software, un enfoque desde la guía
SWEBOK. México: Alfa Omega.

Sommerville, I. (2011). Ingeniería de Software. (9na ed). México: Pearson Educación. ISBN: 84-
7829-074-5

Complementarias.

Bani-Salameh, H. (November, 2015). Towards a comprehensive survey of the requirements

elicitation process improvements. In Proceedings of the International Conference on
Intelligent Information Processing, Security and Advanced Communication (p. 60). ACM. -
Recuperado de https://dl-acm-org.bibliotecavirtual.udla.edu.ec/citation.cfm?id=2816872

Bourque, P., & Fairley, R. E. (2014). Guide to the software engineering body of knowledge (SWEBOK
(R)): Version 3.0. IEEE Computer Society Press.
pág. 6
 Kendall, K. E., & Kendall, J. E. (2011). Análisis y diseño de sistemas. (8va ed). Pearson educación.

Pressman, R. (2010). Ingeniería de Software. (7ma ed). Madrid: McGraw-Hill. ISBN: 6071503140

Moore, J., & Iii, F. S. (August, 2001,). Requirements elicitation using visual and textual information.
In re (p. 0308). IEEE. Recuperado de https://www-computer-
org.bibliotecavirtual.udla.edu.ec/csdl/proceedings/re/2001/1125/00/11250308-abs.html

J. Perfil del docente

Master Universitario en Software y Sistemas (Universidad Politécnica de Madrid), Magister en

Gestión de las Comunicaciones y Tecnologías de la Información (Escuela Politécnica Nacional),
Ingeniero en Sistemas de Computación e Informática (Escuela Politécnica del Ejército). Experiencia
docente Universitario en UDLA; ESPE; Instituto Rumiñahui. Publicaciones: Libros: PROGRAMACIÓN
EN JAVA PARA INGENIEROS (ISBN-13: 978-1940600697), La educación a distancia y virtual en Ecuador
(ISBN-978-9942-08-497-2). Experiencia en el desarrollo de Sistemas informáticos en Agrocalidad.

Contacto: paulo.guerra.teran@udla.edu.ec
Puesto 15, segundo piso bloque 4.
Horario de Atención: Estará publicado en el aula virtual.

pág. 7
Proyecto Final
El estudiante en equipo de trabajo realiza el análisis de requerimientos de un caso de estudio en el cual se evidencie la aplicación de todo lo aprendido en la
asignatura, desde las etapas de recopilación de información hasta llegar a la especificar los requerimientos del software.

Criterios Satisfactorio Bueno Regular Insuficiente

Identifica el problema Identifica el problema Identifica el problema No Identifica el problema
mediante una mediante una descripción mediante una descripción realiza una descripción
descripción exacta y del ámbito del problema, superficial, imprecisa, sin imprecisa e inexacta, no
precisa del ámbito del determinando las causas y determinar causas y efectos, determina causas y efectos,
problema, efectos considerando los sin considerar los datos y los datos y procesos
determinando las datos y procesos procesos involucrados en el involucrados no tienen
Definición del problema. causas y efectos involucrados en el contexto, contexto del problema, relación al contexto del
Identifica el problema que considerando los demostrando conocimiento demostrando un problema.
se solucionará a través de datos y procesos teórico y un nivel completo conocimiento teórico y nivel
la implementación de una involucrados en el de abstracción en el de abstracción parcial del
solución informática. contexto, planteamiento del problema.
(10%) demostrando problema.
conocimiento teórico
y nivel de abstracción
completo en el
planteamiento del
problema
1 puntos 0.7puntos 0.5puntos 0.2puntos

pág. 8
 Identifica múltiples
Identifica múltiples
alternativas para Identifica alternativas
alternativas para resolver el Identifica una o varias
resolver el problema múltiples para resolver el
problema, pero solo una alternativas para resolver un
Selecciona alternativas de que pudieran problema, pero solo algunas
pudiera aplicarse dentro del problema, pero ninguna se
solución para el problema aplicarse dentro de pudieran aplicarse dentro
contexto específico. Realiza aplica en el contexto
planteado mediante un un contexto de un contexto específico.
un análisis de factibilidad de específico. El estudio de
análisis de factibilidad específico. Se realiza Realiza un análisis de
la solución propuesta factibilidad es incompleto o
técnica, operativa y un análisis de factibilidad de la solución
omitiendo algunos factores incorrecto.
económica. (20%) factibilidad de las propuesta omitiendo algún
importantes.
propuestas factor importante.
considerando todos
los factores.
2puntos 1.5puntos 1puntos 0.5puntos
En la solución
presentada los
artefactos y
Los artefactos y
requerimientos son En la solución presentada
En la solución presentada los requerimientos en su mayoría
claros, completos y los artefactos y
artefactos y requerimientos tienen errores, existe
con un alto nivel de requerimientos son claros,
Define una solución están incompletos, tienen inconsistencias y faltan
detalle. Utiliza completos y con un buen
ajustada a los eventos y nivel de detalle superficial. detalles importantes. La
técnicas de nivel de detalle. Utiliza
artefactos definidos en Utiliza técnicas de recolección técnica de recolección de
recolección de técnicas de recolección de
metodologías de de información, pero tiene información no tiene
información. Diseña información. El Diagrama de
desarrollo (50%) inconsistencias. El Diagrama evidencia de haberla
el Diagrama de casos casos de uso, omite alguna
de casos de uso omite varias realizado. El Diagrama de
de uso en base a funcionalidad.
funcionalidades. casos de uso omite varias
datos, información, y
funcionalidades.
procesos recopilados
y analizados.
5puntos 3puntos 2puntos 1puntos

pág. 9
 Proporciona
explicaciones
profundas, precisas y
completas del Proporciona explicaciones
diagrama de casos de Proporciona explicaciones superficiales del diagrama de
Explica la información, de
uso. Hace inferencia claras del diagrama de casos casos de uso. Explica y
manera incorrecta o
Capacidad para explicar el apropiadas basadas de uso. Explica de manera responde de manera
incompleta, malinterpreta la
problema y su solución. en la información clara los requerimientos del superficial los requerimientos
información.
(20%) presentada. Explica sistema con datos, del sistema con datos,
con precisión los procesos, flujos, gráficos. procesos, flujos, gráficos.
requerimientos del
sistema con datos,
procesos, flujos,
gráficos.
2puntos 1.5puntos 1puntos 0.5puntos

pág. 10