软件工程知识点汇总（期末总复习）

自己复习总结完一轮软件工程后，得出结论，软件工程等于背书，所以把这个分享出来给其他的好兄弟，希望有所帮助。

 目录

第一章 软件工程概述

第二章 软件过程模型

第三章 需求分析

第四章 软件工程设计

第五章 软件生产率和工作量度量

第七章 测试技术（25）

第八章 软件测试策略

第九章 软件维护

第十章 软件项目管理

第一章 软件工程概述

软件的定义 软件=程序+数据+文档

软件的特性：软件是逻辑的，不是物理的

软件的双重作用：软件是一种产品，也是开发其他软件产品的工具

软件危机的定义：在计算机软件开发和维护过程中所遇到的一系列严重问题 特点：周期长、成本高、质量差、维护难

软件危机产生的原因：客观： 软件本身的特点（逻辑思维产物、规模庞大） 主观：不正确的开发方法（忽视需求分析；错误认为软件开发=程序编写；轻视软件维护）

软件工程的目标是在给定的时间和预算内，按照用户的需求，开发易修改、高效、可靠、可维护、适应力强、可移动、可重用的软件。

软件工程的三要素：方法、工具、过程

软件工程的七个原则：使用阶段性生命周期计划的管理

 进行连续的验证

 保证严格的产品控制

 使用现代编程工具/工程实践

 保持清晰的责任分配

 用更好更少的人

 保持过程改进

第二章 软件过程模型

软件质量是软件工程的焦点

软件过程模型是软件开发全部过程、活动和任务的结构框架。它能直观表达软件开发全过程，明确规定要完成的主要活动、任务和开发策略。

基本软件过程：沟通、计划、建模、构造、部署 过程性质（时间性、并发性、嵌套性、质量性）

软件过程模型也常称为：软件开发模型、软件生存周期模型、软件工程范型

随着认识的深入，需求是不断变化的，需求的理解需要迭代进行，需要管理修改变更

软件工程最核心内容，设计既是“过程”，也是这个过程的“结果”

各个模型的使用场合：

瀑布模型：瀑布模型适用于系统需求明确、技术成熟、工程管理较严格的场合

快速原型模型：构建原型系统让用户试用，获取用户真实需求。

增量模型 ：模块化。能在早期向用户提交部分产品和易于维护，软件的体系结构必须是开放的。

螺旋模型：支持需求不明确、特别是大型软件系统的开发，分析风险和排除风险。

传统瀑布模型特点：1.阶段间具有顺序性和依赖性 2.推迟实现的观点 3.每个阶段必须完成规定的文档每个阶段结束前完成文档审查，及早改正错误

瀑布模型的优点：1.简单，过程透明性高，过程可管理性高；2.推迟实现，软件实现前必须进行系统分析和设计工作；3.能够及时发现并纠正软件缺陷，能够达到预期质量要求 瀑布模型的缺点：1.模型灵活性差，不适合需求不明确或准确的场合；2. 模型风险控制能力弱；3.过多的文档增加了工作量，当技术具有不确定性情况下完全以文档来评估项目进度时会产生错误的结论

原型模型优点：

 强调用户参与和决策，强化了用户与开发人员的沟通

 可加快需求的确定，能够处理需求的不确定性和风险

 简化了项目管理、缩短了开发时间、降低了风险和开发成本

原型模型缺点：

 不适用于开发大型系统

 软件可维护性差

 用户合作要求高，如果合作不好，反而会拖延开发进度

增量模型结合了原型模型的基本要素和迭代的特征，采用了基于时间的线性序列

增量模型特点：在前面增量的基础上开发后面的增量

 每个增量的开发可用瀑布或快速原型模型

 迭代的思路

增量模型优点

1. 引入增量包概念，不需要提供完整的需求。只要有一个增量包出现，开发就可以进行。

2. 在项目的初始阶段不需要投入太多的人力资源。

3.增量可以有效地管理技术风险，降低系统失败风险。

4. 有利于增加客户信心，提高系统可靠性、可维护性和稳定性。

增量模型缺点

1.增量粒度难以选择：每个增量必须提供一些系统功能，这使得开发者很难根据客户需求给出大小适合的增量。

2. 确定所有的基本业务比较困难。

大型软件项目特点

 需求复杂，无法一开始明确

 开发周期长，需求经常变化

 风险因素多，风险管理要求高

螺旋模型优点

 支持用户需求的动态变化。

 易于用户和开发人员共同理解

 螺旋模型特别强调原型的可扩充性和可修改性，原型的进化贯穿整个软件生存周期，这将有助于目标软件的适应能力

 螺旋模型为项目管理人员及时调整管理决策提供了方便，进而可降低开发风险

