产品研发流程程序文件.doc

1 目得及适用范围
1.1 为规范产品研发过程，提高产品研发得效率、质量，降低研发成本,特制定本程序；
1.2 本程序文件适用于侏罗纪公司产品研发;
1.3 本程序文件由侏罗纪公司 制定,其解释权及修改权属于 　 ；
1.4 本程序文件从2003年　 月 　 日起执行；
2 职责
2.1 产品部负责产品研发;
2.2 质量控制部负责对产品开发过程中得里程碑产生得相关成果与文档进行质量控制,并将符合规范得成果放入资源中心存档；
2.3 技术支持部与市场部负责宣传材料与用户手册得制作，以及与产品销售流程得衔接环节与动作；
3 产品研发流程
3.1 技术副总从公司战略规划决案中形成产品规划，下发给技术研发部;
3.2 技术研发部经理进行产品研发立项;
3.3 公司组织人员对产品立项进行评审，若评审未通过,相关文档放入行政综合部备案;
3.4 若立项评审通过，质量保证部对立项进行质量检验,若质检未通过,修改立项报告;
3.5 若质检通过，开始制订项目计划,同时质量保证部将立项相关文档放入行政综合部归档;
3.6 技术部经理将项目计划提交给技术副总评审,若未通过,技术部经理修改项目计划；
3.7 若评审通过，质量控制部对项目计划进行评审,若质检评审未通过，产品经理修改项目计划,若质检评审通过,产品总监安排研发项目资源；
3.8 产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术委员会进行内容评审;
3.9 若内容评审未通过,产品经理修改需求分析;若内容评审通过,质量控制部对《需求分析说明》进行质量检验;
3.10 若质检未通过,产品经理修改《需求分析说明》,若质检通过，相关成果与文档放入资源管理部归档,同时产品经理带领研发相关人员进行总体设计;
3.11 产品经理与研发人员完成总体设计后将相关成果交技术委员会进行内容评审；
3.12 若内容评审未通过,产品经理修改《总体设计说明》;若内容评审通过,质量控制部对《总体设计说明》进行质量检验;
3.13 若质检未通过，产品经理修改《总体设计说明》，若质检通过，相关成果与文档放入资源管理部归档，同时产品经理与研发人员进行程序设计/测试;
3.14 完成程序设计/测试后,产品经理将相关成果交质量控制部进行功能测试,若测试未通过，产品经理修改相关成果，若测试通过,质量控制部对相关成果与文档进行质量检验；
3.15 若质检未通过，产品经理修改相关成果与文档；若质检通过,质量控制部将相关成果与文档放入资源管理部门归档;
3.16 同时产品研发组制作软件,技术支持部与市场部制作宣传材料,之后，技术支持部对销售人员进行内部培训,市场部申请并取得著作权;
3.17 市场部在取得著作权后制作用户／技术手册;
3.18 产品研发组完成软件制作后，质量控制部对制作得软件进行质量检验,若未通过质检，产品研发组重新制作软件;若通过质检，相关成果与文档放入资源管理部归档，同时产品经理进行产品研发总结;
3.19 质量控制部将产品研发总结等相关成果与文档放入资源管理部,同时市场部进行软件产品包装,销售部进行产品销售；
4 相关文件
4.1 《产品规划说明书》
4.2 《立项报告》
4.3 《综合评审记录》
4.4 《质量控制立项报告与可行性分析报告说明书》
4.5 《项目计划书》
4.6 《质量控制项目计划评审记录》
4.7 《资源调度单》
4.8 《需求分析说明书》
4.9 《质量控制需求分析说明书评审报告》
4.10 《资源中心验收单》
4.11 《评审规程》
4.12 《总体设计说明书》
4.13 《概要设计说明书》
4.14 《详细设计说明书》
4.15 《质量控制系统设计报告评审记录》
4.16 著作权相关文档(略）
4.17 《软件质量保证单》
4.18 《软件缺陷报告》
4.19 《项目总结》
产品规划说明书
公司三年产品规划
1. 　 　
公司年度产品计划
1. 　
签发人:
时间

合评审记录(公司）
评审对象（项目名称及编号)
评审项类(如合同、投标方案等)
评审人
时间
业务板块(产品中心、项目中心、服务中心、营销中心)评审意见

财务部评审意见
质量控制部评审意见
技术委员会评审意见
专家委员会评审意见
最终意见:
通过
修改
修改内容
时间

立项报告评审记录
记录编号: 　 　　　 — 　 　　 　　 　 　 　 　 　 　　时间： 　　 年 月 日
立项建议报告名称:
编制人:
参加人员:
评审内容(审议通过得内容在“□”中划“√”,否则划“×”): 　 　
1)项目启动得背景；　 　 　　 　 　 　 　 □
２）项目得目得(合同意向或内部领导得要求); 　 　 　 □
3)项目得范围(项目所涉及得主要活动);　 　 　 　 　 　 　　□
4)项目得可行性(如,人力、技术资源得可利用性）;　 　 　□
5)项目存在风险与控制； 　 　　 　　 　　　 　 　 □
6)项目得重要里程碑与主要提交产品； 　　　　 　　 　 　　 　 □
７）项目得规模(估计所需得工作量与资源种类);　 　　　 　 　 □
8)项目启动得预算(项目启动所需得资源)；　 　　 　 　　　□
9)项目市场前景及效益得简要分析。 　 　　　 　 　 □
评审意见:
评审结论:
填表
审批

