1．     软件是⑴能够完成预定功能和性能的可执行指令⑵使得程序能够适当的操作信息的数据结构⑶描述程序的操作和使用的文档；软件的特点：⑴是逻辑产品，非物理产品⑵由开发或工程化而形成，无明显的制造过程⑶存在退化问题，必须维护软件。

2．     软件发展历史: 程序设计阶段 程序系统阶段 软件工程阶段 强大的桌面系统和计算机网络迅速发展的时期

3．     软件工程是研究和应用如何以系统化，规范化，可度量的方法去开发，运行和维护软件，即把工程化应用到软件中。

4．     衡量软件质量的主要特征有可维护性，可适用性，可使用性。

5．     软件工程的三要素:工具 方法 过程 还有一个质量焦点

6．     软件工程过程是进行一系列有组织的活动，从能够合理和及时的开发出软件。

7．     软件危机: 软件在开发和维护过程中遇到的一系列严重问题。软件危机包含两层含义：如何开发软件

如何维护数量不断膨胀的已有软件。表现：（1）软件开发的进度难以控制，经常出现经费超预算、完成期限一再拖延的现象。（2）软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果。（3）由于缺乏完整规范的资料，加之软件测试不充分，从而造成软件质量低下，运行中出现大量问题。（4）软件的可维护性差（5）软件文档资料不完整、不合格（6）软件价格昂贵，软件成本在计算机系统总成本中所占的比例逐年上升。原因：①用户对软件需求的描述不精确，可能有遗漏、有二义性、有错误，甚至在软件开发过程中，用户还提出修改软件功能、界面、支撑环境等方面的要求。②软件开发人员对用户需求的理解与用户的本来愿望有差异，这种差异必然导致开发出来的软件产品与用户要求不一致。③大型软件项目需要组织一定的人力共同完成，多数管理人员缺乏开发大型软件系统的经验，而多数软件开发人员又缺乏管理方面的经验。各类人员的信息交流不及时、不准确、有时还会产生误解。④软件项目开发人员不能有效地、独立自主地处理大型软件的全部关系和各个分支，因此容易产生疏漏和错误。⑤缺乏有力的方法和工具方面的支持，过分地依靠程序人员在软件开发过程中的技巧和创造性，加剧软件产品的个性化。⑥软件产品的特殊性和人智力的局限性，导致人们无力处理“复杂问题”。所谓“复杂问题”的概念是相对的，一旦人们采用先进的组织形式、开发方法和工具提高了软件的开发效率和能力，新的、更大的、更复杂的问题又摆在人们面前。

8．     软件工程学原则：抽象，信息隐藏，模块化，局部化，一致性，完整性和可验证性。

9．     软件生存周期阶段：可行性研究，需求分析，概要设计，详细设计，编码，测试，维护。

10．   软件开发模型：边做边改模型，瀑布模型，快速原型模型，增量模型，螺旋模型。

11．   瀑布模型：是将软件生存各个活动规定为依线性顺序联接的若干阶段的模型。它包括可行性分析、项目开发计划、需求分析、概要设计、详细设计、编码、测试和维护。它规定了由前至后，相互衔接的固定次序，如同瀑布流水，逐级下落。本质：工序线性化。

10     软件开发的基本策略：复用，分而治之，优化与折中。

11     可行性研究的任务：经济，技术，运行，法律和开发方案可行性。

1．     需求的概念：⑴用户解决问题或达到目标所需的条件或能力⑵系统或系统部件要满足合同，标准，规范或其他正式文档规定的条件和能力⑶一种满足⑴或⑵所描述的条件或能力的文档说明。

2．     数据字典是对系统所用到的所有数据项和结构的定义，以确保开发人员使用统一的数据定义。

3．     系统流程图：是描述物理系统的传统工具，它用图形符号来表示系统中的各个元素，例如人工处理、数据处理、数据库、文件、设备等。它表达了系统中各个元素之间的信息流动的情况。

4．     需求工程的基本活动：需求的获取，分析，传递，认可，进化。

5．     需求管理: 包括变更控制、版本控制和需求跟踪等活动

6．     需求层次:业务需求：描述了组织结构或客户对系统的高层次的目标要求。 用户需求：描述了用户使用产品必须要完成的任务，使用实例模型描述。 功能需求：定义了开发人员实现的软件的功能。 非功能需求：描述系统的约束和限制条件。

需求错误的原因：缺乏足够用户的参与、用户需求不断增加、需求模棱两可、添加不必要的特性、规格说明过于简单、忽略了用户分类

7．     结构化分析方法就是用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到找到满足功能要求的所有可实现的软件为止

