第十章、算法分析与设计

1.算法的特性

• 算法（Algorithm）是对特定问题求解步骤的一种描述，它是指令的有限序列，其中每**一条指令表示一个或多个操作。**此外，一个算法还具有下列5个重要特性。
  • 有穷性。一个算法必须总是（对任何合法的输入值）在执行有穷步之后结束，且每一步都可在有穷时间内完成。
  • 确定性。算法中的每一条指令必须有确切的含义，理解时不会产生二义性。并且在任何条件下，算法只有唯一的一条执行路径，即对于相同的输入只能得出相同的输出。
  • 可行性。一个算法是可行的，即算法中描述的操作都可以通过已经实现的基本运算执行有限次来实现。
  • 输入。一个算法有零个或多个输入，这些输入取自于某个特定的对象的集合。
  • 输出。一个算法有一个或多个输出，这些输出是同输入有着某些特定关系的量。

2.算法的复杂度

• 算法的时间复杂度分析：主要是分析算法的运行时间，即算法**执行所需要的基本操作数。不同规模的输入所需要的基本操作数是不相同。**在算法分析中，可以建立以输入规模n为自变量的函数T（n）来表示算法的时间复杂度。

• 即使对于**相同的输入规模，数据分布不相同也影响了算法执行路径的不同，**因此所需要的执行时间也不同。根据不同的输入，将算法的时间复杂度分析分为3种情况：最佳情况、最坏情况、平均情况。

• 渐进符号：以输入规模n为自变量建立的时间复杂度实际上还是较复杂的，例如an^2+bn+c，不仅与输入规模有关，还与系数a、b和c有关。此时可以**对该函数做进一步的抽象，仅考虑运行时间的增长率或称为增长的量级，**如忽略上式中的低阶项和高阶项的系数，仅考虑n^2。**当输入规模大到只有与运行时间的增长量级有关时，就是在研究算法的渐进效率。**也就是说，**从极限角度看，只关心算法运行时间如何随着输入规模的无限增长而增长。**下面简单介绍3种常用的标准方法来简化算法的渐进分析。

  

3.递归

• 递归是指子程序（或函数）直接调用自己或通过一系列调用语句**间接调用自己，**是一种描述问题和解决问题的常用方法。递归有两个基本要素：边界条件，即确定递归到何时终止，也称为递归出口；递归模式，即大问题是如何分解为小问题的，也称为递归体。

• 阶乘函数可递归地定义为：

  

• 阶乘函数的自变量n的定义域是非负整数。递归式的**第一式给出了这个函数的一个初始值，是递归的边界条件。递归式的第二式是用较小自变量的函数值来表示较大自变量的函数值的方式来定义n的阶乘，**是递归体。n！可以递归地计算

  

• 递归算法的时间复杂度分析方法：将递归式中等式右边的项根据递归式进行替换，称为展开。展开后的项被再次展开，如此下去，直到得到一个求和表达式，得到结果。 下面书上例子有误，应该是T（n）=T（n-1）+n

  

考试真题

• 已知算法A的运行时间函数为T（n）=8T（n/2）+n^2，其中n表示问题的规模，则该算法的时间复杂度为（D）另已知算法B的运行时间函数为T（n）=XT（n/4）+n^2，其中n表示问题的规模。对充分大的n，若要算法B比算法A快，则X的最大值为（C）。

  

算法设计方法

1.分治法

• 分治法的设计思想是**将一个难以直接解决的大问题分解成一些规模较小的相同问题，以便各个击破，分而治之。**如果规模为n的问题可分解成k个子问题，1<k<=n，这些子问题互相独立且与原问题相同。分治法产生的子问题往往是原问题的较小模式，这就为递归技术提供了方便。
• 一般来说，分治算法在每一层递归上都有3个步骤。
  • （1）分解。将原问题分解成一系列子问题。
  • （2）求解。递归地求解各子问题。若子问题足够小则直接求解。
  • （3）合并。将子问题的解合并成原问题的解。
• 凡是涉及到分组解决的都是分治法，例如归并排序算法完全依照上述分治算法的3个步骤进行。
  • （1）分解。将n个元素分成各含n/2个元素的子序列。
  • （2）求解。用归并排序对两个子序列递归地排序。
  • （3）合并。合并两个已经排好序的子序列以得到排序结果。

2.动态规划法

• 动态规划算法与分治法类似，**其基本思想也是将待求解问题分解成若干个子问题，先求解子问题，然后从这些子问题的解得到原问题的解。**与分治法不同的是，适合用动态规划法求解的问题，**经分解得到的子问题往往不是独立的。**若用分治法来解这类问题，则相同的子问题会被求解多次，以至于最后解决原问题需要耗费指数级时间。

• 然而，不同子问题的数目常常只有多项式量级。如果能够保存已解决的子问题的答案，在需要时再找出已求得的答案，这样就可以避免大量的重复计算，从而得到多项式时间的算法。为了达到这个目的，可以**用一个表来记录所有已解决的子问题的答案。**不管该子问题以后是否被用到，**只要它被计算过，就将其结果填入表中。**这就是动态规划法的基本思路。

• 动态规划算法通常用于求解具有某种最优性质的问题。在这类问题中，可能会有许多可行解，每个解都对应于一个值，我们希望找到**具有最优值（最大值或最小值）的那个解。**当然，最优解可能会有多个，动态规划算法能找出其中的一个最优解。设计一个动态规划算法，通常按照以下几个步骤进行。

  • （1）**找出最优解的性质，**并刻画其结构特征。
  • （2）递归地定义最优解的值。
  • （3）以自底向上的方式计算出最优值。
  • （4）根据计算最优值时得到的信息，构造一个最优解。

• 步骤（1）~（3）是动态规划算法的基本步骤。在只需要求出最优值的情形下，步骤（4）可以省略。若需要求出问题的一个最优解，则必须执行步骤（4）.

• 对于一个给定的问题，若其具有以下两个性质，可以考虑用动态规划法来求解。

  • （1）最优子结构。如果**一个问题的最优解中包含了其子问题的最优，**也就是说该问题具有最优子结构。当一个问题具有最优子结构时，提示我们动态规划法可能会适用，但是此时贪心策略可能也是适用的。
  • （2）重叠子问题。重叠子问题指**用来解原问题的递归算法可反复地解同样的子问题，而不是总在产生新的子问题。**即当一个递归算法不断地调用同一个问题时，就说该问题包含重叠子问题。

• 典型应用：0-1背包问题。

  • 有n个物品，第i个物品价值为vi，重量为wi，其中vi和wi均为非负数，背包的容量为w，w为非负数。现需要考虑如何选择装入背包的物品，使装入背包的物品总价值最大。

  • 满足约束条件的任一集合（x1，x2，...，xn）是问题的一个可行解，问题的目标是要求问题的一个最优解。考虑一个实例，假设n=5，W=17，每个物品的价值和重量如表所示，可将物品1、2和5装入背包，背包未满，获得价值22，此时问题解为（1，1，0，0，1）；也可以将物品4 和5 装入背包，背包装满，获得价值24，此时解为（0，0，0，1，1）。

    

  • （1）刻画0-1背包问题的最优解的结构。 可以将背包问题的求解过程看作是进行一系列的决策过程，即决定哪些物品应该放入背包，哪些物品不放入背包。如果一个问题的最优解包含了物品n，即xn=1，那么其余x1，x2，.，xn-1一定构成子问题1，2，.n-1 在容量为W-wn时的最优解。如果这个最优解不包含物品n，即xn=0，那么其余x1，x2，...，xn-1一定构成子问题1，2，.，n-1在容量为w时的最优解。

  • （2）递归定义最优解的值。 根据上述分析的最优解的结构递归地定义问题最优解。设c[i，w]表示背包容量为w时i个物品导致的最优解的总价值，得到下式。显然，问题要求c[n，W]。

    

3.贪心法

• 和动态规划法一样，贪心法也经常用于解决最优化问题。与动态规划法不同的是，贪心法在解决问题的策略上是仅根据当前已有的信息做出选择，而且一旦做出了选择，不管将来有什么结果，这个选择都不会改变。换而言之，贪心法并不是从整体最优考虑，它所做出的选择只是在某种意义上的局部最优。这种局部最优选择并不能保证总能获得全局最优解，但通常能得到较好的近似最优解。

• 贪心法问题一般具有两个重要的性质。

  • 最优子结构。当一个问题的最优解包含其子问题的最优解时，称此问题具有最优子结构。问题具有最优子结构是该问题可以采用动态规划法或者贪心法求解的关键性质。
  • 贪心选择性质。指问题的整体最优解可以通过一系列局部最优的选择，即贪心选择来得到。这是贪心法和动态规划法的主要区别。证明一个问题具有贪心选择性质也是贪心法的一个难点。

• 贪心法典型应用：背包问题。

• 背包问题的定义与0-1 背包问题类似，但是每个物品可以部分装入背包，即在0-1 背包问题中，xi=0 或者xi=1；而在背包问题中，0<=xi<=1。

• 为了更好地分析该问题，考虑一个例子：n=5，W=100，下表给出了各个物品的重量、价值和单位重量的价值。假设物品已经按其单位重量的价值从大到小排好序。

  

• 为了得到最优解，必须把背包放满。现在用贪心策略求解，首先要选出度量的标准。

  • 按最大价值先放背包的原则。
  • 按最小重量先放背包的原则。
  • 按最大单位重量价值先放背包的原则。

4.回溯法

• 概念：有"通用的解题法”之称，可以系统地搜索一个问题的所有解或任一解。在包含问题的所有解的解空间树中，按照深度优先的策略，从根节点出发搜索解空间树。搜索至任一结点时，总是先判断该结点是否肯定不包含问题的解，如果不包含，则跳过对以该结点为根的子树的搜索，**逐层向其祖先结点回溯；**否则，进入该子树，继续按深度优先的策略进行搜索。
• 可以理解为先进行深度优先搜索，一直向下探测，当此路不通时，返回上一层探索另外的分支，重复此步骤，这就是回溯，意为先一直探测，当不成功时再返回上一层。
• 一般用于解决迷宫类的问题。

考试真题

答案：C A D B

• 在一条笔直公路的一边有许多房子，现要安装消防栓，每个消防栓的覆盖范围远大于房子的面积，如下图所示。现求解能覆盖所有房子的最少消防栓数和安装方案（问题求解过程中，可将房子和消防栓均视为直线上的点）。

  

  该问题求解算法的基本思路为：从左端的第一栋房子开始，在其右侧 m 米处安装一个消防栓，去掉被该消防栓覆盖的所有房子。在剩余的房子中重复上述操作，直到所有房子被覆盖。算法采用的设计策略为（）；对应的时间复杂度为（）。假设公路起点A的坐标为0，消防栓的覆盖范围（半径）为20米，10栋房子的坐标为（10，20，，30，35，60，80，160，210，260，300），单位为米。根据上述算法，共需要安装（）个消防栓。以下关于该求解算法的叙述中，正确的是（）。

  （62）A.分治 B.动态规划 C.贪心 D.回溯

  （63）A. O(lgn) B. O(n) C. O(nlgn) D. O(n2)

  （64） A.4 B.5 C. 6 D.7

  （65）

  ​ A.肯定可以求得问题的一个最优解

  ​ B.可以求得问题的所有最优解

  ​ C.对有些实例，可能得不到最优解

  ​ D.只能得到近似最优解

  答案：C B B C

5.分支限界法

• 原理：在分支限界法中，**每一个活结点只有一次机会成为扩展结点。活结点一旦成为扩展结点，就一次性产生其所有儿子结点。**在这些儿子结点中，**导致不可行解或导致非最优解的儿子结点被舍弃，其余儿子结点被加入活结点表中。**此后，**从活结点表中取下一结点成为当前扩展结点，**并重复上述结点扩展过程。这个过程一直持续到找到所需的解或活结点表为空时为止。
• 与回溯法的区别：
  • 1、求解目标是找出满足约束条件的一个解，或是在满足约束条件的解中找出使某一目标函数值达到极大或极小的解，即在某种意义下的最优解。
  • 2、以广度优先或以最小耗费（最大收益）优先的方式搜索解空间树。
• 从活节点表中选择下一个扩展节点的类型：
  • 队列式（FIFO）分支限界法：按照队列先进先出（FIFO）原则选取下一个节点为扩展节点。
  • 优先队列式分支限界法：按照优先队列中规定的优先级选取优先级最高的节点成为当前扩展节点。

6.概率算法

• 原理：在算法执行某些步骤时，可以随机地选择下一步该如何进行，同时允许结果以较小的概率出现错误，并以此为代价，获得算法运行时间的大幅度减少（降低算法复杂度）。
• 基本特征是对所求解问题的同一实例用同一概率算法求解两次，可能得到完全不同的效果。
• 如果一个问题没有有效的确定性算法可以在一个合理的时间内给出解，但是该问题能接受小概率错误，那么采用概率算法就可以快速找到这个问题的解。
• 四类概率算法：数值概率算法（数值问题的求解）、蒙特卡洛算法（求问题的精确解）、拉斯维加斯算法（不会得到不正确的解）、舍伍德算法（总能求得问题的一个正确解）。
• 概率算法的特征： （1）概率算法的输入包括两部分，一部分是原问题的输入，另一部分是一个供算法进行随机选择的随机数序列。 （2）概率算法在运行过程中，包括一处或多处随机选择，根据随机值来决定算法的运行路径。 （3）概率算法的结果不能保证一定是正确的，但能限制其出错概率。 （4）概率算法在不同的运行过程中，对于相同的输入实例可以有不同的结果，因此，对于相同的输入实例，概率算法的执行时间可能不同。

7.近似算法

• 原理：解决难解问题的一种有效策略，其基本思想是放弃求最优解，而用近似最优解代替最优解，以换取算法设计上的简化和时间复杂度的降低。
• 虽然它可能找不到一个最优解，但它总会给待求解的问题提供一个解。
• 为了具有实用性，近似算法必须能够给出算法所产生的解与最优解之间的差别或者比例的一个界限，它保证任意一个实例的近似最优解与最优解之间的相差程度。显然，这个差别越小，近似算法越具有实用性。
• 衡量近似算法性能两个标准： （1）算法的时间复杂度。近似算法的时间复杂度必须是多项式阶，的这是近似算法的基本目标。 （2）解的近似程度。近似最优解的近似程度也是设计近似算法的重要目标。近似程度与近似算法本身、问题规模，乃至不同的输入实例有关。

