软件开发规范.docx

软件开发规范.docx

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

软件开发规范

质量管理体系

计算机软件设计、开发专业审核指导书

1适用范围

本指导书适用于计算机软件设计、开发专业

2术语

软件：

与计算机系统的操作有关的程序、规程、规则及任何与之有关的文档。

软件生存周期（Lifecycle）：

软件产品从构思开始至软件不再可用结束的时间周期。

软件生存周期典型地包括：

需求阶段、设计阶段、实现阶段、测试阶段、安装和验收阶段、操作和维护阶段有时还包括退役阶段。

软件工程：

运用现代科学技术知识来设计并构造计算机程序及为开发、运行和维护这些程序所必需的相关文件资料。

软件配置项：

软件配置管理的对象，指的是软件工程过程中产生的所有信息项。

包括计算机可执行的源代码、目标代码、数据库等以及计算机不可执行的文档、源程序清单、测试用例等。

软件配置管理：

标识和确定系统中配置项的过程，在系统整个生存周期内控制这些项的投放和更动，记录并报告配置的状态和更动要求，验证配置项的完整性和正确性。

软件测试：

为了发现错误而执行程序的过程，或者说是根据软件开发各阶段的规格说明和程序的内部结构而精心设计一批测试用例，并利用这些测试用例去运行程序，以发现程序错误的过程。

黑盒测试：

又叫功能测试或数据驱动测试。

只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明，而不考虑程序内部的逻辑结构和内部特性。

白盒测试：

又叫结构测试或逻辑驱动测试。

测试人员利用程序内部的逻辑结构以及有关信息，涉及或选择测试用例，对程序所有逻辑路径进行测试。

通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。

基线（Baseline）：

已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理过程方能加以修改的规格说明或产品。

CMM：

软件过程能力成熟度模型，可用于对软件过程评估和软件能力评价。

单元测试：

又称模块测试，是针对软件设计的最小单元——程序模块，进行正确性检验的测试工作。

集成测试：

把软件部件、硬件部件或者两者组合起来进行的测试。

系统测试：

将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其他系统元素结合在一起，在实际运行（使用）环境下，对计算机系统进行一系列的组装测试和确认测试。

回归测试：

用于验证对软件修改后又没有引出新的错误，或者说，验证修改后的软件是否仍然满足系统的需求规格说明。

代码评审/走查：

由若干程序员和测试员组成一个评审小组，通过阅读、讨论和争议，对程序进行静态分析，确定程序中是否有某类错误或“危险”结构的过程。

Bug：

缺陷或隐错

编码（coding）：

即为程序编写，把软件设计转换成计算机可以接受的程序代码（即写成以某一种特定程序设计语言表示的“源程序清单”）的工作。

软件需求说明书：

也称软件规格说明书。

对所开发软件的功能、性能、用户界面、及其运行环境等做出详细的说明。

是用户与开发人员双方对软件需求取得共同理解基础上达成的协议。

概要设计：

对于系统或部件分析各种设计方案和定义软件体系结构、部件、接口和提出事件和估摸方面的估计的过程。

概要设计说明书：

概要设计工作阶段的成果。

说明系统的功能分配、模块划分、程序的总体结构、输入输出及接口设计、运行设计、数据结构设计和出错处理设计等，为详细设计奠定基础。

详细设计说明书：

着重描述每一个模块是如何实现的，包括实现算法、逻辑流程等。

3申请认证的特殊要求

无特殊要求

4专业指导

4.1产品及顾客群

实际使用软件来完成某项计算、控制或数据处理等任务的单位或个人。

4.2产品特性要求

计算机软件是一种复杂、抽象的逻辑实体，它所固有的一些特点有：

抽象性、复杂性、多样性、易变性、软件需求难于把握。

4.2.1软件产品的质量特性一般要求符合：

功能性：

满足明确或隐含的需求

可靠性：

在规定的一段时间和条件下，软件能维持其性能水平的能力

易用性：

使用方便

效率：

在规定的条件下操作，系统相应迅速、及时，占用资源少

可维护性：

软件出了问题或者对其功能加以扩充，易于维护

可移植性：

可容易地递从某一环境移植到另一环境下工作

4.2.2软件设计、开发流程与标准主要条款对应

7.3

软件设计：

从需求分析到概要设计、详细设计的过程

7.5

软件开发：