8．     结构化程序设计的主要思想 :(1）自顶向下、逐步求精的程序设计方法（2）使用3种基本控制结构、单入口、单出口来构造程序。

9．     结构化分析过程是创建数据模型E-R图、功能模型DFD图和行为模型STD图的过程

10．   结构化分析方法使用工具: ERD STD 数据流图  数据词典 判定表与判定树、 结构化英语

11．   概要设计的任务：设计软件结构；设计数据结构和数据库；编写概要设计文档；评审；概要设计的说明书。

12．   软件设计原则: 抽象化 自顶向下，逐步细化 模块化 程序结构 结构划分 软件过程 信息隐蔽

13．   程序结构的深度：程序结构的层次数称为结构的深度。结构的深度在一定意义上反映了程序结构的规模和复杂程度

14．   程序结构的宽度：层次结构中同一层模块的最大模块个数称为结构的宽度。

15．   扇出表示一个模块直接调用（或控制）的其他模块数目。扇入则定义为调用（或控制）一个给定模块的模块个数。多扇出意味着需要控制和协调许多下属模块。而多扇入的模块通常是公用模块

16．   模块的独立性：指软件系统中每个模块只涉及具体的子功能，而和系统中其他模块的接口是简单的。

17．   模块的属性：功能，逻辑，状态。

18．   内聚分为：功能，信息，通信，过程，时间，逻辑和巧合内聚；耦合分为：非直接，数据，标记，控制，外部，公共和内容耦合。(都是高到低)

19．   变换型数据处理问题的工作过程大致分为三步，即取得数据，变换数据和给出数据。

20．   详细设计的任务：确定模块算法，选择适当工具表达算法；确定模块的数据结构；确定模块接口的细节；为模块设计测试用例。

21．   详细设计的描述工具:图形工具 表格工具 语言工具

22．   结构化程序设计采用自顶向下逐步求精的设计方法和单入口单出口的控制结构。

23．   测试分为：动态测试（黑盒，白盒）和静态测试（代码审查，静态分析）。

1．     黑盒测试(功能测试)方法：等价分类法，边界值分析，错误推测，因果图。

2．     白盒测试(结构测试)方法：语句，判定，条件，判定/条件，条件组合覆盖。点，边，路径覆盖。

3．     路径覆盖：指设计足够的测试用例，覆盖被测程序中所有可能的路径。

4．     判定/条件覆盖：指设计足够的测试用例，使得判定表达式中的每个条件的所有可能取值至少出现一次，并使每个判定表达式所有可能的结果也至少出现一次。

5．     条件组合覆盖：是指设计足够的测试用例，使的每个判定表达式中条件的各种可能的值的组合都至少出现一次，条件组合覆盖是比较强的覆盖标准。

6．     条件覆盖：是指设计足够的测试用例，使得判定表达式中每个条件的各种可能的值至少出现一次。满足条件覆盖并不一定满足判定覆盖。

7．     软件测试的目的：测试是为了发现程序中的错误而执行程序的过程；好的测试方案是极有可能发现迄今尚未发现的尽可能多的错误的测试；成功的测试是发现了迄今尚未发现的错误的测试。

8．     测试步骤：模块，系统集成和确认测试。

黑盒测试(功能测试)方法：等价分类法，边界值分析，错误推测，因果图。

软件测试的基本原则：1．应当把“尽早和不断的测试”作为开发者的座右铭2．程序员应该避免检查自己的程序，测试工作应该由独立的专业的软件测试机构来完成。3．设计测试用例时应该考虑到合法的输入和不合法的输入以及各种边界条件，特殊情况下要制造极端状态和意外状态，比如网络异常中断、电源断电等情况。4．一定要注意测试中的错误集中发生现象，这和程序员的编程水平和习惯有很大的关系。5．对测试错误结果一定要有一个确认的过程，一般有A测试出来的错误，一定要有一个B来确认，严重的错误可以召开评审会进行讨论和分析。6．制定严格的测试计划，并把测试时间安排的尽量宽松，不要希望在极短的时间内完成一个高水平的测试。7．回归测试的关联性一定要引起充分的注意，修改一个错误而引起更多的错误出现的现象并不少见。8．妥善保存一切测试过程文档，意义是不言而喻的，测试的重现性往往要靠测试文档。

v 软件开发过程是一个自顶向下，逐步细化的过程

v 软件计划阶段定义软件作用域

v 软件需求分析建立软件信息域、功能和性能需求、约束等

v 软件设计建立软件体系结构和模块实现的算法。

v 把设计用某种程序设计语言转换成程序代码

v 测试过程是依相反顺序安排的自底向上，逐步集成的过程。

v 软件开发过程是一个自顶向下，逐步细化的过程

v 软件计划阶段定义软件作用域

v 软件需求分析建立软件信息域、功能和性能需求、约束等

v 软件设计建立软件体系结构和模块实现的算法。

v 把设计用某种程序设计语言转换成程序代码

v 测试过程是依相反顺序安排的自底向上，逐步集成的过程。

9．     软件可靠性:程序在给定的时间间隔内,按照规格说明书的规定能成功运行的概率

10．   调试策略：跟踪法，演绎法，归纳法，试探法，回溯法和对分查找法。

11．   维护概念：为了改正错误或满足新需要而修改软件的过程。目的是满足用户对已开发产品的性能与运行环境不断提高的要求，延长软件寿命。分为：完善性，适应性，纠错性和预防性维护。

1．     影响可维护的因素：可理解性，可测试性，可修改性。

2．     维护的副作用：代码，数据和文档副作用。

3．     软件维护特点从三个方面理解：结构化维护和非结构化维护，维护的代价，维护的问题。

4．     面向对象方法是运用对象、类、继承、封装、聚合、消息传递、多态性等概念来构造系统软件开发方法。

5．     对象：是系统中用来描述客观事物的一个实体，是系统的基本单位，由属性和服务组成。

6．     类：是具有相同属性和服务的一组对象的集合。

7．     封装性:把对象的全部属性和全部服务结合在一起，形成一个不可分割的独立单位, 尽可能隐蔽对象的内部细节（信息隐蔽）

8．     多态性：指相同的操作或函数、过程可作用于多种类型的对象上并获得不同结果。不同的对象，收到同一消息可以产生不同的结果

9．     继承性是特殊类的对象拥有一般类的全部属性和服务,称作特殊类对一般类的继承

10．   消息:对象之间进行通信的构造

11．   面向对象的特点:建立的模型与客观世界一致便于理解；适应变化的需要修改局限在模块中；具有可复用性。

12．   重用：同一事物不经修改或稍加修改就可以多次重复使用的性质。

13．   可行性研究：按照各种有效的方法和工作程序对搭建工程项目在技术上的先进性，适应性，经济上的合理性，法律可行性是否有必要去解决，以及项目的实施等方面进行深入的系统分析。

14．   白盒测试：按照程序的内部逻辑结构，检验程序中的每条通路是否能够按照规格说明书上的规范正确工作，即把程序看成是装在一个透明的盒子里，完全了解程序的结构和处理过程，又称结构测试。

15．   视图:视图用来表示被建模系统的各个方面，视图由多个图构成，他不是一个图片，而是在某一个抽象层上对系统的抽象表示。如果要为系统建立一个完整的模型图，只需定义一定数量的视图，每个视图表示系统的一个特殊的方面。5种视图，用例视图：用于描述系统内部应该具有的功能集，它是系统的外部用户所能观察到的系统功能的模型图。逻辑视图：展示了系统内部如何提供系统的功能，它利用系统的静态结构和动态行为来刻画系统功能。构建视图：用来显示代码构件的组织方式，他描述了实现模块和他们之间的依赖关系。并发视图：用来显示系统的并发工作状况。部署视图：用来显示系统的物理架构，及系统的物理部署。UML中包含用例图，类图，对象图，状态图，顺序图，协作图，活动图，构件图，部署图共九种。用例图：系统的功能需求。类图：类与类之间的静态关系。对象图：类图的一个实例，反映系统执行到某处时系统的工作状况。状态图：类的所有对象可能具有的状态以及引起状态变化的事件。顺序图：反映若干个对象之间的动态协作关系，显示对象之间发送消息的顺序，对象之间的交互。协作图：动态协作，除了显示消息变化外，协作图还显示了对象和它们之间的关系（上下文有关）。活动图：一个连续的活动流。常用于描述某个操作执行时的活动状况。构件图：反映代码的物理结构。部署图用来显示系统中软件和硬件的物理架构。

16．   什么是软件的可维护性？软件的可维护性与哪些软件质量的特性有关？如何提高软件的可维护性？为什么在软件开发过程中，要特别重视软件的可维护性？

解：

① （2分）软件的可维护性指软件能够被理解、校正、适应及增加功能的容易程度。

② （2分）软件的可维护性与软件质量的下列特性有关：可理解性、可测试性、可修改性、可靠性、可移植性、可使用性和效率。

③（2分） 提高软件的可维护性方法有：

  要建立明确的软件质量目标：要程序满足可维护性的7个指标是不现实的，对于不同性质软件，质量重点不一样。强调哪个质量特性，视情况而定。

     要利用先进的软件开发技术和工具：能大大提高软件质量和减少软件费用。例如面向对象方法开发的软件系统，稳定性好，比较容易修改，比较容易理解，易于测试和调试，因此可维护性好。

  建立明确的质量保证：有4类检查（在检查点进行检查、验收检查、周期性的维护检查、对软件包的检查）。

选择可维护性语言：程序语言的选择对可维护性影响很大。

改进程序的文档：为提高可维护性，需要用户文档、操作文档、数据文档、程序文档和历史文档。

④（2分） 在软件开发过程中，要特别重视软件的可维护性的原因：

软件的可维护性是衡量软件质量的主要特性之一。

软件的可维护性是软件开发阶段的关键目标。

17．    

 

第二篇：软件工程期末重点知识总结

第一章 软件工程学概述

1.1软件危机

1.1.1软件危机的介绍

1.软件危机定义：软件危机是指在软件的开发和维护过程中，所遇到的一系列严重问题。

2.软件危机主要有以下一些典型表现（也是软件工程面临的问题）：

（1）对软件开发成本和进度的估计常常很不准确。

（2）用户对“已经完成的”软件系统不满意的现象经常发生。

（3）软件产品的质量往往靠不住。

（4）软件常常是不可维护的。

（5）软件通常没有适当的文档资料。

（6）软件成本在计算机系统总成本所占的比例逐年上升。

（7）软件开发生产率提高的速度，远远跟不上计算机应用迅速普及深入的趋势。

1.1.3消除软件危机的途径

1.软件是程序、数据及相关文档的完整集合。

其中，程序是能够完成预定功能和性能的可执行的指令序列；

      数据是使程序能够适当地处理信息的数据结构；

      文档是开发、使用和维护程序所需要的图文资料。

2.总之，为了解决软件危机，既要有技术措施（方法和工具），又要有必要的组织管理措施。

软件工程正是从管理和技术两方面研究如何更好的开发和维护计算机软件的一门新学科。

1.2软件工程

1.2.1软件工程的介绍

软件工程的定义：软件工程是指导计算机软件开发和维护的一门工程学科。

采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和

当前能够得到的最好的技术方法结合起来，以经济的开发出高质量的软件并有效地维护它，这就是软件工程。

1.2.2软件工程的基本原理（简答）

七条原理：他认为这7条原理是确保软件产品质量和开发效率的原理的最小集合。

这7条原理是互相独立的，其中任意6条原理的组合都不能代替另一条原理，因此，它们是缺一不可的最小集合。

软件工程的七条基本原理：

（1）用分阶段的生命周期计划严格管理。

（2）坚持进行阶段评审。

（3）实行严格的产品控制。

（4）采用现代程序设计技术。

（5）结果应能清楚地审查。

（6）开发小组的成员应该少而精。

（7）承认不断改进软件工程实践的必要性。

1.2.3软件工程方法学

1.软件工程包括技术和管理两方面的内容，是技术和管理紧密结合所形成的工程学科。

所谓管理就是通过计划、组织和控制等一系列活动，合理地配置和使用各种资源，以达到既定目标的过程。

2.软件工程方法学包含3个要素：方法、工具和过程。

其中，方法是完成软件开发的各项任务的技术方法，回答“怎么做”的问题；

工具是为运用方法而提供的自动的或半自动的软件工程支撑环境；

过程是为了获得高质量的软件所需要完成的一系列任务的框架，它规定了完成各项任务的工作步骤。

1.3软件生命周期

1.概括地说，软件生命周期由软件定义、软件开发和运行维护（也称软件维护）3个时期组成，

每个时期又进一步划分成若干个阶段。

2.软件定义时期的任务是：确定软件开发工程必须完成的总目标；确定工程的可行性；

导出实现工程目标应该采用的策略及系统必须完成的功能：估计完成该项工程需要的资源和成本，并且制定工程进度表。

软件定义时期通常进一步划分成3个阶段，即问题定义、可行性研究和需求分析。

3.开发时期具体设计和实现在前一时期定义的软件，它通常由下述4个阶段组成：总体设计，详细设计，编码和单元测试，综合测试。

其中前两个阶段又称为系统设计，后两个阶段又称为系统实现。

4.维护时期的主要任务是使软件持久的满足用户的需求。具体地说，当软件在使用过程中发现错误时应该加以改正；

当环境改变时，应该修改软件以适应新的环境；当用户有新要求时应该及时改进软件以满足用户的新需要。

通常对维护时期不在进一步的划分阶段，但是每一次维护活动本质上都是一次压缩和简化了的定义和开发过程。

5.软件生命周期每个阶段的基本任务（8个阶段）

（1）问题定义 （2）可行性研究 （3）需求分析 （4）总体设计

（5）详细设计  （6）编码和单元测试 （7）综合测试  （8）软件维护

1.4软件过程

1.4.1瀑布模型

特点：（1）阶段间具有顺序性和依赖性

（2）推迟实现的观点（3）质量保证的观点

优点：

（1)可强迫开发人员采用规范的方法

