详细设计文档评审，应该从哪些方面入手？

[programmer_CMM]

如题。

[UNow2005]

每个细节都要通过评审，让项目组的成员都参加进来，评审前做好必要的准备工作，比如将设计文档提前发给评审成员，并要求提前1天给出反馈意见，准备好PPT和投影仪，做好评审时的记录，在会后将会议记录发给每个评审成员。

在评审过程中发现的问题尽量当时就解决，并取得一致的意见，别这个问题以后再说，哪个问题明天讨论。。。。那么评审就失去评审的意义了。

unow2005.tianyablog.com

[nongly]

发个评审指南

1. 概述
一次正式的会议。在会议上向用户、客户或其他相关各方介绍一个或一组工作产品，以征求对方的意见和批准。评审的最终目的是得到评审员的批准。
2. 流程图
2.1 主流程
评审会
准备评审－－－－》发现缺陷－－－》作出决定－－－》会议结束


2.2 准备评审

作者： 提出评审申请
小组负责人：计划评审、发评审通知
作者： 提交评审资料
协调员： 分发评审资料
评审员： 构思问题

2.3 发现缺陷
协调员：主持会议
读者： 阅读资料
评审员：提出问题、讨论问题、确定缺陷
记录员：记录缺陷

2.4 作出决定
评审员：作出评审决定、确定跟踪人或下次评审时间
记录员：记录评审决定

3. 详细说明
3.1 计划
作者要确定评审的重点和范围，编制待评审工作产品的检查点。针对项目所处的不同阶段，所关注的重点和范围可能不一样，检查点也就不同。
确定了评审范围之后，便可以确定评审者及担任的角色、议程和进行评审所需的信息。选择评审者时，应该在软件构架专业知识和领域专业知识之间建立平衡。一般情况下，评审者主要是本项目/本部门人员，评审者中要有该工作产品的使用者，如果有必要，请求其他项目/部门的人员做评审者。评审者必须是对待评审工作产品是否通过评审具有批准权的人员。
评审者的角色分：
协调员:协调员确保评审按议程进行，并以当前的主题为重点。协调员应该确保对枝节问题的讨论不会使评审脱离正轨，而且所有评审员都以平等的身份参加讨论。
评审员:评审员提出问题。一定要侧重于提出问题，而不要耗费大量精力讨论如何解决问题。注重结果，而不是方法。
读者:阅读待评审工作产品，这个角色通常可由作者承担。
作者:解释工作产品和理解工作产品所需的所有背景信息。
记录员:记录所讨论的内容和要采取的行动。
评审者的数目应该控制在三~七个人。如果评审员的数量太多，实际上会因为会议时间过长、参与更困难，以及在评审过程中增加了枝节问题和讨论，而降低评审的质量。如果评审者少于三个，则会因为减少了问题的多样性而增加片面性的风险。所有评审者都充当评审员角色。
评审员应该在要评审的领域拥有丰富经验；对于用例，评审员应该理解问题领域；对于软件构架，评审员还需要具备软件设计技术的知识。缺乏经验的评审员可以通过参与评审了解有关构架的内容，但他们对评审的帮助很小，同时他们的参与还可能会分散评审力量。
选择符合以下条件的评审员：
具有相当的背景来理解所介绍的材料。
所评审产品或工作产品的质量与之有利害关系。
协调者与作者确定评审会议的时间并通知评审者。在资料分发和评审会议之间应该有足够的时间让评审者做准备工作。
3.2 准备
评审之前，作者应该收集要评审的工作产品、检查点和所有背景材料，并分发给评审者。预先分发足够的评审材料，让评审者有时间准备评审，可以显著提高评审结果的质量。准备评审还会大大提高评审的效率和有效性。
评审者应该在评审之前研究文档、构思问题、确定要讨论的问题，并记录到《缺陷记录》。在评审员正常工作量的情况下，几个工作日通常是准备评审所需的最少时间。
评审者如果对检查点有疑义，应在评审前与作者沟通并解决。若作者修改了检查点，则要及时把修改后的检查点分发给评审者。
3.3 评审
3.3.1 理解评审流程
一般来说，评审流程是一个重复进行的循环过程：
评审员提出问题
讨论问题，同时对问题进行了确认
确定缺陷（确定需要解决的地方）
记录员记录问题
直到没有确定的问题时再继续下一步
如果大家在评审前已经仔细阅读了相关资料，则评审会议上可以不通篇阅读待评审工作产品，而是由评审者提出、读者有选择地阅读部分内容。
为了使这个过程有效进行，每个人都必须理解评审的目标是提高评审工作产品的质量。应该以发现问题的挑剔眼光来评审工作产品。这种做法可能很困难，所以所有评审员都必须经常提醒自己将重点放在确定问题上。我们都强烈地感觉到工作是属于自己的；通常，我们很难接受批评，甚至是建设性的批评。因为这样，我们必须更加努力地工作，以便将注意力集中在评审目标上：使工作产品的质量更好。
3.3.2 使评审保持简短
简短而侧重于明确目标的评审是最有效的。因为很难长期保持重点，而且评审员还有其他的工作要做，应该将评审时间限制在两小时之内。如果要进行时间较长的评审，可以将其拆分为几个规模较小、更有重点的评审。如果评审员能保持重点，就会获得更好的结果。
这种作法的关键是制定非常确定的议程和清楚明确的目标。分发评审材料后，应该向大家传达这些目标，而且评审会议开始时，协调员应该强调这些目标。之后，在会议进行期间，协调员还必须经常地（有时是强迫性的）强调这些目标。
3.3.3 确定问题，而不要解决问题
评审会议无法实现预期结果的一个主要原因是，会议很容易变成关于应该如何解决问题的讨论。解决问题通常需要调查和仔细思考；评审的形式对于这种讨论来说不是一个有效的方法。确定了问题之后，确定该缺陷是否必须得到解决，之后将调查和解决的任务分配给某个人。评审会议应该只注重确定问题。
如果问题需要一组人作进一步的讨论，就另外召开一次单独的会议重点讨论该主题。通常，这种会议需要一些调查和准备工作，而且需要一些具备适当工作技能的人员参加。评审应该将重点放在确定其他问题上。协调员经常需要施加相当大的影响，来确保评审会议侧重于这个方向。
3.3.4 作出决定
评审者讨论决定是否通过评审，决定有：通过，有条件通过，部分通过，不通过。对于有条件通过，要注明条件及跟踪人；对于部分通过，要说明通过的部分，决定未通过部分的下次评审时间；对于不通过，要决定下次评审时间。
3.4 对评审结果采取行动
如果不对评审结果采取行动，那么评审就没有什么价值。评审结束时：
确定问题列表的优先顺序。
创建缺陷，以追踪问题及其解决办法。
如果需要进行其他调查，将调查问题（而不是解决问题）的任务分配给一个小团队。
对于可以在当前迭代中解决的问题，指派一个人或一个团队解决该问题。
将未解决问题的列表留给未来的迭代计划工作。

