软件开发规范.docx

软件开发规范.docx

《软件开发规范.docx》由会员分享，可在线阅读，更多相关《软件开发规范.docx（10页珍藏版）》请在冰豆网上搜索。

软件开发规范

软件开发过程规范

1目的

为了规范软件研发各个阶段的开发行为，特制定此规范。

2适用范围

本规范适用于研发中心软件产品研发从立项，到开发实施、测试、结项的各个阶段，规定了各开发阶段的文档编制、代码编写和资料备份内容与要求。

3术语和缩写

研发项目干系人：

公司内部与研发项目有关联的任何人。

项目计划周期：

从项目立项到计划完成时间的实际工作日数。

项目实际周期：

从项目立项到实际完成时间的实际工作日数。

项目质量目标：

项目允许出现的总的缺陷数的加权平均值。

项目实际质量：

项目实际出现的总的缺陷数的加权平均值。

软件缺陷：

在测试过程中被发现的软件bug，按照不同的严重程度分为四级；

一级，系统崩溃，无法自动恢复，加权系数为100。

二级，系统功能无法实现或性能指标无法达到，但不影响其他功能的使用，加权系数为2。

三级，系统功能实现不完整，加权系数为1。

四级，不影响系统功能和性能的小错误，忽略此错误系统可正常运行，加权系数为0.5。

加权缺陷数量：

测试中出现的各种缺陷的数量乘以其对应的加权系数，求和。

4内容和要求

4.1研发立项

4.1.1立项申请，产品研发经过申请后才能立项，立项申请人可以是公司员工，也可以是公司各职能部门。

4.1.2立项申请人或委托其部门负责人召集相关人员讨论通过，确定项目经理并初步确定项目组成员。

4.1.2.1《研发立项申请书》由项目经理负责编制。

4.1.2.2项目编号规则为，软件项目：

PS+编制日期；（硬件项目：

PH+编制日期）。

如：

PS20070902。

4.1.2.3《研发立项申请书》要规定开发的产品的具体名称，以及所属各个系列的规格型号定义。

4.1.2.4《研发立项申请书》规定开发的产品的属性，包括功能详细描述，性能要求详细描述和稳定性要求详细描述。

4.1.2.5《研发立项申请书》明确项目经理和项目组成员。

4.1.2.6《研发立项申请书》明确项目的开始日期和计划完成日期。

4.1.2.7《研发立项申请书》概要说明项目开发的资源需求，包括硬件设备、软件工具、场地环境等。

4.1.2.8《研发立项申请书》确定项目的质量目标，包括各级缺陷的数量和测试周期，所制定的质量目标不允许有一级缺陷。

4.1.2.9《研发立项申请书》的编制格式参照《研发立项申请书模板》。

4.1.3《研发立项申请书》由研发项目经理、主管软件的研发经理、营销中心经理认可，主管研发副总经理最终确认。

4.1.4内容变更：

研发项目干系人可对申请对《研发立项申请书》的内容进行变更，变更后按申请的流程进行签字确认，变更后的内容重新填写《研发立项申请书》并附在原申请书后。

项目组成员的变更由研发内部掌握，不必进行变更申请。

变更可在结项前的任何阶段提出。

4.1.5项目撤销，如遇重大变故造成所研发的项目已经无实际意义或其他原因需要立即停止，可申请撤销，申请人需是项目干系人，并具有中心经理以上的级别，申请人负责编写《研发项目撤销申请书》,说明撤销原因，撤销申请需得到项目经理、主管软件的研发经理、营销中心经理和主管研发副中经理认可，经由总经理批准后生效。

撤销申请可在结项前的任何阶段提出。

4.2研发

4.2.1研发立项确定后，项目经理需编写《项目研发计划书》。

4.2.1.1《项目研发计划书》初步制定项目开发的任务列表和模块划分，以及项目组人员的模块归属和工作时间安排。

4.2.1.2《项目研发计划书》可以用通用的项目管理工具来完成，编制格式由项目经理确定，推荐使用MicrosoftProject。

4.2.1.3《项目研发计划书》由项目组成员认可。

4.2.1.5项目经理可根据实际情况和设计的深入，随时变更《项目研发计划书》。

