在困难项目中进行评审问题.
项目运行过程中,整个网络系统技术方案由系统组提供,软件组负责软件子系统技术方案,软件代码实现,软件测试.由于系统组缺乏经验,项目中决定引入评审.在评审过程中要求软件组参与.原因为软件组可尽早了解系统方案.有利于解决人力资源的问题.其立意是好的,不过在实现上效果很差.原因如下:
- 不同于同行评审,软件组并没有进行系统方案设计的培训,不具备系统方案同行评审的技术能力.所以,软件工程师评审系统方案,仅能分析系统方案中某些部分是否能软件实现.
- 分析系统方案能否软件实现还依赖,软件工程师对系统方案的了解和对软件产品本身的了解.但现实中,软件工程师未被给予足够的时间来准备技能,基本不能给予有效结果.
对这种评审的运行结果为,评审达不到效果,而在软件实现和测试过程中常常遇到与系统设计方案有关的困难.而系统则声称"已经请软件组评审过了,有问题为什么早不说." 项目进度则遭到挑战.进而,项目要求软件组解决问题.软件组则忙于解决问题就更没有时间进行下一阶段的技术方案评审工作.最后导致恶性循环.同时,在审查过程中,对于审查结果有一定记录例如,反馈意见表等等.但往往关键性技术问题没有发现.
教课书上的同行评审过程在现实项目运作中常常会遭遇资金,人员,项目进度,客户等各方面问题往往得不到有效实施.
所以,如果由于资金,人员,时间等问题,采用工作流上下一级对上一级工作进行审查时,如软件组审查系统技术方案.则为保证实行效果可考虑下列措施
- 审查结果应能反映出审查的有效性.例如在上例中,对系统方案的审查结果可以考虑在系统组方案通过审查之前,要求软件组提供根据系统方案所编写的软件子系统设计方案初稿.该子系统设计方案初稿可基本保证软件组理解了系统组方案并认真考虑了软件子系统设计方案.
- 审查者,如果为软件组.则应组织相关系统方案相关知识培训并保证其能有时间进行详细审查.
附,网上摘录的同行评审方法.
来自it168
目的:尽早、有效的从软件产品中清除错误。
内容:由软件开发者的同事对软件产品进行系统的检查,来发现错误和检查修改过的区域。
目标:
.对等审查需经过计划。
.软件工作产品中的错误需指明和清除。
承诺:
C1.项目要根据机构的政策来进行对等审查。
前提条件:
A1.提供充足的资源和资金对每个需要审核的软件工作产品进行对等审查。
A2.对等审查的领导需要接受如何进行对等审查方面的培训。
A3.参加对等审查的人员需要接受对等审查的目的、原则和方法的培训。
执行动作:
A1.对等审查要有计划,并且计划要文档化。
A2.对等审查要根据文档化程序来完成。
A3.对等审查的数据和结果都要记录下来。
度量分析:
M1.进行度量来判定对等审查活动的状态。
验证:
V1. 软件质量保证组要检查审核对等审查的活动和工作产品并报告结果