技术部管理制度（技术部软件研发管理制度办法规定）

　　技术部管理制度（技术部软件研发管理制度、办法、规定）一、软件研发管理办法
　　软件研发管理办法
　　第1章 总则
　　第1条 目的。
　　为规范软件研发工作，提高研发质量，降低成本，结合公司的实际情况，特制定本办法。
　　第2条 管理部门。
　　软件研发部是软件研发工作的归口管理部门，负责软件的需求调查、设计、开发、测试、发布等各项工作。
　　第2章 软件产品研发决策管理
　　第3条 产品规划内容。
　　产品规划是指产品规划人员通过调查研究，做出有关需求分析、市场导向、竞争对手和产品发展方向的分析报告，制定和维护产品的目标，确保产品满足客户的需要。其具体工作内容包括以下三个方面。
　　1．软件研发部调研人员通过客户需求分析，获取与产品发展相关的客户意向、市场需求、竞争态势、同类产品等信息。
　　2．根据调研分析结果，确定产品的主要发展方向；根据客户与公司的需要，确定产品的关键属性等。
　　3．制定产品的长期目标。
　　第4条 可行性研究及决策程序。
　　1．软件研发部调研分析人员进行市场调查与分析，确认软件的市场需求。
　　2．在调查研究的基础上进行可行性研究，提交可行性分析报告。
　　3．软件研发主管副总组织相关人员进行论证，决定项目取消或继续。
　　4．软件研发部根据论证结果制订初步的软件开发计划。
　　5．根据市场环境、公司软硬件情况预测风险因素。
　　第3章 软件需求分析
　　第5条 软件需求分析与制定研发计划流程。
　　1．调查被开发软件企业的状况。
　　2．对软件开发需求进行分析并给出详细的功能定义。
　　3．做出简单的软件原型，与用户共同研究，直到用户满意为止。
　　4．对可利用的资源（计算机硬件、软件、人力等）进行估计，制订研发进度计划（可有相应的缓冲时间）。
　　5．制订详细的软件研发计划。
　　6．制订质量控制计划和测试计划。
　　7．编写初步的用户手册
　　8．评审。
　　第6条 软件需求分析要求。
　　1．必须以运行环境为基础。
　　2．应有用户指定人员参加。
　　3．需求说明书必须明确，并经过用户确认。
　　第7条 软件需求审批。
　　经评审通过的各项内容形成相应的文档后，须提交软件研发经理审核确认。
　　第4章 概要设计
　　第8条 概要设计的实施流程。
　　1．确定目标系统的总体结构。
　　（1）对于大型系统，可按主要的软件需求划分成子系统，然后为每个子系统定义功能模块及各功能模块间的关系，并描述各子系统的接口界面。
　　（2）对于一般系统，可按软件需求直接定义目标系统的功能模块及各功能模块间的关系。
　　2．给出每个功能模块的功能描述、数据接口描述，以及外部文件与各功能模块间的关系。
　　3．设计数据库或数据结构。
　　4．制订各阶段开发的目标（里程碑）计划。
　　5．制订第一个里程碑的测试计划。
　　6．评审。
　　第9条 概要设计要求。
　　1．在设计目标系统的整体结构时，应力争使其具有好的形态，各功能模块间应满足低耦合度，而各功能模块内应满足高内聚度。功能模块的作用范围应在其控制范围之内。
　　2．在设计目标系统的总体结构时，应降低模块接口的复杂性，以提高目标系统的可靠性。
　　3．每一个里程碑计划又可分为详细设计、实现、组装测试、确认测试、发布、交接等阶段。
　　第10条 审批流程。
　　1．经评审通过的各项内容形成相应的文档后，提交给软件研发部经理审核确认。
　　2．数据库/数据结构设计说明书、概要设计说明书经软件研发部经理确认后还须提交给主管技术副总进行审核确认。
　　第5章 详细设计
　　第11条 详细设计的实施流程。
　　1．将概要设计产生的构成软件系统的各个功能模块逐步细化，形成若干个程序模块。
　　2．确定各程序模块之间的详细接口信息。
　　3．撰写拟订单元测试计划。
　　4．评审。
　　第12条 详细设计的工作要求。
　　1．确定程序模块内的数据流或控制流，对每个程序模块必须确定所有输入、输出和处理功能。
　　2．规定符号的使用规范，确定设计的命名规则。
　　第13条 审批流程。
　　1．经评审通过的各项内容形成相应的文档后，提交给软件研发部经理审核确认。
　　2．详细设计说明书经软件研发部经理确认后，还须提交给主管技术副总进行审核确认。
　　第6章 软件实现
　　第14条 软件实现的实施与要求。
　　1．对每个程序模块用所选定的程序设计语言进行编码，写出的程序应该结构良好、清晰易读且与设计一致，符合公司编码规范。
　　2．单元测试，研发人员按单元测试计划对自己编写的程序进行测试。
　　3．对编程及单元测试过程进行版本管理，主要由高级项目工程师负责。
　　第15条 审批。
　　所有文档必须提交给软件研发部经理审核确认。
　　第7章 测试与发布
　　第16条 组装测试实施程序。
　　1．开发组完成单元自测后，由研发负责人填写＂测试申请单＂连同测试产品清单交与测试人员。
　　2．相关测试人员根据提交的申请单将源程序、文档等拷贝到测试产品目录中。
　　3．执行测试计划中要求的所有组装测试。
　　4．测试人员对测试结果进行分析，生成问题列表（Bug List），返给研发负责人。
　　5．研发人员经过分析、修复并自测完毕，生成Bug修复报告，返给测试人员。
　　6．测试人员进行反复测试，直至测试通过。
　　第17条 组装测试工作要求。
　　1．组装测试应保证模块间无错误连接。
　　2．应对软件系统或子系统的输入输出能力进行测试，使其达到设计要求。
　　3．应测试软件系统或子系统正确的能力和经受错误的能力。
　　第18条 确认测试实施程序。
　　1．在模拟的环境中进行强度测试，即在事先规定的一个时期内运行软件的所有功能，以证明该软件无严重错误。
　　2．执行测试计划中的所有确认测试。
　　3．使用用户手册，以进一步证实其实用性和有效性，并改正其中的错误。
　　4．对测试结果进行分析，生成当前Bug列表。
　　5．反复查找Bug原因，直到修复。
　　6．对所有文件进行整理。
　　第19条 确认测试工作要求。
　　1．全部系统存储量、输入及输出通道，以及进行处理必须预留的余量。
　　2．将预期结果、测试结果及测试数据全部存档。
　　3．测试人员将测试清单中缺少的文档列入Bug记录表。
　　4．对测试中重现与未重现的Bug均要有说明。
　　第20条 发布过程管理。
　　1．经测试合格的产品由测试人员填写＂发布申请表＂连同发布文档一起提交给软件研发部经理、主管副总进行审核。
　　2．软件研发部经理、主管副总审核发布申请。
　　3．测试人员将要发布的产品（包括源程序、执行文件及相关文档）放入发布产品目录中并生成安装程序。
　　第8章 附则
　　第21条 本办法由公司软件研发部制定，修改权、解释权归公司软件研发部所有。
　　第22条 本办法自颁布之日起执行。
　　技术部二、软件需求管理规定
　　软件需求管理规定
　　第1章 总则
　　第1条 目的。
　　为使软件产品满足规定的需求而确定软件的体系结构、组成模块划分和接口说明等，并将上述结果翻译成代码，以实现软件所要求的功能，特制定本规定。
　　第2条 适用范围。
　　本规定适用于公司所有的软件产品的设计与研发工作。
　　第3条 责任部门。
　　软件研发部负责软件需求管理的各项工作。
　　第4条 软件需求的定义。
　　1．用户需求，即用户解决问题或达到目标所需的条件和能力。
　　2．系统需求，即系统或系统部件要满足合同、标准、规范或其他正式文档所必须具有的条件和能力。
　　3．反映需求或能力的文档说明，即对软件设计研发目的的描述。
　　第5条 需求管理活动说明。
　　需求管理活动具体内容如下表所示。
　　第2章 软件需求管理的目标与原则
　　第6条 需求管理的原则。
　　1．需求需分类管理。
　　2．需求需分优先级。
　　3．需求必须文档化。
　　4．需求一旦变化，就必须对需求变更的影响进行评估。
　　5．需求管理必须与需求工程的其他活动紧密结合。
　　第7条 需求管理的目标。
　　1．使软件需求受控，并建立供软件工程和管理使用的需求基线。
　　2．使软件计划、产品、活动与软件需求保持一致。
　　第8条 软件需求的度量要素。
　　软件需求的度量包括9个要素，即正确性、无歧义、完备性、一致性、分级、可验证、可修改、可跟踪及可理解。
　　第3章 需求变更管理
　　第9条 需求变更的原因。
　　1．在软件研发早期所有的问题不可能被完全定义，软件需求是不完全的，这就注定了需求需要变更以便达到完善的程度。
　　2．随着软件的研发进度，软件研发人员对问题的理解发生变化，这些变化也需反馈到需求中去。
　　第10条 变更管理过程。
　　1．变更描述。
　　2．变更分析。
　　3．变更实现。
　　第11条 变更影响分析。
　　每一项需求变更都必须进行变更影响分析，明确它对研发计划和其他需求的影响，明确与变更相关的任务并评估完成这些任务需要的工作量。
　　第4章 软件需求文档管理
　　第12条 需求文档的作用。
　　在用户和研发人员之间就将要开发的软件系统需要达成一致的协议，从而产生正式的需求文档，以便为软件的研发和实现提供依据。
　　第13条 编写软件需求文档的注意事项。
　　1．语句和段落应尽量简短。
　　2．表达方式要采用主动语态。
　　3．语句要完整，且语法、标点等正确无误。
　　4．使用的术语要与词汇中的定义保持一致。
　　5．避免使用模糊、主观的术语。
　　6．避免使用比较性的词汇，尽量给出定量的说明，含糊的语句表达将引起需求的不可验证。
　　第14条 建立软件需求规格说明书。
　　需求文档采用软件需求规格说明书的形式，精确地阐述一个软件系统必须提供的功能和性能以及它所要考虑的限制条件，是对外部行为和系统环境接口间接、完整的描述性文档。
　　第5章 需求验证管理
　　第15条 需求验证流程。
　　1．审查需求文档。
　　2．依据需求编写测试用例。
　　3．编写用户手册。
　　4．确定合格的标准。
　　第16条 需求验证的内容。
　　1．有效性检查。
　　2．一致性检查。
　　3．完备性检查。
　　4．现实性检查。
　　5．可检验性检查。
　　6．可调节性检查。
　　7．可读性检查。
　　第6章 需求评审
　　第17条 需求评审人员。
　　需求评审人员由软件研发部研发人员与客户方的代表共同组成。
　　第18条 需求评审注意事项。
　　1．严格控制每一次评审的文档规模及持续时间。
　　2．评审工作要分段进行。
　　3．对讨论的问题进行控制。
　　4．避免无谓的争吵。
　　第7章 附则
　　第19条 本规定由公司软件研发部制定，其修改权、解释权归公司软件研发部所有。
　　第20条 本规定自颁布之日起执行。三、软件设计管理办法
　　软件设计管理办法
　　第1章 总则
　　第1条 目的。
　　为使软件产品满足规定的需求而确定软件的体系结构、组成模块划分和接口说明等，并将上述结果翻译成代码，以实现软件所要求的功能，特制定本办法。
　　第2条 适用范围。
　　本办法适用于公司所有的软件产品的设计管理工作。
　　第3条 责任部门及职责分工。
　　软件研发部是软件设计研发工作的归口管理部门。
　　1．软件研发部经理负责软件设计研发工作的日常管理，监督软件研发的进度，做好费用预算与控制工作。
　　2．软件研发高级工程师主要负责带领设计研发人员进行新软件的开发。
　　第2章 软件设计与研发
　　第4条 软件设计的内容。
　　1．编写系统的特性规格说明书，主要描述系统结构、各组件间的相关性、接口标准等内容。
　　2．从系统高层开始着手进行系统设计，逐步编写以下内容。
　　（1）对整个系统的设计方案作简明扼要的描述。
　　（2）绘制系统的结构图。
　　（3）确定系统中的风险因素。
　　（4）对系统的重用性进行分析。
　　3．对系统中的子系统进行细分，给出各子系统、各组件的规格说明。
　　4．根据产品的特性规格说明书，制订产品的开发计划。
　　第5条 特性规格说明书的内容。
　　1．摘要，对产品特性的概要描述。
　　2．论证，开发该产品与特性的原因。
　　3．目标，希望得到的最终产品结果。
　　4．需求，产品在发布前必须具备的功能。
　　5．用户使用操作说明。
　　6．进度，产品特性的开发进度和里程碑安排。
　　7．依赖关系，本产品特性依赖于哪些产品特性。
　　8．尚未解决、有待讨论的问题。
　　第6条 软件研发注意事项。
　　软件研发人员根据部门研发计划中的进度与各阶段的要求进行系统设计，设计过程中需考虑软件产品的三大要求，即使用要求、测试要求及维护要求。
　　第7条 软件研发报告。
　　软件研发报告应按公司规定的要求编写，在客户研发报告的格式和内容有特殊要求时，按与客户共同约定的规则编写。
　　第3章 软件研发评审
　　第8条 软件研发评审人员。
　　1．软件研发人员在提交研发报告之前必须对研发报告进行评审，评审活动主要由研发部经理、研发人员参加。
　　2．重大项目的评审需要公司高层领导参与。
　　3．必要时，公司可邀请客户参加评审工作。
　　4．评审记录由软件配置管理负责人填写并归档。
　　第9条 软件研发评审的内容。
　　软件研发评审的内容主要包括以下四点。
　　1．该项设计能否满足规定的功能和性能要求。
　　2．设计是否满足相应的设计规范。
　　3．设计是否满足下一阶段工作的输入要求。
　　4．在进入下一阶段工作前，所有已发现的错误或缺陷是否均已消除，或虽未消除但已弄清楚继续进行工作的风险。
　　第10条 设计的修改。
　　1．未通过评审的研发报告由设计人员负责按照评审意见进行修改，修改后重新进行评审。
　　2．在软件开发过程中，需要对研发报告进行修改时，设计人员须填写更改单申请更改，经审核批准后方可修改。
　　第4章 编码
　　第11条 编码实现。
　　1．项目研发人员应根据所要实现的系统要求选用相应的编程工具，并遵守《计算机源代码编写规范》或开发计划中确定的标准与规程进行系统编码。
　　2．研发人员按照系统报告的要求实现系统编码，以满足用户对系统功能和质量的要求。
　　第12条 编码检查。
　　在编码实现过程中，每一个阶段的结果在提交之前都应由研发高级经理进行检查，以确定其是否满足要求。检查工作包括以下三个方面的内容。
　　1．编程风格满足＂计算机源代码编写规范＂或已确定的标准与规程的要求。
　　2．本阶段的结果是否满足相应的功能和性能需求。
　　3．所有已发现的错误或缺陷均已消除或虽未消除但已弄清楚继续进行工作的风险。
　　第13条 编码信息管理。
　　在编码实现的过程中，研发人员应注意保存必要的编码信息和用户使用信息，完成编码后，应整理这些信息，并按照要求编写＂技术报告＂和＂用户手册＂。
　　第5章 附则
　　第14条 本办法由公司软件研发部制定，其修改权、解释权归软件研发部所有。
　　第15条 本办法自颁布之日起执行。
　　四、软件测试管理规定
　　软件测试管理规定
　　第1章 总则
　　第1条 目的。
　　1．规范软件测试工作，完善测试标准和测试方法。
　　2．确保公司软件产品质量，满足客户要求。
　　3．降低软件开发成本与维护成本。
　　第2条 适用范围。
　　本规定适用于公司新研发或改良升级软件的测试工作。
　　第3条 测试的主要工作内容。
　　1．开展系统、深入、广泛的测试。
　　2．找出产品中存在的所有问题，尽早开展修复工作。
　　3．测试产品的同时，在产品实现之前，对产品的设计进行审核和测试。
　　4．关注产品的规格、进度、资源以及产品开发后期的任何变化。
　　第4条 管理职责分工。
　　软件测试工程师主要负责软件测试计划的制订、执行等相关工作，受软件研发经理的指导与监督，各相关人员需积极配合软件测试工作。
　　第2章 编写测试计划
　　第5条 测试计划的编制。
　　测试计划是测试人员管理测试项目和发现Bug的重要工具，由测试工程师根据测试的对象与测试标准制定，并经软件研发部经理审批通过后方可执行。
　　第6条 测试计划的内容。
　　1．产品概述，说明待测产品的名称、特征、用途以及测试产品的目的。
　　2．测试策略，是测试依据的主要原则、理论、方法，以及测试时重点考虑的因素，等等。
　　3．测试所采用的方法。
　　4．测试区域。
　　5．测试配置。
　　6．测试周期。
　　7．测试资源规划。
　　8．风险分析及应急计划。
　　第3章 测试用例设计
　　第7条 测试用例的设计原则。
　　1．能够复用原则。
　　2．易于分类原则。
　　3．测试内容不重复原则。
　　4．数据库管理归档所有测试用例原则。
　　5．在研发测试过程中不断调整及增强原则。
　　第8条 测试用例应满足的条件
　　1．测试用例应尽可能覆盖软件产品的功能特点和程序代码中的分支流程，并极有可能抓住Bug。
　　2．测试用例应注重测试那些最特殊的输入组合，如对最大值、最小值等边界输入条件的测试。
　　3．选择测试用例时应选用经实践证明最有效的测试用例。
　　4．将复杂的测试用例分解成一组较简单的测试用例分别进行测试。
　　第4章 Bug管理
　　第9条 Bug的界定。
　　1．功能未实现，和规格说明书的描述不一致。
　　2．不能工作，死机，没反应。
　　3．对某种软、硬件配置不兼容。
　　4．在设置边界条件时发生功能缺失或错误。
　　5．界面、消息、提示不够准确，不友好。
　　6．有时把未完成的工作也作为一个Bug。
　　第10条 Bug的级别与后果
　　1．死机，导致死机或系统瘫痪。
　　2．主要问题，可能引发严重问题。
　　3．小问题，不太严重。
　　4．微小问题。
　　第11条 Bug的优先级。
　　1．需要尽快修正的Bug。
　　2．每个里程碑结束前必须修正的Bug。
　　3．如果时间允许就修正的Bug。
　　4．低优先级的Bug。
　　第12条 Bug状态分类。
　　1．活动的Bug。
　　2．已经解决的Bug。
　　3．关闭的Bug。
　　第13条 Bug报告管理。
　　在软件开发过程中，发现并报告Bug不仅是测试工程师的职责，也是所有研发参与人员的职责，所有人报告的Bug都被统一记录、跟踪和管理。
　　第14条 Bug保存。
　　Bug的每一次处理都被记录在数据库内，所有记录都无法删除，只能为记录添加新的内容。
　　第15条 Bug报告与分析流程。
　　1．测试工程师在发现或接收到Bug报告后，应立即建立一个新Bug记录，以备后续的跟踪和管理，Bug记录应包含Bug的具体再现步骤、环境和Bug再现时的屏幕截图等。
　　2．测试工程师应尽可能分析产生Bug的原因，并根据该Bug对于后续软件开发和发布的影响程度，设定合适的优先级和严重级别。
　　3．在分析产生Bug原因的基础上，对Bug进行归类管理。
　　4．设定好优先级和严重级别的Bug将被测试人员根据Bug出现的位置、Bug的可能成因等分派到相关的开发人员，由其专门负责解决。
　　第16条 Bug的解决方法。
　　1．已修正。
　　2．推迟。
　　3．设计问题。
　　4．重复。
　　5．不可再现。
　　6．无需修正。
　　第5章 测试过程管理
　　第17条 完整的测试循环过程工作内容。
　　1．完整测试，按测试计划和测试用例的要求，将所有测试用例完整地执行一遍。
　　2．随机测试，提高发现Bug的几率。
　　3．Bug校验（回归测试），对所有已经改正的Bug进行再次测试，确保先前发现的Bug已完全解决。
　　4．结束条件测试。
　　第18条 各阶段的测试。
　　各测试阶段的测试内容与测试后的技术状态如下表所示。
　　第19条 测试质量要求
　　质量是由产品的可靠性、功能和上市时间来决定的，是三者之间的平衡。
　　1．可靠性是指软件产品功能的正确性，即无大的缺陷或缺陷很少。
　　2．功能是软件产品提供给客户的所有可操作的特性。
　　3．上市时间与软件研发的进度相关。
　　第6章 附则
　　第20条 本规定由公司软件研发部制定，其修改权、解释权归软件研发部所有。
　　第21条 本规定自颁布之日起执行。五、软件研发质量管理制度
　　软件研发质量管理制度
　　第1章 总则
　　第1条 目的。
　　为加强对软件质量的管理，符合标准及规范的要求，确保技术文档齐全正确并且系统便于维护，不断提高公司软件产品的质量水平，特制定本制度。
　　第2条 适用范围。
　　本制度适用于软件研发过程中的质量管理相关工作事项。
　　第3条 相关职责。
　　1．软件研发人员
　　软件研发人员在研发项目的初始阶段组织人员编写＂研发项目质量控制计划＂。
　　2．研发项目质量管理负责人
　　研发项目质量管理负责人负责研发项目实施过程中的质量控制，对其进行评价，组织相关人员制定并实施纠正措施与预防措施。
　　3．研发项目质量管理人员
　　研发项目质量管理人员负责项目研发过程中规定数据的记录和统计，参与研发过程和产品质量改进的相关活动。
　　第4条 软件质量特性。
　　软件产品的质量具有功能性、可靠性、易用性、效率、可维护性、可移植性等特性。
　　第5条 软件质量控制程序。
　　1．编制并执行质量计划。
　　2．进行过程评审。
　　3．软件测试与缺陷跟踪。
　　4．建立报告制度。
　　第2章 编制质量控制计划
　　第6条 质量控制计划内容。
　　研发项目负责人在项目策划阶段组织人员编制的质量控制计划应结合项目的规模、目标、研发周期等具体情况，所编制的质量控制计划应包括以下三个方面的内容。
　　1．研发项目的质量目标。
　　2．研发项目中的质量保证活动人员的职责与权限。
　　3．项目研发过程中的质量控制措施。
　　第7条 软件研发过程质量控制计划。
　　软件研发过程质量控制计划与措施如下表所示。
　　第3章 软件评审
　　第8条 软件评审工作内容。
　　相关技术人员在软件研发的各个阶段进行有组织的软件浏览、文档与代码审读活动，验证工作是否符合预定的标准，其目的是协助软件研发人员在研发初期找出工作中的错误。
　　第9条 软件评审人员。
　　1．评审活动主持人：负责领导与组织审查工作，一般由评审经验丰富的资深研发同行担任，可以是部门内其他研发项目的项目主管，而不能由被评审项目的管理人员担任。
　　2．研发人员：被评审项目的人员。
　　3．评审员：人数一般为5～6人，担任者为技术方面的同行。
　　4．记录员：担任者为技术方面的同行。
　　第10条 评审内容。
　　评审具体内容应参照各相关过程的程序文件执行，如需求分析阶段的评审按照需求分析程序的有关规定进行，开发设计阶段的评审按照开发设计程序的有关流程进行。
　　第11条 评审实施流程。
　　1．人员培训：项目进行初次评审前，需对评审人员进行相关培训，使其熟悉评审程序与相关标准，以提高评审工作的有效性和效率。
　　2．评审准备：研发人员及其管理人员准备好待评审软件，准备好评审所需的材料。
　　3．分发评审材料，即在评审会议前两天将评审材料和评审表格分发给每一位评审员阅读。
　　4．召开评审会议：评审主持人、评审员、研发人员、记录员参加评审会议，会议的重点是查找问题，会议时间一般控制在两个小时，记录员整理评审内容。
　　5．评审报告：记录员依据会议意见整理成评审报告，填写＂评审总结表＂，经主持人签字后生效，交研发工作人员。
　　6．软件修复：研发人员根据评审报告对软件进行修复，修复完成后再次申请评审。
　　7．缺陷跟踪：缺陷跟踪人员将评审出的缺陷录入缺陷跟踪数据库，实施缺陷跟踪与监督。
　　第4章 建立质量报告制度
　　第12条 报告程序。
　　研发人员在研发项目过程中建立报告制度，相关的质量管理人员应定期编写质量控制报告报相关领导审核，使相关领导能够全面了解软件研发质量控制情况，并制定有针对性的措施，以确保整个项目的质量。
　　第13条 项目质量报告类型。
　　1．质量情况周报。
　　2．异常情况报表。
　　3．质量整改反馈报表。
　　4．质量管理人员工作周报。
　　第5章 附则
　　第14条 本制度由公司软件研发部制定，其修改权、解释权归公司软件研发部所有。
　　第15条 本制度自颁布之日起执行。