4.2.1.6主管软件的研发经理可抽查《项目研发计划书》的编制和实施情况，并给出改进建议。

4.2.2研发设计

4.2.2.1《软件需求分析说明书》

4.2.2.1.1软件项目需编制《软件需求分析说明书》。

4.2.2.1.2《软件需求分析说明书》由项目经理或其委托人编制。

4.2.2.1.3《软件需求分析说明书》确定整个系统的物理结构和部署要求，并根据系统的物理结构进行模块划分，确定各个模块的功能范围和模块间的接口方式。

详细说明系统规模要求和运行环境限制，并指出系统运行所需资源的要求。

明确开发和系统运行所需软硬件资源的要求。

确定项目进行一次全面测试所需要的测试人员人数和测试周期。

《软件项目需求分析说明书》的格式参照《软件项目需求分析说明书模板》。

在软件需求分析过程中，如果软件有用户界面，要在此阶段进行界面的初步设计，为了提高效率，界面草图的绘制不限定形式和格式。

4.2.2.1.4《软件需求分析说明书》由项目组全体成员认可，主管软件的研发经理最终确认。

4.2.2.1.5《软件需求分析说明书》的变更，在开发过程中，项目组成员可提出对《软件需求分析说明书》的变更申请，变更的范围限于不能违背《研发立项申请书》的要求，即不能有涉及到《研发立项申请书》变更的内容，如果有，需要做《研发立项申请书》变更的流程。

《软件需求分析说明书》变更的主要目的是修正其中的错误，或者经过变更可提高产品的品质或性能指标或缩短产品的研发周期。

《软件需求分析说明书》的变更需得到项目经理的同意，必要时由项目经理召集相关技术人员和项目组成员召开简短的技术会议进行论证。

项目经理将变更后的内容形成新版本的《软件项目需求分析说明书》，由主管软件的研发经理最终确认。

4.2.2.2《软件概要设计说明书》

4.2.2.2.1软件项目需编制《软件概要设计说明书》。

4.2.2.2.2《软件概要设计说明书》由项目经理或其委托人编制。

4.2.2.2.3《软件概要设计说明书》确定整个系统的逻辑结构，并对需求分析中各物理模块进行逻辑模块划分，详细描述各逻辑模块的业务规则和模块之间的接口以及重要的内部接口，确定系统级的全局变量和数据结构，确定各逻辑模块所包含的程序文件名称和使用的开发工具，描述每个文件中所包含的函数功能。

确定数据库的类型和所有数据表名称及数据表的用途，确定数据库的访问方式。

详细描述系统的配置方式。

如果软件有用户界面，要对界面进行详细设计，确定所有界面的名称、规格及界面上的元素类型及功能，界面设计可在开发工具中直接绘制，也可采用其他绘图方式，但在概要设计文档中要保留图示并进行详细说明。

格式参照《软件项目概要设计说明书模板》。

4.2.2.2.4《软件概要设计说明书》由项目组全体成员认可，主管软件的研发经理最终确认。

4.2.2.2.5《软件概要设计说明书》的变更，在开发过程中，项目组成员可提出对《软件概要设计说明书》的变更申请，变更范围限于不得违背《研发立项申请书》和《软件需求分析说明书》的要求，所涉及的变更不至于影响到《研发立项申请书》和《软件需求分析说明书》的变更，如果有，需要做《研发立项申请书》的变更流程或者《软件需求分析说明书》的变更流程。

《软件概要设计说明书》变更的主要目的是修正其中的错误，或者经过变更可提高产品的品质或性能指标或缩短产品的研发周期。

概要设计说明书的变更需得到项目经理的同意，必要是由项目经理召集相关技术人员和项目组成员召开简短的技术会议进行论证。

项目经理将变更后的内容写入新版本的《软件项目概要设计说明书》，主管软件的研发经理最终签字确认。

4.2.2.3软件详细设计

4.2.2.3.1软件详细设计由项目经理指派，项目组成员分担完成。

4.2.2.3.2软件项目详细设计的内容及格式要求，软件项目的详细设计根据《软件概要设计说明书》划分的各个逻辑模块包含的程序文件，确定每个程序文件中所包含的函数的详细描述，要求有函数的功能描述、输入输出说明、使用规则和限制，如有必要，还可以描述函数的实现流程。