（2）严格的规定了每个阶段必须提交的文档

（3）要求每个阶段的所有产品都必须经过质量保证小组的仔细验证

缺点：

（1）无法解决软件需求不明确或不准确的问题

（2）可能导致最终开发的产品不能真正满足用户的需要

（3）瀑布模型比较适合开发需求明确的软件

1.4.2快速原型模型（过渡产品）

快速原型：是快速建立起来的可以在计算机上运行的程序，它所能完成的功能往往是最终产品能完成的功能的一个子集。

原型：是快速实现和运行的早期版本，反映最终系统部分重要特性。

优点：

（1)通常能反映用户真实需求；

（2）软件产品的开发基本上是线性顺序进行的。

1.4.4螺旋模型（改进了原型模型，在每个阶段都加入风险分析）

螺旋模型的基本思想是，使用原型及其他方法来尽量降低风险。

理解这种模型的一个简便方法，是把它看作在每个阶段之前都增加了风险分析过程的快速原型模型。

螺旋模型主要适用于内部开发的大规模软件项目。

1.4.5喷泉模型（P22）

第二章 可行性研究

2.1可行性研究的任务

1.可行性研究的目的不是解决问题，而是确定问题是否值得去解决。

2.可行性研究的基本内容

（1）技术可行性（2）经济可行性（3）操作可行性

