Introducción al curso

1

Diseño y Documentación de Arquitectura de Software

Atributos de calidad

2

Atributos de Calidad en Sistemas: Definición y Medición

3

Idoneidad Funcional: Completitud, Exactitud y Pertinencia

4

Eficiencia de Ejecución en Sistemas Informáticos

5

Compatibilidad en Sistemas: Interoperabilidad y Coexistencia

6

Subcaracterísticas de Usabilidad en Desarrollo de Software

7

Confiabilidad de Sistemas: Madurez, Disponibilidad, Resiliencia y Recuperación

8

Seguridad de Usuarios en Desarrollo de Software

9

Subcaracterísticas de Mantenibilidad en Sistemas de Software

10

Medición de Adaptabilidad en Sistemas de Software

11

Relación y Tensión entre Atributos de Calidad en Sistemas de Software

12

Atributos de Calidad en Arquitectura de Software

Patrones de arquitectura

13

Patrones de Arquitectura Monolítica y Distribuida

14

Modelo Vista Controlador: Separación de Responsabilidades en Aplicaciones

15

Arquitectura de Capas: Diseño y Comunicación entre Niveles

16

Patrones de Arquitectura Orientada a Eventos y Event Sourcing

17

Patrón de Arquitectura MicroKernel y su Implementación en IDEs

18

Arquitectura "Comparte Nada": Optimización y Procesamiento de Datos

19

Patrón de Microservicios en Arquitectura de Software

20

Patrón CQRS para Separación de Consultas y Comandos

21

Arquitectura Hexagonal: Diseño y Aplicación Práctica

22

Diseño Orientado al Dominio: Conceptos y Aplicaciones Prácticas

23

Patrones de Arquitectura para Aplicaciones Escalables y Modulares

24

Patrones de Arquitectura en Proyectos de Crecimiento Empresarial

Diseño de una arquitectura

25

Diseño de Arquitecturas a Medida: Herramientas y Estrategias

26

Tipos de Conectores en Arquitectura de Software

27

Conectores Asíncronos y Sincrónicos: Implementación y Uso Práctico

28

Diferencias entre Enrutadores y Difusores en Comunicación de Mensajes

29

Conexión de Productores y Consumidores con Colas de Mensajes

30

Framework de Diseño Orientado a Atributos: Escenarios y Tácticas

31

Tácticas para Mejorar la Disponibilidad de Sistemas

32

Tácticas para Mejorar la Disponibilidad del Sistema

33

Tácticas para Mejorar la Mantenibilidad del Software

34

Prevención de Efectos Dominó en Mantenibilidad de Software

35

Estrategias para Mejorar la Eficiencia de Ejecución en Sistemas

36

Tácticas de Seguridad Informática para Detectar, Resistir y Recuperarse de Ataques

37

Estrategias para Mejorar la Capacidad de Prueba de Software

38

Tácticas de Usabilidad en Diseño de Interfaces de Usuario

39

Validación de Arquitectura con ATAM y Métricas de Calidad

40

Diseño de Arquitectura para Startups y Empresas Escalables

Modelado y documentación de arquitectura

41

Documentación Efectiva de Arquitectura de Software

42

Sincronización de Modelos de Arquitectura y Código Fuente

43

Evaluación de Atributos de Calidad en Arquitectura de Software

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Tácticas para Mejorar la Mantenibilidad del Software

33/43
Recursos

¿Cómo se logra la mantenibilidad en el desarrollo de software?

La mantenibilidad en sistemas de software es crucial para asegurar su adaptabilidad a nuevos requerimientos, su eficiencia en el mantenimiento, y la facilidad para implementar cambios. Este concepto implica la capacidad de alterar el sistema sin afectar otras partes cruciales y se estructura en torno a tácticas específicas. Exploremos estas estrategias de manera detallada.

¿Cuál es la importancia de confinar modificaciones?

Al hablar de confinar modificaciones, nos referimos a limitar los cambios a un solo módulo del sistema. Esta táctica busca mantener dependencias ligeras entre módulos, de manera que un requerimiento de cambio no afecte extensas partes del sistema. Mantener la coherencia semántica entre módulos es esencial; si un módulo es cohesivo, sus componentes están estrechamente interrelacionados, facilitando su mantenimiento.

¿Cómo se puede asegurar la coherencia semántica?

