Atualmente, estou trabalhando na minha graduação para meus estudos de "Desenvolvimento de Software", nos quais tenho que desenvolver software complexo individualmente em uma empresa externa. Tudo isso precisa ser feito de maneira estruturada, criando todos os documentos correspondentes.
Para este projeto, decidi trabalhar com os documentos padrão do IEEE: Documento de Requisitos de Software (SRS), Documentos de Arquitetura de Software (SAD) e Documento de Design de Software (SDD). Embora ensinado o contrário na escola, para este projeto eu escolhi criar o SDD após o desenvolvimento (em vez de antes). Meu raciocínio é:
A empresa em que faço meu estágio me deu instruções para criar um software complexo, satisfazendo um certo conjunto de requisitos, de maneira experimental. Devido à quantidade de liberdade que eles me deram na definição do projeto, quase nada é certo de antemão, e pode ser melhor encontrado durante as experiências no processo de desenvolvimento. Além disso, estou criando o software de maneira individual . Não traria nenhum benefício para qualquer pessoa na empresa fazer esse design de software com antecedência. Fazer isso de antemão me custará muito tempo para alterá-lo mais tarde, pois posso ter certeza de que, com as incertezas do projeto, o design que faço antes terá que ser muito alterado . Isso parece contraproducente para mim.
Essa é uma boa justificativa para criar o SDD após o desenvolvimento? Caso contrário, haveria uma boa justificativa para isso?
Edit: O motivo para criar o SDD posteriormente seria para futuros desenvolvedores continuarem no projeto. Não poderei concluir o projeto inteiro no meu período de graduação, portanto outros desenvolvedores terão que continuar na base de código atual.
fonte
Respostas:
No IEEE Std 1016 Seção 3.1 Design de software em contexto, você pode encontrar este parágrafo:
Os autores do IEEE Std 1016 reconhecem que um SDD não pode ser criado antecipadamente. Um pode ser criado depois que o sistema de software existir, a fim de capturar informações para as partes interessadas.
A Seção 1.1 também fornece algumas informações interessantes:
No contexto dessas perguntas, as palavras-chave são "gerenciamento de configuração". O gerenciamento de configuração não se aplica apenas ao sistema de software que está sendo criado, mas a qualquer documentação associada.
Na sua situação pessoal e em muitas situações, criar um SDD antecipadamente é um desperdício. A resposta de David Arno está perto de ser o que eu consideraria a resposta certa. O verdadeiro design do seu sistema de software é o código. No entanto, você "cria o SDD antes" ou "cria o SDD depois" não são suas únicas opções. Você tem uma terceira opção - evolua o SDD com o sistema de software.
Se você está seguindo um padrão como o IEEE Std 1016, possui requisitos para um SDD. Especificamente, a Seção 4 deste padrão define o conteúdo que você possui. À medida que você trabalha nas decisões de design, comece a criar os diferentes pontos de vista, vistas e sobreposições. Ao tomar decisões, capture a lógica do design para elas.
Isso permitirá que as partes interessadas sigam a evolução do design do software sem precisar se aprofundar no código. Obviamente, as pessoas podem ter comentários ou sugestões. Se você estiver atualizando o SDD, eles poderão acompanhar seu progresso e fornecer feedback sobre a abordagem mais cedo, que você poderá incorporar ao produto e ao SDD. Quando você faz a transição do projeto, se o código do software e o SDD estiverem em sincronia, alguém deverá ser capaz de facilmente integrar e iniciar o trabalho.
fonte
Se tudo o que você procura no SDD é comunicar o design com outras pessoas, sim, você pode criá-lo após o desenvolvimento. A única coisa é que é chamado de documentação.
No entanto, gostaria de salientar que um SDD também pode servir a outro propósito. Também pode ajudá-lo a raciocinar sobre o design e garantir que "falhe rapidamente". Isso é bom, especialmente se muitas coisas são incertas de antemão, porque você pode descartar abordagens que não funcionariam durante toda a implementação desde o início. Também pode impedir que você se concentre nos detalhes técnicos em breve, não codificando nada até descobrir o design.
Eu aconselho você a, pelo menos, fazer uma tentativa no SDD de antemão. Se você encontrar coisas nas quais não tem certeza de como as coisas funcionariam, poderá criar pequenos protótipos dos problemas que está tentando resolver. Isso lhe dará experiência na solução de problemas específicos do seu projeto que beneficiarão a qualidade da solução completa a longo prazo.
fonte
O único documento de design detalhado e verdadeiro que você criará é o código. Ele diz precisamente ao compilador como criar seu aplicativo. Como tal, seu design não pode ser concluído até a construção final antes do envio.
Quaisquer outros documentos de design que você criar, como um SDD, precisarão ser atualizados após a conclusão do design (código). Portanto, há um motivo convincente para escrever o SDD posteriormente: você só precisa fazer isso uma vez.
O contrário óbvio disso é: "com que frequência você realmente escreve um SDD após o evento"? O aplicativo é enviado, portanto, é provável que você não queira gastar tempo documentando nessa fase. Mas isso se aplica igualmente à atualização de um existente. O que é pior: nenhum SDD ou SDD está errado e não pode ser confiável?
Existem duas razões para escrever com antecedência. Em primeiro lugar, pode ser um requisito obrigatório para você fazer isso (não é legal; mas acontece). Em segundo lugar, a criação desse documento pode ajudá-lo a formular uma estratégia geral para o design. Mas isso pode ser feito igualmente bem desenhando, anotando notas, etc., de maneira informal. E como ele precisará ser reescrito posteriormente, há muitos benefícios na abordagem "rápida e suja" desse processo inicial de design de macro.
fonte
The app is shipped, so you aren't likely to want to spend time documenting at that stage.Nesse caso, o aplicativo não será finalizado dentro do meu período de graduação, portanto, precisamos de documentação para que outros desenvolvedores possam continuar o desenvolvimento do produto.Para mim, não seria uma boa argumentação.
Se realmente necessário, eu argumentaria com um forte foco no desenvolvimento de protótipos para uma melhor compreensão de um domínio de problema desconhecido. No entanto, mesmo nesses casos, algumas peças de design seriam úteis antes.
fonte
Há um argumento a ser feito para fazê-lo de qualquer maneira . Porque você está fazendo isso para aprender a escrever documentos como este. Ignorar este trabalho porque talvez não seja 100% necessário aqui significa que você ignora seu aprendizado.
Um compromisso pode ser escrevê-lo durante a implementação. Antes de cada componente / módulo / tela ou outra subdivisão do seu programa, você precisa pensar sobre como fazê-lo. Em seguida, você adiciona suas decisões ao documento de design e as implementa.
Se algo mudar mais tarde, você atualiza o documento.
Isso tem várias vantagens em comparação com a escrita após o fato:
Você aprenderá a manter os documentos de design atualizados quando os requisitos mudarem, um hábito útil
Você aprenderá a pensar em design antes da implementação
Não é tão entediante como escrever documentos de design depois que o fato é
Se o tempo acabar, você terá um documento de design descrevendo o que você tem até agora para que outras pessoas possam continuar seu trabalho
Não é muito trabalho extra dessa maneira
À medida que o projeto avança, você pode não ter certeza do motivo pelo qual fez algo assim há dois meses e terá suas anotações para lhe contar.
fonte
System Design Document, um registro de requisitos básicos mais (novos recursos) é atualizado à medida que o projeto avança com novos atributos de design e solução. Mantido até que o projeto / solução seja entregue. Útil, ele se comunica com todos os envolvidos.
fonte