软件工程期末复习

软件工程期末复习

by zetazero 2024.11.19

0.软件工程相关知识点

• 什么是好软件
  • 用户角度：1.软件符合指定需求 2.软件几乎没有缺陷软件性能正常 3.软件容易上手，操作方便
  • 开发人员角度：1.代码可测试性 代码可维护性 代码可读性 2.代码效率：高效管理资源 3.代码安全：可预防常见威胁
  • 投资者角度：1.软件按时交付 2.软件满足预算 3.可复用的开发过程，确保交付质量
• 软件工程的通用框架：沟通 策划 建模 构建 部署
• David Hooker的7个关注软件工程整体实践的原则：
  • 存在价值 保持简洁 保持愿景 关注使用者 面向未来 提前计划复用 认真思考
• 软件工程师特质：
  • 1.良好的沟通能力 2.掌握比较全面的专业技术 3.充分的自信心 4.足够的耐心和责任感 5.要具备怀疑精神和学习能力 6.超强记忆力和洞察力
• 假故⾃⼰被指派作为⼀个⼤型软件产品公司的项⽬负责⼈ ⼯作负责公司已被⼴泛应⽤的⽂字处理教件的新版本开发及管理 由于市场竞争微烈 公司规定了严格的完成期限 结合你所学习的软件⼯程的原理⽅法和技术阐述你该如何开展⼯作 (从计划 软件过程 项⽬组织 进度计划及质量管理 产品维护等⽅⾯考虑)
  
• 面向数据流的分析建模中处于核心地位的是数据字典
• **桩模块**可以代替尚未测试过的下层模块------专供测试用的“假”模块称为被测模块的桩模块
• **配置管理**是对软件修改进行标识 组织和控制的技术 用来协调和控制整个系统工程
• 软件工程三要素 ：方法 工具 过程
• 软件=程序+文档 或 程序+数据+文档
• 程序的效率：程序的执行速度 程序占用的存储空间
• 软件需求的主要工作内容有需求的获取 需求建模 需求评审
• 软件设计的基本原则：抽象与逐步求精 模块化 信息隐藏 关注点分离
• 软件体系结构包括 组件 连接件 约束
• 常用的调试方法有 原始法 回溯法 排除法
• 软件维护有 纠错性维护 适应性维护 完善性维护 预防性维护
• 面向数据流的设计方法把数据流图映射成软件结构
• 可行性研究主要从技术可行性 经济可行性 操作可行性方面研究
• 数据字典是软件需求分析阶段的最重要工具之一，其最基本的功能是数据定义
• 软件工程的主要任务不是写程序
• 当软件验收测试通过 软件开发不是就完成了
• 什么是软件
  • 1.软件是与计算机系统操作有关的程序 2.规程 规则 及任何与之有关的⽂档 3.数据的完整集合
• 什么是软件过程
  • 1.软件过程是为了获得⾼质量软件产品所需要完成的⼀系列任务的框架 2.它规定了完成各项任务的⼯作步骤
• 简述软件项⽬管理主要任务
  • 1.制定软件项⽬的实施计划和⽅案 2.对⼈员进⾏组织和分⼯ 3.按照计划进度 以及成本管理 ⻛险管理 质量管理的要求进⾏软件开发 完成软件项⽬的各项要求和任务
• 软件⼯程的基本活动有哪些
  • 需求 设计 实现 确认 ⽀持
• 结构化的需求分析模型由什么组成
  • 数据字典 和实体⼀关系图 数据流图 状态⼀变迁图 及相关描述说明
• 结构化设计⽅法将数据流图转换为软件结构的步骤有哪些
  • 1.确定信息流的类型 2.划定流界 3.将数据流图映射为程序结构 4.提取层次控制结构 5.通过设计复审和启发式策略精化结构
• 系统测试包含哪些测试
  • 恢复测试 安全性测试 强度测试 性能测试
• 什么是⽤例
• 从外部⽤户的视⻆看⼀个⽤例是主⻆ actor 与⽬标软件系统之间⼀次典型的交互作⽤
• 从软件系统内部的视⻆出发 ⼀个⽤例代表着系统执⾏的⼀系列动作 动作执⾏的结果能够被外部的主⻆所察觉
• 简述边界类的主要任务
• 界⾯控制 外部接回 环境隔离
• 简述软件维护的分类
• 改正性维护 适应性维护 改善性维护 预防性维护
• 关于模块间耦合关系我们的设计标准是什么
  • 1.设计软件时应尽量使⽤教据耦合 2.減少控制耦合 3.外部环境耦合和公共数据耦合 4.杜绝内容耦合