螺旋模型缺点

如果迭代的效率不高，致使迭代次数过多，将会增加成本并推迟提交时间；

使用该模型要求开发队伍水平较高

如何选择过程模型：

 软件开发模型是不断发展的

 各种软件开发模型各有优缺点

 选用时不必拘泥与某种模型

软件工程是以质量为中心，过程、方法和工具为三要素

过程和产品的关系：软件过程决定了软件产品的质量

能力成熟度模型的五个成熟度等级（括号里面是级别的侧重点）：

1.初始级（有能力的人和个人英雄主义）

2.可重复级（基本项目管理）

3.已定义级（过程标准化）

4.量化管理级（量化管理）

5.优化级（持续的过程改进）

第三章 需求分析

需求分析的定义：1.软件需求表达了对解决现实世界中某类问题的产品的要求和约束

2.确定系统必须具有的功能和性能，系统要求的运行环境，并且预测系统发展的前景

3.需求就是以一种清晰、简洁、一致且无二义性的方式，对一个待开发系统中各个有意义方面的陈述的一个集合

需求的特质：可验证、可量化、优先级

功能性需求和非功能性需求： 非功能性需求可以进一步被分为性能要求、可维护性要求、安全需求、可靠性要求、可移植性要求

业务要求与需求的区别和联系

 通过启发、引导，从客户（或用户）那里得到的原始需求是他们的业务要求（Needs），简称为N。这是分析之前获取的需求，其中可能存在一些实际问题。这些问题只有通过分析才能得到解决，直接把获取的需求作为软件设计阶段的依据将会导致严重的后果

需求获取面临的挑战：

 系统的目标或范围问题

 需求不准确性问题

 需求的易变问题

需求分析的四个步骤：

1.需求获取（定义）：软件需求的来源以及软件工程师收集这些软件需求的方法 （需求获取非常困难）

2.需求提炼（定义）： 产生操作规格参数表，指明与其他系统元件的软件接口，确定软件必须遵循的约束

3.需求描述（定义）：撰写需求规格说明书

4.需求检验（定义）：检查需求的正确性、完整性、非二义性、内部和外部的连贯性

需求分析的核心在于建立分析模型 需求分析的特点：多样性

结构化分析方法的分析策略是自顶向下逐步求精

需求变更的必要性：需求总是在变化

结构化分析模型

 数据流图、实体-关系图（ER图）、状态转换图、数据字典

 加工规格说明、控制规格说明、数据对象描述

面向对象分析模型

 用例模型，对象模型，交互模型

需求验证的重要性：

如果在后续的开发或当系统投入使用时才发现需求文档中的错误，就会导致更大代价的返工。由需求问题而对系统做变更的成本比修改设计或代码错误的成本要大的多。

需求验证即检查需求的正确性、完整性、非二义性、内部和外部的连贯性。

需求工程包括需求开发和需求管理

软件需求贯穿于软件工程的整个生命周期

软件需求：用户对目标软件系统在功能、行为、**性能、设计约束等方面的期望。**

需求分析的任务建立需求分析模型和编写需求说*明。**

子功能的数量并不是越多越好，要恰当

在ER图中用椭圆或圆角矩形表示属性，并用无向边将属性与相关的数据对象连接在一起

状态可能有：初态、终态和中间态

建立决策表的步骤

(1) 列出与一个具体过程（或模块）有关的所有处理

(2) 列出过程执行期间的所有条件（或所有判断）

(3) 将特定条件取值组合与特定的处理相匹配，消去不可能**发生的条件取值组合**

(4) 将右部每一纵列规定为一个处理规则，即对于某一条件**取值组合将有什么动作**

UML模型由事物、关系和图组成

面向对象分析的3个模型：用例模型、对象模型、动态模型

包含关系以指向被包含用例的**虚线箭头表示**

扩展关系以**指向基础用例的虚线箭头表示**

用例建模往往不是一次就能完成的**，需要多次迭代、逐步完善**

对象模型由五个层次构成：主题层、类-对象层、结构层、属性层、服务层

第四章 软件工程设计

**软件设计定义为软件的架构、构件、接口和其他特性的定义过程及该过程的结果**

软件设计师进行软件编码的基础；是连接用户需求和软件技术的桥梁

软件设计包含两类活动：软件架构设计、软件详细设计 创新设计不属于软件设计

软件质量可以通过质量属性来描述：质量属性包括 功能性、易用性、可靠性、性能、可支持性

功能独立的好处：易于开发：功能被划分，接口被简化 ； 易于维护（和测试）：次生影响有限，错误传递减少，模块重用

模块化为什么不能无限划分模块：当模块数量增多之后，虽然模块成本降低了，但是他的集成成本上升了，导致总成本上升，所以不能无限划分

