一小时软件工程概论期末速成！笑死，看这一篇就够了，根本挂不了！

软件工程概论

整理By Wolger “做好知识产权保护，有问题别来找我”

此篇内容为速成资料，其中的语言或许不严谨，请不要在意

使用教材为《软件工程实用案例教程》梁洁主编

标有?为考试中经常出现的题目，?越多代表越重要

全部看完不过找我，我把你头给锤烂，这么清晰的资料你能不过多半是有点东西的😅

第一章

软件的要点

1. **???软件的定义：**程序+数据+文档
2. ??软件本质特性：
   • 复杂性（简而言之就是很复杂）
   • 一致性（软件不能独立存在、软件必须遵循协议和适应已有系统、软件要与接口一致）
   • 可变性（就能迭代修改更新呗）
   • 不可见性（是逻辑实体、你无法知道它是如何执行的）

?简述软件危机

由于软件行业面临着巨大的挑战，一方面是软件的规模越来越大，复杂程度越来越高，对软件的需求越来越多，另一方面是软件生产效率低下，开发成本和进度难以控制质量难以保证这种现象，早在20世纪60年代被定义为软件危机。

?软件工程是什么

软件工程即按工程化的原则和方法应用于软件开发和管理

软件工程是系统化的，规范化的，可度量的方法应用于软件的开发运行和维护的过程。

软件工程的要点

1. **???软件工程三要素：**方法、过程、工具（没有理论！！）
2. **软件工程过程：**问题定义、需求开发、软件设计、软件构造、软件测试
3. 软件工程方法：
   • 结构化方法
     1. 过程：结构化分析、设计、实现
     2. 特点：分阶段、瀑布式开发模式、严格技术审查、采用结构化技术
   • 面向对象方法
     1. 过程：面向对象分析、设计、实现、测试（OOAnalysis、OODdesign、OOPrograming、OOTest）
     2. 特点：以对象为基本构建、构建与实现统一、重视软件复用、通过逐步演化完成开发
   • 可视化开发方法
4. 软件工程基本策略：
   • 软件复用（复用已有附件）
   • 分而治之（复杂问题拆分小问题）
   • 逐步演进（字面意思）
   • 优化折中（优化各个质量特性，协调使得整体最优）
5. 软件工程基本原理：（考到我倒立洗头）
   • 分阶段的生命周期严格管理
   • 坚持阶段评审
   • 严格产品控制
   • 采用现代程序设计技术
   • 结果能清楚审查
   • 开发人员少而精
   • 承认不断改进软件工程实践的必要性
6. 软件工程知识域：（别看看了也记不住）
   • 软件需求
   • 软件设计
   • 软件构造
   • 软件测试
   • 软件维护
   • 软件配置管理
   • 软件工程管理
   • 软件工程过程
   • 软件工程工具和方法
   • 软件质量

第二章

软件过程

1. **?分为哪些过程：**组织过程、主要过程、支持过程
2. ?**软件过程概念：**软件过程是软件生命周期中一系列相关过程
3. ???软件生命周期（括号内为瀑布模型所要完成的文档）
   • 可行性研究（可行性研究报告）
   • 需求分析（软件需求规格说明）
   • 设计（软件设计说明书）
   • 编码（源代码清单）
   • 测试（测试报告）
   • 维护

软件过程模型

1. ???瀑布模型（将开发活动划分为界限分明的独立阶段，文档见上）

2. 快速原型化模型（根据需求整个原型/样品给客户看看）

3. 增量模型（先整个核心功能，其他阶段性的慢慢加，该模型有个假设即需求可以分段）

4. ?螺旋模型（瀑布+快速原型）
   • 确定下一阶段目标
   • 开发方案及约束条件、风险分析﹑构造原型
   • 开发﹑验证阶段软件产品
   • 制定下一阶段计划

?软件过程模型的优缺点（盲猜不会考到）

