项目文档的文件夹结构
我看到一些关于源代码的文件夹结构的问题，但我从未看到关于项目文档的文件夹结构的问题。我用谷歌搜索了一下，仍然没有看到很多文章谈论。 这是一个 http://www.projectperfect.com.au/downloads/Info /info_project_folder_struct.pdf
引用其中的一些内容：
“有两种广泛的方法：
- 按阶段组织，以便每个顶部 目录是一个阶段。例如， 你可能有目录 可行性、业务分析、 设计等或无论您处于什么阶段 被称为。
- 按功能组织，以便顶部 目录级别是函数。为了 例如，风险、要求、范围、 变更控制、开发。
大多数时候两者混合使用......”
那么有没有想过？我相信这也是一个重要的问题！
I saw some questions raised about the folder structure of source codes, but I never see the question about folder structure of project documentation. I googled it and still do not see many articles talk about.
Here is one http://www.projectperfect.com.au/downloads/Info/info_project_folder_structure.pdf
To quote some of its words:
"There are two broad approaches:
- Organize by phase so that each top
directory is a phase. For example,
you might have directories for
Feasibility, Business Analysis,
Design etc. or whatever your phases
are called. - Organize by function so that the top
directory level are functions. For
example, Risks, Requirements, Scope,
Change Control, Development.
Most times a mix of both are used..."
So any thought about it? I believe this is also an important issue!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
恕我直言，根据您的文档管理系统，文档结构的选择可能不是问题。当查看项目相关文档试图解决的问题时，您通常会得出这样的结论：文档是关于沟通的。
不同的文档试图传达不同的事物（或上下文）；测试计划讨论测试应该/已经如何执行，需求规范讨论应该如何应用业务规则，架构文档讨论技术组件等等。这些文档中的每一个都可能需要其自己独特的结构。例如，您为测试计划选择的结构可能与您的架构文档所需的结构有很大不同。
当牢记沟通问题和文档上下文时，我通常会回到这两个关键方面。
我认为可搜索性是要记住的最重要的事情，因为不同的人用不同的名称称呼同一个文档。例如，有些人将业务需求文档称为功能规范。有些人将功能规范称为用例文档。由于您无法始终控制文档的命名约定，因此我认为找到正确的文档比存储文档的文件夹或位置重要得多。
因此，为了回答您的问题，我会简单地回答说，您使用哪种结构并不重要，只是您应该使用某种形式的文档管理系统（SharePoint、Documentum、Trim 等）。这些好处实在是太大了，没有它就无法工作:)
IMHO depending on your document management system the choice of structure for your documents may not be an issue. When looking at the problems project related documents are trying to solve you typically come to the conclusion that documents are about communication.
Different documents attempt to communicate different things (or contexts); test plans discuss how testing should/has been executed, requirements specifications discuss how the business rules should be applied, architecture documents discuss the technical components and so forth. Each of these documents might have the need for its own unique structure. For example the structure you choose for your test plans may be vastly different from the structure you need for your architecture documents.
When keeping the communication issue and the document context in mind I generally come back to these 2 key aspects.
I feel searchability is the most important thing to remember because different people call the same document by different names. For example some people call Business Requirements documents Functional Specifications. Some people call Functional Specifications use case documents. As you cannot always govern the naming convention of documents I feel finding the right document to be far more important than the folder or place in which it is stored.
So to answer your question I would simply answer by saying it doesn’t really matter which structure you use, just that you should use some form of document management system (SharePoint, Documentum, Trim, etc). The benefits are simply too great to work without one :)