Quão comum é a prototipagem como o primeiro estágio do desenvolvimento?

Eu tenho feito alguns cursos de design de software nos últimos semestres e, embora eu veja o benefício em grande parte do formalismo, sinto que ele não me diz nada sobre o programa em si:

• Você não pode dizer como o programa funcionará a partir da especificação de Caso de Uso, mesmo que discuta o que o programa pode fazer.
• Você não pode contar nada sobre a experiência do usuário no documento de requisitos, mesmo que ele possa incluir requisitos de qualidade.
• Os diagramas de sequência são uma boa descrição de como o software funciona como a pilha de chamadas, mas são muito limitados e oferecem uma visão altamente parcial do sistema geral.
• Os diagramas de classe são ótimos para descrever como o sistema é construído, mas são totalmente inúteis para ajudá-lo a descobrir o que o software precisa ser.

Onde está todo esse formalismo: a aparência, o funcionamento e a experiência do programa? Não faz mais sentido projetar isso? Não é melhor descobrir como o programa deve funcionar por meio de um protótipo e se esforçar para implementá-lo de verdade?

Eu sei que provavelmente estou sofrendo com o ensino de engenharia por teóricos, mas preciso perguntar: eles fazem isso na indústria? Como as pessoas descobrem o que o programa realmente é, não o que ele deve estar em conformidade? As pessoas fazem muitos protótipos ou usam principalmente as ferramentas formais como a UML e eu ainda não aprendi a usá-las?

Se estamos construindo um aplicativo GUI, quase sempre criamos um protótipo ou POC (prova de conceito). Estabeleceremos qual será o vocabulário visual do aplicativo. Geralmente, envolvemos nosso cliente no meio do POC e garantimos que eles entendam qual é o objetivo e em que devem se concentrar. Nunca me arrependi de ter produzido um protótipo. Apenas certifique-se de não tentar transformar o código do protótipo no código de produção; inicie-o do zero com base no que aprendeu com o protótipo.

Dito tudo isso, quase nunca prototipamos aplicativos do lado do servidor (serviços, middleware etc.). Eu realmente não vejo o retorno do investimento para isso (a menos que você esteja desenvolvendo alguma tecnologia nova e precise provar conceitos diferentes).

No mundo dos negócios, isso importa muito

Eu também costumo pensar nisso, até você chegar ao mundo dos negócios. Então, não é mais simples o suficiente apenas para atender aos requisitos e prosseguir e construir.

Nos negócios, os diagramas de "fluxo" do usuário e os protótipos de lo-fi realmente fazem sentido.

Como o "programa" opera é provavelmente a parte mais fácil. Nos aplicativos LOB (Line Of Business), a maioria é apenas CRUD. O desafio está na lógica e nas regras de negócios . É aqui que os diagramas de fluxo do usuário e os fluxos de processos de negócios se tornam extremamente importantes para entender e planejar com eficiência.

O que você quer dizer com como o programa "opera"? Você parece estar procurando detalhes exatos da implementação em algo diferente da implementação final específica, o que não faz sentido. Elementos de nível superior devem orientar a implementação, não determiná-la.

Pela minha experiência, a prototipagem é um tanto incomum. Certamente fui ensinado em conjunto com especificações, requisitos, arquitetura etc., e isso pode ser muito útil.

Quanto a "o que o software precisa ser", esses são os requisitos. Você parece estar perdendo o ponto inteiro.

As interfaces geralmente são esboçadas de antemão, e os casos de uso podem ser usados ​​para o "fluxo" da interface. A experiência do usuário não está ausente. Se você sentir que algum elemento está faltando, faça outra coisa que seus professores não tenham mencionado. O design não consiste em um conjunto claro de regras transmitidas do céu.

Minha observação pessoal é de que a prototipagem recebe muitos elogios, mas muitas vezes o protótipo, uma vez que mostra sinais de vida, é simplesmente renomeado como 'Beta' ou, pior ainda, v1.0.

existem dois tipos de prototipagem - três, na verdade:

1. criamos protótipos para refinar o design e reduzir riscos antes de iniciar a codificação "real" (Engenharia)

2. construímos o projeto como uma série de protótipos refinados (Agile)

3. nós construímos um protótipo e o enviamos assim que funciona (Cowboy)

O que você está procurando é chamado de especificação - você pode ler uma descrição disso aqui em um dos artigos de Joel

http://www.joelonsoftware.com/articles/fog0000000035.html

Um protótipo também pode ser considerado "iteração 0" do que você precisa fazer. Cumpre várias coisas:

• Isso prova que o conceito pode ser feito. Isso pode ser com seu chefe ou com um cliente pagador.
• Permite identificar coisas que podem ser difíceis de obter para a força da produção e fornecer uma idéia geral da quantidade de trabalho necessária.
• Você realmente tem um código que faz alguma coisa . Isso é imensamente importante!

Em suma, o protótipo deve, com alta probabilidade, ser útil para criar o produto final, a menos que você tenha achado que é necessária uma abordagem completamente diferente.