将设计转化为可交付客户使用，实现功能的产品的过程

7.5.1

软件工程项目管理

7.5.2

编码过程控制

7.5.3

配置管理

7.6

软件测试工具、测试环境

8.2.4

软件测试

8.3

Bug

软件企业的开发过程相当于一般生产企业的产品生产过程，而不是将软件复制作为软件生产过程。

4.3过程描述

4.3.1软件设计开发流程

4.3.2设计过程描述

软件设计是从项目立项开始，通过需求分析、系统分析、框架搭建、数据定义等过程，编制详细设计说明书、用户手册、测试计划等一系列文档的工作过程，最后输出的详细设计说明书清楚地描述了所设计产品的功能、性能、运行环境等要求，并且对各模块的内部接口定义明确。

开发人员依照文档即可进行编码、开发，即使开发人员变动，也不会造成对项目要求的理解偏差。

开发完成后所有功能，均符应合设计说明书的要求，该说明书也是系统测试的依据标准。

软件设计开发企业的设计，为从需求分析到设计说明书输出的这一过程阶段。

4.3.2.1设计策划

设计策划一般包含在项目开发计划中，内容可包括：

1）客户、分包方的职责和权限；

2）软件开发管理规程（可包含在管理体系文件中）；应注意客户是否有特殊流程的要求；

3）开发的环境，包括设施、标准、步骤，工具和开发平台；

4）开发所应实现的基本功能的要求

5）选定项目组成员并确定其在项目组中的作用和职责；

6）确定各个开发阶段及进度计划；部分阶段活动可能需进一步详细的质量策划，如测试阶段。

7）验证、确认方法。

在合同情况下，投标书（可包含可行性计划）可作为策划结果的输出。

4.3.2.2设计输入

设计输入包括需求调研、类似项目的资料（如果项目为以前项目的功能升级，则必须要考虑历史资料，以及兼容要求）、采用的标准、规则、惯例和约定，等。

设计输入应充分考虑合同评审的要求，在投标书或可行性计划的基础上，以顾客的需求为主要输入结合相关的法律法规等要求。

由于大部分客户自己不能提出详细的开发需求，软件项目往往在合同签订或立项前已经开始需求调研，设计开发人员的早期介入可更好地了解客户的需求。

分析的结果有时可直接作为概要设计，并作为合同附件。

4.3.2.3设计输出

设计开发的输出分为两个部分，一部分是编码前完成的文档如：

软件需求说明书、项目进度计划、测试计划等；另一部分是整个项目的最终结果即按顾客要求开发的软件，及其配套的文档如：

用户手册、操作手册等。

概要设计、详细设计、数据库设计完成后即可进入开发阶段。

4.3.2.4设计评审

在设计的适当阶段应进行正式的评审，这里的评审主要指对编码前各阶段工作的评审，应注意在以下阶段进行评审：

1）项目进度计划评审：

人员是否具备专业能力，资源配备是否充足，时间进度是否合理；

2）设计输入评审：

确保用户要求是否明确，是否与用户达成一致意见并得到用户的确认，输入信息及参考资料信息是否充分；需求规格说明书，应取得客户的确认。

3）概要设计评审：

评价概要设计的技术合适性，是否与规格说明一致；

4）详细设计评审：

确定详细设计对需求规格说明书中需求方面的可接受性及其方法的合适性和完整性；

4.3.2.5设计验证

由于软件开发过程的特殊性，开发未完成很难确认设计内容是否符合了用户的实际要求，并具有可操作性。

软件设计中的错误在编码的过程中也不一定能全部发现，甚至要到最终使用时才会显现。

因此，对设计的验证可通设计阶段形成演示版，对产品的风格、界面及部分功能的形式，对部分内容进行验证。

然后，结合测试阶段，在对软件测试的同时对软件设计进行验证。

软件测试应分阶段进行单元测试，整合完成后，应进行最终的系统测试，测试报告可作为对设计验证的记录。

测试通过后提交客户进入试运行阶段。

4.3.2.6设计确认

软件设计的确认在合同情况下应在内部测试之后，在用户现场环境中使用一段时间，由用户对功能、性能等方面是否达到预期效果进行确认，并予以记录；，可通过客户使用后的反馈、问题提交对设计进行确认，必要时应进行修改。

4.3.2.7设计更改的控制

由于软件项目需求变更经常发生，随着项目的进行，客户要求可能不断深化。

