Evaluación de Atributos de Calidad en Arquitectura de Software

Excelente curso.
Después de haber tomado este curso, debo admitir que yo sabia programar pero no sabia hacer software.
Muchas gracias.

Bastante teoría, pero le falto practica, estoy lleno de conceptos que no sabría como aplicarlos xD
Como hago el bus?
Como guardo los eventos y como hago que se ejecuten?
Como puedo armar un arquitectura orientada al dominio u orientada a microservicios?
Como conecto las capas?
Como hacer la documentación?

Por que en el examen preguntas sobre el modelo de vistas de arquitectura “4+1", si en los vídeos no tocas esos temas, no me parece justo.

En mi opinión el curso fue de gran contenido teórico, solo me hicieron falta algunos ejemplos de un caso más práctico para asimilar mejor toda la teoría.

¿piensan agregar un ejemplo de documentación de arquitectura para el proyecto del curso en la pestaña de Archivos?

Gracias a todos los involucrados por traernos este gran curso. Para mi llenó muchos vacios, y me permitió entender conceptos y procesos que veo en mi día a día.

Sugiero una actualización de este curso y el de fundamentos ya que es demasiado contenido teórico puesto a fuerza entre los dos cursos de forma compacta, me hubiese gustado que sea más demostrativo o practico cosa que despierte más la intuición o la lógica al relacionar ese mar de conceptos con casos reales u ejemplos claros y gráficos de cada cosa para no crear lagunas mentales.

La verdad que es un mundo todo esto, pero el conocerlos hace tengamos unas herramientas altamente potenciales. Gracias Guido y por mi parte a seguir estudiando!

Muchas teórica, poca practica.
Sugiero hacer un caso de estudio aplicando toda la teoría vista. Considero que no se aprende a nadar viendo vídeos, se aprende a nadar en el agua y tragando un poco de agua.

Excelente el curso, le pondria algunos ejemplos mas pero fue excelente igual!

opino similar mas ejemplos y tambien bibliografia sugerida para profundizar en el tema.

Tengo miedo de hacer el examen 😦

Acá pueden certificarse en Scrum totalmente gratis y en español.
https://certiprof.com/pages/scrum-foundation-professional-certificate-sfpc-v2020-spanish

Hice un mapa conceptual de los temas en general, se me hace increíble todo lo que se abarcó en estos dos cursos. Soy ingeniero en Sistemas y computación, y gracias a estos cursos pude saldar uno de los peldaños que me hizo falta en la universidad

gracias por el conocimiento

Un conjunto típico de vistas de la arquitectura
La arquitectura se representa mediante un número diferente de vistas de la arquitectura, que, esencialmente, son extractos que ilustran los elementos “significativos arquitectónicamente” de los modelos. En RUP, se empieza en un conjunto típico de vistas, llamado el “modelo de vista 4+1” [KRU95]. Consta de:

La Vista de guión de uso, que contiene guiones de uso y casos de ejemplo que abarcan riesgos técnicos, de clases o de comportamiento significativos arquitectónicamente. Es un subconjunto del Modelo de guión de uso.
La Vista lógica, que contiene las clases de diseño más importantes y su organización en paquetes y subsistemas, y la organización de estos paquetes y subsistemas en capas. También contiene algunas realizaciones de guiones de uso. Es un subconjunto del Modelo de diseño.
La Vista de implementación, que contiene una visión general del Modelo de implementación y su organización en términos de módulos en paquetes y capas. También se describe la asignación de paquetes y clases (de la vista lógica) a los paquetes y módulos de la vista de implementación. Es un subconjunto del Modelo de implementación.
La Vista de proceso, que contiene la descripción de las tareas (proceso y hebras) implicadas, sus interacciones y configuraciones y la asignación de clases y objetos de diseño a tareas. Esta vista sólo debe utilizarse si el sistema tiene un grado significativo de Concurrencia. En RUP, es un subconjunto del Modelo de diseño.
La Vista de despliegue, que contiene la descripción de los diferentes nodos físicos para la mayoría de las configuraciones típicas de la plataforma y la asignación de tareas (de la vista de proceso) a los nodos físicos. Esta vista sólo debe utilizarse si el sistema es distribuido. Es un subconjunto del Modelo de despliegue.
Las vistas de la arquitectura se muestran en el Documento de arquitectura de software. Puede visualizar vistas adicionales para expresar diferentes preocupaciones especiales: vista de interfaz de usuario, vista de seguridad, vista de datos, etc. En sistemas simples, puede omitir algunas de las vistas contenidas en el modelo de vista 4+1.

Atención en la arquitectura
Aunque las vistas de arriba pueden representar el diseño completo de un sistema, la arquitectura trata únicamente algunos aspectos específicos:

