软件工程课件2年下半年部分题目网工略过版

1、目 录第 1 章 软件工程基础知识11.11.21.31.4什么是软件？1软件及软件工程？1有哪些流行的软件工程方法学及其要素？1什么是软件生存周期？有哪些活动？11.4.1 问题定义-“要解决的问题是什么？”11.4.2 可行性分析和项目开发计划-“有行得通的解决方案吗？”11.4.3 需求分析和定义-“系统必须做什么？”11.4.4 概要设计-“概括地说，应该怎样做？”21.4.5 详细设计-“具体怎么样做？”21.4.6 编码-代码实现21.4.7 测 试21.4.8 运行维护2各活动阶段主要文档21.5.1 可行性分析和项目开发计划21.5.2 需求分析中的文档21.5.3 概要设计阶

2、段文档21.5.4 详细设计阶段21.5.5 编码21.5.6 测试31.5.7 系统测试阶段3有哪些主要生存期模型？31.6.1 瀑布模型(传统的软件周期模型)31.6.2 原型模型31.6.3 螺旋模型41.6.4 喷泉模型41.6.5 敏捷开发方法5软件过程基础知识71.7.1 软件过程71.7.2 评估工具7软件工程项目管理基本知识81.8.1 时间管理81.8.2 成本管理91.8.3 风险管理101.51.61.71.81.8.4组织管理111.9软件配置管理121.10 模块化基本知识121.10.1 模块特性131.10.2 模块与模块的耦合性（7 种）131.10.3 模块的

3、内聚性131.10.4 模块的深度、宽度、扇出与扇入141.10.5 模块作用域和域141.10.6 模块化基础知识小结141.11 什么是软件开发方法？有哪些主要方法？151.11.1 结构化方法学151.11.2 结构化设计161.11.3 详细设计阶段设计质量度量方法 McCabe（网工略过）171.11.4 Jackson 方法191.12 软件工具191.13 软件质量管理基础知识191.14 软件质量191.15 容错系统201.16 McCall 软件质量模型（网工略过）201.17 代码评审技术211.18 软件测试211.18.1 软件测试经过的步骤211.18.2 白盒测试

4、211.18.3 黑盒测试221.18.4 灰盒测试231.18.5 回归测试231.18.6 单元测试231.18.7 集成测试231.18.8 确认测试231.18.9 系统测试231.19 软件工程标准和软件文档241.20 软件维护241.20.1 软件维护类型241.20.2 软件的可维护性251.21. 25第1章软件工程基础知识1.1 什么是软件？1. 满足用户功能需求和性能需求的指令或计算机程序集合；2. 处理信息的数据结构；3. 描述程序功能以及程序如何操作和使用所要求的文档。以上三部分的组合了软件。1.2 软件及软件工程？软件是指在计算机软件的开发和维护过程中所遇到的一序列

5、严重问题，在 20 世纪 60 年代末全面爆发，1968 年，北大西洋公约组织提出使用工程的概念、原理、技术和方法来开发与维护软件，即以工程化的方式组织软件的开发。产生软件的可归结为两个重要的方面：软件生产本身存在的复杂性；软件开发所使用的方法和技术。注意：我们只能尽力减少软件的危害，不可能彻底消除软件，犹如人类的感冒，永远不可能彻底消除！1.3 有哪些流行的软件工程方法学及其要素？1. 使用最广泛的软件工程方法学是面向结构化方法学、迭代化方法学、面向对象方法学（上世纪 70-90 年代，流行面向结构化方法学，上世纪 90 年代到现在，流行面向对象方法学）。2. 要素：方法、工具和过程。1.4

6、 什么是软件生存周期？有哪些活动？软件生存周期指的是：一个软件从提出开发要求开始到软件废弃不用的整个过程。而个软件的活动从前往后依次是：问题定义、可行性分析和项目开发计划、需求分析和定义、软件设计（先后细分为：概要设计和详细设计）、编码、测试和运行维护。1.4.1 问题定义-“要解决的问题是什么？”通过对客户的，系统分析员扼要地写出关于问题性质、工程目标和工程规模的报告，经过讨论和必要的修改之后这份报告应该得到客户的确认。参与人：用户、系统分析员、项目。1.4.2 可行性分析和项目开发计划-“有行得通的解决方案吗？”用户、项目和系统分析师搞清楚系统要解决的问题是什么？以及从技术、等方面论证项目

7、开发可行性。1. 技术可行性：现有的技术是否能够有效地解决该问题？是否有多种不同的解决方案？现有的技术力量是否达到？2.何？3.可行性：所有可能的解决方案所需投入的成本能否超过它的开发成本？它的成本效益分析结果如何？投资回报率如可行性：该解决方案是否符合企业实际情况？是否符合员工利益？是否符合相关和行业规范？1.4.3 需求分析和定义-“系统必须做什么？”用户、项目求，从而确和系统分析师确必须做什么？但不关心具体怎么做？要确的功能、性能、数据、界面等要的逻辑模型，同时制定后期测试计划。1. 需求分析的任务 （2014 年上）以下关于文档的叙述中，不正确的是 (33) 。（33）A文档仅仅描述和

