【质量和软件的概念】

1 质量（quality）

ISO9001:2008 定义：质量为一组固有特性满足要求的程度。

（1）特性：可区分的特征

（2）要求：明示的、通常隐含的或必须履行的需求或期望

 

质量具有经济性、广义性、时效性、相对性。

 

产品：

ISO9000:2008 解释：产品是过程的结果。

产品可以分为 4 种类别：硬件、流程性材料、软件、服务或者它们的组合。

 

2  影响质量的因素

人、机（设备）、物（材料）、方法、环境

 

3  质量目标

在质量方面所追求的目的，是产品和工程质量在一定时间内可达到的水平。

 

4  质量成本

将产品质量保持在规定的质量水平上所需的有关费用。

（1）运行时质量成本：保证和提高产品质量支付的费用 + 因质量故障造成的损失费用

（2）外部质量保证成本：为用户提供所要求的客观证据所支付的费用。

 

5  质量管理

从技术层面和质量管理的角度去思考产品质量。

 

6  软件和软件产品

6.1 软件

软件 = 程序（数据） + 文档 + 服务

软件是：

（1）能够完成预定功能和性能的可执行的指令（计算机程序）；

（2）使得程序能够适当地操作信息的数据结构；

（3）描述程序操作和使用的文档。

 

6.2 软件产品组成部分

（1）程序代码           （2）帮助文件        （3）用户手册    （4）样本和示例           （5）标签

（6）产品支持信息    （7）图表和标志    （8）错误信息    （9）广告与宣传材料    （10）软件的安装

（11）软件说明文件（12）测试错误提示信息

 

6.3 软件产品和其他产品的不同

（1）软件是逻辑产品而不是实物产品

（2）软件的功能只能依赖于硬件和运行环境，以及人们对它的操作，才能得以体现

（3）对软件产品的要求比一般有形产品要复杂

（4）软件设计时的复杂性：功能多样性、实现多样性、能见度低、软件结构的合理性差

（5）软件是智力密集型产品

 

【软件生命周期】

1  软件开发项目组

项目管理经理：全程负责整个软件项目的开发

系统设计师：设计整个系统架构

程序员：负责设计、编写程序，并修改软件中的缺陷

软件测试员/测试师或质量保证员（QA）：负责找出并 告软件产品问题

结构管理和制作人员：负责将程序员编写的全部文档资料合并成一个软件包

 

2  软件生命周期质量管理

2.1 概述

传统生命周期（即瀑布模型）：

建造一个软件的相关工作分为三大阶段，每个阶段又可分为几个小阶段：

定义阶段：（1）计划（Planning） （2）需求分析（Requirement Analysis）

开发阶段：（3）设计（Design） （2）编码（Coding） （3）测试（Testing）

维护阶段：（6）运行与维护（Run and Maintenance）

 

2.2 需求分析

了解、分析客户需求，确定软件产品所能达到的目标。

应完成的文档：

（1）可行性 告

（2）项目初步开发计划

（3）需求规格说明

（4）用户手册概要

（5）测试计划

其他（软件生命周期每个阶段必有）：

（1）配置管理

（2）评审

 

2.3 设计

根据需求分析的结果，考虑如何在逻辑、程序上去实现所定义的产品功能、特性等。

设计过程将需求转换成软件表示，设计的结果将作为编码的框架和依据。

分类：

（1）概要设计和详细设计

（2）数据结构设计、软件体系结构设计、应用接口设计、模块设计、算法设计、界面设计等

 

概要设计

主要工作：

（1）建立系统总体结构，划分功能模块；

（2）定义各功能模块接口；

（3）数据库设计（如果需要的话）；

（4）指定组装测试计划

应完成的文档：

（1）概要设计说明书

（2）数据库设计说明书（如果有的话）

（3）组装测试嘉华

 

详细设计

主要工作：

（1）设计各模块具体实现算法；

（2）确定模块间的详细接口；

（3）指定模块测试方案

应完成的文档：

（1）详细设计说明书

（2）模块测试计划

 

2.4 编程

用一种或多种具体的编程工具进行编码，将设计转换成计算机可读的形式。

