随着岁月的流逝,我们获得越来越多的应用。弄清楚一个应用程序是否正在使用来自其他应用程序的功能可能很难。如果我们改变应用程序A中的某些内容,应用程序B中的某些内容会中断吗如何记录应用程序以及它们如何与其他应用程序集成?
我们一直在使用MediaWiki作为文档,但很难保持数据是最新的。
我想我们需要的是某种视觉地图的一切。并有可能创造某种参考完整性?有任何想法吗?
随着岁月的流逝,我们获得越来越多的应用。弄清楚一个应用程序是否正在使用来自其他应用程序的功能可能很难。如果我们改变应用程序A中的某些内容,应用程序B中的某些内容会中断吗如何记录应用程序以及它们如何与其他应用程序集成?
我们一直在使用MediaWiki作为文档,但很难保持数据是最新的。
我想我们需要的是某种视觉地图的一切。并有可能创造某种参考完整性?有任何想法吗?
我在同一条船上,仍然试图在CASE工具Enterprise Architect上销售我的同事。这是一个往返工具 - 图示代码的代码是可能的。它也是以UML为中心的 - 尽管它也支持我不熟悉的其他记法方法...
以下是选择用于记录设计的工具时需要考虑的一些事项(不管它们是系统间通信还是只是设计单个应用程序的内部):
该工具的可用性。也就是说,它不仅容易创建,而且还能维护您感兴趣的数据。
熟悉符号。
A.符号(如UML)必须是您的员工理解的符号。如果您尝试使用UML工具与少数人了解如何正确使用UML工具,那么您会遇到一些混淆,因为有些人错误地记录了事情,而了解UML实施内容的人要么发现错误,要么继续前进并实施错误记录的项目。相反,专业人员使用的更复杂的符号会混淆不熟悉的人。 B.文件不是/不应仅为文件专用人员创建。因此,那些将阅读文档的人必须了解他们正在阅读的内容。因此,获得具有灵活输出选项的工具总是一个不错的选择。
成本。有比Enterprise Architect更先进的工具。我之所以推荐使用这一工具,是因为缺乏UML熟悉度和高压时间表,使用基本结构图来留给自己或同龄人的教育空间不大。这个工具很容易实现这种用途,比StarUML更稳定。 (我尝试了两种方式,StarUML在大量代码的逆向工程中死亡 - 数百万行)对于小型项目,我发现StarUML足够用于家庭使用,直到我安装了Vista。作为开源,它也是免费的。
综上所述,您将永远需要记录什么使用什么,这意味着维护文档!这项任务是少数公司认识到其价值,尽管对于那些愿意这样做的人具有明显的价值。 。 。
+1:很棒的小费!但我不确定这个程序是我在找什么。也许是因为它看起来像一个非常详细的应用程序 – Tommy
CASE工具是冗长的,但您不需要使用所有方面。 许多公司经常忽略维护文档。最后,这是一个平衡的行动,涉及付出的努力。 有一个问题要问自己:如果** Feature X **没有“完整的”设计文档,那么任何人都能够理解它,并且不会在三年内破坏它? 如果答案是肯定的,那么吝啬它是“相对安全”的,而不是忽略它。 *含义**你是对的**,你可以在需要维护时免除额外的加速。* –
我希望有更多的选择,但这是唯一的一个 – Tommy