arquitecto de sistemas

Se espera que los arquitectos comprendan las necesidades humanas y desarrollen productos funcionales y estéticamente atractivos. Un buen arquitecto es también el principal responsable de preservar la visión del usuario sobre el producto final, así como del proceso de definición e implementación de dicha visión.

Los arquitectos no siguen procedimientos exactos. Se comunican con los usuarios/patrocinadores de forma altamente interactiva y relativamente informal; juntos extraen los requisitos reales necesarios para el sistema final diseñado. El arquitecto debe mantenerse en comunicación constante con los usuarios finales y con los ingenieros de sistemas (principales). Por lo tanto, debe conocer a fondo el entorno y el problema de los usuarios, así como los entornos de ingeniería de los posibles espacios de solución.

La especificación de requisitos del usuario debe ser un producto conjunto de los usuarios y el arquitecto: los usuarios aportan sus necesidades y deseos, y el arquitecto aporta su conocimiento sobre lo que es factible dentro de las limitaciones de costo, tiempo y demás. Cuando las necesidades de los usuarios se traducen en un conjunto de requisitos de alto nivel, es también el mejor momento para escribir la primera versión de la prueba de aceptación , que posteriormente debe mantenerse rigurosamente actualizada con los requisitos. De esta manera, los usuarios tendrán total claridad sobre lo que obtienen. Además, sirve como protección contra requisitos imposibles de probar, malentendidos y la ampliación de requisitos.

El desarrollo del primer nivel de requisitos de ingeniería no es un ejercicio puramente analítico, sino que también debe involucrar tanto al arquitecto como al ingeniero. Si se deben realizar concesiones para cumplir con las restricciones, el arquitecto debe asegurarse de que el producto final y su apariencia general no se alejen demasiado de la intención del usuario. El ingeniero debe centrarse en desarrollar un diseño que optimice las restricciones, pero que garantice un producto funcional, fiable, extensible y robusto. La verdadera función de un sistema de ingeniería es proporcionar los servicios necesarios a los usuarios. Sin embargo, a medida que los sistemas se vuelven más grandes y complejos, y que su enfoque se aleja de los componentes simples de hardware y software, se ha constatado que la aplicación limitada de los principios tradicionales de desarrollo de sistemas es insuficiente; se considera necesaria la aplicación de principios más generales de arquitectura de sistemas, hardware y software al diseño de (sub)sistemas. La arquitectura también puede considerarse un modelo simplificado del producto final. Su función principal es definir las partes y sus relaciones entre sí para que el conjunto sea una representación coherente, completa y correcta de lo que los usuarios tenían en mente, especialmente en el caso de la interfaz hombre-máquina. Asimismo, se utiliza para garantizar que las partes encajen y se relacionen de la forma deseada.

Es necesario distinguir entre la arquitectura del mundo del usuario y la arquitectura de los sistemas de ingeniería. La primera representa y aborda problemas y soluciones en el mundo del usuario . Se plasma principalmente en las interfaces hombre-máquina (IHM) del sistema de ingeniería. El sistema de ingeniería representa las soluciones de ingeniería : cómo el ingeniero propone desarrollar, seleccionar y combinar los componentes de la infraestructura técnica para dar soporte a las IHM. En ausencia de un arquitecto experimentado, existe una tendencia desafortunada a confundir ambas arquitecturas. Sin embargo , el ingeniero piensa en términos de hardware y software y en el espacio de soluciones técnicas, mientras que los usuarios pueden estar pensando en resolver el problema de transportar personas del punto A al punto B en un tiempo razonable y con un gasto energético razonable, o de hacer llegar la información necesaria a clientes y empleados. Se espera que un arquitecto de sistemas combine el conocimiento tanto de la arquitectura del mundo del usuario como de las arquitecturas de sistemas de ingeniería (todas las potencialmente útiles) . La primera es una actividad conjunta con los usuarios; la segunda, con los ingenieros. El producto consiste en un conjunto de requisitos de alto nivel que reflejan las necesidades de los usuarios y que los ingenieros pueden utilizar para desarrollar los requisitos de diseño de los sistemas.

Dado que los requisitos evolucionan a lo largo de un proyecto, especialmente si es largo, se necesita un arquitecto hasta que el sistema sea aceptado por el usuario: el arquitecto garantiza que todos los cambios e interpretaciones realizados durante el desarrollo no comprometan el punto de vista de los usuarios.

Los arquitectos son generalistas. No se espera que sean expertos en una sola tecnología, sino que tengan conocimientos de diversas tecnologías y sean capaces de evaluar su aplicabilidad a situaciones específicas. Además, aplican sus conocimientos a situaciones prácticas, pero evalúan la relación costo-beneficio de distintas soluciones que utilizan diferentes tecnologías (por ejemplo, hardware, software o métodos manuales) y se aseguran de que el sistema en su conjunto funcione según las expectativas de los usuarios.

