Como engenheiros, todos nós "projetamos" artefatos (edifícios, programas, circuitos, moléculas ...). Essa é uma atividade (projetar o verbo) que produz algum tipo de resultado (projetar o substantivo).
Acho que todos concordamos que projetar o substantivo é uma entidade diferente do próprio artefato.
Uma atividade importante nos negócios de software (de fato, em qualquer negócio em que o artefato resultante do produto precise ser aprimorado) é entender o "design (o substantivo)". No entanto, como comunidade, parecemos falhas praticamente completas ao registrá-lo, como evidenciado pela quantidade de esforço que as pessoas enviam para redescobrir fatos sobre sua base de códigos. Peça a alguém para mostrar o design do código e ver o que você recebe.
Penso em um design para software como tendo:
- Uma especificação explícita para o que o software deve fazer e quão bem ele faz
- Uma versão explícita do código (esta parte é fácil, todo mundo tem)
- Uma explicação de como cada parte do código serve para alcançar a especificação (por exemplo, uma relação entre fragmentos de especificação e fragmentos de código)
- Uma justificativa para o porquê do código ser do jeito que é (por exemplo, por que uma escolha específica e não outra)
O que NÃO é um design é uma perspectiva específica do código. Por exemplo [para não selecionar especificamente] diagramas UML não são modelos. Em vez disso, são propriedades que você pode derivar do código ou, sem dúvida, propriedades que você deseja derivar do código. Mas, como regra geral, você não pode derivar o código da UML.
Por que, após mais de 50 anos de construção de software, por que não temos maneiras regulares de expressar isso? (Fique à vontade para me contradizer com exemplos explícitos!)
Mesmo se o fizermos, a maioria da comunidade parece tão focada em obter "código" que o design do substantivo se perde de qualquer maneira. (IMHO, até que o design se torne o objetivo da engenharia, com o artefato extraído do design, não vamos contornar isso).
O que você viu como meio para gravar projetos (no sentido que eu descrevi)? Referências explícitas a artigos seriam boas. Por que você acha que meios específicos e gerais não foram bem-sucedidos? Como podemos mudar isso?
[Tenho minhas próprias idéias que realçam o ponto de vista com marcadores acima, mas estou interessado nas respostas de outras pessoas ... e é difícil implementar meu esquema [[e talvez esse seja o verdadeiro problema: -]]]
EDIT 2011/1/3: Um dos tópicos de resposta sugere que a "documentação" (presumivelmente textual, em particular não formal) pode ser adequada. Acho que devo esclarecer que não acredito nisso. As ferramentas CASE apareceram em cena nos anos 80, mas as ferramentas mais antigas capturavam pixels para os diagramas do que você desenhou; embora as ferramentas tenham um sucesso comercial comprovável, elas realmente não foram muito úteis. Um insight importante foi que, se os artefatos adicionais de "design" não forem formalmente interpretáveis, você não poderá obter nenhuma ajuda séria da ferramenta. Acredito que o mesmo insight se aplique a qualquer forma útil de captura de design a longo prazo: se não tiver uma estrutura formal, não será de uso real. Documentos de texto praticamente falham neste teste.