La coherencia semántica en los módulos implica que las responsabilidades que estos contienen están alineadas, lo que genera cohesión y minimiza el acoplamiento. Un módulo cohesivo cambia por una sola razón, mejorando así su mantenibilidad. Esta táctica se puede profundizar mediante:

  • Abstraer servicios comunes: Identificar y extraer servicios que son genéricos, como logging o autenticación, para que puedan ser usados por múltiples módulos sin dependencia directa.

  • Generalizar: Separar las especificaciones de lo genérico y crear interfaces o clases abstractas que definen comportamientos comunes y estables, mientras que las implementaciones específicas pueden variar sin alterar estas bases.

¿Por qué es útil limitar las opciones disponibles?

Limitar las opciones disponibles ante un cambio es útil para mantener la estabilidad del sistema, incluso cuando se presentan requerimientos que modifican comportamientos drásticamente. Esta táctica se beneficia de la anticipación a las necesidades futuras, donde se identifica la posibilidad de cambios y se prepara al sistema para adaptarse eficazmente.

¿Cómo prevenir efectos dominó en el software?

Prevenir efectos dominó significa gestionar y mitigar cómo los cambios pueden inducir errores o requerir modificaciones en otros módulos del sistema. Para lograrlo, se debe trabajar activamente en el manejo de las dependencias entre componentes desde el diseño inicial.

¿En qué consiste diferir enlace?

Diferir el enlace se relaciona con la capacidad de cambiar el código sin necesidad de redeployar toda la aplicación, algo más sencillo en lenguajes interpretados que en aquellos compilados. Esta práctica busca flexibilidad y eficiencia en la actualización de parte del sistema.

A través de estas estrategias de mantenibilidad, los desarrolladores de software pueden gestionar con éxito los cambios de requerimientos, mejorar la estabilidad y asegurar un sistema robusto y flexible para las necesidades futuras. La anticipación, el diseño cuidadoso y la correcta gestión de dependencias son claves para un sistema de software sostenible. ¡Continúa explorando y aplicando estas tácticas para convertirte en un experto en mantenibilidad!

Aportes 14

Preguntas 0

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Mantenibilidad
En este caso el estimulo es un pedido de cambio (llega un requerimiento y tenemos que cambiar el sistema).

Familias de tácticas:
1.- Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.

Abstraer servicios comunes. Cuando encontramos que la aplicación tiene servicios más genéricos de no necesario podemos abstraerlos a un punto común y que las dependencias vayan de los módulos cohesivos a un servicio o modulo externo.

b) Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico.
c) Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
d) Anticipar cambios. Prepararnos para algún cambio que nosotros mismo sepamos que se deberá de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de diseño suelen estar orientados a esto (Patrón estrategia).

2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generaría problemas en otros módulos o dependencias.

3.- Diferir enlace. Como podemos hacer para que un cambio en el código no requiera desplegar toda la aplicación.

Demasiada teoría hasta el momento a mi punto de vista, hubiera estado bien tener más ejemplos reales o en una pizarra para explicar de forma más dinámica.

Escenario: Mantenibilidad

Estimulo: Pedido de cambio / Nuevo requerimiento
Tácticas para que la respuesta sea que se pudo hacer el cambio, probarlo y desplegarlo
Familias de tácticas

  • Confinar modificaciones
    • Coherencia semántica
      ** Abstraer servicios comunes
    • Generalizar
    • Limitar las opciones disponibles
    • Anticipar los cambios
  • Prevenir efectos domino
  • Diferir enlace

Para extender un poco el tema de Acomplamiento / Cohesión:

Apuntes:

Mantenibilidad

Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
• Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.
o Abstraer servicios comunes.
• Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico. • Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
• Anticipar cambios.

Ponerle Profesional al curso, y no considerar un estudio exhaustivo fue un error, como se puede observar para mi, cada clase explicada, requiere quizás hasta una hora entera viendo ejemplos y probando punto a punto lo explicado.

Demasiada teoría, solo estoy tomando notas porque se que lo puedo necesitar, la información tiene valor, lo puedo ver pero creo que podrían haber recomendado leer un pdf y tendría el mismo resultado que ver los videos

Escenarios: Mantenibilidad

El estimulo es un pedido de cambio. dentro de la mantenibilidad hay tres familias de tácticas:

  • Confinar Modificaciones: Van a trabajar sobre nuestros módulos para que cada cambio solo se limite a un modulo. esto hace que las dependencias entre módulos sean más ligeras.
    Tácticas:
  1. Coherencia Semántica.
    1.1 Abstraer servicios comunes
  2. Limitar Opciones
  3. Anticipar Cambios
  • Prevenir efecto domino: Trabaja estrictamente con las dependencias, se trata de conocer cuando puede detectar cuando algún cambio generaría problemas en uno o varios módulos o dependencias.
  • Diferir enlace: Se trata de como hacer que algún cambio en el código no requiera de desplegar toda la aplicación entera.

