Testemunhei recentemente problemas cada vez mais semelhantes aos explicados neste artigo sobre interseções de recursos. Outro termo para isso seria linhas de produtos, embora eu tenha a tendência de atribuí-las a produtos realmente diferentes, enquanto geralmente encontro esses problemas na forma de possíveis configurações de produtos.
A idéia básica desse tipo de problema é simples: você adiciona um recurso a um produto, mas de alguma forma as coisas ficam complicadas devido a uma combinação de outros recursos existentes. Eventualmente, o controle de qualidade encontra um problema com uma rara combinação de recursos que ninguém pensava antes e o que deveria ter sido uma simples correção de bug pode até exigir mudanças importantes no design.
As dimensões desse problema de interseção de recursos são de uma complexidade alucinante. Digamos que a versão atual do software tenha N
recursos e você adicione um novo recurso. Vamos também simplificar as coisas dizendo que cada um dos recursos pode ser ativado ou desativado apenas, então você já tem 2^(N+1)
possíveis combinações de recursos a considerar. Devido à falta de melhores termos de redação / pesquisa, refiro-me à existência dessas combinações como problema de interseção de recursos . (Pontos de bônus por uma resposta, incluindo referência (s) para um termo mais estabelecido.)
Agora, a questão com a qual luto é como lidar com esse problema de complexidade em cada nível do processo de desenvolvimento. Por razões óbvias de custo, é impraticável até o ponto de ser utópico, querer abordar cada combinação individualmente. Afinal, tentamos ficar longe dos algoritmos de complexidade exponencial por um bom motivo, mas transformar o próprio processo de desenvolvimento em um monstro de tamanho exponencial está fadado a levar ao fracasso total.
Então, como você obtém o melhor resultado de maneira sistemática, que não explode nenhum orçamento e é completo de uma maneira decente, útil e profissionalmente aceitável.
Especificação: Quando você especifica um novo recurso - como garantir que ele funcione bem com todas as outras crianças?
Percebo que é possível examinar sistematicamente cada recurso existente em combinação com o novo recurso - mas isso estaria isolado dos outros recursos. Dada a natureza complexa de alguns recursos, essa visão isolada já está quase tão envolvida que precisa de uma abordagem estruturada por si só, sem falar no
2^(N-1)
fator causado pelos outros recursos que alguém ignorou de bom grado.Implementação: quando você implementa um recurso - como garantir que seu código interaja / intercepte adequadamente em todos os casos.
Mais uma vez, estou me perguntando sobre a pura complexidade. Conheço várias técnicas para reduzir o potencial de erro de dois recursos que se cruzam, mas nenhum que fosse dimensionado de maneira razoável. Suponho, porém, que uma boa estratégia durante a especificação deve manter o problema distante durante a implementação.
Verificação: ao testar um recurso - como você lida com o fato de que você só pode testar uma fração do espaço de interseção desse recurso?
Já é bastante difícil saber que testar um único recurso isoladamente não garante nada próximo ao código sem erros, mas quando você reduz isso a uma fração
2^-N
, parece que centenas de testes nem sequer cobrem uma única gota de água em todos os oceanos combinados. . Pior ainda, os erros mais problemáticos são aqueles que se originam da interseção de recursos, que não se espera que levem a problemas - mas como você os testa se não espera uma interseção tão forte?
Embora eu queira ouvir como outras pessoas lidam com esse problema, estou principalmente interessado na literatura ou nos artigos que analisam o tópico em maior profundidade. Portanto, se você seguir pessoalmente uma certa estratégia, seria bom incluir fontes correspondentes em sua resposta.