软件设计师-5.软件工程基础知识

5.1 软件工程概述

5.1.1 软件生存周期

软件：包含程序、数据及相关文档。

软件工程：涉及到软件开发、维护、管理等多方面的原理、工具与环境。最终的目的是开发高质量的软件。

目的：提高软件生产率、提高软件质量、降低软件成本。

声明周期：问题定义 -> 可行性分析 -> 需求分析 -> 总体设计 -> 详细设计 -> 编码和单元测试 -> 综合测试 -> 维护。

• 问题定义：要解决的问题是什么
• 可行性分析：研究问题的范围，是否值得去解决，是否有可行的解决办法
• 需求分析：确定软件系统必须要做什么，确定功能、性能、数据和界面要求，确定逻辑模型
• 总体设计：概括地说，如何解决这个问题？指定推荐系统的详细计划并设计软件的结构
• 详细设计：怎么样具体去实现这个系统？对模块完成的功能进行具体描述。
• 编码和单元测试：写成某种特定程序设计语言表示的源程序清单及测试每一个模块
• 综合测试：通过各种类型的测试使软件达到预定的要求
• 维护：通过各种必要的维护活动使系统持久满足用户的需要

文档的作用：

1. 提高软件开发过程的能见度
2. 提高开发效率，便于发现错误和不一致性
3. 作为开发人员在一定阶段的工作成功和结束标志
4. 记录开发过程中的有关信息，便于协调以后的软件、开发、使用和维护
5. 提供对软件的运行、维护和培训的有关信息，便于相关人员和用户之间的写作、交流和了解
6. 便于潜在用户了解软件的功能、性能等各项指标，为他们选购符合自己需要的软件提供依据

5.1.2 软件生存周期模型

类型	特点
瀑布模型 Waterfall Model	将软件生存周期各个活动规定为依线性顺序连接起来的若干阶段的模型。适合需求明确的模型，但缺乏灵活性，客户需完整表示需求。
演化模型 Evolutionary Model	适合对需求缺乏准确认识的情况，根据用户使用过程中提出的意见和建议对原型不断重新改进，缺点是要对用户要求加以控制
增量模型 Incremental Model	每一线性序列产生软件的可发布的“增量”，但需要对变更进行规划，否则会造成后来增量的不稳定，部分增量可能需要重新开发
螺旋模型 Spiral Model	结合瀑布模型和演化模型的特点，并加入风险分析，适合用户需求的动态变化，适合庞大、复杂并且具有高风险的系统
喷泉模型 Fountain Model	以用户需求为基础，适合面向对象开发，开发过程具有迭代性和无间隙性，开发要重复多次，且开发活动不存在明显边界
统一过程 Unified Process	用例和风险驱动，以架构为中心，迭代的增量开发过程，将开发项目划分为小的“袖珍项目”，其每个都包含所有元素
敏捷方法 Agile Development	通过“尽可能早地、持续地对有价值的软件交付”使客户满意。包括极限编程XP、水晶法、并列争求法和自适应软件开发ASD

• 瀑布模型

  瀑布模型非常看重文档。

• 

   

  假设软件中有以下几个错误，哪个错误引起的后果最严重？

  • 需求分析错误
  • 软件设计错误
  • 编码错误
  • 测试错误
  • 维护错误

  需求分析错误

• 演化 模型、增量模型、螺旋模型 都是在原型模型的基础上演变而来。

  原型模型 就是 一个简单的模型(可快速开发)，例如要开发一个系统，我们可以先短时间开发出界面效果，给客户演示后根据搜集的意见，在此基础上增加功能，或者重新设计功能。

  很多客户其实页不知道自己需要什么，当我们出一个原型后，客户就会根据这个原型把自己的想法提出来。

• 螺旋模型 ： 环+原型

   

• 喷泉模型

  每个步骤之间没有明确的界限

   

• 敏捷方法：

  考虑的是时效性，文档不是很重要

5.1.3 软件开发方法

• 结构化方法：自顶向下、逐层分解。原则是分解与抽象，开发周期长，不适用与大规模、复杂的项目以及变化的需求。
• Jackson方法：面向结构的开发方法。主要包括 JSP（Jackson Structured Programming）和JSD（Jackson System Development）
• 原型化方法：适合用户需求不清晰、业务理论不确定、且需求经常变化的情况适合小规模的项目。
• 面向对象开发方法：包括面向对象分析、设计与实现，适合比较复杂的项目模型。

5.2 软件需求分析

1）可行性分析

 

技术可行性：使用现有技术能实现这个系统吗？

经济可行性：这个系统的经济效益能超过它的开发成本吗？

操作可行性：系统的操作方式在该用户组织内行得通吗？

2）软件需求分析

系统必须完成的事，以及必须具备的品质。包括：

1. 功能需求：所开发的产品必须具备什么功能
2. 非功能需求：是指产品必须具备的属性或品质，如可靠性、性能、响应时间、容错性、扩展性等
3. 设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明，例如必须采用国有自主知识版权的数据库系统、必须运行在UNIX操作系统之下等。

