文章目录
一、功能性：
二、可靠性：产品在规定的条件下，在规定的时间内完成规定功能的能力
三、易用性：在指定使用条件下，产品被理解、 学习、使用和吸引用户的能力
四、效率性：在规定台条件下，相对于所用资源的数量，软件产品可提供适当性能的能力
五、软件维护性："四规"， 在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力
六、软件可移植性：从一种环境迁移到另一种环境的能力

一、功能性：
1、适合性：软件是否提供了相应的功能

2、准确性：软件提供的功能是否正确（用户需要的）

3、互操作性：产品与产品之间交互数据的能力,例如word对其他文档的支持能力

4、保密安全性：允许经过授权的用户和系统能够正常的访问相应的数据和信息，禁止未授权的用户访问…

5、功能性的依从性：国际/国家/行业/企业 标准规范一致性
二、可靠性：产品在规定的条件下，在规定的时间内完成规定功能的能力
1、成熟性：软件产品为避免软件内部的错误扩散而导至系统失效的能力（主要是对内错误的隔离）,exception等的处理

2、容错性：软件防止外部接口错误扩散而导致系统失效的能力（主要是对外错误的隔离）

3、易恢复性：系统失效后，重新恢复原有的功能和性能的能力。

4、可靠性的依从性
三、易用性：在指定使用条件下，产品被理解、 学习、使用和吸引用户的能力
1、易理解性：软件交互给用户的信息时，要清晰，准确，且要易懂，使用户能够快速理解软件。

2、易学性：软件使用户能学习其应用的能力。

3、易操作性：软件产品使用户能易于操作和控制它的能力。

4、吸引性：

5、易用性的依从性：
四、效率性：在规定台条件下，相对于所用资源的数量，软件产品可提供适当性能的能力
1、时间特性：平均事务响应时间，吞吐率，TPS（每秒事务数）. 软件处理特定的业务请求所需要的响应时间。

2、资源利用性：CPU 内存 磁盘 IO 网络带宽 队列 共享内存. 软件处理特定的业务请求所消耗的系统资源。

3、效率依从性：
五、软件维护性：“四规”， 在规定条件下，规定的时间内，使用规定的工具或方法修复规定功能的能力
1、易分析性：分析定位问题的难易程度

2、易改变性：软件产品使指定的修改可以被实现的能力

3、稳定性：防止意外修改导致程序失效

4、易 测试性：使已修改软件能被确认的能力

5、维护性的依从性
六、软件可移植性：从一种环境迁移到另一种环境的能力
1、适应性：适应不同平台

2、易安装性：被安装的能力

3、共存性：软件产品在公共环境中与其它软件分享公共资源共存的软件。

4、易替换性: 软件产品在同样的环境下，替代另一个相同用途的软件产品的能力。

5、可移植性的依从性
参考文章：软件质量模型的六大特性27个子特性

程序更应该注重可移植性


  
一：问题引导 
  
  
1.  什么是可移植性？  
  
  

    
所谓可移植性，即代码编写一次，简单地做一些修改或者原封不动地就能运行在其他的体系架构机器上而继续发挥余热，充分利用前期工作结果的效用，为软件开发提供了很好的复用模块，提升开发效率。
  
  
  
2. 为什么移植性很重要？ 
  
  

    
I.  信息革命走过的时间不过半个多世纪，其中发生了翻天覆地的变化，从 intel 公司于1971年推出的intel 4004微处理器开始，到现在的Core i7系列，其中的晶体管的数量从2250个到几十亿的变化，呈现几何倍数增长，其复杂都可见一斑，x86如此，其他体系架构亦是如此，什么MIPS、PowerPC、ARM等等。
    
    
II.  硬件的发展早于现代意义上的软件发展。软件最早是以二进制指令序列来体现的，后来发明了助记符形式的编程方法-汇编方法，汇编相对于二进制而言，更友好和更易维护，但它还是和具体的体系架构信息紧密联结。后来到了20世纪70年代初期，C/C++等高级语言相继诞生，屏蔽了具体的硬件信息，使得软件开发人员根本不需要了解体系结构的寄存器和以及寻址方式，这些所有工作都扔给了编译器，极大地降低了软件开发的难度。与此同时也提高了软件在不同体系架构之间的可移植性。  
    
    
III.  高级语言产生，使得软件发展的速度远超于硬件。软件的超强灵活性使得软件飞速发展，相对于发展较慢的硬件而言，大量编写过的软件可以重新被复用并且添加新的特性发挥余热。软件行业的发展就是在这样的不断迭代中一步一步跑过来的。因此，移植性对于软件开发而言，至关重要，不需要从头造轮子，在现有的基础上添加新的特性从而适应新时代对软件行业提出的新要求和新挑战。
  
  
  
