Departamento de Ingeniería de Sistemas y Computación

Arquitectura y Diseño de Software

ISIS2503 – 201910

Programa del curso

Propósito del curso

Desarrollar las competencias de 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 y desempeño/escalabilidad), así como estilos y tácticas para guiar el diseño de una arquitectura de software.

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:

• Identificar historias de usuario, escenarios de calidad para un problema propuesto

• Diseñar una arquitectura de software aplicando estilos, tácticas de diseño de alto nivel y patrones de diseño
detallado
• Diseñar pruebas para validar que la arquitectura de software propuesta satisface los escenarios de calidad
• Programar prototipos que reflejan la arquitectura y las pruebas diseñadas en tecnologías concretas
• Iterar sobre la arquitectura y pruebas diseñadas para lograr el cumplimiento de los escenarios de calidad que no se
logren en Sprints tempranos
• Documentar historias de usuario, escenarios de calidad
• Documentar el diseño de alto y bajo nivel de la arquitectura a través de diagramas UML 2
• Documentar diseño de la prueba y los resultados obtenidos
• Aplicar una metodología de diseño centrado en arquitectura que incluye prácticas ágiles
• Desarrollar el proyecto en equipos auto-gestionados
Metodología
• El curso gira alrededor de un proyecto de tamaño mediano sobre el cual se introducen los elementos teóricos y
tecnológicos.
• El objetivo principal es diseñar la solución y experimentar si la aproximación seleccionada cumple o no con los
escenarios de calidad propuestos para los siguientes atributos: desempeño/escalabilidad, disponibilidad y seguridad.
En caso de no cumplirlos, se espera que los grupos iteren sobre la arquitectura y las pruebas diseñadas inicialmente.
• Antes de cada clase magistral, el estudiante deberá revisar diapositivas y lecturas complementarias que lo prepararán
con los elementos teóricos requeridos en dichas clases. En el cronograma del curso se indican las lecturas
complementarias que se deben hacer. Así, las clases magistrales se centran en retomar los conceptos y aplicarlos a
casos de estudio o al proyecto en análisis y diseño, a través de guías de trabajo. 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.
Durante las clases, se harán quices relacionados con lo revisado/leído.
• Las clases de laboratorio tienen los siguientes objetivos: 1) Realizar talleres de tecnologías/herramientas que ayudan
a aterrizan los conceptos vistos en las clases magistrales; 2) Evaluar los prototipos construidos por los grupos
teniendo en cuenta el alcance definido para cada Sprint; 3) Responder la auto/co-evaluación de los Sprints del
proyecto; 3) Dar realimentación a los estudiantes encaminada a la resolución de problemas técnicos enfrentados en
los talleres y/o el proyecto.
• Antes de cada laboratorio, el estudiante deberá realizar actividades relacionadas con el proyecto y/o talleres de
tecnologías. Antes de la finalización del laboratorio, el estudiante deberá terminar los entregables esperados. Al final
del semestre se bonificará a los estudiantes que muestren un buen desempeño en la entrega de los talleres.
• La asistencia a las clases magistrales y laboratorio es obligatoria ya que se desarrollará gran parte del trabajo en
equipo.

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)

Evaluación del curso

La evaluación del curso consiste en:

• 2 Parciales de 15% cada uno

• 4 Sprints de diseño y experimentación de arquitectura: 1er Sprint 10%, 2°, 3° y 4° valen cada uno 15%
• Talleres:10%
• Quices: 5%

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.

Pautas para el trabajo en equipo

Conformación de grupos
Los grupos del proyecto son de 4 estudiantes y se conforman libremente. 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, programación de
prototipos, instalación de infraestructura, despliegue y pruebas. En cada Sprint se debe asignar un líder de arquitectura, ese
rol debe rotarse 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, 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:

Nota Ponderada Nota Final

De 0 a 1,74 1,5
De 1,75 a 2,24 2,0
De 2,25 a 2,74 2,5
De 2,75 a 2,99 2,75
De 3,0 a 3,24 3,0
De 3,25 a 3,74 3,5
De 3,75 a 4,24 4,0
De 4,25 a 4,74 4,5
De 4,75 a 5,0 5,0

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