|
|
|
软件管理标准包含四个，分别是《GB/T 12505—1990计算机软件配置管理计划规范》《GB/T 16260—2006软件工程产品质量》《GB/T 12504—1990计算机软件质量保证计划规范》以及《GB/T 14394—2008计算机软件可靠性和可维护性管理》，下面分别对这四个标准进行简述。
|
|
|
|
|
|
本规范规定了在制定软件配置管理计划时应该遵循的统一的基本要求。
|
|
|
|
|
|
软件生存周期是指从软件系统设计对软件系统提出应用需求开始，经过开发，产生出一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。期间经历系统分析与软件定义、软件开发以及系统的运行与维护三个阶段。其中软件开发阶段一般又分为需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试、安装与验收六个阶段。
|
|
|
|
|
|
软件配置是指一个软件产品在软件生存周期各个阶段所产生的各种形式（机器可读和人工可读）和各种版本的文档、程序及其数据的集合。该集合中的每一个元素称为该软件产品软件配置中的一个配置项。
|
|
|
|
|
|
软件开发库是指在软件生存周期的某一个阶段，存放与该阶段软件开发工作有关的计算机可读信息和人工可读信息的库。
|
|
|
|
|
|
软件受控库是指在软件生存周期某一阶段结束时，存放作为阶段产品而发布的、与软件开发工作有关的计算机可读信息和人工可读信息的库。软件配置管理就是对软件受控库中的各个软件项进行管理，因此软件受控库也称为配置管理库。
|
|
|
|
|
|
软件产品库是指在软件生存周期的组装与系统测试阶段结束后，存放最终产品而后交付给用户运行或在现场安装的软件的库。
|
|
|
|
|
|
功能基线是指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发软件系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是指由下级申请上级同意，或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标识。
|
|
|
|
|
|
指派基线是指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明，指派基线是最初批准的指派配置标识。
|
|
|
|
|
|
产品基线是指在软件组装与系统测试阶段结束时，经过正式评审和批准的有关开发软件产品全部配置项的规格说明。产品基线是最初批准的产品配置标识。
|
|
|
|
|
|
该标准包括四部分内容，分别为：质量模型、外部度量、内部度量和使用质量的度量。
|
|
|
|
软件产品质量模型主要用于评价软件产品和中间产品，它可以根据层次分解为由特性和子特性组成的质量模型。需要注意的是该模型的应用也应该结合具体的环境而有所增删。
|
|
|
|
软件产品质量模型以阶段映射的方式描述了过程质量和产品质量之间的关系，其中产品质量又分为内部质量、外部质量和使用质量三个质量视角。
|
|
|
|
软件产品质量模型针对外部质量和内部质量，将其进一步映射为六类质量特性以及对应的子特性，描述如下：
|
|
|
|
|
|
功能性是指当软件在指定条件下使用时，软件产品提供满足明确和隐含要求的功能的能力。
|
|
|
|
.适合性：指软件产品为指定的任务和用户目标提供一组合适的功能的能力。
|
|
|
|
.准确性：指软件产品提供具有所需精度的正确或相符的结果或效果的能力。
|
|
|
|
.互操作性：指软件产品与一个或更多的规定系统进行交互的能力。
|
|
|
|
.安全保密性：指软件产品保护信息和数据的能力，以使未授权的人员或系统不能阅读或修改这些信息和数据，而不拒绝授权人员或系统对它们的访问。
|
|
|
|
.功能性的依从性：指软件产品遵循与功能性相关的标准、约定或法规以及类似规定的能力。
|
|
|
|
|
|
可靠性是指在指定条件下使用时，软件产品维持规定的性能级别的能力。
|
|
|
|
.成熟性：指软件产品为避免由软件内部的故障而导致失效的能力。
|
|
|
|
.容错性：指在软件出现故障或者违反其指定接口的情况下，软件产品维持规定的性能级别的能力。
|
|
|
|
.易恢复性：指在失效发生的情况下，软件产品重建规定的性能级别并恢复受直接影响的数据的能力指。
|
|
|
|
.可靠性的依从性：指软件产品遵循与可靠性相关的标准、约定或法规的能力。
|
|
|
|
|
|
易用性是指在指定条件下使用时，软件产品被理解、学习、使用和吸引用户的能力。
|
|
|
|
.易理解性：指软件产品使用户能理解软件是否合适以及如何能将软件用于特定任务和使用条件的能力。
|
|
|
|
|
|
.易操作性：指软件产品使用户能操作和控制它的能力。
|
|
|
|
|
|
.易用性的依从性：指软件产品遵循与易用性相关的标准、约定、风格指南或法规的能力。
|
|
|
|
|
|
效率是指在规定条件下，相对于所用资源的数量，软件产品可提供适当性能的能力。
|
|
|
|
.时间特性：是指在规定条件下软件产品执行其功能时提供适当的响应和处理时间以及吞吐率的能力。
|
|
|
|
.资源利用性：指在规定条件下，软件产品执行其功能时，使用合适数量和类别的资源的能力。
|
|
|
|
.效率依从性：指软件产品遵循与效率相关的标准或约定的能力。
|
|
|
|
|
|
维护性是指软件产品可被修改的能力。修改可能包括修正、改进或软件对环境、需求和功能规格说明变化的适应。
|
|
|
|
.易分析性：指软件产品诊断软件中的缺陷或失效原因，或识别待修改部分的能力。
|
|
|
|
.易改变性：指软件产品使指定修改可以被实现的能力。
|
|
|
|
.稳定性：指软件产品避免由于软件修改而造成意外结果的能力。
|
|
|
|
|
|
.维护性的依从性：指软件产品遵循与维护性相关的标准或约定的能力。
|
|
|
|
|
|
可移植性是指软件产品从一种环境迁移到另外一种环境的能力。
|
|
|
|
.适应性：指软件产品毋需采用额外的活动或手段就可适应不同指定环境的能力。
|
|
|
|
|
|
.共存性：指软件产品在公共环境中同与其分享公共资源的其他独立软件共存的能力。
|
|
|
|
.易替换性：指软件产品在同样环境下，替代另一个相同用途的指定软件产品的能力。
|
|
|
|
.可移植性的依从性：指软件产品遵循与可移植性相关的标准或约定的能力。
|
|
|
|
|
|
|
|
有效性是指软件产品在指定的使用环境下，使用户能正确和完全地达到规定目标的能力。
|
|
|
|
|
|
生产率是指软件产品在指定的使用环境下，使用户为达到有效性而消耗适当数量的资源的能力。
|
|
|
|
|
|
安全性是指软件产品在指定使用环境下，达到对人类、业务、软件、财产或环境造成损害的可接受的风险级别的能力。
|
|
|
|
|
|
满意度是指软件产品在指定的使用环境下，使用户满意的能力。
|
|
|
|
|
|
软件质量保证计划规范了在制定软件质量保证计划时应该遵循的统一的基本要求，适用于软件特别是重要软件质量保证计划的制定工作。
|
|
|
|
|
|
软件生存周期是指从提出应用需求开始，经过开发，产生一个满足需求的计算机软件系统，然后投入运行，直至该软件系统退役为止。此周期一般分为需求分析、概要设计、详细设计、编码与单元测试、组装与系统测试及安装与验收等六个阶段。
|
|
|
|
|
|
验证是指确定软件开发周期中的一个给定阶段的产品是否达到上一阶段确立的需求的过程。
|
|
|
|
|
|
确认是指在软件开发过程结束时对软件进行评价以确定它是否和软件需求相一致的过程。
|
|
|
|
|
|
测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。
|
|
|
|
|
|
质量是反映产品或服务满足明确或隐含需求能力的特征和特性的总和。
|
|
|
|
|
|
质量保证指为使软件产品满足规定需求所进行的一系列有计划的必要工作。
|
|
|
|
|
|
这些文档包括软件需求规格说明书、软件设计说明书、软件验证与确认计划、软件验证和确认报告、用户文档、其他文档（比如项目实施计划、项目进展报告、各阶段评审报表、项目开发总结等）。
|
|
|
|
|
|
软件质量保证小组属于总体组领导，由总体组代表、项目的软件工程小组代表、项目的专职质量保证人员、项目的专职配置管理人员以及子系统软件质量保证人员组成。
|
|
|
|
|
|
评审小组原则上由项目总体小组成员或特邀专家担任评审组长，项目委托单位、用户代表、质量保证人员、软件开发单位和上级主管部门的代表以及其他人员作为小组成员。项目评审小组可以不设副组长；项目开发组长或其代表可作为评审组的成员，但不能担任评审组的组长或副组长。
|
|
|
|
|
|
文档质量度量准则包括完备性（在开发阶段结束时，保证文档齐全）、正确性、简明性、可追踪性、规范性。
|
|
|
|
|
|
在验收时，允许用户或用户委托的专家对所要验收的软件进行综合检查，以验证代码和设计文档的一致性、接口规格说明之间的一致性、设计实现和功能需求的一致性、功能需求和测试描述的一致性。
|
|
|
|
|
|
在软件发布前进行功能检查，以确认已满足实现软件需求规格说明书中规定的所有需求。
|
|
|
|
|
|
|
|
|
|
配置检查包括编制有关软件配置的条款，规定用于标识软件产品、控制和实现软件的修改、记录和报告修改实现的状态以及评审和检查配置管理工程等四个方面的活动。此外还必须规定用以维护和存储软件受控版本的方法和措施，必须规定对所发现的软件问题进行报告、追踪和解决的步骤，并指出实现报告、追踪和解决软件问题的机构及其职责。
|
|
|
|
|
|
用户文档必须指明成功运行该软件所需要的数据、控制命令以及运行条件等内容；必须指明所有的出错信息、含义及其修改方法；还必须描述将用户发现的错误或问题通知项目承办单位（或软件开发单位）或项目委托单位的方法。
|
|
|
|
|
|
在概要设计阶段结束后必须继续概要设计评审，以评价软件设计说明书中所描述的软件概要设计在总体结构、外部接口、主要部件功能分配、全局数据结构以及各主要部件之间的接口等方面的适合性。
|
|
|
|
补充说明：《GB/T 12505—1990计算机软件配置管理计划规范》和《GB/T 12504计算机软件质量保证计划规范》被国标委（公告2005年第146号文）废止，废止后没有替代规范。
|
|
|
|
|
|
计算机软件可靠性与可维护性管理标准规定了软件产品在其生命周期内如何选择适当的软件可靠性和可维护性管理要素，并指导可靠性大纲和可维护性大纲的制定和实施。
|
|
|
|
.软件可靠性大纲：满足规定的可靠性要求所采取的技术和管理方法的文档，描述要做的工作，所需要的资源、使用方法、采用的过程、要满足的进度表和项目组织方法。
|
|
|
|
.软件可维护性大纲：满足规定的可维护性要求所采取的技术和管理文档，描述要做的工作，所需要的资源、使用方法、采用的过程、要满足的进度表和项目组织方法。
|
|
|
|
.软件FRACAS（Software Failure Reporting Analysis and Corrective Action System）：软件失效报告、分析和纠正措施系统是一个闭环控制系统，它将软件的失效加以记录、报告，找出失效原因，采取纠正措施。
|
|
|
|
软件生存周期五个基本过程的可靠性和可维护性管理分别如下：
|
|
|
|
|
|
需方确定要获取的软件产品的可靠性和可维护性要求，确保要求是合理的、可行的、可验证的，并有相应的资源保证，进而在制定标书、选择供方过程中加以体现，并且依照要求管理获取过程，最终验收软件产品的可靠性和可维护性是否达到预期要求。
|
|
|
|
|
|
供方在投标书中对可靠性和可维护性进行说明以答复需方要求，并反映在可行性研究报告、合同中，通过评定后确定为管理和保证软件产品的可靠性和可维护性所需的过程、规程和资源，确保在软件开发过程中及时、适当地处理可靠性和可维护性要求，直到软件产品满足要求并交付给需方。
|
|
|
|
|
|
开发者负责实施在软件产品的需求分析、设计、编码、集成、测试以及有关的安装和验收等活动中对可靠性和可维护性的要求。
|
|
|
|
|
|
在软件运作过程和维护过程中，应分析和提高软件的可靠性：
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
.软件生存周期各过程所包含的与可靠性和可维护性相关的要素。
|
|
|
|
|
|
|
|
|
|
|
|
.时间进度、经费与其他资源，存储空间与运行时间，程序设计语言，软件运行的软硬件环境等各种限制条件。
|
|
|
|
|
|
|
|
在需求分析阶段，应建立软件产品的可靠性和可维护性大纲要素，两项大纲的目标应确保满足合同要求，大纲目标由一系列与每项大纲要素有关的任务组成，应明确每项任务的负责人，并提供一个任务实施初步日程表，当情况变化或者出现偏差时大纲应根据需要加以修改。
|
|
|
|
|
|
在可行性研究与计划和需求分析阶段应分析运行环境，并在概要设计阶段和详细设计阶段进行必要的修改，同时要注意运行环境的变化对软件可靠性和可维护性的影响。
|
|
|
|
|
|
在可行性研究与计划阶段，应对软件的可靠性和可维护性要求进行可行性论证，对于合同中提出的可靠性和可维护性要求应根据软件符合规定标准和规范的能力进行评审和论证。
|
|
|
|
|
|
在需求分析阶段，应选定适当的软件规范和准则。若没有适当的软件规范和准则可遵循，则应自行制定相应的规则。
|
|
|
|
|
|
在软件开发过程中各个阶段需进行有关可靠性和可维护性分析，并编写相应的报告。
|
|
|
|
|
|
|
|
|
|
根据合同要求和数据管理目标，应确定文档和数据要求的范围。
|
|
|
|
|
|
要及时制定培训计划。培训计划应与软件开发计划、维护要求、运行支持策略协调一致。
|
|
|
|
|
|
|
