Objetivos del arquitecto

Objetivos del arquitecto.
El arquitecto tiene varias partes interesadas “stakeholders” el cual tiene que conectar esto requerimientos de cada stakeholders con la implementación del sistema.

Stakeholders involucrados con diferentes requerimientos:
• Cliente: Entrega a tiempo y que no rebase el presupuesto.
• Manager: Comunicación clara entre los equipos que participan en el desarrollo del sistema
• Dev: Que el desarrollo llevado acabo sea fácil de implementar y mantener
• Usuario: Disponibilidad del producto.
• QA: Fácil de probar.

El arquitecto de software debe gestionar los siguientes puntos para cada Stakeholder:
• Encontrar los riegos más altas que afecten en el desarrollo del sistema (Cliente)
• Modularización y flexibilidad del sistema que se está desarrollando (Manager)
• Modularidad, mantenibilidad y capacidad de cambio del software (Dev)
• Desisdir estrategias para la disponibilidad del sistema (Usuario)
• Que el sistema pueda ser modularizado y cada una destas partes pueda ser probado de forma fácil (QA).

La unión de estos requerimientos (funcionales / no funcionales) va a llevar al arquitecto a tomar decisiones que impactan directamente en el desarrollo del software.

El Arquitecto va a** conectar a las partes interesadas y los requerimientos de los mismos con la implementación del sistema**.
Es decir tiene una visión global del proyecto en general y debe diseñar el software de tal manera que cumpla con los requerimientos de todas las partes interesadas.

Partes interesadas o Stakeholders

Cliente
Quiere tener su sistema respetando el presupuesto establecido y entregado a tiempo. Debará preocuparse por encontrar cuáles son los mayores riesgos y evitarlos.

Manager
Querrá cumplir con los requerimientos del cliente y además tener la posibilidad de crear equipos que puedan autogestionarse y atacar diferentes partes del sistema de forma simultanea.

Dev
Que sea fácil de implementar y mantener.

Usuario
Que funcione, que haga lo que tiene que hacer cuando lo tenga que hacer.

Tester QA
Que sea fácil de probar

Con todo esto en mente el Arquitecto deberá tomar las mejores desiciones para que el impacto del diseño sea agradable para todas estas partes.

¿Qué son los stakeholders?
Los stakeholders son un grupo de personas afectadas por las decisiones de una empresa. En su traducción al español significa “Partes interesadas”.
¿Qué tipos existen?
Los stakeholders primarios: todas las personas que tienen un vínculo económico directo con la empresa, aquí entran los accionistas, socios, los trabajadores y clientes.
Los secundarios, hablan de aquellos que no participan directamente de la empresa, pero que sin ser primarios, también se ven afectados por los resultados de la misma. Aquí entran los competidores, el mercado o las personas en general.

info: https://rockcontent.com/es/blog/que-es-un-stakeholder/

** Un arquitecto debería tener habilidades en: **

• Dominio de arquitectura de software, metodología de componentes y su interacción.
• Conocimiento de las tecnologías de comunicación disponibles.
• Estándares y normas a aplicar en la construcción de software de la tecnología a su cargo.
• Conocimiento en programación avanzados en varios lenguajes, arquitecturas y paradigmas.
• Manejo de herramientas para la gestión de requerimientos y ambientes de desarrollo.
• Lecto-comprensión y elementos de redacción en inglés.
  Conocimiento avanzado de Bases de Datos (tanto en la rama de programación como administración).
• Conocimiento avanzado de comunicación entre aplicaciones: SOA, Servicios Web (SOAP, REST), protocolos y lenguajes de comunicación (XML, JSON).
• Conocimientos de Ingeniería del Software.
• Prácticas de Testing y Refactoring.
• Conocimiento de metodologías de análisis como UML u otras.
• Conocimiento de metodologías ágiles como SCRUM u otras.
• Conocimiento de herramientas de control de versiones como GIT u otras.
• Conocimientos de patrones de software empresarial.

Conceptos extraídos de:
- http://www.cessi.org.ar/perfilesit/detalle-de-arquitecto-de-software-3

Objetivos del arquitecto

• Conectar los requerimientos de los stakeholders con la implementación del sistema

Stakeholders:

• Cliente
  –Tiempo
  – Presupuesto
• Maneger
  –Formar y administrar equipos
  –Modular
• Dev
  –Fácil de implementar
  – Fácil de mantener
• Usuario
  –Confiable
  -QA
  –Fácil de comprobar

