Introducción al curso de Fundamentos de Arquitectura de Software

1/24
Recursos

Aportes 118

Preguntas 5

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

Divide y vencerás

me acabo de dar cuenta que por aqui se iniciaba y yo empece por “Curso Profesional de Arquitectura de Software” ya me preguntaba yo porque estaba tan dificil el examen XD

Recomiendo esta serie de articulos donde se puede profundizar más en los temas que se van a ver. Tambien encontrarás una recomendación de libros.

Echale un vistazo 😃

El sistema elegido es el que permite la interacción entre el cajero y la facturación en los supermercados Carrefour.

Problemas que resuelve:

  • Sumatoria manual de los precios de los productos comprados por cada cliente.
  • Calculo de total y vuelto manual.
  • Utilización de Postnet para realizar pagos con tarjeta de crédito.

Requerimientos no funcionales:

  • Seguridad en el ingreso de datos sensibles del cliente.
  • Seguridad en la transacción de cada compra.
  • Capacidad de leer varios códigos de barra en el menor tiempo posible.
  • Velocidad al realizar la transacción.
  • Ubicación favorable de la interfaz gráfica para la salud del cajero (que puede pasar muchas horas utilizándola).

Si tuviera que hacer de este sistema un “producto reutilizable” en otros escenarios:

¿Como cambiaría su arquitectura? Agregaría portabilidad para poder transportar la infraestructura externa libremente de un lado a otro, y la infraestructura principal pasaría a ubicarse en la nube para ahorro de gastos y posibilidad de escalabilidad.

¿En que otro escenario debería repensarse completamente? Debería repensarse completamente en un contexto en el que la competencia utiliza sistemas automatizados y veloces sin intervención humana para la facturación de cada compra, ya que esto supondría la futura obsolescencia en mi negocio.

¿En que otros escenarios se mantendría? Podría mantenerse en puntos de venta de mercadería no relacionada con un supermercado, como de autopartes o componentes electrónicos.

alto importante curso.

Esta mal organizada la ruta de fundamentos de porgramacion. Alli esta el curso profesional de arquitectura de software, cuando en realidad tendrian que estar los fundamentos primero.

Holaaa! estoy arrancando este curso hoy. Alguien que este iniciando también hoy? consejos?

Para diagramar una arquitectura de software recomiendan el diagrama de componentes en UML ?

Arquitectura de software

  • Una arquitectura de software se selecciona y diseña con base en objetivos (requisitos) y restricciones
  • Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información.
  • Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información.
  • La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos.
  • Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.

Conceptos extraídos:

¿Qué es la arquitectura de software?

Son formas y guias generales, con las cuales se pueden resolver los problemas que surgen del desarrollo de un software.

Iniciando en este mundo del software

Iniciando con las mejores expectativas del curso

Con toda con este curso

here we go again:)

Esto se ve interesante, hasta tiene nombre como de maestro Jedi XD
a darle

Vamos por un curso más, a seguir aprendiendo!!!

Continuando con la ruta de Fundamentos de Programación

Totalmente ansioso por empezar este curso!

La arquitectura es super fundamental para planeación de proyectos !!

Un nuevo curso, excelente.

Empecemos con el curso ❤️

Diria que este curso es fundamental en toda carrera, no solo es dedicarse a escribir codigo sin objetivo alguno, descubri tarde el curso pero igual lo aprovechare

Por aquí viendo el curso de nuevo, es bastante complejo. Quizás necesite otros conocimientos previos para entender realmente el tema a profundidad.

Justo vengo del curso profesional de arquitectura de software porqué recomiendan tomar esté primero.

Excelente, muy animado por aprender en este curso

Tomar una mala decisión a nivel de arquitectura me trajo muchos problemas en mi actual empleo. Por eso vengo al curso, para evitar que me pase nuevamente

Arquitectura de software: son estructuras, modelos, y módulos que se comunican entre diferentes sistemas.

se ve bastante interesante el curso

** De que va la arquitectura de software?**

  • Estructuras.
  • Modelos con diagramas.
  • Se suelen hablar de la comunicación entre diferentes sistemas o incluso entre diferentes módulos del sistema.

¿Qué vamos a ver en el curso?

  • En este curso va atravesar todo el camino para atender que es el proceso de desarrollo y como la arquitectura está involucrada en cada uno de los pasos del proceso de desarrollo del software.
  • Entenderemos cuál es el rol del arquitecto y como el arquitecto puede ayudar al éxito o fracaso de un sistema.
  • Este curso va hacer evidente decisiones que a veces son implícitas y nos va ayudar a ser consiente de cuando estamos tomando una decisión arquitectónica en un sistema y cómo hacer para tomar la mejor decisión posible en ese momento.

Mmmmm, tengo la ligera sospecha que este curso será semejante al de Game Desing, jejeje. ¡Que genial!

