Como dividir o desenho do seu software em etapas executáveis
O desenho do software tem várias etapas e é importante não atropelá-las. É interessante que você invista tempo e esforço antecipadamente como uma equipe para concluir o processo de design de software antes de iniciar a fase de desenvolvimento do seu projeto.
Como você provavelmente já tem um plano de projeto antes de montar seu design de software, já sabe com que orçamento, recursos, tempo e outros parâmetros está trabalhando. Do seu planejamento de arquitetura de software, você também terá informações sobre requisitos funcionais e não funcionais para seu software, expectativas das partes interessadas e decisões que você já tomou que se aplicam a toda a sua arquitetura de software.
Seu processo de design de software pegará o que você já fez e criará um roadmap para a codificação e implementação do software. Ao passar por esse processo, tenha em mente que um bom desenho de softwaredesign de software segue estes princípios fundamentais:
-
Simplicidade: a complexidade por si só não é útil, e apenas aumenta o uso de recursos, os gastos com manutenção e os desafios associados ao seu software. Cada tarefa deve ser modificada e usada de forma independente com seu próprio módulo para tornar seu código fácil de usar. E se houver uma maneira mais simples de fazer a mesma coisa (todo o resto sendo igual), escolha o caminho simples.
-
Modularidade: dividir seu projeto em peças facilita a realização de suas metas. Isso é conhecido como modularidade e também é um tema comum nas metodologias Ágil, permitindo que você use sprints para finalizar recursos ou tarefas específicos, um de cada vez.
-
Integralidade e suficiência: seu software deve ser completo. Ele deve ser construído para ser adequado e atender aos requisitos do seu projeto.
-
Antecipar mudanças: quando e onde for possível, você deve criar seu software se preparando para mudanças e antecipando requisitos diferentes daquilo que é necessário hoje. Embora seja impossível prever totalmente o futuro, os melhores desenhos de software consideram o futuro e se preparam.
-
Abstração: o desenho do software deve ser capaz de montar um plano, incluindo informações relevantes e excluindo aquelas que não são imediatamente relevantes. Portanto, seu plano provavelmente não especificará todos os detalhes exatos, mas usará abstração.
-
Acoplamento: quando possível, o desenho do software deve ter baixo acoplamento e permitir que sua equipe faça alterações em um módulo do seu software sem afetar significativamente outros módulos.
Início do processo de desenho do software
Lembre-se de que você só pode começar o desenho do software depois de ter feito sua lição de casa. Requisitos, análise de risco e análise de domínio devem ser estabelecidos primeiro para ajudar você a definir seu projeto em etapas.
-
Requisitos: os requisitos do seu software incluem expectativas funcionais e não funcionais que descrevem as necessidades comerciais e do usuário. Esses são os recursos e características que seu software deve ter.
-
Análise de risco: antes de começar seu projeto, você deve estudar os riscos potenciais desse projeto e fazer o que puder para antecipar como esses riscos podem impactar o desenvolvimento do software de modo geral. Além dos riscos gerais de gestão de projetos, como estourar o orçamento ou não conseguir encontrar o pessoal de que precisa, quais são os riscos técnicos?
-
Análise de domínio: nesta etapa, você deve descobrir mais sobre o domínio para entender um pouco melhor os problemas e desafios, bem como procurar pontos em comum entre os sistemas de software relacionados.
Preenchimento do documento de especificação de requisitos
Em seguida, é hora de estabelecer suas expectativas de desenho de softwaredesign de software e compilá-las em documentos de design de software (software design documents, SDD). Um SDD ajuda você a se manter no caminho certo durante o processo de codificação e reduzir a probabilidade de fazer códigos desnecessários ou ter que começar do zero. Em um documento centralizado, você registrará dependências, recursos e outras documentações valiosas.
Veja o que um SDD geralmente inclui:
-
Título, autores e revisores: informações básicas sobre o projeto, incluindo uma lista de partes interessadas e os nomes da equipe de engenharia.
-
Descrição funcional: o que o software faz, assim como outros detalhes, como procedimentos de inicialização, tratamento de erros, limites de usuário etc.
-
Interface do usuário: informações e diagramas que ensinam o sistema e como usá-lo aos usuários.
-
Marcos e metas: marcos importantes para a equipe de engenharia e metas para acompanhar o progresso.
-
Uma matriz de priorização: recursos classificados e histórias de usuários com base na prioridade.
-
Seção de soluções: uma descrição da história do usuário por trás do seu software.
-
Cronograma não técnico: um cronograma para não engenheiros que desejam entender os marcos do seu projeto e compreender um pouco mais.