2.2可行性研究过程

典型的可行性研究过程有下述一些步骤：

（1)复查系统规模和目标        （2）研究目前正在使用的系统

（3）导出新系统的高层逻辑模型 （4）进一步定义问题

（5）导出和评价供选择的解法   （6）推荐行动方针

（7）草拟开发计划             （8）书写文档提交审查

2.4数据流图

数据流图（DFD）是一种图形化技术，它描绘信息流和数据从输入移动到输出的过程中所经受的交换。

4个元素图形表示（P41）

2.5数据字典（理解）

数据字典是关于数据的信息的集合，也就是对数据流图中包含的所有元素的定义的集合。

任何字典最主要的用途都是供人查阅对不了解的条目的解释，数据字典的作用也正是在软件分析和设计的过程中给人

提供关于数据的描述信息。

数据流图和数据字典共同构成系统的逻辑模型，没有数据字典，数据流图就不严格，然而没有数据流图，

数据字典也难以发挥作用。只有数据流图和对数据流图中每个元素的精确定义放在一起，

才能共同构成系统的规格说明书。

第三章 需求分析

3.1需求分析的任务

3.1.1确定系统的综合要求

通常对软件系统有下述几方面的综合要求

（1）功能需求               （2）性能需求

（3）可靠性和可用性需求     （4）出错处理需求

