免费智能真题库 > 历年试卷 > 系统架构设计师 > 2014年下半年 系统架构设计师 下午试卷 论文
  第1题      
  知识点：   变更控制   基线   开发过程   需求管理   版本控制   软件需求   项目管理   需求跟踪   一致性

 
论软件需求管理
软件需求管理是一个对系统需求变更了解和控制的过程。需求管理过程与需求开发过程相互关联，初始需求导出的同时就要形成需求管理规划，一旦启动了软件开发过程，需求管理活动就紧密相伴。
需求管理过程中主要包含变更控制、版本控制、需求跟踪和需求状态跟踪等4项活动，其目标是为项目管理人员建立一个软件需求基线，并保持软件计划、产品和活动与软件需求的一致性。
 
问题：1.1   请围绕“软件需求管理”论题，依次从以下三个方面进行论述。
1.概要叙述你参与管理和开发的软件项目以及你在其中所担任的主要工作。
2.详细描述需求管理过程中各个活动中的主要工作。
3.详细说明你所参与的软件开发项目中，是如何进行软件需求管理的，实施的具体效果如何。
 
 
 

   知识点讲解    
   · 变更控制    · 基线    · 开发过程    · 需求管理    · 版本控制    · 软件需求    · 项目管理    · 需求跟踪    · 一致性
 
       变更控制
        变更控制系统是一套事先确定的修改项目文件或改变项目活动时应遵循的程序，其中包括必要的表格或其他书面文件，责任追踪，以及变更审批制度、人员和权限。变更控制系统应当明确规定变更控制委员会的责任和权力，并由所有的项目干系人认可。在审批变更时，要加强对变更风险和变更效果的评估，并选择对项目影响最小的变更方案，尽量防止增加项目投资。变更控制系统可细分为整体、范围、进度、费用和合同变更控制系统。变更控制系统应当同项目管理信息系统一起通盘考虑，形成整体。
               变更控制委员会
               变更控制委员会（Change Control Board，CCB）也称配置控制委员会（Configuration Control Board），其任务是对建议的配置项变更做出评价、审批，以及监督已批准变更的实施。CCB的成员通常包括项目经理、用户代表、质量控制人员、配置控制人员。这个组织不必是常设机构，可以根据工作的需要组成，其中的人员可以全职的，也可以是兼职的。
               如果CCB除控制变更以外，还要承担更多的配置管理任务，那就应该包括基线的审定、标识的审定，以及产品的审定，并且可能实际的工作需分为项目层、系统层和组织层来组建，使其完成不同层面的配置管理任务。
               变更控制的流程
               变更管理的基本流程如下：
               ①变更申请。应记录变更的提出人、日期、申请变更的内容等信息。
               ②变更评估。对变更的影响范围、严重程度、经济和技术可行性进行系统分析。
               ③变更决策。由具有相应权限的人员或机构决定是否实施变更。
               ④变更实施。由管理者指定的工作人员在受控状态下实施变更。
               ⑤变更验证。由配置管理人员或受到变更影响的人对变更结果进行评价，确定变更结果和预期是否相符、相关内容是否进行了更新、工作产物是否符合版本管理的要求。
               ⑥沟通存档。将变更后的内容通知可能会受到影响的人员，并将变更记录汇总归档。如提出的变更在决策时被否决，其初始记录也应予以保存。
               变更申请需要采用书面的形式提出，主要内容有如下3个方面：
               ①变更描述。包括变更理由、变更的影响、变更的优先级等，就是要描述做什么变更，为什么要做，以及打算怎么做的问题。
               ②对变更的审批。对变更的必要性、可行性的审批意见，主要是由配置管理员和CCB对此项变更把关。
               ③变更实施的信息。
               利用配置库实现变更控制
               配置项可以有3种状态，分别是工作状态、评审状态和受控状态。开发中的配置项尚未稳定下来，对于其他配置项来说是处于不处理工作状态下（自由状态），此时它并未受到配置管理的控制，开发人员的变更并未受到限制。但当开发人员认为工作已告完成，可供其他配置项使用时，它就开始于稳定。把它交出评审，就开始进入评审状态；若通过评审，可作为基线进入配置库（实施检入），开始冻结，此时开发人员不允许对其任意修改，因为它已处于受控状态。通过评审表明它确已达到质量要求；但若未能通过评审，则将其回归到工作状态，重新进行调整。配置项的状态变化过程如下图所示。
               
               配置项的状态变化过程
               处于受控状态下的配置项原则上不允许修改，但这不是绝对的，如果由于多种原因需要变更，就需要提出变更请求。在变更请求得到批准的情况下，允许配置项从库中检出，待变更完成，并经评审后，确认变更无误方可重新入库，使其恢复到受控状态。
 
       基线
        基线（baseline）是项目生存期各开发阶段末尾的特定点，也称为里程碑（milestone），在这些特定点上，阶段工作已结束，并且已经形成了正式的阶段性产品。
        建立基线的概念是为了把各开发阶段的工作划分得更加明确，使得本来连续开展的开发工作在这些点上被分割开，从而更加有利于检验和肯定阶段工作的成果，同时有利于进行变更控制。有了基线的规定就可以禁止跨越里程碑去修改另一开发阶段的工作成果，并且认为建立了里程碑，有些完成的阶段成果已被冻结。
        作为阶段工作的正式产品，基线应该是稳定的，如作为设计基线的设计规格说明应该是通过评审的。如果还只是设计草稿，就不能作为基线，不能被冻结。
        如果把软件看作是系统的一个组成部分，以下3种基线最受人们关注的：功能基线、分配基线、产品基线。
        （1）功能基线：指在系统分析与软件定义阶段结束时，经过正式评审和批准的系统设计规格说明书中对待开发系统的规格说明；或是指经过项目委托单位和项目承办单位双方签字同意的协议书或合同中所规定的对待开发软件系统的规格说明；或是由下级申请经上级同意或直接由上级下达的项目任务书中所规定的对待开发软件系统的规格说明。功能基线是最初批准的功能配置标志。
        （2）分配基线（指派基线）：指在软件需求分析阶段结束时，经过正式评审和批准的软件需求的规格说明。指派基线是最初批准的指派配置标志。
        （3）产品基线：指在软件组装与系统测试阶段结束时，经过正式评审批准的有关所开发的软件产品的全部配置项的规格说明。产品基线是最初批准的产品配置标志。
        另外，交付给外部顾客的基线一般称为发行基线，内部使用的基线称为构造基线。释放是指在软件生存周期的各个阶段结束时，由该阶段向下阶段提交该阶段产品的过程。它也指将集成与系统测试阶段结束时所获得的最终产品向用户提交的过程。后面这个过程也称为交付。
        ：提出基线的概念本来是为了更好地实现变更控制，但如果把每个基线都当成一个整体来看待会造成麻烦。因为一个变更很可能只涉及基线的很小部分。例如，假定某个大型软件中的一个模块修改了，如果将这一变更当做整个软件产品基线的变更，就很不方便。
 
       开发过程
        嵌入式系统软件的开发过程可以分为项目计划、可行性分析、需求分析、概要设计、详细设计、程序建立、下载、调试、固化、测试及运行等几个阶段。
        项目计划、可行性分析、需求分析、概要设计及详细设计等几个阶段，与通用软件的开发过程基本一致，都可按照软件工程方法进行，如采用原型化方法、结构化方法等。
        ：由于嵌入式软件的运行和开发环境不同，开发工作是交叉进行的，所以每一步都要考虑到这一点。
        程序建立阶段的工作是根据详细设计阶段产生的文档进行的，主要是源代码编写、编译链接等子过程，这些工作都在宿主机上进行，不需要用到目标机。产生应用程序的可执行文件后，就要用到交叉开发环境进行调试，根据实际情况可以选用3.6.3节中提到的调试方法或其有效组合来进行。由于嵌入式系统对安全性和可靠性的要求比通用计算机系统要高，所以，在对嵌入式系统进行白盒测试时，要求有更高的代码覆盖率。
        最后，要将经调试后正确无误的可执行程序固化到目标机上。根据嵌入式系统硬件配置的不同，可以固化在EPROM（Erasable Programmable ROM，可擦除可编程ROM）和Flash等存储器中，也可固化在DOC（DiskOnChip）等电子盘中，通常还要借助一些专用编程器进行。
 
       需求管理
        需求管理通常包括定义需求基线、处理需求变更及需求跟踪等方面的工作。根据考试大纲，本节要求考生掌握需求变更、需求跟踪和需求变更风险管理三个方面的知识。本节只简单介绍有关需求跟踪方面的知识。有关定义需求基线和需求变更的知识，请阅读11.5.3节；有关风险管理方面的知识，请阅读11.7节。
        需求跟踪的主要目的如下：
        （1）审核。跟踪能力信息可以帮助审核确保所有需求被应用。
        （2）在增加、删除、修改需求时可以确保不忽略每个受到影响的系统元素。
        （3）使得维护时能正确、完整地实施变更，从而提高生产率。
        （4）获得计划功能当前实现状态的记录。
        （5）再工程。可以列出旧系统中将要替换的功能，记录它们在新系统的需求和软件组件中的位置。
        （6）重新利用跟踪信息可以帮助开发人员在新系统中对相同的功能利用旧系统相关资源。
        （7）可以减少由于关键成员离开项目带来的风险。
        （8）可以在测试出错时指出最可能有问题的代码段。
        在信息系统项目中，需求变更是不可避免的，如何以可控的方式管理软件的需求，对于项目的顺利进行有着重要的意义。如果匆匆忙忙地完成用户调研与分析，则往往意味着不稳定的需求。所以需求管理要保证需求分析各个活动都得到了充分的执行。对于需求变更的管理，则主要使用需求变更流程和需求跟踪矩阵的管理方式。
        需求跟踪包括编制每个需求与系统元素之间的联系文档。这些元素包括已识别的需求、约束、其他设计部件、源代码模块、测试、帮助文件、文档等。需求跟踪分为正向跟踪和逆向跟踪，一般合称为“双向跟踪”。不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵（即表格）。需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。它跟踪的是已明确的需求的实现过程，不涉及需求开发人员的职责，也无法用于防止变更矩阵单元之间的可能存在“一对一”、“一对多”或“多对多”的关系。由于对应关系比较复杂，最好在表格中加必要的文字解释。当需求文档或后续工作成果发生变更时，要及时更新需求跟踪矩阵。
 
       版本控制
        版本是表示一个配置项具有一组定义的功能的一种标识。随着功能的增加，修改或删除，配置项的版本随之演变。应当记录每个软件配置项的所有历史记录，并记录该软件配置项由何人创建，何人在何时因何原因进行了修改等信息，以及对这些软件配置项版本的进行检索和信息查询等活动。
 
       软件需求
        在进行需求获取之前，首先要明确需要获取什么，也就是需求包含哪些内容。软件需求是指用户对目标软件系统在功能、行为、性能、设计约束等方面的期望。通常，这些需求包括功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性需求、软件成本消耗与开发进度需求等，并预先估计以后系统可能达到的目标。此外，还需要注意其他非功能性的需求。具体内容如下。
        （1）功能需求。
        （2）性能需求。
        （3）用户或人的因素。
        （4）环境需求。
        （5）界面需求。
        （6）文档需求。
        （7）数据需求。
        （8）资源使用需求。
        （9）安全保密要求。
        （10）可靠性要求。
        （11）软件成本消耗与开发进度需求。
        （12）其他非功能性要求。
               需求分析的任务
               需求分析主要是确定待开发软件的功能、性能、数据、界面等要求。具体来说有下面几点。
               （1）确定软件系统的综合要求，包括系统界面、功能、性能、安全性、保密性、可靠性、运行等方面的要求。
               （2）分析软件系统的数据要求，包括基本数据元素、数据元素之间的逻辑关系、数据量、峰值等。
               （3）导出系统的逻辑模型，在结构化方法中可用数据流图来描述；在面向对象分析方法中可以用类模型来描述。
               （4）修正项目开发计划。
               （5）如有必要，可开发一个原型系统以验证用户的需求。
               软件需求的分类
               下面介绍软件需求的分类。
               （1）功能需求。所开发的软件必须具备什么样的功能。
               （2）非功能需求。它是指产品必须具备的属性或品质，如可靠性、性能响应时间、容错性和可扩展性等。
               （3）设计约束。其也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。
               软件需求分析方法
               需求分析方法由对软件的数据域和功能域的系统分析过程及其表示方法组成。它定义了表示系统逻辑视图和物理视图的方式。大多数的需求分析方法是由数据驱动的，数据域具有数据流、数据内容和数据结构3种属性。通常一种需求分析方法总要利用其中一种或几种属性。
 
       项目管理
        构建嵌入式系统是一项复杂的任务，尤其是涉及到很多人员共同长期工作的时候。为了使嵌入式项目开发获得成功，必须对系统开发项目的工作范围、花费的工作量（成本）、可能遇到的风险、进度的安排、要实现的任务、经历的里程碑以及需要的资源（人、硬／软件）等做到心中有数，而项目管理可以提供这些信息。项目管理的过程一般包括初启、计划、执行、监控、结项，项目管理的范围覆盖整个系统生命周期过程。
               管理范围
               有效的项目管理集中于4P，即人员（People）、产品（Product）、过程（Process）和项目（Project）。必须将人员组织起来以有效地完成产品构建工作；必须和客户及其他利益相关者很好地沟通，以便了解产品的范围和需求；必须选择适合于人员和产品的过程；必须估算完成工作任务的工作量和工作时间，从而制订项目计划。
               “人的因素”非常重要，在所有项目中，最关键的因素是人员，涉及项目管理人员、高级管理人员、开发人员、客户和最终用户。人员能力成熟度模型（People Capability Maturity Model，PCMM）针对人员定义了以下关键实践域：人员配备、沟通与协调、工作环境、业绩管理、培训、报酬、能力素质分析与开发、个人事业发展、工作组发展以及团队精神或企业文化培育等。PCMM成熟度达到较高水平的组织，更有可能实现有效的项目管理事件。
               在制订项目计划之前，首先确定产品的目标和范围，考虑可选的解决方案，识别技术和管理上的限制。如果没有这些信息，就无法进行合理（精确）的成本估算，也无法进行有效的风险评估和适当的项目任务划分，更无法制定可管理的项目进度计划来给出意义明确的项目进展标志。确定产品的目标只是识别出产品的总体目标，而不用考虑如何实现这些目标。确定产品的范围是识别出产品的主要数据、功能和行为特性，并且应该用量化的方式界定这些特性。然后开始考虑备选解决方案，不讨论细节，使管理者与参与开发的人员根据特定的约束条件选择相对最佳的方案，约束条件有产品的交付期限、预算限制、可用人员、技术接口以及其他各种因素。
               开发过程提供了一个框架，一小部分框架活动适用于所有的项目，多种不同的任务集合使得框架活动适合于不同项目的特性和项目团队的需求。普适性活动（如质量管理、配置管理、测量等）覆盖了过程模型，独立于任何一个框架活动，且贯穿于整个过程之中。
               为了成功地管理项目，需要有计划、可控制，这样才能管理复杂的系统开发；需要了解可能会出现的各类问题以便加以避免。可以采用的方法有：
               （1）在正确的基础上开始工作。
               （2）保持动力。
               （3）跟踪进度。
               （4）做出正确的决策。
               （5）进行事后分析。
               成本估算
               系统开发成本估算主要指系统开发过程中所花费的工作量及相应的代价。为了使开发项目能够在规定的时间内完成，而且不超过预算，成本预算和管理控制是关键。项目开发成本的估算主要靠分解和类推的手段进行。分解技术是将项目分解成一系列较小的、容易理解的问题进行估算。常用的分解技术有：基于问题的估算、基于代码行（LOC）估算、基于功能点（FP）的估算、基于过程的估算、基于用例的估算。选择或结合使用分解技术，进行成本估算。基本的成本估算方法有如下几种。
               （1）自顶向下估算方法。估算人员参照以前完成的项目所耗费的总成本（或总工作量）来推算将要开发的系统的总成本（或总工作量），然后把它们按阶段、步骤和工作单元进行分配。
               自顶向下估算方法的主要优点是对系统级工作的重视，所以估算中不会遗漏集成、配置管理等系统级事务的成本估算，且估算工作量小、速度快。其缺点是不清楚低级别上的技术性困难，而这些困难将会使成本上升。
               （2）自底向上估算方法。自底向上估算方法是将待开发的系统细分，分别估算每一个子任务所需要的开发工作量，然后将它们加起来，得到系统的总开发量。这种方法的优点是对每一部分的估算工作交给负责该部分工作的人来做，所以估算较为准确。其缺点是缺少对各项子任务之间相互联系所需要工作量和与开发有关的系统级工作量的估算，因此预算往往偏低。
               （3）差别估算方法。差别估算方法是将开发项目与一个或多个已完成的类似项目进行比较，找出与某个相类似项目的若干不同之处，并估算每个不同之处对成本的影响，导出开发项目的总成本。该方法的优点是可以提高估算的准确度，缺点是不容易明确“差别”的界限。
               除以上方法外，还有许多方法，大致可分为三类：专家估算法、类推估算法和算式估算法。
               （1）专家估算法。该方法依靠一个或多个专家对要求的项目做出估算，其精确性取决于专家对估算项目的定性参数的了解和他们的经验。
               （2）类推估算法。在自顶向下的方法中，它是将估算项目的总体参数与类似项目进行直接比较得到结果；在自底向上方法中，类推是在两个具有相似条件的工作单元之间进行。
               （3）算式估算法。专家估算法和类推估算法的缺点在于它们依靠带有一定盲目性和主观性的猜测对项目进行估算。算式估算法则是企图避免主观因素的影响，用于估算的方法有两种基本类型：由理论导出和由经验导出。
               典型的成本估算模型主要有动态多变量普特南（Putnam）模型和层次结构的结构性成本模型（Constructive Cost Model，COCOMO）的升级模型COCOMOII等。普特南模型基于软件方程，它假设在软件开发的整个生命周期中有特定的工作量分布。COCOMOII模型层次结构中有三种不同的估算选择：对象点、功能点和源代码行。
               风险分析
               新的系统建立时，总是存在某些不确定性。例如，用户要求是否能确切地被理解？在项目最后结束之前要求实现的功能能否建立？是否存在目前仍未发现的技术难题？在项目出现严重延期时是否会发生一些变更？等等。风险是潜在的，需要识别、评估发生的概率、估算其影响、并制定实际发生时的应急计划。
               风险分析在项目管理中具有决定性作用。当在软件工程的环境中考虑风险时，主要关注以下三个方面。一是关心未来。风险是否会导致项目失败；二是关心变化。用户需求、开发技术、目标机器以及所有其他与项目有关的实体会发生什么变化；三是必须解决需要做出选择的问题，即应当采用什么方法和工具，应当配备多少人力，在质量上强调到什么程度才满足要求等。
               风险分析实际上是贯穿软件工程中的一系列风险管理步骤，其中包括风险识别、风险估计、风险管理策略、风险解决和风险监控。
               进度管理
               进度安排包括把一个项目所有的工作分解为若干个独立的活动，并描述这些活动之间的依赖关系，估算完成这些活动所需的工作量，分配人力和其他资源，制定进度时序。进度的合理安排是如期完成软件项目的重要保证，也是合理分配资源的重要依据，因此进度安排是管理工作的一个重要组成部分。有两种安排软件开发项目进度的方式：
               （1）系统最终交付日期已经确定，系统开发部门必须在规定期限内完成；
               （2）系统最终交付日期只确定了大致的年限，最后交付日期由软件开发部门确定。
               进度安排的常用图形描述方法有Gantt图（甘特图）和PERT（Program Evaluation&Review Technique，项目计划评审技术）图。
               （1）Gantt图。Gantt图中横坐标表示时间（如时、天、周、月、年等），纵坐标表示任务，图中的水平线段表示一个任务的进度安排，线段的起点和终点对应在横坐标上的时间分别表示该任务的开始时间和结束时间，线段的长度表示完成该任务所持续的时间。当日历中同一时段中存在多个水平条时，表示任务之间的并发。下图所示的Gantt图描述了三个任务的进度安排。该图表示：任务1首先开始，完成它需要12周时间；任务2在2周后开始，完成它需要18周；任务3在12周后开始，完成它需要10周。
               
               Gantt图实例
               Gantt图能清晰地描述每个任务从何时开始，到何时结束，任务的进展情况以及各个任务之间的并行性；但是它不能清晰地反映出各任务之间的依赖关系，难以确定整个项目的关键所在，也不能反映计划中有潜力的部分。
               （2）PERT图。PERT图是一个有向图，其基本符号如下图所示。
               
               PERT图的基本符号
               PERT图中的有向弧表示任务，可以标上完成该任务所需的时间，图中的结点表示流入结点的任务已结束，并开始流出结点的任务，这里把结点称为事件。只有当流入该结点的所有任务都结束时，结点所表示的事件才出现，流出结点的任务才可以开始。事件本身不消耗时间和资源，它仅表示某个时间点。每个事件有一个事件号及出现该事件的最早时刻和最迟时刻。最早时刻表示在此时刻之前从该事件出发的任务不可能开始；最迟时刻表示从该事件出发的任务必须在此时刻之前开始，否则整个工程就不能如期完成。每个任务还可以有一个松弛时间（slack time），表示在不影响整个工期的前提下，完成该任务有多少机动时间。为了表示任务间的关系，图中还可以加入一些空任务（用虚线有向弧表示），完成空任务的时间为0。
               PERT图的一个实例如下图所示，该图所表示的工程可分为12个任务，事件号1表示工程开始，事件号11表示工程结束（完成所有任务需要23个时间单位）。松弛时间为0的任务构成了完成整个工程的关键任务，其事件流为1→2→3→4→6→8→10→11，也就是说，这些任务不能拖延，否则整个工程就不能在23个时间单位内完成。
               
               PERT图示例
               PERT图不仅给出了每个任务的开始时间、结束时间和完成该任务所需的时间，还给出了任务之间的关系，即哪些任务完成后才能开始另外一些任务，还可以找出如期完成整个工程的关键任务。任务的松弛时间则反映了完成任务时可以推迟其开始时间或延长其所需完成的时间。PERT图不能反映任务之间的并行关系。
 
       需求跟踪
        需求跟踪的内容
        需求跟踪包括编制每个需求同系统元素之间的联系文档。这些元素包括别的需求、体系结构、其他设计部件、源代码模块、测试、帮助文件、文档等。
        在某种程度上，需求跟踪提供了一个表明与合同或说明一致的方法。需求跟踪还可以改善产品质量，降低维护成本，很容易实现重用。在项目中使用需求跟踪的好处有：
        .审核跟踪能力信息有助于确保应用了所有需求。
        .变更影响分析在增、删、改需求时可以确保不忽略每个受到影响的系统元素。
        .维护可靠的跟踪能力信息使得维护时能正确、完整地实施变更，从而提高生产率。
        .在开发中认真记录跟踪能力数据，就可以获得计划功能当前实现状态的记录。
        .重新构造。
        .重复利用跟踪信息有助于在新系统中对相同的功能利用旧系统相关资源。
        .减小风险。把部件互联关系文档化可减少由于关键成员离开项目带来的风险。
        .测试模块、需求、代码之间的联系链可以在测试出错时指出最可能有问题的地方。
        需求跟踪能力矩阵是表示需求和别的系统元素之间联系链的常用方式。
        使用需求跟踪能力来管理工程时，可考虑以下步骤：
        （1）决定定义哪几种联系链。
        （2）选择要使用的跟踪能力矩阵种类。
        （3）确定对产品哪些部分进行跟踪。
        （4）通过修订过程和核对表来提醒开发人员在需求完成或变更时更新联系链。
        （5）制订规范，统一标识所有系统元素，达到可以相互联系的目的。
        （6）确定提供每类联系链信息的人员。
        （7）培训项目组成员。
        （8）及时更新跟踪能力数据。
        （9）开发过程中周期性更新数据，使跟踪信息与实际相符。
        变更需求代价：影响分析
        影响分析是需求管理的一个重要组成部分。影响分析可以提供对建议变更的准确理解，有助于做出信息量充分的变更批准决策。通过对变更内容的检验，确定对现有的系统做出修改或抛弃的决定，或者创建新系统以及评估每个任务的工作量。
        进行影响分析的能力依赖于跟踪能力数据的质量和完整性。
 
       一致性
        在讨论一致性之前，先看一下CAP理论。它作为一种理论依据，使得在不同应用中，对一致性也有了不同的要求。CAP理论：简单地说，就是对于一个分布式系统，一致性（Consistency）、可用性（Availablity）和分区容忍性（Partition tolerance）三个特点最多只能三选二。
        一致性意味着系统在执行了某些操作后仍处在一个一致的状态，这点在分布式的系统中尤其明显。比如某用户在一处对共享的数据进行了修改，那么所有有权使用这些数据的用户都可以看到这一改变。简言之，就是所有的结点在同一时刻有相同的数据。
        可用性指对数据的所有操作都应有成功的返回。高可用性则是在系统升级（软件或硬件）或在网络系统中的某些结点发生故障的时候，仍可以正常返回。简言之，就是任何请求不管成功或失败都有响应。
        分区容忍性这一概念的前提是在网络发生故障的时候。在网络连接上，一些结点出现故障，使得原本连通的网络变成了一块一块的分区，若允许系统继续工作，那么就是分区可容忍的。
        在数据库系统中，事务的ACID属性保证了数据库的一致性。比如银行系统中，转账就是一个事务，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，具有原子的不可拆分特性，从而保证了整个系统中的总金额没有变化。
        然而，这些ACID特性对于大型的分布式系统来说，是和高性能不兼容的。比如，你在网上书店买书，任何一个人买书这个过程都会锁住数据库直到买书行为彻底完成（否则书本库存数可能不一致），买书完成的那一瞬间，世界上所有的人都可以看到书的库存减少了一本（这也意味着两个人不能同时买书）。这在小的网上书城也许可以运行得很好，可是对Amazon这种网上书城却并不是很好。
        而对于Amazon这种系统，它也许会用Cache系统，剩余的库存数也许是几秒甚至几个小时前的快照，而不是实时的库存数，这就舍弃了一致性。并且，Amazon可能也舍弃了独立性，当只剩下最后一本书时，也许它会允许两个人同时下单，宁愿最后给那个下单成功却没货的人道歉，而不是整个系统性能的下降。
        由于CAP理论的存在，为了提高性能，出现了ACID的一种变种BASE（这四个字母分别是Basically Available，Soft—state，Eventual consistency的开头字母，是一个弱一致性的理论，只要求最终一致性）：
        .Basically Available：基本可用。
        .Soft state：软状态，可以理解为“无连接”的，而与之相对应的Hard state就是“面向连接”的。
        .Eventual consistency：最终一致性，最终整个系统（时间和系统的要求有关）看到的数据是一致的。
        在BASE中，强调可用性的同时，引入了最终一致性这个概念，不像ACID，其并不需要每个事务都是一致的，只需要整个系统经过一定时间后最终达到一致。比如Amazon的卖书系统，也许在卖的过程中，每个用户看到的库存数是不一样的，但最终卖完后，库存数都为0。再比如SNS网络中，C更新状态，A也许可以1分钟就看到，而B甚至5分钟后才看到，但最终大家都可以看到这个更新。
        具体地说，如果选择了CP（一致性和分区容忍性），那么就要考虑ACID理论（传统关系型数据库的基石，事务的四个特点）。如果选择了AP（可用性和分区容忍性），那么就要考虑BASE系统。如果选择了CA（一致性和可用性），如Google的bigtable，那么在网络发生分区的时候，将不能进行完整的操作。
        ACID理论和BASE的具体对比如下表所示。
        
        ACID和BASE的对比表
   题号导航      2014年下半年 系统架构设计师 下午试卷 论文   本试卷我的完整做题情况  
1 /
2 /
3 /
4 /
 
第1题    在手机中做本题