3. 在移植性和效率方面，如何选择？ 
  
  

    
I.   可移植性概念包含了一层含义：就是在具体硬件信息和软件之间增加了一个层的概念，一般而言它是一些系统软件，比如编译器，它完成软件到二进制的中间的转换过程，以适应不同的体系架构。 
    
    
II.  俗话说，鱼和熊掌不可兼得， 二进制形式的软件效率无疑是最高的，因为它充分利用硬件的资源和特性，而经过中间层的可移植软件则不具有如此快的速度。 
III.  一般而言，在一些简单并且注重效率方面，使用汇编这样高效率的实现方式，而一些复杂通用的部分，可以考虑使用高级语言编写的可移植性程序。比如Linux操作系统，99.9%都是用C语言写的，而只有少部分的启动和初始化代码是用特定架构的汇编完成的。
  



  
二：具体阐述 
  
  
1.  舍弃高效率而取移植性  
  
  

    
I.    程序员要面对的一个艰难选择就是：高效率和可移植性。这是一个极其磨人的抉择，因为偏向高效率往往导致代码不可移植，而选择可移植性却又会让软件的性能不那么尽如人意。  
    
    
II.   高效率的软件不会浪费CPU周期，它充分利用了底层硬件的特性，可往往完全忽视了可移植性的问题，比如利用了图形加速器，高速缓冲存储器以及专门的浮点指令等硬件功能。 
    
    
III.   虽然高效率的软件非常有吸引力，但是可移植性意味着软件能够运行在不同的机器上，这使得人们考量的天平向可移植性这一端倾斜。一代代处理器如滚雪球般发展，半导体设计世界的动向令人目不暇接，芯片的性能不断呈现螺旋式加速上升，根据摩尔定律，每个18个月硬件的速度翻倍，当然，现实的发展速度快于定于所言。从这个意义上，可移植性更具优势。
    
    
IIII .  在转移到一个新平台的时候，充分考虑了可移植性因素的软件大大降低他的平台转移成本，开发人员不需要耗费太多时间在移植工作上，因此他们可以把更多的时间用于开发新功能，由此吸引更多的用户，同时也赋予产品新的商业优势。
  
  
  
2. 最高效的方法往往不可移植  
  
  

    
任何时候，但凡一个程序利用了其某些特殊硬件功能的优势，它往往变得高效，但却也变得不那么可移植了。特殊功能有时候会极大提高软件的性能，但他们需要采用于硬件设备相关的代码，但目标硬件被更快的版本取代以后，人们就需要更新代码。  
  
  
  
3. 不要花太多时间去优化程序 
  
  

    
还是那一点：芯片的性能不断呈现螺旋式加速上升，硬件性能越来越快，在有限的时间用于开发更加有用的功能。
  
  
  
4. 常用的一些可移植的处理方式   
  
  

    
I .  shell脚本 编写的软件在类Unix系统上几乎通用。比如各大Linux发行版。Ubuntu，RedHat。 
    
    
II . 采用纯文本文件来存储数据，所谓纯文本就是应该只包括一组由换行符字符或者newline分割的字节流。 文本是通用的可转换格式，几乎说有的目标平台都能处理文本编码的数据，效用文本可以消除很多麻烦，你不需要将自己的数据从一种二进制格式转化到另一种二进制格式。
  