Tendria que haber visto este curso hace mucho tiempo, de hecho, lo habia empezado en su momento. Pero tenia supuestas prioridades y no logre terminarlo. Muchas cosas las he aprendido ya sobre la marcha, pero esto ha logrado que diera muchas opiniones sin base y a riesgo de plantear malas practicas incluso.
Es muy importante estar consciente de esto, tanto como arquitecto como desarrollador. Sumamente importante tener claro como se organiza y opera un equipo y tambien las responsabilidades de cada instancia!. Excelente contenido. Saludos😁

Stakeholders -> partes interesadas

un stakeholder puede ser el cliente ?

RESUMEN:
Objetivos del arquitecto

Es un intermediario entre partes interesadas y los requerimentos con la implementación del sistema.

Cliente: Entregas y resultados a tiempo, en presupuesto. Encontrar cuales son los riesgos más altos asociados al desarrollo.
Manager: Gestionar recursos para que tiempos se den. Gestor de equipos. Modularización y flexibilidad.
Dev: Que sea mantenible e implementable. Es necesario que pueda evolucionar.
Usuario: Que sea confiable y pueda usarse y estará disponible cuando se necesite.
QA: Que sea fácil de comprobar.Sistemas que cumplen atributos de calidad para porbarse. Que el sistema pueda probarse y que responda de determinada manera, y que pueda probarse poro modularización.

Los arquitectos conectan los stakeholders y sus requerimientos con la_ implementación del sistema_ => Estos roles(stakeholders) tienen diferentes requerimientos y estos_ afectaran_ de forma diferente al sistema => todos estos requerimientos guían al arquitecto en las decisiones de diseño que impactan sobre el sistema.

Objetivos de Arquitecto

Cada uno de los stakeholder tiene que ser conectado por el Arquitecto con sus requerimientos.Stakeholder -> Arquitecto -> Requerimientos = Implementaciónes en el Sistema.

Los Requerimientos de cada stakeholder afectan de forma única el sistema.

• Cliente: Entrega a tiempo y dentro del presupuesto.
• Manager: Permite equipos independientes y comunicación clara.
• Dev: Que sea fácil de implementar y de mantener.
• Usuario: Es confiable y estará disponible cuando lo necesite.
• QA: Es fácil de comprobar.

El arquitecto de software debe gestionar los siguientes puntos para cada Stakeholder:
• Encontrar los riegos más altas que afecten en el desarrollo del sistema (Cliente)
• Modularización y flexibilidad del sistema que se está desarrollando (Manager)
• Modularidad, mantenibilidad y capacidad de cambio del software (Dev)
• Desisdir estrategias para la disponibilidad del sistema (Usuario)
• Que el sistema pueda ser modularizado y cada una destas partes pueda ser probado de forma fácil (QA).

La unión de todos estos requerimientos (funcionales o no funcionales) van a llevar al arquitecto a tomar decisiones que impacten sobre el sistema.

Cada StakeHolder tiene sus propios requerimientos, los cuales el arquitecto de software tiene que tener en cuenta.

• Cliente: Tiene un tiempo límite para la entrega del producto.
• Manager: Requiere equipos independientes, cada uno con una responsabilidad clara
• Dev: Requieren que sea facil de implementar, de mantener y de evolucionar(Escalabilidad)
• Usuario: Requiere la disponibilidad y la confiabilidad del sistema, sin errores.
• QA o Tester: Es facil de testear o de comprobar, es decir que el sistema sea modularizado independientemente.

A tiempo.
Modulable.
Extendible.
Fiable.
Testeable.

El Stakeholder es el término en inglés que define a los interesados en un proyecto de desarrollo de software

Osea que el arquitecto es el que busca una solución para cada uno de los requerimientos. Esos requerimientos son como los límites que le dicen al arquitecto “puedes hacer todo lo que te imagines dentro de estos límites” aunque obviamente tampoco puede durar mucho tiempo y tiene que ser eficiente, y todo esto afecta a la creación del sistema. Esto es lo que al menos yo entendí.

con los requerimientos de los implicados en el desarrollo de una aplicación es el rol del arquitecto el dar solución satisfactoria a estos requerimientos sin afectar los demás roles

El arquitecto conecta los stakeholder y sus requerimientos que afectan directamente al sistema.

Objetivos del arquitecto

El arquitecto va a conectar a los StakeHolders y sus requerimientos con la implementation del sistema.

StakeHolders:

• Cliente
• Manager
• Dev
  -Usuario
• QA

Objetivos del Arquitecto
Tomar decisiones de diseño que impacten sobre el sistema tomando en cuenta a las partes interesadas o “stakeholders” conectando sus requerimientos con la implementación del sistema.