¿Qué es la arquitectura de software?

  • La arquitectura de software es el diseño de más alto nivel de la estructura de un sistema.
  • Una arquitectura de software, también denominada arquitectura lógica, consiste en un conjunto de patrones y abstracciones coherentes que proporcionan un marco definido y claro para interactuar con el código fuente del software.
  • Una arquitectura de software se selecciona y diseña con base en objetivos (requisitos) y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como el mantenimiento, la auditoria, flexibilidad e interacción con otros sistemas de información. Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
  • La arquitectura de software define, de manera abstracta, los componentes que llevan a cabo alguna tarea de computación, sus interfaces y la comunicación entre ellos. Toda arquitectura debe ser implementable en una arquitectura física, que consiste simplemente en determinar qué computadora tendrá asignada cada tarea.
  • Entender el rol del arquitecto y cómo él puede ayudar al éxito o fracaso de un sistema.

  • nos va ayudar a tomar una decisión arquitectónica en un sistema y cómo hacer para tomar la mejor decisión posible.

Excelente, a comenzar…

Es excelente esta Introducción, todo se ve muy interesante. Gracias a Guido y todos los demás maestros de Platzi. 😄

En la arquitectura de software se habla de estructuras, modelos con diagramas, comunicación entre diferentes sistemas o incluso entre diferentes módulos del sistema.

Muy emocionado !!!

Para no solo saber programar, si no también diseñar.

Excelente introducción al curso

Definiendo el éxito o el fracaso de un proyecto de software.

Excelente vamos con toda

Aaaaaah! me siento muy emocionado! vamos por ello. Saludos, AF.

Buenas, me alegro poder estar aquí con vosotros, compartiendo conocimiento, aprendiendo!

¿Será que el proceso del arquitecto de software se inicia cuando un cliente plantea una necesidad y finaliza cuando tenemos todo listo para construirlo?

Arquitectura de software: se refiere a estructuras, modelos de diagramas y la comunicación entre diferentes sistemas y módulos

excelente curso

Se ve muy interesante el curso

suena interesante

¿ayuda alguien sabe por qué este curso no aparece en la ruta de aprendizaje de programación?

muy buena introducción

Existen dos tipos de problemas: Los problemas esenciales y los problemas accidentales.

Esenciales: Se dividen en 4 tipos de problemas
• Complejidad: cuando un dominio de un problema es complejo en sí mismo. En el caso de adiciones y todas las acciones que conlleven al sistema a ser más complejo.
Manejo del problema de complejidad: No desarrollar: Comprar - OSS
• Conformidad: en qué contexto se usa el software y cómo debe adecuarse al mismo. Se incluyen todo lo que le compete. Ej: Ambiente, conectividad, impuestos, etc.
Manejo del problema: Prototipado rápido, feedback y ciclos rápidos para soluciones pequeñas.
• Tolerancia al Cambio: Posibilidad del cambio en el mismo y que sea responsivo a diferentes contextos.
Manejo del problema: Desarrollo Evolutivo, desarrollos pequeños. Paso a paso pero de manera firme e ir haciendo crecer el software.
• Invisibilidad: Problemas de tangibilidad nula.
Manejo del problema: Grandes diseñadores, Arquitectos que saben abtraer el problema y que realiza soluciones elegantes, de manera simple, con la mejor calidad posible en los componentes que lo necesitan.

Accidentales: Está relacionado con la plataforma que vamos a implementar, tecnología, lenguajes, frameworks, integraciones, entre otros, que tienen 3 Entornos:
• Lenguajes de alto nivel
• Multi-procesamiento
• Entornos de programación
“Concidero a la especificación, diseño y comprobación del **concepto **la parte difícil de hacer software. (…) Si esto es cierto, hacer software siempre será difícil. No existe la bala de plata.” - Del libro **No Silver Bullet **(Frederick P. Brooks Jr., 1986)

Principios del Manifiesto Ágil

Nuestra mayor prioridad es satisfacer al cliente
mediante la entrega temprana y continua de software
con valor.

Aceptamos que los requisitos cambien, incluso en etapas
tardías del desarrollo. Los procesos Ágiles aprovechan
el cambio para proporcionar ventaja competitiva al
cliente.

Entregamos software funcional frecuentemente, entre dos
semanas y dos meses, con preferencia al periodo de
tiempo más corto posible.

Los responsables de negocio y los desarrolladores
trabajamos juntos de forma cotidiana durante todo
el proyecto.

Los proyectos se desarrollan en torno a individuos
motivados. Hay que darles el entorno y el apoyo que
necesitan, y confiarles la ejecución del trabajo.

El método más eficiente y efectivo de comunicar
información al equipo de desarrollo y entre sus
miembros es la conversación cara a cara.

El software funcionando es la medida principal de
progreso.

Los procesos Ágiles promueven el desarrollo
sostenible. Los promotores, desarrolladores y usuarios
debemos ser capaces de mantener un ritmo constante
de forma indefinida.

La atención continua a la excelencia técnica y al
buen diseño mejora la Agilidad.

La simplicidad, o el arte de maximizar la cantidad de
trabajo no realizado, es esencial.

Las mejores arquitecturas, requisitos y diseños
emergen de equipos auto-organizados.

A intervalos regulares el equipo reflexiona sobre
cómo ser más efectivo para a continuación ajustar y
perfeccionar su comportamiento en consecuencia.