8、规定了软件的使用范围及相操作命令 B文档也是软件的一部分，没有文档的软件就不能称之为软件 C软件文档的编制在软件开发工作中占有突出的地位和相当大的工作量D高质量文档对于发挥软件的效益有着重要的意义(1) 确定软件系统的综合要求：界面要求，功能要求，性能要求，安全性、理要求，将来可能提出的要求。性、可靠性要求，系统运行要求，异常处(2)(3)(4)(5)分析系统的数据要求：数据元素、数据元间的逻辑关系、数据量和峰值等。常用的数据描述是实体-关系模型。导的逻辑模型：结构化分析方法中使用数据流图；面向对象分析方法中使用类模型(类图)修正项目开发计划：在明确了用户的真正需求后，可以更准确地估算软件的成

9、本和进度，从而修正项目开发计划如果必要，可个原型系统来获取用户真正的需求。2. 需求的分类(1)(2)(3)功能需求：所开发的软件必须具备什么样的功能。非功能需求：指必须具备的属性或品质，如可靠性、性能、相应时间、容错性和扩展性等。设计约束：也称为限制条件、补充规约，这通常是对解决方案的一些约束说明。1.4.4 概要设计-“概括地说，应该怎样做？”系统分析师和软件设计师在需求定义的基础上，把各功能需求转换成需要的体系结构，即划分模块、模块的层次、模块之间的调用关系以及各模块的功能，同时设计应用系统的总体数据结构和数据库结构。特例：进销存分为进、销、存三个模块。1.4.5 详细设计-“具体怎么样

10、做？”软件设计师和程序员对概要设计阶段得出的各功能模块进行详细描述成精确的、结构化的过程描述，即各个功能模块具体怎么实现，用相应的工具把模块的结构表示出来，但还未进行编码。1.4.6 编码-代码实现由程序员把详细设计阶段得出的各模块结构（图形）转变成计算机能识别的指令代码。1.4.7 测 试由另一部门（）的软件设计师或系统分析师花费最少的人力物力找出程序最多、最大的错误（bug）-“高产测试”,再高产的测试工作也只能发现大约 80%的软件问题，不可能 100%的发现。1.4.8 运行维护由用户和维护进行的软件生存周期中时间最长的阶段。1.5 各活动阶段主要文档1.5.1 可行性分析和项目开发计

11、划nn可性行项目开发计划1.5.2 需求分析中的文档nnnnn需求规格说明书 初步用户使用手册确认测试的测试计划修改完善的软件开发计划系统测试计划文档1.5.3 概要设计阶段文档nnnn概要设计说明书数据库说明书 用户手册修订的测试计划（测试的策略、方法、步骤）1.5.4 详细设计阶段n详细设计说明书1.5.5 编码n程序1.5.6 测试nn完善的测试计划书软件测试报告1.5.7 系统测试阶段n系统测试报告1.6 有哪些主要生存期模型？瀑布模型、原型开发模型（快速原型模型、演化模型、增量模型）、螺旋模型、喷泉模型、基于知识的模型和变化模型。1.6.1 瀑布模型(传统的软件周期模型)瀑布模型严格

12、遵循软件生命周期各阶段的固定顺序：计划、分析、设计、编程、测试和维护，上一阶段完成后才能进入到下一阶段，整个模型就像一个飞流直下的瀑布，如图 1.1 所示。图 1.1 瀑布模型采用规范的方法，严格规定了各阶段必须提交的文档；要求每一阶段结束后，都要优点：以文档作为驱动，强迫开发进行严格的评审。与它最相适应的开发方法是结构化方法。缺点：不适应用户需求的改动。1.6.2 原型模型1. 快速原型模型快速原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。主要用于需求分析阶段。不追求也不可能要求对需求的严格定义，而是采用了动态定义需求的方法，所以不能定义完善的文档。特征：简化项目管理、尽快建

13、立初步需求、加强用户参与和决策。具有广泛技能水平的原型化是原型实施的重要保证。原型化应该是具有经验与、训练有素的专业。衡量原型化能力的重要标准是他是否能够从用户的模糊描述中快速获取需求。2. 演化模型在快速原型模型中，原型的用途是获知用户的真正需求，一旦需求确定了，原型即被抛弃。而演化模型应用于整个软件开发过程，是从初始模型逐步演化为最终软件 的渐进过程。也就是说，快速原型模型是一种“抛弃式”的原型化方法，而演化模型则是一种“渐进式”的原型化方法。3. 增量模型(渐增式)增量模型主要用于设计阶段，把软件划分为一系列的增量构件，分别进行设计、编程、集成和测试。新的增量构件不得破坏已经开发出来的。