设计输入的变更可能贯穿于整个项目的实施过程，甚至在编码阶段也有可能变更。

应通过项目组同顾客的不断沟通在项目组内部、项目组与顾客充分交换意见，使顾客对这些分析设计结果的确认，尽量避免到项目后期再进行较大规模的功能修改，否则可能会引起项目的延期或者因更改一部分功能影响其他部分的后果。

重点审核更改要求有无评审并批准，由此更改引起的其他设计的变动有无相应手续。

4.3.3开发过程描述

开发过程设计完成后将设计转化为产品的一个过程，相当于生产企业的产品生产过程。

这个过程比较特殊，每个软件产品都是个性化的，不同开发人员实现同一功能时所采取的方法是不同的。

软件开发的实现过程无法完全使用标准化管理。

编码是过程控制的一个重要部分，但不能将其等同于过程控制的全部内容。

从项目计划开始，通过项目实施，直到产品正式发布这一过程的控制管理，包括对产品进行后期维护的过程，是质量管理体系中的过程控制。

4.3.3.1项目管理

在审核过程控制这个要素时，我们要重点关注的是项目的控制管理。

项目的质量不仅仅依靠几个经验丰富的软件工程师就可以得到保证，项目的进度控制、产品的可维护性、可扩展性等特性，也是很重要的指标。

在软件行业中人员流动频繁，如何控制软件质量，同项目管理的方法有很大关系。

项目管理包括对项目的工作计划、人日数的估算、人员安排、任务分配、进度控制、内外沟通协调、阶段检查、总结分析、配置管理等工作。

这些活动贯穿在整个项目之中，相互支撑，保证开发质量。

对于这些活动，企业应制定相关的管理制度加以规范，明确项目经理、开发人员、测试人员、质量保证人员的职责和接口，明确在各个阶段应进行的活动及所需形成的记录，并在各个重要的节点对项目进度、规范执行情况、记录使用的规范性、符合性进行检查和总结。

对于发现的问题应予以记录，并跟踪确认解决情况。

4.3.3.2编码过程控制

编码是整个软件开发过程中的一个特殊过程。

虽然在开发各个阶段中要进行单元测试、集成测试，试运行等各种测试，但并不能保证通过测试能发现所有的问题。

由于编码完全由人工实现，开发人员的经验，考虑问题的周全性，各个模块的协调性及现有技术的局限性等因素，会导致某些问题可能要在产品使用一段时间，或者要在特定的条件下才被发现，而发现的问题可能会影响产品的使用功能。

因此，对编码的过程确认十分重要。

也就是从编码开始到提交测试的过程中，通过各种方法减少人为差错，提高程序的标准化。

首先是设计文档要尽可能详细明确，减少因对文档理解不同产生误差的可能性。

其次应对软件工程师能力进行确认、开发前期对相关技术学习，提高其所需的技术能力。

再次，应制定编码规范并检查执行情况，保证代码符合规范要求并具有可读性。

还可以通过项目组内部代码的检查等方法进行确认。

通过这些方法使编码达到以下要求：

1）遵循开发流程，在设计的指导下进行代码编写。

2）代码的编写以实现设计的功能和性能为目标，要求正确完成设计要求的功能，达到设计的性能。

3）程序具有良好的程序结构。

4）程序可读性强，易于理解；方便调试和测试，可测试性好。

5）易于使用和维护；良好的修改性、扩充性；可重用性强、移植性好。

6）占用资源少，以低代价完成任务。

7）在不降低程序的可读性的情况下，尽量提高代码的执行效率。

4.3.3.3售后服务

除了产品开发之外，产品交付后所提供的服务也是很重要的。

对于软件企业而言，客户的开发要求，往往不是一次开发完成就终止了，一般都附加了相应的服务要求，如约定时间内的维护、定期的换版升级、功能完善等。

在审核的过程中也要关注售后服务这一服务提供的过程控制。

其中对问题的相应速度、解决问题的时间等是服务提供的重点。

4.3.3.4审核中应关注：

1）对项目管理流程的确定（客户是否有特殊要求：

如按客户流程实施）

2）项目的人日数估算与实际情况是否大体一致

3）项目计划中人员配备是否充分，职责是否明确（包括：

项目经理、开发人员、测试人员）

4）项目各阶段完成情况是否符合项目计划的进度要求