De verdad que clase a clase entiendo un poquito mas por que mi tech leader o el CTO de donde trabajo toman las decisiones que toman, entiendo la teoría destrás de esas decisiones, y ahora puedo yo empezar a tomar mejores decisiones para mis contribuciones al proyecto. Muy potente!!!

Este curso esta tremendo, super completo, pero no es para personas que no tengan experiencia trabajando en la industria.

Todos los conceptos se aplican directamente a situaciones a resolver día a día en el trabajo del programador. Incluso a mi siendo junior me estan sirviendo los conceptos para plantear mejor mis propuestas e ideas con mis colegas.

Así que si sienten que no pueden bajar la teoría a la práctica les recomiendo que retomen el curso cuando ya tengan esa experiencia porque si no es dificil que puedan pensar en situaciones donde se aplica todo lo que dice el profe.

Familias de tácticas:
1.- Confinar modificaciones. Las tácticas van a intentar trabajar sobre nuestros módulos para que cada cambio que nos pidan esté confinado a sólo un módulo. Cuando logramos esto logramos que las dependencias entre módulos sean más ligeras y el cambio que nos proponen no afecte a muchas partes del sistema.
a) Coherencia semántica. Habla de la relación entre las responsabilidades de los módulos. Hablamos de acoplamiento y cohesión. Si logramos encontrar la cohesión en un módulo entonces vamos a poder hacer que ese módulo sea más mantenible. De lo contrario es posible que ese módulo cambie por diferentes razones.
Abstraer servicios comunes. Cuando encontramos que la aplicación tiene servicios más genéricos de no necesario podemos abstraerlos a un punto común y que las dependencias vayan de los módulos cohesivos a un servicio o modulo externo.
b) Generalizar. Al generalizar un módulo podemos separar lo específico de lo genérico.
c) Limitar opciones disponibles. Limitar el rango de modificación nos ayuda a que sea más mantenible.
d) Anticipar cambios. Prepararnos para algún cambio que nosotros mismo sepamos que se deberá de dar en el futuro tomando en cuenta una estrategia sobre como incorporar el nuevo cambio. Los patrones de diseño suelen estar orientados a esto (Patrón estrategia).
2.- Prevenir efectos domino. Trabaja estrictamente con las dependencias, es decir cuando podemos detectar que un cambio generaría problemas en otros módulos o dependencias.
3.- Diferir enlace. Como podemos hacer para que un cambio en el código no requiera desplegar toda la aplicación.

Anticipar cambios en mi experienca es una de las peores cosas que se pueden hacer. Si algo no se necesita implementar ahora mismo en el sistema, incluso aunque 'probablemente' se use en el futuro, no se debe agregar. Muchas veces se cambia de prioridad en la empresa y un feature que parecia probable, se vuelve solo codigo que estorba y nunca se uso. Y lo peor de todo, si en algun momento se vuelve a retomar ese feature, se hace desde cero, ya que nadie se acordo que ya habia un avance de eso
<h3>Mantenibilidad</h3>
  • Confinar modificaciones: Aunque no necesariamente existe una relación precisa entre el número de módulos afectados por un conjunto de cambios y el costo de implementar esos cambios, restringir las modificaciones a un pequeño conjunto de módulos generalmente reducirá el costo. El objetivo de las tácticas en este conjunto es asignar responsabilidades a los módulos durante el diseño de modo que los cambios anticipados tengan un alcance limitado.
  • Prevenir efectos dominó: Un efecto dominó de una modificación es la necesidad de realizar cambios en los módulos que no se ven directamente afectados por él. Por ejemplo, si el módulo A se cambia para lograr una modificación particular, entonces el módulo B se cambia solo debido al cambio al módulo A. B tiene que modificarse porque depende, en cierto sentido, de A.
  • Diferir enlace: Las dos categorías tácticas que hemos discutido hasta ahora están diseñadas para minimizar la cantidad de módulos que requieren cambios para implementar modificaciones. Nuestros escenarios de modificabilidad incluyen dos elementos que no se satisfacen al reducir la cantidad de módulos que se van a cambiar: el tiempo de implementación y permitir que los no desarrolladores realicen cambios. Aplazar el tiempo de enlace es compatible con ambos escenarios a costa de requerir infraestructura adicional para soportar el enlace tardío.

🤖
Escenario Mantenibilidad
En este caso el estimulo es un pedido de cambio (llega un requerimiento y tenemos que cambiar el sistema).