主要工作：

（1）编程；

（2）进行模块调试和测试；

（3）编写用户手册

应完成的文档：

（1）程序调试 告

（2）用户手册

 

2.5 测试

测试过程集中于软件的内部逻辑以及外部功能。

按不同的过程阶段分为：

（1）单元测试 （2）集成测试 （3）功能测试 （4）系统测试 （5）验证测试

 

2.6 维护

软件交付之后对软件的修改、升级等。

维护阶段重复定义和开发阶段的步骤，但是是在已有软件的基础上发生的。

分类：

（1）纠错性维护 （2）适应性维护 （3）增强性维护 （4）预防性维护

 

3 软件开发模型

软件开发模型是指软件开发全部过程、活动和任务的结构框架。

3.1 瀑布模型、大棒模型、边写边改模型

瀑布模型

优点：

可以保证整个软件产品较高的质量，保证系统在整体上的充分把握，使系统具备良好的扩展性和可维护性。

（1）易于理解

（2）调研开发的阶段性

（3）强调早期计划及需求调查

（4）确定了何时产生可交付的产品及何时进行评审和审查

（5）强调产品测试

缺点：

（1）依赖早期进行的需求调查，不能适应需求变化

（2）流程单一，开发中的经验得不到反馈和应用于本产品的开发中

（3）没有反映出开发的迭代本质

（4）不包含风险评估

（5）风险往往在后期才显露，失去及早纠正机会

 

大棒模型

在大棒模型中，既没有规格说明，也没有经过设计，软件随着客户的需要一次又一次地不断被修改。

优点：

简单，几乎无计划。

缺点：

开发过程非工程化，随意性大。最终的软件产品是什么样不可知。

关于测试：

有的较简单，有的则非常困难。

 

边写边改模型

在大棒模型的基础上考虑了产品的要求。

项目成员只有粗略的想法就进行简单的设计，然后开始漫长的编码、测试、修复这样一个循环的过程；在认为无法更精细的描述软件产品要求时，就发布产品。

优点：

能够较为迅速的展现成果，适合需要快速制作且用完就扔的小项目。

缺点：

其编码和测试可能将是长期的循环往复的过程。

 

探索测试：

当采用大棒模式或者边写边改模式时，不会有作为测试依据的各类文档，此时可以采用 探索测试。

探索测试将软件当作产品说明书来对待。分步骤地逐项探索软件特性，记录软件执行情况，详细描述功能。虽然无法完整测试软件，但可以进行系统测试，找到软件缺陷。

 

3.2 原型模式、快速应用（RAD）模式、螺旋模式、增量模式、迭代模式、混合模式

原型模式

在基本需求分析之后，快速开发出产品原型，基于这个原型，同客户沟通、交流，更好地了解客户需求，不断修改这个原型，到双方认可的程度，再做详细分析、设计和编程，最终开发出令客户满意的产品。

特点：

可以克服瀑布模型的一些缺点，使用户能够感受到实际的系统，减少由于软件需求不明确带来的开发丰县。

 

快速应用（RAD）模型

RAD（Rapid application development）模型通过使用基于构件的开发方法来缩短产品开发的周期，提高开发的速度。

RAD模型实现的前提是能做好需求分析，并且项目范围明确，这一点与原型模式相反。

 

增量模型

描述软件产品的不同阶段是按产品所具有的功能进行划分：

先开发主要功能或用户最需要的功能；然后随着时间推进，不断增加新的辅助功能或次要功能。

 

迭代模型

描述软件产品的不同阶段是按产品深度或细化的程度来划分：

先将产品的整个框架都建立起来，在系统的初期，已经具有用户所需求的全部功能；然后随着时间推荐，不断细化和完善已有的功能。

 

演化模型（evolutionary model）

针对事先不能完整定义需求的软件开发。

用户给出待开发系统的核心需求，当核心需求被实现后，用户提出反馈，以支持系统的最终设计和实现。

演化模型可以看作是重复执行的多个“瀑布模型”。

 

螺旋模型

