产品研发流程.docx

1、产品研发流程1 目的及适用范围1.1 为规范产品研发过程，提高产品研发的效率、质量，降低研发成本，特制定本程序；1.2 本程序文件适用于侏罗纪公司产品研发；1.3 本程序文件由侏罗纪公司 制定，其解释权及修改权属于 ；1.4 本程序文件从2003年 月 日起执行；2 职责2.1 产品部负责产品研发；2.2 质量控制部负责对产品开发过程中的里程碑产生的相关成果和文档进行质量控制，并将符合规范的成果放入资源中心存档；2.3 技术支持部和市场部负责宣传材料和用户手册的制作，以及和产品销售流程的衔接环节和动作；3 产品研发流程3.1 CEO从公司战略规划决案中形成产品规划，下发给产品中心；3.2 产品

2、中心（副）总监依据产品规划安排产品经理进行产品研发立项；3.3 执委会对产品立项进行评审，若评审未通过，相关文档放入资源管理部备案；3.4 若立项评审通过，质量控制部对立项进行质量检验，若质检未通过，产品经理修改立项报告；3.5 若质检通过，产品经理开始制订项目计划，同时质量控制部将立项相关文档放入资源管理部归档；3.6 产品经理将项目计划提交给产品（副）总监评审，若未通过，产品经理修改项目计划；3.7 若评审通过，质量控制部对项目计划进行评审，若质检评审未通过，产品经理修改项目计划，若质检评审通过，产品总监安排研发项目资源；3.8 产品经理获得研发项目资源后，进行需求分析，并将相关成果交技术

3、委员会进行内容评审；3.9 若内容评审未通过，产品经理修改需求分析；若内容评审通过，质量控制部对需求分析说明进行质量检验；3.10 若质检未通过，产品经理修改需求分析说明，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理带领研发相关人员进行总体设计；3.11 产品经理和研发人员完成总体设计后将相关成果交技术委员会进行内容评审；3.12 若内容评审未通过，产品经理修改总体设计说明；若内容评审通过，质量控制部对总体设计说明进行质量检验；3.13 若质检未通过，产品经理修改总体设计说明，若质检通过，相关成果和文档放入资源管理部归档，同时产品经理和研发人员进行程序设计/测试；3.14 完成程

4、序设计/测试后，产品经理将相关成果交质量控制部进行功能测试，若测试未通过，产品经理修改相关成果，若测试通过，质量控制部对相关成果和文档进行质量检验；3.15 若质检未通过，产品经理修改相关成果和文档；若质检通过，质量控制部将相关成果和文档放入资源管理部门归档；3.16 同时产品研发组制作软件，技术支持部和市场部制作宣传材料，之后，技术支持部对销售人员进行内部培训，市场部申请并取得著作权；3.17 市场部在取得著作权后制作用户/技术手册；3.18 产品研发组完成软件制作后，质量控制部对制作的软件进行质量检验，若未通过质检，产品研发组重新制作软件；若通过质检，相关成果和文档放入资源管理部归档，同时

5、产品经理进行产品研发总结；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.1

6、8 软件缺陷报告项目总结产品规划说明书公司三年产品规划1. 2. 3. 公司年度产品计划1. 2. 签发人：时间合评审记录（公司）评审对象（项目名称及编号）评审项类（如合同、投标方案等）评审人时间业务板块(产品中心、项目中心、服务中心、营销中心)评审意见财务部评审意见质量控制部评审意见技术委员会评审意见专家委员会评审意见最终意见：通过修改修改内容时间立项报告评审记录记录编号： - 时间： 年 月 日立项建议报告名称：编制人：参加人员：评审内容(审议通过的内容在“”中划“”，否则划“”)： 1）项目启动的背景； 2）项目的目的（合同意向或内部领导的要求）； 3）项目的范围（项目所涉及的主要活动）

7、； 4）项目的可行性（如，人力、技术资源的可利用性）； 5）项目存在风险与控制； 6）项目的重要里程碑和主要提交产品； 7）项目的规模（估计所需的工作量和资源种类）； 8）项目启动的预算（项目启动所需的资源）； 9）项目市场前景及效益的简要分析。 评审意见：评审结论:填表审批1 本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。第 页/共 页风险评估与控制（立项建议报告评审附页）立项建议报告名称：评估人/日期：评审部门序号风险描述风险发生可能性风险级别风险现值风险控制措施1目标不明确（如产品定位、市场前景描述不情晰）2时间紧（包括开发、测试、产品包装、产品销售等

