(En los entornos de automatización e ingeniería , el ingeniero o arquitecto de hardware abarca los campos de la ingeniería electrónica y la ingeniería eléctrica , con subespecialidades en sistemas analógicos , digitales o electromecánicos ).
El arquitecto de sistemas de hardware o el arquitecto de hardware es responsable de:
- Interfaz con un arquitecto de sistemas o partes interesadas del cliente . Hoy en día, es extraordinariamente raro que los sistemas de hardware suficientemente grandes y / o complejos requieran que un arquitecto de hardware no requiera un software sustancial y un arquitecto de sistemas. Por lo tanto, el arquitecto de hardware normalmente interactuará con un arquitecto de sistemas, en lugar de hacerlo directamente con los usuarios, patrocinadores u otras partes interesadas del cliente. Sin embargo, en ausencia de un arquitecto de sistemas, el arquitecto de sistemas de hardware debe estar preparado para interactuar directamente con las partes interesadas del cliente a fin de determinar sus necesidades (en evolución) que deben realizarse en el hardware. El arquitecto de hardware también puede necesitar interactuar directamente con un arquitecto o ingeniero (s) de software, o con otros ingenieros mecánicos o eléctricos.
- Generando el más alto nivel de requisitos de hardware, en función de las necesidades del usuario y otras limitaciones como el costo y el cronograma.
- Asegurarse de que este conjunto de requisitos de alto nivel sea coherente, completo, correcto y definido operativamente .
- Realizar análisis de costo-beneficio para determinar los mejores métodos o enfoques para cumplir con los requisitos de hardware; aprovechando al máximo los componentes comerciales disponibles en el mercado o ya desarrollados.
- Desarrollar algoritmos de partición (y otros procesos) para asignar todos los requisitos (hardware) presentes y previsibles en particiones de hardware discretas de modo que se necesite un mínimo de comunicaciones entre las particiones y entre el usuario y el sistema.
- Partición de grandes sistemas de hardware en (capas sucesivas de) subsistemas y componentes, cada uno de los cuales puede ser manejado por un solo ingeniero de hardware o un equipo de ingenieros.
- Asegurar que se desarrolle una arquitectura de hardware lo más robusta posible .
- Generar un conjunto de requisitos de prueba de aceptación , junto con los diseñadores, ingenieros de prueba y el usuario, que determinan que se han cumplido todos los requisitos de hardware de alto nivel, especialmente para la interfaz computadora-humano .
- Generar productos como bocetos, modelos , un manual de usuario temprano y prototipos para mantener al usuario y a los ingenieros constantemente actualizados y de acuerdo sobre el sistema que se proporcionará a medida que evoluciona.
Fondo
La arquitectura de sistemas grandes se desarrolló como una forma de manejar sistemas demasiado grandes para que una persona los concibiera, y mucho menos los diseñara. Los sistemas de este tamaño se están convirtiendo rápidamente en la norma, por lo que los enfoques arquitectónicos y los arquitectos son cada vez más necesarios para resolver los problemas de los grandes sistemas.
Usuarios y patrocinadores
Los ingenieros como grupo no tienen la reputación de comprender y responder cómodamente a las necesidades humanas o de desarrollar productos humanamente funcionales y estéticamente agradables. Se espera que los arquitectos comprendan las necesidades humanas y desarrollen productos humanamente funcionales y estéticamente agradables. Un buen arquitecto es un traductor entre el usuario / patrocinador y los ingenieros, e incluso entre solo ingenieros de diferentes especialidades. Un buen arquitecto es también el principal guardián de la visión del usuario del producto final y del proceso de derivar requisitos e implementar esa visión.
Determinar lo que realmente quieren los usuarios / patrocinadores, en lugar de lo que dicen que quieren, no es ingeniería, es un arte. Un arquitecto no sigue un procedimiento exacto. Se comunica con los usuarios / patrocinadores de una manera muy interactiva; juntos extraen los verdaderos requisitos necesarios para el sistema diseñado. El arquitecto de hardware debe permanecer constantemente en comunicación con los usuarios finales (o un arquitecto de sistemas). Por lo tanto, el arquitecto debe estar familiarizado con el entorno y el problema del usuario. El ingeniero solo necesita ser muy conocedor del espacio potencial de soluciones de ingeniería.
Requisitos de alto nivel
El usuario / patrocinador debe ver al arquitecto como el representante del usuario y proporcionar toda la información a través del arquitecto. En general, se desaconseja la interacción directa con los ingenieros de proyectos, ya que la posibilidad de malentendidos mutuos es muy alta. La especificación de los requisitos del usuario debe ser un producto conjunto del usuario y el arquitecto de hardware (o los arquitectos de sistemas y hardware): el usuario aporta sus necesidades y su lista de deseos, el arquitecto aporta el conocimiento de lo que probablemente resulte factible en términos de costo y tiempo. limitaciones. Cuando las necesidades del usuario se traducen en un conjunto de requisitos de alto nivel, también es el mejor momento para escribir la primera versión de la prueba de aceptación , que, a partir de entonces, debe mantenerse religiosamente actualizada con los requisitos. De esa manera, el usuario tendrá absolutamente claro lo que está obteniendo. También es una protección contra los requisitos no comprobables, los malentendidos y la propagación de requisitos.
El desarrollo del primer nivel de requisitos de ingeniería de hardware no es un ejercicio puramente analítico y también debe involucrar tanto al arquitecto como al ingeniero de hardware. Si se va a hacer algún compromiso, para cumplir con limitaciones como el costo, el horario, la energía o el espacio, el arquitecto debe asegurarse de que el producto final y la apariencia general no se alejen mucho de la intención del usuario. El ingeniero debe centrarse en desarrollar un diseño que optimice las limitaciones pero garantice un producto viable y fiable. El arquitecto se preocupa principalmente por la comodidad y facilidad de uso del producto; el ingeniero se preocupa principalmente por la producibilidad y la utilidad del producto.
La prestación de los servicios necesarios al usuario es la verdadera función de un sistema diseñado. Sin embargo, a medida que los sistemas se vuelven cada vez más grandes y complejos, y a medida que su énfasis se aleja de los componentes de hardware simples, la aplicación limitada de los principios tradicionales de desarrollo de hardware resulta insuficiente: la aplicación de los principios más generales de la arquitectura de hardware al diseño de Se considera necesario (sub) sistemas. Una arquitectura de hardware también es un modelo simplificado del producto final terminado; su función principal es definir los componentes de hardware y sus relaciones entre sí, de modo que el conjunto pueda verse como una representación coherente, completa y correcta de lo que el usuario tenía en mente, especialmente para la interfaz computadora-humano. También se utiliza para garantizar que los componentes encajen y se relacionen de la forma deseada.
Es necesario distinguir entre la arquitectura del mundo del usuario y la arquitectura de hardware diseñada. El primero representa y aborda problemas y soluciones en el mundo del usuario . Se captura principalmente en las interfaces computadora-humano (CHI) del sistema diseñado. El sistema de ingeniería representa las soluciones de ingeniería : cómo el ingeniero propone desarrollar y / o seleccionar y combinar los componentes de la infraestructura técnica para respaldar el CHI. En ausencia de un arquitecto, existe una desafortunada tendencia a confundir las dos arquitecturas, ya que el ingeniero piensa en términos de hardware, pero el usuario puede estar pensando en términos de resolver un problema de llevar a la gente del punto A al punto B en un una cantidad de tiempo razonable y con un gasto de energía razonable, o para hacer llegar la información necesaria a los clientes y al personal. Se espera que un arquitecto de hardware combine el conocimiento tanto de la arquitectura del mundo del usuario como de las arquitecturas de ingeniería de hardware (todas potencialmente útiles). La primera es una actividad conjunta con el usuario; esta última es una actividad conjunta con los ingenieros. El producto es un conjunto de requisitos de alto nivel que reflejan los requisitos del usuario y que los ingenieros pueden utilizar para desarrollar requisitos de diseño de sistemas de hardware.
Debido a que los requisitos evolucionan a lo largo de un proyecto, especialmente uno largo, 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 e interpretación realizados durante el curso del desarrollo comprometa el punto de vista del usuario. .
Análisis de costo-beneficio
La mayoría de los ingenieros de hardware son especialistas. Conocen íntimamente las aplicaciones del diseño y desarrollo de hardware, aplican su conocimiento a situaciones prácticas, es decir, resuelven problemas del mundo real, evalúan los costos-beneficios de varias soluciones dentro de su especialidad de hardware y garantizan el correcto funcionamiento de lo que diseñan. Los arquitectos de hardware son generalistas. No se espera que sean expertos en ninguna tecnología o enfoque de hardware, pero se espera que conozcan muchos y sean capaces de juzgar su aplicabilidad a situaciones específicas. También aplican su conocimiento a situaciones prácticas, pero evalúan el costo / beneficio de varias soluciones utilizando diferentes tecnologías de hardware, por ejemplo, componentes de hardware especialmente desarrollados versus componentes de hardware disponibles comercialmente, y aseguran que el sistema en su conjunto funcione de acuerdo con las expectativas del usuario.
Muchos componentes de hardware comercialmente disponibles o ya desarrollados pueden seleccionarse de forma independiente de acuerdo con limitaciones como el costo, la respuesta, el rendimiento, etc. En algunos casos, el arquitecto ya puede ensamblar el sistema final sin ayuda. O es posible que aún necesite la ayuda de un ingeniero de hardware para seleccionar componentes y diseñar y construir cualquier función de propósito especial. Los arquitectos (o ingenieros) también pueden contar con la ayuda de especialistas en seguridad, protección, comunicaciones, hardware para fines especiales, 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 especialidades críticas.
Particionamiento y estratificación
Un arquitecto que planifica un edificio trabaja en el diseño general, asegurándose de que sea agradable y útil para sus habitantes. Si bien un solo arquitecto puede ser suficiente para construir una casa unifamiliar, es posible que se necesiten muchos ingenieros, además, para resolver los problemas detallados que surgen cuando se diseña un edificio novedoso de gran altura. Si el trabajo es lo suficientemente grande y complejo, las partes de la arquitectura pueden diseñarse como componentes. Es decir, si estamos construyendo un conjunto de viviendas, es posible que tengamos un arquitecto para el conjunto, y uno para cada tipo de edificio, como parte de un equipo arquitectónico.
Los grandes sistemas de hardware también requieren un arquitecto y mucho talento en ingeniería. Si el sistema diseñado es lo suficientemente grande y complejo, el arquitecto jefe de sistemas de hardware puede delegar a los arquitectos subordinados algunas partes del trabajo, aunque todos pueden ser miembros de un equipo de arquitectura conjunto. Pero el arquitecto nunca debe ser visto como un supervisor de ingeniería.
El arquitecto debe subasignar los requisitos de hardware a los componentes o subsistemas principales que están dentro del alcance de un solo ingeniero de hardware, o gerente de ingeniería o arquitecto subordinado. Idealmente, cada uno de estos componentes / subsistemas de hardware es un objeto lo suficientemente independiente como para poder probarlo como un componente completo, separado del todo, utilizando solo un banco de pruebas simple para suministrar 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 él. Solo es necesario conocer las limitaciones bajo las cuales se espera que opere el subsistema.
Un buen arquitecto se asegura de que el sistema, por complejo que sea, se construya sobre conceptos relativamente simples y "limpios" para cada (sub) sistema o capa, fácilmente comprensible para todos, especialmente el usuario, sin una formación especial. El arquitecto utilizará un mínimo de reglas para garantizar que cada partición esté bien definida y libre de errores , soluciones , atajos o detalles confusos y excepciones. A medida que evolucionan las necesidades del usuario (una vez que el sistema está en el campo y en uso), es mucho más fácil desarrollar posteriormente un concepto simple que uno cargado de excepciones, casos especiales y mucha "letra pequeña".
Colocar la arquitectura de hardware en capas es importante para mantenerla lo suficientemente simple en cada capa para que siga siendo comprensible para una sola mente. A medida que se ascienden las capas, los sistemas completos en las capas inferiores se convierten en componentes simples en las capas superiores y pueden desaparecer por completo en las capas más altas.
Examen de ingreso
La prueba de aceptación siempre es responsabilidad principal del arquitecto o arquitectos. Es el medio principal por el cual el arquitecto demostrará al usuario que el hardware es como se planeó originalmente y que todos los arquitectos e ingenieros subordinados han cumplido sus objetivos. Los proyectos grandes tienden a ser dinámicos, con cambios a lo largo del camino que necesita el usuario (p. Ej., A medida que cambian sus problemas) o que se espera del usuario (p. Ej., Por razones de costo o de programación). Pero las pruebas de aceptación deben mantenerse actualizadas en todo momento. Son el principal medio por el cual se mantiene informado al usuario sobre el rendimiento del producto final. Y actúan como el objetivo principal hacia el cual todo el personal subordinado debe diseñar, construir y probar.
Buenas comunicaciones con usuarios e ingenieros
Un arquitecto de edificios utiliza bocetos, modelos, dibujos. Un arquitecto de sistemas de hardware debe usar bocetos, modelos y prototipos para discutir diferentes soluciones y resultados con el usuario o arquitecto del sistema, ingenieros y arquitectos subordinados. Una versión preliminar preliminar del manual del usuario es invaluable, especialmente junto con un prototipo. Se debe evitar explícitamente un conjunto de requisitos (de ingeniería) como medio de comunicación con los usuarios. Un conjunto bien escrito de requisitos, o especificaciones , es inteligible solo para la fraternidad de ingenieros, al igual que un contrato legal lo es para los abogados.
Personas
Ver también
- Arquitectura de sistemas / Arquitecto de sistemas
- Arquitectura de software / arquitecto de software
- Arquitectura de hardware
- Ingeniería de sistemas / Ingeniero de sistemas
- Ingeniería de software / Ingeniero de software
- Análisis de requerimientos
- Diseño de sistemas
- Ingenieria Eléctrica
- Ingeniería electronica