Muchos componentes de hardware y software comerciales, ya sean estándar o desarrollados, pueden seleccionarse de forma independiente según restricciones como el costo, la capacidad de respuesta, el rendimiento, etc. En algunos casos, el arquitecto puede ensamblar el sistema final prácticamente sin ayuda. En otros casos, puede necesitar la asistencia de un ingeniero de hardware o software para seleccionar componentes y diseñar y construir funciones específicas. Los arquitectos (o ingenieros) también pueden recurrir a otros especialistas en seguridad , comunicaciones , hardware especializado, gráficos , factores humanos , pruebas y evaluación , control de calidad , confiabilidad , mantenibilidad , disponibilidad , gestión de interfaces , etc. Un equipo de arquitectura de sistemas eficaz debe tener acceso a especialistas en áreas críticas según sea necesario.

Un arquitecto que planifica un edificio trabaja en el diseño general, asegurándose de que sea agradable y funcional para sus habitantes. Si bien un solo arquitecto puede ser suficiente para construir una vivienda unifamiliar, pueden ser necesarios varios ingenieros, además, para resolver los problemas específicos que surgen al diseñar un edificio de gran altura. Si el proyecto es lo suficientemente grande y complejo, algunas partes de la arquitectura pueden diseñarse como componentes independientes. Es decir, si estamos construyendo un complejo de viviendas, podemos tener un arquitecto para todo el complejo y otro para cada tipo de edificio, como parte de un equipo arquitectónico.

Los sistemas de automatización de gran tamaño también requieren un arquitecto y un gran talento en ingeniería. Si el sistema diseñado es lo suficientemente grande y complejo, el arquitecto de sistemas puede delegar parte del trabajo a un arquitecto de hardware o a un arquitecto de software, aunque todos ellos pueden formar parte de un equipo arquitectónico conjunto.

El arquitecto debe subdistribuir los requisitos del sistema entre componentes o subsistemas principales que estén dentro del alcance de un único ingeniero de hardware o software, o de un gerente y equipo de ingeniería. Sin embargo, el arquitecto nunca debe ser visto como un supervisor de ingeniería. (Si el elemento es suficientemente grande o complejo, el arquitecto jefe subdistribuirá partes a arquitectos más especializados). Idealmente, cada componente o subsistema es un objeto suficientemente independiente como para poder probarse como un componente completo, separado del conjunto, utilizando únicamente un banco de pruebas sencillo para proporcionar entradas simuladas y registrar salidas. Es decir, no es necesario saber cómo funciona un sistema de control de tráfico aéreo para diseñar y construir un subsistema de gestión de datos para el mismo. Solo es necesario conocer las restricciones bajo las cuales se espera que opere el subsistema.

Un buen arquitecto garantiza que el sistema, por complejo que sea, se base en conceptos relativamente simples y claros para cada subsistema o capa, y que sea fácilmente comprensible para todos, especialmente para los usuarios, sin necesidad de formación especializada. El arquitecto utilizará un mínimo de heurísticas para asegurar que cada partición esté bien definida y libre de chapuzas , soluciones improvisadas , atajos o detalles y excepciones confusos. A medida que evolucionan las necesidades de los usuarios (una vez implementado y en funcionamiento), resulta mucho más sencillo desarrollar posteriormente un concepto simple que uno plagado de excepciones, casos especiales y mucha letra pequeña.

La arquitectura por capas es importante para mantenerla suficientemente simple en cada nivel , de modo que siga siendo comprensible para una sola persona. A medida que se asciende en las capas, los sistemas completos de las capas inferiores se convierten en componentes simples de las capas superiores, e incluso pueden desaparecer por completo en las capas más altas.

La prueba de aceptación es una responsabilidad fundamental del arquitecto de sistemas. Es el principal medio por el cual el líder del programa demostrará a los usuarios que el sistema funciona según lo previsto originalmente y que todos los arquitectos e ingenieros involucrados han cumplido sus objetivos.

Un arquitecto de edificios utiliza bocetos, modelos y planos. Un arquitecto de sistemas de automatización (o de software o hardware) debería utilizar bocetos, modelos y prototipos para analizar diferentes soluciones y resultados con usuarios, ingenieros y otros arquitectos. Una versión preliminar del manual de usuario es invaluable, especialmente junto con un prototipo. Sin embargo, es importante crear un conjunto de requisitos o especificaciones viables y bien redactados que sean razonablemente comprensibles para el cliente (para que pueda aprobarlos correctamente, pero los requisitos principales de los usuarios deben estar recogidos en un manual de usuario preliminar para mayor claridad). Debe utilizar un lenguaje preciso e inequívoco para que los diseñadores y otros implementadores no tengan dudas sobre los significados o intenciones. En particular, todos los requisitos deben ser verificables , y el borrador inicial del plan de pruebas debe desarrollarse simultáneamente con los requisitos. Todas las partes interesadas deben aprobar las descripciones de las pruebas de aceptación , o su equivalente, como único determinante del cumplimiento de los requisitos, al inicio del programa.