8、）3源码、文档资料的控制4市场调研不充分，缺乏对市场上已经有的具有相似功能产品的了解5预算不合理6存在技术难点、采用新技术7缺乏对本公司的产品形态、技术路线、战略方针、发展趋势的全面了解8缺乏足够资源9分工明确、缺乏计划性10多部门配合111、 评估中风险不限于表中列出的，应依据评审的具体情况增加风险项。并将各项填写完整。2、 风险描述：描述当前过程中可能发生的风险。风险发生可能性：风险发生的概率，以百分数表示，其中10级为最高级。风险现值：风险发生可能性级别的乘积。风险控制措施：预防风险发生的措施可行性分析报告评审记录记录编号： - 时间： 年 月 日可行性分析报告编号：可行性分析报告名称：

9、编制部门：编制人：参加人员:评审内容:(评审中审议通过的内容在“”中划“”否则划“”)：1) 软件产品功能要点及产品化程度书 2) 量化的市场前景、效益分析和竞争对手分析 3) 开发优势 4) 技术路线 5) 成本估算 6) 进度估算 7) 可用的现行技术、重用软件和开发平台 评审意见:评审结论：填表审批1 本页不足记述评审意见时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。第 页/共 页风险评估与控制（可行性分析报告评审附页）立项建议报告名称：评估人/日期：评审部门序号风险描述风险发生可能性风险级别风险现值风险控制措施1市场调研不充分2市场预测不准确（如目标市场、产品定位等）3

10、编写人员缺乏足够的行业知识和专业知识4时间紧5多部门配合6技术可行性（如技术平参采用、接口的描述等）7缺乏足够的资源8投资预算不合理9缺乏对技术复用的分析10缺乏对本公司的产品形态、技术路线、战略方针、发展趋势的全面了解11缺乏对市场环境、竞争对手的了解1、 评估中风险不限于表中列出的，应依据评审的具体情况增加风险项。并将各项填写完整。2、 风险描述：描述当前过程中可能发生的风险。风险发生可能性：风险发生的概率，以百分数表示，其中10级为最高级。风险现值：风险发生可能性级别的乘积。风险控制措施：预防风险发生的措施项目计划书项目名称项目编号项目经理项目任务描述项目总时间及关键里程碑设置项目资源（

11、人力、技术、设备）项目费用预计审批人意见：总监： 副总监： 执委会：备注：抄送财务部、人力资源部时间项目启动计划评审记录记录编号： 时间： 年 月 日项目编号：项目名称：项目启动计划编号：开发部门：PM：评审地点：参加评审人员:评审内容(评审中审议通过的内容在“”中划“”否则划“”)：1) 项目的目的是否明确？ 2) 对项目的规模是否进行估算？ 3) 是否进行项目启动的预算？ 4) 阶段输出结果是否明确？ 5) 其它方面评审意见：评审结论：填表：审批：1. 项目启动计划评审由项目管理部门组织评审。2. 评审完成后由开发体系决策层SMG批准。3. 本页不足记述结果时，可以加入附页，附页格式自行设

12、计，总页数包括本页与所有附页。第 页/共 页开发计划评审记录记录编号： 时间： 年 月 日项目编号：项目名称：项目计划编号：开发部门：PSM：评审地点：参加评审人员:评审内容：评审意见：评审结论：填表：审批：1. 开发计划评审由项目管理部门组织评审。2. 评审完成后由开发体系决策层SMG批准。3. 本页不足记述结果时，可以加入附页，附页格式自行设计，总页数包括本页与所有附页。第 页/共 页开发计划检查表（开发计划评审附页）项目名称： 项目编号：检查项目检查内容检查结果得分一、质量目标1、是否符合质量体系的要求？2、如果不符合技量体系的要求，是否按要求编制质量计划？二、阶段划分1、是否明确划分各

13、阶段？2、各阶段的输入、输出标准是否明确？3、是否明确各阶段提交物？4、是否明确各阶段质量目标？5、是否明确提出各阶段检查点？三、产品清单1、是否明确提交给客户的产品清单（产品名称、提交时间、客户接受方式、责任人、验收标准）？2、是否明确提交给项目监按钮部门的产品清单（产品名称、提交时间、提交方式、责任人）？四、技术管理1、是否明确开发环境（软件、硬件环境）？2、是否明确开发工具？3、是否明确开发方法？4、是否采用新技术？5、是否考虑软件复用？五、组织结构1、是否确定项目小组成员，并将其划分成多个Team?2、是否明确各个小组成员的职责？六、风险管理1、是否预测了与项目有关的主要风险？2、是否

14、采取跟踪、监测措施以减小风险或避免风险的产生？七、相关性1、是否考虑了项目的外部相关活动？2、是否考虑了项目的内部相关活动？八、资源预算1、是否画了有关资源的直方图？2、是否预算了项目的工作量并划分给小组成员？九、配置管理1、是否制定了配置管理计划表？检查人/日期： 批准人/日期：风险评估与控制（开发计划评审附页）1、 评估中风险不限于表中列出的，应依据评审的具体情况增加风险项。并将各项填写完整。2、 风险描述：描述当前过程中可能发生的风险。风险发生可能性：风险发生的概率，以百分数表示，其中10级为最高级。风险现值：风险发生可能性级别的乘积。风险控制措施：预防风险发生的措施立项建议报告名称：评

