河北工业大学软件工程期末复习.docx

河北工业大学软件工程期末复习.docx

《河北工业大学软件工程期末复习.docx》由会员分享，可在线阅读，更多相关《河北工业大学软件工程期末复习.docx（16页珍藏版）》请在冰豆网上搜索。

软件工程期末复习总结

第一讲概述（选择U填空U简答）

1.1软件工程的研究内容

软件工程要考虑专业软件开发所需要的理论、方法和工具----工程技术问题

软件工程要考虑如何有效的在软件开发中利用有限的成本资源----工程管理的问题

1.2什么是软件?

软件包括：

---软件的内涵

①能够提供客户所需功能与性能的计算机程序；

②使程序能够适当的操作信息的数据结构；

③用以描述程序开发过程及使用的文档。

软件产品可以为一个特定的用户设计开发，也可以为某一类通用的市场设计开发。

软件产品可以分成：

一个新的软件并不一定是全新开发，可以由现有软件或可复用软件成分配置形成。

1.3什么是软件工程？

软件工程是涉及软件生产各个方面的一门工程学科

软件工程涉及软件生命周期的各个方面，从软件需求的确定到软件退役。

软件工程：

（1）将系统化的、规范的、可度量的方法应用于软件的开发、运行和维护的过程，即将工程化应用于软件；

（2）研究

（1）中的方法.

——IEEE[IEE93]

1.4什么是成功的软件项目

一个成功软件项目的三个要素包括：

按时交付不超预算满足用户要求。

1.5软件过程与软件生命周期的相关概念

软件过程是指开发或制作软件产品的一系列活动及其成果.

所有的软件过程中都包括四个基本活动:

（填空）

1.描述（Specification）-系统应该提供的功能及其开发约束；

2.开发（Development）-软件产品的生产过程；

3.有效性验证（Validation）-检验软件产品是否满足了客户的需要；

4.进化（Evolution）-按照用户的变更要求不断的改进软件。

软件生命周期是软件过程的另一种形象描述，通常包括需求定义、分析与描述、软件设计、实现、测试、维护与退役等活动。

1.6什么是优良软件的属性？

P8（填空U选择）

优良的软件应能交付相应的功能与性能，而且应具有良好的可维护性、可依赖性、有效性和可用性：

（选择题，考法内涵匹配）

可维护性（Maintainability）

Softwaremustevolvetomeetchangingneeds;

可依赖性（Dependability）

Softwaremustbetrustworthy;

有效性（Efficiency）

Softwareshouldnotmakewastefuluseofsystemresources;

可接受性（Acceptability）

Softwaremustbeacceptedbytheusersforwhichitwasdesigned.Thismeansitmustbeunderstandable,usableandcompatiblewithothersystems.

第二讲软件过程（画法+特点+结构+缺点+适用场合）

2.1瀑布模型（顺序模型）（特点:

变更少）（画法+特点+结构+缺点+适用场合）

1.需求分析和定义2.系统和软件设计3.实现和单元测试4.集成和系统测试5.运行和维护

（中文解释）

瀑布模型的缺点和适用情况

这种模型生硬的把一个软件过程划分成几个界限清晰的阶段，而且这些阶段前后有严格的顺序，这导致它很难对用户的需求变更做出及时的调整；

因此，瀑布模型只适合需求非常清楚和需求变更被严格限制的情况下。

实际的软件开发过程中，几乎没有多少业务系统具有稳定的需求。

瀑布模型反映了工程设计的基本思想。

2.2进化式开发模型（画法+特点+结构+缺点+适用场合）

基本思想：

通过开发系统原型和用户反复交互，以明确需求，使系统在不断调整与修改中得以进化成熟。

又叫做原型式开发方法。

两种基本类型：

探索式开发;

抛弃式原型法.

2.2进化式开发模型

问题

缺乏过程可见性;

系统结构通常会很差;