信息隐藏原则的定义：模块应该具有彼此相互隐藏的特性

重构的定义：  不改变组件功能和行为条件下简化组件设计（或代码）的一种重组技术

•在程序组件层面，数据结构和相关算法的设计是构建高质量应用程序的根本

• 在程序应用层面，将数据模型（作为需求工程的一部分）转换成数据库也是尤为重要的

• 在业务层面，将存储在不同数据库的信息进行收集并重组成“数据仓库”可以实现数据挖掘、知识发现，这将对业务成功产生重要影响

信息隐蔽原则有利于提高模块的内聚性

数据存储（如文件或数据库）是整个架构的中心**，经常被其他组件访问，如更新、添加、删除、修改存储数据**

客户端软件访问数据中心，*各客户端软件操作的**数据相互独立，某个客户端软件操作的数据不会受其他客户端软件的操作影响**

与此方法相对的是将数据库转化为多个客户端软**件共享的“黑板”，当某个客户端软件修改数据时就向感兴趣的客户端软件发送通知**

体系结构风格内容包括：一组构件、一组连接件、约束、语义模型、框架

C/S体系结构将整个系统分成表示层、应用逻辑层（应用系统的主体部分）、数据层

B/S**体系结构具有以下优点：

（1）基于B/S体系结构的软件，系统安装、修改和维护全在服务器端解决

（2）B/S体系结构提供了异种机、异种网、异种应用服务的联机、联网和统一服务的最现实的开放性基础

C/S体系（客户机/服务器） vs B/S体系（浏览器/服务器）：

（1）功能：B/S体系结构缺乏对动态页面的支持能力，没有集成有效的数据库处理功能**

（2）响应速度：采用B/S体系结构的应用系统，在数据查询等响应速度上，要远远地低于C/S体系结构

（3）动态特性：B/S体系结构的数据提交一般以页面为单位，数据的动态交互性不强，不利于在线事务处理（OLTP）应用

高效用户界面设计有三条重要原则：

 用户控制系统 （用户为中心）

 减少用户记忆负担

 保持界面一致

人机交互的设计准则：

一致性、操作步骤少、不要“哑播放”、提供Undo功能、减少人脑记忆负担、提高学习效率

设计是软件工程技术核心

 数据结构、体系结构、接口和软件组件的过程细节在设计中逐步细化、开发、评审和记录

 模块化（包括程序和数据）和抽象概念能够使设计人员简化和重用软件组件

 细化提供了详细表示各顺序功能层的机制

 程序和数据结构有助于建立软件架构的整体视图，而过程提供了算法实现必要的细节

 信息隐藏和功能独立为实现有效模块化提供了启发

第五章 软件生产率和工作量度量

过高估计危害：给的时间多，工作花费时间也越多；当人数增加后，项目所需的时间不成比例地减少

过低估计危害：质量降低；可靠性零法则

基于代码行数的度量方法的**优点**

 LOC、KLOC和相关度量容易计算

 许多现有的软件估算模型都使用LOC和KLOC作为一项重要输入

 有大量的关于LOC的文献和数据

 基于代码行数的度量方法的**缺点**

 LOC依赖于使用的语言，这对短小精悍的程序不利

 不太适用于非过程化语言

 LOC是由在设计完成时候才能计算，估算需要一定程度的细节，而这些细节可能很难获得，例如，项目计划人员难于在分析和设计完成之前估算LOC

代码行数和功能点之间的关系依赖于编程语言

功能点度量的优点： 软件系统的功能与实现该软件系统的语言无关； 在软件开发的早期阶段（如需求分析）就可通过对用户需求的理解获得软件系统的功能点数目，因而该方法可以较好地克服基于代码行的软件项目规模表示方法的不足。 功能点度量的缺点： 功能点计算主要靠经验公式，主观因素比较多； 没有直接涉及算法的复杂度，不适合算法比较复杂的软件系统； 计算功能点所需的数据不好采集。

第七章 测试技术（25）

软件缺陷：未完成、有错误、画蛇添足（产品说明书中未提到的功能）、隐含需求未实现、不好用

软件测试的目标：尽早找出软件缺陷，并确保缺陷得以修复

软件缺陷特征：看不到，看到但抓不到

可靠性与质量区别：可靠性只是质量的一个方面，甚至不一定是最决定性的 个方面是最决定性的一个方面

软件调试与测试：

相同点：都包含有处理软件缺陷和查看代码的过程

不同点：测试的目标是发现软件缺陷的存在；调试的目标是定位与修复缺陷

测试用例（test case）是测试输入、执行条件，以及预期结果的集合，是为特定的目的开发的

软件测试的基本原则：

