Quando continuo desenvolvendo um software, design de interface do usuário ou design de banco de dados, que deve ser o primeiro?

Question

Tentei projetar a interface do usuário com algum software de zombaria da interface do usuário, mas achei difícil para mim resolver todos os detalhes do design, já que o banco de dados ainda não projetava.

Mas se eu projetar o software primeiro, então o mesmo problema ocorreu, não tive a interface do usuário, como posso criar uma interface do usuário proeminente?

Answer 1

UI primeiro.

Mock Up Up uma interface de usuário elegante e fácil de usar (e fluxo de trabalho) pensando do ponto de vista do usuário e só então pense nas estruturas de banco de dados / dados subjacentes que você precisará dar vida a essa interface do usuário.

Se você não pode projetar sua interface do usuário porque ainda não projetou seu banco de dados, está fazendo errado IMHO. Quantas peças irritantes de software você usou que sofreu de deixar o design do banco de dados acionar o design da interface do usuário?

Editar: Como outros apontaram, você precisa começar com casos de uso / histórias de usuário. O design da interface do usuário e o design do banco de dados, o que você faz, só deve acontecer depois Você sabe o que seu software está tentando fazer e para quem.

Editar Por Bryan Oakley:

_{(fonte: gapingvoid.com)}

Answer 2

Coloque o usuário no local que ele merece. Projete a interface do usuário primeiro.

O banco de dados é apenas uma conseqüência das necessidades do usuário.

Answer 3

Se você está tentando resolver um problema em um idioma orientado a objetos, é recomendável começar a pensar nos objetos envolvidos. Não se preocupe com o banco de dados ou a interface do usuário até que você tenha um modelo de domínio sólido pregado que aborda todos os casos de uso.

Você não se preocupa com o banco de dados ou a interface do usuário no começo. Você pode serializar objetos para o sistema de arquivos se precisar de persistência e não tiver um banco de dados. Ser capaz de dirigir seu aplicativo com uma linha de comando UI é um bom exercício para garantir que você tenha uma boa separação do MVC.

Comece com os objetos.

ATUALIZAR:

A única vantagem que essa abordagem tem é que ela não prejudica a interface do usuário com um design de banco de dados específico ou vice -versa. O objeto é agnóstico sobre as outras duas camadas. Você não precisa ter uma interface do usuário ou banco de dados relacional. Você está apenas acertando os objetos. Depois de ter isso, você pode criar qualquer esquema de interface do usuário ou persistência que desejar, confiante de que o modelo de domínio pode lidar com o problema que você foi solicitado para resolver.

Answer 4

Use casos primeiro, nem interface do usuário nem banco de dados.

Answer 5

Sua pergunta é muito subjetiva.

Minha opinião (e é apenas isso) é que o banco de dados e a estrutura subjacente devem vir primeiro. Muitas vezes, pode ajudar a colocar o teclado e o mouse e compilar algumas notas no papel.

Deixe objetivos como o que você deseja que seu aplicativo faça, liste os recursos necessários e comece a pensar em como você o criará.

Este método funciona para mim no design do aplicativo.

Answer 6

Geralmente você precisa manipular alguns dados nas soluções que desenvolve. Portanto, você deve considerar como esses dados são organizados primeiro, estabilizar essa camada é fundamental no início. Concordo com o comentário de Duffymo sobre o design dos objetos de negócios primeiro, se você estiver em um mundo OO. Mapear esses objetos para o banco de dados fará parte do seu trabalho. Em seguida, você adiciona funcionalidade comercial e trabalha na camada de apresentação. É claro que você terá que refatorar de tempos em tempos, mas geralmente a refatoração afeta as camadas de negócios e apresentação mais do que o banco de dados.

Leia isso, é uma boa técnica.DDD - design do driver de domínio

Answer 7

Você construiria uma casa sem fundamento? O design do banco de dados não é a parte divertida, mas é a base da maioria dos aplicativos de negócios e, se você errar, se torna o mais caro corrigido e o mais onero de manter.

Dito isto, observo que não há razão para que você não possa trabalhar juntos enquanto eles se entrelaçam. Mas antes que você possa fazer, você precisa entender os requisitos e os negócios para os quais está escrevendo o aplicativo.

Answer 8

Todas as respostas acima abordam seu problema na direção certa. Dito isto, eu seguiria o SDLC completamente. Ajuda você a entender a necessidade da solução para o problema em questão. Em seguida, vem a coleta de requisitos, seguida pelo design da interface do usuário / estrutura subjacente que suporta a interface do usuário. É um procedimento, mas você se beneficiaria no final.