在软件Software开发过程中当某个模块详细设计文档(Detail Design)完成后软件Software开发人员会按照详设文档设计要求进行代码开发而软件Software测试人员会按照详设文档要求进行测试用例设计因此详细设计内容是否完善、有无重大缺陷；软件Software开发、测试人员是否正确深入了解了详细设计内容和设计思路都直接关系到该模块开发进度和产品质量
        那么怎样才能够完善模块详细设计并让开发、测试人员正确贯彻设计人员设计思路呢？针对详设级别同行评审可以有效地解决这个问题
        针对详设同行评审其主要目是检查和确认详细设计中缺陷以便在模块开发周期中早期阶段清除设计方面缺陷就缺陷修复成本而言在代码开发工作开始的前就清除设计方面缺陷其所付出成本是较低而且这个检查和确认过程对评审参和人员而言也有助于他们了解参评模块
        那么当我们确定对详细设计进行同行评审时其主要参和者都应该是哪些角色呢？
        试问在个软件Software项目团队(Team)中除了详计文档设计人员的外还有谁对详细设计质量拥有发言权呢？有人可能会说是详细设计Reviewer(检阅人员)诚然详细设计Reviewer往往是团队(Team)中比较有经验“牛人”级角色也有可能是详设人员直属Leader从技术角度上讲他们对于模块详细设计是有发言权能够对详细设计得框架进行把关但是由于角色、职责、精力等方面限定他们往往不会对其审查详设文档进行仔细分析、走查其审查往往只能做到走马观花式宏观把握而对于细节问题往往予以忽略
        在很多大型项目中模块划分数量很多要进行评审详设文档更如烟海要同行评审中如果能有Reviewer级别人物参加当然最好但是基于时间和效率方面考虑让Reviewer参加每次详设评审是很难做到他们往往只参加些重要级别模块详设同行评审
        其实对于份详细设计文档质量优劣感受最深往往是工作在详细设计层下游软件Software开发、测试人员他们工作直接依照详细设计进行详细设计文档质量直接影响到他们实际工作效率和产品质量他们在日常工作中对于详设文档往往是逐字逐句斟酌揣摩对于文档中些细节问题尤为敏感
        因此各模块开发、测试人员应该参和自己所负责模块详设评审并根据自己工作职责和需要对详细设计提出相应修改意见开发、测试人员加入不但可以使模块详细设计更加贴进于实际开发工作同时也可以让参和同行评审开发、测试人员明确是设计者意图确定自己要开发或要测试是什么样软件Software
        但是由于专业知识得限制些初级开发和测试人员往往难以对能够对详细设计中些复杂设计问题提出实质性改进意见因此如果条件允许还有必要邀请两位有经验专家参和评审
        除了保证详细设计质量外同行评审可以给设计、开发、测试人员提供个跨部门横向交流机会；同时也可以从“设计”、“开发”、“测试”等区别角度来对整个模块设计合理性提供意见；相关人员汇聚到起进行同行评审通过相互沟通较好了解模块相关背景知识避免了日后繁琐交流减少了“对项目设计思路理解不致而产生”可能性
        在实际操作中由开发和测试人员参和详细设计同行评审可以以“走读”为主；在技术实力较强情况下也可以进行“技术评审”所谓“走读”其主要是对文档进行检查通过走读发现文档中存在缺陷(可能包括逻辑矛盾、描述模糊和文法等)同时参和人员也可以进行技术交流初级人员也可以学习些技术方面知识了解设计者思路而“技术评审”是个相对正式评审过程其在规格、标准等方面进行评审并在评审后给出相应得修改意见
        理论上些模块构架级别东西应该在概要设计阶段就已经得到了解决我们在评审时不需要在框架问题上多花功夫但是在实际操作中些构架方面东西往往到编码后期还在不停修改因此在进行概要设计评审时设计者应该做好改变甚至推翻模块原有框架心理准备
        详细设计评审应该提前制定相应得计划并做好充分准备制定评审入口准则和相关规程确定评审时间安排相关组织者和和会人员准备所需材料等
        同行评审由专门组织者主持并有作者和相关同行出席其规模不宜过大大致可以控制在 7人以下在会议过程中可以先由作者对其详细设计进行讲解引导大家进行走读然后参和者们共同对详细设计进行评审确认问题并对其进行分类
        般情况下同行评审可以被控制在两个小时的内些简单模块可以把同行评审压缩到个小时的内在评审过程中如果遇到问题需要延时可以由作者决定是否召开“第 3小时会议”
        评审结束后有必要对评审问题进行跟踪以便确认确陷到了修改并且没有引入新缺陷