1.      概述
我们在讨论系统移植的时候，通常会提到一个概念：平台。平台可以是硬件平台，也可以是软件平台，软件平台通常指的就是操作系统。而按照应用领域的不同，我们又可以将软件平台细分为J2EE、.NET平台，如此等等。
衡量系统的可移植性要从两个角度来看待，一个是垂直的，一个是水平的。所谓的垂直移植性，就是如何将一个应用程序从某个平台的一个版本移植到另外一个版本。如将一个应用程序从win32移植到win64，或将操作系统从IA-32移植到IA-64 CPU等。所谓的水平移植性，就是如何将一个应用程序从一个平台移植到另外一个平台。如将一个应用程序从windows平台移植到Linux平台，或将操作系统从Intel平台移植到ADM等。
在这篇文章中，我们主要讲述了两类平台，一类是硬件平台，另外一类就是操作系统平台。我们将重点阐述C++应用程序在操作系统平台上的移植。
2.      硬件平台移植
对系统软硬件起到隔离作用，从而提高系统软件的可移值性及有效地利用人力资源、缩短开发周期和提高产品的可靠性。
硬件抽象层的特点
n  硬件抽象层具有与硬件密切相关性；
n  硬件抽象层具有与操作系统无关性；
n  接口定义的功能应包含硬件或系统所需硬件支持的所有功能；
n  接口定义简单明了，太多接口函数会增加软件模拟的复杂性；
n  具有可测性的接口设计有利于系统的软硬件测试和集成。
2.1.  参考设计
Windows操作系统的HAL模块，封装了对大部分硬件的底层数据交换和操作。
参考Windows操作系统的整体结构图：



对比UNIX操作系统的整体结构图：


3.      操作系统平台移植
不论是桌面应用领域还是嵌入式应用领域，在大多数情况下，这些领域的应用都构建在操作系统之上。每个操作系统都各有其特点，在特定的领域这些操作系统的功能基本相同，而操作系统的基础架构的不一致性，也直接导致了构建在操作系统之上的领域应用的不一致性。往往领域应用需要构建在多个平台之上，这就引入了所谓的“移植”。如何将一个特定的领域应用从一个平台移植到另外一个平台，这是一个相对的问题，我们只能尽可能把平台不一致性的部分给提取、抽象出来，提供应用程序的可移植性。
对于应用程序的可移植性，一直都没有公论，下面我们提供了C++应用程序在操作系统平台之间的移植时的一种解决方案。
a.         选择一种可移植的程序语言，如C++。
其实这也并不是必须的。现在的Java/C#都建在虚拟机之上，从本质上来说，如果虚拟机是可移植的，那么用这些语言编写出来的应用程序也是可移植的。从这点上来说，Java/C#其实是可移植的。
b.         尽量使用C标准库函数。
因为这些库函数，一般的操作的系统提供商和编译器提供商都提供了相应的支持。
c.         分离出不可移植的类型定义，并在应用程序中使用这些定义。
下面阐述是集中常见的情况：
n  文件分隔符
WINDOWS平台采用的是”/”，而UNIX/linux使用的是”/”。
那么把这个部分分离出来,可使用如下的定义：
#ifdef UNIX

#define SEPERATOR    ‘/’

#endif

#ifdef _WINDOWS||__MSDOS__

#define SEPERATOR    ‘/’

#endif

n  基本类型，不同操作系统版本对于基本类型、指针的定义是有差别的。
如在64位系统上，指针是64位的。；而在32位系统上，指针是32位的。
那么把这个部分分离出来,可使用如下的定义：
typedef char             int8_t;

typedef __int16          int16_t;

typedef __int32          int32_t;

typedef __int64            int64_t;

typedef unsigned char    uint8_t;

typedef unsigned __int16 uint16_t; 

typedef unsigned int     uint_t;

typedef unsigned __int32 uint32_t;

typedef unsigned __int64 uint64_t;

#ifndef _INTPTR_T_DEFINED

#ifdef _WIN64

typedef    __int64 intptr_t;

#else

typedef    int intptr_t;

#endif

#define _INTPTR_T_DEFINED

#endif

#ifndef _UINTPTR_T_DEFINED

#ifdef _WIN64

typedef unsigned __int64 uintptr_t;

#else

typedef unsigned int uintptr_t;

#endif

#define _UINTPTR_T_DEFINED

#endif

typedef intptr_t ssize_t;
d.         抽象应用程序依赖于平台API相关的接口，对于不同的平台提供不同的实现。
例如，对于线程的操作，linux和windows平台的API有着不同的定义。
那么我们可以把线程操作相关的接口给抽象出来，如：
class Thread

{

public:

    static Thread* Create(); 

    static Thread* CurrentThread() const;

    void Suspend();

    void Join();

    void Sleep();

    void Start();

    uint_t GetID() const;

    bool IsAlive() const;

    void SetPriority(int32_t priority);

    int32_t GetPriority() const;

    //...

};

        可以把软件的可维护性定性地定义为:维护人员理解、改正、改动或改进这个软件的难易程度。在前面的章节中曾经多次强调,提高可维护性是支配软件工程方法学所有步骤的关键目标。

        8.4.1 决定软件可维护性的因素

        维护就是在软件交付使用后进行的修改,修改之前必须理解待修改的对象,修改之后应该进行必要的测试,以保证所做的修改是正确的。如果是改正性维护,还必须预先进行调试以确定错误的具体位置。因此,决定软件可维护性的因素主要有下述5个。

