¿Cuál es la diferencia entre ingeniería de software y arquitectura de software?

La arquitectura de software se ocupa de los rasgos que abarcan los conceptos de ingeniería de software. Es una abstracción de mayor nivel que la ingeniería de software. La arquitectura de software se refiere a las llamadas preocupaciones transversales llamadas vistas 4 + 1. Aquí se consideran el rendimiento, la interoperabilidad, la mantenibilidad, la vida útil del software, los aspectos de seguridad holísticos, etc. La ingeniería de software no cubre este aliento completo. La arquitectura del software es como el plano de su casa, con diferentes puntos de vista, por ejemplo. Lateral, frontal, etc. Idealmente, el archivado de software es primero antes que la ingeniería de software.

El trabajo del arquitecto de software: necesitamos un servicio de almacenamiento S3 y lo publicaremos diariamente desde sitios remotos. Luego, el postprocesamiento indexará esos datos contra cognito y …

El trabajo del ingeniero de software: así que ahora tengo que implementar la indexación cognitiva …

En general, se trata de alcance y detalle. Con más y más entornos de TI o sistemas de aplicaciones que son mucho más complejos, y explotan los conceptos emergentes de computación distribuida y reutilizan los servicios existentes, o crean otros nuevos, o utilizan servicios de componentes más avanzados como NoSQL y fuentes de datos relacionales, la necesidad de software y la arquitectura de sistemas, a diferencia del diseño, es cada vez más importante.

La regla general para mí es que a nivel de componente, se requiere diseño, y cuando se usan múltiples componentes, se requiere arquitectura. Sin embargo, creo que para hacer bien la arquitectura, debería haber hecho el diseño primero, particularmente en términos de ingeniería de sistemas y software. La arquitectura requiere una cierta mentalidad que no siempre es evidente en aquellos que son buenos en el diseño. La capacidad de abstraer o compartimentar y apreciar completamente diferentes taxonomías es necesaria en algunas formas de arquitectura. Además, la capacidad de apreciar el uso del sistema (según la comprensión de los deseos del usuario o los objetivos comerciales) y traducirlos en una interacción mejorada y la funcionalidad requerida también está en la reserva del arquitecto. A veces pienso que los analistas de negocios piensan que este es su rol y, por lo tanto, puede crear cierta tensión entre aquellos que capturan los requisitos y aquellos que hacen lo que se conoce como diseño conceptual: la creación de conceptos que modelan lo que el usuario quiere hacer, y cómo debe funcionar el sistema o la aplicación.

Por lo tanto, para dar un ejemplo en el ámbito de la arquitectura de software o el diseño de software: la arquitectura de software para una solución compleja de múltiples capas puede analizar la funcionalidad del usuario final (y su ajuste dentro del navegador, por ejemplo), y cómo la aplicación general pueden operar en términos de seguridad, múltiples formas, estilo general y marcos o paneles, etc. También pueden ver lo que se coloca en el middleware o la capa de servicio, y qué patrón general podría ser necesario (por ejemplo, modelo-vista-controlador), cuáles son los grandes objetos (por ejemplo, cliente, producto, inventario, pedido, etc.) y qué entidades de datos podrían ir en qué fuente de datos (por ejemplo, información del cliente en una fuente de datos, historial en otra, actividad en otra, por ejemplo) El método de persistencia podría ser el mejor (p. ej., basado en objetos, basado en conjuntos de datos, basado en gráficos, etc.) e instalaciones de marco comunes como registro, instrumentación, control de acceso, etc.

El diseñador lo llevaría al siguiente nivel y detallaría, o incluso combinaría y mejoraría el diseño con el propósito de implementarlo; modelos de clase completa, diseños de pantalla e interacciones, modelos de eventos, implementación de persistencia e integridad (por ejemplo, objetos relacionados, generación de claves, verificaciones de integridad de atributos, almacenamiento en caché, etc.). El paso del diseño a la implementación sería un paso más pequeño que el conceptual y el lógico, lo que a menudo conduce a suposiciones e inconsistencias entre desarrolladores o en sistemas más grandes, equipos de desarrollo completos.

Personalmente, prefiero no crear una gran división entre arquitectura y diseño, ya que veo que están entrelazados, pero eso es probablemente porque estoy a favor de una definición de diseño más sesgada artísticamente: tomar un problema y diseñar una solución que resuelva el problema. problema y tiene beneficios más amplios si es posible (a veces llamados no funcionales o cualidades, ninguno de los términos hace justicia a la OMI). Por lo tanto, una aplicación bien diseñada no solo proporciona la funcionalidad para el usuario, sino que la hace fácil y conveniente de usar, y se ve hermosa, haciendo que la experiencia en general sea una alegría. Si eso suena como Apple (al menos como era), entonces mis disculpas a los del campo de Microsoft. Eso sí, habiendo visto Surface Studio, las cosas pueden estar cambiando.

Disculpe las opiniones personales aquí, y espero que lea más allá de ellas para obtener una idea de dónde podría detenerse la arquitectura de software y comenzar el diseño de software. Todos estos términos son amplios, a menudo sobrecargados y sujetos a opinión; Este es solo otro que espero sea apreciado.