14、其示意图如图 1.2 所示。 (20014 年下)软件开发中的瀑布模型典型的刻画了软件生存周期的阶段划分，与其最相适应的软件开发方法是 (9) 。（9）A.构件化方法B.结构化方法C.面向对象方法D.快速原型法 (2005 年下)应该在 （7） 阶段制测试计划。（7）A. 需求分析 B. 概要设计 C. 详细设计 D. 系统测试 (2005 年下)（29）详细描述软件的功能、性能和用户界面，以使用户了解如何使用软件。（29）A.概要设计说明书 B.详细设计说明书 C.用户手册D.用户需求说明书图 1.2 增量模型4. 原型模型小结从下面的有关原型化方法的叙述中，选择出正确的叙述：(1)快速原型

15、方法是一种企图克服传统软件周期模型缺点的开发方法。(2)在用户的数据没有得到很好地组织和管理的时候，应该使用原型化方法。(3)在用户没有明确地肯定其需求的时候，应该使用原型化方法。(4)在用户不希望把的时间软件开发过程中的时候，应该使用原型化方法。(5)使用原型化方法时应该使用第三代编程语言。(6)原型化加强了开发过程中用户的参与和决策。(7)原型化方法大致可分为三类：抛弃式、演化式和递增式。(8)原型化方法大致可分为演化式和递增式。(9)采用原型化方法时，软件的开发成本较高。(10)采用原型化方法时，关键的因素是建立的速度，而不是运行的效率。1.6.3 螺旋模型如图 1.3 所示，螺旋模型综

16、合了瀑布模型和原型模型中的演化模型的优点，还增加了风险分析。螺旋线第一圈的开始点可能是一个概念项目。从第二圈开始，一个新命期结束。开发项目开始了，新的演化沿着螺旋线进行若干次迭代，一直转到软件生图 1.3 螺旋模型1.6.4 喷泉模型喷泉模型主要用于描述面向对象的开发过程。喷泉一词体现了面向对象开发过程的迭代和无间隙特征。迭代指的是开发活动常常需要重复多次，在不断的迭代中逐渐完善软件系统，无间歇性指在开发活动之间不存在明显的边界，叉、迭代地进行，如图 1.4 所示。各开发活动交图 1.4 喷泉模型1.6.5 敏捷开发方法1. 迭代软件开发技术Rational 统一开发流程 RUP(Ration

17、al Unified Process)是一个通用的软件流程框架，它是一个以架构为中心、用例驱动的迭代化软件开发流程。RUP 是从几千个软件项目的实践经验中总结出来的，对于实际的项目具有很强的指导意义，是软件开业事实上的行业标准。在 RUP 中，我们把软件开发生命周期划分为四个阶段，每个阶段的结束标志就是一个主要的里程碑（如下图所示）。图 1.5 RUP这四个阶段主要是为了达到以下阶段性的目标里程碑：nnnn先启(Inception)：确定项目开发的目标和范围精化(Elaboration)：确架构和明确需求构建(Construction)：实现剩余的系统功能化(Transition)：完成软件的

18、化工作，将系统移交给客户 （2005 年下）在个系统时，如果用户对系统的目标不是很清楚，难以定义需求，这时最好使用 （6） 。（6）A. 原型法B. 瀑布模型C. V-模型D. 螺旋模型 （2006 年上）渐增式开发方法有利于 (4) 。(4)A.获取软件需求 B.快速开发软件C.大型团队开发 D.商业软件开发 (2005 年下)在个系统时，如果用户对系统的目标不是很清楚，难以定义需求，这时最好使用 （6） 。（6）A. 原型法B. 瀑布模型C. V-模型D. 螺旋模型 (2006 年上)渐增式开发方法有利于 (4) 。(4)A.获取软件需求 B.快速开发软件 C.大型团队开发 D.商业软件开

19、发 (2006 年下)常见的软件开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。其中（5）模型适用于需求明确或很少变更的项目，（6）主要面向对象的软件开发过程。（5） A瀑布模型B.演化模型C. 螺旋模型D.喷泉模型（6） A瀑布模型B.演化模型C. 螺旋模型D.喷泉模型2. 极限编程（XP-网工略过）一种轻量(敏捷)、高效、低风险、柔性、可最大的不同在于：、科学而且充满乐趣的软件开发方法。与其他方法对比，1. 在更短的周期内，更早地提供具体、持续的反馈信息2. 迭代地进行计划编制，首先在最开始迅速生成一个总体计划，然后在整个项目开发过程中不断地发展3.依赖于自动测试程序来开发进度，并及早

20、地捕获缺陷4. 依赖于口头交流，测试和源程序5. 倡导持续的演化式的设计6. 依赖于开发团队内部的紧密协作7. 尽可能达到程序员短期利益和项目长期利益的平衡xp 由价值观、原则、实践和行为四个部分组成，它们彼此相互依赖、关联，并通过行为贯穿于整个生命周期。xp 的是其总结的四大价值观：、简单、反馈和勇气，它们是 xp 的基础，也是 xp 的。5 个原则：快速反馈、简单性假设、逐步修改、提倡更改和优质工作。在 xp 方法中，贯彻的是“小步快走”的开发原则，因此工作质量绝不可打折扣，通常采用测试先行的编码方式来提供支持。在 xp 中，集成了 12 个最佳实践：计划、小型发布、隐喻、简单设计、测试先

