软件工程导论复习重点总结很全(第六版)(精)范文大全

第一篇：软件工程导论复习重点总结很全(第六版)(精)

第1章软件工程学概述 1.1 软件危机 1.1.1 软件危机的介绍

软件危机(软件萧条、软件困扰:是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。

软件危机包含下述两方面的问题: 如何开发软件,满足对软件日益增长的需求;如何维护数量不断膨胀的已有软件。软件危机的典型表现:(1对软件开发成本和进度的估计常常很不准确;(2用户对“已完成的”软件系统不满意的现象经常发生;(3软件产品的质量往往靠不住;(4软件常常是不可维护的;(5软件通常没有适当的文档资料;(6软件成本在计算机系统总成本中所占的比例逐年上升;(7软件开发生产率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。1.1.2 产生软件危机的原因(1与软件本身的特点有关

(2与软件开发与维护的方法不正确有关

1.1.3 消除软件危机的途径 对计算机软件有正确的认识。

认识到软件开发是一种组织良好、管理严密、各类人员协同配合、共同完成的工程项目。应该推广使用在实践中总结出来的开发软件的成功技术和方法,并继续研究探索。

应该开发和使用更好的软件工具。

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

1.2 1.2.1 软件工程的介绍

软件工程:是指导计算机软件开发和维护的一门工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来,以经济地开发出高质量的软件并有效地维护它,这就是软件工程。(期中考

软件工程的本质特性: 软件工程关注于大型程序的构造 软件工程的中心课题是控制复杂性 软件经常变化

开发软件的效率非常重要 和谐地合作是开发软件的关键 软件必须有效地支持它的用户

在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品

1.2.2 软件工程的基本原理 用分阶段的生命周期计划严格管理 坚持进行阶段评审 实行严格的产品控制 采用现代程序设计技术 结果应能清楚地审查 开发小组的人员应该少而精

承认不断改进软件工程实践的必要性 1.2.3 软件工程方法学

软件工程包括技术和管理两方面的内容。软件工程方法学3要素:方法、工具、过程

1.传统方法学(生命周期方法学或结构化范型——强调自顶向下 2.面向对象方法学——强调主动地多次反复迭代 面向对象方法学4个要点:对象、类、继承、消息 1.3 软件生命周期(必考

三个时期八个阶段:软件生命周期由软件定义、软件开发和运行维护(也称为软件维护三个时期组成,每个时期又进一步划分成若干个阶段。

三个时期:八个阶段: 软件生命周期软件定义 软件开发 软件维护 问题定义 可行性研究 需求分析 概要设计 详细设计 编码和单元测试 综合测试

运行维护 系统设计 系统实现 1.4 软件过程 1.4.1 瀑布模型

1.4.2 快速原型模型 1.4.3 增量模型 1.4.4 螺旋模型 1.4.5 喷泉模型 第2章可行性研究 2.1可行性研究的任务 可行性研究的目的: 不是解决问题,而是确定问题是否值得去解决。可行性研究的实质: 进行一次大大压缩简化了的系统分析和设计的过程,也就是在较高层次上以较抽象的方式进行的系统分析和设计的过程。

可行性研究的内容: 首先进一步分析和澄清问题定义,导出系统的逻辑模型;然后从系统逻辑模型出发,探索若干种可供选择的主要解法(即系统实现方案;对每种解法都研究它的可行性,至少应该从三方面研究每种解法的可行性。主要方面: 技术可行性,经济可行性,操作可行性, 其他方面: 运行可行性,法律可行性，2.2 可行性研究过程 1.复查系统规模和目标 2.研究目前正在使用的系统 3.导出新系统的高层逻辑模型 4.进一步定义问题 5.导出和评价供选择的解法 6.推荐行动方针 7.草拟开发计划 8.书写文档提交审查 2.3 系统流程图

系统流程图:是概括地描绘物理系统的传统工具。表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程。

2.4数据流图 2.4.1符号 基本符号:

数据存储:数据存储是处于静止状态的数据;数据流:数据流是处于运动中的数据。附加符号: 星号(*:表示“与”关系 加号(+:表示“或”关系 异或(⊕:表示互斥关系 2.5数据字典

数据流图和数据字典共同构成系统的逻辑模型。2.5.1 数据字典的内容

数据字典的组成:数据流数据流分量(即数据元素 数据存储处理 2.5.2定义数据的方法 方法:对数据自顶向下分解。

数据组成方式(三种基本类型:顺序选择重复附加类型:可选 符号: =意思是等价于(或定义为;+意思是和(即,连接两个分量;[]意思是或(即,从方括弧内列出的若干个分量中选择一个,通常用“|”号隔开供选择的分量;{ }意思是重复(即,重复花括弧内的分量;常常使用上限和下限进一步注释表示重复的花括弧。

(意思是可选(即,圆括弧里的分量可有可无。2.5.3数据字典的实现 计算机实现人工实现 2.6成本/效益分析

2.6.1 成本估计:1.代码行技术 2.任务分解技术 3.自动估计成本技术 2.6.2 成本/效益分析的方法 成本/效益分析涉及的4个概念: 1.货币的时间价值 2.投资回收期 3.纯收入

4.投资回收率:P = F1/(1 + j + F2/(1 + j 2 + …+ Fn(1 + j n 第3章需求分析 需求分析的任务: 需求分析是软件定义时期的最后一个阶段,它的基本任务是准确地回答“系统必须做什么?”这个问题。

确定系统必须完成哪些工作,也就是对目标系统提出完整、准确、清晰、具体的要求。

系统分析员应该写出软件需求规格说明书,以书面形式准确地描述软件需求 3.1需求分析的任务 确定对系统的综合要求 分析系统的数据要求 导出系统的逻辑模型 修正系统开发计划

3.1.1确定对系统的综合要求 1.功能需求 2.性能需求

3.可靠性和可用性需求 4.出错处理需求 5.接口需求

6.约束 7.逆向需求

8.将来可能提出的要求 3.1.2 分析系统的数据要求 建立数据模型——ER图

描绘数据结构——层次方框图和Warnier图 数据结构规范化

3.2 与用户沟通获取需求的方法

访谈:1.正式访谈 2.非正式访谈 3.调查表 4.情景分析技术 面向数据流自顶向下求精 简易的应用规格说明技术

快速建立软件原型:(1 第四代技术(4GL(2 可重用的软件构件(3 形式化规格说明和原型环境

3.3分析建模与规格说明 3.3.1 分析建模

需求分析过程应该建立3种模型:数据模型功能模型行为模型 数据字典是分析模型的核心

实体-联系图用于建立数据模型的图形 数据流图是建立功能模型的基础

状态转换图是行为建模的基础 3.4实体-联系图

数据模型中包含3种相互关联的信息:数据对象、数据对象的属性、数据对象彼此间相互连接的关系

3.4状态转换图 3.6.1状态 状态图分类: 表示系统循环运行过程,通常不关心循环是怎样启动的。表示系统单程生命期,需要标明初始状态和最终状态。3.6.2事件

事件就是引起系统做动作或(和转换状态的控制信息。3.6.3符号

3.7其他图形工具 3.7.1 层次方框图 3.7.2Warnier图 3.7.3IPO图

3.8验证软件需求(重点

3.8.1 从哪些方面验证软件需求的正确性 一致性完整性现实性有效性 第五章总体设计 5.1设计过程 由两个主要阶段组成: 系统设计阶段,确定系统的具体实现方案:设想供选择的方案选取合理的方案推荐最佳方案

结构设计阶段,确定软件结构:功能分解设计软件结构设计数据库制定测试文档书写文档审查和复查

5.2设计原理 5.2.1 模块化 模块化的作用: 采用模块化原理可以使软件结构清晰,不仅容易设计也容易阅读和理解。模块化使软件容易测试和调试,因而有助于提高软件的可靠性。模块化能够提高软件的可修改性。

模块化也有助于软件开发工程的组织管理。5.2.2抽象 5.2.3逐步求精

5.2.4信息隐藏和局部化 5.2.5 模块独立 尽量使用数据耦合, 少用控制耦合和特征耦合, 限制公共环境耦合的范围, 完全不用内容耦合。七种内聚的优劣评分结果: 高内聚:功能内聚 顺序内聚 中内聚:通信内聚 过程内聚 低内聚:时间内聚 逻辑内聚 偶然内聚 5.3启发规则

1.改进软件结构提高模块独立性 2.模块规模应该适中

3.深度、宽度、扇出和扇入都应适当

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

5.力争降低模块接口的复杂程度 6.设计单入口单出口的模块 7.模块功能应该可以预测 5.4 描绘软件结构的图形工具 5.4.1 层次图和HIPO图 1.层次图(H图

层次图用来描绘软件的层次结构。很适于在自顶向下设计软件的过程中使用。2.HIPO图 5.4.2结构图

5.5面向数据流的设计方法

结构化设计方法(简称SD方法,也就是基于数据流的设计方法。5.5.1概念

面向数据流的设计方法把信息流映射成软件结构,信息流的类型决定了映射的方法。信息流有两种类型:变换流事务流

第6章详细设计 6.1 结构程序设计 经典的结构程序设计: 只允许使用顺序、IF-THEN-ELSE型分支和DO-WHILE型循环这3种基本控制结构;扩展的结构程序设计: 如果除了上述3种基本控制结构之外,还允许使用DO-CASE型多分支结构和DO-UNTIL型循环结构;修正的结构程序设计: 再加上允许使用LEAVE(或BREAK结构。6.2人机界面设计 6.2.1设计问题

设计人机界面过程中会遇到的4个问题: 系统响应时间:长度易变性

用户帮助设施:集成的帮助设施附加的帮助设施 出错信息处理 命令交互

6.2.3 人机界面设计指南 一般交互指南 信息显示指南 数据输入指南 6.3过程设计的工具 6.3.1 程序流程图(程序框图 程序流程图的主要缺点: 程序流程图本质上不是逐步求精的好工具,它诱使程序员过早地考虑程序的控制流程,而不去考虑程序的全局结构。

程序流程图中用箭头代表控制流,因此程序员不受任何约束,可以完全不顾结构程序设计的精神,随意转移控制。

程序流程图不易表示数据结构。6.3.2盒图(N-S图 盒图具有下述特点:

功能域明确。不可能任意转移控制。

很容易确定局部和全程数据的作用域。

很容易表现嵌套关系,也可以表示模块的层次结构。6.3.3 PAD图

它用二维树形结构的图来表示程序的控制流,将这种图翻译成程序代码比较容易。

PAD图的主要优点如下: 使用表示结构化控制结构的PAD符号设计出来的程序必然是结构化程序。PAD图所描绘的程序结构十分清晰。PAD图表现程序逻辑易读、易懂、易记。

容易将PAD图转换成高级语言源程序,这种转换可用软件工具自动完成。即可表示程序逻辑,也可描绘数据结构。

PAD图的符号支持自顶向下、逐步求精方法的使用。6.3.4 判定表

判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。

判定表的缺点: 判定表的含义不是一眼就能看出来的,初次接触这种工具的人理解它需要有一个简短的学习过程。

当数据元素的值多于两个时,判定表的简洁程度也将下降。6.3.5 判定树 判定树的优点: 它的形式简单,一眼就可以看出其含义,因此易于掌握和使用。判定树的缺点: 简洁性不如判定表,数据元素的同一个值往往要重复写多遍,而且越接近树的叶端重复次数越多。

画判定树时分枝的次序可能对最终画出的判定树的简洁程度有较大影响。6.3.6 过程设计语言(伪码 伪代码的基本控制结构:

简单陈述句结构:避免复合语句。

判定结构:IF_THEN_ELSE或CASE_OF结构。选择结构:WHILE_DO或REPEAT_UNTIL结构。PDL的优点: 可以作为注释直接插在源程序中间。有助于保持文档和程序的一致性,提高了文档的质量。可以使用普通的正文编辑程序或文字处理系统,很方便地完成PDL的书写和编辑工作。

已经有自动处理程序存在,而且可以自动由PDL生成程序代码。PDL的缺点: 不如图形工具形象直观,描述复杂的条件组合与动作间的对应关系时,不如判定表清晰简单。

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

面向数据结构的设计方法的最终目标是得出对程序处理过程的描述。6.4.1Jackson

A由B、C、D 3个元素顺序组成根据条件A是B或C或D中的某一个 A由B出现N次(N ≥0组成

6.4.2 改进的Jackson图 6.4.3 Jackson方法

6.5 程序复杂程度的定量度量 6.5.1 McCabe方法 1.流图(程序图

2.计算环形复杂度的方法 V(G=流图中的区域数 V(G=E-N+2 其中E是流图中的边数,N是结点数 V(G=P+1 其中P是流图中判定结点的数目 6.5.2 Halstead方法

令N1为程序中运算符出现的总次数,N2为操作数出现的总次数,程序长度N定义为: N=N1+N2 程序中使用的不同运算符(包括关键字的个数n1,以及不同操作数(变量和常数的个数n2。预测程序长度的公式如下: H = n1 log2n1 + n2 log2n2 预测程序中包含错误的个数的公式如下: E = N log2(n1+n2/3000 第7章实现

编码和测试统称为实现。7.1编码

7.1.1 选择程序设计语言 主要的实用标准: 系统用户的要求 可以使用的编译程序 可以得到的软件工具 工程规模 程序员的知识 软件可移植性要求

软件的应用领域 7.1.2 编码风格

1.程序内部的文档:恰当的标识符适当的注解程序的视觉组织 2.数据说明 3.语句构造 4.输入输出

5.效率:程序运行时间存储器效率输入输出的效率 7.2软件测试基础 7.2.1 软件测试的目标

测试是为了发现程序中的错误而执行程序的过程;好的测试方案是极可能发现迄今为止尚未发现的错误的测试方案;成功的测试是发现了至今为止尚未发现的错误的测试。7.2.3 测试方法 黑盒测试(功能测试: 把程序看作一个黑盒子;完全不考虑程序的内部结构和处理过程;是在程序接口进行的测试。白盒测试(结构测试: 把程序看成装在一个透明的盒子里;

测试者完全知道程序的结构和处理算法;按照程序内部的逻辑测试程序,检测程序中的主要执行通路是否都能按预定要求正确工作。

7.2.4 测试步骤 1.模块测试(单元测试

保证每个模块作为一个单元能正确运行;发现的往往是编码和详细设计的错误。2.子系统测试

把经过单元测试的模块放在一起形成一个子系统来测试;着重测试模块的接口。3.系统测试

把经过测试的子系统装配成一个完整的系统来测试;发现的往往是软件设计中的错误,也可能发现需求说明中的错误;不论是子系统测试还是系统测试,都兼有检测和组装两重含义,通常称为集成测试。

4.验收测试(确认测试

把软件系统作为单一的实体进行测试;它是在用户积极参与下进行的,而且可能主要使用实际数据(系统将来要处理的信息进行测试;发现的往往是系统需求说明书中的错误。

5.平行运行

7.2.5 测试阶段的信息流 输入信息有两类: 软件配置,包括需求说明书、设计说明书和源程序清单等;测试配置,包括测试计划和测试方案。7.3 单元测试

单元测试集中检测模块;单元测试和编码属于软件过程的同一个阶段;可以应用人工测试和计算机测试这样两种不同类型的测试方法;单元测试主要使用白盒测试技术,对多个模块的测试可以并行地进行。7.3.1 测试重点 模块接口 局部数据结构 重要的执行通路 出错处理通路 边界条件 7.3.2 代码审查

由审查小组正式进行测试称为代码审查;一次审查会上可以发现许多错误,可以减少系统验证的总工作量。

7.3.3 计算机测试

驱动程序是一个“主程序”,它接收测试数据,传送给被测试的模块,并且印出有关的结果。存根程序代替被测试的模块所调用的模块。它使用被它代替的模块的接口,可能做最少量的数据操作,印出对入口的检验或操作结果,并且把控制归还给调用它的模块。

7.4 集成测试

集成测试是测试和组装软件的系统化技术,主要目标是发现与接口有关的问题。

由模块组装成程序时有两种方法: 7.4.3 不同集成测试策略的比较

混合策略: 改进的自顶向下测试方法 混合法 7.4.4 回归测试 7.5 确认测试

确认测试也称为验收测试,它的目标是验证软件的有效性。7.5.3 Alpha和Beta测试

Alpha测试是在受控的环境中进行的。

Beta测试是软件在开发者不能控制的环境中的“真实”应用。1.接口测试 2.路径测试 3.功能测试 4.健壮性测试 5.性能测试 6.用户界面测试 7.信息安全测试 8.压力测试 9.可靠性测试

10.安装/反安装测试确认测试也称为验收测试,它的目标是验证软件的有效性。Alpha测试是在受控的环境中进行的。

Beta测试是软件在开发者不能控制的环境中的“真实”应用。4.接口测试 5.路径测试 6.功能测试 4.健壮性测试 5.性能测试

6.用户界面测试 7.信息安全测试 8.压力测试 9.可靠性测试 10.安装/反安装测试 7.6 白盒测试技术

7.6.1 逻辑覆盖 语句覆盖

判定覆盖:比语句覆盖强,但对程序逻辑的覆盖程度仍不高。

条件覆盖:判定覆盖不一定包含条件覆盖,条件覆盖也不一定包含判定覆盖。判定/条件覆盖:有时判定/条件覆盖也并不比条件覆盖更强。

条件组合覆盖:条件组合覆盖标准的测试数据并不一定能使程序中的每条路径都执行到。

6.点覆盖(语句覆盖标准相同 7.边覆盖(判定覆盖一致 8.路径覆盖

7.6.2 控制结构测试覆盖 1.基本路径测试

基本路径测试是Tom McCabe提出的一种白盒测试技术。首先计算程序的环形复杂度;以该复杂度为指南定义执行路径的基本集合;2.条件测试

从该基本集合导出的测试用例可保证程序中的每条语句至少执行一次,而且每个条件在执行时都将分别取真、假两种值。

3.循环测试

循环测试是一种白盒测试技术,它专注于测试循环结构的有效性。在结构化的程序中通常只有3种循环,即简单循环、串接循环和嵌套循环。7.7 黑盒测试技术 7.7.1 等价划分 7.7.2 边界值分析 7.7.3 错误推测 7.9 软降可靠性 7.9.1 基本概念 软件可靠性: 程序在给定的时间间隔内,按照规格说明书的规定成功地运行的概率。

软件的可用性: 程序在给定的时间点,按照规格说明书的规定,成功地运行的概率。第8章维护

软件工程的目的是要提高软件的可维护性,减少软件维护所需要的工作量,降低软件系统的总成本。

8.1 软件维护的定义

软件维护:在软件已经交付使用之后,为了改正错误或满足新的需要而修改软件的过程。可分为4项活动: 改正性维护 适应性维护 完善性维护 预防性维护 8.2软件维护的特点

8.2.1 结构化维护与非结构化维护差别巨大 8.2.2 维护的代价高昂 8.2.3 维护的问题很多 8.3软件维护过程 1.维护组织 2.维护报告

3.维护的事件流 4.保存维护记录 5.评价维护活动 8.4 软件的可维护性

决定软件可维护性的因素主要有7个: 可理解性 可测试性 可修改性 可靠性 可移植性 可使用性 效率

第9章面向对象方法学引论 9.1面向对象方法学概述 9.1.1面向对象方法学要点

(1认为客观世界是由各种对象组成的,任何事物都是对象

(2把所有对象都划分成各种类对象,每个对象类都定义了一组数据和一组方法(3按照子类和父类的关系,把若干个对象类组成一个层次结构的系统(4对象彼此之间仅能通过传递消息相互联系

9.1.2 面向对象开发方法 面向对象=对象+类 +继承+通信 9.1.4 面向对象方法组成 面向对象的分析 面向对象的设计 面向对象的程序设计 9.1.6 面向对象方法的优点 1.与人类习惯的思维方式一致 2.稳定性好 3.可重用性好 4.可维护性好

5.较易开发大型软件产品 9.2 面向对象的概念 9.2.1 对象

是客观事物或概念的抽象表述,即对客观存在的事物的描述统称为对象,对象可以是事、物、或抽象概念,是将一组数据和使用该数据的一组基本操作或过程封装在一起的实体。

对象的特点(1 以数据为中心。

(2 对象是主动的。(3 实现了数据封装。(4 本质上具有并行性。(5 模块独立性好。9.2.2 类

是一组具有相同属性和相同操作的对象的集合。9.2.3 实例

由某个特定的类所描述的一个具体的对象。9.2.4 消息

向对象发出的服务请求(互相联系、协同工作等。一个消息包含3个部分:接收消息的对象,消息名,消息变元

9.2.5 方法

方法就是对象所能执行的操作,也就是类中所定义的服务。9.2.6 属性

属性就是类中所定义的数据,它是对客观世界实体所具有的性质的抽象。9.2.7 封装

对象封装了对象的数据以及对这些数据的操作。9.2.8 继承(I 继承是子类自动地共享基类中定义的数据和方法的机制。

单重继承:子类仅从一个父类继承属性和方法 多重继承:子类可从多个父类继承属性和方法 9.2.9 多态性 9.2.10 重载 9.3 面向对象建模(II 面向对象开发软件,需要建立3种形式的模型。对象模型。描述系统数据结构—数据结构。动态模型。描述系统控制结构—执行操作。功能模型。描述系统功能—数值变化。9.4 对象模型

9.4.1类图的基本符号(I 1.定义类

2.定义属性

可见性属性名:类型 = 缺省值 {性质串} 可见性(visibility表示该属性对类外的元素是否可见。分为: public(+公有的,即模型中的任何类都可以访问该属性。private(-私有的,表示不能被别的类访问。

protected(#受保护的,表示该属性只能被该类及其子类访问。如果可见性未申明,表示其可见性不确定。

3.定义操作

可见性操作名(参数表:返回类型{性质串}

9.4.2 表示关系的符号(I 9.4.2.1 关联(I 关联表示两个类的对象之间存在某种语义上的联系。(1普通关联

递归关联:一个类与本身有关联关系(3限定关联

(4关联类

9.4.2.2 聚集(I(1共享聚集

如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成,则该聚集称为共享聚集。

(2组合聚集

如果部分类完全隶属于整体类,部分与整体共存,整体不存在了部分也会随之消失,则该聚集称为组合聚集。

9.4.2.3 泛化(I

(1普通泛化(2受限泛化

预定义的约束有4种:多重、不相交、完全和不完全。

9.4.2.4 依赖

9.4.2.5 细化

9.5动态模型 9.6功能模型 9.6.1用例图

模型元素:系统、行为者、用例及用例之间的关系(扩展关系、使用关系用例的实例是脚本

第10章面向对象分析 10.1 面向对象分析的基本过程

面向对象分析:抽取和整理用户需求并建立问题域精确模型的过程.理解----用户、分析员和领域专家

表达----需求规格说明书(对象模型、动态模型、功能模型

验证----二义性,完善性

对象模型最基本、最重要、最核心。静态结构(对象模型

3个子模型交互次序(动态模型 数据变换(功能模型

复杂问题的对象模型的5个层次 面向对象分析的过程 寻找类与对象 识别结构 识别主题 定义属性 建立动态模型

建立功能模型 定义服务 10.2 需求陈述

需求陈述是阐明“做什么”,而不是“怎样做” 问题范围 功能需求 性能需求 应用环境 假设条件

第11章面向对象设计 11.1 面向对象设计的准则 1.模块化 2.抽象 3.信息隐藏 4.弱耦合

耦合指不同对象之间相互关联的紧密程度。对象之间的耦合分两类: 交互耦合

如果对象之间的耦合通过消息连接来实现,则这种耦合就是交互耦合。交互耦合应尽可能松散。

继承耦合

与交互耦合相反,应该提高继承耦合程度。5.强内聚

在面向对象设计中存在下述3种内聚: 服务内聚:一个服务应该完成一个且仅完成一个功能。

类内聚:一个类应该只有一个用途,它的属性和服务应该是高内聚的。一般-特殊内聚:设计出的一般-特殊结构,应该符合多数人的概念 6.可重用 11.2 启发规则

1.设计结果应该清晰易懂 2.一般-特殊结构的深度应适当 3.设计简单的类 4.使用简单的协议 5.使用简单的服务 6.把设计变动减至最小 第13章软件项目管理 软件工程计划

控制度量软件规模估算工作量进度计划 风险管理 质量保证 配置管理

组织

明确软件开发的目标

提供组织机构和资源配置方面的保证 保证开发目标的实现 技术

管理

13.1估算软件规模

13.1.1 代码行技术 估算方法： 由多名有经验的软件工程师分别做出估计。每个人都估计程序的最小规模(a、最大规模(b和最可能的规模(m，分别算出这 3 种规模的平均值之后，再用下式计算程序规模的估计值： 单位： LOC 或 KLOC。代

码行技术的优点： 代码是所有软件开发项目都有的“产品”，而且很容易计算代码行数； 有大量参考文献和数据。代码行技术的缺点： 源程序仅是软件配置的一个成分，由源程序度量软件规模不太合理； 用不同语言实现同一个软件所需要的代码行数并不相同； 不适用于非过程性语言。13.1.2 功能点技术 功能点技术依据对软件信息域特性和软件复杂性的评估结果，估算软件规模。这种方法用功能点(FP为单位度量软件规模。1.信息域特性 输入项数(Inp、输出项数(Out、查询数(Inq、主文件数(Maf、外部接口数(Inf 每个特征根据其复杂程度分配一个功能点数，即信息域特征系数 a1，a2，a3，a4，a5 2.估算功能点的步骤(1 计算未调整的功能点数 UFP UFP=a1×Inp+a2×Out+a3×Inq+a4×Maf+a5×Inf(2 计算技术复杂性因子 TCF 技术因素对软件规模的综合影响程度 DI： 技术复杂性因子 TCF 由下式计算： TCF = 0.65 + 0.01 × DI 因为 DI 的值在 0~70 之间，所以 TCF 的值在 0.65~1.35 之间。(3 计算功能点数 FP FP = UFP × TCF 功能点技术优点：与所用的编程语言无关，比代码行技术更合理。功能点技术缺点： 在判断信息域特性复杂级别和技术因素的影响程度时主观因素较大，对经 验依赖性较强。13.2 工作量估算

13.2.1 静态单变量模型 E ev 是估算变量（KLOC 或 FP）。13.2.2 动态多变量模型

动态多变量模型也称为软件方程式，该模型把工作量看作是软件规模和开发时间这两个变量 的函数。E=(LOC×B0.333/P3×(1/t4 13.2.3 COCOMO2 模型（构造性成本模型）3 个层次的估算模型： 应用系统组成模型： 这个模型主要用于估算构建原型的工作量，模型名字暗示在构建原型时 大量使用已有的构件。早期设计模型：这个模型适用于体系结构设计阶段。后体系结构模型：这个模型适用于完成体系结构设计之后的软件开发阶段。COCOMO2 使用的 5 个分级因素：项目先例性、开发灵活性、风险排除度、项目组凝聚力、过 程成熟度 13.3 进度计划 13.3.1 估算开发时间 Brooks 规律：向一个已经延期的项目增加人力，只会使得它更加延期。13.3.2 Gantt 图 Gantt 图的主要优点： Gantt 图能很形象地描绘任务分解情况，以及每个子任务(作业的开始和结束时间。具有直观简明和容易掌握、容易绘制的优点。Gantt 图的 3 个主要缺点： 不能显式地描绘各项作业彼此间的依赖关系； 进度计划的关键部分不明确，难于判定哪些部分应当是主攻和主控的对象； 计划中有潜力的部分及潜力的

大小不明确，往往造成潜力的浪费。13.3.3 工程网络 工程网络是系统分析和系统设计的强有力的工具。13.3.4 估算工程进度 计算最早时刻 EET 使用下述 3 条简单规则： 考虑进入该事件的所有作业； 对于每个作业都计算它的持续时间与起始事件的 EET 之和； 选取上述和数中的最大值作为该事件的最早时刻 EET。计算最迟时刻 LET 使用下述 3 条规则：

考虑离开该事件的所有作业； 从每个作业的结束事件的最迟时刻中减去该作业的持续时间； 选取上述差数中的最小值作为该事件的最迟时刻 LET。13.3.5 关键路径 关键事件：EET=LET 13.3.5 机动时间=(LET结束－(EET开始－持续时间 =右下角－左上角－持续时间 13.4 人员组织 13.4.1 民主制程序员组 如果小组内有 n 个成员，则可能的通信信道共有 n(n-1/2 条。13.4.2 主程序员组 主程序员组的两个重要特性：专业化、层次性 13.4.3 现代程序员组 13.5 质量保证 13.5.1 软件质量 13.5.2 软件质量保证措施 13.6 软件配置管理 基于非执行的测试（复审或评审），主要用来保证在编码之前各阶段产生的文档的质量； 基于执行的测试（软件测试），需要在程序编写出来之后进行，它是保证软件质量的最后一 道防线； 程序正确性证明，使用数学方法严格验证程序是否与对它的说明完全一致。1.技术复审的必要性 2.走查:参与者驱动法、文档驱动法 3.审查：综述 准备 审查 返工 跟踪 4.程序正确性证明 软件配置管理是在软件的整个生命期内管理变化的一组活动。具体地说，这组活动用来：①标识变化；②控制变化；③确保适当地实现了变化；④向需要 知道这类信息的人报告变化。软件配置管理的目标： 使变化更正确且更容易被适应，在必须变化时减少所需花费的工作量。

13.6.1 软件配置 1.软件过程的输出信息（软件配置项）： 计算机程序（源代码和可执行程序）； 描述计算机程序的文档（供技术人员或用户使用）； 数据（程序内包含的或在程序外的）2.基线 基线就是通过了正式复审的软件配置项。13.6.2 软件配置管理过程 软件配置管理主要有 5 项任务： 1.标识软件配置中的对象：基本对象、聚集对象 2.版本控制 3.变化控制 4.配置审计 5.状态报告 13.7 能力成熟度模型 1.初始级 软件过程的特征是无序的，有时甚至是混乱的。2.可重复级 软件机构建立了基本的项目管理过程(过程模型，可跟踪成本、进度、功能和质

量。3.已定义级 软件机构已经定义了完整的软件过程（过程模型），软件过程已经文档化和标准化。4.已管理级 软件机构对软件过程（过程模型和过程实例）和软件产品都建立了定量的质量目标，所有项 目的重要的过程活动都是可度量的。5.优化级 软件机构集中精力持续不断地改进软件过程。这一级的软件机构是一个以防止出现缺陷为目 标的机构，它有能力识别软件过程要素的薄弱环节，并有足够的手段改进它们。

第二篇：软件工程导论复习整理(最新)

第一章

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

2.软件与硬件的区别：软件不同于硬件，它是计算机系统中的逻辑部件而不是物理部件。

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

4.软件工程是指导计算机软件开发和维护的一门工程学科，采用工程的概念、原理、技术和方法来开发与维护软件，把经过时间考验而证明正确的管理技术和当前能够得到最好的技术方法结合起来，以经济地开发出高质量的软件并有校地维护它。

5.软件工程方法学三要素：方法、工具和过程。

6.传统方法学也称为生命周期方法学或结构化范型。它采用结构化技术来完成软件开发的各项任务，并使用适当的软件工具或软件工程环境来支持结构化技术的运用。

7.面向对象方法学把数据和行为看成同等重要的，它是一种以数据为主线，把数据和对数据的操作紧密地结合起来的方法。

8.软件生命周期划分为三个时期:1软件定义（问题定义、可行性研究、需求分析），2软件开发（总体设计、详细设计、编码和单元测试、综合测试），3运行维护（软件维护）。

9.4类软件维护活动：改正性维护，也就是诊断和改正在使用过程中发现的软件错误；适应性维护，即修改软件以适应环境的变化；完善性维护，即根据用户的要求改进或扩充软件使它更完善；预防性维护，即修改软件，为将来的维护活动预先做准备。

10.“瀑布模型”的缺点：它是由文档驱动的，仅仅通过写在纸上的静态的规格说明，很难全面正确地认识动态的软件产品；瀑布模型几乎完全依赖于书面的规格说明，很可能导致最终开发出的产品不能真正的满足用户的需要。

11.快速原型模型的优点：原型系统已经通过与用户交互而得到验证，据此产生的规格说明文档正确地描述了用户需求；开发人员通过建立原型系统已经学到了很多东西，因此，在设计和编码阶段发生错误的可能性也比较小，这自然减少了在后续阶段需要改正前面阶段所犯错误的可能性。

第二章 1.可行性研究的三个方面：技术可行性:使用现有的技术能实现这个系统经济可行性:这个系统的经济效益能超过它的开发成本操作可行性:系统的操作方式在这个用户组织内行得通

2.数据流图的4个基本符号及画法P41

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

4.符号含义：＝表示“等价于”或“定义为”；＋表示连接；[ ]表示“或”，用“|”分隔；{ }表示“重复”，()表示“可选”用“，”号隔开；1｛A}5 表示上限和下限。

5.高校电话号码数据的定义P54

第三章

1.需求分析3种模型：数据模型：实体-联系图，描绘数据对象及数据对象之间的关系；功能模型：数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程；行为模型：状态转换图，指明了作为外部事件结果的系统行为，描绘了系统的各种行为模式。

2.ER图3种基本成分：实体（数据对象），关系，属性。P64

3.软件需求验证的四个方面：一致性，完整性，现实性，有效性。

第四章

1.总体设计2个主要阶段：系统设计阶段，确定系统的具体实现方案；结构设计阶段，确定软件结构。

2.信息隐藏：设计和确定模块，使得一个模块内包含的特定信息，对于不需要这些信息的模块来说，是不能访问的。

3.模块独立2个度量标准：内聚和耦合。耦合衡量不同模块彼此间互相依赖（连接）的紧密程度；内聚衡量一个模块内部各个元素彼此结合的紧密程度。4.耦合与内聚判定P98-99

5.深度：表示软件结构中控制的层数，它往往粗略的标志一个系统的大小和复杂程度，深度和程序长度之间应该有粗略的对应关系；宽度：是软件结构内同一层次上的模块总数的最大值；扇出：是一个模块直接控制（调用）的模块数目；扇入：表明一个模块有多少上级模块直接调用它

6.P100 模块的作用域和模块的控制域之间的关系：模块的作用域定义为受该模块内一个判定影响的所有模块的集合；模块的控制域是这个模块本身以及所有直接或间接从属于它的模块的集合；模块的作用域应该在控制域之内（在设计的很好的系统中，所有受判定影响的模块应该都从属于做出判定的那个模块，最好局限于做出判定的那个模块本身以及它的直属下级模块）。

6.层次图，结构图P10

2第六章

1.结构程序设计定义：如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进行连接，并且每一个代码块只有一个入口和一个出口，则称这个程序是结构化的。

2.P124 过程设计的工具：程序流程图、盒图、PAD图、判定表、判定树、过程设计语言。

3.画出伪码程序的程序流程图和盒图 P1

41第七章

1.软件测试在软件生命周期中横跨两个阶段：单元测试：模块的编写者和测试者是同一个人，编码和单元测试属于软件生命周期的同一个阶段；综合测试：由专门的测试人员承担这项工作。

2.为什么软件测试不能由程序的编写人员来做？

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

(2)正确认识测试的目标是十分重要的，测试目标决定了测试力案的设计。如果为了表明程序是正确的而进行测试，就会设计一些不易暴露错误的测试方案；相反，如果测试是为了发现程序中的错误，就会力求设计出最能暴露错误的测试方案。

(3)由于测试的目标是暴露程序中的错误，从心理学角度看，由程序的编写者自己进行测试是不恰当的。

3.测试方法：(1)黑盒测试 ：把程序看作一个黑盒子，完全不考虑程序的内部结构和处理过程 ；对程序接口进行测试，检查程序功能是否能按规格说明书的规定正常使用； 程序是否能适当地接受输入数据并产生正确的输出信息； 程序运行过程中能否保持外部信息的完整性

(2)白盒测试 ：把程序堪称装在一个透明的白盒子里，测试者完全知道程序的结构处理算法 ；按照程序内部的逻辑测试程序，检测程序中的主要执行通路是否都能按 预定要求正确工作。

4.测试步骤：模块测试，子系统测试，系统测试，验收测试，平行运行。P151

5.集成测试是测试和组装软件的系统化技术，即是在把模块按照设计要求组装起来的同时进行测试，由模块组装成程序时两种方法：非渐增式测试方法和渐增式测试方法。

6.P162 逻辑覆盖标准：语句覆盖，判定覆盖，条件覆盖，判定条件覆盖，条件组合覆盖，（还有点覆盖，边覆盖，路径覆盖）。

7.设计测试用例：P16

2第八章

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

2.维护工作量的一个模型： M = P + K × exp(c-d)其中： M是维护用的总工作量，P是生产性工作量，K是经验常数，c是复杂程度d是维护人员对软件的熟悉程度。exp，以自然对数e为底指数函数，Exponential(指数曲线)。

3.软件可维护性与哪些因素有关？在软件开发过程中应该采取哪些措施来提高软件产品可维护性？

答：软件的可理解性、可测试性、可修改性、可移植性 和可重用性是决定软件可维护下的基本因素。

软件生命周期每个阶段的工作都和软件可维护性有密切关系。良好的设计，完整准确易读易理解的文档资料，以及一系列严格的复审和测试，使得一旦发现错误时比较容易诊断和纠正，当用户有新要求或外部环境变化时软件能较容易地适应，并且能够减少维护引入的错误。因此，在软件生命周期的每个阶段都必须充分考虑维护问题，并且为软件维护预做准备。

第九章

1.面向对象的概念：对象，类，实例，消息，方法，属性，封装，继承，多态性P209-215 对象：是封装了数据结构及可以施加在这些数据结构上的操作的封装体（类的实例）类：是对具有相同属性和行为的一个或多个对象的描述（支持继承的抽象数据类型）实例：是由某个特定的类所描述的一个具体的对象

消息:就是要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。由3部分组成：接收消息的对象，消息选择符，零个或多个变元

方法：是对象所能执行的操作，描述了对象执行操作的算法，响应消息的方法

属性：类中所定义的数据，对客观世界实体所具有的性质的抽象

封住：就是信息隐藏，通过封装对外界隐藏了对象的实现细节

继承：子类自动地共享基类中定义的数据和方法的机制

多态性：指子类对象可以像父类对象那样使用，同样的消息既可以发送给父类对象也可以发送给子类对象

2.面向对象建模：描述系统数据结构的对象模型，描述系统控制结构的动态模型，描述系统功能的功能模型。类名

3.对象模型：P217 属性类图符号：服务

4.表示关系的符号：类与类之间通常有关联、泛化(继承)、依赖和细化等4种关系关联：表示俩个类的对象之间存在某种语义上的联系

泛化：是通用元素和具体元素之间的一种分类关系

依赖：描述俩个模型元素（类，用例等）之间的语义连接关系

细化：用来协调不同阶段模型之间的关系，表示各个开发阶段不同抽象层次的模型之间的相关性，常常用于跟踪模型的演变。

5.功能模型：用例图包含的模型元素有系统、行为者、用例及用例之间的关系P224

第十章

1.面向对象分析，就是抽取和整理用户需求并建立问题域精确模型的过程

2.建立对象模型、动态模型、功能模型的基本方法P235-255

第三篇：软件工程导论复习材料

1.软件工程基本概念

1.（）因素促使计算机系统越来越复杂。

A.计算机内存和存储容量上的巨大增长

B.外部输入／输出选项的更加多样性

C.计算机体系结构方面的深刻变化

D.以上所有选项

2.下面的（）不再是现代软件工程师关注的问题。

A.为什么不能在产品发布前去除软件错误？

B.为什么软件需要很长时间才能完成？

C.为什么开发一个软件的成本这么高？

D.为什么计算机硬件的成本这么高？

3.软件会逐渐退化而不会磨损，其原因在于（）。

A.软件备件很难订购

B.软件错误通常发生在使用之后

C.通常暴露在恶劣的环境下

D.不断的变更使组件接口之间引起错误软件

4.大多数软件仍然是定制开发的，其原因在于（）。

A.软件组件重用是十分普遍的 B.可重用的组件太昂贵而无法使用

C.软件在不使用其他组件的情况下很容易构造出来

D.商业组件在很多应用领域中可以得到

5.下面的（）说法是正确的。

A.软件危机在20世纪70年代末期全面爆发

B.当前先进的软件工程方法已经解决了软件危机的问题

C.软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题

D.软件危机是指在软件产品中存在一系列的质量问题 1.瀑布模型本质上是一种（）。

A、线性迭代模型

B、顺序迭代模型C、线性顺序模型

D、及早见产品模型 2.（）是用户和设计交换最频繁的方法。

A、原型化方法

B、瀑布模型方法C、螺旋模型方法

D、构件组装模型 5.在软件开发模型中，提出最早、应用最广泛的模型是（）A.瀑布模型

B.喷泉模型

C.增量模型

D.螺旋模型

1.软件工程的方法只适用于大型软件的开发，对小型软件的开发没有帮助。（）1.什么是软件危机？其主要表现有那些？

1.有人认为软件工程过于耗费时间，并且妨碍开发人员的编程效率。你是否认同这种观点？请阐述理由。

2.需求分析 需求规格说明描述了（）。

A.计算机系统的功能、性能及其约束

B.每个指定系统的实现

C.软件体系结构的元素

D.系统仿真所需要的时间

7．软件可行性研究实质上是要进行一次（）需求分析、设计过程。A.简化、压缩的B.详细的 C.彻底的D.深入的 11.下面说法不正确的是（）。

A.流程图不易表示数据结构

B.流程图容易造成非结构化的程序结构

C.流程图支持逐步求精

D.流程图描述的是程序的逻辑结构 1.需求分析中开发人员要从用户那里了解（）。

A、软件做什么B、用户使用界面C、输入的信息D、软件的规模

2.需求分析阶段，分析人员要确定对问题的综合需求，其中最主要的是（）需求。A、功能 B、性能 C、数据 D、环境 24.软件可行性研究一般不考虑（）

A.是否有足够的人员和相关的技术来支持系统开发 B.是否有足够的工具和相关的技术来支持系统开发 C.待开发软件是否有市场、经济上是否合算 D.待开发的软件是否会有质量问题 25.需求规格说明描述了（）

A.计算机系统的功能、性能及其约束 B.每个指定系统的实现 C.软件体系结构的元素

D.系统仿真所需要的时间

26.需求分析阶段，分析人员要确定对问题的综合需求，其中最主要的是（）需求 A.功能

B.性能

C.数据

D.环境

7.成本效益分析的目的是从

角度评价开发一个项目是否可行。

2.软件需求规格说明书在软件开发过程中具有重要的作用，它是软件可行性分析的依据。3.（）目前存在一个很普遍的现象，即不同的客户提出的需求是相互矛盾的，但每个人都争辩自己是正确的。

5.（）在需求分析过程中，分析员要从用户那里解决的最重要的问题是明确软件做什么。2.可行性研究主要确定问题分析阶段所确定的问题是否有可行的解。（）6.在需求分析过程中，分析员要解决的最重要的问题是明确软件做什么。（）7.数据流图的画法？

3.软件设计与编码.概要设计阶段产生的文档不包括（）。A.概要设计说明书

B.数据库设计说明书 C.用户手册

D.开发进度月报.一个模块把数值作为参数传送给另一个模块，这种耦合方式称为（）。A.数据耦合 B.公共耦合 C.控制耦合 D.标记耦合

10．与详细设计相对应的是数据库的（）设计。A.概念

B.逻辑 C.物理

D.功能 19.序言性注释主要内容不包括（）。

A.模块的接口

B.数据的描述

C.模块的功能

D.数据的状态 11.模块化的目的是：（）

A、增加内聚性 B、降低复杂性C、提高易读性D、减少耦合性 12.软件设计中划分模块的一个准则是（）。

A、低内聚低耦合B、低内聚高耦合C、高内聚低耦合D、高内聚高耦合 13.下列耦合中，耦合程度最高的是：（）A、标记耦合 B、控制耦合 C、内容耦合 D、公共耦合 14.模块间耦合程度越高，说明模块之间彼此依赖的程度越（）。A、松散 B、紧密 C、无法判断 D、相等 15.程序的三种基本控制结构是（）。A、过程、子程序和分程序。B、顺序、选择和重复。C、递归、堆栈和队列。D、调用、返回和转移。

2.软件设计阶段一般分为

和

两个阶段。

3.软件开发过程中，模块化开发追求的目标是：__________________。6.数据建模常用的模型是______________。任何程序都可由

、和

3种基本控制结构构造。这3种基本结构的共同点是

、。

4.软件人员的数量与软件开发进度成正比。（）

8.模块化程序设计中，模块越小，模块化的优点越明显。一般来说，模块的大小都在10行以下。（）

9.模块化，信息隐藏，抽象和逐步求精的软件设计原则有助于得到高内聚，低耦合度的软件产品。（）

10.程序设计风格指导原则提出，尽量多使用临时变量。（）8.模块化程序设计中，模块越小，模块化的优点越明显。（）

4.软件测试

13．（）方法需要考察模块间的接口和各模块之间的联系。A.单元测试

B.集成测试 C.确认测试

D.系统测试

16．在软件生存周期中，时间最长、所花费的精力和费用也最多的阶段是（）。A.详细设计

B.维护 C.概要设计

D.测试 16.软件测试的目的是？（）A、证明软件的正确性

B、找出软件系统中存在的所有错误 C、证明软件系统中存在错误

D、尽可能多的发现软件系统中的错误

17.（）是以提高软件质量为目的的技术活动。A．技术创新

B．测试

C．技术创造

D．技术评审

18.软件维护工作的最主要部分是（）。A、校正性维护 B、适应性维护 C、完善性维护 D、预防性维护

19.检查软件产品是否符合需求定义的过程称为（）。A、确认测试 B、集成测试 C、验收测试 D、系统测试

20.软件维护的副作用，是指（）。A、开发时的错误 B、隐含的错误

C、因修改软件而造成的错误 D、运行时误操作

33.发现错误能力最弱的是（）A.语句覆盖

B.判定覆盖

C.条件覆盖

D.路径覆盖 34.（）方法需要考察模块间的接口和各模块之间的联系 A.单元测试

B.集成测试

C.确认测试

D.系统测试 1.软件测试主要可分为________和________两种类型。

4.软件维护可分为四类，它们是改正性维护，________，________ 和________。8.软件可维护性的因素是可理解性、可测试性、可修改性、可移植性和_____。

9． 软件质量保证应从________开始，直到投入使用和售后服务的软件生存期的每一阶段中 4 的每一步骤。

3.为了加快软件维护作业的进度，应尽可能增加维护人员的数目。（）

5.质量保证是为了保证产品和服务充分满足消费者要求的质量而进行的有计划,有组织的活动。（）

6.判定覆盖不一定包含条件覆盖，条件覆盖也不一定包含判定覆盖。（）7.测试只能证明程序有错误,不能证明程序没有错误。（）3.软件维护就是改正软件中的错误。（）

10.用黑盒法测试时，测试用例是根据程序内部逻辑设计的。（11.基本路径测试的分析方法？）5

5.面向对象的软件工程（UML）..（）意味着一个操作在不同的类中可以有不同的实现方式。

A.消息

B.多继承

C.多态性

D.封装.顺序图反映对象之间发送消息的时间顺序，它与（）是同构的。A.用例图

B.类图

C.协作图

D.状态图

28.在软件工程学中，我们把一组具有相同数据结构和操作的对象的集合定义为（）A.类

B.属性

C.对象

D.消息

29.顺序图反映对象之间发送消息的时间顺序，它与（）是同构的 A.用例图

B.类图

C.协作图

D.状态图 35.下列关于UML叙述不正确的是（）A、UML是一种高级编程语言，且是可视化的B、UML是一种文档化语言 C、UML是一种可用于详细描述的语言

D、UML是一种构造语言

36.表示一种一般事物（父类）和特殊事物（子类）之间的关系是（）A、依赖

B、关联

C、泛化

D、实现 1.（）用例参与者总是人员而不是系统设备。

6.（）面向对象设计是在分析模型的基础上，运用面向对象技术生成软件实现环境下的设计模型。

8.（）关系数据库可以完全支持面向对象的概念，面向对象设计中的类可以直接对应到关系数据库中的表。

9.UML用例图的画法？

6.项目管理

38.CMMI体系中，第三级是（）A、已管理级

B、已量化管理级 C、已定义级

D、持续优化级 5.软件配置管理中，基线是___________________________________。4.（）软件工作产品一旦成为基线就不能再更改了。4.什么是软件配置管理？主要目标和手段是什么？ 4.什么是基线？

第四篇：软件工程复习重点总结

第一章

软件过程：需求设计实现发布

软件过程三要素: 过程+方法+工具

瀑布rup scrum Iconix

Scrum是一种迭代式增量软件开发过程，通常用于敏捷软件开发。Product Owner、Scrum Master、Team Product Backlog、SprintBacklog、Burndown Chart、Sprint、Sprint Planning Meeting、Daily Standup Meeting、Review Meeting、Retrospective Meeting ICONIX软件开发过程

愿景、业务建模、需求分析、健壮性分析、系统设计„„

思想是重点；过程是方式；方法和工具是载体

第二章

敏捷开发是一种以人为核心、迭代、循序渐进的开发方法。敏

捷是一种思想•Scrum是一个框架

敏捷开发过程知多少？

•Scrum、•极限编程（XP）、•Crystal Methods（水晶方法族）

•特性驱动开发（FDD）

•动态系统开发（DSDM）

•轻量型统一过程（RUP）

调查结果：敏捷开发方法—Scrum最流行！

Scrum的适用场景

•7人，+or-2

•偏小一些会更适合•最好能坐在一起

•客户参不度高

•快速移动互联网项目

•自主性研发的产品

第三章

软件项目是为了改善某个组织的某些方面

–老大就是要改善的组织中最有权力的干系人。

用户建模四步曲列出尽可能多的用户识别关键用户（购买决策者/主要使用者）分类，合并次要用户

4添加虚拟和极端用户

第四章

•产品backlog是Scrum的核心

产品功能列表格式

•ID（标示符）

–统一标识符

•Name（标题）

–简短的、描述性的故事名

•Story（故事）

–故事内容描述

•Priority（重要性）

–产品负责人评出一个数值，指示这个故事有多重要

•Initial estimate（初始估计）

–团队的初步估算，表示不其他故事相比，完成该故事所需的工作量

•How to demo（如何做演示）

–它大略描述了这个故事应该如何在sprint 演示上进行示范

•Notes（注解）

–相关信息、解释说明和对其它资料的引用等等

产品功能列表由谁来写？

•思考：由谁来写？

–主要是Product Owner

–Team也有权利，但最终由PO进行取舍。

用户故事是一种敏捷的需求挖掘方式，其侧重点不是将需求书写出来，而是将需求讨论出来。

按“作为一个„„，可以„„，以便„„”样式和思路写成的用户需求，就是用户故事。

用户故事的三个变量

范围，重要性，估算

好故事的准则

•独立的（Independ）

•可讨论的（Negotiable）

•对用户戒客户有价值的（Valuable）

•可估计的（Estimatable）

•小的（Small）

•可测试的（Testable）

Sprint会议如何迚行

–确定Sprint目标及长度

–讲解Story、估算时间、任务分解

–决定 sprint 要包含的故事

–一些其他问题

第六章

什么是界面原型

•界面原型指使用工具根据客户需求及软件分析人员的理解，将头脑中的界面快速的反映到介质上。

界面原型的目的•尽早验证需求

•尽早明确不确定性的因素

•方便沟通交流

•为后续界面设计提供基础

第八章

ICONIX过程

•ICONIX过程的规模介于RUP和XP之间

•适合中小型的、需求相对明确的软件项目

•ICONIX核心思想

•开源！节流！

ICONIX软件过程是用例驱动的软件过程。

ICONIX过程中的第一步：明确愿景

•愿景是确保项目成功的第一步；

•愿景必须来自老大；

•愿景必须是可度量。

如何获取软件项目的愿景

•获取软件项目愿景的三步曲：

•第一步：找到软件项目的“老大”；

•第二步：得到“老大”对项目的期望（愿景）；

•第三步：描述出愿景的度量指标；

要点：系统要改善哪个组织的流程？

老大就是要改善的组织中最有权力的干系人

第九章

业务建模的目的：从组织的角度来定位系统的价值。

业务建模

•业务建模的目的是把视角从系统转向组织，站在客户角度看问题。

•业务用例是对组织为外部业务执行者提供的价值的建模。

•现状业务序列图是对组织价值内部实现流程（业务工人与业务实体的协作）的建模 •改迚业务序列图是对新系统为组织提供的改良的建模。

业务建模的步骤：

1.明确我们为谁服务（选定愿景要改进的组织）。

2.要改进的组织是什么现状（业务用例图、现状业务序列图）。

3.我们如何改进（改进业务序列图）。

第十章

域建模的步骤

第一步：提取名词或名词短语

第二步：排除重复、相似

第三步：排除系统范围外

第四步：画出第一版域模型图

第五步：整理第一版域模型

域模型之间的关系

•泛化[Generalization]，一般元素和特殊元素的关系。

•关联[Association]，两个类乊间存在着某种语义上的联系。

系统需求分析的目的是把视角转向新系统，站在最织

用户（及其它干系人）的角度看问题。

•系统用例是对（新）系统为系统执行者提供的价值的建模

系统用例建模步骤

1.绘制系统用例图

2.编写系统用例描述

3.更新域模型

绘制系统用例图

1.确定系统边界

2.识别系统执行者

3.识别系统用例

4.确定用例间的关系

用例描述的作用

•用例图描述总体，用例文档描述绅节。

•每个用例必须对应有用例描述。

用例描述的基本组成•干系人利益

•基本路径

•扩展路径

•业务觃则

软件产品的典型非功能性需求(RUPS)

•可靠性[Reliability]。

•可用性[Usability]。

•性能[Performance]。

•可支持性[Supportability]。

需求获取的方法

•研究文档。

•问卷调查。

•访谈。

•观察。

•研究竞争对手。

需求分析结果复核

•形式：面对面会议。

•参会人：甲乙双方在需求分析阶段的主要参与者。

•被审材料：域模型、用例图、用例描述、非功能性需求；

•过程：需求分析师主持，最终需求分析成果，所有参与者交流讨论，达成统一理解和确认。•结论：所有参与者签字确认。（当然，也有可能是未达成共识，需要返工。）

•注意：后续的工作基本不需要用户的参不了。

第十一章

健壮性分析的步骤

第一步：创建一个空的健壮性图。

第三步：从基本路径的第一句话开始画健壮性图。

第二步：直接将用例文本粘贴到图上（基本路径和扩展路径）。

第四步：贯串整个用例基本路径，一次一个句子，画执行者、适当的边界对象和实体对象以及控制器，和各元素乊间的连线。

第五步：将每一个扩展路径画在健壮性图上，并以红色标示出。

在用例驱动的开发模式中，用例的准确完整性是关键；

•健壮性分析技术两个主要的价值：其一帮助完善用例分析结果；其二完善域模型，做为需求分析走向系统设计的过度技术；

•丌要花费太多的精力和时间在本阶段，本阶段的成果也仅起到过度作用，不纳入最终文档； 第十二章

关键设计是功能性需求的设计，成果为类图和序列图；

•关键设计还没考虑真实实现的平台相关因素，因此不能基于这个阶段的设计成果开始编码； •关键设计的方法就是在域模型、用例描述和健壮性分析的基础上，迭代生成类图和序列图；

关键设计的步骤

•第一步：将现有的域模型直接作为第一版静态类模型；

•第二步：基于用例描述和健壮性分析结果，画出每个用例的序列图；

•健壮性图中的控制类会转化为方法；

•如果也转化为控制类，那么就添加到类图中（注意：边界类丌添加到类图中）； •第三步：整理静态类图和序列图；

•第四步：关键设计复核，迭代更新用例图、类图和序列图；

高内聚、低耦合。是判断设计好坏的标准。

关键设计复核的指导建议

•确保关键设计的“如何做”和需求阶段的“做什么”匹配。也就是说每个用例都要和序列图匹配，包含了用例的基本流程和分支流程。

•复核设计的品质。应该至少有一个设计与家在场。

•检查消息的连贯性。检查时序图上消息箭头的指向，有时我们会发现对象乊间缺少消息而造成跳跃，我们必须消除这些逻辑跳跃。

•确保方法分配给了适当的类，类视图中的每一个类拥有适当的方法和属性。

第五篇：软件工程导论最全复习总结(精)

1、软件危机是指在计算机开发过程中的开发和维护过程中所遇到的一系列的严重问题。

2、软件是程序、数据及相关文档的完整集合,程序是能够完成预定功能和性能的可执行的

程序序列;数据是是使程序能够适当的处理信息的数据结构;文档是开发、使用和维护程序所需要的图文资料。

3、软件工程学包含3个要素:方法、工具、过程。

4、目前使用最广泛的软件工程方法学是传统方法学和面向对象方法学。

5、软件工程方法学的软件过程基本上可以用瀑布模型来描述。

6、瀑布模型、快速原型模型、增量模型、螺旋模型、喷泉模型。

7、Rup把软件生命周期划为:初始、精化、构建、移交阶段。

8、可行性研究的三方面:技术可行性、经济可行性、操作可行性。

9、数据流图(DFD是一种图形化技术,他描绘信息流和数据从输入移动到输出的过程中

所经受的变化。

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

11、数据流图和数据字典共同构成系统的逻辑模型,没有数据字典,数据如就不严格, 没有流程图,数据字典也难以发挥作用。

12、需求分析阶段结束之前,系统分析员应该写出软件需求规格说明书,以书面形式准

确的描述软件需求。13、9、结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。

14、ER图中包含了实体、关系和属性,矩形代表实体,菱形表示关系,椭圆或圆角矩

形表示属性,用直线把实体和其属性连接。

15、验证软件需求的正确性:一致性、完整性、现实性、有效性。

16、总体设计的基本目的是回答“概括地说,系统应该如何实现?”,总体设计又称为

概要设或初步设计。

17、模块的独立程度可以有两个定性标量度量:内聚和耦合。

18、软件测试的目标:(1测试是为了发现程序中的错误而执行程序的过程;(2好的

测试方案是极可能发现迄今为止尚未发现的错误的测试方案;(3成功的测试是发现可至今为止尚未发现的错误的测试。

19、软件测试步骤:模块测试、子系统测试、系统测试、验收测试、平行运行。

20、软件可靠性是程序在给定的时间点,按照规格说明书的规定,成功的运行的概率。

21、用面向对象方法开发软件,通常需要建立3种形式的模型:描述系统数据结构的对

象模型,描述系统控制结构的动态模型和描述系统功能的功能模型。

22、用面向对象方法开发软件,在任何情况下,对象模型始终都是最重要、最基本的、最核心的。

23、通常,使用UML提供的类图来建立对象模型。

24、类与类之间通常有关联、泛化(继承、依赖和细化等4种关系。

25、在UML中,在一段为空心的三角形的连线表示泛化关系。

26、复杂问题的对象模型通常由:主题层、类与对象层、结构层、属性层和服务层。

27、广义的说,软件重用可分为知识重用、方法和标准的重用、软件成分的重用。

28、工程网络和Gantt图同样是安排进度和管理工程进度情况的强有力的工具。29、3种典型人员组织方式:民主制程序员组、住程序员组、现代程序员组。30、软件过程的输出信息可以分为3类计算机程序、描述计算机程序的文档、数据,这

些项组成了软件过程中产生的全部信息,人们把他们统称为软件配置,而这些项就是软件配置项。

31、Cmm把软件过程从无序到有序的进化过程分成5个阶段,并把这些阶段排序,形

成五个逐层提高的等级。能力的成熟度的5个等级从低到高依次是:初始级(1级、可重复级(2级、已定义级(3级已管理级(4级和优化级(5级。

15、编码风格:持续内部文档、数据说明、语句构造、输入输出、效率、32、软件危机的典型表现:对软件开发成本和进度的估计常常很不准确;用户对“已完

成”的软件系统不满意的现象经常发生;软件产品质量往往靠不住;软件常常是不可维护的;软件通常没有适当的文档资料;软件成本在计算机总成本中所占的比例逐年上升;软件开发生产效率提高的速度,远远跟不上计算机应用迅速普及深入的趋势。

33、软件不同于硬件,他是计算机系统的逻辑部件而不是物理部件。

34、软件不同于一般程序,它的一个显著特点就是规模庞大。简单题

1、软件工程基本原理(1用分阶段的生存周期严格管理。(2坚持进行阶段评审。(3实行严格的产品控制。(4采用现代程序设计技术。(5结果应能清楚地审查。(6开发小组人员应该少而精。(7承认不断改进软件工程实践的必要性。

2、软件生命周期各阶段的基本任务软件生命周期由软件定义、软件开发和运行维护3个时期组成,每个时期又进一步划分成若干个阶段。(1问题定义(2可行性研究(3需求分析(4总体设计(5详细设计(6编码和单元测试(7综合测试(8软件维护

3、需求分析的任务

一、确定对系统的综合要求(1功能需求(2性能需求(3可靠性和可用性需求(4出错处理需求(5接口需求(6约束(7逆向需求(8将来可能提出的需求

二、分析系统的数据要求

三、导出系统的逻辑模型

四、修正系统开发计划

4、改进软件设计的启发式规则(1改进软件结构提高模块独立性(2模块规模应该适中(3深度、宽度、扇出和扇入都应适当(4模块的作用域应该在控制域之(5力争降低模块接口的复杂程度(6设计单入口单出口的模块(7模块功能应该可以预测

5、面向对象设计准则和启发式原则

(1模块化(2抽象(3信息隐藏(4弱耦合(5强内聚(6可重用

(1设计结果应该清晰易懂(2一般-特殊结构的深度应适当(3设计简单的类(4使用简单的协议(5使用简单的服务(6把设计变动减至最小

6、软件维护的几种类型

(1改正性维护(2适应性维护(3完善性维护(4预防性维护

7、决定软件可维护性因素

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

8、软件配置项

软件配置的主要任务就是控制变化,同时也负责各个软件配置项和软件各种版本的标志、软件配置审计以及软件配置发生的任何变化的报告。(1标识软件配置中的对象(2版本控制(3变化控制(4配置审计(5状态报告

设计题

1、等价类有效/无效数据边界值测试

2、UML类图的描述

3、N-S图、PAD图 论述题

(1软件工程(2可行性研究问题定义阶段必须回答的关键问题是:“要解决的问题是

什么”。如果不知道问题是什么就试图解决这个问题,显然是盲目的,只会自白浪费

时间和金钱,最终得出的结果很可能是毫无意义的。尽管确切地定义问题的必要性是十分明显的,但是在实践中它却可能是最容易被忽视的一个步骤。(3需求分析这个阶段的任务仍然不是具体地解决客户的问题,而是准确地回答“目标系统必须做什么”这个问题。(4总体设计这个阶段的基本任务是,概括地回答“怎样实现目标系统?”这个问题。概要设计又称为初步设计、逻辑设计、高层设计或总体设计。(5详细设计这个阶段的任务还不是编写程序,而是设计出程序的详细规格说明。这种规格说明的作用很类似于其他工程领域中工程师经常使用的工程蓝图,它们应该包含必要的细节,程序员可以根据它们写出实际的程序代码。(6编码实现(语言,测试这个阶段的关键任务是写出正确的容易理解、容易维护的程序模块。(7维护维护阶段的关键任务是,通过各种必要的维护活动使系统持久地满足用户的需要。

(8面向对象技术(9项目管理

1.软件工程学:为了更有效地开发与维护软件,软件工作者早20世纪60年代后期开始认真

研究消除软件危机的途径,从而逐渐形成了一门新兴的工程学科。2.软件危机典型变现:(1.对软件发开成本和进度的估计常常不准确.(2.用户对“已完成的”软件系统不满意的现象经常发生.(3.软件产品的质量往往靠不住.(4.软件常常是不可维护的.(5.软件通常没有适当的文档资料.(6.软件成本在计算机系统总成本中所占的比例逐年上升.(7.软件开发产生率提高的速度,远远跟不上计算机应用迅速普及深入的趋势.3.产生软件危机的原因:(1.软件不同于硬件,它是计算机系统中的逻辑部件而不是物理部件.(2.软件不同于一般程序,它的一个显著特点是规模庞大,而且程序复杂性将随着程序规模 的增加而呈指数上升.(3.软件本身独有的特点确实给开发和维护带来一些客观困难.(4与软件开发和维护有关的许多错误认识和做法形成,可以归因于在计算机系统发展的早

期阶段软件开发的个体特点.4.消除软件危机的途径:(1.应该对计算机软件有一个正确的认识.(2.充分认识到软件开发不是某种个体劳动的神秘技巧,而应该是组织良好、管理严密、各

类人员协同配合、共同完成的工程项目.(3.在使用要总结出成功的技术和方法,尽快消除错误概念和做法.(4.开发和使用更好的软件工具 5.软件工程的本质特性:(1.软件工程关注于大型程序的构造.(2.软件工程的中心课题是控制复杂性.(3.软件经常变化.(4.开发软件的效率非常重要.(5.和谐地合作是开发软件的关键.(6.软件必须有效地支持它的用户.(7.在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产

品.6.软件工程的原理:(1.用分段的生命周期计划严格管理.(2.坚持进行阶段评审.(3.实行严格的产品控制.(4.采用现代程序设计技术.(5.结果应能清楚地审查.(6.开发小组的人员应该少而精.(7.承认不断改进软件工程实践的必要性.7.软件生命周期:由软件定义、软件开发和运行维护3个时期组成,每个时期又进一步划分成若干个阶段.8.软件开发时期4个阶段:总体设计,详细设计,编码和单元测试,综合测试.9.软件维护,维护阶段的关键任务是,通过各种必要的维护活动使系统持久地满足用户的需要.10.瀑布模型的特点:(1.阶段间具有顺序性和依赖性.(2.推迟实现的观点.(3.质量保证的观点.11.快速原型模型:是快速建立起来的可以在计算机运行的程序,它所能完成的功能往往是最

终产品能完成的功能的一个子集.12.快速模型的主要优点是不带馈环的,软件产品基本上是线性顺序进行的.13.可行性研究的目的:用最小的代价在尽可能短的时间内确定问题是否能够解决.14.可行性的解法:(1技术可行性.(2经济可行性.(3操作可行性.15.可行性研究过程步骤:(1.复查系统规模和目标.(2.研究目前正在使用的系统.(3.导出新系统的高层逻辑模型.(4.进一步定义问题.(5.导出和评价供选择的解法.(6.推荐行动方针.(7.草拟开发计划.(8.书写文档提交审查.16.系统流程图:是概括地描绘物理系统的传统工具.它的基本思想是用图形符号以黑盒子形

式描绘组成系统的每个部件.17.数据流图(DFD:是一种图形化技术,它描绘信息流和数据从输入移动到输出的过程中所经

受的变换.18.数据字典:是关于数据的信息的集合,就是对数据流图中包括的所有元素的定义的集合.19.数据字典组成元素:(1数据流.(2数据流分量.(3数据存储.(4处理.20.定义数据的方法:定义绝大多数复杂事物的方法,都是用被定义的事物的成分的某种组合

表示这个事物,这些组成成分又由更底层的成分的组合来定义.21.数据字典最重要用途:作为分析阶段的工具。

22.为什么要进行需求分析:因为它的基本任务是准确地回答“系统必须做什么?”这个问

题。可行性研究阶段只是粗略了解用户的需求,许多细节被忽略,然而最终的系统中却不能遗漏任何细节。所以可行性研究并不能代替需求分析。

23.软件系统综合要求:(1功能需求.(2性能需求.(3可靠性和可行性需求.(4出错处理需求.(5 接口需求.(6约束.(7逆向需求.(8将来可能提出的要求.24.访谈:是最早开始使用的获取用户需求的技术,是迄今为止仍然广泛使用的需求分析技术.25.需求分析过程3种模型:数据模型、功能模型和行为模型.26.数据模型包含3种相互关联信息:数据对象、数据对象的属性及数据对象彼此间相互连接的关系.27.总体设计的目的:就是回答“概括地说,系统应该如何实现?”这个问题.28.总体设计两个过程:系统设计阶段,确定系统的具体实现方案;结构设计阶段,确定软件结

构.29.总体设计过程步骤:(1设想供选择的方案.(2选取合理的方案.(3推荐最佳方案.(4功能分

解.(5设计软件结构.(6设计数据库.(7制定测试计划.(8书写文档.(9审查和复查.30.模块化:就是把程序划分成独立命名且可独立访问的模块,每个模块完成一个子功能,把这

些模块集成起来构成一个整体,可以完成指定的功能满足用户的需求.31.怎做到模块独立:开发具有独立功能而且和其他模块之间没有过多的相互作用的模块.32模块独立两个定性标准度量:内聚和耦合.33.耦合:对一个软件结构内不同模块之间互连程度的度量.34.内聚:标志着一个模块各个元素彼此结合的紧密程度,它是信息隐藏和局部化概念的自然

扩展.35.功能内聚10分顺序内聚9分通信内聚7分过程内聚5分时间内聚3分逻辑内聚1 分偶然内聚0分

36.设计时要力争做到高内聚,低耦合.37.启发式规则介绍:(1.改进软件结构提高模块独立性.(2.模块规模应该适中.(3.深度、宽度、扇出和扇入都应适当.(4.模块的作用域应该在控制域之内.(5.力争降低模块接口的复杂程度.(6.设计单入口单出口的模块.(7.模块功能应该可以预测

38.交换流:信息沿输入通信路进入系统,同时由外部形式变换成内部形式,进入系统的信息通

过变换中心,经加工处理以后再沿输出路变成外部形式离开软件系统.39.事务流:数据沿输入通路到达一个处理T,这个处理根据输入数据的类型在若干个动作序列

中选出一个来执行.40.详细设计目标:确定应该怎样具体地实现所要求的系统.41.结构程序设计:如果一个程序的代码块仅仅通过顺序、选择和循环这3种基本控制结构进

行连接,并且每个代码只有一个入口和一个出口.42.实现:通常把编码和测试统称.43.编码:就是那软件设计结果翻译成用某种程序设计语言书写的程序.44.测试方法:黑盒测试(知产品的功能可测试和白盒测试(知产品内部工作过程可测试

45.测试步骤:(1模块测试.(2子系统测试.(3系统测试.(4验收测试.(5平行运行.46.测试重点:(1模块接口(2局部数据结构(3重要的执行通路(4出错处理通路(5边界条件.47.确认测试:也称验收测试,它的目标是验收软件的有效性.48.Alpha测试:由用户在开发者的场所进行,并且在开发者对用户的“指导”下进行测试.开发者

负责记录发现的错误和使用中遇到的问题.49.Beta测试:由软件的最终用户在一个或多个客户场所进行.与Alpha测试不同,开发者通常

不在Beta测试的现场,因此,Bate测试时软件在开发者不能控制的环境中的“真实”应用.50.调试:是在测试发现错误之后排除错误的过程.51.软件维护:就是在软件已经交付使用之后,为了改正错误或满足新的需要而修改的过程.52.改正性维护:诊断和改正错误的过程.53.决定软件维护性的因素:(1可理解性.(2可测试性.(3可修改性.(4可移植性.(5可重用性.54.用户文档:是用户了解系统的第一步,它应该能使用户获得对系统的准确的初步印象.55.用户文档包括的内容:(1功能描述(2安装文档(3使用手册(4参考手册(5操作员指南.56.系统文档:指从问题定义、需求说明到验收测试计划这样一系列和系统实现有关的文档.