51Testing软件测试论坛

标题: 评审流程 [打印本页]

作者: lemonhy 时间: 2006-10-17 11:24
标题: 评审流程
各位XDJM，请问你们以前有没有整理过这样的文档啊？《评审流程》
主要是要把需求评审、概要设计评审、详细设计评审、软件验证与确认评审、管理评审的评审内容及评审方法等都写出来。
非常急，希望各位XDJM能多提宝贵意见！如果手头上有资料的，也可以发给我一份！邮箱：cdhy0625@163.com。
谢谢！

作者: lemonhy 时间: 2006-10-18 12:08
XDJM们都没有做过吗？

作者: gracedl 时间: 2006-10-18 15:09
sdlkfj9 我也急需，有的也给我一份吧，grace_dl@126.com

作者: xin313 时间: 2006-10-26 15:01
能否也发一份给我,xin313@163.com,谢谢

作者: yangkinki 时间: 2006-10-26 16:51
可能不是你想要的，但可能会有点帮助
9条建议
　　建议一：分层次评审
　　
　　我们知道用户的需求是可以分层次的，一般而言可以分成如下的层次：
　　
　　目标性需求：定义了整个系统需要达到的目标；
　　
　　功能性需求：定义了整个系统必须完成的任务；
　　
　　操作性需求：定义了完成每个任务的具体的人机交互；
　　
　　目标性需求是企业的高层管理人员所关注的，功能性需求是企业的中层管理人员所关注的，操作性需求是企业的具体操作人员所关注的。对不同层次的需求，其描述形式是有区别的，参与评审的人员也是不同的。如果让具体的操作人员去评审目标性需求，可能会很容易地导致“捡了芝麻，丢了西瓜”的现象，如果让高层的管理人员也去评审那些操作性需求，无疑是一种资源的浪费或者就会出现案例三的情形。
　　
　　建议二：正式评审与非正式评审结合
　　
　　正式评审是指通过开评审会的形式，组织多个专家，将需求涉及到的人员集合在一起，并定义好参与评审人员的角色和职责，对需求进行正规的会议评审。而非正式的评审并没有这种严格的组织形式，一般也不需要将人员集合在一起评审，而是通过电子邮件、文件汇签甚至是网络聊天等多种形式对需求进行评审。两种形式各有利弊，但往往非正式的评审比正式的评审效率更高，更容易发现问题。因此在评审时，应该更灵活地利用这两种方式。
　　
　　建议三：分阶段评审
　　
　　应该在需求形成的过程中进行分阶段的评审，而不是在需求最终形成后再进行评审。分阶段评审可以将原本需要进行的大规模评审拆分成各个小规模的评审，降低了需求返工的风险，提高了评审的质量。比如可以在形成目标性需求后进行一次评审，在形成系统的初次概要需求后进行一次评审，当对概要需求细分成几个部分，对每个部分进行各个评审，最终再对整体的需求进行评审。
　　
　　建议四：精心挑选评审员
　　
　　需求评审可能涉及的人员包括：需方的高层管理人员、中层管理人员、具体操作人员、IT主管、采购主管；供方的市场人员、需求分析人员、设计人员、测试人员、质量保证人员、实施人员、项目经理以及第三方的领域专家等等。在这些人员中由于大家所处的立场不同，对同一个问题的看法是不相同的，有些观点是和系统的目标有关系的，有些是关系不大的，不同的观点可能形成互补的关系。为了保证评审的质量和效率，需要精心挑选评审员。首先要保证使不同类型的人员的都要参与进来，否则很可能会漏掉了很重要的需求。其次在不同类型的人员中要选择那些真正和系统相关的，对系统有足够了解的人员参与进来，否则很可能使评审的效率降低或者最终不切实际的修改了系统的范围。
　　
　　建议五：对评审员进行培训
　　
　　在很多情况下，评审员是领域专家而不是进行评审活动的专家，他们没有掌握进行评审的方法、技巧、过程等，因此需要对评审员进行培训，同样对于主持评审的管理者也需要进行培训，以便于参与评审的人员能够紧紧围绕评审的目标来进行，能够控制评审活动的节奏，提高评审效率，避免发生案例一和案例二中出现的现象。对评审员的培训也可以区分为简单培训与详细培训两种。简单培训可能需要十几分钟或者几十分钟，需要将在评审过程中的需要把握的基本原则，需要注意的常见问题说清楚。详细培训则可能要需要对评审的方法、技巧、过程进行正式的培训，需要花费较长的时间，是一个独立的活动。需要注意的是被评审人员也要被培训。
　　
　　建议六：充分利用需求评审检查单
　　
　　需求检查单是很好的评审工具，需求检查单可以分成两类：需求形式的检查单和需求内容的检查单。需求形式的检查可以由QA人员负责，主要是针对需求文挡的格式是否符合质量标准来提出的，需求内容的检查是由评审员负责的，主要是检查需求内容是否达到了系统目标、是否有遗漏、是否有错误等等，这是需求评审的重点。检查单可以帮助评审员系统全面地发现需求中的问题，检查单也是随着工程财富的积累逐渐丰富和优化的。
　　
　　建议七：建立标准的评审流程
　　
　　对正规的需求评审会需要建立正规的需求评审流程，按照流程中定义的活动进行规范的评审过程。比如在评审流程定义中可能规定评审的进入条件、评审需要提交的资料、每次评审会议的人员职责分配、评审的具体步骤、评审通过的条件等等。通过评审流程执行可能会避免出现案例五之类的问题。
　　
　　建议八：做好评审后的跟踪工作
　　
　　在需求评审后，需要根据评审人员提出的问题进行评价，以确定哪些问题是必须纠正的，哪些可以不纠正，并给出充分的客观的理由与证据。当确定需要纠正的问题后，要形成书面的需求变更的申请，进入需求变更的管理流程，并确保变更的执行，在变更完成后，要进行复审。切忌评审完毕后，没有对问题进行跟踪，而无法保证评审结果的落实，使前期的评审努力付之东流。
　　
　　建议九：充分准备评审
　　
　　评审质量的好坏很大程度上取决于在评审会议前的准备活动。常出现的问题是，需求文档在评审会议前并没有提前下发给参与评审会议的人员，没有留出更多更充分的时间让参与评审的人员阅读需求文档。更有甚者，没有执行需求评审的进入条件，在评审文档中存在大量的低级的错误或者没有在评审前进行沟通，文档中存在方向性的错误，从而导致评审的效率很低，质量很差。对评审的准备工作，也应当定义一个检查单，在评审之前对照检查单落实每项准备工作。
　　