详细描述软件中所有全局变量的格式、初始值、用途和使用规则。

详细描述软件中所有的数据结构和类结构。

详细描述数据库中的数据表，确定数据表的的每个字段，以及数据表之间的关系，确定所有的视图、触发器和存储过程。

详细设计文档不做具体的格式要求，为了提高研发效率，可以把详细设计作为代码的一部分，直接在程序中编写，编写时要遵循《研发中心软件编码标准》的规定。

4.2.2.3.3项目经理负责组织对详细设计进行审核，审核方式可采用项目经理主审和项目成员互审相结合的方式，主要审核详细设计和概要设计及需求分析的符合性，及详细设计的正确性。

主管软件的研发经理可组织相关技术人员对详细设计情况进行抽查。

4.2.2.3.4详细设计的变更，可在项目开发的任何时段进行，由项目成员在得到项目经理的口头同意后进行，要在变更处做好变更记录。

4.2.2.4质量控制

4.2.2.4.1项目组内部互审，在项目的开发过程中，项目经理可组织项目组成员对编制的代码进行互相审核，目的是审查代码是否符合《研发中心软件编码标准》的要求，并在联调前找到代码中的缺陷，审核时要做好审核记录，内容为代码的编写人、审核人、缺陷位置、缺陷描述和改进建议，格式由项目经理决定。

根据项目的具体情况，项目经理有权决定不进行代码的互审。

4.2.2.4.2研发中心内部抽查审核，在项目的开发过程中，主管软件的研发经理可组织相关人员对项目组的开发质量进行抽查审核，被审核的代码模块由研发经理确认，审核的主要目的是验证的代码书写的规范性和与设计的符合性。

在评审中发现问题，主管软件的研发经理可口头通知项目经理进行整改，问题严重时，可对项目组下达《软件整改通知单》，通知项目组进行整改。

具体使用何种方式由主管软件的研发经理确定。

《软件整改通知单》下达后，按比例扣除项目组的项目奖金，扣除办法参见《研发软件项目奖金发放制度》。

4.2.2.4.3项目组内部集成验证测试，项目经理可在代码完成后组织内部集成测试，并同时指派项目组成员进行《软件使用说明书》的编制，在内部集成测试结束，《软件使用说明书》完成后，项目经理可申请提交软件的a测试。

4.2.2.4.4《a测试申请书》，项目经理负责编制《a测试申请书》，格式参照《a测试申请书模板》。

编制完毕后，与《软件使用说明书》一起提交给主管软件的研发经理进行审核确认，主管软件的研发经理签字同意后，指定项目的测试人员，进行a测试。

4.2.2.4.5测试人员根据《研发立项申请书》和《软件使用说明书》的要求与内容，编制《软件测试大纲》，确定要测试的具体项目以及对这些项目的要求，《软件测试大纲》编制完成后要由项目经理认可，主管软件的研发经理确认。

同时项目组负责协助测试环境的搭建。

4.2.2.4.6在一轮测试结束后，测试人员出具《项目测试报告》。

项目组对测试出的问题进行修改，然后再申请新一轮的测试，新的一轮测试由项目经理决定是进行验证性测试还是完整测试，如果是验证性测试，可由项目经理确定测试内容范围并和测试经理协商测试周期，循环上述过程直到项目经理认为可以结束测试。

为了保证测试质量，要求最后一次测试必须是完整测试。

测试结束后，测试人员要编制《测试过程总结报告》。

4.3研发结项

4.3.1测试结束后，项目经理可决定对项目进行结项提交。

4.3.2项目经理负责编制《研发结项申请书》，格式参照《研发结项申请书模板》。

4.3.3《研发结项申请书》要对所存留的问题进行详细描述。

4.3.4《研发结项申请书》说明项目的实际开发周期，与计划周期的差异将作为项目奖金的评定依据。

4.3.5《研发结项申请书》要说明项目质量目标的实现情况，根据《测试过程总结报告》统计出项目的实际质量，与计划质量目标的差异将作为项目奖金的评定依据。

4.3.6《研发结项申请书》中所存留问题部分的内容需由此项目的实际测试人员进行确认。

4.3.7《研发结项申请书》由项目经理、主管软件的研发经理、营销中心经理、技服中心经理认可后，由主管研发副总经理最终确认。