螺旋模型是在瀑布模型和烟花模型的基础上，加入两者所忽略的风险分析所建立的一种软件开发模型。

主要思想：

在开始时不必详细定义所有细节，而是从小开始，定义重要功能，尽量实现，接受客户反馈，进入下一阶段，并重复上述过程，直到获得最终产品。

每一螺旋（开发阶段）包括 5 个步骤：

（1）确定目标，选择方案和限制条件

（2）对方案风险进行评估，并能解决风险

（3）进行本阶段的开发和测试

（4）计划下一阶段

（5）确定进入下阶段的方法

优点：

严格的全过程风险管理；强调各开发阶段的质量；提供机会评估项目是否有价值继续下去

缺点：

可能难以使用户相信演化方法是可控的；项目的成功依赖于风险评估技术，如果一个大的风险未被发现和管理，就会出现问题。

 

混合模式/过程开发模式/元模式

将几种不同模式组合成一种混合模式，允许一个项目能沿着最有效的路径发函。

 

3.3 敏捷开发

敏捷宣言

个体和交互             胜过    过程和工具

可以工作的软件      胜过    面面俱到的文档

客户合作                 胜过    合同谈判

响应变化                 胜过    遵循计划

 

敏捷开发

敏捷方法论采用迭代/增量开发的过程模型

（1）是一种以用户的需求进化为核心、迭代、循序渐进的开发方法

（2）组织上，软件项目的构建被切分成多个子项目，每个子项目的成果都经过测试，具备集成和可运行的特征

（3）时间上，迭代开发把软件生命周期划分成很多个小周期，每一次迭代都可以生成一个可运行、可验证的版本，并确保软件不断地增加新的价值。

简单来说：

敏捷开发就是把一个大项目分为多个相互联系，但也可独立运行的小项目，并分别完成，在此过程中软件一直处于可使用状态。

 

敏捷开发由几种轻量级的软件开发方法组成：

极限编程（XP）、Scrum、精益开发（Lean Development）等等。

 

 

极限编程（XP）

主要目的是降低需求变化的成本

定义了一套简单的开发流程

提倡互动交流、反馈、简单、勇气、团队

12个最佳实践：核心做法为小规模、频繁的版本发布、短迭代周期、风险评估

 

精益开发

核心思想：

查明和消除浪费。在软件开发过程中，错误（bugs）、没用的功能、等待以及任何对实现结果没有益处的东西都是浪费，浪费及其源头必须被分析查明，然后设法消除。

 

Scrum

Scrum是一个敏捷开发框架，由一个开发过程、几种角色以及一套规范的实施方法组成。

 

Scrum定义了4种主要角色：

（1）产品拥有者（Product Owner）

负责产品的远景规划，平衡所有利益相关者（Stakeholder）的利益，确定不同的产品需求积压的优先级等。

是开发团队和客户/最终用户之间的联络点。

（2）利益相关者（Stakeholder）

该角色与产品之间有直接或间接的利益关系，通常是客户/最终用户代表，负责收集编写产品需求，审查项目成果等。

（3）Scrum专家（Scrum Master）

负责直到开发团队进行Scrum开发与实践，是开发团队与产品拥有者之间的联络点。

（4）团队成员（Team Member）

即项目开发人员

 

Scrum开发模型：

backlog：可以预知的所有任务，包括功能性的非功能性的所有任务。

sprint：一次迭代开发的时间周期。在这个时间按内，开发团队需要完成一个制定的backlog，并且最终结果是一个增量的、可以交付的产品。

sprint backlog：一个sprint周期内要完成的任务

time-box：一个用于开会的时间段。比如每个daily scrum meeting的time-box为15分钟。

sprint planning meeting：产品Owener和团队成员在启动每个sprint前召开，一般为一天时间（8 h）

daily scrum meeting：开发团队成员召开，一般为15分钟。每个开发成员向ScrumMaster汇 三个项目：今天完成了什么了什么障碍无法继续下去要做什么p>

sprint review meeting：在每个print结束后，开发团队将这个sprint的工作成果演示给产品Owner和其他相关人员，一般为4 h 。