模型	优点	缺点
瀑布模型	定义清楚，应用广泛; 强迫开发人员采用规范化的方法; 严格规定每个阶段提交的文档; 易于建模和理解;便于计划和管理; 有支持生命周期模型的多种工具。	必须在开始时就知道大多数需求; 不便于适应需求的变化; 在项目接近完成之前，产品不能投入使用; 可运行的软件交付给用户前，用户只能通过文档来了解。
快速原型化模型	直观形象，符合人们认识事务循序渐进的规律，容易被接受;有效地避免开发人员和用户对需求理解的不一致性; 及时暴露问题、及时反馈，确保系统的正确性; 开发周期短、成本低，软件尽早投入使用。	为了加快开发速度，常常导致软件质量的降低; 没有严格的开发文档，维护困难; 缺乏统一的规划和开发标准; 难以对系统的开发过程进行控制。
增量模型	降低拖延、需求变更及验收间题的风险; 提高项目开发的可管理性; 将一个时间周期较长的项目分解开发。	同瀑布模型一样，必须在早期就了解大部分需求： 对选择具体构件的开发方法敏感： 需要对每次发行进行回归试，增加软件试工作量； 生命周期的早期就将产品置于配置控制之下，因而需要正式的更改控制过程，将增加系统开销.
螺旋模型	设计上的灵活性，可以在项目的各个阶段进行变更; 以小的分段来构建大型系统,使成本计算变得简单容易; 用户始终参与每个阶段的开发，保证了项目的方向与可控性; 具有瀑布模型和原型模型两者的优点。	采用螺旋模型需要丰富的风险评估经验和专门知识 在风险较大的项目开发中,如果未能够及时标识风险,势必造成重大损失; 过多的迭代次数会增加开发成本,延迟提交时间。

??递增与迭代

1. 区别：

   • 递增是在每一个发布中增加功能直到构造全部内容。

   • 迭代是交付一个完整系统的子集，在后续发布中补充完善

2. 相同点：

   • 都是从小的构件逐步到一个完整系统

??敏捷开发宣言

• 个体和交互胜过过程和工具
• 可以工作的软件胜过面面俱到的文档
• 客户合作胜过合同谈判
• 响应变化胜过遵循计划

第三章

人员组织与优化

1. ? 人员组织形式：
   • 民主式（人人平等，缺乏领导，适用规模小）
   • 主程序员式（一带多，分工明确，简化沟通，主程序员必须要有管理和技术才能）
   • 现代程序员（取消主程序员行政管理，分为行政组长和技术组长）

???软件度量—软件规模与成本估算

1. 估算方法

   • 分解技术

   • 经验模型技术

2. 软件规模估算的主要方式

   • ???代码行（用源代码长度来测量）
     $$LOC=(sa+4sm+sb)/6$$
     

   • ???功能点（FP Function Point 功能点没有单位）

     题目一般会给两个表格，一个是功能点数量表、另一个是权重表，简单的题会告诉你F(因子权重)都等于某个数，一共有14个F

     • 解题方法

       1. 算UFP（未调整功能点）

          数量表和权重表每行的低中高一一相乘后相加，然后把每行的UFP都加起来得到总的

          

       2. 算TCF（技术复杂性因子，计算量简单的题会告诉你每个F都一样）
          $$TCF=0.65+0.01?\sum _{i=1}^{14}{F}_i$$

       3. 把两个相乘

       $$FP=UFP?TCF$$

     • 例题

     

3. 基于模型的工作量估算：

   • IBM模型

   • ???COCOMO模型

     • 基本COCOMO

       E是工作量（人月），L是代码行（单位是千行），a和b题目会告诉
       $$E=a?L^b$$
       D是开发时间（月），c和d题目会告诉应该
       $$D=c?E^d$$

     • ???中等COCOMO

       在后面乘个调节因子EAF
       $$EAF=F_1?F_2...?F_{17}$$

       $$E=a?L^b?EAF$$

     • 高等COCOMO（不考）

4. 软件开发成本的估算（看题目给了什么，要看清楚单位，C是平均成本一般是多少/人月，E是工作量人月）
   $$成本=C?E$$

软件项目计划

1. 在制定软件项目计划之前应先确定 目标和范围

2. 进度计划编制方法：

   • 甘特图法

   

   • 网络图法

     • 节点型网络图（PDM一般不考）

     

     • 箭线型网络图（ADM）

• ?两者优缺点
  | 编制方法 | 优点 | 缺点 |
  | -------- | ------------------------ | ------------------------------------------------------------ |
  | 甘特图法 | 更能直观的显示任务的进程 | 不能系统地表达一个项目所包含的各项工作之间的复杂关系 |
  | 网络图法 | 更能展示任务之间的相关性 | 不能系统地表达每项的起始时间与结束时间，不易于对单项任务的过程进行跟踪 |