（5）接口需求               （6）约束

（7）逆向需求               （8）将来可能提出的要求

3.3.2软件规格说明书的作用？（自己查）

（1）软件设计和实现的基础

（2）软件开发项目的规划、软件价格的估算等

（3）测试和用户验收软件系统的重要依据

（4）为软件维护提供重要的信息

例.下列叙述中，不属于软件需求规格说明书的作用的是__D____。

A. 便于用户、开发人员进行理解和交流

B. 反映出用户问题的结构，可以作为软件开发工作的基础和依据

C. 作为确认测试和验收的依据

D. 便于开发人员进行需求分析任何

3.8验证软件需求

3.8.1从哪些方面验证软件需求的正确性

1.一般说来，应该从下述4个方面进行验证。

（1）一致性：所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。

（2）完整性：需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。

（3）现实性：指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。

（4）有效性：必须证明需求是正确有效的，确实能解决用户面对的问题。

第五章 总体设计

5.1设计工程

1.总体设计过程通常由两个主要阶段组成：

（1）系统设计阶段，确定系统的具体实现方案（2）结构设计阶段：确定软件结构

2.典型的总体设计包括下属9个步骤：

（1）设想供选择的方案   （2）选取合理的方案

（3）推荐最佳方案       （4）功能分解

（5）设计软件结构       （6）设计数据库

（7）制定测试计划       （8）书写文档。

(应该完成的文档通常有下述几种：系统说明、用户手册、测试计划、详细的实现计划、数据库设计结构)           （9）审查和复查

5.2设计原理

5.2.1模块化（P94)

1.模块：是由边界元素限定的相邻程序元素的序列，而且有一个总体标示符代表它。

面向对象方法学中的对象是模块，对象内的方法也是模块。模块是构成程序的基本构件。

2.模块化：就是把程序划分成独立命名且可独立访问的模块，每个模块完成一个子功能，把这些模块集成起来构成一个整体，

可以完成指定的功能满足用户的需求。

5.2.4信息隐藏（隐蔽）和局部化

信息隐藏（隐蔽）：在设计和确定模块时，是的一个模块内包含的信息（过程和数据），

不允许其他不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。