21、行、重构、结对编程、集体代码所有制、持续集成、每周工作 40 小时，现场客户，编码标准。3. 敏捷建模（Agile Ming）AM 是一种最近才出现的软件思想，一种轻方法论，XP 实践既给了 AM 灵感，也是 AM 的一种具体实现。其原则为：主张简单；拥抱变化；你的第二个目标是可持续性，简单的说，你在开发的时候，你要能想象到未来；递增的变化；令投资人的投资最大化；有目的的建模；多种模型；高质量的工作；快速反馈； 软件是项目的主要目标；轻装前进。AM 补充原则为：内容比表示更重要；三人行必有我师；了解你的模型；了解你的工具；局部调整；开放 (2008 年上)极限编程是一种轻量级软件开发方法，（2

22、9)的准则不是它强调的。(29)A.持续的交流和B.用最简单的设计 C.用测试驱动开发D.关注用户反馈 (2009 年下)极限编程（XP）由价值观、原则、实践和行为四个部分组成，其中价值观包括、简单性、（36）。(36)A.好的计划B.不断的发布C.反馈和勇气D.持续集成 （2006 年下）常见的软件开发模型有瀑布模型、演化模型、螺旋模型、喷泉模型等。其中（5）模型适用于需求明确或很少变更的项目，（6）主要面向对象的软件开发过程。（5） A瀑布模型B.演化模型C. 螺旋模型D.喷泉模型（6） A瀑布模型B.演化模型C. 螺旋模型D.喷泉模型 （2006 年下）统一过程（UP）的基本特征是“用例

23、驱动，以架构为中心的和受控的迭代式增量开发”。UP 将一个周期的开发过程化分为 4 个阶段，其中 (26)提交结果包含了系统架构。（26）A.先启阶段B.精化阶段C.构建阶段D.提交阶段 （2008 年下）RUP（Rational Unified Process）分为 4 个阶段，每个阶段结都有重要的里程碑， 其中生命周期架构是在 （18） 结的里程碑。（18）A.阶段B.精化阶段C.构建阶段D.移交阶段 （2014 年上）以下关于统一过程 UP 的叙述中，不正确的是 (29) 。（29）AUP 是以用例和风险为驱动，以架构为中心，迭代并且增量的开发过程BUP 定义了四个阶段，即起始、精化、构

24、建和确认阶段C每次迭代都包含计划、分析、设计、构造、集成、测试以及内部和外部发布D每个迭代有五个工作流（2014 年上）某公司要个软件，的某些需求是明确的，而某些需求则需要进一步细化。由于市场竞争的，需要尽快上市，则开发该软件最不适合采用 (30) 模型。（30）A瀑布B原型C增量D螺旋诚实的。4. 自适应软件开发（Adaptive Software Development）ASD 的是三个非线性的、重迭的开发阶段：猜测，合作与学习。5. 水晶方法体系（Crystal）水晶方法体系与 XP 一样，都有以人为中心的理念，但在实践上有所不同。水晶方法体系考虑到人们一般很难严格遵循一个纪律约束很强的

25、过程，认为每一种不同的项目都需要一套不同的策略、约定和方法论。因此，与 XP 的高度纪律性不同，水晶方法体系探索了用最少纪律约束而仍能的方法，从而在产出效率与易于上达到一种平衡。也就是说，虽然列不如XP 那样的产出效率，但会有的人能够接受并遵循它。：并列争球法：用迭代的方法，其中把每 30 天一次的迭代称为一个“冲刺”，并按需求的优先级来实现。多个自组织和自治小组并行地递增实现。协调是通过简短的日常会议来进行的。1.7 软件过程基础知识1.7.1 软件过程软件过程是指人们用于开发和维护软件及相关的一系列活动，包括软件工程过程和软件管理过程。1.7.2 评估工具1. 软件能力成熟度模型（Capa

26、bility Maturity M，CMM），CMM1.1 的 5 个等级（由低级到高级）：n初始级软件过程是无序的，有时甚至是的，对过程几乎没有定义，取决于个人努力，管理是反应式（消防式）的。n可重复级建立了基本的项目管理过程来跟踪费用、进度和功能特性。制定了必要的过程纪律，能重复早先类似应用项目取得的。n已定义级已将软件管理和工程两方面的过程文档化、标准化，并综该组织的标准化软件过程。所有项目均使用经标准、裁减的标准软件过程来开发和维护软件。n已管理级收集对软件过程和质量的详细度量，对软件过程和都有定量的理解与。n优化级加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能

