Arquitecto de sistemas
Un arquitecto de sistemas es la persona responsable de:
- Servir de interfaz con los usuarios y patrocinadores, así como cualquier otro que está involucrado en determinar sus necesidades.
- Generar los niveles más altos de requisitos del sistema, basados en las necesidades del usuario, así como, algunas otras limitantes tales como costos y tiempos.
- Asegurarse de que este alto conjunto de requisitos sea consistente, completo, correcto y operacional.
- Llevar a cabo análisis costo-beneficio para determinar qué costos se cumplen mejor, ya sea manualmente, por software o con hardware; maximizando así los componentes ya desarrollados o los comerciales.
- Desarrollar algoritmos de particionado (y otros procesos) para economizar los requisitos en particiones discretas de manera que se necesite un mínimo de comunicación entre las particiones y los usuarios con el sistema.
- Partir grandes sistemas en (capas sucesivas de) subsistemas y componentes que puedan ser manipulados por un solo ingeniero, equipo de ingenieros o arquitectos subordinados.
- Asegurar que se alcance el máximo de robustez de arquitectura.
- Generar una serie de requisitos de pruebas de aceptación, las cuales junto con los diseñadores, ingenieros de pruebas, y el usuario determinen si se han cumplido los requisitos, especialmente para las interfaces de usuario.
- Generar bosquejos, modelos, guías de usuario y prototipos que mantengan en acuerdo y al corriente a los ingenieros con los usuarios.
Antecedentes
La arquitectura de grandes sistemas se desarrolló como una vía de manejar los sistemas que son demasiado amplios de concebir para una sola persona. Los sistemas de esta envergadura se están convirtiendo en la norma.
Usuarios y patrocinadores
Los ingenieros en grupo no tienen una buena reputación en cuanto a su respuesta a las necesidades humanas, como resultado de ello los productos resultantes que producen son poco estéticos. De los arquitectos se espera que entiendan las necesidades humanas, y por lo tanto produzcan productos estéticos y humanamente funcionales. Un buen arquitecto es aquel que traduce entre los usuarios/patrocinadores e ingenieros, e incluso sólo entre ingenieros de distintas especialidades. Un buen arquitecto es también aquel que se esfuerza por mantener la visión del producto final del usuario, así como, los procesos que se derivan de los requisitos y de la implementación de esa visión.
El hecho de determinar que es lo que los usuarios/patrocinadores realmente desean, en vez de lo que ellos dicen querer, no es ingeniería- es un arte. Un arquitecto nunca sigue un procedimiento en especial. El/Ella se comunica con los usuarios/patrocinadores de una manera altamente interactiva, de manera que pueda extraer los verdaderos requisitos necesarios para llevar a cabo la ingeniería del sistema. El arquitecto debe mantener una constante comunicación con sus usuarios finales. Es más, los arquitectos deben famliarizarse íntimamente con el ambiente de los usuarios y su problemática.
Requisitos de Alto Nivel (High Level Requirement)
El usuario/patrocinador debe ver al arquitecto como el representante del usuario al que debe proporcionar toda la información. No se recomienda que haya una interacción directa con los ingenieros de proyecto, ya que existen grandes posibilidades de que haya problemas de entendimiento. La especificación de los requisitos del usuario deben ser un producto de empalme entre el usuario y el arquitecto: el usuario expresa sus necesidades y su lista de deseos, el arquitecto aporta conocimientos respecto a que es lo que puede ser más factible en términos de costo y tiempo. Cuando las necesidades del usuario han sido traducidas a un conjunto de requisitos de alto nivel, se recomienda que se inicien las primeras versiones de pruebas de aceptación, las cuales debieran ser, actualizadas religiosamente con los requisitos. De esta manera, el usuario tendrá siempre en claro que es lo que obtiene. También sirven como un escudo en contra de requisitos no probados y desentendidos.
El desarrollo del primer nivel de ingeniería de requisitos es un ejercicio no completamente analítico que debe involucrar a los arquitectos e ingenieros. En caso de que se hagan compromisos acordes a los costos, tiempos, energía o espacio, el arquitecto debe asegurarse de que el producto final no se aleje de lo que el usuario desea. El ingeniero debe enfocarse en desarrollar algo que optimice las limitaciones pero a su vez debe asegurarse de que se produzca un producto confiable. Al arquitecto le concierne el confort y usabilidad, mientras que al ingeniero le corresponde la productividad y utilidad del producto principalmente.
La función de un sistema de ingeniería es principalmente proveer de los servicios necesarios al usuario. Debido a que los sistemas se están volviendo cada vez más grandes y complejos, se ha encontrado que los sistemas tradicionales de desarrollo se han vuelto insuficientes, se ha visto la necesidad de recurrir a la aplicación de principios de arquitectura de sistemas, hardware y software para el diseño de subsistemas. La arquitectura es un modelo simplificado del producto final— su función principal es la de definir sus partes y las relaciones entre cada una de ellas, de manera que el sistema sea consistente, completo y represente lo que el usuario tiene en mente— especialmente las interfaces hombre-máquina. También se utiliza para asegurarse de que todas las partes encajan correctamente y se relacionan en la manera deseada.
Es necesario distinguir entre la arquitectura del mundo de usuario y la arquitectura de ingeniería de sistemas. El anterior representa y trata los problemas y soluciones en el mundo de usuario. Su acción se captura principalmente en las interfaces hombre-máquina del sistema. El sistema representa las soluciones de ingeniería— la manera en que el ingeniero propone el desarrollo y/o selecciona y combina los componentes de la infraestructura técnica para darle soporte a las interfaces de usuario. Cuando no hay arquitectos, existe una desafortunada tendencia a confunddir las dos arquitecturas, esto debido a que el ingeniero piensa las cosas en términos de hardware y software, mientras que el usuario pudiera estar pensando en términos de resolver el problema de llevar a las personas desde un punto A al punto B en un periodo razonable de tiempo y con una utilización razonable de energía. Mientras que del arquitecto de sistemas se espera que haya una combinación de conocimientos, tales como del arquitecto del mundo de usuario y (todo el potencial) de los arquitectos de ingeniería de sistemas. La anterior es una actividad que articula con el usuario; la otra es una actividad que articula con los ingenieros. El producto es una serie de requisitos de alto nivel que reflejan aquellos requisitos del usuario que pueden ser utilizados por los ingenieros para desarrollar requisitos de diseño de sistemas.
Los arquitectos son necesitados hasta que los sistemas son aceptados por el usuario debido a que los requisitos evolucionan en el transcurso de los proyectos, especialmente aquellos que son muy largos.
Análisis costo/beneficio
La mayoría de los ingenieros son especialistas. Saben cuál es la aplicación de algún campo de la ingeniería de manera íntima, aplican sus conocimientos a situaciones prácticas— esto es, resuelven problemas del mundo real, evalúan el costo/beneficio de distintas soluciones de acuerdo a su especialidad y se aseguran de la correcta operación de lo que diseñan. Los arquitectos son más generales. Por lo general no son expertos en alguna tecnología específica, más bien de varias tecnologías de las cuales puedan decidir que tan aplicables son a situaciones específicas. También aplican sus conocimientos a situaciones prácticas, pero evalúan el costo/beneficio de distintas soluciones utilizando diversas tecnologías, por ejemplo, hardware contra software contra procesos manuales, y se aseguran de que el sistema como un todo se comporte de acuerdo a las expectativas del usuario.
Existen diversos productos comerciales así como componentes de hardware y software previamentte desarrollados que pueden ser seleccionados independientemente de acuerdo a limitaciones como costo, respuesta, rendimiento de procesamiento, etc. En algunos casos el arquitecto puede ensamblar el sistema final sin ser ayudado.
Capas y particionado
El arquitecto que planea la construcción de un edificio se esfuerza en todos los detalles de su diseño, asegurándose de que sea placentero y útil para sus hospedados. Mientras que un arquitecto puede ser suficiente para construir la casa para una familia, muchos ingenieros se podrían necesitar, en conjunto, para resolver problemas detallados que pudieran surgir al construir y diseñar un edificio. En caso de que el trabajo sea lo suficientemente grande y complejo, algunas partes del trabajo pueden ser sub arquitectadas. Esto significaría que si fuéramos a construir un complejo habitacional, podríamos tener un arquitecto por cada complejo, y uno por cada tipo de edificio como parte de un equipo arquitectónico.
Los grandes sistemas de automatización requieren de un arquitecto y un gran talento en ingeniería.
El arquitecto debe subasignar los requisitos del sistema a componentes mayores o subsistemas que se encuentren en el ámbito de un ingeniero de software, hardware, supervisor de ingeniería o arquitecto subordinado. (Si el objeto es lo suficientemente grande y/o complejo, el arquitecto en jefe debe sub asignar algunas porciones a arquitectos más especializados). Todos y cada uno de los componentes/subsistemas son objetos lo suficientemente independientes que pueden ser probados como componentes individuales, separados del todo utilizando pruebas y simulaciones que proporcionen entradas y salidas. En otras palabras, no es necesario saber como trabaja un sistema de control de tráfico aéreo para diseñar y construir un subsistema. Sólo es necesario saber bajo que restricciones operará el subsistema.
Pruebas de aceptación
Las pruebas de aceptación son la responsabilidad principal de los arquitectos. Significa también que los arquitectos tienen que probarle a los usuarios que el sistema es tal cual se planeó y que todos los arquitectos subordinados e ingenieros han cumplido con sus objetivos. Los grandes proyectos tienden a ser dinámicos, con cambios solicitados por el usuario, o esperados por ellos. Esto no sucede con las pruebas de aceptación, en donde las pruebas deben mantenerse al día en todo momento. Esto se traduce en que el usuario debe ser informado respecto a cómo debe realizarse el producto final. También actúan como el principal objetivo hacia el cual todo el personal subordinado debe diseñar y probar.
Proporcionar una buena comunicación entre usuarios e ingenieros
Un arquitecto de edificios utiliza bosquejos, modelos y dibujos. Es recomendable que un arquitecto de software de automatización de sistemas (de software o hardware) utilice modelos, dibujos y bosquejos para discutir las distintas soluciones y resultados con los usuarios, ingenieros y otros arquitectos. Las versiones preliminares de los manuales de usuario son invaluables, especialmente en conjunto con los prototipos. Una serie de (ingeniería) requisitos establece que se evite comunicar con los usuarios explícitamente. Sin embargo, es importante que se genere un set de requisitos bien escritos o especificaciones, que sean comprensibles por el cliente.
Véase también
- Ingeníería en Informática
- Ingeniería Técnica en Informática de Gestión
- Grado en Ingeniería Informática
- Arquitectura de sistema
- Arquitectura software / Arquitecto de software
- Arquitectura de hardware / Arquitecto de hardware
- Ingeniería de sistemas / Ingeniero de sistemas
- Ingeniería de software / Ingeniero de software
- Análisis de requisitos / Ingeniero de requisitos / Analista de negocios
- Diseño de sistemas