• 什么是软件⼯程 软件⼯程的三要素是什么
• 是⽤⼯程 科学和数学的原则与⽅法研制 维护计算机软件有关技术及管理⽅法
• 软件⼯程的三要素是 ⽅法 ⼯具和过程
• 什么是模块独⽴性
• 是指软件系统中每个模块只涉及软件要求的具体的⼦功能⽽和软件系统中其它的模块的接⼝是简单的
• 软件测试过程中主要有哪⼏种测试活动
• 单元测试 集成测试 确认测试 和系统测试
• 什么是改正性维护和改善性维护
• 改正性维护是为诊断和改正软件系统中潜藏的错误⽽进⾏的活动
• 改善性维护是根据⽤户在使⽤过程中提出的⼀些建设性意⻅⽽进⾏的维护活动
• 简述 UML 中消息种类
  • 简单消息 同步消息 异步消息 返回消息
• 简述控制类的主要任务
• 作为完成⽤例任务的责任承担者 协调 控制其他类共同完成⽤例规定的功能或行为

1.

黑盒测试，黑盒测试又称为功能测试/数据驱动测试

黑盒测试是将测试对象看做一个黑盒，在并不考虑软件产品的内部结构和处理过程的基础上 只依据程序的需求规格说明书 对软件产品进行功能测试。黑盒测试注重软件产品的功能性需求

运用黑盒技术设计测试用例常用的方法有：
① 等价类划分

② 边界值分析
③ 分析法
④ 错误推断法 等

黑盒测试可以发现以下类型错误：

• 不正确或遗漏的功能
• 接口错误
• 数据结构或外部数据库访问错误
• 行为或性能错误
• 初始化和终止错误

2.

白盒测试又称结构测试/透明盒测试/逻辑驱动测试/基于代码的测试

白盒测试时对软件的过程性细节作细致的检查 这一方法是对测试对象看作一个打开的盒子 他允许测试人员利用程序内部的逻辑结构及有关信息 设计或选择测试用例 对程序的所有逻辑路径进行测试

利用白盒测试方法导出 的测试用例：
①保证一个模块中的所有路径至少被执行一次
②对所有的逻辑判定均需测试取真和取假两方面
③在上下边界及可操作的范围内执行所有循环;据结构以确保其有效性

白盒测试方法：（强度由低到高）

• 语句覆盖

  • 程序中的每个可执行语句至少被执行一次

• 判定覆盖

  • 程序中每个判断的取真分支和取假分支至少经历一次，即判断真假值均被满足

• 条件覆盖

  • 每个判断中每个条件的可能取值至少满足一次

• 判定条件覆盖

  • 判断条件中的所有条件可能取值至少执行一次，同时所有判断的可能结果至少执行一次

• 条件组合覆盖

  • 判断中每个条件的所有可能取值组合至少执行一次，并且每个判断本身的结果也至少执行一次

• 路径覆盖

  • 覆盖程序中的所有可能的执行路径

黑盒测试与白盒测试的区别：

3.敏捷开发

最适合采用增量模型

敏捷开发方法以原型开发思想为基础，采用迭代增量式开发，发行版本小型化，比较适合需求变化较大或者开发前期对需求不是很清晰的项目

敏捷团队：小型的并充满动力的项目团队
极限编程是敏捷软件开发使用最广泛的一个方法 XP(极限编程)的四大核心价值观是：沟通、简单、反馈、勇气

4.流图/程序图

环复杂性：V(G)=边数-结点数+2 = 路径数量
路径是贯穿程序的且引入新边

4.

• 数据流图的类型有：变换型 事务型

• 每个加工至少有一个输入数据流和一个输出数据流。

• 在整套分层数据流图中，每个数据存储应至少有一个加工对其进行读操作。另一个加工对其进行写操作，对于某一张DFD来说，可以只写不读或只读不写。

• 分层数据流图中，每个数据流和文件都必须命名 名字反应整个对象 而不是部分；避免使用空洞、含义不清的名字

• 数据流：名词或形容词+名词；

• 加工：动词或动宾

• 数据存储：名词

• 外部实体：可以用实际的人或组织的名称来命名

5.瀑布模型

• 定义：瀑布模型又称为经典生命周期，它提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建和部署的过程，最终提供完整的软件支持

• 优点：

  • 1.可强迫开发人员采用规范的方法 2.严格的规定了每个阶段必须提交的文档 3.要求每个阶段交出的所有产品都必须经过质量保证小组的验证

• 缺点：

  • 1.由于瀑布模型几乎完全依赖于书面的规格说明 很可能导致最终开发出的软件产品不能真正满足用户的需求
  • 2.开发周期长 3.前期不能出错 4.瀑布模型只适用于项目开始时需求已确定的情况

