Sempre existe uma discursão aqui na empresa entre análise e desenvolvimento do seguinte ponto de vista:
A análise sempre quer “prever” todas as possíveis falhas que um usuário pode disparar em suas operações no sistema.
Do meu ponto de vista, de desenvolvimento, acredito que, falhas “muito possíveis” de acontecer em uma interação usuário --> sistema devem de fato ser evitadas; porém, querer “evitar” todo tipo de falha, me parece um esforço desnecessário e tipo vidência, um software muito perfeito é imaginado, e um software que o usuário precisa nunca existe.
Pra mim, a melhor estratégia é a do estilo Google; usar betas - ou seja, lançar uma versão funcional e corrigir os erros que realmente acontecem.
Depende do custo de instalar uma nova versão do software no cliente. Se ele for muito alto (por exemplo, se é o programa da injeção eletrônica de um carro - imagine se o programa estiver errado, é necessário fazer um recall, o que sai muito caro para a montadora) então você tem de mandar o programa perfeito. Se for baixo ou desprezível então faça releases constantes. Um exemplo de um sistema onde o custo de atualizar é baixo é um sistema Web, onde o custo é só de instalar uma nova versão no servidor, e talvez de um retreinamento se houver muita mudança de funcionalidade.
Realmente não tinha pensado nisso. Mas em nosso caso aqui, o custo de distribuíção é baixo, e outra, cabe o uso de beta.
Realmente o exemplo que você citou, não tem como colocar uns 100 modelos para uso pra depois corrigir os problemas e colocar em produção; mas no nosso caso isso é possível na maioria das vezes.
Tem mais um fator que destaco (entre tantos), se uma falha pode causar prejuízos, por exemplo, se você tem uma aplicação de ecommerce, e uma falha permite o usuário comprar produtos e já aparecer marcados como “pago” sem ter pago efetivamente.