3. ???关键路径法（CPM 采用箭线型网络图）

   什么是关键路径？对于一个项目来说最长的或耗时最多的路线，只有这条线结束了项目才算结束

   什么是关键任务？就是关键路径上的任务

   题型1：给你个网络图，让你找关键路径

   • 解法：

     1. 图上会有时间，遍历下每个节点，找出全部路径
     2. 然后把每条路径上的时间加起来，最长时间的那条就是关键路径
     3. 当然你也可以一眼看出来，反正时间最长的那条就对了

   • 例题：

     

   题型2：给你个网络图，让你算关键任务最早开始时间、最迟开始时间

   • 解法：（和下面例题一起看，以5节点为例，因为它很特殊）

     • 先整最早开始时间（顺着来）
       1. 从头开始一个节点一个节点来，选定一个节点
       2. 看有多少箭头指向这个节点，有三个箭头就说明，有三条路径都能到这个节点
       3. 那么去算每条路径的持续时间（就时间加起来），找到最长的时间，就是最早开始时间
       4. 然后这个节点就完事了，下一个节点重复这个步骤
     • 再整最迟开始时间（逆着来）
       1. 从屁股开始，最后一个节点的最迟的和最早是一样的（其实就是关键路径的时间）
       2. 把箭头反过来（当然你也可以不反，反过来是为了思考起来更简单）
       3. 如果你箭头反过来了，那么就和上面一样，去看有多少箭头指向它
       4. 同样的去算指向它的路径的持续时间，同样的也是找到长的时间
       5. 但是！不同的是，你要用屁股节点的时间减去这个数，然后你就得到了它的最迟开始时间

   • 例题：

     

软件配置管理

1. **产生背景：**单纯就是因为管不好，其中一个原因是版本太多了，需要一个版本管理的东西。
2. ??**目的：**控制变化
3. ??**定义：**通过版本控制 和变更控制来管理配置项的完整性和可追踪性
4. ?**主要手段或方法：**其主要手段是采用软件配置项标识、版本控制、变化控制、配置审计和发布配置状态报告等活动
5. 软件配置管理的基本概念
   • 基线（别听概念，其实就是给他打了个标签，告诉别人它差不多得了能用了，可以作为一个小版本了，你可以在这个版本上继续改了，之后如果改崩了也能重新回到这个版本）
     • ?基线的概念
       1. 已经通过正式复审和批准的软件和各类文档,标准或规约
       2. 可以作为进一步开放的基础
       3. 只能通过正式的变化控制过程才允许对它们进行变更
   • 软件配置项（SCI 就是你做出的各种东西叫软件配置项，md怎么喜欢瞎取名，名字和概念屁都对不上）
     • ?软件配置项的概念：软件生命周期内产生、需进行配置管理的各种工作产品、文档、程序、数据、标准和规约
     • ??它是软件配置管理的基本单位！！
   • 配置控制委员会（CCB，管理员差不多意思，一般不会考）

第四章

需求工程

1. ???软件需求的类别

   • 业务需求（确定了系统的目标、规模、范围）
   • 用户需求！！（最重要的，用户就是你爹）
   • 功能需求（开发者必须实现的软件功能）
   • 非功能需求（对用户重要和对开发者重要的属性）

   例子（一个字词检查程序）：

   

需求工程的任务

??需求工程分为需求开发和需求管理（看图）

**需求开发：**需求获取、需求分析、需求描述、需求验证

**需求管理：**变更控制、版本控制、需求跟踪、需求状态跟踪

需求工程的过程（一般不考）

1. 获取需求（面谈法、问卷法、需求专题研讨会）
2. 需求分析与建模（提炼需求、绘制完整性的描述）
3. 确认需求（需求有效性验证）
4. 需求管理（保证一致性，控制需求变更）

第七章

别问中间那几章去哪了，反正它不考

??面向对象基本概念

1. 什么是对象：对象是描述客观事物的实体，是构成系统的基本单位，可以有形也可无形，有自身属性和行为
2. **什么是类：**具有相同属性和行为的对象集合
3. **是什么是消息机制：**对象直接收发消息进行协作，是联系纽带（就是调用呗）

面向对象方法的主要特点（知道就行）

1. ??从客观存在的事务构造软件系统

   • 对象是系统的基本单位

   • 事务的静态特征用对象的属性来表示

   • 事务的动态特征用对象的操作来表示

2. ?对象的属性和操作合为一体，构成独立的实体，对外屏蔽内部细节，这叫封装

3. 对事物进行分类，相同属性和操作的对象为一类，每个对象都是类的一个实例

4. 运用抽象的原则，可通过继承一般类的属性和操作，得到特殊的类

5. 复杂对象可以用简单对象来构成（聚合）

6. 对象之间只能通过消息进行通信

7. 用关联来表达两个或多个类之间的关系，就是1对1，1对多的那种图

???面向对象的三大特征

1. 封装：将属性和方法封装在一起就是类，对外隐藏内部细节
2. 继承：子类可以继承父类，子类可添加也可改写属性和方法
3. 多态：同一操作对不同类的示例，将会有不同的执行结果

???面向对象的基本阶段

1. 面向对象分析（OOA）
2. 面向对象设计（OOD）
3. 面向对象实现（OOP）

???典型的面向对象开发方法

