Quais artefatos de design essenciais você produz?[fechado]

Question

No decorrer do ciclo de vida de desenvolvimento de software, quais artefatos essenciais de design você produz?O que os torna essenciais para sua prática?

O projeto em que estou atualmente está em produção há mais de 8 anos.Este aplicativo da web foi ativamente aprimorado e mantido ao longo desse tempo.Embora tenhamos políticas e processos baseados no CMMI em vigor, com partes da nossa prática bem definidas, a fase de design tem sido amplamente negligenciada.Melhores práticas, alguém?

Answer 1

Tendo trabalhado em muitos projetos em cascata no passado e em muitos projetos ad hoc e ágeis mais recentemente, há uma série de artefatos de design que gosto de criar, embora não possa afirmar o suficiente que isso realmente depende dos detalhes do projeto ( metodologia/estrutura da equipe/prazo/ferramentas etc.).

Para um 'aplicativo corporativo' genérico baseado em servidor, eu gostaria que o mínimo fosse algo assim:

• Um documento detalhado de design funcional (também conhecido como especificação).Geralmente algo parecido com o de Joel Especificação de exemplo WhatsTimeIsIt, embora provavelmente com alguns diagramas de casos de uso UML.
• Um documento de design técnico de software.Não necessariamente detalhado para cobertura de 100% do sistema, mas detalhado em todas as áreas principais e contendo todas as decisões de projeto.Sendo um pouco fanático por UML, seria bom ver muitas imagens ao longo das linhas de diagramas de pacotes, diagramas de componentes, diagramas de classes de recursos principais e provavelmente alguns diagramas de sequência incluídos para uma boa medida.
• Um documento de projeto de infraestrutura.Provavelmente com diagrama de implantação UML para a concepção conceitual e talvez um diagrama de rede para algo mais físico.

Quando digo documento, qualquer um dos itens acima pode ser dividido em vários documentos ou talvez armazenado em um wiki/alguma outra ferramenta.

Quanto à sua utilidade, minha filosofia sempre foi que uma equipe de desenvolvimento sempre deveria ser capaz de entregar um aplicativo a uma equipe de suporte sem ter que entregar seus números de telefone.Se os artefatos de design não indicarem claramente o que o aplicativo faz, como faz e onde faz, então você sabe que a equipe de suporte dará ao aplicativo o mesmo cuidado e atenção que daria a um cachorro raivoso.

Devo mencionar que não estou justificando a prática de entregar software de uma equipe de desenvolvimento para uma equipe de suporte, uma vez que esteja finalizado, que levanta todo tipo de questões interessantes, só estou dizendo que deveria ser possível se a administração assim o desejasse.

Answer 2

Código de trabalho...e desenhos no quadro branco.

:P

Answer 3

Os designs mudam tanto durante o desenvolvimento e depois que a maioria dos meus documentos cuidadosamente elaborados apodrecem no controle de origem e se tornam quase mais um obstáculo do que uma ajuda, uma vez que o código está em produção.Vejo os documentos de design como necessários para uma boa comunicação e para esclarecer seu pensamento enquanto você desenvolve algo, mas depois disso é necessário um esforço hercúleo para mantê-los devidamente mantidos.

Eu tiro fotos de quadros brancos e salvo os JPEGs no controle de origem.Esses são alguns dos meus melhores documentos de design!

Answer 4

Em nosso modelo (que é bastante específico para aplicações de processos de negócios), os artefatos de design incluem:

• um modelo de dados de domínio, com comentários sobre cada entidade e atributo
• um arquivo de propriedades listando todos os gatilhos de modificação e criação em cada entidade, atributos calculados, validadores e outras lógicas de negócios
• um conjunto de definições de tela (modelo de visualização)

Mas será que estes realmente contam como artefatos de design?Nossa estrutura é tal que essas definições são usadas para gerar o código real do sistema, então talvez elas vão além do design.

Mas o fato de eles cumprirem uma função dupla é poderoso porque estão, por definição, atualizados e sincronizados com o código o tempo todo.

Answer 5

Este não é um documento de design em si, mas nosso testes unitários servem ao duplo propósito de "descrever" como o código que eles testam deve funcionar.A parte legal disso é que eles nunca fique desatualizado, já que nossos testes de unidade devem passar para que nossa compilação seja bem-sucedida.

Answer 6

Não acho que nada possa substituir uma boa e velha especificação de design pelos seguintes motivos:

• Ele serve como um meio de comunicar como você construirá um aplicativo para outras pessoas.
• Ele permite que você tire ideias da cabeça para que não se preocupe em rastrear um milhão de coisas ao mesmo tempo.
• Se você tiver que pausar um projeto e retornar a ele mais tarde, você não estará reiniciando seu processo de pensamento.

Gosto de ver várias informações em uma especificação de design:

• Explicação geral da sua abordagem ao desafio em questão
• Como você monitorará seu aplicativo?
• Quais são as preocupações de segurança e como são abordadas?
• Fluxogramas/diagramas de sequência
• Problemas em aberto
• Limitações conhecidas

Os testes de unidade, embora sejam um item fantástico e indiscutivelmente crítico para incluir no desenvolvimento de seu aplicativo, não cobrem todos esses tópicos.