[quote=sergiotaborda][quote=rafadelnero][quote=sergiotaborda]
Finalmente, é preciso não confundir documentação com especificação. Especificação é feito antes, documentação é feito depois. O manual do usuário é uma documentação, a lista de requisitos é uma especificação. Lá porque ambas se escrevem (tradicionalmente) no word ( são “documentos do word”) não os torna documentação. Esta distinção é onde está o cerne da resposta. Planejamento precisa de especificação, não de documentação. A especificação é mutável, a documentação é imutável ( porque ela é gerada após o fato).
[/quote]
Você acha adequado planejar um sistema na cabeça? Se for um sistema relativamente grande diversos detalhes podem passar despercebidos. Talvez um diagrama de classes e levantamentos requisitos não ajudariam no processo?[/quote]
Vc não está querendo entender o que estou dizendo. O MiddleHeaven tem mais de 1800 classes. Vc acha que eu decorei todas ? Obviamente não. Mas sei o que cada uma faz ? sim. Precisei de documentar isso tudo ? não. Por quê ?
É importante entender por quê! Porque eu não precisei de explicar essa classes a ninguém**.
Agora, se vc me perguntar : vc nunca fez um boneco de organização disso ? Fiz. E alguns estão no proprio projeto em jude/astar, mas isso é documentação ? Não. É apenas um boneco. É uma ajuda de memória. Ninguem entender o MH vendo esses diagrama UML.
Todo o planejamento é feito mentalmente. Não se engane do contrário. É por isso que é preciso ter alguem com a visão do todo “the big picture”) ou o projeto sia torto. Não importa como vc chama a pessoa que tem esta visão, mas ela tem que existir ou não ha software. Bonecos podem ajudar a pensar, podem ajudar a comunicar, mas não são documentação.
A palavra “documentação” existe um peso e um calibre de linguagem que vc não precisa e não pode usar no dia a dia. Seria demasiado burocrático. É esse o erro das fábricas de software. Não adianta o cara passar 2 meses fazendo um uml se o cara que vai ler não sabe ler UML, e mesmo que saiba , tem cosias que não vão está lá escritas.
Quando vc diz "Você acha adequado planejar um sistema na cabeça? " Parece que vc quer dizer "Você acha adequado memorizar um sistema na cabeça? ". Não é a mesma coisa. Planejar não é memorizar. É um processo. É dinâmico. O que vc precisa lembrar está no código, e o que não pode ficar no código vc deixa num papel, numa lousa, numa wiki, etc… mas essas cosias não são documentação.
Se a sua pergunta é “deve criar artefactos que me ajudem a memorizar o que eu decidi para o software?” A resposta é: sim. Se vc pergunta "esses artefactos são documentação do software? " a resposta é : não.
Entenda a diferença.
Mais detalhes vc pode encotrar neste livro, que explica o real valor da documentação e o real valor de auxiliares de memoria. Procure também pelo conceito de “agile architecture”
P.S. ** E exactamente porque não tem formas de explicar, que ninguem usa
lol. É complicado documentar as coisas. Veja minhas tentativas no blog do middleheaven, já estão desatualizadas
Documentar exige um esforço muito maior que programar o negocio.[/quote]
Então o ponto é esse, deve-se desenvolver artefatos antes de começar a programar, dessa forma ficará mais fácil de implementar. Valeu pela explicação, vou dar uma lida nos materiais também!
Pelo que foi concluído então com diagrama de classes e casos de uso, pode-se desenvolver um sistema de qualidade da mesma forma que um sistema bem documentado claro que envolvendo todas premissas que foram citadas.