sprint restropective meeting：团队开发的内部人员对刚结束的Sprint进行总结，一般为3 h。

 

实施Scrum的过程：

（1）确定Sprint Backlog

（2）召开sprint planning meeting

（3）进入sprint开发周期，在这个周期内，每天需要召开Daily Scrum meeting

（4）整个sprint周期结束后，召开sprint review meeting，展示成果

（5）团队成员召开sprint retrospective meeting，回顾问题和经验

（6）进入下一次sprint。

 

敏捷开发的问题

敏捷开发只适合小型团队、适合开源 区，而不适合大型软件企业；在软件开发过程的全局上，更适合采用统一过程（RUP）、微软软件开发框架（MSF），而在局部、细节，吸收敏捷思想。

敏捷不能解决问题，只能将问题暴露的更早。

 

3.4 MSF模型

MSF(Microsoft Solution Framework) 微软软件开发框架

MSF基本原则

（1）打造开放的通信。

（2）为了实现共同的愿景努力工作。

（3）授权团队成员。

（4）建立明确的责任和共同分担的责任。

（5）交付增量价值。

（6）保持灵活、期望并适应变化。

（7）进行投入来提高质量。

（8）从所有经验中学习。

（9）与内部和外部客户合作。

（未完）

 

3.5 RUP

RUP(Rational Unified Process) 统一过程，是一个面向对象且基于 络的程序开发方法论。

RUP是理解性的软件工程工具——把开发中面向过程的方面（例如定义的阶段、技术和实践）和其他开发的组件（例如文档、模型、手册以及代码等）整合在一个统一的框架内。

 

二维的软件开发模型

传统的软件开发模型是一个单维的模型，开发工作划分为多个连续的阶段，在一个时间段内只能做某一阶段的工作。

RUP软件开发生命周期是一个二维的软件开发模型：

横轴通过时间组织，是过程展开的生命周期特征，体现开发过程的动态结构；

纵轴以内容来组织，为自然的逻辑活动，体现开发过程的静态结构。

（未完）

 

3.6 软件建模

模型

模型的实质：对现实的简化。

 

建模方法

两种最常用的建模方法：基于算法建模和面向对象建模

随着需求的变化和系统的增长，前者建立的系统难以维护。

在面向对象的建模方法中，主要的模块是对象或者类。

 

UML(Unifed Modeling Language) 统一建模语言

（1）结构类模型图

用四种模型图描述系统应用的静态结构：类图、对象图、组件图和配置图

（2）行为类模型图

用五种模型图描述系统动态行为的各个方面：用例图、序列图、行为图、协作图和状态图

（3）模型管理类模型图

用三种模型图来组织和管理各种应用模型：软件包、子系统和模型

 

4 软件开发与软件测试关系

4.1 测试与各开发阶段的关系

 

4.2 完成的软件开发流程

 

【软件质量的定义】

 1 软件质量的定义

ANSI/IEEE Std 72901983 将软件质量定义为：与软件产品满足规定的和隐含的需求的能力有关的特征或特性的全体

M.J.Fisher 将软件质量定义为：所有描述计算机软件优秀程度的特性的组合

GB/T6583 – ISO 8402(1994) 将软件质量定义为：反映实体满足明确的隐含需要的能力和特性总和。

软件质量还被定义为：客户满意度、一致性准则、软件质量度量、过程质量观

软件质量和一般产品质量类似，被定义为3A特性：可说明性（Accountability）、有效性（Availability）、易用性（Accessibilty）

RUP中，软件质量被定义为具有以下三个维度：功能（Functionality）、可靠（Reliability/Dependability）、性能（Performance）

简言之，软件质量是软件一些特性的组合，它依赖软件的本身。

 

站在不同的角度看待软件质量

用户

如何使用软件，使用效果如何，软件性能如何

软件开发团队

生产出满足质量要求的软件，中间件的质量，如何运用最少的资源、最快的进度生产出质量最优的产品

软件维护者

软件维护特性

企业的管理层

总体利益和长远利益

 

软件质量反映出的问题

（1）软件需求是度量软件质量的基础。