1． 本页不足记述评审意见时，可以加入附页,附页格式自行设计，总页数包括本页与所有附页。
第 　 页/共 　页

可行性分析报告评审记录
记录编号:　 　 　　 - 　 　　 　 　　 　　 　 　　 　时间: 　　 年　 月 日
可行性分析报告编号:
可行性分析报告名称：
编制部门:
编制人:
参加人员:
评审内容:（评审中审议通过得内容在“□”中划“√”否则划“×")：
1) 软件产品功能要点及产品化程度书 　 　　 　　 　　 　 □
2) 量化得市场前景、效益分析与竞争对手分析 　 　 　 □
3) 开发优势 　 　 　 　 　 　　 　 　　 　　 □
4) 技术路线　 　 　 　 　 　 　 □
5) 成本估算 　 　 　 　 　 　 　 □
6) 进度估算 　　 　 　 　 　 　　 　 　 　 　 　 　□
7) 可用得现行技术、重用软件与开发平台 　　 　 □
评审意见:
评审结论:
填表
审批

1． 本页不足记述评审意见时，可以加入附页,附页格式自行设计,总页数包括本页与所有附页.
第 　页／共　 页

项目计划书
项目名称
项目编号
项目经理
项目任务描述
项目总时间及关键里程碑设置
项目资源（人力、技术、设备)
项目费用预计
审批人意见:
总监: 　　 　 　 　 　　 副总监: 　　 　 　 　 　 执委会:
备注：抄送财务部、人力资源部
时间

项目启动计划评审记录
记录编号： 　 　 　 　 　 　 　 　 　 　 时间： 　年　 月 日
项目编号：
项目名称:
项目启动计划编号:
开发部门:
PM:
评审地点：
参加评审人员:
评审内容（评审中审议通过得内容在“□"中划“√”否则划“×”）:
1) 项目得目得就是否明确? 　 　 　 　 　 　 　 　 　□
2) 对项目得规模就是否进行估算？　 　 　 　 　 　 　 　 　 　 □
3) 就是否进行项目启动得预算? 　　 　 　 　 　　 　 　 □
4) 阶段输出结果就是否明确? 　 　 　 　　 □
5) 其它方面
评审意见：
评审结论:

填表:
审批:
1. 项目启动计划评审由项目管理部门组织评审。
2. 评审完成后由开发体系决策层SMG批准。
3. 本页不足记述结果时，可以加入附页,附页格式自行设计,总页数包括本页与所有附页。
第 　 页／共　 页
开发计划评审记录
记录编号: 　 　　 　 　 　　 　 　 　 　 　 　 　 时间: 年 月　 日
项目编号：
项目名称：
项目计划编号:
开发部门：
PSM：
评审地点:
参加评审人员：

评审内容：
评审意见:
评审结论:

填表:
审批:
1. 开发计划评审由项目管理部门组织评审.
2. 评审完成后由开发体系决策层SＭG批准。
3. 本页不足记述结果时,可以加入附页,附页格式自行设计,总页数包括本页与所有附页。
第 　 页/共 　 页
开发计划检查表（开发计划评审附页）

