arquitecto de hardware

Los ingenieros, como colectivo, no se caracterizan por comprender ni responder con facilidad a las necesidades humanas, ni por desarrollar productos funcionales y estéticamente atractivos. De los arquitectos se espera que comprendan las necesidades humanas y desarrollen productos funcionales y estéticamente atractivos. Un buen arquitecto actúa como intermediario entre el usuario/patrocinador y los ingenieros, e incluso entre ingenieros de diferentes especialidades. 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 derivación de requisitos e implementación de dicha visión.

Determinar lo que los usuarios/patrocinadores realmente desean, en lugar de lo que dicen desear, no es ingeniería, es un arte. Un arquitecto no sigue un procedimiento exacto. Se comunica con los usuarios/patrocinadores de forma altamente interactiva; juntos extraen los requisitos reales necesarios para el sistema diseñado. El arquitecto de hardware debe mantenerse en comunicación constante con los usuarios finales (o con un arquitecto de sistemas). Por lo tanto, el arquitecto debe estar familiarizado con el entorno y el problema del usuario. El ingeniero solo necesita tener un profundo conocimiento del espacio potencial de soluciones de ingeniería.

El usuario/patrocinador debe considerar al arquitecto como su representante y proporcionar toda la información a través de él. Generalmente, se desaconseja la interacción directa con los ingenieros del proyecto, ya que existe un alto riesgo de malentendidos. La especificación de requisitos del usuario debe ser un producto conjunto del usuario y el arquitecto de hardware (o de los arquitectos de sistemas y hardware): el usuario aporta sus necesidades y deseos, y el arquitecto aporta su conocimiento sobre lo que es factible dentro de las limitaciones de costo y tiempo. El momento óptimo para redactar la primera versión de la prueba de aceptación , que posteriormente debe mantenerse actualizada rigurosamente con los requisitos, es cuando las necesidades del usuario se traducen en un conjunto de requisitos de alto nivel. De esta manera, el usuario tendrá total claridad sobre lo que recibirá. Esto también sirve como protección contra requisitos imposibles de probar, malentendidos y la ampliación de los requisitos.

El desarrollo de los requisitos de ingeniería de hardware de primer nivel no es un ejercicio puramente analítico, sino que debe involucrar tanto al arquitecto como al ingeniero de hardware. Si se deben realizar concesiones para cumplir con limitaciones como el costo, el cronograma, el consumo de energía o el espacio, 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 limitaciones, pero que garantice un producto funcional y confiable. El arquitecto se preocupa principalmente por la comodidad y la usabilidad del producto; el ingeniero se preocupa principalmente por la producibilidad y la utilidad del mismo.

La verdadera función de un sistema de ingeniería es proporcionar los servicios necesarios al usuario. Sin embargo, a medida que los sistemas se vuelven más grandes y complejos, y su enfoque se aleja de los componentes de hardware simples, la aplicación limitada de los principios tradicionales de desarrollo de hardware resulta insuficiente; se hace necesaria la aplicación de los principios más generales de la arquitectura de hardware al diseño de (sub)sistemas. Una arquitectura de hardware es también un modelo simplificado del producto final; su función principal es definir los componentes de hardware y sus relaciones entre sí para que el conjunto se perciba como una representación coherente, completa y correcta de lo que el usuario tenía en mente, especialmente en la interfaz hombre-máquina. También se utiliza para asegurar que los componentes encajen y se relacionen de la manera deseada.

Es necesario distinguir entre la arquitectura del mundo del usuario y la arquitectura del hardware diseñado. 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 diseñado. El sistema diseñado 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 la IHM. En ausencia de un arquitecto, existe una tendencia desafortunada a confundir ambas arquitecturas, ya que el ingeniero piensa en términos de hardware, mientras que el usuario puede 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 proporcionar la información necesaria a clientes y empleados. Se espera que un arquitecto de hardware combine el conocimiento tanto de la arquitectura del mundo del usuario como de todas las arquitecturas de ingeniería de hardware potencialmente útiles. La primera es una actividad conjunta con el usuario; la segunda, una actividad conjunta con los ingenieros. El producto consiste en un conjunto de requisitos de alto nivel que reflejan las necesidades del usuario y que los ingenieros pueden utilizar para desarrollar los requisitos de diseño de los sistemas de hardware.

Dado que los requisitos evolucionan a lo largo de un proyecto, especialmente uno de larga duración, se necesita un arquitecto hasta que el sistema de hardware sea aceptado por el usuario: el arquitecto es la mejor garantía de que ningún cambio o interpretación realizada durante el desarrollo comprometa el punto de vista del usuario.