人工智能算法

1.数据挖掘算法

• 分析爆炸式增长的各类数据的技术，以发现隐含在这些数据中的有价值的信息和知识。数据挖掘利用机器学习方法对多种数据进行分析和挖掘。其核心是算法，主要功能包括分类、回归、关联规则和聚类等。
• 分类
  • 是一种有监督的学习过程，根据历史数据预测未来数据的模型。
  • 分类的数据对象属性：一般属性、分类属性或目标属性。
  • 分类设计的数据：训练数据集、测试数据集、未知数据。
  • 数据分类的两个步骤：学习模型（基于训练数据集采用分类算法建立学习模型）、应用模型（应用测试数据集的数据到学习模型中，根据输出来评估模型的好坏以及将未知数据输入到学习模型中，预测数据的类型）。
  • 分类算法：决策树归纳（自顶向下的递归树算法）、朴素贝叶斯算法、后向传播BP、支持向量机SVM。
• 频繁模式和关联规则挖掘
  • 挖掘海量数据中的频繁模式和关联规则可以有效地指导企业发现交叉销售机会、进行决策分析和商务管理等。（沃尔玛-啤酒尿布故事）
  • 首先要求出数据集中的频繁模式，然后由频繁模式产生关联规则。
  • 关联规则挖掘算法：类Apriori算法、基于频繁模式增长的方法如FP-growthh，使用垂直数据格式的算法，如ECLAT.
• 聚类
  • 是一种**无监督学习过程。根据数据的特征，将相似的数据对象归为一类，**不相似的数据对象归到不同的类中。物以类聚，人以群分。
  • 典型算法：基于划分的方法、基于层次的方法、基于密度的方法、基于网格的方法、基于统计模型的方法。
• 数据挖掘的应用：数据挖掘在多个领域已有成功的应用。在银行和金融领域，可以进行贷款偿还预测和顾客信用政策分析、针对定向促销的顾客分类与聚类、洗黑钱和其他金融犯罪侦破等；在零售和电信业，可以进行促销活动的效果分析、顾客忠诚度分析、交叉销售分析、商品推荐、欺骗分析等。

2.智能优化算法

• 优化技术是一种以数学为基础，用于求解各种工程问题优化解的应用技术。
• 人工神经网络ANN：一个以有向图为拓扑结构的动态系统，通过对连续或断续的输入作状态响应而进行信息处理。从信息处理角度对人脑神经元网络进行抽象，建立某种简单模型，按不同的连接方式组成不同的网络。
• 遗传算法：源于模拟达尔文的“优胜劣汰、适者生存”的进化论和孟德尔.摩根的遗传变异理论，在迭代过程中保持已有的结构，同时寻找更好的结构。其本意是在人工适应系统中设计一种基于自然的演化机制。
• 模拟退火算法SA：求解全局优化算法。基本思想来源于物理退火过程，包括三个阶段：加温阶段、等温阶段、冷却阶段。将固体加温至充分高，再让其徐徐冷却，加温时，固体内部粒子随温升变为无序状，内能增大，而徐徐冷却时粒子渐趋有序，在每个温度都达到平衡态，最后在常温时达到基态，内能减为最小。
• 禁忌搜索算法TS：模拟**人类智力过程的一种全局搜索算法，是对局部邻域搜索的一种扩展。从一个初始可行解出发，选择一系列的特定搜索方向（移动）一作为试探，选择实现让特定的目标函数值变化最多的移动。为了避免陷入局部最优解，TS搜索中采用了一种灵活的“记忆”技术，对已经进行的优化过程进行记录和选择，指导下一步的搜索方向，**这就是Tabu表的建立。
• 蚁群算法
• 是一种用来寻找优化路径的概率型算法。
• 单个蚂蚁的行为比较简单，但是蚁群整体却可以体现一些智能的行为。例如蚁群可以在不同的环境下，寻找最短到达食物源的路径。这是因为蚁群内的蚂蚁可以通过某种信息机制实现信息的传递。后又经进一步研究发现，蚂蚁会在其经过的路径上释放一种可以称之为“信息素”的物质，蚁群内的蚂蚁对“信息素”具有感知能力，它们会沿着“信息素”浓度较高路径行走，而每只路过的蚂蚁都会在路上留下“信息素”，这就形成一种类似正反馈的机制，这样经过一段时间后，整个蚁群就会沿着最短路径到达食物源了。
• 用蚂蚁的行走路径表示待优化问题的可行解，整个蚂蚁群体的所有路径构成待优化问题的解空间。路径较短的蚂蚁释放的信息素量较多，随着时间的推进，较短的路径上累积的信息素浓度逐渐增高，选择该路径的蚂蚁个数也愈来愈多。最终，整个蚂蚁会在正反馈的作用下集中到最佳的路径上，此时对应的便是待优化问题的最优解。
• 粒子群优化算法PSO
• 设想这样一个场景：一群鸟在随机搜索食物。在这个区域里只有一块食物。所有的鸟都不知道食物在那里。但是**他们知道当前的位置离食物还有多远。**那么找到食物的最优策略是什么呢。最简单有效的就是搜寻目前离食物最近的鸟的周围区域。
• PSO从这种模型中得到启示并用于解决优化问题。PSO中，**每个优化问题的解都是搜索空间中的一只鸟。我们称之为“粒子”。所有的粒子都有一个由被优化的函数决定的适应值（fitness value），每个粒子还有一个速度决定他们飞翔的方向和距离。**然后粒子们就追随当前的最优粒子在解空间中搜索。
• PSO初始化为一群随机粒子（随机解）。然后通过迭代找到最优解。在每一次迭代中，粒子通过跟踪两个"极值"来更新自己。**第一个就是粒子本身所找到的最优解，这个解叫做个体极值pBest。另一个极值是整个种群目前找到的最优解，这个极值是全局极值gBest。**另外也可以不用整个种群而只是用其中一部分作为粒子的邻居，那么在所有邻居中的极值就是局部极值。

第十一章、软件工程基础知识

1.信息系统生命周期

• 软件工程基本原理：用分阶段的生命周期计划严格管理、坚持进行阶段评审、实现严格的产品控制、采用现代程序设计技术、结果应能清楚的审查、开发小组的人员应少而精、承认不断改进软件工程实践的必要性。

• 软件工程的基本要素：方法、工具、过程。

• 软件生存周期：可行性分析与项目开发计划、需求分析、概要设计（选择系统解决方案，规划子系统）、详细设计（设计子系统内部具体实现）、编码、测试、维护。

• 1.系统规划阶段（立项）：任务是对组织的环境、目标及现行系统的状况进行初步调查，根据组织目标和发展战略确定信息系统的发展战略，对建设新系统的需求做出分析和预测，同时考虑建设新系统所受的各种约束，研究建设新系统的必要性和可能性。根据需要与可能，给出制建系统的备选方案。

  输出：可行性研究报告、系统设计任务书。

• 2.系统分析阶段（开发）：任务是根据系统设计任务书所确定的范围，对现行系统进行详细调查，描述现行系统的业务流程，指出现行系统的局限性和不足之处，确定新系统的基本目标和逻辑功能要求，即提出新系统的逻辑模型。系统分析阶段又称为逻辑设计阶段。这个阶段是整个系统建设的关键阶段，也是信息系统建设与一般工程项目的重要区别所在。

  输出：系统说明书。

• 3.系统设计阶段（开发）：系统分析阶段的任务是回答系统“做什么”的问题，而系统设计阶段要回答的问题是"怎么做”。该阶段的任务是根据系统说明书中规定的功能要求，具体设计实现逻辑模型的技术方案，也就是设计新系统的物理模型。这个阶段又称为物理设计阶段，可分为总体设计（概要设计）和详细设计两个子阶段。 输出：系统设计说明书（概要设计、详细设计说明书）。

• 4.系统实施阶段（开发）：是**将设计的系统付诸实施的阶段。**这一阶段的任务包括计算机等设备的购置、安装和调试、程序的编写和调试、人员培训、数据文件转换、系统调试与转换等。这个阶段的特点是几个互相联系、互相制约的任务同时展开，必须精心安排、合理组织。系统实施是按实施计划分阶段完成的，每个阶段应写出实施进展报告。系统测试之后写出系统测试分析报告。 输出：实施进展报告、系统测试分析报告。

• 5.系统运行和维护阶段（运维）：系统投入运行后，需要经常进行维护和评价，记录系统运行的情况，根据一定的规则对系统进行必要的修改，评价系统的工作质量和经济效益。

能力成熟度模型CMM

2.能力成熟度模型

• 能力成熟度模型集成CMMI是若干过程模型的综合和改进，不仅仅软件，而是支持多个工程学科和领域的、系统的、一致的过程改进框架，能适应现代工程的特点和需要，能提高过程的质量和工作效率。 CMMI两种表示方法：

  （1）阶段式模型：类似于CMM，它关注组织的成熟度，五个成熟度模型如下：

  

• 2.连续式模型：关注每个过程域的能力，一个组织对不同的过程域可以达到不同的过程域能力等级。

考试真题

• （B）是系统分析阶段结束后得到的工作产品，（D）是系统测试阶段完成后的工作产品。

  A.系统设计规格说明 B.系统方案建议书 C.程序规格说明 D.单元测试数据

  A.验收测试计划 B.测试标准 C.系统测试计划 D.操作手册

• 以下关于CMM的叙述中，不正确的是（B）。

  A.CMM是指软件过程能力成熟度模型 B.CMM根据软件过程的不同成熟度划分了5个等级，其中，1级被认为成熟度最高，5级被认为成熟度最低 C.CMMI的任务是将已有的几个CMM模型结合在一起，使之构造成为"集成模型" D.采用更成熟的CMM模型，一般来说可以提高最终产品的质量

3.软件过程模型

• 瀑布模型（SDLC）：瀑布模型是一个经典的软件生命周期模型，一般将软件开发分为：可行性分析（计划）、需求分析、软件设计（概要设计、详细设计）、编码（含单元测试）、测试、运行维护等几个阶段。

• 瀑布模型特点 （1）从上一项开发活动接受该项活动的工作对象作为输入。 （2）利用这一输入，实施该项活动应完成的工作内容。 （3）给出该项活动的工作成果，作为输出传给下一项开发活动。 （4）对**该项活动的实施工作成果进行评审。**若其工作成果得到确认，则继续进行下一项开发活动；否则返回前一项，甚至更前项的活动。尽量减少多个阶段间的反复。以相对来说较小的费用来开发软件

• 螺旋模型是一个演化软件过程模型，将原型实现的迭代特征与线性顺序（瀑布）模型中控制的和系统化的方面结合起来。在螺旋模型中，软件开发是一系列的增量发布。
• 开发过程具有周期性重复的螺旋线状。四个象限分别标志每个周期所划分的四阶段：制订计划、风险分析、实施工程和客户评估。螺旋模型强调了风险分析，特别适用于庞大而复杂的、高风险的系统。

• v模型从整体上看起来，就是一个v字型的结构，由左右两边组成。左边的下画线分别代表了需求分析、概要设计、详细设计、编码。右边的上画线代表了单元测试、集成测试、系统测试与验收测试。v模型的特点如下 （1）单元测试的主要目的是针对编码过程中可能存在的各种错误； （2）集成测试的主要目的是针对详细设计中可能存在的问题； （3）系统测试主要针对概要设计，检查系统作为一个整体是否有效地得到运行； （4）验收测试通常由业务专家或者用户进行，以确认产品能真正符合用户业务上的需要。 （5）v模型用于需求明确和需求变更不频繁的情形。

• 原型化模型第一步就是创建一个快速原型，能够满足项目干系人与未来的用户可以与原型进行交互，再通过与相关干系人进行充分的讨论和分析，最终弄清楚当前系统的需求，进行了充分的了解之后，在原型的基础上开发出用户满意的产品。

• 原型法认为在很难一下子全面准确地提出用户需求的情况下，原型应当具备的特点如下。

  （1）实际可行 （2）具有最终系统的基本特征 （3）构造方便、快速，造价低。原型法的特点在于原型法对用户的需求是动态响应、逐步纳入的。

• 增量模型：首先开发核心模块功能，而后与用户确认，之后再开发次核心模块的功能，即每次开发一部分功能，并与用户需求确认，最终完成项目开发，优先级最高的服务最先交付。

• 特点：但由于并不是从系统整体角度规划各个模块，因此不利于模块划分。难点在于如何将客户需求划分为多个增量。与原型不用的是**增量模型的每一次增量版本都可作为独立可操作的作品，**而原型的构造一般是为了演示。

  

• 喷泉模型：是一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。使开发过程具有迭代性和无间隙性。

• 基于构件的开发模型CBSD：利用预先包装的构件来构造应用系统。构件可以是组织内部开发的构件，也可以是商品化成品软件构件。 特点是增强了复用性，在系统开发过程中，会构建一个构件库，供其他系统复用，因此可以提高可靠性，节省时间和成本。

• 形式化方法模型：建立在严格数学基础上的一种软件开发方法，主要活动是生成计算机软件形式化的数学规格说明。

考试真题

• 假设某软件公司与客户签订合同开发一个软件系统，系统的功能有较清晰的定义，且客户对交付时间有严格要求，则该系统的开发最适宜采用（A） A.瀑布模型 B.原型模型 C.v模型 D.螺旋模型

• 以下关于螺旋模型的叙述中，不正确的是（D）

  A.它是风险驱动的，要求开发人员必须具有丰富的风险评估知识和经验

  B.它可以降低过多测试或测试不足带来的风险

  C.它包含维护周期，因此维护和开发之间没有本质区别

  D.它不适用于大型软件开发

4.信息系统开发方法

• 结构是指系统内各个组成要素之间的相互联系、相互作用的框架。

• 结构化方法也称为生命周期法，是一种传统的信息系统开发方法，**由结构化分析（Structured Analysis，SA）、结构化设计（Structured Design，SD）和d结构化程序设计（Structured Programming，SP）**三部分有机组合而成，其精髓是自顶向下、逐步求精和模块化设计。