6.增量模型

增量模型就是经历n个增量(每个增量都包含 沟通 策划 建模 构建 部署) 每做完一个增量就交付一次产品

• 优点
  • 1.在达到初始需求之前可降低成本 2.可快速生产出可使用的系统 3.能够有计划地管理技术风险
• 缺点
  • 增量模型的灵活性可以使其适应这种变化的能力大大优于瀑布模型和快速原型模型，但也很容易退化为边做边改模型，导致软件过程的控制失去整体性

7.演化过程模型

需求不断变化
原型开发：只定义基本任务 没有详细定理功能和特性需求

8.螺旋模型

定义：螺旋模型是一种风险驱动型的过程模型生成器 对于软件集中的系统 它可以指导多个利益相关者的协同工作

只适用大型软件

螺旋模型是的模型。它兼顾了的迭代的特征以及的系统化与严格监控。螺旋模型最大的特点在于引入了其他模型不具备的，使软件在无法排除重大风险时有机会停止，以减小损失。同时，在每个迭代阶段构建原型是螺旋模型用以减小风险的途径。螺旋模型更适合大型的昂贵的系统级的软件应用。

优势：1.结合了原型的迭代性质和瀑布模型的系统性和可控性的特点
2.强调风险
3.强调阶段质量
4.提供纠错的机会
5.提供原型作为风险降低机制
6.进一步使开发人员能够在产品演变的任何阶段应用原型方法

缺点：1.每个阶段都要提出备选方案 进行风险分析 研发周期长 效率低 2.必须要专业的风险分析人员的参与 3.如果没有发现和管理重大风险 问题无疑将会发生

9.原型模型

允许在需求分析阶段对软件的需求进行初步而非完全的分析和定义 快速设计开发出软件系统的原型 该原型向用户展示待开发软件的全部或部分功能和性能

适用场景：适用于小型和中等规模的交互式系统、大型系统的某些部分，例如用户界面、生命周期短的系统

优点：1.有助于满足用户的真实需求
2.原型系统已经通过与用户的交互而得到验证 据此产生的规格说明文档能够正确的描述用户需求
3.软件产品的开发基本上是按线性顺序进行
4.缩短了开发周期 节约开发成本

缺点：1.为了尽快完成软件 开发者没有考虑整体软件质量和长期的可维护性
2.为了使一个原型快速运行起来 往往在实现过程中采用折中的手段

9.原型化方法

• 原型化方法用于解决什么问题(其实也就是原型模型适用于哪些项目)
  • 原型法具有较⼤的灵活性 适合于软件需求不明确 设计⽅案有⼀定⻛险的软件项⽬
• 优点：其主要优点是能统⼀客户和开发⼈员对软件项⽬需求的理解 有助于需求的定义和确认

10.

• UML：统一建模语言

• 协作图与时序图同构的

类图

类图中常见的关系：
1.泛化

• 【泛化关系】是一种继承关系，表示子类继承父类的所有特征和行为。
• 【箭头指向】带三角箭头的实线，箭头指向父类。

2.实现

• 【实现关系】是一种类与接口的关系，表示类是接口所有特征和行为的实现。
• 【箭头指向】带三角箭头的虚线，箭头指向接口。

3.关联

• 【关联关系】是一种拥有关系，它使得一个类知道另一个类的属性和方法。
• 【代码体现】成员变量
• 【箭头指向】带普通箭头的实线，指向被拥有者。双向的关联可以有两个箭头，或者没有箭头。单向的关联有一个箭头。

4.聚合

• 聚合关系】是一种整体与部分的关系。且部分可以离开整体而单独存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
• 【代码体现】成员变量
• 【箭头指向】带空心菱形的实线，空心菱形指向整体。

5.组合

• 【组合关系】是一种整体与部分的关系。但部分不能离开整体而单独存在，组合关系是关联关系的一种，是比聚合关系还要强的关系。
• 【代码体现】成员变量
• 【箭头指向】带实心菱形的实线，实心菱形指向整体。

6.依赖

• 【依赖关系】是一种使用关系，即一个类的实现需要另一个类的协助。
• 【箭头指向】带普通箭头的虚线，普通箭头指向被使用者。

用例图

• 【概念】用例图是指由参与者、用例，边界以及它们之间的关系构成的用于描述系统功能的视图。
• 【目的】用来描述整个系统的功能。
• 用例是一个系统的动作 动词

用例图中包含以下三种关系：

• 包含关系使用符号<>，基本用例虚线指向包含用例。

  • 包含的几种功能可以同时进行