27、持续不断地改进。巧记：初级程序员，可重复写程序，现已定义了管理策略来优化程序设计！2. 成立成熟度集成模型CMMI 的一种表述方式为连续表述，主要关注某特定域的过程改进和能力评估；另一种表述方式为阶段式，主要是衡量一个企业的成熟度，而不把单个过程是否完成作为重点。n阶段表述方式初始级、已管理级、量化管理级和优化级，这些等级要一级一级逐级进行，每个等级是下一个等级的基础，当前一个级别没有达到时，不能进入下一个等级。n连续表述方式分为 0-5 能力等级：未完成级，已执行级，已管理级，已定义级，量化管理级和优化级。 (2011 年上)关于过程改进，以下叙述中不正确的是 （30） 。（30）A. 软件

28、质量依赖于软件开发过程的质量，其中个人因素占主导作用B. 要使过程改进有效，需要制定过程改进目标C. 要使过程改进有效，需要进行培训 (2006 年下)软件能力成熟度模型（CMM）是目前国际上最流行、最实用的软件生产过程标准和软件企业成熟度的等级认证标准。该模型将软件能力成熟度自低到高依次划分为初始级、可重复级、已定义级、已管理级、优化级。从（17）开始，要求企业建立基本的项目管理过程的政策和管理规程，使项目管理过程有章可循。（17）A初始级 B. 可重复级 C. 已定义级 D. 已管理级 (2012 年下)敏捷开发方法中，(30)认为每一种不同的项目都需要一套不同的策略、约定和方法论。(30

29、) A极限编程(XP) B水晶法(Crystal) C并列争球法( Scrum) D自适应软件开发(ASD)1.8 软件工程项目管理基本知识软件项目管理开始于任何技术活动之前，并且贯穿于整个的软件生命周期。软件工程项目管理一般分为时间管理、成本管理、人力管理、风险管理。1.8.1 时间管理1. Gantt 图如图 1.6 所示，是一种简单的水平条形图，它以水平线段表示子任务的工作阶段，线段的起点和终点分别对应着子任务的起始时间，线段长度指示完成该任务所需要的时间。图 1.6、可从图上清楚地标出子任务间的时间对比，但它也有缺点：的优点：直观简明、易学(1)(2)(3)不能显示地描绘各项彼此间的依

30、赖关系；进度计划的关键部分不明显，难以哪些部分应当是主攻和主控的对象；计划中有潜力的部分以及潜力的大小不明确，往往造成潜力的浪费。2. PERT 网图与关键路径PERT 网图是一个由箭头（标识任务）和结点（标识图 1.7 所示。）组成的有向图。将网络方法用于工作计划安排的评审和检查，如图 1.7 任务网络图间和完成该任务所需的时间，还给出了任务之间的依赖关系，即哪些任务PERT 图不仅给出了每个任务的开始时间、结完成后才能开始另一些任务，以及如期完成整个工程的“关键路径”。关键路径（Critical Path）是由一连串的任务所组成的链，距离最大的一条路径。软件项目的管理应该密切注视关键任务的

31、进展情况。如果希望缩短工期，只有往关键任务中增加有效果。 （2006 年上）在软件项目管理中可以使用各种图形工具来辅助决策，下面对 Gantt 图的描述中，不正确的是 (5) 。A. Gantt 图表现了各个活动的持续时间B. Gantt 图表现了各个活动的起始时间C. Gantt 图反映了各个活动之间的依赖关系 D. Gantt 图表现了完成各个活动的进度D. CMMI 成熟度模型是一种过程改进模型，仅支持阶段性过程改进而不支持连续性过程改进1.8.2 成本管理1. 成本估算方法一种常用的成本估算方法是先估计完成软件项目所需的工作量（人月数），然后根据每个人月的代价（金额）计算机软件的开发费

32、用：开发费用 人月数×每个人月的代价另法是估计软件的规模（通常指源代码行数），然后根据每行源代码的平均开发费用（包括分析、设计、编码、测试所花的费用），计算机软件的开发费用：开发费用源代码行数×每行平均费用。估算源代码行数时，可以请n 为有经验的，每位对软件给出 3 个估计值：nnnai-最少源代码行数（该软件可能的最小规模） bi-最大源代码行数（该软件可能的最大规模）mi-最可能的代码行数（该软件最可能的规模）a + 4m + b的估算期 Ei = iii ，n 位n的估算期望值的平均值 1 å E 就是代码行数的估算值。然后计算出每位6in12. 成本估算模

33、型Putnam 模型和O 模型是常用的成本估算模型。(1) Putnam 模型：是一种动态多变量模型，它是假设在软件开发的整个生存期中工作量的分布。(2)O 模型：是结构性成本模型，是最精确、最易于使用的成本估算模型之一。该模型可以分为：1) 基本2) 中级O 模型，是一个静态单变量模型，它是对整个软件系统进行估算。O 模型，是一个静态多变量模型。它将软件系统模型分和部件两个层次，系统由部件，它把软件开发所需人力（成本）看作是程序大小和一系列“成本驱动属性”的函数。3) 详细O 模型，它将软件系统模型分、子系统和模块 3 个层次，它除包括中级模型所考虑的因素外，还考虑了在需求分析、软件设计等每