1. **???Booch法：**类图、状态图、对象图是从该方法继承的
2. **Coad/Yourdon法：**五层分析模型
3. **OMT法：**三个视角描述系统，四个阶段描述开发
4. ???**OOSE法：**提出用例驱动

???UML语言（统一建模语言）

UML采用“可视化”图形来定义语言，让人和机器都能读懂

1. 核心元素
   • 参与者、用例、边界、分析类、设计类、关系、包、组件、节点
2. ???UML9图

???必须要会画的三种图（不会等挂吧）

1. 用例图

   基本元素：

   • 角色（用小人代表、一般为系统的使用者）

   • 用例（用椭圆代表、动词+名词）

   • 关系（一条实线/虚线+小箭头/三角箭头代表、记得写<><>）

     用例图中有关联、包含、扩展、泛化关系

     • 角色和用例：关联

     • 用例和用例：包含，扩展，泛化

     • 角色和角色：泛化

     注：

     包含关系的子用例是一定会用到的，箭头指向子用例

     扩展关系的用例只在特定情况下用到，箭头指向父用例

     泛化关系是子用例/角色继承父用例/角色的所有东西，但特殊一点，箭头指向父用例

   例子：

   

   用例规约（不一定会考）：

   

2. 类图（太简单了懒得写了）

   基本元素：

   • 类（用一个框中间一条线表示，一般都是实体类，名词和动词都可以）

   • 关系（关联、聚集和组合、泛化、依赖）

     • 关联：类之间的固有联系，记得写关联名（具体的操作），记得写多重性，还可以通过关联类来描述关联的信息
     • 聚集和组合：
       1. 聚集(聚合)：整体和部分，注意这里的整体和部分是松散的，部分并不一定依赖于整体，例如雁群和大雁，雁群不存在了，大雁依然可以单独存在。
       2. 组合：同样是整体和部分，但是这个部分非常依赖整体，也就是说当整体不存在了，部分绝对也不存在了，例如大雁和翅膀，大雁没了，翅膀绝对也没了。
     • **泛化：**泛化一般表示为继承关系，即子类具有和父类相同的属性和行为。箭头指向父类。
     • **依赖：**依赖表示当某个类A变了，另一个类B肯定也会变，称为B依赖A，例如课表依赖课程。箭头指向A（被依赖的那个）

   例子：

   

   

   

3. 顺序图

   基本元素：

   • 对象（上面小人和一排框）
   • 生命线（竖着的虚线）
   • 激活（虚线上的框）
   • 消息（线+箭头+字，使用动词+名词，要对别人做了什么事，或者自己对自己做了什么事）

   和其他图的关系：

   • 顺序图和用例图：顺序图是从计算机角度（对象的交互）描述用例
   • 顺序图和类图：类图描述的是系统静态结构，顺序图描述的是动态结构

   画图小技巧

   无外乎三个类，边界类（就是界面），控制类（就是某个总控制台，可以理解为后端程序），实体类（一般来说就是数据库，各种记录，各种信息）

   所以，画顺序图实际上就是套模板，你可以看到之后所有例题，基本都能对应我这套模板。

   1. 先整个界面，界面上操作无外乎打开界面、查看信息，填写信息，单击确认，直接抄上去。
   2. 再来个控制类，一般命名就是什么什么处理、什么什么控制，这个什么什么其实就是你系统要完成的操作，比如说借书系统就是借书处理，选课系统就是选课处理，很简单，不用想的。名字写好了，那这个类的操作只有一个，就是确认！当然你也可以加点字，比如什么什么确认，确认什么什么的。
   3. 然后是各种实体类，上面说了其实就是对数据库的操作，题目一般会告诉你一部分的实体的，当然你也可以凭借你的脑子，一般来说，绝对会有的三个类是用户类（具体用户名字具体看系统，当然有时候就一个用户类可能已经写在最前面了，那就不要写了）、你这个系统要操作的那个对象类、以及用户和那个对象之间的记录类，以服装预定系统为例，分别就是顾客类、服装类、预定记录类。图书借书系统就是读者类、图书类、借书记录类。
   4. 写完实体类的名称之后，具体的操作是什么呢？还是很简单，就是检查，检查，检查，疯狂检查，然后修改某个记录，然后新增某个记录，这个检查检查什么呢，其实就是检查你上面写的实体类，直接把名字拿过来套就行，检查用户信息、检查订购的服装信息，如果觉得太短，那就检查用户信息是否怎么怎么样，比如检查用户信息是否存在之类的话，再然后是修改某个记录，你可以根据具体题目来，比如服装预定，那就是对服装类操作，修改服装数量-1，最后新增一条预定记录。
   5. 好了，完事了，根本不需要脑子，顺序图是这里面最简单的，把上面的套上去80%的分就有了，然后就得根据具体题目来了。

   例子：