• 结构化方法的主要特点 （1）开发目标清晰化。结构化方法的系统开发遵循**“用户第一”**的原则。

  （2）开发工作阶段化。每个阶段工作完成后，要根据阶段工作目标和要求进行审查，这使各阶段工作有条不紊地进行，便于项目管理与控制。 （3）开发文档规范化。结构化方法每个阶段工作完成后，要按照要求完成相应的文档，以保证各个工作阶段的衔接与系统维护工作的遍历。 （4）设计方法结构化。在系统分析与设计时，从整体和全局考虑，自顶向下地分解；在系统实现时，根据设计的要求，先编写各个具体的功能模块，然后自底向上逐步实现整个系统。

• 结构化方法的不足和局限 （1）开发周期长：按顺序经历各个阶段，直到实施阶段结束后，用户才能使用系统。 （2）难以适应需求变化：不适用于需求不明确或经常变更的项目。 （3）很少考虑数据结构：结构化方法是一种面向过程，面向数据流的开发方法，很少考虑数据结构。

• 结构化方法常用工具 结构化方法一般利用图形表达用户需求，常用工具有数据流图、数据字典、结构化语言、判定表以及判定树等。

• 面向对象（Object-Oriented，OO）方法认为，客观世界是由各种对象组成的，**任何事物都是对象，每一个对象都有自己的运动规律和内部状态，都属于某个对象类，**是该对象类的一个元素。复杂的对象可由相对简单的各种对象以某种方式而构成，不同对象的组合及相互作用就构成了系统。

• 面向对象方法的特点 （1）使用OO方法构造的系统具有更好的复用性，其关键在于建立一个全面、合理、统一的模型（用例模型和分析模型）。 （2）OO方法也划分阶段，但其中的系统分析、系统设计和系统实现三个阶段之间已经没有“缝隙”。也就是说，这三个阶段的界限变得不明确，某项工作既可以在前一个阶段完成，也可以在后一个阶段完成；前一个阶段工作做得不够细，在后一个阶段可以补充。 （3）面向对象方法可以普遍适用于各类信息系统的开发。

• 面向对象方法的不足之处必须依靠一定的面向对象技术支持，在大型项目的开发上具有一定的局限性，不能涉足系统分析以前的开发环节。

• 当前，一些大型信息系统的开发，通常是将**结构化方法和OO方法结合起来。**首先，使用结构化方法进行自顶向下的整体划分；然后，自底向上地采用OO方法进行开发。因此，结构化方法和OO方法仍是两种在系统开发领域中相互依存的、不可替代的方法。.

  

• 原型化方法也称为快速原型法，或者简称为原型法。它是一种根据用户初步需求，利用系统开发工具，快速地建立一个系统模型展示给用户，在此基础上与用户交流，最终实现用户需求的信息系统快速开发的方法。

• 按是否实现功能分类：分为水平原型（行为原型，功能的导航）、垂直原型（结构化原型，实现了部分功能）。

• 按最终结果分类：分为抛弃式原型、演化式原型。

• 原型法的特点 原型法可以使系统开发的周期缩短、成本和风险降低、速度加快，获得较高的综合开发效益。 原型法是以用户为中心来开发系统的，用户参与的程度大大提高，开发的系统符合用户的需求，因而增加了用户的满意度，提高了系统开发的成功率。 由于用户参与了系统开发的全过程，**对系统的功能和结构容易理解和接受，**有利于系统的移交，有利于系统的运行与维护。

• 原型法的不足之处开发的环境要求高。管理水平要求高。

• 由以上的分析可以看出，原型法的优点主要在于能更有效地确认用户需求。从直观上来看，原型法适用于那些需求不明确的系统开发。事实上，对于分析层面难度大、技术层面难度不大的系统，适合于原型法开发。

• 从严格意义上来说，目前的原型法不是一种独立的系统开发方法，而只是一种开发思想，它只支持在系统开发早期阶段快速生成系统的原型，没有规定在原型构建过程中必须使用哪种方法。因此，它不是完整意义上的方法论体系。这就注定了原型法必须与其他信息系统开发方法结合使用。

• 敏捷开发是一种**以人为核心、迭代、循序渐进的开发方法，**相对于传统软件开发方法的“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发中人的作用。

• 敏捷软件开发宣言：

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

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

  3.客户合作胜过合同谈判

  4.响应变化胜过遵循计划

• 结对编程：**一个程序员开发，另一个程序在一旁观察审查代码，**能够有效的提高代码质量，在开发同时对代码进行初步审查，共同对代码负责。

• 自适应开发：强调开发方法的适应性（Adaptive）。不象其他方法那样有很多具体的实践做法，它更侧重为软件的重要性提供最根本的基础，并从更高的组织和管理层次来阐述开发方法为什么要具备适应性。

• 水晶方法：每一个不同的项目都需要一套不同的策略、约定和方法论。

• 特性驱动开发：是一套针对中小型软件开发项目的开发模式。是一个模型驱一动的快速迭代开发过程，它强调的是简化、实用、易于被开发团队接受，适用于需求经常变动的项目。

• 极限编程XP：核心是沟通、简明、反馈和勇气。因为知道计划永远赶不上变化，XP无需开发人员在软件开始初期做出很多的文档。XP提倡测试先行，为了。将以后出现bug的几率降到最低。

• 并列争球法SCRUM：是一种迭代的增量化过程，把每段时间（30天）一次的迭代称为一个"冲刺”，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

• 统一过程（RUP）提供了在开发组织中分派任务和责任的纪律化方法。它的目标是在可预见的日程和预算前提下，确保满足最终用户需求的高质量产品。

• 3个显著特点：用例驱动、以架构为中心、迭代和增量。

• 4个流程：**初始阶段、细化阶段、构建阶段和交付阶段。**每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经达到。

• 适用：一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同性能水平和不同的项目规模。

考试真题

• 以下关于结构化开发方法的叙述中，不正确的是（C）。

  A.总的指导思想是自顶向下，逐层分解

  B.基本原则是功能的分解与抽象

  C.与面向对象开发方法相比，更适合于大规模、特别复杂的项目

  D.特别适合于数据处理领域的项目

• 在敏捷过程的开发方法中，（C）使用了迭代的方法，其中，把每段时间（30天）一次的迭代称为一个"冲刺”，并按需求的优先级别来实现产品，多个自组织和自治的小组并行地递增实现产品。

  A.极限编程XP B.水晶法 C.并列争球法 D.自适应软件开发

5.软件产品线

• 软件产品线是一个产品集合，这些产品**共享一个公共的、可管理的特征集，这个特征集能满足特定领域的特定需求。**软件产品线是一个十分适合专业的开发组织的软件开发方法，能有效地提高软件生产率和质量，缩短开发时间，降低总开发成本。 核心资源：包括所有产品所共用的软件架构，通用的构件、文档等。 产品集合：产品线中的各种产品。

• 产品线的建立方式

  

6.逆向工程

• 软件复用是将已有软件的各种有关知识用于建立新的软件，以缩减软件开发和维护的花费。软件复用是提高软件生产力和质量的一种重要技术。早期的软件复用主要是代码级复用，被复用的知识专指程序，后来扩大到包括领域知识、开发经验、设计决定、体系结构、需求、设计、代码和文档等一切有关方面。

• 逆向工程：软件的逆向工程是**分析程序，力图在比源代码更高抽象层次上建立程序的表示过程，逆向工程是设计的恢复过程。**逆向工程的四个级别：

  实现级：包括程序的抽象语法树、符号表、过程的设计表示。 结构级：包括反映程序分量之间相互依赖关系的信息，例如调用图、结构图、程序和数据结构。 功能级：包括反映程序段功能及程序段之间关系的信息，例如数据和控制流模型。 领域级：包括反映程序分量或程序诸实体与应用领域概念之间对应关系的信息，例如E-R模型。

  其中，领域级抽象级别最高，完备性最低，实现级抽象级别最低，完备性最高。

• 与逆向工程相关的概念有重构、设计恢复、再工程和正向工程。 （1）重构是指在同一抽象级别上转换系统描述形式。 （2）设计恢复是指借助工具从已有程序中抽象出有关数据设计、总体结构设计和过程设计等方面的信息。 （3）再工程是指**在逆向工程所获得信息的基础上，修改或重构已有的系统，产生系统的一个新版本。再工程是对现有系统的重新开发过程，包括逆向工程、新需求的考虑过程和正向工程三个步骤。**它不仅能从已存在的程序中重新获得设计信息，而且还能使用这些信息来重构现有系统，以改进它的综合质量。在利用再工程重构现有系统的同时，一般会增加新的需求，包括增加新的功能和改善系统的性能。 （4）正向工程是指不仅从现有系统中恢复设计信息，**而且使用该信息去改变或重构现有系统，**以改善其整体质量。

考试真题

• 应用系统构建中可以采用多种不同的技术，（A）可以将软件某种形式的描述转换为更高级的抽象表现形式，而利用这些获取的信息，（D）能够对现有系统进行修改或重构，从而产生系统的一个新版本。

  A.逆向工程（（Reverse Engineering） B.系统改进（System Improvement） C.设计恢复（DesignRecovery） D.再工程（Re-engineering）

  A.逆向工程（（Reverse Engineering） B.系统改进（System Improvement） C.设计恢复（DesignRecovery） D.再工程（Re-engineering）

• 在软件系统工具中，版本控制工具属于（），软件评价工具属于（）。

  A.软件开发工具 B.软件维护工具 C.编码与排错工具 D.软件管理和软件支持工具

  A.逆向工程工具 B.开发信息库工具 C.编码与排错工具 D.软件管理和软件支持工具

  答案：B D

  解析：软件系统工具通常可以按软件过程活动将软件工具分为软件开发工具、软件维护工具、软件管理和软件支持工具。软件开发工具：需求分析工具、设计工具、编码与排错工具。软件维护工具：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具。软件管理和软件支持工具：项目管理工具、配置管理工具、软件评价工具、软件开发工具的评价和选择。

软件需求

1.软件需求

• 软件需求：是指用户对系统在功能、行为、性能、设计约束等方面的期望。是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。

• 分为需求开发和需求管理两大过程，如下所示：

  

• 业务需求：反映企业或客户对系统高层次的目标要求，通常来自项目投资人、客户、市场营销部门或产品策划部门。通过业务需求可以确定项目视图和范围。

• 用户需求：描述的是**用户的具体目标，或用户要求系统必须能完成的任务。即描述了用户能使用系统来做什么。**通常采取用户访谈和问卷调查等方式，对用户使用的场景进行整理，从而建立用户需求。

• 系统需求：从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等。

  • 1）功能需求：也称为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要。
  • 2）非功能需求：指系统必须具备的属性或品质，又可以细分为软件质量属性（如可维护性、可靠性、效率等）和其他非功能需求。
  • 3）设计约束：也称为限制条件或补充规约，通常是对系统的一些约束说明，例如必须采用国有自主知识产权的数据库系统，必须运行在UNIX操作系统之下等。

• 质量功能部署 质量坊能部署（QFD）是一种**将用户要求转化成软件需求的技术，**其目的是最大限度地提升软件工程过程中用戸的满意度。为了达到这个目标，QFD将软件需求分为三类，分别是常规需求、期望需求和意外需求。

  • （1）常规需求。用户认为系统应该做到的功能或性能，实现越多用户会越满意。
  • （2）期望需求。用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想要得到的这些功能或性能需求。如果期望需求没有得到实现，会让用户感到不满意。
  • （3）意外需求。意外需求也称为兴奋需求，是用户要求范围外的功能或性能（但通常是软件开发人员很乐意赋予系统的技术特性），实现这些需求用户会更高兴，但不实现也不影响其购买的决策。

考试真题

• 软件需求开发是指从情况收集、分析和评价到编写文档、评审等一系列产生需求的活动，分为获取情况、分析、（A）和评审四个阶段。 A.制订规格说明 B.形成需求基线 C.跟踪需求变更 D.控制需求版本

• 某软件公司正在承担开发一个字处理器的任务。在需求分析阶段，公司的相关人员整理出一些相关的系统需求，其中，“找出文档中的拼写错误并提供一个替换项列表来供选择替换拼错的词’属于（）；"显示提供替换词的对话框以及实现整个文档范围的替换”属于（）；"用户能有效地纠正文档中的拼写错误”属于（）。

  A.业务需求 B.用户需求 C.功能需求 D.性能需求 A.业务需求 B.用户需求 C.功能需求 D.性能需求

  A.业务需求 B.用户需求 C.功能需求 D.性能需求

  答案：BCA

2.需求获取

• 需求获取：是一个确定和理解不同的项目干系人的需求和约束的过程。
• 常见的需求获取法包括： （1）用户访谈：1对1-3，有代表性的用户。其形式包括结构化和非结构化两种。 （2）问卷调查：用户多，无法一一访谈。 （3）采样：从种群中系统地选出有代表性的样本集的过程。样本数量=0.25* （可信度因子/错误率）2 （4）情节串联板：一系列图片，通过这些图片来讲故事。 （5）联合需求计划（JRP）：通过联合各个关键用户代表、系统分析师、开发团队代表一起，通过有组织的会议来讨论需求。 （6）需求记录技术：任务卡片、场景说明、用户故事、Volere白卡。

考试真题

• 需求获取是确定和理解不同的项目干系人的需求和约束的过程，需求获取是否科学、准备充分，对获取出来的结果影响很大。在多种需求获取方式中，（）方法具有良好的灵活性，有较宽广的应用范围，但存在获取需求时信息量大、记录较为困难、需要足够的领域知识等问题。（） 方法基于数理统计原理，不仅可以用于收集数据，还可以用于采集访谈用户或者是采集观察用户，。并可以减少数据收集偏差。（）方法通过高度组织的群体会议来分析企业内的问题，并从中获取系统需求。 A.用户访谈 B.问卷调查 C.联合需求计划 D.采样

  A.用户访谈 B.问卷调查 C.联合需求计划 D.采样

  A.用户访谈 B.问卷调查 C.联合需求计划 D.采样

  答案：A D C

3.需求分析

• 需求分析：一个好的需求应该具有无二义性、完整性、一致性、可测试性、确定性、可跟踪性、正确性、必要性等特性，因此，需要分析人员把杂乱无章的用户要求和期望转化为用户需求，这就是需求分析的工作。