[njspi]

给个连接，上面有类似的流程
http://www.softprocess.org
关于评审过程，楼上的讲的比较清楚了，楼主可以给分了:-)

[forture711]

我来简要说一下我们的评审过程吧
一、评审准备
主持人给涉及到的评审人员发送评审通知，通知内容包括被评审的文档，参考资料，评审检查表，评审预计时间和地点等内容。
二、个别审查
各个评审人员填写评审检查表，然后回复给主持人，主持人将各个检查表上的所有问题标注到被评审的文档上，根据评审准备情况确定具体的评审时间和地点并通知各位评审人员。
三、执行评审
评审会议上，主持人先介绍评审原则、责任、议程、时间等内容，然后作者介绍文档，这样开始正式评审，由主持人宣读文档，评审人员提问，作者解答并确认问题，记录员记录问题，会议最后给出评审结论。
四、问题跟踪
对评审发现的问题，跟踪人要对其进行跟踪。

[china_programmer]

好麻烦啊

[bigsir]

楼上几位都说的很详细了，我们可能作不到所有的步骤，向搂住提供些自己的看法

文档评审本身就具有限制：如果在评审过程中发现文档不能完全覆盖评审点，那么就需要作者参与
详细设计是面向实现的，不要把功能扩大化，如果有源头问题，回溯到上一个设计阶段来解决
评审点的制定：一般要涵盖是否符合架构，代码规范，接口定义，错误处理这几个大的方面，
如果你们的详细设计要求的更高，那么再加上关键代码评审这一块。

发现问题一般有两个方面：失误/错误，失误的处理要简单化，错误的处理要详细化。
一般评审时就要解决问题，但是实际上会有遗留或者超出范围的问题存在，那么这时候的问题交互（上溯，下溯）是关键。

解决问题的复核可以通过下一次评审会议或者单独检查实现。

说了几个自己的经验，还有一些不太好说，希望达人跟贴：
1。评审质量的控制
2。复查质量的控制
这两条是实际实施上最难控制的。