需要一些特别的技术（如原型快速开发技术），通常与主流技术不兼容.

适用情况

适合中小规模的交互系统;

可用于大型系统的局部开发（如系统界面），可以和瀑布模型混合使用；

生命周期较短的系统

2.3基于过程反复的过程模型

对于大型项目而言，系统需求的变更是无法避免的，因此开发过程的反复是软件开发的必要手段；

过程反复可以和任何一种一般过程模型结合使用。

两种支持过程反复的过程模型：

增量式开发；

螺旋式开发。

2.3增量式开发

增量式开发的特点

在这种开发方式中，系统不是作为一个整体交付，而是被分解成若干个增量，每个增量交付系统的部分功能。

用户的需求按优先级排队，优先级最高的需求被放入最早交付的增量中。

这样，优先级最高的系统功能就得到最多的测试，系统的可靠性较高。

由于每个增量可以交付部分系统功能，因此软件可以较早的交付用户使用（部分功能）；

早期交付的增量可以作为后期增量的原型帮助后期需求的确定；

项目总体的失败率较低；

优先级最高的系统功能得到最多的测试。

螺旋式开发

这种模型用螺旋线表示软件过程，而不是采用一系列活动及活动间的反馈；

螺旋中的每个回路表示软件过程中的一个阶段；

这种模型充分考虑了软件开发所面临的风险，并贯穿软件过程始终。

螺旋线划分成四部分

目标设置、风险评估和规避、开发与有效性验证、规划

2.4基于构件的软件工程

软件复用是指在两次或多次不同的软件开发过程中重复使用相同或相似软件元素（通常称为可复用构件、组件或软部件）的过程。

软构件是标准的、可以互换的、经过装配可随时使用的软件模块。

在UML中，软构件被定义为系统中某一定型化的、可配置的和可替换的部件，该部件封装了实现并暴露一系列的接口。

软件复用的意义

软件复用的出发点是使软件系统的开发不再“一切从零开始”，能够充分利用已有的知识和经验。

软件复用能够在软件开发中避免重复劳动，充分利用已有的开发成果，，提高开发效率，降低开发成本。

软件复用还可以避免全新开发可能引入的错误，从而提高软件的开发质量。

构件的基本概念

构件是为组装服务的！

软件构件是指可以独立生产、获取和部署的、可以被组装到一个功能性系统中去的可执行单元。

软构件是标准的、可以互换的、经过装配可随时使用的软件模块。

基于构件的软件工程

第三讲需求工程（概念+综合分析（面向对象建模UML+分析））

3.1需求工程过程

需求工程过程并不具有唯一的模型，在所有的过程中都会涉及一些共同的活动，

它们是：

可行性研究（必不可少）；需求导出与分析；需求描述；需求有效性验证;需求管理。

（填空U选择）

3.2可行性研究

可行性研究要决定被提议的系统是否值得去做。

进行可行性研究包括信息评估、信息汇总和书写报告三部分工作。

3.3需求的两个不同层次的描述

用户需求

从客户的角度，采用自然语言配合以图表对目标系统应提供的服务以及系统操作要受到的约束进行的声明。

系统需求

系统需求是一种结构化文档，要运用一些专业的模型详细的描述系统的功能及其约束。

系统需求文档有时也称为功能描述，应该是精确的，它可以成为双方之间合同的重要内容，同时作为开发工作的依据

3.4功能需求与非功能需求

功能需求

对系统应提供的功能，系统在特定的输入下做出的反应及特定条件下的行为的描述。

某些情况下还要包括系统不应做什么。

非功能需求（全局的）

对系统提供服务或功能时收到的约束进行描述。

如时间约束、开发过程约束和标准等。

领域需求

这种需求来自于系统的应用领域，反映领域特征。

可能是功能需求也可能是非功能需求。

功能性需求与非功能性需求相比较，非功能需求往往更为关键，因为非功能需求表示的是系统的整体特征，而功能性需求描述的则是局部功能。

