Presentación de PowerPoint · 2021. 2. 17. · Organizar código en paquetes, directorios,...

Arquitectura del SoftwareE

scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Rol de Arquitecto de softwarey stakeholders

Jose Emilio Labra GayoCurso 2020/2021


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Rol del arquitecto

Expectativas sobre un arquitectoTomar decisiones arquitectónicasAnalizar continuamente la arquitecturaEstar al día de las tendencias actualesAsegurar cumplimiento decisiones existentesExperiencia diversaConocimiento del dominio de negocioPoseer habilidades interpersonalesComprender y navegar en política empresarial

Leyes de arquitectura del software


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Tomar decisiones arquitectónicasDefinir decisiones de arquitectura Definir principios de diseñoGuiar las decisiones tecnológicasMantener registros de decisionesAnalizar puntos a favor y en contra


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Analizar continuamente la arquitectura

Revisar continuamente tecnología y arquitecturaSer responsible del éxito técnico del proyectoEstar al tanto de posible deterioro estructuralPerseguir la consistencia

Organizar código en paquetes, directorios, módulos,...Definir límites, principios, guías,...Incluir entornos de prueba y entrega en proyectos


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Asegurar cumplimiento de decisiones

Los arquitectos normalmente imponen restriccionesEjemplo:

Acceso a base de datos desde interfaz de usuarioLos desarrolladores se las podrían saltar

Interfaz usuario Lógica negocio Base dedatos

invocación directaX


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Estar al día de las tendenciasConocer últimas tendencias tecnológicas e

industrialesLas decisiones de un arquitecto pueden tener larga

duración y ser muy costosasConocer lo que sabes y lo que sabes que no sabes

Cosas que sabemos

Cosas que sabemos que no sabemos

Cosas que no sabemos que no sabemosPeligro!


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Experiencia diversaEstar expuesto a múltiples y diversas tecnologías,

marcos, plataformas, entornos, etc.No quiere decir ser un experto en todas ellas...pero al menos estar familiarizado con varias

tecnologíasAmplitud técnica mejor que profundidad técnica


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Conocimiento dominio de negocioSe espera que el arquitecto tenga un cierto

conocimiento del dominio de negocioComprensión del problema de negocio, los

objetivos y los requisitosComunicarse de forma efectiva con ejecutivos y

usuarios del dominio utilizando su lenguaje


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Habilidades interpersonalesArquitecto del sofware = líderHabilidades de trabajo en equipo y liderazgoLiderazgo técnico

Ser inclusivo y colaboradorAyudar a desarrolladores a comprender la estructura

general (the big picture)Participar en desarrollo

Formar parte de la entregaComprensión de bajo nivelCodificación como parte del rolRevisiones de código y tutorización

"no importa lo que te digam, siempre es un problema de personas", G. Weinberg


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Comprender y navegar la políticaComprender el clima politico de la empresa y ser

capaz de navegar la política empresarialDecisiones arquitectónicas afectan a stakeholders

Dueños de producto, gestores de proyecto, personas de negocio, desarrolladores, etc.

Casi cualquier decisión tomada por un arquitecto va a ser discutida y puesta en duda

Habilidades de negociación son necesariasPresentar y defender la arquitectura

Ascensor del arquitecto del softwareComunicación con diferentes capas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

3 preocupaciones fundamentalesContener la entropía

Definir estándares, convenciones, herramientas a utilizar

Conocer no solamente qué se va a hacer, sino cómo hacerlo y porqué hacerlo

Especificar atributos de calidadDeterminar soluciones de compromise/trade-offs


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Trabajo en equipoLa ingeniería del software es una labor de equipoPatrones de organización diferentes para equipos

Equipos por tecnologíaEquipos por proyecto

Project manager ≠ arquitecto de softwareAlgunos patrones

Ocultarse y mito del genioEl factor Bus3 pilares de interacciones sociales


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ocultarse y mito del genioInseguridad

Las personas tienen miedo de que otros juzguen su trabajoIntentos de esconder el código

Mito del genio: Tendencia a atribuir éxito de un equipo a una personaEjemplos: Bill Gates, Linus Torvalds, etc.

Ocultarse se considera perjudicialEl trabajo en solitario incrementa el riesgo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

El factor Bus*Nº de personas que tienen que ser golpeadas por

un autobús para que el proyecto fracase del todoPueden ocurrir sucesos impredecibles

Trabajo en equipo es obligatorio para reducir riesgoAsegurar al menos 2 personasBuena documentación

*Término acuñado en Google (Software Engineering at Google, 2020)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

3 pilares de interacción social

Software engineering at Google, T. Winters et al, 2020

Humildad

RespetoConfianza

Tú no eres el centro del universo (tampoco tu código)No eres omnisciente ni infalibleEstas abierto a mejora continua

Te preocupas de aquellos con los que trabajasLos tratas amablementeAprecias sus capacidades y logros

Crees que los otros son competentesCrees que los otros harán lo adecuadoTe parece bien dejarles al mando cuando se requiera


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Personalidades del arquitectoArquitecto efectivo = compromiso entre friki de control

y arquitecto de sillón

Architect de sillónFriki de controlDesconectado de desarrolladores

Nunca está (salta de proyecto en proyecto)Solo participa en diagramas iniciales

Participa en todas las decisionesDecisiones de detalle y bajo nivelParticipa en desarrollo de código (cuello de botella)


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Topologías de equiposLas topologías de los equipos afectan a los sistemas

Estructuras de comunicaciónDinámica de equiposTamaño de los equipos

"La asignación de equipos es el primer borrador de la arquitectura", M. Nygaard


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Topología tradicional de equiposDisposición de trabajo tradicional:

