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

10

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?

EpsilonVector
fonte
2
Pela minha leitura, você parece focado demais na parte da interface do usuário do desenvolvimento de software. Os protótipos são excelentes para desenvolver e refinar interfaces de usuário, não tanto para elaborar a lógica principal (ou mesmo para descobrir exatamente qual é a lógica de negócios que você deve implementar)
Anon.
11
Se houver um usuário humano, geralmente haverá GUI. O aspecto da GUI e o desempenho da mesma afetará o design de todo o sistema.
Job

Respostas:

6

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).

Walter
fonte
+1 Protótipo da minha empresa com bastante frequência, mas apenas como prova de conceito, principalmente em GUIs, mas também ao pesquisar uma nova abordagem para um problema, também do lado do servidor.
Orbling
6

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.

Noite escura
fonte
1

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.

Matthew Read
fonte
0

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.

leed25d
fonte
+1 É verdade que o protótipo é visto pelo marketing, que costuma anunciar a conclusão do projeto.
Orbling
11
Este é um argumento para tornar os seus protótipos o melhor possível, dado o tempo, não para recusar-se a fazer protótipos.
Inaimathi
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)

Steven A. Lowe
fonte
0

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.


fonte