2010-03-25 127 views
2

我看到一些关于源代码的文件夹结构的问题,但我从来没有看到项目文档的文件夹结构的问题。我GOOGLE了它,仍然没有看到很多文章谈论。 这里是一个http://www.projectperfect.com.au/downloads/Info/info_project_folder_structure.pdf项目文档的文件夹结构

引述了它的一些字:

“有两大类方法:

  1. 通过相,使得每个顶部 目录是一个相组织。例如。 , 您可能有目录 可行性,业务分析, 设计等或任何您的阶段 被称为。
  2. 按功能组织,使顶层目录 为功能。对于 例如,风险要求范围变更控制发展

大多数时候,两者的混合使用......”

所以关于它的任何想法?我相信这也是一个重要的问题!根据您的文档管理系统的选择

回答

1

恕我直言文件的结构可能不是问题当你看到项目相关文件试图解决的问题时,你通常会得出文件是关于通信的结论

不同的文档试图传达不同的事物(或上下文) ;测试计划di scuss应该如何执行测试,要求规范讨论如何应用业务规则,架构文档讨论技术组件等等。这些文件中的每一个都可能需要它自己独特的结构。例如,您为测试计划选择的结构可能与架构文档所需的结构大不相同。

当保持沟通的问题和文件的上下文时,我通常会回到这两个关键方面。

  1. 搜索能力 - 什么是最简单的方法来找到我正在寻找的文档?
  2. 版本控制 - 我如何知道我正在查找的文档是最新的?

我觉得可搜索性是最重要的事情要记住,因为不同的人用不同的名字称呼相同的文档。例如有些人称业务需求文档功能规格。有些人称之为功能规格用例文档。由于您不能总是管理文档的命名约定,我觉得找到合适的文档比存储文档的文件夹或地点更重要。

所以要回答你的问题,我简单地回答说,你使用哪种结构并不重要,只需要使用某种形式的文档管理系统(SharePoint,Documentum,Trim等)。如果没有一个,好处是太好了,无法正常工作:)

+0

如果您有工具将元数据添加到您的文档并基于此构建可搜索性,那将是一大优势。 但我认为你仍然需要组织你的文档。将状态报告,设计文档和测试计划放在同一个文件夹中确实不是一个好主意。 – Qiulang 2010-03-25 14:33:22