标准的代号和名称
- 我国国家的标准代号：强制性标准代号为GB、推荐性标准代号为GB/T、指导性标准代码为GB/Z，实物标准代号为GSB。
- 行业标准代号：由汉语拼音大写字母组成（如电力行业为DL）
- 地方标准代号：由DB加上省级行政区别代码的前两位
- 企业标准代号：由Q加上企业代号组成
软件工程产品质量第1部分GB/T16260
软件质量是软件特性的总和，软件满足规定或潜在用户需求的能力。该标准认为软件生命周期中，不同阶段关注不同的产品的质量，度量质量的方法与不同。
质量分类
软件分为内部质量（开发中）、外部质量（开发过程外）和使用质量（用户角度来看）三部分。
- 用户质量要求：用户对质量的需求可以是使用质量的度量、外部度量，也可以是内部度量。用户质量需求将成为产品确认准则。
- 外部质量需求：从外部视角来规定要求的质量级别，包括用户质量要求派生的需求（包括使用质量需求）。
- 内部质量需求：从产品的内部视角来规定要求的质量级别。内部质量需求用来规定中间产品的特性。这些可以包括静态和动态的模型，以及其他文档和源代码。
- 外部质量：是基于外部视角的软件产品特征的总和。
- 内部质量：是基于内部视角的软件产品特征的总和。
- 使用质量：是基于用户观点的质量。使用质量的获得依赖于必须的外部质量，而外部质量的获得依赖于取得必须的内部质量。
质量的模型框架
MTBF(平均无故障时间)=无故障总时间/故障次数，是指相邻两次故障之间的平均工作时间。
可用性=可用时间/总时间，是指在某特定时间段内，系统能正常工作的时间占总时间的百分比。“可用性”可用平均修复时间来简单替代。
使用质量的质量模型
使用质量的属性可分为四个特性：有效性、生产率、安全性和满意度。
度量
度量可分为内部度量和外部度量
- 内部度量
- 内部度量可以应用于设计和编码期间的非执行软件产品（标书、需求定义、规格说明、源代码）。内部度量用于测试软件产品的中间产品。使得用户、评价者、测试人员和开发者可以在软件产品可执行之前就能评价软件产品质量和尽早地提出质量问题
- 外部度量
- 外部度量测试、运行和观察可执行的软件或系统。外部度量使得用户、评价者、测试人员和开发人员可以在测试或操作期间评价软件产品质量。外部度量可以通过测量该软件产品作为其一部分的系统行为为测量软件产品的质量。外部度量只能在生存周期过程中的测试阶段和任何运行阶段使用。
软件文档管理指南GB/16680
项目周期中的文档
文档质量分级
文档评审
- 需求评审
- 进一步确认开发者和设计者忆了解用户要求什么，及用户从开发者一方了解某些限制和约束。
- 设计评审
- 通常安排两主要的设计评审——概要设计评审和详细设计评审
- 概要设计评审
- 主要详细评审每个系统组成部分的基本设计方法和测试计划。系统规格说明应根据概要设计评审的结果加以修改。
- 详细设计评审
- 主要评审计算机程序和程序单元测试计划。
文档编制计划
- 列出应编制文档的目录；
- 提示文档编制应参考的标准；
- 指定文档管理员；
- 明确保证文档质量的方法，了为确保文档内容的正确性、合理性，应采取一定的措施，如评审、鉴定等。
- 提供编制文档所需的条件，落实文档编写人员、所需经费及编制工具等。
- 绘制进度表，以图表形式列出在软件生存周期各阶段应产生的文档、编制人员、编制日期、完成日期、评审日期等。
文档归档
文档归档应满足：
- 归档的文档是经过鉴定或评审的；
- 文档应签署完整、成套、格式统一、字迹工整；
- 印制本、打印本以及各种报告应装订成册，并按规定进行编号和签署。
计算机软件质量保证计划规范GB/T 12504-1990
《计算机软件质量保证计划规范GB/T 12504-1990》主要考查的条目如下：
- 验证（Verfication）
- 验证是指确定软件开发周期中，一个给定阶段的产品是否达到在上一阶段确立的需求的过程。
- 确认（Validation）
- 确认是指在软件开发过程结束时，对软件进行评价以确定它是否和软件需求相一致的过程。
- 测试（Testing）
- 测试是指通过执行程序来有意识地发现程序中的设计错误和编码错误的过程。测试是验证和确认的手段之一。
为了确保软件的实现满足需求，至少需要下列基本文档：
- 软件需求规格说明书（Software Requirements Specification）
- 软件设计说明书（Software Design Description）
- 软件验证与确认计划（Software Verification and Validation Plan）
- 软件验证和确认报告（Software Verification and Validation Report）
- 用户文档（User Documentation）
- 其他文档
除基本文档以外，还应包括：项目实施计划、项目进展报表、项目开发各阶段的评审报表。
软件工程术语GB/T 11457 - 2006
《软件工程术语GB/T 11457-2006》主要考查的条目如下：- 软件开发方法是软件开发过程所遵循的方法和步骤，它是规则、方法和工具的集成，即支持开发，也支持以后的演化过程。
- 基线是已经过正式审核与同意，可用作下一步开发的基础，并且只有通过正式的修改管理步骤方能加以修改的规格说明或产品。配置管理有以下三种基线：功能基线、分配基线和产品基线。
- 确认（Validation）是在开发过程期间或结束时对系统或部件进行评价，通过检查和提供客观证据，以确定它是否满足特定预期用途的需求的过程。
- 验证（Verification）是评价系统或部件，以确定软件开发周期中一个给定阶段的产品是否满足在阶段的开始确立的需求的过程
- 审计是为评估工作产品或工作产品是否符合软件需求、规格说明、基线、过程、指令、代码以及合同和特殊要求而进行的一种独立的检查。
其他知识点
计算机软件可靠性和可维护性GB/T 14394-2008
- 制定并实施软件可靠性数据采集规程。
- 实施软件FRACAS
- 测量可靠性，分析现场可靠性是否达到要求；
- 跟踪用户满意程度；
- 用可靠性测量数据指导产品和工程过程的改进；
- 软件产品维护时执行适当的维护规程并参照基本文档中实施适用的管理活动
《中华人民共和国标准GB 1526-1989》
- 数据流程图：表示求解某一问题的数据通路。同时规定处理的主要阶段和所用的各种数据媒体。
- 程序流程图：表示程序中的操作顺序；
- 系统流程图：表示系统的操作控制和数据流。
- 程序网络图：表示程序激活路径和程序与相关数据的相互作用。在系统流程图中，一个程序可能在多个控制流程中出现；但在程序网络图中，每个程序仅出现一次。
- 系统资源图：表示适合于一个问题或一组问题求解的数据单元和处理单元的配置。
计算机软件需求说明编制指南GB/T 9385-2008
- 软件需求规格说明（Software Requirements Specifications，SRS）的编制者。
- SRS的基本要求：SRS是对要完成一定功能、性能的软件产品、程序或一组程序的说明。
- 在SRS中嵌入了设计:在SRS中嵌入设计说明，会过多的约束软件设计，并且人为地人的把具有潜在危险的需求放入SRS中。
- 在SRS在嵌入了一些项目要求：SRS应当是描写一个软件产品，而不是描述生产软件产品的过程。
软件开发的过程是由开发者和客户双方同意开发什么样的软件协议开始的。这种协议要使用SRS的形式，应该由双方联合起草。
计算机软件产品开发文件编制指南GB/T 8567-2006
- 软件生存周期与各种文件的编制。
- 在需求分析阶段内，由系统分析人员对被设计的系统进行系统分析，确定该软件的各项功能、性能需求和设计约束，确定对文件编制的要求。