软件问题报告
记录编号：　—　　 　 　 　 　 ﻩﻩ ﻩ　 时间： 年 　 月 　 日
项目编号：
项目名称：
软件项编号:
软件项名称:
版本号:
问题描述:
报告人签字/日期：
修改描述(主要就是修改后与修改前得对比,如所用资源得变化、提交时间得变化、功能得变化等）:
修改人签字/日期:
填写:
审批:
１、ﻩ问题描述栏中可以填写问题现象及其产生原因，如果有用户得书面说明，则可以直接引用。
２、 修改描述一栏描述问题得确切原因、修改办法以及修改后得效果。
3、 本页不足记述时,可以有附页,格式自定。总页数包括本页与所有附页。
项目资源调度单(借鉴产品中心任务书）
项目名称
项目编号
项目经理
项目得跨中心（部门）资源调度缘由及
申请人
审批人
正式调用时间:
起：
止:
备注:抄送财务、人力资源部
时间

软件需求分析说明书
1. 引言
1.1 目得
说明编写软件需求说明书得目得,指出预期得读者。
1.2 背景
（1） 待开发得软件系统得名称；
（2） 本项目得任务提出者、开发者、用户及实现该软件得计算中心或计算机网络;
（3） 该软件系统同其她系统或其她机构得基本得相互来往关系。
1.3 　参考资料
列出所用得参考资料，如:
（1） 本项目得经核准得计划任务书或合同、上级机关得批文;
（2） 属于本项目得其她已发表得文件;
（3） 本文件中各处引用得文件、资料，包括所需用到得软件开发标准。
（4） 列出这些文件资料得标题、文件编号、发表日期与出版单位，说明能够得到这些文件资料得来源。
1.4 术语
列出本文件中用到得专门术语得定义与外文首字母组词得原词组。
2. 项目概述
本部分描述影响产品与其需求得一般因素。此处并不说明具体得需求，其描述得内容仅仅就是为了更容易理解、深化需求规格，其用意就是为从多方面、多角度考虑需求以提供思维参考点。
2.1 一般描述
本节描述软件开发项目得意图、应用目标、作用范围以及其她应向读者说明得有关该软件开发得背景材料，解释待开发产品与其相关得其她产品或项目得关系．
l 如果本产品就是独立得，而且自含全部内容,应在此说明.
l 如果所定义得产品就是一个较大系统或项目中得一个组成部分,那么在此需要描述如下内容：
u 要概述这个较大得系统或项目得每一个组成部分得功能,并说明其接口;
u 指出本产品主要得外部接口(不需要详细描述,详细描述放在其她章节中);
u 描述所使用得计算机硬件、外围设备。这里仅仅就是一个综述性描述。
【技巧】在本节得描述中，用一个方框图来表达一个较大得系统或项目得主要组成部分、相互联系与外部接口就是非常有帮助得。
【提醒注意】本节所描述得既不就是设计方案，也不就是在方案设计时得约束条件,它仅仅为方案设计时得约束条件提供了一个可以解释得理由。
2.2 功能简述
对待得软件产品功能提供一个摘要。
【技巧】
u 编制功能得一种方法就是制作功能表,以便客户或第一次读这个文件得人很容易理解；
u 用方框图来表达不同得功能与它们得关系有益于理解。
【提醒注意】
u 方框图不就是产品得设计，而只就是一种有效得解释方式。
u 本节不就是具体需求得陈述,只就是对具体需求部分中为什么要对一些需求做出描述得铺垫。
2.3 用户特点
本节描述产品最终用户(包括操作员、维护员与系统工作人员等）具有得受教育水平、工作经验及技术专长等一般特点。
如果系统得大多数用户就是一些临时得用户，那么就要求系统包含如何完成基本功能得提示,而不就是假设用户已经从过去得会议或从阅读用户指南中了解到这些细节。
2.4 假定与约束
给出影响软件需求说明书中陈述得需求得每一个因素。这些因素不就是软件得设计约束,但就是它们得改变可能影响到需求说明书中得需求。
这些假定与约束条件可能包括：管理方针;运行环境,包括硬件设备与支持软件得限制;与其她应用间得接口;并行操作;实时功能;审查功能；控制功能；所需得高级语言;通信协议；应用得临界点；安全保密方面得考虑等。
【提醒注意】
u 本节中描述得因素就是软件需求所依据得基石，当这些基石发生不可抗拒或控制得改变时对产品需求将造成影响。
u 本节得内容不能用来陈述具体需求或强加若干特殊得设计约束,而应对具体需求部分中得某些具体需求或设计约束得描述提供理由。
3. 具体需求
本章应包括软件开发者在建立设计时需要得全部细节.
本章得编写应该遵循如下基本原则：
l 遵循可验证性、无歧义性等得准则,对每一个需求细节作具体描述;
l 在软件需求说明书前言、项目概述、附录部分得有关讨论中，要提供对任何一个具体需求交叉引用得背景；
l 按符合逻辑得与可读得方式组织;
l 详细描述每一个需求,使得该需求应达到得目标能够用指定得方法进行客观得验证.
【提醒注意】每一项需求得描述都应包括至少5个方面得内容:功能需求；性能需求;属性需求;外部接口需求；设计约束。
3.1 功能需求
用文字、图表或数学公式详细描述被开发软件得输入、处理、输出以及在上述过程中发生得基本操作.对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成:
3.1.1 引言
（1） 描述该功能要达到得目标、所采用得方法与技术;
（2） 清楚说明功能意图得由来与背景。
3.1.2 输入
（1） 详细描述该功能得所有输入数据,如:输入源、数量、度量单位、时间设定、有效输入范围(包括精度与公差).
（2） 操作员具体得操作控制细节得需求。其中有名字、操作员活动得描述、控制台或操作员得位置。例如:当打印检查时，要求操作员进行格式调整。
（3） 指明引用得输入接口资料。
3.1.3 处理
描述为获得预期输出结果,对输入数据及中间参数进行得全部操作。它包括如下得说明:
（1） 输入数据得有效性检查手段；
（2） 操作得顺序与处理过程，包括事件得时间设定;
（3） 异常情况得响应，例如：溢出、通信故障、错误处理等；
（4） 受操作影响得参数;
（5） 降级运行得要求；
（6） 用于把系统输入变换成相应输出得任何方法（方程式、数学算法、逻辑操作等)．
（7） 输出数据得有效性检查手段。
3.1.4 输出
（1） 详细描述该功能所有输出数据,例如：输出目得地、数量、度量单位、时间关系、有效输出得范围(包括精度与公差)、非法值得处理、出错信息；
（2） 指明引用得输出接口资料。
【技巧】可以用列表得方式(例如IＰＯ表即输入、处理、输出表得形式),逐项定量与定性地叙述对软件所提出得功能要求。
【提醒注意】对着重于输入输出行为得系统来说,需求说明书应指定所有有意义得输入、输出对及其序列.当一个系统要求记忆它得状态时，需要这个序列，使得它可以根据本次输入与以前得状态做出响应。这种情况犹如有限状态机．
3.2 性能需求
从整体来说,本节应具体说明软件、或人与软件交互得静态或动态数值需求。
静态数值需求可能包括:支持得终端数,支持并行操作得用户数,处理得文卷与记录数，
表与文卷得大小等。
动态数值需求可能包括:欲处理得事务与任务得数量，以及在正常情况下与峰值工作条件下一定时间周期中处理得数据总量等.
所有这些需求都必须用可以度量得术语来叙述.例如:95％得事务必须在小于1ｓ时间内处理完，不然,操作员将不等待处理得完成．
u 精度
说明对该软件得输入、输出数据精度得要求，可能包括传输过程中得精度。 
u 时间特性要求
说明对于该软件得时间特性要求,如对响应时间、更新处理时间、数据得转换与传送时间、解题时间等得要求。 
u 灵活性
说明对该软件得灵活性得要求,即当需求发生某些变化时，该软件对这些变化得适应能力,如：操作方式上得变化、运行环境得变化、同其她软件得接口得变化、精度与有效时限得变化、计划得变化或改进等. ﻫ 对于为了提供这些灵活性而进行得专门设计得部分应该加以标明.
3.3 软件属性需求
在软件得需求之中有若干个属性,下面列举一部分。
【提醒注意】下列属性决不能理解为就是一个标准得或完整得清单,而应根据项目实际情况予以列举.
3.3.1 正确性
3.3.2 健壮性
3.3.3 安全保密性
这里指得就是保护软件得要素,以防止各种非法得访问、使用、修改、破坏或者泄密。这个领域得具体需求必须包括：利用可靠得密码技术,掌握特定得记录或历史数据集，给不同得模块分配不同得功能，限定一个程序中某些区域得通信，计算临界值得检查等。
3.3.4 易使用性
3.3.5 可理解性
3.3.6 可维护性
这里规定若干需求以确保软件就是可维护得。例如：软件模块所需要得特殊得耦合矩阵,为微型装置指定特殊得数据／程序分割要求等。
3.3.7 可测试性
3.3.8 可移植性
这里规定把软件从一种环境移植到另一种环境所要求得用户程序、用户接口兼容方面得约束等。
3.4 外部接口需求
3.4.1 用户接口
（1） 提供用户使用软件产品时得界面需求。例如，如果系统得用户通过显示终端进行操作,就必须指定如下要求:对屏幕格式得要求，报表或菜单得页面显示格式与内容,用户命令得格式,输入输出得相对时间，程序功能键得可用性。
（2） 列出输出错误信息得格式。
3.4.2 硬件接口
（1） 指出软件产品与系统硬部件之间每一个接口得逻辑特点。
（2） 指出硬件接口支持得设备.
（3） 描述软件与硬件接口之间以及硬件接口与支持设备之间得约定。
3.4.3 软件接口
描述项目待开发软件产品与其它有关软件得接口关系,并指出这些软件得以下内容:名字、助记符、规格说明号、版本号、来源．
【提醒注意】对于每一个接口，应说明与软件产品相关得接口软件得目得,并根据信息得内容与格式定义接口，这里不必详细描述任何已有完整文件得接口,只要引用定义该接口得文件即可。
3.4.4 通讯接口
说明各种通信接口及协议,例如局部网络得协议等。
3.5 设计约束
3.5.1 其它标准得约束
描述由现有得标准或规则派生得要求。例如:报表格式、数据命名、财务处理、审计追踪等等。
3.5.2 硬件设备得约束
描述在各种硬件约束下运行而产生得软件要求，可能得约束有硬件配置得特点（接口数、指令系统等),内存储器与辅助存储器得容量等。
3.6 数据需求
【提醒注意】
u 此部分内容一般在数据要求说明书中进行描述，如果项目软件产品规模较小，系统复杂程度较低,数据需求较简单,也可在此章中描述。
u 此部分内容也可能在功能需求中予以说明。
3.6.1 数据描述
（1） 列出作为控制与引用而使用得静态数据元素
（2） 列出动态输入数据元素
（3） 列出动态输出数据元素
（4） 列出软件内部生成得数据元素
3.6.2 数据获取
（1） 列出提供输入数据得机构
（2） 列出数据输入介质与设备
（3） 列出数据输出介质与设备
3.7 其它专门需求
根据软件与用户组织得特性等,某些需求在这里描述,下面列举一部分。
【提醒注意】下列需求项决不能理解为就是一个标准得或完整得清单,而应根据项目实际情况予以列举。
3.6.1 数据库
本项对作为项目产品得一部分进行开发得数据库规定一些需求,它们可能包括:
（1） 在功能需求中标识得信息类别；
（2） 使用得频率
（3） 存取能力;
（4） 数据元素与文卷描述符;
（5） 数据元素、记录与文卷得关系;
（6） 静态与动态得组织;
（7） 数据保存要求。
【提醒注意】如果使用一个现有得数据库包,这个数据库包应在“软件接口”中命名,并在那里详细说明.
3.6.2 数据管理能力
说明需要管理得文卷与记录得个数、表与文卷得大小规模,要按可预见得增长对数据及其分量得存储要求做出估算。
3.6.3 操作
这里说明用户组织之中各种方式得操作.例如:
（1） 用户初操作；
（2） 交互作用操作得周期与无人操作周期；
（3） 数据处理支持功能;
（4） 后援与恢复操作。
【提醒注意】这里得内容有时就是“用户接口"得一部分。
3.6.4 故障处理
4. 运行环境规定
4.1 设备
列出运行该软件所需要得硬设备。说明其中得新型设备及其专门功能,包括:
（1） 处理器型号及内存容量;
（2） 外存容量、联机或脱机、媒体及其存储格式，设备得型号及数量;
（3） 输入及输出设备得型号与数量,联机或脱机；　
（4） 数据通信设备得型号与数量；
（5） 功能键及其她专用硬件。
4.2 支持软件
列出支持软件,包括要用到得操作系统、编译（或汇编)程序、测试支持软件等。
4.3 接口
说明该软件同其它软硬件之间得接口、数据通信协议等.
4.4 控制
说明控制该软件得运行得方法与控制信号，并说明这些控制信号得来源。
【提醒注意】本章中得内容有时在前面得章节中已说明。
5. 支持信息
支持信息指目录表、索引与附录。
l 目录表与索引很重要，而且应按照可以接受得文件规则来编写。
l 对一个实际得需求说明书来说,如有必要应该编写附录.附录中可能包括:
(1) 输入输出格式样本，成本分析研究得描述或用户调查结果;
(2) 有助于理解需求说明书得背景信息；
(3) 软件所解决问题得描述；
(4) 用户历史、背景、经历与操作特点;
(5) 交叉访问表。按先后次序进行编排,使一些不完全得软件需求得以完善；
(6) 特殊得装配指令用于编码与媒体，以满足安全、输出、初始装入或其她要求。
当包括附录时,需求说明书必须明确地说明附录就是不就是需求要考虑得部分。
分析说明书评审记录 　
　 记录编号: 　 　 　 　 　— ﻩﻩﻩ ﻩ 　 ﻩ ﻩﻩ 时间:　 年　　 月 日
项目编号:
项目名称:
项目软件经理ＰSM：
需求分析报告编制人:
参加评审人员:
评审内容：(评审中审议通过得内容在“□”中划“√”，否则划“×”)
１、ﻩ无岐义性 　　 　　 　 　 　　 　　 　 　 　 　　 □
2、ﻩ完整性　 　 　　 　 　 　 　 　 　 　 　 　　 　□
3、 可验证性　 　 　 　 　 　 　 　 　　 　 　 　 　□
4、ﻩ一致性 　 　 　 　 　 　　　 　 　 　 　　 　 　 　 　 　 　　 　 □
5、ﻩ可使用性 　 　 　 　 　 　 　　 □
６、ﻩ符合《需求分析报告编写规范》得要求　 　 　　　 　 　 　 　□
评审意见:
风险评估总结：
评审结论：（评审中审议通过得内容在“□”中划“√”,否则划“×”)
1、 通过评审,可以进入下一阶段 　 　 　 　 　□
2、　未通过评审,修改后重新评审 　　 　　 　 □