5）是否有对项目实施情况的控制管理，如周报，项目会议等

6）对项目实施过程中的变化的应对措施，如：

需求变更、人员变更、进度变更等。

变更是否有相应的纪录。

7）代码的编写是否符合企业的规范要求。

如有代码走查，是否有记录。

8）配置管理是否有计划，并按计划实施留有记录。

如：

代码备份、文档版本管理、人员权限管理等。

9）对安装调试阶段是否达到用户的要求，包括安装终端的数量，功能是否达到，对问题的解决，对客户的培训，文档资料的提交记录等。

4.4资源

4.4.1基础设施：

开发设备：

配备符合开发管理过程性能配置要求的硬件设备和软件环境，如：

服务器、个人电脑或终端、数据库、开发环境、开发工具、网络环境。

布线合理、电源稳定、网络通讯顺畅、网络信息安全，能保证工作的正常运行。

开发工作环境：

应保符合设备正常运行的温度、洁净程度要求，有适度空间、保持安静使开发人员有良好的工作环境。

测试要求：

测试工具、测试环境

4.4.2人力资源：

选用具有专业能力的人员（包括有经验的目管理人员、开发人员），并应对其进行企业的软件开发规范培训。

确立项目组的人员应根据项目要求选用适当人员。

确定培训需求应考虑软件产品开发和管理中用到的具体工具、技术、方法和计算机资源。

并保存适当的培训记录。

4.5外包的控制

对大型项目需将部分功能分包给其他软件开发企业的，应对外包过程进行控制。

1）选择的分包方应熟悉该领域的开发技术

2）信誉良好，状态稳定。

人员能力、管理水平较高，以保证产品质量及售后服务

3）重要或较复杂的项目，应选择有长期合作的分包方

4）对分包方提出的要求应尽可能明确

5）有专人负责对分包方管理、接口、沟通、监督，并贯穿整个设计开发过程，保证信息畅通，及时解决问题

6）明确双方的职责及分工

7）对分包方明确管理要求及提交的文档要求

8）对分包方提交的代码进行测试

4.6测试

测试是软件生存周期中的一个独立的、关键的阶段，也是保证软件质量的重要手段，测试可分为功能、性能测试，测试的内容之一是根据需求核对实际情况。

因此，进行测试前就应完成需求说明文档，据此判断开发实现的正确性与完备性。

目前常用的还是由人工方法来验证软件是否满足规定的需求（黑盒测试）。

测试阶段一般可分为单元测试、集成测试和系统验收测试。

每一阶段的测试都是为了保证下一阶段的工作能正常地进行，单元测试正常不等于集成测试没有问题，集成测试通过不等于在实际操作环境中正式运行没有问题。

在包含设计过程的软件开发中，软件测试的某些阶段与设计的某些阶段可能重合。

见设计验证（4.3.2.5）、设计确认（4.3.2.6）。

测试过程中应首先确认测试环境（7.6）是否与要求的环境相符，如果测试环境与实际环境不同，则有可能造成交付后产品使用发生错误。

为了提高检测出错误的几率，使测试能有计划地进行，并且能对软件质量有全面的评价，必须编写测试文件。

测试文件包括测试计划、测试用例、测试分析报告等，采用这些文件将会提高测试过程的每个阶段的能见度，极大地提高了测试工作的可管理性。

测试计划应在设计阶段就开始编写，应包括对每项测试活动的内容、进度安排、设计考虑、评价准则等。

其中测试用例是整个文档中很重要的一部分内容，在文档中所占的篇幅也最大，编制时应列出用于输入的具体值以及预期的输出结果。

测试用例不但应覆盖软件设计和用户文档中描述的所有功能，而且要包括有代表性的工作任务组合，另外还应考虑到正常操作、异常操作和临界值等各种不同情况。

测试产生的结果应进行记录，每个测试记录应包括足够的信息以方便重复测试，特别应详细描述产生错误（Bug）的操作步骤，使其有可再现性，便于开发人员寻找原因修改程序。

因发现问题或需求变更而对程序产生的修改，修改后应及时对修改部分进行确认。

文档功能和数据中所有的改变部分都应测试，并且考虑修改对其他环节可能造的影响，即受改变部分影响的所有未改变部分都应进行测试。

最后形成测试分析报告，对测试环境、测试结果的充分性、有效性应进行评价。