1.穷尽测试时不可能的；2.测试无法显示潜在的软件缺陷；3.测试活动应尽早进行；4.软件缺陷具有群聚性；5.注意杀虫剂现象；应尽量由独立的测试团队进行测试

软件质量保证人员的主要职责：

创建和执行改进软件开发过程并防止软件缺陷发送的标准和方法

软件测试的目标：

1.确认系统满足其预期的使用和用户的需要。

2.确认解决了所需解决的问题

3.为测试的过程建立责任和可解释性

4.便于及早发现软件和系统的异常

5.及早提供软件和系统的性能评估

6.为管理提供真实信息，以决定在当前状态下发布产品在商业上的风险

7.鉴别出程序在功能等方面的异常聚集之处

软件测试的评估准则：覆盖率、故障插入、变异分值

覆盖率=测试集合T/测试需求集合TR

软件测试的主要方法：

 黑盒测试指忽略系统或组件的内部机制，仅关注于那些特定输入响应及相应执行条件的输出测试，也称功能性测试

白盒测试指考虑系统或组件内部机制的测试（如分支测试、路径测试、语句测试等），也称结构性测试

灰盒测试 黑盒和白盒测试混合方法

基本路径测试基本步骤：

 (1)程序环路复杂性

 (2)确定线性独立路径的基本集合

 (3)为基本集合中每条路径生成测试用例

黑盒测试方法：等价类划分、边界值分析、状态测试

等价类划分：把所有可能输入的数据划分成若干部分，然后从每一部分中选取少数有代表的数据作为测试用例

边界值分析：是对输入或输出的边界值进行测试

状态测试：一种基于模型的测试，是指用状态图来描述时间序列由此产生测试用例

静态测试的作用：通过对代码标准及质量的监控提高代码可靠性

 尽可能早地通过对源代码的检查发现缺陷

 组织代码审核定位易产生错误的模块

静态分析类型：同事审查、走查、审查

第八章 软件测试策略

回归测试可以在所有的测试级别执行，并应用于功能和非功能测试中

回归测试应该尽量采用自动化测试

回归测试的范围：缺陷再测试；功能改变的测试；新功能测试；完全回归测试

缺陷再测试：重新运行所有发现故障的测试

功能改变的测试：测试所有修改或修正过的程序部分

新功能测试：测试所有新集成的程序

完全回归测试：测试整个系统

回归测试标准：只重复测试计划中的高优先级测试

功能测试中，忽略特定的变化

只针对特定配置进行测试

只针对特定子系统或测试级别进行测试

单元测试的主要内容：出错处理、独立路径、边界条件、局部数据结构、模块接口

集成测试的主要方法：自顶向下的集成方法；自底向上的集成方法；SMOKE方法

自顶向下的集成方法的优点

 测试过程中较早地验证了主要的控制和判断点

 选用按深度方向集成的方式，可以首先实现和 验证一个完整的软件功能

自顶向下的集成方法的缺点：桩的开发量较大

自底向上的集成方法的优点：每个底层模块都已经测试，不需要桩模块

缺点：每个模块都必须编写驱动模块；缺陷的隔离和定位不如自顶向下

SMOKE方法优点 ：节省测试时间 ，防止构造失败

SMOKE方法缺点：覆盖率比较低

第九章 软件维护

需要维护的原因：改正程序中的错误和缺陷。

2）改进设计以适应新的软、硬件环境。

3）增加新的应用范围

维护类型：纠错性维护；完善性维护；改正性维护；预防性维护；适应性维护

完善性维护占维护比例的一半（最高）；大部分维护工作是改变和加强软件，而不是纠错

完善性维护 是有计划、有预谋的一种再开发活动

软件维护活动所花费的工作占整个生存期工作量的70%以上

软件维护的代价是降低了生产率

影响维护工作量的因素：

❖系统大小

❖程序设计语言

❖系统年龄

❖数据库技术的应用

❖结构化的软件开发技术

软件的困难性：

1、配置管理工作不到位

2、人员变动造成的影响

3、许多软件的可读性差

4、任务紧、时间急的情况下处理维护请求

适应性维护不可避免，但是可以控制

衡量程序的可维护性：可理解性 ；可使用性；可测试性 ；可移植性；可修改性 ；效率；可靠性

恢复信息的级别：实现级、结构级、领域级、功能级

第十章 软件项目管理

项目管理集中在：人员，产品，过程，项目

团队组织形式：民主分权制、有控制的分权制、有控制的集中制

项目的特征：

有明确的目标

❖有生命周期，可能是一次性的，可能是独一无**二的**

❖项目任务可分解

❖有明确的客户

❖需要多种资源

❖有不确定因素

希望对各位复习考试的同学有所帮助！

---