O que planejar antes de iniciar o desenvolvimento de um projeto? [fechadas]

Digamos que recebi as especificações de um projeto de um cliente e agora é hora de começar a desenvolvê-lo. Normalmente, eu apenas começo com o primeiro módulo (geralmente registro de usuário) e depois passo de um módulo para o outro. Eu só planejo na minha cabeça antes de começar um módulo como vai funcionar, mas não há planejamento antes disso.

No entanto, acho que seria melhor se eu examinasse as especificações e planejasse como o sistema funcionaria antes de codificá-lo, por exemplo, quais são os principais componentes, como eles vão interagir etc. Estou apenas não sei exatamente o que devo planejar.

Para ter uma idéia melhor do que estou pedindo, como devo-

a) Divida o projeto em componentes,

b) Planeje suas interações, por exemplo, devo fazer diagramas de classe, escrever testes de unidade etc.?

Alguma ideia?

Quando você tem o privilégio de iniciar um novo projeto, tem uma tela em branco - que é emocionante e assustadora ao mesmo tempo. Eu trabalho em iterações, e é assim que eu divido o trabalho:

• Comece com os objetivos do projeto. As metas são necessariamente as mais vagas, mas ajudam você a se concentrar no que o cliente ou usuário pretende fazer com o software. No final do dia, você deseja atingir esses objetivos - mesmo que isso signifique abandonar alguns recursos realmente interessantes.
• Então eu começo a dividir o aplicativo em seus subdomínios. Provavelmente, existem centenas de maneiras diferentes de fazer isso, e é por isso que começamos com os objetivos do projeto. Queremos dividir o aplicativo em alguns subsistemas relacionados que suportam esses objetivos. Isso nos ajuda a focar na próxima tarefa.
• Identifique como e quando os subsistemas precisam interagir. Não estamos lidando com os detalhes, apenas as informações de alto nível para garantir que tenhamos um sistema integrado de subsistemas. Você precisa de uma idéia geral disso para poder detalhar os detalhes que sustentam os objetivos gerais do projeto.
• Forneça apenas detalhes do subsistema em que estou trabalhando no momento (semelhante à sua estratégia atual). Eu já sei como esse subsistema precisa interagir com outros subsistemas, mas posso precisar de algumas alternativas para que faça mais sentido. Cada subsistema é separado por uma interface, para que eu possa ajustar a implementação o máximo possível sem interromper o sistema como um todo.
• Reveja como as coisas são implementadas no meu subsistema atual em comparação com como são implementadas em outros subsistemas. Toda abordagem que não é consistente é algo que o usuário precisa aprender. Tudo bem se estamos falando de um novo conceito. Por uma questão de usabilidade, não queremos cinco maneiras diferentes de excluir informações presentes simplesmente porque éramos preguiçosos. Reutilizar os mesmos elementos da interface do usuário é a maneira mais rápida de tornar o aplicativo mais intuitivo. Aprender três conceitos é muito mais fácil do que aprender 20.

Essencialmente, essa abordagem de definir progressivamente um projeto de nível muito alto a um design mais detalhado me serviu bem. Até as interações entre subsistemas são refinadas à medida que você tenta implementá-las. É uma coisa boa.

Eu acho que seria melhor se eu repassasse as especificações

Certo. Boa ideia.

planejei como o sistema funcionaria antes de codificá-lo.

Boa. Faça mais disso.

quais são os principais componentes

Excelente.

como eles vão interagir,

Corrigir.

Só não sei exatamente o que devo planejar.

Como você pode não ter certeza quando já listou várias coisas? Se essas são as coisas que lhe interessam, por que não se concentrar apenas nessas coisas?

Leia o modelo de exibição 4 + 1: http://en.wikipedia.org/wiki/4%2B1_Architectural_View_Model

Leia sobre a estrutura do Zachman: http://en.wikipedia.org/wiki/Zachman_Framework

É isso que você precisa planejar.

como devo: a) Dividir o projeto em componentes,

Use padrões de design amplamente adotados para outros projetos semelhantes.

Em caso de dúvida, leia os projetos J2EE para obter idéias.

http://www.oracle.com/technetwork/java/javaee/blueprints/index.html

como devo b) Planejar suas interações, por exemplo, devo fazer diagramas de classe, escrever testes de unidade etc.?

Sim. Boas ideias, tudo.

O mais importante a fazer: revisar as especificações, interagir com o cliente para obter especificações mais refinadas.

Os requisitos são indubitavelmente incompletos, vagos ou incorretos. O maior desperdício de tempo é fazer a coisa errada. Os clientes não são engenheiros de software profissionais e não se pode esperar que sejam bons no desenvolvimento de um bom conjunto de requisitos.

Portanto, você deve revisar as especificações, entrevistar o cliente e descobrir se é isso que ele / ela realmente precisa e deseja, pode pagar, etc.

Desenvolva casos de teste / uso e revise com o cliente. Se um requisito não for testável, jogue-o fora.

Desenvolva o design e verifique se todas as peças funcionam corretamente e que, em teoria, faria o que você precisa.

Desenvolva um protótipo de arquitetura que teste toda a tecnologia a ser usada em todas as camadas, mas ignore a funcionalidade. Você está testando a arquitetura, não a especificação funcional. Ter a arquitetura errada significa que você precisa reescrever tudo, portanto é importante obter a arquitetura correta. Certifique-se de que ele atenda aos seus requisitos de velocidade, eficiência, segurança etc.

Você definitivamente deseja ter algum design em prática antes de começar a codificar.

Depois disso, geralmente prefiro fazer uma fase inicial da arquitetura primeiro para definir como as camadas do aplicativo se encaixam. Isso incluiria coisas de backbone, como segurança e log.

Então eu construo um recurso de cima para baixo para que você implemente algo completamente.

Então vá de lá.

Tudo

Planeje tudo, é mais fácil trocá-lo no papel do que uma vez que parte dele já está codificado, você obtém uma excelente base de documentação e muitos outros benefícios.