4.7其他应关注的内容

4.7.1追溯性要求

根据配置管理的要求，对软件开发过程生产的信息项如：

有关文档、数据、源代码等进行标识。

制定适当的命名规则，命名要求有唯一性和可追溯性。

对版本进行标识和跟踪管理，应能表明各个版本之间的关系便于检索和跟踪，必要时应可以恢复所需版本的代码。

是否遵循了变更的管理要求，相关的配置项是否进行了及时和正确地更新。

4.7.2顾客财产

软件企业的顾客财产包括：

软件、资料和硬件。

软件、资料一般为：

顾客的技术、知识产权、商业资料、数据信息等。

审核时应注意对这些顾客提供产品的接受方法和集成方法有无进行规定并执行，对涉及知识产权及保密要求资料是否进行控制。

如涉及到顾客现场调试、测试，则应关注对顾客数据信息的保护。

软件开发一般无需顾客提供硬件设备，但必要时如嵌入式软件开发过程中可能需要提供特殊硬件设备供测试时使用。

如企业为自主软件产品开发或者客户无信息保密要求的，根据实际情况可删减7.5.4条款。

4.7.3产品防护

防护：

应建立定期备份制度以保证灾难后的恢复。

建立病毒防护制度，防止因病毒引起的不必要损失。

交付：

在以媒体形式移交或电子传送形式移交时，应有适当的预防措施保护软件产品的完整性并免于在交付期损坏。

4.7.4软件的复制

如企业有成熟的通用性软件产品推向市场（如操作系统等），这个过程中涉及软件复制的过程（如刻制光盘、配置使用说明等）。

这只是设计、开发形成产品后的销售过程，相对简单，一般不称软件的生产。

有能力推出通用性产品的软件企业，基本都具有较强的技术实力，会有后续的产品开发。

通常情况下软件企业不会仅仅申请软件生产这个范围，因为这种描述不包括设计、开发的能力。

但对软件批量复制的过程，应注意对复制软件的质量检查以保证完整可用性，并应对销售产品给予标识（如序列号、版本号），以便对客户提供售后服务。

4.8删减原则

随着软件开发的国际化，越来越多的国际知名企业将中国作为其软件生产基地。

对于这部分软件外包的项目往往客户已经做好了初期的设计工作，所提交的文档非常详细，从界面到功能已经设计完成，甚至提供了底层调用工具及其接口。

只是将部分功能的编码工作交给企业开发，这样的企业可以删减7.3。

5其他规定

5.1对审核员的特殊要求

软件开发企业专业性较强，不同于一般传统生产企业，且各个部门均由可能涉及专业要素。

因此尽可能安排有专业背景的审核人员。

5.2建议的认证范围

5.2.1企业设计开发的软件局限于某一领域的：

应用软件的设计、开发

系统软件的设计、开发

5.2.2如企业设计开发的软件包含多个领域的：

软件的设计、开发

5.2.3如删减7.3则范围应不包括软件的设计，仅为：

软件的开发。

6附件

适用于本专业的法律法规、标准

序号

标准

名称

1

GB/T8566-2007

信息技术软件生存周期过程

2

GB/T8567-2006

计算机软件文档编制规范

3

GB/T9385-2008

计算机软件需求规格说明规范

4

GB/T9386-2008

计算机软件测试文档编制规范

5

GB/T11457-2006

信息技术软件工程术语

6

GB/T15532-2008

计算机软件测试规范

7

GB/T16260.1-2006

软件工程产品质量第1部分:

质量模型

8

GB/T16260.2-2006

软件工程产品质量第2部分:

外部度量

9

GB/T16260.3-2006

软件工程产品质量第3部分:

内部度量

10

GB/T16260.4-2006

软件工程产品质量第4部分:

使用质量的度量

11

GB/T17628-2008

信息技术开放式edi参考模型

12

GB/Z20156-2006

软件工程软件生存周期过程用于项目管理的指南

13

GB/T20157-2006

信息技术软件维护

14

GB/T20158-2006

信息技术软件生存周期过程配置管理

15

GB/T20917-2007

软件工程软件测量过程

16

GB/T20918-2007

信息技术存周期过程风险管理

一般软件开发行业的国家标准均为推荐性标准，可供企业参考使用，并不强求企业一定要遵照执行。

特别是为客户做外包的项目，应符合客户要求。