• 需求分析的任务 （1）绘制系统上下文范围关系图（数据流图）

  （2）创建用户界面原型

  （3）分析需求的可行性

  （4）确定需求的优先级

  （5）为需求建立模型

  （6）创建数据字典

  （7）使用QFD（质量功能部署）

• 结构化的需求分析 结构化特点：自顶向下，逐步分解，面向数据。

  三大模型**：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E-R图）以及数据字典。**

  

• 状态转换图STD如下图所示：

  

• 数据流图描述数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模，数据流图相关概念如图：

• 数据流图是可以分层的，从顶层（即上下文无关数据流）到0层、1层等，顶层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。数据流图示例如下：

  

  

4.需求定义

• 需求定义（软件需求规格说明书SRS）：是需求开发活动的产物，编制该文档的目的是使项目干系人与开发团队对系统的初始规定有一个共同的理解，使之成为整个开发工作的基础。SRS是软件开发过程中最重要的文档之一，对于任何规模和性质的软件项目都不应该缺少。
• 需求定义方法 （1）严格定义也称为预先定义，需求的严格定义建立在以下的基本假设之上：所有需求都能够被预先定义。开发人员与用户之间能够准确而清晰地交流。采 用图形（或文字）可以充分体现最终系统。 （2）原型方法，迭代的循环型开发方式，需要注意的问题：并非所有的需求都能在系统开发前被准确地说明。项目干系人之间通常都存在交流上的困难，原型提供了**克该服困难的一个手段。**特点：需要实际的、可供用户参与的系统模型。有合适的系统开发环境。反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

5.需求验证

• 需求验证：也称为需求确认，目的是与用户一起确认需求无误，对需求规格说明书SAS进行评审和测试，包括两个步骤：
• 需求评审：正式评审和非正式评审。
• 需求测试：设计概念测试用例。
• 需求验证通过后，要请用户签字确认，作为验收标准之一，此时，这个需求规格说明书就是需求基线，不可以再随意更新，如果需要更改必须走需求变更流程。

6.需求管理

• 定义需求基线：通过了评审的需求说明书就是需求基线，下次如果需要变更需求，就需要按照流程来一步步进行。需求的流程及状态如下图所示：

  

• 需求变更和风险 主要关心需求变更过程中的需求风险管理，带有风险的做法有：无足够用户参与、忽略了用户分类、用户需求的不断增加、模棱两可的需求、不必要的特性、过于精简的SRS、不准确的估算。

• 变更产生的原因：外部环境的变化、需求和设计做的不够完整、新技术的出现、公司机构重组造成业务流程的变化。

• 变更控制委员会CCB：也称为配置控制委员会，其任务时对建议的配置项变更做出评价、审批，以及监督已经批准变更的实施。

  

• 双向跟踪，两个层次，如下图所示：

  

• 正向跟踪表示用户原始需求是否都实现了，反向跟踪表示软件实现的是否都是用户要求的，不多不少，可以用原始需求和用例表格（需求跟踪矩阵）来表示：

• 若原始需求和用例有对应，则在对应栏打对号，若某行都没有对号，表明原始需求未实现，正向跟踪发现问题；若某列都没有对号，表明有多余功能用例，软件实现了多余功能，反向跟踪发现问题。

考试真题

• （D）是关于需求管理正确的说法。

  A.为达到过程能力成熟度模型第二级，组织机构必须具有3个关键过程域

  B.需求的稳定性不属于需求属性

  C.需求变更的管理过程遵循变更分析和成本计算、问题分析和变更描述、变更实现的顺序

  D.变更控制委员会对项目中任何基线工作产品的变更都可以做出决定

• 在结构化分析中，用数据流图描述（）。当采用数据流图对一个图书馆管理系统进行分析时，（） 是一个外部实体。

  A.数据对象之间的关系，用于对数据建模

  B.数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模

  C.系统对外部事件如何响应，如何动作，用于对行为建模

  D.数据流图中的各个组成部分 A.读者 B.图书 C.借书证 D.借阅

  答案：B A

软件设计

1.处理流程设计

• 业务流程建模 标杆瞄准：以行业领先的标杆企业为目标，结合本企业情况分析建模。

  IDEF（一系列建模、分析和仿真方法的统称）

  DEMO（组织动态本质建模法）

  Petri网业务流程建模语言：BPEL、BPML、BPMN、XPDL。

  基于服务的BPM：基于Web服务的思想对业务流程进行建模。

• IDEFO：业务流程（功能）建模；

• IDEF1：信息建模；

• IDEF1X：数据建模（如ER模型）；

• IDEF2：仿真建模设计；

• IDEF3：过程描述获取；

• IDEF4：面向对象设计；

• IDEF5：本体论描述获取；

• IDEF6：设计原理获取；

• IDEF7：信息系统审计；

• IDEF8：用户界面建模；

• IDEF9：场景驱动信息系统设计；

• IDEF10：实施架构建模；

• IDEF11：信息制品建模；

• IDEF12：组织结构建模；

• IDEF13：三模式映射设计；

• IDEF14：网络规划。手瓷源

• 流程表示工具

• 程序流程图（Program Flow Diagram，PFD）用一些图框表示各种操作，它独立于任何一种程序设计语言，比较直观、清晰，易于学习掌握。任何复杂的程序流程图都应该由顺序、选择和循环结构组合或嵌套而成。

• IPO图也是流程描述工具，用来描述构成软件系统的每个模块的输入、输出和数据加工。

• N-S图容易表示嵌套和层次关系，并具有强烈的结构化特征。但是当问题很复杂时，N-s图可能很大，因此不适合于复杂程序的设计。

  

• 问题分析图（PAD）是一种支持结构化程序设计的图形工具。PAD具有清晰的逻辑结构、标准化的图形等优点，更重要的是，它引导设计人员使用结构化程序设计方法，从而提高程序的质量。

  

• 业务流程重组BPR

• BPR是对企业的业务流程进行根本性的再思考和彻底性的再设计，从而获得可以用诸如成本、质量、服务和速度等方面的业绩来衡量的显著性的成就。BPR设计原则、系统规划和步骤如下图所示：

  

• 业务流程管理BPM

• BPM是一种以规范化的构造端到端的卓越业务流程为中心，以持续的提高组织业务绩效为目的的系统化方法。

• BPM与BPR管理思想最根本的不同就在于流程管理并不要求对所有的流程进行再造。构造卓越的业务流程并不是流程再造，而是根据现有流程的具体情况，对流程进行规范化的设计

• 流程管理包含三个层面：规范流程、优化流程和再造流程

考试真题

• 流程设计的任务是设计出系统所有模块和它们之间的相互关系，并具体设计出每个模块内部的功能和处理过程。以下关于流程设计的叙述，正确的是（A）。

  A.任何复杂的程序流程图都应该由顺序、选择、循环结构构成

  B.IPO图不适合用来进行流程设计

  C.PAD图是一种支持原型化设计方法的图形工具

  D.N-S图容易表示嵌套关系和层次关系，特别适合于设计非常复杂的流程

• 业务流程重组（Business Process Reengineering，BPR）是针对企业业务流程的基本问题进行回顾，其核心思路是对业务流程的（）改造，BPR过程通常以（）为中心。

  A、增量式 B、根本性 C、迭代式 D、保守式 A、流程 B、需求 C、组织 D、资源

  答案：B A

2.系统设计

• 系统设计主要目的：为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，最终勾画出新系统的详细设计方法。

• 系统设计方法：结构化设计方法，面向对象设计方法。

• 系统设计的主要内容：概要设计、详细设计。

• 概要设计基本任务：又称为系统总体结构设计，是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的模块结构图，即系统结构图。

• 详细设计的基本任务：**模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计（代码、输入/输出格式、用户界面）、**编写详细设计说明书、评审。

• 系统设计基本原理

  抽象化；

  自顶而下，逐步求精；

  信息隐蔽；

  模块独立（高内聚，低耦合）。

• 系统设计原则 保持模块的大小适中；

  尽可能减少调用的深度；

  多扇入，少扇出；

  单入口，单出口；

  模块的作用域应该在模块之内；

  功能应该是可预测的。

考试真题.

• 系统设计是根据系统分析的结果，完成系统的构建过程。系统设计的主要内容包括（）；系统总体结构设计的主要任务是将系统的功能需求分配给软件模块，确定每个模块的功能和调用关系，形成软件的（）。

  A.概要设计和详细设计 B.架构设计和对象设计 C.部署设计和用例设计 D.功能设计和模块设计 A.用例图 B.模块结构图 C.系统部署图 D.类图

  答案：A B

• 以下关于软件系统模块结构设计的叙述中，正确的是（D）

  A.当模块扇出过大时，应把下级模块进一步分解为若十个子模块

  B.当模块扇田过亦时，应适当增加中间的控制模块

  C.模块的扇入大，表示模块的复杂度较高

  D.模块的扇入大，表示模块的复用程度高

3.人机界面设计

• 人机界面设计三大黄金原则：

软件测试

1.测试原则和方法

• 系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
• 测试原则： 应尽早并不断的进行测试； 测试工作应该避免由原开发软件的人或小组承担；在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果； 既包含有效、合理的测试用例，也包含不合理、失效的用例；检验程序是否做了该做的事，且是否做了不该做的事；严格按照测试计划进行； 妥善保存测试计划和测试用例； 测试用例可以重复使用或追加测试。
• 软件测试方法可分为静态测试和动态测试。
• 静态测试：指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测，包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试，包括桌前检查、代码审查、代码走查的方式。使用这种方法能够有效地发现30%-70%的 逻辑设计和编码错误。
• 动态测试：指在计算机上实际运行程序进行软件测试，一般采用白盒测试和黑盒测试方法。 黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。 白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。

2.测试阶段

• （1）单元测试：也称为模块测试，测试的对象是**可独立编译或汇编的程序模块、**软件构件或O0软件中的类飞统称为模块），测试依据是软件详细设计说明书。

• （2）集成测试：目的是检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求。测试依据是软件概要设计文档。

• （3）确认测试：主要用于**验证软件的功能、性能和其他特性是否与用户需求一致。**根据用户的参与程度，通常包括以下类型：

  内部确认测试：主要由软件开发组织内部按照SRS进行测试。

  Alpha测试：用户在开发环境下进行测试。

  Beta测试：用户在实际使用环境下进行测试，通过改测试后，产品才能交付用户。

  验收测试：**针对SRS，在交付前以用户为主进行的测试。**其测试对象为完整的、集成的计算机系统。验收测试的目的是，在真实的用户工作环境下，检验软件系统是否满足开发技术合同或SRS。验收测试的结论是用户确定是否接收该软件的主要依据。除应满足一般测试的准入条件外，在进行验收测试之前，应确认被测软件系统已通过系统测试。

• （4）系统测试：测试对象是完整的、集成的计算机系统；测试的目的是在真实系统工作环境下，验证完成的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求。测试依据是用户需求或开发合同。主要内容包括功能测试、健壮性测试、性能测试、用户界面测试、安全性测试、安装与反安装测试等，其中，最重要的工作是进行功能测试与性能测试。功能测试主要采用黑盒测试方法；性能测试主要指标有响应时间、吞吐量、并发用户数和资源利用率等。

• （5）配置项测试：测试对象是软件配置项，测试目的是**检验软件配置项与SRS的一致性。**测试的依据是SRS。在此之间，应确认被测软件配置项已通过单元测试和集成测试。

• （6）回归测试：测试目的是测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性。

• 测试策略

• 自底向上：从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。

• 自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。

• 三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。

考试真题

• 软件确认测试也称为有效性测试，主要验证（C）。确认测试计划通常是在需求分析阶段完成的。根据用户的参与程度不同，软件确认测试通常包括（C）。

  A.系统中各个单元模块之间的协作性 B.软件与硬件在实际运行环境中能否有效集成 C.软件功能、性能及其它特性是否与用户需求一致 D.程序模块能否正确实现详细设计说明中的功能、性能和设计约束等要求

  A.黑盒测试和白盒测试 B.一次性组装测试和增量式组装测试 C.内部测试、Alpha、Beta和验收测试 D.功能测试、性能测试、用户界面测试和安全性测试

• 软件测试一般分为两个大类：动态测试和静态测试。前者通过运行程序发现错误，包括（A）等方法；后者采用人工和计算机辅助静态分析的手段对程序进行检测，包括（C）等方法。

  A.迈界值分析、逻辑覆盖、基本路径 B.桌面检查、逻辑覆盖、错误推测 C.桌面检查、代码审查、代码走查 D.错误推测、代码审查、基本路径 A.边界值分析、逻辑覆盖、基本路径 B.桌面检查、逻辑覆盖、错误推测 C.桌面检查、代码审查、代码走查 D.错误推测、代码审查新基本路径

3.测试用例的设计

• 黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：

• 等价类划分：把所有的数据按照某种特性进行归类，而后在每类的数据里选取一个即可。等价类测试用例的设计原则：设计一个新的测试用例，使其尽可能多地覆盖尚未被覆盖的有效等价类，重复这一步，直到所有的有效等价类都被覆盖为止；设计一个新的测试用例，使其仅覆盖一个尚未被覆盖的无效等价类，重复这一步，直到所有的无效等价类都被覆盖为止。

• 边界值划分：将每类的边界值作为测试用例，边界值一般为范围的两端值以及在此范围之外的与此范围间隔最小的两个值，如年龄范围为0-150，边界值为0，150，-1，151四个。

• 错误推测：没有固定的方法，凭经验而言，来推测有可能产生问题的地方，作为测试用例进行测试。

• 因果图：由一个结果来反推原因的方法，具体结果具体分析，没有固定方法。

• 白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，覆盖级别从低至高分为下面几种： （1）语句覆盖SC：逻辑代码中的所有语句都要被执行一遍，覆盖层级最低，因为执行了所有的语句，不代表执行了所有的条件判断。 （2）判定覆盖DC：逻辑代码中的所有判断语句的条件的真假分支都要覆盖一次。

  

  （3）条件覆盖CC：针对每一个判断条件内的每一个独立条件都要执行一遍真和假。 （4）条件判定组合覆盖CDC：同时满足判定覆盖和条件覆盖。

  

  （5）路径覆盖：逻辑代码中的所有可行路径都覆盖了，覆盖层级最高.

  

