Académique Documents
Professionnel Documents
Culture Documents
La arquitectura de software se construye en equipo usando una metodología de desarrollo que incluye prácticas ágiles (e.g.,
de SCRUM).
Objetivos pedagógicos
Al final del curso, el estudiante será capaz de:
Generalidades y Funcionamiento
• El curso consiste en 3 horas semanales de clase presencial con el profesor, 1½ horas de trabajo supervisado en el
laboratorio con los monitores y asistente y 4½ horas de trabajo individual por fuera de clase.
• El estudiante que no asista al menos al 80% de las clases y sesiones de trabajo supervisado no podrá aprobar el
curso, de acuerdo con el artículo 42 y 43 del Reglamento General de Estudiantes de Pregrado.
• La grabación, por cualquier medio, de este curso NO está autorizada. En caso de requerirla realice una solicitud por
escrito dirigida al profesor del curso justificando las razones.
• El curso tiene como canales oficiales de comunicación el correo electrónico Uniandes, la lista de correo del curso, el
sistema de apoyo a la docencia SICUA+ (http://sicuaplus.uniandes.edu.co)
Cada entrega del proyecto tendrá una nota global, pero al final del semestre cada miembro tendrá una nota individual de
proyecto teniendo en cuenta las contribuciones realizadas. El grupo determina la contribución a través de co-evaluaciones.
Después del cierre de cada Sprint se hace una coevaluación, si un miembro del equipo no hace la coevaluación el Sprint NO
ES CALIFICADO.
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, entre otras.
Seguimiento y planeación
Los grupos deben hacer reuniones de seguimiento y planeación en las sesiones magistrales. La memoria de los acuerdos
debe quedar en un acta en la Wiki del repositorio.
Análisis de eficacia
Los grupos deben hacer una reflexión sobre el proceso/producto al final de cada Sprint. Se considerarán los resultados de la
coevaluación.
Interdependencia positiva
Se darán bonos a los grupos que demuestren un trabajo en equipo exitoso. Si todos los miembros del grupo tiene un alto
desempeño en los criterios mencionados, todos tendrán un bono extra. Una arquitectura de sw. está compuesta por muchos
elementos que interactúan entre sí para satisfacer las historias de usuario y los escenarios 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.
En este curso las calificaciones definitivas serán de uno cinco (1,5) a cinco (5,0), usando la siguiente escala de aproximación:
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, 2012
[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] https://sourcemaking.com/design_patterns
[11] Mike Cohn.User stories applied, 2004
[12] Nathan Marz, BigData Principles and best practices of scalable real-time data systems. 2015
Cronograma