4.3.4项目提交后，项目经理出具《软件项目信息统计表》，由主管软件的研发经理认可，主管研发副总经理最终确认，作为项目奖金分配的依据。

4.4技术资料的管理与备份

4.4.1项目经理负责技术资料的管理与备份，备份内容包括项目所涉及的文档、代码和其他相关技术资料。

4.4.2项目立项后，项目组要在代码管理服务器上建立专门的项目目录。

4.4.3在研发过程中，项目组不定期的向代码管理服务器进行代码备份，备份时机由项目经理决定。

4.4.4项目提交测试前要进行一次完整备份。

4.4.5项目结项后，要进行一次完整备份，并将最终项目内容刻录光盘备档。

4.4.6备档后的光盘由主管软件的研发经理统一管理。

4.4.7在研发过程中，纸质文档由项目经理负责管理，项目结项后提交到主管软件的研发经理备档。

4.4.8由于项目组备份不及时和备份管理不到位造成项目资料丢失，致使开发周期延误的，每发生一次按比例扣发项目经理的项目奖金，造成重大损失的，全部扣发项目经理项目奖金，并根据具体情况追究其责任,是否为重大损失由主管软件的研发经理确认。

奖金的扣发办法参照《研发软件项目奖金发放制度》。

5职责和权限

5.1主管研发副总经理负责本规范的编制、发布、维护与解释。

5.2主管软件的研发经理负责推动和监督本规范的实施。

5.3公司所有员工可对本规范提出修改意见。

研发硬件项目奖金发放制度

第一条为调动硬件研发人员的工作积极性，提高硬件的开发质量和开发效率，促进研发人员深入市场，及时跟踪产品的销售情况，特制定此制度。

第二条本制度适用于从事硬件项目开发的人员。

第三条根据《研发中心硬件开发过程规范》的要求立项的项目，在项目完成，《项目结项申请书》通过批准后，参与项目的研发人员可在此项目的产品产生销售时，通过提成方式获得项目奖金。

第四条项目奖金的发放额度在项目结项后确定，原则上不得超过所研发的产品销售毛利的10％，不低于产品销售毛利的5％，具体额度由研发中心硬件经理、营销中心经理、副总经理、总经理协商，总经理最终确定。

第五条当发生大市场变化，需要重新确定奖金发放额度时，可由营销中心经理提出，经过研发中心硬件经理、营销中心经理、副总经理、总经理重新协商后，总经理最终确定。

第六条奖金的发放时限为从项目的计划结项日期开始起的三年时间，超过此时限研发人员不再获得此项目产品的奖金。

第七条奖金每月结算一次，项目组内部的分配比例由项目经理在结项后确定，经过研发中心硬件经理认可，主管研发副总经理最终确定。

第八条当项目产品由于技术升级等原因，重新立项升级后，分配比例重新确定，奖金发放时限按新项目计算。

第九条项目提前完成时，按比例增加奖金发放额度，比例计算方法为：

增加比例＝（计划工作日-实际工作日）/计划工作日

当增加比例大于50％时，按50％计算，当增加比例小于0时，按0计算。

例如，项目计划用100天完成，项目组实际用了80天，确定的基础奖金额度为每例1000元，则增加比例为（100-80）/100=20%，实际每例的奖金额度为1000×（1+20%）=1200元。

当项目未完成立项时所计划的质量目标时，此条无效。

第十条当项目未完成立项时所计划的质量目标时，按比例减少奖金发放额度，比例计算方法为：

减少比例＝（实际缺陷数量-计划缺陷数量）/计划缺陷数量

当减少比例大于50％时，按50％计算，当减少比例小于0时，按0计算。

例如，项目的计划缺陷数为100，实际缺陷数为120，确定的基础奖金额度为每例1000元，则减少比例为（120-100）/100=20%，实际每例奖金额度为1000×（1-20%）=800元。

第十一条项目的测试人员按确定的基础奖金额度的5％获得项目奖金，当测试出的缺陷数量超过立项所计划的质量目标时，测试人员获得质量监督奖，比例的计算方法为：

增加比例＝（实际缺陷数量-计划缺陷数量）/计划缺陷数量