考试真题

• 招聘系统要求求职的人年龄在20岁到60岁之间（含），学历为本科、硕士或者博士，专业为计算机科学与技术、通信工程或者电子工程。其中（C）不是好的测试用例。

  A.（20，本科，电子工程） B.（18，本科，通信工程）

  C.（18，大专，电子工程） D.（25，硕士，生物学）

• 以下关于测试的叙述中，正确的是（D）。

  A.实际上，可以采用穷举测试来发现软件中的所有错误

  B.错误很多的程序段在修改后错误一般会非常少

  C.测试可以用来证明软件没有错误

  D.白盒测试技术中，路径覆盖法往往能比语句覆盖法发现更多的错误

• 采用白盒测试方法对下图进行测试，设计了4个测试用例：①（x=0，y=3），②（x=1，y=2），③（x=-1，y=2），④（x=3，y=1）。至少需要测试用例①②才能完成（35）覆盖，至少需要测试用例①②③或①②④才能宝成（36）覆盖

  

  A.语句 B.条件 C.判定/条件 D.路径 A.语句 B.条件 C.判定/条件 D.路径

  答案：A D

4.调试

• 测试是发现错误，调试是找出错误的代码和原因。
• 调试需要确定错误的准确位置；确定问题的原因并设法改正；改正后要进行回归测试。
• 调试的方法有：蛮力法、回溯法（从出错的地方开始，向回找）、原因排除法（找出所有可能的原因，逐一进行排除，具体包括演绎法、归纳法、二分法）。

5.软件度量.

• 软件的两种属性：（外部庸性指面向管理者和用户的属性，可直接测量，一般为性能指标。丙部属性指软件产品本身的的属性，如可靠性等，只能间接测量。
• McCabe度量法：又称为环路复杂度，假设有向图中有向边数为m，节点数为n，则此有向图的环路复杂度为m-n+2.
• 注意m和n代表的含义不能混淆，可以用一个最简单的环路来做特殊值记忆此公式，另外，针对一个程序流程图，每一个分支边（连线）就是一条有向边，每一条语句（语句框）就是一个顶点。

考试真题

• 下图用白盒测试方法进行测试，图中有（B）条路径，采用McCabe度量计算该程序图的环路复杂性为（B）

  A、3 B、4 C、5 D 、6

  A、3 B、4 C、5 D 、6

系统运行与维护

1.系统转换

• 遗留系统是指任何基本上不能进行修改和演化以满足新的变化了的业务需求的信息系统，它通常具有以下特点： （1）系统虽然完成企业中许多重要的业务管理工作，**但仍然不能完全满足要求。**一般实现业务处理电子化及部分企业管理功能，很少涉及经营决策。 （2）系统在性能上已经落后，**采用的技术已经过时。**例如，多采用主机/终端形式或小型机系统，软件使用汇编语言或第三代程序设计语言的早期版本开发，使用文件系统而不是数据库。 （3）通常是大型的软件系统，已经融入企业的业务运作和决策管理机制之中，维护工作十分困难。 （4）没有使用现代信息系统建设方法进行管理和开发，现在基本上已经没有文档，很难理解。

  

• 系统转换是指新系统开发完毕，投入运行，取代现有系统的过程，需要考虑多方面的问题，以实现与老系统的交接，有以下三种转换计划：

• 直接转换：现有系统被新系统直接取代了，风险很大，适用于新系统不复杂，或者现有系统已经不能使用的情况。优点是节省成本。

• 并行转换：新系统和老系统并行工作一段时间，新系统经过试运行后再取代，若新系统在试运行过程中有问题，也不影响现有系统的运行，风险极小，在试运行过程中还可以比较新老系统的性能，适用于大型系统。缺点是耗费人力和时间资源，难以控制两个系统间的数据转换。

• 分段转换：分期分批逐步转换，是直接和并行转换的集合，将大型系统分为多个子系统，依次试运行每个子系统，成熟一个子系统，就转换一个子系统。同样适用于大型项目，只是更耗时，而且现有系统和新系统间混合使用，需要协调好接口等问题。

• 数据转换与迁移：将数据从旧数据库迁移到新数据库中。有三种方法：系统切换前通过工具迁移、系统切换前采用手工录入、系统切换后通过新系统生成。

2.系统维护

• 系统的可维护性可以定义为维护人员理解、改正、改动和改进这个软件的难易程度，其评价指标如下： （1）易分析性。软件产品诊断软件中的缺陷或失效原因或识别待修改部分的能力。 （2）易改变性。软件产品使指定的修改可以被实现的能力，实现包括编码、设计和文档的更改。 （3）稳定性。软件产品避免由于软件修改而造成意外结果的能力。 （4）易测试性。软件产品使已修改软件能被确认的能力。 （5）维护性的依从性。软件产品遵循与维护性相关的标准或约定的能力。
• 系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：
  • 正确性维护：发现了bug而进行的修改。
  • 适应性维护：由于外部环境发生了改变，被动进行的对软件的修改和升级。
  • 完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。
  • 预防性维护：对未来可能发生的bug进行预防性的修改。

3.系统评价

• 系统评价分类

  立项评价：系统开发前的预评价，分析是否立项开发，做可行性评价。

  中期评价：项目开发中期每个阶段的阶段评审。或者项目在开发中途遇到重大变故，评价是否还要继续。

  结项评价：系统投入正式运行后，了解系统是否达到预期的目的和要求而对系统进行的综合评价。

• 系统评价的指标 （1）从信息系统的组成部分出发，信息系统是一个由人机共同组成的系统，所以可以按照运行效果和用户需求（人）、系统质量和技术条件（机）这两条线索构造指标。 （2）从信息系统的评价对象出发，对于开发方来说，他们所关心的是系统质量和技术水平；对于用户方而言，关心的是用户需求和运行质量；系统外部环境则主要通过社会效益指标来反映。 （3）从经济学角度出发，分别按系统成本、系统效益和财务指标3条线索建立指标。

考试真题