5.3 软件

1）软件设计原则

软件设计原则：抽象、模块化、信息隐蔽、模块独立

软件设计的任务与活动

 

2）内聚和耦合

功能内聚：最强的内聚，完成一个单一功能，各个部分协同工作，缺一不可。

顺序内聚：各个处理元素都密切相关与同一功能，且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入

通信内聚：所有处理元素集中在一个数据结构区域上，或者各处理使用相同的输入数据或产生相同的输出数据

过程内聚：模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行

瞬时内聚（时间内聚）：把需要同时执行的动作组合在一起形成的模块

逻辑内聚：模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能

偶然内聚（巧合内聚）：模块内的各处理元素之间没有任何联系

非直接耦合：两个模块之间没有直接关系，分别从属于不同模块的控制和调用，之间不传递任何信息。

数据耦合：两个模块之间有调用关系，传递简单的数据值

标记耦合：两个模块之间传递的是数据结构

控制耦合：一个模块调用另一个模块时，传递的是控制变量，被调用模块根据控制变量执行某个功能

外部耦合：模块间通过软件之外的环境联结（如 I/O 将模块耦合到特定的设备、格式、通用协议上）

公共耦合：通过一个公共数据环境互相作用的那些模块间的耦合

内容耦合：一个模块直接使用另一个模块的内部数据；或通过非正常入口而转入另一个模块内部

5.4 软件测试

5.4.1 V模型

 

需求阶段 对应 验收测试 ：有效性测试、软件配置审查、验收测试

规格说明 对应 系统测试 ：恢复测试、安全性测试、强度测试、性能测试、可靠性测试和安装测试

概要设计 对应 集成测试 ：模块间的接口和通信

详细设计 对应 单元测试 ：模块接口、局部数据结构、边界条件、独立的路径、错误处理

编码

5.4.2 软件测试的过程

• 单元测试|模块测试：模块编写完成且无编译错误后进行。由程序员对自己编写的模块进行测试，主要发现编程和详细设计中产生的错误，测试计划应该在详细设计阶段制定。一般使用白盒测试。

  白盒测试：白盒测试又称结构测试、透明盒测试、逻辑驱动测试或基于代码的测试。白盒测试是一种测试用例设计方法，盒子指的是被测试的软件，白盒指的是盒子是可视的，即清楚盒子内部的东西以及里面是如何运作的。"白盒"法全面了解程序内部逻辑结构、对所有逻辑路径进行测试。

• 集成测试：把模块按系统设计说明书的要求组合起来进行测试。对由各模块组装而成的程序进行测试，主要目标是发现模块间的接口和通信问题。集成测试主要发现设计阶段产生的错误，集成测试计划应该在概要设计阶段完成制定。（黑盒测试）

• 确认测试：检查软件的功能、性能和其他特征是否与用户需求一致，它是以需求规格说明书作为依据的测试，软件确认测试首先要进行有效性测试及软件配置审查，然后进行验收测试。经过管理部门的认可和专家的鉴定后，软件即可交给用户使用。（黑盒测试）

• 系统测试：把软件放在实际的硬件和网络环境中进行测试，主要测试软件的非功能需求和质量属性是否得到满足、场景的系统测试主要有恢复性测试、安全性测试强度测试、性能测试、可靠性测试和安装测试。（黑盒测试）

5.4.3 黑盒测试与白盒测试

动态测试：

• 黑盒测试|功能测试
  • 等价类划分
  • 边值分析
  • 错误推测
  • 因果图
• 白盒测试|结构测试
  • 逻辑覆盖
    • 语句覆盖
    • 判断覆盖
    • 条件覆盖
    • 条件判定覆盖
    • 条件组合覆盖
    • 路径覆盖
  • 循环覆盖
  • 基本路径测试

下面我们对逻辑覆盖做深入的了解，先看一个C语言源代码：

/*  *  白盒测试逻辑覆盖测试范例  */ 
int logicExample(int x, int y) {     
    int magic=0;     
    if(x>0 && y>0) {         
        magic = x+y+10; // 语句块1      
    } else {         
        magic = x+y-10; // 语句块2     
    }          
    if(magic < 0) {         
        magic = 0;      // 语句块3     
    }     
    return magic;       // 语句块4 
}

1. 语句覆盖：被测程序的每个语句至少执行一次。是一种很弱的覆盖标准。

   测试用例：

   • {x=3, y=3}可以执行到语句块1和语句块4，所走的路径：a-b-e-f
   • {x=-3, y=0}可以执行到语句块2、语句块3和语句块4，所走的路径：a-c-d-f
   • 这样，通过两个测试用例即达到了语句覆盖的标准，当然，测试用例（测试用例组）并不是唯一的。

   测试的充分性：

   • 假设第一个判断语句if(x>0 && y>0)中的“&&”被程序员错误地写成了“||”，即if(x>0 || y>0)，使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的语句覆盖，所以语句覆盖无法发现上述的逻辑错误。

   注意： magic < 0 这个条件， 当它为假时，无语句执行，所以在语句覆盖的情况下，这里只要走 d(即判断为真) 这一条路径也符合语句覆盖的条件。

   在六种逻辑覆盖标准中，语句覆盖标准是最弱的。