1.可理解性

        软件可理解性表现为外来读者理解软件的结构、功能、接口和内部处理过程的难易程度,模块化(模块结构良好,高内聚,松耦合)、详细的设计文档、结构化设计、程序内部的文档和良好的高级程序设计语言等,都对提高软件的可理解性有重要贡献

2,可测试性

        诊断和测试的容易程度取决于软件容易理解的程度。良好的文档对诊新和测试是至关重要的,此外,软件结构、可用的测试工具和调试工具,以及以前设计的测试过程也都是非常重要的。维护人员应该能够得到在开发阶段用过的测试方案,以便进行回归测试。在设计阶段应该尽力把软件设计成容易测试和容易诊断的。

        对于程序模块来说,可以用程序复杂度来度量它的可测试性,模块的环形复杂度越大,可执行的路径就越多,因此,全面测试它的难度就高。

3.可修改性

        软件容易修改的程度和本书第5章讲过的设计原理和启发规划直接有关。耦合、内聚、信息稳藏,局部化、控制域与作用域的关系等,都影响软件的可修改性

4.可移植性

        软件可移植性指的是,把程序从一种计算环境(硬件配置和操作系统)转移到另一种计算环境的难易程度,把与硬件,操作系以及其他外部设备有关的程序代码集中放到特定的程序模块中,可以把因环境变化而必须修改的程序局限在少数程序模块中,从而降低修改的难度

5.可重用性

        所谓重用( reuse)是指同一事物不做修改或稍加改动就在不同环境中多次重复使用。大量使用可重用的软件构件来开发软件,可以从下述两个方面提高款件的可维护性：

(1)通常,可重用的软件构件在开发时都经过很严格的测试,可靠性比较高,且在每次重用过程中都会发现并清除一些错误,随着时间推移,这样的构件将变成实质上无误的,因此,软件中使用的可重用构件越多,软件的可靠性越高,改正性维护需求就越少

(2)很容易修改可重用的软件构件使之再次应用在新环境中,因此,软件中使用的可重用构件越多，适应性和完善性维护也就越容易。

8.4.2 文档

        文档是影响软作可维护性的决定因素,由于长期使用的大型软件系统在使用过程中必然会经受多次修改,所以文档比程序代码更重要。软件系统的文档可以分为用户文档和系统文档两类。用户文档主要描述系统功能和使用方法,并不关心这些功能是怎样实现的;系统文档描述系统设计、实现和测试等各方面的内容。总地说来,软件文档应该满足下述要求

(1)必须描述如何使用这个系统,没有这种描述时即使是最简单的系统也无法使用

(2)必须描述怎样安装和管理这个系统。

(3)必须描述系统需求和设计

(4)必须描述系统的实现和测试,以便使系统成为可维护的

下面分别讨论用户文档和系统文档

1.用户文档

        用户文档是用户了解系统的第一步,它应该能使用户获得对系统的准确的初步印象。文档的结构方式应该使用户能够方便地根据需要阅读有关的内容。用户文档至少应该包括下述5方面的内容

(1)功能描述,说明系统能做什么。

(2)安装文档,说明怎样安装这个系统以及怎样使系统适应特定的硬件配置

(3)使用手册,简要说明如何着手使用这个系统(应该通过丰富例子说明怎样使用常用的系统功能,还应该说明用户操作错误时怎样恢复和重新启动)

(4)参考手册,详尽描述用户可以使用的所有系统设施以及它们的使用方法,还应该解释系统可能产生的各种出错信息的含义(对参考手册最主要的要求是完整,因此通常使用形式化的描述技术)

(5)操作员指南(如果需要有系统操作员的话),说明操作员应该如何处理使用中出现的各种情况

        上述内容可以分别作为独立的文档,也可以作为一个文档的不同分册,具体做法应该由系统规模决定

2.系统文档

        所谓系统文档指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档。描述系统设计,实现和测试的文档对于理解程序和维护程序来说是极端重要的。和用户文档类似,系统文档的结构也应该能把读者从对系统概貌的了解,引导到对系统每个方面每个特点的更形式化更具体的认识。本系列前面各章已经较详细地介绍了各个阶段应该产生的文档,此处不再重复