• 扩展关系使用符号<>，扩展用例虚线指向基础用例。

  • 扩展是需要满足特定条件才会触发，比如找回密码，在登陆时只有你选择了才会触发

• 泛化关系，子用例继承父用例所有结构、行为和关系。子用例实现箭头指向父用例。

  • 泛化的几个功能，只能选择其一

用例规约

• 定义：是用于描述用例的详细行为和功能的文档，它是用例图的补充

• 用例名称：指明用例的名称和标识符，用于标示该用例。

  参与者：列出参与该用例的外部角色，如用户、系统或其他实体。

  前置条件：描述执行该用例前需要满足的条件或状态。

  主事件流：该操作成功情况下系统所做的事情

  辅事件流：操作不成功情况系统做的事情

时序图/顺序图

泳道图
泳道图按角色划分为一个个泳道，每个角色的活动散落在各个角色对应的泳道里。泳道图是将模型中的活动按照职责组织起来。这种分配可以通过将活动组织成用线分开的不同区域来表示。由于它们的外观的缘故，这些区域被称作泳道。

11.CRC

1.首先构成相似现实对象的类；2.明确此类应该知道或者应该做的职责；3.找出在此类实现职责过程中产生相互作用的其他类作为协作者。

12.体系结构

定义：程序或计算系统的软件体系结构是指系统的一个或者多个结构 它包括软件构件，构件的外部可见属性以及它们之间的相互关系

体系结构需考虑要素：经济性 易见性 隔离性 对称性 应急性

• 以数据为中心的体系结构

• C/S为中心的体系结构

• 组件结构(构件结构)
  • 方块里面写各个功能模块

• 整体体系结构

13.黄金规则

界面设计的三条黄金规则：

• 把控制权交给用户
• 减轻用户的记忆负担
• 保持界面一致

14.可行性研究

目的：可行性研究的目的就是用最小的代价在尽可能短的时间内确定问题是否能够解决。

实质：可行性研究的实质就是要进行一次压缩、简化了的系统分析和设计的过程。

可行性研究需要的时间长短取决于系统的规模，可行性研究的成本只是预期工程总成本的5-10%

15.α测试和β测试

• α试是在开发者的场所由⽤户进⾏ 在开发者关注和控制的环境下进⾏
• β 测试是最终⽤户在⾃⼰的场所进⾏

16.需求

• 什么是需求

  • ⽤户对⽬标软件系统在**功能 ⾏为 性能 设计约束** 等⽅⾯的期望

• 需求工程包括七项任务：起始 获取 细化 协商 规格说明 确认 和 管理

• 需求建模的两种方法：结构化分析方法 面向对象分析

• 功能需求和非功能需求

  • 功能需求：描述系统必须提供的功能和服务，通常涉及系统应具备的具体功能和特性
  • 非功能需求：描述系统在性能、可靠性、可用性、安全性、效率等方面的要求，不直接涉及具体功能，而是关注系统如何执行这些功能

• 约束性需求(非功能性需求)

  • 描述了系统的质量属性、性能要求、安全性、可用性等方面的约束条件，而不仅仅是系统需要完成哪些功能。约束性需求并不关注系统要做什么，而是系统如何做

• 质量需求

  • 通常涉及系统的性能、可用性、安全性等方面的要求，如响应时间、吞吐量、可扩展性等

• 需求评审程序员和销售人员不必参加

• 软件需求分析阶段的任务是什么

• 软件需求分析阶段的任务是：1.通过对问题及环境的理解 分析 2.将⽤户需求精确化 完全化 最终形成需求规格说明 3.描述系统信息 功能和⾏为

17.RUP

• ，是一个且基于网络的程序开发方
• RUP是风险驱动的、基于Use Case技术的、以架构为中心的、迭代的、可配置的软件开发流程。
• RUP描述了如何有效地利用商业的可靠的方法开发和部署软件，是一种重量级过程（也被称作厚方法学），因此特别适用于大型软件团队开发大型项目
• 核心工作流
  • 1.商业建模 2.需求 3.分析和设计 4.实现 5.测试 6.部署 7.配置和变更管理 8.项目管理 9.环境

18.软件危机

• 定义：软件危机是指落后的软件生产方式无法满足迅速增长的计算机软件需求 从而导致软件开发和维护过程中所遇到的一系列严重问题
• 软件危机的表现
  • 1.产品不能符合用户的实际需求 2.软件开发的效率低 3.软件产品的质量低 4.软件开发成本和进度的估算不准确 5.软件维护性差 6.软件开发文档不全不合格