（参看课本例子加强理解）

功能需求

功能需求描述系统所应提供的功能或服务。

取决于待开发软件的类型、未来的用户以及开发的系统类型。

功能性的用户需求只需要对系统应提供的服务进行高层一般描述，对于系统需求，则应该详细的描述系统功能、输入输出及异常。

非功能性需求

非功能需求不直接和功能相关，但定义了实现系统功能受到的约束与系统特性。

如可靠性、响应时间、存储空间、I/O设备能力等。

非功能需求还常与系统的开发过程有关，表现为过程需求。

如设计必须实用的特定CASE工具集、设计语言和开发方法。

领域需求

领域需求来自于应用领域，描述的是反映领域特点的系统特性与特征。

领域需求可能是新的功能需求，也可能是对现有需求的约束或定义一个特别的计算。

领域需求非常重要，如果领域需求不能满足，可能会使整个系统无法运转。

需求的全面性和一致性

原则上，功能性需求描述应该具备全面性和一致性。

全面性：

包括了所有用户要求的服务。

一致性：

在系统服务的描述中没有冲突和矛盾

需求的两个不同层次的描述

用户需求：

用户需求是从用户角度来描述的系统功能需求与非功能需求，这样的描述可以使不具备专业技术知识的用户能够看明白。

用户需求使用任何人都看得懂的自然语言、图表和直观的图形来描述。

系统需求：

相对于用户需求，系统需求是对系统功能、服务及约束的更详尽的描述。

系统需求是系统实现的基本依据，会被写入合同中。

因此系统需求是一个完全的、一致的系统描述，是设计的起点。

系统需求可以用系统模型来定义与说明。

3.7需求导出与分析

这个阶段在可行性研究之后进行，通常与需求描述交叉进行。

需求导出的过程活动包括：

需求发现、需求的分类与组织、优先排序和冲突解决、需求文档化。

需求的发现与识别是整个过程中最为关键的活动，负责收集目标系统级现存系统的相关信息并从这些信息中提炼出用户需求和系统需求。

信息的来源包括已有的文件，系统的信息持有者（stakeholders）以及相近系统的规约描述。

需求要从多个视点进行分析

视点用来表述不同角度的需求来源（信息持有者、其它相关系统及领域）。

每一个视点代表系统需求的一个子集。

从多视点对系统进行分析是十分重要的，因为没有那一种单一的途径能够诠释整个系统需求

视点的类型：

交互者视点、间接视点、领域视点

3.8结构化分析（SA）建模（概念）

结构化分析方法是一种面向数据流的系统建模技术，它从数据加工的角度对系统进行规格描述；

SA帮助分析者理解系统的功能，并采用模型与用户进行交流；

不同的模型从不同的角度对系统进行描述。

结构化分析建模

结构化分析方法建立的分析模型结构如下图：

结构化分析模型的核心是数据词典，它描述了所有的在目标系统中使用的和生成的数据对象。

围绕着这个核心的有三种图：

实体—关系图（ERD）描述数据对象及数据对象之间的关系；数据流图（DFD）描述数据在系统中如何被传送或变换，以及描述如何对数据流进行变换的功能（子功能）；状态—迁移图（STD）描述系统对外部事件如何响应，如何动作。

因此，ERD用于数据建模，DFD用于功能建模，STD用于行为建模。

（考试用英文）

3.9UML与面向对象分析方法（分析+设计+面向对象建模）

3.9.1理解UML

UML是一种标准的图形化建模语言，它为不同领域的人们提供一种统一的交流标准，这种标准使得系统构造者能够用标准的、易于理解的方式建立能表达出他们想象力的系统蓝图，并使客户、分析员、设计人员、程序员和系统其它涉及者能够相互理解和达成一致，从而能够有效地共享和交流设计结果。

3.9.3需求导出工作流程

需求精化工作流程