导图社区 软件工程（总）
- 142
- 5
- 0
- 举报
软件工程（总）
这是一篇关于软件工程（总）的思维导图，主要内容有绪论、软件需求与软件需求规约、结构化方法、面向对象方法UML、面向对象方法RUP等。
编辑于2022-10-22 20:38:53 广东- 软件工程（总）
- 相似推荐
- 大纲
软件工程
绪论
软件危机
20世纪60年代以来，随着计算机的广泛应用，软件生产率、软件质量满足不了社会发展的需求，成为社会、经济发展的制约因素，人们通常把这些现象称为软件危机。
软件工程
软件工程概念的提出，其目的是倡导以工程的原理、原则和方法进行软件开发，以期解决出现的“软件危机”。
软件工程这一术语首次出现在1968年的NATO（北大西洋公约组织）会议上
定义：软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。
发展：
20世纪60年代末到80年代初
主要成果：提出瀑布模型、开发了诸多过程式语言（如C语言、Pascal语言）和开发方法（如Jackson方法、结构化方法）、开发了一些支持工具（调试工具、测试工具）等
特征：前期主要研究系统实现技术，后期开始关注软件质量和软件工程管理。
20世纪80年代以来
主要成果：提出《软件生存周期过程》、开展计算机辅助工程（CASE）、面向对象语言（如Smalltalk、C++）、提出面向对象软件开发方法等。
特征：开展了一系列有关软件生产技术，特别是软件复用技术和软件生产管理的研究和实践。
软件开发
计算机软件一般是指计算机系统中的程序及其文档。程序是对计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需的阐述性资料。
软件开发的目标是将问题域中的概念映射为运行平台层面上的概念，把问题域中的处理逻辑映射为运行平台层面上的处理逻辑；软件开发就是要弥补问题域与运行平台之间的距离，从而在二者之间直接进行映射。
软件开发的本质
概念：不同抽象层术语之间的“映射”，以及不同抽象层处理逻辑之间的“映射”，实现这一映射的基本途径：系统建模。
内容： 一是如何实现这样的映射，这是技术层面的问题。 二是如何管理这样的映射，以保障映射的有效性和正确性，这是管理层面的问题。
模型
概念：模型，简单地说，是待建系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节。 进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述。
分类：在软件开发中，软件系统模型大体上可分为两类：概念模型和软件模型。 （在软件开发领域，分层的基本动机是为了控制开发的复杂性。）
概念模型：在需求层上创建的系统概念模型是对客观事物系统的抽象，即标识要解决的问题，或称问题定义。
软件模型：设计模型、部署模型、实现模型
软件需求与软件需求规约
需求
定义：一个需求描述了待开发产品／系统功能上的能力、性能参数或其他性质
基本性质（5个）： · 必要的（Necessary）：该需求是用户所要求的； · 无歧义的（Unambiguous）：该需求只能用一种方式解释； · 可测的（Testable）：该需求是可进行测试的； · 可跟踪的（Traceable）：该需求可从一个开发阶段跟踪到另一个阶段； · 可测量的（Measurable）：该需求是可测量的。
分类
需求发现技术
自悟
需求人员把自己作为系统的最终用户，审视该系统并提出问题，“如果是我使用这一系统，则我需要…….”。
交谈
为确定系统应该提供的功能，需求人员通过提出问题/用户回答这一方式，直接询问用户需要的是一个什么样的系统。
观察
通过观察用户执行其现行的任务和过程，或通过观察他们如何操作与所期望的新系统有关的现有系统，了解系统运行的环境，特别是了解要建立的新系统与现存系统、过程以及工作方法间必须进行的交互。
小组会
举行客户和开发人员的联席会议，与客户组织的一些代表共同开发需求。
提炼
复审技术文档，并提取相关信息。
需求规约
定义：是一个软件产项／产品／系统所有需求陈述的正式文档，它表达了一个软件产品／系统的概念模型。
基本特性： （1）重要性和稳定性程度：按需求的重要性和稳定性对需求进行分级，如基本需求、可选需求和期望需求； （2）可修改的 ：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求； （3）完整的：没有被遗漏的需求； （4）一致的：不存在互斥的需求。
格式
需求规约的表达主要存在3种不同的风格： （1）非形式化的需求规约 以一种自然语言来表达需求规约，如同使用一种自然语言写了一篇文章。适用于规模比较小的、复杂程度不大高的小型软件项目，或在获取SRS（草案）时使用的。 （2）半形式化的需求规约 以半形式化符号体系（包括术语表、标准化的表达格式等）来表达需求规约；一些有能力的组织针对大型复杂项目，在开发需求文档时往往使用系统化的需求获取、分析技术和工具。 （3）形式化的需求规约 以一种基于良构数学概念的符号体系来编制需求规约，一般常伴有解释性注释的支持。主要针对质量（特别是安全性）要求比较高的软件产品/系统或其中某一部分。
需求规约的作用可概括为以下4点： ◆ 需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。 ◆ 对于项目的其余大多数工作，需求规约是一个管理控制点。 ◆ 对于产品／系统的设计，需求规约是一个正式的、受控的起始点。 ◆ 需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。
结构化方法
结构化需求分析
基本术语
数据流：在结构化分析方法中，数据流是数据的流动。
加工：加工是数据的变换单元，即它接受输入的数据，对其进行处理，并产生输出；在使用中，一般给出标识，且标识为动宾结构。
数据存储：在结构化分析方法中，数据存储是数据的静态结构。
数据源和数据潭： 数据源是数据流的起点；数据潭是数据流的归宿地。 数据流和数据潭是系统之外的实体，可以是人、物或者其他软件系统。
系统功能模型表示
需求分析的首要任务是建立系统功能模型；
结构化分析方法给出一种能表达功能模型的工具，即数据流图（Dataflow Diagram），简称DFD图。
DFD图是一种描述数据变换的图形化工具，是一种表达待建系统功能模型的工具。
建模过程（自顶向下，功能分解）
NO1.建立系统环境图，确定系统语境
NO.2 自顶向下，逐步求精，建立系统的层次数据流图
◼ 在顶层数据流图基础上，按功能分解的设计思想，进行“自顶向下，逐步求精”； ◼ 即对加工进行分解，自顶向下地画出各层数据流图，直到底层的加工足够简单，功 能清晰易懂，不必再继续分解为止，这样的加工称为“叶加工”。
由“父图”生成“子图”的步骤：
（1）将父图的每一加工按其功能分解为若干个子加工；
（2）将父图的输入、输出流分派到相关的子加工；
（3）在各加工之间建立合理的关联，必要时引入数据存储，使之形成一个有机的整体。
NO.3 定义数据字典
目标：定义数据流图包含的所有数据流和数据存储的数据结构，直到给出构成以上数据的各数据项的基本数据类型。
NO.4 描述加工
目标：给出每一加工的小说明；对DFD图中每一加工给出加工的输入数据和输出数据间的关系；即从外部来视察一个加工的逻辑。（3种表达工具→）
结构化自然语言
判定表
判定树
结构化设计
· 结构化设计的主要任务：在需求分析的基础上，定义满足需求所需要的结构，即针对给定的问题，给出该问题的软件解决方案，确定“怎么做”的问题。 · 为控制软件设计的复杂性，结构化设计进一步分为总体设计和详细设计！ · 总体设计将系统分解成一个个“黑盒子”，详细设计描述其细节。
总体设计
模块：软件中具有特定标识的独立成分；是执行一个特殊任务的一个过程以及相关的数据结构。
模块调用：模块之间的一种使用关系。
基本任务：把系统的功能需求分配到一个特定软件体系结构中，建立系统的模块结构，只声明其作用或功能。
总体设计工具
总体设计步骤
第一阶段：初始设计（将给定的数据流图转换为初始的模块结构图）
待建系统的DFD图可以分为：
变换型数据流图
事务型数据流图
第二阶段：精化设计（“高内聚低耦合”，精化模块结构图，设计数据结构和接口）
第三阶段：复审阶段（对高层软件结构进行复审，精化）
模块化
概念：即把一个待开发的软件分解成若干简单的、具有高内聚低耦合的模块的过程。
目标：基于模块“高内聚低耦合”的原则，提高模块独立性；衡量模块独立性的指标：耦合和内聚。
耦合：不同模块之间相互依赖程度的度量
内容耦合：一个模块直接修改或操作另一个模块的数据。 耦合程度最高，尽量避免使用。
公共耦合：两个或两个以上的模块共同引用一个全局数据项。
控制耦合：一个模块通过接口向另一个模块传递一个控制信号（如开关、标志），接收信号的模块根据信号值进行适当的动作。
标记耦合：模块A通过接口向两个模块B和C传递一个公共参数，称模块B和C间存在一个标记耦合。
数据耦合：模块之间通过参数来传递数据。 耦合程度最低，存在普遍。
内聚：一个模块内部各成分之间相互关联程度的度量
启发式规则
详细设计
目标：将总体设计阶段产生的系统高层结构映射为以这些术语所表达的低层结构，即系统的最终结构。
任务：具体描述模块结构图中的每一个模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精确地定义了满足需求规约的结构。
结构化程序设计
结构化程序设计方法是一种基于结构的编程方法，采用顺序结构、选择结构以及重复结构进行编程，每一结构只允许一个入口和一个出口。
详细设计工具
软件设计规约
面向对象方法UML
术语表
UML：一种图形化建模语言，给出表达客体、客体关系的术语以及表达模型的工具。
表达客观事物（8个术语）：
类和对象
类：一组具有相同属性、操作、关系和语义的对象的描述。 对象：类的一个实例。 类用于抽象客观世界中的事物，有一组属性和操作。
接口
接口是操作的一个集合，其中每个操作描述了类、构件或子系统的一个服务。
接口表示通常有两种形式： · 采用具有分栏和关键字《interface》的矩形符号来表示； · 采用小圆圈和半圆圈来表示。
协作
协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交互内容；交互各方之间的相互作用，提供了某种协作性行为。
用况
用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察到的结果。
主动类
主动类是一种至少具有一个进程或线程的类。
构件
构件是系统设计中的一种模块化部件，通过外部接口隐藏了它的内部实现。
制品
制品是系统中包含物理信息的、可替代的物理部件。
节点
节点是运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。
表达各类事物间的关系（4个术语）：
关联
关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述。 链是对象之间具有特定语义关系的抽象，实现之后的链通常称为对象之间的连接。 例子：{<张三，联想>，<李四，尚德>，<王五，百度>}
关联名
用于描述关联的一定“内涵”。
导航
对于一个给定的类目，可以找到与之关联的另一个类目，这称为导航。
角色
角色是关联一端的类目对另一端的类目的一种呈现。
可见性
多重性
类中对象参与一个关联的数目，称为该关联的多重性。
限定符
限定符是一个关联的属性或属性表，这些属性的值将与该关联相关类的对象集做了一个划分。
聚合
通过“一个类是另一类的一部分”这一性质，对关联集进行分类，凡满足这一性质的关联，都称为一个聚合。显然聚合是关联的一种特殊形式，表达的是一种“整体/部分”的关系。
组合
组合是聚合的一种特殊形式。 如果在一个时间段内，整体类的实例中至少包含一个部分类的实例，并且该整体类的实例负责创建和消除部分类的实例，那么这样的聚合称为组合。
关联类
关联类是一种具有关联和类特性的模型元素。一个关联类，可以被看做一个关联，但还有类的特性；或被看做一个类，但有关联的特性。
约束
· 有序(ordered)：表明类中实例是有序的。 · 无重复对象(set)：表明类中对象是没有重复的。 · 又重复对象(bag)：表明类中对象是有重复的。 · 有序集合(order)：表明类中对象有序且重复。 · 列表(list)或序列(sequence)：表明类中对象有序但可重复。 · 只读(readonly)：表明一旦一个链由于对象而被填加到所参与的关联中，即作为该关联的一个实例时，该链不能修改和删除。
泛化
泛化是一般性类目（称为超类或父类）和它的较为特殊性类目（称为子类）之间的一种关系，有时称为“is-a-kind-of”关系。
如果两个类具有泛化关系，那么 （1）子类可继承父类的属性和操作，并可有更多的属性和操作； （2）子类可以替换父类的声明； （3）若子类一个操作的实现覆盖了父类同一个操作的实现，这种情况被称为操作多态性，但两个操作必须具有相同的名字和参数； （4）可以在其他类目之间创建泛化，例如在节点之间、类和接口之间等。
为了进一步表达泛化的语义，UML给出了4个约束： （1）完整(Complete)：表明已经在模型中给出了泛化中的所有子类，尽管在表达的图形中有所省略，但也不允许增加新的子类。 （2）不完整(Incomplete)：表明在模型中没有给出泛化中的所有子类，因此可以增加新的子类。 （3）互斥(Disjoint)：表明父类的对象最多允许该泛化中的一个子类作为它的类型。 （4）重叠(Overlapping)：表明父类的对象可能具有该泛化中的多个子类作为它的类型。
细化
细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约。
依赖
依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务。 例如，一个类使用另一个类的操作，显然在这种情况下，如果被使用的类发生变化，那么另一个类的操作也会受到一定影响。
按照UML的观点，客观世界一切事物之间的关系都可以用依赖来规约。
UML的模型表达格式
类图
类图是可视化地表达系统静态结构模型的工具，通常包含类、接口、关联、泛化和依赖关系等。
创建类图的步骤： · 模型化待建系统中的概念，形成类图中的基本元素； · 模型化待建系统中的各种关系，形成该系统的初始类图； · 模型化系统中的协作，给出该系统的最终类图； · 模型化逻辑数据库模式。
用况图
用况图是一种表达系统功能模型的图形化工具。
一个用况图通常包含6个模型元素：主题（Subject）、用况（Use cases）、参与者（Actor）、关联、泛化、依赖。
用况图的作用： （1）可以为系统建模，描述软件系统行为的功能结构； （2）可以对业务建模，描述企业或组织的业务过程结构。 Tips: 业务模型和系统模型之间具有“整体/部分”关系，即业务模型是整体，而系统模型是业务模型的一个组成部分。
状态图
状态图是显示一个状态机的图，其中强调了从一个状态到另一状态的控制流。 · UML的图形化工具中，“可用于创建有关系统的行为生存周期模型，给出生存期内的阶段信息”的图。
一个状态机是一种行为，规约了一个对象在其生存期间因响应事件并作出响应而经历的状态。
子主题
状态：一个状态是类目的一个实例在其生存中的一种条件（condition)或情况 (situation)，期间该实例满足这一条件，执行某一活动或等待某一消息。 UML把状态分为3类，即初态（●）、终态（ ）和正常状态（圆角矩形）
事件：一个事件是对确定的时空内一个有意义发生的规约。在状态机的语境下， 一个事件就意味着存在一个可能引发状态转移的激励。
状态转移（→）是两个状态间的一种关系，意指一个对象在一个状态中将执行一些确定的动作，当规约的事件发生和规约的条件满足时，进入第二个状态。
顺序图
顺序图是一种交互图，即由一组对象以及按时序组织的对象之间的关系组成，其中还包含这些对象之间所发送的消息。
面向对象方法RUP
RUP（Rational Unified Process）的突出特点：以一种用况（Use Case）为驱动的、以体系结构为中心的迭代增量式开发。
核心工作流
RUP利用UML提供的术语和工具定义了需求获取层、系统分析层、设计层和实现层，并给出了实现各层模型之间映射的基本活动以及相关的指导。
需求获取
工具：采用Use Case技术获取需求。 目标：使用UML中的用况、参与者及依赖等术语抽象客观实际问题，形成系统的需求获取模型——一种特定的系统/产品模型，并产生该模型视角下的体系结构描述。
NO.1 列出候选的需求
先从客户、用户、计划者、开发者的想法和意愿中搜取特征，形成特征表。 特征是一个新的项（Item）及其简要描述。
NO.2 理解系统语境
（1）领域模型 一般用类图表达，用于捕获系统语境中的一些重要领域对象类。 领域类以的3种形态： ➢ 业务对象：表示那些由业务操纵的事物，如订单、账目和合同等。 ➢ 实在对象（Real-world Objects) ：如教室、运动场地等。 ➢ 事件（Events)：如上课铃响、讨论开始等。
（2）业务模型 · 为捕获业务处理和其中的业务对象，通过以下2个层次来抽象一个业务。业务用况模型：用用况图表达。 · 为精化业务用况模型中的每一个业务用况，表达业务对象的3个术语：工作人员、业务实体、工作单元。
NO.3 捕获系统功能需求
目标：创建系统的用况模型，以表达客户认可的需求——系统必须 满足的条件和能力，作为客户和开发人员间的一种共识。 用况模型：是系统的一种概念模型，是对系统功能的抽象，包括系 统参与者、系统用况以及它们之间的关系。
NO.4 捕获非功能需求
需求分析
目标：在系统用况模型的基础上，创建系统分析模型及在该分析模型视角下的体系结构描述。 分析模型：是系统的一种概念模型，解决系统用况模型中存在的二义性和不一致性等问题，以一种系统化的形式准确表达用户需求。
基本术语
分析类：类的一种衍型，很少有操作和特征标记，用责任定义其行为，其属性和关系也是概念性的。
用况细化：一个协作。针对一个用况，其行为用多个分析类间相互作用来细化，记为用况细化[分析]。
分析包：一种控制信息组织复杂性的机制，提供分析制品的一种组织手段，形成可管理的部分。 特征： · 体现问题分离； · 高内聚、低耦合； · 尽可能体现一个系统的完整顶层设计。
分析模型的表达
◆ 分析模型由“分析系统”定义，该分析系统包含一组具有层次结构的包，每个包中可包含一些分析类和用况细化[分析]； ◆ 分析类和用况细化[分析]可单独出现在分析模型中，以凸显其在系统体系结构方面的作用。
分析的主要活动
创建系统的分析模型，一般应进行4项活动：体系结构分析、用况分析、类的分析、包的分析。
分析模型对以后工作的影响 ➢ 对设计中子系统的影响。 ➢ 对设计类的影响。 ➢ 对用况细化[设计]的影响。
设计
目标：定义满足系统/产品分析模型所规约需求的软件结构。
术语
设计类（Design Class）：对系统实现中一个类或类似构造的一个无缝抽象。
用况细化[设计]：设计模型中的一个协作，使用设计类及其对象，描述一个特定用况是如何细化、执行的。表达协作的工具：类图、交互图和正文事件流等。
设计子系统：包含设计类、用况细化、接口，及其他子系统， 通过对其操作来显示功能。
接口（Interface）：用于规约由设计类和设计子系统提供的操作；为设计类/设计子系统提供一种分离功能的手段；一个接口的重要关联是细化。
设计模型及其视角下的体系结构描述： RUP设计主要结果是系统设计模型，它尽量保持该系统具有分析模型结构，并作为系统实现的输入。 设计模型包括以下元素： ◆ 设计子系统和服务子系统，及其依赖、接口和内容。 ◆ 设计类，及其具有的操作、属性、关系、实现需求。 ◆ 用况细化[设计]，描述了用况的设计。 ◆ 体系结构描述。
主要活动
实现和测试
测试
目标：首要目标：预防错误（几乎不可实现）；第二目标：发现错误
软件测试过程模型：软件测试是一个有程序的过程，包括测试设计、测试执行、测试结果比较等。
软件测试技术
路径测试技术
控制流程图
测试策略
基于事务流的测试技术
其他功能测试技术
等价类划分
边界值分析
因果图
软件测试步骤
单元测试
集合测试
有效性测试
系统测试
软件生命周期过程与管理
引言
过程描述
软件生存周期模型
瀑布模型
增量模型
演化模型
螺旋模型
喷泉模型
过程规划与管理
过程建立
软件生存周期过程的监控
集成化能力成熟度模型CMMI
CMMI的等级
能力等级
成熟度等级
简答题
简述软件工程与软件危机的概念以及提出软件工程概念的目的。
简述软件开发的本质及其涉及到的问题。
简述何谓系统模型以及软件开发中所涉及的系统模型分类。
-模型是待建系统的任意抽象；（1分） -该抽象是在特定意图下所确定的角度和抽象层次对物理系统的一个描述。（1分） -描述其中的成分和成分之间所具有的特定语义的关系，还包括对该系统边界的描述；（1分） -两类：概念模型和软件模型。软件模型又可进一步分为设计模型、实现模型和部署模型。（2分）
简述初始发现需求的常用技术。
· 自悟：需求人员把自己作为系统的最终用户，审视该系统并提出问题；（1分） · 交谈：为了确定系统应该提供的功能，需求人员通过问答方式，直接询问用户需要的是一个什么样的系统；（2分） · 观察：通过观察用户执行其现行的任务和过程，了解系统运行的环境；（0.5分） 特别是了解要建立的新系统与现存系统、过程及工作方法间必须进行的交互；（0.5分） · 小组会：举行客户和开发人员的联席会议，与客户代表共同开发需求；（1分） · 提炼：复审技术文档，并提取相关的信息。（1分）
简述需求规约的概念及其基本性质。
简述需求规约在项目开发中的基本作用。
简述结构化分析建模的基本步骤。
➢ 建立系统环境图，确定系统语境；（1分） ➢ 自顶向下，逐步求精，建立系统的层次数据流图；（2分） ➢ 定义数据字典；（1分） ➢ 过结构化自然语言、判定树判定表等工具，来描述加工。（1分）
简述事务设计的基本步骤。
简述结构化方法详细设计的任务及目标。
➢ 任务：具体描述模块结构图中的每一个模块，即给出实现模块功能的实施机制，包括一组例程和数据结构，从而精确地定义了满足需求规约的结构。（3分） ➢ 目标：将总体设计阶段所产生的系统高层结构映射为以这些术语所表达的低层结构，也是系统的最终结构。（2分）
简述泛化的概念及其约束。
泛化是一般性类目（称为超类或父类）和它的较为特殊性类目（称为子类）之间的一种关系，有时称为“is-a-kind-of”关系。 UML给出以下四个约束：完整、不完整、互斥、重叠。
简述关联、泛化、细化和依赖的概念以及前三者与依赖的关系。
· 关联是类目之间的一种结构关系，是对一组具有相同结构、相同链的描述。 · 泛化是一般性类目（父类）和它的较为特殊性类目（子类）之间的一种关系，有时称为“is-a-kind-of”关系。 · 细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约。 · 依赖是一种使用关系，用于描述一个类目使用另一类目的信息和服务。 · 关联、泛化、细化都是一类特定的依赖。
简用况图及其通常包含的模型元素。
用况图是一种表达系统功能模型的图形化工具。一个用况图通常包含6个模型元素： 主题（Subject）、用况（Use cases）、参与者（Actor）、关联、泛化、依赖。
简述RUP中分析模型的表达及其创建所进行的主要活动。
在RUP中，一个系统的分析模型是由一个“分析系统”定义的，该分析系统包含一组具有层次结构的包；（1分） 每一个包中可包含一些分析类和用况细化[分析]；（1分） 并且一些分析类和用况细化[分析]还可单独地出现在分析模型中，以凸显它们在系统体系结构方面的作用。（1分） 创建系统分析模型，应进行体系结构分析、用况分析、类的分析及包的分析4项活动。（2分）
简述RUP设计模型以及包含的元素。
RUP设计主要结果是系统的设计模型，它尽量保持该系统具有分析模型结构，并作为系统实现的输入。（1分） 设计模型包括以下元素： （1）设计子系统和服务子系统，以及它们的依赖、接口和内容。（1分） （2）设计类，以及它们具有的操作、属性、关系及其实现需求。（1分） （3）用况细化[设计]。（1分） （4）体系结构描述。（1分）
简述验证和确认的定义、作用和区别。
验证是通过提供的客观证据，证实规约的需求是否得以满足。（1分） 确认是通过提供的客观证据，证实有关特定期望的使用或应用需求是否得以满足。（1分） 验证的作用是证实一个过程或项目的每一软件工作产品/服务是否正确反映所规约的需求。（1分） 确认的作用是证实所期望使用的软件工作产品是否满足其需求。（1分） 验证是把在生存期上下文中的一个产品与该产品所要求的特征进行比较的活动。（0.5分） 确认是反映特定期望使用的特殊需求，是否满足其期望的使用。（0.5分）
简述CMMI提出所基于的基本思想。
· 基于过程途径思想，通过过程把软件质量的3个支撑点：受训的人员、规程和方法、工具和设备进行集成。（2分） · CMMI紧紧围绕开发、维护和运行，把经过证明的最佳实践放在一个结构中。（1分） · 该结构有助于指导组织确定其过程的改善优先次序；（1分） · 有助于指导这些改善的实施，以提高其过程能力和成熟度，并且还支持其他领域能力成熟度模型的开发。（1分）
简述CMMI成熟度等级的概念、划分和组成。
· 成熟度等级是指达到预先定义的一组过程域所有目标的一种过程改善等级，意在改进组织的整体性能；（1分） · 1级—初始级、2级—已管理级、3级—已定义级、4级—已定量管理级、5级—持续优化级；（2分） · 成熟度等级是由预先定义的一组过程域集及其相关的一些专用实践和共用实践组成的。（2分）
简述CMMI模型支持的两种过程改善路径。
· 为了改善其开发过程和护过程的组织，CMMI提供了两种类型的等级。（1分） · 能力等级是一种过程改善路径，该路径可使组织针对单一过程域不断改善该过程域；（1分） · 成熟度等级也是一种过程改善路径，该路径可使组织通过关注一组过程域不断改善一组相关的过程域；（1分） · 这两种等级还可用于评定活动、估算，作为过程评估的结果；（1分） · 能力等级和成熟度等级，这两种等级描述了两种过程改善的演化路径。（1分）
软件工程
解答题
简述PDL的特点
（1）PDL也称为伪码，它是一种用正文形式表示数据和处理过程的设计工具。 （2）PDL借用某种结构化程序设计语言（如Pascal或）的关键字作为语法框架，用于定义控制结构和数据结构。 （3）PDL通常使用某种自然语言（如汉语或英语）的词汇，灵活自由地表示实际的操作和判定条件。 （4）PDL可以作为注释工具直接插在源程序中间。
简述状态图中的一个状态转换涉及的内容
（1）源状态：发生状态转移的那个状态。 （2）转移触发器：满足其监护条件，则使状态发生转移。 （3）监护条件：布尔表达式，表达式为真，则触发转移；表达式为假，则不发生转移。 （4）效应：一种可执行的行为。 （5）目标状态：转移完成后所处的状态。
简述软件测试步骤中合理的软件测试序列及每个序列的关注点
（1）合理的测试序列：单元测试、集成测试、有效性测试和系统测试。 （2）单元测试关注每个独立的模块。 （3）集成测试关注模块的组装。 （4）有效性测试关注检验是否符合用户所见的文档。 （5）系统测试关注检验习题中所有元素之间的协作是否合适，整个系统的性能、功能是否达到。
简述项目规划包含的活动
（1）估算工作产品和任务。 （2）确定需要的资源。 （3）协商承诺。 （4）生成进度。 （5）标识并分析项目风险。