Les dejo mi resumen.

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.
La unión de todos estos requerimientos (funcionales o no funcionales) van a llevar al arquitecto a tomar decisiones que impacten sobre el sistema.

Los Requerimientos
Una vez que entendemos el espacio del problema y el espacio de la solución, vamos a entrar a analizar los requerimientos de nuestro sistema.

Requerimientos de producto
Los podemos dividir en tres (03):

• Capa de requerimientos de negocio, son reglas del negocio que alimentan los requerimientos del negocio.
• Capa de usuario, tienen que ver en cómo el usuario se desenvuelve usando el sistema, qué atributos del sistema se deben poner por encima de otros.
• Capa Funcional, se ven alimentados por requerimientos del sistema, ¿qué cosas tienen que pasar operativamente?
Esta capa se ve afectada por las restricciones que pueden afectar operativamente a lo funcional.

Requerimientos Significativos para la Arquitectura del Producto:

• Requerimientos funcionales: (Funciones indispensables) Tienen que ver con las historias de usuarios, que hablan sobre específicamente lo que hace el sistema, por ejemplo que usuario ingrese al sistema.
• Requerimientos no funcionales: (Atributos de calidad): son aquellos que agregan cualidades al sistema, por ejemplo que el ingreso de ese usuario sea de manera segura.

Requerimientos de proyecto

• Tienen que ver más con el rol de gestor de proyectos, se usan para dar prioridad a los requerimientos del producto.
• Estos dos mundos de requerimientos hablan de las prioridades del equipo de trabajo del proyecto.
• Tiene que ver con requerimientos logísticos, que no tienen que ver con el desarrollo del software.

Los Riesgos

Es necesario identificar los riesgos para poder priorizarlos y atacarlos en orden y asegurar que las soluciones arquitectónicas que propongamos resuelvan los problemas más importantes.

Identificación de los riesgos:

• Toma de Requerimientos (Requerimientos funcionales):
Se calificará su riesgo de acuerdo a su dificultad o complejidad.
• Atributos de calidad (Requerimientos NO funcionales):
Se calificará su riesgo de acuerdo a la incertidumbre que genere, cuanto mas incertidumbre hay, mas alto es el riesgo.
• Conocimiento del dominio:
Riesgo prototípico, son aquellos que podemos atacar de forma estándar.

Pregunta de examen:
Los riesgos hay que identificados para poder priorizarlos, recuerda que no es necesario mitigarlos todos, debemos siempre tener en cuenta y dar prioridad a aquellos riesgos que ponen en peligro la solución que se está construyendo.

Las Restricciones

Las restricciones en el contexto de un proceso de desarrollo de software se refiere a las restricciones que limitan las opciones de diseño o implementaciones disponibles al desarrollar.

Los StakeHolders, nos pueden poner limitaciones relacionadas con su contexto de negocio, ejemplo:

• Las limitaciones legales, la implementación de un producto podría tener restricciones en algún país, y esto seria una limitante a considerar para el desarrollo del producto.
• Limitaciones técnicas, relacionadas con integraciones con otros sistemas.
• El ciclo de vida del producto, agregará limitaciones al producto, por ejemplo a medida que avanza el proceso de implementación el modelo de datos va a ser más difícil de modificar.

Nota:
El arquitecto debe balancear entre los requerimiento y las restricciones.

Sigamos con los fundamentos

A por el curso

genial

Feliz y ansioso por terminar el curso y aplicarlo.

A darle átomos!

Disfruto esta suscripción 👌

super

Listo para aprender.

Cool!!!

Vamos a aprender mas sobres este tema. A por todo.

Bien por poner un pdf!!!

Primer curso que tomo en Platzi con una suscripción. La meta, dedicarme a Computer vision y Big data. ¡Vamos con todo!

Venga! vamos a aprender.

Genial y me encanta que venga acompañado de un archivo pdf para documentar bien todo!

A seguir aprendiendo…

Vamos al curso 😃

Bien, a ver que tal el curso! 😄

No soy muy bueno para la arquitectura de software pero le echare ganas

Motivado para este nuevo curso

muy bien

Continuamos con la ruta de Fundamentos de Programación. He aprendido mucho. Vamos a continuar…

Se ve chido vamo a darle!

Excelente, un nuevo curso por aprender

Tienes el apellido de un personaje de Star Wars xd

Arquitectura de software: son estructuras, modelos, y módulos que se comunican entre diferentes sistemas.

Cuales se consideran las metodologías tradicionales ?

Ahora si me siento preparado para entender este curso y la arquitectura se software 🤣

mas bases! aqui vamos!

Repasando 😃 uno más

esta mal el playlist de “El proceso de desarrollo de sotfware”, como seria lo correcto?

empecemos…

A darle con todo a este curso para hacerme un programador super pro 😄

Empezando el curso. Veamos que nos trae

Súper listo para esto!

vamos con toda

¡¡ Excelente curso !!

Me quiero convertir a Arquitecto de Software… Aquí vamos! 🤓

se ve muy interesante vamo a darle