15、估人/日期：评审部门序号风险描述风险发生可能性风险级别风险现值风险控制措施1客户需求不明确2客户需求不明确3开发人员缺乏足够的行业知识和专业知识4源码、文档的控制5工作阶段划分不明确、人员分工不合理6多部门配合7开发队伍不稳定或缺乏人力资源8预算超支9缺乏对技术复用的考虑10时间紧11存在技术难点、采用新技术12检查点设立不合理13缺乏对突发事件的考虑软件问题报告记录编号： - 时间： 年 月 日项目编号：项目名称：软件项编号：软件项名称：版本号：问题描述：报告人签字/日期:修改描述（主要是修改后与修改前的对比，如所用资源的变化、提交时间的变化、功能的变化等）：修改人签字/日期：填写：审批：1

16、. 问题描述栏中可以填写问题现象及其产生原因，如果有用户的书面说明，则可以直接引用。2. 修改描述一栏描述问题的确切原因、修改办法以及修改后的效果。3. 本页不足记述时，可以有附页，格式自定。总页数包括本页与所有附页。项目资源调度单（借鉴产品中心任务书）项目名称项目编号项目经理项目的跨中心（部门）资源调度缘由及申请人审批人正式调用时间：起：止：备注：抄送财务、人力资源部时间软件需求分析说明书1. 引言1.1 目的说明编写软件需求说明书的目的，指出预期的读者。1.2 背景（1） 待开发的软件系统的名称；（2） 本项目的任务提出者、开发者、用户及实现该软件的计算中心或计算机网络；（3） 该软件系统

17、同其他系统或其他机构的基本的相互来往关系。1.3 参考资料列出所用的参考资料，如：（1） 本项目的经核准的计划任务书或合同、上级机关的批文；（2） 属于本项目的其他已发表的文件；（3） 本文件中各处引用的文件、资料，包括所需用到的软件开发标准。（4） 列出这些文件资料的标题、文件编号、发表日期和出版单位，说明能够得到这些文件资料的来源。1.4 术语列出本文件中用到的专门术语的定义和外文首字母组词的原词组。2. 项目概述本部分描述影响产品和其需求的一般因素。此处并不说明具体的需求，其描述的内容仅仅是为了更容易理解、深化需求规格，其用意是为从多方面、多角度考虑需求以提供思维参考点。2.1 一般描述

18、本节描述软件开发项目的意图、应用目标、作用范围以及其他应向读者说明的有关该软件开发的背景材料，解释待开发产品和其相关的其他产品或项目的关系。 如果本产品是独立的，而且自含全部内容，应在此说明。 如果所定义的产品是一个较大系统或项目中的一个组成部分，那么在此需要描述如下内容： 要概述这个较大的系统或项目的每一个组成部分的功能，并说明其接口； 指出本产品主要的外部接口（不需要详细描述，详细描述放在其他章节中）； 描述所使用的计算机硬件、外围设备。这里仅仅是一个综述性描述。【技巧】在本节的描述中，用一个方框图来表达一个较大的系统或项目的主要组成部分、相互联系和外部接口是非常有帮助的。【提醒注意】本节

19、所描述的既不是设计方案，也不是在方案设计时的约束条件，它仅仅为方案设计时的约束条件提供了一个可以解释的理由。2.2 功能简述对待的软件产品功能提供一个摘要。【技巧】 编制功能的一种方法是制作功能表，以便客户或第一次读这个文件的人很容易理解； 用方框图来表达不同的功能和它们的关系有益于理解。【提醒注意】 方框图不是产品的设计，而只是一种有效的解释方式。 本节不是具体需求的陈述，只是对具体需求部分中为什么要对一些需求做出描述的铺垫。2.3 用户特点本节描述产品最终用户（包括操作员、维护员和系统工作人员等）具有的受教育水平、工作经验及技术专长等一般特点。如果系统的大多数用户是一些临时的用户，那么就要

20、求系统包含如何完成基本功能的提示，而不是假设用户已经从过去的会议或从阅读用户指南中了解到这些细节。2.4 假定和约束给出影响软件需求说明书中陈述的需求的每一个因素。这些因素不是软件的设计约束，但是它们的改变可能影响到需求说明书中的需求。这些假定和约束条件可能包括：管理方针；运行环境，包括硬件设备和支持软件的限制；与其他应用间的接口；并行操作；实时功能；审查功能；控制功能；所需的高级语言；通信协议；应用的临界点；安全保密方面的考虑等。【提醒注意】 本节中描述的因素是软件需求所依据的基石，当这些基石发生不可抗拒或控制的改变时对产品需求将造成影响。 本节的内容不能用来陈述具体需求或强加若干特殊的设计