2. 判断覆盖：分支覆盖，判断表达式至少获得一次真、假值。判断覆盖比语句覆盖强。

   测试用例：

   • 数据	P1	P2	路径
     {x=3, y=3}	T	F	a-b-e-f
     {x=-3, y=0}	F	T	a-c-d-f

   • 所有条件的可能取值都满足了一次，而且所有的判断本身的判定结果也都满足了一次。

   测试的充分性：

   • 假设第一个判断语句if(x>0 && y>0)中的“&&”被程序员错误地写成了“||”，即if(x>0 || y>0)，使用上面设计出来的一组测试用例来进行测试，仍然可以达到100%的判定覆盖，所以判定覆盖也无法发现上述的逻辑错误。

     跟语句覆盖相比：由于可执行语句要不就在判定的真分支，要不就在假分支上，所以，只要满足了判定覆盖标准就一定满足语句覆盖标准，反之则不然。因此，判定覆盖比语句覆盖更强

   magic < 0 这个条件， 在判断覆盖的情况下，这里需要走d（真）和f（假） 2条路径才符合判断覆盖的条件。

3. 条件覆盖：每个判定语句中的每个逻辑条件语句的各种可能值至少满足一次。

   在本例中有两个判断if(x>0 && y>0)（记为P1）和if(magic < 0)（记为P2），共计三个条件x>0（记为C1）、y>0（记为C2）和magic<0（记为C3）。

   测试用例：

   • 数据	C1	C2	C3	P1	P2	路径
     {x=3, y=3}	T	T	T	T	F	a-b-e-f
     {x=-3, y=0}	F	F	F	F	T	a-c-d-f

   • 三个条件的各种可能取值都满足了一次，因此，达到了100%条件覆盖的标准。

   测试充分性：

   • 上面的测试用例同时也到达了100%判定覆盖的标准，但并不能保证达到100%条件覆盖标准的测试用例（组）都能到达100%的判定覆盖标准，看下面的例子：

     数据	C1	C2	C3	P1	P2	路径
     {x=3, y=0}	T	F	T	F	F	a-c-e-f
     {x=-3, y=5}	F	T	F	F	F	a-c-e-f

     既然条件覆盖标准不能100%达到判定覆盖的标准，也就不一定能够达到100%的语句覆盖标准了。

4. 条件判定覆盖：每个条件所有可能的值（真/假）至少出现一次，且每个判定本身的判定结果（真/假）也至少出现一次。

   测试用例：

   • 数据	C1	C2	C3	P1	P2	路径
     {x=3, y=3}	T	T	T	T	F	a-b-e-f
     {x=-3, y=0}	F	F	F	F	T	a-c-d-f

   • 所有条件的可能取值都满足了一次，而且所有的判断本身的判定结果也都满足了一次。

   测试的充分性：

   • 达到100%判定-条件覆盖标准一定能够达到100%条件覆盖、100%判定覆盖和100%语句覆盖。

5. 条件组合覆盖：每个判定条件的各种可能值的组合都至少出现一次。

   测试用例：

   • 数据	C1	C2	C3	P1	P2	路径
     {x=-3, y=0}	F	F	F	F	F	a-c-e-f
     {x=-3, y=2}	F	T	F	F	F	a-c-e-f
     {x=-3, y=0}	T	F	F	F	F	a-c-e-f
     {x=3, y=3}	T	T	T	T	T	a-b-d-f

   • C1和C2处于同一判断语句中，它们的所有取值的组合都被满足了一次。

   测试的充分性：

   • 100%满足条件组合标准一定满足100%条件覆盖标准和100%判定覆盖标准。
   • 但上面的例子中，只走了两条路径 a-c-e-f和a-b-d-f，而本例的程序存在三条路径（a-b-d-f/a-c-d-f/a-c-e-f）,还有一条路径是a-b-e-f,是不可能覆盖的路径。

6. 路径覆盖：覆盖所有可能的路径。

   测试用例：

   • 数据	C1	C2	C3	P1	P2	路径
     {x=3, y=5}	T	T	T	T	T	a-b-d-f
     {x=0, y=2}	F	T	T	F	T	a-c-d-f
     这条路径不可能						a-b-e-f
     {x=-8, y=3}	F	T	F	F	F	a-c-e-f

   • 所有可能的路径都满足过一次。

   测试的充分性：

   • 由上表可见，100%满足路径覆盖，但并不一定能100%满足条件覆盖（C2只取到了真），但一定能100%满足判定覆盖标准（因为路径就是从判断的某条分支走的）

5.4.4 测试原则与注意事项

测试原则：

