产品研发流程程序文件.docx
《产品研发流程程序文件.docx》由会员分享，可在线阅读，更多相关《产品研发流程程序文件.docx（52页珍藏版）》请在冰豆网上搜索。
产品研发流程程序文件
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.
2.
3.
公司年度产品打算
1.
2.
签发人：
时刻
合评审记录〔公司〕
评审对象〔项目名称及编号〕
评审项类〔如合同、投标方案等〕
评审人
时刻
业务板块（产品中心、项目中心、服务中心、营销中心）评审意见
财务部评审意见
质量操纵部评审意见
技术委员会评审意见
专家委员会评审意见
最终意见：
通过
修改
修改内容
时刻
立项报告评审记录
记录编号：
-时刻：
年月日
立项建议报告名称：
编制人：
参加人员：
评审内容（审议通过的内容在〝□〞中划〝√〞，否那么划〝×〞）：
1〕项目启动的背景；□
2〕项目的目的〔合同意向或内部领导的要求〕；□
3〕项目的范畴〔项目所涉及的要紧活动〕；□
4〕项目的可行性〔如，人力、技术资源的可利用性〕；□
5〕项目存在风险与操纵；□
6〕项目的重要里程碑和要紧提交产品；□
7〕项目的规模〔估量所需的工作量和资源种类〕；□
8〕项目启动的预算〔项目启动所需的资源〕；□
9〕项目市场前景及效益的简要分析。
□
评审意见：
评审结论:
填表
审批
1．本页不足记述评审意见时，能够加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页
可行性分析报告评审记录
记录编号：
-时刻：
年月日
可行性分析报告编号：
可行性分析报告名称：
编制部门：
编制人：
参加人员:
评审内容:
（评审中审议通过的内容在〝□〞中划〝√〞否那么划〝×〞）：
1）软件产品功能要点及产品化程度书□
2）量化的市场前景、效益分析和竞争对手分析□
3）开发优势□
4）技术路线□
5）成本估算□
6）进度估算□
7）可用的现行技术、重用软件和开发平台□
评审意见:
评审结论：
填表
审批
1．本页不足记述评审意见时，能够加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页
项目打算书
项目名称
项目编号
项目经理
项目任务描述
项目总时刻及关键里程碑设置
项目资源〔人力、技术、设备〕
项目费用估量
审批人意见：
总监：
副总监：
执委会：
备注：
抄送财务部、人力资源部
时刻
项目启动打算评审记录
记录编号：
时刻：
年月日
项目编号：
项目名称：
项目启动打算编号：
开发部门：
PM：
评审地点：
参加评审人员:
评审内容（评审中审议通过的内容在〝□〞中划〝√〞否那么划〝×〞）：
1）项目的目的是否明确？
□
2）对项目的规模是否进行估算？
□
3）是否进行项目启动的预算？
□
4）时期输出结果是否明确？
□
5）其它方面
评审意见：
评审结论：
填表：
审批：
1.项目启动打算评审由项目治理部门组织评审。
2.评审完成后由开发体系决策层SMG批准。
3.本页不足记述结果时，能够加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页
开发打算评审记录
记录编号：
时刻：
年月日
项目编号：
项目名称：
项目打算编号：
开发部门：
PSM：
评审地点：
参加评审人员:
评审内容：
评审意见：
评审结论：
填表：
审批：
1.开发打算评审由项目治理部门组织评审。
2.评审完成后由开发体系决策层SMG批准。
3.本页不足记述结果时，能够加入附页，附页格式自行设计，总页数包括本页与所有附页。
第页/共页
开发打算检查表〔开发打算评审附页〕
软件问题报告
记录编号：
-时刻：
年月日
项目编号：
项目名称：
软件项编号：
软件项名称：
版本号：
问题描述：
报告人签字/日期:
修改描述〔要紧是修改后与修改前的对比，如所用资源的变化、提交时刻的变化、功能的变化等〕：
修改人签字/日期：
填写：
审批：
1.问题描述栏中能够填写问题现象及其产生缘故，假如有用户的书面说明，那么能够直截了当引用。
2.修改描述一栏描述问题的确切缘故、修改方法以及修改后的成效。
3.本页不足记述时，能够有附页，格式自定。
总页数包括本页与所有附页。
项目资源调度单〔借鉴产品中心任务书〕
项目名称
项目编号
项目经理
项目的跨中心〔部门〕资源调度缘由及
申请人
审批人
正式调用时刻：
起：
止：
备注：
抄送财务、人力资源部
时刻
软件需求分析说明书
1.引言
1.1目的
说明编写软件需求说明书的目的，指出预期的读者。
1.2背景
（1）待开发的软件系统的名称；
（2）本项目的任务提出者、开发者、用户及实现该软件的运算中心或运算机网络；
（3）该软件系统同其他系统或其他机构的差不多的相互来往关系。
1.3参考资料
列出所用的参考资料，如：
（1）本项目的经核准的打算任务书或合同、上级机关的批文；
（2）属于本项目的其他已发表的文件；
（3）本文件中各处引用的文件、资料，包括所需用到的软件开发标准。
（4）列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。
1.4术语
列出本文件中用到的专门术语的定义和外文首字母组词的原词组。
2.项目概述
本部分描述阻碍产品和其需求的一样因素。
此处并不说明具体的需求，其描述的内容仅仅是为了更容易明白得、深化需求规格，其用意是为从多方面、多角度考虑需求以提供思维参考点。
2.1一样描述
本节描述软件开发项目的意图、应用目标、作用范畴以及其他应向读者说明的有关该软件开发的背景材料，说明待开发产品和其相关的其他产品或项目的关系。
●假如本产品是独立的，而且自含全部内容，应在此说明。
●假如所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容：
◆要概述那个较大的系统或项目的每一个组成部分的功能，并说明其接口；
◆指出本产品要紧的外部接口〔不需要详细描述，详细描述放在其他章节中〕；
◆描述所使用的运算机硬件、外围设备。
那个地点仅仅是一个综述性描述。
【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的要紧组成部分、相互联系和外部接口是专门有关心的。
【提醒注意】本节所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约束条件提供了一个能够说明的理由。
2.2功能简述
对待的软件产品功能提供一个摘要。
【技巧】
◆编制功能的一种方法是制作功能表，以便客户或第一次读那个文件的人专门容易明白得；
◆用方框图来表达不同的功能和它们的关系有益于明白得。
【提醒注意】
◆方框图不是产品的设计，而只是一种有效的说明方式。
◆本节不是具体需求的陈述，只是对具体需求部分中什么缘故要对一些需求做出描述的铺垫。
2.3用户特点
本节描述产品最终用户〔包括操作员、爱护员和系统工作人员等〕具有的受教育水平、工作体会及技术专长等一样特点。
假如系统的大多数用户是一些临时的用户，那么就要求系统包含如何完成差不多功能的提示，而不是假设用户差不多从过去的会议或从阅读用户指南中了解到这些细节。
2.4假定和约束
给出阻碍软件需求说明书中陈述的需求的每一个因素。
这些因素不是软件的设计约束，然而它们的改变可能阻碍到需求说明书中的需求。
这些假定和约束条件可能包括：
治理方针；运行环境，包括硬件设备和支持软件的限制；与其他应用间的接口；并行操作；实时功能；审查功能；操纵功能；所需的高级语言；通信协议；应用的临界点；安全保密方面的考虑等。
【提醒注意】
◆本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或操纵的改变时对产品需求将造成阻碍。
◆本节的内容不能用来陈述具体需求或强加假设干专门的设计约束，而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。
3.具体需求
本章应包括软件开发者在建立设计时需要的全部细节。
本章的编写应该遵循如下差不多原那么：
●遵循可验证性、无歧义性等的准那么，对每一个需求细节作具体描述；
●在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景；
●按符合逻辑的和可读的方式组织；
●详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。
【提醒注意】每一项需求的描述都应包括至少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）指明引用的输出接口资料。
【技巧】能够用列表的方式〔例如IPO表即输入、处理、输出表的形式〕，逐项定量和定性地表达对软件所提出的功能要求。
【提醒注意】对着重于输入输出行为的系统来说，需求说明书应指定所有有意义的输入、输出对及其序列。
当一个系统要求经历它的状态时，需要那个序列，使得它能够依照本次输入和往常的状态做出响应。
这种情形犹如有限状态机。
3.2性能需求
从整体来说，本节应具体说明软件、或人与软件交互的静态或动态数值需求。
静态数值需求可能包括：
支持的终端数，支持并行操作的用户数，处理的文卷和记录数，
表和文卷的大小等。
动态数值需求可能包括：
欲处理的事务和任务的数量，以及在正常情形下和峰值工作条件下一定时刻周期中处理的数据总量等。
所有这些需求都必须用能够度量的术语来表达。
例如：
95%的事务必须在小于1s时刻内处理完，不然，操作员将不等待处理的完成。
◆精度
说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。
◆时刻特性要求
说明关于该软件的时刻特性要求，如对响应时刻、更新处理时刻、数据的转换和传送时刻、解题时刻等的要求。
◆灵活性
说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：
操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、打算的变化或改进等。
关于为了提供这些灵活性而进行的专门设计的部分应该加以标明。
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数据需求
【提醒注意】
◆此部分内容一样在数据要求说明书中进行描述，假如项目软件产品规模较小，系统复杂程度较低，数据需求较简单，也可在此章中描述。
◆此部分内容也可能在功能需求中予以说明。
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.支持信息
支持信息指名目表、索引和附录。
●名目表和索引专门重要，而且应按照能够同意的文件规那么来编写。
●对一个实际的需求说明书来说，如有必要应该编写附录。
附录中可能包括：
（1）输入输出格式样本，成本分析研究的描述或用户调查结果；
（2）有助于明白得需求说明书的背景信息；
（3）软件所解决问题的描述；
（4）用户历史、背景、经历和操作特点；
（5）交叉访问表。
按先后次序进行编排，使一些不完全的软件需求得以完善；
（6）专门的装配指令用于编码和媒体，以满足安全、输出、初始装入或其他要求。
当包括附录时，需求说明书必须明确地说明附录是不是需求要考虑的部分。
分析说明书评审记录
记录编号：
-时刻：
年月日
项目编号：
项目名称：
项目软件经理PSM：
需求分析报告编制人：
参加评审人员：
评审内容：
（评审中审议通过的内容在〝□〞中划〝√〞，否那么划〝×〞）
1.无岐义性□
2.完整性□
3.可验证性□
4.一致性□
5.可使用性□
6.符合«需求分析报告编写规范»的要求□
评审意见：
风险评估总结：
评审结论：
（评审中审议通过的内容在〝□〞中划〝√〞，否那么划〝×〞）
1.通过评审，能够进入下一时期□
2.未通过评审，修改后重新评审□
填表：
审批：
1.本页不足记录结果时，能够有附页，附页格式自定。
总页数包括本页与所有附页。
第页/共页
评审规程
状态：
草稿
标识号：
评审
当前版本：
1.0
初始版
前一版本：
修订版
公布日期：
摘要
本文详细描述了软件工作产品的评审规程。
将要执行评审的所有项目的软件工作产品都必须遵循该评审规程。
修改历史
日期
版本
作者
修改内容
评审号
更换要求号
名目
1目的和范畴
本文档要紧描述了软件工作产品的评审过程，目的是能够及早和有效地发觉并排除软件工作产品的缺陷。
2评审角色
在评审时有四种角色：
作者、评审组长、记录员及其他人员。
这些角色在评审会上要承担不同的职责。
角色的划分必须遵循下面的原那么：
作者和评审组长是必须的角色，且不能为同一人
记录员能够是任何人员，也可由作者或评审组长兼任
其他人员在数量上没有限制，能够来自与项目相关的其它组织或部门
所有人员都必须具备相关的技术背景知识，对评审的软件工作产品有足够的了解，熟悉评审规程。
2.1作者
作者是指被评审的软件工作产品的作者，其要紧职责如下：
预备相关的评审资料
完成评审后的修改工作
2.2评审组长
评审组长必须为该软件工作产品所属领域的高级技术人员，其要紧职责如下：
指导作者组织并实施评审活动，对评审材料进行初审，确定参加评审的人员
按照评审规程主持评审会议
在评审会议上操纵评审进度，提醒参加者不要在某一问题上花费过多时刻
对评审中发觉的问题进行分析判定，确定处理方法，建议为两类：
1.问题项：
当场确定为问题，需要解决
2.调查项：
无法确定是否为要紧问题，需要进一步调查确认
决定评审结果〔通过和再评审〕
升级会员 