局部化：将一些关系密切的软件元素物理的放得彼此靠近。

5.2.5模块独立

1.衡量模块独立性的两个准则：（1）耦合性（2）内聚性

2.耦合定义：耦合是对一个软件结构内不同模块之间互连程度的度量。

耦合强弱取决于模块间接口的反正程度，进入或访问一个模块的点，以及通过接口的数据。

3.耦合分类：

（1）无直接耦合：两个模块没有直接关系，模块独立性最强。

（2）数据耦合：一个模块访问另一个模块时，仅仅通过数据参数交换输入、输出信息。

    （数据耦合是低耦合）

（3）控制耦合：模块之间传递的是控制信息（尽管有时这种控制信息以数据的形式出现），如开关、

标志、名字等，控制被调用模块的内部逻辑。

（4）特征耦合：两个模块通过传递数据结构加以联系，或都与一个数据结构有关系，则称这两个模块间存在特征耦合。

可能出现的情况：当把整个数据结构作为参数传递时，被调用的模块虽然只需要使用其中的一部分数据元素，

但实际可以使用的数据多于它真正需要的数据，这将导致对数据访问失去控制。

（5）公共环境耦合：一组模块引用一个公用数据区（也称全局数据区，公共数据环境）

公共数据区指：全局数据结构、共享通讯区、内存公共覆盖区等。

（6）内容耦合：（是最不好的耦合形式）有下列情况之一的。

A.一个模块直接访问另一个模块的内部信息。

B.一个模块不通过正常入口转换到另一个模块内部。

C.两个模块有一部分代码重叠。

D.一个模块有多个入口模块。

（注：尽量使用数据耦合，少用控制耦合和特征耦合，限制公共环境耦合的范围，完全不用内容耦合。）

4.内聚定义：又称块内联系。指一个模块内部各个元素彼此结合的紧密程度的度量。

若一个模块内各元素联系的越紧密，则它的内聚性就越高。设计目标：高内聚。

5.内聚有哪些？（P99）

7种内聚及评分：功能内聚（10分）、顺序内聚（9分）、通信内聚（7分）、

过程内聚（5分）、时间内聚（3分）、逻辑内聚（1分）、偶然内聚（0分）

5.3启发规则（P100）

改进原则：高内聚、低耦合

启发性规则以下几条：

（1）改进软件结构，提高模块独立性

（2）模块规模应该适中（重点）

（3）深度、宽度、扇出和扇入都应适当（计算题）

（4）模块的作用域应该在控制域之内

（5）力争降低模块接口的复杂程度

（6）设计单入口单出口的模块

（7）模块功能应该可以预测

5.4描述软件结构的图形工具         5.4.2结构图（P103）

主要成分说明：

（1）一个方框代表一个模块，框内注明模块的名字或者主要功能。

（2）方框之间的箭头（或直线）表示模块的调用关系，表示前一模块对后一模块的调用。

（3）调用直线边的小箭头，表示调用时从一个模块传给另一个模块的数据，也指出了传送方向。

5.5面向数据流的设计方法（P104）

数据流可分为两种类型：（1）变换型数据流（2）事务性数据流

第六章 详细设计

6.1结构程序设计

1.什么是结构程序设计？

经典定义：如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，

而且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。

比较全面的定义：结构程序设计是尽可能少用GOTO语句的程序设计方法，最好仅仅在检测出错误时才使用

GOTO语句，而且一个总是使用前向的GOTO语句。

6.2人机界面设计（理解P119-P124）

6.3过程设计的工具（出大题）（结合课件）

1.要求:会画程序流程图、盒图、PAD图等图形工具。

2.表格工具

（1）判定表：能够清晰地表示复杂的条件组合和应做的动作之间的对应关系。

（2）判定树：是判定表的变种，它也能够清晰地表示复杂的条件组合和应做的动作之间的对应关系。

3.语言工具

过程设计语言（PDL)：也称伪码，是一种介于自然语言和形式化语言之间的语言，

用于描述功能模块的算法设计和处理细节的语言。

特点：易编写，易理解，容易转化成源程序。

6.4面向数据结构的设计方法

Jackson方法和Warnier方法。

6.4.1Jackson图（会画）（P133例题）

逻辑数据结构：顺序结构、选择结构、重复结构

Jackson图的优点：（1）形象直观可读性好 （2）既能表示数据结构也能表示程序结构

6.5程序复杂程度的定量度量

1.计算环形复杂度的3种方法

（1）数图上的区域个数（2）等于判定结点数+1（最优）（3）边数-结点数+2

2.环形复杂度的用途（P138）

第七章 实现

7.1编码/7.1.2编码风格（理解），重点看（P148/5.效果）

7.2软件测试基础

7.2.1软件测试的目标