1. 尽早并不断的进行测试，测试应贯穿在开发的各个阶段，尽早纠正错误，消除隐患。
2. 测试工作应该避免由原开发系统软件的人或小组承担，这样才可以更加彻底地进行测试。
3. 设计测试方案的时候，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果。
4. 在设计测试用例时，不仅要设计有效合理的输入条件，也要包含不合理、失效的输入条件
5. 在测试程序时，不仅要检验程序是否做了该做的事，还要检验程序是否做了不该做的事。
6. 严格按照测试计划来进行，避免测试的随意性。
7. 妥善保持测试计划、测试用例，作为系统软件文档的组成部分，为维护提供方便。
8. 测试用例都是精心设计出来的，可以为重新测试或追加测试提供方便。

测试注意事项：

1. 发现错误较多的模块，在纠正错误后，遗留的错误也较多。
2. 测试的目的主要是为了发现错误，而不是验证程序没有错误。
3. 通过软件测试不可能完全消除错误，完全测试是不可能的。
4. 错误不可能全部被发现，不可能保证程序100%没有问题。
5. 测试工作是由开发方负责的，软件需求阶段开始提出。
6. 开发时应注重将质量构建进产品，而不是在产品出来后再测试。
7. 测试人员应与开发人员密切合作，推动后续开发和测试规范化。
8. 软件测试的目的不仅要找出缺陷，还要随时提供质量相关信息。

5.5 软件运行与维护

软件维护

可维护性因素决定：

• 可理解性
• 可测试性
• 可修改性

软件维护类型：

• 正确性维护（17%~21%）：是指改正在系统开发阶段已发生而系统测试阶段尚未发现的错误； 改正性维护。
• 适应性维护（18%~25%）：是指使应用软件适应新技术变化和管理需求变化而进行的修改；
• 完善性维护（4%）：是指为了扩充功能和改善性能而进行的修改，主要是指对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能和性能特征。
• 预防性维护（50%~60%）：是指为了改进应用软件的可靠性和可维护性，为了适应未来的软硬件环境变化，主动增加预防性的功能，以使应用系统适应各类变化而不被淘汰。

5.6 程序员职业素养

软件工程的基本原理

1. 用分阶段的生命周期计划严格管理，将复杂问题简化处理。
2. 坚持进行阶段评审。
3. 记录软件每个版本的状态，实行严格的版本控制。
4. 采用现代程序设计技术，但不是最新的技术。
5. 结果能清楚地审查。
6. 开发小组人员少而精。
7. 不断积累和改进软件过程实践经验和技术。

软件工程的最终目标

1. 正确性：正确实现算法功能，最重要的目标，得到正确或相符的结果或效果。
2. 可用性：在某个考察时间，系统能够正常运行的概率或时间占有率期望值。
3. 可靠性：在一定时间内，在一定条件下无故障地执行指定功能的能力或可能性。
4. 友好性：具有良好的使用性。
5. 可读性：可读的、可以理解的，方便分析、修改和移植。
6. 健壮性：对不合理的数据或非法的操作进行检查、纠正。
7. 效率：对计算机资源的消耗，包括计算机内存和运行时间的消耗。
8. 可移植性：从一个计算机系统或环境转移到另一个计算机系统或环境的难易程度。

程序员的职业素养：

1. 团队精神和沟通能力：个人能力是有限的，团队才能创造奇迹；及时汇报项目进展，了解偏差。
2. 良好的文档习惯：工作需要有日志文档，进行总结；代码需要有技术文档，便于之后查错、升级和模块复用。
3. 编码规范化、标准化：要养成良好的编码习惯，有助于代码的移植和纠错及不同技术人员之间的协作。代码需要有良好的可读性。注意：代码要简约，但不是简单。
4. 养成测试习惯：每段代码、每个子模块完成后需进行测试，将一些潜在的问题最早的发现和解决，这样对整体系统建设的效率和可靠性就有了最大的保证。
5. 学习和总结能力：技术会淘汰，需要不断掌握新的技术和新的技能，不只是编程能力，还有撰写文档和沟通等多方面的能力。

5.6习题

题5

