Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
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
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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!
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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)
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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)
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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. . .
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
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
Arquitectura del SoftwareE
scu
ela
de
Inge
nie
ría
Info
rmát
ica
Un
iver
sid
ad d
e O
vied
o
Fin