No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Objetivos del arquitecto

7/24
Recursos

El arquitecto conecta los stakeholder con el sistema a construir. Cada uno de los roles que tienen los SH afectan de diferente forma el sistema.

Aportes 48

Preguntas 7

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

Objetivos del arquitecto.
El arquitecto tiene varias partes interesadas 鈥渟takeholders鈥 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.

驴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 鈥淧artes 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/

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.

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

  • Dominio de arquitectura de software, metodologi虂a de componentes y su interaccio虂n.
  • Conocimiento de las tecnologi虂as de comunicacio虂n disponibles.
  • Esta虂ndares y normas a aplicar en la construccio虂n de software de la tecnologi虂a a su cargo.
  • Conocimiento en programacio虂n avanzados en varios lenguajes, arquitecturas y paradigmas.
  • Manejo de herramientas para la gestio虂n de requerimientos y ambientes de desarrollo.
  • Lecto-comprensio虂n y elementos de redaccio虂n en ingle虂s.
    Conocimiento avanzado de Bases de Datos (tanto en la rama de programacio虂n como administracio虂n).
  • Conocimiento avanzado de comunicacio虂n entre aplicaciones: SOA, Servicios Web (SOAP, REST), protocolos y lenguajes de comunicacio虂n (XML, JSON).
  • Conocimientos de Ingenieri虂a del Software.
  • Pra虂cticas de Testing y Refactoring.
  • Conocimiento de metodologi虂as de ana虂lisis como UML u otras.
  • Conocimiento de metodologi虂as a虂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
    鈥揟iempo
    鈥 Presupuesto
  • Maneger
    鈥揊ormar y administrar equipos
    鈥揗odular
  • Dev
    鈥揊谩cil de implementar
    鈥 F谩cil de mantener
  • Usuario
    鈥揅onfiable
    -QA
    鈥揊谩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.

Stackeholder Requerimiento Arquitecto
Cliente Entrega en tiempo y dentro del presupuesto Encontrar riesgos altos y evitar que afecten al desarrollo del sistema
Manager Desarrollo de forma independiente, equipos autogestionados Modularizacion, flexibilidad en el sistema que se esta implementando.
Developer Software f谩cil de implementar y f谩cil de mantener Flexibilidad, mantenibilidad, capacidad de cambio del sw
Usuario Sistema confiable Disponibilidad y Confiabilidad del sistema, decidir estrategia para atacar estos atributos puntuales
QA Facil de probar, sistema estimulado, modularizado Decisiones de arquitectura con la modularizacion y con la capacidad de prueba

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 鈥減uedes 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 鈥渟takeholders鈥 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铆

El arquitecto es el que crea el sistema y los stackeholders son los que se ven afectados por el sistema que crea el arquitecto

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: 鈥淥bjetivos 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