La mayoría de los ingenieros de hardware son especialistas. Conocen a fondo las aplicaciones del diseño y desarrollo de hardware, aplican sus conocimientos a situaciones prácticas (es decir, resuelven problemas reales), evalúan la relación coste-beneficio de diversas soluciones dentro de su especialidad y garantizan el correcto funcionamiento de sus diseños. Los arquitectos de hardware son generalistas. No se espera que sean expertos en una tecnología o enfoque de hardware específico, sino que tengan conocimientos de varios y sean capaces de evaluar su aplicabilidad a situaciones concretas. También aplican sus conocimientos a situaciones prácticas, pero evalúan la relación coste-beneficio de diversas soluciones que utilizan diferentes tecnologías de hardware (por ejemplo, componentes desarrollados específicamente frente a componentes comerciales) y se aseguran de que el sistema en su conjunto funcione según las expectativas del usuario.

Muchos componentes de hardware comerciales o ya desarrollados pueden seleccionarse de forma independiente según restricciones como el coste, la respuesta, el rendimiento, etc. En algunos casos, el arquitecto puede ensamblar el sistema final sin ayuda. En otros, puede que necesite la ayuda de un ingeniero de hardware para seleccionar los componentes y diseñar y construir cualquier función específica. Los arquitectos (o ingenieros) también pueden recurrir a especialistas en seguridad, comunicaciones, hardware especializado, gráficos, factores humanos, pruebas y evaluación, control de calidad, RMA, gestión de interfaces, etc. Un equipo de arquitectura de hardware eficaz debe tener acceso inmediato a especialistas en áreas críticas.

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. Es decir, si estamos construyendo un complejo de viviendas, podemos tener un arquitecto para todo el complejo y uno para cada tipo de edificio, como parte de un equipo de arquitectura.

Los sistemas de hardware de gran tamaño también requieren un arquitecto y un gran talento en ingeniería. Si el sistema es lo suficientemente grande y complejo, el arquitecto jefe de sistemas de hardware puede delegar parte del trabajo en arquitectos subordinados, aunque todos formen parte de un equipo arquitectónico conjunto. Sin embargo, el arquitecto nunca debe ser visto como un supervisor de ingeniería.

El arquitecto debe subdistribuir los requisitos de hardware entre los componentes o subsistemas principales que estén dentro del alcance de un único ingeniero de hardware, gerente de ingeniería o arquitecto subordinado. Idealmente, cada componente o subsistema de hardware 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 dicho sistema. Solo es necesario conocer las limitaciones bajo las cuales se espera que opere el subsistema.

Un buen arquitecto garantiza que el sistema, por complejo que sea, se construya sobre conceptos relativamente simples y claros para cada subsistema o capa, fácilmente comprensibles para todos, especialmente para el usuario, sin necesidad de formación especializada. El arquitecto utilizará un mínimo de reglas 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 del usuario (una vez que el sistema está 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 de hardware se estructura en capas para mantenerla suficientemente simple en cada nivel , de modo que resulte comprensible para una sola persona. A medida que se asciende en el sistema, 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 siempre es responsabilidad principal del arquitecto o arquitectos. Es el principal medio por el cual el arquitecto demostrará al usuario que el hardware se ajusta al diseño original y que todos los arquitectos e ingenieros subordinados han cumplido sus objetivos. Los proyectos de gran envergadura suelen ser dinámicos, con cambios que el usuario necesita (por ejemplo, a medida que cambian sus problemas) o que se esperan de él (por ejemplo, por motivos de coste o plazos). Sin embargo, las pruebas de aceptación deben mantenerse actualizadas en todo momento. Son el principal medio por el cual el usuario se mantiene informado sobre el rendimiento del producto final. Además, constituyen el objetivo principal hacia el cual todo el personal subordinado debe diseñar, construir y probar.

Un arquitecto de edificios utiliza bocetos, maquetas y planos. Un arquitecto de sistemas de hardware debe utilizar bocetos, maquetas y prototipos para analizar diferentes soluciones y resultados con el usuario o el arquitecto del sistema, los ingenieros y los arquitectos subordinados. Una versión preliminar del manual de usuario es invaluable, especialmente en conjunto con un prototipo. Se debe evitar explícitamente el uso de un conjunto de requisitos (de ingeniería) como medio de comunicación con los usuarios. Un conjunto de requisitos o especificaciones bien redactados solo son comprensibles para la comunidad de ingenieros, al igual que un contrato legal lo es para los abogados.