程序/游戏设计工作流程

Question

程序员类型：

您是否为程序或游戏编写了大量的设计文档？ 正在使用UML绘制用例图的标准方法吗？ 根据软件的范围和团队中的开发人员数量，您是否运行了整个图表或各种选择？

Answer 1

首先，

如果您的文档，它应该有一个 “清” 的理由/目的。 这个目的是识别你的文档的性质。

其次：

不要以为文件只是一个 “书面形式” 或Word文档。 它可以是任何form.Even它可以是一个“视频”，其中一些人 说明你的主要架构decisons，为什么他们选择 它[动机]

好吧，假设你想新的团队成员“轻松抓取”你在做什么，你是怎么做的，为什么你在做这样。[要当心一切都取决于你的问题的性质]

• UML用例图可能可以给你的功能的整体画面 要求。它只是说明谁将使用你的系统，以及他们可以用你的系统做什么。
• 短备忘录此状态下，重要的非功能性需求
• 简短的备忘录其中指出你的主要架构决策，为什么你把这个决定
• 也许组件图，它显示了你的重要组成部分，它们的接口
• 如果应用tapology非常重要，那么可能是一个UML部署图，它显示了你的系统将如何物理部署。

但毕竟你不能证明事情，你不应该。你可以用一个UML工具自动生成整个系统的UML类图，但这对新手有什么帮助。

• 但你可以把类图，为做重要和棘手的 零件类和绘制序列图的那些节目的同时，他们的表现很重要和棘手 责任，他们与其他类如何 合作棘手的部分。

为文件建立的关键是puting自己变成你的“观众” [谁 将阅读您的文件]，并问自己

• 如果我是这个文件potantial“观众”将我读到这文件？ [如果不是你为什么做文档]
• 如果我阅读这个文档，它会以某种方式帮助我吗？[它是有效]

最后，我们并不是生活在“理想字” ......有时候，你可能会发现自己做的文档没有真正的观众和没有真正的理由只是因为一些“政治”和你应该赚钱

那么，在这种情况下，UML将有所帮助。绘制无聊，有许多细节[通常aulectumatically生成]图表，没有人阅读或理解，但说“哦，你有大量的文件”。在我们的软件行业中，UML被过分强调了，如果有UML图，许多人甚至会“买”甚至是坏的文档。

这就是所有人...