作者: cai2121 时间: 2006-10-27 11:55
楼上说的很有道理，学习一下

但是还有些疑问,
我也觉着分阶段评审很有必要,但如果项目不大,需求阶段时间也不长,那么有必要多次评审吗,还是视具体情况而定呢

QA人员是只负责形式上的检查阿

请问斑竹有没有需求评审检查单的样例可以参照一下呢

作者: lemonhy 时间: 2006-11-1 12:15
标题: 回复 #5 yangkinki 的帖子
yangkinki (kinki)

虽然已经看过这篇文章，但还是要谢谢版主！
贴出来大家讨论一番也很好。

作者: kingamy 时间: 2006-11-1 17:20
1、制定评审计划
2、评审分正式技术评审和非正式技术评审
3、正式技术评审过程
（1）准备评审
   评审主持人确定评审会议的时间、地点、设备和人员名单
   发评审会议通知
   准备检查表
   发相关材料给评审员
   评审员实现阅读材料
（2）举行评审会议
   主持人宣讲
   作者介绍工作成果
   识别缺陷和答辩
   会议结束决议
（3）修正、跟踪与审核
   修正与跟踪：修正工作成果，消除已识别的缺陷；评审主持人（或指定审查员）跟踪缺陷状态
   提交审核
   审核工作成果
4、非正式技术评审一般是由作者/项目经理发起的评审，过程略

作者: 高山来客 时间: 2007-1-30 16:29
标题: 有道理！
有道理！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)