Objetivos del arquitecto

El arquitecto tiene diversas partes interesadas o stakeholders con los cuales él se tendrá que comunicar y recibir sus requerimientos los cuales afectaran de maneras diferentes al sistema.

StakeHolders:
* Cliente
* Manager
* Dev
* QA
* Usuario
Dados todos los requerimientos algunos funcionales y otros no-funcionales, el arquitecto tendrá que unirlos y tomar decisiones que impacten al diseño del sistema.

✅

Acá falta un stakeholder muy importante, el security engineer, quién debe velar porque el sistema sea seguro, cumpla con normatividad relacionada y esté disponible la mayor cantidad de tiempo posible.

La unión de todos los requerimientos funcionales y no funcionales van a llevar al arquitecto a tomar decisiones de diseño que impacte sobre el sistema a desarrollar.

El Arquitecto de Software debe ser una persona con amplios conocimientos técnicos, gran experiencia en programación y liderazgo.

Si te interesa conocer mas sobre las responsabilidades y las acciones de un arquitecto de software, te recomiendo que revises la metodología RUP, ya tiene sus años pero fue la base sobre la cual se montaron las diferentes metodologías existentes lo puedes ver aquí

La unión de estos requerimientos (funcionales / no funcionales) va a llevar al arquitecto a tomar decisiones que impactan directamente en el desarrollo del software.

buen video

En general el objetivo del arquitecto es hacer feliz a los stakeholders

La unión de todos los requerimientos de los Stakeholders (Cliente, Manager, Developers, Usuarios y QA) van ayudar al arquitecto a tomar decisiones de diseño para el sistema. Saludos, AF.

Osea, el arquitecto es el puente entre los stakeholders y el proyecto como tal, su tarea es combinar y cumplir con todos los requisitos de los stakeholders y hacer dentro de las limitaciones de la app

por fin entiendo un poco mas a fondo

excelente material Guido

El arquitecto de software toma decisiones de diseño que impacten el sistema a desarrollar.

gracias

Tomar las decisiones en base a los diferentes requerimientos de los roles involucrados en el proceso de desarrollo, permitirá implementar soluciones robustas.

conectar a los stakeholder con la implementación del sistema.

cliente
manager
dev
usuario
QA

tomar decisiones de diseño que impacten sobre el sistema a desarrollar.

cliente -> a tiempo y presupuesto
manager -> equipos independientes
dev -> facil de implementar y entender
usuario -> confiable
QA->facil de probar.

en resumen
conectar a todos los involucrados

La union de los requirimientos sean funcionales o no lleva a aquitectto a tomar desiciones

Difícil misión 😃 pero no imposible

Es aquí donde se evidencia la definición: “El conjunto de decisiones principales de diseño tomados en un sistema”, siendo este la unión de los requerimientos.

Buena clase!

Divide y Vencerás ¿Cómo? con Pequeños Módulos

Permitir dividir nuestras aplicaciones en pequeñas partes llamadas modulos con el ánimo de solucionar por partes un problema que en principio podría parecer gigante.

*7. Mis apuntes sobre: “Objetivos del arquitecto”.
Para entender los objetivos del arquitecto, es importante recordar que el arquitecto va a
tener diferentes partes interesadas o [stakeholders], y va a afectar de diferente manera
al desarrollo del sistema.

*Stakeholders: Cliente, Manager, Desarrolladores [Dev], Usuario, QA.*

Cliente: Va a querer el sistema en presupuesto y entregado a tiempo.

Manager: Va a tener en cuenta el requerimiento del cliente, pero también
permitir equipos independientes y comunicación clara (modularización y flexibilidad).

Desarrolladores: Fácil de implementar y mantener.

Usuario: Va a querer que sea confiable y estará disponible cuando lo 
necesite, va a tener que ver con su confiabilidad.

QA: Va a tener que ser fácil de probar, tiene que ver con los atributos de calidad
relacionados a la comprobación, que el sistema pueda estimularse y pueda responder, 
y responder siempre de manera consistente.

La unión de todos estos requerimientos (algunos funcionales y otros no funcionales), van a
llevar al arquitecto a tomar decisiones de diseño que impacten sobre el sistema desarrollado.

mi resumen:
cada persona tiene diferentes requerimientos ,y necesidades ,por lo cual el arquitecto debe saber entender las necesidades de cada interesado y el como solucionarlos, asi como saber que informacion es requeridad para cada uno acorde a sus necesidad