除此以外，还有很要紧的一点，在设计过程中间，常常有很多还没有解决的问题，在设计功能中间，并不是说什么东西解决了就可以开发了，产品已经在开发了，可是还有很多东西没有解决。某些技术性的问题，我等别的团队告诉我，或者有些技术性问题我等着调查，或者有些技术问题不知道，我买了硬件以后，做了平台以后做调试才知道，所谓这样都不能遗漏，为了防止这些问题都忘记，把这些问题也写到规范书里，有一个表格全部列到里面，有这样的方法就知道，整个开发过程中，让你可以随时回去看，这些没有解决的问题是不是已经被解决了，几月几号该被解决，哪些还要被调查，哪些还要被进一步决定。把没有解决的问题列出来，做个总结，谁对这个问题负责，比如某个技术调查问题是开发团队来做的，把这些该负责的人名字写在里面。目前他的状态到底有没有解决，有的已经解决或者是已经正在调查，在一个表里列出来，分成三档。有这样一个总结很明显的帮助你追踪没有解决的问题，在开发过程中状态是怎样的。如果项目过大的话，甚至可以把这个内容拿出来，专门再写一个额外的文件，一个专门的文档专门来总结这样的东西，给别的团队的人看，不见得一定在设计规范里，但是这些内容帮助你把该解决的问题记下来，帮助事后追踪管理这个过程。
怎么写？我们有这个提纲内容，真正写提纲一般是这样的，首先是你组织内容材料，写之前保证我该写的内容写在里面，就象每一节对照提纲，把你的各种想法写出来。刚开始是用倾斜的方式，不见得写的非常完善，但是保证该写的内容在里面，然后回去慢慢再改。很注意要明确你读者的类型，刚刚提到规范书是由设计工程师、测试工程师看的，文档编辑要看，他们对设计规范书有他们的期望，他们了解的内容，你在写的时候要保持在脑子里，写的时候一定要把这些不同读者的内容写进去。最后写你的内容，把内容尽量写的清晰、简短，用大量的图象描述你软件开发的思路，比你用千万的句子来写更好，有一幅画定千万字的说法。
增进版本的设计规范书，有时候我写一个规范书，并不是一个新的版本，我们公司已经有这个产品了，已经在市场上。我们现在这个公司正在做一个增订型的，做下一个版本，这个时候在以前已有的产品基础说我要做什么样的改变。要解决以前没有解决的问题，为什么现在开发，要解决以前没有解决的问题，我用什么样的设计，改变上一代的设计没有解决的问题。如果写崭新的产品就不会有这个问题，但是很多情况下我们的产品已经有了，我们只是要不停的增进，这种情况下要写这个内容。还有一点，设计界面的操作行为，不光是有一个图画，有一个键、数据栏、图象，还要很清楚的描述这个键我按了以后会发生什么情况，数字灌进去会发生什么情况，有时候用鼠标控制的，鼠标到底是左键按下去发生什么情况，右键按下去发生什么情况，这些都要列在里面。你盖一栋房子，描写的很清楚，用什么样的砖、瓦盖这个房子，用什么样的门窗、玻璃描写很清楚，盖出的房子一定是你所需要的，如果你画的是很大的很粗糙的草图，你盖的房子可能不是你所需要的。还有不要忘记一些基本的文章的结构不要忘记，包括标题、日记、版本数，还有页数，前面的目录、章节，不同的章节用什么标记表明的。别人读两三百页厚的设计版本会不会头脑发昏，怎么样让读者理解你的东西，都要写在里面。还有公司项目内部名称，如果公司项目很多的话，有时候项目有代号，代号太多可能读者搞不清楚，对项目内容做一个解释。很多情况下文档是内部使用，作为公司保密的，不能流传出去。你作为项目经理要写的很清楚，告诉团队成员，这个产品开发不能把这个文档公开给别人。在写一个完整的设计文档的时候，这些规范书里都要写在里面。
此文章共有8页 上一页 1 2 3 4 5 6 7 8 下一页
文章来源：互联网
 软件开发项目管理培训课程方案
|
Leadge.com首页 > 知识库 
