Construa um para jogar fora contra o efeito do segundo sistema

Por um lado, há um conselho que diz "Construa um para jogar fora". Somente depois de terminar um sistema de software e ver o produto final, percebemos o que deu errado na fase de design e entendemos como deveríamos ter realmente feito.

Por outro lado, existe o "efeito do segundo sistema", que diz que o segundo sistema do mesmo tipo projetado é geralmente pior que o primeiro; existem muitos recursos que não se encaixavam no primeiro projeto e foram empurrados para a segunda versão, geralmente levando a excessivamente complexos e excessivamente projetados.

Não há aqui alguma contradição entre esses princípios? Qual é a visão correta sobre os problemas e onde está a fronteira entre esses dois?

Acredito que essas "boas práticas" foram promovidas em primeiro lugar no livro seminal The Mythical Man-Month, de Fred Brooks.

Sei que algumas dessas questões são resolvidas pelas metodologias ágeis, mas, no fundo, o problema ainda é o de princípios; por exemplo, não faríamos alterações importantes no projeto três sprints antes de entrar no ar.

Construir um para jogar fora vem de "não saber o que você não sabe" no início, para aprender o que deveria ter feito no início.

O segundo efeito do sistema vem de "agora saber o que você não sabia, mas não saber o que você ainda não sabe", ou seja, o segundo efeito do sistema vem da tentativa de construir um sistema maior, mais brilhante e mais complexo do que o primeiro, sem o conhecimento necessário no início - parece muito com o que acontece com o primeiro sistema.

Portanto, o segundo efeito do sistema não é contraditório. A criação de um segundo sistema com a mesma funcionalidade que o primeiro nunca foi feita (que eu saiba). O segundo sistema sempre tem que ser "melhor", portanto mais complexo e, portanto, problemas substancialmente semelhantes ao primeiro sistema são esperados - que devem ser descartados.

Portanto, crie um para jogar fora, jogue-o de volta e construa-o novamente sem ampliação do escopo, e você não terá um segundo problema no sistema. (Isso costuma ser feito com mais frequência em planetas com céu roxo, mares-de-rosa e porcos voadores.)

O problema ao qual você está se referindo significa que várias coisas foram ignoradas; portanto, o sistema resultante deu errado. Deixe-me descrever algumas das etapas ausentes:

Gestão da Qualidade - Faça certo da primeira vez! Nunca use hacks temporários ou compromissos temporários. Não haverá retrabalho necessário. Todos os recursos são usados ​​com eficiência e tudo o que você faz é uma contribuição adequada para o projeto.

Análise de viabilidade - Descubra as necessidades de negócios. Crie um caso de negócios para o projeto.

Plano do projeto - defina claramente seu escopo inicial, planeje como a solução será entregue, crie uma linha de base e atenha-se ao plano. Não gaste tempo com nada que não esteja no caminho crítico.

Engenharia de requisitos - Elicite requisitos de negócios (por exemplo, capture processos de negócios e determine quais operações de negócios devem ser suportadas pelo sistema computadorizado, traduza operações de negócios 1: 1 para casos de uso do sistema). Valide e verifique! (estamos construindo a coisa certa? Estamos construindo a coisa certa?) Todos os requisitos devem estar vinculados à necessidade comercial original.

Design de software - traduza casos de uso e modelo de domínio em design de componentes e arquitetura de soluções. Todos os componentes devem estar vinculados aos requisitos do ER.

Implementação - Codifique o software como no design. Todo o código deve estar vinculado aos componentes do SD.

Validação - Teste de unidade, teste de integração, desempenho, ... (todos os casos de uso do ER agora precisam ser testados)

Esses são alguns aspectos principais de um processo de software. As atividades mencionadas fazem parte da Engenharia de Software. É assim que você cria a solução de software certa para as necessidades reais dos negócios e a desenvolve dentro do prazo, do orçamento e da especificação.

Consulte estes termos para criar um software melhor e corrigi-lo da primeira vez:

• Análise de viabilidade (especialmente como construir um Business Case)
• Gerenciamento de projetos (esp. Plano do projeto e registro de riscos com mitigação de riscos)
• Engenharia de Requisitos (elicitação, análise, especificação, validação)
• Design de software (UML e engenharia de software baseada em componentes)
• Construção de software (padrões de design, estruturas, programação defensiva)
• Validação de software (teste de unidade, UAT, etc.)