34、一步的成本驱动属性的影响。 （2010 年下半年）使用 PERT 图进行进度安排，不能清晰地描述（16） ，但可以给出哪些任务完成后才能开始另一些任务。下面 PERT 图所示工程从A 到中的关键路径是（17），（图中省略了任务的开始和结刻）。（16）A.每个任务从何时开始B.每个任务到何时结束C.各任务之间的并行情况D.各任务之间的依赖关系（17）A.ABEGHIKB.ABEGHJKC.ACEGHIKD.ACEGHJK （2010 年下半年）某软件项目的活动图如下所示。图中顶点表示项目里程碑，连接顶点的边表示包含的活动，则里程碑(16)在关键路径上，活动 FG 的松弛时间为 (17) 。(16

35、) ABBCCDDI(17) A19B20C21D24（2014 年上）以下关于进度管理工具 Gantt 图的叙述中，不正确的是 (18) 。（18）A能清晰地表达每个任务的开始时间、结间和持续时间 B能清晰地表达任务之间的并行关系C不能清晰地确定任务之间的依赖关系D能清晰地确定影响进度的关键任务1.8.3 风险管理1. 风险的定义n：风险是否会导致软件项目失败？n关心变化：在用户需求、开发技术、目标，以及所有其他与项目及时工作和全面完成有实体中会发生什么样的变化？n关心选择：应采用什么方法和工具，应配置多少人力，在质量上强调到什么程度才能满足要求？风险的特性：风险发生的概率和风险带来的损失。

36、2. 风险的类型(1) 项目风险：指潜在的预算、进度、人力(及组织)、客户和需求等方面的问题以及它们对软件项目的影响。例如：项目复杂性、规模和结构不确定性等都是项目风险、项目风险威胁到项目计划，即如果项目风险变成现实，有可能会拖延项目的进度，增加项目的成本。(2) 技术风险：指潜在的设计、实现、接口、验证和维护等方面的问题。此外，规约的二义性、技术的不正确性，陈旧的技术和“先进的”技术也是技术风险因素。技术风险威胁到开发软件的质量及软件交付时间，如果技术风险成现实，则开发工作可能变得很或根本不可能。(3)nnnnn商业风险：在信息系统项目业风险威胁到要开发系统的生存能力。一般主要有 5 类商业

37、风险：市场风险：开发了一个没有人真正需要的优秀或系统策略风险：开发的不再符合公司的整体商业策略销售风险：开发了一个销售部门不知道如何去卖的管理风险：由于重点的转移或的变动而失去了高级管理层的支持预算风险：没有得到预算或人力上的保证3. 风险管理活动(1) 风险识别试图系统化地确定对项目计划的威胁，风险识别的一个方法是建立风险条目检索表(文档化)；常见的已知的及可的风险有：规模、商业风险、客户特性、过程定义、开发环境、构建的技术、数目及经验等。(2) 风险：又称风险估算，通过对各种风险发生的可能性和破坏性这两个方面进行评估，并将它们按优先级别进行排列。在进行软件工程风险分析时，项目管理要进行四种

38、风险评估活动，包括建立表示风险概率的尺度，描述风险引起的后果，估计风险影响的大小，确定风险估计的正确性。(3) 风险评估：定义风险参照水准，成本、进度和性能就是三种典型的风险参照水准，即对于成本超支、进度延期、性能降低有一个表明导致项目终止的水准；风险评估的四个步骤：定义项目的风险参考水平值、建立每一组与每一个参考水平值之间的关系、一组临界点以定义项目终止区域，该区域由一条曲线或不确定区域所界定、水平值。(4) 风险什么样的风险组合会影响参考这步所有风险分析活动只有一个目的，即辅助项目建立处理风险的策略。一个有效的策略必须包含 3 个问题：1）风险避免；2）风险；3）风险管理及意外计划；如果软

39、件项目组对于风险采用主动的方法，则避免是最好的策略。4. 风险度风险度(risk exposure)=风险损失*风险概率例如：正在开发的软件项目可能存在一个未将发现的错误，这个错误出现的概率是 0.5%，给公司造成的损失将是 100 万元，那么这个错误的风险度是 5000 元。 （2012 年上半年）若软件项目组对风险采用主动的方法，则 (19) 是最好的风险策略。(19)A风险避免B风险C风险消除D风险管理及意外计划 （2012 年下半年）定义风险参照水准是 (19) 活动常用的技术。(19) A风险识别B风险C风险评估D风险（2014 年上）项目复杂性、规模和结构的不确定性属于 (19)

40、风险。 （2006 年上）使用 LOC (lines of code)度量软件规模的优点是 (9) 。(9)A.容易计算 B.与使用的编程语言相关 C.与使用的开发模型有关 D.在设计之前就可以计算出 LOC （2006 年上）软件项目开发成本的估算依据，通常是开发成本估算模型，常用的模型有：IBM 模型Putnam 模型基本O 模型中级O 模型高级 OCOMO 模型其中（18）都是静态单变量模型。（18）AB. C. D. （2014 年上） (17) 软件成本估算模型是一种静态单变量模型，用于对整个软件系统进行估算。（17）APutnamB基本OC中级OD详细O组织管理制程序员组1.8.4