Myers给出的软件测试的目的

（1）测试是为了发现程序中的错误而执行程序的过程。

（2）好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案。

（3）成功的测试是发现了至今为止尚未发现的错误的测试

总之，测试的目的是以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷；

测试附带的收获是它能证明软件的功能和性能与需求说明相符合。

说明：测试不能表明软件中不存在错误，它只能说明软件中存在错误。

7.2.3测试方法

软件测试方法一般分为：静态测试盒动态测试。

静态测试：是指被测程序不在机器上运行，采用人工测试和计算机辅助静态分析的手段对程序进行检测。

动态测试：是指通过运行程序发现错误，又分白盒测试和黑盒测试。

（1）已知产品应该具有的功能，可以通过“黑盒测试”来检验每个功能是否符合设计要求。

（2）已知产品的内在工作过程，可以通过“白盒测试”来检验每种内部操作是否按要求的规定正常进行。

7.3单元测试

7.3.1测试重点

单元测试方法有哪些？（5个）

（1）模块接口测试               （2）局部数据结构测试

（3）路径测试（重要的执行通路） （4）出错处理测试      （5）边界测试

7.3.2代码审查（属于静态测试）(P154)

7.4集成测试

7.4.4回归测试

回归测试定义：指集成测试中，重新执行已经做过测试的某个子集，

以保证上述这些变化没有带来非预期的副作用。

先采取自顶向下的方式测试被修改的模块及其子模块；然后将这一部分视为子系统，再自低向上测试。

7.5确认测试

1.确认测试的依据？

需求分析阶段产生的软件需求规格说明书，准确的描述了用户对软件的合理期望，

因此 是软件有效性的标准，也是进行确认测试的基础。

7.5.3 Alpha和Beta测试（适应：为多个用户开发的软件）

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

Beta测试：由最终用户在实际使用环境下进行的测试，这些用户定期返回有关错误信息给开发者。

注意：只有当Alpha测试达到一定的可靠程度时，才开始Beta测试。

7.6白盒测试技术

所谓测试方案包括具体的测试目的（例如，预定要测试的具体功能），应该输入的测试数据和预期的结果。

通常又把测试数据和预期的输出结果称为测试用例。

7.6.1逻辑覆盖

逻辑覆盖有几种（出题）

逻辑覆盖是以程序内部的逻辑结构为基础设计测试用例的技术。

包括：语句覆盖、判定覆盖、条件覆盖、判定-条件覆盖、条件组合覆盖、

点覆盖、边覆盖、路径覆盖

7.6.2控制结构测试

1.基本路径测试（P166例题）

以环形复杂度为基础，导出基本可执行路径集合，设计测试用例的方法。测试用例要保证程序的可执行语句执行一次。

使用基本路径测试技术设计测试用例的步骤：

（1)根据过程设计结果画出相应的流图。

（2）计算流图的环形复杂度。

（3）确定线性独立路径的基本集合。

（4）设计可强制执行基本集合中每条路径的测试用例。（包括路径1-6的测试用例）

7.7黑盒测试技术

7.7.1等价划分（P172）/7.7.2边界值分析（P175）

7.9软件可靠性

软件可靠性的定义：

程序在给定的时间间隔内，按照规格说明书的规定成功地运行的概率。

随着运行时间的增加，运行时出现程序故障的概率也将增加，即可靠性随着给定的时间间隔的加大而减少。

第八章 维护

软件维护需要的工作量很大，平均来说，大型软件的维护成本高达开发成本的四倍左右。

8.1软件维护的定义

软件维护的定义：就是在软件已经交付使用之后，为了改正错误或者满足新的需求而修改软件的过程。

分为4类：改正性维护、适应性维护、完善性维护、预防性维护。

各种维护类型及维护工作量的比例：

完善性维护（50%-66%）、改正性维护（17%-21%）、

适应性维护（18%-25%）、其他维护活动（4%左右)

8.4软件的可维护性

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

决定软件可维护性的因素：（5个）

（1）可理解性（2）可测试性（3）可修改性（4）可移植性（5）可重用性

8.4.2文档（包括系统文档和用户文档）

文档作用：文档是影响软件可维护性的决定因素。

用户文档：主要描述系统功能和使用方法，并不关心这些功能是怎样实现的。

系统文档：描述系统设计、实现和测试等各种方面的内容。

总体来说，软件文档应该满足下述要求：

（1）必须描述如何使用这个系统，没有这种描述时即使是最简单的系统也无法使用。

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

（3）必须描述系统需求和设计。

（4）必须描述系统的实现和测试，以便使系统成为可维护的。

第九章 面向对象方法学引论

9.2面向对象的概念

9.2.2其他概念

7.继承（P213）

