02 ES Definiciones

¿Cuál es la primer ley de la arquitectura del software?

• Todo en arquitectura es una solución de compromiso
• Un arquitecto de software no debe mezclarse con ingenieros
• Todo sistema software debe tener unos planos
• Individuos e interacciones sobre procesos y herramientas

La mayoría de decisiones de arquitectura del software vienen determinadas por

• Los atributos de calidad o requisitos no funcionales
• El equipo de desarrollo
• El entorno de desarrollo
• Los requisitos funcionales

Las restricciones...

• es bueno conocerlas porque limitan alternativas a considerar
• Son un problema que hay que tratar de evitar
• Son imposiciones de los jefes de proyecto que hay que evitar
• Son imposiciones de los arquitectos de software al equipo

Los stakeholders...

• Son personas interesadas en el proyecto
• Son entidades abstractas que identifican requisitos funcionales
• Son roles que deben adoptar los arquitectos de software
• Son los dueños del proyecto

Un sistema greenfield

• Es un proyecto nuevo
• Es un proyecto de mejora de un sistema existente
• Es un software respetuoso con el medio ambiente
• Es un proyecto finalizado

¿Existe arquitectura del software ágil?

• Sí, cuando la arquitectura puede reaccionar a cambios en el entorno
• No, la arquitectura del software no es compatible con metodologías ágiles
• Sí, cuando los arquitectos de software se ponen a dieta
• Sí, cuando desaparecen los arquitectos de software

¿Quién dijo que los pilares de una buena arquitectura eran Utilidad, durabilidad y elegancia ?

• Vitruvio en 15 al 30 a. de C.
• Julio César en 15 al 30 a. de C.
• Martin Fowler en el s. XX
• Aristóteles en 300 a. de C.

Big design Up-front

• Es un problema al generar demasiados documentos o diagramas innecesarios
• Es necesario para grandes sistemas de software
• Consiste en retrasar decisiones hasta último momento necesario
• Facilita la gestión de proyectos mediante grandes decisiones de diseño

¿Cuál es la segunda ley de arquitectura del software?

• El porqué es más importante que el cómo.
• El cómo es más importante que el porqué.
• El cómo es más importante que el dónde.
• El quién es más importante que el porqué.

Los requisitos funcionales...

• Son una entrada que el arquitecto del software puede considerar
• No afectan a la arquitectura del software
• Suelen terminar en -idad, como escalabilidad, seguridad...
• Son la principal preocupación del arquitecto del software