• 对于遗留系统的评价框架如下图所示，那么处子“高水平、[低价值”区的遗留系统适合于采用的演化策略为（D）。

  A.淘汰 B.继承 C.改造 D.集成

• 以下关于软件维护和可维护性的叙述中，不正确的是（D）。

  A.软件维护要解决软件产品交付用户之后运行中发生的各种问题

  B.软件的维护期通常比开发期长得多，其投入也大得多

  C.进行质量保证审查可以提高软件产品的可维护性

  D.提高可维护性是在软件维护阶段考虑的问题

• 某企业由于外部市场环境和管理需求的变化对现有软件系统提出新的需求，则对该软件系统进行的维护属于（C） 维护。

  A.正确性 B.完善性 C.适应性 D.预防性

第十二章、项目管理

1.范围管理

• 范围管理确定在项目内包括什么工作和不包括什么工作，由此界定的项目范围在项目的全生命周期内可能因种种原因而变化，项目范围管理也要管理项目范围的这种变化。项目范围的变化也叫变更。

• 对项目范围的管理，是通过5个管理过程来实现的： （1）规划范围管理（编制范围管理计划）。对如何定义、确认和控制项目范围的过程进行描述。 （2）定义范围。详细描述产品范围和项目范围，编制项目范围说明书，作为以后项目决策的基础。其输入包括：项目章程。项目范围管理计划。组织过程资产。批准的变更申请。 （3）创建工作分解结构。把整个项目工作分解为较小的、易于管理的组成部分，形成一个自上而下的分解结构。 （4）确认范围。正式验收已完成的可交付成果。 （5）范围控制。监督项目和产品的范围状态、管理范围基准变更。

• 产品范围和项目范围

  产品范围是指产品或者服务所应该包含的功能。产品范围是否完成，要根据产品是否满足了产品描述来判断。产品范围是项目范围的基础，产品范围的定义是产品要求的描述。

  项目范围是指为了能够交付产品，项目所必须做的工作。项目范围的定义是产生项目管理计划的基础。判断项目范围是否完成，要以范围基准来衡量。项目的范围基准是经过批准的项目范围说明书、WBS和WBS词典。

  产品范围描述是项目范围说明书的重要组成部分，因此，产品范围变更后，首先受到影响的是项目的范围。

• WBS将项目整体或者主要的可交付成果分解成容易管理、方便控制的若干个子项目或者工作包，子项目需要继续分解为工作包，持续这个过程，**直到整个项目部分解为可管理的工作包，这些工作包的总和是项目的所有工作范围。**最普通的WBS 如下表所示：

  

考试真题

• （C）把软件项目整体或者主要的可交付成果分解为易于管理、方便控制的若干个子项目；再将子项目继续分解为工作包。在每个分解单元中，都存在可交付成果和里程碑。该模型的主要用途是（B）。

  A.分层数据流图

  B.软件模块图

  C.工作分解结构WBS

  D.PERT图

  A.描述软件项目的功能需求

  B.定义项目边界，有助于防止需求蔓延

  C.对软件的静态结构进行建模

  D.刻画软件开发活动之间的依赖关系

2.进度管理

• 进度管理就是采用科学的方法，确定进度目标，编制进度计划和资源供应计划，进行进度控制，在与质量、成本目标协调的基础上，实现工期目标。

• 具体来说，包括以下过程： （1）活动定义：确定完成项目各项可交付成果而需要开展的具体活动。 （2）活动排序：识别和记录各项活动之间的先后关系和逻辑关系。 （3）活动资源估算：估算完成各项活动所需要的资源类型和效益。 （4）活动历时估算：估算完成各项活动所需要的具体时间。 （5）进度计划编制：分析活动顺序、活动持续时间、资源要求和进度制约因素，制订项目进度计划。 （6）进度控制：根据进度计划开展项目活动，如果发现偏差，则分析原因或进行调整。

• 进行活动资源估算的方法主要有专家判断法、替换方案的确定、公开的估算数据、估算软件和自下而上的估算。 （1）专家判断法。专家判断法通常是由项目管理专家根据以往类似项目经的验和对本项目的判断，经过周密思考，进行合理预测，从而估算出项目资源。 （2）替换方案的确定。资源估算是为了给项目预算明确空间，为早期的资源筹备提供数据，如果某项活动存在替代方案，或提供的资源有替代支持可能，则需要明确声明。 （3）公开的估算数据。有些公司会定期地公开一些生产率或人工费率数据，其中包括很多国家和地区的劳动力交易、材料和设备信息。 （4）估算软件。依靠软件的强大功能，可以定义资源可用性、费率，以及不同的资源日历。 （5）自下而上的估算。把复杂的活动分解为更小的工作，以便于资源估算。将每项工作所需要的资源估算出来，然后汇总即是整个活动所需要的资源数量。（自上而下的估算，是类比估算，之前有类似的项目，参考估算。）

• COCOMO模型：常见的软件规模估算方法。常用的代码行分析方法作为其中一种度量估计单位，以代码行数估算出每个程序员工作量，累加得软件成本。模型按其详细程度可以分为三级： （1）基本COCOMO模型是一个静态单变量模型，它用一个以已估算出来的原代码行数（LOC）为自变量的经验函数计算软件开发工作量。 （2）中间COCOMO模型在基本COCOMO模型的基础上，再用涉及产品、硬件、人员、项目等方面的影响因素调整工作量的估算。 （3）详细COCOMO模型包括中间COCOMO模型的所有特性，将软件系统模型分为系统、子系统和模块3个层次，更进一步考虑了软件工程中每一步骤（如分析、设计）的影响。

• COCOMOⅡ模型：COCOMO的升级，也是以软件规模作为成本的主要因素，考虑多个成本驱动因子。该方法包括三个阶段性模型，即**应用组装模型、早期设计阶段模型和体系结构阶段模型。**包含三种不同规模估算选择：对象点、功能点和代码行。

• 进度安排的常用图形描述方法有Gantt图（甘特图）和项目计划评审技术（Program Evaluation&Review Technique，PERT）图。

  

• 工具与技术--关键路径法 关键路径：是项目的**最短工期，但却是从开始到结束时间最长的路径。**进度网络图中可能有多条关键路径，因为活动会变化，因此关键路径也在不断变化中。关键活动：关键路径上的活动，最早开始时间=最晚开始时间。通常，每个节点的活动会有如下几个时间：

  （1）最早开始时间（ES），某项活动能够开始的最早时间。

  （2）最早结束时间（EF），某项活动能够完成的最早时间。EF=ES+工期

  （3）最迟结束时间（LF）。为了使项目按时完成，某项活动必须完成的最迟时间。

  （4）最迟开始时间（LS）。为了使项目按时完成，某项活动必须开始的最迟时间。LS=LF-工期

• 这几个时间通常作为每个节点的组成部分，如图所示：

  • 顺推：最早开始ES=所有前置活动最早完成EF的最大值；最早完成EF=最早开始ES+持续时间。
  • 逆推：最晚完成LF=所有后续活动最晚开始Ls的最小值；最晚开始LS=最晚完成_F持续事件。

  

• 总浮动时间：在不延误项目完工时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量，就是该活动的进度灵活性。正常情况下，关键活动的总浮动时间为零。

• 总浮动时间=最迟开始Ls-最早开始ES或最迟完成L-最早完成EF或关键路径-非关键路径时长。

• 自由浮动时间：是指在不延误任何紧后活动的最早开始时间且不违反进度制约因素的前提下，活动可以从最早开始时间推迟或拖延的时间量。

• 自由浮动时间=紧后活动最早开始时间的最小值-本活动的最早完成时间。

考试真题

• 下图中（单位：周）显示的项目历时总时长是（C）周。在项目实施过程中，活动d-i比计划延期了2周，活动a-c实际工期是6周，活动f-h比计划提前了1周，此时该项目的历时总时长为（C）周。

  

  A.14 B.18 C.16 D.13

  A.14 B.18 C.16 D.17

• 某项目包含A、B、C、D、E、F、G七个活动，各活动的历时估算和逻辑关系如下表所示，则活动c的总浮动时间是（）天，项目工期是（）天。

  

  答案： D D

3.成本管理

• 项目成本管理是在整个项目的实施过程中，为确保项目在批准的预算条件下尽可能保质按期完成，而对所需的各个过程进行管理与控制。
• 项目成本管理包括成本估算、成本预算和成本控制三个过程。 （1）成本估算是对完成项目所需成本的估计和计划，是项目计划中的一个重要的、关键的、敏感的部分；成本估算主要靠分解和类推的手段进行，基本估算方法分为三类：自顶向下的估算、自底向上的估算和差别估算法。 （2）成本预算是把估算的总成本分配到项目的各个工作包，建立成本基准计划以衡量项目绩效；应急储备和管理储备。 （3）成本控制保证各项工作在各自的预算范围内进行。
• 成本的类型 （1）可变成本：随着生产量、工作量或时间而变的成本为可变成本。可变成本又称变动成本。 （2）固定成本：不随生产量、工作量或时间的变化而变化的非重复成本为固定成本。 （3）直接成本：直接可以归属于项目工作的成本为直接成本。如项目团队差旅费、工资、项目使用的物料及设备使用费等。 （4）间接成本：来自一般管理费用科目或几个项目共同担负的项目成本所分摊给本项目的费用，就形成了项目的间接成本，如税金、额外福利和保卫费用等。 （5）机会成本：是利用一定的时间或资源生产一种商品时，而失去的利用这些资源生产其他最佳替代品的机会就是机会成本，泛指一切在做出选择后其中一个最大的损失。 （6）沉没成本：是指由于**过去的决策已经发生了的，而不能由现在或将来的任何决策改变的成本。**沉没成本是一种历史成本，对现有决策而言是不可控成本，会很大程度上影响人们的行为方式与决策，在投资决策时应排除沉没成本的干扰。
• 学习曲线：重复生成产品时，**产品的单位成本会随着产量的扩大呈现规律性递减。**估算成本时，也要考虑此因素。

考试真题

• 关于成本类型的描述，不正确的是（A）

  A、项目团队差旅费、工资、税金及设备使用费为直接成本

  B、随着生产量，工作量或时间而变的成本称为变动成本

  C、利用一定时间或资源生产一种商品时，便失去了使用这些资源生产其他最佳替代品的机会称为机会成本

  D、沉没成本是一种历史版本，对现有决策而言是不可控成本

• 投资者赵某可以选择股票和储蓄存款两种投资方式。他于2017年1月1日用2万元购进某股票，一年后亏损了500元，如果当时他选择储蓄存款，一年后将有360元的收益。由此可知，赵某投资股票的机会成本为（B）元。

  A、500 B、360 C、860 D、140

4.软件配置管理

• 配置管理是为了系统地控制配置变更，在系统的**整个生命周期中维持配置的完整性和可跟踪性，**而标识系统在不同时间点上配置的学科。

• 在GB/T11457-2006中将“配置管理”正式定义为：“应用技术的和管理的指导和监控方法以**标识和说明配置项的功能和物理特征，**控制这些特征的变更，记录和报告变更处理和实现状态并验证与规定的需求的遵循性。

• 配置管理包括6个主要活动：制订配置管理计划、配置标识、配置控制、配置状态报告、配置审计、发布管理和交付。

• 配置项：GB/T11457-2006对配置项的定义为：“为配置管理设计的硬件、软件或二者的集合，在配置管理过程中作为一个单个实体来对待”

• 以下内容都可以作为配置项进行管理：外部交付的软件产品和数据、指定的内部软件工作产品和数据、指定的用于创建或支持软件产品的支持工具、供方/供应商提供的软件和客户提供的设备/软件。

• 典型配置项包括项目计划书、需求文档、设计文档、源代码、可执行代码、测试用例、运行软件所需的各种数据，它们经评审和检查通过后进入配置管理。

• 每个配置项的主要属性有：名称、标识符、文件状态、版本、作者、日期等。

• 配置项可以分为基线配置项和非基线配置项两类，例如，基线配置项可能包括所有的设计文档和源程序等；非基线配置项可能包括项目的各类计划和报告等。

• 所有配置项的操作权限应由CMO（配置管理员）严格管理，基本原则是：基线配置项向开发人员开放读取的权限；非基线配置项向PM、CCB及相关人员开放。

• 配置项的状态可分为**”草稿”“正式”和“修改”三种。配置项刚建立时，其状态为“草稿”。配置项通过评审后，其状态变为“正式”。此后若更改配置项，则其状态变为“修改”。当配置项修改完毕并重新通过评审时，其状态又变为“正式”。**如图所示

  

• 配置项版本号 （1）处于**"草稿”状态的配置项的版本号格式为0.YZ**，Yz的数字范围为01一99。随着草稿的修正，YZ的取值应递增。YZ的初值和增幅由用户自己把握。 （2）处于“正式”状态的配置项的版本号格式为X.Y，X为主版本号，取值范围为1一9。Y为次版本号，取值范围为0一9。配置项第一次成为“正式”文件时，版本号为1.0。如果配置项升级幅度比较小，可以将变动部分制作成配置项的附件，附件版本依次为1.0，1.1..。当附件的变动积累到一定程度时，配置项的Y值可适量增加，Y值增加一定程度时，x值将适量增加。当配置项升级幅度比较大时，才允许直接增大x值。 （3）处于“修改”状态的配置项的版本号格式为X.YZ。配置项正在修改时，一般只增大Z值，X.Y值保持不变。当配置项**修改完毕，状态成为“正式”时，将Z值设置为0，增加X.Y值。**参见上述规则（2）。

• 配置项版本管理：在项目开发过程中，绝大部分的配置项都要经过多次的修改才能最终确定下来。对配置项的任何修改都将产生新的版本。由于我们不能保证新版本一定比旧版本”好”，所以不能抛弃旧版本。版本管理的目的是按照一定的规则保存配置项的所有版本，避免发生版本丢失或混淆等现象，并且可以快速准确地查找到配置项的任何版本。

• 配置基线（常简称为基线）由一组配置项组成，这些配置项构成一个相对稳定的逻辑实体。基线中的配置项被“冻结”了，不能再被任何人随意修改。对基线的变更必须遵循正式的变更控制程序。

• 基线通常对应于开发过程中的里程碑，一个产品可以有多个基线，也可以只有一个基线。交付给外部顾客的基线一般称为发行基线（Release），内部开发使用的基线一般称为构造基线（Build）。

• 一组拥有唯一标识号的需求、设计、源代码文卷以及相应的可执行代码、构造文卷和用户文档构成一条基线。

• 产品的一个测试版本（可能包括需求分析说明书、概要设计说明书、详细设计说明书、已编译的可执行代码、测试大纲、测试用例、使用手册等）是基线的一个例子。

• 对于每一个基线，要定义下列内容：建立基线的事件、受控的配置项、建立和变更基线的程序、批准变更基线所需的权限。在项目实施过程中，每个基线都要纳入配置控制，对这些基线的更新只能采用正式的变更控制程序。

• 建立基线还可以有如下好处： （1）基线为开发工作提供了一个定点和快照。 （2）新项目可以在基线提供的定点上建立。新项目作为一个单独分支，将与随后对原始项目（在主要分支上）所进行的变更进行隔离。 （3）当认为更新不稳定或不可信时，基线为团队提供一种取消变更的方法。 （4）可以**利用基线重新建立基于某个特定发布版本的配置，**以重现已报告的错误。

• **配置库存放配置项并记录与配置项相关的所有信息，**是配置管理的有力工具。主要作用：

  （1）记录与配置相关的所有信息，其中存放受控的软件配置项是很重要的内容。 （2）利用库中的信息评价变更的后果，这对变更控制有着重要的意义。 （3）从库中可提取各种配置管理过程的管理信息。

• 使用配置库可以帮助配置管理员把信息系统开发过程的各种工作产品，包括半成品或阶段产品和最终产品管理得井井有条，使其不致管乱、管混、管丢。

• 配置库可以分开发库、受控库、产品库3种类型。 （1）开发库，也称为动态库、程序员库或工作库，用于保存开发人员当前正在开发的配置实体，如：新模块、文档、数据元素或进行修改的已有元素。动态中的配置项被置于版本管理之下。动态库是开发人员的个人工作区，由开发人员自行控制。库中的信息可能有较为频繁的修改，只要开发库的使用者认为有必要，无需对其进行配置控制，因为这通常不会影响到项目的其他部分。可以任意的修改。 （2）受控库，也称为主库，包含当前的基线加上对基线的变更。受控库中的配置项被置于完全的配置管理之下。在信息系统开发的某个阶段工作结束时，将当前的工作产品存入受控库。可以修改，需要走变更流程 （3）产品库，也称为静态库、发行库、软件仓库，包含已发布使用的各种基线的存档，被置于完全的配置管理之下。在开发的信息系统产品完成系统测试之后，作为最终产品存入产品库内，等待交付用户或现场安装。一般不再修改，真要修改的话需要走变更流程。

考试真题

• 项目配置管理中，产品配置是指一个产品在其生命周期各个阶段所产生的各种形式和各种版本的文档、计算机程序、部件及数据的集合。该集合中的每一个元素称为该产品配置中的一个配置顶，（C）不属于产品组成部分工作成果的配置顶。

  A.需求文档 B.设计文档 C.工作计划 D.源代码

• 项目配置管理中，配置项的状态通常包括（A）。

  A.草稿、正式发布和正在修改

  B.草稿、技术评审和正式发布

  C.草稿、评审或审批、正式发布

  D.草稿、正式发布和版本变更

5.质量管理

• 质量是软件产品特性的综合，表示**软件产品满足明确（基本需求）或隐含（期望需求）要求的能力。**质量管理是指确定质量方针、目标和职责，并通过质量体系中的质量计划、质量控制、质量保证和质量改进来使其实现的所有管理职能的全部活动；

• 主要包括以下过程： （1）质量规划：识别项目及其产品的质量要求和标准，并书面描述项目将如何达到这些要求和标准的过程。 （2）质量保证：一般是每隔一定时间（例如，每个阶段末）进行的，主要通过系统的质量审计（软件评审）和过程分析来保证项目的质量。 （3）质量控制：**实时监控项目的具体结果，以判断它们是否符合相关质量标准，**制订有效方案，以消除产生质量问题的原因。

• 信息技术软件产品评价质量特性及其使用指南GB/T 16260-2002

• (6大特性21小特性)

  

  

• McCall质量模型

  

• 软件评审 质量两个必要条件：设计的规格说明书符合用户标准，称为设计质量。程序按照设计规格说明书所规定的情况正确执行，称为程序质量。

• 软件容错技术：容错就是软件遇到错误的处理能力，实现容错的手段主要是冗余，包括下面四种冗余技术：

• 结构冗余：分为静态、动态、混合冗余三种，当错误发生时对错误进行备份处理。

• 信息冗余：为检错和纠错在数据中加上一段额外的信息，例如校验码原理。

• 时间冗余：**遇到错误时重复执行，**例如回滚，重复执行还有错，则转入错误处理逻辑。

• 冗余附加技术：是指为实现结构、信息和时间冗余技术所需的资源和技术，包括程序、指令、数据、存放和调动它们的空间和通道等。

考试真题

• 软件质量保证是软件项目控制的重要手段，（B）是软件质量保证的主要活动之一。

  A.风险评估 B.软件评审 C.需求分析 D.架构设计

• ISO/IEC软件质量模型中，易使用性是指与使用所需的努力由一组规定或隐含的用户对这样使用所作的个别评价有关的一组属性，其易使用性的子特性不包括（C）。

  A、易理解性 B、易学性 C、易分析性 D、易操作性

6.风险管理

• 风险管理就是要对项目风险进行认真的分析和科学的管理，这样，是能够避开不利条件、少受损失、取得预期的结果并实现项目目标的，能够争取避免风险的发生或尽量减小风险发生后的影响。但是，完全避开或消除风险，或者只享受权益而不承担风险是不可能的。
• 风险管理计划编制：如何安排与实施项目的风险管理，制定下列各步的计划。
• 风险识别：识别出项目中已知和可预测的风险，确定风险的来源、产生的条件、描述风险的特征以及哪些项目可以产生风险，形成一个风险列表。
• 风险定性分析：对已经识别的风险进行排序，确定风险可能性与影响、确定风险优先级、确定风险类型。
• 风险定量分析：进一步了解风险发生的可能性具体由多大，后果具体由多严重。包括灵敏度分析、期望货币价值分析、决策树分析、蒙特卡罗模拟。
• 风险应对计划编制：对每一个识别出来的风险来分别制定应对措施，这些措施组成的文档称为风险应对计划。包括消极风险（避免策略、转移策略、减轻策略）；积极风险（开拓、分享、强大）。
• 风险监控；监控风险计划的执行，检测残余风险，识别新的风险，保证风险计划的执行，并评价这些计划对减少风险的有效性。
• 项目风险：作用于项目上的不确定的事件或条件，既可能产生威胁，也可能带来机会。
• 通过积极和合理的规划，超过90%的风险都可以进行提前应对和管理。
• 风险应该尽早识别出来，高层次风险应记录在章程里。
• 应由对风险最有控制力的一方承担相应的风险。
• 承担风险程度与所得回报相匹配原则，承担的风险要有上限。
• 风险的属性： （1）随机性：风险事件发生及其后果都具有偶然性（双重偶然），遵循一定的统计规律。 （2）相对性：风险是**相对项目活动主体而言的。承受力不同，影响不同。**风险承受力影响因素：收益大小（收益越大，越愿意承担风险）；投入大小（投入越大，承受能力越小）；主体的地位和资源（级别高的人能承担较大的风险）。 （3）风险的可变性：**条件变化，会引起风险变化。**包括性质、后果的变化，以及出现新风险。
• 风险的分类：
• 按照后果的不同，风险可划分为纯粹风险（无任何收益）和投机风险（可能带来收益）
• 按风险来源划分，自然风险（天灾）和人为风险（人的活动，又可分为行为风险、经济风险、技术风险、政治和组织风险等），
• 按是否可管理划分，**可管理（如内部多数风险）和不可管理（如外部政策），**也要看主体管理水平。
• 按影响范围划分，局部风险（非关键路径活动延误）和总体风险（关键路径活动延误）。
• 按后果承担者划分：业主、政府、承包商、投资方、设计单位、监理单位、保险公司等。
• 按可预测性划分：已知风险（已知的进度风险）、可预测风险（可能服务器故障）、不可预测风险（地震、洪水、政策变化等）。
• 在信息系统项目中，从宏观上来看，风险可以分为项目风险、技术风险和商业风险。
• 项目风险是指**潜在的预算、进度、个人（包括人员和组织）、资源、用户和需求方面的问题，以及它们对项目的影响。**项目复杂性、规模和结构的不确定性也构成项目的（估算）风险因素。项目风险威胁到项目计划，一旦项目风险成为现实，可能会拖延项目进度，增加项目的成本。
• 技术风险是指潜在的**设计、实现、接口、测试和维护方面的问题。**此外，**规格说明的多义性、技术上的不确定性、技术陈旧、最新技术（不成熟）也是风险因素。技术风险威胁到待开发系统的质量和预定的交付时间。**如果技术风险成为现实，开发工作可能会变得很困难或根本不可能。
• 商业风险威胁到待开发系统的生存能力，主要有以下5种不同的商业风险： （1）市场风险。开发的系统虽然很优秀但不是市场真正所想要的。 （2）策略风险。开发的系统不再符合企业的信息系统战略。 （3）销售风险。开发了销售部门不清楚如何推销的系统。 （4）管理风险。由于重点转移或人员变动而失去上级管理部门的支持。 （5）预算风险。开发过程没有得到预算或人员的保证。

考试真题

• 以下关于软件风险的叙述中，不正确的是（C）

  A、风险是可能发生的事件

  B、如果发生风险，风险的本质、范围和时间可能会影响风险所产生的后果

  C、如果风险可以预测，可以避免其发生

  D、可以对风险进行控制

• 以下叙述中，（B）不是一个风险、

  A.由另一个小组开发的子系统可能推迟交付，导致系统不能按时交付客户

  B.客户不清楚想要开发什么样的软件，因此开发小组开发原型帮助其确定需求

  C.开发团队可能没有正确理解客户的需求

  D.开发团队核心成员可能在系统开发过程中离职

补充知识

• 组织结构模式：项目型（项目经理绝对领导）、职能型（部门领导为主）、矩阵型（二者结合，既有项目经理也有部门领导，但权利分割不同）。
• 程序设计小组的组织方式： （1）主程序员制小组（主程序员全权负责，后援工程师必要时能替代主程序员，适合大规模项目） （2）民主制小组（也即无主程序员小组，成员之间地位平等，任何决策都是全员参与投票，适合于项目规模小，开发人员少，采用新技术和确定性较小的项目） （3）层次式小组（两个层次，一名组长领导若干个高级程序员，每个高级程序员领导若干个程序员）。

考试真题

• 在进行软件开发时，采用无主程序员的开发小组，成员之间相互平等；而主程序员负责制的开发小组，由一个主程序员和若干成员组成，成员之间没有沟通。在一个由8名开发人员构成的小组中，无主程序员组和主程序员组的沟通路径分别是（D）。 A.32和8 B.32和7 C.28和8 D.28和7

第十三章、结构化开发方法

1.系统分析与设计概述

• 系统分析过程一般按如图所示的逻辑进行： （1）认识、理解当前的现实环境，获得当前系统的“物理模型” （2）从当前系统的“物理模型”抽象出当前系统的“逻辑模型” （3）对当前系统的“逻辑模型”进行分析和优化，建立目标系统的“逻辑模型” （4）对目标系统的逻辑模型具体化（物理化），建立目标系统的物理模型。

• 系统开发的目的是把现有系统的物理模型转化为目标系统的物理模型，即图中所描述的路径，而系统分析阶段的结果是得到目标系统的逻辑模型。逻辑模型反映了系统的功能和性质，而物理模型反映的是系统的某一种具体实现方案。

  

• 系统设计基本原理：抽象、模块化、信息隐蔽、模块独立。

  衡量模块独立程度的标准有两个：耦合性和内聚性。内聚程度从低到高如下表所示

  

• 耦合程度从低到高如下表所示：

  

考试真题

• 某模块中各个处理元素都密切相关于同一功能且必须顺序执行，前一处理元素的输出就是下一处理元素的输入，则该模块的内聚类型为（C）内聚 A、过程 B、时间 C、顺序 D、逻辑

• 已知模块A给模块B传递数据结构x，则这两个模块的耦合类型为（D）。

  A.数据耦合 B.公共耦合 C.外部耦合 D.标记耦合

• 系统总体结构设计是要根据系统分析的要求和组织的实际情况对新系统的总体结构形式和可利用的资源进行大致设计，这是一种宏观、总体上的设计和规划。

• 系统结构设计原则： （1）分解-协调原则。 （2）自顶向下的原则。 （3）信息隐蔽、抽象的原则。 （4）一致性原则。 （5）明确性原则。 （6）模块之间的耦合尽可能小，模块的内聚度尽可能高。 （7）模块的扇入系数和扇出系数要合理。 （8）模块的规模适当。

• 子系统划分的原则： （1）子系统要具有相对独立性。 （2）子系统之间数据的依赖性尽量小。 （3）子系统划分的结果应使数据冗余较小。 （4）子系统的设置应考虑今后管理发展的需要。 （5）子系统的划分应便于系统分阶段实现。 （6）子系统的划分应考虑到各类资源的充分利用。

• 子系统结构设计的任务是确定划分后的子系统模块结构，并画出模块结构图。在这个过程中必须考虑以下几个问题。 （1）每个子系统如何划分成多个模块。 （2）如何确定子系统之间、模块之间传送的数据及其调用关系。 （3）如何评价并改进模块结构的质量。 （4）如何从数据流图导出模块结构图。

• 系统模块结构设计 模块是组成系统的基本单位，它的特点是可以组合、分解和更换。系统中的任何一个处理功能都可以看成是一个模块。根据功能具体化程度的不同，模块可以分为逻辑模块和物理模块。

• 一个模块应具备以下4个要素。 （1）输入和输出。 （2）处理功能。指模块把输入转换成输出所做的工作。 （3）内部数据。指仅供该模块本身引用的数据。 （4）程序代码。指用来实现模块功能的程序。

  前两个要素是模块外部特性，反映了模块的外貌。后两个要素是模块的内部特性。

• 模块结构图为了保证系统设计工作的顺利进行，结构设计应遵循以下原则。 （1）所划分的模块其内部的凝聚性要强，模块之间的联系要少，即模块具有较强的独立性。 （2）模块之间的连接只能存在上下级之间的调用关系，不能有同级之间的横向联系。 （3）整个系统呈树状结构，不允许网状结构或交叉调用关系出现。 （4）所有模块（包括后继IPO图）都必须严格地分类编码并建立归档文件。

  模块结构图主要关心的是模块的外部属性，即上下级模块、同级模块之间的数据传递和调用关系，并不关心模块的内部。

考试真题

• 以下关于软件设计原则的叙述中，不正确的是（A）

  A、系统需要划分多个模块，模块的规模越小越好

  B、考虑信息隐蔽，模块内部的数据不能让其他模块直接访问模块独立性要好

  C、尽可能高内聚和低耦合

  D、采用过程抽象和数据抽象设计

• 在进行子系统结构设计时，需要确定划分后的子系统模块结构，并画出模块结构图。该过程不需要考虑（B）。

  A.每个子系统如何划分成多个模块

  B.每个子系统采用何种数据结构和核心算法

  C.如何确定子系统之间、模块之间传送的数据及其调用关系

  D.如何评价并改进模块结构的质量

2.结构化开发方法

• 结构化分析与设计方法是一种面向数据流的传统软件开发方法，它以数据流为中心构建软件的分析模型和设计模型。结构化分析（Structured Analysis，SA）结构化设计（Structured Design，SD）和结构化程序设计（Structured Programming Design，SPD）构成了完整的结构化方法。

• 结构化方法的分析结果由以下几部分组成：一套分层的数据流图、一本数据词典、一组小说明（也称加工逻辑说明）、补充材料。

• 数据流图DFD

  基本图形元素：外部实体、加工、数据存储、数据流。

  

• 1）数据流：由一组固定成分的数据组成，表示数据的流向。在DFD中，数据流的流向必须经过加工。.

  2）加工：描述了输入数据流到输出数据流之间的变换，数据流图中常见的三种错误如图所示：

  加工3.1.2有输入但是没有输出，称之为“黑洞”。

  加工3.1.3有输出但没有输入。称之为“奇迹”

  加工3.1.1中输入不足以产生输出，我们称之为“灰洞”。

  3）数据存储：用来存储数据。 4）外部实体（外部主体）：是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地（源）和系统所产生的数据的归宿地（宿）。

  

• 分层数据流图：

  

• 数据字典DD

  数据流图描述了系统的分解，但没有对图电各成分进行说明。数据字典就是为数据流图中的每个数据流、文件、加工，以及组成数据流或文件的数据项做出说明。 数据字典有以下4类条目：数据流、数据项、数据存储和基本加工。

  

• 加工逻辑也称为“小说明”。常用的加工逻辑描述方法有结构化语言、判定表和判定树3种。.

考试真题

• 在结构化分析中，用数据流图描述（B）。当采用数据流图对一个图书馆管理系统进行分析时，（A）是一个外部实体。 A.数据对象之间的关系，用于对数据建模 B.数据在系统中如何被传送或变换，以及如何对数据流进行变换的功能或子功能，用于对功能建模 C.系统对外部事件如何响应，如何动作，用于对行为建模D.数据流图中的各个组成部分 A.读者 B.图书 C.借书证 D.借阅

3.结构化设计方法

• 结构化设计（Structured Design，SD）方法是一种面向数据流的设计方法，它可以与SA方法衔接。结构化设计方法的基本思想是将系统设计成由相对独立、功能单一的模块组成的结构。
• 结构化设计方法中用**结构图（Structure Chart）来描述软件系统的体系结构，**指出一个软件系统由哪些模块组成，以及模块之间的调用关系。模块结构图是结构化设计的工具，由模块、调用、数据、控制和转接五种基本符号组成。
• 结构化设计主要包括 ①体系结构设计：定义软件的主要结构元素及其关系。 ②数据设计：基于实体联系图确定软件涉及的文件系统的结构及数据库的表结构。 ③接口设计：描述用户界面，软件和其他硬件设备、其他软件系统及使用人员的外部接口，以及各种构件之间的内部接口。 ④过程设计：确定软件各个组成部分内的算法及内部数据结构，并选定某种过程的表达形式来描述各种算法。

考试真题

• 在采用结构化开发方法进行软件开发时，设计阶段接口设计主要依据需求分析阶段的（A）。接口设计的任务主要是（C）。

  A.数据流图 B.E-R图 C.状态-迁移图 D.加工规格说明

  A.定义软件的主要结构元素及其之间的关系

  B.确定软件涉及的文件系统的结构及数据库的表结构

  C.描述软件与外部环境之间的交互关系，软件内模块之间的调用关系

  D.确定软件各个模块内部的算法和数据结构

4.WebApp分析与设计

• WebApp是基于web的系统和应用。大多数WebApp采用敏捷开发过程模型进行开发。

• WebApp的特性： （1）网络密集性。WebApp驻留在网络上，服务于不同客户全体的需求。网络提供开放的访问和通信（如Internet）或者受限的访问和通信（如企业内联网）。 （2）并发性。大量用户可能同时访问WebApp。很多情况下最终用户的使用模式存在很大的差异。 （3）无法预知的负载量。WebApp的用户数量每天都可能有数量级的变化。例如，周一显示有100个用户使用系统，周四就有可能会有10000个个用户。 （4）性能。如果一位WebApp用户必须等待很长时间（访问、服务器端处理、客户端格式化显示），该用户就可能转向其他地方。 （5）可用性。尽管期望百分之百的可用性是不切实际的，但是对于热门的WebApp，用户通常要求能够24/7/365（全天候）访问。 （6）数据驱动。许多WebApp的主要功能是使用超媒体向最终用户提供文本、图片、音频及视频内容。除此之外，WebApp 还常被用来访问那些存储在Web应用环境之外的数据库中的信息。

• WebApp五种需求模型

  1、内容模型：给出由WebApp提供的全部系列内容，包括文字、图形、图像、音频和视频。包含结构元素，为WebApp的内容需求提供了一个重要的视图。这些结构元素包含内容对象和所有分析类，在用户与WebApp交互时生成并操作用户可见的实体。

  2、交互模型：描述了用户与WebApp采用了哪种交互方式。由一种或多种元素构成，包括用例、顺序图、状态图、用户界面原型等。

  3、功能模型：许多WebApp提供大量的计算和操作功能，这些功能与内容直接相关（既能使用又能生成内容，如统计报表）。这些功能常常以用户的交互活动为主要目标。功能模型定义了将用于WebApp内容并描述其他处理功能的操作，这些处理功能不依赖于内容却是最终用户所必需的。

  4、导航模型：为WebApp定义所有导航策略。考虑了每一类用户如何从一个WebApp元素（如内容对象）导航到另一个元素。

  5、配置模型：描述WebApp所在的环境和基础设施。在必需考虑复杂配置体系结构的情况下，可以使用UML部署图。

• WebApp设计

  1、架构设计：描述将以什么方式来管理用户交互、操作内部处理任务、实现导航及展示内容。MVC（模型视图控制器）结构是WebApp基础结构模型之一，将WebApp功能及信息内容分离。

  2、构件设计：WebApp构件：定义良好的聚合功能，为最终用户处理内容或提供计算或处理数据；内容和功能的聚合包，提供最终用户所需要的功能。因此，WebApp构件设计通常包括内容设计元素和功能设计元素。构件级内容设计：关注内容对象，以及包装后展示给最终用户的方式，应该适合创建的WebApp特性。 构件级功能设计：将WebApp作为一系列构件加以交付，这些构件与信息体系结构并行开发，以确保一致性。

  3、内容设计：着重于内容对象的表现和导航的组织，通常采用线性结构、网格结构、层次结构、网络结构四种结构及其组合。

  4、导航设计：定义导航路径，使用户可以访问WebApp的内容和功能。

第十四章、面向对象技术

1.面向对象开发

• （1）对象：由数据及其操作所构成的封装体，是系统中用来描述客观事务的一个实体，是构成系统的一个基本单位。一个对象通常可以由对象名、属性和方法3个部分组成。 （2）类：现实世界中实体的形式化描述，类将该实体的属性（数据）和操作 （函数）封装在一起。对象是类的实例，类是对象的模板。

  类可以分为三种：实体类、接口类（边界类）和控制类。实体类的对象表示现实世界中真实的实体，如人、物等。接口类（边界类）的对象为用户提供一种与系统合作交互的方式，分为人和系统两大类，其中人的接口可以是显示屏、窗口、Web窗体、对话框、菜单、列表框、其他显示控制、条形码、二维码或者用户与系统交互的其他方法。系统接口涉及到把数据发送到其他系统，或者从其他系统接收数据。控制类的对象用来控制活动流，充当协调者。

  （3）抽象：通过**特定的实例抽取共同特征以后形成概念的过程。它强调主要特征，忽略次要特征。**一个对象是现实世界中一个实体的抽象，一个类是一组对象的抽象，抽象是一种单一化的描述，它强调给出与应用相关的特性，抛弃不相关的特性。

  （4）封装：是一种信息隐蔽技术，将相关的概念组成一个单元模块，并通过一个名称来引用。面向对象封装是将数据和基于数据的操作封装成一个整体对象，对数据的访问或修改只能通过对象对外提供的接口进行。 （5）继承：表示**类之间的层次关系（父类与子类），**这种关系使得某类对象可以继承另外一类对象的特征，又可分为单继承和多继承。 （6）多态：**不同的对象收到同一个消息时产生完全不同的结果。包括参数多态（不同类型参数多种结构类型）、包含多态（父子类型关系）、过载多态（类似于重载，一个名字不同含义）、强制多态（强制类型转换）**四种类型。多态由继承机制支持，将通用消息放在抽象层，具体不同的功能实现放在低层。

  （7）接口：描述对操作规范的说明，其只说明操作应该做什么，并没有定义操作如何做。 （8）消息：体现对象间的交互，通过它向目标对象发送操作请求。 （9）覆盖：子类在原有父类接口的基础上，用适合于自己要求的实现去置换父类中的相应实现。即在子类中重定义一个与父类同名同参的方法。 （10）函数重载：与覆盖要区分开，函数重载与子类父类无关，且函数是同名不同参数。 （11）绑定是一个把过程调用和响应调用所需要执行的代码加以结合的过程。在一般的程序设计语言中，绑定是在编译时进行的，叫作静态绑定。动态绑定则是在运行时进行的，因此，一个给定的过程调用和代码的结合直到调用发生时才进行。

考试真题

• 一个类中可以拥有多个名称相同而参数表（参数类型或参数个数或参数类型顺序）不同的方法，称为（C） A.方法标记 B.方法调用 C.方法重载 D.方法覆盖

• 在某销售系统中，客户采用扫描二维码进行支付。若采用面向对象方法开发该销售系统，则客户类属于（B）类，二维码类属于（A）类。

  A.接口 B.实体 C.控制 D.状态

  A.接口 B.实体 C.控制 D.状态

• 面向对象的分析：是为了**确定问题域，理解问题。**包含五个活动：认定对象、组织对象、描述对象间的相互作用、确定对象的操作、定义对象的内部信息。

• 面向对象需求建模：

  

• 面向对象的设计：是设计分析模型和实现相应源代码，设计问题域的解决方案，与技术相关。OOD同样应遵循抽象、信息隐蔽、功能独立、模块化等设计准则。

• 面向对象的分析模型主要由顶层架构图、用例与用例图、领域概念模型构成；设计模型则包含以包图表示的软件体系结构图、以交互图表示的用例实现图、完整精确的类图、针对复杂对象的状态图和用以描述流程化处理过程的活动图等。

  

• 面向对象的设计原则： （1）单一责任原则。就一个类而言，应该仅有一个引起它变化的原因。即，当需要修改某个类的时候原因有且只有一个，让一个类只做一种类型责任。 （2）开放-封闭原则。软件实体（类、模块、函数等）应该是可以扩展的，即开放的；但是不可修改的，即封闭的。 （3）里氏替换原则。**子类型必须能够替换掉他们的基类型。**即，在任何父类可以出现的地方，都可以用子类的实例来赋值给父类型的引用。 （4）依赖倒置原则。**抽象不应该依赖于细节，细节应该依赖于抽象。**即，高层模块不应该依赖于低层模块，二者都应该依赖于抽象。 （5）接口分离原则。不应该强迫客户依赖于它们不用的方法。接口属于客户，不属于它所在的类层次结构。即：依赖于抽象，不要依赖于具体，同时在抽象级别不应该有对于细节的依赖。这样做的好处就在于可以最大限度地应对可能的变化。

• 一般来说，对面向对象软件的测试可分为下列4个层次进行。 （1）算法层。测试类中定义的每个方法，基本上相当于传统软件测试中的单元测试。 （2）类层。测试封装在同一个类中的所有方法与属性之间的相互作用。在向面对象软件中类是基本模块，因此可以认为这是面向对象测试中所特有的模块测试。 （3）模板层。测试一组协同工作的类之间的相互作用，大体上相当于传统软件测试中的集成测试，但是也有面向对象软件的特点（例如，对象之间通过发送消息相互作用）。 （4）系统层。把各个子系统组装成完整的面向对象软件系统，在组装过程中同时进行测试。

考试真题

• 面向对象的分析模型主要由顶层架构图、用例与用例图和（）构成：设计模型则包含以（）表示的软件体系机构图、以交互图表示的用例实现图、完整精确的类图、描述复杂对象的（）和用以描述流程化处理过程的活动图等。

  A.数据流模型 B.领域概念模型 C.功能分解图 D.功能需求模型 A.模型视图控制器 B.组件图 C.包图 D.2层、3层或N层 A.序列图 B.协作图 C.流程图 D.状态图

  答案：BCD

• 在面向对象设计的原则中、（D）原则是指抽象不应该依赖予细节，细节应该依赖于抽象，即应针对接口编程，而不是针对实现编程。

  A.开闭 B.里氏替换 C.最少知识 D.依赖倒置

2.统一建模语言UML

• UML（统一建模语言）：是一种可视化的建模语言，而非程序设计语言，支持从需求分析开始的软件开发的全过程。

• 从总体上来看，UML的结构包括构造块、规则和公共机制三个部分。 （1）构造块。UML有三种基本的构造块，分别是事物（thing）、关系（relationship）和图（diagram）。事物是UML的重要组成部分，关系把事物紧密联系在一起，图是多个相互关联的事物的集合。 （2）公共机制。公共机制是指达到特定目标的公共UML方法。 （3）规则。规则是构造块如何放在一起的规定。

  

• 结构事物：模型的静态部分，如类、接口、用例、构件等；

• 行为事物：模型的动态部分，如交互、活动、状态机；

• 分组事物：模型的组织部分，如包；

• 注释事物：模型的解释部分，依附于一个元素或一组元素之上对其进行约束或解释的简单符号。

• 依赖：一个事物的语义依赖于另一个事物的语义的变化而变化

• 关联：是一种结构关系，描述了一组链，链是对象之间的连接。分为组合和聚合，都是部分和整体的关系，其中组合事物之间关系更强。两个类之间的关联，实际上是两个类所扮演角色的关联，因此，两个类之间可以有多个由不同角色标识的关联。

• 泛化：**一般/特殊的关系，**子类和父类之间的关系

• 实现：一个类元指定了另一个类元保证执行的契约。

  

考试真题

• 采用面向对象方法进行软件开发时，将汽车作为一个系统。以下（B）之间不属于组合 （Composition）关系。 A.汽车和座位 B.汽车和车窗 C.汽车和发动机 D.汽车和音乐系统

• 如图所示的UML类图中，Shop和Magazine之间为（A）关系，Magazine和Page之间为（C）关系。UML类图通常不用于对（D）进行建模。

  

  A.关联 B.依赖 C.组合 D.继承 A.关联 B.依赖 C.组合 D.继承 A.系统的词汇 B.简单的协作 C.逻辑数据库模式 D.对象快照

• UML2.0图，书上是13种，有的说法还包含制品图，一共14种，了解即可，总分类如下：

  

• 类图：静态图，为系统的静态设计视图，展现一组对象、接口、协作和它们之间的关系。UML类图如下：

  

• 对象图：静态图，展现某一时刻一组对象及它们之间的关系，为类图的某一快照。在没有类图的前提下，对象图就是静态设计视图。如下：

  

• 用例图：静态图，展现了一组用例、参与者以及它们之间的关系。用例图中的参与者是人、硬件或其他系统可以扮演的角色；用例是参与者完成的一系列操作，用例之间的关系有扩展、包含、泛化。如下：

  

• 序列图：即顺序图，动态图，是场景的图形化表示，描述了以时间顺序组织的对象之间的交互活动。有同步消息（进行阻塞调用，调用者中止执行，等待活控制权返回，需要等待返回消息，用实心三角箭头表示），异步消息（发出消息后继续执行，不引起调用者阻塞，也不等待返回消息，由空心箭头表示）、返回消息（由从右到左的虚线箭头表示）三种。如下：

  

• 通信图：动态图，即协作图，强调参加交互的对象的组织。如下：

  

• 状态图：动态图，展现了一个状态机，描述单个对象在多个用例中的行为，包括简单状态和组合状态。转换可以通过事件触发器触发，事件触发后相应的监护条件会进行检查。状态图中转换和状态是两个独立的概念，如下：图中方框代表状态，箭头上的代表触发事件，实心圆点为起点和终点。

  

• 活动图：动态图，是一种特殊的状态图，展现了在系统内从一个活动到另一个活动的流程。活动的分岔和汇合线是一条水平粗线。牢记下图中并发分岔、并发汇合、监护表达式、分支、流等名词及含义。每个分岔的分支数代表了可同时运行的线程数。活动图中能够并行执行的是在一个分岔粗线下的分支上的活动

  

• 构件图（组件图）：静态图，为系统**静态实现视图，展现了一组构件之间的组织和依赖。**如下：

  

• 部署图：静态图，为系统静态部署视图，部署图物理模块的节点分布。它与构件图相关，通常一个结点包含一个或多个构件。其依赖关系类似于包依赖，一因此部署组件之间的依赖是单向的类似于包含关系。如下：

  

• UML 4+1视图 （1）逻辑视图。逻辑视图也称为设计视图，它表示了设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集。 （2）进程视图。进程视图是可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例，描述了并发与同步结构。 （3）实现视图。实现视图对组成基于系统的物理代码的文件和构件进行建模。 （4）部署视图。部署视图把构件部署到一组物理节点上，表示软件到硬件的映射和分布结构。 （5）用例视图。用例视图是最基本的需求分析模型。

  

考试真题

• 用例（use case）用来描述系统对事件做出响应时所采取的行动。用例之间是具有相关性的。在一个会员管理系统中，会员注册时可以采用电话和邮件两种方式。用例“会员注册"和"电话注册"、 "邮件注册”之间是（C）关系。 A.包含（include） B.扩展（extend） C.泛化（generalize） D.依赖（depends on）

• 以下关于UML状态图的叙述中，不正确的是（B）

  A.活动可以在状态内执行，也可以在迁移时执行

  B.若事件触发一个没有特定监护条件的迁移，则对象离开当前状态

  C、迁移可以包含事件触发器，监护条件和状态

  D、事件触发迁移

• 在UML提供的系统视图中，（A）是逻辑视图的一次执行实例，描述了并发与同步结构；（D）是最基本的需求分析模型。

  A.进程视图 B.实现视图 C.部署视图 D.用例视图

  A.进程视图 B.实现视图 C.部署视图 D.用例视图

• 如下所示的UML图是（D），图中（I）表示（A）,（Ⅱ）表示（B）。

  A.序列图 B.状态图 C.通信图 D.活动图 A.合并分叉 B.分支 C.合并汇合 D.流 A.分支条件 B.监护表达式 C.动作名 D.流名称

  

3.设计模式

• 架构模式：软件设计中的高层决策，例如C/S结构就属于架构模式，架构模式反映了开发软件系统过程中所作的基本设计决策。

• 设计模式：每一个设计模式描述了一个在我们周围**不断重复发生的问题，以及该问题的解决方案的核心。**这样，你就能一次又一次地使用该方案而不必做重复劳动。设计模式的核心在于提供了相关问题的解决方案，使得人们可以更加简单方便的复用成功的的设计和体系结构。 四个基本要素：模式名称、问题（应该在何时使用模式）、解决方案（设计的内容）、效果（模式应用的效果）。

• 惯用法：是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用一计数就是C++语言中的一种惯用法。

  

• 创建型设计模式

• 结构形设计模式

  

• 行为型设计模式

  

  

考试真题

• 设计模式描述了一个出现在特定设计语境中的设计再现问题，并为它的解决方案提供了一个经过充分验证的通用方案，不同的设计模式关注解决不同的问题。例如，抽象工厂模式提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类，它是一种（54）模式；（55）模式将类的抽象部分和它的实现部分分离出来，使它们可以独立变化，它属于（56）模式；（57）模式将一个请求封装为一个对象，从而可用不同的请求对客户进行参数化，将请求排队或记录请求日志，支持可撤销的操作。

  （54）A.组合型 B.结构型 C.行为型 D.创建型 （55）A.Bridge B.Proxy C.Prototype D.Adapter （56）A.组合型 B.结构型 C.行为型 D.创建型 （57）A.Command B.Facade C.Memento D.Visitor

  答案：D A B A

• 欲开发一个绘图软件，要求使用不同的绘图程序绘制不同的图形，该绘图软件的扩展性要求将不断扩充新的图形和新的绘图程序，以绘制直线和图形为例，得到如下图所示的类图，该设计采用（）模式将抽象部分与其实现部分分离，使它们都可以独立的变化。其中（）定义了实现类接口，该模式适用于（）的情况，该模式属于（）模式。

  

  A、适配器（adapten） B、装饰（Decorator） C、桥接（Bridge） D、组合（composite） A、Shape B、Circle和Rectangle C、V1Drawing和V2Drawing D、Drawing

  A、不希望在抽象和它的实现部分之间有一个固定判定关系.

  B、想表示对象的部分-整体层次结构.

  C、想使用一个已经存在的类，而它的接口不符合要求

  D、在不影响其他对象的情况下，以动态透明的方式给单个对象添加职责

  A、创建型对象 B、结构型对象 C、行为型对象 D、结构型类

  答案：A A A B