江苏龙网

  1. 主页 > 生活百科 > >

如何才能写出好的软件设计文档？ 软件设计文档模板

软件设计文档模板(怎样才能写出好的软件设计文档？)
作为一名软件工程师，我花了很多时间阅读和编写设计文档 。经过上百份文档的磨练，我发现优秀的设计文档与项目的成功息息相关 。
本文将介绍如何撰写一份优秀的设计文档 。
为什么要写设计文档？
一份文件，或技术规范，是用来描述你打算如何解决这个问题 。已经有很多文章解释了为什么设计文档应该写在编码之前 。这里不再赘述，但我想再补充一句:
设计文档是确保正确完成工作的最有用的工具 。
设计文档的主要目的是迫使你仔细思考设计，并收集他人的反馈，以便更好地完成工作 。一般认为，设计文档的目的是让别人了解某个系统，或者作为参考文档 。这些只是设计文档有益的副作用，但绝不是其根本目的 。
根据经验，如果你的项目需要一个人月或者更多，那么你应该写设计文档 。此外，一些小项目也可以受益于迷你设计文件 。
但是，不同的工程团队，甚至同一个团队的工程师，写设计文档的方式是不一样的 。接下来，我们来谈谈优秀设计文档的内容、风格和流程 。
设计文档应该包含什么？
设计文档描述了问题的解决方案 。因为每个问题的性质不同，设计文档的结构也不同 。
这里有一个列表 。你至少可以考虑把它写进文件里 。
标题和字符
设计文档的标题、作者(应该与计划参与项目的人员列表相同)、文档的审阅者(将在“过程”部分详细讨论)以及文档的最后更新日期 。
摘要
摘要可以帮助公司的每个工程师理解文档的内容，决定是否继续阅读文档的其余部分 。摘要最多可包含3个段落 。
背景
描述要解决的问题，为什么需要这个项目，需要哪些知识的人来评价这个项目，它与技术战略、产品战略或者团队的季度目标的关系 。
目标和非目标
目标应包括:
描述项目对用户的影响——你的用户可能是另一个工程团队或者另一个系统 。
指定如何使用指标来衡量项目的成功-如果能链接到指标仪表板就更好了 。
非目标同样重要 。它们用来描述项目不会解决什么问题，让大家达成共识 。
里程碑
一系列可测量的检查点，通过这些检查点，你的项目经理和老板可以大致知道项目的每个部分何时完成 。如果项目持续时间超过一个月，我建议你为用户将项目分解成里程碑 。
设置里程碑时，可以使用日历日期，考虑到延迟、假期和会议等因素 。示例:
开始日期:2018年6月7日
里程碑1-在黑暗模式下运行新系统MVP:2018年6月28日
里程碑2-抛弃旧系统:2018年7月4日
结束日期:向新系统添加新功能X、Y和Z:2018年7月14日
如果某些里程碑的ETA发生变化，需要在这里添加【更新】，这样相关人员就可以很容易的看到更新的内容 。
目前的方案
除了描述当前的实现，还应该举例说明用户如何与系统交互以及数据如何在系统中流动 。
此时可以使用用户故事 。记住，你的系统可能有不同类型的用户，他们的使用场景是不同的 。
拟议方案
有人称这部分为技术架构 。这一部分也可以通过用户故事来体现，可以包含多个小节和图表 。
从大的方面开始，然后补充细节 。您应该确保即使您在荒岛上度假，团队中的其他工程师也能根据您的描述实现解决方案 。
其他选择
在提出上述解决方案的同时，有没有考虑过其他的解决方案？替代方案的优缺点是什么？您是否考虑过使用第三方解决方案——或者开源解决方案——来解决问题，而不是构建自己的解决方案？
以及监控和警报 。
人们往往把这一部分当作事后的想法，甚至直接忽略 。问题发生后，他们很着急，却不知道该怎么办，也不知道为什么会出现这些问题 。
跨团队影响
这样会不会增加倒班待机和DevOps的负担？
它的成本是多少？
会增加系统延迟吗？
会不会暴露系统安全漏洞？
会带来哪些负面后果和副作用？
支持团队应该如何与客户沟通？
讨论
此部分可以包含您不确定的任何问题、您希望阅读文档的人一起权衡的有争议的决定、对未来工作的建议等等 。
详细的范围和时间表
本部分的主要读者是参与项目的工程师、技术主管和管理人员 。因此，这一节放在文件的末尾 。
本质上这就是项目计划的实施方法和时间分解，可以包含很多内容 。
我倾向于将这一部分视为项目任务跟踪器，因此每当范围估计发生变化时，我都会更新它 。但更像是个人喜好 。


推荐阅读


上一篇：止于至善，臻于完美 臻于完美

下一篇：高以翔最后一条微博 高以翔微博