Departamento de Ingeniería de Sistemas y Computación
Arquitectura y Diseño de Software
Programa del curso Arquitectura y Diseño de Software
Propósito
Desarrollar las competencias para diseñar, justificar, implementar y probar una arquitectura de software para un
sistema complejo. Para cumplir esto, el curso presenta mecanismos de especificación de requerimientos de calidad
(disponibilidad, seguridad, desempeño, escalabilidad y modificabilidad), así como estilos y tácticas para guiar el
diseño de una arquitectura de software.
Se empleará una metodología de desarrollo, basada en prácticas ágiles, para el desarrollo de la arquitectura de
software.
Objetivos de aprendizaje
Al final del curso el estudiante comprenderá que:
• El proceso de construcción de una arquitectura de software usa múltiples especificaciones como entrada
diversas especificaciones, para producir modelos y experimentos de forma incrementalmente.
• En el diseño de arquitectura se decide qué estilos, tácticas y patrones escoger para lograr el cumplimiento de
las especificaciones de calidad.
• Las decisiones de diseño se documentan y comunican usando modelos de arquitectura, que se agrupan de
acuerdo con preocupaciones de los stakeholders.
• En cada incremento del proceso se hacen experimentos, los cuales consisten en la implementación de una parte
de los modelos de arquitectura y de pruebas.
• En el diseño de arquitectura se maneja la contienda de los requerimientos de calidad.
Metodología
• El curso se fundamenta en el desarrollo de un proyecto colaborativo que se llevará a cabo durante las 16
semanas de clase. En este proyecto se busca diseñar la solución a el(los) requerimiento(s) de un cliente real y
experimentar si la aproximación seleccionada cumple o no con los requerimientos de calidad propuestos para
los siguientes atributos: desempeño/escalabilidad, disponibilidad, seguridad y mantenibilidad.
• El trabajo se organiza en 4 Sprints que les permitirán a los equipos aplicar la información teórica del curso y
realizar los avances iterativos sobre la arquitectura del proyecto, junto con las pruebas de concepto que servirán
para ajustar o cambiar el diseño inicial.
• Las actividades del curso se organizan en los siguientes momentos:
o Antes de la clase 1 y 2: Los/las estudiantes tienen la responsabilidad de revisar los materiales
correspondientes a cada sesión y realizar las actividades asignadas. Estas actividades hacen parte de la
evaluación “sumativa” que tiene nota.
o Durante de la clase 1 y 2: Estará centrado en retomar los conceptos y aplicarlos a casos de estudio o al
proyecto en análisis y diseño, a través de actividades en clase. Además, se realizarán reuniones para
garantizar que todos los miembros del equipo están comprometidos con el éxito del proyecto de forma
equitativa. Estas actividades hacen parte de la evaluación “formativa” cuyo propósito es aclarar
conceptos y mejorar el proyecto antes de las entregas de sprint, pero no asignar nota.
o Laboratorio: Con este espacio se busca:
▪ Dar realimentación encaminada a la resolución de problemas técnicos enfrentados en los
talleres y/o el proyecto.
▪ Evaluar los experimentos construidos por los grupos teniendo en cuenta el alcance definido para
cada Sprint.
▪ Ofrecer un espacio para las reuniones del grupo.
Los entregables de las sesiones de laboratorio variarán dependiendo del propósito de cada una y
esto se aclarará en las instrucciones de Bloque N. Algunos ejemplos de entregables son: resultados
solicitados en los talleres de tecnología, actas de reunión de equipo, ASRs, entre otros. Estas
actividades hacen parte de la evaluación “sumativa”.
A continuación, para cada sección, se especifican las fechas de entrega límite para las actividades del “antes” de las
clases 1, 2 y laboratorio:
Secciones Antes de clase 1 Antes de clase 2 Antes de laboratorio
1 Martes a las 6:30 a.m. Viernes a las 6:30 a.m. Lunes a las 6:30 a.m.
2 Lunes a las 6:30 a.m. Miércoles a las 6:30 a.m. Viernes a las 6:30 a.m.
3 Lunes a las 8 a.m. Martes a las 8 a.m. Viernes a las 8 a.m.
4 Lunes a las 9:30 a.m. Martes a las 9:30 a.m. Viernes a las 9:30 a.m.
5 Miércoles a las 5 p.m. Jueves a las 5 p.m. Lunes a las 5 p.m.
Si durante las clases 1 y 2 se realizan actividades, el profesor definirá la fecha de entrega límite de acuerdo con el
avance que observe en clase.
Las entregas relacionadas con laboratorios deben finalizarse y entregarse, máximo:
• Para las secciones 2, 3 y 4: El martes (a medianoche) siguiente a la sesión de laboratorio.
• Para las secciones 1 y 5: El viernes (a medianoche) siguiente a la sesión de laboratorio.
El profesor de cada sección tiene la libertad de correr las fechas límite de entrega de los “antes” y “durante” en caso
de eventualidades importantes.
En Bloque Neón se encuentran las instrucciones y materiales requeridos para realizar las actividades de las clases 1,
2 y laboratorios. Igualmente se encuentra la ruta de avance del proyecto y los criterios de evaluación.
Generalidades y Funcionamiento
El curso consiste en 3 horas semanales de clase presencial con el profesor, 1½ horas de trabajo presencial
supervisado en el laboratorio con los monitores y asistente y 4½ horas de trabajo individual (fuera de clase).
El profesor y el asistente comunicarán el horario de atención a estudiantes y el modo de atención (presencial y/o
virtual).
Los contenidos del curso se encuentran protegidos por las normas internacionales y nacionales vigentes sobre
propiedad Intelectual, por lo tanto su utilización parcial o total, reproducción, comunicación pública, transformación,
distribución, alquiler, préstamo público e importación, total o parcial, en todo o en parte, en formato impreso o
digital y en cualquier formato conocido o por conocer, se encuentran prohibidos, y solo serán lícitos en la medida
en que se cuente con la autorización previa y expresa por escrito de la Universidad de los Andes.
El curso tiene como canales oficiales de comunicación:
▪ Sesiones presenciales de las clases 1, 2. El profesor puede hacer sesiones virtuales por Zoom en caso de
eventualidades importantes como enfermedad o problemas de movilidad en la ciudad
▪ Sesiones híbridas de los laboratorios. En el cronograma del curso se indica cuáles sesiones de laboratorio
son presenciales y cuáles virtuales. Es responsabilidad del estudiante estar al tanto de la modalidad
establecida en el cronograma
▪ Horarios de atención
▪ Correo electrónico Uniandes
▪ Sistema de apoyo a la docencia Bloque Neón. Los estudiantes deben configurar en Bloque Neón qué tipo de
notificaciones del aula desean recibir y a través de qué medio (ya sea correo electrónico o SMS).
Recomendamos como mínimo seleccionar los debates (foros) y noticias.
▪ Foros en Bloque Neón
▪ Canales de Teams
Evaluación sumativa del curso
La evaluación del curso consiste en los siguientes ítems:
▪ 2 parciales de 15% cada uno
▪ 4 Sprints de diseño y experimentación de arquitectura:
o 1er Sprint vale 5%
o 2do y 3er Sprints valen cada uno 10%
o 4to Sprint vale 15%
▪ Laboratorios individuales: 20%
▪ Actividades y tareas del ”antes”: 10%
Los equipos de proyecto son de 4 miembros quienes deberán trabajar en las diferentes entregas del proyecto de
forma mancomunada. Los grupos de proyecto se conformarán libremente en la primera semana de clases y la
conformación debe mantenerse a lo largo del semestre. Los sprints tendrán sustentaciones intermedias y
seguimientos que serán útiles para que el equipo docente realimente a los grupos de proyecto. En la evaluación de
cada sprint se considerarán estas observaciones.
Antes de la sustentación final de cada sprint, los estudiantes deberán coevaluar a sus compañeros, este es un
prerrequisito obligatorio de la sustentación. Cada estudiante deberá revisar los resultados de la coevaluación y
reflexionar sobre qué acciones de mejora debe plantearse como individuo y equipo.
Los equipos deben tener en cuenta los siguientes lineamientos para las sustentaciones de sprint:
• Todos los integrantes del equipo deben asistir. Si alguien no puede debe informarlo al profesor adjuntando
la debida justificación como lo indica el reglamento de estudiantes.
• Cualquier miembro del equipo debe poder estar en capacidad de sustentar, no debe haber dependencia con
ciertos miembros o computadores personales. El profesor puede designar quién realizará la sustentación de
las diferentes partes del sprint, por lo tanto, es importante que los miembros del equipo tengan un
conocimiento compartido de los entregables.
Ante imprevistos, el equipo docente puede comunicar sobre cambios en los horarios, hasta un día antes de la
sustentación, a través de Teams y correo electrónico. Si un equipo no puede asistir al nuevo horario propuesto, debe
comunicarlo con prontitud al equipo docente para reagendar.
Si el equipo presenta algún conflicto entre sus miembros (por ej., insatisfacción con la calidad de las contribuciones
de algunos estudiantes), el equipo debe informar a los profesores quienes mediaran para resolver el conflicto. La
mediación incluye:
• Revisar las contribuciones de los miembros del equipo. En este punto se revisarán entregables como:
resultados de coevaluaciones, herramienta de planeación, wiki, repositorio, entre otros
• Evaluar si es necesario reasignar una nota proporcional a los esfuerzos de cada miembro. Si el esfuerzo del
integrante en cuestión es de cero %, la nota también será cero
• Establecer compromisos de mejora del trabajo en equipo, la calidad de los entregables y los tiempos de
entrega
• Decidir sobre desvincular al miembro del equipo. Se llega a este punto si el miembro del equipo en cuestión
no cumple con los compromisos ni mejora en la próxima entrega concertada. El equipo es quien debe
solicitar la desvinculación a los profesores y si la solicitud es aceptada el miembro en cuestión debe hacer
las entregas faltantes de forma individual, sin cambios en el alcance de estas
• Si el profesor propone una acción con miras a la resolución del conflicto por alguno de los canales de
comunicación del curso, se espera que los estudiantes se pongan al tanto de esto y manifiesten su posición
a fin de llegar a un acuerdo, máximo 3 días calendario después de iniciada la comunicación.
Un proveedor externo otorgará una cantidad de créditos a los estudiantes para realizar experimentaciones con su
infraestructura y servicios de nube. Es responsabilidad de los estudiantes hacer un uso racional de estos créditos,
siguiendo las guías y lineamientos proporcionados en el curso. El desperdicio de los créditos conllevará a una
penalización en la nota de las actividades evaluativas y si algún estudiante se queda sin créditos deberá asumir el
costo de infraestructura y servicios de nube por sus propios medios.
En las actividades individuales se espera una diferenciación entre las entregas de los estudiantes. Recuerde que el
régimen disciplinario del pregrado expresa claramente la importancia de cumplir las reglas establecidas por la
universidad y por el evaluador, que en este caso se asocian con evitar conductas como: copiar total o parcialmente
en exámenes, tareas y demás actividades académicas. O, presentar como de autoría toda o parte de una obra, un
trabajo, un documento o una invención de otra persona; incorporar un trabajo ajeno en el propio de forma que
induzca a error al observador o lector en cuanto a su autoría. Si se demuestra alguna de estas conductas, la nota en
la asignación correspondiente será cero y si se reincide en la conducta se llevará a comité disciplinario.
En los casos en los cuales se permita el uso de herramientas de IAG para realizar trabajos académicos se debe indicar
en la sección que mejor corresponda qué sistemas de IAG se usaron y de qué manera o con qué fines.
A partir del segundo semestre de 2023, la fecha límite de retiro será varias semanas antes de finalizar el curso. El
equipo docente entregará las notas que suman alrededor del 30% para que tengan esta información a la hora de
tomar alguna decisión de retiro, antes de la fecha límite estipulada por Registro.
En este curso las calificaciones definitivas serán de uno cinco (1,5) a cinco (5,0), usando la siguiente escala de
aproximación:
Nota Ponderada Nota Final
De 0,00 a 1,74 1,50
De 1,75 a 2,24 2,00
De 2,25 a 2,74 2,50
De 2,75 a 2,99 2,75
De 3,00 a 3,24 3,00
De 3,25 a 3,74 3,50
De 3,75 a 4,24 4,00
De 4,25 a 4,74 4,50
De 4,75 a 5,00 5,00
Usos de IAG en el curso
El uso de IAG no está permito en los parciales, pero un uso reflexivo/crítico sí está permitido en los entregables
del curso que tienen que ver con el diseño de arquitectura de software. Estos entregables son listados en la tabla
que sigue y en frente se describe lo que se espera que hagan los estudiantes cuando usan la IAG:
Entregable Uso permitido de IAG
- Especificaciones (ASRs, motivadores, El estudiante realiza una primera versión de la
restricciones, etc.) actividad y puede hacer uso de IAG para mejorar
- Diseño de experimento su trabajo. No se permite la creación de
entregables completamente con IAG. Se debe
indicar en la sección que mejor corresponda si se
usaron herramientas de IAG y con qué fin.
Diseño de arquitectura. El estudiante realiza una primera versión de la
actividad y puede hacer uso de IAG para crear
contenido relacionado al diseño. Debe comparar
su versión con la versión generada con IAG,
analizarla y consolidarla. Se debe indicar en la
sección que mejor corresponda si se usaron
herramientas de IAG y con qué fin.
- Implementación de experimento. Se permite el desarrollo de la actividad
- Otras actividades (Por ej.: presentaciones, completamente con IAG. El estudiante debe
infografías, videos, etc.) realizar una evaluación de los resultados y
ajustarlos de ser necesario. Se debe indicar en la
sección que mejor corresponda si se usaron
herramientas de IAG y con qué fin.
Pautas para el trabajo en equipo
Conformación de grupos
Los grupos del proyecto son de 4 estudiantes y se conforman libremente en la primera semana de clases. La
conformación debe mantenerse a lo largo del semestre.
Asignación de roles
Todos los miembros del equipo deben hacer las tareas de un arquitecto, a saber: análisis, diseño y experimentación
(esto es programación/despliegue/pruebas de parte de los modelos). En cada Sprint se debe asignar un líder de
arquitectura, el cual rotará entre los Sprints. Adicionalmente, debe definirse un relator para cada una de las
reuniones de los grupos. Ese rol también debe rotarse.
Contratos
El equipo debe definir un conjunto de reglas de funcionamiento a principio de semestre. Las reglas deben abordar
aspectos como: canales de comunicación, reuniones fuera de aula, cumplimiento de compromisos, manejo de
trabajo no equitativo entre los miembros del grupo, etc.
Seguimiento y planeación
Los grupos deben hacer reuniones de seguimiento, planeación en las sesiones. La memoria de los acuerdos debe
quedar en un acta en la Wiki del grupo.
Análisis de eficacia
Los grupos deben hacer una reflexión sobre el proceso/producto al final de cada Sprint.
Interdependencia positiva
Se darán bonos a los grupos que demuestren un trabajo en equipo exitoso. Si todos los miembros del grupo tienen
un alto desempeño en los criterios mencionados, todos tendrán un bono extra. Una arquitectura de software está
compuesta por muchos elementos que interactúan entre sí para satisfacer las historias de usuario y los
requerimientos de calidad. Los elementos son hechos por los miembros del grupo. Así, la arquitectura no puede ser
exitosa (en calidad y tiempos de entrega) si los miembros del equipo no coordinan sus esfuerzos para completar las
tareas. En algunas actividades se escogerá de forma aleatoria a un miembro del grupo para que explique su trabajo
individual y el de sus compañeros.
Bibliografía
[1] Rozanski, N., Woods,E., “Software Systems Architecture”, Second Edition. Addison Wesley. 2011
[2] Bass, L. Clements, P., Kazman, R., “Software Architecture in Practice”, Third Edition. Addison-Wesley, 2022
[3] Paul Clements et al, “Documenting Software Architectures: Views and Beyond”, Addison Wesley, Second Edition.
2011
[4] Paul Clements et al, “Evaluating Software Architectures”, Addison Wesley, 2002.
[5] Richard Taylor, Nenad Medvidovic, Eric Dashofy. “Software Architecture Foundations, Theory and Practice, 2009.
[6] Frank Buschmann, Kevin Henney, Douglas Schmidt. Pattern-Oriented Software Architecture. Volume4.
[7] Anthony Lattanze. Architecting Software Intensive Systems: A Practitioners Guide. Auerbach Publications
(November 18, 2008)
[8] Chris Richardson. Microservices Patterns. Manning. 2018
[9] Gamma. Design Patterns. Adisson Wesley. 1995
[10] [Link]
[11] Mike [Link] stories applied, 2004
[12] Nathan Marz, BigData Principles and best practices of scalable real-time data systems. 2015