La estructura del modelo: los patrones organizativos, por ejemplo, la Creación de capas.
Los elementos esenciales: guiones de uso críticos, clases principales, mecanismos comunes, etc., en oposición a todos los elementos presentes en el modelo.
Unos cuantos casos de ejemplo clave que muestran los flujos de control principales en el sistema.
Los servicios, para capturar aspectos de la línea de productos, modularidad y características opcionales.
Las vistas de la arquitectura son, esencialmente, abstracciones o simplificaciones de todo el diseño, en las que las características importantes pasan a ser más visibles y se dejan de lado los detalles. Estas características son importantes cuando se razona sobre:

La evolución del sistema, el paso al siguiente ciclo de desarrollo.
La reutilización de la arquitectura, o partes de ella, en el contexto de una línea de productos.
La evaluación de calidades suplementarias, como rendimiento, disponibilidad, portabilidad y seguridad.
La asignación de trabajo de desarrollo a equipos y subcontratistas.
Las decisiones sobre la inclusión de componentes asequibles.
La inserción en un sistema más amplio.

Para poder hablar y razonar sobre la arquitectura de software, antes debe definir una representación arquitectónica, una manera de describir aspectos importantes de una arquitectura. En RUP, esta descripción se captura en el Documento de arquitectura de software.

La arquitectura de software es un concepto fácil de entender y que la mayoría de los ingenieros aprecian intuitivamente, sobre todo los que tienen un poco de experiencia, pero resulta difícil definirlo con precisión. En concreto, es difícil dibujar una línea precisa entre el diseño y la arquitectura, la arquitectura es un aspecto de diseño que se concentra en algunas características específicas.

En An Introduction to Software Architecture, David Garlan y Mary Shaw sugieren que la arquitectura es un nivel de diseño que se centra en aspectos: “Beyond the algorithms and data structures of the computation; designing and specifying the overall system structure emerges as a new kind of problem. Structural issues include gross organization and global control structure; protocols for communication, synchronization, and data access; assignment of functionality to design elements; physical distribution; composition of design elements; scaling and performance; and selection among design alternatives.” (Más allá de los algoritmos y estructuras de datos de la computación; el diseño y la especificación de la estructura general del sistema emergen como una clase nueva de problema. Los aspectos estructurales incluyen la estructura global de control y la organización general; protocolos de comunicación, sincronización y acceso de datos; asignación de funciones para diseñar elementos; distribución física, composición de elementos de diseño; ajuste y rendimiento; y selección entre otras alternativas de diseño).

Excelente curso Guido
⭐️⭐️⭐️⭐️⭐️

Les recomiendo el libro “Software Architecture in Practice” de Len Bass, Paul Clements y Rick Kazman.
Yo lo leí casi al mismo tiempo que pase este curso y el curso previo de Fundamentos de Arquitectura y lo note muy complementario, ya que si bien el libro es un poco “antiguito”, aun mantiene la esencia de los conceptos generales de desarrollo de software que son necesarios para ser un arquitecto de software. Muchas cosas son exactamente igual que en estos cursos, pero le da aun mas profundidad y análisis.

Muy buen curso…

Excelente Curso, ayuda a comprender muchas cosas que están inconclusas a la hora de diseñar una arquitectura de software.
Gracias Gran Aporte al Conocimiento.!!

Me hizo falta una clase donde se haga un análisis práctico de trade-offs y así poder profundizar en los criterios para poder priorizar distintos atributos de calidad.

Me gustó mucho el curso.En mi ser, tenía muchas “lagunas de información” en el tema de arquitectura de software. Lo recomiendo definitivamente.

Genial, me gustó mucho. Gracias por compartir tu conocimiento!!

Excelente curso. Y con los ejemplos que Guido usa, permite entender la teoría de una forma más sencilla y aterrizar los conceptos.

Muchas gracias por esta lluvia de información, muy útil ya que es necesario entender como funciona la arquitectura de software y todo lo que conlleva ponerla en practica.

Es un curso super genial!

Alguna recomendacion de libros para seguir aprendiendo!

Muy útil toda la información del curso, aunque me hubiese gustado que se analicen arquitecturas de software de empresas o startups representativas, como las aplican y que cambios hicieron.

Siento que para que este curso no sea tan pesado de teoría en diapositivas pudo colocar gráficos de arquitecturas básicas y y fueran incrementando con proyectos ya implementados. Casi no me gusto este curso, aprendi cosas y lo agradezco.

En términos generales, el curso tiene buena información, pero si esperaba algo más práctico, con ejemplos de implementación con los patrones más populares.

Excelente curso.

porque no comparten una presentación a modo de síntesis y ejemplos desarrollados en documentación real o ligas a ejemplos que utilizan los corporativos, gracias.

Cuando empece el curso solo sabia patrones de arquitectura, pero ahora se que puedo diseñar mi arquitectura gracias a estos atributos de calidad, y también combinarlos con los patrones de arquitectura, para tener un estilo dependiendo de el dominio del problema.