Architecture 技术设计文件的工具和标准

我想知道现在我的同事在技术设计文档中使用了哪些工具和标准

---

在过去，当我们公司只提供客户机-服务器win应用程序时，我们的设计文档有word模板。我们的模板总是从数据库图开始，然后是UI模型、字段映射、功能描述等。。。有了Word和Visio，我们已经受够了。但最近我们正在结合Wiki、UML图、原型工具等。。。没有真正强有力的标准和工具政策。你认为让建筑师在每个项目的特定时刻自由选择他们认为合适的工具和标准是好的，还是公司应该在这方面强制执行和标准化

除非你的项目是千篇一律的，否则只有为手头的工作应用最佳的工具组合才有意义。也就是说，一些松散的（粗略的指导原则）或狭窄的（适用于特定情况）标准可能是有道理的。

在我看来，主要开发人员或团队成员之间的彻底讨论（可能记录在以后）比任何文档都更有价值。给他们选择工具的所有自由，并要求他们在早期只写一个高层技术决策的简短摘要。这可能是以后项目中文档的基础。技术设计文档很快就会过时，需要花费太多的时间来编写。

我认为应该有一套在体系结构时指定的工具和标准来描述如何记录设计。有一个记录这些事情的标准是非常重要的；否则，他们往往会半途而废；如果设计文档是异构的，那么真正需要了解设计的人可能无法在真正需要的时候找到他们真正需要的设计信息

---

也就是说，工具和标准的选择完全取决于每个不同的组织；对一个组织有效的东西对他们来说都是正确的。只要标准（以及工具，在某种程度上）保持一致性，为单个组织选择的任何东西都适合他们。它只需要决定和执行。

任何设计文档背后的原因都是与所有相关人员的清晰沟通。因此，从这个角度来看，无论您作为架构师选择什么工具，最终产品现在都需要由所有相关人员阅读，以后也需要由维护人员阅读。因此，至少选择一些相当标准的工具是有意义的，这些工具在几年后仍然存在

---

也就是说，设计文档通常用于启动项目或系统。此后，良好的代码文档和一些基本文档就足够了。我可能会更加注意文档的组织，这样人们就可以很容易地在将来找到他们想要的东西。它可以帮助实施某种标准的存储库结构/系统来存储文档，但不一定要坚持使用各种文档模板。关注内容而不是工具。

不幸的是，没有人真正回答你的问题。我在这里冲浪寻找比Visio更新更好的东西：）