Equipos existentes son asignados a cada nuevo proyectoEjemplo: 4 equipos: front-end, back-end, DBA y Ops

Ops

DBA

Backenddev

Front-enddev


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ley de Conway

Source: https://meekrosoft.wordpress.com/2013/06/25/conways-second-law/

Las organizaciones que diseñan sistemas...están avocadas a producir diseños que son copias de las estructuras de estas organizaciones [M. Conway, 1967]

Corolario: La mejor estructura de un sistema está influenciada por

la estructura social de la organizaciónEjemplo:

Si hay 3 equipos (diseño, programación, bases de datos), el sistema tendrá de forma natural 3 módulos

https://meekrosoft.wordpress.com/2013/06/25/conways-second-law/


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Maniobra inversa de ConwayEvolucionar equipos y estructura organizativa para

promover la arquitectura deseadaCrear equipos después de la descomposición modularEjemplo con microservicios

App dev

API dev

DBdev

App dev

API dev

DBdev

App dev

API dev

DBdev

App dev

API dev

DBdev

Equipo A Equipo B Equipo C Equipo D

MicroservicioA

MicroservicioB

MicroservicioC

MicroservicioD

Principio de Amazon: Tú lo construyes, tú lo ejecutas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Tamaño de equipoTamaño eficiente de un equipo influencia el éxito

del proyectoAlgunos avisos a tener en cuenta:

Pérdida por procesoIgnorancia colectivaDifusión de responsabilidad

Regla de 2-pizzas: "si no puedes dar de comer a tu equipo con 2 pizzas, entonces es muy grande", J. Bezos


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Pérdida por procesoDiferencia entre potencial de grupo y productividad actual

Razones: sobrecarga comunicación, reuniones,...

Potencialgrupo

Productividadactual

Pérdida porproceso

Ley de Brook. Añadir más personas a un equipo que va retrasado hace que se retrase más todavía


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Ignorancia colectivaCuando todo el mundo está públicamente de

acuerdo en algo y privadamente lo rechazan pero creen que hay algo obvio que no entiendenDecisiones arquitectónicas no cuestionadas

Fábula del nuevo traje del Emperadorhttp://fablesfairytalesandsocialjustice.weebly.com/the-emperors-new-clothes.html

http://fablesfairytalesandsocialjustice.weebly.com/the-emperors-new-clothes.html


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Difusión de responsabilidadTamaño de equipo grande impacta la comunicaciónAlgunas señales:

Confusión sobre quién es responsable de quéCosas que quedan abandonadas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Apoyarse en listas de controlListas de control (checklists) = método efectivo

para asegurar que algunas tareas son realizadas o cubiertasTareas propensas a error o que se olvidan

frecuentementeHacer equipos más efectivos

Efecto Hawthorne: Si la gente sabe que están siendo observados, entonces cambian su comportamiento para hacer las cosas adecuadas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

StakeholdersTodas las partes que participan en el desarrollo o

son afectadas por el sistemaPuede ser una persona, rol u organizaciónNormalmente tienen preocupaciones diferentes

Algunas veces contradictoriasEs necesario

Comprender la naturaleza, fuente y prioridad de sus preocupaciones

Identificar y comprometerse con ellosSolicitar sus necesidades y expectativas

Los Stakeholders manejan (explicita o implicitamente) la forma y dirección de la arquitectura para que sirva a sus necesidades


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Identificando stakeholdersTodos los individuos, roles u organizaciones que:

Deberían conocer la arquitecturaTienen que ser convencidos de la arquitecturaTienen que trabajar con la arquitectura o el códigoNecesitan la documentación de la arquitectura para

realizar su trabajoTienen que tomar decisiones sobre el sistema o su

desarrollo


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Identificando stakeholdersInternos

AnalistaDiseñadorPersonas de negociosDesarrolladorProduct ownerDiseñador de UXJefe de proyecto. . .

ExternosClienteUsuarios finalesAuditorAutoridades públicasSuministradoresProveedores servicios

externos. . .


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Expectativas de stakeholdersLas expectativas ayudan a:

Identificar necesidades específicasObjetivo: alcanzar mayor satisfacción de la audiencia

Evitar trabajo innecesarioEvitar documentar cosas irrelevantes

Formato típico:Role/nombre Contacto Expectativas


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Mapa de stakeholdersMostrar personas/roles relacionados

Incluir relaciones e interaccionesEjemplo Sistema automatización licitaciones (*)

Ciudadanos

Ayuntamiento Oficina de gestión

votan

Alcalde

Desarrolladores

votan

regula

paga

Pidenservicios

Departamentosde la ciudad

regula

regula

Necesidadeslicitaciones

Boletínoficial

licitaciones

Abogadode contratos

contratoslicitaciones

Consulta

(*) Source: Design it!, M. Keeling

Negocioslocales


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Declarar objetivos de negociosObjetivos de negocios centrados en personasNormalmente entre 3 ó 5Persona/stakeholder

Resultado: expresa la necesidad como algo medibleCómo cambiaría el mundo si el Sistema tiene éxito?

ContextoAlguna aclaración sobre el objetivo

Persona/stakeholder Resultado Contexto

Alcalde de la ciudad Reducir costes 30% Evitar recortes de los presupuestospara servicios esenciales

Oficina de gestión Revisar datos de licitacioneshistóricos de los últimos 30 años

Los datos históricos pueden ayudar a predecir contratos futuros


scu

ela

de

Inge

nie

ría

Info

rmát

ica

Un

iver

sid

ad d

e O

vied

o

Fin

Presentación de PowerPoint · 2021. 2. 17. · Organizar código en paquetes, directorios,...

Documents

Transcript of Presentación de PowerPoint · 2021. 2. 17. · Organizar código en paquetes, directorios,...