不符合需求的软件不具备质量。

（2）规范化的标准定义了一组开发准则，用来指导软件人员用工程化的方法来开发软件。

如果不遵守开发准则，软件质量就得不到保证。

（3）往往有一些隐含的需求没有显式地提出来。

如果软件只满足那些精确定义了的需求，而没有满足这些隐含的需求，软件质量也不能保证。

 

2 软件质量特性

软件质量特性反映了软件的本质，讨论一个软件的质量，问题最终要归结到定义软件的质量特性。

软件质量可由以下质量特性来定义：

（1）功能性

软件所实现的功能达到它的设计规范和满足用户需求的程度

（2）效率

在规定条件下，用软件实现某种功能所需的计算机资源（包括时间）的有效程度

（3）可靠性

在满足一定条件的应用环境中，软件能够正常维持其工作的能力

（4）安全性

为了防止意外或人为的破坏，软件应具备的自身保护能力

（5）易使用性

对于一个软件，用户在学习、操作和理解过程中所做努力的程度

（6）可维护性

当环境改变或软件运行发生故障时，为了使其恢复正常运行所做努力的程度

（7）可扩充性

在功能改变和扩充情况下，软件能够正常运行的能力

（8）可移植性

为使一个软件从现有运行平台向另一个运行平台过渡所做努力的程度

（9）重用性

整个软件或其中一部分能作为软件包而被再利用的程度

 

3 软件生存期与质量特性

从用户的角度看，软件的生存期可分为三个阶段：

（1）初期运用：运行新开发的软件产品

（2）维护与扩充：在运行过程中修改缺欠的内容；为了进一步使用，根据运行环境的变化做功能上和性能上的扩充

（3）移植和连接：把原有平台上运行的软件向其他新的运行环境转移、或者组成软件包以便宠用、或者与其他软件进行连接

 

软件生存期与质量特性的关系

 

【影响软件质量的主要因素】

影响软件质量的三个主要因素：

开发软件产品的组织、开发过程、开发使用的方法和技术

 

【软件质量模型】

质量模型是用来描述质量需求以及对质量进行评价的理论基础。

1 Boehm质量模型

2 McCall质量模型

 

3 ISO软件质量模型

3.1 1991版

概述

1985年，国际标准化组织（ISO）建议，软件质量度量模型由三层组成：

（1）高层软件质量需求评价准则（SQRC）

从用户观点出发，由8个要素组成。

（2）中层软件质量设计评价准则（SQDC）

从开发者观点出发，由23个评价准则组成。

（3）低层软件质量度量评价准则（SQMC），由各使用单位根据实际情况决定。

 

质量特性和质量子特性

1991年，ISO发布了质量特性的国际标准 ISO/IEC9126:1991

将质量特性降为6个：

功能性、可靠性、可维护性、效率、可使用性、可移植性

并定义了21个质量子特性：

 

软件质量评价

评价目的：

（1）确定产品是否通过验收，确定何时发布产品

（2）与其他类似产品相比较，对产品进行选择

（3）在使用该产品时评估其正面及负面的影响

（4）确定何时优化或替代该产品

评价步骤：

（1）质量要求定义

根据软件需求定义软件质量特性和可能的子特性，将用户的质量要求转化为软件开发不同阶段的质量要求，并及时分解为软件产品组成部分的质量要求。

（2）评价准备

a. 选择质量度量

b. 定义等级

c. 评估准则定义

（3）评价过程

a. 测量：把选定的度量应用到软件产品上

b. 评级：根据等级定义确定某一测量值的等级

c. 评估：将评出的等级加以归纳，给出软件产品质量 告；管理人员比较质量与时间、成本等，根据管理准则决定该产品是否通过验收或者是否发行

注意：给出评价结果时，必须说明评价所使用的度量、等级以及准则。

 

3.2 2001版

2001年，将1991年发布的ISO/IEC9126标准分为了两部：

（1）ISO/IEC9126 《信息技术 软件产品质量》

（2）ISO/IEC14598 《信息技术 软件产品评价》

 

ISO 9126