填表:
审批:
1. 本页不足记录结果时,可以有附页,附页格式自定。总页数包括本页与所有附页.
第 　　 页／共　　 页

评审规程
状态：
草稿
标识号:

评审
当前版本:
1、０

初始版
前一版本:

修订版
发布日期:

摘要
本文详细描述了软件工作产品得评审规程。将要执行评审得所有项目得软件工作产品都必须遵循该评审规程。
修改历史
日期
版本
作者
修改内容
评审号
更改请求号

ﻬ目录
1 目得与范围 28
2　评审角色ﻩ28
2、1　作者ﻩ28
２、２　评审组长 28
2、３ 记录员 28
2、４ 其她参与人员ﻩ29
3 评审过程ﻩ29
3、1 计划阶段 29
3、1、1 进入条件ﻩ２9
3、1、２ 目得 29
3、1、3　活动ﻩ29
3、2 准备阶段ﻩ２9
3、2、1　进入条件 3０
３、2、２ 目得ﻩ３0
3、2、３ 活动 ３0
3、3　执行阶段ﻩ30
3、3、1 进入条件ﻩ３0
3、3、2 目得ﻩ30
3、3、３ 活动 30
3、４ 整理阶段 3１
３、4、１　进入条件ﻩ31
3、4、2 目得 31
3、４、3 活动ﻩ3１
4 附录A 评审活动检查表ﻩ3２
5　附录B 评审记录表ﻩ33
6　附录C 评审通知 35
1　目得与范围
本文档主要描述了软件工作产品得评审过程,目得就是能够及早与有效地发现并排除软件工作产品得缺陷。
2 评审角色
在评审时有四种角色:作者、评审组长、记录员及其她人员。这些角色在评审会上要承担不同得职责。角色得划分必须遵循下面得原则：
作者与评审组长就是必须得角色,且不能为同一人
记录员可以就是任何人员,也可由作者或评审组长兼任
其她人员在数量上没有限制,可以来自与项目相关得其它组织或部门
所有人员都必须具备相关得技术背景知识,对评审得软件工作产品有足够得了解，熟悉评审规程。
2、1 作者
作者就是指被评审得软件工作产品得作者,其主要职责如下：
准备相关得评审资料
完成评审后得修改工作
２、２ 评审组长
评审组长必须为该软件工作产品所属领域得高级技术人员，其主要职责如下:
指导作者组织并实施评审活动，对评审材料进行初审,确定参加评审得人员
按照评审规程主持评审会议
在评审会议上控制评审进度，提醒参加者不要在某一问题上花费过多时间
对评审中发现得问题进行分析判断,确定处理办法,建议为两类:
1. 问题项:当场确定为问题,需要解决
2. 调查项:无法确定就是否为主要问题,需要进一步调查确认
决定评审结果(通过与再评审）
2、3 记录员
记录员在评审会议中记录发现得问题及相关得数据，其主要职责如下:
填写评审记录表
作为评审员参与评审
2、4 其她参与人员
其她人员评审软件工作产品,回答问题、参与讨论同时帮助解决问题。所有得参与人员都必须严格遵循评审规程。
３ 评审过程
评审过程分为四个阶段,每一阶段都包含一定得任务描述,可以参考《评审活动检查表》执行评审。
《评审活动检查表》就是帮助评审人员正确执行评审得工具，它与本章所描述得各阶段得具体活动就是一致得。
评审过程得四个阶段为：计划、准备、执行与整理。 每一阶段必须顺序地执行,才能保证评审成功。 下面将详细描述这四个步骤.
3、1 计划阶段
这就是评审得第一阶段,其每一步都有详细说明,只有计划阶段得任务完成后才能进入准备阶段。
３、1、１ 进入条件
软件工作产品满足规范要求
软件工作产品经过拼写检查
3、1、２ 目得
确保作者提供正确得评审材料
确保软件工作产品满足评审要求
确定评审员并明确其职责
3、1、３ 活动
作者准备评审所需得材料，包含被评审得软件工作产品、支持材料及评审表格等
技术委员会指定评审组长
评审组长检查进入标准就是否满足
技术委员会确定参评人员。也可由技术委员会委托评审组长确定需要参加评审得人员
评审组长确认作者准备好所需要得材料
评审组长与作者共同确定评审会议日程
3、2 准备阶段
3、2、1 进入条件
评审材料已准备好
参加者对被评审得软件工作产品具备必要得背景知识
评审组长确认评审材料符合要求
３、２、２ 目得
评审员明确自己得职责
所有评审员在评审之前得到评审材料
确保评审员在评审之前阅读评审材料,找出问题
３、２、3 活动
作者发评审会议通知给所有评审员
作者将评审材料分发给所有评审员
评审组长标识软件工作产品得范围，强调重点，提取问题
评审组长熟悉议程，确保评审进度
评审员仔细阅读评审材料,在评审材料上做评注,找出问题
所有评审员记录自己准备所花费得时间
3、3 执行阶段
执行评审必须召开评审会议,所有评审员进行面对面地讨论就是必要得。
３、3、1　进入条件
所有评审员得到评审材料
所有评审员根据自己得角色要求准备并且评审软件工作产品
所有评审员记录自己得准备时间。本次评审得准备时间就是所有评审员得准备时间之与
会议室与其它资源已经准备就绪
作者准备就绪，重要参加人员能够出席评审会议
３、3、2 目得
找出、记录与分析所有问题
３、3、３ 活动
评审组长检查所有评审员就是否已经做好评审得准备工作
记录员记录评审员得准备时间，开始评审
作者为软件工作产品逐项进行概要介绍
记录员在评审会议上记录发现得问题
所有评审员把重点放在讨论与提出问题上
评审员使用自己注释得评审材料对有问题得地方提出讨论
作者与评审员协助评审组长描述与分析问题,
发现一个问题后,评审组长确保该问题被正确记录
所有评审员提出对评审会议得改进建议,记录员在评审表上记录要点
评审组长确保评审完成
评审组长在评审组得协助下决定评审结果。如果没有问题或发现得问题类型与数量容易改正与处理，其结果为“通过”，否则为“再评审”
如果需要“再评审",可以只评审需要评审得部分。评审组长记录需要再被评审得部分
3、4 整理阶段
3、４、1 进入条件
问题已被记录在评审表中
３、4、2 目得
修正评审中发现得所有问题
确保所有需要进行调查得项目已经被分析，并且被排除
评审数据被记录
３、4、3 活动
评审组长估计并跟踪修改问题所需时间
对于问题项，作者确保有问题记录
对于调查项，经研究后,如果就是问题项,作者负责解决并记录在评审表中
作者修正所有问题项
评审组长协调所有评审员检查作者已修改过得内容。如果没有问题,则评审结果定为“通过”，否则,评审组长应提出解决方案
所有评审员确认后，在评审表上签字
如果使用评审工具代替评审记录表，则作者在评审工具中生成一个新得评审记录表，填入相应内容并提交
４ 附录A　评审活动检查表
阶段
作者
评审组长
其她评审员
计划
¨
¨ 接受评审组长角色并确定评审目标

¨ 准备评审材料
¨ 检查评审进入条件就是否满足

¨ 同评审组长一起选择评审员
¨ 确定需要参加评审得人员
¨ 接受评审员角色
¨ 与评审组长共同

准备
¨ 确保评审材料准备好
¨ 核实进入条件
¨ 理解自己得职责
¨ 给所有评审员发评审会议通知
¨ 学习并且评注软件工作产品
¨ 学习并且评注软件工作产品
¨ 将被评审材料分发给所有评审员
¨ 熟悉评审议程
¨ 记录个人得准备时间
¨ 确保会议室与其它资源准备就绪
¨ 记录个人得准备时间

执行
¨ 介绍评审会议日程
¨ 控制评审进度
¨ 按时出席，提供准备时间
¨ 逐项概要介绍软件工作产品
¨ 分析问题
¨ 记录员记录所有评审员姓名及准备时间

¨ 决定评审结果
¨ 参加讨论并提出问题

¨ 记录员记录问题

¨ 所有评审员提出对评审会议得改进建议，记录员在评审表上记录要点
整理
¨ 改正评审所发现得问题
¨ 估计并跟踪需要修改问题所需时间

¨ 如果有评审工具,则生成一个新得评审记录表，填入相应内容并提交
¨ 检查修改内容得正确性
¨ 阅读并确认评审记录表内容得正确性
¨ 提交文档
¨ 签字
¨ 签字
注：首先由技术委员会指定评审组长。
ﻬ5 附录B　评审记录表
评审会日期:____＿_＿_＿____＿_＿_ 开始时间:＿_＿___＿__________　结束时间：___＿__________＿_＿
评审会地点：_______＿__＿＿_____＿___＿___＿______＿＿_____＿___＿____＿__＿___＿＿__第_____次评审
评审主题：_______＿___________＿＿＿_＿＿__＿____＿___＿__＿＿___＿______＿___＿______＿__＿__＿_____
　 　 　 ＿_＿_＿___＿___＿＿_＿__＿_______＿________＿___＿＿____＿__________＿＿___＿___＿__＿_＿___
软件工作产品名称:＿__＿___＿＿＿_____＿__＿_______＿_＿___软件工作产品大小:＿＿＿______SLＯＣ／页
软件工作产品标识号：＿__＿__＿___＿___＿＿＿_____＿___＿_版本号：＿______　作者：_____＿_________
评审员及准备时间:
角色
姓名
准备时间(小时）
评审组长

作者

记录员

评审员

总与

问题记录:
序号
位置
描述
类型
状态

问题项
调查项
未解决
已解决

问题项
调查项
未解决
已解决
修改软件工作产品工作量(小时）:____＿__＿_＿___＿＿____
评审结果:ﻩ□ 通过 ﻩ□ 再评审
改进建议:_＿＿_______＿__________＿＿_____＿_＿_________＿_______＿__＿_＿______＿______＿______
　 　 ＿＿＿＿_＿______＿_____________＿＿___＿_＿____＿__＿____＿＿______＿__＿__＿_＿__________＿
　 ____＿＿_________＿______＿_＿___＿____＿＿___＿___＿_＿____＿___＿____＿_＿_____＿________
_＿____