执行同行评审时,针对评审人员的选择,以下哪些描述是正确的
发布网友
发布时间：2022-05-08 13:03
共2个回答
热心网友
时间：2023-12-29 17:39
1审核结果：
内部质量审核
外部质量审核（如顾客及第三方公证机构）
2顾客反馈
顾客满意测量
顾客投诉
顾客需求
3过程的业绩和产品符合性
过程测量的结果
过程的能力
产品内部测量的结果
产品、顾客或市场测量的结果
4预防和纠正措施的状况
提出的预防和纠正措施
预防和纠正措施的执行情况
5以往管理评审的跟踪措施
改进措施的有效性
提出的改进跟踪结果
完成情况
6经策划的可能影响质量体系的变更
由于任何原因（如：产品、顾客或市场变化）可能需变更的体系
变更可能会产生的影响
7改进的建议
已识别的可改进的方向
改进的目标及方法
热心网友
时间：2023-12-29 17:39
但是很多并不重视，或者效果不佳。
原因有很多：没有获得合适的专家、组织不合理、方法不当等。
针对代码评审，想简单地谈几点（其实其它工程文档的评审存在同样问题）：
1、评审要计划。
因为大家都很忙，各领域的专家也都有各自的工作，评审结果的好坏对工作绩效没有影响，所以专家投入多少精力来用于评审不受控，完全靠自己的职业精神。
所以，这就要求项目经理比较有影响力，能够争取到足够的、合适的专家来参与评审。
专家最好要提前协调，当然项目经理首先要知道要请哪些专家（如系统专家、领域专家、测试人员、QA等），这些专家在哪里。能否获得专家资源的支持，是项目经理的项目管理能力一个重要体现。
评审时间的投入比例，一般是第一次版本准备时间的3/5以上。
2、评审要分层次和重点。
作为项目成员，在代码编写完成后，首先是自检，这时发现的缺陷不计算；
然后是项目组内的评审，这时发现的缺陷应计算；
最后才是外部评审。
应提前把相关文档和代码交给评审专家，让各自评审；
根据项目和评审结果的情况，决定是否召开评审会议，评审会议以确认问题为主，而不是讨论解决方案。
对于重要的核心的代码，要投入重点评审力量；
另外，对于能力不足的成员所完成的代码，也要重点评审。
每个角色也应明白各自评审重点，如QA重点放在编程规范、测试人员侧重在可测性、系统专家侧重在从整体来考虑（如对其它功能的影响、性能等）。
3、问题的确认与跟踪。
评审专家发现问题后，首先与该代码的完*进行确认，如果大家达成一致认可这个问题，然后由代码完*提出解决方案，这个解决方案要得到问题发现者的同意，然后编程人员编码实现该方案，并进行测试和验证，并将验证结果提交问题发现人，问题发现人确认无误后，该问题就可关闭。
所以，评审专家发现问题后并没有结束，而是要负责跟踪该问题。
总之，评审活动的组织其实比较复杂，也是项目经理项目管理能力的一个重要体现，项目经理对评审活动负有重要责任。
