Software para organizar e manter a documentação do projeto, especificação? [fechadas]

Estou procurando um software para organizar e manter a documentação interna, especificação, requisitos, etc. Atualmente, armazenamos toda a documentação como muitos arquivos do MS Word DOC em um repositório de controle de origem, o que nos dá controle de versão, e isso é legal. Mas você não pode pesquisar essas informações, criar links entre elas, categorizar, colaborar.

Requisitos, preferências:

• Zero instalação no lado do cliente (baseado na WEB).
• Controle de versão do documento.
• Anotações de documentos.
• Vinculação de documentos.
• Pesquisa completa (toda a documentação).
• Importação \ exportação do MS Word (* .doc).
• Editor de texto WYSIWYG.

Sistemas que descobri e tentei até agora:

• MediaWiki
• XWiki
• Confluência

Que tal algo como Sphinx ?

Você escreve sua documentação em reStructuredText (a sintaxe é semelhante ao Markdown, que o Stack Overflow usa) em arquivos de texto sem formatação (= fácil de controlar a versão) e o Sphinx cospe páginas HTML.

Os dois usuários mais importantes do Sphinx (que eu conheço) são a linguagem Python e o TortoiseHG (consulte os links para a documentação gerada pelo Sphinx).

EDITAR:

Acabei de ler que você está falando sobre a documentação interna do projeto, e não a documentação do usuário final.
Na minha opinião, algo como o Sphinx também é a melhor maneira de documentação interna (desde que você possa solicitar que seus analistas escrevam reStructuredText) porque:

1. Você pode controlar com facilidade os documentos (as diferenças de arquivos de texto ocupam muito, muito menos espaço do que arquivos binários como .doc ou .pdf).
2. Se um desenvolvedor deseja um arquivo .doc ou .pdf legível, ele pode criá-lo com o Sphinx a partir das fontes.

Se o Sphinx for muito complicado, existe ainda uma maneira mais fácil: você pode escrever sua documentação no Markdown e usar o Pandoc para criar (por exemplo) arquivos .rtf, .doc ou .pdf (pode fazer muito mais).
Achei o Pandoc mais fácil de iniciar do que o Sphinx, mas o Pandoc não pode criar hierarquias de menu agradáveis, como o Sphinx (como na documentação do Python e do TortoiseHG que eu vinculei acima).

Independentemente das ferramentas usadas, se você possui um servidor web interno e um servidor de construção, é possível configurá-lo para que o servidor de construção gere saída HTML e a copie no servidor da Web sempre que alguém enviar algo à documentação. Para que seus analistas nem precisem pensar na saída final, eles apenas precisam confirmar e promover suas alterações.

Bem, você pode tentar implementar um Wiki. O Mediawiki possui todos os recursos que você está falando (funções de pesquisa, histórico de versões, links, categorização). Você precisará certificar-se de que sabe exatamente qual versão da documentação pertence a qual versão do software, mas isso pode ser feito com a convenção de incluir uma referência de versão ou uma categoria específica em cada artigo dependente da versão.

MAS: Você escreve que tem "analistas" que não são desenvolvedores (admito, não sou fã dessa constelação). Esse tipo de pessoa geralmente não fica feliz quando você substitui as ferramentas do MS Office por alguma ferramenta textual, como um Wiki. E como o MS-Word não é um software livre, acho que o requisito "software livre" não é realmente obrigatório. Nessa situação, um servidor do Sharepoint pode ser a melhor alternativa. Não é gratuito, mas o AFAIK possui todos os recursos que você está solicitando e os documentos ainda podem ser criados usando o Word, Excel etc.

É sempre melhor manter a especificação e a documentação sob controle de versão, pois isso proporcionaria a maior vantagem, embora a curva de aprendizado fosse um pouco íngreme. No caso de um mecanismo de conhecimento, recomendo o seguinte

1. Trac - Sistema de rastreamento de erros e mecanismo de conhecimento fáceis de usar. Escrito em Python e extensível, você estará em funcionamento em alguns minutos
2. MoinMoin - Mecanismo wiki completo. Novamente Python com muitos recursos

Ambos possuem interfaces mínimas, suportam a maioria das estruturas wiki, são fáceis de implantar e manter, suportam revisões, possuem um bom editor WYSIWYG e você também pode manter sua documentação e especificação. A menos que seus projetos sejam realmente grandes, você pode escolher qualquer uma das opções acima.

Recentemente, começamos a usar o Alfresco DMS, que possui muitas propriedades interessantes:

• Instalação muito simples
• Possui um indexador embutido para pesquisas rápidas em vários documentos
• Permite fluxos de trabalho, grupos e, se necessário, acesso específico a documentos pelos clientes
• Código aberto
• Comunidade ativa
• Integração LDAP / AD / SSO
• Lida com muitos documentos diferentes

Existem também algumas desvantagens:

• A interface do usuário nem sempre é intuitiva
• Não é realmente um wiki, então o trabalho colaborativo simultâneo em um documento pode ser um pouco frágil

Se você decidir fazer um balanço, entre em contato comigo com suas opiniões.

Outra possibilidade pode ser usar o LaTeX ou algum outro formatador de texto (talvez texinfo ou mesmo lout ) para documentação. Partes dele podem ser geradas à máquina. Existem algumas ferramentas para conversão de HTML, como o HeVeA para converter o LaTeX em HTML. Você também pode usar doxygen para gerar documentação a partir de comentários estruturados dentro do seu código-fonte. E as partes escritas à mão da documentação podem (e devem) ser gerenciadas como código fonte (por exemplo, controle de versão e construção).

Eu sugeriria o uso de uma ferramenta UML e ERD, além de seus documentos. Além disso, você pode armazenar esses documentos no ZOHO no ZOHO-Docs , que não é gratuito, mas é extremamente barato e permite recursos de pesquisa de documentos.

Qualquer que seja a ferramenta que você usa, é necessário organizar cuidadosamente o conteúdo do documento para poder usar a pesquisa de texto e obter resultados significativos. A organização do conteúdo do documento, juntamente com a nomeação inteligente e padrão de arquivos, pode ajudar bastante.