Estudo sobre complexidade arquitetural

Um excelente estudo realizado pela NASA endereça um dos assuntos mais críticos contidos em grandes sistemas computacionais, como apresentado, o sistema de controle aeroespacial: Como lidar com o crescimento da tamanho e da complexidade de um software ao longo do tempo e entre diferentes projetos realizados com base em um mesmo domínio? O estudo, apesar de ser baseado no domínio aeroespacial, pode ser aplicado a qualquer sistema que tenha as características por ele apresentado. É uma leitura rica e repleta de reflexões possíveis para a nossa realidade e enfatiza basicamente os seguintes aspectos:

1. A importancia no investimento em arquitetura de software
2. A necessidade de se enxugar ao máximo os requisitos diminuindo complexidade
3. Tratar o acréscimo de complexidade no software em todas as fases do projeto
4. Tratar sistematicamente desde os requisitos a disciplina de "proteção a falhas"

Estes aspectos acima citados, ganham grande enfoque e estão diluídos em 16 recomendações "macro" abaixo listadas:

• Difundir a consciência de complexidade entre as diversas camadas do sistema para todos os participantes de um projeto
• Documentar os motivadores e bases para os requisitos e seu objetivo-chave para o negócio, promovendo eliminação de requisitos desnecessários, diminuição de sua complexidade e amarração com o escopo.
• Difundir o conhecimento do negócio, com todos os seus aspectos multidiciplinares
• Introduzir a análise arquitetural o mais cedo possível no projeto
• Realizar revisões arquiteturais
• Dar maior suporte e investir em arquitetos de software
• Envolver os usuários finais desde o inicio e continuamente no processo
• Decisão "Make-or-Buy" (COTS) baseada na facilidade de separação desta do restante do sistema e da complexidade no processo de testes
• Investir numa arquitetura de referência
• Estimular a difusão tecnológica entre equipes e projetos
• Usar ferramentas de análise estáticas de código e "code compliance"
• Padronizar a terminologia usada para definir os diversos tipos de falhas de sistema, através da definição de um padrão léxico para proteção a falhas e definição de um conjunto de principios e funcionalidades que caracterizem arquiteturas de software a respeito de desta disciplina.
• Estabelecer a revisão dos requisitos ou proposta baseada nos aspectos de tratamento de falhas.
• Desenvolver a cultura de proteção a falhas e autonomia de sistemas
• Pesquisar técnicas de contenção de falhas
• Coletar e USAR métricas de software (Como medir complexidade das fases de software)?

Vale a pena o estudo do documento completo. Ele trás ainda boas referências e pequenos estudos práticos. Bons estudos!