EVOLUÇÃO E MANUTENÇÃO DA ARQUITETURA DE PROJETOS NA VIDA REAL: LIÇÕES APRENDIDAS JÉSSICA FÉLIX (JESSILYNEH)

Dificuldades de manter software evoluindo de forma rápida e saudável @jessilyneh Sobrecarga do time responsável pela manutenção e evolução, principalmente se o processo de governança for manual, em maioria Débitos técnicos acumulados por anos Arquitetura que cresceu de forma reativa, sem um minimo planejamento Sistemas muito complexos, custos, etc etc...

Evolução de Software Baseada em Avaliação de Arquitetura - Danielle Pompeu Noronha Pontes - 2012 @jessilyneh

Em vez de evoluir a arquitetura de software a cada nova mudança que ocorre, a arquitetura original deve ser capaz de permitir os tipos mais comuns de evolução. @jessilyneh

Erosão Arquitetural @jessilyneh quando a arquitetura de um sistema de software se degrada ao longo do tempo devido a decisões e implementações realizadas pelos desenvolvedores, que acabam violando os princípios e diretrizes arquiteturais originais, conceito elaborado por Perry e Wolf em 1992.

Manutenção @jessilyneh Requer a mudança do design do sistema: correção de erros, adaptação para novos ambientes e adição de novas caracteristicas (PARNAS, 1994)

Evolução @jessilyneh Subtende a ideia de mudança essencial que não está transparente no termo de manuteção. Sugere novos designs evoluindo de sistemas antigos. (GODFREY;GERMAN,2008)

Evolução e Manutenção são conceitos diferentes @jessilyneh

Arquitetura de Software: Descreve a estrutura e os componentes de um sistema de software, incluindo as interações entre eles. Evolução de Software: O processo de mudanças e melhorias em um sistema de software para atender às novas exigências de mercado. @jessilyneh

Método de Análise de Tradeoff de Arquitetura (ATAM) é um método utilizado para avaliar os atributos de qualidade de arquiteturas de software, como desempenho, disponibilidade e segurança. O ATAM é aplicado nos estágios iniciais do ciclo de vida de desenvolvimento de software (SDLC) para mitigar riscos em arquiteturas de software @jessilyneh

Fase 1: Apresentação da arquitetura. Fase 2: Investigação e análise. Fase 3: Teste. Fase 4: Entrega. @jessilyneh Método de Análise de Tradeoff de Arquitetura (ATAM)

8 Leis de Lehman @jessilyneh Lei da Mudança Contínua (Continuing Change): Sistemas do tipo E devem ser continuamente adaptados, caso contrário, eles se tornarão progressivamente menos satisfatórios em uso.

8 Leis de Lehman @jessilyneh Lei do Aumento da Complexidade (Increasing Complexity): À medida que um sistema do tipo E evolui, sua complexidade aumenta, a menos que seja feito um trabalho para mantê-la ou reduzi-la.

8 Leis de Lehman @jessilyneh Lei da Auto-Regulação (Self Regulation): Os processos de evolução de sistemas globais do tipo E são autorregulados.

8 Leis de Lehman @jessilyneh Lei da Conservação da Estabilidade Organizacional (Conservation of Organisational Stability): A menos que os mecanismos de feedback sejam ajustados adequadamente, a taxa de atividade global efetiva média em um sistema do tipo E em evolução tende a permanecer constante ao longo da vida útil do produto.

8 Leis de Lehman @jessilyneh Lei da Conservação da Familiaridade (Conservation of Familiarity): Em geral, o crescimento incremental e a taxa de crescimento a longo prazo de sistemas do tipo E tendem a diminuir.

8 Leis de Lehman @jessilyneh Lei do Crescimento Contínuo (Continuing Growth): A capacidade funcional de sistemas do tipo E deve ser continuamente aumentada para manter a satisfação do usuário ao longo da vida útil do sistema.

8 Leis de Lehman @jessilyneh Lei do Declínio da Qualidade (Declining Quality): A menos que sejam rigorosamente adaptados para levar em conta as mudanças no ambiente operacional, a qualidade de sistemas do tipo E parecerá estar diminuindo.

8 Leis de Lehman @jessilyneh Lei do Sistema de Feedback (Feedback System): Os processos de evolução de sistemas do tipo E são sistemas de feedback multiníveis, multilaços e multiagentes.

Evolução de Software Baseada em Avaliação de Arquitetura - Danielle Pompeu Noronha Pontes - 2012 @jessilyneh

Evolução de Software Baseada em Avaliação de Arquitetura @jessilyneh Aplicação do Roteiro O artigo apresenta um exemplo de aplicação do roteiro de avaliação de arquitetura em um sistema para automação de linhas aéreas. O exemplo detalha os passos do ATAM e como eles foram aplicados ao sistema. .

Evolução de Software Baseada em Avaliação de Arquitetura @jessilyneh Conclusões Avaliação de arquiteturas é essencial para a evolução de software. A utilização do ATAM como um roteiro para a evolução arquitetural pode ajudar a garantir que os sistemas de software sejam capazes de atender às novas exigências de mercado e manter a satisfação dos usuários ao longo do tempo.

Building Evolutionary Architectures @jessilyneh

Evolução, Adaptação e Mudanças inevitáveis @jessilyneh - adaptar a arquitetura de software às mudanças constantes nas demandas dos usuários e no ecossistema de desenvolvimento de software. - arquitetura deve ser maleável e capaz de se adaptar ao longo do tempo - fazer mudanças incrementais e controladas para evitar a degradação da arquitetura. - considerar múltiplas dimensões arquiteturais ao planejar a evolução da arquitetura.

Fitness Function para governança de evolução da arquitetura @jessilyneh Um mecanismo que define e valida propriedades-chave da arquitetura, permitindo que ela evolua de forma controlada. - Escopo Holistico ou Atomico - Diferentes cadências - Resultados Estáticos ou Dinâmicos, automatizadas ou manuais -Proativas, Emergentes - Genéricas ou específicas

Fitness Function para governança de evolução da arquitetura @jessilyneh Ford, N., Parsons, R., Kua, P., & Sadalage, P. (2023). Building Evolutionary Architectures (2nd ed.). O'Reilly Media. Monitoramento DevOps Métricas de código Engenharia de caos Estruturas de teste de arquitetura Varredura de segurança

fitness function-driven architecture @jessilyneh As fitness functions são usadas não apenas para validar propriedades da arquitetura, mas para ativamente moldar e guiar as decisões de design arquitetural.

Caso de estudo @jessilyneh o arquiteto projetou o sistema para que o serviço orquestrador contenha o estado do fluxo de trabalho. Se algum dos serviços se comunicar entre si, ignorando o orquestrador, a equipe não terá informações precisas sobre o estado do fluxo de trabalho. No caso de ciclos de dependência, existem ferramentas de métricas para permitir que os arquitetos façam verificações em tempo de compilação. No entanto, os serviços não estão restritos a uma única plataforma ou stack de tecnologia, tornando altamente improvável que alguém já tenha construído uma ferramenta que corresponda exatamente a uma arquitetura específica.

Estudo de caso @jessilyneh

Referencias: @jessilyneh https://www.cin.ufpe.br/~in953/lectures/papers/LEHMANRulesAndToolsForSoft wareEvolutionPlanningAndManagement.pdf https://www.teses.usp.br/teses/disponiveis/3/3141/tde-14092012- 122012/publico/DISSERTACAO_DANIELLEPNPONTES.pdf Ford, N., Parsons, R., Kua, P., & Sadalage, P. (2023). Building Evolutionary Architectures (2nd ed.). O'Reilly Media.