41、1.是一种非正式的组织方式，小组成员完全平等，享有充分，小组成员通过协商作出技术决策，小组有高度的凝聚力，组内学术空气浓厚，有利于攻克技术难关。小组成员之间的通信是平行的，如果小组内有 n 个成员，则可能的通信信道是n(n-1)/2。适用于开发少（28 人），软件规模较小，每个开发技术水平都高的情况下。2.组在以下情况下，适用组的方式比较合适。nnn软件开发多数比较缺乏经验；程序设计过程中有许多事务性的工作，例如，大量信息的和更新；多通信很费时间，将降低程序员的生产率。图 1.8既懂管理，同时又是技术很很棒的组的结构。而后备程序员是和如图1.8 所示，水平相当，随时可替带主程序员工作的，编程负

42、责项目相全部事务性工作，如维护项目资料库和项目文档等。3. 现代程序员组在主程序组的基础上，取消的行政管理工作，让其单纯搞技术，负责技术工作方面的质量，而加进行政组长负责管理方面的工作。现代程序员组如图 1.9、图 1.10、图 1.11 所示。图 1.9 现代程序员组的结构（19）A项目B技术CD商业图 1.10 大型项目的技术管理组织结构图 1.11 包含分散决策的组织方式1.9 软件配置管理软件配置管理(Software Configure Management,SCM)用于整个软件工程过程。主要目标是标识变更； 正确地实现；报告有关变更。SCM 是一组管理整个软件生存期各阶段中变更的活

43、动。1. 基线变更；确保变更基线是软件生存期中各开发阶段的一个特定点，把各个开发阶段明确地，使本来连续的工作点在这些点上断开，以便检肯定阶段成果。基线可以作为一个检查点，在开发过程中，当采用的基线发生错误时，可以知道所处的位置，返回到最近获最恰当的基线上。2. 软件配置项软件配置项(Software Cinfigure Item,SCI)是软件工程中产生的信息项，是配置管理的基本象，并形成基线。，以下的 SCI 是SCM 的对系统规格说明书、软件项目实施计划、软件需求规格说明书、设计规格说明书(数据设计、体系结构设计、模块设计、接口设计、对象描述)、源代码管理，测试计划和过程、测试用例和测试结

44、果，操作和安装手册、可执行程序(可执行程序模块、连接模块)、数据库描述(模式和文件结果、初始内容)、用户手册、维护文档、软件工程标准、项目开发小结。3. 版本一些文档经过转换生成另外一些文档，并产生一些信息；另一文档又随时会有新的变更出现，形成新的版本。4. 变更变更是一项最重要的软件配置任务。为有效地实现变更，需借助于配置数据库和基线的概念。配置数据库分为以下三类：开发库、受控库、库。1.10 模块化基本知识模块是指执行某一特定任务的数据和可执行语句程序元素的集合，通常是指可通过名字来调用等。模块化就是将一个待开发的软件划分成若干个可完成某一子功能的模块，每个模块可的过程、函数、子程序或宏地

45、开发、测试，最后组装成 （2012 年上）(18) 最不适于采用无组的开发组织形式。(18)A项目开发人数少（如 3-4 人）的项目 B采用新技术的项目 C大规模项目 D确定性较小的项目完整的程序。有以下的模块类型：nnn传入模块：从下属模块取得数据，经过某些处理，再将其结果传送给模块；传出模块：从模块取得数据，经过某些处理，再将其结果传送给下属模块；变化模块：也叫模块。它从模块取得数据，进行特定的处理，转换成其他形式，再传回模块。它的数据流叫做变换数据流。n协调模块：对所有的下属模块进行协调和管理的模块。在系统的输入输出部分或数据部分可以找到这样的模块。在一个好的模块结构图中，协调模块应在较

46、出现。1.10.1 模块特性1. 可分解性如果一种设计方法提供了将问题分解成子问题的系统化机制，它就能降低整个系统的复杂性，从而实现一种有效的模块化解决方案。2. 可组装性如果一种设计方法使现存的（可复用的）设计构件能被组装成新系统，它就能提供一种不需要一切从头开始的模块化解决方案。3. 可理解性如果一个模块可以作为一个4. 连续性的（不用参考其他模块）被理解，那么它就易于构造和修改。如果对系统需求的微小修改只导致对单个模块，而不是整个系统的修改，则修改引起副作用就会被最小化。5. 保护性如果模块内部出现异常情况，并且它的影响限制在模块内部，注意“连续性”和“保护性”的区别！影响其他模块，则错