以下关于数据流图的说法，错误的是(）。

A.数据流图是用来作为结构化分析建模的一种工具

B.传统的数据流图中主要包含加工、外部实体、数据流、数据存储、控制流5中基本构件

C.数据流图可只有一个也可以有多个。

D.数据流图属于需求分析阶段的产物

答案 B

数据流图的主要构件是 加工、外部实体、数据流、数据存储，不包含 控制流。

题6

下面关于内聚和耦合的描述中，错误的是（）。

A.内聚体现的是代码功能的集中程度。

B.耦合体现的是模块间联系的紧密程度。

C.通讯内聚比逻辑内聚的内聚度更高。

D.数据耦合比公共耦合的耦合度更高。

答案D

本体主要考察内聚与耦合的概念。高内聚、低耦合是软件设计的一个原则，其中内聚是指模块内部各元素之间的紧密程度，也就是代码功能的集中程度。耦合是指模块之间互相联系的紧密程度。

模块的内聚通常分为7中，根据内聚度从高到低排序如下表所示。

内聚类型	描述
功能内聚	完成一个单一功能，各部分协调工作，缺一不可
顺序内聚	处理元素相关，而且必须顺序执行
通信内聚	所有处理元素集中在一个数据结构区域上
过程内聚	处理元素相关，且必须按某个特定次序执行
瞬时内聚	所包含的任务必须在同一时间间隔内完成
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

模块的耦合通常分为7中，根据耦合度从低到高排序如下表所示。

耦合类型	描述
非直接耦合	没有直接联系，互相不依赖
数据耦合	借助参数表传递简单数据
标记耦合	一个数据结构的一部分借助于模块接口被传递
控制耦合	模块间传递的信息中包含用于控制模块内部逻辑的信息
外部耦合	与软件以外的环境有关
公共耦合	多个模块引用同一个全局数据
内容耦合	一个模块访问另一个模块的内部数据；一个模块不通过正常入口转到另一模块的内部；两个模块有一部分程序代码重叠；一个模块有多个入口

题7

下列选项中，不属于可用性子特性的是（）。

A.可理解性

B.易学性

C.依从性

D.可操作性

答案 C

本地考查 ISO/IEC9126 的软件质量模型。其中6个质量特性和21个质量子特性是我们主要理解的内容。

1. 功能性

   功能性是指软件所具备的各项功能及其规定性质有关的一组属性，包括：

   • 适合性：规定任务能否提供一组功能，以及这组功能的适合程度的软件属性。适合程度的例子是面向任务系统中由子功能构成的功能是否合适、表容量是否合适等。
   • 准确性：能否得到正确的结果或效果的属性。此属性包括计算值所需的准确程度。
   • 互操作性（互用性）：同其他指定系统进行交互的能力有关的软件属性。为避免可能与易替换的含义相混淆，此处用互操作性（互用性）而不用兼容性。
   • 依从性：使软件遵循有关的标准、约定、法规及类似规定的软件属性。
   • 安全性：防止对程序及数据的非授权的故意或意外的访问的能力有关的软件属性。

2. 可靠性

   可靠性是指在规定运行条件下和规定时间内，与软件维护其性能级别的能力有关的一组属性。可靠性反映的是软件中存在的需求错误、设计错误和实现错误而造成的失效情况，包括：

   • 成熟性：由软件故障引起失效的频度的相关属性。
   • 容错性：在软件故障或违反指定接口的情况下，维持规定的性能水平的能力，有关的属性。性能水平包括失效防护能力。
   • 可恢复性：在失效发生后，重建其性能的水平，并恢复直接受影响数据的能力，以及为达此目的所需时间和努力。

3. 可用性

   可用性是指根据规定用户或隐含用户的评估所作出的努力程度，包括：

   • 可理解性：用户为认识逻辑概念机器应用范围所花费的努力
   • 易学性：用户为学习应用花费的努力
   • 可操作性性：用户为操作和运行控制的努力

4. 效率

   效率是指在规定条件下，软件性能级别和所用资源总量之间的关系，包括：

   • 时间特性：执行其功能响应和处理时间，以及吞吐量
   • 资源特性：在软件执行其功能时所用的资源数量及其使用时间

5. 可维护性

   可维护性是指对软件进行修改的难易程度。

   • 可分析性：为诊断缺陷或失效原因，及为判定待修改的部分所需的努力
   • 可改变性：进行修改、排除错误或使用环境变化所需的努力
   • 稳定性：修改所造成的未预料结果的风险
   • 可测试性：确认已修改软件所需的努力

6. 可移植性

   可移植性是指与一个软件从一个环境转移到另一个环境运行的能力。

   • 适应性：软件无需为该软件准备活动或手段就可能使用不同的规定环境。
   • 可安装性：在指定环境下安装软件所需的能力
   • 遵循性（一致性）：使软件遵循与可移植性有关的标准或约定有关的属性。
   • 可替换性：软件在该软件环境中用来替代指定的其他软件的机会和努力有关的熟悉。

题8

以下关于开发模型的描述中，不正确的是（）。

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

B.喷泉模型主要用于描述面向对象的开发过程

C.瀑布模型严格规定了各阶段必须提交的文档

D.螺旋模型结合了瀑布模型和快速原型模型的优点

答案 D

瀑布模型严格遵循软件生命周期各阶段的固定顺序：计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入下一阶段，整个模型就像一个瀑布。瀑布模型有许多优点：可强迫开发人员采用规范的方法；严格规定了各阶段必须提交的文档；要求每个阶段结束后，都要进行严格的评审。但瀑布模型过于理想化，而且缺乏灵活性，无法在开发过程中逐渐明确用户难以确切表达或已是难以想到的需求，直到软件开发完成后才发现与用户需求有很大的距离，此时必须付出高额的代价才能纠正这一偏差，这一开发模型主要适用于需求非常明确的应用。

喷泉模型主要用于描述面向对象的开发过程，喷泉一词体现了面向对象开发过程的迭代和无间隙特征。迭代意味着模型中的开发活动常常需要多次重复，每次重复都会增加或明确一些目标系统的特性，但却不是对先前工作结果的本质性改动。无间隙是指在开发活动（如分析、设计、编程）之间不存在明显的边界，而是运行各开发活动交叉、迭代的进行。

快速原型模型对于许多需求不明确的项目，比较适合。它采用了一种动态定义需求的方法，通过快速地建立一个能够反映用户主要需求的软件模型，让用户在计算机上使用它，了解其概要，在根据反馈的结果进行修改，因此能够充分体现用户的参与和决策。原型化人员对原型的实施很重要，衡量它们的重要标准是能否从用户的模糊描述中快速地获取实际的需求。

演化模型也是一种原型化开发方法，但与快速原型模型略有不同。在快速原型模型中，原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。而演化模型的开发过程，则是从初始模型逐步演化为最终软件产品的渐进过程。也就是说，快速原型模型是一种“抛弃式”的原型化方法，而演化模型是一种“渐进式”的原型化方法。

螺旋模型结合了瀑布模型和演化模型的优点，最主要的特点在于加入了风险分析。它是由制定计划、风险分析、实施工程、客户评估这一循环组成的，它最初从概念项目开始第一个螺旋，这种开发模型将风险缝隙作为一个单独的阶段来做，比较适合风险较大的大中型的软件开发项目。

题10

UP 的基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”。UP 将一个周期的开发过程划分为4个阶段，其中（）开发剩余的构件。

A.初始阶段

B.精化阶段

C.构建阶段

D.提交阶段

答案 C

统一过程 UP 的基本特征是“用例驱动、以架构为中心的和受控的迭代式增量开发”。一个 UP 可分为若干个周期，每个周期开发过程被分为4个阶段，每个阶段可进行若干次迭代。

1. 初始阶段：该阶段的主要任务包括确定项目范围和边界，识别系统的关键用例，展示系统的候选架构，估计项目费用和时间，评估项目风险。其意图是建立项目的范围和版本，确定业务实现的可能性和项目目标的稳定性。提交结果包括原始的项目需求和业务用例。
2. 精化阶段：该阶段主要任务包括分析系统问题领域，建立软件架构基础，淘汰最高风险元素。其意图是对问题域进行分析，建立系统的需求和架构，确定技术实现的可行性和系统架构的稳定性。提交结果包括系统架构及其相关文档、领域模型、修改后的业务用例和整个项目的开发计划。
3. 构建阶段：该阶段相对简单一些，其主要任务包括资源管理、控制和流程优化，开发剩余的构件，然后进行构件组装和测试等。其主要意图是将软件产品提交给用户。
4. 提交阶段：该阶段主要任务包括进行 β测试，制作发布版本，用户文档定稿，确认新系统，获取用户反馈，培训、调整产品使最终用户可以使用产品。其主要意图是将软件产品提交用户。

题13

CMM 将软件过程的成熟的分为5个等级。以下关于 CMM各级别特征的描述中，不正确的是（）。

A.处于初始级的软件可能是混乱的，项目成功往往依赖于个人

B.管理级的最大特征是软件过程和产品质量有详细的度量标准

C.定义级的最大特征是软件过程文档化，并能持续地进行过程改进

D.可重复级能实现对成本、进度和功能特征的追踪

答案 C

CMM模型将软件开发过程的成熟度分为5个等级

1. 初始级：软件过程的特点是无序的有时甚至是混乱的。软件过程定义几乎处于无章法和步骤可循的状态，软件产品所取得的成功往往依赖极个别人的努力和机遇。初始级的软件过程是未加定义的随意过程，项目的执行是随意甚至是混乱的。也许，有些企业制定了一些软件工程规范，但若这些规范未能覆盖基本的关键过程要求，其执行没有政策、资源等方面的保证，那么仍被视为初始级。
2. 可重复级：已经建立起了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。焦点集中在软件管理过程上。一个可管理的过程则是一个可重复的过程，一个可重复的过程则能逐渐演化和成熟。从管理角度可以看到一个按计划执行的、阶段可控的软件开发过程。
3. 定义级：用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。全部项目均采用与实际情况吻合的、适当修改后的标准软件过程来进行操作。要求制定企业范围的工程化标准，而且无论是管理还是工程开发都需要一套文档化的标准，并将这些标准集成到企业软件开发标准过程中去。所有开发的项目需根据这个标准过程，剪裁出与项目适宜的过程，并执行这些过程。过程的剪裁不是随意的，在使用前需经过企业有关人员的批准。
4. 管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
5. 优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。

题17

下面关于极限编程（XP）的叙述中，不正确的是（）。

A.极限编程注重用户反馈

B.极限编程提倡减少文档

C.极限编程的4大价值观是沟通、变更、反馈、勇气

D.简答设计是极限编程的十二个最佳实践之一

答案 C

极限编程是一种敏捷开发方法。其他敏捷方法还有自适应开发、水晶方法、特性驱动开发等，他们都有一个共同的特点，那就是都将矛头指向了文档，它们认为传统软件工程方法太中，称为重量级方法，而相应的敏捷方法则是轻量级方法。

在极限编程方法终，提出了四大价值观：沟通、简单、反馈、勇气。

五大原则：快速反馈、简单性假设、逐步修改、提倡更改、优质工作。

还有十二个最佳实践：计划游戏、小型发布、隐喻、简单设计、测试先行、重构、集体代码所有制、结对编程、每周工作40小时、持续集成、编码标准和现场客户。

题19

如果两个小组独立地测试同一个程序，第一组发现60个错误，第二组发现50个错误，在两个小组发现的错误中有30个是共同的，那么可以估计程序中的错误总数是（）个？

A.50

B.60

C.100

D.120

答案 C

本题考查对软件测试策略的理解。对于这类题的求解，首先要求解出每组发现错误的效率，然后用其他发现的错误数除以效率，就可以估算出总的错误数。

对于第一组，发现60个错误，这其中有30个是与第二组相同，而第二组发现50个错误中，第一组还有20个没有发现，所以其发现错误的效率为 30/50=60%，因此可以估算出程序中错误总数为60/60% = 100。

同样的道理，通过计算第二小组的效率也可以估算出程序中总的错误数为100（50/(30/60)）。

另外由于两个小组是独立进行测试的，所以可以估计：程序中的错误总数为100个。

题21

在某教师管理系统中，教师的级别有教授、副教授、讲师，且教师年龄在 25~60 岁。若用等价类划分来进行相关测试，则（）不是最好的测试用例。

A.(博士，30)

B.(教授，40)

C.(副教授，70)

D.(博士，62)

答案 D

所谓等价类就是某个输入域的集合，对于一个等价类中的输入值来说，它们揭示程序中错误的作用是等效的。也就是说，如果等价类中的一个输入数据能检测出一个错误，那么等价类中的其他输入数据也能检测出同一个错误。（简而言之，等价类就是一个集合，一个等价类对应一种错误）

等价类可分为有效等价类和无效等价类，其中如果一个等价类内的数据是符合要求的、合理的数据，则称这个等价类为有效等价类；否则，则称这个等价类为无效等价类，无效等价类主要用来检验软件的容错性。

采用等价类划分法来设计测试用例的步骤如下：

1. 根据软件的功能说明，对每一个输入条件确定若干个有效等价类和若干个无效等价类，并为每个有效等价类和无效等价类编号。
2. 设计一个测试用例，使其覆盖尽可能多的尚未被覆盖的有效等价类。重复这一步，直至所有的有效等价类均被覆盖。
3. 设计一个测试用例，使其覆盖一个尚未被覆盖的无效等价类。重复这一步，直至所有的无效等价类均被覆盖。

在本题中，不难看出，有两个条件，一个是教师级别；另一个是年龄。从答案给出的4个选项来看，D选项中的两个输入都不是有效输入（不符合第三条），如果用这个用例检测出了一个错误，那么也不能确定是由哪个条件引起的，因此其不是一个好的测试用例。

题22

采用 McCabe 度量法计算如图所示程序图的环路复杂性为（）。

A.3

B.4

C.5

D.6

答案 B

本题主要考察环路复杂度计算，这也是软件设计师中的一个重点。

McCabe 度量法是一种基于程序控制流程的复杂性度量方法。采用这种方法要先画出程序图，然后采用公式计算环路复杂度。对于这种题目，场景的计算方法有如下4种：

1. 使用公式 V(G) = E-N+2（E是流程图中的边数，N是流程图中的结点数）。V(G) =12-10+2=4
2. 计算独立路径数，从控制流图来看，一条独立路径就是包含一条在其他独立路径中没有用过的边的路径。可知有4条路径，这个方法比较麻烦。
3. 计算流程图中判定的个数，然后用判定个数+1即可。本题中，可以看出判定个数是3（有分支的节点就是判定节点）
4. 计算控制流图中区域的数量，简单来说就是闭合环路+大区域，也可以得到结果为4

题25

定义风险参照水准是（）活动常用的技术。

A.风险识别

B.风险预测

C.风险评估

D.风险控制

答案 C

本题主要考察项目管理中风险管理的相关知识。

风险是一种不确定的事件，而且只要发生就会给项目带来影响。风险管理中的活动由风险识别、风险预测、风险评估、风险控制等。

• 风险识别的任务是通过建立风险条目检查表，试图系统化地确定对项目计划的威胁。该检查表可以用于识别风险，并使人们集中来识别一些常见的、已知的及可预测的风险。
• 风险预测，又称风险估算，它从两个方面评估一个风险：风险发生的可能性或概率；以及如果风险发生了所产生的的后果。
• 风险评估的任务是定义风险参考水平值，预测影响参考水平值的风险组合。
• 风险控制的任务是风险避免、风险监控和风险管理及意外事件计划。

题26

在进行软件工程风险分析时，项目管理人员要进行4种风险评估活动，这4种风险活动是（）以及确定风险估计的正确性。

A.建立表示风险概率的尺度，描述风险引起的后果，估计风险影响的大小

B.建立表示风险概率的尺度，描述风险引起的后果，确定产生风险的原因

C.确定产生风险的原因，描述风险引起的后果，估计风险影响的大小

D.建立表示风险概率的尺度，确定产生风险的原因，估计风险影响的大小

答案 A

风险是可能发生的事件，而且是会带来损失的事件，风险评估试图从两个方面评估每一个风险——风险发生的可能性，以及如果风险发生了，所产生的后果。项目计划者，以及其他管理人员和技术人员一起执行4个风险预测活动：

1. 建立一个尺度，以反映风险发生的可能性。
2. 描述风险的后果。
3. 估算风险对项目及产品的影响。
4. 标注风险预测的整体精度（正确性），以免产生误解。

题27

在下列说法中，（）是造成软件危机的主要原因。

①用户使用不当 ②软件本身特点 ③硬件不可靠

④对软件的错误认识 ⑤缺乏号的开发方法和手段 ⑥开发效率低

A.①③⑥

B.①②④

C.③⑤⑥

D.②⑤⑥

答案 D

软件危机是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。软件危机主要表现在：软件需求的增长得不到满足，软件生产成本高、价格昂贵，软件生产进度无法控制，软件需求定义不够准确，软件质量得不到保证，软件可维护性差。归纳起来，产生软件危机的内在原因可归结为两个重要方面：一方面是由于软件生产本身存在着复杂性；另一方面是与软件开发所使用的的方法和技术有关。

题28

在软件设计阶段，划分模块的原则是：一个模块的（）。

A.作用范围应该在其控制范围之内

B.控制范围应该在其作用范围之内

C.作用范围与控制范围互不包含

D.作用范围与控制范围不受任何限制

答案 A

模块的作用范围是指收受该模块的内部一个判断的所有模块集合，只有某一模块内含有依赖于该判定的操作，那么该模块就在该判定的作用范围内。

模块的控制范围包括该模块本身以及该模型的所有下属模块。控制范围完全取决于系统的结构，与模块本身并么有多大关系。

在系统设计中，对模块的作用范围和控制范围有两条规则：

1. 对任何一个判断，其作用范围应该是这个判断所在模块的控制范围的一个子集。换言之，所有受判断影响的模块应该从属于作出判断的那个模块。
2. 受模块M判定影响的模块，最好局限于模块M本身或其直接下属模块。

因此，一个模块的作用范围应该在其判断范围之内。

题29~30

某案件项目的活动图如下所示。图中顶点表示项目里程碑，连接顶点的边表示包含的活动，则该活动图的关键路径是（），活动FG的松弛时间为（）。

(29)

A.A-D-F-G-J

B.A-C-F-H-J

C.A-D-F-H-J

D.A-D-F-I-H-J

(30)

A.19 B.20 C.32 D.24

答案 C B

本题主要考察项目活动图。这类题目是考试中常考的知识点。而对于这类题目的考查，主要会考查关键路径、关键路径长度、某结点最早或最晚开始时间，以及某活动的松弛时间。

关键路径是途中从起点到终点长度最长的那条路径，而关键路径的长度是整个项目的工期。对于关键路径的求解，可以用观察法，比如在本题中，我们通过看图不难发现，路径 A-D-F-H-J 的长度为48，是最长的一条路径，因此它就是关键路径。

如果对观察法不熟练的话，也可以用计算的方法求解，这样就要求出每个结点的最早开始时间和最晚开始时间，然后最早开始时间和最晚开始时间相等的结点就是关键路径上的点，这样也能求出关键路径及关键路径长度。

求每个结点的最早开始时间时，采用顺推，从起点出发，起点的最早开始时间为0，那么要求B的最早开始时间，用0+3=3，另外要注意，如果要求F得最早开始时间，因为有两个箭头指向了它，那么就要分别将这两条路径的最早开始时间都计算出来，然后取较大的那个，从C到F的最早开始时间是10，从D到F的最早开始时间是18，因此F的最早开始时间是18。

而要求每个结点的最晚开始时间，则采用逆推，从终点出发，终点的最晚开始时间为关键路径长度，那么要求G得最晚开始时间，用48-7=41，另外要注意，如果要求I的最晚开始时间，因为有两个箭头从他出发，那么就要分别将这两条路径的最晚开始时间都计算出来，然后取较小的那个，从J到I的最晚开始时间是 48-12=36，从 H到I的最晚开始时间是 48-10-1=37，因此I的最晚开始时间是 36，否则就会影响整个项目的工期。

要求活动的松弛时间，就要求出活动的最早开始时间和最晚开始时间，其最晚开始时间减去最早开始时间，就是活动的松弛时间。对于活动FG，其最早开始时间是10+8=18，最晚开始时间是48-7-3=38，因此该活动的松弛时间是20。