单继承：一个类只允许有一个父类，即类等级为树形结构。

多继承：一个类允许有多个父类。

9.3面向对象建模

用面向对象方法开发软件，通常需要建立三种形式的模型，它们分别是：

描述系统数据结构的对象模型、描述系统控制结构的动态模型、描述系统功能的功能模型。

9.4对象模型

9.4.1类图的基本符号（P217）类图描述类及类与类之间的静态关系。

9.6功能模型

功能模型表示变化的系统的“功能”性质，它指明了系统应该“做什么”，

因此更直接的反映了用户对目标系统的需求。

使用“用例图”描述（P224)

9.3种模型之间的关系

3种模型分别是：对象模型、功能模型、动态模型

3种模型之间的关系：

（1）对象模型描述了动态模型、功能模型所操作的数据结构。

对象模型中的操作对应于动态模型中事件和功能中的函数。

（2）动态模型描述了实现的控制结构，告诉我们哪些结构是依赖于对象值，

哪些引起对象的变化，并激活了函数。

（3)功能模型由数据流图和用例图组成，描述了对象模型中操作的含义、

动态模型中动作的意义以及对象模型中的约束的意义 。

第十一章 面向对象设计

11.2启发规则

6个启发规则：

（1）设计结果应该清晰易懂。 （2）一般-特殊结构的深度应适当。

（3）设计简单的类。         （4）使用简单的协议。

（5）使用简单的服务。       （6）把设计变动减至最小。

11.3软件重用

11.3.1概述

1.重用的定义：

重用也叫再用或复用，是指同一事物不作修改或稍加改动就多次重复使用。

2.软件成分的重用级别

软件成分的重用可以进一步划分成3个级别,级别由低到高分别是：

（1）代码重用（2）设计结果重用（3）分析结果重用

第十二章 面向对象实现

12.2程序设计风格

12.2.1提高可重用性

提高可重用性的主要规则（7条）：

（1）提高方法的内聚         （2）减小方法的规模

（3）保持方法的一致性       （4）把策略与实现分开

（5）全面覆盖               （6）尽量不使用全局信息

（7）利用继承机制

第十三章 软件项目管理

13.3进度计划

13.3.2 Gantt图（Gantt图的优缺点）

优点：直观简明、容易掌握、容易绘制。

缺点：（1）不能显式地描绘各项作业彼此间的依赖关系。

（2）进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象。

（3）计划中有潜力的部分及潜力的大小不明确，往往造成潜力的浪费。

13.3.2工程网络（工程网络的优缺点）(P315）

工程网络是制定进度计划时另一种常用的图形工具，它同样能描绘任务分解情况以及

每项作业的开始时间和结束时间，此外，它还显式的描绘了各个作业彼此间的依赖关系。

因此，工程网络是系统分析和系统设计的强有力的工具。

13.4人员组织

人员组织的3种方式：

民主程序员组、主程序员组、现代程序员组

13.5质量保证

13.5.1软件质量

1.软件质量的定义：软件质量就是“软件与明确地和隐含地定义的需求相一致的程度”。

更具体的说，软件质量是软件与明确地叙述的功能和性能需求、文档中明确描述的开发标准

以及任何专业开发的软件产品都应该具有的隐含特征相一致的程度。

上述定义强调了下述的3个要点：

（1）软件需求是度量软件质量的基础，与需求不一致就是质量不高。

（2）指定的开发标准定义了一组指导软件开发的准则，如果没有遵守这些准则，

肯定会导致软件质量不高。

（标准有：国家标准、国际标准、行业标准、企业标准）

（3）通常，有一组没有显式描述的隐含需求（例如，软件应该是容易维护的）。

如果软件满足明确描述的需求，当却不满足隐含的需求，那么软件的质量仍然是值得怀疑的。

2.软件质量因素的定义（P325表）

13.5.2软件质量保证措施

软件质量保证措施主要有：

（1）基于非执行的测试（也称为复审或评审）

（2）基于执行的测试（即软件测试）

（3）程序正确性证明

1.技术复审的重要性（P326）

13.6软件配置管理

13.6.1软件配置

1.什么是软件配置？

简称SCM，是在软件生命周期内管理“变更”的一组活动。

这组活动使得因为“变更”而引起的混乱减到最小，最有效地提高生产率。

2.软件配置项：

软件过程的输出信息，包括3类：

（1）计算机程序（源代码和可执行程序）

（2)描述计算机程序的文档（供技术人员或用户使用）

（3）数据（程序内包含的或在程序外的）

3.基线（P329）

13.7能力成熟度模型（CMM）

能力成熟度的5个等级从低到高依次是：

初始级（又称为1级）

可重复级（又称为2级）

已定义级（又称为3级）

已管理级（又称为4级）

优化级（又称为5级）