47、误引起的副作用就会被最小化。1.10.2 模块与模块的耦合性（7 种）耦合是对一个软件结构内不同模块之间互连程度的度量。耦合可以分成下列几种，它们之间的耦合度由高到低排列。1. 内容耦合直接操作或修改另一模块的数据，或不通过正常转入另一个模块。软件设计时应坚决2. 公共耦合内容耦合，应设计成单、单出口的模块，避免连接。多个模块同一全局数据区。例如，C 语言中的 external 数据类型、磁盘文件等都是全局数据区。3. 外部耦合模块与软件以外的环境有关联。例如，输入输出把一个模块与特定的设备、格式、通信协议耦合在一起。4.耦合一模块明显把开关量、名字等信息送入另一模块，5. 标记耦合另一模块的

48、功能。两个模块之间通过传递公共指针或地址相互作用的耦合。6. 数据耦合模块间通过传递信息。7. 非直接耦合（无耦合）模块间无任何关系，工作原则上讲，模块化设计总是希望模块之间的耦合表现为非直接耦合方式。在以上耦合中，耦合度从高到低，内容耦合度最高，非直接耦合度最低。总结：内公不好，家外被控了，标志数年心血了！（内功不好，家外被控了，标志数年心血白费了！）1.10.3 模块的内聚性内聚是指一个模块内各个元素彼此结合的紧密程度，它是信息隐蔽和局部的概念的自然扩展。设计时应该力求高内聚，理想内聚的模块应当恰好做一件事情。1. 偶然内聚：一个模块的各成分之间毫无关系。比如：一组语句在程序的多处出现，为

49、了节省内存空间，这些语句放在一个模块中，该模块的内聚是偶然内聚的。2. 逻辑内聚：把几种逻辑上相功能组放在同一模块中。3. 瞬时内聚（时间内聚）：一个模块所包含的任务必须在同一时间间隔内执行，例如初始化模块。4. 过程内聚：一个模块的处理元素是相，而且必须按特定的次序执行。5. 通信内聚：一个模块的所有成分都结合在同一个数据结构上。6. 顺序内聚：模块的成分同一个功能密切相关，且输出，作为另外一个成分的输入。7. 功能内聚：模块内的所有成分属于一个整体，完成单一的功能。在以上的内聚中，内聚度从低到高，偶然内聚度最低，功能内聚度最高。模块的高内聚、低耦合的原则称为模块也称为模块设计的原则。原则，

50、巧记：偶然逻辑，瞬间遗忘过程，打（通信）询问，顺序清楚，功能也搞定！1.10.4 模块的深度、宽度、扇出与扇入1. 深度：表示软件结构中的层数；2. 宽度：是软件结构中同一个层次上的模块总数的最大值；3. 扇入：一个模块的扇入是指直接调用该模块的模块的个数；4. 扇出：一个模块调用的下层模块个数。图 1.12 模块结构图如图 1.12 所示，模块M 的深度为 4，宽度为 4，扇出为 4；模块C 的扇出为 3，扇入为 1。注意：模块设计原则：低扇出、高扇入。1.10.5 模块作用域和域软件设计时，模块的作用域应在域之内。1.10.6 模块化基础知识小结1. 通过模块的合并和分解，降低模块的耦合度

51、。2. 模块的扇入应尽量大，扇出应尽量小。一个模块的扇入是指直接调用该模块的模块的个数。一个模块的扇出是指该模块直接调用的下级模块的个数。扇入大表示模块的重用性高，利用率高。扇出大表示模块的复杂度高。所以要高扇入，低扇出。3. 要将模块的作用范围限制在模块的范围之内。4. 降低模块之间的复杂性，避免“连接”。 （2006 年上）模块的耦合度描述了 (16) 。(16)A模块内各种元素结合的程度B模块内多个功能之间的接口C模块之间公共数据的数量D模块之间相互关联的程度 （2006 年上）内聚是一种指标，表示一个模块 (17) 。(17)A代码优化的程度B代码功能的集中程度C完成任务时及时程度D为

52、了与其他模块连接所要完成的工作量 （2012 年下）在软件设计阶段，划分模块的原则是：一个模块的(18)。(18)A作用范围应该在其范围之内 B范围应该在其作用范围之内C作用范围与范围互不包含D作用范围与范围不受任何限制（2014 年上）模块 A 提供某个班级某门课程的成绩给模块 B，模块 B 计算平均成绩、最高分和最低分，将计算结果返回1.11 什么是软件开发方法？有哪些主要方法？nn软件开发方法：使用已定义好的技术集及符号表示习惯组织软件生产的过程。结构化方法、面向对象方法、JACKSON 方法、维也纳开发方法（VDM）等。1.11.1 结构化方法学结构化方法学也称为生命周期方法学（瀑布模型方法），是一种面向数据流的需求分析方法。它的基本思想是自顶向下逐层分解。为了在需求改变时对软件的影响较小，结构化分析时应该使程序结构与问题结构相对应。常用工具： 数据流图（DFD）、数据字典（DD）、实例-关系图（E-R 图）及描述1. 数据流图(DFD 图)数据流图主要由 4 种成分组成，如表 1.1 所示：处理的结构化语言、判定表、判定树。表 1.1 数据流