21、约束，而应对具体需求部分中的某些具体需求或设计约束的描述提供理由。3. 具体需求本章应包括软件开发者在建立设计时需要的全部细节。本章的编写应该遵循如下基本原则： 遵循可验证性、无歧义性等的准则，对每一个需求细节作具体描述； 在软件需求说明书前言、项目概述、附录部分的有关讨论中，要提供对任何一个具体需求交叉引用的背景； 按符合逻辑的和可读的方式组织； 详细描述每一个需求，使得该需求应达到的目标能够用指定的方法进行客观的验证。【提醒注意】每一项需求的描述都应包括至少5个方面的内容：功能需求；性能需求；属性需求；外部接口需求；设计约束。3.1 功能需求用文字、图表或数学公式详细描述被开发软件的输入、

22、处理、输出以及在上述过程中发生的基本操作。对于每一类功能或者有时对于每一个功能，这部分通常由引言、输入、处理、输出四个部分组成：3.1.1 引言（1） 描述该功能要达到的目标、所采用的方法和技术；（2） 清楚说明功能意图的由来和背景。3.1.2 输入（1） 详细描述该功能的所有输入数据，如：输入源、数量、度量单位、时间设定、有效输入范围（包括精度和公差）。（2） 操作员具体的操作控制细节的需求。其中有名字、操作员活动的描述、控制台或操作员的位置。例如：当打印检查时，要求操作员进行格式调整。（3） 指明引用的输入接口资料。3.1.3 处理描述为获得预期输出结果，对输入数据及中间参数进行的全部操作

23、。它包括如下的说明：（1） 输入数据的有效性检查手段；（2） 操作的顺序和处理过程，包括事件的时间设定；（3） 异常情况的响应，例如：溢出、通信故障、错误处理等；（4） 受操作影响的参数；（5） 降级运行的要求；（6） 用于把系统输入变换成相应输出的任何方法（方程式、数学算法、逻辑操作等）。（7） 输出数据的有效性检查手段。3.1.4 输出（1） 详细描述该功能所有输出数据，例如：输出目的地、数量、度量单位、时间关系、有效输出的范围（包括精度和公差）、非法值的处理、出错信息；（2） 指明引用的输出接口资料。【技巧】可以用列表的方式（例如IPO表即输入、处理、输出表的形式），逐项定量和定性地叙述

24、对软件所提出的功能要求。【提醒注意】对着重于输入输出行为的系统来说，需求说明书应指定所有有意义的输入、输出对及其序列。当一个系统要求记忆它的状态时，需要这个序列，使得它可以根据本次输入和以前的状态做出响应。这种情况犹如有限状态机。3.2 性能需求从整体来说，本节应具体说明软件、或人与软件交互的静态或动态数值需求。静态数值需求可能包括：支持的终端数，支持并行操作的用户数，处理的文卷和记录数，表和文卷的大小等。动态数值需求可能包括：欲处理的事务和任务的数量，以及在正常情况下和峰值工作条件下一定时间周期中处理的数据总量等。所有这些需求都必须用可以度量的术语来叙述。例如：95%的事务必须在小于1s时间

25、内处理完，不然，操作员将不等待处理的完成。 精度说明对该软件的输入、输出数据精度的要求，可能包括传输过程中的精度。 时间特性要求说明对于该软件的时间特性要求，如对响应时间、更新处理时间、数据的转换和传送时间、解题时间等的要求。 灵活性说明对该软件的灵活性的要求，即当需求发生某些变化时，该软件对这些变化的适应能力，如：操作方式上的变化、运行环境的变化、同其他软件的接口的变化、精度和有效时限的变化、计划的变化或改进等。 对于为了提供这些灵活性而进行的专门设计的部分应该加以标明。3.3 软件属性需求在软件的需求之中有若干个属性，下面列举一部分。【提醒注意】下列属性决不能理解为是一个标准的或完整的清单

26、，而应根据项目实际情况予以列举。3.3.1 正确性3.3.2 健壮性3.3.3 安全保密性这里指的是保护软件的要素，以防止各种非法的访问、使用、修改、破坏或者泄密。这个领域的具体需求必须包括：利用可靠的密码技术，掌握特定的记录或历史数据集，给不同的模块分配不同的功能，限定一个程序中某些区域的通信，计算临界值的检查等。3.3.4 易使用性3.3.5 可理解性3.3.6 可维护性这里规定若干需求以确保软件是可维护的。例如：软件模块所需要的特殊的耦合矩阵，为微型装置指定特殊的数据/程序分割要求等。3.3.7 可测试性3.3.8 可移植性这里规定把软件从一种环境移植到另一种环境所要求的用户程序、用户接

27、口兼容方面的约束等。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 数据需求【提醒注意】