修订后的 ISO 9126(GB/T 16260) 描述新的软件质量模型，分为4个部分：

（1）ISO 9126-1:2001 第1部分：质量模型

（2）ISO 9126-2:2002 第2部分：外部质量度量

外部度量测量包含该软件的计算机系统的行为。只在生存周期过程中的测试阶段和任何运行阶段使用。

（3）ISO 9126-3:2003 第3部分：内部质量度量

内部度量测量软件本身。可用于开发阶段的非执行软件产品（例如标书、需求定义、设计规格说明、源代码等），为用户提供测量中间可交付项的质量的能力，从而可以预测最终产品的质量，使得用户尽可能在开发生存周期的早期察觉质量问题并采取纠正措施。

（4）ISO 9126-4:2004 第4部分：使用质量度量

使用质量度量测量在指定条件中使用该软件的效果。在真实的系统环境下获得。

 

ISO 14598

ISO/IEC 14598(GB/T 18905) 从软件开发者、软件的需方和软件的独立评价者三种不同的角度分别给出了软件产品评价过程模型。

 

3.3 SQuaRE(System and Software product Quality Requirements and Evaluation) 软件产品质量要求和评价

SQuaRE系列标准的编 为 25000 – 25050

3.3.1 SQuaRE系列国际标准 与 ISO/IEC 9126(GB/T 16260)、ISO/IEC 14598(GB/T 18905)的主要差异：

SQuaRE相比较原系列标准，范围更广、内容更全面，其由 质量管理、质量模型、质量度量、质量需求、质量评价 五个主要部分 和 SQuaRE扩展部分 组成。

 

3.3.2 SQuaRE分部组成

ISO/IEC 2500n 质量管理分部

ISO/IEC 2501n 质量模型分部

ISO/IEC 2502n 质量测量分部

ISO/IEC 2503n 质量要求分部

ISO/IEC 2504n 质量评价分部

ISO/IEC 25050-25099 保留用于SQuaRE扩展的国际标准和技术 告：目前包括了就绪可用软件的质量要求和易用性测试 告行业通用格式。

 

3.3.3 SQuaRE系列标准

整个SQuaRE系列标准由十几个文件组成。

（1）ISO/IEC 2500n

ISO/IEC 25000 SQuaRE指南

（2）ISO/IEC 2501n

ISO/IEC 25010 系统与软件质量模型：

描述了软件产品内部和外部质量以及使用质量的模型。该文件给出软件内部和外部质量的特性和子特性以及使用质量的特性。

（3）ISO/IEC 2502n

……

（4）ISO/IEC 2503n

……

（5）ISO/IEC 2504n

……

（6）ISO/IEC 25050 – 25099

ISO/IEC 25051 就绪可用软件产品（RUSP）的质量要求和测试细则

该标准确立了RUSP的质量要求，测试RUSP的测试计划、测试说明等文档要求和RUSP的符合性评价细则，适用于软件产品的供方、需方、最终用户和第三方测评认证机构等。

 

【我国的软件质量标准】

1 采标

我国分别于2002年、2006年将 ISO/IEC 14598、ISO/IEC 9126 引入国内，研制了 GB/T 18905《软件工程产品评价》、GB/T 16260 《软件工程产品质量》 国家系列标准。

2010年，我国进一步制定了等同采用SQuaRE的两个标注，分别是 GB/T 25000.1-2010 《软件工程软件产品质量要求于评价SQuaRE指南》、GB/T 25000.51-2010 《软件工程软件产品质量要求与评价（SQuaRE） 商品现货（COTS）软件产品的质量要求和测试细则》

目前，

ISO/IEC 25051:2006 已经升级为 ISO/IEC 25051-2014

ISO/IEC 25000.51-2010 已经升级为 ISO/IEC 25000.51-2016

 

2 自主研制的国家标准

GB/T 16260 系列标准并未给出具体的度量方法，度量指标获取方法也不明确，造成实际使用过程中难以操作。

因此，结果我国的实际应用情况，依据GB/T 16260标准体系，制定了GB/T 16260的扩展标准，分为指标体系、度量方法和测试方法三个部分。