Introducci贸n al curso

1

Introducci贸n al curso de Profesional de Arquitectura de Software

Atributos de calidad

2

Definici贸n

3

Atributos: Idoneidad funcional

4

Atributos: Eficiencia de ejecuci贸n

5

Atributos: Compatibilidad

6

Atributos: Usabilidad

7

Atributos: Confiabilidad

8

Atributos: Seguridad

9

Atributos: Mantenibilidad

10

Atributos: Portabilidad

11

Tensiones entre atributos

12

Analizando PlatziServicios

Patrones de arquitectura

13

Patrones monol铆ticos vs distribuidos

14

Patrones: Modelo Vista Controlador

15

Patrones: Capas

16

Patrones: Orientado a eventos / Provisi贸n de eventos.

17

Patrones: Microkernel - Plug-ins

18

Patrones: Comparte-nada

19

Patrones: Microservicios

20

Patrones: CQRS

21

Patrones: Hexagonal - Puertos y adaptadores

22

Patrones: Dise帽o orientado al dominio

23

Combinando patrones de arquitectura

24

Analizando nuevamente PlatziServicios

Dise帽o de una arquitectura

25

Pararse en hombros de gigantes

26

Herramientas y partes de un dise帽o: Tipos de conectores

27

Conectores: Llamado asincr贸nico / sincr贸nico. Modelo Cliente servidor.

28

Conectores: Enrutador, difusi贸n

29

Conectores: Pizarra, repositorio, colas, modelo PUBSUB

30

Escenarios y t谩cticas

31

Escenarios: Disponibilidad, detecci贸n, reparaci贸n

32

Escenarios: Reintroducci贸n y prevenci贸n

33

Escenarios: Mantenibilidad

34

Escenarios: Prevenir efectos domin贸 y diferir enlace

35

Escenarios: Eficiencia de ejecuci贸n

36

Escenarios: Seguridad

37

Escenarios: Capacidad de prueba

38

Escenarios: Usabilidad

39

Validar las decisiones de dise帽o: Arquitectura en evoluci贸n

40

脷ltimo an谩lisis a PlatziServicios

Modelado y documentaci贸n de arquitectura

41

C贸mo comunicar la arquitectura: Vistas y Puntos de vista

42

Documentaci贸n vs implementaci贸n

43

Conclusiones del curso

A煤n no tienes acceso a esta clase

Crea una cuenta y contin煤a viendo este curso

C贸mo comunicar la arquitectura: Vistas y Puntos de vista

41/43
Recursos

Aportes 7

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Arquitectura restrictiva
Restringe las decisiones que quedan por tomar (por ejemplo cu谩ndo se le da a un equipo de desarrollo)
Arquitectura descriptiva
Documenta las decisiones tomadas y describe el estado actual del sistema, restricciones del pasado m谩s las actuales

El arquitecto va a trabajar con diferentes personas para garantizar que la arquitectura se ejecute correctamente:

Analista: Negociaci贸n de requerimientos
Operaciones: C谩lculo de recursos
Desarrolladores: Restricciones y libertades para desarrollar
Dise帽adores de productos dependientes (Product Managers): Definici贸n de interoperabilidad. Comunicaci贸n entre productos. Requerimientos de comunicaci贸n como una API. Sincronizar equipos
Gestores de proyecto (Project Manager): Gesti贸n de equipos y recursos
Equipo de calidad (QA):聽M茅tricas y conformidad

C贸mo comunicar la arquitectura: Vistas y Puntos de vista

鈥淓sencialmente, todo modelo es incorrecto. Pero algunos son 煤tiles.鈥


  • Arquitectura Restrictiva: Como vamos a utilizar este modelo para restringir las acciones que quedan por tomar. la arquitectura va a funcionar como restricciones de dise帽o.

  • Arquitectura Descriptiva: Habla de un sistema ya existente y que habla del estado actual del sistema.Es nuestra responsabilidad conectar el estado actual con nuestro modelo o documentaci贸n arquitect贸nica.

  1. El arquitecto va a negociar con el analista y encontrar los trade-offs (Negociaci贸n de requerimientos).
  2. El arquitecto junto a operaciones va poder entender esta propuesta arquitect贸nica y empezar a calcular el costos de los recursos que vamos a empezar a consumir.
  3. El equipo de desarrollo va utilizar toda la documentaci贸n anterior para entender las restricciones y libertades a desarrollar.

  1. Dise帽adores de producto se comparte la arquitectura para entender la interoperabilidad del producto.
  2. Gestores de Proyecto Aprovechan la documentaci贸n del proyecto para entender que equipo deben armar para garantizar el 茅xito del proyecto.
  3. Equipo de calidad (QA) va utilizar la documentaci贸n de arquitectura para poder entender como es que puede medir estas garant铆as.

En los 煤ltimos segundos se oyen unas voces. Pens茅 que hab铆a gente en mi casa pero era el video jajaja

Arquitecto va a trabajar con :
o Analista: Negociaci贸n de requerimientos
o Operaciones: C谩lculo de recursos
o Desarrolladores: Restricciones y libertades
o Product Managers: Defici贸n de interoperabilidad
o Project Manager: Gesti贸n de equipos y recursos
o Calidfad: M茅tricas y conformidad

  • Arquitectura restrictiva
    Restringe las decisiones que quedan por tomar (por ejemplo cu谩ndo se le da a un equipo de desarrollo)

  • Arquitectura descriptiva
    Documenta las decisiones tomadas y describe el estado actual del sistema, restricciones del pasado m谩s las actuales
    馃
    El arquitecto va a trabajar con diferentes personas para garantizar que la arquitectura se ejecute correctamente:
    Analista: Negociaci贸n de requerimientos
    Operaciones: C谩lculo de recursos
    Desarrolladores: Restricciones y libertades para desarrollar
    Dise帽adores de productos dependientes (Product Managers): Definici贸n de interoperabilidad. Comunicaci贸n entre productos. Requerimientos de comunicaci贸n como una API. Sincronizar equipos
    Gestores de proyecto (Project Manager): Gesti贸n de equipos y recursos
    Equipo de calidad (QA): M茅tricas y conformidad

Quality assurance the best!!