5.39. CS292. Ingeniería de Software II (Obligatorio)
- Semestre: 7mo Sem. Créditos: 4
- Horas del curso: Teoría: 2 horas; Práctica: 2 horas; Laboratorio: 2 horas;
-
Prerrequisitos:
- CS291. Ingeniería de Software I (5to Sem)
5.39.1. Justificación
Ingeniería de Software II se basa en los principios fundamentales del primer curso, cambiando el enfoque hacia patrones de diseño avanzados, evolución de software y la gestión de proyectos a gran escala. Explora las complejidades de mantener sistemas heredados, asegurar la calidad del software mediante validación rigurosa, y la aplicación de técnicas profesionales de gestión de proyectos en entornos ágiles.
5.39.2. Objetivos Generales
- 1.
- Aplicar patrones de diseño orientados a objetos avanzados para resolver problemas arquitectónicos complejos.
- 2.
- Dominar la gestión de configuración de software y control de versiones en entornos colaborativos.
- 3.
- Comprender los principios de evolución y mantenimiento de software.
- 4.
- Gestionar proyectos de software usando técnicas de estimación y análisis de riesgos.
- 5.
- Implementar estrategias de prueba avanzadas y métricas de calidad.
5.39.3. Contribución a los resultados (Outcomes)
-
AG-C09) Diseño y Desarrollo de Soluciones: Diseña, implementa y evalúa soluciones para problemas complejos de computación. (Usage)
-
AG-C03) Trabajo Individual y en Equipo: Se desempeña efectivamente como individuo y como miembro o líder en equipos diversos. (Usage)
5.39.4. Contenido
5.39.4.1. Colaboración y Dinámica de Equipo (14 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Sommerville, 2015, Pressman and Maxim, 2019]
Temas
- 1.
- Comunicación efectiva, incluida la oral y escrita, así como formal (correo electrónico, documentos, comentarios, presentaciones) e informal (chat de equipo, reuniones). Sociedad, ética y la Profesión (SEP) -Communication
- 2.
- Causas comunes de conflicto en el equipo y enfoques para la resolución de conflictos.
- 3.
- Programación cooperativa:
- a)
- Programación por parejas (pair programming) o Enjambre (swarming)
- b)
- Revisión de código
- c)
- Colaboración mediante control de versiones
- 4.
- Roles y responsabilidades en un equipo de software: Sociedad, ética y la Profesión (SEP)
-ProfessionalEthics
- a)
- Ventajas del trabajo en equipo
- b)
- Riesgos y complejidad de dicha colaboración
- 5.
- Procesos del equipo: responsabilidades para las tareas, estimación de esfuerzo, estructura de reuniones, cronograma de trabajo
Aprendizaje esperado (Learning Outcomes)
- 1.
- Seguir prácticas efectivas de comunicación en equipo [Analizar]
- 2.
- Articular las fuentes, peligros y beneficios potenciales del conflicto en el equipo, especialmente enfocándose en el valor de estar en desacuerdo sobre ideas o propuestas sin insultar a las personas [Articular]
- 3.
- Facilitar una estrategia de resolución de conflictos y resolución de problemas en un entorno de equipo [Analizar]
- 4.
- Colaborar efectivamente en desarrollo/programación cooperativa [Analizar]
- 5.
- Proponer y delegar los roles y responsabilidades necesarios en un equipo de desarrollo de software [Proponer]
- 6.
- Redactar y seguir una agenda para una reunión de equipo [Componer]
- 7.
- Facilitar, a través de la participación en un proyecto de equipo, los elementos centrales de la formación de equipos, el establecimiento de una cultura de equipo saludable y la gestión de equipos, incluida la creación y ejecución de un plan de trabajo del equipo [Crear]
5.39.4.2. Principios y Arquitectura de Software (16 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Gamma et al., 1994a, Pressman and Maxim, 2019]
Temas
- 1.
- Principios de diseño de sistemas. Fundamentos de Sistemas (SF) -Reliability
- a)
- Niveles de abstracción (por ejemplo, diseño arquitectónico y diseño detallado)
- b)
- Separación de preocupaciones (separation of concerns)
- c)
- Ocultación de información (information hiding)
- d)
- Acoplamiento y cohesión (coupling and cohesion)
- 2.
- Arquitectura de software. Fundamentos de Sistemas (SF) -Reliability
- a)
- Paradigmas de diseño
- 1)
- Descomposición funcional de arriba hacia abajo/diseño por capas
- 2)
- Arquitectura orientada a datos
- 3)
- Análisis y diseño orientado a objetos
- 4)
- Diseño dirigido por eventos
- b)
- Arquitecturas estándar (por ejemplo, cliente-servidor y arquitecturas de microservicios incluyendo discusiones sobre REST, n-capas, tuberías y filtros, Modelo Vista Controlador)
- c)
- Identificar límites y dependencias de componentes
- 3.
- Programación a gran escala vs programación a pequeña escala (programming in the large vs programming in the small). Fundamentos de Sistemas (SF) -Reliability
- 4.
- Malos olores del código (code smells) y otras indicaciones de la calidad del código, distintas de la corrección. Seguridad (SEC) -Engineering
Aprendizaje esperado (Learning Outcomes)
- 1.
- Identificar la arquitectura de software estándar de un diseño de alto nivel dado [Analizar]
- 2.
- Seleccionar y usar un paradigma de diseño apropiado para diseñar un sistema de software simple y explicar cómo se han aplicado los principios de diseño de sistemas en este diseño [Evaluar]
- 3.
- Adaptar un diseño de sistema defectuoso para que siga mejor principios como la separación de preocupaciones o la ocultación de información [Crear]
- 4.
- Identificar las dependencias entre un conjunto de componentes de software en un diseño arquitectónico [Analizar]
5.39.4.3. Prácticas de Codificación (14 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Sommerville, 2015]
Temas
- 1.
- Pruebas prácticas a pequeña escala Fundamentos de Desarrollo de Software (SDF) -Practices
- a)
- Pruebas unitarias
- b)
- Desarrollo guiado por pruebas (Test-driven development): esto es particularmente
valioso para los estudiantes psicológicamente, ya que es mucho más fácil involucrarse
constructivamente con el desafío de identificar entradas desafiantes para una API dada
(casos límite, casos extremos) a priori. Si implementan primero, el instinto es a menudo evitar intentar hacer fallar su nueva creación, mientras que un enfoque de pruebas primero les da la satisfacción intelectual de detectar los casos problemáticos y luego ver cómo pasan más pruebas durante el proceso de desarrollo.
- 2.
- Documentación Fundamentos de Desarrollo de Software (SDF) -Practices
- a)
- Documentación de la interfaz: describir los requisitos de la interfaz, potencialmente incluyendo contratos (formales o informales), pre y post condiciones, invariantes.
- b)
- La documentación de la implementación debe centrarse en partes de código complicadas y no
obvias, ya sea porque el código usa características avanzadas del lenguaje o porque el
comportamiento del código es complejo. (No agregar comentarios que reafirmen operaciones
comunes/obvias y características simples del lenguaje.)
- 1)
- Aclarar el flujo de datos, cómputo, etc., centrándose en lo que el código es.
- 2)
- Identificar partes sutiles/complicadas del código y refactorizar para que sean autoexplicativas si es posible o proporcionar comentarios apropiados para aclarar.
- 3.
- Estilo de codificación Fundamentos de Desarrollo de Software (SDF) -Practices
- a)
- Guías de estilo
- b)
- Comentarios
- c)
- Nomenclatura (naming)
- 4.
- "Mejores Prácticas"para la codificación: técnicas, patrones/idiomas, mecanismos para construir
programas de calidad Seguridad (SEC) -Coding,SDF-Practices
- a)
- Prácticas de codificación defensiva
- b)
- Prácticas y principios de codificación segura
- c)
- Usar mecanismos de manejo de excepciones para hacer los programas más robustos, tolerantes a fallos
- 5.
- Depuración (debugging) Fundamentos de Desarrollo de Software (SDF) -Practices
- 6.
- Registro (logging)
- 7.
- Uso de bibliotecas y frameworks desarrollados por otros Fundamentos de Desarrollo de Software (SDF) -Practices
Aprendizaje esperado (Learning Outcomes)
- 1.
- Escribir pruebas unitarias apropiadas para un componente pequeño (varias funciones, un solo tipo, etc.) [Escribir]
- 2.
- Escribir comentarios apropiados de interfaz y (si es necesario) de implementación para un componente pequeño [Escribir]
- 3.
- Describir técnicas, patrones de codificación y mecanismos para implementar diseños para lograr propiedades deseadas como confiabilidad, eficiencia y robustez [Describir]
-
4.
- Escribir código robusto utilizando mecanismos de manejo de excepciones [Escribir]
- 5.
- Describir prácticas de codificación segura y defensiva [Describir]
- 6.
- Seleccionar y usar un estándar de codificación definido en un proyecto de software pequeño [Usar]
- 7.
- Comparar y contrastar estrategias de integración, incluyendo integración de arriba hacia abajo (top-down), de abajo hacia arriba (bottom-up) y sándwich [Comparar]
- 8.
- Describir el proceso de analizar e implementar cambios en la base de código desarrollada para un proyecto específico [Describir]
- 9.
- Describir el proceso de analizar e implementar cambios en una base de código existente grande [Describir]
5.39.4.4. Conceptos de verificación y validación (10 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Pressman and Maxim, 2019]
Temas
- 1.
- Conceptos de verificación y validación
- a)
- Verificación: ¿Estamos construyendo la cosa correctamente?
- b)
- Validación: ¿Construimos la cosa correcta?
- 2.
- Por qué importan las pruebas: ¿El componente sigue siendo funcional a medida que el código evoluciona?
- 3.
- Objetivos de las pruebas
- a)
- Usabilidad
- b)
- Confiabilidad
- c)
- Conformidad con la especificación
- d)
- Rendimiento
- e)
- Seguridad
Aprendizaje esperado (Learning Outcomes)
- 1.
- Explicar por qué las pruebas son importantes [Explicar]
- 2.
- Distinguir entre validación y verificación de programas [Distinguir]
- 3.
- Describir diferentes objetivos de las pruebas [Describir]
5.39.4.5. Herramientas y Análisis de Pruebas (4 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Sommerville, 2015, Pressman and Maxim, 2019]
Temas
- 1.
- Herramientas y automatización de verificación y validación
- a)
- Análisis estático
- b)
- Cobertura de código
- c)
- Fuzzing
- d)
- Análisis dinámico y contención de fallos (sanitizadores, etc.)
- e)
- Registro y seguimiento de fallos
- 2.
- Planificación y generación de pruebas
- a)
- Estimación de fallos y terminación de pruebas, incluyendo siembra de defectos
- b)
- Uso de números aleatorios y pseudoaleatorios en las pruebas
- 3.
- Pruebas de sistemas asíncronos, paralelos y concurrentes
- 4.
- Verificación y validación de artefactos que no son código (documentación, materiales de capacitación)
Aprendizaje esperado (Learning Outcomes)
- 1.
- Describir y comparar diferentes herramientas para verificación y validación [Describir]
- 2.
- Automatizar el uso de diferentes herramientas en un proyecto de software pequeño [Diseñar]
- 3.
- Explicar cómo y cuándo se deben usar números aleatorios en las pruebas [Explicar]
- 4.
- Describir enfoques para la estimación de fallos [Describir]
- 5.
- Estimar el número de fallos en una aplicación de software pequeña basándose en la densidad de fallos y la siembra de fallos [Estimar]
- 6.
- Describir técnicas y problemas con las pruebas de software asíncrono, concurrente y paralelo [Describir]
- 7.
- Crear un plan de pruebas para un segmento de código de tamaño mediano que contenga código asíncrono, concurrente y/o paralelo, incluyendo una matriz de pruebas y generación de datos y entradas de prueba [Crear]
- 8.
- Describir técnicas para la verificación y validación de artefactos que no son código [Describir]
5.39.4.6. Pruebas de Rendimiento y Evaluación Comparativa (4 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Bondi, 2015, Gregg, 2020]
Temas
- 1.
- Pruebas de rendimiento y evaluación comparativa
- a)
- Rendimiento (throughput) y latencia
- b)
- Degradación bajo carga (pruebas de estrés, manejo FIFO vs LIFO de solicitudes)
- c)
- Aceleración (speedup) y escalado (scaling)
- 1)
- Ley de Amdahl
- 2)
- Ley de Gustafson
- 3)
- Escalado suave (soft) y débil (weak)
- d)
- Identificar y medir figuras de mérito (figures of merit)
- e)
- Cuellos de botella de rendimiento comunes
- 1)
- Limitado por cómputo (compute-bound)
- 2)
- Limitado por ancho de banda de memoria
- 3)
- Limitado por latencia
- f )
- Métodos estadísticos y mejores prácticas para la evaluación comparativa (benchmarking)
- 1)
- Estimación de la incertidumbre
- 2)
- Intervalos de confianza
- g)
- Análisis y presentación (gráficos, etc.)
- h)
- Técnicas de medición de tiempo (timing)
Aprendizaje esperado (Learning Outcomes)
- 1.
- Describir el rendimiento (throughput) y la latencia y proporcionar ejemplos de cada uno [Describir]
- 2.
- Explicar la aceleración (speedup) y las diferentes formas de escalado (scaling) y cómo se calculan [Explicar]
- 3.
- Describir cuellos de botella de rendimiento comunes [Describir]
- 4.
- Describir métodos estadísticos y mejores prácticas para la evaluación comparativa (benchmarking) de software [Describir]
- 5.
- Explicar técnicas y desafíos para medir el tiempo al construir una evaluación comparativa (benchmark) [Explicar]
- 6.
- Identificar las figuras de mérito, construir y ejecutar una evaluación comparativa (benchmark) y analizar estadísticamente y visualizar los resultados para un proyecto de software pequeño [Analizar]
5.39.4.7. Conceptos de Confiabilidad (10 horas) [Habilidades AG-C03,AG-C09]
Referencias Bibliográficas: [Sommerville, 2015]
Temas
- 1.
- Concepto de confiabilidad como probabilidad de fallo o tiempo medio entre fallos, y fallas (faults) como causa de fallos (failures)
- 2.
- Identificar requisitos de confiabilidad para diferentes tipos de software
- 3.
- Fallos de software causados por defectos/errores (bugs), por lo que para alta confiabilidad el objetivo es tener un mínimo de defectos - inyectando menos defectos (mejor capacitación, educación, planificación) y eliminando la mayoría de los defectos inyectados (pruebas, revisión de código, etc.)
- 4.
- Confiabilidad del software, confiabilidad del sistema y comportamiento de fallos
- 5.
- Ciclo de inyección y eliminación de defectos, y diferentes enfoques para la eliminación de defectos
- 6.
- Comparar el enfoque de "presupuesto de error"(error budget) para la confiabilidad con el enfoque "libre de errores"(error-free) e identificar dominios donde cada uno es relevante.
Aprendizaje esperado (Learning Outcomes)
- 1.
- Describir cómo determinar el nivel de confiabilidad requerido por un sistema de software [Describir]
- 2.
- Explicar los problemas que existen para lograr niveles muy altos de confiabilidad [Explicar]
- 3.
- Comprender enfoques para minimizar fallas que pueden aplicarse en cada etapa del ciclo de vida del software [Explicar]
5.39.5. Referencias Bibliográficas