当增加比例大于500％时，按500％计算，当增加比例小于0时，按0计算。

例如，项目的计划缺陷数为100，实际缺陷数为200，确定的基础奖金额度为每例1000元，则增加比例为（200-100）/100=100%，测试人员实际每例获得的奖金额度为1000×5％×（1＋100％）＝100元。

每次发放项目奖金时，从实际应发的奖金额度中扣除测试人员所应发的奖金额度，剩余部分项目组内部按比例发放。

如果有一级缺陷未在测试中被发现，而在后续的销售环节中被发现的，从缺陷被发现之日起，测试人员不再获得项目奖金，并全额扣除测试人员的质量保证金。

第十二条项目开发过程中，线路板设计人员一次设计成功，则以所设计线路板的实际硬件成本和加工费的100％比例一次性奖励项目组，其中设计人员获得其中的70%，项目经理获得其中的10％，剩余20％有项目经理负责分配，此奖金在项目结项后一次性领取，如果项目未完成立项时计划的质量目标，则此条无效。

第十三条项目开发过程中，线路板设计人员三次或三次以上还未设计成功，则从第三次算起，每失败一次，按所设计线路板的实际硬件成本和加工费的50％比例一次性处罚项目组，处罚分配比例由项目经理决定，项目经理所承担的额度不得低于总额度的20％。

罚金从后续的项目奖金中扣除。

第十四条项目奖金发放的第一年，公司暂留发放额度的40％作为质量保证金，当产品因研发原因在现场出现问题，需要研发人员解决时，研发人员出差产生的部分费用从质量保证金中支出，支出比例为出差费用的50％，如果暂留的质量保证金不足，则按全额质量保证金扣除，多出部分由公司负担，扣除时以当前剩余的质量保证金为限，不涉及以后的质量保证金。

最终剩余的质量保证金满一年后一次性发放，如果项目组成员中途离职，则不发放暂留的质量保证金。

从项目奖金发放的第二年开始，不再暂留质量保证金，升级项目重新计算。

第十五条开发过程中，在内部质量审核时，由于存在质量问题或不符合标准等问题，被下达《硬件整改通知单》进行整改的，每下达一次《硬件整改通知单》，扣除项目组研发人员项目奖金总额度的2％。

第十六条由于项目组备份不及时和备份管理不到位造成项目资料丢失，致使开发周期延误的，每发生一次扣发项目经理项目奖金的30％，直至全部扣发。

造成重大损失的，全部扣发项目经理项目奖金，并根据具体情况追究其责任,是否为重大损失由主管硬件的研发经理确认。

第十七条在项目奖金发放期间，出现因研发原因引起的产品退货时，按110％的比例扣除当次所发放项目奖金。

第十八条在项目产品基础上产生的定制版本，要重新核算一个分配比例，每例奖金额度不变，以后销售此定制版本产品时，按新比例发放奖金。

产品定制不影响项目奖金的发放时限。

新比例由项目经理，研发软件经理协商，主管研发副总经理最终确定。

第十九条因公司发展需要所研发的一些基础类项目，短期内不能产生销售时，可在项目结束后一次性发放固定额度的奖金给研发人员，具体额度由研发中心硬件经理、营销中心经理、副总经理、总经理协商，总经理最终确定。

第二十条本制度由主管研发副总经理负责解释。

研发软件项目奖金发放制度

第一条为调动软件研发人员的工作积极性，提高软件的开发质量和开发效率，促进研发人员深入市场，及时跟踪产品的销售情况，特制定此制度。

第二条本制度适用于从事软件项目开发的人员。

第三条根据《研发中心软件开发过程规范》的要求立项的项目，在项目完成，《项目结项申请书》通过批准后，参与项目的研发人员可在此项目的产品产生销售时，通过提成方式获得项目奖金。

第四条项目奖金的发放额度在项目结项后确定，原则上不得超过所研发的产品销售毛利的10％，不低于产品销售毛利的5％，具体额度由研发中心软件经理、营销中心经理、副总经理、总经理协商，总经理最终确定。

第五条当发生大市场变化，需要重新确定奖金发放额度时，可由营销中心经理提出，经过研发中心软件经理、营销中心经理、副总经理、总经理重新协商后，总经理最终确定。

