阅读导航→01 软件研发管理办法02 软件需求管理规定03 软件设计管理办法04 软件测试管理规定05 软件研发质量管理制度一、软件研发管理办法软件研发管理办法第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．测试用例应尽可能覆盖软件产品的功能特点和程序代码中的分支流程，并极有可能抓住Bug2．测试用例应注重测试那些最特殊的输入组合，如对最大值、最小值等边界输入条件的测试3．选择测试用例时应选用经实践证明最有效的测试用例4．将复杂的测试用例分解成一组较简单的测试用例分别进行测试第4章 Bug管理第9条 Bug的界定1．功能未实现，和规格说明书的描述不一致2．不能工作，死机，没反应3．对某种软、硬件配置不兼容4．在设置边界条件时发生功能缺失或错误5．界面、消息、提示不够准确，不友好6．有时把未完成的工作也作为一个Bug第10条 Bug的级别与后果1．死机，导致死机或系统瘫痪2．主要问题，可能引发严重问题3．小问题，不太严重4．微小问题第11条 Bug的优先级1．需要尽快修正的Bug2．每个里程碑结束前必须修正的Bug3．如果时间允许就修正的Bug4．低优先级的Bug第12条 Bug状态分类1．活动的Bug2．已经解决的Bug3．关闭的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条 本制度自颁布之日起执行#技术部##制度设计##管理工具#本文由弗布克原创，版权归属弗布克，欢迎转发，禁止转载，抄袭、洗稿，侵权必究领取本资料的Word、PDF版完整内容方法：1.本资源编号：7382.关注+评论+转发，然后私信“资料”
（图片来源网络，侵删）
0 评论