• 软件危机产生的主要原因
  • ⽤户对软件需求的描述经常出现⼆义性 不确定性 遗漏或者错误等
  • 开发⼈员对⽤户需求的理解与⽤户本来的愿望有差异
  • ⼤型项⽬需要组织⼀定的⼈⼒共同完成 多数管理⼈员缺乏开发⼤型软件的经验 同时⼜缺乏管理经验
  • 开发⼈员素质与经验不足
  • 缺乏有⼒的的⽅法学和⼯具⽀持 过分地依赖程序员的技巧和创造性 加固软件个性化
  • 软件产品的特殊性和⼈类智⼒的局限性 使⼈们处理复杂问题困难重重

19.模块内聚性

偶然内聚性的内聚程度最低
为了提高模块的性，模块内部最好是 功能内聚

• 偶然内聚性：模块内的各个元素之间没有任何关系，仅仅是偶然放在一起，内聚程度最低

• 过程内聚：模块内的各个成分通过执行一系列相关操作来完成一个具体任务

• 功能内聚：模块内的各个成分共同完成一个单一的功能

• 时间内聚：1.时间内聚⼜称为经典内聚

  ​ 2.模块内的各个成分在时间上相关，通常是指在同一个时间点或时间段内执行的多个操作

  • 初始化模块和结束模块从块内联系看 被称为时间内聚模块

• 逻辑内聚：模块内的各个成分通过某种逻辑关系联系在一起

• 通信内聚：模块内的元素通过操作同一个数据而联系在一起

• 顺序内聚：模块内的元素之间存在顺序关系，一个元素的输出是另一个元素的输入

20.CMM软件能力成熟度模型

• 简述：1.CMM 是⽤于衡量软件过程能⼒的事实上的标准 同时也是⽬前软件过程改进最好的参考标准

  ​ 2.CMM把企业控制软件过程的能⼒分五级 初始级 重复级 已定义级 已管理级和优化级

21.基线技术

• 简述：1.基线标志软件开发过程的各个⾥程碑任⼀SCI⼀旦形成⽂档并复审通过 即成为⼀个基线 它标志开发过程中⼀个阶段的结束

  ​ 2.对于已成为基线的SCI 虽然可以修改 但必须按照⼀个特殊的 正式的过程进⾏评估 确认每⼀处修改

22.⾯向功能的度量

• 面向功能的度量主要是通过衡量软件系统的功能来评估其复杂性、效率、质量等特征。面向功能的度量着重于软件提供的功能和这些功能所需要的资源或成本，它强调软件的功能性而非其代码结构或实现技术

• 优点：1.与程序设计语⾔⽆关

  ​ 2.功能点度能⽤于软件项⽬的开发初期

• 缺点：1.它涉及到的主观因素⽐较多 如各种权函数的取值

  ​ 2.信息领域中的某些数据有时不容易采集

  ​ 3.FP 的值没有直观的物理意义

23.软件工程原则

• 按软件⽣存期分阶段制定计划并认真实施
• 坚持进⾏阶段评审
• 坚持严格的产品控制
• 使⽤现代程序设计技术
• 明确责任
• ⽤⼈少⽽精
• 不断改进开发过程

24.软件生命周期的活动

• 主要活动：需求 设计 实现 确认 支持和管理
  • 需求：定义问题 即建立系统模型
  • 设计：在需求分析的基础上 给出系统的软件解决方案
  • 实现：选择合适的工具编码
  • 确认：需求 设计的评审及软件的测试
  • 支持：交付后的各种维护
  • 管理：对软件工程项目进行计划 组织 监控和管理

• 软件定义时期

  • 主要解决做什么的问题
  • 问题定义 可行性研究 需求分析

• 软件开发时期

  • 主要解决如何做的问题
  • 概要设计 详细设计 编码 测试

• 软件运行维护时期

  • 主要使软件持久地满足用户的需要
  • 改正性维护 适应性维护 完善性维护 预防性维护

25.结构化需求分析模型

• 简述：1.数据字典 实体-关系图 数据流图和状态迁移图及相关描述说明

  ​ 2.实体-关系图用于数据建模 数据流图用于功能建模 状态迁移图用于行为建模

26.扇入扇出

• 扇入衡量一个模块被上级调用的次数，表示其复用程度；
• 扇出则指模块直接管理的下级模块数量，过高表示复杂度增加。
• 理想情况下，应保持适度的扇出，避免模块过于复杂或内聚度低。适当增加中间模块层次可以降低扇出，而扇入过低可能需要考虑模块重构或合并。

27.软件设计原则

• 分而治之 模块性 提高抽象层次 复用性设计 灵活性设计