第六条奖金的发放时限为从项目的计划结项日期开始起的三年时间，超过此时限研发人员不再获得此项目产品的奖金。

第七条奖金每月结算一次，项目组内部的分配比例由项目经理在结项后确定，经过研发中心软件经理认可，主管研发副总经理最终确定。

第八条当项目产品由于技术升级等原因，重新立项升级后，分配比例重新确定，奖金发放时限按新项目计算。

第九条项目提前完成时，按比例增加奖金发放额度，比例计算方法为：

增加比例＝（计划工作日-实际工作日）/计划工作日

当增加比例大于50％时，按50％计算，当增加比例小于0时，按0计算。

例如，项目计划用100天完成，项目组实际用了80天，确定的基础奖金额度为每例1000元，则增加比例为（100-80）/100=20%，实际每例的奖金额度为1000×（1+20%）=1200元。

当项目未完成立项时所计划的质量目标时，此条无效。

第十条当项目未完成立项时所计划的质量目标时，按比例减少奖金发放额度，比例计算方法为：

减少比例＝（实际缺陷数量-计划缺陷数量）/计划缺陷数量

当减少比例大于50％时，按50％计算，当减少比例小于0时，按0计算。

例如，项目的计划缺陷数为100，实际缺陷数为120，确定的基础奖金额度为每例1000元，则减少比例为（120-100）/100=20%，实际每例奖金额度为1000×（1-20%）=800元。

第十一条项目的测试人员按确定的基础奖金额度的5％获得项目奖金，当测试出的缺陷数量超过立项所计划的质量目标时，测试人员获得质量监督奖，比例的计算方法为：

增加比例＝（实际缺陷数量-计划缺陷数量）/计划缺陷数量

当增加比例大于500％时，按500％计算，当增加比例小于0时，按0计算。

例如，项目的计划缺陷数为100，实际缺陷数为200，确定的基础奖金额度为每例1000元，则增加比例为（200-100）/100=100%，测试人员实际每例获得的奖金额度为1000×5％×（1＋100％）＝100元。

每次发放项目奖金时，从实际应发的奖金额度中扣除测试人员所应发的奖金额度，剩余部分项目组内部按比例发放。

如果有一级缺陷未在测试中被发现，而在后续的销售环节中被发现的，从缺陷被发现之日起，测试人员不再获得项目奖金，并全额扣除测试人员的质量保证金。

第十二条项目奖金发放的第一年，公司暂留发放额度的40％作为质量保证金，当产品因研发原因在现场出现问题，需要研发人员解决时，研发人员出差产生的部分费用从质量保证金中支出，支出比例为出差费用的50％，如果暂留的质量保证金不足，则按全额质量保证金扣除，多出部分由公司负担，扣除时以当前剩余的质量保证金为限，不涉及以后的质量保证金。

最终剩余的质量保证金满一年后一次性发放，如果项目组成员中途离职，则不发放暂留的质量保证金。

从项目奖金发放的第二年开始，不再暂留质量保证金，升级项目重新计算。

第十三条开发过程中，在内部质量审核时，由于存在质量问题或不符合标准等问题，被下达《软件整改通知单》进行整改的，每下达一次《软件整改通知单》，扣除项目组研发人员项目奖金总额度的2％。

第十四条由于项目组备份不及时和备份管理不到位造成项目资料丢失，致使开发周期延误的，每发生一次扣发项目经理项目奖金的30％，直至全部扣发。

造成重大损失的，全部扣发项目经理项目奖金，并根据具体情况追究其责任,是否为重大损失由主管软件的研发经理确认。

第十五条在项目奖金发放期间，出现因研发原因引起的产品退货时，按110％的比例扣除当次所发放项目奖金。

第十六条在项目产品基础上产生的定制版本，要重新核算一个分配比例，每例奖金额度不变，以后销售此定制版本产品时，按新比例发放奖金。

产品定制不影响项目奖金的发放时限。

新比例由项目经理，研发软件经理协商，主管研发副总经理最终确定。

第十七条因公司发展需要所研发的一些基础类项目，短期内不能产生销售时，可在项目结束后一次性发放固定额度的奖金给研发人员，具体额度由研发中心软件经理、营销中心经理、副总经理、总经理协商，总经理最终确定。

第十八