| |
分类导航 |
 |
|
|
|
|
|
|
资源大小：9.99 KB |
资源类型：文档 |
|
下载积分： 0 |
|
|
|
-->
|
|
资源介绍 |
|
关于功能详细设计的讨论
1令狐冲问：我感觉自己找不到太准确的衡量标准，我写到什么程度算深浅适中，我不知道如何下手，好像有些东西不在写代码之前想不出来，有现成的模板吗？
风清扬答：我们也想找个模板，可是网上的都是站着不腰疼，都是什么CMM，ISO9000
写个故事，比如你去客户那调查完了，你模拟一下客户的工作过程，然后写下来，不就成了？
不过可不要写成客户以后怎么使用你的软件的过程，比如按一个按钮然后….。写成流水帐也没关系，你看看你会有什么感觉。往往是正式做而真不知道该怎么做了，在自己闲暇时却偏偏做好了，你说怪不怪？
然后交给其他同事阅读，看他是否理解，把他的想法再填加到你的文档中，你的文档才会一点一点完善和趋于合理，罗马不是一天建成的，想集中一段时间搞一个完善的东西是不可能的，事物是迭代进步的。
把事情你觉得说清楚了，别人看了也觉得清楚了，并且可以按照你的思路复述一遍，这就可以了。
如果还是不太明确你想做的事，搭一个小程序，按你的现有描述实现一个简单的例子，在过程中想想有哪些你写的代码却没有描述，或者代码与你的描述两张皮，然后再试着修改文档。
如果还是不清楚，如果你做过代码维护工作，你想你在维护别人的代码的时候最需要看到什么，这样你就会知道你写些什么
在写文档时没必要我们想破脑子把所有的情况都想到都写下来，那不可能，我们大家都憎恨这种不现实的东西。设计时描述不清楚的就不要描述，咱们干吗非要固定不可能固定的东西呢？
但是有没有一种方法，什么是可以描述清楚的，什么是不可描述清楚的呢？
2令狐冲问：为什么要写呀，未来变化多端，你非要固定下来按这样去做，这是软件工程早就证明了的一种死办法，我们应该写了客户有什么问题，我们怎么解决的记录下来，具体怎么实现，就由程序员决定，开发完了再写详细设计文档，这样的文档才是真正的设计文档。
风清扬答：》开发文档就是把你的开发过程包括你的开发思想和各种问题的解决方法都记录下来，
这是我们的需求分析文档
》只是告诉要实现什么功能，
这是我们的功能概要描述呀
》程序员就记录在开发文档里面
这是我们的功能详细描述和数据流详细描述
》但以前我都是先写程序再写开发文档，程序没出来以前只有一份设计文档
先写程序再写开发文档，是为了以后人员的维护，来理解现在这个软件是怎么回事。我们的这个详细设计文档也就是说清楚每个功能的大致流程，流程中涉及到的一些异常业务，业务中的术语，让我们在编码前好知道我们做出来的这个东西大致是什么样，而不是我们就试着写吧，遇到问题再说。那样就不是商业的软件开发。商业的软件开发必须对进度，风险，成本有相当的预测。当然我们写完详细设计文档也不是什么问题都没了，我们也会在遇到问题时商讨，但至少我们对我们要干的事的轻重缓急有一个大致的预测。
我们写的也不是培训文档。培训文档是对照一个软件，有什么DBGRID，有什么下拉框，先点什么按钮。如果你的详细设计文档写成了这样，就出了问题。不是详细设计的大思路错了，就是你的功能概要设计划分的太细了
3令狐冲问：那我们该写些什么文档，我们可忙着呢，别费了好大劲，写出来也没人看，没人检查，格式也不知道，各有各的写法，最后不了了之。
风清扬答：我们不是为了文档漂亮，给客户看，给老板看，那样是出不来好产品的，我们的文档给我们是给我们在编码期自己看的，看你对业务的了解是否用文字可以描写清楚，如果能用文字描述清楚，你们写代码我们也就不担心了。
就是怕：我们不知道你们理解不理解，你们自己也不知道是不是理解了，于是大家就开始瞎做吧，做到哪算哪，好坏也不是我一个人的错。如果造成那样的后果，我们现在所做也就没有什么意义了
反正就是不要让我们在做每一个工程时都思考我该怎么写，以告戒其他同志正确的思考方向，不要重复思考别人思考过的问题；并且整理出一份你希望的详细功能描述文档的格式，以有个草案让我们逐步改进它使它合理
所以我们准备写这几个文档：
需求文档
模块进度文档 为了估计最后的出品日期和每个模块的工作量
功能概要文档 为了在编码期制定每周工作计划，编制每个功能的详细设计和数据流设计
表结构文档
|
|
|
下载地址 |
|
|
| |
|
|
